Teraquant 'No Fluff' Blog

In Teraquant’s recent “Local Number Portability and How to Troubleshoot” No Fluff Tech Tip, we provided technical guidance on how to troubleshoot Local Number Portability (LNP) when transported over the ISUP/SS7. In this No Fluff Tech Tip, we show you how to troubleshoot and verify LNP is working well over SIP.

Teraquant provides an add-on to Oracle’s Communications Operations Monitor (OCOM) that highlights the parts of the SIP INVITE carrying the LNP information allowing you to search on specific calls and ensure the ported number is delivered to the correct switch in the network and routed to the new number’s destination.

What is Local Number Portability and Why is it Important?

The right of telephone subscribers to keep their phone number even if they move across the country was introduced with the Telecommunications Act of 1996. Typically, when a call is made through a telephony switch, the switch determines whether they can route that call based on the called digits directly from the routing table in that local switch, e.g., using the first 6 digits (NPA-NXX) of the 10 digits of the ANSI standard dial plan. In other words, if the destination number is in the routing table of that switch’s database, the call can be routed directly to the destination. This is rarely the case.

Calls not immediately routable activate a trigger and the switch routes the call to their Access Tandem partner who will “dip” or access a database hosted on the Service Control Point (SCP). This distributed database is supported nationally throughout North America by tier one carriers or the access tandem switch network provider.

This database query is still made in the SS7 network but can be initiated using the SIP protocol through a gateway. Once the response comes back from the query, we need to see how this is shown in the SIP INVITE.

The LNP Process

The NPAC (Number Portability Administrative Center) has the authoritative database for all the ported telephone numbers. The NPAC SMS (Service Management System) provides updates to the LNP database of LNP service provider (also referred to as Local Service Management System). The telephone switch of the OSP (Originating Service Provider) is the network element that subscribes to the LNP service provider and normally does the query to the LNP database to find the routing information of the ported number.

The query from the telephone service provider to the LNP database could be via multiple different protocols depending on the protocols supported and the service agreement between the OSP and the LNP database service provider. Normally ENUM, SS7, and SIP are the widely used protocols for performing the LNP dip, with SIP gaining more popularity as per the research we conducted.

Sample Invite Message Sent from the UE

A query is made by the originating subscriber’s switch for called number 17194881003 to the LNP database server to see if the number has been ported. During the LNP dip, the LNP database server checks its database and determines that the number has been ported. So it replies back with the LRN of the ported number. The originating subscriber’s switch, or its partner that made the query to the SMS, then routes the call further with the LRN included within the R-URI and npdi=yes, indicating that a LNP query was done, see below.

Sample Invite after LNP Query

The npdi parameter stands for Number Portability Dip Indicator and it could be explicitly set to ‘yes’ or just be present in the Invite R-URI as per RFC 4694 to indicate that LNP query has been made.

In case the LNP query has been done by the originating service provider or a partner’s switch and the number has not been ported, the downstream Invite message would contain the npdi parameter. However, LRN would not be present in the R-URI as shown in the example below.

Commonly Occurring Problems

Often the responsibility to query the LNP database falls between the cracks. The local originating carrier may fail to do it and the immediate northbound carrier [N-1] may also drop the task.

Although very much less common, it can happen at the SCP and its backup is offline, maybe for scheduled maintenance. A message would come back stating “Subsystem Unavailable”. More frequent is a slow response from the N-1 carrier, triggering a timeout on the local originating switch. Hopefully, this would be caught by alerts generated to the support desk /NOC.

Sometimes an incorrect LRN value can be returned by the TCAP query. Basically, the LNP database has been given incorrect information. You know the old adage “garbage in, garbage out”. It starts with manual human data entry following a rather complex administrative process and errors can occur along the way.

Quick and Easy Troubleshooting

What information do we need from our network monitoring tools in order to ensure the process is working correctly and to be able to troubleshoot when it is not?

The main new parameter that we need to monitor is the LRN. This is the routing number of the new switch on which the new destination this ported number now resides. All we need to do is to route the invite to this LRN and it will know where to route to the new destination of the called party. So we need to be able to search on the calling number, the called number which is obviously in standard functionality of OCOM. But in addition, we need to be able to search on the LRN or the ‘RN’ in the SIP INVITE.

To learn more about local number portability and how to troubleshoot it, please contact us.