1. Equipment Identity Register User Guide
  2. Feature Description
  3. EIR Call Flows
  4. SS7/Sigtran EIR Call Flow

2.2.1 SS7/Sigtran EIR Call Flow

When a handset roams into a new MSC/VLR area, it attempts a registration procedure with the VLR. In a network without the EIR function, this procedure results in the VLR sending a location update message to the HLR providing the HLR with the current MSC location of the Mobile Station (MS)/handset. When the EIR function is deployed in a network, this registration procedure is interrupted to validate the IMEI of the MS/handset attempting to register before completing the registration procedure and updating the HLR.

In the network with EIR, the MSC/VLR sends a MAP_CHECK_IMEI message to DSR requesting EIR processing before sending a location update to HLR. This message contains, at a minimum, the IMEI of the MS attempting registration. It may also contain the IMSI of the subscriber whose SIM card is currently being used in the MS/ handset. Upon receipt of this message, EIR searches the White, Gray, and Black Lists for a match on the IMEI. EIR then returns a response to the MSC. Depending upon the result of the search, the response contains either the equipment status of the MS/handset (whether the IMEI for the MS/handset is allowed or not based on its status in the White, Gray, or Black Lists), or a user error (invalid or unknown IMEI). The MSC then either continues the registration procedure (if the IMEI is allowed) or rejects it (if the IMEI is disallowed, invalid, or unknown).

If the IMSI is also included in the message, EIR attempts to match this IMSI to one provisioned with the IMEI before sending a response to the MSC. A match on IMSI overrides any Blacklist condition found based on the IMEI match alone and causes a response of MS allowed.

Figure 2-1 illustrates the steps for the vSTP EIR call flow process.
  1. MSC sends a CheckIMEI request to vSTP-MP over SS7 links.
  2. vSTP-MP queries the UDR NOAM for IMEI/IMSI DB. The query is sent to all UDR NOAMs in primary and secondary sites in a round-robin manner. vSTP-MP uses the ComAgent StackEvent request to query the UDR database.
  3. UDR NOAM looks up the IMEI/IMSI database and sends a response to the vSTP-MP. The response to vSTP-MP is then sent as a ComAgent StackEvent response.
  4. EIR on vSTP-MP receives the response from UDR; applies the business logic on the received ComAgent StackEvent response; creates a SS7 CheckIMEI response message; and encodes it to send to MSC.

Figure 2-1 vSTP EIR Call Flow

img/eir-call-flow-part-2.png

The UDR information contains the list of IMEIs and an indication to the list where they are located. UDR contains two types of IMEIs: Individual IMEIs (Table 2-1) and ranges of IMEIs (Table 2-2). The Individual IMEIs are searched first. The IMEI entries in this list may also contain an association to an IMSI. If no individual IMEI match is found, IMEI ranges are searched.

EIR can support up to 100 million subscriber entries, including both individual IMEI and a range of IMEIs.

Table 2-1 Example of Individual IMEIs

IMEI IMSI (optional) White List Gray List Black List
12345678901234 495867256894125 No No Yes
234567890123456   No Yes No
49876523576823   No Yes Yes
68495868392048 495867565874236 Yes Yes No
29385572695759   Yes Yes Yes

As shown in Table 2-1, it is possible for a given IMEI to be on more than one list (on the Whitelist, and also on the Gray and/or Black List). The logic illustrated by Figure 2-1 is used to determine which answer to return in the CHECK_IMEI response, determined by which list or lists the IMEI is on. Table 2-2 also shows three possible EIR response types. The EIR response type is a system-wide EIR option that is configured by the user. The combination of the setting of the EIR response type, the list or lists in which the IMEI is located, and the optional IMSI check determines the response returned to the querying MSC.

Table 2-2 Logic for IMEIs in Multiple Lists

Presence in List EIR Response Type
White Gray Black Type 1 Type 2 Type 3
X     in White List in White List in White List
X X   in Gray List in Gray List in Gray List
X X X in Black List in Black List in Black List
X   X in Black List in Black list in Black List
  X   in Gray List in Gray List Unknown
  X X in Black List in Black List Unknown
    X in Black List in Black List Unknown
      in White List Unknown Unknown

Example Scenarios

Example One
  1. A CHECK_IMEI is received with IMEI = 49876523576823, no IMSI in message.
  2. An individual IMEI match is found (Table 2-1, entry 3) indicating the IMEI is on the Gray and Black Lists.

    The EIR Response Type is set to Type 3 and an IMSI is not present.

  3. Table 2-2 indicates the required response is Unknown.
  4. EIR formulates a CHECK_IMEI error response with Error = 7 Unknown Equipment
Example Two
Example 2 is the same as Example 1, except that the setting of the EIR Response Type is re-provisioned by the operator to Type 2.
  1. A CHECK_IMEI is received with IMEI = 49876523576823, no IMSI in message.
  2. An individual IMEI match is found (Table 2-1, entry 3), indicating the IMEI is on the Gray and Black Lists.

    The EIR Response Type is set to Type 2, and an IMSI is not present.

  3. Table 2-2 indicates the required response is Blacklisted.
  4. EIR formulates a CHECK_IMEI response with Equipment Status = 1 Blacklist.
Example Three
  1. A CHECK_IMEI is received with IMEI = 12345678901234, and IMSI = 495867256894125.
  2. An individual IMEI match is found (Table 2-1, entry 1) indicating the IMEI is on the Blacklist.
  3. The EIR Response Type is set to Type 1.
  4. Table 2-2 indicates that the normally required response would be Blacklisted; however, because an IMSI is present in the message, and the IMEI is on the Blacklist, the IMSI is compared to the IMSI entry in the database for this IMEI.
  5. In this case, the IMSI in the RTDB matches the IMSI in the query, thus the Blacklist condition is cancelled.
  6. EIR formulates a CHECK_IMEI response with Equipment Status = 0 Whitelist.
Example Four
  1. A CHECK_IMEI is received with IMEI = 12345678901234, and IMSI = 495867256894126.
  2. An individual IMEI match is found (Table 2-1 entry 1), indicating the IMEI is on the Blacklist.
  3. The EIR Response Type is set to Type 1.
  4. Table 2-2 indicates that the normally required response would be Blacklisted, however; because an IMSI is present in the message, and the IMEI is on the Blacklist, the IMSI is compared to the IMSI entry in the RTDB for this IMEI.
  5. In this case, the IMSI in the RTDB does not match the IMSI in the query, the Blacklist condition is maintained.
  6. EIR formulates a CHECK_IMEI response with Equipment Status = 1 Blacklist.