Wrong CID/LAC shown in Database Viewer (0.1.25-alpha-b3 )

[He3556]

1. "Database Viewer" > "Cell data" (and also under "Cell Information"):
There is always a CellID = 65554 with LAC = 0 when i start the App. I first saw it a few months ago, so it is not a new issue. After a few hours this cell disappears again (in the View "Cell Information") i have to search if it is still in the local db. I hope it is and we keep all data.

2. In the "Database Viewer" > "Location data":
There are a few Cells with CellID = -1 and LAC = 0

• Solution might be: check the values before saving to db. (only save If CellID != -1)
  I never found CellID=0 as a failure, so i would like to keep this data - in fact a "0" is quite suspicious.

3. I think the label "Neighboring Cells" (in View "Cell Information" and in the Debug Log is really confusing. "Neighboring Cells" is a special term for a list that is send by the BTS to the phone - and we don't have access to this kind of data right now. As far as i can remember, we are currently saving the data from the history - like cells the phone was connected to before.
This is how we build up this list in the View "Cell Information" Is that right?
So let's discuss it - we need to get this clear for our users and also for our development.

[SecUpwN]

@He3556, thanks for filing this, I will be happy to merge a pull request to fix 1 and 2. As for your third point, how would you suggest that we should rename Neighboring Cells? Find a good name for us.

[E3V3A]

I think this may be either an OCID data integrity problem or a OCID DB import problem.

I have a similar issue where there are loads of cells with Samples: -1. As mentioned in item (13) HERE.

[E3V3A]

Thanks to THIS issue of MLS, we may have an explanation. Let's continue this investigation.

The LAI (location area identification) for UMTS mentions LAC 0x000 and 0xfffe as special reserved values stating:

"These reserved values are used in some special cases when no valid LAI exists in the MS (see 3GPP TS 24.008 [5], 3GPP TS 31.102 [27] and 3GPP TS 51.011 [9])."

We already filter out LAC = 0, but do allow both LAC = 65534 and 65535 for all networks. And we do have network entries in our data for both of these LAC values (~80 and ~2000 respectively). We need to figure out what these special cases are and if we should tighten our filter. We also need to see if similar special cases exist for other radio types.

We need to look at these docs:

• 3GPP TS 23.003 LAI (location area identification) for UMTS
• 3GPP TS 24.008 UMTS/LTE Layer 3 specification & core protocols
• 3GPP TS 24.301 LTE NAS protocol for Evolved Packet System (EPS)
• 3GPP TS 31.102 Characteristics of the USIM application
• 3GPP TS 51.011 Specification of the SIM-ME interface

[He3556]

1. We are filtering LAC = 0? But i see Cells with LAC = 0 in the "Database Viewer" > "Cell data"
2. I don't connect to UMTS - "GSM only" is switched on all the time. So the reserved LAI for UMTS can't be the reason.
   Maybe the CellID = -1 and LAC = 0 in the "Database Viewer" > "Location data" comes from the cell tracking mechanism. If the Cell didn't change since the last tracking procedure. But let's investigate this TS documents before we change anything in the code.
3. Anything above has nothing to do with the OCID DB. i was looking into the "Cell data" and "Location data" not the "OCID DB" in the "Database Viewer".

@SecUpwN Instead "Neighboring Cells" - we could call it "Cell History" that explains it much better i think.

[SecUpwN]

Instead "Neighboring Cells" - we could call it "Cell History" that explains it much better i think.

@tobykurien, do you agree with this suggestion? @He3556, I'd edit that directly on GitHub, but when messing around with the strings in CellInfoFragment.java and CellTracker.java I'm afraid the code breaks. Toby, can you tackle this with your next larger pull request? I will be buying a new development laptop next year and set that up with the latest and greatest Android Studio. Until then, please hang tight!

[E3V3A]

@tobykurien @SecUpwN @He3556
I'm in the process of finishing up the DB re-structure docs. Please wait before changing those names, to avoid confusion. The issue being we have to change a whole bunch of things, so let's try do this in a more organized way (?).

1. I finish the docs, then
2. you guys make a critical re-view and feedback
3. I make the updates
4. We re-code.

How's that sound?

[E3V3A]

@hannosch has made some further investigations. (Thanks!)

The special 0x0000 and 0xfffe values are actually described in TS 24.008 10.5.3 Location Area Identification information element [p.431] , where it says: "If a LAI has to be deleted then all bits of the location area code shall be set to one with the exception of the least significant bit which shall be set to zero. If a SIM/USIM is inserted in a Mobile Equipment with the location area code containing all zeros, then the Mobile Equipment shall recognise this LAC as part of a deleted LAI".

So both of these values mean the LAC value is "deleted" or unknown.

The same applies to the tracking area code for LTE, covered in TS 24.301 9.9.3.32 (p.286) where 0x0000 and 0xfffe have the same meaning of a "deleted" state.

For CDMA I only found parts of the standard for eHRPD which states that 0 is a reserved value indicating base stations not belonging to a network and 65535 being a reserved value used in roaming detection.

[SecUpwN]

@He3556, is this Issue still present in our current code after the commits by @Ueland?

[He3556]

thanks to @hannosch for this information. I think we can close this. But i would add a "Remember_This"

[E3V3A]

It's very funny, but on a different network monitor program, I keep seeing LAC 65535 (0xFFFE) flash by in a periodic manner. Especially when changing from HSPA to HSPA+... And that LAC is located at equator on 0 meridian and messes up the measurements. Let's keep this open until I'm done with the DBe consistency detection flowchart.