Hello everyone!
Right now I am moving some code from OsmoBTS to libosmocore,
exactly OsmoBTS/src/osmo-bts-trx/gsm0503*. And there is a
licensing conflict, because this code licensed under AGPLv3+,
but libosmocore code is GPLv2+.
So, this is why I am contacting all authors/copyright holders.
The question is: does everyone agree to re-license the code
under GPLv2-or-later and move it code to libosmocore?
Thanks in advance!
With best regards,
Vadim Yanitskiy.
Hello All,
We are trying to bring up osmo-trx setup in Ettus USRP B200 Board for Testing CS and PS call . When we tried to do the initial Registration for UE it is failing.
Could you please help to point out what could be the issue and how to resolve this.
Please find below the observation and log snippet for reference:
After MS power Up Network is getting detected on the MS , Rach is received at BTS , Channel Activation is successful at A-bis interface and later Immediate Assignment is seen in the log.
After Immediate assignment no further message is observed in Uplink/Downlink and later BSC is releasing the SDCCH/SACCH channel as observed from the log.
BTS LOG Snippet:
OsmoBTS# <0000> rsl.c:2209 (bts=0,trx=0,ts=0,ss=4) Fwd RLL msg CHAN_RQD from LAPDm to A-bis
<0000> rsl.c:2290 (bts=0,trx=0,ts=0,ss=0) Rx RSL CHAN_ACTIV
<0000> rsl.c:926 chan_nr=0x20 type=0x00 mode=0x00
<0006> scheduler.c:1344 Activating SDCCH/4(0) on trx=0 ts=0
<0006> scheduler.c:1344 Activating SACCH/4(0) on trx=0 ts=0
<0006> scheduler.c:1393 Set mode 3, 0, handover 0 on SDCCH/4(0) of trx=0 ts=0
<0006> scheduler.c:1458 Set a5/0 uplink for SDCCH/4(0) on trx=0 ts=0
<0006> scheduler.c:1458 Set a5/0 uplink for SACCH/4(0) on trx=0 ts=0
<0006> scheduler.c:1458 Set a5/0 downlink for SDCCH/4(0) on trx=0 ts=0
<0006> scheduler.c:1458 Set a5/0 downlink for SACCH/4(0) on trx=0 ts=0
<0000> rsl.c:559 (bts=0,trx=0,ts=0,ss=0) Tx CHAN ACT ACK
<000b> trx_if.c:485 Tx burst length 0 invalid
<0000> rsl.c:2236 (bts=0,trx=0,ts=0,ss=0) Rx RSL IMM_ASS_CMD
<000b> trx_if.c:485 Tx burst length 0 invalid
<000b> trx_if.c:485 Tx burst length 0 invalid
<000b> trx_if.c:485 Tx burst length 0 invalid
<0006> scheduler_trx.c:867 Received incomplete data frame at fn=0 (0/102) for SDCCH/4(0)
<0006> scheduler_trx.c:867 Received incomplete data frame at fn=0 (0/102) for SACCH/4(0)
<0000> rsl.c:2290 (bts=0,trx=0,ts=0,ss=0) Rx RSL DEACTIVATE_SACCH
<0006> scheduler.c:1344 Deactivating SACCH/4(0) on trx=0 ts=0
<0000> rsl.c:2290 (bts=0,trx=0,ts=0,ss=0) Rx RSL RF_CHAN_REL
<0006> scheduler.c:1344 Deactivating SDCCH/4(0) on trx=0 ts=0
<0000> rsl.c:519 (bts=0,trx=0,ts=0,ss=0) Tx RF CHAN REL ACK
<0006> scheduler_trx.c:867 Received incomplete data frame at fn=1421484 (12/104) for PTCCH
<0006> scheduler_trx.c:867 Received incomplete data frame at fn=1421484 (12/104) for PTCCH
<0000> rsl.c:2209 (bts=0,trx=0,ts=0,ss=4) Fwd RLL msg CHAN_RQD from LAPDm to A-bis
<0000> rsl.c:2290 (bts=0,trx=0,ts=2,ss=0) Rx RSL CHAN_ACTIV
<0000> rsl.c:926 chan_nr=0x0a type=0x00 mode=0x00
<0006> scheduler.c:1344 Activating TCH/F on trx=0 ts=2
<0006> scheduler.c:1344 Activating SACCH/TF on trx=0 ts=2
<0006> scheduler.c:1393 Set mode 3, 0, handover 0 on TCH/F of trx=0 ts=2
<0006> scheduler.c:1393 Set mode 3, 0, handover 0 on PDTCH of trx=0 ts=2
<0006> scheduler.c:1393 Set mode 3, 0, handover 0 on PTCCH of trx=0 ts=2
<0006> scheduler.c:1458 Set a5/0 uplink for TCH/F on trx=0 ts=2
<0006> scheduler.c:1458 Set a5/0 uplink for SACCH/TF on trx=0 ts=2
<0006> scheduler.c:1458 Set a5/0 downlink for TCH/F on trx=0 ts=2
<0006> scheduler.c:1458 Set a5/0 downlink for SACCH/TF on trx=0 ts=2
<0000> rsl.c:559 (bts=0,trx=0,ts=2,ss=0) Tx CHAN ACT ACK
<0000> rsl.c:2236 (bts=0,trx=0,ts=0,ss=0) Rx RSL IMM_ASS_CMD
<0006> scheduler.c:267 Prim for trx=0 ts=2 at fn=1085114 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=1436721)
<0006> scheduler_trx.c:1054 Received incomplete TCH frame ending at fn=1436997 (29/104) for TCH/F
<0006> gsm0503_coding.c:1690 tch_fr_decode(): error decoding FACCH frame (399/456 bits)
<0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1436997 for TCH/F
<0006> gsm0503_coding.c:1690 tch_fr_decode(): error decoding FACCH frame (286/456 bits)
<0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1437213 for TCH/F
<0006> gsm0503_coding.c:1706 tch_fr_decode(): error checking CRC8 for the FR part of an FR frame
<0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1438301 for TCH/F
<0006> scheduler_trx.c:1054 Received incomplete TCH frame ending at fn=1438522 (98/104) for TCH/F
<0006> gsm0503_coding.c:1690 tch_fr_decode(): error decoding FACCH frame (159/456 bits)
<0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1438522 for TCH/F
<0006> scheduler_trx.c:1054 Received incomplete TCH frame ending at fn=1438652 (20/104) for TCH/F
<0006> gsm0503_coding.c:1706 tch_fr_decode(): error checking CRC8 for the FR part of an FR frame
<0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1438652 for TCH/F
<0000> rsl.c:2290 (bts=0,trx=0,ts=2,ss=0) Rx RSL DEACTIVATE_SACCH
<0006> scheduler.c:1344 Deactivating SACCH/TF on trx=0 ts=2
<0000> rsl.c:2290 (bts=0,trx=0,ts=2,ss=0) Rx RSL RF_CHAN_REL
<0006> scheduler.c:1344 Deactivating TCH/F on trx=0 ts=2
<0000> rsl.c:519 (bts=0,trx=0,ts=2,ss=0) Tx RF CHAN REL ACK
<0006> scheduler_trx.c:867 Received incomplete data frame at fn=1462772 (12/104) for PTCCH
BSC log Snippet :
OpenBSC# <0000> chan_alloc.c:342 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH
<0004> abis_rsl.c:1727 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(990) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0d ta=0
<0004> abis_rsl.c:536 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL
<0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED
<0004> abis_rsl.c:1456 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK
<0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE
<0004> abis_rsl.c:806 (bts=0,trx=0,ts=0,ss=0) RF Channel Release CMD due error 1
<0004> abis_rsl.c:718 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD
<0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR
<0004> abis_rsl.c:863 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK
<0004> abis_rsl.c:767 (bts=0,trx=0,ts=0,ss=0) is back in operation.
<0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE
<0000> chan_alloc.c:342 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH
<0004> abis_rsl.c:1727 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(990) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0b ta=0
<0004> abis_rsl.c:536 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL
<0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED
<0004> abis_rsl.c:1456 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK
<0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE
<0004> abis_rsl.c:806 (bts=0,trx=0,ts=0,ss=0) RF Channel Release CMD due error 1
<0004> abis_rsl.c:718 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD
<0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR
<0004> abis_rsl.c:863 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK
<0004> abis_rsl.c:767 (bts=0,trx=0,ts=0,ss=0) is back in operation.
<0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE
<0000> chan_alloc.c:342 (bts=0,trx=0,ts=2,pchan=TCH/F) Allocating lchan=0 as TCH_F
<0004> abis_rsl.c:1727 (bts=0,trx=0,ts=2,ss=0) Activating ARFCN(990) SS(0) lctype TCH_F r=OTHER ra=0xe7 ta=0
<0004> abis_rsl.c:536 (bts=0,trx=0,ts=2,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL
<0004> abis_rsl.c:1127 (bts=0,trx=0,ts=2,ss=0) state NONE -> ACTIVATION REQUESTED
<0004> abis_rsl.c:1456 (bts=0,trx=0,ts=2,ss=0) CHANNEL ACTIVATE ACK
<0004> abis_rsl.c:1127 (bts=0,trx=0,ts=2,ss=0) state ACTIVATION REQUESTED -> ACTIVE
<0004> abis_rsl.c:806 (bts=0,trx=0,ts=2,ss=0) RF Channel Release CMD due error 1
<0004> abis_rsl.c:718 (bts=0,trx=0,ts=2,ss=0) DEACTivate SACCH CMD
<0004> abis_rsl.c:1127 (bts=0,trx=0,ts=2,ss=0) state ACTIVE -> RELEASE DUE ERROR
<0004> abis_rsl.c:863 (bts=0,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK
<0004> abis_rsl.c:767 (bts=0,trx=0,ts=2,ss=0) is back in operation.
<0004> abis_rsl.c:1127 (bts=0,trx=0,ts=2,ss=0) state RELEASE DUE ERROR -> NONE
Note : We are using internal clock of osmo-trx no external Clock is connected.
Thanks and Regards,
Mrinal
On Tue, Sep 13, 2016 at 04:39:38PM +0000, Max wrote:
> To view, visit https://gerrit.osmocom.org/815
>
> This is revert of 8c119f7a0510b75e7fa1b96a37f2a6650e13824f - would be better if it were marked as such.
whoa, I wasn't aware of this. It is a patch from the Quickstart Guide for the
new litecell15 board.
Well, since it's already merged, I guess we won't mark it as a revert then,
sorry about that.
I've also posted a comment at OS#1661
https://osmocom.org/issues/1661
~Neels
Hi All,
2 (related) questions in 1 thread here:
I'm looking at Chapter 10.5.1.7 of GSM 04.08, also Figure 10.5.7 there,
but I am not quite getting how to interpret it in relation to either
openBSC log output such as:
<000d> db.c:1130 Sync Equipment IMEI=357371048322730, classmark1=33,
classmark2=33 18 82 , classmark3=00 08 00 52 20 00 00 4b
or equally:
root@bsc:~# echo "SELECT classmark1 FROM Equipment where id='505';" |
sqlite3 /var/lib/osmocom/hlr.sqlite3 | xxd
0000000: 3531 0a 51.
root@bsc:~# echo "SELECT classmark2 FROM Equipment where id='505';" |
sqlite3 /var/lib/osmocom/hlr.sqlite3 | xxd
0000000: 0132 1781 0a .2...
root@bsc:~# echo "SELECT classmark3 FROM Equipment where id='505';" |
sqlite3 /var/lib/osmocom/hlr.sqlite3 | xxd
0000000: 01ff 07ff 511f ffff 4a0a ....Q...J.
Specifically, in this case, not having the mathematical theory, I don't
understand how to map
01ff 07ff 511f ffff 4a0a to 00 08 00 52 20 00 00 4b
It doesn't /quite/ match, but more importantly mapping to Classmark 3
Value Part
Could you help me understand how to map 01ff 07ff 511f ffff 4a0a to
Figure 10.5.7
BTW, I get that the BLOBs in sqlite are somehow encoded, (if that is not
completely the wrong term to use) as hex_value-1, I've also noted this
in the SMS table when trying to identify an sms in the sms_queue. So
question part 2: what is that about?
Is there an easy way I could "decode" on the command line, as in:
echo "SELECT user_data FROM sms limit 1;" | sqlite3
/var/lib/osmocom/hlr.sqlite3 | some magic to display readable SMS content
Any tips?
Thanks!
When updating https://osmocom.org/projects/cellular-infrastructure/wiki/PortNumbers
I noticed that 4252 is used both for OpenGGSN Ctrl as well as sysmobts-mgr VTY.
Should we do something about that?
Technically, we have VTY commands available to redirect the vty bind port, but
sysmobts-mgr does not heed that VTY command yet.
Related: https://gerrit.osmocom.org/754
~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
Yesterday we had problems building the current osmo-bts-octphy with the current
octphy-2g-headers. To resolve, we've reverted two commits and added a change in
osmo-bts.
(1)
osmo-bts included a struct member not present anywhere in octphy-2g-headers.
https://gerrit.osmocom.org/820https://gerrit.osmocom.org/821
On our test setup at sysmocom, I found a version of the headers called
OCTSDR-2G-02.05.00-B780-DEBUG that includes this struct member, but those
headers have proprietary licensing. Also, the current version apparently is
2.07, while the one with the unknown struct header seems to be older: 2.05. So
it looks like the usCentreArfcn item has been removed in a newer version, even
though it looks really useful to me.
It would be good to resolve this confusion, probably as soon as Max is back
from vacation (Max is the author of the reverted commits).
(2)
In the most recent version, a #define naming has changed.
In https://gerrit.osmocom.org/822 Holger asks:
> Do we have any precedence of using #if for version checks? You can
> use #ifdef for both of them to support old and new headers?
We could use a check like
#if cOCTVC1_HW_VERSION_MAJOR <=2 && cOCTVC1_HW_VERSION_MINOR < 7
[...]_IDLE[...]
#else
[...]_UNUSED[...]
#endif
but I doubt that we will want to go back to old headers.
If I'm the only one in doubt, we'd have a check like above in three places in
osmo-bts.
Thanks for your opinions,
~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
Dear all,
We recently discussed with Harald, that there is a lot of code related to
GSM L1 should be migrated from OsmoBTS to libosmogsm. The reason is that
it would be better to have one shared implementation of the convolutional
codes, mapping, interleaving, etc., because then in near future it can be
used not only from OsmoBTS, but also from OsmocomBB and even from foreign
projects, such as GR-GSM.
I just started to work on this direction, and found that there is already
some code, related to the conventional codes, in libosmogsm. But unlike
OsmoBTS, where all the tables can be found within the single file named
'gsm0503_conv.c', these tables appears in separate files during building
process. So, I have several questions:
1) Which approach is better to use? To store everything in a single file
or to use auto generation (utils/conv_gen.py)?
2) What about the copyright? I have not seen any license/author info at
the top pf these files. Who is the author?
Also, there is the 'gsm0503_coding.c' file, which uses the following
external dependences:
* The DL1C logging category, which isn't defined in libosmocore;
* The 'osmo-bts/gsm_data.h', which includes 'openbsc/gsm_data_shared.h'
as well.
So, there is regarding questions:
3) Which logging category it would be better to use after migration?
4) What to do with the 'osmo-bts/gsm_data.h'?
5) I don't think, that it's a good way to require something from the
OpenBSC sources during OsmoBTS build... How can we change it?
With best regards,
Vadim Yanitskiy.