Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-20T21:47:23ZOpen Source Mobile Communications
Redmine E1/T1 Hardware Interface (including icE1usb) - Support #6412 (New): No alignmenthttps://osmocom.org/issues/64122024-03-20T21:47:23Zpfassberg
<p>I'm testing icE1usb to connect a ISDN PBX to a switch partly over SDH.<br /><pre>
SS7/ISDN Switch - (STM-1) - ADM - (E1) - icE1usb - (IP) - icE1usb - (E1) - PABX
</pre></p>
<p>In the PABX side I have no problems, but between the ADM and the icE1usb I have problem to get the icE1usb aligned.</p>
<p>If I use a loopback cable I can get the ADM and the icE1usb aligned. But when I connect them only the ADM get aligned, never the icE1usb. The icE1usb don't act at all. The green LED keeps flashing and nothing in the logs or stat.</p>
<p>If I connect a Cisco modem pool to the same ADM port it immediately get aligned. I have MGWs and other stuff connected to the same ADM with no problems.</p>
<p>I've measured the voltage and find roughly 4 V Vp-p from icE1usb and 5 V Vp-p from the ADM.</p>
<p>I do not use CRC4 but I can't find any CRC4 settings in osmo-e1d config.</p>
<p>Any clues about what is going on and how to debug this?</p>
<p>// Peter</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> OCTOI - Osmocom Community TDM over IP - Bug #5883 (New): GPS sync sometimes goes to hold overhttps://osmocom.org/issues/58832023-01-30T00:06:12Ztnt
<p>Last occurrences :</p>
<p>Sun Nov 27th 01:00<br />Thu Dec 6th 21:46 <br />Sun Dec 18th 01:00 <br />Wed Dec 28th 13:36<br />Sun Jan 29th 01:00</p>
<p>So at least 3 of them happened on Sundays, at 1 am local time (so 00:00 UTC), which also seems to correspond to the moment the GPS resets its 'ppr` messages counter to 0 ...</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> E1/T1 Hardware Interface (including icE1usb) - Feature #5710 (New): rs422: Merge as much of the g...https://osmocom.org/issues/57102022-10-13T18:53:21Ztnt
<p>Currently the gateware for the RS422 mode is another branch. It's just too big to have dual channel + hw support for it in the same build.</p>
<p>Either try to make it a build option, or reduce size of the gateware to make it fit.<br />ATM we create a whole different UART but technically we could just use the GPS uart and re-route the IO since the on-board GPS isn't used when rs422 mode is used.</p>
<p>This wouldn't support a possible future GPS 02/03 emulation mode but that's a problem for the future. (Although thinking about it, it could actually since after init we never TX to the onboard GPS and we never RX anything on the rs422 ... so we could have the same uart split: rx from onboard gps and tx to the RBS ... we just need to keep the onboard gps at 9600 or support different tx/rx baudrates)</p> E1/T1 Hardware Interface (including icE1usb) - Feature #5709 (New): rs422: Merge as much of the f...https://osmocom.org/issues/57092022-10-13T18:49:19Ztnt
<p>"Pluggable" GPS implementation should be possible.</p>
<p>The extensions boards have an EEPROM to allow run-time discovery and the firmware code size is not an issue, we have 64k and we're using 20.5k ATM so having the GPS03 code in there isn't going to make much of a difference.</p> E1/T1 Hardware Interface (including icE1usb) - Bug #5708 (New): rs422: Support runtime re-init of...https://osmocom.org/issues/57082022-10-13T18:46:17Ztnt
<p>Currently if the GPS receiver side doesn't have power, init will fail and never recover without a reboot.</p>
<p>This is because without power on that side, we can't talk to the I2C IO expander on the isolated side to initialize it and set up the RS422 transceiver ...</p>
<p>Solution is that if we haven't seen NMEA messages in a few seconds, try to re-init the I2C IO expander (default state on reset/power loss is everything disabled to be safe).</p>
<p>One thing to pay attention to is that I2C is slow. And the current I2C driver code is blocking, so we'd need to check the init sequence isn't too long and doesn't block the main loop processing for too long which would cause USB over/underflows ...</p> E1/T1 Hardware Interface (including icE1usb) - Bug #5490 (Feedback): ISO IN urb sometimes complet...https://osmocom.org/issues/54902022-03-14T08:22:23Zlaforge
<p>This is happening frequently at <a class="user active" href="https://osmocom.org/users/739890">gruetzkopf</a>:<br /><pre>
Assert failed size % 32 == 0 mux_demux.c:419
</pre></p>
<p>This means that a non-modulo-32 length (plus 5 byte header) was received in an ISO IN URB.</p>
<pre>
22:00 <@gruetzkopf> <0001> mux_demux.c:421 (I0:L0) Transfer cut short, size was 251 bytes
23:58 <@gruetzkopf> just so i don't forget: i've also seen 253 and 252 by now
</pre>
<p>So this means that instead of 256 (+4) we've seen 251-253 (+4) byte transfer length.</p>
<p>I've checked the firmware, an I don't see any way how the firmware could do something wrong here: It uses <code>(n * 32) + 4)</code> as length, whic hcan never be one of those odd values.</p>
<p>On the osmo-e1d side, we are always checking for LIBUSB_TRANSFER_COMPLETED state, so both the transfer/urb, as well as the individual packets have LIBUSB_TRANSFER_COMPLETED before passing them higher up to the mux_demux code which is asserting here.</p>
<p>So I guess the underlying question is: Is this a kernel/libusb bug? Is it legal for ISO IN packets to complete with a length less than what was submitted?</p>
<p>If this is legal, then the next question si why it it is happening.</p>
<p>We can of course plaster around the issue and substitute the missing data with 0xff or something, creating various bit errors, rathe than asserting.</p> E1/T1 Hardware Interface (including icE1usb) - Feature #4910 (New): Automatically set the A / ala...https://osmocom.org/issues/49102020-12-16T20:20:22Zlaforge
<p>At least according to one of my German retronetworking books on PDH it is stated that an E1 interface must set the A[larm] bit in TS0 if no received signal is detected.</p>
<p>I expect we don't do that yet as we have no real concept of LOS.</p>
<p>Relying on the host software to insert that A bit is not really a good idea, as the host has the least idea of what's happening on the physical layer.</p>
<p>So I would guess, similar to the way how we automatically can generate the E bits in case of Rx CRC errors, it would be good to generate the A bits based on whether or not we see incoming Rx clock cycles.</p> OsmoTRX - Bug #3222 (Stalled): include (tested) example config files for usrp1, uhd/b200 as well ...https://osmocom.org/issues/32222018-04-28T14:50:47Zlaforge
<p>Let's make sure we ship example configs for the various SDR hardware, just like we do in other osmocom projects that use vty / config files.</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> OsmoTRX - Feature #3054 (Stalled): Extended (11-bit) RACH support in OsmoTRXhttps://osmocom.org/issues/30542018-03-10T07:22:35Zlaforge
<p>OsmoTRX is currently only correlating with one of the three RACH sync sequences indicated in TS 05.02 5.2.7. We need to define TS1+TS2 as well as correlated against thosee during RACH detection</p>
<pre>
const BitVector GSM::gRACHSynchSequence("01001011011111111001100110101010001111000");
+const BitVector GSM::gRACHSynchSequenceTS1("01010100111110001000011000101111001001101"); /* EGPRS with 8PSK in uplink */
+const BitVector GSM::gRACHSynchSequenceTS2("11101111001001110101011000001101101110111"); /* EGPRS without 8PSK in uplink */
</pre> 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> OsmocomBB - Bug #1458 (New): AGC broken (strong cell cannot be syncedhttps://osmocom.org/issues/14582016-02-19T22:48:42Zlaforge
<p>There seems to be a problem when trying to sync to particularly strong cells, as we overload the input of the ADC.</p>
<p>As we're doing power measurements anyway, we need to use the received power level as input to the SCH and FCCH task and not start those with some default power level</p> Miscellaneous Projects - Bug #64 (New): osmo-bts-amp: 2.2uF capacitors next to PA need to be 0603...https://osmocom.org/issues/642016-02-19T22:47:33Zlaforge
<p>0805 capacitors are typically higher thant the PA module and would thus interfere with mounting it against a heatsink. Thus, we're using 0603 capacitors in 2.2uF, and the footprint can (and should) be shrinked from the current 0805</p>