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@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@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@cs.berkeley.edu wrote:
Yeah, and we have that working.
On Thu, Feb 2, 2012 at 12:56 AM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
On Thu, Feb 2, 2012 at 12:08, Kurtis Heimerl kheimerl@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.
Comments in line!
On Thu, Feb 2, 2012 at 9:17 PM, Alexander Chemeris alexander.chemeris@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@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@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@cs.berkeley.edu wrote:
Yeah, and we have that working.
On Thu, Feb 2, 2012 at 12:56 AM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
On Thu, Feb 2, 2012 at 12:08, Kurtis Heimerl kheimerl@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.
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.
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@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@gnumonks.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
baseband-devel@lists.osmocom.org
-
Alexander Chemeris -
Harald Welte -
Kurtis Heimerl