Subject: [gaia] Fixes to "Alternative Network Deployments" Internet Draft

From: Ioannis Komnios <[email-masked]>
Date: Wed, 5 Nov 2014 18:12:11 +0200

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 <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/ <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

---

From: Arjuna Sathiaseelan <[email-masked]>
Date: Thu, 6 Nov 2014 08:30:13 +0000

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

Regards

On 5 November 2014 16:12, Ioannis Komnios <[email-masked]> 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.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.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
> 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 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/)
> 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.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.
> -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.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.10 “Although it is undeniable the contribution… access gap,” -> “Although
> the contribution… access gap is undeniable,”
> p.18 “From crowd shared perspective and considering just regular” -> “From
> crowdshared perspective and considering only regular”
> _______________________________________________
> gaia mailing list
> [email-masked]
> https://irtf.org/mailman/listinfo/gaia
>

-- 
Arjuna Sathiaseelan | http://www.cl.cam.ac.uk/~as2330/

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 6 Nov 2014 09:33:39 +0100

Thanks a lot, Ioannis! This is really good feedback.
 
Jose
 
De: gaia [mailto:[email-masked]] En nombre de Ioannis Komnios
Enviado el: miércoles, 05 de noviembre de 2014 17:12
Para: [email-masked]
Asunto: [gaia] Fixes to "Alternative Network Deployments" Internet Draft
 
All,

Issues to be considered
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/)
 
Typos and others
 
Ioannis

---

From: Steve Song <[email-masked]>
Date: Thu, 06 Nov 2014 16:37:13 +0000

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 <
[email-masked]> wrote:

> > p.7 “The network capacity shared…” This is a repetition, since it is
> already
> > mentioned in the previous paragraph.
> > p.8 We should rename Section 2.4 Testbeds to Testbeds for research
> purposes
> > to make it more clear.
> > p.19 When we refer to LEDBAT we can add the following two publications
> that
> > summarise some important LEDBAT issues:
> > p.2 “network models as e.g., community networks” -> “network models such
> as
> > community networks”
> > 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 “This will reduce significantly the” -> “This will significantly
> reduce
> > the”
> > p.17 “so it is likely that you will want to run a high repeater site” ->
> “so
> > a high repeater site is required”
> > p.18 “These networks are composed of” -> “Alternative Networks are
> typically
> > composed of”

---

From: Arjuna Sathiaseelan <[email-masked]>
Date: Thu, 6 Nov 2014 19:19:08 +0000

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 <[email-masked]> wrote:
> On Thu Nov 06 2014 at 04:30:24 Arjuna Sathiaseelan
> <[email-masked]> wrote:
>>
>> > p.4 We should introduce the acronym AN for Alternative Networks, since
>> > we
>> > use it in the document.
>> > p.8 “The Virtual Operator: entity that” -> “The Virtual Operator (VO):
>> > An
>> > entity that”
>> > p.18 “not guaranteed, the link stability” -> “not guaranteed and the
>> > link
>> > stability”

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 7 Nov 2014 10:11:27 +0100

Steve,

I was wondering... perhaps you could contribute two paragraphs about 802.22 for the draft...

Jose

> -----Mensaje original-----
> De: gaia [mailto:[email-masked]] 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,
> 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
> 
> > 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
> >
> >
> >> > 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.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.
> >> > 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.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:”
> >> > 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/)
> >> > 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.
> >> > 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.”
> >> > 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.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.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.10 “Although it is undeniable the contribution… access gap,” ->
> >> > “Although the contribution… access gap is undeniable,”
> >> > output power. The maximum”
> >> > “Equivalent Isotropically Radiated Power (EIRP)”
> >> > p.17 “so it is likely that you will want to run a high repeater
> >> > site” -> “so a high repeater site is required”
> >> > typically composed of”
> >> > p.18 “From crowd shared perspective and considering just regular”
> >> > -> “From crowdshared perspective and considering only regular”

---

From: Ermanno Pietrosemoli <[email-masked]>
Date: Fri, 7 Nov 2014 18:10:48 +0100

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
---------

[Docs <http://tools.ietf.org/html/>] [txt
<https://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.txt>|
pdf
<http://tools.ietf.org/pdf/draft-manyfolks-gaia-community-networks-01.txt>|
xml
<http://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.xml>|
html
<http://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.html>]
[Tracker
<https://datatracker.ietf.org/doc/draft-manyfolks-gaia-community-networks>]
[Email
<[email-masked]?subject=draft-manyfolks-gaia-community-networks%20>]
[Diff1
<http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-manyfolks-gaia-community-networks-01.txt>]
[Diff2
<http://tools.ietf.org/rfcdiff?url2=draft-manyfolks-gaia-community-networks-01.txt>]
[Nits
<http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.txt>]

Versions: 00
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-00> 01
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-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>

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 BCP 78 <http://tools.ietf.org/html/bcp78> and BCP 79
<http://tools.ietf.org/html/bcp79>.

   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/.

   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 BCP 78 <http://tools.ietf.org/html/bcp78>
and the IETF Trust's Legal

   Provisions Relating to IETF Documents

   (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 Section 4
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#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>

Internet-Draft       Alternative Network Deployments        October 2014

Table of Contents

   1
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-1>.
Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-3>

     1.1
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-1.1>.
Requirements Language . . . . . . . . . . . . . . . . . .   4
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-4>

   2
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2>.
Classification  . . . . . . . . . . . . . . . . . . . . . . .   4
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-4>

     2.1
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.1>.
Community Networks  . . . . . . . . . . . . . . . . . . .   5
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-5>

     2.2.  Crowdshared approaches, led by the people and third party

           stakeholders  . . . . . . . . . . . . . . . . . . . . . .   6
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-6>

     2.3
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.3>.
User-centric Networks . . . . . . . . . . . . . . . . . .   7
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-7>

     2.4
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.4>.
Testbed . . . . . . . . . . . . . . . . . . . . . . . . .   8
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-8>

   3
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3>.
Scenarios where Alternative Networks are deployed . . . . . .   8
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-8>

     3.1.  Alternative Networks depending on the income level of

           each country  . . . . . . . . . . . . . . . . . . . . . .   8
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-8>

     3.2
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3.2>.
Urban vs. rural areas . . . . . . . . . . . . . . . . . .  10
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-10>

   4
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4>.
Technologies employed . . . . . . . . . . . . . . . . . . . .  11
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11>

     4.1
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1>.
Wired . . . . . . . . . . . . . . . . . . . . . . . . . .  11
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11>

       4.1.1
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1.1>.
Optical Fiber . . . . . . . . . . . . . . . . . . . .  11
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11>

     4.2
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2>.
Wireless  . . . . . . . . . . . . . . . . . . . . . . . .  11
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11>

       4.2.1
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.1>.
Antennas  . . . . . . . . . . . . . . . . . . . . . .  11
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11>

       4.2.2
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.2>.
Link length . . . . . . . . . . . . . . . . . . . . .  13
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-13>

       4.2.3
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3>.
Layer 2 . . . . . . . . . . . . . . . . . . . . . . .  15
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-15>

         4.2.3.1
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.1>.
802.11 (Wi-Fi)  . . . . . . . . . . . . . . . . .  15
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-15>

         4.2.3.2
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.2>.
GSM . . . . . . . . . . . . . . . . . . . . . . .  17
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17>

   5
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5>.
Network and architecture issues . . . . . . . . . . . . . . .  17
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17>

     5.1
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1>.
Layer 3 . . . . . . . . . . . . . . . . . . . . . . . . .  17
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17>

       5.1.1
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.1>.
IP addressing . . . . . . . . . . . . . . . . . . . .  17
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17>

       5.1.2
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2>.
Routing protocols . . . . . . . . . . . . . . . . . .  18
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18>

         5.1.2.1
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.1>.
Traditional routing protocols . . . . . . . . . .  18
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18>

         5.1.2.2
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.2>.
Mesh routing protocols  . . . . . . . . . . . . .  18
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18>

     5.2
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2>.
Upper layers  . . . . . . . . . . . . . . . . . . . . . .  18
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18>

       5.2.1
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1>.
Services provided by these networks . . . . . . . . .  19
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-19>

         5.2.1.1
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.1>.
Intranet services . . . . . . . . . . . . . . . .  20
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-20>

         5.2.1.2
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.2>.
Access to the Internet  . . . . . . . . . . . . .  20
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-20>

     5.3
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.3>.
Topology  . . . . . . . . . . . . . . . . . . . . . . . .  21
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21>

   6
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-6>.
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21>

   7
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-7>.
Contributing Authors  . . . . . . . . . . . . . . . . . . . .  21
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21>

   8
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-8>.
IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22>

   9
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-9>.
Security Considerations . . . . . . . . . . . . . . . . . . .  22
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22>

   10
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10>.
References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22>

     10.1
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10.1>.
Normative References . . . . . . . . . . . . . . . . . .  22
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22>

     10.2
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10.2>.
Informative References . . . . . . . . . . . . . . . . .  23
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-23>

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-25>

*1*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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>

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 [Pietrosemoli
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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.

*1.1*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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 RFC 2119
<http://tools.ietf.org/html/rfc2119> [RFC2119
<http://tools.ietf.org/html/rfc2119>].

*2*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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, RFC1918 <http://tools.ietf.org/html/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>

Internet-Draft       Alternative Network Deployments        October 2014

*2.1*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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) 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) 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>

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 [Braem
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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.

*2.2*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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>

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 [PAWS
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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

   [Sathiaseelan_a
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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 [Sathiaseelan_b
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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.

*2.3*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.3>*.
User-centric Networks*

   A first example is constituted by the networks created and managed by
City Councils

   (e.g., [Heer
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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>

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.

*2.4*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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 [Samanta
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Samanta>
].

*3*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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.

*3.1*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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>

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" [WSIS
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-WSIS>
],

   and called upon "governments, private sector, civil society and

   international organisations" to actively engage to accomplish it

   [WSIS
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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>

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 [Rendon
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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.

*3.2*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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>

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.

*4*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4>*.
Technologies employed*

*4.1*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1>*.
Wired*

   Some of the wired technologies employed in ANs are:

*4.1.1*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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-
<http://www.fiberopticmania.com/blogs/details/948/lowenstedt-villagers-built-own-fiber-optic-network#sthash.rolFITEo.dpuf>

   villagers-built-own-fiber-optic-network#sthash.rolFITEo.dpuf
<http://www.fiberopticmania.com/blogs/details/948/lowenstedt-villagers-built-own-fiber-optic-network#sthash.rolFITEo.dpuf>

   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>

   German-villagers-set-up-their-own-broadband-network.html
<http://www.telegraph.co.uk/news/worldnews/europe/germany/10871150/German-villagers-set-up-their-own-broadband-network.html>

*4.2*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2>*.
Wireless*

   Different wireless technologies [WNDW
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-WNDW>]
can be employed in Alternative

   Network Deployments.

*4.2.1*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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>

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 [Flickenger
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Flickenger>]
[Zennaro
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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>

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.

*4.2.2*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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>

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>

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.

*4.2.3*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3>*.
Layer 2*

*4.2.3.1*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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 [IEEE
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-IEEE>
].

Saldana, et al.           Expires April 9, 2015                [Page 15]

<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-16>

Internet-Draft       Alternative Network Deployments        October 2014

*4.2.3.1.1*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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>

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.

*4.2.3.1.2*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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.

*4.2.3.2*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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-
<http://timesofindia.indiatimes.com/world/rest-of-world/Ignored-by-big-companies-Mexican-village-creates-its-own-mobile-service/>

   big-companies-Mexican-village-creates-its-own-mobile-service/
<http://timesofindia.indiatimes.com/world/rest-of-world/Ignored-by-big-companies-Mexican-village-creates-its-own-mobile-service/>

   articleshow/22094736.cms?referral=PM

*5*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5>*.
Network and architecture issues*

*5.1*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1>*.
Layer 3*

*5.1.1*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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 [Avonts
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Avonts>
]

   indicated that IPv6 rollout presents a challenge to Community Networks.

   Most Community Networks use private IPv4 address ranges, as defined

   by RFC 1918 <http://tools.ietf.org/html/rfc1918> [RFC1918
<http://tools.ietf.org/html/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>

Internet-Draft       Alternative Network Deployments        October 2014

*5.1.2*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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.

*5.1.2.1*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.1>*.
Traditional routing protocols*

   The BGP protocol, as defined by RFC 4271
<http://tools.ietf.org/html/rfc4271> [RFC4271
<http://tools.ietf.org/html/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 RFC 2328 <http://tools.ietf.org/html/rfc2328> [
RFC2328 <http://tools.ietf.org/html/rfc2328>].

*5.1.2.2*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.2>*.
Mesh routing protocols*

   A large number of Community Networks use the OLSR routing protocol as

   defined in RFC 3626 <http://tools.ietf.org/html/rfc3626> [RFC3626
<http://tools.ietf.org/html/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.)

   [Abolhasan
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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 [Neumann
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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.

*5.2*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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 RFC 6297 <http://tools.ietf.org/html/rfc6297> [
RFC6297 <http://tools.ietf.org/html/rfc6297>].

Saldana, et al.           Expires April 9, 2015                [Page 18]

<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-19>

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

   [Sathiaseelan_a
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Sathiaseelan_a>]
[Suresh
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Suresh>].
There are also other proposals such as

   Wi2Me [Lampropulos
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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 [Hanbali
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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 RFC 3135
<http://tools.ietf.org/html/rfc3135> [RFC3135
<http://tools.ietf.org/html/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)

   [Castignani_c
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_c>].
Similarly, the ACK Congestion Control (ACKCC)

   mechanism RFC 5690 <http://tools.ietf.org/html/rfc5690> [RFC5690
<http://tools.ietf.org/html/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.

*5.2.1*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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>

Internet-Draft       Alternative Network Deployments        October 2014

*5.2.1.1*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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.

*5.2.1.2*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.2>*.
Access to the Internet*

*5.2.1.2.1*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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.

*5.2.1.2.2*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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>

Internet-Draft       Alternative Network Deployments        October 2014

*5.3*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.3>*.
Topology*

   These networks follow different topology patterns, as studied in

   [Vega
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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 [Sathiaseelan_a
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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 [Castignani_a
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_a>]
[Castignani_b
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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

   [Castignani_c
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_c>
].

*6*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-6>*.
Acknowledgements*

   This work has been partially funded by the CONFINE European

   Commission Project (FP7 - 288535).

*7*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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>

Internet-Draft       Alternative Network Deployments        October 2014

   L. Aaron Kaplan

   Funkfeur

   Street

   1234 city

   Austria

   Phone: +43 (0)699 11994786

   Email: [email-masked]

*8*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-8>*.
IANA Considerations*

   This memo includes no request to IANA.

*9*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-9>*.
Security Considerations*

   No security issues have been identified for this document.

*10*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10>*.
References*

*10.1*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10.1>*.
Normative References*

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and

              E. Lear, "Address Allocation for Private Internets", BCP
<http://tools.ietf.org/html/bcp5>

              5 <http://tools.ietf.org/html/bcp5>, RFC 1918
<http://tools.ietf.org/html/rfc1918>, February 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

              Requirement Levels", BCP 14 <http://tools.ietf.org/html/bcp14>,
RFC 2119 <http://tools.ietf.org/html/rfc2119>, March 1997.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328
<http://tools.ietf.org/html/rfc2328>, April 1998.

   [RFC3135]  Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.

              Shelby, "Performance Enhancing Proxies Intended to

              Mitigate Link-Related Degradations", RFC 3135
<http://tools.ietf.org/html/rfc3135>, June 2001.

   [RFC3626]  Clausen, T. and P. Jacquet, "Optimized Link State Routing

              Protocol (OLSR)", RFC 3626
<http://tools.ietf.org/html/rfc3626>, October 2003.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway

              Protocol 4 (BGP-4)", RFC 4271
<http://tools.ietf.org/html/rfc4271>, January 2006.

   [RFC5690]  Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding

              Acknowledgement Congestion Control to TCP", RFC 5690
<http://tools.ietf.org/html/rfc5690>,

              February 2010.

   [RFC6297]  Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort

              Transport Protocols", RFC 6297
<http://tools.ietf.org/html/rfc6297>, June 2011.

Saldana, et al.           Expires April 9, 2015                [Page 22]

<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-23>

Internet-Draft       Alternative Network Deployments        October 2014

*10.2*
<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-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>

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>

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

              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,

              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>

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: [email-masked]

   Andres Arcia-Moret

   Universidad de Los Andes

   Facultad de Ingenieria. Sector La Hechicera

   Merida  5101

   Venezuela

   Phone: +58 274 2402811

   Email: [email-masked]

   Bart Braem

   iMinds

   Gaston Crommenlaan 8 (bus 102)

   Gent  9050

   Belgium

   Phone: +32 3 265 38 64

   Email: [email-masked]

   Leandro Navarro

   U. Politecnica Catalunya

   Jordi Girona, 1-3, D6

   Barcelona  08034

   Spain

   Phone: +34 934016807

   Email: [email-masked]

   Ermanno Pietrosemoli

   Escuela Latinoamericana de Redes

   Apartado 514

   Merida  5101

   Venezuela

   ICTP

   Via Beirut 7

   Trieste 34151

   Italy

   Phone: +39 040 2240 471

   Email: [email-masked]

Saldana, et al.           Expires April 9, 2015                [Page 26]

<http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-27>

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: [email-masked]

   Arjuna Sathiaseelan

   University of Cambridge

   15 JJ Thomson Avenue

   Cambridge  CB30FD

   United Kingdom

   Phone: +44 (0)1223 763781

   Email: [email-masked]

   Marco Zennaro

   Abdus Salam ICTP

   Strada Costiera 11

   Trieste  34100

   Italy

   Phone: +39 040 2240 406

   Email: [email-masked]

Saldana, et al.           Expires April 9, 2015                [Page 27]

Html markup produced by rfcmarkup 1.109, available from
https://tools.ietf.org/tools/rfcmarkup/

On Fri, Nov 7, 2014 at 10:11 AM, Jose Saldana <[email-masked]> wrote:

> > >> > p.5 “The principles of these networks” and p. 6 “These networks
> grow…”.
> > >> > It
> > >> > p.11 We refer to scarce technical skills as a problem to rural
> areas.
> > >> > The
> > >> > p.11 There is no need for a subsection 4.1.1. since it is the only
> one.
> > >> > We
> > >> > p.11 We first refer to Fresnel zone in p.11, but we describe it in
> p.12.
> > >> > This explanation should be moved here.

-- 
Professor Ermanno Pietrosemoli
Telecommunications/ICT for Development Laboratory (T/ICT4D)
Abdus Salam International Centre for Theoretical Physics, GGH, Via Beirut
7, Trieste 34151 Italy
[email-masked]       http://wireless.ictp.it
-------
Presidente
Fundación Escuela Latinoamericana de Redes (EsLaRed)
www.EsLaRed.net

---

From: Arjuna Sathiaseelan <[email-masked]>
Date: Fri, 7 Nov 2014 20:14:05 +0000

Thanks Ermanno,

Should we also write more on TVWS - about geolocation databases and why
using proprietary databases may not be the right way forward to connect
rural areas in developing regions - and whether cognitive sensing could be
used because there is enough spectrum along with the spectrum masking
details etc?.

Or do you think it will be too much for this document..

Regards
Arjuna
On 7 Nov 2014 17:11, "Ermanno Pietrosemoli" <[email-masked]> wrote:

> <https://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.txt>
> |pdf
> <http://tools.ietf.org/pdf/draft-manyfolks-gaia-community-networks-01.txt>
> |xml
>    Scenarios studied in France and Luxembourg show that the density of
> APs in
>
>               Requirement Levels", BCP 14
> <http://tools.ietf.org/html/bcp14>, RFC 2119
> <http://tools.ietf.org/html/rfc2119>, March 1997.
>
>
>               Acknowledgement Congestion Cont
> ...

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 10 Nov 2014 15:01:50 +0100

Ermanno, thanks a lot for the feedback!.
 
If everyone agrees, we can discuss the "Alternative Network Deployments" draft in the list for two more weeks, and then we could try to write a new version of the draft during the week 24th-28th November.
 
Best regards,
 
Jose
 
De: [email-masked] [mailto:[email-masked]] En nombre de Arjuna Sathiaseelan
Enviado el: viernes, 07 de noviembre de 2014 21:14
Para: Ermanno Pietrosemoli
CC: Steve Song; Jose Saldana; gaia
Asunto: Re: [gaia] Fixes to "Alternative Network Deployments" Internet Draft
 
Thanks Ermanno,
Should we also write more on TVWS - about geolocation databases and why using proprietary databases may not be the right way forward to connect rural areas in developing regions - and whether cognitive sensing could be used because there is enough spectrum along with the spectrum masking details etc?.
Or do you think it will be too much for this document..
Regards
Arjuna
On 7 Nov 2014 17:11, "Ermanno Pietrosemoli" <[email-masked]> wrote:
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
---------

[Docs <http://tools.ietf.org/html/> ] [txt <https://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.txt> |pdf <http://tools.ietf.org/pdf/draft-manyfolks-gaia-community-networks-01.txt> |xml <http://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.xml> |html <http://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.html> ] [Tracker <https://datatracker.ietf.org/doc/draft-manyfolks-gaia-community-networks> ] [Email <mailto:[email-masked]?subject=draft-manyfolks-gaia-community-networks%20> ] [Diff1 <http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-manyfolks-gaia-community-networks-01.txt> ] [Diff2 <http://tools.ietf.org/rfcdiff?url2=draft-manyfolks-gaia-community-networks-01.txt> ] [Nits <http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.txt> ]      
                                                                        
Versions: 00 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-00>  01 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01>                                                          

    Alternative Network Deployments.  Taxonomy and characterization
               draft-manyfolks-gaia-community-networks-01
 
Abstract

 

 
Status of This Memo
 
   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 <http://tools.ietf.org/html/bcp78>  and BCP 79 <http://tools.ietf.org/html/bcp79> .

 
 
Copyright Notice

   This document is subject to BCP 78 <http://tools.ietf.org/html/bcp78>  and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (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 Section 4 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4> .e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

 

Table of Contents
 
   1 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-1> .  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-3> 
     1.1 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-1.1> .  Requirements Language . . . . . . . . . . . . . . . . . .   4 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-4> 
   2 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2> .  Classification  . . . . . . . . . . . . . . . . . . . . . . .   4 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-4> 
     2.1 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.1> .  Community Networks  . . . . . . . . . . . . . . . . . . .   5 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-5> 
     2.2.  Crowdshared approaches, led by the people and third party
           stakeholders  . . . . . . . . . . . . . . . . . . . . . .   6 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-6> 
     2.3 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.3> .  User-centric Networks . . . . . . . . . . . . . . . . . .   7 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-7> 
     2.4 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.4> .  Testbed . . . . . . . . . . . . . . . . . . . . . . . . .   8 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-8> 
   3 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3> .  Scenarios where Alternative Networks are deployed . . . . . .   8 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-8> 
     3.1.  Alternative Networks depending on the income level of
           each country  . . . . . . . . . . . . . . . . . . . . . .   8 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-8> 
     3.2 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3.2> .  Urban vs. rural areas . . . . . . . . . . . . . . . . . .  10 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-10> 
   4 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4> .  Technologies employed . . . . . . . . . . . . . . . . . . . .  11 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11> 
     4.1 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1> .  Wired . . . . . . . . . . . . . . . . . . . . . . . . . .  11 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11> 
       4.1.1 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1.1> .  Optical Fiber . . . . . . . . . . . . . . . . . . . .  11 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11> 
     4.2 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2> .  Wireless  . . . . . . . . . . . . . . . . . . . . . . . .  11 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11> 
       4.2.1 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.1> .  Antennas  . . . . . . . . . . . . . . . . . . . . . .  11 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11> 
       4.2.2 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.2> .  Link length . . . . . . . . . . . . . . . . . . . . .  13 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-13> 
       4.2.3 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3> .  Layer 2 . . . . . . . . . . . . . . . . . . . . . . .  15 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-15> 
         4.2.3.1 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.1> .  802.11 (Wi-Fi)  . . . . . . . . . . . . . . . . .  15 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-15> 
         4.2.3.2 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.2> .  GSM . . . . . . . . . . . . . . . . . . . . . . .  17 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17> 
   5 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5> .  Network and architecture issues . . . . . . . . . . . . . . .  17 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17> 
     5.1 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1> .  Layer 3 . . . . . . . . . . . . . . . . . . . . . . . . .  17 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17> 
       5.1.1 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.1> .  IP addressing . . . . . . . . . . . . . . . . . . . .  17 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17> 
       5.1.2 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2> .  Routing protocols . . . . . . . . . . . . . . . . . .  18 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18> 
         5.1.2.1 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.1> .  Traditional routing protocols . . . . . . . . . .  18 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18> 
         5.1.2.2 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.2> .  Mesh routing protocols  . . . . . . . . . . . . .  18 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18> 
     5.2 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2> .  Upper layers  . . . . . . . . . . . . . . . . . . . . . .  18 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18> 
       5.2.1 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1> .  Services provided by these networks . . . . . . . . .  19 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-19> 
         5.2.1.1 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.1> .  Intranet services . . . . . . . . . . . . . . . .  20 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-20> 
         5.2.1.2 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.2> .  Access to the Internet  . . . . . . . . . . . . .  20 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-20> 
     5.3 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.3> .  Topology  . . . . . . . . . . . . . . . . . . . . . . . .  21 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21> 
   6 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-6> .  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21> 
   7 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-7> .  Contributing Authors  . . . . . . . . . . . . . . . . . . . .  21 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21> 
   8 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-8> .  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22> 
   9 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-9> .  Security Considerations . . . . . . . . . . . . . . . . . . .  22 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22> 
   10 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10> . References  . . . . . . . . . . . . . . . . . . . . . . . . .  22 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22> 
     10.1 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10.1> .  Normative References . . . . . . . . . . . . . . . . . .  22 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22> 
     10.2 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10.2> .  Informative References . . . . . . . . . . . . . . . . .  23 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-23> 
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-25> 
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-1> 1.  Introduction

 

   rural/remote areas [Pietrosemoli <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Pietrosemoli> ].  In these cases, the networks have

 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-1.1> 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 RFC 2119 <http://tools.ietf.org/html/rfc2119>  [RFC2119 <http://tools.ietf.org/html/rfc2119> ].
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2> 2.  Classification

   IPv6, RFC1918 <http://tools.ietf.org/html/rfc1918> , OLSR, BMX6, etc.) coexist.

 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.1> 2.1.  Community Networks

 

 
 
   A definition of Free Network (which MAY be the same as Community
   Network) is proposed by the Free Network Foundation (see
   http://thefnf.org <http://thefnf.org/> ) as:

 

 

 

 

   Network is described in [Braem <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Braem> ].  These networks are effective in

 
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.2> 2.2.  Crowdshared approaches, led by the people and third party
      stakeholders

 

   scavenger traffic), to be employed by any user of the service in the
   immediate area.  An example is described in [PAWS <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-PAWS> ].
 
   [Sathiaseelan_a <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Sathiaseelan_a> ].

 
 
   - Network operators, who have a financial incentive to lease out the
   unused capacity [Sathiaseelan_b <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Sathiaseelan_b> ] at lower cost to the VNOs.

 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.3> 2.3.  User-centric Networks
 
   A first example is constituted by the networks created and managed by City Councils
   (e.g., [Heer <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Heer> ]).  Some companies [FON reference missing] develop and

 

 

 
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.4> 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 [Samanta <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Samanta> ].
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3> 3.  Scenarios where Alternative Networks are deployed

 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3.1> 3.1.  Alternative Networks depending on the income level of each country

 

 
   sustainable development and improving their quality of life" [WSIS <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-WSIS> ],
   [WSIS <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-WSIS> ].
 
   initially on improving and extending the existing infrastructure in order to not  leave their population behind.  Universal Access and Service

   the beginning of the 90s [Rendon <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Rendon> ].

 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3.2> 3.2.  Urban vs. rural areas

 

 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4> 4.  Technologies employed
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1> 4.1.  Wired

 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1.1> 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- <http://www.fiberopticmania.com/blogs/details/948/lowenstedt-villagers-built-own-fiber-optic-network#sthash.rolFITEo.dpuf> 
   villagers-built-own-fiber-optic-network#sthash.rolFITEo.dpuf <http://www.fiberopticmania.com/blogs/details/948/lowenstedt-villagers-built-own-fiber-optic-network#sthash.rolFITEo.dpuf> 
   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> 
   German-villagers-set-up-their-own-broadband-network.html <http://www.telegraph.co.uk/news/worldnews/europe/germany/10871150/German-villagers-set-up-their-own-broadband-network.html> 
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2> 4.2.  Wireless
 
   Different wireless technologies [WNDW <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-WNDW> ] can be employed in Alternative
   Network Deployments.
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.1> 4.2.1.  Antennas

 

 
 
   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 [Flickenger <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Flickenger> ] [Zennaro <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Zennaro> ].

 

 

 
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.2> 4.2.2.  Link length

 

 

 

 

 

 

 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3> 4.2.3.  Layer 2
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.1> 4.2.3.1.  802.11 (Wi-Fi)

 
   In 2012 IEEE issued the 802.11-2012 Standard that consolidates all
   the previous amendments.  The document is freely downloadable from
   IEEE standards [IEEE <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-IEEE> ].

 

 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.1.1> 4.2.3.1.1.  Deployment planning for 802.11 wireless networks

 

 

 
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.1.2> 4.2.3.1.2.  802.11af (TVWS)
 
   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> 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- <http://timesofindia.indiatimes.com/world/rest-of-world/Ignored-by-big-companies-Mexican-village-creates-its-own-mobile-service/> 
   big-companies-Mexican-village-creates-its-own-mobile-service/ <http://timesofindia.indiatimes.com/world/rest-of-world/Ignored-by-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> 5.  Network and architecture issues
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1> 5.1.  Layer 3
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.1> 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 [Avonts <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Avonts> ]
   indicated that IPv6 rollout presents a challenge to Community Networks.
 
   Most Community Networks use private IPv4 address ranges, as defined
   by RFC 1918 <http://tools.ietf.org/html/rfc1918>  [RFC1918 <http://tools.ietf.org/html/rfc1918> ].  The motivation for this was the lower cost
   and the simplified IP allocation because of the large available
   address ranges.

 

 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2> 5.1.2.  Routing protocols

 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.1> 5.1.2.1.  Traditional routing protocols
 
   The BGP protocol, as defined by RFC 4271 <http://tools.ietf.org/html/rfc4271>  [RFC4271 <http://tools.ietf.org/html/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 RFC 2328 <http://tools.ietf.org/html/rfc2328>  [RFC2328 <http://tools.ietf.org/html/rfc2328> ].
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.2> 5.1.2.2.  Mesh routing protocols
 
   A large number of Community Networks use the OLSR routing protocol as
   defined in RFC 3626 <http://tools.ietf.org/html/rfc3626>  [RFC3626 <http://tools.ietf.org/html/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.)
   [Abolhasan <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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 [Neumann <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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> 5.2.  Upper layers
 
   on keeping low latency RFC 6297 <http://tools.ietf.org/html/rfc6297>  [RFC6297 <http://tools.ietf.org/html/rfc6297> ].

 
   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
   [Sathiaseelan_a <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Sathiaseelan_a> ]  [Suresh <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Suresh> ].  There are also other proposals such as
   Wi2Me [Lampropulos <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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 [Hanbali <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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 RFC 3135 <http://tools.ietf.org/html/rfc3135>  [RFC3135 <http://tools.ietf.org/html/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)
   [Castignani_c <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_c> ].  Similarly, the ACK Congestion Control (ACKCC)
   mechanism RFC 5690 <http://tools.ietf.org/html/rfc5690>  [RFC5690 <http://tools.ietf.org/html/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> 5.2.1.  Services provided by these networks

 

 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.1> 5.2.1.1.  Intranet services
 
   - VoIP (e.g. with SIP)

 
   - P2P file sharing.
 
   - public video cameras.
 
   - DNS.
 
   - online games servers.

   - IRC chat.
 
   - weather stations.
 
   - NTP.
 
   - Network monitoring.

   - Radio streaming.
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.2> 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> 5.2.1.2.1.  Web browsing proxies

 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.2.2> 5.2.1.2.2.  Use of VPNs

 

 

 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.3> 5.3.  Topology
 
   These networks follow different topology patterns, as studied in
   [Vega <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Vega> ].
 
   Networks [Sathiaseelan_a <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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 [Castignani_a <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_a> ] [Castignani_b <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-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
   [Castignani_c <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_c> ].
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-6> 6.  Acknowledgements

 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-7> 7.  Contributing Authors

 

 

   L. Aaron Kaplan
   Funkfeur
   Street
   1234 city
   Austria
 
   Phone: +43 (0)699 11994786 <tel:%2B43%20%280%29699%2011994786> 
   Email: [email-masked]
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-8> 8.  IANA Considerations

 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-9> 9.  Security Considerations

 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10> 10.  References
 
 <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10.1> 10.1.  Normative References
 
   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets", BCP <http://tools.ietf.org/html/bcp5> 
              5 <http://tools.ietf.org/html/bcp5> , RFC 1918 <http://tools.ietf.org/html/rfc1918> , February 1996.
 
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14 <http://tools.ietf.org/html/bcp14> , RFC 2119 <http://tools.ietf.org/html/rfc2119> , March 1997.
 
   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328 <http://tools.ietf.org/html/rfc2328> , April 1998.
 
   [RFC3135]  Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
              Shelby, "Performance Enhancing Proxies Intended to
              Mitigate Link-Related Degradations", RFC 3135 <http://tools.ietf.org/html/rfc3135> , June 2001.
 
   [RFC3626]  Clausen, T. and P. Jacquet, "Optimized Link State Routing
              Protocol (OLSR)", RFC 3626 <http://tools.ietf.org/html/rfc3626> , October 2003.
 
   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271 <http://tools.ietf.org/html/rfc4271> , January 2006.

---

From: "Prof. Adam Wolisz" <[email-masked]>
Date: Thu, 20 Nov 2014 16:46:20 +0100

Dear Friends

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/

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

On 07.11.2014 18:10, Ermanno
Pietrosemoli wrote:

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

---------

[Docs]
[txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 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

A. Sathiaseelan

University of Cambridge

M. Zennaro

Abdus Salam ICTP

October 6, 2014

Alternative Network Deployments.  Taxonomy
and characterization

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]

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

Status of This Memo

This Internet-Draft is submitted in full
conformance with the

provisions of BCP
78 and 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-

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

This document is subject to BCP
78 and the IETF Trust's Legal

(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 Section 4.e of

the Trust Legal Provisions and are provided
without warranty as

Saldana, et al.           Expires April 9, 2015
[Page 2]

Internet-Draft       Alternative Network
Deployments        October 2014

Table of Contents

1.  Introduction  . . . . . . . . .
. . . . . . . . . . . . . . .   3

1.1.  Requirements Language . . . .
. . . . . . . . . . . . . .   4

2.  Classification  . . . . . . . .
. . . . . . . . . . . . . . .   4

2.1.  Community Networks  . . . . .
. . . . . . . . . . . . . .   5

2.2.  Crowdshared approaches, led by the
people and third party

stakeholders  . . . . . . . . . . . . .
. . . . . . . . .   6

2.3.  User-centric Networks . . . .
. . . . . . . . . . . . . .   7

2.4.  Testbed . . . . . . . . . . .
. . . . . . . . . . . . . .   8

3.  Scenarios where Alternative
Networks are deployed . . . . . .   8

3.1.  Alternative Networks depending on the
income level of

each country  . . . . . . . . . . . . .
. . . . . . . . .   8

3.2.  Urban vs. rural areas . . . .
. . . . . . . . . . . . . .  10

4.  Technologies employed . . . . .
. . . . . . . . . . . . . . .  11

4.1.  Wired . . . . . . . . . . . .
. . . . . . . . . . . . . .  11

4.1.1.  Optical Fiber . . . . . . .
. . . . . . . . . . . . .  11

4.2.  Wireless  . . . . . . . . . .
. . . . . . . . . . . . . .  11

4.2.1.  Antennas  . . . . . . . . .
. . . . . . . . . . . . .  11

4.2.2.  Link length . . . . . . . .
. . . . . . . . . . . . .  13

4.2.3.  Layer 2 . . . . . . . . . .
. . . . . . . . . . . . .  15

4.2.3.1.  802.11 (Wi-Fi)  . . . . .
. . . . . . . . . . . .  15

4.2.3.2.  GSM . . . . . . . . . . .
. . . . . . . . . . . .  17

5.  Network and architecture issues
. . . . . . . . . . . . . . .  17

5.1.  Layer 3 . . . . . . . . . . .
. . . . . . . . . . . . . .  17

5.1.1.  IP addressing . . . . . . .
. . . . . . . . . . . . .  17

5.1.2.  Routing protocols . . . . .
. . . . . . . . . . . . .  18

5.1.2.1.  Traditional routing
protocols . . . . . . . . . .  18

5.1.2.2.  Mesh routing protocols  .
. . . . . . . . . . . .  18

5.2.  Upper layers  . . . . . . . .
. . . . . . . . . . . . . .  18

5.2.1.  Services provided by these
networks . . . . . . . . .  19

5.2.1.1.  Intranet services . . . .
. . . . . . . . . . . .  20

5.2.1.2.  Access to the Internet  .
. . . . . . . . . . . .  20

5.3.  Topology  . . . . . . . . . .
. . . . . . . . . . . . . .  21

6.  Acknowledgements  . . . . . . .
. . . . . . . . . . . . . . .  21

7.  Contributing Authors  . . . . .
. . . . . . . . . . . . . . .  21

8.  IANA Considerations . . . . . .
. . . . . . . . . . . . . . .  22

9.  Security Considerations . . . .
. . . . . . . . . . . . . . .  22

10. References  . . . . . . . . . .
. . . . . . . . . . . . . . .  22

10.1.  Normative References . . . .
. . . . . . . . . . . . . .  22

10.2.  Informative References . . .
. . . . . . . . . . . . . .  23

Authors' Addresses  . . . . . . . . . . . . . .
. . . . . . . . .  25

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]

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 [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

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
RFC
2119 [RFC2119].

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

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, RFC1918,
OLSR, BMX6, etc.) coexist.

Saldana, et al.           Expires April 9, 2015
[Page 4]

Internet-Draft       Alternative Network
Deployments        October 2014

2.1.
Community Networks

Community Networks are large-scale,
distributed, self-managed

- 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

- 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)
as:

A free network equitably grants the following
freedoms to all:

Freedom 0 - Freedom to communicate for any
purpose, without

Freedom 1 - The freedom to grow, improve,
communicate across, and

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)
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]

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 [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.

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]

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 [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

[Sathiaseelan_a].

- 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 [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.

2.3.
User-centric Networks

A first example is constituted
by the networks created and managed by City
Councils

(e.g., [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

Saldana, et al.           Expires April 9, 2015
[Page 7]

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

- The owner: an entity (e.g. end-user;
operator; virtual operator;

municipality) that is to be made responsible
for any actions

- 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

- 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.

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 [Samanta].

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.

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]

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" [WSIS],

and called upon "governments, private sector,
civil society and

international organisations" to actively engage
to accomplish it

[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]

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 [Rendon].

Although it is undeniable the contribution made
by mobile network

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.

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]

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.

4.
Technologies employed

4.1.
Wired

Some of the wired technologies employed in ANs
are:

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

4.2.
Wireless

Different wireless technologies [WNDW] can be employed in Alternative

Network Deployments.

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]

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

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 [Flickenger] [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]

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.

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,

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]

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 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

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

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

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]

Internet-Draft       Alternative Network
Deployments        October 2014

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.

4.2.3.
Layer 2

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

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

|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 [IEEE].

Saldana, et al.           Expires April 9, 2015
[Page 15]

Internet-Draft       Alternative Network
Deployments        October 2014

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

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]

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

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.

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.

5.
Network and architecture issues

5.1.
Layer 3

5.1.1.
IP addressing

Most known Alternative Networks started in or
around the year 2000.

Networks still use IPv4.  A community networks
survey [Avonts]

indicated that IPv6 rollout presents
a challenge to Community Networks.

Most Community Networks use private IPv4
address ranges, as defined

by RFC
1918 [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]

Internet-Draft       Alternative Network
Deployments        October 2014

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.

5.1.2.1.
Traditional routing protocols

The BGP protocol, as defined by RFC
4271 [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 RFC
2328 [RFC2328].

5.1.2.2.
Mesh routing protocols

A large number of Community Networks use the
OLSR routing protocol as

defined in RFC
3626 [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.)

[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 [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.

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 RFC
6297 [RFC6297].

Saldana, et al.           Expires April 9, 2015
[Page 18]

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

[Sathiaseelan_a]  [Suresh].  There are also other
proposals such as

Wi2Me [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 [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 RFC
3135 [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)

[Castignani_c].  Similarly, the ACK
Congestion Control (ACKCC)

mechanism RFC
5690 [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.

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

Saldana, et al.           Expires April 9, 2015
[Page 19]

Internet-Draft       Alternative Network
Deployments        October 2014

5.2.1.1.
Intranet services

- VoIP (e.g. with SIP)

- remote desktop (e.g. using my computer and my
Internet connection

- FTP file sharing (e.g. distribution of Linux
software).

- P2P file sharing.

- public video cameras.

- DNS.

- online games servers.

- IRC chat.

- weather stations.

- NTP.

- Network monitoring.

- Radio streaming.

5.2.1.2.
Access to the Internet

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.

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]

Internet-Draft       Alternative Network
Deployments        October 2014

5.3.
Topology

These networks follow different topology
patterns, as studied in

[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 [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 [Castignani_a] [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

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

[Castignani_c].

6.
Acknowledgements

This work has been partially funded by the
CONFINE European

7.
Contributing Authors

Saldana, et al.           Expires April 9, 2015
[Page 21]

Internet-Draft       Alternative Network
Deployments        October 2014

L. Aaron Kaplan

Funkfeur

Street

1234 city

Austria

Email: [email-masked]

8.
IANA Considerations

9.
Security Considerations

No security issues have been identified for
this document.

10.
References

10.1.
Normative References

[RFC1918]  Rekhter, Y., Moskowitz, R.,
Karrenberg, D., Groot, G., and

E. Lear, "Address Allocation for
Private Internets", BCP

5,
RFC
1918, February 1996.

[RFC2119]  Bradner, S., "Key words for use in
RFCs to Indicate

Requirement Levels", BCP
14, RFC
2119, March 1997.

[RFC2328]  Moy, J., "OSPF Version 2", STD 54, 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",
RFC
3135, June 2001.

[RFC3626]  Clausen, T. and P. Jacquet,
"Optimized Link State Routing

Protocol (OLSR)", RFC
3626, October 2003.

[RFC4271]  Rekhter, Y., Li, T., and S. Hares,
"A Border Gateway

Protocol 4 (BGP-4)", RFC
4271, January 2006.

[RFC5690]  Floyd, S., Arcia, A., Ros, D., and
J. Iyengar, "Adding

Acknowledgement Congestion Control
to TCP", RFC
5690,

February 2010.

[RFC6297]  Welzl, M. and D. Ros, "A Survey of
Lower-than-Best-Effort

Transport Protocols", RFC
6297, June 2011.

Saldana, et al.           Expires April 9, 2015
[Page 22]

Internet-Draft       Alternative Network
Deployments        October 2014

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

[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]

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,

[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),

[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]

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

[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

[WNDW]     Wireless Networking in the
Developing World/Core

Contributors, "Wireless Networking
in the Developing

World, 3rd Edition", The WNDW
Project, available at

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

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]

Internet-Draft       Alternative Network
Deployments        October 2014

Jose Saldana (editor)

University of Zaragoza

Zaragoza  50018

Spain

Phone: +34 976 762 698

Andres Arcia-Moret

Universidad de Los Andes

Merida  5101

Venezuela

Phone: +58 274 2402811

Bart Braem

iMinds

Gent  9050

Belgium

Phone: +32 3 265 38 64

Leandro Navarro

U. Politecnica Catalunya

Jordi Girona, 1-3, D6

Barcelona  08034

Spain

Phone: +34 934016807

Ermanno Pietrosemoli

Apartado 514

Merida  5101

Venezuela

ICTP

Via Beirut 7

Trieste 34151

Italy

Phone: +39 040 2240 471

Email: [email-masked]

Saldana, et al.           Expires April 9, 2015
[Page 26]

Internet-Draft       Alternative Network
Deployments        October 2014

Carlos Rey-Moreno

Robert Sobukwe road

Bellville  7535

South Africa

Phone: 0027219592562

Arjuna Sathiaseelan

University of Cambridge

15 JJ Thomson Avenue

Cambridge  CB30FD

United Kingdom

Marco Zennaro

Abdus Salam ICTP

Strada Costiera 11

Trieste  34100

Italy

Phone: +39 040 2240 406

Email: [email-masked]

Saldana, et al.           Expires April 9, 2015
[Page 27]

Html markup produced by rfcmarkup 1.109, available
from https://tools.ietf.org/tools/rfcmarkup/

On Fri, Nov 7, 2014 at 10:11 AM, Jose
Saldana <[email-masked]>
wrote:

Steve,

I was wondering... perhaps you could contribute two
paragraphs about 802.22 for the draft...

Jose

> >> On 5 November 2014 16:12, Ioannis Komnios
<[email-masked]>

> >> > p.4 We should introduce the acronym
AN for Alternative Networks,

> >> > since we use it in the document.

> >> > p.5 “The principles of these
networks” and p. 6 “These networks grow…”.

> >> > p.11 We refer to scarce technical
skills as a problem to rural areas.

> >> > p.11 There is no need for a
subsection 4.1.1. since it is the only one.

> >> > p.11 We first refer to Fresnel zone
in p.11, but we describe it in p.12.

> >> > 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.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.14 “This will reduce significantly
the” -> “This will

> >> > significantly reduce the”

> >> > p.18 “not guaranteed, the link
stability” -> “not guaranteed and

> >> > the link stability”

gaia mailing list

[email-masked]

--

Abdus Salam International Centre for Theoretical Physics,
GGH, Via Beirut 7, Trieste 34151 Italy

-------

Presidente

www.EsLaRed.net

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 25 Nov 2014 11:04:47 +0100

Hi all,
 
This week I will use the feedback received in order to write a new version of the “Alternative Network Deployments” Draft.
 
The idea of this draft is to set a clear "classification" or a "taxonomy" of Alternative Network Deployments.
 
We have three possible approaches:
 
(1) To write a draft including everything, i.e. the classification itself and very long explaining about each kind of network. This would be a “fat” document including everything. The drawback of this approach: Consensus will be very difficult to reach, because we can get blocked in many parts.

(2) To split the draft into a number of different documents (with different authors), each one about one kind of Alternative Network. The classification could be something like:
- Community Networks
- Crowdshared approaches, led by the people and third party stakeholders
- User-centric Networks 
- Testbed
 
Drawback: If we just split the current draft into a number of documents, we may lose the classification.

(3) A thin "classification" draft and some other "fat" ones explaining each kind of Alternative Networks. Perhaps we could keep the initial draft "thin" enough so as to permit other ones further exploring and explaining each kind of network in deep.

Currently, the authors of the draft think that the most practical approach could be (3): let's start with a classification, and see if we can find people for writing the other ones. Following this approach, the strength of the “Alternative Network Deployments” document will be the classification, not a very deep explaining about each kind of network.

Jose
 
De: gaia [mailto:[email-masked]] En nombre de Jose Saldana
Enviado el: lunes, 10 de noviembre de 2014 15:02
Para: 'Arjuna Sathiaseelan'; 'Ermanno Pietrosemoli'
CC: 'gaia'
Asunto: Re: [gaia] Fixes to "Alternative Network Deployments" Internet Draft

 
Best regards,
 
Jose

Thanks Ermanno,
Should we also write more on TVWS - about geolocation databases and why using proprietary databases may not be the right way forward to connect rural areas in developing regions - and whether cognitive sensing could be used because there is enough spectrum along with the spectrum masking details etc?.
Or do you think it will be too much for this document..
Regards
Arjuna
On 7 Nov 2014 17:11, "Ermanno Pietrosemoli" < <mailto:[email-masked]> [email-masked]> wrote:
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/> Docs] [ <https://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.txt> txt| <http://tools.ietf.org/pdf/draft-manyfolks-gaia-community-networks-01.txt> pdf| <http://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.xml> xml| <http://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.html> html] [ <https://datatracker.ietf.org/doc/draft-manyfolks-gaia-community-networks> Tracker] [ <mailto:[email-masked]?subject=draft-manyfolks-gaia-community-networks%20> Email] [ <http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-manyfolks-gaia-community-networks-01.txt> Diff1] [ <http://tools.ietf.org/rfcdiff?url2=draft-manyfolks-gaia-community-networks-01.txt> Diff2] [ <http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.txt> Nits]      
                                                                        
Versions:  <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-00> 00  <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01> 01                                                         

 
Abstract

 

 
Status of This Memo
 
   This Internet-Draft is submitted in full conformance with the
   provisions of  <http://tools.ietf.org/html/bcp78> BCP 78 and  <http://tools.ietf.org/html/bcp79> 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/> http://datatracker.ietf.org/drafts/current/.

 
Copyright Notice

   This document is subject to  <http://tools.ietf.org/html/bcp78> BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( <http://trustee.ietf.org/license-info> 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> Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

 

Table of Contents
 
    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-1> 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-3> 3
      <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-1.1> 1.1.  Requirements Language . . . . . . . . . . . . . . . . . .    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-4> 4
    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2> 2.  Classification  . . . . . . . . . . . . . . . . . . . . . . .    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-4> 4
      <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.1> 2.1.  Community Networks  . . . . . . . . . . . . . . . . . . .    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-5> 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> 6
      <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.3> 2.3.  User-centric Networks . . . . . . . . . . . . . . . . . .    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-7> 7
      <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-2.4> 2.4.  Testbed . . . . . . . . . . . . . . . . . . . . . . . . .    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-8> 8
    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3> 3.  Scenarios where Alternative Networks are deployed . . . . . .    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-8> 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> 8
      <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-3.2> 3.2.  Urban vs. rural areas . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-10> 10
    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4> 4.  Technologies employed . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11> 11
      <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1> 4.1.  Wired . . . . . . . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11> 11
        <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.1.1> 4.1.1.  Optical Fiber . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11> 11
      <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2> 4.2.  Wireless  . . . . . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11> 11
        <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.1> 4.2.1.  Antennas  . . . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-11> 11
        <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.2> 4.2.2.  Link length . . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-13> 13
        <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3> 4.2.3.  Layer 2 . . . . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-15> 15
          <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.1> 4.2.3.1.  802.11 (Wi-Fi)  . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-15> 15
          <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-4.2.3.2> 4.2.3.2.  GSM . . . . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17> 17
    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5> 5.  Network and architecture issues . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17> 17
      <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1> 5.1.  Layer 3 . . . . . . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17> 17
        <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.1> 5.1.1.  IP addressing . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-17> 17
        <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2> 5.1.2.  Routing protocols . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18> 18
          <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.1> 5.1.2.1.  Traditional routing protocols . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18> 18
          <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.1.2.2> 5.1.2.2.  Mesh routing protocols  . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18> 18
      <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2> 5.2.  Upper layers  . . . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-18> 18
        <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1> 5.2.1.  Services provided by these networks . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-19> 19
          <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.1> 5.2.1.1.  Intranet services . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-20> 20
          <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.2.1.2> 5.2.1.2.  Access to the Internet  . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-20> 20
      <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-5.3> 5.3.  Topology  . . . . . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21> 21
    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-6> 6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21> 21
    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-7> 7.  Contributing Authors  . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-21> 21
    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-8> 8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22> 22
    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-9> 9.  Security Considerations . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22> 22
    <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10> 10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22> 22
      <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10.1> 10.1.  Normative References . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-22> 22
      <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#section-10.2> 10.2.  Informative References . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-23> 23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#page-25> 25

 

   rural/remote areas [ <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Pietrosemoli> Pietrosemoli].  In these cases, the networks have

 
   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> RFC 2119 [ <http://tools.ietf.org/html/rfc2119> RFC2119].

 

 

 

 
   A definition of Free Network (which MAY be the same as Community
   Network) is proposed by the Free Network Foundation (see
    <http://thefnf.org/> http://thefnf.org) as:

 

   The principles of these networks have also been summarized (see
    <http://guifi.net/ca/CXOLN> http://guifi.net/ca/CXOLN) this way:

 

 

 
   Network is described in [ <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Braem> Braem].  These networks are effective in

 

 

   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> PAWS].
 
   [ <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Sathiaseelan_a> Sathiaseelan_a].

 
 
   - 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> Sathiaseelan_b] at lower cost to the VNOs.

 
   (e.g., [ <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Heer> Heer]).  Some companies [FON reference missing] develop and

 

 

 

   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> Samanta].

 

 

 
   sustainable development and improving their quality of life" [ <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-WSIS> WSIS],
   [ <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-WSIS> WSIS].

 

   the beginning of the 90s [ <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Rendon> Rendon].

 

 

 

 
   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> 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> 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> 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> German-villagers-set-up-their-own-broadband-network.html

   Different wireless technologies [ <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-WNDW> WNDW] can be employed in Alternative
   Network Deployments.

 

 

   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> Flickenger] [ <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Zennaro> Zennaro].

 

 

 

 

 

 

 

 

 

 

 

   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> IEEE].

 

 

 

 

 

 
 
   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/> 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/> big-companies-Mexican-village-creates-its-own-mobile-service/
   articleshow/22094736.cms?referral=PM

 
 
   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> 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> RFC 1918 [ <http://tools.ietf.org/html/rfc1918> RFC1918].  The motivation for this was the lower cost
   and the simplified IP allocation because of the large available
   address ranges.

 

 

   The BGP protocol, as defined by  <http://tools.ietf.org/html/rfc4271> RFC 4271 [ <http://tools.ietf.org/html/rfc4271> 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> RFC 2328 [ <http://tools.ietf.org/html/rfc2328> RFC2328].

   A large number of Community Networks use the OLSR routing protocol as
   defined in  <http://tools.ietf.org/html/rfc3626> RFC 3626 [ <http://tools.ietf.org/html/rfc3626> 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> 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> 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.

   on keeping low latency  <http://tools.ietf.org/html/rfc6297> RFC 6297 [ <http://tools.ietf.org/html/rfc6297> RFC6297].

 
   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> Sathiaseelan_a]  [ <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Suresh> Suresh].  There are also other proposals such as
   Wi2Me [ <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Lampropulos> 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> 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> RFC 3135 [ <http://tools.ietf.org/html/rfc3135> 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> Castignani_c].  Similarly, the ACK Congestion Control (ACKCC)
   mechanism  <http://tools.ietf.org/html/rfc5690> RFC 5690 [ <http://tools.ietf.org/html/rfc5690> 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.

 

 
   - VoIP (e.g. with SIP)

 
   - P2P file sharing.
 
   - public video cameras.
 
   - DNS.
 
   - online games servers.

   - IRC chat.
 
   - weather stations.
 
   - NTP.
 
   - Network monitoring.

   - Radio streaming.

 

 

 

   These networks follow different topology patterns, as studied in
   [ <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Vega> Vega].
 
   Networks [ <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Sathiaseelan_a> Sathiaseelan_a] can also extend the service.
 
   of performing file transfers [ <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_a> Castignani_a] [ <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_b> Castignani_b]. 
   [ <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_c> Castignani_c].

 

 

 

   L. Aaron Kaplan
   Funkfeur
   Street
   1234 city
   Austria
 
   Phone:  <tel:%2B43%20%280%29699%2011994786> +43 (0)699 11994786
   Email:  <mailto:[email-masked]> [email-masked]

 

 
 
   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",  <http://tools.ietf.org/html/bcp5> BCP
               <http://tools.ietf.org/html/bcp5> 5,  <http://tools.ietf.org/html/rfc1918> RFC 1918, February 1996.
 
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels",  <http://tools.ietf.org/html/bcp14> BCP 14,  <http://tools.ietf.org/html/rfc2119> RFC 2119, March 1997.
 
   [RFC2328]  Moy, J., "OSPF Version 2", STD 54,  <http://tools.ietf.org/html/rfc2328> 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> RFC 3135, June 2001.
 
   [RFC3626]  Clausen, T. and P. Jacquet, "Optimized Link State Routing
              Protocol (OLSR)",  <http://tools.ietf.org/html/rfc3626> 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> RFC 4271, January 2006.

---

From: Javier Simó <[email-masked]>
Date: Tue, 25 Nov 2014 13:51:03 +0100

Hello Jose

IMHO, option (1) would lack of flexibility, and option (2) could easily 
drive to some overlapping  and lack of consistency. So I guess that I 
vote (3). It sounds good starting with an initial "thin" draft, and try 
to keep the development of each subsection balanced in style, extension 
and type of content.

In the current version, I guess that my contributions can be in 
"testbed", and specifically in rural communications using wireless 
technologies. However, I think that the classification may be improved 
trying to present a 'multidimensional model' in the introduction in 
which the variables used for the taxonomy are more clearly stated 
(incentive, promoter, technology, population, ... ?) and used 
consistently all along the document. If there is interest to cook a bit 
more the classification in this sense, we can try to do it in this step 
by proposing two -or more- alternate drafts: one strictly based in what 
exists now, and may be another more ellaborated. Let me know if you 
think that this makes sense.

Best regards

Javier

El 25/11/14 a las #4, Jose Saldana escribió:
>
> Hi all,
>
> This week I will use the feedback received in order to write a new 
> version of the “Alternative Network Deployments” Draft.
>
> The idea of this draft is to set a clear "classification" or a 
> "taxonomy" of Alternative Network Deployments.
>
> (1) To write a draft including everything, i.e. the classification 
> itself and very long explaining about each kind of network. This would 
> be a “fat” document including everything. The drawback of this 
> approach: Consensus will be very difficult to reach, because we can 
> get blocked in many parts.
>
> (2) To split the draft into a number of different documents (with 
> different authors), each one about one kind of Alternative Network. 
> The classification could be something like:
>
> - Community Networks
>
> Drawback: If we just split the current draft into a number of 
> documents, we may lose the classification.
>
> (3) A thin "classification" draft and some other "fat" ones explaining 
> each kind of Alternative Networks. Perhaps we could keep the initial 
> draft "thin" enough so as to permit other ones further exploring and 
> explaining each kind of network in deep.
>
> Currently, the authors of the draft think that the most practical 
> approach could be (3): let's start with a classification, and see if 
> we can find people for writing the other ones. Following this 
> approach, the strength of the “Alternative Network Deployments” 
> document will be the classification, not a very deep explaining about 
> each kind of network.
>
> Jose
>
> *De:*gaia [mailto:[email-masked]] *En nombre de *Jose Saldana
> *Enviado el:* lunes, 10 de noviembre de 2014 15:02
> *Para:* 'Arjuna Sathiaseelan'; 'Ermanno Pietrosemoli'
> *CC:* 'gaia'
> *Asunto:* Re: [gaia] Fixes to "Alternative Network Deployments" 
> Internet Draft
>
> If everyone agrees, we can discuss the "Alternative Network 
> Deployments" draft in the list for two more weeks, and then we could 
> try to write a new version of the draft during the week 24th-28th 
> November.
>
> Best regards,
>
> Jose
>
> *De:[email-masked] 
> [mailto:[email-masked]] *En nombre de *Arjuna Sathiaseelan
> *Enviado el:* viernes, 07 de noviembre de 2014 21:14
> *Para:* Ermanno Pietrosemoli
> *CC:* Steve Song; Jose Saldana; gaia
> *Asunto:* Re: [gaia] Fixes to "Alternative Network Deployments" 
> Internet Draft
>
> Thanks Ermanno,
>
> Should we also write more on TVWS - about geolocation databases and 
> why using proprietary databases may not be the right way forward to 
> connect rural areas in developing regions - and whether cognitive 
> sensing could be used because there is enough spectrum along with the 
> spectrum masking details etc?.
>
> On 7 Nov 2014 17:11, "Ermanno Pietrosemoli" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> 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
>
> ---------
>
> <https://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.txt>|pdf 
> <http://tools.ietf.org/pdf/draft-manyfolks-gaia-community-networks-01.txt>|xml 
> <http://tools.ietf.org/id/draft-manyfolks-gaia-community-networks-01.xml>|html 
> <mailto:[email-masked]?subject=draft-manyfolks-gaia-community-networks%20>] 
> [Diff1 
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-00>01 
> provisions of BCP 78 <http://tools.ietf.org/html/bcp78>and BCP 79 
> This document is subject to BCP 78 
> <http://tools.ietf.org/html/bcp78>and the IETF Trust's Legal
>
> <http://tools.ietf.org/html/rfc2119>[RFC2119 
> http://thefnf.org <http://thefnf.org/>) as:
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-PAWS>].
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Sathiaseelan_a>].
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Samanta>].
>
> *3* 
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-WSIS>],
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-WSIS>].
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Rendon>].
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Zennaro>].
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-IEEE>].
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Avonts>]
>
> by RFC 1918 <http://tools.ietf.org/html/rfc1918>[RFC1918 
> <http://tools.ietf.org/html/rfc4271>[RFC4271 
> protocol, as defined by RFC 2328 
> <http://tools.ietf.org/html/rfc2328>[RFC2328 
> <http://tools.ietf.org/html/rfc2328>].
>
> *5.1.2.2* 
> defined in RFC 3626 <http://tools.ietf.org/html/rfc3626>[RFC3626 
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Neumann>].
>
> on keeping low latency RFC 6297 
> <http://tools.ietf.org/html/rfc6297>[RFC6297 
> <http://tools.ietf.org/html/rfc6297>].
>
> <http://tools.ietf.org/html/rfc3135>[RFC3135 
> mechanism RFC 5690 <http://tools.ietf.org/html/rfc5690>[RFC5690 
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Vega>].
>
> <http://tools.ietf.org/html/draft-manyfolks-gaia-community-networks-01#ref-Castignani_b>]. 
>
>
> Email: [email-masked] <mailto:[email-masked]>
>
> *8* 

-- 

---------------------------------------------------
Fco. Javier Simó Reigadas <[email-masked]>
Subdirector de Ord. Docente
ETS de Ingeniería de Telecomunicación
D-204, Departamental III
Camino Del Molino, s/n - 28943 Fuenlabrada (Madrid)
Tel: 914888428, Fax: 914887500
Web personal: http://www.tsc.urjc.es/~javier.simo

---

From: Matthew Ford <[email-masked]>
Date: Tue, 25 Nov 2014 14:53:08 +0000

Hi Jose,

A few comments, inline:

> (1) To write a draft including everything, i.e. the classification itself and very long explaining about each kind of network. This would be a “fat” document including everything. The drawback of t…

I'll note that consensus is not required in the IRTF. Nice to have, but not a hard requirement for IRTF research groups.

> Drawback: If we just split the current draft into a number of documents, we may lose the classification.

The taxonomy and identification of meaningful ways to distinguish between network types is one of the most valuable aspects, so I wouldn't want to see an approach that resulted in losing that.

> (3) A thin "classification" draft and some other "fat" ones explaining each kind of Alternative Networks. Perhaps we could keep the initial draft "thin" enough so as to permit other ones further ex…

As I said, I think the classification is the thing of value here. Combined with some detail about the different network types and extensive references to examples of those networks and further information, this would be a valuable document. I think I'm arguing for thin, but not too thin!

> Currently, the authors of the draft think that the most practical approach could be (3): let's start with a classification, and see if we can find people for writing the other ones. Following this…

Classification, an overview of the different network types including defining characteristics and maybe common issues, and extensive pointers to further information would be useful, IMHO.

Mat