Project

General

Profile

Actions

Feature #4505

closed

LimeSDR+osmo-bts-trx+gsm-r band set

Added by dingdingYang almost 4 years ago. Updated 6 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
04/19/2020
Due date:
% Done:

0%

Spec Reference:
Tags:

Description

I'm using LimeSDR based osmo-bts-trx.And I want to support GSM-R frequency band by them.
I have read the description documents,but not found the GSM-R band config in osmo-bts-trx.So I have two questions about this:
1.Does osmo-bts-trx support GSM-R frequency band?
2.If osmo-bts-trx support GSM-R frequency,what should I do to set band config?

Actions #1

Updated by fixeria almost 4 years ago

1.Does osmo-bts-trx support GSM-R frequency band?

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.

[1] https://en.wikipedia.org/wiki/Absolute_radio-frequency_channel_number#ARFCN_table_for_common_GSM_systems

Actions #2

Updated by laforge almost 4 years ago

Just to be clear here: Even if you get the SDR to transmit on an GSM-R ARFCN,
this by far doesn't make the Osmocom stack implement GSM-R. The different
frequency is only one of the many differences between GSM and GSM-R.

One would have to add at least the following features:
  • ASCI (VBS, VGCS) including the NCH on Um, and related signaling on Abis and A
  • CSD on the control plane as well as the user plane (Um, Abis/RTP, MGCP, MGW, ...)
Actions #3

Updated by laforge almost 4 years ago

fixeria wrote:

If you check the actual band/frequency mapping [1], you will see that it uses the same frequencies as E-GSM.

This is not correct. GSM-R uses frequencies below E-GSM. This is why GSM-R
handsets have special band filters that are different than normal band filters.

Actions #4

Updated by fixeria almost 4 years ago

This is not correct. GSM-R uses frequencies below E-GSM...

Oh, you're right. Sorry for confusion. The Ful(x) formula is the same, but ARFCN ranges are different...

Actions #5

Updated by dingdingYang almost 4 years ago

laforge wrote:

fixeria wrote:

If you check the actual band/frequency mapping [1], you will see that it uses the same frequencies as E-GSM.

This is not correct. GSM-R uses frequencies below E-GSM. This is why GSM-R
handsets have special band filters that are different than normal band filters.

Thank you very much,谢谢

Actions #6

Updated by laforge over 1 year ago

  • Tags set to ASCI, GSM-R
  • Tracker changed from Support to Feature
  • Assignee set to fixeria
Actions #7

Updated by fixeria over 1 year ago

Seeing this ticket assigned to me, I would like to clarify what needs to be done here.

Here is what I have in mind:

  • Extending the gsm_arfcn2freq10() / gsm_freq102arfcn() API in libosmocore.git to support R-GSM ARFCNs
    • Most likely adding the R-GSM band (DL 921.0 – 960.0 MHz) to the enum gsm_band in libosmocore.git
    • Adding unit tests, making sure that ARFCN-to-Freq (and vice-versa) conversion works
  • Adding a new BTS feature BTS_FEAT_GSMR (or more specifically BTS_FEAT_BAND_GSMR)
    • Adding some logic to osmo-bsc.git checking presence of that feature
  • Extending the VTY command band BAND in osmo-bsc.git and osmo-bts.git
  • Checking osmo-trx freq. correctness with a spectrum analyzer

laforge please correct me or let me know if I missed something.

Actions #8

Updated by fixeria over 1 year ago

  • Status changed from New to Feedback
  • Assignee changed from fixeria to laforge
Actions #9

Updated by laforge about 1 year ago

  • Assignee changed from laforge to fixeria

Sorry for the late feedback. I agree that your plan looks good. Let's call the feature BTS_FEAT_BAND_*.

Also, I think the band is called R-GSM (and, in addition, ER-GSM) and not GSM-R.

Actions #11

Updated by fixeria 7 months ago

  • Status changed from Feedback to In Progress
Actions #12

Updated by fixeria 7 months ago

fixeria wrote in #note-7:

Here is what I have in mind:

  • Extending the gsm_arfcn2freq10() / gsm_freq102arfcn() API in libosmocore.git to support R-GSM ARFCNs
    • Most likely adding the R-GSM band (DL 921.0 – 960.0 MHz) to the enum gsm_band in libosmocore.git
    • Adding unit tests, making sure that ARFCN-to-Freq (and vice-versa) conversion works

Actually, this is not needed. The GSM_BAND_900 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 gsm_arfcn2freq10() / gsm_freq102arfcn() API:

$ 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

So we're doing good here.

  • Adding a new BTS feature BTS_FEAT_GSMR (or more specifically BTS_FEAT_BAND_GSMR)
    • Adding some logic to osmo-bsc.git checking presence of that feature

I will be working on this, let's call it BTS_FEAT_BAND_RGSM then.

  • Extending the VTY command band BAND in osmo-bsc.git and osmo-bts.git

Not needed, using "GSM900" is sufficient.

  • Checking osmo-trx freq. correctness with a spectrum analyzer

Will give it a try today.

Actions #13

Updated by fixeria 7 months ago

fixeria wrote in #note-7:

  • Checking osmo-trx freq. correctness with a spectrum analyzer

I tested ARFCNs 955 and 974 with osmo-{bts,trx} and confirmed that everything works as expected using a poor man's spectrum analyzer.

Actions #14

Updated by fixeria 7 months ago

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 enum osmo_bts_features (max. flag number is currently limited to 128) and improve support of nanoBTS.

Below are patches for osmo-bsc:

https://gerrit.osmocom.org/c/osmo-bsc/+/34321 bts_siemens_bs11: remove ip.access nanoBTS specific code
https://gerrit.osmocom.org/c/osmo-bsc/+/34322 abis_nm: separate parsing of osmo-bts features into a function
https://gerrit.osmocom.org/c/osmo-bsc/+/34323 abis_nm: parse feature flags in NM_ATT_IPACC_SUPP_FEATURES
https://gerrit.osmocom.org/c/osmo-bsc/+/34354 nm_{bb_transc,bts}_fsm: rework sending of Get Attributes [NEW]
https://gerrit.osmocom.org/c/osmo-bsc/+/34355 abis_nm: get rid of MAX_BTS_ATTR [NEW]
https://gerrit.osmocom.org/c/osmo-bsc/+/34356 oml: ipacc: parse Object Version from SW Activated Report [NEW]
https://gerrit.osmocom.org/c/osmo-bsc/+/34298 oml: ipacc: send GPRS Cell attributes based on IPA Object Version [WIP]
https://gerrit.osmocom.org/c/osmo-bsc/+/34357 oml: ipacc: fix sending hard-coded GPRS Cell attributes [NEW]
https://gerrit.osmocom.org/c/osmo-bsc/+/34358 oml: ipacc: fix copy-pasted talloc chunk names [NEW]
https://gerrit.osmocom.org/c/osmo-bsc/+/34359 abis_nm: send Get Attributes to Rado Carrier MO [NEW]
https://gerrit.osmocom.org/c/osmo-bsc/+/34360 abis_nm: send Get Attributes to GPRS Cell MO [NEW]

Actions #15

Updated by fixeria 6 months ago

Below are patches for osmo-bts:

https://gerrit.osmocom.org/c/osmo-bts/+/34430 osmo-bts-{oc2g,lc15}: signal CBCH support to BSC
https://gerrit.osmocom.org/c/osmo-bts/+/34431 oml: oml_tx_attr_resp(): pass *mo to handle_attrs_{bts,trx}()
https://gerrit.osmocom.org/c/osmo-bts/+/34432 oml: refactor generation of Get Attribute Response
https://gerrit.osmocom.org/c/osmo-bts/+/34433 oml: oml_tx_attr_resp(): handle common nm_state attributes
https://gerrit.osmocom.org/c/osmo-bts/+/34434 oml: implement handling of NM_ATT_IPACC_SUPP_FEATURES

Once all patches have been merged, this ticket can be closed.

Actions #16

Updated by fixeria 6 months ago

  • Status changed from In Progress to Resolved

All patches have been merged.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)