This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgOn Fri, Jul 03, 2009 at 11:21:59AM +0200, Nordin wrote:
> As I am not an experienced GSM engineer I can't fully understand the GSM
> specs.
> But I found this in paragraph 4.1.1.2.1 of GSM 04.08:
> "NOTE:
> Whenever GMM performs a combined GMM procedure, a GPRS MS enters the MM
> state
> MM LOCATION UPDATING PENDING in order to prevent the MM to perform a
> location update procedure."
I think the way OpenBSC is working (or at leats supposed to work), we don't
permit for any combined GMM procedures but rather tread GSM and GPRS entirely
separate. I don't remember the terminology, but there are three entirely
different methods on how MM and GMM interact. They probably reflect the
evolvement of GSM equipment. The simplest case to move forward for us is
to keep GSM and GPRS entirely separate, i.e. not risking any regressions
due to the inclusion of GPRS support (if at all, at some point).
I strongly believe the problem is related to our SYSTEM INFROMATION headers,
but I currently don't have the time to debug/verify the implementation that I
did for it in some git branch...
> P.S.: Is everybody on holiday...:)
no, working full-time on GSM security right now.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)