Dear list,
I recently integrated nanoBTS under OpenBSC. They work fine, but I encountered the following limitations.
1. Dynamic PDCH/TCH switching is allowed to be configured, but not working. The timeslots are stuck in TCH/F mode and never converted to PDCH. Is there any trick I need to do other than setting the channel type to TCH/F_PDCH?
2. No matter what I do, the BTS only schedules one uplink timeslot. If I understand it correctly, the PCU implementation in this case is inside the NanoBTS. Is there a way to change for example an NVRAM parameter to allow a more balanced UL/DL timeslot ratio?
3. Multi-TRX setup: it is quite a limitation that you cannot use any timeslots as PDCH in a multi-TRX setup on the secondary or third carriers at all. I don't think there is any solution to that, but it worth noting.
I hope someone can point me in the right direction with dyn PDCH switching and the single UL TS issue.
Thanks!
Regards,
Csaba
Good afternoon!
In libbsc/bsc_init.c we have the following case:
case GSM_BAND_900:
if (bts->c0->arfcn < 1 ||
(bts->c0->arfcn > 124 && bts->c0->arfcn < 955) ||
bts->c0->arfcn > 1023) {
LOGP(DNM, LOGL_ERROR, "GSM900 channel must be between 1-124, 955-1023.\n");
return -EINVAL;
}
break;
3GPP 45.005, table 2-2 gives valid channel numbers as:
P-GSM900 -> 1-124,
E-GSM900 -> 0-124 and 975-1023
R-GSM900 -> 0-124 and 955-1023
ER-GSM900 -> 0-124 and 940-1023
The code looks to bounds check ARFCN closest to R-GSM900, but omits ARFCN 0.
Is the check "bts->c0->arfcn < 1" erroneous, or am I missing some history?
Also should it really check for the R-GSM 900 range, or should it be E-GSM (more common)?
The other band checks look correct.
Kind Regards,
Mike
PS: osmo-arfcn is okay with ARFCN 0:
$ ./osmo-arfcn -a 0
ARFCN 0: Uplink 890.0 MHz / Downlink 935.0 MHz
Hi Folks,
When I build OpenBsc, I find a number of cases where libosmovty isn't in the link, but is needed by libosmoabis (basically anywhere libosmoabis is linked, but vty isn't) e.g.
/bin/ld: warning: libosmovty.so.1, needed by /.build/usr/local/lib/libosmoabis.so, not found (try using -rpath or -rpath-link)
/.build/usr/local/lib/libosmoabis.so: undefined reference to `install_node'
/.build/usr/local/lib/libosmoabis.so: undefined reference to `install_element_ve'
/.build/usr/local/lib/libosmoabis.so: undefined reference to `vty_out_rate_ctr_group'
/.build/usr/local/lib/libosmoabis.so: undefined reference to `vty_out'
/.build/usr/local/lib/libosmoabis.so: undefined reference to `install_element'
/.build/usr/local/lib/libosmoabis.so: undefined reference to `vty_install_default'
I'm not sure why/how I'm seeing this and others apparently aren't, but it looks legitimate. I've verified the configure script has [correctly] derived build configfrom the staged pkgconfig:
LIBOSMOABIS_CFLAGS='-I/.build/usr/local/include/ '
LIBOSMOABIS_LIBS='-L/.build/usr/local/lib -losmoabis '
So I wonder if libosmoabis.pc.in should be updated to include vty, a bit like libosmogb.pc.in i.e.
Signed-off-by: Michael McTernan <Michael.McTernan(a)wavemobile.com>
--- libosmoabis.pc.in (revision 19495)
+++ libosmoabis.pc.in (working copy)
@@ -6,6 +6,6 @@
Name: A-bis Core Library
Description: C Utility Library
Version: @VERSION@
-Libs: -L${libdir} -losmoabis
+Libs: -L${libdir} -losmoabis -losmovty
Cflags: -I${includedir}/
Otherwise every user of libosmoabis has to remember to link with -losmovty as well.
Kind Regards,
Mike
PS: I've stripped the very long full build paths from output - I don't really build in /.build!
