Hello On Thu, Sep 1, 2011 at 9:58 PM, Scott Weisman <sweisman@pobox.com> wrote:

After checking out your web site, I see you're trying to use standard off-the-shelf hardware. In that case, this is the wrong avenue to pursue. I think a better idea, without knowing anything about the deep technical details, would be to drop the phone-to-phone mesh network effort and focus instead on creating some sort of BTS-in-a-box that can be deployed by airdrop or whatever, using low power components capable of being maintained on solar alone. The mesh networking could come into play here, where perhaps a BTS-to-BTS mesh can be developed (again, I don't even know if this is possible, but this seems to be a better avenue to pursue if stock cell phones are a goal). There is at least one group working to deploy OpenBTS-based hardware in extremely remote locations running under very limited power budgets. This kind of solution could use 100% stock phone hardware. While carrier-grade BTS hardware is ridiculously expensive, it doesn't have to be that way for this kind of use case.

I hear what you are saying, and we are working to support inter-BTS meshing for OpenBTS and OpenBSC. However, there is also value in getting the phones to mesh, if only because there are plenty situations where you might not be able to get a BTS, or be able to use any BTS that is around.

Also, in an emergency situation like the Haiti earthquake, which was your inspiration, are you really going to be concerned with all the strict legalities involved, or are you going to be more concerned with saving lives? Let's see. Tens of thousands dead and injured, and more deaths by the minute. So, we better make sure our hardware is 100% compliant with local laws and difficult to deploy since it needs custom software and possible hardware mods to function. Or, maybe, just maybe, in this type of disaster scenario, since the local cellular service is down anyway, easily deploy a legally questionable but 100% workable solution many times faster.

I know what you are saying, and much does happen in emergency situations that is not tolerated otherwise. However this is not to say that we should not be aspiring to fully legal solutions. While we talk much about disaster, we also care about developing world and rural/remote markets where incumbent cellular carriers will certainly litigate over any unlicensed BTSes.

As an aside, I read an article in an amateur radio magazine back in the 1980s by someone who designed a portable solar-powered packet radio repeater with stock hardware of the time. He use an old ammo box to hold everything and powered it with a solar panel and motorcycle battery. It was self-contained, had no overheating issues (he checked), and was just cool.

That is cool, and are aware that we are in many ways just re-spinning tech that has been around 40 or 50 years, whether it be packet radio, FIDOnet or other such technologies. Paul.

Scott On Thu, Sep 1, 2011 at 7:11 AM, Paul Gardner-Stephen <paul@servalproject.org> wrote:

...

Greetings all,

At the Serval Project we have created a mobile mesh telephony system that currently works over wifi.

From the outset, we have wanted to get it working on the ISM915 and/or ISM868 bands that are located adjacent to the GSM 850/900 frequency allocations.

My initial investigations and enquiries indicate that this should be possible by creative programming of the baseband processor in many models of phones.  The trick, as I suspect you well know, is the difficulty in getting the information and tools required to reprogram these radios.

I am now in a position to potentially fund further work on this.

So, as the open-source group with the most experience reprogramming baseband radios, what is the feasibility of creating a proof-of-concept using the types of phones you already work with to send and receive arbitrary data packets without reliance on a cell tower (even for time synchronisation)?

I know there are a lot of constraints and problems, but I am most interested in creative solutions that can get us to a working prototype, however crude, that can be used to demonstrate the feasibility of what I am proposing.

If this discussion is off-topic here, I am happy to hold the conversation at the serval-project-developers google group, but I am equally comfortable with it continuing here.

Thanks in advance, Paul Gardner-Stephen. Shuttleworth Telecommunications Fellow at Flinders University.

Hi Sylvain, On Thu, Sep 1, 2011 at 10:51 PM, Sylvain Munaut <246tnt@gmail.com> wrote:

You have to essentially stick with GSM mostly so:

 - Same modulation GMSK  - Same frame structure of 4.615ms  - Same bursts : 156.25 bits  - Same channel coding for CCH and TCH  - Same channel spacing of 200kHz

This way you can mostly reuse the GSM primitives offered by the baseband DSP.

Then you have to create new primitives so that phones can do between them what they would do with a BTS  - Transmit a FCCH / SCH ( so that a phone can become 'local master' and provide sync to other phones )  - RX RACH requests ( so that a phone that's 'local master' can answer incoming requests for channels )

Both of theses actually already exist (I coded them).

Most interesting!

Then you have to come up with a protocol that with those primitives can build a stable mesh network.

Well, once there is a stable packet transport, then it is fairly easy to build the mesh on top.

And this latter part doesn't actually require any messing with osmocom-bb at first, you should design and simulate it fully _first_. And then once you have it you can start implementing it on real hardware.

Indeed. The Serval mesh software is being setup so that it can use any link-layer, including such a GSMish one as you have described. That part is the easy part from my perspective.

You could probably get some inspiration from the specs of TETRA DMO mode since what you want is essentially a DMO mode for GSM.

Yes, in some ways that is what we want. We also need to deal with bridging to WiFi and some other odd bits and pieces. Paul.

Cheers,

   Sylvain

Hello, On Fri, Sep 2, 2011 at 12:37 AM, Sylvain Munaut <246tnt@gmail.com> wrote:

...

Well, once there is a stable packet transport, then it is fairly easy to build the mesh on top.

You can't do it like that here (like you could with Wifi).

Because the mesh network itself is gonna have to provide negatiation and everything _to_ establish reliable packet transport. (neighbor discovery, master election, organization or the nodes  in 'micro network' for sync etc etc ...).

All that needs to be figured out first, because when you power up a phone, it doesn't have _anything_ and before it can even think about exchanging packet, it'll have to find some other node to provide sync ... (and then whenever a node is changed / moved / ... adapt)

Gotcha. I mis-interpreted your previous message as you had built an election system from your primitives. Okay, so time to start thinking about how to bootstrap the process. Simplest approach that comes to mind would be for every phone to listen for a master, and if it can't hear one, try to be one. Then have a resolution process for when multiple masters are present. In any case, very interested to take a look at your primitives and how they might be assembled to meet our needs. Paul.

Cheers,

   Sylvain

Hello Mad, On Fri, Sep 2, 2011 at 2:10 AM, mad <mad@auth.se> wrote:

Hi Paul,

another point to assess is if it is feasible at all to use these devices with a to-be-developed p2p protocol in terms of practicability to operate them in the field as you intend.

Because there is still the issue of power consumption you can not get around so easily. GSM phones can maintain their high standby-times only by relying on stable basestations to be able to switch off their transceivers for most of the time.

As Sylvain stated there has to be a master kind of imitating the BS for its neighbours to sync on. This master most certainly had to send a beacon all the time so its battery would drain quickly. The operation time in master mode would be significantly less than the usual speech-time of that phone, so not much more than very few hours.

As there is only a short radio range, all participating devices had to act as a master for some time of their operation and suffer from this energy consuming mode, especially in loosely covered areas where are no or few other devices reachable.

It's just my view that this should be considered, too, before making huge efforts to implement sth. like this for the intended purpose.

You're absolutely right about energy consumption. In fact, this is a big problem for WiFi too, as there it is difficult to disable the 10Hz beaconing in ad-hoc mode. Our view is that the right technology for other occasions, e.g.,, GSM, exists, but we want to at least provide the possibility of communications in the other situations, which it turns out happens fairly often (disaster, remote, developing countries). We will also look into tricks like using the beacons from a nearby cell to synchronise ourselves if it is available, as that should enable us to save a lot of power, and only resort to beaconing ourselves if we really have to. Your point about sharing around the being master is an important point, and certainly one that would need to implement.

Of course it would be a cool addon to osmocom-bb and this shouldn't keep anybody from doing this for the sake of rising to the challenge. ;-)

Well, if it looked like it was sensible, then someone else would probably have done it ;) Anyway, I am committed to at least try, and intend to throw some resources (including financial) behind the effort. Besides, the more this conversation continues, the more convinced I am that it is possible, even if the solution might be a conglomeration of rather interesting work-arounds. The point is that there is every possibility that it will work, and if it does, then one of the eventual side-effects should be the gaining of access to material that will enable the reprogramming of more modern baseband processors to positive ends, which will be much more interesting for everyone. Paul.

Regards,  Mad