https://osmocom.org/https://osmocom.org/favicon.ico?16647414092020-04-23T03:22:45ZOpen Source Mobile CommunicationsOsmoPCU - Bug #4509: osmo-pcu rejects 8-bit RACH requests rejected on new MS when on "egprs only" modehttps://osmocom.org/issues/4509?journal_id=180552020-04-23T03:22:45Zfixeria
<ul></ul><p>If I remember correctly, <a class="user active" href="https://osmocom.org/users/4282">keith</a> reported a similar behavior in the IRC (not sure if there is any ticket).</p>
<blockquote>
<p>... spec 3GPP TS 04.60 sec "7.1.3 TBF establishment using two phase access".</p>
</blockquote>
<p>TS 04.60 (or TS 44.060) mostly describes the establishment procedures for configurations where PBCCH (and thus PRACH) is present (despite it has been deprecated a while ago, and should not be used nowadays). I would recommend to additionally check out 3GPP TS 44.018, in particular section 3.5.2 "Packet access procedure using CCCH".</p>
<blockquote>
<p>So as far as I understand from the spec reference listed above, it should be possible for this scenario to work.</p>
</blockquote>
<p>Yep, I also think we should not reject phones just because egprs_ms_class is not known. Even in case of 11 bit EGPRS Packet Channel Request, egprs_ms_class is not always included (depending on its type). Maybe we should just do a regular GPRS assignment in that case? AH, damn, it's 'egprs-only' mode...</p>
<blockquote>
<p>Maybe I need to send some specific value in the RACH request so that single block is selected in order to sent PACKET RESOURCE REQUEST?</p>
</blockquote>
<p>See 3GPP TS 44.018, table 9.1.8.1 "CHANNEL REQUEST message content". The value '3A'O was picked randomly, because back then in September I had almost no knowledge about GPRS and its RLC/MAC. So '3A'O ('00111010'B) is <strong>not even a valid packet Access Burst</strong> :/ Looking at the table, it matches '0011xxxx'B - "Answer to paging".</p>
<p>So I would try sending '01110xxx'B (single block packet access), or one of '011110xx'B | '01111x0x'B | '01111xx0'B (one phase packet access). Good luck!</p> OsmoPCU - Bug #4509: osmo-pcu rejects 8-bit RACH requests rejected on new MS when on "egprs only" modehttps://osmocom.org/issues/4509?journal_id=180572020-04-23T15:35:21Zpespin
<ul></ul><p>Apparently we receive System Information 13 from BTS to PCU through the pcuif, so we can also gain information in osmo-pcu regarding what's allowed:<br />3GPP TS 04.08 version 7.21.0 "10.5.2.37b SI 13 Rest Octets"</p>
<p>Also in TS 04.60 (7.1.2.1 Initiation of the packet access procedure):<br /><pre>
EGPRS TBF mode capable MSs shall monitor the GPRS Cell Options IE on the PBCCH (PSI1/PSI13) for the cell's EGPRS capability. In the GPRS Cell Options IE it is also indicated if the EGPRS PACKET CHANNEL REQUEST is supportedin the cell.
</pre></p> OsmoPCU - Bug #4509: osmo-pcu rejects 8-bit RACH requests rejected on new MS when on "egprs only" modehttps://osmocom.org/issues/4509?journal_id=180672020-04-24T06:53:42Zlaforge
<ul></ul><p>On Thu, Apr 23, 2020 at 03:35:22PM +0000, pespin [REDMINE] wrote:</p>
<blockquote>
<p>Apparently we receive System Information 13 from BTS to PCU through the pcuif,</p>
</blockquote>
<p>yes, this is among other things needed so we can send it to individual MS over PACCH<br />once the TBF duration exceeds a certain time. This is required as the MS is not able<br />to read SI13 from the BCCH while it is in an active TBF.</p> OsmoPCU - Bug #4509: osmo-pcu rejects 8-bit RACH requests rejected on new MS when on "egprs only" modehttps://osmocom.org/issues/4509?journal_id=202412020-11-03T09:51:07Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-2 priority-default closed" href="/issues/4544">Feature #4544</a>: concurrent operation of GPRS and EGPRS mode</i> added</li></ul> OsmoPCU - Bug #4509: osmo-pcu rejects 8-bit RACH requests rejected on new MS when on "egprs only" modehttps://osmocom.org/issues/4509?journal_id=204052020-11-25T19:25:24Zpespin
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Closed</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>"egprs only" vty command has been deprecated and is nowadays a NO-OP in current master, so this has been implicitly fixed by all later changes related to <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: concurrent operation of GPRS and EGPRS mode (Resolved)" href="https://osmocom.org/issues/4544">#4544</a>.<br />Closing the ticket.</p>