capacity analysis of iptv over ieee 802.11n

Capacity Analysis of IPTV

over IEEE 802.11n

By

Saad Saleh

2011-NUST-MS-EE(S)-018

Supervisor

Dr. Zawar Hussain Shah

NUST-SEECS

A thesis submitted in partial fulfilment of the requirements for the degree

of Masters of Science in Electrical Engineering (MS EE)

In

School of Electrical Engineering and Computer Science,

National University of Sciences and Technology (NUST),

Islamabad, Pakistan.

(July 2013)

iii

Dedication

I dedicate this thesis to my parents and teachers

iv

CERTIFICATE OF ORIGINALITY

I hereby declare that the thesis titled “Capacity Analysis of IPTV over

IEEE 802.11n” is my own work and to the best of my knowledge it contains

no materials previously published or written by another person, nor material

which to a substantial extent has been accepted for the award of any degree or

diploma at SEECS or any other education institute, except where due

acknowledgment, is made in the thesis. Any contribution made to the research

by others, with whom I have worked at SEECS or elsewhere, is explicitly

acknowledged in the thesis.

I also declare that the intellectual content of this thesis is the product of

my own work, except to the extent that assistance from others in the project’s

design and conception or in style, presentation and linguistic is acknowledged.

I also verified the originality of contents through plagiarism software.

Author Name: Saad Saleh

Signature: ______________

v

Acknowledgment

This thesis is a milestone in my academic carrier. Extensive research has

increased my knowledge in learning theories and concepts. I am grateful to

Almighty Allah who gave me strength and support throughout the research

work. It would not have been possible without His blessings.

I am eternally grateful to my family who have always supported me by

their encouragement and by moral and emotional support throughout the

dissertation.

My special thanks to my committee members, Dr Adeel Baig, Dr Adnan

Khalid Kiani, Dr Khawar Khurshid and to all those students and teachers who

contributed towards the successful completion of my dissertation.

Finally, my utmost gratitude to Dr. Zawar Hussain Shah who provided

me assistance and invaluable thoughts in my research process. His

recommendations and advices have enabled me to fulfil the requirements of the

dissertation effectively. Apart from his assistance and support during the thesis,

I am alone responsible for any errors or omissions which may remain in the

dissertation.

Saad Saleh

vi

Table of Contents

1 Introduction 1

1.1 Capacity of IPTV and VoIP over IEEE 802.11n 3

1.2 Transport Layer Protocols for IPTV and VoIP 3

1.3 Access Point parameters for IEEE 802.11n 3

1.4 Research Gap & Problem Statement 4

1.5 Thesis contribution 5

1.6 Thesis Organization 6

2 Literature Review

2.1 Wireless IPTV 7

2.2 Wireless VoIP 8

2.3 Combined IPTV and VoIP 10

2.4 IEEE 802.11n Parameters 10

2.5 DCCP 12

2.6 Conclusion 13

3 Capacity Analysis of IPTV over IEEE 802.11n

3.1 Introduction 14

3.2 Capacity Analysis of Wireless IPTV 15

3.3 Bandwidth Analysis of IPTV 16

3.3.1 Factors Affecting Data Rate 16

3.3.2 Data Rate Requirement 17

3.3.3. Data Rate with Compression Schemes 18

3.4 Capacity of IPTV over IEEE 802.11n without Aggregation 18

3.5 IPTV Capacity Trends with Frame Aggregation 20

3.6 Capacity of IPTV using DCCP 22

3.6.1 Capacity of IPTV using TCP-like. 23

3.6.2 Capacity of IPTV using TFRC 23

3.6.3 Capacity Comparison of IPTV using UDP, 25

TCP-like and TFRC

3.7 IPTV capacity analysis with UDP and DCCP in the 26

presence of TCP traffic

3.8 Conclusion 27

4 Capacity Analysis of IPTV and VoIP over IEEE 802.11n

4.1 Introduction 29

4.2 Network Scenario 30

4.3 Capacity of combined IPTV and VOIP using UDP 32

vii

4.4 Capacity of combined IPTV and VoIP using TFRC 33

4.4.1 IPTV using TFRC and VoIP using UDP 33

4.4.2 IPTV using UDP and VoIP using TFRC 34

4.4.3 IPTV using TFRC and VoIP using TFRC 35

4.5 Capacity and Fairness of IPTV and VOIP with TCP traffic 37

4.5.1 IPTV and VoIP using UDP 38

4.5.2 IPTV and VoIP using TFRC 39

4.6 Conclusion 40

5 Tuning IEEE 802.11n Parameters for IPTV and VoIP

5.1 Introduction 41

5.1 Effect of Queue Size 42

5.2 Effect of Transmission Opportunity (TXOP) 43

5.3 Effect of Aggregation and Block Acknowledgement (ACK) 43

5.3.1 Block ACK in Low Bit Error Rate 44

5.3.2 Block ACK in High Bit Error Rate 44

5.4 Effect of Short Interframe Spacing (SIFS) 46

5.5 Effect of Distributed Interframe Spacing (DIFS) 46

5.6 Effect of Physical Header (PH) 47

5.7 Effect of Contention Window (CW) 48

5.8 Discussion 49

5.9 Conclusion 50

6 Conclusion

6.1 Summary 51

6.2 Future Work 52

7 Bibliography 53

viii

List of Abbreviations

Abbreviations Descriptions

A-MPDU Aggregate MAC Protocol Data Unit

A-MSDU Aggregate MAC Service Data Unit

AP Access Point

BER Bit Error Rate

CTS Clear To Send

CW Contention Window

DCCP Datagram Congestion Control Protocol

DIFS Distributed Inter-frame Spacing

FTP File Transfer Protocol

HDTV High Definition Television

IP Internet Protocol

IPTV Internet Protocol Television

MAC Medium Access Control

MIMO Multiple Input Multiple Output

MPDU MAC Protocol Data Unit

MSDU MAC Service Data Unit

PH Physical Header

QoS Quality of Service

RTS Request To Send

RTT Round Trip Time

SDTV Standard Definition Television

SIFS Short Inter-frame Spacing

TCP Transmission Control Protocol

TFRC TCP Friendly Rate Control

TXOP Transmission Opportunity

UDP User Datagram Protocol

VoIP Voice over Internet Protocol

WiFi Wireless Fidelity

WLAN Wireless Local Area Network

ix

List of Tables

1. IEEE 802.11n Access Point Parameters for IPTV 16

2. Data rate requirement for various compression and resolution schemes 19

3. IPTV users over IEEE 802.11n without aggregation 19

4. IPTV capacity trends with packet aggregation 22

5. IPTV capacity using TCP-like 24

6. IPTV capacity using TFRC 25

7. IPTV capacity comparison for UDP and DCCP 26

8. Performance Statistics from IPTV (UDP/DCCP) Traffic

along with TCP traffic 27

9. IEEE 802.11n Access Point Parameters for IPTV and VoIP 31

10. Capacity of IPTV users versus VoIP users using UDP 32

11. Capacity of combined IPTV(TFRC) And VoIP(UDP) 34

12. Capacity of combined IPTV(UDP) and VoIP(TFRC) 35

13. Capacity of combined IPTV (TFRC) And VoIP (TFRC) 36

14. Performance Statistics For Combined IPTV and VOIP

along with TCP traffic 39

15. Default and Proposed Parameters for IEEE 802.11n 50

x

List of Figures

1. WiFi router, phone and TV in a home network 1

2. Capacity of IPTV over IEEE 802.11b and IEEE 802.11g networks 8

3. Combined VoIP and tracking capacity over IEEE 802.11b

and IEEE 802.11g WLAN 9

4. Throughput and delay versus number of hops 10

5. Fairness analysis of UDP and DCCP with TCP 12

6. IPTV Network Scenario 16

7. HDTV performance without Aggregation 20

8. Throughput and delay requirement for HDTV users

versus time without aggregation 20

9. Throughput and delay requirement for HDTV Users

versus time with 4 times packet aggregation 21

10. HDTV performance with Optimal Aggregation 22

11. IPTV Capacity Trends with Packet Aggregation size 23

12. Packet delay for 3 and 4 IPTV sources using TCP-like 24

13. Packet delay for 5 and 6 IPTV sources using TFRC 24

14. Throughput and delay of HDTV users versus time

with TCP traffic using 4 times packet aggregation 27

15. Fairness of UDP and DCCP with TCP traffic 28

16. IPTV and VoIP Network Scenario 31

17. Capacity of IPTV users versus VoIP users using UDP 33

18. Capacity of combined IPTV(TFRC) versus VoIP(UDP) 34

19. Capacity of combined IPTV (UDP) versus VoIP (TFRC) 35

20. Capacity of combined IPTV (TFRC) And VoIP (TFRC) 36

21. IPTV and VoIP over multiple protocols 37

22. Capacity of IPTV and VoIP with TCP traffic 38

23. IPTV and VoIP Capacity versus Queue size 43

24. IPTV and VoIP Capacity versus Transmission Opportunity 44

25. Capacity of IPTV and VoIP in Low BER 45

26. Capacity of IPTV and VoIP in High BER 45

27. IPTV and VoIP Capacity versus SIFS 46

28. IPTV and VoIP Capacity versus DIFS 47

29. IPTV and VoIP Capacity versus Physical Header 48

30. IPTV and VoIP Capacity versus Contention Window 49

31. Capacity of combined IPTV and VoIP over UDP and TFRC

With optimized and non-optimized parameters 49

xi

Abstract

Internet Protocol Television (IPTV) has gained an enormous growth rate

by revolutionizing personal entertainment. High data rates with increased

coverage radius of IEEE 802.11n Wireless Local Area Networks (WLANs)

motivate the concept of wireless IPTV. Focusing on wireless IPTV, our work

deals with the capacity evaluation of IPTV users over IEEE 802.11n. We first

present an upper capacity limit for supporting maximum number of users over

IEEE 802.11n. We then propose that 4-times packet size is the optimal frame

aggregation size for IPTV which maximizes users capacity and QoS.

Moreover, we suggest the use of Datagram Congestion Control Protocol

(DCCP) at transport layer for IPTV. We show that DCCP increases capacity

upto 35% for IPTV by reducing packet losses at Access Point (AP), compared

to User Datagram Protocol (UDP). We further evaluate fairness of IPTV traffic

in the presence of Transmission Control Protocol (TCP) traffic in the network.

Our study concludes that IPTV using DCCP over IEEE 802.11n not only

provides increased user’s capacity but also co-exists fairly with TCP traffic.

Transmission of combined IPTV and VoIP over a wireless network is a

challenging task. We evaluate capacity of combined IPTV and VoIP over IEEE

802.11n. We then evaluate the use of DCCP at transport layer of IPTV. Our

study shows that DCCP(TFRC) can provide 25% additional IPTV users. Our

results suggest that performance of DCCP is worst in presence of any other

UDP flow because of congestion-less mechanism of UDP. Our fairness

analysis with TCP traffic shows that IPTV and VoIP using TFRC provide fair

share in bandwidth to TCP with 19% increase in combined capacity. We

evaluate optimal parameters of IEEE 802.11n AP for running IPTV and VoIP.

We show the optimal values and trends of AP parameters including queue size,

transmission opportunity, aggregation and block acknowledgement etc. Our

study shows that nearly 9 more VoIP users are supported with a queue size of

70 packets and transmission opportunity of 9. Our study concludes that

selection of DCCP and optimized parameters over IEEE 802.11n can enhance

capacity of IPTV and VoIP by at-least 19% than use of UDP.

Chapter 1Introduction

Internet Protocol (IP) based networks have gained huge growth rates in the pastfew years. A number of features are provided in IP based networks which includeeconomics, interactivity and better Quality of Service (QoS). These features have ne-cessitated the demand for triple play services over the internet. Triple play servicesrefer to the transmission of television, phone and internet simultaneously at the userend. A number of manufacturers are supplying triple play services at the user end. Dueto huge growth in the market and industry of telecommunications, the next phase is thedemand for telephone, internet and television over the wireless technology at the userend. Transmission of triple play services over the wireless network is a challengingtask. They are a combination of real time and non-real time traffic with different QoSrequirements. A typical view of a home network using a number of Wireless Fidelity(WiFi) devices is shown in Fig. 1.1.

Figure 1.1: WiFi router, phone and TV in a home network

Internet Protocol Television (IPTV) is the killer application for the future net-works [17]. The demand of data rate and timing latency requirements for IPTV makeit a great area of research for improving the QoS in terms of throughput, packet loss,delay and latency. A number of schemes have been suggested for the improvement ofIPTV services at the user end. IPTV system transmits information in encoded and com-pressed form through various encoders and compressors. Unicast mechanism has been

1

converted to multicast mechanism over wired ethernet mechanism and the main purposewas to support maximum number of users in the given environment. In the transmissionof IPTV services, low bandwidth between the user end and Access Point (AP) is themain problem. Bandwidth between AP and server has rose to Giga Bit per seconds. Asa result of bandwidth issues, delay in channel change time has increased and this delayis called the channel zap time. Channel zap time refers to the difference in time whena user requests a new channel from the server and the time instant when the first packetreaches the user end. The main delays encountered are jitter delays, buffer delays, net-work processing time and decoding time of Station Top Box (STB). Apart from delays,packet loss is another critical factor affecting the number of IPTV users. Packets dropfrom queues of AP which disrupts the support for large number of IPTV users. The de-mand of IPTV in wireless environment is also increasing. It is still an open problem totransmit IPTV with maximum support for users through Wireless Local Area Network(WLAN).

Voice over Internet Protocol (VoIP) is another fastly growing internet application.In 2010, VoIP users have grown to more than 250 million subscribers worldwide whichis more than 10 times of IPTV users [29]. Analysis of IPTV would be incomplete ifVoIP is not incorporated into the network containing IPTV traffic. VoIP basically refersto the communication technologies, protocols and techniques used for transmission ofvoice and multimedia sessions through IP based networks. To control the tear up anddown process, VoIP uses the popular session control protocols. A number of codecsare used by various voice schemes including the popular G.711 codec. Codec rate ofG.711 codec is 64 kbps and packetization interval is 10 ms. Transmission of VoIP at theuser end is a challenging task because of limited packet loss and delay requirements.Wireless LANs further deteriorate the capacity by increasing packet loss at the AP. Lowbandwidth at user end increases the delay experienced by VoIP end user. Moreover,VoIP is a bidirectional traffic so two way delay and packet loss have to be encounteredto guarantee QoS at both user ends. Users demand, economics and freedom of mobilitydemand an insight investigation for VoIP with IPTV services in a home WLAN. Deter-mination of capacity of VoIP versus IPTV users can pave the way for future planning ofhome networks with wireless IPTV and VoIP.

IEEE 802.11n is the latest standard providing maximum data rates as compared toit predecessor standards. IEEE 802.11 a/b/g were providing limited data rates from 11Mbps to 54 Mbps. With the advent of IEEE 802.11n, theoretical data rate of 600 Mbps ispossible. Maximum available routers are having a data rate of 300 Mbps. IEEE 802.11nhas been equipped with a number of enhanced features including Multiple Input Mul-tiple Output (MIMO) technology. Multiple streams are transmitted from transmitterand received at the receiver antenna. Moreover, aggregation and block acknowledge-ment mechanism has been added to reduce overhead of transmission and for selective

2

retransmission. A number of physical layer features including SIFS, DIFS, ContentionWindow (CW) and Physical Header (PH) have been specified in the standard. Researchon IEEE 802.11n parameters for enhancing capacity of IPTV and VoIP users is an openproblem. This research would pave the way for transmission of wireless IPTV and VoIPover IEEE 802.11n with enhanced capacity.

1.1 Capacity of IPTV and VoIP over IEEE 802.11n

IPTV and VoIP are key applications for current generation wireless services. Satis-factory QoS must be provided to user ends for transmission of IPTV and VoIP services.Capacity of IPTV and VoIP refers to the number of users that can be accommodatedover IEEE 802.11n with satisfactory QoS. Satisfactory QoS refers to the packet lossand delay requirements of end users. This study would be a milestone for planningfuture home networks.

1.2 Transport Layer Protocols for IPTV and VoIP

IPTV and VoIP use User Datagram Protocol (UDP) at transport layer. UDP is acongestion-less protocol with less reliability and more time sensitive response. IPTVand VoIP require less packet loss and delay. UDP provides less delay but it cannot pro-vide less packet loss. For less packet loss, transport layer protocol of IPTV and VoIPmust be evaluated for better QoS. Moreover, UDP is a congestion less protocol whichcannot cope with the network congestion. In presence of high data rates at the AP, UDPencounters large packet loss due to congestion at AP. We study the use of DatagramCongestion Control Protocol (DCCP) at transport layer of IPTV and VoIP. DCCP pro-vides congestion mechanisms which can cope fairly with the network congestion. It hasgot two variants namely, TCP-like and TCP Friendly Rate Control (TFRC). TCP-likeoffers high reliability with less timely response. TFRC provides more timely responsewith less reliability. Our study evaluates both TCP-like and TFRC for transmission ofIPTV and VoIP over IEEE 802.11n.

1.3 Access Point Parameters for IEEE 802.11n

Majority of parameters of IEEE 802.11n AP have been adapted from previouslow data rate IEEE 802.11 a/b/g predecessor standards. With the use of IPTV andVoIP services at the user end over IEEE 802.11n AP, a study on the optimal values ofIEEE 802.11n AP is required. Queue size of IEEE 802.11n AP varies from vendor tovendor. Different services require different queue sizes depending upon the packet size

3

and arrival ratio of the packets. TXOP feature has been added in IEEE 802.11n whichgives more time to AP for data transmission. Aggregation has been added which is tobe exploited in maximizing the capacity of IPTV and VoIP users. Evaluation of optimalparameters of IEEE 802.11n for transmission of IPTV and VoIP services can increaseperformance of combined IPTV and VoIP.

1.4 Research Gap and Problem Statement

IEEE 802.11n can increase throughput and performance of combined IPTV andVoIP owing to its high data rate features. Most of the existing literature and research isfocused on transmission of IPTV and VoIP over IEEE 802.11 a/b/g WLANs. Supportfor users is limited in previous standards and satisfactory QoS can be provided for a fewnumber of users only. Evaluating the capacity of IPTV and VoIP users is required toestimate the efficiency and for planning of home networks.

At the advent of IPTV and VoIP, a transport layer protocol was required whichcould provide time sensitive response by avoiding retransmissions. UDP was the mostsuitable protocol which offers timely response to real-time applications with less focuson reliability. Now, network traffic has increased to a rate of Giga bit per sec with anumber of applications running simultaneously at the user end. Performance of non-real-time applications deteriorates severely in presence of UDP based applications be-cause UDP has no congestion control mechanism. With the advent of DCCP, study onevaluation of DCCP for combined IPTV and VoIP is required which could cope fairlywith the current network traffic categories.

Transmission of combined IPTV and VoIP over IEEE 802.11n requires an insightinvestigation on the parameters of IEEE 802.11n. Selection of optimal parameters isrequired to enhance capacity with minimum number of resources consumed. Currentresearch is focused on IPTV and VoIP over predecessor standards. Research on tuningof optimal parameters of IEEE 802.11n is required for transmission of combined IPTVand VoIP.

A formal problem statement is given as:“Capacity of IPTV and VoIP degrades in IEEE 802.11 WLANs due to large proto-

col overheads and packet losses at AP. Congestion-less transport layer protocol resultsnot only in packet loss but also results in unfair bandwidth allocation between differenttraffic categories.”

4

1.5 Thesis contribution

Contribution of our research work includes the capacity analysis of IPTV and VoIPover IEEE 802.11n. We focus on capacity enhancement by study of transport layerprotocols for IPTV and VoIP. Moreover, we suggest the use of optimal parameters fortransmission of IPTV and VoIP over IEEE 802.11n. Our various contributions are asfollows:

(i) We present an upper capacity limit for supporting maximum number of IPTV usersover IEEE 802.11n.

(ii) We propose that 4-times packet size is the optimal frame aggregation size for IPTVwhich maximizes users capacity and QoS.

(iii) We suggest the use of DCCP at transport layer of IPTV. We show that DCCP in-creases capacity of IPTV upto 35% by reducing packet losses at AP, compared toUDP.

(iv) We further evaluate fairness of IPTV traffic in the presence of Transmission ControlProtocol (TCP) traffic in the network. Our study shows that IPTV using DCCPover IEEE 802.11n not only provides increased users capacity but also co-existsfairly with TCP traffic.

(v) We evaluate the use of DCCP at transport layer of IPTV and VoIP. Our study showsthat DCCP can enhance capacity of IPTV by 25%.

(vi) Our study confirms that performance of DCCP deteriorates severely in presence ofany other UDP flow because of congestion-less mechanism of UDP.

(vii) Our fairness analysis with TCP traffic shows that IPTV and VoIP using DCCPprovide fair share in bandwidth to TCP with 19% increase in combined capacity.

(viii) We study the effect of IEEE 802.11n parameters and obtain optimal values. Weshow the optimal values and trends of AP parameters including queue size, trans-mission opportunity, aggregation and block acknowledgement etc. Our studyshows that nearly 9 more VoIP users are supported with a queue size of 70 packetsand transmission opportunity of 9.

(ix) Our study concludes that selection of DCCP and optimized parameters over IEEE802.11n can enhance the capacity of IPTV and VoIP by atleast 25% and 19%respectively as compared to the use of UDP.

5

1.6 Thesis Organization

The rest of the thesis is organized as follows:Chapter 2 reviews the related literature for IPTV, VoIP and IEEE 802.11n. Various

studies for transmission of IPTV over WiFi have been discussed. Studies of DCCP overVoIP have also been presented. Deficiencies in existing literature have been discussedand existing work has been broadly categorized for IPTV and VoIP analysis.

In chapter 3, we present the capacity analysis of IPTV over IEEE 802.11n. Westudy the frame aggregation mechanism for capacity enhancement. Our study evaluatesthe use of DCCP (TCP-like and TFRC) for IPTV and VoIP. We study fairness of IPTVtraffic with TCP traffic in the network.

Chapter 4 presents the analysis of IPTV along with VoIP traffic in the networkover IEEE 802.11n. We study the use of TFRC for IPTV or VoIP or both traffics in thenetwork. We analyze the transport layer with fairness comparison of TCP traffic in thenetwork.

In Chapter 5, we evaluate the optimal parameters of IEEE 802.11n AP for transmis-sion of combined IPTV and VoIP. We study queue size, transmission opportunity, aggre-gation, block acknowledgement, SIFS, DIFS, contention window and physical header.Moreover, we present the capacity by use of TFRC along with optimal parameters overIEEE 802.11n.

Thesis concludes with a summary of our research findings and a note on the futurework for analysis of IPTV over IEEE 802.11n in chapter 6.

6

Chapter 2Related Work

We present the related work in five different sections. In these sections, wepresent the related work for IPTV, VoIP, combined IPTV and VoIP, IEEE 802.11n andDCCP. Various related works in addition to their findings are as follows.

2.1 IPTV

Several studies have been conducted for IPTV distribution in wireless networks.In [17], Yang et al. claims that IPTV is a killer application for next generation internetand performance metrics need to be studied in WLANs. They suggested that IPTV canbring exciting revenues in future due to an increase in users demand. They surveyed onexisting technologies for provision of IPTV at the user end.

In [32], Singh et. al. evaluate the possibility of transmitting IPTV over WLANs.They study various protocols including Real-time Transport Protocol (RTP) for trans-mission of IPTV. A number of QoS techniques have been analysed to enhance perfor-mance over IEEE 802.11 WLAN. MAC mechanism has also been studied to evaluatethe possibility of IPTV transmission in a wireless network. They suggested that IEEE802.11 a/b/g WLANs do not provide enough data rates for transmission of large numberof IPTV users.

In [18], the authors show that IEEE 802.11b and IEEE 802.11g networks can sup-port upto 2 and 6 IPTV users respectively. Their simulation results from Fig. 2.1show that delay becomes untolerable after 2 and 6 streams for IEEE 802.11b and IEEE802.11g WLANs respectively. They show that system capacity has a non-linear re-lationship with data rate of WLAN. They studied the effect of Signal to Noise Ratio(SNR) on the capacity of IPTV. They showed that SNR and data rate of WLAN effectthe capacity of IPTV users.

In [19], Gidlund et al. show that IEEE 802.11b Wireless Mesh Network (WMN)can provide upto 3 IPTV channels with maximum 2 hops only. They conclude that cur-rent WLANs are not efficient for supporting IPTV and VoIP over multiple hops. As weincrease number of hops in the network then QoS is severely degraded. Low data ratesof current IEEE 802.11 a/b/g WLANs further limit the capacity of maximum numberof IPTV users. They suggest the use of IEEE 802.11n WLAN for IPTV because of itshigh data rate.

In [20], the authors suggest that IPTV packet loss can be minimized by minimizingnumber of hops in the network and maximizing buffer size. They extend fluid modelflow analysis to study buffer size and number of hops relationship with QoS of IPTV.

7

Figure 2.1: Capacity of IPTV over (a)IEEE 802.11b (b) IEEE 802.11g WLAN [18]

They have supported their analytical results through extensive ns2 simulations. Theyshowed that combined effect of hop count and buffer size has a beneficial effect on thecapacity of IPTV.

In [9], Atenas et al. develop an experimental test bed for IPTV performance overIEEE 802.11n. They estimate delay, jitter, packet loss and conclude that indoor envi-ronment can provide better QoS than outdoor. They have not shown the capacity resultsfor IPTV. Our study differs from their experimentation because we focus on frame ag-gregation trends and use of DCCP over IEEE 802.11n for IPTV.

Comparison of studies on IPTV shows that research on wireless IPTV is limiteddue to low data rates of IEEE 802.11n. Owing to high data rates of IEEE 802.11n, signif-icant performance improvement is expected for IPTV. Better features of IEEE 802.11ncan provide better QoS for IPTV.

2.2 VoIP

VoIP has been studied over IEEE 802.11 WLANs in various studies.In [32], the authors evaluate upper bound capacity limit for VoIP users over IEEE

802.11b WLAN through simulations. They conclude that IEEE 802.11b can support 3to 12 simultaneous VoIP calls based on codec packetization interval and transmissionrate in wireless medium. Their study shows that small packet size and small packetiza-tion intervals of VoIP limit the capacity over IEEE 802.11 WLANs.

In [21], the authors evaluate VoIP capacity over IEEE 802.11b/g WLANs throughsimulations and experiments. They show that there is a 30% decrease in combined VoIPand tracking capacity at higher packetization intervals in comparison to VoIP only ca-pacity. Their simulation results from Fig. 2.2 show that VoIP crosses packet loss thresh-old of 2% very quickly at lower packetization intervals. Their capacity findings are asource of motivation for our work of evaluating IPTV and VoIP over IEEE 802.11n.

8

Figure 2.2: Combined VoIP and tracking capacity over (a)IEEE 802.11b (b) IEEE802.11g WLAN [21]

In [33], the authors evaluate experimental performance of VoIP over IEEE 802.11btest-bed and compare it with theoretical and simulation results. They show that VoIPexhibits capacity of 15 calls with a packetization interval of 20 ms. They proved thatthere is a large gap between theoretical capacity and experimental results over IEEE802.11 WLANs.

In [36], the authors study VoIP traces to find long hand-offs and occurrence ofunpredictable bursts in VoIP. They conclude that VoIP can run through IEEE 802.11networks if there is less mobility and good signal strength. They carried out extensivesimulations on QoS of VoIP. Their study shows that QoS of VoIP is severely degradedin presence of high movement.

In [37], authors evaluate the reasons behind low performance of VoIP over IEEE802.11b networks. They provide a MAC layer enhancement mechanism for VoIP andshow that VoIP performance can be enhanced by 300% over IEEE 802.11b networks.Their study shows that MAC layer of IEEE 802.11b WLAN has significant non-compatiblefeatures for VoIP. A slight enhancement and modification in MAC layer can enhanceVoIP capacity for VoIP over IEEE 802.11b WLAN.

In [38], the authors show the performance of VoIP over IEEE 802.11g/e networks.This study shows that 13 VoIP calls can run over IEEE 802.11e network and perfor-mance can be enhanced by selecting contention window and TXOP according to re-transmission rate of the system. They show a performance increase of 24% by usingtheir contention window and TXOP mechanism. Their work on contention windowand TXOP acts as a source of motivation for our work on IPTV and VoIP over IEEE802.11n. They have shown that optimal selection of contention window and TXOP canenhance performance of VOIP significantly over IEEE 802.11g/e networks.

Comparison of studies on VoIP shows that VoIP users are significantly limited overIEEE 802.11b/g/e WLANs. QoS metrics of VoIP are difficult to keep in wireless en-vironments due to constantly varying conditions. Small packet size and packetizationinterval further make it more tedious to transmit VoIP over IEEE 802.11 WLAN. With

9

the advent of high data rates over IEEE 802.11n, significant performance and capacityimprovement is expected for VoIP.

2.3 Combined IPTV and VoIP

Combined IPTV and VoIP over wireless LAN has been studied in [19]. The authorsused reconfigured IEEE 802.11 b/g AP. They show through simulations and experimentsthat 3 IPTV streams can be provided along with VoIP connected with satisfactory QoSover 2 hops in the network as shown in Fig. 2.3. Results also show that throughput anddelay performance is enhanced in presence of RTS and CTS. They conclude that IPTVand VoIP capacity is limited in IEEE 802.11b/g WLANs. Addition of VoIP with IPTVtraffic in the network makes it a more challenging task to keep the QoS constraints ofboth IPTV and VoIP. Moreover, majority of IPTV traffic is uni-directional because videotransmits from server to user end and no traffic in opposite direction. On the other hand,VoIP uses bi-directional traffic which makes it a more challenging task by accountingQoS metrics at both ends.

Figure 2.3: (a) Throughput versus no. of hops (b) Delay versus no. of hops [19]

2.4 IEEE 802.11n

IEEE 802.11n is the latest standard providing maximum data rates to end users.A number of throughput and QoS enhancing mechanisms have been incorporated intoIEEE 802.11n standard. A number of studies have been conducted to investigate the in-sight of IEEE 802.11n standard. Some of these studies and their findings are describedin following paragraphs.

10

In [5], the authors show that MAC enhancements of IEEE 802.11n give significantperformance improvement than its legacy networks. They have compared performanceof IEEE 802.11 b/g networks with IEEE 802.11n standard. They have conducted ex-tensive simulations by using VoIP over IEEE 802.11n standard. By using VoIP QoSmetrics, they analyse the performance of VoIP over IEEE 802.11n standard. They con-clude with simulations that VoIP performance is significantly improved by using IEEE802.11n.

In [7], frame aggregation mechanism of IEEE 802.11n has been studied. The au-thors show that frame aggregation can increase channel utilization upto 95% for UDPtraffic. They conclude that frame aggregation at physical layer is more effective thanat MAC layer because of physical bit error rate. No individual acknowledgement issent for MAC layer aggregated frames. Individual acknowledgements are sent for onlyphysical layer frames which makes it a more better option to aggregate physical layerframes instead of aggregating MAC layer frames.

In [8], authors show that throughput performance of IEEE 802.11n is affected inpresence of legacy networks because of frame protection mechanisms. They show thatIEEE 802.11n AP shows best performance if no other legacy IEEE 802.11 WLAN existsin the vicinity of AP. They analyse performance of IEEE 802.11n in presence of legacynetworks. They conclude that capacity of IEEE 802.11n has enhanced as compared topredecessor standards even in presence of legacy networks.

IEEE 802.11n MAC enhancements have been evaluated in [39]. The authors con-clude that the enhanced MAC and physical layer features of IEEE 802.11n can signifi-cantly enhance capacity of VoIP. They study MIMO technology and also spatial divisionmultiplexing. Their study is an evaluation of the enhancement features of IEEE 802.11nstandard.

In [40], the authors study the frame aggregation mechanism for the transmissionsusing multicast delivery. They suggest that IEEE 802.11n cannot provide a reliablemulticast delivery method. For multicast, IEEE 802.11a is the only standard offeringmulticast delivery approach. They evaluate the effect of frame aggregation on MACthroughput. Their study shows that A-MPDU suits better for noisy channels. For idealnon-noisy channel, A-MSDU slightly outperforms A-MPDU.

Comparison of various studies over IEEE 802.11n shows that research over IEEE802.11n has been carried in reference to its performance. Limited research for VoIPover IEEE 802.11n has been carried out. With the advent of IEEE 802.11n, perfor-mance metrics are still unknown for performance of real time applications over IEEE802.11n.

11

2.5 DCCP

Datagram Congestion Control Protocol (DCCP) is the latest transport layer proto-col. A number of studies have been conducted over DCCP. Various studies along-withtheir findings are described in below paragraphs.

In [11], the authors suggest that DCCP can enhance performance for VoIP, videostreaming and video gaming. They show that change of data rate in congested situationscan increase performance of time-sensitive applications. They suggest that DCCP givesfair share to TCP rather than UDP. Their capacity findings and fairness evaluations area source of motivation for using DCCP over IPTV.

In [12], the authors present an experimental study of DCCP for streaming of multi-media packets over the internet. They study the behaviour of DCCP over IEEE 802.11gWLAN. They showed that TCP and DCCP share better bandwidth with each other.Their study shows that UDP flows degrade the performance of TCP and DCCP flowsin the network. They suggest that UDP can reach high throughput in presence of othernetwork flows but the high packet loss encountered makes it impossible to stream mediaapplications.

In [21], Imdad et. al. evaluate the capacity of VoIP and tracking data over IEEE802.11b/g WLANs. They study the use of DCCP for VoIP. Their fairness results forUDP and DCCP with TCP traffic are shown in Fig. 2.4 (a) and Fig. 2.4 (b) respec-tively. They show that DCCP for VoIP gives not only better bandwidth share to TCP butalso provides an increased capacity to VoIP users. They have studied DCCP at differ-ent packetization intervals and their results show that VoIP capacity increases at higherpacketization intervals.

Figure 2.4: Fairness Analysis of (a) UDP with TCP (b) DCCP with TCP [21]

In [13], the authors study the performance of paced and non-paced TCP with DCCPtraffic in the network. They carried out simulations for both short and long delay net-works. They show that paced TCP performs better in all long delay networks by pro-viding less varying throughput and less jitter. Moreover, they show that paced TCP

12

performs better in presence of DCCP (TCP-like) and DCCP (TFRC) in comparison tostandard TCP. They conclude that paced TCP must be preferred over non-paced TCPand also paced TCP should be applied for packet formatting of DCCP.

In [14], the authors study the DCCP (TFRC) for wireless networks. They show thatperformance of congestion control protocol DCCP is deteriorated in wireless networksdue to packet losses in the wireless environment. They present a mechanism for ex-plicitly marking packets. Their strategy detects the real congestion in the network andavoids the confusion between packet loss and network congestion. They have shownthrough simulations that their technique can improve throughput performance in wire-less LANs.

Comparison of various studies shows that DCCP is the better suitable protocol withTCP. DCCP provides fair share in bandwidth to TCP traffic in the network. A numberof studies have shown that DCCP is beneficial for real time applications. As far as weknow, no study has been conducted on use of DCCP for IPTV. DCCP is beneficial forother real time applications but performance metrics of DCCP for IPTV have not beenstudied.

2.6 Conclusion

Comparison of various studies shows that low data rates of IEEE 802.11b/g werethe major hurdles in the path of wireless IPTV. With the advent of high data rates ofIEEE 802.11n, performance of wireless IPTV is expected to improve. Moreover, useof DCCP is currently limited to voice and video applications only. As far as we know,very limited investigation has been made on frame aggregation trends and use of DCCPfor IPTV and VoIP over IEEE 802.11n wireless network.

13

Chapter 3IPTV Capacity Analysis over IEEE 802.11n

3.1 Introduction

Internet Protocol Television (IPTV) is an exciting application which provides stream-ing of television contents over Internet Protocol (IP) based networks. IPTV transmitsvideo, audio, data and graphics etc simultaneously to users. In the past few years, IPTVhas gained an unremarkable growth rate [2]. It has been predicted that IPTV networktraffic would increase from 34% to 54% by 2016 [2]. Users growth rate, packet lossreduction, channel change time reduction and coping fairly with the current networktraffic are key challenges for current IPTV infrastructure. The architecture of IPTV iscomposed of three major parts: video head end, transport network and video receiver.Video head end and video receiver deal with the transmission and reception of packets.Transport network includes the core network, distribution network and access network.IPTV service provider transports the IPTV streams to user end by using all entities ofthe transport network. Among all these entities, major bandwidth restricting entity intransport network is the Access Point (AP) because limited buffer size of queues at APdrops packets [4]. To avoid bandwidth restriction, wired access links are preferred byIPTV service providers. But ease of mobility, less installation cost and freedom of en-tertainment demands the shift of paradigm from wired to wireless infrastructure.

Among wireless technologies, IEEE 802.11n is the latest standard providing max-imum data rate. Frame aggregation is an important capacity enhancement mechanismfor IEEE 802.11n WLANs. Multiple frames are combined at Medium Access Control(MAC) Layer and physical layer. This feature reduces the header overhead and colli-sion time. Our study shows that significant capacity improvement is gained by frameaggregation mechanism for IPTV over IEEE 802.11n. We also show that there is anoptimal aggregation size for IPTV transmission over IEEE 802.11n. In [5]-[8], authorsshow that IEEE 802.11n gives performance improvement for VoIP and UDP based ap-plications while [9] experimentally verifies IPTV performance over IEEE 802.11n. Tothe best of our knowledge, no work has been done on the frame aggregation trends ofIPTV over IEEE 802.11n.

IPTV uses UDP at transport layer. IPTV requires less delay and less packet loss.UDP provides less delay but it increases packet loss because it has no network conges-tion avoidance mechanism. To resolve UDP’s congestion-less mechanism, DCCP hasemerged as a suitable transport layer protocol for streaming media applications [10].It has two variants i.e., TCP-like and TCP Friendly Rate Control (TFRC) protocol.

14

TCP-like offers high reliability with no retransmissions while TFRC prefers timelinessand avoids network congestion. Our study shows that DCCP (TFRC) can significantlyenhance IPTV capacity than UDP. Moreover, TCP and UDP cannot co-exist in anynetwork with fairness because TCP decreases its congestion window size in congestedsituations while UDP sends data with constant bit rate [15]. This results in starvation ofTCP flows [15]. We also study fairness of IPTV traffic with TCP traffic because 80% ofnetwork users are using TCP traffic [16]. Our fairness results show that DCCP is muchmore fairer to TCP than UDP.

Our main contributions in this work are,

(i) To determine capacity of IPTV users using IEEE 802.11n,

(ii) To investigate the effect of frame aggregation size on IEEE 802.11n for the capacityof IPTV,

(iii) To study the use of DCCP (TCP-like and TFRC) for IPTV over IEEE 802.11n inplace of UDP,

(iv) To evaluate the capacity of IPTV users using DCCP (TFRC) and UDP in the pres-ence of TCP flows in the network.

3.2 Capacity Analysis of Wireless IPTV

To evaluate the capacity of wireless IPTV, we use the open source simulation toolns2 [23]. We implement IEEE 802.11n MAC and physical layer module with DCCP(TCP-like and TFRC) at transport layer in ns2 [23]. Our implementation is an exten-sion of previous modules [5] and [24] which now provide support of enhanced dis-tributed channel access, transmission opportunity and access categories having timersin compatibility with the DCCP module. The developed module is compatible with thelegacy IEEE 802.11 module. Block acknowledgement and frame aggregation mecha-nisms have been modified to include Aggregate MAC Service Data Unit (A-MSDU)and Aggregate MAC Protocol Data Unit (A-MPDU). Packet format is modified to in-clude IEEE 802.11n and DCCP enhancement. We conduct capacity analysis for bothStandard Definition Television (SDTV) and High Definition Television (HDTV).

Fig. 3.1 shows the IPTV architecture, implemented in form of an IPTV serverat one end of internet and AP located on other side. A number of wireless nodes re-quiring IPTV traffic are connected to IEEE 802.11n AP. Table-3.1 lists the various slottimes used for configuring IEEE 802.11n AP having queue size of 70 packets [5]. IPTVpacket size is 1368 bytes.

15

Table 3.1: 802.11n Access Point ParametersParameter ValueSlot time 20 us

SIFS 10 usTXOP limit 3.264 ms

Channel Bandwidth 40 MHzBit error rate 0.000008

Area 500 * 500 m

Figure 3.1: IPTV Network Scenario

3.3 Bandwidth Analysis of IPTV

We evaluate the bandwidth requirements by taking into account all factors affectingdate rate. We study the various resolution formats and compression schemes. Using allthese factors, we calculate the data rate required for transmission of IPTV over IEEE802.11n.

3.3.1 Factors Affecting Data Rate

IPTV requires a picture resolution which takes into account a number of factors in-cluding the pixel quality given by luminance and chrominance. Luminance is basicallythe light intensity and chrominance is the colour depth. Moreover, a moving pictureis composed of a number of frames which move in series to make a moving picture,so IPTV takes into account the frames per sec. Another important factor is the size ofthe video resolution. Although a number of sizes exist but there are two standard sizes

16

used. Standard Definition Television (SDTV) gives a lower quality video with a ratio of16:9 or using a 4:3 resolution. This standard was used in previous analog televisions.Apart from SDTV, a new high resolution provisioning television called High DefinitionTelevision (HDTV) has also been proposed. Compression schemes play an importantrole in deciding the amount of data to be transmitted through the network. Moving Pic-ture Expert Group (MPEG) has suggested a number of compression schemes and themost important schemes are MPEG-2 and MPEG-4. Studies have revealed that H.264(MPEG-4) gives a much better compression ratio than the currently used MPEG-2 stan-dard.

3.3.2 Data Rate Requirement

Data rate requirement plays the most important role in evaluating the capacity ofIPTV for deploying in a given network. We evaluate the data rate by taking into accountall the factors. The various factors used in the data rate calculation have values given asfollows:

Frames per sec = 24fps for moviesSDTV picture resolution = 640 * 480 for 16:9 resolution.HDTV picture resolution = 1920* 1080 for (4:3) resolution.SDTV chrominance = 2 bytesHDTV chrominance = 3 bytes

Using all these factors the data rate required in uncompressed form is given by the equa-tion:

D = RHRV CFB (3.1)

Here RH is the horizontal resolution and RV is the vertical resolution for the pic-ture resolution. C is the chrominance factor and F is the intensity of frames per secused for the pictures. Applying various values in eq. 3.1, we find that the bandwidthrequirement for SDTV is about 117.96 Mbps and for HDTV it comes out to be 796.26Mbps. This is the application layer data rate and it ignores headers and retransmissionsrequired for a frame.

The data rate obtained without any compression scheme is very much high andpractically not possible to devote a large network bandwidth for IPTV. Various com-pression schemes have suggested that data rate can be decreased by a series of complexiterations using either MPEG-2 or H.264. These compression schemes present a veryhigh compression ratio given as follows:

MPEG-2 and H.263 compression ratio (Hcomp) = 30:1MPEG-4 and H.264 compression ratio (Hcomp) = 50:1Also, a group of pictures Ngop is generated which is arranged in a certain priority

17

given by I, P and B frames. Now the modified data rate equation after applying com-pression schemes become as follows:

D = RHRV CFBNgop/Hcomp (3.2)

We can use equation 3.2 to find the data rate for various resolutions against variouscompression ratios.

3.3.3 Data Rate with Compression Schemes

Application layer data rate can only be used for evaluation of the video qualityrequirement but the actual data rate is more due to headers which come from variouslayers of internet surfing model and also you require a number of retransmissions sorequired data rate increases by a certain amount. To evaluate the required data rate, weevaluate the MPEG-2 coding scheme (because it is the most used standard). Researcheshave shown that 7 MPEG-2 packets can be transmitted in IPTV transmission. Each ofthe MPEG-2 packet is composed of 4 bytes of header and 184 bytes of payload. So, atotal of 188×7 bytes (1316 bytes) are sent to the Internet service model. Internet ser-vice layer adds UDP header to the IPTV header and it requires an addition of 8 bytes indata packet. 20 bytes of IP header are added by the internet protocol layer. Normally,ethernet is used which requires an addition of further 14 bytes of header to the receivedpacket. Finally, 10 bytes are added by the ATM layer (if used in certain service mod-els).

Data = Application layer data (MPEG-2 encoded) + UDP header + IP header +Ethernet header + ATM layer (if used)By evaluating above equation, we find that the net data rate requirement is nearly equalto 1368 bytes. Above calculation simply shows that you require 1368 bytes for a trans-mission of 1288 bytes of data. I have ignored the fragmentation effect for simplicity.If you use fragmentation then depending upon the maximum amount of payload, youwould increase the header size and consequently more requirement for data. Headersize requirement can be given by a ratio of 1.062 : 1. Table-3.2 presents the data ratesrequired after applying compression schemes.

3.3.4 Capacity of IPTV over IEEE 802.11n withoutAggregation

We evaluate the capacity of wireless IPTV using IEEE 802.11n without using ag-gregation mechanism. Our motivation is to minimize IPTV packets delay by removingaggregation at AP which can enhance QoS. IPTV can tolerate a delay of 50ms [18].

18

Table 3.2: Data Rate Requirement for various compression and resolution schemesTV F C Resolution Compression Required Data

(fps) RH ∗RV Scheme Rate (Mbps)

SD 24 2 640 * 480 MPEG-2 3.93SD 24 2 640 * 480 MPEG-4 2.36HD 24 3 1920* 1080 MPEG-2 26HD 24 3 1920* 1080 MPEG-4 15.92

IPTV allows channel zap time of 200ms which is the time required to wait for a newchannel request [19]. Also, IPTV cannot tolerate packet loss greater than 1% [20].Table-3.3 shows that capacity is limited to a single HDTV user without aggregation.

Table 3.3: IPTV users over IEEE 802.11n without AggregationTV Capacity Packet Loss Delay Chan. zap timeHD 1 0.4% 2.5ms 7msSD 4 0.5% 3ms 58ms

If number of users are increased then it results only in loss of packets at AP. Fig.3.2 shows that average throughput drops from 15.86 Mbps to 8.8 Mbps with the additionof second HDTV user. Third user deteriorates the average throughput to 6 Mbps. Aver-age delay and channel zap time for second user are 3.2ms and 18ms which are less thantheir corresponding threshold values (50ms and 200ms respectively). Fig. 3.2 showsthat average throughput has an inverse relationship with number of wireless users whiledelay has direct relationship with number of users. Our results show that 1st user gets apacket loss of 0.4% while further users get packet loss greater than 1%. Results showthat any addition of HDTV channels after 1st channel results in loss of throughput be-cause there is no aggregation of packets at AP. Additional users have limited delay butpacket loss crosses threshold value. SDTV users exhibit similar behaviour but they havemore capacity than HDTV users because less resolution of SDTV allows more users tobe accommodated in the same bandwidth. This holds true for all our simulations resultspresented in this thesis.

Fig. 3.3 shows the results of average throughput and delay for HDTV over IEEE802.11n. Results show that capacity is shared by all the channels. Addition of users af-ter 1st user deteriorate the capacity of system by decreasing throughput of users. 1st usergets a minimum delay with 7ms channel zap time. Addition of second user increasesthe channel time to 15ms. Fourth user gets less channel zap time than the third userbecause majority of packets of fourth user are lost. Results also show that relative delayof packets increases by addition of users in the system. This behaviour occurs becauselarge number of users increase congestion in the network which results in an increase in

19

Figure 3.2: HDTV throughput and delay versus time without aggregation

delay for packets of all users.

Figure 3.3: HDTV throughput, delay and packet loss versus users without aggregation

3.3.5 IPTV Capacity Trends with Frame Aggregation

In this subsection, we aim to estimate the IEEE 802.11n aggregation trends forwireless IPTV. Our goal is to find the aggregation limit for which delay is tolerable andmaximum number of users can be accommodated. Fig. 3.4 shows the instantaneousthroughput and delay for packets. Results show that throughput of all users remainsconstant to 15.92Mbps upto four IPTV users. The addition of fifth user deterioratesthroughput by dropping packets at AP. Moreover, results of channel zap time and rela-tive delay show that channel zap time increases as we increase the number of wireless

20

users. The addition of fifth user decreases the channel zap time because packets are lostat the AP. The relative delay of packets increase by addition of IPTV users because ofan increase in congestion in the network.

Figure 3.4: HDTV throughput and delay versus time with optimal aggregation

Results from Fig. 3.5 show that throughput remains stable upto 4 HDTV users andit drops to 12.4 Mbps with the addition of 5th HDTV user. Channel zap time for allusers is less than 200ms. Delay of packets comes to be 2.1ms for 1 user and increasesupto 6.5ms for 6 users. Channel zap time varies from 9ms to 140ms. Packet loss graphshows that upto 4 users get a loss less than 1%. Packet loss for 5th user reaches to5.8%. Limited buffer size of queues at AP drop packets in congested situations. Thisresults in an increase in packet-loss with number of users. HDTV support is limitedto 4 users with optimal aggregation. SDTV users exhibit same trends having 4-timesoptimal packet aggregation size.

Table-3.4 shows that IPTV capacity increases as we increase the packet aggrega-tion size. After 4-times aggregation size, any further increase in packet aggregation sizeat AP does not increase capacity of IPTV users. Analysis shows that by using aggrega-tion, more packets can be sent from AP with less probability of collision. IPTV capacitydoes not increase after 4-times aggregation limit because the delay (57ms) for 5th usercrosses the threshold value (50ms). Packet aggregation at AP more than the thresholddelay value results in loss of capacity of IPTV users.

Fig. 3.6 shows the capacity trends of IPTV versus the packet aggregation sizes.Our results show that capacity increases by increasing number of IPTV users. Curve

21

Figure 3.5: HDTV Performance with Optimal Frame Aggregation

becomes constant after 4-times packet size. Finally, capacity decreases after 6 timespacket size because large delay disrupts the support for many users. SDTV users arealways more in number than the HDTV users because of less bandwidth consumptionby SDTV users.

Table 3.4: IPTV capacity trends with Packet Aggregation

TVPacket Aggregation

1-time 2-times 4-times 6-times 8-timesHD users 1 2 4 4 3HD delay 35ms 31ms 29ms 43ms 48msSD users 4 7 17 17 11SD delay 37ms 34ms 32ms 39ms 45ms

3.4 Capacity of IPTV using DCCP

IPTV using UDP encounters packet loss in congested situations because UDP hasno congestion control mechanism. To avoid packet-loss, we study the use of DCCPfor IPTV. DCCP has two famous variants namely TCP-like and TFRC [7]. TCP-like issimilar to the congestion mechanism of TCP and it gives abrupt changes in bandwidthwith more reliability. TFRC is a nearly constant bandwidth protocol which uses roundtrip time, segment size and packet loss rate to determine sending rate. We use bothvariants TCP-like and TFRC to determine IPTV capacity.

22

Figure 3.6: IPTV Capacity Trends with Packet Aggregation size

3.4.1 Capacity of IPTV using TCP-like

We configure IPTV for using TCP-like in place of UDP for same number of SDTV andHDTV sessions. A number of channels are turned-on one-by-one. Our aim is to esti-mate the number of channels for which delays and packet losses are tolerable.

Fig. 3.7 presents the results of delays for 3 and 4 sources respectively. Resultsclearly show that 3 sources limit the delay to 50ms. The addition of 4th source makesthe delay un-tolerable (above 50 ms). This suggests that 4 sources are not supportablewith IPTV using TCP-like. Our results of packet loss show that number of packets lostare less than UDP. But TCP-like makes the delay intolerable beyond threshold delayvalues.

Results from Table-3.5 suggest that 3 HDTV users are supported with optimal ag-gregation (4-times aggregation). Main reason for less capacity of TCP-like is attributedto its nature of preferring reliability over timeliness. Capacity of HDTV and SDTVchannels drop by 25% and 18% respectively by using TCP-like in place of UDP. Simu-lation results show that the delay for 4th and 15th user of HDTV and SDTV streams is75ms and 80ms, respectively. Packet loss is less than 1% by using TCP-like but packetdelay is greater than the threshold delay value. It implies that TCP-like can avoid packetloss but delay is un-tolerable which decreases IPTV user’s capacity.

3.4.2 Capacity of IPTV using TFRC

TCP Friendly Rate Control (TFRC) protocol is implemented in IPTV in place of UDP.Same numbers of SDTV and HDTV channels are turned on one-by-one.

23

Figure 3.7: (a) Delay of TCP-like with 3 sources - (b) Delay of TCP-like with 4 sources

Table 3.5: IPTV Capacity using TCP-likeTV Without Aggregation With 4-times Aggregation

HD1 3

delay=33ms pkt-loss=0.08% delay=42ms pkt-loss=0.1%

SD3 14


Fig. 3.8 presents the results of delay for IPTV using TFRC. The results show thatdelay is within the threshold value of 50ms. As we increase number of sources thendelay increases upto 35ms. Finally, the removal of sources stops the increasing trend indelay. We repeated same simulations by entering 6 sources one-by-one. Results showthat the delay is still within the threshold value of 50ms. But our readings of packetloss show that it has crossed 1% threshold by the use of 6 sources. It shows that upto 5sources of IPTV are supported by using TFRC for IPTV.

Figure 3.8: (a) Delay of TFRC with 5 sources - (b) Delay of TFRC with 6 sources

The results of IPTV using TFRC are presented in Table-3.6. Our results show thatcapacity for HDTV and SDTV channels increased by 25% and 35% respectively. Packetloss is upto 0.96% but it is still less than 1% threshold value. Delay for HDTV users is

24

upto 18 ms. Main reason for more capacity of TFRC is attributed to its nature of beingmore time sensitive than being reliable. TFRC decreases its data rate in congested situa-tions and sends those packets on next instants. Our results imply that TFRC encountersmore packet loss and less delay than TCP-like.

Table 3.6: IPTV Capacity using TFRCTV Without Aggregation With 4-times Aggregation

HD1 5


SD7 23


3.4.3 Comparison of IPTV capacity using UDP and DCCP(TCP-like and TFRC)

In this subsection, we perform a comparison of the transport layer techniques forIPTV. Our results from section-3.3.5 show that UDP gives sufficient capacity to IPTVusers. UDP gives 4 HDTV and 17 SDTV users using optimal frame aggregation at ac-cess point. No further users can be accommodated because if we increase users thanpacket loss at AP results in sharing of capacity between remaining users.

Using TCP-like for IPTV has made our IPTV system more reliable but has in-creased packet delay beyond threshold values. This behavior has degraded performancesuch that 3 HDTV and 14 SDTV users are supportable with optimum aggregation. Al-though congested situations have been avoided but packet delays have crossed thresholdvalue of 50ms. So, TCP-like would be unsuitable for IPTV.

Our proposed methodology suggests that we should use TFRC for transmittingIPTV streams. Major advantage gained is the increased capacity of IPTV. TFRC im-proves performance by decreasing data rate in congested situations. Simulations showthat 5 HDTV users and 23 SDTV users can be accommodated by using TFRC. Table-3.7presents a comparison of IPTV capacity by using original architecture and the proposedmodification.

Results from Table-3.7 present a comparison of the IPTV capacity by using DCCPin place of UDP. Comparison shows that TCP-like decreases capacity upto 25% thanUDP. Moreover, use of DCCP (TFRC) can increase capacity by 25%. It implies thatTFRC may be preferred over TCP-like for capacity enhancement of IPTV. TFRC in-creases performance by in time packets delivery with less packet loss. Use of aggrega-tion can further increase the capacity by 4-times of all transport layer protocols.

25

Table 3.7: IPTV Capacity Comparison for UDP and DCCPIPTV Capacity over IEEE 802.11n without Aggregation

TV UDP TCP-like TFRCHD 1 1 1SD 4 3 7

IPTV Capacity over IEEE 802.11n with AggregationTV UDP TCP-like TFRCHD 4 3 5SD 17 14 23

3.5 IPTV Capacity Analysis with UDP and DCCP inthe presence of TCP traffic

Network statistics claim that non-real time traffic is four times greater than thereal-time traffic [9]. This suggests that our analysis of IPTV would be incomplete ifwe don’t incorporate other traffic categories with IPTV traffic. In this subsection, wesuggest that use of DCCP not only improves IPTV capacity but it also gives fair shareto TCP. File Transfer Protocol (FTP) application has been implemented because it usesTCP as transport layer protocol. FTP traffic has a packet size of 1000 bytes. OriginalIPTV architecture carrying UDP traffic is analysed by passing TCP traffic simultane-ously in the network.

Fig. 3.9 presents the results of instantaneous IPTV throughput and delay in pres-ence of TCP traffic. Results show that throughput of 4th IPTV user drops in presence ofTCP connections. To keep TCP stable, number of IPTV streams must be reduced.

Our results from Table-3.8 show that IPTV capacity using UDP decreases by 25%and 24% for HDTV and SDTV users respectively, in the presence of TCP traffic. Thissuggests that IPTV using UDP encounters packet loss in presence of TCP traffic. Ourcapacity results show that IPTV using TFRC provides more users (20 SDTV users) thanIPTV using UDP (13 SDTV users) in presence of TCP traffic. It implies that TFRC cangain significant capacity improvement in presence of TCP traffic.

Bandwidth usage statistics show that throughput of TCP has increased by 6 Mbpsin presence of IPTV using TFRC. Our results show that IPTV capacity using TFRCdecreases by 20% and 13% for HDTV and SDTV users respectively in presence of TCPtraffic. It reveals that the decrease in capacity for IPTV using UDP is always higher thanIPTV using TFRC, in presence of TCP traffic.

Fairness analysis from Fig. 3.10 shows that throughput of TCP remains stable to13 Mbps in presence of 3 HDTV users running on IPTV using UDP. But the additionof 4th user introduces 15.92 Mbps of UDP traffic which increases network congestion.

26

Figure 3.9: HDTV throughput and delay with TCP traffic

Table 3.8: PERFORMANCE STATISTICS FROM IPTV (UDP/DCCP) TRAFFICALONG WITH TCP TRAFFIC

Channel Combined Average Traffic With Without CapacityType Traffic Throughput Bandwidth TCP TCP decrease

Flows (Mbps) Usuage(%) capacity capacity (%)HDTV UDP- UDP:51.2 UDP:84.8 3 4 25

TCP TCP:9.19 TCP:15.2HDTV TFRC- TFRC:67.5 TFRC:81.7 4 5 20

TCP TCP:15.1 TCP:18.28SDTV UDP- UDP:50.4 UDP:85.2 13 17 24

TCP TCP:8.73 TCP:14.8SDTV TFRC- TFRC:77.8 TFRC:83.5 20 23 13

TCP TCP:15.3 TCP:15.4

This behaviour causes TCP to decrease its congestion window size to nearly zero after25 sec and UDP keeps sending IPTV data at an average rate of 51.2 Mbps. On contrary,throughput of TCP is about 15.1 Mbps in presence of IPTV using TFRC and IPTV getsan average data rate of 67.5 Mbps. TCP throughput remains stable to 14 Mbps till last.Obtained results show that use of DCCP for IPTV can provide fair share in bandwidthto TCP.

3.6 Conclusion

In this chapter, we evaluate the capacity of IPTV users for transmission over IEEE802.11n.

27

Figure 3.10: (a) Simultaneous UDP and TCP Traffic - (b) Simultaneous DCCP and TCPTraffic

(a) Our study shows that optimal frame aggregation size is required to maximize ca-pacity of IPTV users. We conclude that 4-times packet size aggregation givesminimum delay with maximum number of users. Any further increase in aggre-gation results in loss of capacity because of an increase in packet’s delay. Wededuce that limited buffer size of queues at AP limit the capacity of IPTV usersby dropping packets in congested situations.

(b) We study the use of DCCP at transport layer of IPTV. Our results verify that DCCP(TFRC) for IPTV can give significant capacity improvement by varying its datarate in congested situations.

(c) Our study shows that TCP-like degrades the capacity of IPTV by 25% with anincrease in packet end-to-end delay.

(d) Fairness analysis also shows that DCCP (TFRC) for IPTV provides better band-width share to TCP. Our study concludes that DCCP (TFRC) can increase capacityfor IPTV users over IEEE 802.11n.

28

Chapter 4Capacity of IPTV and VoIP over IEEE 802.11n

4.1 Introduction

Internet Protocol Television (IPTV) has gained tremendous growth rates in thepast few years. Five times increase in IPTV traffic is expected from 2011 to 2016 [29].Economic, video-on-demand and interactivity are key benefits of IPTV. IPTV transmitsvideo, audio and data simultaneously to end users with satisfactory Quality of Service(QoS) [30]. Aside from IPTV, Voice over Internet Protocol (VoIP) is another fastlygrowing internet application. VoIP users are expected to increase to 928 millions by2016 [29]. The success of VoIP is attributed to cheaper rates, conference calls and lesshardware cost. By 2016, half of the world would be using wireless AP at user end [29].Among wireless standards, IEEE 802.11n is the latest standard providing maximumdata rate with better coverage. Provision of wireless IPTV and VoIP at the user end withgood QoS is a challenging task. Less packet loss, less delay, better QoS, more capacityand the fair allocation of resources to all traffic categories are key challenges for IPTVand VoIP.

Access link provides the major hindrance in providing satisfactory QoS becausepackets drop at the queues of AP and bandwidth at access links is limited. Freedomof mobility, less installation cost and ease of access demands the provision of wire-less IPTV and VoIP. This requires an insight investigation on combined IPTV and VoIPusers having good QoS with wireless access link. Evaluation of capacity is essential fordeployment of real time applications including IPTV and VoIP over wireless networks.Our previous study [31] shows that use of DCCP with optimal frame aggregation sizeover IEEE 802.11n can enhance the capacity of IPTV.

IPTV and VoIP are delay sensitive applications. They use UDP at transport layerwith no congestion control mechanism which causes large packet loss and delay in con-gested situations. In recent past, Datagram Congestion Control Protocol (DCCP) hasemerged as a suitable transport layer protocol in place of UDP for streaming media ap-plications. DCCP provides congestion control mechanism without any retransmissions.DCCP variant TCP Friendly Rate Control (TFRC) provides less reliability but gives aless variation in data rate which makes it suitable for time-sensitive applications. Previ-ous studies [11]-[21] have studied the performance of DCCP and its fairness with TCPtraffic but no evaluation has been made for combined IPTV and VoIP over DCCP tothe best of our knowledge. Our study shows that use of TFRC for IPTV and VoIP cansignificantly increase network capacity by varying its data rate in congested situations.

29

80% of network users use TCP traffic so we also analyze IPTV and VoIP with TCP traf-fic [16]. In presence of UDP, TCP decreases its data rate which results in the starvationof TCP flows [15]. Our fairness analysis shows that TFRC for IPTV and VoIP gives fairshare of bandwidth to TCP traffic than UDP.

IEEE 802.11n standard provides maximum data rates over IEEE 802.11 a/b/g.IEEE 802.11n has enhanced features including frame aggregation, block acknowledge-ment, Transmission Opportunity (TXOP) and Multiple-Input Multiple-Output (MIMO).High data rates of IEEE 802.11n with enhanced features motivate the concept of com-bined IPTV and VoIP over wireless LAN. Our study from Chapter 3 shows that IPTVcan gain significant capacity over IEEE 802.11n. Moreover, results from chapter 3 showthat TFRC is the better suitable protocol for IPTV which not only increases capacity butalso gives fair share in bandwidth to TCP traffic. Results show that optimal aggrega-tion size for IPTV is 4-times packet size which maximizes capacity of IPTV over IEEE802.11n.

Our main contributions in this chapter include,

(a) To evaluate the capacity of combined IPTV and VoIP over IEEE 802.11n

(b) To evaluate the effectiveness of TFRC for IPTV and VoIP over IEEE 802.11n

(c) To determine the capacity of IPTV and VoIP using TFRC in presence of TCP trafficin the network

(d) To study fairness of IPTV and VoIP using TFRC with TCP traffic in the network

4.2 Network Scenario

We use the patch developed in section 3.2.1 for the ns2 simulations. We enter VoIPtraffic in the network along with the IPTV traffic in the system. Both VoIP and IPTVhave been simulated as constant bit rate sources with codec and compression schemesas G.711 and MPEG-2/MPEG-4 respectively.

Simulated architecture is shown in Fig. 4.1 with IPTV and VoIP server on oneside of the internet and access nodes located in vicinity of AP. Access nodes include notonly video streaming sources (television sets) but also the VoIP sources (handsets). VoIPserver handles the bi-directional traffic continuously while majority of IPTV server traf-fic is downstream to user end. Internet cloud in between server and user ends containsthe load of a number of servers. As the links have high bandwidth inside the internetbecause of fibre optics so major bandwidth restricting entity is at the user end at accesslink.

IEEE 802.11n AP has been implemented by use of default MAC and physical

30

layer values from [20] with configurable parameters as shown in Table-4.1. Our pre-vious study from Chapter 3 shows aggregation of 4 packets as optimal size for IPTVtraffic. We will use this aggregation size in all our simulations. Slot time used is 9 µs.We use a SIFS value of 16 µs while DIFS is more than twice the value of SIFS whichcomes to be 34 µs. TXOP limit is 5 which implies that upto 5 packets can be transferredto the user end by the AP. Bit Error Rate (BER) is 10−6. We use a channel bandwidthof 40 MHz with a data rate of 300 Mbps. Currently, 300 Mbps access points are themaximum available data rate access points.

Table 4.1: 802.11n Access Point ParametersParameter Value Parameter Value

DIFS 34 µs SIFS 16 µsSlot time 9 µs Physical Header 20 µs

Contention Window min 15 TXOP limit 5Channel Bandwidth 40 MHz Bit error rate 0.000008

Area 500m×500m No. of nodes 50

Figure 4.1: IPTV Network Scenario

We implement VoIP with the use of popular codec G.711 with a data rate of 64kbps. VoIP packet size is 80 bytes (excluding headers) while packetization interval is10ms.

31

4.3 Capacity of IPTV and VoIP using UDP

We simulate IPTV and VoIP in ns2 by turning on VoIP and IPTV users one-by-one.Both IPTV and VoIP use the default UDP protocol at transport layer. To evaluate thecapacity of IPTV, we take a packet loss of 1% and delay of 200 ms as default thresholdvalues [26]. Packet loss and delay threshold values for VoIP are 2% and 150 ms respec-tively [21][32]. Our objective in all simulations is to evaluate the effect and trends ofVoIP users capacity by increasing IPTV users in the network. We aim to evaluate thecapacity relationship between IPTV users and VoIP users.

Table-4.2 shows the capacity evaluation results for HDTV and VoIP users. Ourresults show that 1 HDTV user and 36 VoIP users can be accommodated with IPTVpacket loss of 0.89% and VoIP packet loss of 1.79%. As we increase the number ofHDTV users, capacity of VoIP decreases by nearly 33%. Hence, 2 HDTV users support24 VoIP users while 3 users can accommodate 11 VoIP users only. Maximum numberof HDTV users appear to be 4 which allow 2 VoIP streams simultaneously. Analysisshows that addition of IPTV users decreases capacity for VoIP users. IPTV requirescomparatively larger bandwidth than VoIP users which disrupts the support for largenumber of VoIP users. Net available bandwidth remains same in the system but dis-tribution of bandwidth changes with the addition of IPTV users. Similarly, capacityof VoIP users decreases with the increase of SDTV users. Maximally, 17 SDTV usersand 3 VoIP streams can be accommodated simultaneously. Our study shows that moreSDTV streams can be accommodated with VoIP than HDTV because SDTV consumesless bandwidth than HDTV.

Table 4.2: Capacity of combined IPTV and VoIPHDTV VoIP HDTV VoIPUsers Users Packet loss Delay(ms) Packet loss Delay(ms)

1 36 0.89% 152 1.79% 1322 24 0.92% 161 1.93% 1253 11 0.87% 170 1.83% 1314 2 0.96% 175 1.9% 141

Histograms from Fig. 4.2 of IPTV versus VoIP users capacity depict the exacttrends in capacity. Results show that increase in IPTV users deteriorates the capacityof VoIP users by limiting the available bandwidth. Maximum IPTV (HDTV) users arelimited to 4 with only 2 VoIP streams simultaneously. Moreover, results show that thedecreasing trend is more steeper at start than at the end. This occurs due to congestionwhich deteriorates capacity worstly in the beginning and number of nodes are limited.These results show that VoIP capacity is significantly degraded in the presence of IPTVusers because of large bandwidth consumption by IPTV users.

32

Figure 4.2: Capacity of IPTV and VoIP

4.4 Capacity of IPTV and VoIP using TFRC

In this section, we evaluate the use of Datagram Congestion Control Protocol(DCCP) at the transport layer of combined IPTV and VoIP. DCCP has two famousvariants namely TCP-like and TFRC [10]. Our previous study [31] shows that TFRCis the better suitable protocol for time sensitive applications like IPTV than TCP-like.TFRC provides less reliability with more timely response and uses no retransmissions.TFRC uses segment size, round trip time and packet loss rate to determine the sendingrate continuously and adjusts itself according to varying congested situations [10].

The aim of our simulations is to study the suitability of TFRC for IPTV and VoIP.To test this, we take three scenarios for simulations. In the first scenario, TFRC basedIPTV runs with UDP based VoIP. In the second scenario, UDP based IPTV runs withTFRC based VoIP. In the third scenario, TFRC based IPTV runs with TFRC based VoIP.Our study would reveal the optimum selection of transport layer protocol for IPTV andVoIP.

4.4.1 IPTV using TFRC and VoIP using UDP

We configure IPTV for using TFRC in place of UDP while VoIP uses UDP. VoIPusers are increased with IPTV users until the delay and packet loss cross the thresh-old values. Table-4.3 shows the IPTV and VoIP capacity trends by varying number ofusers. Our results show that 1 HDTV user can accommodate upto 7 VoIP users. The 8th

VoIP user makes TFRC to decrease its sending rate and delay crosses threshold valuefor HDTV. Similarly, 2 and 3 HDTV users can accommodate 5 and 3 VoIP users re-spectively. 4th HDTV user can run only if there is no VoIP running on UDP. Similarbehavior is seen for SDTV streams where 4 SDTV channels can accommodate 6 VoIP

33

users. Maximally, 17 SDTV users can accommodate no VoIP stream simultaneously.Analysis shows that addition of IPTV users deteriorates systems capacity by increasingqueue congestion at wireless AP. As a result, packets drop from queue of AP and capac-ity of VoIP users is limited. TFRC decreases its data rate which makes delay and packetloss intolerable for IPTV users.

Table 4.3: Capacity of combined IPTV(TFRC) and VoIP(UDP)HDTV VoIP HDTV VoIPUsers Users Packet loss Delay(ms) Packet loss Delay(ms)

1 7 0.92% 171 1.9% 1272 5 0.89% 188 1.85% 1153 3 0.97% 179 1.89% 1354 0 0.76% 165 2.52% 139

Fig. 4.3 shows the trends of IPTV versus VoIP users by plotting histograms. Aswe increase IPTV users then VoIP users decrease due to less available bandwidth. NoVoIP user is supported with 4 IPTV users so we see no histogram with 4 IPTV users.All supported users for IPTV have a packet loss and delay of less than 1% and less than200 ms respectively. Similarly, all supported users for VoIP have a packet loss and delayof less than 2% and less than 150 ms respectively.

Figure 4.3: Capacity of IPTV and VoIP using DCCP and UDP respectively

4.4.2 IPTV using UDP and VoIP using TFRC

In this subsection, we configure our simulations such that VoIP uses TFRC whileIPTV uses UDP. Our results from Table-4.4 show that net capacity deteriorates by usingTFRC for VoIP. 1 and 2 HDTV users can accommodate 8 and 6 VoIP users respectively.Similarly, 3 and 4 HDTV users can arrange 4 and 1 VoIP calls respectively. Similar

34

trends are observed for SDTV streams where 4 SDTV streams can accommodate 6 VoIPstreams. Maximally, 17 SDTV users can arrange no VoIP connection simultaneously.Main reason for less capacity of VoIP is attributed to the use of TFRC. Our results alsoshow that UDP based applications cannot run with fairness with TFRC based applica-tions because of congestion-less mechanism of UDP. UDP connections must be reducedin order to run DCCP connections so as to avoid network congestion.

Table 4.4: Capacity of combined IPTV(UDP) and VoIP(TFRC)HDTV VoIP HDTV VoIPUsers Users Packet loss Delay(ms) Packet loss Delay(ms)

1 8 0.89% 163 1.86% 1232 6 0.95% 174 1.82% 1353 4 0.97% 169 1.91% 1384 1 0.87% 182 1.96% 143

Fig. 4.4 shows the trends of capacity for IPTV users versus VoIP users. Similardecreasing trends in capacity are observed as seen in previous sub-section. Here, we seethat 1 additional VoIP user along with 4 IPTV users are supported by using TFRC forVoIP. As data rate required for IPTV is many times larger than VoIP so use of TFRC forVoIP in presence of UDP based IPTV is more preferred. TFRC does not suit in pres-ence of UDP based applications but gives sufficient performance if used for less datarate applications.

Figure 4.4: Capacity of IPTV and VoIP using UDP and DCCP respectively

4.4.3 IPTV using TFRC and VoIP using TFRC

To test the performance of combined IPTV and VoIP over TFRC, we simulateIPTV and VoIP with TFRC as transport layer protocol. Same setup is simulated by

35

varying number of users of IPTV and VoIP. Results from Table-4.5 show that 1 and2 HDTV users can accommodate 35 and 22 VoIP connections respectively simultane-ously. Maximum 5 HDTV users can accommodate 1 VoIP user simultaneously. Similartrends are seen for SDTV channels where 4 SDTV channels can accommodate 33 VoIPchannels simultaneously. Maximally, 22 SDTV streams can allow 1 VoIP connectionsimultaneously. These results clearly show that TFRC increases capacity of IPTV andVoIP users if both applications use same protocol. Analysis shows that TFRC adjustsits data rate in congested situations. In the absence of UDP based applications, TFRCfits better for IPTV and VoIP by sharing fair bandwidth. Large IPTV packet size is alsoan advantage for IPTV which reduces header overhead and increases capacity of IPTVusers. Our investigation suggests that DCCP is the better suitable protocol for IPTV andVoIP which increases net capacity of IPTV users.

Table 4.5: Capacity of combined IPTV(TFRC) and VoIP(TFRC)HDTV VoIP HDTV VoIPUsers Users Packet loss Delay(ms) Packet loss Delay(ms)

1 35 0.85% 176 1.84% 1252 22 0.82% 181 1.79% 1373 11 0.76 158 1.61% 1444 2 0.8% 164 1.74% 1225 1 0.74% 179 1.7% 139

Fig. 4.5 shows the results of IPTV versus VoIP users plotted in form of histograms.Our results show that capacity has increased by use of TFRC for both IPTV and VoIP.Our results confirm that TFRC based applications work well in the presence of otherTFRC based applications. Net capacity of IPTV users has increased to 5 users and 1VoIP stream can also be supported simultaneously with IPTV streams.

Our simulation results are summarized in Fig. 4.6. Comparison of various sce-narios shows that TFRC is not suitable for IPTV only or VoIP only applications. Useof TFRC for combined IPTV and VoIP can increase net capacity. Histogram curvesfor IPTV and VoIP using TFRC and UDP or vice versa are far less in capacity thanIPTV and VoIP using TFRC for both applications. Based on these findings, we carryout further simulations using only UDP or TFRC for both IPTV and VoIP.

36

Figure 4.5: Capacity of IPTV and VoIP using DCCP

Figure 4.6: IPTV and VoIP over multiple protocols

4.5 Capacity and Fairness of IPTV and VoIP withTCP Traffic

Studies suggest that non-real time traffic is four times greater than the real timetraffic [16]. This motivates us to study TCP traffic along with IPTV and VoIP traffic inthe network. Aim of our simulations is to evaluate the capacity and fairness of combinedIPTV and VoIP traffic along with TCP traffic in the network. TCP traffic is the mostreliable traffic in the network. Congestion control mechanisms of TCP make their besteffort to avoid congestion in the network. There is no data lost by using TCP but theonly trade-off is the delay encountered for the TCP traffic. TCP is used for best efforttraffic so delay is not considered for TCP traffic but throughput is important. Our resultsfrom section-4.4 show that TFRC for combined IPTV and VoIP gives better capacity.

37

We analyze TCP traffic with IPTV and VoIP traffic running UDP as transport layer pro-tocol. Moreover, we also study TCP traffic running along-with IPTV and VoIP usingTFRC.

We have implemented File Transfer Protocol (FTP) at application layer which usesTCP at transport layer. We use a packet size of 1000 bytes for simulations. Multi-ple connections (4) of TCP are established because multiple connections decrease theircontention window sizes less abruptly than a single connection [35].

4.5.1 IPTV and VoIP using UDP

Our simulation results for IPTV and VoIP using UDP from Fig. 4.7(a) show that 1HDTV user can accommodate 27 VoIP connections simultaneously. Similarly, 2 and 3HDTV streams can accommodate 16 and 7 VoIP connections respectively. Throughputof TCP drops to nearly 0 in the presence of 4 HDTV streams. Fig. 4.7(b) shows similartrends for SDTV streams with a maximum capacity of 16 SDTV and 1 VoIP user. Aswe increase the SDTV users then capacity of VoIP users drops. Our results show thatVoIP capacity is significantly degraded in presence of TCP flows. Analysis shows thatTCP goes to starvation in the presence of UDP flows which results in reduction of TCPcongestion window size to nearly zero. This shows that due to constant bit rate mech-anism of UDP, TCP decreases its congestion window size. To give TCP a reasonablethroughput, UDP connections must be reduced. Hence IPTV and VoIP users capacity issignificantly degraded in presence of TCP flows.

(a) Using HDTV (b) Using SDTV

Figure 4.7: Capacity of IPTV and VoIP with TCP traffic

38

Table 4.6: PERFORMANCE STATISTICS FOR COMBINED IPTV AND VoIPALONG WITH TCP TRAFFIC

IPTV Combined Average Traffic VoIP VoIP CapacityTraffic Throughput Bandwidth capacity capacity decreaseFlows (Mbps) Usuage(%) with without (%)

TCP TCPHDTV UDP- UDP: 50.7 UDP: 88.2 27 36 25%

TCP TCP: 6.8 TCP: 11.8HDTV TFRC- TFRC: 66.5 TFRC: 82.4 33 35 6%

TCP TCP: 14.2 TCP: 17.6SDTV UDP- UDP: 51.3 UDP: 89.4 29 37 22%

TCP TCP: 6.1 TCP: 10.6SDTV TFRC- TFRC: 64.7 TFRC: 81.7 39 41 5%

TCP TCP: 14.4 TCP: 18.3

4.5.2 IPTV and VoIP using TFRC

We configure IPTV and VoIP using TFRC in an environment already running TCPtraffic. Fig. 4.7(a) shows the results of capacity of IPTV versus VoIP users. Our resultsshow that capacity gained by IPTV and VoIP users is much better by using TFRC thanUDP. 1 and 2 HDTV users can accommodate 33 and 21 VoIP users respectively. Sim-ilarly, 3 and 4 HDTV users can arrange 10 and 1 VoIP user respectively. Fig. 4.7(b)shows similar trends for SDTV streams with a maximum capacity of 16 SDTV and1 VoIP user. SDTV users exhibit more better bandwidth sharing trends because theyconsume less bandwidth and this can result in better utilization of available bandwidth.Analysis shows that congestion control mechanisms of TCP and TFRC adjust them-selves according to the dynamic conditions of the network. This results in better band-width share between TCP and TFRC than TCP and UDP. Results show that VoIP ca-pacity has increased with the use of TFRC than UDP.

Table-4.6 presents the throughput results for IPTV and VoIP using UDP andTFRC with TCP traffic. Results show that TFRC for IPTV decreases VoIP capacityby 6% only while UDP for IPTV decreases VoIP capacity by 25% with TCP traf-fic. Throughput results show that TCP gets 14.2 Mbps in presence of TFRC while6.8 Mbps in presence of UDP. Bandwidth consumption results show that HDTV (UDP)gets 88.2% of bandwidth while TCP gets 11.8% share in bandwidth in presence of UDP.By using TFRC, HDTV (TFRC) gets 82.4% of the bandwidth while TCP gets 17.6%of the bandwidth in presence of TFRC. Basically, TFRC does not increase the availablebandwidth. TFRC increases the efficient utilization of the bandwidth which not onlyincreases network capacity but also gives fair share in bandwidth to TCP.

39

SDTV exhibits similar trends to HDTV. TCP gets a throughput of 6.1 Mbps inpresence of SDTV using UDP. TFRC for SDTV enables TCP to get a throughput of14.4 Mbps. Net traffic bandwidth usage is 89.4% by UDP and 10.6% by TCP in pres-ence of SDTV (UDP) with TCP traffic. By using TFRC, bandwidth consumption byTFRC becomes 81.7% while bandwidth consumed by TCP is 19.3%. This shows thatTFRC enables TCP to get more share in bandwidth than the share in presence of UDP.These results show that TFRC is much more fairer to TCP traffic than UDP.

Comparison of UDP and TFRC shows that UDP not only gives less capacity butalso provides unfair share in bandwidth to TCP. On contrary, TFRC gives more capacitywith better fair share in bandwidth to TCP traffic. Results show that congestion con-trol protocols work better in presence of other congestion control protocols instead ofcongestion less protocols.

4.6 Conclusion

In this chapter, we evaluate the capacity of combined IPTV and VoIP users overIEEE 802.11n.

(a) Our results show that increase in IPTV users decreases the capacity of VoIP usersby 33%.

(b) Our evaluations show that use of TFRC at transport layer of combined IPTV andVoIP can increase network capacity of IPTV users by 25%.

(c) Results confirm that use of TFRC for IPTV or VoIP in presence of UDP basedapplications can severely deteriorate the performance of IPTV and VoIP.

(d) Fairness analysis of combined IPTV and VoIP in presence of TCP flows shows thatTFRC for IPTV and VoIP gives much more fair share in bandwidth to TCP trafficthan UDP.

40

Chapter 5Tuning IEEE 802.11n Access Point parameters

5.1 Introduction

IEEE 802.11n standard provides maximum data rates over IEEE 802.11 a/b/g.IEEE 802.11n has enhanced features including frame aggregation, block acknowledge-ment, Transmission Opportunity (TXOP) and Multiple-Input Multiple-Output (MIMO).Our study shows that optimal parameter selection of queue size, TXOP and aggregationsize can significantly enhance capacity of IPTV and VoIP over IEEE 802.11n. Our anal-ysis deals with the optimal values and trends of SIFS, DIFS, contention window size andphysical header for IPTV and VoIP over IEEE 802.11n.

Capacity and QoS can be significantly enhanced by selection of optimal param-eters. In chapter 3 and 4, we have studied the capacity of IPTV and VoIP over IEEE802.11n. We have shown that use of DCCP for IPTV and VoIP can not only increase netcapacity but it can also provide fair share in bandwidth to TCP traffic. In this chapter,we study the parameters of IEEE 802.11n AP for optimal performance. We use UDPat the transport layer of IPTV and VoIP for simulations. In last subsection, we wouldevaluate capacity with the use of DCCP along with optimal parameters of IEEE 802.11nand compare it with UDP for IPTV and VoIP.

Queues of various sizes are used for IEEE 802.11n AP by different vendors. Queuesize depends upon the functionality of AP. We would focus on the queue size for datatransmission of IPTV and VoIP with maximum capacity.

TXOP at AP gives more time for data transfer to AP. AP has the load of all thepackets. Use of TXOP can reduce the collisions overhead for the AP and hence in-crease the net throughput.

IEEE 802.11n has been equipped with frame aggregation. Multiple frames arecombined at MAC layer and physical layer. This results in reduction of header over-head by MAC layer and physical layer. Standard specifies aggregation of MAC layerframes as MAC Service Data Unit (MSDU). Combining multiple frames at physicallayer is referred as MAC Protocol Data Unit (MPDU). A group of MSDUs or MPDUsis referred to as A-MSDU or A-MPDU.

Block acknowledgement is a capacity enhancement mechanism. By using blockacknowledgement, acknowledgments of individual MPDUs can be sent. This reducesthe overhead of transmitting correctly received MPDUs. However, no individual ac-knowledgements are sent for MSDUs.

Parameters like SIFS, DIFS, physical header and contention window are used by

41

all WLANs for accessing the medium. Our focus would be to obtain the optimal valueswhich can provide maximum capacity for SIFS, DIFS, physical header and contentionwindow.

Our main focus in this chapter is to study the effect of various parameters of IEEE802.11n over the capacity of IPTV and VoIP. We study the effect of following parame-ters:a) Effect of Queue Sizeb) Effect of Transmission Opportunity (TXOP)c) Effect of Aggregation and Block Acknowledgementd) Effect of SIFSe) Effect of DIFSf) Effect of Contention Windowg) Effect of Physical Header

5.1.1 Effect of Queue Size

IEEE 802.11n AP uses queues to store data at AP before transmission to end user.Various queue sizes are used by different vendors. Capacity is significantly degradedif packets drop at queues of AP. We simulate IPTV and VoIP for maximum capacityby varying queue size. Our motivation is to find the optimal queue size for combinedIPTV and VoIP over IEEE 802.11n. We vary the queue size from 5 to 500 packets andinvestigate the capacity of IPTV and VoIP.

Results of queue size trends from Fig. 5.1 show that maximum capacity is reachedat a queue size of 70 packets. System capacity increases sharply initially by increasingqueue size because larger queue size avoids packet loss at AP. There is a little increasein capacity from 50 to 70 packets because delay increases with large queue values.Above 70 packets, system’s capacity remains constant to 4 IPTV users and 2 VoIP usersbecause capacity to transfer packets to end users is the bottleneck. At a queue size of5 packets, only 1 IPTV and 2 VoIP users are supported. Increase in queue size to 10packets increases the capacity to 2 IPTV and 1 VoIP user. At 30 packets of queue size,we get a capacity of 3 IPTV and 1 VoIP user. 4 IPTV users along with 1 VoIP user issupported at a queue size of 50 packets. At a queue size of 70 packets, 2 VoIP userswith 4 IPTV users are supported. Further increase in queue size has no effect on usersbecause capacity to end user is the bottleneck. Our study shows that any increase inqueue size above 70 packets is redundant. Optimal queue size for combined IPTV andVoIP over IEEE 802.11n is 70 packets.

42

Figure 5.1: IPTV and VoIP Capacity versus Queue size

5.1.2 Effect of Transmission Opportunity (TXOP)

TXOP for AP can provide contention free access to AP for a time equal to TXOPtime limit. AP has the load of all users packets so TXOP gives it more time for transmis-sion. We vary TXOP in varying ranges of values to investigate IPTV and VoIP capacity.

Fig. 5.2 presents the results for IPTV and VoIP capacity versus TXOP of AP. Re-sults show that capacity of IPTV becomes constant after TXOP of 5. Further increasein TXOP increases capacity by small margins which can translate to VoIP users only.TXOP of 9 is the maximum value which can accommodate 12 VoIP users with 4 IPTVstreams simultaneously. Analysis shows that increase of TXOP allows the AP to sendmore packets with less collisions. After TXOP of 9, the bottleneck link transfers fromAP to user ends. TXOP of 10 gives less time to users for packet transmission which re-sults in a constant capacity curve after TXOP of 9. At TXOP of 1, 1 IPTV and 13 VoIPusers are supported. With increase in TXOP, capacity of IPTV and VoIP users increasessuch that 3 IPTV and 7 VoIP users are supported at TXOP of 3. TXOP of 5 gives 4IPTV with 2 VoIP streams. TXOP of 7 gives 4 IPTV with 9 VoIP streams. Capacitybecomes constant to 4 IPTV and 12 VoIP users by using TXOP of 9. TXOP of 10 and11 give same capacity as TXOP of 9. VoIP trends are abrupt in Fig. 5.2 because anyincrease in throughput with TXOP accommodates the IPTV users first before arrangingmaximum number of VoIP users. Optimal TXOP value for combined IPTV and VoIPover IEEE 802.11n is 9.

5.1.3 Effect of Aggregation and Block Acknowledgement(ACK)

IEEE 802.11n has been equipped with aggregation and Block ACK mechanism.Aggregation combines multiple frames at AP queues so that the overhead of transmis-sion is reduced. Multiple MSDUs and MPDUs are combined at MAC layer and physi-

43

Figure 5.2: IPTV and VoIP Capacity versus Transmission Opportunity

cal layer level. Acknowledgements of individual MPDUs can be sent using block ACK.This feature results in selective retransmission of MPDUs. To test the performance ofaggregation and block ACK, we simulate two scenarios of IPTV and VoIP. The firstscenario with low bit error rate while second scenario with high bit error rate. We usedtwo scenarios because block ACK performance can be evaluated only by changing BERfrom low to high value.

Block ACK in Low Bit Error Rate

We evaluate IPTV and VoIP users capacity using block ACK in low bit error rate of10−6. Fig. 5.3(a) shows the results for IPTV and VoIP capacity without using blockACK. Results show that maximum capacity is reached at an aggregation of 4 packets.Without aggregation, 1 IPTV and 5 VoIP users are supported. At an aggregation of 2packets, 2 IPTV and 6 VoIP users are supported. Maximally, 4 IPTV users can accom-modate 2 VoIP users simultaneously.

Results of IPTV and VoIP capacity using block ACK are shown in Fig. 5.3(b).Results show that Block ACK deteriorates capacity in low bit error rates. Without ag-gregation, 1 IPTV and 2 VoIP users are supported. At an aggregation of 2 packets, 2IPTV and 3 VoIP users are supported. Maximally, 3 IPTV users can accommodate 10VoIP users simultaneously. Analysis shows that block ACK sends acknowledgementsof individual MPDUs. In case of low bit error rate, corrupted packets are few in numberso block ACK is not suitable. Time for block ACK can be utilized for data packets inlow bit error rates. Hence, block ACK is not suitable for low BER.

Block ACK in High Bit Error Rate

We evaluate Block ACK performance by increasing bit error rate to 10−5. Resultsof IPTV and VoIP without block ACK in high bit error rate are shown in Fig. 5.4(a). Re-

44

(a) Without Block ACK (b) Using Block ACK

Figure 5.3: Capacity of IPTV and VoIP in Low BER

sults show that maximum capacity of IPTV and VoIP users is degraded in comparison tolow bit error rate results. Without aggregation, 1 IPTV and 1 VoIP users are supported.At an aggregation of 2 packets, 1 IPTV and 8 VoIP users are supported. Maximally, 3IPTV streams can accommodate 9 VoIP connections simultaneously.

Same simulations are repeated by using block ACK in high bit error rate as shownin Fig. 5.4(b). Without aggregation, 1 IPTV and 7 VoIP users are supported. At anaggregation of 2 packets, 2 IPTV and 8 VoIP users are supported. Block ACK in highbit error rates provides 4 IPTV users with 3 VoIP users. Results show that block ACKincreases capacity of IPTV and VoIP users. This trend occurs because only corruptedMPDUs have to be retransmitted instead of re-transmitting the whole packet contain-ing multiple MPDUs. Trends of VoIP in Fig. 5.4 show variation because aggregationincreases throughput. Increase in throughput is translated to a maximum number ofIPTV users. Only left over throughput is available for VoIP. Hence VoIP shows varyingtrends. Block ACK results show that block ACK is suitable only in high bit error rate.Aggregation results show that aggregation of 4 packets is the optimal size for combinedIPTV and VoIP over IEEE 802.11n.

(a) Without Block ACK (b) Using Block ACK

Figure 5.4: Capacity of IPTV and VoIP in High BER

45

5.1.4 Effect of Short Interframe Spacing (SIFS)

SIFS duration is the idle time in the network immediately after transmission ofRTS or data. We take a default SIFS value (16 µs) as a reference and modify defaultvalue in ratio to get the trends in capacity for SIFS. Our objective is to estimate theminimum change in SIFS which can increase network capacity.

Fig. 5.5 shows the IPTV and VoIP capacity trends for SIFS. Our results show thatSIFS ratio of 1 gives a capacity of 4 IPTV users with 2 VoIP users. SIFS ratio of 0.9gives 4 IPTV users with 3 VoIP users. This shows that 10% decrease in SIFS valueincreases 1 VoIP user. SIFS value of 0 gives 4 IPTV with 14 VoIP users. SIFS trendsshow that capacity of IPTV decreases to 3 users with 15 VoIP users at a ratio of 1.1.This occurs because increase in SIFS increases idleness in the network which decreasesthe time for data transfer. Analysis shows that any decrease in SIFS value reduces theoverhead by converting reduced time to data transfer time. Our study shows that optimalSIFS ratio is 0.9 which appears to be 14.4 µs.

Figure 5.5: IPTV and VoIP Capacity versus SIFS

5.1.5 Effect of Distributed Interframe Spacing (DIFS)

We simulate IPTV and VoIP by varying DIFS duration in the medium. DIFS du-ration is waited by all stations before going to back off mechanism for transmission ofdata. Default DIFS value is 34 µs which is varied from 0 times to 2 times of originalvalue.

Fig. 5.6 shows the IPTV and VoIP capacity trends for DIFS duration. Our resultsshow that 4 IPTV with 2 VoIP users can be accommodated at a DIFS ratio of 1. DIFSratio of 0.9 gives 4 IPTV users with 3 VoIP users. This shows that 10% decrease in DIFSduration increases nearly 1 VoIP user. Maximum capacity of IPTV and VoIP users is

46

obtained at a DIFS value of 0 with 4 IPTV and 16 VoIP users. Analysis shows that de-crease in DIFS duration allows the communicating nodes to transmit immediately aftertransmission with less waiting time. These results are valid only if DIFS is equal totwice of SIFS duration plus the propagation time as shown in below equation. Decreasein DIFS duration without changing SIFS results in a collision of packets between nodeswhich decreases capacity. Our study shows that decrease in DIFS duration increasesIPTV and VoIP capacity. Optimal DIFS ratio is 0.9 which gives 30.6 µs DIFS value.

DIFS = 2×SIFS + 2×Propagation Time

Figure 5.6: IPTV and VoIP Capacity versus DIFS

5.1.6 Effect of Physical Header (PH)

We vary the time duration of PH transmission. IEEE 802.11n transmits the headersat low data rates which significantly increases the transmission time. We would vary thetime duration of physical header transmission time. Our aim is to estimate the effect ofPH duration on the IPTV and VoIP capacity. Default PH value of 20 µs is varied in ratioof original value.

Results of IPTV and VoIP capacity versus physical header duration are shown inFig. 5.7. Results show that PH ratio of 1 can support 4 IPTV streams with 2 VoIPstreams. With a PH ratio of 0.9, 4 IPTV streams can be supported with 3 VoIP streams.Trend of PH is similar to SIFS and DIFS. Major trend difference occurs at a ratio of 1.5.Capacity of IPTV streams reduces to 2 users with 16 VoIP streams. Maximum capacityis obtained at a PH ratio of 0 which gives 4 IPTV and 16 VoIP streams simultaneously.This shows that increase in PH adversely effects capacity than increase in SIFS or DIFS.Analysis shows that decrease in PH duration allows the nodes to send more data. Ourresults suggest that PH ratio of 0.9 is a reasonable ratio size with a value of 18 µs.

47

Figure 5.7: IPTV and VoIP Capacity versus Physical Header

5.1.7 Effect of Contention Window (CW)

IEEE 802.11n AP uses back-off mechanism with a default minimum CW size of15. We aim to estimate the optimal CW size because excessive CW size can result inredundant delays. CW less than optimal value results in repeated collisions betweenpackets. We take CW of 15 as a reference and vary CW in ratio of original value.

Fig. 5.8 shows our results of IPTV and VoIP capacity by varying CW size. Re-sults show that optimal capacity is obtained at a ratio of 0.7. This shows that CW of11 (0.7×15) is the optimal size. Decrease in CW size from 15 decreases the redun-dant waiting times of nodes till CW size of 11 is reached. CW size below 11 decreasesperformance because probability of selecting same window size by multiple nodes in-creases. This increases collisions and results in redundant delays. Results also showthat no IPTV user is supported at a ratio of 0.2 or less than 0.2×CW. This suggests thatlower CW size is the worst factor affecting IPTV and VoIP capacity. At lower CW size,probability of selecting same CW size by multiple nodes increases which results in ex-cessive collisions between the packets. This also shows that collisions in IEEE 802.11nAP effect system’s performance by decrease in capacity of combined IPTV and VoIP.

5.1.8 Discussion

Our study presents the optimal parameters for IEEE 802.11n using UDP at trans-port layer of IPTV and VoIP. Results from above sections show that optimal values ofqueue size, TXOP, aggregation, SIFS, DIFS, CW and PH can enhance capacity of IPTVand VoIP users. But all parameters have been evaluated using UDP at transport layerof both IPTV and VoIP. Use of other protocols at transport layer protocols pose certainquestions on the optimal values of IEEE 802.11n parameters.

OSI layer model and TCP/IP models have been configured by keeping layers in-dependent from each other. Each layer serves certain functionalities by use of certain

48

Figure 5.8: IPTV and VoIP Capacity versus Contention Window

protocols at every layer. Layers don’t know the protocols of above layers. This suggeststhat different protocols can be used at transport layer without reconfiguring MAC andphysical layer protocols.

Chapter 4 shows that TFRC is the better suitable protocol for combined IPTV andVoIP. Since layers are independent, so optimal parameters do not change by use ofTFRC at transport layer of IPTV and VoIP. TFRC changes net capacity of IPTV andVoIP by use of congestion control mechanisms. TFRC adjusts its data rate according tothe dynamic conditions of the network.

Results of both IPTV and VoIP over TFRC with optimized AP parameters fromFig. 5.9(a) show that maximally 5 IPTV and 10 VoIP flows can be accommodated.With 1 IPTV stream, 43 VoIP users can be accommodated simultaneously. Our simu-lations show that TFRC and optimal parameters of IEEE 802.11n can increase capacityby at least 23% for VoIP users as compared to TFRC with non-optimized parameters.

Results from Fig. 5.9(b) present the comparison of UDP with optimized and non-

(a) With TFRC (b) With UDP

Figure 5.9: Capacity of combined IPTV and VoIP

49

optimized parameters over IEEE 802.11n. Results show that 1 IPTV and 44 VoIP userscan be accommodated by using optimized parameters. Maximally, 4 IPTV and 15 VoIPusers can be accommodated. Our results show that there is at least 22% increase in VoIPusers with the use of optimized IEEE 802.11n parameters as compared to non-optimizedparameters over UDP.

Table-5.1 presents the comparison of the optimal parameters obtained in this sec-tion and default parameters of IEEE 802.11n [34] for combined IPTV and VoIP.

Table 5.1: Parameters for IEEE 802.11nParameters Default Parameters [34] Proposed ParametersQueue Size 50 pkts 70 pkts

TXOP 5 9SIFS 16µs 14.4µsDIFS 34µs 30.6µs

Physical Header 20µs 18µsContention Window 15 11

5.2 Conclusion

Our study evaluates optimal parameters for IEEE 802.11n parameters.

(a) We show that queue size and transmission opportunity have optimal values of 70and 9 respectively.

(b) Performance of block ACK is enhanced only in the presence of high bit error rate.

(c) We show that the selection of 14.4µs, 30.6µs and 18µs for SIFS, DIFS and physicalheader respectively enhance the combined IPTV and VoIP capacity. We show thatdecrease in SIFS, DIFS and physical header duration increases capacity of IPTVusers.

(d) Contention window works best only at optimal point of 11 beyond which collisionsor delays increase.

(e) We conclude that use of optimal parameters for IEEE 802.11n can increase capacityof IPTV and VoIP users by atleast 19% in comparison to non-optimized parame-ters of IEEE 802.11n.

50

Chapter 6Conclusion

6.1 Summary

Transmission of IPTV and VoIP services over a wireless network is a challengingtask. Low data rates and poor QoS of WLANs were the major restricting factors fortransmission of IPTV and VoIP services to the user end. High data rates with betterprovisioning of QoS of IEEE 802.11n standard motivate the concept of wireless IPTVand VoIP at the user end.

In this thesis, analysis on the capacity evaluation of IPTV and VoIP to the userend using IEEE 802.11n has been presented. We evaluate the capacity of IPTV usersfor transmission over IEEE 802.11n. Our study shows that optimal frame aggregationsize is required to maximize capacity of IPTV users. We conclude that 4-times packetsize aggregation gives minimum delay with maximum number of users. Any furtherincrease in aggregation results in loss of capacity because of an increase in packet’sdelay. We deduce that limited buffer size of queues at AP limit the capacity of IPTVusers by dropping packets in congested situations.

We study the use of DCCP at transport layer of IPTV. Our study shows that TCP-like degrades capacity of IPTV due to large delays encountered by packets. Our resultsverify that TFRC for IPTV can give upto 25% capacity improvement by varying its datarate in congested situations. Fairness analysis also shows that DCCP for IPTV providesbetter bandwidth share to TCP with less variation in data rate. Our study concludes thatDCCP(TFRC) can increase capacity for IPTV users over IEEE 802.11n.

We evaluate the capacity of combined IPTV and VoIP users over IEEE 802.11n.Our study shows that increase in IPTV users decreases capacity of VoIP users by 33%.Our evaluations show that use of TFRC at transport layer of combined IPTV and VoIPcan increase capacity of IPTV users by 25%. Results show that use of TFRC for IPTVor VoIP in presence of UDP based applications can severely deteriorate the performanceof IPTV and VoIP. Fairness analysis of combined IPTV and VoIP in presence of TCPtraffic shows that TFRC for IPTV and VoIP gives much more fair share in bandwidth toTCP traffic than UDP.

Our study also evaluates optimal parameters for IEEE 802.11n including queuesize and TXOP. Our study shows that nearly 9 more VoIP users are supported with aqueue size of 70 packets and transmission opportunity of 9. Moreover, performance ofblock ACK is enhanced only in the presence of high bit error rate. We show that theselection of 14.4µs, 30.6µs and 18µs for SIFS, DIFS and physical header respectively

51

enhance the combined IPTV and VoIP capacity. Contention window works best onlyat optimal point of 11. We conclude that use of TFRC with optimal parameters forIEEE 802.11n can increase capacity of IPTV and VoIP users by at least 25% and 19%respectively in comparison to UDP with non-optimized parameters.

6.2 Future Work

In future, the proposed suggestions can be used for performance evaluation in awireless mesh network. Effectiveness of various IEEE 802.11n parameters may be seenin an environment having multiple access points in vicinity of each other. Handoff delaywould deteriorate the performance of IPTV and VoIP in such an environment. Analysiscan be made more concrete by taking mobility effects into account. Performance is ex-pected to degrade in presence of mobility due to continuously varying SNR levels.

Based on our findings on DCCP, future research can be carried out for developmentof a new transport layer protocol which suits better for IPTV using multicast transmis-sion. Currently, TFRC and TCP-like use unicast mechanism. Capacity of IPTV userscan be enhanced by using multicast mechanism for various channels to end users. Ac-cording to Huff’s law, probability of watching a channel ’x’ is x-times less than the firstchannel where channels are arranged in decreasing order of their probabilities. Thissuggests that probability of watching popular channels is many times more than leats-popular channels. By using multicast mechanism, capacity can be further improved bysupplying same channel stream to multiple users. Transmission Flow Multicast Con-gestion Control Protocol (TFMCC) is a protocol designed for multicast mechanisms inwired scenarios. In wireless environment, its performance is expected to deterioratebecause different users are susceptible to varying SNR levels. So, a scheme should bedeveloped which could cope fairly to all nodes in the wireless environment. An ns2simulation patch for the proposed protcol should be developed which could be an ever-lasting contribution to the ns2 community.

52

Bibliography

[1] Recommendation ITU-T Y.1901, “Requirements for the support of IPTV ser-vices”, ITU Standardization Sector, Approved: 01/2009.

[2] Cisco White Paper, “Cisco Visual Networking Index: Forecast and Methodology,2011-2016”, published on May 30, 2012.

[3] W. Geng, W. Lenan and W. Deguo, “The Technical Framework of End-to-EndVideo Transmission System for the IPTV”, in Information Management and Engi-neering (ICIME), pp. 464 - 467, April 2010.

[4] M. Garcia, J. Lloret, M. Edo and R. Lacuesta, “IPTV distribution network accesssystem using WiMAX and WLAN technologies”, In Proc. of Use of P2P, GRIDand agents for the development of content networks (UPGRADE-CN), Germany,June 2009.

[5] C. Yang and H. Wei, “IEEE 802.11n MAC Enhancement and Performance Eval-uation”, in Journal Mobile Networks and Applications, pp. 760 - 771, volume 14,issue 6, December 2009.

[6] Abraham, A. Meylan and S. Nanda, “802.11n MAC design and system perfor-mance”, in IEEE International Conference on Communications (ICC), pp. 2957 -2961, May 2005.

[7] B. Ginzburg and A. Kesselman, “Performance analysis of A-MPDU and A-MSDUaggregation in IEEE 802.11n”, in IEEE Sarnoff Symposium, April-May 2007.

[8] T. Selvam and S. Srikanth, “Performance study of IEEE 802.11n WLANs”, inproc. of the First international conference on COMmunication Systems And NET-works (COMSNETS’09), pp. 637-642, 2009.

[9] M. Atenas, S. Sendra, M. Garcia and J. Lloret, “IPTV Performance in IEEE 802.11n WLANs”, in IEEE Global Telecommunications Workshop (GLOBECOM), pp.929-933, Miami, December 2010.

[10] E. Kohler, M. Handley, and S. Floyd, “Datagram Congestion Control Protocol(DCCP)”, RFC 4340, March 2006.

53

[11] L. M. de Sales, H. O. Almeida, and A. Perkusich, “On the Performance of TCP,UDP and DCCP over 802.11 g Networks”, in proceedings of ACM Symposium onApplied Computing, New York, USA, 2008.

[12] L.M. Sales, H.O. Almeida, A. Perkusich, M. Sales, “An Experimental Evaluationof DCCP Transport Protocol: A Focus on the Fairness and Hand-Off over 802.11gNetworks”, in proceedings of Consumer Communications and Networking Con-ference (CCNC), Las Vegas, NV, January 2008.

[13] S.A. Nor, S. Hassan, O. Ghazali, A.S.M. Arif, “On the Performance of TCP Pac-ing with DCCP”, in Network Applications Protocols and Services (NETAPPS),Kedah, September 2010.

[14] S. Safaripour Khanloo, M. Soryani, M. Fathy, “AIMD-TCP-Friendly Rate ControlOver Wireless Networks”, in proceedings of Wireless Communications, Network-ing and Mobile Computing (WiCOM), Dalian, October 2008.

[15] H. K. Rath and A. Karandikar,”Performance Analysis of TCP and UDP-based Ap-plications in a IEEE 802.16 deployed Network”, Wireless Personal MultimediaCommunications (WPMC), France, October 2011.

[16] M. Fomenkov, K. Keys, D. Moore and K. Claffy, “Longitudinal Study of InternetTraffic from 1998 to 2003”, in Proceedings of the Winter International Symposiumon Information and Communication Technologies, ACM Press, New York, USA,January 2004.

[17] Y. Xiao, X. Du, J. Zhang, F. Hu and S. Guizani, “Internet Protocol Television(IPTV):The Killer Application for the Next-Generation Internet”, IEEE Commu-nications Magazine, Vol. 45, Issue 11, November 2007.

[18] T. Guo, C. H. Foh, J. Cai, D. Niyati and E. W. M. Wong, “Performance Evaluationof IPTV Over Wireless Home Networks”,IEEE transactions on multimedia, vol.13, no. 5, October 2011.

[19] M. Gidlund and J. Ekling, “VoIP and IPTV Distribution over Wireless MeshNetworks in Indoor Environment”, IEEE Transactions on Consumer Electronics,November 2008.

[20] E. Shihab, F. Wan, L. Cai, A. Gulliver and N. Tin, “Performance analysis ofIPTV traffic in home networks”, IEEE Global Telecommunications Conference(GLOBECOM), pp. 5341-5345, Washington, DC, November 2007.

54

[21] I. Ullah, Z. Shah, M. Owais and A. Baig, “VoIP and Tracking Capacity over WiFiNetworks”, in 73rd IEEE Vehicular Technology Conference (VTC Spring), Hun-gary, May 2011.

[22] Motorola inc, ”The Future of Video”, available athttp://www.motorola.com/Video-Solutions/US-EN/Home

[23] The Network Simulator - NS-2, http://www.isi.edu/nsnam/ns.

[24] S. Linck, DCCP Module for ns-2, open-source available at http://lifc.univ-fcomte.fr/ dedu/ns2.

[25] ETSI Standard, ”Digital Video Broadcasting (DVB); Framing structure, chan-nel coding and modulation for digital terrestrial television”, Available athttp://pda.etsi.org.

[26] Agilent technologies, ”IPTV QoE: Understanding and interpreting MDI values”,white paper, 2008.

[27] B. Dekeris and L. Narbutaite, “IPTV Channel Zap Time Analysis”, in Proceedingsof International Conference on Ubiquitous and Future Networks, China, 2009.

[28] W. Sun, K. Lin and Y. Guan, “Performance analysis of a finite duration multichan-nel delivery method in IPTV”, IEEE Transactions on Broadcasting, pp. 419-429,2008.

[29] Cisco, ”Cisco Visual Networking Index Forecast 2011-2016”, available athttp://goo.gl/hSJjX

[30] Recommendation ITU-T Y.1901, “Requirements for the support of IPTV ser-vices”, ITU Standardization Sector, Approved: 01/2009.

[31] S. Saleh, Z. Shah, A. Baig, “IPTV Capacity Analysis using DCCP over IEEE802.11n”, Accepted in 78th IEEE Vehicular Technology Conference (VTC Fall),USA, 2013. Available at http://goo.gl/hPTm2

[32] S. Garg and M. Kappes, ”Can I add a VoIP call?”, in IEEE International Confer-ence on Communications (ICC), Alaska, USA, May 2003.

[33] S. Shin and H. Schulzrinne, ”Experimental Measurement of the Capacity for VoIPTraffic in IEEE 802.11 WLANs”, in 26th IEEE International Conference on Com-puter Communications (INFOCOM), Alaska, USA, May 2007.

55

[34] IEEE 802.11n,“IEEE Standard for Information Technology Telecommunicationsand information exchange between systems Local and metropolitan area networksSpecific requirements. Part 11: Wireless LAN Medium Access Control (MAC) andPhysical Layer (PHY) specifications.”, Oct 2009.

[35] T. Nguyen and S.S. Cheung, “Multimedia streaming using multiple TCP connec-tions”, in 24th IEEE International Performance, Computing, and CommunicationsConference (IPCCC), Phoenix, Arizona, April 2005.

[36] F. D. Conceicao, D. A. Florencio and F. Kon, “Is IEEE 802.11 ready for VoIP”,May 2008.

[37] S. Kakumanu, C. Tsao, R. Sivakumar,”Improving VoIP Call Capacity over IEEE802.11 Networks”, In Proc. of Broadband communications, Networks and Systems(BROADNETS), Raleigh, USA, September 2007.

[38] Grainne Hanley, “A Study of the Performance of Voice over IP over IEEE 802.11Wireless Local Area Networks”, Masters Thesis, University College Dublin, Ire-land, July 2005.

[39] N. Hajlaoui, I. Jabri,”On the performance of IEEE 802.11n protocol”, In Procof Wireless and Mobile Networking Conference (WMNC), Bratislava, Slovakia,September 2012.

[40] Y. Daldoul, T. Ahmed, D. E. Meddour,”IEEE 802.11n aggregation performancestudy for the multicast”, In Proc of Wireless Days (WD), October 2011

[41] IEEE Standard for Information technology - 802.11n-2009, Available athttp://standards.ieee.org/findstds/standard/802.11n-2009.html.

[42] D. Le Gall, MPEG: a video compression standard for multimedia applicationsACM Comm., vol.34, n.4, pp. 46-58, April 1991.

56

capacity analysis of iptv over ieee 802.11n

Documents