Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-02-28T00:28:49ZOpen Source Mobile Communications
Redmine OsmoBSC - Bug #6378 (New): Ericsson DUG 20 rejects SI2quaterhttps://osmocom.org/issues/63782024-02-28T00:28:49Zkeith
<p>Sending SI2quater to the DUG20 results in</p>
<pre>
ERROR REPORT (cause=Radio Resource not available [ 21 01 80 ])
</pre>
<p>For what it may be worth, the SI and the error are in the attached pcap.</p>
<p>Maybe the BTS software version I have simply does not support it?</p> OsmoPCU - Bug #6179 (Feedback): ASSERT in st_wait_releasehttps://osmocom.org/issues/61792023-09-14T19:25:37Zkeith
<p>osmo-pcu from the recent release:</p>
<p>Here's a backtrace (from sysmobts with osmo-pcu-dbg and libosmocore-dbg symbols installed)<br /><pre>
Assert failed 0 ../../git/src/tbf_dl_fsm.c:309
backtrace() returned 0 addresses
Program received signal SIGABRT, Aborted.
0x432dcf74 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x432dcf74 in raise () from /lib/libc.so.6
#1 0x432de358 in abort () from /lib/libc.so.6
#2 0xb6eb38d4 in osmo_panic_default (args=..., fmt=0x0)
at /usr/src/debug/libosmocore/1.9.0+gitrAUTOINC+aca2c724ae-r2.18.0/git/src/core/panic.c:45
#3 osmo_panic (fmt=0x66fd4 "Assert failed %s %s:%d\n")
at /usr/src/debug/libosmocore/1.9.0+gitrAUTOINC+aca2c724ae-r2.18.0/git/src/core/panic.c:80
#4 0x00040f5c in st_wait_release (fi=<optimized out>, event=<optimized out>, data=<optimized out>)
at /usr/src/debug/osmo-pcu/1.3.0+gitAUTOINC+3ef173b980-r0.18/git/src/tbf_dl_fsm.c:309
#5 0xb6ea7824 in _osmo_fsm_inst_dispatch (fi=0x15e420, event=0, event@entry=3, data=data@entry=0x0, file=0x70098 "../../git/src/tbf.cpp",
line=line@entry=540) at /usr/src/debug/libosmocore/1.9.0+gitrAUTOINC+aca2c724ae-r2.18.0/git/src/core/fsm.c:875
#6 0x000356cc in gprs_rlcmac_tbf::poll_timeout (this=0x162920, pdch=0x154e64, poll_fn=223816, reason=<optimized out>)
at /usr/src/debug/osmo-pcu/1.3.0+gitAUTOINC+3ef173b980-r0.18/git/src/tbf.cpp:540
#7 0x0003585c in tbf_poll_timeout (tbf=<optimized out>, pdch=<optimized out>, poll_fn=<optimized out>, reason=<optimized out>)
at /usr/src/debug/osmo-pcu/1.3.0+gitAUTOINC+3ef173b980-r0.18/git/src/tbf.cpp:828
#8 0x0004cdf8 in pdch_ulc_expire_fn (ulc=0x1549d0, fn=223816, fn@entry=1395928)
at /usr/src/debug/osmo-pcu/1.3.0+gitAUTOINC+3ef173b980-r0.18/git/src/pdch_ul_controller.c:331
#9 0x00026a70 in pcu_rx_data_ind_pdtch (bts=bts@entry=0x154cd8, pdch=0x154e64, data=0x0, len=<optimized out>, fn=223816, meas=0xbefffb80,
meas@entry=0xbefffb78) at /usr/src/debug/osmo-pcu/1.3.0+gitAUTOINC+3ef173b980-r0.18/git/src/pcu_l1_if.cpp:396
#10 0x00015d70 in handle_ph_data_ind (fl1h=0x15de28, fl1h=0x15de28, l1p_msg=0x202ef8, data_ind=0x202fc0)
at /usr/src/debug/osmo-pcu/1.3.0+gitAUTOINC+3ef173b980-r0.18/git/src/osmo-bts-sysmo/sysmo_l1_if.c:220
</pre></p>
<p>It's always happening at line 540 in tbf.cpp:<br /><pre><code class="c syntaxhl"><span class="n">osmo_fsm_inst_dispatch</span><span class="p">(</span><span class="n">this</span><span class="o">-></span><span class="n">state_fi</span><span class="p">,</span> <span class="n">TBF_EV_MAX_N3105</span><span class="p">,</span> <span class="nb">NULL</span><span class="p">);</span>
</code></pre></p>
<p>Logs are messy, there's a lot going on.<br />Maybe attached log (at INFO) helps.</p> OsmoBSC - Bug #5986 (New): PAGING impossible until CCCH LOAD IND is received from the BTShttps://osmocom.org/issues/59862023-03-29T20:10:54Zkeith
<p>I noticed this with the RBS unit, that does not seem to be sending CCCH LOAD ind.</p>
<p>At <a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/osmo-bsc/src/branch/master/src/osmo-bsc/paging.c#L249">https://gitea.osmocom.org/cellular-infrastructure/osmo-bsc/src/branch/master/src/osmo-bsc/paging.c#L249</a> we fully delay all paging requests and log "Paging delayed: waiting for available slots at BTS" until such a LOAD ind has been received.</p>
<p>Maybe this check should be removed/relaxed if the vty param "paging load -1" is set?</p>
<p>Maybe the check for (bts_pag_st->free_chans_need != -1) and the above can be reordered?</p> OsmoBTS - Bug #5944 (In Progress): DTXu + AMR on TCH/H appears to be not usable on osmo-bts-sysmohttps://osmocom.org/issues/59442023-03-11T05:12:25Zkeith
<p>The problem is that conversation is uncomfortable bordering on impossible due to random lost words and cut off of initial speech after silence periods.</p>
<p>I've been experimenting sending the AMR RTP stream into decoders or SIP endpoints, (all using libopencore-amr) and also, without using any external MNCC, thereby only having the the audio stream pass through osmo-mgw before going to a B-leg MS. I observe the problem in all cases.</p>
<p>I've put quite some hours into this so far, without being able to achieve any improvements. Rather than leave it all fade from memory, I'll just make a quick note of the main points of what was observed:</p>
<p>It all seems fine as long as you have sequences of speech followed by SID_FIRST_P1, SID_FIRST_P2, then eventually an ONSET, followed by speech frames... rinse and repeat. This is fine.</p>
<p>When it goes wrong is if you have a situation where (because of the timing of the VAD) you get either a SID_FIRST_INH or a SID_UPDATE_INH, in these cases, what I've observed is that after the SID_UPDATE_INH, the L1 does not seem to be sending us any Speech frames, (just TCH/H with no payload) even though I am speaking. Eventually, there will be an ONSET followed by speech frames.</p>
<p>I may be wrong, but I don't think there's anything that osmo-bts is doing or can do about this, so I'm pretty convinced at this point that is is an L1 problem, and therefore will not (cannot?) be fixed. I'm aware that there is code in libosmocore to deal with all this weird interleaving and such that goes on in AMR DTX, but we don't use any of it in osmo-bts-sysmo.</p>
<p>The pcap comes from an osmo-bts with some modifications to logging and RTP marking, (ignore the BAD AMR frames following ONSET - that's a hack but not relevant) the main point would be to observe what is happening around and after packet no 1482 - Note all that PH-DATA.ind TCH/H with no payload. I am speaking then.</p> OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://osmocom.org/issues/58952023-02-07T03:11:09Zkeith
<p>Writing this up now while it's a bit fresh...</p>
<p>I have spent the last 12 hours or so working with people on site to try to track down these problems:</p>
<p>Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)</p>
<p>Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.</p>
<p>However, today I discovered the extent of how bad this was on local MS to MS calls.</p>
<p>After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.</p>
<p>Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.</p>
<p>Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.</p>
<p>So what to do? Well note it at least. I don't have another lc15 to test on. <br />Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.</p>
<p>There's the chance that this was fixed since 1.4.0 or in another lib.</p>
<p><em>Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.</em></p> OsmoHLR - Feature #5865 (New): Automate selection of LU Reject Causehttps://osmocom.org/issues/58652023-01-20T13:59:07Zkeith
<p>There is some suggestion in <a class="external" href="https://gerrit.osmocom.org/c/osmo-hlr/+/16808">https://gerrit.osmocom.org/c/osmo-hlr/+/16808</a> that osmo-hlr could use some criteria to decide what cause/reason to send to the GSUP client when rejecting a Location/Routing Update</p>
<p>Possibly, sending "IMSI Unknown in HLR" is wrong when the SIM is foreign to our network.</p>
<p>We could have a regex config option to let osmo-hlr know what is "our" SIM or not. Or maybe a GSUP client like osmo-msc can comunicate MNC-MCC info from the MSC network config over GSUP? I'm not familiar with GSUP.</p> OsmoPCU - Feature #5833 (New): A "meas-feed" for osmo-pcuhttps://osmocom.org/issues/58332022-12-18T18:32:10Zkeith
<p>It might be interesting to observe real-time display of some parameters available from the PCU;<br />such as:</p>
<ul>
<li>RSSI </li>
<li>Link Quality</li>
<li>Coding Scheme</li>
<li>DL Throughput.</li>
</ul>
<p>This could be integrated into the "meas web" app<sup><a href="#fn1">1</a></sup>.</p>
<p>[1] <a class="external" href="https://gitlab.tic-ac.org/keith/meas_web">https://gitlab.tic-ac.org/keith/meas_web</a></p> OsmoBSC - Feature #5740 (New): Disallow unworkable AMR modes.https://osmocom.org/issues/57402022-11-03T19:21:01Zkeith
<p>This is fairly trivial, but as a note to self, two things.</p>
<p>1) establish exactly what's wrong and make it not possible to configure osmo-bsc like this?<br />2) Can "RADIO INTERFACE MESSAGE FAILURE" be any more sepcific? (LOG / Tx to MSC)</p>
<p>config:<br /><pre>
amr tch-h modes 2 3 4 5
amr tch-h threshold ms 32 24 32
amr tch-h hysteresis ms 8 4 4
amr tch-h threshold bts 32 24 32
amr tch-h hysteresis bts 8 4 4
amr tch-h start-mode 3
</pre></p>
<pre>
Radio Signalling Link (RSL)
GSM A-I/F DTAP - Assignment Command
Protocol Discriminator: Radio Resources Management messages (6)
DTAP Radio Resources Management Message Type: Assignment Command (0x2e)
Channel Description 2 - Description of the First Channel, after time
Power Command
Channel Mode - Mode of the First Channel(Channel Set 1)
Element ID: 0x63
Channel Mode: speech full rate or half rate version 3(FR AMR or HR AMR) (65)
MultiRate configuration
Element ID: 0x03
Length: 6
001. .... = Multirate speech version: Adaptive Multirate speech version 1 (1)
...0 .... = NSCB: Noise Suppression Control Bit: Noise Suppression can be used (default) (0)
.... 1... = ICMI: Initial Codec Mode Indicator: The initial codec mode is defined by the Start Mode field (1)
.... ..10 = Start Mode: 2
0... .... = 12,2 kbit/s codec rate: is not part of the subset
.0.. .... = 10,2 kbit/s codec rate: is not part of the subset
..1. .... = 7,95 kbit/s codec rate: is part of the subset
...1 .... = 7,40 kbit/s codec rate: is part of the subset
.... 1... = 6,70 kbit/s codec rate: is part of the subset
.... .1.. = 5,90 kbit/s codec rate: is part of the subset
.... ..0. = 5,15 kbit/s codec rate: is not part of the subset
.... ...0 = 4,75 kbit/s codec rate: is not part of the subset
..10 0000 = AMR Threshold: 16.0 dB (32)
1000 .... = AMR Hysteresis: 4.0 dB (8)
.... 0110 00.. .... = AMR Threshold: 12.0 dB (24)
..01 00.. = AMR Hysteresis: 2.0 dB (4)
.... ..10 0000 .... = AMR Threshold: 16.0 dB (32)
.... 0100 = AMR Hysteresis: 2.0 dB (4)
</pre>
<pre>
GSM A-I/F DTAP - Assignment Failure
Protocol Discriminator: Radio Resources Management messages (6)
DTAP Radio Resources Management Message Type: Assignment Failure (0x2f)
RR Cause
RR cause value: Channel mode unacceptable (9)
</pre>
<pre>
20221103200919685 DCHAN DEBUG lchan(3-0-1-SDCCH8-0)[0x55b6c3e79310]{ESTABLISHED}: (type=SDCCH) SAPI=0 DATA INDICATION (abis_rsl.c:2528)
20221103200919685 DCHAN DEBUG lchan(3-0-1-SDCCH8-0)[0x55b6c3e79310]{ESTABLISHED}: (type=SDCCH) Rx ASSIGNMENT FAILURE (gsm_04_08_rr.c:985)
20221103200919685 DAS DEBUG assignment(msc0-conn16_subscr-IMSI-334070000000890-TMSI-0x11dc2226_3-0-2-TCH_H-0)[0x55b6c3e91b40]{WAIT_RR_ASS_COMPLETE}: Received Event ASSIGNMENT_EV_RR_ASSIGNMENT_FAIL (gsm_04_08_rr.c:1031)
20221103200919685 DAS DEBUG assignment(msc0-conn16_subscr-IMSI-334070000000890-TMSI-0x11dc2226_3-0-2-TCH_H-0)[0x55b6c3e91b40]{WAIT_RR_ASS_COMPLETE}: (bts=3,trx=0,ts=2,ss=0) incrementing rate counter: assignment:failed Received Assignment Failure message (assignment_fsm.c:738)
20221103200919685 DAS DEBUG assignment(msc0-conn16_subscr-IMSI-334070000000890-TMSI-0x11dc2226_3-0-2-TCH_H-0)[0x55b6c3e91b40]{WAIT_RR_ASS_COMPLETE}: (bts=3,trx=0,ts=2,ss=0) incrementing rate counter: bts3 assignment:failed_speech Received Assignment Failure message on speech lchan (assignment_fsm.c:738)
20221103200919685 DAS ERROR assignment(msc0-conn16_subscr-IMSI-334070000000890-TMSI-0x11dc2226_3-0-2-TCH_H-0)[0x55b6c3e91b40]{WAIT_RR_ASS_COMPLETE}: (bts=3,trx=0,ts=2,ss=0) Assignment failed in state WAIT_RR_ASS_COMPLETE, cause RADIO INTERFACE MESSAGE FAILURE: Rx RR Assignment Failure (assignment_fsm.c:739)
20221103200919685 DAS DEBUG assignment(msc0-conn16_subscr-IMSI-334070000000890-TMSI-0x11dc2226_3-0-2-TCH_H-0)[0x55b6c3e91b40]{WAIT_RR_ASS_COMPLETE}: (bts=3,trx=0,ts=2,ss=0) result rate counter already recorded, NOT counting as: assignment:error Assignment failed for other reason (assignment_fsm.c:739)
20221103200919685 DMSC INFO Tx MSC: BSSMAP: ASSIGNMENT FAIL (osmo_bsc_sigtran.c:380)
</pre> OsmoMSC - Bug #5491 (New): MT CSFB calls fail (only) first time after Airplane mode toggle (proba...https://osmocom.org/issues/54912022-03-19T02:49:20Zkeith
<p>To reproduce:</p>
<p>With working EUTRAN and GERAN networks, toggle airplane mode. Phone (re)-ATTACHes to LTE network.</p>
<p>Call the phone:</p>
<p>In osmo-msc: (i've attached the entire debug log)</p>
<pre>
20220319023547480 DMM DEBUG msc_a(TMSI-0x2F655780:GERAN-A-50:LU)[0x55b8e91359b0]{MSC_A_ST_VALIDATE_L3}: LOCATION UPDATING REQUEST: MI=TMSI-0x2F655780 LU-type=NORMAL (gsm_04_
20220319023547480 DMM DEBUG msc_a(TMSI-0x2F655780:GERAN-A-50:LU)[0x55b8e91359b0]{MSC_A_ST_VALIDATE_L3}: USIM: old LAI: 334-07-101 (gsm_04_08.c:407)
20220319023547480 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 for MNCC: establish call: Paging Response action (expired) (paging.c:154)
20220319023547480 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 for MNCC: establish call: Removing Paging Request (paging.c:127)
20220319023547480 DCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 callref-0x13ad tid-255) Paging expired (gsm_04_08_cc.c:339)
20220319023547480 DMNCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 callref-0x13ad tid-255) tx MNCC_REL_IND (gsm_04_08_cc.c:237)
20220319023547480 DCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 callref-0x0 tid-255) Freeing transaction (transaction.c:230)
</pre>
<p>After this 1st try, the subsequent try succeeds:</p>
<pre>
20220319024811027 DCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 callref-0x13af tid-255) New transaction (transaction.c:218)
20220319024811027 DMNCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 callref-0x13af tid-255) rx MNCC_SETUP_REQ (gsm_04_08_cc.c:1979)
20220319024811027 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 for MNCC: establish call: Starting paging (paging.c:101)
20220319024814102 DMM DEBUG Tx AUTH REQ (rand = 07e7f2e89f5782be2bac726d7d90914a) (gsm_04_08.c:642)
20220319024814102 DMM DEBUG AUTH REQ (autn = e6ab0ad9e6a7000050ffb868d2a25996) (gsm_04_08.c:644)
20220319024815042 DMM DEBUG msc_a(IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684:GERAN-A-52:PAGING_RESP)[0x55b8e913d250]{MSC_A_ST_AUTH_CIPH}: MM UMTS AUTHENTICATION RESPONSE (res = 6ce1b1df36c7c61f) (gsm_04_08.c:1119)
20220319024815749 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 for MNCC: establish call: Paging Response action (success) (paging.c:154)
20220319024815749 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 for MNCC: establish call: Removing Paging Request (paging.c:127)
20220319024815749 DCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 callref-0x13af tid-255) Paging succeeded (gsm_04_08_cc.c:316)
</pre>
<p>There's a difference in show subscriber cache after an ATTACH via SGS as opposed to a complete LUR on GERAN (we have auth data):</p>
<pre>
show subscriber cache
Subscriber #00:
MSISDN: 12345174747
LAC / cell ID: 101 / 100
RAN type: EUTRAN-SGs
IMSI: 334070000000968
TMSI: 1E460BB7
IMEI: 35729207588080
IMEISV: 3572920758808001
Flags:
IMSI detached: false
Conf. by radio contact: true
Subscr. data conf. by HLR: true
Location conf. in HLR: true
Subscriber dormant: false
Received cancel location: false
MS not reachable: false
LA allowed: true
A3A8 last tuple (used 1 times):
seq # : 4
RAND : 17 8a 18 c2 62 8e 85 a5 fe a1 1b 03 c2 51 37 9a
SRES : a0 10 84 9a
Kc : 01 1d 45 1b 6c 47 74 00
Expires: never
Paging: not paging for 0 requests
SGs-state: SGs-ASSOCIATED
SGs-MME: mmec01.mmegi0002.mme.epc.mnc007.mcc334.3gppnetwork.org
Use count total: 1
Use count: 1 (attached)
</pre>
<pre>
show subscriber cache
Subscriber #00:
MSISDN: 12345174747
LAC / cell ID: 101 / 0
RAN type: EUTRAN-SGs
IMSI: 334070000000968
TMSI: 2F655780
Flags:
IMSI detached: false
Conf. by radio contact: true
Subscr. data conf. by HLR: true
Location conf. in HLR: true
Subscriber dormant: false
Received cancel location: false
MS not reachable: false
LA allowed: true
Expires: never
Paging: not paging for 0 requests
SGs-state: SGs-ASSOCIATED
SGs-MME: mmec01.mmegi0002.mme.epc.mnc007.mcc334.3gppnetwork.org
Use count total: 1
Use count: 1 (attached)
</pre>
<p>Assigning to myself; I do intend to fix it.</p>
<p>Would appreciate confirmation all the same from anybody else who has a working setup, or even some static analysis by those more familiar with this code.</p> OsmoBSC - Bug #5246 (New): sigsegv in bts_count_free_ts()https://osmocom.org/issues/52462021-10-03T20:08:51Zkeith
<p>Just noting this quickly, I'll need to come back to it.</p>
<pre>
Program received signal SIGSEGV, Segmentation fault.
0x00005555555b5535 in bts_count_free_ts (bts=0x0, pchan=GSM_PCHAN_TCH_F) at bts.c:725
725 llist_for_each_entry(trx, &bts->trx_list, list)
(gdb) bt
#0 0x00005555555b5535 in bts_count_free_ts (bts=0x0, pchan=GSM_PCHAN_TCH_F)
at bts.c:725
#1 0x00005555555dd4bc in candidate_set_free_tch (c=0x7fffffff7a50)
at handover_decision_2.c:1026
#2 0x00005555555ddb0e in collect_handover_candidate (lchan=0x7ffff7fd1ef0,
nmp=0x7ffff7fd205c, clist=0x7fffffff87e0, candidates=0x7fffffff87dc,
include_weaker_rxlev=false, rxlev_current=53, neighbors_count=0x7fffffff8764)
at handover_decision_2.c:1141
#3 0x00005555555de410 in collect_candidates_for_lchan (lchan=0x7ffff7fd1ef0,
clist=0x7fffffff87e0, candidates=0x7fffffff87dc, _rxlev_current=0x7fffffffce60,
include_weaker_rxlev=false) at handover_decision_2.c:1219
#4 0x00005555555de569 in find_alternative_lchan (lchan=0x7ffff7fd1ef0,
include_weaker_rxlev=false, request_upgrade_to_tch_f=false)
at handover_decision_2.c:1298
#5 0x00005555555e0729 in on_measurement_report (mr=0x7ffff7fd2230)
at handover_decision_2.c:1572
#6 0x00005555555f0f05 in ho_meas_rep (mr=0x7ffff7fd2230) at handover_logic.c:95
#7 0x00005555555f3242 in ho_logic_sig_cb (subsys=3, signal=8, handler_data=0x0,
signal_data=0x7fffffffd060) at handover_logic.c:316
</pre> OsmoBSC - Feature #5106 (Feedback): Watchdog that would try to un-BORKE BORKen timeslotshttps://osmocom.org/issues/51062021-04-04T20:21:26Zkeith
<p>In <a class="issue tracker-1 status-3 priority-2 priority-default closed behind-schedule" title="Bug: rbs2000 ALL BORKEN Channels (Resolved)" href="https://osmocom.org/issues/5096">#5096</a> that discussed lchans ending up borken on a busy ericsson bts:</p>
<p>"What would probably make sense is some kind of watchdog that would try to un-BORKE BORKen timeslots after a certain time. This can be done by activating a broken sub-slot and releasing it immediately. If the BTS still refuses to activate it, then it's completely BORKen and the second attempt to un-BORKE can be postponed further."</p>
<p>(<a class="external" href="https://osmocom.org/issues/5096#note-12">https://osmocom.org/issues/5096#note-12</a>)</p> OsmoBSC - Feature #4922 (In Progress): Implement MS Power Controlhttps://osmocom.org/issues/49222020-12-24T17:17:30Zkeith
<p>For a BTS that does not implement MS uplink power control, such as the RBS6k, we need to have the BSC process MEASUREMENT RESULT messages and send MS POWER CONTROL messages.</p> OsmoPCU - Bug #4856 (Feedback): PCU is running but has no NS connection and does not retry.https://osmocom.org/issues/48562020-11-09T19:00:47Zkeith
<p>It has been noticed that at times osmo-bts, osmo-pcu are up and running on a sysmobts, GPRS is configured but there is no NS connection to the SGSN.</p>
<p>What I don't have about this:</p>
<ul>
<li>A method to reproduce.</li>
<li>logs leading up to failure.</li>
<li>I don't know if the NS was up and failed, or if it never came up on pcu startup.</li>
<li>osmo-bts and pcu are not current master, if fact there are some various versions installed.. (BSC is nitb)</li>
</ul>
<p>As I am writing this, I have one case of running osmo-pcu with no connection.</p>
<p>pcu is not logging ANYTHING. (logging level set-all debug) <br />version: OsmoPCU 0.8.0.152-b90d<br />show stats: all counters are zero.</p>
<p>ntib shows all of the "states" <strong>Oper 'Enabled', Admin 'Unlocked', Avail 'OK'</strong><br />as does the associated <del>pcu</del> osmo-bts</p>
<p>also, shows PCU connected:<br /><pre>
OpenBSC# show bts 2
BTS 2 is of sysmobts type in band GSM850, has CI 2 LAC 269, BSIC 63 (NCC=7, BCC=7) and 1 TRX
Description: (null)
PCU version 0.8.0.152-b90d connected
</pre></p>
<p>To possibly simplify a little: <br />It seems to be that the PCU is in a states where it "knows" that the NS is down<br /><pre>
OsmoPCU# show ns
Encapsulation NS-UDP-IP Local IP: 0.0.0.0, UDP Port: 0
</pre></p>
<p>yet it it not trying to bring it up.<br />Maybe the bts did not inform the PCU of the config?</p>
<p>show bts statistics: also all counters at ZERO.<br />all rate-counters are zero.</p>
<p>really looks like it was never initialised.</p>
<p>Maybe needless to say, but worth adding - systemctl restart osmo-pcu restores service.</p> Cellular Network Infrastructure - Feature #3142 (New): Further simplification of "NITB like" setupshttps://osmocom.org/issues/31422018-04-05T20:09:38Zlaforge
<p>Running the post-NITB network is quite a lot more complex than the old code.</p>
<p>There are some ideas on how to make it simpler to run small, self-contained networks while removing some complexity</p>
<ul>
<li>I was also wondering if we should spend time on "MGW-less operation". In theory, you only need OsmoMGW if you have no IP-level routing between your Abis / A / core network [like any decent network operator for security reasons]. But then, if you run everything on one machine, and don't need/want transcoding, and have transparent routing between all components, we could do without the MGW.</li>
</ul>
<ul>
<li>stp-less operation should also be possible (but make configuration actually more complicated), as both the "ASP" (client) and "SG" (server) role are inside libosmo-sigtran, and hence the server could run inside the MSC without the need of an external stp (osmo-stp is just a thin wrapper with vty around libosmo-sigtran)</li>
</ul>
<p>Let's keep this as a reminder and create sub-tasks as ideas materialize more</p> OsmoMSC - Feature #2487 (Stalled): MSC side of LCLS (local call local switching) as per the 3GPP ...https://osmocom.org/issues/24872017-09-03T17:37:40Zlaforge
<p>3GPP LCLS allows the media stream of a call to remain locally at the BTS, if both legs of a call are within the same BTS. We should implement this in OsmoMSC, if not only to test the OsmoBSC side which we want to implement, too.</p> OsmoMSC - Feature #1974 (New): VLR: high water mark on subscriber storagehttps://osmocom.org/issues/19742017-03-08T14:54:50Zneelsnhofmeyr@sysmocom.de
<p>In libvlr, we (will) keep every subscriber in RAM as long as it still has valid auth tuples (3GPP TS 33.102 Annex C.2.3).<br />Most subscribers will still have auth tuples left upon detaching, so we would store <strong>all</strong> subscribers.</p>
<p>Implement a configurable way of limiting the number of subscribers kept in RAM, e.g. a fixed max size.<br />If this is reached, discard those subscribers that have been inactive for the longest time first.</p> OsmoMSC - Feature #1973 (New): VLR: efficient subscriber lookuphttps://osmocom.org/issues/19732017-03-08T14:52:10Zneelsnhofmeyr@sysmocom.de
<p>In libvlr, we (will) keep every subscriber in RAM as long as it still has valid auth tuples (3GPP TS 33.102 Annex C.2.3).<br />Most subscribers will still have auth tuples left upon detaching, so we would store <strong>all</strong> subscribers.<br />Storing numerous subscribers in a linear list is inefficient, implement a hash table for faster access times.</p> OsmoBTS - Feature #1755 (New): osmo-bts-sysmo L1: unify hLayer3 handlinghttps://osmocom.org/issues/17552016-06-16T11:27:40Zneelsnhofmeyr@sysmocom.de
<p>In <a class="external" href="https://gerrit.osmocom.org/264">https://gerrit.osmocom.org/264</a> , some hLayer3 use was added.<br />However, some of the messages were already using hLayer3.</p>
<p>After the patch, the prim_init() sets a hLayer3 which is overwritten<br />shortly after that, so the other functionality is not affected by this patch.</p>
<p>Some functions to generate hLayer3 for a timeslot and similar already existed,<br />and also to retrieve a timeslot and similar back from a hLayer3 handle.</p>
<p>And also, the other hLayer3 functions use a "magic" byte<br />(like the most significant byte always set to 0xbb).</p>
<p>So in fact, we should have rejected this patch, and we should follow up with<br />a merger of my hLayer3 to the existing hLayer3 infrastructure.<br />The priority is low though, since no harm is done.</p>
<p>See:</p>
<ul>
<li>osmo-bts/src/osmo-bts-sysmo/oml.c
<ul>
<li>mph_send_activate_req()</li>
<li>mph_send_config_logchpar()</li>
<li>mph_send_config_ciphering()</li>
<li>mph_send_deactivate_req()</li>
</ul></li>
</ul> OsmoBTS - Feature #1576 (New): consider using hLayer2 as a pointer storagehttps://osmocom.org/issues/15762016-02-23T15:38:30Zlaforge
<p>This would speed up the l1if_hLayer_to_lchan lookup. Not sure if it's worth the extra risk.</p>