Possible Bug Issue - BAND_INDICATOR bit value is reversed
Dear Sir/Ma'am, I kindly ask you to check on information below for a possible error. The claim is that the return bit value of the following function is reversed. It is supposed to be 1 instead of 0 and 0 instead of 1. https://gitea.osmocom.org/cellular-infrastructure/osmo-bsc/src/commit/2b7181... Following sources are presented as proof for the claim. - Image_1 https://www.etsi.org/deliver/etsi_ts/145000_145099/145014/06.02.00_60/ts_145... - Image_2 https://www.etsi.org/deliver/etsi_ts/145000_145099/145014/06.02.00_60/ts_145... - Image_3 https://data.epo.org/publication-server/rest/v1.2/publication-dates/20160622... Thank you for your time and effort. Sorry if I have wasted your time. Volkan from Turkiye
Hi, I fail to see what's wrong according to you: """ static int is_dcs_net(const struct gsm_bts *bts) { if (bts->band == GSM_BAND_850) return 0; if (bts->band == GSM_BAND_1900) return 0; return 1; } """ """ osmo_gsm48_rest_octets_si1_encode(si1->rest_octets, NULL, is_dcs_net(bts)); """ """ int osmo_gsm48_rest_octets_si1_encode(uint8_t *data, uint8_t *nch_pos, int is1800_net) { ... if (is1800_net) bitvec_set_bit(&bv, L); else bitvec_set_bit(&bv, H); } """ Do you mind explaining the case in which we end up encoding a wrong value? Also probably better use redmine to fill a bug report if you think there may be one. Regards, Pau -- - Pau Espin Pedrol <pespin@sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Siemensstr. 26a * 10551 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
Dear Sir, I have tested and verified on several phones. This is a BUG. The trouble is that 1800 MHz transmission is identified as 1900 MHz and vice versa for common ARFCNs. This is the opposite for the design, explained below. https://www.3gpp.org/ftp/Specs/archive/05_series/05.05/0505-8k0.zip A multi-band MS shall interpret ARFCN numbers 512 to 810 as either DCS 1800 or PCS 1900 frequencies according to the parameter BAND_INDICATOR when received in other than the DCS 1800 or PCS 1900 bands. If received in the DCS 1800 or PCS 1900 bands, those ARFCN numbers shall be interpreted as frequencies in the same band. The BAND_INDICATOR is broadcast on BCCH, PBCCH and SACCH. The most recently received value shall be applied by the mobile station. If the parameter is not broadcast, the default value is DCS 1800 frequencies. BAND_INDICATOR (1 bit field) See 3GPP TS 05.05 for definition of this field, which is coded as follows: 0 ARFCN indicates 1800 band 1 ARFCN indicates 1900 band Pau Espin Pedrol <pespin@sysmocom.de>, 29 Nisan 2025 Salı saat 13:10 tarihinde şunu yazdı:
Hi,
I fail to see what's wrong according to you:
""" static int is_dcs_net(const struct gsm_bts *bts) { if (bts->band == GSM_BAND_850)
return 0; if (bts->band == GSM_BAND_1900)
return 0; return 1; } """
""" osmo_gsm48_rest_octets_si1_encode(si1->rest_octets, NULL, is_dcs_net(bts));
"""
""" int osmo_gsm48_rest_octets_si1_encode(uint8_t *data, uint8_t *nch_pos, int is1800_net) { ... if (is1800_net) bitvec_set_bit(&bv, L); else bitvec_set_bit(&bv, H); } """
Do you mind explaining the case in which we end up encoding a wrong value?
Also probably better use redmine to fill a bug report if you think there may be one.
Regards, Pau
-- - Pau Espin Pedrol pespin@sysmocom.de http://www.sysmocom.de/
======================================================================= * sysmocom - systems for mobile communications GmbH * Siemensstr. 26a * 10551 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
Hi! This is weird -- your mail arrived in my inbox on 2025-05-25, and your mail is dated 2025-04-29, also around two hours *before* the email you are responding to. Something seems to be wrong with your mail client. Please fix that!! About a possible bit flip bug -- you may also remember that I confirmed in a separate mail Pau's findings that the code you pointed out is indeed correct. Please read again: https://lists.osmocom.org/hyperkitty/list/openbsc@lists.osmocom.org/message/... You insist that there is a bit flip somewhere, which means that the bug is not in that part of the code we are looking at. Would you please explain in more detail: how do you determine a band misinterpretation? What is your test setup, what symptom do you see, and what do you expect to see instead? Thanks! ~N On Tue, Apr 29, 2025 at 10:40:19AM +0000, Volkan Akkuş wrote:
Dear Sir, I have tested and verified on several phones. This is a BUG. The trouble is that 1800 MHz transmission is identified as 1900 MHz and vice versa for common ARFCNs. This is the opposite for the design, explained below. https://www.3gpp.org/ftp/Specs/archive/05_series/05.05/0505-8k0.zip
A multi-band MS shall interpret ARFCN numbers 512 to 810 as either DCS 1800 or PCS 1900 frequencies according to the parameter BAND_INDICATOR when received in other than the DCS 1800 or PCS 1900 bands. If received in the DCS 1800 or PCS 1900 bands, those ARFCN numbers shall be interpreted as frequencies in the same band. The BAND_INDICATOR is broadcast on BCCH, PBCCH and SACCH. The most recently received value shall be applied by the mobile station. If the parameter is not broadcast, the default value is DCS 1800 frequencies.
BAND_INDICATOR (1 bit field) See 3GPP TS 05.05 for definition of this field, which is coded as follows: 0 ARFCN indicates 1800 band 1 ARFCN indicates 1900 band
Pau Espin Pedrol <pespin@sysmocom.de>, 29 Nisan 2025 Salı saat 13:10 tarihinde şunu yazdı:
Hi,
I fail to see what's wrong according to you:
""" static int is_dcs_net(const struct gsm_bts *bts) { if (bts->band == GSM_BAND_850)
return 0; if (bts->band == GSM_BAND_1900)
return 0; return 1; } """
""" osmo_gsm48_rest_octets_si1_encode(si1->rest_octets, NULL, is_dcs_net(bts));
"""
""" int osmo_gsm48_rest_octets_si1_encode(uint8_t *data, uint8_t *nch_pos, int is1800_net) { ... if (is1800_net) bitvec_set_bit(&bv, L); else bitvec_set_bit(&bv, H); } """
Do you mind explaining the case in which we end up encoding a wrong value?
Also probably better use redmine to fill a bug report if you think there may be one.
Regards, Pau
-- - Pau Espin Pedrol pespin@sysmocom.de http://www.sysmocom.de/
======================================================================= * sysmocom - systems for mobile communications GmbH * Siemensstr. 26a * 10551 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
-- - Neels Hofmeyr <nhofmeyr@sysmocom.de> https://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Siemensstr. 26a * 10551 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte
Hi! AFAICT the code you point out is correct. In your analysis, please also take into account the function osmo_gsm48_rest_octets_si1_encode() which consumes the return value of is_dcs() as argument is1800_net. We always try to keep encoding details out of our decision logic. So, since the function is called is_dcs(), it shall return 1 == true for DCS bands. Which value it is encoded as is "hidden" within osmo_gsm48_rest_octets_si1_encode(): if (is1800_net) bitvec_set_bit(&bv, L); else bitvec_set_bit(&bv, H); The bit written to SI1 is according to the specs you kindly point out: DCS band = 1800 band = L, and non-DCS = 1900 = H. Many thanks for your efforts and for pointing out possible bugs in osmocom! ~N
participants (3)
-
Neels Hofmeyr -
Pau Espin Pedrol -
Volkan Akkuş