1 Sep
2011
1 Sep
'11
4:11 a.m.
Greetings all,
At the Serval Project we have created a mobile mesh telephony system
that currently works over wifi.
1 Sep
1 Sep
7:18 a.m.
I think you would be better taking your existing hardware, which must be
somewhat custom to begin with (since it works over wifi) and use something
like a HopeRF module (http://www.hoperf.com/) or similar. HopeRF has
transceivers with power output up 100mW, data rates up to 256kbps, and a
choice of 4 different bands (315, 433, 868, 915). This sounds like it would
be a far easier choice to incorporate into your already-working system than
hacking OsmocomBB-capable phones.
There is a lot of development from many different companies in this area and
quite a bit of hacker activity as well.
Scott
On Thu, Sep 1, 2011 at 7:11 AM, Paul Gardner-Stephen <paul(a)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.
12:28 p.m.
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.
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.
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.
Scott
On Thu, Sep 1, 2011 at 7:11 AM, Paul Gardner-Stephen <paul(a)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.
12:47 p.m.
Hello
On Thu, Sep 1, 2011 at 9:58 PM, Scott Weisman <sweisman(a)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(a)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.
1:21 p.m.
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).
Then you have to come up with a protocol that with those primitives
can build a stable mesh network.
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.
You could probably get some inspiration from the specs of TETRA DMO
mode since what you want is essentially a DMO mode for GSM.
Cheers,
Sylvain
3:03 p.m.
Hi Sylvain,
On Thu, Sep 1, 2011 at 10:51 PM, Sylvain Munaut <246tnt(a)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
3:07 p.m.
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)
Cheers,
Sylvain
3:24 p.m.
Hello,
On Fri, Sep 2, 2011 at 12:37 AM, Sylvain Munaut <246tnt(a)gmail.com> wrote:
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.
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)
Cheers,
Sylvain
4:40 p.m.
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.
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. ;-)
Regards,
Mad
9:16 p.m.
Hello Mad,
On Fri, Sep 2, 2011 at 2:10 AM, mad <mad(a)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
5088
days inactive
5088
days old
baseband-devel@lists.osmocom.org
9 comments
4 participants
participants (4)
-
mad -
Paul Gardner-Stephen -
Scott Weisman -
Sylvain Munaut