Scalable Wireless Communications To Enrich Live Concerts in Large Halls

FACULDADE DE E NGENHARIA DA U NIVERSIDADE DO P ORTO
Scalable Wireless Communications to

Enrich Live Concerts in Large Halls
Carlos Manuel Sanches Leocádio
MS C D ISSERTATION
M ESTRADO I NTEGRADO EM E NGENHARIA E LETROTÉCNICA E DE C OMPUTADORES
Supervisor: Manuel Ricardo (PhD)

Co-Supervisor: Filipe Ribeiro
February 24, 2016

© Carlos Manuel Sanches Leocádio, 2016
Resumo
A recente evolução tecnológica potenciou uma disseminação de dispositivos móveis com uma
crescente capacidade de processamento e melhorias ao nível da conectividade sem fios. Um ex-
emplo disso são os smartphones, que se revelam actualmente imprescindíveis no quotidiano, pela
facilidade de acesso à informação e capacidade comunicação que proporcionam.
Porém, no contexto de um concerto musical a interacção entre os músicos e a sua assistência
permanece ausente. Esta fronteira que se verifica existir entre os músicos e a sua assistência limita
o âmbito da experiência musical, que de outra forma poderia ser mais rica e abrangente.
A solução procura eliminar essa barreira e permitir que a audiência se torne parte do espec-
táculo, interagindo com os músicos em palco através dos seus dispositivos móveis, possibilitando
experiências únicas e dinâmicas.
A componente central do sistema baseia-se na utilização de comunicação sobre IP multicast,
conjugada com técnicas de escalonamento temporal e retransmissões, tendo sempre em consider-
ação a reduzida validade temporal das mensagens. O sistema proporciona uma reduzida taxa de
perda de pacotes, estabelecendo um limite temporal máximo para a sua recepção no cliente.
A solução desenvolvida foi implementada no concerto do aniversário dos 30 anos do INESC
TEC, que decorreu na Sala Suggia da Casa da Música, para uma audiência de 1000 pessoas.
i
ii
Abstract
The fast technological development we are facing allowed the spread of mobile devices with in-
creased processing capacity and improved wireless connectivity. For instance smartphones are
now indispensable in daily life, because they provide ease of access to information and communi-
cation.
However, in the context of a musical concert interaction between musicians and their audience
is still absent. This boundary between musicians and their audience, limits the scope of the musical
experience which otherwise could be richer and more comprehensive.
The solution aims to eliminate such barrier allowing the audience to become part of the show,
interacting with the musicians on stage through their mobile devices, thus enabling unique and
dynamic experience.
The central component of the system is based on the use of communication over IP multicast,
combined with time scheduling and retransmission techniques, taking into account messages’ lim-
ited temporal validity. The system provides a low loss rate, establishing a maximum time frame
for the message reception by the clients’ devices.
The developed solution was implemented in a concert in Sala Suggia at Casa da Música to
celebrate the 30th INESC TEC anniversary, to an audience of 1 000 spectators.
iii
iv
Agradecimentos
Mais do que uma dissertação para conclusão de curso, este projeto foi uma aventura, um enorme
desafio, e uma oportunidade única de aprendizagem.
Desde cedo o desafio de tornar possível o que muitos afirmavam ser inalcançável se revelou
estimulante. Claro está que em momentos críticos até mesmo o mais crente acaba por ceder à
tentação de duvidar... "Será que isto vai funcionar?"
Esta dissertação é produto não de uma pessoa, mas resulta do trabalho de um coletivo que se
reuniu em torno de um propósito, a equipa ’a.bel’.
Agradeço ao professor Manuel Ricardo por me ter dado a oportunidade de integrar um projeto
com esta dimensão, pelo apoio que me prestou e por ter acreditado nas minhas capacidades e nos
meus (ainda verdes) conhecimentos.
Um bem-haja ao professor Rui Penha, por ter tido a brilhante ideia de que resultou este projeto,
e pela grande dedicação e apoio que sempre demonstrou.
Não poderia também deixar de mencionar o prazer e agradecer a oportunidade que foi trabalhar
com o Tiago Costa e o Alexandre Clément, e relembrar aqueles vários dias com mais de 24 horas
que passei na vossa companhia e na dos restantes membros da equipa ’a.bel’.
Deixo também uma palavra de apreço ao professor Rui Rodrigues, com o qual tive a oportu-
nidade de ter as primeiras reuniões de discussão sobre a implementação do projeto, e que sempre
demonstrou uma enorme calma mesmo nos momentos mais críticos.
Agradeço em especial ao meu co-orientador Filipe Ribeiro, que soube sempre apoiar-me ao
longo do projeto, acompanhando e ajudando-me a refletir no desenvolvimento das suas várias com-
ponentes. O conhecimento que me transmitiu não tem preço. O seu contributo para a organização
coerente deste documento é inegável. De outra forma este documento teria muito provavelmente
começado pela conclusão, a introdução a meio e o índice na contracapa, sem esquecer a numeração
de páginas hard coded.
Não podia também de deixar de agradecer aos membros da WiN, pelo seu contributo no projeto
’a.bel’, e ao INESC TEC pela forma salutar como me acolheu.
Agradeço a todos os meus amigos pelo apoio e confiança que me transmitiram.
Por fim, não poderia deixar de agradecer aos meus pais e à minha irmã pelo apoio incondi-
cional que sempre me deram, mesmo nos meus dias mais difíceis.
Carlos Leocádio
v
vi
“If debugging is the process of removing software bugs,
then programming must be the process of putting them in. ”
Edsger W. Dijkstra
vii
viii
Contents
1 Introduction 1
1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 State of the Art 5

2.1 Related Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 IEEE 802.11 Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 DSSS and OFDM Techniques . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 ISM Frequency Bands - 2.4 and 5 GHz . . . . . . . . . . . . . . . . . . 11
2.2.3 MIMO Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.4 Interference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.5 Medium Access Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.6 Quality of Service - 802.11e Amendment . . . . . . . . . . . . . . . . . 19
2.2.7 Transmission Power Control - 802.11d, 802.11h and 802.11k Amendments 20
2.3 Radio Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.1 Antennas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 IP Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.1 Internet Protocol - IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.2 IP Address Assignment and Routing . . . . . . . . . . . . . . . . . . . . 23
2.4.3 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5 Smartphones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.5.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.5.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3 Proposed Solution 35
3.1 Auditorium Spatial Organization . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2 Solution’s Network Component Characterization . . . . . . . . . . . . . . . . . 41
3.3 Wireless Connectivity Coverage and Frequency Planning . . . . . . . . . . . . . 42
3.4 Interference Minimization - Medium Access Mediator . . . . . . . . . . . . . . 43
3.4.1 a.bel Throughput Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.5 Terminal Devices Network Configurations . . . . . . . . . . . . . . . . . . . . . 54
4 Solution Implementation 57
4.1 System API Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2 A.N.S. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3 Pd Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.4 XML Configurations File Generator . . . . . . . . . . . . . . . . . . . . . . . . 76
ix
x CONTENTS
4.5 Network Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5 System Performance Analysis 79

5.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2 Intra Zone Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.3 Inter Zone Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.4 Sala Suggia Concert Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.4.1 Multimedia Result and Media Impact . . . . . . . . . . . . . . . . . . . 99
6 Conclusion 101
A A.N.S. Output Interface - Super zones example 103
B Experiments Network Hardware 105
References 107
List of Figures
1.1 Sala Suggia blueprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 IEEE 802.11 Physical and Data Link components . . . . . . . . . . . . . . . . . 8

2.2 Representation of Narrowband versus Wideband Signals . . . . . . . . . . . . . 10
2.3 Representation of 2.4 GHz band channels [17] . . . . . . . . . . . . . . . . . . . 11
2.4 Multipath Propagation [19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Small-scale fading [19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6 MIMO Channel Model [20] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7 Hidden Node Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.8 Exposed Node Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.9 Access method and back-off procedure [19] . . . . . . . . . . . . . . . . . . . . 17
2.10 RTS/CTS Handshake Mechanism [26] . . . . . . . . . . . . . . . . . . . . . . . 19
2.11 802.11 MAC PHY Stages Model [32] . . . . . . . . . . . . . . . . . . . . . . . 22
2.12 Unicast Addressing [35] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.13 Multicast Addressing [37] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.14 Mapping between IP and Ethernet Multicast Addresses [40] . . . . . . . . . . . 26
2.15 Switch without IGMP Snooping support . . . . . . . . . . . . . . . . . . . . . . 28
2.16 Switch with IGMP Snooping support . . . . . . . . . . . . . . . . . . . . . . . . 28
2.17 Broadcast Addressing [42] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.18 Generic TCP connection establishment (3-way handshake) . . . . . . . . . . . . 30
2.19 Generic TCP connection close . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.20 Mobile Operating System Market Share [44] . . . . . . . . . . . . . . . . . . . . 31
3.1 a.bel Sytem’s Interaction Loop Representation . . . . . . . . . . . . . . . . . . . 36

3.2 System’s Components Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Sala Suggia Audience Zone’s Organization . . . . . . . . . . . . . . . . . . . . 38
3.4 Normalized Zones Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5 Cell Zones Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6 Superzones example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.7 System’s components overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.8 Cell zones Layout with 2.4 GHz Operating Frequency Planning . . . . . . . . . . 43
3.9 High Level Representation of A.N.S.’s Architecture . . . . . . . . . . . . . . . . 44
3.10 Formula for δ value calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.11 Translation process abstract representation . . . . . . . . . . . . . . . . . . . . . 46
3.12 D&S Process Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.13 Consumer’s processing sequence . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.14 A.N.S. output over time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.15 Super zones packets delivery VLAN based mechanism . . . . . . . . . . . . . . 51
xi
xii LIST OF FIGURES
3.16 Target transmission time window splitting procedure . . . . . . . . . . . . . . . 52

3.17 Wireless channels abstract representation . . . . . . . . . . . . . . . . . . . . . 53
3.18 ARP flood problem - query to localhost IP . . . . . . . . . . . . . . . . . . . . . 55
4.1 Data Packet structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.2 Block structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3 Terminal Packet structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4 Initialization process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5 Receiver component process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.6 D&S component process – overview . . . . . . . . . . . . . . . . . . . . . . . . 64
4.7 D&S component process – data packet pre-processing . . . . . . . . . . . . . . 65
4.8 D&S component process – pairs creation and enqueue procedure . . . . . . . . . 66
4.9 Channel queue consumer process . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.10 Super zones consumer process . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.11 Broadcast sending routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.12 Reset procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.13 Pd Simulator GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.14 Pd Simulator usage - part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.15 Pd Simulator usage - part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.16 Zones coverage by AP belonging to cell zone C8 . . . . . . . . . . . . . . . . . 77
5.1 Delay testbed layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.2 Representation of the translation and enqueue process by A.N.S. of a single test
data packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.3 A.N.S. output NIC capture, resulting of one test data packet translation . . . . . 82
5.4 A.N.S. Output NIC Capture shown super zones terminal packets transmission . . 83
5.5 Intra zone delay measurement layout . . . . . . . . . . . . . . . . . . . . . . . . 84
5.6 Network delays histogram - reference . . . . . . . . . . . . . . . . . . . . . . . 85
5.7 Application delays histogram - reference . . . . . . . . . . . . . . . . . . . . . . 87
5.8 Network delays histograms - reference vs attenuated client . . . . . . . . . . . . 88
5.9 Application delays histograms - reference vs attenuated client . . . . . . . . . . . 88
5.10 Same channel saturation layout . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.11 Network delays histograms - reference vs saturated operating channel condition . 90
5.12 Application delays histograms - reference vs saturated operating channel condition 90
5.13 Adjacent channels saturation layout . . . . . . . . . . . . . . . . . . . . . . . . 91
5.14 Network delays histograms - saturated operating channel vs saturated adjacent
channels conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.15 Application delays histograms - saturated operating channel vs saturated adjacent
channels conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.16 Application delays histograms - reference vs P = 20% network losses . . . . . . 94
5.17 Application delays histograms - reference vs P = 30% network losses . . . . . . 95
5.18 Application delays histograms - P = 20% network losses vs P = 30% network losses 96
5.19 Inter zone delay measurement layout . . . . . . . . . . . . . . . . . . . . . . . . 96
5.20 Application delays histograms - inter zone experiment with 3 terminal clients . . 97
5.21 Monitor computer location during the event . . . . . . . . . . . . . . . . . . . . 98
5.22 Event room overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.23 Event picture showing public interaction through their smartphones . . . . . . . 100
List of Tables
2.1 Evolution of IEEE 802.11 Standard . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 IGMP versions comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3 Top selling Android smartphones specifications . . . . . . . . . . . . . . . . . . 32
2.4 Apple’s iPhone models characteristics . . . . . . . . . . . . . . . . . . . . . . . 32
3.1 Zones Map example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2 Traffic Reduction Experimental Results . . . . . . . . . . . . . . . . . . . . . . 55
5.1 Histogram mode values in ms - test vs theoretical . . . . . . . . . . . . . . . . . 86

5.2 Tests results (values in ms) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.3 Lossy network scenario - application delays results . . . . . . . . . . . . . . . . 95
5.4 Concert results - absolute values . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.5 Concert results - successful delivery rates . . . . . . . . . . . . . . . . . . . . . 99
5.6 Consecutive lost packets occurrences . . . . . . . . . . . . . . . . . . . . . . . . 99
xiii
xiv LIST OF TABLES
Abbreviations, acronyms and initials
ACI Adjacent-Channel Interference

ACK Acknowledgment
AP Access Point
ARM Advanced RISC Machine
BSS Basic Service Set
CA Collision Avoidance
CAP Controlled Access Phase
CC Control Contention
CCA Clear Channel Assessment
CCI Co-Channel Interference
CFP Contention Free Period
CP Contention Period
CPU Central Processing Unit
CSI Channel State Information
CSMA Carrier Sense Multiple Access
CTS Clear To Send
CW Contention Window
DCF Distributed Coordinated Function
DFS Dynamic Frequency Selection
DHCP Dynamic Host Configuration Protocol
DIFS DCF Interframe Space
DSSS Direct-Sequence Spread Spectrum
EDCA Enhanced Distributed Channel Access
ETSI European Telecommunications Standards Institute
FIFO First-In First-Out
FHSS Frequency-Hopping Spread Spectrum
GPU Graphics Processing Unit
HC Hybrid Controller
HCCA HCF Controlled Channel Access
HCF Hybrid Coordination Function
HD-WLAN High Density WLAN
HiperLan High Performance Radio LAN
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IGMP Internet Group Management Protocol
IP Internet Protocol
IPTV Internet Protocol Television
IR Infrared
xv
xvi Abbreviations, acronyms and initials
ISM Industrial, Scientific and Medical

ISO International Organization for Standardization
LAN Local Area Network
LLC Logic Link Control
LOS Line of Sight
LTE Long Term Evolution
MAC Media Access Control
MIMO Multiple-Input and Multiple-Output
MISO Multiple-Input and Single-Output
MLD Multicast Listener Discovery Protocol
MPC Multi Path Component
MU-MIMO Multi-User Multiple-Input and Multiple-Output
NAT Network Address Translation
NAV Network Allocation Vector
NDP Neighbor Discovery Protocol
NIC Network Interface Controller
OFDM Orthogonal Frequency-Division Multiplexing
OS Operating System
OSI Open Systems Interconnection
PHY Physical Layer
PC Point Coordinator
PCF Point Coordination Function
PD Pure Data
PIFS PCF Interframe Space
PIM Protocol Independent Multicast
PN Pseudo-Noise
QoS Quality of Service
RAM Random Access Memory
RF Radio Frequency
RFC Request for Comments
RISC Reduced Instruction Set Computing
RS Receiver Sensitivity
RTS Request To Send
SIMO Single-Input and Multiple-Output
SINR Signal-to-Interference-plus-Noise Ratio
SISO Single-Input and Single-Output
SLAAC Stateless Address Autoconfiguration
SNMP Simple Network Management Protocol
STA Station - device with wireless capabilities
TCP Transmission Control Protocol
TPC Transmission Power Control
TX Transmitter
TXOP Transmission Opportunity
UDP User Datagram Protocol
VoIP Voice over Internet Protocol
WC Wireless Channel
WiMAX Worldwide Interoperability for Microwave Access
WLAN Wireless Local Area Network
Chapter 1
Introduction
1.1 Context
Create interaction between audience and performers during a concert, is increasingly desired,
aiming to provide a richer multimedia experience, using the already available and highly spreaded
devices, such as smartphones. Nevertheless, such interaction is difficult to achieve, and could
easily become a disruptive element in the context of a performance.
Although today most people that attend a musical concert have a device with wireless com-
munication capabilities, there isn’t available a solution that can make the audience devices part of
the performance. There are two major groups of restrictions to consider in such scenario; all the
devices have their own specifications and capabilities devided by brand, model and OS version
and compilation; the installed communication technology was not designed for such demanding
scenario. In large events, with hundreds of simultaneous connected devices in the same open
space, the wireless network is expected to perform poorly, and its implementation represents a
complex challenge. Our main motivation is supported by the analysis of the State of the Art where
we concluded that there isn’t available an integrated, reliable, scalable and cost-effective network
solution that could support such scenario.
1.2 Goals
Develop a solution to connect hundreds of mobile devices to a network in a concert environment

that is reliable, cost-effective, easy to deploy and operate.
The resulting system aims a real case scenario targeting an audience of approximately 1000
spectators, that took place in a concert in Casa da Musica Sala Suggia to celebrate the 30th IN-
ESC TEC anniversary. The event was scheduled to 26th October 2015, three months before the
scheduled delivery of this thesis. This fact by itself represents a goal of this thesis, which was to
develop and implement a solution with challenging requirements within a few months.
The solution should meet the following requirements:
1
2 Introduction
Figure 1.1: Sala Suggia blueprint
• Real-time communication - during the concert, the generated messages should be sent to
their target clients with minimum delay possible;
• Time-validity - each generated message targeting clients should be received by them within
a reduced time-window, after which its significance is lost considering the concert piece
timing;
• Zone-aware messaging - the system should provide some sort of client’s addressing gran-
ularity, allowing a given message to be received by multiple groups of users simultaneously,
without affecting the remaining ones;
• Generation order preservation - the messages generation order should be preserved, and
must not change during the processing and sending procedures, so it remains consistent with
the ongoing performance on-stage;
• Devices compatibility - the system must support both Apple’s iOS and multi-brand An-
droid OS devices, represented by a large variety of hardware implementations with different
capabilities;
• Transparency - user’s system usage should be transparent, or acquired with minimum

intervention, without making any permanent change in their devices.
1.3 Structure 3
• Energy efficient - the solution must take into account that the target systems have a low
autonomy and so, the developing system should avoid energy wasting.
1.3 Structure
This thesis is organized in several chapters. Chapter 2 presents and discusses the most relevant
technologies to be considered in the scope of the pursued solution and their limitations. In Chap-
ter 3 a solution is proposed and highly detailed and Chapter 4 describes the implementation of the
proposed solution. Chapter 5 describes the tests methodology used to verify system’s requirements
conformity. Lastly, Chapter 6 ends this report, presenting some conclusions.
4 Introduction
Chapter 2
State of the Art
The present chapter describes some previous solutions, which somehow tries to address the major
problematic of the scenario we target: to provide interaction among the audience members during
a live concert.
The previously developed solutions presented in Section 2.1, which are recurrently imple-
mented in stadiums and auditoriums where is usually verified a cluster of wireless devices, al-
though provide enriched experience to the audience participants, do not allow an explicit inter-
action with them. This results from the extremely complex scenario which represents wireless
connectivity when aiming to provide live interaction in high-density environments. In our per-
spective such interaction is never truly accomplished by none of the already available solutions, as
they only provide unidirectional type of interaction.
Our solution main purpose is to enable live bidirectional interaction between the performers on
stage and the audience participants, using the increasingly common devices such smartphones and
tablets. All these devices have one common aspect regarding their communication capabilities,
since currently all of them conforms with the IEEE 802.11 standard. Therefore, after presenting
the related solutions, this chapter will present a deep analysis on such standard and their speci-
fications in Section 2.2, aiming to verify which of them suits the pursued solution requirements.
Besides the IEEE 802.11 standard, a brief evaluation on the ISO model layers 3 and 4 protocols,
to assess how their characteristics combine with the pursued solution requirements.
2.1 Related Solutions
The use of mobile devices networking together, in order to create ubiquitous experiences in musi-
cal concerts, have been explored over the years.
Golan Levin, in 2001, used his audience 2G mobile phones ringtones as the musical material
for his work called "Dialtones (A Telesymphony)" [1]. Here, the audience’s mobile phones were
previously loaded with ringtone melodies, during the seating ticket assignment process. Also
during this process, the audience’s phone numbers were collected and introduced in a custom
5
6 State of the Art
developed software, which allowed the live performers to call up to 60 simultaneous mobile phones
triggering their ring tones, creating a musical performance.
Other works, such as Princetons Laptop Orchestra (PLORK) [2] and Standford’s Mobile Phone
Orchestra (MoPho) [3, 4] and Orquestra de iPhones da Casa da Música [5], have demonstrated
innovative ways to use mobile devices in the context of musical performance.
PLORK’s performances were made by 12 to 15 persons, using laptops connected to specially
designed multi-channel hemispherical speakers, transmitting musical content previously devel-
oped using Max/MSP or Chuck audio programming languages. They also use other peripherals in
the performance context, such as keyboards, graphic tablets, infrared/light/pressure sensors and,
more recently, Nintendo’s Wii remote controller.
MoPho and Orquestra de iPhones da Casa da Música created musical ensembles using mobile
devices, exploring their I/O capabilities, such as, multi-touch screens, built-in accelerometers,
gyroscopes, microphones, speakers, cameras and GPS, enabling portable and personal musical
instruments, that can be used to create and broadcast multimedia content.
The British band Coldplay has been using wristbands, with colored LEDs and radio receivers,
called Xylobands [6], since 2012 to engage audiences and make them part of the show, config-
uring a practical example on the growing willingness of popular music acts to adopt novel ways
to increase interaction with their audience. These device’s behavior is centrally controlled by a
computer software connected to a radio transmitter, allowing to set the LEDs status – ON or OFF
– and also blinking frequency. Control messages are addressed to the wristbands based on their
colors. More recently a similar product provided by PixMob have debuted in the market. Using
the same concept as the Xylobands, PixMob offers a variety of remotely controlled devices, like
wristbands and ball with RGB LEDs using Bluetooth and Infrared technologies. These devices
powered by their own battery, are carried by the audience members that represent pixels of a large
screen. Such setup requires the use of dedicated solution designed equipment, namely the light-
ning console where the commands are generated, and the wireless broadcaster that can be either
IR or Bluetooth. The requirements of a musical performance, such as precision, timing, relia-
bility and responsiveness, represents an interesting and demanding environment for the currently
most spread communication technologies. The aforementioned examples use either the audience
members ringtones as sound sources or a computer network on stage as an integral part of the per-
formance environment. However, nowadays we can assume that a significant part of the audience
in a concert carries a smartphone or other type of devices with wireless communication capabil-
ities, which can be used as a part of a framework, in order to create a bidirectional interaction
between performers and audience, enabling a "Performer – System – Audience" as described by
Bongers et. al [7].
In 2003, with the increasing availability of mobile devices with wireless communication con-
nectivity, the financial and technological viability of large sized wireless networks deployments
becomes pertinent, as discussed in [8]. Here, it is proposed that, enabling the audience in large-
2.1 Related Solutions 7
venue events with rented wireless devices could attract more consumers, empower their involve-
ment in the event and increase the revenue.
In [9] a complete scalable architecture for multimedia streaming via wireless LAN’s (WLAN’s)
using IEEE 802.11 standard is proposed, which can, allegedly, support up to 1600 concurrent me-
dia streaming clients. This work makes use of concepts of multi-channel WLAN’s, transmission
power control, and cache-and-relay technologies. The results, based on simulations, did not take
into account the network stack, ignoring for instance, the medium access control or the distributed
coordination function (DCF) mechanisms presented in IEEE 802.11 protocol, leading to the con-
clusion that the presented results have limited feasibility considering the reality.
The work [10] presents the practical results of using wireless LAN to send information toward
a potential large number of mobile terminals, running an application developed for the purpose of a
large fireworks festival. The setup makes use of directional antennas and IP multicast. Regardless
of being an interesting approach, the total number of clients effectively served by this solution
during the event did not exceed the two hundred, considering the goals of our work, it was low.
Furthermore, information on the simultaneous number of served clients is not provided. The
network implemented on a seafront, where interference caused by nearby networks is negligible,
has only two access points (AP) working on channels – 7 and 11 –, with 20 MHz bandwidth using
OFDM. This configuration leads us to conclude that the solution targets a simpler scenario than
the one we propose in this thesis.
Commercial solutions are available which can provide high capacity, coverage and throughput,
to stadium size areas. An example of such solution is "Cisco Connected Stadium Wi-Fi Solution"
[11], which combines highly directional antennas and high-performance dual band access points
plus specially designed software algorithms working on proprietary and dedicated hardware to
optimize access to typically obstructed wireless radio frequency (RF) environment. Here, the
main objective is to provide to the audience with live video streaming of the event, as well as
other functionalities such as internet connectivity, and oriented publicity using their personal own
devices(i.e., smartphones, tablets, laptops). Still, a solution like the aforementioned is extremely
expensive to deploy. For instance, the central device on which this solution is based, the Cisco
5508 wireless LAN Controller, costs at least 22 000 euros [12].
Ruckus, which is another company specialized in deployment of wireless networks, takes an
approach based on carefully placement of multiple APs considering the target place’s architec-
tural geometry and construction materials, in order to reduce the interference. During the 2014
World Cup this company deployed a network in Maracana Stadium. With a total of 76000 seats
and 217 Ruckus ZoneFlex APs installed, the resulting ratio seats/AP was 350 [13]. From the
217 APs installed, 126 were ZoneFlex model 7782N, a dual-band IEEE 802.11n compatible ac-
cess point with an integrated 30 degrees narrow beam antenna [14]. Once more, each one of this
AP costs approximately 2000 euros, resulting in an even expensiver solution than the previous one.
The following sections will present and discuss the potential technologies which can provide
solution’s groundwork for the high-density wireless scenario we are addressing, and the major
8 State of the Art
problematics involved. Although other standards have been proposed for wireless connectivity,
such as High Performance Radio Lan (HiperLan) by European Telecommunications Standards
Institute (ETSI), 100 % of the solution’s targeted devices support IEEE 802.11 standard and con-
sequently, we focused our study in this standard.
Consequently, it was important to comprehend the IEEE 802.11 standard and its evolutions,
thereby attempting that the final solution took advantage of all the capabilities it currently presents.
2.2 IEEE 802.11 Standard

The increasingly demand for wireless connectivity and bandwidth lead to the evolution of IEEE
802.11 standard, which specifies physical and data link layers from Open Systems Interconnection
(OSI) model, as shown in Figure 2.1.
Figure 2.1: IEEE 802.11 Physical and Data Link components
The original standard for WLAN, IEEE 802.11, was released in 1997 and specifies three phys-
ical layer technologies: infrared (IR), frequency-hopping spread spectrum (FHSS) and direct-
sequence spread spectrum (DSSS).
Two years later IEEE released two amendments to the original protocol. The 802.11b, which
uses DSSS modulation technique in the 2.4 GHz band, and the 802.11a, which uses orthogonal
frequency-division multiplexing (OFDM) modulation instead of DSSS to accomplish higher data
rates. In Section 2.2.1 both techniques will be presented. The IEEE 802.11a standard introduces
the use of 5 GHz frequency band, allowing a greater number of non-overlapping channels. How-
ever it was not compatible with the previous one. Both standards could not handle the demanding
data rate needs of multimedia applications, such as voice or video streaming.
In 2003 IEEE released a new amendment called IEEE 802.11g, which implements OFDM
modulation techniques from IEEE 802.11a in the 2.4 GHz frequency band. The IEEE 802.11n
amendment introduces mechanisms of frame aggregation, allowing substantially decrease on net-
work overhead. This amendment also introduces the use of Multiple Input Multiple Output
(MIMO) technique, exploiting multipath propagation to accomplish higher data rates, as will be
2.2 IEEE 802.11 Standard 9
discussed in Section 2.2.3. Table 2.1 summarize the key aspects of IEEE 802.11 standard evolu-
tion.
Table 2.1: Evolution of IEEE 802.11 Standard
Release Date Standard Band (GHz) Channel Bandwidth (MHz) Modulations Maximum rate Advanced Antenna Technologies
1997 802.11 2.4 20 IR, FHSS, DSSS 2 Mbit/s none
1999 802.11a 5 20 OFDM 54 Mbit/s none
1999 802.11b 2.4 20 DSSS 11 Mbit/s none
2003 802.11g 2.4 20 DSSS, OFDM 54 Mbit/s none
2009 802.11n 2.4, 5 20, 40 OFDM 600 Mbit/s MIMO
2012 802.11ad 60 2160 SC OFDM 6.76 Gbit/s Beamforming
2013 802.11ac 5 20, 40, 80, 160 OFDM 6.93 Gbit/s MIMO, MU-MIMO
The continuous update of the standard noticeably increased the maximum data rate capacity
of the networks that implement it. This enables the connected devices to transfer data with higher
throughputs. Furthermore, lowering the latency was always a concerning aspect with the advent
of real-time applications, like VoIP. A fundamental cause for the aforementioned throughput in-
creases, was the hardware evolution, more specifically the computational power.
As predicted by the Moore’s Law, which guides semiconductor industry planning, the number
of transistors in an integrated circuit has doubled every two years since 1975, resulting in higher
computational powers. Moreover, in the last recent years new CPU architectures were developed
to equip the mobile devices with higher computational power at expense of lower energy consump-
tion. One of such architectures is Advanced RISC Machine (ARM), firstly developed by Acorn
Computers in the 1980s, which later joined efforts with two major players in the market, Apple
Inc. and VLSI Technology. Today this architecture, either 32 or 64 bits, dominates the mobile
devices market.
From the IEEE 802.11 standard point-of-view, the capacity gains were accomplished by means
of three evolutions:
1. Changing modulation technique from DSSS to OFDM;
2. Using larger channel bandwidth and different spectrum regions;
3. Development of multiple-input and multiple-output (MIMO) technology;
2.2.1 DSSS and OFDM Techniques
DSSS modulation technique is based on multiplying the signal of interest, carrying data to trans-
mit, with a pseudo-random locally generated digital signal, represented by a sequence of values
1 or −1. The latter one, also called pseudo-noise (PN) sequence, is produced by a deterministic
10 State of the Art
process commonly known by both transmitter and receiver to allow a correct demodulation, has
a higher frequency compared to the signal being modulated. As a consequence, the frequency
spectrum presented by the resulting signal has a larger bandwidth when compared to the original
one, and is similar to the frequency spectrum of white noise. In addition, spreading the original
narrowband signal in a wideband one, allows the resulting signal power to be lower than the noise
power, as represented in Figure 2.2. Therefore the resulting signal has higher resistance to inter-
ception and jamming. This scheme allows multiple simultaneous users in the same channel in
a secure and non-interfering way, as each signal has its own generating PN sequence, making it
suitable and very common in military communications. Nevertheless DSSS modulation technique
is unable to accomplish high data rates.
Our solution targets an indoor open space environment, its structural architecture and build-
ing materials lead to the occurrence of multipath and fading phenomenons characterized in Sec-
tion 2.2.3 . The use of DSSS modulation in such conditions would imply the need for a more
complex demodulator at receiver, resulting in higher processing latency and ultimately in more
power consumption on the terminal devices, contradicting the requirement for a energy efficient
solution.
Figure 2.2: Representation of Narrowband versus Wideband Signals
Evolution from DSSS to OFDM was an inevitable step given the needs for high-data rates.
Although OFDM has been firstly described in 1966, its implementation only becomes possible in
the 1990s, as a result of hardware evolution in the field of digital signal processing.
Orthogonal Frequency Division Multiplexing (OFDM) is the modulation technique used by the
recent IEEE 802.11 amendments, and takes an approach based on frequency division multiplexing
without the need of guard bands. This results in a more efficient frequency spectrum usage and
higher data rates.
With this technique a high-rate data stream of bandwidth size B is splitted in N parallel streams,
each one is then transmitted by a single sub-carrier of bandwidth NB . The N subcarriers are orthog-
onal and partially overlapping among each other.
Wi-Fi standard specifies the usage of channels with 20 MHz bandwidth. Higher bandwidths
are accomplished by aggregating multiple adjacent channels of 20 MHz. Currently, IEEE 802.11
MAC layer allocates an entire channel to a single client, even if the amount of data to transmit
requires only a fraction of that bandwidth. Recent works propose a technique called channel
width adaptation [15] for IEEE 802.11, in which a channel is divided into multiple sub-channels
allocated to multiple users. This enables the transmission of simultaneous data streams by distinct
users, and improves the wireless network efficiency. In the proposed solution, each sub-channel
is composed by a variable number of OFDM subcarriers, either adjacent or not, providing to the
client the amount of bandwidth based on their traffic needs. Similar approaches were taken in the
currently IEEE 802.16 (WiMAX) and Long Term Evolution (LTE) standards, as a mean to support
the deployment of high-density efficient wireless networks. However, it is not possible in the IEEE
802.11 as it requires a new MAC layer.
2.2.2 ISM Frequency Bands - 2.4 and 5 GHz
The physical layer (PHY) of IEEE 802.11 standard specifies the usage of 2.4 and 5 GHz Industrial,
Scientific and Medical (ISM) frequency bands. Each country applies its own regulations on the
available channels and maximum transmission power. The presented information is focused on
European Union regulations.
The 2.4 GHz band represented in Figure 2.3, is divided in 13 channels with a bandwidth of 22
MHz each, when considering DSSS modulation technique, spaced by 5 MHz, resulting in 3 non-
overlapped channels. The useful bandwidth in each channel, i.e. the bandwidth actually used to
transmit data, depends on the modulation technique used. When using OFDM the actual channel
bandwidth is 20 MHz. The low number of orthogonal channels in 2.4 GHz band is a constraint
to the deployment of a network with several APs because, as more APs are installed, more APs
will be operating on the same channel. An incorrect planning of location and cell size of each AP
results in high co-channel interference [16].
Figure 2.3: Representation of 2.4 GHz band channels [17]
The 5 GHz band, is divided in 19 channels, all non-overlapping, with a bandwidth of 20 MHz.
Although the use of this band leads to higher data rates, it is also a fact that will have shorter range
as a consequence of the higher frequency compared to the 2.4 GHz. The 2.4 GHz band is used
by many others devices such as microwave ovens, cordless phones, Bluetooth devices, wireless
video cameras, outdoor microwave links, wireless game controllers, Zigbee devices, fluorescent
12 State of the Art
lights, WiMAX, and so on. These devices does not work in a collaborative way with IEEE 802.11
ones, and can induce in erroneous assumptions on the medium occupation, leading to a drop of
throughput. As a consequence, IEEE 802.11a/n networks using 5 GHz band, are noise dominated,
while IEEE 802.11b/g/n using 2.4 GHz band are interference dominated [16].
As stated in 1.2, the purpose of this work is to support currently marketed smartphones. Al-
though the of IEEE 802.11ac is being spreaded into the newer equipments, this technology is
still far from being predominant [18]. By that reason, our solution will focus on IEEE 802.11n
standard, using the 2.4 GHz frequency band.
2.2.3 MIMO Technology

In MIMO, input and output refers to the point of view of the channel used to establish com-
munication between two terminals. Besides IEEE 802.11, 3G and 4G mobile phone networks,
among others, use this technique. The performance gains results from sending multiple beams
simultaneously, each one carrying a different data stream, through the same channel, using multi-
ple transmitters and receivers, exploiting multipath propagation characteristics and fading. When
available, MIMO technique uses Channel State Information (CSI) to optimize transmission. CSI
could be either empirical or statistical, and refers to the channel’s propagation conditions between
the transmitter and receiver, influenced by phenomenons as multipath, fading, scattering and power
decay.
At this point, is important to introduce the two following phenomenons:
Multipath: transmitted signal can reach the target receiver through multiple paths, as a result
of its reflection on the environment objects, as illustrated in Figure 2.4. In some cases where
the communication by Line of Sight (LOS) is not possible transmission the signal reaches the
destination after one or multiple reflections and diffractions, resulting in a multitude of signals
with different properties such as delay, amplitude, direction of arrival and phase shifts. Each one
of these signals is commonly known as a Multi Path Component (MPC) [19, p.27].
Figure 2.4: Multipath Propagation [19]
Fading: simple receiver cannot distinguish MPCs from each other, and simply proceeds to the
sum of all of received MPCs. This process results in interference, which can be either constructive
or destructive, depending on the phases of each MPC. MPC phases depend mostly on the traveled
distance, position of the stations and intervening objects on the path [19, p.28]. Figure 2.5 shows
an example of the small-scale fading and its effects on the signal.
Figure 2.5: Small-scale fading [19]
MIMO technology exploits the previously presented wireless communications peculiarities to

accomplish greater channel capacity, using the following techniques.
• Beamforming: At the transmitter, the original signal is emitted through all of the available
antennas, with suitable phase and module, based on CSI. The objective is to maximize the
signal power at the receiver, where signals from distinct antennas are added in a constructive
way reducing the effects of multipath and fading.
• Spatial multiplexing: A high-rate signal is divided into multiple signals, which are then
transmitted through distinct antennas. These signals arrive at receptor’s antennas affected
by multipath and fading. The receptor with CSI knowledge is able to recognize and separate
each one of the streams in approximate parallel channels. The maximum number of spatial
parallel streams is given by the minimum common number of antennas between receptor
and transmitter [19, p.465].
• Space-Time Coding: As no CSI information is available at transmitter (TX), redundancy

is added, resulting in the same signal being transmitted through all the available antennas.
Each one of the aforementioned signals is previously coded with full or near orthogonal
coding and transmitted from a distinct antenna, thus increasing the probability that at least
one reaches the receptor, in conditions of being decoded.
Figure 2.6 shows a generic representation of MIMO channel model.
Let’s us assume the following:

14 State of the Art
Figure 2.6: MIMO Channel Model [20]
xi – signal transmitted by transmitter i ∈ [1, NT ];

y j – signal received by receiver j ∈ [1, NR ];
hi j – channel complex gain between transmitter i and receptor j;
Given that, the resulting signal Y at the receiver can be expressed by the following equation:
Y (n) = H(n) × X(n) + η (n) (2.1)
where:
  
  
x1 η1   y1
    h11 h12 h13 . . . h1,NR  
 x2   η2   y2 
 h21 h22 h23 . . . h2,NR 
       
x  y 
X(n) =  3  η (n) =  3  H(n) =  Y (n) =
η 
 .. .. .. .. ..    3
 . 
 .. 
 . 
 ..   . . . . .   . 
 .. 
hNT ,1 hNT ,2 hNT ,3 . . . hNT ,NR
     
xNT ηNR yNR
X(n): original signal to transmit;

H(n): matrix representing the complex channel gain;
η (n): noise component;
Y (n): received signal;
As a consequence, depending on the number of antennas of both transmitter (NT ) and receiver
(NR ), there are three particular cases of MIMO topologies:
• SISO – Single Input Single Output – both transmitter and receiver have only one antenna;
• SIMO – Single Input Multiple Output – transmitter has only one antenna, but receiver has
multiple antennas;
• MISO – Multiple Input Single Output – transmitter has multiple antennas, but receiver has
only one;
In [21] a capacity study, based on simulations on each one of topologies is presented. As

expected, the SISO configuration presented the worst performance. MISO 2x1 configuration had
a similar, or in some cases even better performance than MIMO 2x2, which was not expected. In
the pursued solution’s scope this result has significant importance, as the target devices, mostly
smartphones are typically equipped with a single antenna.
2.2.4 Interference
In order to understand the interference problematic, the following two definitions are of major
importance.
Contention Domain: The contention domain of node i is the set of nodes which can generate
enough interference, preventing node’s i transmission, and can be mathematically represented by
Si = { j}∀i, j : N0 + Pj d ji ≥ Ci , i 6= j (2.2)
where Ci matches the CCA threshold of node i, Pj is the transmit power of node j and d ji is the
channel gain between nodes j and i.
Symmetry: Network N is considered symmetric, if and only if i ∈ S j and j ∈ Si , ∀i, j ∈ N and

i 6= j;
In wireless environments we can assume two types of interference: adjacent-channel in-

terference (ACI) and co-channel interference (CCI). Here is important to note that both the
aforementioned types of interference are generated by the equipments using IEEE 802.11 stan-
dard, and should not be misunderstood with the interference caused by other equipments, such as
microwaves, Bluetooth, and other devices that operate on the same frequency band. The ACI and
CCI are characterized by a collaborative interference type which are attended in the standard using
medium access mechanisms that are detailed in Section 2.2.5.
CCI happens when a device transmission causes a delay on other device transmission, when
both shares the same channel. This phenomenon can also lead to frame losses due to collisions.
In large scale wireless deployments, where channel re-usage is inevitable, CCI reduces the band-
width available in each cell. ACI occurs when transmission is made using partially overlapping
channels, as a result of the limited number of orthogonal channels available, as described in Sec-
tion 2.2.2. This type of interference can lead to one of following problems, as stated in [22] and
[23]:
Hidden node: when two non interfering nodes start to transmit at the same time, it causes a
collision at their common receiver. For example, in Figure 2.7 where the nodes A, B,C ∈ network
N, where B ∈ SA and B ∈ SC , but both SA and SC are two disjoint sets. As a consequence A and
C may start to transmit at the same time, causing a collision in their common receiver B. To
16 State of the Art
address this problem, IEEE 802.11 standard recommends the use of Request-to-Send/Clear-to-
Send (RTC/CTS) handshake, as will be detailed in Section 2.2.5.2.
Figure 2.7: Hidden Node Problem
Exposed node: occurs when a node prevents its transmission, due to the presence of another
transmitter in is neighborhood/contention domain. In Figure 2.8 (B + D) ∈ SC , but B ∈
/ SD . Thus, C
will defer its transmission, every time B is transmitting, although their transmissions have different
recipients.
Figure 2.8: Exposed Node Problem
IEEE 802.11n standard is particularly susceptible to ACI, in comparison with older b/g stan-
dards, mostly because the number of OFDM data subcarriers was increased from 48 to 52, reduc-
ing the number of guard carriers [23, 24].
There is also a phenomenon that causes frame losses known as "stronger-last" collision, which
derives from the inability of common Wi-Fi equipments, for reasons of hardware price reduction
and complexity, to distinguish a new received signal powerful than the previous one, although it
had enough power to be decoded [25]. As a result, both previous and current transmissions are
lost.
2.2.5 Medium Access Mechanisms
Every time that there is a frame to be sent, 802.11 MAC layer medium access mechanisms are
triggered. The frame’s destination can be either broadcast, multicast or unicast and its retransmis-
sions. The medium access mechanisms knowledge are relevant to assess how can their procedures
affect the pursued solution performance.
2.2.5.1 CSMA/CA Mechanism
In order to control medium access, IEEE 802.11 distributed coordination function (DCF) imple-
ments carrier sense multiple access with collision avoidance (CSMA/CA) mechanism with binary
exponential back-off time whose implementation is mandatory for all stations (STAs). DCF is part
of OSI model layer 2, as shown in Figure 2.1. According to this mechanism, all the STAs follow a
listen-before-talk proceeding. Every STA checks the channel state, accessing its occupation before
transmitting. If the channel is idle for a DCF Interframe Space (DIFS) period, the transmission is
made. On the other hand, if the channel is sensed busy, STA defers its transmission, waiting for
the end of the current one. After then, STA selects a random number between 0 and a contention
window (CW), which indicates the required time that the wireless channel has to be idle before a
new transmission attempt. CW size is incremented (up to a limit) each time a transmission has to
be deferred, and is doubled in case of collision occurrence during transmission [19, p.747].
DCF, presented in Figure 2.9, only support best-effort delivery, without any guarantees on
packet delay and jitter.
Figure 2.9: Access method and back-off procedure [19]
CSMA/CA evaluates channel state through clear channel assessment (CCA). Before transmit-
ting a frame, STA measures the interference power present on the wireless channel, and compares
it with its own CCA threshold. If the measure presents a value greater than CCA threshold the
channel is considered to be busy and the transmission is delayed, based on formerly presented
CSMA/CA mechanism. Assigning an appropriate CCA threshold value based on the total inter-
fering signal power SI measures, may allow simultaneous wireless channel (WC) usage by multi-
ple STAs. However, changing this value carelessly, may result in a signal degradation at receiver,
preventing adequate demodulation [16].
R
SINR = (dB) (2.3)
N0 + I
18 State of the Art
Equation (2.3) presents the definition of signal-to-interference-plus-noise ratio (SINR) used

to determine the maximum data rate capacity of a given WC, from the client’s perspective. R
represents the power of the receiving signal of interest, N0 the power of the noise and I the total
interfering signal power. A greater SINR leads to a greater data rate channel capacity.
In scenarios, like the one we propose, where is expected to have hundreds of devices connect-
ing to a network with several APs installed in open space, the study of the interference problem is
of great importance since there is a direct correlation between the number of the APs installed and
the interference generated between them. Moreover, the throughput that each device can achieve is
directly correlated with the number of APs installed because the capacity of each AP is divided by
the connected devices. As more APs are installed, higher is the capacity of the network, however
as higher is the number the APs higher is the interference for a set of channels.
As stated in [25], in order to provide good throughput in HD-WLANs the parameters underly-
ing the CSMA/CA need to be adaptive, considering network’s topology, which changes with the
movement of people, existing traffic and interference. Hence, a solution is proposed, based on
both CCA threshold adaptation algorithm and dynamical adjust of receiver sensitivity (RS), using
SINR information measures gathered from network devices, in order to decrease hidden and ex-
posed node probabilities, whose problematic has been characterized in Section 2.2.4. RS dynamic
adaptation allows filtering of reception interfering weak signals, and theoretically this approach
could lead to 300% throughput increase.
In [22] is presented a cross-layer solution to address unsuitability of CSMA/CA in HD-
WLANs based on tuning parameters like CCA threshold and transmission power, in a controlled
and centralized way, avoiding node starvation and asymmetric links. Briefly, when a node wants
to perform a high power transmission, his CCA threshold should be lowered.
Both works, [25] and [22], refer that interference could be reduced using dynamical power
control in all STAs, like it’s done in cellular networks (3G/LTE).
As a consequence of the contention domain and symmetry definitions, presented in Section 2.2.4,
when performing transmission power control, one must guarantee that there is none node j ∈ Si for
which i ∈
/ S j . Otherwise node j could prevent node’s i transmission, leading it to medium access
starvation.
Although transmission power control could lead to substantial improvements in throughput,
as shown in [22], it is impractical to implement in our solution, because it would require dynam-
ical control of transmission power and CCA threshold of each STA individually, as well as high
privilege access to the equipment’s network stack in all of those STAs. Also, as stated in [25],
transmission power control has two major problems: is limited to the hardware capacity to trans-
mit in a wide transmission power range and to the regulations, and also, lowering transmission
power in order to obtain a greater spacial reutilization could result in a transmitted signal with a
power lower than the noise N0 .
2.2.5.2 RTS/CTS
Figure 2.10: RTS/CTS Handshake Mechanism [26]
Figure 2.10 shows RTS/CTS handshake mechanism. When a node have a packet to send, it
starts listening the medium during a DIFS period. If the medium is free, the node sends a RTS
frame, which includes the receiver’s address, as well as an estimated time for transmission of data
and ACK frames. ACK should be sent by the receiver upon successful reception of data frames.
Each node that receives an RTS, must setup its network allocation vector (NAV) accordingly,
deferring access to the medium during the estimated time transmission. The destination node,
immediately after receiving the RTS frame, starts listening the medium for a SIFS period. If
during this time, the medium is sensed free, it then sends the CTS frame. Once more, CTS frame
indicates the estimated time for the transmission of data+ack, and all the stations update their NAV
accordingly and the sender node starts the transmission.
RTS/CTS is an optional feature of IEEE 802.11 standard, introduced specifically to address the
hidden node problem, reducing collisions and improving the overall network performance. These
performance gains are achieved through the reduction of retransmissions. Nevertheless, this fea-
ture is only useful when the hidden node problem is expected to exist. Otherwise, the air-time
consumed by the mechanism will have a negative impact in network performance [27].
2.2.6 Quality of Service - 802.11e Amendment
Introduced in 2005, this amendment addresses IEEE 802.11 MAC enhancements to provide Qual-
ity of Service (QoS) capabilities, which relevance becomes pertinent with the increasing usage of
delay sensitive real-time applications over WLANs.
Originally supported only by IEEE 802.11a/b/g MAC, this amendment was included in the
IEEE 802.11-2007 standard specification. Besides DCF operation, based in the CSMA/CA mech-
anism presented in Section 2.2.5.1, IEEE 802.11 MAC layer also specifies, in an upper layer, an
20 State of the Art
alternative point coordination function (PCF) – Figure 2.1 –, wherein the AP, playing the role of
a point coordinator (PC), sends beacon frames periodically to announce its presence and spread
informations about the network it belongs to. Between these frames, PCF mechanism is applied,
splitting the time frame interval in two: contention period (CP), where contention-based DCF
mechanism is applied; contention free period (CFP), which uses PCF, a polling-based approach.
Stations implementing PCF, will transmit one MAC protocol data unit (MPDU) during CFP, when
asked by the AP through CF-Pool packet. The PC accesses medium occupation waiting for a PCF
Interframe Space (PIFS) period, lower than DIFS, and consequently has higher channel access
priority.
PCF does not provide QoS in the real sense of the term, because traffic classes are not defined,
as occurs in other QoS implementations such as DiffServ. Consequently within IEEE 802.11e
amendment, DCF and PCF are improved, in order to provide QoS capabilities.
Enhanced Distributed Channel Access (EDCA) was consequently introduced, presenting an

evolution on the previous DCF MAC mechanism, wherein traffic is classified and sent based on
their priority. There are four types of priority: voice; video; best effort; background. Consequently,
the outgoing traffic is putted in four distinct FIFO queues, one for each priority, and greater pri-
ority queues lower is the backoff time. Also, a packet transmission occurs during a Transmission
Opportunity (TXOP), where higher priority means a higher TXOP. Although the traffic classifi-
cation is based on application requirements, this implementation being contention based cannot
guarantee QoS leading to the introduction of HCCA.
PCF evolution resulted in the HCF (hybrid coordination function) Controlled Channel Access
(HCCA). As in PCF, inter-frame beacon time is divided in CP and CFP and, during CP, all STAs
uses the previously presented EDCA. The main difference is that in HCCA the PC can establish a
CFP – here called Controlled Access Phase (CAP) – even during a CP, through sending a Control
Contention (CC) frame. During CAP the AP, which in this context is known as Hybrid Controller
(HC), regains control over medium access.
PCF in IEEE 802.11 MAC layer is optional, and consequently in large deploys is possible
to have client devices which only implements DCF. Those devices are not compatible with IEEE
802.11e.
In the scope of our solution it can be useful to consider APs with IEEE 802.11e capabilities,
particularly with Wi-Fi Multimedia (WMM) certification, providing a more reliable and demo-
cratic traffic flow. For instance, when considering multicast traffic, that affect a multitude of
devices simultaneously, one should grant higher medium access priority over unicast traffic.
2.2.7 Transmission Power Control - 802.11d, 802.11h and 802.11k Amendments

The usage of wireless communications in high density deployments soon revealed problematic,
mostly due to co-channel interference (CCI). For that reason, over the years, IEEE has tried to
minimize this problem, through a series of amendments, aiming to provide transmission power
control in a centralized and coordinated manner.
2.3 Radio Propagation 21
The first amendment which tries to address this problem was IEEE 802.11d, released in 2001,
wherein each AP has the ability to advertise the regulatory or country transmission power maxi-
mum limit.
Later, in 2003, IEEE 802.11h introduced a power constraint element, where an AP could apply
to it’s domain a transmission power lower than the regulatory limit. All the devices covered by this
AP should set up their TX power accordingly. However, this mechanism only applies to Dynamic
Frequency Selection (DFS) and Transmission Power Control (TPC) compliant devices in the 5
GHz band – IEEE 802.11a PHY – which is far from being common.
With the intent to create a more general solution, and given the increasing use of wireless net-
works by mobile devices, i.e. smartphones, tablets, laptops, using high traffic and time-critical ap-
plications, IEEE released in 2008 a new amendment, called 802.11k, introducing concepts specif-
ically to limit CCI and optimize battery power usage of mobile devices. Once more an AP can
advertise a transmission power constraint lower than the regulatory limit. However, contrarily to
IEEE 802.11h, this amendment applies both 2.4 and 5 GHz bands. Generally speaking, IEEE
802.11k implements transmission power control mechanism through link reports which allow a
client to discover how its signal is heard by the AP, allowing it to adequate its transmission power
level. Thus, CCI is reduced, allowing higher concentration of clients, with improved network
throughput.
Even though it was introduced seven years ago, there are still few devices compatible with
IEEE 802.11k. The aforementioned amendment is part of Wi-Fi Alliance Voice-Enterprise Certi-
fication [28], which currently has only 36 phones certified 1 . For instance, Android, which has the
largest market share in mobile operating systems [29], in its latest release (Android 5.0 Lollipop),
still does not support IEEE 802.11k [30, 31].
2.3 Radio Propagation

2.3.1 Antennas
When deploying high-density wireless infrastructures, typically formed by multiple cells, the an-
tennas play a fundamental role. Their placement and characteristics will bound the solution ca-
pacity.
The overall throughput of an IEEE 802.11 HD-WLAN can be approximated by the following
expression [25]:
C×L×N (2.4)
where:
• C - per-link capacity;
1 http://www.wi-fi.org/product-finder-results?sort_by=default&sort_order=desc&
categories=4&capabilities=6
22 State of the Art
• L - number of simultaneous transmissions/links per channel;
• N - number of non-interfering channels used by the network;
The variables C and N are bounded by both IEEE standards and the legislation on the frequency
spectrum usage. As a result, the variable L represents the only degree of freedom that can be
optimized to improve the network capacity, as the authors state. But, even L, is conditioned by
CCA mechanism.
As described in [32] L is bounded to the CCA mechanism. To achieve an higher L, a lower
modulation and coding scheme (MCS) is used, so the total channel capacity is divided by a lower
C. However, this same characteristics have the downside of increasing the hidden node problem
probability.
The common installed antennas are divided into two types, directional and omni-directional
antennas. With directional antennas the transmitted power is concentrated towards a set of re-
ceivers. This increases the received signal power providing a better demodulation condition.
Therefore, due to this type of directional radiation, the interference problem is mitigated since
it reduces the nodes contention domain. Having this, spatial reuse techniques can be applied for a
better network planning.
The wireless communications typical physical layer is based on the four blocks model, shown
in figure Fig. 2.11.
Figure 2.11: 802.11 MAC PHY Stages Model [32]
In [32] a performance analysis based on the usage of directional antennas in HD-WLANs is

presented, leading to the conclusion that omni-directional transmission (OTx), omni-directional
CCA (OCCA) and directional reception (DRx) is the configuration which provides the highest
throughput. It is also concluded that with a larger beamwidth directional antenna, the overall
throughput decreases for the same CCA threshold.
Considering the previous study conclusions, and our particular case scenario, the use of direc-
tional antennas in the deployed APs to perform directional transmission and reception (DTx and
DRx) could theoretically allow concurrent channel access by clients associated to distinct APs
2.4 IP Communication 23
operating in the same wireless channel, when considering clients with DRx. But since our target
devices are marketed smartphones with omni-directional behavior in all the three stages (CCA, Tx
and Rx), such channel concurrency can not be accomplished, as all the devices operating in the
same channel affects each other.
2.4 IP Communication
2.4.1 Internet Protocol - IP
Introduced in September 1981, as described in the IETF publication RFC 791 [33], IPv4 provides
addressing and fragmentation functions. The host address has 32-bit length, resulting in total of
4294967296 addresses – 232 –, about 4295 millions. From these, there are some reserved address
ranges. For instance, there are about 18 millions addresses reserved for private networks and about
270 millions for multicast.
IPv6, specified by RFC 2460 [34], with a status of Internet Standard, was published in De-
cember 1998, uses a 128-bit address space, allowing up to 2128 different addresses.
Although the increasing usage of IPv6, its stack implementation has not reached the expected
maturity and permeability. This comes from the fact that many Operating System (OS) developers
have disregarded IPv6 stack implementation, and some of those implementations are not in accor-
dance with the Internet Standard as will be exposed in Section 2.5.2. For that matter, this thesis
will focus in the usage of IPv4 as it represents a more mature addressing protocol and one that is
highly deployed in the target devices. Nevertheless considerations on the IPv6 stack will be made
thus presenting a contribution for future evolutions on the current solution.
2.4.2 IP Address Assignment and Routing
When considering IP communication there are four types of operational characteristics, which are
related with the IP address class considered, namely unicast, multicast, broadcast and anycast. In
this work we will focus on the usage of unicast, multicast and broadcast whose characteristics
better suit our pursued solution considering system’s requirements which entail the following two
major probable scenarios:
(A) Send/receive information to/from a specific client, in a one-to-one approach;
(B) Send the same information to numerous clients, simultaneously, with minimum wireless
medium resources usage;
2.4.2.1 Unicast
Unicast, as illustrated in Figure 2.12, consist on sending information to a specific destination on

the network, identified by a unique address, thus representing scenario A. The unicast address
assignment procedure can be either static or dynamic.
24 State of the Art
Figure 2.12: Unicast Addressing [35]
In a static based IP configuration the address is manually assigned to the device’s interface.
As a consequence, when used over large scale networks carelessly can result in conflicts when
multiple devices in the same network have equal IP addresses.
Dynamic IP assignment can be accomplished through the use of Dynamic Host Configuration
Protocol (DHCP). The dynamic IP assignment process uses of a DHCP server, which is responsi-
ble to lease IP addresses, and other network relevant configurations, to hosts on request. The usage
of such mechanism avoids the need of assign IP statically to every machine on a network, and also
avoids duplicated IP address assignment conflicts occurrence. Consequently, DHCP server is fre-
quently deployed in common network hardware, like routers.
If neither static or dynamic IP assignment succeeds, some host’s operating systems can trigger
address autoconfiguration mechanism, through which the device can make its own IP assignment,
enabling communication within the link-local scope. A link-local address is one that is only valid
for unicast communication within the LAN segment where it was generated. As a result routers
do not forward packets which destination consists in a link-local IP address. There are reserved
address blocks to use in such scenario, which are 169.254.0.0/16 for IPv4, while IPv6 uses the
fe80::/10 block.
Usually IPv4 hosts do not support multiple addresses per interface, and consequently their
network configuration is normally acquired using static or dynamic assignment processes. How-
ever an IPv4 host which supports IP address auto configuration can trigger the autoconfiguration
procedure, when unable to receive an IP address lease from an DHCP server. Therefore, the host
starts by choosing a random IP from the reserved link-local block, and uses ARP request to verify
if there is any other host on the network using that same IP. Then if the host receives an ARP
reply, meaning that the IP address has already been taken by other host, it chooses other address,
and restarts the ARP request verification process. When the host do not receive an ARP reply
for a certain link-local IP, it configures its interface with that same address, and becomes locally
available. Microsoft’s Automatic Private IP Addressing (APIPA) is an example of such protocol.
For IPv6 stack implementation ARP was replaced by Neighbour Discovery (ND) protocol,
whose operation is based on ICMPv6. In the recent IP stack implementation, IPv6, hosts are
required to support multiple addresses in the same interface. Therefore IPv6 presents improved
self configuration functionalities, as Stateless Address Autoconfiguration (SLAAC). Stateless Ad-
dress Autoconfiguration (SLAAC), as described in RFC 2462 [36], allows a host to self-assign a
link-local IP address based on its own Ethernet MAC address, following the next steps:
1. Link-local address generation - the device generates an link-local address formed by the
prefix 1111 1110 10, followed by 54 zeros and its own 64-bit NIC Ethernet MAC;
2. Address uniqueness test - the device ensures that the previously generated link-local ad-
dress is locally unique. Here, the device sends a Neighbour Solicitation (NS) message, using
Neighbour Discovery (ND) protocol;
3. Address assignment - if the previous step succeeds, based on the interpretation of received
Neighbour Advertisement (NA) messages, the device assigns itself the address, becoming
available in the local network;
4. Router contact - occurs by sending a Router Solicitation message by the device, or by
listening of Router Advertisement (RA) messages sent periodically by routers.
5. Router direction - The router may announce a "stateful" configuration, telling the address
of the DHCP server to use or, alternatively, when a "stateless" configuration is implemented
the router provides information which allows the device to obtain a global Internet address.
This message allows a device to complete its autoconfiguration.
6. Global address configuration - If it assumes a "stateless" configuration, the host will
configure its interface with the globally-unique Internet address provided by the router.
The previously described autoconfiguration address mechanisms, available for both IPv4 and
IPv6 networks, can avoid the need for deployment of a DHCP server, which can be difficult to con-
figure and maintain, giving the number of clients targeted by our solution. Also, a DHCP server
represents a potential single point of failure, which can compromise the network operation. More-
over, our solution targets a wireless environment with hundreds of people, and DHCP negotiation
and renovation proceedings would result in a considerable wireless medium occupation.
Nevertheless auto configuration mechanisms, although avoiding the need of a DHCP server
deployment, would inevitably result in wireless medium occupation, and network performance
degradation, as result on the previously presented configurations sequences. For instance, in an
IPv4 network, whose auto configuration method relies on ARP messages, an ARP broadcast storm
could occur.
2.4.2.2 Multicast
Figure 2.13: Multicast Addressing [37]
Multicast address identifies a group of receivers which have demonstrate their interest in re-
ceiving traffic sent to a specific group, matching scenario B needs. Each group is identified by a
26 State of the Art
distinct IP address. The sender sends a single datagram from its unicast address, designated to a
multicast address. All users that have previously joined the multicast group receive the sent data-
grams. This addressing methodology is particularly useful when sending the same information to
multiple simultaneous receivers and, for that reason, is typically used in multimedia applications
like IPTV streaming. Multicast uses UDP, which has no acknowledge mechanism at MAC layer,
susceptible to losses that are aggravated when used through wireless networks.
As mentioned in [38], when performing multicast transmission over Wi-Fi, the maximum
transfer rate is limited by the maximum rate capacity of the worst receiver present in the basic
service set (BSS). A BSS is formed by one AP and all their associated STAs. The MCS used in
this kind of transmission can be seen as the lowest commonly supported within BSS. Hence, clients
with more powerful devices will ultimately have the same throughput as the powerless one present
in the BSS. Also, multicast transmission over Wi-Fi relies only in the CSMA/CA mechanism,
discussed in Section 2.2.5.1, to decrease collision probability when accessing the shared wireless
medium resource. The RTS/CTS mechanism presented in Section 2.2.5.2 is not supported, with
consequent increase probability of occurrence of the hidden node problem.
Some devices, including some Google’s official ones like Nexus 4 and Nexus 5, have their
kernels compiled without multicast support, as described in Issue # 51195 [39]. This results from
the lack of Internet Group Management Protocol (IGMP) support, which is the de facto multicast
membership control protocol. IGMP will be presented and discussed in Section 2.4.2.2.
Figure 2.14: Mapping between IP and Ethernet Multicast Addresses [40]
IP multicast presents another peculiarity to have in consideration, shown in Figure 2.14 The
range of IPv4 addresses reserved for multicast purposes, formerly classified as class D addresses
(224.0.0.0/4), which results in layer 3 address range with value 1110 in the four most significant
bits, leaving 28 bits for addressing. This addresses are mapped in layer 2 directly, considering
only the 23 less significant bits of IP address. All the Ethernet multicast addresses begin with
0x0110.5Eyy.yyyy, thus presenting only 23 bits for addressing, making it impossible to map the
28-bit IP multicast address (layer 3) without loss of information. This results in an ambiguity
of 32:1 between IP multicast (layer 3) addresses and Ethernet addresses (layer 2). For instance,
the IP multicast addresses 224.1.1.1, 224.109.1.1 and 238.1.1.1 presents the same MAC multicast
address (01:00:5E:01:01:01), and can cause collisions in layer 2 equipments, such as switches.
Multicast Routing Protocols
Multicast networks are typically dynamic, as any node may join or leave a group at any instant.
Consequently, a set of mechanisms is needed to provide such capabilities.
IGMP, which has three versions, is used in IPv4 networks by their nodes, primarily by routers
and hosts, to report multicast groups membership to their adjacent routers. Any node may sub-
scribe multiple multicast groups. Hence, IGMP support is fundamental to allow proper multicast
traffic flow.
Table 2.2: IGMP versions comparison
IGMPv1 IGMPv2 IGMPv3

Default Query Interval (seconds) 60 125 125
Maximum response time 10 seconds configurable (0 to 25.5 seconds) configurable (0 to 53 min.)
Leave Group Message Support no yes yes
Destination Address of Leave Group Message - 224.0.0.2 224.0.0.22
Group specific query support no yes yes
Versions Interoperability - with IGMPv1 with IGMPv1 and IGMPv2
IGMPv1, described in RFC 1112 released in August 1989, was the first Internet Standard
to specify the required IP host extensions to support IP multicast. It defines two types of IGMP
messages: host membership query and host membership report. The first is used by the router,
to discover which multicast groups are present in a segment, and is sent periodically. The latter
allows a host to announce their multicast group membership.
Later, in November 1997, RFC 2236 was released, presenting IGMPv2 specification. The
major improvement introduced was IGMP Leave Group message, allowing a host to inform their
correspondent multicast router that no longer belongs to a given group, reducing the time taken
by a multicast router to access that there are no longer members of a particular group present in
a given segment. When a router receives a leave message, sends out a membership query to that
group to verify if there is still some node in the segment belonging to the queried multicast group.
If none membership report is received by the router, it stops sending the traffic to that segment,
resulting in a more efficient bandwidth usage.
Originally proposed in RFC 3376 in October 2002, IGMPv3 was lately defined in RFC 4604
in August 2006, which also includes Multicast Listener Discovery Protocol Version 2 (MLDv2)
specification. MLD is IPv6 specific and uses ICMPv6.
IGMP Snooping
Our scenario targets a wireless network of considerable dimensions. In such deployments, the net-
work equipment used to connect all the APs providing network connectivity is a layer 2 compatible
equipment. In a network where multicast traffic is present, a normal switch – pure layer 2 switch
– will forward all the received multicast traffic through all their ports, except to the incoming
one. This is commonly known as multicast flood, and can cause negative impact on the network
28 State of the Art
performance. Eventually the flood will reach AP, and be transmitted to the wireless environment,
leading to unnecessary medium occupation.
IGMP snooping is a layer 2 mechanism, that enables a switch to build a map of which of
their interfaces have multicast groups subscribers, and what groups. That map is built through the
interpretation on the layer 3 IGMP messages. Consequently, switch will only forward multicast
stream to the links where it is actually needed, i.e., links where multicast clients have joined a
specific multicast group.
When APs are connected to a switch this mechanism is of extreme importance, as it prevents
all the multicast traffic present in a specific domain from being transmitted to the wireless medium.
Figure 2.15: Switch without IGMP Snooping support
Figure 2.16: Switch with IGMP Snooping support
Figure 2.15 shows a switch without IGMP snooping capabilities and consequently all the mul-
ticast traffic present in the LAN is sent through all the APs to the wireless medium, even when
inside their cells only some of that traffic was needed. Therefore the wireless medium is being
occupied with unnecessary packets. In Figure 2.16 a switch implementing IGMP snooping is pre-
sented. As a consequence of IGMP snooping mechanism, this switch only forwards to each AP
the multicast packets that have been requested by their associated STA.
Besides what is supposed to happen, some documentation such as [41], reports some issues
related with interoperability between IGMP versions 2 and 3 compatible hosts, in networks where
hosts and routers are connected through a IGMP snooping capable switch.
2.4.2.3 Broadcast
Figure 2.17: Broadcast Addressing [42]
Broadcast addressing methodology, as illustrated in Figure 2.17, allows sending a single packet
to all devices available in the same network.
In IPv4 networks, broadcast address can be derived from host’s IP address, setting to one
all bits equal to zero in its network mask. Using pure broadcast methodology to accomplish
communications will affect all the devices within the network, even the ones to which the message
content is not intended. As a result, such approach leads to a lost on network performance and
devices unnecessary computational power consumption.
IPv6 network stack implementation have eliminated the concept of a broadcast specific ad-
dress. In those networks, broadcast is accomplished using a all-nodes multicast address. Never-
theless we must remind that IPv6 stack implementation is not always compatible with our target
devices, as will be discussed in Section 2.5.2.
2.4.3 Transport Layer

The two most commonly used transport protocols – OSI Model layer 4 – are TCP and UDP, built
on top of IP. These have differences as regards the type of service each provides.
TCP is a connection oriented protocol, supporting reliable transmissions with error checking,
flow and congestion control mechanisms. Before data transmission, a channel must be created, be-
tween two participants, which is accomplished through connection establishment sequence, based
on a three-way handshake, as presented in Figure 2.18.
30 State of the Art
Figure 2.18: Generic TCP connection establishment (3-way handshake)
Upon successful data transmission, the previously created channel must be closed. The closing
proceeding is accomplished through the exchange of four messages, as shown in Figure 2.19.
Figure 2.19: Generic TCP connection close
As a result of the previously presented mechanisms, which are primarily intended to ensure
the reliability of the transmission, a large overhead is added. Consequently, TCP is not suitable
for real-time communications, in which this paper focus. This inefficiency would become more
evident when using such transport protocol over Wi-Fi, due to the potential losses caused by
collisions.
TCP has been developed to target wired communications, its additive increase/multiplicative
decrease and slow start mechanisms, when used in wireless mediums, can lead to an under-
utilization of channel’s capacity. For instance, a lost packet acknowledge, which easily could
occur in wireless environments due to a sporadic collision, leads the protocol to assume that the
medium is congested, proceeding to a drastic decrease on the congestion window, resulting in a
2.5 Smartphones 31
lower throughput than the possible, considering the wireless channel’s environment conditions.
Over the years multiple enhancements to TCP have been developed and proposed, aiming to opti-
mize its usage under wireless environments, as mentioned in [43].
UDP is a connectionless transport protocol, as it has no acknowledgement capabilities and
does not requires an establishment neither termination proceedings. The lack of such mechanisms
results in a protocol with low overhead, appropriate for real-time applications such as sought in
this work, where losing data packets is preferred to receive delayed packets.
2.5 Smartphones
Considering the data presented in Figure 2.20, currently there are two major players as regards
mobile operating systems: Android OS from Google, with a market share of 52 % and iOS from
Apple Inc. with 39 % share.
Figure 2.20: Mobile Operating System Market Share [44]
Considering this distribution, our work will focus on providing a solution compatible with the
two predominant operating systems.
2.5.1 Hardware
Smartphone sales in Portugal have been increasing, reaching over 2 million only in 2013. Samsung
leads the preferences of consumers, having sold about 700 thousand units, followed by LG with
sales of around 290 thousand units. Despite the higher number of units sold belong to Samsung,
LG has the highest sales growth rate. Third in the preferences of Portuguese consumers is Apple
with its iPhone models to submit sales of about 250 000 units [45].
Considering this statistical numbers, Table 2.3 summarizes the relevant hardware and software
characteristics of the most common Android smartphones from Samsung, providing a rough view
of their capabilities. Similarly Table 2.4 resumes the capabilities of some of the most recent iPhone
32 State of the Art
models.
Android OS
Table 2.3: Top selling Android smartphones specifications
Original OS Sreen Size

Year Model CPU (GHz) RAM (GB) Wi-Fi connectivity
version (inches)
2011 Samsung Galaxy S II 2.3 1,2 - 1,5 dual-core 1 4.3 802.11 a/b/g/n
2012 Sansung Galaxy S III 4.0.4 1,4 quad-core 1-2 4.8 802.11 a/b/g/n
Samsung Galaxy S4 4.2.2 1,2 - 1,6 quad-core 2 5 802.11 a/b/g/n/ac
2013
Samsung Galaxy S4 mini 4.2.2 1,7 dual core 1,5 4.3 802.11 a/b/g/n
802.11 a/b/g/n/ac
Samsung Galaxy S5 4.4.2 1,3 - 1,9 quad-core 2 5.1
2014 MIMO (2x2)
Samsung Galaxy S5 mini 4.4.2 1,4 quad-core 1,5 4.5 802.11 a/b/g/n
Apple iOS
Table 2.4: Apple’s iPhone models characteristics
Year Model Original OS version CPU (GHz) RAM (MB) Wi-Fi connectivity
iPhone 4 4.0 1 (@ 800MHz) 512

2011 802.11 b/g/n (2,4 GHz only)
iPhone 4s 5.0 1 (@ 800MHz) dual-core 512
2012 iPhone 5 6.0 1,3 dual-core 1024

802.11 a/b/g/n (2,4 and 5 GHz)
2013 iPhone 5s 7.0 1,3 dual-core 1024
2014 iPhone 6 8.0 1,4 dual-core 1024 802.11 a/b/g/n/ac
2.5.2 Software
Android OS
A substantial number of devices running Android OS, released in 2013 and after, aren’t ca-
pable of connecting to IPv6 only Wi-Fi networks, as stated in Issue # 32630 [46]. Some devices
running this Android based OS today can connect to IPv6 WLANs using Stateless Address Au-
toconfiguration but, upon connection, they start waiting for DHCPv4 lease response. If after
some time IPv4 lease is not granted, the equipment automatically leaves the previously connected
WLAN. Such behaviour is related with losses of connectivity when trying IPv6-only communi-
cations in Android devices, and goes against what is currently stated as Best Current Practice in
RFC 6540 [47]. The aforementioned document, released in April 2012, clearly states that "IPv6
support must be equivalent or better in quality and functionality when compared to IPv4 support
in a new or updated IP implementation." and "New and updated IP networking implementations
should support IPv4 and IPv6 coexistence (dual-stack), but must not require IPv4 for proper and
complete function.".
2.5 Smartphones 33
Another relevant aspect is related with the implementation of Neighbour Discovery Protocol
(NDP) as reported in Issue # 32662 [48]. NDP is part of IPv6 stack, and provides mechanisms for
router solicitation (RS), router advertisement (RA), neighbour advertisement (NA) and network
redirects (NR), which are used during the IP assignment and route configuration processes, as
presented in Section 2.4.1. Devices affected by this issue ignore RA packets after connecting to
the network. As a result of this misbehavior, they lose their connectivity, as these packets have the
ability to renew the validity of IPv6 and the default router addresses. In the context of our work
is also important to notice that Android does not support DHCPv6, as described in Issue # 32621
[49], presenting a limitation to a stateful configuration implementation, according to [50].
Android, being free and open-source linux-based mobile OS, had a great acceptance in the
market, mostly because it ships in a large variety of equipments, produced by tens of different
brands, covering from the most simple and affordable cell-phones, with limited hardware re-
sources – typically single core ARM CPU and 256 or 512 MB of RAM –, to the most expensive
smartphones currently marketed with considerable processing capabilities – quad-core or even
eight-core CPU’s, dedicated GPU full-HD capable and up to 4 GB of RAM. As a consequence,
each producer compiles and installs its own version of the OS, in each different model, leading to
a non-uniform platform.
Apple iOS
Apple’s iOS, a BSD-based and closed-source mobile OS, is developed to target a specific
equipment, with previously defined hardware capabilities, resulting in a more stable and uniform
platform.
34 State of the Art
Chapter 3
Proposed Solution
We now present a novel solution for the high density wireless networks in large concert halls where
the main communication challenge is to enable interaction between the audience mobile devices
and the performers systems. In Chapter 2 we have presented some solutions that try to solve the
problem of creating interaction between the audience and the performers. However those solutions
either use dedicated hardware or the supported number of mobile devices is very low compared to
our target.
PLORK/SLORK implementations only allow a cooperative interaction among the performers,
using laptop computers and dedicated peripherals. It has a limited scope given the reduced number
of people involved, and the only difference between such approach and the traditional orchestra
setup is the usage of digital technology during the performance.
Dialtones approach is more embracing, as it clusters the entire audience as part of the orchestra.
Nevertheless, audience members are only used as an output interface to the sound being generated
and centrally controlled. Given the technology implied – 2G mobile network – the solution is not
scalable, as it would be impractical to use such technology to create a performance with a few
hundred people due to 2G network cell’s capacity constraints. Even with current technologies, the
aforementioned approach would not be easily implementable. Also, the solution only allows a 60
simultaneous generated sounds transmitted through the audience mobile phones.
Pyxmob, as an evolution of Xylobands technology, creates large pictures or animations by
equipping the audience with devices that emit light like pixels in a display. Thus, the users in-
teraction is almost absent as they only are devices carriers. Pyxmob’s approach uses proprietary
technology and specifically designed devices, acquired by the audience, resulting in a more costly
solution. Also, users devices are probably disposed at the end of the performance due to its short
life-time characteristics, configuring an non ecological solution.
In the same chapter we have performed a detailed study of the most wireless technology spread
through mobile devices, IEEE 802.11. This study enabled us to better understand the problems
related to the HD-WLAN and enabled us to develop a solution with multiple strands related to the
mandatory goals enumerated in Section 1.2. The developed solution provide unique features when
compared to the state of the art ones presented in Section 2.1.
35
36 Proposed Solution
network packets to create

interaction opportunities
a.bel Network
Dispatcher
a.bel Wi-Fi
messages sent to
specific zones or
audiovisual stimuli superzones
musicians on stage with

traditional and/or
electronic instruments
hundreds of audience members' smartphones with

the a.bel app and the concert-specific content
audiovisual feedback
Figure 3.1: a.bel Sytem’s Interaction Loop Representation
Figure 3.1 presents our vision, of what we consider to be a truly inclusive and interactive sys-
tem. The musicians performing on stage using instruments either traditional, electronic or both,
and the audience being included in the overall performance using their smartphones to create
multimedia contents synchronized to each instant context. This synchronization with the running
concert context is achieved by performers by sending real-time commands to the audience smart-
phones through a wireless network. Installed in all the smartphones is an application specially
designed to process the received commands.
To solve the interaction problem we had to consider a larger scope for this thesis, that could
included all the communications dependent components of the a.bel system. To accomplish that,
our solution had to include:
1. a specific wireless network configuration;
2. a middleware software component, which represents our major contribution;
3. smartphones network configuration;
4. smartphones dedicated application networking behavior design;
5. performers application networking behavior design
6. solution test tools;

Proposed Solution 37
The thesis also includes a full system deployment in Casa da Música for the INESC TEC
anniversary concert.
The diagram in Figure 3.2 presents a high-level overview of a.bel system components, used to
achieve the desired interaction with the audience. The system is divided into four major blocks:
Figure 3.2: System’s Components Overview
• Data Generator, responsible for generating content data considering the audience’s room
organization, which will be discussed in Section 3.1. This software component development
is out of the scope of this thesis, however its networking behavior is. The performers used
this module to generate the commands targeting smartphones with a strict temporal rela-
tionship with the on-stage performance. For Sala Suggia’s specific implementation, data
generator was implemented in an environment called Pure Data (Pd), based on libpd open-
source visual programming language. Pure Data allows the creation of multimedia content
through a drag-and-drop based interface, avoiding the need of writing explicit libpd code
language [51].
• A.bel Network Server (A.N.S.), a middleware component, which acts as an interface be-
tween the data generator and the clients terminal devices;
• Network Hardware, from which is part all the wireless access points and the layers 2 and
3 backbone hardware;
• Client Terminal Devices, connected to the system by their IEEE 802.11 compatible wire-
less interfaces, allowing them to receive the generated data stream, and interacting through
a.bel smartphone’s application, developed for Android OS and Apple’s iOS mobile oper-
ating systems. This thesis do not focus on the development process of such applications.
Nevertheless we have provided guidelines on the proper devices network configurations.
Our purpose was to provide a stand-alone solution, which fulfills all the system’s requirements
presented in Chapter 1. The developed system was able to work autonomously after the initial
configurations.
Before proceed to the solution description, it must be understood the target room’s dimensions
and characteristics, which imposed some restrictions to the solution design. These characteristics
and the zoning design proposed is explain in the next section.
3.1 Auditorium Spatial Organization
In the interest of artistic expression, and pursuing the zone-aware system requirement, we have
proceed to the division of Sala Suggia’s auditorium, with a total of 1069 seats, into zones, thus
enabling individual and differentiated interaction with the users among each one of these areas.
The division was made uniformly resulting in an average of 35 people among each zone. Split
large spaces into multiple zones is the common approach to be taken when planing HD-WLANs,
providing a better throughput/coverage relation and network hardware equipment acquisition costs
optimization. Sala Suggia’s spatial division result in 30 distinct areas, as shown in Figure 3.3, and
so this the maximum resolution available to the composer when developing contents to be played
by the audience for his piece.
Figure 3.3: Sala Suggia Audience Zone’s Organization
To provide an easier analysis for the upcoming discussion, the Figure 3.4 represents a normal-
ized layout of the previous Sala Suggia’s blueprint based figure, in which a single zone – z18 –
3.1 Auditorium Spatial Organization 39
is highlighted. There are 30 single zones, and each of this zones represents a group of mobile
devices. The single zone is the zone that aggregates the smallest amount of devices.
Figure 3.4: Normalized Zones Layout
A group of single zones which coverage is provided through the same AP is called a cell zone,
denoted by C. In Figure 3.5, cell zone C1 is formed by zones z1 and z2 , and C12 by zones z23
and z24 . The number of zones needed to form a cell zone should be dimensioned according to
each target space dimensions and other characteristics. In our case scenario, which targets Sala
Suggia, due to people’s density among each single zone z and foreseeing AP hardware maximum
supported simultaneous associated clients limitations, cell zones are formed by pairs of single
zones. Consequently this type of zone aggregates the double of devices than a single zone.
Figure 3.5: Cell Zones Layout
Grouping multiple adjacent single zones covered by multiple APs, creates a new kind of zone
called super zone denoted by S. Each super zone has also its own unique identifier. Consequently,
when the composer wants to send a message to multiple adjacent zones, he can generate a message
bounded to a super zone that groups all the targeted zones into one leaving to the network layer
the responsibility to deliver the message to all the aggregated devices in time.
Figure 3.6: Superzones example
In Figure 3.6, super zone S1 is formed by single zones z1 , z2 , z3 , z4 , z5 and z6 and super zone
S6 by single zones z1 , z7 , z13 , z19 and z25 .
Because each zone, regardless of its type, has a unique identification number, it allows the per-
formers to send content through the data generator to the specified zones without any knowledge
of the wireless network configuration.
Considering Sala Suggia’s layout, we have distinguished two types of super zones S: column
super zones S1 to S6 and line super zones S7 to S11 .
In conclusion, the auditorium logical organization comprises the following three types of
zones:
• single zones z, the singular building block, grouping an average of 35 people;
• cell zones C, formed by pairs of adjacent single zones z that are covered by a common AP;
• super zones S, formed by grouping multiple adjacent single zones, which the coverage is
provided by multiple APs;
• broadcast zone B, can be accomplished by grouping the minimum number of zones S needed
to cover all the audience participants. In our particular case scenario, that would be possible
using all the available line super zones
In conclusion, and considering a specific example, a client belonging to single zone z7 also
belongs to cell zone C4 and super zones S1 and S8 . Therefore, every client will always be part of
4 distinct zones, depending on its seat.
3.2 Solution’s Network Component Characterization 41
3.2 Solution’s Network Component Characterization

The network solution components used to interconnect stations with the data generator, are critical
since they set the overall network reliability and feasibility.
In this section the 3rd and 4th OSI layer solution is presented aiming to provide some base
ground information knowledge to better understand the remaining sections of this chapter.
The solution makes use of both addressing methodologies presented in Section 2.4, unicast
and multicast, as shown in Figure 3.7.
Figure 3.7: System’s components overview
Unicast based communication is used to connect data generator component with A.N.S., using
UDP protocol on top of IP addressing. We decided to use UDP because it better suits a typical real
time traffic scenario like ours, which is not compatible with the retransmission, acknowledge and
rate-adaptation mechanisms present in TCP, the other commonly used transport layer protocol.
IP multicast communication, in the context of the solution’s time-critical and zone-aware
requirements, was considered as being the ideal addressing methodology, to communicate with
stations, as it provides a one-to-many UDP based communication form. Due to its broadcasting
nature, the multicast traffic has no acknowledge mechanism at the MAC layer and so its reception
acknowledge by stations is not possible. Considering the time-validity and time-critical system’s
requirements, the acknowledge mechanism absence is considered profitable, allowing a more clean
wireless environment. In our scenario, acknowledge traffic has no practical interest, as the content
of a retransmitted data can arrive to stations out of the temporal context.
Nevertheless, the acknowledge mechanism absence can result in a significant loss rate prob-
ability. To overcome this problem the proposed solution includes a retransmission mechanism
described in Section 3.4, which aims to increase the packet’s successful delivery probability, send-
ing each packet multiple times. Consequently, it’s possible that the same packet reach client’s
terminal application R + 1 times, leading to the need of replicated packet filtering at application’s
level – OSI model layer 7. Furthermore, all the R+1 transmissions should occur within a time win-
dow W in which the message contained in the packet is considered still valid in the performance’s
context.
Therefore, A.N.S system component, which is responsible to establish the communication
interface between data generator component and the stations makes use of two input values:
• R, number of retransmissions to perform;
• W, maximum time window size, in milliseconds, to accomplish the R+1 transmissions of

each terminal packet resulting from the processing of a single data packet
In this document, data packet refers to packets whose format is according to the structure used
in the communication process between data generator and A.N.S., and are represented in blue
in all the diagrams. Also terminal packets refers to the structure used to communicate between
A.N.S. and stations, and the packets of this structure are represented in green in all the diagrams.
The nomenclature here stated will be used across all the document.
3.3 Wireless Connectivity Coverage and Frequency Planning

Aiming to provide a high compatible solution considering the large variety of marketed smart-
phones with different connectivity capabilities, we have based our solution in the usage of dual-
band access points (AP), which use both 2.4 and 5 GHz bands simultaneously. Consequently the
solution provides compatibility with value-line smartphones, which are typically only 2.4 GHz
compatible, but also with the more recent 5 GHz compatible devices. Equipments supporting 5
GHz band are also normally compatible with the 2.4 GHz one. In such case, the smartphone
automatically uses 5 GHz band when available, or asks the user to choose which band to use.
When possible, dual-band stations will automatically choose to use the 5 GHz band, as it is
less affected by interference phenomenons allowing also high-bandwidth connectivity.
The proposed solution can be implemented using common network equipment – APs and
switches – being necessary to adapt their capabilities to the dimension of the space and stations
specifications and quantity.
The number of APs needed for a given implementation depends on the number of simultaneous
stations each AP can handle. Typical values of simultaneous associations to a given AP vary
between 60 to 100, depending on their hardware capabilities and existing traffic pattern.
Considering Sala Suggia’s layout, and AP capacity constraints, we have decided to use 15 APs,
each one covering 2 zones, with a total average of 70 clients, whose operating channels are stated
in Figure 3.8. The radio-frequency planing lead us to the conclusion that in such scenario there
will be 5 APs working on each one of the three non-overlapping channels available in the 2.4 GHz
band. Such conclusion guided us to develop the software component presented in Section 3.4.
The radio-frequency planing for the 5 GHz band is not so critical as for the 2.4 GHz, as all the
19 channels available in this band are non-overlapping. Because our solution only had 15 dual-
band AP, each one operated in a distinct 5 GHz frequency band channel. Therefore co-channel
interference was not a aspect to consider when dimensioning the system’s 5 GHz operation. Nev-
ertheless, restrictions on the transmission power in this band was a concerning aspect. The 5 GHz
band is used for instance by weather radars and other environment-measure devices. Consequently,
a careless usage on the transmission power control is prejudicial.
3.4 Interference Minimization - Medium Access Mediator 43
Figure 3.8: Cell zones Layout with 2.4 GHz Operating Frequency Planning
3.4 Interference Minimization - Medium Access Mediator

Large scale wireless deployments, as the one targeted by our solution, are characterized has hav-
ing poor network performance due to the increased collision probability and interference phe-
nomenons. The primary issue when deploying a high-density WLAN is, as shown in Chapter 2,
interference, either ACI or CCI.
The proposed solution makes use of a middleware component – Abel Network Server (A.N.S.)
– by which the following objectives were pursued:
• Establish an abstraction layer between data generator component and the wireless network,
facilitating the performers content creation process. Content developers should be unaware
of network component implementation and stations connectivity aspects.
• Generate the appropriated zone-aware multicast stream based on the data generator output.
• Coordinate the medium access by APs working on the same wireless channel, preventing
collisions occurrence and undefined delay behavior, aiming to optimize the channel’s usage.
• Achieve a high resilient communication, through retransmission mechanisms, increasing

the successful delivery probability, contradicting interference negative effects. The retrans-
mission mechanism should allow each station to receive a maximum of R + 1 replicas of
each terminal packet.
• Time-critical and time-validity transmission behavior implementation, through which all the
R + 1 terminal packets transmissions occour inside the target transmission window W.
A.N.S. presents as an interface between wireless network and data generator components.
Data generator component runs on a remote computer, or possibly in multiple remote computers
working cooperatively, and is responsible for generating the commands related with the musical
concert content.
For the scope of this thesis, the multimedia content generated by the data generator is irrele-
vant. It must be assumed as an abstract identity able to generate data according to a given specified
data packet structure and to establish UDP/IP based communication with A.N.S..
Figure 3.9 presents an high level overview of A.N.S. architecture, and its major blocks in-
terconnections. A.N.S. implementation is based on nch + 1 distinct FIFO queues, plus the data
input queue where the data generator packets are firstly placed. Each one of the existing nch + 1
queues provides an interface to one distinct wireless channel, assuming the existence of nch non-
overlapping channels. Qq with q ∈ [1, nch ] is where packets bound for single zones or cell zones
are placed and Qsz is the queue to place terminal packets addressed to super zones.
Figure 3.9: High Level Representation of A.N.S.’s Architecture
From an architectural point of view, A.N.S. can be described by three major modules, as shown
in Figure 3.9:
• Receiver
• Dispatcher & Scheduler
• nch + 1 dedicated Consumers

When started, A.N.S. will read the content of a configuration file, which holds the information
related with each zone unique identifier (Zone ID), and their attributes, creating a map structure
called Zones Map. Through this structure, A.N.S. becomes fully aware on room’s organization, i.e.
which zones exist but also their identifiers, zone types, coverage AP and correspondent working
channel, VLAN segment and IP multicast group used to communicate with clients within that
zone. The VLAN identification number is used to establish connectivity with AP in distinct LAN
segments, and its usage will be clarified ahead in the current section. Table 3.1 shows an example
of such structure.
Table 3.1: Zones Map example
Zone ID AP Channel Zone Type Multicast IP Address VLAN ID

z1 1 Zone 1
z2 1 Zone 1
z3 2 Zone 1
z4 2 Zone 1
z5 n Zone One distinct IP address 2
z6 n Zone per each Zone ID 2
... from the address
z9 1 Zone range 224.0.0.0 2
z10 1 Zone through 239.255.255.255 2
z11 2 Zone 2
C1 1 Cell Zone 1
C2 2 Cell Zone 1
C3 n Cell Zone 1
S1 - Super Zone 1 and 2
The Receiver module establishes a communication channel with the data generator, proceed-
ing to the reception and validation on the data stream and control information. Thus, the received
data packets are placed in a FIFO queue, identified as data input queue, that acts as an interface
between the Receiver and Dispatcher & Scheduler modules. This procedure ensures that pack-
ets are processed by the Dispatcher & Scheduler according to their order of arrival from the data
generator, thereby meeting one of the system’s requirements.
The Dispatcher & Scheduler (D&S) module has a fundamental role to play, as it is responsi-
ble to translate each received data packet, to the resulting pairs of δ and terminal packets.
The δ value assigned to each generated terminal packet is a time duration in milliseconds,
used by the Consumers to impose a delay between each packet retransmission. The δ associated
to each terminal packet depends on the target transmission window W value and on the number of
packets to transmit by a given consumer per each transmission k ∈ [0, R], represented by σ . For
our particular implementation, which targets a maximum number R = 3, the δ values are assigned
according to the equations in Figure 3.10.
Figure 3.10: Formula for δ value calculation
Figure 3.11: Translation process abstract representation
As evidenced by Figure 3.11, the translation process implemented by D&S, is not univocal, as
one data packet can be addressed to an arbitrary number of zones, and even different zone types,
resulting in an arbitrary number of pairs. Ultimately a data packet can be addressed to all the
available zones. In that case, A.N.S. will broadcast the message to all the available zones, using
the minimum possible super zones needed to cover the entire room’s area, minimizing the number
of generated pairs, and consequently the number of packets crossing the solution’s network side.
Reduce the number of packets generated is a concerning aspect, since the solution is dealing with
time-critical data and more packets to process and send will lead to an inevitable delay increase,
as a result of a greater wireless medium usage.
The term translation is purposefully used to bring to light the two different packet structures
used across the solution. Both data packet and terminal packet structures somehow represent solu-
tion’s API. Both structures formats developed to assess our particular case scenario are presented
in Section 4.1. An example on the D&S translation process is shown in Figure 3.12, based on the
information available in Table 3.1.
Figure 3.12: D&S Process Characterization
Figure 3.12 presents a translation example of one data packet addressed to seven different
zones to the resulting pairs of δk and terminal packets, considering retransmission factor R = 3.
The information of data packet target zones, i.e. the list of target zone ID values, should be carried
by each data packet.
When a packet arrive at A.N.S., and after validated by the Receiver as being a data packet, it is
placed in the data input queue, waiting for being processed by D&S module. This, after signaled
by the Receiver, picks a data packet from data input queue’s head, and executes a pre-processing
step. Through this step D&S determines the number of terminal packets to each consumer’s queue
will be generated as result of the data packet translation process. The number of packets addressed
to each queue is represented by σq being q ∈ [1, nch ] the destination channel’s queue number or σsz
for super zones queue, per transmission or retransmission k, with k ∈ [0, R]. Having knowledge of
all σq and σsz values, A.N.S. is able to calculate the appropriated delta times δk , splitting the target
transmission time window W over all the terminal packets belonging to each queue accordingly.
Using the information contained in Zones Map, D&S is able to process and translate a given
data packet addressed to a specific zone ID, to the matching terminal packet, as it possesses all
the information related with that zone ID. Such information includes zone type it refers, which
can be a single zone, a cell zone or a super zone, the channel and the VLAN segment to whom
belongs the access point serving that zone and the IP multicast address used to communicate with
that zone. From the translation process results the generation of a pair formed by a delta time
δ and a terminal packet, for each zone the data packet is intended to. Those pairs are placed
in their appropriated channel queues, based on the destination zoneID access point’s operating
channel. Having enqueued all the pairs resulting from the translation process of a given data
packet, D&S notifies the consumers, triggering their processes. D&S module only picks the next
data packet from data input queue after all the terminal packets resulting from the previous data
packet translation have been sent, which happens when all the consumer’s queues become empty.
This way the order of reception by the stations is the same as the order of generation by the data
generator component, besides all the retransmissions which may occur.
Therefore, Dispatcher & Scheduler module has two primary functions. It acts as translator,
converting data packets placed in data input queue to terminal packets, and as a scheduler, placing
the terminal packets in the channel queues accordingly to the channel they are addressed, or in the
super zones queue, generating the delta time values at the same time. When placing the generated
pairs of delta time and terminal packet in their appropriated queue, D&S has in consideration
the number of retransmissions R previously configured in A.N.S.. Therefore, D&S’s translation
procedure of a given data packet will result in R + 1 terminal packets for each zone ID the data
packet is bound for, placed in one of the available nch + 1 queues, enabling the retransmission
behavior. The k-th + 1 transmission only occurs after all the packets related with the k-th have
been sent, resulting in a fair waiting time for all the stations, avoiding starvation or unfair delay.
From the analysis of Table 3.1, which represents an example on the zones information map
structure’s content, it’s possible to imply that each zone, identified by its unique zone ID, belongs
to a channel, and each channel has its own FIFO queue, leading to the existence of nch different
channel queues. Consequently we establish a direct relationship between the number of available
wireless channels and the number of FIFO queues used.
The value of nch is related with the Wi-Fi technology used to establish communication with the
clients. Depending on the used Wi-Fi technology, limitations on the number of non-overlapping
channels will always arise, as a result of the limited radio-frequency ranges available, and other
characteristics, like the bandwidth of each channel. Our approach allows the usage of multiple
available nch non-overlapping channels simultaneously, in a coordinated way, increasing network’s
efficiency.
The nch queues Qq , with q ∈ [1, nch ], are not limited in size, but their maximum size is given
by the following expression:
QqmaxSize = Nb. of zones belonging to Qq channel queue × (R + 1)
Likewise Qsz maximum size can also be derived from the next expression:
QszmaxSize = Total number of existing super zones × (R + 1)
On the other side Data input queue size is limited, in order to avoid data packets to accumulate
and lose their time-validity in the context of the performance. Such packet accumulation in this
queue may occur due to difficulties in proceeding to their processing with a higher cadence than its
generation. It can also occur due to an error at the data generator component, leading it to generate
an excessive amount of data packets, within a reduced time interval. If a limitation on data input
queue’s size was not implemented, the real-time requirement would be potentially compromised,
as all received data packets will be placed in it, and consequently processed by D&S, despite the
fact that their content was no longer relevance in the live performance’s context.
Every one of the nch + 1 Consumers follows the standard behavior, described in Figure 3.13.
Figure 3.13: Consumer’s processing sequence
Each one picks the pair from their queue’s head, and sends its terminal packet to the appro-
priate IP multicast address, through the virtual or physical NIC belonging to the network segment
where the stations which have joined the destination multicast group are present.
In order to know to which VLAN each packet has to be sent, which dictates the proper out-
put NIC, the consumer uses the information contained in the Zones Map, in the field VLAN ID
associated with each zone ID.
If the terminal packet is bound for a single zone or a cell zone, it is sent by its Qq consumer
through the A.N.S. NIC belonging to the same VLAN as the terminal packet destination AP.
Otherwise, if it is bound for a super zone, the Qsz consumer sends a replica of the terminal packet
to each VLAN the super zone is divided.
Lastly, the consumer waits for the time duration specified by the pair’s δ value before proceed
to the next pair in its queue.
This procedure is repeated by every consumer thread, until its queue become empty.
The Qsz consumer has a distinct behavior, when compared with the remaining nch consumers.
While the nch consumers work simultaneously, the Qsz consumer works in mutual exclusion with
the nch consumers, avoiding medium access concurrency issues. Figure 3.14 presents the A.N.S.
output as result of the sending procedure of the nch + 1 consumers. The diagram brings to light
simultaneous transmission by the nch consumers, but also the mutual exclusion mechanism im-
plemented between them and the Qsz consumer, as every time the latter is sending a packet, the
remaining consumers prevent their transmissions.
Super zones, despite having their own unique identifiers, are formed by grouping multiple
adjacent single zones. Therefore, if none mutual exclusion mechanism was implemented, medium
access concurrency issues could arise when sending simultaneously a terminal packet for a single
Figure 3.14: A.N.S. output over time
zone and a super zone. As super zones are formed by grouping multiple single zones, it is expected
that a given super zone uses an AP whose operating channel is common to some zone’s AP, and
so if no mutual exclusion is granted co-channel interference phenomenon will occur.
Such phenomenon could lead to two possible results. If both APs – A and B – working
on the same wireless channel, belong to each others contention domain, i.e. A ∈ SB and B ∈
SA , the terminal packet will suffer a transmission delay as a result of the CSMA/CA back-off
mechanism. Otherwise if, for instance A ∈
/ SB but B ∈ SA , which can occur due to distinct CCA
values between A and B, or as result of very distinct transmission powers from A or B, a wireless
collision could occur, increasing the packet’s loss rate. The interference problematic has been
described in Section 2.2.4.
Also packets bound for a super zone requires the simultaneous transmission over multiple
APs and it is expected that some of these operate on the same channel. To prevent undefined delay
behavior or eventual collisions by attempting to access the same wireless channel in an uncoor-
dinated way, the APs belonging to a super zone were grouped in APs operating on different and
non-overlapping channels, and each group is allocated to a distinct VLAN. Thus, when processing
a data packet bound for a super zone, A.N.S. will generate multiple terminal packets, each one
targeting all the VLANs the super zone is divided in.
In Figure 3.15, the process of sending a terminal packet to all STA belonging S1 , which is
divided into VLANs 1 and 2, is stated. The action of sending replicas of a single terminal packet
to all the VLANs forming a super zone using different NICs, either virtual or real, is made by the
Qsz consumer.
Figure 3.15: Super zones packets delivery VLAN based mechanism
The proposed solution makes use of the VLAN abstraction to address the medium access prob-
lematic for super zones’ particular case, as it has the advantage of allowing forward mechanism
to the appropriate LAN segment without complicated forwarding or routing rules, and generating
the least possible traffic. Also, packets’ forwarding process is performed by network hardware
(layer 2), and the contention procedure due to wireless medium access, is solved by the APs us-
ing the CSMA/CA mechanism, representing a considerable faster approach than any attempt to
implement a pure software based solution, again revealing the concern in provide the minimum
delay possible.
The wireless medium we are addressing is characterized as being limited by both noise and
interference, and also susceptible to losses resulting from collisions. To overcome this problem-
atic characteristic, and provide a high delivery probability, we have developed a retransmission
mechanism. Therefore lets consider only Q1 from Figure 3.12, shown in Figure 3.16, in order to
analyze some of the retransmission mechanism peculiarities.
Figure 3.16: Target transmission time window splitting procedure
The target transmission time window W is splitted across all the packets of each queue, con-
sidering R retransmissions as shown in Figure 3.16 example. From the expression presented in
Figure 3.16 used to determine the value of δk for the k-th (re)transmission, and considering that
∆0 = 0, we can postulate that the highest throughput occurs during the first transmission (k = 0),
as all the packets are sent immediately, giving to the stations the opportunity to receive the data as
soon as possible, minimizing the delay between generation, by the data generator, and stations re-
ception. The retransmissions, from k = 1 to k = 3, will then occur, to overcome possible losses in
some stations, which may result from collisions or bad reception conditions. The last pair placed
in each channel queue, for the k-th retransmission with k = R, has an associated delta time δ0 ,
allowing the consumer to be immediately available to process new upcoming terminal packets.
The transmission k = 0, and all the retransmissions from k = 1 to k = 3, have a time window to
occur, ∆k , which is divided by all the packets to be sent within that retransmission. As k increases,
the time window ∆k also increases, leading to a decrease in the throughput, and increasing the
successful delivery probability. The sum of all the delta times ∆k is equal to 95% of the target
transmission time window W, leaving 5% of free-time to accommodate delays, such the ones
caused either by back-off proceeding in CSMA/CA or by the mutual exclusion medium access
mechanism implemented between the nch consumers and the Qsz consumer.
3.4.1 a.bel Throughput Analysis
Now that the solution has been described, some considerations on its expected throughput become
relevant.
Therefore lets assume the data generator produces a number of data packets per second, based
on a factor β with β ≥ 0.1W according to the following expression:
1000
G= (packet/s) (3.1)
W +β
β is a constraint to consider, since the generation rate must be inferior to the consumption rate
by A.N.S., established by W . Otherwise data packets will be discarded by A.N.S.
Considering the implementation described in Section 3.4, A.N.S. transfer function is given by
the following expression:
W +β
ANSgain = (R + 1) × Z (packet/s) (3.2)
W
being Z = ∑nq=1
ch
σq + σsz , i.e. the number of destination zones of a given data packet.
The consumers implemented in A.N.S. send their queue packets to the STA, through a switch
which provides networking across all the AP.
Therefore the switch provides connectivity to each one of the available non-overlapping wire-
less channels – nch – and to an abstract channel reserved to super zones. Figure 3.17 shows the
abstract representation of the channels connected to the switch. Each circle represents one non-
overlapping wireless channel from the nch available ones, and the pentagon represents the abstract
super zones channel.
Figure 3.17: Wireless channels abstract representation
The super zones abstract channel is in fact a superposition of all the nch , since a terminal packet
bound for a super zone, will inevitably result in the occupation of the nch channels.
If we considered all the channels independent from each other, the ratio Rx between the number
of terminal packets which arrive to channel x and the total number of distinct generated terminal
packets Z would be represented by the Equation (3.3).
σx
Rchx = (3.3)
Z
But since all the traffic addressed to the abstract super zones channel will also overlap the
remaining nch , we have made an approximation, from which all the throughput generated to the
super zones abstract channel affects the overall throughput of the nch non-overlapping channels.
σx + σsz
Rchxapprox = (3.4)
Z
Therefore, the approximated throughput per channel x – Tchx – is given by the following ex-
pression:
Tchx = G × ANSgain × Rchxapprox (packet/s) (3.5)
3.5 Terminal Devices Network Configurations

Deploy a wireless network in large event venues, where everyone carries a mobile phone with
Wi-Fi connectivity, presents a great issue when considering the amount of traffic generated by
those devices, even without users intervention. We have carried out preliminary measurements,
where smartphones generate in average 2 packets per second. Those packets are primarily gener-
ated by social media applications, such as Facebook, new income email check events, messaging
applications, like Skype or WhatsApp, among others.
Our particular case scenario targets an audience of approximately 1000 people. From the fact
that each wireless channel is common to 5 AP, each one covering approximately 70 devices, and
considering 2 as the average packet generation per second and per device, the total average packets
per second would be 700.
Aiming to minimize undesirable terminal’s traffic generation, we have considered a network
configuration based on the following directives:
• Static IPv4 address configured based on ticket’s number and/or QR code, allowing an indi-
rect form of spatial localization;
• DNS servers 1 and 2 pointing to 127.0.0.1, preventing DNS queries generation;
• Gateway as 127.0.0.1 (optional and should be used carefully);
The assumption behind the proposed configuration was that, if terminal device network config-
uration addresses, namely DNS servers and gateway, pointed to the reserved localhost IP address
(127.0.0.1) its traffic would not pass over its wireless interface, thus preventing wireless medium
occupation.
Using the previous configuration model, a considerable traffic reduction has been verified, as
summarized in Table 3.2. For each case, the column marked with a ’*’ refers to the results obtained
from our particular configuration. The columns without any mark on it present the scenario results
where the equipment had acquired a default network configuration using DHCP. The collected
data also present scenarios with user interaction (w/ UI) and without user interaction (w/o UI).
Although promising, the described approach turns out to be problematic. Some devices ex-
perienced network association issues, and some of them flooded the network with ARP queries
3.5 Terminal Devices Network Configurations 55
Table 3.2: Traffic Reduction Experimental Results

Nexus 7 (w/ UI) Nexus 7 (w/o UI) Wiko (w/o UI) Samsung Mini S3 (w/o UI)
* * * *
Total Packets 926 142 459 30 366 51 589 19
Avg. packets/sec 2,814 0,41 2,1 0,126 1,65 0,218 1,873 0,078
Avg. packet size (bytes) 76,122 70,75 70,81 78,3 77,175 75,235 74,183 58,842
Overall Reduction (packet/s) 86% 94% 86% 96%
targeting 127.0.0.1 IP address, as a result of its configuration as device’s gateway. Such ARP
queries lead us to the conclude that Android’s IPv4 stack implementation does not distinguish
between IPs with a private network scope from others with a host scope. Figure 3.18 shows a
capture snippet where such problem is visible.
Figure 3.18: ARP flood problem - query to localhost IP
Consequently, an alternative approach have been pursued considered:
• Static IPv4 address configured based on ticket’s number and/or QR code, allowing an indi-
rect form of spatial localization;
• DNS servers 1 and 2 pointing to the previously assigned static IPv4, preventing DNS queries
generation;
• Device gateway equals to it’s own IP address;
Static IP address configuration have the advantage to grant client’s connectivity, without the
need of deploying a DHCP server, which operation could impact badly in the network perfor-
mance, due to the amount of packets generated during configuration handshake. Also, in an
environment such the one discussed in this solution, a DHCP server presents a potential point-
of-failure, which can jeopardize the system’s operation.
Apple’s SDK, used to develop iOS application for iPhone and iPad, do not allow network inter-
face configuration without explicit user intervention. Consequently, a DHCP server was deployed,
leasing valid network configurations only for iOS devices.
Chapter 4
Solution Implementation
4.1 System API Structures

To provide an efficient communication through all system’s components, the following two struc-
tures were defined. The packets’ structure format used in the communication process is important
to understand system’s operation. Figures 4.1 and 4.3 present, respectively, both data and terminal
packets schemes used in our case scenario. Above each field is presented its size in bits. Both
structures were defined using standard integer unsigned type 8-bits width – uint8_t – to prevent
memory alignment problems which could arise when transmitting the packets through sockets.
Such problems could derive from the multiple architectures with different endiannesses poten-
tially involved in the system’s components. Even the 16-bits length fields were built using two
8-bits length variables.
The ARM processors architecture, which is the predominant one on smartphones, is typically
little-endian, and so all the communication procedures using sockets should take into account such
characteristic.
Figure 4.1: Data Packet structure
A data block, as shown in Figure 4.2, is formed by a pair of two values, an ID and a command,
which generation and significance is related with the data generator system’s component, imple-
mented by Pd. The maximum number of blocks generated by Pd is 40, and so the Blocks[B] in
the data packet will present a maximum size of 80 bytes.
57
58 Solution Implementation
Figure 4.2: Block structure
The data packet structure is used in the communication process between Data Generator and
A.N.S., and their fields specifications are as follows:
• Type – establishes the carrier message type, from the several available possible types, which
will be presented ahead
• Nb. Zones (Z) – specifies the number of zones the data packet content is bounded for;
• Nb Data Blocks (B) – states the number of data blocks to send to each zone;
• Piece ID – as our solution was specifically designed to aim the Sala Suggia’s concert, this
field was used to allow the client’s terminal application to distinguish between the several
pieces which may occur;
• Data Packet Seq. Nb. – holds data generator packet sequence number, and is related with
the Piece ID field;
• Zones[Z] – variable length array of zoneID values, to whom the carried Blocks[B] content
data packet are addressed to;
• Blocks[B] – variable length data blocks array, representing the clients’ application payload.
This field carries the commands responsible to create the interaction potential;
Figure 4.3: Terminal Packet structure
The arbitrary number of terminal packets generated by A.N.S. during the already described
translation process of a single data packet, which are sent using IP multicast, are build according
to the structure shown in Figure 4.3. For all the terminal packets generated by A.N.S. during the
translation process of a given data packet, a copy of the content presented by the latter is placed
in the fields with common denomination.
Consequently, the following two non-common structures’ fields should be clarified:
• ZoneID – zone unique identification number to whom the packet is addressed. This field is
stated according to each on of the values presented by the data packet’s Zones[Z] field from
which it has resulted.
4.2 A.N.S. Architecture 59
• Network Seq. Nb. – specifies the packet’s network sequence number, and is stated by
A.N.S. during the packets’ generation process. This field allows the end-user application to
distinguish between replicated packets, since all replicas have the same network sequence
number.
Considering the maximum size of the Blocks[B] field, the UDP packet carrying the terminal
packet content will have a maximum size of 134 bytes.
Finally, we must clarify the defined packet types, as they are an integral part of the API.
The types are arranged in two different groups, Content related and Control types. The first,
characterized in the list below, are related with the concert’s organization, and allows the terminal
application to interpret each message in the context of the concert. The latter, which group is
formed by only one defined type – TYPE_RESET – provides a system recovery mechanism. When
a failure of any kind is verified, it allows the reinitialization of the client’s application current
network sequence numbers, allowing them to recover and proceed. Otherwise, A.N.S. will recover
from a possible failure with all zones network sequence numbers initialized to zero, and clients
would discard all the consequently generated terminal packets, as they were out of the expected
sequence.
• TYPE_START_CONCERT - sets the client’s application to the starting concert status
• TYPE_START_PIECE - sets the client’s application to the starting piece status
• TYPE_LOAD_PIECE - triggers the client’s application to load the piece specific content
files
• TYPE_END_PIECE - sets the client’s application to the piece ending status
• TYPE_END_CONCERT - sets the client’s application to the ending concert status
• TYPE_PD - is the type carried by all the common data packets, and refers to the informa-
tion which allows the interaction. The PD name in the type definition comes from the fact
that, for our particular case scenario, the data generator was carried by an application based
on the Pure Data (Pd) language
• TYPE_SELF_TEST - a special type, included only for debug purposes, which in fact is
used only by Pd Simulator. Terminal packets of this type will trigger a color change in the
client’s application
4.2 A.N.S. Architecture

A.N.S., which is a critical system component, due to the demanding requirements it must comply,
was written in C++, using UNIX standard libraries. The compilation was accomplished using
the GNU Compiler Collection (GCC) version 4.8.4, with options to support C++ 2011 standard
(-std=c++11) and the common POSIX Threads API (-pthread), targeting a 64-bit machine archi-
tecture. Such language and APIs were chosen given their maturity, that results from its vastly
usage and performance proofs over the years. Also, A.N.S. was developed targeting a little-endian
CPU architecture, in conformity with the default clients’ terminal devices endianess. As A.N.S.
was built using only standard libraries, it can be easily cross compiled to run on any operating
system and machine architecture compatible with the GNU C compiler. For instance MinGw [52],
a free and open source software development environment for Microsoft’s Windows OS, provides
a GCC port, thought which such compilation could be accomplished.
Over this section the complete A.N.S. processing algorithm will be described, using flowcharts,
presenting implementation’s specific details. Figure 4.4 describes the A.N.S. initialization process.
Figure 4.4: Initialization process

When started, A.N.S. will take two user input integer values, which will be used to define its
behavior. They are R, the number of retransmissions to perform for each terminal packet, and
W, the time window in milliseconds (ms) in which all the terminal packets resulting from the
translation process of a given data packet should be transmitted. Having the knowledge of both
values, A.N.S. is able to calculate the ∆k values for each transmission k with k ∈ [0, R], according
with expressions presented in Figure 3.16, whose usage is clarified further in the current section.
Considering the scope of our particular solution, and the solution’s specific requirements, A.N.S.
was designed to perform up to 3 retransmissions – Rmax = 3.
After both R and W have been defined, A.N.S. will process the data contained in the file hold-
ing the zones informations, typically a CSV file, and setup the Zones Map structure accordingly.
The CSV file holds a list of all the zones available, and each row defines the following zone’s
specific characteristics:
• zone ID
• Multicast IP Address
• AP number
• AP working channel
• VLAN ID
• Zone Type
The CSV entries related with super zones have their "AP working channel" field equal to zero,
as they do not present a unique working channel, as clarified earlier.
Zones Map makes use of the standard map container. The container’s template is typedef
pair<const Key, T> value_type. The container has an associative property, allowing the storage of
elements formed by a combination of two values: a key value and a generic type T mapped value.
A.N.S. stores all the available zones’ characteristics in a map container instance, according to the
following specific’s implementation’s template: typedef pair<ZoneID, ZoneInfo> ZonesMap.
ZoneInfo is a defined structure according to the following presented.
1 typedef s t r u c t {
2 / * W i r e l e s s o p e r a t i o n channel number * \
3 / * I n t h e 2 . 4 GHz band should be c o n s i d e r e d o n l y 1 , 6 o r 11 * /
4 u i n t 8 _ t channel ;
5 / * Access p o i n t number * /
6 u i n t 8 _ t apNumber ;
7 / * P o i n t e r t o queue where packets are placed a c c o r d i n g t o t h e i r t a r g e t channel * /
8 queue < p a i r < i n t , a b e l _ a p i _ h e a d e r _ t e r m i n a l > > * channelQueue ;
9 / * M u l t i c a s t IPv4 Address * /
10 i n _ a d d r _ t mcast ;
11 / * C u r r e n t zone ’ s network sequence number * /
12 u i n t 1 6 _ t networkSeqNb ;
13 / * Superzone t y p e − e i t h e r Colomn o r L i n e * /
14 char szType ;
15 / * Vlan i d * /
16 i n t VLANID ;
17 / * Number o f s e n t b y t e s * /
18 u i n t 1 6 _ t NbTxBytes ;
19 } ZoneInfo ;
Such container was used to allow an easier and efficient access to any mapped ZoneInfo in-
stance, holding each zone informations, using ZoneID as key value.
After completed the Zones Map initialization process, A.N.S. knows the number of distinct
channels used – nch – and so starts D&S module thread and nch + 1 consumer threads, proceeding
to the initialization on the receiver’s operation, whose description is stated in Figure 4.5.
Figure 4.5: Receiver component process

Receiver starts by opening an UDP/IP socket, from which the connection within the data gen-
erator component will be accomplished. The receiver’s socket monitoring operation was imple-
mented in a non-busy waiting way, using the select() function from Linux <sys/select.h> library.
When a packet arrives to the previously opened receiver’s socket, is checked to verify if it con-
forms with the data packet established structure, to discard eventual communication errors. If
the type of the received data packet is not one of the sytem’s API defined types, or the packet is
corrupted, it is dropped and receiver returns to its socket’s monitoring process. Otherwise the data
packet is placed in the data input queue. The data input queue’s access procedure ensures mutual
exclusion, through the usage of mutexes, as this queue is shared between both receiver and D&S
modules, both implemented using dedicated threads. If no mutual exclusion access to data input
queue was granted, the commonly known producer-consumer race condition could arise.
Data input queue’s accessing procedures represent a critical section, and consequently pro-
ducer (receiver) and consumer (D&S) accessing procedures must be synchronized. Generally, in
software engineering mutual exclusion access to shared memory structures is achieved through
some form of synchronization primitives, such as mutexes, semaphores, monitors, among others.
Our particular implementation makes use of single standard mutex associated to data input queue
accessing procedures. Before taking any action on the data input queue shared structure, receiver
and D&S must acquire the mutex ownership, releasing it after finished their operations. Both
ownership acquisition and release procedures uses respectively the functions mutex_lock() and
mutex_unlock(), whose atomicity is granted.
After placing a data packet in the data input queue the receiver notifies the D&S, thus inform-
ing that a new data packet is waiting for processing. The notification procedure is made using
POSIX semaphores.
A.N.S. being a time-critical application, has a thread based implementation, to allow a more
fast and efficient processing, taking advantage from the increasingly common multi-core CPU’s
architectures. Considering the potential large number of threads implemented – nch + 1 consumer
threads, a main/receiver thread and a D&S thread, resulting in a total of nch +3 threads – busy wait-
ing operation was not possible, or at least, not recommended. Given that, threads synchronization
mechanism was accomplished using semaphores, avoiding threads busy-waiting behavior.
The D&S module is described in Figures 4.6 and 4.8 and ??. As shown in Figure 4.6 it is
constantly waiting for receiver’s notifications, which are accomplished through the semaphore
sem_dispatcher. When notified, it starts processing the new arrived data packet, only if all the
consumer queues have become previously empty (Tpackets = 0). Otherwise it will wait until such
condition occurs, or until a established maximum waiting time expires. This aspect, is of extreme
relevance, and aims to fulfill one of the solution’s requirements, as we will clarify further later.
Figure 4.6: D&S component process – overview

When notified, and if all the consumer queues are empty, it accesses the data input queue
through the mutual exclusion mechanism, catching the data packet present on its head position.
Then it performs a pre-processing sequence, as described in Figure 4.7, to determine the number
of terminal packets to each consumer queue as result of the data packet translation process – σq
with q ∈ [1, nch ] for channel queues and σsz for super zones queue.
Figure 4.7: D&S component process – data packet pre-processing
This process also accounts possible invalid ZoneID values in the Zones[Z] field of data packet’s
structure setting σinv accordingly. During this pre-processing interpretation process of data packet’s
Zones[Z] field, at every valid ZoneID occurrence, i.e.the ZoneID value present in Zones[Z] matches
a existing key value in the Zones Map structure, its network sequence number is incremented. Dur-
ing this step D&S uses the value Z, contained in the data packet’s "Nb Zones" field, to know the
length of the Zones[Z] array, over which it will iterate. Knowing all the σq , σsz and σinv values,
D&S executes the following calculation:
n
Tpackets = (R + 1) × ( ∑ σq + σsz − σinv ) (4.1)
q=1
Tpackets is an atomic type integer variable, shared between the D&S and all the nch + 1 con-
sumers, through which it is able to indirectly verify the consumers queues sizes. The need for such
variable will be clarified ahead.
After set Tpackets value, D&S starts the pairs generation and process according to Figure 4.8.
Figure 4.8: D&S component process – pairs creation and enqueue procedure
Once more D&S iterates over the data packet’s Zones[Z] array, this time generating a pair of
δk and terminal packet for each valid ZoneID. Notice that, as exemplified in Figure 3.16, δk = σ∆qk
for all the packets within the k-th transmission, with exception for the last packet, whose δ value is
δk+1 = ∆σk+1q
. The generated pairs are placed in their appropriated consumer queue’s, based on the
queue reference available at the ZoneInfo structure mapped in ZonesMap by the terminal packet’s
ZoneID. This process is repeated until k = R.
Completed the generation and queue placement process of pair instances, D&S notifies all
the consumer threads. Once more the notification is accomplished using semaphores. Each con-
sumer has its own semaphore, which in addition to prevent busy-waiting, also holds the number
of packets available in each consumer’s queue.
After completed the consumer’s notification procedure, D&S thread blocks, using Tpackets as-
sociated to a conditional variable locking mechanism. More specifically, D&S acquires the own-
ership of a std::unique_lock<std::mutex>, and executes a waiting procedure, on a condition as-
sociated to the acquired mutex. In our implementation, the waiting procedure was implemented
using the wait_for() operation, which blocks the D&S’s thread until the condition associated with
the condition variable is met or until a specified timeout duration. For our implementation, the
condition to be verified was Tpackets = 0, meaning that all the previously created pairs have been
consumed. The timeout duration value was set up to 1.1W , allowing the accommodation of delays
associated with the consumers thread’s synchronization mechanism.
Tpackets associated to a conditional variable locking procedure has been implemented targeting
three fundamental goals. First, D&S thread should not work on a busy-waiting manner. Secondly,
one of the system’s requirements was to keep unchanged the data packets generation order.
Therefore, through the previously described procedure, D&S thread will only resume and initiates
processing the next data packet, after the consumption of all the previously generated pairs. Third,
it presents an efficient approach by which the D&S becomes aware of the consumer’s queues size
status without the need of constant verification.
Each nch channel queue consumer thread has it own semaphore, semq , and a mutex mutexq ,
with q ∈ [1, nch ], whose process is described in Figure 4.9.
Figure 4.9: Channel queue consumer process

The super zones consumer thread has also its own semaphore, semsz , and can access and lock
the others nch consumer’s mutexes as its process description is illustrated in Figure 4.10. Is through
this configuration that mutual exclusion between the nch consumer threads and the super zones one
is accomplished, preventing wireless collision occurrence or unpredictable packet delays.
Figure 4.10: Super zones consumer process

The broadcast sending routine implemented by the super zones consumer process is described
in Figure 4.11.
Figure 4.11: Broadcast sending routine
Before proceed with the explanation on the consumer’s threads process, a clarification has
to be made on the socket’s implementation. Each consumer thread has at its disposal two sock-
ets, whose descriptors are created to perform IPv4 (AF_INET) domain communications, using
UDP(SOCK_DGRAM) semantics. The computer on which A.N.S. should be installed, must have
as many NICs, either physical or virtual, as the number of VLANs needed for the specified sce-
nario. In our scenario’s specific implementation, were considered two LAN segments.
After declared, each socket is binded to each one of the two available distinct NICs, using the
following code snippet:
1 i n t socketFd ;
2 s t r u c t in_addr eth_iface_address ;
3 i n e t _ a t o n ( "VLAN i n t e r f a c e IP i n quad−d o t t e d n o t a t i o n " , &e t h _ i f a c e _ a d d r e s s ) ;
4 s e t s o c k o p t ( socketFd , IPPROTO_IP , IP_MULTICAST_IF , &e t h _ i f a c e _ a d d r e s s ,
5 sizeof ( eth_iface_address ) ) ;
If only one socket was considered per each consumer, and given that all the consumers are
expected to generate packets addressed to clients present in all the available LAN segments, a
socket configuration would have to be made, using setsockopt() function, before every terminal
packet’s transmission, setting it to the proper outgoing interface. Such approach will inevitably
lead to an increase in A.N.S. processing delays. Furthermore, our approach, which associate each
consumer’s socket to a concrete interface, prevents the generated multicast traffic of being affected
by possible OS internal routing procedures. Consequently all the multicast traffic generated in
each consumer’s socket is sent from the specified interface. For instance, if IP_MULTICAST_IF
option in socket’s configuration is not set, all multicast transmissions are performed through the
computer’s default interface.
Its also important to ratify that both nch channel queue consumers and super zones con-
sumer sending procedures are made through the function SendToClients() whose definition goes
according to the following:
1 i n t SendToClients ( i n t socketFDVLANid1 , i n t socketFDVLANid2 , ... ,
2 i n t socketFDVLANidm ,
3 ( s t r u c t so c k a d d r _ i n * ) dest_IPMcast_addr ,
4 t e r m i n a l packet TP , s i z e o f ( TP ) ) ;
Generically, this function sends a copy of the terminal packet instance, through each one of the
m socket’s file descriptors passed by argument, using the destination IP multicast address specified
in the sockaddr_in structure. Each socket file descriptor, passed as argument, should be binded to
an interface belonging to each one of the scenarios’ available LAN segments. SendToClients() act
as a wrapper to the sendto() function included in the <sys/socket.h> header.
Each consumer thread waits for D&S’s notification through its own semaphore, semq . As
soon as it is notified, locks its mutexq , and picks a pair <δ,TP> instance from its queue’s head.
To know the IP multicast and the corresponding VLAN to which the TP instance is intended,
the consumer accesses Zones Map structure using the TP’s ZoneID field value as key. Knowing
both VLAN ID and IP multicast attributes of the destination ZoneID, the consumer is able to
invoke the function SendToClients(), passing to it the destination VLAN socket descriptor, the
destination zoneID IP multicast, the terminal packet instance and its length. The length value
is used to verify if the sending process was accomplished successfully, and is merely used for
statistical purposes. Immediately after sending the terminal packet TP, consumer removes the pair
instance from its queue head. Then it decrements the atomic variable Tpackets , releases its mutex
and suspends its process for the time duration in ms stated in the sent pair δ value. Every time
Tpackets is decremented, D&S module is notified, allowing it to resume its process if the condition
Tpackets = 0 arises.
The super zone consumer’s process behavior depends on the TP’s target super zone type –
??. As mentioned before, our solution differentiates two types of super zones, column and line,
according to Figure 3.6. This is fundamentally because all the APs belonging to a line super
zone, which are three, are all inside the same VLAN, as three are also the number of 2.4GHz non-
overlapping channels available. By contrast, a column super zone is formed by 5 APs, grouped in
the two available distinct VLANs, as shown in Figure 3.15.
The super zones consumer initial procedure is similar to the one used by the remaining nch
consumers, as it waits for D&S’s notification on its own semaphore, semsz . The difference regards
the mutex operation mechanism. The super zones consumer, after notified by D&S, only proceeds
to the sending process after locking all the nch consumer’s mutexes. Consequently, when super
zone’s consumer thread is during the process of sending a terminal packet, all the remaining nch
consumers are suspended. Then the sending process depends on the super zone type. So, when
considering a line super zone type, super zones’ consumer acts exactly according to the process
already described for the nch consumers. For column super zone type, the super zones’ consumer
will invoke the SendToClients() function passing always both their socket descriptors, among the
remaining arguments needed: IP multicast address, terminal packet TP instance and its size in
bytes. This derives from the fact that one terminal packet addressed to a column super zone should
inevitably be sent to the two available VLANs in which the column super zones are arranged. Once
the terminal packet instance is sent, the super zones consumer removes the pair instance from its
queue’s head, decrementing the atomic variable Tpackets accordingly. The mutexes unlocking, after
which the super zones process suspends itself for the time value stated in the sent pair δ ms, is
made in random order, thus avoiding predictability when resuming the nch consumers threads.
In Figures 4.4 to 4.6 A.N.S. reset procedure is mentioned, which was implemented to allow
system’s recovery in case of failure. When triggered this procedure, as described in Figure 4.12,
will generate a broadcast TYPE_RESET data packet message, which is then treated by the D&S
module accordingly. This message makes client’s application to clear their network sequence
counters, preparing them to receive and process new terminal packets, which otherwise would be
rejected. As a result of such procedure, A.N.S. also set to zero their internal network sequence
number, related with each zone, stored in Zones Map structure. Preventively this procedure is
always triggered when starting A.N.S.
Figure 4.12: Reset procedure

4.3 Pd Simulator
During the solution’s development process there was a need to develop an application to assess
if all the system’s components were working as expected. The simple and most reliable way to
implement such debugging software were simulating a situation as closely as possible to the Sala
Suggia’s particular case scenario. Consequently a GUI application, based on the Sala Suggia’s
spatial organization and AP locations, were developed.
The application, called Pd Simulator, was written in C++ using Qt4 framework for GUI sup-
port. It allows the simulation of data generator component, according to the user’s input, through
buttons, check boxes and some input numerical fields. The user could choose an arbitrary number
of zones and super zones, and then Pd Simulator will build the data packet according to the API
structure presented in Section 4.1, sending it through localhost to A.N.S.. Although being devel-
oped to be used in the same machine running A.N.S., it could be easily deployed in any computer
in the same LAN as A.N.S..
The data packets generated by Pd Simulator has a Blocks[B] field 80 bytes long, which con-
forms to 40 blocks, the maximum defined according to our solution’s requirements, for our partic-
ular scenario implementation. Consequently, the size of each terminal packet is 130 bytes.
A.N.S. should perform according to the received data packet, translating it to the resulting
terminal packets, which are then sent to their target stations. By doing so, it was possible to test
and validate all system’s components, from the data generator to the terminal client’s application,
passing by A.N.S. and the network hardware equipment.
Figure 4.13 shows the Pd Simulator graphical user interface (GUI).
Figure 4.13: Pd Simulator GUI

4.3 Pd Simulator 75
Figures 4.14 and 4.15 presents Pd Simulator detailed usage procedures, whose major function-
alities goes according to the specified in the list below.
(A) send a message to one of the available 30 zones, by pressing the correspondent zone button,
individually;
(B) send a message to one of the available 15 cell zones;
(C) send a message to one of the available 6 columns super zones
(D) send a message to one of the available 5 lines super zones
(E) change the number of generated consecutive messages;
(F) set the delay, in milliseconds, between each consecutive generated message;
(G) send a message to an arbitrary number of zones and zone types (zone, super zone or cell
zone), according to the user’s selection;
Figure 4.14: Pd Simulator usage - part 1
Figure 4.15: Pd Simulator usage - part 2

4.4 XML Configurations File Generator

As mentioned before, unlike Apple’s iOS, Android OS allows the network interface configuration
to be made through application, without user’s intervention. In order to take advantage of such
capability, aiming to reduce the generated traffic by client’s, we have provide each Android device
a specific network configuration. After having tested several possible configurations, and accord-
ing with the results from Section 3.5, we have concluded that point the both DNS addresses and
gateway to the client’s self IP allows a considerable traffic reduction – client’s IP = DNS1 = DNS2
= GW.
Consequently there was a need to create a configuration file to provide each client its specific
configuration. To do so, a XML file generator was developed, which creates a configuration to each
terminal identified by its room seat. Each client specific file was downloaded to the correspondent
client terminal device during the ticket’s validation process. Such process was based on a distinct
QR Code printed in each ticket. The QR code provides an encrypted pointer to the specific ticket’s
seat configuration file URL remote’s server location.
4.5 Network Infrastructure

When implementing IP multicast based communications over wireless, as for the case of our
implementation, some considerations need to be taken into account to prevent a network flood with
multicast traffic. Common implementations makes use of IGMP snooping capabilities, described
in Section 2.4.2.2, to prevent that all the multicast traffic present in a given LAN segment to be
transmitted to the wireless medium through the switch attached APs.
Although the switch backbone equipment used in our solution to connect all the APs has IGMP
snooping capabilities, such functionality was not considered in the network hardware component
design as it could lead to a potential deep performance and reliability decay.
In our solution we want to assure that each AP only sends packets whose multicast groups
destination IP multicast are according to the zones it covers. For instance, the AP represented in
figure Figure 4.16 should only allow the transmission of multicast packets addressed to zones z15
e z16 , cell zone C8 , column super zones S3 and S4 and line super zone S9 , thus preventing medium
occupation with packets irrelevant to its associated clients.
4.5 Network Infrastructure 77
Figure 4.16: Zones coverage by AP belonging to cell zone C8
If we have used IGMP snooping switch functionalities, and if a client associated to cell zone’s
C8 AP joined other multicast group than the ones related with their own zones, it would make the
switch to forward the wrong multicast stream to its AP.
Therefore in our specific implementation we have disabled switch IGMP snooping capabilities,
and established a direct relation between each IP multicast and its switch output physical interface,
where the desired AP was connected. The same desired behaviour could be accomplished using
other approaches such as ACL rules, associating each AP to a specific ACL group.
Chapter 5
System Performance Analysis
This chapter’s purpose is to provide an in-deep analysis on system’s behavior. To accomplish

meaningful values, the tests were performed in a testbed, using off-the-shelf hardware equipment
compatible with the IEEE 802.11n standard. The hardware equipment specifications are resumed
in Appendix B.
The tests performed are organized in two categories, intra zone and inter zone tests, and so
this chapter present one section per each.
5.1 Methodology
When considering wireless networks, its characterization is made from the analysis of three as-
pects, namely throughput, transmission delay and packet loss rate. Having into account the pur-
sued system requirements and the real-time traffic characteristics, specifically the time-critical
and time-validity packet transmission, we have developed a test environment wherein the evalua-
tion of such requirements was made.
Our analysis will focus in the transmission delay between the data generator component and
the client STA application, as this dimension is the most critical when dealing with real-time
traffic, since it impacts on the user’s experience. For that purpose we have carried several tests
using the testbed presented in Figure 5.1.
Figure 5.1: Delay testbed layout
79
80 System Performance Analysis
The generic testbed topology consisted in four blocks. A desktop computer running A.N.S.,
an arbitrary number of AP each one providing network access to a single STA, STAs representing
the clients devices, and a switch used to interconnect all the APs with the desktop computer.
The switch configuration was performed according to the established in Section 4.5. The AP’s
transmission power was set to 0 dBm (1mW).
In the testbed layout from Figure 5.1, the desktop computer is represented by the major black
box running A.N.S., where was also deployed the data generator and data logger applications.
The tests main objective was to assess the delay between the generation of a data packet by
data generator and the reception of the resulting terminal packets in STA, denoted by αapp . There-
fore, each data packet generated by data generator component was tagged with a 1µs precision
time-stamp, and passed to A.N.S. where, after translated to the correspondent number of terminal
packets, was sent out to the network equipment providing STA connectivity.
In this setup, the STA were implemented using a common laptop computer, equipped with a
WLAN IEEE 802.11n compatible interface – see Appendix B – and a LAN IEEE 802.3 gigabit
interface. Each STA was running a software designed to join a specified multicast group on its
WLAN interface, and immediately forward all the captured multicast packets thought its LAN
interface. The forwarded packets were consequently received on the same machine where they
were primarily generated, on which the data logger calculates the time difference between the
generation time, carried by each packet, and its arrival time. Such time difference represents the
packet’s round-trip time (RTT) – PRT T . PRT T can be approximated by the sum of two major delay
components, αapp and αfw , where αfw can be assumed constant and measured using common
software as the ping utility.
As a result, we can derive the value of αapp , from the following expressions:
PRT T ≈ αapp + α f w = A
So:
A = αapp + α f w
and considering:
Avg. Ping RTT LAN
αfw ≈
2
with Ping RTT Avg. value determined for 130 bytes long packets, then:
αapp ≈ A − α f w
In our testbed both A.N.S. and data logger components have their own dedicated Ethernet
NIC, thus avoiding communication concurrency.
In order to implement a real case scenario, we have defined a test data packet, according to the
structure settled in Figure 4.1, addressed to 8 zones, single zones z1 to z6 and line super zones S7
and S8 . Considering these target zones, all the consumers will had two packets to send per each
new data packet, thereby performing a balanced operation among each other.
5.1 Methodology 81
During the tests A.N.S. was defined with nch = 3, that resulted in 3 channel queues, to conform
with the number of 2.4 GHz WLAN non-overlapping channels. Besides, it was configured with a
target transmission window of W = 100 ms and a retransmission factor R = 3.
As a consequence for each test data packet generated, the nch + 1 = 3 A.N.S. queues will have
a total of 8 terminal packets each – 2 distinct zones terminal packets per transmission multiplied
by R + 1 = 4 since R = 3 – resulting in a total of 32 terminal packets sent.
Figure 5.2 presents a detailed processing description of a single test data packet by A.N.S.. As
a consequence of translation and enqueue proceeding by A.N.S., terminal packets are placed inside
queues Q1 , Q2 , and Q3 , according to the channel they were addressed to, respectively channels
1, 6 and 11, or in Qsz for the case of super zone addressed packets. In each queue are shown 2
terminal packets, addressed to distinct zones, and its retransmissions k with k ∈ [0, R].
Figure 5.2: Representation of the translation and enqueue process by A.N.S. of a single test data
packet
Figure 5.3 shows a capture on the A.N.S. ouput NIC, for the translation processes described in
Figure 5.2. Therefore a total of 32 terminal packets are visible, addressed to their zoneID specific
IP multicast. From its analysis the following assumptions can be made:
Figure 5.3: A.N.S. output NIC capture, resulting of one test data packet translation
1. Consumers are able to send all their packets, including retransmissions, inside the defined
maximum transmission window W .
2. The transmission and recurring retransmissions of each terminal packet are interleaved.
3. The nch consumers work simultaneously but in mutual exclusion within super zones con-
sumer.
4. The unpredictability on the super zones consumer mutex unlocking procedure is visible, as
the first terminal packet occurrence following a super zone’s varies.
Such conclusions are only valid when restrictively considering the A.N.S. output NIC, and
do not reflect possible delays introduced by downstream components, namely the network equip-
ment and medium access mechanisms. It’s fundamental to verify how this perfectly temporally
5.1 Methodology 83
characterized sending procedure is affected by wireless medium occupation and accessing mecha-
nisms, namely CSMA/CA back-off procedures, and their impact on the delay of terminal packets.
In order to characterize the system as a whole, we have carried tests based on the testbed layout
presented in Figure 5.1.
For performance characterization purposes Figure 5.4 shows a capture on the A.N.S. ouput
interface, in which the data packet used was the same as the one defined for tests, but in which
the line super zones S7 and S8 were replaced by column super zones S1 and S2 . From its analysis
is visible the super zones consumer behavior, which sends two replicated terminal packets, one
for each of the VLANs where the super zone is arranged. The elapsed time between sending of
both replicas addressing S2 , which is 18 µs for its first transmission (K = 0), is highlighted. This
time interval is in the order of magnitude of ∆ = t1 − t0 values, shown in Figure 3.15. Appendix A
shows the complete capture.
Figure 5.4: A.N.S. Output NIC Capture shown super zones terminal packets transmission
The reason why column super zones were not considered as targets during the test scenario,
was because it would cause an unbalanced consumer’s threads operation. For each terminal packet
addressed to column super zones placed in Qsz , its consumer would have to send two replicas, one
for each VLAN. On the other hand, Qq consumers always send one single terminal packet per
each available in their queues.
As already detailed, each data packet sent by the data generator is processed and forwarded
by A.N.S. R+1 times for each resulting terminal packet. From here we have collected to different
delay times:
• Application layer delay - Time it takes to receive, in the STA’s forwarder application, the
first of four (R + 1) terminal packets from each data packet produced by the data generator.
• Network delays - Time it takes to receive, in the STA’s forwarder application, any of the
four terminal packets resulting from each data packet produced the data generator.
The collected experiments data presentation and analysis is made in the current chapter, using
two types of delays histograms, with a bin resolution of 1 ms.
• Application delays histogram - represents application layer delays;
• Network delays histogram - represents the network delays;
The application delays histograms will only reflect the delay of the first occurrence of each
terminal packet, as the remaining ones are redundant from the application’s perspective. Con-
sequently, in the absence of losses, the application delays sample size will be exactly 1⁄4 of the
network delays one. Also in network delays histograms will always be represented the applica-
tion’s delay empirical CDF, through an orange curve.
5.2 Intra Zone Tests
Figure 5.5: Intra zone delay measurement layout
The intra zone test procedure consisted in the generation of 10 000 data packets using Pd Simula-
tor, acting as data generator component, which was configured to generate one data packet every
120 ms interval.
Considering the Equation (3.5), whose mathematical deduction has been presented in Sec-
tion 3.4.1, the throughput generated per each channel x : x ∈ [1, nch ] with nch = 3, considering the
number of destination zones of the data packet Z = 8 equally distributed across all the available
queues, W = 100, β = 0, 2W and R = 3 is 21440 bytes/s.
5.2 Intra Zone Tests 85
Figure 5.5 shows the same testbed presented in Figure 5.1. However is now identified with the
specific AP in channel 6 and a STA associated with the single zone z3 . Consequently the described
methodology is maintained, with the particularity that in LAN with the switch is only connected
one single AP operating in channel 6, and its associated STA, which belongs to IP multicast group
of single zone z3 .
Reference Scenario
Figure 5.6 presents the network delays normalized histogram, and its empirical cumulative dis-
tribution function (CDF). This experiment’s data resulted from an almost-optimal transmission
and reception conditions, i.e. reduced wireless channel usage by neighbor equipments, as their
were carried at night. STA receiver reported an average RSSI ≈ −60dBm. Moreover these re-
sults are used as reference values with which the remaining results from other experiments will be
confronted.
Figure 5.6: Network delays histogram - reference
The histogram from Figure 5.6 presents four predominant modes, which are directly related
with the factors R and W. Since we configured R=3, is expected to be plotted 4 histogram modes
that represent the network delay of each retransmission.
From the analysis of the network delay histogram in Figure 5.6 we can derive the following
conclusions:
• The four histogram modes values relative to the retransmissions k with k ∈ [0, R] are respec-
tively 1, 9, 31 and 71 ms;
• The CDF curve presents a step behavior, in which the step has a dimension of 25% of the
total sample, as we are performing 4 transmissions; The CDF shape reveals the predomi-
nance of the histogram modes, as it increase is almost instantaneous in the vicinity of each
one of the four modes;
• All the packets have been received within the established target transmission time window
W = 100 ms;
Our test STA is associated with the single zone z3 , whose packets are placed in queue Q2 .
Considering the procedure and equations described in Figure 3.16, and given that for our test data
packet, the total packets per transmission in Q2 is σ2 = 2, we can try to get approximate values on
the network delays histogram modes.
Being Mk the mode value associated to the each terminal packet addressed to single zone z3
and k the packet’s transmission index with k ∈ [0, R], our test STA theoretical mode values are as
follows:
First mode – M0 = δ0 = 0ms.
Second mode – M1 = δ0 + δ1 ≈ δ1 = 7, 5ms.
Third mode – M2 = δ0 + δ1 + δ1 + δ2 = ∆1 + δ2 = 30ms.
Fourth mode – M3 = δ0 + δ1 + δ1 + δ2 + δ2 + δ3 = ∆1 + ∆2 + δ3 = 70ms.
Table 5.1 summarizes the mode values:
Table 5.1: Histogram mode values in ms - test vs theoretical
k index Test Modes Values Theoretical Modes Values Difference

0 1 0 1
1 9 7.5 1.5
2 31 30 1
3 71 70 1
From data analysis, the difference between the value of the mode obtained from the testbed
scenario and its theoretical value is arround 1 ms. From such peculiarity the following conclusion
can be made: the delays introduced by A.N.S., network equipment as the switch, the CSMA/CA
mechanism presented by the AP and the STA processing is, in average, 1 ms.
More generally, the modes on a network delays histogram can be described as a function of
W, ∆k and σc , as follows:
k−1
∆k
Mk = ∑ ∆i + σc (1 + γ ) (5.1)
i=0
where:
R is the number of defined retransmissions in A.N.S.

Mk is the histogram mode associated with the transmission k, with k ∈ [0, R]
σc is the number of packets to transmit in channel c per each k-th transmission
γ represents the number of packets belonging to k-th transmission that has been already sent
with:
∑Rj=0 ∆ j
W= (5.2)
0, 95
At application level, only the first occurrence of each packet is considered, being discarded all
the replicated ones based on their sequence numbers. Consequently, because these results were
gathered in non-loss conditions, the application delays histogram in Figure 5.7 is given by the first
mode presented by the network delays in Figure 5.6.
Figure 5.7: Application delays histogram - reference
In the plotted empirical CDF in Figure 5.7, 95% of the terminal packets were received within
a delay below than 5 ms. Also, the application delays histogram presents an average delay value
of 3,27 ms and a statistical mode equal to 1,07 ms.
Highly-Attenuated STA Receptor
Foreseeing the possibility of clients with poor reception conditions, either due to hardware limi-
tations or for being in the AP’s cell periphery, we have conducted a test where the STA receiver’s
reported a RSSI below -90 dBm. An RSSI value lower than this is difficult to accomplish, as it
leads to unexpected STA dissociation from its AP. To implement such test scenario we have placed
the STA, equipped with an antenna attenuator of 23dB, at a distance of 18 m from its AP. The STA
antenna gain of 4 dB was removed.
Figure 5.8: Network delays histograms - reference vs attenuated client
Figure 5.9: Application delays histograms - reference vs attenuated client

Although the increase of 5.04 ms in the average delay, when compared with the reference sce-
nario, from the analysis of both network and application delays histograms, Figures 5.8 and 5.9,
we can conclude that even at such highly-attenuated reception conditions, the impact on the appli-
cation delay is negligible. In this test scenario 95% of the terminal packets were received within a
delay below than 7.2 ms, as seen in Figure 5.9, once more revealing a degradation when compared
with the reference scenario. The statistical mode value, i.e. the value with more occurrences in
the sampled data, is ≈1 ms, very similar to the obtained in the reference scenario. Nevertheless,
the increase on the standard deviation value, which is four times the obtained from the reference
scenario, clearly shows that the sampled application delays are more spread, which can result
from STA’s difficulties in proceed with the decoding of the data in such reception conditions, with
consequences in the delay increase.
Operating Channel in Saturated Conditions

In the context of the proposed solution it is important to realize the impact on the delay when op-
erating in highly saturated channel conditions. Its very common the existence of multiple WLANs
operating in the same channel, which can result in a substantial amount of traffic being generated
by neighbor terminals using them. In order to assess the effects of co-channel interference, we
have deployed a new test scenario using two extra-system APs, operating in the same wireless
channel as the AP supporting the system’s testbed. Each AP provides connectivity to a pair of
wireless devices, with one acting as client and the other as server, as seen in Figure 5.10. Between
each client-server pair a UDP packet stream with a target bandwidth of 100 Mbit/s was established
using using iperf utility [53].
Figure 5.10: Same channel saturation layout

Figure 5.11: Network delays histograms - reference vs saturated operating channel condition
Figure 5.12: Application delays histograms - reference vs saturated operating channel condition
Although the target throughput of 100 Mbit/s in both iperf clients, their reports indicated a
maximum bandwidth usage of approximately 33 Mbit/s each. In this scenario, and as a conse-
quence of the wireless medium occupation, the CSMA/CA back-off mechanism effects on the
delay becomes evident, through the exponential decay verified across the histograms of both Fig-
ures 5.11 and 5.12. Such effect is also visible in the network delay CDF curve in Figure 5.11,
which presents a smother increase, thus revealing the network delay sample data spreading over
the transmission window. The application delays histogram from Figure 5.12 shows a average
delay six times greater than the seen in the reference scenario. Even so, nearly 90% of the packets
arrive at the application with a delay less than 40 ms. The CDF curve indicates a delay of 75 ms
for 95% of the application delays sample size, which is still inside the target transmission window
of 100 ms.
Operating Channel with both Adjacent Channels in Saturated Condition
In this test we have followed a replica on the previous scenario, with the difference that each one
of the extra-system APs were working on adjacent channels from the one used by the testbed, as
shown in Figure 5.13. With such approach we want to assess how the system would behave in the
presence of adjacent channel interference.
Figure 5.13: Adjacent channels saturation layout
This test scenario has provided us even worst results than the obtained from the previous one,
a conclusion that can be made based on the analisys of the two network CDF curves presented in
Figure 5.14. In this scenario was verified an average delay of 43.07 ms, representing the worst
scenario until now, as illustrated in Figure 5.15. Also, in this conditions only 90% of the applica-
tion packets have arrived with a delay inferior to the target transmission window W = 100., when
in the previous scenario 95% of them have arrived with a delay inferior than 75 ms, once more
revealing that the current scenario communication conditions are worst than the former ones.
Such results stem from the fact that the testbed’s AP ability to sense the interference by both
interfering APs operating in channels 5 and 7 has diminished. Since 2.4 GHz wireless channels
Figure 5.14: Network delays histograms - saturated operating channel vs saturated adjacent chan-
nels conditions
Figure 5.15: Application delays histograms - saturated operating channel vs saturated adjacent
channels conditions
have a bandwidth of 20 MHz and a channel inter-spacing of 5 MHz, the two interfering channels
have a 15 MHz common spectrum within the testbed’s AP. This will force CSMA/CA mechanism
to be more conservative, as it will be in the presence of two interference sources. On the other
hand, both interfering channels 5 and 7 only share 10 MHz spectrum range. Therefore their CS-
MA/CA mechanism is not so influenced by each other’s presence, which could result in interfering
bandwidth greater than the verified in the previous scenario.
The combination of the previously stated conditions, leads CSMA/CA back-off mechanism to
became even more evident than when targeting only co-channel interference, leading to a aver-
age delay increase, whose spreading over a larger interval can also be evaluated considering the
standard deviation value, which is the highest when compared with all the previously presented
scenarios.
Therefore, the table Table 5.2 summarizes some of the relevant values from the previous tests:
Table 5.2: Tests results (values in ms)
Scenario Description Avg. Delay Std. Deviation 95% CDF App. delay value
Reference 3,27 11,04 5,01
Highly-Attenuated STA 8,56 41,59 7,17
Saturated Channel 19,94 38,17 74,53
Saturated Adjacent Channels 43,07 90,57 >100
From the analysis of table Table 5.2, the application average delay increase becomes evident at
each test performed, since the channel’s access conditions here become worst between each test.
In the first three scenarios described the statistical mode value for the applications delays his-
tograms was in average 1 ms, thus revealing that even in such distinct medium access conditions
this value is what occurs more often. For the scenario were both adjacent channels were in satura-
tion conditions, the applications delays mode value is four times greater than in the other scenarios.
Even so, an application delay of 4 ms will have no significant impact on the user’s experience.
In the presented delays histograms, either network or application, the CDF curve maximum
value, although near, never reaches the value 1. This comes from the fact that the data used in the
plots were not treated to discard rare occasions in which the delay becomes high, or values far way
from the average value. This decision was taken to provide a more realistic approach, as in real
world conditions such rare occurrences can in fact take place.
Lossy Network Scenario
All the previous discussed tests have provided us an analysis on the system delay characteristics,
but in all the previously presented experiments both network (0,0375%) and application (0,03%)
maximum losses rates verified were negligible. Consequently the retransmissions effect is not
evident in the applications delays histograms, has they present only one mode which corresponds
to the first verified in the network delays histogram.
In order to demonstrate the A.N.S. retransmission mechanism effectiveness, we have carried

out two tests where the network loss rate has simulated according to a standard uniform continu-
ous distribution probability function U(a, b), which is a form of a maximum entropy probability
distribution.
The losses generating process was implemented in the forwarder application, at client’s side,
accordingly to the following procedure: at each packet received over WLAN interface, a value x
between a = 0 and b = 1 was randomly generated, acording to the function U(a, b). If x > P then
the packet was forwarded through the LAN segment. Otherwise it was discarded, resulting in a
network lost packet.
Consequently P is the target network loss rate. We have carried out tests for P = 20% and P = 30%.
Figure 5.16: Application delays histograms - reference vs P = 20% network losses

Figure 5.17: Application delays histograms - reference vs P = 30% network losses
Table 5.3 summarizes the statistical values obtained from the applications delays histograms
presented in Figures 5.16 and 5.17.
Table 5.3: Lossy network scenario - application delays results
Scenario Description Avg. Delay Std. Deviation 95% CDF App. delay value
20% Loss Rate 6,15 13,75 31,46
30% Loss Rate 8,09 15,84 32,61
With the increase on the loss rate, the average delay also increases, as expected given the re-
transmissions mechanism implemented. In lossy scenarios, the application will not always receive
the first retransmission of a given packet, but can receive one of its four replicas. The maximum
delay reported by the application would occur for the case where the three first terminal pack-
ets were lost, and the application were only able to receive the fourth one. As a result, scenarios
with network losses will always present increased average application delays when compared with
loss-free networking conditions. In both scenarios the CDF curve indicates a delay lower than 33
ms for 95% of the application delays sample size.
From Figure 5.18 we can conclude that the retransmission mechanisms is effective, because
in the presence of network losses the modes related with the retransmissions appear, as expected.
Also they become more evident with the increase on the network loss rate.
Figure 5.18: Application delays histograms - P = 20% network losses vs P = 30% network losses
5.3 Inter Zone Tests
Figure 5.19: Inter zone delay measurement layout
The inter zone test procedure followed the same generation behavior adopted in the intra zone,
using exactly the same test data packet and A.N.S. configurations. The difference was that for the
current scenario we have deployed three different clients, each one connected to a distinct AP, as
illustrated in figure 5.19. In this setup, the three STA joined and forwarded the terminal packets
addressed to distinct zones. From the 3 deployed APs, two were operating in the same channel.
5.3 Inter Zone Tests 97
Our objective was to assess the system’s behavior, when considering multiple STA and multiple
co-channel operating APs.
Figure 5.20: Application delays histograms - inter zone experiment with 3 terminal clients
The results obtained, represented in Figure 5.20 which refers to application delays histogram,
once again prove the system’s ability in delivering the packets within a target transmission win-
dow. The CDF representing the application’s delays sample data show that stations STA1, STA2
and STA3 were able to receive 95% of terminal packets with a delay of 7,13, 16,56 and 19,79 ms
respectively.
All the tests performed and the obtained results lead us to conclude that the proposed system
fulfills all the system’s requirements. The retransmission mechanism developed has proven its
effectiveness, as it is able to overcome network losses inside the target transmission time window
W , even in the presence of extreme wireless interference, either ACI and CCI. Although the av-
erage throughput per channel could be considered low its real-time characteristics must be taken
into account. Also the solution targets an environment with typical poor network performance and
high-losses probability, where real-time communications are difficult to accomplish.
5.4 Sala Suggia Concert Results
Figure 5.21: Monitor computer location during the event
In order to verify the system’s behavior during the event, where the terminals density was higher
than the considered during the experiments, a monitor computer was associated with the AP cov-
ering the cell zone number 10, according to Figure 5.21.
Given the slope of the room, and the height at which the APs were placed – 6 m above the
ground – the monitor computer was at the same height as its corresponding AP.
During the event A.N.S. was configured to perform using W = 100 and R = 3, like during
the experiments previously presented. The concert lasted for about one hour, during which a
total of 820 data packets were generated, whose translation process by A.N.S. produced a total of
R + 1 × 820 = 3280 terminal packets.
From the capture’s analysis performed by our monitor computer, using Wireshark, were re-
ceived 2652 of the 3280 total generated terminal packets, which represents a 80.85% successful
network delivery rate.
Tables 5.4 and 5.5 summarize the obtained results.
Table 5.4: Concert results - absolute values
Generation Reception
(data generator) (monitor computer)
Data Packets 820 -

Terminal Packets 3280 2652
5.4 Sala Suggia Concert Results 99
Though the analysis of all the received packets’ sequence number, we were able to assess the
total application losses. Our monitor computer reported a total of 15 application lost packets, rep-
resenting 98.17% successful application delivery rate. To clarify, an application lost packet means
that for a given terminal packet’s sequence number, none of its R + 1 = 4 replicas were received.
Table 5.5: Concert results - successful delivery rates
Successful delivery rates (%)

Network Application
80.85 98.17
Using the log from the monitor computer we have also proceed to the analysis on the consec-
utive lost packets occurrence, whose results are shown in Table 5.6.
Table 5.6: Consecutive lost packets occurrences
Consecutive Lost Packets Number of occurrences

1 6
2 3
3 1
4 0
From the data shown in table Table 5.6, and assuming that during the event the data generator
component was generating in average two data packets per second, the 1.83% application loss rate
represent a total inactivity time, i.e. the total time during which the client was unable to perform
any interaction, of 7.5 seconds during the entire event, which have lasted for about an hour. Based
on the data, the worst inactivity time verified was 1.5 seconds.
5.4.1 Multimedia Result and Media Impact

The event was a success and had obtained an excellent acceptance by the audience. The media in-
dustry has also provide the event excellent opinions, which was reflected in the extensive coverage
provided. The event obtained a total of 59 news divided in the following formats:
• 35 on-line news articles.
• 13 in printed format, in newspapers and magazines.
• 10 television programs.
• 1 radio program.
Figure 5.22 shows the Sala Suggia room, where the event took place. In Figure 5.23 is pre-
sented an image of the event, where the interaction using the audience smartphones is visible.
The complete video of the event is available in [54].
Figure 5.22: Event room overview
Figure 5.23: Event picture showing public interaction through their smartphones
Chapter 6
Conclusion
This thesis purpose was to enable interaction during a concert performance with an audience of
about 1000 people, through smartphones, taking advantage of their wireless connectivity capabil-
ities.
Provide wireless connectivity in open-space and crowded environments, aiming real-time in-
teraction within the on-stage performers and its audience, presents a major challenge.
Therefore, a system was designed, providing wireless connectivity, real-time and zone-aware
communications with the clients. The system core component was A.N.S., representing this thesis
major contribution. A.N.S. implementation based on IP multicast for zone-aware traffic capabili-
ties, provides time-critical retransmission behavior to compensate possible network losses, which
are almost inevitable to occur in such high-density wireless environments.
The system was exhaustively tested in real-world conditions to assess its conformity with its
technical restrictions, and has proven its effectiveness providing that the existing network loss did
not affect the overall end-user experience. Finally it was deployed in a real-case scenario, to an
audience of almost 1000 spectators, with remarkable success, as becomes evident by the event
media impact. Consequently, all the pursued system’s requirements, presented in Section 1.2,
have been achieved.
The gathered results lead us to conclude that time-critical wireless communication in crowded
open-space environments can be accomplished with a high successful packet delivery. The de-
scribed system, presents a novel approach and improved features when compared with all the
previous similar implementations described in Section 2.1.
The solution’s core component, A.N.S., provides zone-aware, time-critical, and reliable wire-
less IP multicast communications, in high-density wireless environments, using all the available
non-overlapping channels of a given band simultaneously.
Therefore, although the solution was developed to target musical concerts its core component
can be applied in other scenarios, with some of the same time-critical, zone-aware and time-
validity traffic requirements. For instance in commercial halls the solution could be deployed
to provide clients oriented commercial advertising or promotional contents. Also in stadiums, it
101
102 Conclusion
could be used to give the audience real-time statistical information during live sports events.
Wireless communications are in constant evolution, especially when considering the IEEE
802.11 standard. In the near future, with the expected increase on high-density WLAN new
amendments are expected to arise, and some already available amendments deployment will in-
evitably become more common. For instance the IEEE 802.11k amendment released in 2008,
targeting radio resource management implementation allows STAs transmission power control in
a centralized way, as in cellular networks, and would benefit our solution, allowing increased net-
work performance and, in the limit, client’s up-link connectivity. Also, the recent IEEE 802.11ac
standard implementation will certainly become more popular, providing MU-MIMO capabilities,
allowing an increase on the data rate speed but also simultaneous user’s connections over the same
channel.
Consequently the solution described in this thesis can evolve, taking advantages of the newer
technologies, always targeting the solution’s requirements and client’s experience improvement.
Implement some simulations using NS-3 can be a valuable future work, in order to assess
system behavior in a controlled environment, aiming to characterize it without the influence of
external variables or simulate any desired conditions.
103
104 A.N.S. Output Interface - Super zones example
Appendix A
A.N.S. Output Interface - Super zones

example
Appendix B
Experiments Network Hardware
Access Point Equipment - AP

The wireless communications during the experiments were performed using TP-Link N750 wire-
less dual band gigabit router, running OpenWrt "Chaos Calmer" 15.05, a GNU/Linux based and
open-source firmware, which targets embedded devices.
Therefore, its major characteristics will be enumerated:
• CPU - Atheros AR9344 running at 560MHz;

• RAM - 128 MB;
• ROM - 8 MB;
• LAN communications - 5 gigabit LAN ports;
• WLAN communications - dual band concurrent operation MIMO compatible; Dual-Stream
(2x2) on the 2.4 GHz up to 300 Mbps; Triple-Stream (3x3) on the 5 GHz Band up to
450Mbps;
• IEEE wireless standards conformity - IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE
802.11n;
Switching Equipment
During the experiments there was a need to interconnect multiple devices, namely the computer
running A.N.S. and all the remaining software, the multiples access poins used and all the client’s
LAN interfaces. Such interconnectivity was accomplished using TP-Link TL-SG3424 gigabit L2
managed switch, which provides 24 gigabit ports, with a maximum switching bandwidth capacity
of 48 Gbps, supporting up to 4000 VLANs simultaneously.
Although being categorized as a Layer 2 equipment, this switch presents some Layers 3 and 4
features. From those features, in the scope of our work, the most useful was IP multicast address
routing capabilities, which allows forwarding of all packets addressed to a specific IP multicast
105
106 Experiments Network Hardware
to be sent to only one specific port. This device also conforms with IGMP V1/V2/V3, but such
protocol has not used.
Wireless USB Adapter

In order to implement an uniform testbed, during the experiments all the clients have been equipped
with the same wireless receiver. The equipment used was the TP-Link TL-WN722N wireless
USB Adapter, with the following major characteristics:
• SOC - AR9271 running at 117 MHz;

• Operating frequency - 2.4 GHz;
• Data rate - 150 Mps;
• WLAN communications - single band operation;
• Antenna gain - 4dBi;
• IEEE wireless standards conformity - IEEE 802.11n, IEEE 802.11g, IEEE 802.11b;
References
[1] Flong.com, Dialtones (a telesymphony) - interactive art by golan levin and collaborators,
2015. [Online]. Available: http://www.flong.com/projects/telesymphony/
(visited on 2015-05-11).
[2] Plork.princeton.edu, Plork: princeton laptop orchestra, 2015. [Online]. Available: http:
//plork.princeton.edu/index.php (visited on 2015-05-10).
[3] Mopho.stanford.edu, Stanford mobile phone orchestra (mopho), 2015. [Online]. Available:
http://mopho.stanford.edu/.
[4] G. Wang, G. Essl, and H. Penttinen, “Do mobile phones dream of electric orchestras?”, in
Proceedings of the International Computer Music Conference, 2008.
[5] PÚBLICO, Orquestra de iphones na casa da música do porto, Porto, Jun. 2010. [Online].
Available: http://www.publico.pt/tecnologia/noticia/orquestra- de-
iphones-na-casa-da-musica-do-porto-1441528.
[6] Xylobands, Radio controlled led wristbands for concerts and other live events, 2013. [On-
line]. Available: http://www.xylobands.com/xylobands/xylobands/ (visited
on 2015-05-10).
[7] B. Bongers, “Physical interfaces in the electronic arts interaction theory and interfacing
techniques for real-time performance”, Trends in Gestural Control of Music, vol. 2000, no.
January, pp. 41–70, 2000. [Online]. Available: http://citeseerx.ist.psu.edu/
viewdoc/download?doi=10.1.1.90.4997%7B%5C&%7Drep=rep1%7B%5C&
%7Dtype=pdf.
[8] M. Akpeneye, D. Gauthier, Y. Jiang, and J. Kusterer, “Viability of deploying wireless sta-
dium networks”, pp. 1–12, 2003.
[9] J. Cao and C. Williamson, “Towards stadium-scale wireless media streaming”, 14th IEEE
International Symposium on Modeling, Analysis, and Simulation, 2006, ISSN : 1526-7539.
DOI : 10.1109/MASCOTS.2006.49.
[10] K. Kondo, H. Yamamoto, C. Sasaki, S. Ano, and K. Yamazaki, “Contents distribution to

android clients using wireless lan multicast for a large fireworks festival”, in Advanced
Communication Technology (ICACT), 2013 15th International Conference on, IEEE, 2013,
107
108 REFERENCES
pp. 900–905. [Online]. Available: http://ieeexplore.ieee.org/stamp/stamp.

jsp?tp=%7B%5C&%7Darnumber=6488326.
[11] C. Connected and S. Benefits, Cisco connected stadium solution, 2015. [Online]. Available:
http://www.cisco.com/web/strategy/docs/sports/Connected%7B%5C_
%7DStadium%7B%5C_%7DDatasheet.pdf.
[12] Senetic.pt, Cisco air-ct5508-100-k9 5508 series wireless controller, 2015. [Online]. Avail-
able: https://www.senetic.pt/product/AIR-CT5508-100-K9.
[13] Designing for high density: stadiums and arenas. 2013. [Online]. Available: http : / /
www.ruckuswireless.com/carriers/designing-high-density-stadiums-
and-arenas (visited on 2015-04-22).
[14] Zoneflex 7782n 802.11n access point. [Online]. Available: http://www.ruckuswireless.

com/products/access-points/zoneflex-outdoor/zoneflex-7782 (visited
on 2015-04-22).
[15] H. Zhao, S. Zhang, J. Wei, and Y. Li, “Channel width adaptation and access in high-density
wifi networks”, 2014 XXXIth URSI General Assembly and Scientific Symposium (URSI
GASS), pp. 1–4, Aug. 2014. DOI : 10 . 1109 / URSIGASS . 2014 . 6929303. [Online].
Available: http : / / ieeexplore . ieee . org / lpdocs / epic03 / wrapper . htm ?
arnumber=6929303.
[16] V. P. Mhatre and K. Papagiannaki, “Optimal design of high density 802.11 wlans”, Pro-
ceedings of CoNEXT 2006, p. 1, 2006. DOI : 10.1145/1368436.1368448. [Online].
Available: http://portal.acm.org/citation.cfm?doid=1368436.1368448.
[17] Wikipedia, List of wlan channels, 2015. [Online]. Available: https://en.wikipedia.
org / wiki / List % 7B % 5C _ %7Dof % 7B % 5C _ %7DWLAN % 7B % 5C _ %7Dchannels %
7B%5C#%7D/media/File:2.4%7B%5C_%7DGHz%7B%5C_%7DWi- Fi%7B%5C_
%7Dchannels%7B%5C_%7D%7B%%7D28802.11b,g%7B%5C_%7DWLAN%7B%%7D29.
svg.
[18] Abiresearch.com, 802.11ac wi-fi cpe shipments to accelerate in 2015 to reach 71 million
units | abi research, 2015. [Online]. Available: https : / / www . abiresearch . com /
press/80211ac-wi-fi-cpe-shipments-to-accelerate-in-2015-/.
[19] A. F. Molisch, Wireless Communications, 2nd ed. John Wiley & Sons Ltd., 2011, ISBN :
9780470741870.
[20] Wikipedia, Mimo, 2015. [Online]. Available: https://en.wikipedia.org/wiki/
MIMO.
[21] K. Sengar, N. Rani, A. Singhal, D. Sharma, S. Verma, and T. Singh, “Study and capacity
evaluation of siso , miso and mimo rf wireless communication systems”, vol. 9, no. 9,
pp. 436–440, 2014.
REFERENCES 109
[22] V. P. Mhatre, K. Papagiannaki, and F. Baccelli, “Interference mitigation through power

control in high density 802.11 wlans”, IEEE INFOCOM 2007 - 26th IEEE International
Conference on Computer Communications, pp. 535–543, 2007, ISSN : 0743-166X. DOI :
10 . 1109 / INFCOM . 2007 . 69. [Online]. Available: http : / / ieeexplore . ieee .
org/lpdocs/epic03/wrapper.htm?arnumber=4215651.
[23] A. Zubow and R. Sombrutzki, “Adjacent channel interference in ieee 802.11 n”, . . . Confer-
ence (WCNC), 2012 IEEE, pp. 1163–1168, 2012. [Online]. Available: http://ieeexplore.
ieee.org/xpls/abs%7B%5C_%7Dall.jsp?arnumber=6213952.
[24] A. Zankiewicz, “Susceptibility of ieee 802 . 11n networks to adjacent-channel interference

in the 2 . 4ghz ism band”, Przeglad Elektrotechniczny, vol. 88, no. 9, pp. 287–288, 2012.
[25] J. Zhu, B. Metzler, X. Guo, and Y. Liu, Adaptive csma for scalable network capacity in
high-density wlan: a hardware prototyping approach, 2006. DOI : 10.1109/INFOCOM.
2006.174.
[26] Supportforums.cisco.com, Rts/cts handshake - cisco support community, 2016. [Online].

Available: https : / / supportforums . cisco . com / discussion / 10482726 /
rtscts-unicast-or-broadcast-random-backoff-time (visited on 2015-07-16).
[27] H. Jasani and N. Alaraje, Evaluating the performance of ieee 802.11 network using rts/cts
mechanism, 2007. DOI: 10.1109/EIT.2007.4374535.
[28] Wi-Fi Alliance, Wi-fi alliance voice-enterprise certification: [Online]. Available: http:
/ / static1 . squarespace . com / static / 54860cc3e4b020d690f237ba / t /
548b239ae4b0a6f211d74e60/1418404762203/Wi-Fi+Alliance(TM)+Voice-
Enterprise+Certification.pdf.
[29] Www.idc.com, Idc: smartphone os market share, 2015. [Online]. Available: http : / /
www.idc.com/prodserv/smartphone-os-market-share.jsp.
[30] A. O. S. P. .-.-. I. Tracker, Issue 17972 - android - fast roaming - android open source project
- issue tracker - google project hosting, 2011. [Online]. Available: https : / / code .
google.com/p/android/issues/detail?id=17972 (visited on 2015-05-30).
[31] ——, Issue 73862 - android - nexus 4 appends mobility domain tag if the wlan network
supports fast roaming (802.11r) - android open source project - issue tracker - google
project hosting, 2014. [Online]. Available: https://code.google.com/p/android/
issues/detail?id=73862 (visited on 2015-05-30).
[32] G. Li and J. Zhu, “Performance analysis on utilizing directional antenna in high-density

wlan”, Proceedings of the Sixth International Conference on Networking, ICN’07, 2007.
DOI : 10.1109/ICN.2007.68.
[33] J. Postel, “Rfc 791: internet protocol, sept. 1981”, Status: STANDARD, 1997. [Online].
Available: https://www.ietf.org/rfc/rfc791.txt.
110 REFERENCES
[34] S. Deering and R. Hinden, “Rfc 2460 - internet protocol, version 6 (ipv6) specification,
1998”, 2006. [Online]. Available: https://tools.ietf.org/html/rfc2460.
[35] Wikipedia, Unicast, 2016. [Online]. Available: https://en.wikipedia.org/wiki/
Unicast%7B%5C#%7D/media/File:Unicast.svg (visited on 2016-01-14).
[36] T. Narten and S. Thomson, “Rfc 2462: ipv6 stateless address autoconfiguration”, Standards
Track, [Online]. Available: https://tools.ietf.org/html/rfc2462.
[37] Wikipedia, Multicast, 2016. [Online]. Available: https : / / en . wikipedia . org /
wiki/Unicast%7B%5C#%7D/media/File:Multicast.svg (visited on 2016-01-14).
[38] J. M. Vella, “Infrastructure-dependent wireless multicast over 802 .11n wlan”, 2013.
[39] A. O. S. P. .-.-. I. Tracker, Issue 51195 - android - many devices have multicast disabled
in the kernel - android open source project - issue tracker - google project hosting, 2013.
[Online]. Available: https://code.google.com/p/android/issues/detail?
id=51195.
[40] Technet.microsoft.com, How ipv4 multicasting works: multicast routing, 2015. [Online].
Available: https://technet.microsoft.com/en-us/library/cc759719%7B%
%7D28v=ws.10%7B%%7D29.aspx.
[41] M. J. Christensen and F. Solensky, Igmpv3 and igmp snooping switches, 2015. [Online].
Available: https : / / www . ietf . org / proceedings / 50 / I - D / idmr - snoop -
00.txt.
[42] Wikipedia, Broadcast, 2016. [Online]. Available: https : / / en . wikipedia . org /

wiki/Unicast%7B%5C#%7D/media/File:Broadcast.svg (visited on 2016-01-14).
[43] M. Usman, A. Khan, and Y. A. Rasheed, “Optimization of tcp over wireless networks”, no.
October, 2011. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/
summary?doi=10.1.1.653.8083.
[44] Netmarketshare.com, Operating system market share, 2015. [Online]. Available: https:
/ / www . netmarketshare . com / operating - system - market - share . aspx ?
qprid=8%7B%5C&%7Dqpcustomd=1.
[45] S. Ribeiro, Portugueses compraram 6 mil smartphones por dia, 2014. [Online]. Available:
http://www.sol.pt/noticia/106877 (visited on 2015-07-17).
[46] A. O. S. P. .-.-. I. Tracker, Issue 32630 - android - support connecting to ipv6-only wireless
networks - android open source project - issue tracker - google project hosting, 2012. [On-
line]. Available: https://code.google.com/p/android/issues/detail?id=
32630.
[47] W. George, C. Donley, and C. Liljenstolpe, “L. howard," ipv6 support required for all ip-
capable nodes”, BCP 177, RFC 6540, April, Tech. Rep., 2012. [Online]. Available: http:
//tools.ietf.org/html/rfc6540.
REFERENCES 111
[48] A. O. S. P. .-.-. I. Tracker, Issue 32662 - android - frequently ignores icmpv6 ras and other
multicast traffic - android open source project - issue tracker - google project hosting, 2012.
[Online]. Available: https://code.google.com/p/android/issues/detail?
id=32662.
[49] ——, Issue 32621 - android - support for dhcpv6 (rfc 3315) - android open source project
- issue tracker - google project hosting, 2012. [Online]. Available: https : / / code .
google.com/p/android/issues/detail?id=32621.
[50] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins, and M. Carney, “Rfc 3315, dynamic
host configuration protocol for ipv6 (dhcpv6)”, Standards Track, 2003. [Online]. Available:
https://tools.ietf.org/html/rfc3315.
[51] Puredata.info, Pure data community site, 2016. [Online]. Available: https://puredata.
info/.
[52] Mingw.org, Mingw | minimalist gnu for windows, 2016. [Online]. Available: http : / /
www.mingw.org/.
[53] Iperf.fr, Iperf - the tcp, udp and sctp network bandwidth measurement tool, 2016. [Online].
Available: https://iperf.fr/.
[54] YouTube, Inesc tec: "concerto a.bel - nova música interactiva" na íntegra, 26outubro2015,
2016. [Online]. Available: https : / / www . youtube . com / watch ? v = X % 7B % 5C _
%7DYeO3Qi3H4 (visited on 2016-01-14).

Scalable Wireless Communications To Enrich Live Concerts in Large Halls

Enviado por

Dados do documento

Título original

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Scalable Wireless Communications To Enrich Live Concerts in Large Halls

Título original:

Enviado por

Direitos autorais:

FACULDADE DE E NGENHARIA DA U NIVERSIDADE DO P ORTO

Scalable Wireless Communications to

Carlos Manuel Sanches Leocádio

M ESTRADO I NTEGRADO EM E NGENHARIA E LETROTÉCNICA E DE C OMPUTADORES

Supervisor: Manuel Ricardo (PhD)

February 24, 2016

2 State of the Art 5

4.5 Network Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5 System Performance Analysis 79

A A.N.S. Output Interface - Super zones example 103

B Experiments Network Hardware 105

1.1 Sala Suggia blueprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 IEEE 802.11 Physical and Data Link components . . . . . . . . . . . . . . . . . 8

3.1 a.bel Sytem’s Interaction Loop Representation . . . . . . . . . . . . . . . . . . . 36

3.16 Target transmission time window splitting procedure . . . . . . . . . . . . . . . 52

4.1 Data Packet structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.1 Delay testbed layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

2.1 Evolution of IEEE 802.11 Standard . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Zones Map example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1 Histogram mode values in ms - test vs theoretical . . . . . . . . . . . . . . . . . 86

ACI Adjacent-Channel Interference

ISM Industrial, Scientific and Medical

Develop a solution to connect hundreds of mobile devices to a network in a concert environment

Figure 1.1: Sala Suggia blueprint

• Transparency - user’s system usage should be transparent, or acquired with minimum

State of the Art

2.1 Related Solutions

2.2 IEEE 802.11 Standard

Figure 2.1: IEEE 802.11 Physical and Data Link components

Table 2.1: Evolution of IEEE 802.11 Standard

1997 802.11 2.4 20 IR, FHSS, DSSS 2 Mbit/s none

1999 802.11a 5 20 OFDM 54 Mbit/s none

1999 802.11b 2.4 20 DSSS 11 Mbit/s none

2003 802.11g 2.4 20 DSSS, OFDM 54 Mbit/s none

2009 802.11n 2.4, 5 20, 40 OFDM 600 Mbit/s MIMO

2012 802.11ad 60 2160 SC OFDM 6.76 Gbit/s Beamforming

1. Changing modulation technique from DSSS to OFDM;

2. Using larger channel bandwidth and different spectrum regions;

3. Development of multiple-input and multiple-output (MIMO) technology;

2.2.1 DSSS and OFDM Techniques

Figure 2.2: Representation of Narrowband versus Wideband Signals

2.2.2 ISM Frequency Bands - 2.4 and 5 GHz

Figure 2.3: Representation of 2.4 GHz band channels [17]

2.2.3 MIMO Technology

Figure 2.4: Multipath Propagation [19]

Figure 2.5: Small-scale fading [19]

MIMO technology exploits the previously presented wireless communications peculiarities to

• Space-Time Coding: As no CSI information is available at transmitter (TX), redundancy

Figure 2.6 shows a generic representation of MIMO channel model.

Let’s us assume the following:

Figure 2.6: MIMO Channel Model [20]

xi – signal transmitted by transmitter i ∈ [1, NT ];

Y (n) = H(n) × X(n) + η (n) (2.1)

X(n): original signal to transmit;

In [21] a capacity study, based on simulations on each one of topologies is presented. As

Symmetry: Network N is considered symmetric, if and only if i ∈ S j and j ∈ Si , ∀i, j ∈ N and

In wireless environments we can assume two types of interference: adjacent-channel in-

Figure 2.7: Hidden Node Problem

Figure 2.8: Exposed Node Problem

2.2.5 Medium Access Mechanisms

affect the pursued solution performance.

2.2.5.1 CSMA/CA Mechanism

Figure 2.9: Access method and back-off procedure [19]

Equation (2.3) presents the definition of signal-to-interference-plus-noise ratio (SINR) used

Figure 2.10: RTS/CTS Handshake Mechanism [26]