2.8.2 VLR Validation

The VLR Validation uses the information stored in the HLR about the current VLR to validate the VLR from which the message is received.

The vSTP Call flow for VLR Validation first lookup the Common DB that is UDR for IMSI. If the record is available, 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. Both the scenarios of vSTP call flow for VLR Validation are described below:

• vSTP Call Flow - When no record is found in Common DB

  The following figure shows the vSTP call flow when IMSI record is not available in Common DB:

  Figure 2-9 VLR Validation - vSTP Call Flow when No IMSI Record Found in UDR

  
  

  

  
  
  1. The incoming message will be decoded.
     1. An Error will be generated in case of decode failure.
  2. The message information will be stored in the local database.
  3. The request to get the IMSI information is generated towards UDR.
  4. If the IMSI record is not found in UDR, the Any Time Interrogation (ATI) request will be generated towards the HLR.
     1. The ATI Request will be coded so that Acknowledgment is received on the same MP, as the DB is local.
  5. For a successful response from the HLR:
     1. The ATI Response will be decoded to get the current VLR address.
     2. The current VLR address will be compared with the CgPA stored in the local database for the subscriber.
     3. On a successful Match, forward the message stored in the local DB to HLR. The UDR is updated with the new IMSI record by sending Update or Create Event to UDR corresponding to IMSI of query message.
     4. In case of failure,
        1. Send the configured response.
        2. Increment the measurement for failed messages.

  The ATI sent to HLR must be formatted as follows:

  1. MTP OPC=vSTP SID, MTP DPC = HLR PC
  2. SCCP CGPA (RI = SSN, PC = Local Signaling Point SID, SSN = <SSFAPP SSN>, SCCP CDPA (received message CDPA)
  3. TCAP BEGIN with valid MAP dialogue portion (as per MAP specification)
  4. TCAP DTID = unique OTID generated for each ATI (The DTID will not be reused within 4.5 seconds)
  5. ATI details: IMSI = IMSI/MSISDN received in received message, and other mandatory parameters

  The Local Signaling Point will validate the ATI_ACK received from the HLR. A valid ATI_ACK message is defined as:

  1. It is a well formatted ANSI or ITU SCCP UDT, non-segmented XUDT message, with a valid TCAP END message, with valid dialogue portion, and single component in the component portion as return result with operation code = ATI_ACK
  2. Value of DTID received in TCAP END matches with one of the ongoing transactions
  3. Component type is a return result and contains ATI_ACK.
  4. VMSC digits are received in ATI_ACK
• 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-10 VLR Validation - vSTP Call Flow when IMSI Record is Found in UDR

  
  

  

  
  

1. The incoming message will be decoded.
   1. An Error will be generated in case of decode failure.
2. The message information will be stored in the local database.
3. The request to get the IMSI information is generated towards UDR.
4. The current VLR address from UDR response will be compared with the CgPA stored in the local database for the subscriber.
5. On a successful Match,
   1. Forward the Message stored in the local DB to HLR.
   2. The UDR is updated with the latest timestamp for this IMSI record by sending Update event .
6. In case of failure,
   1. Send the configured response.
   2. Increment the measurement for failed messages.