· No d’ordre: 3586 THÈSE présentée devant l’Université de Rennes 1 pour obtenir le grade de : DOCTEUR DE L’UNIVERSITÉ DE RENNES 1 Mention INFORMATIQUE par …

No d’ordre: 3586

THÈSE

présentée

devant l’Université de Rennes 1

pour obtenir

le grade de : DOCTEUR DE L’U NIVERSITÉ DE RENNES1Mention INFORMATIQUE

par

Kamal Deep SINGH

Équipe d’accueil : DIONYSOS - INRIA RennesÉcole Doctorale : Matisse

Composante universitaire : IFSIC

Titre de la thèse :

Improving Quality of Service and Resource Utilization forMultimedia Streaming over Third Generation Mobile

NetworksSoutenue le 17 Décembre 2007 devant la commission d’examen

MM. : Gerardo RUBINO PrésidentMM. : André-Luc BEYLOT Rapporteurs

Andrzej DUDA

MM. : David ROS ExaminateursLaurent TOUTAIN

César VIHO

Mme.: Ana Carolina MINABURO Invitée

Acknowledgments

It is with great pleasure and felicity that I would like to express thanks to all the peoplewho have made this thesis possible.

I am grateful to Ana Minaburo and Laurent Toutain, who is alsomy co-advisor, forall their help and for motivating me to start the thesis. Special thanks to my co-advisorDavid Ros for all the thorough discussions related to the thesis. Special thanks againto my thesis director César Viho for providing strong supportand the opportunity towork in this research domain. The painstaking guidance and technical feedback of myadvisors have led to the successful culmination of this thesis.

I thank Conseil régional de Bretagne, ref. B/1042/2004/MOTIV6, and the Euro-pean project IST-035072 STP ANEMONE (Advanced Next gEneration Mobile andOpen Network) of FP6 for partially financing my thesis.

I would like to express gratitude to my professors at IIT Delhi who have inculcatedme with the fundamentals of computer science and electronics. I wish to thank thejury members and the rapporteurs, André-Luc Beylot and Andrzej Duda, as it is agreat honor for me to have them evaluate my work.

The influential technical discussions with Gerardo Rubino, Arpad Huszak, BrunoTuffin, Xavier Lagrange and Julio Orozco have greatly helpedin the advancement ofthis thesis.

I would like to thank Priyanka Rawat for proof reading my thesis and Sachin Upad-hyay for working with me during his internship. I am thankfulto Alexandra Desmoulinand Fatma Bouabdallah for helping me write the synopsis of my thesis in french. Ithank Adlen Ksentini, Majd Ghareeb and Kandaraj Piamrat forassisting me to im-prove my presentation for the thesis defense.

Furthermore, I would like to thank the project assistants atINRIA, including Fabi-enne Cuyollaa, for their support. I would like to thank all of my friends and colleaguesat INRIA and ENSTB for creating a convivial atmosphere. Some of whom are An-nie, Anthony, Antoine, Ariel, Bruno Sericola, Cécile, Elisabeth, Francis Dupont, Fréd,Géraldine, Gildas, Guillaume, Jad, Jean-Marie Bonnin, Joanna, Laurent Guillo, Louis-Marie Le NY, Lucian, Nizar, Pablo, Samer and Xavier. In addition, I wish to expressmy gratitude to all those people, whose name I may not have mentioned here, for theirkindness and assistance.

I wish to thank my friends, my brothers and my relatives for providing a loving en-vironment for me. Lastly, and most importantly, I feel indebted to my parents, DheerSingh and Gyanesh Kumari for encouraging me and always beingthere for me. With-out their continuous support this work would not have been possible. To them I dedi-cate this work.

Table des matières

Table des matières 1

Amélioration de la qualité de service et de l’utilisation des ressources pour latransmission multimédia sur les réseaux mobiles de troisième génération 61.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Diffusion Multimédia et Qualité de Service . . . . . . . . . . .. . . 8

1.2.1 Compression Vidéo . . . . . . . . . . . . . . . . . . . . . . . 81.2.2 Diffusion Vidéo (Video-Streaming) . . . . . . . . . . . . . . 91.2.3 Qualité de Service . . . . . . . . . . . . . . . . . . . . . . . 9

1.3 Réseaux UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.4 La compression d’en-tête d’IP pour les flux multimédias .. . . . . . 11

1.4.1 Configuration de ROHC . . . . . . . . . . . . . . . . . . . . 121.4.2 Protocoles UDP lite et ROHC . . . . . . . . . . . . . . . . . 13

1.5 Video-Streaming au-dessus de High Speed Downlink Packet Access(HSDPA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.5.1 L’ordonnanceur Normalized Rate Guarantee . . . . . . . . . 17

1.6 Contrôle de congestion pour les flux vidéo . . . . . . . . . . . . . .. 211.6.1 TFRC sur HSDPA . . . . . . . . . . . . . . . . . . . . . . . 211.6.2 Estimation de perte sans fil et retransmission sélectives . . . . 22

1.6.2.1 Un schéma d’estimation de perte sans fil . . . . . . 221.6.2.2 Les retransmissions sélectives . . . . . . . . . . . . 25

1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.7.1 La compression d’en-tête pour les flux Multimédia . . . .. . 291.7.2 Diffusion Vidéo sur HSDPA . . . . . . . . . . . . . . . . . . 291.7.3 Contrôle de congestion pour les flux vidéo . . . . . . . . . . . 30

1

2 Table des matières

Improving Quality of Service and Resource Utilization for Mul-timedia Streaming 30

2 Introduction 332.1 Evolution to 3G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.2 Context and Contributions of this Thesis . . . . . . . . . . . . . . .. 342.3 Dissertation Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.3.1 Part I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.3.2 Part II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.3.3 Part III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.4 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3 Multimedia Streaming over Third Generation Mobile Networks 393.1 Video Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.1.1 Video Compression Standards . . . . . . . . . . . . . . . . . 403.1.1.1 MPEG-4 . . . . . . . . . . . . . . . . . . . . . . . 403.1.1.2 H-264/AVC . . . . . . . . . . . . . . . . . . . . . 403.1.1.3 MPEG4-SVC . . . . . . . . . . . . . . . . . . . . 41

3.2 Video Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3 Video Quality Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3.1 Objective Assessment . . . . . . . . . . . . . . . . . . . . . 433.3.2 Subjective Assessment . . . . . . . . . . . . . . . . . . . . . 44

3.4 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.4.1 DiffServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.4.1.1 Expedited Forwarding . . . . . . . . . . . . . . . . 453.4.1.2 Assured Forwarding . . . . . . . . . . . . . . . . . 46

3.4.2 DiffServ aware Video Streaming . . . . . . . . . . . . . . . . 473.5 UMTS Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.5.1 All IP Network . . . . . . . . . . . . . . . . . . . . . . . . . 503.5.2 QoS in UMTS . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.5.2.1 UMTS QoS Classes . . . . . . . . . . . . . . . . . 513.5.3 Long Term Evolution (LTE) . . . . . . . . . . . . . . . . . . 523.5.4 High Speed Downlink Packet Access . . . . . . . . . . . . . 53

I Header Compression for Multimedia Flows 55

4 Robust Header Compression (ROHC) 574.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.2 Header Compression . . . . . . . . . . . . . . . . . . . . . . . . . . 594.3 Header Compression in the UMTS . . . . . . . . . . . . . . . . . . . 594.4 Robust Header compression (ROHC) . . . . . . . . . . . . . . . . . . 60


4.4.1 ROHC Context . . . . . . . . . . . . . . . . . . . . . . . . . 624.4.2 Protocol stack and ROHC profiles . . . . . . . . . . . . . . . 62

4.4.2.1 Link Layer . . . . . . . . . . . . . . . . . . . . . . 624.4.2.2 Network Layer . . . . . . . . . . . . . . . . . . . . 624.4.2.3 Transport Layer . . . . . . . . . . . . . . . . . . . 634.4.2.4 Application Layer . . . . . . . . . . . . . . . . . . 634.4.2.5 ROHC Profiles . . . . . . . . . . . . . . . . . . . . 64

4.4.3 ROHC Negotiation . . . . . . . . . . . . . . . . . . . . . . . 644.4.4 Compression Levels of the Compressor . . . . . . . . . . . . 654.4.5 Operation Modes . . . . . . . . . . . . . . . . . . . . . . . . 664.4.6 ROHC Decompressor . . . . . . . . . . . . . . . . . . . . . 664.4.7 Mode Transition . . . . . . . . . . . . . . . . . . . . . . . . 67

4.5 ROHC Implementation Platform . . . . . . . . . . . . . . . . . . . . 684.5.1 ROHC Implementation . . . . . . . . . . . . . . . . . . . . . 684.5.2 Error Simulator . . . . . . . . . . . . . . . . . . . . . . . . . 694.5.3 CRC coverage for Sequence Number (SN) . . . . . . . . . . 70

5 Optimization of Robust Header Compression over UMTS 735.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.2 ROHC compression parameters and schemes . . . . . . . . . . . . .745.3 Configuration of ROHC . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.3.1 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.3.2 Compression Efficiency vs. Robustness . . . . . . . . . . . . 77

5.3.2.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . 795.3.2.2 Optimistic Approach . . . . . . . . . . . . . . . . 815.3.2.3 Sliding Window Width (SWW) . . . . . . . . . . . 81

5.4 Dynamic Negotiation for ROHC . . . . . . . . . . . . . . . . . . . . 835.4.1 Dependence of the ROHC parameters on link characteristics . 855.4.2 Optimization of ROHC performance . . . . . . . . . . . . . . 86

5.5 Performance Improvement of Multimedia flows by using UDP-Lite . 875.5.1 Checksum coverage levels . . . . . . . . . . . . . . . . . . . 895.5.2 Performance Improvement . . . . . . . . . . . . . . . . . . . 91

5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

II Video Streaming over High Speed Downlink Packet Access 95

6 High Speed Downlink Packet Access 976.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.2 High Speed Downlink Packet Access (HSDPA) . . . . . . . . . . . .98

6.2.1 Channel Adaptation . . . . . . . . . . . . . . . . . . . . . . 100


6.2.2 Hybrid ARQ . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.2.3 Packet Scheduling . . . . . . . . . . . . . . . . . . . . . . . 100

6.3 HSDPA Packet Schedulers . . . . . . . . . . . . . . . . . . . . . . . 1016.3.1 Round-Robin Scheduling . . . . . . . . . . . . . . . . . . . . 1026.3.2 Maximum C/I Scheduling . . . . . . . . . . . . . . . . . . . 1036.3.3 Proportionally Fair Scheduling . . . . . . . . . . . . . . . . . 1036.3.4 Rate-Guarantee Scheduling . . . . . . . . . . . . . . . . . . 104

6.4 Simulation Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056.4.1 QoS-aware IP Queue Management in the UTRAN . . . . . . 1066.4.2 Physical layer model in EURANE . . . . . . . . . . . . . . . 106

6.5 Related Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

7 Streaming of H.264 Video over HSDPA: Impact of MAC-Layer Schedulerson User-Perceived Quality 1097.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107.2 Estimation of Subjective Video Quality . . . . . . . . . . . . . .. . 1117.3 Normalized Rate Guarantee Scheduling . . . . . . . . . . . . . . . .1127.4 Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 114

7.4.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 1157.4.2 Simulation Scenarios . . . . . . . . . . . . . . . . . . . . . . 117

7.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187.5.1 Video Quality vs. Best Effort Throughput . . . . . . . . . . . 1197.5.2 Long-Lived Flows as Background Traffic . . . . . . . . . . . 121

7.5.2.1 Simple Call Admission Control . . . . . . . . . . . 1217.5.2.2 Restricted Access to Video Users . . . . . . . . . . 1227.5.2.3 Best Effort Load . . . . . . . . . . . . . . . . . . . 124

7.5.3 Mix of TCP Long-Lived and WWW Flows as BackgroundTraffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

7.5.4 Evaluation using PSNR . . . . . . . . . . . . . . . . . . . . . 1287.5.5 Comparison of loss rates . . . . . . . . . . . . . . . . . . . . 131

7.6 Discussion and Conclusions . . . . . . . . . . . . . . . . . . . . . . 132

8 Proportional Resource Partitioning over Shared WirelessLinks 1358.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1358.2 Weighted Proportional Resource Partitioning . . . . . . . . .. . . . 136

8.2.1 A lower QoS class as a single virtual user of a higher class . . 1378.3 Partitioning Strategies for Video-Streaming and Best-Effort Users . . 138

8.3.1 No guarantees to BE users . . . . . . . . . . . . . . . . . . . 1398.3.2 BE users as a single virtual QoS user . . . . . . . . . . . . . 1408.3.3 VS users employing rate control . . . . . . . . . . . . . . . . 142


8.3.4 Congestion control based on available resources . . . . .. . 1448.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

III Congestion Control for Video Flows 145

9 TCP-Friendly Rate Control over High-Speed Downlink PacketAccess 1479.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1479.2 Congestion Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

9.2.1 Transmission Control Protocol (TCP) . . . . . . . . . . . . . 1489.2.2 Congestion Control for Video Flows . . . . . . . . . . . . . . 1489.2.3 TCP-Friendly Rate Control (TFRC) . . . . . . . . . . . . . . 149

9.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1509.4 Simulation Models and Scenarios . . . . . . . . . . . . . . . . . . . 1519.5 Results and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 153

9.5.1 RNC Buffer Size . . . . . . . . . . . . . . . . . . . . . . . . 1539.5.2 HSDPA Schedulers . . . . . . . . . . . . . . . . . . . . . . . 1549.5.3 Comparison of TFRC and TCP . . . . . . . . . . . . . . . . 156

9.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

10 Improvement of Multimedia Streaming using Estimation of Wireless losses16310.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16410.2 The WLED Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

10.2.1 WLED Algorithm . . . . . . . . . . . . . . . . . . . . . . . 16510.2.2 Integration of WLED with Multimedia Rate-Control Protocols 16710.2.3 Loss Estimation . . . . . . . . . . . . . . . . . . . . . . . . . 168

10.3 Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 16810.3.1 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . 16910.3.2 Choice of Loss Estimator and Thresholdθ . . . . . . . . . . . 17010.3.3 Link Utilization . . . . . . . . . . . . . . . . . . . . . . . . . 17310.3.4 TCP Friendliness . . . . . . . . . . . . . . . . . . . . . . . . 17310.3.5 Marking Scheme . . . . . . . . . . . . . . . . . . . . . . . . 174

10.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

11 Congestion Control and Adaptive Retransmission for Multimedia Stream-ing 17911.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17911.2 WLED-ARC with DCCP . . . . . . . . . . . . . . . . . . . . . . . . 18011.3 The Retransmission Scheme . . . . . . . . . . . . . . . . . . . . . . 18211.4 Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

11.4.1 Droptail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18511.4.2 RIO (Red In and Out) . . . . . . . . . . . . . . . . . . . . . 188


11.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

12 Conclusion and Future Work 19112.1 Header Compression for Multimedia Flows . . . . . . . . . . . . .. 19112.2 Video Streaming over High Speed Downlink Packet Access. . . . . . 19212.3 Congestion Control for Video Flows . . . . . . . . . . . . . . . . . . 194

Glossaire 197

Bibliographie 215

Table des figures 217

Amélioration de la qualité de service etde l’utilisation des ressources pour latransmission multimédia sur lesréseaux mobiles de troisièmegénération (3G)

1.1 Introduction

La première génération de réseaux mobiles (appelée 1G) a étéproposée en 1980et est basée sur de la technologie analogique. Elle a été remplacée par une deuxièmegénération de réseaux mobiles (appelée 2G) qui est basée surune technologie numé-rique. La norme GSM (pour «Global System for Mobile Communication»), développéen Europe, est actuellement la norme la plus populaire de réseaux mobiles 2G et lanorme la plus utilisée dans le monde. L’objectif lors de la conception de ces réseauxmobiles 2G était d’avoir des services vocaux de bonne qualité.

La troisième génération de réseaux mobiles (appelée 3G) a été conçue dans l’ob-jectif d’améliorer encore la communication en fournissantdes débits élevés de l’ordrede 2 Mbps. Les réseaux 3G doivent également fournir des services variés, comme lemultimédia, en plus des services traditionnels que sont lesservices vocaux. L’augmen-tation du nombre de services est possible grâce à l’augmentation des débits dans lesréseaux mobiles 3G et également grâce au support de la Qualité de Service (QoS).

On assiste aujourd’hui à une évolution vers des réseaux “tout IP”, plus efficaceset moins coûteux pour les opérateurs. De nouveaux problèmesse posent comme parexemple le sur-coût dû aux en-têtes IP ou des taux de pertes depaquets élevés surdes liens radio. De plus, la plupart des réseaux IP existantsne peuvent satisfaire lescontraintes, en termes de délai, gigue ou pertes, des applications comme la diffusionmultimédia. Dans cette thèse, nous nous intéressons aux problèmes de diffusion mul-timédia sur IP dans les réseaux 3G.

La première partie de cette thèse (cf. Part I) porte sur un schéma de compression

7

8 Transmission multimédia sur les réseaux mobiles de troisième génération

permettant de réduire le sur-coût induit par les en-têtes IP. Ensuite (cf. Part II), nousintroduisons de nouvelles stratégies pour le support de la qualité de service, baséessur l’ordonnancement des paquets. Enfin (cf. Part III), nousétudions le contrôle decongestion pour la vidéo, et nous proposons des mécanismes d’estimation des pertesdues à des liaisons radio et de retransmission sélective, visant à améliorer la qualitédes flux vidéo.

Cette partie du document est un résumé (en français) des principaux résultats dé-crits dans le manuscrit (en anglais). Les sections 1.2 et 1.3décrivent certains principesliés à cette thèse. Dans la section 1.4, nous étudions la compression d’en-tête dans lesréseaux 3G. La fourniture de QoS sur les réseaux 3G est discutée dans la section 1.5. Lasection 1.6 décrit l’étude liée aux mécanismes du protocolede contrôle de congestionadaptés aux flux vidéo.

1.2 Diffusion Multimédia et Qualité de Service

Dans cette section, nous nous intéressons aux problèmes de compression multimé-dia. Nous nous concentrons sur la compression vidéo plutôt que sur la compressionaudio. En effet, la transmission de flux vidéo nécessitent beaucoup plus de bande pas-sante que celle de flux audio. Néanmoins, la plupart des principes décrits peut égale-ment s’appliquer aux flux audio.

1.2.1 Compression Vidéo

Principe : En règle générale, la numérisation d’une source vidéo génère une grandequantité de données. Il convient donc de les compresser avant transmission. Les mé-canismes de compression vidéo sont basés sur l’éliminationdes redondances dans uneséquence d’images. Il existe des redondances spatiales et des redondances temporelles.La redondance spatiale apparaît à l’intérieur d’une image vidéo quand une zone (éga-lement appelée région) est égale à une ou plusieurs régions contiguës de l’image. Laredondance temporelle se produit entre des trames contiguës : en effet, dans une vidéo,la différence entre une image et la suivante est souvent trèsfaible. Le codec utilisé(pour le codage lors de la compression) réduit la redondancespatiale en prenant unerégion comme référence pour ses voisins. De même, le codec prend certaines tramescomme références temporelles pour les trames suivantes. Dans les deux cas, seules lesdifférences avec la trame de référence sont considérées. Laplupart des normes de co-decs sont ainsi basées sur ces idées.

Les Normes :MPEG-1 est la première norme de compression pour la compressionaudio et vidéo, qui a été défini par le «Moving Pictures Experts Group» (MPEG). Uneautre norme, appelée MPEG-2, a été choisie comme système de compression pour

Diffusion Multimédia et Qualité de Service 9

«Digital Video Broadcast» (DVB) et «Digital Video Disk» (DVD). MPEG-4 est lanouvelle norme définie après MPEG-2. MPEG-4 fournit une meilleure qualité et unmeilleur taux de compression en comparaison des normes précédentes.

1.2.2 Diffusion Vidéo (Video-Streaming)

La diffusion vidéo (video-streaming) sur les réseaux a des exigences strictes entermes de délai et de gigue. La raison est que les unités de données vidéo doivent êtrereçues par le client pour la présentation avant un instant bien déterminé.

L’encodeur vidéo compresse ou encode les données dans un fichier vidéo. Ce fi-chier peut être stocké dans le serveur de diffusion pour plustard. Le serveur peutcommencer à transmettre la vidéo dès qu’un client demande lavidéo. Habituellement,le client commence à lire la vidéo après un certain retard initial qui est généralement del’ordre de 4 à 8 secondes. Ce retard initial est utilisé pour bufferiser les données dansune zone mémoire du client appelée «play-out buffer». Elle absorbe la gigue entre lespaquets et veille aussi à une lecture correcte de vidéo, mêmelorsque la bande passanteréseau devient insuffisant pendant un certain temps. Il convient de noter que ce «play-out buffer» ne peut absorber que les variations de délai ou debande passante à courtterme. Les variations à long terme peuvent dégrader la qualité de la vidéo et peuventintroduire une discontinuité dans sa lecture.

1.2.3 Qualité de Service

Certaines applications, comme le video-streaming, ont des exigences qui ne peuventêtre satisfaites avec un service BE (Best Effort) quand il n’y a pas assez de ressourcesdisponibles ou lorsque le réseau est encombré (problème de congestion). Pour ces ap-plications, l’infrastructure du réseau doit être adaptée afin de leur accorder un trai-tement spécial en termes de délai, de perte, de gigue, etc. Ce traitement spécial estgénéralement appelé Qualité de Service (QoS).

L’IETF (Internet Engineering Task Force) a développé des normes et technologiesafin de fournir de la QoS dans les réseaux IP. L’architecture DiffServ (DifferentiatedServices) est l’architecture la plus utilisée. Dans DiffServ, le trafic est divisé en diffé-rentes catégories de services en fonction des besoins individuels. À la périphérie desréseaux, les paquets sont marqués, selon le traitement qu’il souhaite recevoir à l’inté-rieur des réseaux. Le marquage est une valeur appelée «DiffServ Code Point» (DSCP)dans l’en-tête IP. Des paquets avec la même valeur DSCP appartiennent à la mêmeclasse et doivent recevoir le même traitement à l’intérieurdes réseaux. Les différentstraitements accordés aux paquets par les routeurs sont appelés PHB (Per Hop Beha-viors).

Le PHB EF (Expedited Forwarding) [69] est conçu pour des services comme laVoix sur IP (VoIP). Un des PHBs liés à la diffusion multimédia est le PHB AF (As-


sured Forwarding) [60]. Il fournit quatre classes avec trois priorités. Ces priorités sontgénéralement identifiées avec des couleurs :vert est la priorité d’envoi la plus haute,jaunela priorité moyenne etrougela priorité la plus basse.

Dans une configuration typique utilisant un PHB de type AF, lemarquage est ef-fectué par les routeurs et est basé sur le taux de transmission ou le type de flux [60].Toutefois, l’application peut marquer ses paquets afin de leur permettre de profiter desmeilleures valeurs offertes par le PHB AF pour le délai, la gigue et/ou la perte. C’estce qu’on appelle le «Diffserv-aware» streaming. Le Diffserv-aware streaming se com-pose de marquage des différents éléments de la vidéo en fonction de leur importancerelative. Ainsi, des codecs comme MPEG-2 ou MPEG-4 définissent une hiérarchiede trois catégories de trames, classés par l’importance de leur effet sur la qualité vi-suelle : I (référence), P et B. Une méthode peut consister ici àmarquer les trames Iavec la priorité AF la plus élevée, i.e.vert. Les trames P sont marquées avec une prio-rité moyenne, i.e.jauneet les trames B sont marquées avec la priorité la plus bassereprésentée par la couleurrouge. En cas de congestion, les paquets rouges contenantles données moins importantes (trames B) sont supprimés en premier et les paquetsverts contenant les données les plus importantes (trames I)sont les derniers à être sup-primés par les routeurs. Ainsi, en cas de situation de congestion, cette approche devraitoffrir une meilleure qualité visuelle que l’approche BE.

1.3 Réseaux UMTS

Les réseaux UMTS (pour Universal Mobile Telecommunications System) corres-pondent à la 3ème génération des réseaux mobiles. L’architecture simplifiée de UMTS[61] est constituée par le «core network» et le «UMTS Terrestrial Radio Access Net-work» ou UTRAN. L’UTRAN est composé des contrôleurs de réseau radio (RNC). UnRNC contrôle plusieurs stations de base (BS, ou Node B) et est responsable du contrôledes ressources radios dans son domaine. Un utilisateur mobile présent dans l’UTRANpeut lire en mode «streaming» des vidéos sur son équipement utilisateur (UE) à partird’un serveur connecté à l’Internet. L’UTRAN est connecté à d’autres réseaux tels quel’Internet au travers du «core network». Dans un réseau UMTS, tous les liens dansle «core network» sont généralement très bien pourvus en bande passante. L’excèsd’approvisionnement du «core network» mais les fluctuations de la qualité dues auxconditions radio, fait que l’UTRAN est un goulot d’étranglement.

Les utilisateurs ont une vue de bout en bout de la qualité de service. Le réseauUMTS considère donc la QoS telle que vue par les utilisateursdans un contexte debout en bout. La QoS de bout en bout utilise des services appelés «Bearer Services».Chaque «Bearer» offre ses services à la couche supérieure et utilise les fonctionnalitésdes couches inférieures. UMTS définit quatre classes de QoS [13]. Le trafic reçoit letraitement à l’intérieur du réseau UMTS en fonction de sa classe. Les quatre classes de

La compression d’en-tête d’IP pour les flux multimédias 11

qualité de service sont les suivantes :• «Conversational class» : Le trafic correspondant à des applications telles que

les applications transmettant des données de personne à personne (exemple :conversation téléphonique) ou correspondant à de la vidéo “Appel vocal” est dansla classe appelée Conversational class.

• «Streaming class» : La Vidéo à la demande (VoD) relève de cette catégorie. Lesexigences en terme de délai sont présentes mais ne sont pas aussi strictes quedans la classe «Conversational class».

• «Interactive class» : Les trafics interactifs comme les parcours Web sont danscette catégorie.

• «Background class» : Cette classe est la moins sensible au délai. Elle comprendles trafics tels que e-mail et SMS.

Après la première version “Release’99”, les normes 3G ont continué à évoluer.Dans la version 5, le groupe qui produit les normes 3G, a commencé la spécificationde High Speed Packet Access (HSPA), en spécifiant High Speed Downlink PacketAccess (HSDPA), qui prend en charge des vitesses de l’ordre de 10 Mbps et est décritdans la section suivante. La spécification pour la liaison montante, High Speed UplinkPacket Access (HSUPA), a été réalisée dans la version 6.

Une autre évolution, appelée Long Term Evolution (LTE) [63,15], doit se termi-ner en 2007-2008. La technologie radio LTE utilisera un multiplexage appelé OFDM(Orthogonal Frequency Division Multiplexing) et le Multiple Input Multiple Output(MIMO). Les débits devraient atteindre 100 Mbit/s pour la liaison descendante Down-link et 50 Mbit/s pour la liaison ascendante Uplink.

1.4 La compression d’en-tête d’IP pour les flux multi-médias

UMTS va fournir de nombreux services basés sur IP. Toutefois, l’utilisation de IP aun coût important et nécessite une importante bande passante, qui est difficile à obtenirsur les liens cellulaires. Par conséquent, il est nécessaire de compresser les en-têtes etd’économiser les ressources radio. Dans une architecture UMTS, une couche (appeléePDCP pour «Packet Data Convergence Protocol»), dédiée à la compression d’en-tête,a été introduite. La compression d’en-tête est une méthode qui supprime les informa-tions redondantes (idéalement toutes) dans les en-têtes depaquets. Les mécanismestraditionnels pour la compression d’en-tête ne fonctionnent pas bien sur les liens cellu-laires en raison d’un taux d’erreurs BER (Bit Error Rate) élevé,d’environ 10−2 à 10−3,et d’un RTT (Round Trip Times), autour de 200ms. Dans ce scénario, une solution va-lable est le protocole de compression ROHC (pour Robust Header Compression), quia été proposé par l’IETF (Internet Engineering Task Force).


1.4.1 Configuration de ROHC

ROHC définit trois modes de fonctionnement :• Unidirectional Mode (U-Mode) en l’absence de l’utilisation de retour d’informa-

tion des feedback• Optimistic Mode (O-mode), qui utilise uniquement le feedback négative et• Reliable Mode (R-mode) utilise beacoup de feedback.La compression des en-têtes est faite en enlevant des informations redondantes,

tels que le champ numéro de séquence et d’autres champs qui nechangent pas aucours de flux. Il y a trois niveaux de compression. L’objectifest de communiquer lesinformations qui ne changent pas dans les deux premiers niveaux de compression,Initialisation and Refresh (IR), First Order (FO), et ensuitede rester dans le troisièmeniveau de compression, appelée Second Order (SO), pour transmettre les informationsminimales.

La performance de ROHC varie dépend de l’état du réseau qui est très variabledans un environnement radio. Dans ROHC, il ya plusieurs paramètres qui déterminentle compromis entre l’efficacité de la compression et la robustesse. Ce compromis peutêtre exploitée pour optimiser le comportement de ROHC et nous concevons une négo-ciation dynamique pour ROHC qui fait les mises à jour des paramètres ROHC, chaquefois qu’il ya eu un changement significatif dans l’état du réseau.

Par exemple, lorsque le taux d’erreur est élevé dans le réseau, les paramètres deROHC sont adaptés pour le rendre plus robuste vis-à-vis des pertes. Dans le cas où ily a un taux d’erreur faible, les paramètres sont adaptés de façon à augmenter l’effica-cité de la compression. Prenons un paramètre ROHC, appelé L, qui est utilisée dansles modes U et O-mode. L’outil de compression de ROHC utilisele paramètre L ap-pelée “variable de confiance”, afin d’assurer la bonne transmission de l’informationd’en-tête. Cela signifie que dans chaque niveau de compression le même format d’en-tête est envoyé au moins L fois dans les premiers niveaux de compression (IR et FO)avant de passer au niveau SO de compression. Même si un seul paquet est reçu par ledécodeur, les informations ont été communiquées. Pour un faible BER, l’outil de com-pression peut utiliser une faible valeur de L pour permettreune efficacité maximale dela compression sans compromis sur la robustesse.

Quand le taux de bits erronés BER est élevé, le compresseur doit fonctionner avecun objectif de grande robustesse et ceci spécialement dans le U-mode, sinon une longuesuccession de pertes peut se produire. En O-mode, le décompresseur peut envoyer unaccusé de réception négatif (NACK) si une erreur est détectée. Ce NACK baisseraautomatiquement le niveau de compression. Un simple algorithme peut être utilisépour que la valeur de L s’adapte dynamiquement en fonction deBER. La Figure 1.1donne des exemples, L variable, de la perte de ROHC en fonction du BER. Ainsi, laperte ROHC, comme on peut le voir sur la figure, est moins importants quand la valeurde L est variable. Mais toutefois, il est souhaitable de maintenir la valeur de L aussi


FIG. 1.1 – Perte ROHC avec différentes valeurs de L et BER.

faible que possible parce que l’envoi de gros en-têtes L foispeut diminuer l’efficacitéde la compression si L est grand.

1.4.2 Protocoles UDP lite et ROHC

L’utilisation de ROHC dans les liens radios permet de gagnerde la bande passanteet réduit la perte de paquets en diminuant la probabilité de corruption d’en-tête IP.Néanmoins, les paquets peuvent toujours être supprimés si des erreurs se produisentdans le champ données. Pour contrer ce problème, les applications peuvent utiliser decodeurs correcteurs d’erreur et peuvent utiliser le protocole UDP-Lite qui permet auxapplications de recevoir de recevoir des données partiellement endommagées plutôtque de perdre tout le paquet. Les applications multimédias vont bénéficier de l’utilisa-tion des protocoles ROHC et UDP-Lite. Les deux mécanismes réduisent le nombre depaquets perdus et améliorent la qualité des flux multimédia.Dans cette section, nousétudions la combinaison de l’utilisation du protocole UDP-Lite avec de la compressionROHC.

Pour vérifier les performances de ROHC et le nombre de paquetsrejetés dans lacouche d’application en utilisant le protocole UDP-Lite. Nous avons proposé quatrestratégies de contrôle de la couverture de checksum : cf. Table 1.1. Ces stratégies sonttestées à l’aide de deux serveurs vidéo : VLC et Darwin. Notons que ces deux serveurs


TAB . 1.1 – La stratégie par rapport au checksum.

Stratégie 1 Stratégie 2 Stratégie 3 Stratégie 4UDP 100% UDP-Lite 50% UDP-Lite 25% UDP-Lite 0%

Partie cou-verte par lechecksum

L’en-tête(IP/UDP/RTP/l’en-têtede données) +données

L’en-tête(IP/UDP-Lite/RTP/l’en-têtede données) +partie des don-nées

L’en-tête(IP/UDP-Lite/RTP/l’en-têtede données)

L’en-tête(IP/UDP-Lite)

L’en-tête estcorrompu

Perte de paquetspar ROHC




Les donnéesont corrompu

Perte de paquetsdue à UDP

Perte de paquetsdue à UDP

Envoyé au ap-plication

Envoyé au ap-plication

codent la vidéo dans des trames de tailles différentes1.

Les différentes stratégies changent la façon dont les erreurs affectent les paquets.Lorsqu’une erreur se produit dans les données, le paquet estenvoyé à la couche appli-cation. Dans ce cas, la décision de savoir si le paquet est utile est prise par l’application.Si l’erreur se produit dans les données couvertes par le checksum, le paquet est sup-primé. Dans une autre situation, si l’erreur se produit dansl’en-tête et ROHC ne peutpas la corriger, le paquet est supprimé par ROHC.

Nous avons réalisé des essais avec des flux IPv6/UDP/RTP et IPv6/UDP-Lite/RTPavec différents niveaux d’erreurs sur le lien pour comparerles quatre stratégies et com-parer chacune d’elles par rapport à UDP. Par ailleurs, il faut noter que nous utilisonsun profil qui ne compresse que les en-têtes IPv6/UDP et IPv6/UDP-Lite, mais pas lesen-têtes RTP.

La Figure 1.2 montre les pertes en U-mode et O-mode pour les quatre stratégies.Il faut noter que la perte de paquets diminue chaque fois que le checksum est réduit.L’amélioration en terme de perte de paquets est plus évidente lorsque l’erreur dans lelien est plus élevée parce que la perte passe d’un taux de prèsde 100 % à un tauxd’environ 20 %.

1C’est à cause de leurs implémentations.


0

20

40

60

80

100

0 0.00001 0.0001 0.0005 0.001 0.003 0.005

Loss

(%

)

BER

UDP (CRC 100%)CRC 50%CRC 25%CRC 0%

(a) U mode

0

20

40

60

80

100

0 0.00001 0.0001 0.0005 0.001 0.003 0.005

Loss

(%

)

BER


(b) O mode

FIG. 1.2 – Perte au niveau application dans le mode unidirectionnel et optimiste pourles quatre stratégies.


1.5 Video-Streaming au-dessus de High Speed Down-link Packet Access (HSDPA)

HSDPA (pour High Speed Downlink Packet Access) [62, 6, 7, 105] permet uneamélioration des réseaux UMTS. HSDPA supporte des débits deplusieurs Mbps ce quiconvient pour des applications multimédias. HSDPA apportede nombreuses amélio-rations par rapport aux anciennes versions de l’UMTS. En HSDPA, une surveillancerapide de la condition radio de tous les utilisateurs est réalisée : toutes les 2 ms, unéquipement utilisateur (UE) peut envoyer un «Channel Quality Indicator» (CQI), à lastation de base (BS), sur un canal de contrôle. L’indicateur CQI permet d’adapter letaux de codage, la modulation et le nombre de codes employés,afin que les utilisateursayant de bonnes conditions radio puissent être fournis avecun débit très important. Lamanipulation de donnée erronées a été améliorée en HSDPA. EnHSDPA, la coucheMAC elle-même peut rapidement retransmettre les données erronées. Le délai de re-transmission est réduit grâce au déplacement de la décisionde renvoi d’une trame dansle BS. Cela permet également un temps de réponse plus rapide. L’UE à son tour, nesupprime pas les trames erronées, mais les combine avec l’aide des trames retrans-mises. Chaque Intervalle de temps de transmission (TTI) est d’une durée de 2 ms.L’ordonnanceur choisit le prochain utilisateur en fonction des conditions radio de tousles utilisateurs, et aussi en fonction des différentes exigences de QoS. Cette méthodeadaptative peut être utilisée, par exemple, pour maximiserle débit global cellulaire enordonnançant des utilisateurs uniquement lorsque les conditions radio sont favorables.

Nous avons étudié le problème de la vidéo, codée par H.264, ettransmise surHSDPA. Notre but est d’évaluer l’impact de plusieurs approches d’ordonnancementsur la qualité visuelle. Nous avons utilisé les techniques de perception subjective (PSQA,Pseudo Subjective Quality Assessment) pour évaluer les performances de ces poli-tiques dans la transmission de vidéo. Les résultats montrent que l’ordonnanceur peutadmettre plus d’utilisateurs sans altérer la QoS. En termesde nombre d’utilisateurspouvant être admis dans le système, nos résultats montrent les gains réalisés par l’or-donnancement, prenant compte de la QoS, avec la même qualitésubjective pour lesutilisateurs vidéo. D’ailleurs, la capacité restante est bien répartie parmi les utilisateursde Best Effort. Néanmoins, nous avons constaté que la performance de cet ordonnan-cement se détériore quand la charge augmente dans le Best Effort.

De plus, nous avons étudié le rôle de l’ordonnancement dans le partage des res-sources entre les différentes classes de QoS. Nous avons également proposé une nou-velle politique d’ordonnancement appelé «Normalised Rate Guarantee» (cf. sectionsuivant) qui améliore les politiques d’ordonnancement existantes en ne détériorant pasla QoS lorsque la charge augmente dans le Best Effort. Nous discutons de cette poli-tique «Normalised Rate Guarantee» dans la section suivante.

Video-Streaming au-dessus de High Speed Downlink Packet Access (HSDPA) 17

1.5.1 L’ordonnanceur Normalized Rate Guarantee

L’ordonnanceur HSDPA est la clé de la gestion des ressourcesdans le lien des-cendant de l’UTRAN, car il contrôle l’accès au canal radio. Pour cette étude, nousconsidérons (voir [126]) les ordinnanceurs RR (Round-Robin),CI (Max C / I), PF(Proportionnellement Fair) et une politique d’ordonnancement prenant compte de laQoS.

Pour les ordonnanceurs QoS, il a été montré dans [64] que, en tenant compte del’utilité des utilisateursUi(λi), il est possible d’obtenir une bonne politique d’ordon-nancement QoS. L’utilisateur choisirai∗ tel que :

i∗ = argmaxi{Ri(t) ·U

′i (λi(t))} (1.1)

Ri(t) est le débit instantané etλi(t) est le taux moyen reçu par l’utilisateuri à un tempst. Cet ordonnanceur est tel qu’on choisit l’utilisateuri∗ lorsquei∗= argmaxi{Bi(t) ·Ri(t)/λi(t)}etBi(t) est appelé «Barrier function».

L’ordonnanceur Rate-Guarantee (RG) a ainsi été conçu par Hosein dans [64] enutilisant l’équation 1.1. Une fonction d’utilité

UQ (λ) = log(λ)+1−exp(−β · (λ−λmin)) (1.2)

a été supposée pour la qualité de service des utilisateurs (avecβ > 0), soit un Ordon-nanceur avec le «Barrier function»

Bi(t) =

{

1+λi(t) ·β ·exp(−β · (λi(t)−λ(i)min)) ∀i ∈ Q ,

1 ∀i ∈ B ,(1.3)

qui correspond au cas où un débit minimalλ(i)min est exigé par la QoS utilisateuri ; Q

etB désignent respectivement les utilisateurs de la qualité deservice et de Best Effort,respectivement. Dans [93], une autre variante de RG est utilisé avec la modificationsuivante pour la qualité de service aux utilisateurs :

Bi(t) = 1+αexp(−β · (λi(t)−λ(i)min)) ∀i ∈ Q ; (1.4)

où α est une constante, indépendante deλi(t) et λ(i)min. L’ordonnanceur donné par (1.4)

est aussi utilisé comme une référence dans [82].Maintenant, pour tout utilisateuri ∈ Q , nous indiquons par∆λi(t) la différence

instantanée au tempst entre le taux moyen deλi(t) en son taux minimum garanti

λ(i)min, soit ∆λi(t) = λi(t)− λ(i)

min. Le but de la «Barrier function» (1.3)-(1.4) est alorsd’accroître le probabilité d’ordonnancement d’utilisateur i lorsque∆λi(t) < 0.

RG [64] et sa variante [93] souffrent de la détérioration des garanties de la qualitéde service aux utilisateurs quand le nombre d’utilisateursBE actifnBE = |B | augmente.


C’est parce que, commenBE augmente, la valeur deλi pour les utilisateurs BE dimi-nue. Cela augmente alors la duréeBi(t)/λi . En outre, les ordonnanceurs ci-dessus, enparticulier celui décrit par (1.4), ont tendance à être biaisé vers certains utilisateurs enfonction de leur valeur de garantie.

Nous proposons un nouvel ordonnanceur appelé «Normalised Rate Guarantee»(NRG), qui est basé sur RG. La justification de l’ordonnanceur NRG est que nousvoulons répartir le taux de perte d’une façon plus équitableau cours des congestionsquel que soit le taux de garantie. Nous voulons aussi que l’augmentation de la chargedu trafic BE ne dégrade pas la QoS. De plus, l’augmentation de lacharge BE doit êtrepartagée uniquement entre les utilisateurs BE.

Nous supposons l’utilité suivante pour la qualité de service aux utilisateurs :

UQ (λ) = λmin ·(

log(λ)+1−exp

(

−βλ−λmin

λmin

))

. (1.5)

Pour les utilisateurs BE, nous considérons que les garantiessont toujours satisfaites sil’on suppose un utilitaire pour les utilisateurs BE de la forme :

UB (λ) =kBE

nBElog(λ). (1.6)

Une constantekBE permettra de déterminer la proportion des ressources allouées auxutilisateurs BE ; en utilisant le termenBE, si le nombre d’utilisateurs BE augmente,alors la charge sur les ressources pour la QoS.

En utilisant Eq (1.5)-(1.6) et l’équation (1.1), on obtientun ordonnanceur avec la «Barrier Function» :

Bi(t) =

{

λ(i)min +λi(t)βe−β(λi(t)−λ(i)

min)/λ(i)min ∀i ∈ Q ,

kBE/nBE ∀i ∈ B .(1.7)

Pour évaluer les ordonnanceurs, nous utilisons des traces des vidéo, encodés parH.264, de la séquence de référence appelé “mother and daughter” avec un débit≈360kbps. Nous utilisons la méthode de traces [104] et simulons HSDPA avec EUR-ANE [1], qui est une extension d’un simulateur appelé NS-2 [95]. Pour évaluer laqualité de la vidéo, on utilise une nouvelle technologie appelée «Pseudo SubjectiveQuality Evaluation» (PSQA) [102, 119]. PSQA fournit une évaluation subjective de laqualité d’un flux vidéo sur un réseau de paquets, telle que perçue par l’utilisateur final.La note PSQA varie de 0 à 5 et la note 5 représente la meilleure qualité. L’outil est basésur des techniques «Random Neural Networks» (RNN), pour saisir la façon dont leshumains perçoivent la qualité de la vidéo. L’outil PSQA est d’abord entrainé avec deshumains et, plus tard, il est utilisé pour prédire les notes PSQA. La partie formation estcoûteuse et prend du temps, mais l’évaluation est très rapide et automatique.

Video-Streaming au-dessus de High Speed Downlink Packet Access (HSDPA) 19

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

0 5 10 15 20 25

Qm

in (

PS

QA

sco

re)

Number of TCP flows

NRGRGCIPFRR

FIG. 1.3 –Qmin en fonction du nombre d’utilisateurs TCP.

0.9

1.1

1.3

1.5

1.7

0 5 10 15 20 25 30 35 40

TC

P T

hrou

ghpu

t (M

bps)

Number of TCP flows

NRGRG

FIG. 1.4 – Débit agrégé du trafic Best Effort en fonction du nombrenBE d’utilisateursTCP.


0

1

2

3

4

5

6

32 64 128 256 384 512

loss

(%

)

Users with Rate Guarantees (kbps)

NRGNRG Hosein

NRG Lundevall

FIG. 1.5 – Taux de perte pour des utilisateurs ayant des garanties de débit différentes.

Maintenant, nous indiquons parQmin la valeur telle que les 95 % de la populationreçoivent un note PSQAQ≥Qmin. Qmin est un bon paramètre d’évaluation parce que,comme dans tout système, il est souhaitable qu’un minimum dequalité soit reçu parle plus grand nombre d’utilisateurs possible. Ainsi, nous utilisons ce paramètre au lieude la note PSQA moyenne. Figure 1.3 compare la qualité de la vidéo avec différentsordonnanceurs. Il y a 4 utilisateurs vidéo et le nombre d’utilisateurs BE (TCP) est aug-menté pour augmenter la charge. On peut constater que la qualité ne se détériore pasavec NRG contrairement à RG. En outre, d’autres ordonnanceursne prévoient pas debonne qualité de vidéo en comparaison avec les deux ordonnanceurs QoS. Cette amé-lioration s’explique par le fait que NRG et RG ne peuvent éviterd’accorder davantagede ressources aux utilisateurs TCP quand leur nombre augmente (voir figure 1.4).

Afin de tester l’équité entre les différents taux des garanties, nous avons utilisé desflux CBR (i.e. sans les traces réelles) des taux différents. Afinde permettre une compa-raison équitable, nous normalisons l’utilité pour les utilisateurs BE, donnée par (1.6),pour les ordonnanceurs (1.3), et nous l’appelons NRG Hosein.La variante donnée par(1.4), nous l’appelons NRG Lundevall. Nous n’avons pas normalisé l’utilité pour lesutilisateurs de QoS. Fig. 1.5 montre le taux de perte pour lesdifférents utilisateurs. Onpeut voir qu’il y a une grande amélioration de NRG par rapport àNRG-Lundevall etune légère de NRG par rapport à NRG-Hosein en terme d’équité en taux de pertes.

Contrôle de congestion pour les flux vidéo 21

1.6 Contrôle de congestion pour les flux vidéo

Les applications multimédia doivent assurer le contrôle decongestion pour adapterle taux de transmission à la bande passante disponible. Ainsi, la congestion et l’effon-drement de réseaux sont évités. Dans les réseaux cellulaires, la bande passante dispo-nible peut changer rapidement en raison de la variabilité dela ressource radio.

Aujourd’hui la stabilité de l’Internet est due à TCP [133, 3, 4, 70]. TCP adapte sontaux de transmission à la bande passante disponible. En général, TCP est un protocolede transport très efficace pour le transfert de données. Toutefois, dans [52] les auteursont montré que TCP est inadapté pour les applications vidéo puisqu’il ne respectepas les exigences strictes de la vidéo en termes de délai et degigue. En outre, lesretransmissions TCP sont inutiles pour la plupart des données vidéo. En effet, certainesretransmissions peuvent dépasser le temps limite d’arrivée et ainsi elles deviennentobsolètes. Par conséquent de nombreuses recherches ont étémenées visant à trouverdes solutions.

1.6.1 TFRC sur HSDPA

TCP Friendly Rate Control (TFRC) [53, 59] est un protocole de contrôle de conges-tion de bout en bout pour les applications multimédia. TFRC a été conçu pour offrir untaux de transmission plus stable que TCP et adapté aux applications multimédia. TFRCse base sur l’équation (1.8) pour maintenir un taux d’envoi relativement stable tout enétant sensible aux encombrements. Un TFRC expéditeur ajustele taux de transmissionen fonction de la fréquence«loss events». La fréquence «loss event» mesure le nombremoyen de paquets perdus dans un seul «Round Trip time» (RTT).

Afin d’être compatible avec les flux TCP, TFRC calcule le taux de retransmissiondes utilisateurs en suivant «TCP response function» [53] quimodélise le comportementd’un flux TCP :

T =s

R√

2p/3+ tRTO(3√

3p/8) p(1+32p2)(1.8)

où le taux de transmissionT, en octets par seconde, est modélisée en fonction de lataille des paquetss, de (RTT)R, de la fréquence des «loss events»p, et de la valeur de«retransmission timeout»tRTO de TCP.

Nous avons effectué des simulations de TFRC sur HSDPA en utilisant la plate-forme EURANE [1]. Les résultats obtenus sont surprenants. Eneffet, dans le contextede HSDPA, la stabilité du taux de transmission de TFRC n’est pas nécessairementmeilleure que celle de TCP. Ce résultat n’est pas conforme à ce qui est habituellementobtenu pour les réseaux filaires. Ce comportement peut être expliqué par le fait quedans HSDPA, la bande passante est variable à cause des conditions radio. Cela signifieégalement que TFRC a un taux de transmission globalement inférieure, par rapport à


100

300

500

50 60 70 80 90 100 110

Thr

ough

put (

kbps

)

time (s)

TFRC RGTFRC PF

TCP PF

FIG. 1.6 – Amélioration de la stabilité des débits de TFRC avec l’ordonnanceur RG.Echelle temporelle = 1 s, distance entre l’UE et la BS = 300 m, etdébit garanti = 200kbps.

TCP, à cause de son adaptabilité plus lente que TCP. De plus, nous avons montré quel’utilisation d’un ordonnancement approprié, prenant en compte la QoS, peut consi-dérablement améliorer les performances de TCP et de TFRC. Figure 1.6 montre unexemple comparant la stabilité des taux de transmission de TFRC et de TCP. Danscette figure, les fluctuations de la bande passante peuvent être contrôlées à l’aide d’unordonnanceur de QoS (l’ordonnancement RG pour le cas présenté dans la figure), etcela peut bénéficier aux deux mécanismes TCP et TFRC.

1.6.2 Estimation de perte sans fil et retransmission sélectives

Les protocoles de contrôle de congestion ne suffisent pas pour assurer une bonnequalité des applications multimédia et une utilisation efficace du réseau. Les pertesde paquets, dues à des taux d’erreurs élevés dans les réseauxsans fil, dégradent nonseulement la qualité des applications multimédia mais aussi rendent les algorithmesde contrôle de congestion inefficaces. En effet, l’incapacité de distinguer des pertesdues à la nature même des réseaux sans fil de celles dues à la congestion entraîne unediminution inutile du taux de transmission.

Dans cette section, nous étudions le cas de diffusion multimédia préenregistrées surdes réseaux sans fil. Nous intégrons des protocoles de contrôle de congestion ayant unsystème de retransmission sélective afin de retransmettre certains paquets multimédiaperdus. En outre, nous avons intégré un système d’estimation de perte sans fil pouraméliorer l’efficacité du protocole de contrôle de congestion.

1.6.2.1 Un schéma d’estimation de perte sans fil

Nous proposons un mécanisme dénommé «Wireless Loss Estimation for Diffserv»(WLED). WLED est un mécanisme d’estimation de perte sans fil ayant pour but d’ai-


der les protocoles de contrôle de congestion dans les réseaux DiffServ utilisant AF(voir la section 1.2.3). Il est conçu pour les applications «DiffServ-aware» utilisant despriorités différentes [104] dans le même flux en envoyant toujours les paquets verts. Ils’applique également sur les réseaux sans fil comme l’UMTS qui supportent la QoS.

L’algorithme WLED fonctionne de la manière suivante. On estime le taux de pertesans fil lors d’une congestion moyenne (pas trop importante), en se basant sur le tauxde perte de paquets (vert). Ces derniers ne seront pas supprimés en raison d’une lé-gère congestion dans les réseaux DiffServ. WLED exploite la protection inhérente despaquets les plus prioritaires avec l’algorithme RIO, utilisé par DiffServ. Cela signifieque, si le taux de perte de paquets de moindre priorité n’est pas significatif, alors onpeut présumer que la perte de paquets de haute priorité est fortement corrélée avec letaux de perte sans fil.

Du côté de l’expéditeur, WLED maintient un numéro de séquenceNj pour lespaquets marqués d’une couleurj ∈ {vert, jaune, rouge}, ainsi qu’un numéro d’ordrecommunN pour tous les paquets envoyés. Ces numéros d’ordre sont envoyés danstous les paquets. Ceci est essentiel pour le destinataire pour être en mesure de calculerde taux de perte par priorité (par couleur)l j . Du côté du destinataire, WLED estimele taux de perte, tous les RTT, et les envoie à l’expéditeur, qui utilise les informationspour ajuster son taux de transmission. On calcule la valeur du taux de perte sans filwen utilisant le taux de pertelvert des paquetsverts. Lorsque le taux de perte des paquetsde priorité inférieure (jaune) est inférieur à un seuil 0< θ ≤ 1, alors WLED prendw = lvert. Si le taux de perte des paquets de priorité inférieure dépasse le seuil, alorsWLED contribue à la réduction de l’envoi en prenantw = 0.

Afin d’intégrer WLED à un protocole de contrôle de congestion,nous voulons unmodèle TCP qui modélise le comportementidéal de TCP dans les scénarios sans-fil,en réduisant le taux de transmission seulement si les pertessont dues à la congestionet non à des phénomènes sans fil. À notre connaissance, ARC [18]est le premier tra-vail qui modélise le comportement idéal de TCP face à des pertes sans fil. Il utilisel’équation suivante :

S=1

4RTT

(

3+

√

25+24pc

)

, (1.9)

où Sest le taux de transmission en paquets par seconde,RTT est «Round Trip Time»,et pc est la probabilité de perte due à la congestion. Ce dernier peut être calculé enfonction de la probabilité de perte totalπ et probabilité des pertes due à réseau sans filw grâce à l’expression :

pc =

(

π−w1−w

)

. (1.10)

ARC a besoin d’une méthode pour calculerπ et w pour calculerpc. Notons que lavaleur deπ est facilement estimée à partir du nombre total des paquets reçus et lenombre total des paquets perdus après avoir observé la séquence des paquets. Puisque


0

10

20

30

40

50

60

70

80

90

100

0 0.05 0.1 0.15 0.2

% L

ink

Util

izat

ion

Wireless Loss Probability

WLED-ARCTFRC

TCP NewReno

FIG. 1.7 – Utilisation de la liaison sans fil pour différentes valeurs de probabilité deperte.

le calcul dew est délicat, ARC s’appuie sur les couches inférieures pour obtenir w.Toutefois, cette approche viole le paradigme du bout en boutet ne fonctionnera pas s’iln’y a pas d’aide des couches inférieures. Ainsi, nous proposons WLED pour estimerles valeurs dew et pc pour ARC.

Nous avons étudié notre mécanisme en utilisant la topologie«dumbbell». Tous lesessais ont été effectués avec le simulateur NS-2 [95] sans laplateforme HSDPA. Letemps simulé est de 120 secondes. Tous les liens ont la même bande passante égale à6 Mbps. La valeur de RTT (sans compter le délai due à la file d’attente) est de 240 ms.La topologie représente un réseau avec les derniers liens d’une connexion sans fil oùla congestion peut se produire. Les liens sans fils sont présents à la fin du lien «bot-tleneck» pour introduire principalement les pertes de paquets sans fil. Cela se fait aumoyen d’un simple modèle de pertes des paquets qui élimine les paquets de façon aléa-toire, avec la distribution de Bernoulli. Nous avons utiliséle protocole RIO pour mettreen place le PHB AF dans nos simulations. Les paramètres RIO utilisés sont qualitative-ment proches des valeurs utilisées dans [94, 40, 103, 91]. Enoutre, nous avons choisile modèle «staggered» pour RIO qui est recommandé dans [94].

L’un des objectifs de WLED est d’améliorer l’utilisation desliens sans fil, malgréles pertes, tout en maintenant les mêmes paramètres de performance ou en les amé-liorant. Fig. 1.7 montre l’utilisation des liens pour différentes valeurs de la probabilitéde perte sans filw. Nous avons mesuré le taux d’utilisation des liens avec WLED-ARC avec différentes valeurs dew. Nous avons fixé le nombre d’utilisateursM à 20.À des fins de comparaison, nous avons également mesuré la performance de TFRC etTCP NewReno dans les mêmes conditions pour des différentes valeurs de probabilité


de la perte sans fil. On peut constater que l’utilisation des liens avec WLED-ARC esttoujours> 90%, même quandw est aussi élevé que 0,2, mais l’utilisation se dégradefortement avec TFRC et TCP pour les valeurs relativement faible dew. La performancede WLED avec ARC est meilleure que TFRC et TCP NewReno puisque les deux der-niers ne peuvent pas distinguer les pertes dues à de la congestion de celles dues auxconditions radio. En outre, les performances en termes de stabilité des taux de trans-mission et de la conformité avec les flux TCP «TCP-friendliness» était similaire à cellede TFRC.

1.6.2.2 Les retransmissions sélectives

Pour résoudre le problème de dégradation de la qualité vidéoen raison de la pertedes paquets, nous proposons d’utiliser les retransmissions sélectives pour récupérer lesdonnées multimédia perdues à cause des pertes sans fil. Nous avons également intégréle mécanisme d’estimation de perte sans fil à un protocole de contrôle de congestion.Nous étudions des combinaisons de certaines stratégies de retransmission, telles que :la retransmission prioritaire des données les plus importantes, la retransmission uni-quement des données ayant une chance d’être reçues avant sonéchéance, et la désacti-vation de la retransmission pendant les périodes de congestion.

Pour cette partie de nos simulations, nous utilisons Datagram Congestion ControlProtocol (DCCP) [80]. DCCP fournit les éléments nécessaires comme les numéros deséquence et des dispositifs comme les vecteurs de Feedback/ACK [80] qui sont utilespour la détection des pertes. Notre implémentation du mécanisme WLED-ARC avecDCCP constitue une amélioration par rapport à celle décrite dans la section 1.6.2.1.Il n’est pas nécessaire d’utiliser des numéros de séquence différents pour détecter lespertes pour les couleurs différentes de DiffServ car nous gérons toute l’histoire despaquets DCCP en utilisant les vecteurs Feedback/ACK.

Le mécanisme de retransmission sélective désactive ou active la retransmission depaquets perdus en fonction de l’état du réseau. En général, la retransmission de tousles paquets devrait être désactivée lorsque le réseau est encombré. L’algorithme decontrôle de congestion calcule le taux de transmission qui est indépendant du débitdes flux vidéo. Quand le réseau est encombré, ou presque encombré, le taux de trans-mission calculé est généralement beaucoup plus faible que le débit vidéo. Dans cettesituation, la retransmission devrait être désactivée.

Afin de permettre la retransmission ou l’empêcher, la surcharge due à la retransmis-sion doit être estimée. Pour déterminer les seuils pour la retransmission des différentstypes de trames, certains résultats statistiques ont été utilisés [83, 42]. Habituellement,les valeurs statistiques de la vidéo peuvent également êtrepré-calculées dans le casde la vidéo préenregistrée. Dans le cas contraire, les valeurs généralement acceptablesdoivent être utilisées pour estimer la taille des ratios pour différents types de tramesdans un «Group Of Pictures» (GOP). Nous utilisons les résultats statistiques présen-


tées dans [83] comme valeurs générales.

Afin de calculer la charge supplémentaire pour retransmettre les différents typesde trames, considérons le ratioρI entre la taille de trame I et la taille totale de GOP.De même, les ratios des trames P et B sont respectivementρP et ρB. Avec les résultatsdans [83] et en examinant certains cas avec les combinaisonsdes différents nombresdes trames I, P et B, nous avons trouvé la limite supérieure comme≈ 50%. Ainsi,quand les données statistiques ne sont pas disponibles, nous supposons que la limitesupérieure des trames I, P et B dans un flux de données est 50 %, 50 % et 50 %2. Demême, la charge supplémentaire (λextra) en raison de la retransmission de la trame I estcalculée comme suit :

λ50%extra = ρ50%· rstream·π (1.11)

où rstreamest le débit du flux vidéo, etπ, tel que décrit précédemment, est la probabilitéde la perte des paquets. De la même façon, la charge supplémentaire est utilisée pourtous les types de trames. Une fois que les ratios sont disponibles, la surcharge estcalculée pour I, P ou la totalité des trames comme suit :

λIextra = ρI · rstream·π (1.12)

λI+Pextra = (ρI +ρP) · rstream·π (1.13)

λallextra = (ρall ) · rstream·π (1.14)

Nous utilisons un processus qui permet d’activer ou de désactiver la retransmissiondes différents types de trames, en fonction de la charge supplémentaire et le taux detransmission calculé par le protocole de contrôle de congestion (CC-taux). La retrans-mission doit être désactivée lorsqueS≤ rv, où S correspond au taux de transmissiondéterminé par le protocole de contrôle de la congestion etrv est le débit (d’encodage)de la vidéo. Puisque les trames I sont plus prioritaires, elles doivent être retransmisesen priorité. Les règles de retransmission de I, I + P et toutesles trames sont indiquéesdans le tableau 1.2.

2Notons que nous prenons la limite supérieure et, par conséquent, la somme des pourcentages nepeut pas être égale à 100 %.


TAB . 1.2 – Retransmissions en fonction du type de trames

Ratio par défaut Ratios réels(ρ50%=0.5) (ρI , ρP, ρB)

Trames I rv < S< rv +λ50%extra rv < S< rv +λI

extra

Trames I + P rv +λextra < S< rv +2λ50%extra rv < S< rv +λI+P

extra

Tous les trames S> rv +2λ50%extra rv < S< rv +λall

extra

Pour l’évaluation des performances, certains scénarios sont exécutés dans le simu-lateur NS-2 [95]. Nous utilisons la topologie «dumbbell» avec des liens de 1 Mbps. Lelien “sans fil” est le lien «bottleneck», dans le but d’introduire les pertes de paquetssans fil, à l’aide d’un simple modèle aléatoire.

Tout d’abord, nous examinons les différents protocoles de contrôle de congestionavec notre mécanisme. Le délai dans le réseau est 40ms. Nous utilisons RIO pour lagestion de la file DiffServ comme dans la section 1.6.2.1. Le PSNR (Peak Signal toNoise Ratio) est utilisé pour évaluer la qualité de vidéo codépar H.264 avec le débit≈360kbps3.

Comme le montre la Figure 1.8, le WLED et ARC sont nettement mieuxque TFRCet TFRC sans les retransmissions. En outre, une améliorationlégère peut être obser-vée lors de l’utilisation de la différenciation des trames pour la retransmission. Avecces méthodes, plus de paquets perdus peuvent être retransmis avec succès. Comme lemontre4 la figure, la qualité vidéo (PSNR) est nettement plus élevée avec ARC mêmequandw est élevé. En effet, à la différence de TFRC, ARC ne réduit pas inutilementle taux de transmission quand il y a des pertes sans fil. Avec TFRC, l’application vi-déo non seulement ne retransmet pas les données perdues, mais aussi elle n’est pas enmesure d’envoyer la séquence vidéo complète en raison de la faible valeur du taux detransmission.

L’augmentation du trafic de base n’a aucun effet sur le protocole TFRC lorsque laperte est déjà élevée parce que le taux de transmission calculé est déjà trop faible, enraison du haut taux de perte (10 %), pour permettre la retransmission. Donc, dans le casde TFRC, la retransmission est désactivée. C’est la raison pourlaquelle le protocoleTFRC avec retransmission est très semblable au cas sans la retransmission lorsqu’onfixe la perte sans fil àw = 10%, comme la montre la figure 1.9.

3La vidéo de référence est “mother and daughter”, qui est utilisée dans la section 1.5.4Note que «without retransmission» correspond au cas où l’application vidéo utilise TFRC et il n’y

a pas retransmission.


5

10

15

20

25

30

35

40

0 0.05 0.1 0.15 0.2

PS

NR

(dB

)


WLEDARC

TFRCWithout Retrans.

FIG. 1.8 – PSNR moyen en fonction de la probabilité de perte sans fil w, pour ARC,TFRC, WLED et le cas sans retransmission, dans un réseau DiffServ. Le nombre d’uti-lisateurs web est de 10.

5

10

15

20

25

30

35

5 10 15 20 25 30 35

PS

NR

(dB

)

WWW Users

WLEDARC


FIG. 1.9 – SNR moyen en fonction du nombre d’utilisateurs web, pour ARC, TFRC,WLED et le cas sans retransmission, dans un réseau DiffServ. La probabilité de pertesans fil est dew = 0,1.

Conclusion 29

1.7 Conclusion

Dans cette thèse nous nous sommes intéressés à la diffusion multimédia dans lesréseaux mobiles de troisième génération (3G) en utilisant la technologie par paquetscomme l’Internet Protocol (IP). Les principales contributions sont décrites dans cettesection.

1.7.1 La compression d’en-tête pour les flux Multimédia

Nous avons étudié la compression d’en-tête dans les réseaux3G pouvant être bé-néfique pour certaines applications multimédias telles quela Voix sur IP (VoIP). Nousavons constaté que la performance de ROHC varie avec les paramètres de compres-sion, lorsqu’il est confronté à la simulation d’environnement sans fil avec erreur. Lerésultat important est qu’il existe un compromis entre la robustesse et l’efficacité de lacompression qui pourrait être exploité pour optimiser le comportement de ROHC. Unmécanisme d’optimisation, basé sur le compromis, a été conçu.

En outre, nous avons étudié l’impact d’un protocole récent,appelé UDP-Lite, etROHC sur les applications multimédia. Nous avons étudié certaines stratégies pourcouvrir partiellement la charge utile des données avec les en-têtes de paquets compres-sées par ROHC. Nous avons constaté que la performance globalede ROHC avec UDP-Lite a considérablement augmenté parce que nous étions capables de choisir les infor-mations couvertes par le «checksum» sans affecter les données d’application. Dansl’avenir, nous voudrions analyser le comportement du ROHC sur une pile de radioréelle. Si les coûts ou la complexité s’avère être trop élevés, alors nous envisageronsd’au moins intégrer ROHC dans le simulateur HSDPA utilisé dans les autres parties decette thèse.

1.7.2 Diffusion Vidéo sur HSDPA

Nous avons étudié la fourniture de QoS sur High Speed Downlink Packet Access(HSDPA) qui convient pour les applications multimédia. Nous avons utilisé les poli-tiques d’ordonnancement dans HSDPA pour satisfaire les exigences de qualité de ser-vice pour les utilisateurs vidéo. Nous avons étudié le streaming vidéo codé par H.264sur HSDPA en testant différents ordonnanceurs. De plus, à notre connaissance, cetteétude a le mérite d’être nouvelle, car elle utilise un outil appelé Pseudo SubjectiveQuality Assessment (PSQA) pour évaluer l’impact sur la qualité «subjective» perçuepar les utilisateurs.

D’abord, nous avons proposé un ordonnanceur avec un taux de garantie norma-lisé (NRG), qui est une extension d’un ordonnanceur précédent pour les utilisateurs deQoS. L’ordonnanceur NRG fournit les améliorations suivantes : absence de dégrada-tion de la qualité vidéo en présence d’une augmentation du trafic Best Effort. En outre,


il répartit équitablement le taux de perte pour les utilisateurs.Comme travail futur, nous aimerions étudier le problème du «Call Admission Control»

(CAC) pour le partage des liaisons sans fil telles que HSDPA. Unebonne CAC auraitsurveillé la qualité du canal radio pendant un certain tempsavant de prendre la décisionconcernant l’admission de l’utilisateur. Par ailleurs, certaines fonctionnalités commela renégociation du débit de vidéo pour contrôler la congestion peut être intégrée avecl’algorithme CAC.

1.7.3 Contrôle de congestion pour les flux vidéo

Dans la dernière partie de cette thèse, nous avons étudié lesmécanismes du pro-tocole de contrôle de congestion adaptés aux flux vidéo. Nousavons obtenu certainsrésultats surprenants lorsque nous avons étudié TCP Friendly Rate Control (TFRC) surHSDPA. Nous avons constaté que, dans le contexte de HSDPA, lastabilité des taux deTFRC n’était pas forcément meilleure que celle de TCP. Cela est surprenant car il estopposé à ce qui est habituellement rapporté dans les liens filaires.

Nous avons également proposé deux stratégies de lutte contre les problèmes cau-sés par les pertes sans fil. Premièrement, nous avons conçu une méthode de calcul despertes qui pourraient estimer la probabilité de perte sans fil de bout-en-bout. Deuxiè-mement, nous avons utilisé les retransmissions sélectivespour récupérer les donnéesmultimédia perdues à cause de pertes sans fil. Nos résultats ont montré que le systèmeintégré assure non seulement l’amélioration de la qualité de la vidéo en raison de laretransmission et de la récupération de certaines données vidéo perdues, mais aussi lareprise elle-même a été efficace en raison de la perte d’estimation sans fil.

Dans l’avenir, nous aimerions étudier le problème du contrôle de congestion pourune vidéo encodée par le tout récent codec Scalable Video Codec (SVC). SVC assurel’encodage de la vidéo tout en adaptant le débit de la vidéo avec les changementsprogressifs dans la qualité de la vidéo.

Improving Quality of Service andResource Utilization for Multimedia

Streaming

31

Chapter 2

Introduction

Universal Mobile Telecommunications System (UMTS) [61] isa third-generation (3G),wireless cellular network that uses Wideband Code Division Multiple Access (WCDMA)as its radio interface technology. UMTS offers higher data rates with respect to older2G and 2.5G networks and, with the Release 5 version, is evolving into an all-IP, wire-less network. The increased bandwidth provided by UMTS allows for the deploymentof a wide range of services, like voice, data and multimedia streaming services.

2.1 Evolution to 3G

First generation (1G) wireless cellular mobiles were analog phones, introduced in the1980s. They were replaced by second generation (2G) phones that used digital commu-nication. Global System for Mobile Communications (GSM), originally from Europe,is currently the most popular 2G mobile standard used in the world. GSM and theother 2G systems were originally designed for voice services with good quality andthe first services were available in as early as 1991. Systemslike GSM also supportshort messaging service (SMS). Moreover, operators also offer roaming services andit is possible to use the GSM services available in all over the world. The GSM stan-dard made it possible for the different equipments made by different vendors to beinteroperable and that contributed towards an easy and fastdeployment of GSM.

Global Packet Radio Services (GPRS) is an enhancement to the systems like GSMand is considered as 2.5G. It introduces data services, withdata rates of the order of40kbps, to the 2G systems that originally supported only voice. It supports Internetaccess protocols like Wireless Access Protocol (WAP), an open standard, that allowswireless applications to connect to the Internet.

The data rates for the data services over mobile equipments are further increasedwith Enhanced Data rates for GSM Evolution (EDGE) or Enhanced GPRS (EGPRS).Some high class EDGE devices even fall under the category of the third generation(3G) mobile systems because they satisfy the low end data rate requirements of 3G.

33

34 Introduction

The third generation mobile systems are designed to furtherenhance the communi-cation by providing high data rates of the order of 2 Mbps. The3G mobile systems aimto provide varied services, like multimedia, in addition totraditional services like voicecall. Services like person-to-person two way video calls orone way video calls, aim toimprove person-to-person communication. Entertainment services like gaming, videostreaming of a movie, movie trailers or video clips are also supported in 3G. Moreover,services like web browsing and data download enhance the connectivity of the users.Many more of such services are possible due to the augmented data rates supported bythe 3G networks and because of the support for Quality of Service differentiation inorder to efficiently deliver required quality for differenttypes of services.

The specification of 3G is done in the 3rd Generation Partnership Project (3GPP),that is a joint project of the standardization bodies from different countries. The firstspecifications were available at the end of the year 1999 and the release was calledRelease’99. The standardization work has continued and has led to further evolutionof data rates and capabilities, resulting in releases like Release 4 in 2001, Release 5 in2002 and so on.

2.2 Context and Contributions of this Thesis

The first generation and the second generation mobile systems were successful in pro-viding good quality voice services over wireless and soon became popular, resultingin billions of subscribers. Now, third generation mobile systems aim to do the samewith more applications like multimedia and data services. Multimedia services overwireless are gaining momentum and will likely be a significant source of revenues forcellular-network operators. The work reported in this document focuses on the designand study of multimedia services over third generation mobile systems.

This work studies the delivery of the multimedia services over IP because the thirdgeneration mobile network is evolving towards an “All IP Network”. Traditionally, thereal time services were provided using circuit switched technology but, in the “All IPNetwork” they will be provided using a packet switched (IP) technology. The goal isnot only to provide a similar quality as compared to circuit switched technology but,to move ahead further by providing even better quality and service. This goal itselfis a challenge, because apparently the existing packet switched network, the currentInternet, is inherently unsuitable for real time services.This study aims at contributingtowards such goal and is presented in three parts.

Multimedia applications considered in this study are the Voice over IP (VoIP) andthe unicast video streaming service over IP. Even at present, the roaming, long distanceand international call services are expensive over wireless. The VoIP represents a goodsolution as calls can be made from one VoIP client to any otherclient or phone withvery low costs. In 3G, the VoIP service is required to go even one step further. It

Dissertation Outline 35

not only allows two or more persons to communicate in real time but also integratesthe sharing of content, like video and images, gaming etc. Nevertheless, one of thedisadvantages of VoIP, and other applications over IP, is the large IP packet header thatis of the order of 40 to 120 bytes when combined with other protocols that are utilized.This is a significant overhead when compared to the typical payload size of the orderof 100 bytes for the VoIP applications. Thus, a header compression scheme is requiredto reduce the overhead and is the core theme of the first part ofthis work. The resultsrelated to this part have been published in [97, 98, 99].

Quality of Service (QoS) differentiation is an important part of the 3G network be-cause different services have different requirements. As an example; real time serviceshave stricter requirements when compared with the servicessuch as data download andemail. It is important to differentiate and prioritize the services with stricter require-ments over the services with loose requirements to save the former during overload onnetwork resources. The part II of this work studies the problem of providing QoS dif-ferentiation through the use of channel adaptive packet scheduling for the 3G. Novelstrategies are proposed that are important for the allocation of resources between dif-ferent QoS classes. Moreover, a new packet scheduler is proposed that improves uponexisting scheduling policies by not deteriorating the QoS during the overload on thenetwork resources. The results obtained from the studies done in this part have beenpublished in [32, 54, 126, 127, 131].

The last part of the thesis focuses on the transmission of video data over wirelesslinks such as those found in 3G systems. Multimedia transmission schemes shoulduse some form of congestion control, both in wired and cellular networks, in order toadapt the sending rate to the available bandwidth, hence preventing the network fromsuffering from congestion collapse. The typical video congestion control schemes facea new challenge over wireless links because the packet loss rate is higher than thetypical wired networks, due to bad radio conditions. These packet losses not onlyconfuse the congestion control schemes, but also deteriorate the video quality due tothe loss of the video data. In part III, new strategies are proposed that enhance thevideo quality by using wireless loss estimation and differentiation, that in turn areused in adaptive and efficient congestion control for the video transmission. Moreover,selective retransmission strategies are proposed that areused to further improve thevideo quality by recovering the lost video data. The resultspresented in this last parthave been published in [128, 130, 129] and [125] is submittedfor review.

2.3 Dissertation Outline

This section provides the outline of this dissertation by giving some details on thedifferent chapters that present the contribution of this study, already summarized in theprevious section. This chapter forms the introduction and the chapter 3 presents the

36 Introduction

related background.

2.3.1 Part I

The chapter 4 gives an overview of a header compression scheme called Robust HeaderCompression (ROHC). The optimization of ROHC over 3G systems is discussed in thechapter 5.

2.3.2 Part II

The High Speed Downlink Packet Access (HSDPA) enhancement to the UMTS is pre-sented in the chapter 6. The impact of HSDPA packet scheduling on video streamingis studied in chapter 7. It is a novel study, to the best of our knowledge, because it usessubjective quality evaluation metrics to assess the packetscheduling policies. More-over, in the same chapter, a new scheduler called NormalizedRate Guarantee (NRG)is proposed that improves upon an existing scheduling policy. Further, some resourceallocation strategies are studied in chapter 8.

2.3.3 Part III

A summary of congestion control schemes proceeded by a studyof such a schememore suitable for video transmission is given in chapter 9. Chapter 10 proposes awireless loss estimation scheme that can be used to improve the efficiency of the con-gestion control schemes used for the video transmission. Chapter 11 presents someselective retransmissions schemes for the recovery of the lost video data due to badradio conditions.

2.4 Publications

The work presented in this document has been published in thefollowing articles:

• Kamal Deep Singh, Arpad Huszak, David Ros, César Viho and Gabor Jeney. “Con-gestion Control and Adaptive Retransmission for Multimedia Streaming over WirelessNetworks”. Submitted to an international conference.

• Kamal Deep Singh and David Ros. “Normalized Rate Guarantee Schedulerfor HighSpeed Downlink Packet Access”. InIEEE GLOBECOM 2007, Washington, November2007.

• Kamal Deep Singh, David Ros, Laurent Toutain and César Viho. “Proportional Re-source Partitioning over Shared Wireless Links”. InIEEE 66th Vehicular TechnologyConference, Baltimore, MD, USA, September 2007.

Publications 37

• Kamal Deep Singh, Julio Orozco, David Ros and Gerardo Rubino. “Streaming of H.264Video over HSDPA: Impact of MAC-Layer Schedulers on User-Perceived Quality”.ENST Bretagne Research Reportno. RR-2007002-RSM, 2007 and submitted for publi-cation in a journal.

• Kamal Deep Singh and David Ros. “TCP-Friendly Rate Control over HighSpeedDownlink Packet Access”. InProceedings of IEEE ISCC’07 (12th IEEE Symposiumon Computers and Communications), Aveiro, Portugal, July 2007.

• Kamal Deep Singh, David Ros, Laurent Toutain and César Viho. “Improving Multime-dia Streaming over Wireless using End-to-End Estimation of Wireless Losses”. In IEEE64th Vehicular Technology Conference, Montreal, Canada, September 2006.

• Kamal Deep Singh, David Ros, Laurent Toutain and César Viho. “Improvement ofMultimedia Streaming using Estimation of Wireless losses”,IRISA Research Reportno.PI-1792, March 2006.

• Ana Minaburo, Kamal Deep Singh, Laurent Toutain, Cécile Marc and Elizabeth Mar-tinez. “Performance Improvement of Multimedia flows by using UDP-Lite and ROHCcompression”. In5th ICICS International Conference on Information, Communicationsand Signal Processing, Bangkok, Thailand, December 2005.

• Ramiro Garcia, Jose Incera and Kamal Deep Singh. “An Experimental evaluation ofH.264/AVC semantic codec video streaming in a Diffserv network architecture”. InROC&C 2005, Acapulco, Mexico, November 2005.

• Pablo Frank Bolton, Jose Incera and Kamal Deep Singh. “Objective and subjectivecharacterization of video streams in IP networks”. InROC&C 2005, Acapulco, Mexico,November 2005.

• Ana Minaburo, Kamal Deep Singh, Laurent Toutain and Loutfi Nuaymi. “Proposedbehavior for robust header compression over a radio link”. InIEEE International Con-ference on Communications (ICC 2004), Paris, France, June 2004.

• Ana Minaburo, Loutfi Nuaymi, Kamal Deep Singh and Laurent Toutain. “Configu-ration and Analysis of ROHC in the UMTS”. In14th IEEE International Symposiumon Personal, Indoor, and Mobile Radio Communications (PIMRC’03), Beijing, China,September 2003.

38 Introduction

Chapter 3

Multimedia Streaming over ThirdGeneration Mobile Networks

This chapter provides the general background of the thesis;more specific backgroundis presented in the relevant chapters later. Initial sections present some background onMultimedia Compression. The focus is on the video compression and not on the audiocompression because the video stream takes far more bandwidth in comparison to theaudio stream. Nevertheless, most of the general descriptionapplies to audio as well.The latter part of this chapter presents the quality of service architecture and supportfor the multimedia applications. The description of the UMTS network concludes thechapter.

3.1 Video Compression

Typically, digitalizing a video source generates a lot of data, so it is commonly com-pressed before streaming. Video compression mechanisms are based on the removalof redundancy from a sequence of pictures.

Video frames have spatial and temporal redundancy. Spatialredundancy appearsinside a video frame when a region is equal to one or more contiguous regions. Tem-poral redundancy occurs between contiguous frames becausethe difference betweena particular frame and the next one is often very small. The codec reduces the spatialredundancy by defining a region as a reference to its neighbors. Similarly, the codectakes some frames as temporal references for the next ones. In both cases, only thedifferences between the secondary frames and the referenceframe are considered.

This kind of processing provides a high compression rate, but it is very vulnerableto packet losses in a congested network. Indeed, if a reference frame is lost, the degra-dation of the video quality is notorious, since not only the information in that frameis lost, but also the subsequent frames based on it become useless. Nevertheless, the

39

40 Multimedia Streaming over Third Generation Mobile Networks

most standard and popular set of codecs are based on these ideas.

3.1.1 Video Compression Standards

The Moving Pictures Experts Group (MPEG) was formed by the International Stan-dards Organization (ISO) to set standards for audio and video compression. MPEG-1was the first compression standard for compressing audio andvideo. A subsequentstandard called MPEG-2 was chosen as compression scheme forDigital Video Broad-cast (DVB) and Digital Video Disk (DVD). MPEG-4 is the name of the standard thatcame after MPEG-2.

3.1.1.1 MPEG-4

MPEG-4 provides better quality and better compression ratein comparison to the pre-vious standards. This is achieved by using improved compression tools that thoughhave additional complexity but improved efficiency.

MPEG-4 is set to become an important standard for multimediadelivery over In-ternet and wireless networks.

3.1.1.2 H-264/AVC

MPEG-4 has several profiles. H-264/AVC [115, 11, 140] refersto the part 10 profileof MPEG-4. The main goal of H.264 is the efficient and robust compression of rectan-gular video frames for applications like storage, videoconferencing, video-telephony,broadcast and streaming over a wide variety of networks.

H.264 offers an improved compression efficiency of over 50% against older codecslike MPEG-4/Part-2 or H.263+ [76] [72]. The enhanced codingefficiency of H.264is not due to a dramatic change in the coding principles; as a matter of fact, H.264follows the same model of block-based transformation and motion compensated inter-frame prediction used by older standards. The superior performance of H.264 comesfrom the aggregated effect of a series of algorithmic innovations, each one accountingfor an incremental gain. For motion prediction, these enhancements include the useof small and variable block-sizes, quarter-pixel accuracy, motion vectors over pictureboundaries and the use of multiple reference pictures [116]. Other enhancements in-clude small block-size transformation and the use of advanced entropy coding methods(CABAC and CVLC) [140].

In addition to an improved coding efficiency, a very important feature of H.264 isthat it is specifically designed for the transport of coded video over a variety of existingand future network transport technologies. The design of H.264 addresses this needfor flexibility and customizability by means of separating the coded information intwo layers: the Video Coding Layer (VCL) and theNetwork Adaptation Layer(NAL)

Video Streaming 41

[140]. VCL represents the coded video information in the mostefficient manner pos-sible. NAL formats the VCL data and organizes it in elements with the appropriateheaders for transport or storage on a wide variety of technologies.

Regarding error robustness, H.264 includes several advanced features that are closelyrelated to the concept of NAL [116]. The key syntax elements of the H.264 structureare flexible-sizedslices. Each slice is conveyed in a single logical data packet (calledNAL Unit or NALU). This flexibility allows for the efficient adaptation of the codedstream to the particular transport technology. Other features include the concepts ofFlexible Macroblock Ordering (FMO) and Data Partitioning (DP) [138].

3.1.1.3 MPEG4-SVC

Recently the trend is towards developing a Scalable Video Codec (SVC). Today’s mar-ket trend of “TV anywhere and anytime” requires the ability to stream multimediatowards multiple kinds of terminals and over different types of networks to reach theend users. Existing solutions encode videos several times in different formats and bitrates to cope with the requirements. But, this approach is expensive and inflexible be-cause lots of encoding and storage resources are needed and too much bandwidth iswasted.

SVC will code the video stream in such a way that it will be possible to obtain a bitstream of any given rate. The stream is coded in a hierarchical way and the degradationin quality will be significantly linear with the change in rate. This way applications willbe able to adapt to the network in a very flexible way. MPEG4-FGS [87] representsan example of such kind of codec. Currently lot of research is under way to obtainmore scalability. Moreover, MPEG4-SVC provides scalability with good compressionefficiency in comparison with other scalable encoding solutions.

3.2 Video Streaming

Video streaming, over any network, has strict requirementsin terms of delay and jitter.This is because the video data units have to be ready for presentation before theirdeadline. Figure 3.1 shows a typical scenario of video streaming. The video encoderfirst compresses or encodes the raw video into a file. That file can be stored in theserver for streaming it later.

The server can begin transmitting the video as soon as a videoclient requests thevideo. The client usually starts to play the video after someinitial delay that is typicallyof the order of 4 to 8 seconds. This initial delay is used to buffer the incoming data intothe client buffer or the play-out buffer. This smooths out the jitter between the packetsand also ensures smooth play-out even when network bandwidth becomes insufficientfor some time. It should be noted that this play-out buffer can absorb only short termdelay or bandwidth variations. Long term variations can degrade the quality of video


Figure 3.1: A typical scenario of video streaming [17]

Figure 3.2: Streaming of variable bit rate video [17]

Video Quality Evaluation 43

streaming and can introduce discontinuity in the video playback. Moreover, a longerplay-out buffer can absorb larger variations, but it will also lead to higher initial delays.

There are also several buffers present in the network routers that aim to accommo-date the bursts of arriving packets. They also protect the packets from getting discardedduring temporary degradations in the link bandwidth or during congestion.

It is sometimes desirable to encode the video with variable bit rate (VBR) becausethe different scenes in the video may contain different amounts of complexity, requir-ing more bits to preserve the relative quality. The streaming of VBR video, shownin Figure 3.2 poses some problems. Some video streaming strategies send the dataat a constant rate by adaptively delaying some data packets.Sending at constant ratereduces the burstiness1 and helps the video stream to remain compatible with someQuality of Service, discussed in the following sections, attributes that give priority tothe video data only up to certain bit rate.

Nevertheless, the delays introduced while sending VBR videoat constant rate putstricter delay requirements on the network. It also adds to the complexity of the videostreaming client because the stream has to be processed two times at the client as shownin Figure 3.2.

3.3 Video Quality Evaluation

Several factors, such as network delay, packet loss etc., may lead to loss of video datathat can distort the video sequence. Two types of methodologies have become popularthat can measure the distortion: objective assessment and subjective assessment. Wedescribe these approaches in the following text.

3.3.1 Objective Assessment

Objective Assessment methods use algorithms to measure thedistortion in a givenvideo sequence. These algorithms are fast and very easy to use. Most of these algo-rithms require the original signal in order to compare it with the distorted signal. Oneof the most popular method is to use the Peak Signal-to-NoiseRatio (PSNR) measure.

PSNR gives the distortion between the original and the processed (impaired) ver-sions of a video sequence. Let’s say that we have two sequences: S (original) andS′

(impaired). S(x,y,k) is the luminance of a pixel at positionx,y in framek from theoriginal sequence andS′(x,y,k) is the luminance of a pixel at the corresponding posi-tion in the impaired version. The sequences areK frames long, the frame size isM ∗Npixels, and each pixel luminance is represented with 8 bits.The Mean Square Error isfirst obtained with the formula below:

1Burstiness is undesirable for the network routers as it can cause the router buffers to fill up suddenly.


MSE=1

KMN

K

∑k=1

M

∑y=1

N

∑x=1

[S(x,y,k)−S′(x,y,k)]2 (3.1)

The MSE is the cumulative squared error between the originaland the impairedimages. A lower MSE means a smaller error. The PSNR is then computed with thefollowing expression:

PSNRdB = 20log10255√MSE

(3.2)

The result of the PSNR is a decibel value (dB).

3.3.2 Subjective Assessment

Subjective assessment methods are supposed to be the best indicators of the videoquality, for a video that will be watched by humans, because the assessment is done byreal humans. In general a distorted sequence, in addition tothe original sequence, isshown to the human subjects and they are asked to give a score to the sequence. Later,the scores from several subjects are statistically processed to give a mean score (theMOS or Mean Opinion Score) for that particular distorted sequence.

The ITU-R Recommendation BT.500-11 [65] defines several standard methods andprocedures for the subjective quality assessment of television pictures. One of themethods is called Double-Stimulus Impairment Scale (DSIS). In DSIS method, anassessor is first presented with the original video sequence, then she is shown the dis-torted version. The assessor rates the degree of the impairment of the second imagehaving the reference in mind. This is repeated with several pairs of sequences. Thescore for each sequence is taken from the impairment scale shown in table 3.1.

Note Description5 Imperceptible4 Perceptible, but not annoying3 Slightly annoying2 Annoying1 Very annoying

Table 3.1: Impairment scale

However, such kind of assessment is costly and time consuming. An alternativeway is to use a novel technology called Pseudo-Subjective Quality Assessment (PSQA)that will be described and used in chapter 7. PSQA provides anaccurate quantitativeevaluation of the quality of a video stream over a packet network, as perceived by the

Quality of Service 45

final user. The evaluation provided by PSQA can be done, if necessary, in real time. Itis based on statistical learning techniques and currently uses a specific class of NeuralNetworks called Random Neural Networks, to capture the way humans perceive thevideo quality. The PSQA tool is first trained using real humans and later it is usedto predict the MOS scores. The training part is costly and time consuming, but theevaluation is very fast and automatic.

3.4 Quality of Service

Some applications, like video streaming, have requirements that cannot be satisfiedwith a Best Effortservice when there are not enough network resources available, i.e.,when the network is congested. For these applications the network infrastructure mustbe adapted in order to give them a special treatment in terms of delay, loss tolerance,jitter, etc. This special treatment is usually called Quality of Service (QoS). When thenetwork provides QoS it is possible to provide different service levels to different dataaccording to its particular needs.

3.4.1 DiffServ

The IETF (Internet Engineering Task Force) has developed some standards and tech-nologies in order to provide QoS in IP networks; the most widely accepted amongthem, is the Differentiated Services architecture. In DiffServ, the user traffic is sepa-rated into different Classes of Service based on their individual requirements. At theedge of the network, each packet is marked according to the treatment that it wouldlike to receive inside the network. The mark or tag is a coded value in the DiffServCode Point field (DSCP) of the IP header. Packets with the same DSCP value belongto the same class and will receive the same treatment inside the network. The differenttreatments a particular router can implement are called PerHop Behaviors (PHB).

3.4.1.1 Expedited Forwarding

The Expedited Forwarding or EF PHB [69] is designed for the provisioning of end-to-end services with low-delay, low-loss, low-jitter and guaranteed throughput. Applica-tions with strong QoS requirements like voice over IP, interactive video or business-critical data systems should benefit from this type of service. The main building blockfor the implementation of an EF core router is a scheduling mechanism like PriorityQueuing or Weighted Fair Queuing.


Figure 3.3: “Staggered” RIO.

3.4.1.2 Assured Forwarding

One of the standardized PHB is Assured Forwarding (AF) [60].The AF PHB allowsa network provider supporting DiffServ to offer different levels of forwarding assur-ances, for IP packets accomplishing a target throughput foreach network aggregate.It provides four AF forwarding classes with three dropping priorities each that definethe relative importance inside an AF class. These drop priorities are usually identifiedwith colors: greenfor the lowest drop precedence (the highest forwarding priority),yellowfor the middle one andred for the highest one.

In a typical AF setup, packet marking is done by edge routers and is based on rate-metering or flow identification mechanisms [60]. However, asexplained in the follow-ing section, the application can mark its packets in order for them to take advantageof the advanced rate, delay, jitter and/or loss features offered by a DiffServ-enabledIP network supporting AF-based service classes. The idea behind this is that perfor-mance may be improved if applications are “aware ”—i.e.,make use—of the enhancednetwork capabilities offered by the DiffServ architecture(see e.g. [104] and referencestherein). A DiffServ-aware streaming application marks the outgoing packets accord-ing to therelevance, for decoding purposes, of the information they carry. Thisway,the differentiated treatment inside the DiffServ network should yield a better percep-tual quality by assuring a particular rate, limiting delay and jitter, ordiscarding firstless important packetswhen congestion arises.

The implementation of an AF core router requires two mechanisms: a schedulerand a priority dropper. The scheduler does the weighted allocation of bandwidth tothe classes (or queues) and the priority dropper performs the differentiated discard of

Quality of Service 47

Figure 3.4: DiffServ coloring for video frames.

packets within each queue. Examples of schedulers for AF areClass-Based Queuingand Weighted Fair Queuing. Priority dropping is performed by an extension of theRED Active Queue Management mechanism, like RIO or Weighted RED.

RIO (RED with In and Out) [41] is the basic queue management mechanism suit-able for the setup of the AF PHB. Active queue management (AQM)mechanismsprovide congestion avoidance at the router. RIO is derived from RED [50], whichis one of the best-known AQM mechanisms. RED avoids congestion by controllingthe average queue size and comparing it against two thresholds, minth and maxth. In-side this “congestion-avoidance” interval, packets are discarded with a probability thatgrows linearly with the average queue size. Several variants of RIO exist, of which Fig-ure 3.3 shows the “staggered thresholds” model [94]. It can be seen that the packets oflower priority are more likely to be discarded as compared tohigher priority packets.Moreover, incoming higher priority packets are only dropped after discarding all thelower priority packets when queue length starts to increase, i.e., during congestion.

3.4.2 DiffServ aware Video Streaming

The termQoS-aware video streamingrefers in general to any streaming architecture inwhich video data packets receive a differential treatment from the network, accordingto the relative importance of the coded-video information carried by those packets.The idea is that the underlying IP QoS mechanisms can be leveraged to offer a “better”treatment (for instance, in terms of packet loss rate) to packets that have been “marked”by the source application as containing data which are the most important for decodingpurposes. In what follows we will present a QoS-aware H.264 streaming techniquebased on a particular QoS architecture, theDiffServarchitecture.

Video codecs perform compression by removing redundant information from theoriginal signal both spatially (within a single frame) and temporally (between con-secutive frames). This way, some frames are coded very much like still images andtaken as reference for subsequent or previous frames. If a reference frame is lost, theeffect on visual quality is large, because a whole group of derived frames can not bedecoded correctly without the reference information. Thus, a way of realizing QoS-aware streaming consists of mapping the relative loss relevance (orsemantics) of the


video elements to the different loss priorities in a DiffServ AF network. For example,legacy codecs like MPEG-2 or MPEG-4 define a hierarchy with three types of frames,ordered by their loss effect on visual quality: I (reference), P and B. As shown inFigure 3.4, a simple DiffServ aware scheme is to mark I frameswith the highest AFpriority, i.e.,green. The P frames are marked asyellowand the B frames are marked asred. During congestionred packets containing the least important (B-frames) data arediscarded first andgreenpackets containing most important (I-frames) data are the lastto be discarded. Thus, for an equivalent loss rate, this approach should offer a bettervisual quality than Best Effort.

This type of DiffServ-aware mapping was proposed and evaluated for H.264 stream-ing in [104]. The authors describe different AF-aware coding and marking strategiesbased on the network adaptation and error resilience features of H.264. The simpleststrategy consists of adapting the video slice size to the network packet size and markpackets containing I, P and B slices as high, middle and low priority, respectively,within a single AF class. A tool forobjectivevideo quality assessment was used forperformance evaluation, and the results show that DiffServ-aware streaming yieldsbetter quality than Best-Effort under congestion (improvements of up to 30% werereported in [104]).

3.5 UMTS Network

A simplified UMTS [61] architecture consists of the core network and the UMTS Ter-restrial Radio Access Network (UTRAN) as shown in Figure 3.5. The UTRAN con-sists of Radio Network Controllers (RNC) which control several base stations (BS, orNode B) and is responsible for the control of radio resources in its domain. A mo-bile user present in the UTRAN can stream video on her User Equipment (UE) from aserver in the Internet. The UTRAN is connected to the other networks like the Internetthrough the core network. In the UMTS network, all the links in the core network areusually over-provisioned. Such over-provisioning of the core network, together withthe fluctuations in radio channel quality that are inherent of wireless links, will oftenmake the UTRAN act as a bottleneck.

The core network contains the Home Location Register (HLR), that is the databasewhere the details of the user’s subscription of different services are stored. Somenodes present in the core network are divided such that they are either used for circuitswitched services or are used for packet switched services.Mobile Services SwitchingCenter (MSC), the switch, and Visitor Location Register (VLR), the database, providecircuit switched services to a user in its current location,that may be away from home.Gateway MSC (GMSC) is the switch that provides the connectionwith the external cir-cuit switched networks like Integrated Services Digital Network (ISDN), Public LandMobile Network (PLMN), Public Switched Telephone Network (PSTN), etc.

UMTS Network 49

Figure 3.5: A general UMTS network.


The nodes, present in the core network, related to the packetswitched services areServing GPRS Support Node (SGSN), with the functionality similar to MSC/VLR inthe context of packet switched services, and Gateway GPRS Support Node (GGSN)that connects the core network to the external packet switched networks like the Inter-net.

There are also several interfaces that are present in the UMTS network. Some ofthem are described as follows:

• Uu: This is the radio interface through which a UE connects to a BS presentin the UTRAN. This interface being subject to varying radio conditions, that inturn make it a bottleneck, is the subject of much optimization and research.

• Iub: This interface connects a BS to a RNC.

• Iur: This interface connects two RNCs and can be used when bothRNCs areserving a particular UE during soft handover.

• Iu: This interface is used to connect a UTRAN to the core network. It caneither be IuCS that connects a UTRAN with the nodes providing circuit switchedservices or IuPS that connects it to the ones providing packet switched services.

• Gn: This interface connects a SGSN to a GGSN.

3.5.1 All IP Network

In the last generation of mobile networks, the real time services were carried via circuitswitched (CS) networks. The trend is moving towards an “All IPNetwork”[12] orpacket switched (PS) technology, where all the services will be carried over the InternetProtocol (IP). This will ensure compatibility with the Internet that in turn runs overIP. Moreover, this will lead to the simplification of the network, easy maintenanceand bandwidth efficiency. That in turn will provide efficiency and cost reduction forthe network equipments. A seamless network, a similarity ofservices and the inter-working between different networks are some of the key aspects identified in [16].

The Initial releases of UMTS offered voice and video via a CS network and otherservices like SMS, email etc. via a PS network. In the recent releases of UMTS,release 5 onwards, it is possible to offer all the services, including voice, via a packetswitched network. As the UMTS evolves with new releases, therising demand ofpacket switched services will, side-by-side, need enhancements of the packet switchedtechnology to provide quality of service to the users. Moreover, while changing fromCS to PS it will not be sufficient to provide the same quality as observed in CS network,but users will expect better quality from the new technology. The third generationmobile networks aim to achieve this goal by supporting high data rates and includingQoS differentiation support in their networks

UMTS Network 51

Figure 3.6: QoS Architecture for UMTS.

3.5.2 QoS in UMTS

The users perceive the quality of service in an end-to-end manner. The UMTS networkthus considers an end-to-end service that is visible to the users. The end-to-end servicein turn uses “Bearer Services” that are setup in the path and have certain functionali-ties and characteristics. Each bearer service offers its services to the upper layer anduses the functionalities of the lower layers as shown in Figure 3.6. The two TerminalEquipments (TE) shown in the figure are the end points for the traffic and one can bethe video streaming server and other can be the mobile equipment playing the video.The traffic between the two TEs has to pass through all the bearer services on its way.

3.5.2.1 UMTS QoS Classes

UMTS defines four QoS classes [13] and the classified traffic gets the treatment insidethe UMTS network according to its class. The four QoS classesare:

• Conversational class: The traffic from the applications like person-to-personvideo or voice call is classified into conversational class.The delay and jitter


requirements for this type of traffic are very strict. This isbecause on the bothend points there is a human expecting the delivery of the voice and/or video datain very short time after it is sent.

• Streaming class: Video on Demand (VoD) falls under this class. The delay re-quirements are there but are not as strict as the conversational class.

• Interactive class: The interactive traffic like interactive e-mail or web browsingfalls under this category. Though there is still some delay requirement, it is lessstrict than the conversational and streaming classes. Moreover, since the trafficmostly pertains to data applications, the bit error rate should be very low.

• Background class: This class is the most insensitive to delay. It includes thetraffic from background applications like background emailand SMS. Though,the bit error rate, like the Interactive class, should be very low.

3.5.3 Long Term Evolution (LTE)

After the Release’99, the 3rd Generation Partnership Project (3GPP) continued to workthat led to important evolutions and new releases. In Release5, 3GPP started the spec-ification of High Speed Packet Access (HSPA) by specifying High Speed DownlinkPacket Access (HSDPA), that supports data rates of the orderof 10 Mbps and is de-scribed in the following section. The specification for the Uplink, High Speed UplinkPacket Access (HSUPA) was done in Release 6.

Further evolution, called Long Term Evolution (LTE) [63, 15], is a work in progressthat is expected to finish in 2007-2008. The LTE radio technology will use OrthogonalFrequency Division Multiplexing (OFDM) and Multiple Inputand Multiple Output(MIMO). The data rates, as shown in Figure 3.7, are expected to reach 100Mbps forthe downlink and 50 Mbps for the uplink.

Some general goals and requirements of LTE are [15]:

• Downlink data rates of the order of 100 Mbps and uplink data rate of the orderof 50Mbps.

• Reduced cost per bit.

• Increased service provisioning - more services at lower cost with better userexperience.

• Flexibility of use of existing and new frequency bands.

• Simplified architecture, and Open interfaces.

• Allow for reasonable terminal power consumption.

UMTS Network 53

Figure 3.7: Peak data rates for the Long Term Evolution (LTE)of the UMTS.

3.5.4 High Speed Downlink Packet Access

High Speed Downlink Packet Access (HSDPA) [62, 6, 7, 105] is an enhancement toUMTS networks and it supports data rates of several Mbit/s, making it suitable forapplications ranging from file transfer to multimedia streaming.

HSDPA is an enhancement of UMTS that has been designed to meetthe increasingdemands of data and multimedia services. It provides many improvements as com-pared to older versions of UMTS. Higher data rates and lower delays are achieved us-ing fast and channel-adaptive schemes like Adaptive Modulation and Coding (AMC),fast Hybrid-ARQ (HARQ) and fast scheduling based upon a very short time intervalof 2 ms.

A new transport channel called High Speed Downlink Shared Channel (HS-DSCH)has been introduced for HSDPA [62]. HS-DSCH is supported by anauxiliary channelcalled High Speed Shared Control Channel (HS-SCCH). The goal of the latter is toallow for fast monitoring of the radio channel conditions ofall users: every 2 ms, aUE can send to the base station a Channel Quality Indicator (CQI) over this controlchannel. This feedback makes it possible to optimize the transmission by means ofchannel-adaptive schemes. Thus, the CQI is used to adapt the coding rate, modulationscheme and number of codes employed, so that users having good channel conditionsmay be provided with high data rates.

In older releases of UMTS, the frames with errors are retransmitted by the RLC(Radio Link Control) protocol layer present in the RNC. In HSDPA,the MAC layeritself can perform fast retransmission of the erroneous data, and retransmission timesare reduced as this functionality has been moved to the BS. This also provides fast


response times of the channel-adaptive schemes described above. At the MAC level,fast Hybrid-ARQ (HARQ) is used to retransmit the erroneous frames; UEs in turn donot discard the erroneous frames, but combine them with the successive retransmittedframes using schemes like Chase Combining and Incremental Redundancy.

Due to its shared nature, providing resource management (that is, allocating band-width among terminals) is complex due to variable radio channel conditions; these maychange rapidly, especially for users farther from the BS. Oneof the main characteristicsof HSDPA is the use of MAC-layer scheduling to perform resource management (i.e.,bandwidth allocation between terminals), taking into account the radio channel condi-tions of all users. Such channel-adaptive scheduling may result in strong bandwidthfluctuations, causing packet loss and degradation in the quality of the received video.Additional factors like fairness between users, cell throughput or quality-of-service(QoS) parameters are also considered in some scheduling mechanisms proposed in theliterature.

Part I

Header Compression for MultimediaFlows

55

Chapter 4

Robust Header Compression (ROHC)

Convergence of IP with wireless networks in the third generationmobile systems raisesa problem that some multimedia applications such as Voice over IP (VoIP) face sig-nificant overhead while using IP. For such applications, the packet header size is sig-nificant when compared with the payload size of the IP packets. Aheader compres-sion scheme is required that is not only efficient but also robust to work over wirelessnetworks. This chapter presents ROHC [35] that is the new standard for header com-pression proposed by the IETF (Internet Engineering Task Force) to compress differentprotocol headers.

4.1 Introduction

UMTS is expected to provide many services based on the Internet or IP-based services.However, the use of IP will mean large overheads, as shown in Figure 4.1, which willtake a significant amount of bandwidth, which is already scarce in cellular links. More-over, the use of IPv6 flows for data transmissions in Releases 4and 5 of UMTS willdegrade the situation, as the overhead bytes in IPv6 are larger. Hence, there is a needto compress the large headers and save some valuable radio resources. In the UMTSreference protocol architecture, a special layer (PDCP: Packet Data Convergence Pro-tocol), shown in Figure 4.2, dedicated to header compression has been introduced. Theheader compression is a scheme that removes (ideally all) the redundant informationfrom packet headers. Existing header compression schemes do not perform well overcellular links due to the high Bit Error Rate (BER), around 10−2 to 10−3, and the highround trip time (RTT), around 200ms, of the radio channel. Inthis scenario a valid so-lution is represented by Robust Header Compression (ROHC) thathas been proposedby the Internet Engineering Task Force (IETF).

57

58 Robust Header Compression

Figure 4.1: Headers overhead [17]

Figure 4.2: UMTS Radio Interface Protocol Architecture [14]

Header Compression 59

4.2 Header Compression

The problem of the performance of the IP protocol over a low bandwidth link has beenstudied since 1984 with the Thin-wire protocol specified by Farber et al. [47]. In 1990,Van Jacobson proposed a mechanism based on the header redundancy information,which compressed the 40 bytes of the TCP/IPv4 header to 3-6 bytes [68]. There areother propositions for the different protocol headers based on redundancy, as the CTCP(IP Header Compression) header mechanism [46], which manages a wide variety ofstreams and gives particular attention to IPv6. The CRTP (Compressing IP/UDP/RTPHeaders for Low-Speed Serial Links) header mechanism [37] is a detailed specificationfor RTP compression.

Studies [45] and [74] have demonstrated that the performance of these protocols isstill quite poor in wireless links. The next generation of header compression mecha-nisms aims to add a robust and efficient compression scheme that can be used in a lowbandwidth link with significant error rate. An algorithm to improve the performanceand robustness for TCP/IP flows was proposed by Degemark [46] who suggested astrategy to recover from the loss of compression synchronization, which occurs due tohigh BER. A second algorithm called PEHC was presented by Perkins [109] to furtherreduce the probability of synchronization loss. These schemes were further improvedby Giovanardi who proposed two retransmission strategies,ABP-SCS and ABP-DCS[117], to reduce the TCP/IP header synchronization loss in anUMTS radio link. Thenew contributions for TCP/IP header compression are TAROC [144], EPIC [111] andROHC+ [30]. TAROC’s goal is the limitation of error propagation using TCP con-gestion window tracking. EPIC uses a variant of Huffman encoding to produce a setof compressed header formats. ROHC+ proposes a new profile andan algorithm forcompressing TCP streams within the ROHC framework.

Many contributions have been proposed for the IP/UDP/RTP protocol stack, likethe adapted header compression for real time multimedia application (ACE) [86], theheader compression using keyword packets [101], or the header compression basedon Checksum (ROCCO) [75]. These three contributions are the basis for the headercompression standard ROHC (Robust Header Compression) described in RFC 3095[35].

4.3 Header Compression in the UMTS

The network functions of the UMTS architecture, see Figure 4.2, are divided logicallyinto two service stratums: the AS (Access Stratum) and the NAS (Non Access Stra-tum). The data flows are divided into two planes: the control and the user plane [61].The control plane uses the RRC (Radio Resource Control) protocol for the signalingbetween the network and the UE (User Equipment). The signaling is divided in two


Figure 4.3: ROHC over UMTS

parts: the AS for call control and the NAS for call management.The PDCP layer [8] exists only in the user plane and it is only used for packet

mode services between the UE (User equipment) and the UTRAN (UMTS TerrestrialRadio Access Network). The PDCP layer includes in its functionalities the IP headercompression protocols (CTCP [46] and ROHC [35]). The PDCP entities can use zero,one or several header compression mechanisms. In addition,different radio bearerscan use the same PDCP entity.

Header Compression can be used over wireless links in the UMTSnetwork withthe compression and decompression pair on the each side of the link as shown in Fig-ure 4.3. This will benefit both the downlink and the uplink. The UMTS networkhas included the ROHC standard as it is used in a PPP (Point to Point Protocol) [123]network: the negotiation is made initially where the compression parameters are estab-lished, but the UMTS network uses its resources dynamically. The RRC layer containsan update procedure to know the QoS parameters values of the radio link at any instant,with which it controls the radio resources. The QoS parameters that are useful for theheader compression are transfer delay, residual error and bit error rate, all defined in[10].

4.4 Robust Header compression (ROHC)

The ROHC header compression algorithm was conceived to reduce the header sizesof IP packets to be sent through a cellular link, which is characterized, by high BER,long RTT (Round Trip Time) and residual errors that pass undetected even after CRCchecks. ROHC can compress several types of headers such as IP, UDP and RTP etc.In order to compress the header, the ROHC mechanism makes a classification of theheader fields. That is based on how the values in the header fields change during a

Robust Header compression (ROHC) 61

C I D o c t e t

T y p e o f R O H C h e a d e r

0 - 2 C I D o c t e t s

R O H C p r o f i l e

C R C

S t a t i c i n f o r m a t i o n

D y n a m i c i n f o r m a t i o n

D a t a

C I D o c t e t

1 s t R O H C h e a d e r b y t e + t y p e i n f o r m a t i o n

0 - 2 C I D o c t e t s

D a t a

R O H C h e a d e r o f v a r i a b l e s i ze + CRC

0T y p e 0 , 1 a n d 2 P a c k e t sI R & I R - D Y N P a c k e t s

7 70

Figure 4.4: ROHC general header format packets. IR belongs to first compressionlevel, IR-DYN and UOR-2 to second compression level and type 1 and 0 to thirdcompression level.

stream. These fields are separated and assigned to the staticand the dynamic chain ofthe compressed header packets. Static refers to the information which remains moreor less constant during the lifetime of the stream and dynamic refers to the informationwhich may change but its change pattern may be known. ROHC uses different headerformat packets to establish the information in the decompressor, see Figure 4.4. First,the static information is sent to the decompressor and afterthat it increases the com-pression level by sending just the dynamic information or the encoded and compressedvalue of the several fields found in the packet headers.

The principle of ROHC is to send the minimal amount of information with high ro-bustness. One key element here is CRC (Cyclic Redundancy Check) that is computedover the original header fields before compression. The decompressor then verifies theCRC after decompressing the header and checks whether it has received the correctinformation or if the information has been corrupted due to transmission errors in thelink.


4.4.1 ROHC Context

ROHC uses a context maintained between the compressor and the decompressor tostore the information about the header stream. This contextcontains the last correctupdate of the original header and also the redundant information in the stream. Thecontext is kept both in the compressor and in the decompressor in order to ensure therobustness of the mechanism. Each time a value in the contextchanges, the contextis updated. If the context is lost due to transmission errorsthen there is no synchro-nization between the compressor and the decompressor. The decompressor then canrequest for the context update through the possible use of acknowledgments. Eachflow in a channel has its context which is identified by a CID (Context Identifier). CIDis a number that differentiates the different flows and theircontexts in the compressorand the decompressor.

4.4.2 Protocol stack and ROHC profiles

The Internet protocol stack is divided in layers and each layer gives a service by addinga header to the data flow. When interactive services are used such as voice over IP, theRTP protocol is used to transport the multimedia data [121].The header size used forIPv6/UDP/RTP can vary from 40 to 120 bytes, which representsa large overhead forapplications like Voice over IP (VoIP) that use a typical payload size of the order of100 bytes.

4.4.2.1 Link Layer

The link layer, for example the PPP protocol [123], enables the communication be-tween two computers. PPP handles the transmission of the datagrams from the upperlayer and it enables the following features: header compression, access control, trans-mission error detection and correction, and the automatic configuration of the clientpeer.

When header compression is used over PPP, it can be configured through the NCP(Network Control Protocol) protocol. The header compression mechanism, ROHC ispositioned between link layer and the upper layer (IP layer)to compress all protocolheaders starting from IP. However, compression also means redundancy reduction inthe transferred information which makes it more vulnerableto noisy transmissions.

4.4.2.2 Network Layer

The IP protocol transfers the application data in a datagrammode. This protocol en-sures the data routing and manages fragmentation. Its objective is to build a networkover any kind of physical layer. The IP has two versions: IPv4and IPv6 [44].


4.4.2.3 Transport Layer

The UDP protocol is an unreliable protocol and does not do anycongestion control. Achecksum is computed over the UDP header and the payload for end-to-end detectionof any errors. The checksum also covers some IP header fields [135] and is optionalfor IPv4 but mandatory for IPv6.

A new protocol called UDP-Lite has been defined in [85] and there are somechanges as compared to UDP. The header format is the same, butthe meaning ofthe datagram length field has changed. In UDP this field is useless because it can bededuced from the length field of the IP header. UDP-lite will use this field to know thechecksum coverage. If the coverage is zero, UDP-Lite will consider that the checksumhas to cover the entire packet. If its value is 8 then only the UDP header is covered bythe checksum. The values among 1 and 7 are reserved because the UDP-Lite check-sum must cover the whole 8-byte of the header itself. A value more than 8 will meanthat a portion of data is also protected by the checksum. If the coverage is equal to thelength of the message then we have the same situation as compared to UDP.

The idea of the UDP-Lite protocol is to divide the multimediadata into sensitiveand non-sensitive parts. Only sensitive part will be covered by the UDP-Lite checksumand if an error occurs in the non-sensitive part the packet will still be transmitted toapplication. This will give a better performance if the video codec is error resilient.

4.4.2.4 Application Layer

Real-time applications may encode multimedia flows to give better quality by correct-ing the erroneous bits in the payload during decoding. The applications can, thus,ameliorate the quality even if a full packet is lost. To decide which part of the payloadis important to include in the UDP-Lite checksum coverage, we studied the payloadformat of the H.263 RTP packets [146]. The RTP protocol is flexible in a way that itadapts to the nature of information it transports. The RTP header carries the charac-teristic information of the media flow such as timestamps andsequence numbers. TheRTP protocol gives the control to application for some functions such as ALF (Ap-plication Layer Framing) and the flow control to avoid congestion in the network, fore.g., by increasing the image compression rate or reducing the frame speed [135].

H.263 video stream packets have the RTP/UDP/IP header and also a payload header.This payload header could have three different formats depending on the desired net-work packet size and H.263 encoding options employed. In addition, all the videocodecs use a payload header that includes the signaling information of the payload. InH.263 there are three formats: mode A, B and C. The payload header in mode A willhave a size of four bytes; in mode B of eight bytes and in mode C twelve bytes.

Payload Header data is critical for the applications since it contains informationabout the payload header mode, the use of PB-frames, the current picture resolution,if the frame is an intra-coded or inter-coded picture, the motion vector options, the


differential quantization parameter and the temporal references for the B and P frames.Author in [146] stress that recovery from packet loss depends on a decoder’s ability touse the information provided in the H.263 payload header within RTP packets.

4.4.2.5 ROHC Profiles

ROHC has defined some profiles, each one compresses a packet header set. The pro-files are used to define different types of header streams. Thedecompressor can de-termine the stream type by looking at the profile. At the startof this study, only fiveprofiles were being standardized but recently the standardization has been done for twomore profiles:

• Profile 0: It does not compress any headers,

• Profile 1: compresses the IPv4/v6/UDP/RTP headers. The IPv6 extensions arealso compressed,

• Profile 2: compresses the IPv4/v6/UDP headers,

• Profile 3: compresses the IPv4/v6/ESP (Encapsulating Security Payload) head-ers,

• Profile 4: compresses only the IP header: IPv4 or IPv6 [73],

• Profile 7: compresses the IPv4/v6/UDP-Lite/RTP header [108],

• Profile 8: compresses the IPv4/v6/UDP-Lite header [108].

The ROHC header compression mechanism uses profiles to identify the compressedheader. The compressor supports one or several ROHC profiles(the profiles define thenature of the header that will be compressed). During the link setup, the compressorand the decompressor negotiate the profiles, which they bothcan support, and negotiatesome ROHC link parameters.

4.4.3 ROHC Negotiation

The first phase of the ROHC protocol is a negotiation. In this phase the compressor andthe decompressor learn about the different characteristics of the link and the parametersthat will be used for compression. Negotiation is made whileestablishing a channel.A channel is a connection between two nodes. Each channel hasa compressor anda decompressor at each side, with the possibility of it beingeither bi-directional orunidirectional. The present solution [34] is for an Internet network where each IPinterface in the IP layer can have multiple channels, each one being bi-directional orunidirectional.

The present ROHC negotiation establishes the following parameters:


Figure 4.5: ROHC Compression Levels. Each operation mode hasthese three levelsof compression. Each compression level use different packet as for example SO leveluse the UO-1, R-1, UO-0 and R-0 packets.

• MAX-CID: the maximum CID that can be used.

• MAX-Header: the largest header that can be compressed.

• MRRU (Maximum Received Reconstructed Unit): when segmentation is used,it helps to know the maximal size of the segment in bytes.

• Sub-options: there can be zero or several sub-options. Until now, only one sub-option has been specified: the Profile. It informs about the profiles that aresupported.

4.4.4 Compression Levels of the Compressor

ROHC has three compression levels: Initialization and Refresh (IR), First Order (FO)and Second Order (SO). Each compression level in each operation mode uses differentheader types, as shown inside the octagons in Figure 4.5. Forward and backward1

transitions to the different compression levels depend on the operation mode; there arethree operation modes. The compressor always sends the header format packet that fitsthe information needed for decompression. The size of the compressed header dependson the compression level and the header information required by the decompressor. Inthe first level of compression IR, the header size is between 48to 130 bytes; In theFirst Order, the compressed headers have a size between 3 to 84 bytes. In the lastcompression level (SO), the header can be compressed up to just 2 bytes.

1From now onwards, for ROHC, let us assume that going forward or lower means going to a statewith better compression efficiency and going backwards or upper means transiting to a state with worsecompression efficiency.


4.4.5 Operation Modes

The different operation modes allow the compressor to change from one mode to an-other based on the link characteristics and the performancerequirements. Each opera-tion mode has its own behavior.

In Unidirectional (U) mode the compressor operates over links where feedbackis not possible. In this mode, the compressor uses a confidence system to base itsconfidence about decompressor status. This system sends thesame header formatpacket L times to move to the lower compression levels. Each particular type of ROHCheader contains different information about the flow changepatterns and the changegets communicated successfully even if 1 out of those L packets gets received. U-mode also uses two timers and keeps on coming back to initial compression levelswhen timer expires or when there is an update in the header information. One timer isused to come back to IR compression level, Timer-1 (IR-TIMEOUT) and other is usedto come back to FO compression level, Timer-2 (FO-TIMEOUT).

The bi-directional optimistic (O) mode is very similar to the U-mode but the de-compressor can also send negative acknowledgments. This mode does not use the twotimers, but it uses the confidence system, L. The compressor goes backwards to theinitial compression levels on the receipt of negative feedbacks. There are two kinds ofnegative feedbacks: the NACK, that force compressor to go to FO compression level,and the STATIC-NACK that forces it to go to IR compression level, see Figure 4.5. Ifthe compressor receives a header that will update the entirecontext, or if a SO packetcannot communicate the changes, then it goes backwards to the FO or the IR level ofcompression.

The bi-directional reliable operation (R) mode works only with the acknowledg-ments received from the decompressor. Each time the compressor receives an ACK orNACK, the compressor changes the compression level. It goes to the IR compressionlevel if a STATIC-NACK is received, see Figure 4.5. Here, a secure reference principleis also enforced in both compression and decompression logic. The principle meansthat only a compressed packet carrying a 7 or 8-bit CRC can update the decompressioncontext and be used as a reference for subsequent decompression.

4.4.6 ROHC Decompressor

The decompressor has a state machine based on the context state (see Figure 4.6). Thedecompressor has three states. Initially when there is no context, or when the contextis lost, the decompressor stays in No Context (NC) state in which only the IR headerformat packets are decompressed and any other header formatpacket is dropped. Thedecompressor changes to Full Context (FC) state as soon as correct decompressionof a header takes place (verified by CRC) or if the context is established. The StaticContext (SC) state is not reached except when there is an error and the dynamic part


Figure 4.6: ROHC Decompression Levels.

of the header is lost. The decompressor then waits in U-mode for a timer to expire inthe compressor. In the other modes it sends a NACK to the compressor for getting aFO compression level packet.

The decompressor uses a “k out of n” failure rule, where k is the number of packetsreceived with an error in the last n transmitted packets. This rule is used in the statemachine of the decompressor in order to assume the damage of context and to moveto the downward states after sending a NACK to the compressor,when bi-directionallink is used.

4.4.7 Mode Transition

Each time the decompressor wants to work in a new operation mode, it starts the modetransition by sending an ACK/NACK with mode parameter bits setto the new opera-tion mode. During transition, the compressor is allowed to work only in the first twocompression levels, all the packets sent contain a CRC to verify the information. Eachof the compressor and the decompressor keeps two control variables: Transition andMode, and any new request for transition is denied till current transition gets com-pleted. To finish the transition, an ACK with the valid sequence number and the newoperation mode has to be received by the compressor, if it is not the case, the Transi-tion variable keeps the pending value and Mode variable keeps the old value. Also, toinitiate the transition to the R-mode, the context must have been established betweenthe compressor and the decompressor. For the other transitions, the decompressor canstart the transition mode at any moment.

In Figure 4.7 we can see the general behavior of ROHC in every operation mode.The size of original header of IPv6 is 40 bytes shown as a dashed line in Figure 4.7.The solid line indicates the size of the compressed headers.The compressor alwaysstarts in the U-mode and the bigger headers seen in Figure 4.7are the IR packets,which are sent periodically in the U-mode to refresh static information in the contextof the decompressor.

The mode transitions can also be seen in Figure 4.7 and it can be noted that duringmode transition, the compressor cannot send the smallest compressed headers that are


Figure 4.7: ROHC compression. Illustration of Operation Modes (U, O, R), TransitionModes and the use of feedback with small error.

of SO compression level.We notice the difference between O-mode and R-mode and observe the increased

use of feedback channel in the latter. The R-mode and O-mode show more com-pression efficiency because there are no timers as in U-mode that force the sender toregularly send big headers. Moreover, R-mode does not have the confidence system(L), as in U and O modes, and it relies totally on the feedback channel. Nevertheless,the slight compression advantage obtained from not sendingthe large ROHC headersL times might be lost in the R-mode because of larger R-mode packets, due to largerCRC, used in the SO state.

4.5 ROHC Implementation Platform

In order to investigate the working of ROHC with UMTS we implemented ROHC overa FreeBSD platform. We have built a simplified model of the UMTSradio link, whichis a simulation of the error conditions that prevail in the cellular link. In our studies wemeasure the response time, the transfer rate and the robustness of the system.

4.5.1 ROHC Implementation

The FreeBSD platform for ROHC is composed of two computers linked by a PPPoEuser mode channel. The PPP protocol allows a communication between these twocomputers, PPP includes:

• The LCP (Link Control Protocol) Negotiation protocol, to establish and config-ure the link and to negotiate the connection parameters.

ROHC Implementation Platform 69

• Optionally, the authentication protocols.

• PPP uses a network protocols family, the NCP (Network ControlProtocol) Pro-tocols group to establish and configure the networks layer protocols like IPCPand IPv6CP, where we have included the ROHC header compression negotiationas specified in RFC 3241 (ROHC over PPP).

Each side of the PPP channel will have a ROHC entity. Each ROHCentity hasboth the compressor and the decompressor. The ROHC compressor function needs anIP packet and a context as input and it outputs the compressedROHC packet. TheROHC compressor function uses the context space to store information regarding con-text flows. The receive function is called from the decompressor function of the sameside. While receiving a packet if the decompressor recognizes it to be a feedbackpacket then it can pass it to the compressor of the same node.

The ROHC decompressor function needs a ROHC packet and a context as input andit outputs the decompressed IP packets. The ROHC decompressor uses the contextspace to store and retrieve information regarding context flows. The decompressorneeds to send feedback depending on the operation mode of ROHC. This is currentlydone by using a link layer function from the PPP library.

In U-mode the compressor periodically comes back to previous compression lev-els and in the implementation this is done by using the PPP timers from the PPP li-brary. The experimentations were done with a video application using the Darwinvideo server and the Quicktime client using a RTP flow. The client asks the server fora desired video and the server streams the video through a lowbandwidth connectionbetween two FreeBSD computers with ROHC.

The ROHC implementation is made for the profiles 1, 2, 4, 7 and 8, that is theheader compression of flows with: IPv4/v6/UDP/RTP, IPv4/v6/UDP, IPv4/v6, IPv4/v6-/UDP-Lite/RTP and IPv4/v6/UDP-Lite headers. The implementation keeps some ROHCtraces in the log: the sequence of compressed header format packets, the average speed,the number of failures during decompression, the number of missing packets in appli-cation, the compressed header size of each packet and the sequence number.

In IPv4 the checksum is optional (checksum = 0 will mean that it is disabled) andUDP can be used to transport the multimedia flows. With IPv6, the use of checksumis mandatory because IPv6 header does not have a checksum.

4.5.2 Error Simulator

A bit error simulator using the Bernoulli distribution was implemented in our platform.The simulator introduces errors in the packet before decompression.

It is important to mention that Figure 4.7 shows the evolution of the compressionwith small BER and it is used only for comparing compression efficiency. When theerror is small, the O-mode performance is found to be better than the R-mode because


I P / U D P L a y e r

R O H C C o m p r e s s o r

P h y s i c a l L a y e r

R O H C c h a n n e l

R O H C F e e d b a c k

R O H C D e c o m p r e s s o r

P h y s i c a l L a y e r

I P / U D P L a y e r

A p p l i c a t i o n L o s s

R O H CL o s s

N o n c o m p r e s s e dp a c k e t

D e c o m p r e s s e dP a c k e t

X

X

Figure 4.8: The ROHC Architecture has two types of error.

the feedback channel is used less in the former than the latter; but the case is entirelydifferent in a noisy link where the increased use of the feedback channel in the R-modeprovides more robustness.

In general there are two types of packet losses when using ROHC over a radio link.They occur in two types of situations as shown in Figure 4.8. First is when an erroroccurs in the compressed header and the decompressor detects it through the use ofROHC CRC. The decompressor then drops the packet, it does not forward it to theIPv6 layer and when this happens, we call itROHC loss. The other situation is whenan error occurs in the payload, then the decompressor is unable to catch the error andforwards it to the IPv6 layer. When the payload is handed to UDPand since for IPv6the UDP checksum is mandatory, the error is caught and the packet is discarded, wecall this kind of packet loss asApplication loss. This loss can be undesired becausemost sources (video, speech codecs) developed for cellularlinks tolerate errors in theencoded data. Such codecs will want the damaged packets to bestill delivered to themand will not want to enable UDP Checksum.

4.5.3 CRC coverage for Sequence Number (SN)

While implementing ROHC we found some differences between Profile 1 and Profile2 of ROHC that degrade the performance. In profile 1 (UDP/RTP/IP) of ROHC, theRTP sequence number controls the decompression of other header fields and controlsthe working of feedback mechanism as feedback messages carry the sequence numberof the last successfully decompressed headers. ROHC sends the update informationon reception of negative feedbacks and this mechanism is totally based on the value ofsequence number of the last successfully decompressed header at the decompressor,carried by the feedback.

In the compression algorithm for UDP/IP, ESP/IP and IP (Profiles 2,3 and 4) the

ROHC Implementation Platform 71

ROHC mechanism adds a sequence number (SN) randomly generated by the compres-sor itself to control the transmission. We have found in our results that in the operationmodes O and R, which use feedback for ensuring robustness, theerror rate is higherwhen compared to Profile 1.

The reason for this is that for Profile 2, 3 and 4 according to [35], the SN is notincluded in the computation of the CRC. As the SN is not protectedby CRC, therefore,when there is an error in the SN, the decompressor cannot detect it and still uses thecorrupted SN for its feedback mechanism, which relies heavily on the SN for compres-sion efficiency and robustness. This leads to the failure of feedback mechanism thatincreases packet loss and degrades the compression efficiency. We suggest to protectthe SN by CRC in profile 2, 3 and 4 to improve the performance of ROHC for theO-mode and the R-mode.


Chapter 5

Optimization of Robust HeaderCompression over UMTS

Robust header compression (ROHC) [35] is the new standard forheader compressionproposed by the IETF (Internet Engineering Task Force) to compress different protocolheaders. ROHC needs to be configured to adapt to the changes inthe characteristicsof the UMTS radio link and to provide a better compression of IP flows.

In this chapter, we study ROHC and its compression parametersthat are recom-mended as implementation dependent in the ROHC specification. This study exploitsthe trade-off between the robustness and the compression efficiency to optimize the be-havior of ROHC. Further, we study the impact of a recently proposed protocol, calledUDP-Lite, on ROHC and the multimedia applications.

5.1 Introduction

Robust header compression (ROHC) [35] scheme removes the redundant informationfrom the packet headers. It is very useful for the applications such as Voice over IP(VoIP) and the video applications over UMTS. For these applications, the header sizeof the packet header can be between 40 to 120 bytes, while the payload size is of theorder of 100 bytes and can be even 20 bytes or less, considering voice compressionalgorithms and real time constraints. ROHC eliminates, significantly, the redundancyin the header information, reducing the header to a much smaller size of up to 2 bytes.However, the robustness and compression efficiency of ROHC comes at the cost ofincreased complexity. Moreover, the UMTS radio can be a challenging environmentfor ROHC due to high Bit Error Rate (BER) when the link conditions are bad.

In chapter 4, we introduced the characteristics and the behavior of ROHC. ROHCinvolves many parameters and they control the performance of ROHC in terms of com-pression efficiency and robustness. In a real situation, thecompressed header packets

73

74 Optimization of ROHC over UMTS

Figure 5.1: The Compression Parameters. They are localized in the compressor, in thedecompressor and in the different header format packets. Note that at each end of thelink both Compressor and Decompressor are present.

over a radio channel such as UMTS will be confronted with a variable environment thatsometimes could make compression fail. The use of correct compression parametersadapted to these changes will give better robustness and efficiency of ROHC.

In this chapter we study ROHC and its compression parametersover wireless linkssimilar to UMTS. We look at the different compression parameters that could affect theefficiency and robustness of ROHC. The study is aimed at optimizing and improvingthe ROHC scheme in order to achieve better efficiency and robustness over wirelesslinks such as UMTS. This work was done in collaboration with Ana Minaburo duringand after her PhD thesis, and has been the subject of common publications [97, 98, 99].

5.2 ROHC compression parameters and schemes

The value of the compression parameters of ROHC that determine the efficiency androbustness are not defined in ROHC specification. The parameters are not negotiatedinitially, but are stated as implementation dependent. Thecompression parameters, seeFigure 5.1 and some schemes used by ROHC are described as follows:

• L: In U-mode and O-mode the ROHC compressor uses a confidencevariable (L)in order to ensure the correct transmission of header information. This meanssending the same header format packet of each compression level, at least Ltimes in the first levels (IR and FO) before transiting to SO compression level.If even a single packet reaches the decompressor the information gets communi-cated.

• Timer-1 (IR-TIMEOUT): In U-mode, the compressor uses this timer to return tothe IR compression level and periodically resends static information because ithas no way to get any feedback about the errors which may occurat the decom-pressor side.

Configuration of ROHC 75

• Timer-2 (FO-TIMEOUT): The compressor uses another timer in U-mode to gobackwards to the FO compression level if the compressor is working in the SOcompression level.

• Sliding Window Width (SWW): The compressor while compressing header fieldslike Sequence Number (SN) and Time-stamp (TS) uses W-LSB encoding, de-scribed below, that uses a Sliding Window of width equal to SWW.

• Window based Least Significant Bits (WLSB) encoding: This scheme is used tocompress those header fields whose change pattern is known. When using thisencoding, the compressor sends only the least significant bits (LSBs). The de-compressor uses these bits to construct the original value of the encoding fields.The number of bits required to send the changes depends on theSWW of theSliding Window, which is maintained by the compressor. All the SN values, thatthe compressor believes have not reached the decompressor,are to be used andare kept in the Sliding Window. Thus, a larger SWW will requirelarger num-ber of bits to be sent in the header format packets because only one value in thewindow should have those LSB SN bits for correct decompression.

• k and n: The ROHC decompressor uses a “k out of n” failure rule, where k is thenumber of packets received with an error in the last n transmitted packets. Thisrule is used in the state machine of the decompressor to assume the damage ofcontext and move downwards to a state after sending a negative acknowledgmentto the compressor, if bi-directional link is used. The decompressor does notassume context damage and stays in the current state until k packets arrive witherror in the last n packets. The k1, n1 values are used to assume dynamic contextdamage and k2, n2 to assume static context damage.

• MODE: There are two bits in the header format packets to define the operationmode in which the compressor and the decompressor work. There are three-operation modes, U, O and R mode defined in [35] and discussed in chapter 4.

5.3 Configuration of ROHC

We analyzed the results and investigated the role of the ROHCcompression parametersfor IPv6 flows. In order to evaluate efficiency, throughput and to estimate robustness,our implementation stores the statistics of each connection.

The parameters kept for each end of the link are: number of packets sent and re-ceived, size of each packet sent, size of header, size of compressed header, ROHCloss1, Application loss and the type of compressed headers sent. The formats of com-

1See section 4.5.2 for the definition.


pressed ROHC headers are defined in [35]. Their use depends onthe variation of theoriginal header and the quality of the link.

We use an IPv6/UDP/RTP video stream packet generator, unless explicitly speci-fied, that sends packets in which the SN and TS field of the RTP header change withregular patterns. In our tests we have used the average payload size of 200 bytes anda RTT (Round Trip Time) of around 100ms. It may be noted that as IPv6 is used theUDP checksum becomes mandatory in our RTP application, adding 2 extra bytes tothe ROHC compressed header.

5.3.1 Robustness

The BER of a radio link can corrupt the compressed headers and can cause loss ofcontext synchronization. A robust scheme should have errormanagement and errordetection techniques and it should also have fast recovery methods to avoid prolongedlosses due to relatively long RTT. ROHC uses CRC to detect theseerrors and discardsthe packets whenever CRC check fails. The error in the links also leads to the lossof packets carrying update information. All these errors sometimes cause the loss ofsynchronization between the context of the compressor and the decompressor; thissituation is known as context damage.

Context damage can occur in two cases. First, when CRC is unable to detect dam-age in the packet and it corrupts the context. Second, when anupdate takes place andcould not reach the decompressor due to bursts of error.

The values of k and n parameters have a high influence on the robustness of ROHCbecause these parameters are used to detect context damage.In a contrary situation,the errors in the link can cause consecutive loss and the decompressor will incorrectlyassume context damage depending on k. Detection of context damage, whether corrector incorrect, will make the decompressor go up to a state where it will unnecessarilydiscard a large number of packets and will continue to do so until an update from thecompressor arrives. A large number of packets will be lost when the value of RTT isrelatively high. The result is worse in U-mode where feedbacks are not possible andpackets will continue to get lost until the timer expires in the compressor to send theupdates.

The possible solution will be to take a large value of k and n but this implies morecomputational efforts and large storage space, as the compressor will need to knowwhether in the k packets out of last n packets, a CRC failure has occurred. A largervalue of k will also mean that the decompressor will have to wait each time for kpackets to know if context damage has occurred and this will cause all the packets tobe lost during that time.

In Figure 5.2 we have shown the results of our implementationfor different valuesof k and BER in the three ROHC operation modes. As we can see in Figure 5.2, thecase is different in each operation mode. Though in all the modes the error rate is high


for small values of k because when the value of k is small, the decompressor incorrectlyassumes context damage and then starts discarding packets until an update packet ar-rives. This error rate decreases fast with the value of k because the probability of anumber of consecutive packets being in error for a given BER, falls exponentially withthe number of packets. In U-mode the error becomes stable after a value of k; furtherincreasing k does not make any difference. This happens because the decompressorin U-mode will have to wait until a timeout occurs, and whether it detects a contextdamage early or late it makes no difference. In O-mode and R-mode the error firstdecreases down to a minimum and then starts increasing with the value of k becauseas k increases the compressor has to wait for more CRC fails to occur before detectinga context damage and communicating it to the compressor through feedbacks. In asituation where BER is lower than 10−3, the error in O-mode does not rise much withthe value of k because the probability of context getting damaged decreases with BER.In R-mode the error is lowest and it does not rise much with the value of k because inR-mode the compressor always uses a 7 or 8 bit CRC in packets that update the contextand hence, context damage is less likely in R-mode. In R-mode the compressor alsouses some packets which do not have any CRC bits and they do not update the con-text, this also decreases the number of packets dropped and reduces the overall erroras compared to other modes.

The values of k and n do not affect compression efficiency hence, these valuesshould be chosen keeping only robustness in mind. In Figure 5.2, we have taken a valueof n equal to k + int(k/8) to allow for the case when erroneous packets pass through theCRC check, especially in header format packets with 3-bit CRC that detect errors onlywith a probability of 7/8. The value of k and n used to assume static context should bekept larger than that used for assuming dynamic context damage because probabilityof the former is significantly low as compared to that of latter. Based on our results wesuggest that in U-mode the value of k should be kept larger andit would be better ifthe decompressor does not move to the lower states even if a context damage occursand keeps trying to repair the context. In O-mode and R-mode the value of k may bechosen between 8 to 20 because the error is lowest between these values.

5.3.2 Compression Efficiency vs. Robustness

Some parameters, which affect the robustness, also affect the compression efficiency.In some cases, compression efficiency is reduced when high robustness is achieved. Itwill be desirable to configure ROHC such that it performs at the best compression ef-ficiency and with a high robustness. We will use Average Compressed header Length(ACL) introduced by [137] as our benchmark for making comparisons for the com-pression efficiency.


0 10 20 30 40 50 60 70 80

1 2 4 6 8 12 14 16 20 30 50 70 90

RO

HC

loss

(%

)

Value of k

U-modeO-modeR-mode

(a) BER = 0.001

0

20

40

60

80

100

0 10 20 30 40 50 60 70 80 90

RO

HC

loss

(%

)

Value of k

U-modeO-modeR-mode

(b) BER = 0.005

Figure 5.2: Percentage loss of packets at ROHC layer for different values of BER, kand operation modes.


4

6

8

10

12

14

16

18

0 200 400 600 800 1000

AC

L (b

ytes

)

IR-TIMEOUT (No. of packets)

FO-TIMEOUT = 30FO-TIMEOUT = 60FO-TIMEOUT = 90

FO-TIMEOUT = 120

Figure 5.3: Average compressed header length in U-mode withvarying IR-TIMEOUTand FO-TIMEOUT. The value of timers is in number of packets.

5.3.2.1 Timers

In U/O mode the compressor maintains robust behavior by sending header formatpackets L times and in U-mode it also uses IR-TIMEOUT and FO-TIMEOUT to re-turn to one of the initial compression levels and resends packets periodically with moreinformation.

The values of IR-TIMEOUT and FO-TIMEOUT determine compression efficiencyin U mode. Compression efficiency decreases when large headers are sent with morefrequency, i.e., when the value of IR-TIMEOUT and FO-TIMEOUTare low and thevalue of L is large. Thus, in order to have good compression efficiency a solution isto choose a value for IR-TIMEOUT and FO-TIMEOUT as large as possible and thevalue of L as small as possible. We assume that large values ofL more than 10 will notbe considered as this will reduce the compression efficiencysignificantly. We show theeffect of increasing IR-TIMEOUT and FO-TIMEOUT with L = 5 in Figure 5.3.

We have to determine the value of IR-TIMEOUT and FO-TIMEOUT toget therequired robustness because, in U- mode, the feedbacks are not possible and the prob-ability of context damage increases at a high rate with time.The values of the twotimers thus, depend on the probabilities of dynamic contextgetting damaged for FO-TIMEOUT and static context for IR-TIMEOUT. The probability of damage is lowerfor static context in comparison to that of dynamic context since, most of the timestatic information remains constant, the CRC used to detect errors is larger (8 bits) andgenerally no update takes place for static values. The compressor is designed to workin SO compression level most of the time thus, packets carrying just dynamic infor-


0

2

4

6

8

10

12

0 200 400 600 800 1000

RO

HC

loss

(%

)

IR-TIMEOUT (No. of packets)

FO-TIMEOUT = 30FO-TIMEOUT = 90

(a) BER = 0.001

0

10

20

30

40

50

60

0 200 400 600 800 1000

RO

HC

loss

(%

)IR-TIMEOUT (No. of packets)

FO-TIMEOUT = 30FO-TIMEOUT = 90

(b) BER = 0.005

Figure 5.4: ROHC loss for different values of BER and timers inU-mode with k = 10and n = 12. The value of timers is in number of packets.

mation are expected to pass through the channel most of the time. This makes themmore vulnerable to error and moreover they carry a small CRC (3 bits) that may not beable to detect error sometimes and thus can cause dynamic context damage with sig-nificant probability as compared to static context damage. After comparing the casesfor static context damage and dynamic context damage, we suggest that the values oftimers be chosen such that dynamic information is refreshedmuch more often thanstatic information.

We thus compare the robustness by looking at the values of error rate for differ-ent values of BER, IR-TIMEOUT and FO-TIMEOUT. We choose two values of FO-TIMEOUT that are 30 packets and 90 packets for our analysis, because it can be seenin Figure 5.3 that when FO-TIMEOUT is increased from 30 packets to 90 packets, thecompression efficiency increases as ACL decreases, but increasing the value furtherfrom 90 does not decrease ACL significantly and a larger value of FO-TIMEOUT isnot even desired because the probability of dynamic contextdamage is high and thecompressor should keep going to FO compression level at an interval as small as pos-sible. In Figure 5.4 we show the results obtained with our implementation and findthat increasing the value of timeouts increases ROHC loss. However, decreasing thosevalues not necessarily decreases ROHC loss always because it may mean that largerheaders are sent more number of times and since large headersare more prone to er-rors, they will cause more loss of packets and thus, reduced robustness. Based on ourresults we suggest the value of IR-TIMEOUT to be taken between200 and 400 packetsif a value of FO-TIMEOUT be chosen around 90, and if the value of FO-TIMEOUTis chosen around 30 packets then even larger values of IR-TIMEOUT will maintainrobustness as in Figure 5.4.


5.3.2.2 Optimistic Approach

In order to communicate the information efficiently in U/O mode, the compressor usesanother technique, called “Optimistic Approach” [35], in which it sends a particularheader format packet L times. The probability of information being communicatedthus increases when the value of L increases. A good value of Lcan diminish thechances of packets loss. On the other hand, if the update is not communicated tothe decompressor due to error bursts in the link then contextdamage occurs and alarge number of packets are lost. The problem diminishes if avalue of L is chosenwhich is sufficiently large that even if an occasional burst of error happens it is able tocommunicate the information.

Compression efficiency and throughput clearly decrease as larger headers are com-municated more times. Thus, the value of L cannot be high. We tested our imple-mentation, this time using a real video stream with the help of VLC player, in U andO-mode for different values of L and BER, see Figure 5.5. We noticed that the ROHCloss was slightly higher in the case of video stream as compared to the IPv6/UDP/RTPpacket generator. This is because the value of TS in the RTP header of the real videostream changed more irregularly than our packet generator.This caused more and big-ger update ROHC headers to be sent frequently. That is turn increases the ROHC lossbecause a bigger packet has a higher probability of being corrupted for a given BER.

In U-mode when BER is high, then L should be kept high, i.e., L = 10, to minimizethe ROHC loss, as shown in Figure 5.5. When BER is low, then L = 3 isa goodsolution for high efficiency and robustness. However, when using O-mode the resultsare different. When compared to U-mode, the value of ROHC lossis less for O-modebecause of the use of feedback. When BER is high, the value of L = 5gives goodperformance with O-mode and the value of L = 3 can be used when the BER is low.Moreover, when RTT is low, the error in the context can be quickly corrected by usingthe feedback and the value for L may be taken as 1, but when RTT is long then Lshould be kept higher to communicate the update with more confidence. The choice ofthe parameter L is further discussed in Section 5.4.

5.3.2.3 Sliding Window Width (SWW)

The SWW is another important parameter for compression efficiency as already shownby Wang et al. [137]. With a larger SWW, the ROHC compressor needs more bits torepresent LSB bits. Also a large SWW needs more storage space and more computingefforts. But, it helps to improve robustness because even when there are consecutivelost packets equal to SWW - 1, compression still works well.

In [137], Wang gives the effect of increasing SWW for U-mode and showed that inthis mode ROHC works well if a SWW of 14 is taken for the case of IPv4/UDP/RTP.We continue to compare and analyze the effect of increasing SWW in O-mode and R-mode. The O-mode and R-mode are different from U-mode becausethey use feedback


0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8

1 2 3 4 5 6 7 8 9 10

RO

HC

loss

(%

)

L

U-modeO-mode

(a) BER = 0.0001

0

10

20

30

40

50

60

70

1 2 3 4 5 6 7 8 9 10

RO

HC

loss

(%

)

L

U-modeO-mode

(b) BER = 0.005

Figure 5.5: Percentage loss of packets for different valuesof L. When k and n equals10 and 12 respectively, IR-TIMEOUT equals 300 packets and FO-TIMEOUT equals40 packets.

Dynamic Negotiation for ROHC 83

3

4

5

6

7

8

9

0 14 50 63 100 150 200

AC

L (b

ytes

)

SWW

U-modeO-modeR-mode

Figure 5.6: ACL in different operation mode. Where L = 5 and IR-TIMEOUT equals300 packets FO-TIMEOUT equals 40 packets.

channel. In O-mode and R-mode, the decompressor can send the ACK with the SNvalue of the last successfully decompressed header. The compressor thus comes toknow about the SN values that have reached the decompressor and shrinks the slidingwindow. However in O-mode, the ACKs are optional and normallyare not sent hence,ACKs normally shrink the sliding window only in R-mode.

In R-mode, the number of bits available for SN in the SO state packets is 6 in R-mode type-0 packet (R-0) and 7 in R-mode type-0 packet with CRC (R-0-CRC), unlikeU/O mode packet type-0 (UO-0) that has only 4 bits. Hence, onemight conclude thatfor R-mode, the value of SWW can be chosen larger than 14, but above a particularvalue of SWW the ACL will increase as it does in case of U/O-mode.However, inFigure 5.6 we can see that increasing SWW window in R-mode has noeffect on com-pression efficiency. This is due to the fact that R-modeadaptsits SWW depending onfeedback. The ACKs always shrink the sliding window and increasing SWW producesno effect. But, increasing SWW has an effect on O-mode because ACKs are optionaland generally not enabled, and in U-mode because ACKs are not possible.

5.4 Dynamic Negotiation for ROHC

The present negotiation [34], as explained in chapter 4, does not take into account thecharacteristics of the radio link layer and the possible constraints in the decompressor.Over a serial link, the problems are avoided because the transmissions are not disruptedby the different possible errors. Whereas, over a radio link there are certain factors


like transmission delay, the residual errors and the bit-error-rate (BER) [10] that candisrupt the transmission. Moreover, these parameters can change their value and thevariation can be high. Thus, ROHC negotiation must be based on the channel state. Thecompressor needs to know the updated value of these channel attributes to re-evaluatethe initial negotiated channel state. Especially, when U and O-mode are used becausethese modes use the L parameter to increase the robustness ofcompression. As seenin section 5.3, there exists a trade-off between ROHC’s robustness and efficiency thatdepends on the channel state. ROHC’s performance can be optimized if the channelstate is known.

We propose a negotiation procedure that involves an information exchange be-tween the Radio Resource Control (RRC) layer of UMTS and ROHC (compressor anddecompressor). The negotiation begins by requesting the radio parameters from theradio link to the RRC layer through the control link between thePDCP and the RRC,see figure 4.2 of chapter 4. When the compressor has these parameters, it sends thenegotiation packet to the decompressor, that in turn, sendsits parameters through anacknowledgment packet.

An update function will be created when using ROHC; this function will receive thevalues of the radio link parameters from the RRC layer. This negotiation is necessarybecause in the radio network the terminals are able to know the parameters of only thereceiving radio link, it is thus obligatory for each part to send the radio parameters ofits receiving link to the other part, see Figure 5.7.

In the negotiation packet, the following information will be sent from the compres-sor to the decompressor:

• MAX-CID: the maximum CID that can be used by the compressor.

• MAX-Header: the largest header that can be compressed.

• MRRU (Maximum Received Reconstructed Unit).

• ROHC Profiles supported by the compressor.

• BER in the compressor side. The BER value is coded to 4 bits according to theUMTS specification [10].

• Transfer delay in the compressor side. This value is coded to 6 bits mapped bythe different time limits of the delay in the radio link according to [10]. Thisvalue can also be inferred, with the use of feedbacks, by noting the time ofdeparture and arrival of the packets.

The decompressor will answer with an acknowledgment packet, reporting the aboveinformation and whether it agrees to some of the informationsent by the compressor.If some of the values are unacceptable by the decompressor, it can communicate its

Dynamic Negotiation for ROHC 85

Figure 5.7: Actual and Proposed ROHC Negotiations. The proposed negotiation givesthe opportunity to use the accepted parameters for both sides and also to receive infor-mation from the RRC to know the updated link variables.

possibilities by the acknowledgment packet. In case the decompressor is not able towork in any profile of the compressor, Profile 0 (Non-Compression) is used.

After the negotiation, a dynamic updating procedure is triggered in the RRC to in-form the PDCP layer of the new values of the BER and transfer delay through the con-trol link between the PDCP layer and the RRC. When the values of the radio channelattributes change enough to update the parameters, then thecompression and decom-pression variables (L, timers, SWW, k, n) must be updated. Using our mechanism, thecompressor and the decompressor are certain to know the updated QoS link param-eters. This update is frequently (order of magnitude≈ 1 second) made in the RRC,which will inform the compressor and the decompressor if thevalues have changed.

Knowing the radio link parameters will help to determine thevalue of L, SWW andtimers in the compressor, and the values of k and n in the decompressor. If required,the initial values will be modified in order to improve the performance of ROHC bytuning its efficiency and robustness.

5.4.1 Dependence of the ROHC parameters on link characteristics

The dependence of the ROHC implementation parameters on link characteristics canbe seen in detail in section 5.3. The objective is to test whether the transmission errorin the link is reduced when the value of L is increased, while taking into account thecompression efficiency because efficiency reduces when L is increased. We use ACL


(Average compressed header length ) as our benchmark for compression efficiency sothat if ACL is high then efficiency is low and vice versa.

As follows from section 5.3, for a low BER, the compressor can use a low valueof L and a high value of timers in order to work at maximum compression efficiencywithout compromising on robustness. When BER is high, the compressor has to workwith high robustness otherwise specially in U-mode a long loss event can occur. InO-mode, the decompressor can send a negative acknowledgment when an error is de-tected. These negative feedbacks will make an automatic transition to the lower com-pression level in the compressor.

When incrementing the value of L, the compression efficiency in the link is decre-mented because each time the compressor goes downwards to FOor to IR compressionlevels, the big header format packets are sent L times. On theother hand, it will try torecover the flow if there is an error. Moreover, it is important to see that the losses alsodepend on the size of the header2.

5.4.2 Optimization of ROHC performance

The optimal value of ROHC parameters, such as L, depends on the link parameterslike BER and should adapt dynamically to the changing link parameters. Instead, ifthe compressor keeps a fixed value of L, for example L = 3, and since in a radio linkthe error is (often quickly) variable, a high BER may lead to many packets being lostdue to ROHC.

Instead, a simple optimal algorithm can be used that dynamically adapts the valueof L such that, for a given BER, the point lies close to the lower right side of the groupof curves shown in Figure 5.8. Thus, reducing the ROHC loss ingeneral as can be seenin the figure when the value of L is variable.

Figure 5.9 shows the average header length (ACL) of the headersent in U-modeand O-mode with different error values in the link. In U-modethe ACL is directlyproportional to L, with L=10 we send 10 times the IR and FO compression levelspackets to reinitialize the context. The value of BER does notaffect the value of ACLbecause compressor always sends the same number of IR and FO level packets if thevalue of L and timers is fixed3. Thus, a smallest possible value of L should be chosenfor the U-mode that still remains optimal as discussed above.

In O-mode we can see that ACL value increases with the value of BER becauseeach time compressor receives a STATIC-NACK/NACK then either IR or FO headerpackets, that are bigger in size, are sent L times. Moreover,a high value of L maynot be needed as it uses feedback. We found that the value of L =5 is optimal in ourexperiments for O-mode.

2As remarked before, a bigger packet has more chances of beingcorrupted, and discarded due toROHC CRC fail, for a given BER.

3In U-mode it does not know if an error occurred or not.

Performance Improvement of Multimedia flows by using UDP-Lite 87

Figure 5.8: ROHC loss with different values of L and BER.

In fact, the optimal configuration of O-mode also depends on the value of RTT.When RTT is low and an error occurs, the feedback will arrive inshort time and thecompressor will quickly send the update packets to correct the error. However, if RTTis high then lot of packets will be lost before the compressorsends the update packets.We would like to study the optimization of O-mode, for different values of RTT, asfuture work.

5.5 Performance Improvement of Multimedia flows byusing UDP-Lite

The use of delay sensitive multimedia applications over lowbandwidth noisy links,such as those in wireless networks or cellular networks, hasbeen shown to have a badperformance. Some studies have been done [58, 124] to adapt the voice and videocoders to the bit error rate of network links. On one hand, thecoders are adapted tosend information with a high quality even if some of this information gets corruptedand on the other hand, the lower layers such as transport and link layer use a strictintegrity control (checksum or CRC) to drop corrupted packets.The lower layers,instead, should send the corrupted packets to the higher layer and take the benefits ofthe error resilience property of video and voice coders.


Figure 5.9: The ACL of the Static vs Dynamic configuration for different values of Land BER. Note that 2 bytes are extra because UDP checksum is mandatory for IPv6.

In the case when ROHC is used over low bandwidth and noisy links, it saves band-width and reduces packet loss by decreasing the probabilityof header corruption. Inaddition to reducing the header size, the ROHC header compression is robust fromtransmission errors. Nevertheless, the packets can still be dropped if errors occur inpayload, called application loss, and is described in chapter 4. For example, this hap-pens when the checksum is enabled in the UDP layer, that in turn drops the corruptedpacket.

One solution to this problem is to disable the UDP checksum. With IPv4, thechecksum is not mandatory, the data even with corrupted bitsis transmitted to the ap-plication layer if the checksum is disabled. However, when UDP is used with IPv6, theUDP checksum is mandatory. To counter this problem, the applications can use errorresilient coders and in addition can use UDP-Lite protocol [85] which allows applica-tions to have partially damaged payload delivered rather than discarded. Multimediaapplications will benefit from the use of both ROHC and UDP-Lite. Both mechanismsreduce the number of packets dropped and improve the qualityof multimedia flows.

The compression of UDP-Lite header with ROHC has been proposed [108] by theROHC working group in the IETF (Internet Engineering Task Force). We developedthis proposition and compared it with our UDP implementation. We take the H.263[67] codec as reference for the discussions in the followingsections. H.263 is a videocodec that was standardized by the International Telecommunication Union’s Telecom-munication Standardizations Sector (ITU-T) for low bit-rate videoconferencing appli-cations. The codec was designed for circuit switched technologies but soon becamepopular with applications using packet switched technology (IP). Its basic principlesare similar to those of MPEG codecs, discussed in chapter 3.

Performance Improvement of Multimedia flows by using UDP-Lite 89

Figure 5.10: Checksum coverage strategies.

5.5.1 Checksum coverage levels

To verify the performance of ROHC and the number of dropped packets in the appli-cation layer, while using the UDP-Lite protocol, four strategies of checksum coverageare used for IPv6 flows. Figure 5.10 shows the coverage in the different cases:

• The first strategy is the complete coverage of the packet with the checksum. Inother words this strategy means using UDP.

• The second strategy is the coverage of the header IP/UDP-Lite/RTP/payload-header and a part of the payload, this strategy is important because the videocoder puts the most important information at the beginning of the packet. Here,the payload header for H.263 is covered with some data payload.

• The third strategy covers the header IP/UDP-Lite/RTP/payload-header. All theprotocol stack headers from the IP to the application layer header is covered.

• The last strategy covers only the IP/UDP-Lite header, it iscalled zero percentbecause payload is not covered by the checksum. This is the minimal headerthat must be covered when UDP-Lite is used [85].

In strategy 1 only packets without error are delivered to theapplication layer. Nev-ertheless, for strategy 2, even if error occurs in the packet, the application gets thepacket and use it to reduce the error impact in the global quality. The strategy 3 isuseful for ROHC layer, because only the header is covered by checksum, the decom-pressor is able to verify all the compressed header information and it will be confidentabout the context information. The same principle could be applied for strategy 4, butthe usability of the RTP and payload header is not assured. Therefore, packets thatmight not be useful at all, might consume processing resources at the decompressionside as well as the networking resources.

The strategies are summarized in Table 5.1 and are tested using two different videoservers: VLC and Darwin, both servers code the video in frames of different sizes4.

4This is because of their own specific implementations


Table 5.2 shows the results of the checksum coverage with theaverage header size ofVLC and Darwin coders.

Strategies change the manner in which errors affect the packets. When an erroroccurs in uncovered data, the packet is sent to the application and in this case thedecision is taken by the application to see if the packet is useful. If error occurs in thedata covered by the checksum, the packet is dropped. There isone more case that if theerror occurs in the header and ROHC could not correct it, thenthe packet is dropped bythe ROHC. Table 5.1 shows the possibilities for dropping packets within the strategiesof checksum coverage in case of error.

Table 5.1: The strategy in relation with the checksum coverage.

Strategy 1 Strategy 2 Strategy 3 Strategy 4UDP 100% UDP-Lite

50%UDP-Lite25%

UDP-Lite 0%

ChecksumCoverage

Header(IP/UDP/RTP/payloadheader) + partof payload

Header(IP/UDP-Lite/RTP/payloadheader) + partof payload

Header(IP/UDP-Lite/RTP/payloadheader)

Header(IP/UDP-Lite)

The headeris corrupted

Loss of packetby ROHC




The Payloadis corrupted

Loss of packetby UDP

Loss of packetby UDP

Sent to the ap-plication

Sent to the ap-plication

Table 5.2: Checksum Coverage within different Video Coders.

Video Coder VLC Darwin

Strategy 100% 50% 25% 0% 100%50% 25% 0%Average Packet Size 1376 392(bytes)Coverage (bytes) 1376 712 132 48 392 220 132 48IP/UDP-Lite Header 48 48(bytes)RTP Header (bytes) 12-72 12-72Payload Header (bytes) 4, 8, 12 4, 8, 12(Mode: A, B, C)

Conclusion 91

5.5.2 Performance Improvement

Tests are made with an IPv6/UDP/RTP flow and an IPv6/UDP-Lite/RTP flow with dif-ferent error levels on the link to compare the four strategies and to see the improvementof each one compared against UDP. Moreover, it should be noted that we used a profilethat only compressed the IPv6/UDP and IPv6/UDP-Lite headers and RTP headers arenot compressed.

Figure 5.11 shows the loss in the ROHC Unidirectional and Optimistic modes forthe four strategies. It can be observed that the packet loss decreases every time whenthe checksum coverage is reduced.

The improvement in terms of packets loss is more obvious whenthe error in thelink is higher because the loss varies from nearly hundred percent to twenty percent.In Optimistic mode we observe a slightly better performance, as compared to the Uni-directional mode, especially when strategy 4 is used because, in case of errors, thefeedbacks are able to notify the compressor more efficientlythan the timers from Uni-directional mode. In strategies other than the strategy 4, the behavior is almost similar.

Note that, the UDP-Lite global performance5 is better than the UDP performancebut the ROHC compression efficiency is better when UDP is used; this phenomenon isa consequence of the bigger ROHC header formats in case of UDP-Lite. The differenceis that UDP-Lite also sends the fields like the checksum coverage and the checksum.

Figure 5.11 shows the case when the error of the link is very high (0.005). It can beseen that the Unidirectional mode is blocked and the application doesn’t receive anyinformation, therefore almost all packets are lost when strategy1 or UDP is used.

Figure 5.12 shows ROHC loss that is the number of packets dropped by the ROHClayer. These are the packets that are lost because ROHC is notable to decompressthem. In U-mode, the difference in performance between UDP and UDP-Lite, withUDP-lite performing worse, is clearer only when BER is high. This is because ROHCheaders for UDP-Lite are slightly bigger. Otherwise the performance for both is simi-lar.

Figure 5.12(b) shows ROHC loss in Optimistic mode. In O-modeboth, UDPand UDP-lite, perform similar because acknowledgments prevent the compressor fromsending large headers regularly. In addition, it can be seenthat the global performanceis better than U-mode due to this reason.

5.6 Conclusion

In this chapter, we have seen the importance of link parameter configuration and adap-tive negotiation for the performance of ROHC over a radio link. We notice that thesystem shows generally the same response when the error in the link is relatively small

5Corresponding to the trade-off between compression efficiency and loss rate


0

20

40

60

80

100

0 0.00001 0.0001 0.0005 0.001 0.003 0.005

Loss

(%

)

BER


(a) U-mode

0

20

40

60

80

100

0 0.00001 0.0001 0.0005 0.001 0.003 0.005

Loss

(%

)

BER


(b) O-mode

Figure 5.11: Application loss in the Unidirectional and Optimistic mode in the fourstrategies.

Conclusion 93

0

2

4

6

8

10

12

14

16

18

20

0 0.00001 0.0001 0.0005 0.001 0.003 0.005

RO

HC

loss

(%

)

BER

UDP LiteUDP

(a) U-mode

0

2

4

6

8

10

0 0.00001 0.0001 0.0005 0.001 0.003 0.005

RO

HC

loss

(%

)

BER

UDP LiteUDP

(b) O-mode

Figure 5.12: ROHC loss in the Unidirectional and Optimisticmode.


but when this error increases, the response to the differentvalues of the compressionparameters is different. Moreover, it may not be optimal to just choose the smallestor the largest value for a given compression parameter because there exists a trade-offbetween robustness and compression efficiency. Nevertheless, it is always possible toset a range of values where the transmission error is minimized and the compressionefficiency is maximized.

For the U-mode and the O-mode a compromise has to be made for the choice of L.A fixed value of the compression parameters may lead to bad performance because theradio link characteristics are variable with time. We thus recommend a re-negotiationprocedure that updates the link parameters like BER and transfer delay in order to im-prove the performance of ROHC over radio links by dynamically adapting the ROHCparameters.

We also studied some strategies for multimedia streaming using UDP-Lite. Itwas found that UDP-Lite gives better performance than UDP. Moreover, ROHC com-pressed the UDP-Lite header without any significant degradation when compared tothe compression of the UDP header.

Part II

Video Streaming over High SpeedDownlink Packet Access

95

Chapter 6

High Speed Downlink Packet Access

High Speed Downlink Packet Access (HSDPA) is an enhancement of UMTS networksthat supports data rates of several Mbit/s, making it suitable for data applicationsranging from file transfer to multimedia streaming. In spiteof the fairly high data ratesthat HSDPA offers, the shared downlink radio channel used in HSDPA is a challeng-ing environment for delay- and loss-sensitive applications like video. One of the salientpoints of HSDPA is the use of MAC-layer scheduling to perform resource management,(i.e., bandwidth allocation between terminals), taking intoaccount the radio channelconditions of all users. Such channel-adaptive schedulingmay result in strong band-width fluctuations, causing packet loss and degrading the quality of the received video.In some proposals, additional factors like fairness betweenusers, cell throughput orquality-of-service (QoS) parameters are also considered in the scheduling mechanism.

6.1 Introduction

High Speed Downlink Packet Access (HSDPA) [62, 6, 7, 105] canbe regarded as apacket-based enhancement of UMTS1. It supports data rates of several Mbit/s, mak-ing it suitable for data applications ranging from file transfer to multimedia streaming.Such data rates are (in principle) high enough for supporting the streaming of multi-media flows to several users at a time in a single cell. Nonetheless, due to its sharednature, the radio channel used to transfer data from the basestation to mobile termi-nals remains a challenging environment for delay- and loss-sensitive applications likevideo. One of the main characteristics of HSDPA is the use of MAC-layer schedul-ing to perform resource management (i.e., bandwidth allocation between terminals),taking into account the radio channel conditions of all users. Such channel-adaptivescheduling may result in strong bandwidth fluctuations, causing packet loss and degra-

1The equivalent new technology in CDMA2000 1xEV-DO systems is called High Data Rate (HDR)[25].

97

98 High Speed Downlink Packet Access

INTERNET

GGSN SGSNVideo Server

UMTS CORE NETWORK

UTRAN

RNCBS

UEs

Figure 6.1: UMTS video streaming scenario.

dation in the quality of the received video. Additional factors like fairness betweenusers, cell throughput or quality-of-service (QoS) parameters are also considered insome scheduling mechanisms proposed in the literature.

This chapter presents some background on the HSDPA enhancements and thepacket level HSDPA simulator used for the studies done later. We also present theHSDPA simulation platform that will be used for the studies in the following chapters.The following chapters will focus on the unicast streaming over HSDPA. Figure 6.1illustrates such generic streaming scenario where a mobileuser connects her UserEquipment (UE) to the UTRAN, which in turn is connected to the Internet throughthe UMTS core network. The mobile user present in the UTRAN would stream videoon her User Equipment (UE) from a server in the Internet.

6.2 High Speed Downlink Packet Access (HSDPA)

HSDPA is an enhancement of UMTS that has been designed to meetthe increasingdemands of data and multimedia services. It provides many improvements as com-pared to the Release’99 version of UMTS. Higher data rates andlower delays areachieved using fast and channel-adaptive schemes like Adaptive Modulation and Cod-ing (AMC), fast Hybrid-ARQ (HARQ) and fast scheduling based upon a very shorttime interval of 2 ms. This section presents a brief overviewof the main features ofHSDPA; for a more thorough presentation, see for instance [62, 6, 7, 105].

High Speed Downlink Packet Access (HSDPA) 99

-20-15-10-5 0 5

10

0 10 20 30 40 50 60 70

Rec

eive

d P

ower

(dB

)

Time (s)

(a) 50m

-20-15-10-5 0 5

10

0 10 20 30 40 50 60 70

Rec

eive

d P

ower

(dB

)

Time (s)

(b) 200m

-20-15-10-5 0 5

10

0 10 20 30 40 50 60 70

Rec

eive

d P

ower

(dB

)

Time (s)

(c) 350m

-20-15-10-5 0 5

10

0 10 20 30 40 50 60 70

Rec

eive

d P

ower

(dB

)

Time (s)

(d) 500m

Figure 6.2: Example of received power by UEs (Ped A, 3km/h) atdifferent distancesfrom the Base Station.


6.2.1 Channel Adaptation

A new transport channel called High Speed Downlink Shared Channel (HS-DSCH)has been introduced for HSDPA. HS-DSCH is supported by an auxiliary channel calledHigh Speed Shared Control Channel (HS-SCCH). The goal of the latter is to allow forfast monitoring of the radio channel conditions of all users: every 2 ms, a UE cansend to the base station a Channel Quality Indicator (CQI) overthis control channel.This feedback makes it possible to optimize the transmission by means of channel-adaptive schemes. Thus, the CQI is used by AMC to adapt the coding rate, modulationscheme, and number of codes employed, so that users having good channel conditionsmay be provided with very high data rates. Previously, in UMTS Release’99 systems,a power control mechanism was used in the dedicated channelsto counter channelfading; however, power control finds a limited use in a sharedchannel like HS-DSCH,and therefore it is not used in HSDPA.

6.2.2 Hybrid ARQ

The handling of erroneous data frames has been improved in HSDPA. In UMTS re-lease’99, frames with errors are retransmitted by the RLC protocol layer present in theRNC. In HSDPA, the MAC layer itself can retransmit the erroneous data, and retrans-mission times are reduced as MAC-layer functionalities havebeen moved to the basestation. This also provides fast response times of the channel-adaptive schemes de-scribed above. At the MAC level, fast Hybrid-ARQ is used to retransmit the erroneousframes; UEs in turn do not discard the erroneous frames, but combine them with thesuccessive retransmitted frames using schemes like Chase Combining and IncrementalRedundancy.

6.2.3 Packet Scheduling

HSDPA uses a shared wireless channel and providing resourcemanagement (that is,allocating bandwidth among terminals) is complex due to variable radio channel con-ditions. For example, in Figure 6.2 it can be seen that the channel conditions2, espe-cially for the farther users, may change rapidly. Resource management is performedby a scheduler that may adapt to fluctuating radio conditions. The Transmission TimeInterval (TTI) in HSDPA has been reduced to 2 ms as compared tothe 10, 20, 40, and80 ms intervals supported by UMTS Release’99. Every TTI, the scheduler chooses thenext user to be served based on the channel conditions ofall the users. This channel-adaptive scheduling can be used, for instance, to maximize the global cell throughputby scheduling users only when their channel condition is good. Note that a given

2The curves in the figure were obtained by the simulation of a PHY-layer mode.

HSDPA Packet Schedulers 101

(a) Two mobile Users (b) HSDPA scheduling

Figure 6.3: Example of HSDPA scheduling.

UE can experience strong fluctuations in bandwidth over time, due to such channel-dependent scheduling policies. More details on packet scheduling are discussed in thenext section.

6.3 HSDPA Packet Schedulers

The HSDPA scheduler is the key to resource management in the UTRAN downlink,because it decides which user is to be scheduled at each time slot. In general, thescheduling decision does not only take into account the channel conditions: additionalfactors like fairness between users, cell throughput or quality-of-service (QoS) param-eters are considered in the scheduling mechanism as well. The choice of a schedulerusually involves some trade-offs between these factors.

Numerous MAC-layer schedulers have been proposed and studied in the literature[71, 81, 21, 64, 82]. In the remainder of this chapter we are going to focus only on thefollowing four types of schedulers:

• Round-Robin (RR) scheduling.

• Maximum C/I (CI) scheduling.

• Proportionally Fair (PF) scheduling.

• Rate-Guarantee (RG) scheduling.


Figure 6.4: Scheduler Trade-off.

We do not claim that this list is exhaustive, however, we believe that it covers rea-sonably well the different families of schedulers that havebeen proposed for HSDPA,and that they are representative of different design trade-offs and constraints.

Figure 6.3 shows an example of 2 mobile users connected to a Base Station (BS).The BS can monitor the channel quality every 2 ms through the feedback from the UserEquipments (UEs). It then schedules the user depending on its channel condition. Oneof the policies, as shown in Figure 6.3(b), can be to schedulethe user having bestchannel conditions in order to obtain the maximal cell throughput or cell capacity. Thedisadvantage with such kind of scheduling is that the users far away from the basestation, having relatively bad channel conditions, might never be scheduled. Thus, asshown in Figure 6.4, there is generally a trade-off between cell throughput and fairnessamong different users. The listed schedulers are discussedin more detail below.

6.3.1 Round-Robin Scheduling

The RR scheduler, which is probably the simplest one in terms of implementation,gives the time slot to users in a round-robin manner. Note that RR is fair with respectto system resources (i.e., time slots), but in general the capacity isnot shared equallyamong the UEs, as each one may have different channel conditions. This will be shownmore clearly in the following chapters. Moreover, RR policy is not optimal with respectto maximizing the global throughput.

HSDPA Packet Schedulers 103

6.3.2 Maximum C/I Scheduling

Maximum C/I (CI) scheduling3 gives the channel to the user having the best channelconditions at each given time slot. IfRi(t) is the instantaneous data rate experiencedby useri at timet, then the CI scheduler assigns the slot at timet to a useri∗ such that:

i∗ = argmaxi{Ri(t)} (6.1)

that is, it gives the channel to the user able to achieve the highest instantaneous rate.The CI scheduler provides the highestcell (global) throughput because it always servesthe users that can support the highest data rates. On the other hand, this scheme is veryunfair as a user nearest to the base station can get all the resources, and the users fartheraway will be starved.

6.3.3 Proportionally Fair Scheduling

The Proportionally Fair (PF) scheduling algorithm [71], [81] assigns the slot at timetto a useri∗ such that:

i∗ = argmaxi

{

Ri(t)λi(t)

}

(6.2)

with Ri(t) as before andλi(t) is theaverage throughputat timet of useri, which iscalculated as follows:

λi(t) =

(

1− 1τ

)

·λi(t−∆t)+1τ·Ri(t) (6.3)

with τ > 1 and∆t equal to the length of the TTI. The PF scheduler offers a good trade-off between cell throughput and fairness, as it both gives the channel to the user having“relatively good” channel conditions and results in a fair distribution of resources.

This scheduler provides the so-called proportional fairness criterion defined in [77].This criterion says that a set of user throughputs{λi} is proportionally fair if it isfeasible and, if for any other feasible vector of throughputs {λ∗i } the aggregate ofproportional changes is zero or negative:

∑i

λ∗i −λi

λi≤ 0 (6.4)

3C/I denotes the signal-to-interference ratio that is used to estimate the optimal value ofRi(t), witha given Block Error Rate target (BLERtarget).


6.3.4 Rate-Guarantee Scheduling

QoS guarantees will be required by users of services like video streaming that haverequirements in terms of minimum bit rate and maximum packetdelay. User satisfac-tion is the main factor that should be considered. Satisfaction criteria are different fordifferent services, each having their own QoS requirements. Thus, resource manage-ment should be aimed at fulfilling these QoS requirements instead of only providingfairness.

QoS classes and parameters have already been defined by 3GPP standards [13].These standards do not define the scheduler implementation details, and they provideflexibility to the system implementors to choose their own scheduler in order to mapthese QoS classes and parameters.

Several schedulers that can offer QoS assurances in HSDPA have been proposed inthe literature. Pedersen et al. [107] discuss different options for providing QoS usingQoS-aware schedulers like those presented in [21, 64]. Mostof these schedulers takethe slot assignment decision based on an index of the form:

i∗ = argmaxi

{

Bi(t)Ri(t)λi(t)

}

(6.5)

whereBi(t) represents a “barrier function” [64]. In order to design QoSschedulers,it was shown in [64] that, given user utilitiesUi(λi), it is possible to obtain a “good”scheduler that will pick the useri∗ such that:


′i (λi(t))}. (6.6)

Note that, in the above formulation, the corresponding utility functions for RR, CI, andPF scheduling areU(λ) = 1,U(λ) = λ andU(λ) = logλ, respectively.

A Rate-Guarantee (RG) scheduler was thus designed in [64] using the above equa-tion (6.6). A utility function of the form

U(λ) = log(λ)+1−exp(−β · (λ−λmin)) (6.7)

was assumed (withβ > 0), resulting in a scheduler with a barrier function

Bi(t) =

{

1+λi(t) ·β ·exp(−β · (λi(t)−λ(i)min)) ∀i ∈ Q ,

1 ∀i ∈ B ,(6.8)

which corresponds to the case where a minimum throughputλ(i)min is required by a QoS

useri; Q andB denote the set of QoS and best-effort (BE) users, respectively.In the literature, there exist several studies (e.g. [64, 107, 93]) that use an RG

scheduler in order to provide rate guarantees to QoS users. In [93], a different variant

Simulation Platform 105

Figure 6.5: Packet Queues in EURANE.

of the RG scheduler described by (6.8) is used with the following change for QoSusers:

Bi(t) = 1+α ·exp(−β · (λi(t)−λ(i)min)) ∀i ∈ Q ; (6.9)

note thatα is a constant, independent of bothλi(t) andλ(i)min. The scheduler given by

(6.9) is also used as a reference scheduler in [82].

6.4 Simulation Platform

In the following chapters all the studies for HSDPA will be done using a packet levelsimulator. In order to simulate HSDPA, we used the EURANE extensions [1] to ns-2[95]. EURANE models the UTRAN in detail, whereas the nodes SGSNand GGSNare just used to route IP packets from the Internet to the UTRANand introduce somedelays. In particular, in EURANE all the functions of the RLC and MAC-hs (MAC inHSDPA) layers are implemented.

The RLC layer consists of two modes of operation, Unacknowledged Mode (UM)and Acknowledged Mode (AM). There are per-user queues in theRNC and a credit-based algorithm, specified in [9], is used for flow control between MAC and RNC.The MAC layer implements the chosen HSDPA scheduler and other functionalitieslike HARQ. The underlying physical layer is modeled in detail, as described in [139],and this model is used to compute a Channel Quality Indicator (CQI) which is fed backfrom UEs to the base station. For the benefit of the readers, a short summary of thephysical layer model used in EURANE is given in the section 6.4.2.

In order to be able to simulate both the four chosen schedulers and a DiffServ-awarestreaming architecture, explained in the section 3.4 of thechapter 3, we implemented


in EURANE a DiffServ queuing behavior as described in section6.4.1, as well as thePF and RG schedulers. Remark that each IP queue in the RNC holds packets fromasingle flow.

6.4.1 QoS-aware IP Queue Management in the UTRAN

The use of a QoS-aware video streaming technique needs support from the underlyingIP network. In particular, it is necessary that the network support some DiffServ-likefunctionality, in the form of a QoS-aware active queue management mechanism likethe one used in the AF per-hop behavior (section 3.4 of the chapter 3): QoS-awaremarking by the video server can then be combined with an AQM algorithm in networknodes, in order to prioritize the important data and drop theleast important data duringcongestion.

In the UTRAN, IP packets are queued at the Radio Network Controller (RNC) be-fore being fragmented and sent to the MAC layer. The RNC keepsper-userpacketqueues, in order to optimize the channel adaptation as each user has different channelconditions. The use of a flow control mechanism, between the MAC layer (at the basestation) and the RNC, ensures that no loss occurs in the MAC queues due to conges-tion or bandwidth drops. This makes the (IP) queues at the RNC the bottleneck in ourconfiguration, since IP packets are dropped if the RNC queue limit is reached. There-fore, for the purposes of the QoS-aware video streaming architecture we assume thatRNC buffers implement a QoS-aware AQM scheme; in particular,the RIO algorithm[41, 94] is employed for differential packet dropping.

6.4.2 Physical layer model in EURANE

This section presents the physical layer model used by EURANE. See [139] for moredetails.

The transmitted signalTx has a constant power to which the effects of the physicallayer are added. First, the intra-cell interferenceIintra, assumed to be a constant value,is added. After that, the signal strength is reduced by a variable amount due to channelpropagation loss that is modeled as follows. The propagation lossL consists of threeelements:L = P+ S+ M, whereP is the path loss,S is the shadow fading, andMis the short-term fading. The path loss is described by the Okamura-Hata model forsuburban areas:P(x) = Linit +10·n· log10(x), wherex is the distance between UE andBS inkm, Linit is the loss at 1kmandn is the path loss exponent.

The shadow fading is caused by the obstacles in the propagation path between UEand BS. EURANE uses the correlation model for shadow fading from [56]. The lossdue to shadow fading is constructed as follows [139]:S(x+δx) = aS(x)+bσN, whereδx is the distance between two subsequent time samples andN is a random variablethat satisfies the standard normal distribution. The parameter b is taken such that the

Related Studies 107

vector containing all realizations equalsσ. The parametera is determined such thatthe autocorrelation function ofSsatisfies:E[S(x)S(x+δx)] = aσ2.

The fast fadingM model that is caused by multi-path is taken from the stan-dard 3GPP models such as Pedestrian A, Vehicular A, etc. At the end, the inter-cell interferenceIinter is also added to the signal and is also assumed to be a con-stant value. A value ofSNRis estimated from the resulting signal that is equal to:

SNR= Tx−10· log10(10Iintra

10 + 10Iinter+L

10 ), whereTx is the transmitted code power indBm, L in dB and interference in dBm. Proper delays in the reception are also ac-counted.

The resulting signal is also used by the receiver to do the HARQChase Combining.Chase Combining is a type of soft combining that is used to combine the successivere-transmissions of the frame in case of erroneous frames. Moreover, depending on theresulting signalRx, an ACK or NACK is generated corresponding to whether the framewas received correctly or not. In order to determine whethera frame was receivedcorrectly or not, a random number from a uniform distribution is drawn and is mapped,using a BLER toSNRtable, to a minimum value ofSNRrequired for correct reception.This table corresponds to a AWGN (Additive White Gaussian Noise) channel. Thisminimum value of theSNRand the estimated value of theSNRfrom Tx is used for allHARQ transmissions to determine if the block was received correctly or not and anACK or NACK is generated. After a maximum number of HARQ re-transmissions,the block is discarded and, depending on the RLC mode (UM or AM), is left to theRLC to handle it.

The resultingSNRis also used by the receiver to estimate the channel quality.TheCQI value is generated, using estimatedSNRvalue, for feedback. This CQI value isgenerated for a target Block Error Rate,BLERtarget.

6.5 Related Studies

Recent studies have focused on evaluating the performance ofHSDPA-enhanced UMTSsystems in the context of best-effort traffic [81, 39]. Parkvall et al. [105] provided anoverview of key HSDPA technologies and showed the improvements in terms of userthroughput, cell capacity, and coverage. Jalali et al. [71]discussed the data throughputperformance of the channel-adaptive Proportional Fair (PF) scheduler.

Channel-adaptive schedulers are reported to take advantageof the multi-user diver-sity that is inherent in wireless systems. Borst [36] studiedthe user-level performanceof the PF scheduler. A dynamic setting with a random nature ofservice demands isconsidered in comparison to many previous works assuming a static user population.Bonald et al. [33] extended the results of [36] by using some general scheduling andadmission control schemes. A “spatial” component is also considered in the traffic ar-rival model. Landstrom et al. studied congestion control for Best-Effort traffic in [84]


using a new queue management scheme [120] designed for UMTS packet buffers.Video streaming and providing QoS over HSDPA has also been the subject of sev-

eral studies. In [92], Lo et al. did a performance evaluationstudy of H.264 streamingover a pre-Release 5 UMTS network (that is, a 3G networkwithoutHSDPA). Andrewset al. proposed a scheduler based on providing delay and rateguarantees in [21]. Bar-riac et al. [24] extended the PF scheduler to equalize the user throughputs for videousers. Hosein showed in [64] that “good” schedulers can be designed based upon userutility functions. Kolding [82] proposed a new scheduler, based on similar princi-ples as above, using a better estimation of the required scheduling activity for a givenuser. Ameigeiras [20] studied the performance of differentHSDPA schedulers on CBRvideo quality. Leibl et al. [89] studied different strategies for joint buffer managementand scheduling for H.264 coded video streaming over HSDPA. Lundevall et al. [93]studied the performance of 55 kbps and 90 kbps streaming services over HSDPA, andshowed that a QoS-aware scheduler can protect the quality ofvideo during high loadconditions. Pedersen et al. [107] discussed the mapping of the schedulers to the QoSparameters specified by the 3GPP project.

6.6 Conclusion

This chapter gave an overview of the HSDPA enhancements to the UMTS. The keypoint of HSDPA is its fast and adaptive packet scheduling. This chapter discussedsome existing HSDPA packet schedulers. In the remaining chapters of this part, theseexisting schedulers will be evaluated from the user-perceived quality point of view.Moreover, certain improvements and resource allocation strategies will be proposed.

Chapter 7

Streaming of H.264 Video overHSDPA: Impact of MAC-LayerSchedulers on User-Perceived Quality

In spite of the fairly high data rates that HSDPA offers, the shared downlink radiochannel used in HSDPA is a challenging environment for delay- and loss-sensitiveapplications like video.

This chapter focuses on the problem of streaming H.264-coded video over HSDPA.Our goal is to evaluate the impact of several MAC-level scheduling approaches onvideo quality. The video quality is evaluated using a tool that yields a good estimateof the user-perceived, subjective quality. We consider both abest-effortstreamingscenario, that is, without any QoS support at the IP level, anda QoS-awarestreamingscenario, in which some video packets, marked by the video server as being the mostimportant for the decoding process, are protected from loss. Our results show the gainsachieved by a QoS scheduler in terms of increased cell coverage and increased numberof users that can be admitted in the system, for the same subjective quality experiencedby the video users. In addition, with the use of a QoS scheduler, the remaining capacityis fairly divided among the best-effort users.

Moreover, we propose a Normalized Rate Guarantee (NRG) scheduler, which is anextension of a previous QoS scheduler. When allocating the available bandwidth, theNRG scheduler takes into account the fact that QoS requirements (in terms of minimumbandwidth) may vary from one flow to the other. It tries to apportion loss rates in afairer way during congestion. Another goal of NRG is to avoid the deterioration ofQoS when best-effort load is increased.

109

110 Streaming of H.264 Video over HSDPA

7.1 Introduction

Video streaming services are becoming popular and will likely be a significant sourceof revenues for cellular-network operators. Figure 6.1 shows a typical video streamingscenario and a simplified UMTS architecture consisting of the core network and theUMTS Terrestrial Radio Access Network (UTRAN). The UTRAN consists of RadioNetwork Controllers (RNC) which control several base stations(BS, or Node B). Amobile user present in the UTRAN can stream video on her User Equipment (UE)from a server in the Internet. The UTRAN is connected to the Internet through theServing GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN)present in the core network. In the UMTS network, all the links in the core networkare usually over-provisioned. Such over-provisioning of the core network, togetherwith the fluctuations in radio channel quality that are inherent of wireless links, willoften make the UTRAN act as a bottleneck. Therefore, resourcemanagement will berequired in UTRAN to provide good Quality of Service (QoS) to the users.

This chapter focuses on the problem of streaming H.264-coded video over HSDPA,and particularly on the choice of a MAC-level scheduler suitable for video streaming.We are interested in assessing the impact of several schedulers on thesubjectivequal-ity of the received video. Some studies have already been done (see section 6.5 ofthe chapter 6) that use objective quality parameters like PSNR (Peak Signal to NoiseRatio), packet delay or loss and play-out buffer underflow to study video streamingover HSDPA. However, it is well known that objective metricslike those above donot necessarily correlate well with user-perceived quality when a network is involved(see for instance [141]). In order to obtain a quality metricas correlated as possi-ble with human visual perception, we employ a recently proposed technique, PSQA(Pseudo-Subjective Quality Assessment) [102, 119, 118] that yields an estimate of thesubjective quality. PSQA is based on a specific type of queuing network used as alearning tool called Random Neural Network.

We consider two types of streaming scenarios, differing in the level of QoS supportoffered at the IP layer: (1) Abest-effortstreaming scenario, that is, without any QoSsupport at the IP level. (2) AQoS-awarestreaming scenario, in which the networkprotects from loss the video packets that are the most important for the decoding pro-cess. This protection is achieved through both a packet-marking scheme at the H.264streaming server, and a QoS-aware queue management in the UTRAN.

Moreover, in this chapter, we propose a new scheduler calledNormalized RateGuarantee (NRG). NRG scheduling improves upon the existing HSDPA QoS sched-ulers because, unlike those schedulers, it isnot sensitive to the best-effort (BE) loadand during congestion it apportions the loss rates, among different QoS users, in a fairway.

Section 7.2 focuses on the problem of evaluating the subjective video quality andpresents the quality estimation tool that we employed. Section 7.3 presents the NRG

Estimation of Subjective Video Quality 111

scheduler. Sections 7.4 and 7.5 present and discuss a performance evaluation studydone with the well-known ns-2 network simulator [95].

7.2 Estimation of Subjective Video Quality

To evaluate the perceived quality we use the PSQA tool proposed in [102, 119] forvideo and audio flows respectively. The technique consists of the following procedure.We take a short video sequenceσ and we send it through a network where we cancontrol the values of a vector ofJ parametersp= (p1, · · · , pJ) that we have selected ashaving the maximal impact on the quality, as perceived by a panel of human observers.We randomly chooseM +N different combinations of the values of theJ parametersthat we put into two different sets denoted byM andN . Each of them is called aconfiguration. With thekth configuration we associate the value given to sequenceσk

by the panel of humans, following a controlledsubjective testingexperiment accordingto some well established norm such as [66]. Then, we build a function Q() of theJ parameters, such that for any configurationp ∈ M the numberQ(p) is close tothe quality ofσk given by the human panel. This is done using a specific statisticallearning method described below. After obtaining thisQ() function, we validate it bycomparing its value on the configurations in the second setN and the quality numbercoming from the subjective testing experiment. If these values are close enough, thetool is validated.

To build the quality functionQ() we use a feed-forward Random Neural Network(RNN), that is, an open Markovian queuing network composed ofJ+ H + 1 queues.Nodes 1 toJ are input ones receiving customers from outside according to independentPoisson processes with ratesν1 to νJ. They send their customers to nodesJ + 1 toJ + H. Customers leaving a nodeJ + h, 1≤ h≤ H, are sent to nodeJ + H + 1 andfrom it all customers leave the network. Nodes are independent ·/M/1 queues. Theservice rate at nodei is µi . When leaving input nodej, 1≤ j ≤ J, a customer canbe transformed into a “negative” one. In that case, when it arrives at a nodeJ + h,1 ≤ h ≤ H, it “kills” itself and it “kills” one of the customers present at the nodeat that point in time. The routing is independent of everything in the network, andthe probability that a customer that leaves nodej goes to nodeJ + h as a normal(or positive) customer (respectively as a negative one) is fixed, and denoted here asr+

j,J+h (respectivelyr−j,J+h). We have∑Hh=1(r

+j,J+h + r−j,J+h) = 1. Things are similar for

transfers between nodeJ+ h and the only output nodeJ+ H + 1; here, we just haver+J+h,J+H+1 + r−J+h,J+H+1 = 1.

The number of customers at a node behaves as thepotentialof a neuron, and thoseflows of negative customers asinhibiting signals since they decrease the potential ofthe neuron. This is what makes this tool behave as a neural network, and [102, 119]and the more recent [118] show that, for this application, itbehaves better than clas-


sical tools such as standard Neural Networks. When used as a learning tool, we mustsee the RNN as a black-box implementing a parametric functionwith J input variables(the rates of the external arriving flows) and one output one (the load of the only outputnode, assuming the network in equilibrium). In symbols, we see the loadρJ+H+1 ofthe output node asρJ+H+1 = ρJ+H+1(ν1, · · · ,νJ). The routing probabilities are theparameters of the function. Learning means finding an appropriate set of parameters,such that when the input of the function is the configurationp, the outputρJ+H+1(p) isclose to the quality of a sequence having encountered a network where those selectedquality-affecting parameters have the values inp. Finally, remark that the mappingp 7→Q(p) implemented in such a black-box is a rational function, having nice mathe-matical properties (this is worth noting, even if we don’t exploit this here).

In the QoS-aware video streaming case, we used the followingfour parametersas the inputs of the quality metric tool: the loss rate of green packets, the loss rateof yellow packets, the loss rate of red packets and the mean loss burst size of greenpackets. The first three parameters have a clear meaning. Thefourth is there becauseof the particular impact on quality of the distribution of losses among green packets:it can be expected that loss bursts of green packets (containing the most importantinformation) should have a strong impact on perceived quality. Note that we don’texplicitly take delays into account because a late packet isconsidered as a lost one inour framework.

The result of the PSQA process is a quality function of these 4variables: aftermeasuring the values of these loss ratios and the average size of the burst of green lostpackets at some timet, the function provides an approximation of theinstantaneousperceived quality of the video at timet.

In this study the quality metric is used in the following way:the PSQA functionis called every second and the 4 parameters are computed on a time window of length5 s. After evaluating the quality at every second, the average for the whole sequence iscomputed.

7.3 Normalized Rate Guarantee Scheduling

In the chapter 6, we discussed HSDPA schedulers and providedthe background relatedto the QoS scheduling. In this section, we give a brief recap of the QoS scheduling andthen propose the Normalized Rate Guarantee (NRG) Scheduling.

In the chapter 6, we saw that the QoS schedulers in general pick a useri∗ satisfying:

i∗ = argmaxi{Bi(t)Ri(t)/λi(t)} (7.1)

whereBi(t) represents a “barrier function” [64],Ri(t) is the instantaneous data rateexperienced by useri at timet andλi(t) is theaverage throughputof useri.

Normalized Rate Guarantee Scheduling 113

In order to design QoS schedulers, it was shown in [64] that, given user utilitiesUi(λi), it is possible to obtain a “good” scheduler that will pick the useri∗ such that:


′i (λi(t))} (7.2)

A Rate-Guarantee (RG) scheduler was thus designed by Hosein in[64] usingEq. (7.2). A utility function

UQ (λ) = log(λ)+1−exp(−β · (λ−λmin)) (7.3)

was assumed for QoS users (withβ > 0), resulting in a scheduler with a barrier function

Bi(t) =

{

1+λi(t)β ·exp(−β · (λi(t)−λ(i)min)) ∀i ∈ Q ,

1 ∀i ∈ B ,(7.4)

which corresponds to the case where a minimum throughputλ(i)min is required by a

QoS useri; Q andB denote the set of QoS and best-effort (BE) users, respectively.Note that theBi(t) function for BE users corresponds to a user utility of the formUB (λ) = log(λ).

In [93], a different variant of the RG scheduler described by (7.4) is used with thefollowing change for QoS users:

Bi(t) = 1+αexp(−β · (λi(t)−λ(i)min)) ∀i ∈ Q ; (7.5)

note thatα is a constant, independent of bothλi(t) andλ(i)min.

Now, before coming back to the NRG scheduler, considering forany useri ∈ Q ,let us denote by∆λi(t) the instantaneous difference at timet between the average rate

λi(t) and its minimum guaranteed rateλ(i)min, that is,∆λi(t) = λi(t)−λ(i)

min. The purposeof the barrier functions (7.4)-(7.5) is then to increase theprobability of scheduling useri whenever∆λi(t) < 0.

Both the original RG scheduler in [64] and its variant in [93] suffer from the de-terioration of rate guarantees of the QoS users as the numberof “active” BE usersnBE = |B | is increased. This is because asnBE increases the value ofλi for BE usersdecreases. This in turn increases the termBi(t)/λi for BE users asBi(t) = 1 remainsconstant. Moreover, the above schedulers, especially the one described by the equa-tion (7.5), tend to be biased towards some users depending ontheir value of rate guar-antees. This is further made clear and discussed in the section 7.5.

We propose a new scheduler called Normalized Rate Guarantee (NRG) that isbased on the RG scheduler. We want to apportion loss rates in a fairer way duringcongestion irrespective of the rate guarantees. We also want that the increase in theBE load does not deteriorate the quality of the QoS flows and theincreased BE loadbe shared among BE users only.


We assume the following utility for QoS users:

UQ (λ) = λmin ·(

log(λ)+1−exp

(

−β · λ−λmin

λmin

))

, (7.6)

For best-effort users we consider that the rate guarantees are “always satisfied”, hence,the utility for BE users is:

UB (λ) =kBE

nBElog(λ). (7.7)

The constantkBE will determine the proportion of resources allocated to theBE usersand thenBE term, similar to the concept used in [82], in the denominatorwill ensurethat if the number of BE users increases then it will not increase the load on resourcesfor QoS users. Furthermore, a valuen(min)

BE can be chosen such thatBi(t) = kBE/n(min)BE

if nBE < n(min)BE to avoid the division by zero and to slightly improve the QoS when the

number of BE users goes low.Using the above utilities and equation (7.2) results in a scheduler (7.1) with:

Bi(t) =

λ(i)min+λi(t)β ·exp

(

−β · (λi(t)−λ(i)min)

λ(i)min

)

∀i ∈ Q ,

kBEnBE

∀i ∈ B .(7.8)

The parameterβ will determine the aggressiveness of the scheduler to the increas-ing loss; neither a low value ofβ nor a high value ofβ is good. The latter will unnec-essarily increase the priority of a user having a very bad channel, and the former willnot be able to provide rate guarantees even on slight channeldeterioration. The choiceof β andkBE is discussed more in section 7.5.1.

It should be noted that the termBi(t)/λi(t) in the scheduler (7.1) becomes equalfor all the QoS users when they achieve their minimum throughput or when the lossratio of QoS users is the same. Thus, we call it as normalized rate guarantee schedulerbecause both the terms∆λi(t) for QoS users andBi(t) for BE users are normalized.

7.4 Performance Evaluation

The simulation platform used for this study is already described in the chapter 6. Inwhat follows, we will describe a performance evaluation study done with the well-known ns-2 network simulator [95]. For the sake of clarity, presentation and discus-sion of results will be deferred to section 7.5; in this section we will only explainthe methodology and tools we used for this study, as well as the different simulationscenarios and parameters.

The goal of this study is to compare the performance of the NRG scheduler andthe four HSDPA schedulers discussed in Section 6.3 of chapter 6, in terms of the sub-jective video quality perceived by end-users. The video is encoded by a H.264 codec

Performance Evaluation 115

SGSN

INTERNET

GGSN

Video and WebServers

UMTS CORE NETWORK UTRAN

RNC

BS

Video Users

TCP Users

IuPS UuIubGnGi

RTT

RTT

video

web

Figure 7.1: Simulation topology.

whose output is a constant-rate bitstream. We consider two video streaming scenar-ios: a best-effort scenario (i.e., no QoS support at the IP layer), and a DiffServ-awarescenario implemented according to the principles described in chapter 3. The result-ing subjective quality is estimated thanks to the PSQA tool presented in the previoussection. We also give some complimentary results using the traditional Peak Signal toNoise Ratio (PSNR) metric.

7.4.1 Methodology

The evaluation study was performed as follows. A raw (YUV) video sequence is codedby a H.264 software encoder, whose output (a bitstream) is fed to a parser and packe-tizer module. In order to be able to perform DiffServ-aware streaming, this parser firstdetects syntax elements (NALUs) in the bitstream, then setsthe appropriate DSCP val-ues in the header of the resulting IP packets, depending on the type of NALU carriedby the packet. It is this pre-defined mapping function which implements the particu-lar QoS marking strategy chosen. The output of the parser is atrace file in a formatreadable by the simulator.

Next, the video packet trace file is fed to the ns-2 simulator (compiled with theEURANE extensions). This trace file serves as a traffic generator during the simula-tion. A simulation script allows to define the particular scenario under consideration(network topology, simulation parameters, and so on). When the simulation is run,an output trace file is produced which contains delay- and loss-related information forevery video packet sent by the (simulated) video server.

Finally, from the simulation output trace, relevant parameters are computed andthen fed to the PSQA tool which gives a quality score. For the PSNR results, theoutput trace is used to generate the received video file and that in turn is comparedwith the original file to compute the PSNR.


Table 7.1: Default simulation parameters.

Parameter Default ValueCarrier frequency, TTI 1950 MHz, 2msHARQ max retransmissions 2Time delay (TTI) in CQI 3CQI value: Min - Max 0 - 30Site to site distance 1.0 kmMultipath environment, User Speed Pedestrian A, 3.0 km/hDistance Loss model, Shadow fadingOkamura-Hata, correlation model [56]Linit (distance loss at 1 km) 137.4Path loss exponent 3.52Correlation in shadow fading 40 mStd. dev. in shadow fading 8 dBBS Transmission power 38 dBmBase station antenna gain 17 dBiIintra (intra cell interference) 30 dBmIinter (inter cell interference) -70 dBmMaximum Data Rate,BLERtarget 3.6 Mbps, 10%α, β in Equation (6.9) 1.25, 0.0313 kbps−1 [93]λmin in Equation (6.9) 400 kbpsτ in Equation (6.3) 1000RLC mode UMNumber of Video Users 4WWW file size model Pareto-distributed

Pareto shape parameter 1.2Mean file size 10 KB

WWW thinking-times model Exp-distributedMean thinking time 5 seconds

RNC queue limitQ 128 IP packetsRIO parameters (Fig. 3.3)minthred,minthyellow,minthgreen (0.1,0.3,0.5)∗Qmaxthred,maxthyellow,maxthgreen (0.3,0.5,0.7)∗QmaxPred, maxPyellow, maxPgreen 0.2,0.1,0.02wq 0.9Round Trip Times

RTTvideo, RTTweb 100 ms, 40 ms to 200 msRTTGn,RTTIuPS,RTTIub 20 ms, 1 ms, 30 ms

Simulated time 72 seconds(single simulation run)


Figure 7.2: Reference video “Mother and Daughter”. The size format is QCIF and thevideo is repeated 2 times to make its duration equal to 64 seconds.

7.4.2 Simulation Scenarios

Table 7.1 summarizes the default values of simulation parameters; these parametersremain unchanged in all scenarios unless specified otherwise. The table describesalmost all the relevant parameters and for extra details please see [1]. All scenariosunder consideration correspond to the network topology shown in Figure 7.1. There isa fixed number of video users (four) and several background TCPflows, representingusers running data applications. Two types of background flows were considered:long-lived flows (corresponding to users downloading largedata files) and web-like,on-off traffic (modeling WWW-browsing users).

The video is an H.264-coded reference sequence called “mother and daughter”.The size format is QCIF and the video is repeated 2 times to makeits duration equal to64 seconds. A single frame of the video used is shown in Figure7.2. The target averagebit rate of the encoded video stream is controlled using the quantization parameter ofthe H.264 codec. The Group of Pictures (GOP) size of 16 framesis used. The resultantaverage bit rate is≈ 384 kbps and the video is streamed in unicast mode using UDP.The size of a single video packet, or a single “slice”, is variable but close to the targetvalue of 1000 bytes given to the encoder.

The rate guarantee, shown in the table 7.1, is set slightly higher than the actualvideo bit rate, i.e., rate guarantee is 1.1 · (average video bitrate) for the video users.The factor of 1.1 is used to accommodate for the burstiness in the video bitrate.

As explained in chapter 6, we implemented RIO queuing management in the RNCas it protects the video packets considered important by thedecoding process. ForDiffServ-aware streaming, a simple marking policy taken from [104] was adopted: I-type slices are put in packets marked as “green”, whereas themark applied to P-typeslices (“yellow” or “red”) is chosen at random for each packet, according to a Bernoullidistribution with parameterp = 0.5. No B-type slices were produced by the version of


1

1.5

2

2.5

3

3.5

4

0 10 20 30 40 50 60 70 80

Qm

in (

PS

QA

sco

re)

Queue Limit (Packets)

RIO + RGDT + RGRIO + PFDT + PF

Figure 7.3: Comparison of DT and RIO. The numberNwww of WWW flows is 18 andthe number of long-lived TCP flows is 2.

the encoder that was available during PSQA tool training. This is because that versionof the encoder is not able to tolerate the loss of B frames, resulting in decoder crash.

The comparison between drop-tail (DT) and RIO is shown in Figure 7.3. In orderto compare the two queue management schemes with more fairness, we fixed the DTqueue limit equal to the value of themaxthred threshold of RIO. This is done becausein RIO all “red” packets are dropped if this threshold is reached and a significant lossof “red” packets will bring down the PSQA score to less than 3.0. For simplicity, onlytwo schedulers are compared and it can be seen that for both schedulers, RIO providesgains in terms of PSQA scores as it protects the important packets when packets haveto be dropped. Thus, we use the RIO queue management for further simulations.

For a given scenario with a specific set of studied parameters, independent runsare performed for at least 45 times or till the 95%-confidenceintervals for the PSQAmetric are less than a given thresholdθ. We takeθ = 0.05 for all the schedulers exceptCI, for whichθ = 0.25. This is because, as we will see later, the CI scheduler providesa quality that is highly unstable.

Finally, we consider that the users experiencing a PSQA score lower than 3.0 arenot satisfied. A score equal to 3.0 corresponds to a “fair” quality rating.

7.5 Results

We will now present and discuss results from several scenarios, obtained followingthe methodology and tools described in section 7.4. The video quality evaluation is

Results 119

done using the PSQA tool, except for section 7.5.4 where PSNRis used. Unless statedotherwise, all results correspond to the DiffServ-aware streaming case.

Further, it should be noted that when we compare RG and NRG then the onlyresults to highlight are that with NRG:

• The video quality does not deteriorate when Best Effort or the background loadis increased

• NRG provides fair loss rates irrespective of the rate guarantees of the differentQoS users.

We do not highlight the relative difference of PSQA scores with RG and NRG as itcan always be argued that even though the RG scheduler provides an overall relativelylow video quality, it provides slightly better throughput to Best Effort (BE) users. Ourargument is that we do not want the BE throughput to increase atthe cost of QoS usersand we would like to control the perceived video quality and the total BE throughputin more flexible way.

Now, let us denote byQmin the value such that the 95% of the video user popula-tion, across all simulation runs, gets a PSQA scoreQ≥ Qmin. Qmin is a good designparameter, as in any system it is desired that a minimum quality should be experiencedby as many QoS users as possible. Thus, we use this parameter instead of the averagePSQA score in some of the following results.

7.5.1 Video Quality vs. Best Effort Throughput

After running some preliminary simulations, we choose the values ofβ andkBE forthe NRG scheduler, keeping in mind the trade-off between perceived video qualityby the video users and total throughput of the TCP users ( or theBest Effort (BE)users). Figures 7.4 and 7.5 show the trade-off when increasing or decreasingβ andkBE. It can be seen that the total throughput of BE users is low witha low value ofkBE and the throughput increases with the value ofkBE. Moreover, it can be seenthat in some cases neither a low value ofβ nor a high value ofβ is good. The latterwill unnecessarily increase the priority of a user having a very bad channel. This willcause the throughput available for BE flows to decrease. Not only that, but it may alsocause the video quality to decrease in some cases as shown in Figure 7.4. Whereas,a low value ofβ will not be able to provide rate guarantees even on slight channeldeterioration.

The value ofβ = 3.125·10−5 for Hosein’s RG scheduler is similar to the one usedin [64, 93] when the rates are in bps. For NRG, we choose the values ofβ andkBE to be6.0 and 15·105 respectively, when the rates are in bps (note the change in magnitudesof β andkBE because of the normalization factors).


2.8

3

3.2

3.4

3.6

3.8

4

4.2

4.4

4.6

0 2 4 6 8 10 12

Qm

in (

PS

QA

Sco

re)

β

kBE = 5 x 105

kBE = 15 x 105

kBE = 30 x 105

Figure 7.4:Qmin value with different values ofkBE andβ.

0.9

1.0

1.1

1.2

1.3

1.4

1.5

0 2 4 6 8 10 12

TC

P T

hrou

ghpu

t (M

bps)

β

kBE = 5 x 105

kBE = 15 x 105

kBE = 30 x 105

Figure 7.5: Total throughput obtained by Best Effort users with different values ofkBE

andβ.

Results 121

0

0.2

0.4

0.6

0.8

1

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5

Pro

babi

lity(

Sco

re >

x)

x (PSQA Score)

NRGRGCIPFRR

Figure 7.6: Inverse CDF of PSQA scores with 10 TCP long flows as background traffic.The bin size for the CDF is 0.25. A “fair” quality rating corresponds to PSQA = 3.0.

7.5.2 Long-Lived Flows as Background Traffic

In this scenario,N > 1 TCP flows are present as background along with the videoflows. It is assumed that the TCP users had enough data to transmit for the duration ofsimulation.

7.5.2.1 Simple Call Admission Control

Figure 7.6 shows the result when four video users were present with N = 10 TCP long-lived flows. The distance of the users was randomly varied with a uniform distribution,and a maximum distance from the base station equal to 500 m. This scenario is equiv-alent to one where a simple connection-admission control (CAC) is used that restrictsthe number of users queued at a single time.

It can be seen that the Normalized Rate-Guarantee (NRG) scheduler performs bestand is able to provide a PSQA score of 3.0 or more to about 90% ofusers, as com-pared to only≈65% for the RG scheduler and≈30% for the CI scheduler. A goodCAC should be able to block users (or reduce their guaranteed bit rate value) that willeventually get a low PSQA score due to their bad channel conditions. It can be noticedthat the PF and RR schedulers never achieve the required PSQA score as they dividethe bandwidth in a fair way, without taking special care of video users. Thus, 10 TCPlong flows turns out to be a high background traffic load for thePF and RR schedulers.

If we look at the NRG and the RG scheduler, then it should be notedthat in thisscenario the bandwidth given to 10% and 35% of the users, respectively, was“wasted”,


in the sense that the PSQA scores for these users are< 3.0 and so they would not besatisfied with the video quality. More bandwidth was wasted in the case of the otherschedulers. These users should not have been admitted for the video service, as it isdesirable to either give a satisfactory quality to the videousers or none at all to savethe bandwidth that will eventually be wasted.

This can be achieved by a CAC that monitors the channel conditions for a userdemanding a particular video service. CAC will use a threshold to decide if the userbe given access to the demanded video service or not. If the channel condition is lowerthan the threshold then CAC can either drop the demand or can re-negotiate a lowerbandwidth (in the case of the RG scheduler). Moreover, if the channel conditions of auser who has already been given access fall considerably fora “prolonged time”, thenthe CAC could drop the user to avoid the degradation of the quality experienced bythe other video users. This call dropping should be done in extreme cases and onlywhen the channel conditions deteriorate for a prolonged period, as fluctuations in thechannel conditions over a short-time scale are inherent in the wireless link.

7.5.2.2 Restricted Access to Video Users

The aforementioned CAC may use a minimum threshold corresponding to the channelconditions, to decide whether a user should be given access or not. Remark that thereceived SNR (Signal to Noise Ratio) decreases in proportionto the distance of the UEfrom the base station. Thus, if the CAC uses such a threshold, that will in turn result ina given cell coverage radius. A higher threshold will mean that only the users near tothe BS will be given access to the video service, whereas a lower threshold will meanthat the users farther from the BS will be able to access the video service.

In this second scenario we employed a CAC to give access to video users whosedistanced from the base station is≤ dmax. The value ofdmax was increased in steps.This scenario can be used to estimate the cell coverage, since the scheduler that willprovide user satisfaction for the highest value ofdmaxwill provide better cell coverage.As in the previous case, the number of background TCP users is 10.

Figure 7.7 shows the average PSQA obtained with different values ofdmax. It canbe seen that, on the average, the NRG scheduler performs much better than the otherschedulers. It should be noted that the background load generated by the TCP usersremains high even whendmax is as low as 100 m. Moreover, on the average the CIscheduler gives better quality scores than the PF or RR ones.

Figure 7.8 shows the value ofQmin with varying dmax. In our scenario, the NRGscheduler satisfies users up to 450 m and the RG scheduler up to 300 m from the BS,if a PSQA threshold of 3.0 is considered.

It is worth noting that, with respect toQmin, the CI scheduler performs worst ex-cept for the users that are within 100 m from the BS. This is contrary to what can beobserved when average PSQA scores are considered (Fig. 7.7). This means that the

Results 123

0

1

2

3

4

5

100 200 300 400 500

Ave

rage

PS

QA

Sco

re

Maximum Distance from Base station (m)

NRGRGCIPFRR

Figure 7.7: Average PSQA scores.

0

1

2

3

4

5

100 200 300 400 500

Qm

in (

PS

QA

Sco

re)

Maximum Distance from Base station (m)

NRGRGCIPFRR

Figure 7.8: Minimum PSQA score obtained after removing lower 5 percentile of users.


0

0.2

0.4

0.6

0.8

1

200 400 600 800

Pro

babi

lity

(thr

ough

put >

x)

x (Throughput in kbps)

NRGRGCIPFRR

Figure 7.9: Inverse CDF of average per-user throughput obtained by background TCPflows. The bin size for CDF is 25 kbps.

CI scheduler gives very good quality to few users, which increases the average qualityscore, but many users get a video quality that is very poor. Thus, it will not be pos-sible to provide satisfaction to as many as 95% of the users. This particular case alsoemphasizes the usefulness of a metric such asQmin for the performance evaluation.

It is interesting to look at the quality experienced by thebackgroundflows, mea-sured here in terms of throughput. Figure 7.9 shows the CDF of per-user throughputobtained by the TCP flows. As expected the CI scheduler is the most unfair and givesvery good throughput to≈ 40% of the users and a very bad throughput to the rest.This figure also illustrates the trade-off provided by the NRGand RG schedulers: theyprovide satisfaction to most video users, but it results in lower per-user throughput forTCP flows. One good point about these schedulers is that they divide the remainingcapacity to best-effort (TCP) users in a fair way. This can be inferred from the shapeof the inverse CDF graph of the NRG and RG schedulers, which is similar to that ofthe PF and RR schedulers as seen in Fig. 7.9.

7.5.2.3 Best Effort Load

When the number of users increases, the quality will decreaseas HSDPA is a sharedchannel. Thus, the CAC will have to decide on the maximum number of users that canbe admitted in the system. We study the performance of the schedulers with differentnumbers of background TCP users. A benchmark similar to the one used in [107, 82]is employed to evaluate the performance of the scheduler, asfollows. The numbernBE

of background flows is increased. WhennBE cannot be increased while keeping up to

Results 125

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

0 5 10 15 20 25

Qm

in (

PS

QA

sco

re)

Number of TCP flows

NRGRGCIPFRR

Figure 7.10: Minimum PSQA score obtained after removing lower 5 percentile ofusers. The numberN of background TCP flows was varied.

95% of the users satisfied, its value is called themaximum load.Figure 7.10 shows theQmin value for different values ofnBE. It can be seen for

instance that, if 95% of the users should get a PSQA score≥ 3.0, then the maximumload with a PF scheduler is 4; that is, at most 4 TCP long flows canbe accepted inthe system. With RG scheduler, also, the value ofQmin decreases with the BE loadand up to 14 TCP long-lived flows can be served while satisfyingthe video qualityconstraint. Whereas, theQmin value remains stable with the NRG scheduler when theBE load is increased. The reason for this behavior is that whenthe BE load increases,the RG scheduler cannot avoid giving more resources to the BE flows, as explainedby the increase in total BE throughput in Fig. 7.11, at the costof QoS/video users.On the other hand, this deterioration is not there with the NRGscheduler. NRG, thus,improves upon the RG scheduler as it remains insensitive to the BE load as is clear inthe figures.

7.5.3 Mix of TCP Long-Lived and WWW Flows as BackgroundTraffic

Since a mix of TCP long-lived flows and WWW flows is a more realisticbackgroundtraffic pattern, we also ran simulations with 4 video flows, 2 TCP long-lived flowsandNwww WWW flows. The value ofNwww was increased in order to increase theload. WWW traffic was simulated as follows. A simple on-off session-level model ofWWW traffic is used, in which downloading of a “file” (web page) isfollowed by a


0.9

1.1

1.3

1.5

1.7

0 5 10 15 20 25 30 35 40

TC

P T

hrou

ghpu

t (M

bps)

Number of TCP flows

NRGRG

Figure 7.11: Total Best Effort throughput when the numbernBE of background TCPflows was varied.

0

1

2

3

4

5

0 5 10 15 20 25 30 35 40

Qm

in (

PS

QA

sco

re)

Number of WWW flows

NRGRGCIPFRR

Figure 7.12: Minimum PSQA score obtained after removing lower 5 percentile ofusers. The numberNwww of WWW flows was varied and the number of long-livedflows was kept equal to 2.

Results 127

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8

Pro

babi

lity

(dow

nloa

d tim

e <

x)

x (seconds)

NRGRGCIPFRR

Figure 7.13: CDF of the download times experienced by users. The numberNwww ofWWW flows is 20 and the number of long-lived TCP flows is 2.

“thinking time”, after which the user will initiate a new download. File sizes follow atruncated Pareto distribution with an average of 10 KB and with shape parameter equalto 1.2; sizes are truncated at a minimum value of 100 bytes anda maximum value of2 MB. Thinking times were modeled using an exponential distribution with an averageof 5 seconds.

A point worth noting is that, when the PF scheduler was used, Equation (6.3) wasnot updated if the RNC queue for the WWW user was empty. This is a practicalapproach because if (6.3) is updated for a user even when there is no data in the corre-sponding RNC queue, it will make theλi(t) close to zero if no data arrives in the queuewhile the user is still “thinking”. This will lead to a very high priority for the WWWflow when the next data burst arrives to the RNC queue. Thus, this approach avoidsthe decrease in the estimated value ofλi(t) when in fact it is not decreasing.

Figure 7.12 shows the value ofQmin for video users when the number of WWWflows is varied and the number of TCP long flows is kept equal to 2.In addition to2 long TCP flows, it can be seen that if we assume a threshold of 3.0 for Qmin, thenwith PF at most 22 WWW users can be supported in the system. On theother hand,with RG up to 40 WWW users can be supported and still the satisfaction to the 95%of video users can be provided. With the NRG scheduler we see again that the valueof Qmin remains stable as it is unaffected by the load generated by the BE traffic.

Figure 7.13 shows the CDF of the download times per single web page experiencedby users when 22 WWW users are allowed in the system. It can be seen that the CDFfor the RG scheduler there is only slight deterioration in comparison to that of the PFand RR ones. With NRG scheduler, the deterioration is more because of the trade-off


between video quality and BE throughput. However, the NRG scheduler still performsgood enough in comparison to the CI scheduler that in turn has has a “long” tail i.e.the download times were high for a large percentage of users with CI scheduler.

7.5.4 Evaluation using PSNR

In this section we evaluate the video quality with the PSNR metric. The reason for thisevaluation is to complement1 the previous results obtained using the PSQA metrics.As an extension, we use B frames, in addition to I and P frames,in the encoded videoand use an additional video stream coded at≈ 128kbps. The target average bitratesof the encoded video streams are controlled using the quantization parameter of theH.264 codec. Fig. 7.14 shows the bitrate versus time for the video users. The bitrateof the different I, P and B frames produced by the codec is alsoshown. The GOP sizeis 32.

The simulation parameters are same as before except the following. We againassume four video users but, the “average” bitrate for two video users is 128 kbps andfor the other two video users is 360 kbps. The value ofQ is 128 packets for 360 kbpsusers and 60 packets for 128 kbps users. The value ofdmax= 500m. As done before,in section 7.4.2, the rate guarantees are set slightly higher than the actual video bit rate.This is done in order to accommodate for the burstiness in thevideo bitrate as seen inFig. 7.14.

Figure 7.15 compares the original RG scheduler by Hosein [64], given by (7.4), andthe NRG scheduler when the value ofnBE is increased. It can be seen in Figure 7.15(a)that the average loss rate almost doubles with the RG scheduler asnBE is increased,whereas it remains stable with the NRG scheduler. Note that wecompare the byteloss rate (LB = (bytes lost)/(bytes sent)) instead of packet loss rate because of thevariable packet size. A similar observation can be made for the average peak signal-to-noise ratio (PSNR) values of the received videos in Figure7.15(b), i.e., with the RGscheduler the average PSNR deteriorates when the BE load is increased as shown inFigure 7.15(c). The difference in Figures 7.15(c) and 7.11 is because of the fact thatdmax = 500m for the former anddmax = 300m for the latter. A higher value ofdmax

means that the video users can be present further away from the BS. This means thatthere are more chances of the video users encountering bad channel, requiring morescheduling resources, that in turn decreases the BE throughput.

1One reason to employ PSNR to further test the NRG scheduler isthat even though the qualityevaluation with PSQA tool is very fast, the PSQA tool training is a time consuming process. Thus,PSQA training was done only once, but during that there were certain limitations that the training wasdone using the≈ 360kbpsvideo stream only and the possibility of using B frames was limited with theversion of the codec used. However, we would certainly like to extend the PSQA tool as future work.

Results 129

50

100

150

200

250

0 10 20 30 40 50 60 70

Bitr

ate

(kbp

s)

time (s)

I + P + B framesI + P frames

I frames

(a) average 128kbps

100

200

300

400

500

600

700

0 10 20 30 40 50 60 70

Bitr

ate

(kbp

s)

time (s)

I + P + B framesI + P frames

I frames

(b) average 360kbps

Figure 7.14: Bitrate vs time for the encoded video streams.


3

4

5

6

7

0 10 20 30 40 50

L B (

Byt

e lo

ss r

ate

%)

Number of TCP flows

128 kbps RG360 kbps RG

128 kbps NRG360 kbps NRG

(a) Loss rate

36

37

38

39

40

41

42

0 10 20 30 40 50

aver

age

PS

NR

(dB

)

Number of TCP flows

128 kbps NRG360 kbps NRG

128 kbps RG360 kbps RG

(b) PSNR

0.8

1.0

1.2

1.4

0 10 20 30 40 50

Thr

ough

put (

Mbp

s)

Number of TCP flows

RGNRG

(c) BE throughput

Figure 7.15: Comparison of RG (Hosein) and NRG scheduler.

Results 131

0

1

2

3

4

5

6

32 64 128 256 384 512

loss

(%

)

Users with Rate Guarantees (kbps)

NRGNRG Hosein

NRG Lundevall

Figure 7.16: Loss rate for users with different rate guarantees.

7.5.5 Comparison of loss rates

Another set of simulations were run with six video users and with nBE = 28. Thesimulation parameters are same except the following. The video flows are modeled byCBR sources instead of using the real video traces. At the client side, the packets thatare delayed by more than 4 s are dropped. The values ofλmin and sending rates forthe six video users are 32, 64, 128, 256, 384 and 512 kbps. Per-user drop-tail queuesholding up to 2 s of video data are used at the RNC and video packet size is 500 bytes.

In order to look at the bias towards certain rate guarantees,we compare NRG,“NRG-Hosein” (i.e., takingBi(t) for QoS users from (7.4) and for BE users from(7.8)) and “NRG-Lundevall” (i.e., takingBi(t) for QoS users from (7.5) and for BEusers from (7.8)). For the last two “hybrid” schedulers, we took theBi from NRG,∀i ∈ B , so as to remove the sensitivity to BE load, in order to focus only on the effectof λmin values. Nevertheless, theBi(t) functions for QoS users werenot normalizedfor the last two schedulers. The value ofβ for the last two schedulers is 3.125·10−5

andkBE is 4.5 when the rates are in bps. The value ofα is 1.25 for the “Lundevall”variant given by Eq. (7.5). The values ofβ andkBE for NRG are the same as in thefirst set of simulations with video traces. For a fair comparison, the above parameterswere chosen such that the loss rates were minimal and the capacity (total guaranteedrate + total TCP throughput) obtained was the same and equal to2 Mbps. Fig. 7.16shows the loss rates for different QoS users. It can be seen that the NRG-Lundevallscheduler is biased towards the low bit rate users. NRG thus improves greatly uponNRG-Lundevall and slightly upon NRG-Hosein (as overall loss rate is less for NRG)in terms of providing fair loss rates to different QoS users.


7.6 Discussion and Conclusions

In this chapter, we focused on streaming H.264-coded video over HSDPA and wereinterested in evaluating the impact of different HSDPA schedulers on the video quality.This is a novel study that focuses on such evaluation based onSubjective Quality.

For evaluating the performance we considered mixed traffic scenarios. QoS usersstreamed video on their equipment while Best-Effort (BE) users were represented bylong-lived TCP flows and WWW flows. WWW users were modeled using demands interms of download sizes and thinking times with statisticalproperties that have beenestablished in the literature before. Though we do not claimof using very realistictraffic scenarios, we think that a reasonable mix of traffic was considered.

We also used a QoS-aware queuing mechanism called RIO in the radio buffers, toprotect the video packets considered as important by the decoding process. In com-parison to RIO, results showed that indeed DropTail (DT) queuing was degrading thequality by dropping the important packets when the situation of ultimately having todiscard a packet arrived.

Different HSDPA schedulers were compared in terms of their impact on the videoquality. Quality experienced by users was evaluated using atool that yields good esti-mates of the user-perceived quality. We proposed a new scheduler called NormalizedRate Guarantee (NRG) that is based on an existing Rate Guarantee(RG) scheduler.It was shown that the NRG scheduler improves upon the RG scheduler as it does notdeteriorate the quality of the QoS flows when the load of the best-effort users is in-creased. Moreover, the NRG scheduler provides fair loss rates irrespective of the rateguarantees of the different QoS users.

Our focus was on achieving a video quality higher than a minimum threshold toat least 95% of the video users. While testing the 384-kbps video streaming serviceit was clear that, for our cell configuration, the full cell could not be covered andbandwidth would be wasted by users getting an unacceptable video quality. Thus,some approaches to limit access to the service were considered. First, the cell coveragelimit of video users (in terms of maximum distance between the UE and the BS) wasstudied. After that the maximum video user distance was fixedand the limit in termsof number of users that can be admitted in the system was studied.

Further, it should be noted that no handovers are consideredas a single cell2 isanalyzed in our study; taking handovers into account is leftfor future work. Moreover,an admission control algorithm that limits the access to thechannel, based on the user’sdistance from BS, remains theoretical. A real implementation of CAC would have tomonitor the channel quality for some time before taking the decision regarding theadmission of the user. Another desired, but not implemented, property would be theautomaticre-negotiation of e.g. the video bit rate, if the channel conditions becomebad during the connection.

2Nevertheless, inter-cell interference is accounted for inthe physical layer model of the simulator.

Discussion and Conclusions 133

In terms of the maximum number of users that can be served at one time and thecell coverage in terms of maximum distance for the video users we found that QoSaware schedulers, RG and NRG, performed better. For the low load conditions all thefair schedulers like RR and PF gave good performance but as theload was increased itwas only QoS schedulers that were able to guarantee a minimumquality to the 95% ofthe video users. The tradeoff was the lower per-user throughput that the BE users weregetting in comparison. Nevertheless, the QoS-aware schedulers were still dividingthe remaining capacity among the BE users in a fair manner and were significantlybetter than the Max C/I scheduler. Moreover, though the use ofQoS-aware schedulingresulted in lower per-user throughput for long TCP flows it didnot noticeably degradethe download times of the WWW users in the case of RG scheduling.


Chapter 8

Proportional Resource Partitioningover Shared Wireless Links

It is relatively easy to partition resources over wired linkswith known link capacity.Nevertheless, such partitioning is complex for wireless links with variable capacity;due to the dynamic nature of the link, it is difficult to effectively allocate the resources(i.e., time slots) between users who may be paying different prices for different ser-vices. In this chapter we study the general problem of resource partitioning for sharedwireless links like HSDPA. We consider different QoS classesor user groups, and theuse of MAC-layer scheduling for resource partitioning between groups and between in-dividual users. We propose a variant of an existing HSDPA scheduler called RequiredActivity Detection (RAD) scheduler. The proposal is studied by means of packet-levelsimulation.

8.1 Introduction

The shared downlink radio channel used in HSDPA is a challenging environment foreffective resource partitioning. The problem remains to partition the resources effec-tively between different QoS classes or different users whomay be paying differentprices for different services.

In this chapter we study the general problem of resource partitioning for sharedwireless links like HSDPA. We consider different QoS classes or user groups as shownin Figure 8.1, and study how resource allocation among thosegroups may be doneusing HSDPA MAC-layer scheduling. We focus on the case in which one of the classesconsists in best-effort users. In order to perform hierarchical link sharing (i.e., betweenQoS classes and then between users in each class), a variant of a recently proposedscheduler called Required Activity Detection scheduler [82] is proposed, as well as away of sharing link capacity while trying to avoid starvation of best-effort users.

135

136 Proportional Resource Partitioning over Shared Wireless Links

c j

c 1

Per User Queues Scheduler

QoS Class 1

QoS Class j

Figure 8.1: Resource partitioning among different user groups.

8.2 Weighted Proportional Resource Partitioning

Let us consider a “long” session of durationT ∈N+ time slots, during which there are

N active users. Over this long time interval, useri = 1, . . . ,N will get xiT time slots,with xi ∈ [0,1], so that∑i xi = 1. We will call xi thescheduling rate. It was shown in[36], assuming that the channel quality variations are statistically equal for all users,that a PF scheduler divides the time slots “almost equally” between the users, so wemay consider:xi = 1/N∀i.

Now suppose we want to partition the time slots in a desired manner(xT1 , ...,xT

N),wherexT

i ∈ [0,1] is the target scheduling rate for the useri. Following [36], it can beshown that a scheduler that picks the useri∗ given by:

i∗ = argmaxi

{

xTi Ri(t)/λi(t)

}

(8.1)

approximately allocates the time slots among users such that xi = xTi . Note that, from

chapter 6, such a scheduler corresponds to the user utilityUi(λi) = xTi log(λi) and the

general scheduler:

i∗ = argmaxi

{

Ri(t) ·U′i (λi(t))

}

. (8.2)

Remark also that the PF scheduler, given by equation (6.2) in chapter 6, is a particularcase of equation (8.1), i.e., whenxT

i = xT ∀i.This concept can be used to divide resources among differentuser groups or classes,

then among users inside each class in aweightedproportionally fair way. This may beachieved by using the scheduler equation (8.1) with appropriate weightsxT

i , as follows.Let us now considerM QoS classes, withS j the set of class-j users, soNj = |S j | isthe total number of users in classj = 1, . . . ,M. Then, the resources can be dividedamong differentQoS classesusing thecumulative(per-class) target scheduling rates

Weighted Proportional Resource Partitioning 137


Parameter Default ValueEURANE default configuration see chapter 7RTT Internet 60 to 100 ms (variable)RTT UMTS core 50 msRNC per-user buffer 30 packetsVideo Packet Size 500 bytesBE flows: TCP version Newreno

Packet Size 1000 bytesReceiver Window 10000 packets

(cT1 , ...,cT

M), wherecTj ∈ [0,1],∀ j and∑ j c

Tj = 1. Further, the resources allocated to

each class can be distributed among its users such that the target scheduling rate of useri of classj is xT

i , under the constraint∑i∈S jxT

i ≤ cTj . The strict inequality∑i∈S j

xTi < cT

jcorresponds to the situation where some resources are kept reserved to be allocatedduring congestion, i.e., when some QoS users are not gettingtheir guarantees.

We illustrate this concept by means of simulation results. The default configurationfor EURANE, the HSDPA extension to ns-2, is same as that in chapter 7. Table 8.1shows the parameters related to the simulation topology andsimulation traffic. Letus considerM = 2 groups of users (i.e., QoS classes). The number of users in eachgroup isN1 andN2, respectively. The target scheduling ratesxT

i for the group-1 andgroup-2 users are chosen ascT

1 /N1 and(1−cT1 )/N2, respectively1; that is, the desired

cumulative scheduling rate of group-1 users iscT1 and that of group-2 users is 1− cT

1 .Figures 8.3 and 8.4 show the ratio of obtained cumulative scheduling rate of group1 to the target cumulative scheduling ratecT

1 , for different values ofcT1 , N1 andN2.

Each simulation run corresponds toT = 340,000 time slots and the users are locatedrandomly in the cell. It can be seen that the obtained scheduling ratec1 is close tocT

1 asthe ratio of both is close to 1, except for the case where very few users (N1 = N2 = 4)are there in the system2.

8.2.1 A lower QoS class as a single virtual user of a higher class

There is also a certain hierarchy among the different QoS classes, i.e., some classesare to be given more priority than the others. The concept of weighted proportionalscheduling can be extended to “hierarchically” divide the time slots among differentclasses, then among users of each class, over shared wireless links like HSDPA.

1In this example, for the sake of simplicity we have chosen identical weights for all users in a givenclass, but note that this does not need to be so.

2This could be due to the lack of multiuser diversity.


Per User Queues

QoS Class 1

QoS Class 2

Scheduler

c 1

c 2

Total

Total Virtual User

Figure 8.2: A lower QoS class as a single virtual user of a higher class.

Consider now the case in which there is an additional class corresponding tobest-effort (BE) users, that is, users running elastic data applicationslike file transfer, Webbrowsing, etc. Existing schemes often allocate resources in such a way that the BEusers are not guaranteedany time slots; they only get the residual time slots after theQoS requirements of the other users are satisfied. This type of resource allocation,performed by schedulers like those in [64] and [82], can cause instability, in the sensethat during congestion periods the BE users will be starved. Note that even a singleuser in a higher-QoS class, suffering with bad channel quality (even if temporarily),can cause starvation to the BE users. Starvation will last at least for the time neededby the RNC to step in and take appropriate congestion control measures. Moreover, ifwe considerM > 1 higher-QoS classes, in general the chance of the BE class gettingstarved increases withM and the number of users in higher-QoS classes.

In order to avoid the above problems, we propose that a lower class be considereda single virtual user of the next higher-QoS classas shown in Figure 8.2. This typeof allocation is then applied iteratively for all the other classes. Coming back to ourexample, the whole BE class be considered as a single virtual user of the next higher-QoS class. The resources allocated to this virtual user are then further divided amongthe “real” users in that class. Thus, the resources guaranteed to every BE user arenot nil, since some amount of time slots are reserved for the whole class. Duringcongestion, the degradation in service will be shared in proportion to the resourcesallocated to the virtual user and all the users in the BE class.

8.3 Partitioning Strategies for Video-Streaming and Best-Effort Users

Without loss of generality, in what follows we will consideronly two QoS classes.We will apply the principles described in Section 8.2 to the particular case in which

Partitioning Strategies for Video-Streaming and Best-Effort Users 139

1

1.05

1.1

1.15

1.2

0 0.2 0.4 0.6 0.8 1

Rat

io (

Act

ual/T

arge

t)

Target Scheduling Rate

N1 = 10, N2 = 10N1 = 10, N2 = 20N1 = 10, N2 = 30N1 = 10, N2 = 40

Figure 8.3: Ratioc1/cT1 . Group 1 hasN1 = 10 users.

one classV corresponds to video streaming (VS) users, and the other classB to best-effort (BE) users. The number of users in each class will be noted byNVS andNBE,respectively. Video streaming users have some requirements in terms of maximumaffordable delay and guaranteed data rate. Delay requirements of VS users are not asstrict as those of real-time users. This is because, in a video streaming scenario, thereis usually an initial time delay (on the order of a few seconds) before the client starts toplay the video. During this time the data gets stored in a buffer and later on this bufferis used to absorb the delay and jitter of the arriving packets.

8.3.1 No guarantees to BE users

In [82], Kolding proposed a novel scheduler called RAD (Required Activity Detection)that calculates the scheduling ratemi needed by a useri of classV , so as to provide arate guaranteeλmin

i , as:

mi = λmini /λsch

i (8.3)

Here, λschi is the moving average of the scheduled bit rate of useri, estimated us-

ing (6.3) except that if the user is not scheduled at timet thenλschi (t) = λsch

i (t−∆t);also, a small value ofτ is chosen to allow a faster tracking ofλsch

i (t). Note that, ingeneral,∑i∈V mi can take any value in[0,∞) depending on the resources “needed” bythe users of theV class.

BE users only get residual time slots, as follows. If∑i∈V mi < 1, then the residualpercentage of time slots 1−∑i∈V mi is shared by BE users such that:xT

i = mi,∀i ∈ VandxT

i = (1−∑i∈V mi)/NBE,∀i ∈ B . On the other hand, if∑i∈V mi > 1 then VS users


1

1.05

1.1

1.15

1.2

0 0.2 0.4 0.6 0.8 1

Rat

io (

Act

ual/T

arge

t)

Target Scheduling Rate

N1 = 4, N2 = 4N1 = 4, N2 = 8

N1 = 4, N2 = 12N1 = 4, N2 = 16

Figure 8.4: Ratioc1/cT1 . Group 1 hasN1 = 4 users.

are not getting the required resources, i.e., “more than 100%” of the slots would beneeded to satisfy the minimum bit-rate requirements. In that case the BE users donot get any time slots, and VS users get a reduced proportionxT

i = mi · (∑i∈V mi)−1

of the time slots. Thus, (relatively) slowly adapting values of the cumulative targetscheduling ratescT

VandcT

B are used, and during congestion the resource partitioningis such thatcT

V= 1 andcT

B = 0.

8.3.2 BE users as a single virtual QoS user

Assume now that BE users are handled by the proposed allocation scheme of Sec-tion 8.2.1. For this purpose, we introduce a variant of RAD scheduling that we callRAD2. We allocatecT

B > 0 resources to theB class andcTV

> 0 to theV class asfollows. For VS users, we takexT

i = mi (with mi computed as before), and for BEusers we takexT

i = cTB /NBE ∀i ∈ B . This allocation remains the same whether “tem-

porary” congestion is there or not. During congestion the degradation in the service is,automatically, in proportion to the allocated resources. Note that thexT

i above shouldbe normalized to make their sum equal to 1 but, since the normalization factor is acommon term for all users of both classes in the equation (8.1), this factor can bediscarded.

In order to evaluate the performance of this type of resourceallocation, we measurethe throughput obtained by BE users and look at the satisfied percentage of VS users.In the simulation, the VS users are modeled using 100 kbps CBR (Constant Bit Rate)flows, andsatisfied usersare those whose 90% of data is neither lost nor delayed more


2.0

1.5

1.0

0.5

0 5 10 15 20

Bes

t Effo

rt th

roug

hput

(M

bps)

Number of Video users

RADRAD2, cBE = 0.4RAD2, cBE = 0.3RAD2, cBE = 0.2RAD2, cBE = 0.1

Figure 8.5: BE throughput versus total number of VS usersNVS.

than 3 s. This maximum delay is rather pessimistic if we consider a typical initialplay-out delay of the order of 8 seconds. The duration of video flows is 67 s. BE users(20 long-lived TCP flows, which is a good amount of load for the system) are started5 s in advance, making for a total simulated time of 72 s. 40 independent simulationruns are performed to get good confidence in the results. Every user’s distance fromthe BS is chosen randomly. A minimum video rate guarantee ofλmin

i =110 kbps∀iis chosen, i.e., 10% higher than the actual rate of a CBR flow, to accomodate channelquality fluctuations.

Figure 8.5 shows the “average” throughput obtained by BE users; that is, we cannottell if some individual BE users were starved, however, we can tell the amount ofcumulative data downloaded, in Mbps. Figure 8.6 shows the proportion of unsatisfiedVS users. The results compare the RAD and RAD2 schedulers with increasing numberof VS users and different values ofcT

BE for RAD2. The trade-off when comparingRAD2 with RAD can be seen in both the figures. When VS users are few,the RADscheduler gives slightly better throughput to BE users, because of the high value of1−∑i∈V mi. Nevertheless, as the number of VS users is increased the starvation ofBE users is faster with RAD, in comparison to RAD2. This is because no resourcesare guaranteed for BE users with RAD. Moreover, RAD2 performs better in the regionwhere the percentage of unsatisfied VS users is low in general. The region of lessunsatisfied users is normally chosen (using Call Admission Control) as the desiredoperating region in order to provide good service to most of the users already admittedin the system. Thus, RAD2 improves upon RAD for the studied environment.


0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 5 10 15 20

Uns

atis

fied

Use

rs (

ratio

)


RADRAD2, cBE = 0.4RAD2, cBE = 0.3RAD2, cBE = 0.2RAD2, cBE = 0.1

Figure 8.6: Ratio of unsatisfied VS users versusNVS.

8.3.3 VS users employing rate control

VS users can also employ rate-control schemes like [52] to send their data. In thecase of RAD scheduling, due to the way residual time slots are shared, these userswill not be able to get a higher data rate than the guaranteed bit rate. However, ahigher data rate may be beneficial as users can finish the streaming of the video inadvance, thus, leaving the channel empty for other users. Moreover, during congestionperiods they can back-off to prevent data packet loss. When channel conditions aregood, they can send at a higher data rate to buffer video data in the client, that inturn can be utilized to absorb the congestion periods. Usinga resource allocationsimilar to RAD2,cT

Vresources are allocated for VS users, and the resources needed

for satisfying the rate guarantees are automatically provided using the value ofmi . Theresidual resources are then shared among the other users that can send at a higher ratethan theirλmin

i and also with the BE users, in a proportional way. This improvement isconfirmed in Figures. 8.7 and 8.8. The simulations are done ina similar way as before,except that the video users use rate control (TCP based) and only those lost packets areretransmitted that may arrive before their play-out deadline3. Here, an initial play-outbuffer of 8 s is assumed, and an unsatisfied user is one whose buffer underflows (evenonce). One curve from the previous CBR scenario is also included in the figures forreference.

3The retransmissions are not optimized, e.g., by retransmitting more important packets before theless important ones in addition to taking into consideration certain parameters like the packet deadline,network delay. However, chapter 11 addresses this issue.


2.5

2.0

1.5

1.0

0.5

0 5 10 15 20

Bes

t Effo

rt th

roug

hput

(M

bps)


RAD(ref.) CBR, cBE = 0.3

RAD2, cBE = 0.3RAD2, cBE = 0.2RAD2, cBE = 0.1

Figure 8.7: BE throughput versusNVS, using rate control.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 5 10 15 20

Uns

atis

fied

Use

rs (

ratio

)


RAD(ref.) CBR, cBE = 0.3

RAD2, cBE = 0.3RAD2, cBE = 0.2RAD2, cBE = 0.1

Figure 8.8: Ratio of unsatisfied VS users versusNVS, using rate control.


8.3.4 Congestion control based on available resources

Let us define the load factorρ j for class j as: ρ j = ∑i∈S jmi . Moreover, the total load

in the system can also be defined asρ = ∑ j ρ j and wheneverρ < 1 the system is notcongested and vice versa. Hence, wheneverρ j > cT

j , users of classj are not gettingtheir guarantees if the maximum allocated scheduling rate for them iscT

j . Thus, inorder to do congestion control, the RNC can keep track of this load factor for all theQoS classes and try to bring down the load, for instance by either increasing the BStransmission power or by dropping the user needing a high scheduling rate but havinga bad channel quality (indicated by a low value ofλsch

i ).

8.4 Conclusion

In this chapter we studied a general problem of resource partitioning for shared wire-less links like HSDPA. It is relatively easy to partition resources over wired links withknown link capacity. Nevertheless, such partitioning is complex for wireless links withvariable capacity. We discussed the concept of using HSDPA MAC-layer schedulingfor resource partitioning, and some concepts like resourceallocation for the QoS usersemploying rate control schemes and congestion control at the RNC. We proposed thatthe lower classes be considered as a virtual user in the higher QoS classes. A variantof an existing scheduler was proposed and studied using a detailed HSDPA simulator.The results show improvements in the form that the new variant gives lower proba-bility of unsatisfied QoS users in the operable region, and prevents the starvation ofbest-effort users.

Part III

Congestion Control for Video Flows

145

Chapter 9

TCP-Friendly Rate Control overHigh-Speed Downlink Packet Access

TCP-Friendly Rate Control (TFRC) is an end-to-end congestion control mechanism,whose goal is to provide rate control for unicast flows in IP networks. The main fea-ture of TFRC is its ability to smoothly adapt the sending rateof a flow to networkconditions, while competing for bandwidth with TCP flows in a relatively fair manner.TFRC was designed to offer a more stable sending rate than TCP onwired, best-effortnetworks, making it suitable for applications like multimedia streaming.

This chapter presents a simulation study of TFRC over UMTS networks with High-Speed Downlink Packet Access (HSDPA). We evaluate the performance of TFRC andcompare it with that of TCP, under different scenarios of MAC-layer scheduling, radioconditions and background traffic. Our results show that, inthis context, the ratestability of TFRC is not necessarily better than that of TCP, and that the performanceof TFRC may be greatly improved by the use of an appropriate QoS scheduling policyfor HSDPA.

9.1 Introduction

Multimedia applications should use some form of congestioncontrol in order to adaptthe sending rate to the available bandwidth, hence preventing the network from suffer-ing from congestion collapse. In cellular networks, the available bandwidth can changerapidly due to typically varying channel conditions; this together with the shared natureof the wireless channel in HSDPA networks, makes the rate control a desired feature.

TFRC [53] is an end-to-end congestion control mechanism suitable for applicationswith constraints on rate stability, like voice or streamingmedia. It has been designedto adapt the sending rate of a flow in a smooth manner, while trying to fairly share theavailable bandwidth with competing TCP flows. TFRC is an Internet standard [59],

147

148 TCP-Friendly Rate Control over High-Speed Downlink Packet Access

and it has been adopted at the IETF as one of the congestion control profiles that maybe used with the DCCP transport protocol [51]; TFRC may also be implemented byUDP-based applications wishing to perform congestion control.

This chapter presents a simulation study of TFRC over UMTS networks support-ing HSDPA. Since we are interested in video streaming applications, we evaluate theperformance of TFRC in terms ofrate stabilityover different time scales, and compareit with that of TCP. Several scenarios of MAC-layer scheduling, radio conditions andbackground traffic are considered.

9.2 Congestion Control

9.2.1 Transmission Control Protocol (TCP)

Today’s Internet stability is due to TCP [133, 3, 4, 70]. TCP adapts its sending ratedynamically to the available bandwidth and backs off when itdetects congestion. TCPuseswindowbased flow control, and employs feedback and timeouts to detect a packetloss that in turn is assumed as the sign of congestion. In the absence of congestionor losses, TCP keeps on probing for the available bandwidth byincreasing its sendingrate. TCP starts in a state calledslow-start, that in fact is not slow but is roughlyexponential, where it doubles its sending rate every RTT (Round Trip Time). When itreaches the steady state calledcongestion avoidance, it probes the bandwidth linearlyusing Additive Increase and Multiplicative Decrease (AIMD).

TCP represents a very efficient transport protocol in generaland is suitable for datatransfer. However, it has been argued [52] that TCP is unsuitable for video streamingbecause strict delay and jitter requirements of video streaming are not respected byTCP. Moreover, TCP retransmissions are unnecessary for videoas most video codecsare robust to small losses and most of the time the retransmitted data may miss thearrival deadline and become obsolete. This has led researchers to look for alternativeoptions that will be discussed in the sections below.

Nevertheless, TCP is a good paradigm of an efficient transportprotocol and someworks exist [96, 23, 88] that use TCP for multimedia applications. Till now somepopular Video on Demand (VoD) systems, e.g., [2], use TCP as their transport protocol.This is mainly because of the non-availability of other options. Some other reasons arethat the delay/jitter constraints are less strict for VoD and alternative protocols likeUser Datagram Protocol (UDP) are filtered-off in many firewalls.

9.2.2 Congestion Control for Video Flows

Most of the work related to congestion control for video flowshas either emulated TCPor has used the TCP model. Rhee et al. [114] developed a flow control scheme called

Congestion Control 149

TCP-emulation at the receivers (TEAR). All the processing of the congestion signalis done at the receivers and a smooth value of the emulated TCP rate is calculated inorder to avoid rate fluctuations.

Sisalem et al. [132] used AIMD algorithm combined with the RTP [5] function-alities. A packet pair technique, described by Bolot [31], isused to determine thebottleneck bandwidth. This technique works on the principle that if two back-to-backpackets pass through the bottleneck then the packets are spread out by the transmissiontime of the second packet over the bottleneck. From this spacing the sender is able todetermine the bottleneck bandwidth.

Rejaie et al. [113] proposed a Rate Adaptation Protocol (RAP) that is arate basedTCP friendly protocol. It uses the AIMD algorithm to adapt itssending rate everyRTT. RAP detects loss clusters caused by a single congestion event and losses presentin a cluster are ignored to react only once. It also does fine-grained rate adaptation,in order to be more responsive and stable to transient congestion, by fine tuning thesending rate by the ratio of short and long term moving averages of RTT.

Kelly in [78] presented a game-theoretic congestion control method based on ad-ditive increase and multiplicative decrease scheme. Kellyapproached the problem ofnetwork congestion by making it an optimization problem where system has to opti-mize the aggregate user utility [122] and as well as respect the constraint that aggregaterate of users should not exceed the system capacity.

Other works on rate control exist, like [22] which proposes an architecture forH.264 unicast video streaming using SCTP. It makes use of the fact that SCTP providesmore granularity in terms of reliability by providing multiple streams having differentattributes. WMSTFP [143] is another TCP friendly solution which can be used whereonly the last hop is wireless. It relies on the MAC layer to provide statistics related tothe wireless losses and uses it to adapt its sending rate. WMSTFP violates the end-to-end approach as it relies on the MAC layer.

9.2.3 TCP-Friendly Rate Control (TFRC)

TFRC congestion control consists in an equation-based rate control mechanism, de-signed to keep a relatively steady sending rate while still being responsive to conges-tion. A TFRC sender adjusts its rate as a function of the measured rate ofloss events,where a loss event consists in one or more packets dropped1 within a single round-triptime.

In order to compute a TCP-friendly sending rate, TFRC uses the following TCPresponse function[53] which models the behavior of a TCP flow:

T =s

R√

2p/3+ tRTO(3√

3p/8) p(1+32p2)(9.1)

1Or marked, if Explicit Congestion Notification (ECN) [112] is used.


where the sending rateT, in bytes/sec, is modeled as a function of packet sizes, roundtrip time R, steady-state loss event ratep, and the retransmission timeout valuetRTO.

Note that (9.1) uses aloss event raterather than the packet loss rate. This is becausedifferent versions of TCP congestion control generally reduce the congestion windowjust once, in response to several losses in a single round trip time (RTT). Thus, inTFRC the loss behavior of TCP is emulated by explicitly ignoring the subsequentlosses, within an RTT, that follow an initial loss. Remark that the loss event rate willgenerally differ from the packet loss rate [52].

TFRC computesp as a weighted average of the most recentn loss intervals (typ-ically, n = 8), where a loss interval corresponds to the number of packets receivedbetween two consecutive loss events. The weights have been chosen so as to obtain agood trade-off between responsiveness and rate stability [53]. A history discountingmechanism [52] may be added to the computation ofp, in order to render TFRC morereactive to sudden decreases in the loss rate.

The value ofp is calculated by the receiver and fed back to the sender by meansof feedback messages. Such messages may be produced at a rateof one message perRTT, but they may also be sent as soon as, say, a loss event has been detected. Thesender also uses the feedback messages to keep an estimateR of the round-trip time.This estimate may be obtained by simply applying an exponentially-weighted, movingaverage (EWMA) filter to RTT samples; however, an optional, more robust estimatoris proposed in [59], with the goal of avoiding rate oscillations in scenarios with a lowdegree of statistical multiplexing.

Instead of computing the retransmit timeouttRTO as TCP does, TFRC uses theheuristic approximation:tRTO= 4R. Every time a feedback message is received, thevalues ofp, RandtRTOare then used by the sender to compute the appropriate emissionrate using (9.1). The sender handles a timer for dealing withthe case in which nofeedback is received for a “long” period (essentially, the sender divides its rate by 2when the timer expires after 4 RTTs without any feedback). Also, a “slow start” phase,similar in spirit to that of TCP, allows the sender to roughly double its rate each RTTas long as there are no losses.

9.3 Related Work

A few papers have been devoted to studying the performance ofTFRC over UMTS net-workswithout HSDPA enhancements. For instance, Velev et al. [136] studied videostreaming over UMTS. They used the rate control mechanism ofTFRC for “dynamicswitching” between video streams when available bandwidthchanged. It was foundthat the rate control and feedback features of TFRC improved the quality of videostreaming even during handovers. De Cicco and Mascolo [43] found that TFRC andTCP showed similar burstiness in an UMTS scenario, contrary to what can be expected

Simulation Models and Scenarios 151

INTERNET

GGSN SGSN Servers

UMTS CORE NETWORK

UTRAN

RNCBS

UEs

RTT Internet

Iub

IuPS

Gn

Uu

Figure 9.1: UMTS video streaming scenario.

in the wired Internet where TFRC gives a smoother rate than TCP.Alexiou et al. [19]analyzed the performance of TFRC over UMTS; the HSDPA scenario was identifiedas a future step. A general analytical study of TFRC was done byXu et al.[142].They proposed a model for the TFRC client buffer2. Landstrom et al. [84] comparedthe performance of TFRC and TCP SACK over HSDPA, using the RR and CI sched-ulers and a custom simulation model of HSDPA. However, the traffic model used wasrepresentative of short-lived WWW flows.

The contributions of this work with respect to previous works are as follows. First,we assess the performance of TFRC over HSDPA using a very detailed, publicly-available simulation model [1]. Since TFRC has been designedmainly for streamingmedia applications, we consider long-lived flows as done in [53], and focus on per-formance metrics relevant to streaming. Lastly, we includea QoS scheduler for theMAC-layer (i.e., the RG scheduler [64]) that can give rate guarantees to the flows.

9.4 Simulation Models and Scenarios

We have considered the generic simulation scenario depicted in Fig. 9.1, in which UEsconnect to video and data servers on the Internet. HSDPA functionalities are deployedin the UMTS Terrestrial Radio Access Network (UTRAN).

We consider two scenarios to study TFRC and to compare its performance withthat of TCP. In the scenario called Case I, we only consider long-lived flows that lastfor the whole duration of the simulation. A total of 5 TFRC longflows (representingvideo flows) and 5 TCP long flows (representing the background traffic) is used. Whilemodeling the video flows we consider the streaming scenario where a pre-encoded

2The buffer that is used to store the received video data before its play-out.


Table 9.1: Assigning rate guarantees.

Distance Rate guarantee0 – 150 m 300 kb/s150 – 300 m 200 kb/sMore than 300 m 100 kb/s

video file is streamed from a server to the client. The client uses a play-out buffer, ofthe order of 4 to 8 seconds, to smooth out the jitter in the arriving packets. The sendingrate is controlled using a congestion control protocol, i.e., TFRC. It should be notedthat the emphasis is not on the video per se, but more on the feasibility of using TFRCfor a streaming application in the studied scenario.

Only one TFRC flow and one TCP flow are monitored and the distancesof thecorresponding UEs, from the BS, are set at a given value for a given configuration. Thedistances of the other UEs are chosen at random with a maximumvalue correspondingto the cell radius. In the scenario called Case II, 3 TFRC long flows, 3 TCP long flowsand 38 TCP WWW-like flows are used. As in Case I, only one TFRC flow and oneTCP flow are monitored and all other UEs are randomly placed in the cell. A simpleon-off, session-level model of WWW traffic is used, in which downloading of a “file”is followed by a “thinking time”, after which the user will initiate a new download.File sizes follow a truncated Pareto distribution with an average of 10 KB and withshape parameter equal to 1.2; sizes are truncated at a minimum value of 100 bytesand a maximum value of 2 MB. Thinking times are modeled using anexponentialdistribution with an average of 5 s.

For the RG QoS scheduler, discussed in the section 6.3.4 of thechapter 6, thesimulations are run in a slightly different manner. Minimumrates are assigned3 tothe flows representing video flows, according to Table 9.1. Since we are interested incomparing TFRC with TCP, we used for Case I either 5 TFRC flows or 5 TCPflows,with rate guarantees, representing video flows. The background flows were alwaysTCP long flows without any rate guarantees. This was done in a similar manner forCase II. Thus, the TCP flows representing video flows got rate guarantees but not theTCP background flows.

For a given configuration (i.e., a given set of scheduler, distance of monitored UEfrom the BS, RNC buffer size, etc.), 45 independent simulationruns of 140 s each areperformed. The default values for the main configuration parameters can be found inthe Table 9.2.

3In general, rate guarantees would be assigned using Call Admission Control and be based on themonitored channel conditions of the user. For the sake of simplicity, here we assign them based on thedistance of the UE from the BS, as channel conditions deteriorate with this distance.

Results and Discussion 153


Parameter Default ValueEURANE default configuration See [1] and [139]Configuration of schedulers See [93]Cell radius, User speed 500 m, 3.0 km/hMultipath fading environment Pedestrian ARLC mode UnacknowledgedRound Trip Times (see Fig. 9.1)

RTTinternetmonitored 80 msRTTinternet 60 ms to 100 msRTTGn,RTTIuPS,RTTIub 20 ms, 1 ms, 30 ms

TFRCPacket Size 1000 bytesLoss andRTT estimators As in [52]NumFeedback 1 perRTT

TCP NewrenoPacket size 1000 bytesReceiver window 10000 packets

9.5 Results and Discussion

In this section we discuss the results obtained under the modeling assumptions de-scribed in section 9.4. When relevant, 95%-confidence intervals are shown, except insome cases where they are omitted for the sake of readability.

First, we present a preliminary study used for choosing a value for the RNC buffersize for the remainder of the simulations. Next, we look at the impact of the differentHSDPA schedulers. Finally, we compare the performance of TFRC and TCP. Theperformance metrics considered are: average packet delay,average loss rate, ratio ofthe throughput obtained by a TFRC and a TCP flow under similar conditions, andcoefficient of variation (CoV) of the sending rate. The latteris used as a measure ofrate stability: a low CoV value means a “smoother” rate. The CoVis computed as theratio of the standard deviation to the mean of the sending rate values measured overa time windowT, also calledtime scale. The rate values for the first 20 s of everysimulation run are discarded to filter out the start-up phase.

9.5.1 RNC Buffer Size

We changed the size,B, of the RNC buffer, shown in the figure 6.5 of the chapter 6, andlooked at the averages of the packet loss percentage, packetdelay and slow-start dura-


Table 9.3: Effect of the RNC buffer size.

B lossTFRC (%) ssdTCP (s) ssdTFRC (s)(packets) 100m 400m 100m 400m 100m 400m

15 2.0 5.9 1.8 2.6 1.9 5.530 1.4 3.7 2.5 3.4 2.7 5.360 1.3 2.4 3.8 5.8 6.2 11.0100 1.7 2.0 6.7 7.6 17.4 15.0150 1.8 3.2 11.2 11.3 25.8 26.5200 2.1 3.4 15.1 15.4 36.5 30.2

tion (ssd) of the flows. It can be seen in Table 9.3 that the packet loss ratelossTFRCfirstdecreases on increasing the buffer size and then it increases, irrespective of the distanceof the UE to the BS. This is because a too small RNC buffer cannot accommodate thepacket bursts and the effects of the bandwidth variations due to channel conditions; onthe other hand, a large buffer creates a large delay that in turn may cause some videopackets to be lost due to missed deadlines. It can also be seenthat the duration of thefirst slow-start period for TCP (ssdTCP) and for TFRC (ssdTFRC) increases with thebuffer size. This is because the first loss is delayed in proportion to the buffer sizeof the initially empty “dedicated” queues. Variations of the CoV of the rate with thebuffer size are insignificant, so we do not show these results.

Figure 9.2 shows the effect of the buffer sizeB, on the average packet delay. Asexpected, the average packet delay increases withB. It should be noted from Table 9.3that B > 60 packets can be undesirable as it leads to highssdvalues, especially forTFRC flows. The value ofssdshould be of the order of the typical value of the initialdelay (say, 4 to 8 seconds) before video play-out starts in the client. Looking at theloss rates, we can say thatB≈ 60 packets is a good choice; note the trade-off betweendelay and packet loss, as a lower value ofB will give lower average packet delay buthigher average packet loss. From here onwards we fixB = 60 packets, as the averagepacket delay obtained is acceptable if the play-out buffer in the video client can hold8 s of video data, corresponding to the initial play-out delay.

9.5.2 HSDPA Schedulers

Figure 9.3 shows the average throughput obtained by a TFRC flow, as a function ofthe distance of the UE to the BS and the type of MAC-layer scheduler. Note firstthat the CI scheduler offers the worst performance, since thethroughput degrades veryrapidly with increasing distance. Besides, the large valuesof throughput obtainedby “near” users may well be wasted on streamed video flows withrelatively modestbit rates. Remark also that the plot corresponding to the RG scheduler is close to a


0 0.5

1 1.5

2 2.5

3 3.5

0 50 100 150 200Ave

rage

Pac

ket D

elay

(s)

RNC buffer size (Packets)

TFRC 100mTFRC 400m

Figure 9.2: Average packet delay for TFRC.

100200300400500600700800900

1000

50 100 200 300 400 500

Thr

ough

put (

kbps

)

Distance from BS (m)

CIPFRRRG

Figure 9.3: Per-user throughput obtained by TFRC with different schedulers.


staircase function with three “steps”, related to the threeminimum rate values shownin Table 9.1.

Figure 9.4 compares the performance of TFRC with different HSDPA schedulers.Only results corresponding to Case I are shown. It can be seen again that the perfor-mance of the CI scheduler is highly variable with respect to the distance of the UEfrom the BS. This is because the CI scheduler always gives the channel to the UE hav-ing best channel conditions. Hence, UEs that are near to the BSget the channel mostof the time, and UEs far from the BS are starved as they have relatively bad channelconditions. This is reflected in the low values of the packet delay, packet loss and CoV,for the users that are near to the BS and when the CI scheduling isused. The otherschedulers give a much fairer treatment to all the UEs, as canbe seen by the relativelybetter performance of the “far” users.

Remark also that the RG scheduler yields the minimum CoV of the rate, since ittries to keep the UE’s bandwidth close to the guaranteed rate. It should be further notedthat slightly higher delays are experienced with the RG scheduler, compared with thePF and RR ones. This is due to the fact that the guaranteed rate in our configurationwas chosen to be slightly lower than the rate a UE will get whenusing the PF and RRschedulers, as seen in fig. 9.3, and the average delay is in fact inversely proportionalto the bandwidth. Higher rate guarantees can also be chosen when the RG scheduleris used, however, there is a trade-off as the RG will take bandwidth from best-effortusers in order to satisfy such guarantees, even when the channel conditions of the“guaranteed” user become bad. To obtain a good trade-off we use a configuration forRG scheduling similar to that in [93], and assign minimum rateguarantees as shownin Table 9.1.

9.5.3 Comparison of TFRC and TCP

Figure 9.6 shows the ratio of the average throughputs obtained by terminals usingTFRC and TCP (TFRC throughput/TCP throughput) under similar conditions, i.e.,with the same scheduler, background traffic, UE distance from BS, rate guaranteeswhen using RG scheduling, etc. It can be seen that the ratio decreases as the UEdistance from BS increases, even when TFRC faces similar conditions to TCP; this ishighly visible with the CI scheduler and significantly visible with the RR and the PFschedulers. The reason is that TFRC is slower than TCP to adapt to the bandwidthfluctuations. Moreover, it can be noted that the RG scheduler improves the ratio evenfor the “far” users, since it tries to keep the throughput near to the value of the assignedrate guarantee.

Next, a comparison of TFRC and TCP was done for Case I and Case II configura-tions, using only the PF and the RG schedulers. Figure 9.5 shows the value of the CoVof the rate for TFRC and TCP users under similar conditions. We show only the resultsfor three different UE distances from the BS. It can be seen that the rate stability of


Figure 9.4: Average packet loss, delay and CoV of the rate of TFRC flows with differ-ent schedulers. The timescale for CoV is 1.0 s.


0

0.1

0.2

0.3

0.4

0.5

1 10

CoV

Time Scale (s)

TCP PF case ITFRC PF case ITCP PF case II

TFRC PF case IITCP RG case I

TFRC RG case ITCP RG case II

TFRC RG case II

(a) 100m

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1 10

CoV

Time Scale (s)




TFRC RG case II

(b) 300m

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

1.2

1.3

1 10

CoV

Time Scale (s)




TFRC RG case II

(c) 500m

Figure 9.5: CoV of rate with different schedulers and varyingdistance from the BaseStation.


0

0.2

0.4

0.6

0.8

1

50 100 200 300 400 500

Thr

ough

put r

atio

(T

FR

C/T

CP

)

Distance from BS (m)

CI case IRR case IPF case I

PF case IIRG case IRG case II

Figure 9.6: Ratio of TFRC/TCP throughput.

TFRC is better than that of TCP for short time scales. Over time scales of more than1.0 s, in comparison to TCP, TFRC shows either similar rate stability (when the UEis near to the BS) or slightly poorer rate stability (when the UE is far away), for allthe cases and both schedulers. Higher timescales are important for video streaming,because the play-out buffer of the video client can hold dataup to several seconds, soit can easily smooth the rate variation for lower timescales. In contrast, the CoV valueson lower timescales will be important for e.g. interactive video, when play-out buffersizes are smaller.

Comparing the two schedulers, it can be seen in Fig. 9.5 that the RG schedulerimproves the performance of both TFRC and TCP and results in lower values of CoV.With PF scheduling, TFRC and TCP show a poorer rate stability. The behavior ofTFRC is unlike what is usually reported in wired scenarios [53]. These differences maybe explained in terms of the use of per-flow (per-user) queues, so that the effect of otherflows sharing the resources is less in comparison to a more “conventional” scenariowith a higher degree of statistical multiplexing. Moreover, the bandwidth itself israpidly fluctuating due to scheduling; since TFRC is slower than TCP in adapting tothe bandwidth variations, it presents more rate fluctuations on higher timescales.

The faster adaptation of TCP results in the higher CoV values for lower timescales.This is made clearer in Figs. 9.7, 9.8 and 9.10. Figure 9.7 shows the trace of thereceived power at a UE 300m far from the BS, using aPed Afading environment withuser speed 3 km/h. It can be noticed that the channel conditions change both rapidlyand in a slow manner. Figures 9.8 and 9.10 show the sending rates, computed overdifferent timescales, obtained when using TFRC or TCP, and with the UE’s channelconditions varying as shown in Fig. 9.7; the rate guarantee for the RG scheduler is


-20

-15

-10

-5

0

5

10

20 40 60 80 100 120 140

Rec

eive

d P

ower

(dB

)

time (s)

Figure 9.7: Example of the received power for a UE 300m from the BS.

100

300

500

50 60 70 80 90 100 110

Thr

ough

put (

kbps

)

time (s)

TFRC RGTFRC PF

TCP PF

Figure 9.8: TFRC and TCP throughput with a timescale of 4.0 s.

Conclusion 161

100

300

500

20 40 60 80 100 120 140

Thr

ough

put (

kbps

)

time (s)

TFRC PFTCP PF

Figure 9.9: TFRC and TCP throughput with a timescale of 1.0 s, UEdistance is 300 mand the rate guarantee is 200 kb/s.

100

300

500

50 60 70 80 90 100 110

Thr

ough

put (

kbps

)

time (s)

TFRC RGTFRC PF

TCP PF

Figure 9.10: Improvement in TFRC and TCP throughput stabilitywith RG scheduler.The timescale is 1.0 s, UE distance is 300 m and the rate guarantee is 200 kb/s.

200 kb/s. Between time 80 s to 110 s, it can be seen that TCP is ableto track someof the changes in the available bandwidth4, whereas TFRC is unable to do so. Thisleads to more bandwidth for TCP over longer timescales as seenin Fig. 9.8, which isthe reason for better CoV values over longer timescales. Moreover, once again the RGscheduler improves the performance in terms of rate stability as is clear from Figs. 9.8,9.9 and 9.10.

9.6 Conclusion

In this chapter we studied the performance of TFRC over UMTS/HSDPA networksand compared it with that of TCP. Different scenarios of MAC-layer scheduling, radioconditions and background traffic were considered. We showed that TFRC did notshow better rate stability as compared to TCP except on low timescales. This is sur-

4In HSDPA, bandwidth is related to received power [62].


prising as it is unlike what is usually reported in wired scenarios. Such behavior canbe explained by the fact that in HSDPA, there is a lower degreeof statistical multi-plexing and the bandwidth itself is fluctuating due to variable radio conditions. This inturn also means a lower overall throughput for TFRC, as compared to TCP, due to itsslower rate adaptiveness.

Further, it was shown that the use of an appropriate QoS scheduler for HSDPA,i.e., a rate-guarantee scheduler, can greatly improve the performance of TFRC. Notethat, for the sake of simplicity, we assigned rate guarantees based on the distance ofUEs from the BS, as channel conditions deteriorate with this distance. In practice, rateguarantees would be assigned using Connection Admission Control (CAC), based onthe initially-monitored channel quality of the user.

Chapter 10

Improvement of MultimediaStreaming using Estimation ofWireless losses

Many networked applications use end-to-end congestion control protocols to avoidthe occurrence of congestion collapse phenomena. However, such transport protocolsmay suffer from link underutilization when there are wirelesslinks along the path: theinability to distinguish wireless losses from congestion losses often results in unneces-sary throughput decreases. Since networks are becoming increasingly heterogeneous,consisting of a mix of wired and wireless links, it is importantto have some meansof correctly identifying the cause of a packet loss, so as to adapt the response of thetransport protocol.

In this chapter, we present an end-to-end solution to this problem and propose anovel method for Wireless Loss Estimation in IP DiffServ networks (WLED). WLEDaims at enhancing the performance of equation-based rate control protocols for mul-timedia applications, by means of directly estimating the wireless and congestion lossrates. We discuss the integration of WLED with a recent, equation-based rate con-trol protocol and we evaluate WLED’s performance through simulation. Our resultsillustrate a new benefit of using DiffServ-like mechanisms for multimedia streaming inwireless networks.

Moreover, in this and the following chapters of this part, we are not interested ina detailed simulation model of, say, HSDPA and simulate a general wireless link withwireless losses.

163

164 Improvement of Multimedia Streaming using Estimation of Wireless losses

10.1 Introduction

Multimedia applications may utilize congestion control protocols to adapt their send-ing rate to the path conditions and prevent the network from suffering from congestioncollapse. However, TCP-derived rate-control protocols, like TFRC [59, 52], may showa significant degradation of performance over wireless links. Such protocols usuallytake packet loss as an indication of congestion; they confuse wireless losses with con-gestion losses, so they unnecessarily reduce the throughput.

In wireless links, a significant percentage of packets may belost due to bad channelconditions. Thus, wireless losses can significantly degrade the performance of conges-tion control mechanisms for multimedia flows. Approaches like link-layer retransmis-sions (ARQ) and Forward Error Correction (FEC) can reduce the impact of wirelesslosses. Nonetheless, these schemes can never eliminate such an impact completely.Link-layer retransmission mechanisms (ARQ), which try to reduce the impact of wire-less losses, can only retransmit a lost frame a limited number of times. Moreover,since retransmissions add to the end-to-end delay, they maybe harmful for multimediaapplications due to their strict requirements on delay and jitter, so ARQ may even beabsent. Thus, wireless losses can significantly degrade theperformance of congestioncontrol mechanisms for multimedia flows.

The ability of correctly discriminating among wireless andcongestion losses cansignificantly enhance the performance of congestion control mechanisms, and also canbe beneficial to applications that can adapt their error coding to the channel conditions.

In the literature, some end-to-end approaches to differentiate wireless losses haveused Round Trip Time (RTT) variations to predict the nature oflosses. Biaz and Vaidya[26] tested some congestion predictors based on RTT variations to decide whethercongestion was present or not. They showed that the performance of these conges-tion predictors was not satisfactory. Parsa and Garcia-Luna-Aceves [106] proposed avariant of TCP that uses a state machine that changes TCP’s congestion window sizebased on RTT variations. Tobe et al. [134] proposed a scheme called Spike which dif-ferentiates among degrees of congestion, instead of directly identifying wireless andcongestion losses. It uses the Relative One-way Trip Time (ROTT) to identify the stateof congestion. ROTT is the time a packet takes to go from the sender to the receiver,computed for thei-th packet as:ROTT= trecv(i)−tsend(i)−(trecv(0)−tsent(0)). ROTTis used instead of delay, because of the fact that the delay value can be incorrect dueto clock skew between the sender and the receiver; hence, a “relative” measurement ispreferred. Cen et al. [38] proposed the so-called ZigZag scheme, which uses a com-bination of the values of ROTT and the number of lost packets to classify losses aswireless-related or congestion-related. They also proposed a hybrid loss discrimina-tor, which uses the Biaz and Vaidya’s [27], ZigZag and Spike methods and switchesamong them depending on the observed network conditions. Liu et al. [90] proposeda scheme using Loss Pairs and Hidden Markov Modeling techniques. This work also

The WLED Scheme 165

uses the changes in RTT over time to infer the cause of losses.The above type of loss differentiation can be tricky and unreliable over wireless net-

works, because large delay fluctuations are inherent in suchtypes of networks. More-over, some of the previously-cited works report inaccuracies in these differentiators.Also, let us remark that other approaches exist, based on using explicit congestion no-tification (ECN) [112] to allow conveying non-ambiguous, explicit congestion signalsto the end-hosts. We however limit our discussion to “pure” end-to-end approaches, inthe sense that we exclude the possibility of any kind of signaling from the routers backto the traffic sources.

We propose a more reliable algorithm for end-to-end wireless loss estimation usingDiffServ (WLED), which is based on the fact that DiffServ networks [29] may providedifferential dropping to packets according to their drop precedences [60]. If overallloss rate for lower priority packets is not very high, then wecan safely assume thatthe congestion loss rate for the highest priority packets will be insignificant. In such acase, the loss of highest priority packets will be mainly dueto wireless errors. Thus, itis to be expected that, in general, there is a good correlation between wireless packetloss rate and the total loss rate of highest priority packets. We exploit this correlationfor estimating the wireless loss rate. Note that this basic concept of using DiffServ’sbiased queuing behavior has been used in a similar way in [28], for improving thethroughput of TCP flows by “de-randomizing” the congestion losses.

10.2 The WLED Scheme

WLED is a wireless loss estimation scheme that is designed to help congestion con-trol schemes, in DiffServ networks supporting services based on Assured Forwarding(AF)1. The idea of WLED is to exploit additional information regarding the charac-ter of losses, which can be obtained through the use of the AF PHB. The protectionof higher-priority packets inherent in the staggered RIO algorithm means that, if theloss rate of low-priority packets is not significant, then wemay assume that the loss ofhigh-priority packets is highly correlated with the wireless loss rate.

10.2.1 WLED Algorithm

The pseudo-code of the WLED algorithm is shown in Fig. 10.1. Some details likewhether (and how) to estimate the congestion probability are in fact separate fromthe generic algorithm; the particular choices shown in Fig.10.1 will be discussed inSections 10.2.2 and 10.2.3.

At the sender side, WLED maintains a separate sequence numberNj for the streamof packets marked with colorj ∈ {green,yellow, red}, as well as a common sequence

1AF is explained in section 3.4.1.2 of the chapter 3


SENDER:

for every packet of color j {increment N and Nj;send the packet, using sequence

numbers N and Nj;}

RECEIVER:

every RTT {calculate lgreen, lyellow and ltotal;if lyellow < θ then w = lgreen else w = 0;pc = EWMA_Estimator(ltotal,w);send an ACK with the value pc;

}

EWMA_Estimator(ltotal,w) {pc = (ltotal−w)/(1−w);pc← αpc +(1−α) · pc;return pc;

}

Figure 10.1: WLED algorithm.

numberN for all the packets sent2. These per-precedence sequence numbers are es-sential for the receiver to be able to compute theper-precedence(per-color) loss ratesl j . At the receiver side, WLED estimates the losses every RTT. Itcomputes the valueof wireless loss ratew using the loss ratelgreenof greenpackets. When the loss rate oflower (yellow) priority packets is less than a threshold 0< θ≤ 1, then WLED takeswequal to the loss rate ofgreenpackets. If the loss rate of lower priority packets exceedsthe threshold, then WLED conservatively assumes that all losses are due to congestion,sow = 0.

In the variant of the algorithm that we tested, the total lossrate ltotal is calculatedtaking into account all the packets, irrespective of color.Besides, the receiver sendsback to the sender an ACK with a (smoothed) estimated value ˆpc of the congestion lossprobability.

2Other implementations, like the one that will be discussed in chapter 11, are possible which do notrequire sending two sequence numbers in every packet, nor having the receiver compute the loss rates;we however adopted this method for the sake of simplicity.

The WLED Scheme 167

10.2.2 Integration of WLED with Multimedia Rate-Control Pro-tocols

There are several congestion control protocols that have been proposed in the literature.We will focus on equation-based rate control protocols3. We first considered bothTFRC [59, 52] and ARC [18] as they both use mathematical models of TCP for ratecontrol; we decided to initially work with ARC for the reasonsdiscussed below.

TFRC is a mechanism for equation-based congestion control for unicast traffic,designed to be TCP-friendly. A TFRC sender adjusts its rate as afunction of the mea-sured rate ofloss events, where a loss event consists of one or more packets droppedwithin a single round-trip time. Theloss event fractionwill obviously differ from thepacket loss rate (for a thorough discussion see e.g. [52].) However, WLED estimatesthe wirelesspacket loss rate, thus, it is incompatible with the loss event rate used in theTFRC equation. WLED in fact needs to be coupled to a model of TCP that capturesthe ideal behavior of TCP in wireless scenarios, that is, to back off only if losses aredue to congestion and to do nothing if losses are due to wireless-related phenomena.The required model should take into account the wireless loss probability in additionto the congestion loss probability, which is not the case with TFRC.

To the best of our knowledge, ARC [18] is the first to model this desired, idealbehavior of TCP facing wireless losses. ARC is a rate-control scheme that uses thefollowing equation:

S=1

4RTT

(

3+

√

25+24pc

)

, (10.1)

whereS is the sending rate in packets per second,RTT is the round trip time, andpc isthe congestion loss probability. The latter is related to the total packet loss probabilityπ and the wireless loss probabilityw through the expression:

pc =

(

π−w1−w

)

. (10.2)

ARC needs a way to calculateπ andw, in order to further computepc; note thatthe value ofπ is easily estimated from the total packets received and the total packetslost, which in turn can be known by the receiver by looking at the sequence numbers.Calculatingw is tricky and ARC relies on the MAC layer to get this loss probability.However, this approach violates the end-to-end paradigm and will not work if there isno way to obtain the wireless loss probability from lower layers.

For these reasons, we propose using WLED in conjunction with ARC over DiffServ-enabled networks. As discussed before, WLED calculatesw by using the loss rate ofgreenpackets, which in turn can be known by looking at the sequencenumberNgreen

3Note that WLED can work with any rate-control protocol that uses loss probability to calculatethroughput.


of such packets. WLED uses a loss estimation method to infer the values ofpc, w andπ. At present, we only estimate the value ofpc, as shown in Fig. 10.1, because onlythat quantity is needed to control the sending rate. The value of w can also be inferredin the same way if needed by applications, say, for determining the level of forwarderror correction (FEC) to be used.

In addition to WLED, we have also integrated some mechanisms from TFRC (dis-cussed in [52]) into ARC4. For example, we initially increase the sending rate in a fastway similar to TCP’s Slow Start. Later, the rate is determinedby the TCP model equa-tion (10.1). If the model suggests increasing the rate, thenwe augment the sending rateby at most one packet per RTT; otherwise, it is directly reduced to the computed value.

10.2.3 Loss Estimation

Loss estimation is perhaps the most important part of any equation-based congestioncontrol mechanism. Several loss estimators have been discussed in the literature. Theloss estimator that we would like to use with WLED should have the following char-acteristics: it should take loss history into account, it should yield a “smooth” estimateof the loss probability (in order to avoid fast oscillationsin the sending rate) and, at thesame time, it should be fast enough to detect congestion build-up.

We first tested a trivial loss estimation method by counting losses over a time win-dow of n > 1 RTTs. As will be discussed in Section 10.3, we found that this methodresults in strong oscillations in the sending rate. Thus, wedo not recommend the use ofthe time-window method. We finally selected the well-known EWMA (exponentially-weighted moving average) estimation method, which uses thefollowing update equa-tion for computing the estimated quantityE from the current sampleE:

E← αE +(1−α)E, (10.3)

where the weightα ∈ (0,1) determines the “responsiveness” of the estimator.As shown in Fig. 10.1, we used the EWMA method to estimatepc. The estimated,

smoothed value ofpc is sent to the sender which utilizes it directly in the ARC rateequation (10.1).

10.3 Performance Evaluation

We will now present a simulation study of WLED in combination with ARC. We areinterested in looking at the link utilization in wireless networks and to compare the

4From now on, when we say “WLED-ARC” we refer to the ARC rate-control scheme in combinationwith WLED, TFRC’s Slow Start and TFRC’s rate increase and decrease methods; likewise, by “WLEDusers” we mean applications using such a scheme.


1

2

M

1

2

Router Router

Bottleneck Link

(with RIO)

WLED Senders

WLEDReceivers

WirelessLinks

M

Figure 10.2: Simulation topology.

WLED-ARC scheme with other congestion control protocols facing the same wire-less loss conditions. Moreover, we tested the stability of sending rate and the TCP-friendliness of the scheme.

10.3.1 Experimental Setup

In this section we describe the general settings that we usedto evaluate WLED. Thesesettings remain the same for all the simulations unless specified otherwise. In thisstudy we are not interested in a detailed simulation model of, say, HSDPA — but instudying our scheme in more ’‘generic” sense. Thus, we simulate a general wirelesslink with wireless losses.

All tests were done with the well-known ns-2 simulator [95].The general topologythat we used is as shown in Fig. 10.2. Simulated time is 120 seconds. All the linksare of the same capacity, equal to 6 Mbps. The value of RTT (notconsidering thequeuing delay) is 240 ms. The topology represents a network where the last link isa wireless one and congestion can occur just before the packets are sent over the link(e.g., UMTS and 802.11 networks). The “wireless links”, which are present at the endof the “bottleneck link”, mainly serve to introduce wireless packet losses. This is doneusing a simple drop model that discards the packets randomlywith the given wirelessloss probability. The end points are theM WLED-ARC senders andM WLED-ARCreceivers. The senders are not data-limited, i.e., they cansend at high rates dependingon the bandwidth availability. Moreover, the senders are responsible to mark theirpackets asgreen, yellowor red. In most of the tests we have used an assured rate5 of50%. We will call this a “marking profile of 50%”. The effect ofthe marking profile

5Assured rate is the rate guaranteed to the user by the DiffServ network provider. It is roughly equalto the rate ofgreenpackets because it signifies the percentage of the user’s traffic that will get the besttreatment.


Table 10.1: RIO settings (Q = total buffer length).

Color thmin thmax maxp

green 0.50Q 0.70Q 0.02

yellow 0.30Q 0.50Q 0.1

red 0.10Q 0.30Q 0.2

on the performance of WLED is also discussed later.We used the RIO AQM to set up the AF PHB in our simulations. Configuring

RIO and its parameters is in itself a separate area of research[94, 40, 103, 91]. OurRIO settings, as shown in Table 10.1, are qualitatively closeto the values used in theabove works. Moreover, we have chosen the “staggered” RIO model (shown in thefigure 3.3 of chapter 3) that is recommended in [94]. The RIO algorithm uses anEWMA filter to estimate the average queue length over time in the same manner asRED. The smoothness of the filter output depends on a weightwq; we have followedthe recommendations of [49] and usedwq = 0.0013.

The value ofQ, the total length of the RIO buffer should be as small as possibleto minimize the queuing delay. On the other hand, it should belarge enough so as toavoid excessive losses ofgreenpackets. After some tests we fixedQ to 300 kbytes,which corresponds to about three times the bandwidth-delayproduct.

10.3.2 Choice of Loss Estimator and Thresholdθ

For loss estimation, we have selected the EWMA method becausethe time-windowmethod produces oscillations in the sending rate, as seen inFig. 10.4(a). Rate oscilla-tions appear when the loss estimation is not smooth, as shownin Fig. 10.3(a). EWMAgives a better performance by yielding a smoother estimate of pc, thus leading to asmoother sending rate; nonetheless, the smoothness depends on the value of weightα.Selecting the right value ofα is not obvious, because if this weight is too high thenthe sending rate will tend to oscillate (see Figs. 10.4(b) and 10.3(b)), whereas if it istoo low then the sender will be slow to react to congestion. Wechooseα = 0.005 as itseems to represent a good compromise between rate stabilityand responsiveness. Thisvalue also seems to work well for different wireless loss rates, as shown in Figs. 10.3(c)and 10.4(c).

We found the performance of WLED is not very sensitive to the value of θ, how-ever, a low value may lead to underestimation ofw. On the other hand, a higher value ofθ can lead to overestimatingw whengreenpackets get lost due to congestion (thoughthis should not be frequent since RIO offers a good protectionto thegreenpackets).The value ofθ was chosen to be 0.5 in all the simulations except in Figs. 10.3 and 10.4,


5 10

15 20

25 30

Time Window(RTTs)

20 40

60 80

100 120

Time (secs)

0 0.1 0.2 0.3

Estimated Loss

(a) Time Window estimator.

0.001

0.005

0.010

0.015

0.020

EWMAweight

20 40

60 80

100 120

Time (secs)

0 0.006 0.012 0.018

Estimated Loss Rate

(b) EWMA with different weights.

0.05

0.10

0.15

0.20Wireless Loss

20 40

60 80

100 120

Time (secs)

0 0.006 0.012

Estimated Loss Rate

(c) EWMA with different wireless losses andweight = 0.005.

Figure 10.3: Estimated Congestion Loss.


5 10

15 20

25 30

Time Window(RTTs)

20 40

60 80

100 120

Time (secs)

0200400600

Sending Rate(kbps)

(a) Time Window estimator.

0.001

0.005

0.010

0.015

0.020

EWMAweight

20 40

60 80

100 120

Time (secs)

0150300

Sending Rate(kbps)

(b) EWMA with different weights.

0.05

0.1

0.15

0.20Wireless Loss

20 40

60 80

100 120

Time (secs)

0200400

Sending Rate(kbps)

(c) EWMA with different wireless losses andα =0.005.

Figure 10.4: Sending Rate variation.


0

10

20

30

40

50

60

70

80

90

100

0 0.05 0.1 0.15 0.2

% L

ink

Util

izat

ion


WLED-ARCTFRC

TCP NewReno

Figure 10.5: Link Utilization for Different Wireless Loss Probabilities.

whereθ = 0.8 was used: we did so because we were more concerned about finding agood setting forα and did not want noise in the estimation due to (a possibly toolow)θ.

10.3.3 Link Utilization

One goal of WLED is to improve link utilization despite wireless losses. We measuredthe link utilization with WLED-ARC with different values ofw. We set the number ofusersM to 20. For comparison purposes, we also measured the performance of TFRCand TCP NewReno under the same conditions with varying wireless loss probability.

Fig. 10.5 shows the link utilization for different values ofthe wireless loss prob-ability w. It can be seen that the link utilization with WLED-ARC is always > 90%,even whenw is as high as 0.2, whereas utilization drops sharply with TFRCand TCPfor relatively low values ofw. WLED performs better than TFRC and TCP NewRenobecause the latter two fail to distinguish among congestionand wireless losses.

10.3.4 TCP Friendliness

Link utilization alone is not a good indicator of performance for congestion controlmechanisms; such mechanisms should also share the available bandwidth in a fairway. Since ARC was designed to be TCP-friendly, we tested WLED-ARC for its TCP-friendliness using the topology shown in Fig. 10.6. The difference from the originalsettings is thatM TCP users are present in addition to theM WLED users. All userscompete for their share of the bottleneck bandwidth. In addition, the TCP flows do


1

2

M

1

2

M

Router Router

Bottleneck Link

(with RIO)

WLED Senders

WLEDReceivers

WirelessLinks

1

2

M

1

2

M

FixedLinks

TCPReceivers

TCP Senders

Figure 10.6: Topology used for testing TCP friendliness.

not travel through wireless links. This was done due to the fact that TCP does notdifferentiate between wireless and congestion losses and its performance may be badover wireless links. Thus, no wireless losses were introduced to TCP flows to givefairer conditions to them.

Fig. 10.7 shows the fairness of WLED-ARC when it competes with TCP NewRenoflows, the latter subject to no wireless losses. The number offlowsM and the wirelessloss probabilityw for WLED was varied, and the normalized throughput of each flowwas plotted (shown as individual plot marks). Note that WLED-ARC is indeed fairwith respect to TCP: on the average, the throughput of a WLED-ARCflow is no morethan 10% greater than that of a TCP flow, irrespective of the values ofM andw. Thebehavior observed in Fig. 10.7(c) for low values ofM might be due to the fact that, athigher values ofw, the running estimate oflyellow crosses the thresholdθ more often.This may lead to underestimation ofw, which in turn decreases the aggressiveness ofWLED-ARC senders to probe for available bandwidth.

10.3.5 Marking Scheme

Applications can decide to mark their packets in arbitrary ways, meaning that the pro-portion ofgreenpackets may change from one application to the other. In the contextof video streaming, the marking ratio may be very flexible when hierarchical, scalablevideo codecs [87] are used.

To test the impact of the marking scheme on WLED-ARC we used the topologyshown in Fig. 10.6 withM = 12. We measured the stability over time of the sendingrate by computing its coefficient of variation (CoV), that is,the ratio of the standarddeviation to the mean value; a low CoV value means higher rate stability. In orderto calculate the CoV, throughputs were measured6 using a time window of 1 s. The

6Simulations were run for 140 s, and the rate values for the first 20 s were discarded to filter out the


0.8

0.85

0.9

0.95

1

1.05

1.1

1.15

1.2

8 12 16 20 24 28 32

Nor

mal

ized

Thr

ough

put

Number of TCP ’or’ WLED flows

TCP FlowsWLED Flows

Mean TCPMean WLED

(a) No wireless losses (w = 0).

0.8

0.85

0.9

0.95

1

1.05

1.1

1.15

1.2

8 12 16 20 24 28 32

Nor

mal

ized

Thr

ough

put


TCP FlowsWLED Flows

Mean TCPMean WLED

(b) w = 0.1.

0.8

0.85

0.9

0.95

1

1.05

1.1

1.15

1.2

8 12 16 20 24 28 32

Nor

mal

ized

Thr

ough

put


TCP FlowsWLED Flows

Mean TCPMean WLED

(c) w = 0.2.

Figure 10.7: TCP NewReno and WLED.


values of CoV obtained with different marking profiles and wireless loss probabilitiesare shown in Fig. 10.8(a). The error bars show the deviation of CoV values betweendifferent users. It can be seen that the CoV tends to increase (meaning a decrease inrate stability) for lower values of assured rate. This is because lower values of assuredrate (< 30%) mean that lessgreenpackets are available for estimation per RTT, hence,the quality of the estimation deteriorates.

In order to see the effect of the marking profile on TCP friendliness, we plottedthe ratio of total throughput of WLED flows and total throughput of TCP flows inFig. 10.8(b). The percentage of assured rate and wireless loss probability were variedand, for each case, the simulation was run 10 times. The average and standard devia-tion, shown by the error bars in the graph, obtained from these simulations is plotted.Similar to the above case, it can be seen that the lower valuesof assured rate (< 30%)give a poorer TCP friendliness.

10.4 Conclusion

In this chapter we have proposed a wireless loss estimation scheme for DiffServ-enabled networks that works together with equation-based congestion control schemes.This novel scheme, WLED, estimates the wireless probabilityin an end-to-end fash-ion. This significantly helps congestion control protocolsbecause they can use thisinformation and reduce their throughput accordingly, otherwise they would unneces-sarily drop their sending rates, resulting in a very low utilization of links. Estimation ofwireless loss probability can also help the applications, as some of them can optimizethe amount of forward error correction based on this information.

WLED was evaluated with the ARC congestion control scheme. In comparisonwith TFRC and TCP, we found that the link utilization of WLED-ARC was far better,while showing stability of sending rates and TCP friendliness for a diverse range ofscenarios.

start-up phase.

Conclusion 177

0

0.2

0.4

0.6

0.8

1

10 20 30 40 50 60 70 80 90

CoV

Assured Rate %

wireless loss 0.0wireless loss 0.05wireless loss 0.1

wireless loss 0.15wireless loss 0.2

(a) CoV of Throughputs with Different Assured Rates and Measur-ing Window of 1 s.

0

0.5

1

1.5

2

10 20 30 40 50 60 70 80 90

Rat

io (

WLE

D/T

CP

thro

ughp

ut)

Assured Rate %

wireless loss 0.0wireless loss 0.05wireless loss 0.10wireless loss 0.15wireless loss 0.20

(b) Ratio of WLED and TCP Throughputs with Different AssuredRates.

Figure 10.8: Stability and TCP-Friendliness of WLED


Chapter 11

Congestion Control and AdaptiveRetransmission for MultimediaStreaming

In wireless networks, congestion control may not be enough to ensure good quality ofmultimedia and efficient utilization of the network. Packet losses due to the high biterror rate not only degrade the multimedia quality, but render the current congestioncontrol algorithms as inefficient: these algorithms back-off on every packet loss evenwhen there is no congestion.

In this chapter we study the case of pre-recorded multimedia streaming over wire-less networks. We integrate the congestion control schemes with an adaptive retrans-mission scheme in order to selectively retransmit some lostmultimedia packets. More-over, we integrate a wireless loss estimation scheme to improve the efficiency of con-gestion control. Our results show that the integrated scheme improves the multimediaquality due to the retransmission and recovery of some of thelost multimedia data.Moreover, the congestion control schemes, and hence the integrated retransmissionscheme, show improved performance because of the wireless loss estimation.

11.1 Introduction

In wireless environment, the frequent losses degrade the quality of the video streams,therefore, new methods should be investigated to increase the number of successfullyreceived packets. To minimize the end-to-end packet loss ratio the packet loss shouldbe either prevented or subsequently handled.

Multimedia applications may use congestion control in order to avoid congestioncollapse of the network and to minimize the packet loss due tocongestion. The perfor-mance of congestion control protocols may significantly degrade over wireless links

179

180 Adaptive Retransmission for Multimedia Streaming

because they confuse the wireless losses with the congestion losses and unnecessarilyreduce the throughput, as explained in chapter 10.

Traditional error control mechanisms generally use retransmission to provide re-liability at the expense of latency. Loss-tolerant multimedia applications should useretransmissions as well, but the retransmission will be successful only if the retrans-mitted packet arrives at the receiver before the playback. In a congested network theround-trip-time (RTT) and the loss probability is significantly higher and the retrans-mitted packets probably will be lost again, therefore the retransmission of lost videostream packets is not recommended in such conditions. To efficiently control the re-transmissions a selective retransmission scheme is needed.

Some prior work has been done to develop error recovery and concealment forthe real-time video. Content based retransmission methods retransmit only the impor-tant data of the bitstream, taking advantage of the motion prediction loop employedin most motion compensation based codecs. Correcting errorsin a reference frame,caused by earlier packet loss, prevents error propagation.Feamster and Balakrishnan[48] analyzed a content based approach with SR-RTP [100]. Zheng and Atiquzzaman[145] proposed a new selective retransmission scheme, for multimedia transmission,over a noisy wireless channel using the ATM ABR service. Some selective retrans-mission methods investigate the possibility of successfulpacket retransmissions as afunction of the actual network delay and bandwidth. Attempts are made to imple-ment a selective retransmission protocol with a decision algorithm [110] based on theEuclidean distance, calculated by the loss and latency ratio. Moreover, the retransmis-sion requests are used in the scheme introduced in [57]. A survey and taxonomy ofretransmission-based partially reliable transport protocols can be found in [55].

We propose a combination of the retransmission approach with new congestioncontrol methods that can distinguish between the congestion and the wireless losses.Depending on the calculated sending rate, the video bitrateand the MPEG frame type,we decide whether to enable or disable the retransmissions.In our proposal, we useDCCP (Datagram Congestion Control Protocol) [80, 79] as the transport protocol be-cause of its benefits that will be explained in the following section.

11.2 WLED-ARC with DCCP

WLED [130], described in chapter 10, is an end-to-end wireless loss estimation schemefor the DiffServ networks supporting AF-based services. WLED needs to work inconjunction with a congestion control protocol. Among TFRC or ARC, we chose thelatter as explained in chapter 10. WLED uses an end-2-end lossestimation methodto infer the values ofpc, w andπ in the equations (10.1) and (10.2). As described inchapter 10,pc is the congestion loss rate,w is the wireless loss rate andπ is the totalloss rate.

WLED-ARC with DCCP 181

Figure 11.1: DCCP interaction with an application.

We use Datagram Congestion Control Protocol (DCCP) [80] as the transport layerprotocol for testing the congestion control and the retransmission scheme described inthe following sections. DCCP provides the necessary semantics like sequence num-bers, and features like “Feedback/ACK vectors” [80] are useful for loss detection. Theinteraction of DCCP and the application is shown in Figure 11.1. DCCP congestioncontrol is “modular”, in the sense that the protocol may easily support different con-gestion control mechanisms without the need of modifying its fundamental workings;for instance, both TFRC and a TCP-like mechanism have been adopted by DCCP.

Our WLED-ARC implementation over DCCP is an improvement over theone de-scribed in chapter 10. There is no need to use separate sequence numbers to detectlosses for different DiffServ colors because we manage all the history of packets usingDCCP “ACK vectors”. A circular buffer, of sizebhist, contains the history of the pack-ets, lost or received, withbhist = 100: that is an arbitrary value based on our empiricalresults. A lowerbhist produces oscillations in the loss estimation and a higher valuemakes it slow to respond to congestion events.

The loss (pc, w andπ) estimation, using exponentially weighted moving average(EWMA), is similar to the estimation method explained in chapter 10 and the esti-mated value is updated each time an “ACK vector” is received. As in chapter 10, somemechanisms from TFRC, like the “slow start” emulation, are also integrated. One im-portant difference when using ARC is that in our simulations we assume that ARC hasthe perfect knowledge1 of w and just needs to calculateπ to estimate the value ofpc.Moreover, in the case of ARC2, another crucial difference is that TFRC stops the “slowstart” as soon as it detects the first loss, but here, as ARC is supposed to distinguish

1Recall that, ARC relies on the MAC layer to know the wireless loss probability and, as explainedbefore, the WLED scheme aims to improve that by providing end-to-end wireless loss estimation.

2We implemented ARC over DCCP and TFRC over DCCP for the comparison tests. These imple-mentations do not include the WLED scheme unless mentioned explicitly.


between wireless and congestion losses, the first loss couldbe due to wireless losses.Thus, a separate “slow start” history is maintained and “slow start” is stopped as soonasπ > w.

In the case of WLED-ARC, it is assumed that the Diffserv support is present in thenetwork. Again the slow start history is maintained separately. It should be observedthat, in Diffserv networks,red packets are lost first during congestion thus, the slowstart is stopped as soon aslossred > redthreshold, with redthreshold taken to be 40%, i.e.,when manyred packets are getting lost as high as 40% that means link bandwidthis already reached. The assumption is thatw < 40% is reasonable enough for realwireless links because connections should be simply dropped for higherw.

After the slow start is stopped, for both ARC and TFRC, the slow start historyis discarded as the loss experienced during slow start is generally high and the TCPmodels used do not model the slow start behavior. The value ofpc is initialized to avalue that corresponds, depending on the TCP model, to the “received rate” obtainedby the receiver at that time.

11.3 The Retransmission Scheme

The entire pre-recorded video can be transmitted, in lessertime than its duration, whenthe network conditions are good enough. On the contrary, packets can be lost duringbad channel conditions and the sending rate may not be high enough to send all thevideo data.

The proposed selective retransmission scheme either disables or enables the re-transmission of lost packets according to the current stateof the network. In generalthe retransmission of any packet should be disabled when thenetwork is congested.The congestion control algorithm calculates the actual sending rate to avoid conges-tion, while the video stream bitrate is absolutely independent of the calculated sendingbitrate. When the network is in congested state, or near to this state, the calculatedsending rate is generally much lower than the video bitrate.In this situation the retrans-missions should be disabled. Whereas, the retransmission should be enabled when thesending rate, determined by the congestion control protocol, is higher than the videostream rate. In this case we have to decide whether to retransmit only I-frames, orboth I- and P-frames, or all the lost packet i.e., we can differentiate the lost packetsaccording to the packet content. When the proposed sending rate is not high enough toretransmit all the lost packets, only the I-frame or I + P-frames data packets should beretransmitted.

In order to make the decision to retransmit or not, the extra load due to the re-transmissions should be estimated. To determine the sending rate thresholds for thedifferent frame type retransmissions, some statistical results were used [83, 42]. Usu-ally, the statistical values of the video can also be computed offline in the case of

The Retransmission Scheme 183

Table 11.1: Frame Sizes in number of packets using LognormalDistribution

Frame type µ (mean value) σ (standard deviation)

I 5.1968 0.2016P 3.7380 0.5961B 2.8687 0.2675

Table 11.2: Frame Ratio in MPEG Streams

N=4, M=2 I P Bnumber of frames 1 1 2avg. total size in packets 5.1968 3.7380 5.7374ratio 35.42% 25.48% 39.1%



pre-recorded video transmission. In the case when the different frame type sizes cannot be calculated before the transmission, generally acceptable values should be usedto estimate the frame type size ratios in a Group of Pictures/Frames (GOP).

The statistical results [83]3 show that the size of the different frame types4 can bemodeled with standard normal distribution using the parameters shown in table 11.1.

The video frame structure is specified by the N and M parameters. N and M dealwith the intra-frame to inter-frame coding ratio and define the sequence of I, P andB frames. N specifies the I frame interval, or the GOP size, andM specifies the I orP frame interval. Let us consider the ratio of I frame size andtotal GOP size asρI .Similarly, the ratios for P and B frames areρP andρB respectively. We wanted to fixan upper bound on the values of these ratios. As shown in Table11.2, we considered 3

3The statistical results are more general and are not specificto H.264 coded video that we use in thisstudy, but they work well for our simulations as shown in the following sections presenting the results.

4Note that the frame size is given in number of packets. We don’t need the size of packet in bytesbecause we will use the ratio of frame sizes in our further analysis.


cases with different values of N and M.Table 11.2 shows the upper bounds such that the I-frame data in the GOP is es-

timated as 35.42% (ρI=0.3542), the P-frame data as 48.17% (ρP=0.4817) and the B-frame data as 67.71% (ρB=0.6771). We see that the upper bounds are≈ 50%. Thus,when the statistical data is not available, we assume the upper bounds for the I, P andB frame data in the stream to be 50%-50%-50%5 and the extra load (λextra) due to theI frame retransmissions is calculated as follows:

λ50%extra = ρ50%· rstream·π (11.1)

whererstreamis the video stream bitrate, andπ, as described before, is the total packetloss probability. This extra load is used for all types of frames. When the frame typesize ratios are available, the extra load is calculated for I, P or all the type of frames asfollows:

λIextra = ρI · rstream·π (11.2)

λI+Pextra = (ρI +ρP) · rstream·π (11.3)

λallextra = (ρall ) · rstream·π (11.4)

The frame enabling process enables or disables the retransmission, of different typeof frames, according to the extra load and the sending rate given by the congestioncontrol (CC-rate).

The retransmission should be disabled whenS≤ rv, whereSstands for the sendingrate determined by the congestion control protocol andrv is the bit rate at which thevideo was encoded. The priority of I-frames is higher than the other frames, thereforefirst I-frame data packets should be retransmitted. The rules to retransmit I, I + P andall the frames are shown in table 11.3.

Table 11.3: Frame Type Retransmissions

Default ratio Ratios of the actual video(ρ50%=0.5) (ρI , ρP, ρB)

I frames rv < S< rv +λ50%extra rv < S< rv +λI

extra

I + P frames rv +λextra < S< rv +2λ50%extra rv < S< rv +λI+P

extra

all frames S> rv +2λ50%extra rv < S< rv +λall

extra

5Note that we are taking the upper bounds and, thus, the sum maynot be equal to 100%.

Simulation Results 185

11.4 Simulation Results

In order to test the performance of the different types of congestion control based se-lective retransmission schemes and the proposed retransmission thresholds, we analyzesome scenarios with the ns-2 [95] network simulator. We use dumbbell topology with1Mbps links and 10 ms link delays. The “wireless link” is the bottleneck link, in orderto introduce wireless packet losses, using a simple random drop model, with the givenloss probability. We study two types of cases: one with Droptail queue managementand the other with RIO (Red In and Out) queue management in the bottleneck link.

11.4.1 Droptail

First, we examine how the different congestion control based selective retransmissionschemes can utilize the available bandwidth on the bottleneck link. Either FTP orWWW background traffic, similar to chapter 7, is set up during the simulations. Thenetwork delay is 40ms, while the Droptail queue limit is set to 40. To analyze thequality of the 360kbps H.264 video stream6, the PSNR (Peak Signal to Noise Ratio)objective quality metrics is used.

The decision algorithm for the retransmission scheme is based on the actual calcu-lated sending rate given by the congestion control algorithm. The TFRC sending rateis the lowest; therefore, using this protocol for the selective retransmission disables theretransmission, but ARC still enables it, especially in the case of high wireless lossprobability.

With cross layer information, ARC can utilize the wireless loss probability; there-fore it retransmits more lost packets without causing congestion. Whereas, the TFRC-based selective retransmission retransmits fewer packetsthan ARC.

The retransmissions and the congestion control method havea significant impacton the number of packets lost. Slightly less packets are lostwhen the retransmission isdisabled, although the video quality is the worst as will be shown later in this section.Using ARC as the congestion control protocol, the high sending rate can cause slightlyhigher loss probability, but more packets are retransmitted improving the video quality.

When the difference between the video bit-rate and the determined sending rate issmall, only the important data packets should be retransmitted. Retransmitting all thelost packets causes congestion in the network. If more packets are retransmitted thanthe available link capacity, the packets will be lost again.The ARC protocol efficientlyapproaches the link capacity limits and, therefore, the differentiating between the pack-ets is beneficial. We investigate the number of lost packets when packet differentiationand retransmission thresholds are used. As Figure 11.2 illustrates, the number of lostpackets is 3-5% less when differentiation is used. The impact of different frame typeson the video quality is not the same; therefore our motivation is to protect the important

6The reference video is “mother and daughter” that is used in chapter 7.


0

100

200

300

400

500

600

700

800

900

0 0.05 0.1 0.15 0.2

Lost

Pac

kets


ARCARC + frame Diff.

Figure 11.2: The number of lost packets, using the retransmission thresholds withdifferentiation of frames. Without any background traffic.

frames like I pictures to avoid the propagation of errors. When there is not enough linkcapacity to retransmit all the packets, only the I frame datapackets or I and P framesare retransmitted.

According to the next simulation results, where we compare different congestioncontrol schemes, the best video quality is achieved with ARC and ARC with framedifferentiation. Moreover, a slight improvement can be seen when using frame differ-entiation in addition to ARC. With these methods more lost packets can be success-fully retransmitted. As shown7 in Figure 11.3, the PSNR video quality is significantlyhigher when ARC is used and the wireless probability is high. This is because ARCdoes not back-off unnecessarily during wireless losses whereas, TFRC does that andthe sending rate available to the video application is very low. With TFRC, the videoapplication not only fails to retransmit the lost data, but also it is not able to send thecomplete video sequence because of the low value of the sending rate.

We also compare the video quality when the retransmission threshold is determinedby general frame type size ratios (ρ50%) and by actual ratios (the analyzed H.264 videoframe size ratios are:ρI = 18%, ρP = 60%, ρB = 22%). Figure 11.4 shows that thedifference is only 0.1-0.4dB in the case when the valid statistical values (possible forpre-recorded video streaming) are used for the retransmission threshold determination.Thus, our default values can be used without significant degradation in the video qual-ity, when the valid statistical values are not available.

7Note that the “without retransmission” case corresponds tothe case when video application usesTFRC scheme as the congestion control scheme and it never retransmits the lost video data

Simulation Results 187

5

10

15

20

25

30

35

0 0.05 0.1 0.15 0.2

PS

NR

(dB

)


ARCARC + frame Diff.

TFRCwithout retransmission

Figure 11.3: The average video quality (PSNR). With a single FTP source as the back-ground traffic.

26

27

28

29

30

31

32

33

0 0.05 0.1 0.15 0.2

PS

NR

(dB

)


(I,P,B) ratio = (18%, 60%, 22%)(I,P,B) ratio = (50%, 50%, 50%)

Figure 11.4: The average PSNR, using different threshold calculation methods. Witha single FTP source as the background traffic


5

10

15

20

25

30

35

5 10 15 20 25 30 35

PS

NR

(dB

)

WWW Users

ARCTFRC

Without retrans.

Figure 11.5: Average PNSR, when the bottleneck link is sharedamong the DCCPvideo connection and the WWW users. The value of wireless loss ratew = 0.1.

In the next simulation scenario, we vary the background traffic load. To analyze theeffect of the background load, WWW connections are used on the shared bottlenecklink. The number of lost packets increases on increasing theload on the bottleneck link,although the wireless loss probability is constant (w = 10%, i.e., high). Figure 11.5shows that ARC performs significantly better than the other schemes. This is becausewhenw is high the other schemes can not differentiate between congestion and wirelessloss and the sending rate is very low. Not only they disable the retransmission, but theyalso send the video data at a rate significantly lower than thevideo bit-rate.

11.4.2 RIO (Red In and Out)

The retransmission method is investigated in a Diffserv network as well, where the im-portant packets are marked asgreenand the least important packets asred. Moreover,it is possible to use WLED-ARC as it assumes a Diffserv network.In the simulations,the frame differentiation is also used to prefer the retransmission of the most impor-tant I frames. Again, as shown in Figure 11.6, the WLED and ARC schemes performsignificantly better than TFRC and TFRC without retransmissions.

The increase in the background traffic has no effect on the TFRC-based transmis-sion when the wireless loss is already high because the determined sending rate isalready too low to enable retransmission. In the case of TFRC, the retransmission isdisabled because, due to the high loss rate (10%), the calculated sending rate is too lowto even transmit the video at its video bit-rate. This is the reason that the TFRC retrans-mission and the case without retransmission are very similar in the next case when we

Conclusion 189

5

10

15

20

25

30

35

40

0 0.05 0.1 0.15 0.2

PS

NR

(dB

)


WLEDARC


Figure 11.6: Average PSNR of ARC-, TFRC-, WLED-ARC-based retransmissionsand the case without retransmission in a Diffserv network with varying wireless lossprobability and 10 WWW users.

fix the wireless loss tow = 10%. The results are shown in figures 11.7 and 11.8. Theperformance of ARC- and WLED-ARC-based retransmission is significantly better inwireless networks with high loss ratio. The quality improvement is due to the largenumber of retransmitted packets that were lost when the retransmission was enabled.

ARC and WLED-ARC effectively forward the video stream, and retransmit the lostdata as shown in Figure 11.8, achieving significant improvement in the video quality.

11.5 Conclusion

Packet losses, due to bad radio conditions in wireless networks, not only degrade thevideo quality but, render the current congestion control algorithms that back-off onevery loss, as inefficient.

In order to counter this problem, we integrate the congestion control schemes withan adaptive retransmission scheme in order to selectively retransmit some lost videopackets. We also integrate a wireless loss estimation scheme to avoid the confusionbetween two types of losses and improve the efficiency of congestion control mecha-nism. Our results show that the integrated scheme not only improves the video qualitydue to the retransmission and recovery of some of the lost video data, but also that therecovery itself is efficient because of the wireless loss estimation.


5

10

15

20

25

30

35

5 10 15 20 25 30 35

PS

NR

(dB

)

WWW Users

WLEDARC


Figure 11.7: Average PSNR of ARC-, TFRC-, WLED-ARC-based retransmissionsand the case without retransmission in a Diffserv network. The value of wireless lossratew = 0.1.

0

2

4

6

8

10

12

14

5 10 15 20 25 30 35

Ret

rans

mis

sion

Rat

io (

%)

WWW Users

WLEDARC

TFRC

Figure 11.8: The ratio of the number of retransmitted packets and the number of lostpackets. The value of wireless loss ratew = 0.1.

Chapter 12

Conclusion and Future Work

In this dissertation we focused on multimedia streaming over third generation (3G)mobile networks using packet switched technology (IP). Themain contributions arethree-fold:

• Improvement in the resource utilization by reducing the overheads encounteredwhen providing multimedia services over IP.

• Improvement in the Quality of Service (QoS) by prioritizing the multimediaflows that have stricter requirements in comparison to otherapplications.

• Overcoming the packet losses and congestion periods, thatare the inherent char-acteristics of the 3G radio links, with the use of loss estimation and selectiveretransmission schemes.

The following sections summarize these contributions and also discuss the relevantfuture work.

12.1 Header Compression for Multimedia Flows

In the initial chapters, we studied header compression over3G mobile network thatcan benefit certain multimedia applications such as Voice over IP (VoIP). These ap-plications face significant overhead when they use IP. This is because the header size,considering all the headers such as IP, UDP and RTP, of an IP packet can range from40 to 120 bytes in comparison to the typical payload size of the order of 100 bytes.

Robust Header Compression (ROHC) is a header compression solution proposedby IETF and will be used in the 3G networks. However, the compressed header packetsover a radio channel such as UMTS will be confronted with a variable environment thatcan lead to failure of header decompression. We studied the compression parametersof ROHC that determine its performance in terms of robustness and its compression

191

192 Conclusion and Future Work

efficiency. We found that the performance of ROHC varies withthe compression pa-rameters, when confronted with the simulated wireless environment with bit errors.The important result was that there exists a trade-off between the robustness and thecompression efficiency that could be exploited to optimize the behavior of ROHC. Anoptimization scheme was designed that adapted the compression parameters depend-ing on the estimated network state. When the bit error rate washigh in the network,the ROHC parameters were adapted to make it more robust to thelosses. In the caseof low bit error rate, the ROHC parameters were adapted to increase the compressionefficiency of ROHC without compromising the required robustness.

Further, we studied the impact of a recently proposed protocol, called UDP-Lite,on ROHC and the multimedia applications. UDP-Lite allows the multimedia applica-tions to have partially damaged payload delivered rather than discarded. This can bebeneficial to the multimedia applications that use error correction in the encoding ofthe multimedia data. We studied some strategies to partially cover the payload datawith the packet headers being compressed by ROHC. These strategies changed themanner in which errors affected the packets. When an error occurred in the uncovereddata, the packet was sent to the application and in that case the decision was taken bythe application to see if the packet was useful. If error occurred in the data coveredby the checksum, the packet was dropped. There was one more case that if the erroroccurred in the header and ROHC could not correct it, then thepacket was droppedby ROHC. It was found that the global performance of ROHC with UDP-Lite flowsincreased considerably because we were able to choose the information that must becovered by the checksum without affecting the application data.

In the future, we would like to analyze the behavior of ROHC over a real radiostack. If the costs or the complexity turns out to be high, then we would at least liketo integrate ROHC in the highly detailed HSDPA packet simulator, used in the otherparts of this dissertation, for further study.

12.2 Video Streaming over High Speed Downlink PacketAccess

While using packet based technology, such as IP, over 3G mobile networks, the Qual-ity of Service (QoS) differentiation is an important part because different services havedifferent requirements. This is because packet based networks such as the Internet areoften designed to provide only theBest Effortservice that cannot satisfy the require-ments of some real time applications in terms of delay, loss tolerance, jitter, etc.

We studied the provisioning of QoS over High Speed Downlink Packet Access(HSDPA) making it suitable for multimedia applications. Weused the salient featureof HSDPA that is packet scheduling to satisfy the QoS requirement of H.264 videostreaming applications. We did an extensive case study of H.264 video streaming over

Video Streaming over High Speed Downlink Packet Access 193

HSDPA while testing different schedulers. Moreover, to thebest of our knowledge, thisstudy itself has the merit of being novel because it uses a tool called Pseudo SubjectiveQuality Assessment (PSQA) to evaluate the impact on the perceived quality by theusers. This is unlike the state of the art studies that assessvideo streaming using toolslike PSNR that are not a good indicator to the perceived quality.

In our study, it was found that all the existing schedulers satisfied the video require-ments when there was no network load, but when the network load was increased, thenonly QoS schedulers guaranteed a minimum quality to the video users. Moreover, theQoS-aware schedulers still divided the remaining resources among the BE users in afair manner. An important observation was that the existingQoS scheduler called RateGuarantee (RG) was still causing deterioration in the video quality with higher loadson the network due to Best Effort traffic. Moreover, it was biased towards users withcertain rate guarantees.

Based on the above observation, we proposed a Normalized Rate Guarantee (NRG)scheduler, which is an extension of a previous QoS scheduler. NRG scheduler providedthe following improvements. There was no deterioration in the video quality whenthere was an increase in the Best Effort traffic. Moreover, it apportioned fair loss ratesto the users with different rate guarantees.

Further, we studied a general problem of resource partitioning for shared wirelesslinks like HSDPA. This could be easy over wired links with known link capacity, butsuch partitioning is complex for wireless links with variable capacity. We discussed theconcept of using HSDPA MAC-layer scheduling for resource partitioning, and someconcepts like resource allocation for the QoS users employing rate control schemes andcongestion control at the RNC. We proposed that the lower classes be considered as avirtual user in the higher QoS classes. A variant of an existing scheduler was proposedand studied. The results showed improvements in terms of more satisfied QoS users.Moreover, the QoS satisfaction was not done at the cost of starving Best Effort users.

As a future work, we would like to study the problem of Call Admission Control(CAC) for the shared wireless links such as HSDPA. A good CAC would have tomonitor the channel quality for some time before taking the decision regarding theadmission of the user. Moreover, some features like video bit rate re-negotiations andcongestion control can be integrated with the CAC algorithm.Such that a lower bitrate video can be transmitted to a video user when the channelconditions become bador when there is congestion. This would depend on the re-negotiation policy and mayimprove the perceived quality of the video users, as the initial video stream with thehigher bit rate might be experiencing an intolerable packetloss rate. In addition, thePSQA tool can be integrated with the video client to feed backthe perceived qualityon a regular basis. That in turn may be used to take the above decisions related to there-negotiation of the video bit rate.


12.3 Congestion Control for Video Flows

In the last part of this dissertation, we studied congestioncontrol schemes that aresuited for video flows. The suitability is determined by the rate stability provided by therate control algorithm of such schemes. This is also relatedto the stricter requirementsof the real time services such as video streaming. The fluctuations in the availablesending rate can cause delay in the transmission of the videodata, that in turn cancause the data to miss its play-out deadline.

We obtained some surprising results when we studied TCP-Friendly Rate Control(TFRC) over HSDPA. TFRC is an end-to-end congestion control mechanism, whosegoal is to provide rate control for unicast flows in IP networks. We found that, in thecontext of HSDPA, the rate stability of TFRC was not necessarily better than that ofTCP. This was surprising because it is opposite to what is usually reported over wiredlinks. The reason for this behavior is that the HSDPA packet scheduling combinedwith the variable characteristics of the radio environmentproduces fluctuations in thebandwidth itself. This in turn causes rate instability in the sending rate of TFRC as wellas TCP. Another result was that TCP, due to its better adaptability to the bandwidth,obtained better throughput in comparison to TFRC when facingidentical conditions.Later, we showed that the bandwidth fluctuations can be controlled by using an appro-priate QoS packet scheduling and this can benefit both TCP and TFRC.

The congestion control schemes face some more problems whenoperating overwireless networks in general. The problem is that there are packet losses in the wirelessnetwork due to bad radio conditions. This not only degrades the multimedia quality,but renders the current congestion control algorithms as inefficient: These algorithmsback-off on every packet loss even when there is no congestion. Thus, we proposedtwo strategies to counter this problem:

• We designed a loss estimation scheme that could estimate the wireless loss prob-ability in an end-to-end fashion. This proved useful to somecongestion controlschemes because they were able to reduce the number of unnecessary back-offsas a function of the wireless probability.

• We used selective retransmissions to recover the lost multimedia data due towireless losses. We also integrated the above wireless lossestimation schemeto aid the congestion control algorithm. A combination of some retransmissionstrategies was studied such as prioritizing the retransmission for more importantdata, only retransmitting the data having a chance of being received before itsplay-out deadline and disabling the retransmissions during congestion periods.

Our results showed that the integrated scheme not only improved the video qualitydue to the retransmission and recovery of some of the lost video data, but also that therecovery itself was efficient because of the wireless loss estimation.

Congestion Control for Video Flows 195

In the future, we would like to improve the rate stability of TFRC over HSDPA.Even if the rate stability is an inherent problem of the 3G network itself and should betackled by the network itself, we still think that there is some scope of improvementin the TFRC algorithm as it neither provided good rate stability nor did it obtain goodthroughput.

We would also like to study the problem of congestion controlfor the video en-coded by Scalable Video Codec (SVC). SVC is a recent video codecand it encodes thevideo such that it is possible to adapt the rate of the video itself with graceful changesin the video quality. This property can be used to adapt the video quality as a functionof the network conditions that translate to the sending ratewhen congestion control isused. This can be useful over 3G networks where bandwidth fluctuations are presentbecause it will make the rate stability requirements more flexible. Moreover, it mayhelp the video bit rate re-negotiation scheme that is discussed in Section 12.2.


Glossaire

1G First Generation2G Second Generation3G Third Generation3GPP Third Generation Partnership ProjectABP-DCS Adaptive Base Proposal with Dynamic Compression StartABP-SCS Adaptive Base Proposal with Static Compression StartABR Available Bit RateACL Average Compressed header LengthAF Assured ForwardingAIMD Additive Increase and Multiplicative DecreaseAMC Adaptive Modulation and CodingAQM Active Queue ManagementARC Analytical Rate ControlARQ Automatic Repeat reQuestAS Access StratumATM Asynchronous Transfer ModeAVC Advanced Video CodingBE Best EffortBER Bit Error RateBLER BLock Error RateBMC Broadcast and Multicast ControlBS Base StationCABAC Context Adaptive Binary Arithmetic CodingCAC Connection Admission ControlCBR Constant Bit RateCDF Cumulative Distribution FunctionCDMA Code Division Multiple Access

197

198 Glossaire

CID Context IDentifierCoV Coefficient of VariationCQI Channel Quality IndicatorCRC Cyclic Redundancy CheckCRTP Compressed RTPCS Circuit SwitchedCTCP Compressed TCPCVLC Context adaptive Variable Length CodingDCCP Datagram Congestion Control ProtocolDP Data PartitioningDSCP DiffServ Code PointDSIS Double Stimulus Impairment Scale methodDVB Digital Video BroadcastDVD Digital Video DiskECN Explicit Congestion NotificationEDGE Enhanced Data rates for GSM EvolutionEF Expedited ForwardingEGPRS Enhanced GPRSEPIC Efficient Protocol Independent CompressionESP Encapsulating Security PayloadEURANE Enhanced UMTS Radio Access Network Extensions for ns-2EWMA Exponential Weighted Moving AverageFC Full ContextFEC Forward Error CorrectionFGS Fine Granularity ScalabilityFMO Flexible Macroblock OrderingFO First OrderFTP File Transfer ProtocolGGSN Gateway GPRS Support NodeGMSC Gateway MSCGOP Group of PicturesGPRS Global Packet Radio ServicesGSM Global System for Mobile communicationsHARQ Hybrid-ARQ

Glossaire 199

HDR High Data RateHLR Home Location RegisterHSDPA High Speed Downlink Packet AccessHS-DSCH High Speed Downlink Shared ChannelHSPA High Speed Packet AccessHS-SCCH High Speed Shared Control ChannelHSUPA High Speed Uplink Packet AccessIETF Internet Engineering Task ForceIP Internet ProtocolIPCP IP Control ProtocolISDN Integrated Services Digital NetworkISO International Standards OrganizationITU International Telecommunication UnionLCP Link Control ProtocolLSB Least Significant BitLTE Long Term EvolutionMAC Medium Access ControlMAC-hs MAC in HSDPAMIMO Multiple Input and Multiple OutputMOS Mean Opinion ScoreMPEG Moving Pictures Expert GroupMRRU Maximum Received Reconstructed UnitMSC Mobile services Switching CenterMT Mobile TerminalNAL Network Adaptation LayerNALU NAL UnitNAS Non Access StratumNC No ContextNCP Network Control ProtocolNRG Normalized Rate GuaranteeOFDM Orthogonal Frequency Division MultiplexingPEHC PErkins Header CompressionPDCP Packet Data Convergence ProtocolPF Proportionally Fair

200 Glossaire

PHB Per Hop BehaviorsPLMN Public Land Mobile NetworkPPP Point-to-Point ProtocolPPPoE PPP over EthernetPS Packet SwitchedPSNR Peak Signal to Noise RadioPSQA Pseudo-Subjective Quality AssessmentPSTN Public Switched Telephone NetworkQCIF Quarter Common Intermediate FormatQoS Quality of ServiceRAD Required Activity DetectionRAP Rate Adaptation ProtocolRED Random Early DetectionRG Rate GuaranteeRIO Red In and OutRLC Radio Link LayerRNC Radio Network ControllersRNN Random Neural NetworkROCCO RObust Checksum-based header COmpressionROHC RObust Header CompressionROTT Relative One-way Trip TimeRR Round RobinRRC Radio Resource ControlRTO Retransmission TimeOutRTP Real-time Transport ProtocolRTT Round Trip TimeSC Static ContextSCTP Stream Control Transmission ProtocolSGSN Serving GPRS Support NodeSMS Short Messaging ServiceSN Sequence NumberSNR Signal-to-Noise RatioSO Second OrderSSD Slow Start Duration

Glossaire 201

SVC Scalable Video CodecSWW Sliding Window WidthTAROC TCP-Aware RObust header CompressionTCP Transmission Control ProtocolTE Terminal EquipmentsTEAR TCP Emulation at ReceiversTFRC TCP-Friendly Rate ControlTS TimeStampTTI Transmission Time IntervalUDP User Datagram ProtocolUE User EquipmentUMTS Universal Mobile Telecommunications SystemUTRAN UMTS Terrestrial Radio Access NetworkVBR Variable Bit RateVCL Video Coding LayerVLR Visitor Location RegisterVoD Video on DemandVoIP Voice over IPVS Video StreamingWAP Wireless Access ProtocolWCDMA Wideband Code Division Multiple AccessWLED Wireless Loss Estimation in IP DiffServ networksWLSB Window-based LSBWMSTFP Wireless Multimedia Streaming TCP-Friendly ProtocolWWW World Wide Web

202 Glossaire

Bibliography

[1] EURANE. http://www.ti-wmc.nl/eurane/.

[2] YouTube. http://www.youtube.com.

[3] Transmission Control Protocol. Internet Standards Track RFC 793, IETF,September 1981.

[4] Requirements for Internet Hosts – Communication Layers. Internet StandardsTrack RFC 793, IETF, October 1989.

[5] RTP: A Transport Protocol for Real-Time Applications. Internet StandardsTrack RFC 1889, IETF, January 1996.

[6] 3GPP TS 25.848, Physical layer aspects of UTRA High Speed Downlink PacketAccess: Iub/Iur protocol aspects, release 4, 2001.

[7] 3GPP TS 25.308, High Speed Downlink Packet Access: Overall description,release 5, March 2002.

[8] 3GPP TS 25.323, Technical Specification Group Radio Access Network: PacketData Convergence Protocol (PDCP) Specification, 2002.

[9] 3GPP TS 25.877, Technical Specification Group Radio Access Network: HighSpeed Downlink Packet Access: Iub/Iur protocol aspects, release 5, June 2002.

[10] 3GPP TS24.008, Technical Specification Group Core Network: Mobile RadioInterface Layer 3 Specification, 2002.

[11] ISO/IEC 14496-10 and ITU-T recommendation H.264, Advanced Video Cod-ing, 2003.

[12] 3GPP TR 22.978 V 7.1.0, ALL-IP Network (AIPN) feasibility study, 2005.

[13] 3GPP TR 23.107 V 5.13.0, Technical Specification Group Services and SystemAspect; Quality of Service (QoS) concept and architecture,Release 5, 2005.

203

204 Bibliography

[14] 3GPP TS 25.301 V 5.6.0, Technical Specification Group Radio Access Net-work; Radio Interface Protocol Architecture, Release 5, 2005.

[15] 3GPP TR 25.913 V 7.3.0, Requirements for Evolved UTRA (E-UTRA) andEvolved UTRAN (E-UTRAN), 2006.

[16] 3GPP TR 21.902 V 7.0.0, Evolution of 3GPP system, Release7, 2007.

[17] 3GPP TR 26.937 V 7.0.0, Transparent end-to-end packet switched streamingservice (PSS); Real-time Transport Protocol (RTP) usage model, Release 7,2007.

[18] Ozgur B. Akan and Ian F. Akyildiz. ARC: the analytical rate control scheme forreal-time traffic in wireless networks.IEEE/ACM Transactions on Networking,12(4):634–644, 2004.

[19] Antonios Alexiou, Dimitrios Antonellis, and Christos Bouras. Equation basedcongestion control for video transmission over WCDMA networks. In IEEEAINA 2006, April 2006.

[20] Pablo Ameigeiras.Packet Scheduling and Quality of Service in HSDPA. PhDthesis, Institute of Electronic Systems, Aalborg University, Denmark, October2003.

[21] Matthew Andrews, Krishnan Kumaran, Kavita Ramanan, Alexander Stolyar,Phil Whiting, and Rajiv Vijayakumar. Providing quality of service over a sharedwireless link.IEEE Communications Magazine, 39(2):150–154, February 2001.

[22] A. Argyriou and V. Madisetti. Streaming H.264/AVC video over the internet.In Consumer Communications and Networking Conference, 2004. CCNC 2004.First IEEE, pages 164 – 174. IEEE, January 2004.

[23] Goel Ashvin, Krasic Charles, Li Kang, and Walpole Jonathan. Supporting LowLatency TCP-Based Media Streams. InProceedings of IWQoS, May 2002.

[24] Gwen Barriac and Jack Holtzman. Introducing delay sensitivity into the propor-tional fair algorithm for CDMA downlink scheduling. InIEEE Seventh Inter-national Symposium on Spread Spectrum Techniques and Applications, 2002,September 2002.

[25] P. Bender, P. Black, M. Grob, R. Padovani, N. Sindhushayana, and A. Viterbi.CDMA/HDR: A Bandwidth-Efficient High-Speed Wireless Data Service forNomadic Users.IEEE Communications Magazine, pages 70–77, July 2000.

Bibliography 205

[26] Saad Biaz and Nitin Vaidya. Distinguishing congestion losses from wirelesstransmission losses: A negative result. InProceedings of IEEE IC3N ’98, page722, Washington, DC, USA, 1998.

[27] Saad Biaz and Nitin H. Vaidya. Discriminating congestion losses from wirelesslosses using inter-arrival times at the receiver. Technical Report 98-014, CSDept., Texas A & M University, August 1998.

[28] Saad Biaz and Nitin H. Vaidya. "De-randomizing" congestion losses to improveTCP performance over wired-wireless networks.IEEE/ACM Transactions onNetworking, 13(3):596–608, 2005.

[29] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. An archi-tecture for differentiated services. Internet Standards Track RFC 2475, IETF,December 1998.

[30] G. Boggia, P. Camarda, and V.G. Squeo. ROHC+: a new header compressionscheme for TCP streams in 3G wireless systems.IEEE International Conferenceon Communications, ICC’02, 5:3271–3278, May 2002.

[31] J. C. Bolot. End-to-End Packet Delay and Loss Behavior in the Internet. InACM SIGCOMM’93, pages 289–298, September 1993.

[32] Pablo Frank Bolton, Jose Incera, and Kamal Deep Singh. Objective and subjec-tive characterization of video streams in IP networks. InROC&C 2005, Aca-pulco, Mexico, November 2005.

[33] Thomas Bonald and Alexandre Proutière. Wireless Downlink Data Channels:User Performance and Cell Dimensioning. InProceedings of Mobicom’03,September 2003.

[34] C. Bormann. Robust Header Compression (ROHC) over PPP.RFC3241, April2002.

[35] C. Bormann, C. Burmeister, M. Degermark, H. Fukushima, H. Hannu, L-E.Jonsson, R. Hakenberg, T. Koren, K. Le, Z. Liu, A. Martensson,A. Miyazaki,K. Svanbro, T. Wiebke, T. Yoshimura, and H. Zheng. RObust Header Com-pression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncom-pressed. Internet Standards Track RFC3095, IETF, July 2001.

[36] Sem Borst. User-level performance of channel-aware scheduling algorithms inwireless data networks.IEEE/ACM Transactions on Networking, 13(3):636–647, 2005.

206 Bibliography

[37] S. Casner and V. Jacobson. Compressing IP/UDP/RTP Headers for Low-SpeedSerial Links. Internet Standards Track RFC2508, IETF, 1999.

[38] Song Cen, Pamela C. Cosman, and Geoffrey M. Voelker. End-to-end differentia-tion of congestion and wireless losses.IEEE/ACM Transactions on Networking,11(5):703–717, 2003.

[39] Mun Choon Chan and Ramachandran Ramjee. TCP/IP performance over 3Gwireless links with rate and delay variation. InProceedings of MobiCom ’02,pages 71–82, New York, NY, USA, September 2002. ACM Press.

[40] Chin-Hui Chien and Wanjiun Liao. A self-configuring RED gateway for qualityof service (QoS) networks. InInternational Conference on Multimedia andExpo, 2003 ICME’03., volume 1, July 2003.

[41] David D. Clark and Wenjia Fang. Explicit allocation of best-effort packet deliv-ery service.IEEE/ACM Transactions on Networking, 6(4):362–373, 1998.

[42] Liesbeth Steffens Damir Isovic, Gerhard Fohler. Real-time issues of MPEG-2playout in resource constrained systems.IEEE Journal of Embedded Comput-ing, 1(2):239–256, 2005.

[43] L. De Cicco and S. Mascolo. TCP versus TFRC over wired and wireless internetscenarios: an experimental evaluation. InNEW2AN 2006, LNCS 4003, pages530–541, Saint Petersburg, May 2006.

[44] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification.Internet Standards Track RFC 2460, IETF, January 1998.

[45] M. Degermark, H. Hannu, L. Jonsson, and K. Svanbro. Evaluation of CRTP Per-formance over cellular Radio Links.IEEE Personal Communications, 7(4):20–25, 2000.

[46] M. Degermark, B. Nordgren, and S. Pink. IP Header Compression. InternetStandards Track RFC2507, IETF, 1999.

[47] David J. Farber, Gary S. Delp, and Thomas M. Conte. A Thinwire Protocolfor connecting personal computers to the INTERNET. InternetStandards TrackRFC914, IETF, July 2001.

[48] M. Feamster and H. Balakrishnan. Packet Loss Recovery forStreaming Video.In 12th International Packet Video Workshop, Pittsburgh, PA, USA, 2002.

[49] S. Floyd, R. Gummadi, and S. Shenker. Adaptive RED: An algorithm for in-creasing the robustness of RED. Technical report, ICIR, 2001.

Bibliography 207

[50] S. Floyd and V. Jacobson. Random early detection gateways for congestionavoidance. IEEE/ACM Transactions on Networking, 1(4):397–413, August1993.

[51] S. Floyd, E. Kohler, and J. Padhye. Profile for Datagram Congestion Con-trol Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control(TFRC). Internet Standards Track RFC4342, IETF, March 2006.

[52] Sally Floyd, Mark Handley, Jitendra Padhye, and Jorg Widmer. Equation-BasedCongestion Control for Unicast Applications.Technical report TR-00-03, Inter-national Computer Science Institute, March 2000.

[53] Sally Floyd, Mark Handley, Jitendra Padhye, and Jorg Widmer. Equation-basedcongestion control for unicast applications. InACM SIGCOMM 2000, pages43–56, Stockholm, Sweden, August 2000.

[54] Ramiro Garcia, Jose Incera, and Kamal Deep Singh. An Experimental eval-uation of H.264/AVC semantic codec video streaming in a Diffserv networkarchitechture. InROC&C 2005, Acapulco, Mexico, November 2005.

[55] Karl-Johan Grinnemo, Johan Garcia, and Anna Brunstrom.Taxonomy and sur-vey of retransmission-based partially reliable transportprotocols. ComputerCommunications, 27(15):1441–1452, September 2004.

[56] M. Gudmundson. Correlation model for shadow fading in mobile radio systems.Electronics Letters, 27(23):2145–2146, 1991.

[57] H. Hagino, Y. Miyazaki, Y. Onoe, Y. Atsumi, H. Komaki, M.Taniguchi, andN. Yamanouchi. A Playout Time Oriented Retransmission Scheme for Multi-media Streaming Systems. InHSNMC’03, Estoril, Portugal, July 2003.

[58] F. Hammer, P. Reichl, T. Nordstrom, and G. Kubin. Corrupted speech dataconsidered useful.Proc. 1st ISCA Tutorial and Research Workshop on AuditoryQuality of Systems, 2003.

[59] M. Handley, S. Floyd, J. Padhye, and J. Widmer. TCP Friendly Rate Control(TFRC): Protocol Specification. Internet Standards Track RFC 3448, IETF,January 2003.

[60] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski. Assured Forwarding PHBGroup. Internet Standards Track RFC 2597, IETF, June 1999.

[61] Harri Holma and Antti Toskala.WCDMA for UMTS: Radio Access for ThirdGeneration Mobile Communications. John Wiley & Sons Ltd., 3rd edition,2004.

208 Bibliography

[62] Harri Holma and Antti Toskala.HSDPA/HSUPA for UMTS: High Speed RadioAccess for Mobile Communications. John Wiley & Sons Ltd., 2006.

[63] Harri Holma and Antti Toskala.WCDMA for UMTS: HSPA Evolution and LTE.John Wiley & Sons Ltd., 4th edition, 2007.

[64] P. Hosein. Qos Control for WCDMA High Speed Packet Data. InIEEE Proc In-ternational Workshop on Mobile and Wireless Network Communications, pages169–173, September 2002.

[65] ITU-R. Methodology for the subjective assessment of thequality of televisionpictures. Recommendation BT.500.11, 2002.

[66] ITU-R Recommendation BT.500-10. Methodology for the Subjective Assess-ment of the Quality of Television Pictures, March 2000.

[67] ITU-T. Video coding for low bit rate communication, version 2. Recommenda-tion H.263, 1998.

[68] V. Jacobson. Compressing TCP/IP Headers. Internet Standards Track RFC1144,IETF, 1990.

[69] V. Jacobson, K. Nichols, and K. Poduri. An Expedited Forwarding PHB. Inter-net Standards Track RFC 2598, IETF, June 1999.

[70] Van Jacobson. Congestion Avoidance and Control. InACM SIGCOMM’88,pages 314–329, 1988.

[71] A. Jalali, R. Padovani, and R. Pankaj. Data throughput of CDMA-HDR a highefficiency-high data rate personal communication wirelesssystem. InProceed-ings of IEEE VTC 2000 Spring, volume 3, 2000.

[72] A. Joch, F. Kossentini, and P. Nasiopoulos. A performance analysis of the ITU-T draft H.26L video coding standard. InProceedings of the 12th InternationalPacket Video Workshop, April 2002.

[73] L. Jonsson and G. Pelletier. RObust Header Compression (ROHC): A Compres-sion Profile for IP. Internet Standards Track RFC3843, IETF, 2004.

[74] Lars-Erik Jonsson, Mikael Degermark, Hans Hannu, and Krister Svanbro.Header Compression for IP-Telephony over Cellular Links, 1999. IETF 46,Ericsson research group Presentation.

[75] Lars-Erik Jonsson, Mikael Degermark, Hans Hannu, and Krister Svanbro. RO-bust Checksum-based header COmpression (ROCCO). Internet EngineeringTask Force, draft-ietf-rohc-rtp-rocco-01.txt, June 2000.

Bibliography 209

[76] N. Kamaci and Y. Altunbasak. Performance comparison ofthe emerging H.264video coding standard with the existing standards. InProceedings of IEEEICME’03, July 2003.

[77] F. Kelly. Charging and rate control for elastic traffic.European Transactions onTelecommunications, 8:33–37, 1997.

[78] F. Kelly, A. Maulloo, and D. Tan. Rate control in communication networks:shadow prices, proportional fairness and stability.Journal of the OperationalResearch Society, 49, 1998.

[79] E. Kohler, M. Handley, and S. Floyd. Designing DCCP: Congestion controlwithout reliability, 2003.

[80] E. Kohler, M. Handley, and S. Floyd. Datagram CongestionControl Protocol.Internet Standards Track RFC4340, IETF, March 2006.

[81] T. E. Kolding. Link and system performance aspects of proportional fairscheduling in WCDMA/HSDPA. InProceedings of IEEE VTC 2003-Fall, vol-ume 3, pages 1717–1722, October 2003.

[82] Troels E. Kolding. QoS-Aware Proportional Fair PacketScheduling with Re-quired Activity Detection. InProceedings of IEEE VTC 2006-Fall, September2006.

[83] M. Krunz and H. Hughes. A Traffic Model for MPEG-Coded VBR Streams.In Proceedings of the ACM SIGMETRICS Conference on the Measurement andModeling of Computer Systems, pages 47–56, 1995.

[84] Sara Landstrom, Lars-Ake Larzon, and Ulf Bodin. Congestion control in a highspeed radio environment. InProceedings of the International Conference onWireless Networks, pages 617–623, Las Vegas, Nevada, USA, June 2004.

[85] LA Larzon, M. Degermark, S. Pink, LE Jonsson, and G. Fairhurst. RFC 3828:The lightweight user datagram protocol (UDP-Lite), July 2004.

[86] C. Le and Z. Liu. Adaptive Header Compression (ACE) for Real-Time Multi-media.Nokia Research Center, pages 1–38, 2000.

[87] Weiping Li. Overview of Fine Granularity Scalablilityin MPEG-4 Video Stan-dard. IEEE Transactions on Circuit and Systems for Video Technology, 11(3),March 2001.

[88] Sam Liang and David Cheriton. TCP-RTM: Using TCP for Real Time Multi-media Applications, 2001. http://gregorio.stanford.edu/sliang/rtm.pdf.

210 Bibliography

[89] Günther Liebl, Hrvoje Jenkac, Thomas Stockhammer, Christian Buchner, andAxel Klien. Radio Link Buffer Management and Scheduling for Video Stream-ing over Wireless Shared Channels. InProceedings of the 14th InternationalPacket Video Workshop, July 2004.

[90] Jun Liu, Ibrahim Matta, and Mark Crovella. End-to-end inference of loss naturein a hybrid wired/wireless environment. InProceedings of WiOpt’03, 2003.

[91] Wei Liu, Zongkai Yang, Jianhua He, Chunhui Le, and Chun Tung Chou. Anal-ysis and improvement on the robustness of AQM in Diffserv networks. InPro-ceedings of IEEE ICC 2004, volume 4, pages 2297–2301, June 2004.

[92] Anthony Lo, Geert Heijenk, and Ignas Niemegeers. Evaluation of MPEG-4Video Streaming over UMTS/WCDMA Dedicated Channels. InProceedingsof WICON’05, July 2005.

[93] M. Lundevall, B. Olin, J. Olsson, N. Wiberg, S. Wanstedt,J. Eriksson, andF. Eng. Streaming Applications over HSDPA in Mixed Service Scenarios. InProceedings of IEEE VTC 2004-Fall, volume 2, pages 841–845, September2004.

[94] R. Makkar, I. Lambadaris, J. Salim, N. Seddigh, B. Nandy, and J. Babiarz. Em-pirical study of buffer management scheme for DiffServ Assured ForwardingPHB. InProceedings of IEEE ICCCN, 2000.

[95] S. McCanne and S. Floyd.nsNetwork Simulator. http://www.isi.edu/nsnam/ns/.

[96] P. Mehra and A. Zakhor. TCP-based Video Streaming Using Receiver-drivenBandwidth Sharing. InInternational Packet Video Workshop, Nantes, France,April 2003.

[97] Ana Minaburo, Loutfi Nuaymi, Kamal Deep Singh, and Laurent Toutain. Con-figuration and Analyses of ROHC in the UMTS. InThe 14th IEEE Inter-national Symposium on Personal, Indoor, and Mobile Radio Communications(PIMRC’03), Beijing, China, September 2003.

[98] Ana Minaburo, Kamal Deep Singh, Laurent Toutain, CécileMarc, and ElizabethMartinez. Performance Improvement of Multimedia flows by using UDP-Liteand ROHC compression. InThe 5th ICICS International Conference on Infor-mation, Communications and Signal Processing, Bangkok, Thailand, December2005.

[99] Ana Minaburo, Kamal Deep Singh, Laurent Toutain, and Loutfi Nuaymi. Pro-posed behavior for robust header compression over a radio link. In IEEE Inter-national Conference on Communications (ICC 2004), Paris, France, June 2004.

Bibliography 211

[100] A. Miyazaki, A. H. Fukushima, K. Hata, T. Wiebke, R. Hakenberg, C. Burmeis-ter, and Matsushita. RTP payload formats to enable multipleselective re-transmission. Internet Engineering Task Force, draft-ietfavt-rtp-selret-04.txt,November 2001.

[101] A. Miyazaki, H. Fukushima, T. Wiebke, R. Hakenberg, andC. Burmeister. Ro-bust Header Compression Using Keyword-Packets. Internet Engineering TaskForce, Draft-Miyazaki-ROHC-KWHC-00, March 2000.

[102] S. Mohamed and G. Rubino. A Study of Real–time Packet Video Quality UsingRandom Neural Networks.IEEE Transactions On Circuits and Systems forVideo Technology, 12(12):1071 –1083, December 2002.

[103] J. Orozco and D. Ros. An Adaptive RIO (A-RIO) queue management algorithm.In Proceedings of QoFIS 2003, 2003.

[104] J. Orozco and D. Ros. Diffserv-Aware Streaming of H.264video. InProceed-ings of the 14th International Packet Video Workshop, December 2004.

[105] Stefan Parkvall, Eva Englund, Magnus Lundvell, and Johan Torsner. Evolving3G Mobile Systems: Broadband and Broadcast Services in WCDMA.IEEECommunications Magazine, pages 68–74, February 2006.

[106] Christina Parsa and J. Garcia-Luna-Aceves. Differentiating congestion vs. ran-dom loss: A method for improving TCP performance over wireless links. InIEEE WCNC’2000, pages 90–93, 2000.

[107] Klaus I. Pedersen, Preben E. Mogensen, and Troels E. Kolding. QoS Consider-ations for HSDPA and Performance Results for Different Services. InProceed-ings of IEEE VTC 2006-Fall, September 2006.

[108] G. Pelletier. RObust Header Compression (ROHC): Profiles for User DatagramProtocol (UDP) Lite. Internet Standards Track RFC4019, IETF,April 2005.

[109] Stephen Perkins and Matt W. Mutka. Dependency Removal for Transport Pro-tocol Header compression over Noisy Channels. InICC (2), pages 1025–1029,1997.

[110] Mike Piecuch, Ken French, George Oprica, and Mark Claypool. A Selec-tive Retransmission Protocol for Multimedia on the Internet. In Proceedingsof SPIE International Symposium on Multimedia Systems and Applications,Boston, MA, USA, November 2000.

212 Bibliography

[111] R. Price, R. Hancock, S. McCann, A. Surtees, P. Ollis, and M. West. Frame-work for EPIC-LITE. Internet Engineering Task Force, draft-ietf-rohc-epic-lite-01.txt, February 2002.

[112] K. Ramakrishnan, S. Floyd, and D. Black. The Addition of Explicit CongestionNotification (ECN) to IP. Internet Standards Track RFC 3168, IETF, September2001.

[113] Reza Rejaie, Mark Handley, and Deborah Estrin. RAP: An End-to-End Rate-based Congestion Control Mechanism for Realtime Streams in theInternet. InProceedings of INFOCOMM’99, 1991.

[114] I. Rhee, V. Ozdemir, and Y. Yi. TEAR: TCP Emulation at Receivers – FlowControl for Multimedia Streaming. Technical report, NCSU, April 2000.

[115] I. Richardson.H.264 and MPEG-4 Video Compression. John Wiley and Sons,2003.

[116] I.E.G. Richardson.H.264 and MPEG-4 Video Compression: Video Coding forNext-generation Multimedia. Wiley, 2003.

[117] M. Rossi, A. Giovanardi, M. Zorzi, and G. Mazzini. Improved header compres-sion for TCP/IP over wireless links.Electronics Letters, 36(23):1958–1960,November 2000.

[118] G. Rubino, P. Tirilly, and M. Varela. Evaluating Users’Satisfaction in PacketNetworks Using Random Neural Networks. InProceedings of ICANN’06,Athens, Greece, September 2006.

[119] G. Rubino, M. Varela, and S. Mohamed. Performance Evaluation of Real-time Speech through a Packet Network: a Random Neural Networks-based Ap-proach.Performance Evaluation, 57(2):141–162, May 2004.

[120] Mats Sagfors, Reiner Ludwig, Micheal Meyer, and Janne Peisa. Queue Man-agement for TCP Traffic over 3G links. InIEEE WCNC, pages 1663–1668,March 2003.

[121] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A transportProtocol for Real-Time Applications. Internet Standards Track RFC3550, IETF,July 2003.

[122] Scott Shenker. Fundamental design issues for the future internet.IEEE Journalon Selected Areas in Communication, 13(7), September 1995.

Bibliography 213

[123] W. Simpson. The Point to Point Protocol (PPP). Internet Standards TrackRFC1661, IETF, 1994.

[124] A. Singh, A. Konrad, and A.D. Joseph. Performance evaluation of UDP lite forcellular video.Proceedings of the 11th international workshop on Network andoperating systems support for digital audio and video, pages 117–124, 2001.

[125] Kamal Deep Singh, Arpad Huszak, David Ros, César Viho, and Gabor Jeney.Congestion control and Adaptive Retransmission for Multimedia Streamingover Wireless Networks. 2008. Submitted to an international conference.

[126] Kamal Deep Singh, Julio Orozco, David Ros, and Gerardo Rubino. Stream-ing of H.264 Video over HSDPA: Impact of MAC-Layer Schedulerson User-Perceived Quality. Technical Report RR-2007002-RSM, ENST Bretagne, 2007.

[127] Kamal Deep Singh and David Ros. Normalized Rate Guarantee Scheduler forHigh Speed Downlink Packet Access. InIEEE GLOBECOM’07, Washington,DC, USA, November 2007.

[128] Kamal Deep Singh and David Ros. TCP-Friendly Rate Control over High SpeedDownlink Packet Access. In12th IEEE Symposium on Computers and Commu-nications (ISCC’07), Aveiro, Portugal, July 2007.

[129] Kamal Deep Singh, David Ros, Laurent Toutain, and César Viho. Improvementof Multimedia Streaming using Estimation of Wireless losses. Research reportPI-1792, IRISA, March 2006.

[130] Kamal Deep Singh, David Ros, Laurent Toutain, and César Viho. ImprovingMultimedia Streaming over wireless using end-2-end estimation of WirelessLosses. InIEEE 64th Vehicular Technology Conference, Montreal, Canada,September 2006.

[131] Kamal Deep Singh, David Ros, Laurent Toutain, and César Viho. ProportionalResource Partitioning over Shared Wireless Links. InIEEE 66th Vehicular Tech-nology Conference (To appear), Baltimore, MD, USA, September 2007.

[132] Dorgham Sisalem and Henning Schulzrinne. The Loss-Delay Based AdjustmentAlgorithm: A TCP-Friendly Adaptation Scheme. InProceedings of NOSSDAV,Cambridge, UK., 1998.

[133] Andrew S. Tanenbaum.Computer Networks. Prentice Hall, 3rd edition, 1996.

[134] Y. Tobe, Y. Tamura, A. Molano, S. Ghosh, and H. Tokuda. Achieving moderatefairness for UDP flows by path-status classification. InProceedings of IEEELCN ’00, page 252, Washington, DC, USA, 2000.

214 Bibliography

[135] Laurent Toutain.Réseaux locaux et Internet. Hermes Lavoisier, 3rd edition,2003.

[136] Genadi Velev, Rolf Hakenberg, José Rey, and Michael Zink. TCP-friendlystreaming in next generation wireless networks. InIEEE CCNC 2004, pages181–186, January 2004.

[137] B. Wang, H. P. Schwefel, K. C. Chua, R. Kutka, and C. Schmidt. On implemen-tation and improvement of robust header compression in UMTS. In The 13thIEEE International Symposium on Personal, Indoor and Mobile Radio Commu-nications, volume 3, 2002.

[138] Stephan Wenger. H.264/AVC over IP.IEEE Transactions on Circuits and Sys-tems for Video Technology, 13(7):645–656, July 2003.

[139] Neill Whillans, Irene de Bruin, Simon Oosthoek, Frank Brouwer, Assed Je-hangir, and Geert Heijenk. Seacorn project, deliverable D3.2v2, End-to-endnetwork model for Enhanced UMTS, October 2003.

[140] T. Wiegand, G.J. Sullivan, G. Bjontegaard, and A. Luthra. Overview of theH.264/AVC Video Coding Standard.IEEE Transactions on Circuits and Sys-tems for Video Technology, July 2003.

[141] R.H. Wu, T. Ferguson, and B. Qiu. Digital video quality using quantitativequality metrics. In4th International Conference on Signal Processing, pages1013–1016, Beijing, China, 1998.

[142] Lisong Xu and Josh Helzer. Media streaming via TFRC: An analytical studyof the impact of TFRC on user-perceived media quality.Computer Networks:The International Journal of Computer and Telecommunications Networking,51(17):4744–4764, 2007.

[143] Fan Yang, Qian Zhang, Wenwu Zhu, and Ya-Qin Zhang. An end-to-end TCP-friendly streaming protocol for multimedia over wireless internet. InICME2003, Baltimore, Maryland, USA, July 2003.

[144] Qian Zhang, Wenwu Zhu, Ya-Qin Zhang, Richard Price, Robert Hancock,Stephen McCann, Mark A West, Abigail Surtees, and Paul Ollis.TCP-AwareRObust Header Compression (TAROC). Internet Engineering Task Force, draft-ietf-rohc-tcp-taroc-04.txt, November 2001.

[145] Bing Zheng and Mohammed Atiquzzaman. Network Requirement for Manage-ment of Multimedia over Wireless Channel. In5th IFIP/IEEE InternationalConference on Management of Multimedia Networks and Services, London,UK, 2002.

Bibliography 215

[146] C. Zhu. RTP Payload Format for H.263 Video Streams. Internet StandardsTrack RFC2190, IETF, 1997.

216 Bibliography

List of Figures

1.1 Perte ROHC avec différentes valeurs de L et BER. . . . . . . . . . .. 131.2 Perte au niveau application dans le mode unidirectionnel et optimiste

pour les quatre stratégies. . . . . . . . . . . . . . . . . . . . . . . . . 151.3 Qmin en fonction du nombre d’utilisateurs TCP. . . . . . . . . . . . . 191.4 Débit agrégé du trafic Best Effort en fonction du nombrenBE d’utili-

sateurs TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.5 Taux de perte pour des utilisateurs ayant des garanties de débit diffé-

rentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.6 Amélioration de la stabilité des débits de TFRC avec l’ordonnanceur

RG. Echelle temporelle = 1 s, distance entre l’UE et la BS = 300 m,etdébit garanti = 200 kbps. . . . . . . . . . . . . . . . . . . . . . . . . 22

1.7 Utilisation de la liaison sans fil pour différentes valeurs de probabilitéde perte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.8 PSNR moyen en fonction de la probabilité de perte sans filw, pourARC, TFRC, WLED et le cas sans retransmission, dans un réseau Diff-Serv. Le nombre d’utilisateurs web est de 10. . . . . . . . . . . . . .28

1.9 SNR moyen en fonction du nombre d’utilisateurs web, pourARC,TFRC, WLED et le cas sans retransmission, dans un réseau DiffServ.La probabilité de perte sans fil est dew = 0,1. . . . . . . . . . . . . . 28

3.1 A typical scenario of video streaming [17] . . . . . . . . . . . .. . . 423.2 Streaming of variable bit rate video [17] . . . . . . . . . . . . .. . . 423.3 “Staggered” RIO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.4 DiffServ coloring for video frames. . . . . . . . . . . . . . . . . .. . 473.5 A general UMTS network. . . . . . . . . . . . . . . . . . . . . . . . 493.6 QoS Architecture for UMTS. . . . . . . . . . . . . . . . . . . . . . . 513.7 Peak data rates for the Long Term Evolution (LTE) of the UMTS. . . 53

4.1 Headers overhead [17] . . . . . . . . . . . . . . . . . . . . . . . . . 584.2 UMTS Radio Interface Protocol Architecture [14] . . . . . . .. . . . 584.3 ROHC over UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

217

218 List of Figures

4.4 ROHC general header format packets. IR belongs to first compressionlevel, IR-DYN and UOR-2 to second compression level and type 1 and0 to third compression level. . . . . . . . . . . . . . . . . . . . . . . 61

4.5 ROHC Compression Levels. Each operation mode has these three lev-els of compression. Each compression level use different packet as forexample SO level use the UO-1, R-1, UO-0 and R-0 packets. . . . . . 65

4.6 ROHC Decompression Levels. . . . . . . . . . . . . . . . . . . . . . 674.7 ROHC compression. Illustration of Operation Modes (U, O, R), Tran-

sition Modes and the use of feedback with small error. . . . . . .. . 684.8 The ROHC Architecture has two types of error. . . . . . . . . . .. . 70

5.1 The Compression Parameters. They are localized in the compressor, inthe decompressor and in the different header format packets. Note thatat each end of the link both Compressor and Decompressor are present. 74

5.2 Percentage loss of packets at ROHC layer for different values of BER,k and operation modes. . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.3 Average compressed header length in U-mode with varyingIR-TIMEOUTand FO-TIMEOUT. The value of timers is in number of packets. .. . 79

5.4 ROHC loss for different values of BER and timers in U-mode with k =10 and n = 12. The value of timers is in number of packets. . . . . .. 80

5.5 Percentage loss of packets for different values of L. Whenk and nequals 10 and 12 respectively, IR-TIMEOUT equals 300 packetsandFO-TIMEOUT equals 40 packets. . . . . . . . . . . . . . . . . . . . 82

5.6 ACL in different operation mode. Where L = 5 and IR-TIMEOUTequals 300 packets FO-TIMEOUT equals 40 packets. . . . . . . . . .83

5.7 Actual and Proposed ROHC Negotiations. The proposed negotiationgives the opportunity to use the accepted parameters for both sides andalso to receive information from the RRC to know the updated linkvariables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.8 ROHC loss with different values of L and BER. . . . . . . . . . . . . 875.9 The ACL of the Static vs Dynamic configuration for different values

of L and BER. Note that 2 bytes are extra because UDP checksum ismandatory for IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.10 Checksum coverage strategies. . . . . . . . . . . . . . . . . . . . . .895.11 Application loss in the Unidirectional and Optimisticmode in the four

strategies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.12 ROHC loss in the Unidirectional and Optimistic mode. . .. . . . . . 93

6.1 UMTS video streaming scenario. . . . . . . . . . . . . . . . . . . . . 986.2 Example of received power by UEs (Ped A, 3km/h) at different dis-

tances from the Base Station. . . . . . . . . . . . . . . . . . . . . . . 996.3 Example of HSDPA scheduling. . . . . . . . . . . . . . . . . . . . . 101

List of Figures 219

6.4 Scheduler Trade-off. . . . . . . . . . . . . . . . . . . . . . . . . . . 1026.5 Packet Queues in EURANE. . . . . . . . . . . . . . . . . . . . . . . 105

7.1 Simulation topology. . . . . . . . . . . . . . . . . . . . . . . . . . . 1157.2 Reference video “Mother and Daughter”. The size format isQCIF and

the video is repeated 2 times to make its duration equal to 64 seconds. 1177.3 Comparison of DT and RIO. The numberNwww of WWW flows is 18

and the number of long-lived TCP flows is 2. . . . . . . . . . . . . . 1187.4 Qmin value with different values ofkBE andβ. . . . . . . . . . . . . . 1207.5 Total throughput obtained by Best Effort users with different values of

kBE andβ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207.6 Inverse CDF of PSQA scores with 10 TCP long flows as background

traffic. The bin size for the CDF is 0.25. A “fair” quality rating corre-sponds to PSQA = 3.0. . . . . . . . . . . . . . . . . . . . . . . . . . 121

7.7 Average PSQA scores. . . . . . . . . . . . . . . . . . . . . . . . . . 1237.8 Minimum PSQA score obtained after removing lower 5 percentile of

users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1237.9 Inverse CDF of average per-user throughput obtained by background

TCP flows. The bin size for CDF is 25 kbps. . . . . . . . . . . . . . . 1247.10 Minimum PSQA score obtained after removing lower 5 percentile of

users. The numberN of background TCP flows was varied. . . . . . . 1257.11 Total Best Effort throughput when the numbernBE of background TCP

flows was varied. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267.12 Minimum PSQA score obtained after removing lower 5 percentile of

users. The numberNwww of WWW flows was varied and the numberof long-lived flows was kept equal to 2. . . . . . . . . . . . . . . . . 126

7.13 CDF of the download times experienced by users. The number Nwww

of WWW flows is 20 and the number of long-lived TCP flows is 2. . . 1277.14 Bitrate vs time for the encoded video streams. . . . . . . . . .. . . . 1297.15 Comparison of RG (Hosein) and NRG scheduler. . . . . . . . . . . . 1307.16 Loss rate for users with different rate guarantees. . . .. . . . . . . . 131

8.1 Resource partitioning among different user groups. . . . .. . . . . . 1368.2 A lower QoS class as a single virtual user of a higher class. . . . . . . 1388.3 Ratioc1/cT

1 . Group 1 hasN1 = 10 users. . . . . . . . . . . . . . . . . 1398.4 Ratioc1/cT

1 . Group 1 hasN1 = 4 users. . . . . . . . . . . . . . . . . 1408.5 BE throughput versus total number of VS usersNVS. . . . . . . . . . 1418.6 Ratio of unsatisfied VS users versusNVS. . . . . . . . . . . . . . . . . 1428.7 BE throughput versusNVS, using rate control. . . . . . . . . . . . . . 1438.8 Ratio of unsatisfied VS users versusNVS, using rate control. . . . . . . 143

9.1 UMTS video streaming scenario. . . . . . . . . . . . . . . . . . . . . 151

220 List of Figures

9.2 Average packet delay for TFRC. . . . . . . . . . . . . . . . . . . . . 1559.3 Per-user throughput obtained by TFRC with different schedulers. . . . 1559.4 Average packet loss, delay and CoV of the rate of TFRC flows with

different schedulers. The timescale for CoV is 1.0 s. . . . . . . .. . . 1579.5 CoV of rate with different schedulers and varying distance from the

Base Station. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1589.6 Ratio of TFRC/TCP throughput. . . . . . . . . . . . . . . . . . . . . 1599.7 Example of the received power for a UE 300m from the BS. . . . .. 1609.8 TFRC and TCP throughput with a timescale of 4.0 s. . . . . . . . . .1609.9 TFRC and TCP throughput with a timescale of 1.0 s, UE distance is

300 m and the rate guarantee is 200 kb/s. . . . . . . . . . . . . . . . . 1619.10 Improvement in TFRC and TCP throughput stability with RG sched-

uler. The timescale is 1.0 s, UE distance is 300 m and the rate guaranteeis 200 kb/s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

10.1 WLED algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16610.2 Simulation topology. . . . . . . . . . . . . . . . . . . . . . . . . . . 16910.3 Estimated Congestion Loss. . . . . . . . . . . . . . . . . . . . . . . . 17110.4 Sending Rate variation. . . . . . . . . . . . . . . . . . . . . . . . . . 17210.5 Link Utilization for Different Wireless Loss Probabilities. . . . . . . . 17310.6 Topology used for testing TCP friendliness. . . . . . . . . . .. . . . 17410.7 TCP NewReno and WLED. . . . . . . . . . . . . . . . . . . . . . . . 17510.8 Stability and TCP-Friendliness of WLED . . . . . . . . . . . . . . .177

11.1 DCCP interaction with an application. . . . . . . . . . . . . . . . .. 18111.2 The number of lost packets, using the retransmission thresholds with

differentiation of frames. Without any background traffic.. . . . . . . 18611.3 The average video quality (PSNR). With a single FTP source as the

background traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18711.4 The average PSNR, using different threshold calculation methods. With

a single FTP source as the background traffic . . . . . . . . . . . . . 18711.5 Average PNSR, when the bottleneck link is shared among the DCCP

video connection and the WWW users. The value of wireless loss ratew = 0.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

11.6 Average PSNR of ARC-, TFRC-, WLED-ARC-based retransmissionsand the case without retransmission in a Diffserv network with varyingwireless loss probability and 10 WWW users. . . . . . . . . . . . . . 189

11.7 Average PSNR of ARC-, TFRC-, WLED-ARC-based retransmissionsand the case without retransmission in a Diffserv network. The valueof wireless loss ratew = 0.1. . . . . . . . . . . . . . . . . . . . . . . 190

11.8 The ratio of the number of retransmitted packets and thenumber oflost packets. The value of wireless loss ratew = 0.1. . . . . . . . . . 190

Résumé

Les réseaux mobiles de troisième génération ont été conçus pour offrir des servicesavancés de communication tels que la voix sur IP et le video-streaming, et des débitsrelativement élevés. On assiste aujourd’hui à une évolution vers des réseaux “toutIP”, plus efficaces et moins coûteux pour les opérateurs. De nouveaux problèmes seposent comme par exemple le surcoût dû aux en-têtes IP ou des taux de pertes depaquets élevés sur des liens radio. De plus, la plupart des réseaux IP existants ne peu-vent satisfaire les contraintes de ces applications en termes de délai, gigue ou pertes.La première partie de cette thèse porte sur un schéma de compression permettant deréduire le surcoût induit par les en-têtes IP. Ensuite, nousintroduisons de nouvellesstratégies pour le support de la qualité de service, basées sur l’ordonnancement des pa-quets. Enfin, nous étudions le contrôle de congestion pour lavidéo, et nous proposonsdes mécanismes d’estimation des pertes dues à la radio et de retransmission sélective,visant à améliorer la qualité des flux vidéo.

Abstract

The third generation mobile networks are designed to further enhance the communica-tion by providing higher data rates and varied services, like voice, data and multimediastreaming services. The trend is towards an “All IP Network”that will bring efficiencyand cost reduction for the network equipments. Nevertheless, there are some new de-sign problems such as the large IP overhead and high packet loss rates found in theradio links. Moreover, the existing IP network, the currentInternet, cannot satisfythe requirements of real time applications in terms of delay, loss, jitter, etc. The firstpart of this document focuses on the IP header compression scheme to reduce the IPoverhead. The next part proposes novel QoS differentiationstrategies using packetscheduling that aim to satisfy the requirements of servicessuch as video streaming.The last part studies congestion control for applications such as video streaming andQoS is further improved with the help of a wireless loss estimation and selective re-transmission scheme.

Documents

· No d’ordre: 3586 THÈSE présentée devant l’Université de Rennes 1 pour obtenir le grade de : DOCTEUR DE L’UNIVERSITÉ DE RENNES 1 Mention INFORMATIQUE par …