Feature #4505
closedLimeSDR+osmo-bts-trx+gsm-r band set
Added by dingdingYang about 4 years ago. Updated 7 months ago.
0%
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?
Updated by fixeria about 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.
Updated by laforge about 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.
- 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, ...)
Updated by laforge about 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.
Updated by fixeria about 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...
Updated by dingdingYang about 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,谢谢
Updated by laforge over 1 year ago
- Tags set to ASCI, GSM-R
- Tracker changed from Support to Feature
- Assignee set to fixeria
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_bandin libosmocore.git - Adding unit tests, making sure that ARFCN-to-Freq (and vice-versa) conversion works
- Most likely adding the R-GSM band (DL 921.0 – 960.0 MHz) to the
- Adding a new BTS feature
BTS_FEAT_GSMR(or more specificallyBTS_FEAT_BAND_GSMR)- Adding some logic to osmo-bsc.git checking presence of that feature
- Extending the VTY command
band BANDin 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.
Updated by fixeria over 1 year ago
- Status changed from New to Feedback
- Assignee changed from fixeria to laforge
Updated by laforge over 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.
Updated by fixeria 8 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_bandin 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 specificallyBTS_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 BANDin 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.
Updated by fixeria 8 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]
Updated by fixeria 8 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.
