OpenBSC

openbsc@lists.osmocom.org

4315 discussions

include grouping
by Neels Hofmeyr 14 Jul '16

14 Jul '16

Hi Max, in e.g. e6052c4cc756f7d3a5023a0ba57fe8d80783967c you have added #include <stdbool.h> in various files. I'd like to nitpick about the place where you put it: index 3cba5d1..3d7c244 100644 --- a/openbsc/include/openbsc/gsm_subscriber.h +++ b/openbsc/include/openbsc/gsm_subscriber.h @@ -5,6 +5,8 @@ #include <osmocom/core/linuxlist.h> #include <osmocom/gsm/protocol/gsm_23_003.h> +#include <stdbool.h> + (there are also some more instances) I'd prefer if we keep system headers grouped on top. Thanks :) ~Neels

4 3

fully dynamic TS, naming
by Neels Hofmeyr 14 Jul '16

14 Jul '16

About http://osmocom.org/issues/1757#note-4 With the current naming scheme, the logical name for a fully dynamic TCH/F-TCH/H-PDCH channel would be GSM_PCHAN_TCH_F_TCH_H_PDCH timeslot 2 phys_chan_config TCH/F_TCH/H_PDCH Is it asking for trouble to just name it DYN instead? GSM_PCHAN_DYN timeslot 2 phys_chan_config DYN I'm in (at least) two minds about it, opinions welcome... ~Neels

3 3

Full state machine implementation
by Sipos Csaba 13 Jul '16

13 Jul '16

Dear Harald, Just seen your branch regarding FSM: http://cgit.osmocom.org/openbsc/log/?h=laforge/om2000-fsm Do you think this is also doable for the Nokia Site BTS series? Because if you think its doable, based on your work I a would like to try and implement this for Nokia support too, as even between different Site versions (InSite, Metro and UltraStie), there are some differences in the OML initialization (especially in the timing of it) which is now handled by hard coded values, instead of a proper state machine. Regards, Csaba

4 5

osmo-bts-trx: patch 498
by Neels Hofmeyr 13 Jul '16

13 Jul '16

Hi osmo-bts-trx folks, reviews on https://gerrit.osmocom.org/498 would be appreciated :) Thanks! ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

1 0

Error compiling libosmocore under Mac Osx
by Juan Antonio Barea Lopez 13 Jul '16

13 Jul '16

Hello all, in order to try grgsm software, it asked for the libosmocore library and i proceed to configura and install it. Configure process went ok, but when trying to "make", it gets a error about unidentified symbols. I have been searching on the web and got several hints that it could be based on the 64bit version of gcc used. The error in question is this: **********Output error begins here********** /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive Making all in include make[2]: Nothing to be done for `all'. Making all in src /Applications/Xcode.app/Contents/Developer/usr/bin/make all-am make[3]: Nothing to be done for `all-am'. Making all in src/vty make[2]: Nothing to be done for `all'. Making all in src/codec CCLD libosmocodec.la Undefined symbols for architecture x86_64: "_bitvec_get_bit_pos", referenced from: _osmo_fr_check_sid in gsm610.o "_bitvec_get_uint", referenced from: _osmo_hr_check_sid in gsm620.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [libosmocodec.la] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 *********End of output error************ I tried to also made a reconfigure -i but without success. Has anyone experienced this error or have an idea about what could be happening?. Thanks in advance!!!!

3 2

GPRS on osmo-trx not working
by Neels Hofmeyr 11 Jul '16

11 Jul '16

Hi List, Voice is working well, but I can't seem to get GPRS working on osmo-trx. I used the standard debian 8.4 packages for UHD which seem to work, and documented that at http://osmocom.org/projects/osmotrx/wiki/OsmoTRX#Dependencies I also tried to use a PCU from before EDGE support was merged, so that's not causing it. Any ideas on what might be causing this? With sysmobts, for example, I needed to configure the pcu with --enable-sysmocom-dsp. Any such things with osmo-trx? I'm running both pcu and osmo-bts-trx as root with -r 1. Some of the log messages look quite bad, like 20160628170840743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 I didn't do the rts-advance increase by 5, because when that log message is issued, the PCU is not running yet: 20160628170837632 DL1C <0006> scheduler.c:240 Prim for trx=0 ts=0 at fn=272652 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=272658) Below are some logs and attached are the config files. The identical setup is working for other BTS models, the osmo-bts.cfg is the only difference. Thanks for any hints! ~Neels TRX: linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.007.003-0-unknown opening configuration table from path :memory: Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 1 EDGE support............ Disabled External Reference...... Disabled C0 Filler Table......... Disabled Diversity............... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 -- Operating over USB 2. -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 32.000000 MHz -- Actually got clock rate 32.000000 MHz -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Asking for clock rate 26.000000 MHz -- Actually got clock rate 26.000000 MHz -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting B210 4 SPS -- Transceiver active with 1 channel(s) NOTICE 140232141276928 17:27:18.0 Transceiver.cpp:241:start: Starting the transceiver NOTICE 140232141244160 17:27:18.5 Transceiver.cpp:380:pushRadioVector: dumping STALE burst in TRX->USRP interface ^ I see ~130 of these notices of a stale burst, but all with an identical timestamp, and only once after osmo-bts-trx starts up. PCU: 20160628170840742 DL1IF <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS 20160628170840742 DL1IF <0001> osmobts_sock.cpp:285 osmo-bts PCU socket has been connected 20160628170840742 DL1IF <0001> pcu_l1_if.cpp:359 BTS available 20160628170840742 DNS <0008> gprs_ns.c:233 NSVCI=65534 Creating NS-VC 20160628170840742 DNS <0008> gprs_ns.c:233 NSVCI=1800 Creating NS-VC 20160628170840742 DNS <0008> gprs_ns.c:1568 NSEI=1800 RESET procedure based on API request 20160628170840742 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170840742 DL1IF <0001> pcu_l1_if.cpp:83 Sending activate request: trx=0 ts=5 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:486 PDCH: trx=0 ts=5 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:83 Sending activate request: trx=0 ts=6 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:486 PDCH: trx=0 ts=6 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:83 Sending activate request: trx=0 ts=7 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:486 PDCH: trx=0 ts=7 20160628170843743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170846743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170849743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170852743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170855743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170858743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170901743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170904744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170907744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170910744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170913744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170916744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170919744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170922744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170925745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170928745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170931745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170934745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170937745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170940745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170943746 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) SGSN: <0010> gprs_ns.c:233 NSVCI=65534 Creating NS-VC 20160628170817898 DGPRS <000f> sgsn_main.c:361 VTY at 127.0.0.1 4245 20160628170817898 DGPRS <000f> sgsn_main.c:370 CTRL at 127.0.0.1 4251 20160628170817898 DLGTP <0023> gtp.c:701 GTP: gtp_newgsn() started 20160628170840743 DNS <0010> gprs_ns.c:233 NSVCI=65535 Creating NS-VC 20160628170840743 DNS <0010> gprs_ns.c:1262 Creating NS-VC for BSS at 10.9.1.120:23000 20160628170840743 DNS <0010> gprs_ns.c:834 NSVCI=65535(invalid) Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170840743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170840743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170840743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170843743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170843743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170843743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170843743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170846743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170846743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170846743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170846743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170847899 DGPRS <000f> gprs_sgsn.c:790 Checking for inactive LLMEs, time = 16442 20160628170849743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170849743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170849743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170849743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170852743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170852743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170852743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170852743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170855743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170855743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170855743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170855743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170858743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170858743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170858743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170858743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170901744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170901744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170901744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170901744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170904744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170904744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170904744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170904744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170907744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170907744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170907744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170907744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170910744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170910744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170910744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170910744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170913744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170913744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170913744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170913744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170916744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170916744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170916744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170916744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170917900 DGPRS <000f> gprs_sgsn.c:790 Checking for inactive LLMEs, time = 16472 20160628170919744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170919744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170919745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170919745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170922745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170922745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170922745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170922745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170925745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170925745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170925745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170925745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170928745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170928745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170928745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170928745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170931745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170931745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170931745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170931745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170934745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170934745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170934745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170934745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170937745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170937745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170937745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170937745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170940746 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170940746 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170940746 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170940746 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170943746 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170943746 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170943746 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170943746 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170946746 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170946746 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170946746 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170946746 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 osmo-bts-trx: [...] 20160628170836837 DOML <0001> oml.c:217 OC=CHANNEL INST=(00,00,06) Tx STATE CHG REP 20160628170836877 DOML <0001> oml.c:817 OC=CHANNEL INST=(00,00,07) SET CHAN ATTR (TSC = 7) 20160628170836877 DL1C <0006> scheduler.c:1273 Configuring multiframe with PDCH trx=0 ts=7 20160628170836877 DOML <0001> oml.c:884 ADM state already was Unlocked 20160628170836877 DOML <0001> oml.c:249 OC=CHANNEL INST=(00,00,07) AVAIL STATE Dependency -> OK 20160628170836877 DOML <0001> oml.c:256 OC=CHANNEL INST=(00,00,07) OPER STATE Disabled -> Enabled 20160628170836877 DPCU <0009> pcu_sock.c:627 PCU socket not connected, dropping message 20160628170836877 DOML <0001> oml.c:217 OC=CHANNEL INST=(00,00,07) Tx STATE CHG REP 20160628170836984 DL1C <0006> scheduler_trx.c:1433 GSM clock skew: old fn=272611, new fn=272536 20160628170837632 DL1C <0006> scheduler.c:240 Prim for trx=0 ts=0 at fn=272652 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=272658) 20160628170840742 DPCU <0009> pcu_sock.c:824 PCU socket connected to external PCU 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PDTCH on trx=0 ts=5 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PTCCH on trx=0 ts=5 20160628170840743 DRSL <0000> rsl.c:579 (bts=0,trx=0,ts=5,ss=0) not sending CHAN ACT ACK 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PDTCH on trx=0 ts=6 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PTCCH on trx=0 ts=6 20160628170840743 DRSL <0000> rsl.c:579 (bts=0,trx=0,ts=6,ss=0) not sending CHAN ACT ACK 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PDTCH on trx=0 ts=7 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PTCCH on trx=0 ts=7 20160628170840743 DRSL <0000> rsl.c:579 (bts=0,trx=0,ts=7,ss=0) not sending CHAN ACT ACK 20160628170857756 DL1C <0006> scheduler_trx.c:907 Received incomplete PDTCH block ending at fn=276994 (42/104) for PDTCH 20160628170857756 DL1C <0006> scheduler_trx.c:921 Received bad PDTCH block ending at fn=276994 (42/104) for PDTCH 20160628170940774 DL1C <0006> scheduler_trx.c:907 Received incomplete PDTCH block ending at fn=286315 (3/104) for PDTCH 20160628170940775 DL1C <0006> scheduler_trx.c:921 Received bad PDTCH block ending at fn=286315 (3/104) for PDTCH 20160628170945250 DL1C <0006> scheduler_trx.c:907 Received incomplete PDTCH block ending at fn=287285 (37/104) for PDTCH 20160628170945250 DL1C <0006> scheduler_trx.c:921 Received bad PDTCH block ending at fn=287285 (37/104) for PDTCH -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

3 9

merging iu specific branches to master
by Neels Hofmeyr 09 Jul '16

09 Jul '16

Hi 3G folks, I would like to make our osmocom jenkins build openbsc with --enable-iu, which still requires use of non-master branches in aper-prefix, libosmo-sccp and libosmo-netif. I will at first make the jenkins build use these branches to build 3G, but since we'd like them to be merged to master anyway, let's try to push this forward. Here are the remaining tasks again, as from the openbsc@ mail on Feb 19, 2016: http://lists.osmocom.org/pipermail/openbsc/2016-February/007906.html ( <20160219083519.GA4570@nataraja> ) First the good news for libosmo-sccp: On Fri, Feb 19, 2016 at 09:35:19AM +0100, Harald Welte wrote: > > libosmo-sccp: * laforge/wip > > My main problem with this patch set is naming. We are creating an 'SCCP > User SAP' which should look the same no matter what the underlying > transport protocol stacking is. [...] This boils down to a mere rename of opaque structs osmo_sua_link and osmo_sua_user, which I've started to submit. https://gerrit.osmocom.org/477 > > asn1c: * aper-prefix First of all, it looks like we imported from svn, but Lev Walkin later did another migration to git, which we fetched as well. So our master is on our old svn import, while the upstream master has different hashes in its history. Our aper-prefix branch is based on the upstream history, not our "stale" master, which made a rebase a bit easier. Furthermore, on https://github.com/vlm/asn1c/commits/master there are scores of new commits we don't have in our asn1c. our last commit from Lev Walkin is from 2015-04-28, "?= was confusing some environments", 62913d8b8e1eb96d74315ff I have thus: * fetched upstream master from github's vlm/asn1c, pushed as new branch vlm/master to our git.osmocom.org/asn1c * rebased our aper-prefix branch to that master (with minor conflicts), pushed as new branch aper-prefix-onto-upstream We should probably: * reset --hard our master to vlm/master * reset --hard our aper-prefix to aper-prefix-onto-upstream (after testing) Agreed? Then follows: On Fri, Feb 19, 2016 at 09:35:19AM +0100, Harald Welte wrote: > > If you look at the aper code I took from OpenAirInterface and re-based, For the record: https://gitlab.eurecom.fr/oai/openair-cn/tree/master/SRC/S1AP/MESSAGES/ASN1 https://gitlab.eurecom.fr/oai/openair-cn/blob/master/SRC/S1AP/MESSAGES/ASN1… https://gitlab.eurecom.fr/oai/openair-cn/blob/master/SRC/S1AP/MESSAGES/ASN1… > you will see that it does not look 100% complete and would > probably not yet qualify for submitting it to the upstream asn1c > project. The situation is not made better by my hackish way to > implement the type prefixing on top of it by means of an environment > variable. > > Specifically, it > * contains commented-out code which might just have been a work-around > of some buggy code, rather than fit for removal in general > * contains TODO comments like "/* TODO: act upon NOTE in #18.7 for > canonical PER */" which hints that it is not properly implementing > parts of the PER specification > * contrary to the rest of asn1c, it does not come with a comprehensive > test suiet for the APER encoding and decoding routines of all types > > Any help in cleaning this code up (it could be done for the type > prefixing independent of the APER support) would be much appreciated. > The goal is to get this merged in asn1c, after all. > > It might also be worth to contact the OpenAirInterface guys about their > thoughts on moving this code forward. I fear there might be none, as > they are using an ancient version of asn1c to begin with. But they are > a much larger project and might be convinced to put some resources on > doing this properly? I've written to the openair-cn-devel list. https://lists.eurecom.fr/sympa/arc/openaircn-devel/2016-07/msg00001.html > Unless we think something is ready for pushing to upstream asn1c, we > should keep it out of our local master, too. > > libosmo-netif: * sysmocom/sctp > > commit d484b0593112222cef3f106da654df07c3d40919 (hash changed after rebases) > basically just > prints some messages to the log file in case there are association state > changes like UP and LOST. This is clearly not the intended behavior. > > The application should be notified accordintly in such events, > particularly in 'connection lost' events that can be communicated in the > same way as they can for e.g. TCP sockets. > > Only after that is resolved, we can merge it to master. This doesn't look like a lot of work, though I'm not familiar with how exactly this should be done. ret = sctp_recvmsg(conn->ofd.fd, msgb_data(msg), msgb_tailroom(msg), NULL, NULL, &sinfo, &flags); if (flags & MSG_NOTIFICATION) { union sctp_notification *notif = (union sctp_notification *) msgb_data(msg); LOGP(DLINP, LOGL_DEBUG, "NOTIFICATION %u flags=0x%x\n", notif->sn_header.sn_type, switch (notif->sn_header.sn_type) { case SCTP_ASSOC_CHANGE: LOGP(DLINP, LOGL_DEBUG, "===> ASSOC CHANGE:"); switch (notif->sn_assoc_change.sac_state) { case SCTP_COMM_UP: LOGPC(DLINP, LOGL_DEBUG, " UP\n"); call accept_cb? break; case SCTP_COMM_LOST: LOGPC(DLINP, LOGL_DEBUG, " LOST\n"); osmo_stream_srv_destroy() ? break; case SCTP_RESTART: LOGPC(DLINP, LOGL_DEBUG, " RESTART\n"); break; case SCTP_SHUTDOWN_COMP: LOGPC(DLINP, LOGL_DEBUG, " SHUTDOWN COMP\n"); break; case SCTP_CANT_STR_ASSOC: LOGPC(DLINP, LOGL_DEBUG, " CANT STR ASSOC\n"); break; } break; case SCTP_PEER_ADDR_CHANGE: LOGP(DLINP, LOGL_DEBUG, "===> PEER ADDR CHANGE\n"); break; case SCTP_SHUTDOWN_EVENT: LOGP(DLINP, LOGL_DEBUG, "===> SHUTDOWN EVT\n"); /* Handle this like a regular disconnect */ osmo_stream_srv_destroy() ? return 0; break; } return -EAGAIN; Thanks for any thoughts or even help :) ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

2 1

OsmoTRX / BER, RSSI and Link Quality
by Harald Welte 07 Jul '16

07 Jul '16

Hi Tom and List, we're currently introducing some code that will make more use of measurement related information associated with the PH-RACH.req and PH-DATA.ind coming from the PHY up into L2. The first part is to introduce a reasonable BER limit fo 17% for RACH ghost elimination, but I have more plans for unifying the measurement processing/generation accross all supported BTS models. For osmo-bts-{sysmo,lc15,octphy} it is clear to me how to get the related information on RSSI, BER and LinkQuality for each of the RACH and DATA indications from the PHY. However, how can I get the related information from osmo-bts-trx? osmo-bts-trx seems to lack any BER reporting toward the common part, which among other things is the reason why link/rate adaption in the PCU can not work with it. Could you sched some light on this? -- - 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)

3 4

[PATCH 0/2] osmo-trx: add .gitignore, add a configure check
by Neels Hofmeyr 06 Jul '16

06 Jul '16

From: Neels Hofmeyr <neels(a)hofmeyr.de> Rebased the patches onto updated master, added a binary to .gitignore. Neels Hofmeyr (2): add basic .gitignore configure.ac: check for boost/config.hpp header .gitignore | 44 ++++++++++++++++++++++++++++++++++++++++++++ configure.ac | 3 +++ 2 files changed, 47 insertions(+) create mode 100644 .gitignore -- 2.1.4

2 3

dynamic PDCH
by Neels Hofmeyr 06 Jul '16

06 Jul '16

> I am Tiger. Glad to connect with you.From osmo-bts commitment I see you are > working on dynamic PDCH which I think is a breakthrough. Is it working now? > It looks like only support PDCH and Full TCH switch,right? Hi Tiger, thanks for your comments and enquiry! I am still working on TCH/F <-> PDCH switching for the osmo-bts-trx SDR platform, but for ip.access nanobts, SysmoBTS and the litecell15, dynamic TCH/F <-> PDCH switching is already functional. TCH/F <-> PDCH could be called the ip.access compatibility mode, as it uses ip.access vendor specific messages to activate and deactivate PDCH on a TCH/F_PDCH timeslot. There are plans to include TCH/H as well, using a different vendor specific extension. Though development has not commenced yet, which will depend on funding by interested parties. See: http://osmocom.org/issues/1565 http://osmocom.org/issues/1757 BTW, Tiger, you have contacted my private email address. Instead, I'm replying from my sysmocom address, Bcc to you and copying to our mailing list, which would be the most appropriate place for questions on osmocom development. ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC