Re: [gaia] Fixes to "Alternative Network Deployments" Internet Draft
"Prof. Adam Wolisz" <awo@ieee.org> Thu, 20 November 2014 15:46 UTC
Return-Path: <awo@ieee.org>
X-Original-To: gaia@ietfa.amsl.com
Delivered-To: gaia@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA8B1A1AC8 for <gaia@ietfa.amsl.com>; Thu, 20 Nov 2014 07:46:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.539
X-Spam-Level: **
X-Spam-Status: No, score=2.539 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_AFFORDABLE=1, GB_I_LETTER=-2, GB_SUMOF=1, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_PAIN=2.3, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smj17r-onJ7J for <gaia@ietfa.amsl.com>; Thu, 20 Nov 2014 07:46:21 -0800 (PST)
Received: from mail.tu-berlin.de (mail.tu-berlin.de [130.149.7.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 134AB1A1AB6 for <gaia@irtf.org>; Thu, 20 Nov 2014 07:46:20 -0800 (PST)
X-tubIT-Incoming-IP: 192.76.146.51
Received: from wlan.dagstuhl.de ([192.76.146.51] helo=[192.168.12.216]) by mail.tu-berlin.de (exim-4.72/mailfrontend-8) with esmtpa id 1XrTw0-0002e0-k5; Thu, 20 Nov 2014 16:46:17 +0100
Message-ID: <546E0CCC.5090201@ieee.org>
Date: Thu, 20 Nov 2014 16:46:20 +0100
From: "Prof. Adam Wolisz" <awo@ieee.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ermanno Pietrosemoli <ermanno@gmail.com>, Jose Saldana <jsaldana@unizar.es>
References: <9C1CE519-C7D9-44D3-BBF8-C76D220D264B@gmail.com> <CAPaG1AkoE1GJ5WpM7YTaxWVfqaA7h0YwA-9GcwQ++bZTtj3uSQ@mail.gmail.com> <CAD_CWO0kyYrr6tLzRyr9hcdCxUc2hnc_-=T0abPC4BKYe=LSNg@mail.gmail.com> <CAPaG1An0c=grZ8ShGXdQAf-19Xi+=XFyGt-iNs-meJJu-x7DKQ@mail.gmail.com> <008a01cffa6a$d0966bb0$71c34310$@unizar.es> <CA+qwFJkTVTYr5KomBdyMh02VfW885__N0PYXcaYCPwQS7rKDTw@mail.gmail.com>
In-Reply-To: <CA+qwFJkTVTYr5KomBdyMh02VfW885__N0PYXcaYCPwQS7rKDTw@mail.gmail.com>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.20.153918
X-PMX-Spam: Gauge=IIIIIII, Probability=0%, Report=''
Archived-At: http://mailarchive.ietf.org/arch/msg/gaia/RzoftqVCc6l5zYetZStbzOMQXs0
Cc: gaia <gaia@irtf.org>, Steve Song <stevesong@nsrc.org>, Arjuna Sathiaseelan <arjuna.sathiaseelan@cl.cam.ac.uk>
Subject: Re: [gaia] Fixes to "Alternative Network Deployments" Internet Draft
X-BeenThere: gaia@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Global Access to the Internet for All <gaia.irtf.org>
List-Unsubscribe: <https://irtf.org/mailman/options/gaia>, <mailto:gaia-request@irtf.org?subject=unsubscribe>
List-Archive: <http://irtf.org/mail-archive/web/gaia/>
List-Post: <mailto:gaia@irtf.org>
List-Help: <mailto:gaia-request@irtf.org?subject=help>
List-Subscribe: <https://irtf.org/mailman/listinfo/gaia>, <mailto:gaia-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Nov 2014 15:46:33 -0000
At the edge of the discussion about possible usage of white spaces i would like to drow attention of those who
migh tbe interested in experimental work:
The European Commission Project "CREW" http://www.crew-project.eu/" rel="nofollow">http://www.crew-project.eu/
is entirely to creation and running testbeds for cognitive radio usage of "unused frequencies" including
white spaces.
A set of testbeds is available (both in- doors and out- doors) - open calls make possile usage of these
testbeds and their extensions to meet possible additional requirements
best
adam
Hi,I made a few changes in the document, highlighted in red in the attached pdf, and a short mention of the 802.22 standard, since, to the best of my knowledge, it has not been implemented in any of the White Spaces products currently available.
Best regards,Ermanno---------
[http://tools.ietf.org/html/" rel="nofollow">Docs] [https://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.txt" rel="nofollow">txt|http://tools.ietf.org/pdf/draft-manyfolks-gaia-community-networks-01.txt" rel="nofollow">pdf|http://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.xml" rel="nofollow">xml|http://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.html" rel="nofollow">html] [https://datatracker.ietf.org/doc/draft-manyfolks-gaia-community-networks" rel="nofollow">Tracker] [Email] [http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-manyfolks-gaia-community-networks-01.txt" rel="nofollow">Diff1] [http://tools.ietf.org/rfcdiff?url2=draft-manyfolks-gaia-community-networks-01.txt" rel="nofollow">Diff2] [http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.txt" rel="nofollow">Nits]
Versions: http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-00" rel="nofollow">00 http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01" rel="nofollow">01
Global Access to the Internet for All J. Saldana, Ed.
Internet-Draft University of Zaragoza
Intended status: Informational A. Arcia-Moret
Expires: April 9, 2015 Universidad de Los Andes
B. Braem
iMinds
L. Navarro
U. Politecnica Catalunya
E. Pietrosemoli
Escuela Latinoamericana de Redes
C. Rey-Moreno
University of the Western Cape
A. Sathiaseelan
University of Cambridge
M. Zennaro
Abdus Salam ICTP
October 6, 2014
Alternative Network Deployments. Taxonomy and characterization
draft-manyfolks-gaia-community-networks-01
Abstract
This document presents a taxonomy of "alternative network
deployments", and a set of definitions and shared characteristics.
This term includes a set of network models emerged in the last
decades with the aim of bringing Internet connectivity to people,
following topological, architectural and business models different
from the so-called "traditional" ones, where a company deploys the
infrastructure connecting the households of the users, who pay for
it.
Several initiatives throughout the World have built large scale
networks that use wireless technologies (including long distance) due
to the reduced cost of using the unlicensed spectrum. Others rely on
wired technologies. Some of these networks are self-organized and
decentralized, other ones are based on sharing wireless resources of
the users. The emergence of these networks can be motivated by
different causes: Sometimes the reluctance, or the impossibility, of
network operators to provide wired and cellular infrastructures to
rural/remote areas. In these cases, the networks have self
sustainable business models that provide more localised communication
services as well as providing Internet backhaul support through
peering agreements with traditional network operators. Some other
times, they are built as a complement and an alternative to
commercial Internet access provided by "traditional" network
operators.
Saldana, et al. Expires April 9, 2015 [Page 1]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-2" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
The classification considers different existing network models as
e.g., community networks, open wireless services, user-extensible
services, traditional local ISPs, new global ISPs, etc. Different
criteria are used in order to build a classification as e.g., the
ownership of the equipment, the way the network is organized, the
participatory model, the extensibility, if they are driven by a
community, a company or a local (public or private) stakeholder, etc.
According to the developed taxonomy, a characterization of each kind
of network is presented, in terms of network characteristics related
to architecture, organization, etc.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of http://tools.ietf.org/html/bcp78" rel="nofollow">BCP 78 and http://tools.ietf.org/html/bcp79" rel="nofollow">BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/" rel="nofollow">http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 9, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to http://tools.ietf.org/html/bcp78" rel="nofollow">BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info" rel="nofollow">http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4" rel="nofollow">Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Saldana, et al. Expires April 9, 2015 [Page 2]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-3" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
Table of Contents
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-1" rel="nofollow">1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-3" rel="nofollow">3
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-1.1" rel="nofollow">1.1. Requirements Language . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-4" rel="nofollow">4
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2" rel="nofollow">2. Classification . . . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-4" rel="nofollow">4
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.1" rel="nofollow">2.1. Community Networks . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-5" rel="nofollow">5
2.2. Crowdshared approaches, led by the people and third party
stakeholders . . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-6" rel="nofollow">6
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.3" rel="nofollow">2.3. User-centric Networks . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-7" rel="nofollow">7
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.4" rel="nofollow">2.4. Testbed . . . . . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-8" rel="nofollow">8
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3" rel="nofollow">3. Scenarios where Alternative Networks are deployed . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-8" rel="nofollow">8
3.1. Alternative Networks depending on the income level of
each country . . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-8" rel="nofollow">8
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3.2" rel="nofollow">3.2. Urban vs. rural areas . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-10" rel="nofollow">10
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4" rel="nofollow">4. Technologies employed . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11" rel="nofollow">11
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1" rel="nofollow">4.1. Wired . . . . . . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11" rel="nofollow">11
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1.1" rel="nofollow">4.1.1. Optical Fiber . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11" rel="nofollow">11
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2" rel="nofollow">4.2. Wireless . . . . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11" rel="nofollow">11
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.1" rel="nofollow">4.2.1. Antennas . . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11" rel="nofollow">11
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.2" rel="nofollow">4.2.2. Link length . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-13" rel="nofollow">13
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3" rel="nofollow">4.2.3. Layer 2 . . . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-15" rel="nofollow">15
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.1" rel="nofollow">4.2.3.1. 802.11 (Wi-Fi) . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-15" rel="nofollow">15
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.2" rel="nofollow">4.2.3.2. GSM . . . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17" rel="nofollow">17
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5" rel="nofollow">5. Network and architecture issues . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17" rel="nofollow">17
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1" rel="nofollow">5.1. Layer 3 . . . . . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17" rel="nofollow">17
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.1" rel="nofollow">5.1.1. IP addressing . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17" rel="nofollow">17
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2" rel="nofollow">5.1.2. Routing protocols . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18" rel="nofollow">18
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.1" rel="nofollow">5.1.2.1. Traditional routing protocols . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18" rel="nofollow">18
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.2" rel="nofollow">5.1.2.2. Mesh routing protocols . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18" rel="nofollow">18
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2" rel="nofollow">5.2. Upper layers . . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18" rel="nofollow">18
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1" rel="nofollow">5.2.1. Services provided by these networks . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-19" rel="nofollow">19
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.1" rel="nofollow">5.2.1.1. Intranet services . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-20" rel="nofollow">20
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.2" rel="nofollow">5.2.1.2. Access to the Internet . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-20" rel="nofollow">20
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.3" rel="nofollow">5.3. Topology . . . . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21" rel="nofollow">21
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-6" rel="nofollow">6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21" rel="nofollow">21
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-7" rel="nofollow">7. Contributing Authors . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21" rel="nofollow">21
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-8" rel="nofollow">8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22" rel="nofollow">22
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-9" rel="nofollow">9. Security Considerations . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22" rel="nofollow">22
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10" rel="nofollow">10. References . . . . . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22" rel="nofollow">22
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10.1" rel="nofollow">10.1. Normative References . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22" rel="nofollow">22
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10.2" rel="nofollow">10.2. Informative References . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-23" rel="nofollow">23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-25" rel="nofollow">25
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-1" rel="nofollow">1. Introduction
Several initiatives throughout the World have built large scale
networks that use wireless technologies (including long distance) due
to the reduced cost of using the unlicensed spectrum. Others rely on
Saldana, et al. Expires April 9, 2015 [Page 3]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-4" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
wired technologies. Some of them are self-organized and
decentralized, other ones are based on sharing wireless resources of
the users. The emergence of these networks can be motivated by
different causes: Sometimes the reluctance, or the impossibility, of
network operators to provide wired and cellular infrastructures to
rural/remote areas [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Pietrosemoli" rel="nofollow">Pietrosemoli]. In these cases, the networks have
self sustainable business models that provide more localised
communication services as well as providing Internet backhaul support
through peering agreements with traditional network operators. Some
other times, they are built as a complement and an alternative to
commercial Internet access provided by "traditional" network
operators.
One of the aims of the Global Access to the Internet for All (GAIA)
IRTF initiative is "to document and share deployment experiences and
research results to the wider community through scholarly
publications, white papers, Informational and Experimental RFCs,
etc." In line with this objective this document is intended to
propose a classification of these "alternative network deployments".
This term includes a set of network models emerged in the last
decades with the aim of bringing Internet connectivity to people,
following topological, architectural and business models different
from the so-called "traditional" ones, where a company deploys the
infrastructure connecting the households of the users, who pay for
it. The document is intended to be largely descriptive providing a
broad overview of initiatives, technologies and approaches employed
in these networks. Research references describing each kind of
network are also provided.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-1.1" rel="nofollow">1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in http://tools.ietf.org/html/rfc2119" rel="nofollow">RFC 2119 [http://tools.ietf.org/html/rfc2119" rel="nofollow">RFC2119].
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2" rel="nofollow">2. Classification
This section classifies Alternative Networks according to their
intended usage. Each of them have different incentive structures,
maybe common technological challenges, but most importantly
interesting usage challenges which feeds into the incentives as well
as technological challenges.
This classification is agnostic from the technical point of view.
Technology in this case must be taken as implementation. Moreover,
many of these networks are implemented in a way that several
technologies (Ad-Hoc WiFi, Infrastructure WiFi, Optical Fibre, IPv4,
IPv6, http://tools.ietf.org/html/rfc1918" rel="nofollow">RFC1918, OLSR, BMX6, etc.) coexist.
Saldana, et al. Expires April 9, 2015 [Page 4]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-5" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.1" rel="nofollow">2.1. Community Networks
Community Networks are large-scale, distributed, self-managed
networks sharing these characteristics:
- They are built and organized in a decentralized and open manner.
- They start and grow organically, they are open to participation
from everyone, sometimes agreeing to an open peering agreement.
Community members are directly contributing active network
infrastructure (not just passive infrastructure).
- Knowledge about building and maintaining the network and ownership
of the network itself is decentralized and open. Community members
have an obvious and direct form of organizational control over the
overall operation of the network in their community (not just their
own participation in the network).
- The network CAN serve as a backhaul for providing a whole range of
services and applications, from completely free to even commercial
services.
Hardware and software used in community networks CAN be very diverse,
even inside one network. A Community Network CAN have both wired and
wireless links. The network CAN be managed by multiple routing
protocols or network topology management systems.
A definition of Free Network (which MAY be the same as Community
Network) is proposed by the Free Network Foundation (see
http://thefnf.org/" rel="nofollow">http://thefnf.org) as:
A free network equitably grants the following freedoms to all:
Freedom 0 - Freedom to communicate for any purpose, without
discrimination, interference, or interception.
Freedom 1 - The freedom to grow, improve, communicate across, and
connect to the whole network.
Freedom 2- The freedom to study, use, remix, and share any network
communication mechanisms, in their most reusable forms."
The principles of these networks have also been summarized (see
http://guifi.net/ca/CXOLN" rel="nofollow">http://guifi.net/ca/CXOLN) this way:
- You have the freedom to use the network for any purpose as long as
you don't harm the operation of the network itself , the rights of
Saldana, et al. Expires April 9, 2015 [Page 5]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-6" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
other users, or the principles of neutrality that allow contents and
services to flow without deliberate interference.
- You have the right to understand the network, to know its
components, and to spread knowledge of its mechanisms and principles.
- You have the right to offer services and content to the network on
your own terms.
- You have the right to join the network, and the responsibility to
extend this set of rights to anyone according to these same terms.
These networks grow organically, since they are formed by the
aggregation of nodes belonging to different users. A minimum
governance infrastructure is required in order to coordinate IP
addressing, routing, etc. A clear example of this kind of Community
Network is described in [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Braem" rel="nofollow">Braem]. These networks are effective in
enhancing and extending digital Internet rights following a
participatory model.
The fact of the users adding new infrastructure can be used to build
another definition: A network in which any participant in the system
may add link segments to the network in such a way that the new
network segments can support multiple nodes and adopt the same
overall characteristics as those of the joined network, including the
capacity to further extend the network. Once these link segments are
joined to the network, there is no longer a meaningful distinction
between the previous extent of the network and the new extent of the
network. In that sense, Community Networks can be called "user-
extensible networks".
These networks are also called sometimes "Free Networks" or even
"Network Commons". However, the most accepted name is Community
Networks.
In Community Networks, the profit can only be made by services and
not by the infrastructure itself, because the infrastructure is
neutral, free, and open (traditional ISPs base their business on the
control of the infrastructure). In Community Networks, everybody
keeps the ownership of what he/she has contributed.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.2" rel="nofollow">2.2. Crowdshared approaches, led by the people and third party
stakeholders
These networks follow the following approach: the home router creates two
wireless networks, one of them to be normally used by the owner, and
the other one is public. A small fraction of the bandwidth is
allocated to the public network (as e.g. Less-than-best-effort or
Saldana, et al. Expires April 9, 2015 [Page 6]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-7" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
scavenger traffic), to be employed by any user of the service in the
immediate area. An example is described in [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-PAWS" rel="nofollow">PAWS].
A Virtual Private Network (VPN) is created for public traffic, so it
is completely secure and separated from the owner's connection. The
network capacity shared may employ a less-than-best-effort approach,
so as not to harm the traffic of the owner of the connection
[http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Sathiaseelan_a" rel="nofollow">Sathiaseelan_a].
There are three actors in the scenario:
- End users who sign up for the service and share their network
capacity. As a counterpart, they can access anyone's home broadband
for free.
- Virtual Network Operators (VNOs) are stakeholders with socio-
environmental objectives. They can be a local government, grass root
user communities, charities, or even content operators, smart grid
operators, etc. They are the ones who actually run the service.
- Network operators, who have a financial incentive to lease out the
unused capacity [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Sathiaseelan_b" rel="nofollow">Sathiaseelan_b] at lower cost to the VNOs.
VNOs pay the sharers and the network operators, thus creating an
incentive structure for all the actors: the end users get money for
sharing their network, the network operators are paid by the VNOs,
who in turn accomplish their socio-environmental role.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.3" rel="nofollow">2.3. User-centric Networks
A first example is constituted by the networks created and managed by City Councils
(e.g., [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Heer" rel="nofollow">Heer]). Some companies [FON reference missing] develop and
sell Wi-Fi routers with a dual access: a Wi-Fi network for the user,
and a shared one. A user community is created, an people can join it
different ways: they can buy a dual router, so they share their
connection and in turn they get access to all the routers associated
to the community. Some users can even get some revenues every time
another user connects to their Wi-Fi spot. Other users can just buy
some passes in order to use the network. Some telecommunications
operators can collaborate with the community, including in their
routers the possibility of creating these two networks.
These networks can be defined as a set of nodes whose owners share
common interests (e.g. sharing connectivity; resources; peripherals)
regardless of their physical location. The node location exhibits a
space and time correlation which is the basis to establish a robust
connectivity model over time.
Saldana, et al. Expires April 9, 2015 [Page 7]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-8" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
- "Interest": a parameter capable of providing a measure (cost) of
the attractiveness of a node towards a specific location, in a
specific instant in time.
- The owner: an entity (e.g. end-user; operator; virtual operator;
municipality) that is to be made responsible for any actions
concerning his/her device.
- The user: a legal entity or an individual using or requesting a
publicly available electronic communications' service for private or
business purposes, without necessarily having subscribed to such
service.
- Resources: A physical or virtual element of a global system. For
instance, bandwdith; energy; data; devices.
- The Virtual Operator: entity that acts in some aspects as a network
coordinator. It may provide services such as initial authentication
or registering, and eventually, trust relationship storage. A VO is
not an ISP given that it does not provide Internet access (e.g.
infrastructure; naming). A VO is neither an ASP since it does not
provide user services.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.4" rel="nofollow">2.4. Testbed
In some cases, the initiative to start the network is not from the
community, but from a research entity (e.g. a university), with the
aim of using it for research purposes [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Samanta" rel="nofollow">Samanta].
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3" rel="nofollow">3. Scenarios where Alternative Networks are deployed
Alternative Network Deployments are present in every part of the
World. Even in some high-income countries, these networks have been
built as an alternative to commercial ones managed by traditional
network operators. This section discusses the scenarios where
alternative networks are interesting or have been deployed.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3.1" rel="nofollow">3.1. Alternative Networks depending on the income level of each country
There is no definition for what a developing country represents that
has been recognized internationally, but the term is generally used
to describe a nation with a low level of material well-being. In
this sense, one of the most commonly used classification is the one
by the World Bank, who ranks countries according to their Gross
National Income (GNI) per Capita: low income, middle income, and high
income, being those falling within the low and middle income groups
considered developing economies. Developing countries have been also
defined as those which are in transition from traditional lifestyles
Saldana, et al. Expires April 9, 2015 [Page 8]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-9" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
towards the modern lifestyle which began in the Industrial
Revolution. Additionally, the Human Development Index, which
considers not only the GNI but also life expectancy and education,
has been proposed by the United Nations to rank countries according
to the well-being of a country and not solely based on economic
terms. These classifications are used to give strong signals to the
international community to the need of special concessions in support
of these countries, implying a correlation between development and
increased well-being.
However, at the beginning of the 90's the debates about how to
quantify development in a country were shaken by the appearance of
Internet and mobile phones, which many authors consider the beginning
of the Information Society. With the beginning of this Digital
Revolution, defining development based on Industrial Society concepts
started to be challenged, and links between digital development and
its impact on human development started to flourish. The following
dimensions are considered to be meaningful when measuring the digital
development state of a country: infrastructures (availability and
affordability); ICT sector (human capital and technological
industry); digital literacy; legal and regulatory framework; and
content and services. The lack or less extent of digital development
in one or more of these dimensions is what has been referred as
Digital Divide. This divide is a new vector of inequality which - as
it happened during the Industrial Revolution - generates a lot of
progress at the expense of creating a lot economic poverty and
exclusion. The Digital Divide is considered to be a consequence of
other socio-economic divides, while, at the same time, a reason for
their rise.
In this context, the so-called "developing countries", worried of
being left behind of this incipient digital revolution, motivated the
World Summit of the Information Society which aimed at achieving "a
people-centred, inclusive and development-oriented Information
Society, where everyone can create, access, utilize and share
information and knowledge, enabling individuals, communities and
peoples to achieve their full potential in promoting their
sustainable development and improving their quality of life" [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-WSIS" rel="nofollow">WSIS],
and called upon "governments, private sector, civil society and
international organisations" to actively engage to accomplish it
[http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-WSIS" rel="nofollow">WSIS].
Most efforts from governments and international organizations focused
initially on improving and extending the existing infrastructure in order to not leave their population behind. Universal Access and Service
plans have taken different forms in different countries over the
years, with very uneven success rates, but in most cases inadequate
to the scale of the problem. Given its incapacity to solve the
Saldana, et al. Expires April 9, 2015 [Page 9]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-10" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
problem, some governments included Universal Service and Access
obligations to mobile network operators when liberalizing the
telecommunications market. In combination with the overwhelming and
unexpected uptake of mobile phones by poor people, this has mitigated
the low access indicators existing in many developing countries at
the beginning of the 90s [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Rendon" rel="nofollow">Rendon].
Although it is undeniable the contribution made by mobile network
operators in decreasing the access gap, their model presents some
constraints that limits the development outcomes that increased
connectivity promises to bring. Prices, tailored for the more
affluent part of the population, remain unaffordable to many, who
invest large percentages of their disposable income in
communications. Additionally, the cost of prepaid packages, the only
option available for the informal economies existing throughout
developing countries, is high compared with the rate longer-term
subscribers pay.
The consolidation of many Alternative Networks (e.g. Community
Networks) in high income countries sets a precedent for civil society
members from the so-called developing countries to become more active
in the search for alternatives to provide themselves with affordable
access. Furthermore, Alternative Networks could contribute to other
dimensions of the digital development like increased human capital
and the creation of contents and services targeting the locality of
each network.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3.2" rel="nofollow">3.2. Urban vs. rural areas
The Digital Divide presented in the previous section is not only
present between countries, but within them too. This is specially
the case for rural inhabitants, which represents approximately 55% of
the World's population, from which 78% inhabit in developing
countries. Although it is impossible to generalize among them, there
exist some common features that have determined the availability of
ICT infrastructure in these regions. The disposable income of their
dwellers is lower than those inhabiting urban areas, with many
surviving on a subsistence economy. Many of them are located in
geographies difficult to access and exposed to extreme weather
conditions. This has resulted in the almost complete lack of
electrical infrastructure. This context, together with their low
population density, discourages telecommunications operators to
provide similar services to those provided to urban dwellers, since
they do not deem them profitable
The cost of the wireless infrastructure required to set up a network,
including powering them via solar energy, is within the range of
availability if not of individuals at least of entire communities.
Saldana, et al. Expires April 9, 2015 [Page 10]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
The social capital existing in these areas can allow for Alternative
Network set-ups where a reduced number of nodes may cover communities
whose dwellers share the cost of the infrastructure and the gateway
and access it via inexpensive wireless devices. In this case, the
lack of awareness and confidence of rural communities to embark
themselves in such tasks can become major barriers to their
deployment. Scarce technical skills in these regions have been also
pointed as a challenge for their success, but the proliferation of
urban Community Networks, where scarcity of spectrum, scale, and
heterogeneity of devices pose tremendous challenges to their
stability and to that of the services they aim to provide, has
fuelled the creation of robust low-cost low-consumption low-
complexity off-the-self wireless devices which make much easier the
deployment and maintenance of these alternative infrastructures in
rural areas.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4" rel="nofollow">4. Technologies employed
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1" rel="nofollow">4.1. Wired
Some of the wired technologies employed in ANs are:
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1.1" rel="nofollow">4.1.1. Optical Fiber
In many (developed or developing) countries it may happen that
national service providers may decline to provide connectivity to
tiny and isolated villages. So in some cases the villagers have
created their own optical fiber networks
http://www.fiberopticmania.com/blogs/details/948/lowenstedt-villagers-built-own-fiber-optic-network#sthash.rolFITEo.dpuf" rel="nofollow">http://www.fiberopticmania.com/blogs/details/948/lowenstedt-
http://www.fiberopticmania.com/blogs/details/948/lowenstedt-villagers-built-own-fiber-optic-network#sthash.rolFITEo.dpuf" rel="nofollow">villagers-built-own-fiber-optic-network#sthash.rolFITEo.dpuf
http://www.telegraph.co.uk/news/worldnews/europe/germany/10871150/German-villagers-set-up-their-own-broadband-network.html" rel="nofollow">http://www.telegraph.co.uk/news/worldnews/europe/germany/10871150/
http://www.telegraph.co.uk/news/worldnews/europe/germany/10871150/German-villagers-set-up-their-own-broadband-network.html" rel="nofollow">German-villagers-set-up-their-own-broadband-network.html
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2" rel="nofollow">4.2. Wireless
Different wireless technologies [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-WNDW" rel="nofollow">WNDW] can be employed in Alternative
Network Deployments.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.1" rel="nofollow">4.2.1. Antennas
Three kinds of antennas are suitable to be used in these networks:
omnidirectional, directional and high gain antennas.
For local access, omnidirectional antennas are the most useful, since
they provide the same coverage in all directions of the plane in
which they are located. Above and below this plane, the received
signal will diminish, so the maximum benefits are obtained when the
client is at approximately the same height as the Access Point.
Saldana, et al. Expires April 9, 2015 [Page 11]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-12" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
When using an omnidirectional antenna outdoors to provide
connectivity to a large area, people often select high gain antennas
located at the highest structure available to extend the coverage.
In many cases this is counterproductive, since a high gain
omnidirectional antenna will have a very narrow beamwidth in the
vertical plane, meaning that clients that are below the plane of the
antenna will receive a very weak signal (and by the reciprocity
property of all antennas, the omni will also receive a feeble signal
from the client). So a moderate gain omnidirectional of about 8 to
10 dBi is normally preferable. Higher gain omnis antennas are only
advisable when the farthest way client are roughly in the same plane.
For indoor clients, omnis are generally fine, because the numerous
reflections normally found in indoor environments negate the
advantage of using directive antennas.
For outdoor clients, directive antennas can be quite useful to extend
coverage to an Access Point fitted with an omni.
When building point to point links, the highest gain antennas are the
best choice, since their narrow beamwidth mitigates interference from
other users and can provide the longest links [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Flickenger" rel="nofollow">Flickenger] [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Zennaro" rel="nofollow">Zennaro].
24 to 34 dBi antennas are commercially available at both the
unlicensed 2.4 GHz and 5 GHz bands, and even higher gain antennas can
be found in the newer unlicensed bands at 17 GHz and 24 GHz.
Despite the fact that the free space loss is directly proportional to
the square of the frequency, it is normally advisable to use higher
frequencies for point to point links when there is a clear line of
sight, because it is normally easier to get higher gain antennas at
5 GHz. Deploying high gain antennas at both ends will more than
compensate for the additional free space loss. Furthermore, higher
frequencies can make do with lower altitude antenna placement since
the Fresnel zone is inversely proportional to the square root of the
frequency.
On the contrary, lower frequencies offer advantages when the line of
sight is blocked because they can leverage diffraction to reach the
intended receiver.
It is common to find dual radio Access Points, at two different
frequency bands. One way of benefiting from this arrangement is to
attach a directional antenna to the high frequency radio for
connection to the backbone and an omni to the lower frequency to
provide local access.
Saldana, et al. Expires April 9, 2015 [Page 12]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-13" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
Of course, in the case of mesh networking, where the antenna should
connect to several other nodes, it is better to use omnidirectional
antennas.
Keep also in mind that the same type of polarisation must be used at
both ends of any radio link. For point to point links, some vendor
use two radios operating at the same frequency but with orthogonal
polarisations, thus doubling the achievable throughput, and also
offering added protection to multipath and other transmission
impairments.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.2" rel="nofollow">4.2.2. Link length
For short distance transmission, there is no strict requirement of
line of sight between the transmitter and the receiver, and multipath
can guarantee communication despite the existence of obstacles in the
direct path.
For longer distances, the first requirement is the existence of an
unobstructed line of sight between the transmitter and the receiver.
For very long path the earth curvature is an obstacle that must be
cleared, but the trajectory of the radio beam is not strictly a
straight line due to the bending of the rays as a consequence of non-
uniformities of the atmosphere. Most of the time this bending will
mean that the radio horizon extends further than the optical horizon.
Another factor to be considered is that radio waves occupy a volume
around the optical line, which must be unencumbered from obstacles
for the maximum signal to be captured at the receiver. This volume
is known as the Fresnel ellipsoid and its size grows with the
distance between the end points and with the wavelength of the
signal, which in turn is inversely proportional to the frequency.
So, for optimum signal reception the end points must be high enough
to clear any obstacle in the path and leave extra "elbow room" for
the Fresnel zone. This can be achieved by using suitable masts at
either end, or by taking advantage of existing structures or hills.
Once a clear radio-electric line of sight (including the Fresnel zone
clearance) is obtained, one must ascertain that the received power is
well above the sensitivity of the receiver, by what is known as the
link margin. The greater the link margin, the more reliable the
link. For mission critical applications 20 dB margin is suggested,
but for non critical ones 10 dB might suffice.
Bear in mind that the sensitivity of the receiver decreases with the
transmission speed, so more power is needed at greater transmission
speeds.
Saldana, et al. Expires April 9, 2015 [Page 13]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-14" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
The received power is determined by the transmitted power, the gain
of the transmitting and receiving antennas and the propagation loss.
The propagation loss is the sum of the free space loss (proportional
to the square of the the frequency and the square of the distance),
plus additional factors like attenuation in the atmosphere by gases
or meteorological effects (which are strongly frequency dependent),
multipath and diffraction losses.
Multipath is more pronounced in trajectories over water, if they
cannot be avoided special countermeasures should be taken.
So to achieve a given link margin (also called fade margin), one can:
a) increase the output power. The maximum transmitted power is
specified by the country's regulation, and for unlicensed frequencies
is much lower than for licensed frequencies.
b) Increase the antenna gain. There is no limit in the gain of the
receiving antenna, but high gain antennas are bulkier, present more
wind resistance and require sturdy mounts to comply with tighter
alignment requirements. The transmitter antenna gain is also
regulated and can be different for point to point as for point to
multipoint links. Many countries impose a limit in the combination
of transmitted power and antenna gain, the EIRP (Equivalent
Isotropically Irradiated Power) which can be different for point to
point or point to multipoint links.
c) Reduce the propagation loss, by using a more favourable frequency
or a shorter path.
d) Use a more sensitive receiver. Receiver sensitivity can be
improved by using better circuits, but it is ultimately limited by
the thermal noise, which is proportional to temperature and
bandwidth. So one can increase the sensitivity by using a smaller
receiving bandwidth, or by settling to lower throughput even in the
same receiver bandwidth. This step is often done automatically in
many protocols, in which the transmission speed can be reduced say
from 150 Mbit/s to 6 Mbit/s if the receiver power is not enough to
sustain the maximum throughput.
A completely different limiting factor is related with the medium
access protocol. WiFi was designed for short distance, and the
transmitter expects the reception of an acknowledgment for each
transmitted packet in a certain amount of time, if the waiting time
is exceeded, the packet is retransmitted. This will reduce
significantly the throughput at long distance, so for long distance
application it is better to use a different medium access technique,
Saldana, et al. Expires April 9, 2015 [Page 14]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-15" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
in which the receiver does not wait for an acknowledgement of the
transited packet. This strategy of TDMA (Time Domain Multiple
Access) has been adopted by many equipment vendors who offer
proprietary protocols alongside the standard WiFi in order to
increase the throughput at longer distances. Low cost equipment
using TDMA can offer high throughput at distances over 100
kilometres.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3" rel="nofollow">4.2.3. Layer 2
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.1" rel="nofollow">4.2.3.1. 802.11 (Wi-Fi)
Wireless standards ensure interoperability and usability to those who
design, deploy and manage wireless networks. The Standards used in
the vast majority of Community Networks come from the IEEE Standard
Association's IEEE 802 Working Group.
The standard we are most interested in is 802.11 a/b/g/n, as it
defines the protocol for Wireless LAN. Different 802.11 amendments
have been released, as shown in the table below, also including their
frequencies and approximate ranges.
|802.11| Release | Freq |BWdth | Data Rate per | Approx range (m) |
|prot | date | (GHz)|(MHz) |stream (Mbit/s) | indoor | outdoor |
+------+---------+------+------+----------------+--------+----------+
| a |Sep 1999 | 5 | 20 | 6,9,12, 18, 24,| 35 | 120 |
| | | | | 36, 48, 54 | | |
| b |Sep 1999 | 2.4 | 20 | 1, 2, 5.5, 11 | 35 | 140 |
| g |Jun 2003 | 2.4 | 20 | 6,9,12, 18, 24,| 38 | 140 |
| | | | | 36, 48, 54 | | |
| n |Oct 2009 | 2.4/5| 20 | 7.2, 14.4, 21.7| 70 | 250 |
| | | | | 28.9, 43.3, | | |
| | | | | 57.8, 65, 72.2 | | |
| n |Oct 2009 | 2.4/5| 40 | 15, 30, 45, 60,| 70 | 250 |
| | | | | 90, 120, | | |
| | | | | 135, 150 | | |
| ac |Nov 2011 | 5 | 20 | Up to 87.6 | | |
| ac |Nov 2011 | 5 | 40 | Up to 200 | | |
| ac |Nov 2011 | 5 | 80 | Up to 433.3 | | |
| ac |Nov 2011 | 5 | 160 | Up to 866.7 | | |
In 2012 IEEE issued the 802.11-2012 Standard that consolidates all
the previous amendments. The document is freely downloadable from
IEEE standards [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-IEEE" rel="nofollow">IEEE].
Saldana, et al. Expires April 9, 2015 [Page 15]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-16" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.1.1" rel="nofollow">4.2.3.1.1. Deployment planning for 802.11 wireless networks
Before packets can be forwarded and routed to the Internet, layers
one (the physical) and two (the data link) need to be connected.
Without link local connectivity, network nodes cannot talk to each
other and route packets.
To provide physical connectivity, wireless network devices must
operate in the same part of the radio spectrum. This means that
802.11a radios will talk to 802.11a radios at around 5 GHz, and
802.11b/g radios will talk to other 802.11b/g radios at around 2.4
GHz. But an 802.11a device cannot interoperate with an 802.11b/g
device, since they use completely different parts of the
electromagnetic spectrum. More specifically, wireless interfaces
must agree on a common channel. If one 802.11b radio card is set to
channel 2 while another is set to channel 11, then the radios cannot
communicate with each other.
When two wireless interfaces are configured to use the same protocol
on the same radio channel, then they are ready to negotiate data link
layer connectivity. Each 802.11a/b/g device can operate in one of
four possible modes:
1.Master mode (also called AP or infrastructure mode) is used to
create a service that looks like a traditional access point. The
wireless interface creates a network with a specified name (called
the SSID) and channel, and offers network services on it. While in
master mode, wireless interfaces manage all communications related to
the network (authenticating wireless clients, handling channel
contention, repeating packets, etc.) Wireless interfaces in master
mode can only communicate with interfaces that are associated with
them in managed mode.
2.Managed mode is sometimes also referred to as client mode.
Wireless interfaces in managed mode will join a network created by a
master, and will automatically change their channel to match it.
They then present any necessary credentials to the master, and if
those credentials are accepted, they are said to be associated with
the master. Managed mode interfaces do not communicate with each
other directly, and will only communicate with an associated master.
3.Ad-hoc mode creates a multipoint-to-multipoint network where there
is no single master node or AP. In ad-hoc mode, each wireless
interface communicates directly with its neighbours. Nodes must be
in range of each other to communicate, and must agree on a network
name and channel. Ad-hoc mode is often also called Mesh Networking.
Saldana, et al. Expires April 9, 2015 [Page 16]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
4.Monitor mode is used by some tools (such as Kismet) to passively
listen to all radio traffic on a given channel. When in monitor mode,
wireless interfaces transmit no data. This is useful for analysing
problems on a wireless link or observing spectrum usage in the local
area. Monitor mode is not used for normal communications.
When implementing a point-to-point or point-to-multipoint link, one
radio will typically operate in master mode, while the other(s)
operate in managed mode. In a multipoint-to-multipoint mesh, the
radios all operate in ad-hoc mode so that they can communicate with
each other directly. Remember that managed mode clients cannot
communicate with each other directly, so it is likely that you will
want to run a high repeater site in master or ad-hoc mode. Ad-hoc is
more flexible but has a number of performance issues as compared to
using the master / managed modes.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.1.2" rel="nofollow">4.2.3.1.2. 802.11af (TVWS)
Some Alternative Networks make use of TV White Spaces, using 802.11af
standard. Nevertheless for rural applications the IEEE 802.22 standard
is better suited since it is specifically designed for greater range.
Although current deployments of TV White Spaces have not implemented
the full specifications of 802.22, they are closer to it than to 802.11af.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.2" rel="nofollow">4.2.3.2. GSM
802.11 is not the only layer 2 option to be used in Alternative
Networks. Some of them use mobile technologies as e.g. GSM.
http://timesofindia.indiatimes.com/world/rest-of-world/Ignored-by-big-companies-Mexican-village-creates-its-own-mobile-service/" rel="nofollow">http://timesofindia.indiatimes.com/world/rest-of-world/Ignored-by-
http://timesofindia.indiatimes.com/world/rest-of-world/Ignored-by-big-companies-Mexican-village-creates-its-own-mobile-service/" rel="nofollow">big-companies-Mexican-village-creates-its-own-mobile-service/
articleshow/22094736.cms?referral=PM
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5" rel="nofollow">5. Network and architecture issues
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1" rel="nofollow">5.1. Layer 3
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.1" rel="nofollow">5.1.1. IP addressing
Most known Alternative Networks started in or around the year 2000.
IPv6 was fully specified by then, but almost all Alternative
Networks still use IPv4. A community networks survey [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Avonts" rel="nofollow">Avonts]
indicated that IPv6 rollout presents a challenge to Community Networks.
Most Community Networks use private IPv4 address ranges, as defined
by http://tools.ietf.org/html/rfc1918" rel="nofollow">RFC 1918 [http://tools.ietf.org/html/rfc1918" rel="nofollow">RFC1918]. The motivation for this was the lower cost
and the simplified IP allocation because of the large available
address ranges.
Saldana, et al. Expires April 9, 2015 [Page 17]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2" rel="nofollow">5.1.2. Routing protocols
These networks are composed of possibly different layer 2 devices,
resulting in a mesh of nodes. Connection between different nodes is
not guaranteed, the link stability can vary strongly over time. To
tackle this, some Community Networks use mesh network routing
protocols while other networks use more traditional routing
protocols. Some networks operate multiple routing protocols in
parallel. E.g., they use a mesh protocol inside different islands
and use traditional routing protocols to connect islands.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.1" rel="nofollow">5.1.2.1. Traditional routing protocols
The BGP protocol, as defined by http://tools.ietf.org/html/rfc4271" rel="nofollow">RFC 4271 [http://tools.ietf.org/html/rfc4271" rel="nofollow">RFC4271] is used by a
number of Community Networks, because of its well-studied behavior
and scalability.
For similar reasons, smaller Community Networks opt to run the OSPF
protocol, as defined by http://tools.ietf.org/html/rfc2328" rel="nofollow">RFC 2328 [http://tools.ietf.org/html/rfc2328" rel="nofollow">RFC2328].
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.2" rel="nofollow">5.1.2.2. Mesh routing protocols
A large number of Community Networks use the OLSR routing protocol as
defined in http://tools.ietf.org/html/rfc3626" rel="nofollow">RFC 3626 [http://tools.ietf.org/html/rfc3626" rel="nofollow">RFC3626]. The pro-active link state routing
protocol is a good match with Community Networks because it has good
performance in mesh networks where nodes have multiple interfaces.
The Better Approach To Mobile Adhoc Networking (B.A.T.M.A.N.)
[http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Abolhasan" rel="nofollow">Abolhasan]protocol was developed by members of the Freifunk
community. The protocol handles all routing at layer 2, creating one
bridged network.
Parallel to BGP, some networks also run the BMX6 protocol [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Neumann" rel="nofollow">Neumann].
This is an advanced version of the BATMAN protocol which is based on
IPv6 and tries to exploit the social structure of Community Networks.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2" rel="nofollow">5.2. Upper layers
From crowd shared perspective, and considering just regular TCP
connections during the critical sharing time, the Access Point
offering the service is likely to be the bottleneck of the
connection. This is the main concern of sharers, having several
implications. There should be an adequate Active Queue Management
(AQM) mechanism that implements a Less than Best Effort policy for the
user and protect the sharer. Achieving LBE behaviour requires the
appropriate tuning of the well known mechanisms such as ECN, or RED,
or others more recent AQM mechanisms such as CoDel and PIE that aid
on keeping low latency http://tools.ietf.org/html/rfc6297" rel="nofollow">RFC 6297 [http://tools.ietf.org/html/rfc6297" rel="nofollow">RFC6297].
Saldana, et al. Expires April 9, 2015 [Page 18]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-19" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
The user traffic should not interfere with the sharers traffic.
However, other bottlenecks besides client's access bottleneck may not
be controlled by the previously mentioned protocols. Therefore, recently
proposed transport protocols like LETBAT [reference required] with
the purpose of transporting scavenger traffic may be a solution.
LEDBAT requires the cooperation of both the client and the server to
achieve certain target delay, therefore controlling the impact of the
user along all the path.
There are applications that manage aspects of the network from the
sharer side and from the client side. From sharer's side, there are
applications to centralise the management of the APs conforming the
network that have been recently proposed by means of SDN
[http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Sathiaseelan_a" rel="nofollow">Sathiaseelan_a] [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Suresh" rel="nofollow">Suresh]. There are also other proposals such as
Wi2Me [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Lampropulos" rel="nofollow">Lampropulos] that manage the connection to several Community
Networks from the client's side. This application have shown to
improve the client performance compared to a single-Community Network
client.
On the other hand, transport protocols inside a multiple hop wireless
mesh network are likely to suffer performance degradation for
multiple reasons, e.g., hidden terminal problem, unnecessary delays
on the TCP ACK clocking that decrease the throughout or route
changing [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Hanbali" rel="nofollow">Hanbali]. So, there are some options for network
configuration. The implementation of an easy-to-adopt solution for
TCP over mesh networks may be implemented from two different
perspectives. One way is to use a TCP-proxy to transparently deal
with the different impairments http://tools.ietf.org/html/rfc3135" rel="nofollow">RFC 3135 [http://tools.ietf.org/html/rfc3135" rel="nofollow">RFC3135]. Another way is to
adopt end-to-end solutions for monitoring the connection delay so
that the receiver adapts the TCP reception window (rwnd)
[http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_c" rel="nofollow">Castignani_c]. Similarly, the ACK Congestion Control (ACKCC)
mechanism http://tools.ietf.org/html/rfc5690" rel="nofollow">RFC 5690 [http://tools.ietf.org/html/rfc5690" rel="nofollow">RFC5690] could deal with TCP-ACK clocking
impairments due to inappropriate delay on ACK packets. ACKCC
compensates in an end-to-end fashion the throughput degradation due
to the effect of media contention as well as the unfairness
experienced by multiple uplink TCP flows in a congested WiFi access.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1" rel="nofollow">5.2.1. Services provided by these networks
This section provides an explaining of the services between hosts
inside the network. They can be divided into Intranet services,
connecting hosts between them, and Internet services, connecting to
nodes outside the network.
Saldana, et al. Expires April 9, 2015 [Page 19]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-20" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.1" rel="nofollow">5.2.1.1. Intranet services
- VoIP (e.g. with SIP)
- remote desktop (e.g. using my computer and my Internet connection
when I am on holidays in a village).
- FTP file sharing (e.g. distribution of Linux software).
- P2P file sharing.
- public video cameras.
- DNS.
- online games servers.
- jabber instant messaging.
- IRC chat.
- weather stations.
- NTP.
- Network monitoring.
- videoconferencing / streaming.
- Radio streaming.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.2" rel="nofollow">5.2.1.2. Access to the Internet
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.2.1" rel="nofollow">5.2.1.2.1. Web browsing proxies
A number of federated proxies provide web browsing service for the
users. Other services (file sharing, skype, etc.) are not usually
allowed.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.2.2" rel="nofollow">5.2.1.2.2. Use of VPNs
Some "micro-ISPs" may use the network as a backhaul for providing
Internet access, setting up VPNs from the client to a machine with
Internet access.
Saldana, et al. Expires April 9, 2015 [Page 20]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.3" rel="nofollow">5.3. Topology
These networks follow different topology patterns, as studied in
[http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Vega" rel="nofollow">Vega].
Regularly rural areas in these networks are connected through long-
distance links (the so-called community mesh approach) which in turn
convey the Internet connection to relevant organisations or
institutions. In contrast, in urban areas, users tend to share and
require mobile access. Since these areas are also likely to be
covered by commercial ISPs, the provision of wireless access by
Virtual Operators like FON is the way to extend the user capacity (or
gain connection) to the network. Other proposals like Virtual Public
Networks [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Sathiaseelan_a" rel="nofollow">Sathiaseelan_a] can also extend the service.
As in the case of main Internet Service Providers in France,
Community Networks for urban areas are conceived as a set of APs
sharing a common SSID among the clients favouring the nomadic access.
For users in France, ISPs promise to cause a little impact on their
service agreement when the shared network service is activated on
clients' APs. Nowadays, millions of APs are deployed around the
country performing services of nomadism and 3G offloading, however as
some studies demonstrate, at walking speed, there is a fair chance
of performing file transfers [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_a" rel="nofollow">Castignani_a] [http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_b" rel="nofollow">Castignani_b].
Scenarios studied in France and Luxembourg show that the density of APs in
urban areas (mainly in downtown and residential areas) is quite big and
from different ISPs. Moreover, performed studies reveal that aggregating
available networks can be
beneficial to the client by using an application that manage the best
connection among the different networks. For improving the scanning
process (or topology recognition), which consumes the 90% of the
connection/reconnection process to the Community Network, the client
may implement several techniques for selecting the best AP
[http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_c" rel="nofollow">Castignani_c].
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-6" rel="nofollow">6. Acknowledgements
This work has been partially funded by the CONFINE European
Commission Project (FP7 - 288535).
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-7" rel="nofollow">7. Contributing Authors
Saldana, et al. Expires April 9, 2015 [Page 21]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
L. Aaron Kaplan
Funkfeur
Street
1234 city
Austria
Phone: +43 (0)699 11994786
Email: aaron@lo-res.org
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-8" rel="nofollow">8. IANA Considerations
This memo includes no request to IANA.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-9" rel="nofollow">9. Security Considerations
No security issues have been identified for this document.
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10" rel="nofollow">10. References
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10.1" rel="nofollow">10.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", http://tools.ietf.org/html/bcp5" rel="nofollow">BCP
http://tools.ietf.org/html/bcp5" rel="nofollow">5, http://tools.ietf.org/html/rfc1918" rel="nofollow">RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", http://tools.ietf.org/html/bcp14" rel="nofollow">BCP 14, http://tools.ietf.org/html/rfc2119" rel="nofollow">RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, http://tools.ietf.org/html/rfc2328" rel="nofollow">RFC 2328, April 1998.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", http://tools.ietf.org/html/rfc3135" rel="nofollow">RFC 3135, June 2001.
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol (OLSR)", http://tools.ietf.org/html/rfc3626" rel="nofollow">RFC 3626, October 2003.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", http://tools.ietf.org/html/rfc4271" rel="nofollow">RFC 4271, January 2006.
[RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding
Acknowledgement Congestion Control to TCP", http://tools.ietf.org/html/rfc5690" rel="nofollow">RFC 5690,
February 2010.
[RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort
Transport Protocols", http://tools.ietf.org/html/rfc6297" rel="nofollow">RFC 6297, June 2011.
Saldana, et al. Expires April 9, 2015 [Page 22]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-23" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10.2" rel="nofollow">10.2. Informative References
[Abolhasan]
Abolhasan, M., Hagelstein, B., and J. Wang, "Real-world
performance of current proactive multi-hop mesh
protocols", In Communications, 2009. APCC 2009. 15th Asia-
Pacific Conference on (pp. 44-47). IEEE. , 2009.
[Avonts] Avonts, J., Braem, B., and C. Blondia, "A Questionnaire
based Examination of Community Networks", Proceedings
Wireless and Mobile Computing, Networking and
Communications (WiMob), 2013 IEEE 8th International
Conference on (pp. 8-15) , 2013.
[Braem] Braem, B., Baig Vinas, R., Kaplan, A., Neumann, A., Vilata
i Balaguer, I., Tatum, B., Matson, M., Blondia, C., Barz,
C., Rogge, H., Freitag, F., Navarro, L., Bonicioli, J.,
Papathanasiou, S., and P. Escrich, "A case for research
with and on community networks", ACM SIGCOMM Computer
Communication Review vol. 43, no. 3, pp. 68-73, 2013.
[Castignani_a]
Castignani, G., Loiseau, L., and N. Montavont, "An
Evaluation of IEEE 802.11 Community Networks Deployments",
Information Networking (ICOIN), 2011 International
Conference on , vol., no., pp.498,503, 26-28 , 2011.
[Castignani_b]
Castignani, G., Monetti, J., Montavont, N., Arcia-Moret,
A., Frank, R., and T. Engel, "A Study of Urban IEEE 802.11
Hotspot Networks: Towards a Community Access Network",
Wireless Days (WD), 2013 IFIP , pp.1,8, 13-15 , 2013.
[Castignani_c]
Castignani, G., Arcia-Moret, A., and N. Montavont, "A
study of the discovery process in 802.11 networks",
SIGMOBILE Mob. Comput. Commun. Rev., vol. 15, no. 1, p. 25
, 2011.
[Flickenger]
Flickenger, R., Okay, S., Pietrosemoli, E., Zennaro, M.,
and C. Fonda, "Very Long Distance Wi-Fi Networks", NSDR
2008, The Second ACM SIGCOMM Workshop on Networked Systems
for Developing Regions. USA, 2008 , 2008.
[Hanbali] Hanbali, A., Altman, E., and P. Nain, "A Survey of TCP
over Ad Hoc Networks", IEEE Commun. Surv. Tutorials, vol.
7, pp. 22-36 , 2005.
Saldana, et al. Expires April 9, 2015 [Page 23]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-24" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
[Heer] Heer, T., Hummen, R., Viol, N., Wirtz, H., Gotz, S., and
K. Wehrle, "Collaborative municipal Wi-Fi networks-
challenges and opportunities", Pervasive Computing and
Communications Workshops (PERCOM Workshops), 2010 8th IEEE
International Conference on (pp. 588-593). IEEE. , 2010.
[IEEE] Institute of Electrical and Electronics Engineers, IEEE,
"IEEE Standards association", 2012.
[Lampropulos]
Lampropulos, A., Castignani, G., Blanc, A., and N.
Montavont, "Wi2Me: A Mobile Sensing Platform for Wireless
Heterogeneous Networks", 32nd International Conference on
Distributed Computing Systems Workshops (ICDCS Workshops),
2012, pp. 108-113 , 2012.
[Neumann] Neumann, A., Lopez, E., and L. Navarro, "An evaluation of
bmx6 for community wireless networks", In Wireless and
Mobile Computing, Networking and Communications (WiMob),
2012 IEEE 8th International Conference on (pp. 651-658).
IEEE. , 2012.
[PAWS] Sathiaseelan, A., Crowcroft, J., Goulden, M.,
Greiffenhagen, C., Mortier, R., Fairhurst, G., and D.
McAuley, "Public Access WiFi Service (PAWS)", Digital
Economy All Hands Meeting, Aberdeen , Oct 2012.
[Pietrosemoli]
Pietrosemoli, E., Zennaro, M., and C. Fonda, "Low cost
carrier independent telecommunications infrastructure", In
proc. 4th Global Information Infrastructure and Networking
Symposium, Choroni, Venezuela , 2012.
[Rendon] Rendon, A., Ludena, P., and A. Martinez Fernandez,
"Tecnologias de la Informacion y las Comunicaciones para
zonas rurales Aplicacion a la atencion de salud en paises
en desarrollo", CYTED. Programa Iberoamericano de Ciencia
y Tecnologia para el Desarrollo , 2011.
[Samanta] Samanta, V., Knowles, C., Wagmister, J., and D. Estrin,
"Metropolitan Wi-Fi Research Network at the Los Angeles
State Historic Park", The Journal of Community
Informatics, North America, 4 , May 2008.
Saldana, et al. Expires April 9, 2015 [Page 24]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-25" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
[Sathiaseelan_a]
Sathiaseelan, A., Rotsos, C., Sriram, C., Trossen, D.,
Papadimitriou, P., and J. Crowcroft, "Virtual Public
Networks", In Software Defined Networks (EWSDN), 2013
Second European Workshop on (pp. 1-6). IEEE. , 2013.
[Sathiaseelan_b]
Sathiaseelan, A. and J. Crowcroft, "LCD-Net: Lowest Cost
Denominator Networking", ACM SIGCOMM Computer
Communication Review , Apr 2013.
[Suresh] Suresh, L., Schulz-Zander, J., Merz, R., Feldmann, A., and
T. Vazao, "Towards Programmable Enterprise WLANs with
ODIN", In Proceedings of the first workshop on Hot topics
in software defined networks (HotSDN '12). ACM, New York,
NY, USA, 115-120 , 2012.
[Vega] Vega, D., Cerda-Alabern, L., Navarro, L., and R. Meseguer,
"Topology patterns of a community network: Guifi. net.",
Proceedings Wireless and Mobile Computing, Networking and
Communications (WiMob), 2012 IEEE 8th International
Conference on (pp. 612-619) , 2012.
[WNDW] Wireless Networking in the Developing World/Core
Contributors, "Wireless Networking in the Developing
World, 3rd Edition", The WNDW Project, available at
http://wndw.net" rel="nofollow">wndw.net , 2013.
[WSIS] International Telecommunications Union, ITU, "Declaration
of Principles. Building the Information Society: A global
challenge in the new millenium", World Summit on the
Information Society, 2003, at http://www.itu.int/wsis" rel="nofollow">http://www.itu.int/wsis,
accessed 12 January 2004. , Dec 2013.
[Zennaro] Zennaro, M., Fonda, C., Pietrosemoli, E., Muyepa, A.,
Okay, S., Flickenger, R., and S. Radicella, "On a long
wireless link for rural telemedicine in Malawi", 6th
International Conference on Open Access, Lilongwe, Malawi
, Nov 2008.
Authors' Addresses
Saldana, et al. Expires April 9, 2015 [Page 25]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-26" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
Jose Saldana (editor)
University of Zaragoza
Dpt. IEC Ada Byron Building
Zaragoza 50018
Spain
Phone: +34 976 762 698
Email: jsaldana@unizar.es
Andres Arcia-Moret
Universidad de Los Andes
Facultad de Ingenieria. Sector La Hechicera
Merida 5101
Venezuela
Phone: +58 274 2402811
Email: andres.arcia@ula.ve
Bart Braem
iMinds
Gaston Crommenlaan 8 (bus 102)
Gent 9050
Belgium
Phone: +32 3 265 38 64
Email: bart.braem@iminds.be
Leandro Navarro
U. Politecnica Catalunya
Jordi Girona, 1-3, D6
Barcelona 08034
Spain
Phone: +34 934016807
Email: leandro@ac.upc.edu
Ermanno Pietrosemoli
Escuela Latinoamericana de Redes
Apartado 514
Merida 5101
Venezuela
ICTP
Via Beirut 7
Trieste 34151
Italy
Phone: +39 040 2240 471
Email: ermanno@ictp.it
Saldana, et al. Expires April 9, 2015 [Page 26]
http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-27" rel="nofollow">
Internet-Draft Alternative Network Deployments October 2014
Carlos Rey-Moreno
University of the Western Cape
Robert Sobukwe road
Bellville 7535
South Africa
Phone: 0027219592562
Email: crey-moreno@uwc.ac.za
Arjuna Sathiaseelan
University of Cambridge
15 JJ Thomson Avenue
Cambridge CB30FD
United Kingdom
Phone: +44 (0)1223 763781
Email: arjuna.sathiaseelan@cl.cam.ac.uk
Marco Zennaro
Abdus Salam ICTP
Strada Costiera 11
Trieste 34100
Italy
Phone: +39 040 2240 406
Email: mzennaro@ictp.it
Saldana, et al. Expires April 9, 2015 [Page 27]
Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/" rel="nofollow">https://tools.ietf.org/tools/rfcmarkup/
On Fri, Nov 7, 2014 at 10:11 AM, Jose Saldana <jsaldana@unizar.es> wrote:
Steve,
I was wondering... perhaps you could contribute two paragraphs about 802.22 for the draft...
Jose
> -----Mensaje original-----
> De: gaia [mailto:gaia-bounces@irtf.org] En nombre de Arjuna Sathiaseelan
> Enviado el: jueves, 06 de noviembre de 2014 20:19
> Para: Steve Song
> CC: gaia
> Asunto: Re: [gaia] Fixes to "Alternative Network Deployments" Internet Draft
>
> Hello Steve,
> I think this is a good suggestion and we should also add 802.22.
>
> Also I think we need to add more details on TVWS. We will work with Marco and
> Ermanno on this.
>
> Thanks once again Steve.
>
> Regards
>
> On 6 November 2014 16:37, Steve Song <stevesong@nsrc.org> wrote:
> > Hi Arjuna,
> >
> > Is there a particular reason that only 802.11af is mentioned when it
> > comes to TVWS? Would it not make sense to include 802.22 alongside
> > 802.1af in section 4.2.3.1.2.
> >
> > Regards... Steve
> >
> >
> > On Thu Nov 06 2014 at 04:30:24 Arjuna Sathiaseelan
> > <arjuna.sathiaseelan@cl.cam.ac.uk> wrote:
> >>
> >> Thanks Ioannis - I would also encourage others to read this draft and
> >> give feedback..
> >>
> >> http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01" target="_blank" rel="nofollow">http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01
> >>
> >> Regards
> >>
> >> On 5 November 2014 16:12, Ioannis Komnios <ikomnios@gmail.com> wrote:
> >> > All,
> >> >
> >> > I have reviewed the “Alternative Network Deployments” Internet
> >> > Draft and I have found several things that could be fixed, in order
> >> > to make the text more concise and readable.
> >> >
> >> > Issues to be considered
> >> > p.4 We should introduce the acronym AN for Alternative Networks,
> >> > since we use it in the document.
> >> > p.5 The Free Network description does not read well here, since it
> >> > MAY be the same as a Community Network. I suggest to create a
> >> > separate sub-section, where we define a Free Network.
> >> > p.5 “The principles of these networks” and p. 6 “These networks grow…”.
> >> > It
> >> > is not clear if we refer to community networks or free networks. We
> >> > should make it clear.
> >> > p.6 “These networks are also called sometimes “Free networks” or
> >> > even “Network Commons.” This is a confusing repetition and should be
> omitted.
> >> > p.7 “The network capacity shared…” This is a repetition, since it
> >> > is already mentioned in the previous paragraph.
> >> > p.6-7 The way crowdshared approaches and user-centric approaches
> >> > are defined right now is a little confusing, since they look really
> >> > similar. We can add some examples of each case to highlight the
> >> > differences.
> >> > p.7 FON missing reference: https://corp.fon.com/en" target="_blank" rel="nofollow">https://corp.fon.com/en
> >> > p.8 The bullets that describe the actors in user-centric networks
> >> > start abruptly. We should first add a sentence like “The actors
> >> > involved in a user-centric network are summarised below:”
> >> > p.8 We should define ISP and ASP acronyms when we first use them.
> >> > p.8 We should rename Section 2.4 Testbeds to Testbeds for research
> >> > purposes to make it more clear.
> >> > p.8 Section 3.1 mostly describes developing countries and digital
> >> > divide, not network deployment scenarios. For this reason, we could
> >> > rename this section “Digital Divide”. We can also add a reference
> >> > to the Digital Agenda Europe (http://ec.europa.eu/digital-agenda/" target="_blank" rel="nofollow">http://ec.europa.eu/digital-agenda/)
> >> > p.11 We should add a reference to dwellers that share the cost of
> >> > the infrastructure ant the gateway and access it via inexpensive
> >> > wireless devices.
> >> > p.11 We refer to scarce technical skills as a problem to rural areas.
> >> > The
> >> > same problem exists in developing countries, as well.
> >> > p.11 There is no need for a subsection 4.1.1. since it is the only one.
> >> > We
> >> > should re-write this paragraph more formally and move the reference
> >> > to the end of the document.
> >> > p.11 Add one more introductory sentence to Section 4.2. “Below we
> >> > summarise topics to be considered in such deployments.”
> >> > p.11 We first refer to Fresnel zone in p.11, but we describe it in p.12.
> >> > This explanation should be moved here.
> >> > p.13 Section 4.2.2. Link Length could be further split into three
> >> > subsections: Line-of-Sight, Transmitted and Received Power and
> >> > Medium Access Protocol.
> >> > p.17 Section 4.2.3.2. GMS should be re-written like “GSM has also
> >> > been used in Alternative Networks as layer 2 option.” and reference
> >> > should be moved to the end of the document.
> >> > p.19 When we refer to LEDBAT we can add the following two
> >> > publications that summarise some important LEDBAT issues:
> >> > -D.Ros and M. Welzl, “Assessing LEDBAT’s delay impact”,
> >> > Communication Letters, IEEE, vol. 17, no. 5, pp. 1044-1047, May 2013.
> >> > -I. Komnios, A. Sathiaseelan and J. Crowcroft, “LEDBAT performance
> >> > in subpacket regimes”, IEEE/IFIP WONS, Austria, April 2014.
> >> > p.19 Rename Section 5.2.1. "Services provided by these networks” to
> >> > “Services provided by alternative networks”
> >> > p.20 We should add an introduction to Section 5.2.1.1. such as
> >> > “Intranet services can include, but are not limited to:”. And also
> >> > make the first letter of each bullet capital.
> >> >
> >> > Typos and others
> >> > p.1 and p.4: “as well as providing Internet” -> “as well as Internet”
> >> > p.2 “network models as e.g., community networks” -> “network models
> >> > such as community networks”
> >> > p.4 “In line with this objective this” -> “In line with this
> >> > objective, this”
> >> > p.4 “Each of them have” -> “Each of them has”
> >> > p.4 “as well as technological” -> “as well as the technological”
> >> > p.5 “a obvious” -> “an obvious"
> >> > p.5 “Freedom 0 - Freedom” -> “Freedom 0 - The freedom”
> >> > p.5 “most reusable forms.” ” -> “most reusable forms. ”
> >> > p.5 “as long as you don’t harm” -> “as long as you do not harm”
> >> > p. 6 “to be normally used” -> “is normally used”
> >> > p.6 “as e.g. Less-than-best-effort” -> “as Less-than-best-effort”
> >> > p.7 “an people can” -> “and people can”
> >> > p.8 “ “Interest” “ -> “ Interest “
> >> > p.8 “The Virtual Operator: entity that” -> “The Virtual Operator (VO):
> >> > An
> >> > entity that”
> >> > p.8 “This section discusses the scenarios where alternative
> >> > networks are interesting or have been deployed.” -> “This section
> >> > discusses scenarios, where alternative networks have been
> >> > deployed."
> >> > p.9 “worried of being left behind” -> “in order not to be left behind”
> >> > p.9 “peoples” -> “people”
> >> > p.10 “Although it is undeniable the contribution… access gap,” ->
> >> > “Although the contribution… access gap is undeniable,”
> >> > p.10 “they do not deemed them profitable” -> “they do not deem them
> >> > profitable”
> >> > p.11 “stability and to that of the services” -> “stability and the
> >> > services”
> >> > p.11 “off-the-self” -> “off-the-shelf”
> >> > p.12 “omnis” -> “omnidirectional antennas”
> >> > p.12 “So a moderate gain” -> “A moderate gain”
> >> > p.13 “Of course, in the case of” -> “In the case of”
> >> > p.13 “Keep also in mind that the same type” -> “The same type”
> >> > p.13 “some vendor use” -> “some vendors use”
> >> > p.13 “So, for optimum” -> “For optimum”
> >> > p.13 “Bear in mind that the sensitivity” -> “The sensitivity”
> >> > p.14 “over water, if they cannot” -> “over water. If they cannot”
> >> > p.14 “So to achieve” -> “In order to achieve”
> >> > p.14 “a) increase the output power.The maximum” -> “a) Increase the
> >> > output power. The maximum”
> >> > p.14 “the EIRP (Equivalent Isotropically Irradiated Power)” ->
> >> > “Equivalent Isotropically Radiated Power (EIRP)”
> >> > p.14 “So one can increase” -> “One can increase"
> >> > p.14 “can be reduced say from” -> “can be reduced from”
> >> > p.14 “is related with the medium” -> “is related to the medium”
> >> > p.14 “This will reduce significantly the” -> “This will
> >> > significantly reduce the”
> >> > p.16 “This is means” -> “This means”
> >> > p.16 “they are said to be associated” -> “they are associated”
> >> > p.16 “and will only communicate” -> “and only communicate”
> >> > p.17 “Remember that managed mode” -> “Managed mode”
> >> > p.17 “so it is likely that you will want to run a high repeater
> >> > site” -> “so a high repeater site is required”
> >> > p.17 “but most almost” -> “but almost”
> >> > p.18 “These networks are composed of” -> “Alternative Networks are
> >> > typically composed of”
> >> > p.18 “not guaranteed, the link stability” -> “not guaranteed and
> >> > the link stability”
> >> > p.18 “E.g., they use” -> “For example, they use”
> >> > p.18 “From crowd shared perspective and considering just regular”
> >> > -> “From crowdshared perspective and considering only regular”
> >> > p.18 “that implement a” -> “that implements a”
> >> > p.18 “and protect the sharer” -> “and protects the sharer.”
> >> > p.18 “requieres” -> “requires”
> >> > p.19 “And so, recently” -> “Recently”
> >> > p.19 “LETBAT" -> “LEDBAT"
> >> > p.19 “This application have shown” -> “These applications have shown”
> >> > p.19 “So, there are some” -> “There are some”
> >> > p.19 “explaining” -> “explanation”
> >> > p.21 “These networks follow” -> “Alternative networks follow”
> >> > p.21 “that manage the best” -> “that manages the best"
> >> >
> >> > Ioannis
> >> >
> >> > _______________________________________________
> >> > gaia mailing list
> >> > gaia@irtf.org
> >> > https://irtf.org/mailman/listinfo/gaia" target="_blank" rel="nofollow">https://irtf.org/mailman/listinfo/gaia
> >> >
> >>
> >>
> >>
> >> --
> >> Arjuna Sathiaseelan | http://www.cl.cam.ac.uk/%7Eas2330/" target="_blank" rel="nofollow">http://www.cl.cam.ac.uk/~as2330/
> >>
> >> _______________________________________________
> >> gaia mailing list
> >> gaia@irtf.org
> >> https://irtf.org/mailman/listinfo/gaia" target="_blank" rel="nofollow">https://irtf.org/mailman/listinfo/gaia
> >
> >
> > _______________________________________________
> > gaia mailing list
> > gaia@irtf.org
> > https://irtf.org/mailman/listinfo/gaia" target="_blank" rel="nofollow">https://irtf.org/mailman/listinfo/gaia
> >
>
>
>
> --
> Arjuna Sathiaseelan | http://www.cl.cam.ac.uk/%7Eas2330/" target="_blank" rel="nofollow">http://www.cl.cam.ac.uk/~as2330/
>
> _______________________________________________
> gaia mailing list
> gaia@irtf.org
> https://irtf.org/mailman/listinfo/gaia" target="_blank" rel="nofollow">https://irtf.org/mailman/listinfo/gaia
_______________________________________________
gaia mailing list
gaia@irtf.org
https://irtf.org/mailman/listinfo/gaia" target="_blank" rel="nofollow">https://irtf.org/mailman/listinfo/gaia
--
Professor Ermanno Pietrosemoli
Telecommunications/ICT for Development Laboratory (T/ICT4D)
Abdus Salam International Centre for Theoretical Physics, GGH, Via Beirut 7, Trieste 34151 Italyermanno@ictp.it http://wireless.ictp.it/" target="_blank" rel="nofollow">http://wireless.ictp.it
-------
Presidente
Fundación Escuela Latinoamericana de Redes (EsLaRed)
http://www.EsLaRed.net" target="_blank" rel="nofollow">www.EsLaRed.net
_______________________________________________ gaia mailing list gaia@irtf.org https://irtf.org/mailman/listinfo/gaia" rel="nofollow">https://irtf.org/mailman/listinfo/gaia
- [gaia] Fixes to "Alternative Network Deployments"… Ioannis Komnios
- Re: [gaia] Fixes to "Alternative Network Deployme… Arjuna Sathiaseelan
- Re: [gaia] Fixes to "Alternative Network Deployme… Jose Saldana
- Re: [gaia] Fixes to "Alternative Network Deployme… Steve Song
- Re: [gaia] Fixes to "Alternative Network Deployme… Arjuna Sathiaseelan
- Re: [gaia] Fixes to "Alternative Network Deployme… Jose Saldana
- Re: [gaia] Fixes to "Alternative Network Deployme… Ermanno Pietrosemoli
- Re: [gaia] Fixes to "Alternative Network Deployme… Arjuna Sathiaseelan
- Re: [gaia] Fixes to "Alternative Network Deployme… Jose Saldana
- Re: [gaia] Fixes to "Alternative Network Deployme… Prof. Adam Wolisz
- Re: [gaia] Fixes to "Alternative Network Deployme… Jose Saldana
- Re: [gaia] Fixes to "Alternative Network Deployme… Javier Simó
- Re: [gaia] Fixes to "Alternative Network Deployme… Matthew Ford