Atas - 13ª Conferência sobre Redes de Computadores

Transcrição

A Internet do futuro
13ª Conferência sobre Redes de Computadores, CRC2013
Leiria, Portugal, 14-15 de Novembro de 2013
Atas da conferência
Editores
António Pereira
Carlos Rabadão
Patrício Domingues
Vitor Fernandes
Publicado por
INSTITUTO POLITÉCNICO DE LEIRIA
ISBN
978-972-8793-62-3
Créditos
TÍTULO
SUBTÍTULO
13ª Conferência sobre Redes de Computadores, CRC2013
Leiria, Portugal, 14-15 de Novembro de 2013
Atas da conferência
EDITORES
António Pereira
Carlos Rabadão
Patrício Domingues
Vitor Fernandes
Centro de Investigação em Informática e Comunicações do Instituto Politécnico de Leiria
Departamento de Engenharia Informática, Escola Superior de Tecnologia e Gestão, Instituto
Politécnico de Leiria
EDIÇÃO, IMPRESSÃO E ACABAMENTOS
Escola Superior de Tecnologia e Gestão, Instituto Politécnico de Leiria
COPYRIGHT
Instituto Politécnico de Leiria
DEPÓSITO LEGAL
367128/13
ISBN
978-972-8793-62-3
WEB
http://crc2013.dei.estg.ipleiria.pt
Organização
Presidentes Gerais
António Pereira
Patrício Domingues
ESTG - Instituto Politécnico de Leiria
Presidentes da Comissão de Programa
Carlos Rabadão
Vítor Fernandes
Comissão Coordenadora
Alexandre Santos
Edmundo Monteiro
Rui Aguiar
Teresa Vazão
Universidade do Minho
Universidade de Coimbra
Universidade de Aveiro
Instituto Superior Técnico
Comissão Organizadora
João Pereira
Mário Antunes
Miguel Frade
Nuno Costa
Paulo Loureiro
Comissão de Programa
Adriano Moreira
Alexandre Santos
Álvaro Barradas
Amaro de Sousa
António Costa
António Nogueira
António Pereira
Arnaldo Martins
Augusto Casaca
Bruno Dias
Carlos Eduardo Pereira
Carlos Miguel Ribeiro
Carlos Ribeiro
Carlos Salema
Carlos Sá da Costa
Carlos Serôdio
Diogo Gomes
Edmundo Monteiro
Eduardo Cerqueira
Fernando Boavida
Fernando Ramos
Fernando Velez
Universidade do Algarve
Universidade Federal do Rio Grande do Sul (Brasil)
ISCTE - Instituto Universitário de Lisboa
Universidade de Trás os Montes e Alto Douro
Universidade Federal do Pará (Brasil)
Universidade de Lisboa
Universidade da Beira Interior
Gabriela Schütz
Jânio Monteiro
João Pereira
Joaquim Ferreira
Joaquim Macedo
Joel Rodrigues
Jorge Sá Silva
José Alberto Fonseca
José Legauteaux Martins
José Luís Oliveira
José Ruela
Luís Almeida
Luís Bernardo
Luís Lino Ferreira
Luís Rodrigues
Manuel Ricardo
Maria João Nicolau
Marília Curado
Mário Antunes
Mário Freire
Miguel Frade
Nuno Costa
Nuno Cota
Noélia Correia
Osvaldo Santos
Patrício Domingues
Paulo Carvalho
Paulo Loureiro
Paulo Mendes
Paulo Pedreiras
Paulo Pereira
Paulo Pinto
Paulo Portugal
Paulo Salvador
Paulo Simões
Pedro Assunção
Pedro Gonçalves
Pedro Sousa
Rui Aguiar
Rui Lopes
Salvador Abreu
Silvana Meire
Solange Rito Lima
Susana Sargento
Universidade Nova de Lisboa
Faculdade de Engenharia da Universidade do Porto
Universidade do Porto
Instituto Politécnico do Porto
Faculdade de Engenharia da Universidade do Porto
Instituto Politécnico de Lisboa
Instituto Politécnico de Castelo Branco
Universidade Lusófona
Universidade do Porto
Instituto Politécnico de Bragança
Universidade de Évora
Universidade de Vigo (Espanha)
Prefácio
Foi com particular entusiasmo que o Centro de Investigação em Informática e Comunicações e
o Departamento de Engenharia Informática da Escola Superior de Tecnologia e Gestão, do
Instituto Politécnico de Leiria, organizaram e receberam a 13ª Conferência sobre Redes de
Computadores – CRC2013.
Desde o seu início, em 1998, a Conferência sobre Redes de Computadores tem-se assumido
como um veículo por excelência para a divulgação de trabalhos de investigação,
desenvolvimento e inovação na área das redes de computadores, constituindo um fórum para a
partilha de experiências e a descoberta de interesses comuns entre a comunidade científica
nacional. Tem-no feito seguindo uma política de proximidade com as comunidades científicas
nacionais, tendo já sido realizada em Coimbra, Évora, Viseu, Covilhã, Faro, Bragança, Leiria,
Portalegre, Oeiras, Braga e Aveiro.
Nesta sua 13ª edição, dedicada ao tema “A Internet do Futuro”, a CRC tem por principal
objetivo constituir-se num fórum nacional para a apresentação e discussão de resultados de
investigação originais de elevada qualidade, orientados no sentido de mitigar os novos desafios
colocados à Internet, e navegar rumo à Internet do Futuro. Privilegia-se nesta edição os
trabalhos sobre novas tecnologias, capazes de responder a novos serviços e desafios, atuais e
futuros, nomeadamente ao nível da segurança, da qualidade de serviço, da mobilidade, da gestão
da rede, da escalabilidade e da sustentabilidade.
Foram submetidos 32 trabalhos e, após cuidada revisão, foram selecionados 18 artigos de
elevada qualidade que foram apresentados nas sessões temáticas em que a Conferência foi
organizada – Eficiência energética e sustentabilidade, Serviços e aplicações para a Internet de
futuro, Redes sensoriais e veiculares, Arquiteturas e tecnologias para funcionamento em rede, e
Encaminhamento em redes – e que se encontram reunidos e editados neste livro de Atas.
Adicionalmente, e para divulgação de trabalhos de I&D+i em curso, essencialmente associados
a licenciaturas, mestrados e doutoramentos, incluem-se também 5 artigos curtos, em formato de
resumo estendido.
Expressam-se os agradecimentos a todos os que contribuíram para este processo, especialmente
a todos os colegas da Comissão Científica de Programa da CRC2013, aos membros da
Comissão Coordenadora das CRC, aos colegas do Centro de Investigação em Informática e
Comunicações e do Departamento de Engenharia Informática da ESTG/IPLeiria, e a toda a
Comissão Organizadora desta 13ª Conferência sobre Redes de Computadores. Expressa-se
também um agradecimento especial ao INOV – INESC Inovação e aos cursos e estudantes dos
cursos afetos ao Departamento de Engenharia Informática da ESTG/IPLeiria, por todo o
apoio logístico prestado. Finalmente, um reconhecido agradecimento para todas as entidades e
instituições que apoiaram esta CRC2013, concedendo outros contributos essenciais para elevar a
qualidade desta Conferência.
Para finalizar, esperamos que encontre nestas Atas um documento útil e atual, com novas ideias,
resultados e descobertas no sentido de mitigar os novos desafios colocados à Internet, e de nos
levar rumo à Internet do Futuro.
Leiria, novembro de 2013
António Pereira
Carlos Rabadão
Patrício Domingues
Vitor Fernandes
Índice
Sessão 1: Eficiência energética e sustentabilidade
A Survey of Communication Technologies for the Low Voltage Distribution
Segment in a Smart Grid ......................................................................................................................... 1
António Grilo, Paulo Rogério Pereira, Mário Serafim Nunes, Augusto Casaca
Performance Analysis and Comparison between Legacy-PSM and U-APSD ................................. 7
Adriano Vinhas, Vitor Bernardo, Marilia Curado, Torsten Braunn
Gestão de Cargas numa Micro Grid Utilizando Algoritmos Genéticos .......................................... 13
Jorge Eduardo, Pedro Cardoso, Jânio Monteiro
Sessão 2: Serviços e aplicações para a Internet de futuro
SDN Framework for Connectivity Services ........................................................................................ 19
Rafael Gouveia, João Aparício, João Soares, Bruno Parreira, Susana Sargento, Jorge Carapinha
Framework e Cliente WebRTC ............................................................................................................. 25
Vasco Amaral, Solange Lima, Telma Mota, Paulo Chainho
Testing Performance of MLP Neural Networks for Intrusion Detection with MATLAB .......... 33
José Quevedo, Rui Aguiar
Configuração dinâmica em redes sem fios ........................................................................................... 39
Daniel Fuentes, António Pereira
Sessão 3: Redes sensoriais e veiculares
Encaminhamento com QoS para Redes Ad Hoc com rotas estáveis .............................................. 47
Tiago Coelho, António Costa, Maria João Nicolau, Joaquim Macedo
Performance Evaluation of IEEE 802.11 Underwater Wireless Networks ................................... 53
Filipe Teixeira, José Quevedo, Rui Campos, Manuel Ricardo
SILOS - A Simple Location Service for Vehicular Ad-hoc Networks ............................................ 59
André Camões, Teresa Vazão
Sessão 4: Arquiteturas e tecnologias para funcionamento em rede
Solução Aberta para uma Rede de Sondas de QoS na RCTS ........................................................... 65
Pedro Queiros, M. João Nicolau, Alexandre Santos
Using Web10G for Service and Network Diversity Exploitation and Failure Recovery ............. 73
Filipe Ribeiro de Carvalho, José Legatheaux Martins
Towards Widespread use of SCTP for the Future Internet .............................................................. 79
Bruno Sousa, Ricardo Santos, Marilia Curado
A comparative analysis of IEEE 802.11 MAC layer mechanisms to handle real-time
traffic in open communication environments ..................................................................................... 85
Robson Costa, Paulo Portugal, Francisco Vasques, Ricardo Moraes
Sessão 5: Encaminhamento em redes
Bayesian based selfish aware routing on Delay Tolerant Networks ................................................ 91
Ricardo Oliveira, António Costa, Joaquim Macedo, Maria Nicolau
Recolha e Análise de Dados de Contactos Físicos e Sociais numa Rede Tolerante a Atrasos .... 97
João Antunes, António Costa, Joaquim Macedo
Encaminhamento Multi-Caminho Baseado num Número Reduzido de Árvores ....................... 103
João Horta, Margarida Mamede, José Legatheaux Martins
Encaminhamento IP Optimizado Através de uma Aproximação de Software
Defined Networking ............................................................................................................................. 109
Alexandre Pinote, José Legatheaux Martins
Sessão de posters
Automatização de Testes SIP .............................................................................................................. 115
David Gonçalves, Nuno Sousa, António Amaral, António Costa
Transmissão de vídeo com múltiplas descrições com débitos variáveis em canais
multi-percurso com débito assimétrico .............................................................................................. 119
Pedro Correia, Pedro Assunção, Vítor Silva
Web-browser Real Time Communication in IMS Systems ............................................................. 123
Rui Sábio, Fernando Silva, Carlos Rabadão, António Pereira
Técnicas de classificação e detecção de tráfego para Voice over Internet Protocol (VoIP) ...... 127
Hugo Fonseca, Paulo Simões, Edmundo Monteiro, Tiago Cruz, José Silva, Pedro Gomes, Nuno Centeio
Validação remota de aplicações de informática forense com recurso a dongles por USB/IP ... 131
Albano Afonso, Mário Antunes, Filipe Pinto
A Survey of Communication Technologies for the
Low Voltage Distribution Segment in a Smart Grid
António Grilo, Paulo Rogério Pereira, Mário Serafim Nunes, Augusto Casaca
Inesc-ID/Inesc INOV, Instituto Superior Técnico, Universidade de Lisboa, Rua Alves Redol, nº 9, 1000-029 Lisboa, Portugal.
e-mails: {antonio.grilo, prbp, mario.nunes, augusto.casaca}@inesc.pt
Abstract—This paper presents a survey of technologies for
data transmission in an electricity distribution network between
the controllers at the electrical secondary substations and the
home equipment. The selected technologies can be used for
implementation of advanced monitoring and control
functionalities in the Low Voltage (LV) network of the electricity
distribution system within the smart grid paradigm.
Keywords—Smart Grid, PLC, RF Mesh,Wireless.
I.
INTRODUCTION
support for the Smart Grid functionalities. However, given the
dimension, complexity and scenario diversity of the Smart
Grid, it is doubtful that the market will converge to a single
winner, since all technologies have advantages and
disadvantages with respect to this or that evaluation metric or
scenario peculiarity. In fact, some published papers consider
the possibility of integrating several technologies, from lowrate short-range wireless communications to fiber optic
segments capable of aggregating data rates in the order of
Mbit/s or Gbit/s spanning distances in the order of many
kilometers [1][2][3].
In the recent past, the concept of Smart Grid has gained
relevance as a paradigm for the future energy grids. This
concept spans all levels of the energy business model,
comprising the generation, transport, distribution and
consumption of energy. However, this paper only deals with
the Low Voltage (LV) distribution segment.
The communication network that overlays the LV
distribution segment of the Smart Grid is the LV Distribution
Network (LVDN). The main components and interfaces
related with the LVDN functionality are depicted in Fig. 1.
The top level comprises the Energy Management System
(EMS), which supervise, manage and control the energy
infrastructure based on the gathered metering and energy
infrastructure status data. The mid-level corresponds to the
Local Controller near the MV/LV power transformer in the
secondary substation, which provides concentration of data
from LVDN. It is capable of automation, fault detection, event
reporting and also quality of supply monitoring. The data that
is collected by the Local Controller is typically sent to the
EMS through a Wide Area Network (WAN). The lower level
comprises the LVDN properly said, which interconnects
sensors and actuators attached to LV infrastructure devices, as
well as the Energy Meters (EMs) located at the customers’
houses, to the Local Controller. Adding sensors to the LV
infrastructure allows new metering, automation and
management of the energy network functionalities, as well as
location of faults and increased energy efficiency, among
other applications. The EM provides metering and contractual
functions, and enables micro-generation integration and
control. Through a wireless Home Area Network (HAN), the
EM can monitor and control energy devices inside a house.
The producer/consumer (prosumer) can interact with the EM
through a local interface.
Several communication technologies have been presented
in the literature as candidates to provide the underlying
Fig. 1. Smart Grid Communication Infrastructure.
This paper presents a state-of-the-art of the communication
technologies that are relevant for monitoring and intelligent
control of the LVDN under the MONITOR-BT project,
partially supported by the QREN program.
MONITOR-BT aims to sense and monitor utility’s field
devices, as well as to control micro-generation equipment at
the customer premises, with both of them being located in the
LV section of the electricity distribution grid. In terms of the
architecture, this corresponds mainly to the LVDN section of
the communications infrastructure. Although some of the
sensor data is to be remotely monitored by the EMS – which
also involves the Wide Area Network (WAN) – the project
shall here rely on existing communications infrastructure. This
1
state-of-the-art will thus restrict its scope to the technologies
that are considered suitable for LVDN deployment:
•
•
•
Power Line Communications (PLC);
Infrastructure-based Wireless Networks;
Radiofrequency Mesh (RF-Mesh) networks.
The reasons why these groups of technologies are more
relevant in this case, have mainly to do with the following
factors:
•
Since LVDN is already located at the edge of the Smart
Grid, the amount of traffic is much lower in comparison
with the WAN, since the latter must aggregate traffic
from several LV islands.
•
For cost-effectiveness reasons, the footprint of the
communications network in terms of additional
equipment and/or requirement for changes in existing grid
equipment must be minimized. Wireless technologies
avoid the deployment of cabled infrastructure (RF-Mesh)
or employ existing infrastructure from a telecom operator
(Public Land Mobile Network – PLMN). On the other
hand, PLC also avoids the deployment of cabled
infrastructure, since the latter already exists in the
electricity grid.
This paper presents an analysis of these three groups of
candidate technologies, presenting their advantages,
disadvantages and constraints.
II.
ANALYSIS OF TECHNOLOGIES
A. Power Line Communications (PLC)
Power Line Communications (PLC) technology is used
since the 1950s by the electricity distribution companies in
order to remotely perform some control functions on electric
network equipment [4]. Recently, this technology has earned
more relevance because the technology evolution has led to an
increase of the achieved data rates, both in medium and low
voltage. The advantage of PLC comes from the fact that it
uses the same infrastructure for both energy distribution and
communications, which greatly reduces the deployment costs.
The PLC systems are usually classified according to three
different bandwidth classes: Ultra Narrowband (UNB),
Narrowband (NB) and Broadband (BB) [5][6]. Although the
attained data rates and ranges are highly dependent on the
specific characteristics and transient conditions of the network
(e.g., the impedance is highly dependent on the number and
characteristics of attached electrical devices), some
approximate figures shall be provided as a reference to allow a
better comparison between the different classes.
The UNB-PLC systems operate in the Very Low
Frequency (VLF) band, which corresponds to 0.3-3.0 kHz.
The attained bit rates are usually in the order of 100 bit/s, with
ranges of up to 150 km. The relevant UNB-PLC applications
comprise Automatic Meter Reading (AMR), and fault
detection in the distribution grid, as well as voltage
monitoring.
2
The NB systems operate in the Low Frequency (LF) band,
which corresponds to 3-500 kHz. In Europe, the European
Committee for Electrotechnical Standardization (CENELEC)
has defined four frequency bands for PLC use: CENELEC-A
(3-95 kHz), CENELEC-B (95-125 kHz), CENELEC-C (125140 kHz) and CENELEC-D (140-148.5 kHz). CENELEC-A is
reserved for exclusive use by energy providers, while
CENELEC-B, CENELEC-C and CENELEC-D are open for
end user applications. In NB-PLC, the attained data rates span
from a few kbit/s to around 800 kbit/s – depending on the
technology, bandwidth and channel conditions –, while the
range is in the order of some kilometers. Some standards for
Building Automation Applications (BAA), such as BacNet
(ISO 16484-5) and LonTalk (ISO/IEC 14908-3), employ NBPLC with a single carrier. The IEC 61334 standard for lowspeed reliable power line communications by electricity
meters, water meters and SCADA, uses the 60-76 kHz
frequency band, being able to achieve 1.2-2.4 kbit/s with
Spread Frequency Shift Keying (S-FSK) modulation. Yitran
Communications Ltd. and Renesas Technology provide
solutions based on Differential Chaos Shift Keying (DCSK) –
a form of Direct-Sequence Spread Spectrum (DSSS) –, which
are able to achieve bitrates as high as 60 kbit/s in the
CENELEC-A band. On the other hand, PoweRline Intelligent
Metering Evolution (PRIME)1 and G32 are multi-carrier
systems based on Orthogonal Frequency Division
Multiplexing (OFDM), which allows them to support higher
data rates. PRIME operates within the CENELEC-A
frequency band, more specifically in the 42–89 kHz range, and
is able to achieve 21-128 kbit/s. G3 may operate in the
CENELEC-A and CENELEC-B bands, being able to achieve
2.4-46 kbit/s. The G3-PLC MAC layer is based on the IEEE
802.15.4 MAC. In order to unify the OFDM-based NB-PLC
systems, ITU has approved recommendations G.9955
(G.hnem physical layer) [7] and G.9956 (G.hnem data link
layer) [8], while IEEE has approved recommendation P1901.2
[9].
BB-PLC systems operate in the High Frequency (HF) and
Very High Frequency (VHF) bands, which corresponds to 1.8250 MHz. The achievable data rates may be as high as 500
Mbit/s, but the range is significantly shorter than for NB-PLC.
Consequently, BB-PLC is normally used for local connectivity
in the HAN or as a broadband access technology. The most
recent BB-PLC standards are IEEE P1901 (also designated
Broadband Over Power Line – BPL)3 and ITU G.996x (G.hn),
which are based on OFDM. The ITU G.9963 recommendation
[10] also incorporates some MIMO concepts through the use
of multiple cables.
Despite the advantages of PLC for Smart Grid
applications, namely the reduced costs and easier management
of a single infrastructure (i.e. energy distribution plus
communications in a single network), PLC faces some
obstacles and challenges, which are often similar to the ones
faced by RF-Mesh (see below):
1
PoweRline Intelligent Metering Evolution: http://www.prime-alliance.org
2
http://www.maxim-ic.com/products/powerline/g3-plc
3
IEEE P1901 is based on the HomePlug AV system developed by the
HomePlug Powerline Alliance.
Atas da 13ª Conferência sobre Redes de Computadores - CRC2013
•
•
The shared medium is subject to significant attenuation
and noise, which limit the data rates and ranges that can
be effectively achieved.
A failure in the energy distribution infrastructure usually
means that the communications cannot take place while
the malfunction rests unresolved, which may negatively
affect some applications. Another consequence of the
latter is that a communications failure may be wrongly
interpreted as a malfunction in the energy distribution
infrastructure.
B. Infrastructure-based Wireless Networks
The technologies that fall within the Infrastructure-based
Wireless Networks category rely on a fixed infrastructure of
base stations, together with switching equipment and
management systems, in order to provide wide coverage
communication service to the end user. Fixed wireless access
and mobile cellular networks, both fit into this category.
The WiMAX technology is defined in the IEEE 802.16
standard for fixed and mobile broadband wireless access [11],
being able to achieve a coverage range in the order of 50 km
and data rates in the order of tens or even hundreds of Mbit/s.
Despite its advantages, the widespread adoption of Long Term
Evolution (LTE) by mobile operators has brought down the
initial popularity that WiMax was, for some time, able to
enjoy. Moreover, the lack of WiMax networks and operators
in Portugal constitute significant obstacles to the adoption of
this technology to support Smart Grid functionalities in this
country, since the energy provider would have to deploy its
own WiMax infrastructure. IEEE 802.16 shall be addressed
again in this paper, but in the context of RF-Mesh
technologies.
The mobile cellular communications technologies divide
the covered territory into smaller areas designated cells, each
served by a base station. If the base station is equipped with
directional antennas, the cell may be further sectorized, which
increases the frequency reuse and hence its capacity to support
more users. Before a call is established, the mobile user
terminal is tracked as it moves between different sectors or
cells, allowing the mobile terminal to be paged at any time.
Moreover, handover signaling procedures allow the user to
move even while a call is taking place. Mobile cellular
technologies have already spanned two digital generations
starting on the 2nd Generation (2G) and are already in their
fourth generation.
Examples of 2G technologies available in Europe (and
Portugal in particular) are Global System for Mobile
Communications / General Packet Radio Service
(GSM/GPRS) and Terrestrial Trunked Radio (TETRA). GPRS
is the packet switched complement of GSM and supports
effective data rates up to 177.6 kbit/s in the downlink and
118.4 kbit/s in the uplink. The effective data rate depends on
the required error protection, class of terminal and sharing
with other users using the same frequency channel. The
TETRA technology is primarily used by security and civilian
protection entities, as well as transportation services, due to
the support of specific functionalities like direct mode
operation and group calls. The supported data rates span from
2.4 kbit/s to 28 kbit/s, depending on the required error
protection and channel allocation.
The 3rd Generation (3G) arrived in the beginning of this
century with the Universal Mobile Telecommunications
System (UMTS), which offered 2 Mbit/s (shared) in urban
areas. UMTS suffered a number of upgrades to increase the
supported data rates, namely the High-Speed Downlink Packet
Access+ (HSDPA) and HSDPA+ for the downlink, and HighSpeed Uplink Packet Access (HSUPA) for the uplink. HSDPA
can support data rates up to 42 Mbit/s, though later releases
specify data rates up to 337 Mbit/s with HSDPA+. In the
opposite direction, HSUPA may support data rates up to 23
Mbit/s, though existing mobile operators might offer a lower
value.
CDMA450 is also a 3G technology, based on the
adaptation of the American standard CDMA2000 to operate in
the 450-470 MHz frequency band. The supported total bitrates
depend on the specific mode of operation. For Multicarrier
EV-DO, overall bitrates may be as high as 9.3 Mbit/s for
downlink and 5.4 Mbit/s for uplink, with average rates per
user in the order of 1.8-4.2 Mbit/s for downlink and 1.5-2.4
Mbit/s for uplink. This technology was offered in Portugal by
the Zapp operator until 2011, being abandoned afterwards.
This means that in order to use CDMA450 as a Smart Grid
infrastructure, the utility will have to deploy its own network
infrastructure, like for WiMax.
Currently, most European mobile operators already offer
LTE, including the Portuguese mobile operators. Although
marketed as 4G, LTE does not satisfy yet all the 4G
requirements defined by 3GPP. LTE employs Orthogonal
Frequency Division Multiple Access (OFDMA) in the
downlink and Single-Carrier Frequency Division Multiple
Access (SC-FDMA) in the uplink. Supported peak data rates
are 299.6 Mbit/s for the downlink and 75.4 Mbit/s for the
uplink.
Given their proven reliability, technology maturity and
extensive coverage, mobile cellular networks constitute
important candidates to support the Smart Grid
communications infrastructure, being used already in
applications such as Automatic Meter Reading (AMR).
However, these technologies face the following challenges:
•
The difficulties related with radiofrequency (RF)
penetration inside buildings constitute sometimes an
obstacle for its use in some Smart Grid applications,
namely AMR.
•
The fact that the mobile cellular network is most of the
time managed by an external operator, means that the
utility will have to pay the latter for the provisioning of
communications services. Alternatively, the utility might
deploy its own communications infrastructure (e.g.,
WiMax or CDMA450), though that would certainly
constitute a substantial investment on communication
systems.
C. Radiofrequency Mesh (RF-Mesh)
An RF-Mesh is a network formed by RF capable nodes,
which are self-organized in a mesh topology [12][13][14].
3
This self-organization capability brings several advantages in
the context of Smart Grid communications, namely
deployment flexibility and automatic connection reestablishment and topology reconfiguration in the presence of
link or node failure. This explains why this family of
technologies is so popular in the USA, where it is used to
support Smart Metering applications. Within the RF-Mesh
family, we can distinguish between broadband and
narrowband technologies.
The most representative broadband technologies are
currently WiFi [15] and IEEE 802.16j [16]. Even if the IEEE
802.11s mesh extension is not used, IEEE 802.11 can be
configured to operate as a mesh by performing ad-hoc routing
at the network layer (e.g., IP layer). These technologies
support communication ranges in the order of hundreds (IEEE
802.11) or thousands (IEEE 802.16) of meters, as well as high
data rates in the order of Mbit/s, which makes them
multimedia capable. Besides physical and Medium Access
Control (MAC) aspects, IEEE 802.11s specifies the routing
protocol, which is the Hybrid Wireless Mesh Protocol
(HWMP). The latter is a hybrid between a tree routing
protocol and the Ad-hoc On-Demand Distance Vector
(AODV) protocol [17]. In case IEEE 802.11 is used without
the mesh extension, a myriad of routing protocols such as
AODV, Optimized Link State Routing Protocol (OLSR) [18],
or Routing Protocol for Low-Power and Lossy Networks
(RPL) [19] can be used at the network layer. As to IEEE
802.16j, it does not specify how the path evaluation and
selection is done, there being freedom for manufacturer
specific implementations. However, it constrains the topology
to be tree based. Although the high bitrates supported by
broadband RF-Mesh allow the support of virtually any Smart
Grid applications, both real-time and non-real-time, these
technologies also have some disadvantages that can hinder
their global applicability:
•
Broadband communications means operating at higher
frequencies, which are more vulnerable to path loss and
other causes of signal attenuation.
•
Broadband RF-Mesh transceivers often present higher
energy consumption in comparison with narrowband RFMesh. This is made even worse by the need to increase
the transmit power in order to compensate for path loss
and attenuation. The deployment of a huge number of
nodes means that the energy overhead introduced by the
Smart Grid communications may start to be nonnegligible.
•
High bitrates demand a corresponding processing and
storage capacity to be available on the network nodes,
which will likely be translated into an increase of the unit
cost.
•
The deployment of these technologies by the utility
requires the choice of the operating frequency. IEEE
802.11 operates mainly on the unlicensed bands of 2.4
GHz or 5 GHz. The 2.4 GHz band is cluttered, since it is
subject to the interference of both private and public
WLANs. On the other hand, the 5 GHz band has a
reduced range for the same transmit power. IEEE 802.16
4
supports frequency bands between 2 GHz and 66 GHz,
both licensed and unlicensed. Besides the problems
related with spectrum occupancy, the use of unlicensed
bands also raises the problem of communications security.
On the other hand, the use of licensed bands usually
represents additional costs for the utility.
The narrowband RF Mesh technologies correspond to
those that belong to the Wireless Sensor Network (WSN) and
Internet of Things (IoT) domains. These are usually
characterized by simpler hardware and operating systems,
leading to a lower unit cost [13]. The lower power
consumption that characterizes these technologies allows
greater autonomy and effectiveness of energy harvesting
techniques, which can feed the network nodes in case they
cannot be directly fed by the LV network.
In the context of WSNs, the IEEE 802.15.4 standard is
nowadays prominent, constituting the basis (PHY and MAC
layers) of several protocol stacks such as ZigBee,
WirelessHART, ISA100.11a and IoT, which are
recommended for industrial and Smart Utility Networks
(SUN) applications [14]. The IEEE 802.15.4 MAC protocol is
based on Carrier Sense Multiple Access with Collision
Avoidance (CSMA/CA), but also includes an optional Time
Division Multiple Access (TDMA) operational mode. The
latter is reserved for traffic that requires stringent access delay
guarantees. While the original IEEE 802.15.4 standard
restricted operation to the unlicensed frequency bands of 868870 MHz (Europe), 902-928 MHz (USA) and 2.4 GHz, the
IEEE 802.15.4g standard for SUN extends the set of supported
Ultra-High Frequency (UHF) bands, adds new transmission
modes (e.g., OFDM) and extends the MAC layer
functionalities to allow the efficient and fair coexistence of
networks using different transmission modes within the same
frequency range. IEEE 802.15.14g can achieve a maximum
bitrate of 1094 kbit/s and maximum ranges in the order of tens
of kilometers.
ZigBee is a standard protocol stack brought forth by the
ZigBee Alliance consortium, which includes IEEE 802.15.4 at
the lower layers, but defining its own network and application
support layers. ZigBee, together with its ZigBee Smart Energy
application profile, were defined by the National Institute of
Standards and Technology (NIST) in USA as standards for
communications within the Home Area Network (HAN)
domain of the Smart Grid [20]. ZigBee was also selected by
many energy companies as the communication technology for
smart meters, since it provides a standard platform for data
exchange between the latter and HAN devices [21]. The
functionalities supported by the Smart Energy profile include
load management, AMR, real-time billing and text messaging
[22]. The ZigBee Alliance also developed an IP networking
specification called ZigBee IP which is based on existing
IETF protocols defined for IoT (see below). The ZigBee
Smart Energy version 2.0 specifications already make use of
ZigBee IP. It is an enhancement of the ZigBee Smart Energy
version 1 specifications, adding services for plug-in electric
vehicle (PEV) charging, installation, configuration and
firmware download, prepaid services, user information and
messaging, load control, demand response and common
information and application profile interfaces for wired and
wireless networks. The application function sets implemented
in this release were mapped to the IEC Common Information
Model [23].
WirelessHART [24] is another protocol stack, based on a
TDMA MAC protocol implemented over IEEE 802.15.4. It
was developed as an adaptation of the HART protocol defined
for wired industrial networks. While it was initially developed
by a private consortium, the stack was standardized by the
International Electrotechnical Commission (IEC) as IEC
62591. ISA100.11a is a standard protocol stack developed by
the International Society for Automation (ISA), which is
functionally very similar to WirelessHART [14].
In the meantime, IETF has defined a protocol stack
adapted to the characteristics of the IoT, which is suitable to
support Smart Grid applications in a way that is more
compatible with the standard Internet protocol stack [25]. The
core of the IoT protocol stack is IPv6 over Low power WPAN
(6LoWPAN), which specifies how to support the IPv6
protocol over low bitrate wireless technologies, such as IEEE
802.15.4. 6LoWPAN specifies the protocols and procedures
needed for address assignment and deconfliction, Ipv6 and
higher layer header compression and fragmentation. Energy
efficiency lies at the core of 6LoWPAN. Header compression
exploits the redundancy between the MAC and IPv6 header
fields – namely the addresses –, and/or simplifies the range of
IPv6 header field value options in order to achieve higher
compression rates. Regarding the routing function, the
Routing Over Low power and Lossy networks (ROLL) group
in IETF has specified the already mentioned RPL protocol
[19]. RPL is based on the formation of routing trees
designated Destination Oriented Directed Acyclic Graphs
(DODAGs), supporting the overlapping between two or more
of these, possibly with different root nodes. RPL is designed
to minimize the routing overhead in stable networks, which is
done by increasing the routing message period exponentially
when there are no topology changes. On the other hand, the
protocol keeps its responsiveness to topology changes by
restoring the initial routing update period once a topology
change is detected. As already seen, ZigBee Smart Energy
version 2.0 takes advantage of these IP-oriented
functionalities.
Besides the standard RF Mesh solutions described above,
there are a number of proprietary RF Mesh solutions that were
developed in the USA and have been enjoying significant
popularity among energy operators. These products usually
operate within the ISM frequency band of 902-928 MHz and
employ Frequency Hop Spread Spectrum (FHSS) to increase
the robustness and security of the links, namely to prevent
jamming attacks and interference from other equipment
operating in the same ISM band. Offered bitrates range
between 9.6 kbit/s and 300 kbit/s, with ranges in the order of 2
km with 1 W of transmit power. An example is the
Landis+Gyr’s Gridstream, which employs a proprietary
geographical based routing protocol in order to minimize the
routing overhead [12]. Another example is the Silver Spring
Networks solution [26].
and use of less cluttered ISM frequency bands such as the 900
MHz in the USA and 868 MHz in Europe. The main
disadvantage is, of course, the reduced bitrates as compared
with broadband RF Mesh solutions.
Some additional disadvantages can be identified for RF
Mesh solutions in general, which are the following:
•
Performance is highly dependent on the propagation and
interference environment.
•
Depending on the scenario and inter-node distances, the
deployment of additional relay nodes may be needed,
which adds to the deployment costs.
•
Wireless communications propagate through a shared
medium, which poses some threats in terms of security.
The protocol stack must implement security mechanisms
that are able to meet the requirements of the Smart Grid
applications. These requirements are often different from
application to application.
It should be noted that the European Utilities Telecom
Council (EUTC) is seeking to reserve 6 MHz in the 450-470
MHz frequency band for use by grid utility operators, together
with a frequency band above 1 GHz (e.g., 1.5 GHz band
spanning 10 MHz) [27]. In this way, both low rate and high
rate applications would be supported.
III.
COMPARATIVE ANALYSIS AND CONCLUSION
The previous section presented the state-of-the-art of
communication technologies for the LVDN. Three types of
communication
technologies
were
analyzed:
PLC,
Infrastructure-based Wireless Networks and RF-Mesh. The
main characteristics of these technologies are listed in Table I
in order to facilitate the comparison.
From the table, it can be concluded that narrowband RFMesh and NB-PLC offer the best compromise between bit
rate, range and cost, especially if the supported Smart Grid
services require only a low bit rate. Mobile cellular solutions
are easy to deploy, since mobile cellular coverage is very
extensive. However, this communication service must be paid
to the operator, which may result into significant operational
costs.
One possible adequate solution for deployment in the
LVDN might be an RF Mesh based on a Narrowband (IEEE
802.15.4g) radio, such as the XbeePro operating on the 869.4869.65 MHz band [28] as it allows 500 mW transmission
power, medium range and standard radio. RF Mesh
Narrowband does not require hiring the services of an operator
(unlike a mobile cellular solution) and it can be designed to be
fault tolerant (at least temporarily) to failures in the energy
grid (unlike PLC) if nodes are capable of energy storage
(through a small battery or supercapacitors).
However, RF Mesh may be affected by radio
communication problems. Consequently, the integration of
different technologies can bring many advantages, increasing
the robustness and reliability of the Smart Grid.
The advantages of narrowband RF Mesh solutions are
mostly related with deployment flexibility, increased range
5
TABLE I
Type
PLC
Infrastructurebased
Wireless
Networks5
COMPARISON OF COMMUNICATION TECHNOLOGIES FOR THE
LVDN IN A SMART GRID
Subtype
CAPEX
UNB
Low
NB
Low
2.5G
(GPRS)
Low
3G
(HSDPA,
HSUPA)
Low
4G
(WiMAX,
LTE)
Low
Broadband
(IEEE
802.11n/s)
Narrowband
(Silver
Spring
RF Mesh
Networks)
Maximum
Bit rate
Negligible
100 bit/s
128 kbit/s
Negligible (CENELECA)
177.6 kbit/s
downlink
High
118.4 kbit/s
uplink
42 Mbit/s
downlink
High
5.76 Mbit/s
uplink
299.6 Mbit/s
downlink
High
75.4 Mbit/s
uplink
OPEX
[7]
Range4
150 km
[8]
Several
km
[9]
Coverage
dependent
[10]
Coverage
dependent
[11]
Coverage
dependent
[12]
High
Negligible
600 Mbit/s
Hundreds
of meters
High
High (if
license is
required
from
ANACOM)
100 kbit/s
Several
km
[14]
[15]
1094 kbit/s
Several
km (e.g.,
XbeePro
868 @
24 kbit/s)
Narrowband
(IEEE
Medium
802.15.4g)
Negligible
[13]
[16]
ACKNOWLEDGEMENT
This work was partially supported by national funding
from QREN through the “Monitorização e controlo inteligente
da rede de Baixa Tensão” (MONITOR BT) project and by
FCT – Fundação para a Ciência e a Tecnologia, under project
PEst-OE/EEI/LA0021/2013.
[17]
[18]
[19]
[20]
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
N. Saputro, K. Akkaya, S. Uludag, “A Survey of Routing Protocols for
Smart Grid Communications,” Computer Networks, Elsevier, 56 (2012),
pp. 2742–2771, 2012.
X. Fang, S. Misra, G. Xue, D. Yang, “Smart Grid – The New and
Improved Power Grid: A Survey,” IEEE Communications Surveys &
Tutorials (COMST), 14(4): 944-980, IEEE, 4th Quarter 2012.
Z. Fan, P. Kulkarni, S. Gormus, C. Efthymiou, G. Kalogridis, M.
Sooriyabandara, Z. Zhu, S. Lambotharan, W. Chin, “Smart Grid
Communications: Overview of Research Challenges, Solutions, and
Standardization Activities,” IEEE Communications Surveys & Tutorials
(COMST), 15(1):21-38, IEEE, 1st Quarter 2013.
I. H. Cavdar, “A solution to remote detection of illegal electricity usage
via power line communications,” IEEE Transactions on Power Delivery,
October 2004.
M. Nassar, Y. Mortazavi, I. Kim, “Local Utility Powerline
Communications in the 3-500 kHz Band: Channel Impairments, Noise,
and Standards,” IEEE Signal Processing Magazine, IEEE, July 2012 (to
appear.)
H. Ferreira, L. Lampe, J. Newbury, and T. Swart. Power line
communications: Theory and applications for narrowband and
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
4
5
Maximum ranges are usually achieved with the lowest bitrates only.
It is assumed that the Infrastructure-based Wireless Network Service is hired
from an operator.
6
broadband communications over power lines. John Wiley and Sons,
2010.
ITU-T G.9955, “Narrowband orthogonal frequency division
multiplexing power line communication transceivers – Physical layer
specification”, ITU-T, December 2011.
ITU-T G.9956, “Narrowband orthogonal frequency division
multiplexing power line communication transceivers – Data link layer
specification”, ITU-T, November 2011.
IEEE P1901.2, “IEEE Draft Standard for Low Frequency (less than 500
kHz) Narrow Band Power Line Communications for Smart Grid
Applications”, IEEE, approved Project Authorization Request, March
2010.
ITU-T G.9963, “Unified high-speed wireline-based home networking
transceivers – Multiple input/multiple output specification”, ITU-T,
December 2011.
IEEE 802.16-2009, “IEEE Standard for Local and metropolitan area
networks Part 16: Air Interface for Broadband Wireless Access
Systems”, IEEE, May 2009.
B. Lichtensteiger et al, “RF Mesh Systems for Smart Metering: System
Architecture and Performance,” IEEE SmartGridComm 2010.
V. Gungor, B. Lu, G. Hancke, “Opportunities and Challenges of
Wireless Sensor Networks in Smart Grid,” IEEE Transactions on
Industrial Electronics, IEEE, vol. 57, no. 10, October 2010.
B. Akyol, H. Kirkham, S. Clements, and M. Hadley. “A survey of
wireless communications for the electric power system,” Prepared for
the U.S. Department of Energy, 2010.
IEEE 802.11-2012, “IEEE Standard for Information technology–
Telecommunications and information exchange between systems Local
and metropolitan area networks–Specific requirements Part 11: Wireless
LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications”, IEEE, March 2012.
IEEE 802.16j, “IEEE Standard for Local and metropolitan area networks
Part 16: Air Interface for Broadband Wireless Access Systems
Amendment 1: Multihop Relay Specification”, IEEE, June 2009.
C. Perkins et al., “Ad hoc On-Demand Distance Vector (AODV)
Routing”, RFC 3561, IETF, July 2003.
T. Clausen, P. Jacquet, “Optimized Link State Routing Protocol
(OLSR)”, RFC 3626, IETF, October 2003.
T. Winter et al., “RPL: Ipv6 Routing Protocol for Low-Power and Lossy
Networks”, RFC 6550, IETF, March 2012.
National Institute of Standards and Technology. NIST Framework and
roadmap for smart grid interoperability standards, release 1.0,
http://www.nist.gov/public_affairs/releases/upload/smartgrid_interopera
bility_final.pdf, January 2010.
H. Farhangi, “The path of the smart grid”, IEEE Power & Energy
Magazine, 8(1):18–28, 2010.
P. Yi, A. Iwayemi, and C. Zhou, “Developing ZigBee deployment
guideline under WiFi interference for smart grid applications”, IEEE
Transactions on Smart Grid, 2(1):110–120, 2011.
IEC 61970-301, “Energy management system application program
interface (EMS-API) – Part 301: Common Information Model (CIM)
Base”, IEC, Edition 1.0, November 2003.
IEC 62591, “Industrial communication networks – Wireless
communication
network
and
communication
profiles
–
WirelessHART™”, IEC, Edition 1.0, April 2010.
P. Kulkarni, S. Gormus, Z. Fan, B. Motz, “A Mesh-Radio-Based
Solution for Smart Metering Networks,” IEEE Communications
Magazine, IEEE, July 2012.
Silver Spring Networks, “Smart Grid Standards”, whitepaper,
09/04/2012.
EUTC, “Spectrum needs for Utilities”, EUTC position paper,
http://eutc.org/system/files/UTC_private_file/EUTC%20Spectrum%20P
osition%20Paper-9April2013.pdf, last access 5/09/2013.
XBeePro 868, http://www.digi.com/products/wireless-wired-embeddedsolutions/zigbee-rf-modules/point-multipoint-rfmodules/xbee-pro-868,
last access 6/09/2013
Performance Analysis and Comparison between
Legacy-PSM and U-APSD
Adriano Vinhas∗ , Vitor Bernardo∗ , Marilia Curado∗ , Torsten Braun†
∗ Center
for Informatics and Systems, University of Coimbra, Coimbra, Portugal
{avinhas,vmbern,marilia}@dei.uc.pt
† Institute for Computer Science and Applied Mathematics,
University of Bern, Bern, Switzerland
[email protected]
Abstract—This paper evaluates the performance of the most
popular power saving mechanisms defined in the IEEE 802.11
standard, namely the Power Save Mode (Legacy-PSM) and
the Unscheduled Automatic Power Save Delivery (U-APSD).
The assessment comprises a detailed study concerning energy
efficiency and capability to guarantee the required Quality of
Service (QoS) for a certain application. The results, obtained in
the OMNeT++ simulator, showed that U-APSD is more energy
efficient than Legacy-PSM without compromising the end-toend delay. Both U-APSD and Legacy-PSM revealed capability
to guarantee the application QoS requirements in all the studied
scenarios. However, unlike U-APSD, when Legacy-PSM is used
in the presence of QoS demanding applications, all the stations
connected to the network through the same access point will
consume noticeable additional energy.
Index Terms—IEEE 802.11, Energy Efficiency, Power Save
Mode, U-APSD
I. I NTRODUCTION
The usage of Wireless Local Area Networks (WLANs) has
become more and more popular worldwide, since they have
low maintenance and deployment costs while offering a good
performance (e.g., throughput and coverage) to the end-users.
The IEEE 802.11 [1] family is the most used WLAN technology. The actual IEEE 802.11 public and private infrastructure
is well disseminated, leading mobile phone vendors’ to include
this technology in almost all devices.
The IEEE 802.11 proliferation, together with the more
developed cellular networks available, has contributed to the
growth of traffic generated by mobile devices [2]. However, the
increasing growth of this kind of traffic revealed that mobile
phones with IEEE 802.11 capabilities require a higher device’s
energy consumption [3], prooving that the use of WLAN
capabilities in a mobile device has direct impact on its battery
lifetime. This limitation is mainly due to the original design
and goals of the IEEE 802.11 standard, where the energy
constraints were not fully taken into account.
The usage of IEEE 802.11 in battery powered devices
raises new challenges regarding energy consumption. Aiming
at solving these issues, the IEEE 802.11 standard [1] specifies
a Power Save Mode (referred as Legacy-PSM in this paper)
which allows the device to commute between active and doze
states. In the former, the device is able to send and receive
data, while in the latter it can not communicate with the
network. When operating in active state, the device consumes
more energy than in sleep state. In fact, the values of energy
consumption in sleep state are almost negligible [4].
The Legacy-PSM can perform well for non real-time applications, but several limitations were identified using realtime
applications, namely Video Streaming and Voice over IP
(VoIP), which are the most popular applications among mobile
end-users [2]. The Legacy-PSM specified in IEEE 802.11 is
not able to guarantee the Quality of Service (QoS) required
by these applications. Later, with the introduction of QoS
support in the standard (IEEE 802.11e [5]), a new mechanism
that uses power saving techniques while guaranteeing the
QoS requirements was proposed. This mechanism was named
Unscheduled Automatic Power Save Delivery (U-APSD) and
must be used within the QoS-aware IEEE 802.11 MAC layer,
the Enhanced Distributed Channel Access (EDCA).
This work aims to study IEEE 802.11 power saving mechanisms performance by comparing the most popular power save
schemes, namely Legacy-PSM and U-APSD. Additionally,
this assessment takes also into consideration the application
QoS requirements, evaluating the feasibility of employing
power save mechanisms in scenarios where QoS guarantees
are required. The studied power saving algorithms were implemented in the OMNeT++ simulator, and the performance
comparison between them includes the study of Quality of
Service related metrics (e.g., end-to-end delay) and energy
consumption. The analysis includes scenarios with multiple
parameters, ranging from the network level (e.g., distinct
packet sizes) to algorithm specific parameters variation, such
as wake up period.
The remaining of this paper is organized as follows. Section
II describes the IEEE 802.11 power saving mechanisms in
study, followed by the related work discussion in Section III.
Section IV depicts the performance evaluation scenario and
conditions, and discusses obtained results. Finally, Section V
concludes the paper.
II. IEEE 802.11 P OWER S AVING M ECHANISMS
This section describes the IEEE 802.11 Legacy Power Save
Mode (Legacy-PSM) and Unscheduled Automatic Power Save
Delivery (U-APSD) power saving schemes.
7
A. IEEE 802.11 Legacy-PSM
This subsection describes the IEEE 802.11 Legacy Power
Save Mode (Legacy-PSM) algorithm.
When communicating using the IEEE 802.11 standard, an
Access Point (AP) periodically broadcasts Beacon Frames.
Apart from other control related information, the Beacon
Frames also contain specific information related with the
power saving operations. In Legacy-PSM a Station (STA)
can be in two main different states: Continuous Aware Mode
(CAM) or Power Saving Mode (PSM), which is also known
as sleep mode.
When a Station (STA) is in sleep mode, the AP handles the
frames addressed to it by buffering them locally. All the STAs
operating the Legacy-PSM must wake up regularly to receive
the Beacon Frames. Therefore, the STA can recognize whether
the AP has buffered frames addressed to it by analyzing the
Traffic Indicator Map (TIM) field of the Beacon Frame.
Once a STA wakes up to receive the Beacon Frame, it might
goes back into sleep mode if there are no queued frames in the
AP to be received. The AP should always be informed about
power saving mode changes. If the STA recognizes that there
are frames buffered for it in the AP, it sends back a request
to receive those frames by transmitting a PS-Poll frame to the
AP. When the AP receives such frame, it must reply with an
Acknowledgment (ACK) or directly with a queued data frame.
If the AP has more than one frame to send for a certain STA,
it sets the MoreData flag, forcing the STA to be awake to
receive all the pending frames. If the frames stay buffered for
too long, the AP might use an aging function to delete these
frames. Due to this dependency with the Beacon Frame, a STA
operating in Legacy-PSM is characterized as reactive.
B. IEEE 802.11 U-APSD
This subsection describes the U-APSD power saving mode.
Unlike Legacy-PSM, the U-APSD does not relay on Beacon
Frames to control the stations power management. When operating in U-APSD, a STA does not need to wake up periodically
to receive the Beacon Frames. Instead, the STA has a proactive
behavior, meaning that it can wake up whenever desired.
To inform the AP about its power state, the STA sends a
trigger frame (QoS data or QoS Null messages) to it. These
trigger frames can be sent to the AP anytime and do not need
to be sent after receiving a Beacon Frame.
Upon receiving a trigger frame, if there are pending data to
the STA, the AP allocates a Service Period (SP) to the STA.
The transmission starts and the AP can send all the pending
frames, limited by the maximum service period time length,
following the Transmission Opportunity rules (TXOP).
When the service period is over, the AP informs the STA
about the Service Period (EOSP) using the Power Management
bits within the Frame Control field of transmitted frames. If
the EOSP bit is not set, the station remains awake and waits
for the other incoming frames. Once the EOSP bit is set, the
station go back into sleep.
Concerning the Quality of Service support, the usage of the
novel Enhanced Distributed Channel Access (EDCA) MAC
8
layer (mandatory to use the U-APSD protocol), also introduces
important changes in order to support the applications QoS
demands. The EDCA defines four access categories which can
be used to classify the traffic, as described in Table I.
TABLE I
EDCA ACCESS C ATEGORIES
Name
Description
Example Apps
AC BK
Background Access Category
File transfer (e.g., FTP)
AC BE
Best Effort Access Category
Browsing (e.g., HTTP)
AC VI
Video Access Category
Video streaming
AC VO
Voice Access Category
VoIP applications
Each category has a different priority (the first category
has the lowest priority and the last category has the highest
priority) which allows the traffic to be treated in a different
way according with the above categories.
III. R ELATED W ORK
This section describes the most relevant related work concerning the comparison between Legacy-PSM and U-APSD
algorithms.
In spite of both algorithms having the same approach, they
reach the same goal in different ways. Legacy-PSM takes
advantage of Beacon Frames to inform associated stations
about possible pendent information for them. In order to know
if there are buffered frames for a STA, it must wake up in
each Beacon Interval to receive the beacon frame. In U-APSD,
since the STA has power to decide whether it should wake up,
information about buffered data is only given when the STA
makes a request and informs the AP about its active state.
Perez Costa et al. [6] have studied the main difference between both algorithms and proposed a new U-APSD paradigm,
called Static U-APSD. Despite of the analysis of Legacy-PSM
and U-APSD, they use only the energy metrics to study the
impact of varying the number of stations associated to a single
AP. Therefore, they do not study the impact of varying beacon
interval in Legacy-PSM or wake up period in U-APSD in the
total energy consumption and end-to-end delay.
The QoS requirements within power saving algorithms were
studied by CampsMur et al. [7], where the authors’ analyze the
performance of distinct QoS demanding applications. In this
work, the authors have employed VoIP traffic, using G.711
codec, and evaluated the application performance regarding
various QoS requirements. Nevertheless, the simulation results
presented do not take into account the possibility of a STA
running various applications at the same time, but consider
only that a STA can just be receiving data belonging to a
single Access Category.
Others in the literature [8][9][10] have proposed enhancements to standard Legacy-PSM, while suggesting some drawbacks of employing U-APSD due to unfairness or starvation
problems. Nevertheless, those works do not perform a proper
comparison between their power saving proposals against both
Legacy-PSM and U-APSD standards.
The next section presents the results obtained from the performance evaluation of Legacy-PSM and U-APSD algorithms.
TABLE II
OMN E T++
SIMULATION PARAMETERS
Parameter
Value
This section shows the performance evaluation of the power
saving mechanisms in study. First, the simulation scenario
and configuration parameters are described, followed by the
experimental results analysis and discussion.
OMNeT++ version
4.3
INET version
2.1.0
Simulation time
300 seconds
Repetitions
15
A. Simulation Scenario and Parameters
IEEE 802.11 standard
“g” and “e”
Default regular wake up interval
100 ms
Power while transmitting
2000 mW
Power while receiving
1500 mW
Power while idle
300 mW
Power while sleep
20 mW
IV. P ERFORMANCE E VALUATION
This subsection depicts the simulation scenario used and
presents the relevant parameters configured. The study goal is
to provide a comparison between Legacy-PSM and U-APSD
using energy consumption and end-to-end delay as metrics.
The simulations were performed using OMNeT++ 4.3
simulator [11]. OMNeT++ is an open-source simulator that
contains several frameworks such as INET [11][12], which
implements several protocols and standards, including TPC/IP
and wireless networks support. The choice of OMNeT++ as
the simulator to carry on the tests was twofold. First, there
is an implementation of Legacy-PSM which was previously
validated and tested [13]. Second, a multimeter like model
implementation is also available for INET framework version
2.1.0 [13]. The U-APSD was implemented also within the
INET framework 2.1.0.
The simulation scenario used is illustrated in Figure 1.
Server
beacons. It is possible that a STA does not wake up to receive
all the beacons, but in this work we assume that a STA will
always wake up to receive all the beacons. When using UAPSD, the regular wake up period is defined by the STA,
as already discussed in Section II-B. Additionally, a scenario
where power saving mechanism were not employed (i.e., NoPSM scenario) is also discussed.
The end-to-end delay (milliseconds) achieved for all the
tested scenarios (No-PSM, Legacy-PSM and U-APSD) is
depicted in Figure 2, where the x-axis shows the distinct
regular wake up periods studied in milliseconds.
Access Point
Algorithm:
No PSM
PSM
U−APSD
150
Core Network
135
120
IEEE 802.3
Fig. 1. OMNeT++ simulation scenario
Table II describes the simulation parameters used, such as
power values used [14], IEEE 802.11 standard and Beacon
Interval. Although some of the parameters are changed to
provide a detailed study (e.g. Beacon Interval), when the
parameters are not changed, a base value is used (the value
showed in Table II) to guarantee a standard of values in order
to provide a comparison between the different tests.
All the results depicted in the following sections include 15
runs using different random seed numbers with a confidence
interval of 95%.
B. Regular wake up period
This subsection discusses the impact of regular wake up
period in Legacy-PSM and U-APSD algorithms. For the
Legacy-PSM, the regular wake up period was studied defining
distinct beacon intervals in the access point, since according
to the protocol each station must wake up to listen to the
105
Delay (milliseconds)
Station
90
75
60
45
30
15
0
20
40
60
80
100
120
Regular Wake Up Interval (milliseconds)
Fig. 2. End-to-end delay for distinct wake up periods
As expected, the No-PSM mechanism is not affected by
the regular wake up period (i.e., different beacon interval in
this scenario), since the STA is always awake and ready to
receive or send information to the network. In Legacy-PSM
and U-APSD scenarios, the end-to-end delay is influenced by
the regular wake up period. When compared with U-APSD,
the Legacy-PSM has a lower average end-to-end delay, but the
maximum delay is always higher. This can be explained by the
9
No PSM
Legacy PSM
U−APSD
119.08
119.06
119.04
119.02
119.00
118.99
118.98
119.10
140
120
68.53
68.51
68.50
68.47
68.45
68.43
68.42
80
68.42
100
60
9.80
9.78
9.74
9.72
9.68
20
9.82
40
9.67
119.11
Algorithm:
9.68
U−APSD
119.52
Legacy PSM
118.84
No PSM
120.22
121.61
140
125.80
Algorithm:
This study was made with distinct packet size values and a
fixed sending interval of 40ms. An additional scenario with
No-PSM mechanism was also studied, referred as No-PSM
scenario.
The energy consumption results are presented in Figure 4.
The y-axis depicts the total energy consumption in Joule and
the x-axis shows the different packet sizes tested, in Bytes.
Total Energy Consumption (Joule)
TXOP concept implemented in EDCA, which gives advantage
to U-APSD when sending queued frames to the STA.
To keep the end-to-end delay within the acceptable bounds,
the Legacy-PSM must change the AP beacon interval. This
need represents an extra overhead for all the STAs connected
to the AP, since they must wake up to receive more information. Moreover, it also increases the overall network collision
probability, because the medium will be busy for longer
periods. This behavior can be observed when the regular wake
up period is defined with lower values (e.g., 20ms). In this
case the Legacy-PSM performance is worst than with UAPSD, which is able to keep the end-to-end delay within the
acceptable bounds.
The energy consumption for the already presented scenario
is illustrated in Figure 3. The y-axis shows the total energy
consumption in Joule, while the x-axis shows the different
wake up periods tested.
0
100
200
400
600
800
1000
1200
70.01
69.13
70.88
69.46
Fig. 4. Total energy consumption for distinct packet sizes
31.84
60
11.16
11.98
13.25
15.27
19.45
40
20
0
20
40
60
80
100
120
Regular Wake Up Interval (milliseconds)
Fig. 3. Energy consumption for distinct wake up periods
The No-PSM scenario energy consumption is higher than
both Legacy-PSM and U-APSD, showing the need to employ
these mechanisms in order to save energy. By analyzing
Legacy-PSM and U-APSD, it is possible to observe a lower
energy consumption of the U-APSD algorithm in all the
cases. The Legacy-PSM needs almost 4 times more energy
for scenarios with wake up period ≥ 40ms and roughly 2.5
times more when the wake up period is lower (i.e. wake up
period = 20ms).
In short, the U-ASPD outperforms the Legacy-PSM, since
it is able to reach almost the same performance (i.e., delay)
using less energy. The U-APSD has also benefits regarding the
network congestion, since the beacon interval does not need
to be changed. Moreover, unlike U-APSD, using the LegacyPSM all the STAs must have the same wake up period.
C. Study of Packet Size
This subsection studies the impact of varying the packet size
for both Legacy-PSM and U-APSD power saving mechanisms.
10
100
Packet Size (B)
72.65
80
50
76.04
120
With the Legacy-PSM it is possible to see that energy
consumption in No-PSM scenario is higher than both LegacyPSM and U-APSD, showing the need to employ the power
saving mechanisms of the IEEE 802.11 technology. Regarding
the Legacy-PSM and U-APSD power saving mechanisms, UAPSD saves more energy than Legacy-PSM for each one of
the packet size values used. Legacy-PSM performs the tests
needing approximately 4 times more energy than U-APSD.
By analysing these results, it is possible to observe that
packet size has a minor impact on the STA overall energy
consumption, following the results shown in a testbed analysis
performed by Bernardo et al. [4].
Aiming to evaluate the energy cost of receiving information
from the AP, the results of energy consumption per byte are
illustrated in Figure 5. The y-axis shows the energy required to
receive each byte in Joule, while the x-axis depicts the packet
sizes variation.
The results also show that lower packet sizes require more
energy per byte than higher packet sizes. This observation
encourages the employment of aggregation techniques on
the IEEE 802.11 technology, in order to reduce the energy
consumption per byte. The usage of MAC layer aggregation
techniques allows to transmit several frames in a single MAC
frame. As the packet size only slightly influences the STA
energy consumption, this technique allows to reduce the total
energy consumption while contributing to reduce the medium
overhead and collisions [15].
Algorithm:
No PSM
Legacy PSM
150
U−APSD
140
10.0
130
9.5
9.0
120
110
8.0
100
7.5
Delay (miliseconds)
Energy Consumption per Byte (Joule)
8.5
7.0
6.5
6.0
5.5
5.0
4.5
4.0
90
80
70
60
50
3.5
40
3.0
30
2.5
2.0
20
1.5
10
1.0
0.5
0
0.0
50
100
200
400
600
800
1000
PSM with
Wake Up interval = 20ms
1200
Packet Size (B)
D. Study of QoS requirements guarantees
This subsection studies the QoS requirements guarantees
for both Legacy-PSM and U-APSD by emulating the main
characteristics of the G.711 voice codec [16]. Regarding the
end-to-end delay metrics studied, this codec has a maximum
acceptable end-to-end delay of 150ms defined by the ITU-T
Y.1541 recommendation [17].
In order to emulate a more realistic scenario, three other
applications were used to create background traffic. Each
application was used in a distinct Access Category, different
from the one to be used for the VoIP service. This scenario
creates a more realistic network, since the Access Point must
deal with different applications priorities.
The end-to-end delay (milliseconds) achieved for both
Legacy-PSM and U-APSD is depicted in Figure 6. The x-axis
shows the different access mechanisms used with the power
saving mode referred in the graphic subtitle. As Legacy-PSM
does not support traffic prioritization, it is only possible to
classify traffic in a single class. In the U-APSD case, it does
support traffic prioritization as it operates together with EDCA
mechanism, explaining the reason why it appears the box plot
related with access category used by the VoIP application in
the Figure 6.
Three different scenarios were taken into account to make
this study. The first one is the employment of Legacy-PSM
with the default Beacon Interval indicated on Table II. The
second one is also a Legacy-PSM scenario with a Beacon
Interval value of 20ms. Lastly, an U-APSD scenario was
analysed, with a regular wake up period of 20ms.
The Legacy-PSM scenario with beacon interval value of
100ms has higher delay values when compared within the
other two scenarios, showing the need to change the beacon
interval in order to keep end-to-end delay values within the
acceptable bounds.
The other Legacy-PSM scenario is a consequence of this
conclusion since the end-to-end delay is lower in this sce-
U−APSD with
Algorithm
Fig. 6. QoS requirements guarantees on PSM and U-APSD end-to-end delay
nario. However, reducing the beacon interval introduces more
overhead in the network since the STA is trying to listen for
a number of beacons 5 times higher than the Legacy-PSM
scenario with beacon interval value of 100ms.
The results show that all scenarios guarantee a good operation of the VoIP application since the end-to-end delay
does not reach the maximum end-to-end delay acceptable for
applications which use the G.711 voice codec. However, the
Legacy-PSM scenario with a beacon interval value of 100ms
almost reaches this limit since it obtains higher end-to-end
delay values when compared with the others.
The energy consumption for the scenarios described is
illustrated on Figure 7. The y-axis shows the total energy
consumption in Joule, while the x-axis indicates the different
scenarios studied.
80
75
74.76
73.00
70
65
Fig. 5. Energy Consumption per byte for distinct packet sizes
PSM with
60
55
50
45
40
35
30
25
22.13
20
15
10
5
0
PSM with
PSM with
U−APSD with
Algorithm
Fig. 7. Impact of running a VoIP application in PSM and U-APSD Energy
Consumption
11
It is possible to see the consequence of sending more
beacons. Besides introducing more overhead in the network,
the Legacy-PSM scenario with a Beacon Interval value of
20ms also causes the STA to be in sleep mode for less time.
That is why energy consumption values are lower for the
Legacy-PSM scenario with Beacon Interval value of 100ms.
Concerning the U-APSD scenario, it presents the lowest
energy consumption values as in all the previous studies.
V. C ONCLUSIONS
The constant growth of traffic generated by mobile devices
in the last years, together with the increasing number devices
using IEEE 802.11 capabilities, created new challenges regarding the standard power saving protocols. Apart from avoid
the devices’ batteries from running out in a short time, these
protocols must also be able to guarantee certain Quality of
Server for a range of applications, particularly for the realtime ones. This paper evaluates the performance of two power
saving mechanisms defined in IEEE 802.11 standard (LegacyPSM and U-APSD) in order to fulfill those challenges.
The obtained results comparing Legacy-PSM and U-APSD
showed that U-APSD is more energy efficient, while keeping
better application performance. When analyzing the energy
consumption, the results revealed that Legacy-PSM needs
roughly 4 times more energy than U-APSD for scenarios with
wake up period ≥ 40ms and roughly 2.5 times more when the
wake up period is equal to 20ms.
Concerning the QoS requirements, U-APSD revealed the
capability to guarantee Quality of Service for the studied realtime applications, as the obtained end-to-end delay is lower
than the maximum acceptable end-to-end delay allowed in
ITU-T Y.1541 recommendation.
ACKNOWLEDGMENTS
This work was partially supported by the COST framework,
under Actions IC0804 and IC0906, as well as by the iCIS
project (CENTRO-07-ST24-FEDER-002003), co-financed by
QREN, in the scope of the Mais Centro Program and European
Union’s FEDER, and by industrial partners (ISA, OneSource)
and COMPETE program in the scope of SI I&DT sMeter
project (“Integrated Platform for Energy Efficiency and Smart
Metering”, contract n. 21588, QREN FCOMP-01-02)
The second author was also supported by the Portuguese
National Foundation for Science and Technology (FCT)
through a Doctoral Grant (SFRH/BD/66181/2009).
[4] V. Bernardo, M. Curado, T. Staub, and T. Braun, “Towards energy
consumption measurement in a cloud computing wireless testbed,”
in Network Cloud Computing and Applications (NCCA), 2011 First
International Symposium on, pp. 91–98, 2011.
[5] “Ieee standard for information technology - telecommunications and
information exchange between systems - local and metropolitan area
networks - specific requirements part 11: Wireless lan medium access
control (mac) and physical layer (phy) specifications amendment 8:
Medium access control (mac) quality of service enhancements,” IEEE
Std 802.11e-2005 (Amendment to IEEE Std 802.11, 1999 Edition (Reaff
2003), pp. 0 1–189, 2005.
[6] X. P. Costa, D. Camps-Mur, and A. Vidal, “On distributed power saving
mechanisms of wireless lans 802.11e u-apsd vs 802.11 power save
mode.,” Computer Networks, vol. 51, no. 9, pp. 2326–2344, 2007.
[7] X. Perez-Costa and D. Camps-Mur, “Ieee 802.11e qos and power saving
features overview and analysis of combined performance [accepted from
open call],” Wireless Communications, IEEE, vol. 17, no. 4, pp. 88–96,
2010.
[8] Y. He, R. Yuan, X. Ma, J. Li, and C. Wang, “Scheduled psm for
minimizing energy in wireless lans,” in Network Protocols, 2007. ICNP
2007. IEEE International Conference on, pp. 154–163, 2007.
[9] E. Rozner, V. Navda, R. Ramjee, and S. Rayanchu, “Napman: networkassisted power management for wifi devices,” in Proceedings of the 8th
international conference on Mobile systems, applications, and services,
MobiSys ’10, (New York, NY, USA), pp. 91–106, ACM, 2010.
[10] A. J. Pyles, Z. Ren, G. Zhou, and X. Liu, “Sifi: exploiting voip silence
for wifi energy savings insmart phones,” in Proceedings of the 13th
international conference on Ubiquitous computing, UbiComp ’11, (New
York, NY, USA), pp. 325–334, ACM, 2011.
[11] A. Varga and R. Hornig, “An overview of the omnet++ simulation
environment,” in Proceedings of the 1st international conference on
Simulation tools and techniques for communications, networks and
systems & workshops, Simutools ’08, (ICST, Brussels, Belgium, Belgium), pp. 60:1–60:10, ICST (Institute for Computer Sciences, SocialInformatics and Telecommunications Engineering), 2008.
[12] “INET framework main page.” http://www.inet.omnetpp.org/.
[13] V. Bernardo, M. Curado, and T. Braun, “Enhancing ieee 802.11 energy
efficiency for continuous media applications,” in EE-LSDS 2013, Energy
Efficiency in Large Scale Distributed Systems conference, vol. 8046,
(n/a), pp. 1–15, Lecture Notes in Computer Science, Vol. 8046, April
2013.
[14] D. Camps-Mur, M. D. Gomony, X. P. Costa, and S. S. Ribes, “Leveraging 802.11n frame aggregation to enhance qos and power consumption
in wi-fi networks,” Computer Networks, vol. 56, no. 12, pp. 2896–2911,
2012.
[15] D. Skordoulis, Q. Ni, H.-H. Chen, A. Stephens, C. Liu, and A. Jamalipour, “IEEE 802.11n MAC frame aggregation mechanisms for nextgeneration high-throughput WLANs,” Wireless Communications, IEEE,
vol. 15, pp. 40–47, Feb. 2008.
[16] I. T. Recommendation, “ITU-T recommendation G.711. Pulse code
modulation (PCM) of voice frequencies,” Nov. 1988.
[17] I. T. Recommendation, “ITU-T recommendation Y.1541: Network Performance Objectives for IP-Based Services,” tech. rep., International
Telecommunication Union, 2003.
R EFERENCES
[1] “Ieee standard for information technology–telecommunications and
information exchange between systems local and metropolitan area
networks–specific requirements part 11: Wireless lan medium access
control (mac) and physical layer (phy) specifications,” IEEE Std 802.112012 (Revision of IEEE Std 802.11-2007), pp. 1–2793, 2012.
[2] Cisco,
“Cisco
Visual
Networking
Index:
Global
Mobile
Data
Traffic
Forecast
Update,
2012–2017.”
http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns7
05/ns827/white paper c11-520862.html, February 2013.
[3] G. Li, Z. Xu, C. Xiong, C. Yang, S. Zhang, Y. Chen, and S. Xu, “Energyefficient wireless communications: tutorial, survey, and open issues,”
Wireless Communications, IEEE, vol. 18, no. 6, pp. 28–35, 2011.
12
Gestão de Cargas numa Micro Grid Utilizando
Algoritmos Genéticos
Jorge Eduardo
Pedro Cardoso
Jânio M. Monteiro
Instituto Superior de Engenharia
Faro, Portugal 8005-139
Email: [email protected]
Resumo—O sistema de produção de energia elétrica tem até
hoje caraterizado-se por um esquema de geração centralizado,
unidirecional e contendo medidas de incentivo e controlo sobre
a procura de consumo. Com o recente desenvolvimento de novos
equipamentos de geração e controlo verifica-se uma mudança
gradual deste modelo para outro denominado de Smart Grid,
em que a geração de eletricidade distribuı́da, geralmente de
baixa potência, começa a integrar-se de uma forma eficaz com
a rede já existente e não apenas com a entrega da eletricidade
produzida. Uma das medidas que pode ser implementada para
que se promova um ajuste no lado do consumo por forma a que
este se nivele a uma potência produzida que varia em função
de fatores ambientais, baseia-se na implementação de tarifários
variáveis. Mas para que tal venha a ser possı́vel é necessário
desenvolver uma série de equipamentos que consigam comunicar
entre si e com a rede de distribuição, utilizando protocolos
normalizados, gerindo os consumos de uma forma otimizada em
função dos tarifários previstos e refletindo as preferências dos
utilizadores. Neste âmbito, o objetivo deste artigo é o de definir
e avaliar uma solução de otimização aplicada à gestão de cargas
em Smart Grids baseada em algoritmos genéticos, que em função
de restrições impostas pelo utilizador defina o escalonamento de
funcionamento de diversas cargas.
Palavras-chaves: Smart Grids, Home Grids, Micro Grids,
Algoritmos Genéticos.
I.
I NTRODUÇ ÃO
Nas redes de produção e distribuição de energia elétrica
encontramos atualmente um dinamismo bastante diferente daquele que encontrávamos há uns anos atrás, resultante em
grande parte da crescente introdução de fontes de energia
renováveis. Ao contrário da distribuição elétrica clássica, na
produção obtida a partir de energias renováveis, os fatores
ambientais de que elas dependem causam variações na geração
difı́ceis de controlar, que por sua vez, são a causa de ineficiências e desadaptações de diversa ordem.
Diversas soluções têm sido apontadas neste âmbito. Algumas propostas apontam para que se promova um ajuste no
lado do consumo por forma a que este se nivele à potência
produzida. Outras soluções apontam para que se armazene
a energia produzida em excesso em determinado momento,
recorrendo entre outros, às baterias dos automóveis elétricos.
Há ainda soluções que optam por tarifar a produção para
autoconsumo privado, de sistemas ligados à rede energética,
numa tentativa de limitar a generalização destes equipamentos
e reduzir os riscos de desestabilização, tal como aconteceu
recentemente em Espanha [1].
Se por um lado a produção desregulada pode ser vista
como um risco, o ajuste do consumo em momentos de pico
é visto como algo desejável por parte dos operadores de
eletricidade. Assim, a primeira versão do protocolo Open
Automated Demand Response (openADR) [2] surgiu como
uma das medidas que poderia minimizar os apagões verificados
na crise energética vivida no ano 2000, no estado da Califórnia.
Em termos de tarifários de eletricidade, existe uma clara
desadaptação entre os preços dos tarifários dos utilizadores
e os custos marginais de produção [3]. Uma solução que
poderia resolver este problema passa pela introdução de tarifários dinâmicos, que estão neste momento a ser testados
e implementados em várias regiões dos Estados Unidos da
América, a par da instalação de 27 milhões de contadores
inteligentes já efetuada [4].
Assim, pretende-se comunicar aos equipamentos e pessoas
o tarifário em vigor para que estas decidam em consonância.
Neste contexto, as tecnologias associadas às Smart Grids
surgem como a solução que a médio/longo prazo permitirão
a gestão eficiente das redes energéticas equipadas de geração
renovável, através de equipamentos que combinem as redes
de distribuição elétrica, as redes de comunicação, as redes
de sensores e as tecnologias de informação, criando uma
plataforma de configuração fácil e acesso ubı́quo.
Neste sentido, o objetivo de criação de um sistema de
gestão de energia é o de implementar um conjunto de equipamentos que comuniquem entre si, chamados objetos inteligentes [5], que atuando num sistema de controlo otimizado
suportado no conceito da Internet of Things (IoT), permitam
um melhor aproveitamento da energia produzida pelas energias
renováveis e a melhoria da gestão energética de edifı́cios.
No âmbito dos protocolos que podem ser utilizados para
gestão energética salientam-se as recentes especificações das
arquiteturas protocolares Smart Energy Profile – versão 2 (SEP
2.0) [6], IEEE 1888 [7] e do protocolo OpenADR 2.0 [8].
Qualquer arquitetura protocolar que venha a ser implementada
não pode por isso ser criada sem ter em conta essas soluções.
A um nı́vel mais baixo salientam-se também o conjunto de
protocolos IPv6 e 6LoWPAN que cada vez mais assumem importância em redes com elevado número de objetos inteligentes
13
capazes de comunicar entre si, sobre redes com ou sem fios.
Por fim, suportando-se nas tecnologias de informação, o
sistema deverá fazer do utilizador o elemento chave da solução
final. Para tal, deverá ser criada uma interface que lhe permita
de uma forma fácil aceder, configurar e modificar sempre que
seja necessário as suas preferências. Por exemplo cabe ao
utilizador especificar que a temperatura da água quente não
deve baixar dos 30 graus, ou que o programa da máquina de
lavar a louça deve terminar antes das 19:00. Ao utilizador cabe
a definição das restrições a que o sistema deverá responder,
sendo o primeiro liberto da gestão do sistema. Essa gestão
deverá ser feita utilizando algoritmos de otimização que, tendo
em conta os tarifários e comunicando com os diversos objetos
inteligentes de uma Home/Micro Grid decidam que cargas
devem entrar em funcionamento e em que alturas o devem
fazer. É este o âmbito deste artigo.
O resto do artigo tem a seguinte estrutura. A secção II
apresenta o conjunto de protocolos de comunicação atualmente
em definição para Smart Grids. A secção III apresenta os
algoritmos de otimização considerados neste artigo, nomeadamente os algoritmos genéticos. A secção IV faz a descrição
e formulação do problema do controlo de cargas. A secção
V descreve os testes e ensaios efetuados. Por fim, a secção
VI conclui o artigo apontando possı́veis desenvolvimentos
futuros.
II.
P ROTOCOLOS DE C OMUNICAÇ ÃO EM S MART G RIDS
A possibilidade de os utilizadores gerirem os seus consumos de energia em função da produção é uma caracterı́stica
crı́tica das Smart Grids sendo a base de inovação, novos
produtos e serviços. Por forma a suportar esta capacidade, a
comunicação entre os diversos dispositivos, tais como contadores, eletrodomésticos, veı́culos elétricos, sistemas de gestão de
energia e recursos energéticos distribuı́dos (incluindo energias
renováveis e armazenamento) deve ocorrer utilizando procedimentos abertos, seguros e normalizados. Neste âmbito, foram
recentemente definidos vários protocolos.
Um desses protocolos, o Smart Energy Profile resulta da
colaboração entre low-power ZigBee, o Wi-Fi e a Home Plug
power-line technologies, construindo uma arquitetura de gestão
de energia para Micro Grids, suportada em redes IP. Assim, ao
contrário do SEP 1.0 que considerava apenas o ZigBee como
forma de interligação entre objetos inteligentes, nesta última
versão as comunicações já incluem ligações Wi-Fi e PLC. O
Smart Energy Profile foi desenhado para implementar uma
arquitetura REST, tendo como base as ações do GET, HEAD,
PUT, POST e DELETE, complementadas com um mecanismos
de subscrição leve. Apesar do SEP se poder suportar em
qualquer protocolo que implemente uma comunicação REST
(por exemplo o Constrained Application Protocol (CoAP) [9])
o HTTP é considerado a base para a interoperabilidade das
aplicações.
Em março de 2011, o Institute of Electrical and Electronics
Engineers (IEEE), a maior associação profissional do Mundo
anunciou a aprovação e publicação da norma Standard for Ubiquitous Green Community Control Network Protocol (IEEE
1888TM ), no âmbito da Ubiquitous Green Community Control
Network Protocol (UGCCNet). Com origem na China, a norma
14
IEEE 1888 assume-se como uma norma global no âmbito da
IoT que tem como objetivo a eficiência energética, através da
gestão das energias renováveis (dita green energy), através da
comunicação utilizando protocolos Internet e as Tecnologias
de Informação e Comunicação.
Como fundamento da especificação das normas, está a
intenção de criar um novo sistema de controlo fácil de
utilizar, largamente divulgado e inteligente, incluindo: a
fácil monitorização do consumo, análise dos desperdı́cios
energéticos e sugestões de melhoria, controlo automático de
ı́ndices de conforto (CI), ajuste produção-consumo, entre outros.
Várias sub-normas IEEE 1888 estão atualmente em
definição, identificadas como IEEE 1888.x, com x a variar
entre 1 e 4.
O protocolo de aplicação Open Automated Demand Response (OpenADR) versão 2.0 [8], é uma evolução e extensão
da primeira versão desenvolvida pela Demand Response Research Center no Lawrence Berkeley National Laboratory.
OpenADR 2.0 é suportado pela aliança industrial OpenADR,
tendo sido desenvolvida como parte da norma OASIS Energy
Interoperation 1.0 publicada em Fevereiro de 2012.
Uma caracterı́stica que diferencia o OpenADR de outras
arquiteturas que implementam o Demand Response (DR) automatizado é a de que os pedidos não contêm informação
que especifique os dispositivos ou operações que devem ser
alteradas ou paradas. O OpenADR apenas notifica os dispositivos para que estes reduzam o consumo – quer utilizando
pedidos especı́ficos ou através de um aumento no preço da
eletricidade. As respostas dos equipamentos dependem sempre
das preferências diretas ou indiretas do utilizador. Para além
disso, as mensagens OpenADR permitem aos utilizadores individualmente responderem aos pedidos de Demand Response
com um sinal de “opt out”, o que aumenta ainda mais a
flexibilidade dada às opções dos utilizadores. O resultado é um
sistema que promove a DR automatizada, enquanto maximiza
a flexibilidade local em resposta aos pedidos.
O núcleo da norma OpenADR 2.0 é constituı́do por um
conjunto de modelos de dados e padrões de troca que definem os sinais de DR e as interfaces entre: mercados de
energia (no sentido de suportarem uma informação de preço
dinâmico), Independent System Operators (ISO), Distributed
Energy Resources (DER) e consumidores de energia (industriais/residenciais).
Se por um lado os protocolos que permitem a comunicação
entre os diversos equipamentos de uma Micro Grid estão a ser
definidos, há ainda que definir os procedimentos de controlo de
cargas otimizados que permitam o ajuste DR. Esse é o âmbito
das próximas secções.
III.
A LGORITMOS DE OTIMIZAÇ ÃO
Em matemática, o termo otimização, refere-se ao estudo
de problemas em que se busca minimizar ou maximizar uma
função através da escolha sistemática dos valores de variáveis
reais ou inteiras dentro de um conjunto viável.
Para a resolução destes problemas, além de possı́veis
métodos especı́ficos, existem métodos genéricos de
otimização, usualmente designados de meta-heurı́sticas,
que podem aproximar as soluções dos problema que se
consigam modelar de acordo com estruturas de dados
adequadas. Exemplos são os Algoritmos Genéticos (AG)
[10], os algoritmos baseados em colónias de formigas (Ant
colony Optimization) [11] ou os algoritmos Particle Swarm
Optimization [12].
Em particular neste artigo dedicaremos a nossa atenção
aos AGs. O processo evolutivo dos AG começa por uma
população (ou geração) inicial, formada por um conjunto de
indivı́duos que representam soluções do problema a otimizar.
Em geral, a população inicial é definida aleatoriamente, usando
heurı́sticas, ou soluções conhecidas. As gerações seguintes
são obtidas iterando sobre os passos que se seguem até se
verificar o critério de paragem especificado. Começa-se por
avaliar os indivı́duos da geração de forma a definir a sua
“qualidade” dentro da população. No passo seguinte alguns dos
indivı́duos são selecionados de acordo com as suas aptidões,
i.e., quanto melhores forem os indivı́duos mais chances terão
de serem escolhidos para o efetuarem o cruzamento. Na
fase do cruzamento são criados novos indivı́duos, os filhos,
que combinam as caraterı́sticas dos pais. A alguns desses
novos indivı́duos são aplicadas mutações de modo a evitar a
estagnação da população e consequente convergência prematura. Os indivı́duos obtidos são agora colocados numa nova
população com tamanho igual ao da população original. O
processo pode ser resumido de acordo com o Algoritmo 1.
Algoritmo 1 Algoritmo genético
1: Gerar a população inicial.
2: Enquanto critério de paragem não for satisfeito faça
3:
Avaliar cada indivı́duo da população.
4:
Seleccionar os indivı́duos mais aptos.
5:
Criar novos indivı́duos aplicando os operadores: cruzamento e mutação.
6:
Armazenar os novos indivı́duos numa nova população.
7: Fim Enquanto
8: Devolve a melhor solução encontrada
Na seção seguinte iremos apresentar uma formulação para
problema da gestão eficiente de energia e discutir a solução
implementada.
IV.
D ESCRIÇ ÃO E FORMULAÇ ÃO DO P ROBLEMA
A. Formulação do Problema
O objetivo de um sistema de controlo de cargas é o de
minimizar os custos do consumo de eletricidade de diversos
aparelhos deslocando-os no tempo (ou ajustando a potência
consumida). O sistema deverá procurar minimizar o custo em
função do tarifário em vigor. Para além disso, o sistema deve
impedir em cada momento que o consumo exceda a potência
contratada.
Deste modo são vários os objetivos, dos quais podemos
destacar: minimizar o custo dos consumos de diversos equipamentos; não exceder a potência contratada; evitar exceder em
consumo a potência produzida por fontes renováveis, quando
existentes; utilizar tanto quanto possı́vel as tarifas económicas;
ter em conta as restrições temporais impostas pelo utilizador
para cada um dos equipamentos.
B. Descrição do Simulador
O sistema que se pretende implementar pode ser visto
como um sistema em que cada objeto (contadores, geradores
e consumidores) é um agente dentro do Sistema Multi-Agente
(SMA)[13]. Nesse sentido, o simulador foi implementado
como um sistema semidistribuı́do, em que o processo de
otimização é controlado por um agente central que comunica
e decide os perı́odos de funcionamento dos outros agentes
usando um algoritmo genético. Como benefı́cio, o sistema
distribuı́do pode fornecer redundância, flexibilidade e adaptabilidade. No nosso caso, trata-se de um sistema bastante flexı́vel
quando consideramos a adição ou remoção de novos objetos
produtores ou consumidores, que é feita de forma transparente.
Salientamos que foi ponderado um processo de otimização
distribuı́do, usando processos de negociação de perı́odos de
funcionamento entre agentes, mas que nesta fase foi deixado para trabalho futuro. Utilizando o sistema hı́brido que
esboçamos, consegue-se tirar partido das caracterı́sticas dos
sistemas centralizados que permitem exercer um controlo mais
rı́gido sobre os objetos, pois exige que todas as comunicações
e decisões passem por um único objeto centralizador, não
perdendo a flexibilidade associada à volatilidade dos restantes
agentes.
Como referido, neste trabalho foi implementado um sistema semidistribuı́do em que todos os agentes consumidores
respondem ao sincronismo de um agente central, o gestor
de cargas. Este agente coordena a actividade dos restantes
e contabiliza os custos. Cada um dos outros agentes está
encarregue de guardar o seu histórico de utilização e informar
o centralizador das suas potências.
Relativamente ao simulador este foi implementado sobre a
plataforma SPADE (Smart Python Multi-Agent Development
Environment) [14], [15]. O SPADE foi constuı́do à volta
da framework de comunicação XMPP/Jabber. Desenvolvido
em Python, trata-se de um sistema particularmente útil na
implementação de SMA, suportando os conceitos de agente
e servidores, a comunicação entre agentes desenvolvidos em
múltiplas linguagens de programação, processamento de comportamentos e o protocolo de comunicação extensı́vel baseado
em XML. O SPADE segue ainda as especificações FIPA para
SMA [16].
Quanta à implementação do simulador foi considerada a
sequência de passos que a seguir descrevemos. O processo
começa com o gestor de cargas (GC) a enviar uma mensagem
em broadcast para todos os equipamentos de consumo, com
a requisição dos pedidos de funcionamento dos equipamentos,
horário de inı́cio pretendido, limite para terminar o programa,
além do seu registo de consumo previstos ao longo do tempo.
Para efeitos de simulação, foi estipulado que esta requisição
é enviada às 7h00. O GC aguarda pelas respostas dos agentes
e após as ter recebido com os dados requisitados, efetua
o escalonamento dos horários de inı́cio de funcionamento
das máquinas. Como já referimos, neste escalonamento é
aplicado um AG. A informação do escalonamento (horários
de ı́nicio) é depois enviada a cada um dos consumidores.
15
Figura 1.
Diagrama da sequência de mensagens entre o gestor de cargas e os consumidores.
Cada equipamento consumidor guarda o horário de inı́cio de
funcionamento e envia mensagem de Acknowledgement para o
gestor de cargas. A partir daı́ o gestor de cargas passa a enviar
apenas mensagem de sincronismo. Quando o equipamento
consumidor atinge o horário de inı́cio de funcionamento passa
a enviar os seus dados de consumo até terminar o perı́odo de
operação.
Relativamente ao AG foi usado a framework PyEvolve [17]
com os indivı́duos codificados como listas de inteiros correspondentes ao inı́cio do programa da máquina consumidora. A
configuração usada inclui o método de seleção uniforme, o
operador de cruzamento de ponto único e os operadores de
mutação swap e Gaussiano inteiro.
Na Figura 1 está resumida sequência que acabámos de
descrever.
V.
T ESTES E E NSAIOS
Por forma a confirmar a fiabilidade do simulador desenvolvido fez-se uma análise gradual de testes com o objetivo
de verificar o procedimento de cálculo do custo e o correcto
posicionamento das cargas.
Admitindo uma potência contratada de 3.3 kVA, foi considerado um valor unitário para o factor de potência (PF),
resultando na potência ativa de 3.3 kW.
Admitindo que numa habitação ou empresa existirão cargas
que não são controláveis, o sistema de controlo de carga irá
ajustar a soma das potências das cargas controláveis para que
esta não ultrapasse uma percentagem da potência contratada
16
(por exemplo 0.80), evitando assim o deslatre dos circuitos
quando as cargas não controláveis aumentem de potência.
Para efeitos de testes foi considerado um tarifário com três
tarifas:
•
P1 (“horas de vazio”) – 0.1 euros por kWh entre as
22h00 e as 22h30;
•
P2 (“horas de cheia”) – 0.1486 euros por kWh entre
as 22h30 e as 10h30 (do dia seguinte); e
•
P3 (“horas de ponta”) – 0.1865 euros por kWh entre
as 10h30 e as 22h00.
Tendo em conta este tarifário e admitindo cargas de
potência constante durante perı́odos de 1 hora, a expectativa
é que o inı́cio de funcionamento das cargas fique próximo
do inı́cio do perı́odo das “horas vazias”. Assim, por exemplo,
admitindo 3 cargas de 1kW com uma duração de 1 hora, os
tarifários anteriores e uma potência máxima controlável de
2.64 kW (admitindo uma rácio entre potência controlada e
potência contratada de 0.8), espera-se que duas cargas tenham
inı́cio aproximado às 22h00 e que uma das cargas seja obrigada
a deslocar-se para o tarifário P2.
Consideremos outro exemplo, admitindo quatro cargas em
que uma das cargas tem 2.5 kW constantes durante uma hora
e as outras três cargas consomem 1 kW durante uma hora, a
carga de 2.5 kW deverá ocupar o horário da tarifa mais baixa
e as restantes três cargas ficarão na tarifa intermédia, pois é
essa a solução que minimiza o custo.
De seguida apresentamos resultados experimentais considerando um cenário de cargas constantes ao longo do seu
sidências, obtidas utilizando o Analisador de Qualidade de
Energia Fluke 435. Entre os registos disponı́veis, não foram considerados controláveis cargas como arcas frigorı́ficas,
iluminação ou aparelhos AVAC. Os quatro equipamentos considerados controláveis foram: a máquina de lavar a roupa,
a máquina de secar roupa, o termoacumulador e bomba de
piscina. Os resultados destes ensaios não têm uma análise tão
balizada, em que se perceba de antemão qual é o resultado
final do posicionamento de cada uma das cargas de consumo
porque estas poderão ser “encaixadas” nas tarifas mais baixas
sem ultrapassar os 80% da potência contratada. O algoritmo
deverá garantir que o inı́cio de funcionamento das máquinas
não conduza a que a soma das potências ultrapasse os 80%
da potência contratada. Na Figura 3 apresenta-se a potência
consumida ao longo do tempo por: a) Bomba de Piscina; b)
Máquina de Lavar Roupa; c) Máquina de Secar Roupa; d)
Termoacumulador.
Figura 2. Consumo das cargas de acordo com o escalonamento e tarifários
para 4 equipamentos
perı́odo de funcionamento e posteriormente os ensaios considerarão curvas de carga de equipamentos reais.
A. Resultados para uma máquina 2.5 kW e três máquinas de
1 kW com três tarifários
Nestes testes foram quantificados os custos resultantes do
escalonamento temporal dos diversos equipamentos, comparando a introdução do algoritmo genérico com uma seleção
aleatória da hora de entrada em funcionamento das máquinas.
Consideraram-se quatro equipamentos: um consumindo uma
potência de 2.5 kW durante 1 hora e três consumindo uma
potência de 1 kW durante 1 hora. Para limitar as opções
dos testes, a tarifa mais baixa apenas esteve disponı́vel entre
as 22:00 e as 22:30 (de acordo com o tarifário apresentado
na secção anterior). Os equipamentos foram definidos para
funcionar numa janela temporal de 24h, entre as 7h do primeiro
dia e as 7h do dia seguinte.
As simulações foram repetidas vinte vezes, tendo-se posteriormente calculado a média e desvio padrão de custos para
ambas as situações (escalonamento aleatório e escalonamento
com o AG). A média de custos diária para a entrada em funcionamento aleatória dos equipamentos foi de 0.9177 Euros, com
um desvio padrão de 0.0691 Euros. Já no caso da introdução do
AG alcançou-se um custo médio de 0.7561 Euros com desvio
padrão igual a 0.0026. Estes resultados traduzem uma redução
média de custos de 17.6%.
A Figura 2 apresenta um dos resultados do algoritmo
genético. Como se pode constatar, a carga que consome maior
potência ficou escalonada para iniciar o funcionamento às
22:00 e as outras cargas ficaram escalonadas para funcionar no
perı́odo do tarifário com custo intermédio (P2), o que traduz
o custo mais baixo possı́vel.
B. Resultados para quatro equipamentos (reais) com três
tarifas
Nos testes seguintes foram consideradas curvas de potência
consumida de diversos equipamentos existentes em re-
Também neste caso o simulador foi executado vinte vezes.
Das simulações obteve-se uma média de 0,5028 Euros (desvio
padrão igual 0.0309 Euros) para a entrada em funcionamento
dos equipamentos num instante aleatório. Já no caso da
introdução do AG alcançou-se um custo médio de 0.4232
Euros com desvio padrão igual a 0.003. Estes resultados
traduzem uma redução média de custos de 16%, confirmando
os resultados obtidos previamente.
VI.
C ONCLUS ÕES E T RABALHO FUTURO
Neste artigo foi apresentado um método para efetuar o
escalonamento de cargas ao longo de um dia com o objetivo de minimizar os custos associados aos consumos. Essa
minimização tem em conta os tarifários conhecidos à priori.
O processo foi simulado na plataforma multi-agentes SPADE,
tendo sido apresentado os valores obtidos para dois cenários.
Conclui-se que no cenário de teste o AG obteve uma melhoria
de cerca de 17%, enquanto que no cenário com leituras de
máquinas reais essa melhoria foi de cerca de 16%.
Como trabalho futuro, pretende-se considerar a produção
de energia através de fontes renováveis, otimizando de acordo
com as estimativas de produção ao longo do dia, aplicar cargas
não controláveis, estudar processos de otimização distribuı́dos
incluindo processos de negociação entre agentes.
AGRADECIMENTOS
Este trabalho foi parcialmente suportado pelo projeto Manage the Intelligence QREN I&DT, n.o 30260.
R EFER ÊNCIAS
[1]
“Propuesta de real decreto por el que se establece la regulación de las condiciones administrativas, técnicas y economicas de las modalidades de suministro de energı́a eléctrica
con autoconsumo y de producción com autoconsumo,” Online:
http://www.suelosolar.es/newsolares/newsol.asp?id=8479, Julho 2013.
[2] M. A. Piette, G. Ghatikar, S. Kiliccote, E. Koch, D. Hennage, P. Palensky, and C. McParland, Open automated demand response communications specification (Version 1.0), California Energy Commission,
PIER. CEC-500-2009-063, 2009.
[3] P. L. Joskow and C. D. Wolfram, “Dynamic pricing of electricity,” The
American Economic Review, vol. 102, no. 3, pp. 381–385, 2012.
17
Figura 3. Potência consumida ao longo do tempo pelos equipamentos: a) Bomba de Piscina; b) Máquina de Lavar Roupa; c) Máquina de Secar Roupa; d)
Termoacumulador
[4] Utility-Scale Smart Meter Deployments, Plans & Proposals, Institute
for Electric Efficiency, Setembro 2011.
[5] J.-P. Vasseur and A. Dunkels, Interconnecting smart objects with ip:
The next internet. Morgan Kaufmann, 2010.
[6] Smart Energy Profile 2, Application Protocol Standard, Zigbee public
document 13-0200-00 ed., ZigBee Alliance, abril 2013.
[7] IEEE Standard for Ubiquitous Green Community Control Network
Protocol, IEEE Std 1888 Std., abril 2011. [Online]. Available:
http://standards.ieee.org/findstds/standard/1888-2011.html
[8] OpenADR 2.0. Profile Specification. A Profile, OpenADR Alliance,
2012.
[9] Z. Shelby, K. Hartke, and C. Bormann, Constrained Application Protocol (CoAP), Draft: draft-ietf-core-coap-18, Internet Engineering Task
Force (IETF) Std., junho 2013.
[10] A. E. Eiben and J. E. Smith, Introduction to evolutionary computing.
Springer Berlin, 2010, vol. 2.
[11] M. Dorigo and T. Stützle, Ant Colony Optimization. MIT Press, 2004.
[12] R. Poli, J. Kennedy, and T. Blackwell, “Particle swarm optimization,”
Swarm intelligence, vol. 1, no. 1, pp. 33–57, 2007.
[13] Y. Shoham and K. Leyton-Brown, Multiagent systems: Algorithmic,
game-theoretic, and logical foundations. Cambridge University Press,
2009.
[14] E. Argente, J. Palanca, G. Aranda, V. Julian, V. Botti, A. GarciaFornes, and A. Espinosa, “Supporting agent organizations,” in MultiAgent Systems and Applications V. Springer, 2007, pp. 236–245.
[15] M. E. Gregori, J. P. Cámara, and G. A. Bada, “A jabber-based multiagent system platform,” in Proceedings of the fifth international joint
conference on Autonomous agents and multiagent systems. ACM,
2006, pp. 1282–1284.
[16] “Fipa specifications,” online: http://www.fipa.org/, 2013.
[17] “Pyevolve,” online: http://pyevolve.sourceforge.net/, 2013.
18
SDN Framework for Connectivity Services
Rafael Gouveia#, JoãoAparício#, João Soares*#, Bruno Parreira*, Susana Sargento#, Jorge Carapinha*
#
Instituto de Telecomunicações, Universidade de Aveiro
*
PT Inovação
Campus Universitário de Santiago,3810-134 Aveiro, Portugal
Abstract—Considering the advantages of the SDN to the
management of the operators’ network, it becomes
important to have autonomous and automatic frameworks
available. In this paper we propose and evaluate the
performance of a SDN framework oriented for
connectivity services upon a real Openflow network. This
evaluation encompasses the analyses of the framework for
three different scenarios: service activation, link loss and
reaction to a new link.
Keywords— Openflow; dynamic networking; SDN; cloud
computing; connectivity services; network testbed.
I. INTRODUCTION AND MOTIVATION
The explosion of connected devices and applications in the
last years triggered a series of problems and limitations in the
development and management of new services in the network.
On the end-user side, due to the fact that large part of these
devices is mobile and there are well inherent challenges to
keep these devices permanently connected. On the other side,
due to the dynamicity that new paradigms such as cloud
computing are bringing to the network. In the latter case there
is the clear need of a more scalable and flexible network
architecture, starting within data centre domains [1][2]. Cloud
environments have continuous allocation and re-optimization
processes of virtual resources in the network, which requires
constant configurations in the network. However, the impact
is not limited to data centre networks as the transport network
also plays a fundamental role, from connecting data centres, to
the actual delivery of these services to the end-user. Thereby,
the complexity of network management increases
exponentially both inside and outside data centres, i.e. on the
operator network.
Taking into account the abovementioned factors, it is not
feasible to have a static network (as today) that does not have
dynamic capacity. The network architecture needs to evolve to
be able to provide current and next generation networking
services, both from a performance and implementation point
of view. In other words, it needs to be more service oriented.
Software-Defined Networking (SDN) is an emergent
paradigm that proposes a change in current network
architecture, based on the separation of the data plane and
control plane. From a logical point of view, this separation
allows the placement of the network intelligence into a higher
layer, reducing the current complexity of network elements
(forwarding elements, switches and routers) and making the
network more programmable. Therefore, network elements
just need to ensure connectivity services as the intelligence is
now at an upper layer [3][4]. The operation method is based
on the exchange of messages between the control plane and
network elements (data plane), instead of statically
programming those elements. This allows the network to
become more dynamic and for resources to be more
efficiently used, leading to a better management of Quality of
Service (QoS) [3]. The most widely accepted protocol to
perform the communication between the two layers is
Openflow.
SDN, with Openflow, offers other advantages to the
operator, among which: the ability, from a control perspective,
to be agnostic to the hardware, which reduces vendor lock-in;
the displacement of network intelligence allows for a higher
layer of abstraction from a lower layer, i.e., an abstraction
layer to the individual elements in the network. Having a
logically centralized management entity also enables faster
deployments of new services.
Although the application of SDN has been mostly linked
to data center networks, there are network operators already
experimenting it beyond data centers, such as NTT [5]. Apart
from the known advantages of SDN, currently there is no
framework that contains the complete SDN architecture.
Ideally, with a complete framework, the network should be
seen from a service perspective, leaving the work of
provisioning and managing the network connectivity to the
framework itself. The latter should have monitoring and
management mechanisms that guarantee the normal operation
of the network and non-optimal data paths.
In this paper we present a service-oriented SDN
framework that enables the automatic provisioning of
connectivity services over an Openflow network. Moreover,
we undertake the management and maintenance of the same,
by presenting a set of self-management mechanisms to ensure
the optimal functioning of the network. This framework
allowed to study the potential of SDN as a solution for the
future Internet. A thorough evaluation of the framework is
performed, presenting encouraging results towards a possible
future deployment.
The remainder of this paper is organized as follows.
Section II briefly presents related work, and Section III
presents the architecture of the SDN framework with a
thorough description of its internal modules. Section IV
presents the implementation aspects of those modules, while
Section V describes the developed testbed, the exploited
scenarios and the experimental results. Finally, Section VI
presents conclusions and points out future work.
19
II. BACKGROUND AND RELATED WORK
SDN has been widely explored both on the industrial side
as well as on the academic side.
On the industrial side the Open Networking Foundation
(ONF) [6] is a well-known initiative currently focused on the
analysis of SDN requirements and the evolvement of the
OpenFlow standard. Another strong initiative is the
OpenDayLight project [7], which intends to create a common
and open SDN platform enabling network control and
programmability. Its ultimate goal is to provide a complete
SDN framework based on OpenFlow. Although far from
being completed, this initiative is most probably the one
closest to the focus of our work.
In the academia there are several works that tackle SDN
and Openflow related topics. P. Sharma [8] proposes a
network management and control system framework that
allows network operators to run their networks in a hybrid
mode, i.e. composed by the legacy network protocols and a
controller with Openflow. With this they automate and
simplify network management while increasing the dynamic
control of individual flows, regarding QoS requirements.
Although an improvement, this architecture is still hindered
by legacy management tools and protocols, limiting the
potential of a complete SDN management solution.
Furthermore, H. Egilmez [9] proposes a different approach of
QoS architectures for rerouting capability, using non-shortest
paths for lossless and lossy QoS flows. In a latter work [10],
the author proposes a framework for dynamic rerouting of
QoS flows to stream scalable coded videos, consisting of a
base and one or more enhancement layers. This work aims to
resolve the optimization problem of the flows, concerning the
QoS requirements, in an Openflow network, but does not
focus on their initial configuration and activations of the flows
in the Openflow network.
On the other hand, B. Sonkoly [11] proposes an integrated
Openflow virtualization framework capable of running with
different Openflow versions simultaneously, running and
configuring full controllers that manage virtual networks, and
configuring QoS in the network. This tackles the virtualization
problem associated with the Openflow network, also focusing
on the QoS requirements of the flows. Yang Yu [12] proposes
a framework that uses the OpenFlow to handle the transient
link failure. This still uses the legacy routing protocols,
shifting for the Openflow to tackle the problem until the
system is recovered.
Ofelia is a European project which aims at creating an
unique experimental infrastructure that allows researchers to,
not only experiment on a test network, but also control and
extend it dynamically and accurately. It consists of
autonomous OpenFlow enabled islands where each will serve
as a nucleus for an OpenFlow enabled campus network at
their local organization and site [16].
In order to support and enable more efficiently ICN [17]
management, it arises coCONET [18], tested in Ofelia,
consisting of a platform that integrates a set of features that
enable it to respond to the content-centric request/reply
20
paradigm for data distribution, effected route-by-name
operations and allocated in cache of network.
Moreover, [13] proposes a data plane abstraction for
application service providers focused on expressing and
enforcing application traffic management policies and
application delivery constrains. This abstraction is an
extension of OpenFlow and SDN concepts.
Most of the current work focuses on specificities of SDN
(OpenFlow, interfaces, programming platforms), and only a
very small set look into SDN from a full stack perspective.
Although the former are essential, also the latter perspective
needs to be taken into account. In this sense, our work focuses
on a complete framework targeted to services with modular
characteristics.
III. SDN FRAMEWORK ARCHITECTURE
In this section the proposed SDN framework is presented.
This SDN framework allows the creation and management of
network connectivity services over an Openflow based
network. Moreover, it assures the integrity of these services
(fault-management), as well as the optimal usage of the
infrastructure (run-time management).
In the framework, a network connectivity service is
defined by four parameters: communication type, endpoints,
service type and rule type. The first defines the
communication type, for example, Multicast or Full-Mesh
communication. The second defines the type of network
service, for example, TCP, UDP, ICMP and ARP
communication. The third defines a set of endpoints that are
part of the service, which are identified using MAC and/or IP
addresses. Moreover, single ports (i.e. switch interfaces) are
also an option. The last parameter, rule type, defines the type
of rule that is applied in the network, i.e. if apart from the
service type, also IP and/or MAC are taken into account.
The framework’s architecture, presented in Figure 1, is
composed of five modules.
Figure 1 – SDN Framework Architecture
The control grid of the framework is composed by four
modules: Flow Handler, Activator, Monitoring and Controller.
It is responsible for the connection between the data plane,
Figure 2 shows the interaction between the modules in its
various functionalities: system startup; service activation;
event detection; fault detection; and re-optimization process.
Throughout the iteration between modules, there is a
continuous communication between Monitoring and
Controller and also between the Controller and the OpenFlow
network. When the system starts, the Flow Handler module
subscribes to the services provided by the Monitoring.
Simultaneously, the Monitoring collects network information
from the Controller (network element list and capabilities),
which will then be used to build the network topology and
associated information to be transmitted to the Flow Handler.
After this, the platform is available to receive and activate
connectivity services.
On the activation of a service, the user communicates to
the Service Handler which service he wants to activate on the
network. This module validates the request (i.e. verifies if
parameters are consistent with what the platform has to offer)
and stores it in a database. The Flow Handler is in continuous
communication with the database looking for new flows to
activate. When this module finds new flows in the database, it
retrieves its description to later associate them a path that will
be mapped on the network. Finally, it transmits all necessary
information to the Activator module to insert these flows in
the network. The activation flows are updated on the table of
flows of the network elements, via the Controller.
USER
Service Handler
Database
Flow Handler
System Startup
Subscription
Response
Monitoring
Service Activation
Activator
Controller
OF Network
Network Information Request
Response
Openflow protocol
Notification
Response
Save
Request
Get Flows
Description
Response
Response
Flows Activation
Response
Update
Flows
Event
/Fault
Detection Monitoring
Monitoring
Openflow protocol
Service Request
Reoptimization Process
where the forwarding elements are, and the applications plane,
where the fifth module is – Service Handler. Moreover, it is
also responsible for assuring the optimal functioning of the
network. The individual functions of the different modules are
described below.
Service Handler – module with the vision of connectivity
services and flows. This module is responsible for receiving
requests and checking their consistency. Furthermore, it
translates service requests into flows that are then sent to the
Flow Handler. Finally, it makes available state information of
the services to upper layers (e.g. active, failed, provisioning).
The interaction between the Service Handler and the Flow
Handler represents the bridge between the application plane
and the control plane of the SDN standard architecture.
Flow Handler – module with the vision of flows and rules.
In an initial moment, this module subscribes to the services
provided by the Monitoring in order to gather the information
of the network elements (topology) and problems
(alarms/changes in the topology) that are felt there. Then, it is
responsible to decide the links (path) that the flows traverse in
the network. Besides the activation of flows via Activator, this
module also reacts to events detected in the substrate with the
objective of optimizing, in case there is an increment of
network elements, or to maintain the normal functioning of
services and network, in case there is a loss of network
elements.
Activator – module responsible to decode the received
path of a rule type by the Flow Handler, in order to gather the
information of the network elements that will be affected.
Then, it updates the flow tables of those elements, belonging
in the data plane, via Controller. All the information
concerning the rules (flows, path and state) implemented in
the substrate is saved in an internal data structure. At last, it
makes available the information of the rules present in the
network.
Monitoring – module responsible to identify, monitor,
save and provide information regarding the network elements.
This module uses the Controller to gather the information and
saves it in an internal data structure. It provides all the
relevant information concerning the network elements for the
superior modules, in this case for the Flow Handler. It
operates through a subscription service to provide the
information about the topology and problems of the network.
Controller – module responsible for the communications
between the control plane and the data plane. This module
uses the Openflow protocol to configure and to manage the
operations on the flow tables of the network elements.
Openflow protocol
Flows Check-up
Response
Openflow protocol
Notification
Get Flows
Description
Rule Update
Response
Response
Event /Fault
Detection
Response
Flows Reoptimization
Flows Activation
Response
Rule Update
Response
Update Flows
Openflow protocol
Flows Check-up
Response
Figure 2 – Modules’ interaction (System Startup, Service Activation and
Reoptimization Process)
The reoptimization process starts when the Flow Handler,
after receiving an event from the Monitoring module, detects a
change in the network by comparing the new and the previous
topology. In case there are new links, the Flow Handler will
search for possible optimization of active services. For this
purpose, the module executes the flow allocation algorithm
(Dijkstra) for every flow stored in the database in an attempt
of finding shorter paths. In case some links have been
removed, the module will search for possible failures in active
services - Fault Detection functionality previously mentioned.
In this case, all data paths of active flows are analysed and, in
case the failure affects a flow, the flow allocation algorithm is
applied in order to reallocate the flow.
21
IV. IMPLEMENTATION
This Section describes the internal characteristics and
options made in the development of the modules.
The Controller chosen to operate with the Openflow
protocol is the Floodlight with the version 0.9. This controller
is open source, uses the RESTful web API principles, and has
an active mailing list. All those characteristics make the
Floodlight suitable to use in our framework.
The rest of the modules use the version 2.7 of the Python
language. This architecture is designed to be modular,
autonomous, automatic and easily scalable. From a logical
point of view, the modules Service Handler and Flow Handler
are separated, but from an implementation point of view they
are united in the same server. On the other hand, the modules
Activator and Monitoring have independent servers. All
modules use a RESTful web API and HTTP principles to make
the exchange of data from and to the servers, with JSON to
serialize data.
The Service Handler allows two types of services: Fullmesh that creates bidirectional connections between the list of
elements; and Multicast that creates unidirectional
connections between an element labelled as source and the
elements labelled as destiny. The communication between this
module and the Flow Handler is performed through a
database. The Flow Handler is in continuous access with the
database to detect if there are flows uncompleted (flows
without a path associated), or if there are flows completed but
not actives. This module uses the Dijsktra algorithm to
discover the shortest path in the network. Moreover, this last
module will perform management actions concerning the
modifications felted in the substrate network.
The Monitoring is in continuous communication with the
Controller in order to gather all the relevant information of the
network elements. This module produces adjacency matrixes
with the information of the network topology, link bandwidth
and places of problems felt in the network. The modules that
want to receive this information need to perform a previous
registration (subscription), and after that moment the
Monitoring knows the addresses of where to send the
information. Every time that the network topology changes,
this module remakes the adjacency matrixes and sends that
information to the subscribed addresses.
Figure 3 – Network elements scheme
The Open VSwitch is used to emulate the switches in the
nodes. The Open VSwitch is an open source application that
emulates the behaviour of a real switch that supports the
Openflow protocol.
The control grid is configured to allow the access to the
machines where the Open VSwitch are installed, in order to
obtain the results of the simulations. The characteristics of the
nodes are below in the Table I.
B. Scenarios
In the scope of the evaluation, it is analysed three different
scenarios. These scenarios allow the exhibition of the features
developed for the SDN framework.
1) Service Activation – the connectivity service is
received by the framework and its consistency is evaluated.
After that initial step, the framework translates the service in
its correspondent number of individually flows considering
the type of work chosen, and stores them in the database.
Afterwards, a path finding algorithm is executed to complete
the flows. After this point, the flows are considered completed
and ready to be activated. At last, the framework activates all
the flows and updates the state of the service.
2) Loss of a link – the framework detects that a link
was removed from the network. After this process, the new
adjacency matrix of the network topology is made. Finally, all
the flows activated are analysed, in order to identify and
modify the flows that are directly affected with this loss. This
re-optimization process aims to maintain the services active.
3) Addition of a link – the framework detects that a
link was added in the network. As the previous scenario, the
new adjacency matrix representing the network topology is
made. After that, every flow is optimized according with the
new state of the network. This is a complete re-optimization
process.
V. EVALUATION
This section evaluates the proposed SDN framework. First,
the testbed used for the evaluation is described. Furthermore,
the different scenarios studied are presented. Finally, the
experimental results are obtained and analysed.
A. Testbed
The testbed built to evaluate the performance of the SDN
framework is shown in the Figure 3. The Controller and the
servers are placed in the node C, and that same node connects
the testbed with the Internet.
22
Node CPU
Model
A
Intel
PentiumD
950
B
Intel Core
2
Duo
E6400
C
Intel Core
2
Duo
E6400
D
Intel
PentiumD
950
TABLE I – TESTBED SPECIFICATION
CPU CPU
CPU
HDD
RAM
Freq. Cores Threads Memory Amount
3.40 2
4
40 GB
6 GB
GHz
2.13
GHz
2
2
145 GB
4 GB
2.13
GHz
2
2
145 GB
4 GB
3.40
GHz
2
4
40 GB
6 GB
RAM
Freq,
667
MHz
DDR2
533
MHz
DDR2
533
MHz
DDR2
667
MHz
DDR2
C. Performance Results
This sub-section presents the performance analysis in the 3
previously defined scenarios.
Relatively to the first scenario, Figure 4, it is activated a
connectivity service of the type UDP with the operation mode
Multicast, in which the host source will be always placed at
the node A. The targets will be placed: 1 at node D (service
with 2 elements in which it will be translated into 1 flow); 2 at
node B and 2 at node D (service with 5 elements which will
be translated into 4 flows); and 3 at node A, 4 at node B and
12 at node D (service with 20 elements which will be
translated into 19 flows).
Additionally to the individual analyses of the modules
Service Handler and Flow Handler, the activation time
presents also a linear behaviour. It takes approximately 140
ms to activate each flow. The service that is translated in one
flow takes approximately 460 ms to be received, treated and
activated. In the case that the service results in four flows, it
takes approximately 1260 ms from the first moment until it is
completely active. For the last service, which is translated into
19 flows, it takes approximately 5800 ms to be activated.
These times will be affected by the size of the substrate
network. This is related with the policy used for finding the
path for the flows (Dijkstra that gives the shortest path).
The results of the second and third scenarios are
presented in Figure 5. For both cases, the initial step is the
perception that there was a change in the substrate network by
the Monitoring. The other step is the re-optimization process.
It is noticed a large time difference between the reaction for
the loss of a link, approximately 100 ms, and the reaction to
the addition of a link, approximately 3000 ms. For the first
case, the re-optimization time will be directly proportional to
the flows affected, because it is needed to find another path to
allocate them and activate again. For the second case, it is
performed a path finding attempt for every flow. In our
experiments, the time for both cases is almost the same,
because the number of flows that get affected with the loss of
a link is the same than the one that afterwards get a shorter
path with the addition of that same link. In addition, we
noticed in our experiments that the search for the flows
affected when there is a loss of a link consume more time than
a path finding try for the entire flows present in the database.
However, when the number of nodes in the network is larger,
it is expected that the re-optimization process due to the
addition of elements will have longer time consumption than
the cases when there is a loss of elements, because of the
complexity of the Dijkstra algorithm.
Figure 4 – Service activation
The difference of performance for both cases is in the
identification that the substrate network has changed, that is
quicker for the loss of a link than for the addition of a link. In
the addition of a link, the switch interface needs to perform an
internal reconfiguration, informing the internal Open VSwitch,
and only after that, the controller is notified. On the contrary,
the loss of a link does not need reconfiguration and the
controller is notified right away.
Figure 5 – Loss of a link and addition of a link
VI. CONCLUSION
The goal of this paper is to overcome the lack of a full
stack of layers in a single framework, from the data plane to
the application plane, which offers connectivity services to the
users in a simple, autonomous and automatic form.
This paper proposed a complete SDN framework that
enables the configuration and management of connectivity
services upon a real Openflow network. Two different
operation forms are made available to perform the
configuration of those services. The management of those
services encompasses a re-optimization process when there is
23
addition of network elements, or a maintenance process of the
services when there is a loss of network elements.
The performance of the SDN framework is evaluated in a
real environment, which gives insight on the times that it takes
to perform the configuration and management of connections
upon a real Openflow network. It takes approximately 245 ms
and 290 ms, per flow, to receive, manage and activate services
for the Full-mesh and Multicast operation forms
correspondently.
As future work, we plan to incorporate this SDN
framework with cloud computing mapping algorithms, being
this framework responsible to perform the enforcement of the
mapping decisions, related with the links, in the operator
network.
[18]
International Conference on emerging Networking EXperiments and
Technologies (CoNEXT), 2009
Veltri, L., Morabito, G., Salsano, S., Blefari-Melazzi, N., & Detti,
A:“Supporting information-centric functionality in software defined
networks”. In Communications (ICC), 2012 IEEE International
Conference on (pp. 6645-6650). IEEE. June,2012.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
24
Open Networking Foundation: “Enabled Hybrid Cloud Services
Connect Enterprise and Service Provider Data Centers”, white paper,
November, 2012.
Open Networking Foundation: “Software-Defined Networking: The
New Norm for Networks”, white paper, April, 2012.
M. Mendonca, B. Nunes, X.Nguyen, K. Obraczka and T.Turletti: “A
Survey of Software-Defined Networking: Past, Present and Future of
Programmable Networks”, May, 2013.
W. Stallings: “Software-Defined Networks and Openflow”, in The
Internet Protocol Journal, Cisco, Volume 16, Issue 1, pp. 2-14, March,
2013.
H. Nagasono: “NTT DATA’s Efforts for Openflow/SDN”, in NTT
Technical Review, Volume 10, Number 11, November, 2012.
Open Networking Foundation: “Openflow Switch Specification”,
August, 2013.
OpenDaylight: “An Open Source Community and Meritocracy for
Software-Defined Networking”, April, 2013.
P. Sharma, S. Banerjee, S. Tandel, R. Aguiar, R. Amorim and D.
Pinheiro: “Enhancing Network Management Frameworks with SDNlike Control”, Integrated Network Management (IM 2013), 2013
IFIP/IEEE International Symposium on , pp.688,691, 27-31 May, 2013.
H. Egilmez, B. Gorkemli, A. Tekalp and S. Civanlar: "Scalable video
streaming over OpenFlow networks: An optimization framework for
QoS routing", Image Processing (ICIP), 2011 18th IEEE International
Conference on, pp.2241-2244, 11-14 September, 2011.
H. Egilmez, S. Civanlar and A. Tekalp: "An Optimization Framework
for QoS-Enabled Adaptive Video Streaming Over OpenFlow
Networks", Multimedia, IEEE Transactions on, vol.15, no.3, pp.710715, April, 2013.
B. Sonkoly, A. Gulyas, F. Nemeth, J. Czentye, K. Kurucz, B. Novak
and G. Vaszkun: "OpenFlow Virtualization Framework with Advanced
Capabilities", Software Defined Networking (EWSDN), 2012 European
Workshop, pp.18-23, 25-26 October, 2012.
Y. Yu, C. Shanzhi, L. Xin and W. Yan: "A framework of using
OpenFlow to handle transient link failure", Transportation,
Mechanical, and Electrical Engineering (TMEE), 2011 International
Conference on , pp.2050-2053, 16-18 December, 2011.
S. Paul and R. Jain: "OpenADN: Mobile apps on global clouds using
OpenFlow and Software Defined Networking", Globecom Workshops
(GC Wkshps), 2012 IEEE , pp.719-723, 3-7 December, 2012.
J. Aparício, “Integração da Cloud com a rede do Operador ”, Master
Thesys, Department Electronic Telecommunication and Informatics,
University of Aveiro, Aveiro, Portugal, 2013.
R. Gouveia, “Demonstrador de uma rede Openflow”, Master Thesys,
Department Electronic Telecommunication and Informatics, University
of Aveiro, Aveiro, Portugal, 2013.
A. Köpsel and H. Woesner: “Test Facility for OpenFlow
Experimentation”, In EICT GmbH, Berlin. November, 2011
V. Jacobson, D. K. Smetters, J. D. Thornton, M.F. Plass, N.H. Briggs,
and R. L. Braynard, “Networking Named Content”, Fifth ACM
Framework e Cliente WebRTC
Vasco Amaral† ∗ , Solange Rito Lima∗ Telma Mota† Paulo Chainho† † Portugal Telecom Inovação, SA, 3810-106
Aveiro, Portugal
∗ Centro Algoritmi, Departamento de Informática, Universidade do Minho
Campus de Gualtar, 4710-057 Braga, Portugal
Resumo—WebRTC é uma tecnologia normalizada, que permite
a comunicação em tempo real entre browsers, sem a necessidade de instalar plugins adicionais. Desta forma é possı́vel
a qualquer dispositivo (computadores, smartphones, etc.) que
tenha instalado um browser, realizar comunicações em tempo
real peer-to-peer, de uma forma nativa. Exemplo disso são as
comunicações de voz, vı́deo e também a possibilidade de falar
por chat, partilhar ficheiros e partilhar ecrã. É uma tecnologia
relativamente recente mas tem vindo a crescer exponencialmente,
tanto a nı́vel de soluções implementadas, como também a nı́vel de
compatibilidade de web browsers. Desta forma WebRTC torna-se
uma tecnologia em forte crescimento e evolutiva, onde poderão
surgir cada vez mais soluções de serviços.
Atendendo a que ainda não está definida uma implementação
normalizada para a comunicação entre endpoints WebRTC, este
artigo apresenta um projeto que consiste numa abordagem à
tecnologia WebRTC, de forma a identificar as potencialidades
desta tecnologia e de que forma podem ter impacto no mundo
das telecomunicações. No decorrer do estudo realizado, e para
o fundamentar, foi desenvolvida uma framework que tem como
objetivo tornar mais fácil a criação e implementação de serviços
WebRTC, que servirá como uma solução de comunicação entre
vários clientes.
Este é o foco deste artigo, em que se apresenta um estudo
realizado à tecnologia WebRTC de forma a determinar a sua
maturidade e a sua evolução. Pretende-se, adicionalmente,
mostrar os principais aspectos envolvidos no desenvolvimento
de uma framework que irá permitir, a utilizadores ou entidades
externas, criar serviços ou aplicações WebRTC de uma forma
simples e a um alto nı́vel. Vários serviços alvo são testados
como prova de conceito no âmbito do desenvolvimento da
framework.
O artigo está organizado da seguinte forma: na Secção II são
apresentados os conceitos associados à tecnologia WebRTC,
nomeadamente a arquitetura e as Application Programming
Interface (APIs) que a constituem; na Secção III aborda-se
o trabalho relacionado com WebRTC, como as soluções já
existentes em termos de sinalização e também em termos
de tecnologia; na Secção IV são apresentados os serviços
que se pretendem desenvolver no âmbito da framework e a
solução arquitetural apresentada para os suportar; na Secção V
incluem-se as principais conclusões do trabalho desenvolvido.
II. C ONCEITOS
I. I NTRODUÇ ÃO
Cada vez mais as telecomunicações estão presentes no
nosso dia-a-dia. São criados mais serviços, cada vez mais
baratos, que se tornaram indispensáveis no nosso quotidiano.
Exemplo disso, são as chamadas áudio, as videochamadas, as
mensagens, etc.
Tal como estes serviços, a Web tem evoluı́do de uma forma
bastante significativa, tornando-se um meio indispensável e
onde circula uma grande quantidade de informação diariamente. Começaram a ser criadas as Single-Page Aplications
(SPA) [22] que permitem redesenhar uma parte da interface
de utilizador, sem necessidade de realizar sempre pedidos
ao servidor, fazendo uma divisão mais equilibrada de carga
entre o servidor e o cliente. Com esta evolução começaram a
surgir novas tecnologias que permitem a criação de soluções
inovadoras, como a tecnologia WebRTC. Esta tecnologia vem
dinamizar o mundo das telecomunicações permitindo a criação
de novas soluções de serviços.
WebRTC é uma tecnologia recente que tem estado em constante evolução e traz grandes desafios. No mundo empresarial
os maiores desafios passam pelos serviços que podem ser
desenvolvidos com esta tecnologia. Para isso, é necessário
fazer um estudo à tecnologia e implementar uma solução que
permita facilitar o desenvolvimento de diferentes serviços de
telecomunicações (e.g., presença, lista de contactos, chamadas
áudio e vı́deo, etc).
Nesta secção são apresentados os principais conceitos inerentes à tecnologia WebRTC, tais como a sua arquitetura, as
Application Programming Interface (API) que a constituem e
de que forma funcionam.
A. Arquitetura WebRTC
A arquitetura WebRTC apresenta dois nı́veis distintos: WebRTC C++ API e Web API, consoante ilustrado na Figura
1. A WebRTC C++ API destina-se principalmente aos programadores de Web browsers, permitindo criar Web browsers
que suportem as funcionalidades da WebRTC [3]. Para quem
desenvolve aplicações Web, o uso da Web API é fundamental.
Permite tirar proveito das funcionalidades WebRTC que os Web
browsers suportam, a partir de programação JavaScript [3].
B. WebRTC API
A API de WebRTC está a ser desenvolvida sobre três
conceitos essenciais: PeerConnection, MediaStreams e DataChannel [1].
1) PeerConnection: PeerConnection permite que dois utilizadores comuniquem diretamente, browser-to-browser. Para
estabelecer esta ligação e haver uma sinalização de negociação,
é necessário que haja um canal de sinalização. Este é fornecido
por um script implementado num servidor Web, utilizando
25
C. WebSockets
Figura 1.
O WebSocket Protocol é um protocolo que fornece uma
comunicação bidirecional, baseado em sockets e usa HTTP
como camada de transporte. Desta forma é possı́vel usar
WebSockets com soluções web já existentes, visto que pode
trabalhar sob portas HTTP como 80 e 443, o que facilita a
integração deste protocolo com as soluções já existentes. Para
além disso, este protocolo não está apenas limitado ao HTTP,
o que permite fazer um handshake simples sob uma porta sem
reinventar o protocolo [4], [5]. Na Figura 2 estão representados
dois tipos de ligações: polling (HTTP) e WebSockets. Numa
ligação polling o browser necessita de estar sempre a fazer
pedidos, pois o servidor só responde no caso de receber esses
pedidos. No caso do WebSocket o browser faz apenas um
pedido e o servidor envia toda a informação em vários pacotes
de dados, sem ter que receber qualquer pedido adicional por
parte do browser. Esta ligação entre o servidor e o browser é
designada como uma ligação persistente, pois sempre que um
deles precisar de enviar qualquer informação podem fazê-lo a
qualquer momento.
Arquitetura WebRTC [3].
WebSockets ou XMLHttpRequest. Este mecanismo usa o protocolo Interactive Connectivity Establishment (ICE) juntamente
com Session Traversal Utilities for NAT (STUN) e Traversal
Using Relays arround NAT (TURN) para permitir ajudar as
streams de media a passarem por Network Address Translation
(NAT) e firewalls [1], [25], [2].
2) MediaStreams: MediaStream é uma forma abstrata de
representar uma stream de dados áudio e/ou vı́deo. Este
tipo de aplicações pode ser usada para mostrar, gravar ou
enviar o seu conteúdo para um peer remoto. Existem dois
tipos de stream: Local MediaStream ou Remote MediaStream.
Local MediaStream é a stream capturada no próprio sistema
(webcam e microfone) enquanto que Remote MediaStream é
a stream recebida de outro peer. Para ter acesso à media
dos componentes do terminal é necessário executar a função
getUserMedia(), onde podem ser definidos alguns parâmetros,
dependendo do que o utilizador do terminal queira reproduzir. Para a transmissão das streams são usados protocolos
como Secure Real-time Transport Protocol (SRTP), Realtime Transport Protocol (RTP) e Real-time Transport Control
Protocol (RTCP) para monitorização de transmissão de media.
O Protocolo Datagram Transport Layer Security (DTLS) é
usado como uma chave de SRTP e para gestão de associações
[1], [25], [2].
3) DataChannel: RTCDataChannel é um canal de dados bidirecional em ligações peer-to-peer. É possı́vel serem
transferidos dados que não sejam media e é necessário usar
outro protocolo, como SCTP encapsulado em DTLS. Desta
forma existe uma solução para NAT com confidencialidade,
autenticação da fonte e integridade dos dados que sejam
necessários transferir. O SCTP permite a entrega, fiável e não
fiável, de dados e permite que as aplicações abram várias
streams independentes. Para a criação de um DataChannel
é necessário executar a função CreateDataChannel() numa
instância da PeerConnection [1], [25], [2].
26
Figura 2. Comparação de latência entre polling e aplicações Websockets [6].
D. Sinalização
Ao contrário do que acontece com uma infraestutura completamente pensada para estabelecer uma ligação ou até
mesmo controlar todo o media, o mesmo não acontece quando
se fala da sinalização. Para estabelecer uma chamada entre os
utilizadores, é necessário haver uma negociação de parâmetros
da sessão, descritos via Session Description Protocol (SDP).
A definição do método a utilizar fica a cargo da camada
aplicacional, ou seja, a pessoa que está a desenvolver uma
aplicação pode definir o método que quer para a sinalização.
Apesar disso existem alguns protocolos que definem como
deve ser feita a sinalização. Por exemplo, o JavaScript Session
Establishment Protocol define de que forma as aplicações
JavaScript interagem com as funções Real Time Communication (RTC). Este protocolo é responsável pela forma como os
clientes podem recolher informação sobre o tipo de media que
suportam e que codecs usam, o que fica definido num objeto
SDP RTCSessionDescription. O JSEP fornece mecanismos de
criação de offers e answers, como também de que forma
podem ser aplicadas numa sessão [9]. Este protocolo não
define de que forma essa informação é trocada, ou seja, não
é definido como essa informação é enviada ou recolhida do
servidor web, ficando isso a cargo do programador.
Package Manager (npm) [10]. O npm, para além de servir
para instalar os módulos, permite também tratar da gestão
de versões e gestão de dependências. Um dos módulos que
permite desenvolver aplicações que atuem em tempo real e
que utilizem uma API tipo WebSockets, é o socket.io. Este
permite que WebSockets e tempo real estejam presentes em
qualquer browser, para além disso ainda fornece multiplexing,
escalabilidade horizontal e codificação e descodificação em
JSON [10].
B. Vertx.io
Figura 3.
Modelo JSEP [9].
A figura 3 mostra o modelo utilizado pelo JSEP, onde as
mensagens entre o browser e a aplicação são objetos SDP,
e o protocolo que é usado para transmitir essa informação é
especificado na camada aplicacional.
III. S OLUÇ ÕES W EB RTC
Com a evolução da tecnologia WebRTC nestes últimos anos,
o número de aplicações e/ou soluções WebRTC têm vindo a
aumentar. Existem soluções para realizar conferências entre
duas ou mais pessoas (Conversat.io), partilha de ecrã, partilha
de ficheiros, falar por chat, partilha de conteúdos peer-to-peer,
com o objetivo de não sobrecarregar os servidores (peerCDN),
e ainda usar jogos multiplayer que utilizam RTCDataChannel (BananaBread). Existem ainda soluções SIP HTML5 que
usam a Web API, para que haja uma interoperabilidade entre
sistemas SIP nativos e sistemas WebRTC (sipML5). Estes são
exemplos de aplicações Web funcionais.
WebSockets é uma tecnologia que também se encontra
em desenvolvimento e ainda não é suportável em todos os
browsers. Existem várias aplicações que permitem o desenvolvimento de soluções Websockets num servidor, as duas mais
relevantes para este artigo são: Node.js e Vertx.io.
A. Node.js
É uma plataforma orientada a eventos, do lado do servidor,
que permite a criação de aplicações web escaláveis. Os programas que são desenvolvidos com esta plataforma são escritos
em JavaScript e são assı́ncronos, o que permite diminuir
o overhead e aumentar a escalabilidade [11]. Contém uma
biblioteca de servidor HTTP, que permite correr aplicações
web sem usar um servidor tı́pico HTTP (e.g. Apache). Esta
plataforma permite a criação de aplicações que tenham por
objetivo funcionar completamente em tempo real, como por
exemplo, streaming de voz ou vı́deo, ou então serviços de
chat e partilha de ficheiros [11]. Implementa um repositório
de módulos, onde cada um tem uma funcionalidade diferente.
Cada um destes módulos pode ser instalado a partir de Node
É uma framework da próxima geração, que corre em Java
Virtual Machine (JVM), é orientada a eventos e assı́ncrona. Implementa um modelo de concorrência assı́ncrono que permite
a criação de aplicações facilmente escaláveis, de uma forma
simples. No que diz respeito às linguagens de programação
que podem ser usadas, é uma framework poliglota, suportando
desenvolvimento em: Java, JavaScript, Groovy, Ruby, Python
e Scala.
Para além das caracterı́sticas apresentadas anteriormente,
esta framework aborda alguns conceitos que são importantes
para o desenvolvimento de aplicações [15], [14], nomeadamente:
• Verticle: Um verticle é definido por ter uma função
principal (main), que corre um script especı́fico. Um
verticle pode conter mais verticles, desde que sejam
referenciados na função main.
• EventLoops: São threads que estão sempre a correr e
estão sempre à escuta, de forma a verificar se existem
operações a executar ou dados a tratar. A gestão destas
threads é feita por uma instância do Vert.x, que aloca um
número especı́fico de threads a cada núcleo do servidor.
• Work Verticle: Este tipo de verticle não é atribuı́do a uma
thread event loop do Vert.x, em vez disso, é executado
a partir de uma thread que se encontra numa pool de
threads internas, à qual se chama background pool.
• EventBus: Esta é uma caracterı́stica do Vert.x bastante importante que permite a comunicação entre vários verticles
ou módulos do Vert.x. Para além disso, é possı́vel haver
uma comunicação não só entre verticles mas entre entidades que registem handlers num servidor (ex. clientes).
Desta forma é possı́vel a partilha de informação entre
as várias entidades que constituam um sistema, chamada
de Message Passing. Pode-se verificar na figura 4 uma
arquitetura especı́fica do Vert.x.
• Modules: É possı́vel a criação de módulos individuais,
que executem diferentes funções. Isto permite uma melhor organização de código e uma maior escalabilidade
de aplicações. A comunicação entre os módulos é feita a
partir de um eventbus. Existe ainda um repositório onde
existem módulos previamente criados, que podem ser
usados para facilitar a construção de aplicações.
No que diz respeito a frameworks, bibliotecas ou
repositórios não se verificam muitos desenvolvimentos. Foram
desenvolvidas algumas soluções que permitem criar soluções
WebRTC de uma forma mais simples e mais dinâmica, a
um mais alto nı́vel. No que diz respeito a bibliotecas e
27
deteção de presença (orientado a eventos onde é verificado quando um utlizador entra ou sai, sem vários estados
de presença).
Esta biblioteca usa firebase por defeito, que é uma tecnologia com uma base de dados na cloud e que permite
desenvolver aplicações em tempo real. Tem uma estrutura
de dados partilhada e sincronizada, desta forma sempre que
os dados são mudados ou atualizados é possı́vel atualizar
essa informação em todos os clientes que estão ligados [18].
Para além disso, é possı́vel implementar uma solução que use
socket.io ou WebSockets.
2) DataChannel.js: É uma biblioteca JavaScript que foi
desenhada para ajudar a desenvolver aplicações para partilha
de dados. Estes dados podem ser ficheiros ou simples mensagens de texto. Tal como a RTCMultiConnection.js simplifica
o desenvolvimento de aplicações. Esta biblioteca implementa
as seguintes funcionalidades [19]:
• mensagens de texto directas entre utilizadores;
• banir ou rejeitar qualquer utilizador;
• sair de uma sessão ou encerrar uma sessão completa;
• tamanho de ficheiros ilimitado;
• quantidade de dados ilimitada;
• detecção de presença (orientado a eventos onde é verificado quando um utlizador entra ou sai, sem vários estados
de presença).
Como indicado na biblioteca RTCMultiConnection.js, usa
por defeito e como backend o firebase, mas também pode
usar socket.io ou Websockets para sinalização.
3) RecordRTC.js: Esta biblioteca foi desenvolvida para
permitir aos utilizadores guardarem áudio, vı́deo ou até mesmo
imagens animadas. A stream de áudio é gravada no formato
.wav, a stream de vı́deo é guardada em formato WebM e
as imagens animadas em .GIF. Estes formatos podem ser
gravados no disco de forma a ser possı́vel retornar o URL desse
ficheiro, para aceder posteriormente a essa informação. Fica
a cargo de quem está a desenvolver a aplicação dizer se quer
como retorno o URL, DataURL ou o objeto Blob [17]. Esta
biblioteca pode ser útil para gravar chamadas entre clientes, ou
até mesmo gravar uma mensagem de videomail ou voicemail.
4) RTCCall.js: Esta biblioteca foi desenvolvida para ter
apenas uma funcionalidade. Esta funcionalidade passa por
um administrador de um sistema poder falar com os seus
clientes/visitantes. Como exemplo, um administrador de um
sitio online, onde são oferecidos serviços, poderá ter um
botão em que os seus clientes clicam e telefonam para si.
Desta forma é possı́vel tirar dúvidas sobre produtos ou até
mesmo reportar problemas encontrados. Assim há uma maior
interatividade entre administradores e clientes [20].
•
Figura 4.
Funcionamento geral da aplicação Vert.x [13].
Tabela I
P ERFIXOS DAS INTERFACES NOS DIFERENTES browsers [12].
W3C Standard
getUserMedia
RTCPeerConnection
RTCSessionDescription
RTCIceCandidate
Google Chrome
Não Suporta
Não Suporta
Não Suporta
Não Suporta
Mozilla
Suporta
Suporta
Suporta
Suporta
Firefox
>v17
>v22
>v22
>v22
repositórios destacam-se: Adapter.js, WebRTC-Experiment e
SimpleWebRTC, que a seguir se descrevem.
C. Adapter.js
As chamadas ao sistema de cada Web browser são feitas
de forma diferente, ou seja, é necessário executar funções
diferentes na mesma aplicação caso se queira que a aplicação
funcione em dois ou mais browsers diferentes.
A Tabela I representa que tipo de funções são usadas para
desenvolver uma solução WebRTC em diferentes browsers. A
biblioteca Adapter.js vem unificar estas funções, isto é, ao
carregar esta biblioteca para uma aplicação é possı́vel usar
funções W3C Standard que podem ser usadas tanto no Chrome
como no Firefox.
D. WebRTC Experiment
É um repositório de bibliotecas JavaScript que implementa
demos WebRTC e que tem por objetivo ajudar no desenvolvimento de aplicações deste tipo. Existem quatro bibliotecas diferentes neste repositório: RTCMultiConnection.js,
DataChannels.js, RecordRTC.js e RTCall.js [16].
1) RCMultiConnection.js: Com esta biblioteca é possı́vel
desenvolver alguns serviços avançados de uma forma mais
simples, como [18]:
• conferências Áudio/Vı́deo;
• partilha de dados ou de ficheiros;
• partilha de ecrã;
• renegociação de streams múltiplas e remoção de streams
individuais;
• fazer mute ou unmute às várias streams (áudio e vı́deo);
• banir utilizadores;
28
E. SimpleWebRTC
É uma biblioteca Javascript que permite desenvolver
aplicações de comunicações em tempo real em ambientes Web
(WebRTC). É possı́vel configurar variáveis, para simplificar a
implementação das soluções que se pretendem desenvolver,
como saber quais os objetos HTML5 aos quais se devem
alocar as streams, se o pedido para permissão de uso de
câmara e microfone deve ser feito automaticamente ou não.
Para além disso, é uma biblioteca orientada a eventos, que
permite saber se o utilizador está pronto e se está à espera que
alguém se junte à sessão [21]. É necessário usar um servidor
socket.io, que servirá como servidor de sinalização, que está
implementado num servidor Web fornecido pelos criadores
deste repositório [21].
Como a tecnologia Vert.x permite uma separação por
módulos, foi decidido desenvolver uma arquitetura modular
em que cada módulo tem funções diferentes, separando assim
o funcionamento dos serviços por módulos. A figura 5, ilustra
de que forma foi definida a arquitetura para a framework e de
que forma o cliente poderá interagir com o servidor.
IV. F RAMEWORK DESENVOLVIDA
Esta secção apresenta a solução proposta para o desenvolvimento de uma framework que tem por objetivo permitir, a
utilizadores ou entidades externas, criar serviços ou aplicações
WebRTC de uma forma simples e a um alto nı́vel.
Foram definidas algumas especificações inicialmente para
o desenvolvimento desta solução. Houve uma análise inicial
às tecnologias e bibliotecas existentes. Analisaram-se os potenciais de cada uma delas, desde o seu desempenho em
várias situações e quais é que forneciam mais vantagens neste
projeto.
A. Tecnologias
Foram analisadas várias tecnologias no que diz respeito a
WebSockets. Depois da pesquisa de alguns estudos relativos
ao Vertx.io e Node.js, foram analisados dois estudos realizados externamente [23], [24]. No primeiro estudo [23], são
realizados dois testes distintos. O primeiro teste consistia em
medir o desempenho da tecnologia Vert.x e da Node.js, em
que o servidor respondia com uma mensagem simples (200OK), a cada pedido realizado a esse servidor. Vert.x conseguiu
responder a mais de 300000 pedidos (servidor programado
em Java), enquanto Node.js ultrapassou um pouco os 100000
pedidos. Num segundo teste o servidor fornecia um ficheiro
estático de 72 bytes a cada pedido. Verificou-se que o Vert.x
atingiu mais de 100000 pedidos por segundo enquanto o
Node.js não ultrapassou os 30000 pedidos. No segundo estudo
analisado [24], foi realizado apenas um teste com um servidor
pub/sub que os clientes subscrevem e a partir desse momento
recebem atualizações sobre o stock e notificações de pedidos
realizados. Neste teste a tecnologia Vert.x foi escalável até
às 25000 ligações, fazendo com que o servidor ficasse sem
memória. No que diz respeito ao Node.js, foi escalável até as
24000 ligações, tornando-se lento a partir desse momento.
Concluiu-se que a tecnologia Vertx.io era mais rápida, mais
escalável e apresentava melhor desempenho. Juntando estas
conclusões às suas caracterı́sticas e ao facto de ser poliglota,
decidiu-se usar esta tecnologia para o desenvolvimento da
parte do servidor.
B. Arquitetura
Para definir uma arquitetura para esta framework, foi
necessário definir alguns dos serviços que se pretendem ver
desenvolvidos:
• chamada / Conferência áudio e vı́deo;
• presença e Lista de contactos;
• chat / Mensagens instantâneas;
• partilha de ficheiros;
• gravação voz e vı́deo.
Figura 5.
Arquitetura da framework.
Como ilustrado, existe o lado do cliente e do servidor.
Os módulos existentes estão registados na parte do servidor.
Assim, o cliente, a partir do EventBus, poderá comunicar
diretamente com cada um dos módulos para executar as
funções necessárias.
1) Módulo Servidor Web: O módulo Web Server consegue
criar um servidor Web onde são facilmente fornecidos ficheiros
que se encontrem nesse servidor. Tem uma configuração
bastante completa, onde são indicados os campos mais importantes. Desta forma é possı́vel ter um servidor Web completo,
que responda aos pedidos de cada cliente, a partir de um
endereço especı́fico. Cada pedido de um cliente, ou até mesmo
de um módulo no servidor, deve ser direcionado para esse
endereço, para que o servidor Web possa retornar uma resposta.
2) Módulo Base de Dados Mongo: No que diz respeito
à base de dados optou-se por utilizar uma base de dados
não relacional, Mongo DB. Tal deve-se ao facto de existir
um módulo desenvolvido pela comunidade Vert.x, que permite
uma gestão dinâmica e simples da base de dados. Este módulo
permite operações como:
• save: salva documentos nas collections existentes;
• update: atualiza informação de um documento e de uma
collection;
• find: encontra um ou mais documentos nas collections
associadas;
• find one: encontra apenas um documento na collection
associada;
• count: conta o número de documentos numa collection;
• delete: apaga todos os documentos associados.
Todas estas operações são executadas apenas pelos módulos
do servidor, isto é, toda a atividade executada pelos clientes é
enviada primeiro para os módulos como: Módulo de Presença,
Notificação, Histórico de Chamadas, etc. Estes módulos são
29
responsáveis por atualizar toda a informação da base de dados,
que lhe esteja relacionada.
3) Módulo de Presença: O módulo de presença permite a
implementação do serviço de presença e de lista de contactos.
É o módulo que está responsável por adicionar e remover
pessoas da lista de contactos, atualizar o estado de presença de
cada pessoa (Online, Offline, Ausente, Ocupado). Cada cliente,
para além do seu perfil de utilizador, onde se encontram
informações como: nome de utilizador, e-mail, password e
histórico de chamadas, tem ainda o que se chama grupo de
perfil de utilizador. Este grupo permite ao utilizador guardar
todos os dados relacionados com os pedidos de subscrição
por parte de outros utilizadores. Estes pedidos são guardados
numa lista que se chama presence authorization pendent,
onde estão todos os pedidos de subscrição que ainda não
foram tratados. Os pedidos rejeitados são guardados numa
lista denied presence e os que são aceites na lista authorised presence. É nesta última lista que estão guardados
todos os contactos de um cliente. A partir do momento que
um cliente executa a autenticação no sistema, será enviada
uma mensagem tipo ”find” para o módulo de presença que
ficará encarregue de procurar e carregar todos os contactos
desse cliente, como também o estado de presença de cada
um (Online, Offline, Ausente, Ocupado). Para além disso, é
enviada outra mensagem para o mesmo módulo, de forma a
que se possa atualizar a informação da sessão desse utilizador.
Cada utilizador tem um endereço registado para cada pessoa
da sua lista de contactos, isto é, cada cliente tem registado um
endereço especı́fico (presence.<nome do contacto >), por
cada contacto que tenha na sua lista. Sempre que um cliente
atualize o seu estado, irá enviar uma mensagem ”publish” de
forma a que todos os seus subscribers possam receber essa
mensagem, como ilustrado na Figura 6.
momento que é aceite esse pedido, o módulo encarregar-se-à
de atualizar a informação referente a esses dois utilizadores,
colocando ambos na lista authorised presence de cada um e
irá notificar a pessoa que enviou o pedido. No caso do pedido
ser rejeitado, ambos serão colocados na lista denied presence
de cada um, notificando o cliente que realizou o pedido de
que foi rejeitado.
4) Módulo de Notificação: O módulo de notificações
trata as mensagens de notificação referentes às chamadas.
Sempre que um utilizador é convidado para uma sessão de
chamada/conferência é enviada uma notificação para esse
utilizador, de que um cliente o quer contactar. Assim, este
cliente pode escolher se quer rejeitar ou não a sessão. Existem
notificações que estão associadas a outros módulos, logo não
passam por este. Exemplo disso são as notificações do módulo
de presença, sempre que é adicionado um novo cliente à lista
de contactos, a notificação é tratada no módulo de presença.
O mesmo acontece quando um cliente muda o seu estado de
presença.
5) Módulo de Histórico de Chamadas: O módulo histórico
de chamadas guarda informação referente às conferências ou
chamadas efetuadas dos utilizadores. Sempre que é iniciada
uma sessão de chamada/conferência é guardada a hora inicial
da chamada, juntamente com a data e quem iniciou a chamada.
Conforme forem entrando pessoas nessa sessão a informação
vai sendo atualizada, existindo a possibilidade de saber todas
as pessoas que participaram nessa sessão. Quando a sessão
termina é enviada uma mensagem do tipo ”registcall”, para
este módulo para que a informação relativa a essa sessão possa
ser guardada na base de dados. Desta forma a informação
está sempre atualizada e sempre que um utilizador fizer
autenticação no sistema, poderá visualizar o histórico das
chamadas realizadas e recebidas. As informações guardadas
na base de dados referente a cada chamada realizada são:
•
•
•
•
•
Figura 6.
Notificação de mudança de estado.
Desta forma é possı́vel manter a informação sobre o estado de presença dos contactos atualizada. Para adicionar
uma pessoa à lista de contactos é enviada uma mensagem
do tipo ”subscribe” para este módulo, o cliente adicionado
será notificado de que alguém o quer adicionar. A partir do
30
initiator - pessoa que iniciou a chamada/conferência;
hour - hora de inicio da chamada/conferência;
date - data da chamada/conferência;
duration - duração da chamada/conferência;
participants - pessoas que participaram na
chamada/conferência.
6) Módulo Gestor de Chamadas: O módulo gestor de
chamadas permite ter um maior controlo no que diz respeito às chamadas/conferências. O cliente poderá escolher
que tipo de sessão quer iniciar, isto é, se quer realizar uma
chamada áudio e vı́deo, ou se apenas quer falar por mensagens
com um determinado utilizador. É possı́vel escolher vários
serviços para uma sessão de chamada, desde: chat, partilha
de ficheiros, partilha de ecrã, chamada/conferência áudio,
chamada/conferência vı́deo, e também todos estes serviços
numa sessão. Quando um cliente quer iniciar uma sessão de
chamada/conferência, envia uma mensagem para o servidor
com todas as caracterı́sticas da sessão. Desta forma, este
módulo irá tratar a mensagem para que seja enviada uma
notificação para cada cliente, que esteja convidado para entrar
na sessão. Assim, é possı́vel informar cada um dos clientes de
qual é o tipo de sessão e que serviços são necessários para a
iniciar.
7) Módulo Gestor de Sessões: O módulo gestor de sessões
permite uma gestão mais completa das sessões que são iniciadas. Existem dois tipos de sessões: sessões de utilizadores e
sessões de chamadas. As sessões de utilizadores são iniciadas
sempre que um cliente se autentica no sistema, sendo guardados dados como: nome do utilizador, estado, identificador da
sessão e os endereços correspondentes aos serviços. Quando
o utilizador sai do sistema, a sessão que lhe está associada é
apagada. As sessões de chamadas são iniciadas sempre que é
realizada uma chamada/conferência entre utilizadores. Desta
forma é possı́vel ter um controlo total da chamada, como
a hora a que se iniciou, há quanto tempo está a decorrer
a chamada, quais os participantes e qual o estado atual da
chamada. Com esta informação é possı́vel voltar ao estado
atual de uma chamada mesmo que algum erro ocorra durante
a mesma.
C. Aplicação Cliente
Como referido anteriormente, foi desenvolvida uma
aplicação cliente com o objetivo de demonstrar as funcionalidades da framework. Esta aplicação foi delineada recorrendo a
tecnologias como HTML5, JavaScript e Websockets, que permitem o desenvolvimento de aplicações single page totalmente
web e que tiram partido da Web API da WebRTC. Dos casos de
uso definidos para a arquitetura, implementaram-se e testaramse os seguintes casos: chamadas/conferência áudio e vı́deo;
presença e lista de contactos; chat/mensagens instantâneas;
partilha de ficheiros; partilha de ecrã e histórico de chamadas.
Toda a parte da sinalização usa a tecnologia socket.io, que
permite a criação de namespaces entre peers, garantindo que
a negociação de sinalização seja feita apenas entre dois peers.
Quanto aos serviços de presença, lista de contactos e histórico
de chamadas, foram desencadeados à parte da tecnologia WebRTC, utilizando o Vert.x para troca de mensagens entre peers
e o servidor. Estes módulos interagem mais frequentemente
com o servidor, pois é necessário que mantenham toda a
informação actualizada em runtime.
Todo o processo de validação e teste de serviços foi
contı́nuo, acompanhando dos módulos de suporte. Desta forma
foi possı́vel verificar e validar as funcionalidades, de forma
a poder avançar para o desenvolvimento de outros módulos.
Foi feita uma validação final, onde foram testadas todas as
funcionalidades implementadas na aplicação cliente.
tecnologia WebRTC e o protocolo WebSockets. Como trabalho
futuro pretende-se enriquecer a framework com mais serviços,
como Voice Activity Detection (VAD) e quadro interativo.
Para além disso, pretende-se resolver eventuais problemas
que surjam e melhorar a framework no que diz respeito a
desempenho e interoperabilidade entre browsers.
R EFER ÊNCIAS
[1] Salvatore Loreto and Simon Pietro Romano. Real-Time Communications
in the Web Issues, Achievements, and Ongoing Standardization Efforts.
IEE Computer Society, 16(5):68-73, September/October 2012.
[2] HTML5 Rocks: Getting Started with WebRTC, http://www.html5rocks.
com/en/tutorials/webrtc/basics/, 23 07 2012.
[3] WebRTC:
General
Overview,
http://www.webrtc.org/reference/
architecture, 2011.
[4] The Websocket Protocol, http://tools.ietf.org/html/rfc6455, 2011.
[5] Introducing websockets: Bringing sockets to the web, http://www.
html5rocks.com/en/tutorials/websockets/basics/, 2010-2012.
[6] Html5 web sockets: A quantum leap in scalability for the web., http:
//www.websocket.org/quantum.html, 2013.
[7] The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)., http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-09,
2013.
[8] Real-Time Web Communication by using XMPP Jingle., http://tools.ietf.
org/html/draft-suzuki-web-jingle-00, 2012.
[9] Javascript Session Establishment Protocol (JSEP)., http://tools.ietf.org/
html/draft-ietf-rtcweb-jsep-03, 2012.
[10] Node packaged modules., https://npmjs.org/, 2012.
[11] Nodejs., http://nodejs.org/, 2012.
[12] Interop Notes., http://www.webrtc.org/interop, 2012.
[13] OSGi case study: a modular vert.x., http://www.javacodegeeks.com/
2012/07/osgi-case-study-modular-vertx.html, 2012.
[14] Vert.x., http://vertx.io/, 2012
[15] Vert.x - main manual., http://vertx.io/manual.html, 2012
[16] Realtime/Working
WebRTC
Experiments.,
https://github.com/
muaz-khan/WebRTC-Experiment, 2012
[17] RecordRTC: WebRTC audio/video recording / Demo., https://github.
com/muaz-khan/WebRTC-Experiment/tree/master/RecordRTC, 2012
[18] RTCMultiConnection Documentation., https://github.com/muaz-khan/
WebRTC-Experiment/tree/master/RTCMultiConnection, 2012
[19] DataChannel.js : A JavaScript wrapper library for RTCDataChannel
APIs., https://github.com/muaz-khan/WebRTC-Experiment/tree/master/
DataChannel, 2012
[20] RTCall.js — A library for Browser-to-Browser audio-only calling., https:
//github.com/muaz-khan/WebRTC-Experiment/tree/master/RTCall, 2012
[21] simpleWebRTC., http://simplewebrtc.com/, 2012
[22] Single page apps in depth., http://singlepageappbook.com/, 2012
[23] Vert.x vs node.js simple HTTP benchmarks., http://vertxproject.
wordpress.com/2012/05/09/vert-x-vs-node-js-simple-http-benchmarks/,
2012
[24] Comparing server side Websockets using Atmosphere, Netty, node.js
and vertx.io. , http://weblog.plexobject.com/?p=1698, 2012
[25] Alan Johnston and Daniel Burnett WebRTC: APIs and Rtcweb Protocols
of the Html5 Real-Time Web, USA: Digital Codex LLC, 1 ed., 2012.
V. C ONCLUS ÃO E T RABALHO F UTURO
A tecnologia WebRTC tem vindo a crescer, assim como
a sua comunidade. Existem cada vez mais soluções, tanto
a nı́vel de aplicações, como a nı́vel de bibliotecas. No que
diz respeito aos browsers, cada vez mais suportam diferentes
funcionalidades das APIs desta tecnologia. Tem sido feito um
bom trabalho nesse sentido.
No que diz respeito a serviços, consoante evidenciado neste
trabalho, é possı́vel desenvolver uma framework que permita
a criação de serviços a um mais alto nı́vel. Foi possı́vel desenvolver serviços como: presença, lista de contactos, chamada /
conferência áudio e vı́deo, chat, partilha de ficheiros e partilha
de ecrã. Todos estes serviços foram desenvolvidos utilizando a
31
32
Testing Performance of MLP Neural Networks for
Intrusion Detection with MATLAB
José Quevedo, Rui L. Aguiar
Universidade de Aveiro, Instituto de Telecomunicações, Portugal.
Abstract—The increase of security threats in computer networks requires the implementation of several lines of defense
capable to effectively preserve the confidentiality, integrity and
availability of the information. In the present work multilayer
perceptron (MLP) artificial neural networks are trained to be
used for monitoring events and identifying possible attempts to
compromise the network resources. The 1999 DARPA dataset was
taken as source of traffic packets. Specific packet information
including some relevant features of the application layer and
of the TCP/IP protocols headers were selected for training
and testing these neural networks. As a result, several neural
networks were tested and their optimal design parameters were
derived to ensure an efficient detection of anomalies in the
network traffic. The feasibility of using MLP networks for
intrusion detection was confirmed in such a realistic case.
Keywords—Intrusion Detection, Neural Networks, Multilayer
Perceptron.
I. I NTRODUCTION
In recent years, network security has received critical attention from both academia and industry. As data networks
become more pervasive with larger scales, network intrusion
and attack have become severe threats to network users.
Several security methods are used to prevent and overcome the
negative effects and the consequent monetary losses associated
with security incidents. Intrusion Detection Systems (IDS)
are one of the most widely used mechanisms [1]. Intrusion
detection techniques generally fall into two main categories,
misuse detection, where intrusions are detected by looking for
activities that correspond to known signatures of intrusions or
vulnerabilities, and anomaly detection, that detect intrusions
by searching for abnormal network traffic. Misuse detection
based IDS rely on sets of predefined rules that unfortunately
require frequent updates to remain current, they are usually
unable to detect an attack if the sequence of events is slightly
different from the predefined profile. Such IDS have low false
positive rate, but they cannot detect new types of attacks.
Moreover, there are attacks that cannot be defined by rules.
Anomaly detection based IDS can detect unknown attacks but
the false positive rate is high and the occurrence of false negatives has been also reported [2]. The drawbacks associated to
misuse detection IDS have increased the interest in achieving
high detection performance using anomaly detection IDS.
To improve the detection efficiency of IDS, Artificial Intelligence (AI) technologies such as Artificial Neural Network
(ANN), genetic algorithms [3], [4], fuzzy logic [4], [5], [6]
and theory of immunity [7] have been applied to intrusion
detection system research. In particular, ANN has become a
promising AI approach for designing IDS due to their ability
in classifying patterns. Different ANN technologies such as
multilayer perceptron (MLP), Radial Basis Function [8], [9]
and Self-Organizing Maps (SOM) [10], [11] have been applied
to the intrusion detection problem.
Several researchers have addressed the application of various AI technologies to improve the detection efficiency of
IDS [12], [13]. Some of them have combined MLP networks
with other neural networks technologies, such as SOM, Recirculation Neural Networks (RNN) and Grey Neural Networks
(GNN), in a hierarchical model for obtaining better performance [14], [15], [16], [17]. Considerable amount of work
dealing with classifiers purely based on MLP neural networks
have been developed using different structures to achieve better
performances.
The general structure of these ANN can be described as
composed of consecutive interconnected layers. Each layer
contains a certain number of processing element (neurons)
with the same characteristics (transfer function, learning rate,
etc). MLP architecture often consists of one input layer, one or
more hidden layers and one output layer. During the learning
process the best set of connection coefficients (weights) are
found.
MLP structures with two layers have been reported to have
an overall detection rate of 94% [18] while for structures with
three layers this rate has reached 93.43% [19] and a maximum
of 98% has been reported, but considering only four specific
type of attacks [20]. Hardware based solutions have been also
designed and implemented in FPGA and they have shown to
be able to detect attack at high speed and with acceptable
accuracy [21].
The main objective of the present study is to obtain high
performance intrusion detection classifiers using MLP neural
networks. To this purpose, several structures of MLP networks
are implemented using MATLAB Neural Network Toolbox
and evaluated applying the 1999 DARPA Intrusion Detection
Dataset as source of traffic information. The behavior of
the detection capabilities of the MLP networks is studied
using different normalization methods, training algorithms and
network structures.
MLP training processes become more problematical and require higher computational resources for more complex MLP
structures. Neural networks consume more memory and longer
operational time is involved as a new hidden layer is added.
Furthermore, the resulting neural network is more complex
and less memory efficient [19]. To take this into account, a
secondary objective of the present study is to evaluate the
33
possibility of achieving the same results using simpler neural
network structures. A comparison among the efficiency of 2
layers and 3 layers MLP is provided. MLP networks structures
exhibiting the best combination of effectiveness and efficiency
are determined.
The rest of the paper is organized as follows. The main components of the IDS studied in the present work are sketched in
Section II. Section III deals with the basis for the establishment
of an appropriate dataset for training and evaluating IDS.
Section IV describes the conducted experiments, particularly
the sets of tests used for evaluating the performance of the
MLP network structures in each of the two testing phases.
Results and discussion subsections are included to ensure the
coherence of the given information. Section V concludes the
paper with an overall discussion of the results. Finally, Section
VI recommends actions for further develop this study.
Information Source
Preprocessing Unit
Input Data Generator
Live Network Stream
Offline Traffic Source
Output Data Generator
System Manager
Event Manager
Anomaly Detection Module
Alarm Trigger
MLP
weights
Log Manager
Evaluator
Log File
Expected Output
Other Network
Entities
Report
Generator
The architecture and main components of the MLP-based
anomaly IDS studied in the present work are shown in Figure
1. The system design includes two modes of operation, training
and testing the MLP networks, which is the focus of this work,
and using the already trained networks as traffic classifier. The
Information Source is able to provide two different inputs to
the system, an offline dataset of audit data, which will be used
for training and testing purposes and a live network stream,
that will be checked for intrusions during real world deployments. Once the raw packets (tcpdump formatted) have been
obtained, they need to be processed at the Preprocessing Unit
to generate the data vector to be supplied to the MLP-based
Anomaly Detection Module. During the training and testing
processes, the Preprocessing Unit will also be responsible for
providing the expected output of the system. This information
will be used by the Evaluator, during the testing phase, for
determining the detection rate statistics of the classifier. The
Anomaly Detection Module uses the input data either for
training and testing the MLP network or for analyzing and
detecting intrusions/attacks using the already trained MLP
network. This module is responsible for analyzing the data
vector and generating an output that classifies the packet
into “normal” or “attack”. Such classification is given to the
Event Manager for recording events in the system log file,
for generating the corresponding report and for triggering the
alarm in case an attack is detected. The System Manager
interacts and coordinate with other components based on the
command and parameters delivered from the operator. This
module is also responsible for developing the adequate actions,
which may vary from simple packet discarding to forcing
firewall reconfiguration in order to block the source of an
attack, notifications to administrators, etc.
III. I NTRUSION D ETECTION DATASET
There are two main approaches to the establishment of a
dataset for training and evaluating IDS. The first approach is
based on creating the necessary data within a local network
[22]. Some existing attack tools can be used to generate attack
traffic within a local network. This traffic as well as samples
Normalizer
ANN Input Vector
Feature
Extractor
II. S YSTEM A RCHITECTURE
34
“tcpdump”
Packet
Train MLP
Test MLP
MLP Classifier
Classifier Output
(Normal/Attack)
Figure 1. MLP-based anomaly IDS architecture.
of usual traffic of the network, can be capture to conform the
required dataset. The second approach is based on the use of
available Intrusion Detection Datasets, such as DARPA [23],
or some others derived from DARPA, as KDD-99 [24] and
NSL-KDD [25].
The 1999 DARPA Intrusion Detection Dataset is used in
the present work. It contains more than 200 instances of 58
attack types launched against victim UNIX and Windows NT
hosts arranged in three weeks of training data and two weeks
of testing data [26]. DARPA dataset has been widely used
for training and testing ANN-based anomaly IDS. This fact
facilitates the comparison of the results of the present research
with those obtained by other researchers.
From all the information contained in a packet only specific
part of it, showing specific features, was selected to feed the
MLP network. Selected features included the following:
•
•
•
•
•
•
General information: Time delta from previous received
packet.
IP header fields: Type of service, Total length, Flags,
Time to live, Protocol, Fragment offset.
ICMP header fields: Type, Code.
TCP header fields: Source port, Destination port, Sequence number, Acknowledgment number, Flags, Window size.
UDP header fields: Source port, Destination port, Length.
Higher layer information: First 400 bytes of data.
The original 1999 DARPA dataset is based on raw tcpdump
log files. The selected features were extracted from the tcpdump files and exported into numerical vectors by a parser
developed using MATLAB. Based on the information provided
by DARPA, each vector (processed packet) was classified into
“normal” or “attack”, and a numerical value “0” or “1” was
respectively assigned to that vector.
IV. E VALUATION P ROCESS D ESCRIPTION
This section describes the set of tests used to evaluate the
performance of several MLP network structures and identifies
those design parameters leading to optimal intrusion detection
performance. Tests also assess the effectiveness of various
training algorithms and normalization methods.
B. First Testing Phase
1) Design Considerations: MLP networks with only one
hidden layer were used during this first testing phase. The
training functions and normalization methods provided by
MATLAB neural network toolbox were considered. For all
possible combinations of such mechanisms, the number of
neurons in the hidden layer was incremented from 5 to 50
with a 5 neurons step. The trainings were conducted using
300 epochs and the goal error was set to 1 × 10−10 . The
remaining training parameters were set to the default values
of each algorithm, these values can be found in [27].
2) Results: During this testing phase a total amount of 400
MLP networks were trained. The training algorithms trainlm
and trainbfg were not analyzed because they require a lot of
memory to run [27] and are therefore considered to have only
low significance for the deployment of IDS, where systems
may be memory limited. The 65 best performance results for
the trained networks using different normalization methods
are shown in Figure 2 in terms of the cumulative distribution
function (CDF) of their overall detection rates.
3) Further Evaluations: Taking into account that the best
results of this first testing phase refer to the use of mapstd normalization method, it was considered appropriate to continue
using it to further evaluations involving:
• 3 layers MLP networks (two hidden layers of neurons),
using all training algorithms to train the network structures resulting from varying the number of neurons in
each of the two layers from 5 to 30, with a 5 neurons
step.
mapstd
mapminmax [−1.1]
mapminmax [0.1]
processpca
CDF for different normalization methods
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
50
55
60
65
70
75
80
Overall detection rates (%)
85
90
95
Figure 2. Best overall detection rates for 2 layers MLP networks using
different normalization methods.
2 layers MLP, using all training algorithms to train the
network structures resulting from varying the number of
neurons in the hidden layer from 5 to 50 with a 5 neurons
step, but this time the higher layer information features
were not submitted to the MLP network.
The 65 best performance results are shown in Figure 3 in
terms of the CDF of the overall detection rates for the
MLP networks, where “2 layers” refers to the results of the
previous subsection when using mapstd normalization method,
“3 layers” refers to the results for the networks with two
hidden layer evaluated in this subsection and “2 layers*” refers
to the results of the networks for which the higher layer
information was not submitted to the MLP network.
•
1
2 layers
3 layers
2 layers *
0.9
CDF for different network structures
A. Initial Design Considerations
The input layer of the MLP networks used in the present
work consists of 419 neurons. The number of neurons corresponds to the 19 selected features from the TCP/IP protocols
header and the first 400 bytes of the payload. Each byte taken
from the payload is used as raw binary data and is considered
as an individual feature. For packets with less than 400 bytes
in the payload the corresponding empty inputs are filled with
zeros. The number of neurons in the hidden layers is variable.
The dimension of the output layer is given by the number of
sorts used by the classifier. In this case two possible outputs
are considered (“normal” and “attack”) and therefore only one
output neuron is required. The logsig function was selected as
transfer function because it is bounded between 0 and 1 and is
continuous within the whole interval. The detection threshold
was defined to be 0.5 so that an output value within the
interval [0, 0.5) is considered to be normal and one within the
interval [0.5, 1] is considered to be an attack. The performance
of the trained networks was evaluated based on the detection
percentages of normal and attack packets.
1
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
72
74
76
78
80
82
84
86
88
90
92
Figure 3. Best overall detection rates for different network structures using
mapstd normalization method.
4) Discussion: The analysis of the stability of the overall
detection rates of MLP networks for different normalization
methods indicates, as shown in Figure 2, that the best performance was obtained when using mapstd as normalization
method.
35
C. Second Testing Phase
Based on the results of the first testing phase, pointing
to mapstd as the normalization method showing better performance, a second testing phase was designed to further
evaluate the behavior of different structured MLP networks
using mapstd as normalization method.
1) Design Considerations: Only 2 layers MLP networks
were evaluated during the second training phase. Mapstd function was used as normalization method. As training algorithms
were used traingda, traingdx, traincgf, traincgp, traincgb and
trainscg, because they led to acceptable overall detection rates
during the first training phase (more than 85%).
In order to ensure the better accuracy in the results, the
number of epochs was increased up to 1000 while the number
of neurons in the hidden layer was varied from 1 to 100 with
one neuron step.
2) Results: During this second testing phase a total amount
of 600 MLP networks were trained. Obtained results have
indicated an overall improvement in 2 layers MLP networks
performance, characterized by a greater number of networks
with higher overall detection rate. Twelve MLP network
reached overall detection rates above 96%, as it is shown in
Table I.
Table I
B EST 12 OVERALL DETECTION RATES FOR THE SECOND TESTING
Training
Algorithm
Neurons in
Hidden Layer
traingda
traingdx
traingda
traingdx
traingdx
trainscg
traingda
trainscg
traingdx
trainscg
traingdx
traingdx
45
63
20
94
44
88
71
24
40
27
74
97
Attack
98,36
96,5
97,37
95,86
97,1
96,2
96,95
96,37
96,06
96,43
95,59
95,73
PHASE
Detection Rate (%)
Normal
Overall
94,92
96.64
96,44
96.47
95,39
96.38
96,9
96.38
95,35
96.22
96,12
96.16
95,27
96.11
95,83
96.10
96,04
96.05
95,59
96.01
96,43
96.01
96,29
96.01
0.9
0.8
0.7
0.6
0.5
0.4
0.3
traincgb
traincgf
traincgp
traingda
traingdx
trainscg
0.2
0.1
0
93
93.5
94
94.5
95
95.5
96
96.5
97
Figure 4. Best overall detection rates for 2 layers MLP networks using
different training algorithms.
According to the results shown in Figure 4, training process
using algorithms traingda, traingdx and trainscg have resulted
in better performance of the MLP networks. From Table I
it can be concluded that the two MLP networks with the
better combination of effectiveness and efficiency were the
ones trained with traingda and having respectively 45 and 20
neurons in the hidden layer. However, no clear relationship
among the number of neurons in the hidden layer and the
performance of the MLP networks could be established.
D. Comparison with other works
Several representative results, ours included, are listed in
Table II. They basically refer to the use of different MLP
structures taking the DARPA dataset, or already processed
versions of it, as source of traffic packets. Although the
reported results represent what could be expected from the
MLP based IDS solutions in terms of detection rates, they
have been achieved using different criteria (e.g., structure,
training algorithm, transfer function). In consequence, no clear
conclusion can be derived from Table II on which MLP
network design parameters lead to a better performance. The
comparison of the results indicates that our system is greatly
competitive, as the one with higher detection rate is restricted
to the analysis of only four specific types of attacks.
V. C ONCLUSIONS
The detailed results derived from the application of the
different training algorithms are shown in Figure 4 in terms
of the CDF of the overall detection rates for the 163 trained
networks which values exceeded 93%.
3) Discussion: The results of this second testing phase
indicate that the further refinement in the 2 layers MLP designs
have led to a significant increase of the overall detection
rate if compared with the results from the previous phase.
36
1
CDF for different training algorithms
Additional tests to evaluate the behavior of different structured MLP networks have indicated, as shown in Figure 3,
that when using mapstd as normalization method the 2 layers
MLP networks exhibited better performance than 3 layers
MLP networks. In addition, the use of 3 layers MLP is not
recommendable as including a second hidden layer increases
the complexity of the ANN and consequently requires more
computational resources. The obtained results also indicate
that when applying 2 layers MLP networks, the exclusion of
higher layer information features is not recommendable.
The rise of shared networks and Internet usage demand
an increased attention to information systems security, particularly on the improvement and development of intrusion
detection systems. The use of mapstd as normalization method
for MLP networks has led to the best performances with
overall detection rates exceeding 96%, which are comparable
with the results reported by others authors. Using mapstd as
normalization method 3 layers MLP networks showed lower
performance than 2 layers MLP networks. The obtained results
have confirmed the feasibility of using MLP networks as
classifiers for anomaly detection based IDS.
Table II
C OMPARISON OF PERCENTAGES OF SUCCESSFUL CLASSIFICATION FOR
ANN- BASED IDS
Reference
Moradi, M. et al., 2004 [28]
Moradi, M. et al., 2004[28]
Siddiqui, M., 2004 [29]
Sammany, M. et al., 2007 [30]
Barapatre, P. et al., 2008 [31]
Ahmad, I. et al.,2009 [20]
Haddadi, F. et al., 2010[18]
Norouzian, M.R. et al.,2011 [19]
Present work
MLP Structure
2-layers
3-layers
2-layers
3-layers
2-layers
3-layers
2-layers
3-layers
2-layers
Detection Rate (%)
87
91
81.37
93.43
81.96
98*
94
90.78
96.64
* Limited to the analysis of only four specific type of attacks
VI. F UTURE W ORK
From the practical point of view, the experimental results
imply that there is more to do in the field of ANN-based IDS.
Future development of the present study should be aimed at
seeking for higher processing speed of the networks through
the establishment of new methods for reducing the number
of features to be extracted from the packet information.
Possible combinations of multiple neural networks should be
considered as a way to improve the performance of the MLP
networks. Assessing the performance of MLP networks using
specially created datasets should be explored.
VII. ACKNOWLEDGMENTS
Special thanks should be expressed to Walter Baluja García
from the Polytechnic University of Havana, Cuba, for his
valuable comments and contributions to this work.
R EFERENCES
[1] R. Richardson, “2010/2011 computer crime and security survey,” Computer Security Institute (CSI), Tech. Rep., 2010.
[2] P. García-Teodoro, J. Díaz-Verdejo, G. Maciá-Fernández, and
E. Vázquez, “Anomaly-based network intrusion detection: Techniques,
systems and challenges,” Computers & Security, vol. 28, no. 1-2, pp.
18 – 28, 2009.
[3] W. Li, “Using genetic algorithm for network intrusion detection,”
Proceedings of the United States Department of Energy Cyber Security
Group, pp. 1–8, 2004.
[4] S. M. Bridges and R. B. Vaughn, “Fuzzy data mining and genetic
algorithms applied to intrusion detection,” in Proceedings twenty third
National Information Security Conference, 2000.
[5] J. Dickerson and J. Dickerson, “Fuzzy network profiling for intrusion
detection,” in Fuzzy Information Processing Society, 2000. NAFIPS. 19th
International Conference of the North American, 2000, pp. 301–306.
[6] J. Gomez and D. Dasgupta, “Evolving fuzzy classifiers for intrusion
detection,” in Proceedings of the 2002 IEEE Workshop on Information
Assurance, vol. 6, no. 3. New York: IEEE Computer Press, 2002, pp.
321–323.
[7] J. Kim, P. J. Bentley, U. Aickelin, J. Greensmith, G. Tedesco, and
J. Twycross, “Immune system approaches to intrusion detection - a
review,” Natural Computing, vol. 6, no. 4, pp. 413–466, 2007.
[8] A. Rapaka, A. Novokhodko, and D. Wunsch, “Intrusion detection using
radial basis function network on sequences of system calls,” in Neural
Networks, 2003. Proceedings of the International Joint Conference on,
vol. 3, 2003, pp. 1820–1825 vol.3.
[9] A. Hofmann and B. Sick, “Evolutionary optimization of radial basis
function networks for intrusion detection,” in Neural Networks, 2003.
Proceedings of the International Joint Conference on, vol. 1, 2003, pp.
415–420 vol.1.
[10] H. G. Kayacik, A. N. Zincir-Heywood, and M. I. Heywood, “A hierarchical som-based intrusion detection system,” Engineering Applications
of Artificial Intelligence, vol. 20, no. 4, pp. 439 – 451, 2007.
[11] Á. Grediaga, F. Ibarra, F. García, B. Ledesma, and F. Brotóns, “Application of neural networks in network control and information security,” in
Advances in Neural Networks-ISNN 2006. Springer, 2006, pp. 208–213.
[12] F. Yanwei, Z. Yingying, and Y. Haiyang, “Study of neural network technologies in intrusion detection systems,” in Wireless Communications,
Networking and Mobile Computing, 2009. WiCom ’09. 5th International
Conference on, sept. 2009, pp. 1 –4.
[13] C. Modi, D. Patel, B. Borisaniya, H. Patel, A. Patel, and M. Rajarajan, “A
survey of intrusion detection techniques in cloud,” Journal of Network
and Computer Applications, vol. 36, no. 1, pp. 42 – 57, 2013.
[14] C. Jirapummin, N. Wattanapongsakorn, and P. Kanthamanon, “Hybrid
neural networks for intrusion detection system,” in Proc. of ITC–CSCC,
2002, pp. 928–931.
[15] V. Golovko, L. Vaitsekhovich, P. Kochurko, and U. Rubanau, “Dimensionality reduction and attack recognition using neural network
approaches,” in Neural Networks, 2007. IJCNN 2007. International Joint
Conference on, aug. 2007, pp. 2734 –2739.
[16] V. Golovko, P. Kachurka, and L. Vaitsekhovich, “Neural network ensembles for intrusion detection,” in Intelligent Data Acquisition and
Advanced Computing Systems: Technology and Applications, 2007.
IDAACS 2007. 4th IEEE Workshop on, sept. 2007, pp. 578 –583.
[17] D.-X. Xia, S.-H. Yang, and C.-G. Li, “Intrusion detection system based
on principal component analysis and grey neural networks,” in Networks
Security Wireless Communications and Trusted Computing (NSWCTC),
2010 Second International Conference on, vol. 2, april 2010, pp. 142
–145.
[18] F. Haddadi, S. Khanchi, M. Shetabi, and V. Derhami, “Intrusion detection and attack classification using feed-forward neural network,” in
Computer and Network Technology (ICCNT), 2010 Second International
Conference on, april 2010, pp. 262 –266.
[19] M. Norouzian and S. Merati, “Classifying attacks in a network intrusion
detection system based on artificial neural networks,” in Advanced Communication Technology (ICACT), 2011 13th International Conference
on, feb. 2011, pp. 868 –873.
[20] I. Ahmad, A. Abdullah, and A. Alghamdi, “Application of artificial
neural network in detection of probing attacks,” in Industrial Electronics
Applications, 2009. ISIEA 2009. IEEE Symposium on, vol. 2, oct. 2009,
pp. 557 –562.
[21] A. Hassan, A. Elnakib, and M. Abo-Elsoud, “Fpga-based neuroarchitecture intrusion detection system,” in Computer Engineering Systems, 2008. ICCES 2008. International Conference on, nov. 2008, pp.
268 –273.
[22] M. Amini, R. Jalili, and H. R. Shahriari, “Rt-unnid: A practical solution
to real-time network-based intrusion detection using unsupervised neural
networks,” Computers & Security, vol. 25, no. 6, pp. 459 – 468, 2006.
[23] “Darpa intrusion detection data sets,” 1999. [Online]. Available: http://
www.ll.mit.edu/mission/communications/cyber/CSTcorpora/ideval/data/
[24] “Kdd cup 1999 data,” 1999. [Online]. Available: http://kdd.ics.uci.edu/
databases/kddcup99/kddcup99.html
[25] M. Tavallaee, E. Bagheri, W. Lu, and A. Ghorbani, “A detailed analysis
of the kdd cup 99 data set,” in Proceedings of the Second IEEE
Symposium on Computational Intelligence for Security and Defence
Applications 2009, 2009.
[26] R. Lippmann, J. W. Haines, D. J. Fried, J. Korba, and K. Das, “The
1999 darpa off-line intrusion detection evaluation,” Computer Networks,
vol. 34, no. 4, pp. 579 – 595, 2000.
[27] “Matlab r2012b neural network toolbox documentation,” 2012. [Online].
Available: http://www.mathworks.com/help/nnet/index.html
[28] M. Moradi and M. Zulkernine, “A neural network based system for
intrusion detection and classification of attacks,” in Proceedings of
2004 IEEE International Conference on Advances in Intelligent Systems
Theory and Applications, Luxembourg Kirchberg, Luxembourg, 2004.
[29] M. Siddiqui, “High performance data mining techniques for intrusion
detection,” Ph.D. dissertation, University of Central Florida Orlando,
Florida, 2004.
[30] M. Sammany, M. Sharawi, M. El-Beltagy, and I. Saroit, “Artificial neural
networks architecture for intrusion detection systems and classification
of attacks,” in fifth international conference-INFO, 2007, pp. 24–26.
[31] P. Barapatre, N. Tarapore, S. Pukale, and M. Dhore, “Training mlp neural
network to reduce false alerts in ids,” in Computing, Communication and
Networking, 2008. ICCCn 2008. International Conference on, dec. 2008,
pp. 1 –7.
37
38
Configuração Dinâmica em Redes sem Fios
Daniel Alexander Lopes Fuentes
António Manuel de Jesus Pereira
ESTG, Instituto Politécnico de Leiria
INOV INESC Inovação, Delegação de Leiria
Centro de Investigação em Informática e Comunicações,
IPLeiria
ESTG, Instituto Politécnico de Leiria
INOV INESC Inovação, Delegação de Leiria
Centro de Investigação em Informática e Comunicações,
IPLeiria
Abstract - A evolução das tecnologias de informação e
comunicação tem levado os operadores de comunicações a
investir na sua infraestrutura e a adaptarem-se à realidade atual.
O problema é que este investimento apenas acontece nos grandes
centros populacionais e não nas zonas rurais e dispersas, visto
estas não proporcionarem o retorno financeiro desejado. Esta
situação levou ao aparecimento de projetos de redes sem fios
como
alternativa
aos
operadores
de
comunicações,
providenciando serviços multimédia, nomeadamente o acesso à
Internet. No entanto estes projetos têm-se revelado muito difíceis
de manter devido ao investimento financeiro necessário. Neste
artigo é proposto um sistema que tem como objetivo tornar as
soluções de redes locais sem fios de larga escala sustentáveis,
autónomas e inteligentes, reduzindo assim os custos associados
com a implementação e manutenção das mesmas, tornando-as
sustentáveis. Desta forma evitam-se intervenções por parte dos
administradores ou técnicos especializados, minimizando assim
os problemas associados à dispersão dos equipamentos em
ambientes rurais. Os testes efetuados ao sistema, em laboratório e
em cenário real, mostram a rapidez e autonomia na execução das
tarefas da solução apresentada.
Palavras-chave:
Configuração
Dinâmica,
Sistemas
Inteligentes, Sistemas Autónomos, Ambientes Rurais, Redes
Sem Fios de Larga Escala.
I.
INTRODUÇÃO
A crescente procura por um acesso à Internet tem levado os
operadores de comunicações a apostarem forte nas suas
infraestruturas. O problema é que essas mesmas estruturas
apenas estão a ser otimizadas onde existe uma grande
concentração de população. As zonais rurais e dispersas, visto
terem pouca população, não são um bom retorno financeiro
para os operadores, o que os leva a não investir nas
infraestruturas localizadas nestas zonas [1]. Por vezes até
existem localizações onde nem sequer há um acesso mínimo à
Internet, o que levou algumas freguesias a implementar redes
sem fios para colmatar esta necessidade [2]. O problema neste
tipo de redes é que têm que abranger bastantes populações
dispersas numa vasta área geográfica [3], o que levanta muitos
problemas em termos de custo de instalação e manutenção,
tornando-as uma solução não sustentável.
Este tipo de redes, denominadas de redes locais sem fios de
larga escala (Large-Scale WLAN1) [4], é composto por vários
pontos de distribuição espalhados geograficamente e que se
1
encontram interligados entre si através de ligações sem fios. A
configuração desses pontos de distribuição tem de ser feita, no
início, aquando a instalação da rede para que se consiga obter
ligação entre os vários pontos da mesma.
A própria instalação e configuração da infraestrutura da rede
por vezes é dificultada, visto que pode existir algum problema
de configuração em algum equipamento, o qual tem de ser
reconfigurado no local. Os problemas não existem apenas
quando se constrói a infraestrutura, eles também se
manifestam durante o funcionamento da mesma,
nomeadamente desconfigurações de equipamentos e alterações
obrigatórias na topologia de rede. Isto tudo leva a que haja
custos demasiado elevados na manutenção de uma rede local
sem fios de larga escala [5].
Os factos supracitados associados à localização rural deste
tipo de redes leva a que o seu custo de manutenção seja
agravado pela distância a que as equipas especializadas se
encontram. De forma a minimizar esses entraves são
implementados sistemas de monitorização e gestão remota da
rede que ajudam a reduzir os custos de manutenção. Isto
consegue-se através de uma gestão centralizada de toda a rede,
na qual são monitorizados todos os equipamentos presentes na
mesma [6]. A limitação destes sistemas de monitorização
encontra-se no facto destes necessitarem de ter todos os
equipamentos alcançáveis na rede para poderem funcionar
corretamente.
A evolução das redes de comunicação tem levado a vários
estudos na área das redes do futuro, nomeadamente nas
características que uma rede deve ter para ser considerada
como tal [7]. Duas dessas caraterísticas são a
autossustentabilidade e a capacidade da rede ser autónoma, as
quais são necessidades encontradas em redes locais sem fios
de larga escala.
No trabalho apresentado neste artigo pretende-se não só
colmatar as falhas presentes no sistema de monitorização, mas
também tornar este tipo de redes sem fios inteligentes,
autónomas e acima de tudo sustentáveis, direcionando-as para
o futuro.
Para além da presente secção, o artigo encontra-se estruturado
da seguinte forma: a secção II apresenta o trabalho relacionado
com projetos de configuração dinâmica em redes sem fios; A
secção III apresenta a arquitetura do sistema; Na secção IV
apresenta-se o cenário de testes, quais os objetivos dos
mesmos e os resultados dos diferentes tipos de testes; Na
do inglês Wireless Local Area Network
39
secção V encontram-se as conclusões sobre todo o trabalho
elaborado.
II.
REVISÃO DA LITERATURA
A automatização em redes de comunicação desde cedo que
desperta grande interesse por parte dos investigadores
agregados à área, fator que se deve ao crescimento
exponencial, tanto no tamanho das redes como na área que
abrangem e nos serviços associados às mesmas [8][9]. Este
facto suscitou a necessidade do estudo de novos conceitos e
tecnologias que fossem de encontro à resolução da
problemática da autoconfiguração dos equipamentos e
otimização das redes de comunicação [10][11].
A investigação realizada neste âmbito, agregada à crescente
exigência por parte dos gestores de rede, levou ao
aparecimento de diversos estudos relacionadas com esta
matéria, nomeadamente a nível de paradigmas a serem
adotados na criação de redes sem fios autoconfiguráveis e das
abordagens a ter na disposição dos pontos de acesso na rede
[12][13].
A informação inerente aos processos descritos anteriormente
agregada à necessidade, cada vez mais premente, do
processamento de grandes quantidades de dados por parte
destes equipamentos, levou ao aparecimento do conceito de
arquiteturas distribuídas [14][15][16], cujo objetivo é
descentralizar o tratamento desta informação distribuindo-a
por todos os equipamentos presentes na rede.
A evolução destes sistemas autónomos levou a que os
investigadores aplicassem os conhecimentos de outras áreas
neste tipo de redes, nomeadamente inteligência artificial,
criando assim sistemas baseados em arquiteturas multiagentes,
cuja função principal é dotar os dispositivos de uma
inteligência própria que os permita ser autónomos [17][18]
[19].
A configuração dinâmica de equipamentos em redes locais
sem fios (WLAN) já deu alguns passos, nomeadamente em
redes domésticas / pequenos escritórios (SOHO2). Esta
funcionalidade é utilizada por alguns fabricantes para permitir
que equipamentos como computadores, telemóveis ou mesmo
tablets se liguem à rede sem fios de uma forma fácil. Desta
forma é extremamente simples conseguir aceder a uma rede
protegida com poucos conhecimentos, ou mesmo nenhuns, de
redes sem fios.
O Wi-Fi Protected Setup (WPS) [20] providencia dois
mecanismos de configuração de redes SOHO, um através de
um Personal Identification Number (PIN) e outro via Push
Button Configuration (PBC). Estes permitem que utilizadores
com poucos conhecimentos em configuração de redes sem fios
consigam adicionar novos equipamentos à rede de forma
segura.
O AirStation One-Touch Secure System (AOSS) [21] funciona
de maneira similar ao WPS mas apenas fornece o mecanismo
de PBC. Este sistema foi desenvolvido pela Bufallo
Technology e está presente em quase todos os seus
equipamentos de redes sem fios SOHO.
2
40
do inglês Small Office / Home Office
Tendo em vista os objetivos a que nos propomos com esta
solução e tendo em conta os trabalhos encontrados na área,
propomos um sistema autónomo, distribuído e inteligente que:
visa a autoconfiguração de equipamentos presentes numa
infraestrutura de rede local sem fios de larga escala em
ambientes rurais, proporcionando a redução de custos na
implementação e manutenção da mesma; minimiza a
necessidade de intervenção de equipas especializadas no
terreno; reduz os problemas inerentes à dispersão geográfica
dos equipamentos e à sua acessibilidade; não impõe limitações
em termos de escalabilidade da infraestrutura.
III.
ARQUITETURA DO SISTEMA
A infraestrutura de uma rede local sem fios de larga escala é
composta, nomeadamente, por clientes, pontos de distribuição,
servidores e gateways. Os clientes são os equipamentos
instalados em casa dos utilizadores finais, como o próprio
nome indica. Os pontos de distribuição são os equipamentos
distribuídos pela área a abranger, estão interligados entre si
através de ligações sem fios e fornecem um ponto de ligação
aos clientes. Os servidores são os equipamentos que fornecem
os mais variados serviços aos utilizadores da rede e
encontram-se normalmente localizados no ponto central da
mesma. Os gateways são os equipamentos responsáveis por
interligar a rede interna ao mundo exterior, fornecendo o
acesso à Internet aos utilizadores da rede.
O Dynamic Wireless Configuration System (DWCS)
implementa uma arquitetura distribuída e multiagente que
permite subdividir as tarefas pelos vários equipamentos na
rede, os quais têm incorporado agentes que se encarregam de
cumprir essas mesmas tarefas. Estes agentes podem ter várias
funções, consoante a sua finalidade.
Um agente é uma entidade baseada em software que, neste
caso, consegue aceder às informações do equipamento onde se
encontra, efetuando as operações necessárias no mesmo. Estes
agentes interligam-se entre si para fornecer uma solução
distribuída, providenciando assim divisão de tarefas entre
equipamentos. Os agentes são também responsáveis por
manter o correto funcionamento dos dispositivos e, para tal,
têm de garantir a comunicação entre equipamentos.
Figura 1 - Arquitetura do sistema
Na Figura 1 podemos visualizar a arquitetura definida e onde
se encontram os respetivos agentes localizados. O agente
Cliente, o agente Distribuição, o agente Servidor e a rede de
configuração, apresentada mais à frente, formam este sistema,
sendo cada um destes imprescindíveis para o correto
funcionamento da rede e do sistema.
A.
Agentes
O agente Cliente, apresentado na Figura 2, encontra-se
presente no equipamento que está em casa do utilizador final.
É este dispositivo que faz a ligação do cliente ao core da rede
sem fios. Este é responsável pelas configurações do
equipamento, nomeadamente por iniciar o dispositivo em
modo configuração ou standard, e está periodicamente a
monitorizar o dispositivo, para verificar a ligação à rede e a
existência de novas configurações para o mesmo.
Os equipamentos podem iniciar em dois modos de operação:
no modo de configuração o equipamento inicia num estado em
que tenta adquirir as suas configurações de rede; no modo
standard o equipamento inicia normalmente já com as
configurações obtidas no modo de configuração.
O agente Cliente liga-se ao agente Distribuição para poder
estabelecer comunicação com o agente Servidor.
Desta forma estes conseguem adquirir as suas configurações
dinamicamente, sem ser necessária qualquer intervenção dos
administradores de rede.
O agente Distribuição, exemplificado na Figura 3, é a ponte de
ligação entre o agente Cliente e o agente Servidor.
O agente Servidor, responsável por manter a funcionalidade da
rede, guardar toda a informação inerente à configuração e
permitir a gestão do sistema por parte do administrador,
agrega também uma componente de web services, como
constatado na Figura 4. Esta componente disponibiliza as
configurações necessárias aos outros agentes presentes na
infraestrutura, possibilitando deste modo a sua configuração.
BASE DE DADOS
FICHEIROS DE CONFIGURAÇÃO
SOFTWARE DE GESTÃO
WEB SERVICES
AGENTE SERVIDOR
Figura 4 - Agente Servidor
Figura 2 - Agente Cliente
O agente Distribuição está presente nos dispositivos de core e
tem o objetivo de permitir a comunicação entre os vários
dispositivos (clientes, core e servidores) para que estes se
consigam configurar dinamicamente.
Nestes equipamentos existem várias redes definidas, desde
ligações ponto-a-ponto a redes de distribuição, em que se
destaca a rede de configuração DWCS, à qual todos os
equipamentos, que estejam em modo configuração, se ligam.
O DWCS interage diretamente com o sistema de
monitorização da rede, como se pode ver na Figura 5. Esta
interação
permite
que
os
equipamentos
sejam
automaticamente adicionados ao sistema de monitorização
sem ser necessária qualquer intervenção por parte do
administrador da rede. Isso torna possível também que o
DWCS consiga obter dados do estado dos equipamentos da
rede diretamente do sistema de monitorização. Desta forma
consegue-se gerir o sistema de monitorização da rede através
do servidor de DWCS e da respetiva plataforma de gestão,
evitando a redundância de operações por parte do
administrador.
Servidor DWCS
Rede
Sistema de
monitorização
Adicionar, editar ou remover equipamentos
Consultar o estado dos equipamentos
Figura 5 - Comunicação entre sistemas
B.
Figura 3 - Agente Distribuição
Rede de configuração
Um dos pontos fulcrais neste sistema é a rede de configuração.
É através desta rede que os dispositivos conseguem
estabelecer comunicação com o servidor e adquirir as suas
configurações. Sem esta rede de configuração não é possível
configurar e recuperar os equipamentos automaticamente,
porque de outra forma estes não teriam qualquer meio para
poder comunicar com o servidor central.
41
Uma das maiores preocupações encontradas é a segurança do
sistema, visto querer-se evitar ao máximo falhas na mesma.
No sentido de solucionar esta problemática, a rede encontra-se
protegida com encriptação Wi-Fi Protected Access II (WPA2)
[20] utilizando passwords com 128 bits, garantindo assim que
apenas os equipamentos que possuam o sistema DWCS
conseguem aceder à mesma.
Para uma proteção superior são também utilizadas as
respetivas firewalls nos equipamentos de distribuição,
devidamente configuradas, para que a rede de configuração
apenas permita tráfego de configuração na mesma,
nomeadamente acesso exclusivamente ao servidor de DWCS.
A rede de configuração pode ser criada de duas formas:
através de um rádio Wi-Fi adicional, sendo uma rede
independente, ou através da configuração de um Ponto de
Acesso Virtual (Virtual AP). Os “Virtual AP” podem ser
criados utilizando para tal um rádio que esteja a desempenhar
funções de ponto de acesso. Neste caso, visto que todos os nós
do core da rede contêm uma rede de distribuição, para os
clientes se ligarem, esta poderá ser utilizada para esse mesmo
efeito.
C.
Funcionamento do sistema
Para que seja possível implementar o sistema DWCS, o agente
Distribuição tem de disponibilizar a rede de configuração para
que os clientes e outros nós secundários possam efetuar a sua
configuração dinamicamente. Esta rede é disponibilizada pelo
agente Distribuição presente nos equipamentos de core,
podendo ser uma rede real ou virtualizada. É neste core que
são encontrados dois tipos de nós, o principal, que é o ponto
central da rede que está ligado aos servidores e ao gateway, e
os secundários, que são todos os outros. No primeiro tipo
temos a Distribuição Principal (DP), apresentada na Figura 6,
que é o nó central da rede. Este encontra-se ligado
diretamente, através da rede cablada, à rede do servidor de
DWCS. Neste nó o dispositivo utiliza a “Config LAN” para se
ligar ao servidor e adquirir automaticamente as suas
configurações, isto quando se encontra em modo de
configuração.
A “Config LAN” é a porta de rede da Distribuição Principal
que está diretamente ligada à rede do servidor de DWCS.
Desta forma o agente distribuição consegue aceder ao servidor
para adquirir as configurações do equipamento.
Figura 6 - Tipos de distribuição
No segundo tipo temos as Distribuições Secundárias (DS),
exemplificadas também na Figura 6,que são aquelas que estão
distribuídas, geograficamente, pela área englobada pela rede
de larga escala. De salientar que este tipo de nós pode não ter
rede de distribuição associado, visto existirem pontos na rede
42
que podem servir apenas como ponte entre várias localidade,
isto devido à falta de linha de vista entre os nós ou distâncias
excessivas.
Este nó, quando em modo de configuração, utiliza o “Config
Radio” para se ligar à rede de configuração mais próxima. O
“Config Radio” é o primeiro rádio disponível no equipamento
e é aquele que está direcionado para o nó mais próximo do
servidor. Isto é necessário pelo facto de um nó poder ter vários
rádios, o que não pode ser um fator que impeça o sistema de
funcionar corretamente.
O funcionamento do sistema de DWCS é um conjunto de
processos simples, o que o torna eficaz. Numa fase inicial
todos os equipamentos na rede (core e clientes) encontram-se
em modo de configuração. O agente presente na Distribuição
Principal, que está ligada diretamente à rede do servidor de
DWCS através da “Config LAN”, acede ao servidor,
descarrega os ficheiros de configuração, aplica-os e reinicia o
equipamento.
Após a DP reiniciar, esta encontra-se configurada e pronta a
fornecer, aos outros nós, acesso ao servidor de DWCS. Uma
Distribuição Secundária liga-se à rede de DWCS da DP,
através do “Config Radio”, e configura-se automaticamente.
De seguida uma segunda DS liga-se ao próximo nó, presente
no caminho de acesso ao servidor, através da rede DWCS
deste e adquire as suas configurações para poder iniciar
normalmente. Neste ponto já todo o core da rede se encontra
configurado e os equipamentos cliente começam a ligar-se ao
sistema de DWCS do mesmo para que os seus agentes
comecem a adquirir as configurações dos equipamentos. No
final destes processos toda a rede se encontra configurada
(Figura 7) dinamicamente sem ser necessária a intervenção do
administrador da mesma.
Figura 7 - Processo de configuração
D.
Algoritmo
De forma a se conseguir elaborar um sistema genérico de
configuração dinâmica, elaborou-se um algoritmo de
configuração que pode ser utilizado nos agentes Cliente e
Distribuição. A Figura 8 apresenta esse mesmo algoritmo.
O equipamento ao iniciar verifica se arrancou em modo
configuração ou não. Em caso positivo, o dispositivo verifica
se tem conectividade ao servidor de DWCS e se tem alguma
configuração disponível no mesmo. Se tiver este é
descarregado, aplicado e o dispositivo reinicia configurado. Se
não tiver conectividade ou não houver configuração
disponível, o sistema aguarda pela próxima iteração. Estas
iterações acontecem periodicamente, consoante o tempo prédefinido pelo administrador, isto para não aumentar o
processamento dos equipamentos desnecessariamente. Caso
não esteja, o equipamento verifica o sinal wireless, se estiver
inativo este verifica se a rede de configuração está alcançável
pelo sistema. Se estiver alcançável o dispositivo aguarda pela
próxima iteração até voltar a fazer nova verificação.
OpenWRT [23], um firmware baseado em Linux muito
utilizado em dispositivos de rede.
Figura 9 - Cenário de testes
Devido a este sistema ser open-source torna-se uma vantagem
para este projeto, sendo possível alterar o software dos
equipamentos para os tornar autónomos e inteligentes, o que
normalmente não seria possível de efetuar em equipamentos
com firmware proprietário.
Figura 8 - Algoritmo de configuração
Se não estiver alcançável, o equipamento verifica há quanto
tempo a ligação sem fios está desligada, se for há mais tempo
que o pré-definido o dispositivo reinicia em modo
configuração, visto poder haver algum problema com a
ligação que foi obtida do servidor, senão aguarda até fazer
nova verificação da conetividade. Caso esteja, o equipamento
verifica a ligação ao servidor e questiona o mesmo se este tem
novas configurações. Caso não haja resposta ou novas
configurações o dispositivo aguarda até fazer nova
verificação. Ao obter novas configurações o equipamento
aplica-as e reinicia.
Este algoritmo, na forma como foi idealizado, permite ser
adaptado para os diferentes equipamentos, de fabricantes
diferentes, que se possam utilizar na rede. Desta forma
conseguem-se obter resultados semelhantes em plataformas
diferentes.
IV.
TESTES E RESULTADOS
Nesta secção são descritos pormenorizadamente todos os
testes que foram efetuados ao sistema DWCS, tal como testes
de configuração e recuperação do equipamento. Também aqui
são apresentados os resultados de todos os testes efetuados.
A.
Cenário de testes
Para efetuar todos os testes necessários implementou-se um
pequeno cenário laboratorial composto por uma DP, uma DS e
um cliente, o qual é apresentado na Figura 9.
Este cenário é a réplica, em parte, de um ramo de uma rede
local sem fios de larga escala existente, a rede Memória
Online, que é uma rede presente na freguesia da Memória.
Esta rede está localizada numa região rural composta por
montes e vales no distrito de Leiria em Portugal.
Uma das características encontradas nesta rede é o facto de os
equipamentos utilizados funcionarem com base no sistema
B.
Objetivo dos testes
Os testes tiveram como objetivo verificar o bom
funcionamento e detetar possíveis falhas que existissem. Para
tal dividiram-se os testes em quatro grupos:
 Testes de instalação;
 Testes de configuração;
 Testes de recuperação;
 Testes em cenário real.
C.
Testes de instalação
Os testes de instalação são feitos para observar o tempo
necessário para que os equipamentos estejam devidamente
instalados na rede. Na TABELA 1 temos as três etapas
percorridas pelos dispositivos:
 Arranque do dispositivo, que ilustra o tempo que o
equipamento demora a iniciar;

Obtenção da configuração, que mostra o tempo que
o equipamento demora a obter a sua configuração;
 Equipamento configurado, que indica o tempo
necessário para o dispositivo estrar completamente
configurado e funcional.
TABELA 1 – TEMPOS MÉDIOS NA INSTALAÇÃO
Cliente
Distribuição
Arranque do dispositivo
52 segundos
50 segundos
Nova configuração
104 segundos
120 segundos
Dispositivo instalado
158 segundos
171 segundos
Tendo em conta o tempo necessário para uma configuração
manual de um equipamento deste tipo, os resultados obtidos
durante estes testes comprovam que este sistema agiliza o
processo de instalação de dispositivos na rede.
D.
Testes de configuração
Os testes de configuração são feitos para observar o tempo
necessário para que os equipamentos se reconfigurem com
43
novas configurações disponíveis no servidor. Na TABELA 2
estão presentes as duas etapas percorridas pelos dispositivos:
 Obtenção de nova configuração, que ilustra o tempo
necessário para o equipamento obter a nova
configuração;
 Equipamento configurado, que mostra o tempo
necessário para o dispositivo estar novamente pronto
a funcionar.
TABELA 2 - TEMPOS MÉDIOS NA RECONFIGURAÇÃO
Cliente
Distribuição
Nova configuração
12 segundos
38 segundos
Dispositivo configurado
49 segundos
83 segundos
Sendo que o processo de atualização dos equipamentos numa
rede é moroso, nos resultados obtidos durante estes testes
visualiza-se uma vantagem clara do sistema proposto a
propagar uma atualização de configuração pela rede.
E.
Testes de recuperação
Os testes de recuperação são efetuados para observar quanto
tempo é necessário para os equipamentos se reconfigurarem, a
partir do momento em que o equipamento tem configurações
erradas, ou quando existe um erro na configuração existente
no servidor. Na TABELA 3 estão apresentadas as etapas
percorridas pelos dispositivos:
 Configuração inválida, que mostra o tempo que o
dispositivo demora até se aperceber que existe
algum problema com a sua configuração;
 Arrancar em modo configuração, que ilustra o tempo
que o dispositivo demora até iniciar em modo de
configuração para adquirir novas configurações;
 Obtenção de nova configuração, que indica o tempo
necessário para o dispositivo adquirir as novas
configurações após a falha;
 Equipamento configurado, que mostra o tempo
necessário para o dispositivo voltar a estar
operacional após ter detetado uma falha na
configuração.
TABELA 3 - TEMPOS MÉDIOS NA RECUPERAÇÃO
Cliente
Distribuição
Configuração inválida
25 segundos
26 segundos
Iniciar em modo config.
143 segundos
232 segundos
Nova configuração
160 segundos
262 segundos
209 segundos
295 segundos
F.
Testes em cenário real
Os testes efetuados em cenário real são baseados nos testes
efetuados em laboratório e para tal definiram-se os seguintes:
 Testes de instalação;
 Testes de configuração;
 Testes de recuperação;
 Testes de convergência.
Estes testes, em cenário real, foram executados na rede local
sem fios de larga escala intitulada de Memória Online, mais
precisamente na ramificação Lar, Santa Margarida e
Farraposa. A zona da rede que serve como cenário de testes
real é composta por uma Distribuição Principal, duas
Distribuições Secundária e três Clientes. O servidor de DWCS
encontra-se situado no ponto central da rede, juntamente com
os diversos servidores da mesma.
Os testes de instalação são apresentados na TABELA 4 que
indica o tempo que os equipamentos demoraram até ficarem
operacionais.
TABELA 4 - TESTES DE INSTALAÇÃO EM CENÁRIO REAL
Cliente
Distribuição
163 segundos
175 segundos
Os testes de configuração são apresentados na TABELA 5 e
indica o tempo que os equipamentos demoraram até ficarem
completamente configurados.
TABELA 5 - TESTES DE CONFIGURAÇÃO EM CENÁRIO REAL
Cliente
Distribuição
52 segundos
87 segundos
Os testes de recuperação são apresentados na TABELA 6 e
indica o tempo que os equipamentos demoraram a recuperar
de uma configuração incorreta.
TABELA 6 - TESTES DE RECUPERAÇÃO EM CENÁRIO REAL
Cliente
Distribuição
Dispositivo
215 segundos 302 segundos
configurado
Os testes de convergência foram efetuados parcialmente,
devido a limitações impostas pela administração da rede. De
qualquer das formas os resultados dos testes foram bastante
satisfatórios e muito parecidos aos obtidos em laboratório
como se pode constatar na TABELA 7.
TABELA 7 - TESTES DE CONVERGÊNCIA EM CENÁRIO REAL
Tempo
Os resultados obtidos nesta secção validam o objetivo deste
projeto de proporcionar um sistema munido de ferramentas de
recuperação de erros automatizada, eliminando a necessidade
de intervenções técnicas, que por vezes podem ser demasiado
morosas e dispendiosas.
Distribuição Principal
184 segundos
Distribuição Secundária (1)
397 segundos
Distribuição Secundária (2)
568 segundos
Cliente
649 segundos
Como se pode verificar, mesmo devido ao fato de existir uma
DS adicional neste cenário, os tempos apresentados não
44
sofreram grandes alterações, quando em comparação com os
testes laboratoriais.
G.
Resultados
Através dos resultados obtidos nos testes expostos
anteriormente pode-se concluir que o sistema DWCS fornece
aos administradores de uma rede local sem fios de larga
escala, ferramentas de gestão autónoma de equipamentos. Os
tempos obtidos na configuração, reconfiguração e recuperação
dos dispositivos foram de encontro aos resultados esperados.
V.
CONCLUSÕES E TRABALHO FUTURO
Neste artigo foi proposto um sistema de configuração
dinâmica de equipamentos para redes locais sem fios de larga
escala. Este sistema tem como objetivo automatizar a
configuração de equipamentos, sejam eles de clientes ou da
própria infraestrutura, de uma forma dinâmica e rápida,
tornando a rede inteligente, autónoma e sustentável.
As vantagens que o DWCS traz às redes locais sem fios de
larga escala são, nomeadamente, a redução de custos, tanto a
nível de instalação como de manutenção, o automatismo
facultado à rede e a inteligência proporcionada aos
equipamentos.
Os resultados dos testes efetuados em laboratório, através do
uso de uma réplica do cenário real (Memória Online),
demonstraram a rapidez do sistema e a autonomia do mesmo.
Além disso também foram efetuados testes na rede real e os
resultados foram de encontro aos encontrados em laboratório.
O próximo passo na evolução desta solução, o qual já se
encontra em execução, deverá ser o alargamento do leque de
equipamentos suportados, nomeadamente dispositivos cujo
sistema operativo não seja baseado em OpenWRT.
[8]
J. Strassner. “Autonomic Networking – Theory and Practice”.
IEEE Tutorial. 2004.
[9]
C. Prehofer, C. Bettstetter. “Self-Organization in Communication
Networks: Principles and Paradigms”. IEEE Comunication Magazine.
2005.
[10] N. Agoulmine, S. Balasubramaniam, D. Botvitch, J. Strassner, E.
Lehetihet, W. Donnelly. “Challenges for autonomic network
management”. First Conference on Modelling Autonomic
Communication Environment. 2006,
[11] E. Lehtihet, H.Derbel, N. Agoulmine, Y. Ghamri-Doudane, Sven
van der Meer. “Initial approach toward self-configuration and selfoptimization in IP networks”. Management of multimedia network and
services. 2005.
[12] F.J. Mullany, et al. “Self-Deployment, Self-Configuration: Critical
Future Paradigms for Wireless Access Networks”. WAC 2005. 2004.
[13] K. Zimmerman. “An Autonomic Approach for Self-Organising
Access Points”. Diploma Thesis, University of Ulm – Germany. 2004.
[14] M.H. Fazel Zarandi, P. Ahmadpour. “Fuzzy agent-based expert
system for steel making process”. Expert Systems With Applications
36(5). 2008.
[15] U. Manzoor, K. Ijaz, A. Shahid. “Distributed dependable enterprise
business system – DDEBS”. Proceeding of springer communications in
computer and information science, vol.19. 2008
[16] Sergio Ilarria, Eduardo Menaa, Arantza Illarramendib. “Using
cooperative mobile agents to monitor distributed and dynamic
environments”. Information Sciences, 178. 2007.
[17] J.O. Kephart, W.E. Walsh. “An artificial intelligence perspective in
autonomic computing policies”. Proceedings of POLICY’04. 2004.
[18] D. Gavalas, D. Greenwood, M. Ghanbari, M. O’Mahony.
“Hierarchical network management: A scalable and dynamic mobile
agent-based approach”. Computer Networks, 38(6). 2002.
[19] G. Weiss. “Multiagent systems a modern approach to distributed
artificial intelligence”. The MIT Press Crambridge. 1999.
[20] Wi-Fi Alliance. “Wi-Fi CERTIFIED Wi-Fi Protected Setup”.
2010.
[21] Buffalo Technology. “AirStaion One-Touch Secure System”.
2004.
[22] Wi-Fi Alliance. The State of Wi-Fi Security. 2012.
[23] OpenWRT, [http://openwrt.org], Acedido em Julho de 2013.
AGRADECIMENTOS
Todo o trabalho desenvolvido neste artigo foi parcialmente
suportado pela Rede de Inovação da Região Centro (RICE) e
pelo INOV - INESC Inovação, apoiado pelo Centro de
Investigação em Informática e Comunicações do Instituto
Politécnico de Leiria e pelo projeto Memória Online.
REFERÊNCIAS
[1]
S. Mishra, J. Hwang, D. Filippini, R. Moazzami, L. Subramanian,
T. Du. “Economic analysis of networking technologies for rural
developing regions”. Internet and Network Economics. Springer Berlin
Heidelberg. 2005
[2]
M. Ranga, Mamello Thinyane, Alfredo Terzoli. “Exploring CostEffective Reinforcements for Rural Telecommunication Networks:
Dwesa Case Study”. SATNAC. 2010.
[3]
Rodrigo Selada. “Redes Wireless de Banda Larga”. Universidade
de Trás-os-Montes e Alto Douro. 2008.
[4]
Alex Hills. “Large-Scale Wireless LAN Design”. IEEE
Communications Magazine. 2001.
[5]
S. Surana, R. Patra, E. Brewer. “Simplifying fault diagnosis in
locally managed rural WiFi networks”. Proceedings of the 2007
workshop on Networked systems for developing regios. ACM. 2007.
[6]
Luís Frazão, Silvana Meire, Carlos Rabadão, António Pereira.
“Modelo de Gestão de Rede Wireless de Banda Larga em Ambientes
Rurais”. Sistemas e Tecnologias de Informação – CISTI. 2013.
[7]
International Telecommunication Union. “Future Networks:
Objectives and design goals”. ITU-T Y.3001. 2001.
45
46
Encaminhamento com QoS para Redes Ad Hoc
com rotas estáveis
Tiago Coelho
António Costa
Joaquim Macedo
M. João Nicolau
Centro Algoritmi
Univ. Minho, Portugal
[email protected]
Centro Algoritmi & DI
[email protected]
[email protected]
Centro Algoritmi & DSI
[email protected]
Resumo—Devido às características próprias das redes móveis
ad hoc (Mobile Ad hoc Network - MANET), dotar este tipo de redes
de garantias de qualidade de serviço (QoS) no tráfego fim a fim
torna-se um desafio. Este artigo apresenta um protocolo de
encaminhamento com QoS para redes ad hoc, que se designa por
Ad hoc QoS Multipath Routing with Route Stability (QMRS), que
tem como objectivo suportar aplicações com requisitos de qualidade
de serviço, nomeadamente requisitos no atraso fim a fim. Este
protocolo tem a possibilidade de encontrar até três rotas de nós
disjuntos que cumpram o requisito de QoS. Adicionalmente e com o
objectivo de garantir a estabilidade do processo de
encaminhamento, usa a potência de sinal das ligações entre nós
vizinhos para eleger a rota mais estável, rota essa que passa a ser
usada para o reenvio do tráfego. Quando se verifica a existência de
rotas com uma estabilidade idêntica, dá-se preferência à rota com
menor atraso fim a fim. O protocolo detém também um mecanismo
de manutenção, recuperação e verificação de incumprimento do
requisito de QoS nos caminhos encontrados. Os resultados obtidos
na simulação realizada permitem verificar, que o protocolo QMRS
implementado, reduz o atraso fim a fim e aumenta a taxa de
entrega de pacotes no destino, comparativamente com protocolo Ad
hoc On-Demand Distance Vector (AODV).
Palavras-chave—Ad hoc; QoS; Encaminhamento com QoS;
Encaminhamento Ad hoc
I.
INTRODUÇÃO
As redes móveis ad hoc são compostas por nós móveis que
têm a capacidade de autonomamente, criar uma rede de
comunicações entre eles sem assistência de um ponto de
acesso, contrariamente às redes de infra-estrutura. A
comunicação é sem fios e ocorre directamente entre os nós
vizinhos localizados no mesmo raio de alcance. Os nós da rede
são simultaneamente sistemas terminais e encaminhadores já
que participam no processo de encaminhamento (multi-hop)
para que os pacotes possam ser transmitidos desde a fonte até
ao destino, passando por vários nós intermédios. O aumento da
diversidade e capacidade dos dispositivos móveis sem fios e
simultaneamente a evolução das aplicações multimédia, criou a
necessidade de propor e avaliar formas deste tipo de redes
oferecer garantias de Qualidade de Serviço (QoS) ao tráfego
fim a fim, de forma a cumprir os requisitos de QoS solicitados
por este tipo de aplicações (largura de banda, atraso fim a fim,
variação do atraso, etc). Devido à mobilidade dos nós, a
topologia de rede é dinâmica e imprevisível, ocorrendo
frequentes quebras nas rotas. Além disso, o meio de
comunicações sem fios é partilhado entre os nós vizinhos.
Estes factores levam a que o encaminhamento de tráfego com
requisitos de QoS constitua um desafio ainda maior do que
fazê-lo nas redes fixas.
II.
TRABALHO RELACIONADO
Os protocolos de encaminhamento são normalmente
classificados em duas categorias: proactivos (table-driven) ou
reactivos (on-demand). Os protocolos de encaminhamento
proactivos (p.e. Optimized link state routing protocol – OLSR
[2]) têm como objectivo, manter a informação actualizada das
tabelas de encaminhamento. Estes protocolos têm baixa
latência, mas necessitam de trocar mensagens de controlo
constantemente para actualizar todas as rotas entre os nós
pertencentes à rede, mesmo sem que algum nó pretenda
transmitir. Com a mobilidade dos nós e as limitações ao nível
da energia típica dos dispositivos que utilizam este tipo de
redes, estas características são vistas como possíveis
limitações. Nos protocolos reactivos (p.e. Ad hoc on demand
distance vector – AODV [1]) as rotas são obtidas a pedido do
nó fonte, ou seja, apenas quando um nó pretende transmitir
para determinado destino e não contém uma rota válida na sua
tabela de encaminhamento é que se inicia o processo de
descoberta de rota. Desta forma há menos tráfego de controlo a
transitar na rede, permitindo assim, aos dispositivos que
utilizam a rede, poupar recursos de processamento e
essencialmente
energia.
Entre
os
protocolos
de
encaminhamento reactivos, o protocolo AODV é normalmente
o mais referenciado, no entanto durante o processo de
descoberta de rota apenas permite encontrar uma única rota
para o destino, ou seja, quando ocorre uma quebra de ligação
entre nós pertencentes a essa rota, é necessário iniciar
novamente o processo de descoberta de rotas. Para colmatar
este problema, de forma a diminuir a frequente necessidade de
descobrir novamente uma rota para o destino, foram
implementados alguns protocolos de múltiplos caminhos, por
exemplo o protocolo Ad hoc on-demand multipath distance
vector - AOMDV [3]. No entanto, nesta variante do protocolo
AODV, as diferentes rotas alternativas que são descobertas não
oferecem nenhuma garantia de qualidade de serviço.
Este trabalho é financiado por Fundos FEDER através do Programa
Operacional Fatores de Competitividade – COMPETE e por Fundos
Nacionais através da FCT – Fundação para a Ciência e Tecnologia no âmbito
do Projeto: FCOMP-01-0124-FEDER-022674.
47
Em contrapartida, existem várias propostas de protocolos
de encaminhamento para fornecer garantias de QoS em redes
móveis ad hoc.
Y Hwang and P varshney propõem o protocolo designado
por An Adaptive QoS Routing Protocol with Dispersity for Adhoc Networks (ADQR) [4], que consiste num algoritmo de
descoberta de rotas que permite encontrar vários caminhos
disjuntos. Com base nas informações da largura de banda
obtidas durante a descoberta de rotas este protocolo procede à
reserva de recursos nestes caminhos. A transmissão de dados é
efectuada em todos os caminhos reservados. O protocolo
ADQR monitoriza a rede na tentativa de detectar mudanças na
topologia e com o objectivo de actualizar as rotas antes que as
mesmas fiquem indisponíveis. Com os processos de descoberta
e manutenção de rotas utilizados no protocolo, o ADQR
procura melhorar significativamente o desempenho da rede e
dar suporte de QoS fim a fim em redes ad-hoc. A principal
desvantagem encontrada é o facto de não resolver o problema
da reordenação dos pacotes, inerente ao balanceamento do
tráfego pelos vários caminhos. Além disso, para processar o
pedido de rota, o mecanismo de encaminhamento proposto,
necessita de armazenar em cada nó as informações de estado da
topologia da rede. Por outro lado, a monitorização proactiva
necessária para o seu funcionamento dá origem a uma
sobrecarga de pacotes de controlo na rede, que pode ser
excessiva.
Qi Xue e Aura Ganz propõem o protocolo AQOR [7]. É um
protocolo de encaminhamento com QoS baseado no AODV
com reserva de recursos. O protocolo para fornecer QoS
incorpora as seguintes características: estimativa da largura de
banda disponível e medição do atraso fim-a-fim, reserva da
largura de banda e recuperação de rota. Para não ter que lidar
com a libertação dos recursos reservados em cada nó da rede
quando ocorre uma quebra de ligação, a reserva dos recursos é
efectuada apenas temporariamente. O processo de recuperação
de rota inclui, a detecção de quebra de ligações, verificação de
incumprimento de QoS e recuperação de rota no destino.
Nityananda Sarma e Sukumar Nandi [6] propõem o
protocolo SMQR para redes ad hoc. Este protocolo possibilita
encontrar múltiplas rotas de nós disjuntos com maior
estabilidade. Permite obter rotas que cumpram os requisitos de
atraso fim a fim máximo e taxa de transferência efectiva
mínima, para dar suporte de QoS a aplicações de tempo real
nas redes móveis ad hoc. Segundo os autores, os resultados
obtidos na simulação, indicaram melhorias comparativamente
ao protocolo AODV em termos de taxa de entrega de pacotes,
atraso médio fim-a-fim, variação no atraso máximo e taxa de
transferência efectiva.
pretende desta forma reduzir o atraso fim a fim e atender aos
requisitos de serviço de aplicações multimédia em tempo real.
III.
AD HOC QOS ON-DEMAND MULTIPATH ROUTING WITH
ROUTE STABILITY
Nesta secção, descreve-se o protocolo Ad hoc QoS OnDemand Multipath Routing with Route Stability (QMRS)
proposto. Este protocolo é um protocolo de encaminhamento
reactivo. Inicialmente foi baseado no protocolo AODV, onde
foram implementadas as alterações necessárias para o
modificar de forma a torna-lo um protocolo de
encaminhamento de múltiplos caminhos, tendo-se depois
procedido à implementação final do protocolo proposto, de
forma a atender aos requisitos de QoS sem comprometer a
estabilidade do processo de encaminhamento.
O protocolo QMRS possibilita a descoberta de até três rotas
de nós disjuntos que cumpram o requisito de atraso fim a fim.
Entre as rotas encontradas é seleccionada a rota mais estável
para iniciar a transmissão no nó fonte para o destino, ficando as
restantes como rotas alternativas, desta forma pretende-se
diminuir a possibilidade de uma quebra de rota durante a
transmissão. Apenas no caso de serem encontradas rotas com
uma estabilidade idêntica é seleccionada a rota com menor
atraso fim a fim.
A descoberta de múltiplas rotas de nós disjuntos
alternativas permite que, quando se verifica uma falha na rota
principal devido à movimentação de algum nó pertencente a
esta, o nó fonte reaja à notificação dessa quebra, procedendo à
comutação para uma rota alternativa. A probabilidade de existir
uma rota alternativa válida é elevada graças ao algoritmo
utilizado para a descoberta de rotas. Este algoritmo considera
como rotas alternativas apenas aquelas em que entre a fonte e o
destino não existe um mesmo nó intermédio. Se os caminhos
encontrados fossem de ligações não disjuntas, com a
movimentação de apenas um nó poder-se-iam quebrar logo
todas as rotas alternativas entre a fonte e o destino, tendo o nó
fonte que iniciar novamente o processo de descoberta de rota.
Neste sentido, com a solução proposta, diminui-se o tráfego de
controlo na rede e verifica-se um menor atraso fim a fim,
durante a transmissão do fluxo de dados. A Figura 1 ilustra o
conceito de rotas disjuntas. Com a topologia apresentada,
durante o processo de descoberta de rotas, seria possível obter
três caminhos de nós disjuntos (fonte-A-D-destino; fonte-Bdestino; fonte-C-E-destino), ou seja, o mesmo nó intermédio só
poderá pertencer a um dos caminhos entre a fonte e o destino,
nunca poderá pertencer a outro dos caminhos encontrados e
armazenados na tabela de encaminhamento.
Shun Liu e Jian Liu propõem o protocolo DMSR [8]. É um
protocolo de encaminhamento de múltiplos caminhos, que
utiliza o atraso fim a fim para fornecer suporte de QoS a
aplicações multimédia de tempo real em redes ad hoc. O
protocolo obtém a informação local e realiza o cálculo do
atraso verificado no nó, utilizando-o como métrica para
selecção do caminho. A métrica tem em conta o número de nós
vizinhos dos nós de encaminhamento, o tempo de contenção e
o número de pacotes na fila de espera. O protocolo DMSR
Figura 1 - Caminhos de nós disjuntos
48
Uma vez descobertas as rotas de nós disjuntos entre a fonte
e o destino que cumpram o requisito de QoS, o QMRS utiliza,
a potência de sinal recebido para determinar a rota mais estável
e o atraso fim a fim em caso de empate, para seleccionar a
melhor rota para transmissão. Sobre todos caminhos
encontrados entre o nó fonte e o destino, é realizado o
mecanismo de manutenção de rotas, que verifica
periodicamente se o cumprimento de QoS se mantém, assim
como, efectua uma actualização da potência do sinal mínima
do caminho e do atraso fim a fim. Com base na actualização
das métricas, poderá ocorrer uma comutação de rota. Com os
mecanismos utilizados o protocolo proposto possibilita assim
efectuar uma transmissão de dados eficiente oferecendo
garantias de QoS.
A. Manutenção da informação de estado entre vizinhos
Entre os nós da rede localizados dentro do alcance de
transmissão, ocorrem trocas periódicas de mensagens “Hello”
que indicam que os vizinhos estão disponíveis e acessíveis (no
seu raio de alcance), informação essa que é necessária para o
procedimento de descoberta e manutenção das rotas. Para além
da acessibilidade, através das mensagens “Hello” é mantida a
informação para cada vizinho da potência do sinal recebido e
do atraso ocorrido (desde que o pacote é colocado na fila de
espera do vizinho até que chega ao respectivo nó e que inclui o
tempo gasto na fila de espera, o tempo de contenção no acesso
ao meio, o tempo de transmissão e o tempo de propagação).
Isto é necessário para manter os valores das métricas
actualizadas e dar possibilidade aos nós intermédios de
responder aos pedidos de rota por parte de uma fonte em que o
destino é um dos seus vizinhos. A troca das mensagens de
“Hello” é periódica e no caso de não ser recebida uma
mensagem de um vizinho durante um determinado intervalo de
tempo é desencadeado o processo de recuperação de rota. A
potência do sinal na recepção é obtida directamente na camada
física através de uma interacção cross-layer.
B. Descoberta de Rota
O processo de descoberta de rotas foi implementado com
base no protocolo AODV. Foi necessário efectuar alterações
significativas ao algoritmo e introduzir mecanismos adicionais,
para permitir a descoberta de múltiplos caminhos de nós
disjuntos que cumpram determinado requisito de atraso fim a
fim máximo. Além disso para cada caminho encontrado o
algoritmo do QMRS determina a potência de sinal (métrica
côncava que resulta do cálculo do mínimo valor da potência de
sinal recebido nas várias ligações que constituem o caminho), e
o atraso fim a fim (métrica aditiva que resulta do somatório de
todos os atrasos obtidos nas diferentes ligações e nós que
constituem o caminho).
Um nó da rede quando pretende transmitir para
determinado destino e não contém na sua tabela de
encaminhamento uma rota válida para o mesmo, terá de iniciar
o processo de descoberta de rotas. Este processo consiste no
envio de um pacote Route Request (RREQ) em broadcast para
os nós vizinhos, pacote esse que contém a informação do nó
fonte (Origin Address, sequence number) e a informação do nó
destino (dst Address, dst sequence number). O campo
designado por sequence number diz respeito a um número
inteiro que vai sendo incrementado, para permitir durante a
descoberta de rota verificar se a informação relativa a
determinado nó contida na tabela de encaminhamento está
actualizada ou já está obsoleta, em relação à informação que o
nó que fez o envio do pacote detém sobre esse mesmo nó. Os
campos mencionados, juntamente com o campo resquest ID e o
endereço IP são essenciais para permitir distinguir pedidos
sucessivos e evitar ciclos no encaminhamento. A Tabela I e
Tabela II apresentam a estrutura dos pacotes RREQ e Route
Reply (RREP).
TABELA I - RREQ
RREQ ID
Destination IP Address
Destination Sequence Number
Originator IP Address
Originator Sequence Number
hopCount
firstHop
RxSSPath
delayAcc
delayPath
delayReq
TABELA II - RREP
Destination IP Address
Destination Sequence Number
Originator IP Address
hopCount
firstHop
RxSSPath
RxSSPathToDst
delayPath
delayReq
Os nós vizinhos ao receberem o RREQ, incrementam o
campo do pacote de número de saltos (hopCount) e inserem o
seu endereço IP num campo designado de firstHop, este campo
é utilizado para verificar se o caminho encontrado é de nós
disjuntos. No caso de o nó não conter uma rota para o destino,
retransmite o pacote em broadcast. Desta forma sempre que
um nó recebe o pacote RREQ pela primeira vez (verificado
pelo campo request ID e Origin Address, campos que permitem
identificar unicamente o pacote) e não contém informação de
rota para o destino, retransmite o pacote que é assim difundido
pela rede até chegar ao nó destino, ou então a um nó
intermédio que possua uma rota válida para esse destino. A
rota só é considerada válida, no caso de o nó intermédio conter
na sua tabela de encaminhamento uma rota com um dst
sequence number igual ou superior ao contido na mensagem
RREQ recebida. No caso de ser um nó intermédio a responder
ao pedido do nó fonte, terá de enviar um pacote designado por
gratuitous Route Reply para informar o destino da rota para o
nó fonte.
49
Os nós intermédios ao receberem um pacote RREQ
verificam se o sequence number do nó fonte contido no pacote
é superior ou igual ao da tabela de encaminhamento. No caso
de ser igual, além de ser verificado se o caminho é de nós
disjuntos, também é verificado se o número de rotas contidas
na tabela é inferior a três (o protocolo armazena no máximo até
três caminhos de nós disjuntos). Após serem executadas estas
verificações, é criada ou actualizada a entrada na tabela de
encaminhamento referente à rota para o nó fonte. Após a
retransmissão do pacote RREQ, o nó intermédio fica um
período de tempo à espera de receber uma resposta ao pedido
efectuado, ou seja, espera pela recepção de um pacote Route
Reply (RREP) para validar a rota para o destino. No caso de o
sequence number do nó fonte contido do pacote RREQ ser
superior ao da tabela, as rotas para o nó fonte são removidas, e
é inserida na tabela de encaminhamento a nova rota
encontrada.
entrada da tabela de encaminhamento para o nó destino, e
retransmitem o pacote RREP para o nó fonte. A informação do
atraso fim a fim e da potência do sinal recebido mínima, é
também inserida no caminho encontrado e validado nos nós
intermédios para o nó destino, desta forma se estes nós
receberem algum pedido de rota de outro nó fonte para esse
destino, podem verificar se o atraso fim a fim pode ser
cumprido, assim como informar da estabilidade deste caminho.
Durante a descoberta de rota, é utilizado um mecanismo de
controlo de admissão, sempre que se verifique o não
cumprimento do atraso fim a fim máximo requisitado pela
aplicação (delayReq), ou seja o pacote é descartado, permitindo
encontrar outras rotas que cumpram o requisito de QoS.
D. Manutenção das Rotas
A topologia neste tipo de redes é dinâmica e imprevisível,
com a frequente mobilidade dos nós, podem ocorrer a qualquer
momento quebras nos caminhos encontrados.
Para verificar se o requisito de QoS está a ser cumprido
durante a descoberta de rota, um nó ao receber o pacote RREQ,
calcula o atraso que ocorre no nó e acrescenta-o ao atraso
acumulado até ao momento contido no pacote RREQ
(delayAcc), efectua-se depois a comparação entre o atraso
acumulado e o atraso fim a fim máximo requisitado, em que o
atraso acumulado terá de ser inferior ao atraso requisitado
(delayAcc < delayReq). Sempre que não se verifique esta
condição de controlo, o pacote é descartado.
No caso de o caminho percorrido até ao momento cumprir
o requisito de QoS, são colocados no pacote RREQ a
informação sobre o atraso acumulado (delayAcc) e a potência
do sinal recebido mínima (RxSSPath) do caminho até ao
momento. A potência do sinal é uma métrica côncava, obtida
directamente da camada física, através de uma interacção
cross-layer. O valor obtido da potência do sinal na recepção no
nó (RxSSPath) é comparado com o valor contido no pacote
RREQ, apenas no caso em que o valor lido seja inferior ao
contido no pacote, é que se altera o campo RxSSPath do pacote
RREQ por esse valor lido, caso contrário mantém-se o valor
previamente existente no pacote RREQ da potência do sinal na
recepção mínima do caminho percorrido até ao momento (1).
Com a informação das métricas actualizadas o pacote RREQ é
retransmitido em broadcast, para continuar a procura de uma
rota para o destino.
RREQ.RxSSPath = min(RREQ.RxSSPath,RxSSRead)
(1)
A resposta ao pedido de rota, quer seja feita no nó destino,
ou por um nó intermédio que detém uma rota válida para o
mesmo, a informação contida no pacote RREQ, actualizada nó
a nó durante a sua retransmissão nos nós intermédios no
caminho percorrido, contém no final, a informação do atraso
fim a fim (delayPath) e a potência do sinal recebido mínima
(RxSSPath) do caminho encontrado. Essa informação vai
contida na resposta (pacote RREP) directamente em unicast
para o nó fonte pelo percurso inverso ao percorrido pelo pacote
RREQ recebido. Desta forma, os nós intermédios validam a
50
C. Selecção do caminho
Entre os caminhos encontrados de nós disjuntos que
cumpriram o requisito do atraso fim a fim, com a informação
da estabilidade de cada caminho, baseada na potência do sinal
recebido mínima de cada caminho, é eleita a rota mais estável
para transmissão. Apenas quando é verificada a existência de
caminhos com uma estabilidade idêntica, dá-se preferência ao
caminho com menor atraso fim a fim.
Após a descoberta de rota desencadeada pelo nó fonte,
todos os nós pertencentes a este caminho, armazenam na sua
tabela de encaminhamento a respectiva informação das rotas
para o nó fonte e destino. Quando um nó intermédio
pertencente à rota, verifique que o nó de próximo salto
utilizado para atingir o destino já não se encontra no seu
alcance de transmissão, ou seja, detecta a quebra de ligação
para o nó vizinho, terá de enviar um pacote Route Error
(RERR) de forma a notificar o nó fonte, que aquele nó
utilizado para atingir determinado destino ficou indisponível.
Este pacote percorre os nós intermédios utilizados neste
caminho, que fazem a remoção da entrada da tabela de
encaminhamento para o destino que utiliza como próximo salto
o nó de quem enviou o RERR, e depois retransmite-o para que
este possa chegar ao nó fonte. O nó fonte ao receber o pacote
RERR remove também da sua tabela de encaminhamento a
rota correspondente, e caso esta rota esteja definida como rota
principal, caso existam rotas alternativas, procede à comutação
para a rota alternativa mais estável entre as existentes. Se não
existir nenhuma rota alternativa terá de iniciar o processo de
descoberta de rota. Caso a notificação de quebra de ligação seja
sobre uma rota alternativa, apenas é realizada a remoção dessa
entrada da tabela de encaminhamento, mantendo-se a rota
principal para transmissão.
Nos caminhos encontrados durante o processo de
descoberta de rota, executa-se uma verificação de
incumprimento do requisito de QoS. São utilizados os pacotes
InspectPath e ReplyInpectPath, transmitidos por esses
caminhos, de forma a verificar se o requisito de atraso fim a
fim continua a ser cumprido. O procedimento utilizado para
esta verificação é semelhante à utilizada no processo de
descoberta de rota, em que é verificado se o atraso acumulado é
inferior ao atraso fim a fim requisitado durante a retransmissão
do pacote nó a nó. Quando é verificado que o requisito de QoS
não está a ser cumprido, é enviado um pacote RERR para
notificar o nó fonte que aquele caminho não poderá ser
utilizado, visto que não cumpre o requisito de atraso fim a fim.
Os nós intermédios na recepção do pacote RERR, executam o
procedimento anteriormente descrito na recepção deste tipo de
pacotes, fazem a remoção da entrada na tabela de
encaminhamento para o destino que utilize como próximo salto
o nó que enviou o pacote e retransmitem-no. Durante o
encaminhamento dos pacotes InspectPath nó a nó ao
percorrerem os caminhos encontrados durante a descoberta de
rota, é realizada também a actualização das métricas utilizadas
para seleccionar a rota principal, do atraso fim a fim e a
potência do sinal mínima de cada caminho.
IV.
SIMULAÇÃO E ANÁLISE DE RESULTADOS
Nesta secção, são apresentados os resultados das
simulações realizadas ao protocolo QMRS. Foi utilizado o
simulador NS-3 [9] para implementação e realização dos testes
ao protocolo proposto.
Para a realização dos testes e análise do desempenho ao
protocolo proposto, utilizou-se o protocolo AODV incluído no
simulador, para servir de referência para uma comparação dos
resultados obtidos com os mesmos parâmetros de simulação,
de forma a verificar o desempenho do protocolo em relação ao
atraso fim a fim, taxa de transferência efectiva e a taxa de
pacotes entregues no destino.
A. Simulação
De forma a obter resultados fiáveis, realizaram-se 60
simulações para cada um dos protocolos, sendo apresentados
os resultados nos gráficos seguintes (Figura 2,3 e 4) em que se
indica para cada velocidade, a média e o intervalo de confiança
de 95% correspondente. A simulação efectuada consistiu em
dispor 80 nós de forma aleatória e com uma movimentação
aleatória, utilizando o modelo de mobilidade random waypoint.
Os nós deslocam-se a velocidades máximas entre 0 e 10m/s,
num local com uma dimensão de 600m x 1500m. Todos os nós
da rede têm um alcance de transmissão de 160m. A Tabela III
indica os parâmetros utilizados nas simulações realizadas.
de entrega de pacotes no destino e a taxa de transferência
efectiva.
1) Atraso fim a fim
Relativamente ao atraso médio verificado durante a
transmissão dos fluxos de dados entre a fonte e o destino, podese constatar ao analisar a Figura 2, para as velocidades
máximas entre 0 e 10m/s apresentadas, o protocolo proposto
consegue dar garantias do requisito de atraso fim a fim para os
vários fluxos transmitidos, pode-se observar um atraso fim a
fim médio entre 0 e 250 milissegundos. Enquanto para o
protocolo AODV, verifica-se um atraso médio muito superior
durante a transmissão dos pacotes até ao nó destino. Como
anteriormente descrito, o protocolo AODV não oferece
quaisquer garantias de qualidade de serviço, em que o caminho
usado na transmissão poderá estar congestionado, com o
acréscimo de ter de iniciar o processo de descoberta de rota
sempre que ocorre uma falha numa ligação entre nós
pertencentes à rota usada para transmitir, verifica-se desta
forma nos resultados obtidos apresentados na Figura2 um
atraso significativo nos pacotes até serem entregues no destino.
Enquanto com as garantias que o protocolo QMRS oferece, os
caminhos encontrados e utilizados na transmissão dos dados,
são caminhos pouco congestionados que cumprem o atraso
requisitado, com um número menor de quebra de rotas, uma
recuperação de rota mais rápida e os mecanismos de
manutenção de rotas e verificação de incumprimento de QoS
utilizados, permitem obter um atraso fim a fim
significativamente inferior ao protocolo AODV.
Durante o tempo de simulação de 200s, são transmitidos no
total 15 fluxos de dados, em que são seleccionados
aleatoriamente o nó fonte e o destino. É usado o protocolo
UDP para gerar tráfego Constant Bit Rate (CBR), os pacotes de
dados foram definidos com um tamanho de 64bytes e são
transmitidos a uma taxa de transferência de 2Kbps.
TABELA III - PARÂMETROS DE SIMULAÇÃO
Parâmetros
Dimensão
Número de nós
Modelo de Mobilidade
Posição dos nós
Alcance transmissão
Tipo de tráfego
Tamanho dos pacotes
Número de fluxos
Taxa de transmissão
Valor
600m x 1500m
80
Random Waypoint
Aleatório
160m
Constant Bit Rate (CBR)
64 bytes
15
2Kbps
IEEE 802.11b, freq. 2.4Ghz
Especificações Wifi
Taxa de transf. até 2Mbps
Tempo de simulação (s)
200
B. Análise dos resultados
Para verificar o desempenho dos protocolos, são utilizadas
como meio de comparação as métricas de atraso fim a fim, taxa
Figura 2 - Atraso fim a fim
2) Taxa de Entrega de Pacotes e Taxa de Transferência
Pode-se observar na Figura 3, durante as simulações
realizadas para as diferentes velocidades máximas entre 0 e 10
m/s que a taxa de entrega de pacotes no destino no protocolo
QMRS mantém-se entre os 70% e 80%, verificando-se para o
protocolo AODV taxas de entrega de pacotes muito inferiores,
entre os 10% e 20%.
Relativamente à taxa de transferência efectiva, pode-se
observar na Figura 4 quanto aos resultados obtidos nas
simulações realizadas, que a média da quantidade de dados
transferidos entre a fonte e o destino, para o protocolo QMRS
para as velocidades máximas entre 0 e 10m/s apresentadas,
mantém-se nos 2Kbps, enquanto para o protocolo AODV
verificam-se valores inferiores a 1Kbps.
51
O protocolo proposto, que tem por objectivo garantir a
estabilidade do processo de encaminhamento, na selecção que
faz da rota para transmissão com ligações estáveis entre os nós,
e com o mecanismo de descoberta de rota utilizado, que
verifica o cumprimento do requisito de atraso fim a fim, os nós
que constituírem o caminho durante a transmissão, serão nós da
rede com filas de espera pouco congestionadas. O inverso é
verificado no protocolo AODV, como apenas possibilita a
descoberta de uma rota, não sendo realizada qualquer
verificação durante a sua descoberta ou manutenção, o
caminho utilizado poderá conter ligações de tal forma
congestionadas, que os nós não conseguem ter acesso ao meio
e encaminhar os pacotes todos, ocorrendo congestão nas filas
de espera, que ao atingir a capacidade máxima, grande parte
dos pacotes acabam por ser descartados, originando os
resultados observados na Figura 2 para as diferentes
velocidades máximas entre 0 e 10 m/s, de taxas de entrega no
destino entre 10% e 20%, e na Figura 3 de taxas de
transferência efectiva inferiores a 1Kbps.
rota rápida, que efectua a comutação para uma rota alternativa
sempre que se verifique o incumprimento do requisito de QoS,
ou sempre que é detectada uma quebra no caminho principal. O
protocolo proposto consegue obter, segundo os resultados
apresentados, um desempenho superior comparativamente ao
protocolo AODV e oferecer garantias de QoS.
V.
CONCLUSÃO
O protocolo proposto, Ad hoc QoS Multipath Routing with
Route Stability (QMRS) tenta dar suporte a aplicações com
requisitos de qualidade de serviço nas redes móveis ad hoc,
nomeadamente requisitos no atraso fim a fim.
Este protocolo possibilita encontrar múltiplos caminhos de
nós disjuntos que cumpram o requisito de QoS, durante o
processo de descoberta de rota e durante o mecanismo de
manutenção das rotas, que verifica a estabilidade de cada
caminho, e ao seleccionar para transmissão o caminho mais
estável entre os existentes, permite assim, reduzir o numero de
falhas nas rotas principais usadas para transmissão, e no caso
de se verificar que o caminho principal deixe de ser exequível,
permite efectuar uma rápida recuperação de rota, através da
comutação para um caminho alternativo, não sendo necessário
iniciar novamente o processo de descoberta de rota.
O protocolo QMRS com os mecanismos existentes de
descoberta, manutenção, recuperação de rotas e verificação de
incumprimento do requisito de QoS nos caminhos encontrados,
segundo as simulações realizadas, permitem ao protocolo
proposto, obter resultados com melhorias significativas,
comparativamente ao protocolo Ad hoc On-Demand Distance
Vector (AODV), no que diz respeito ao atraso fim a fim, taxa
de entrega de pacotes no destino e taxa de transferência
efectiva.
Figura 3 - Taxa de entrega de pacotes no destino
REFERÊNCIAS
[1]
[2]
[3]
[4]
[5]
Figura 4 - Taxa de transferência efectiva
[6]
3) Conclusão da Analise dos resultados
O protocolo QMRS, com os mecanismos existentes de
descoberta, manutenção, recuperação de rotas e verificação de
incumprimento do requisito de QoS nos caminhos encontrados.
Permite aumentar a probabilidade de seleccionar rotas para
transmissão que se prolonguem por mais tempo disponíveis.
Com a selecção da rota mais estável e que cumpra o requisito
do atraso fim a fim, o caminho utilizado para transmissão
conterá nós da rede com as suas filas de espera e ligações
menos congestionadas. Com o mecanismo de recuperação de
52
[7]
[8]
[9]
Perkins, Charles, E. Belding-Royer, and Samir Das. "Ad hoc on demand
distance vector (AODV) routing (RFC 3561)." IETF MANET Working
Group (August. 2003) (2003).
Clausen, Thomas, et al. "Optimized link state routing protocol (OLSR)."
(2003).
Marina, Mahesh K., and Samir R. Das. "Ad hoc on-demand multipath
distance vector routing." ACM SIGMOBILE Mobile Computing and
Communications Review 6.3 (2002).
Y Hwang and P varshney, An Adaptive QoS Routing Protocol with
Dispersity for Ad-hoc Networks, proc of the 36th Hawaii International
Conference on System Sciences (HICSS'03), 2003
X. Li and L. Cuthbert, " Multipath QoS routing of supporting Diffserv in
Mobile Ad hoc Networks," Proc. of SNPD/SAWN.'05,2005.
N. Sarma, S. Nandi, "A Route Stability based Multipath QoS Routing
(SMQR) in MANETs," First International Conference on Emerging
Trends in Engineering and Technology, 2008
Qi Xue, Aura Ganz, Ad hoc QoS on-demand routing (AQOR) in mobile
ad hoc networks, Journal of Parallel and Distributed Computing,
Volume 63, Issue 2, February 2003
Liu, Shun, and Jian Liu. "Delay-aware multipath source routing protocol
to
providing
QoS
support
for
wireless
ad
hoc
networks." Communication Technology (ICCT), 2010 12th IEEE
International Conference on. IEEE, 2010.
NS-3, http://www.nsnam.org/
Performance Evaluation of IEEE 802.11
Underwater Wireless Networks
Filipe Teixeira, Rui Campos, Manuel Ricardo
José Quevedo
INESC TEC, Faculdade de Engenharia, Universidade do Porto
Porto, Portugal
Email: {fbt, rcampos, mricardo}@inescporto.pt
Instituto de Telecomunicações
Aveiro, Portugal
Abstract—The use of autonomous vehicles for surveillance and
maintenance of underwater facilities, together with the development of new sensors for underwater monitoring, is bringing up
the need for new, fast, and cheap underwater communications
solutions. Current solutions are based on acoustic communications which, despite their range, offer very low bitrates.
Although Radio Frequency (RF) communications show very high
attenuations in underwater environments, IEEE 802.11 networks
can still be useful in the monitoring, surveillance and maintenance
applications due to the high speed and low cost devices.
This paper evaluates the performance of an IEEE 802.11g
network in fresh water using ns-3. The results show that high
bitrate communications are possible up to 1.4 m. For scenarios
involving point-to-multipoint communications, simulation results
show the need to enable the RTS/CTS mechanism.
I.
I NTRODUCTION
Underwater communications are getting an increasing interest over the past years, not only in research but also for
commercial applications. New autonomous underwater vehicles (AUVs) for surveillance and maintenance of underwater
facilities are being deployed mainly for water quality control
and inspection [1]. Also, new sensors able, for instance, to
monitor the pressure and temperature of a oil pipeline are being
developed [2]. However, these applications require proper
communications solutions to exchange the data collected from
AUVs and sensors to the surface without the energy cost
of going to the surface or the expensive underwater cable
coupling of AUVs.
Current communications solutions are based on acoustic
systems [3], which despite the long range (up to several
kilometers) have many limitations. They provide very low
bitrate, in the order of few kbit/s, thus limiting the capability of
real time video and fast data transmissions [3]. Besides, they
are affected by turbidity and perform poorly in shallow waters
[4]. Moreover, the usage of acoustic waves can have great
impact on marine life [5]. Wireless optical communications can
be a solution for high bitrate communications, but they require
line-of-sight and proper alignment of the nodes, which may not
be possible in some scenarios [3]. Although RF waves suffer
high attenuation underwater, they are unaffected by turbidity,
do not require line-of-sight, are immune to acoustic noise, and
can enable high bitrates for short-range communications [3]
[6] [7] [8] [9] [10].
IEEE 802.11g is a widely used RF communications technology. It operates at 2.4 GHz ISM band and is capable of
creating a Basic Service Set (BSS), which consists of one
Access Point (AP) and one or more stations (STA) connected
via wireless media. The usage of IEEE 802.11 networks in
underwater scenarios can represent a low-cost solution for
short-range high bitrate underwater communications. So, it is
worth it to study such possibilities and scenarios.
The main contributions of this article are two-fold: (1)
a simulation-based performance evaluation of IEEE 802.11g
networks in fresh water scenarios using ns-3 [11] and (2)
a new model for ns-3 specifically developed to cope with
the propagation characteristics of RF waves in fresh water.
The simulation results show the feasibility of IEEE 802.11g
networks for high bitrate communications up to 1.4 m, with
low delay and low packet loss.
The rest of the paper is organized as follows. Section 2
presents the propagation models for underwater communications. Section 3 presents the performance evaluation using ns3 simulator. The simulation results are shown in Section 4.
Finally, conclusions and future work are presented in Section
5.
II.
P ROPAGATION M ODELS
Radio frequency waves propagate differently in the water
and in the air; in the water, RF waves propagate slower.
The propagation speed in underwater scenarios is directly
proportional to the frequency [3] [8] and given by Equation 1.
r
vRF
=
f×
107
m/s
σ
(1)
Where for fresh water the value of the water conductivity
(σ) is 0.01 S/m [12].
However, the propagation speed is limited to the speed of
light in the medium; in water, this is given by the speed of
light in vacuum (c) divided by the refractive coefficient of the
water n (1.33 at 20◦ C. [13]), as shown in Equation 2. The
resulting maximum propagation speed is 2.26 × 108 m/s.
vlightU W
=
c
3.0 × 108
=
= 2.26 × 108 m/s
n
1.33
(2)
Table I compares the propagation speed of RF waves in free
space and in fresh water with the propagation speed of acoustic
53
TABLE I: Propagation speed for RF waves (Free Space, Fresh Water) and Acoustic waves (Fresh Water)
Propagation
Speed (m/s)
Free Space (RF)
Fresh Water (RF)
Acoustic
1 kHz
3.00 × 108
1.00 × 106
1.50 × 103
10 kHz
3.00 × 108
3.16 × 106
1.50 × 103
100 kHz
3.00 × 108
1.00 × 107
1.50 × 103
1 MHz
3.00 × 108
3.16 × 107
1.50 × 103
10 MHz
3.00 × 108
1.00 × 108
1.50 × 103
100 MHz
3.00 × 108
2.26 × 108
1.50 × 103
1 GHz
3.00 × 108
2.26 × 108
1.50 × 103
2.412 GHz
3.00 × 108
2.26 × 108
1.50 × 103
10 GHz
3.00 × 108
2.26 × 108
1.50 × 103
TABLE II: Attenuation of RF waves underwater (Fresh Water)
Frequency
Attenuation (dB/m)
1 kHz
0.05
10 kHz
0.17
100 kHz
0.55
1 MHz
1.73
waves commonly used for underwater communications. The
comparison is performed for frequencies from 1 kHz to 10
GHz. Acoustic waves propagate much slower than RF signals,
even at low frequencies [3]. Lower propagation speed of
acoustic waves causes higher communications delay. For IEEE
802.11g networks, if Channel 1 is considered (2.412 GHz), the
maximum value for the propagation speed (2.26 × 108 ) can be
achieved. This value is in the same order of magnitude of c
(3.00 × 108 ), which should not have significant changes in the
Wi-Fi models for the short distances that can be achieved. This
is valid for every channel of IEEE 802.11g networks.
Signal power attenuation is another significant difference
between over-the-air and underwater communications [6]; underwater communications suffer from higher attenuation. In
fresh water, the attenuation in dB/m is given by Equation 3
[8] [12].
Lf resh
water
=
p
0.0173 f × σ dB/m
100 MHz
17.30
1 GHz
54.71
2.412 GHz
84.96
10 GHz
173
1) AP-STA: Figure 1(a) represents the test scenario with
only one STA, where the distance d between the STA and
the AP is gradually increased until no connectivity exists. The
STA is sending information to the access point. Underwater
and over-the-air (free space) models are tested, considering
distances up to 2 m for underwater and up to 4000 m for
over-the air communications.
2) STA-AP-STA: Figure 1(b) shows a scenario with two
STAs. Two stations are generating at the same time two
different traffic flows to the Access Point. Both over-the-air
(free space) and underwater model are tested, considering
the distances between each STA and the AP defined for the
scenario of Figure 1(a). IEEE 802.11 CSMA/CA is used as the
medium access control mechanism. As the distance between
the STAs and the AP increases, the hidden node problem
(3)
Table II shows the attenuation of RF waves in fresh water
for different frequencies. We can observe from the table that
for IEEE 802.11 Channel 1, the attenuation is 84.96 dB/m.
After adding this value to the free space path loss, which is
around 40 dB if we consider the distance of 1 m at 2.412 GHz,
we end up with a total path loss of almost 125 dB. This shows
the reduced range of underwater RF communications.
III.
10 MHz
5.47
(a) One STA scenario
P ERFORMANCE E VALUATION
We evaluate the performance of IEEE 802.11g communications at 2.4 GHz in fresh water. Ns-3, version 3.17, was used
for simulation purpose. This section presents the scenarios
addressed, the required model changes in the ns-3 and the
performance tests.
A. Scenarios
As a basis for our evaluation scenarios we considered the
802.11 Basic Service Set (BSS), which consists of an access
point (AP) and one or more stations (STA) in its radio range,
using CSMA/CA as the medium access control mechanism. In
our case, we consider two scenarios: 1) BSS formed by one AP
and one STA, in order to test point-to-point communications;
2) BSS formed by one AP and two STAs so that we could
evaluate point-to-multipoint communications. Each scenario is
detailed below and illustrated in Figure 1.
54
(b) Two STA scenario
Fig. 1: Tested Scenarios
may occur, as the distance between STAs is greater than the
carrier sense distance. The hidden node problem may have
significant impact on the network performance due to the
induced collisions. In this work, the carrier sense threshold CcaMode1Threshold of YansWifiPhy model of ns-3 - was kept
with the default level of -99 dBm, 3 dB higher than the -96
dBm of the EnergyDetectionThreshold, which is the minimum
energy for the PHY layer to detect the signal.
B. ns-3 Propagation Models Adaptation
The ns-3 simulator does not include models for RF
underwater communications. Therefore, adaptations to the
current propagation models were performed to include
the lower propagation velocity and higher attenuations
associated with underwater communications. The speed
attribute
of
ns3::ConstantSpeedPropagationDelayModel
was changed to the formula in Equation (1). Also,
the
ns3::FriisPropagationLossModel::SetFrequecy
was
changed in order to reflect the new wavelength for the
lower propagation speed. The attenuation coefficient in
ns3::FriisPropagationLossModel::DoCalcRxPower
was
changed according to Equation (3).
C. Performance tests
The tests aimed at evaluating the performance of underwater IEEE 802.11 communications in terms of throughput,
packet loss ratio, delay and jitter. Measurements were performed for different distances to the gateway in order to infer
the maximum achievable range with a transmission power of
20 dBm and 0 dBi gain antenna both at the transmitter and
receiver nodes. The packet generators in each STA are not
synchronized and follow a Poisson arrival process. Each test is
repeated 10 times with different seeds and the 95% confidence
intervals are calculated using a t-student distribution due to the
small number of degrees of freedom.
1) AP-STA scenario - TCP and UDP Throughput: This
test aims to measure the maximum achievable throughput from
one STA to the AP in underwater and over-the-air scenarios.
The ns-3 BulkSendApplication is the packet generator used
for sending TCP packets. This application was set to send
packets with 1450 bytes each, during 10 seconds, simulating
the transfer of a big file. Once the lower layer buffer is full,
the application waits until space is free to send more data. The
throughput is measured at the AP. The distances considered
are from 0.2 m to 2 m in underwater scenario with 0.1 m
steps, and from 1 to 4000 m in 500 m steps in the over-theair scenario. This test was repeated using UDP packets with
1470 bytes each with the ns-3 OnOffApplication, which sends
a 25 Mbit/s constant bitrate traffic for 10 seconds to infer the
maximum bitrate at the receiver (the off state is not used).
2) AP-STA scenario - Delay, Jitter, and Packet Loss:
The main goal of this test is to evaluate the impact of the
propagation speed difference associated to the underwater RF
communications. Results will be used for a further comparison
with the acoustic wave approach. The average delay and jitter
for each distance of the AP-STA scenario was calculated using
the timestamps of 4000 UDP packets sent from STA to AP.
Since in ns-3 simulator the nodes’ clock are synchronized,
we can use the timestamps of the packets to perform the
calculations. The packet loss was also calculated according
to the number of packets received at the AP.
3) STA-AP-STA scenario - TCP and UDP Throughput: The
test with two stations with TCP is a more demanding scenario.
Now two STAs are competing for the medium with a TCP data
flow. The same BulkSendApplication was used in both STA.
The throughput is measured at the AP for each flow in the same
set of distances as the AP-STA scenario. Tests were repeated
using 1470 byte UDP packets with the OnOffApplication.
IV.
R ESULTS
A. AP-STA scenario - TCP and UDP Throughput
Figure 2(a) shows that the maximum TCP throughput from
STA to AP in underwater scenario exceeds 20 Mbit/s and
is kept almost constant until 1 m. After that, the throughput
decreases very quickly until 1.4 m, where the connection is not
possible anymore. The maximum achieved UDP throughput is
about 25 Mbit/s and follows the same curve of the TCP test,
showing a quick throughput decrease from 1 m to 1.3 m. In the
over-the-air scenario, represented in Figure 2(b) the throughput
is over 20 Mbit/s for TCP traffic and over 24 Mbit/s for UDP
traffic at 1 m and it gradually decreases until 4000 m. The
difference between TCP and UDP throughput can be explained
by the TCP ACK that use the medium and are not accounted
as throughput.
B. AP-STA scenario - Delay, Jitter and Packet Loss
Figure 3(a) and Figure 3(b) show the average delay in
underwater and over-the-air scenarios. We can see that the
delay follow the same shape in both scenarios and is kept
below 1 ms in most cases. Using an acoustic communications
solution, with a propagation delay of 0.67 s/km (inverse of the
propagation speed 1.50 × 103 - see Table I), the expected delay
would be about 1 ms for 1.4 m, showing that for the considered
distances, both solutions provide a low delay communication.
Jitter is kept under 25 ms in both cases, even at the edge of
the coverage, which is acceptable for most applications. Packet
loss is also kept under 0.05% in the tests performed, which is
neglectable.
C. STA-AP-STA scenario - TCP and UDP Throughput
The graph of Figure 2(c) shows that both STAs can
fairly share the medium in the underwater communication
until 1 m, with an average of 6 Mbit/s for each STA and
a confidence interval of around 2 Mbit/s. At a distance of
1 m to the access point, the direct distance between the 2
STA exceeds 1.4 m, which means that the STA are not aware
of each other - the carrier sense threshold is exceeded. The
hidden node problem justifies the sharp decrease in throughput
observed from 0.9 m to 1 m, being the combined throughput
much lower than the observed in the single station scenario.
Therefore, RTS/CTS mechanism should be enabled by default
in underwater scenarios, where the hidden node problem is
more severe due to the higher attenuation. We can also observe
that the TCP window mechanism does not cope well with
underwater scenarios; the results show big confidence intervals.
In the over-the-air scenario shown in the graph of Figure 2(d),
the fairness is kept at all distances. The throughput achieved
55
(a) underwater
(b) over-the-air
(c) underwater
(d) over-the-air
(e) underwater
(f) over-the-air
Fig. 2: Single Station (AP-STA) TCP and UDP throughput tests (a) (b), STA-AP-STA TCP throughput tests (c) (d), STA-AP-STA
UDP throughput tests (e) (f)
56
(a) underwater
(b) over-the-air
Fig. 3: AP-STA delay test
for each STA is identical, starting at 6 Mbit/s for 1 m and
gradually decreasing until 4000 m.
The UDP underwater results of Figure 2(e) show an
average throughput above 10 Mbit/s up to 1 m underwater
and illustrate the hidden node problem after 1 m; the combined
throughput is much lower than in the scenario with one station
only. In the over-the-air scenario, depicted in Figure 2(f), we
can see that the curves follow the curves of the TCP test of
the Figure 2(d), showing that the nodes can fairly share the
medium and no abrupt changes in throughput occur.
V.
C ONCLUSIONS
The current need for sensing and monitoring in underwater scenarios requires more and more underwater devices to
communicate with each other. In this regard, the use of cables
may not be a suitable solution for some scenarios, making the
underwater wireless communications a relevant research topic.
Although current solutions are based mainly on acoustic
waves, RF communications can potentially achieve much
higher throughputs for short distances. In the present work,
ns-3 was used to conduct a performance evaluation of IEEE
802.11g underwater networks in fresh water. Specific ns-3
models were adapted to the propagation characteristics of underwater environments, where the propagation speed is lower
and the attenuation is much higher when compared with overthe-air models. Simulation results show that standard IEEE
802.11g equipment, running at 2.412 GHz, may be able to
communicate up to a distance of 1.4 m in fresh water. The
achieved throughput is suitable for live video transmission
from multiple stations sharing the same medium. However,
the hidden node problem is more severe underwater when
compared with over-the-air scenarios at the test frequencies.
Therefore, RTS/CTS should be enable by default in these kind
of networks.
Based on the obtained results, as a future work we will develop a prototype for conducting experiments in real underwater environments and validate the simulation results presented
herein. We also expect to extend this research to scenarios
considering lower frequencies for higher range. Finally, we
expect to study the changes required at the MAC level to
mitigate the hidden node problem and in this way, reduce the
number of retransmissions and increase the fairness among
connected nodes.
ACKNOWLEDGMENT
This work is part of the project BEST CASE. Project
BEST CASE is co-financed by the North Portugal Regional
Operational Programme (ON.2 O Novo Norte), under the
National Strategic Reference Framework (NSRF), through the
European Regional Development Fund (ERDF).
R EFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
N. A. Cruz, A. C. Matos, R. M. Almeida, and B. M. Ferreira, “Trimares
- a hybrid auv/rov for dam inspection,” in OCEANS 2011, 19-22
September 2011.
S. Mitchell, “A sensor network for non-intrusive and efficient leak
detection in long pipelines,” in Wireless Days, 10-12 October 2011.
X. Che, I. Wells, G. Dickers, P. Kear, and X. Gong, “Re-evaluation of rf
electromagnetic communication in underwater sensor networks,” IEEE
Communications Magazine, vol. 48, no. 12, pp. 143–151, December
2010.
X. Lurton, An Introduction to Underwater Acoustics - Principles and
Applications. Springer, 2010.
W. Au, P. Nachtigall, and J. Pawloski, “Acoustic effects of the atoc
signal (75 hz, 195 db) on dolphins and whales,” Journal of the
Acoustical Society of America, vol. 101, pp. 2973–77, May 1977.
S. Jiang and S. Georgakopoulos, “Electromagnetic wave propagation
into fresh water,” Electromagnetic Analysis and Applications, vol. 3,
pp. 261–266, July 2011.
R. Somaraju and J. Trumpf, “Frequency, temperature and salinity variation of the permttivity of seawater,” IEEE Transactions on Antennas
and Propagation, vol. 54, no. 11, pp. 3441–3448, November 2006.
A. Elrashidi, A. Elleithy, M. Albogame, and K. Elleithy, “Underwater
wireless sensor netowrk communication using electromagnetic waves at
resonance frequency 2.4 ghz,” in 15th Communications and Networking
Simulation Symposium (CNS’12), no. 13, 26-29 March 2012.
57
[9]
S. Sendra, J. Lloret, J. J. P. C. Rodrigues, and J. M. Aguiar, “Underwater
wireless communications in freshwater at 2.4 ghz,” IEEE Communications Letters, vol. 17, no. 9, pp. 1794–1797, September 2013.
[10] J. Lloret, S. Sendra, M. Ardid, and J. J. P. C. Rodrigues, “Underwater
wireless sensor communications in the 2.4 ghz ism frequency band,”
Sensors, vol. 12, no. 4, pp. 4237–4264, March 2012.
[11] “ns-3 discrete-event network simulator, version 3.17.” [Online].
Available: www.nsnam.org
58
[12]
B. Benson, Y. Li, R. Kastner, and B. Faunce, “Design of a lowcost underwater acoustic modem for short-range sensor networks,” in
OCEANS 2010, 24-27 May 2010.
[13] S. Mitchell, Electromagnetic Wave Propagation - Theory and Application to Bathymetric Lidar Simulation. University of Colorado at
Boulder, December 2008.
SILOS - a SImple LOcation Service for Vehicular
Ad-hoc Networks
André Camões
Teresa Vazão
INESC-ID/IST
Email:[email protected]
INESC-ID/IST
Email:[email protected]
Abstract—Given the constant development in Vehicular Networks, this area has gained increasingly maturity, with new
proposals to address the new challenges brought by this type of
networks, in particular questions concerning about routing processes, different vehicular environments and high node mobility
problematic. Associated with this development is the ever growing
commitment by automobile manufacturers to equip their vehicles
with communication units, in addition to the already common
widespread GPS devices. It is of interest, then, to develop efforts
towards the making of networks that take full advantage of the
features present in this vehicular environment. In this work will
be implemented a location service, that takes advantage of the
physical infrastructure on the roads and evaluate its feasability
comparing with another location service, used in tradicional
mobile ad-hoc networks.
Keywords—Vehicular Networks, Location Service, Positionbased Routing, Vehicle Prediction
I.
I NTRODUCTION
The evolution in communication systems lead to an emergent research area - Vehicular Ad-hoc NETworks (VANETs) where the major goal is to improve road safety by extending
the communication range and disseminate relevant information
to remote areas. A VANET may be considered a sub-set of
Mobile Ad-hoc NETworks (MANETs), with specific characteristics associated with node properties, road environment and
vehicle’s dynamics. Such networks also has a very specific
purpose as intended better experience of drivers and passengers
through the provision of vehicle to vehicle communications
(V2V) and vehicle to infrastructure (V2I).
This new area lead to the development of specific applications, leveraging the low cost of wireless technology that
is widespread. Typically these applications aim to increase
road safety and transportation efficiency, as well as to reduce
the impact of transportation on the environment [1]. These
features enable new opportunities that are financially exploited
by investors which see in this area a great source of profit and
profitability of its infrastructure. It is notorious that effort by
consortia which have been created to stimulate the growth of
this area, including the automotive industry, the road operators,
tolling agencies and other service providers [2].
In spite of the broad range of services that might be offered
by VANETs, the specific requirements of the environment
create significant challenges that had been addressed by the
research community. One of these challenges is related with
routing: the difficulties of coping with the network dynamics,
where a wide variable density of nodes, moving at very
different speeds and having different mobility patterns [3]
introduces additional difficulties in the process of finding a
route to a destination or locating a node.
A wide variety of routing protocols have been proposed
either topology or position-based, as surveys in [4], [5].
When comparing both approaches, several performance studies
have shown that position-based routing are more adequate for
VANETs than other solutions [6]. Nevertheless, usually the
comparisons rely on the use of an omniscient location service
[7], hiding the overhead related with the discovery of the
destination node’s location.
Unlike topology-based routing, position-based relies on the
use of a location service to find the position of the destination
node. Different location services have been proposed in the
literature, using basically two main approaches: flooding or
rendezvous based, as surveyed in [8]. These approaches use
different strategies to locate the nodes, but none of them take
into account the context. We claim that a simpler and efficient
location-service can be designed, if the characteristics of the
physical infra-structure is taken into account. In this paper we
propose a new location service, the Simple Location Service
(SILOS), fully aware of the vehicular environment that can
take advantage of this knowledge to offer a better performance.
In order to assess if position-based routing outperforms
topology-based we compare our solution, coupled with the
most well-known position-based protocol, the Greedy Perimeter Stateless Routing (GPSR) with a typical topology-based
protocol.
In the next section, we describe most relevant works that
lead to our proposal. After that, we present our algorithm and
the performance studies that have been realised to assess it. At
the end, we identify future research opportunities and conclude
by summarizing our findings.
II.
S TATE OF THE A RT
A. Location Services
Location Services can be divided into two major approaches: Flooding and Rendezvous-based. The most relevant
proposals of each one of these groups are described next.
1) Flooding-based location service: Flooding-based location services floods the network whenever it is necessary to
find a destination node, using two different operation modes:
proactive and reactive.
In the proactive mode each destination node periodically
floods its location to other nodes in the network, in order to
59
maintain an updated location table in every node. Proactive
location service is used by Distance Routing Effect Algorithm
for Mobility (DREAM) [9]. In DREAM, each node disseminates its position information with a frequency that depends
on its own mobility: nodes moving faster must broadcast their
location information more often, whilst nodes that are stopped
do not exchange such type of information.
In a reactive mode, there is no periodical exchange of
control information, since the location discovery is triggered
upon request, only when the location of the destination node
is unknown. Under this circumstances, the network is flooded
with control messages. The Reactive Location Service (RLS)
[10] is based on this operation mode. When a node does
not have a valid location for a given destination, starts a
discovery process by sending a location request message to its
neighbourhood. A neighbour node may reply with the location
information, if it is available in its location-table, or may
trigger a flooding process, if it does not know the required
position. In order to reach the destination node directly, the
header of the location request message contains the full path
that will be used to send back the reply message.
2) Rendezvous-based location service: in the Rendezvousbased location services, all the nodes (potential senders or
receivers) in the network agree upon a mapping that associates
each node unique identifier to one or more other nodes in the
network. To perform such mapping different strategies might
be used: quorum-based or hierarchical-based.
In the quorum-based approach, each nodes sends the location update message to an explicit defined subset (update
quorum) of available nodes and a location query for that node
is sent to a potentially different subset (query quorum). In [11],
the authors propose a a scalable quorum-based location service
based on a localized approach, where multiple location servers
replicated on several geographical positions to form a quorum.
In quorum, location updates are propagated in south and north
direction until they reach the boundaries of the network and
location queries are propagated in east and west direct until
the network boundaries. The search packet is bound to obtain
the required location from a rendezvous node between a pair
of column and row quorums.
In the hierarchical-based mechanism, location servers are
chosen via a hashing function, either in the node identifier
space or in the location space.
The Grid Location Service (GLS) [12] is built upon a
set of location servers distributed throughout the network,
with information that is kept up-to-date to cope with nodes’
mobility. This network is formed by an hierarchical grid,
with squares of increasing size, represented by orders. The
smaller squares represent order-1 squares. Four order-1 squares
represents one order-2 square, four order-2 squares represent
one order-3 square and so on. Each node as a unique identifier,
randomly selected by applying a strong hash function to the
node’s unique name. A node chooses its location servers by
selecting a set of nodes with IDs close to its own ID. To
start sending data to an unknown destination, a location query
request is sent through the grid according to the orders and the
destination ID, being the answer sent back through the same
way.
The Hierarchical Location Service (HLS) [13] is somehow
60
similar to GLS. The HLS covers the entire area network via
a scheme of hierarchy of regions, where the lowest level is
called cell. For each node, one specific cell of each level of
the hierarchy is selected, by means of an hash function. As
the node changes its position it transmits position updates to
these responsible cells. The same hash function is to identify
the node and determine the cells that may hold information
about its position. The node starting the location discovery
process, proceeds to query the nodes in these cells in the order
of the hierarchy, until it receives a reply containing the current
position of destination node.
3) Comparison and Discussion of the Location Services:
As mentioned in previous sections, existing protocols for
location services fall into two categories: flooding-based and
rendezvous-based. Flooding-based location services offer a
simple location solution, which do not scale well with the
network size, as stated by [14]. When comparing the proactive
and reactive approaches, the first one introduces much overhead with useless information, whilst the second one increases
the latency of the location discovery. Therefore, none of them
seem adequate for VANETs.
The rendezvous-based location services offers also two
type of solutions: quorum-based and hashing-based. From a
comparative viewpoint, authors in [15] argue that the quorumbased protocols are unsuitable for large size VANET, due
to lack of network expandability, caused by the trade-off
between the number of quorums and the robustness of the
location service. Concerning the hierarchical-based approach,
it provides a scalable solution with the network size, but the
drawback here is related with the overhead needed to deal
with mobility and the increasing probability of unsuccessful
location caused by update/lookup failures in highly mobile
environments.
By taking into account the physical environment context,
one can provide a much simpler and yet efficient location
service, where Road-Side Units (RSUs) may be used to convey
queries and replies, increasing the range and the reliability
of the service, while providing low latency to the location
discovery process.
III.
A RCHITECTURE
A. Characterization of Vehicular Network Architecture
The design of a simple location service would benefit if
such service may take into account the properties of the sorrowing environment. Then, the first step is the characterization
of the most important VANET scenarios: highway and urban.
Usually, in an highway environment there is an advanced
communications infrastructure used by tolls and traffic management and surveillance systems. This infrastructure is typically composed of an optical backbone that interconnects
different systems, such as video surveillance cameras, sensors,
emergency warning and toll systems. Remote communication
is usually performed at the entrances and exists, but may
also exist in some intermediate locations. In this scenario,
deploying RSUs is not a major issue, since equipment is
already disposed along the highways [16].
The urban scenario is much more complex, due to the properties of the physical map, environment and mobility patterns.
However, one can easily state that, specially in large cities, fleet
transportation systems are already equipped with interesting
networking facilities, since information of bus schedules is
available, near real-time, at the bus stops. Therefore, enhancing
these systems with adequate RSUs is feasible.
D. Location Service Protocol
At the level of protocol that will sustain the location
service, it mainly consists in three phases: The RegistryEntry
Phase, the PositionQuery Phase and the RemoveEntry Phase.
Regarding the vehicles, manufacturers are increasingly
making efforts to ensure that vehicles have embedded on-board
units (OBU) in order to enable communication among them.
In the meanwhile, such communication may be also performed
through smartphones or tablets.
These RSUs may be integrated into the location service
with advantages. In the simplest scenario, they might be used
to host local location servers, providing location information
to a broad range of vehicles, due to their higher coverage
range. In a more advanced scenario, they can provide context
information, such as indication of speed limit signals, curves
and so on, to improve the accuracy of the movement prediction.
B. Location Service Requirements
The new location service must be designed to support the
following requirements:
•
Simplicity - the location service must be as simple as
possible, in order to allow a fast adaptation to environment dynamics without using a significant amount
of resources or realizing complex operations.
•
Context-aware - the service must take into account
the operational characteristics of the environment,
such as the existence of RSUs that might be used
to extend the coverage area; their relative location
regarding the physical topology properties, such as
the existence of curves, speed bumps, intersections or
other things that might affect the prediction of the
vehicles position.
•
Accuracy - since the position is a key feature for
position-based routing protocols an accurate prediction scheme must be used in order to cope with
the vehicles mobility. Hence, context and historical
information might be used to improve the accuracy of
prediction.
•
Performance - the location service must offers a good
performance, meaning that both overhead and latency
of location discovery must be small.
C. Location Service Overview
The SILOS location service is characterized by the use
of the physical infrastructure present in the vehicular environment, in order to assist in the process of obtaining the vehicles
positions. In this way, vehicles equipped with OBUs are aware
of the presence of a physical communications infrastructure,
which record their positions whenever they are within range
of a RSU. Thus, whenever there is the need to get the position
of a destination node, vehicles can simple obtain it by the
triggering of a location request to the infrastructure, which
will respond with a prediction of the nodes location, based on
the context information delegated by the vehicles. In figure 1
and figure 2, it was presented the operation model of the two
components (OBU and RSU), enlightening their behavior.
Fig. 1.
OBU Operation Model
Fig. 2.
RSU Operation Model
In the RegistryEntry phase, nodes first announce their presence to its neighborhod with GPSR periodic hello messages
with the following fields: Node ID and Position. Whenever a
RSU or a OBU receive one of this GPSR hello messages, it
updates its Position and Location Tables with this information.
If this message has been received by a RSU, additionally a
location hello message is sent, enunciating itself and querying
about vehicles’s speed. When the vehicle receives this message, it will return a location update message inform about
is more updated position and is current speed, as requested.
From this moment, this RSU has full knowledge of the node
and is ready to receive location requests.
The PositionQuery phase will be triggered whenever a
vehicle need to know the location of a destination node. For
that, first it queries the location service module about its
knowledge of the desired position. If it has a valid position,
it is returned, otherwise it is triggered a location query to the
nearest RSU. When the RSU receives this query, two situations
can occur: Or RSU have knowledge about the request position,
or not. If it has the vehicle’s position, a location request is
sent immediately containing a prediction of its position. For
61
that it will use a combination of the last known position of the
vehicle allied to the speed provided in that temporal instant. If
the RSU is unaware about the desired position, it is triggered
a RSU Query, interrogating the other on this information.
The RemoveEntry phase will always take place when
the lifetime of the location table entry expires. In case this
happens, the whole process of obtaining the position of a
destination node is again executed. This is because since there
is a great mobility of the nodes, their positions have to be
continuously updated.
E. Location Service Protocol Example
accelerate until they reach 33 m/s, which matches the high-way
speed limit. This speed is constant across the simulation.
Parameter
Simulator
SimulationTime
Number of Nodes
Node Spacing
Transmission Rate
Transmission OBU Range
Transmission RSU Range
Packet Size
Hello Rate
Location Entry LifeTime
Position Entry LifeTime
Propagation Loss Model
TABLE I.
In order to illustrate the behaviour of the SILOS Protocol,
an application example is presented on figure 3.
Value
NS-3.12
100s
20 nodes
100 m
8192 bps
300m
1000m
512B
1pkt/s
5s
5s
Two Ray Ground + Nakagami
S IMULATION PARAMETERS
B. Evaluation Metrics
In order to evaluate the performance of proposed location
service and assess whether the requirements can be guaranteed,
it was made a comparison between SILOS and RLS according
the establishment of the following evaluation metrics: Location
Overhead (1), Location Accuracy (2) and Time to obtain a
position (3). These metrics are computed as follows:
LocationM essages
LocationM essages+RoutingM essages+DataM essages
LocationOverhead(%) =
(1)
PN LocQueries
LocationAccuracy(m) =
i=1
( CurrentP ositioni −P redictedP ositioni )
T otalLocationQueries
(2)
PN LocQueries
T imeObtainP osition(ms) =
i=1
( T imeLocationQueryi −T imeLocationReplyi )
T otalLocationQueries
(3)
Besides that, it was also performed a general comparison
between a position-based protocol coupled with a location service and topology-based protocols. Packet Delivery Rate (4),
Routing Overhead (5) and Throughput (6) are the metrics that
were used to assess the protocols.These metrics are computed
as follows:
Fig. 3.
Diagram of the SILOS Protocol
T otalN umberP acketsT x
T otalN umberP acketsRx
(4)
T otalM essages−DataM essages
T otalM essages
(5)
N umberP acketsRx∗DataP acketLenght
T otalT imeSimulation
(6)
P acketDeliveryRate(%) =
IV.
T ESTS
A. Test Scenario
RoutingOverhead(%) =
In order to validate the concept proposed by SILOS, it
was implemented a prototype in the NS-3 simulator. For this
purpose, it was extended the GPSR protocol, implemented in
[3], stripping it of the omniscient location service and adding
to it the SILOS. To test the reliability of this location service,
it was set up a test scenario where a client node on the network
send data to a server node via a UDP connection between both.
The parameters of this connection are specified in table 1. In
terms of mobility, a mobility scenario was developed in which
nodes representing the RSUs were placed on specific fixed
coordinates and the cars were programmed according to a Car
Following Model. On this model, all the vehicles depart from
a fixed position, one behind the other, leaving a 100 meter gap
between them. Regarding the speed, cars starts from 0 m/s and
62
T hroughput(kbps) =
C. Results
1) Location Service Overhead: Concerning the location
service overhead required for the location nodes process, two
distinctive behaviours are identifiable between SILOS and
RLS. As can be observed in figure 4, RLS, in a situation
of reduced multi-hop transmission, achieves a low overhead
due to the smaller number of messages exchanged through the
network. For a situation in which the number of hops increases,
this value starts to rise almost exponentially, congesting the
lost during multi-hop forwarding, required for the message to
travel between the transmitter-receiver pair.
In SILOS, this message does not has to travel the nodes
between this pair, but instead, just reach the RSU incumbent
for the service. This RSU will respond directly in single hop
given the range from RSUs antennas, improving the overall
position obtaining time.
Fig. 4.
Location Service Overhead versus Distance
network. This congestion is harmful to the routing information,
lowering the packet’s delivery.
Regarding SILOS, given the procedure of registration and
discovery is always the same, regardless the number of nodes
in the network and the distance between them, there is a
constant overhead rate. This enables higher rates of package
delivery in the most demanding situations, especially when the
destination node is relatively far.
2) Location Accuracy: Regarding the precision of the node
location, figure 5 shows an elevated amount of errors associated with the RLS in relation to SILOS. This happens due
to the way RLS discovers the node’s position, reaching out to
the neighbour nodes when the emitting node does not have the
required position and repeating this same process through out
all the neighbour nodes until the position is known. This modus
operandi makes RLS naturally weaker when the destination
node is further from the emitting node.
The SILOS delegates the discovery process to the infrastructure, benefiting from its global node information. For this
level of precision, the prediction scheme is also fundamental.
Fig. 5.
Fig. 6.
Time to obtain a position versus Distance
4) Packet Delivery Rate: In terms of Packet Delivery Rate,
a more wider comparison between AODV and GPSR coupled
various location services was taken under consideration. As a
result it is possible to analyse the impact that the location
service leads in the subsequent packet routing. Based on
figure 7, the first conclusion that can be taken is the lack of
viability of the topology-based protocols in dynamic multi-hop
scenarios, in contrast with position-based protocols. Another
conclusion that can be taken is the impact that the choice
of location service has in the subsequent routing of packets.
Based on the behaviour of RLS, the higher the distance to
the destination, more broadcast queries are made, making the
whole process of obtaining position very difficult; this clearly
has an impact on the routing process. SILOS coupled with
GPSR is able to provide an acceptable delivery rate, almost
reaching the limit that is provided by GPSR coupled with GOD
Location Service.
Location Accuracy versus Distance
3) Time to obtain position: Figure 6 show us a comparison
about the time it takes to obtain a position, between SILOS
and RLS protocol. Both were tested, with the common routing
protocol GPSR. As can be seen, RLS has a progressive
increase of the time it takes to obtain a position as the
distance increases, while SILOS remains constant regardless
of distance. This progressive increase is explained by the time
Fig. 7.
Packet Delivery Rate vs Distance
5) Routing Overhead: In what concerns the Routing Overhead metrics, it contemplates both routing and location service
overhead. In this way, it is verifiable the real overhead needed
for the position-based protocols operationalization. As can be
observed in figure 8, the GPSR with SILOS coupled overhead
63
values are constant because the routing overhead is the same
regardless of distance. This consists in the periodic Hello
send-outs and the location’s overhead is, almost fully, the
required overhead for the location management. The AODV
protocol’s overhead is much higher given the unawareness of
the destination’s node position. Due to this situation, there
are control packets which circulate the network even if the
destination node is in front or behind itself. This is harmful
to the overhead values and, consequently, to the bandwidth
usage.
The result of these tests concluded that indeed there are real
gains with this infrastructure exploitation and position-based
protocols coupled with a specific location service to vehicular
environment have performances definitely more favorable than
traditional topology-based protocols.
As future work it is intended to evaluate some more
meaningful metrics, to attest the viability of the proposed
location service, such as Location Query Sucess Rate and its
Robustness to high levels of network load. It is also intent to
transpose this service for the urban environment.
ACKNOWLEDGMENT
This work was partially supported by national funds
through FCT Fundação para a Ciência e a Tecnologia, under
project PEst-OE/EEI/LA0021/2013.
R EFERENCES
[1]
[2]
Fig. 8.
[3]
Routing Overhead vs Distance
6) Throughput: Even though the Packet Delivery Rate’s
metrics express in a clear way the level of packet delivery,
it matters to figure out through a bandwidth point of view,
how much the volume of packets transfer per second is. As it
can be seen in figure 9, as the distance increases, the AODV
protocol’s throughput diminishes due to the overhead routing
values but, mostly, to a destination vehicle agnostic forwarding.
The GPSR with SILOS coupled offers a reasonable overhead
value, a more efficient forwarding which contributes to a higher
throughput value.
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
Fig. 9.
Throughput vs Distance
V.
[13]
C ONCLUSION
In this work, it was proceeded the development of a
location service that takes advantage of the communications
infrastructure present in the vehicular environment in order
to achieve an efficient localization of vehicles position and
thus help to increase the performance of routing vehicle.
In order to assess this location service, it was implemented
a prototype in NS-3 simulator and then comparison tests
were performed with the intention of attest its feasibility.
64
[14]
[15]
[16]
Toor, Y.; Muhlethaler, P.; Laouiti, A., ”Vehicle Ad Hoc networks: applications and related technical issues,” Communications Surveys Tutorials,
IEEE , vol.10, no.3, pp.74,88, Third Quarter 2008
Hartenstein, H.; Laberteaux, K.P., ”A tutorial survey on vehicular ad hoc
networks,” Communications Magazine, IEEE , vol.46, no.6, pp.164,171,
June 2008
Fonseca, António and Camões, André and Vazão, Teresa, Geographical
routing implementation in NS3, Proceedings of the Fifth International
Conference on Simulation Tools and Techniques, 2012
Lee Kevin C. and Lee, Uichin and Gerla, Mario, Survey of Routing
Protocols in Vehicular Ad Hoc Networks, 2010
Jagadeesh Kakarla, S Siva Sathya, B Govinda Laxmi, Ramesh Babu B.:
A Survey on Routing Protocols and its issues in VANET, 2011
Fonseca, A., Vazao, T.: Applicability of position-based routing for vanet
in highways and urban environment. Journal of Networks and Computer
Applications (2012)
B. Karp and H. T. Kung. GPSR: Greedy Perimeter Stateless Routing for
Wireless Networks. In Proceedings of the Sixth Annual ACM/IEEE International Conference on Mobile Computing and Networking (Mobicom
2000), Boston, MA, August 2000
Ayaida, Marwane and Fouchal, Hacène and Afilal, Lissan and Ghamridoudane, Yacine, A Comparison of Reactive , Grid and Hierarchical
Location-based Services for VANETs, 2012
Basagni, Stefano and Chlamtac, Imrich and Syrotiuk, Violet R. and
Woodward, Barry A. A Distance Routing Effect Algorithm for Mobility
(DREAM) 1998
M. Kasemann, H. Hartenstein, and M. Mauve, A reactive location
service for mobile ad hoc networks, Department of Computer Science
University of Mannheim Tech Rep TR02014, 2002
Dandan Liu and Stojmenovic, I. and Xiaohua Jia, Mobile Adhoc
and Sensor Systems (MASS), 2006 IEEE International Conference on,
A Scalable Quorum Based Location Service in Ad Hoc and Sensor
Networks, 2006
Li, J., Jannoti, J., De Couto, D.S.J., Karger, D.R., Morris, R.: A scalable
location service for geografic ad hoc routing. Proceedings of the 6th
annual internacional conference on Mobile computing and networking
MobiCom ’00 pp.120-130 (2000)
Kieß, Wolfgang and Fü, Holger and Widmer, Jörg and Mauve, Martin,
Hierarchical location service for mobile ad-hoc networks, SIGMOBILE
Mob. Comput. Commun. Rev., October 2004
Das, Saumiua M and Hu, Y Charlie and Lafayette, West, Performance
Comparison of Scalable Location Services for Geographic Ad Hoc
Routing, 2005
Woo, H., Lee, M.: Vehicle Location Service Scheme using the Vehicle
Trajectory for VANETS ppp.1256-1261(2012)
Jacqueline Jardim, Teresa Vazão, Jorge Lopes: Simulação do uso de redes veiculares em situações de emergência numa auto-estrada Portuguesa,
CRC 2012
Solução Aberta para uma Rede de Sondas de QoS
na RCTS
Pedro Queirós
M. João Nicolau
Alexandre Santos
Centro Algoritmi
[email protected]
Centro Algoritmi & DSI
[email protected]
[email protected]
Resumo—A RCTS tem em operação, desde há vários anos,
um conjunto de sondas do tipo appliance destinadas a aferir de
forma contínua a qualidade da rede, tanto em IPv4 como IPv6.
Normalmente, pelo facto de serem appliances, consequentemente
“fechadas”, cria-se uma dependêndia de hardware e software.
Apesar das appliances possuírem algumas características únicas
ao nível de hardware, podem desenvolver-se soluções abertas
(open source) equiparadas. Na realidade, vários sistemas de aferição de desempenho de redes, desenvolvidos em open source, tanto
na GÉANT (rede académica europeia) como na Internet2 (rede
académica americana), atingiram uma notoriedade que permite
considerá-los como alternativas credíveis para as atuais sondas,
se se provar a sua maturidade e estabilidade. Neste trabalho
apresenta-se o desenvolvimento e teste de uma especificação de
uma nova sonda para a RCTS, baseada em soluções open source.
Index Terms—Sondas de QoS, Sincronização Temporal, One
Way Delay, RCTS
I. I NTRODUÇÃO
O aumento da largura de banda possibilitou o surgimento
de novos serviços, como o video-on-demand, e de uma nova
cultura - always-online - onde o modelo best-effort da Internet
já não se adequa. É necessário agora oferecer aos utilizadores uma experiência de utilização melhorada, que permita a
utilização destes novos serviços na sua plenitude. Para isso,
é também necessário medir constantemente a qualidade de
serviço (em inglês: QoS) da rede.
É do interesse de um fornecedor de serviço de rede ter
conhecimento dos problemas muito antes dos seus clientes
os reportarem, tornando-se vital uma monitorização constante
das ligações, de forma a detetar atempadamente avarias na
rede, bem como conter os estragos que estas possam causar
na mesma. Utilizando técnicas de monitorização do tráfego
na rede, é possível estimar o comportamento da rede, saber se
existem estrangulamentos na mesma, e mesmo detetar ataques
a esta.
II. E STADO DA ARTE
Para efetuar esta monitorização, utilizam-se normalmente
dois métodos de medição do tráfego: medição ativa e medição
passiva.
A. Medição ativa
A medição ativa consiste na introdução de tráfego na rede
que permita a medição fim-a-fim de parâmetros como o atraso,
a perda de pacotes, a variação do atraso entre pacotes sucessivos de dados (jitter), a largura de banda disponível, entre
outros. As medições ativas são feitas recorrendo a software
específico, o qual permite construir pacotes que são transmitidos através da rede e posteriormente permitem a análise e
cálculo de alguns dos parâmetros referidos anteriormente.
Uma destas ferramentas, e provavelmente a mais conhecida,
é a ferramenta ping [1]. Fazendo uso do protocolo ICMP, é
enviada uma mensagem echo request e o echo reply permite
calcular o tempo RTT (Round Trip Time) e também informação
sobre a perda de pacotes. Outra ferramenta que utiliza o
protocolo ICMP é o traceroute [2]. Esta ferramenta permite
determinar o caminho percorrido por uma mensagem na rede
e o tempo de ida e volta para cada salto até ao destino.
Ainda hoje, mais de duas décadas após o seu aparecimento,
estas continuam a ser das ferramentas mais usadas para
diagnosticar falhas de rede. Em 1997 foi criado um grupo
de trabalho na IETF, denominado por IPPM [3], que se
propôs a desenvolver métricas padrão para avaliar a qualidade,
desempenho e confiança dos serviços de transporte de dados
da Internet, em termos quantitativos. Este grupo de trabalho
lançou documentos que especificam métricas e procedimentos
para as determinar, como one-way delay ou one-way loss,
obtidas a partir do OWAMP [4]. Estas medições efetuadas só
num sentido permitem ao operador perceber em que sentido
da ligação é que se encontra um problema, mas necessitam
que os terminais de rede se encontrem sincronizados com alta
precisão, p.ex. através de fontes externas de relógio como o
GPS ou CDMA.
Foram encontradas três ferramentas que implementam o
protocolo OWAMP: OWAMP [5] (tem o mesmo nome do protocolo), desenvolvida pela Internet2, QoSMet [6] (é baseada
num draft do protocolo) e J-OWAMP [7], uma implementação
em Java desenvolvida pelo Instituto de Telecomunicações de
Aveiro. Em [8], os autores desenvolveram uma solução em
hardware que gera informação de sincronização de relógio
extremamente precisa para os pacotes de teste OWAMP, tanto
no emissor como no receptor.
Outras métricas especificadas pelo IPPM dizem respeito
à capacidade de uma ligação (largura de banda disponível quando não existe tráfego), largura de banda disponível
(quando existe tráfego concorrente) e capacidade de transferência em bloco (bulk transfer capacity). Iperf [9], nuttcp
65
[10] e thrulay [11] são algumas das ferramentas que permitem
calcular a largura de banda de uma ligação, usando UDP ou
TCP, bem como outras métricas, tal como o atraso e a perda
de pacotes.
B. Medição passiva
A medição passiva, por sua vez, não interfere com o
tráfego na rede, consistindo apenas na análise do mesmo. O
tráfego é capturado numa localização específica da rede, sendo
armazenado e posteriormente processado, de forma a elaborar
estatísticas sobre o mesmo. Esta análise do tráfego pode ser
feita com vários níveis de granularidade, visto que os pacotes
podem ser capturados ao nível da ligação (camada 2 da pilha
OSI).
A medição passiva pode ainda ser distinguida, conforme
se utilizem métodos baseados em hardware ou software. Os
métodos baseados em software passam, na sua maioria, pela
modificação dos sistemas operativos e drivers dos dispositivos
de rede, de forma a possibilitar a captura do tráfego.
As ferramentas mais referidas na literatura para efetuar a
captura do tráfego e respetiva análise são o tcpdump/libpcap,
tcptrace e Wireshark. Em [12], os autores referem algumas
limitações na utilização deste tipo de soluções em hardware
convencional para analisar tráfego em ligações de alto débito
(10 Gbps ou mais).
Os métodos baseados em hardware são desenhados para
possibilitar a réplica dos dados que atravessam o canal de
transmissão, de forma a duplicar os mesmos, permitindo assim
que o tráfego seja dividido e processado de igual forma pela
interface de rede e pelo hardware específico de monitorização.
As diferenças entre os métodos baseados em software e
hardware refletem-se essencialmente em custo e precisão dos
resultados. Os dispositivos de rede comuns não são desenhados
com a monitorização dos pacotes em mente, pelo que não
manifestam bom desempenho quando é necessário efetuar a
captura dos pacotes.
Foi com esta limitação em mente que os autores em [13]
desenvolveram hardware específico para a captura de tráfego
em redes de alta velocidade. Desde então, as placas de
captura e processamento de tráfego Endace DAG [14] são
hoje usadas em muitos projetos que requerem alta fiabilidade
e sincronismo dos dados, garantindo 100% de captura de
tráfego, mesmo em redes de alto débito (10 Gbps).
No entanto, mesmo utilizando métodos baseados em hardware específico para a captura do tráfego, é necessário garantir
o armazenamento e processamento do tráfego capturado. Se
esta captura for feita em troços de alto débito - 10 Gbps, p.ex.
- a uma velocidade constante, podem obter-se 4.5 Terabytes
de dados em apenas uma hora de captura (10 Gbps ×
3600 segundos ' 4.5 Terabytes). Além do armazenamento,
o processamento desta quantidade de dados também não é
trivial. O processamento pode ser feito em tempo real, se
for crítico, ou mais tarde, permitindo a correlação do tráfego
capturado dentro de uma determinada janela de tempo. Os
autores em [15] sugerem um sistema com uma arquitetura
que distribui as várias fases dos processos de captura e
66
análise do tráfego, executando-as paralelamente em hardware
convencional, tornando-se assim escalável e possibilitando a
captura de tráfego em interfaces de alto débito.
A filtragem de pacotes permite observar apenas uma parte
do tráfego, recorrendo a regras que permitem filtrar o tipo de
tráfego a recolher (p.ex., todos os pacotes TCP), limitando
o tamanho da informação a analisar ao considerar apenas os
primeiros N bytes de dados do pacote, ignorando os restantes.
Um fluxo é uma sequência de pacotes que são trocados
entre duas entidades, identificado recorrendo a uma chave,
formada por alguns campos dos pacotes, como por exemplo o par <IP orig., IP dest.> ou <porta#orig.,
porta#dest.>, ou o <protocolo#> de transporte. Assim, todos os pacotes com uma chave idêntica são considerados como pertencentes ao mesmo fluxo, simplificando a
análise. Neste contexto, a Cisco desenvolvou o NetFlow [16],
que foi a norma de-facto durante muitos anos, antes do IETF
organizar um grupo de trabalho denominado de IPFIX, que
lançou uma norma de igual nomenclatura (IPFIX) [17], definindo como a informação de um fluxo IP deve ser formatada
e transferida. A amostragem dos pacotes passa por recolher
apenas alguns dos pacotes que chegam à interface de captura
- por exemplo, recolher 5 em cada 100 pacotes. Existem
vários métodos de amostragem, tais como aleatório simples,
sistemático e estratificado, que são descritos e comparados em
detalhe com novos métodos de amostragem em [18].
C. Projetos internacionais
Enquanto algumas das ferramentas descritas anteriormente
foram derivadas de projetos de métricas de QoS, outras foram
diretamente utilizadas em alguns projetos internacionais, que
são brevemente referidos de seguida.
Surveyor [19] Este projeto visava a medição do desempenho das ligações de uma WAN, utilizando métricas bem
definidas. Neste projeto foram usadas as métricas de one-way
delay e perda de pacotes para caracterizar as ligações entre
as organizações participantes. Em 1999 este projeto contava
com medições em 41 locais, maioritariamente Universidades
e Centros I&D.
RIPE Network Coordination Centre Test Traffic Measurement [20] Um projeto semelhante ao Surveyor, destinado
a todos aqueles que desejam testar as suas ligações com outros
clientes deste serviço. Disponibiliza um serviço comercial que
é gerido pelo RIPE NCC.
RIPE Network Coordination Centre Atlas [21] Este
trata-se de outro projeto do RIPE NCC, que utiliza sondas
próprias (construídas pelo RIPE NCC) para efetuar medições.
Estas sondas podem ser compradas e instaladas por qualquer
operador, funcionando como um dispositivo plug-and-play. O
objetivo desta rede de sondas é elaborar vários mapas a nível
mundial (latência, conetividade, etc.) para avaliar o estado da
rede que liga as sondas. Depois de devidamente instaladas,
estas sondas fazem vários testes com a rede de sondas ativas
no projeto Atlas (em Agosto de 2012 existiam já 1750 sondas
espalhadas por todo o Mundo): testes de traceroute, DNS,
round trip time, entre outros.
perfSonar [22]
perfSonar é uma arquitetura orientada
aos serviços que permite a monitorização do desempenho das
redes, facilitando a resolução de problemas em ligações fim
a fim que atravessam várias redes. Especifica um conjunto de
serviços e define um protocolo de comunicação entre os vários
serviços, permitindo a qualquer pessoa interessada implementar os mesmos. Esta ferramenta pode ser vista como middleware, permitindo que várias implementações de serviços
diferentes comuniquem entre si, alargando assim o espectro
de medições que podem ser efetuadas entre os utilizadores
desta arquitetura. O perfSonar foi desenvolvido através de uma
colaboração internacional entre a Internet2, ESnet, RNP e a
GÉANT.
PingER [23] Utilizando a ferramenta ping, este projeto
da IEPM visa testar a conetividade das ligações da Internet.
Começando por se focar na comunidade HEP, atualmente
conta com medições para mais de 700 locais em mais de 160
países e disponibiliza os dados das suas medições online.
Etomic [24]
Este projeto pretende, à semelhança de
outros, criar uma infraestrutura de medições ativas capaz de
operar com uma resolução temporal elevada (aproximadamente 10 ns) e globalmente sincronizada. O objetivo destas
medições é fornecer uma visão geral de alta resolução das
rápidas mudanças do tráfego na rede. Entre os participantes
deste projeto encontram-se várias universidades e institutos
de investigação europeus.
Archipelago [25] A CAIDA [26] trata-se de uma colaboração entre organizações comerciais, governamentais e de
investigação, com o objetivo de promover uma maior cooperação no desenvolvimento e manutenção de uma infraestrutura
escalável e robusta para a Internet. Muitas das ferramentas
desenvolvidas em projetos de investigação são depois usadas
em projetos da CAIDA em larga escala. Um desses projetos é
o Archipelago (ou Ark), uma infraestrutura de medições ativas
que pretende reduzir o esforço necessário ao desenvolvimento
e implementação de medições em larga escala.
das appliance QoSMetrics (pré-existentes) usando uma instalação personalizada, com sistema operativo CentOS, de baixa
complexidade e pouco exigente em termos de recursos. Definese depois uma arquitetura genérica, que pode utilizar tanto a
appliance QoSMetrics como hardware genérico, integrando
outras ferramentas Open Source, nomeadamente o perfSonar,
para estabelecer uma rede de sondas e o respetivo sistema de
monitorização de QoS.
A. Enquadramento e Análise de Cenários de Reutilização
Desde 2006 que a FCCN possui um parque de sondas na
RCTS, o qual permite o controlo e medição da qualidade
de serviço que a FCCN oferece aos utilizadores desta rede nomeadamente Universidades, Laboratórios de Investigação e
Institutos Politécnicos. O parque de sondas é constituído por
duas sondas principais, localizadas nos nós centrais da rede
(Lisboa e Porto), de maior capacidade, e por várias sondas
de menor capacidade localizadas nos pontos de interligação
da RCTS com as instituições académicas. No total, 26 sondas espalhadas pelos maiores pólos de Ensino Superior em
Portugal - apresentadas na figura 1 - efetuam medições que
permitem avaliar o estado das ligações da rede [27].
D. Sumário
Apesar de se referirem algumas das ferramentas mais usadas, seria impossível analisar, ou sequer descrever, todas as
ferramentas desenvolvidas para a medição, ativa ou passiva,
de parâmetros de QoS. A CAIDA fornece uma lista extensa,
agrupando as ferramentas conforme a sua função na medição
dos parâmetros. Existe atualmente um vasto leque de opções
para efetuar medições passivas e ativas. A investigação nesta
área é muito rica e produz com frequência novos dados e direções que permitem a evolução das métricas e das ferramentas
utilizadas para as obter.
III. R EDE DE S ONDAS : S OLUÇÕES O PEN S OURCE
Nesta secção apresenta-se a metodologia e resultado dos
testes laboratoriais efetuados para determinar a viabilidade
da utilização de soluções abertas (Open Source) para uma
rede de sondas de QoS na RCTS. Inicialmente, pretendeu-se
aferir a viabilidade operacional de reutilização do hardware
Figura 1: Mapa da distribuição das sondas
O hardware da maioria das sondas é composto por chassi
de rack, tamanho 1U, com processador a 1.6 GHz, 512 MB
RAM. Possui ainda um adaptador de cartões CF para IDE,
produto da QoSMetrics, que utiliza um cartão Compact Flash
de 2 GB como dispositivo de armazenamento primário.
Durante este estudo, foram realizadas com sucesso novas
instalações de software aberto, quer ao nível de SO, quer a
nível aplicacional, nas sondas / appliance QoSMetrics préexistentes. Foi demonstrado que o hardware atualmente à disposição da FCCN poderia ser reutilizado, por forma a instalar
uma nova solução de medição de parâmetros de qualidade
de serviço. Foram no entanto identificadas e documentadas
limitações relacionadas com a utilização de cartões CF (sem
67
suporte para DMA) como dispositivo de armazenamento primário; recomendar-se-ia a inclusão de um disco SSD e ainda
a expansão da memória RAM para o máximo suportado pela
placa mãe, 2 GB.
Como boa caraterística do hardware da appliance convirá
referir a existência de uma boa solução proprietária para a
sincronização temporal. Quando lidamos com medições que
exigem uma precisão ao nível do nanosegundo ou do microsegundo, não podemos ignorar os fatores de atraso presentes
nos métodos de sincronização temporal através de uma rede
de pacotes. É um facto que a sincronização temporal absoluta
sobre uma rede de pacotes é impossível: existem atrasos não
determinísticos que irão sempre influenciar a sincronização.
O importante é estar consciente destas limitações e utilizar
os métodos que melhor se adequam ao nível de exatidão que
pretendemos obter com a sincronização e que são, ao mesmo
tempo, economicamente eficientes.
Uma exatidão fiável na ordem dos microsegundos requer
hardware com um propósito específico, que geralmente inclui
uma relação explícita entre o hardware que produz um evento
e o relógio que gera o carimbo temporal associado a esse
evento.
No levantamento de plataformas de metrologia em rede feito
em [28], os autores analisam os métodos aqui apresentados e
constatam que a maioria das soluções existentes, ou são precisas e eficientes, mas caras e não escaláveis, ou são imprecisas
e com fraco desempenho, mas de fácil implementação. Assim,
concluem, projetar uma infraestrutura para permitir a medição
da qualidade de serviço de uma rede, que seja precisa, pouco
dispendiosa e fácil de implementar, utilizando as soluções
atualmente existentes, permanece um desafio.
Neste contexto, este trabalho pretende explorar uma solução
de arquitetura aberta, tanto a nível de hardware como de
software, capaz de dar resposta satisfatória à rede de sondas
para o sistema de monitorização de QoS da rede académica.
B. Arquitetura para Solução Aberta
Para a definição de uma arquitetura de medição de parâmetros de QoS, consideraram-se duas premisas: a topologia da
rede e a solução atualmente em utilização, ambas referidas em
III-A. As várias instituições servidas pela RCTS encontramse, na sua maioria, ligadas diretamente a dois nós principais:
Lisboa e Porto. Assim sendo, justifica-se a realização de
medições entre os nós principais e a periferia da rede para
avaliar o estado das ligações. Esta é também a filosofia
empregue pela solução atual, onde as sondas periféricas fazem
medições com as sondas de Lisboa e Porto para aferir os
parâmetros de QoS das ligações.
perfSONAR: Monitorização e software aberto
O perfSONAR é uma framework de monitorização desenhada para ambientes de monitorização multi-domínio, que
permite a descoberta, cálculo, armazenamento e distribuição de
métricas de medição de QoS. O seu desenvolvimento surge de
um esforço internacional de cooperação entre várias entidades,
nomeadamente a GÉANT [29], ESnet [30], Internet2 [31] e
68
RNP [32]. O objetivo do perfSONAR é diminuir as restrições
administrativas existentes no acesso aos dados das medições
entre vários domínios, facilitar a resolução de problemas de
desempenho fim-a-fim em caminhos de rede que atravessam
vários domínios, facilitar a gestão de redes e permitir às
aplicações adaptar o seu comportamento ao estado da rede.
O desenvolvimento do perfSONAR é da responsabilidade de
um consórcio de organizações que procura desenvolver um
middleware que seja interoperável entre várias redes e permita
uma análise do desempenho intra e inter redes, e é constituído
por:
• Um protocolo, que assume diferentes tipos de serviços e
define uma sintaxe e semântica padrão através dos quais
eles comunicam, e permite diferentes implementações
de um serviço. Este protocolo é baseado em mensagens
SOAP XML e foi desenvolvido pelo OGF NM-WG [33].
• Várias ferramentas (implementações em software dos
vários serviços), desenvolvidas por diversos parceiros,
que tentam implementar uma framework interoperável de
monitorização de desempenho.
A arquitetura do perfSONAR é apresentada na Figura 2.
Figura 2: Arquitetura de 3 camadas do perfSONAR [22]
Os serviços do perfSONAR podem correr em múltiplos
domínios, usando mensagens SOAP (transportadas em HTTP),
tanto para descrever os dados das medições, como para troca
de informação entre serviços.
1) Componentes: O perfSONAR, de natureza open-source
e com uma arquitetura modular, permite aos administradores
da rede implementar, combinar e personalizar várias ferramentas de acordo com as suas necessidades individuais. Para
facilitar a integração das ferramentas, o perfSONAR oferece
serviços individuais [34], responsáveis por funcionalidades
específicas, como a recolha de dados e a visualização dos
mesmos.
2) Pontos de medição: Os pontos de medição (ou MP)
recolhem e publicam a informação obtida através das ferramentas de medição. As medições são geralmente efetuadas
localmente, a pedido de um cliente, ou automaticamente, com
intervalos programados. É também no ponto de medição que é
feita a conversão entre o formato de dados que a ferramenta de
medição disponibiliza e o formato de dados do perfSONAR.
3) Arquivos de medição: Os arquivos de medição (ou MA)
armazenam o resultado das medições numa base de dados
(SQL, por exemplo) ou num sistema de ficheiros. Estes dados
podem ser lidos pelos clientes, processados ou visualizados.
Os arquivos de medição também suportam a agregação de
dados.
4) Serviços de pesquisa: Cada domínio que implementa o
perfSONAR deve possuir um serviço de pesquisa (ou LS).
Todos os serviços disponibilizados dentro de um domínio
devem ser registados no serviço de pesquisa, permitindo que os
serviços de pesquisa de diferentes domínios possam comunicar
entre si e partilhar informação. Assim, um utilizador apenas
precisa de saber o URL do serviço de pesquisa para saber que
tipo de serviços é disponibilizado por um dado domínio.
5) Ferramentas de visualização: As ferramentas de visualização permitem recolher os dados armazenados nos arquivos
de medição e tratar a informação recolhida para a apresentar ao
utilizador. O carácter open-source destas ferramentas permite
adaptar a apresentação dos dados à necessidade de grupos
específicos de utilizadores.
6) Implementações: Existem atualmente duas implementações principais que se comprometeram a interoperar: perfSONAR MDM [35], desenvolvida pelo GÉANT, e perfSONARPS [36], desenvolvida pela Internet2 e ESnet. Ambas utilizam
o protocolo aberto desenvolvido pelo OGF para trocar dados,
são baseadas em serviços web e partilham os mesmos propósitos: flexibilidade, escalabilidade, abertura e descentralização.
Diferem no processo de desenvolvimento, no ciclo de vida dos
produtos, na interação com os seus utilizadores e no modelo
de implementação e distribuição.
O perfSONAR MDM foi desenvolvido como um sistema de
monitorização multi-domínio, pensado para servir os parceiros
do GÉANT e destinado a fornecer um serviço federado,
centralmente monitorizado e coordenado, com suporte total
do GÉANT. O perfSONAR-PS tem um modelo de suporte
distribuído, com o objetivo de proliferar o número de nós
disponíveis na comunidade.
Ambas as implementações disponibilizam um GUI de configuração e visualização dos resultados das medições baseado
numa interface web. O perfSONAR MDM disponibiliza ainda
um cliente baseado em Java para aceder aos dados das
medições, designado por perfSONAR-UI [37].
De entre os utilizadores conhecidos destas duas implementações1 , destacam-se os membros das redes LHC OPN [38] e
LHC ONE [39].
7) Ferramentas de medição: As implementações do perfSONAR incluem uma gama de ferramentas que permitem
fazer medições e monitorização ao nível da camada IP e
acima, desde ferramentas de medição do atraso e da largura
de banda disponível, até ferramentas que permitem fazer
medições passivas.
8) Medição da taxa de transferência: A medição da taxa
de transferência é feita recorrendo ao BWCTL [40] no caso
do perfSONAR-PS e ao BWCTL MP, um ponto de medição
baseado no BWCTL, no caso do perfSONAR MDM. O
BWCTL é de um encapsulador de ferramentas já conhecidas,
como o iperf, thrulay ou o nuttcp.
1 Existe ainda uma terceira implementação, denominada de perfSONARNC, desenvolvida pela UNINETT,
9) Medição do atraso: As medições do atraso baseiam-se
no HADES [34] para o perfSONAR MDM e no OWAMP para
o perfSONAR-PS. O HADES permite obter informações sobre
o one-way delay [41], delay jitter [42], packet loss rate [43] e
rotas alternativas. O OWAMP é uma ferramenta desenvolvida
pela Internet2, que implementa o protocolo do mesmo nome.
Esta ferramenta é usada para determinar o one-way delay entre
dois pontos da rede.
10) Medições passivas: Ferramentas do perfSONAR baseadas na monitorização passiva da rede foram recentemente
desenvolvidas (PacketLoss) ou encontram-se em desenvolvimento (ABW2) [34]. Alguns parâmetros e características da
rede apenas podem ser obtidos recorrendo a medições passivas,
que não influenciam o tráfego da rede.
IV. S OLUÇÃO A BERTA : T ESTES E R ESULTADOS
Atendendo ao estado de desenvolvimento da implementação, à alargada comunidade de utilizadores, ao feedback
existente por parte da FCCN e à estrutura de suporte, optouse pelo perfSONAR-PS, versão 3.2.2, correndo sobre CentOS
5.8. Esta é portanto uma solução aberta a nível de software
(aplicacional e SO) e foi implementada e testada com sucesso para a implementação de sondas de QoS em hardware
da appliance QoSMetrics, em hardware genérico e também
máquinas virtuais.
A. Métricas de qualidade de serviço
Para avaliar a qualidade de serviço das ligações da RCTS, a
FCCN tem utilizado a solução proprietária da QoSMetrics para
calcular algumas métricas, incluídas também num relatório
mensal disponibilizado às instituições ligadas à RCTS. As
métricas coletadas e que se pretendem continuar a obter são
as seguintes:
• one-way delay mínimo, médio e máximo
• jitter mínimo, médio e máximo
• pacotes enviados, recebidos, perdidos e duplicados
Estas métricas são sempre calculadas de forma independente
para os dois sentidos da ligação. Com a adoção desta nova
solução baseada no perfSONAR, pretendeu determinar-se estas
métricas (tanto em IPv4, como em IPv6) e manter a compatibilidade com o sistema automático de produção de relatórios
que a FCCN tem em operação [27], baseado em Cacti [44]
e HP Openview Service Desk (entretanto descontinuado pela
HP).
B. Estabilidade da referência temporal
Para determinar as métricas referidas em IV-A, o OWAMP,
usado pelo perfSONAR-PS, requer que os pontos entre os
quais são feitas as medições estejam corretamente sincronizados com o NTP. Isto é necessário para assegurar que
os relógios das máquinas envolvidas nas medições estejam
sincronizados, de forma a reduzir o erro dos carimbos temporais atribuídos aos pacotes de medição. Para configurar o
NTP, os autores do OWAMP sugerem que sejam configurados
como referências temporais pelo menos quatro servidores.
Contrariamente, em [45], os autores sugerem que, para manter
69
a estabilidade do NTP, se deve configurar apenas um servidor
(próximo e de baixo stratum) como referência temporal.
Quando se utiliza apenas um servidor como referência, a
variação destes parâmetros torna-se menor, mas em caso de
falha desta única referência, o comportamento do NTP irá
variar drasticamente [45] [46], produzindo carimbos temporais
com flutuações acentuadas que irão interferir nas medições do
one-way delay.
C. Testes e Resultados
A FCCN possui quatro servidores NTP stratum 1, tendo sido
utilizados os do Porto e Lisboa, devido à distância dos mesmos
às sondas de teste, localizadas na UMinho e em Lisboa.
Inicialmente, para facilitar a operacionalização, a sonda da
UMinho foi colocada na rede interna da Universidade.
As medições iniciais, configuradas com os valores por
omissão (enviar 10 pacotes por segundo, de 20 bytes cada),
mostraram valores mínimos próximos daqueles obtidos com
a solução proprietária da QoSMetrics, mas valores máximos
com picos de dezenas e centenas de milisegundos. Mesmo
os valores mínimos continham algumas flutuações, e ocasionalmente alguns picos. Estes resultados eram semelhantes nas
duas direções, e estão demonstrados nas Figuras 3 e 4.
Figura 3: Sonda QoS; valores obtidos para OWD (BragaLisboa) mínimo
Figura 4: Sonda QoS; valores obtidos para OWD (BragaLisboa) máximo
Após análise cuidada e comparação direta com os resultados
das sondas em produção, foi possível detetar algumas das
flutuações nos resultados das medições diretamente correlacionadas com alterações da temperatura ambiente da sonda.
70
As alterações da temperatura ambiente influenciam as propriedades do cristal do relógio presente na máquina, criando
variações na frequência de oscilação, com influência direta
na sincronização NTP e, consequentemente, nas medições do
OWAMP, tal como assinalado na Figura 5.
Figura 5: Influência da temperatura na determinação de OWD
mínimo entre a sonda da UMinho e Lisboa
Alterações no ambiente de testes
No sentido de melhorar a precisão dos resultados, tentando
minimizar a influência de fatores externos, realizaram-se as
seguintes alterações:
• sonda na UMinho: instalou-se um disco SSD e mais 512
Mbytes de RAM;
• a sonda foi realocada no datacenter da UMinho e ligada
diretamente à rede do backbone RCTS.
Com este ambiente de teste, foi possível efetuar testes na
rede RCTS entre Braga e Lisboa, mimetizando, em parte, a
configuração da solução proprietária atualmente existente e em
utilização pela FCCN para medição dos parâmetros de QoS
na rede da RCTS. Os testes de one-way delay foram agora
configurados de forma a que fosse enviado um pacote de 1500
bytes a cada segundo.
Com esta alteração no ambiente de teste, as medições
passaram a apresentar valores mínimos de one-way delay
estáveis, como se pode ver na Figura 6. No entanto, os valores
máximos continuaram a apresentar picos de várias dezenas de
milisegundos, representados na Figura 7. Foi analisada a carga
nas sondas, na rede, e a configuração do NTP, mas não foi
encontrada nenhuma justificação para os picos apresentados.
Após discussão desta ocorrência com o suporte do
perfSONAR-PS, a explicação mais provável para os picos
apresentados nas medições é de que estes são decorrentes dos
atrasos presentes na pilha do software. Em alguns casos, as
variações dos atrasos no processo de receber um pacote, gerar
uma interrupção, e colocar um carimbo temporal, poderão
introduzir falsos atrasos nos pacotes de medição. A carga do
CPU das sondas ronda os 10% (estando idle 90% do tempo).
Foi dada prioridade aos processos do ntpd e do owampd,
através do comando nice, mas tal não produziu diferenças
notáveis nos valores obtidos com as medições, como seria de
esperar dada a carga das máquinas. O tráfego total gerado
pelas sondas ronda os 100 kbps, permitindo concluir que o
Figura 6: Amostra do one-way delay mínimo entre a sonda de
Lisboa e Braga
Figura 7: Amostra do one-way delay máximo entre a sonda
de Lisboa e Braga
processo de monitorização não tem impacto significativo na
operação normal da rede.
O NTP das sondas reporta erros de relógio estimados num
intervalo de 2 a 35 microsegundos, aproximadamente. No
entanto, o próprio NTP estima o one-way delay entre o cliente
e o servidor NTP como sendo metade do RTT. Comparando
com a solução da QoSMetrics, as medições do perfSONAR-PS
apresentam variações entre os 0.2 e os 0.4 milisegundos.
Não se considerou a reconfiguração de hardware com
placas adicionais, nem a inclusão de outros dispositivos de
sincronização externa (como p.ex. GPS) e testaram-se apenas
soluções e protocolos abertos (não se considerou nunca a
hipótese de usar protocolos de sincronização proprietários,
como p.ex. o QTP). Existe portanto espaço para aprofundar
a investigação ao nível dos mecanismos de sincronização de
relógio que utilizem hardware genérico.
Importa referir que os picos apresentados são resultado
de apenas um ou dois pacotes com um atraso visivelmente
superior à média, num total de 60 pacotes em cada sessão de
um minuto. Usando métodos estatísticos, estes outliers podem
ser facilmente descartados.
V. C ONCLUSÃO
Apresentou-se uma arquitetura para a implementação de
uma rede de sondas de QoS baseada apenas em soluções
Open Source, utilizando unicamente hardware genérico, sem
dispositivos (internos ou externos) adicionais. Esta arquitetura
foi implementada e testada sobre a infraestrutura de backbone
da RCTS e os resultados obtidos foram muito satisfatórios.
O perfSONAR mostrou ser uma framework consolidada,
com duas grandes implementações distintas, mas que, essencialmente, têm o mesmo objetivo. No caso específico do
perfSONAR-PS, o suporte oferecido pela comunidade (incluindo programadores e utilizadores) é rápido e eficiente,
sendo possível obter respostas a dúvidas e sugestões de
instalação para casos específicos.
Embora não apresentado neste trabalho, verificou-se ainda
que a possibilidade de aceder à base de dados onde são
guardados os dados de medição do OWAMP permite uma fácil
integração com outras ferramentas (especificamente, foi realizada a integração com a ferramenta de criação de relatórios
RCTS).
A dependência do OWAMP em relação ao NTP também
influencia os resultados das medições, sendo desejável que no
futuro seja possível suportar outros métodos de sincronização
temporal. No caso da utilização do NTP, é necessário proceder
à sua correta configuração (não utilizar a que vem instalada
por definição). Idealmente, o NTP deve ser sempre utilizado
em conjunto com uma referência externa de relógio precisa e
fiável, como um recetor GPS. O preço destes recetores não
é, hoje em dia, muito alto, mas, ainda assim, as questões
logísticas implícitas na instalação destes continuam a ser um
grande entrave à sua utilização.
Seria interessante poder realizar testes com outras configurações de hardware e software, para poder aferir com exatidão
a causa dos picos nos valores máximos do atraso, e comparar
os valores obtidos com diferentes configurações. Infelizmente,
por restrições logísticas e temporais, tal não foi possível.
VI. AGRADECIMENTOS
Este trabalho foi parcialmente financiado por Fundos FEDER, através do Programa Operacional Fatores de Competitividade - COMPETE - e por Fundos Nacionais através da FCT
- Fundação para a Ciência e Tecnologia, através do Projecto:
FCOMP-01-0124-FEDER-022674.
Agradece-se ainda a cooperação da FCCN / FCT na facilitação do acesso à RCTS e aos meios computacionais necessários para a prossecução deste trabalho. Um agradecimento
muito especial a João Nuno Ferreira, Carlos Friaças, Emanuel
Massano e Ana Pinto, todos da FCCN, por toda a ótima
colaboração prestada.
R EFERÊNCIAS
[1] The Story of the PING program. [Online]. Available:
http://ftp.arl.mil/~mike/ping.html (accessed July 2012)
[2] Traceroute for Linux. [Online]. Available: http://
traceroute.sourceforge.net (accessed July 2012)
[3] IP
Performance
Metrics.
[Online].
Available:
http://datatracker.ietf.org/wg/ippm/charter/
(accessed
July 2012)
[4] A One-way Active Measurement Protocol (OWAMP).
[Online]. Available: http://tools.ietf.org/html/rfc4656 (accessed July 2012)
71
[5] An implementation of the One-Way Active Measurement
Protocol. [Online]. Available: http://www.internet2.edu/
performance/owamp/index.html (accessed July 2012)
[6] QoSMet - Quality of Service Metrology. [Online]. Available: http://fabien.michaut.free.fr/qosmet/ (accessed July
2012)
[7] H. Veiga, T. Pinho, J. Oliveira, R. Valadas, P. Salvador, A.
Nogueira, “Active traffic monitoring for heterogeneous
environments”, 4th International Conference on Networking, ICN’05, April 17-21, 2005 - Reunion Island.
[8] Zhang Shu and Katsushi Kobayashi, “HOTS: An
OWAMP-Compliant Hardware Packet Timestamper”,
2005
[9] iperf. [Online]. Available: http://sourceforge.net/projects/
iperf/ (accessed July 2012)
[10] nuttcp. [Online]. Available: http://www.lcp.nrl.navy.mil/
nuttcp/stable/nuttcp.html (accessed July 2012)
[11] thrulay. [Online]. Available: http://sourceforge.net/
projects/thrulay/ (accessed July 2012)
[12] S. Ubik, P. Zejdl, “Passive monitoring of 10Gb/s lines
with pc hardware”, 2008
[13] John Cleary, Stephen Donnelly, Ian Graham, Anthony
McGregor, Murray Pearson, “Design Principles for Accurate Passive Measurement”, 2000
[14] ENDACE
DAG
CARDS.
[Online].
Available:
http://www.endace.com/
endace-dag-high-speed-packet-capture-cards.html
(accessed July 2012)
[15] Se-Hee Han, Myung-Sup Kim, Hong-Taek Ju, James
Won-Ki Hong, “The Architecture of NG-MON: a Passive Network Monitoring System for High-Speed IP
Networks”, 2002
[16] Cisco IOS Flexible NetFlow Technology White Paper.
[Online]. Available: http://www.cisco.com/en/US/prod/
collateral/iosswrel/ps6537/ps6555/ps6601/ps6965/prod_
white_paper0900aecd804be1cc.html (accessed July
2012)
[17] Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of IP Traffic Flow Information.
[Online]. Available: http://tools.ietf.org/html/rfc5101 (accessed July 2012)
[18] Nick Duffield, “Sampling for Passive Internet Measurement: A Review”, 2004
[19] Surveyor. [Online]. Available: http://www.isoc.org/
inet99/proceedings/4h/4h_2.htm#surveyor (accessed July
2012)
[20] RIPE Test Traffic Measurement Service. [Online].
Available:
http://www.ripe.net/data-tools/stats/ttm/
test-traffic-measurement-service (accessed July 2012)
[21] RIPE Atlas [Online]. Available: https://atlas.ripe.net (accessed August 2012)
[22] perfSonar. [Online]. Available: http://www.perfsonar.net
(accessed July 2012)
[23] PingER. [Online]. Available: http://www-iepm.slac.
stanford.edu/pinger/ (accessed July 2012)
[24] Etomic. [Online]. Available: http://www.etomic.org/ (ac-
72
cessed July 2012)
[25] Archipelago Measurement Infrastructure. [Online]. Available: http://www.caida.org/projects/ark/ (accessed July
2012)
[26] CAIDA. [Online]. Available: http://www.caida.org/ (accessed July 2012)
[27] Emanuel Massano, “SONAR - Supervisão da RCTS”,
2008
[28] Anne-Cécile Orgerie, P. Gonçalves, M. Imbert, J. Ridoux,
D. Veitch, “Survey of network metrology platforms”,
2012
[29] GÉANT. [Online]. Available: http://www.geant.net/ (accessed June 2013)
[30] ESnet. [Online]. Available: http://www.es.net/ (accessed
June 2013)
[31] Internet2. [Online]. Available: http://www.internet2.edu/
(accessed June 2013)
[32] RNP. [Online]. Available: http://www.rnp.br/ (accessed
June 2013)
[33] Open Grid Forum’s Network Measurement Working
Group. [Online]. Available: http://nmwg.internet2.edu
[34] D. Vicinanza, “Intercontinental Multi-Domain Monitoring for LHC with perfSONAR”, 2012
[35] perfSONAR Multi Domain Monitoring. [Online]. Available: https://forge.geant.net/forge/display/perfsonar/Home
[36] perfSONAR Perl Services. [Online]. Available: http://
psps.perfsonar.net/ (accessed June 2013)
[37] perfSONAR User Interface. [Online]. Available:
http://www.perfsonar.net/perfsonarUI.html
(accessed
June 2013)
[38] LHC Optical Private Network. [Online]. Available: http:
//lhcopn.web.cern.ch/lhcopn/ (accessed June 2013)
[39] LHC Open Network Environment. [Online]. Available:
http://lhcone.net/ (accessed June 2013)
[40] BWCTL. [Online]. Available: http://www.internet2.edu/
performance/bwctl/ (accessed June 2013)
[41] One-way Delay. [Online]. Available: http://tools.ietf.org/
html/rfc2679 (accessed June 2013)
[42] Jitter Delay. [Online]. Available: http://tools.ietf.org/
html/rfc3393 (accessed June 2013)
[43] Packet loss. [Online]. Available: http://tools.ietf.org/html/
rfc2680 (accessed June 2013)
[44] Cacti. [Online]. Available: http://www.cacti.net/ (accessed June 2013)
[45] Wolfgang John, Sven Tafvelin, Tomas Olovsson, “Passive internet measurement: Overview and guidelines based on experiences”, 2010
[46] OWAMP Details. [Online]. Available: http://www.
internet2.edu/performance/owamp/details.html#NTP (accessed June 2013)
Using Web10G for Service and Network Diversity
Exploitation and Failure Recovery
Filipe Carvalho and José Legatheaux Martins
CITI and DI-FCT, Universidade Nova de Lisboa, Quinta da Torre, 2829-516 Portugal
Emai: [email protected], [email protected]
Abstract—Diversity and redundancy are key properties at
the heart of the Internet performance and reliability. However,
traditional network and transport interfaces prevent upper layers
from directly exploiting them. In order to allow an immediate,
ready-to-use, exploitation of diversity and redundancy, we introduced a way of supporting multi-path and multi-server logical
connections among a client and a service. The proposal is based
on a programming pattern and a run-time support implemented
using the Web10G Linux kernel patch, which allows user level
access to the kernel TCP variables and performance measures
characterizing each TCP connection. The resulting framework
allows applications to explore network and service diversity for
increased performance and fault recovery experiments.
I. I NTRODUCTION
Diversity and redundancy are key properties at the heart
of the Internet performance and reliability. Despite this, in
general, the interfaces of the different layers (e.g., IP, TCP,
HTTP, ...) prevent upper layers from directly exploiting these
properties of the different Internet subsystems.
At the network level, choosing alternate paths could be a
way to get different qualities of service or using different
providers, for example, via client devices with several interfaces and IP addresses, or services connected to different
providers and also accessible via different IP addresses. The
identity / location separation approaches [1] (e.g., LISP[2]),
proposed to enhance the Internet routing and addressing scalability, also call for the use of identity addresses that may be
mapped to different locator IP addresses. Some authors, e.g.,
[3], proposed the generalization of the visibility of addressing
alternatives to enhance diversity access.
At the transport level, multiple local interfaces and remote
IP addresses are already being considered: Multi-Path TCP
[4] is a new version of the traditional TCP protocol that
leverages the simultaneous usage of different IP addresses for
performance enhancement, and SCTP [5], [6] is a transport
protocol that also supports the usage of several interfaces and
remote IP addresses to support multi-homing and roaming.
At higher layers, most critical or popular applications (e.g.,
DNS, content-distribution, mass communication and collaboration, social networks, . . . ) are implemented using service
replication. Many of these systems use automatic redirection
of a client to the closest (or preferred) replica. In general, this
redirection only takes place at service connection time, using
modified DNS servers or HTTP redirections.
Traditional solutions to support diversity and redundancy
are based on control planes completely under control of
providers, fully opaque to end-systems: routing control planes
and content-distribution networks subsystems used to loadbalance clients. Nevertheless, there are also many success
stories were end-systems take control of a significant part of
the control plane. The most successful one is the congestion
control system of the Internet, mostly based on the endsystems implementation of TCP which dynamically adapts the
emission rate to the status of the network. Other prominent
examples are the P2P content distribution systems and more
recently the distribution of video content by the so-called
Dynamic Adaptive Streaming over HTTP (DASH) [7], [8].
We think that there is some room for more experiments
allowing applications to explore network and service diversity
for increased performance and fault recovery. For this purpose,
and by hypothesis, we consider that network and service
alternatives may be accessible using different IP addresses
(local and remote). Also, instead of considering new transport
protocols, we want to experiment and assess the alternative
of only using old ones, namely TCP. Finally, we do not want
application code to deal with the complexities of having to
directly deal with fault detection and network performance
comparisons. Since TCP philosophy and implementation rely
on an considerable set of performance statistics, we want
to base these experiments in those pre-existing performance
indicators.
To this end, we propose a way of exploring multi-path or
multi-server TCP-based logical connections among a client
and a server, or a service, via an application-level programming framework, to ease network and service diversity exploitation and fault recovery. This functionality is made available through a Java object that supports a logical connection
among a client and a server or a service. This object, we dub
NChannelSocket, can exploit alternative pairs of IP addresses
to connect a client to a server or a service. Used in conjunction
with an easy to understand programming pattern, it facilitates
the development of client / server TCP interactions exploiting
path diversity between a client and a server, or among a client
and several different but idempotent-equivalent servers.
The goal is to provide a reasonable general-purpose programming pattern and a supporting framework that can be
integrated in client / server applications to leverage interface,
network and service diversity. In what concerns performance
73
evaluation and comparison, it relies on parameter estimation
that TCP already performs at kernel level. These kernel
statistics are ready available in Linux through the Web10G
Linux kernel patch [9] and may be easily made available in
other operating systems in the future.
In the next two sections we present the proposal and its
implementation. A certain number of experiments and the
analysis of their results are the object of section IV. Related
work is discussed in section V. A discussion of the proposal
and future work are both treated in section VI. The paper ends
by presenting some preliminary conclusions of this experiment
in section VII.
II. P ROGRAMMING PATTERN AND RUN T IME S UPPORT
The goal of this work is to develop and evaluate a programming pattern [10] and a monitoring runtime support, both
geared towards building distributed request / reply applications
that explore network and service diversity. As already stated,
diversity must be available by means of several (local and
remote) IP addresses and we also want to leverage TCP
statistics already being collected by the kernel.
The proposal is built around a kind of logical client /
server connection, mainly equivalent to a new type of socket,
called NChannelSocket. At initialization, this object receives
several local and remote IP addresses, and establishes a TCP
connection among the client and a server using one pair of the
available addresses.1 Each different remote IP address should
represent the same server or a server representing the same
replicated service. When several servers are used, it is assumed
that the service has an interface based on idempotent operations and that the different servers are semantically equivalent.
This property is inherent to many services interfaces supported
atop of HTTP, a popular solution these days.
During the client / server interaction, if the current TCP
connection fails, or a more performant one seems to be
available, an alternative TCP connection can be used. Thus,
a NChannelSocket represents a logical multi-path connection
to a server or a logical multi-path connection to a set of
semantically equivalent servers representing the same service.
Typical applications of the proposed mechanisms are long
client / server interactions, built around a TCP-based request /
reply mechanism, to transfer, in several interactions, medium
to large volumes of data (e.g., a large file, a stream or a list
of related files). The code sketch below is an example of the
utilization of the proposed mechanism.
NChannelSocket ncs = new NChannelSocket(IP addresses, port, ... );
do {
try {
Socket s = ncs.getCurrentSocket();
// one or more request / reply interactions
writeRequest ( s, request ) ;
reply = readReply ( s ) ;
processReply ( reply ) ;
if( ! ncs.bestSocketBeingUsed() ) {
ncs.swithConnection() ;
}
1 In fact each connection is characterized also by the ports it uses, however
we omit that each IP address has a port associated and, for simplicity, consider
the TCP connection only characterized by the local and remote IP addresses.
74
}
catch(Network or Server Exception e) {
ncs.swithConnection(); }
} while( ! done );
The programming style subjacent to the programming pattern corresponds to a series of requests / replies, at the end
of each one the client has the choice to follow, or not,
a possible connection switching recommendation. See the
example in the listing above. To begin with, a NChannelSocket
is instantiated. Then a loop performs a series of request / reply
transactions each using the currently available connection. At
the end of each transaction (or several of them) a call to
method bestSocketBeingUsed() (optionally) asks if a better
connection seems to be available and if it is the case, a call to
the switchConnection() method asks the switch to that better
connection. An exception also forces switching the connection
(the exception catch and treatment). For the sake of simplicity
we do not show the treatment of all other exceptions the object
NChannelSocket can rise (e.g., no connections available) or
other completion conditions.
The NChannelSocket supporting runtime includes mechanisms to compute the past performance of the TCP connections
made (we called it ”history”) as well as the performance
of the connection currently in use, and also to probe the
other available alternatives. Based on these statistics, a recommendation is made available to the application when the
bestSocketBeingUsed() method is called.2 The initialization
phase as well as the swithConnection() method also relies on
these statistics to automatically choose and open an alternative
connection.
Connection switching is always controlled by the application programmer since it only takes place when it explicitly
asks the switch. Therefore, the application programmer has
full control over when a potential change of the used server
can take place. This may be important for the application and
its application logic. Naturally, the application designer also
has to define what is a transaction between the client and the
service. In most situations where a NChannelSocket presents
a suitable solution, the transaction is equivalent to a get of a
block or a chunk (of a file, or a stream, . . . ). The size of that
block, or set of blocks, must be chosen since it may impact
the performance as well as the periodicity with which the
method bestSocketBeingUsed() is called. In general, between
each two calls of the method the connection in use should have
the opportunity to attain a steady state (the implementation
refrains from recommending a too early switch). Moreover,
for short interactions with a server, it may be unreasonable to
switch the connection since this introduces at least one extra
round-trip time.
In what concerns communications fault recovery, as we will
discuss in section IV, the time taken to recover from a broken
connection is dependent of the value of the timeout used to
limit the time taken to read or write using the current socket.
As we rely on TCP, this timeout value can also be controlled
2 In case of a positive switching recommendation, the method also informs
the caller of the nature of the recommendation, see the next section.
and set by the programmer using the TCP sockets provided
methods.
III. I MPLEMENTATION
We implemented the NChannelSocket abstraction as a Java
object encapsulating the runtime framework interface. It relies
on a kernel patch (Web10g [9], version 3.0, configured on a
Linux system with kernel version 3.0.16) that allows access
to kernel-level TCP performance statistics, normally hidden
from end users, through a kernel Java Native Interface (JNI)
that we also developed. These statistics include Round Trip
Time (RTT), Retransmission Timeout (RTO), packets received
/ sent / lost, transfer performance figures, time passed since
the connection started and many other attributes.
As previously discussed, we provide support for connection
switching from a worst or broken connection to a more
viable one. To support this switching we rely on: performance
collection, probing and exceptions.
Performance collection is continuously performed using the
Web10g interface. In every 250 ms the JNI method is called
and a new set of measurements is taken out from the kernel.
We maintain three working sets of collected data at any given
moment. Last set, which represents the last measurements
taken; Recent set, which is the aggregated values of the
last ten measurements collected; Past set, which represents
the updated history of all connections made between any pair
of addresses. The later set is saved to a file every 5 seconds
(i.e., every 20 samples since 250ms * 20 = 5 seconds). If the
values collected are not mean values (e.g., congestion window
size) the Recent and Past sets are always updated to show
the most recent mean values. If the values are mean values
by themselves (e.g., SmothedRTT) the Recent set displays the
latest values (they are already a mean for this connection), but
in the Past set the values are saved with a weighted mean (e.g.,
this connection RTT has less weight than all the past RTTs
made with this pair of addresses).
Probing is done periodically by opening, without any data
transfer, the alternative connections and measuring the RTT of
the probed path / server. If another better connection seems to
be available (based of the measured RTT), that will be reported
when a call to bestSocketBeingUsed() runtime method is made.
Exceptions rise up to the application when a critical error
occurs within the connection, either by a timeout or by a link
failure. In this case the use of a new pair of addresses is
mandatory and a new connection should be started.
Another alternative to switch a connection is when its
performance has decayed significantly in correspondence to
its past, e.g., an increase in packet loss or a suddenly decrease
in throughput.
All the switching logic is intertwined in the method bestSocketBeingUsed() that, at each call, checks if the connection
is working properly (no loss in performance) and, if not, uses
the information from the probing to make a recommendation.
Even if the current connection seems to continue to behave
properly, inspired from popular P2P systems, we have also
implemented a pseudo-random decision method that risks
changing connections with low probability if we cannot infer
for sure if there is a better path, or with higher probability, if
it clearly seems that better alternatives are available. The core
of the bestSocketBeingUsed() method logic is the following:
if (tooRecentlyInvoked() || ! grownUpConnection(currentConn)
|| ! availableAlternatives(currentConn)) {
return 0; // do not switch recommendation
}
if (senderDependent(currentConn)
&& isWindowInRecoveryState(currentConn)) {
if (highSenderPacketLoss(currentConn,pastCon)
|| receiverThroughputDecayed(currentConn,pastConn)) {
return 1; // recommend switch type 1
}
}
if ( receiverDependent(currentConn)
&& senderThroughputDecayed(currentConn,pastConn)) {
}
if (isThereABetterPath(currentConn))
switchProb = HIGHPROB;
else switchProb = SMALLPROB;
double random = Math.random();
if(random < switchProb){
}
// otherwise, do not switch recommendation
return 0;
The currentConn and pastConn parameters represent the
current connection in use and it’s past in the Past set, respectively. The method returns a “no change” suggestion if it has
been called recently, the current connection is not grown up
(i.e., has, in the current implementation, less then 100 RTTs
or less then 5 seconds) or there are no available alternatives.
If the client is sending more data than receiving (thus the
connection is sender dependent), we check if the congestion
window is in the recovery state, i.e. if the size is equal
or less then 2 ∗ MSS (Maximum Segment Size), and if the
sender packet loss (i.e., the client packet loss) or the receiver
throughput (i.e., the throughput from the other side of the
connection) has recently decayed. Otherwise, if the client
is receiving more data than sending (thus the connection
is receiver dependent), we check if the sender throughput
(i.e., the throughput from the other side of the connection)
has recently decayed. Both return types 1 and 2 signals the
application that the performance has decreased. Return type 3
is used to signal the application to take a risk, with higher or
lower probability, as explained before.
When the method switchConnection() is called, the best
alternative is selected using Smoothed RTT as the main criterion if past performance is unknown. After the creation of a
NChannelSocket, the first connection is chosen randomly or,
if history data is available, based on the past performance.
In summary, NChannelSockets provide: connection initialization; connection history collection where the past performance of all TCP connections made are saved in a file; probing
of connections; choice of initial pair of addresses, through
connection history if available, or randomly choosing one pair
of the available addresses to start with; and choice of posterior
pairs of addresses when the current connection compares unfavorably, or if it broke. Together, these functionalities are used
75
TABLE II
JAVA S OCKET, NChannelSocket AND WGet TRANSFERS COMPARISON IN
SECONDS .
TABLE I
C HARACTERISTICS OF THE LINKS USED IN THE FIRST TEST SCENARIO .
Link
Capacity
RTT
Packet loss
Worst-path
Middle-path
Best-path
700 Kbps
900 Kbps
1000 Kbps
15 ms
15 ms
5 ms
1%
1%
1%
Mean
Java Socket
NChannelSocket
WGet
165.59 ± 0.42
165.83 ± 0.62
165.30 ± 0.82
TABLE III
O NE PATH NChannelSocket TRANSFERS COMPARISON IN SECONDS .
to test and recommend the switching between connections to
maintain the transfer active and as performant as possible.
Mean
Worst-path
Middle-path
Best-path
245.41 ± 2.40
195.47 ± 3.36
165.84 ± 0.63
IV. E VALUATION
To evaluate the proposal we developed an application that
downloads a file, via a sequence of block transfers using
HTTP Partial Requests and uses the programming pattern and
framework presented above.
Fig. 1.
First test scenario
The first test scenario was configured as follows: a client
with one local address and three remote servers with three
different addresses (three virtual machines in one server rack)
but replicating the same 20 M Byte object. Client and servers
are connected to the same switch as shown in Figure 1.
With the help of Dummynet [11] we simulated three different paths to the servers (see Table I). The three paths had no
significant performance differences since we intended to test
the ability of the framework to compare their characteristics
and elect the best one.
Due to the emulated link capacities chosen, the test scenario
is not fully representative of the variations in path performance
in the real Internet. This was done to make the test scenario
simple. The links that we emulated have characteristics that
are no longer common place in the Internet given that, for
example, higher throughputs are becoming a more common
scenario in home broadband access settings. Our choice rests
on the fact that we wanted to emulate a long file transfer,
and instead of using files with large sizes, again because of
the time resources available, we opted for a smaller file, with
slower transfer rates.
Control tests were used to devise how the different parameters influenced the switching recommendation mechanism and
the total transfer time. For example, we adopted a block size
of 512 K Bytes, since increasing it does not decreased the total
transfer time, while when decreasing it, performance suffered.
With the best-path, this block is transferred in 4 seconds, what
76
corresponds to a not very tight control of the performance but
allows better TCP performance estimation. We will return to
this point below. We also concluded that using the pattern
with one only available path corresponds to almost the same
performance we could get with a traditional Java Socket or
even while using an optimized Linux utility like wget (allways
using the same path), as can be seen in Table II. Thus, with
this block size, the pattern and the framework do not penalize
a file transfer in the case where no alternatives are available.
We also computed the time needed to transfer the file over
each of the available paths, i.e., when one only path was
available to the NChannelSocket, see Table III.
Control tests, as well as all tests presented below were
repeated 20 times, giving us a good mean and standard
deviation values to support our conclusions. All the tests
presented from now on were done using simultaneously all
the three paths.
In test 1 no previous history was available, while test 2 was
made taking in consideration the measured past performance
of the paths. These tests were useful to see if our framework
starting from a random path eventually changes to the fastest
available one (in test 1), or if starting from the better one (test
2) it stayed with that connection, thus testing positively the
advantage of using information based on the past performance
of the paths. Results for tests 1 and 2 can be seen in Table
IV. In test 1 the client always switched to the best path while
during test 2 the client always stayed with the best path.
Test 3 was made to check if when the best connection
available (the one being used) fails persistently, the framework
can chose another one, and how long it takes to switch to an
alternate path. Test 4 checks if the framework can detect a
decrease in the performance of the connection being used,
how long it takes to detect it, and how long it takes to switch
to another, better, connection. Results for tests 3 and 4 can be
seen in Tables V and VI. The “switch at” column represents
time after the best-path failure or performance update.
These two tests took noticeably more time to transfer the
file, because faults and performance problems were introduced. After 20 seconds of starting the transfer, we completely
blocked the path in use (Test 3) or decreased it’s performance
significantly to 100 Kbps (Test 4). With test 3, when a failure is
detected, after a TCP enforced timeout of 1000 milli seconds,
the framework immediately provides an alternate connection.
In this case, the available paths were worst than the one
TABLE IV
T ESTS 1 ( NO HISTORY ) AND 2 ( WITH HISTORY ) - T OTAL TRANSFER TIME
IN SECONDS .
Mean
No History
With History
171.04 ± 1.36
167.68 ± 0.86
TABLE V
T EST 3 ( PERSISTENT FAILURE ) - T OTAL TRANSFER TIME IN SECONDS .
Persistent Failure
Mean
Total time
Switch at
202.52 ± 14.55
1.27 ± 0.34
opened over the wireless link. Results can be seen in Table VII.
The first column shows the results when only the wireless link
was used, the second when only the wired link was used and
the third shows a scenario where the transfer started over the
wired interface and after the fault of that interface switched to
the wireless one. Since the switch to the alternative interface
is quick, only the block being transferred while the fault arose
was lost, what corresponds in average to a very short period.
Recall that the block size is 512 K Bytes and the file had
150 M Bytes, thus each block was transferred in less than 0.5
seconds. The end user would notice almost no difference.
TABLE VI
T EST 4 ( DECREASE IN
PERFORMANCE )
SECONDS .
T EST 5 ( WIRED
Decrease in performance
Mean
Total time
Switch at
355.65 ± 51.34
178.38 ± 62.36
that failed, hence the increasing in transfer time. Figure 2
represents the throughput in our application for the channel
being used at a given moment. This chart shows clearly that,
after 20 seconds, the throughput for the best-path dropped
to zero, i.e. a link failure occurred. After that failure another
path was chosen (middle-path). After a while even another
path was chosen (this time the worst-path). This path was
chosen because our system relies heavily on Smoothed RTT
when no previous transfer performance is available, and the
worst-path, despite having worst throughput, was with better
measurements of Smoothed RTT at the time.
Fig. 2.
Test 3 - Transfer Example
Test 4, on the other hand, takes longer, since the parameters
used to detect when a path decreases its performance revealed
hard to fine tune. In fact, in some of the 20 performed tests,
the framework took longer to react.
Now we turn to a different scenario intended to test a home
client with two interfaces (wired and wireless) accessing to
a remote server, over the public Internet, to download a file
of 150 MBytes. The client started by using the path over the
wired link. After 15 seconds this interface was shutdown, an
exception arose after the timeout and a new connection was
TABLE VII
- T OTAL TRANSFER TIME IN SECONDS .
- T OTAL TRANSFER TIME IN
Mean
LINK FAILURE )
Wireless (s)
Wired (s)
Link failure (s)
119.47 ± 2.24
115.93 ± 0.57
117.05 ± 0.34
Although more varied tests with different link characteristics could be performed, the presented ones are significant
to highlight the functionality and behavior of our proposed
framework.
V. R ELATED W ORK
Our proposal adheres to a simple evolutionary approach
by using several TCP connections and alternatively switching
among them. Other evolutionary approaches are possible.
Multi-Path TCP [4] leverages path diversity using all paths
simultaneously, however it cannot support server diversity and
requires the adoption of a new version of TCP. SCTP also
supports the usage of several local and remote IP addresses
and there is a very active research on leveraging this feature to
support transparent handover and multihoming [6], since the
original standard only used it to support backup paths. Both
transport protocols do not support the notion of a connection
between a client and a multi-server service, maintain diversity
hidden from application programmers and represent a significant departure from current stacks, something we would like
to avoid.
Leveraging diversity has been a recent trend that most P2P
systems are engaged in. Many techniques have been developed
to allow peers to choose, among the several available alternatives, the ones that are most effective. This optimization can
be solved by the peers alone or with the help of some extra
information, made available directly or indirectly by (network
or content) providers. Paper [12] presents a survey of the issues
and the solutions. We introduced a general purpose framework
to make available at application level the information TCP
already collects at the host kernel level. Our search for more
generality and application neutrality, as well as the leveraging
of the kernel TCP implementation are different, but can be
extended if providers provided hints on the quality of their
paths.
Most critical Internet services (e.g., DNS, CDNs), applications and subsystems use replication techniques to replicate
data and to redirect clients to the best available replica.
77
We propose an approach that empowers clients to choose
themselves the most suitable server.
Using local different addresses closely related to different
interfaces is now common place. Visibility of different server
IP addresses is not yet widespread. However, the so called
”Identity / Location Separation” approaches are based on
the usage of identity addresses, mapped to different location
addresses [3], [2]. Location addresses are closely related to
network properties and also denote paths, an idea that the
work described in [13] took to its limits. An upper level
service (e.g., DNS or a LISP mapping server) can provide the
extra indirection between a server or a service and the several
addresses that may be used to access them. NChannelSockets
builds on this eventual address diversity to explore network
diversity.
VI. D ISCUSSION AND FUTURE WORK
Our approach provides the same abstractions and mechanisms to be used in two different scenarios: edge exploitation
of network diversity and application exploitation of service
diversity. Concrete experiments made to explore both scenarios should be performed. Perhaps, these experiments will
recommend the separation of the programming patterns (and
the support mechanisms) to be used in these two different
contexts.
Service diversity exploitation requires more application engagement. For example, it would be challenging to use the proposed approach to implement a video streaming client capable
of automatically adapt the video resolution to the available
network performance, as current dynamic adaptable streaming
over HTTP clients do, but also simultaneously exploiting
alternative servers delivering the same video, to find the best
one. This kind of application requires a close control of the
switching moments and of the transactions between clients and
servers as our proposal allows. Nowadays, adaptable streaming
is being scaled to millions of costumers, by simultaneously
leveraging several content distribution networks. A provider
side control plane is already used to direct clients to a specific
data center. This control plane could be improved with client
side options.
Multi-Path TCP and SCTP are both well suited to leverage
transparent network diversity exploitation in a stable client
server relationship. In this scenario, it seems that both protocols are better alternatives than our proposal. However,
they prevent any control of the application over the criteria
used to choose paths. Our framework can be easily extended
to support other criteria to rank connections. For example,
connectivity price can be an extra parameter to be considered
when deciding to switch connections. Our proposal should also
be extended in this direction. Multi-Path TCP or SCTP seem
less suited to support that kind of experiments.
Finally, TCP interprets missed acknowledges as originated
by congestion episodes, not by path failures, and waits a long
period before declaring a TCP connection as broken.
78
Therefore, we use user level timeouts to detect path failures.
If we used very short timeouts (e.g., 100 milliseconds), we
may wrongly interpret these exceptions as path faults, and
introduce path switching instability. Thus, better ways to
distinguish path failures from path congestion are needed
and should be researched. However, this problem probably
stresses the limits of a fully client centric fault detection
method. In fact, if the RTT of a connection is significant, the
detection by the client that the path broke will take several
rounds, and will be impossible in the sub second range.
VII. C ONCLUSIONS
In his paper we have presented a programming pattern and
a support framework whose joint usage empowers a client
of a service to explore network and service diversity and
mask faults. The programming pattern is very simple and
easy to use and it successfully allows the programming of
a client of a replicated service, or of a server reachable by
different paths, to transparently explore several servers and
network paths for performance enhancing and fault masking.
The proposal is reasonably application neutral, is based on the
Web10G Linux kernel-level patch and interface and provides
user processes with means to explore and choose among
several alternative TCP connections between the client and
a potentially replicated service. No changes of the traditional
TCP/IP stack or of upper level protocols were required.
R EFERENCES
[1] D. Jen, M. Meisel, H. Yan, D. Massey, L. Wang, B. Zhang, and
L. Zhang, “Towards A New Internet Routing Architecture: Arguments
for Separating Edges from Transit Core,” in Seventh ACM Workshop on
Hot Topics in Networks (HotNets-VII), 2008.
[2] D. Meyer, “The locator identifier separation protocol (lisp),” The Internet
Protocol Journal, vol. 11, no. 1, March 2008.
[3] V. Kafle and M. Inoue, “Introducing multi-id and multi-locator into
network architecture,” Communications Magazine, IEEE, vol. 50, no. 3,
pp. 104 –110, march 2012.
[4] A. Ford et al., “Architectural guidelines for multipath TCP development,”
Internet Engineering Task Force (IETF) - RFC 6182, March 2011.
[5] E. Stewart, R., “Stream control transmission protocol - proposed standard,” Internet Engineering Task Force (IETF) - RFC 4960, September
2007.
[6] T. Wallace and A. Shami, “A review of multihoming issues using
the stream control transmission protocol,” Communications Surveys
Tutorials, IEEE, vol. 14, no. 2, pp. 565 –578, quarter 2012.
[7] T. Begen, A. Akgul and M. Baugher, “Watching video over the web:
Part 1: Streaming protocols,” Internet Computing, IEEE, vol. 15, no. 2,
pp. 54–63, march-april 2011.
[8] S. Akhshabi, A. Begen, and C. Dovrolis, “An experimental evaluation
of rate-adaptation algorithms in adaptive streaming over http,” ACM
MMSys, vol. 11, pp. 157–168, 2011.
[9] Web10G Project. http://web10g.org, 2011.
[10] E. Gamma, R. Helm, R. E. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA:
Addison-Wesley, 1995.
[11] M. Carbone and L. Rizzo, “Dummynet revisited,” SIGCOMM Comput.
Commun. Rev., vol. 40, no. 2, pp. 12–20, Apr. 2010.
[12] J. Dai, F. Liu, and B. Li, “The disparity between p2p overlays and isp
underlays: issues, existing solutions, and challenges,” Network, IEEE,
vol. 24, no. 6, pp. 36 –41, nov-dec 2010.
[13] X. Yang, D. Clark, and A. Berger, “Nira: A new inter-domain routing
architecture,” IEEE/ACM Transactions on networking, vol. 15, no. 4, pp.
775 –788, aug. 2007.
Towards Widespread use of SCTP for the Future
Internet
Bruno Sousa, Ricardo Santos, Marilia Curado
[email protected], [email protected], [email protected]
CISUC, University of Coimbra
Abstract—The future Internet is becoming a very important
researching topic, as the number of devices with multiple network
interfaces is greatly increasing. With its multi-homing support,
Stream Control Transmission Protocol (SCTP) supports multiple
network connections in a single association, which provides
resilience support. Fast Recovery Algorithm (FRA) is an algorithm that enhances the resilience support of SCTP by including
anomaly-trace and optimeHoming algorithms. Such algorithms
are able to detect faulty servers based on multiple criteria. This
paper analyses the performance of the usage of FRA in faulty
network environments of a distributed file transfer cloud service,
comparing to SCTP and TCP. In order to perform this study,
a testbed environment was used for evaluating the different
solutions. The obtained results show that FRA offers a more
resilient solution in faulty scenarios, comparing to the other
approaches.
Keywords: SCTP, multi-homing, reconfiguration mechanisms,
Fast Recovery Algorithm, testbed.
I. I NTRODUCTION
The future of the Internet is an active research topic, as
the existing networking technologies improve, where decentralized and distributed services are a growing trend, which
require more secure, scalable and resilient solutions, in order
to achieve the demanding performance.
As a transport protocol, Stream Control Transport Protocol
(SCTP) [1] already provides multi-homing support, a feature
that increases resilience by enabling the use of every network
interface from each device. However, there is a lack of decision
mechanisms suitable for faulty conditions, such as resources
unavailability or congestion situations. Therefore, there is a
need for the usage of more adaptive and robust solutions that
overcome the limitations of SCTP.
This paper addresses the usage of Fast Recovery Algorithm
(FRA) [2] over SCTP. FRA combines an anomaly-trace algorithm that detects faulty servers, and the optimeHoming
algorithm which enables server selection based on multicriteria mechanisms. FRA is compared with existing transport
protocols in a testbed environment, namely SCTP and TCP.
These approaches are tested in multiple scenarios presented in
a cloud file transfer service, where multiple servers are used to
provide content to their clients. The tested scenarios include
failure situations with network problems, such as delay, packet
loss or congestion, and resource unavailability conditions in
one of the servers (e.g. server overloading).
Given the above, this paper is structured as follows. In
Section II, it is presented existing work regarding the covered paper topic. The description of the used reconfiguration
mechanisms integrating FRA are described in Section III.
Section IV shows the architecture of the evaluated system and
the description of the different scenarios. The results of the
performed tests are discussed in Section V. Finally, Section VI
concludes the paper.
II. R ELATED W ORK
The usage of SCTP has been studied in the past years, as
a resilient transport-aware protocol. The existing literature in
this topic is focused in improving the behaviour of SCTP,
either with new protocol implementations based on specific
scenarios or configuring the native fail over mechanisms of
SCTP.
Authors in [3] analysed the performance of Single Path
Transfer and Concurrent Multi-path Transfer, two SCTPbased approaches, when transmitting multimedia data over
a network, being recommended a set of SCTP parameters
for each of the transferring mechanisms. In [4], the authors
studied the tuning of SCTP failover mechanisms in order
to reduce deteriorating effects for carrier grade telephone
signaling, providing a configuration recommendation for this
type of traffic.
The mobile Stream Control Transmission Protocol
(mSCTP) [5] is a SCTP implementation, focused in
mobility network schemes and supporting dynamic address
reconfiguration. In [6] authors identified scenarios where
mSCTP can enhance handover support through the multihoming mechanism, when comparing to the native SCTP
implementation. In [7], a comparison of using SCTP and
TCP while transferring Web traffic was studied. Besides
multi-homing, the authors explored SCTP’s multiple stream
feature when transferring multiple objects from HTTP
web pages. A TCP to SCTP shim layer [8] allows the
transformation of TCP system calls to SCTP system calls.
With such shim layer, TCP applications can communicate
through SCTP without modifying applications. The authors
demonstrated the utility of this layer using common network
applications (e.g. file transfer), improving their responsiveness
and network throughput. Authors in [9] also proposed an
application-aware transport solution, based in SCTP, focusing
in ensuring improved user satisfaction in multi-homed thin
client architectures, being leveraged by the use of multiple
network interfaces at the same time.
79
TABLE I: Modified SCTP API values
Parameter
rto min (ms)
rto max (ms)
max burst
path max retrans
Value
10
1000
20
1
Parameter
hb interval
sack timeout (ms)
addip enable
addip noauth enable
Value
5000
100
1
1
III. FAST R ECONFIGURATION A LGORITHM
This section describes and details the anomaly-trace and
optimeHoming algorithms to improve the resilience support
of FRA.
A. SCTP
Stream Control Transport Protocol (SCTP) [1] is a transport
protocol that supports multi-homing, a feature that is lacking
in most of the common transport protocols, such as TCP or
UDP. With its primary-backup model, it is defined a primary
path used for data transfer. The remaining available paths are
backup paths that can be used to replace the primary path
when a failure occurs (mostly detected through retransmission
time outs). That way, SCTP contains resilience mechanisms,
along with other configurable options that can be used to
improve multi-homing support, such as message delivery options, number of streams, retransmission time outs and number
of retransmissions. The used values from the SCTP kernel
API are detailed in Table I. Authors in [10] showed that
performance improvements can be achieved by defining short
SACK timeout and retransmission timeout (RTO) minimum
and maximum values. In [3], authors show that configuring
the Path Max Retransmissions (PMR) value to a low value
(0 or 1) can achieve best throughput in failure or non-failure
scenarios. addip_enable and addip_noauth_enable
were set to 1 to allow the dynamic configuration of the SCTP
primary address.
B. Anomaly-trace Algorithm
The anomaly-trace algorithm [11] detects anomalies in each
of the network nodes, based on real-time collected metrics
by sar, an utility from the sysstat [12] Linux package.
sysstat contains performance monitoring and log tools for
measuring Operating System level metrics, such as CPU utilization, CPU run-queue size, pages in/out used, free memory,
packets sent/received, disk blocks read/written and read/write
transactions. Using this algorithm, nodes behaving abnormaly
can be detected and switch to a faulty free node. The output
of this algorithm works as a cost criterion algorithm, where 0
indicates stable condition and 1 corresponds to a faulty/failure
situation.
C. Multihoming optimization - optimeHoming
The optimeHoming algorithm [13] provides an evaluation
for each existing server. Based on a list of benefits (security,
availability, path capacity and available path capacity) and a
list of costs (round trip time, loss, reorder, anomaly trace score,
delay and jitter), the algorithm scores and ranks each server,
defining the best server that should be used. Its output is a n×2
matrix (being n the number of servers), with the server number
80
Fig. 1: Evaluated system architecture
in the first column and its respective score in the second one.
Using this algorithm the total file transfer time is expected to
be improved.
FRA configures the primary path and the server to use of
SCTP, according the server score determined by optimeHoming, which relies on the anomaly-trace algorithm.
IV. E VALUATION
This section details the testbed architecture, the testing
scenarios and the evaluated metrics. For each type of testing
scenario, tests were made using TCP, SCTP and FRA.
A. Architecture
The evaluated system corresponds to a file transfer service,
hosted in a cloud environment, as per Figure 1. That way,
two servers are used, representing a distributed file transfer
service, along with a client that receives the files. Each server
has two Gigabit Ethernet network connections that the client
uses. The client would receive files through one server at time,
despite the possibility to have load balancing between servers.
Besides client and servers, two computers were also used as
traffic generators to emulate a congested network scenario.
B. Scenarios
The experiments were made through five different scenarios:
In a normal without-faults model, with induced delay, packet
loss, network congestion and resources failure, respectively.
The results of each testing scenario includes results from
12 runs, as with such number of runs results were stable,
without significant variations. The experiments consisted in
transferring multiple files with two different sizes (≈ 750M b,
corresponding to a typical CD image - referred as CD, and
≈ 2000M b, an average size DVD image - named DVD), from
the servers to the client.
1) Without faults - normal: This represents both servers
and client in a stable environment establishing therefore, a
baseline reference for the studied scenarios. Thus, no existing
network restrictions exist that can affect the file transfer
throughput.
2) With delay - delay: The delay scenario consists in a
replica of the normal scenario conditions, but inducing delay
between one network interface of one server. A networking
with these conditions can represent a client trying to access
the file transfer service cloud from a mobile device in a poor
network signal. This was made using the traffic control tool
from Linux tc [14]. Two different tests were made - in the first
there was a delay of 50ms with a 20ms variation, following
an normal distribution and, in the second, there was a delay
of 100ms with a 20ms variation, also following a normal
distribution. Figure 2 presents an example of an induced delay
in a network interface command using tc.
tc qdisc add dev eth0 parent 1:3 handle 31:
delay 100ms 20ms distribution normal
Total transfer time represents the elapsed time between
the first and last received file data chunk. This is calculated by the file transfer client node.
Individual sequence transfer time corresponds to the
time taken to transfer a file sequence. It is calculated
by determining the elapsed time between a previously
received chunk and the reception of a new file sequence.
Percentage of server utilization after each file transfer
run, the number of sequences sent through each server
is summed, using the last field of each sequence log line
(Figure 5) and the usage percentage is calculated, for each
server.
•
•
•
2066945;1368201564434;0
netem
Fig. 5: Received sequence log line (sequence number, received time, server number)
Fig. 2: Adding network interface delay using tc code
3) With packet loss - loss: The loss scenario consists in
inducing packet loss between a network interface of one server.
With tc two tests were made, with 5% and 15% loss rate,
respectively. In a real production environment, the existence of
networks with a consistent packet loss rate could mean existing
routing problems or faulty network hardware e.g., which can
degrade the performance of the provided services. Figure 3
shows an example of an induced packet loss in a network
interface command using tc.
V. R ESULTS
This section presents the obtained results for the metrics
defined in Section IV-C, divided for each scenario. Table II
summarizes the results for all the scenarios, regarding server
usage ratio and transfer time.
A. Without faults - normal scenario
65.74
tc qdisc add dev eth0 parent 1:3 handle 31: netem
loss 5%
61.27
60.28
DVD_FRA
DVD_SCTP
60
4) With congestion - cong: cong consists in inducing
network congestion in one of the network interfaces of one
of the servers. Using iperf [15] each traffic generator introduced 350M bps of UDP traffic towards the server’s network
interface. This scenario simulates multiple simultaneous file
transfers between the servers and clients. Having one of the
server’s network interface congested, both client and server’s
file transfer behaviour under such condition can be analysed.
Figure 4 shows an used iperf script for generating network
traffic during 1 hour (3600 seconds).
transfer time (s)
Fig. 3: Adding network interface packet loss using tc code
40
27.40
Fig. 4: Generating 350M bps of UDP traffic during 3600s with iperf
5) With resources failure - fail: This scenario overloads a
server by introducing CPU intensive tasks. This can represent
a situation when the server is too busy processing requests
or doing multiple system calls at the same time. In order to
create the overload, 1000 processes running md5sum were
introduced in the server, determining the md5 checksum value
of the file used in the DVD tests (≈ 2000M B).
C. Metrics
For each test executed through the scenarios presented in
Section IV-B, the following metrics were collected:
24.41
CD_SCTP
CD_TCP
20
0
CD_FRA
iperf -c 10.161.230.91 -u -b 350m -t 3600
25.28
Test Cases
DVD_TCP
Fig. 6: Average file transfer time results for normal scenario
Figure 6 shows the mean transfer time of CD and DVD in
normal scenario, using TCP, SCTP and FRA. The achieved
results are used as a reference, acting as a baseline to the remaining tests, made in the different scenarios. It is observable
that the average file transfer time in CD is lower when using
TCP, comparing to SCTP and FRA. In DVD, SCTP performs
better than TCP and FRA. Despise this mean file transfer time
comparison, the difference between the obtained values is very
small due to the absence of any type of failure in this scenario.
As seen in Figure 7, during a testing run with CD, all the
three transfer protocols have a linear growth on the individual
sequence transfer time, being close to each other.
81
TABLE II: Transfer time and server usage ratio results for the evluated scenarios
Transfer
Time (s)
normal
50ms
delay
100ms
5%
loss
15%
cong
fail
22803
64961
769609
1450231
332450
907932
932635
2673856
1865271
5347713
1380724
3592340
3326959
10164635
CD
DVD
CD
DVD
CD
DVD
CD
DVD
CD
DVD
CD
DVD
CD
DVD
TCP
Utilization
of server
0
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
Utilization
of server
1
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
SCTP
Utilization
of server
0
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
Transfer
Time (s)
24412
59164
38235
95916
58461
117209
38522
101694
43441
95624
241384
509037
5108029
10202490
Utilization
of server
1
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
Transfer
Time (s)
24981
60159
28095
73257
29282
81527
28122
76955
30469
87046
23288
72494
27303
61934
FRA
Utilization
of server
0
0%
0%
0%
12.16%
0%
0%
0%
0%
0%
0%
0%
0%
0.01%
0.02%
Utilization
of server
1
100%
100%
100%
87.84%
100%
100%
100%
100%
100%
100%
100%
100%
99.99%
99.98%
Transfer over time
proto
FRA
SCTP
117.21
TCP
95.75
100
81.53
Transfer Time (ms)
transfer time (s)
20000
58.46
73.27
38.24
50
10000
29.28
28.10
CD
DVD
0
0
0e+00
2e+05
4e+05
Sequence/Time
6e+05
Fdelay1_FRA
Fdelay0_FRA
Fdelay1_FRA
Fdelay0_FRA
Fdelay0_SCTP
Fdelay0_SCTP
Fdelay1_SCTP
Fdelay1_SCTP
8e+05
Fig. 8: Average total file transfer time results for delay
Fig. 7: Individual sequence transfer time in normal for CD
Transfer over time
B. With delay
proto
82
FRA
SCTP
TCP
524.288
262.144
131.072
65.536
32.768
16.384
8.192
Transfer Time (s)
Figure 8 shows the mean transfer time for CD and DVD in
delay cases, with induced 50ms and 100ms delay respectively, both with a 20ms normal variation, having the delay
applied in one of the servers network interface. The results
are presented for FRA and SCTP. TCP mean file transfer
time values were not presented in the figure due to their
extremely high values, comparing to FRA and SCTP. Although
it is visible the difference of sequence transfer times during
a testing run for delay with 100ms and transferring CD in
Figure 9, where it is used a logarithmic scale in the transfer
time axis, due to the results scale difference.
In this scenario, TCP only used the address with delay, since
it lacks multi-homing support, which explains the high transfer
times.
Although SCTP can detect path failure with its native
resilience support mechanisms, for this scenario, in the beginning of each test run, the sent packets arrived to the client
before the RTO interval expired, which delayed the alternate
address retransmission event. This provoked a transfer time
4.096
1.024
0.001
0
2e+05
4e+05
Sequence/Time
6e+05
8e+05
Fig. 9: Individual sequence transfer time in delay with 100ms and CD
overhead when comparing to FRA, where the optimeHoming
algorithm detected quickly this induced delay failure.
150
101.69
72.49
75
23.29
25
100
0
600
transfer time (s)
76.96
36.86
50
509.04
400
241.38
200
0
28.12
30.47
3592.34
3000
CD
0
DVD
1380.72
1000
0
Floss0_FRA
Floss1_FRA
Floss0_FRA
Floss1_FRA
Floss1_SCTP
Floss0_SCTP
Floss0_SCTP
Floss1_SCTP
Fig. 10: Average total file transfer time results for loss
CD_Fcongest
FRA
Test Cases
DVD_Fcongest
Fig. 12: Average total file transfer time results for cong
Transfer over time
Transfer over time
proto
TCP
2000
proto
SCTP
65536
FRA
SCTP
TCP
1048.576
32768
524.288
16384
262.144
8192
131.072
65.536
4096
32.768
16.384
1024
Transfer Time (s)
Transfer Time (ms)
SCTP
transfer time (s)
87.05
43.44
FRA
50
95.62
8.192
4.096
1.024
0.001
1
0
2e+05
4e+05
Sequence/Time
6e+05
8e+05
Fig. 11: Individual sequence transfer time in loss with 15% and CD
C. With packet loss
Figure 10 shows the mean transfer time for CD and DVD
in loss, evaluating the system with a loss rate of 5% and
15% applied to one of the servers network interface. As in
Section V-B, the mean transfer time values for TCP were
extremely higher than FRA and SCTP, so only the last two
protocols are presented in the figure.
With existing packet loss, SCTP performed equally
good comparing to FRA. This can be explained due to
the used SCTP configurations, where it is set a low
Path.Max.Retransmissions value. That way, SCTP
quickly detects path failure and quickly starts retransmitting
packets through the alternative address, where there is no
packet loss.
D. With congestion
In cong, both TCP and SCTP makes use of the server
with the congested network interface. TCP uses the congested
address during the entire file transfer, therefore having very
0
2e+05
4e+05
Sequence/Time
6e+05
8e+05
Fig. 13: Individual sequence transfer time in cong with CD
high file transfer results.
In FRA, with all the incoming congestion traffic present in
the affected server, the Anomaly-trace algorithm detected the
elevated processing rate and quickly switched the used server.
That way, FRA mean file transfer times were not affected by
the induced network congestion.
With that, as seen in Figure 12 and Figure 13, FRA performs
better than SCTP and TCP.
E. With resources failure
In the fail scenario, the induced resources failure in
one of the servers quickly reduced its processing capacity,
therefore affecting drastically the performance of the file
transfer service. Since TCP and SCTP were not using the
optimeHoming algorithm, these kind of failures detection was
not present during each test, always using the server without
available resources.
In FRA, this lack of processing power was quickly detected
by the anomaly-trace algorithm, which triggered OptiHoming
to immediately change the used server, performing the rest of
83
All these approaches were tested in a cloud file transfer
service between multiple servers and a client, under different
scenarios. Besides the normal service usage, the evaluation
was performed in different faulty situations.
After performing the results analysis, it was concluded
that FRA enhances the resilience support of SCTP in fault
scenarios including losses, delay, network congestion and
resource failures, compared to TCP and SCTP.
61.93
75
FRA
50
27.30
25
10202.49
7500
5104.98
5000
SCTP
transfer time (s)
0
10000
2500
ACKNOWLEDGMENTS
0
10000
This work was partially financed by ISA and OneSource
and by the program COMPETE, in the project of SI I&DT
sMeter (“Plataforma Integrada para eficiência energética e
smart metering”, contract n. 21588, QREN FCOMP-01-02).
10164.64
7500
TCP
5000
4990.44
2500
0
CD
R EFERENCES
DVD
Test Cases
Fig. 14: Average total file transfer time results for fail
Transfer over time
proto
FRA
SCTP
Transfer Time (ms)
1048576
524288
262144
131072
65536
32768
16384
8192
4096
1024
1
0
2e+05
4e+05
Sequence/Time
6e+05
8e+05
Fig. 15: Individual sequence transfer time in fail with CD
the file transfer in the server without processing issues. With
that, FRA mean file transfer times were several times lower
than SCTP and TCP, as presented in Figure 14 and Figure 15.
VI. C ONCLUSION
With the accelerated technology improvements presented
nowadays, the existing number of devices with multiple interfaces has significantly increased. The characteristics of these
devices motivates the usage of transport protocols that supports multi-homing, such as the Stream Control Transmission
Protocol.
In order to improve the usage of those interfaces, there is
a need to create resilient-aware adaptive mechanisms over the
existing ones. This paper investigated the behaviour of existing
transport protocols, TCP and SCTP, and Fast Reconfiguration
Algorithm, an algorithm that increases resilience support of
SCTP by performing a multi-criteria evaluation of the status of
the network and by identifying if a node is behaving properly.
84
[1] R. Stewart, Ed., “Stream Control Transmission Protocol,” IETF Request
for Comments: 4960, September 2007.
[2] B. M. Sousa, R. Santos, M. Curado, S. Pertet, R. Gandhi, C. Silva,
and K. Pentikousis, “Enhancing Reconfiguration in the Cloud,” in IEEE
CAMAD 2013, September 2013.
[3] Changqiao Xu, Enda Fallon, Yuansong Qiao, Lujie Zhong, Gabriel-Miro
Muntean, “Performance Evaluation of Multimedia Content Distribution
Over Multi-Homed Wireless Networks,” IEEE TRANSACTIONS ON
BROADCASTING, VOL. 57, NO. 2, June 2011.
[4] Johan Eklund, Karl-Johan Grinnem, Stephan Baucke, Anna Brunstrom,
“Tuning SCTP failover for carrier grade telephony signaling,” Elsevier
Computer Networks 54 (2010), 2010.
[5] M. Riegel, M. Tuexen, “Mobile SCTP,” Working Draft, Tech. Rep.,
2005.
[6] A. Brunstrom, K.-J. Grinnemo,1, R. Fracchia, Ł. Budzisz, R. Ferrús, G.
Galante, F. Casadevall, “Towards transport-layer mobility: Evolution of
SCTP multihoming,” Elsevier Computer Cummunications 31 (2008),
2008.
[7] Rajesh Rajamani, Sumit Kumar, Nikhil Gupta, “SCTP versus TCP:
Comparing the Performance of Transport Protocols for Web Traffic,”
Technical report, University of Wisconsin-Madison, 2002.
[8] Ryan W. Bickhart, Paul D. Amer, Randall R. Stewart, “Transparent TCPto-SCTP Translation Shim Layer,” EuroBSDCon, Copenhagen 2007,
2007.
[9] Md. Ali-Al-Mamun, Md. Motaharul Islam, Seung-Un Choe, Eui-Nam
Huh, “SCTP based Protocol Architecture for Multihomed Thin Client,”
International Conference on Ubiquitous Information Management and
Communication ’12, 2012.
[10] R. Rembarz, S. Baucke, and P. Mahonen, “Enhancing resilience for high
availability ip-based signaling transport,” in Personal, Indoor and Mobile
Radio Communications, 2005. PIMRC 2005. IEEE 16th International
Symposium on, vol. 4, 2005, pp. 2301–2305 Vol. 4.
[11] Soila Kavulya, Rajeev Gandhi, Priya Narasimhan, “Gumshoe: Diagnosing Performance Problems in Replicated File-Systems,” SRDS ’08. IEEE
Symposium on Reliable Distributed Systems, 2008.
[12] Sebastien Godard. (2006) Sysstat utilities home page. [Online].
Available: http://sebastien.godard.pagesperso-orange.fr/
[13] Bruno Sousa, Kostas Pentikousis, Marilia Curado, “Enhancing Path
Selection in Multihomed Nodes,” 2013, submitted to 5th International
Conference on Mobile Networks and Management, MONAMI 2013.
[14] Bert Hubert. (2000) Linux Advanced Routing & Traffic Control
HOWTO. [Online]. Available: http://lartc.org/lartc.html
[15] National Laboratory for Applied Network Research. (2008) Iperf.
[Online]. Available: http://iperf.sourceforge.net/
A comparative analysis of IEEE 802.11 MAC layer
mechanisms to handle real-time traffic in
open communication environments
Robson Costa∗ , Paulo Portugal∗∗ , Francisco Vasques∗ and Ricardo Moraes§
∗ IDMEC,
FEUP, University of Porto – Porto, Portugal
TEC, FEUP, University of Porto – Porto, Portugal
§ Federal University of Santa Catarina – Araranguá, Brazil
Email: {robson, pportugal and vasques}@fe.up.pt and [email protected]
∗∗ INESC
Abstract—The IEEE 802.11 standard has been evolving over
the past decade by introducing new mechanisms with the aim
to improve communication’s QoS (Quality of Service). Among
them we highlight the MAC layer mechanisms, namely DCF,
PCF, EDCA and HCCA. In this paper we perform a comparative
analysis between these mechanisms to handle real-time traffic in
an open communication environment composed of real-time (RT)
and non-RT stations operating in the same frequency channel
and coverage area. The target of the paper is to understand
the limitations of each mechanism and to provide a comparative
assessment between them when supporting RT communication.
We show that for most of the situations, including less demanding
scenarios, these mechanisms are not adequate to support RT
traffic.
I. I NTRODUCTION
Presently there is a growing interest to support real-time
(RT) applications using wireless technologies, particulary in
industrial environments. Although wireless solutions are more
susceptible to transmission problems than wired ones, it is
a fact that most industrial applications can tolerate a few
message losses or deadline misses without compromising
significantly its performance [1]. In this context, the IEEE
802.11 [2] family of protocols appears as a promising solution
to support these applications due to its large acceptance, high
performance, easy deployment and low cost.
An aspect that must be considered when addressing wireless solutions, is that all the stations share the access to the
same radio channel, as the medium is an open communication
environment. Thus, any participant can try to access the
medium at any instant according to the MAC (Media Access
Control) rules and establish its own communication channels. Furthermore, the wireless communication environment
is susceptible to interferences from devices using the same
frequency band [3], as well as interferences resulting from
signal propagation and noise (e.g. fading and electromagnetic
interference – EMI). As a consequence, the system load cannot
be predicted at system setup time, nor can it be effectively
controlled during the system run-time.
This is a well known problem that has been addressed in
the last years through the proposal of enhanced mechanisms
on successive versions/extensions of the standard (e.g. IEEE
802.11e to support QoS stations), or by using upper layer protocols that try to guarantee specific requirements (e.g. latency).
However, most of these solutions were developed having in
mind non-RT traffic. Even when RT traffic was considered,
the assumed requirements are generally very different from
those found in industrial environments. These scenarios are
characterized by control applications that exchange periodic
traffic, conveyed in small packets, with stringent deadlines.
Small and controlled delays and lower deadline miss ratios
are usual traffic requirements. Moreover, the non-compliance
with these requirements can lead to unpredictable behavior by
control applications, which can result in economic losses or
even in danger for the people or the environment.
The main contribution of this paper are twofold. First, to
perform an assessment, by simulation, of the medium access
mechanisms (DCF – Distributed Coordination Function, PCF
– Point Coordination Function, EDCA – Enhanced Distributed
Channel Access and HCCA – HCF Controlled Channel Access) defined in the IEEE 802.11 standard to handle RT traffic
in an open communication environment. By RT traffic we mean
small sized packets, generated periodically with well-defined
temporal deadlines. Although in the last decade many papers
have been published on the evaluation of these mechanisms,
most of them focuses on scenarios and metrics usually found
in multimedia environments. Only a few of them consider RT
traffic commonly found in industrial environments (relevant
exceptions are [4] and [5]), and even in these cases only a
partial assessment was made. Moreover, the impact of varying
network conditions, which is one of the main challenges to
ensure QoS support in IEEE 802.11 networks, as identified in
[6], are usually not considered. Second, by using the same set
of scenarios for the assessment of all mechanisms it is possible
to perform a comparative analysis between them. This is also
an advantage over previous works, were each mechanism was
assessed independently using different parameters, metrics and
scenarios.
The remainder of this paper is organized as follows: Section
II presents the medium access mechanisms defined by the
IEEE 802.11 standard. Simulation results are presented in
section III. In Section IV a summary and state-of-the-art are
drawn. Finally, the paper is concluded in Section V.
II. IEEE 802.11 M EDIUM ACCESS M ECHANISMS
The main medium access mechanism of the IEEE 802.11
standard is based on a CSMA/CA (Carrier Sense Multiple
Access with Collision Avoidance) mechanism, referred as DCF.
More accurately, the original IEEE 802.11 MAC sublayer
introduces two MAC functions: the mandatory DCF and the
85
At the beginning of the CFP the PC sends a beacon
message, which defines the maximum duration of the CFP
(CFPmax ). All stations that receive this beacon message set
the NAV (Network Allocation Vector) to the value defined
into the CFPmax to block the medium access of DCF-based
stations. As an additional safe-guard to prevent interference, all
contention-free transmissions are separated only by SIFS and
PIFS intervals (Fig. 1). As both are shorter than DIFS interval
(used by DCF), no DCF-based stations can gain access to the
medium before the PCF stations (Fig. 2).
Contention-Free Repetition Interval
Contention-Free Period
Thus, in this specific case, stations keep sensing the
medium for this additional random time, after detecting the
medium as idle for a DIFS interval. If the medium gets busy
due to interference or transmissions while a station is downcounting its backoff counter, the station stops down-counting
and defers the medium access until the medium becomes idle
for a DIFS interval again. As soon as the backoff counter
reaches zero, the station retries its transmission (Fig. 1). A
new independent random backoff value is selected for each
new transmission attempt, where the CW value is increased
by (CW old × 2 + 1), with an upper bound given by CWmax .
Fig. 1.
DCF and EDCA interframe spaces.
The DCF access method imposes an idle interval between
consecutive messages, which is called IFS (Interframe Space).
Different IFS are defined in order to impose different priorities
to multiple message types as follows: the SIFS (Short Interframe Space) is the shortest of the interframe spaces and it is
used for acknowledgement (ACK) messages, the PIFS (PCF
Interframe Space) is only used by stations operating under
the PCF mechanism, the DIFS is used by stations operating
under the DCF mechanism and the EIFS (Extended Interframe
Space) is used in communication-error conditions.
In a different way, the PCF provides a contention-free
service. It implements a centralized polling scheme to support
synchronous data transmissions, where the PC (Point Coordinator) performs the role of polling master. In this context,
the associated stations only can begin a transmission after
receiving an authorization message from the PC. Thus, the
PCF is restricted to infrastructured networks.
The contention-free service is not provided full-time. Periods of contention-free service arbitrated by the PC alternate
with the standard DCF-based service. When the PCF is used,
the time on the medium is divided in CFP (Contention-Free
Period) and CP (Contention Period). Access to the medium
in the first case is controlled by the PCF, while access to the
medium in the second case is controlled by the DCF.
86
SIFS
SIFS
SIFS
D2 + ack
+ poll
D1 + poll
D3 + ack
+ poll
U1 + ack
SIFS
Contention Period
SIFS
PIFS
CF-End
PIFS
Beacon
optional PCF. DCF is the basic IEEE 802.11 mechanism,
where stations perform a so-called backoff procedure before
initiating a transmission. That is, when a station wants to transmit, it previously senses the medium; if the medium remains
idle during a specific time interval called DIFS (Distributed
Interframe Space) it immediately starts the transmission. Otherwise, the station selects a random backoff time. The duration
of this random interval is a multiple of the Slot Time (ST),
which is a system parameter that depends on the characteristics
of the physical layer. The number of slots is an integer in the
range of [0, CW], where CW (Contention Window) is initially
assigned as CWmin . A backoff counter is used to maintain the
current value of the backoff time.
D4 + poll
U2 + ack
U4 + ack
SIFS
SIFS
No response to CF-Poll
Reset NAV
NAV
NAV = Network Allocation Vector
Dx = Frames sent by Point Coordinator
Ux = Frames sent by polled stations
Fig. 2.
CFPMaxDuration
PCF service.
After the PC has taken control of the wireless medium,
it polls any associated stations on a polling list for data
transmissions. During the CFP, stations may only transmit if
the PC requests the transmission with a contention-free polling
frame (CF-Poll). Each CF-Poll allows the station to transmit
one frame. Multiple frames can be transmitted only if the PC
sends multiple poll requests. To ensure that the PC retains
control of the medium, it may send a CP-Poll to the next
station on its polling list if no response is received after one
PIFS interval. Soon after the end of CFP, the CP starts. The
CP must have a minimum duration equal to the time required
to transmit and acknowledge one MPDU (MAC Protocol Data
Unit) with maximum size (i.e. 4095 bytes).
The beginning of first transmission in CFP not necessarily
matches with the beginning of CFP. Some times it is possible
that a DCF-based transmission overrun the end of the CP.
When this occurs, the CFP is foreshortened. The transmission
of current frame is finished before the transmission of the next
beacon frame, which will announce the start of contentionfree operation. The CFP is shortened by the amount of the
delay generated by the previously foreshortening. The CFP
ends no later than the maximum duration from the next
expected beginning point, referred as TBTT (Target Beacon
Transmission Time). The PC may also terminate the CFP
before the time defined into the beacon frame by transmitting a
CF-End frame. It can support this decision based on the polling
list size or any other factor that the PC considers important.
In order to provide QoS support to IEEE 802.11 networks,
an additional function called HCF (Hybrid Coordination Function) was incorporated in 2005. HCF schedules the access to
the channel allocating a TXOP (Transmission Opportunities)
to each station. A TXOP is defined by a starting time and a
maximum duration (i.e. a time interval during which the station
keeps the control of the medium). Consequently, multiple
messages can be transmitted within an acquired TXOP. The
allocation of TXOP to the stations can be made through one
of two access mechanisms of the HCF: EDCA and HCCA.
The EDCA was designed to enhance the DCF mechanism
providing differentiated transmission services with four AC
Contention-Free Repetition Interval
Contention-Free Period
AIF S[AC] = AIF SN[AC] × aSlotT ime + SIF S
(1)
where the AIF SN[AC] is a positive integer that must be
greater than or equal to 2 for all QoS Stations (QSTA), except
for the QoS Access Points (QAP), where it shall be greater
than or equal to 1. As mentioned before, CWmin and CWmax
parameters depends on the characteristics of the physical layer.
Similarly to PCF, the HCCA is a centralized and contention
free based coordination system that uses a polling mechanism
to distribute TXOP to each HCCA station. It contains a logical
entity known as HC (Hybrid Coordinator) residing in the AP
(Access Point), which includes an ACU (Admission Control
Unit) and a scheduler. The ACU decides whether to accept or
refuse each requested TXOP, and the scheduler controls the
polling according to the decisions of the ACU. The HCCA
guarantees the necessary bandwidth through negotiation between HC and the station that wants be polled.
In the negotiation process, a station uses the TSPEC (Traffic
Specification) field of management frames to convey QoS
information. TSPEC is a set of QoS parameters that are used
to describe a TS (Traffic Stream1 ). These informations are
inserted into an ADDTS (Add Traffic Stream) request message
and sent to the HC. Based on these parameters the ACU
decides whether or not to admit the station request. The station
is informed of the decision by means of an ADDTS response
message. If the request was admitted, the scheduler will launch
the newly allowed TXOP to the polling routine.
The polling routine of the HCCA can operate in two modes:
i) using only the CFP; and ii) using both CFP and CP. In
the first mode, only HCCA stations will be able to transmit,
while in the second mode the CFP is reserved exclusively
to HCCA stations, being the CP shared between HCCA and
EDCA stations. When a HCCA station is polled during the
CP, this time is called CAP (Contention Access Phase).
In the beginning of each CFP interval, the HC sends a
beacon message specifying the start time and duration of the
CFP (Fig. 3). After this, the HC offers a TXOP to HCCA
stations by sending CF-Poll messages to them. The stations
must reply back within a SIFS interval with a data message
or a null message, indicating that the station has no traffic or
that the requested message exceeds the allocated TXOP. If no
message is received after PIFS interval, the HC polls the next
station in the polling list. The CFP ends when the HC sends
a CF-End message, or when the CFP duration expires.
For further details concerning the description of the IEEE
802.11 protocol, please refer to the standard [2].
1A
Traffic Stream identifies a specific data flow between two stations.
PIFS
Data
Ack
Data
SIFS
CF-Poll
AIFS
Ack . . .
Ack
Data
Different levels of service are provided to each AC, based
on three independent mechanisms: the AIFS (Arbitration Interframe Space), the TXOP and the CW size. Similarly to DCF,
a station operating under EDCA will wait that the medium
remains idle during an AIF S[AC] interval before beginning
its transmission. This interval time is given by:
Contention Period
SIFS
SIFS
CF-End
PIFS
CF-Poll
PIFS
Beacon
(Access Categories). Each message arriving at the MAC sublayer with a defined priority will be mapped into one of the
four AC, as follows: background (BK), best-effort (BE), video
(VI) and voice (VO), that is the highest priority level.
SIFS
SIFS
EDCA TXOP
HCCA TXOP (polled)
Reset NAV
HCCA TXOP polled
SIFS
Controlled Access Phase
Reset NAV
NAV
NAV = Network Allocation Vector
Fig. 3.
HCCA service.
III. S IMULATION A NALYSIS
The proposed scenarios compare the support of RT traffic
transmission using DCF, PCF, EDCA and HCCA mechanisms,
when operating in an open communication environment. The
simulation scenarios were built considering a RT infrastructured network overlapped with a non-RT infrastructured network, both operating in the same coverage area and frequency
channel. The RT network is composed of multiple RT stations
(clients) and one RT server (SRVRT ) that exchange messages
with each other through a real-time Access Point (APRT ). The
non-RT network operates based on the EDCA function and
it is composed of 10 non-RT stations (clients) and one nonRT server (SRVnon−RT ) that also exchange messages with
each other through a non-RT Access Point (APnon−RT ). It is
assumed that all stations are within the range of transmission
of each other and there is no node mobility nor hidden stations.
RT stations only transfer RT traffic. Each RT message
has a MSDU size of 73 bytes and has constant generation
period (Pi ). In order to simplifying the analysis we have
assessed periods of 30 and 60 milliseconds separately. We
also consider that each RT message has a deadline equal to
its period. RT traffic is transmitted in the voice AC in the
EDCA and HCCA mechanisms, that is, using the highest
access category (and priority). For the remaining cases (PCF
and DCF), it is transmitted in the standard queue. Related to
the CFP parameter of PCF and HCCA, in both cases it was
defined as 50% of Pi , i.e. Pi/2.
Each non-RT station generates 5 types of traffic that are
transmitted in 3 different AC. The best-effort AC transmits
HTTP, FTP and SMTP/POP traffic according to a Poisson
distribution. The MSDU size ranges from 350 bytes (e.g.
HTTP request) to MSDU maximum size (i.e. 2304 bytes).
The voice AC transmits VoIP traffic using the G.711 codec. In
this case messages have a constant MSDU size of 160 bytes
and are transmitted with a constant period of 20 milliseconds.
Finally, the video AC transmits video-conference traffic using
the H.264 codec. This results in a bandwidth consumption
of 240 Kbits/s per camera stream that is achieved by the
transmission of messages with a variable MSDU size.
Since the non-RT traffic is transmitted using the EDCA
mechanism, no admission control is used. For the set of nonRT stations, the offered load is classified as Low, Mid and High
corresponding to 10%, 30% and 50% of the maximum theoretical throughput, respectively. Each offered load is composed
by 15% of voice traffic, 25% of video traffic and 60% of besteffort traffic. In order to avoid transmission synchronizations,
both RT and non-RT stations are randomly started.
All models were evaluated using the OPNET simulation
tool [7]. The physical layer is based on the IEEE 802.11a
87
Upperbound deadline misses
5
0
5
10
15
20
25
30
35
40
DCF
PCF
EDCA
HCCA
15
10
5
0
5
10
Number of Real-Time Stations
15
DCF
PCF
EDCA
HCCA
10 Upperbound deadline misses
5
0
10
20
30
40
50
60
70
Fig. 5.
(a) Network Load = Low
Average deadline misses (P = 60ms)
80
20
25
30
35
40
10
5
0
5
10
15
10
10
20
30
40
50
60
(b) Network Load = Mid
All the simulation results have been obtained with a 95%
confidence interval, with a half-width relative interval less than
5%. The performance metrics used to analyze RT traffic are
the usually found in industrial environments, and include the
average deadline miss ratio and average delay. The average
deadline miss ratio represents the average ratio of RT messages
that miss their deadlines either by loss or delayed delivery to
the destination. The average delay represents the end-to-end
average delay of the successfully delivered messages.
A. Results: Average Deadline Miss Ratio
The first analysis concerns the assessment of the average
deadline miss ratio. A rule-of-thumb usually employed by
industrial control applications says that the upper limit should
not be over 5%. Figure 4 shows the deadline miss ratio for
Pi = 30 milliseconds.
When considering the Low network load case (Fig. 4(a)),
the DCF can support up to 26 RT stations. EDCA and PCF
increase this value up to 30 and 36 RT stations, respectively. It
is important to note that the deadline miss ratio in the HCCA
mechanism is null, but it can support only 2 RT stations. This
is consequence of its pessimistic assumptions used by their
admission control mechanism which computes all ADDTS
requests based on the MSDU maximum size. Furthermore, the
HCCA requires that all its transmissions are performed using
the basic transmission rate allowed by the physical layer.
When the network load is increased to the Mid level (Fig.
4(b)), the number of supported RT stations is significantly
20
25
30
35
40
(c) Network Load = High
5
0
15
DCF
PCF
EDCA
HCCA
[8]. Each station operates at OFDM (Orthogonal Frequency
Division Multiplexing) physical mode, where control messages
are transmitted at a basic rate (6 Mbits/s) while MSDU are
transmitted at 54 Mbits/s. We consider an error-prone communication channel based on the model available in OPNET,
where the BER (Bit Error Ratio) is dynamically evaluated
based on the mean value of SNR (Signal-to-Noise Ratio). For
the evaluated scenarios the average BER ranges from 10−4 to
10−3 [1].
88
20
DCF
PCF
EDCA
HCCA
15
Average Deadline Misses (%)
20
15
20
Average deadline misses (P = 30ms)
Fig. 4.
10
20
15
DCF
PCF
EDCA
HCCA
20
70
80
20
DCF
PCF
EDCA
HCCA
15
10
5
0
10
20
30
40
50
60
70
80
reduced. In the case of DCF, it only can support up to 6
RT stations (a reduction of ≈ 76% when compared with the
previous result). EDCA and PCF can support only up to 10
and 20 RT stations, respectively. This represents a reduction
of ≈ 67% and ≈ 45% on the EDCA and PCF, respectively.
The supported number of RT stations by HCCA mechanism
remains equal to 2 stations.
For the High network load level (Fig. 4(c)), the DCF is not
able to support any RT stations and the EDCA and PCF can
support up to 3 and 10 RT stations, respectively. As expected,
HCCA was not affected by the increase in the network load.
The results presented when the RT stations have a Pi =
60 milliseconds (Fig. 5) is quite similar to the previous one.
As expected, the number of RT stations supported by each
mechanism increases, as well as the number of the supported
RT stations decreases when the network load imposed by nonRT stations increase. In the Low network load level (Fig. 5(a))
the DCF mechanism can support up to 52 RT stations and the
EDCA and PCF mechanism can be able to support up to 60
and 70 RT stations, respectively. Although again the HCCA
does not miss any deadline, it is penalized by its admission
control mechanism that only allows the admission of 4 RT
stations. Figure 5(c) also illustrates the impact in the number
of supported RT stations when the network load is increased
to the level defined as High, supporting up to 10 RT stations
in the DCF mechanism, and up to 12 and 15 RT stations, in
EDCA and PCF, respectively.
B. Results: Average Delay
Figures 6 and 7 present the average delay (and the respective standard deviation) for different numbers of RT stations
with Pi equal to 30 and 60 milliseconds, respectively. The
results show, as expected, that DCF is not adequate to support
RT traffic under Mid and High load conditions. In both cases
(30 and 60 milliseconds), the average delay and standard deviation significantly increases with the increase in the number
of RT stations. The average delay of EDCA can be considered
quite good since it is below the message deadline threshold,
25
20
15
10
5
0
5
10
15
20
25
30
35
30
25
20
15
10
5
0
40
5
10
60
50
40
20
10
10
20
30
40
50
60
Fig. 7.
25
70
DCF
PCF
EDCA
HCCA
30
0
20
Average delay (P = 60ms)
30
35
30
25
20
15
10
5
0
40
5
10
70
80
50
40
20
10
10
20
30
40
50
60
25
70
30
0
20
30
35
40
70
80
DCF
PCF
EDCA
HCCA
60
15
Average Delay (ms)
Average Delay (ms)
70
15
DCF
PCF
EDCA
HCCA
35
Average delay (P = 30ms)
Fig. 6.
40
DCF
PCF
EDCA
HCCA
35
Average Delay (ms)
30
40
DCF
PCF
EDCA
HCCA
Average Delay (ms)
35
Average Delay (ms)
Average Delay (ms)
40
70
80
DCF
PCF
EDCA
HCCA
60
50
40
30
20
10
0
10
20
30
40
50
60
even for a reasonable number of RT stations (≈ 30 stations).
The trends showed by PCF and HCCA are consequence of
transmissions made on the CFP, that are periodically created
with the transmission of a beacon message. Within this context,
both mechanisms show results around 15 milliseconds (Pi/2).
In the case of PCF, it is possible to verify an increase on the
average delay when the number of RT stations reaches its limit
(Figs. 6(a) and 7(a)).
even more reductions (foreshortened). Furthermore, it was also
observed the increase of the number of cycles where the
CFP was not set. This behavior results from losses of beacon
messages (that are transmitted in broadcast). In the case of
HCCA, although it can support only a reduced number of
RT stations (consequence of rules imposed by its admission
control mechanism), it presented the best behavior under High
network load.
When the network load is increased to the level defined
as Mid (Fig. 6(b)) and High (Fig. 6(c)), DCF suffers a
considerable increase on its average delay. EDCA, PCF and
HCCA follows the same trend of previous results with a
minimal increase on the case of EDCA. The same behavior
can be observed when Pi = 60 milliseconds.
There are many published works addressing the IEEE
802.11 performance, however, most of them consider a closed
environment, which is a basic assumption on the wired CSMA
networks. The timing behavior can be easily guaranteed
through the tight control of every communicating device in
these networks. Unfortunately, this approach cannot be enforced in wireless environments, since all stations share the
access to the same radio channel.
IV. S UMMARY AND S TATE - OF - THE -A RT
The performance assessments show that DCF is the most
susceptible to suffer with changes on network load and with
the increase of the number of RT stations. The main reason
is related with the lack of a mechanism able to increase the
medium access priority of the RT traffic over non-RT traffic.
Another limitation comes from the backoff mechanism, that
under high network loads can lead to long deferring periods.
The efficiency of a differentiation mechanism can be observed
in the EDCA results. By the use of different AC and CWmin
and CWmax values, the EDCA can ensure the lowest average
delay when compared with the remaining mechanisms.
The results presented by PCF and HCCA have quite similar
behavior. This is related with the contention-free medium
access mechanism used by both. As in this case the CFP
were created periodically based on the TBTT (that was defined
as the same duration of Pi ), the average delay value tends
to Pi/2. The main difference is related with the use of CAP
by the HCCA mechanism. The PCF is the mechanism that
supports the highest number of RT stations, that is established
due to the available size of CFP. Moreover, further analysis
shows that with the increase of the network load imposed by
the non-RT stations, the starting instant of each CFP suffers
Numerous attempts were made to analyze the performance
of IEEE 802.11 mechanisms. DCF has been studied using
analytical modeling method based on Markov chain theory
[9], [10], [11]. Bianchi et al [12] developed a two-dimensional
Markov chain model for analysis of the saturation throughput
of the DCF. However, some important performance metrics
such as packet delays or packet drop probabilities were not
estimated in this research. In the case of PCF assessment, the
same analytical approach can be observed [13].
In [14], [15], [16] several authors also analyze the QoS
support of the EDCA mechanism through analytical models.
These models derive an average delay estimation for the
different traffic priorities. It was observed that, even with the
improvements of the EDCA (compared with the DCF), in some
cases it can not ensures the strict QoS requirements of real-time
services such as voice and video traffic. By simulation analysis
[5], [17], [18] confirm this situation. In [5], it was assessed the
EDCA when dealing with RT communications considering an
open communication environment. It was concluded that in
most cases, both the number of message losses and the average
delays forecast an unacceptable number of deadline misses
89
for the RT traffic, even for intermediate network load cases.
Another limitation of EDCA was described by Cena et al. in
[19]. They showed that under high network loads, the EDCA
can suffer priority inversions. This occurs as consequence of
the architecture implemented in the AP by some hardware
companies which, although classifying the messages in four
AC, stores all of them in the same buffer.
The HCCA mechanism was analyzed by [20], [21], [22].
Specifically in [21], Casetti et al. analyze the inefficiency of
HCCA mechanism when it is used to transmit VoIP and a
generic TCP traffic. The main limitation observed was the
difficulty in defining good parameters to CFP.
V. C ONCLUSION
This paper presents a comparative assessment of the
medium access mechanisms defined by the IEEE 802.11 standard when handling real-time traffic in an open communication
environment. The results show that only HCCA preserves
RT traffic requirements, as defined in this paper (periodic
traffic), even in scenarios where external traffic sources impose
a significant network load. However, it is penalized by its
admission control mechanism, that reduces drastically the
maximum number of RT stations that can be admitted. As a
consequence, due to the reduced number of supported stations,
this mechanism is also not adequate for realistic scenarios.
It was observed that DCF, EDCA and PCF suffer with the
increase of network load imposed by non-RT stations and with
the increase of the number of RT stations. In what concerns the
DCF results, a detailed analysis showed that the main reason
of its deadline misses is related with the delivery delay.
In the case of EDCA, its average delay can be considered
quite good since it is well below the message deadline threshold. However, its main limitation is related with exceeding the
retransmission threshold, which results in discarding messages
and consequently in a deadline misses. This behavior is mainly
caused by the transmission of voice traffic by non-RT stations.
An analysis shows that when this traffic is not transmitted
by non-RT stations, the ratio of deadline misses suffers a
reduction. Another limitation of EDCA is related with using
the same buffer to store messages with different priorities.
In this case, when the network load increases, RT traffic
(transmitted by the voice AC) is dropped, since the buffers
of communication devices (mainly the AP) are full.
Finally, in the case of PCF, its main limitations are related
with the loss of the beacon message (preventing the creation
of CFP) and with the increase of foreshortening under high
network loads.
ACKNOWLEDGMENT
This work was partially supported by CNPQ
(485803/2011-9) and FCT (SFRH/BD/48301/2008).
R EFERENCES
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[1]
A. Willig, M. Kubisch, C. Hoene, and A. Wolisz, “Measurements of
a wireless link in an industrial environment using an IEEE 802.11compliant physical layer,” IEEE Transactions on Industrial Electronics,
vol. 49, no. 6, pp. 1265–1282, December 2002.
[2] “IEEE Standard for Information Technology – Telecommunications and
Information Exchange Between Systems Local and Metropolitan Area
Networks – Specific Requirements Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Specifications,” IEEE
Std 802.11–2012 (Revision of IEEE Std 802.11–2007), pp. 1–2793,
2012.
90
[21]
[22]
D. Miorandi, E. Uhlemann, S. Vitturi, and A. Willig, “Guest Editorial:
Special Section on Wireless Technologies in Factory and Industrial
Automation, Part I,” IEEE Transactions on Industrial Informatics,
vol. 3, no. 2, pp. 95–98, 2007.
G. Cena, I. Bertolotti, A. Valenzano, and C. Zunino, “Evaluation
of Response Times in Industrial WLANs,” IEEE Transactions on
Industrial Informatics, vol. 3, no. 3, pp. 191–201, 2007.
R. Moraes, P. Portugal, F. Vasques, and R. F. Custódio, “Assessment of
the IEEE 802.11e EDCA Protocol Limitations when Dealing with RealTime Communication,” EURASIP Journal on Wireless Communications
and Networking, 2010.
N. Ramos, D. Panigrahi, and S. Dey, “Quality of service provisioning in
802.11e networks: challenges, approaches and future directions,” IEEE
Network, vol. 19, no. 4, pp. 14–20, 2005.
OPNET, “OPNET Technologies Inc.” OPNET Technologies Inc.,
February 2013. [Online]. Available: http://www.opnet.com
“IEEE Standard for Information Technology - Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) Specifications: HighSpeed Physical Layer in the 5 GHz Band,” 1999.
S. Kumar, N. Shende, C. R. Murthy, and A. Ayyagari, “Throughput
Analysis of Primary and Secondary Networks in a Shared IEEE 802.11
System,” IEEE Transactions on Wireless Communications, vol. 12,
no. 3, pp. 1006–1017, 2013.
G. Tian and Y.-C. Tian, “Markov Modelling of the IEEE 802.11
DCF for Real-Time Applications with Periodic Traffic,” in 12th IEEE
International Conference on High Performance Computing and Communications (HPCC), 2010, pp. 419–426.
G. Tian, Y.-C. Tian, and C. Fidge, “Performance analysis of IEEE
802.11 DCF based WNCS networks,” in IEEE 35th Conference on
Local Computer Networks (LCN), 2010, pp. 496–503.
G. Bianchi, “Performance analysis of the IEEE 802.11 distributed coordination function,” IEEE Journal on Selected Areas in Communications,
vol. 18, no. 3, pp. 535–547, 2000.
B. Sikdar, “An Analytic Model for the Delay in IEEE 802.11 PCF
MAC-Based Wireless Networks,” IEEE Transactions on Wireless Communications, vol. 6, no. 4, pp. 1542–1550, 2007.
X. Chen, H. Zhai, X. Tian, and Y. Fang, “Supporting QoS in IEEE
802.11e wireless LANs,” IEEE Transactions on Wireless Communications, vol. 5, no. 8, pp. 2217–2227, August 2006.
S. Datta and S. Das, “Performance analysis of real-time traffic in
Wi-Fi networks: A Markov chain-based approach,” in IEEE Wireless
Communications and Networking Conference, 2013, pp. 2102–2107.
Y. Zhao, “Performance analysis for VoIP traffic with limited retransmissions in IEEE 802.11-based wireless networks,” in 8th IEEE International Wireless Communications and Mobile Computing Conference
(IWCMC), 2012, pp. 962–967.
P. Serrano, A. Banchs, P. Patras, and A. Azcorra, “Optimal Configuration of 802.11e EDCA for Real-Time and Data Traffic,” IEEE
Transactions on Vehicular Technology, vol. 59, no. 5, pp. 2511–2528,
2010.
M. Maadani, S. Motamedi, and M. Noshari, “Delay analysis and
improvement of IEEE 802.11e-based Soft-Real-Time Wireless Industrial Networks: Using an open-loop Spatial Multiplexing scheme,”
in International Symposium on Computer Networks and Distributed
Systems (CNDS), 2011, pp. 17–22.
G. Cena, L. Seno, A. Valenzano, and C. Zunino, “On the Performance
of IEEE 802.11e Wireless Infrastructures for Soft-Real-Time Industrial
Applications,” IEEE Transactions on Industrial Informatics, vol. 6,
no. 3, pp. 425–437, 2010.
A. Pastrav, E. Puschita, and T. Palade, “HCCA support in IEEE 802.11
networks QoS and QoE performance evaluation,” in 10th International
Symposium on Electronics and Telecommunications (ISETC), 2012, pp.
139–142.
C. Casetti, C. F. Chiasserini, M. Fiore, and M. Garetto, “Notes on the
Inefficiency of 802.11e HCCA,” in 62nd IEEE Vehicular Technology
Conference (VTC), vol. 4, 2005, pp. 2513–2517.
R. Costa, P. Portugal, F. Vasques, and R. Moraes, “Comparing RT-WiFi
and HCCA approaches to handle real-time traffic in open communication environments,” in IEEE 17th Conference on Emerging Technologies
Factory Automation (ETFA), 2012, pp. 1–8.
Bayesian based selfish aware routing on Delay
Tolerant Networks
Ricardo Oliveira∗ , António Duarte Costa† , Maria João Nicolau‡ and Joaquim Macedo§
Centro Algoritmi, Universidade do Minho, 4710-057 Braga, Portugal
[email protected]∗ , [email protected]† , [email protected]‡ , [email protected]§
Abstract—Delay Tolerant Networks (DTNs) aim to increase
messages delivery ratio in environments where it is not possible to
establish an end-to-end connection. Although the research of new
DTN routing protocols has been gaining some relevance, those
protocols usually assume that nodes in a network will collaborate.
Nodes can behave selfishly, leading to the inappropriate use
of resources, following up the malfunction of the network
environment.
This paper presents an extension based on bayesian game
theory to existing routing protocols. Each node tries to figure
others node’s type using the Naive Bayes classifier and behaves
appropriately in order to achieve optimal results across the
cooperative nodes. The regarded data through the exchangeable
events between nodes can also be used to calculate each node’s
selfishness, assigning the acceptance and respective delivery
probability of a message to its destination. The filter extension
improved the delivery ratio of the cooperative nodes on selfish
networks.
Index Terms—DTN; Selfish Routing Protocols; Selfish Aware
Routing; Bayes Classifier.
I. I NTRODUCTION
Over the past decade, the Internet’s impact on the society
has been increasing to the point of becoming an essential
need for everyone’s day-a-day. With the growing availability
of mobile devices, the costs to maintain and install faster
and broader centralized networks are also increasing [1]. On
the other hand, rural areas, developing countries, military
networks, or even in underwater or interplanetary networks
lack the network infrastructure needed to offer continuous
connectivity [2].
The connection between devices is made through the
TCP/IP protocol which heavily relies in end-to-end and low
delay connections. Those conditions are not always met.
The lack of connectivity, commonly referred as disruption,
may occur due to intermittent connectivity, long or variable
propagation delays, low data rates and high error rates [3].
The high demand and the increasing cost of network structures led to increased interest on Delay Tolerant Networks
(DTNs). These networks main goal is to offer data communication where it was not possible before, but it also improves
communication on centralized networks by diminishing the
infrastructures data load.
Originally called InterPlaNetary (IPN) Internet, DTNs
aimed to improve the interplanetary communication; however,
it was late discovered it is also adaptable to terrestrial networks.
Fig. 1: Representation of the store-carry-forward technique on
DTNs
As referred in multiple sources, [2], [3], DTNs consist in
overlays, known as bundle layer, which operates above any
of the communication protocols. Its mode of operation allows
nodes with different underlying protocols and technologies to
connect with each other. The bundle layer takes advantage of
ad-hoc connections between several devices exchanging message between nodes with the store-carry-forward technique. In
this method, messages are recursively stored and forwarded on
intermediary nodes until eventually reach their destination as
illustrated in Figure 1.
DTNs are a recent case of study and offer several opportunities for research such as more efficient routing protocols,
security and fairness techniques, and data partitioning.
Several sources, [2], [3], [4], group routing protocols in
two large categories: replica based protocols, and knowledge
based protocols. The former ones make several copies of
existing messages and forwards them to reachable nodes, i.e.
flooding protocols. Those protocols are resource demanding
which may lead to several problems. On the other hand, with
the knowledge based protocols the movement of the networked
nodes is predictable or even known, hence the exchanging of
data only to the best known path. To perform the routing, those
protocols require some knowledge of the network topology.
The majority of the routing protocols consider that every
node in a network will behave as expected, but there are
always deviations from users which will try to take advantage
of the protocol and give priority on their messages. Those
nodes can have a selfish or a malicious behavior, leading to the
inappropriate use of energy, memory and network bandwidth,
which gives an unfair advantage to the rest of the nodes [5],
[6], [7]. This incorrect execution of those nodes translates as a
91
•
•
The usage-biased subdomains approach assigns a threshold for a given sender based on how many cumulative
buffer space it used in the past.
The penalty box approach identifies and blocks potential
greedy node from the same domain until the buffer
becomes uncongested.
It assumes cooperative/trusted nodes can be verified and
authenticated by assigned authorities. Trusted nodes do not
change their behavior.
Fig. 2: Representation of selfish nodes on DTNs
B. Evolutionary forwarding games [7]
forced drop-page of unimportant received messages for them
or the broadcast of too many messages to the rest of the nodes.
Those nodes will not relay as expected and will drastically
reduce the delivery ratio of the messages. This behavior is
exemplified in the Figure 2.
This behavior can be controlled with incentive based routing
protocols. In this paper, we propose a new extension based
on bayesian games theory for existent routing protocols. No
information is shared or considered between nodes other than
the known interactions done between them.
This paper is structured as follows. Section II discusses the
several available routing protocols and techniques to increase
the delivery ratio on selfish network environments. Section III
describes relevant considerations used on the design of the
proposed routing protocol as well as the proposed algorithm.
Section IV discusses results and compares routing protocols.
Section V concludes the paper and discusses future work.
Defines the nodes forwarding policies according to the
evolutionary game theory. Its main objective is to make a lower
number of players with variable strategies not as successful
as the rest of the nodes which maintain their strategy. The
decision of the strategy to use with each node is made at the
contact time. There are two modules responsible to calculate
the utility of each one of the nodes: the activation control
(AC), and the live time control (LTC).
•
•
With the AC, during a local interaction between two
nodes, each node can have two different strategies: to
forward or not to forward its message to the destination.
The utility of the nodes which have a forwarding strategy
is calculated in conjunction with the estimation of energy
cost of each message. Nodes with no forwarding strategy
will not be considered.
LTC prioritizes nodes which will keep the messages for
the most of their time to live value.
II. R ELATED W ORK
Selfish nodes can be treated as a requirement, or as a
deviation of the expected typical behavior of the routing
protocol. There are several works which consider the presence
of selfish nodes on DTNs [8], [9], [10], [11]. Nevertheless
the following techniques and routing protocols are the most
relevant for this work.
A. Coarse-Grained priority classes [5]
The goal of this technique is to minimize the effects of
resource hogs originated by greedy nodes. The used approach
only requires local information available within a DTN node.
The buffer management is structured around the concept
of domains, prioritizing domain members to use its buffer
space. A principal is a node or a set of nodes from the same
domain. All messages coming from other nodes are classified
as coming from a different domain.
If the buffer has enough free space it allocates the message,
if not, it drops the message and then rejects them in order
to free space. The technique was further expanded in order
to diminish resources consumption of greedy nodes from the
same domain. Three different methods were tested:
• The equal subdomains approach counts the number of
distinct senders, whose messages currently occupy the
buffer and then assigns a separate dynamic subdomain
for each of them with a threshold.
92
C. RELICS [12]
This module assigns a rank to each one of the known
nodes. It considers that every node behaves selfishly, trying to
spend as less energy as possible but maintaining an acceptable
delivery ratio. As a node relays more messages, its rank gets
higher, and consequently, its messages priority increases on
other nodes. The rank gets lower every time a node creates a
new message. All the nodes involved in the relay of a message
are rewarded.
The more messages a node wants to deliver, the more
messages it needs to relay, consequently, the more resources
it needs to spend. In order to solve this issue, each node
is allowed to set a delivery ratio threshold which is used to
activate its power saving features. A node’s radio is enabled
or disabled if its delivery ratio is higher than the threshold or
not.
D. Discussion
The assumption of trusted information and trusting authorities is unrealistic under the consideration of heavily occupied
and varying scenarios. We propose a new extension which
only considers the node’s observable information about the
networks taxonomy and behaves accordingly with its made
classifications.
III. ROUTING P ROTOCOL
The developed extension is based on game theory mixed
with Naive Bayes classifiers. There is a two tier classification
system. First, it classifies the scenario and then the nodes. In
this section, we start by describing what kind of information
can be considered as trustworthy, following the formulation of
the bayesian game, the classifiers algorithm, and how buffers
and connections are prioritized.
A. Trustworthy Information
Most knowledge based DTN routing protocols rely on
shared information between nodes. On selfish environments,
unless the information is given by a trustworthy node, that
information should not be considered. With this proposed extension, we assume that the privacy and integrity of a message
is assured by end-to-end encryption (by both the message’s
creator and its destination). Since neighboring nodes may only
have access to the source address and destination, they can
not modify the content of the sent messages; otherwise the
destination node can not validate the incoming message and
will discard it. This assumes nodes must share its public keys
on a previously made contact with other ones to be able to
exchange messages with them. With these considerations, it
is then possible to share some statistically events based on
the history of other nodes with both messages’ creator and
destination.
Despite these limitations, there is a considerable number
of variables and events which can effect our knowledge of
the network’s cooperation. Considered outgoing events can be
defined as:
• the number of contacts made by both Host and its
neighbor
• the transmission of a Host’s own message/ACK
• the retransmission of another node’s message/ACK
• the direct delivery of a message/ACK from the Host to
the neighbor
• the number of aborted transmissions
• the number of rejected receptions and their respective
cause (the recipient was busy, the message is old, the
message TTL (Time To Live) has expired, the recipient
has low resources, denied based on a policy, and the
recipient has no free space).
Similar data can be gathered regarding the incoming events
but, the Host needs to consider every previously events to
calculate how believable that data is.
A message and an ACK contain information about the node
for whom the message creator sent the message to and the
relay node who sent the message to the destination. The first
is immediately before the transmission of the message. The
second is in the ACK before being transmitted.
A fully cooperative node can provide information about
all its known nodes. Due to the size that this information
can reach, the number of requests made in an interval of
time must be limited. The information provided by undefined,
cooperative or fully cooperative nodes is always taken into
consideration. Information given by fully cooperative nodes
will be more valuable than the information given by cooperative or undefined nodes.
B. Bayesian games formulation
Cooperation can be stimulated, and disruptive nodes can be
avoided with the application of the Game-Theory.
Game theoretic applications consider every interaction a
player can make, being necessary to specify a set of rules for
each one of the participants, as well as its outcome. There are
a wide number of Game Theory types, and it is necessary to
formulate them carefully for each case, but the common goal
is to achieve fairness according to decision-makers actions.
Those decision-makers, or players, are admittedly rational
and noncooperative, that is, players perform actions which
assure the best outcome for themselves. Those actions are
essentially dependent of the available information from other
players previous actions and its consequences. This set of
information represents a player’s strategy. The player strategies
describe actions made at each stage of the game or associate
probabilities to already known actions based on previous
actions. [7], [13], [14]
Nodes are classified according to the player’s gathered information. Non-cooperative nodes can give erratic information
about their moves; hence the concept of Bayesian games is the
most indicated for this work. Bayesian games considers the
existence of imperfect information. In this case, the imperfect
information is related to the node behavior. In order to know
if a node is cooperative or noncooperative, we must assign
it a type depending of the regarded information. This type is
given probabilistically by an additional player called Nature
(Ω). The rest of the problem is formulated as a normal game.
1) Strategies: In this Bayesian routing algorithm, rational
nodes try to maximize their rank, and therefore, maximize the
number of relayed messages across the network. In order to
do this, the host will need to choose one of the four different
strategies at every contact:
• S1: receive node Ni (Node i) message and send Host’s
message;
• S2: receive node Ni message and do not send Host’s
message;
• S3: do not receive Ni ’s message and send Host’s message;
• S4: do not receive Ni ’s message and do not send Host’s
message.
2) Delivery probability and classification assignment: The
Nature (Ω) of the Hosts game with Ni is given by the
computation of the Cooperation Probability for Ni . In the very
first contact with Ni , this value is 0.5 by default, hence the
undefined classification. This value will increase and decrease
as the Host, and Ni classification is changed along the game.
Given that the proposed protocol attempts to improve efficiency in routing messages on selfish networks, it is also
necessary to take into consideration the quality of information
provided by other network nodes and the information that
each node can infer about the other. Thus, in this protocol
a node only uses the network information provided by other
nodes when they are considered fully cooperative. The delivery
93
probability and the node classification of the remaining nodes
are deduced with the exchange of messages. Some actions
contribute positively, whereas others have a negative effect on
both probabilities and classifications.
The information that contributes positively to the calculation
of the delivery probability is deduced by:
• The number of messages relayed or delivered;
• The number of confirmation messages relayed or delivered.
The information that negatively contributes to calculate the
delivery probability is deduced by:
• The number of aborted or denied messages;
• The number of messages sent.
However, the number of sent and rejected messages will
only effect the nodes classification if they are higher than the
threshold defined by the current scenario.
The bayesian game utility function is based on the following
formulations:
P C newi = P C oldi − (P C oldi ) ∗ Pi ter
(1)
P C newi = P C oldi + (1 − P C oldi ) ∗ Pi ter
(2)
Where P C newi is the new cooperation predictability of
node Ni and P C oldi is node Ni old cooperation predictability. Pi ter is a static value used to calculate new probabilities.
The lower it is, the slower it converges into the correct type,
but the more reliable it is. Ranges between 0.0 and 1.0.
•
Fully Cooperative nodes accept most of the sent messages, generally deliver messages to the Host and have
a low drop probability. Their classification is attributed
only after a long set of positive classifications.
The classifiers take into consideration every type of event
occurred in the exchange of data between nodes and consider
the number of historic classifications.
Routing protocols where each message receives a delivery
confirmation benefit for having a more assertive node’s classification, but there is a bigger exchange of messages which
decreases the buffer’s capability.
D. Extended Buffer management
The messages stored in the buffer commonly have a FIFO
order, which leads to the removal of the older messages when a
new one is received. However, in this extension, the messages
order is affected by both protocol ordering algorithm and the
owner classification.
The Epidemic, Spray and Wait [16], and Prophet [17]
routing protocols are common examples where messages are
ordered in the same order as they are received. With our
approach, messages are prioritized upwardly by a custom TTL
assigned by the function:
Cooperation Index ∗ M essage0 s T T L.
(3)
C. Classifiers
E. Extended connection list
As previously mentioned, the proposed algorithm uses two
different Naive Bayes classifiers, more precisely, the Updateable Naive Bayes Classifier [15]. This specific version of
the classifier enables the continuously change/increase of the
classifiers training set, which makes the training set moldable
with varying scenarios.
The host performs an action depending on the type associated to each one of the known nodes. When a new node is
discovered, it is assigned the undefined type. This classification
is maintained for a previously defined number of outgoing and
incoming events (e.g. When the number of outgoing events or
the number of incoming events is bigger than 30). Thereafter,
a node’s classification is recalculated at every new operation
performed with a node.
A node can be classified as malicious, noncooperative,
undefined, cooperative and fully cooperative:
• Malicious nodes are statically defined as identities who
may drop, reject, or abort around 90% of the received
messages, and broadcast all of it is messages.
• Noncooperative nodes are statically defined as identities
who may drop, reject, or abort around 75% of the
received messages.
• Undefined nodes are nodes which have around 50% of
aborting messages. This could be caused by interference
on the transmission of messages.
• Cooperative nodes accept around 75% of the sent messages and generally deliver messages to the Host.
The list of outgoing messages are commonly ordered according to the specific routing protocol mechanics. In this
extension, the sender’s cooperation probability affects the
message’s order.
By default, messages are sent to every connection in the
same order we have made a contact. This is the case of the
Epidemic, and the Spray and Wait routing protocol. The list
of connections is sorted with our extension, giving priority to
the most cooperative routing protocols over the least.
Prophet sorts the connection list by delivery probability. Our
sorting algorithm multiplies the delivery probability with the
assigned Cooperation Index.
94
IV. S IMULATION AND RESULTS
We have implemented and tested the extension on the well
known Prophet routing protocol.
To test and evaluate this technique, we have carried several
simulations with The ONE [18] simulator. The ONE is a
complete, and commonly used framework to implement and
evaluate DTN protocols. It is an open source Java solution,
easily extensive, that supports mobility, event generation and
message exchange. It includes DTN routing and application
protocols and a basic notion of energy consumption. Visualization and analysis interfaces are also provided for importing and
exporting mobility traces, events, and even entire messages.
Fig. 3: Delivery probability in a 12 hours simulation
A. Scenario description
The proposed extension was evaluated in a scenario with
similar specifications with the default one. It has a total
number of 150 nodes (both cooperative and selfish). While
selfish nodes only accept the reception of packets created by
other selfish nodes, dismissing and dropping the reception and
forwarding from cooperative nodes, cooperative nodes send
and receive packets from any node.
The cooperative nodes use the proposed extension which
classifies the nodes and decreases the priority in receiving
and sending packets originally sent by selfish nodes. Messages
from selfish also have a lower TTL.
Both type of nodes moved randomly through the default
paths of the The ONE’s default scenario.
Each simulation was executed with 30 different seeds. For
each simulation i, there are 150 − 15i cooperative nodes
and 15i selfish nodes. The first simulation started with 150
cooperative nodes and 0 selfish nodes, whereas the last one
had 0 cooperative nodes and 150 selfish.
Each scenary simulated the interaction of nodes for 6, 12,
and 18 hours.
B. Evaluation
The delivery probability refers to the probability of a message being delivered from a certain kind of nodes. Although
selfish nodes always maintain a higher probability of delivery
in comparison to the cooperative nodes, using the strategy
proposed, the benefit of the selfish nodes is not as evident.
However, it is apparent that the probability of delivering by
cooperative nodes (with and without strategy) decreases with
the increasing of the quantity of selfish nodes in the network.
This is because the number of nodes ready to relay cooperative
messages becomes lower.
As can be seen, when the number of selfish nodes is 0,
the probability of message delivery from this type of nodes is
approximately 40%, while when the number of selfish nodes is
about half of the total number of existing nodes in the network,
the probability delivery is also about 20%.
Since selfish nodes only receive packets from other selfish
nodes, as the number of selfish nodes increase, the number of
delivery messages tends to resemble the number of messages
delivered by the cooperative nodes when the number of selfish
nodes is 0. These results are expected because selfish nodes
treat selfish said messages in the same way that we deal with
cooperative messages from other nodes.
Node type
SE
S
CE
C
6 hours
0.4
0.43
0.18
0.11
12 hours
0.5
0.52
0.22
0.11
18 hours
0.53
0.55
0.25
0.11
TABLE I: Delivery probabilities with and without extension
filter
Table I represents the delivery probabilities of 75 Selfish,
and 75 Cooperative nodes with and without the filter extension. SE and S stand for Selfish with Extension nodes and
Selfish nodes, whereas CE and C stand for Cooperative with
Extension nodes and Cooperative nodes.
As it can be easily noticed, Cooperative nodes in presence
of Selfish nodes maintain a delivery probability of 11% as
the time goes one, because they don’t have any way to
distinguish or filter the good from the bad behaving nodes,
whereas Cooperative nodes with the Filter Extension begin
to distinguish the type nodes, and start to prioritize their
messages accordingly.
95
V. D ISCUSSION
Cooperative nodes which used the filter extension improved
their delivery ratio, but the selfish nodes maintained their
dominance. We expect to test the proposed filter on other
routing protocols and to increase the aggressiveness of the
extension so that selfish node’s delivery ratio starts decreasing.
Furthermore, for constantly varying scenarios we plan to
propose a new classifier which classifies a scenario according
to previously similar history of events with similar delivery,
contact and proximity ratios. At the beginning of the simulation, the set of scenario classifiers is empty, but, every n
minutes, the current scenario information is recorded as well
as the nodes classifications, making a new node’s training set
associated with the newly created scenario training set.
After the creation of a training set, when the next scenario
starts, it uses the previously used classifier for 5 minutes
(static defined variable), and then it finds the best match of the
scenario it’s associated node’s training set. The finding would
be made based on the information saved in the scenario’s
training phase.
A PPENDIX A
N OTATION
Follows the notation and the meaning of the symbols used
through the paper.
A. Players
•
•
Host : The node which is choosing the strategy.
Ni : The i node contacted in the network.
B. Bayesian Game symbols
•
•
•
•
•
•
•
Ω: Nature of the game.
N payof fi j: Ni s payoff for doing j strategy.
Hpayof fj : Hosts payoff for doing j strategy.
P C defi : Ni s default cooperation predictability.
P C newi : Ni s new cooperation predictability.
P C oldi : Ni s old cooperation predictability.
Pi ter: Static value used to calculate new probabilities.
The lower it is, the slower it converges into the correct
type, but the more reliable it is. Ranges between 0.0 and
1.0.
[3] F. Warthman, V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R. Durst,
K. Scott, K. Fall, H. Weiss, D.-t. N. Architecture, and et al., “Delaytolerant networks ( dtns ),” Networks, no. March, 2003.
[4] S. Ali, J. Qadir, and A. Baig, “Routing protocols in delay tolerant
networks – a survey,” Knowledge Creation Diffusion Utilization, pp.
70–75, 2010.
[5] J. Solis, N. Asokan, K. Kostiainen, P. Ginzboorg, and J. Ott, “Controlling
resource hogs in mobile delay-tolerant networks,” Computer Communications, vol. 33, no. 1, pp. 2–10, 2010.
[6] Q. Li, S. Zhu, and G. Cao, “Routing in socially selfish delay tolerant
networks,” 2010 Proceedings IEEE INFOCOM, pp. 1–9, 2010.
[7] R. El-azouzi, F. D. Pellegrini, and V. Kamble, Evolutionary forwarding
games in Delay Tolerant Networks. IEEE, 2010, pp. 76–84.
[8] A. J. Mashhadi, S. B. Mokhtar, and L. Capra, “Habit: Leveraging human
mobility and social network for efficient content dissemination in delay
tolerant networks,” Building, pp. 1–6, 2009.
[9] L. Yin, H.-m. Lu, Y.-d. Cao, and J.-m. Gao, “Cooperation in delay tolerant networks,” Signal Processing Systems ICSPS 2010 2nd International
Conference on, vol. 1, p. V1–202, 2010.
[10] U. Shevade and Y. Zhang, “Incentive-aware routing in dtns,” 2008 IEEE
International Conference on Network Protocols, pp. 238–247, 2008.
[11] R. L. R. Lu, X. L. X. Lin, H. Z. H. Zhu, X. S. X. Shen, and B. Preiss, “Pi:
A practical incentive protocol for delay tolerant networks,” pp. 1483–
1493, 2010.
[12] Y. S. Uddin, B. Godfrey, and T. Abdelzaher, “Relics : In-network
realization of incentives to combat selfishness in dtns,” 2010 18th IEEE
International Conference on Network Protocols ICNP, pp. 203–212,
2010.
[13] S. Keshav, “Mathematical foundations of computer networking,” Society,
pp. 177–202, 2005.
[14] S. Heap and Y. Varoufakis, Game Theory: A Critical Introduction.
Routledge, 1995.
[15] G. H. John and P. Langley, “Estimating continuous distributions in
bayesian classifiers,” in Eleventh Conference on Uncertainty in Artificial
Intelligence. San Mateo: Morgan Kaufmann, 1995, pp. 338–345.
[16] T. Spyropoulos, K. Psounis, and C. S. Raghavendra, “Spray and wait: an
efficient routing scheme for intermittently connected mobile networks,”
in Proceedings of the 2005 ACM SIGCOMM workshop on Delaytolerant networking, ser. WDTN ’05. ACM, 2005, pp. 252–259.
[17] A. Lindgren, A. Doria, and O. Schelén, “Probabilistic routing in intermittently connected networks,” SIGMOBILE Mob. Comput. Commun.
Rev., vol. 7, no. 3, pp. 19–20, Jul. 2003.
[18] A. Keränen, J. Ott, and T. Kärkkäinen, “The ONE simulator for DTN
protocol evaluation,” Proceedings of the Second International ICST
Conference on Simulation Tools and Techniques, 2009.
ACKNOWLEDGMENT
This work is partially funded by FEDER Funds through the
Programa Operacional Fatores de Competitividade – COMPETE and by National Funds through the FCT - Fundação
para a Ciência e a Tecnologia (Portuguese Foundation for
Science and Technology) within project FCOMP-01-0124FEDER-022674
R EFERENCES
[1] G. Trecarichi, V. Rizzi, L. Vaccari, M. Marchese, and P. Besana, “Openknowledge at work: exploring centralized and decentralized information
gathering in emergency contexts,” Crisis, no. January, 2009.
[2] V. Venkataraman, H. B. Acharya, H. Shah, and S. Lam, “Delay tolerant
networking - a tutorial,” SciencesNew York, 2009.
96
Recolha e Análise de Dados de Contactos Físicos e Sociais
numa Rede Tolerante a Atrasos
João Antunes*, António Costa+, Joaquim Macedo^
Centro Algoritmi
Braga, Portugal 4710-057
* Email: [email protected]
+ Email: [email protected]
^ Email: [email protected]
Resumo—As redes tolerantes a atrasos surgiram com o
propósito de abordar o problema de comunicação em redes onde
a ligação é intermitente e feita através de contactos oportunistas.
Um caso particular destas redes são aquelas em que os nós são
dispositivos transportados por pessoas, as Pocket Switch
Networks. A relação social entre os nós tem sido recentemente
explorada na decisão de encaminhamento neste tipo de redes.
Neste trabalho, foi concebido um sistema de recolha de dados
dos contactos físicos e sociais numa RTA com o objetivo de
avaliar uma nova métrica social a ser usada na decisão de
encaminhamento.
Palavras-chave— Redes Tolerantes a Atrasos, Sistema de
Recolha, Datasets, Pocket Switch Networks, Redes Sociais.
I. INTRODUÇÃO
O enorme sucesso da Internet nas últimas três décadas
deve-se ao uso de protocolos denominados TCP/IP, pois estes
garantem a flexibilidade, eficiência e robustez, que lhe
permitem suportar diversas aplicações em diferentes cenários.
No entanto, em cenários com longos atrasos e conexões
intermitentes, os protocolos TCP/IP não funcionam e é
necessário a criação de novos protocolos. Redes com estas
características específicas são denominadas Redes Tolerantes a
Atrasos (RTAs), e um dos seus principais desafios é o
encaminhamento, pois é necessário determinar rotas sem o
conhecimento da existência de um caminho fim-a-fim[1].
Para contornar os problemas de atrasos longos e conexões
intermitentes, as RTAs usam técnicas de troca de mensagens e
armazenamento de dados. Quando uma mensagem precisa de
ser enviada, ela é armazenada e encaminhada nó a nó desde a
origem até o destino, ou seja, são redes do tipo store-andforward: a mensagem é recebida integralmente e armazenada,
para depois ser enviada ao próximo nó, que pode ou não ser o
nó destino[2].
Um dos tipos de RTAs mais usuais são as chamadas Pocket
Switched Networks (PSNs), que consistem em contactos
oportunistas entre os nós da rede. Estes nós encontram-se em
constante movimento e nem sempre estão conectados à rede,
Este trabalho é financiado por Fundos FEDER através do Programa
Operacional Fatores de Competitividade – COMPETE e por Fundos
Nacionais através da FCT – Fundação para a Ciência e Tecnologia no
âmbito do Projeto: FCOMP-01-0124-FEDER-022674 .
visto serem controlados diretamente por seres humanos,
através de smartphones, computadores portáteis, etc.[3].
Tendo em conta que os nós das redes dependem de fatores
humanos, os protocolos de encaminhamento para este tipo de
redes podem basear-se em dois campos: o campo físico, que
consiste no histórico de contactos1 entre os nós da rede; e o
campo social que consiste na relação social entre os mesmos.
Existem atualmente alguns estudos sobre a relação entre o
grafo social e o grafo de contactos físicos[4],[5], no entanto, o
propósito final deste trabalho científico é verificar a validade
da inclusão na decisão de encaminhamento de uma métrica que
relaciona o campo social e o histórico de contactos físicos.
Para obter a relação social entre os nós, podemos utilizar as
redes sociais existentes na Internet, como o Facebook, o
Twitter ou o MySpace. Estas redes são utilizadas regularmente
por milhões de pessoas em todo o mundo e permitem obter
dados da vida social de cada um.
Este trabalho propõe um sistema baseado no conceito
Cliente-Servidor para criação de uma RTA através da qual se
pretende obter os dados do histórico de contactos entre os nós e
a relação social entre eles, para posterior construção e análise
de um grafo que relacione estes dados. Para isso, o trabalho irá
consistir em três partes distintas: uma aplicação em Android
instalada em cada nó da RTA, responsável pela obtenção do
histórico dos contactos físicos entre os nós e de um perfil social
de cada nó enviando a informação obtida para o servidor; um
servidor responsável por receber dados dos nós da rede e pela
construção de um grafo que relacione o histórico de contactos
entre os nós e a relação social entre eles; um sistema de análise
do grafo construído no servidor que permita obter resultados
acerca do relacionamento entre o histórico de contactos e os
dados sociais entre os nós numa RTA.
1
Um contacto é o encontro entre dois nós da rede, ou seja,
quando um nó se encontra ao alcance de outro nó de modo a
que estes possam comunicar
97
II. ESTADO DA ARTE
III. SISTEMA DE RECOLHA E ANÁLISE DE DADOS
Podemos dividir os protocolos em RTAs em dois tipos
distintos: protocolos baseados em redes onde existem
infraestruturas e protocolos baseados em redes puramente
móveis. Este último tipo de redes pode também ser dividido em
dois tipos: protocolos dissemination-based e context-based. A
diferença entre estes dois tipos consiste na falta de informação
de contexto no encaminhamento de mensagens entre os nós da
rede nos protocolos dissemination-based, enquanto que os
protocolos
context-based
baseiam
a
decisão
de
encaminhamento de dados numa informação de contexto que
pode incluir dados relativos ao histórico de contactos entre os
nós ou da relação social entre eles, ou mesmo uma junção entre
estes dois campos.
Nos protocolos dissemination-based podemos incluir o
Epidemic Routing[6]. Este protocolo consiste na distribuição
das mensagens pela rede de uma forma epidémica, isto é, a
cada novo contato entre dois nós da rede existe uma troca de
informações entre os nós de modo a que cada nó receba as
mensagens que ainda não tenha guardado. Desta forma, as
mensagens são rapidamente distribuídas entre duas porções de
rede que estejam próximas uma da outra contando para isso
com a mobilidade dos nós. Este protocolo garante uma
probabilidade elevada na entrega de mensagens, contudo,
sobrecarrega a rede devido à falta de informação de contexto e
consome demasiados recursos aos nós da rede. Para contrariar
a sobrecarga da rede e dos nós, posteriores versões deste
protocolo incluíram um número limite de saltos e de cópias das
mensagens presentes na rede.
Dentro dos protocolos context-based incluem-se o
PROPHET[7], o SimBet[8], o FairRouting[9], o
BubbleRap[10] e o PeopleRank[11]. Cada um destes
protocolos utiliza uma informação de contexto na decisão de
encaminhamento de mensagens entre os nós da rede, sendo que
a diferença entre eles está na natureza dessa informação. O
PROPHET baseia-se unicamente no histórico de contactos
entre os nós e na transitividade na decisão de encaminhamento,
isto é, se dois nós se encontrarem regularmente, têm maior
probabilidade de entregar uma mensagem um ao outro do que
dois nós que raramente se encontrem. O SimBet inclui na sua
informação de contexto a centralidade do nó da rede, a
similaridade dos nós e a força das ligações entre eles. A
informação de contexto no FairRouting inclui a força de
interação e o grau de assortativeness (pessoas com os mesmos
interesses tendem a encontrar-se mais vezes). Já o BubbleRap
utiliza a divisão dos nós em comunidades e a centralidade de
cada um deles na decisão de encaminhamento. Por fim, o
PeopleRank utiliza a relação social entre os nós da rede como
informação de contexto.
Em relação á comunicação entre os nós existe um consenso
em torno de um protocolo experimental que é usado na troca de
mensagens numa rede RTA, o Bundle Protocol RFC 5050[12]
que pode ser usado como suporte em todos os protocolos de
encaminhamento. Este protocolo foi elaborado pelo IRTF´s
Delay Tolerant Networking Research Group (DTNRG), e
divide blocos de dados em pacotes, transmitindo-os, usando
um mecanismo de store-and-forward.
No sistema desenvolvido foi necessário definir algumas
questões como a forma de comunicação entre os nós da rede, o
tipo de base de dados utilizada pelo servidor para construir o
grafo e a forma de criar o perfil social de cada nó.
98
A. Comunicação entre os nós da rede
No que concerne a comunicação entre os nós da rede,
foram estudadas algumas hipóteses: Bluetooth, infravermelhos,
redes ad-hoc Wi-Fi, redes Wi-Fi e redes celulares.
Destas cinco possíveis formas de comunicação, três delas
foram automaticamente excluídas por razões distintas. Os
infravermelhos foram rejeitados por serem uma tecnologia em
decadência, visto já não existirem na maioria dos dispositivos
tecnológicos. As redes celulares GSM ou UMTS por terem um
custo associado na troca de mensagens não foram
consideradas. E por fim, as redes Wi-Fi foram excluídas devido
à necessidade de usarem pontos de acesso, o que não permite a
possibilidade de comunicação a qualquer momento, um aspeto
crucial na rede criada.
Restam duas tecnologias: o Bluetooth e as redes ad-hoc WiFi. A escolha recaiu sobre o Bluetooth, visto que esta
tecnologia requer um consumo de energia menor que a
utilização do Wi-Fi[13] em dispositivos móveis. Por outro lado
a tecnologia ad-hoc Wi-Fi só está acessível em versões mais
recentes do sistema operativo Android.
Independentemente da tecnologia utilizada como forma de
comunicação entre os nós deve ser possível retirar informação
acerca de cada contacto entre dois nós. Todos os dados
interessantes passíveis de serem retirados de um contato físico
entre dois nós são: a identificação dos sujeitos (endereço
MAC); a duração do contacto; o instante de início do contacto;
a localização geográfica de onde ocorreu o contacto; e o nível
de energia e de memória de cada nó;
Depois de analisados estes pontos, concluiu-se que alguns
campos poderiam ser dispensados. Entre eles, a localização
geográfica de onde ocorreu o contacto, que é desnecessário
pois requer o uso de tecnologias que iriam consumir mais
recursos aos nós da rede. Também, o nível de energia e de
memória de cada nó considera-se dispensável, pois não
acrescenta informação quanto à força da ligação entre os nós,
sendo que estes valores só são importantes quando tratamos de
RTA com nós egoístas.
B. Registo do Histórico de Interações
Para o desenvolvimento deste projeto, é necessária a
construção de uma base de dados pelo servidor de forma a
guardar os dados de contactos físicos entre os nós da rede e o
perfil social desses mesmos nós. Para esse efeito, foi necessário
escolher um tipo de base de dados, sendo que essa escolha
poderia recorrer sobre uma base de dados relacional (SQL) ou
uma base de dados não relacional (NoSQL).
Visto que, para este projeto, o que se pretende guardar são
dados obtidos de uma rede, o tipo de base de dados mais
indicado seria uma base de dados não relacional, ou seja, a
base de dados NoSQL.
O termo NoSQL (Not only SQL) refere-se a uma classe de
base de dados não relacional, acabando, desta forma, com o
uso exclusivo de bases de dados relacionais. A principal razão
do aparecimento deste tipo de base de dados deve-se à
necessidade crescente de obter maior escalabilidade no
armazenamento de dados. As bases de dados relacionais
também promovem escalabilidade, no entanto, quanto maior
for o tamanho dos dados, mais custosa se torna a
escalabilidade, seja pelo custo de novas máquinas ou pela
manutenção de especialistas no local onde se encontram as
bases de dados. Por esta razão, foram criadas as bases de dados
não relacionais NoSQL, que permitem uma escalabilidade mais
barata e menos trabalhosa, visto não necessitarem de máquinas
muito poderosas e a sua manutenção ser simples, permitindo
assim reduzir o número de profissionais necessários.
Existem alguns tipos de bases de dados não relacionais:
bases de dados chave/valor, bases de dados orientados a
documentos e bases de dados de grafos. Enquanto o primeiro e
segundo tipo não são indicados para usar com grafos, o último
tipo de bases de dados é bastante compatível com o nosso caso
já que estamos a tratar de redes que, por sua vez, podem ser
representadas por grafos[14]. A ideia deste modelo é
representar os dados como grafos dirigidos. Este tipo de
modelo funciona melhor quando se pretende dar mais
relevância à conectividade ou à topologia dos dados que aos
dados propriamente ditos. É constituído por três elementos
básicos: os nós (vértices do grafo), as relações (as arestas) e as
propriedades dos nós e das relações. Algumas das bases de
dados que utilizam o modelo de grafos são: Neo4j, Infinite
Graph, InforGrid, HyperGraphDB, etc. No âmbito deste
projeto, vai ser utilizada a base de dados Neo4j que está
desenhada para ser usada na linguagem de programação Java.
Esta base de dados foi criada pela Neo Technology e o seu uso
é bastante fácil e intuitivo, proporcionando uma forma eficaz
de representar bases de dados por grafos e dando a
possibilidade de atribuir, de uma forma simples, atributos tanto
aos nós do grafo, como às ligações entre eles.
C. Obtenção do Perfil Social
Uma premissa para a realização deste trabalho foi recolher
o perfil social de um grupo de pessoas (os utilizadores da
aplicação) para posteriormente construir um grafo social. De
forma a recolher estes dados, decidiu-se utilizar as redes
sociais, visto estarem muito em voga na atualidade. Entre elas,
as mais conhecidas e as mais utilizadas são: o Facebook, o
Twitter, o MySpace e o Linkedin.
O Facebook é a rede social online mais utilizada no mundo
inteiro, por ser gratuita, de interesse generalizado e simples de
usar. Nesta rede social, cada utilizador tem um perfil com a sua
informação pessoal, lista de interesses, fotos e uma lista de
amigos. Os utilizadores podem trocar mensagens privadas e
públicas entre si. Cada pessoa tem um mural onde os seus
amigos podem colocar publicações (frases, fotografias, vídeos,
etc.) e que pode ser acedido por todos os utilizadores da rede,
ou não, dependendo da privacidade definida pelo próprio
utilizador. Este tem, também, a possibilidade de criar ou aderir
a grupos restritos, identificar amigos em publicações ou fotos,
criar publicações no seu próprio mural e “gostar” de
publicações. A página principal do Facebook é o feed de
notícias onde o utilizador pode ver a atividade recente dos seus
amigos e notícias dos seus grupos e das páginas de que gosta.
Como já foi referido antes, retirou-se o perfil social dos nós
da rede através do Facebook, visto ser a rede social online com
mais utilizadores [15]. Como a aplicação está feita em
programação Android, utilizou-se a ferramenta Facebook SDK
integrada no eclipse. Esta ferramenta permite aceder de uma
forma simples ao Graph API do Facebook através do qual
podemos ler e escrever dados. Todos os dados relevantes
passíveis de serem retirados do Facebook são: identificação do
utilizador (nome e id); lista de amigos; lista de interesses; lista
de familiares; localização; número de identificações em
fotos/posts de amigos; número de feeds/mensagens trocadas
com amigos.
Tendo em conta que o Facebook SDK tem algumas
limitações na recolha de dados, e visto que se pretende
preservar a máxima privacidade possível do utilizador, decidiuse prescindir de obter os dois últimos campos, ou seja, o
número de identificações em fotos/posts de amigos e o número
de feeds/mensagens trocadas com amigos.
IV. ARQUITETURA
O sistema construído para a recolha de dados e construção
de grafos sociais e de contactos físicos numa rede RTA, dividese em dois componentes: os nós da rede e o servidor. Os nós da
rede serão responsáveis por recolher os dados de contactos
físicos entre eles e de obter o seu perfil social, enviando a
informação obtida para o servidor. O servidor é responsável
por receber os dados dos nós e construir um grafo que
relacione o histórico de contactos entre os nós e o seu perfil
social.
Os nós da rede serão simulados por utilizadores que terão
instalado nos seus dispositivos móveis uma aplicação com as
seguintes responsabilidades: definir um protocolo de
comunicação para verificar a existência de contactos entre
utilizadores; guardar em cache o histórico de contactos até
obter acesso ao servidor; enviar o histórico de contactos ao
servidor; obter o perfil social do utilizador; enviar o perfil
social do utilizador para o servidor; e oferecer segurança na
troca de dados.
O servidor é uma aplicação desenvolvida em Java que deve
estar registada na internet para poder comunicar com os
clientes. O servidor tem a responsabilidade de: permitir a
ligação dos nós da rede através da internet; receber o perfil
social e o histórico de contactos dos nós da rede; permitir
adicionar e remover novos nós; construir um grafo que
relacione o histórico de contactos entre os nós e a sua relação
social. Na figura 1, podemos ver a arquitetura global do
sistema. Na figura 2 podemos observar os módulos da
aplicação e as interações entre estes.
A. Nó da rede
Para a realização deste projeto é necessário obter
autorização de um grupo de pessoas para ter acesso ao seu
perfil social e ao histórico dos contactos físicos existentes entre
eles. Para conseguir essa autorização, decidiu-se criar um
incentivo para que as pessoas aceitassem entregar os seus
99
dados - o acesso gratuito a uma aplicação denominada de
SocialConnector. A aplicação está disponível para telemóveis
com o sistema operativo Android e funcionará como um nó da
rede RTA.
Depois de um estudo que visou a escolha de uma aplicação
que fizesse com que várias pessoas instalassem a aplicação,
decidiu-se que a SocialConnector iria consistir no seguinte:
uma aplicação que nos mostra os interesses das pessoas que
estão ao nosso lado, e que tenham a aplicação instalada, em
qualquer local onde nos encontremos. A aplicação funciona à
base de avisos, ou seja, quando descobrir alguém na mesma
zona que tenha a aplicação instalada, notifica o utilizador da
descoberta dessa pessoa, bem como do seu perfil social. Os
interesses dos utilizadores são obtidos através do Facebook e
são atualizados regularmente. A comunicação entre os
utilizadores será feita por Bluetooth. Estando ligada a aplicação
pode funcionar em três modos diferentes: modo normal, modo
egoísta ou modo social. No modo normal, a aplicação tanto
está à procura de novos dispositivos para receber os seus perfis,
como torna o seu dispositivo visível disponibilizando-se para
entregar o seu perfil ao nó encontrado. No modo egoísta, a
aplicação só procura novos utilizadores para obtenção de novos
perfis não se tornando visível para os outros nós e não
permitindo, assim, enviar o seu perfil a novos utilizadores. No
modo social, a aplicação torna-se visível para os outros nós da
rede, enviando para estes o seu perfil, mas não procura novos
dispositivos para receber perfis. A atratividade desta aplicação
encontra-se no facto de ajudar as pessoas a socializar, pois
permite aos utilizadores poderem descobrir os interesses de
uma pessoa desconhecida, facilitando, assim, o início de uma
conversa casual e, possivelmente, uma nova amizade.
A aplicação SocialConnector está dividida em 6 módulos
distintos, cada um com a sua responsabilidade:
•
Ligação ao Facebook: responsável por aceder à rede
social e retirar os dados desejados, criando o perfil social.
•
Gestor de perfil: responsável por gerir o perfil do
utilizador, ou seja, definir o que o utilizador pretende partilhar
com os outros. Ao recolher os dados do Facebook, o utilizador
deverá criar um perfil social onde irá constar a sua informação
retirada do Facebook para partilhar com os outros utilizadores.
Devido a questões de privacidade, na aplicação deverá ser
permitido ao utilizador escolher que dados do seu perfil
pretende partilhar com os outros dispositivos, sendo possível
esconder alguns dos seus interesses ou dos seus amigos. Os
dados que constam no perfil social são: o nome, a idade, a lista
de interesses, a lista de amigos e a localização.
•
Comunicação entre nós: responsável por definir e
estabelecer o protocolo de comunicação, aquando do encontro
entre dois nós. A aplicação deve permitir procurar novos
dispositivos, ao mesmo tempo que permite ao nó ficar visível
para outros. A comunicação funciona da seguinte forma: se um
nó A encontrar um nó B, ou vice-versa, depois de verificar se o
nó B tem a aplicação instalada e a funcionar no modo normal
ou social, o nó A pede uma parte do perfil do nó B, com o seu
nome, idade e localização. Depois de receber esses primeiros
dados, o nó B deve decidir se pretende pedir o resto do perfil
social, e caso o pretenda deve pedi-lo ao nó B. O nó B deve dar
Figura 1 - Arquitetura do sistema
permissão para enviar o resto do perfil social. Caso o utilizador
B permita o envio do perfil, é enviado para o nó A a totalidade
do seu perfil: a sua foto, a sua lista de interesses e a lista de
amigos (Figura 3). Os utilizadores devem guardar todos os
perfis acedidos recentemente até ter acesso ao servidor.
Aquando de um novo encontro, e depois da partilha de perfis
entre si, os nós devem comunicar e, caso pretendam, devem
enviar a lista de perfis encontrada recentemente, desta forma,
contrariar o limite de alcance do Bluetooth, utilizando a
transitividade na partilha de perfis.
•
Armazenamento de dados: responsável por guardar
temporariamente o histórico de contactos do nó e
permanentemente o perfil social do utilizador.
•
Segurança e privacidade: responsável por garantir a
segurança na partilha de informação entre utilizadores e a
privacidade dos mesmos. Para isso, é usada uma ligação
RFCOMM segura com registo do serviço Bluetooth, sendo
todos os identificadores sumariados com uma função de hash
na comunicação entre nós e na ligação com o servidor.
•
Ligação ao servidor: responsável por estabelecer a
ligação ao servidor para o envio de dados. Cada vez que um nó
acede à aplicação, verifica se tem acesso à internet, e, se tal for
o caso, envia o seu histórico de contactos para o servidor,
apagando-os da memória local. Na primeira ligação e quando
houver uma atualização do perfil, o nó também envia uma
mensagem para o servidor com o seu perfil social.
Figura 2 - Esquema SocialConnector
100
TABELA 1. DATASET SIGCOMM09
Número de participantes
76
Duração da experiência
5 Dias
Total de interesses
711
Encontros entre os nós
285879
Média contactos por nó
≃ 3762
Média interesses por nó
≃ 12
Média amizades por nó
≃4
definir um mecanismo de segurança que permita garantir a
privacidade dos utilizadores na apresentação dos dados, isto é,
não deve mostrar o nome do utilizador nem o seu perfil social,
mas sim identificar esses dados por identificadores já
sumariados nos clientes.
V. DISCUSSÃO E AVALIAÇÃO DO SISTEMA
Figura 3 - Comunicação entre dois nós
B. Servidor
O servidor irá ser desenvolvido em Java e está dividido em
cinco módulos:
•
Registo na internet: responsável por colocar o servidor
disponível na internet, de modo a que esteja acessível aos nós
da rede.
•
Comunicação com os nós: responsável por definir um
protocolo de comunicação com os nós da rede, de modo a
receber periodicamente o histórico de contactos e o perfil
social de cada nó. O servidor deve receber do nó uma
mensagem por cada contacto que este tenha, e que deve ter os
seguintes campos: identificação do sujeito encontrado
(endereço MAC),duração do contacto e instante de início do
contacto.
•
Processamento dos dados obtidos: responsável pelo
processamento das mensagens recebidas dos nós da rede, de
modo a armazenar a informação num grafo NoSQL.
•
Criação do grafo: responsável por guardar
permanentemente os dados obtidos num grafo numa base de
dados NoSQL. Com os valores obtidos do histórico de
contactos e dos perfis sociais, o servidor deve construir um
grafo. Esse grafo, deve representar os nós e as ligações entre
estes, relacionando os contactos físicos com o perfil social de
cada utilizador. Uma ligação entre dois nós do grafo deve
parecer-se com o da Figura 4. O servidor deverá, também,
guardar para cada nó a seguinte informação: número total de
contactos com todos os outros nós, duração total dos contactos
com todos os outros nós, lista de amigos e lista de interesses.
•
Segurança e privacidade: responsável por garantir a
segurança na partilha de informação com os nós da rede e por
O objetivo inicial era recolher efetivamente os dados,
instalando a aplicação SocialConnector num conjunto de
dispositivos que seriam utilizados por um grupo de pessoas
previamente escolhidas. Nesta fase de desenvolvimento do
trabalho, não foi ainda possível coletar dados reais utilizando o
SocialConnector, tendo-se recorrido a datasets já existentes
para avaliar o sistema.
Utilizando o crawdad, foi encontrado um dataset que
permite avaliar o nosso sistema, o dataset sigcomm2009. Este
contém dados coletados de uma aplicação desenvolvida para
telemóveis com o sistema operativo Windows Phone: a
MobiClique[4]. A aplicação foi usada por 76 pessoas durante
os diasda conferência SIGCOMM, em 2009, em Barcelona. O
dataset inclui os dados de proximidade obtidos através de
Bluetooth, criação e disseminação de mensagens oportunistas e
os perfis sociais, incluindo a lista de amigos e de interesses dos
participantes. Foi pedido aos participantes que utilizassem um
smartphone que lhes era fornecido com a aplicação
MobiClique, e que o utilizassem durante os dois dias da
experiência. Os dados sobre os contactos físicos e sociais
foram guardados na memória dos próprios dispositivos. Na
tabela 1, podemos verificar os valores globais acerca dos
encontros e dos perfis sociais obtidos nesta experiência e que
servirão para ser colocados no servidor desenvolvido de forma
Figura 4 - Exemplo de uma ligação do grafo
101
a serem analisados através do nosso programa de análise de
dados.
O objetivo final deste trabalho é obter a relação entre o
histórico de contactos físicos e a relação social dos nós numa
rede RTA.
Com esse propósito, foram definidas duas métricas: o
[ ] ;eo
coeficiente social entre o nó A e o nó B
coeficiente dos contactos físicos entre o nó A e o nó B
[ ].
O coeficiente social é calculado da seguinte forma:
(1)
Nesta métrica estão incluídos o coeficiente de amizade
[ ] e o coeficiente de interesses
[ ]. O
primeiro indica a razão entre o número de amigos em comum
entre A e B, sobre o número total de amigos que os dois têm
em conjunto. O segundo refere-se à razão entre o número de
interesses em comum entre A e B, sobre o número total de
interesses que os dois têm em conjunto. σ e β são valores que,
somados, têm que dar 1, e que se referem à importância que se
pretende dar a cada coeficiente.
O coeficiente de contactos físicos é calculado da seguinte
forma:
[
]
uma Pocket Switched Network. Para obter essa relação, foi
construído um sistema de recolha e análise de dados de
contactos físicos e sociais numa rede tolerante a atrasos que
consiste num esquema Cliente-Servidor, onde o cliente é uma
aplicação desenvolvida em Android, responsável por recolher
os dados relativos aos contactos físicos e ao seu perfil social e
enviá-los para o servidor. O servidor é uma aplicação em Java
que recebe os dados dos clientes e organiza-os num grafo onde
relaciona o campo social com o campo do histórico de
contactos. Depois de obtidos os dados, procede-se à análise dos
mesmos, através de uma métrica que relaciona os dois campos
já referidos: social e físico. Sendo que este trabalho ainda se
encontra em desenvolvimento, não foram obtidos os testes para
verificar a validade desta métrica. No entanto, no final,
pretende-se que o teste seja feito, utilizando para isso um
dataset já existente: o dataset SIGCOMM09. Caso seja
validada no teste, a métrica calculada pode ser usada
futuramente como uma métrica numa decisão de
encaminhamento para um protocolo que use informação de
contexto social numa RTA.
REFERÊNCIAS
[1]
(2)
Em relação ao coeficiente dos contatos físicos, este
consiste, igualmente, em dois coeficientes: o coeficiente do
[ ] ; e o coeficiente da
número de contactos físicos
[ ]. O
duração desses mesmos contactos físicos
primeiro alude à razão entre o número de contactos entre os
nós A e B na rede, sobre o número total de contactos com
todos os nós da rede que os dois têm em conjunto. O segundo
aponta a razão entre a duração total dos contactos entre A e B,
sobre a duração total dos contactos com todos os nós da rede
que os dois têm em conjunto. e são valores que, somados,
têm que dar 1 e que se referem à importância que se pretende
[ ] é a constante de
dar a cada coeficiente.
envelhecimento; e
é a média de
tempo decorrido entre os contactos dos nós A e B.
Por fim, para relacionar os dois coeficientes fazemos a
razão entre eles e retiramos as devidas ilações.
[
]
(3)
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
{
(4)
Já foram realizados os primeiros testes experimentais com
estas métricas, contudo, visto tratar-se de um trabalho ainda em
desenvolvimento, estes não foram devidamente validados, o
que inviabiliza a apresentação de resultados.
VI. CONCLUSÃO
O principal objetivo deste trabalho é verificar a existência
de uma relação entre o histórico de contactos físicos e a relação
social entre os nós de uma rede RTA, mais concretamente de
102
[11]
[12]
[13]
[14]
[15]
K. Fall, “A delay-tolerant network architecture for challenged internets,”
Proc. 2003 Conf. Appl. Technol. Archit. Protoc. Comput. Commun. SIGCOMM ’03, p. 27, 2003.
L. Fratta, M. Gerla, and L. Kleinrock, “The flow deviation method: An
approach to store‐and‐forward communication network design,”
Networks, 1973.
P. Hui, A. Chaintreau, J. Scott, R. Gass, J. Crowcroft, and C. Diot,
“Pocket switched networks and human mobility in conference
environments,” Proceeding 2005 ACM SIGCOMM Work. Delaytolerant Netw. - WDTN ’05, pp. 244–251, 2005.
A. Pietiläinen, E. Oliver, and J. LeBrun, “MobiClique: middleware for
mobile social networking,” 2nd ACM Work. Online Soc. networks, pp.
49–54, 2009.
A. Pietilänen and C. Diot, “Dissemination in opportunistic social
networks: the role of temporal communities,” MobiHoc ’12 Proc.
Thirteen. ACM Int. Symp. Mob. Ad Hoc Netw. Comput., 2012.
A. Vahdat and D. Becker, “Epidemic routing for partially connected ad
hoc networks,” 2000.
A. Lindgren, A. Doria, and O. Schelén, “Probabilistic routing in
intermittently connected networks,” ACM SIGMOBILE Mob. Comput.
Commun. Rev., vol. 7, no. 3, p. 19, Jul. 2003.
E. M. Daly and M. Haahr, “Social Network Analysis for Information
Flow in Disconnected Delay-Tolerant MANETs,” IEEE Trans. Mob.
Comput., vol. 8, no. 5, pp. 606–621, May 2009.
J. M. Pujol, A. Lopez Toledo, and P. Rodriguez, “Fair Routing in Delay
Tolerant Networks,” IEEE INFOCOM 2009 - 28th Conf. Comput.
Commun., pp. 837–845, Apr. 2009.
P. Hui, J. Crowcroft, and E. Yoneki, “BUBBLE Rap : Social-Based
Forwarding in Delay-Tolerant Networks,” no. November, pp. 1576–
1589, 2011.
A. Mtibaa and M. May, “Peoplerank: Social opportunistic forwarding,”
INFOCOM 2010 Proc. IEEE, 2010.
K. Scott, S. Burleigh, and The MITRE Corporation, “Bundle Protocol
Specification,” pp. 1–51, 2007.
R. Balani, “Energy Consumption Analysis for Bluetooth , WiFi and
Cellular Networks.”
C. Vicknair, M. Macias, Z. Zhao, X. Nan, Y. Chen, and D. Wilkins, “A
comparison of a graph database and a relational database,” in
Proceedings of the 48th Annual Southeast Regional Conference on ACM
SE 10, 2010, p. 1.
“Redes
Sociais.”
[Online].
Available:
http://www.ebizmba.com/articles/social-networking-websites.
[Accessed: 13-Sep-2013].
Encaminhamento Multi-Caminho Baseado num
Número Reduzido de Árvores
João Horta, Margarida Mamede e José Legatheaux Martins
CITI e Departamento de Informática, Faculdade de Ciências e Tecnologia,
Universidade Nova de Lisboa, 2829–516 Caparica, Portugal
Email: [email protected], {mm, jose.legatheaux}@fct.unl.pt
Resumo—Quando se utiliza encaminhamento multi-caminho
para engenharia de tráfego, o número total de caminhos necessários é potencialmente muito elevado, da ordem de O(kn2 ),
onde n é a cardinalidade do conjunto de nós de entrada /
saı́da de tráfego (edge nodes) e k é o número de caminhos
distintos, simultaneamente usados entre cada par desses nós. A
dimensão das tabelas de encaminhamento dos nós é proporcional
ao número total de caminhos necessários. Reduzir o seu número
é um objectivo importante, que pode ser conseguido através da
agregação dos caminhos em árvores. No entanto, determinar o
número mı́nimo de árvores que cobrem um conjunto de caminhos
é um problema NP-difı́cil.
Este artigo começa com uma análise das diferentes alternativas que podem ser usadas para realizar encaminhamento multicaminho, usando equipmentos off-the-shelf, baseado na utilização
de várias árvores. Em seguida, apresenta um novo algoritmo
de agregação de caminhos num número reduzido de árvores,
destinado a optimizar a concretização de encaminhamento multicaminho e utilizável em várias das alternativas anteriores. Nos
testes experimentais efectuados, que envolvem redes sintéticas
e reais, o algoritmo produziu melhores resultados que outros
previamente publicados.
I.
I NTRODUÇ ÃO
Para o encaminhamento intra-domı́nio numa rede de computadores, uma solução comum consiste em utilizar um caminho único entre os nós origem e destino dos pacotes
(e.g., RIP, OSPF, IS-IS, ...). No entanto, quando critérios de
optimização da capacidade disponı́vel na rede assumem um
papel preponderante [1], é frequente recorrer a técnicas de
encaminhamento mais sofisticadas, recorrendo, por exemplo,
a formas de distribuição do tráfego com utilização simultânea
de mais do que um caminho entre cada par de nós origem /
destino do tráfego (e.g., usando MPLS [2] e engenharia de
tráfego [3] com encaminhamento multi-caminho). Entre os
diversos caminhos usados entre cada par de nós devem estar
presentes caminhos mais curtos, mas também caminhos que
proporcionem equidade entre fluxos e capacidade de optimizar
a distribuição do tráfego e a resistência a avarias [4], [5].
Num quadro de encaminhamento multi-caminho, a tendência mais recente consiste na computação e instalação destes
caminhos a priori, por métodos off-line. Assim, se os nós de
entrada do tráfego na rede tiverem a capacidade de realizar a
distribuição da carga pelos diferentes caminhos disponı́veis, a
complexidade dos nós interiores poderá ser minimizada, visto
que a sua configuração poderá ser estática (a menos da sua
eventual participação na sinalização de avarias e contabilização
de tráfego), na linha do defendido em [6].
A optimalidade da distribuição dinâmica de carga e da
reacção a avarias continua a ser objecto de investigação recente
[1], [4]. Mas o problema da simplicidade global dos nós da
rede tem sido mais desprezado. No quadro descrito, o número
total de caminhos parametrizados a priori nos nós da rede
é muito elevado, da ordem de O(kn2 ), onde n é o número
de nós de entrada / saı́da de tráfego (edge nodes) e k é
o número de caminhos distintos entre cada par desses nós.
Reduzir o número de entradas da tabela de encaminhamento
(i.e., da FIB - Forwarding Information Base) também é um
objectivo importante. Uma forma de realizar esta optimização
consiste na agregação dos diferentes caminhos em árvores.
Se a redução assim conseguida for significativa, o número de
entradas nas FIBs poderá ser muito reduzido. Infelizmente,
determinar o número mı́nimo de árvores que cobrem um
conjunto de caminhos é um problema NP-difı́cil [7], [8].
As principais contribuições deste artigo são, primeiro,
uma análise das diferentes alternativas que podem ser usadas
para concretizar encaminhamento multi-caminho com base na
utilização de várias árvores e, depois, um novo algoritmo
de agregação de caminhos num número reduzido de árvores,
destinado a optimizar a concretização de encaminhamento
multi-caminho e utilizável em várias das situações anteriores.
Nos testes experimentais efectuados, o algoritmo produziu
melhores resultados que outros previamente publicados.
Na secção II é discutida a concretização do encaminhamento multi-caminho com base em várias árvores. Na secção
III é apresentado trabalho prévio sobre o tema. A secção IV
descreve e discute o algoritmo proposto. Em seguida, na secção
V, é efectuada uma análise empı́rica do mesmo e realizada uma
comparação com outros algoritmos. Finalmente, na secção VI,
são apresentadas algumas conclusões e trabalho futuro.
II.
E NCAMINHAMENTO M ULTI -C AMINHO COM BASE EM
Á RVORES
Para esta discussão, uma rede é definida por um grafo
G = (V, E) simples (um grafo sem lacetes nem arcos paralelos),
não orientado (onde (v1 , v2 ) e (v2 , v1 ) denotam o mesmo
arco) e conexo (existe caminho entre dois quaisquer nós). Seja
N ⊆ V o conjunto, de cardinalidade n, dos nós de entrada e
saı́da da rede, ou seja, o conjunto dos nós que podem ser
a origem ou o destino do tráfego. Para todos os pares de
nós (x, y) ∈ N 2 , com x < y (para uma qualquer relação de
103
ordem total em N), computaram-se previamente (até) k > 0
caminhos distintos com caracterı́sticas adequadas ao suporte de
encaminhamento multi-caminho [3], [5], [9], [10]. O número
total desses caminhos é geralmente próximo de k n(n−1)
2 , visto
que em certas redes e contextos podem não existir k caminhos
distintos para certos pares de nós. Como veremos nas secções
seguintes, existem algoritmos que permitem agregar esses
caminhos num certo número de árvores.
Considera-se igualmente que existem mecanismos, necessários para engenharia de tráfego, que permitem a um nó
x de entrada de tráfego obter as seguintes informações: M1)
dado o endereço de destino de um fluxo, determinar o nó y
de saı́da a que o destino está ligado; M2) dado um nó y de
destino, conhecer os k caminhos para lhe chegar; e M3) dados
os k caminhos que permitem a x alcançar y, qual destes deve
ser escolhido para cada fluxo / pacote (segundo um critério de
engenharia de tráfego ou outro). A solução completa destes
3 problemas está fora do âmbito deste trabalho, no entanto,
nas subsecções que se seguem, faremos referência ao modo
como estes podem ser abordados em diferentes alternativas de
encaminhamento com base em árvores.
A. MPLS com Utilização de LSPs Multipoint-to-Point
Com MPLS cada caminho é concretizado na rede através
de um LSP (Label Switch Path). Como o seu número é muito
elevado, desenvolveram-se técnicas de agregação de LSPs com
o objectivo de utilizar uma única entrada na FIB de um nó
intermédio z, sempre que vários LSPs partilham o mesmo
caminho de z até ao destino [7], [11], [12]. Estes LSPs
especiais designam-se multipoint-to-point, ou m-t-p, e a sua
determinação tem semelhanças com a agregação de caminhos
em árvores.1 A secção seguinte refere algoritmos propostos
para esta agregação.
A utilização de MPLS para engenharia de tráfego com
parametrização estática dos LSPs é comum, pelo que existem
os mecanismos M1), M2) e M3) acima referidos nos equipamentos com suporte de MPLS (ver, por exemplo, [3]).
B. Utilização de VLANs
Numa rede de switches Ethernet organizada em malha é
possı́vel desactivar o protocolo STP (Spanning Tree Protocol)
e parametrizar estaticamente em cada switch a que VLANs
devem estar associadas cada uma das suas portas. Assim, é
possı́vel parametrizar na rede até 4096 árvores distintas (o limite do número de VLANs imposto pela norma IEEE 802.1D)
[10]. Com esta solução é possı́vel realizar o encaminhamento
multi-caminho com base num número reduzido de árvores.
A escolha do caminho que um dado pacote deve seguir é
equivalente à escolha da VLAN tag que o mesmo recebe à
entrada da rede. O encaminhamento é depois realizado usando
o tradicional algoritmo de inundação com aprendizagem pelo
caminho inverso.2 A proposta geral do método foi feita no
quadro do encaminhamento em redes para centros de dados.
1 Um LSP m-t-p não é exactamente uma árvore (um subgrafo da rede G,
acı́clico e conexo), visto que é um grafo orientado (“dirigido para a raiz”, que
é o destino dos caminhos). Mas é acı́clico e fracamente conexo.
2 Caso seja necessário preservar identificadores de VLANs com significado
fora da rede, deverá ser utilizada alguma forma de encapsulamento suplementar (e.g., IEEE 802.1ad).
104
Neste quadro a implementação dos mecanismos M1), M2) e
M3) pode ser realizada nos drivers Ethernet dos servidores
[10]. O método requer a utilização de inundação e de tabelas
de endereços MAC cuja dimensão pode ser significativa.
Outra proposta baseada na utilização de VLANs consiste
em usar tantas árvores de cobertura, computadas pelo protocolo
STP, quanto o número de switches de N (i.e., n árvores),
cada uma com raiz em cada um desses switches [13]. Para
realizar a distribuição de tráfego multi-caminho, os fluxos são
distribuı́dos pelas diferentes n árvores numa forma roundrobin. No entanto, este método não permite controlar com rigor
os caminhos usados por cada fluxo e a qualidade dos mesmos.
C. Utilização de Longest-Prefix Matching
Dada uma árvore, é possı́vel realizar o encaminhamento
ponto a ponto usando equipamentos com suporte de encaminhamento IP, endereços hierárquicos e Longest-Prefix Matching, portanto sem recurso a inundação.
Para este efeito é necessário parametrizar os equipamentos
com rotas estáticas, especı́ficas para cada árvore, da seguinte
forma. Dada uma árvore t, é-lhe associado um prefixo ou
intervalo de endereços I, disjunto de todos os outros. Em
seguida, I é particionado em vários subintervalos, cada um
dos quais associado a um nó filho da raiz. Esta operação é
realizada recursivamente até às folhas. Em seguida, em cada
nó da árvore, I é associado à interface que dá acesso ao nó
pai (excepto na raiz) e cada subintervalo afectado a um filho é
associado à interface que lhe dá acesso. Finalmente, cada nó da
rede recebe um endereço no seu intervalo (este endereço não é
afectado a nenhum filho). É fácil verificar que o algoritmo de
encaminhamento Longest-Prefix Matching encaminha pacotes
destinados a um endereço contido em I, na árvore t, sem
necessidade de realizar inundação. Este método apenas requer
espaço nas FIBs para as rotas estáticas proporcional ao número
de árvores em que cada nó participa.
A escolha do caminho que um pacote deve seguir é
equivalente à escolha do endereço do nó destino na árvore pela
qual se pretende encaminhar o pacote. Esta transformação de
endereços pode ser realizada por vários métodos, como por
exemplo túneis IP sobre IP, ou recorrendo a LISP [14], que
fornece igualmente interfaces para a utilização dos mecanismos M1), M2) e M3).
Na literatura é possı́vel encontrar diversas outras realizações de encaminhamento multi-caminho usando ECMP (Equal
Cost Multi-Path Routing) em redes fisicamente configuradas
com árvores, mas a comparação exaustiva das qualidades e
defeitos de cada um desses métodos, assim como dos métodos
indicados acima, ultrapassa o âmbito deste artigo.
III.
AGREGAÇ ÃO DE C AMINHOS EM Á RVORES :
P ROBLEMA E S OLUÇ ÕES
O problema da agregação de caminhos em árvores pode
ser definido da seguinte forma. Dado um conjunto S de
caminhos num grafo G = (V, E) simples, não orientado e
conexo, pretende-se obter um conjunto T de árvores de G (ou
seja, um conjunto de subgrafos de G acı́clicos3 e conexos),
3 Um grafo cı́clico (respect. acı́clico) é um grafo com (respect. sem) ciclos.
Um ciclo é um caminho com pelo menos dois nós, tal que o primeiro e o
último nós são iguais e cujos arcos são todos distintos.
com a menor cardinalidade possı́vel, tal que todo o caminho
de S seja um caminho em alguma árvore de T . Sem perda de
generalidade, assume-se que qualquer caminho p ∈ S tem pelo
menos dois nós e que todos os nós de p são distintos. No subproblema da agregação de caminhos com o mesmo destino,
todos os caminhos de S têm o mesmo nó destino.
Sabe-se que o problema de decisão da agregação de caminhos com o mesmo destino, onde se pergunta se é possı́vel
agregar os caminhos de S em m ≥ 1 árvores, é NP-completo
[7], [8]. Consequentemente, os dois problemas de optimização
referidos são NP-difı́ceis, não havendo actualmente algoritmos
polinomiais para os resolver. Portanto, os algoritmos que existem não garantem que a cardinalidade do conjunto retornado
é a menor possı́vel, sendo essa cardinalidade a medida para
avaliar a qualidade da solução computada.
O caso particular da agregação de caminhos com o mesmo
destino foi estudado no contexto de LSPs m-t-p. Em [11],
o problema é reformulado em termos de programação linear
inteira (do tipo 0-1). Em [7] é proposto um algoritmo greedy
que, basicamente, agrega caminhos (e árvores) por ordem
descrescente de comprimento dos “sufixos comuns”.
Embora o problema geral pudesse ser atacado com estes
algoritmos, para os nossos conjuntos S de caminhos, o número
total de árvores nunca seria muito reduzido. Em geral, S tem
k caminhos para cada par (x, y) ∈ N 2 , com x < y. Ou seja,
|S| ≈ k n(n−1)
2 , onde n = |N|. Particionando S pelo vértice final
dos caminhos, seriam gerados n − 1 problemas de agregação
com o mesmo destino e, para cada um deles, o conjunto de
árvores retornado teria, no mı́nimo, k árvores, porque cada
um dos k caminhos com a mesma origem (e destino) teria de
ser coberto por uma árvore diferente. Portanto, obter-se-iam
pelo menos (n − 1)k árvores no total, não sendo esperadas
repetições. Esta estratégia de resolução do problema será
designada por estratégia LSPs m-t-p, na secção V.
Para simplificar as próximas definições, considere-se que
um caminho p = v1 v2 · · · vm−1 vm (com m ≥ 2) induz o grafo
não orientado G p = (Vp , E p ), onde Vp = {v1 , v2 , . . . , vm−1 , vm }
é o conjunto dos vértices e E p = {(v1 , v2 ), . . . , (vm−1 , vm )} é o
conjunto dos arcos. Sejam G0 = (V 0 , E 0 ) um subgrafo acı́clico
de G e p ∈ S um caminho. Diz-se que G0 contém ou cobre p se
E p ⊆ E 0 e que p pode ser agregado a G0 se (V 0 ∪Vp , E 0 ∪ E p )
for um grafo acı́clico. A inserção ou agregação de p em G0
transforma G0 no grafo (V 0 ∪Vp , E 0 ∪ E p ).
No âmbito do sistema SPAIN [8], [10], cujos objectivos
são muito semelhantes aos nossos, Mudigonda et al. desenvolveram dois algoritmos aleatórios para agregar caminhos em
subgrafos acı́clicos (não necessariamente conexos). Devido à
sua natureza, ambos os algoritmos devem ser executados várias
vezes, sendo guardado e retornado um dos conjuntos calculados nas diferentes execuções com a menor cardinalidade.
O primeiro algoritmo [8], [10] é muito simples. Inicialmente, o conjunto O de subgrafos é vazio. O conjunto
S é percorrido, por uma ordem aleatória, e cada um dos
seus caminhos p é tratado sequencialmente, começando-se por
verificar se algum subgrafo de O o contém. Em caso afirmativo,
passa-se ao caminho seguinte. Se nenhum subgrafo cobrir p,
percorre-se novamente O, por uma ordem aleatória, até se
encontrar um subgrafo G0 ao qual p possa ser agregado e
efectua-se a inserção de p em G0 . Se p não puder ser agregado
a nenhum subgrafo existente, cria-se o subgrafo G p (com os
vértices e os arcos do caminho), que se acrescenta a O.
O segundo algoritmo [8] é muito complexo para ser descrito em detalhe. Basicamente, S é inicialmente particionado
pelo vértice final dos caminhos, para que os sub-problemas
possam ser resolvidos em paralelo, e cada conjunto de subgrafos que agregam os caminhos com um mesmo destino é obtido
através de uma redução ao problema da coloração de vértices.
Como a reunião de todos os conjuntos computados (que é
uma solução do problema original) pode ser muito grande,
depois executa-se uma função não determinista que efectua
reuniões de subgrafos obtidos para destinos diferentes (quando
o resultado é um grafo acı́clico).
A justificação apresentada pelos autores para desenvolver
o segundo algoritmo é a diminuição dos tempos de execução,
devido à paralelização da primeira fase. Mas os dois algoritmos
não são comparados, nem quanto aos tempos de execução,
nem quanto à qualidade das soluções produzidas (dada pela
cardinalidade dos conjuntos retornados). Por estes motivos,
só comparámos o nosso algoritmo com o primeiro, cuja
implementação é significativamente mais simples.
IV.
A LGORITMO DE AGREGAÇ ÃO DE C AMINHOS EM
Á RVORES
O novo algoritmo de agregação de caminhos em árvores é
determinista. Partindo de um conjunto vazio de árvores, vão-se
agregando caminhos às árvores existentes, criando uma nova
árvore apenas quando a inserção dos caminhos em qualquer
uma das árvores que já existem resultaria num grafo cı́clico
ou não conexo. A grande diferença em relação aos algoritmos
semelhantes descritos na secção anterior é que se começa
por inserir “pares de caminhos compatı́veis”, por uma ordem
e numa árvore especı́ficas. Por abuso, chamamos par a um
conjunto {p, q} com dois caminhos, denotando-o por (p, q),
mas os caminhos são distintos e a ordem pela qual ocorrem
é irrelevante. É importante recordar que S é o conjunto de
entrada (i.e., um conjunto de caminhos num grafo G), que
G p = (Vp , E p ) denota o grafo induzido por um caminho p ∈ S
e que uma árvore t de G é um subgrafo de G conexo e acı́clico
(definido por (Vt , Et )).
A noção de “compatibilidade” é fundamental e definese entre dois caminhos, entre um caminho e uma árvore e
entre um par de caminhos e uma árvore. No primeiro caso,
a compatibilidade será usada para definir a ordem pela qual
os pares de caminhos são processados. Nos restantes, será
usada para escolher a árvore onde um caminho ou um par
de caminhos é inserido, quando há várias alternativas.
A compatibilidade entre um par de caminhos (p, q) é −1
se o grafo (Vp ∪Vq , E p ∪ Eq ) for cı́clico; e é |Vp ∩Vq |, o número
de nós em comum, no caso contrário. A compatibilidade entre
um caminho p e uma árvore t define-se de forma semelhante: é
−1 se o grafo (Vt ∪Vp , Et ∪E p ) for cı́clico; e é |Vt ∩Vp |, no caso
contrário. A compatibilidade entre um par de caminhos (p, q)
e uma árvore t é −1 se o grafo (Vt ∪Vp ∪Vq , Et ∪ E p ∪ Eq ) for
cı́clico; e é |Vt ∩Vp |+|Vt ∩Vq |, nos outros casos. Dois caminhos
(respect., um caminho e uma árvore, ou um par de caminhos e
uma árvore) dizem-se compatı́veis se a compatibilidade entre
eles — denotada por compat(·, ·) — for positiva.
105
Note-se que dois caminhos sem nós em comum (respect.,
um caminho sem nós em comum com uma árvore) não são
compatı́veis, porque a reunião dos respectivos grafos não é um
grafo conexo. Mas um par de caminhos pode ser compatı́vel
com uma árvore, mesmo que um dos caminhos não partilhe
qualquer nó com a árvore (desde que o outro partilhe). As
seguintes propriedades, que permitem efectuar operações com
entidades compatı́veis, são fáceis de verificar.
•
Se (p, q) for um par de caminhos compatı́veis, a
criação de um novo grafo com (p, q), definido por
(Vp ∪Vq , E p ∪ Eq ), produz uma árvore.
•
Se o caminho p e a árvore t forem compatı́veis, a
inserção de p em t, que transforma t no grafo (Vt ∪
Vp , Et ∪ E p ), produz uma árvore.
•
Se (p, q) for um par de caminhos compatı́veis, t for
uma árvore, e (p, q) e t forem compatı́veis, a inserção
de (p, q) em t, que transforma t no grafo (Vt ∪ Vp ∪
Vq , Et ∪ E p ∪ Eq ), produz uma árvore.
O algoritmo de agregação de caminhos é composto por
três fases: (i) geração dos pares de caminhos compatı́veis e
dos caminhos singulares iniciais (os caminhos de S que são
incompatı́veis com todos os outros e que, consequentemente,
não ocorrem em nenhum par de caminhos compatı́veis); (ii)
agregação de pares de caminhos compatı́veis; e (iii) agregação
de caminhos singulares.
Na primeira fase, são analisados todos os pares de caminhos de S e avaliada a sua compatibilidade. Os pares
compatı́veis serão processados na segunda fase, por uma ordem
que envolve três critérios: primeiro, por ordem decrescente
de compatibilidade do par; depois, por ordem decrescente
de “potencial de agregação” do par em S; e, em caso de
empate na compatibilidade e no potencial de agregação, por
ordem decrescente de comprimento do par (que é a soma dos
comprimentos dos dois caminhos).
O critério da compatibilidade tem como objetivo privilegiar
os pares cuja agregação é a mais “natural”, ou seja, aqueles
cujo resultado agregado é o menos diferente de cada um
dos caminhos. A ordenação pelo potencial de agregação dá
prioridade a pares de caminhos que têm um maior número de
nós em comum com todos os outros. Formalmente, o potencial
de agregação de um caminho p no conjunto S é a soma das
compatibilidades de todos os pares de caminhos de S que
envolvem p:
potAgreg(p, S) =
∑
compat(p, q).
q∈S\{p}
Na fase de agregação dos caminhos singulares, os caminhos
são seleccionados por ordem decrescente de comprimento. O
processamento de cada caminho p também se inicia com a
procura de uma árvore que o contenha, não havendo nada mais
a fazer quando esta pesquisa tem sucesso. Se p não estiver
contido em nenhuma árvore, verifica-se se p é compatı́vel
com alguma árvore e, em caso afirmativo, insere-se p numa
árvore existente. Quando o caminho é incompatı́vel com todas
as árvores, a árvore G p é criada e adicionada ao conjunto
resultado.
A procura de uma árvore compatı́vel com um dado caminho ou par de caminhos α devolve, em caso de sucesso, a
árvore t onde a inserção de α será efectuada. Essa árvore é, de
entre todas as árvores compatı́veis com α, uma que maximiza
o valor da compatibilidade. Ou seja, se T for o conjunto das
árvores existentes, a árvore t ∈ T onde α é inserido verifica:
compat(α,t) ≥ 1 e (∀t 0 ∈ T ) compat(α,t) ≥ compat(α,t 0 ).
A complexidade temporal do algoritmo é O(|S|3 × |V |),
onde V denota o conjunto dos nós da rede G, pelos seguintes
motivos. A compatibilidade entre duas entidades pode ser
decidida e avaliada em O(|V |) passos, porque o comprimento
de cada caminho não excede |V | − 1. Consequentemente, o
custo da primeira fase é O(|S|2 × (|V | + log |S|)), uma vez que
todos os pares de caminhos são analisados e os pares compatı́veis são ordenados. Nas duas últimas fases, processam-se
os pares de caminhos compatı́veis, e ordenam-se e processamse os caminhos singulares. Como o processamento de cada
par ou caminho singular requer tempo O(|T | × |V |), onde T
representa o conjunto corrente de árvores, a complexidade total
das duas últimas fases é O(|S|2 × |T | × |V |). A conclusão é
obtida usando o facto de que |T | ≤ |S|.
V.
O potencial de agregação de um par de caminhos (p, q) em S
é a soma do potencial de agregação de p e de q em S:
potAgreg((p, q), S) = potAgreg(p, S) + potAgreg(q, S).
Por fim, com o terceiro critério, pretende-se tratar os caminhos
de maior comprimento o mais cedo possı́vel, enquanto existem
mais possibilidades de agregação, deixando para o fim os que,
em princı́pio, têm mais facilidade em se agregar.
Na fase de agregação dos pares de caminhos compatı́veis,
processa-se um par de cada vez, pela ordem definida acima,
até todos os pares terem sido tratados. Começa-se por verificar,
106
para cada caminho do par, se alguma árvore existente o cobre,
sendo necessário distinguir três casos. No primeiro, os dois
caminhos estão contidos em árvores (possivelmente distintas)
e o processamento do par termina. No segundo caso, nenhum
dos caminhos está contido numa árvore. Se houver alguma
árvore compatı́vel com o par, insere-se o par de caminhos numa
das árvores existentes; senão, é criada uma nova árvore com
o par de caminhos. No terceiro caso, um dos caminhos está
contido numa árvore t e o outro (que designaremos por p) não
está contido em nenhuma árvore. Se p for compatı́vel com t,
o caminho é inserido nessa árvore; se p não for compatı́vel
com t mas houver alguma árvore compatı́vel com p, agregase p a uma das árvores existentes; e se não existir nenhuma
árvore compatı́vel com p, o caminho é adicionado à estrutura
dos caminhos singulares (adiando-se a sua agregação).
AVALIAÇ ÃO
O novo algoritmo e o (primeiro) do SPAIN foram implementados em Java. Todos os testes foram executados num
computador com 4 Gbytes de RAM, CPU a 2,53 GHertz e
usando a Java VM versão 1.7.
Cada conjunto S de teste foi obtido com o algoritmo de
selecção de caminhos para encaminhamento multi-caminho
proposto em [5]. O algoritmo recebe a rede G (cujos arcos têm
custos positivos), dois nós distintos x, y ∈ N, o número k > 0
de caminhos desejados de x para y e mais dois parâmetros, que
limitam o comprimento e o custo dos caminhos pretendidos, e
retorna um conjunto de caminhos de x para y. Para cada rede
(a) Full Mesh
(b) Anel
(ver Figura 2b). Os caminhos interessantes entre cada par de
nós da primeira camada (que corresponde ao conjunto N) são
todos simultaneamente de menor custo e disjuntos entre si e
o seu número é igual ao número de nós da segunda camada,
dado por n. Por estes motivos, S tem n2 (n − 1)/2 caminhos.
Na rede usada no teste, n = 6. As redes folded clos também
são utilizadas em centros de dados e têm a propriedade de
assegurar a disjunção máxima de caminhos.
Figura 1: Representações das redes Full Mesh e Anel
B. Redes Não Regulares
(a) Fat Tree
(b) Folded Clos
Figura 2: Representações das redes Fat Tree e Folded Clos
testada, o algoritmo foi executado para todos os pares de nós
(x, y) ∈ N 2 , com x < y, tendo-se contruı́do S com a reunião dos
n(n − 1)/2 conjuntos retornados.
Testaram-se dois tipos de redes: redes regulares, representativas de configurações com propriedades bem conhecidas,
utilizadas frequentemente em redes para interligação de computadores em clusters e em centros de dados, e redes não
regulares, que incluem backbones reais e uma rede aleatória.
Os caminhos seleccionados nas redes regulares são fáceis
de identificar e coincidem com os que serão classificados
como interessantes. Nas redes não regulares, são caminhos
que asseguram multiplicidade de encaminhamento, disjunção
de rotas e custo e comprimento adequados.
A. Redes Regulares
Foram utilizadas quatro redes regulares: full mesh, anel, fat
tree e folded clos. Nos dois primeiros casos, todos os nós são
origem e destino de tráfego (ou seja, N = V ). Na full mesh
cada nó está directamente ligado a todos os outros formando
uma clique (como ilustrado na Figura 1a). Numa rede destas
com n nós, entre cada par existe um caminho de menor custo
(com custo 1) e n − 2 caminhos com custo 2. O conjunto
S tem todos estes (n − 1) × n(n − 1)/2 caminhos, os únicos
considerados interessantes. Numa rede em anel, cada nó tem
grau 2 e existem apenas 2 caminhos (disjuntos) entre cada par
de nós (ver Figura 1b). Neste caso, S tem 2 caminhos por par.
Usou-se uma full mesh com 6 nós e um anel com 10 nós.
Uma rede fat tree é uma rede hierárquica frequentemente
usada em centros de dados. O teste foi efectuado com a rede
da Figura 2a. Configurada adequadamente, esta rede assegura
que entre quaisquer dois nós folha (os que pertencem a N)
existe capacidade garantida. Os caminhos interessantes entre
cada par de nós folha são os caminhos de menor custo, cujo
número é 22m−1 , onde m é o número de nı́veis que é necessário
subir para chegar ao nó de destino.
Uma rede com topologia folded clos é definida por duas
camadas distintas, formando um grafo bipartido tal que cada
nó da primeira camada está ligado a todos os nós da segunda
Foram usados três backbones reais e uma rede aleatória.
Para os testes foram removidos das redes reais canais paralelos
e nós que não acrescentavam diversidade. Nas redes reais o
custo dos canais usado é proporcional à distância entre os nós
e na rede aleatória o peso de todos os arcos é 1 (tal como nas
redes regulares).
A rede GÉANT é uma rede europeia de investigação e
educação que interliga as diferentes redes de investigação e
educação dos paı́ses europeus. A configuração testada tem 31
nós e 50 canais. A Internet 2 é um consórcio norte-americano
que liga universidades, centros de investigação, corporações e
outras redes regionais de educação e investigação nos EUA.
A configuração testada tem 25 nós e 44 canais. A NTT Communications é uma corporação subsidiária da NTT (Nippon
Telegraph and Telephone) e possui uma rede IP com uma
distribuição geográfica mundial. A configuração testada tem
27 nós e 63 canais. A rede aleatória utilizada foi gerada com
base numa distribuição de Poisson, com um grau médio dos
nós de valor 3. A configuração testada tem 30 nós e 48 arcos.
Nos quatro casos, todos os nós são origem e destino de tráfego.
C. Resultados da Agregação em Árvores
A tabela I apresenta alguns dados sobre os conjuntos de
teste e os resultados. A primeira coluna identifica a rede; a
segunda tem o número n de nós de entrada e saı́da da rede
(|N|); a terceira o número k de caminhos distintos pedidos ao
algoritmo de selecção de caminhos para cada par de nós de
N; e a quarta o número total de caminhos seleccionados (i.e.,
a cardinalidade do conjunto S).
Para as redes regulares, calculámos o número de árvores
óptimo (apresentado na quinta coluna da tabela I), através da
análise da rede e dos caminhos seleccionados. Para as restantes
redes, não conhecemos a cardinalidade da solução óptima.
Os algoritmos de agregação de caminhos em árvores
comparados são o novo e o (primeiro) algoritmo do sistema
SPAIN [8], [10], cujos resultados se encontram na sexta e na
sétima colunas da tabela I, respect.. O algoritmo SPAIN foi
executado para cada rede múltiplas vezes. Mas, ao invés de
definir o número de execuções, limitou-se o tempo utilizado
por estas. Isto é, durante um certo intervalo de tempo, o
algoritmo foi executado repetidamente, tendo sido escolhido o
resultado de uma execução com o menor número de subgrafos.
Nestes resultados, o intervalo de tempo utilizado corresponde
a 5 vezes o tempo de execução do novo algoritmo para a
mesma rede. Convém referir que o algoritmo foi implementado
como foi descrito na secção III e pelos autores [8], [10].
Por isso, o resultado é um conjunto de grafos acı́clicos, não
necessariamente conexos (o que justifica o tı́tulo das duas
colunas de resultados na tabela). A oitava coluna apresenta
107
que recorrem a switches e VLANs, que encaminham através de
árvores, com base em inundação optimizada por aprendizagem
pelo caminho inverso. O mesmo também permite a utilização
de FIBs muito mais compactas do que as necessárias quando
se usa MPLS e m-t-p LSPs. Tanto quanto é do nosso conhecimento, a sua proposta não foi ainda previamente sistematizada
na literatura existente.
Tabela I: Resultados da execução dos algoritmos
Redes
Full Mesh
Anel
Fat Tree
Folded Clos
GÉANT
Internet 2
NTT
Aleatória
n
6
10
8
6
31
25
27
30
k
5
2
2 ou 8
6
3
3
3
3
|S|
75
90
152
90
1381
898
1044
1318
# óptimo
de árvores
6
10
8
6
—
—
—
—
# de subgrafos
Novo
SPAIN
6
10
10
10
8
14
6
18
30
38
14
16
25
39
27
34
LSPs
m-t-p
25
18
56
30
90
72
78
87
Em seguida introduzimos um algoritmo de agregação de
caminhos ponto a ponto num número reduzido de árvores. Nos
testes realizados, o algoritmo apresenta melhores resultados
que outros recenseados na literatura. Como trabalho futuro,
pretendemos tentar deduzir qual a distância máxima da solução
computada à solução óptima.
Tabela II: Tempos de execução dos algoritmos
Redes
Full Mesh
Anel
Fat Tree
Folded Clos
GÉANT
Internet2
NTT
Aleatória
Tempo (SPAIN)
965ms
15ms
12sec 820ms
2sec 420ms
25min 39sec
34min 19sec
41min 32sec
22min 56sec
# de execuções (SPAIN)
699
83
2274
870
20268
32570
27391
22598
Tempo (Novo)
193ms
3ms
2sec 564ms
484ms
5min 7sec
6min 51sec
8min 18sec
4min 35sec
Este trabalho insere-se num trabalho mais geral que visa
desenvolver algoritmos e mecanismos de engenharia de tráfego
que permitam optimizar o funcionamento da rede num quadro
de carga variável e desconhecida a priori, incluindo a resposta
atempada às falhas dos canais e dos nós.
R EFER ÊNCIAS
o menor número de árvores que poderia ser obtido com a
estratégia LSPs m-t-p (c.f. secção III), assumindo que não
haveria repetições, e que corresponde a (n − 1)k. A tabela II
apresenta os resultados da execução dos algoritmos para cada
rede (tempo de execução e número de execuções no caso do
SPAIN).
Os resultados mostram que o novo algoritmo agrega os
conjuntos de caminhos das redes regulares no número óptimo
de árvores. Para as restantes redes, ao não se conhecer o valor
óptimo, esta avaliação não pode ser realizada. No entanto,
analisando os resultados de forma comparativa, repara-se que
os do novo algoritmo são sempre os melhores e que o número
de árvores é muito reduzido. O SPAIN só tem um desempenho
igual para a rede em anel. Os valores da coluna LSPs m-t-p são
substancialmente mais elevados do que os resultados obtidos
por ambos os algoritmos, indiciando que aquela estratégia de
resolução do problema geral não é a mais adequada.
VI.
C ONCLUS ÕES E T RABALHO F UTURO
[2]
[3]
[4]
[5]
[6]
[7]
[8]
Quando se pretende realizar o encaminhamento numa rede
usando engenharia de tráfego, a utilização de encaminhamento
através de múltiplos caminhos tem-se imposto. Neste quadro,
a procura de soluções simples, mas que não sacrifiquem a
optimalidade, na linha das defendidas em [6], é fundamental.
O trabalho aqui apresentado centra-se na problemática da
redução do número de entradas nas FIBs dos equipamentos
de encaminhamento, com recurso à agregação dos caminhos
num número reduzido de árvores, para encaminhamento com
equipamentos banalizados (off-the-shelf ) e sem necessidade de
recorrer a novos protocolos.
O recenseamento apresentado na secção II mostra que é
possı́vel encaminhar com base em árvores através de pelo
menos três métodos distintos. Usando MPLS e LSPs m-t-p,
usando diversas VLANs e usando Longest-Prefix Matching.
Este último método é implementável em qualquer equipamento
que suporte encaminhamento com base em tabelas de prefixos
IP e que possa ser parametrizado com rotas estáticas. Tratase de uma solução mais simples e mais escalável do que as
108
[1]
[9]
[10]
[11]
[12]
[13]
[14]
N. Wang, K. H. Ho, G. Pavlou, and M. Howarth, “An overview of
routing optimization for internet traffic engineering,” IEEE Communications Surveys and Tutorials, vol. 10, no. 1, pp. 36–56, 2008.
E. Rosen, A. Viswanathan, and R. Callon, “Multiprotocol label switching architecture,” IETF, RFC 3031, 2001.
O. M. Heckmann, The Competitive Internet Service Provider, 1st ed.,
ser. Wiley Series in Communications Networking & Distributed Systems. Chichester, UK: Wiley-Interscience, April 2006.
M. Suchara, D. Xu, R. Doverspike, D. Johnson, and J. Rexford,
“Network architecture for joint failure recovery and traffic engineering,”
SIGMETRICS Performance Evaluation Review-Measurement and Evaluation, vol. 39, no. 1, p. 97, 2011.
J. Horta, M. Mamede, and J. L. Martins, “Selecção de caminhos para
encaminhamento multi-caminho,” in Actas do Inforum 2013 - Simpósio
de Informática, September 2013, pp. 78–89.
M. Caesar, M. Casado, T. Koponen, J. Rexford, and S. Shenker, “Dynamic route recomputation considered harmful,” SIGCOMM Comput.
Commun. Rev., vol. 40, no. 2, pp. 66–71, Apr. 2010.
S. Bhatnagar, S. Ganguly, and B. Nath, “Creating multipoint-to-point
LSPs for traffic engineering,” Workshop on High Performance Switching
and Routing, 2003, HPSR., pp. 201–207, 2003.
J. Mudigonda, P. Yalagandula, M. Al-Fares, and J. Mogul, “Spain:
Design and algorithms for constructing large data-center ethernets from
commodity switches,” Tech. Rep. HPL-2009-241, HP Labs, Tech. Rep.,
2009.
S. Nelakuditi and Z.-L. Zhang, “On selection of paths for multipath
routing,” in Quality of Service — IWQoS 2001, ser. Lecture Notes
in Computer Science, L. Wolf, D. Hutchison, and R. Steinmetz, Eds.
Springer Berlin Heidelberg, 2001, vol. 2092, pp. 170–184.
J. Mudigonda, P. Yalagandula, M. Al-Fares, and J. Mogul, “Spain:
Cots data-center ethernet for multipathing over arbitrary topologies,”
in Proceedings of the 7th USENIX conference on Networked systems
design and implementation. USENIX Association, 2010, pp. 18–18.
H. Saito, Y. Miyao, and M. Yoshida, “Traffic engineering using multiple
multipoint-to-point lsps,” in INFOCOM 2000. Nineteenth Annual Joint
Conference of the IEEE Computer and Communications Societies.
Proceedings. IEEE, vol. 2, 2000, pp. 894–901 vol.2.
F. Solano, R. Fabregat, and J. Marzo, “On optimal computation of mpls
label binding for multipoint-to-point connections,” Communications,
IEEE Transactions on, vol. 56, no. 7, pp. 1056–1059, july 2008.
R. van Haalen, R. Malhotra, and A. de Heer, “Optimized routing
for providing ethernet lan services,” Communications Magazine, IEEE,
vol. 43, no. 11, pp. 158–164, nov. 2005.
D. Meyer, “The locator identifier separation protocol (LISP),” The
Internet Protocol Journal, vol. 11, no. 1, March 2008.
Encaminhamento IP Optimizado Através de uma
Aproximação de Software Defined Networking
Alexandre Pinote e José Legatheaux Martins
CITI e Departamento de Informática, Faculdade de Ciências
e Tecnologia, Universidade Nova de Lisboa, 2829–516 Caparica, Portugal
Email: [email protected], [email protected]
Resumo—Este artigo apresenta uma implementação optimizada de encaminhamento IP Unicasting e Multicasting para
uma rede de switches. A optimização está implementada segundo a aproximação Software Defined Networking (SDN),
com base na norma OpenFlow e no controlador FloodLight.
Através da introdução de novos mecanismos de optimização da
implementação de ARP, IGMP e da gestão do encaminhamento
IP Multicasting, o trabalho demonstra que as promessas de
flexibilidade e simplicidade da aproximação SDN são reais. O
encaminhamento IP Multicasting é realizado com base em árvores
de caminhos mais curtos, equivalentes às utilizadas por IP PIMDM, mas implementadas de forma muito mais simples e leve.
do que uma única subnet IP e encaminha de forma sub-óptima
(pelo menos dentro de cada sub-net).
Nos últimos anos apareceram diversas propostas de
optimização do encaminhamento pelos switches, que introduzem simultaneamente servidores de directório em redes de
switches Ethernet empresariais ou de centros de dados (e.g.,
[2], [3], [4], [5]). Simultanemente, apareceu também uma
proposta para tornar mais flexı́vel o controlo e evolução deste
tipo de redes através de uma aproximação que se veio a
designar Software Defined Networking (SDN) [6], [7].
A. Software Defined Networking e OpenFlow
I.
I NTRODUÇ ÃO
A rede Ethernet foi inicialmente definida com base num
meio de difusão partilhado de tal forma que os custos da
comunicação ponto a ponto (unicasting ) ou ponto multi-ponto
(difusão: broadcasting e multicasting ) eram idênticos. Como
as subnets IP têm necessidade de mecanismos de descoberta e
directórios (para afectação de endereços IP e mapeamento de
endereços IP em endereços MAC), o baixo custo do difusão na
Ethernet tornou muito atractiva a sua utilização, em conjunto
com soft state, como alternativa de implementação desses
mecanismos.
A disponibilidade de switches Ethernet de baixo custo
permitiria hoje em dia construir subnets IP de grande dimensão
(e.g., cobrindo todo um campus universitário ou uma grande
empresa), que dispensariam a complexidade da utilização de
encaminhamento IP entre várias subnets distintas. No entanto,
na prática, tal aproximação não é muito utilizada. Por um
lado, critérios de segurança recomendam a partição da rede em
várias VLANs distintas (virtual local area networks). Por outro
lado, a utilização indiscriminada de difusão na rede de switches
(e.g., ARP, DHCP, IGMP, inundação para aprendizagem do
encaminhamento unicasting e inundação para encaminhamento
IP Multicasting) limitaria de forma significava o seu desempenho.
Na prática as redes institucionais de switches são particionadas em diversas VLANs. Cada VLAN é uma subnet
distinta, com um prefixo IP especı́fico, e o encaminhamento é
nelas realizado com base em, por um lado, encaminhamento
sub-óptimo através de árvores de cobertura (protocolo STP Spaning Tree Protocol [1]) dentro de cada VLAN e, por outro,
encaminhamento IP entre VLANs distintas (e.g., RIP, OSPF).
Na prática tal rede é do ponto de vista de gestão mais complexa
Nas redes convencionais os equipamentos de rede desempenham simultaneamente duas funções distintas, geralmente
designadas por data plane e control plane. As funções do
data plane consistem em analisar os cabeçalhos dos pacotes
recebidos e, em função de tabelas de comutação ou de encaminhamento, enviarem-nas para o seu destino final via a interface
seleccionada. O control plane implementa todos os protocolos de coordenação com os outros equipamentos de rede
necessários para a parametrização e controlo do funcionamento
do data plane. Numa rede de switches Ethernet o control plane
executa pelo menos o algoritmo de aprendizagem de endereços
MAC, assim como o protocolo STP. Nos switches que também
implementam nı́vel 3, o control plane é igualmente responsável
pela implementação dos protocolos de encaminhamento IP.
A aproximação SDN consiste em separar o data plane do
control plane e implementá-los em equipamentos distintos, ver
a figura 1. Assim, os switches apenas realizam as funções
do data plane, enquanto que servidores, designados por controladores de rede, realizam as funcionalidades do control
plane através de uma aproximação logicamente centralizada.
Finalmente, os switches e os controladores comunicam através
de um protocolo de controlo, cujo exemplo mais conhecido e
normalizado é o protocolo OpenFlow [6].
O protocolo OpenFlow permite a um controlador programar um switch através de regras de encaminhamento. No
essencial, cada regra é constituı́da por um descritor de um
conjunto de pacotes (i.e., um descritor de um flow) e por uma
ou mais acções a aplicar ao conjunto desses pacotes (i.e., ao
flow).
Um descritor OpenFlow é da mesma natureza que as ACLs
usadas em diversos equipamentos de rede e permite especificar
um flow com uma grande flexibilidade, usando exact matching
109
rede simples de nı́vel L2 convencional. Geralmente fornecem
igualmente módulos de realização de controlo de acessos (firewalling) e de encaminhamento unicasting usando o caminho
mais curto numa configuração arbitrária de switches (i.e., em
malha e com ciclos). No entanto, tanto quanto conseguimos
apurar, não existem no domı́nio público implementações de
IGMP nem de encaminhamento IP Multicasting optimizado
através de árvores de difusão (como as computadas por
PIM por exemplo). Um único artigo faz referência a uma
implementação sem apresentar informação concreta sobre a
solução [12].
Figura 1: Separação do data plane e do control plane numa
rede
e wild card matching. As acções determinam o que fazer com
os pacotes que pertencem ao flow sendo as mais comuns:
drop e forward. No último caso, a acção pode especificar o
envio da mensagem por uma interface determinada, a difusão
(flood) da mesma, o seu envio para o controlador, etc.. Em
versões mais recentes do protocolo o conjunto de acções
compreende igualmente acções mais complexas como empilhar
identificadores (e.g., ATM), ou transformar o cabeçalho IP.
Através do protocolo OpenFlow é possı́vel implementar
uma nova arquitectura de controlo de uma rede, com diversas
vantagens potenciais quando comparada com a aproximação
convencional. Os switches passam a ser equipamentos fabricados com base em circuitos VLSI verticais (merchant silicon)
que implementam as tabelas de encaminhamento (CAMs e
TCAMs - Content Addressing Memories) assim como interfaces de controlo e comunicação normalizadas. Os controladores
são servidores banalizados cuja especificidade está associada
ao software que executam. Ambos os factores poderão conduzir a uma descida significativa de custos.
Mas a vantagem mais importante advêm do facto de
que um controlador pode controlar simultaneamente dezenas
ou mesmo centenas de switches, o que permite desenvolver
no mesmo uma visão logicamente centralizada da rede. Tal
visão permite usar algoritmos mais simples que os algoritmos
distribuı́dos de coordenação e controlo subjacentes aos protocolos de rede usados actualmente. Espera-se que desta forma
seja mais fácil introduzir novas e mais sofisticadas formas
de controlo, ou seja, flexibilizar e banalizar a evolução e a
adaptabilidade do control plane.
Actualmente já existem diversos switches que suportam
OpenFlow e vários controladores OpenFlow. Os controladores
fornecem uma espécie de sistema de operação de rede que
suporta uma visão lógica da mesma, a interface com os
switches por OpenFlow e um ambiente de desenvolvimento
do tipo event driven para introdução de novas funcionalidades.
Alguns dos controladores mais citados são: NOX [8], POX [9],
Beacon [10] e o FloodLight [11].
Este artigo apresenta um trabalho que consistiu em introduzir no controlador FloodLight um conjunto de modificações
com o objectivo de optimizar o funcionamento de uma rede
de switches Ethernet, de tal forma que seja mais realista
trabalhar com uma única subnet IP, mesmo numa rede de
grande dimensão1 . Estas modificações têm como principal
contribuição novas implementações dos protocolos ARP e
IGMP e do encaminhamento do IP Multicasting.
As modificações e optimizações introduzidas reduzem a
utilização de difusão pelo protocolo ARP, encaminham o
tráfego unicasting usando o caminho mais curto na rede (funcionalidade já implementada no FloodLight) e implementam
o tráfego multicasting usando uma árvore de difusão óptima
por grupo IP e por emissor. Para a implementação desta
última funcionalidade foi também necessário introduzir uma
implementação do protocolo IGMP. As novas funcionalidades
foram desenvolvidas em Java para o FloodLight, e foram
testadas usando o simulador de redes OpenFlow Mininet [13].
A configuração da rede fı́sica é arbitrária, podendo incluir
canais redundantes e ciclos.
Na próxima secção apresenta-se brevemente o controlador
FloodLight e os módulos relevantes para este trabalho que
este implementa. Na secção III apresenta-se o módulo de
descoberta introduzido (que implementa os protocolos ARP
e IGMP) e as modificações no encaminhamento introduzidas
para suportar encaminhamento IP Multicasting. Na secção
seguinte é apresentada a avaliação do trabalho realizado.
Finalmente, na secção V, são apresentadas algumas conclusões
e discutido o trabalho futuro.
II.
C ONTROLO DE R EDES IP COM O C ONTROLADOR
F LOODLIGHT
Para a realização deste trabalho foi escolhido o controlador
FloodLight, devido a este ser considerado como tendo um
desempenho elevado, estar desenvolvido em Java e ter por
ambição controlar redes em produção. Quando comparado com
outros controladores é, no entanto, geralmente considerado
como mais difı́cil de modificar devido à sua maior complexidade.
O Floodlight fornece um framework de base constituı́do por
uma estrutura de execução baseada em módulos normalizados,
dinamicamente instanciáveis, e orientada a eventos com base
no paradigma editores/subscritores, uma thread pool, mecanismos normalizados de gestão de tabelas partilhadas pelos
B. Contribuições deste Trabalho
A maioria dos controladores acima citados já oferecem
módulos que permitem, através de OpenFlow, construir uma
110
1 Os requisitos de segurança ultrapassam o âmbito deste trabalho mas poderiam ser implementados com base no módulo de firewalling já disponibilizado
pelo Floodlight.
diferentes módulos, uma interface de diálogo com os switches
por OpenFlow etc.
Entre os módulos mais relevantes do FloodLight
encontram-se alguns dos que a seguir são indicados. O módulo
LinkDiscoveryManager realiza a gestão dos canais existentes
na rede através do protocolo LLDP (Link Layer Discovery Protocol). O módulo envia para os switches as mensagens LLDP
a serem flooded, processa a sua recepção pelos switches adjacentes e mantém uma visão centralizada dos canais existentes
na rede. O módulo TopologyManager gere a configuração da
rede e fornece serviços para cálculo de caminhos mais curtos
e árvores de cobertura de caminhos mais curtos com raiz num
nó dado. O módulo DeviceManager faz snooping dos pacotes
recebidos pelo controlador e gere uma tabela de dispositivos
ligados à rede mantendo sobre cada um diversos atributos
(switch e porta a que está ligado, endereços MAC e IP, . . . ).
O módulo Forwarding é responsável pela introdução de flows
(i.e., das respectivas regras nos switches) correspondentes ao
tráfego unicasting entre quaisquer dois devices. O FlowReconcileManager é responsável pela reconfiguração dos flows
unicasting na sequência de uma alteração da configuração
dos canais. Com base nestes módulos, o FloodLight gere
completamente uma rede L2 da forma a seguir apresentada.
Todo o tráfego multicasting ou broadcasting de nı́vel 2 é
encaminhado directamente pelo controlador pois os switches
não têm regras para o seu processamento de outra forma.
Assim, todos os frames com endereços MAC deste tipo são
enviados para o controlador e este é que decide, caso a caso,
se o frame deve ser ignorado ou flooded em função da porta
e switch onde foi recebido. Assim, por defeito, o FloodLight
usa inundações da rede para processar ARP requests, DHCP,
IGMP, IP Multicasting e outro tráfego em broadcasting ao
nı́vel L2. Para evitar broadcast storms, é usado um algoritmo
de inundação sobre uma árvore de cobertura de caminhos mais
curtos com raiz no switch de menor identificador (computada
de forma centralizada mas equivalente à definida pelo protocolo STP).
Em contrapartida, o controlador usa o tráfego que passa
na rede para preencher a sua tabela de devices (c.f. módulo
DeviceManager) pelo que sempre que recebe um primeiro
frame de um flow unicasting, instala regras nos switches
de tal forma que todo o tráfego desse flow (caracterizado
pelos endereços MAC e IP origem e destino) passa a ser
encaminhado pelo caminho mais curto. O controlador deixará
assim de receber estes pacotes enquanto o flow estiver activo.
III.
S OLUÇ ÃO I MPLEMENTADA
De modo a criar uma solução para o encaminhamento IP
optimizado no FloodLight, foi necessário criar um módulo
que se designou IPDiscoveryManager e modificar o módulo
Forwarding. Os objectivos do primeiro módulo são gerir uma
cache partilhada de ARP e responder a ARP Requets, assim
como gerir um directório de grupos IP Multicast, através
de uma solução baseada em IGMP. Adicionalmente, foi necessário alterar o módulo Forwarding, de forma a optimizar o
encaminhamento do IP Multicasting.
A. Optimização do protocolo ARP
O módulo DeviceManager, por defeito, regista os endereços
MAC dos computadores e utiliza o tráfego ARP e DHCP para
registar também os seus endereços IP. Esta implementação foi
alterada para que todos os pacotes IP que chegam ao controlador fossem usados para actualizar também os endereços IP do
emissor. O módulo IPDiscoveryManager usa as informações
recolhidas pelo DeviceManager como uma cache partilhada
de ARP. Com efeito, essa cache permite obter por soft state a
associação entre endereços IP Unicast e os endereços MAC.
Assim, o módulo IPDiscoveryManager intercepta os pedidos ARP (ARP Request) e, caso a informação solicitada se
encontre na cache há menos de um intervalo de tempo (daqui
para a frente designado por TRUST INTERVAL e actualmente
com o valor de 60 segundos) responde directamente com
um pacote ARP Reply. Caso contrário deixa o broadcasting
prosseguir. Com esta implementação o controlador terá de:
1) interceptar os pacotes ARP Request, verificando nas suas
estruturas de dados se o computador de destino enviou pacotes
que lhe chegaram há menos de TRUST INTERVAL segundos;
2) responder aos pacotes ARP Request caso a condição anterior
seja satisfeita.
Para se compreender melhor o papel desta cache é necessário ter em atenção que o controlador receberá os pacotes
emitidos por um computador IP sempre que estes não são
encaminhados directamente pelos switches. Isso passa-se com
todos os ARP Requests visto que os mesmos são emitidos em
difusão e com todos os primeiros pacotes de cada novo fluxo
unicast, sendo estes caracterizados por aparecer um pacote em
que os campos IP origem, IP destino ou VLAN são distintos
de outros anteriores. Sempre que um novo fluxo é iniciado,
o controlador instala o seu caminho nos switches através de
comandos OpenFlow. Esses comandos são válidos enquanto o
fluxo tiver actividade, e durante esse tempo os pacotes do fluxo
não chegam ao controlador. No entanto, qualquer ARP Request
assim como algum ARP Reply e ainda qualquer novo fluxo
que seja iniciado por qualquer outro par de computadores,
permitirá ao controlador enriquecer a sua cache com nova
informação.
Em alguns sistemas de operação (e.g., Mac OS X), sempre
que uma interface é activada, ou uma associação a um novo
AP WIFI tem lugar, o driver Ethernet emite um gratious
ARP 2 . Se esta implementação fosse normalizada, a cache do
controlador representaria quase sempre a realidade, e poder-seia praticamente suprimir todos as difusões relacionadas com o
protocolo ARP. De qualquer forma, como veremos a seguir, a
cache do controlador tem uma eficácia significativa na prática.
B. Gestão do protocolo IGMP - Recenseamento dos grupos
IP Multicast e da sua filiação
Para gerir os grupos multicast e os computadores subscritores dos mesmos, é utilizado o protocolo IGMP de acordo com
a sua norma (a implementação realizada baseia-se na versão
2), assumindo o controlador o papel de um router multicast.
Através do envio periódico de IGMP Queries e da análise
dos IGMP Reports, o módulo IPDiscoveryManager recenseia
os grupos IP Multicast existentes e os seus subscritores.
Adicionamente, esse recenseamento também tem lugar sempre
que os computadores emitem por sua iniciativa mensagens
IGMP Join e IGMP Leave. Se um subscritor se deixa de
manifestar durante um certo intervalo de tempo, isto é, não
2 i.e.,
um ARP Request do seu próprio endereço IP.
111
responde mais às IGMP Queries, o controlador considera que
o mesmo deixou de subscrever o grupo.
O controlador terá portanto de: 1) enviar periodicamente
IGMP Queries; 2) interceptar os IGMP Membership Reports
para saber os membros associados aos grupos e actualizar as
estruturas de dados; 3) interceptar IGMP Joins e Leaves e
actualizar as estruturas de dados; 4) limpar periodicamente das
estruturas de dados a informação sobre subscrições de grupos
desactualizadas.
Para clarificar a gestão do IGMP feita pelo módulo,
apresenta-se o pseudo-código correspondente, que ilustra
igualmente o estilo de programação usada no controlador.
Um thread (não apresentado) assegura a funcionalidade 4) do
módulo.
HashMap <group ip, list of devices> groups;
// in FloodLight, a device is a communication interface
HashMap <subscriber ip, timestamp> subscriberLastSeen;
received(PacketIn pi, Switch sw){
if (pi is an IGMP packet) return handleIgmp(pi, sw)
else .... // process other packet types
}
O passo seguinte consiste na instalação de flows nos
switches da árvore podada, configurando os mesmos para
fazerem inundação dos pacotes. Nos restantes instalam-se
flows para fazer drop dos mesmos pacotes. Na versão 1.0
do protocolo OpenFlow só é possı́vel associar uma acção de
forwarding a cada flow. A versão 1.3 já suporta associar várias
acções, o que permitiria enviar os pacotes apenas para os
canais que pertencem à árvore. Infelizmente, como a nova
versão ainda não está generalizada, e não é suportada pela
versão do software e do simulador que utilizámos, foi usada
a implementação com base em difusão para todas as portas.
Assim, quando o módulo Forwarding do Floodlight recebe um
pacote, e este é um pacote IP Multicast, realiza as computações
necessárias (lista de switches da árvore podada) e por fim
instala os flows nos switches. A implementação é descrita a
seguir em pseudo código, uma vez mais para ilustrar o estilo
de programação do controlador.
received(PacketIn pi, Switch sw){
if(pi is an IP multicast packet)
doMulticast(pi, sw)
else // process other packet types
}
handleIgmp(packetIn pi, switch sw){
if (pi.srcIp != controllerIp) {
device = device such that device.IP = pi.srcIP
// we must handle this packet,
// since it is a join/leave/report message
if (pi.type equals report or join){
groups.add(pi.dstIp, device)
update subscriberLastSeen
} else if (pi.type equals leave){
groups.remove(pi.dstIp, device)
}
}
// allow other modules to process the packet
return continues
}
doMulticast(packetIn pkt, switch sw){
BroadcastTree bt = topology.getBroadcastTree(pkt.src.srcSw);
tree = computeFloodSwitches(bt, pkt.src.srcSw, ptk.dst);
if(tree.contains(sw)){
installDoFloodFlow(tree, pkt, sw)
}else{
installDoDropFlow(pkt)
drop packet
}
}
//this method is called each 90 seconds by an endless thread
sendQuery(){
create packetOut and build it as an IGMP Report
write to switch with lower id
}
C. Encaminhamento IP Multicasting
Para optimizar a implementação do IP Multicasting usada
pelo Floodlight, é necessário evitar tráfego inútil e fazer chegar
cada mensagem difundida a cada subscritor pelo caminho mais
curto. Dispondo de informação sobre os subscritores de cada
grupo e, com base nos pacotes enviados para os mesmos, o
controlador, sempre que recebe um pacote IP Multicast com
origem no emissor E, e dirigido ao grupo G, deve assegurar o
seu encaminhamento através de uma árvore de caminhos mais
curtos com raiz em E e cobrindo apenas os subscritores de G.
O Floodlight já dispõe de uma forma de calcular uma
árvore de cobertura da rede com raiz num dado nó, usada
para o tráfego unicast. A implementação usa o algoritmo de
Dijkstra. Para adaptar estas árvores ao novo objectivo, foi
necessário podá-las para evitar mensagens inúteis, através de
um algoritmo, que introduzimos no FloodLight sob o nome
computeFloodSwitches, que computa uma árvore que cobre
todos os switches com membros de um grupo IGMP com
raiz no emissor. O algoritmo calcula um conjunto de switches
112
inicializado com a raı́z e todos os switches com subscritores
do grupo. Em seguida acrescenta a esse conjunto todos os
switches extra que são necessários para chegar de cada switch
no conjunto inicial até à raiz.
installDoFloodFlow(tree, packetIn, root){
initiate OFFlowMod
set match from packetIn
set idle and hard timeouts
set command to add flow and action to flood
set wildcards to inPort, dataLinkVLAN, dataLinkSrc,
dataLinkDst, networkMaskSrc, networkMaskDst
for each switch in tree {
if(switch.Id equals root.Id){
set match inPort to packetIn inPort
// the match port is the sender port
}else{
set match inPort to tree.getPort(switch)
// the match port is the port connecting this
// switch to the root switch
}
send flow to switch
}
send packetOut to sender switch
}
O pseudo código apresentado corresponde a uma
simplificação significativa da implementação visto que o
mesmo não ilustra o tratamento da modificação de grupos.
Como os timeouts dos flows usados são idle timeouts (i.e., os
flows só expiram na ausência de tráfego), se um emissor estiver
sempre a enviar tráfego, só o grupo inicial o irá receber e mais
nenhum membro que entre posteriormente. Por outro lado, se
um membro sair do grupo, poderá passar a existir tráfego inútil.
A solução é tratar as alterações de filiação. Na implementação,
o módulo Forwarding também processa os pacotes IGMP
enviados pelos devices para detectar eventuais alterações de
grupos com flows já instalados nos switches. Caso as alterações
conduzam a uma modificação da árvore de difusão do grupo, o
módulo procede as alterações necessárias dos flows. O mesmo
sucede quando há subscrições que expiram.
IV.
AVALIAÇ ÃO
De modo a avaliar esta proposta, utilizou-se o simulador
Mininet [13]. O Mininet é um simulador especial, disponibilizado em Linux, que permite simular uma rede de dimensão
significativa num único computador, mesmo com recursos
limitados. No nosso caso foi utilizado um computador com
CPU Intel i7 a 2.5 GHz e com 4 GBytes de RAM. Neste
computador o simulador corria numa máquina virtual própria,
ligada por IP ao sistema hospedeiro. Neste corria directamente
o servidor Floodlight e nele foi realizado o desenvolvimento
do código Java do mesmo. Na verdade, o controlador e a rede
simulada até podiam correr em computadores distintos.
O Mininet simula os switches através do módulo
OpenVSwitch, o qual implementa um verdadeiro switch OpenFlow. O simulador constrói uma rede de switches interligando
directamente verdadeiras interfaces virtuais do kernel Linux.
Assim, toda a comunicação entre os switches é directamente
assegurada pelo kernel. Finalmente, os computadores ligados
à rede simulada, partilham o file system e executam num
name space especı́fico, que faz com que cada um deles, seja
equivalente a um verdadeiro host Linux ligado à rede.
Cada um desses hosts pode executar directamente comandos e programas convencionais (e.g., ifconfig, tcpdump, sock,
bash, . . . ) através de uma consola de comando programável
que permite controlar a rede e executar comandos nos computadores à mesma ligados. Desta forma, é possı́vel instanciar
uma rede e um conjunto de computadores ligados à mesma,
lançar programas de geração de tráfego, lançar monitores de
tráfego, obter amostras dos pacotes que passam nos canais e
nas interfaces, etc. usando comandos Linux normais.
Os testes foram realizados usando um conjunto de scripts
em Python que controlavam a execução de programas nos
computadores ligados à rede simulada. Deste modo foi possı́vel
simular redes OpenFlow e controlar o fluxo de comandos que
os computadores executavam. Dois comandos foram usados
intensivamente, o programa sock e o programa tcpdump. O
programa sock, da autoria de Richard Stevens, disponibiliza
um grande leque de opções para demonstrar e testar as funcionalidades do TCP/IP, como por exemplo instanciar emissores
e receptores multicast. Deste modo, criaram-se scripts para
simular uma rede OpenFlow e ordenar que os computadores
dessa rede executem o programa sock. Assim, foi possı́vel
simular uma rede com grupos IP Multicast em funcionamento
e testar se o comportamento da mesma era o esperado, analisando os traces de pacotes recolhidos através de tcpdump.
Num teste final, mais completo, foi usada uma configuração
de 7 switches e 8 computadores Os últimos entravam e saiam
aleatoriamente de diversos grupos IP Multicast e, também
aleatoriamente, iniciavam a transmissão de fluxos de pacotes para os diferentes grupos. Este teste, mais abrangente,
Hora
1
2
3
4
5
6
7
Total
TI = 0
4872
5802
5575
6534
7205
5142
228
35358
TI = 60
1137
1495
2323
2443
1845
992
56
10291
TI = 1200
584
560
1409
1030
451
395
5
4434
Ganho
TI = 60
76,66%
74,23%
58,33%
62,61%
74,39%
80,71&
75,44%
70,89%
Ganho
TI = 1200
88,01%
90,35%
74,73&
84,24%
93,74%
92,32%
97,81%
87,46%
Tabela I: Número de ARP Requests por hora (variando TI) e
% de redução dos mesmos pela cache do controlador
permitiu, através de análise detalhada dos traces, verificar a
implementação realizada.
Apesar de não ter sido desenvolvida uma avaliação rigorosa
do desempenho em produção, o trabalho desenvolvido e os
testes realizados permitiram verificar as hipóteses iniciais, isto
é, uma vez vencida a barreira de penetrar na arquitectura do
controlador, do seu ambiente de programação e testes, e dos
detalhes de implementação do OpenFlow e da aproximação
SDN, os algoritmos de controlo da rede são certamente mais
simples do que a sua versão completamente distribuı́da.
Para avaliar a optimização das difusões de ARP Requests
foi usado um trace de pacotes recolhidos numa rede convencional e avaliados quais os ganhos que a cache partilhada de
ARP introduziria. O resultado deste avaliação foi saber qual
a redução de difusões que a mesma permitiria, usando vários
valores para o parâmetro TRUST INTERVAL (TI).
Na tabela I apresenta-se o número de ARP Requests
existentes na rede e o número de ARP Requests que existiriam
na mesma se se utilizasse o controlador com a optimização
desenvolvida. A tabela tem uma linha por cada hora de
tráfego recolhido e apresenta três hipóteses. No primeiro caso
é apresentado o número de ARP Requests total capturados
durante essa hora. No segundo caso é apresentado o número
de ARP Requests que existiriam na mesma rede durante essa
hora com TI = 60 segundos, e no terceiro caso com TI =
1200. Como se pode observar existe redução significativa das
difusões de ARP Requests.
V.
C ONCLUS ÕES E T RABALHO F UTURO
O trabalho realizado permite tirar várias conclusões. As
primeiras estão relacionadas com a extensibilidade e flexibilidade da aproximação SDN. Com efeito, foi possı́vel de forma
relativamente simples e com base em algoritmos centralizados
substituir integralmente a utilização de difusão por defeito
pelo uso de encaminhamento pelos caminhos mais curtos, quer
para o tráfego ponto a ponto (funcionalidade já disponibilizada
pelo Floodlight), mas também para o tráfego IP Multicasting.
Neste último caso o encaminhamento passou a ser realizado
com árvores de caminhos mais curtos optimizadas para cada
emissor e o grupo de subscritores do grupo. Ambas as formas
de encaminhamento funcionam perfeitamente numa rede de
switches organizada em malha, com caminhos alternativos e
redundantes.
Foi igualmente possı́vel optimizar a gestão dos mapeamentos de endereços IP / MAC e da filiação de grupos (protocolos
113
ARP e IGMP) através da utilização de uma gestão centralizada
de directórios. A actualização dos directórios é realizada pelos
switches enviando directamente para o controlador os pacotes
ARP Replies e IGMP Reports recebidos. Sempre que os
switches solicitam ao controlador que os instrua sobre a forma
de realizarem o encaminhamento, os pacotes IP também são
usados para actualizar o mapa de endereços IP / MAC.
O encaminhamento implementado constituı́ uma ilustração
particularmente feliz das vantagens potenciais do paradigma
SDN na medida em que se encaminha com qualidade equivalente à da utilização simultânea de OSPF para todo o
tráfego IP Unicasting, e IGMP e PIM-DM (PIM Dense Mode)
para o tráfego IP Multicasting, mas com uma implementação
baseada em algoritmos centralizados e sem todo o overhead de
controlo do PIM-DM. Com efeito, o PIM-DM usa inundações
periódicas particularmente ineficazes com uma distribuição
pouco densa de subscritores. Adicionalmente, os gestores da
rede não necessitam de introduzir endereçamento IP para
várias subnets distintas. A complexidade do novo control
plane é relativamente baixa, ao mesmo tempo que os switches
apenas necessitam de manter tabelas de flows grosso modo
equivalentes às tabelas de endereços MAC convencionais e
deixaram de executar protocolos e algoritmos distribuı́dos.
É no entanto necessário ter presente que estas vantagens
são apenas potenciais devido a diversos desafios levantados
pelas SDN.
Em primeiro lugar os problemas de escalabilidade [14]
quando a rede atinge dimensões muito significativas. Em
segundo lugar os problemas relacionados com a resistência a
avarias, desde logo as do controlador, mas também a forma
como este lida com as avarias da rede, sobretudo as que
conduzirem a partições da mesma. Intimamente relacionado
com este problema está o problema do bootstrap (como é
que os switches encontram o controlador e comunicam com
este e sobretudo como é que o controlador e os switches se
coordenam perante avarias). Por último lugar, os problemas
de segurança, em particular os relacionados com ataques de
negação de serviço ao controlador. Finalmente, é necessário
ter presente que a aproximação SDN introduz um novo ponto
a necessitar de normalização e coordenação para evitar a
dependência de soluções proprietárias. Tal dependência irá
deslocar-se para o software dos controladores, o qual é ainda
objecto de desenvolvimento e investigação.
Na implementação realizada diversas facetas relacionadas
com o controlo da rede pelo Floodlight, usando OpenFlow,
necessitam de ser melhor trabalhadas, nomeadamente as que
se discutem a seguir.
O envio de comandos para os switches pelo Floodlight é
assı́ncrono. Assim, podem eventualmente ocorrer race conditions porque um pacote de um flow pode chegar a um
switch antes do comando para processar o mesmo flow. Esta
situação não introduz necessariamente incorrecções, mas pode
introduzir processamento extra e inútil no controlador e atrasos
no encaminhamento. Este problema é delicado e necessita de
um tratamento mais aprofundado. Uma possı́vel forma de o
minorar, corresponde a impor uma ordem estrita de instalação
dos flows pelos diferentes switches, começando sempre a
instalá-los nos switches mais próximos da raiz.
da rede, o Floodlight dispõe de mecanismos que os detectam e
disparam as correspondentes notificações. Na implementação
do IP Multicasting será necessário acrescentar o tratamento
dessas notificações (por agora ignoradas) e reconfigurar todas
as árvores afectadas.
Tal como para a detecção de falhas, o Floodlight tem
mecanismos para identificar se um computador se moveu
na rede. O processamento desses eventos passaria por duas
situações: 1) a de um computador subscritor de um grupo
se mover e 2) a de um computador emissor se mover. Para
a primeira, é necessário, analogamente ao que acontece na
mudança da filiação de um grupo, calcular a diferença entre
a árvore antiga e a nova e proceder de forma idêntica. Na
segunda situação, o tratamento mais simples consistiria em
desinstalar a antiga árvore e instalar a nova.
O trabalho futuro passa igualmente pelo teste em produção
numa rede real.
AGRADECIMENTOS
São devidos a Samuel Neves e Luı́s Anjos pelo apoio na
recolha dos dados sobre o tráfego que permitiram avaliar o
ganho potencial da utilização da cache ARP.
R EFER ÊNCIAS
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
R. Perlman, “An algorithm for distributed computation of a spanning
tree in an extended lan,” ACM SIGCOMM Computer Communication
Review, vol. 15, no. 4, pp. 44–53, Sep. 1985.
R. J. Perlman, “Rbridges: Transparent routing,” in INFOCOM, 2004.
M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown, and
S. Shenker, “Ethane: taking control of the enterprise,” SIGCOMM
Comput. Commun. Rev., vol. 37, no. 4, pp. 1–12, Aug. 2007.
C. Kim, M. Caesar, and J. Rexford, “Seattle: A scalable ethernet
architecture for large enterprises,” ACM Trans. Comput. Syst., vol. 29,
no. 1, p. 1, 2011.
A. Greenberg, J. R. Hamilton, N. Jain, S. Kandula, C. Kim, P. Lahiri,
D. A. Maltz, P. Patel, and S. Sengupta, “Vl2: a scalable and flexible
data center network,” in SIGCOMM ’09, 2009.
N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson,
J. Rexford, S. Shenker, and J. Turner, “Openflow: enabling innovation
in campus networks,” SIGCOMM CCR, vol. 38, no. 2, pp. 69–74, Mar.
2008.
T. A. Limoncelli, “Openflow: A radical new idea in networking,” Queue,
vol. 10, no. 6, pp. 40:40–40:46, Jun. 2012.
N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown,
and S. Shenker, “Nox: towards an operating system for networks,”
SIGCOMM Comput. Commun. Rev., vol. 38, no. 3, pp. 105–110, Jul.
2008.
“Pox project,” http://www.noxrepo.org, [Acedido em outubro de 2013].
D. Erickson, “Baecon a java-based openflow controller,” https://
openflow.stanford.edu/display/Beacon/Home, [Acedido em outubro de
2013].
“Floodlight project,” http://floodlight.openflowhub.org, [Acedido em
outubro de 2013].
Y. Nakagawa, K. Hyoudou, and T. Shimizu, “A management method
of IP multicast in overlay networks using openflow,” in Proceedings of
the first workshop on Hot topics in software defined networks - HotSDN
’12. New York, New York, USA: ACM Press, 2012, p. 91.
B. Lantz, B. Heller, and N. McKeown, “A network in a laptop: rapid
prototyping for software-defined networks,” in Proceedings of HotnetsIX, ser. Hotnets-IX. New York, NY, USA: ACM, 2010, pp. 19:1–19:6.
S. H. Yeganeh, A. Tootoonchian, and Y. Ganjali, “On scalability
of software-defined networking,” Communications Magazine, IEEE,
vol. 51, no. 2, pp. 136–141, 2013.
Se existirem problemas com os switches ou com os canais
114
Automatização de Testes SIP
∗ Centro
David Gonçalves∗ , Pedro Sousa∗ , António Amaral† and António Costa∗
Algoritmi, Universidade do Minho, [email protected], {pns,costa}@di.uminho.pt
† PT Inovação, [email protected]
Abstract—As redes IP são actualmente as principais infraestruturas de comunicação utilizadas por um conjunto crescente
de aplicações e serviços heterogéneos, nos quais se incluem os
serviços de voz. Neste sentido, as funções de transmissão e gestão
de sessões são muitas vezes asseguradas por protocolos dedicados,
como seja o exemplo do Real-Time Transport Protocol (RTP) e o
Session Initiation Protocol (SIP).
O protocolo SIP apresenta um papel preponderante na gestão
de sessões, desempenhando funções vitais num conjunto extenso
de soluções. Contudo, a disseminação do protocolo acarreta
alguns desafios, tais como a validação e teste de soluções SIP.
Estes processos de validação necessitam de considerar diversos
fatores, como seja o caso da análise de cabeçalhos, validação
de valores dinâmicos, verificação de fluxos de mensagens, entre
outros. Nesta perspetiva, a validação manual de soluções SIP
apresenta-se como um processo moroso e dispendioso, sendo
crucial o desenvolvimento de processos automatizados nesta área.
Neste contexto, este resumo alargado aborda e analisa de
forma integrada a temática geral da validação de soluções
SIP, apresentando também ferramentas e aplicações capazes de
auxiliarem os processos de automatização de testes de soluções
SIP.
No que respeita à sinalização, o protocolo Session Initiation
Protocol (SIP) [3] apresenta-se como um protocolo preponderante no estabelecimento de sessões, sendo o mesmo definido
na RFC 3261 [3]. Em termos funcionais, o protocolo SIP opera
a nı́vel aplicacional seguindo o modelo cliente-servidor para
a troca de mensagens entre os participantes da sessão.
No que respeita às mensagens trocadas, o SIP apresenta as
mensagens em formato texto, sendo de simples interpretação
para o utilizador, mas de difı́cil interpretação integral para os
sistemas computacionais.
Embora o formato das mensagens SIP favoreça a validação
manual, a diversidade destas torna o processo de validação
manual moroso e propenso a erros, verificando-se a necessidade de automatizar o processo de validação. Contudo, a
implementação e validação de soluções com elevada diversidade, tal como acontece com o protocolo SIP, torna a tarefa
de automatização árdua e de difı́cil implementação.
Ao longo do resumo são discutidas as dificuldades associadas aos processos de validação de soluções SIP bem como
estratégias gerais de um possı́vel processo de automatização.
I. I NTRODUÇ ÃO
A proliferação das redes IP veio mudar o modo como as
pessoas interagem e comunicam. O impacto desta tecnologia
faz-se sentir tanto nos utilizadores como nos fornecedores de
serviço, tendo pois consequências no que respeita às receitas
obtidas pelas redes de telecomunicações [1].
As soluções de comunicação por voz em redes IP
denominam-se usualmente por soluções Voice over IP (VoIP),
caracterizando-se como soluções capazes de converter sinais
analógicos de voz em sinais digitais passı́veis de serem transmitidos sobre uma rede comutada de pacotes. No que diz
respeito às vantagens do VoIP, estas apresentam-se distintas
para utilizadores finais, empresas e operadores tendo contudo,
um principio base comum, diminuição de custos comparativamente com serviços das redes telefónicas.
Em termos protocolares, as soluções VoIP necessitam de
possuir por base mecanismos de sinalização e transmissão
dos media, capazes de permitir o estabelecimento de uma
sessão e a correspondente troca de dados sobre a mesma.
Em relação aos protocolos usados para a transmissão de
dados, destaca-se o protocolo Real-Time Transport Protocol
(RTP) [2], caracterizado como um protocolo de transporte de
dados independente das camadas inferiores.
Este trabalho é financiado por Fundos FEDER através do Programa
Operacional Fatores de Competitividade – COMPETE e por Fundos Nacionais
através da FCT – Fundação para a Ciência e Tecnologia no âmbito do Projeto:
FCOMP-01-0124-FEDER-022674. Agradeço à PT Inovação, a possibilidade
para a realização do trabalho descrito neste artigo.
II. M OTIVAÇ ÃO
Em termos gerais, a qualidade de um projeto encontra-se
diretamente relacionada com a capacidade dos testes validarem
todos os requisitos considerados. Contudo, o mapeamento de
requisitos em testes e a execução destes na sua totalidade
apresenta-se como uma tarefa morosa e de difı́cil alcance.
No que respeita à realização de validações de soluções SIP,
estas necessitam de ser validadas sobre o conjunto de equipamentos que possuem intervenção no fluxo de mensagens, tendo
pois cada equipamento de ser validado de forma singular.
Em termos de condicionantes, para além do elevado
número de validações a realizar sobre diferentes equipamentos,
verificam-se obstáculos associados com as próprias caracterı́sticas das mensagens, quer seja devido à multiplicidade
de informação presente, ao dinamismo de certos valores ou
relacionadas com o tipo de mensagem e a sua integração no
fluxo geral de mensagens.
A nı́vel estrutural as mensagens SIP seguem o modelo
definido na RFC 2822 [4], sendo constituı́das por uma
start-line, um conjunto de cabeçalhos e o corpo das mensagens. Aquando da validação de soluções SIP, o foco principal centra-se na validação dos valores associados com os
cabeçalhos presentes nas mensagens. Sendo estes em grande
número, encontrando-se definidos só na RFC base mais de 40
cabeçalhos distintos [3].
Juntamente com o elevado número de cabeçalhos verificamse dificuldade na validação dos mesmos pelo dinamismo
115
que estes apresentam. Os valores dos cabeçalhos SIP são
definidos por uma gramática Augmented Backus–Naur Form
(ABNF) [5] apresentando-se restritos, mas com um grau de
dinamismo elevado comparativamente com os cabeçalhos da
maioria dos protocolos.
Este conjunto extenso de problemáticas tem relevância tanto
ao nı́vel académico como empresarial apresentando-se util para
equipas multidisciplinar que operem directa ou indirectamente
com o protocolo SIP. Verificando-se assim a necessidade de
desenvolver métodos capazes de analisarem soluções SIP de
forma rápida e eficaz, permitindo a realização cómoda de
validações e teste de soluções SIP.
III. M ETODOLOGIA DE TESTE E VALIDAÇ ÃO DE CEN ÁRIOS
SIP
Tendo como ponto de partida as dificuldades de validação de
soluções SIP anteriormente identificadas, começou-se a desenvolver trabalho tendo como propósito final a criação de uma
solução/metodologia capaz de validar soluções SIP de forma
rápida e simples. Neste processo terão que ser consideradas
as questões centrais do controlo dos inputs e outputs dos
equipamentos, e a execução dos testes em condições em tudo
semelhantes às condições que a solução terá no ambiente final.
O controlo dos inputs, outputs é fundamental. A solução
a validar sobre o ponto de vista do equipamento possui
mecanismos de tratamento das mensagens SIP consoante a
informação que chega ao equipamento na mensagem, sendo
crucial conhecer e controlar bem a informação que é enviada
para e do equipamento para se conseguir testar diferentes
cenários com a precisão necessária.
A solução proposta para esta temática identifica a necessidade de ostracizar o elemento a validar para um ambiente
controlado onde os inputs e outputs encontram-se ao encargo
da equipa de validações.
Neste tipo de cenários é configurado o equipamento para
operar com dois terminais a executar software de emulação
SIP. A escolha de ferramentas de emulação em detrimento de
terminais fı́sico justifica-se pela capacidade que estas ferramentas possuem de manipular diretamente as mensagens do
fluxo, permitindo criar cenários idênticos aos presentes na rede
onde o equipamento a validar se encontrara implementado.
Relativamente à criação das mensagens, como indicado
anteriormente, as mensagens SIP possuem um tamanho avultado sendo assumido por alguns autores o valor médio de
731 bytes por mensagem [6]. Estes valores põem em causa
a criação manual das mensagens no script a emular, sendo
necessário desenvolver mecanismos automáticos de geração
de scripts. Para endereçar esta questão, optou-se pelo uso de
aplicações capazes de através de capturas de rede gerar scripts
de emulação de tráfego. Desta forma consegue-se garantir a
exatidão dos comportamentos, avaliando se os mesmos estão
alinhados com a realidade.
IV. F ERRAMENTAS Open Source
Ao nı́vel de ferramentas de emulação de tráfego SIP, existe
um conjunto extenso de possibilidades, tais como Seagull
[7], SIP Tester [8], SIPp [9], entre outros. Das ferramentas
116
analisadas a que se revelou mais adequada foi o SIPp, devido
aos mecanismos que possui de validação de mensagens, à
aceitação que a ferramenta tem por parte de entidades relevantes na área do SIP como a Fraunhofer [10] e pelo conjunto
de aplicações de tratamento de tráfego que dispõe.
No que respeita a geração de cenário, são analisadas duas
aplicações que através de capturas de rede (ficheiros PCAP)
redigem cenários SIPp.
A. SIPp
O SIPp é um projeto open source desenvolvido tendo como
propósito a geração de tráfego SIP e a validação do mesmo [9].
Em termos de modelo funcional, o SIPp opera sobre ficheiros
XML onde são descritos os cenários a executar de forma
simples e concisa, sendo fácil o processo de adaptação dos
mesmos.
Ao nı́vel protocolar, a ferramenta encontra-se equipada com
suporte para protocolos diversos como o IPv4, IPv6, UDP,
SCTP entre outros, permitindo o desenvolvimento de cenários
próximos da realidade, conjugando scripts de emulação com
equipamentos fı́sicos. Relativamente a cenários de testes, um
caso prático de integração da ferramenta de emulação com
equipamentos, apresentar-se-ia semelhante a Figura 1.
Fig. 1: Fluxo de estabelecimento de sessão entre UAC e UAS
Os ficheiros SIPp representados como UAC (cliente) e UAS
(servidor) apresentam o mesmo fluxo, mas com comportamento complementar um do outro. Como indicado anteriormente o SIP segue um modelo cliente-servidor onde para um
dado request (ex. INVITE), é enviada uma response (ex. 200
OK).
Quando o SIPp UAC faz o envio de um request o UAS tem
no seu fluxo a indicação do request enviado pelo UAC e viceversa mantendo desta forma o fluxo das mensagens (excerto
I de cenário entre o UAC e o UAS).
Aquando do término da criação dos cenários SIPp, existe
a necessidade de aplicar expressões regulares ao mesmo de
Exc. I: Interligação entre o INVITE do UAC e UAS
<send>
INVITE ...
</send>
<recv request=”INVITE” >
</recv>
forma a validar valores especı́ficos da mensagem. Em termos
funcionais, na mensagem que se quer validar indica-se o valor
expectável para o cabeçalho a validar, estando este mapeado
numa expressão regular. Aquando da execução, o próprio SIPp
encarrega-se de analisar a mensagem recebida e verificar se a
mesma apresenta o valor esperado.
O conteúdo da expressão é validado dentro de uma tag
<ereg> indicando que componente da mensagem se pretende
validar, que tipo de validação e qual a expressão regular
com que se pretenda que exista match. Em termos estruturais
apresenta-se semelhante ao evidenciado no excerto de código
IV.
B. Preparação de testes a partir de cenários reais
Como referido anteriormente de forma a tornar o processo
de geração de scripts uma tarefa menos penosa recorre-se
ao uso de aplicações capazes de, forma automática, gerar os
cenários pretendidos. De entre as aplicações destacam-se o
pcap2sipp [11], sniff2sipp [12].
Das aplicações de estudadas o sniff2sipp apresentou-se
como a aplicação mais adequada para a geração de scripts,
apresentando-se como uma aplicação mais madura, operando
com um conjunto de protocolos superior e capaz de realizar
scripts através de capturas ou de traces diretos na rede.
V. E XEMPLO DE U TILIZAÇ ÃO
O conjunto das ferramentas apresentadas possibilita a
validação de soluções SIP sobre diferentes cenários. A tı́tulo
de exemplo demonstra-se de seguida os diferentes passos a
seguir para a validação de um equipamento SIP com funções
de encaminhamento e manipulação de cabeçalhos.
A validação dos testes inicia-se com o processo de criação
dos scripts SIPp, sendo esta tarefa levada a cabo pelo
sniff2sipp. Tendo a captura com o comportamento a validar,
basta executar a aplicação indicando o nome da captura a gama
de portos usada pelo SIP como verificado na excerto II.
Exc. II: Comando de arranque da aplicação sniff2sipp
./sniff2sipp -f call.cap -p 5060-5062
Após a execução do comando são gerados os ficheiros do
cliente e do servidor. No ficheiro do cliente é apresentado o INVITE a ser enviado para o equipamento a validar (excerto III),
enquanto que do lado do servidor é indicada a mensagem que
se espera receber.
Com o envio e a espera de receção da mensagem já se
valida a solução ao nı́vel do fluxo. Contudo, o equipamento
a validar substitui o user-part do cabeçalho To pelo valor
“siphomenetwork”, sendo necessário aplicar uma expressão
regular ao INVITE a receber no servidor (excerto IV)
Estando os cenários SIPp preparados e com as expressões
regulares embebidas, basta executar os mesmos.
Exc. III: Mensagem INVITE em cenário SIPp UAC
INVITE sip:[service]@[remote ip] [remote port] SIP/2.0
Via: SIP/2.0/UDP [local ip]:[local port];branch=[branch];rport
Max-Forwards: 70
Contact: <sip:test1@[local ip]:[local port]>
To: <sip:[service]@[remote ip]:[remote port]>
From: <sip:test1@[local ip]:[local port]>;tag=[pid]
Call-ID: [call id]
CSeq: 1 INVITE
Exc. IV: Mensagem INVITE em cenário SIPp UAS
<recv request=”INVITE” crlf=”true”>
<action >
<ereg regexp=”<sip:siphomenetwork@*” search in=”hdr” header=”To”/>
</action>
</recv>
Através da plataforma, consegue-se realizar validações em
ambiente emulado como se de tráfego real se tratasse permitindo assim executar e validar os diferentes cenários de
forma mais autónoma e controlando o cenário de testes na
sua totalidade.
VI. C ONCLUS ÕES
As soluções tecnológicas envolvendo o protocolo SIP
encontram-se cada vez mais presentes no dia-a-dia das
pessoas, verificando-se a necessidade de desenvolver estratégias auxiliares na resolução de tarefas morosas e dispendiosas, como é o caso dos processos de validação e
testes de infra-estruturas VoIP. Desta forma, a definição de
estratégias eficazes, recorrendo à utilização de ferramentas de
automatização, torna-se uma mais-valia indispensável nesta
área. A utilização destes mecanismos é útil, tanto no processo
de validação de soluções, como no auxı́lio ao estudo de
anomalias, permitindo pois um mais rápido desenvolvimento
e implementação de soluções nos clientes finais.
Através da solução delineada, que tem por base ferramentas
open source, é pois possı́vel acelerar todo o processo de
desenvolvimento de soluções SIP, possibilitando às equipas
de desenvolvimento a definição de um framework simples mas
eficaz para o teste e deteção de anomalias nestes ambientes.
R EFERENCES
[1] Antonio Cuevas, J.I. Moreno, P. Vidales, and H. Einsiedler. The ims
service platform: a solution for next-generation network operators to be
more than bit pipes. Communications Magazine, IEEE, 44(8):75–81,
2006.
[2] H. Schulzrinne S. Casner R. Frederick V. Jacobson. Rtp: A transport
protocol for real-time applications, 7 2003. RFC 3550.
[3] J. Rosenberg H. Schulzrinne G. Camarillo A. Johnston J. Peterson R.
Sparks M. Handley E. Schooler. Sip: Session initiation protocol, 6 2002.
RFC 3261.
[4] P. Resnick. Internet message format, 4 2001. RFC 2822.
[5] D. Crocker P. Overell. Augmented bnf for syntax specifications: Abnf,
1 2008. RFC 5234.
[6] Masataka Ohta. Overload control in a sip signaling network. International Journal of Electrical and Electronics Engineering, 2009.
[7] HP OpenCall Software. Seagull: an open source multi-protocol traffic
generator @ONLINE, 2 2009.
[8] StarTrinity.com. Freeware sip tester (call generator, sip/rtp stressing tool,
dos simulator) @ONLINE, 2013.
[9] R. Day. Welcome to sipp @ONLINE, 4 2013.
[10] Fraunhofer FOKUS. Links for ims developers @ONLINE, 2008.
[11] C. Oancea. pcap2sipp @ONLINE, 4 2013.
[12] Digium. digium: The asterik company @ONLINE, 2013.
117
118
Transmissão de vı́deo com múltiplas descrições com débitos
variáveis em canais multi-percurso com débito assimétrico
Pedro Correia
Pedro A. Amado Assunção
Vı́tor Silva
Instituto Politécnico de Tomar/EST
Portugal
[email protected]
Instituto Politécnico de Leiria/ESTG
Portugal
[email protected]
Universidade de Coimbra/DEEC
Portugal
[email protected]
Resumo—Este artigo propõe um método para codificação e transmissão de vı́deo, usando múltiplas descrições não balanceadas com
débitos variáveis em canais assimétricos multi-percurso. O controlo
de débito de cada descrição é realizado através da combinação dos
parâmetros de codificação escalar não balanceada (U-MDSQ), com base
num método que explora a relação linear entre o número de bits e a
percentagem de coeficientes da transformada no domı́nio MDSQ. Os
resultados de simulação mostram que o método proposto garante uma
melhoria de desempenho em transmissão de vı́deo através de canais multipercurso, com restrições na capacidade de transmissão e com taxas de
perda de pacotes assimétricas, quando comparado com esquemas MDSQ
balanceado (B-MDSQ). Deste modo, a sua utilização traz vantagens
em sistemas de comunicação de vı́deo que usam redes ou canais de
transmissão com múltiplos percursos e com restrições na capacidade
disponı́vel ou taxas de perdas assimétricas.
de bits gerados e o número de coeficientes da transformada que são
nulos no contexto MDSQ. Demonstra-se que esta relação linear se
mantém em cada descrição quando se aplica na cascata quantificaçãoMDSQ aos coeficientes da transformada usada em H.264/AVC.
O método proposto permite reservar e controlar débitos binários
diferentes em cada descrição de acordo com a restrição global de
largura de banda e distribuição entre descrições sem degradar o
desempenho débito-distorção MDC global. Apesar dos métodos de
controlo de débito baseados no modelo linear terem sido usados
noutros contextos, o seu uso em esquemas MDSQ não tem sido muito
investigado, conferindo assim um aspecto inovador ao caso estudado
neste artigo.
I. I NTRODUÇ ÃO
II. M ODELO ρ PARA MDSQ
Nos ambientes heterogéneos das redes de comunicação atuais,
a grande variedade de tecnologias de rede, assim como a rápida
evolução das suas arquiteturas e topologias, tem dado origem ao
aparecimento de novos métodos que permitam solucionar os problemas de erros de transmissão e perdas. A transmissão de vı́deo
com diversidade de canais é vista como um esquema interessante de
comunicação para fazer face a este cenário. Enquadrando-se neste
contexto, a codificação de Vı́deo com Múltiplas Descrições (MDC)
é uma abordagem de codificação eficiente de modo a aumentar a
robustez em canais sujeitos a erros, particulamente em aplicações
que permitem a utilização de vários caminhos de comunicação entre
o servidor e um determinado cliente.
Na codificação de vı́deo com múltiplas descrições (MDC), a fonte
de sinal é representada através da codificação de vários fluxos de
dados (descrições), onde cada um pode ser descodificado de forma
independente. Por outro lado, as descrições podem ser combinadas
entre si, obtendo-se assim uma descodificação com melhor qualidade
quando comparada com a descodificação independente [1].
A maioria das arquitecturas MDC usam N = 2 descrições com
débitos e distorções semelhantes, i.e. balanceadas. No entanto, para
que o sistema possa lidar com as caracterı́sticas variáveis dos canais,
em termos de largura de banda disponı́vel e taxas de perda de
pacotes, o codificador MDC necessita de adaptar de forma dinâmica
os débitos de transmissão de cada descrição por forma a minimizar
a distorção no descodificador. Deste modo, esta necessidade obriga
que os esquemas de transmissão MDC possuam a capacidade de gerar
débitos assimétricos para cada descrição (MDC não balanceado (UMDC)), podendo descodificar cada descrição de forma independente
para resoluções e/ou qualidades diferentes.
Usando o conceito de codificação com múltiplas descrições baseado em quantificação escalar (MDSQ) balanceado [2], este artigo usa
um novo método MDSQ baseado em tabelas de indexação variáveis
[3]. Neste artigo é avaliada a relação linear existente entre o número
O modelo ρ é baseado na dependência linear entre o número de bits
produzido por um codificador e a percentagem de coeficientes nulos
resultantes da transformada ρ, depois da quantificação [4]. Este é um
modelo bastante simples e pode ser expresso pela seguinte equação,
usando apenas um parâmetro φ,
R(ρ) = φ(1 − ρ),
(1)
onde R(ρ) é o número de bits obtido como função de ρ, i.e. a
percentagem de coeficientes nulos. O parâmetro do modelo é obtido
através das unidades de codificação anteriores. A função débitoquantificação (R-Q) é obtida de forma indirecta através da relação
entre a estatı́stica da fonte com o passo de quantificação. Consequentemente, é necessário calcular a estatistica da fonte, que pode
ser obtida baseada em modelos paramétricos [5]. Outra abordagem
possı́vel consiste em usar os dados de unidades de codificação
(imagem) anteriores, de modo a poder obter a estatı́stica da fonte
de forma operacional para posteriormente calcular um parâmetro de
quantificação (QP) adequado para um determinado valor de ρ.
A Fig. 1 mostra a dependência entre o número de bits produzido
em cada descrição, resultante da codificação MDSQ de imagens I e P,
e a percentagem de coeficientes nulos antes de ser aplicado MDSQ.
Este exemplo mostra que as descrições balanceadas e não balanceadas
seguem uma relação linear entre número de bits e percentagem de
zeros antes de MDSQ. É interessante verificar que a proporcionalidade é mantida para diferentes percentagens de balanceamento. Esta
caracteristica é particularmente evidente em MDSQ balanceado e para
MDSQ não balanceado em débitos binários mais elevados.
III. C ONTROLO DE D ÉBITO U-MDSQ
Esta secção apresenta uma nova abordagem para controlo do
débito binário em codificadores U-MDSQ, baseada no conceito de
atribuição de ı́ndices para MDC não balanceado. Esta abordagem
permite que o débito binário entre descrições possa ser dinâmico
119
Bal.-D1
Bal.-D2
Unbal. Z=0-D1
Unbal. Z=0-D2
Unbal. Z=1-D1
Unbal. Z=1-D2
Unbal. Z=2-D1
Unbal. Z=2-D2
Unbal. Z=3-D1
Unbal. Z=3-D2
300
rate(kbits/frame)
250
200
150
250
Balanceado-D1
Balanceado-D2
Não bal. Z=0-D1
Não bal. Z=0-D2
Não bal. Z=1-D1
Não bal. Z=1-D2
Não bal. Z=2-D1
Não bal. Z=2-D2
Não bal. Z=3-D1
Não bal. Z=3-D2
200
kbits/imagem
350
150
(
100
100
0
40
50
60
70
80
Percentage of zeros before MDSQ
90
0
55
60
(a) Imagens I.
Figura 1.
65
70
75
80
85
Percentagem de zeros antes de MDSQ
90
95
(b) Imagens P.
Relação entre percentagem de zeros e débito, sequência bus.
através da alteração das tabelas de indexação do método MDSQ [3].
O método de controlo de débito proposto tem por objetivo produzir
duas descrições com débitos diferentes, baseado na dependência
linear entre percentagem de zeros dos coeficientes da transformada
e o número de bits obtidos em cada descrição depois de MDSQ.
É utilizado um buffer comum às duas descrições. O débito global
gerado pelo esquema MDSQ é controlado através a escolha adequada
do parâmetro de quantificação QP0 do codificador central e também
pela escolha das tabelas de indexação MDSQ, de acordo com um
débito desejado pré-definido.
Este método opera em dois nı́veis distintos: GOP (Grupo de
imagens) e imagem. Ao nı́vel de GOP, o algoritmo de controlo
de débito determina o quantidade de bits necessária para manter
um nı́vel adequado de preenchimento do buffer de acordo com um
determinada restrição de largura de banda do canal. Adicionalmente,
a percentagem de balanceamento entre descrições é também definida
de acordo com o débito alocado a cada uma das descrições. O
método proposto é pois uma extensão do modelo usado em [6]
de modo a incluir um objectivo de débito adicional, de acordo
com a percentagem de balanceamento, para que se possa definir
o débito de cada descrição para um determinado débito total. Ao
nı́vel da imagem, o método de controlo de débito é composto por
duas etapas. A primeira etapa define o objectivo para débito global
(i.e, para ambas as descrições) com base na ocupação do buffer e
das medidas de complexidade da imagem. Adicionalmente, calcula
o objectivo de débito para a descrição principal (a que possuir o
débito maior), tendo em conta a percentagem de balanceamento entre
descrições. A segunda etapa usa o modelo ρ aplicado à descrição
principal para calcular a percentagem de zeros, ρ, necessária para
cumprir o ojectivo de débito. Tendo este valor segue-se o cálculo do
passo de quantificação δ que permite obter o débito necessário e o
correspondente parâmetro de quantificação QP0 . Cada descrição é
codificada com base no QP0 e na matriz de indexação determinada
para a percentagem de balanceamento desejada. Depois de codificar
ambas as descrições, o parâmetro do modelo ρ e a tabela de indexação
são actualizadas para a próxima imagem.
A. Controlo de débito a nı́vel de imagem
O objectivo do número de bits para cada descrição Ti (j) e a
percentagem de balanceamento (π1 , π2 ), é dado pela expressão,
Ti (j)D1 = Ti (j) × π1
Ti (j)D2 = Ti (j) × π2
(2)
O algoritmo de controlo segue a percentagem de balanceamento
desejado através do ajuste do parâmetro Z e consequentemente da
matriz de indexação, baseada no número de bits obtido em cada
descrição na imagem anterior. Este ajuste é feito usando o modelo
linear,
120
(3)
Posteriormente, tendo em conta as caracterı́sticas descritas na
secção II, é aplicado o modelo ρ para determinar o parâmetro de
quantificação central (QP0 ) para um determinado objectivo de débito
em cada descrição. Tendo em conta os resultados obtidos, o modelo
possui uma maior linearidade na descrição com maior débito. Deste
modo, o modelo é aplicado à descrição principal usando as estatı́sticas
da imagem anterior do mesmo tipo. Assim, o parâmetro do modelo,
φi , para a imagem i é calculada de acordo com,
50
50
π1 (Z, t) = mt Z + bt , − 1 ≤ Z ≤ 3, t = I, P, B
π2 (Z, t) = 100 − π1 (Z, t)
φi = Ri−1 /(1 − ρi−1 ).
(4)
Depois de calcular φi para uma dada imagem e o correspondente
objetivo de débito para a descrição principal, é calculado o valor ρ
correspondente (i.e. a percentagem de zeros) usando a equação (1).
Através do histograma dos coeficientes da transformada da imagem
anterior, é definido o valor do passo de quantificação δ, de acordo
com a percentagem de zeros ρ necessária para produzir o número
de bits pretendido. A relação entre δ e ρ é estabelecida através
de uma tabela de correspondência, preenchida com base nos dados
obtidos na imagem anterior. Finalmente, o parâmetro de quantificação
é determinado a partir da expressão [5],
3δ
)c, 0 ≤ QP0 ≤ 51.
(5)
2
O valor de QP0 para as imagens B são obtidas por interpolação
das imagens de referência vizinhas (I ou P), tendo em conta a
correspondente distância temporal. O valor absoluto da diferença
entre imagens adjacentes é limitada ao valor máximo 2, por forma a
garantir uma qualidade visual uniforme ao longo da sequencia de
vı́deo. As matriz de indexação usada é a mesma da imagem de
referencia mais próxima.
QP0 = b6 × log2 (
IV. AVALIAÇ ÃO DE D ESEMPENHO
O desempenho do método de controlo de débito baseia-se na
simulação para transmissão MDC em canais com débito assimétrico
com vários cenários de condições de perda de pacotes, comparando os
métodos MDC não balanceado com MDC balanceado. Foram usadas
para a simulação as sequencias foreman e bus, com resolução CIF,
frequência de imagem= 15Hz, GOP=IPBBP... e 16 imagens/GOP.
Foi usada a arquitectura MDC em malha fechada descrita em [7]
para implementação do método de controlo de débito para MDC
não balanceado. Na simulação foi usado uma dimensão do buffer
B = Channelrate∗1.5 (em bits) com um atraso inicial D = B∗0.8,
equivalente a um atraso de 1.2 segundos. São definidos como objectivos, o débito global assim como as percentagens de balanceamento
entre descrições.
A. Transmissão em canais com débito assimétrico
O método de controlo de débito foi avaliado em cenários de
transmissão de video com perda de pacotes em canais com débitos
diferentes, mas também com taxas de perda de pacotes diferenciados.
O débito de saı́da foi definido a 1 Mbps, usando um número fixo de
10 pacotes por imagem, com 20% de redundância da informação
lateral para controlo de distorção, resultante num débito global de
1.2 Mbps. Os débitos e nı́veis de resundância são idêntidos para os
esquemas balanceados e não balanceados. A informação adicional é
assimetricamente distribuı́da nas duas descrições de modo a manter
as percentagens de balanceamento especificadas como objectivo em
41
39
38
37
36
35
0
32
31
30
29
2
4
DLR(%)
6
8
28
0
10
(a) Sequencia foreman.
34
40
33
39
32
38
37
35
0
4
DLR(%)
6
8
10
PSNR média usando canais com taxa de perda de pacotes (PLR)
41
36
2
(b) Sequencia bus.
PSNR(dB) Média
PSNR(dB) Média
Figura 2.
iguais.
Bal. (600 kbps; 600 kbps)
Não bal. (480 kbps; 720 kbps)
Não bal.(360 kbps; 840 kbps)
33
PSNR(dB) Média
PSNR(dB) Média
34
Bal.(600kbps,600 kbps)
Não bal.(480 kbps, 720 kbps)
Não bal. (360 kbps; 840 kbps)
40
Não bal. (360 kbps; 840 kbps)-(70%,30%)
Bal. (600 kbps; 600 kbps)-(70%,30%)
Não bal. (480 kbps; 720 kbps)-(60%,40%)
Bal. (600 kbps; 600 kbps)-(60%,40%)
2
4
DLR(%)
6
31
30
29
8
(a) Sequência foreman.
10
28
0
Não bal. (360 kbps; 840 kbps)-(70%,30%)
Bal. (600 kbps; 600 kbps)-(70%,30%)
Não bal. (480 kbps; 720 kbps)-(60%,40%)
Bal. (600 kbps; 600 kbps)-(60%,40%)
2
4
DLR(%)
6
8
10
(b) Sequência bus.
Figura 3. PSNR média usando canais com taxas de perda de pacotes (PLR)
diferentes.
cada descrição. A simulação de perdas de pacotes foram realizadas
usando o modelo de Markov Gilbert-Elliott de 2 estados por forma
a gerar várias taxas médias de perda de pacotes (PLR) e valores
médios de perdas em rajada (burst) [8]. De modo a obter resultados
estatisticamente relevantes, a transmissão de cada sequência (foreman
and bus) foi simulada 50 vezes para cada condição de rede especificada. Nesta simulação, foram consideradas taxas de perda de pacotes
médias entre 0% e 10% com um burst médio de 4 pacotes.
São considerados dois cenários de aplicação para comparação entre
MDSQ balanceado e não balanceado.: i) canais com a mesma PLR e
ii) canais com diferentes PLR. Em ambos os casos, o desempenho é
avaliado através da PSNR global (i.e., obtida pela descodificação das
duas descrições) em função da percentagem da perda total de dados
(DLR) em ambas as descrições, i.e.,
DLR(%) = (1 − Rx rate/T x rate) × 100%.
(6)
De notar que em U-MDC, valores diferentes de PLR podem produzir
a mesma DLR devido ao tamanho variável dos pacotes existente em
cada descrição, embora tenhamos o mesmo de número de pacotes
por imagem em cada uma delas.
1) Canais com o mesmo PLR: As Figs. 2(a) e 2(b) mostram os
resultados relativos ao desempenho em canais com o mesmo PLR.
A PSNR média é mostrada como função de DLR. A comparação
entre MDSQ balanceada e não balanceada mostram que a PSNR
média para U-MDSQ é melhor que MDSQ balanceado para o
mesmo débito total, i.e. entre 0.5dB e 1dB em média. Este facto é
explicado pelo facto de existir no método não balanceado uma melhor
qualidade reconstrução de apenas uma descrição, comparando com o
método balanceado para o mesmo débito. Os resultados mostram uma
melhoria efectiva do desempenhodo método proposto face ao método
clássico balanceado em aplicações com diversidade de canais, com
diferentes largura de banda disponı́veis.
2) Canais com PLR diferentes: Este cenário de transmissão
assume que cada canal tem diferentes PLR. Para que se possa
estabelecer condições equivalentes, cada descrição tanto do método
balanceado como do método não balanceado estão sujeitas à mesma
percentagem de dados perdidos. De notar que, como foi explicado anteriormente, este facto é obtido usando PLR diferentes em cada canal.
Em MDSQ não balanceado, a descrição de maior débito é transmitido
no canal com melhor condições, i.e., menor PLR. Foram utilizadas
dois objectivos de débito: i) RD1 = 480kbps; RD2 = 720kbps;
ii) RD1 = 360kbps; RD2 = 840kbps. Para o caso de MDSQ
balanceado, a comparação é realizada para o mesmo débito total de
1200 kbps, i.e., RD1 = 600kbps; RD2 = 600kbps.
As Figs. 3(a) e 3(b) mostram a PSNR média versus DLR. Na
comparação dos resultados, a percentagem total de dados perdidos em
cada descrição correspondente é a mesma, i.e., (70%, 30%) and (60%,
40%). Estes resultados mostram que o método U-MDSQ também são
melhores do que MDSQ balanceado para a maioria dos valores de
DLR. Os valores médios de ganho de U-MDSQ são da ordem de 1dB
comparando com o caso balanceado. Assim, os resultados mostram
que existe uma melhoria da qualidade dos sinais descodificados,
quando se usa o método proposto em ambientes de transmissão com
vários canais, com largura de banda e PLR diferentes.
V. C ONCLUS ÕES
Este artigo propõe um novo método MDSQ não balanceado para
transmissão em canais com largura de banda e percentagem de perda
de pacotes diferentes. Os resultados apresentados mostram que o
método proposto melhora o desempenho global em cenários de canais
sujeitos a perdas de pacotes, onde a largura de banda de cada canal
e a taxa de perdas de pacotes são assimétricos. Como conclusão, o
trabalho desenvolvido pode ser aplicado em aplicações de codificação
de vı́deo com múltiplas descrições onde a transmissão seja realizada
através de vários canais com largura de banda e restrições de perdas
de pacotes assimétricas.
AGRADECIMENTOS
Este trabalho for parcialmente suportado pela Fundação para a Ciência e
Tecnologia (FCT), com as bolsas SFRH/BD/50035/2009 e o projecto PEstOE/EEI/LA0008/2013.
R EFER ÊNCIAS
[1] V. Goyal, “Multiple description coding: Compression meets the network,”
IEEE Signal Processing Magazine, vol. 18, no. 5, pp. 74–93, September
2001.
[2] P. F. Correia, P. Assuncao, and V. Silva, “Multiple description of coded
video for path diversity streaming adaptation,” IEEE Transactions on
Multimedia, vol. 16, no. 3, pp. 923–935, 6 2012.
[3] P. F. Correia, P. Assunção, and V. Silva, “Unbalanced multiple description
video coding,” in Conf. on Telecommunications - ConfTele, vol. 1, May
2013, pp. —–.
[4] Z. He and S. Mitra, “A unified rate-distortion analysis framework for
transform coding,” IEEE Transactions on Circuits and Systems for Video
Technology, vol. 11, no. 12, pp. 1221 –1236, dec 2001.
[5] S. Milani, L. Celetto, and G. A. Mian, “An accurate low-complexity rate
control algorithm based on ρ-domain,” IEEE Transactions on Circuits and
Systems for Video Technology, vol. 18, no. 2, pp. 257–262, Feb. 2008.
[6] Z. Li, W. Gao, F. Pan, S. Ma, K. Lim, G. Feng, X. Lin, S. Rahardja,
H. Lu, and Y. Lu, “Adaptive rate control for H.264,” Journal of Visual
Communication and Image Representation, vol. 17, no. 2, pp. 376 – 406,
2006.
[7] P. Correia, P. Assuncao, and V. Silva, “Drift-free multiple description intra
video coding,” in Image Processing (ICIP), 2009 16th IEEE International
Conference on, 7-10 2009, pp. 625 –628.
[8] Z. Li, J. Chakareski, X. Niu, Y. Zhang, and W. Gu, “Modeling of distortion
caused by markov-model burst packet losses in video transmission,” in
IEEE International Workshop on Multimedia Signal Processing (MMSP),
Oct. 2009, pp. 1–6.
121
122
Web-Browser Real Time Communication in IMS Systems
Rui Sábioa, Fernando Silvaa, Carlos Rabadãoa,b, António Pereiraa,b
a
Centro de Investigação de Informática e Comunicações, Escola Superior de Tecnologia e Gestão de Leiria, 2411-901, Leiria
b
Inov Inesc Inovação Instituto de Novas Tecnologias – Delegação de Leiria
Resumo- Nos últimos anos a sociedade carece de uma
constante comunicação e de conteúdo web cada vez mais
dinâmico. Esta necessidade despoletou, por parte do IETF
e W3C, um esforço conjunto para viabilizar a
comunicação em tempo real através do browser sem a
necessidade de agentes intermédios. Nesse sentido surgiu o
Web-Browser Real Time Communication (WebRTC), uma
Application Programming Interface (API) que permite às
aplicações web o acesso aos inputs (webcam, microfone,
entre outros) e adiciona mecanismos de comunicação que
permitem o envio e receção de conteúdo através de Peer to
Peer. Esta nova abordagem, onde deixa de ser necessário
um agente intermédio para mediar a comunicação entre
clientes, deu origem a novos modelos de negócio por parte
das empresas e a uma desmistificação do paradigma
comunicacional relacionado com a Internet. Este trabalho
apresenta uma solução vocacionada para o público sénior,
a qual utiliza o WebRTC em conjunto com um IP
Multimedia Subsystem (IMS), criando dessa forma uma
plataforma de suporte a uma aplicação cliente que permite
aos utilizadores funcionalidades como: videochamada,
reconhecimento de voz para controlo da interface, assim
como, o acesso a um conjunto de aplicações lúdicas e
utilitárias de uma forma centralizada.
Keywords—Web-Browser Real Time Communication,
Ambient Assisted Living, IP Multimedia Subsystem.
I.
INTRODUÇÃO
O constante desenvolvimento das Tecnologias de
Informação e Comunicação (TIC) e a sua crescente
importância na sociedade atual fomenta o desenvolvimento de
aplicações e tecnologias, que não só nos possibilitam o contato
permanente entre indivíduos, como proporcionam o acesso a
serviços que de outra forma se encontravam fora do alcance de
uma determinada população[1].
Uma dessas tecnologias emergentes é o WebRTC, o qual
permite a comunicação direta entre browsers, eliminando a
necessidade de um agente intermédio para a realização da
comunicação[2][4].
Estes fatores permitem o aparecimento de soluções de
baixo custo, de extrema mobilidade e sem a necessidade de
recursos complexos a que normalmente soluções deste tipo
estão associadas[5].
As soluções supracitadas fornecem por um lado excelentes
ferramentas para a melhoria da qualidade de vida da
população, e por outro permitem uma comunicação facilitada
que se traduz numa menor exclusão social.
Tendo em conta esse panorama, este trabalho apresenta
uma solução vocacionada para a criação de uma plataforma
que, de uma forma centralizada, agregue serviços e os
disponibilize de forma simples, facilitando a sua utilização
pelos idosos e, paralelamente utilize as vantagens inerentes à
API WebRTC[3] e à framework IMS[6].
Ao longo deste resumo são apresentados trabalhos
relacionados com o âmbito da solução proposta, bem com a
arquitetura idealizada para o efeito e as tecnologias que foram
alvo de estudo, o WebRTC e a framework IMS.
II.
TRABALHO RELACIONADO
Existem diversos projetos focados no desenvolvimento de
tecnologias e frameworks Ambient Assisted Living (AAL)[7]
que possibilitam a implementação de serviços baseados em
AAL. Tendo isso em mente serão abordadas algumas das
soluções existentes relacionadas com esta temática, por forma
a enquadrar a solução proposta no âmbito destas tecnologias.
No seguimento do estudo das AAL, apresentamos alguns
projetos relacionados focados na interação dos utilizadores
com tecnologias de reconhecimento de movimentos para o
controlo de jogos. Exemplo disso é o “An Elderly-Oriented
Platform to Simplify the Use of Physical Activity Controlled
Game Consoles”[7], que aproveita o facto de cada vez mais as
plataformas de jogos incitarem os seus utilizadores a terem um
papel ativo no desenrolar do jogo, forma de fomentar uma
maior atividade física, e leva esse conceito até às populações
mais idosas. Propõem para o efeito uma arquitetura que torna
o idoso no comando da consola, ou seja, passa o corpo a ser a
peça que controla as ações no jogo, anulando assim a
complexidade muitas das vezes agregada ao controlo que
certas ações requerem. Ao mesmo tempo que regista a
utilização por parte do utilizador, recolhe informações
importantes sobre a atividade física praticada pelo idoso que,
posteriormente, pode ser analisada por forma a verificar se o
indivíduo está ou não a cumprir o plano de atividade diária ou
a detetar padrões de inatividade cuja causa pode estar em
problemas físicos.
Outra das soluções que partilha o mesmo âmbito
previamente referido é a “System Architecture for Palliative
Care in the Home Environment”[7], que se propõe a
monitorizar, através de uma rede sensorial montada em casa
de cada utilizador, parâmetros como os sinais vitais do
mesmo, entre outros, dados esses que são transmitidos para
um centro de controlo onde são guardados e analisados de
modo a tentar detetar padrões anómalos.
Não obstante, não existem só implementações
relacionadas, mas também algumas plataformas que
pretendem criar standards sobre os quais se podem basear
futuras soluções. Exemplo disso é a “universAAL – An Open
and Consolidated AAL Platform”[7] que consolida a
123
informação proveniente de diversos projetos, a saber:
AMIGO[8], GENESYS[9], OASIS[10], MPOWER[11],
PERSONA[12], SOPRANO[13] e ElderCare[1].
Esta consolidação deu origem a uma arquitetura comum
que define os parâmetros a serem desenvolvidos por qualquer
implementação inserida no âmbito de uma aplicação AAL.
Este standard fornece também um conjunto de regras
sobre os quais os futuros desenvolvimentos aplicacionais nesta
área devem assentar, para que sejam integráveis com soluções
existentes e que tornem possível a integração dos vários
módulos sem a necessidade de alterações específicas.
III.
A. Módulo Cliente
O módulo cliente é constituído por uma aplicação web
transversal a qualquer tipo de plataforma, desde que a mesma
seja executada num browser compatível.
CONCEITOS
Nesta secção são apresentados os principais conceitos
relativos às tecnologias que foram alvo de estudo durante a
fase de conceptualização da arquitetura idealizada para a
solução.
A. API WebRTC
A API WebRTC propõe-se a dinamizar as aplicações web,
na medida em que permite a comunicação e transferência de
dados browser-to-browser. Com esse intuito, o seu
desenvolvimento está a ser feito tendo em conta três conceitos
relevantes: PeerConnection, MediaStreams e DataChannel.
1) PeerConnection:
permite
que
dois
clientes
comuniquem directamente entre si através da aplicação web.
2) MediaStreams: mecanismo que representa e gere
streams de dados multimédia, aúdio e/ou vídeo, sejam eles
locais ou remotos.
3) DataChannel: mecanismo de comunicação bidirecional, que permite o envio de dados entre os clientes,
sejam eles dados multimédia ou não[2][3][14].
B. Framework IMS
A framework IMS, inicialmente desenvolvida para
disponibilizar serviços sobre IP aos utilizadores da rede
UMTS, permite disponibilizar um conjunto de serviços através
da rede IP. Para isso engloba uma série de funcionalidades,
tais como, controlo de utilizadores, servidores aplicacionais e
suporte para mensagens Session Initiation Protocol (SIP), as
quais permitem, de forma modular, a disponibilização de
diversos serviços baseados em arquiteturas ALL-IP.
Esta framework tem uma arquitetura modular, composta
por Call Services Controll Functions (CSCF) que interpretam
as mensagens SIP e controlam a comunicação interna entre
módulos para que as diversas funcionalidades sejam
executadas[5][6].
IV.
ARQUITETURA
Tendo em consideração a problemática supracitada sobre
as AAL e o estudo realizado aos conceitos expostos, foi
definida uma arquitetura base para a solução, constituída por
dois módulos distintos, o Módulo Cliente e o Módulo
Servidor, como pode ser constatado na Figura 1.
124
Figura 1 - Arquitetura Geral
Esta aplicação, desenvolvida em Hyper Text Markup
Language (HTML) 5 e Javascript, faz uso do WebRTC e da
API sipML5 para comunicar através de mensagens SIP com o
módulo servidor, obtendo assim acesso a todas as
funcionalidades disponibilizadas através da framework IMS.
B. Módulo Servidor
O módulo servidor encontra-se dividido em dois submódulos distintos:
1) O módulo de Gestão Open-Ims, assente numa sistema
Linux, incorpora o serviço Open-Ims, os vários servidores
aplicacionais que suportam os serviços disponibilizados pela
solução, o sistema de base de dados necessário a todo o
sistema e por último o sistema de gestão desenvolvido para a
gestão do serviço em si.
Este módulo é responsável por gerir a autenticação dos
utilizadores, pela gestão e disponibilização dos serviços
associados e pela base de dados inerente à solução. Sendo que
é com este módulo que a aplicação cliente comunica
diretamente através de websockets.
2) O módulo servidor, denominada por Servidor
Reconhecimento de Voz/Aplicação web, assente num sistema
Windows, é constituído pela aplicação que habilita o
reconhecimento de voz por parte da aplicação cliente e pelo
servidor web que disponibiliza a aplicação web aos clientes.
A aplicação de reconhecimento de voz foi desenvolvida
com recurso à linguagem de programação .Net e à API
Microsoft Speech Recognition Engine[15]. Esta aplicação
recebe os dados de áudio diretamente da aplicação cliente e
processa os mesmos por forma a dar uma resposta de controlo
à plataforma, em conformidade com o comando de voz
enviado pelo utilizador.
Em relação ao componente servidor web, este é baseado
em Apache, alberga a aplicação cliente e está configurado para
comunicar com os clientes através de HyperText Transfer
Protocol Secure (HTTPS).
V.
TESTES
Nesta seção são apresentados os testes realizados à
aplicação por uma amostra populacional representativa do
público-alvo desta solução.
Na TABELA 1 elencamos o conjunto de tarefas definidas,
a serem realizadas pelos grupo de utilizadores que se
disponibilizaram a executar os testes.
TABELA 1 - TABELA DE TAREFAS A REALIZAR
Tarefas
Iniciar o registo na plataforma
Visualizar os contatos
Utilizar o reconhecimento de voz para visualizar os contatos
Realizar uma videochamada
Os parâmetros utilizados para a realização dos testes
foram:
 Cada utilizador realizou o teste individualmente;
 O teste foi realizado num computador com interface
touch;
 Os resultados foram registados à medida que cada
teste foi executado.
Na Figura 2 é apresentado o gráfico do tempo, em
segundos, que cada utilizador levou a executar cada tarefa.
Analisando os resultados, conclui-se que a tarefa que em
média demorou mais tempo a ser executada, foi a “Realizar
Videochamada, e a que em média demorou menos tempo foi a
“Registo na Plataforma. Estes resultados prendem-se com a
complexidade das tarefas, e eram os esperados.
Figura 3 - Gráfico de Erros por Utilizador
VI.
O objetivo da solução proposta era uma plataforma de
custo reduzido, com um conjunto de serviços úteis à
população sénior e aos seus cuidadores, utilizando as mais
recentes tecnologias.
Para isso foi realizado um estudo a diversas tecnologias, o
qual deu origem à arquitetura apresentada na seção
Arquitetura, e que foi projetada com o intuito de disponibilizar
uma infraestrutura de baixo custo, tanto em termos de
manutenção como em termos de custos para os utilizadores.
Por último, os testes realizados à solução foram de
encontro com os esperados e verificam a viabilidade da
solução para o fim proposto.
REFERÊNCIAS
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
Figura 2 - Gráfico Tempos de Execução por Tarefa
[9]
A Figura 3, apresenta o gráfico representativo dos erros
cometidos por cada utilizador na realização das diversas
tarefas. Ao analisarmos os resultados obtidos, apercebemo-nos
que as tarefas que deram origem a mais erros foram a
“Visualizar Contatos” e a “Realizar Videochamada”.
No que diz respeito aos erros verificados na tarefa
“Realizar Videochamada”, pensa-se que estão relacionados
com a complexidade inerente à mesma.
Em síntese, os resultados obtidos são indicadores de que o
interface é de fácil utilização e estão de acordo com os
resultados esperados para uma aplicação deste tipo com um
público-alvo pertencente a uma faixa etária sénior.
CONCLUSÕES
[10]
[11]
[12]
[13]
[14]
[15]
I. Marcelino, J. Barroso, J. B. Cruz, and A. Pereira, “Elder Care
Architecture – a physical and social approach.”
S. Loreto, S. Pietro, and F. Ii, “Real-Time Communications in the
Web,” 2012.
Google Inc, “WebRTC,” 2012. [Online]. Available:
http://www.webrtc.org/. [Accessed: 22-Aug-2013].
IETF, “Real-Time Communication in WEB-browsers (rtcweb).”
[Online]. Available: http://datatracker.ietf.org/wg/rtcweb/.
[Accessed: 22-Aug-2013].
I. Enablement, “WebRTC IMS Systems and WebRTC Proprietary
Islands,” 2012.
“3gpp - IMS.” [Online]. Available:
http://www.3gpp.org/Technologies/KeywordsAcronyms/article/ims. [Accessed: 01-Jul-2013].
R. Wichert and B. Eberhardt, Eds., Ambient Assisted Living.
Springer, 2011, p. 318.
“AMIGO.” [Online]. Available: http://www.hitechprojects.com/euprojects/amigo/. [Accessed: 24-Jun-2013].
“GENESYS.” [Online]. Available: http://www.genesysplatform.eu/. [Accessed: 24-Jun-2013].
“OASIS.” [Online]. Available: http://www.oasis-project.eu/.
[Accessed: 24-Jun-2013].
“MPOWER.” [Online]. Available: www.mpower-project.eu.
“PERSONA.” [Online]. Available: http://www.aal-persona.org/.
“SOPRANO.” [Online]. Available: http://www.soprano-ip.org/.
E. Adam Bergkvist, V. Daniel C. Burnett, C. Cullen Jennings, and
M. Anant Narayanan, “W3C - WebRTC 1.0: Real-time
Communication Between Browsers.” [Online]. Available:
http://www.w3.org/TR/webrtc/. [Accessed: 22-Aug-2013].
“Microsoft Speech Platform SDK Documentation.” [Online].
Available: http://msdn.microsoft.com/enus/library/dd266409(v=office.14).aspx. [Accessed: 29-Jun-2013].
125
126
Técnicas de detecção e classificação de
tráfego para aplicações de Voz sobre IP (VoIP)
Hugo Fonseca, Tiago Cruz, Paulo Simões,
Edmundo Monteiro,
CISUC-DEI
Universidade de Coimbra, Portugal
{hfonseca, tjcruz, psimoes, edmundo}@dei.uc.pt
Resumo— Nos últimos anos surgiu uma nova geração de
aplicações baseadas em Voice-over-IP (VoIP), que oferecem
serviços de comunicações de voz na Internet. Fornecidas
maioritariamente como serviços over-the-top, e usando normas
como o SIP ou mecanismos proprietários (tais como Skype,
Google Talk e Yahoo! Voice), estas aplicações ganharam grande
popularidade devido ao seu baixo custo e à facilidade de uso. No
entanto, por múltiplas razões, tais como a aplicação de políticas
de uso, garantias de qualidade, segurança ou interesses
empresariais, é frequentemente necessário detectar, classificar e
monitorizar a presença de tráfego de voz em redes de dados.
Neste trabalho apresenta-se um estudo de técnicas de
detecção e classificação de tráfego gerado por protocolos VoIP,
com ênfase em duas categorias principais (com base no perfil de
padrões de tráfego de rede e com base em modelos de fluxos de
comunicação para a detecção de anomalias), discutindo algumas
das técnicas mais populares dentro de cada um destes dois
grupos. São também descritas técnicas clássicas, ainda que de
forma mais sucinta.
Palavras-chave— VoIP, Técnicas de detecção e classificação
I.
INTRODUÇÃO
O aumento do poder computacional disponível para o
utilizador final, assim como os avanços no acesso e eficiência
das tecnologias de rede, como cabo, fibra ao local (FTTx) e
redes móveis 3G e 4G, abriu caminho para a generalização de
aplicações de voz baseadas em IP (VoIP – Voice over IP),
suportadas por uma grande variedade de dispositivos, desde
computadores de secretária até smartphones.
Algumas dessas aplicações são baseadas em normas
abertas, tais como o SIP (Session Initiation Protocol [1]) e
CODECs de voz normalizados, enquanto outras usam soluções
proprietárias – por exemplo o Skype [2], o Google Talk [3] e o
Yahoo! Voice [4]. Com a gradual evolução das redes móveis e
dos smartphones, estas aplicações passaram também dos
computadores – onde eram geralmente usadas – para os
terminais móveis.
No entanto, a introdução e generalização de aplicações e
serviços baseados em VoIP tem aumentado as preocupações
para operadores de telecomunicações, provedores de serviços e
outros intervenientes, ainda que a natureza destas preocupações
nem sempre seja consensual.
Para os operadores de telecomunicações tradicionais as
principais preocupações estão relacionadas com a erosão do
mercado por aplicações e serviços VoIP que usam as suas redes
José Silva, Pedro Gomes, Nuno Centeio
COLLAB
Av. Dom João II, Lote 1.03.2.3
1998-031 Lisboa, Portugal
{jose.silva, pedro.gomes, nuno.centeio}@collab.pt
de dados, reduzindo a receita de telefonia fixa e móvel.
Juntamente com os operadores de telecomunicações, algumas
organizações também estão a implementar mecanismos para
identificar as chamadas VoIP, a fim de cobrar por estas ou
simplesmente bloqueá-las. Os prestadores de serviços VoIP,
por outro lado, estão preocupados com o fornecimento de
serviços de qualidade e confiança, garantindo níveis adequados
de segurança e Qualidade do Serviço (QoS).
Independentemente da perspetiva em que nos colocamos, a
capacidade de detectar e classificar aplicações VoIP é
fundamental, ainda que o desenvolvimento contínuo de novos
protocolos e serviços VoIP exija a pesquisa e desenvolvimento
sistemático de novas técnicas de detecção e classificação. Neste
artigo apresenta-se uma visão geral das técnicas para detectar e
classificar aplicações baseadas em VoIP, assim como estudos
de diversas metodologias que foram desenvolvidas a partir de
técnicas tradicionais existentes.
O resto deste artigo está organizado da seguinte forma. O
capítulo 2 apresenta as técnicas clássicas mais relevantes. O
capítulo 3 discute metodologias baseadas em perfis para
detecção e classificação de tráfego VoIP (com atenção especial
a técnicas baseadas em tráfego de rede e modelos de fluxo de
comunicação), e o capítulo 4 conclui o artigo.
II.
TÉCNICAS DE CLASSIFICAÇÃO CLÁSSICAS
Embora o uso de classificadores para análise e detecção de
aplicações de rede não seja um desenvolvimento recente,
constitui um campo de pesquisa activa, devido à necessidade
de evolução e também ao melhoramento contínuo dos
protocolos VoIP.
Em geral a literatura [5] [6] [7] [8] menciona dois tipos de
técnicas clássicas para a classificação de tráfego VoIP: as
baseadas em análise porta TCP/IP e as que efetuam análise de
protocolo. Neste capítulo é fornecida uma descrição destas
técnicas que, no entanto, se tornaram gradualmente ineficazes,
não oferecendo resultados precisos nos dias de hoje.
A. Análise baseada em portos
A técnica mais simples para a detecção de aplicações VoIP
consiste em analisar os portos pré-definidos que as aplicações
de voz utilizam. Esta técnica baseia-se assim na vigilância de
um conjunto de números de portos TCP/IP definidos de forma
estática e tradicionalmente usados pelas aplicações VoIP.
Até algum tempo atrás, o número dos portos TCP
(Transmission Control Protocol) e UDP (User Datagram
Protocol) usados pelas aplicações podia ser identificado com
127
alguma precisão por uma lista fornecida pela IANA (Internet
Assigned Numbers Authority [9]). Com esta informação era
possível identificar facilmente o tráfego de voz. No entanto
esta técnica de classificação não é eficaz, devido ao facto de
não existir controlo sobre os portos que são realmente usados
pelas aplicações de voz, que têm deixado de usar portas prédefinidas para passarem a usar portos dinâmicas e técnicas
automáticas para adaptação ou reação às características da rede
ondem operam – de modo a contornar firewalls, proxies e
mecanismos NAT (Network Address Translation). Outras
aplicações optaram por usar técnicas de túnel, em geral por
meio de HTTP (Hypertext Transfer Protocol) nos portos TCP
80 e TCP 443, de modo a disfarçar o seu tráfego.
B. Análise baseada em protocolo
A técnica de análise baseada em protocolo consiste na
utilização de equipamentos e aplicações de software que
monitorizam a rede, recolhendo informações a partir de pacotes
de dados e fluxos de comunicação para identificar aplicações.
Estes mecanismos fazem uso de assinaturas ou modelos de
fluxo de tráfego, também designados por impressões digitais,
de modo a identificar as referidas aplicações de voz.
Muitas aplicações de classificação comerciais ou de código
aberto são baseadas neste tipo de técnica. No entanto, esta
solução torna necessário um conhecimento prévio dos
protocolos de comunicação usados pela aplicação, tanto para a
criação de assinaturas e modelos de fluxo de tráfego como para
a recolha de informação da rede. A evolução das aplicações
leva frequentemente à necessidade de criar ou atualizar as
assinaturas e os modelos de fluxo de tráfego. Para além disso, o
uso cada vez mais comum de técnicas de criptografia contribui
para aumentar a complexidade desta abordagem. Como
resultado, a utilização desta técnica é frequentemente
desencorajada e muitas vezes impossível.
III.
METODOLOGIAS BASEADAS EM PADRÕES
Conforme foi já mencionado, as técnicas clássicas para
classificar tráfego VoIP estão a perder progressivamente
eficácia, principalmente devido ao facto de o paradigma de
desenvolvimento das aplicações VoIP ter evoluído. Algumas
das aplicações mais recentes apresentam comportamentos
distintos, que habitualmente impedem a criação de assinaturas
e de modelos de fluxos ou utilizam técnicas de ofuscação de
tráfego gerado.
A. Classificação baseada em padrões de tráfego de rede
Como alternativa às técnicas clássicas, o trabalho de
investigação mais recente nesta área propõe novas abordagens
para ultrapassar as limitações das técnicas descritas na Secção
2. Uma das abordagens mais comuns consiste na análise do
comportamento das aplicações de voz, em termos de utilização
da rede [5][6][10][11][12], fazendo uso de técnicas de análise
intensiva para identificar os parâmetros de rede que são mais
representativos da presença de aplicações VoIP – ou seja, as
características do tráfego de rede que podem indiciar em
tempo real a presença de tráfego de voz. Ao analisar essas
características do tráfego de rede torna-se possível superar as
limitações anteriores, uma vez que esses parâmetros não
correspondem a recursos estáticos como portos ou o
128
conhecimento de protocolos. Diversos parâmetros têm sido
propostos, incluindo por exemplo o intervalo de tempo entre o
primeiro e o último pacote do fluxo, o número total de
pacotes, o número de pacotes por segundo, o tamanho dos
pacotes, o número de octetos transmitidos num intervalo de
tempo e os respectivos valores médios para cada uma dessas
métricas.
Estas técnicas assumem que existe uma distinção clara
entre o tráfego gerado por aplicações VoIP e outras aplicações
[5]. Neste âmbito, aplicações como o Google Talk, o Skype e o
Yahoo! Voice foram analisadas e caracterizadas como
apresentando uma elevada taxa de envio de pacotes e um
tamanho reduzido por pacote, quando comparadas com outras
aplicações (e.g. partilha de arquivos, chat ou jogos).
Um trabalho de análise mais detalhado permite ainda
concluir que a largura de banda média (Kb/s), o tamanho
médio do pacote e o intervalo de tempo entre a chegada de
dois pacotes consecutivos são também factores que distinguem
o Skype de outras restantes aplicações VoIP [6][10].
Ao identificar as características do tráfego de rede
distintivas das aplicações VoIP e associar essas características
a assinaturas baseadas em regras de comportamento, torna-se
possível criar ferramentas que analisam o tráfego de rede e
tentam identificar as assinaturas de aplicações de voz. Por
outras, um mecanismo de classificação para aplicações VoIP
que não necessita de conhecimento prévio dos portos ou dos
protocolos para funcionar com níveis de precisão satisfatórios.
B. Classificação baseada em modelos de fluxos
A técnica descrita anteriormente destina-se à análise das
características específicas comuns à generalidade das
aplicações de voz, através da análise das características
particulares do tráfego que estas geram. No entanto, muitas
aplicações VoIP recorrem a técnicas de túnel. Estas técnicas
são usadas quando um aplicativo detecta que está numa rede
com configurações de NAT ou firewalling restritivas ou
simplesmente porque se pretenda camuflar o tráfego de voz,
misturando-o com o tráfego de outras aplicações. Este cenário
afecta a precisão das técnicas anteriores, uma vez que introduz
ruído nos parâmetros-chave de classificação.
Para lidar com estas situações, alguns autores propõem
como técnica alternativa a análise dos parâmetros dos canais
de comunicação em que a técnica de túnel é aplicada [7-8].
Este tipo de abordagem sucede, por exemplo, quando as
aplicações encapsulam o tráfego de voz como tráfego HTTP
(portas TCP 80 e TCP 443) para contornar firewalls.
Ao analisar as características do tráfego HTTP é possível
criar modelos para o tráfego normal de navegação web (isto é,
sem tráfego de voz misturado). A partir destes modelos é
possível caracterizar o tráfego HTTP, identificando as suas
características mais relevantes (por meio de métodos
estatísticos), podendo depois ser criados algoritmos para
detectar desvios (anomalias) no que diz respeito a um perfil de
um modelo de tráfego "normal" HTTP. Se houver um desvio
do modelo original, pode concluir-se que existem aplicações
que fazem uso das técnicas de túnel.
Em [7][8] são apresentados modelos para tráfego HTTP
com os seguintes parâmetros: tamanho do pedido e da resposta
web, intervalo de tempo entre chegada de pedidos
consecutivos, número de pedidos por “página” e tempo total
de chegada da “página completa”. Com estes modelos, e
recorrendo a testes de Kolmogorov-Smirnov, Goodness-of-Fit
e Qui-quadrado para detectar diferentes fluxos desconhecidos
com
características
fundamentais
diferentes
do
comportamento esperado, é possível detectar tráfego de voz.
C. Comparação entre técnicas
A Tabela I apresenta uma comparação entre os dois grupos
de técnicas considerados neste artigo, tendo por referência os
seguintes parâmetros: complexidade, robustez e performance.
TABELA I.
COMPARAÇÃO ENTRE TÉCNICAS DE CLASSIFICAÇÃO
Classificação baseada
Classificação baseada
Parâmetros
em padrões de tráfego
em modelos de fluxos
Complexidade
+++
Robustez
+++
Eficácia
++
++
Ambos os mecanismos de classificação assumem alguma
complexidade, ainda que a classificação com base no tráfego
de rede seja menos complexa de implementar e utilizar, dado
que é possível desenvolver algoritmos genéricos para detectar
aplicações de voz com base exclusivamente nas diferenças de
tráfego entre estas aplicações e outros tipos de aplicações. As
classificações baseadas em modelos de fluxo são mais
complexas, pois exigem um modelo de fluxo e um conjunto de
dados de treino para funcionar corretamente. Quanto mais
complexos forem os fluxos de comunicação mais complexos
serão os modelos representativos e mais extenso e complexo
necessitará de ser o conjunto de dados do treino.
Em termos de robustez a classificação com base no modelo
de fluxo é tipicamente superior. As aplicações de voz podem
mudar o tráfego que geram e, por conseguinte, tornar inúteis
os algoritmos baseados na análise do tráfego de rede. Por
outro lado, a classificação baseada em modelos de fluxos não
depende da aplicação de voz em si, mas sim do tráfego
observado no comunicação. Este não tende a mudar com
muita frequência, por isso o modelo permanece inalterado por
mais tempo. Em termos da eficácia, a Tabela I mostra que
ambas as técnicas de classificação são semelhantes, com a
força de uma das técnicas a ser a fraqueza de outra e viceversa.
IV.
CONCLUSÃO E TRABALHO FUTURO
A detecção e classificação de aplicações de voz com base
na análise do tráfego de rede é uma questão importante para
várias entidades (tais como operadores de telecomunicações e
prestadores de serviços de voz), devido a diversos motivos:
segurança, gestão de qualidade do serviço, gestão da rede, e
aplicação de políticas de negócio preestabelecidas.
Neste âmbito, este artigo apresenta uma visão geral de
técnicas clássicas e das técnicas mais recentes para detecção e
classificação de aplicações de voz. As técnicas clássicas
incluem mecanismos baseados na detecção por porta ou
protocolo, que se tornaram gradualmente menos eficazes com
o surgimento de novas aplicações e protocolos VoIP e com a
evolução das técnicas de evasão e ofuscação.
Relativamente às técnicas mais recentes, foram
identificados dois grandes grupos: os que se baseiam na
caracterização dos padrões do tráfego de rede e aqueles que
usam modelação de fluxos para detecção de anomalias.
A primeira categoria permite distinguir os parâmetros de
tráfego de rede gerados por aplicações de voz sem um
conhecimento prévio das dos portos ou dos protocolos usados.
Existem muitos algoritmos que se enquadram nesta categoria,
sendo genericamente capazes de detectar vários tipos de
aplicações de voz sem grande distinção entre eles. Há também
variações específicas de algoritmos dentro desta categoria,
projetadas para identificar tipos específicos de aplicações de
voz. A segunda categoria de algoritmos de detecção e
classificação trabalha com os modelos de fluxos dos canais de
comunicação, a fim de estabelecer os modelos de referência
que servem como base para a utilização de técnicas de
detecção de anomalias. Estas técnicas são particularmente
adequadas para aplicações de voz que recorrem a túneis,
misturando por exemplo o seu tráfego com tráfego HTTP.
A categorização proposta permite estabelecer uma distinção
clara entre estas diferentes abordagens para o mesmo
problema,
independentemente
dos
algoritmos
de
aprendizagem, modelação ou detecção de anomalias usados
em concreto. Espera-se no futuro desenvolver mais esta
categorização, de modo a identificar e caracterizar
subcategorias mais detalhadas.
AGRADECIMENTOS
Este trabalho foi parcialmente financiado pela Collab S.A.
e pelo programa QREN (no âmbito do projeto I&DT Nubitalk,
referência QREN 22983) e pela Comissão Europeia, no
âmbito do projeto CockpitCI (FP7-SEC-2011-1, N. 285647).
Os nossos agradecimentos aos restantes participantes nestes
dois projetos, pelas várias contribuições recebidas.
REFERÊNCIAS
[1]
[2]
[3]
[4]
[5]
RFC 3261, “SIP: Session Initiation Protocol”
Microsoft Inc., Skype, http://www.skype.com/
Google Inc, Google Talk, http://www.google.com/hangouts/
Yahoo! Inc, Yahoo Message, http://messenger.yahoo.com/
F. Idress e U. Khan, “A Generic Technique for Voice over Internet
Protocol (VoIP) Traffic Detection,” no International Journal of Computer
Science and Network Security, VOL.8 No.2, 2008
[6] M. Perényi e S. Molnár, “Enhanced Skype Traffic Identification,” em
Budapest University of Technology & Economics, Hungary, 2007
[7] E. Freire, A. Ziviani e R. Salles, “Detecting VoIP Calls Hidden in Web
Traffic,” em IEEE TNSM, vol. 5, no. 4, 2008.
[8] E. Freire, A. Ronaldo e M. Salles, “On Metrics to Distinguish Skype Flows
from HTTP Traffic,” em J Netw Syst Manage 17:53-72, 2009.
[9] IANA “Port numbers”, http://www.iana.org/assignments/port-numbers
[10] M. Perényi, A. Gefferth, T. D. Dang e S. Molnár, “Skype Traffic
Identification,” GLOBECOM 2007.
[11] S. Molnár e M. Perényi, “On the identification and analysis of Skype
traffic,” em Int. J. Commun. Syst., vol. 24, no. 1, 2011.
[12] P. Biondi e F. Desclaux, “Skype uncovered - Security study of Skype,”
EADS, 2005.
129
130
Validação remota de aplicações de informática
forense com recurso a dongles por USB/IP
Albano Afonso
Portugal
Mário Antunes
Filipe Mota Pinto
Center for Research in Advaced
Computing Systems (CRACS),
DCC/FC, Universidade do Porto
Portugal
Centro Algoritmi, Universidade do
Minho
Portugal
Resumo — O uso de dongles USB para alojamento de licenças
de utilização é uma técnica muito usada por várias aplicações de
software. Na área da informática forense há duas aplicações
comerciais de renome internacional muito utilizadas: o Encase
Forensic© da Guidance Software e o Forensic ToolKit (FTK)© da
AccessData Group. A validação das licenças destas aplicações por
meio de dongles levanta vários problemas às equipas de
investigação em informática forense, designadamente o perigo de
furto e perda, com o consequente acesso não autorizado às
respetivas aplicações, bem como a inviabilização da otimização
dos recursos, tanto humanos como tecnológicos, já que cada
examinador terá de ter um dongle, que deverá ser transportado e
utilizado por si. Neste artigo apresenta-se uma arquitetura
distribuída para a gestão de dongles, recorrendo ao uso do
protocolo USB/IP. A abordagem utilizada permite o acesso
remoto e distribuído aos dongles USB com as licenças das
aplicações de informática forense, recorrendo a uma rede
TCP/IP. A solução apresentada foi desenvolvida em colaboração
com a Secção de Investigação da Criminalidade informática e
Tecnológica (SICIT) da Polícia Judiciária Portuguesa (PJ), tendo
sido realizados testes de aceitção.
Keywords— USB, dongle, USB/IP, Acesso Remoto a Licenças
I.
INTRODUÇÃO
A informática forense é um ramo da ciência forense e uma
área da investigação criminal relacionada com as provas
digitais encontradas em suportes de armazenamento digital
[1]. De forma a auxiliar os examinadores de informática
forense e os peritos a otimizar a recolha da prova digital, há
duas aplicações comerciais, lideres de mercado a nível
internacional de informática forense [2], que são muito
utilizadas por estes profissionais: Forensic Toolkit (FTK)© [3]
e o Encase© [4]. Para validar a licença do utilizador e concederlhe o respectivo acesso, estas aplicações recorrem ao uso de um
dongle [5]. Um dongle é um dispositivo de hardware com uma
interface USB, utilizado na deteção da licença de utilização de
um software. O maior desafio dos examinadores que utilizam
estas aplicações consiste na necessidade de terem que ligar
fisicamente o dongle no computador onde está instalada a
aplicação, tendo para isso de o transportar fisicamente de
computador para computador. Desta forma, o risco de perda ou
furto do dongle aumenta, bem como a possibilidade do seu uso
não autorizado.
Neste artigo apresenta-se uma solução distribuída, assente
numa rede TCP/IP, que pretende mitigar o problema
apresentado e com o qual os examinadores de informática
forense se deparam constantemente. O objectivo principal
consiste em agilizar o acesso remoto aos dongles onde estão as
licenças das aplicações de informática forense, através da rede
local TCP/IP.
O trabalho apresentado consiste na replicação das portas
USB existentes nas máquinas, a partir de um servidor TCP/IP
pertencentes à rede local privada e isolada do exterior [6].
Desta forma, os clientes acedem remotamente aos dongles
USB ligados fisicamente no servidor, como se os mesmos
estivessem ligados localmente à interface USB. Os dongles são
partilhados e acedidos remotamente pela rede local, através dos
pedidos efetuados pelos clientes, através do protocolo USB/IP.
O desenvolvimento efetuado no servidor USB/IP foi realizado
recorrendo a componentes de software opensource [7]. Foi
igualmente desenvolvida uma interface gráfica para o cliente
USB/IP.
II.
CONCEITOS FUNDAMENTAIS
A limitação física de acesso às portas USB pode ser
ultrapassada através do uso de uma solução de USB sobre
TCP/IP, através do protocolo USB/IP. A aplicação servidor,
em execução na máquina que disponibiliza o acesso físico às
portas físicas USB, é acedida remotamente por uma aplicação
cliente, através de uma máquina onde não existe o recurso
físico a essas portas USB.
A possibilidade de aceder remotamente a uma porta USB
através da rede TCP/IP foi inicialmente proposta por Hirofuchi,
et al. [7]. Em 2007, Kwon et al. [8], implementaram uma nova
versão do USB/IP em que estenderam a possibilidade do
cliente ser compatível com o sistema operativo Microsoft
Windows. Posteriormente, em 2009 procedeu-se ao
desenvolvimento de um cliente baseado na linha de comandos
para o Windows. Em 2011, com o suporte da ReactOS [9], foi
publicada uma versão melhorada desse cliente Microsoft
Windows, em que os drivers USB/IP necessários para a
aplicação são assinados digitalmente e tornam-se compatíveis
com sistemas operativos Windows de 32 bits e 64 bits [9].
Atualmente, a versão do USB/IP que está disponível para
ser instalada por um instalador de software do Linux (p.e.
apt-get), encontra-se obsoleta e é incompatível com as
versões do kernel superior à 2.6.
O protocolo aplicacional USB/IP utiliza uma arquitetura do
tipo cliente/servidor. Desta forma, o servidor exporta os
dispositivos USB, colocando-os a disposição dos clientes que
131
procedem a importação dos mesmos. Além disso, o driver do
dispositivo USB exportado é executado na máquina cliente.
III.
ARQUITETURA
Nesta seção, é apresentada a arquitetura do sistema
desenvolvido para validação remota de licenças guardadas em
dongles, assente numa solução distribuída com acesso remoto
por USB/IP. O caso de estudo usado neste trabalho utilizou o
acesso remoto às aplicações de informática forense em uso na
Secção SICIT da PJ.
A Figura 1 ilustra a situação atual (a) e a solução proposta
(b). Actualmente as aplicações encontram-se instaladas em
cada um dos computadores dos examinadores, sendo o seu
acesso validado através de um dongle que se encontra ligado
fisicamente em cada máquina.
dispositivo USB, este automaticamente era removido no
servidor. Ou seja, o servidor removia automaticamente esse
dispositivo da lista dos dispositivos exportados, sendo por isso
obrigatório proceder-se novamente à partilha do mesmo no
servidor USB/IP.
Esta situação verificava-se tanto no cliente Linux como no
cliente Microsoft Windows, tornando assim a utilização desta
versão pouco viável. No entanto, a versão compatível com o
kernel 3.0 tenta mitigar estes problemas, conforme descrito em
[9]. Nesta versão foi também incrementada a funcionalidade
que permite no servidor parar a partilha de um determinado
dispositivo. Constatámos no entanto que não existe
compatibilidade com versões do kernel anteriores à 3.0,
atendendo a que são utilizados módulos diferentes do kernel.
Além disso, esta versão não se encontra disponível no
repositório de software do Linux.
Desta forma, a única alternativa consistiu em obter o código
fonte do USB/IP presente no kernel 3.2.28, disponível em
\linux3.2.28\drivers\staging\usbip\userspace, e
proceder à compilação e instalação manual a partir do código
fonte, respeitando todas as dependências necessárias.
(b)
(a)
Figura 1. Cenário Atual (a) e a solução desenvolvida (b)
O cenário desenvolvido, ilustrado em (b), consiste na
implementação de uma solução distribuída em que o servidor
USB/IP é uma máquina Linux que aloja fisicamente no seu
barramento USB, todos os dongles USB disponíveis e
necessários a cada aplicação de informática forense.
A aplicação USB/IP do servidor encontra-se instalada e está
à escuta de pedidos TCP no porto 3240. As máquinas onde
estão a ser executadas as aplicações de informática forense são
os clientes USB/IP e usam o sistema operativo Microsoft
Windows com os drivers USB/IP devidamente instalados.
Nestas máquinas encontra-se também instalada a aplicação
cliente USB/IP que vai interagir com o servidor USB/IP e será
responsável pelos pedidos de acesso aos dispositivos USB
ligados fisicamente no servidor e partilhados através da rede
TCP/IP.
Cada máquina cliente virtualiza um acesso remoto através
da rede local TCP/IP ao dispositivo USB, como se de uma
porta USB de acesso local se tratasse. Com o objetivo de
validar a licença de utilização antes de iniciar uma das
aplicações de informática forense, o examinador recorre à
aplicação cliente USB/IP e obtém o acesso ao dongle remoto
que se encontra ligado fisicamente no servidor. Neste novo
cenário de utilização dos dongles, o número de licenças é
exatamente igual ao utilizado no cenário actual, respeitando
assim as condições de licenciamento.
IV.
DESENVOLVIMENTO
O desenvolvimento efectuado baseou-se no projeto open
source USB/IP [7], que inicialmente foi concebido para um
ambiente homogéneo Linux, para a versão 2.6 do kernel.
Durante o desenvolvimento constatou-se que nesta versão do
USB/IP, sempre que um cliente terminasse a ligação virtual ao
132
Após a compilação desta nova versão verificou-se que a
aplicação servidor de USB/IP ficou devidamente instalada e
que o problema anteriormente existente ficou resolvido. No
entanto, estas alterações ao código do servidor tornou-se
incompatível com o cliente para Microsoft Windows baseado
na linha de comandos.
Assim, foi necessário obter o código fonte do cliente
Windows e compilá-lo. Também com o recurso ao Windows
Driver Kit 7 e a partir dos ficheiros do código fonte, foram
gerados os ficheiros binários .sys para 32 e 64 bits,
compatíveis com o Windows 7, Windows Server 2008 e
Windows 8. A partir deste momento constatou-se a
compatibilidade entre o servidor na sua versão mais recente e o
novo cliente para o Windows baseado na linha de comandos. A
Figura ilustra aplicação gráfica desenvolvida para o cliente
USB/IP.
Figura 2. Aplicação gráfica de interação com o utilizador
V.
TESTES REALIZADOS
Esta secção resume os principais testes realizados com
dongles USB. Foram realizados testes recorrendo aos dongle
USB, ligados fisicamente no servidor através de um hub USB.
Para cada dongle foi realizado um teste entre o servidor e o
cliente em que este último acedeu remotamente ao dongle
USB como se de um dongle USB local se tratasse,
possibilitando assim a validação remota da licença de
utilização das aplicações de informática forense, Encase© e
FTK© utilizadas pelos examinadores. Os dongles utilizados
nos testes são um CodeMeter que suporta a licença da
aplicação de informática forense FTK© e dois Aladdin HASP
HL que suportam a licença da aplicação de informática
forense Encase©.
Neste teste a máquina servidor USB/IP tem o sistema
operativo Ubuntu 12 LTS e o cliente tem o sistema operativo
Microsoft Windows 7 (64bits). Na máquina cliente USB/IP
estão instaladas as aplicações Encase© e CodeMeter Control
Center©, sendo esta última responsável pela gestão das licenças
utilizadas na aplicação FTK©. Também neste teste as máquinas
encontram-se ligadas a um switch na mesma rede local,
conforme ilustrado na Figura 2.
Foram realizados vários testes com a aplicação
desenvolvida, no laboratório da PJ em Lisboa, quer com discos
externos USB, quer com dongles USB usados para o acesso
remoto ao licenciamento das aplicações de informática forense,
EnCase© e FTK©, que constituiam o objectivo principal deste
trabalho. Embora os testes tenham sido realizados com duas
aplicações muito específicas, cuja licença se encontra alojada
em dongles, o mesmo procedimento poderá ser igualmente
bem sucedido com outras aplicações que utilizem o mesmo
processo de validação de licenças. Por exemplo, a aplicação de
desenho assistido por computador AutoCAD©, as aplicações de
gestão e contabilidade PHC© e algumas aplicações utilizadas
na saúde, na área da radiologia.
BIBLIOGRAFIA
[1] Eoghan Casey, Handbook of Digital Forensics and
Investigation.: Academic Press, 2010.
Figura 2. Cenário de teste com os dongles USB
Neste teste, o cliente através da aplicação gráfica USB/IP,
estabeleceu com sucesso uma ligação TCP ao servidor USB/IP,
e obteve a lista dos dongles exportados pelo servidor através da
rede local.
Após a ligação virtual estabelecida entre o cliente e os
dongles remotos CodeMeter e Aladdin HASP HL, as
aplicações de informática forense do FTK© (Figura 11-a) e do
Encase© (Figura 11-b) realizaram a validação remota da licença
de utilização.
[2] 2013 SC Awards US Finalists: Round Three; "SC
Magazine", "http://www.scmagazine.com//2013-scawards-us-finalists-round-three/article/270295/";
Consultado em Setembro 2013.
[3] "AccessData Group Software FTK", ",
http://www.accessdata.com/products/digital forensics/ftk",
[4] "Guidance Software Encase",,
"http://www.guidancesoftware.com/encase-forensic",
[6] Piazzalunga, U., Salvaneschi, P., Balducci, F., Jacomuzzi,
P., & Moroncelli, C. (2007). "Security strength
measurement for dongle-protected software"; Security &
Privacy, IEEE, 5(6), pp. 32-40.
(a)
(b)
Figura 3. (a) A aplicação CodeMeter detetou o dongle remoto e (b)
Informações sobre a licença encontrada no dongle remoto
O processo decorreu de forma transparente para o utilizador
final, não tendo havido necessidade do examinador ligar
fisicamente um dongle USB na máquina onde a aplicação
forense está instalada.
VI.
CONCLUSÕES
Neste artigo foi abordada a validação remota das aplicações
de informática forense e o desenvolvimento realizado na
adaptação do protocolo USB/IP existente em open source. Do
lado do servidor conseguiu-se colocar em funcionamento uma
versão estável da aplicação, compatível com o kernel 3.2 do
Linux. Por outro lado, no que diz respeito ao cliente USB/IP,
foi possível realizar os desenvolvimentos necessários para o
colocar em funcionamento no sistema operativo Windows 7, na
versão de 64 bits, mantendo-se disponível um cliente Linux
nativo no kernel 3.2, através de comandos executados na shell.
[5] "Wibu-Systems", "http://www.wibu.com/hardware-copyprotection.html", Consultado em Setembro 2013.
[6] Albano Afonso; "USBport Through TCP/IP - Replicação
de portas USB," Relatório de Projeto de Mestrado,
Novembro de 2012.
[7] Takahiro Hirofuchi, Eiji Kawai, Kazutoshi Fujikawa, and
Hideki Sunahara, "USB/IP a Peripheral Bus Extension for
Device Sharing over IP Network," in FREENIX Track:
USENIX Annual Technical Conference, 2005, pp.47-60.
[8] Han Wook Cho, and Yong Ho Song Wonhong Kwon,
"Design and Implementation of Peripheral Sharing
Mechanism on Pervasive Computing with Heterogeneous
Environment," 5th IFIP WG 10.2 International Workshop
Seoul 2007, pp. 537-546.
[9] "USB/IP Project", " http://usbip.sourceforge.net/",
133
134

Atas - 13ª Conferência sobre Redes de Computadores

Transcrição

Documentos relacionados

o problema mente-corpo através das abordagens psico

autorização para retirada de kit por terceiro

Paulo Leal Ferreira - Instituto de Física Teórica

Hub FireWire de 3 portas O FH300 IEEE 1394 oferece 3 portas

Hub FireWire de 6 portas O FH600 IEEE 1394 oferece 6

Quarta-feira de cinzas

Iniciando a Sua Pesquisa

Resolução PUCRS 2008 Inverno Inglês

A Terceira via - Carlos Noronha Feio

1 Psicologia do Espaço Mental Sinopse A Psicologia do Espaço