My Oracle Support Banner

The Number Portability (NP) Service Does Not Find Some Numbers When DN Ranges of the Same Entry Type Overlap (Doc ID 1638227.1)

Last updated on OCTOBER 18, 2016

Applies to:

Oracle Communications Network Charging and Control - Version 4.4.0 and later
Information in this document applies to any platform.

Symptoms

The Number Portability (NP) Service is not sending the correct ported number digits to Network switches.  Other symptoms include the Service Management System's (SMS) User Interface (UI), Services -> NP Service -> Subscriber and Network -> Common Find Panel screen, and/or the Provisioning Interface (PI) NPDS1=QRY command, failing to find the destination number (DN) range for a ported number, even though a database query of the NP_DN_RANGE table shows that the number is provisioned inside a DN range.

Closer analysis of the database query shows the queried number belongs to multiple overlapping DN ranges of the same entry type (Operator or Subscriber).  Provisioning of overlapping DN ranges of the same entry type should not be possible and is against the NP Service design rules.  It results in a control plan's NP Destination Selection (NDST) node failing to correctly match a ported number, and hence not send the correct information to the Network's switches. 

NCC Feature Nodes Reference Guide: The NP Destination Selection (NDST) node determines the owner of the called number (that is, is the number ported or non ported?).  Based on the porting status and whether the number is owned by the Operator (internal) or owned by another Operator (external), it can be configured how the call number is modified.

The following example demonstrates the issue:

Three overlapping DN ranges (A-C) have been defined as follows:

When a small set of numbers (64210340150, 64210340152, 64210340175) is directly queried in the database the following results are given:

-- 1. 64210340150 sits inside 3 DN ranges. Okay as entry type is S.
SQL> set pages 200 lines 132
SQL> col dn_start format a18
SQL> col dn_end format a18
SQL> SELECT
 dn.dn_start, dn.dn_end, dn.activation_date, rn.routing_number, dn.entry_type
FROM
 np_dn_range dn,
 np_routing_number rn
WHERE
 dn.rn_id = rn.id
AND
 dn.dn_start <= '&&dn'
AND
 dn.dn_end >= '&dn';
Enter value for dn: 64210340150
old   9:  dn.dn_start <= '&&dn'
new   9:  dn.dn_start <= '64210340150'
old  11:  dn.dn_end >= '&dn'
new  11:  dn.dn_end >= '64210340150'

DN_START           DN_END             ACTIVATION_DAT ROUTING_NUMBER           ENT
------------------ ------------------ -------------- ------------------------ ---
64210340150        64210340150        20130201090807 1                        S
64210340145        64210340155        20140301001500 321                      O
64210340100        64210340199        20140301001500 123                      O
-- 2. 64210340152 returns two rows in an operator range with different routing numbers and same activation date (the first row would be returned to the application, but which is correct?)
SQL> set verify off
SQL> undefine dn
SQL> /
Enter value for dn: 64210340152

DN_START           DN_END             ACTIVATION_DAT ROUTING_NUMBER           ENT
------------------ ------------------ -------------- ------------------------ ---
64210340145        64210340155        20140301001500 321                      O
64210340100        64210340199        20140301001500 123                      O
-- 3. 64210340175 returns 1 row in an operator range
SQL> undefine dn
SQL> /
Enter value for dn: 64210340175
DN_START           DN_END             ACTIVATION_DAT ROUTING_NUMBER           ENT
------------------ ------------------ -------------- ------------------------ ---
64210340100        64210340199        20140301001500 123                      O

When using the PI (or UI) to query the same set of numbers then the following results are given:

smf_oper@sms01:/IN/service_packages/PI/bin$ ./PIbatch npds1-qry.pi 127.0.0.1 ; cat npds1-qry.pi.result
->admin,*****;
<-ACK;
->NPDS1=QRY:DN=64210340150;
<-NPDS1=QRY:ACK:DN_START=64210340150,DN_END=64210340150,ACTIVATION_DATE=20130201090807,ROUTING_NUMBER=1,ADDITIONAL_ROUTING_NUMBER= ,DONOR_ID= ,PORT_ID= ,ENTRY_TYPE=S,NUMBER_TYPE=,URI=;
->NPDS1=QRY:DN=64210340152,ENTRY_TYPE=O;
<-NPDS1=QRY:ACK:DN_START=64210340145,DN_END=64210340155,ACTIVATION_DATE=20140301001500,ROUTING_NUMBER=321,ADDITIONAL_ROUTING_NUMBER= ,DONOR_ID= ,PORT_ID= ,ENTRY_TYPE=O,NUMBER_TYPE=,URI=;
->NPDS1=QRY:DN=64210340175,ENTRY_TYPE=O;
<-NPDS1=QRY:NACK:1004-The DN 64210340175 was not in the defined ranges;

Note how the last number was not found (NACK:1004-The DN 64210340175 was not in the defined ranges) even though it belongs in DN range C.  It is always the numbers in the last section of overlapping DN ranges (of same entry type) that fail to be matched correctly.

DN Ranges A and B (or C) are allowed as their entry types are different, with the subscriber (S) taking precedence over the operator (O) entry type when queried by the NP Service.  Ranges B and C overlap each other and have the same operator entry type.  This is not allowed and the NP Service application does not expect to find this kind of provisioned data in the NP_DN_RANGE table. 

Steps to Reproduce Issue by Provisioning Overlapping DN Ranges of Same Entry Type

Two different NP provisioning methods have been detected as briefly described below:

Method A: NP UI Screens (Services -> NP Service -> Subscriber and Network -> DN Range)

  1. Define NP DN Range A with Entry Type  Operator: A=64210340100-64210340199
  2. Define NP DN Range B, that overlaps DN Range A but with values inside Range A, and with Entry Type Operator: B=64210340145-64210340155
  3. [Save] change - Result message: P/error/Inserting record: Save operation failed - Attempt to insert an overlapping range in the DN Range table.
  4. For DN Range B uncheck the Entry Type, so DN Range becomes a Subscriber range.
  5. [Save] entry - Result: Save completed successfully - new record created.
  6. Without exiting screen for DN Range B, check the Entry Type so it is an Operator range.
  7. [Save] change - Result: P/error/Inserting record: Save operation failed - Attempt to insert an overlapping range in the DN Range table.
  8. Use the [Find] button and [Select] Range B again for the NP/Subscriber and Network - Update Mode screen (note: top 6 UI data entry fields greyed out and cannot be changed).
  9. Check the Entry Type so it is an Operator range.
  10. [Save] entry - Result message: Save completed successfully - existing record updated.

Method B: PI NPDS1=CHG command

  1. Provision overlapping DN range of different ENTRY_TYPE (O and S).  Example PI MML commands:
    NPDS1=ADD:DN_START=64210340100,DN_END=64210340199,ACTIVATION_DATE=20140301001500,ROUTING_NUMBER=123,NUMBER_TYPE=F,ENTRY_TYPE=O;
    NPDS1=ADD:DN_START=64210340145,DN_END=64210340155,ACTIVATION_DATE=20140301001500,ROUTING_NUMBER=123,NUMBER_TYPE=F,ENTRY_TYPE=S;
     
  2. Use the change command to switch the Subscriber entry type to Operator (ACTIVATION_DATE must match original entry).  For example:
    NPDS1=CHG:64210340145,DN_END=64210340155,ACTIVATION_DATE=20140301001500,ROUTING_NUMBER=123,ENTRY_TYPE=O;

These examples use Operator entries to show overlapping DN ranges as it is the more likely scenario.  It is possible to produce the same behaviour for Subscriber DN ranges though.

Cause

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


In this Document
Symptoms
Cause
Solution
References


My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.