Hi!
As more and more code is moving into libraries (like I just did with the
LAPDm code, and like pablo is working on with libosmo-abis), we needed a
solution how to allocate and use the LOGP subsystem constants like DRSL,
DRR, ... from within libraries.
The existing logging code wasn't really prepared for that. I've now
come um with a hack to extend it while preserving compatibility to
applications:
* we use negative numbers starting from -1 for library-internal
subsystems
* those numbers get converted to a positive index into the various
arrays at run-time. So -1 ends up one entry higher in the array
than the last application-providede log category/subsystem.
As part of this change, the array allocations are now dynamic, i.e there
is no maximum limit for the number of log categories that an application
can register with the core.
Only for libraries (even outside libosmocore), we have compile-time
registration, i.e. the 'struct log_info_cat' and the D* constant need to
be defined inside libosmocore. I think this is an acceptable
compromise.
Furthermore, if LOGP()/DEBUGP() ever see a subsystem number that it
doesn't know, it will assign it to the new 'DLGLOBAL' (Debug Library
GLOBAL) category, i.e. there cna be no array overflows.
This ensures that even an external library using a 'newer' D* constant
will not crash or otherwise fail, it will simply log in a slightly
different way.
Regards,
Harald
--
- 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)
Hi everybody!
I need to replicate in my private network the functionalities of an SGSN and
a GGSN for academic purpose. I see the openGGSN project and I understand
that it's composed by two components: sgsnemu and ggsn.
What I want to ask to you is if I could test all the PDP Context activation
process with these two components and how.
This is the real (very semplified) process:
Mobile Phone ---> SGSN ---> GGSN ---> SGSN ---> Mobile Phone
(for a full description of the process see
here<http://www.eventhelix.com/RealtimeMantra/Telecom/gprs_attach_pdp_sequence_d…>
)
My suspicion, tell me if I'm wrong, is that sgsnemu component allow to test
only this part of the complete process:
SGSN ---> GGSN ---> SGSN
(simulating the mobile terminal request but not really accepting it from an
external module/device). Is it right?
How could I test all the process? Consider that I could use a linux pc
instead of a mobile phone.
Thank you very much!!!
--
Guido Cilia
Web: http://www.guidocilia.it
E-Mail: guidocx84(a)gmail.com
Skype: guidocx84
Hi all,
it seems like supporting the Motorola BTS from OpenBSC is a really big
challenge. Not only are there problems regarding an unknown
configuration database format (see
http://laforge.gnumonks.org/weblog/2011/06/18/)
Dieter has found the following excellent document, which in Chapter 5
describes the architecture of the Motorola specific changes to A-bis:
http://read.pudn.com/downloads61/ebook/212957/SYS01.pdf
Judging from the document:
* there is an unknown 'motorola executive header' in front of RSL
* many RSL standard messages have been replaced by proprietary ones
* they use a mixture of 08.08 (A) and 08.58 (A-bis) information elements
* many features normally found in the BSC are implemented in the BTS,
e.g. the entire CHAN RQD / RSL CHAN ACT / IMM ASS CMD sequence is
done fully inside the BTS.
As a result, I think it will be a quite complex project to support those
BTSs from OpenBSC. It's not just a matter of adding some small
vendor-specific OML messages like with Siemens, Ericsson and ip.access.
While it might still be interesting, I think it's unrealistic to assume
this would happen ahead of the camp [unless somebody finds a compatible
Motorola BSC that they can borrow us for analysis + protocol tracing].
Thus, the focus for the 2011 CCC Camp is now back to ip.access. The
main issues we will be facing is on the RF side, i.e.
* RF PA for the TX side
* combining the PA outputs to be transmitted on one antenna
* filter + LNA for Rx side
* splitting the Rx signal
As indicated previously, I would love to see something like two BTS
with three TRX each.
If we'd recycle the duplexer/combiner blocks from the Motorola BTS, we
could do something like three sites with 2 TRX each. (as they can only
combine two TRX).
We _might_ also be able to re-cycle the TX PA from the Motorola CTUs, at
least on the RF side it would be pretty easy to drive them from a
nanoBTS rather than its internal source (as there's a connector).
The bigger question is how do we get the controller logic of the PA into
a state that the PA is actually enabled and active...
Regards,
Harald
--
- 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)
Hi zecke and others,
I may have found a cause of one of the problems that we've been
experiencing in nanoBTS bring-up, at least at some point in the past.
The problem could be observed/described as: During the first OML
connect of the nanoBTS, OpenBSC fails to bring it up completely. Second
and successive connects worked fine.
What I have just noticed is that we never re-set the NM state
information for the 12.21 MOs inside OpenBSC. This means, if the A-bis
link is lost, the old state information continues to exist.
I guess it would be cleaner to simply re-set all the nm_state strucures
that are part of the 'struct gsm_bts', gsm_bts_trx, etc. when the A-bis
link is lost.
As I'm working in this area right now anyway, I intend to produce a
patch addressing the issue.
But now that I think more about it: I guess it is unrelated to the old
problem, as a typical work-around was to re-start OpenBSC, at which time
all state is re-set again.
Regards,
Harald
--
- 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)
Dear all,
I want to buy some nanoBTS or HSL 2.75G picocell .
Is there any body who wants to sell nanoBTS or HSL 2.75G picocell ?
Looking forward for any offer .
Regards,
jngpz(a)163.com
2011-06-19
Dear Developers,
I mentioned earlier that I found a tutorial in which we read that this cell
is within the box's serial port.
I found him looking for a RS485 port outlet, and 2x5-pin lines of pins.
Images from the PCB:
http://www.facebook.com/media/set/?set=a.1979958333026.114473.1065188491
IPSEC have read so far by launching tube through a communication
gateway through
which to get "home location register" information, etc..
Whether there is a chance to even download the firmware via the serial
terminal analysis?
Or perhaps to be found in lines of pins USB option?
The presentation referred to the serial port connection just yet to start
when you press the reset button four times, then the boot menu to configure
the IP address, login data.
greetings: bthomyka
Dear Developers!
Currently, the only tool I have found this information:
http://users.atw.hu/helvei/UAP3801E.rar?atw_referer=http% 3A% 2F% 2Fmobil-
telefon.vatera.hu 2Fmobiltelefon_tartozek%%% 2Fegyeb
2F4_db_huawei_ap_femtocella_mobil_bazisallomas_1459406466.html
This is a power point presentation, the pages visible to a certain set of
procedures.
Although I do not know how much help in the development, but I share with
you.
Consulted during a programmer who is interested in finding a "reverse
engineering" and curious about the possibility of the device, the
communication.
I am confident that if he succeeds, much of the project promotes the
development
of OpenBSC.
Regards,
bthomyka