https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092020-04-20T00:11:38ZOpen Source Mobile CommunicationsOsmoBTS - Feature #4505: LimeSDR+osmo-bts-trx+gsm-r band sethttps://projects.osmocom.org/issues/4505?journal_id=180322020-04-20T00:11:38Zfixeria
<ul></ul><blockquote>
<p>1.Does osmo-bts-trx support GSM-R frequency band?</p>
</blockquote>
<p>If you check the actual band/frequency mapping [1], you will see that it uses the same frequencies as E-GSM. Thus no 'special' band configuration is required.</p>
<p>[1] <a class="external" href="https://en.wikipedia.org/wiki/Absolute_radio-frequency_channel_number#ARFCN_table_for_common_GSM_systems">https://en.wikipedia.org/wiki/Absolute_radio-frequency_channel_number#ARFCN_table_for_common_GSM_systems</a></p> OsmoBTS - Feature #4505: LimeSDR+osmo-bts-trx+gsm-r band sethttps://projects.osmocom.org/issues/4505?journal_id=180382020-04-20T09:40:15Zlaforge
<ul></ul><p>Just to be clear here: Even if you get the SDR to transmit on an GSM-R ARFCN,<br />this by far doesn't make the Osmocom stack implement GSM-R. The different<br />frequency is only one of the many differences between GSM and GSM-R.</p>
One would have to add at least the following features:
<ul>
<li>ASCI (VBS, VGCS) including the NCH on Um, and related signaling on Abis and A</li>
<li>CSD on the control plane as well as the user plane (Um, Abis/RTP, MGCP, MGW, ...)</li>
</ul> OsmoBTS - Feature #4505: LimeSDR+osmo-bts-trx+gsm-r band sethttps://projects.osmocom.org/issues/4505?journal_id=180402020-04-20T11:56:53Zlaforge
<ul></ul><p>fixeria wrote:</p>
<blockquote>
<p>If you check the actual band/frequency mapping [1], you will see that it uses the same frequencies as E-GSM.</p>
</blockquote>
<p>This is not correct. GSM-R uses frequencies <strong>below</strong> E-GSM. This is why GSM-R<br />handsets have special band filters that are different than normal band filters.</p> OsmoBTS - Feature #4505: LimeSDR+osmo-bts-trx+gsm-r band sethttps://projects.osmocom.org/issues/4505?journal_id=180432020-04-20T13:40:37Zfixeria
<ul></ul><blockquote>
<p>This is not correct. GSM-R uses frequencies below E-GSM...</p>
</blockquote>
<p>Oh, you're right. Sorry for confusion. The Ful(x) formula is the same, but ARFCN ranges are different...</p> OsmoBTS - Feature #4505: LimeSDR+osmo-bts-trx+gsm-r band sethttps://projects.osmocom.org/issues/4505?journal_id=180802020-04-26T12:39:39ZdingdingYang
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>fixeria wrote:</p>
<blockquote>
<p>If you check the actual band/frequency mapping [1], you will see that it uses the same frequencies as E-GSM.</p>
</blockquote>
<p>This is not correct. GSM-R uses frequencies <strong>below</strong> E-GSM. This is why GSM-R<br />handsets have special band filters that are different than normal band filters.</p>
</blockquote>
<p>Thank you very much,谢谢</p> OsmoBTS - Feature #4505: LimeSDR+osmo-bts-trx+gsm-r band sethttps://projects.osmocom.org/issues/4505?journal_id=255192022-11-21T19:11:18Zlaforge
<ul><li><strong>Tags</strong> set to <i>ASCI, GSM-R</i></li><li><strong>Tracker</strong> changed from <i>Support</i> to <i>Feature</i></li><li><strong>Assignee</strong> set to <i>fixeria</i></li></ul> OsmoBTS - Feature #4505: LimeSDR+osmo-bts-trx+gsm-r band sethttps://projects.osmocom.org/issues/4505?journal_id=255212022-11-21T19:42:20Zfixeria
<ul></ul><p>Seeing this ticket assigned to me, I would like to clarify what needs to be done here.</p>
<p>Here is what I have in mind:</p>
<ul>
<li>Extending the <code>gsm_arfcn2freq10()</code> / <code>gsm_freq102arfcn()</code> API in libosmocore.git to support R-GSM ARFCNs
<ul>
<li>Most likely adding the R-GSM band (DL 921.0 – 960.0 MHz) to the <code>enum gsm_band</code> in libosmocore.git</li>
<li>Adding unit tests, making sure that ARFCN-to-Freq (and vice-versa) conversion works</li>
</ul>
</li>
<li>Adding a new BTS feature <code>BTS_FEAT_GSMR</code> (or more specifically <code>BTS_FEAT_BAND_GSMR</code>)
<ul>
<li>Adding some logic to osmo-bsc.git checking presence of that feature</li>
</ul>
</li>
<li>Extending the VTY command <code>band BAND</code> in osmo-bsc.git and osmo-bts.git</li>
<li>Checking osmo-trx freq. correctness with a spectrum analyzer</li>
</ul>
<p><a class="user active" href="https://projects.osmocom.org/users/7">laforge</a> please correct me or let me know if I missed something.</p> OsmoBTS - Feature #4505: LimeSDR+osmo-bts-trx+gsm-r band sethttps://projects.osmocom.org/issues/4505?journal_id=256002022-11-25T11:59:09Zfixeria
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li><li><strong>Assignee</strong> changed from <i>fixeria</i> to <i>laforge</i></li></ul> OsmoBTS - Feature #4505: LimeSDR+osmo-bts-trx+gsm-r band sethttps://projects.osmocom.org/issues/4505?journal_id=259472023-01-17T11:57:54Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>fixeria</i></li></ul><p>Sorry for the late feedback. I agree that your plan looks good. Let's call the feature BTS_FEAT_BAND_*.</p>
<p>Also, I think the band is called R-GSM (and, in addition, ER-GSM) and not GSM-R.</p> OsmoBTS - Feature #4505: LimeSDR+osmo-bts-trx+gsm-r band sethttps://projects.osmocom.org/issues/4505?journal_id=277622023-09-02T21:05:23Zfixeria
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>In Progress</i></li></ul> OsmoBTS - Feature #4505: LimeSDR+osmo-bts-trx+gsm-r band sethttps://projects.osmocom.org/issues/4505?journal_id=277632023-09-04T07:13:35Zfixeria
<ul></ul><p>fixeria wrote in <a href="#note-7">#note-7</a>:</p>
<blockquote>
<p>Here is what I have in mind:</p>
<ul>
<li>Extending the <code>gsm_arfcn2freq10()</code> / <code>gsm_freq102arfcn()</code> API in libosmocore.git to support R-GSM ARFCNs
<ul>
<li>Most likely adding the R-GSM band (DL 921.0 – 960.0 MHz) to the <code>enum gsm_band</code> in libosmocore.git</li>
<li>Adding unit tests, making sure that ARFCN-to-Freq (and vice-versa) conversion works</li>
</ul></li>
</ul>
</blockquote>
<p>Actually, this is not needed. The <code>GSM_BAND_900</code> in libosmocore.git does include P-GSM, E-GSM, and R-GSM. According to 3GPP TS 45.005, table 2-2, the R-GSM band is basically an extension of E-GSM, which in turn is an extension of P-GSM. The ARFCN range 955..974 (inclusive) is R-GSM specific and as it turned out already supported by the <code>gsm_arfcn2freq10()</code> / <code>gsm_freq102arfcn()</code> API:</p>
<pre>
$ osmo-arfcn -a 955
ARFCN 955: Uplink 876.2 MHz / Downlink 921.2 MHz
# Fl(n) = 890 + 0.2*(n-1024) = 890 + 0.2*(955-1024) = 876.2
# Fu(n) = Fl(n) + 45 = 876.2 + 45 = 921.2
$ osmo-arfcn -a 974
ARFCN 974: Uplink 880.0 MHz / Downlink 925.0 MHz
# Fl(n) = 890 + 0.2*(n-1024) = 890 + 0.2*(974-1024) = 880.0
# Fu(n) = Fl(n) + 45 = 880.0 + 45 = 925.0
</pre>
<p>So we're doing good here.</p>
<blockquote>
<ul>
<li>Adding a new BTS feature <code>BTS_FEAT_GSMR</code> (or more specifically <code>BTS_FEAT_BAND_GSMR</code>)
<ul>
<li>Adding some logic to osmo-bsc.git checking presence of that feature</li>
</ul></li>
</ul>
</blockquote>
<p>I will be working on this, let's call it <code>BTS_FEAT_BAND_RGSM</code> then.</p>
<blockquote>
<ul>
<li>Extending the VTY command <code>band BAND</code> in osmo-bsc.git and osmo-bts.git</li>
</ul>
</blockquote>
<p>Not needed, using "GSM900" is sufficient.</p>
<blockquote>
<ul>
<li>Checking osmo-trx freq. correctness with a spectrum analyzer</li>
</ul>
</blockquote>
<p>Will give it a try today.</p> OsmoBTS - Feature #4505: LimeSDR+osmo-bts-trx+gsm-r band sethttps://projects.osmocom.org/issues/4505?journal_id=277642023-09-04T09:21:11Zfixeria
<ul></ul><p>fixeria wrote in <a href="#note-7">#note-7</a>:</p>
<blockquote>
<ul>
<li>Checking osmo-trx freq. correctness with a spectrum analyzer</li>
</ul>
</blockquote>
<p>I tested ARFCNs 955 and 974 with osmo-{bts,trx} and confirmed that everything works as expected using a poor man's spectrum analyzer.</p> OsmoBTS - Feature #4505: LimeSDR+osmo-bts-trx+gsm-r band sethttps://projects.osmocom.org/issues/4505?journal_id=278432023-09-11T12:30:59Zfixeria
<ul></ul><p>I found out that nanoBTS does indicate information about supported bands using ip.access specific attributes, so I though it would be a good idea to replicate these attributes in osmo-bts. This way we do not pollute the <code>enum osmo_bts_features</code> (max. flag number is currently limited to 128) and improve support of nanoBTS.</p>
<p>Below are patches for osmo-bsc:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/34321">https://gerrit.osmocom.org/c/osmo-bsc/+/34321</a> bts_siemens_bs11: remove ip.access nanoBTS specific code<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/34322">https://gerrit.osmocom.org/c/osmo-bsc/+/34322</a> abis_nm: separate parsing of osmo-bts features into a function<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/34323">https://gerrit.osmocom.org/c/osmo-bsc/+/34323</a> abis_nm: parse feature flags in NM_ATT_IPACC_SUPP_FEATURES<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/34354">https://gerrit.osmocom.org/c/osmo-bsc/+/34354</a> nm_{bb_transc,bts}_fsm: rework sending of Get Attributes [NEW]<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/34355">https://gerrit.osmocom.org/c/osmo-bsc/+/34355</a> abis_nm: get rid of MAX_BTS_ATTR [NEW]<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/34356">https://gerrit.osmocom.org/c/osmo-bsc/+/34356</a> oml: ipacc: parse Object Version from SW Activated Report [NEW]<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/34298">https://gerrit.osmocom.org/c/osmo-bsc/+/34298</a> oml: ipacc: send GPRS Cell attributes based on IPA Object Version [WIP]<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/34357">https://gerrit.osmocom.org/c/osmo-bsc/+/34357</a> oml: ipacc: fix sending hard-coded GPRS Cell attributes [NEW]<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/34358">https://gerrit.osmocom.org/c/osmo-bsc/+/34358</a> oml: ipacc: fix copy-pasted talloc chunk names [NEW]<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/34359">https://gerrit.osmocom.org/c/osmo-bsc/+/34359</a> abis_nm: send Get Attributes to Rado Carrier <abbr title="s">MO</abbr> [NEW]<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/34360">https://gerrit.osmocom.org/c/osmo-bsc/+/34360</a> abis_nm: send Get Attributes to GPRS Cell <abbr title="s">MO</abbr> [NEW]</p> OsmoBTS - Feature #4505: LimeSDR+osmo-bts-trx+gsm-r band sethttps://projects.osmocom.org/issues/4505?journal_id=278872023-09-16T21:10:18Zfixeria
<ul></ul><p>Below are patches for osmo-bts:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/34430">https://gerrit.osmocom.org/c/osmo-bts/+/34430</a> osmo-bts-{oc2g,lc15}: signal CBCH support to BSC<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/34431">https://gerrit.osmocom.org/c/osmo-bts/+/34431</a> oml: oml_tx_attr_resp(): pass *mo to handle_attrs_{bts,trx}()<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/34432">https://gerrit.osmocom.org/c/osmo-bts/+/34432</a> oml: refactor generation of Get Attribute Response<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/34433">https://gerrit.osmocom.org/c/osmo-bts/+/34433</a> oml: oml_tx_attr_resp(): handle common nm_state attributes<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/34434">https://gerrit.osmocom.org/c/osmo-bts/+/34434</a> oml: implement handling of NM_ATT_IPACC_SUPP_FEATURES</p>
<p>Once all patches have been merged, this ticket can be closed.</p> OsmoBTS - Feature #4505: LimeSDR+osmo-bts-trx+gsm-r band sethttps://projects.osmocom.org/issues/4505?journal_id=279232023-09-24T16:10:36Zfixeria
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li></ul><p>All patches have been merged.</p>