To keep CONFINE a relevant project, the CONFINE research should remain useful to community networks.

So we have asked all current (11/2013) three community networks for their challenges. Below is a list of challenges, from the different networks.

sink: internet uplink / gateway.

Be able to distinguish between layer 2 and layer 3 links in a graph. How? Annotate a toplogy (dot(1)) graph. What's the best way?

What is the best internal data structure for our topologies?

Should we make a recommendation for a data structure which helps networks/CWNs to compare their topologies and your our tools for analysis?

This is a tough one. Essentially we have a multi-dimensional constraint solving issue here (constraint solving programming or optimisations from the field of operational research topics come to mind immediately) . Please note that the text below is just a *proposal*/ a first rough sketch.

Given:

• be x a potential new node / device specified by the parameters (gps(lat,lon,h), …)
• be T a topology (graph theoretic),
• be S a set of time series for each radio/device/node and each to be measured layer 2 or 3 value (biterror rate, SNR, noise, signal, qbss value, airtime availability, bitrate, measured throughput,…) and
• be H a geographic hight map,

Let M be a metric on T

Then Sol = an ordered list of [ (node, metric) ,…] such that the entries in this list are an estimate of which nodes this new node x should try to connect to first (by order in the list). The order is given by to constraints listed above:

• nodes which are not visible (LoS) are excluded
• nodes which do not give internet uplink (a path to a sink) are excluded (they are not interesting)
• the metric M influences the order in Sol: nodes with higher metrics are listed first. The metric shall indicate the value for connecting to that specific node (for example ETX metric ~= packloss is reduced).

Variations

1. further add to the constraints by specifying the wireless frequency and/or the antenna pattern
2. maximise personal uplink (as defined by metric)
3. maximise network wide throughput/latency/benefit (as definied by metric)

Note: the last two variations might be in conflict.

Measuring the quality of automatic channel assignments algorithms with the help of users

Suggest much needed intermediate nodes and give a list of their minimum speeds/maximum packetloss etc.

find super-nodes

automatic fault-tree analysis (by using dominator tree ) - each node should have at least 2-3 independent paths to a sink

Node analysis:

• Types etc
• weak points of the network: Connectivity, Bandwidth, Link quality, Other metrics

Other Node characteristics

BMX6 research performed by the UPC is being very useful for Guifi. BMX6 is the mesh routing protocol used by the qMp system. Guifi.net is mainly BGP and privative software and qMp is a free software alternative which is being used in many places of the community network.

The DLEP research might be useful for our community network. It is not yet introduced but it seems a nice approach for building cheap nodes with many radio/antennas.

Researchers should provide clear uses cases to let the community know how to adopt it.

The original RFC draft of DLEP might be not enough flexible and useful for the community. We would like to ask to the DLEP researchers to do not follow line-by-line the draft but implement such new features which may be useful in a real environment.

BGP layer2 awareness: adjust metric based on link quality

Experimentation with Encryption, Authorization and Privacy, For all Community Network Applications

The Open Data provided by the Confine researchers is not directly useful for us (yet?). However, since the Open Data idea is now very popular, we may use it to attract attention from the public administration or private entities and collaborate together in projects which benefit our community.

Guifi.net could provide BGP Open Data sets but we need the properly tools and the support from the researchers to do it.

Open Data:

• BGP Data (BGP historical data parser και grapher)
• SNMP data
• Neighbor Protocol Data
• Flow data
• Latency ( Smokeping )
• Failures - Outages ( Nagios )
• Users Analysis

We find the community-lab software very useful for our community. It is not strong attached to the research purposes so it might be used as a distributed cloud platform to publicy services. Any user in the network can easy create a virtual machine to publish his own service or just a private slice to run some experiment.

Furthermore, what might be more useful to is to be able to integrate the current community device into the research device as a special CONFINE sliver.

3×3 MIMO 5GHz RF Feeders