From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com>
The signature of mr_config and the BSC implementation didn't
match and the compiler was warning about it:
osmo_bsc_api.c:530:2: warning: initialization from incompatible pointer type
.mr_config = bsc_mr_config,
^
osmo_bsc_api.c:530:2: warning: (near initialization for ‘bsc_handler.mr_config’)
Change the mr_config again and provide an implementation
that will set the ms and bts data structure. It would be
better to put the size outside of the IE but I am not going
to change it right now. It would also be nice to either move
the AMR setting into the "nitb" structure or have the msc
data be used _after_ the bts settings. This needs to be
cleaned up in the next step.
Manually verified by placing a MO call and checking that
both the channel mode modify and the mode modify request
contain the multi rate config with the rate mr config
(length two bytes, version 1, icmi==1, no start mode being
set).
---
openbsc/include/openbsc/bsc_api.h | 2 +-
openbsc/src/libbsc/bsc_api.c | 2 +-
openbsc/src/osmo-bsc/osmo_bsc_api.c | 36 +++++++++++++++++++++++++-----------
3 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/openbsc/include/openbsc/bsc_api.h b/openbsc/include/openbsc/bsc_api.h
index a70d765..a3d12f2 100644
--- a/openbsc/include/openbsc/bsc_api.h
+++ b/openbsc/include/openbsc/bsc_api.h
@@ -40,7 +40,7 @@ struct bsc_api {
* not implemented AMR5.9 will be used.
*/
void (*mr_config)(struct gsm_subscriber_connection *conn,
- uint8_t *mr_ms_lv, uint8_t *mr_bts_lv);
+ struct gsm_lchan *lchan, int full_rate);
};
int bsc_api_init(struct gsm_network *network, struct bsc_api *api);
diff --git a/openbsc/src/libbsc/bsc_api.c b/openbsc/src/libbsc/bsc_api.c
index e157eb9..504f044 100644
--- a/openbsc/src/libbsc/bsc_api.c
+++ b/openbsc/src/libbsc/bsc_api.c
@@ -163,7 +163,7 @@ static void handle_mr_config(struct gsm_subscriber_connection *conn,
struct gsm48_multi_rate_conf *mr_conf;
if (api->mr_config)
- return api->mr_config(conn, lchan->mr_ms_lv, lchan->mr_bts_lv);
+ return api->mr_config(conn, lchan, full_rate);
if (full_rate)
mr = &lchan->ts->trx->bts->mr_full;
diff --git a/openbsc/src/osmo-bsc/osmo_bsc_api.c b/openbsc/src/osmo-bsc/osmo_bsc_api.c
index 00a10b3..fbeed77 100644
--- a/openbsc/src/osmo-bsc/osmo_bsc_api.c
+++ b/openbsc/src/osmo-bsc/osmo_bsc_api.c
@@ -491,9 +491,10 @@ static void bsc_cm_update(struct gsm_subscriber_connection *conn,
}
static void bsc_mr_config(struct gsm_subscriber_connection *conn,
- struct gsm48_multi_rate_conf *conf)
+ struct gsm_lchan *lchan, int full_rate)
{
struct osmo_msc_data *msc;
+ struct gsm48_multi_rate_conf *ms_conf, *bts_conf;
if (!conn->sccp_con) {
LOGP(DMSC, LOGL_ERROR,
@@ -504,18 +505,31 @@ static void bsc_mr_config(struct gsm_subscriber_connection *conn,
msc = conn->sccp_con->msc;
- conf->ver = 1;
- conf->icmi = 1;
+ /* initialize the data structure */
+ lchan->mr_ms_lv[0] = sizeof(*ms_conf);
+ lchan->mr_bts_lv[0] = sizeof(*bts_conf);
+ ms_conf = (struct gsm48_multi_rate_conf *) &lchan->mr_ms_lv[1];
+ bts_conf = (struct gsm48_multi_rate_conf *) &lchan->mr_bts_lv[1];
+ memset(ms_conf, 0, sizeof(*ms_conf));
+ memset(bts_conf, 0, sizeof(*bts_conf));
+
+ bts_conf->ver = ms_conf->ver = 1;
+ bts_conf->icmi = ms_conf->icmi = 1;
/* maybe gcc see's it is copy of _one_ byte */
- conf->m4_75 = msc->amr_conf.m4_75;
- conf->m5_15 = msc->amr_conf.m5_15;
- conf->m5_90 = msc->amr_conf.m5_90;
- conf->m6_70 = msc->amr_conf.m6_70;
- conf->m7_40 = msc->amr_conf.m7_40;
- conf->m7_95 = msc->amr_conf.m7_95;
- conf->m10_2 = msc->amr_conf.m10_2;
- conf->m12_2 = msc->amr_conf.m12_2;
+ bts_conf->m4_75 = ms_conf->m4_75 = msc->amr_conf.m4_75;
+ bts_conf->m5_15 = ms_conf->m5_15 = msc->amr_conf.m5_15;
+ bts_conf->m5_90 = ms_conf->m5_90 = msc->amr_conf.m5_90;
+ bts_conf->m6_70 = ms_conf->m6_70 = msc->amr_conf.m6_70;
+ bts_conf->m7_40 = ms_conf->m7_40 = msc->amr_conf.m7_40;
+ bts_conf->m7_95 = ms_conf->m7_95 = msc->amr_conf.m7_95;
+ if (full_rate) {
+ bts_conf->m10_2 = ms_conf->m10_2 = msc->amr_conf.m10_2;
+ bts_conf->m12_2 = ms_conf->m12_2 = msc->amr_conf.m12_2;
+ }
+
+ /* now copy this into the bts structure */
+ memcpy(lchan->mr_bts_lv, lchan->mr_ms_lv, sizeof(lchan->mr_ms_lv));
}
static struct bsc_api bsc_handler = {
--
2.3.5
Greetings!
I'm not sure if I am emailing the right list, but I got stuck with an error with making Osmo-TRX and need some help.
To give you some background, I am doing a project with OpenBTS and GSM. My project is being built on the small, yet powerful Beaglebone Black. As you might now, Osmo TRX is one of the few ARM-friendly transceivers for OpenBTS. I was following the instructions as provided on the main website for install it and when it came time to make the project, I ran across an error:
Make: ***No rule to make target '/Makefile.common', needed by 'Makefile.in'. Stop.
I am using the code from the github site. Unfortunately, I could not diagnose the bug and the error.
Would anyone be able to assist me? Thank you so much for your help, I really do appreciate it!
As an added note:
Another error that I ran into that you might want to know about is when I ran "autoreconf -i", I got an error saying:
C objects in subdir but 'AM_PROG_CC_C_0' not in 'configure.ac'
Which caused automake to fail with exit status 1. However, simply adding 'AM_PROG_CC_C_0' to the file configure.ac seemed to fix the problem.
Thanks again! :)
Dear all,
after my futile attempt in September last year to finally merge l1sap
(see the 201409-l1sap branch), I'm making one final attempt.
The following branches have been created + pushed:
* 201509-l1sap: The core l1sap change that I intend to merge
This is most of the heavy lifting by introducing L1SAP between the
sysmobts l1 and the common code. Hasn't been modified much.
* 201509-trx-rebase: osmo-bts-trx support that I intend to merge
This is what I can merge without too much review, as it does not touch
the common code, except some minor l1sap fixes, and
* the AMR multirate change, requiring a matching patch on openbsc.git
* bts_model_abis_close() which should be fine
* ability to configue multiple TRX from VTY
* 201509-fairwaves-rebase Stuff I cannot merge in its current form
* the abis/e1inp multi-trx and reconnect changes require in-depth
review and testing. Part of it is marked as HACK even by Andreas.
* a so-called 'fix for use after free' that is actually a patch that
introduces another copy for every primitive and is only required for
the loopback mode
* copying gsm_data_common.[ch] into the repo for debian packaging
[let's not discuss further work on this before l1sap and trx-rebase
are merged]
I recommend everyone with a stake in this to review or test the code
in 201509-l1sap and 201509-trx-rebase now. My schedule is to merge at
some point next week, unless someone raises some serious objections.
What needs to be done after the merge is to unify the
src/common/power_control.c code from Holger originating in master with
src/common/loops.c from Andreas originating from the osmo-trx branch.
There is no doubt that the power control and timing advance loops should
be part of common, as this is required in virtually any BTS hardware.
However, we can safely merge/unify this after the merging of the above
branches.
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 Jacob,
Finally I managed to get everything in a working order, so I can finally start testing the GPRS part of OpenBSC/Osmo-PCU with an USRP B200.
I am using a Cat 12 device with a 4 PDCH configuration.
In the past I wrote a little script to test the PRACH stability of OpenBTS, which sends a single ping to the gateway address, waits until the session goes into idle, and then tries again. The goal is to generate as many PRACH as possible and check if there is a response.
I used this script and it turns out that around 1 out of every 20 requests the ping is not reaching the gateway, and the UE indicates an abnormal DL TBF release.
I attached the UE side log, so you can take a look.
During this issue there is no reasonable frequency nor timing variation indicated on the UE side.
What I noticed is the very high number of RLC resent and RLC restarted. After a few minutes of pinging, this is the result from the PCU:
RLC Sent : 18015 (0/s 0/m 0/h 0/d)
RLC Resent : 17596 (0/s 0/m 0/h 0/d)
RLC Restarted : 15669 (0/s 0/m 0/h 0/d)
RLC Stalled : 0 (0/s 0/m 0/h 0/d)
Please note that the ARFCN I use is completely clean, I filter the uplink with proper duplexer and the TRX is not complaining about anything.
Also interesting that during constant pinging (the system does not need to do PRACH), this problem is not popping up.
Will update my UHD stack from 3.8.0 to 3.9.0 just to test with the latest, but I don't think itt will change anything about this issue. And to be hones, we've seen similar PRACH related issues with OpenBTS GPRS too.
If you need any more logs or you have an idea what to try, I am happy to do that. :-)
Regards,
Csaba
Hi all,
I am getting rid of some old hardware to make space for new stuff.
The most bulky item in my collection is a Motorola Horizon macro BTS.
If you don't know it, check out
http://openbsc.osmocom.org/trac/wiki/Motorola_Horizon_macro in the
OpenBSC wiki.
IMPORTANT: Due to the large deviations of Motorola from standard GSM,
this BTS does not have an Abis interface and thus is not compatible with
OpenBSC!
Still, it contains some interesting electronics, including the 40W PAs
and hybrid combiner/duplexers.
The unit comes with three TRX (as on the pictures linked above), as well
as my custom-made serial cable to access the console port of all three
main processors, see
http://openbsc.osmocom.org/trac/wiki/Motorola_Horizon_macro/MCUF_Console
You can have it free of charge if you take care of shipping.
Please contact me privately if you are interested.
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 all,
the history of OpenBSC (and thus the Osmocom umbrella project) started
with the Siemens BS-11 microBTS.
I still have three of those BTS, and think that one is enough, i.e. two
BS-11 are available.
If you are an active contributor to OpenBSC or represent a public
research organization, I will provide them free of charge, you only have
to pay for shipping.
For all other interested parties, I would like 200 EUR per unit (excl.
shipping), which still makes it one of the cheapest options for running
your own network with OpenBSC.
If you're not familiar with the BS-11 and its technical data, please check
http://openbsc.osmocom.org/trac/wiki/BS11 and related pages i nthe wiki.
They units I have available are with 230V power supply and operate in
the GSM900 band.
I also have one compatible HFC-E1 PCI E1 adapter (supported by mISDN +
OpenBSC) available.
Please contact me privately if you are interested.
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,
as a part of our project at university, we implemented extraction of EPC
Capability flag. This flag is a bit sent by mobile phone to indicate
support of EPC (or LTE). This bit is extracted during processing of Attach
request to log this information. An function to check the the of this flag
for given sgsn context is also created to make it reusable.
For the extraction of the EPC Capability field we used the location
described in TS 24.008 v10.15.0 section 10.5.5.12.
This can be interesting information for any developers experimenting with
devices supporting 4G, so I think I would be a good idea to make it
available in the original repository. The patch for this change is in the
attachment.
Best regards,
Tomas Movay
Dear Harald,
This is probably no the best moment, but as the original implementer of DAHDI support in OpenBSC, maybe you can fix this.
It seems that DAHDI 2.7.0 breaks the compatibility with OpenBSC. I think the only thing they changed is the way you need to refer to the E1 device in /dev and because of that, OpenBSC will not going to find the DAHDI device and give an error in that regard. The last time I checked (around version 2.9) this was the only problem, otherwise OpenBSC compiles fine with DAHDI.
Anyway, the use of DAHDI 2.6.3 (the latest which works with OpenBSC) forces us to use very old kernels (and OSes), and I am quite sure we are not the only ones still using OpenBSC with E1. :-)
I hope you will have some time and take a quick look into this.
If you dont have any E1 based hardware anymore, I am more than happy to help you and test the fix on our (Nokia InSite, MetroSite, Ultrasite based) system.
Thank you!
Regards,
Csaba