https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092019-09-12T14:32:16ZOpen Source Mobile CommunicationsOsmoMSC - Feature #4200: Work around nano3G-S16 requiring RAB ID to be below 16https://projects.osmocom.org/issues/4200?journal_id=159382019-09-12T14:32:16Zlaforge
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li><li><strong>Assignee</strong> set to <i>efistokl</i></li></ul><p>I suspect this is some constraint of the nano3G-S16 and not neccessarily a bug by OsmoMSC.</p>
<p>3GPP TS 25.413 defines the RAB ID in Section 9.2.1.2. At no point does it state that RAB IDs must be recycled and stay below the maximum count of concurrent RAB supported by the RNC/NodeB, and that they cannot use any arbitray (unique) value from 0...255. So IMHO, OsmoMSC is well within its right to choose whatever RAB ID it wants.</p>
<p>To me it looks a bit like the nano3G S16 may support 16 concurrent UE and hence RABs, and that it only permits RAB ID 0..16 for that. You can confirm this theory by making the RAB ID start with 17 in the first call (you have to patch the OsmoMSC side), and see if that first call already fails.</p> OsmoMSC - Feature #4200: Work around nano3G-S16 requiring RAB ID to be below 16https://projects.osmocom.org/issues/4200?journal_id=159432019-09-12T18:27:24Zlynxis
<ul></ul><blockquote>
<p>(If I don't do this then the UE will not respond to Paging Request (assuming it doesn't have enough time after Iu-Release which happens after USSD)</p>
</blockquote>
<p>The paging problem might be fixed by <a class="external" href="https://gerrit.osmocom.org/c/osmo-msc/+/15494">https://gerrit.osmocom.org/c/osmo-msc/+/15494</a></p> OsmoMSC - Feature #4200: Work around nano3G-S16 requiring RAB ID to be below 16https://projects.osmocom.org/issues/4200?journal_id=159462019-09-13T09:06:37Zefistokl
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>To me it looks a bit like the nano3G S16 may support 16 concurrent UE and hence RABs, and that it only permits RAB ID 0..16 for that. You can confirm this theory by making the RAB ID start with 17 in the first call (you have to patch the OsmoMSC side), and see if that first call already fails.</p>
</blockquote>
<p>Genau! The theory has been confirmed. Thanks.<br />Also, what is interesting. When I reached the rab ID 21, instead of replying the femtocell did Deregister:)</p>
<p>I guess I will try to mask the RAB ID to be in the range 1..16 and see what the femtocell has to say...</p> OsmoMSC - Feature #4200: Work around nano3G-S16 requiring RAB ID to be below 16https://projects.osmocom.org/issues/4200?journal_id=159512019-09-13T12:41:46Zefistokl
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li></ul><p>efistokl wrote:</p>
<blockquote>
<p>I guess I will try to mask the RAB ID to be in the range 1..16 and see what the femtocell has to say...</p>
</blockquote>
<p>Double confirmed. I used the range 1..15 (I guess it is also acceptable to be 0 but I haven't checked) and all is fine. Closing this. Thanks, Harald!</p>
<p>lynxis wrote:</p>
<blockquote><blockquote>
<p>(If I don't do this then the UE will not respond to Paging Request (assuming it doesn't have enough time after Iu-Release which happens after USSD)</p>
</blockquote>
<p>The paging problem might be fixed by <a class="external" href="https://gerrit.osmocom.org/c/osmo-msc/+/15494">https://gerrit.osmocom.org/c/osmo-msc/+/15494</a></p>
</blockquote>
<p>Thank you and excuse me for being so slow to test this. I am still fixing some call problems (unrelated to osmocom software). I will test it when I am free from the urgent stuff...</p> OsmoMSC - Feature #4200: Work around nano3G-S16 requiring RAB ID to be below 16https://projects.osmocom.org/issues/4200?journal_id=159552019-09-13T21:13:24Zlaforge
<ul></ul><p>On Fri, Sep 13, 2019 at 12:41:46PM +0000, efistokl [REDMINE] wrote:</p>
<blockquote>
<p>Double confirmed. I used the range 1..15 (I guess it is also acceptable to be 0 but I haven't checked) and all is fine. Closing this. Thanks, Harald!</p>
</blockquote>
<p>well, not sure it should be closed. We still might want to have a workaround in the codebase.</p>
<p>Maybe rather rename the issue subject to "work around nano3G-S16 requiring RAB ID to be below 16" <br />or so?</p>
<p>OsmoMSC (and SGSN?) could use a RAB-ID allocation algoritmh that would always choose the lowest<br />available free number, rather than using a monotonically incrementing counter. Doing just modulo<br />arithmetic won't cut it, as RAB-ID 0 could be particularly long-lasting, and at the time we wrap,<br />0 can very well still be in use.</p> OsmoMSC - Feature #4200: Work around nano3G-S16 requiring RAB ID to be below 16https://projects.osmocom.org/issues/4200?journal_id=159562019-09-14T08:29:29Zefistokl
<ul><li><strong>Tracker</strong> changed from <i>Bug</i> to <i>Feature</i></li><li><strong>Subject</strong> changed from <i>Getting "radioNetwork: failure-in-the-radio-interface-procedure (14)" in RAB-AssignmentResponse after 15 calls.</i> to <i>Work around nano3G-S16 requiring RAB ID to be below 16</i></li><li><strong>Status</strong> changed from <i>Resolved</i> to <i>In Progress</i></li></ul> OsmoMSC - Feature #4200: Work around nano3G-S16 requiring RAB ID to be below 16https://projects.osmocom.org/issues/4200?journal_id=159572019-09-14T09:48:15Zefistokl
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>You can confirm this theory by making the RAB ID start with 17 in the first call (you have to patch the OsmoMSC side), and see if that first call already fails.</p>
</blockquote>
<p>Performed the same test with ip.access nano3g S8 (though you said before that it behaved totally fine on ccc events, but we have different software versions on them). S8 is totally fine. S16 is quite weird in this sense as it should be more advanced than S8 (well, it is at least in terms of coverage)... I think I need to ask ip.access whether they have a software update targeting this. Sounds very much like a bug in S16 software...</p>