29 Jul
2009
29 Jul
'09
5:28 a.m.
Hi, I'm a long time lurker into this project and I've wondered something for
a bit of time.Knowing that we can use an ip.access nanoBTS to work on
OpenBSC, why not adapt OpenBSC for UMA (unlicensed mobile access)
standards?
I know over here in the US we currently use UMA with T-Mobile over WiFi to
communicate back to the T-Mobile servers and eventually off to the GSM and
regular ol' networks.
http://www.umatechnology.org/specifications/index.htm is the UMA
specification, and to my knowledge T-Mobile US's @Home service uses the
1.0.3 protocol revision.
To me it seems like it'd be trivial to make a derived copy of OpenBSC with
UMA support up and running, but I'd like some other thoughts into this
matter. I'm not a programmer by any means here, so if this is impossible,
well, then so be it.
-DC
31 Jul
31 Jul
10:58 p.m.
Hi Dakota.
Hi, I'm a long time lurker into this project and
I've wondered something for
a bit of time.Knowing that we can use an ip.access nanoBTS to work on
OpenBSC, why not adapt OpenBSC for UMA (unlicensed mobile access)
standards?
That could very well be an option. I have not looked into UMA as I only
know it as a buzzword.
To me it seems like it'd be trivial to make a
derived copy of OpenBSC with
UMA support up and running, but I'd like some other thoughts into this
matter. I'm not a programmer by any means here, so if this is impossible,
well, then so be it.
Please don't take this the wrong way, but: In Open Source projects, features
typically get added because somebody has a need and actually implements
them :)
For myself, I don't have such a need and I think there are many much more
important GSM feature that OpenBSC needs, i.e. stable SMS support, independent
media gateway process, GPRS support, intra/inter-BSC handover, BSC/MSC
functional split, A-interface, A3/A5/A8 support, ... so it's not like we're
going to run out of ideas what we could do anytime soon.
Also, for most people involved with OpenBSC, it is one of many projects they are
involved in - so the amount of time we can and want to spend on it is limited.
Cheers,
--
- 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)
3 Aug
3 Aug
11:54 a.m.
functional split, A-interface, A3/A5/A8 support, ...
so it's not like
we're
I am thinking for some time now how this could be done. What i have seen
so
far, is that A5 is open to the public so implementing it is no problem. But
A3/8 is secret so what is you idea of implementing it? Since it is inside
the SIM I don't see how it could be replaced.
Johannes
12:59 p.m.
On Mon, Aug 03, 2009 at 11:54:17AM +0200, Johannes Schmitz wrote:
A5/2 and A5/1 is implemented in both BS-11 and the nanoBTS. You do not
need to know anything about it. You just set the "encrption information" IE
when activating or modifying the channel from the BSC side, that's it.
A3/A8 is either proprietary by the operator, or comp128v2 or v3 (both are
officially closed, but it's safe to assume them to be known).
As Dieter has indicated in earlier mails, you can get SIM's that have comp128v1
or XOR as A3/A8 and which allow you to set the Ki of the SIM. With those
SIM's, or an emulated SIM you can test any implementation of encryption for
OpenBSC, once it has been done.
--
- 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)
functional
split, A-interface, A3/A5/A8 support, ... so it's not
like we're
I am thinking for some time now how this could be done. What i have
seen so far, is that A5 is open to the public so implementing it is
no problem. But A3/8 is secret so what is you idea of implementing
it? Since it is inside the SIM I don't see how it could be replaced.
10:56 p.m.
Am Montag, den 03.08.2009, 12:59 +0200 schrieb Harald Welte:
A3/A8 is either proprietary by the operator, or
comp128v2 or v3 (both are
officially closed, but it's safe to assume them to be known).
As Dieter has indicated in earlier mails, you can get SIM's that have comp128v1
or XOR as A3/A8 and which allow you to set the Ki of the SIM. With those
SIM's, or an emulated SIM you can test any implementation of encryption for
OpenBSC, once it has been done.
At this point I have got one general question, maybe also towards
Dieter:
How can A3/A8 be proprietary by any operator? How does international
roaming work then if there is no standardized algorithm?
Johannes
11:44 p.m.
On Mon, Aug 03, 2009 at 10:56:08PM +0200, Johannes Schmitz wrote:
Am Montag, den 03.08.2009, 12:59 +0200 schrieb Harald
Welte:
A3/A8 is performed between your SIM and the HLR/AUC of your home network,
no matter whether you're roaming or not.
--
- 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)
A3/A8 is either proprietary by the operator, or
comp128v2 or v3 (both are
officially closed, but it's safe to assume them to be known).
As Dieter has indicated in earlier mails, you can get SIM's that have comp128v1
or XOR as A3/A8 and which allow you to set the Ki of the SIM. With those
SIM's, or an emulated SIM you can test any implementation of encryption for
OpenBSC, once it has been done.
At this point I have got one general question, maybe also towards
Dieter:
How can A3/A8 be proprietary by any operator? How does international
roaming work then if there is no standardized algorithm?
5801
days inactive
5806
days old
5 comments
3 participants
participants (3)
-
Dakota C -
Harald Welte -
Johannes Schmitz