The following flow charts provide an overview of the Velocity Check feature for Stateful Applications:

Figure 2-3 SFAPP Process Message

Figure 2-4 SFAPP Process Request

Figure 2-5 SFAPP Process HLR Response

Figure 2-6 Perform VLR Velocity Check

This use case challenges the visited VLR after the procedure for location update has been completed by asking for the subscriber’s IMEI information in a PSI message. After that, one of these actions is taken:

1. The IMEI information can then be compared against an external database to validate the IMEI and consequently the VLR by either allowing the original procedure to complete or fail it by initiating in a Purge MS operation, or
2. The IMEI information can be added to/updated in the external database if the VLR is trusted and the IMEI is validated.

Figure 2-7 shows the call flow.

Figure 2-7 Graylisted VLR Challenge

1. Incoming UL message on the LIM card, either from the VLR or SGSN, is forwarded to the SCCP card by GT routing using GTT action for SFAPP. The SCCP card uses GTT based on SFAPP action to forward the message to the SFAPP card.
2. UL message is decoded on the SFAPP card. An error is generated in case of decoding failure. Details of the decoding failure errors are described in Decoding Errors Generated EAGLE.
3. The VLR address is checked to see if it is white/gray/blacklisted in the VLR database on the card. If graylisted, IMSI and the VLR address information is stored in a local data structure for further challenging the visited VLR with IMEI information for the mobile subscriber.
4. After extracting the IMSI and VLR address, the UL message is forwarded to the CdPA(HLR).
5. UL timer of 9 seconds timeout value is started to wait for update location procedure to complete on the mobile subscriber by the visited VLR to HLR. At the expiry of the UL timer, IMEI challenge begins.
6. The IMEI information for the subscriber is retrieved from the EEDB, if present. If not found, use case 3 is terminated and no further action is taken.
7. If found, the IMEI is stored and a PSI message is encoded by EAGLE with the IMSI and VLR from the original UL message and sent to the visited VLR. The SCCP portion of the PSI message is encoded to route on SSN SFAPP. CgPA from the original UL message is copied as the CdPA. CGPA is created from the psirescgmodid parameter of ent-gtmod command. TCAP layer of the PSI message is filled with the PSI opcode and IMSI tag/length/value, and requested information in the component portion is updated with IMEI tag/length fields. Transaction ID for an outgoing PSI message is encoded as described in Routing of PSI Response Back to Originating SFAPP Card.
8. Encoded PSI message is routed on SSN SFAPP to the SCCP card and is further GTT routed on to the visited VLR by the LIM card. A transaction timer of 4 seconds timeout (with a unique transaction_id) is started to track the PSI message sent. If the timer expires, the challenge is considered to have failed and a purgeMS is generated as described in 13.
9. When a PSI ACK arrives at EAGLE, upon arrival of the MSU at the SCCP card, if the mate_id in the TCAP transaction ID matches with the stored STP_ID of EAGLE, PSI ACK is sent to the SFAPP card. The details of the implementation of this functionality on the SCCP card is discussed in Routing of PSI Response Back to Originating SFAPP Card.
10. FAILACTID is enforced on the SFAPP card for the IMEI challenge just like in the case of velocity check challenge. If the IMEI decoded from the PSI_ACK does not match the IMEI retrieved from the EEDB and the VLR is graylisted, the provisioned FAILACTID is enforced.
    1. If the FAILACTID is FALLBACK, then the PSI_ACK is not decoded (for example, no further data is decoded from the PSI_ACK) and the IMSI is not marked with an ms_purged_flag in HLR.
    2. If the FAILACTID is DISCARD, then it is used to send a purgeMS message to the HLR for a given IMSI.
11. If the FAILACTID is not provisioned by the customer, every PSI_ACK message is decoded at the SFAPP card by matching TID (transaction_index) in the TCAP information with the appropriate PSI_ACK_TID and looking for PSI map_opcode to look for the IMEI tag in the ACK message. If the IMEI tag is present and the value matches with what was retrieved from the EEDB, the IMEI challenge is considered as passed. An absent IMEI tag in the PSI_ACK is considered a failure.
12. An IMEI challenge failure results in generating another ATI to the HLR (as in use case 2) to verify the subscriber’s current VLR. Upon receiving the ATI ACK or a timeout, a purgeMS is sent by EAGLE to the HLR. The encoding of the purgeMS message is as follows:
    1. HLR address (CdPA - used at SCCP layer) is obtained by the saved copy of the UL message in the local data structure.
    2. CgPA is the EAGLE self PC.
    3. The SCCP portion of the PSI message is encoded to route on SSN SFAPP.

    Note:

    If the timer for the ATI ACK expires, no UIM displays indicating the expiration.
13. If the challenge has failed, the SFAPP categorizes the VLR as an intruder and generates a purgeMS message to the HLR for the subscriber from the original UL. The purgeMS incorporates the IMSI tag/length/value. The important piece in the TCAP layer component portion is msPurgingContext 5 bytes value which is as follows: 0x02-operation tag 0x01-length, 0x43-purge MAP opcode 0xa3-sequence tag, 0x00-length. There is no requested information built into the purgeMS message at the TCAP layer. EAGLE does not expect and process response from HLR for purgeMS. Hence, the transaction ID at the TCAP has 4 bytes OTID as 'ff ff ff ff' to indicate an INVALID TID.
14. HLR marks the mobile subscriber as MS_purged_flag so that any request for routing information for a mobile-terminated call or mobile-terminated short message is treated as if the MS were not reachable.

The following decoding errors can result from the call flow:

• As a special identification aid, a special TCAP/MAP invoke_id is embedded in the PSI message as a special fixed value. This invoke_id is not user configurable.
• When the PSI_ACK returns to the SCCP card, if the map_opcode is not present, the combination of the special invoke_id/TCAP_END and return_result_last is used to validate that the PSI_ACK received has been generated by the Eagle and the PSI_ACK can be decoded for IMEI validation.

Transaction ID Encoding and Decoding

The SFAPP card encodes the Originating Transaction ID in the PSI message in this format to identify the STP Node that generated the message:

struct {
t_u8 card_loc;
t_u8 ref_count:4;
t_u8 mate_id:4;
t_u16 trans_index;
}field

The Mate ID is the index of the location of the STP’s self ID provisioned in the STP mate table. The mate table is populated with the STP’s mate point codes as well as its own. If the mate tables of each STP that forms a pair/quad contains the same point codes, the order of the tables for each node is guaranteed to be the same.

PSI Response Handling on SCCP Card

As indicated in Figure 2-8, an IPSM card that is configured with a TCP connection will maintain a connection to an external database containing IMSI/IMEI data indexed by IMSI. To support IMEI validation when a VLR is graylisted, the SFAPP card will generate an addition or an update containing the subscriber data that is then routed to the EEDB via the IPSM card if the VLR has been determined to be whitelisted (learning).

Figure 2-8 Whitelisted VLR DB Learn - Whitelisted VLR DB Learning

When the UL message has been intercepted by EAGLE, if the VLR is determined to be whitelisted, a query to the EEDB is launched. If the IMSI is not found, when the IMEI is extracted from the PSI_ACK, it is added to the EEDB. If it was found and the data matched to that returned in the PSI_ACK, the record in the EEDB is updated with aging data.

Secondary SFAPP Cards

Figure 2-9 shows the VLR challenge flow including learning.

Figure 2-9 Dynamic VLR learning (VLR Whitelisting)

When a new VLR in the incoming network message is received on a secondary SFAPP card, the VLR is first searched in the dynamic VLR profile table. If exact match is found, a control flag - for example, dynamic_entry_found - is set and a subsequent static VLR profile table search is applied. If an exact match is NOT found, the new VLR is added to a buffer, but the static VLR profile table search is still applied. In static table search, there can be three cases:

• Complete match found: If complete match is found, nothing needs to be done.
• Partial match found: If partial match is found, use the best matching partial static VLR profile entry.
• No matches found: If no matches are found for new VLR in static VLR profile table, check the value of dynamic_entry_found flag.

Primary SFAPP Cards

Secondary SFAPP Cards

Figure 2-10 shows the VLR velocity check flow.

Figure 2-10 VLR Velocity Check

The dynamic VLR roaming table is used on these occasions:

• When both new VLR and old VLR are found in the dynamic VLR profile table.

  In this case, we look up the dynamic VLR roaming table with the dynamic VLR profile table indices of new VLR and old VLR to get threshold and subscriber state. If the threshold value is less than or equal to the age of location found in the ATI ACK, then VLR validation is considered successful.

• When one VLR is found in the dynamic VLR profile table and the other VLR is found in the static VLR profile table.

  In this case, the VLR entry found in the static VLR profile table is duplicated into the dynamic VLR profile table on that SFAPP card. This is done so as to obtain both new and old VLR indices from the same profile table.

  For example, say new VLR is found in the dynamic profile table, but the old VLR is found in the static profile table. We replicate the old VLR entry from the static profile table into the dynamic profile table and get the indices of both the new VLR entry and the newly-created old VLR entry from the dynamic profile table. With these indices, the search is performed in the dynamic VLR roaming table to get the threshold, subscriber state, and last activity time.

Primary SFAPP Cards

The syncing of the dynamic VLR roaming table is the same as that of dynamic VLR profile table.

With this feature, SFAPP cards are now split into two groups: Primary - having only one member, and Secondary - all other SFAPP cards. To select the primary, the general rule is one having the lowest IMT address is designated as the primary SFAPP card, but if any SFAPP card having higher IMT address becomes active before others and primary cards selection procedure completes on it before other SFAPP cards becomes active, then that SFAPP card continues to be a primary SFAPP card and all the other cards are designated as secondary SFAPP cards. The primary SFAPP card has numerous responsibilities for dynamic VLR information management and therefore, does not process any traffic - its primary duties are to collate the updates from the secondaries and act as a sync between the secondaries and OAMs. The secondary SFAPP cards, however, are the ones that process traffic to inform primary SFAPP card of the new VLRs they have learned individually over time.

Dynamic entries have an aging process applied to remove dynamic VLR entries, which do not get referenced. An agetime parameter is added to the new SFAPPOPTS command to define an age limit that a dynamic VLR entry must be referenced (updated) within to avoid being aged out/removed.

The aging process is performed per the time interval set in the agetime (in hours) parameter in SFAPPOPTS table. The primary SFAPP card performs the ageing mechanism on dynamic VLR profile and roaming tables by deleting the entries, which were not referenced for the duration set in agetime. Once the ageing mechanism completes on primary SFAPP card, it then syncs the complete tables with secondary SFAPP cards and OAM using the table copy mechanism.

The ageing mechanism is overloaded with the one-hour primary SFAPP to OAM sync. When ageing and one-hour sync intersect, then only the ageing mechanism is performed since it also covers the one-hour sync mechanism.

Dynamic VLR Table Sync with Primary SFAPP Card

There are two processes on the OAM where dynamic updates and the use of dynamic VLR tables are used.

The primary SFAPP card has a 1-hour timer, on expiry of which it begins the dynamic VLR profile table sync between itself and the active OAM. The beginning of the hourly sync process is indicated using a UIM. At 1-hour timer expiry, the primary SFAPP card sends a signal to the active OAM to indicate the start of the dynamic VLR table sync cycle. On receiving this signal, OAM checks if there are any pending updates that need to be done on dynamic VLR table before sync begins. If there are no updates, the OAM sends back an ACK informing the primary SFAPP card that it is ready for syncing. If there are pending updates, those updates are processed before sending out the ACK. On receiving the ACK from OAM, the primary SFAPP card initiates table copy mechanism and sends three dynamic VLR tables (dbmm, profile, and roaming) to the OAM. The OAM then refreshes its RAM and binary trees. Once the RAM copy of dynamic VLR profile table on the active OAM is updated, the active OAM then sends the updated dynamic VLR profile table to the standby OAM. The standby OAM writes the table in the RAM first and then to its disk.

During this process, access to the dynamic tables must be controlled and no other access can be allowed. Therefore, the following commands are inhibited:

The sync process start is signaled by issuing UIM 1316, and sync completion by UIM 1317.

Dynamic VLR Table Sync with Secondary SFAPP Card

When all SFAPP cards are initialized, they download all the required static tables from the OAM. But the OAM sends the dynamic VLR tables only to the primary SFAPP card. It is the responsibility of the primary SFAPP card to send the dynamic VLR tables to the secondary SFAPP cards. When the secondary SFAPP cards have downloaded the entire dynamic VLR table from the primary SFAPP card, they transition into IS-NR state and start processing traffic for autonomous learning. This mechanism helps to minimize the possibility of single/multiple SFAPP cards going out of sync with other SFAPP cards as well as the OAM.