Good afternoon!
In libbsc/bsc_init.c we have the following case:
case GSM_BAND_900: if (bts->c0->arfcn < 1 || (bts->c0->arfcn > 124 && bts->c0->arfcn < 955) || bts->c0->arfcn > 1023) { LOGP(DNM, LOGL_ERROR, "GSM900 channel must be between 1-124, 955-1023.\n"); return -EINVAL; } break;
3GPP 45.005, table 2-2 gives valid channel numbers as:
P-GSM900 -> 1-124, E-GSM900 -> 0-124 and 975-1023 R-GSM900 -> 0-124 and 955-1023 ER-GSM900 -> 0-124 and 940-1023
The code looks to bounds check ARFCN closest to R-GSM900, but omits ARFCN 0.
Is the check "bts->c0->arfcn < 1" erroneous, or am I missing some history?
Also should it really check for the R-GSM 900 range, or should it be E-GSM (more common)?
The other band checks look correct.
Kind Regards,
Mike PS: osmo-arfcn is okay with ARFCN 0: $ ./osmo-arfcn -a 0 ARFCN 0: Uplink 890.0 MHz / Downlink 935.0 MHz
On 10 Apr 2015, at 19:42, Mike McTernan (wavemobile) mike.mcternan@wavemobile.com wrote:
Hi,
Is the check "bts->c0->arfcn < 1" erroneous, or am I missing some history?
no, it looks erroneous.
Also should it really check for the R-GSM 900 range, or should it be E-GSM (more common)?
the “biggest” band should be fine. The BTS can still OML NACK this ARFCN if it doesn’t support this specific sub-band.