One document matched: draft-manyfolks-gaia-community-networks-00.xml
<?xml version="1.0" encoding="utf-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2328 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3135 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3135.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3626 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3626.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC5690 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5690.xml">
<!ENTITY RFC6297 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6297.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-manyfolks-gaia-community-networks-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="CN">Community Networks. Definition and taxonomy</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Jose Saldana" initials="J." surname="Saldana" role="editor">
<organization>University of Zaragoza</organization>
<address>
<postal>
<street>Dpt. IEC Ada Byron Building</street>
<!-- Reorder these if your country does things differently -->
<city>Zaragoza</city>
<region></region>
<code>50018</code>
<country>Spain</country>
</postal>
<phone>+34 976 762 698</phone>
<email>jsaldana@unizar.es</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Andres Arcia-Moret" initials="A." surname="Arcia-Moret">
<organization>Universidad de Los Andes</organization>
<address>
<postal>
<street>Facultad de Ingeniería. Sector La Hechicera</street>
<!-- Reorder these if your country does things differently -->
<city>Merida</city>
<region></region>
<code>5101</code>
<country>Venezuela</country>
</postal>
<phone>+58 274 2402811</phone>
<email>andres.arcia@ula.ve</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Bart Braem" initials="B." surname="Braem">
<organization>University of Antwerp - iMinds</organization>
<address>
<postal>
<street>Middelheimlaan 1</street>
<!-- Reorder these if your country does things differently -->
<city>Antwerp</city>
<region></region>
<code>B-2020</code>
<country>Belgium</country>
</postal>
<phone>+32 (0)3 265.38.64</phone>
<email>bart.braem@iminds.be</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Leandro Navarro" initials="L." surname="Navarro">
<organization>U. Politecnica Catalunya</organization>
<address>
<postal>
<street>Jordi Girona, 1-3, D6</street>
<!-- Reorder these if your country does things differently -->
<city>Barcelona</city>
<region></region>
<code>08034</code>
<country>Spain</country>
</postal>
<phone>+34 934016807</phone>
<email>leandro@ac.upc.edu</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Ermanno Pietrosemoli" initials="E." surname="Pietrosemoli">
<organization>Escuela Latinoamericana de Redes</organization>
<address>
<postal>
<street>Apartado 514</street>
<!-- Reorder these if your country does things differently -->
<city>Merida</city>
<region></region>
<code>5101</code>
<country>Venezuela</country>
</postal>
<phone>+58 0274 2403327</phone>
<email>ermanno@ula.ve</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Carlos Rey-Moreno" initials="C." surname="Rey-Moreno">
<organization>University of the Western Cape</organization>
<address>
<postal>
<street>Robert Sobukwe road</street>
<!-- Reorder these if your country does things differently -->
<city>Bellville</city>
<region></region>
<code>7535</code>
<country>South Africa</country>
</postal>
<phone>0027219592562</phone>
<email>crey-moreno@uwc.ac.za</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Arjuna Sathiaseelan" initials="A." surname="Sathiaseelan">
<organization>University of Cambridge</organization>
<address>
<postal>
<street>15 JJ Thomson Avenue</street>
<!-- Reorder these if your country does things differently -->
<city>Cambridge</city>
<region></region>
<code>CB30FD</code>
<country>United Kingdom</country>
</postal>
<phone>+44 (0)1223 763781</phone>
<email>arjuna.sathiaseelan@cl.cam.ac.uk</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Marco Zennaro" initials="M." surname="Zennaro">
<organization>Abdus Salam ICTP</organization>
<address>
<postal>
<street>Strada Costiera 11</street>
<city>Trieste</city>
<region></region>
<code>34100</code>
<country>Italy</country>
</postal>
<phone>+39 040 2240 406</phone>
<email>mzennaro@ictp.it</email>
</address>
</author>
<date month="June" year="2014" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<workgroup>Global Access to the Internet for All</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>Several communities have developed initiatives to build large scale,
self-organized and decentralized community wireless
networks that use wireless technologies (including long distance) due to the reduced cost
of using the unlicensed spectrum. This 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 has motivated the rise of these
networks. Some other times, they are built as a complement and an alternative to
wired Internet access.</t>
<t>These community wireless 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 who see such community
led networks as a way to extend their reach to rural/remote areas at lower cost.</t>
<t>This document defines these networks, summarizes their technological
characteristics and classifies them, also talking about their socio-economic
sustainability models.</t>
<t>There exist other networks, also based on sharing wireless resources of the users, but
not built upon the initiative of the users themselves, nor owned by them. The
characterization of these networks is not the objective of this document.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Several communities have developed initiatives to build large scale,
self-organized and decentralized community wireless
networks that use wireless technology (including long distance) due to the reduced cost
of using the unlicensed spectrum. This 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 has motivated the rise of these
networks <xref target="Pietrosemoli"></xref>. Some other times, they are built as a
complement and an alternative to wired Internet access.</t>
<t>These community wireless 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 who see such community
led networks as a way to extend their reach to rural/remote areas at lower cost.</t>
<t>A Community Network MAY or MAY NOT be organized as a company, but in any case this
document only considers those operated and owned by the community members (e.g. as a
cooperative). The fact of setting up a company is sometimes an advantage: it not only
permits the provision of the service within the current regulatory framework
(in some countries, in order to charge for the services, even in a cost-recovery mode
only, you need to have a licence), but it also allows to obtain wholesale prices
from other operators when peering, which are way cheaper than those offered for
normal clients, prices which influence greatly on the uptake of the service and in
the financial sustainability of the Community Network.</t>
<t>There exist other networks, also based on sharing wireless resources of the users, but
not built upon the initiative of the users themselves, nor owned by them. The
characterization of these networks is not the objective of this document.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Definition">
<!-- Written by Bart -->
<t>Community Networks are large-scale, distributed, self-managed networks which are built
and organized in a decentralized and open manner. Community Networks start and grow
organically, they are open to participation from everyone agreeing to an open peering
agreement. Knowledge about building and maintaining the network and ownership of the
network itself is decentralized and open. 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. The network CAN serve as a backhaul for providing
a whole range of services and applications, from completely free to even commercial services.</t>
</section>
<section title="Scenarios">
<t>Scenarios where CNs are interesting or have been deployed.</t>
<section title="Developing countries">
<!-- Written by Carlos -->
<t>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 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.</t>
<t>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.</t>
<t>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” <xref target="WSIS"></xref>, and called upon “governments, private
sector, civil society and international organisations” to actively engage to
accomplish it <xref target="WSIS"></xref>.</t>
<t>Most efforts from governments and international organizations focused initially on
improving and extending the existing infrastructure for not leaving 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 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 <xref target="Rendon"></xref>.</t>
<t>Although it is undeniable the contribution made by mobile network operators in
decreasing the access gap, its 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.</t>
<t>The consolidation of many 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, Community 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.</t>
</section>
<section title="Rural areas">
<!-- Written by Carlos -->
<t>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 deemed them profitable</t>
<t>The cost of the wireless infrastructure required to set up a Community Network,
including powering them via solar energy, is within the range of availability
if not of individuals at least of entire communities. The social capital existing
in these areas can allow for Community 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.</t>
</section>
</section>
</section>
<section title="Technologies employed">
<t>These networks employ different technologies <xref target="WNDW"></xref>.
They can be classified according to different criteria:</t>
<!--[Jose] Marco can contribute here.-->
<section title="Antennas">
<!-- Written by Ermanno -->
<t>Three kinds of antennas are suitable to be used in community
networks: omnidirectional, directional and high gain antennas.</t>
<t>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.</t>
<t>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.</t>
<t>For indoor clients, omnis are generally fine, because the numerous reflections normally
found in indoor environments negate the advantage of using directive antennas.</t>
<t>For outdoor clients, directive antennas can be quite useful to extend coverage to an
Access Point fitted with an omni.</t>
<t>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 <xref target="Flickenger"></xref> <xref target="Zennaro"></xref>.</t>
<t>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.</t>
<t>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 frequently 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 due with lower altitude antenna placement since the Fresnel zone is inversely
proportional to the square root of the frequency.</t>
<t>On the contrary, lower frequencies offer advantages when the line of sight is blocked
because they can leverage diffraction to reach the intended receiver. </t>
<t>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.</t>
<t>Of course, in the case of mesh networking, where the antenna should connect to several
other nodes, it is better to use omnidirectional antennas.</t>
<t>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.</t>
</section>
<section title="Link length">
<!-- Written by Ermanno -->
<t>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.</t>
<t>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.</t>
<t>Another factor to be considered is that radio waves occuppy 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.</t>
<t>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.</t>
<t>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.</t>
<t>Bear in mind that the sensitivity of the receiver decreases with the transmission
speed, so more power is needed at greater transmission speeds.</t>
<t>The received power is determined by the transmitted power, the gain of the
transmitting and receiving antennas and the propagation loss.</t>
<t>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.</t>
<t>Multipath is more pronounced in trajectories over water, if they cannot be avoided
special countermeasures should be taken.</t>
<t>So to achieve a given link margin (also called fade margin), one can:</t>
<t>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.</t>
<t>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.</t>
<t>c) Reduce the propagation loss, by using a more favourable frequency or a shorter path.</t>
<t>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.</t>
<t>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, in which
the receiver does not wait for an acknowledge 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.</t>
</section>
<section title="Layer 2">
<section title="The 802.11 standard">
<!-- Written by Marco -->
<t>Wireless standards ensure interoperability and usability by 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.</t>
<t>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.</t>
<figure align="left">
<artwork align="left"><![CDATA[
|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 | | |
]]></artwork>
</figure>
<t>In 2012 IEEE issued the 802.11-2012 Standard that consolidates all the previous amendments.
The document is freely downloadable from <xref target="IEEE">IEEE standards</xref>.</t>
</section>
<section title="Deployment planning for 802.11 wireless networks">
<!-- Written by Marco -->
<t>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.</t>
<t>To provide physical connectivity, wireless network devices must operate in the same part of
the radio spectrum. This is 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.</t>
<t>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:</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>4.Monitor mode is used by some tools (such as Kismet) to passively listen to all radio traHc
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.</t>
<t>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.</t>
</section>
<section title="802.11af (TVWS)">
<t>Some Community Networks make use of TV White Spaces, using 802.11af standard.</t>
</section>
<section title="Other options">
<t>802.11 is not the only layer 2 option to be used in Community Networks.</t>
</section>
</section>
<section title="Layer 3">
<section title="IP addressing">
<!-- Written by Bart -->
<t>Most known Community Networks started in or around the year 2000. IPv6 was fully specified
by then, but most almost all Community Networks still use IPv4. A <xref target="Avonts">community
networks survey</xref> indicated that IPv6 rollout forms a challenge to Community Networks.</t>
<t>Most Community Networks use private IPv4 address ranges, as defined by <xref
target="RFC1918">RFC 1918</xref>. The motivation for this was the lower cost and the simplified
IP allocation because of the large available address ranges.</t>
</section>
<section title="Routing protocols">
<!-- Written by Bart -->
<t>Community Networks are composed of possibly different layer 2 devices, resulting in a mesh
of Community Network 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.</t>
<section title="Traditional routing protocols">
<!-- Written by Bart -->
<t>The BGP protocol, as defined by <xref target="RFC4271">RFC 4271</xref> is used by a
number of Community Networks, because of its well-studied behavior and scalability.</t>
<t>For similar reasons, smaller Community Networks opt to run the OSPF protocol, as
defined by <xref target="RFC2328">RFC 2328</xref>.</t>
</section>
<section title="Mesh routing protocols">
<!-- Written by Bart -->
<t>A large number of Community Networks use the OLSR routing protocol as defined in <xref
target="RFC3626">RFC 3626</xref>. 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.</t>
<t>The Better Approach To Mobile Adhoc Networking (B.A.T.M.A.N.) <xref
target="Abolhasan "></xref>protocol was developed
by member of the Freifunk community. The protocol handles all routing at layer 2,
creating one bridged network.</t>
<t>Parallel to BGP, some networks also run the BMX6 protocol <xref target="Neumann">
</xref>. This is an advanced version
of the BATMAN protocol which is based on IPv6 and tries to exploit the social structure
of Community Networks.</t>
</section>
</section>
</section>
<section title="Upper layers">
<!-- Written by Andres -->
<t>From crowd shared perspective, and considering just regular TCP connections during the critical
sharing time, the Access Point offering the CN 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 implement a Less than Best Effort
policy for the CN user and protect the sharer. Achieving LBE behaviour requieres 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 <xref target="RFC6297">RFC 6297</xref>.</t>
<t>The CN user traffic should not interfere with the sharers traffic. However, other bottlenecks
besides client’s access bottleneck may not be controlled by previously mentioned protocols. And
so, recently proposed transport protocols like LETBAT [reference required] with the purpose of transporting scavenger
traffic may be a solution. LEDBAT requieres the cooperation of both the client and the server
to achieve certain target delay, therefore controlling the impact of the CN user all along the
path.</t>
<t>There are applications that manage aspects of CN 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 CN that have been recently proposed by means of SDN <xref target="Sathiaseelan_a">
</xref> <xref target="Suresh"></xref>. There are also other proposals such as Wi2Me
<xref target="Lampropulos"></xref> that manage the connection to several CNs from the client’s
side. This application have shown to improve the client performance compared to a single-CN
client.</t>
<t>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
<xref target="Hanbali"></xref>. 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 <xref target="RFC3135">RFC 3135</xref>. Another way is to adopt end-to-end
solutions for monitoring the connection delay so that the receiver adapts the TCP reception
window (rwnd) <xref target="Castignani_c"></xref>. Similarly, the
ACK Congestion Control (ACKCC) mechanism <xref target="RFC5690">RFC 5690</xref> 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.</t>
<section title="Services provided by these networks">
<t>This section provides an explaining of the services between hosts inside the CN. They can
be divided into Intranet services, connecting hosts between them, and Internet services,
connecting to nodes outside the network.</t>
<section title="Intranet services">
<t>- VoIP (e.g. with SIP)</t>
<t>- remote desktop (e.g. using my computer and my Internet connection when I am on holidays in a village).</t>
<t>- FTP file sharing (e.g. distribution of Linux software).</t>
<t>- P2P file sharing.</t>
<t>- public video cameras.</t>
<t>- DNS.</t>
<t>- online games servers.</t>
<t>- jabber instant messaging.</t>
<t>- IRC chat.</t>
<t>- weather stations.</t>
<t>- NTP.</t>
<t>- Network monitoring.</t>
<t>- videoconferencing / streaming.</t>
<t>- Radio streaming.</t>
</section>
<section title="Access to the Internet">
<section title="Web browsing proxies">
<t>A number of federated proxies provide web browsing service for the users. Other services
(file sharing, skype, etc.) are not usually allowed.</t>
</section>
<section title="Use of VPNs">
<t>Some “micro-ISPs” may use the CN as a backhaul for providing Internet access, setting up
VPNs from the client to a machine with Internet access.</t>
</section>
</section>
</section>
</section>
</section>
<section title="Topology">
<t>These networks follow different topology patterns, as studied in <xref target="Vega"></xref>.</t>
<!-- Perhaps we could summarize the cited paper, talking about how CNs grow, etc.-->
<!-- Written by Andres -->
<t>Regularly rural areas in CNs 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 <xref target="Sathiaseelan_a"></xref> can also extend the
service.</t>
<t>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 CNs users in France, ISPs promise to cause a little
impact on their service agreement when the CN 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 peatonal speed,
there is a fair chance of performing file transfers <xref target="Castignani_a"></xref>
<xref target="Castignani_b"></xref>. In studied scenarios
in France and Luxembourg the density of APs around the urban areas (mainly in downtown
and residential areas) there is a crowded deployment of APs for the 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 CNs. 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
<xref target="Castignani_c"></xref>.</t>
</section>
<section title="Classification">
<t>This section classifies Community 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</t>
<t>Some networks exist, which they are outside the scope of the present document. A first example
are the networks created and managed by City Councils (e.g., <xref target="Heer"></xref>).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.</t>
<section title="Community led Wireless Mesh, led by the people">
<t>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 <xref target="Braem"></xref>.</t>
</section>
<section title="Crowdshared approaches, led by the people and third party stakeholders">
<!--[jose]PAWS (Public Access Wi-Fi Service) can be included here.-->
<t>These networks follow the next 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 scavenger traffic),
to be employed by any user of the service in the immediate area. An example is described in
<xref target="PAWS"></xref>.</t>
<t>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 <xref target="Sathiaseelan_a">
</xref>.</t>
<t>There are three actors in the scenario:</t>
<t>- 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.</t>
<t>- 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.</t>
<t>- Network operators, who have a financial incentive to lease out the unused capacity
<xref target="Sathiaseelan_b"></xref> at lower cost to the VNOs.</t>
<t>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.</t>
</section>
<section title="Testbed">
<t>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
<xref target="Samanta"></xref>.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t></t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<!--<section anchor="Contributing_Authors" title="Contributing Authors">
<t>contrib.</t>
<figure align="left">
<artwork align="left"><![CDATA[
contrib 1
University of ..
Street
1234 city
Country
Phone: +23 349879874
Email: me@anything.com ]]></artwork>
</figure>
</section>
-->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>No security issues have been identified for this document.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&RFC1918;
&RFC2119;
&RFC2328;
&RFC3135;
&RFC3626;
&RFC4271;
&RFC5690;
&RFC6297;
</references>
<references title="Informative References">
<reference anchor="Abolhasan" target="">
<front>
<title>Real-world performance of current proactive multi-hop mesh protocols</title>
<author initials="M." surname="Abolhasan">
<organization>University of Wollongong</organization>
</author>
<author initials="B." surname="Hagelstein">
<organization>University of Wollongong</organization>
</author>
<author initials="J.P." surname="Wang">
<organization>University of Wollongong</organization>
</author>
<date year="2009" />
</front>
<seriesInfo name="In Communications, 2009. APCC 2009. 15th Asia-Pacific Conference on (pp. 44-47). IEEE." value="" />
</reference>
<reference anchor="Avonts" target="">
<front>
<title>A Questionnaire based Examination of Community Networks</title>
<author initials="J." surname="Avonts">
<organization>University of Antwerp - iMinds</organization>
</author>
<author initials="B." surname="Braem">
<organization>University of Antwerp - iMinds</organization>
</author>
<author initials="C." surname="Blondia">
<organization>University of Antwerp - iMinds</organization>
</author>
<date year="2013" />
</front>
<seriesInfo name="Proceedings Wireless and Mobile Computing, Networking and Communications (WiMob), 2013 IEEE 8th International Conference on (pp. 8-15)" value="" />
</reference>
<reference anchor="Braem" target="">
<front>
<title>A case for research with and on community networks</title>
<author initials="B." surname="Braem">
<organization>University of Antwerp - iMinds</organization>
</author>
<author initials="R." surname="Baig Viñas">
<organization>Guifi, Spain</organization>
</author>
<author initials="A.L." surname="Kaplan">
<organization>Funkfeuer, Austria</organization>
</author>
<author initials="A." surname="Neumann">
<organization>Pangea, Spain</organization>
</author>
<author initials="I." surname="Vilata i Balaguer">
<organization>Pangea, Spain</organization>
</author>
<author initials="B." surname="Tatum">
<organization>OPLAN, United Kingdom</organization>
</author>
<author initials="M." surname="Matson">
<organization>OPLAN, United Kingdom</organization>
</author>
<author initials="C." surname="Blondia">
<organization>University of Antwerp - iMinds</organization>
</author>
<author initials="C." surname="Barz">
<organization>Fraunhofer FKIE</organization>
</author>
<author initials="H." surname="Rogge">
<organization>Fraunhofer FKIE</organization>
</author>
<author initials="F." surname="Freitag">
<organization>Universitat Politecnica de Catalunya, Spain</organization>
</author>
<author initials="L." surname="Navarro">
<organization>Universitat Politecnica de Catalunya, Spain</organization>
</author>
<author initials="J." surname="Bonicioli">
<organization>AWMN, Greece</organization>
</author>
<author initials="S." surname="Papathanasiou">
<organization>AWMN, Greece</organization>
</author>
<author initials="P." surname="Escrich">
<organization>Guifi, Spain</organization>
</author>
<date year="2013" />
</front>
<seriesInfo name="ACM SIGCOMM Computer Communication Review" value="vol. 43, no. 3, pp. 68-73" />
</reference>
<reference anchor="Castignani_a" target="">
<front>
<title>An Evaluation of IEEE 802.11 Community Networks Deployments</title>
<author initials="G." surname="Castignani">
<organization>IT/TELECOM Bretagne, Univ. Europ. de Bretagne</organization>
</author>
<author initials="L." surname="Loiseau">
<organization>IT/TELECOM Bretagne, Univ. Europ. de Bretagne</organization>
</author>
<author initials="N." surname="Montavont">
<organization>IT/TELECOM Bretagne, Univ. Europ. de Bretagne</organization>
</author>
<date year="2011" />
</front>
<seriesInfo name="Information Networking (ICOIN), 2011 International Conference on , vol., no., pp.498,503, 26-28" value=""/>
</reference>
<reference anchor="Castignani_b" target="">
<front>
<title>A Study of Urban IEEE 802.11 Hotspot Networks: Towards a Community Access Network</title>
<author initials="G." surname="Castignani">
<organization>University of Luxembourg / SnT</organization>
</author>
<author initials="J." surname="Monetti">
<organization>University of Luxembourg / SnT</organization>
</author>
<author initials="N." surname="Montavont">
<organization>Institut Mines-Telecom / Telecom Bretagne</organization>
</author>
<author initials="A." surname="Arcia-Moret">
<organization>International Centre for Theoretical Physics (ICTP)</organization>
</author>
<author initials="R." surname="Frank">
<organization>University of Luxembourg / SnT</organization>
</author>
<author initials="T." surname="Engel">
<organization>University of Luxembourg / SnT</organization>
</author>
<date year="2013" />
</front>
<seriesInfo name="Wireless Days (WD), 2013 IFIP , pp.1,8, 13-15" value=""/>
</reference>
<reference anchor="Castignani_c" target="">
<front>
<title>A study of the discovery process in 802.11 networks</title>
<author initials="G." surname="Castignani">
<organization>IT/TELECOM Bretagne, Univ. Europ. de Bretagne</organization>
</author>
<author initials="A." surname="Arcia-Moret">
<organization>Universidad de Los Andes, Merida, Venezuela</organization>
</author>
<author initials="N." surname="Montavont">
<organization>IT/TELECOM Bretagne, Univ. Europ. de Bretagne</organization>
</author>
<date year="2011" />
</front>
<seriesInfo name="SIGMOBILE Mob. Comput. Commun. Rev., vol. 15, no. 1, p. 25" value=""/>
</reference>
<reference anchor="Flickenger" target="">
<front>
<title>Very Long Distance Wi-Fi Networks</title>
<author initials="R." surname="Flickenger">
<organization></organization>
</author>
<author initials="S." surname="Okay">
<organization></organization>
</author>
<author initials="E." surname="Pietrosemoli">
<organization></organization>
</author>
<author initials="M." surname="Zennaro">
<organization></organization>
</author>
<author initials="C." surname="Fonda">
<organization></organization>
</author>
<date year="2008" />
</front>
<seriesInfo name="NSDR 2008, The Second ACM SIGCOMM Workshop on Networked Systems for Developing Regions. USA, 2008" value=""/>
</reference>
<reference anchor="Hanbali" target="">
<front>
<title>A Survey of TCP over Ad Hoc Networks</title>
<author initials="A. Al" surname="Hanbali">
<organization>INRIA Sophia Antipolis, France</organization>
</author>
<author initials="E." surname="Altman">
<organization>INRIA Sophia Antipolis, France</organization>
</author>
<author initials="P." surname="Nain">
<organization>INRIA Sophia Antipolis, France</organization>
</author>
<date year="2005" />
</front>
<seriesInfo name="IEEE Commun. Surv. Tutorials, vol. 7, pp. 22–36" value=""/>
</reference>
<reference anchor="Heer" target="">
<front>
<title>Collaborative municipal Wi-Fi networks-challenges and opportunities</title>
<author initials="T." surname="Heer">
<organization>RWTH Aachen Universiy</organization>
</author>
<author initials="R." surname="Hummen">
<organization>RWTH Aachen Universiy</organization>
</author>
<author initials="N." surname="Viol">
<organization>RWTH Aachen Universiy</organization>
</author>
<author initials="H." surname="Wirtz">
<organization>RWTH Aachen Universiy</organization>
</author>
<author initials="S." surname="Gotz">
<organization>RWTH Aachen Universiy</organization>
</author>
<author initials="K." surname="Wehrle">
<organization>RWTH Aachen Universiy</organization>
</author>
<date year="2010" />
</front>
<seriesInfo name="Pervasive Computing and Communications Workshops (PERCOM Workshops), 2010 8th IEEE International Conference on (pp. 588-593). IEEE." value=""/>
</reference>
<reference anchor="IEEE" target="">
<front>
<title>IEEE Standards association</title>
<author>
<organization>Institute of Electrical and Electronics Engineers, IEEE</organization>
</author>
<date year="2012"></date>
</front>
</reference>
<reference anchor="Neumann" target="">
<front>
<title>An evaluation of bmx6 for community wireless networks</title>
<author initials="A." surname="Neumann">
<organization>UPC</organization>
</author>
<author initials="E." surname="Lopez">
<organization>UPC</organization>
</author>
<author initials="L." surname="Navarro">
<organization>UPC</organization>
</author>
<date year="2012" />
</front>
<seriesInfo name="In Wireless and Mobile Computing, Networking and Communications (WiMob), 2012 IEEE 8th International Conference on (pp. 651-658). IEEE." value=""/>
</reference>
<reference anchor="PAWS" target="">
<front>
<title>Public Access WiFi Service (PAWS)</title>
<author initials="A." surname="Sathiaseelan">
<organization>Univ. of Cambridge</organization>
</author>
<author initials="J." surname="Crowcroft">
<organization>Univ. of Cambridge</organization>
</author>
<author initials="M." surname="Goulden">
<organization></organization>
</author>
<author initials="C." surname="Greiffenhagen">
<organization></organization>
</author>
<author initials="R." surname="Mortier">
<organization></organization>
</author>
<author initials="G." surname="Fairhurst">
<organization></organization>
</author>
<author initials="D." surname="McAuley">
<organization></organization>
</author>
<date month="Oct" year="2012" />
</front>
<seriesInfo name="Digital Economy All Hands Meeting, Aberdeen" value=""/>
</reference>
<reference anchor="Pietrosemoli" target="">
<front>
<title>Low cost carrier independent telecommunications infrastructure</title>
<author initials="E." surname="Pietrosemoli">
<organization></organization>
</author>
<author initials="M." surname="Zennaro">
<organization></organization>
</author>
<author initials="C." surname="Fonda">
<organization></organization>
</author>
<date year="2012" />
</front>
<seriesInfo name="In proc. 4th Global Information Infrastructure and Networking Symposium, Choroni, Venezuela" value=""/>
</reference>
<reference anchor="Rendon" target="">
<front>
<title>Tecnologías de la Información y las Comunicaciones para zonas rurales Aplicación a la atención de salud en países en desarrollo</title>
<author initials="A." surname="Rendon">
<organization>Universidad Rey Juan Carlos, Madrid, Spain</organization>
</author>
<author initials="P.J." surname="Ludena">
<organization>Universidad Rey Juan Carlos, Madrid, Spain</organization>
</author>
<author initials="A." surname="Martinez Fernandez">
<organization>Universidad Rey Juan Carlos, Madrid, Spain</organization>
</author>
<date year="2011" />
</front>
<seriesInfo name="CYTED. Programa Iberoamericano de Ciencia y Tecnología para el Desarrollo" value=""/>
</reference>
<reference anchor="Samanta" target="">
<front>
<title>Metropolitan Wi-Fi Research Network at the Los Angeles State Historic Park</title>
<author initials="V." surname="Samanta">
<organization>UCLA, Los Angeles, USA</organization>
</author>
<author initials="C." surname="Knowles">
<organization>UCLA, Los Angeles, USA</organization>
</author>
<author initials="J." surname="Wagmister">
<organization>UCLA, Los Angeles, USA</organization>
</author>
<author initials="D." surname="Estrin">
<organization>UCLA, Los Angeles, USA</organization>
</author>
<date month="May" year="2008" />
</front>
<seriesInfo name="The Journal of Community Informatics, North America, 4" value=""/>
</reference>
<reference anchor="Sathiaseelan_a" target="">
<front>
<title>Virtual Public Networks</title>
<author initials="A." surname="Sathiaseelan">
<organization>Univ. of Cambridge</organization>
</author>
<author initials="C." surname="Rotsos">
<organization>Univ. of Cambridge</organization>
</author>
<author initials="C.S." surname="Sriram">
<organization>Paxtera Solutions</organization>
</author>
<author initials="D." surname="Trossen">
<organization>Univ. of Cambridge</organization>
</author>
<author initials="P." surname="Papadimitriou">
<organization>Leibniz Universitat Hannover</organization>
</author>
<author initials="J." surname="Crowcroft">
<organization>Univ. of Cambridge</organization>
</author>
<date year="2013" />
</front>
<seriesInfo name="In Software Defined Networks (EWSDN), 2013 Second European Workshop on (pp. 1-6). IEEE." value=""/>
</reference>
<reference anchor="Sathiaseelan_b" target="">
<front>
<title>LCD-Net: Lowest Cost Denominator Networking</title>
<author initials="A." surname="Sathiaseelan">
<organization>Univ. of Cambridge</organization>
</author>
<author initials="J." surname="Crowcroft">
<organization>Univ. of Cambridge</organization>
</author>
<date month="Apr" year="2013" />
</front>
<seriesInfo name="ACM SIGCOMM Computer Communication Review" value=""/>
</reference>
<reference anchor="Suresh" target="">
<front>
<title>Towards Programmable Enterprise WLANs with ODIN</title>
<author initials="L." surname="Suresh">
<organization>Instituto Superior Tecnico, Lisbon, Portugal</organization>
</author>
<author initials="J." surname="Schulz-Zander">
<organization>Telekom Innovation Laboratories / TU Berlin</organization>
</author>
<author initials="R." surname="Merz">
<organization>Telekom Innovation Laboratories / TU Berlin</organization>
</author>
<author initials="A." surname="Feldmann">
<organization>Telekom Innovation Laboratories / TU Berlin</organization>
</author>
<author initials="T." surname="Vazao">
<organization>Instituto Superior Tecnico, Lisbon, Portugal</organization>
</author>
<date year="2012" />
</front>
<seriesInfo name="In Proceedings of the first workshop on Hot topics in software defined networks (HotSDN '12). ACM, New York, NY, USA, 115-120" value=""/>
</reference>
<reference anchor="Lampropulos" target="">
<front>
<title>Wi2Me: A Mobile Sensing Platform for Wireless Heterogeneous Networks</title>
<author initials="A." surname="Lampropulos">
<organization>IT/TELECOM Bretagne, Univ. Europ. de Bretagne</organization>
</author>
<author initials="G." surname="Castignani">
<organization>IT/TELECOM Bretagne, Univ. Europ. de Bretagne</organization>
</author>
<author initials="A." surname="Blanc">
<organization>IT/TELECOM Bretagne, Univ. Europ. de Bretagne</organization>
</author>
<author initials="N." surname="Montavont">
<organization>IT/TELECOM Bretagne, Univ. Europ. de Bretagne</organization>
</author>
<date year="2012" />
</front>
<seriesInfo name="32nd International Conference on Distributed Computing Systems Workshops (ICDCS Workshops), 2012, pp. 108–113" value=""/>
</reference>
<reference anchor="Vega" target="">
<front>
<title>Topology patterns of a community network: Guifi. net.</title>
<author initials="D." surname="Vega">
<organization>Universitat Politecnica de Catalunya</organization>
</author>
<author initials="L." surname="Cerda-Alabern">
<organization>Universitat Politecnica de Catalunya</organization>
</author>
<author initials="L." surname="Navarro">
<organization>Universitat Politecnica de Catalunya</organization>
</author>
<author initials="R." surname="Meseguer">
<organization>Universitat Politecnica de Catalunya</organization>
</author>
<date year="2012" />
</front>
<seriesInfo name="Proceedings Wireless and Mobile Computing, Networking and Communications (WiMob), 2012 IEEE 8th International Conference on (pp. 612-619)" value=""/>
</reference>
<reference anchor="WNDW" target="">
<front>
<title>Wireless Networking in the Developing World, 3rd Edition</title>
<author>
<organization>Wireless Networking in the Developing World/Core Contributors</organization>
</author>
<date year="2013" />
</front>
<seriesInfo name="The WNDW Project, available at wndw.net" value=""/>
</reference>
<reference anchor="WSIS" target="">
<front>
<title>Declaration of Principles. Building the Information Society: A global challenge in the new millenium</title>
<author>
<organization>International Telecommunications Union, ITU</organization>
</author>
<date month="Dec" year="2013" />
</front>
<seriesInfo name="World Summit on the Information Society, 2003, at http://www.itu.int/wsis, accessed 12 January 2004." value=""/>
</reference>
<reference anchor="Zennaro" target="">
<front>
<title>On a long wireless link for rural telemedicine in Malawi</title>
<author initials="M." surname="Zennaro">
<organization></organization>
</author>
<author initials="C." surname="Fonda">
<organization></organization>
</author>
<author initials="E." surname="Pietrosemoli">
<organization></organization>
</author>
<author initials="A." surname="Muyepa">
<organization></organization>
</author>
<author initials="S." surname="Okay">
<organization></organization>
</author>
<author initials="R." surname="Flickenger">
<organization></organization>
</author>
<author initials="S.M." surname="Radicella">
<organization></organization>
</author>
<date month="Nov" year="2008" />
</front>
<seriesInfo name="6th International Conference on Open Access, Lilongwe, Malawi" value=""/>
</reference>
</references>
<!-- Change Log
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:47:47 |