1. Virtual Signaling Transfer Point
  2. Overview of vSTP
  3. Stateful Application Feature
  4. Velocity Check

2.8.3 Velocity Check

The Velocity Check use case uses the information stored in HLR about the current VLR and the age of location parameter to identify if the new VLR is reachable from the current VLR stored in HLR.

This use case is dependent on the validity of the information stored in the VLR and the T3212 timer (periodic update location timer). This timer governs the rate at which the mobile subscriber autonomously updates their location. In case the time distance between two networks is less than the value of T3212 timer configured for the network, this use case test would provide false positives since the location age information would not have been properly updated in the VLR.
The assumption for successful execution of this use case are:
  • The First location update can be identified using the IMSI only in the address.
  • The Age of Location provided by HLR is accurate.
  • The quantum of information (Age of Location) will not be less than the time to get travel.
The vSTP Call flow for Velocity Check, can be completed in a reasonable amount of time for Location Update to succeed.
The vSTP Call flow for Velocity Check, first lookup the Common DB that is UDR, for IMSI. If the record is available in UDR, then the ATI is not sent to HLR and the UDR information is used further. But, in case the record is not available in UDR, then ATI is sent to HLR.

In both the scenarios, the UDR is updated in case of successful validation. If record is not found in UDR and validation is successful through ATI, then a new record is created in UDR with that IMSI. In case the IMSI record is available in UDR and validation is successful, then the last updated time of the record is updated in UDR.

Both the scenarios of vSTP call flow for VLR Validation are described below:
  • vSTP Call Flow for Velocity Check - When no IMSI record is found in Common DB
    The following figure shows the vSTP call flow when there is no record available in Common DB:

    Figure 2-11 Velocity Check - vSTP Call Flow when IMSI Record is not Found in UDR


    img/velocity-check-no-records-found.jpg

    1. A local database on vSTP will be configured to identify the network locations (using country codes for VLR addresses) and the shortest amount of time it may take to travel between them.
    2. The incoming message will be decoded:
      1. An Error will be generated in case of decode failure.
      2. A Measurement will be pegged for the decode failure with OpCode and CgPA.
    3. The message information will be stored in the local database.
    4. The request to get the IMSI information is generated towards UDR.
    5. If the IMSI record is not found in UDR, the ATI request will be generated toward the HLR identified in the CdPA of the incoming message. The ATI request will be coded so that it is received on the same MP, as DB is local.
    6. In case the HLR sends a failure in the ATI response:
      1. A measurement will be pegged to identify HLR error corresponding message from CgPA (VLR).
    7. For a success response, extract the Age of Location from the ATI Response message and the VMSC address in the HLR.
    8. A record is created in UDR for the IMSI after successful validation.
    9. In case the VLR from which the SAI/LU was received matches the VLR in the ATI response, do nothing.
    10. In case the VLR addresses do not match:
      1. Calculate the time difference between the current time and the Age of Location.
      2. Verify the Age of Location is less than the travel time configured in the local database.
      3. Calculate the distance between two country codes using Havrshine Formula. Longitude/Latitude values are retrieved from database for corresponding entries.
      4. In case the time value is not within limits:
        1. The validation gets failed.
        2. A measurement will be pegged.
        3. Response will be generated based on the configured option.
    11. If validation is successful, forward message to HLR and update the UDR with relevant data with VLR number, last updated Network, last update time.
  • vSTP Call Flow - When IMSI record is found in Common DB
    The following figure shows the vSTP call flow when the IMSI record is available in Common DB:

    Figure 2-12 Velocity Check - vSTP Call Flow when IMSI Record Found in UDR


    img/velocity-check-imsi-number-found.jpg

  1. A local database on vSTP will be configured to identify the network locations (using country codes for VLR addresses) and the shortest amount of time it may take to travel between them.
  2. The incoming message will be decoded:
    1. An Error will be generated in case of decode failure.
    2. A Measurement will be pegged for the decode failure with OpCode and CgPA.
  3. The message information will be stored in the local database.
  4. In case VLR address do not match:
    1. Lookup into SfappCCMCCMap table and for corresponding country codes and retrieve the MCC.
    2. The exception or neighboring list table is checked for with old MCC, if it is available in neighboring list then do nothing. Else, the following step will be performed.
  5. The exception or neighboring list table is checked for with old MCC, if it is available in neighboring list then the process ends. Else, the following step will be performed.
  6. The distance between 2 country codes is calculated using Havrshine Formula. Use Longitude/Latitude values from database.
  7. The Time ( = Distance / Velocity) shall be calculated and used to authenticate the subscriber location.
  8. Validate the last time distance check based on last location with the VLR address received in the incoming message.
  9. In case the VLR addresses do not match:
    1. Calculate the distance between 2 country codes using Havrshine Formula using longitude and latitude values (from SfappLongLat MO).
    2. Calculate the time using distance calculated from above point and travel_velocity value from vSTPSccpOptions MO.
    3. Verify that Time calculated in point b is less than the (current time -last update time from UDR).
  10. If validation is successful forward message to HLR and update the UDR with relevant data with VLR number, last updated Network, last update time.
  11. In case the validation failed,
    1. A measurement will be pegged.
    2. Response will be generated based on the configured option.

Note:

  • The T3212 timer is responsible for periodic location update for subscribers. If the timer is set to a value greater than the shortest travel time value between two network locations, then the location validation in the use case fails.
  • Results of the use cases depends on the pre-configured values of SfappCCMCCMAP, SfappCountryLongLat, SfappCountryCodes, and SfappNeighboringCountries entries.