From laforge at osmocom.org  Fri May  1 14:54:53 2020
From: laforge at osmocom.org (Harald Welte)
Date: Fri, 1 May 2020 16:54:53 +0200
Subject: DGSM merge: need feedback on open questions
In-Reply-To: <20200430174338.GA8397@my.box>
References: <20200428151704.GA5297@my.box>
 <20200430174338.GA8397@my.box>
Message-ID: <20200501145453.GA1294372@nataraja>

Hi Neels,

On Thu, Apr 30, 2020 at 07:43:38PM +0200, Neels Hofmeyr wrote:
> Seems like everyone is pointing in a slightly different direction.  But I think
> most of our concerns are rather scratching the surface rather than being
> substantial deep review on the core implementations of D-GSM.

Agreed.  I've now merged the entire patch series as it is so far, we
cannot delay this another couple of months.  This obviously doesn't
meant that the code cannot change from how it is now.  Anyone is welcome
to improve it in any way.

I know this may not make everyone happy, but we had to do something to
unblock the situation.  I value the 5 different lines of thought, but it
seemed we were unable to converge on one particular direction.  I could
have taken either of those directions (no real preference either way),
but going for the patches as they are now obviously means we can move
ahead without additional work now.

In hindsight I have the feeling that this development was kept in a
private branch for too long before being submitted to gerrit for review,
until a point it was very far developed and complex.  If I'm right
with that feeling, I would strongly encourage a different approach in
future development projects.

Regards,
	Harald
-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From zhankun_bi at 163.com  Sat May  9 01:15:17 2020
From: zhankun_bi at 163.com (cruise)
Date: Sat, 9 May 2020 09:15:17 +0800
Subject: How to 'POWERON' the osmo-trx
Message-ID: <fb598419-4bb2-16dc-c7c1-5c16dc74f82a@163.com>


hello:

I installed the osmo-NITB on ubuntu18.04, including 
osmo-trx,osmo-bts,and openbsc.

The following is the print messages when these three applications start up.

*1.osmo-trx*

$ sudo osmo-trx-uhd -C osmo-trx-usrp_b200.cfg
Info: SSE3 support compiled in and supported by CPU
Info: SSE4.1 support compiled in and supported by CPU
Tue May? 5 12:36:27 2020 DLGLOBAL <0007> telnet_interface.c:104 
Available via telnet 127.0.0.1 4237
Tue May? 5 12:36:27 2020 DLCTRL <000e> control_if.c:911 CTRL at 
127.0.0.1 4236
Tue May? 5 12:36:27 2020 DMAIN <0000> osmo-trx.cpp:484 
[tid=139758118945664] Config Settings
 ?? Log Level............... 0
 ?? Device args.............
 ?? TRX Base Port........... 5700
 ?? TRX Address............. 127.0.0.1
 ?? GSM BTS Address......... 127.0.0.1
 ?? Channels................ 1
 ?? Tx Samples-per-Symbol... 4
 ?? Rx Samples-per-Symbol... 4
 ?? EDGE support............ 0
 ?? Extended RACH support... 0
 ?? Reference............... 1
 ?? Filler Burst Type....... Empty bursts
 ?? Filler Burst TSC........ 0
 ?? Filler Burst RACH Delay. 0
 ?? Multi-Carrier........... 0
 ?? Tuning offset........... 0
 ?? RSSI to dBm offset...... 28
 ?? Swap channels........... 0
 ?? Tx Antennas............. '<default>'
 ?? Rx Antennas............. '<default>'

Tue May? 5 12:36:27 2020 DMAIN <0000> osmo-trx.cpp:438 
[tid=139758118945664] Setting SCHED_RR priority 18
Tue May? 5 12:36:27 2020 DDEVDRV <0006> log.cpp:460 
[tid=139758008424192] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; 
UHD_3.14.0.HEAD-0-g6875d061
Tue May? 5 12:36:27 2020 DDEV <0005> UHDDevice.cpp:470 
[tid=139758118945664] Using discovered UHD device 
type=b200,name=Lab_B210,serial=86680AA,product=B210
Tue May? 5 12:36:28 2020 DDEVDRV <0006> b200_impl.cpp:386 
[tid=139758008424192] [B200] Detected Device: B210
Tue May? 5 12:36:29 2020 DDEVDRV <0006> b200_iface.cpp:441 
[tid=139758008424192] [B200] Loading FPGA image: 
/home/cruise/openBSC/osmo-trx/usrp_b210_fpga.bin...
Tue May? 5 12:36:45 2020 DDEVDRV <0006> b200_impl.cpp:433 
[tid=139758008424192] [B200] Operating over USB 3.
Tue May? 5 12:36:45 2020 DDEVDRV <0006> b200_impl.cpp:484 
[tid=139758008424192] [B200] Detecting internal GPSDO....
Tue May? 5 12:36:46 2020 DDEVDRV <0006> gps_ctrl.cpp:253 
[tid=139758008424192] [GPS] No GPSDO found
Tue May? 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:587 
[tid=139758008424192] [B200] Initialize CODEC control...
Tue May? 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:650 
[tid=139758008424192] [B200] Initialize Radio control...
Tue May? 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:957 
[tid=139758008424192] [B200] Performing register loopback test...
Tue May? 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:966 
[tid=139758008424192] [B200] Register loopback test passed
Tue May? 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:957 
[tid=139758008424192] [B200] Performing register loopback test...
Tue May? 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:966 
[tid=139758008424192] [B200] Register loopback test passed
Tue May? 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:758 
[tid=139758008424192] [B200] Setting master clock rate selection to 
'automatic'.
Tue May? 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:1013 
[tid=139758008424192] [B200] Asking for clock rate 16.000000 MHz...
Tue May? 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:1024 
[tid=139758008424192] [B200] Actually got clock rate 16.000000 MHz.
Tue May? 5 12:36:47 2020 DMAIN <0000> UHDDevice.cpp:211 
[tid=139758118945664] Antennas configured successfully
Tue May? 5 12:36:47 2020 DDEVDRV <0006> multi_usrp.cpp:502 
[tid=139758008424192] [MULTI_USRP] Setting master clock rate selection 
to 'manual'.
Tue May? 5 12:36:47 2020 DDEVDRV <0006> b200_impl.cpp:1013 
[tid=139758008424192] [B200] Asking for clock rate 26.000000 MHz...
Tue May? 5 12:36:47 2020 DDEVDRV <0006> b200_impl.cpp:1024 
[tid=139758008424192] [B200] Actually got clock rate 26.000000 MHz.
Tue May? 5 12:36:47 2020 DDEV <0005> UHDDevice.cpp:275 
[tid=139758118945664] Rates configured for B210 4 SPS
Tue May? 5 12:36:47 2020 DDEV <0005> UHDDevice.cpp:235 
[tid=139758118945664] Supported Tx gain range [0; 89.75]
Tue May? 5 12:36:47 2020 DDEV <0005> UHDDevice.cpp:240 
[tid=139758118945664] Supported Rx gain range [0; 76]
Tue May? 5 12:36:47 2020 DDEV <0005> UHDDevice.cpp:244 
[tid=139758118945664] Default setting Tx gain for channel 0 to 44.875
Tue May? 5 12:36:47 2020 DDEV <0005> UHDDevice.cpp:251 
[tid=139758118945664] Default setting Rx gain for channel 0 to 38
Tue May? 5 12:36:47 2020 DDEV <0005> UHDDevice.cpp:569 
[tid=139758118945664] Device configuration: Single USRP:
 ? Device: B-Series Device
 ? Mboard 0: B210
 ? RX Channel: 0
 ??? RX DSP: 0
 ??? RX Dboard: A
 ??? RX Subdev: FE-RX2
 ? TX Channel: 0
 ??? TX DSP: 0
 ??? TX Dboard: A
 ??? TX Subdev: FE-TX2
Tue May? 5 12:36:47 2020 DMAIN <0000> osmo-trx.cpp:532 
[tid=139758118945664] -- Transceiver active with 1 channel(s)

*_/when the osmo-bts-trx launched later, the following messages will 
arise,? shows that the osmo-trx received the? 'POWEROFF' command and 
feed back the 'RESPONSE' to osmo-bts-trx./_*

Tue May? 5 12:42:44 2020 DTRXCTRL <0002> Transceiver.cpp:832 
[tid=139758118945664][chan=0] command is 'POWEROFF'
Tue May? 5 12:42:44 2020 DTRXCTRL <0002> Transceiver.cpp:977 
[tid=139758118945664][chan=0] response is 'RSP POWEROFF 0'

**

*_/POWERON command was not launched. and the USRP TX/RX LED was not 
lighted./_*


*2.osmo-bts-trx*

$ sudo osmo-bts-trx
((*))
 ? |
 ?/ \ OsmoBTS
<0017> control_if.c:911 CTRL at 127.0.0.1 4238
<0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241
<0012> input/ipaccess.c:1024 enabling ipaccess BTS mode, OML connecting 
to 192.168.122.1:3002
<000b> trx_if.c:1174 phy0.0: Open transceiver

**

*_/About one minutes later, the osmo-bts-trx will exit automatically, 
and the following messages was printed./_*

<0012> e1_input.c:243 abis_sendmsg: msg->dst == NULL: 0c 12 01 90 0f 00 c8
<0012> e1_input.c:243 abis_sendmsg: msg->dst == NULL: 0c 12 01 88 12 06 
00 00 00 00 00 00
<000d> abis.c:143 Signalling link down
<0001> bts.c:293 Shutting down BTS 0, Reason Abis close
Shutdown timer expired

*3. osmo-nitb*

$ sudo osmo-nitb -c osmo-nitb-ipa.cfg
<001e> telnet_interface.c:104 Available via telnet 127.0.0.1 4242
<0020> input/ipaccess.c:985 enabling ipaccess BSC mode on 0.0.0.0 with 
OML 3002 and RSL 3003 TCP ports
<0025> control_if.c:911 CTRL at 127.0.0.1 4249
DB: Database initialized.

DB: Database prepared.


In a word, the hardware USRP? TX/RX LED? has not been lighted, it seems 
not work. How to poweron it?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200509/19daa41b/attachment.htm>

From pespin at sysmocom.de  Sat May  9 12:52:17 2020
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Sat, 9 May 2020 14:52:17 +0200
Subject: How to 'POWERON' the osmo-trx
In-Reply-To: <fb598419-4bb2-16dc-c7c1-5c16dc74f82a@163.com>
References: <fb598419-4bb2-16dc-c7c1-5c16dc74f82a@163.com>
Message-ID: <7ba75d83-386f-cec8-8f16-a42db5489a2f@sysmocom.de>

Hi,

the problem is not in osmo-bts-trx <-> osmo-trx, that's working fine so
far on your setup (sending a POWEROFF at startup is fine since then it
makes sure the osmo-trx is powered off before configuring it and finally
running POWERON on it). It won't be configured until the BSC (in your
case osmo-nitb) instructs osmo-bts-trx on how to do it through Abis OML
connection.

The problem is here:

On 5/9/20 3:15 AM, cruise wrote:
> *_/About one minutes later, the osmo-bts-trx will exit automatically,
> and the following messages was printed./_*
> 
> <0012> e1_input.c:243 abis_sendmsg: msg->dst == NULL: 0c 12 01 90 0f 00 c8
> <0012> e1_input.c:243 abis_sendmsg: msg->dst == NULL: 0c 12 01 88 12 06
> 00 00 00 00 00 00
> <000d> abis.c:143 Signalling link down
> <0001> bts.c:293 Shutting down BTS 0, Reason Abis close
> Shutdown timer expired


The  Abis connection, be it OML or RSL, between the BTS and the BSC (in
your case osmo-nitb) fails at some point. Unfortunately unless you
provide config files, complete logs and pcap files it's difficult to
tell you more. Please next time provide those while reporting.


> 
> *3. osmo-nitb*

FYI, osmo-ntib is deprecated and not maintained since years ago.
Please better use new software stack:
https://osmocom.org/projects/cellular-infrastructure/wiki



-- 
- Pau Espin Pedrol <pespin at 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
* Geschaeftsfuehrer / Managing Director: Harald Welte


From zhankun_bi at 163.com  Mon May 11 08:54:24 2020
From: zhankun_bi at 163.com (cruise)
Date: Mon, 11 May 2020 16:54:24 +0800
Subject: How to 'POWERON' the osmo-trx
In-Reply-To: <7ba75d83-386f-cec8-8f16-a42db5489a2f@sysmocom.de>
References: <fb598419-4bb2-16dc-c7c1-5c16dc74f82a@163.com>
 <7ba75d83-386f-cec8-8f16-a42db5489a2f@sysmocom.de>
Message-ID: <5656ad11-d784-a468-2ba1-910e30008144@163.com>

Thanks for your detailed and generous explanation. I am a beginner on 
openBSC, looking forward to your guidance.

There are some files in the attachment, i don't know whether they are 
enough.

1. The config files of osmo-trx, osmo-bts-trx and osmo-nitb. They are 
the original files downloaded from git repository, and i select one of 
them to run the application, i don't know whether they are correct, and 
i don't know how to modify it.

2. config.log files of osmo-trx, osmo-bts-trx and osmo-nitb. I don't 
know whether they are the logs you mentioned in your reply. I guess not, 
but i don't know how to get the complete logs, Maybe you give me some tips ?

3. pcap file which includes the data package whose src ip and dst ip are 
the 127.0.0.1, these packages were captured using wireshark.


I guess there are some problems on the config file osmo-nitb-ipa.cfg , i 
select it as the config file without reason, because i don't know how to 
config the file.


thanks for your help again.


? 2020/5/9 ??8:52, Pau Espin Pedrol ??:
> Hi,
>
> the problem is not in osmo-bts-trx <-> osmo-trx, that's working fine so
> far on your setup (sending a POWEROFF at startup is fine since then it
> makes sure the osmo-trx is powered off before configuring it and finally
> running POWERON on it). It won't be configured until the BSC (in your
> case osmo-nitb) instructs osmo-bts-trx on how to do it through Abis OML
> connection.
>
> The problem is here:
>
> On 5/9/20 3:15 AM, cruise wrote:
>> *_/About one minutes later, the osmo-bts-trx will exit automatically,
>> and the following messages was printed./_*
>>
>> <0012> e1_input.c:243 abis_sendmsg: msg->dst == NULL: 0c 12 01 90 0f 00 c8
>> <0012> e1_input.c:243 abis_sendmsg: msg->dst == NULL: 0c 12 01 88 12 06
>> 00 00 00 00 00 00
>> <000d> abis.c:143 Signalling link down
>> <0001> bts.c:293 Shutting down BTS 0, Reason Abis close
>> Shutdown timer expired
>
> The  Abis connection, be it OML or RSL, between the BTS and the BSC (in
> your case osmo-nitb) fails at some point. Unfortunately unless you
> provide config files, complete logs and pcap files it's difficult to
> tell you more. Please next time provide those while reporting.
>
>
>> *3. osmo-nitb*
> FYI, osmo-ntib is deprecated and not maintained since years ago.
> Please better use new software stack:
> https://osmocom.org/projects/cellular-infrastructure/wiki
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200511/327dcdb5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config_osmo-btx.log
Type: text/x-log
Size: 30953 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200511/327dcdb5/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config_osmo-nitb.log
Type: text/x-log
Size: 41598 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200511/327dcdb5/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config_osmo-trx.log
Type: text/x-log
Size: 47612 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200511/327dcdb5/attachment-0002.bin>
-------------- next part --------------
!
! OsmoBTS (1.2.0.46-40fb) configuration saved from vty
!!
!
log stderr
 logging filter all 1
 logging color 1
 logging print category-hex 1
 logging print category 0
 logging timestamp 0
 logging print file 1
 logging level rsl notice
 logging level oml notice
 logging level rll notice
 logging level rr notice
 logging level meas error
 logging level pag error
 logging level l1c error
 logging level l1p error
 logging level dsp error
 logging level pcu notice
 logging level ho notice
 logging level trx notice
 logging level loop notice
 logging level abis error
 logging level rtp notice
 logging level sum notice
 logging level lglobal notice
 logging level llapd notice
 logging level linp notice
 logging level lmux notice
 logging level lmi notice
 logging level lmib notice
 logging level lsms notice
 logging level lctrl notice
 logging level lgtp notice
 logging level lstats notice
 logging level lgsup notice
 logging level loap notice
 logging level lss7 notice
 logging level lsccp notice
 logging level lsua notice
 logging level lm3ua notice
 logging level lmgcp notice
 logging level ljibuf notice
 logging level lrspro notice
!
stats interval 5
!
line vty
 no login
!
e1_input
 e1_line 0 driver ipa
 e1_line 0 port 0
 no e1_line 0 keepalive
phy 0
 osmotrx ip local 127.0.0.1
 osmotrx ip remote 127.0.0.1
 osmotrx base-port local 5800
 osmotrx base-port remote 5700
 osmotrx fn-advance 20
 osmotrx rts-advance 5
 instance 0
bts 0
 band DCS1800
 ipa unit-id 6969 0
 oml remote-ip 192.168.122.1
 rtp jitter-buffer 100
 rtp port-range 16384 17407
 paging queue-size 200
 paging lifetime 0
 uplink-power-target -75
 gsmtap-sapi ccch
 gsmtap-sapi pdtch
 min-qual-rach 50
 min-qual-norm -5
 max-ber10k-rach 1707
 smscb queue-max-length 15
 smscb queue-target-length 2
 smscb queue-hysteresis 2
 trx 0
  power-ramp max-initial 5000 mdBm
  power-ramp step-size 1000 mdB
  power-ramp step-interval 2
  ms-power-control osmo
  phy 0 instance 0
-------------- next part --------------
!
! OpenBSC configuration saved from vty
!   !
password foo
!
line vty
 no login
!
e1_input
 e1_line 0 driver ipa
network
 network country code 1
 mobile network code 1
 short name OpenBSC
 long name OpenBSC
 auth policy closed
 location updating reject cause 13
 encryption a5 0
 neci 1
 rrlp mode none
 mm info 1
 handover 0
 handover window rxlev averaging 10
 handover window rxqual averaging 1
 handover window rxlev neighbor averaging 10
 handover power budget interval 6
 handover power budget hysteresis 3
 handover maximum distance 9999
 bts 0
  type sysmobts
  band DCS1800
  cell_identity 0
  location_area_code 1
  training_sequence_code 7
  base_station_id_code 63
  ms max power 15
  cell reselection hysteresis 4
  rxlev access min 0
  channel allocator ascending
  rach tx integer 9
  rach max transmission 7
  ip.access unit_id 1801 0
  oml ip.access stream_id 255 line 0
  gprs mode none
  trx 0
   rf_locked 0
   arfcn 514
   nominal power 23
   max_power_red 20
   rsl e1 tei 0
   timeslot 0
    phys_chan_config CCCH+SDCCH4
   timeslot 1
    phys_chan_config SDCCH8
   timeslot 2
    phys_chan_config TCH/F
   timeslot 3
    phys_chan_config TCH/F
   timeslot 4
    phys_chan_config TCH/F
   timeslot 5
    phys_chan_config TCH/F
   timeslot 6
    phys_chan_config TCH/F
   timeslot 7
    phys_chan_config TCH/F
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-openbsc.pcap
Type: application/vnd.tcpdump.pcap
Size: 500 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200511/327dcdb5/attachment-0003.bin>
-------------- next part --------------
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
 egprs disable
 ! 28 dB offset below is valid only for the B2xx in 1800 MHz band, see
 ! https://osmocom.org/issues/4468 for more details
 rssi-offset 28.000000
 tx-sps 4
 rx-sps 4
 clock-ref external
 rt-prio 18
 chan 0


From pespin at sysmocom.de  Mon May 11 09:14:41 2020
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Mon, 11 May 2020 11:14:41 +0200
Subject: How to 'POWERON' the osmo-trx
In-Reply-To: <5656ad11-d784-a468-2ba1-910e30008144@163.com>
References: <fb598419-4bb2-16dc-c7c1-5c16dc74f82a@163.com>
 <7ba75d83-386f-cec8-8f16-a42db5489a2f@sysmocom.de>
 <5656ad11-d784-a468-2ba1-910e30008144@163.com>
Message-ID: <9f81b354-2839-81e9-25ac-e9e1bd3a6b2d@sysmocom.de>

Hi,

you sent compilation logs, which are of no use here.

I recommend you to drop osmo-nitb and switch to the new osmocom stack as
I already said on my last email.
Furthermore, go through the wiki and read about al lthe components, as
well as user manuals in http://ftp.osmocom.org/docs/latest/ to
understand better the setup and basic configuration.


-- 
- Pau Espin Pedrol <pespin at 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
* Geschaeftsfuehrer / Managing Director: Harald Welte


From zhankun_bi at 163.com  Mon May 11 09:56:21 2020
From: zhankun_bi at 163.com (cruise)
Date: Mon, 11 May 2020 17:56:21 +0800
Subject: How to 'POWERON' the osmo-trx
In-Reply-To: <9f81b354-2839-81e9-25ac-e9e1bd3a6b2d@sysmocom.de>
References: <fb598419-4bb2-16dc-c7c1-5c16dc74f82a@163.com>
 <7ba75d83-386f-cec8-8f16-a42db5489a2f@sysmocom.de>
 <5656ad11-d784-a468-2ba1-910e30008144@163.com>
 <9f81b354-2839-81e9-25ac-e9e1bd3a6b2d@sysmocom.de>
Message-ID: <2558f64c-0090-d562-8a4b-8e1613a83fd5@163.com>

which are the useful logs? I didn't find them. How to get them?

? 2020/5/11 ??5:14, Pau Espin Pedrol ??:
> Hi,
>
> you sent compilation logs, which are of no use here.
>
> I recommend you to drop osmo-nitb and switch to the new osmocom stack as
> I already said on my last email.
> Furthermore, go through the wiki and read about al lthe components, as
> well as user manuals in http://ftp.osmocom.org/docs/latest/ to
> understand better the setup and basic configuration.
>
>



From djks74 at gmail.com  Mon May 11 10:09:51 2020
From: djks74 at gmail.com (Sandi Suhendro)
Date: Mon, 11 May 2020 17:09:51 +0700
Subject: How to 'POWERON' the osmo-trx
In-Reply-To: <2558f64c-0090-d562-8a4b-8e1613a83fd5@163.com>
References: <fb598419-4bb2-16dc-c7c1-5c16dc74f82a@163.com>
 <7ba75d83-386f-cec8-8f16-a42db5489a2f@sysmocom.de>
 <5656ad11-d784-a468-2ba1-910e30008144@163.com>
 <9f81b354-2839-81e9-25ac-e9e1bd3a6b2d@sysmocom.de>
 <2558f64c-0090-d562-8a4b-8e1613a83fd5@163.com>
Message-ID: <CANWiJYgP8LWyMR=Jbx2GVtGfcBJNfFCPdY0h=t+3=c+QK5SLSw@mail.gmail.com>

You can follow mine at user wiki.

regards,
Sandi / DUO

On Mon, May 11, 2020, 16:57 cruise <zhankun_bi at 163.com> wrote:

> which are the useful logs? I didn't find them. How to get them?
>
> ? 2020/5/11 ??5:14, Pau Espin Pedrol ??:
> > Hi,
> >
> > you sent compilation logs, which are of no use here.
> >
> > I recommend you to drop osmo-nitb and switch to the new osmocom stack as
> > I already said on my last email.
> > Furthermore, go through the wiki and read about al lthe components, as
> > well as user manuals in http://ftp.osmocom.org/docs/latest/ to
> > understand better the setup and basic configuration.
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200511/5e252ad7/attachment.htm>

From laforge at osmocom.org  Mon May 11 15:18:31 2020
From: laforge at osmocom.org (Harald Welte)
Date: Mon, 11 May 2020 17:18:31 +0200
Subject: How to 'POWERON' the osmo-trx
In-Reply-To: <2558f64c-0090-d562-8a4b-8e1613a83fd5@163.com>
References: <fb598419-4bb2-16dc-c7c1-5c16dc74f82a@163.com>
 <7ba75d83-386f-cec8-8f16-a42db5489a2f@sysmocom.de>
 <5656ad11-d784-a468-2ba1-910e30008144@163.com>
 <9f81b354-2839-81e9-25ac-e9e1bd3a6b2d@sysmocom.de>
 <2558f64c-0090-d562-8a4b-8e1613a83fd5@163.com>
Message-ID: <20200511151831.GW15731@nataraja>

Hi cruise,

On Mon, May 11, 2020 at 05:56:21PM +0800, cruise wrote:
> which are the useful logs? I didn't find them. How to get them?

Maybe this video is useful to you:
https://media.ccc.de/v/osmocon17-4008-reporting_and_investigating_issues_in_osmocom/related

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From sonny.lafuente at entropysolution.com  Fri May 29 06:45:31 2020
From: sonny.lafuente at entropysolution.com (Sonny Lafuente)
Date: Fri, 29 May 2020 06:45:31 +0000
Subject: Osmo-SIP-Connector Version 6
Message-ID: <1FC3EA48-7D4E-443D-A210-1674D1D0FC91@entropysolution.com>

Hi Community,

Does anyone here tried to upgrade the your working OSMO environment to its latest version? I have the experience where I upgraded my working osmo to the latest version and I have encountering some problem between the connection of osmo-nitb and osmo-sip-connector. For the latest sip connector update it will communicate the connection going to osmo-msc. Since I don?t use the osmo-msc instead I am using the osmo-nitb for the standalone project. Below is the error I have experiencing right now in the osmo-sip-connector and osmo-nitb.

SIP Connector Logs:

<0001> mncc.c:845 Incompatible version(5) expected 6
<0001> mncc.c:936 Reconnected to /tmp/msc_mncc
<0001> mncc.c:841 Got hello message version 5
<0001> mncc.c:845 Incompatible version(5) expected 6
<0001> mncc.c:936 Reconnected to /tmp/msc_mncc
<0001> mncc.c:841 Got hello message version 5
<0001> mncc.c:845 Incompatible version(5) expected 6

OSMO-NITB Logs:

Fri May 29 13:13:16 2020 <0006> mncc_sock.c:84 MNCC Socket has LOST connection
Fri May 29 13:13:16 2020 <0001> gsm_04_08.c:463 Clearing all currently active transactions!!!
Fri May 29 13:13:21 2020 <0006> mncc_sock.c:271 MNCC Socket has connection with external call control application
Fri May 29 13:13:21 2020 <0006> mncc_sock.c:84 MNCC Socket has LOST connection
Fri May 29 13:13:21 2020 <0001> gsm_04_08.c:463 Clearing all currently active transactions!!!


Here are the configuration file of osmo-nitb and osmo-sip-connector and how we run the command.


SIP Connector:

Command to run: ./osmo-sip-connector -c ~/osmo-sip-connector.cfg

Config File:

#
sip
 local 192.168.1.166 5062
 remote 192.168.1.166 5060
 sofia-sip log-level 2
mncc
 socket-path /tmp/msc_mncc
app


OSMO NITB:

Command to run: ./osmo-nitb -C -c ~/osmo-nitb.cfg -T -P -l /home/hlr.sqlite3 -M /tmp/msc_mncc

Config File:

line vty
 no login
!
e1_input
 e1_line 0 driver ipa
 e1_line 0 port 0
 no e1_line 0 keepalive
network
 network country code 94
 mobile network code 1
 short name 1
 long name 1
 auth policy accept-all
 authorized-regexp .*
 location updating reject cause 13
 encryption a5 0
 neci 1
 paging any use tch 0
 rrlp mode none
 mm info 1
 handover 0
 handover window rxlev averaging 10
 handover window rxqual averaging 1
 handover window rxlev neighbor averaging 10
 handover power budget interval 6
 handover power budget hysteresis 3
 handover maximum distance 9999

 timer t3109 1

 timer t3105 1

 timer t3113 60

 timer t3103 1

 timer t3122 10

 timer t3101 10

 dyn_ts_allow_tch_f 0
 subscriber-keep-in-ram 1

 bts 0
  type sysmobts
  band GSM900
  cell_identity 1
  location_area_code 1
  base_station_id_code 63
  ms max power 0
  cell reselection hysteresis 4
  rxlev access min 0
  periodic location update 30
  radio-link-timeout 32
  channel allocator descending
  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 1000 0
  oml ip.access stream_id 255 line 0
  neighbor-list mode automatic
  codec-support fr hr efr amr
  amr tch-h modes 0
  amr tch-h start-mode auto
  gprs mode gprs
  gprs 11bit_rach_support_for_egprs 0
  gprs routing area 1
  gprs network-control-order nc0
  gprs cell bvci 2
  gprs cell timer blocking-timer 3
  gprs cell timer blocking-retries 3
  gprs cell timer unblocking-retries 3
  gprs cell timer reset-timer 3
  gprs cell timer reset-retries 3
  gprs cell timer suspend-timer 10
  gprs cell timer suspend-retries 3
  gprs cell timer resume-timer 10
  gprs cell timer resume-retries 3
  gprs cell timer capability-update-timer 10
  gprs cell timer capability-update-retries 3
  gprs nsei 101
  gprs ns timer tns-block 3
  gprs ns timer tns-block-retries 3
  gprs ns timer tns-reset 3
  gprs ns timer tns-reset-retries 3
  gprs ns timer tns-test 30
  gprs ns timer tns-alive 3
  gprs ns timer tns-alive-retries 10
  gprs nsvc 0 nsvci 101
  gprs nsvc 0 local udp port 23000
  gprs nsvc 0 remote udp port 23000
  gprs nsvc 0 remote ip 127.0.0.2
  gprs nsvc 1 nsvci 0
  gprs nsvc 1 local udp port 0
  gprs nsvc 1 remote udp port 0
  gprs nsvc 1 remote ip 0.0.0.0
  no force-combined-si

  trx 0
   rf_locked 0
   arfcn 74
   nominal power 0
   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
  trx 1
   rf_locked 0
   arfcn 65
   nominal power 0
   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
mncc-int
 default-codec tch-f fr
 default-codec tch-h amr
nitb
 subscriber-create-on-demand

 subscriber-create-on-demand random 100000 199999
 no assign-tmsi
smpp
 local-tcp-ip 127.0.0.1 2776
 system-id password
 policy closed
 smpp-first
 esme root
  password password
  default-route


Thank you.

Sonny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200529/f0a83b3a/attachment.htm>

From axilirator at gmail.com  Fri May 29 08:19:34 2020
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Fri, 29 May 2020 15:19:34 +0700
Subject: Osmo-SIP-Connector Version 6
In-Reply-To: <1FC3EA48-7D4E-443D-A210-1674D1D0FC91@entropysolution.com>
References: <1FC3EA48-7D4E-443D-A210-1674D1D0FC91@entropysolution.com>
Message-ID: <CAPEnp=ZDU4yfA3v8OrCLpwCELnA3ru7G-+s=r6eMhSqOKAi0Uw@mail.gmail.com>

Hello Sonny,

thank you for such a detailed report.

> Does anyone here tried to upgrade the your working OSMO environment to its latest version?

I guess almost everybody (at least in development team) nowadays is
using the new CNI stack with separate components (BSC, MSC, HLR),
because osmo-nitb has been deprecated years ago. We don't really want
to look back all the time and keep compatibility layers for osmo-nitb
in other components. This means that you're mostly on your own with
osmo-nitb.

> Since I don?t use the osmo-msc instead I am using the osmo-nitb for the standalone project

I would still recommend you to use the new stack, since we have fixed
tons of bugs and implemented many new features. But if it's not
possible, you could try to downgrade osmo-sip-connector.
Alternatively, you could implement handling of the new MNCC protocol
version (6) in osmo-nitb. I believe it's just a few minutes of work,
basically: updating some structures and bumping protocol version in
the header file. Patches are welcome ;)

Good luck!

With best regards,
Vadim Yanitskiy.


From laforge at osmocom.org  Fri May 29 16:13:53 2020
From: laforge at osmocom.org (Harald Welte)
Date: Fri, 29 May 2020 18:13:53 +0200
Subject: Osmo-SIP-Connector Version 6
In-Reply-To: <1FC3EA48-7D4E-443D-A210-1674D1D0FC91@entropysolution.com>
References: <1FC3EA48-7D4E-443D-A210-1674D1D0FC91@entropysolution.com>
Message-ID: <20200529161353.GA182140@nataraja>

Hi Sonny,

On Fri, May 29, 2020 at 06:45:31AM +0000, Sonny Lafuente wrote:

> Since I don?t use the osmo-msc instead I am using the osmo-nitb for the standalone project. Below is the
> error I have experiencing right now in the osmo-sip-connector and osmo-nitb.

Sorry but - everyone is free to shoot themselves into the foot.  If you
are using software that is abandoned,
deprecated and unmaintained for several years now (osmo-nitb), you
cannot expect any support for this by the community - particularny not
if you want to combine it a much more modern osmo-sip-connector.

Either you use ancient osmo-nitb with ancient lcr or osmo-sip-connector
(and no support), or you use a CNI based network with separate BSC, STP,
MGW, MSC, HLR, ...  - which will also give you many years worth of
bugfixes.

Regards,
	Harald
-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From keith at rhizomatica.org  Fri May 29 16:44:58 2020
From: keith at rhizomatica.org (Keith)
Date: Fri, 29 May 2020 11:44:58 -0500
Subject: Osmo-SIP-Connector Version 6
In-Reply-To: <1FC3EA48-7D4E-443D-A210-1674D1D0FC91@entropysolution.com>
References: <1FC3EA48-7D4E-443D-A210-1674D1D0FC91@entropysolution.com>
Message-ID: <17a3c47c-2b30-4a8e-cc85-e5dc24b17705@rhizomatica.org>

Sonny,

I had been thinking about dealing with this for sometime now, as Vadim
says, not a big job,

I had just wondered whether to "upgrade" the mncc support in osmo-nitb
or else to make a configuration variable in osmo-sip-connector for
"mncc-version" and make the new code dependent on that. Probably the
first option would be most acceptable as why burden the
osmo-sip-connector with code to support something obsolete? On the other
hand you add some code to osmo-nitb just to throw it away, (the nitb
won't use any of the new fields in the MNCC version 6.)

Partly I never did either, as I don't want to bother code reviewers with
supporting osmo-nitb.

I totally am with what Harald says, at the same time, it has kind of
annoyed me that we still publish packages for osmo-nitb and
osmo-sip-connector and that combination has not worked now for some time.

So, in the meantime, if you MUST use osmo-nitb, unless you still have a
package for your OS around, (check in your apt cache?) I'd suggesting
building osmo-sip-connector version 1.3. It's a fairly easy build.

If you really really have a pressing reason why you cannot move to the
new core network stack and you absolutely cannot find a solution, Tell
me something about your use case, either PM or here on the list, I can
help out one way or another.

k.






From sonny.lafuente at entropysolution.com  Fri May 29 23:25:58 2020
From: sonny.lafuente at entropysolution.com (Sonny Lafuente)
Date: Fri, 29 May 2020 23:25:58 +0000
Subject: Osmo-SIP-Connector Version 6
In-Reply-To: <17a3c47c-2b30-4a8e-cc85-e5dc24b17705@rhizomatica.org>
References: <1FC3EA48-7D4E-443D-A210-1674D1D0FC91@entropysolution.com>
 <17a3c47c-2b30-4a8e-cc85-e5dc24b17705@rhizomatica.org>
Message-ID: <F89E5975-6FD5-4DF5-89E7-16D25804F30F@entropysolution.com>

Hi Keith,

Thank you for this. I just downgraded the osmo-sip-connector just to support the version of osmo-nitb.

Regards,
Sonny

On May 30, 2020, at 12:44 AM, Keith <keith at rhizomatica.org> wrote:

> Sonny,
> 
> I had been thinking about dealing with this for sometime now, as Vadim
> says, not a big job,
> 
> I had just wondered whether to "upgrade" the mncc support in osmo-nitb
> or else to make a configuration variable in osmo-sip-connector for
> "mncc-version" and make the new code dependent on that. Probably the
> first option would be most acceptable as why burden the
> osmo-sip-connector with code to support something obsolete? On the other
> hand you add some code to osmo-nitb just to throw it away, (the nitb
> won't use any of the new fields in the MNCC version 6.)
> 
> Partly I never did either, as I don't want to bother code reviewers with
> supporting osmo-nitb.
> 
> I totally am with what Harald says, at the same time, it has kind of
> annoyed me that we still publish packages for osmo-nitb and
> osmo-sip-connector and that combination has not worked now for some time.
> 
> So, in the meantime, if you MUST use osmo-nitb, unless you still have a
> package for your OS around, (check in your apt cache?) I'd suggesting
> building osmo-sip-connector version 1.3. It's a fairly easy build.
> 
> If you really really have a pressing reason why you cannot move to the
> new core network stack and you absolutely cannot find a solution, Tell
> me something about your use case, either PM or here on the list, I can
> help out one way or another.
> 
> k.
> 
> 
> 
> 



From sonny.lafuente at entropysolution.com  Fri May 29 23:27:06 2020
From: sonny.lafuente at entropysolution.com (Sonny Lafuente)
Date: Fri, 29 May 2020 23:27:06 +0000
Subject: Osmo-SIP-Connector Version 6
In-Reply-To: <CAPEnp=ZDU4yfA3v8OrCLpwCELnA3ru7G-+s=r6eMhSqOKAi0Uw@mail.gmail.com>
References: <1FC3EA48-7D4E-443D-A210-1674D1D0FC91@entropysolution.com>
 <CAPEnp=ZDU4yfA3v8OrCLpwCELnA3ru7G-+s=r6eMhSqOKAi0Uw@mail.gmail.com>
Message-ID: <1D84852C-B4C1-4320-8740-D9634E22B551@entropysolution.com>

Hi Vadim,

Thank you for the information. I just downgraded the version of my sip-connector just to support the version of my osmo-nitb. 

Regards,
Sonny

On May 29, 2020, at 4:19 PM, Vadim Yanitskiy <axilirator at gmail.com> wrote:

> Hello Sonny,
> 
> thank you for such a detailed report.
> 
>> Does anyone here tried to upgrade the your working OSMO environment to its latest version?
> 
> I guess almost everybody (at least in development team) nowadays is
> using the new CNI stack with separate components (BSC, MSC, HLR),
> because osmo-nitb has been deprecated years ago. We don't really want
> to look back all the time and keep compatibility layers for osmo-nitb
> in other components. This means that you're mostly on your own with
> osmo-nitb.
> 
>> Since I don?t use the osmo-msc instead I am using the osmo-nitb for the standalone project
> 
> I would still recommend you to use the new stack, since we have fixed
> tons of bugs and implemented many new features. But if it's not
> possible, you could try to downgrade osmo-sip-connector.
> Alternatively, you could implement handling of the new MNCC protocol
> version (6) in osmo-nitb. I believe it's just a few minutes of work,
> basically: updating some structures and bumping protocol version in
> the header file. Patches are welcome ;)
> 
> Good luck!
> 
> With best regards,
> Vadim Yanitskiy.