-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi, List!
As I promise, here my patch, to solve the problem I explained on
18.06.2010.
I'm now sure, my patch is NOT responsible of the problem sending SMS,
then I'd like to submit it to the list.
Greetings
- --
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 0
Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFMIdheAXzltVKV/2wRAnhaAJ96NdDGLzdAxvn6e1XV8uF8Xf62mACgqbPp
AD8uCeWjX/poI/fycmE0R1Y=
=+3SS
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi, again!
I have another question, and this is: how can I measure the distance of
a mobile from a BTS?
I'm reading the book "Die GSM-Dm-Kanäle im Dialog" by Joachim Göller,
and I learned, that a mobile phone sends, about every second, a
MEASUREMENT REPORT to the station, where it is logged.
In this report the mobile sends the signal power of the cell, where
it is logged, and of other neighborhood cells.
With these signals, I can measure the distance of the mobile from my
cell(s).
But I don't understand how can I get this values using OpenBSC.
Can someone explain me how can I do this?
Thanks a lot!
- --
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 0
Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFMIb5RAXzltVKV/2wRAv4zAKDpdHjed/uWweDtoknOaaHIOZlB1QCgtkhs
2jxsdaR/Y2ZmHdT1Nh/mVVY=
=9tWf
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi, List!
It seems not possible to send SMS anymore with the yesterday's version
of OpenBSC (0.9.0.889-f7a1c).
I tryed with another old version (0.9.0.531-b938) and it works (same
NanoBTS, same configuration).
If I activate the log on Telnet I get:
<0002> gsm_04_08.c:621 <- CM SERVICE REQUEST serv_type=0x04
mi_type=0x04 M(1552623826) <0012> db.c:159 DBI: 1: ambiguous column
name: updated <0002> gsm_04_08.c:572 -> CM SERVICE ACK
<0012> db.c:159 DBI: 1: ambiguous column name: updated
<0004> abis_rsl.c:1313 RF release on (bts=0,trx=0,ts=2,ss=0) but state
ACTIVE <0004> abis_rsl.c:1024 (bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but
state ACTIVE <0004> abis_rsl.c:1313 RF release on
(bts=0,trx=0,ts=2,ss=0) but state NONE <0004> abis_rsl.c:1024
(bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but state NONE
on the old version, and:
<0002> gsm_04_08.c:770 <- CM SERVICE REQUEST serv_type=0x04
mi_type=0x04 M(1910630704) <0002> gsm_04_08.c:695 -> CM SERVICE ACK
<0004> abis_rsl.c:1350 RF release on (bts=0,trx=0,ts=2,ss=0) but state
ACTIVE <0004> abis_rsl.c:1039 (bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but
state ACTIVE <0004> abis_rsl.c:1350 RF release on
(bts=0,trx=0,ts=2,ss=0) but state NONE <0004> abis_rsl.c:1039
(bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but state NONE
on the new one.
I see, the line 572 (or 695) in gsm_04_08.c, and it is the same
function (gsm48_tx_mm_serv_ack), but with other parameters.
Has someone else the same problem? How can I solve it?
Thanks a lot
- --
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 0
Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFMIbMRAXzltVKV/2wRAufHAJ9YkFNYhEXzdNSCuNwDEJcdoICWaACg5SD8
vITTtkdXrlqbxQOHFnoBpeE=
=69Za
-----END PGP SIGNATURE-----
Hi!
There is a more or less common pattern going through a lot of the problems
that we've been debugging recently, e.g.:
* ip.access BTS OML initialization sometimes doesn't complete
* BS-11 initialization problems (no BCCH content)
When I started to write OpenBSC (at that time still called bs11-abis),
I didn't know much about GSM 12.21 and was simply starting. As there is no
explicit information in 12.21 or 08.59 on whether or not there can be
multiple outstanding OML requests on one OML link, I simply assumed that
I could send a number of commands without having to wait for their ACK.
This made it easy to make quick progress early on in the project.
However, now we are facing some problems, e.g. we send RSL messages before
OML has completed its initialization. I suspect the BTSs don't like that
in a number of cases.
Possible solutiosn to this:
1) Always store the last OML command that we have issued and wait for an
explicit ACK/NACK before sending the next one. This means all
msgb's sent down by abis_nm_sendmsg() will end up in a queue which is
dequeued by ACK/NACK responses before sending the next command.
It's simple to implement and probably solves some of the ordering issues.
However, the caller has no idea when the queued operation will actually
complete (or if it will complete)
2) Implement some kind of blocking OML layer that will block the caller of
abis_nm_sendmsg() until the ACK/NACK has been received. This means that
writing the OML code will be much more natural, i.e. if the BTS returns
an error, the OML code can deal with it at exactly the message that
has caused the error.
However, this would imply that OML bringup would have to spawn one thread
for each BTS that is about to be brought up, as we cannot block the full
BSC just because one of the BTS's is reinitialized.
This would be a big difference from the existing non-blocking asynchronous
single-process + single-thread model that we have, and there is probably
a bit of thinking required how this would affect concurrent accesses to
our data structures. As OML is fairly independent from everything else,
I don't think it will be much of an issue, though.
At the moment I'm slightly more inclined to actually go for '2', since it is
a cleaner solution from my point of view.
What do you think?
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!
Some other 'bug' that I discovered while looking at traces recently is
in RSL, where we
* Send RSL ACTIVATE CHANNEL to open a channel on the BTS side
* Send RR IMMEDIATE ASSIGN through the AGCH to the MS
and only later receive RSL ACT CHAN ACK.
This seems to work fine, since we queue the messages in-order and dequeue them
in-order and simply assume the BTS will ACK. but what if it cannot activate
the channel due to a hardware problem? Or what if we have a bug and try to
assign the same channel twice?
However, on the E1 protocol analyzer the ordering of events was reversed, i.e.
the IMMEDIATE ASSIGN happened before the RSL CHAN ACT. I couldn't understand
why, since we always enqueue at the end of the queue and dequeue from the
front. But what I was missing: In a multi-TRX setup, the IMMEDIATE ASSIGN
gets sent over the TRX0 (AGCH, part of BCCH) while the RSL CHAN ACTIVATE
gets sent over TRX1. Each TRX has its own RSL link, and the TRX0 link
might be ready to receive our message a bit sooner than the TRX1 link...
So in this case, we send the messages in wrong order, and risk a channel
assignment error.
What needs to be done is to actually send the RSL CHAN ACT, save the state,
wait for the CHAN ACT ACK, then transmit the IMMEDIATE ASSIGN.
Similar issues might exist in other cases of channel activation, such as
handover.
--
- 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)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi, list!
I wrote an E-Mail on 18.06.2010, asking why many errors:
<0012> db.c:157 DBI: 1: ambiguous column name: id
<0012> db.c:157 DBI: 1: ambiguous column name: updated
appear (by sending, over Telnet, "sms send pending" and
"subscriber ... name ...").
Now I decided to search in the code for a reason.
There are two functions in db.c (db_sms_get_unsent_by_subscr [line 1055]
and get_equipment_by_subscr [line 301]) having queries with ambiguous
column name.
I suggest to correct the queries, adding the table name.
Unfortunately, I'm not sure, which names are correct...
I think, for db_sms_get_unsent_by_subscr it should be correct so:
result = dbi_conn_queryf(conn,
"SELECT * FROM SMS,Subscriber "
"WHERE sms.receiver_id >= %llu AND sms.sent is NULL "
"AND sms.receiver_id = subscriber.id "
"AND subscriber.lac > 0 "
"ORDER BY sms.receiver_id, sms.id LIMIT 1",
min_subscr_id);
or better, using JOIN:
result = dbi_conn_queryf(conn,
"SELECT * FROM SMS JOIN Subscriber "
"ON (SMS.received_id = Subscriber.id) "
"WHERE sms.receiver_id >= %llu AND sms.sent is NULL "
"AND subscriber.lac > 0 "
"ORDER BY sms.receiver_id, sms.id LIMIT 1",
min_subscr_id);
and for get_equipment_by_subscr so:
result = dbi_conn_queryf(conn,
"SELECT equipment.* FROM Equipment,EquipmentWatch "
"WHERE EquipmentWatch.equipment_id=Equipment.id "
"AND EquipmentWatch.subscriber_id = %llu "
"ORDER BY Equipment.updated DESC", subscr->id);
or, with the JOIN:
result = dbi_conn_queryf(conn,
"SELECT equipment.* FROM Equipment JOIN EquipmentWatch "
"ON (EquipmentWatch.equipment_id = Equipment.id) "
"WHERE EquipmentWatch.subscriber_id = %llu "
"ORDER BY Equipment.updated DESC", subscr->id);
but, as I said, I'm not sure...
Can someone confirm me, that I understood the queries correctly and my
correction proposals are right?
If they are right, I'll write a patch and submit it to the list.
I think, correcting this bug is important, since the queries with this
ambiguous column name will NOT be executed.
Thanks a lot
- --
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 0
Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFMIH4WAXzltVKV/2wRAr/mAJ9cQGOgl+ZTiutmehhS1aaeFegAmgCfWDxu
gUh/bQqXuK6PKdzWQ7gq6oo=
=GgRb
-----END PGP SIGNATURE-----
Hi to all,
I couldn't use sms send pending and show subscriber cache commands of Telnet
interface. Could anybody explain the functions and usage of these commands?
Thanks.
Jason.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi, List!
OpenBSC saves his DB normally in the current directory, but I can
overwrite this property with -l.
Now I'd like to know WHERE OpenBSC created the DB, and what is his name.
Is it possible?
I searched in the telnet's commands but I found anything useful...
Thanks a lot
- --
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 0
Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFMH27kAXzltVKV/2wRAhf5AKCTWzNChFAa+p8NfWppobxLCOU91wCcCaAd
Ez8o4AvIPuC0lvrSU89sBDo=
=++RV
-----END PGP SIGNATURE-----
