I have now built osmo-trx-lms and osmo-bts-trx from source on an i386
platform.
I have beacon, and two phones registered, the configuration from msc and
up is the one
I had three weeks ago, which more or less worked, but with large
stability problems.
I guess *this* report is the most interesting for you now....
I build from the "master", and target debian9 on i386.
I have not been able to make a call yet, possibly because I might have
messed up some
library the MSC is dependent on, but I will work on that.
What is interesting is that bts 0 trx 0 is running trx-uhd with a B100,
and seems quite stable.
Moreover, bts 1 trx 0 is running on the i386 and seems happy so far,
after 30 minutes.
This is Limesdr mini.
I have just copied the bts0 to trx 0 section from my original config,
duplicated it and changed
bts0 to bts1, and the ipa unit-id 1805 0, and of course the ip addresses.
I will comment the various lines in my configs, as I have understood
them, and look forward to your
comments, or maybe a keyword list explaining what each parameter is used
for.
! osmo-bsc default configuration
! (assumes STP to run on 127.0.0.1 and uses default point codes)
!
e1_input
e1_line 0 driver ipa
network
network country code 1
mobile network code 1
encryption a5 0
neci 1
paging any use tch 0
handover 0
handover algorithm 1
handover1 window rxlev averaging 10
handover1 window rxqual averaging 1
handover1 window rxlev neighbor averaging 10
handover1 power budget interval 6
handover1 power budget hysteresis 3
handover1 maximum distance 9999
dyn_ts_allow_tch_f 0
periodic location update 30
! here is the first bts - trx section. The ip.access id must match the
one in the BTS, where it is called ipa.
bts 0
type sysmobts
band DCS1800
cell_identity 0
location_area_code 1
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
radio-link-timeout 32
channel allocator ascending
rach tx integer 9
rach max transmission 7
channel-descrption attach 1
channel-descrption bs-pa-mfrms 5
channel-descrption bs-ag-blks-res 1
early-classmark-sending forbidden
ip.access unit_id 1801 0
oml ip.access stream_id 255 line 0
codec-support fr
gprs mode none
trx 0
rf_locked 0
arfcn 871
nominal power 20
! to use full TRX power, set max_power_red 0
max_power_red 3
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
timeslot 1
phys_chan_config TCH/F
hopping enabled 0
timeslot 2
phys_chan_config TCH/F
hopping enabled 0
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
timeslot 4
phys_chan_config TCH/F
hopping enabled 0
timeslot 5
phys_chan_config TCH/F
hopping enabled 0
timeslot 6
phys_chan_config TCH/F
hopping enabled 0
timeslot 7
phys_chan_config TCH/F
hopping enabled 0
! this is BTS1. The
! osmo-bsc default configuration
! (assumes STP to run on 127.0.0.1 and uses default point codes)
!
e1_input
e1_line 0 driver ipa
network
network country code 1
mobile network code 1
encryption a5 0
neci 1
paging any use tch 0
handover 0
handover algorithm 1
handover1 window rxlev averaging 10
handover1 window rxqual averaging 1
handover1 window rxlev neighbor averaging 10
handover1 power budget interval 6
handover1 power budget hysteresis 3
handover1 maximum distance 9999
dyn_ts_allow_tch_f 0
periodic location update 30
*bts 0**
*** type sysmobts
band DCS1800
cell_identity 0
location_area_code 1
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
radio-link-timeout 32
channel allocator ascending
rach tx integer 9
rach max transmission 7
channel-descrption attach 1
channel-descrption bs-pa-mfrms 5
channel-descrption bs-ag-blks-res 1
early-classmark-sending forbidden
* ip.access unit_id 1801 0**
* oml ip.access stream_id 255 line 0
codec-support fr
gprs mode none
trx 0
rf_locked 0
* arfcn 871**
* nominal power 20
! to use full TRX power, set max_power_red 0
max_power_red 3
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
timeslot 1
phys_chan_config TCH/F
hopping enabled 0
timeslot 2
phys_chan_config TCH/F
hopping enabled 0
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
timeslot 4
phys_chan_config TCH/F
hopping enabled 0
timeslot 5
phys_chan_config TCH/F
hopping enabled 0
timeslot 6
phys_chan_config TCH/F
hopping enabled 0
timeslot 7
phys_chan_config TCH/F
hopping enabled 0
*bts 1**
*** type sysmobts
band DCS1800
cell_identity 0
location_area_code 1
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
radio-link-timeout 32
channel allocator ascending
rach tx integer 9
rach max transmission 7
channel-descrption attach 1
channel-descrption bs-pa-mfrms 5
channel-descrption bs-ag-blks-res 1
early-classmark-sending forbidden
* ip.access unit_id 1805 0**
* oml ip.access stream_id 255 line 0
codec-support fr
gprs mode none
trx 0
rf_locked 0
* arfcn 881**
* nominal power 20
! to use full TRX power, set max_power_red 0
max_power_red 3
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
timeslot 1
phys_chan_config TCH/F
hopping enabled 0
timeslot 2
phys_chan_config TCH/F
hopping enabled 0
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
timeslot 4
phys_chan_config TCH/F
hopping enabled 0
timeslot 5
phys_chan_config TCH/F
hopping enabled 0
timeslot 6
phys_chan_config TCH/F
hopping enabled 0
timeslot 7
phys_chan_config TCH/F
hopping enabled 0
msc 0
no bsc-welcome-text
no bsc-msc-lost-text
no bsc-grace-text
type normal
allow-emergency allow
amr-config 12_2k forbidden
amr-config 10_2k forbidden
amr-config 7_95k forbidden
amr-config 7_40k forbidden
amr-config 6_70k forbidden
amr-config 5_90k allowed
amr-config 5_15k forbidden
amr-config 4_75k forbidden
codec-list fr1 fr2 fr3 hr1 hr3
mgw remote-ip 127.0.0.1
mgw remote-port 2427
mgw local-port 2727
mgw endpoint-range 1 31
bsc
mid-call-timeout 0
no missing-msc-text
Does this look OK to you??
Regards,
Gullik
Hi,
I have just received a limesdr mini, and I am trying to get that sdr to
the same level as I had with
uhd B100. I managed to get the whole config working properly, but
stability was bad, as you have read.
As I was recommended, I have been runnig "nightly" binaries, and see
where I end up.... :-)
limesdr installed in Orange Pi Zero, (armhf). Limesuite 18.10.0-1,
LimeUtil seems happy, and I can see the SDR
However, I cannot get stability enough to get a stable signal....
Gullik
TRX LIME CONFIG
log stderr
logging filter all 1
logging color 1
logging print category 1
logging timestamp 1
logging print file basename
logging level set-all info
!
line vty
no login
!
trx
bind-ip 127.0.0.1
remote-ip 127.0.0.1
base-port 5700
egprs disable
tx-sps 4
rx-sps 4
rt-prio 18
chan 0
tx-path BAND1
rx-path LNAW
bsc 1.3.0.287 or .284 will not run, fails with error in sysmalloc(), so
I try running .283, from dec 19....
maybe this problem is armhf related...??
this is the bsc config......
osmobsc config file
! osmo-bsc default configuration
! (assumes STP to run on 127.0.0.1 and uses default point codes)
!
e1_input
e1_line 0 driver ipa
network
network country code 1
mobile network code 1
encryption a5 0
neci 1
paging any use tch 0
handover 0
handover algorithm 1
handover1 window rxlev averaging 10
handover1 window rxqual averaging 1
handover1 window rxlev neighbor averaging 10
handover1 power budget interval 6
handover1 power budget hysteresis 3
handover1 maximum distance 9999
dyn_ts_allow_tch_f 0
periodic location update 30
bts 0
type sysmobts
band DCS1800
cell_identity 0
location_area_code 1
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
radio-link-timeout 32
channel allocator ascending
rach tx integer 9
rach max transmission 7
channel-descrption attach 1
channel-descrption bs-pa-mfrms 5
channel-descrption bs-ag-blks-res 1
early-classmark-sending forbidden
ip.access unit_id 1801 0
oml ip.access stream_id 255 line 0
codec-support fr
gprs mode none
trx 0
rf_locked 0
arfcn 871
nominal power 20
! to use full TRX power, set max_power_red 0
max_power_red 3
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
timeslot 1
phys_chan_config TCH/F
hopping enabled 0
timeslot 2
phys_chan_config TCH/F
hopping enabled 0
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
timeslot 4
phys_chan_config TCH/F
hopping enabled 0
timeslot 5
phys_chan_config TCH/F
hopping enabled 0
timeslot 6
phys_chan_config TCH/F
hopping enabled 0
timeslot 7
phys_chan_config TCH/F
hopping enabled 0
msc 0
no bsc-welcome-text
no bsc-msc-lost-text
no bsc-grace-text
type normal
allow-emergency allow
amr-config 12_2k forbidden
amr-config 10_2k forbidden
amr-config 7_95k forbidden
amr-config 7_40k forbidden
amr-config 6_70k forbidden
amr-config 5_90k allowed
amr-config 5_15k forbidden
amr-config 4_75k forbidden
codec-list fr1 fr2 fr3 hr1 hr3
mgw remote-ip 127.0.0.1
mgw remote-port 2427
mgw local-port 2727
mgw endpoint-range 1 31
bsc
mid-call-timeout 0
no missing-msc-text
bsc does not seem to want to speak with trx-lms, I don't understand
which config entry is wrong....
osmo_bsc_main.c:284 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 871
using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63
<0007> a_reset.c:106 A-RESET(msc-0)[0xdb2e98]{DISC}: (re)sending BSSMAP
RESET message...
<0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC:
RI=SSN_PC,PC=0.23.1,SSN=BSSAP
<0007> osmo_bsc_bssap.c:58 RESET ACK from MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP
<0007> a_reset.c:74 A-RESET(msc-0)[0xdb2e98]{DISC}: SIGTRAN connection
succeded.
<0011> bts_ipaccess_nanobts.c:315
timeslot(0-0-0-CCCH_SDCCH4)[0xddfcd8]{UNUSED}: Event TS_EV_OML_READY not
permitted
<0011> bts_ipaccess_nanobts.c:315
timeslot(0-0-1-TCH_F)[0xde0038]{UNUSED}: Event TS_EV_OML_READY not permitted
<0011> bts_ipaccess_nanobts.c:315
timeslot(0-0-2-TCH_F)[0xde0398]{UNUSED}: Event TS_EV_OML_READY not permitted
<0011> bts_ipaccess_nanobts.c:315
timeslot(0-0-3-TCH_F)[0xde06f8]{UNUSED}: Event TS_EV_OML_READY not permitted
<0011> bts_ipaccess_nanobts.c:315
timeslot(0-0-4-TCH_F)[0xde0a58]{UNUSED}: Event TS_EV_OML_READY not permitted
<0011> bts_ipaccess_nanobts.c:315
timeslot(0-0-5-TCH_F)[0xde0db8]{UNUSED}: Event TS_EV_OML_READY not permitted
<0011> bts_ipaccess_nanobts.c:315
timeslot(0-0-6-TCH_F)[0xde1118]{UNUSED}: Event TS_EV_OML_READY not permitted
<0011> bts_ipaccess_nanobts.c:315
timeslot(0-0-7-TCH_F)[0xde1478]{UNUSED}: Event TS_EV_OML_READY not permitted
<0015> input/ipaccess.c:248 Sign link vanished, dead socket
<0015> input/ipaccess.c:74 Forcing socket shutdown with no signal link set
<0015> bts_ipaccess_nanobts.c:416 (bts=0) Dropping OML link.
<0015> bts_ipaccess_nanobts.c:397 (bts=0,trx=0) Dropping RSL link.
<0015> input/ipa.c:262 accept()ed new link from 127.0.0.1 to port 3002
<0004> abis_nm.c:538 BTS0 feature 'EGPRS' reported via OML does not
match statically set feature: 0 != 1. Please fix.
<0004> abis_nm.c:538 BTS0 feature 'OML Alerts' reported via OML does not
match statically set feature: 1 != 0. Please fix.
So, has anyone config files for Limesdr mini -> trx-lms ->
osmo-bts-trx_0.8.1.199 -> osmo-msc or can point me in the
right direction....
Gullik
Researching for a discussion at https://gerrit.osmocom.org/c/libosmocore/+/12384
made me realize that our use of doxygen keywords is currently confused.
TLDR:
- Links to structs, members and functions are implicit in doxygen.
- Don't use '\ref', except to link to sections or files.
- Don't use '\a', it is merely cosmetic and breaks reading flow for some.
Details:
(*) We are often using '\ref' wrongly, and also '\a' is merely cosmetic.
Example:
osmo_crc16(), see param 'len' intending to reference the 'buffer' param:
/*! Compute 16bit CCITT polynome 0x8408 (x^0 + x^5 + x^12) over given buffer.
* \param crc[in] previous CRC value
* \param buffer[in] data pointer
* \param len[in] number of bytes in input \ref buffer
* \return updated CRC value
*/
uint16_t osmo_crc16(uint16_t crc, uint8_t const *buffer, size_t len)
...
It looks perfectly sane, but this is wrong for more than one reason:
- '\ref' is not actually about code elements. It is about referencing pages or
code sections. See http://www.doxygen.nl/manual/commands.html#cmdref
"Creates a reference to a named section, subsection, page or anchor."
Doxygen complains with e.g.:
"gsmtap_util.c:192: warning: unable to resolve reference to `data' for \ref command"
Luckily '\ref' doesn't break implicit linking, which is probably why the
misconception that we need to include them arose in the first place.
- There *AREN'T* any references to function arguments at all!!
It is not possible in doxygen to create a formal link to a function argument.
You can reference struct members, functions, ... but not arguments.
API code often uses '\a' (at least 320 times in libosmocore), but that does not
add a formal link, either. '\a' is only and simply putting a term in italics.
http://www.doxygen.nl/manual/commands.html#cmda
There are currently at least 260 uses of '\ref' in libosmocore, of which only a
few are correct. An example of correct use is gsmtap_source_init():
http://ftp.osmocom.org/api/latest/libosmocore/core/html/group__gsmtap.html#…
/*! [...] integrated with libosmocore \ref select */
which renders as
integrated with libosmocore [Select loop abstraction]
Ironically, the same gsmtap_source_init() also includes examples of incorrect
use, ignore those for this argument, please.
(*) Hyperlinks are fully automatic and implicit.
Notice that formal links are detected automatically, without the need for an
explicit doxygen marker. For example, look at the API doc for osmo_cgi_name2():
http://ftp.osmocom.org/api/latest/libosmocore/gsm/html/gsm23003_8c.html#af9…
It has a link to osmo_cgi_name(), with a doxygen source of
/*! Same as osmo_cgi_name(), but uses a different static buffer. [...]
I will hence continue to omit '\a' and '\ref', and will actually ask patch
submitters to omit them in code review.
~N
Hello Everyone
I was trying to set priority bit in paging type 1. I tried modifying the function rsl_paging_cmd in abis_rsl.c . But when i am checking the same in wireshark, I couldn't view it. Any help on this.
BR
All,
I have the following error when I run pySim-read.py:
Traceback (most recent call last):
File "pySim-read.py", line 86, in <module>
sl = SerialSimLink(device=opts.device, baudrate=opts.baudrate)
File "/home/macbook/Desktop/pyscard-1.9.7/pysim/pySim/transport/serial.py",
line 45, in __init__
baudrate = baudrate,
File "/home/macbook/.local/lib/python2.7/site-packages/serial/serialutil.py",
line 240, in __init__
self.open()
File "/home/macbook/.local/lib/python2.7/site-packages/serial/serialposix.py",
line 268, in open
raise SerialException(msg.errno, "could not open port {}:
{}".format(self._port, msg))
serial.serialutil.SerialException: [Errno 2] could not open port
/dev/ttyUSB0: [Errno 2] No such file or directory: '/dev/ttyUSB0'
Exception AttributeError: "'SerialSimLink' object has no attribute
'_sl'" in <bound method SerialSimLink.__del__ of
<pySim.transport.serial.SerialSimLink object at 0x7ff879094d10>>
ignored
I'm no Linux and/or Python guru but from what I can gather is that
it's having issues with identifying the card reader on dev/ttyUSB0.
To address that issue, I've confirmed my current card reader (identiv
SCR3310) is working when I've ran the pcsc_scan script:
PC/SC device scanner
V 1.5.2 (c) 2001-2017, Ludovic Rousseau <ludovic.rousseau(a)free.fr>
Using reader plug'n play mechanism
Scanning present readers...
0: SCR3310 Smart Card Reader [CCID Interface] (53311828708432) 00 00
Wed Jan 2 12:02:36 2019
Reader 0: SCR3310 Smart Card Reader [CCID Interface] (53311828708432) 00 00
Card state: Card inserted,
ATR: 3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8
ATR: 3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8
+ TS = 3B --> Direct Convention
+ T0 = 9F, Y(1): 1001, K: 15 (historical bytes)
TA(1) = 95 --> Fi=512, Di=16, 32 cycles/ETU
125000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 156250 bits/s
TD(1) = 80 --> Y(i+1) = 1000, Protocol T = 0
-----
TD(2) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface
bytes following
-----
TA(3) = C3 --> Clock stop: no preference - Class accepted by the
card: (3G) A 5V B 3V
+ Historical bytes: 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18
Category indicator byte: 80 (compact TLV data object)
Tag: 3, len: 1 (card service data byte)
Card service data byte: E0
- Application selection: by full DF name
- Application selection: by partial DF name
- BER-TLV data objects available in EF.DIR
- EF.DIR and EF.ATR access services: by GET RECORD(s) command
- Card with MF
Tag: 7, len: 3 (card capabilities)
Selection methods: FE
- DF selection by full DF name
- DF selection by partial DF name
- DF selection by path
- DF selection by file identifier
- Implicit DF selection
- Short EF identifier supported
- Record number supported
Data coding byte: 21
- Behaviour of write functions: proprietary
- Value 'FF' for the first byte of BER-TLV tag fields: invalid
- Data unit in quartets: 2
Command chaining, length fields and logical channels: 13
- Logical channel number assignment: by the card
- Maximum number of logical channels: 4
Tag: 5, len: 7 (card issuer's data)
Card issuer data: 86 81 02 86 98 44 18
+ TCK = A8 (correct checksum)
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B 9F 95 80 1F C3 80 31 E0 73 FE 21 13 57 86 81 02 86 98 44 18 A8
GREEN CARD, Grcard (Hong Kong ) Co.,Limited, LTE Usim Card (Telecommunication)
Celcom Postpaid 3G (Telecommunication)
Additionally, I've ran the following command (dmesg | tail -6) to
determine what path my card reader is mounted to:
macbook@ubuntu:~/Desktop/pyscard-1.9.7/pysim$ dmesg | tail -n 6
[ 7079.120203] usb 3-3.1: new full-speed USB device number 6 using xhci_hcd
[ 7079.223962] usb 3-3.1: New USB device found, idVendor=04e6, idProduct=5116
[ 7079.223965] usb 3-3.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=5
[ 7079.223968] usb 3-3.1: Product: SCR33xx v2.0 USB SC Reader
[ 7079.223969] usb 3-3.1: Manufacturer: Identive
[ 7079.223971] usb 3-3.1: SerialNumber: 53311828708432
My questions are this, is there a known work around for this errors
that I've posted above? Also, if my card is not mounting to
dev/ttyUSB0, where do they mount to? I've looked in /mnt, /media as
well as /dev....no joy. I've searched the Open BSC archives as well
as scoured the web for an answer to this issue and I'm coming up
blank. One last thing, I've ran this python script on an Ubuntu VM
and Dual Boot. Same issue both machines. I've also tried this script
with an Alcor card reader. Same output. Any help is greatly
appreciated.
Thanks,
Derek
Hi all,
my current task is implementing inter-MSC Handover for OsmoMSC.
It would be immensely helpful to look at network traces of the messages
carrying out an inter-MSC handover. Primarily for 2G (BSSAP), but 3G (RANAP)
might also be interesting.
The part on the A-interface (BSSAP) is interesting for both the outgoing (orig.
MSC and BSS) as well as the incoming (remote MSC and BSS) sides.
Most interesting would be some kind of trace of communication between the two
MSCs, the E-interface (MAP) negotiating the HO as well as the call forwarding
between the two MSCs, if at all available.
We are exploring various avenues to obtain inter-MSC HO traces, so far to no
avail. If anyone reading this is able to help out, that would be highly
appreciated and super helpful to be interoperable.
Thanks!
~N
--
- 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
Hi all.
1) SIP Connector handling of TON GSM340_TYPE_INTERNATIONAL
Apparently at least one person was frustrated at the congress by not
being able to call out using the numbers stored in their GSM handset
using the form +CountryCode.
As we know this appears at Call Control with TON intl, which sip
connector then prefixes with '+' before sending to SIP
The reason for lack of service at ccc was that the Yate pbx does not
support this number scheme and needed the 00 prefix. This would have
been trivial to patch had we known, and it prompts me to think this
should probably be implemented as a runtime config option in sip section
'tonintl prefix' or some such? It would seem correct for it to be
restricted to the set of either '00' or '+', no other options really
makes sense, not even "no prefix". right?
2) 3G data instabilities
( Just a quick observation note, no pcap! )
I happened to notice that pinging a 3G handset from the network side
(default ping: 1 sec internal, 64 ICMP bytes) keeps the connection
"alive" and using 3G data is then a pleasant experience, IM, email,
browsing, SIP call all working nicely. peak max download speed of 16Mbps
was reported at one time by m.speedof.me
However, stopping the ping results in loss of data conex within a few
seconds, and the behaviour from users point of view is then strikingly
similar to what's observed on 2G; and I am more or less convinced has to
do with the unknown Timing Advance issues in the PCU.
So I thought I'd note it down here.
k/