G-Port MNP Overview

The Global System for Mobile Communications (GSM) Mobile Number Portability (G-Port) feature implements MNP for GSM networks according to ETSI GSM 03.66. In response to governmental mandates for telecommunication networks, this feature focuses on service provider number portability on GSM networks.

G-Port minimizes the challenges for GSM network operators while enabling them to meet regulatory obligations. G-Port supports the Signaling Relay Function (SRF) for direct and indirect routing. SRF-based MNP processing examines MAP messages for ported numbers. For call-related messages, G-Port acts as an NP HLR for exported number by responding with a MAP SRI message; G-Port performs a message relay function for calls to imported numbers and non-call related messages.

The G-Port feature allows subscribers to be moved easily from one Home Location Register (HLR) to another. The G-Port feature applies to ANSI, ITU-I (international), and ITU-N (national) networks.

G-Port performs a number of actions based on the message received and the number status:
  • If the number is ported-out or not known to be ported and the message received is a call-related SRI (not-SOR), G-Port sends the SRI Ack message to the MSC with the Routing Number (RN) information in the MAP portion of the message.
  • If the number is ported-out and the message received is non-call related (non-SRI), G-Port relays the message and forwards the translated message based on the RN information.
  • If the number is non-ported or ported-in, then G-Port performs an HLR translation and forwards the translated message to the HLR.

An additional user option allows the user to configure the G-Port to modify the processing. If the number is not found in the UDR (Number Portability Database) NPDB (individual or range), then G-Port returns a negative acknowledgement in response to an SRI.

Message Verification/Decode

  • MTP/SCCP Verification

    vSTP does not perform any additional MTP/SCCP verification for G-Port. G-Port uses the information decoded by SCRC.

  • General TCAP/MAP Verification

    TCAP/MAP verification is performed on all messages.

    Any error found in the message verification process does not generate any error responses. G-Port aborts verification and performs message relay on the message using the decoded SCCP information. The Event information is printed to report the error.

  • MAP Verification

    G-Port performs no MAP verification like validation of ACN or decoding of user information. G-Port looks at the operation code of the message to distinguish SRI messages from all other messages. After determining the operation code to be SRI, G-Port looks for the presence of an OR Interrogation Parameter to further distinguish an SRI from an SRI for Optimal routing (SRI-SOR) message. If the OR Interrogation is present or if operation code is not an SRI, then the G-Port message relay is performed. Otherwise, SRI-specific verification is performed.

  • SRI-Specific Verification

    This verification is performed only for SRI messages. G-Port looks for only the MSISDN parameter. It does not look for the existence of any other parameter even if they are mandatory.

    Any error found in this part of the verification process would cause the SRI message to be discarded and an appropriate SRI negative response message is sent back.

Message Handling

  • RN Prefix Deletion
    • SRIDN = 'SCCP'

      The decoded SCCP CdPA digits may have an RN concatenated with the MSISDN number in two forms 1) RN+DN 2) CC+RN+DN. So, when the SNAI is either RNIDN or RNNDN or RNLDN, G-Port compares the decoded MSISDN number with the list of provisioned home RN prefixes defined in the NPDB. If a match is found, then G-Port strips the RN digits from the number. Number conditioning (if required) is performed after deleting the RN. When SNAI is CCRNDN, G-Port first compares the CC to DEFCC/MultCC list. If CC does not equal DEFCC/MultCC, then no prefix deletion is performed and G-Port processing continues. If CC equals DEFCC/MultCC then, G-Port compares the digits after CC with the list of provisioned home RN prefixes defined in the NPDB. If a match is found, then G-Port strip the RN digits from the number. If no match, then no prefix deletion is performed and G-Port processing continues.

    • SRIDN = 'TCAP'

      The decoded MAP MSISDN digits may have an RN concatenated with the MSISDN number in two forms. 1) RN+DN 2) CC+RN+DN. The MAP NAI is used to determine the type: international, national, or subscriber. If VstpMnpOptions:MNPCRP is OFF, RN prefix deletion is not attempted. If VstpMnpOptions:MNPCRP is ON, then RN prefix deletion is attempted on all MSISDNs. If the MAP NAI indicates international, then a check is performed for DEFCC/MultCC prefix on the MSISDN. If DEFCC/MultCC is detected, then HomeRN deletion is attempted using the CC+RN+DN format. All other MSISDNs use the RN+DN format. G-Port compares the decoded MSISDN number with the list of provisioned home RN prefixes defined in the NPDB. If a match is found, the G-Port strip the RN digits from the number. Number conditioning (if required) is performed after deleting the RN. If CC+RN+DN search is performed, G-Port compares the digits after CC with the list of provisioned home RN prefixes defined in the NPDB. If a match is found, G-Port strips the RN digits from the number. If no match is found, then no prefix deletion is performed and G-Port processing continues.

      The RN Prefix deletion for SRI_SM, when SRISMDN= SCCP or TCAP, will work in the same manner as it works for SRI message when SRIDN=SCCP or TCAP respectively.

  • Number Conditioning

    UDR NPDB 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 G-Port is required to be performed on a message and the number is not international (for example, NAI of MSISDN number is National (Significant) Number or Subscriber Number or SNAI is NATL or SUB or RNNDN or RNLDN), then the national/local to international number is triggered. For a national (significant) number, the received CdPA/MAP MSISDN digits are prepended with the default country code; and for a subscriber number, the CdPA/MAP MSISDN digits are prepended with the default country code and the default network code.

  • Database Lookup
    G-Port performs the UDR NPDB 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 and range based database, then GTT is performed on the message. In case of MSISDN numbers in the UDR NPDB database being odd and CdPA GTI of the incoming being 2 and the last digit of the number is zero, G-Port first performs a database lookup once using the even number. If no match is found then G-Port again performs the database lookup now using the odd number (without the last digit).

    Table 2-1 Action on Database Lookup Result

    Message Type MSISDN Found Entity Result Portability Type Result VstpMnpOptions:MNPCRP ON and HomeRN Deleted from Received DN Action
    SRI Yes RN N/A No

    SRI Ack message using RN prefix.

    NPS is encoded only if these PT values are present with MSISDN:
    • PT=0,1,2 and VstpMnpOptions table option ENCODENPS is ON

      OR

    • PT=null and VstpMnpOptions table option ENCDNPSPTNONE is ON.

    For PT=null, NPS has a value of 0

    SRI Yes RN N/A Yes Issue Event #70304 and fall through to GTT
    SRI Yes SP N/A N/A Forward SRI message to the destination using SP data
    SRI Yes None 0, 1, 2, or null No SRI Ack message using MSISDN. PT=none maps to NPS=0 in response. PT=0/1/2 has the values of 0/1/2
    SRI Yes None >2 N/A Fall through and perform GTT
    SRI Yes None 0, 1, 2, or null Yes Issue Event #70304 and fall through to GTT
    SRI No N/A N/A N/A Fall through and perform GTT
    Non-SRI or SRI-SOR Yes RN N/A No Forward the message to the next node using RN data
    Non-SRI or SRi-SOR Yes RN N/A Yes Issue Event #70304 and fall through to GTT
    Non-SRI or SRI-SOR Yes SP N/A N/A Forward the message to the destination using SP data
    Non-SRI or SRI-SOR Yes None N/A No Fall through and perform GTT
    Non-SRI or SRI-SOR Yes None N/A Yes Issue Event #70304 and fall through to GTT
    Non-SRI or SRI-SOR No N/A N/A N/A Fall through and perform GTT
  • Modification of SCCP CdPA
    vSTP supports the configuration for new Numbering Plan (NP), Translation Type (TT), and Nature of Address Indicator (NAI) at UDR. UDR also provides an option to cancel GT in the Base Set field of Subscriber Entity for MnpSPRN and MnpGRN Entities. This allows G-Port to modify entire SCCP CdPA part of relayed messages. The SCCP CdPA part of a message consists of the following configurations:
    • Translation Type
    • Numbering Plan
    • Nature of Address Indicator

    If new values are specified for NAI, NP, or TT, message relay modifies that particular field of the CdPA part. Also, the entire CdPA Global Title is deleted when the Cancel GT option is specified. This is applicable, when the Signaling Point (SP) entity received after UDR lookup has RI = 1, such as route ON SSN.

    This functionality also enables configuration of MXXSETID in SP entity data to be used further if the data related to the same ID is configured in vSTP MAP or MRN Set Tables.

    The following points must be considered for this functionality:
    • CGGT option is applicable on CDPA part of the relayed message if RI = 1. For example, route ON SSN
    • New Numbering Plan, New Translation Type, New Nature Address Indicator can only be applied to CDPA part of the relayed message if entity data has RI = 0. For example, route on GT
    • MXXSETID can be applicable on CDPA part of the relayed message if RI = 1. For example, route ON SSN
    • Both New Number plan and New Nature of Address Indicator can be applied to the CDPA of relayed message if GTI =4 in the incoming Message

    The new fields can be configured in SRPN entity data in UDR > Configuration > Subscriber Query and Provisioning > Create Profile / Add Entity section for MNP SPRN select type.

    Example:

    <?xml version="1.0" encoding="UTF-8"?>
    <MnpSPRN>
        <Type>SP</Type>
        <EDigit>654321</EDigit>
        <RI>0</RI>
        <PC>0-255-4</PC>
        <PCDom>itui</PCDom>
        <SSN>7</SSN>
        <SRFIMSI>11232311</SRFIMSI>
        <DigAct>INSERTENTITYID</DigAct>
        <NNP>3</NNP>
        <NTT>8</NTT>
        <NNAI>23</NNAI>
        <MXXSETID>2</MXXSETID>
    </MnpSPRN> 
    

Mobile Terminated GSM SMS NP

MT-SMS messaging involves the SMSC or MMSC querying the HLR for destination subscriber for SMS delivery. For the GSM network, these query messages are called SRI_SM. The HLR response to these messages includes routing information that can be used by the query generator (SMSC) to deliver the SMS message. The G-Port service intercepts these MT-SMS messages destined to the HLR and replies with routing information for out-of-network destination subscribers.

The MT-SMS NP feature:

  • Intercepts SMS routing information request from SMSC/MMSC before it reaches the HLR.
  • Extracts the message destination address (MAP MSISDN or SCCP Called Party GTA based on SRISMDN parameter value in VstpMnpOptions table), conditions the digits, and performs the lookup in the NPDB.
  • For destination address/subscribers belonging to foreign networks, sends a reply message to the SMSC/MMSC with routing information. This information can be used by the SMSC to route the message to their recipient networks using protocols like SMPP.
  • For in-network destination addresses, the SMS routing information request is relayed to the HLR.

MT-SMS NP Processing

The SMSC (or MMSC) sends the SRI_SM message to vSTP (with a destination of the HLR) with SCCP CdPA GTA (or MAP MSISDN based on SRISMDN parameter value in VstpMnpOptions table) as the DN of the destination subscriber to be GT routed to the HLR.

The service selector configured to channel MSUs to the G-Port service has a service NAI (SNAI) parameter.

Existing handling of SRI_SM for GT-routed, ANSI/ITU MTP/SCCP, ITU TCAP/MAP, encapsulated in either non-segmented XUDT or UDT SCCP message type, matching G-Port service Selector involves detailed MSU decode/encode information.

Figure 2-1 G-Port SMS-MT Processing for No Entity Case

img/g-port-sms-mt-processing-no-entity-case.png

If an entity was found in the UDR NPDB lookup, the existing behavior of G-Port is to check for MNP Circular Route Prevention, or generate SRI_SM_NACK. If NACK is not required, relay the message to the node specified by EPAP entity. In case G-Port fails to relay the message, it falls through to the GTT. This is the default existing G-Port relay mechanism for SRI_SM message.

Figure 2-2 G-Port SMS-MT Processing for Entity Found Case

img/g-port-sms-mt-processing-entity-found-case.png