3 Feb
2012
3 Feb
'12
6:17 a.m.
Hi Kurtis,
(I'm changing subject to the actual topic of this discussion)
Yes, I quickly looked through your code. Looks like a big hack right
now, but I guess it's meant to be a hack at this point :)
So, your idea is to manipulate Tx power of a BTS to cover only
actually working handsets, if I understand correctly. It's not
possible to do with a normal GSM phone, because phone does not
transmit until it sees a beacon. So you want to create a "wake up BTS"
channel to get around. Am I following your logic correctly?
It does look like an interesting idea if could be done dirt-cheap. But
how do you plan to do paging in this system? I see the only way - to
use the same "wake up channel", but in other direction. So basically
you have a network-specific "default" ARFCN which is used when no
active BTS is in range. All communications are first tried on this
ARFCN and only then on other ones. Right?
On Thu, Feb 2, 2012 at 22:43, Kurtis Heimerl <kheimerl(a)cs.berkeley.edu> wrote:
This is part of my thesis work at Cal, yes. Range is
not in any way involved.
That's roughly the use case, areas where there are too few users to
keep a BTS in constant use. Our designs allow the power usage to scale
with the number of users, rather than sit at a fixed output, as they
do now. The BTS side is simple; the osmocom side is complicated. We
have a handset that can wakeup a sleeping tower, or a "wakeup button"
device which only transmits when a button is pressed. That thing is ~5
bucks and can probably be attached to the back of a legacy phone in
case we can't convince a large manufacturer to incorporate our changes
into the baseband.
Anyhow, the code is online if you're interested in looking at our
progress (https://github.com/kheimerl). It's nowhere near ready, but
you're a very knowledgeable guy, and I'd be happy to hear your
opinions on any of our designs.
On Thu, Feb 2, 2012 at 10:37 AM, Alexander Chemeris
<alexander.chemeris(a)gmail.com> wrote:
> Is it a part of your TIER university work?
> I wonder about use cases for this.
>
> One use case I see is when you have a BTS which is rarely used, like
> in a desert and you don't want it to work all the time. What use cases
> do you plan to use it for?
>
> On Thu, Feb 2, 2012 at 22:03, Kurtis Heimerl <kheimerl(a)cs.berkeley.edu> wrote:
>>
>> Yeah, and we have that working.
>>
>> On Thu, Feb 2, 2012 at 12:56 AM, Alexander Chemeris
>> <alexander.chemeris(a)gmail.com> wrote:
>> > On Thu, Feb 2, 2012 at 12:08, Kurtis Heimerl
<kheimerl(a)cs.berkeley.edu> wrote:
>> >> I think I looked at that... I'll give you some context.
>> >>
>> >> We've modified osmocom to "wakeup" a specific tower at a
specific
>> >> ARFCN.
>> >
>> > Interesting. Do you mean you send some packet to a "sleeping" BTS
to wake it up?
>> >
>> > --
>> > Regards,
>> > Alexander Chemeris.
>
>
>
>
> --
> Regards,
> Alexander Chemeris.
--
Regards,
Alexander Chemeris.
3 Feb
3 Feb
9:32 a.m.
Comments in line!
On Thu, Feb 2, 2012 at 9:17 PM, Alexander Chemeris
<alexander.chemeris(a)gmail.com> wrote:
Hi Kurtis,
(I'm changing subject to the actual topic of this discussion)
Good idea.
Yes, I quickly looked through your code. Looks like a big hack right
now, but I guess it's meant to be a hack at this point :)
And it will remain a big hack into the near future!
So, your idea is to manipulate Tx power of a BTS to cover only
actually working handsets, if I understand correctly. It's not
possible to do with a normal GSM phone, because phone does not
transmit until it sees a beacon. So you want to create a "wake up BTS"
channel to get around. Am I following your logic correctly?
Ah... sorta not really, unless we're using different terminology. We
use the existing channel (that the BTS is listening on) and send a
RACH over that channel to the BTS. Though the handset can't hear the
beacon, the radio is capable of transmitting at that ARFCN without a
beacon (thanks Sylvain!) if we tell it to do so. We do so ("wakeup"),
causing the handset to RACH at a specific ARFCN and the BTS to hear
some discernible noise (however not a RACH as the clocks are not
synced) and turn the PA on. Following this, the handset camps normally
and makes a call.
In writing that, it is awfully hard to describe. I hope that made some
sense. I can tell you that it's working in our lab, and it's pretty
cool.
It does look like an interesting idea if could be done dirt-cheap. But
how do you plan to do paging in this system? I see the only way - to
use the same "wake up channel", but in other direction. So basically
you have a network-specific "default" ARFCN which is used when no
active BTS is in range. All communications are first tried on this
ARFCN and only then on other ones. Right?
Paging is actually quite simple, as we own the BTS. When we receive a
call, we hold it ("please wait for connection") and turn the PA on. We
then wait for the HS to camp, and if they do, page them once
available. A little delay (much better with SMS), but I think most
users would be fine with it. We haven't written this yet.
On Thu, Feb 2, 2012 at 22:43, Kurtis Heimerl <kheimerl(a)cs.berkeley.edu> wrote:
This is part of my thesis work at Cal, yes. Range
is not in any way involved.
That's roughly the use case, areas where there are too few users to
keep a BTS in constant use. Our designs allow the power usage to scale
with the number of users, rather than sit at a fixed output, as they
do now. The BTS side is simple; the osmocom side is complicated. We
have a handset that can wakeup a sleeping tower, or a "wakeup button"
device which only transmits when a button is pressed. That thing is ~5
bucks and can probably be attached to the back of a legacy phone in
case we can't convince a large manufacturer to incorporate our changes
into the baseband.
Anyhow, the code is online if you're interested in looking at our
progress (https://github.com/kheimerl). It's nowhere near ready, but
you're a very knowledgeable guy, and I'd be happy to hear your
opinions on any of our designs.
On Thu, Feb 2, 2012 at 10:37 AM, Alexander Chemeris
<alexander.chemeris(a)gmail.com> wrote:
> Is it a part of your TIER university work?
> I wonder about use cases for this.
>
> One use case I see is when you have a BTS which is rarely used, like
> in a desert and you don't want it to work all the time. What use cases
> do you plan to use it for?
>
> On Thu, Feb 2, 2012 at 22:03, Kurtis Heimerl <kheimerl(a)cs.berkeley.edu> wrote:
>>
>> Yeah, and we have that working.
>>
>> On Thu, Feb 2, 2012 at 12:56 AM, Alexander Chemeris
>> <alexander.chemeris(a)gmail.com> wrote:
>> > On Thu, Feb 2, 2012 at 12:08, Kurtis Heimerl
<kheimerl(a)cs.berkeley.edu> wrote:
>> >> I think I looked at that... I'll give you some context.
>> >>
>> >> We've modified osmocom to "wakeup" a specific tower at a
specific
>> >> ARFCN.
>> >
>> > Interesting. Do you mean you send some packet to a "sleeping" BTS
to wake it up?
>> >
>> > --
>> > Regards,
>> > Alexander Chemeris.
>
>
>
>
> --
> Regards,
> Alexander Chemeris.
--
Regards,
Alexander Chemeris. 
3:08 p.m.
Hi Kurtis,
On Fri, Feb 03, 2012 at 12:32:12AM -0800, Kurtis Heimerl wrote:
Paging is actually quite simple, as we own the BTS.
When we receive a
call, we hold it ("please wait for connection") and turn the PA on. We
then wait for the HS to camp, and if they do, page them once
available. A little delay (much better with SMS), but I think most
users would be fine with it. We haven't written this yet.
I think the delay will be quite significant, depending on where and how
the MS is currently scanning and/or trying to register to other
networks, I would guess it could easily be 20 to 30 seconds.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
7:35 p.m.
I think that's acceptable. I expected a lot longer, to be honest.
As an alternative, I could instead just call both parties back once
the phone has camped. There's a number of ways to communicate the
wait, and I don't think users in rural areas would be particular
bothered by the execution. In my own experience in rural Uganda, they
went through a lot more hoops (e.g., climbing trees) for coverage.
On Fri, Feb 3, 2012 at 6:08 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
Hi Kurtis,
On Fri, Feb 03, 2012 at 12:32:12AM -0800, Kurtis Heimerl wrote:
Paging is actually quite simple, as we own the
BTS. When we receive a
call, we hold it ("please wait for connection") and turn the PA on. We
then wait for the HS to camp, and if they do, page them once
available. A little delay (much better with SMS), but I think most
users would be fine with it. We haven't written this yet.
I think the delay will be quite significant, depending on where and how
the MS is currently scanning and/or trying to register to other
networks, I would guess it could easily be 20 to 30 seconds.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
4478
days inactive
4478
days old
baseband-devel@lists.osmocom.org
3 comments
3 participants
participants (3)
-
Alexander Chemeris -
Harald Welte -
Kurtis Heimerl