Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092023-12-25T00:38:03ZOpen Source Mobile Communications
Redmine Osmo-CC - Feature #6319 (New): protocol version should have a defined end markerhttps://projects.osmocom.org/issues/63192023-12-25T00:38:03Zneelsnhofmeyr@sysmocom.de
<p>in osmo-cc-v0.91.pdf I read:</p>
<pre>When a connection is established, both ends send a version string of eight bytes:
“OSMOCCv1” first. (no \0 termination, no line feed, case sensitive) The Version number is
defined by the eighth byte. In this case the protocol version is ‘1’.</pre>
<p>I think it would be better to make this more flexible than a single version char.</p>
<p>I was thinking, what happens when we reach "OSMOCCv10"? It cannot be distinguished from "OSMOCCv1" followed by an unrelated "0".</p>
<p>So I guess it should actually be \0 terminated, or it should be in a TLV, or it should be defined that the version string is sent in a single TCP packet where the entire payload is just the version string? Something that allows extending the string in the future.</p>
<p>What do you think?</p> Core testing infrastructure - Bug #6185 (New): Submit titan.ProtocolEmulations.SCCP patch upstreamhttps://projects.osmocom.org/issues/61852023-09-20T11:38:25Zpespin
<p>It was noticed that we currently hold & use in osmo-ttcn3-hacks our own fork of titan.ProtocolEmulations.SCCP.git [1].</p>
<p>We use our own fork because we are using an extra patch on top of master [2]. AFAICT, that patch has never been submitted upstream, but at first glance it looks like it should?</p>
<p>The upstream to submit to is in gitlab [3].</p>
<p>[1] <a class="external" href="https://github.com/osmocom/titan.ProtocolEmulations.SCCP">https://github.com/osmocom/titan.ProtocolEmulations.SCCP</a><br />[2] <a class="external" href="https://github.com/osmocom/titan.ProtocolEmulations.SCCP/commit/17a894fc6620a0df11d0d98c897fb66168276b16">https://github.com/osmocom/titan.ProtocolEmulations.SCCP/commit/17a894fc6620a0df11d0d98c897fb66168276b16</a><br />[3] <a class="external" href="https://gitlab.eclipse.org/eclipse/titan/titan.ProtocolEmulations.SCCP">https://gitlab.eclipse.org/eclipse/titan/titan.ProtocolEmulations.SCCP</a></p> OsmoHNBGW - Feature #5904 (New): HNBAP Register Request handling does checks that seem to make no...https://projects.osmocom.org/issues/59042023-02-11T02:28:42Zneelsnhofmeyr@sysmocom.de
<p>Looking at this code, a couple of things seem to make no sense:</p>
<p><a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/osmo-hnbgw/src/commit/a3c7f750a2f77c0c0e0ade1800f5b3a97a2f0b6e/src/osmo-hnbgw/hnbgw_hnbap.c#L431">https://gitea.osmocom.org/cellular-infrastructure/osmo-hnbgw/src/commit/a3c7f750a2f77c0c0e0ade1800f5b3a97a2f0b6e/src/osmo-hnbgw/hnbgw_hnbap.c#L431</a></p>
<ul>
<li>we are using getpeername() to compare the remote address of the current ctx to all other hnb. But we are handling a PDU in an accept()ed connection, and the hnb_context *ctx has already been looked up according to the remote address the PDU was received from.</li>
</ul>
<ul>
<li>assuming there are two connections from the same remote address, what do we care about the IP address? if there are two HNB entities connecting via two distinct conns, so be it, from the same address or not. We should only care about the HNB id (LAC,SAC,RAC,CID,MCC,MNC identity)</li>
</ul>
<ul>
<li>assuming we want to check the remote address: in the error checking path of failed getpeername(), we are still going on to compare as if the result from getpeername() was valid.</li>
</ul>
<ul>
<li>the loop is guarding against two HNB registering with identical HNB id.
<ul>
<li>When this occurs from the same remote address, we discard the <strong>old</strong> hnb_context. However, in practice it seems that instead of allocating another hnb_context on the same remote address, instead the HNB-Register-Req is dispatched to the same hnb_context in osmo-hnbgw, and this loop is essentially skipped (the log often shows the "(duplicated)" at the bottom of the function).</li>
<li>When this occurs from a different remote address, we reject the <strong>new</strong> hnb_context (bottom of the loop body). Now, in recent efforts to hunt down UE state leaks in osmo-hnbgw, it became clear that a HNB disconnecting may go unnoticed. Imagine a HNB's conn being disrupted, its state still present in osmo-hnbgw. If a new conn is established for this HNB from another remote address, we refuse this new connection, favoring the disrupted connection. It may be frustrating for a user trying to reconnect a HNB via a different link. The comment names two reasons:
<ul>
<li>misconfiguration: it is the user's responsibility to configure distinct HNBs with distinct identities. Is it helpful to refuse a new connection when a previous connection became stale and lingers? It may avoid oscillation of two HNBs with same id competing, but it is also hard to recover from a failed link when refusing new connections.</li>
<li>impersonation: we have no authentication of HNB, we are utterly incapable of avoiding impersonation anyway.</li>
</ul></li>
</ul></li>
</ul>
<p>3GPP TS 25.469 8.2.4 Abnormal Conditions:<br />""" <br />If the HNB-GW receives a duplicate HNB REGISTER REQUEST (i.e. for an already registered HNB identified by the<br />unique HNB identity), then the new HNB REGISTER REQUEST shall override the existing registration and the<br />handling of the new HNB REGISTER REQUEST is according to section 8.2.<br />"""</p>
Context:
<ul>
<li>this patch introduced the reject on duplicate HNB REGISTER REQ: <a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/osmo-iuh/commit/c964a2cfa1b08e5bbda5d721a7a0095d26b53791">https://gitea.osmocom.org/cellular-infrastructure/osmo-iuh/commit/c964a2cfa1b08e5bbda5d721a7a0095d26b53791</a></li>
<li>this patch introduced accepting the new HNB REGISTER REQ when from the same address: <a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/osmo-hnbgw/commit/12bc4afab3096c60554cd6d43fa11840bd76228c">https://gitea.osmocom.org/cellular-infrastructure/osmo-hnbgw/commit/12bc4afab3096c60554cd6d43fa11840bd76228c</a></li>
</ul>
<p>It seems the initial motion to reject a duplicate HNB REGISTER was wrong, and the newer patch tried to alleviate this, but still kept the rejection based on the remote address for reasons not named.</p>
My idea for this is:
<ul>
<li>do not check remote addresses at all.</li>
<li>compare only HNB IDs. If they match, always discard the <strong>old</strong> hnb_context, allow the new HNB register.</li>
</ul>
<p>To test this, I implemented this behavior, and HNBGW_Tests.ttcn3 still succeed<br />(with only the expected failure of TC_hnb_register_duplicate() that no longer gets the HNB Register Reject it wants to see)<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-hnbgw/+/31289">https://gerrit.osmocom.org/c/osmo-hnbgw/+/31289</a></p>
<p>feedback welcome</p> OsmoHNBGW - Bug #5876 (New): on HNBAP HNB Register, clear previous UE state if anyhttps://projects.osmocom.org/issues/58762023-01-25T14:03:01Zneelsnhofmeyr@sysmocom.de
<p>when a HNB registers with osmo-hnbgw, and the same HNB is already registered, osmo-hnbgw keeps the HNB state and simply logs "(duplicated)" with the HNB Register Request log.</p>
<p>A HNB should only register when it has restarted, and no UE state should stay around when that happens.<br />So, upon HNB Register Request, if we find that HNB already connected, clear out any previous state on that HNB.</p>
<p>Otherwise we likely keep stale UE state and stale SCCP conns indefinitely, by ignoring a restart of a HNB.</p> Cellular Network Infrastructure - Feature #5771 (New): series of presentations about the invididu...https://projects.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> OsmoMSC - Bug #5197 (New): msc_i Unimplemented msg type: HANDOVER PERFORMEDhttps://projects.osmocom.org/issues/51972021-07-12T14:18:36Zpespin
<p>As seen on a running osmo-msc:<br /><pre>
<0010> ran_msg_a.c:848 msc_i(IMSI-...:MSISDN-...:TMSI-0x...:GERAN-A-65:PAGING_RESP)[0x...]{READY}: RAN decode: BSSMAP: Unimplemented msg type: HANDOVER PERFORMED
</pre></p>
<p>Seems the message type is missing in ran_a_decode_bssmap. Is this expected? what's missing?</p> OsmoMSC - Bug #5196 (New): Verify several "event not permitted" log lines in unit testshttps://projects.osmocom.org/issues/51962021-07-12T11:48:53Zpespin
<pre>
pespin ~/dev/sysmocom/git/osmo-msc $ ag "not permitted" tests/msc_vlr/ | grep Event
tests/msc_vlr/msc_vlr_test_gsm_authen.err:60:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:649:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:1480:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:1793:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:2058:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:2324:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:3242:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_ms_timeout.err:814:DMSC msc_a(IMSI-901700000004620:GERAN-A:LU){MSC_A_ST_WAIT_CLASSMARK_UPDATE}: Event MSC_A_EV_UNUSED not permitted
</pre>
<p>We should check whether those events are indeed not expected and only triggered by tests, or whether they can happen and hence we should allow them and handle them properly in the FSM.</p>
<p>Similar to:<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-msc/+/24916">https://gerrit.osmocom.org/c/osmo-msc/+/24916</a> msc_a.c: Allow MSC_A_EV_CN_CLOSE in state MSC_A_ST_RELEASING</p> Cellular Network Infrastructure - Bug #5188 (New): BSSMAP Cell Identifier IE vs. Cell Identifier ...https://projects.osmocom.org/issues/51882021-06-23T00:43:19Zneelsnhofmeyr@sysmocom.de
<p>In libosmocore, we have enum CELL_IDENT, which gets used in both of<br /> Cell Identifier IE (3GPP TS 48.008 3.2.2.17)<br />and<br /> Cell Identifier List IE (3GPP TS 48.008 3.2.2.27)</p>
<p>The similar meaning and structuring of these two IEs suggests that the List IE<br />is simply a bunch of the plain Cell Identifier. However, if you read in 3GPP TS<br />48.008, comparing 3.2.2.17 and 3.2.2.27, there is this odd difference:</p>
<p>3.2.2.17, Cell Identifier IE:</p>
<pre><code>0000 CGI<br /> 0001 LAC+CI<br /> 0010 CI<br /> 0011 No cell</code></pre>
<pre><code>1000 PLMN+LAC+RNC (<del>> E-UTRAN)<br /> 1001 RNC (</del>> E-UTRAN)<br /> 1010 LAC+RNC (-> E-UTRAN)<br /> 1011 SAI<br /> 1100 LAC+RNC+CI</code></pre>
<p>3.2.2.27a, Cell Identifier List Segment:</p>
<pre><code>0000 CGI<br /> 0001 LAC+CI<br /> 0010 CI<br /> 0011 No cell</code></pre>
<pre><code>0100 LAI<br /> 0101 LAC<br /> 0110 entire BSS<br /> 0111 MCC+MNC</code></pre>
<p>I noticed this because I was trying to check for the correct target cell <br />identifier in the BSSMAP Handover Request message; we send a LAI cell <br />identification in the Cell Identifier IE. wireshark shows the LAI cell<br />identifer the same way that osmo-msc intends to encode it, but the TTCN3 <br />BSSAP_Templates fail to parse this LAI cell identifier.</p>
<p>So I added this cell id type to BSSMAP_IE_CellIdentifier in<br />./deps/titan.ProtocolModules.BSSMAP/src/BSSAP_Types.ttcn. and just to confirm<br />that I'm right i took a quick look in the spec, and then found that the ttcn <br />definition is in fact on par with the spec: the LAI cell id is not<br />present in 3.2.2.17 at all!</p>
<p>Now, our libosmocore gsm/protocol/gsm_08_08.h and gsm0808_utils.h are based on<br />the assumption that the same cell identifiers are used in both of these IEs.</p>
<p>The osmo-bsc and osmo-msc neighbor config for inter-BSC handover is built<br />assuming that we can send the 3.2.2.27a cell identifiers in the Handover<br />Request's 'Cell Identifier (Target)' IE.</p>
<p>Apparently the spec intends otherwise.</p>
<p>The effect of this goes across several osmo cn components:</p>
<ul>
<li>We define enum CELL_IDENT in libosmocore.</li>
<li>osmo-bsc sends the Handover Request using the 'Cell Identifier (Serving)' and 'Cell Identifier (Target)' IEs.</li>
<li>osmo-msc parses these, possibly forwards in inter-MSC handover procedure.</li>
</ul>
<p>I'm not sure how to resolve this.</p>
<ul>
<li>We could just accept that we're using the 3.2.2.27a identifiers also in 3.2.2.17. It makes an awful lot of sense in fact.<br /> The wireshark implementation seems to agree with this point, though of course that's not the benchmark.<br /> It might pose an incompatibility with strictly spec conforming cn implementations.<br /> And we would need to extend the TTCN BSSAP_Types.ttcn with values that aren't strictly present in 3.2.2.17,<br /> if we want to test these cell identifier types in our test suite.</li>
</ul>
<ul>
<li>or we could endeavour to fix the identifiers that we use in the BSSMAP protocol according to spec, in osmo-bsc and osmo-msc
<ul>
<li>either we introduce two distinct enums -- that could ripple through a lot of the cell identifier API, ugly.</li>
<li>or we still use the same enum for both, but making distinctions in the implementations which values are used for which.</li>
</ul></li>
</ul>
<p>To enforce that, we may have to adjust which cell identifier types can be used in the neighbor configuration of osmo-bsc and osmo-msc,<br />or we find ways to, for example, convert all cell identifier types to a supported one.<br />I guess easiest would be to enforce full CGI everywhere.</p>
<p>Yet easier would be to highlight in the documentation that osmocom is capable of nonstandard cell identifiers,<br />and to conform to specs users should simply use the full CGI everywhere in the neighbor config.</p>
<p>Any insights or opinions on this?</p> osmo-sip-connector - Bug #5177 (New): respect dynamic RTP payload types of external SIPhttps://projects.osmocom.org/issues/51772021-06-12T07:24:17Zlaforge
<p>As <a class="user active" href="https://projects.osmocom.org/users/4282">keith</a> reported in OsmoDevCall on June 11, when an external SIP entity sends a SIP INVITE with SDP for AMR using a dynamic PT, osmo-sip-connector still sends AMR audio using a different (actually unassigned for this call/session) PT.</p>
<p>I guess this relates to the fact that 3GPP uses "pseudo static" PTs for the different codecs, i.e. it has defined that certain PT numbers from the dynamic PT range actually statically represent 3GPP codec types. Within Osmocom, we are sticking to the latter and may not have considered "Real" SIP/SDP compatibilty on the external interface.</p> Cellular Network Infrastructure - Bug #4883 (New): update OsmoNITB migration guidehttps://projects.osmocom.org/issues/48832020-12-01T08:32:05Zlaforge
<p><a class="wiki-page" href="https://projects.osmocom.org/projects/cellular-infrastructure/wiki/OsmoNITB_Migration_Guide">OsmoNITB_Migration_Guide</a> is showing its age. I've fixed the two most obvious outdated bits (no subscriber-create-on-demand and references to bsc_mgcp), but I'm sure there are plenty more, particularly in the config file snippets.</p>
<p>As there may still be people migrating from OsmoNITB, let's update it to reflect the current situation.</p> OsmoMSC - Bug #4784 (New): wrong cause code (resources unavailable) in MO-to-MT call without resp...https://projects.osmocom.org/issues/47842020-10-08T13:24:35Zlaforge
<p>if a MO-to-MT call is performed using osmo-msc with internal MNCC handler, and the call proceeds up to the "ALERTING" being sent by the MT-leg (but the call is never accepted by the MT side), the CC RELEASE is sent using cause value "resources unavailable, unspecified" (GSM48_CC_CAUSE_RESOURCE_UNAVAIL). This is quite misleading to users, and one is trying to find what kind of resources miight be exhausted. But there is no exhaustion, "B" just never responded the call from "A".</p> OsmoBSC - Support #4621 (New): feedback: osmo-bsc modifies the LAI in LU Accept messages, and the...https://projects.osmocom.org/issues/46212020-06-18T16:36:53Zneelsnhofmeyr@sysmocom.de
<p>looking at osmo_bsc_filter.c, I notice that we probably don't want any of this to remain in osmo-bsc:<br /><a class="external" href="http://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/osmo_bsc_filter.c#n110">http://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/osmo_bsc_filter.c#n110</a></p>
<ul>
<li>we are modifying the LAI in a Location Updating Accept message. I'm pretty sure we don't want to do this in osmo-bsc ever.<br /> <a class="external" href="http://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/osmo_bsc_filter.c#n135">http://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/osmo_bsc_filter.c#n135</a></li>
</ul>
<ul>
<li>we are modifying the MM info, see bsc_patch_mm_info()<br /> <a class="external" href="http://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/osmo_bsc_filter.c#n32">http://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/osmo_bsc_filter.c#n32</a><br /> I'm least sure about the timezone information that osmo-bsc overwrites in the MM info,<br /> I dimly remember an explicit request to be able to run BSCs in different time zones...</li>
</ul>
<p>Which parts of this can be dropped?</p> OsmoSGSN - Bug #4599 (New): counter group sgsn:pdpctx already exists for index X, instead using Yhttps://projects.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://projects.osmocom.org/users/1741">lynxis</a> any ideas?</p> OsmoBSC - Bug #4560 (New): inter-BSC HO: target cell fails when there is no TCH, only dynamic TCH...https://projects.osmocom.org/issues/45602020-05-20T21:00:50Zneelsnhofmeyr@sysmocom.de
<p>someone relayed this factoid.<br />Set up an inter-BSC HO situation where the target cell has only TCH/F_PDCH dynamic timeslots, and see whether handover fails because of that.<br />According to the report, having at least one non-dynamic TCH timeslot fixes the problem.</p> IMSI Pseudonymization - Feature #4495 (New): Specification: More referenceshttps://projects.osmocom.org/issues/44952020-04-16T08:50:56Zlaforge
<p>The specification currently doesn't have any references to anything except the numbers of some 3GPP specs.</p>
<p>I think it would be good to have references to othe relevant articles / literature, for example on the location privacy weaknesses of 2G to 4G, the attacks people have published, etc.</p> IMSI Pseudonymization - Feature #4494 (New): Specification: Add bibliographyhttps://projects.osmocom.org/issues/44942020-04-16T08:49:27Zlaforge
<p>When referenccing 3GPP specs, lets use the same mechanism as we use in the osmo-gsm-manuals with a separate Biblipgraphy section that contains hyperlinks to the related specification homepage.</p> IMSI Pseudonymization - Feature #4493 (New): Specification: Cover 2G, 3G and 4G separatelyhttps://projects.osmocom.org/issues/44932020-04-16T08:47:55Zlaforge
<p>Rgiht now, the spec is very 2G-centric. 3G is very similar in terms of MSC/HLR. But at least fro 4G, we also should have a ladder diagram and related text.</p> Cellular Network Infrastructure - Bug #4141 (New): No osmux specific code in place during codec n...https://projects.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://projects.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 #3656 (New): inter-BSC handover outgoing: compose Cell Identifier List from sev...https://projects.osmocom.org/issues/36562018-10-15T22:04:32Zneelsnhofmeyr@sysmocom.de
<p>Thinking about inter-BSC handover, I may have made a naive choice when designing the outgoing inter-BSC mechanism:</p>
<ul>
<li>The BSSMAP Handover Required message features a Cell Identifier List to name several remote-BSS target cells.</li>
<li>The current implementation associates each ARFCN+BSIC with a Cell Identifier List, and when we consider a given ARFCN+BSIC having good enough RXLEV, we send that ARFCN+BSIC's Cell Identifier List to the MSC.</li>
</ul>
<p>However, I now think it was more intended like this:</p>
<ul>
<li>We know each remote-BSS ARFCN+BSIC's <strong>single</strong> Cell Identifier.</li>
<li>We see several remote-BSS ARFCN+BSIC having good RXLEV.</li>
<li>When asking for handover, we compose a Cell Identifier List, adding each viable ARFCN+BSIC to the list and send that to the MSC.</li>
</ul>
<p>I have often wondered how one ARFCN+BSIC would in practice correspond to several Cell Identifiers, and now I had a bit of a face-palm moment, realizing I probably put the cart before the horse there.</p>
<p>So maybe we should:</p>
<ul>
<li>Roll back the ability to store several remote-BSS Cell Identifiers per ARFCN+BSIC key
<ul>
<li>in the VTY UI (most urgent).</li>
<li>maybe also in the internal neighbor_ident.c storage, in API and code complexity I have introduced (less urgent).</li>
</ul></li>
</ul>
<ul>
<li>Handover decision algorithm 1: collect all remote-BSS neighbors with better RXLEV, if there are more than one -- might even make practical sense when an MS travels to in-between two remote-BSS cells and one of them is overloaded.</li>
<li>Handover decision algorithm 2: collect all "ok" remote-BSS neighbors instead of only the best one (algorithm 2 currently does handovers to remote-BSS only upon critical levels). Makes practical sense to find any one remote-BSS neighbor that helps to avert lchan loss due to critically low reception levels: the MS has already moved considerably far out of this BSS and might have several options to camp to. Maybe some of those are overloaded and the alternative ones would save the call.</li>
</ul> OsmoHLR - Feature #3644 (New): allow arbitrary bytes in Global Title (GT), a.k.a. the VLR,SGSN's ...https://projects.osmocom.org/issues/36442018-10-11T11:54:36Zneelsnhofmeyr@sysmocom.de
<p>osmo-msc and osmo-sgsn send IPA_IDTAG_SERNR identifications to osmo-hlr of the form "MSC-00-00-00-00-00-00".<br />We've already enlarged the vlr_number and sgsn_number fields in osmo-hlr's subscriber struct to make room for this.<br />However, the real Global Title to identify an entity like the MSC should be allowed to contain <strong>arbitrary</strong> bytes and lengths.</p>
<p>Particularly, in osmo-hlr's luop, the luop->peer is just a pointer and needs a length.<br />Furthermore we should not expect nul termination, as we currently do, for proper GT support.<br />We should also adjust osmo-hlr's database scheme for arbitrary GT blobs.</p> OsmoBSC - Feature #3586 (New): support LCLS for inter-BSC handoverhttps://projects.osmocom.org/issues/35862018-09-24T15:58:42Zneelsnhofmeyr@sysmocom.de
<p>In the osmo-bsc handover_fsm.c, we do not do lcls_apply_config() anywhere yet.</p>
<p>For an intra-BSC handover, the MSC isn't even involved and we would simply redirect the RTP stream from one BTS to the other. The network-side RTP switching would be unchanged.</p>
<p>Only for incoming inter-BSC handover do we want to apply LCLS, so that its result is sent in the BSSMAP Handover Complete message.</p>
<p>Similar to the LCLS Assignment fix I8dd561d744d8081b5ac5ffa7635f17ac19bcda45, we would need to <strong>first</strong> set conn->lchan to the new lchan, then call lcls_apply_config() and only after that send the BSSMAP Handover Complete. (So far the FSM wants to signal success and switch the lchan only <strong>after</strong> sending the BSSMAP HO Complete succeeds, but if sending the BSSMAP fails we might as well release the lchan and in consequence tear down the conn completely.) This would happen in handover_end() in handover_fsm.c when result == HO_RESULT_OK and ho->scope & HO_INTER_BSC_IN.</p> OsmoBSC - Feature #3505 (New): ttcn3: test inter-BSC HO with encryption enabledhttps://projects.osmocom.org/issues/35052018-08-28T09:28:02Zneelsnhofmeyr@sysmocom.de
<p>The initial implementation of inter-BSC HO (incoming) fails to apply the encryption configuration to the new lchan.<br />Add a ttcn3 test that does inter-BSC HO with encryption enabled and make sure the encryption gets applied.</p> OsmoBSC - Feature #3483 (New): handover decision: if rxlev is ok but rxqual is bad, move from TCH...https://projects.osmocom.org/issues/34832018-08-20T11:57:56Zneelsnhofmeyr@sysmocom.de
<p>Bad quality scenario: rxlev is ok, but rxqual drops below the min_rxqual threshold.</p>
<p>Handover decision 2 contains a switch from TCH/H to TCH/F to improve rxqual. See on_measurement_report() in handover_decision_2.c, by the comment "Bad Quality".<br />However, that condition seems buggy: "if (... av_rxqual > ho_get_hodec2_min_rxqual(bts->ho))" should probably be the flipped?</p>
<p>To test for this with real equipment, we could manipulate the min_rxqual threshold during a call.<br />In ttcn3, we could use measurement reports.</p> OsmoMSC - Bug #3110 (New): Test and possibly fix ID Request after Auth failurehttps://projects.osmocom.org/issues/31102018-03-26T12:42:36Zneelsnhofmeyr@sysmocom.de
<p>In vlr_auth_fsm, we have an illegal transition from WAIT_RESP_RESYNC to <br />WAIT_ID_IMSI. That looks weird, to go from an UMTS AKA auth resync attempt back <br />to the ID Request. But looking at TS 29.002 in "Figure 25.5/2 (sheet 2 of 2): <br />Macro Authenticate_VLR" I see there is a branch that wants to ensure the TMSI<br />used in auth matches the IMSI. So if the TMSI didn't belong to the IMSI<br />reported back from an ID Response, we should retry auth. However, if the IMSI <br />reported back indeed was the one we expected, we should fail right away; it <br />doesn't look like we do that yet.</p>
<p>Write tests and fix if errors become obvious.</p> OsmoMSC - Feature #3069 (New): investigate multiple CM Service Request on the same connhttps://projects.osmocom.org/issues/30692018-03-16T12:28:10Zneelsnhofmeyr@sysmocom.de
<p>TS 24.008 Section 4.5.2:</p>
<blockquote>
<p>According to the protocol architecture described in 3GPP TS 24.007<br />[20], each CM entity will have its own MM connection. These different<br />MM connections are identified by the protocol discriminator PD and,<br />additionally, by the transaction identifier TI.</p>
</blockquote>
<p>So for example, one could have multiple calls (same pdisc, but different TI),<br />or one could have SMS ongoing while a call (different pdisc+TI).</p>
<p>Testing an SMS sent during an ongoing call indeed shows a secondary CM Service Request.</p>
In attached pcap it seems that we are already handling the situation rather well.<br />Nevertheless, take a close look:
<ul>
<li>are we handling the TI properly?</li>
<li>make sure that the tear down of one service handling doesn't cut short any other pending CM Service Requests,<br /> especially if one CM Service Request concludes while the another has just sent the CM Service Request and we are still waiting for the actual CC/RR/... service request following.</li>
</ul>
<p>(I also notice in attached PCAP that DTMF requests are rejected, and that a call Hold command is rejected; that may have to become separate issues.)</p> OsmoBSC - Bug #3002 (New): HO2: handover decision for dynamic timeslotshttps://projects.osmocom.org/issues/30022018-02-26T00:05:32Zneelsnhofmeyr@sysmocom.de
<p>The recent handover_decision_2.c hasn't been duly tested in the presence of dynamic timeslots.<br />Particularly TCH/F_TCH/H_PDCH timeslots are potentially both TCH/F or TCH/H, which might require another spin on the handover_decision_2.c code.</p> OsmoGSMTester - Feature #2861 (New): osmo-gsm-tester: Add 3g support for sysmocell-5khttps://projects.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> Cellular Network Infrastructure - Feature #2623 (New): SCCP/M3UA: detect restart of osmo-msc and ...https://projects.osmocom.org/issues/26232017-11-07T23:25:36Zneelsnhofmeyr@sysmocom.de
<p>Connecting osmo-bsc and osmo-hnbgw to the MSC and SGSN via an OsmoSTP instance, it is currently not possible to detect that the MSC or SGSN has restarted.</p>
<p>Scenario: using a sysmoBTS as a NITB, change MSC config, restart MSC -- now osmo-bsc happily continues to run and does not even notice that it is an entirely new MSC instance running in the core net now.</p>
<p>In the old days, the SCCPlite link would go down, but since now OsmoSTP is in-between and has no concept of who depends on who, no-one is notifying BSC or HNBGW that MSC or SGSN have gone down. Find out how this is intended to be solved if at all, and devise a way how osmo-bsc will restart and/or reconnect to a new MSC instance, and so forth.</p> OsmoGSMTester - Support #2504 (New): check whether running osmo-* from docker images is feasible ...https://projects.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>