Open gdt opened 8 years ago
Thanks for bringing this up! I remember vaguely some user pointed me to a stackoverflow discussion some very long time ago. I think it was this one: https://stackoverflow.com/questions/7240038/utran-cell-identity-returned-by-getcid
According to the discussion the higher bits would indicate the RNC. Unfortunately the Android documentation isn't of great help at this point..
Please let me know, if you have any better ideas!
Cheers Toby
Here's how I did it on SatStat: https://github.com/mvglasow/satstat/commit/2196ddd5fbfb9290d3ab236f37b96bba11f83e68 (inspired by @gdt 's post and @wish7code 's link). In a nutshell:
I've added a preference for users to choose their preferred format.
@gdt
It seems that the low 16 bits of HSPA match GSM
That is just a convention which some carriers use but others don't. On Vodafone Germany the GSM and UMTS cell IDs indeed match while on other carriers they don't. Likewise, Vodafone Germany uses the last decimal digit of the cell ID to identify the antenna sector whereas O2 uses the first decimal digit.
Thanks for explaining. I look forward to the new satstat build on f-droid. So if I understand correctly, CID for GSM and CID for UMTS are technically totally independent, but it seems that for providers that choose to make the match (the obvious nerd choice, to me), it could be useful to determine that and be able to aggregate observations.
AT&T (US) seems to use adjoining CID values for sectors, but it isn't strictly a digit - they often cross over the 10s digit.
Having the RNC-CID format makes figuring this out far easier. I wonder if radiocells and the website should do this too. Do we know what the cellspotting community does?
I've seen a few lists on this site, which split up the IDs. Then again, as I just did some Android debugging, I noticed that the logs use the decimal format. Essentially that means we're likely to encounter both.
As for aggregating observations, the guys over at Mozilla had a similar discussion (https://github.com/mozilla/ichnaea/issues/143) and ultimately decided against it, as they found the complexity and risk of introducing errors currently outweighs the benefits. For the same reason, I'd be extremely careful about "baking" such aggregations into the database. At the most, we could implement it on the resolver side (i.e. offline provider or web API for the online provider) – if we make mistakes on that end, they're a lot easier to fix.
HSPA cells are presented as 9 digit numbers, and GSM is typically 5 (16 bits). It seems that the low 16 bits of HSPA match GSM and are the actual cell id, vs the higher bits in HSPA (which mean ??). After observing HSPA, the cells tab shows 16-bit IDs that are not recognizable from the 9 without a calculator. It would be nice to decide on one form and be consistent. I wonder if using hex would be right, as truncation is easy.