Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092022-11-14T19:25:57ZOpen Source Mobile Communications
Redmine 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> 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> Cellular Network Infrastructure - Feature #3229 (New): build-system: jenkins.sh: Improve debian ...https://osmocom.org/issues/32292018-05-03T12:40:28Zpespin
<p>The idea is to add extra tests/checks to avoid breaking debian package building during nightly builds in OBS. Instead, let's catch it during gerrit patch submission time and don't allow merging it until it's fixed.</p>
<p>We should investigate several tools, like pbuilder, dpkg-build, etc. I recall lynxis also told me something about some kind of lint tool available for this purposes.</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 #2933 (New): change of trans->bearer_cap (e.g. via MNCC) will not trigger BSSMAP AS...https://osmocom.org/issues/29332018-02-12T11:36:39Zlaforge
<p>Whenever the trans->bearer_cap change (e.g.due to a CC MODIFY or MNCC MODIFY), the MSC must chck if the new bearer capabilities are different from the old bearer capabilities, and subsequently trigger a BSSMAP ASSIGNMENT towards the BSS.</p>
<p>Currently, the handling of bearer_cap will in only work if the related CC/MNCC message with <br />besrer_cap IE happens before the pint in time at which the MSC performs the BSSMAP ASSIGNMENT<br />procedure. Our logic still needs to change in a way that the CC/MNCC <br />code in gsm_04_08.c detects if trans->bearer_cap != new bearer_cap, and<br />in that case triggers a new follow-up BSSMAP ASSIGNMENT.</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> 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> Cellular Network Infrastructure - Bug #1612 (New): more configuration consistency checkinghttps://osmocom.org/issues/16122016-02-23T16:22:14Zlaforge
<p>Right now it is possible to configure various things that wouldn't work, like an ARFCN that is outside the band of the BTS, or even the TRX.</p>
<p>More consistency checks would make sense, together with reasonable error messages.</p>