Prepaid Short Message Service Intercept

Prepaid Short Message Service Intercept (PPSMS) is applicable to the A-Party (MSISDN) and B-Party (TP-DA of SM-RP-UI) sides of the GSM Forward Short Message.

PPSMS performs the following main functions:

Message Discrimination

PPSMS uses the G-Port message selection methods to determine whetPPSMSher the message should receive PPSMS/G-Port service versus GTT.

If the incoming selectors match a SRVSEL entry and the entry has SERV=PPSMS, PPSMS is performed. If no match is found in SRVSEL table then GTT is performed. If the SSN is for HLR, G-Port is performed. If the SSN is for MSC, PPSMS is performed, and if the SSN is for neither, GTT is performed. Next, the MAP Operation Code received in the message is examined. Only Mobile originated forward short message calls receive PPSMS service. Other messages fall through to GTT. After MAP operation code discrimination, PPSMS provides discrimination based on SCCP CgPA GTA digits. This allows the operator to decide whether messages from certain CgPAs will receive PPSMS service or fall through to GTT, even if the messages meet all of the previous service selection criteria.

Number Conditioning

The UDR stores international MSISDNs only. The received MSISDN number or SCCP CdPA digits may need to be converted to an international number to do a database lookup.

When PPSMS is required to be performed on a message and the number is not international (that is, the NAI of MSISDN number is “National (Significant) Number” or “Subscriber Number)”, the National/Local to International number conditioning is triggered.

For a National (Significant) Number, the received MSISDN digits are prepended with the default country code and for a Subscriber number, the MSISDN digits are prepended with the default country code and the default network code. If the NAI is neither International or Subscriber, the message is treated as National.

Prepaid Screening

Once the number is conditioned, the PPSMS feature performs a database search to determine if the MSISDN belongs to a prepaid subscriber. This is determined by the portability type field associated with the database entry for the MSISDN. PPSMS performs the database lookup using the international MSISDN. The individual number database is searched first, and if the number is not found, then the number range database is searched. If a match is not found in individual nor range-based database, then GTT is performed on the message. In case of MSISDN numbers in the PPSMS database being odd and the last digit of the decoded MSISDN from the FSM being 'zero', PPSMS first performs a database lookup once using the even number. If no match is found, then PPSMS performs the database lookup again, now using the odd number (without last digit).

Message Relay to IN Platform

If the database search determines that the subscriber is prepaid, the message is redirected to one of the two IN platforms using the translation data in the PPSOPTS table. If the routing indicator in the IN platform translation data is route-on-SSN, the mated application table is accessed to determine the point code/subsystem status for the IN platform, and if it has a mate. The SCCP CdPA GTA should not be changed as a result of this operation. If the RI in the translation data indicates route-on-GT, and if the Intermediate GTTLoad Sharing feature is turned on, the Mated Relay Node (MRN) table is accessed to determine the point code status and if the IN platform has a mate. Subsystem status is not maintained in the mated relay node.

Prepaid Short Message Service Intercept Message Handling

Prepaid Short Message Service Intercept (PPSMS) performs message handling in the following steps.

  1. The message arrives at the vSTP route-on-gt. The vSTP decodes the SCCP portion and uses the data to perform the G-Port selection based on the CdPA NP, NAI, TT, SSN, and GTI. The result of the selection provides a service indicator. The service indicator is PPSMS if PPSMS is required. If a PPSMS selector does not match the incoming GT fields, the message is passed on for GTT selection.
  2. If #1 indicates PPSMS is required, and the message is not a UDTS generated by vSTP, the vSTP performs PPSMS service.
  3. If the message is a UDTS generated by the vSTP, then regular GTT is performed on the message.
  4. If the vSTP receives a UDTS message from another node, it is treated in the same manner as any other message. If GTT is indicated, then the UDTS translation is based on the CdPAGTA, and the message is routed to the translated address. If GTT is not indicated, the UDTS is through switched via MTP routing. The one exception is that if translation fails on the UDTS, the vSTP will not generate another UDTS to send to the originator of the UDTS that failed.
  5. The TCAP/MAP portion of the message is decoded by PPSMS. If the message is not a TC_BEGIN, the message falls through to GTT.
  6. If the message is a TC_BEGIN, PPSMS decodes the Operation Code of the MAP message to distinguish MO_FSMs from the rest. If the OpCode is not FSM (MAP version 1 or 2) or MO_FSM (MAP version 3), the message falls through to GTT.
  7. If the OpCode is FSM (MAP version 1 or 2) or MO_FSM (MAP version 3), the MAP portion of the message is decoded and searched for a MSISDN tag. If a MSISDN tag is not found, the message falls through to GTT. For version 3 MO_FSMs, the SMRPOA parameter would contain the MSISDN tag. For version 1 or 2 FSMs, a MSISDN tag is found if the message is mobile originated. If it is mobile terminated, a MSISDN tag is not found and the message falls through to GTT.
  8. If the MSISDN is found in #7, the SCCP CgPA GTA is compared to the IN platform GTAs provisioned in the PPSOPTS table. If the decoded GTA matches one of the IN platform Gas, the message falls through to GTT.
  9. If the SCCP CgPA GTA in #8 does not match any of the IN platform GTAs, the MSISDN from the MAP portion is decoded and conditioned to an international number before performing the lookup. The number conditioning is based on NAI of MSISDN parameter. The number is converted to an international number, if necessary.
  10. The database lookup is performed in two parts:
    • The exception or individual number database is searched for a match. If the match is found, the data associated with this entry is considered.
    • If the conditioned number is absent in the exception database, the number range database is searched. If the match is found, the data associated with this range entry is considered. If the search is unsuccessful, the result is no match.
  11. If a number match is found as a result of the search, the portability type field associated with the entry is examined.
    • If the portability type is in the range of Prepaid1 to Prepaid32, the IN platform translation information (PC and RI) associated with that type is retrieved from the GSM options. If the RI is SSN, the information is used to access the mated application (MAP) table for point code status and to see if the selected IN platform is in a load sharing relationship with another. If the RI is GT, and if the IGTTLoad Sharing feature is on, the mated relay node table is used for this purpose. If the point code is available, the message is routed the IN platform. If the point code is in a load sharing relationship with other point codes, messages are equally divided between them.
    • If the portability type is not in the range of Prepaid1 to Prepaid32, the message falls through to GTT.
  12. If a number match is not found as a result of the search in #10, the message falls through to GTT.