Bluetooth mesh is now a thing

64 views
Skip to first unread message

Rob Thomas

unread,
Sep 3, 2019, 6:33:22 PM9/3/19
to serval-proje...@googlegroups.com

Paul Gardner-Stephen

unread,
Sep 3, 2019, 10:41:40 PM9/3/19
to Serval Project Developers
Hi Rob,

Yes, I saw it, too.

Paul.

On Wed, 4 Sep 2019 at 08:03, Rob Thomas <xro...@gmail.com> wrote:
--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/serval-project-developers/CAC5zRjOS1r7nTNuDiO3r2AFAAN6uzWyNVnka3GKpLg2LhVRieg%40mail.gmail.com.

Lumvn Charythial

unread,
Sep 4, 2019, 12:48:22 PM9/4/19
to serval-proje...@googlegroups.com
Is there a standard protocol for this, or is it proprietary to each app?  It's one thing to tell everyone in your group to go download a certain app,  but it would be nice to have a protocol that competing apps can use so everyone can be ready for the unplanned.

john whelan

unread,
Sep 4, 2019, 12:59:50 PM9/4/19
to Serval Project Developers
Although mesh on the phones works in my mind using Wi-Fi to a router might be better.  Tp-link for example have at least one that can be powered from USB so a battery pack.

Then you need to address identifying the phones and perhaps run a mesh network on the routers.  Commotion is one possibility.

Messaging needs to be done over the top.

Anyway just idle thoughts although if it could be put together then it opens up a lot of possibilities.  Not least is Wi-Fi with the right equipment can work over 15 km or more using standard protocols.

Cheerio John

Paul Gardner-Stephen

unread,
Sep 4, 2019, 4:52:56 PM9/4/19
to Serval Project Developers
Hello,

The problem is that there is no "one protocol to bind them all" when it comes to mesh telephony, because this is an area that is still very much being worked on by different people. Also, the particular use-case really influences what is the best approach.  Delay-tolerant networking requires very different protocols to phone calls.  Also, getting broad support across many different devices is a real pain.  So, unfortunately, the space is rather fragmented. We are trying to work with some other projects to bring greater harmonisation where possible. In particular, Commotion and a couple of others also use Serval's Rhizome Delay Tolerant Networking layer.

Paul..

Paul Gardner-Stephen

unread,
Sep 4, 2019, 4:54:21 PM9/4/19
to Serval Project Developers
Hello,

On Thu, 5 Sep 2019 at 02:29, john whelan <jwhel...@gmail.com> wrote:
Although mesh on the phones works in my mind using Wi-Fi to a router might be better.  Tp-link for example have at least one that can be powered from USB so a battery pack.

This is exactly what the Serval Mesh Extender does for all of these reasons.
 

Then you need to address identifying the phones and perhaps run a mesh network on the routers.  Commotion is one possibility.

Messaging needs to be done over the top.

Correct. This is how Serval Mesh and Serval Chat work.


Anyway just idle thoughts although if it could be put together then it opens up a lot of possibilities.  Not least is Wi-Fi with the right equipment can work over 15 km or more using standard protocols.

Correct, and with UHF packet radio or HF packet radio, this can be increased considerably.  But again, for delay tolerant networking, TCP etc is simply not a solution, as you might have individual links up or down at any point, but rarely anything like an end to end link.

Paul.

john whelan

unread,
Sep 4, 2019, 7:37:34 PM9/4/19
to Serval Project Developers
So currently a GL-AR150 can be used as a mesh extender although you'd want a two or three to play with.  That would give you a basic WiFi based network.  Is there documentation lying around somewhere?

"Real soon now" if enough people are interested mesh extender 2.0 which incorporates a radio will hopefully be available to play with for around $200 a unit.

Yes I realise that it can be used with phones by themselves but the extenders add a lot of functionality.

Thanks John



Paul Gardner-Stephen

unread,
Sep 4, 2019, 10:54:20 PM9/4/19
to Serval Project Developers
Hello,

http://developer.servalproject.org and follow the links to 2nd generation Mesh Extenders.  They can run the same firmware as the GL-AR150.

Paul.

john whelan

unread,
Sep 5, 2019, 7:53:13 AM9/5/19
to Serval Project Developers

Roland Turner

unread,
Sep 5, 2019, 11:58:20 PM9/5/19
to serval-proje...@googlegroups.com
Why is that device useful as a range extender? It appears to be a low power (63mW) 2.4GHz-only WiFi-only access point.

- Roland



Paul Gardner-Stephen

unread,
Sep 5, 2019, 11:59:39 PM9/5/19
to Serval Project Developers
Two reasons:

1. We add a UHF packet radio to it for longer-range communications.
2. It runs the Serval Rhizome Delay-Tolerant Networking software, that allows it to cache messages for later forwarding, so it doesn't matter if there is no stable end-to-end link.

Paul.
Hello,


Cheerio John

To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsub...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsub...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsub...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsub...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsub...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsub...@googlegroups.com.

john whelan

unread,
Sep 6, 2019, 10:21:16 AM9/6/19
to Serval Project Developers
Comment one is a phone to phone wifi maximum distance is shorter than a phone to router distance.  Typically routers have better aerials and stronger signals.

Comment two is to do with Serval's niche.  The rate of change in communication networks and computers is rapid.  Remember Fidonet?  It came before the internet and was a way to exchange email and messages on low band width dial up connections.  It would zip the messages to compress them to keep bandwidth requirements down.   Routers can now be run off a USB power supply.  Different versions of Android support different WiFi options.  These are all big changes.

Serval being university based means they have to plan what to do, then ask nicely for funding, then do it.  Takes a longer time than someone writing an app that runs over WiFi Direct.

Serval does three things at the client end, messaging, file transfer and voice.  It started off with all three.  Voice over a mesh network is difficult because of lag.  The newer flasher peer to peer software mainly do just the easy bit of messaging.

Then you get to the requirements.  If internet access is cheap enough and available it offers a lot more options.  In a disaster scenario internet access may not be available or if it is it will be a slow satellite connection.  

Often if you can preplan something it's cheaper.  The Red Cross for example has a Intel NUC preloaded with software it uses for communication etc in Africa.

Then you get to what are you trying to do and how much money do you have.

Can you combine requirements and resources? That takes planning and time and time is often a luxury you don't have in responding to a disaster.

wndw.net is a good site to look at some of these issues.

Distance matters, and the mesh extenders with a radio are a fairly cheap way to get distance. 

If you have the local expertise then I think a Commotion network with an email server (Postfix?) and possibly an Asterisk voip server although I've never managed to get Asterisk configured to send SMS messages would work well but setting it up, configuring it and keeping it maintained would be interesting.  Note an SSD can be plugged into a Router USB port these days to give you NAS file sharing with vengeance, microSD cards are an alternative.  It's main advantage is that clients can continue to use their software they're used to and training is a killer.  The other plus side would be that emails could be sent to clients outside the network if even a slow internet connection was available at odd hours.  Typically 2 am to 8 am internet connections are much cheaper.  The drawback is it takes time and expertise to set up, Serval doesn't.

How far could you get with a router with memory for file sharing?  I'm not sure but it could do simple messaging its when you want to extend it beyond one router or LAN that it gets difficult and that is where Serval comes in.

I think the core functionality of Serval is good.  I'm not terribly happy with the way it changes the name of the phone, and I look forward to seeing a way to extend messaging and file transmission off the Serval mesh network.

Cheerio John





Paul Gardner-Stephen

unread,
Sep 6, 2019, 7:37:50 PM9/6/19
to Serval Project Developers
Hi John,

On Fri, 6 Sep 2019 at 23:51, john whelan <jwhel...@gmail.com> wrote:
Comment one is a phone to phone wifi maximum distance is shorter than a phone to router distance.  Typically routers have better aerials and stronger signals.

Yes, we are quite familiar with this problem.


Comment two is to do with Serval's niche.  The rate of change in communication networks and computers is rapid.  Remember Fidonet?  It came before the internet and was a way to exchange email and messages on low band width dial up connections.  It would zip the messages to compress them to keep bandwidth requirements down.   Routers can now be run off a USB power supply.  Different versions of Android support different WiFi options.  These are all big changes.

Yes, which is why we have focused on the Serval Mesh Extender as relay device, and which runs a wifi AP, so that phones just connect to it using stink-normal wifi.
 

Serval being university based means they have to plan what to do, then ask nicely for funding, then do it.  Takes a longer time than someone writing an app that runs over WiFi Direct.

Serval does three things at the client end, messaging, file transfer and voice.  It started off with all three.  Voice over a mesh network is difficult because of lag.  The newer flasher peer to peer software mainly do just the easy bit of messaging.

We have also been focusing on messaging and file transfer the last few years, precisely because they can be done easily over DTN.  Voice mail is also possible for the same reasons.
 

Then you get to the requirements.  If internet access is cheap enough and available it offers a lot more options.  In a disaster scenario internet access may not be available or if it is it will be a slow satellite connection.  

Exactly. We are building solutions for when the internet isn't available, for whatever reason.
 

Often if you can preplan something it's cheaper.  The Red Cross for example has a Intel NUC preloaded with software it uses for communication etc in Africa.

Correct. But, again, we are building for when such solutions aren't possible -- whatever the reason.
 

Then you get to what are you trying to do and how much money do you have.

Can you combine requirements and resources? That takes planning and time and time is often a luxury you don't have in responding to a disaster.

This is why we work with Red Cross and UN WFP.  The goal is that we have pre-prepared fly-away packs as part of their regular logistics chain.  They want this capability.
 
wndw.net is a good site to look at some of these issues.

Distance matters, and the mesh extenders with a radio are a fairly cheap way to get distance. 

Exactly.  We can also connect Mesh Extenders to HF radios to provide very long range connections, basically to automate much of the kind of message passing that HAMs often do now in disasters, but also with security (and thus not using HAM frequences, but the frequencies of Red Cross and other parties who have licensed HF spectrum and thus are allowed to encrypt).
 

If you have the local expertise then I think a Commotion network with an email server (Postfix?)

Commotion uses a bunch of Serval protocols under the hood ;)
 
 and possibly an Asterisk voip server although I've never managed to get Asterisk configured to send SMS messages would work well but setting it up, configuring it and keeping it maintained would be interesting.  Note an SSD can be plugged into a Router USB port these days to give you NAS file sharing with vengeance, microSD cards are an alternative.  It's main advantage is that clients can continue to use their software they're used to and training is a killer.  The other plus side would be that emails could be sent to clients outside the network if even a slow internet connection was available at odd hours.  Typically 2 am to 8 am internet connections are much cheaper.  The drawback is it takes time and expertise to set up, Serval doesn't.

This lack of setup / training etc is a key feature/goal of Serval.
 

How far could you get with a router with memory for file sharing?  I'm not sure but it could do simple messaging its when you want to extend it beyond one router or LAN that it gets difficult and that is where Serval comes in.

Right. And indeed the Mesh Extenders are basically a router with memory for file sharing, and the means to replicate automatically over multiple hops.


I think the core functionality of Serval is good.  I'm not terribly happy with the way it changes the name of the phone, and I look forward to seeing a way to extend messaging and file transmission off the Serval mesh network.

The new version of the app won't do that. That was a hack for transferring data over bluetooth when bluetooth was much less mature. We are currently trying to get the new version ready for release.  You can take a sneak peak at developer.servalproject.org/files/chat/alpha
 
Paul.


Cheerio John






On Thu, 5 Sep 2019 at 23:58, 'Roland Turner' via Serval Project Developers <serval-proje...@googlegroups.com> wrote:
Why is that device useful as a range extender? It appears to be a low power (63mW) 2.4GHz-only WiFi-only access point.

- Roland

--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-dev...@googlegroups.com.

Roland Turner

unread,
Sep 10, 2019, 6:22:46 PM9/10/19
to serval-proje...@googlegroups.com
Hi John,

You've made a series of generic arguments about the benefits of easy-to-deploy infrastructure, and particularly repurposed access points, which are all pretty obvious from the perspective of the objectives Serval project.

That wasn't my question. My question was about why the GL-AR150 device in particular was of interest. On the face of it, it does not appear to be an usually interesting choice. For example, a more widely available device (you mentioned the NUC) would appear a more obvious starting point.

- Roland



--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-dev...@googlegroups.com.

Roland Turner

unread,
Sep 10, 2019, 6:22:46 PM9/10/19
to serval-proje...@googlegroups.com, Paul Gardner-Stephen
Which radio?

- Roland



To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/serval-project-developers/fbe4a22e-caee-4a7d-8ed5-6775d76deba7%40googlegroups.com.


john whelan

unread,
Sep 10, 2019, 7:45:53 PM9/10/19
to Serval Project Developers
I have a number of complementary interests and more experience than I care to relate.  Remembering that experience is what you get when you don't get what you want.

One problem that has come up in the past is refuge camps.  Lots of smartphones but not much internet bandwidth.

Then you get the African village where step one is just to show what is available.  Typically after you drop in a low cost network demand grows and it becomes economic to put in a conventional node.

Disaster is something else.  The users have education and want something reliable but there is little time for training.  My gut feel is there is a demand for internet access even if its only email through a satellite phone.

Then you get what I'd call groups of hikers / climbers etc.  A GL-AR150 on top of a back pack is one solution with the hikers using phones.  They're interesting because they have money.  $100 for a pair of two way radios is a minor expense, a Serval networking mesh with a radio extender should be able to send the location from the smartphone without having to worry about reading it out and writing it down.

The GL-AR150 with a small aerial can be used in a number of different ways.  First it can be run from a conventional smartphone battery pack.  Add in Linphone on smartphones and you get messaging and voice connections over a longer distance than just smartphone to smartphone.  You don't need an internet connection the LAN works fine.  You can also add in Linphone on a laptop to this mixture.  This solution needs testing and documenting.

90% of the traffic in a camp is probably within the camp you've just saved a lot of internet bandwidth.  If the money is there and the electricity is as well then you can put up a bigger router to extend the system.

The GL-AR150 is just a router.  However it has a fair bit of memory on it and it can also have the serval mesh extender firmware burnt to it.  I suspect it can also run commotion network software but that requires expertise in the field to set up.

An Intel NUC is a computer so something that connects to a router.  You might put services on it such as DNS, Astrix for phones, an email server etc.  For a person to use it they'd need a screen and a keyboard.  It has WiFi but only to the extent that a smartphone or laptop has it.  ie not much range.  A raspberry pi might work as well as the current it needs is much lower.  However Win 10 has a kinder user interface than Unix and that's what you want for reliability which sort of suggests laptops.

I believe the Red Cross set up works if you bring the phone and the NUC box very close together.  They get a lot of control but you need a lot of thought about how to tie it all together.

Then you get to the Serval niche which is distance in low population areas.  Yes radios work quite well but so can Serval with a digital radio plugged into the mesh extender which is where Paul is working on at the moment.  The nice thing here is once you know the Serval interface then its easier to use than a conventional radio.  Serval can work with a couple of different radios, as Paul mentioned its sort of Lego plugging together.

Does that clarify?

Cheerio John





john whelan

unread,
Sep 10, 2019, 8:03:39 PM9/10/19
to Serval Project Developers
One final comment when New York was flooded and there was no power there was technical expertise and a Commotion network ran with a high up Wi-Fi antenna so phones could use email and messaging until power was restored.

Cheerio John

Jan Lühr

unread,
Sep 11, 2019, 3:43:16 AM9/11/19
to serval-proje...@googlegroups.com
Heiho,

Am 11/09/2019 um 01.45 schrieb john whelan:
> I have a number of complementary interests and more experience than I
> care to relate.  Remembering that experience is what you get when you
> don't get what you want.
>
> One problem that has come up in the past is refuge camps.  Lots of
> smartphones but not much internet bandwidth.
>
> Then you get the African village where step one is just to show what is
> available.  Typically after you drop in a low cost network demand grows
> and it becomes economic to put in a conventional node.
>
> Disaster is something else.  The users have education and want something
> reliable but there is little time for training.  My gut feel is there is
> a demand for internet access even if its only email through a satellite
> phone.
Not sure - it might not that different from the camp situation. When
asked about messaging in emergency.lu, Gilles wrote:

"What we found out is that people (users) are basically using the same
apps in the field they use during "freedom times" at home.
That is true for messaging but also for all other tools.

For messaging that means that +90% of the people use WhatsApp and similar.
Those apps have also proven to be very stable and work well."

That somehow makes IP-access first class. From what I've heard, their
network is used in real-world situations

But I guess, there's a ground for ideas like serval, still: Teams -
especially when run by volunteers - usually use some apps for
coordination or recruiting / advertisements. From the UX point of view
you it's to closer rocket chat / MS teams than to WhatsApp / signal.

Greetz, yanosz


--
There's a ripped off cord
To my TV screen
With a note saying:
"Im not afraid to dream"
-- Donkey Boy, Crazy Something Normal

john whelan

unread,
Sep 11, 2019, 7:42:57 AM9/11/19
to Serval Project Developers
>Not sure - it might not that different from the camp situation. When
asked about messaging in emergency.lu, Gilles wrote:

"What we found out is that people (users) are basically using the same
apps in the field they use during "freedom times" at home.
That is true for messaging but also for all other tools.

For messaging that means that +90% of the people use WhatsApp and similar.
Those apps have also proven to be very stable and work well."

That somehow makes IP-access first class. From what I've heard, their
network is used in real-world situations

But I guess, there's a ground for ideas like serval, still: Teams -
especially when run by volunteers - usually use some apps for
coordination or recruiting / advertisements. From the UX point of view
you it's to closer rocket chat / MS teams than to WhatsApp / signal


Which comes back to training and user interface.  One of the biggest problems is having to rebuild the list of contacts.  When you have limited or no Internet access then keeping things on the LAN keeps the Internet traffic down and that's where Linphone and Serval etc. are very useful tools.  Besides I don't trust Facebook but that's another story.

Cheerio John

Paul Gardner-Stephen

unread,
Sep 11, 2019, 12:48:06 PM9/11/19
to Serval Project Developers
Hallo Jan,

wie geht's? Antwort steht unten...

Actually, the issue is when internet isn't available for whatever reason -- then something like Serval is vital.  If internet is available, then of course Serval isn't needed, but we know that this isn't always the case.

Paul.
 

Greetz, yanosz


--
There's a ripped off cord
To my TV screen
With a note saying:
"Im not afraid to dream"
-- Donkey Boy, Crazy Something Normal

--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-dev...@googlegroups.com.

yanosz

unread,
Sep 11, 2019, 1:32:52 PM9/11/19
to serval-proje...@googlegroups.com
Hello,


Am 11/09/2019 um 18.47 schrieb Paul Gardner-Stephen:

[..]
> But I guess, there's a ground for ideas like serval, still: Teams -
> especially when run by volunteers - usually use some apps for
> coordination or recruiting / advertisements. From the UX point of view
> you it's to closer rocket chat / MS teams than to WhatsApp / signal.
>
>
> Actually, the issue is when internet isn't available for whatever reason
> -- then something like Serval is vital.  If internet is available, then
> of course Serval isn't needed, but we know that this isn't always the case.

These are just two extremes. In the real world, its likely that internet
can be made available (e.g. think of emergency.lu dropping some
inflatable satellite dishes), but cost and capacity very a lot.

It's not even clear, what "Internet" actually means nowadays, people use
"Internet"-Of-Things networks, that don't use IP for large parts of it
(e.g. LoraWAN). For some people internet means IP communication across
different Autonomous Systems (AS), others know much about "the
internet", but have no clue about RFC4271.

I don't like to think in these extremes or technical details - I prefer
UX: For a user, it doesn't really matter what network technology is used
to deliver a message. In the end, it's "internet" if you can reach
virtually anybody on this planet using computers (i.e. without being
restricted to telephones).

But UX is lost, if you need a dedicated App per network technology - are
you going to try all of 'em, if you don't know the network the receiver
is active atm? In essence you need an App taking care of selecting the
correct channel, while providing a homogeneous UX.

Thus: serval (as in a working serval app) is needed, even if internet is
available.

From the UX perspective, messaging is and was always delay tolerant
(offline messages in instant messaging, email / uucp etc.) and the UX is
fine. You won't loose much if you integrate DTNs in regular messaging apps.

Paul Gardner-Stephen

unread,
Sep 11, 2019, 1:54:36 PM9/11/19
to Serval Project Developers
Hello,

Yes, I agree that the Serval app should work when Internet is available as well, if we can muster the development effort to do so.  Really the implicit goal of Serval is to make messaging possible regardless of the crazy communications channels available.  The Mesh Extender can be seen as a radio to wifi abstraction layer in this sense.

Our challenge right now is that we don't have the resources to push ahead on this. If folks were interested in helping out on this front, that would be super welcome.

Paul
 

Greetz, yanosz

--
There's a ripped off cord
To my TV screen
With a note saying:
"Im not afraid to dream"
-- Donkey Boy, Crazy Something Normal

--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-dev...@googlegroups.com.

Roland Turner

unread,
Sep 12, 2019, 1:06:27 AM9/12/19
to serval-proje...@googlegroups.com
Hi John,

OK, tiny WiFi router on a tent-pole/tree/etc. with no UHF radio is a potentially interesting use case. The question is still begged though: why use a relatively obscure device when comparable widely-available devices are in the same price range? By way of example: the TP-Link MR3020.

(Also, spec sheets are hard to find for the GL-AR150, however at least one example of real-world testing reveals unusually poor range on a like-for-like basis.)

- Roland



john whelan

unread,
Sep 12, 2019, 7:36:49 AM9/12/19
to Serval Project Developers
Serval used to use the mr3020 but the US government brought in a rule that makes it almost impossible to change the firmware.

Serval mesh extenders were based on the 2030 with addition memory kudgled in but the 150 is available with more memory, has an optional external aerial, ships with WRT operating system, takes the same code so is now the base system for the mesh extender, can also be used as a Wi-Fi extender and since it is WRT based can be used in a Commotion network.

Lan messenger will run on a single router with mobiles.

Next question?

Thanks John

Roland Turner

unread,
Sep 12, 2019, 9:51:02 AM9/12/19
to serval-proje...@googlegroups.com
Ah, yes, that's biting the amateur radio community as well. Obscure Chinese devices it is then.

- Roland



yanosz

unread,
Sep 13, 2019, 11:01:45 AM9/13/19
to serval-proje...@googlegroups.com
Hello,

Am 11/09/2019 um 19.54 schrieb Paul Gardner-Stephen:
> On Thu, 12 Sep 2019 at 03:02, yanosz <serval-...@yanosz.net
> <mailto:serval-...@yanosz.net>> wrote:
> Am 11/09/2019 um 18.47 schrieb Paul Gardner-Stephen:
>

> Yes, I agree that the Serval app should work when Internet is available
> as well, if we can muster the development effort to do so.  Really the
> implicit goal of Serval is to make messaging possible regardless of the
> crazy communications channels available.  The Mesh Extender can be seen
> as a radio to wifi abstraction layer in this sense.
>
> Our challenge right now is that we don't have the resources to push
> ahead on this. If folks were interested in helping out on this front,
> that would be super welcome.

Well... I think its to help out, since its very complicated task.

I stumbled up on this:

- Is there any documentation on the protocols in use? I tried to
understand
https://github.com/servalproject/serval-dna/blob/development/doc/REST-API-MeshMS.md
but I'm confused: On the one hand it describes a RESTApi of a service -
on the other hand, I expect the client to be a node in a DTN. - Is there
an API, that follows some existing protocols (e.g. FCM, MQTT), that
could be resused?

- IMHO you cannot just write an App to do so, since a stable connection
to arbitrary message brokers violates a lot of assumptions, that are
present in many platforms (esp. energy savings). Creating some kind of
offline FCM would require coordination with google, but I don't know any
folks, there.

- IMHO its worth to consider building a cellular network (e.g. LTE-U)
for the access part (i.e. connection to end-devices).
It's not absurd, I guess (e.g. https://www.nist.gov/ctl/pscr/openfirst -
but this is going to have a huge impact on the network architecture at all.

Paul Gardner-Stephen

unread,
Sep 13, 2019, 8:42:19 PM9/13/19
to Serval Project Developers
Hello,

On Sat, 14 Sep 2019 at 00:31, yanosz <serval-...@yanosz.net> wrote:
Hello,

Am 11/09/2019 um 19.54 schrieb Paul Gardner-Stephen:
> On Thu, 12 Sep 2019 at 03:02, yanosz <serval-...@yanosz.net
> <mailto:serval-...@yanosz.net>> wrote:
>     Am 11/09/2019 um 18.47 schrieb Paul Gardner-Stephen:
>

> Yes, I agree that the Serval app should work when Internet is available
> as well, if we can muster the development effort to do so.  Really the
> implicit goal of Serval is to make messaging possible regardless of the
> crazy communications channels available.  The Mesh Extender can be seen
> as a radio to wifi abstraction layer in this sense.
>
> Our challenge right now is that we don't have the resources to push
> ahead on this. If folks were interested in helping out on this front,
> that would be super welcome.

Well... I think its to help out, since its very complicated task.

I stumbled up on this:

- Is there any documentation on the protocols in use? I tried to
understand
https://github.com/servalproject/serval-dna/blob/development/doc/REST-API-MeshMS.md
but I'm confused: On the one hand it describes a RESTApi of a service -
on the other hand, I expect the client to be a node in a DTN. - Is there
an API, that follows some existing protocols (e.g. FCM, MQTT), that
could be resused?

The REST API is for use within an application, not between them. It is just to make it easier to make the UI for an app. The actual transfers happen using Serval Rhizome, our DTN protocol.
 
- IMHO you cannot just write an App to do so, since a stable connection
to arbitrary message brokers violates a lot of assumptions, that are
present in many platforms (esp. energy savings). Creating some kind of
offline FCM would require coordination with google, but I don't know any
folks, there.
 
This is why we created Rhizome ourselves.

- IMHO its worth to consider building a cellular network (e.g. LTE-U)
for the access part (i.e. connection to end-devices).
It's not absurd, I guess (e.g. https://www.nist.gov/ctl/pscr/openfirst -
but this is going to have a huge impact on the network architecture at all.

Unfortunately it turns out to be practically impossible during either civil unrest or a natural disaster to get the necessary permissions to import let alone turn on any cellular equipment. We know this from Red Cross and many others. Cellular is great in theory, but practically impossible in practice. 

Paul.

Greetz, yanosz

--
There's a ripped off cord
To my TV screen
With a note saying:
"Im not afraid to dream"
-- Donkey Boy, Crazy Something Normal

--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-dev...@googlegroups.com.

Roland Turner

unread,
Sep 13, 2019, 9:00:09 PM9/13/19
to serval-proje...@googlegroups.com
On 14/9/19 8:42 am, Paul Gardner-Stephen wrote:
Hello,

On Sat, 14 Sep 2019 at 00:31, yanosz <serval-...@yanosz.net> wrote:
Hello,

- IMHO its worth to consider building a cellular network (e.g. LTE-U)
for the access part (i.e. connection to end-devices).
It's not absurd, I guess (e.g. https://www.nist.gov/ctl/pscr/openfirst -
but this is going to have a huge impact on the network architecture at all.

Unfortunately it turns out to be practically impossible during either civil unrest or a natural disaster to get the necessary permissions to import let alone turn on any cellular equipment. We know this from Red Cross and many others. Cellular is great in theory, but practically impossible in practice.

Note that LTE-U appears to have been designed by telcos to facilitate freezing out of non-telco use of ISM bands, in contrast to LAA which is designed to cooperate with other uses. Quite why the FCC permitted what amounts to deliberate interference ("unprotected basis" is not a license to interfere; not only does LTE-U not listen-before-talk on ISM bands, it doesn't even deploy a receiver with which it could do so), however MulteFire has been designed by equipment manufacturers (over telco objections, which is why it's not happening inside 3GPP) to operate entirely within ISM bands. If the handset manufacturers ever do include support in their factory builds then it will be feasible to over at least some LTE service over unlicensed spectrum, which would fit this use case rather well.

- Roland

Paul Gardner-Stephen

unread,
Sep 13, 2019, 11:49:15 PM9/13/19
to Serval Project Developers
Hello,

Well, it can remove the spectrum barrier, but not the regulatory barriers, e.g., the need to hold a public telecommunications license or equivalent, and all the obligations that come with that, which are based on licensees being large organisations.

Paul.

- Roland

--
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-dev...@googlegroups.com.

yanosz

unread,
Sep 14, 2019, 4:54:02 AM9/14/19
to serval-proje...@googlegroups.com
Hello,


Am 14/09/2019 um 02.42 schrieb Paul Gardner-Stephen:
> On Sat, 14 Sep 2019 at 00:31, yanosz <serval-...@yanosz.net
> <mailto:serval-...@yanosz.net>> wrote:
>
> - Is there any documentation on the protocols in use? I tried to
> understand
> https://github.com/servalproject/serval-dna/blob/development/doc/REST-API-MeshMS.md
> but I'm confused: On the one hand it describes a RESTApi of a service -
> on the other hand, I expect the client to be a node in a DTN. - Is there
> an API, that follows some existing protocols (e.g. FCM, MQTT), that
> could be resused?
>
>
> The REST API is for use within an application, not between them. It is
> just to make it easier to make the UI for an app. The actual transfers
> happen using Serval Rhizome, our DTN protocol.

Thanks ... I'm still a little bit confused ..

so, MeshMS is the Application, Rhizome is the middleware. If MeshMS is
used, Rhizome is running on the same, device, isn't it?

Looking at
https://github.com/servalproject/batphone/tree/development/app/src/main/jni

Most of the rhizome-code is called via JNI. There's no pure Java
implementation of it. Rest is used to overcome limitations of JNI. In
this setting, rhizome runs as a local http-service, isn't it?

Having MDP and MSP, serval operates on osi-3 -
https://github.com/servalproject/serval-dna/blob/development/doc/Mesh-Datagram-Protocol.md
Is there an existing implementation for MDP / MSP over p2p-Links /
Tunnels using IP or UDP/TCP underneath? By intuition I'd have a expect
to kind of UDP transport mode for these kinds of packets, but there is
none, isn't it?

Looking at the system-architecture: What's your strategy for a mobile
phone participating in a serval mesh, respecting energy savings on
osi-1/2 designed by the platform? E.g.
1) Rely on Mesh-Extenders during energy saving periods? or
2) Keep the radio up all time, try to disable energy savings?
3) Define a energy saving protocol, that needs to be implemented on osi-2/3?

By intuition, I'd rule out 2) in a DTN and 3) due to complexity, but
relying on mesh extenders limits the system significantly.

Than

john whelan

unread,
Sep 14, 2019, 3:01:13 PM9/14/19
to Serval Project Developers
Sometimes I think it makes sense to step back and look at the requirements.

These are my thoughts.

We want something that can be deployed quickly and cheaply.  If we can make use of existing phones that would be nice.

For reasons of red tape we want to avoid anything other than WiFi in the basic set of tools but it would be nice to have something that could extend the range to a few kms or more.

User training needs to be kept to a minimum.  In practice this means can we use an existing interface if possible and recognise different people are comfortable with different tools.

We'd like something that can make the most of existing bandwidth.

We recognise that energy saving is important if only to extend battery life.  So it would be nice if I could connect to the network, grab any messages etc then turn the device off.

We need good documentation in different languages.  English is important but not everyone speaks it.

Rural or urban makes a difference.  Rural will have less background WiFi / radio noise so there should be less signal problems.

The number of users.

The distance we need to communicate.

A web page and file server would be nice.

Standards based where possible.

These may need refining.

From a functional point of view how do the different solutions measure up.

I like email, on a phone the Gmail app can work off line then connect and exchange messages at a later date.  It will connect to other mail systems than Google.  Very low training costs and the interface is available in 72 languages.  You can turn the phone off between sessions to save energy.  The other nice bit is by having the phone wake up at different times you need less bandwidth and lower requirements on the server side.  Working with a local computer club I wrote a script that would log on to the BBS first reply to any messages that had been replied to off line, the grab the new messages then drop the connection.  It was a four line BBS and members had capacity problems logging on before the script.  With the script the problems disappeared.

Reality I think currently it is too complex to deploy although Raspberry Pi s have been set up as an email server and they are low power and can be battery powered.  You'd want to use an SSD such as a Verbatim VX500 for storage rather than a microSDXC memory card because of the number of writes.  You also need some sort of routing table if you have more than one BBS or email server.  Using an external SSD might up the reliability of a mesh server as well.

We used to run Fidonet BBses and they also had direct email messaging.  Initially they would exchange mail at midnight until 1 am but this was changed later as the software progressed.  The really nice thing about Fido was the messages were compressed before sending and decompressed or unpacked on arrival then processed.  Some were copied onto disks and sent by mail then copied into to the inbox on the other system.  They were normally zipped but 7zip could be used and 7 zip is available on Android.  This has the advantage of a CRC check digit on the file.  If we could make use of this then the available bandwidth has just increased by a factor of ten for text messages.

IM messaging has its place on a LAN or closed network Serval mesh and "LAN Messenger"  both work and offer file transfer but "LAN Messenger" has a friendly user interface and may be available in seven or eight languages.  The GL AR150 uses low power and can be battery powered quite easily.  Note it is only 2.4 G and the throughput is not as high as some other solutions.  There are SIP based systems out there but there doesn't seem to be a standard implementation.

If we want to extend the network over a longer distance then Serval Mesh works but "LAN Manager" needs either a router set up in repeater mode or something like Commotion.  With only 2.4 G the GL AR150 would lose bandwidth if used in repeater mode.

Extending the network:  Line of sight is fairly easy.  The GL-AR150 routers have been used in pairs to bridge with specialist external antennas over distances of several kms.  More details earlier in this thread and on WRT forum https://forum.openwrt.org .  Note the external antenna solution works best in remote areas because of background noise. To work with digital radios Serval is probably the best solution at the moment.

Voice, there are solutions such as Serval, Csipsimple currently both are no longer on the play store but do work in a standalone LAN environment.  Across a limited capacity mesh network Voice takes up bandwidth and the hops cause latency problems.  So two phone on one router is fine but multihop is not so good.  Users have posted they have got both Linphone and Mizudroid working using just an ip address so do not need an Internet connection, currently I'm unable to reproduce this.  Realistically you'd need to have a fixed IP address for the phone so the routher would need configuring as normally they use DHCP.  Of these Linphone on Android has the very nice OPUS codec which was developed from the Skype codec and is considered to be a modern codec that works well at low bit rate.

Video, I'd basically forget it the bandwidth requirements are too high in my opinion.

A conventional LAN with a web / file / email server probably offers the nicest user interface and most flexibility.  One or more Raspberry Pi s theoretically can act as servers.  Realistically the Red Cross NUC based solution if it could be hooked up to the network might be more practical to the Red Cross as it would contain their applications.  Add in Astrix on a laptop and you have a fully functioning PBX.

Firechat works best with lots of devices in the mesh.  Also it is a closed network so much more difficult to add functionality and send messages away from the mesh of devices.

Connecting the phones to a router allows a longer distance for communication.  Bluetooth / WiFi are interesting in that Bluetooth I understand draws lower power, and has a range of 10 meters, WiFi normally has a range of 90 meters outdoors but this does depend on the antenna.  Note WiFi 6 has much better bandwidth and can power down when not in use.  WiFi 6 is not yet generally available.  The GL AR150 has an early version of WiFi and only uses the 2.4G wavelength.  Having both 2.4 and 5 G gives more bandwidth locally but 2.4 has a longer range.  Note the version of WiFi used will be the lowest that is supported by both devices so a WiFi 6 phone will only connect at WiFi 6 level to a WiFi 6 router.

So currently Serval is the only solution that works out of the box using a combination of phones and mesh extenders.  However finding a trusted source currently is a problem.  It doesn't seem to be on the google store for some reason and   http://developer.servalproject.org/files/ does not have an SSL certificate.  If I was deploying it with an NGO or government hat on I would  be reluctant to trust the source.  Also loading from an apk may require a level of technical expertise that may or may not be available.

What might be nice is the Serval network and the ability to hang servers off it.  Even a SSD on the mesh extender that could be mapped from a phone would add capability.  CX file explorer on a smartphone is quite capable of finding its way to an SSD set up as a NAS on my ASUS router, loading an HTML file into chrome.  A fully fledged web server it might not be but a way of making information available it is useful.

On the power saving side Power widget lite is useful in being able to turn both WiFi and location off and on as required.  With both off the battery lasts a little longer.

Cheerio John



yanosz

unread,
Sep 14, 2019, 5:09:34 PM9/14/19
to serval-proje...@googlegroups.com
Heiho,

thanks for sharing your thoughts and the long mail.

I guess, that's hard to continue this discussion by mail - most of them
are reasonable requirements for building a network.

When I started looking a serval in the first, I was hoping to find an
Android application for messaging in a isolated mesh network.

Digging into the wikis and source I'm still overwhelmed by the
complexity of the full project. I didn't expect that - although doing
mesh-things (Freifunk) and software development for more than a decade.

Looking at the requirements - as you've done in your mail - is a good
way for not getting lost :-). Thanks.

From my perspective - as an outsider - it looks like a very cool list of
clever and fascinating ideas is implemented in serval. Still, there's no
software I can "just use". Almost all devices in my closet are too new
to run OpenWRT 12.02 for instance.

Some docs look to me a little bit like research papers on DTN
optimization, using serval as a motivation / use-case. Others are really
practical describing lessons learned in the field. In some parts, I
don't get the motivation for a particular part of complexity. Please
don't get me wrong: I think both is very exciting and fascinating - it
feels somewhat hard to digest the concrete motivation, then.

Same is for the GL-AR150 - its a very special tool IMHO:
It's advertised as a small, cheap and lightweight travel router. Its
good for small team, that needs to share files or route internet
packets. It can be powered using just a USB-Port. It's probably nice so
spawn a free Wifi having a VPN back home.

Rumors suggest, that some people the German THW use similar devices (TP
Link, ar71xx) for similar use-cases. As you already mentioned, Raspberry
Pis are an interesting alternative.

But I probably won't use it to build larger network. The wifi doesn't
even support 2x2 MIMO (unlike GL-AR 300M, GL-AR 750), the platform is
kind of old and the single core CPU is very limited.

Personally, I like ubiquity gear for building larger networks; but there
are other pro's and cons - you probably trade network performance for
money and energy consumption.

Like the GL-AR150, android phones are also a very special. They're
optimized to process information using IP and the Google Cloud. Of
course, you can use them in other ways, but sometimes you're hitting a
barrier: For example: Huge capacities in local wifi can leverage file
sharing, but a messaging connection to arbitrary brokers or a wifi ap
will drain the battery very fast. Email is something in between. An
email service using small SoCs appears to be realistic.

After digging through information about serval, I start sympathizing
with the emergency.lu approach, to just provide a little bit of
internet. Tools such as Meshenger / Hackerfleet [1] can utilize local
capacity, still.

I really like the idea behind serval .. but as I said in the beginning,
I'm looking for an Android application for doing messaging a mesh
network .. and I think for the moment, serval isn't ready to do that:
It'll be hard e.g. to patch conversations to just communicate with
serval's middleware in addition.

I guess, I'm going to follow this mailing list for while (as I've done
before), but I don't think that, I'm going to start coding for serval.

Greetz, yanosz

[1] https://github.com/meshenger-app/meshenger-android
[2] https://github.com/hackerfleet
> be battery powered.  You'd want to use an SSD such as aVerbatim VX500
> <https://forum.openwrt.org/> .  Note the external antenna solution works
> --
> You received this message because you are subscribed to the Google
> Groups "Serval Project Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to serval-project-dev...@googlegroups.com
> <mailto:serval-project-dev...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/serval-project-developers/CAJ-Ex1Gv1ftjoVk7S8L5kJUPVP7aZxx4xJE91FT3nkZkZYwq_g%40mail.gmail.com
> <https://groups.google.com/d/msgid/serval-project-developers/CAJ-Ex1Gv1ftjoVk7S8L5kJUPVP7aZxx4xJE91FT3nkZkZYwq_g%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Roland Turner

unread,
Sep 14, 2019, 11:11:37 PM9/14/19
to serval-proje...@googlegroups.com
On 14/9/19 11:48 am, Paul Gardner-Stephen wrote:
Hello,

On Sat, 14 Sep 2019 at 10:30, 'Roland Turner' via Serval Project Developers <serval-proje...@googlegroups.com> wrote:

Note that LTE-U appears to have been designed by telcos to facilitate freezing out of non-telco use of ISM bands, in contrast to LAA which is designed to cooperate with other uses. Quite why the FCC permitted what amounts to deliberate interference ("unprotected basis" is not a license to interfere; not only does LTE-U not listen-before-talk on ISM bands, it doesn't even deploy a receiver with which it could do so), however MulteFire has been designed by equipment manufacturers (over telco objections, which is why it's not happening inside 3GPP) to operate entirely within ISM bands. If the handset manufacturers ever do include support in their factory builds then it will be feasible to over at least some LTE service over unlicensed spectrum, which would fit this use case rather well.


Well, it can remove the spectrum barrier, but not the regulatory barriers, e.g., the need to hold a public telecommunications license or equivalent, and all the obligations that come with that, which are based on licensees being large organisations.


Not at all. Whether your on-air protocol is WiFi, Bluetooth, or LTE doesn't change your regulatory position by itself. The obligations that you're describing will arise equally in a Serval mesh if you provide a gateway to the public network somewhere in the mesh and charge for its use. So long as you remain a "closed user group", these obligations don't arise.

MulteFire is interesting because of the moderate likelihood that handset manufacturers will include it in their factory builds, which we can safely assume will never be true for Serval. If - and only if - this actually happens then it is possible to support a far better provisioning model:

  • Self-provisioning a network connection without the various trade-offs that WiFi still imposes (shared key or out-of-band key distribution in particular; granted, WPA3 might fix this)
  • The option to use a web app, meaning:
    • No need for users to do a thing that security folks are actively teaching them not to do (side-loading apps from unknown or non-expert sources).
    • No dependence upon having a working app available for every version of every device that users are likely to have.

Etc.

This is not to say that the Android<->Android capabilities of Serval aren't interesting, just that the moment that you introduce infrastructure, all of the trade-offs change.

- Roland

Reply all
Reply to author
Forward
0 new messages