Hi.
Attached is a small patch which replaces direct call to comp128 from libosmocore to
auth api call. This will help to remove comp128 from libosmocore public api and to
use other auth functions in openbsc in future.
--
best regards,
Max, http://fairwaves.ru
Hi all,
We're moving this discussion to the mailing list, as it seems it is
more generic and complex than we've thought initially.
The issue arose when I started doing load testing of the OsmoTRX
transceiver and disabled all gating in it. As a result, all incoming
noise was processed as valid Normal Bursts and Access Bursts and sent
up to OsmoBTS. This leads to a situation, similar to a RACH flood,
when there are more RACH requests coming, than a BTS could reasonably
process. And this leads to an unbounded increase of the AGCH queue in
the BTS - it consumes a few Mb per minute.
I think that this is the root cause of the issue we've seen at a
Netherlands festival installation, when 20K phones suddenly started
connecting to our station after official networks went down. When the
amount of RACH requests exceeded available CCCH capacity (took <5
seconds), mobile phones stopped answering out IMM.ASS messages.
Hypothesis is that the AGCH queue became so long, requests were sent
too late for a phone to receive it. And thus no phones answered to our
IMM.ASS messages. Unfortunately, I wasn't able to collect enough data
to check this hypothesis during that time and we don't have another
big festival on hands atm.
An attached is a quick fix for the unbounded queue growth. It uses a
hardcoded value for the maximum queue length, which is fine for our
load testing, but not flexible enough for the real life usage. We
should make the AGCH queue long enough to keep high performance. At
the same time, it must not exceed MS timeout or _all_ IMM.ASS messages
will miss their target MS's.
We could make this parameter user-configurable on a BTS side, but it
seems more reasonable to automatically calculate it, depending on the
channel combination and timeout values. But this should be done on the
BSC side. So the questions are:
1) what is a good way to calculate it?
2) should we configure this queue length over OML, or move the queue
from BTS to BSC?
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Hi Jason,
On Fri, Nov 08, 2013 at 01:21:46PM +0000, Jason DSouza wrote:
> But I'm waiting at Opstart for Obj Class - RADIO_CARRIER to trigger
> trx-init() which is never received from BSC. That is where I'm struck
> now. All this so far is similar to sysmobts interface, something
> similar to bts_model_opstart() function in osmo-bts-sysmo.
Please see the following code from bts_ipaccess_nanobts.c:
==============
/* Callback function to be called whenever we get a GSM 12.21 state change event */
static int nm_statechg_event(int evt, struct nm_statechg_signal_data *nsd)
{
[...]
case NM_OC_RADIO_CARRIER:
trx = obj;
if (new_state->operational == NM_OPSTATE_DISABLED &&
new_state->availability == NM_AVSTATE_OK)
abis_nm_opstart(trx->bts, obj_class, trx->bts->bts_nr,
trx->nr, 0xff);
break;
==============
So the opstrart for the RADIO_CARRIER is sent in response to an incoming
NM_MT_STATECHG_EVENT_REP withe the operational state set to DISABLED and
the availability set to OK.
My guess is that you are not sending such a state event from the BTS to
the BSC. I can also not see that in the pcap file you have sent. All
OML messages in there relate to the Site MAnager or the BTS object
class, but there are no messages related to any other MOs.
As indicated, it is best to start from a known-working setup with a
supported BTS model, or at least from a protocol trace of an existing
supported configuration.
Please also make sure to set your 'bts model' to nanobts, I _think_ the
'bts model sysmobts' is still broken.
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)
Currently the NET_DST information element (see GSM 24.008) is not
included in generated MM info messages even when the DST field in the
timezone info has been set via the VTY or the control interface.
This patch modifies gsm48_tx_mm_info() to append this information
element if (and only if) a non-zero DST has been configured. The
DST IE is not part of GSM 4.8. Therefore it will only be sent, if the
DST offset is configured to a value != 0.
Sponsored-by: On-Waves ehf
---
openbsc/src/libmsc/gsm_04_08.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c
index 3cfc455..0d1ba7b 100644
--- a/openbsc/src/libmsc/gsm_04_08.c
+++ b/openbsc/src/libmsc/gsm_04_08.c
@@ -656,6 +656,7 @@ int gsm48_tx_mm_info(struct gsm_subscriber_connection *conn)
struct tm* gmt_time;
struct tm* local_time;
int tzunits;
+ int dst = 0;
msg->lchan = conn->lchan;
@@ -749,6 +750,9 @@ int gsm48_tx_mm_info(struct gsm_subscriber_connection *conn)
tzunits = tzunits + (bts->tz.mn/15);
ptr8[7] = bcdify(tzunits);
}
+ /* Convert DST value */
+ if (bts->tz.dst >= 0 && bts->tz.dst <= 2)
+ dst = bts->tz.dst;
}
else {
/* Need to get GSM offset and convert into 15 min units */
@@ -768,8 +772,19 @@ int gsm48_tx_mm_info(struct gsm_subscriber_connection *conn)
}
else
ptr8[7] = bcdify(tzunits);
+
+ /* Does not support DST +2 */
+ if (local_time->tm_isdst)
+ dst = 1;
}
+#ifdef GSM48_IE_NET_DST
+ ptr8 = msgb_put(msg, 3);
+ ptr8[0] = GSM48_IE_NET_DST;
+ ptr8[1] = 1;
+ ptr8[2] = dst;
+#endif
+
DEBUGP(DMM, "-> MM INFO\n");
return gsm48_conn_sendmsg(msg, conn, NULL);
--
1.7.9.5
Hi all,
time is moving fast, and I want to start some initial discussion and
planning for OsmoDevCon 2014.
There are basically four questions which I'm raising below. Please
provide your feedback to the osmocom-event-orga mailing list only, to
avoid cross-posting over all the project lists.
= Who? =
My intention is to keep it an 'active developer/contributer only' event,
like we had it before. I would also want to keep the group relatively
small, to keep the 'Osmocom family' atmosphere.
If desired, we could have one half or full day of public prsentations in
a larger auditorium, but the developer meeting should be a close group,
as known so far.
= Where? =
If we keep the number of attendees within the same range as this year,
then I'm sure we could again hold it at the same venue. I know it is
not perfect, but it is a place that we have access to, 24 hours per day,
and free of cost for community projects like osmocom.org.
If the community wants a larger event, then this is something that would
require more funds and much more time organizing. And that is something
that I personally could not offer to take care of, sorry. I'm happy to
attend and support any larger events, but I'm unable to take care of
fundraising and venue research.
= When? =
Q1/2014. In January, I'm not aware of any 'blocker' events. February,
there is Fosdem (Feb 1 + Feb 2), and MWC from Feb 24 through Feb 27. In
March there is CeBIT (March 10-14) and Easter holidays (with EasterHegg
March 17-21). Did I miss any other FOSS / mobile event that might clash
in Q1?
So my preference woudl be to do it either late January (23-26) or in
February (6-9 or 13-16). Any preferences regarding preferred schedule?
Once we have some concencus here on the list [and we want to do it in
the same size / venue], I'll talk to IN-Berlin.
= What? =
I think that question is easy to answer, if we have the above three
figured out... There's no shortage of topics, I suppose.
You can start adding your suggestions to
http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014
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)
The implementation of for_each_line is based on strtok() and skips
any sequence of CR and LF. Thus empty lines are never detected. There
exists code which tests for an empty line to detect the beginning of
the SDP part which is dead code currently (the parser works
nevertheless due to other reasons). So the semantics of this macro
have been misunderstood at least once.
This patch renames the macro to reflect the semantics more precisely.
Sponsored-by: On-Waves ehf
---
openbsc/src/libmgcp/mgcp_protocol.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/openbsc/src/libmgcp/mgcp_protocol.c b/openbsc/src/libmgcp/mgcp_protocol.c
index 7096495..c040ab1 100644
--- a/openbsc/src/libmgcp/mgcp_protocol.c
+++ b/openbsc/src/libmgcp/mgcp_protocol.c
@@ -36,7 +36,7 @@
#include <openbsc/mgcp.h>
#include <openbsc/mgcp_internal.h>
-#define for_each_line(line, save) \
+#define for_each_non_empty_line(line, save) \
for (line = strtok_r(NULL, "\r\n", &save); line;\
line = strtok_r(NULL, "\r\n", &save))
@@ -527,7 +527,7 @@ static struct msgb *handle_create_con(struct mgcp_parse_data *p)
return create_err_response(NULL, 510, "CRCX", p->trans);
/* parse CallID C: and LocalParameters L: */
- for_each_line(line, p->save) {
+ for_each_non_empty_line(line, p->save) {
switch (line[0]) {
case 'L':
local_options = (const char *) line + 3;
@@ -652,7 +652,7 @@ static struct msgb *handle_modify_con(struct mgcp_parse_data *p)
return create_err_response(endp, 400, "MDCX", p->trans);
}
- for_each_line(line, p->save) {
+ for_each_non_empty_line(line, p->save) {
switch (line[0]) {
case 'C': {
if (verify_call_id(endp, line + 3) != 0)
@@ -771,7 +771,7 @@ static struct msgb *handle_delete_con(struct mgcp_parse_data *p)
return create_err_response(endp, 400, "DLCX", p->trans);
}
- for_each_line(line, p->save) {
+ for_each_non_empty_line(line, p->save) {
switch (line[0]) {
case 'C':
if (verify_call_id(endp, line + 3) != 0)
@@ -873,7 +873,7 @@ static struct msgb *handle_noti_req(struct mgcp_parse_data *p)
if (p->found != 0)
return create_err_response(NULL, 400, "RQNT", p->trans);
- for_each_line(line, p->save) {
+ for_each_non_empty_line(line, p->save) {
switch (line[0]) {
case 'S':
tone = extract_tone(line);
@@ -1218,7 +1218,7 @@ int mgcp_parse_stats(struct msgb *msg, uint32_t *ps, uint32_t *os,
return -1;
/* this can only parse the message that is created above... */
- for_each_line(line, save) {
+ for_each_non_empty_line(line, save) {
switch (line[0]) {
case 'P':
rc = sscanf(line, "P: PS=%u, OS=%u, PR=%u, OR=%u, PL=%d, JI=%u",
--
1.7.9.5
Hello,
I'm working on producing a graphic which shows Osmocom projects that
can be used in a production GSM network, along with related projects
that are used together with these. I'd also like to show these in the
context of legacy networks, e.g. with existing BSC and MSC etc.
First, I need to be sure I have the complete list:
— Osmocom
* BSC (or much more): OpenBSC (osmo-bsc or NITB)
* BTS: OsmoBTS + sysmoBTS or osmo-trx/UmTRX in Fairwaves solution
* PCU: osmo-pcu
* SGSN: OsmoSGSN
* GGSN: OpenGGSN
* ??: cellmgr_ng (what would be the best use cases to show? E.g. as in
bsc_nat diagram)
* ??: bsc_nat (show as in diagram on wiki? Perhaps with fewer elements...)
* ??: osmo-gbproxy
Not sure about the status of osmocom-lcs?
— Ecosystem (supporting projects)
* Linux Call Router
* FreeSWITCH
* Telscale SS7 card (for interfacing with legacy networks)
— Legacy
* nanoBTS and others
* BSC
* MSC
* ... ?
The idea would be to try and show as many use cases as is reasonably
possible and without making the graphic a mess.
I'd appreciate any comments and suggestions folks may have.
Cheers,
Andrew
--
Andrew Back
http://carrierdetect.com