Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-02-07T03:11:09ZOpen Source Mobile Communications
Redmine 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> Cellular Network Infrastructure - Feature #5771 (New): series of presentations about the invididu...https://osmocom.org/issues/57712022-11-14T19:25:57Zlaforge
<p>Most of the talks we ever gave on setting up and running the Osmocom CNI are ages old and hence relatively outdated.</p>
<p>Given the number of network elements and the relate complexity, I think we should consider doing a talk on each of them. The talk doesn't have to be of a particular length, so some network elements might have shorter or longer presentations.</p>
<p>Looking at the checklist below, we already have 14 items. Covering this in OsmoDevCall is not an option, it would take too long (14 months if no other topic would be covered in between). So it is going to be on a separate schedule.</p>
<p>I would consider each presentation should then be prominently linked from the redmine project page of each network element, next to the user manual.</p>
<p>We may of course still be publishing those via the OsmoDevCall "event" on media.ccc.de, so all videos are in one location.</p>
<p>I think every presentation should start with a quick picture at the overal diagram of netwokr elements, describe the surrounding elements and their interfaces to then look in detail at the specific element that ist he subject of the talk.</p>
It should cover
<ul>
<li>basic configuration to get it started / connected</li>
<li>VTY for state introspection ("ar alle connections up?", ...)</li>
<li>looking at logs / protocol traces</li>
<li>practical demo; looking at what happens in pcaps + logs for some basic transaction like LU, SMS, voice call.</li>
</ul> OsmoSGSN - Bug #4599 (New): counter group sgsn:pdpctx already exists for index X, instead using Yhttps://osmocom.org/issues/45992020-06-08T18:05:33Zlaforge
<p>When using OsmoSGSN (current nightly) in a setup with 3rd party 2G BSS and 3G RAN, we are running quite often into the following error message:</p>
<pre>
<0020> rate_ctr.c:224 counter group 'sgsn:pdpctx' already exists for index 5, instead using index 8. This is a software bug that needs fixing.
</pre>
<p>I wonder how this happens. It basically means we want to allocate a PDP context for the same NSAPI where we already have a PDP context.</p>
<p>The only path that calls sgsn_pdp_ctx_alloc() is sgsn_create_pdp_ctx() via activate_ggsn() originating from do_act_pdp_req() and the latter actually chekcs if we already have a PDP context fro the NSAPI in sgsn_pdp_ctx_by_nsapi. weird.</p>
<p><a class="user active" href="https://osmocom.org/users/1741">lynxis</a> any ideas?</p> Cellular Network Infrastructure - Bug #4141 (New): No osmux specific code in place during codec n...https://osmocom.org/issues/41412019-08-05T15:57:19Zpespin
<p>Current code in OsmoBSC and OsmoMSC doesn't take into account that Osmux is to be used when codec negotiation goes one. That means that supported codec list needs to be correctly configured manually in VTY in order to avoid selecting incorrect codecs (like non-AMR). Moreover if an MS doesn't support AMR, since we don't have transcoding yet, the call cannot take place.</p>
<p>Different scenarios need to be listed here and think about what we want to do in each case.</p> OsmoGSMTester - Bug #3676 (New): ofono: org.ofono.ConnectionManager property Bearer returning "none"https://osmocom.org/issues/36762018-10-29T13:11:32Zpespin
<p>According to ofono, it should return the data technology used (gprs, edge, etc.), but it returns None no matter we enable gprs or edge in the network in osmo-gsm-tester (and data services work).</p>
<p>Documentation about the property can be found here:<br /><a class="external" href="https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/connman-api.txt#n103">https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/connman-api.txt#n103</a></p>
<p>This property seems to be updated in common ofono code (src/gprs.c) through API <code>ofono_gprs_bearer_notify</code>. It seems though that property is not implemented in current ofono QMI code (I cannot find any reference to code under qmi calling that function).</p>
<p>It seems, however, that QMI supports some way to query this information, as can be seen in libqmi-glib <code>QmiWdsDataBearerTechnology</code>:<br /><a class="external" href="https://chromium.googlesource.com/chromiumos/third_party/libqmi/+/factory-4128.B/libqmi-glib/qmi-enums-wds.h#680">https://chromium.googlesource.com/chromiumos/third_party/libqmi/+/factory-4128.B/libqmi-glib/qmi-enums-wds.h#680</a></p>
<p>It would be nice to implement that part in ofono to cross-check that the MS resolves the network configuration correctly (if we configure the BTS to use EGPRS, see than ofono indeed states it uses EGPRS and not GPRS).</p> OsmoBSC - Feature #3330 (New): osmo-bsc: Implement IMMEDIATE ASSIGNMENT EXTENDEDhttps://osmocom.org/issues/33302018-06-08T12:14:49Zpespin
<p>See 04.08 "9.1.19 Immediate assignment extended". It allows to send two Immediate Assignment to different MS in the same message.</p>
<p>Furthermore, according to 08.58 "5.7 IMMEDIATE ASSIGNMENT" section:</p>
<pre>
The IMMEDIATE ASSIGNMENT EXTENDED message is either sent by the BSC in the IMMEDIATE ASSIGN
COMMAND, or built by the BTS from up to two IMMEDIATE ASSIGN COMMAND messages.
</pre>
<p>It's probably more useful to implement it in osmo-bts (see <a class="issue tracker-2 status-1 priority-2 priority-default" title="Feature: osmo-bts: Implement IMMEDIATE ASSIGNMENT EXTENDED (New)" href="https://osmocom.org/issues/3329">#3329</a>), but we may still want to support it in osmo-bsc if we connect to non osmo-bts which don't craft IMMEDIATE ASSIGNMENT EXTENDED from regular IMMEDIATE ASSIGNMENT on their own. I imagine for instance an scenario osmo-bsc<->nanobts.</p>
<p>We recently saw some production scenarios which high load in which the AGCH IMM Assign queue was saturated (1000 messages in the queue), so this should help maintain the queue len in lower numbers.</p> OsmoBTS - Feature #3329 (New): osmo-bts: Implement IMMEDIATE ASSIGNMENT EXTENDEDhttps://osmocom.org/issues/33292018-06-08T12:02:32Zpespin
<p>See 04.08 "9.1.19 Immediate assignment extended". It allows to send two Immediate Assignment to different MS in the same message.</p>
<p>Furthermore, according to 08.58 "5.7 IMMEDIATE ASSIGNMENT" section:</p>
<pre>
The IMMEDIATE ASSIGNMENT EXTENDED message is either sent by the BSC in the IMMEDIATE ASSIGN
COMMAND, or built by the BTS from up to two IMMEDIATE ASSIGN COMMAND messages.
</pre>
<p>So we don't need to support IMMEDIATE ASSIGNMENT EXTENDED in osmo-bsc, we can already craft them in osmo-bts (bts.c) in a way similar to what we already do with IMMEDIATE ASSIGNMENT REJECT commands (we couple up to 4 messages in one in there).</p>
<p>We recently saw some production scenarios which high load in which the AGCH IMM Assign queue was saturated (1000 messages in the queue), so this should help maintain the queue len in lower numbers.</p> OsmoSGSN - Bug #2958 (Stalled): OsmoSGSN doesn't authenticate on second/further ATTACH REQUESThttps://osmocom.org/issues/29582018-02-17T17:29:12Zlaforge
<p>When a new/unknown MS performs an ATTACH REQUEST for the first time, it is authenticated.</p>
<p>However, if that same MS later performs a second ATTACH REQUEST, even with new P-TMSI/TLLI, it is not authenticated and we simply send an ATTACH ACCEPT. This is a security problem, as it means anyone can impersonate other known-existing IMSIs.</p> OsmoMSC - Bug #2928 (New): OsmoMSC doesn't do BSSMAP ASSIGNMENT if no MNCC_RTP_CREATE is receivedhttps://osmocom.org/issues/29282018-02-11T10:35:23Zlaforge
When operating OsmoMSC with external MNCC handler, it seems that it "forgets" to
<ul>
<li>perform BSSMAP ASSIGNMENT procedure</li>
<li>perform CRCX/MDCX on MGW endpoint for RAN side<br />if the eternal MNCC handler is not sending the MNCC_RTP_CREATE.</li>
</ul>
<p>This is wrong and indicates the state machines have some trouble.</p>
<p>The voice call should be established towards MS/RAN/MGW as usual, no matter if and when an external MNCC handler decides to actually connect to the MSC-located MGW. The MNCC_RTP_{CREATE,MODIFY} should only be translated to CRCX/MDCX of the mncc-side connection to OsmoMGW, and not anything on the RAN side.</p> OsmoGSMTester - Feature #2861 (New): osmo-gsm-tester: Add 3g support for sysmocell-5khttps://osmocom.org/issues/28612018-01-22T14:55:21Zpespin
<p>Probably nothing different than the implementation required for nano3g is needed, only setting up the sysmocell5k and creating a type to set it up as 3g.</p> OsmoGSMTester - Feature #2707 (New): Add support for verifying content of log files after test is...https://osmocom.org/issues/27072017-12-04T16:30:13Zpespin
<p>We need to add some pieces to osmo-gsm-tester that lets us do some verifications on each object once the test is finished.</p>
<p>We could have a generic verification phase after the test .py file has finished: During test run, when an object instance is requested by the test and allocated by suite.py, we can add that object to a list of objects to verify.<br />When the test execution is passed, for each object we call obj.verify(), which will trigger an Exception if some verification fails.</p>
<p>We can then have a generic API providing helpers to be used inside verify() of each object, as for each object we want to check different information and sources of information. This helpers can also be used by tests to verify specific requirements for that test which doesn't apply in general. Some verification sources I can think of:<br />- log file generated by each object (process).<br />- pcap file owned by each object (through its PcapRecorder object).</p>
<p>Log files:<br /> It would be nice to have an API which allows you to pass the log file, and then another file with strings/regexp to match. If one of those strings/regexp matches in the file, then a exception is triggered. We also want a similar API to do the same but to verify that it doesn't contain a specific string/regexp. The first one can be useful, for instance, to have a list of error strings which should never appear under normal circumstances and that we want to investigate in case they happen. That's the case for string "no space for uplink measurement" (see <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: frequent "no space for uplink measurement" message (Resolved)" href="https://osmocom.org/issues/2329">#2329</a>). This way we can catch regressions quite quickly.</p>
<p>Pcap files:<br />It would be nice to have an API both for:<br />- generic verification: In general, we may want to check that specific filter never appears or that a specific filter must appear. This can be easily implemented using tshark.<br />- specific verification: A test may want to verify some information from the pcap file. For instance, that a certain kind of packet was received, or that a special error is triggered, or that at least N packets matching a filter are being sent.<br />- wait() trigger: It can be used either internally or by tests to wait for specific events to happen before doing something.</p>
<p>I'd first start with the log file part, then once we are done, go for the pcap part.</p> OsmoGSMTester - Feature #2646 (New): osmo-gsm-tester: Add osmo-sip-connector supporthttps://osmocom.org/issues/26462017-11-16T13:43:11Zpespin
<p>We should be able to test</p>
<p>- mo_mt MS phone going trough osmo-sip-connector and asterisk.<br />- Calling unknown numbers<br />- Calling non-registered MS</p>
<p>ms*2 <-> bts <-> bsc <-> msc <-> osmo-sip-connector <-> asterisk</p> OsmoGSMTester - Bug #2615 (New): Add API to check GPS lock in BTShttps://osmocom.org/issues/26152017-11-03T17:00:23Zpespin
<p>We should make sure that all BTS are always correctly calibrated.</p>
<p>For sysmocell5000, ssh+ccli can be used:</p>
<p>Ensure GPS_AUTO_SET_DATE_TIME_ENABLE is enabled<br /><pre>
> mib.get GPS_AUTO_SET_DATE_TIME_ENABLE
OK
GPS_AUTO_SET_DATE_TIME_ENABLE 1 (0x1
</pre></p>
<p>Other interesting commands to check for fix:<br /><pre>
> gps.get-location
OK
lat=0, long=0, alt=0m, age=4294967295s
> gps.get-time
OK
time=023016.33, date=1970-01-11, unixtime=873016, age=4294967295s
</pre></p>
<p>For OCTPHY it's even part of the DSP API.</p>
<p>For b-200, there no way to check afaik.</p>
<p>For sysmobts: gps related:"gpsmon", "gpsdate", "gpsctl", "cgps /dev/ttyS2" <br />To calibrate use sysmobts-calib -m calibrate with any available source (gps or other networks).</p> OsmoGSMTester - Feature #2612 (New): Allow skipping pcaps by configuration if access to tcpdump i...https://osmocom.org/issues/26122017-11-02T14:55:23Zpespin
<p>I found today the title of this task in a comment in osmo-gsm-tester user manual, so putting it here and cleaning it from there.</p> OsmoGSMTester - Support #2504 (New): check whether running osmo-* from docker images is feasible ...https://osmocom.org/issues/25042017-09-07T18:36:30Zneelsnhofmeyr@sysmocom.de
<p>using docker on the osmo-gsm-tester would help to solve / simplify a number of issues.<br />But does it work?</p>
<p>Try it out: build an osmo core-net in a docker image and attempt to run it on the osmo-gsm-tester-rnd.<br />Also try running several (different) images alongside each other.</p>
<p>Is there a bottleneck? Which one (disk space vs. RAM)?</p>
<p>In the extreme we would like to run each of the osmo-* binaries in an own image, being about 10 images in parallel.</p> OsmoGSMTester - Bug #2431 (New): osmo-gsm-tester: add test case: MS sends SMS to ESMEhttps://osmocom.org/issues/24312017-08-10T15:47:28Zpespin
<p>Test A:<br />- Configure SMSC to route to ESME SMS from a specific route (or default route)<br />- ESME connects to SMSC<br />- MS registers<br />- MS sends message to ESME<br />- Validate ESME receives the SMS</p>
<p>Test B:<br />- Configure SMSC to route to ESME SMS from a specific route (or default route)<br />- MS registers enabling Delivery Report<br />- MS sends message to ESME (not registered yet, SMS is stored)<br />- ESME connects to SMSC<br />- Validate ESME receives the SMS<br />- Validate MS receives Delivery Report</p> OsmoGSMTester - Feature #2399 (New): add tests for graceful restart of individual componentshttps://osmocom.org/issues/23992017-07-25T00:02:36Zneelsnhofmeyr@sysmocom.de
<p>Test restart of individual components and associated recovery (BTS/PCU/SGSN/BSC/MSC/HLR restart)</p> OsmoGSMTester - Feature #2374 (New): osmo-gsm-tester: add test case: sms between MS with delivery...https://osmocom.org/issues/23742017-07-18T14:40:04Zpespin
<p>Implement the following test case:</p>
<ol>
<li>Start core network</li>
<li>Power on MS1 and register it to the network, enabling delivery report. Send an SMS to MS2.</li>
<li>Verify delivery report has NOT been received yet by MS1</li>
<li>Power on MS2 and register it to the network.</li>
<li>Verify delivery report is received in MS1</li>
</ol> OsmoGSMTester - Feature #2318 (New): testing sysmobts: skip copying of binaries when the same are...https://osmocom.org/issues/23182017-06-07T15:55:42Zneelsnhofmeyr@sysmocom.de
<p>For each run using a sysmoBTS, we copy the built binaries over, even if the same are already there.<br />Use the sysmobts artifact's checksum file to detect when the identical artifact is already on the sysmoBTS and skip copying if so.</p> OsmoGSMTester - Feature #2314 (New): osmo-gsm-tester: add test case: smpp: correct ESME routinghttps://osmocom.org/issues/23142017-05-31T16:29:10Zpespin
<p>Test feature "default-route" and "route prefix" from smpp vty.</p>
<p>See smpp_vty.c in libmsc (openbsc) for more details.<br />Improve VTY doc if required.</p> OsmoGSMTester - Feature #2313 (New): osmo-gsm-tester: add test case: smpp: imsi extensionhttps://osmocom.org/issues/23132017-05-31T16:27:43Zpespin
<p>Test feature "deliver-src-imsi" from smpp vty. Check that the imsi extension works correctly.</p>
<p>See smpp_vty.c in libmsc (openbsc) for more details.<br />Improve VTY doc if required.</p> OsmoGSMTester - Feature #2311 (New): osmo-gsm-tester: add test case: smpp: smpp_first featurehttps://osmocom.org/issues/23112017-05-31T16:21:35Zpespin
<p>Test feature "smpp_first" from smpp vty. When this feature is on, it will always first send the SMS to the ESME and let it take decisions on routing.</p>
<p>See smpp_vty.c in libmsc (openbsc) for more details.<br />Improve VTY doc if required.</p> OsmoGSMTester - Feature #2266 (New): in the gsm tester, use ipa.py from openbsc instead of the cu...https://osmocom.org/issues/22662017-05-16T16:31:51Zneelsnhofmeyr@sysmocom.de
<p>In openbsc, there is a new and better CTRL implementation, now adopted in the python tests:<br />openbsc/openbsc/ipa.py<br />Copy (?) that to the osmo-gsm-tester, replacing the current CTRL code (that came from the old tester and looks rather bad).</p> OsmoGSMTester - Feature #2230 (New): osmo-gsm-tester: arfcn as resourcehttps://osmocom.org/issues/22302017-05-04T22:18:06Zneelsnhofmeyr@sysmocom.de
<p>So far we have ARFCN resources configured, but they aren't actually resolved and reserved yet.</p>
<ul>
<li>Add arfcn to the suites/sms/suite.conf</li>
<li>implement reservation of an arfcn according to the picked BTS band</li>
</ul>
<p>A problem to overcome could be that a reserved ARFCN doesn't match the BTS band. This may need to be resolved in the scenario files selecting a BTS. i.e. on top of picking a BTS type, a matching ARFCN band needs to be selected. To resolve this directly from the selected BTS implies hardcoded magic, which is also possible, but it would be better if that can be avoided.</p> OsmoGSMTester - Feature #2200 (New): osmo-gsm-tester: allow collecting statistics / KPI of a test...https://osmocom.org/issues/22002017-04-26T15:45:59Zneelsnhofmeyr@sysmocom.de
<p>the osmo-gsm-tester so far "merely" asserts success or failure of a test run.<br />For some setups, it would be interesting to see actual key performance indicators on the test results, included in the jenkins reports.</p>
<p>For example received signal strength (RSSI), the time that something took, the amount of data transmitted...</p>
<ul>
<li>Add an API to collect such (presumably) numbers (but keep it type agnostic?)</li>
<li>pretty-print these results at the end of the test</li>
<li>Include in the jenkins reports</li>
</ul> OsmoGSMTester - Feature #2197 (Stalled): osmo-gsm-tester: use MNCC interfacehttps://osmocom.org/issues/21972017-04-26T15:29:52Zneelsnhofmeyr@sysmocom.de
<p>the MNCC interface present in the old osmo-gsm-tester code is not yet present in the new osmo-gsm-tester.<br />Add test API to interact with the NITB (future OsmoMSC) using MNCC.</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> OsmoBSC - Feature #1946 (New): Add checks to the BSC VTY to prevent configurations known to not workhttps://osmocom.org/issues/19462017-02-08T23:41:53Zneelsnhofmeyr@sysmocom.de
<p>e.g. running TCH/F_TCH/H_PDCH timeslots on a nanobts doesn't work,<br />similarly, the BS11 should reject any codec except HRv1, FR and EFR (i.e. no AMR),<br />and so on.</p>