Local Number Portability

From TBwiki
(Difference between revisions)
Jump to: navigation, search
(→Outgoing call mapping)
m (fix column width)
 
(5 intermediate revisions by 3 users not shown)
Line 10: Line 10:
 
When the first subscriber within an NPA-NXX group changes service providers, the entire NPA-NXX is considered “ported” (all 10k numbers) which means that this particular NPA-NXX combination has become a portable number and no longer represents a specific exchange.  Every call to that NPA-NXX will trigger a query to a database to determine the LRN of the number of the switch responsible for the NPA-NXX-XXXX being called.
 
When the first subscriber within an NPA-NXX group changes service providers, the entire NPA-NXX is considered “ported” (all 10k numbers) which means that this particular NPA-NXX combination has become a portable number and no longer represents a specific exchange.  Every call to that NPA-NXX will trigger a query to a database to determine the LRN of the number of the switch responsible for the NPA-NXX-XXXX being called.
  
−
=== Implementation of LNP relay ===
+
=== LNP and TelcoBridges ===
  
−
Most carriers and operators exposing ISUP interfaces to CLECs detects if an incoming call is in the 'translates' mode or not by looking at the content of the ISUP message.  If the ISUP call does not contain any LNR number, then the carrier/operator switch does a query to the SS7 database to figure out the LRN and adjust the call information accordingly.  Although TelcoBridges's Toolpack framework does not make the actual query to the database (also known as the 'DP' [pronounce 'dip']), it is able to terminate or relay a call from SIP to SS7 providing the LRN information is contained in the SIP body.  What is relayed and how it is relayed depends on the profile configuration options.
+
TelcoBridges products support the LNP use cases described by the following table.
  
−
==== Call flow and configuration options ====
+
{| cellpadding="5" border="1" class="wikitable"
−
 
+
! width="150" | Scenario
−
Toolpack processes sequentially the incoming call by parsing the content of the signalling protocol and mapping it to "protocol-agnostic" internal variables that are accessible by the routing scripts.  Through all the [[Routing_script_tutorial:Mini_Development_Guide#Script_parameters_protocol_mapping|routing script variables]] accessible to scripts are some related to LNP such as 'ported_number'.  The mapping of the information found in the incoming call depends on the option selected in the "incoming" parameters of the LNP section in the profile associated with the incoming NAP.  Then its mapping to the outgoing call depends on configuration parameters of the profile for the outgoing NAP.
+
! Description
−
 
+
! TelcoBridges support
−
===== Incoming call mapping =====
+
−
The image below shows the different configuration options available and affect on how the system will map the '''incoming''' call information into the script variable available during routing.
+
−
<br />
+
−
[[File:LNP_profile_incoming.PNG|500x|650px]]
+
−
<br /><br />
+
−
The following table contains the pseudo-code of the mapping according to the configuration AND the content of the incoming call signaling:
+
−
<br />
+
−
'''CPN''' = called party number or the TO sip header<br />
+
−
'''called''' = called number variable accessible in routing script<br />
+
−
'''GAP''' = generic address number SS7 information element type 0xc0<br />
+
−
'''ported_number''' = extra number type accessible in the routing script<br />
+
−
'''RN''' = rn field in SIP request URI<br />
+
−
'''bitM''' = SS7 Forward call indicator information element: ported number translation indicator (bit M)<br />
+
−
'''X''' = drop number<br />
+
−
<br />
+
−
{| class="wikitable"
+
 
|-
 
|-
−
! Parameter !! SS7 !! SIP
+
| All Call Query
 +
| Before every call, obtain the routing number corresponding to the called number from a centralized database.
 +
| The routing scripts can be configured to query the database through RADIUS, or using a SS7/SIP call.
 
|-
 
|-
−
| Ignore || CPN => called <br />GAP => X  || CPN => called <br />RN => X
+
| Query on Release
 +
| Route calls normally. If a remote operator returns a redirection response without any destination specified, obtain the routing number corresponding to the called number from a centralized database.
 +
| The routing scripts can be configured to query the database through RADIUS, or using a SS7/SIP call.
 
|-
 
|-
−
| Terminate || GAP => called<br />CPN => X  <br />ported_number not available  || CPN => called<br />  RN => X<br />    ported_number not available
+
| Call Dropback
 +
| Route calls normally. A remote operator may provide a routing number to use to route the call somewhere else.
 +
| TelcoBridges products can process, relay or drop redirections.
 
|-
 
|-
−
| Forward || if bitM=1 then<br />"" => ported_number<br />if GAP then<br />CPN => called<br />GAP => PNB<br />else<br />CPN => called || if npdi=yes then<br />"" => ported_number<br />if RN then<br />CPN => ported_number<br />RN=> called<br />else<br />CPN => called
+
| Onward Routing
 +
| Route calls normally. A remote operator may choose to re-route the call by itself or provide a routing number.
 +
| TelcoBridges products can process, relay or drop redirections. They also handle call transfers.
 
|}
 
|}
  
−
===== Outgoing call mapping =====
+
==== Relaying ====
 +
Most carriers and operators exposing ISUP interfaces to CLECs detects if an incoming call is in the 'translated' mode or not by looking at the content of the ISUP message.  If the ISUP call does not contain any LRN number, then the carrier/operator switch does a query to the SS7 database to figure out the LRN and adjust the call information accordingly. The TelcoBridges' [[Toolpack]] framework is able to terminate or relay a call from SIP to SS7 providing the LRN information is contained in the SIP body.  What is relayed and how it is relayed depends on the profile configuration options.
  
−
The image below shows the different configuration options available and affect on how the system will map the '''outgoing''' call information into the script variable available during routing.  
+
==== Processing ====
−
<br />
+
TelcoBridges' [[Toolpack]] framework allows to route calls based on both the called number or the LRN based on the profile configuration options.
−
<br />
+
 
−
[[File:LNP_profile_outgoing.PNG|500x|750px]]
+
[[Toolpack]] can query an external LNP database using [[RADIUS]] authorizations or SS7 or SIP [[Redirect|redirections]]. This operation is also commonly referred as LNP/LRN "dipping".
−
<br />
+
 
−
<br />
+
=== Configuration ===
−
The following table contains the pseudo-code of the mapping to the outgoing call according to the configuration AND what was present in the routing script variables:
+
 
−
<br />
+
Toolpack processes sequentially the incoming call by parsing the content of the signalling protocol and mapping it to "protocol-agnostic" internal variables that are accessible by the routing scripts.  Through all the [[Routing_script_tutorial:Mini_Development_Guide#Script_parameters_protocol_mapping|routing script variables]] accessible to scripts are some related to LNP such as 'ported_number'.  The mapping of the information found in the incoming call depends on the option selected in the "incoming" parameters of the LNP section in the profile associated with the incoming NAP.  Then its mapping to the outgoing call depends on configuration parameters of the profile for the outgoing NAP.
−
{| class="wikitable"
+
 
−
|-
+
[[Toolpack:Modify_NAP_profile_A|Configuring LNP in v2.6]]
−
! Parameter !! SS7 !! SIP
+
−
|-
+
−
| No insertion || bitM = 0<br />if ported_number then<br />ported_number => CPN<br />called => X<br />else<br />called => CPN || RN and ndpi not present<br />if ported_number then<br />ported_number => CPN<br />called => X<br />else<br />called => CPN
+
−
|-
+
−
| Always || bitM = 1<br />ported_number => GAP<br />called => CPN || ndpi=yes<br />if ported_number then<br />called => RN<br />ported_number => CPN<br />else<br />called => CPN<br />RN not present
+
−
|-
+
−
| Relay || called=>CPN<br />if ported_number then<br />bitM = 1<br />if ported_number is empty then<br />ported_number => X<br />else<br />ported_number => GAP <br />else<br />bitM = 0 || if ported_number then<br />ndpi=yes<br />if ported_number is empty then<br />called => CPN<br />RN not present<br />else<br />called => RN<br />ported_number => CPN<br />else<br />called => CPN
+
−
|}
+

Latest revision as of 13:02, 28 April 2015

Contents

Local Number Portability (LNP)

History and overview

Since the beginning of modern telephony, the phone number has been composed of series of digits representing the address of the final destination (i.e. the callee). This is actually what the end-user believed actually. But in reality, the signification of these digits has changed over the decades sometimes partially representing the actual route from one switch to the other or the rural region where the callee actually lives.

Traditionally, every switches was assigned an NPA-NXX (where NPA means "Numbering Plan Area"), meaning that a phone number with the format NPA-NXX-XXXX was actually refering to a specific geographical switch. As the number of end-user was growing in geographical regions, the set of available numbers in a specific NPA-NXX-XXXX was reducing forcing the telecommunication authorities to allocate more regional codes. At some point, the switches themselves were provisioned at their maximum capacity which forces the operators to include other switches not necessarily to the same geographical locations thus making the NPA-NXX less and less relevant to geography. However, the real changes came when the normative authorities decided that a end-user has the right to keep his assigned phone number regardless of which carrier he's chose as long as it kept to the same local geographical region. This change had to be supported by the ISUP switching/terminating equipment to decouple the actual phone number from the carrier/switching equipment and link it to the end-user. However, for routing purposes, these equipments still needed a way to deduce the routing to reach that end-customer number. This mechanism is referred to as "Local Number Portability" (LNP).

With LNP now active, a new number called the LRN (Location routing number) is introduced in the routing mechanism. It is formatted as NPA-NXX-XXXX and points logically to a particular switching equipment: it is the switch permanent address. The DNIS (end-user called number) is now a “virtual number” that only the last end-switch knows how to route to the subscriber. It is the role of the originating switch and intermediate switches to translate the DNIS into an LRN (consulting a regional databases using SS7 or SIP) and route the call to the final switch responsible for that subscriber. Then, and only then, the last switch uses the original DNIS to route it to the end-user.

When the first subscriber within an NPA-NXX group changes service providers, the entire NPA-NXX is considered “ported” (all 10k numbers) which means that this particular NPA-NXX combination has become a portable number and no longer represents a specific exchange. Every call to that NPA-NXX will trigger a query to a database to determine the LRN of the number of the switch responsible for the NPA-NXX-XXXX being called.

LNP and TelcoBridges

TelcoBridges products support the LNP use cases described by the following table.

Scenario Description TelcoBridges support
All Call Query Before every call, obtain the routing number corresponding to the called number from a centralized database. The routing scripts can be configured to query the database through RADIUS, or using a SS7/SIP call.
Query on Release Route calls normally. If a remote operator returns a redirection response without any destination specified, obtain the routing number corresponding to the called number from a centralized database. The routing scripts can be configured to query the database through RADIUS, or using a SS7/SIP call.
Call Dropback Route calls normally. A remote operator may provide a routing number to use to route the call somewhere else. TelcoBridges products can process, relay or drop redirections.
Onward Routing Route calls normally. A remote operator may choose to re-route the call by itself or provide a routing number. TelcoBridges products can process, relay or drop redirections. They also handle call transfers.

Relaying

Most carriers and operators exposing ISUP interfaces to CLECs detects if an incoming call is in the 'translated' mode or not by looking at the content of the ISUP message. If the ISUP call does not contain any LRN number, then the carrier/operator switch does a query to the SS7 database to figure out the LRN and adjust the call information accordingly. The TelcoBridges' Toolpack framework is able to terminate or relay a call from SIP to SS7 providing the LRN information is contained in the SIP body. What is relayed and how it is relayed depends on the profile configuration options.

Processing

TelcoBridges' Toolpack framework allows to route calls based on both the called number or the LRN based on the profile configuration options.

Toolpack can query an external LNP database using RADIUS authorizations or SS7 or SIP redirections. This operation is also commonly referred as LNP/LRN "dipping".

Configuration

Toolpack processes sequentially the incoming call by parsing the content of the signalling protocol and mapping it to "protocol-agnostic" internal variables that are accessible by the routing scripts. Through all the routing script variables accessible to scripts are some related to LNP such as 'ported_number'. The mapping of the information found in the incoming call depends on the option selected in the "incoming" parameters of the LNP section in the profile associated with the incoming NAP. Then its mapping to the outgoing call depends on configuration parameters of the profile for the outgoing NAP.

Configuring LNP in v2.6

Retrieved from "https://docs.telcobridges.com/mediawiki/index.php?title=Local_Number_Portability&oldid=18264"
Personal tools