What values should the IMEI Fraud API respond with to indicate reported ownership status?

[Kevsy]

Discussion:

The IMEI Fraud API indicates whether a mobile device has been reported lost or stolen. This information is accessible to mobile operators via a lookup to the Equipment Identity Register (EIR) database. The question is what values are available to IMEI Fraud API on fulfilling an API call. for which I provide the following information

The EIR procedure is defined in 3GPP TS 29.272 , section 6.2 'ME Identity Check Procedures', with further information on the expected responses in 3GPP TS 22.016 , section 4:

Three registers are defined, known as "allowed lists", "tracked lists" and "prohibited lists". The use of such lists is at the operators' discretion.
The allowed list is composed of all number series of equipment identities that are permitted for use.
The prohibited list contains all equipment identities that belong to equipment that need to be barred.
Besides the prohibited and allowed list, administrations have the possibility to use a tracked list. Equipment on the tracked list are not barred (unless on the prohibited list or not on the allowed list), but are tracked by the network (for evaluation or other purposes).

Hence supported values for the CAMARA IMEI Fraud API should be based on (or directly reflect) one of allowed | prohibited | tracked

Informational note : the internal network lookup from MME to EIR over DIAMETER is defined in 3GPP TS 23.401

6.2.1.3 Detailed behaviour of the EIR
When receiving an ME Identity Check request, the EIR shall check whether the mobile equipment is known.
The EIR shall identify the mobile equipment based on the first 14 digits of the IMEI AVP; if a 15th digit is received in the IMEI AVP, this digit shall be ignored by the EIR.
Based on operator policies, the EIR may also use the Software-Version AVP, in addition to the first 14 digits of the IMEI AVP, to check the equipment identity against prohibited and tracking lists (see 3GPP TS 22.016 [13]).
If the mobile equipment identity is not known, a result code of DIAMETER_ERROR_ EQUIPMENT_UNKNOWN is returned.
If it is known, the EIR shall return DIAMETER_SUCCESS with the equipment status.

[eric-murray]

Oracle documentation gives the same three statuses.

So I would suggest that the API mandatorily returns one of these statuses and, if that status is tracked, optionally returns additional information on why that device is being tracked (if that is known - the EIR itself does not appear to have this additional information).

Should that additional information also be an enumerated type, or would a free text string be required? A free text string is more flexible, but also less useful, for an API, so I'd prefer to avoid that.

[rartych]

The API proposal says that fraud markers should indicate if the device is: lost, suspended, stolen, blacklisted, etc.
Such information is probably stored in CRM or other IT systems, but can be dependent on specific implementation and local regulations.
So it should be optional and the challenge is to define categories (enum values) that can be used unambiguously in all API implementations.

[eric-murray]

@rartych
We need some proper definitions for those terms. The EIR prohibited might be stolen, blacklisted, suspended or all three; tracked might be lost or maybe that is one of the etc.. Without proper definitions, we cannot make a mapping. It may indeed be that the EIR cannot (unambiguously) provide any of these statuses, in which case the API will need to rely on CRM or other proprietary systems.

I'm still waiting for any update from Waseem Amra, who submitted the proposal and should be driving this.

[eric-murray]

https://www.gsma.com/services/deviceregistry/

[sachinvodafone]

If we take into account the categories "allowed," "prohibited," and "tracked," which I believe, should include all potential scenarios then we can outline additional secondary status options as follows:

Allowed

Secondary Status	Description
Active	Currently active and authorized for network use.
Authorized	Authorized for network access.
Registered	Properly registered and approved for network use.
Verified	Verified and eligible for network access.
Approved	Approved for network use based on criteria.
Valid	Valid IMEI allowed on the network.

Prohibited

Secondary Status	Description
Stolen	Reported as stolen, not allowed on the network.
Blacklisted	Device is blacklisted due to issues or breaches.
Suspended	Services temporarily suspended for various reasons.
Fraudulent	Associated with fraudulent activities or misuse.
Blocked	Blocked from network access for specific reasons.
Non-Compliant	Non-compliant with regulatory or network standards.
Invalid	Invalid IMEI, not allowed on the network.
Unauthorized	Unauthorized device access or usage.
Unregistered	Not properly registered or approved for use.
Compromised	Device integrity compromised, not allowed.
Unapproved	Not approved for network use due to issues.

Tracked

Secondary Status	Description
Pending Investigation	Under investigation for suspicious activities.
Suspended (Temporary)	Temporary suspension of services.
Under Review	Undergoing a review process for access decision.
Non-Compliant	Non-compliant with regulatory or network standards.
Flagged	Flagged for potential issues or anomalies.
Unknown	Uncertain categorization pending further info.
Quarantined	Isolated or quarantined for security reasons.
Restricted	Access restricted due to specific criteria.
Watchlisted	Placed on a watchlist for monitoring.
Investigated	Undergoing an investigative process.

[eric-murray]

Thanks @sachinvodafone. What is the source for these secondary statuses?

[sachinvodafone]

HI @eric-murray , The secondary statuses mentioned in the earlier responses were not derived from any particular industry-standard or official documentation. I was aiming to include additional scenarios mentioned in your earlier statement, "The EIR prohibited might be stolen, blacklisted, suspended or all three; tracked might be lost or maybe that is one of the etc." These terms may often used interchangeably. Some EIRs may use additional subcodes or flags to provide more granular information about the status of a device. However, we can consolidate all potential scenarios into just three primary statuses ("allowed," "tracked," and "prohibited"), regardless of the status obtained from the Equipment Identity Register (EIR). Sorry for confusion.

[eric-murray]

OK. We always need to be thinking about how we implement such APIs.

[eric-murray]

So not only do the GSMA have a device registry, they also have an Device Check API with which to query it. That seems awfully like an "IMEI Fraud" API to me - are CAMARA just re-inventing the wheel here? I uploaded a GSMA presentation on the service here.

For reference, the different status categories they appear to register are:

Block List (i.e. prohibited)

• Lost or Stolen
• Fraudulently Obtained
• Broken or Faulty
• Court Ordered Block

General List (i.e. tracked)

• Ownership Claim
• Financial Claim

I don't have the specific implementation details, however.

[sachinvodafone]

Hi @eric-murray , Based on the details provided in this ,source, it appears that GSMA offers a web-based platform for checking device information but does not provide an API for integration. They also offer a portal specifically for Spain. In my opinion, GSMA could be considered a third-party source for such connections, as they maintain device information for numerous Opco (although not all of them). It's possible that there are other third-party entities that offer similar sets of information.

[SniffleSneeze]

Ah amazing , thanks @eric-murray to check that out.
I never had the chance to look into their specs but I agree with @sachinvodafone GSMA I believe can and should be use as a third party as their are also the aggregator for device IMEI.
On that I was wondering if you guys at the contact and power to ask GSMA to get one of their guy to join one of our call to discuss?
I reckon that would help us quite a bit.

[eric-murray]

Slide 19 of their presentation implies there is an existing API, but I don't know the commercial status of this. But they are clearly thinking about it!

Representatives from MTN (and Huawei) will be able join the meetings from next year, and will then lead this API. We can then understand better the differences between the CAMARA and GSMA APIs.

[Kevsy]

GSMA recently posted a video promoting the registry, but more use-case focused than technical. It directs interested parties to their GSMA account manager for further details.