24 Apr
2025
24 Apr
'25
12:52 p.m.
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/2b718…
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_14…
- Image_2
https://www.etsi.org/deliver/etsi_ts/145000_145099/145014/06.02.00_60/ts_14…
- Image_3
https://data.epo.org/publication-server/rest/v1.2/publication-dates/2016062…
Thank you for your time and effort.
Sorry if I have wasted your time.
Volkan from Turkiye
29 Apr
29 Apr
10:10 a.m.
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(a)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
10:40 a.m.
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(a)sysmocom.de>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(a)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
27 May
27 May
12:08 a.m.
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(a)sysmocom.de>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(a)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(a)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
30 Apr
30 Apr
4:22 p.m.
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
29
days inactive
62
days old
4 comments
3 participants
participants (3)
-
Neels Hofmeyr -
Pau Espin Pedrol -
Volkan Akkuş