From nhofmeyr at sysmocom.de  Sun Aug  1 18:06:49 2021
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sun, 1 Aug 2021 20:06:49 +0200
Subject: rsl_rx_bs_pwr_ctrl()
Message-ID: <20210801180649.GA20612@my.box>

Hey Vadim,

Just now I came across this code,
with an early return in case of BCCH. But right below that, BCCH is still
mentioned in the comment, and there are more IEs being parsed.

So I get the impression the early return may prevent that OSMO_MIN limiting for
BCCH, and that may not be intended?


	/* Osmocom specific extension for BCCH carrier power reduction */
	if (dch->chan_nr == RSL_CHAN_BCCH) {
		int rc = bts_set_c0_pwr_red(trx->bts, new);
		if (rc != 0) {
			const uint8_t cause = (rc == -ENOTSUP) ?
				RSL_ERR_SERV_OPT_UNIMPL : RSL_ERR_IE_CONTENT;
			return rsl_tx_error_report(trx, cause, &dch->chan_nr, NULL, msg);
		}

		return 0;
	}

	/* BS power reduction is generally not allowed on BCCH/CCCH carrier.
	 * However, we allow it in the BCCH carrier power reduction operation.
	 * Constrain BS power value by the maximum reduction for this timeslot. */
	if (trx->bts->c0 == trx)
		new = OSMO_MIN(new, lchan->ts->c0_power_red_db);

	/* 9.3.32 (TLV) BS Power Parameters IE (vendor specific) */
	if ((ie = TLVP_GET(&tp, RSL_IE_BS_POWER_PARAM)) != NULL) {

https://git.osmocom.org/osmo-bts/tree/src/common/rsl.c?id=6611e7f3059d26794a59135637076fe59cf52dae#n2220


From nhofmeyr at sysmocom.de  Sun Aug  1 23:01:24 2021
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 2 Aug 2021 01:01:24 +0200
Subject: Can't establish calls between two handsets [nanoBTS 165AU]
In-Reply-To: <CAPy3zgFYmGw1bMqv4zm1Zs9S9q8ChKPQMDrmXDvqt7ZushpwXA@mail.gmail.com>
References: <CAPy3zgFPmRcKNHC-t7wx22pKnYXnniVxip6yqP_OW-QrezsW6Q@mail.gmail.com>
 <06b0bc30-bdaa-daff-ae1e-ca0b4cc604b7@sysmocom.de>
 <CAPy3zgFYmGw1bMqv4zm1Zs9S9q8ChKPQMDrmXDvqt7ZushpwXA@mail.gmail.com>
Message-ID: <20210801230124.GB20612@my.box>

Nothing interesting can be said about your IPACC_CRCX message.
Compare a pcap of a normal assignment, taken from our test suite:
https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/lastSuccessfulBuild/artifact/logs/bsc-tester/BSC_Tests.TC_assignment_codec_amr_f.pcap.gz

Maybe someone else knows whether it can be a problem with the nanoBTS
configuration? I can't help with those devices unfortunately.

~N

On Fri, Jul 30, 2021 at 04:51:17PM +0100, Sebastian Mauer wrote:
> Attached is a dump of the communication between BSC and nanoBTS when
> attempting to make a call.


From mauimauer at gmail.com  Mon Aug  2 08:46:00 2021
From: mauimauer at gmail.com (Sebastian Mauer)
Date: Mon, 2 Aug 2021 09:46:00 +0100
Subject: Can't establish calls between two handsets [nanoBTS 165AU]
In-Reply-To: <20210801230124.GB20612@my.box>
References: <CAPy3zgFPmRcKNHC-t7wx22pKnYXnniVxip6yqP_OW-QrezsW6Q@mail.gmail.com>
 <06b0bc30-bdaa-daff-ae1e-ca0b4cc604b7@sysmocom.de>
 <CAPy3zgFYmGw1bMqv4zm1Zs9S9q8ChKPQMDrmXDvqt7ZushpwXA@mail.gmail.com>
 <20210801230124.GB20612@my.box>
Message-ID: <CAPy3zgHOazsRqNt8Vi6249ogxMu+RZ2JVs5Jqypj=1+pBAOOUg@mail.gmail.com>

Yeah, I was hoping to get some understanding of what's going wrong
with the CRCX message.
Before setting up the nanoBTS it was NVRAM reset so I am unsure if
it's possible any old configuration would
have been left over.

On Mon, 2 Aug 2021 at 00:01, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
>
> Nothing interesting can be said about your IPACC_CRCX message.
> Compare a pcap of a normal assignment, taken from our test suite:
> https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/lastSuccessfulBuild/artifact/logs/bsc-tester/BSC_Tests.TC_assignment_codec_amr_f.pcap.gz
>
> Maybe someone else knows whether it can be a problem with the nanoBTS
> configuration? I can't help with those devices unfortunately.
>
> ~N
>


From laforge at gnumonks.org  Mon Aug  9 15:23:31 2021
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 9 Aug 2021 17:23:31 +0200
Subject: Harald's surplus telecom equipment for free
Message-ID: <YRFIc3thbLKlumRW@nataraja>

Hi all,

as I currently have to clear my basement for water-damage related renovation,
I'm going to use the opportunity to get rid of some of the things I'm unlikely
going to use ever again

https://osmocom.org/projects/miscellaneous-projects/wiki/LaForge_surplus_202108

If anyone is interested: I'm not looking for any money in return.  I just want
to find a new home for it rather than actually disposing of it at some recycling
facility.

Let me know ASAP if you're interested in any of it, thanks.

Happy hacking,
	Harald

-- 
- Harald Welte <laforge at gnumonks.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  Tue Aug 10 10:36:11 2021
From: sonny.lafuente at entropysolution.com (Sonny Lafuente)
Date: Tue, 10 Aug 2021 10:36:11 +0000
Subject: HR / AMR Lab Testing Using OSMO-NITB
Message-ID: <A998C068-44D6-4E86-9211-B2736D299D13@entropysolution.com>

Hello Community!


Would like to as if anyone here have experience  testing Half rate /AMR in osmo-nitb and Freeswitch. Basically we are testing it in our lab with our devices Samsung Note 9 and iPhone and we are having issue / errors as observed during testing. Below are the details of the NITB we using:



OpenBSC# show version
OpenBSC 1.1.0.76-0bbb9 (OpenBSC).
Copyright (C) 2008-2016 Harald Welte, Holger Freyther
Contributions by Daniel Willmann, Jan L?bbe, Stefan Schmidt
Dieter Spaar, Andreas Eversberg, Sylvain Munaut, Neels Hofmeyr

License AGPLv3+: GNU AGPL version 3 or later <http://gnu.org/licenses/agpl-3.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

OpenBSC#



Osmo running-config:

stats interval 5
!
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 10
 mobile network code 1
 short name testnetwork
 long name testnetwork
 auth policy closed
 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 t3113 60

 timer t3103 1

 timer t3101 10

 timer t3109 1

 timer t3122 10

 timer t3105 1

 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 23
  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

  trx 0
   rf_locked 0
   arfcn 122
   nominal power 0
   rsl e1 tei 0

   timeslot 0
    phys_chan_config CCCH+SDCCH4
    hopping enabled 0
   timeslot 1
    phys_chan_config SDCCH8
    hopping enabled 0
   timeslot 2
    phys_chan_config SDCCH8
    hopping enabled 0
   timeslot 3
    phys_chan_config TCH/H
    hopping enabled 0
   timeslot 4
    phys_chan_config TCH/H
    hopping enabled 0
   timeslot 5
    phys_chan_config TCH/H
    hopping enabled 0
   timeslot 6
    phys_chan_config TCH/H
    hopping enabled 0
   timeslot 7
    phys_chan_config TCH/H
    hopping enabled 0
  trx 1
   rf_locked 0
   arfcn 42
   nominal power 0
   rsl e1 tei 0

   timeslot 0
    phys_chan_config CCCH+SDCCH4
    hopping enabled 0
   timeslot 1
    phys_chan_config TCH/H
    hopping enabled 0
   timeslot 2
    phys_chan_config TCH/H
    hopping enabled 0
   timeslot 3
    phys_chan_config TCH/H
    hopping enabled 0
   timeslot 4
    phys_chan_config TCH/H
    hopping enabled 0
   timeslot 5
    phys_chan_config TCH/H
    hopping enabled 0
   timeslot 6
    phys_chan_config TCH/H
    hopping enabled 0
   timeslot 7
    phys_chan_config TCH/H
    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 admin
  password password
  default-route


NITB Logs:



Not Working:


Tue Aug 10 17:08:40 2021 <0004> abis_rsl.c:1848 (bts=0) CHAN RQD: reason: call re-establishment (ra=0x49, neci=0x01, chreq_reason=0x02)
Tue Aug 10 17:08:40 2021 <0004> abis_rsl.c:1924 (bts=0,trx=1,ts=7,ss=0) Activating ARFCN(73) SS(0) lctype TCH_H r=CALL ra=0x49 ta=0
Tue Aug 10 17:08:40 2021 <0004> abis_rsl.c:595 (bts=0,trx=1,ts=7,pchan=TCH/H) Tx RSL Channel Activate with act_type=INITIAL
Tue Aug 10 17:08:40 2021 <0004> abis_rsl.c:1231 (bts=0,trx=1,ts=7,ss=0) state NONE -> ACTIVATION REQUESTED
Tue Aug 10 17:08:40 2021 <0004> abis_rsl.c:1603 (bts=0,trx=1,ts=7,ss=0) CHANNEL ACTIVATE ACK
Tue Aug 10 17:08:40 2021 <0004> abis_rsl.c:1231 (bts=0,trx=1,ts=7,ss=0) state ACTIVATION REQUESTED -> ACTIVE
Tue Aug 10 17:08:41 2021 <000a> bsc_api.c:415 Sending (bts=0,trx=1,ts=7,ss=0) ChanModify for speech: SPEECH_AMR on channel TCH_H
Tue Aug 10 17:08:41 2021 <0003> gsm_04_08_utils.c:517 -> CHANNEL MODE MODIFY mode=0x41 <?????????????????????????????????????? This is what we observed, no Channel Modify Ack
Tue Aug 10 17:08:47 2021 <000a> bsc_api.c:139 Assignment T10 timeout on 0x15b4350
Tue Aug 10 17:08:47 2021 <0003> osmo_msc.c:82 MSC assign failure (do nothing).
Tue Aug 10 17:08:51 2021 <0004> abis_rsl.c:1848 (bts=0) CHAN RQD: reason: call re-establishment (ra=0x49, neci=0x01, chreq_reason=0x02)
Tue Aug 10 17:08:51 2021 <0004> abis_rsl.c:1924 (bts=0,trx=1,ts=7,ss=1) Activating ARFCN(73) SS(1) lctype TCH_H r=CALL ra=0x49 ta=0
Tue Aug 10 17:08:51 2021 <0004> abis_rsl.c:595 (bts=0,trx=1,ts=7,pchan=TCH/H) Tx RSL Channel Activate with act_type=INITIAL
Tue Aug 10 17:08:51 2021 <0004> abis_rsl.c:1231 (bts=0,trx=1,ts=7,ss=1) state NONE -> ACTIVATION REQUESTED
Tue Aug 10 17:08:51 2021 <0004> abis_rsl.c:1603 (bts=0,trx=1,ts=7,ss=1) CHANNEL ACTIVATE ACK
Tue Aug 10 17:08:51 2021 <0004> abis_rsl.c:1231 (bts=0,trx=1,ts=7,ss=1) state ACTIVATION REQUESTED -> ACTIVE
Tue Aug 10 17:08:53 2021 <0017> smpp_smsc.c:746 [entropy] smpp_pdu_rx(00 00 00 10 00 00 00 15 00 00 00 00 00 00 00 24 )
Tue Aug 10 17:08:53 2021 <0017> smpp_smsc.c:595 [entropy] Rx Enquire Link
Tue Aug 10 17:08:53 2021 <0017> smpp_smsc.c:599 [entropy] Tx Enquire Link Response
Tue Aug 10 17:09:03 2021 <0004> abis_rsl.c:1848 (bts=0) CHAN RQD: reason: call re-establishment (ra=0x47, neci=0x01, chreq_reason=0x02)
Tue Aug 10 17:09:03 2021 <0004> abis_rsl.c:1924 (bts=0,trx=1,ts=6,ss=0) Activating ARFCN(73) SS(0) lctype TCH_H r=CALL ra=0x47 ta=0
Tue Aug 10 17:09:03 2021 <0004> abis_rsl.c:595 (bts=0,trx=1,ts=6,pchan=TCH/H) Tx RSL Channel Activate with act_type=INITIAL
Tue Aug 10 17:09:03 2021 <0004> abis_rsl.c:1231 (bts=0,trx=1,ts=6,ss=0) state NONE -> ACTIVATION REQUESTED
Tue Aug 10 17:09:03 2021 <0004> abis_rsl.c:1603 (bts=0,trx=1,ts=6,ss=0) CHANNEL ACTIVATE ACK
Tue Aug 10 17:09:03 2021 <0004> abis_rsl.c:1231 (bts=0,trx=1,ts=6,ss=0) state ACTIVATION REQUESTED -> ACTIVE
Tue Aug 10 17:09:13 2021 <0004> abis_rsl.c:1358 (bts=0,trx=1,ts=7,ss=0) CONNECTION FAIL: RELEASING state ACTIVE CAUSE=0x01(Radio Link Failure)
Tue Aug 10 17:09:13 2021 <0004> abis_rsl.c:867 (bts=0,trx=1,ts=7,ss=0) RF Channel Release due to error: 1
Tue Aug 10 17:09:13 2021 <0004> abis_rsl.c:777 (bts=0,trx=1,ts=7,ss=0) DEACTivate SACCH CMD
Tue Aug 10 17:09:13 2021 <0004> abis_rsl.c:1231 (bts=0,trx=1,ts=7,ss=0) state ACTIVE -> RELEASE DUE ERROR
Tue Aug 10 17:09:13 2021 <0004> abis_rsl.c:939 (bts=0,trx=1,ts=7,ss=0) RF CHANNEL RELEASE ACK
Tue Aug 10 17:09:17 2021 <0004> abis_rsl.c:826 (bts=0,trx=1,ts=7,ss=0) is back in operation.
Tue Aug 10 17:09:17 2021 <0004> abis_rsl.c:1231 (bts=0,trx=1,ts=7,ss=0) state RELEASE DUE ERROR -> NONE
Tue Aug 10 17:09:19 2021 <0004> abis_rsl.c:1848 (bts=0) CHAN RQD: reason: Location updating (ra=0x07, neci=0x01, chreq_reason=0x03)
Tue Aug 10 17:09:19 2021 <0004> abis_rsl.c:1924 (bts=0,trx=0,ts=1,ss=0) Activating ARFCN(8) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x07 ta=0
Tue Aug 10 17:09:19 2021 <0004> abis_rsl.c:595 (bts=0,trx=0,ts=1,pchan=SDCCH8) Tx RSL Channel Activate with act_type=INITIAL
Tue Aug 10 17:09:19 2021 <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=1,ss=0) state NONE -> ACTIVATION REQUESTED
Tue Aug 10 17:09:19 2021 <0004> abis_rsl.c:1603 (bts=0,trx=0,ts=1,ss=0) CHANNEL ACTIVATE ACK
Tue Aug 10 17:09:19 2021 <0004> abis_rsl.c:1231 (bts=0,trx=0,ts=1,ss=0) state ACTIVATION REQUESTED -> ACTIVE




Osmo-sip-connector Logs:


<0000> sip.c:330 sip_release_call(): Release with MNCC cause(NORM_CALL_CLEAR)
<0000> sip.c:302 cause2status(): Mapping cause(NORM_CALL_CLEAR) to status(200)
<0000> sip.c:353 Ending leg(0x8dc700) in con
<0000> sip.c:223 SIP event(33) status(200) phrase(OK) 0x8dc700
<0000> sip.c:257 leg(0x8dc700) got resp to bye
<0000> sip.c:223 SIP event(9) status(200) phrase(Session Terminated) 0x8d7150
<0000> sip.c:265 leg(0x8d7150) got bye, releasing.
<0000> sip.c:223 SIP event(7) status(0) phrase(INVITE sent) 0x8d7150
<0000> sip.c:223 SIP event(1) status(100) phrase(Trying) (nil)
<0000> sip.c:89 Incoming call handle(0x8d96a0)
<0000> sip.c:223 SIP event(7) status(100) phrase(Trying) 0x8dc700
<0000> sip.c:330 sip_release_call(): Release with MNCC cause(RESOURCE_UNAVAIL)
<0000> sip.c:302 cause2status(): Mapping cause(RESOURCE_UNAVAIL) to status(503)
<0000> sip.c:341 Canceling leg(0x8dc700) in cnfd state
<0000> sip.c:223 SIP event(31) status(503) phrase(Service Unavailable) 0x8d7150
<0000> sip.c:242 leg(0x8d7150) unknown SIP status(503), releasing.
<0000> sip.c:248 Releasing other leg (0x8d6f30) with status(503)
<0001> mncc.c:54 cmd(0x204) never arrived for leg(2147483656) <?????????????????????????????????????? Basically it didn?t arrived in B Leg.
<0001> mncc.c:495 call(2147483656) can not be found




Very well appreciated your help on this.



Best Regards,
Sonny


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20210810/3413a4a9/attachment.htm>

From keith at rhizomatica.org  Tue Aug 10 16:28:21 2021
From: keith at rhizomatica.org (Keith)
Date: Tue, 10 Aug 2021 11:28:21 -0500
Subject: HR / AMR Lab Testing Using OSMO-NITB
In-Reply-To: <A998C068-44D6-4E86-9211-B2736D299D13@entropysolution.com>
References: <A998C068-44D6-4E86-9211-B2736D299D13@entropysolution.com>
Message-ID: <0ddfd57d-b7e0-5751-bdf3-c2ef0d5db7a6@rhizomatica.org>


On 10/08/2021 05:36, Sonny Lafuente wrote:
>
>
> *OpenBSC# show version*
> OpenBSC 1.1.0.76-0bbb9 (OpenBSC).

Hi Sonny. I don't think you are likely to get much response here about
OpenBSC (despite the name of the list still pending change)

All the same, I can tell you that it "Works for me", albeit with a
carefully chosen combination of versions of osmo-nitb, osmo-bts,
osmo-sip-connector, freeswitch and amr modules.

I don't even think that current osmo-sip-connector will connect to
"current" osmo-nitb though, and neither will current osmo-bts, (although
you do not specify what BTS you are using).

My question is: why are you testing this?

If you need more help, better might be a pcap of traffic including SIP
and RTP and freeswitch logs. osmo-bts log too, if you are using it. Not
necessarily suggesting you should post that to this list though. But if
you do, maybe include some info on what the project is for?

Thanks!

k.




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

From domi at tomcsanyi.net  Tue Aug 10 18:19:49 2021
From: domi at tomcsanyi.net (Tomcsanyi, Domonkos)
Date: Tue, 10 Aug 2021 20:19:49 +0200
Subject: HR / AMR Lab Testing Using OSMO-NITB
In-Reply-To: <0ddfd57d-b7e0-5751-bdf3-c2ef0d5db7a6@rhizomatica.org>
References: <0ddfd57d-b7e0-5751-bdf3-c2ef0d5db7a6@rhizomatica.org>
Message-ID: <7A267483-A8A0-43B1-A856-03A0C2183EC5@tomcsanyi.net>

Hi Sonny,

I am really sorry to be *that guy* who is ruining all the fun, but I must chime in and state:
Osmo NITB is end of life and it is highly unlikely to receive any fixes or support for it.
I think it was clearly stated by main contributors of the project that basically the new, more 3GPP-like network from osmocom is supposed to be used by all users. It is really not that more complicated to deploy it once you get the hang of it compared to nitb in my opinion.

Sorry again, and good luck Sonny.

Keith, obviously I did not mean the above to you, I am aware your use case is special and you have a good reason(s) to do things the way you are doing them. In case of Sonny since he mentioned a lab-setup I expect him to be more flexible and be able to rapidly move to the new architecture - hence my comment above.

Kind regards,
Domi


> 10.08.2021 d?tummal, 18:28 id?pontban Keith <keith at rhizomatica.org> ?rta:
> 
> ?
> 
> 
> On 10/08/2021 05:36, Sonny Lafuente wrote:
>> 
>> 
>> OpenBSC# show version
>> OpenBSC 1.1.0.76-0bbb9 (OpenBSC).
> 
> Hi Sonny. I don't think you are likely to get much response here about OpenBSC (despite the name of the list still pending change)
> 
> All the same, I can tell you that it "Works for me", albeit with a carefully chosen combination of versions of osmo-nitb, osmo-bts, osmo-sip-connector, freeswitch and amr modules.
> 
> I don't even think that current osmo-sip-connector will connect to "current" osmo-nitb though, and neither will current osmo-bts, (although you do not specify what BTS you are using). 
> 
> My question is: why are you testing this?
> 
> If you need more help, better might be a pcap of traffic including SIP and RTP and freeswitch logs. osmo-bts log too, if you are using it. Not necessarily suggesting you should post that to this list though. But if you do, maybe include some info on what the project is for?
> 
> Thanks!
> 
> k.
> 
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20210810/fe557f71/attachment.htm>

From vyanitskiy at sysmocom.de  Thu Aug 12 04:00:37 2021
From: vyanitskiy at sysmocom.de (Vadim Yanitskiy)
Date: Thu, 12 Aug 2021 10:00:37 +0600
Subject: rsl_rx_bs_pwr_ctrl()
In-Reply-To: <20210801180649.GA20612@my.box>
References: <20210801180649.GA20612@my.box>
Message-ID: <24b9fc9e-350d-0c52-4120-83f2c61293d5@sysmocom.de>

Hi Neels,

On 8/2/21 12:06 AM, Neels Hofmeyr wrote:
> Just now I came across this code,
> with an early return in case of BCCH. But right below that, BCCH is still
> mentioned in the comment, and there are more IEs being parsed.
> 
> So I get the impression the early return may prevent that OSMO_MIN limiting for
> BCCH, and that may not be intended?

in rsl_rx_bs_pwr_ctrl(), we actually handle these different cases:

a) power reduction on *inactive* logical channels of the BCCH carrier,
b) power reduction on *active* logical channels of the BCCH carrier,
c) power reduction on *active* logical channels of a non-BCCH carrier.

Case a) is handled in bts_set_c0_pwr_red().  This function iterates over 
all timeslots and sets power reduction values depending on their pchan 
combinations.

Case b) actually depends on a), because ts->c0_power_red_db is set in 
bts_set_c0_pwr_red().  The idea is that b) is not allowed unless the BTS 
is operating in the power saving mode.

So, this is why the OSMO_MIN limiting is not relevant to a).

Case c) is not related to the question brought in this thread.

Regards,
Vadim.

-- 
- Vadim Yanitskiy <vyanitskiy 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 laforge at osmocom.org  Thu Aug 12 11:34:51 2021
From: laforge at osmocom.org (Harald Welte)
Date: Thu, 12 Aug 2021 13:34:51 +0200
Subject: Announcement of "OsmoDevCall" on August 13, 2021
Message-ID: <YRUHW06swTVMWOOT@nataraja>

Dear Osmocom community,

It's my pleasure to announce the next OsmoDevCall at

	August 13, 2021 at 20:00 CEST
at
	https://meeting4.franken.de/b/har-xbc-bsx-wvs

This meeting will have the following schedule:

20:00 meet + greet
20:15 presentation on "GSM-R and its differences to GSM"
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call

Attendance is free of charge and open to anyone with an interest
in Osmocom.

More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall

Looking forward to meeting you on Friday.

Best regards,
	Harald

[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.

-- 
- 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 nhofmeyr at sysmocom.de  Fri Aug 13 22:18:51 2021
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 14 Aug 2021 00:18:51 +0200
Subject: rsl_rx_bs_pwr_ctrl()
In-Reply-To: <24b9fc9e-350d-0c52-4120-83f2c61293d5@sysmocom.de>
References: <20210801180649.GA20612@my.box>
 <24b9fc9e-350d-0c52-4120-83f2c61293d5@sysmocom.de>
Message-ID: <20210813221851.GA29735@my.box>

On Thu, Aug 12, 2021 at 10:00:37AM +0600, Vadim Yanitskiy wrote:
> in rsl_rx_bs_pwr_ctrl(), we actually handle these different cases:
> 
> a) power reduction on *inactive* logical channels of the BCCH carrier,
> b) power reduction on *active* logical channels of the BCCH carrier,
> c) power reduction on *active* logical channels of a non-BCCH carrier.
> 
> Case a) is handled in bts_set_c0_pwr_red().  This function iterates over all
> timeslots and sets power reduction values depending on their pchan
> combinations.
> 
> Case b) actually depends on a), because ts->c0_power_red_db is set in
> bts_set_c0_pwr_red().  The idea is that b) is not allowed unless the BTS is
> operating in the power saving mode.

sorry i tried but i don't really understand in depth ... but me understanding
is not required. If you think this is not obvious to someone familiar with BCCH
power management, then maybe adding a code comment explaining could be nice?

~N


From laforge at osmocom.org  Tue Aug 24 11:50:13 2021
From: laforge at osmocom.org (Harald Welte)
Date: Tue, 24 Aug 2021 13:50:13 +0200
Subject: Announcement of "OsmoDevCall" on August 27, 2021
Message-ID: <YSTc9aNFH6DAK9Ic@nataraja>

Dear Osmocom community,

It's my pleasure to announce the next OsmoDevCall at

	August 27, 2021 at 20:00 CEST
at
	https://meeting4.franken.de/b/har-xbc-bsx-wvs

This meeting will have the following schedule:

20:00 meet + greet
20:15 presentation on "osmo-remsim in practice"
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call

Attendance is free of charge and open to anyone with an interest
in Osmocom.

More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall

Looking forward to meeting you on Friday.

Best regards,
	Harald

[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.

-- 
- 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 mariolucas75 at mail.ru  Sat Aug 28 21:19:56 2021
From: mariolucas75 at mail.ru (=?UTF-8?B?TWFyaW8gTHVjYXM=?=)
Date: Sun, 29 Aug 2021 00:19:56 +0300
Subject: =?UTF-8?B?Q29ubmVjdCBjZWxsIHBob25lIHRvIHJlYWwgR1NNIG5ldHdvcmsgdGhyb3Vn?=
 =?UTF-8?B?aCBPcGVuQlRT?=
Message-ID: <1630185596.729267813@f492.i.mail.ru>


?
Dear Osmocom society,
?
I am trying to connect a cell phone (lets call it phone #1) through OpenBTS to real GSM network?
To do so i have to introduce a osmocomBB phone?which will be connected to my linux machine which runs OpenBTS
So kind of it will be a following structure:
Phone #1 ??OpenBTS ??OsmocomBB phone ??real GSM netwok.
No my goal is to have OpenBTS and OsmocomBB phone to talk to each other??for example authentication parameters which to be exchanged between phone #1 and real?network to happen through the chain described above ?.
?
Has this case been or something like this done before ? Or are you aware of any cases when OpenBTS and OsmocomBB phone exchange data?
?
Thank you very much
?
?
--
Mario Lucas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20210829/9ef35447/attachment.htm>