A Internet do futuro. 13ª Conferência sobre Redes de Computadores, CRC2013 Leiria, Portugal, de Novembro de Atas da conferência.

Transcrição

1

2 A Internet do futuro 13ª Conferência sobre Redes de Computadores, CRC2013 Leiria, Portugal, 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

3 Créditos TÍTULO A Internet do futuro SUBTÍTULO 13ª Conferência sobre Redes de Computadores, CRC2013 Leiria, Portugal, 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 /13 ISBN WEB

4 Organização Presidentes Gerais António Pereira Patrício Domingues ESTG - Instituto Politécnico de Leiria ESTG - Instituto Politécnico de Leiria Presidentes da Comissão de Programa Carlos Rabadão ESTG - Instituto Politécnico de Leiria Vítor Fernandes ESTG - Instituto Politécnico de Leiria Comissão Coordenadora Alexandre Santos Edmundo Monteiro Rui Aguiar Teresa Vazão 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 Minho Universidade de Coimbra Universidade de Aveiro Instituto Superior Técnico ESTG - Instituto Politécnico de Leiria ESTG - Instituto Politécnico de Leiria ESTG - Instituto Politécnico de Leiria ESTG - Instituto Politécnico de Leiria ESTG - Instituto Politécnico de Leiria Universidade do Minho Universidade do Minho Universidade do Algarve Universidade de Aveiro Universidade do Minho Universidade de Aveiro ESTG - Instituto Politécnico de Leiria Universidade de Aveiro Instituto Superior Técnico Universidade do Minho Universidade Federal do Rio Grande do Sul (Brasil) ESTG - Instituto Politécnico de Leiria Instituto Superior Técnico Instituto Superior Técnico ISCTE - Instituto Universitário de Lisboa Universidade de Trás os Montes e Alto Douro Universidade de Aveiro Universidade de Coimbra Universidade Federal do Pará (Brasil) Universidade de Coimbra Universidade de Lisboa Universidade da Beira Interior

5 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 do Algarve Universidade do Algarve ESTG - Instituto Politécnico de Leiria Universidade de Aveiro Universidade do Minho Universidade da Beira Interior Universidade de Coimbra Universidade de Aveiro Universidade Nova de Lisboa Universidade de Aveiro Faculdade de Engenharia da Universidade do Porto Universidade do Porto Universidade Nova de Lisboa Instituto Politécnico do Porto Instituto Superior Técnico Faculdade de Engenharia da Universidade do Porto Universidade do Minho Universidade de Coimbra ESTG - Instituto Politécnico de Leiria Universidade da Beira Interior ESTG - Instituto Politécnico de Leiria ESTG - Instituto Politécnico de Leiria Instituto Politécnico de Lisboa Universidade do Algarve Instituto Politécnico de Castelo Branco ESTG - Instituto Politécnico de Leiria Universidade do Minho ESTG - Instituto Politécnico de Leiria Universidade Lusófona Universidade de Aveiro Instituto Superior Técnico Universidade Nova de Lisboa Universidade do Porto Universidade de Aveiro Universidade de Coimbra ESTG - Instituto Politécnico de Leiria Universidade de Aveiro Universidade do Minho Universidade de Aveiro Instituto Politécnico de Bragança Universidade de Évora Universidade de Vigo (Espanha) Universidade do Minho Universidade de Aveiro

6 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

7

8 Í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 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 Rafael Gouveia, João Aparício, João Soares, Bruno Parreira, Susana Sargento, Jorge Carapinha Framework e Cliente WebRTC Vasco Amaral, Solange Lima, Telma Mota, Paulo Chainho Testing Performance of MLP Neural Networks for Intrusion Detection with MATLAB José Quevedo, Rui Aguiar Configuração dinâmica em redes sem fios Daniel Fuentes, António Pereira Sessão 3: Redes sensoriais e veiculares Encaminhamento com QoS para Redes Ad Hoc com rotas estáveis Tiago Coelho, António Costa, Maria João Nicolau, Joaquim Macedo Performance Evaluation of IEEE Underwater Wireless Networks Filipe Teixeira, José Quevedo, Rui Campos, Manuel Ricardo SILOS - A Simple Location Service for Vehicular Ad-hoc Networks 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 Pedro Queiros, M. João Nicolau, Alexandre Santos Using Web10G for Service and Network Diversity Exploitation and Failure Recovery Filipe Ribeiro de Carvalho, José Legatheaux Martins Towards Widespread use of SCTP for the Future Internet Bruno Sousa, Ricardo Santos, Marilia Curado A comparative analysis of IEEE MAC layer mechanisms to handle real-time traffic in open communication environments Robson Costa, Paulo Portugal, Francisco Vasques, Ricardo Moraes

9 Sessão 5: Encaminhamento em redes Bayesian based selfish aware routing on Delay Tolerant Networks 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 João Antunes, António Costa, Joaquim Macedo Encaminhamento Multi-Caminho Baseado num Número Reduzido de Árvores João Horta, Margarida Mamede, José Legatheaux Martins Encaminhamento IP Optimizado Através de uma Aproximação de Software Defined Networking Alexandre Pinote, José Legatheaux Martins Sessão de posters Automatização de Testes SIP 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 Pedro Correia, Pedro Assunção, Vítor Silva Web-browser Real Time Communication in IMS Systems 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) 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 Albano Afonso, Mário Antunes, Filipe Pinto

10 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, Lisboa, Portugal. s: {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 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 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]. 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 A Internet do futuro 1

11 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 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. The NB systems operate in the Low Frequency (LF) band, which corresponds to 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 ( khz), CENELEC-C ( khz) and CENELEC-D ( 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 ) and LonTalk (ISO/IEC ), employ NB- PLC with a single carrier. The IEC standard for lowspeed reliable power line communications by electricity meters, water meters and SCADA, uses the khz frequency band, being able to achieve 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 G3 2 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 khz range, and is able to achieve kbit/s. G3 may operate in the CENELEC-A and CENELEC-B bands, being able to achieve kbit/s. The G3-PLC MAC layer is based on the IEEE 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 P [9]. BB-PLC systems operate in the High Frequency (HF) and Very High Frequency (VHF) bands, which corresponds to 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: IEEE P1901 is based on the HomePlug AV system developed by the HomePlug Powerline Alliance. 2 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

12 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 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 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 2 nd 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 kbit/s in the downlink and 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 3 rd 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 High- Speed 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 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 Mbit/s for downlink and 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 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]. A Internet do futuro 3

13 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 j [16]. Even if the IEEE s mesh extension is not used, IEEE 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 ) or thousands (IEEE ) 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 s 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 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 j, 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 RF- Mesh. 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 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 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 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 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 standard restricted operation to the unlicensed frequency bands of MHz (Europe), MHz (USA) and 2.4 GHz, the IEEE g 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 g 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 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 4 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

14 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 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 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 LoWPAN 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 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]. The advantages of narrowband RF Mesh solutions are mostly related with deployment flexibility, increased range 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 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 RF- Mesh 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 g) radio, such as the XbeePro operating on the 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. A Internet do futuro 5

15 TABLE I COMPARISON OF COMMUNICATION TECHNOLOGIES FOR THE LVDN IN A SMART GRID Type Subtype CAPEX OPEX Maximum Bit rate Range 4 UNB Low Negligible 100 bit/s 150 km 128 kbit/s PLC Several NB Low Negligible (CENELECkm A) Infrastructurebased Wireless Networks 5 RF Mesh 2.5G (GPRS) 3G (HSDPA, HSUPA) 4G (WiMAX, LTE) Broadband (IEEE n/s) Narrowband (Silver Spring Networks) Narrowband (IEEE g) Low Low Low High High High kbit/s downlink kbit/s uplink 42 Mbit/s downlink 5.76 Mbit/s uplink Mbit/s downlink 75.4 Mbit/s uplink High Negligible 600 Mbit/s High High (if license is required from ANACOM) 100 kbit/s Medium Negligible 1094 kbit/s ACKNOWLEDGEMENT Coverage dependent Coverage dependent Coverage dependent Hundreds of meters Several km Several km (e.g., XbeePro 24 kbit/s) 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. REFERENCES [1] N. Saputro, K. Akkaya, S. Uludag, A Survey of Routing Protocols for Smart Grid Communications, Computer Networks, Elsevier, 56 (2012), pp , [2] 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): , IEEE, 4 th Quarter [3] 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, 1 st Quarter [4] I. H. Cavdar, A solution to remote detection of illegal electricity usage via power line communications, IEEE Transactions on Power Delivery, October [5] M. Nassar, Y. Mortazavi, I. Kim, Local Utility Powerline Communications in the khz Band: Channel Impairments, Noise, and Standards, IEEE Signal Processing Magazine, IEEE, July 2012 (to appear.) [6] H. Ferreira, L. Lampe, J. Newbury, and T. Swart. Power line communications: Theory and applications for narrowband and 4 Maximum ranges are usually achieved with the lowest bitrates only. 5 It is assumed that the Infrastructure-based Wireless Network Service is hired from an operator. broadband communications over power lines. John Wiley and Sons, [7] ITU-T G.9955, Narrowband orthogonal frequency division multiplexing power line communication transceivers Physical layer specification, ITU-T, December [8] ITU-T G.9956, Narrowband orthogonal frequency division multiplexing power line communication transceivers Data link layer specification, ITU-T, November [9] 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 [10] ITU-T G.9963, Unified high-speed wireline-based home networking transceivers Multiple input/multiple output specification, ITU-T, December [11] IEEE , IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Broadband Wireless Access Systems, IEEE, May [12] B. Lichtensteiger et al, RF Mesh Systems for Smart Metering: System Architecture and Performance, IEEE SmartGridComm [13] 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 [14] 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, [15] IEEE , 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 [16] IEEE j, IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Broadband Wireless Access Systems Amendment 1: Multihop Relay Specification, IEEE, June [17] C. Perkins et al., Ad hoc On-Demand Distance Vector (AODV) Routing, RFC 3561, IETF, July [18] T. Clausen, P. Jacquet, Optimized Link State Routing Protocol (OLSR), RFC 3626, IETF, October [19] T. Winter et al., RPL: Ipv6 Routing Protocol for Low-Power and Lossy Networks, RFC 6550, IETF, March [20] National Institute of Standards and Technology. NIST Framework and roadmap for smart grid interoperability standards, release 1.0, bility_final.pdf, January [21] H. Farhangi, The path of the smart grid, IEEE Power & Energy Magazine, 8(1):18 28, [22] 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): , [23] IEC , Energy management system application program interface (EMS-API) Part 301: Common Information Model (CIM) Base, IEC, Edition 1.0, November [24] IEC 62591, Industrial communication networks Wireless communication network and communication profiles WirelessHART, IEC, Edition 1.0, April [25] P. Kulkarni, S. Gormus, Z. Fan, B. Motz, A Mesh-Radio-Based Solution for Smart Metering Networks, IEEE Communications Magazine, IEEE, July [26] Silver Spring Networks, Smart Grid Standards, whitepaper, 09/04/2012. [27] EUTC, Spectrum needs for Utilities, EUTC position paper, osition%20paper-9april2013.pdf, last access 5/09/2013. [28] XBeePro 868, last access 6/09/ Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

16 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 Institute for Computer Science and Applied Mathematics, University of Bern, Bern, Switzerland Abstract This paper evaluates the performance of the most popular power saving mechanisms defined in the IEEE 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 , Energy Efficiency, Power Save Mode, U-APSD I. INTRODUCTION 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 [1] family is the most used WLAN technology. The actual IEEE public and private infrastructure is well disseminated, leading mobile phone vendors to include this technology in almost all devices. The IEEE 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 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 standard, where the energy constraints were not fully taken into account. The usage of IEEE in battery powered devices raises new challenges regarding energy consumption. Aiming at solving these issues, the IEEE 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 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 e [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 MAC layer, the Enhanced Distributed Channel Access (EDCA). This work aims to study IEEE 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 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 POWER SAVING MECHANISMS This section describes the IEEE Legacy Power Save Mode (Legacy-PSM) and Unscheduled Automatic Power Save Delivery (U-APSD) power saving schemes. A Internet do futuro 7

17 A. IEEE Legacy-PSM This subsection describes the IEEE Legacy Power Save Mode (Legacy-PSM) algorithm. When communicating using the IEEE 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 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 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 CATEGORIES 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. RELATED WORK 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. 8 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

18 The next section presents the results obtained from the performance evaluation of Legacy-PSM and U-APSD algorithms. IV. PERFORMANCE EVALUATION 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. A. Simulation Scenario and Parameters 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 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 [13]. The U-APSD was implemented also within the INET framework The simulation scenario used is illustrated in Figure 1. Server TABLE II OMNET++ SIMULATION PARAMETERS Parameter Value OMNeT++ version 4.3 INET version Simulation time Repetitions 15 IEEE standard Default regular wake up interval Power while transmitting Power while receiving Power while idle Power while sleep 300 seconds g and e 100 ms 2000 mw 1500 mw 300 mw 20 mw 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 U- APSD, 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., No- PSM 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 Core Network Station IEEE Fig. 1. OMNeT++ simulation scenario Table II describes the simulation parameters used, such as power values used [14], IEEE 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 Delay (milliseconds) 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 A Internet do futuro 9

19 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 U- APSD, 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 Algorithm: No PSM Legacy PSM U APSD 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) Algorithm: No PSM Legacy PSM U APSD Total Energy Consumption (Joule) 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 Legacy- PSM 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 Packet Size (B) Fig. 4. Total energy consumption for distinct packet sizes With the Legacy-PSM it is possible to see that energy consumption in No-PSM scenario is higher than both Legacy- PSM and U-APSD, showing the need to employ the power saving mechanisms of the IEEE technology. Regarding the Legacy-PSM and U-APSD power saving mechanisms, U- APSD 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 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]. 10 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

20 Algorithm: No PSM Legacy PSM U APSD Energy Consumption per Byte (Joule) Delay (miliseconds) Packet Size (B) 0 PSM with Wake Up interval = 20ms PSM with Wake Up interval = 100ms Algorithm U APSD with Wake Up interval = 20ms Fig. 5. Energy Consumption per byte for distinct packet sizes Fig. 6. QoS requirements guarantees on PSM and U-APSD end-to-end delay 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- 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. Total Energy Consumption (Joule) PSM with Wake Up interval = 20ms PSM with Wake Up interval = 100ms Algorithm U APSD with Wake Up interval = 20ms Fig. 7. Impact of running a VoIP application in PSM and U-APSD Energy Consumption A Internet do futuro 11

21 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. CONCLUSIONS The constant growth of traffic generated by mobile devices in the last years, together with the increasing number devices using IEEE 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 standard (Legacy- PSM 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 ), 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 , 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 , [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 e-2005 (Amendment to IEEE Std , 1999 Edition (Reaff 2003), pp , [6] X. P. Costa, D. Camps-Mur, and A. Vidal, On distributed power saving mechanisms of wireless lans e u-apsd vs power save mode., Computer Networks, vol. 51, no. 9, pp , [7] X. Perez-Costa and D. Camps-Mur, Ieee e qos and power saving features overview and analysis of combined performance [accepted from open call], Wireless Communications, IEEE, vol. 17, no. 4, pp , [8] Y. He, R. Yuan, X. Ma, J. Li, and C. Wang, Scheduled psm for minimizing energy in wireless lans, in Network Protocols, ICNP IEEE International Conference on, pp , [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 , ACM, [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 , ACM, [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, Social- Informatics and Telecommunications Engineering), [12] INET framework main page. [13] V. Bernardo, M. Curado, and T. Braun, Enhancing ieee 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 [14] D. Camps-Mur, M. D. Gomony, X. P. Costa, and S. S. Ribes, Leveraging n frame aggregation to enhance qos and power consumption in wi-fi networks, Computer Networks, vol. 56, no. 12, pp , [15] D. Skordoulis, Q. Ni, H.-H. Chen, A. Stephens, C. Liu, and A. Jamalipour, IEEE n MAC frame aggregation mechanisms for nextgeneration high-throughput WLANs, Wireless Communications, IEEE, vol. 15, pp , Feb [16] I. T. Recommendation, ITU-T recommendation G.711. Pulse code modulation (PCM) of voice frequencies, Nov [17] I. T. Recommendation, ITU-T recommendation Y.1541: Network Performance Objectives for IP-Based Services, tech. rep., International Telecommunication Union, REFERENCES [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 (Revision of IEEE Std ), pp , [2] Cisco, Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, /ns827/white paper c html, February [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 , Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

22 Gestão de Cargas numa Micro Grid Utilizando Algoritmos Genéticos Jorge Eduardo Instituto Superior de Engenharia Universidade do Algarve Faro, Portugal Pedro Cardoso Instituto Superior de Engenharia Universidade do Algarve Faro, Portugal Jânio M. Monteiro Instituto Superior de Engenharia Universidade do Algarve Faro, Portugal Resumo O sistema de produção de energia elétrica tem até hoje caraterizado-se por um esquema de geração centralizado, unidirecional e contendo medidas de incentivo e controlo sobre a procura de consumo. Com o recente desenvolvimento de novos equipamentos de geração e controlo verifica-se uma mudança gradual deste modelo para outro denominado de Smart Grid, em que a geração de eletricidade distribuída, geralmente de baixa potência, começa a integrar-se de uma forma eficaz com a rede já existente e nã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 potência produzida que varia em função de fatores ambientais, baseia-se na implementação de tarifários variáveis. Mas para que tal venha a ser possível é necessário desenvolver uma série de equipamentos que consigam comunicar entre si e com a rede de distribuição, utilizando protocolos normalizados, gerindo os consumos de uma forma otimizada em função dos tarifários previstos e refletindo as preferências dos utilizadores. Neste âmbito, o objetivo deste artigo é o de definir e avaliar uma solução de otimização aplicada à gestão de cargas em Smart Grids baseada em algoritmos genéticos, que em função de restrições impostas pelo utilizador defina o escalonamento de funcionamento de diversas cargas. Palavras-chaves: Smart Grids, Home Grids, Micro Grids, Algoritmos Genéticos. I. INTRODUÇÃO Nas redes de produção e distribuição de energia elétrica encontramos atualmente um dinamismo bastante diferente daquele que encontrávamos há uns anos atrás, resultante em grande parte da crescente introdução de fontes de energia renováveis. Ao contrário da distribuição elétrica clássica, na produção obtida a partir de energias renováveis, os fatores ambientais de que elas dependem causam variações na geração difíceis de controlar, que por sua vez, são a causa de ineficiências e desadaptações de diversa ordem. Diversas soluções têm sido apontadas neste âmbito. Algumas propostas apontam para que se promova um ajuste no lado do consumo por forma a que este se nivele à potência produzida. Outras soluções apontam para que se armazene a energia produzida em excesso em determinado momento, recorrendo entre outros, às baterias dos automóveis elétricos. Há ainda soluções que optam por tarifar a produção para autoconsumo privado, de sistemas ligados à rede energética, numa tentativa de limitar a generalização destes equipamentos e reduzir os riscos de desestabilização, tal como aconteceu recentemente em Espanha [1]. Se por um lado a produção desregulada pode ser vista como um risco, o ajuste do consumo em momentos de pico é visto como algo desejável por parte dos operadores de eletricidade. Assim, a primeira versão do protocolo Open Automated Demand Response (openadr) [2] surgiu como uma das medidas que poderia minimizar os apagões verificados na crise energética vivida no ano 2000, no estado da Califórnia. Em termos de tarifários de eletricidade, existe uma clara desadaptação entre os preços dos tarifários dos utilizadores e os custos marginais de produção [3]. Uma solução que poderia resolver este problema passa pela introdução de tarifários dinâmicos, que estão neste momento a ser testados e implementados em várias regiões dos Estados Unidos da América, a par da instalação de 27 milhões de contadores inteligentes já efetuada [4]. Assim, pretende-se comunicar aos equipamentos e pessoas o tarifário em vigor para que estas decidam em consonância. Neste contexto, as tecnologias associadas às Smart Grids surgem como a solução que a médio/longo prazo permitirão a gestão eficiente das redes energéticas equipadas de geração renovável, através de equipamentos que combinem as redes de distribuição elétrica, as redes de comunicação, as redes de sensores e as tecnologias de informação, criando uma plataforma de configuração fácil e acesso ubíquo. Neste sentido, o objetivo de criação de um sistema de gestão de energia é 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 renováveis e a melhoria da gestão energética de edifícios. No âmbito dos protocolos que podem ser utilizados para gestão energética salientam-se as recentes especificações das arquiteturas protocolares Smart Energy Profile versão 2 (SEP 2.0) [6], IEEE 1888 [7] e do protocolo OpenADR 2.0 [8]. Qualquer arquitetura protocolar que venha a ser implementada não pode por isso ser criada sem ter em conta essas soluções. A um nível mais baixo salientam-se também o conjunto de protocolos IPv6 e 6LoWPAN que cada vez mais assumem importância em redes com elevado número de objetos inteligentes A Internet do futuro 13

23 capazes de comunicar entre si, sobre redes com ou sem fios. Por fim, suportando-se nas tecnologias de informação, o sistema deverá fazer do utilizador o elemento chave da solução final. Para tal, deverá ser criada uma interface que lhe permita de uma forma fácil aceder, configurar e modificar sempre que seja necessário as suas preferências. Por exemplo cabe ao utilizador especificar que a temperatura da água quente não deve baixar dos 30 graus, ou que o programa da máquina de lavar a louça deve terminar antes das 19:00. Ao utilizador cabe a definição das restrições a que o sistema deverá responder, sendo o primeiro liberto da gestão do sistema. Essa gestão deverá ser feita utilizando algoritmos de otimização que, tendo em conta os tarifá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. É este o âmbito deste artigo. O resto do artigo tem a seguinte estrutura. A secção II apresenta o conjunto de protocolos de comunicação atualmente em definição para Smart Grids. A secção III apresenta os algoritmos de otimização considerados neste artigo, nomeadamente os algoritmos genéticos. A secção IV faz a descrição e formulação do problema do controlo de cargas. A secção V descreve os testes e ensaios efetuados. Por fim, a secção VI conclui o artigo apontando possíveis desenvolvimentos futuros. II. PROTOCOLOS DE COMUNICAÇÃO EM SMART GRIDS A possibilidade de os utilizadores gerirem os seus consumos de energia em função da produção é uma característica crítica das Smart Grids sendo a base de inovação, novos produtos e serviços. Por forma a suportar esta capacidade, a comunicação entre os diversos dispositivos, tais como contadores, eletrodomésticos, veículos elétricos, sistemas de gestão de energia e recursos energéticos distribuídos (incluindo energias renováveis e armazenamento) deve ocorrer utilizando procedimentos abertos, seguros e normalizados. Neste âmbito, foram recentemente definidos vários protocolos. Um desses protocolos, o Smart Energy Profile resulta da colaboração entre low-power ZigBee, o Wi-Fi e a Home Plug power-line technologies, construindo uma arquitetura de gestão de energia para Micro Grids, suportada em redes IP. Assim, ao contrário do SEP 1.0 que considerava apenas o ZigBee como forma de interligação entre objetos inteligentes, nesta última versão as comunicações já incluem ligações Wi-Fi e PLC. O Smart Energy Profile foi desenhado para implementar uma arquitetura REST, tendo como base as ações do GET, HEAD, PUT, POST e DELETE, complementadas com um mecanismos de subscrição leve. Apesar do SEP se poder suportar em qualquer protocolo que implemente uma comunicação REST (por exemplo o Constrained Application Protocol (CoAP) [9]) o HTTP é considerado a base para a interoperabilidade das aplicações. Em março de 2011, o Institute of Electrical and Electronics Engineers (IEEE), a maior associação profissional do Mundo anunciou a aprovação e publicação da norma Standard for Ubiquitous Green Community Control Network Protocol (IEEE 1888 TM ), no âmbito da Ubiquitous Green Community Control Network Protocol (UGCCNet). Com origem na China, a norma IEEE 1888 assume-se como uma norma global no âmbito da IoT que tem como objetivo a eficiência energética, através da gestão das energias renováveis (dita green energy), através da comunicação utilizando protocolos Internet e as Tecnologias de Informação e Comunicação. Como fundamento da especificação das normas, está a intenção de criar um novo sistema de controlo fácil de utilizar, largamente divulgado e inteligente, incluindo: a fácil monitorização do consumo, análise dos desperdícios energéticos e sugestões de melhoria, controlo automático de índices de conforto (CI), ajuste produção-consumo, entre outros. Várias sub-normas IEEE 1888 estão atualmente em definição, identificadas como IEEE 1888.x, com x a variar entre 1 e 4. O protocolo de aplicação Open Automated Demand Response (OpenADR) versão 2.0 [8], é uma evolução e extensão da primeira versão desenvolvida pela Demand Response Research Center no Lawrence Berkeley National Laboratory. OpenADR 2.0 é suportado pela aliança industrial OpenADR, tendo sido desenvolvida como parte da norma OASIS Energy Interoperation 1.0 publicada em Fevereiro de Uma característica que diferencia o OpenADR de outras arquiteturas que implementam o Demand Response (DR) automatizado é a de que os pedidos não contêm informação que especifique os dispositivos ou operaçõ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 através de um aumento no preço da eletricidade. As respostas dos equipamentos dependem sempre das preferências diretas ou indiretas do utilizador. Para alé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 às opções dos utilizadores. O resultado é um sistema que promove a DR automatizada, enquanto maximiza a flexibilidade local em resposta aos pedidos. O núcleo da norma OpenADR 2.0 é constituído por um conjunto de modelos de dados e padrões de troca que definem os sinais de DR e as interfaces entre: mercados de energia (no sentido de suportarem uma informação de preço dinâmico), Independent System Operators (ISO), Distributed Energy Resources (DER) e consumidores de energia (industriais/residenciais). Se por um lado os protocolos que permitem a comunicação entre os diversos equipamentos de uma Micro Grid estão a ser definidos, há ainda que definir os procedimentos de controlo de cargas otimizados que permitam o ajuste DR. Esse é o âmbito das próximas secções. III. ALGORITMOS DE OTIMIZAÇÃO Em matemática, o termo otimização, refere-se ao estudo de problemas em que se busca minimizar ou maximizar uma função através da escolha sistemática dos valores de variáveis reais ou inteiras dentro de um conjunto viável. Para a resolução destes problemas, além de possíveis métodos específicos, existem métodos genéricos de 14 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

24 otimização, usualmente designados de meta-heurísticas, que podem aproximar as soluções dos problema que se consigam modelar de acordo com estruturas de dados adequadas. Exemplos são os Algoritmos Genéticos (AG) [10], os algoritmos baseados em colónias de formigas (Ant colony Optimization) [11] ou os algoritmos Particle Swarm Optimization [12]. Em particular neste artigo dedicaremos a nossa atenção aos AGs. O processo evolutivo dos AG começa por uma população (ou geração) inicial, formada por um conjunto de indivíduos que representam soluções do problema a otimizar. Em geral, a população inicial é definida aleatoriamente, usando heurísticas, ou soluções conhecidas. As gerações seguintes são obtidas iterando sobre os passos que se seguem até se verificar o critério de paragem especificado. Começa-se por avaliar os indivíduos da geração de forma a definir a sua qualidade dentro da população. No passo seguinte alguns dos indivíduos são selecionados de acordo com as suas aptidões, i.e., quanto melhores forem os indivíduos mais chances terão de serem escolhidos para o efetuarem o cruzamento. Na fase do cruzamento são criados novos indivíduos, os filhos, que combinam as caraterísticas dos pais. A alguns desses novos indivíduos são aplicadas mutações de modo a evitar a estagnação da população e consequente convergência prematura. Os indivíduos obtidos são agora colocados numa nova população com tamanho igual ao da população original. O processo pode ser resumido de acordo com o Algoritmo 1. Algoritmo 1 Algoritmo genético 1: Gerar a população inicial. 2: Enquanto critério de paragem não for satisfeito faça 3: Avaliar cada indivíduo da população. 4: Seleccionar os indivíduos mais aptos. 5: Criar novos indivíduos aplicando os operadores: cruzamento e mutação. 6: Armazenar os novos indivíduos numa nova população. 7: Fim Enquanto 8: Devolve a melhor solução encontrada Na seção seguinte iremos apresentar uma formulação para problema da gestão eficiente de energia e discutir a solução implementada. IV. DESCRIÇÃO E FORMULAÇÃO DO PROBLEMA A. Formulação do Problema O objetivo de um sistema de controlo de cargas é o de minimizar os custos do consumo de eletricidade de diversos aparelhos deslocando-os no tempo (ou ajustando a potência consumida). O sistema deverá procurar minimizar o custo em função do tarifário em vigor. Para além disso, o sistema deve impedir em cada momento que o consumo exceda a potência contratada. Deste modo são vários os objetivos, dos quais podemos destacar: minimizar o custo dos consumos de diversos equipamentos; não exceder a potência contratada; evitar exceder em consumo a potência produzida por fontes renováveis, quando existentes; utilizar tanto quanto possível as tarifas económicas; ter em conta as restrições temporais impostas pelo utilizador para cada um dos equipamentos. B. Descrição do Simulador O sistema que se pretende implementar pode ser visto como um sistema em que cada objeto (contadores, geradores e consumidores) é 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 otimização é controlado por um agente central que comunica e decide os períodos de funcionamento dos outros agentes usando um algoritmo genético. Como benefício, o sistema distribuído pode fornecer redundância, flexibilidade e adaptabilidade. No nosso caso, trata-se de um sistema bastante flexível quando consideramos a adição ou remoção de novos objetos produtores ou consumidores, que é feita de forma transparente. Salientamos que foi ponderado um processo de otimização distribuído, usando processos de negociação de períodos de funcionamento entre agentes, mas que nesta fase foi deixado para trabalho futuro. Utilizando o sistema híbrido que esboç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 comunicações e decisões passem por um único objeto centralizador, não perdendo a flexibilidade associada à 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 está encarregue de guardar o seu histórico de utilização e informar o centralizador das suas potências. Relativamente ao simulador este foi implementado sobre a plataforma SPADE (Smart Python Multi-Agent Development Environment) [14], [15]. O SPADE foi constuído à volta da framework de comunicação XMPP/Jabber. Desenvolvido em Python, trata-se de um sistema particularmente útil na implementação de SMA, suportando os conceitos de agente e servidores, a comunicação entre agentes desenvolvidos em múltiplas linguagens de programação, processamento de comportamentos e o protocolo de comunicação extensível baseado em XML. O SPADE segue ainda as especificações FIPA para SMA [16]. Quanta à implementação do simulador foi considerada a sequência de passos que a seguir descrevemos. O processo começa com o gestor de cargas (GC) a enviar uma mensagem em broadcast para todos os equipamentos de consumo, com a requisição dos pedidos de funcionamento dos equipamentos, horário de início pretendido, limite para terminar o programa, além do seu registo de consumo previstos ao longo do tempo. Para efeitos de simulação, foi estipulado que esta requisição é enviada às 7h00. O GC aguarda pelas respostas dos agentes e após as ter recebido com os dados requisitados, efetua o escalonamento dos horários de início de funcionamento das máquinas. Como já referimos, neste escalonamento é aplicado um AG. A informação do escalonamento (horários de ínicio) é depois enviada a cada um dos consumidores. A Internet do futuro 15

25 Figura 1. Diagrama da sequência de mensagens entre o gestor de cargas e os consumidores. Cada equipamento consumidor guarda o horá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 horário de início de funcionamento passa a enviar os seus dados de consumo até terminar o período de operaçã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 máquina consumidora. A configuração usada inclui o método de seleção uniforme, o operador de cruzamento de ponto único e os operadores de mutação swap e Gaussiano inteiro. Na Figura 1 está resumida sequência que acabámos de descrever. V. TESTES E ENSAIOS Por forma a confirmar a fiabilidade do simulador desenvolvido fez-se uma análise gradual de testes com o objetivo de verificar o procedimento de cálculo do custo e o correcto posicionamento das cargas. Admitindo uma potência contratada de 3.3 kva, foi considerado um valor unitário para o factor de potência (PF), resultando na potência ativa de 3.3 kw. Admitindo que numa habitação ou empresa existirão cargas que não são controláveis, o sistema de controlo de carga irá ajustar a soma das potências das cargas controláveis para que esta não ultrapasse uma percentagem da potência contratada (por exemplo 0.80), evitando assim o deslatre dos circuitos quando as cargas não controláveis aumentem de potência. Para efeitos de testes foi considerado um tarifário com três tarifas: P1 ( horas de vazio ) 0.1 euros por kwh entre as 22h00 e as 22h30; P2 ( horas de cheia ) euros por kwh entre as 22h30 e as 10h30 (do dia seguinte); e P3 ( horas de ponta ) euros por kwh entre as 10h30 e as 22h00. Tendo em conta este tarifário e admitindo cargas de potência constante durante períodos de 1 hora, a expectativa é que o início de funcionamento das cargas fique próximo do início do período das horas vazias. Assim, por exemplo, admitindo 3 cargas de 1kW com uma duração de 1 hora, os tarifários anteriores e uma potência máxima controlável de 2.64 kw (admitindo uma rácio entre potência controlada e potência contratada de 0.8), espera-se que duas cargas tenham início aproximado às 22h00 e que uma das cargas seja obrigada a deslocar-se para o tarifário P2. Consideremos outro exemplo, admitindo quatro cargas em que uma das cargas tem 2.5 kw constantes durante uma hora e as outras três cargas consomem 1 kw durante uma hora, a carga de 2.5 kw deverá ocupar o horário da tarifa mais baixa e as restantes três cargas ficarão na tarifa intermédia, pois é essa a solução que minimiza o custo. De seguida apresentamos resultados experimentais considerando um cenário de cargas constantes ao longo do seu 16 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

26 Figura 2. Consumo das cargas de acordo com o escalonamento e tarifários para 4 equipamentos período de funcionamento e posteriormente os ensaios considerarão curvas de carga de equipamentos reais. A. Resultados para uma máquina 2.5 kw e três máquinas de 1 kw com três tarifários Nestes testes foram quantificados os custos resultantes do escalonamento temporal dos diversos equipamentos, comparando a introdução do algoritmo genérico com uma seleção aleatória da hora de entrada em funcionamento das máquinas. Consideraram-se quatro equipamentos: um consumindo uma potência de 2.5 kw durante 1 hora e três consumindo uma potência de 1 kw durante 1 hora. Para limitar as opções dos testes, a tarifa mais baixa apenas esteve disponível entre as 22:00 e as 22:30 (de acordo com o tarifário apresentado na secçã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 simulações foram repetidas vinte vezes, tendo-se posteriormente calculado a média e desvio padrão de custos para ambas as situações (escalonamento aleatório e escalonamento com o AG). A média de custos diária para a entrada em funcionamento aleatória dos equipamentos foi de Euros, com um desvio padrão de Euros. Já no caso da introdução do AG alcançou-se um custo médio de Euros com desvio padrão igual a Estes resultados traduzem uma redução média de custos de 17.6%. A Figura 2 apresenta um dos resultados do algoritmo genético. Como se pode constatar, a carga que consome maior potência ficou escalonada para iniciar o funcionamento às 22:00 e as outras cargas ficaram escalonadas para funcionar no período do tarifário com custo intermédio (P2), o que traduz o custo mais baixo possível. B. Resultados para quatro equipamentos (reais) com três tarifas Nos testes seguintes foram consideradas curvas de potência consumida de diversos equipamentos existentes em residências, obtidas utilizando o Analisador de Qualidade de Energia Fluke 435. Entre os registos disponíveis, não foram considerados controláveis cargas como arcas frigoríficas, iluminação ou aparelhos AVAC. Os quatro equipamentos considerados controláveis foram: a máquina de lavar a roupa, a máquina de secar roupa, o termoacumulador e bomba de piscina. Os resultados destes ensaios não têm uma análise tão balizada, em que se perceba de antemão qual é o resultado final do posicionamento de cada uma das cargas de consumo porque estas poderão ser encaixadas nas tarifas mais baixas sem ultrapassar os 80% da potência contratada. O algoritmo deverá garantir que o início de funcionamento das máquinas não conduza a que a soma das potências ultrapasse os 80% da potência contratada. Na Figura 3 apresenta-se a potência consumida ao longo do tempo por: a) Bomba de Piscina; b) Máquina de Lavar Roupa; c) Máquina de Secar Roupa; d) Termoacumulador. Também neste caso o simulador foi executado vinte vezes. Das simulações obteve-se uma média de 0,5028 Euros (desvio padrão igual Euros) para a entrada em funcionamento dos equipamentos num instante aleatório. Já no caso da introdução do AG alcançou-se um custo médio de Euros com desvio padrão igual a Estes resultados traduzem uma redução média de custos de 16%, confirmando os resultados obtidos previamente. VI. CONCLUSÕES E TRABALHO FUTURO Neste artigo foi apresentado um método para efetuar o escalonamento de cargas ao longo de um dia com o objetivo de minimizar os custos associados aos consumos. Essa minimização tem em conta os tarifários conhecidos à priori. O processo foi simulado na plataforma multi-agentes SPADE, tendo sido apresentado os valores obtidos para dois cenários. Conclui-se que no cenário de teste o AG obteve uma melhoria de cerca de 17%, enquanto que no cenário com leituras de máquinas reais essa melhoria foi de cerca de 16%. Como trabalho futuro, pretende-se considerar a produção de energia através de fontes renováveis, otimizando de acordo com as estimativas de produção ao longo do dia, aplicar cargas não controláveis, estudar processos de otimização distribuídos incluindo processos de negociação entre agentes. AGRADECIMENTOS Este trabalho foi parcialmente suportado pelo projeto Manage the Intelligence QREN I&DT, n.o REFERÊNCIAS [1] Propuesta de real decreto por el que se establece la regulación de las condiciones administrativas, técnicas y economicas de las modalidades de suministro de energía eléctrica con autoconsumo y de producción com autoconsumo, Online: Julho [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 , [3] P. L. Joskow and C. D. Wolfram, Dynamic pricing of electricity, The American Economic Review, vol. 102, no. 3, pp , A Internet do futuro 17

27 Figura 3. Potência consumida ao longo do tempo pelos equipamentos: a) Bomba de Piscina; b) Máquina de Lavar Roupa; c) Máquina de Secar Roupa; d) Termoacumulador [4] Utility-Scale Smart Meter Deployments, Plans & Proposals, Institute for Electric Efficiency, Setembro [5] J.-P. Vasseur and A. Dunkels, Interconnecting smart objects with ip: The next internet. Morgan Kaufmann, [6] Smart Energy Profile 2, Application Protocol Standard, Zigbee public document ed., ZigBee Alliance, abril [7] IEEE Standard for Ubiquitous Green Community Control Network Protocol, IEEE Std 1888 Std., abril [Online]. Available: [8] OpenADR 2.0. Profile Specification. A Profile, OpenADR Alliance, [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 [10] A. E. Eiben and J. E. Smith, Introduction to evolutionary computing. Springer Berlin, 2010, vol. 2. [11] M. Dorigo and T. Stützle, Ant Colony Optimization. MIT Press, [12] R. Poli, J. Kennedy, and T. Blackwell, Particle swarm optimization, Swarm intelligence, vol. 1, no. 1, pp , [13] Y. Shoham and K. Leyton-Brown, Multiagent systems: Algorithmic, game-theoretic, and logical foundations. Cambridge University Press, [14] E. Argente, J. Palanca, G. Aranda, V. Julian, V. Botti, A. Garcia- Fornes, and A. Espinosa, Supporting agent organizations, in Multi- Agent Systems and Applications V. Springer, 2007, pp [15] M. E. Gregori, J. P. Cá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 [16] Fipa specifications, online: [17] Pyevolve, online: Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

28 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, 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. A Internet do futuro 19

29 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 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, 20 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

30 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. 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. System Startup Monitoring Service Activation Monitoring Event /Fault Detection Reoptimization Process USER Service Handler Database Flow Handler Monitoring Activator Controller OF Network Service Request Response Save Request Get Flows Description Response Update Flows Get Flows Description Response Update Flows Subscription Response Notification Notification Flows Activation Response Network Information Request Flows Check-up Response Event /Fault Detection Flows Reoptimization Response Network Information Request Response Rule Update Response Network Information Request Response Flows Activation Response Flows Check-up Response Rule Update Response Openflow protocol Openflow protocol Openflow protocol Openflow protocol Openflow protocol 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. A Internet do futuro 21

31 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 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

32 Node CPU Model A B C D Intel PentiumD 950 Intel Core 2 Duo E6400 Intel Core 2 Duo E6400 Intel PentiumD 950 TABLE I TESTBED SPECIFICATION CPU CPU CPU HDD RAM RAM Freq. Cores Threads Memory Amount Freq, GB 6 GB 667 GHz MHz 2.13 GHz 2.13 GHz 3.40 GHz DDR GB 4 GB 533 MHz DDR GB 4 GB 533 MHz DDR GB 6 GB 667 MHz DDR2 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. 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. 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 A Internet do futuro 23

33 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. International Conference on emerging Networking EXperiments and Technologies (CoNEXT), 2009 [18] 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 ). IEEE. June,2012. REFERENCES [1] Open Networking Foundation: Enabled Hybrid Cloud Services Connect Enterprise and Service Provider Data Centers, white paper, November, [2] Open Networking Foundation: Software-Defined Networking: The New Norm for Networks, white paper, April, [3] 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, [4] W. Stallings: Software-Defined Networks and Openflow, in The Internet Protocol Journal, Cisco, Volume 16, Issue 1, pp. 2-14, March, [5] H. Nagasono: NTT DATA s Efforts for Openflow/SDN, in NTT Technical Review, Volume 10, Number 11, November, [6] Open Networking Foundation: Openflow Switch Specification, August, [7] OpenDaylight: An Open Source Community and Meritocracy for Software-Defined Networking, April, [8] 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, May, [9] H. Egilmez, B. Gorkemli, A. Tekalp and S. Civanlar: "Scalable video streaming over OpenFlow networks: An optimization framework for QoS routing", Image Processing (ICIP), th IEEE International Conference on, pp , September, [10] 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 , April, [11] 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, October, [12] 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 , December, [13] S. Paul and R. Jain: "OpenADN: Mobile apps on global clouds using OpenFlow and Software Defined Networking", Globecom Workshops (GC Wkshps), 2012 IEEE, pp , 3-7 December, [14] J. Aparício, Integração da Cloud com a rede do Operador, Master Thesys, Department Electronic Telecommunication and Informatics, University of Aveiro, Aveiro, Portugal, [15] R. Gouveia, Demonstrador de uma rede Openflow, Master Thesys, Department Electronic Telecommunication and Informatics, University of Aveiro, Aveiro, Portugal, [16] A. Köpsel and H. Woesner: Test Facility for OpenFlow Experimentation, In EICT GmbH, Berlin. November, 2011 [17] V. Jacobson, D. K. Smetters, J. D. Thornton, M.F. Plass, N.H. Briggs, and R. L. Braynard, Networking Named Content, Fifth ACM 24 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

34 Framework e Cliente WebRTC Vasco Amaral, Solange Rito Lima Telma Mota Paulo Chainho Portugal Telecom Inovação, SA, Aveiro, Portugal Centro Algoritmi, Departamento de Informática, Universidade do Minho Campus de Gualtar, Braga, Portugal Resumo WebRTC é uma tecnologia normalizada, que permite a comunicação em tempo real entre browsers, sem a necessidade de instalar plugins adicionais. Desta forma é possível a qualquer dispositivo (computadores, smartphones, etc.) que tenha instalado um browser, realizar comunicações em tempo real peer-to-peer, de uma forma nativa. Exemplo disso são as comunicações de voz, vídeo e também a possibilidade de falar por chat, partilhar ficheiros e partilhar ecrã. É uma tecnologia relativamente recente mas tem vindo a crescer exponencialmente, tanto a nível de soluções implementadas, como também a nível de compatibilidade de web browsers. Desta forma WebRTC torna-se uma tecnologia em forte crescimento e evolutiva, onde poderão surgir cada vez mais soluções de serviços. Atendendo a que ainda não está definida uma implementação normalizada para a comunicação entre endpoints WebRTC, este artigo apresenta um projeto que consiste numa abordagem à tecnologia WebRTC, de forma a identificar as potencialidades desta tecnologia e de que forma podem ter impacto no mundo das telecomunicações. No decorrer do estudo realizado, e para o fundamentar, foi desenvolvida uma framework que tem como objetivo tornar mais fácil a criação e implementação de serviços WebRTC, que servirá como uma solução de comunicação entre vários clientes. Este é o foco deste artigo, em que se apresenta um estudo realizado à tecnologia WebRTC de forma a determinar a sua maturidade e a sua evolução. Pretende-se, adicionalmente, mostrar os principais aspectos envolvidos no desenvolvimento de uma framework que irá permitir, a utilizadores ou entidades externas, criar serviços ou aplicações WebRTC de uma forma simples e a um alto nível. Vários serviços alvo são testados como prova de conceito no âmbito do desenvolvimento da framework. O artigo está organizado da seguinte forma: na Secção II são apresentados os conceitos associados à tecnologia WebRTC, nomeadamente a arquitetura e as Application Programming Interface (APIs) que a constituem; na Secção III aborda-se o trabalho relacionado com WebRTC, como as soluções já existentes em termos de sinalização e também em termos de tecnologia; na Secção IV são apresentados os serviços que se pretendem desenvolver no âmbito da framework e a solução arquitetural apresentada para os suportar; na Secção V incluem-se as principais conclusões do trabalho desenvolvido. I. INTRODUÇÃO Cada vez mais as telecomunicações estão presentes no nosso dia-a-dia. São criados mais serviços, cada vez mais baratos, que se tornaram indispensáveis no nosso quotidiano. Exemplo disso, são as chamadas áudio, as videochamadas, as mensagens, etc. Tal como estes serviços, a Web tem evoluído de uma forma bastante significativa, tornando-se um meio indispensável e onde circula uma grande quantidade de informação diariamente. Começ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 divisão mais equilibrada de carga entre o servidor e o cliente. Com esta evolução começaram a surgir novas tecnologias que permitem a criação de soluções inovadoras, como a tecnologia WebRTC. Esta tecnologia vem dinamizar o mundo das telecomunicações permitindo a criação de novas soluções de serviços. WebRTC é uma tecnologia recente que tem estado em constante evolução e traz grandes desafios. No mundo empresarial os maiores desafios passam pelos serviços que podem ser desenvolvidos com esta tecnologia. Para isso, é necessário fazer um estudo à tecnologia e implementar uma solução que permita facilitar o desenvolvimento de diferentes serviços de telecomunicações (e.g., presença, lista de contactos, chamadas áudio e vídeo, etc). II. CONCEITOS Nesta secção são apresentados os principais conceitos inerentes à 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 aplicações Web, o uso da Web API é fundamental. Permite tirar proveito das funcionalidades WebRTC que os Web browsers suportam, a partir de programação JavaScript [3]. B. WebRTC API A API de WebRTC está a ser desenvolvida sobre três conceitos essenciais: PeerConnection, MediaStreams e DataChannel [1]. 1) PeerConnection: PeerConnection permite que dois utilizadores comuniquem diretamente, browser-to-browser. Para estabelecer esta ligação e haver uma sinalização de negociação, é necessário que haja um canal de sinalização. Este é fornecido por um script implementado num servidor Web, utilizando A Internet do futuro 25

35 Figura 1. Arquitetura WebRTC [3]. C. WebSockets O WebSocket Protocol é um protocolo que fornece uma comunicação bidirecional, baseado em sockets e usa HTTP como camada de transporte. Desta forma é possível usar WebSockets com soluções web já existentes, visto que pode trabalhar sob portas HTTP como 80 e 443, o que facilita a integração deste protocolo com as soluções já existentes. Para além disso, este protocolo não está apenas limitado ao HTTP, o que permite fazer um handshake simples sob uma porta sem reinventar o protocolo [4], [5]. Na Figura 2 estão representados dois tipos de ligações: polling (HTTP) e WebSockets. Numa ligação polling o browser necessita de estar sempre a fazer pedidos, pois o servidor só responde no caso de receber esses pedidos. No caso do WebSocket o browser faz apenas um pedido e o servidor envia toda a informação em vários pacotes de dados, sem ter que receber qualquer pedido adicional por parte do browser. Esta ligação entre o servidor e o browser é designada como uma ligação persistente, pois sempre que um deles precisar de enviar qualquer informação podem fazê-lo a qualquer momento. 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 é uma forma abstrata de representar uma stream de dados áudio e/ou vídeo. Este tipo de aplicações pode ser usada para mostrar, gravar ou enviar o seu conteúdo para um peer remoto. Existem dois tipos de stream: Local MediaStream ou Remote MediaStream. Local MediaStream é a stream capturada no próprio sistema (webcam e microfone) enquanto que Remote MediaStream é a stream recebida de outro peer. Para ter acesso à media dos componentes do terminal é necessário executar a função getusermedia(), onde podem ser definidos alguns parâmetros, dependendo do que o utilizador do terminal queira reproduzir. Para a transmissão das streams são usados protocolos como Secure Real-time Transport Protocol (SRTP), Realtime Transport Protocol (RTP) e Real-time Transport Control Protocol (RTCP) para monitorização de transmissão de media. O Protocolo Datagram Transport Layer Security (DTLS) é usado como uma chave de SRTP e para gestão de associações [1], [25], [2]. 3) DataChannel: RTCDataChannel é um canal de dados bidirecional em ligações peer-to-peer. É possível serem transferidos dados que não sejam media e é necessário usar outro protocolo, como SCTP encapsulado em DTLS. Desta forma existe uma solução para NAT com confidencialidade, autenticação da fonte e integridade dos dados que sejam necessários transferir. O SCTP permite a entrega, fiável e não fiável, de dados e permite que as aplicações abram várias streams independentes. Para a criação de um DataChannel é necessário executar a função CreateDataChannel() numa instância da PeerConnection [1], [25], [2]. Figura 2. Comparação de latência entre polling e aplicações Websockets [6]. D. Sinalização Ao contrário do que acontece com uma infraestutura completamente pensada para estabelecer uma ligação ou até mesmo controlar todo o media, o mesmo não acontece quando se fala da sinalização. Para estabelecer uma chamada entre os utilizadores, é necessário haver uma negociação de parâmetros da sessão, descritos via Session Description Protocol (SDP). A definição do método a utilizar fica a cargo da camada aplicacional, ou seja, a pessoa que está a desenvolver uma aplicação pode definir o método que quer para a sinalização. Apesar disso existem alguns protocolos que definem como deve ser feita a sinalização. Por exemplo, o JavaScript Session Establishment Protocol define de que forma as aplicações JavaScript interagem com as funções Real Time Communication (RTC). Este protocolo é responsável pela forma como os clientes podem recolher informação sobre o tipo de media que suportam e que codecs usam, o que fica definido num objeto 26 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

36 SDP RTCSessionDescription. O JSEP fornece mecanismos de criação de offers e answers, como também de que forma podem ser aplicadas numa sessão [9]. Este protocolo não define de que forma essa informação é trocada, ou seja, não é definido como essa informação é enviada ou recolhida do servidor web, ficando isso a cargo do programador. Package Manager (npm) [10]. O npm, para além de servir para instalar os módulos, permite também tratar da gestão de versões e gestão de dependências. Um dos módulos que permite desenvolver aplicações que atuem em tempo real e que utilizem uma API tipo WebSockets, é o socket.io. Este permite que WebSockets e tempo real estejam presentes em qualquer browser, para além disso ainda fornece multiplexing, escalabilidade horizontal e codificação e descodificação em JSON [10]. Figura 3. Modelo JSEP [9]. A figura 3 mostra o modelo utilizado pelo JSEP, onde as mensagens entre o browser e a aplicação são objetos SDP, e o protocolo que é usado para transmitir essa informação é especificado na camada aplicacional. III. SOLUÇÕES WEBRTC Com a evolução da tecnologia WebRTC nestes últimos anos, o número de aplicações e/ou soluções WebRTC têm vindo a aumentar. Existem soluções para realizar conferências entre duas ou mais pessoas (Conversat.io), partilha de ecrã, partilha de ficheiros, falar por chat, partilha de conteúdos peer-to-peer, com o objetivo de não sobrecarregar os servidores (peercdn), e ainda usar jogos multiplayer que utilizam RTCDataChannel (BananaBread). Existem ainda soluções SIP HTML5 que usam a Web API, para que haja uma interoperabilidade entre sistemas SIP nativos e sistemas WebRTC (sipml5). Estes são exemplos de aplicações Web funcionais. WebSockets é uma tecnologia que também se encontra em desenvolvimento e ainda não é suportável em todos os browsers. Existem várias aplicações que permitem o desenvolvimento de soluções Websockets num servidor, as duas mais relevantes para este artigo são: Node.js e Vertx.io. A. Node.js É uma plataforma orientada a eventos, do lado do servidor, que permite a criação de aplicações web escaláveis. Os programas que são desenvolvidos com esta plataforma são escritos em JavaScript e são assíncronos, o que permite diminuir o overhead e aumentar a escalabilidade [11]. Contém uma biblioteca de servidor HTTP, que permite correr aplicações web sem usar um servidor típico HTTP (e.g. Apache). Esta plataforma permite a criação de aplicações que tenham por objetivo funcionar completamente em tempo real, como por exemplo, streaming de voz ou vídeo, ou então serviços de chat e partilha de ficheiros [11]. Implementa um repositório de módulos, onde cada um tem uma funcionalidade diferente. Cada um destes módulos pode ser instalado a partir de Node B. Vertx.io É uma framework da próxima geração, que corre em Java Virtual Machine (JVM), é orientada a eventos e assíncrona. Implementa um modelo de concorrência assíncrono que permite a criação de aplicações facilmente escaláveis, de uma forma simples. No que diz respeito às linguagens de programação que podem ser usadas, é uma framework poliglota, suportando desenvolvimento em: Java, JavaScript, Groovy, Ruby, Python e Scala. Para além das características apresentadas anteriormente, esta framework aborda alguns conceitos que são importantes para o desenvolvimento de aplicações [15], [14], nomeadamente: Verticle: Um verticle é definido por ter uma função principal (main), que corre um script específico. Um verticle pode conter mais verticles, desde que sejam referenciados na função main. EventLoops: São threads que estão sempre a correr e estão sempre à escuta, de forma a verificar se existem operações a executar ou dados a tratar. A gestão destas threads é feita por uma instância do Vert.x, que aloca um número específico de threads a cada núcleo do servidor. Work Verticle: Este tipo de verticle não é atribuído a uma thread event loop do Vert.x, em vez disso, é executado a partir de uma thread que se encontra numa pool de threads internas, à qual se chama background pool. EventBus: Esta é uma característica do Vert.x bastante importante que permite a comunicação entre vários verticles ou módulos do Vert.x. Para além disso, é possível haver uma comunicação não só entre verticles mas entre entidades que registem handlers num servidor (ex. clientes). Desta forma é possível a partilha de informação entre as várias entidades que constituam um sistema, chamada de Message Passing. Pode-se verificar na figura 4 uma arquitetura específica do Vert.x. Modules: É possível a criação de módulos individuais, que executem diferentes funções. Isto permite uma melhor organização de código e uma maior escalabilidade de aplicações. A comunicação entre os módulos é feita a partir de um eventbus. Existe ainda um repositório onde existem módulos previamente criados, que podem ser usados para facilitar a construção de aplicações. No que diz respeito a frameworks, bibliotecas ou repositórios não se verificam muitos desenvolvimentos. Foram desenvolvidas algumas soluções que permitem criar soluções WebRTC de uma forma mais simples e mais dinâmica, a um mais alto nível. No que diz respeito a bibliotecas e A Internet do futuro 27

37 Figura 4. Funcionamento geral da aplicação Vert.x [13]. Tabela I PERFIXOS DAS INTERFACES NOS DIFERENTES browsers [12]. W3C Standard Google Chrome Mozilla Firefox getusermedia Não Suporta Suporta >v17 RTCPeerConnection Não Suporta Suporta >v22 RTCSessionDescription Não Suporta Suporta >v22 RTCIceCandidate Não Suporta Suporta >v22 repositó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 são feitas de forma diferente, ou seja, é necessário executar funções diferentes na mesma aplicação caso se queira que a aplicação funcione em dois ou mais browsers diferentes. A Tabela I representa que tipo de funções são usadas para desenvolver uma solução WebRTC em diferentes browsers. A biblioteca Adapter.js vem unificar estas funções, isto é, ao carregar esta biblioteca para uma aplicação é possível usar funções W3C Standard que podem ser usadas tanto no Chrome como no Firefox. D. WebRTC Experiment É um repositório de bibliotecas JavaScript que implementa demos WebRTC e que tem por objetivo ajudar no desenvolvimento de aplicações deste tipo. Existem quatro bibliotecas diferentes neste repositório: RTCMultiConnection.js, DataChannels.js, RecordRTC.js e RTCall.js [16]. 1) RCMultiConnection.js: Com esta biblioteca é possível desenvolver alguns serviços avançados de uma forma mais simples, como [18]: conferências Áudio/Vídeo; partilha de dados ou de ficheiros; partilha de ecrã; renegociação de streams múltiplas e remoção de streams individuais; fazer mute ou unmute às várias streams (áudio e vídeo); banir utilizadores; deteção de presença (orientado a eventos onde é verificado quando um utlizador entra ou sai, sem vários estados de presença). Esta biblioteca usa firebase por defeito, que é uma tecnologia com uma base de dados na cloud e que permite desenvolver aplicações em tempo real. Tem uma estrutura de dados partilhada e sincronizada, desta forma sempre que os dados são mudados ou atualizados é possível atualizar essa informação em todos os clientes que estão ligados [18]. Para além disso, é possível implementar uma solução que use socket.io ou WebSockets. 2) DataChannel.js: É uma biblioteca JavaScript que foi desenhada para ajudar a desenvolver aplicações para partilha de dados. Estes dados podem ser ficheiros ou simples mensagens de texto. Tal como a RTCMultiConnection.js simplifica o desenvolvimento de aplicações. Esta biblioteca implementa as seguintes funcionalidades [19]: mensagens de texto directas entre utilizadores; banir ou rejeitar qualquer utilizador; sair de uma sessão ou encerrar uma sessão completa; tamanho de ficheiros ilimitado; quantidade de dados ilimitada; detecção de presença (orientado a eventos onde é verificado quando um utlizador entra ou sai, sem vários estados de presença). Como indicado na biblioteca RTCMultiConnection.js, usa por defeito e como backend o firebase, mas também pode usar socket.io ou Websockets para sinalização. 3) RecordRTC.js: Esta biblioteca foi desenvolvida para permitir aos utilizadores guardarem áudio, vídeo ou até mesmo imagens animadas. A stream de áudio é gravada no formato.wav, a stream de vídeo é 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 informação. Fica a cargo de quem está a desenvolver a aplicação dizer se quer como retorno o URL, DataURL ou o objeto Blob [17]. Esta biblioteca pode ser útil para gravar chamadas entre clientes, ou até mesmo gravar uma mensagem de videomail ou voic . 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 são oferecidos serviços, poderá ter um botão em que os seus clientes clicam e telefonam para si. Desta forma é possível tirar dúvidas sobre produtos ou até mesmo reportar problemas encontrados. Assim há uma maior interatividade entre administradores e clientes [20]. E. SimpleWebRTC É uma biblioteca Javascript que permite desenvolver aplicações de comunicações em tempo real em ambientes Web (WebRTC). É possível configurar variáveis, para simplificar a implementação das soluções que se pretendem desenvolver, como saber quais os objetos HTML5 aos quais se devem alocar as streams, se o pedido para permissão de uso de câmara e microfone deve ser feito automaticamente ou não. 28 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

38 Para além disso, é uma biblioteca orientada a eventos, que permite saber se o utilizador está pronto e se está à espera que alguém se junte à sessão [21]. É necessário usar um servidor socket.io, que servirá como servidor de sinalização, que está implementado num servidor Web fornecido pelos criadores deste repositório [21]. Como a tecnologia Vert.x permite uma separação por módulos, foi decidido desenvolver uma arquitetura modular em que cada módulo tem funções diferentes, separando assim o funcionamento dos serviços por módulos. A figura 5, ilustra de que forma foi definida a arquitetura para a framework e de que forma o cliente poderá interagir com o servidor. IV. FRAMEWORK DESENVOLVIDA Esta secção apresenta a solução proposta para o desenvolvimento de uma framework que tem por objetivo permitir, a utilizadores ou entidades externas, criar serviços ou aplicações WebRTC de uma forma simples e a um alto nível. Foram definidas algumas especificações inicialmente para o desenvolvimento desta solução. Houve uma análise inicial às tecnologias e bibliotecas existentes. Analisaram-se os potenciais de cada uma delas, desde o seu desempenho em várias situações e quais é que forneciam mais vantagens neste projeto. A. Tecnologias Foram analisadas vá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], sã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 (200- OK), a cada pedido realizado a esse servidor. Vert.x conseguiu responder a mais de pedidos (servidor programado em Java), enquanto Node.js ultrapassou um pouco os pedidos. Num segundo teste o servidor fornecia um ficheiro estático de 72 bytes a cada pedido. Verificou-se que o Vert.x atingiu mais de pedidos por segundo enquanto o Node.js não ultrapassou os 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 atualizações sobre o stock e notificações de pedidos realizados. Neste teste a tecnologia Vert.x foi escalável até às ligações, fazendo com que o servidor ficasse sem memória. No que diz respeito ao Node.js, foi escalável até as ligações, tornando-se lento a partir desse momento. Concluiu-se que a tecnologia Vertx.io era mais rápida, mais escalável e apresentava melhor desempenho. Juntando estas conclusões à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 necessário definir alguns dos serviços que se pretendem ver desenvolvidos: chamada / Conferência áudio e vídeo; presença e Lista de contactos; chat / Mensagens instantâneas; partilha de ficheiros; gravação voz e vídeo. Figura 5. Arquitetura da framework. Como ilustrado, existe o lado do cliente e do servidor. Os módulos existentes estão registados na parte do servidor. Assim, o cliente, a partir do EventBus, poderá comunicar diretamente com cada um dos módulos para executar as funções necessárias. 1) Módulo Servidor Web: O módulo Web Server consegue criar um servidor Web onde são facilmente fornecidos ficheiros que se encontrem nesse servidor. Tem uma configuração bastante completa, onde são indicados os campos mais importantes. Desta forma é possível ter um servidor Web completo, que responda aos pedidos de cada cliente, a partir de um endereço específico. Cada pedido de um cliente, ou até mesmo de um módulo no servidor, deve ser direcionado para esse endereço, para que o servidor Web possa retornar uma resposta. 2) Módulo Base de Dados Mongo: No que diz respeito à base de dados optou-se por utilizar uma base de dados não relacional, Mongo DB. Tal deve-se ao facto de existir um módulo desenvolvido pela comunidade Vert.x, que permite uma gestão dinâmica e simples da base de dados. Este módulo permite operações como: save: salva documentos nas collections existentes; update: atualiza informaçã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 número de documentos numa collection; delete: apaga todos os documentos associados. Todas estas operações são executadas apenas pelos módulos do servidor, isto é, toda a atividade executada pelos clientes é enviada primeiro para os módulos como: Módulo de Presença, Notificação, Histórico de Chamadas, etc. Estes módulos são A Internet do futuro 29

39 responsáveis por atualizar toda a informação da base de dados, que lhe esteja relacionada. 3) Módulo de Presença: O módulo de presença permite a implementação do serviço de presença e de lista de contactos. É o módulo que está responsável por adicionar e remover pessoas da lista de contactos, atualizar o estado de presença de cada pessoa (Online, Offline, Ausente, Ocupado). Cada cliente, para além do seu perfil de utilizador, onde se encontram informações como: nome de utilizador, , password e histó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 subscrição por parte de outros utilizadores. Estes pedidos são guardados numa lista que se chama presence authorization pendent, onde estão todos os pedidos de subscrição que ainda não foram tratados. Os pedidos rejeitados são guardados numa lista denied presence e os que são aceites na lista authorised presence. É nesta última lista que estão guardados todos os contactos de um cliente. A partir do momento que um cliente executa a autenticação no sistema, será enviada uma mensagem tipo find para o módulo de presença que ficará encarregue de procurar e carregar todos os contactos desse cliente, como também o estado de presença de cada um (Online, Offline, Ausente, Ocupado). Para além disso, é enviada outra mensagem para o mesmo módulo, de forma a que se possa atualizar a informação da sessão desse utilizador. Cada utilizador tem um endereço registado para cada pessoa da sua lista de contactos, isto é, cada cliente tem registado um endereço específico (presence.<nome do contacto >), por cada contacto que tenha na sua lista. Sempre que um cliente atualize o seu estado, irá enviar uma mensagem publish de forma a que todos os seus subscribers possam receber essa mensagem, como ilustrado na Figura 6. Figura 6. Notificação de mudança de estado. Desta forma é possível manter a informação sobre o estado de presença dos contactos atualizada. Para adicionar uma pessoa à lista de contactos é enviada uma mensagem do tipo subscribe para este módulo, o cliente adicionado será notificado de que alguém o quer adicionar. A partir do momento que é aceite esse pedido, o módulo encarregar-se-à de atualizar a informação referente a esses dois utilizadores, colocando ambos na lista authorised presence de cada um e irá notificar a pessoa que enviou o pedido. No caso do pedido ser rejeitado, ambos serão colocados na lista denied presence de cada um, notificando o cliente que realizou o pedido de que foi rejeitado. 4) Módulo de Notificação: O módulo de notificações trata as mensagens de notificação referentes às chamadas. Sempre que um utilizador é convidado para uma sessão de chamada/conferência é enviada uma notificação para esse utilizador, de que um cliente o quer contactar. Assim, este cliente pode escolher se quer rejeitar ou não a sessão. Existem notificações que estão associadas a outros módulos, logo não passam por este. Exemplo disso são as notificações do módulo de presença, sempre que é adicionado um novo cliente à lista de contactos, a notificação é tratada no módulo de presença. O mesmo acontece quando um cliente muda o seu estado de presença. 5) Módulo de Histórico de Chamadas: O módulo histórico de chamadas guarda informação referente às conferências ou chamadas efetuadas dos utilizadores. Sempre que é iniciada uma sessão de chamada/conferência é guardada a hora inicial da chamada, juntamente com a data e quem iniciou a chamada. Conforme forem entrando pessoas nessa sessão a informação vai sendo atualizada, existindo a possibilidade de saber todas as pessoas que participaram nessa sessão. Quando a sessão termina é enviada uma mensagem do tipo registcall, para este módulo para que a informação relativa a essa sessão possa ser guardada na base de dados. Desta forma a informação está sempre atualizada e sempre que um utilizador fizer autenticação no sistema, poderá visualizar o histórico das chamadas realizadas e recebidas. As informações guardadas na base de dados referente a cada chamada realizada são: initiator - pessoa que iniciou a chamada/conferência; hour - hora de inicio da chamada/conferência; date - data da chamada/conferência; duration - duração da chamada/conferência; participants - pessoas que participaram na chamada/conferência. 6) Módulo Gestor de Chamadas: O módulo gestor de chamadas permite ter um maior controlo no que diz respeito às chamadas/conferências. O cliente poderá escolher que tipo de sessão quer iniciar, isto é, se quer realizar uma chamada áudio e vídeo, ou se apenas quer falar por mensagens com um determinado utilizador. É possível escolher vários serviços para uma sessão de chamada, desde: chat, partilha de ficheiros, partilha de ecrã, chamada/conferência áudio, chamada/conferência vídeo, e também todos estes serviços numa sessão. Quando um cliente quer iniciar uma sessão de chamada/conferência, envia uma mensagem para o servidor com todas as características da sessão. Desta forma, este módulo irá tratar a mensagem para que seja enviada uma notificação para cada cliente, que esteja convidado para entrar na sessão. Assim, é possível informar cada um dos clientes de qual é o tipo de sessão e que serviços são necessários para a iniciar. 30 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

40 7) Módulo Gestor de Sessões: O módulo gestor de sessões permite uma gestão mais completa das sessões que são iniciadas. Existem dois tipos de sessões: sessões de utilizadores e sessões de chamadas. As sessões de utilizadores são iniciadas sempre que um cliente se autentica no sistema, sendo guardados dados como: nome do utilizador, estado, identificador da sessão e os endereços correspondentes aos serviços. Quando o utilizador sai do sistema, a sessão que lhe está associada é apagada. As sessões de chamadas são iniciadas sempre que é realizada uma chamada/conferência entre utilizadores. Desta forma é possível ter um controlo total da chamada, como a hora a que se iniciou, há quanto tempo está a decorrer a chamada, quais os participantes e qual o estado atual da chamada. Com esta informação é possível voltar ao estado atual de uma chamada mesmo que algum erro ocorra durante a mesma. C. Aplicação Cliente Como referido anteriormente, foi desenvolvida uma aplicação cliente com o objetivo de demonstrar as funcionalidades da framework. Esta aplicação foi delineada recorrendo a tecnologias como HTML5, JavaScript e Websockets, que permitem o desenvolvimento de aplicaçõ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/conferência áudio e vídeo; presença e lista de contactos; chat/mensagens instantâneas; partilha de ficheiros; partilha de ecrã e histórico de chamadas. Toda a parte da sinalização usa a tecnologia socket.io, que permite a criação de namespaces entre peers, garantindo que a negociação de sinalização seja feita apenas entre dois peers. Quanto aos serviços de presença, lista de contactos e histórico de chamadas, foram desencadeados à parte da tecnologia WebRTC, utilizando o Vert.x para troca de mensagens entre peers e o servidor. Estes módulos interagem mais frequentemente com o servidor, pois é necessário que mantenham toda a informação actualizada em runtime. Todo o processo de validação e teste de serviços foi contínuo, acompanhando dos módulos de suporte. Desta forma foi possível verificar e validar as funcionalidades, de forma a poder avançar para o desenvolvimento de outros módulos. Foi feita uma validação final, onde foram testadas todas as funcionalidades implementadas na aplicação cliente. tecnologia WebRTC e o protocolo WebSockets. Como trabalho futuro pretende-se enriquecer a framework com mais serviços, como Voice Activity Detection (VAD) e quadro interativo. Para além disso, pretende-se resolver eventuais problemas que surjam e melhorar a framework no que diz respeito a desempenho e interoperabilidade entre browsers. REFERÊ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 [2] HTML5 Rocks: Getting Started with WebRTC, com/en/tutorials/webrtc/basics/, [3] WebRTC: General Overview, architecture, [4] The Websocket Protocol, [5] Introducing websockets: Bringing sockets to the web, html5rocks.com/en/tutorials/websockets/basics/, [6] Html5 web sockets: A quantum leap in scalability for the web., http: // [7] The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)., [8] Real-Time Web Communication by using XMPP Jingle., org/html/draft-suzuki-web-jingle-00, [9] Javascript Session Establishment Protocol (JSEP)., html/draft-ietf-rtcweb-jsep-03, [10] Node packaged modules., [11] Nodejs., [12] Interop Notes., [13] OSGi case study: a modular vert.x., /07/osgi-case-study-modular-vertx.html, [14] Vert.x., [15] Vert.x - main manual., [16] Realtime/Working WebRTC Experiments., muaz-khan/webrtc-experiment, 2012 [17] RecordRTC: WebRTC audio/video recording / Demo., com/muaz-khan/webrtc-experiment/tree/master/recordrtc, 2012 [18] RTCMultiConnection Documentation., WebRTC-Experiment/tree/master/RTCMultiConnection, 2012 [19] DataChannel.js : A JavaScript wrapper library for RTCDataChannel APIs., 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., [22] Single page apps in depth., [23] Vert.x vs node.js simple HTTP benchmarks., 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., [25] Alan Johnston and Daniel Burnett WebRTC: APIs and Rtcweb Protocols of the Html5 Real-Time Web, USA: Digital Codex LLC, 1 ed., V. CONCLUSÃO E TRABALHO FUTURO A tecnologia WebRTC tem vindo a crescer, assim como a sua comunidade. Existem cada vez mais soluções, tanto a nível de aplicaçõ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 serviços, consoante evidenciado neste trabalho, é possível desenvolver uma framework que permita a criação de serviços a um mais alto nível. Foi possível desenvolver serviços como: presença, lista de contactos, chamada / conferência áudio e vídeo, chat, partilha de ficheiros e partilha de ecrã. Todos estes serviços foram desenvolvidos utilizando a A Internet do futuro 31

41 32 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

42 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. INTRODUCTION 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 A Internet do futuro 33

43 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. II. SYSTEM ARCHITECTURE 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. INTRUSION DETECTION 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 Information Source Live Network Stream Offline Traffic Source Other Network Entities Event Manager Log File Alarm Trigger Log Manager Report Generator tcpdump Packet System Manager Classifier Output (Normal/Attack) Preprocessing Unit Input Data Generator Feature Extractor Normalizer Output Data Generator Anomaly Detection Module MLP weights Figure 1. MLP-based anomaly IDS architecture. Evaluator Train MLP Test MLP MLP Classifier 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. ANN Input Vector Expected Output 34 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

44 IV. EVALUATION PROCESS DESCRIPTION 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. 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. 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 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. CDF for different normalization methods mapstd mapminmax [ 1.1] mapminmax [0.1] processpca Overall detection rates (%) 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. CDF for different network structures layers 3 layers 2 layers * Overall detection rates (%) 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. A Internet do futuro 35

45 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. 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 BEST 12 OVERALL DETECTION RATES FOR THE SECOND TESTING PHASE Training Algorithm Neurons in Hidden Layer Detection Rate (%) Attack Normal Overall traingda 45 98,36 94, traingdx 63 96,5 96, traingda 20 97,37 95, traingdx 94 95,86 96, traingdx 44 97,1 95, trainscg 88 96,2 96, traingda 71 96,95 95, trainscg 24 96,37 95, traingdx 40 96,06 96, trainscg 27 96,43 95, traingdx 74 95,59 96, traingdx 97 95,73 96, 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. CDF for different training algorithms traincgb traincgf 0.2 traincgp traingda 0.1 traingdx trainscg Overall detection rates (%) 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. CONCLUSIONS 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. 36 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

46 Table II COMPARISON OF PERCENTAGES OF SUCCESSFUL CLASSIFICATION FOR ANN-BASED IDS Reference MLP Structure Detection Rate (%) Moradi, M. et al., 2004 [28] 2-layers 87 Moradi, M. et al., 2004[28] 3-layers 91 Siddiqui, M., 2004 [29] 2-layers Sammany, M. et al., 2007 [30] 3-layers Barapatre, P. et al., 2008 [31] 2-layers Ahmad, I. et al.,2009 [20] 3-layers 98 * Haddadi, F. et al., 2010[18] 2-layers 94 Norouzian, M.R. et al.,2011 [19] 3-layers Present work 2-layers * Limited to the analysis of only four specific type of attacks VI. FUTURE WORK 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. REFERENCES [1] R. Richardson, 2010/2011 computer crime and security survey, Computer Security Institute (CSI), Tech. Rep., [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 , [3] W. Li, Using genetic algorithm for network intrusion detection, Proceedings of the United States Department of Energy Cyber Security Group, pp. 1 8, [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, [5] J. Dickerson and J. Dickerson, Fuzzy network profiling for intrusion detection, in Fuzzy Information Processing Society, NAFIPS. 19th International Conference of the North American, 2000, pp [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 [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 , [8] A. Rapaka, A. Novokhodko, and D. Wunsch, Intrusion detection using radial basis function network on sequences of system calls, in Neural Networks, Proceedings of the International Joint Conference on, vol. 3, 2003, pp vol.3. [9] A. Hofmann and B. Sick, Evolutionary optimization of radial basis function networks for intrusion detection, in Neural Networks, Proceedings of the International Joint Conference on, vol. 1, 2003, pp 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 , [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 Springer, 2006, pp [12] F. Yanwei, Z. Yingying, and Y. Haiyang, Study of neural network technologies in intrusion detection systems, in Wireless Communications, Networking and Mobile Computing, WiCom 09. 5th International Conference on, sept. 2009, pp [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 , [14] C. Jirapummin, N. Wattanapongsakorn, and P. Kanthamanon, Hybrid neural networks for intrusion detection system, in Proc. of ITC CSCC, 2002, pp [15] V. Golovko, L. Vaitsekhovich, P. Kochurko, and U. Rubanau, Dimensionality reduction and attack recognition using neural network approaches, in Neural Networks, IJCNN International Joint Conference on, aug. 2007, pp [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, IDAACS th IEEE Workshop on, sept. 2007, pp [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 [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 [19] M. Norouzian and S. Merati, Classifying attacks in a network intrusion detection system based on artificial neural networks, in Advanced Communication Technology (ICACT), th International Conference on, feb. 2011, pp [20] I. Ahmad, A. Abdullah, and A. Alghamdi, Application of artificial neural network in detection of probing attacks, in Industrial Electronics Applications, ISIEA IEEE Symposium on, vol. 2, oct. 2009, pp [21] A. Hassan, A. Elnakib, and M. Abo-Elsoud, Fpga-based neuroarchitecture intrusion detection system, in Computer Engineering Systems, ICCES International Conference on, nov. 2008, pp [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 , [23] Darpa intrusion detection data sets, [Online]. Available: [24] Kdd cup 1999 data, [Online]. Available: 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, [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 , [27] Matlab r2012b neural network toolbox documentation, [Online]. Available: [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, [29] M. Siddiqui, High performance data mining techniques for intrusion detection, Ph.D. dissertation, University of Central Florida Orlando, Florida, [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 [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, ICCCn International Conference on, dec. 2008, pp A Internet do futuro 37

47 38 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

48 Configuração Dinâmica em Redes sem Fios Daniel Alexander Lopes Fuentes 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 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 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 WLAN 1 ) [4], é composto por vários pontos de distribuição espalhados geograficamente e que se 1 do inglês Wireless Local Area Network 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 A Internet do futuro 39

49 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 (SOHO 2 ). 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. 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. 2 do inglês Small Office / Home Office Figura 1 - Arquitetura do sistema 40 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

50 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. 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. 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 SOFTWARE DE GESTÃO WEB SERVICES Figura 4 - Agente Servidor FICHEIROS DE CONFIGURAÇÃO AGENTE SERVIDOR 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 Adicionar, editar ou remover equipamentos Sistema de monitorização Consultar o estado dos equipamentos Figura 5 - Comunicação entre sistemas Figura 3 - Agente Distribuição B. 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. A Internet do futuro 41

51 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 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 42 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

52 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 A Internet do futuro 43

53 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 Dispositivo configurado 209 segundos 295 segundos 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. 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 Dispositivo configurado 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 Dispositivo configurado 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 Distribuição Principal Distribuição Secundária (1) Distribuição Secundária (2) Cliente Tempo 184 segundos 397 segundos 568 segundos 649 segundos Como se pode verificar, mesmo devido ao fato de existir uma DS adicional neste cenário, os tempos apresentados não 44 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

54 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 [9] C. Prehofer, C. Bettstetter. Self-Organization in Communication Networks: Principles and Paradigms. IEEE Comunication Magazine [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 [12] F.J. Mullany, et al. Self-Deployment, Self-Configuration: Critical Future Paradigms for Wireless Access Networks. WAC [13] K. Zimmerman. An Autonomic Approach for Self-Organising Access Points. Diploma Thesis, University of Ulm Germany [14] M.H. Fazel Zarandi, P. Ahmadpour. Fuzzy agent-based expert system for steel making process. Expert Systems With Applications 36(5) [15] U. Manzoor, K. Ijaz, A. Shahid. Distributed dependable enterprise business system DDEBS. Proceeding of springer communications in computer and information science, vol [16] Sergio Ilarria, Eduardo Menaa, Arantza Illarramendib. Using cooperative mobile agents to monitor distributed and dynamic environments. Information Sciences, [17] J.O. Kephart, W.E. Walsh. An artificial intelligence perspective in autonomic computing policies. Proceedings of POLICY [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) [19] G. Weiss. Multiagent systems a modern approach to distributed artificial intelligence. The MIT Press Crambridge [20] Wi-Fi Alliance. Wi-Fi CERTIFIED Wi-Fi Protected Setup [21] Buffalo Technology. AirStaion One-Touch Secure System [22] Wi-Fi Alliance. The State of Wi-Fi Security [23] OpenWRT, [ Acedido em Julho de 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 [2] M. Ranga, Mamello Thinyane, Alfredo Terzoli. Exploring Cost- Effective Reinforcements for Rural Telecommunication Networks: Dwesa Case Study. SATNAC [3] Rodrigo Selada. Redes Wireless de Banda Larga. Universidade de Trás-os-Montes e Alto Douro [4] Alex Hills. Large-Scale Wireless LAN Design. IEEE Communications Magazine [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 [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 [7] International Telecommunication Union. Future Networks: Objectives and design goals. ITU-T Y A Internet do futuro 45

55 46 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

56 Encaminhamento com QoS para Redes Ad Hoc com rotas estáveis Tiago Coelho Centro Algoritmi Univ. Minho, Portugal António Costa Centro Algoritmi & DI Univ. Minho, Portugal Joaquim Macedo Centro Algoritmi & DI Univ. Minho, Portugal M. João Nicolau Centro Algoritmi & DSI Univ. Minho, Portugal 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 FEDER A Internet do futuro 47

57 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. 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 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 On- Demand 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. Figura 1 - Caminhos de nós disjuntos 48 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

58 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. A Internet do futuro 49

59 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. 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. 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 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. 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. 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. 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 50 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

60 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. 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 Valor Dimensão 600m x 1500m Número de nós 80 Modelo de Mobilidade Random Waypoint Posição dos nós Aleatório Alcance transmissão 160m Tipo de tráfego Constant Bit Rate (CBR) Tamanho dos pacotes 64 bytes Número de fluxos 15 Taxa de transmissão 2Kbps Especificações Wifi IEEE b, freq. 2.4Ghz 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 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. 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. A Internet do futuro 51

61 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. Figura 3 - Taxa de entrega de pacotes no destino 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. REFERÊNCIAS Figura 4 - Taxa de transferência efectiva 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 [1] 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). [2] Clausen, Thomas, et al. "Optimized link state routing protocol (OLSR)." (2003). [3] 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). [4] 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 [5] X. Li and L. Cuthbert, " Multipath QoS routing of supporting Diffserv in Mobile Ad hoc Networks," Proc. of SNPD/SAWN.'05,2005. [6] 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 [7] 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 [8] Liu, Shun, and Jian Liu. "Delay-aware multipath source routing protocol to providing QoS support for wireless ad hoc networks." Communication Technology (ICCT), th IEEE International Conference on. IEEE, [9] NS-3, 52 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

62 Performance Evaluation of IEEE Underwater Wireless Networks Filipe Teixeira, Rui Campos, Manuel Ricardo INESC TEC, Faculdade de Engenharia, Universidade do Porto Porto, Portugal {fbt, rcampos, José Quevedo Instituto de Telecomunicaçõ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 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 g 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. INTRODUCTION 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 g 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 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 g 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 g 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 ns- 3 simulator. The simulation results are shown in Section 4. Finally, conclusions and future work are presented in Section 5. II. PROPAGATION MODELS 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. v RF = 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 m/s. v lightuw = c n = = m/s (2) Table I compares the propagation speed of RF waves in free space and in fresh water with the propagation speed of acoustic A Internet do futuro 53

63 TABLE I: Propagation speed for RF waves (Free Space, Fresh Water) and Acoustic waves (Fresh Water) Propagation Speed (m/s) 1 khz 10 khz 100 khz 1 MHz 10 MHz 100 MHz 1 GHz GHz 10 GHz Free Space (RF) Fresh Water (RF) Acoustic TABLE II: Attenuation of RF waves underwater (Fresh Water) Frequency 1 khz 10 khz 100 khz 1 MHz 10 MHz 100 MHz 1 GHz GHz 10 GHz Attenuation (db/m) 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 g networks, if Channel 1 is considered (2.412 GHz), the maximum value for the propagation speed ( ) can be achieved. This value is in the same order of magnitude of c ( ), 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 g 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]. 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 CSMA/CA is used as the medium access control mechanism. As the distance between the STAs and the AP increases, the hidden node problem L fresh water = f σ db/m (3) Table II shows the attenuation of RF waves in fresh water for different frequencies. We can observe from the table that for IEEE Channel 1, the attenuation is 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 GHz, we end up with a total path loss of almost 125 db. This shows the reduced range of underwater RF communications. (a) One STA scenario III. PERFORMANCE EVALUATION We evaluate the performance of IEEE g 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 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. (b) Two STA scenario Fig. 1: Tested Scenarios 54 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

64 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 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. RESULTS 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 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 A Internet do futuro 55

65 (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 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

66 (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. CONCLUSIONS 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 g 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 g equipment, running at 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). REFERENCES [1] N. A. Cruz, A. C. Matos, R. M. Almeida, and B. M. Ferreira, Trimares - a hybrid auv/rov for dam inspection, in OCEANS 2011, September [2] S. Mitchell, A sensor network for non-intrusive and efficient leak detection in long pipelines, in Wireless Days, October [3] 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 , December [4] X. Lurton, An Introduction to Underwater Acoustics - Principles and Applications. Springer, [5] 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 , May [6] S. Jiang and S. Georgakopoulos, Electromagnetic wave propagation into fresh water, Electromagnetic Analysis and Applications, vol. 3, pp , July [7] 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 , November [8] 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, March A Internet do futuro 57

67 [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 , September [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 , March [11] ns-3 discrete-event network simulator, version [Online]. Available: [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, May [13] S. Mitchell, Electromagnetic Wave Propagation - Theory and Application to Bathymetric Lidar Simulation. University of Colorado at Boulder, December Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

68 SILOS - a SImple LOcation Service for Vehicular Ad-hoc Networks André Camões INESC-ID/IST andre.camoes@ist.utl.pt Teresa Vazão INESC-ID/IST teresa.vazao@ist.utl.pt 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. INTRODUCTION 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. A. Location Services STATE OF THE ART 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 A Internet do futuro 59

69 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 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. ARCHITECTURE 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. 60 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

70 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. 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. 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. Fig. 1. Fig. 2. OBU Operation Model 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 A Internet do futuro 61

71 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 In order to illustrate the behaviour of the SILOS Protocol, an application example is presented on figure 3. accelerate until they reach 33 m/s, which matches the high-way speed limit. This speed is constant across the simulation. Parameter Value Simulator NS-3.12 SimulationTime 100s Number of Nodes 20 nodes Node Spacing 100 m Transmission Rate 8192 bps Transmission OBU Range 300m Transmission RSU Range 1000m Packet Size 512B Hello Rate 1pkt/s Location Entry LifeTime 5s Position Entry LifeTime 5s Propagation Loss Model Two Ray Ground + Nakagami TABLE I. SIMULATION 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: LocationOverhead(%) = LocationMessages LocationMessages+RoutingMessages+DataMessages (1) LocationAccuracy(m) = NLocQueries ( CurrentP ositioni P redictedp ositioni) i=1 T otallocationqueries (2) Fig. 3. Diagram of the SILOS Protocol T imeobtainp osition(ms) = NLocQueries ( T imelocationqueryi T imelocationreplyi) i=1 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: A. Test Scenario IV. TESTS 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 C. Results P acketdeliveryrate(%) = T otalnumberp acketst x T otalnumberp acketsrx (4) RoutingOverhead(%) = T otalmessages DataMessages T otalmessages (5) T hroughput(kbps) = NumberP acketsrx DataP acketlenght T otalt imesimulation (6) 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 62 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

72 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. 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. Fig. 5. 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 A Internet do futuro 63

73 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 Fundação para a Ciência e a Tecnologia, under project PEst-OE/EEI/LA0021/2013. Fig. 8. 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. Fig. 9. Throughput vs Distance V. CONCLUSION 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. REFERENCES [1] 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 [2] 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 [3] Fonseca, António and Camões, André and Vazão, Teresa, Geographical routing implementation in NS3, Proceedings of the Fifth International Conference on Simulation Tools and Techniques, 2012 [4] Lee Kevin C. and Lee, Uichin and Gerla, Mario, Survey of Routing Protocols in Vehicular Ad Hoc Networks, 2010 [5] Jagadeesh Kakarla, S Siva Sathya, B Govinda Laxmi, Ramesh Babu B.: A Survey on Routing Protocols and its issues in VANET, 2011 [6] Fonseca, A., Vazao, T.: Applicability of position-based routing for vanet in highways and urban environment. Journal of Networks and Computer Applications (2012) [7] 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 [8] Ayaida, Marwane and Fouchal, Hacène and Afilal, Lissan and Ghamridoudane, Yacine, A Comparison of Reactive, Grid and Hierarchical Location-based Services for VANETs, 2012 [9] Basagni, Stefano and Chlamtac, Imrich and Syrotiuk, Violet R. and Woodward, Barry A. A Distance Routing Effect Algorithm for Mobility (DREAM) 1998 [10] 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 [11] 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 [12] 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 (2000) [13] Kieß, Wolfgang and Fü, Holger and Widmer, Jörg and Mauve, Martin, Hierarchical location service for mobile ad-hoc networks, SIGMOBILE Mob. Comput. Commun. Rev., October 2004 [14] Das, Saumiua M and Hu, Y Charlie and Lafayette, West, Performance Comparison of Scalable Location Services for Geographic Ad Hoc Routing, 2005 [15] Woo, H., Lee, M.: Vehicle Location Service Scheme using the Vehicle Trajectory for VANETS ppp (2012) [16] Jacqueline Jardim, Teresa Vazão, Jorge Lopes: Simulação do uso de redes veiculares em situações de emergência numa auto-estrada Portuguesa, CRC Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

74 Solução Aberta para uma Rede de Sondas de QoS na RCTS Pedro Queirós Centro Algoritmi Univ. Minho, Portugal M. João Nicolau Centro Algoritmi & DSI Univ. Minho, Portugal Alexandre Santos Centro Algoritmi & DI Univ. Minho, Portugal 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. INTRODUÇÃ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. ESTADO 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 A Internet do futuro 65

75 [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 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. 66 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

76 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. 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. REDE DE SONDAS: SOLUÇÕES OPEN SOURCE 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 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]. 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 A Internet do futuro 67

77 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 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 68 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

78 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: perfso- NAR MDM [35], desenvolvida pelo GÉANT, e perfsonar- PS [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ções 1, destacam-se os membros das redes LHC OPN [38] e LHC ONE [39]. 7) Ferramentas de medição: As implementações do perf- SONAR 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 perfsonar- NC, 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. SOLUÇÃO ABERTA: TESTES E RESULTADOS 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 A Internet do futuro 69

79 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 (Braga- Lisboa) mínimo Figura 4: Sonda QoS; valores obtidos para OWD (Braga- Lisboa) 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. 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 70 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

80 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. CONCLUSÃ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 FE- DER, 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 FEDER 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. REFERÊNCIAS [1] The Story of the PING program. [Online]. Available: (accessed July 2012) [2] Traceroute for Linux. [Online]. Available: traceroute.sourceforge.net (accessed July 2012) [3] IP Performance Metrics. [Online]. Available: (accessed July 2012) [4] A One-way Active Measurement Protocol (OWAMP). [Online]. Available: (accessed July 2012) A Internet do futuro 71

81 [5] An implementation of the One-Way Active Measurement Protocol. [Online]. Available: performance/owamp/index.html (accessed July 2012) [6] QoSMet - Quality of Service Metrology. [Online]. Available: (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, Reunion Island. [8] Zhang Shu and Katsushi Kobayashi, HOTS: An OWAMP-Compliant Hardware Packet Timestamper, 2005 [9] iperf. [Online]. Available: iperf/ (accessed July 2012) [10] nuttcp. [Online]. Available: nuttcp/stable/nuttcp.html (accessed July 2012) [11] thrulay. [Online]. Available: 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: 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: 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: (accessed July 2012) [18] Nick Duffield, Sampling for Passive Internet Measurement: A Review, 2004 [19] Surveyor. [Online]. Available: inet99/proceedings/4h/4h_2.htm#surveyor (accessed July 2012) [20] RIPE Test Traffic Measurement Service. [Online]. Available: test-traffic-measurement-service (accessed July 2012) [21] RIPE Atlas [Online]. Available: (accessed August 2012) [22] perfsonar. [Online]. Available: (accessed July 2012) [23] PingER. [Online]. Available: stanford.edu/pinger/ (accessed July 2012) [24] Etomic. [Online]. Available: (accessed July 2012) [25] Archipelago Measurement Infrastructure. [Online]. Available: (accessed July 2012) [26] CAIDA. [Online]. Available: (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: (accessed June 2013) [30] ESnet. [Online]. Available: (accessed June 2013) [31] Internet2. [Online]. Available: (accessed June 2013) [32] RNP. [Online]. Available: (accessed June 2013) [33] Open Grid Forum s Network Measurement Working Group. [Online]. Available: (accessed June 2013) [34] D. Vicinanza, Intercontinental Multi-Domain Monitoring for LHC with perfsonar, 2012 [35] perfsonar Multi Domain Monitoring. [Online]. Available: (accessed June 2013) [36] perfsonar Perl Services. [Online]. Available: psps.perfsonar.net/ (accessed June 2013) [37] perfsonar User Interface. [Online]. Available: (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: (accessed June 2013) [40] BWCTL. [Online]. Available: performance/bwctl/ (accessed June 2013) [41] One-way Delay. [Online]. Available: html/rfc2679 (accessed June 2013) [42] Jitter Delay. [Online]. Available: html/rfc3393 (accessed June 2013) [43] Packet loss. [Online]. Available: rfc2680 (accessed June 2013) [44] Cacti. [Online]. Available: (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: internet2.edu/performance/owamp/details.html#ntp (accessed June 2013) 72 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

82 Using Web10G for Service and Network Diversity Exploitation and Failure Recovery Filipe Carvalho and José Legatheaux Martins CITI and DI-FCT, Universidade Nova de Lisboa, Quinta da Torre, Portugal Emai: 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. INTRODUCTION 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 A Internet do futuro 73

83 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. PROGRAMMING PATTERN AND RUN TIME SUPPORT 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. } 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. 74 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

84 and set by the programmer using the TCP sockets provided methods. III. IMPLEMENTATION 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 ) 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 best- SocketBeingUsed() 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)) { return 2; // recommend switch type 2 } if (isthereabetterpath(currentconn)) switchprob = HIGHPROB; else switchprob = SMALLPROB; double random = Math.random(); if(random < switchprob){ return 3; // recommend switch type 3 } // 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 A Internet do futuro 75

85 TABLE I CHARACTERISTICS OF THE LINKS USED IN THE FIRST TEST SCENARIO. Link Capacity RTT Packet loss Worst-path 700 Kbps 15 ms 1% Middle-path 900 Kbps 15 ms 1% Best-path 1000 Kbps 5 ms 1% to test and recommend the switching between connections to maintain the transfer active and as performant as possible. IV. EVALUATION 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 TABLE II JAVA SOCKET, NChannelSocket AND WGet TRANSFERS COMPARISON IN SECONDS. Java Socket NChannelSocket WGet Mean ± ± ± 0.82 TABLE III ONE PATH NChannelSocket TRANSFERS COMPARISON IN SECONDS. Worst-path Middle-path Best-path Mean ± ± ± 0.63 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 76 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

86 TABLE IV TESTS 1 (NO HISTORY) AND 2 (WITH HISTORY) - TOTAL TRANSFER TIME IN SECONDS. No History With History Mean ± ± 0.86 TABLE V TEST 3 (PERSISTENT FAILURE) - TOTAL TRANSFER TIME IN SECONDS. Persistent Failure Total time Switch at Mean ± ± 0.34 TABLE VI TEST 4 (DECREASE IN PERFORMANCE) - TOTAL TRANSFER TIME IN SECONDS. Decrease in performance Total time Switch at Mean ± ± 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 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 VII TEST 5 (WIRED LINK FAILURE) - TOTAL TRANSFER TIME IN SECONDS. Wireless (s) Wired (s) Link failure (s) Mean ± ± ± 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. RELATED WORK 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. A Internet do futuro 77

87 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. DISCUSSION 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. 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. CONCLUSIONS 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. REFERENCES [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), [2] D. Meyer, The locator identifier separation protocol (lisp), The Internet Protocol Journal, vol. 11, no. 1, March [3] V. Kafle and M. Inoue, Introducing multi-id and multi-locator into network architecture, Communications Magazine, IEEE, vol. 50, no. 3, pp , march [4] A. Ford et al., Architectural guidelines for multipath TCP development, Internet Engineering Task Force (IETF) - RFC 6182, March [5] E. Stewart, R., Stream control transmission protocol - proposed standard, Internet Engineering Task Force (IETF) - RFC 4960, September [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 , quarter [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 , march-april [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 , [9] Web10G Project [10] E. Gamma, R. Helm, R. E. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, [11] M. Carbone and L. Rizzo, Dummynet revisited, SIGCOMM Comput. Commun. Rev., vol. 40, no. 2, pp , Apr [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 , nov-dec [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 , aug Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

88 Towards Widespread use of SCTP for the Future Internet Bruno Sousa, Ricardo Santos, Marilia Curado 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. INTRODUCTION 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. RELATED WORK 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. A Internet do futuro 79

89 TABLE I: Modified SCTP API values Parameter Value Parameter Value rto min (ms) 10 hb interval 5000 rto max (ms) 1000 sack timeout (ms) 100 max burst 20 addip enable 1 path max retrans 1 addip noauth enable 1 III. FAST RECONFIGURATION ALGORITHM 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 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. EVALUATION 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 2000Mb, 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. 80 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

90 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. 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. tc qdisc add dev eth0 parent 1:3 handle 31: delay 100ms 20ms distribution normal Fig. 2: Adding network interface delay using tc code netem 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 ; ;0 Fig. 5: Received sequence log line (sequence number, received time, server number) V. RESULTS 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 tc qdisc add dev eth0 parent 1:3 handle 31: netem loss 5% Fig. 3: Adding network interface packet loss using tc code 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) iperf -c u -b 350m -t 3600 Fig. 4: Generating 350Mbps 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 ( 2000MB). C. Metrics For each test executed through the scenarios presented in Section IV-B, the following metrics were collected: CD_FRA CD_SCTP CD_TCP DVD_FRA DVD_SCTP DVD_TCP Test Cases 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. A Internet do futuro 81

91 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 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) Utilization of server 1 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% Transfer Time (s) 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 TCP Transfer Time (ms) transfer time (s) 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 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 e+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. Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

92 transfer time (s) CD 0 DVD 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 FRA SCTP TCP Transfer Time (s) Transfer Time (ms) SCTP transfer time (s) FRA e+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 A Internet do futuro 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

93 transfer time (s) Transfer Time (ms) CD DVD Test Cases Fig. 14: Average total file transfer time results for fail Transfer over time proto FRA SCTP 0 2e+05 4e+05 6e+05 8e+05 Sequence/Time 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. CONCLUSION 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. FRA SCTP TCP 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. ACKNOWLEDGMENTS 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 eficiência energética e smart metering, contract n , QREN FCOMP-01-02). REFERENCES [1] R. Stewart, Ed., Stream Control Transmission Protocol, IETF Request for Comments: 4960, September [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 [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 [4] Johan Eklund, Karl-Johan Grinnem, Stephan Baucke, Anna Brunstrom, Tuning SCTP failover for carrier grade telephony signaling, Elsevier Computer Networks 54 (2010), [5] M. Riegel, M. Tuexen, Mobile SCTP, Working Draft, Tech. Rep., [6] A. Brunstrom, K.-J. Grinnemo,1, R. Fracchia, Ł. Budzisz, R. Ferrús, G. Galante, F. Casadevall, Towards transport-layer mobility: Evolution of SCTP multihoming, Elsevier Computer Cummunications 31 (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, [8] Ryan W. Bickhart, Paul D. Amer, Randall R. Stewart, Transparent TCPto-SCTP Translation Shim Layer, EuroBSDCon, Copenhagen 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, [10] R. Rembarz, S. Baucke, and P. Mahonen, Enhancing resilience for high availability ip-based signaling transport, in Personal, Indoor and Mobile Radio Communications, PIMRC IEEE 16th International Symposium on, vol. 4, 2005, pp 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, [12] Sebastien Godard. (2006) Sysstat utilities home page. [Online]. Available: [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 [14] Bert Hubert. (2000) Linux Advanced Routing & Traffic Control HOWTO. [Online]. Available: [15] National Laboratory for Applied Network Research. (2008) Iperf. [Online]. Available: 84 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

94 A comparative analysis of IEEE 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 INESC TEC, FEUP, University of Porto Porto, Portugal Federal University of Santa Catarina Araranguá, Brazil {robson, pportugal and and Abstract The IEEE 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. INTRODUCTION 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 [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 e 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 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 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 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 MEDIUM ACCESS MECHANISMS The main medium access mechanism of the IEEE standard is based on a CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) mechanism, referred as DCF. More accurately, the original IEEE MAC sublayer introduces two MAC functions: the mandatory DCF and the A Internet do futuro 85

95 optional PCF. DCF is the basic IEEE 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 CW min. A backoff counter is used to maintain the current value of the backoff time. 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 CW max. 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. At the beginning of the CFP the PC sends a beacon message, which defines the maximum duration of the CFP (CFP max ). All stations that receive this beacon message set the NAV (Network Allocation Vector) to the value defined into the CFP max 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). PIFS NAV Beacon SIFS D1 + poll SIFS U1 + ack NAV = Network Allocation Vector Dx = Frames sent by Point Coordinator Ux = Frames sent by polled stations Fig. 2. PCF service. SIFS D2 + ack + poll Contention-Free Repetition Interval Contention-Free Period SIFS U2 + ack SIFS D3 + ack + poll PIFS D4 + poll No response to CF-Poll SIFS U4 + ack SIFS CF-End Reset NAV Contention Period CFPMaxDuration 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 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 networks, an additional function called HCF (Hybrid Coordination Function) was incorporated in 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 86 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

96 (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. 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: 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, CW min and CW max 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 Stream 1 ). 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 protocol, please refer to the standard [2]. 1 A Traffic Stream identifies a specific data flow between two stations. PIFS NAV Beacon PIFS CF-Poll SIFS Data NAV = Network Allocation Vector Fig. 3. Contention-Free Period SIFS Ack SIFS HCCA TXOP (polled) HCCA service. Contention-Free Repetition Interval Data SIFS Ack... CF-End Reset NAV AIFS Data SIFS EDCA TXOP Ack Contention Period PIFS CF-Poll SIFS HCCA TXOP polled Controlled Access Phase Reset NAV III. SIMULATION ANALYSIS 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 (SRV RT ) that exchange messages with each other through a real-time Access Point (AP RT ). The non-rt network operates based on the EDCA function and it is composed of 10 non-rt stations (clients) and one non- RT server (SRV non RT ) that also exchange messages with each other through a non-rt Access Point (AP non 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 (P i ). 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 P i, 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 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 non- RT 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 a A Internet do futuro 87

97 Average Deadline Misses (%) Fig. 4. Average Deadline Misses (%) Fig DCF PCF EDCA HCCA Upperbound deadline misses Number of Real-Time Stations (a) Network Load = Low Average deadline misses (P = 30ms) DCF PCF EDCA HCCA Upperbound deadline misses Number of Real-Time Stations (a) Network Load = Low Average deadline misses (P = 60ms) Average Deadline Misses (%) Average Deadline Misses (%) 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]. 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 P i = 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 DCF PCF EDCA HCCA Upperbound deadline misses Number of Real-Time Stations (b) Network Load = Mid Upperbound deadline misses Number of Real-Time Stations (b) Network Load = Mid Average Deadline Misses (%) Average Deadline Misses (%) DCF PCF EDCA HCCA Upperbound deadline misses Number of Real-Time Stations (c) Network Load = High DCF PCF EDCA HCCA Upperbound deadline misses Number of Real-Time Stations (c) Network Load = High 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 P i = 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 non- RT 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 P i 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, 88 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

98 Average Delay (ms) Fig. 6. Average Delay (ms) Fig DCF PCF EDCA HCCA Number of Real-Time Stations (a) Network Load = Low Average delay (P = 30ms) DCF PCF EDCA HCCA Number of Real-Time Stations (a) Network Load = Low Average delay (P = 60ms) 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)). 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 P i = 60 milliseconds. IV. SUMMARY AND STATE-OF-THE-ART 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 CW min and CW max 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 P i ), 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 Average Delay (ms) Average Delay (ms) DCF PCF EDCA HCCA Number of Real-Time Stations (b) Network Load = Mid Number of Real-Time Stations (b) Network Load = Mid DCF PCF EDCA HCCA Average Delay (ms) Average Delay (ms) DCF PCF EDCA HCCA Number of Real-Time Stations (c) Network Load = High DCF PCF EDCA HCCA Number of Real-Time Stations (c) Network Load = High 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. There are many published works addressing the IEEE 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. Numerous attempts were made to analyze the performance of IEEE 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 A Internet do futuro 89

99 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. CONCLUSION This paper presents a comparative assessment of the medium access mechanisms defined by the IEEE 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). REFERENCES [1] A. Willig, M. Kubisch, C. Hoene, and A. Wolisz, Measurements of a wireless link in an industrial environment using an IEEE compliant physical layer, IEEE Transactions on Industrial Electronics, vol. 49, no. 6, pp , December [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 (Revision of IEEE Std ), pp , [3] 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 , [4] 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 , [5] R. Moraes, P. Portugal, F. Vasques, and R. F. Custódio, Assessment of the IEEE e EDCA Protocol Limitations when Dealing with Real- Time Communication, EURASIP Journal on Wireless Communications and Networking, [6] N. Ramos, D. Panigrahi, and S. Dey, Quality of service provisioning in e networks: challenges, approaches and future directions, IEEE Network, vol. 19, no. 4, pp , [7] OPNET, OPNET Technologies Inc. OPNET Technologies Inc., February [Online]. Available: [8] IEEE Standard for Information Technology - Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: High- Speed Physical Layer in the 5 GHz Band, [9] S. Kumar, N. Shende, C. R. Murthy, and A. Ayyagari, Throughput Analysis of Primary and Secondary Networks in a Shared IEEE System, IEEE Transactions on Wireless Communications, vol. 12, no. 3, pp , [10] G. Tian and Y.-C. Tian, Markov Modelling of the IEEE DCF for Real-Time Applications with Periodic Traffic, in 12th IEEE International Conference on High Performance Computing and Communications (HPCC), 2010, pp [11] G. Tian, Y.-C. Tian, and C. Fidge, Performance analysis of IEEE DCF based WNCS networks, in IEEE 35th Conference on Local Computer Networks (LCN), 2010, pp [12] G. Bianchi, Performance analysis of the IEEE distributed coordination function, IEEE Journal on Selected Areas in Communications, vol. 18, no. 3, pp , [13] B. Sikdar, An Analytic Model for the Delay in IEEE PCF MAC-Based Wireless Networks, IEEE Transactions on Wireless Communications, vol. 6, no. 4, pp , [14] X. Chen, H. Zhai, X. Tian, and Y. Fang, Supporting QoS in IEEE e wireless LANs, IEEE Transactions on Wireless Communications, vol. 5, no. 8, pp , August [15] 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 [16] Y. Zhao, Performance analysis for VoIP traffic with limited retransmissions in IEEE based wireless networks, in 8th IEEE International Wireless Communications and Mobile Computing Conference (IWCMC), 2012, pp [17] P. Serrano, A. Banchs, P. Patras, and A. Azcorra, Optimal Configuration of e EDCA for Real-Time and Data Traffic, IEEE Transactions on Vehicular Technology, vol. 59, no. 5, pp , [18] M. Maadani, S. Motamedi, and M. Noshari, Delay analysis and improvement of IEEE e-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 [19] G. Cena, L. Seno, A. Valenzano, and C. Zunino, On the Performance of IEEE e Wireless Infrastructures for Soft-Real-Time Industrial Applications, IEEE Transactions on Industrial Informatics, vol. 6, no. 3, pp , [20] A. Pastrav, E. Puschita, and T. Palade, HCCA support in IEEE networks QoS and QoE performance evaluation, in 10th International Symposium on Electronics and Telecommunications (ISETC), 2012, pp [21] C. Casetti, C. F. Chiasserini, M. Fiore, and M. Garetto, Notes on the Inefficiency of e HCCA, in 62nd IEEE Vehicular Technology Conference (VTC), vol. 4, 2005, pp [22] 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 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

100 Bayesian based selfish aware routing on Delay Tolerant Networks Ricardo Oliveira, António Duarte Costa, Maria João Nicolau and Joaquim Macedo Centro Algoritmi, Universidade do Minho, Braga, Portugal 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. INTRODUCTION 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 A Internet do futuro 91

101 Fig. 2: Representation of selfish nodes on DTNs 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. II. RELATED WORK 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. 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. B. Evolutionary forwarding games [7] 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. 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. 92 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

102 III. ROUTING PROTOCOL 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 N i (Node i) message and send Host s message; S2: receive node N i message and do not send Host s message; S3: do not receive N i s message and send Host s message; S4: do not receive N i s message and do not send Host s message. 2) Delivery probability and classification assignment: The Nature (Ω) of the Hosts game with N i is given by the computation of the Cooperation Probability for N i. In the very first contact with N i, this value is 0.5 by default, hence the undefined classification. This value will increase and decrease as the Host, and N i 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 A Internet do futuro 93

103 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 new i = P C old i (P C old i ) P i ter (1) P C new i = P C old i + (1 P C old i ) P i ter (2) Where P C new i is the new cooperation predictability of node N i and P C old i is node N i old cooperation predictability. P i 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 Message s T T L. (3) C. Classifiers 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. E. Extended connection list 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. IV. SIMULATION 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. 94 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

104 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 i 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 6 hours 12 hours 18 hours SE S CE C 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. A Internet do futuro 95

105 V. DISCUSSION 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. APPENDIX A NOTATION Follows the notation and the meaning of the symbols used through the paper. A. Players Host : The node which is choosing the strategy. N i : The i node contacted in the network. B. Bayesian Game symbols Ω: Nature of the game. Npayoff i j: N i s payoff for doing j strategy. Hpayoff j : Hosts payoff for doing j strategy. P C def i : N i s default cooperation predictability. P C new i : N i s new cooperation predictability. P C old i : N i s old cooperation predictability. P i 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, [4] S. Ali, J. Qadir, and A. Baig, Routing protocols in delay tolerant networks a survey, Knowledge Creation Diffusion Utilization, pp , [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, [6] Q. Li, S. Zhu, and G. Cao, Routing in socially selfish delay tolerant networks, 2010 Proceedings IEEE INFOCOM, pp. 1 9, [7] R. El-azouzi, F. D. Pellegrini, and V. Kamble, Evolutionary forwarding games in Delay Tolerant Networks. IEEE, 2010, pp [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, [9] L. Yin, H.-m. Lu, Y.-d. Cao, and J.-m. Gao, Cooperation in delay tolerant networks, Signal Processing Systems ICSPS nd International Conference on, vol. 1, p. V1 202, [10] U. Shevade and Y. Zhang, Incentive-aware routing in dtns, 2008 IEEE International Conference on Network Protocols, pp , [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 , [12] Y. S. Uddin, B. Godfrey, and T. Abdelzaher, Relics : In-network realization of incentives to combat selfishness in dtns, th IEEE International Conference on Network Protocols ICNP, pp , [13] S. Keshav, Mathematical foundations of computer networking, Society, pp , [14] S. Heap and Y. Varoufakis, Game Theory: A Critical Introduction. Routledge, [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 [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 [17] A. Lindgren, A. Doria, and O. Schelén, Probabilistic routing in intermittently connected networks, SIGMOBILE Mob. Comput. Commun. Rev., vol. 7, no. 3, pp , Jul [18] A. Keränen, J. Ott, and T. Kärkkäinen, The ONE simulator for DTN protocol evaluation, Proceedings of the Second International ICST Conference on Simulation Tools and Techniques, ACKNOWLEDGMENT This work is partially funded by FEDER Funds through the Programa Operacional Fatores de Competitividade COM- PETE and by National Funds through the FCT - Fundação para a Ciência e a Tecnologia (Portuguese Foundation for Science and Technology) within project FCOMP FEDER REFERENCES [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, [2] V. Venkataraman, H. B. Acharya, H. Shah, and S. Lam, Delay tolerant networking - a tutorial, SciencesNew York, Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

106 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 Universidade do Minho Braga, Portugal * joao99antunes@gmail.com + costa@di.uminho.pt ^ macedo@di.uminho.pt 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 FEDER 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 contactos 1 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 A Internet do futuro 97

107 II. ESTADO DA ARTE 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. III. SISTEMA DE RECOLHA E ANÁLISE DE DADOS 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ó. 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 Wi- Fi. 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. 98 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

108 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 A Internet do futuro 99

109 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 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

110 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 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. 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 V. DISCUSSÃO E AVALIAÇÃO DO SISTEMA 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 A Internet do futuro 101

111 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 coeficiente social entre o nó A e o nó B [ ] ; e o 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: [ ] (2) Em relação ao coeficiente dos contatos físicos, este consiste, igualmente, em dois coeficientes: o coeficiente do número de contactos físicos [ ] ; e o coeficiente da duração desses mesmos contactos físicos [ ]. O 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 dar a cada coeficiente. [ ] é a constante de 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. 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 [ ] (3) { (4) 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 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] K. Fall, A delay-tolerant network architecture for challenged internets, Proc Conf. Appl. Technol. Archit. Protoc. Comput. Commun. - SIGCOMM 03, p. 27, [2] L. Fratta, M. Gerla, and L. Kleinrock, The flow deviation method: An approach to store and forward communication network design, Networks, [3] 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 , [4] A. Pietiläinen, E. Oliver, and J. LeBrun, MobiClique: middleware for mobile social networking, 2nd ACM Work. Online Soc. networks, pp , [5] 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., [6] A. Vahdat and D. Becker, Epidemic routing for partially connected ad hoc networks, [7] 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 [8] 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 , May [9] J. M. Pujol, A. Lopez Toledo, and P. Rodriguez, Fair Routing in Delay Tolerant Networks, IEEE INFOCOM th Conf. Comput. Commun., pp , Apr [10] P. Hui, J. Crowcroft, and E. Yoneki, BUBBLE Rap : Social-Based Forwarding in Delay-Tolerant Networks, no. November, pp , [11] A. Mtibaa and M. May, Peoplerank: Social opportunistic forwarding, INFOCOM 2010 Proc. IEEE, [12] K. Scott, S. Burleigh, and The MITRE Corporation, Bundle Protocol Specification, pp. 1 51, [13] R. Balani, Energy Consumption Analysis for Bluetooth, WiFi and Cellular Networks. [14] 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. [15] Redes Sociais. [Online]. Available: [Accessed: 13-Sep-2013]. 102 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

112 Encaminhamento Multi-Caminho Baseado num Número Reduzido de Árvores João Horta, Margarida Mamede e José Legatheaux Martins CITI e Departamento de Informática, Faculdade de Ciências e Tecnologia, Universidade Nova de Lisboa, Caparica, Portugal jp.horta@campus.fct.unl.pt, {mm, jose.legatheaux}@fct.unl.pt Resumo Quando se utiliza encaminhamento multi-caminho para engenharia de tráfego, o número total de caminhos necessários é potencialmente muito elevado, da ordem de O(kn 2 ), onde n é a cardinalidade do conjunto de nós de entrada / saída de tráfego (edge nodes) e k é o número de caminhos distintos, simultaneamente usados entre cada par desses nós. A dimensão das tabelas de encaminhamento dos nós é proporcional ao número total de caminhos necessários. Reduzir o seu número é um objectivo importante, que pode ser conseguido através da agregação dos caminhos em árvores. No entanto, determinar o número mínimo de árvores que cobrem um conjunto de caminhos é um problema NP-difícil. Este artigo começa com uma análise das diferentes alternativas que podem ser usadas para realizar encaminhamento multicaminho, usando equipmentos off-the-shelf, baseado na utilização de várias árvores. Em seguida, apresenta um novo algoritmo de agregação de caminhos num número reduzido de árvores, destinado a optimizar a concretização de encaminhamento multicaminho e utilizável em várias das alternativas anteriores. Nos testes experimentais efectuados, que envolvem redes sintéticas e reais, o algoritmo produziu melhores resultados que outros previamente publicados. I. INTRODUÇÃO Para o encaminhamento intra-domínio numa rede de computadores, uma solução comum consiste em utilizar um caminho único entre os nós origem e destino dos pacotes (e.g., RIP, OSPF, IS-IS,...). No entanto, quando critérios de optimização da capacidade disponível na rede assumem um papel preponderante [1], é frequente recorrer a técnicas de encaminhamento mais sofisticadas, recorrendo, por exemplo, a formas de distribuição do tráfego com utilização simultânea de mais do que um caminho entre cada par de nós origem / destino do tráfego (e.g., usando MPLS [2] e engenharia de tráfego [3] com encaminhamento multi-caminho). Entre os diversos caminhos usados entre cada par de nós devem estar presentes caminhos mais curtos, mas também caminhos que proporcionem equidade entre fluxos e capacidade de optimizar a distribuição do tráfego e a resistência a avarias [4], [5]. Num quadro de encaminhamento multi-caminho, a tendência mais recente consiste na computação e instalação destes caminhos a priori, por métodos off-line. Assim, se os nós de entrada do tráfego na rede tiverem a capacidade de realizar a distribuição da carga pelos diferentes caminhos disponíveis, a complexidade dos nós interiores poderá ser minimizada, visto que a sua configuração poderá ser estática (a menos da sua eventual participação na sinalização de avarias e contabilização de tráfego), na linha do defendido em [6]. A optimalidade da distribuição dinâmica de carga e da reacção a avarias continua a ser objecto de investigação recente [1], [4]. Mas o problema da simplicidade global dos nós da rede tem sido mais desprezado. No quadro descrito, o número total de caminhos parametrizados a priori nos nós da rede é muito elevado, da ordem de O(kn 2 ), onde n é o número de nós de entrada / saída de tráfego (edge nodes) e k é o número de caminhos distintos entre cada par desses nós. Reduzir o número de entradas da tabela de encaminhamento (i.e., da FIB - Forwarding Information Base) também é um objectivo importante. Uma forma de realizar esta optimização consiste na agregação dos diferentes caminhos em árvores. Se a redução assim conseguida for significativa, o número de entradas nas FIBs poderá ser muito reduzido. Infelizmente, determinar o número mínimo de árvores que cobrem um conjunto de caminhos é um problema NP-difícil [7], [8]. As principais contribuições deste artigo são, primeiro, uma análise das diferentes alternativas que podem ser usadas para concretizar encaminhamento multi-caminho com base na utilização de várias árvores e, depois, um novo algoritmo de agregação de caminhos num número reduzido de árvores, destinado a optimizar a concretização de encaminhamento multi-caminho e utilizável em várias das situações anteriores. Nos testes experimentais efectuados, o algoritmo produziu melhores resultados que outros previamente publicados. Na secção II é discutida a concretização do encaminhamento multi-caminho com base em várias árvores. Na secção III é apresentado trabalho prévio sobre o tema. A secção IV descreve e discute o algoritmo proposto. Em seguida, na secção V, é efectuada uma análise empírica do mesmo e realizada uma comparação com outros algoritmos. Finalmente, na secção VI, são apresentadas algumas conclusões e trabalho futuro. II. ENCAMINHAMENTO MULTI-CAMINHO COM BASE EM ÁRVORES Para esta discussão, uma rede é definida por um grafo G = (V,E) simples (um grafo sem lacetes nem arcos paralelos), não orientado (onde (v 1,v 2 ) e (v 2,v 1 ) denotam o mesmo arco) e conexo (existe caminho entre dois quaisquer nós). Seja N V o conjunto, de cardinalidade n, dos nós de entrada e saída da rede, ou seja, o conjunto dos nós que podem ser a origem ou o destino do tráfego. Para todos os pares de nós (x,y) N 2, com x < y (para uma qualquer relação de A Internet do futuro 103

113 ordem total em N), computaram-se previamente (até) k > 0 caminhos distintos com características adequadas ao suporte de encaminhamento multi-caminho [3], [5], [9], [10]. O número total desses caminhos é geralmente próximo de k n(n 1) 2, visto que em certas redes e contextos podem não existir k caminhos distintos para certos pares de nós. Como veremos nas secções seguintes, existem algoritmos que permitem agregar esses caminhos num certo número de árvores. Considera-se igualmente que existem mecanismos, necessários para engenharia de tráfego, que permitem a um nó x de entrada de tráfego obter as seguintes informações: M1) dado o endereço de destino de um fluxo, determinar o nó y de saída a que o destino está ligado; M2) dado um nó y de destino, conhecer os k caminhos para lhe chegar; e M3) dados os k caminhos que permitem a x alcançar y, qual destes deve ser escolhido para cada fluxo / pacote (segundo um critério de engenharia de tráfego ou outro). A solução completa destes 3 problemas está fora do âmbito deste trabalho, no entanto, nas subsecções que se seguem, faremos referência ao modo como estes podem ser abordados em diferentes alternativas de encaminhamento com base em árvores. A. MPLS com Utilização de LSPs Multipoint-to-Point Com MPLS cada caminho é concretizado na rede através de um LSP (Label Switch Path). Como o seu número é muito elevado, desenvolveram-se técnicas de agregação de LSPs com o objectivo de utilizar uma única entrada na FIB de um nó intermédio z, sempre que vários LSPs partilham o mesmo caminho de z até ao destino [7], [11], [12]. Estes LSPs especiais designam-se multipoint-to-point, ou m-t-p, e a sua determinação tem semelhanças com a agregação de caminhos em árvores. 1 A secção seguinte refere algoritmos propostos para esta agregação. A utilização de MPLS para engenharia de tráfego com parametrização estática dos LSPs é comum, pelo que existem os mecanismos M1), M2) e M3) acima referidos nos equipamentos com suporte de MPLS (ver, por exemplo, [3]). B. Utilização de VLANs Numa rede de switches Ethernet organizada em malha é 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, é possível parametrizar na rede até 4096 árvores distintas (o limite do número de VLANs imposto pela norma IEEE 802.1D) [10]. Com esta solução é possível realizar o encaminhamento multi-caminho com base num número reduzido de árvores. A escolha do caminho que um dado pacote deve seguir é equivalente à escolha da VLAN tag que o mesmo recebe à entrada da rede. O encaminhamento é depois realizado usando o tradicional algoritmo de inundação com aprendizagem pelo caminho inverso. 2 A proposta geral do método foi feita no quadro do encaminhamento em redes para centros de dados. 1 Um LSP m-t-p não é exactamente uma árvore (um subgrafo da rede G, acíclico e conexo), visto que é um grafo orientado ( dirigido para a raiz, que é o destino dos caminhos). Mas é acíclico e fracamente conexo. 2 Caso seja necessário preservar identificadores de VLANs com significado fora da rede, deverá ser utilizada alguma forma de encapsulamento suplementar (e.g., IEEE 802.1ad). Neste quadro a implementação dos mecanismos M1), M2) e M3) pode ser realizada nos drivers Ethernet dos servidores [10]. O método requer a utilização de inundação e de tabelas de endereços MAC cuja dimensão pode ser significativa. Outra proposta baseada na utilização de VLANs consiste em usar tantas árvores de cobertura, computadas pelo protocolo STP, quanto o número de switches de N (i.e., n árvores), cada uma com raiz em cada um desses switches [13]. Para realizar a distribuição de tráfego multi-caminho, os fluxos são distribuídos pelas diferentes n árvores numa forma roundrobin. No entanto, este método não permite controlar com rigor os caminhos usados por cada fluxo e a qualidade dos mesmos. C. Utilização de Longest-Prefix Matching Dada uma árvore, é possível realizar o encaminhamento ponto a ponto usando equipamentos com suporte de encaminhamento IP, endereços hierárquicos e Longest-Prefix Matching, portanto sem recurso a inundação. Para este efeito é necessário parametrizar os equipamentos com rotas estáticas, específicas para cada árvore, da seguinte forma. Dada uma árvore t, é-lhe associado um prefixo ou intervalo de endereços I, disjunto de todos os outros. Em seguida, I é particionado em vários subintervalos, cada um dos quais associado a um nó filho da raiz. Esta operação é realizada recursivamente até às folhas. Em seguida, em cada nó da árvore, I é associado à interface que dá acesso ao nó pai (excepto na raiz) e cada subintervalo afectado a um filho é associado à interface que lhe dá acesso. Finalmente, cada nó da rede recebe um endereço no seu intervalo (este endereço não é afectado a nenhum filho). É fácil verificar que o algoritmo de encaminhamento Longest-Prefix Matching encaminha pacotes destinados a um endereço contido em I, na árvore t, sem necessidade de realizar inundação. Este método apenas requer espaço nas FIBs para as rotas estáticas proporcional ao número de árvores em que cada nó participa. A escolha do caminho que um pacote deve seguir é equivalente à escolha do endereço do nó destino na árvore pela qual se pretende encaminhar o pacote. Esta transformação de endereços pode ser realizada por vários métodos, como por exemplo túneis IP sobre IP, ou recorrendo a LISP [14], que fornece igualmente interfaces para a utilização dos mecanismos M1), M2) e M3). Na literatura é possível encontrar diversas outras realizações de encaminhamento multi-caminho usando ECMP (Equal Cost Multi-Path Routing) em redes fisicamente configuradas com árvores, mas a comparação exaustiva das qualidades e defeitos de cada um desses métodos, assim como dos métodos indicados acima, ultrapassa o âmbito deste artigo. III. AGREGAÇÃO DE CAMINHOS EM ÁRVORES: PROBLEMA E SOLUÇÕES O problema da agregação de caminhos em árvores pode ser definido da seguinte forma. Dado um conjunto S de caminhos num grafo G = (V, E) simples, não orientado e conexo, pretende-se obter um conjunto T de árvores de G (ou seja, um conjunto de subgrafos de G acíclicos 3 e conexos), 3 Um grafo cíclico (respect. acíclico) é um grafo com (respect. sem) ciclos. Um ciclo é um caminho com pelo menos dois nós, tal que o primeiro e o último nós são iguais e cujos arcos são todos distintos. 104 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

114 com a menor cardinalidade possível, tal que todo o caminho de S seja um caminho em alguma árvore de T. Sem perda de generalidade, assume-se que qualquer caminho p S tem pelo menos dois nós e que todos os nós de p são distintos. No subproblema da agregação de caminhos com o mesmo destino, todos os caminhos de S têm o mesmo nó destino. Sabe-se que o problema de decisão da agregação de caminhos com o mesmo destino, onde se pergunta se é possível agregar os caminhos de S em m 1 árvores, é NP-completo [7], [8]. Consequentemente, os dois problemas de optimização referidos são NP-difíceis, não havendo actualmente algoritmos polinomiais para os resolver. Portanto, os algoritmos que existem não garantem que a cardinalidade do conjunto retornado é a menor possível, sendo essa cardinalidade a medida para avaliar a qualidade da solução computada. O caso particular da agregação de caminhos com o mesmo destino foi estudado no contexto de LSPs m-t-p. Em [11], o problema é reformulado em termos de programação linear inteira (do tipo 0-1). Em [7] é proposto um algoritmo greedy que, basicamente, agrega caminhos (e á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 número total de á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 vértice final dos caminhos, seriam gerados n 1 problemas de agregação com o mesmo destino e, para cada um deles, o conjunto de árvores retornado teria, no mínimo, k árvores, porque cada um dos k caminhos com a mesma origem (e destino) teria de ser coberto por uma árvore diferente. Portanto, obter-se-iam pelo menos (n 1)k árvores no total, não sendo esperadas repetições. Esta estratégia de resolução do problema será designada por estratégia LSPs m-t-p, na secção V. Para simplificar as próximas definições, considere-se que um caminho p = v 1 v 2 v m 1 v m (com m 2) induz o grafo não orientado G p = (V p,e p ), onde V p = {v 1,v 2,...,v m 1,v m } é o conjunto dos vértices e E p = {(v 1,v 2 ),...,(v m 1,v m )} é o conjunto dos arcos. Sejam G = (V,E ) um subgrafo acíclico de G e p S um caminho. Diz-se que G contém ou cobre p se E p E e que p pode ser agregado a G se (V V p,e E p ) for um grafo acíclico. A inserção ou agregação de p em G transforma G no grafo (V V p,e E p ). No âmbito do sistema SPAIN [8], [10], cujos objectivos são muito semelhantes aos nossos, Mudigonda et al. desenvolveram dois algoritmos aleatórios para agregar caminhos em subgrafos acíclicos (não necessariamente conexos). Devido à sua natureza, ambos os algoritmos devem ser executados várias vezes, sendo guardado e retornado um dos conjuntos calculados nas diferentes execuções com a menor cardinalidade. O primeiro algoritmo [8], [10] é muito simples. Inicialmente, o conjunto O de subgrafos é vazio. O conjunto S é percorrido, por uma ordem aleatória, e cada um dos seus caminhos p é tratado sequencialmente, começando-se por verificar se algum subgrafo de O o contém. Em caso afirmativo, passa-se ao caminho seguinte. Se nenhum subgrafo cobrir p, percorre-se novamente O, por uma ordem aleatória, até se encontrar um subgrafo G ao qual p possa ser agregado e efectua-se a inserção de p em G. Se p não puder ser agregado a nenhum subgrafo existente, cria-se o subgrafo G p (com os vértices e os arcos do caminho), que se acrescenta a O. O segundo algoritmo [8] é muito complexo para ser descrito em detalhe. Basicamente, S é inicialmente particionado pelo vé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 é obtido através de uma redução ao problema da coloração de vértices. Como a reunião de todos os conjuntos computados (que é uma solução do problema original) pode ser muito grande, depois executa-se uma função não determinista que efectua reuniões de subgrafos obtidos para destinos diferentes (quando o resultado é um grafo acíclico). A justificação apresentada pelos autores para desenvolver o segundo algoritmo é a diminuição dos tempos de execução, devido à paralelização da primeira fase. Mas os dois algoritmos não são comparados, nem quanto aos tempos de execução, nem quanto à qualidade das soluções produzidas (dada pela cardinalidade dos conjuntos retornados). Por estes motivos, só comparámos o nosso algoritmo com o primeiro, cuja implementação é significativamente mais simples. IV. ALGORITMO DE AGREGAÇÃO DE CAMINHOS EM ÁRVORES O novo algoritmo de agregação de caminhos em árvores é determinista. Partindo de um conjunto vazio de árvores, vão-se agregando caminhos às árvores existentes, criando uma nova árvore apenas quando a inserção dos caminhos em qualquer uma das árvores que já existem resultaria num grafo cíclico ou não conexo. A grande diferença em relação aos algoritmos semelhantes descritos na secção anterior é que se começa por inserir pares de caminhos compatíveis, por uma ordem e numa árvore específicas. Por abuso, chamamos par a um conjunto {p, q} com dois caminhos, denotando-o por (p, q), mas os caminhos são distintos e a ordem pela qual ocorrem é irrelevante. É importante recordar que S é o conjunto de entrada (i.e., um conjunto de caminhos num grafo G), que G p = (V p,e p ) denota o grafo induzido por um caminho p S e que uma árvore t de G é um subgrafo de G conexo e acíclico (definido por (V t,e t )). A noção de compatibilidade é fundamental e definese entre dois caminhos, entre um caminho e uma árvore e entre um par de caminhos e uma árvore. No primeiro caso, a compatibilidade será usada para definir a ordem pela qual os pares de caminhos são processados. Nos restantes, será usada para escolher a árvore onde um caminho ou um par de caminhos é inserido, quando há várias alternativas. A compatibilidade entre um par de caminhos (p,q) é 1 se o grafo (V p V q,e p E q ) for cíclico; e é V p V q, o número de nós em comum, no caso contrário. A compatibilidade entre um caminho p e uma árvore t define-se de forma semelhante: é 1 se o grafo (V t V p,e t E p ) for cíclico; e é V t V p, no caso contrário. A compatibilidade entre um par de caminhos (p, q) e uma árvore t é 1 se o grafo (V t V p V q,e t E p E q ) for cíclico; e é V t V p + V t V q, nos outros casos. Dois caminhos (respect., um caminho e uma árvore, ou um par de caminhos e uma árvore) dizem-se compatíveis se a compatibilidade entre eles denotada por compat(, ) for positiva. A Internet do futuro 105

115 Note-se que dois caminhos sem nós em comum (respect., um caminho sem nós em comum com uma árvore) não são compatíveis, porque a reunião dos respectivos grafos não é um grafo conexo. Mas um par de caminhos pode ser compatível com uma árvore, mesmo que um dos caminhos não partilhe qualquer nó com a árvore (desde que o outro partilhe). As seguintes propriedades, que permitem efectuar operações com entidades compatíveis, são fáceis de verificar. Se (p, q) for um par de caminhos compatíveis, a criação de um novo grafo com (p,q), definido por (V p V q,e p E q ), produz uma árvore. Se o caminho p e a árvore t forem compatíveis, a inserção de p em t, que transforma t no grafo (V t V p,e t E p ), produz uma árvore. Se (p,q) for um par de caminhos compatíveis, t for uma árvore, e (p,q) e t forem compatíveis, a inserção de (p,q) em t, que transforma t no grafo (V t V p V q,e t E p E q ), produz uma árvore. O algoritmo de agregação de caminhos é composto por três fases: (i) geração dos pares de caminhos compatíveis e dos caminhos singulares iniciais (os caminhos de S que são incompatíveis com todos os outros e que, consequentemente, não ocorrem em nenhum par de caminhos compatíveis); (ii) agregação de pares de caminhos compatíveis; e (iii) agregação de caminhos singulares. Na primeira fase, são analisados todos os pares de caminhos de S e avaliada a sua compatibilidade. Os pares compatíveis serão processados na segunda fase, por uma ordem que envolve três critérios: primeiro, por ordem decrescente de compatibilidade do par; depois, por ordem decrescente de potencial de agregação do par em S; e, em caso de empate na compatibilidade e no potencial de agregação, por ordem decrescente de comprimento do par (que é a soma dos comprimentos dos dois caminhos). O critério da compatibilidade tem como objetivo privilegiar os pares cuja agregação é a mais natural, ou seja, aqueles cujo resultado agregado é o menos diferente de cada um dos caminhos. A ordenação pelo potencial de agregação dá prioridade a pares de caminhos que têm um maior número de nós em comum com todos os outros. Formalmente, o potencial de agregação de um caminho p no conjunto S é a soma das compatibilidades de todos os pares de caminhos de S que envolvem p: potagreg(p, S) = q S\{p} compat(p, q). O potencial de agregação de um par de caminhos (p,q) em S é a soma do potencial de agregação de p e de q em S: potagreg((p, q), S) = potagreg(p, S) + potagreg(q, S). Por fim, com o terceiro critério, pretende-se tratar os caminhos de maior comprimento o mais cedo possível, enquanto existem mais possibilidades de agregação, deixando para o fim os que, em princípio, têm mais facilidade em se agregar. Na fase de agregação dos pares de caminhos compatíveis, processa-se um par de cada vez, pela ordem definida acima, até todos os pares terem sido tratados. Começa-se por verificar, para cada caminho do par, se alguma árvore existente o cobre, sendo necessário distinguir três casos. No primeiro, os dois caminhos estão contidos em árvores (possivelmente distintas) e o processamento do par termina. No segundo caso, nenhum dos caminhos está contido numa árvore. Se houver alguma árvore compatível com o par, insere-se o par de caminhos numa das árvores existentes; senão, é criada uma nova árvore com o par de caminhos. No terceiro caso, um dos caminhos está contido numa árvore t e o outro (que designaremos por p) não está contido em nenhuma árvore. Se p for compatível com t, o caminho é inserido nessa árvore; se p não for compatível com t mas houver alguma árvore compatível com p, agregase p a uma das árvores existentes; e se não existir nenhuma árvore compatível com p, o caminho é adicionado à estrutura dos caminhos singulares (adiando-se a sua agregação). Na fase de agregação dos caminhos singulares, os caminhos são seleccionados por ordem decrescente de comprimento. O processamento de cada caminho p também se inicia com a procura de uma árvore que o contenha, não havendo nada mais a fazer quando esta pesquisa tem sucesso. Se p não estiver contido em nenhuma árvore, verifica-se se p é compatível com alguma árvore e, em caso afirmativo, insere-se p numa árvore existente. Quando o caminho é incompatível com todas as árvores, a árvore G p é criada e adicionada ao conjunto resultado. A procura de uma árvore compatível com um dado caminho ou par de caminhos α devolve, em caso de sucesso, a árvore t onde a inserção de α será efectuada. Essa árvore é, de entre todas as árvores compatíveis com α, uma que maximiza o valor da compatibilidade. Ou seja, se T for o conjunto das árvores existentes, a árvore t T onde α é inserido verifica: compat(α,t) 1 e ( t T ) compat(α,t) compat(α,t ). A complexidade temporal do algoritmo é O( S 3 V ), onde V denota o conjunto dos nó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 não excede V 1. Consequentemente, o custo da primeira fase é O( S 2 ( V +log S )), uma vez que todos os pares de caminhos são analisados e os pares compatíveis são ordenados. Nas duas ú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 árvores, a complexidade total das duas últimas fases é O( S 2 T V ). A conclusão é obtida usando o facto de que T S. V. AVALIAÇÃ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 versão 1.7. Cada conjunto S de teste foi obtido com o algoritmo de selecção de caminhos para encaminhamento multi-caminho proposto em [5]. O algoritmo recebe a rede G (cujos arcos têm custos positivos), dois nós distintos x, y N, o número k > 0 de caminhos desejados de x para y e mais dois parâmetros, que limitam o comprimento e o custo dos caminhos pretendidos, e retorna um conjunto de caminhos de x para y. Para cada rede 106 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

116 (a) Full Mesh (b) Anel Figura 1: Representações das redes Full Mesh e Anel (a) Fat Tree (b) Folded Clos Figura 2: Representações das redes Fat Tree e Folded Clos testada, o algoritmo foi executado para todos os pares de nós (x,y) N 2, com x < y, tendo-se contruído S com a reunião dos n(n 1)/2 conjuntos retornados. Testaram-se dois tipos de redes: redes regulares, representativas de configurações com propriedades bem conhecidas, utilizadas frequentemente em redes para interligação de computadores em clusters e em centros de dados, e redes não regulares, que incluem backbones reais e uma rede aleatória. Os caminhos seleccionados nas redes regulares são fáceis de identificar e coincidem com os que serão classificados como interessantes. Nas redes não regulares, são caminhos que asseguram multiplicidade de encaminhamento, disjunçã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 nós são origem e destino de tráfego (ou seja, N = V ). Na full mesh cada nó está directamente ligado a todos os outros formando uma clique (como ilustrado na Figura 1a). Numa rede destas com n nó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 únicos considerados interessantes. Numa rede em anel, cada nó tem grau 2 e existem apenas 2 caminhos (disjuntos) entre cada par de nós (ver Figura 1b). Neste caso, S tem 2 caminhos por par. Usou-se uma full mesh com 6 nós e um anel com 10 nós. Uma rede fat tree é uma rede hierá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 nós folha (os que pertencem a N) existe capacidade garantida. Os caminhos interessantes entre cada par de nós folha são os caminhos de menor custo, cujo número é 2 2m 1, onde m é o número de níveis que é necessário subir para chegar ao nó de destino. Uma rede com topologia folded clos é definida por duas camadas distintas, formando um grafo bipartido tal que cada nó da primeira camada está ligado a todos os nós da segunda (ver Figura 2b). Os caminhos interessantes entre cada par de nós da primeira camada (que corresponde ao conjunto N) são todos simultaneamente de menor custo e disjuntos entre si e o seu número é igual ao número de nós da segunda camada, dado por n. Por estes motivos, S tem n 2 (n 1)/2 caminhos. Na rede usada no teste, n = 6. As redes folded clos também são utilizadas em centros de dados e têm a propriedade de assegurar a disjunção máxima de caminhos. B. Redes Não Regulares Foram usados três backbones reais e uma rede aleatória. Para os testes foram removidos das redes reais canais paralelos e nós que não acrescentavam diversidade. Nas redes reais o custo dos canais usado é proporcional à distância entre os nós e na rede aleatória o peso de todos os arcos é 1 (tal como nas redes regulares). A rede GÉANT é uma rede europeia de investigação e educação que interliga as diferentes redes de investigação e educação dos países europeus. A configuração testada tem 31 nós e 50 canais. A Internet 2 é um consórcio norte-americano que liga universidades, centros de investigação, corporações e outras redes regionais de educação e investigação nos EUA. A configuração testada tem 25 nós e 44 canais. A NTT Communications é uma corporação subsidiária da NTT (Nippon Telegraph and Telephone) e possui uma rede IP com uma distribuição geográfica mundial. A configuração testada tem 27 nós e 63 canais. A rede aleatória utilizada foi gerada com base numa distribuição de Poisson, com um grau médio dos nós de valor 3. A configuração testada tem 30 nós e 48 arcos. Nos quatro casos, todos os nós são origem e destino de tráfego. C. Resultados da Agregação em Á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 número n de nós de entrada e saída da rede ( N ); a terceira o número k de caminhos distintos pedidos ao algoritmo de selecção de caminhos para cada par de nós de N; e a quarta o número total de caminhos seleccionados (i.e., a cardinalidade do conjunto S). Para as redes regulares, calculámos o número de árvores óptimo (apresentado na quinta coluna da tabela I), através da análise da rede e dos caminhos seleccionados. Para as restantes redes, não conhecemos a cardinalidade da solução óptima. Os algoritmos de agregação de caminhos em árvores comparados são o novo e o (primeiro) algoritmo do sistema SPAIN [8], [10], cujos resultados se encontram na sexta e na sétima colunas da tabela I, respect.. O algoritmo SPAIN foi executado para cada rede múltiplas vezes. Mas, ao invés de definir o número de execuções, limitou-se o tempo utilizado por estas. Isto é, durante um certo intervalo de tempo, o algoritmo foi executado repetidamente, tendo sido escolhido o resultado de uma execução com o menor número de subgrafos. Nestes resultados, o intervalo de tempo utilizado corresponde a 5 vezes o tempo de execução do novo algoritmo para a mesma rede. Convém referir que o algoritmo foi implementado como foi descrito na secção III e pelos autores [8], [10]. Por isso, o resultado é um conjunto de grafos acíclicos, não necessariamente conexos (o que justifica o título das duas colunas de resultados na tabela). A oitava coluna apresenta A Internet do futuro 107

117 Tabela I: Resultados da execução dos algoritmos # óptimo # de subgrafos LSPs Redes n k S de árvores Novo SPAIN m-t-p Full Mesh Anel Fat Tree 8 2 ou Folded Clos GÉANT Internet NTT Aleatória Tabela II: Tempos de execução dos algoritmos Redes Tempo (SPAIN) # de execuções (SPAIN) Tempo (Novo) Full Mesh 965ms ms Anel 15ms 83 3ms Fat Tree 12sec 820ms sec 564ms Folded Clos 2sec 420ms ms GÉANT 25min 39sec min 7sec Internet2 34min 19sec min 51sec NTT 41min 32sec min 18sec Aleatória 22min 56sec min 35sec o menor número de árvores que poderia ser obtido com a estratégia LSPs m-t-p (c.f. secção III), assumindo que não haveria repetições, e que corresponde a (n 1)k. A tabela II apresenta os resultados da execução dos algoritmos para cada rede (tempo de execução e número de execuções no caso do SPAIN). Os resultados mostram que o novo algoritmo agrega os conjuntos de caminhos das redes regulares no número óptimo de árvores. Para as restantes redes, ao não se conhecer o valor óptimo, esta avaliação não pode ser realizada. No entanto, analisando os resultados de forma comparativa, repara-se que os do novo algoritmo são sempre os melhores e que o número de árvores é muito reduzido. O SPAIN só tem um desempenho igual para a rede em anel. Os valores da coluna LSPs m-t-p são substancialmente mais elevados do que os resultados obtidos por ambos os algoritmos, indiciando que aquela estratégia de resolução do problema geral não é a mais adequada. VI. CONCLUSÕES E TRABALHO FUTURO Quando se pretende realizar o encaminhamento numa rede usando engenharia de tráfego, a utilização de encaminhamento através de múltiplos caminhos tem-se imposto. Neste quadro, a procura de soluções simples, mas que não sacrifiquem a optimalidade, na linha das defendidas em [6], é fundamental. O trabalho aqui apresentado centra-se na problemática da redução do número de entradas nas FIBs dos equipamentos de encaminhamento, com recurso à agregação dos caminhos num número reduzido de árvores, para encaminhamento com equipamentos banalizados (off-the-shelf ) e sem necessidade de recorrer a novos protocolos. O recenseamento apresentado na secção II mostra que é possível encaminhar com base em árvores através de pelo menos três métodos distintos. Usando MPLS e LSPs m-t-p, usando diversas VLANs e usando Longest-Prefix Matching. Este último método é implementável em qualquer equipamento que suporte encaminhamento com base em tabelas de prefixos IP e que possa ser parametrizado com rotas estáticas. Tratase de uma solução mais simples e mais escalável do que as que recorrem a switches e VLANs, que encaminham através de árvores, com base em inundação optimizada por aprendizagem pelo caminho inverso. O mesmo também permite a utilização de FIBs muito mais compactas do que as necessárias quando se usa MPLS e m-t-p LSPs. Tanto quanto é do nosso conhecimento, a sua proposta não foi ainda previamente sistematizada na literatura existente. Em seguida introduzimos um algoritmo de agregação de caminhos ponto a ponto num número reduzido de árvores. Nos testes realizados, o algoritmo apresenta melhores resultados que outros recenseados na literatura. Como trabalho futuro, pretendemos tentar deduzir qual a distância máxima da solução computada à solução óptima. Este trabalho insere-se num trabalho mais geral que visa desenvolver algoritmos e mecanismos de engenharia de tráfego que permitam optimizar o funcionamento da rede num quadro de carga variável e desconhecida a priori, incluindo a resposta atempada às falhas dos canais e dos nós. REFERÊNCIAS [1] 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 , [2] E. Rosen, A. Viswanathan, and R. Callon, Multiprotocol label switching architecture, IETF, RFC 3031, [3] O. M. Heckmann, The Competitive Internet Service Provider, 1st ed., ser. Wiley Series in Communications Networking & Distributed Systems. Chichester, UK: Wiley-Interscience, April [4] 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, [5] J. Horta, M. Mamede, and J. L. Martins, Selecção de caminhos para encaminhamento multi-caminho, in Actas do Inforum Simpósio de Informática, September 2013, pp [6] 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 , Apr [7] 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 , [8] 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 , HP Labs, Tech. Rep., [9] 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 [10] 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 [11] H. Saito, Y. Miyao, and M. Yoshida, Traffic engineering using multiple multipoint-to-point lsps, in INFOCOM Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, vol. 2, 2000, pp vol.2. [12] 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 , july [13] R. van Haalen, R. Malhotra, and A. de Heer, Optimized routing for providing ethernet lan services, Communications Magazine, IEEE, vol. 43, no. 11, pp , nov [14] D. Meyer, The locator identifier separation protocol (LISP), The Internet Protocol Journal, vol. 11, no. 1, March Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

118 Encaminhamento IP Optimizado Através de uma Aproximação de Software Defined Networking Alexandre Pinote e José Legatheaux Martins CITI e Departamento de Informática, Faculdade de Ciências e Tecnologia, Universidade Nova de Lisboa, Caparica, Portugal a.pinote@campus.fct.unl.pt, jose.legatheaux@fct.unl.pt Resumo Este artigo apresenta uma implementação optimizada de encaminhamento IP Unicasting e Multicasting para uma rede de switches. A optimização está implementada segundo a aproximação Software Defined Networking (SDN), com base na norma OpenFlow e no controlador FloodLight. Através da introdução de novos mecanismos de optimização da implementação de ARP, IGMP e da gestão do encaminhamento IP Multicasting, o trabalho demonstra que as promessas de flexibilidade e simplicidade da aproximação SDN são reais. O encaminhamento IP Multicasting é realizado com base em árvores de caminhos mais curtos, equivalentes às utilizadas por IP PIM- DM, mas implementadas de forma muito mais simples e leve. I. INTRODUÇÃO A rede Ethernet foi inicialmente definida com base num meio de difusão partilhado de tal forma que os custos da comunicação ponto a ponto (unicasting ) ou ponto multi-ponto (difusão: broadcasting e multicasting ) eram idênticos. Como as subnets IP têm necessidade de mecanismos de descoberta e directórios (para afectação de endereços IP e mapeamento de endereços IP em endereços MAC), o baixo custo do difusão na Ethernet tornou muito atractiva a sua utilização, em conjunto com soft state, como alternativa de implementação desses mecanismos. A disponibilidade de switches Ethernet de baixo custo permitiria hoje em dia construir subnets IP de grande dimensão (e.g., cobrindo todo um campus universitário ou uma grande empresa), que dispensariam a complexidade da utilização de encaminhamento IP entre várias subnets distintas. No entanto, na prática, tal aproximação não é muito utilizada. Por um lado, critérios de segurança recomendam a partição da rede em várias VLANs distintas (virtual local area networks). Por outro lado, a utilização indiscriminada de difusão na rede de switches (e.g., ARP, DHCP, IGMP, inundação para aprendizagem do encaminhamento unicasting e inundação para encaminhamento IP Multicasting) limitaria de forma significava o seu desempenho. Na prática as redes institucionais de switches são particionadas em diversas VLANs. Cada VLAN é uma subnet distinta, com um prefixo IP específico, e o encaminhamento é nelas realizado com base em, por um lado, encaminhamento sub-óptimo através de á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 prática tal rede é do ponto de vista de gestão mais complexa do que uma única subnet IP e encaminha de forma sub-óptima (pelo menos dentro de cada sub-net). Nos últimos anos apareceram diversas propostas de optimização do encaminhamento pelos switches, que introduzem simultaneamente servidores de directório em redes de switches Ethernet empresariais ou de centros de dados (e.g., [2], [3], [4], [5]). Simultanemente, apareceu também uma proposta para tornar mais flexível o controlo e evolução deste tipo de redes através de uma aproximação que se veio a designar Software Defined Networking (SDN) [6], [7]. A. Software Defined Networking e OpenFlow Nas redes convencionais os equipamentos de rede desempenham simultaneamente duas funções distintas, geralmente designadas por data plane e control plane. As funções do data plane consistem em analisar os cabeçalhos dos pacotes recebidos e, em função de tabelas de comutação ou de encaminhamento, enviarem-nas para o seu destino final via a interface seleccionada. O control plane implementa todos os protocolos de coordenação com os outros equipamentos de rede necessários para a parametrização e controlo do funcionamento do data plane. Numa rede de switches Ethernet o control plane executa pelo menos o algoritmo de aprendizagem de endereços MAC, assim como o protocolo STP. Nos switches que também implementam nível 3, o control plane é igualmente responsável pela implementação dos protocolos de encaminhamento IP. A aproximação SDN consiste em separar o data plane do control plane e implementá-los em equipamentos distintos, ver a figura 1. Assim, os switches apenas realizam as funções do data plane, enquanto que servidores, designados por controladores de rede, realizam as funcionalidades do control plane através de uma aproximação logicamente centralizada. Finalmente, os switches e os controladores comunicam através de um protocolo de controlo, cujo exemplo mais conhecido e normalizado é o protocolo OpenFlow [6]. O protocolo OpenFlow permite a um controlador programar um switch através de regras de encaminhamento. No essencial, cada regra é constituída por um descritor de um conjunto de pacotes (i.e., um descritor de um flow) e por uma ou mais acções a aplicar ao conjunto desses pacotes (i.e., ao flow). Um descritor OpenFlow é da mesma natureza que as ACLs usadas em diversos equipamentos de rede e permite especificar um flow com uma grande flexibilidade, usando exact matching A Internet do futuro 109

119 Figura 1: Separação do data plane e do control plane numa rede e wild card matching. As acções determinam o que fazer com os pacotes que pertencem ao flow sendo as mais comuns: drop e forward. No último caso, a acção pode especificar o envio da mensagem por uma interface determinada, a difusão (flood) da mesma, o seu envio para o controlador, etc.. Em versões mais recentes do protocolo o conjunto de acções compreende igualmente acções mais complexas como empilhar identificadores (e.g., ATM), ou transformar o cabeçalho IP. Através do protocolo OpenFlow é possível implementar uma nova arquitectura de controlo de uma rede, com diversas vantagens potenciais quando comparada com a aproximaçã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 comunicação normalizadas. Os controladores são servidores banalizados cuja especificidade está associada ao software que executam. Ambos os factores poderão conduzir a uma descida significativa de custos. Mas a vantagem mais importante advêm do facto de que um controlador pode controlar simultaneamente dezenas ou mesmo centenas de switches, o que permite desenvolver no mesmo uma visão logicamente centralizada da rede. Tal visão permite usar algoritmos mais simples que os algoritmos distribuídos de coordenação e controlo subjacentes aos protocolos de rede usados actualmente. Espera-se que desta forma seja mais fácil introduzir novas e mais sofisticadas formas de controlo, ou seja, flexibilizar e banalizar a evolução e a adaptabilidade do control plane. Actualmente já existem diversos switches que suportam OpenFlow e vários controladores OpenFlow. Os controladores fornecem uma espécie de sistema de operação de rede que suporta uma visão lógica da mesma, a interface com os switches por OpenFlow e um ambiente de desenvolvimento do tipo event driven para introdução de novas funcionalidades. Alguns dos controladores mais citados são: NOX [8], POX [9], Beacon [10] e o FloodLight [11]. B. Contribuições deste Trabalho A maioria dos controladores acima citados já oferecem módulos que permitem, através de OpenFlow, construir uma rede simples de nível L2 convencional. Geralmente fornecem igualmente módulos de realização de controlo de acessos (firewalling) e de encaminhamento unicasting usando o caminho mais curto numa configuração arbitrária de switches (i.e., em malha e com ciclos). No entanto, tanto quanto conseguimos apurar, não existem no domínio público implementações de IGMP nem de encaminhamento IP Multicasting optimizado através de árvores de difusão (como as computadas por PIM por exemplo). Um único artigo faz referência a uma implementação sem apresentar informação concreta sobre a solução [12]. Este artigo apresenta um trabalho que consistiu em introduzir no controlador FloodLight um conjunto de modificações com o objectivo de optimizar o funcionamento de uma rede de switches Ethernet, de tal forma que seja mais realista trabalhar com uma única subnet IP, mesmo numa rede de grande dimensão 1. Estas modificações têm como principal contribuição novas implementações dos protocolos ARP e IGMP e do encaminhamento do IP Multicasting. As modificações e optimizações introduzidas reduzem a utilização de difusão pelo protocolo ARP, encaminham o tráfego unicasting usando o caminho mais curto na rede (funcionalidade já implementada no FloodLight) e implementam o tráfego multicasting usando uma árvore de difusão óptima por grupo IP e por emissor. Para a implementação desta última funcionalidade foi também necessário introduzir uma implementaçã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 configuração da rede física é arbitrária, podendo incluir canais redundantes e ciclos. Na próxima secção apresenta-se brevemente o controlador FloodLight e os módulos relevantes para este trabalho que este implementa. Na secção III apresenta-se o módulo de descoberta introduzido (que implementa os protocolos ARP e IGMP) e as modificações no encaminhamento introduzidas para suportar encaminhamento IP Multicasting. Na secção seguinte é apresentada a avaliação do trabalho realizado. Finalmente, na secção V, são apresentadas algumas conclusões e discutido o trabalho futuro. II. CONTROLO DE REDES IP COM O CONTROLADOR FLOODLIGHT Para a realizaçã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 ambição controlar redes em produção. Quando comparado com outros controladores é, no entanto, geralmente considerado como mais difícil de modificar devido à sua maior complexidade. O Floodlight fornece um framework de base constituído por uma estrutura de execução baseada em módulos normalizados, dinamicamente instanciáveis, e orientada a eventos com base no paradigma editores/subscritores, uma thread pool, mecanismos normalizados de gestão de tabelas partilhadas pelos 1 Os requisitos de segurança ultrapassam o âmbito deste trabalho mas poderiam ser implementados com base no módulo de firewalling já disponibilizado pelo Floodlight. 110 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

120 diferentes módulos, uma interface de diálogo com os switches por OpenFlow etc. Entre os módulos mais relevantes do FloodLight encontram-se alguns dos que a seguir são indicados. O módulo LinkDiscoveryManager realiza a gestão dos canais existentes na rede através do protocolo LLDP (Link Layer Discovery Protocol). O módulo envia para os switches as mensagens LLDP a serem flooded, processa a sua recepção pelos switches adjacentes e mantém uma visão centralizada dos canais existentes na rede. O módulo TopologyManager gere a configuração da rede e fornece serviços para cálculo de caminhos mais curtos e árvores de cobertura de caminhos mais curtos com raiz num nó dado. O módulo DeviceManager faz snooping dos pacotes recebidos pelo controlador e gere uma tabela de dispositivos ligados à rede mantendo sobre cada um diversos atributos (switch e porta a que está ligado, endereços MAC e IP,... ). O módulo Forwarding é responsável pela introdução de flows (i.e., das respectivas regras nos switches) correspondentes ao tráfego unicasting entre quaisquer dois devices. O FlowReconcileManager é responsável pela reconfiguração dos flows unicasting na sequência de uma alteração da configuração dos canais. Com base nestes módulos, o FloodLight gere completamente uma rede L2 da forma a seguir apresentada. Todo o tráfego multicasting ou broadcasting de nível 2 é encaminhado directamente pelo controlador pois os switches não têm regras para o seu processamento de outra forma. Assim, todos os frames com endereços MAC deste tipo são enviados para o controlador e este é que decide, caso a caso, se o frame deve ser ignorado ou flooded em função da porta e switch onde foi recebido. Assim, por defeito, o FloodLight usa inundações da rede para processar ARP requests, DHCP, IGMP, IP Multicasting e outro tráfego em broadcasting ao nível L2. Para evitar broadcast storms, é usado um algoritmo de inundação sobre uma árvore de cobertura de caminhos mais curtos com raiz no switch de menor identificador (computada de forma centralizada mas equivalente à definida pelo protocolo STP). Em contrapartida, o controlador usa o tráfego que passa na rede para preencher a sua tabela de devices (c.f. módulo DeviceManager) pelo que sempre que recebe um primeiro frame de um flow unicasting, instala regras nos switches de tal forma que todo o tráfego desse flow (caracterizado pelos endereços MAC e IP origem e destino) passa a ser encaminhado pelo caminho mais curto. O controlador deixará assim de receber estes pacotes enquanto o flow estiver activo. III. SOLUÇÃO IMPLEMENTADA De modo a criar uma solução para o encaminhamento IP optimizado no FloodLight, foi necessário criar um módulo que se designou IPDiscoveryManager e modificar o módulo Forwarding. Os objectivos do primeiro módulo são gerir uma cache partilhada de ARP e responder a ARP Requets, assim como gerir um directório de grupos IP Multicast, através de uma solução baseada em IGMP. Adicionalmente, foi necessário alterar o módulo Forwarding, de forma a optimizar o encaminhamento do IP Multicasting. A. Optimização do protocolo ARP O módulo DeviceManager, por defeito, regista os endereços MAC dos computadores e utiliza o tráfego ARP e DHCP para registar também os seus endereços IP. Esta implementação foi alterada para que todos os pacotes IP que chegam ao controlador fossem usados para actualizar também os endereços IP do emissor. O módulo IPDiscoveryManager usa as informações recolhidas pelo DeviceManager como uma cache partilhada de ARP. Com efeito, essa cache permite obter por soft state a associação entre endereços IP Unicast e os endereços MAC. Assim, o módulo IPDiscoveryManager intercepta os pedidos ARP (ARP Request) e, caso a informação solicitada se encontre na cache há 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 contrário deixa o broadcasting prosseguir. Com esta implementação o controlador terá de: 1) interceptar os pacotes ARP Request, verificando nas suas estruturas de dados se o computador de destino enviou pacotes que lhe chegaram há menos de TRUST INTERVAL segundos; 2) responder aos pacotes ARP Request caso a condição anterior seja satisfeita. Para se compreender melhor o papel desta cache é necessário ter em atenção que o controlador receberá os pacotes emitidos por um computador IP sempre que estes não são encaminhados directamente pelos switches. Isso passa-se com todos os ARP Requests visto que os mesmos são emitidos em difusã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 são distintos de outros anteriores. Sempre que um novo fluxo é iniciado, o controlador instala o seu caminho nos switches através de comandos OpenFlow. Esses comandos são válidos enquanto o fluxo tiver actividade, e durante esse tempo os pacotes do fluxo nã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, permitirá ao controlador enriquecer a sua cache com nova informação. Em alguns sistemas de operação (e.g., Mac OS X), sempre que uma interface é activada, ou uma associação a um novo AP WIFI tem lugar, o driver Ethernet emite um gratious ARP 2. Se esta implementação fosse normalizada, a cache do controlador representaria quase sempre a realidade, e poder-seia praticamente suprimir todos as difusões relacionadas com o protocolo ARP. De qualquer forma, como veremos a seguir, a cache do controlador tem uma eficácia significativa na prática. B. Gestão do protocolo IGMP - Recenseamento dos grupos IP Multicast e da sua filiação Para gerir os grupos multicast e os computadores subscritores dos mesmos, é utilizado o protocolo IGMP de acordo com a sua norma (a implementação realizada baseia-se na versão 2), assumindo o controlador o papel de um router multicast. Através do envio periódico de IGMP Queries e da análise dos IGMP Reports, o módulo IPDiscoveryManager recenseia os grupos IP Multicast existentes e os seus subscritores. Adicionamente, esse recenseamento també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 é, não 2 i.e., um ARP Request do seu próprio endereço IP. A Internet do futuro 111

121 responde mais às IGMP Queries, o controlador considera que o mesmo deixou de subscrever o grupo. O controlador terá 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 informação sobre subscrições de grupos desactualizadas. Para clarificar a gestão do IGMP feita pelo módulo, apresenta-se o pseudo-código correspondente, que ilustra igualmente o estilo de programação usada no controlador. Um thread (não apresentado) assegura a funcionalidade 4) do mó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 } 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 } //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 implementação do IP Multicasting usada pelo Floodlight, é necessário evitar tráfego inútil e fazer chegar cada mensagem difundida a cada subscritor pelo caminho mais curto. Dispondo de informaçã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 através de uma árvore de caminhos mais curtos com raiz em E e cobrindo apenas os subscritores de G. O Floodlight já dispõe de uma forma de calcular uma árvore de cobertura da rede com raiz num dado nó, usada para o tráfego unicast. A implementação usa o algoritmo de Dijkstra. Para adaptar estas árvores ao novo objectivo, foi necessário podá-las para evitar mensagens inúteis, através de um algoritmo, que introduzimos no FloodLight sob o nome computefloodswitches, que computa uma árvore que cobre todos os switches com membros de um grupo IGMP com raiz no emissor. O algoritmo calcula um conjunto de switches inicializado com a raíz e todos os switches com subscritores do grupo. Em seguida acrescenta a esse conjunto todos os switches extra que são necessários para chegar de cada switch no conjunto inicial até à raiz. O passo seguinte consiste na instalação de flows nos switches da árvore podada, configurando os mesmos para fazerem inundação dos pacotes. Nos restantes instalam-se flows para fazer drop dos mesmos pacotes. Na versão 1.0 do protocolo OpenFlow só é possível associar uma acção de forwarding a cada flow. A versão 1.3 já suporta associar várias acções, o que permitiria enviar os pacotes apenas para os canais que pertencem à árvore. Infelizmente, como a nova versão ainda não está generalizada, e não é suportada pela versão do software e do simulador que utilizámos, foi usada a implementação com base em difusão para todas as portas. Assim, quando o módulo Forwarding do Floodlight recebe um pacote, e este é um pacote IP Multicast, realiza as computações necessárias (lista de switches da árvore podada) e por fim instala os flows nos switches. A implementação é descrita a seguir em pseudo código, uma vez mais para ilustrar o estilo de programação do controlador. received(packetin pi, Switch sw){ if(pi is an IP multicast packet) domulticast(pi, sw) else // process other packet types } 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 } } 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 código apresentado corresponde a uma simplificação significativa da implementação visto que o mesmo não ilustra o tratamento da modificação de grupos. Como os timeouts dos flows usados são idle timeouts (i.e., os flows só expiram na ausência de tráfego), se um emissor estiver sempre a enviar tráfego, só o grupo inicial o irá receber e mais nenhum membro que entre posteriormente. Por outro lado, se um membro sair do grupo, poderá passar a existir tráfego inútil. 112 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

122 A solução é tratar as alterações de filiação. Na implementação, o módulo Forwarding também processa os pacotes IGMP enviados pelos devices para detectar eventuais alterações de grupos com flows já instalados nos switches. Caso as alterações conduzam a uma modificação da árvore de difusão do grupo, o módulo procede as alterações necessárias dos flows. O mesmo sucede quando há subscrições que expiram. IV. AVALIAÇÃO De modo a avaliar esta proposta, utilizou-se o simulador Mininet [13]. O Mininet é um simulador especial, disponibilizado em Linux, que permite simular uma rede de dimensão significativa num ú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 máquina virtual própria, ligada por IP ao sistema hospedeiro. Neste corria directamente o servidor Floodlight e nele foi realizado o desenvolvimento do código Java do mesmo. Na verdade, o controlador e a rede simulada até podiam correr em computadores distintos. O Mininet simula os switches através do módulo OpenVSwitch, o qual implementa um verdadeiro switch Open- Flow. O simulador constrói uma rede de switches interligando directamente verdadeiras interfaces virtuais do kernel Linux. Assim, toda a comunicação entre os switches é directamente assegurada pelo kernel. Finalmente, os computadores ligados à 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 à rede. Cada um desses hosts pode executar directamente comandos e programas convencionais (e.g., ifconfig, tcpdump, sock, bash,... ) através de uma consola de comando programável que permite controlar a rede e executar comandos nos computadores à mesma ligados. Desta forma, é possível instanciar uma rede e um conjunto de computadores ligados à mesma, lançar programas de geração de tráfego, lançar monitores de trá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 execução de programas nos computadores ligados à 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 opçõ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 através de tcpdump. Num teste final, mais completo, foi usada uma configuração de 7 switches e 8 computadores Os últimos entravam e saiam aleatoriamente de diversos grupos IP Multicast e, também aleatoriamente, iniciavam a transmissão de fluxos de pacotes para os diferentes grupos. Este teste, mais abrangente, Hora TI = 0 TI = 60 TI = 1200 Ganho TI = 60 Ganho TI = ,66% 88,01% ,23% 90,35% ,33% 74,73& ,61% 84,24% ,39% 93,74% ,71& 92,32% ,44% 97,81% Total ,89% 87,46% Tabela I: Número de ARP Requests por hora (variando TI) e % de redução dos mesmos pela cache do controlador permitiu, através de análise detalhada dos traces, verificar a implementação realizada. Apesar de não ter sido desenvolvida uma avaliação rigorosa do desempenho em produção, o trabalho desenvolvido e os testes realizados permitiram verificar as hipóteses iniciais, isto é, uma vez vencida a barreira de penetrar na arquitectura do controlador, do seu ambiente de programação e testes, e dos detalhes de implementação do OpenFlow e da aproximação SDN, os algoritmos de controlo da rede são certamente mais simples do que a sua versão completamente distribuída. Para avaliar a optimização das difusõ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 avaliação foi saber qual a redução de difusões que a mesma permitiria, usando vários valores para o parâmetro TRUST INTERVAL (TI). Na tabela I apresenta-se o número de ARP Requests existentes na rede e o número de ARP Requests que existiriam na mesma se se utilizasse o controlador com a optimização desenvolvida. A tabela tem uma linha por cada hora de tráfego recolhido e apresenta três hipóteses. No primeiro caso é apresentado o número de ARP Requests total capturados durante essa hora. No segundo caso é apresentado o número de ARP Requests que existiriam na mesma rede durante essa hora com TI = 60 segundos, e no terceiro caso com TI = Como se pode observar existe redução significativa das difusões de ARP Requests. V. CONCLUSÕES E TRABALHO FUTURO O trabalho realizado permite tirar várias conclusões. As primeiras estão relacionadas com a extensibilidade e flexibilidade da aproximação SDN. Com efeito, foi possível de forma relativamente simples e com base em algoritmos centralizados substituir integralmente a utilização de difusão por defeito pelo uso de encaminhamento pelos caminhos mais curtos, quer para o tráfego ponto a ponto (funcionalidade já disponibilizada pelo Floodlight), mas também para o tráfego IP Multicasting. Neste último caso o encaminhamento passou a ser realizado com á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 gestão dos mapeamentos de endereços IP / MAC e da filiação de grupos (protocolos A Internet do futuro 113

123 ARP e IGMP) através da utilização de uma gestão centralizada de directórios. A actualização dos directórios é 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 também são usados para actualizar o mapa de endereços IP / MAC. O encaminhamento implementado constituí uma ilustração particularmente feliz das vantagens potenciais do paradigma SDN na medida em que se encaminha com qualidade equivalente à da utilização simultânea de OSPF para todo o tráfego IP Unicasting, e IGMP e PIM-DM (PIM Dense Mode) para o tráfego IP Multicasting, mas com uma implementação baseada em algoritmos centralizados e sem todo o overhead de controlo do PIM-DM. Com efeito, o PIM-DM usa inundações periódicas particularmente ineficazes com uma distribuição pouco densa de subscritores. Adicionalmente, os gestores da rede não necessitam de introduzir endereçamento IP para várias subnets distintas. A complexidade do novo control plane é relativamente baixa, ao mesmo tempo que os switches apenas necessitam de manter tabelas de flows grosso modo equivalentes às tabelas de endereços MAC convencionais e deixaram de executar protocolos e algoritmos distribuídos. É no entanto necessário ter presente que estas vantagens são apenas potenciais devido a diversos desafios levantados pelas SDN. Em primeiro lugar os problemas de escalabilidade [14] quando a rede atinge dimensões muito significativas. Em segundo lugar os problemas relacionados com a resistência a avarias, desde logo as do controlador, mas também a forma como este lida com as avarias da rede, sobretudo as que conduzirem a partições da mesma. Intimamente relacionado com este problema está o problema do bootstrap (como é que os switches encontram o controlador e comunicam com este e sobretudo como é que o controlador e os switches se coordenam perante avarias). Por último lugar, os problemas de segurança, em particular os relacionados com ataques de negação de serviço ao controlador. Finalmente, é necessário ter presente que a aproximação SDN introduz um novo ponto a necessitar de normalização e coordenação para evitar a dependência de soluções proprietárias. Tal dependência irá deslocar-se para o software dos controladores, o qual é ainda objecto de desenvolvimento e investigação. Na implementaçã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 é 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 situação não introduz necessariamente incorrecções, mas pode introduzir processamento extra e inútil no controlador e atrasos no encaminhamento. Este problema é delicado e necessita de um tratamento mais aprofundado. Uma possível forma de o minorar, corresponde a impor uma ordem estrita de instalação dos flows pelos diferentes switches, começando sempre a instalá-los nos switches mais próximos da raiz. Se existirem problemas com os switches ou com os canais da rede, o Floodlight dispõe de mecanismos que os detectam e disparam as correspondentes notificações. Na implementação do IP Multicasting será necessário acrescentar o tratamento dessas notificações (por agora ignoradas) e reconfigurar todas as árvores afectadas. Tal como para a detecção de falhas, o Floodlight tem mecanismos para identificar se um computador se moveu na rede. O processamento desses eventos passaria por duas situações: 1) a de um computador subscritor de um grupo se mover e 2) a de um computador emissor se mover. Para a primeira, é necessário, analogamente ao que acontece na mudança da filiação de um grupo, calcular a diferença entre a árvore antiga e a nova e proceder de forma idêntica. Na segunda situação, o tratamento mais simples consistiria em desinstalar a antiga árvore e instalar a nova. O trabalho futuro passa igualmente pelo teste em produção numa rede real. AGRADECIMENTOS São devidos a Samuel Neves e Luís Anjos pelo apoio na recolha dos dados sobre o tráfego que permitiram avaliar o ganho potencial da utilização da cache ARP. REFERÊNCIAS [1] 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 , Sep [2] R. J. Perlman, Rbridges: Transparent routing, in INFOCOM, [3] 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 [4] 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, [5] 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, [6] 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 , Mar [7] T. A. Limoncelli, Openflow: A radical new idea in networking, Queue, vol. 10, no. 6, pp. 40:40 40:46, Jun [8] 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 , Jul [9] Pox project, [Acedido em outubro de 2013]. [10] D. Erickson, Baecon a java-based openflow controller, openflow.stanford.edu/display/beacon/home, [Acedido em outubro de 2013]. [11] Floodlight project, [Acedido em outubro de 2013]. [12] 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. [13] B. Lantz, B. Heller, and N. McKeown, A network in a laptop: rapid prototyping for software-defined networks, in Proceedings of Hotnets- IX, ser. Hotnets-IX. New York, NY, USA: ACM, 2010, pp. 19:1 19:6. [14] S. H. Yeganeh, A. Tootoonchian, and Y. Ganjali, On scalability of software-defined networking, Communications Magazine, IEEE, vol. 51, no. 2, pp , Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

124 Automatização de Testes SIP David Gonçalves, Pedro Sousa, António Amaral and António Costa Centro Algoritmi, Universidade do Minho, PT Inovação, Abstract As redes IP são actualmente as principais infraestruturas de comunicação utilizadas por um conjunto crescente de aplicações e serviços heterogéneos, nos quais se incluem os serviços de voz. Neste sentido, as funções de transmissão e gestão de sessões sã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 gestão de sessões, desempenhando funções vitais num conjunto extenso de soluções. Contudo, a disseminação do protocolo acarreta alguns desafios, tais como a validação e teste de soluções SIP. Estes processos de validação necessitam de considerar diversos fatores, como seja o caso da análise de cabeçalhos, validação de valores dinâmicos, verificação de fluxos de mensagens, entre outros. Nesta perspetiva, a validação manual de soluções SIP apresenta-se como um processo moroso e dispendioso, sendo crucial o desenvolvimento de processos automatizados nesta área. Neste contexto, este resumo alargado aborda e analisa de forma integrada a temática geral da validação de soluções SIP, apresentando também ferramentas e aplicações capazes de auxiliarem os processos de automatização de testes de soluções SIP. I. INTRODUÇÃO A proliferaçã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 serviço, tendo pois consequências no que respeita às receitas obtidas pelas redes de telecomunicações [1]. As soluções de comunicação por voz em redes IP denominam-se usualmente por soluções Voice over IP (VoIP), caracterizando-se como soluções capazes de converter sinais analógicos de voz em sinais digitais passíveis de serem transmitidos sobre uma rede comutada de pacotes. No que diz respeito às vantagens do VoIP, estas apresentam-se distintas para utilizadores finais, empresas e operadores tendo contudo, um principio base comum, diminuição de custos comparativamente com serviços das redes telefónicas. Em termos protocolares, as soluções VoIP necessitam de possuir por base mecanismos de sinalização e transmissão dos media, capazes de permitir o estabelecimento de uma sessão e a correspondente troca de dados sobre a mesma. Em relação aos protocolos usados para a transmissã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 é 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 FEDER Agradeço à PT Inovação, a possibilidade para a realização do trabalho descrito neste artigo. No que respeita à sinalização, o protocolo Session Initiation Protocol (SIP) [3] apresenta-se como um protocolo preponderante no estabelecimento de sessõ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 sessão. No que respeita às mensagens trocadas, o SIP apresenta as mensagens em formato texto, sendo de simples interpretação para o utilizador, mas de difícil interpretação integral para os sistemas computacionais. Embora o formato das mensagens SIP favoreça a validação manual, a diversidade destas torna o processo de validação manual moroso e propenso a erros, verificando-se a necessidade de automatizar o processo de validação. Contudo, a implementação e validação de soluções com elevada diversidade, tal como acontece com o protocolo SIP, torna a tarefa de automatização árdua e de difícil implementação. Ao longo do resumo são discutidas as dificuldades associadas aos processos de validação de soluções SIP bem como estratégias gerais de um possível processo de automatização. II. MOTIVAÇÃ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 execução destes na sua totalidade apresenta-se como uma tarefa morosa e de difícil alcance. No que respeita à realização de validações de soluções SIP, estas necessitam de ser validadas sobre o conjunto de equipamentos que possuem intervenção no fluxo de mensagens, tendo pois cada equipamento de ser validado de forma singular. Em termos de condicionantes, para além do elevado número de validações a realizar sobre diferentes equipamentos, verificam-se obstáculos associados com as próprias características das mensagens, quer seja devido à multiplicidade de informação presente, ao dinamismo de certos valores ou relacionadas com o tipo de mensagem e a sua integraçã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 cabeçalhos e o corpo das mensagens. Aquando da validação de soluções SIP, o foco principal centra-se na validação dos valores associados com os cabeçalhos presentes nas mensagens. Sendo estes em grande número, encontrando-se definidos só na RFC base mais de 40 cabeçalhos distintos [3]. Juntamente com o elevado número de cabeçalhos verificamse dificuldade na validação dos mesmos pelo dinamismo A Internet do futuro 115

125 que estes apresentam. Os valores dos cabeçalhos SIP são definidos por uma gramática Augmented Backus Naur Form (ABNF) [5] apresentando-se restritos, mas com um grau de dinamismo elevado comparativamente com os cabeçalhos da maioria dos protocolos. Este conjunto extenso de problemáticas tem relevância tanto ao nível acadé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 métodos capazes de analisarem soluções SIP de forma rápida e eficaz, permitindo a realização cómoda de validações e teste de soluções SIP. III. METODOLOGIA DE TESTE E VALIDAÇÃO DE CENÁRIOS SIP Tendo como ponto de partida as dificuldades de validação de soluções SIP anteriormente identificadas, começou-se a desenvolver trabalho tendo como propósito final a criação de uma solução/metodologia capaz de validar soluções SIP de forma rápida e simples. Neste processo terão que ser consideradas as questões centrais do controlo dos inputs e outputs dos equipamentos, e a execução dos testes em condições em tudo semelhantes às condições que a solução terá no ambiente final. O controlo dos inputs, outputs é fundamental. A solução a validar sobre o ponto de vista do equipamento possui mecanismos de tratamento das mensagens SIP consoante a informação que chega ao equipamento na mensagem, sendo crucial conhecer e controlar bem a informação que é enviada para e do equipamento para se conseguir testar diferentes cenários com a precisão necessária. A solução proposta para esta temá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 validações. Neste tipo de cenários é configurado o equipamento para operar com dois terminais a executar software de emulação SIP. A escolha de ferramentas de emulação em detrimento de terminais físico justifica-se pela capacidade que estas ferramentas possuem de manipular diretamente as mensagens do fluxo, permitindo criar cenários idênticos aos presentes na rede onde o equipamento a validar se encontrara implementado. Relativamente à criação das mensagens, como indicado anteriormente, as mensagens SIP possuem um tamanho avultado sendo assumido por alguns autores o valor médio de 731 bytes por mensagem [6]. Estes valores põem em causa a criação manual das mensagens no script a emular, sendo necessário desenvolver mecanismos automáticos de geração de scripts. Para endereçar esta questão, optou-se pelo uso de aplicações capazes de através de capturas de rede gerar scripts de emulação de tráfego. Desta forma consegue-se garantir a exatidão dos comportamentos, avaliando se os mesmos estão alinhados com a realidade. IV. FERRAMENTAS Open Source Ao nível de ferramentas de emulação de tráfego SIP, existe um conjunto extenso de possibilidades, tais como Seagull [7], SIP Tester [8], SIPp [9], entre outros. Das ferramentas analisadas a que se revelou mais adequada foi o SIPp, devido aos mecanismos que possui de validação de mensagens, à aceitação que a ferramenta tem por parte de entidades relevantes na área do SIP como a Fraunhofer [10] e pelo conjunto de aplicações de tratamento de tráfego que dispõe. No que respeita a geração de cenário, são analisadas duas aplicações que através de capturas de rede (ficheiros PCAP) redigem cenários SIPp. A. SIPp O SIPp é um projeto open source desenvolvido tendo como propósito a geração de tráfego SIP e a validação do mesmo [9]. Em termos de modelo funcional, o SIPp opera sobre ficheiros XML onde são descritos os cenários a executar de forma simples e concisa, sendo fácil o processo de adaptaçã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 cenários próximos da realidade, conjugando scripts de emulação com equipamentos físicos. Relativamente a cenários de testes, um caso prático de integração da ferramenta de emulação com equipamentos, apresentar-se-ia semelhante a Figura 1. Fig. 1: Fluxo de estabelecimento de sessã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), é enviada uma response (ex. 200 OK). Quando o SIPp UAC faz o envio de um request o UAS tem no seu fluxo a indicação do request enviado pelo UAC e viceversa mantendo desta forma o fluxo das mensagens (excerto I de cenário entre o UAC e o UAS). Aquando do término da criação dos cenários SIPp, existe a necessidade de aplicar expressões regulares ao mesmo de 116 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

126 Exc. I: Interligaçã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 expectável para o cabeçalho a validar, estando este mapeado numa expressão regular. Aquando da execução, o próprio SIPp encarrega-se de analisar a mensagem recebida e verificar se a mesma apresenta o valor esperado. O conteúdo da expressão é validado dentro de uma tag <ereg> indicando que componente da mensagem se pretende validar, que tipo de validação e qual a expressão regular com que se pretenda que exista match. Em termos estruturais apresenta-se semelhante ao evidenciado no excerto de código IV. B. Preparação de testes a partir de cenários reais Como referido anteriormente de forma a tornar o processo de geração de scripts uma tarefa menos penosa recorre-se ao uso de aplicações capazes de, forma automática, gerar os cenários pretendidos. De entre as aplicações destacam-se o pcap2sipp [11], sniff2sipp [12]. Das aplicações de estudadas o sniff2sipp apresentou-se como a aplicação mais adequada para a geração de scripts, apresentando-se como uma aplicação mais madura, operando com um conjunto de protocolos superior e capaz de realizar scripts através de capturas ou de traces diretos na rede. V. EXEMPLO DE UTILIZAÇÃO O conjunto das ferramentas apresentadas possibilita a validação de soluções SIP sobre diferentes cenários. A título de exemplo demonstra-se de seguida os diferentes passos a seguir para a validação de um equipamento SIP com funções de encaminhamento e manipulação de cabeçalhos. A validação dos testes inicia-se com o processo de criação dos scripts SIPp, sendo esta tarefa levada a cabo pelo sniff2sipp. Tendo a captura com o comportamento a validar, basta executar a aplicação indicando o nome da captura a gama de portos usada pelo SIP como verificado na excerto II. Exc. II: Comando de arranque da aplicação sniff2sipp./sniff2sipp -f call.cap -p Após a execução do comando são gerados os ficheiros do cliente e do servidor. No ficheiro do cliente é apresentado o IN- VITE a ser enviado para o equipamento a validar (excerto III), enquanto que do lado do servidor é indicada a mensagem que se espera receber. Com o envio e a espera de receção da mensagem já se valida a solução ao nível do fluxo. Contudo, o equipamento a validar substitui o user-part do cabeçalho To pelo valor siphomenetwork, sendo necessário aplicar uma expressão regular ao INVITE a receber no servidor (excerto IV) Estando os cenários SIPp preparados e com as expressões regulares embebidas, basta executar os mesmos. Exc. III: Mensagem INVITE em cená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 cenário SIPp UAS <recv request= INVITE crlf= true > <action > <ereg regexp= <sip:siphomenetwork@* search in= hdr header= To /> </action> </recv> Através da plataforma, consegue-se realizar validações em ambiente emulado como se de tráfego real se tratasse permitindo assim executar e validar os diferentes cenários de forma mais autónoma e controlando o cenário de testes na sua totalidade. VI. CONCLUSÕES As soluções tecnológicas envolvendo o protocolo SIP encontram-se cada vez mais presentes no dia-a-dia das pessoas, verificando-se a necessidade de desenvolver estratégias auxiliares na resolução de tarefas morosas e dispendiosas, como é o caso dos processos de validação e testes de infra-estruturas VoIP. Desta forma, a definição de estratégias eficazes, recorrendo à utilização de ferramentas de automatização, torna-se uma mais-valia indispensável nesta área. A utilização destes mecanismos é útil, tanto no processo de validação de soluções, como no auxílio ao estudo de anomalias, permitindo pois um mais rápido desenvolvimento e implementação de soluções nos clientes finais. Através da solução delineada, que tem por base ferramentas open source, é pois possível acelerar todo o processo de desenvolvimento de soluções SIP, possibilitando às equipas de desenvolvimento a definição de um framework simples mas eficaz para o teste e deteção de anomalias nestes ambientes. REFERENCES [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, [2] H. Schulzrinne S. Casner R. Frederick V. Jacobson. Rtp: A transport protocol for real-time applications, RFC [3] J. Rosenberg H. Schulzrinne G. Camarillo A. Johnston J. Peterson R. Sparks M. Handley E. Schooler. Sip: Session initiation protocol, RFC [4] P. Resnick. Internet message format, RFC [5] D. Crocker P. Overell. Augmented bnf for syntax specifications: Abnf, RFC [6] Masataka Ohta. Overload control in a sip signaling network. International Journal of Electrical and Electronics Engineering, [7] HP OpenCall Software. Seagull: an open source multi-protocol traffic [8] StarTrinity.com. Freeware sip tester (call generator, sip/rtp stressing tool, dos [9] R. Day. Welcome to [10] Fraunhofer FOKUS. Links for ims [11] C. Oancea [12] Digium. digium: The asterik A Internet do futuro 117

127 118 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

128 Transmissão de vídeo com múltiplas descrições com débitos variáveis em canais multi-percurso com débito assimétrico Pedro Correia Instituto de Telecomunicações Instituto Politécnico de Tomar/EST Portugal Pedro A. Amado Assunção Instituto de Telecomunicações Instituto Politécnico de Leiria/ESTG Portugal Vítor Silva Instituto de Telecomunicações Universidade de Coimbra/DEEC Portugal Resumo Este artigo propõe um método para codificação e transmissão de vídeo, usando múltiplas descrições não balanceadas com débitos variáveis em canais assimétricos multi-percurso. O controlo de débito de cada descrição é realizado através da combinação dos parâmetros de codificação escalar não balanceada (U-MDSQ), com base num método que explora a relação linear entre o número de bits e a percentagem de coeficientes da transformada no domínio MDSQ. Os resultados de simulação mostram que o método proposto garante uma melhoria de desempenho em transmissão de vídeo através de canais multipercurso, com restrições na capacidade de transmissão e com taxas de perda de pacotes assimétricas, quando comparado com esquemas MDSQ balanceado (B-MDSQ). Deste modo, a sua utilização traz vantagens em sistemas de comunicação de vídeo que usam redes ou canais de transmissão com múltiplos percursos e com restrições na capacidade disponível ou taxas de perdas assimétricas. I. INTRODUÇÃO Nos ambientes heterogéneos das redes de comunicação atuais, a grande variedade de tecnologias de rede, assim como a rápida evolução das suas arquiteturas e topologias, tem dado origem ao aparecimento de novos métodos que permitam solucionar os problemas de erros de transmissão e perdas. A transmissão de vídeo com diversidade de canais é vista como um esquema interessante de comunicação para fazer face a este cenário. Enquadrando-se neste contexto, a codificação de Vídeo com Múltiplas Descrições (MDC) é uma abordagem de codificação eficiente de modo a aumentar a robustez em canais sujeitos a erros, particulamente em aplicações que permitem a utilização de vários caminhos de comunicação entre o servidor e um determinado cliente. Na codificação de vídeo com múltiplas descrições (MDC), a fonte de sinal é representada através da codificação de vários fluxos de dados (descrições), onde cada um pode ser descodificado de forma independente. Por outro lado, as descrições podem ser combinadas entre si, obtendo-se assim uma descodificação com melhor qualidade quando comparada com a descodificação independente [1]. A maioria das arquitecturas MDC usam N = 2 descrições com débitos e distorções semelhantes, i.e. balanceadas. No entanto, para que o sistema possa lidar com as características variá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 dinâmica os débitos de transmissão de cada descrição por forma a minimizar a distorção no descodificador. Deste modo, esta necessidade obriga que os esquemas de transmissão MDC possuam a capacidade de gerar débitos assimétricos para cada descrição (MDC não balanceado (U- MDC)), podendo descodificar cada descrição de forma independente para resoluções e/ou qualidades diferentes. Usando o conceito de codificação com múltiplas descrições baseado em quantificação escalar (MDSQ) balanceado [2], este artigo usa um novo método MDSQ baseado em tabelas de indexação variáveis [3]. Neste artigo é avaliada a relação linear existente entre o número de bits gerados e o número de coeficientes da transformada que são nulos no contexto MDSQ. Demonstra-se que esta relação linear se mantém em cada descrição quando se aplica na cascata quantificação- MDSQ aos coeficientes da transformada usada em H.264/AVC. O método proposto permite reservar e controlar débitos binários diferentes em cada descrição de acordo com a restrição global de largura de banda e distribuição entre descrições sem degradar o desempenho débito-distorção MDC global. Apesar dos métodos de controlo de débito baseados no modelo linear terem sido usados noutros contextos, o seu uso em esquemas MDSQ não tem sido muito investigado, conferindo assim um aspecto inovador ao caso estudado neste artigo. II. MODELO ρ PARA MDSQ O modelo ρ é baseado na dependência linear entre o número de bits produzido por um codificador e a percentagem de coeficientes nulos resultantes da transformada ρ, depois da quantificação [4]. Este é um modelo bastante simples e pode ser expresso pela seguinte equação, usando apenas um parâmetro φ, R(ρ) = φ(1 ρ), (1) onde R(ρ) é o número de bits obtido como função de ρ, i.e. a percentagem de coeficientes nulos. O parâmetro do modelo é obtido através das unidades de codificação anteriores. A função débitoquantificação (R-Q) é obtida de forma indirecta através da relação entre a estatística da fonte com o passo de quantificação. Consequentemente, é necessário calcular a estatistica da fonte, que pode ser obtida baseada em modelos paramétricos [5]. Outra abordagem possível consiste em usar os dados de unidades de codificação (imagem) anteriores, de modo a poder obter a estatística da fonte de forma operacional para posteriormente calcular um parâmetro de quantificação (QP) adequado para um determinado valor de ρ. A Fig. 1 mostra a dependência entre o número de bits produzido em cada descrição, resultante da codificação MDSQ de imagens I e P, e a percentagem de coeficientes nulos antes de ser aplicado MDSQ. Este exemplo mostra que as descrições balanceadas e não balanceadas seguem uma relação linear entre número de bits e percentagem de zeros antes de MDSQ. É interessante verificar que a proporcionalidade é mantida para diferentes percentagens de balanceamento. Esta caracteristica é particularmente evidente em MDSQ balanceado e para MDSQ não balanceado em débitos binários mais elevados. III. CONTROLO DE DÉBITO U-MDSQ Esta secção apresenta uma nova abordagem para controlo do débito binário em codificadores U-MDSQ, baseada no conceito de atribuição de índices para MDC não balanceado. Esta abordagem permite que o débito binário entre descrições possa ser dinâmico A Internet do futuro 119

129 rate(kbits/frame) Figura Percentage of zeros before MDSQ (a) Imagens I. 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 kbits/imagem 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-D Percentagem de zeros antes de MDSQ (b) Imagens P. Relação entre percentagem de zeros e débito, sequência bus. através da alteração das tabelas de indexação do método MDSQ [3]. O método de controlo de débito proposto tem por objetivo produzir duas descrições com débitos diferentes, baseado na dependência linear entre percentagem de zeros dos coeficientes da transformada e o número de bits obtidos em cada descrição depois de MDSQ. É utilizado um buffer comum às duas descrições. O débito global gerado pelo esquema MDSQ é controlado através a escolha adequada do parâmetro de quantificação QP 0 do codificador central e também pela escolha das tabelas de indexação MDSQ, de acordo com um débito desejado pré-definido. Este método opera em dois níveis distintos: GOP (Grupo de imagens) e imagem. Ao nível de GOP, o algoritmo de controlo de débito determina o quantidade de bits necessária para manter um nível adequado de preenchimento do buffer de acordo com um determinada restrição de largura de banda do canal. Adicionalmente, a percentagem de balanceamento entre descrições é também definida de acordo com o débito alocado a cada uma das descrições. O método proposto é pois uma extensão do modelo usado em [6] de modo a incluir um objectivo de débito adicional, de acordo com a percentagem de balanceamento, para que se possa definir o débito de cada descrição para um determinado débito total. Ao nível da imagem, o método de controlo de débito é composto por duas etapas. A primeira etapa define o objectivo para débito global (i.e, para ambas as descrições) com base na ocupação do buffer e das medidas de complexidade da imagem. Adicionalmente, calcula o objectivo de débito para a descrição principal (a que possuir o débito maior), tendo em conta a percentagem de balanceamento entre descrições. A segunda etapa usa o modelo ρ aplicado à descrição principal para calcular a percentagem de zeros, ρ, necessária para cumprir o ojectivo de débito. Tendo este valor segue-se o cálculo do passo de quantificação δ que permite obter o débito necessário e o correspondente parâmetro de quantificação QP 0. Cada descrição é codificada com base no QP 0 e na matriz de indexação determinada para a percentagem de balanceamento desejada. Depois de codificar ambas as descrições, o parâmetro do modelo ρ e a tabela de indexação são actualizadas para a próxima imagem. A. Controlo de débito a nível de imagem O objectivo do número de bits para cada descrição T i(j) e a percentagem de balanceamento (π 1, π 2), é dado pela expressão, { Ti(j) D1 = T i(j) π 1 T i(j) D2 = T i(j) π 2 (2) O algoritmo de controlo segue a percentagem de balanceamento desejado através do ajuste do parâmetro Z e consequentemente da matriz de indexação, baseada no número de bits obtido em cada descrição na imagem anterior. Este ajuste é feito usando o modelo linear, { π 1(Z, t) = m tz + b t, 1 Z 3, t = I, P, B π 2(Z, t) = 100 π 1(Z, t) Posteriormente, tendo em conta as características descritas na secção II, é aplicado o modelo ρ para determinar o parâmetro de quantificação central (QP 0) para um determinado objectivo de débito em cada descrição. Tendo em conta os resultados obtidos, o modelo possui uma maior linearidade na descrição com maior débito. Deste modo, o modelo é aplicado à descrição principal usando as estatísticas da imagem anterior do mesmo tipo. Assim, o parâmetro do modelo, φ i, para a imagem i é calculada de acordo com, (3) φ i = R i 1/(1 ρ i 1). (4) Depois de calcular φ i para uma dada imagem e o correspondente objetivo de débito para a descrição principal, é calculado o valor ρ correspondente (i.e. a percentagem de zeros) usando a equação (1). Através do histograma dos coeficientes da transformada da imagem anterior, é definido o valor do passo de quantificação δ, de acordo com a percentagem de zeros ρ necessária para produzir o número de bits pretendido. A relação entre δ e ρ é estabelecida através de uma tabela de correspondência, preenchida com base nos dados obtidos na imagem anterior. Finalmente, o parâmetro de quantificação é determinado a partir da expressão [5], QP 0 = 6 log 3δ 2( ), 0 QP0 51. (5) 2 O valor de QP 0 para as imagens B são obtidas por interpolação das imagens de referência vizinhas (I ou P), tendo em conta a correspondente distância temporal. O valor absoluto da diferença entre imagens adjacentes é limitada ao valor máximo 2, por forma a garantir uma qualidade visual uniforme ao longo da sequencia de vídeo. As matriz de indexação usada é a mesma da imagem de referencia mais próxima. IV. AVALIAÇÃO DE DESEMPENHO O desempenho do método de controlo de débito baseia-se na simulação para transmissão MDC em canais com débito assimétrico com vários cenários de condições de perda de pacotes, comparando os métodos MDC não balanceado com MDC balanceado. Foram usadas para a simulação as sequencias foreman e bus, com resolução CIF, frequência de imagem= 15Hz, GOP=IPBBP... e 16 imagens/gop. Foi usada a arquitectura MDC em malha fechada descrita em [7] para implementação do método de controlo de débito para MDC não balanceado. Na simulação foi usado uma dimensã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. São definidos como objectivos, o débito global assim como as percentagens de balanceamento entre descrições. A. Transmissão em canais com débito assimétrico O método de controlo de débito foi avaliado em cenários de transmissão de video com perda de pacotes em canais com débitos diferentes, mas também com taxas de perda de pacotes diferenciados. O débito de saída foi definido a 1 Mbps, usando um número fixo de 10 pacotes por imagem, com 20% de redundância da informação lateral para controlo de distorção, resultante num débito global de 1.2 Mbps. Os débitos e níveis de resundância são idêntidos para os esquemas balanceados e não balanceados. A informação adicional é assimetricamente distribuída nas duas descrições de modo a manter as percentagens de balanceamento especificadas como objectivo em 120 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

130 PSNR(dB) Média Figura 2. iguais. PSNR(dB) Média DLR(%) Bal.(600kbps,600 kbps) Não bal.(480 kbps, 720 kbps) Não bal. (360 kbps; 840 kbps) (a) Sequencia foreman. PSNR(dB) Média Bal. (600 kbps; 600 kbps) Não bal. (480 kbps; 720 kbps) Não bal.(360 kbps; 840 kbps) DLR(%) (b) Sequencia bus. PSNR média usando canais com taxa de perda de pacotes (PLR) 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%) DLR(%) (a) Sequência foreman. PSNR(dB) Média 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%) DLR(%) (b) Sequência bus. Figura 3. PSNR média usando canais com taxas de perda de pacotes (PLR) diferentes. cada descrição. A simulação de perdas de pacotes foram realizadas usando o modelo de Markov Gilbert-Elliott de 2 estados por forma a gerar várias taxas médias de perda de pacotes (PLR) e valores médios de perdas em rajada (burst) [8]. De modo a obter resultados estatisticamente relevantes, a transmissão de cada sequência (foreman and bus) foi simulada 50 vezes para cada condição de rede especificada. Nesta simulação, foram consideradas taxas de perda de pacotes médias entre 0% e 10% com um burst médio de 4 pacotes. São considerados dois cenários de aplicação para comparação entre MDSQ balanceado e não balanceado.: i) canais com a mesma PLR e ii) canais com diferentes PLR. Em ambos os casos, o desempenho é avaliado através da PSNR global (i.e., obtida pela descodificação das duas descrições) em função da percentagem da perda total de dados (DLR) em ambas as descriçõ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 variável dos pacotes existente em cada descrição, embora tenhamos o mesmo de nú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 média é mostrada como função de DLR. A comparação entre MDSQ balanceada e não balanceada mostram que a PSNR média para U-MDSQ é melhor que MDSQ balanceado para o mesmo débito total, i.e. entre 0.5dB e 1dB em média. Este facto é explicado pelo facto de existir no método não balanceado uma melhor qualidade reconstrução de apenas uma descrição, comparando com o método balanceado para o mesmo débito. Os resultados mostram uma melhoria efectiva do desempenhodo método proposto face ao método clássico balanceado em aplicações com diversidade de canais, com diferentes largura de banda disponíveis. 2) Canais com PLR diferentes: Este cenário de transmissão assume que cada canal tem diferentes PLR. Para que se possa estabelecer condições equivalentes, cada descrição tanto do método balanceado como do método não balanceado estão sujeitas à mesma percentagem de dados perdidos. De notar que, como foi explicado anteriormente, este facto é obtido usando PLR diferentes em cada canal. Em MDSQ não balanceado, a descrição de maior débito é transmitido no canal com melhor condições, i.e., menor PLR. Foram utilizadas dois objectivos de débito: i) R D1 = 480kbps; R D2 = 720kbps; ii) R D1 = 360kbps; R D2 = 840kbps. Para o caso de MDSQ balanceado, a comparação é realizada para o mesmo débito total de 1200 kbps, i.e., R D1 = 600kbps; R D2 = 600kbps. As Figs. 3(a) e 3(b) mostram a PSNR média versus DLR. Na comparação dos resultados, a percentagem total de dados perdidos em cada descrição correspondente é a mesma, i.e., (70%, 30%) and (60%, 40%). Estes resultados mostram que o método U-MDSQ também são melhores do que MDSQ balanceado para a maioria dos valores de DLR. Os valores médios de ganho de U-MDSQ sã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 método proposto em ambientes de transmissão com vários canais, com largura de banda e PLR diferentes. V. CONCLUSÕES Este artigo propõe um novo método MDSQ não balanceado para transmissão em canais com largura de banda e percentagem de perda de pacotes diferentes. Os resultados apresentados mostram que o método proposto melhora o desempenho global em cenários de canais sujeitos a perdas de pacotes, onde a largura de banda de cada canal e a taxa de perdas de pacotes são assimétricos. Como conclusão, o trabalho desenvolvido pode ser aplicado em aplicações de codificação de vídeo com múltiplas descrições onde a transmissão seja realizada através de vários canais com largura de banda e restrições de perdas de pacotes assimétricas. AGRADECIMENTOS Este trabalho for parcialmente suportado pela Fundação para a Ciência e Tecnologia (FCT), com as bolsas SFRH/BD/50035/2009 e o projecto PEst- OE/EEI/LA0008/2013. REFERÊNCIAS [1] V. Goyal, Multiple description coding: Compression meets the network, IEEE Signal Processing Magazine, vol. 18, no. 5, pp , September [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 , [3] P. F. Correia, P. Assunçã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 , dec [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 , Feb [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 , [7] P. Correia, P. Assuncao, and V. Silva, Drift-free multiple description intra video coding, in Image Processing (ICIP), th IEEE International Conference on, , pp [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 A Internet do futuro 121

131 122 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013

132 Web-Browser Real Time Communication in IMS Systems Rui Sábio a, Fernando Silva a, Carlos Rabadão a,b, António Pereira a,b a Centro de Investigação de Informática e Comunicações, Escola Superior de Tecnologia e Gestão de Leiria, , 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 A Internet do futuro 123

133 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. 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. 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. 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 124 Atas da 13ª Conferência sobre Redes de Computadores - CRC2013