Print this page Print NPIF » NANC Change Orders » NANC 401

NANC 401

Separate LSMS Association for OptionalData Fields

Origination Date :01/13/2005

Originator:VeriSign

Description:

This change order would modify the NPAC to support a separate LSMS association, using a different SPID, for the data in the NPB/SV OptionalData fields.  The NPAC would manage the distribution of LSMS broadcasts such that LSMSs that support this new optional data feature would have NPB/SV porting data broadcast down the appropriate LSMS association, and LSMSs that use the current mechanism would continue to have all NPB/SV porting data broadcast down their single LSMS association.

Two options were discussed, regarding the filtering of the downloads to the 2nd  LSMS association:

  1. The NPAC would broadcast all data to association-2, and the LSMS would decide whether or not to store the data. This functionality would be supported under NANC 400.
  2. NPAC audits may need a change.

  i.  If LSMS stores all data, no NPAC change required.

  ii.  If LSMS only stores OptionalData, then NPAC would need to ignore their discrepancy for conventional port data.

  1. NPAC functionality for modify-active, mass update, and disconnect, no NPAC change required.
  2. The NPAC would use a new NPB object and new SV object to transmit data between the NPAC and association2.  This will be used for porting data for the NPB/SV OptionalData fields. Two new objects required to support this functionality.
  3. NPAC audits will need a change.

  i.  NPAC must audit based on type of association.

  ii.  NPAC must handle discrepant data for data that the LSMS is not supporting, and therefore, not consider it discrepant.

  1. NPAC functionality for modify-active, mass update, and disconnect, will need a change.  Must send the correct object to the applicable LSMS.

 Major points/processing flow/high-level requirements:

  1. The NPAC broadcasts NPB/SV porting data to all LSMSs, which in turn provision elements in their respective Service Provider’s networks.  In order to accommodate NPB/SV OptionalData fields introduced by NANC 400, Service Providers may institute separate provisioning flows.  Individual Service Providers may decide to implement these separate flows through the use of separate LSMS associations with the NPAC. Conventional NPB/SV porting data would continue to be broadcast on the current LSMS association.
  2. In order to meet some Service Provider’s provision needs, an LSMS will be allowed to establish a dedicated LSMS association for data associated with NPB/SV OptionalData fields.  This will be accomplished by using a different SPID than the one used for conventional porting data (1a above).  There are two options for receiving the OptionalData fields.

    i.  The data for this second association will use existing objects (SV object which will include subscription OptionalData fields, NPB object which will include pooled block OptionalData fields).  Hereafter this is referred to as Option-1.

    ii.  The data for this second association will use new objects (SVOptionalData object for subscription OptionalData fields, NPBOptionalData object for pooled block OptionalData fields).  Hereafter this is referred to as Option-2.

  1. Option-2 only.  A new SP specific tunable, Channel for LSMS Unbundled Enhancement (CLUE), will indicate whether or not an LSMS ONLY supports receiving the new OptionalData objects.  One new object will contain SV data, the second one will contain NPB data.
  2. Option-2 only.  CLUE (when value set to TRUE) will be used to allow a Service Provider, by using a different SPID value, to establish an LSMS association specifically for data associated with the new OptionalData objects.
  3. Both Option-1 and Option-2.  LSMS function masks do not require any changes.
  4. Option-2 only.  NPAC processing in a CLUE environment.  Applicable for Service Providers with CLUE set to TRUE. When a Service Provider does not support CLUE with the NPAC:

   i.  The new OptionalData objects WILL NOT be generated by the NPAC for downloading to the LSMS.

   ii.  All LSMS traffic (network data, NPB data, SV data, notifications, NPB OptionalData, SV OptionalData) flows across the one LSMS association.  Success/failure of the download is BAU.

   iii.  Priority and Type of message is BAU.

   iv.  LSMS Recovery is BAU.

   v.  An NPB/SV Query is BAU.

   vi.  If the Service Provider has enabled OptionalData fields in their NPAC Profile, these attributes will be broadcast across the one LSMS association.

  1. When a Service Provider does support CLUE with the NPAC:

   i.  The new OptionalData objects WILL be generated by the NPAC for downloading to the LSMS.  The actual data will be based on which OptionalData fields are enabled in their NPAC Profile.

   ii.  The NPAC sends LSMS data based on current functionality mask.

   iii.  LSMS associates to the NPAC with the existing functionality mask (“Association2”, which is the only association from the second SPID).  Only applicable traffic (network data, notifications, the new NPBOptionalData object, the new SVOptionalData object) flows across “Association2”.  Success/failure of the download is BAU.

   iv.  LSMS Recovery is based on the functionality supported by that binding association, as described in 5-b-iii, above.

   v.  Queries will change based on the functionality supported by that binding association, as described in 5-b-iii, above.

  1. NPAC processing will change to accommodate audits for association2.  For association1, no change to audits is required. Option-1 only.  The NPAC will use the Service Provider profile settings to determine if the new OptionalData fields are involved, but using the existing SV and NPB objects.  Each LSMS will need to respond back to the NPAC query request, based on current data.  The NPAC will process the responses, compare to the NPAC data, and send any updates if needed.  In the case of a CLUE-less LSMS, conventional porting data is not expected, so no discrepancies will be reported back to the requesting SOA.
  2. Option-2 only.  The NPAC will use a combination of the Service Provider profile settings, plus the CLUE indicator to determine if the new OptionalData objects are involved.  Each LSMS will need to respond back to the NPAC query request, based on current data.  The NPAC will process the responses, compare to the NPAC data, and send any updates if needed.  In the case of a CLUE LSMS, conventional porting data is not expected, so no discrepancies will be reported back to the requesting SOA.
  3. If an LSMS indicates that it supports CLUE, but they don’t change any of their SP Profile flags and therefore don’t support any OptionalData fields, it becomes a dark association for NPB/SV data, because no downloads are generated nor sent to that new association.

 Open Issues:

  1. Audit complexity is increased because the NPAC must initiate one type of query to the conventional LSMS (association1), and a different type of query to the OptionalData LSMS (association2).  For option 2, added complexity because two objects now represent the same SV/NPB.
  2. Should we create a new version of the NPB and SV BDD files to accommodate the difference between conventional porting data and OptionalData porting data?
  3. Adding new Managed Objects requires much greater development and testing time on both the NPAC and the LSMS.

Requirements:

Option 1 and 2:

None.

Option 1 Only:

Req 1  Audit OptionalData Only Tunable

NPAC SMS shall provide a Service Provider Audit OptionalData Only tunable parameter which defines whether an LSMS supports only OptionalData information.

Req 2  Audit OptionalData Only Tunable – Default

NPAC SMS shall default the Service Provider Audit OptionalData Only tunable parameter to FALSE.

Req 3  Audit OptionalData Only Tunable – Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider Audit OptionalData Only tunable parameter.

Req 4  Audit Processing in an OptionalData Only Configuration

NPAC SMS shall, when processing the audit query results from an OptionalData Local SMS (Service Provider Audit OptionalData Only tunable parameter set to TRUE), audit the following attributes:

  1. SV-ID
  2. TN
  3. SPID
  4. Activation TS
  5. SV Type
  6. OptionalData Alternative SPID (only Service Provider Local SMSs that support this attribute will be audited on this attribute)
  7. Voice URI (only Service Provider Local SMSs that support this attribute will be audited on this attribute)
  8. MMS URI (only Service Provider Local SMSs that support this attribute will be audited on this attribute)
  9. PoC URI (only Service Provider Local SMSs that support this attribute will be audited on this attribute)
  10. Presence URI (only Service Provider Local SMSs that support this attribute will be audited on this attribute)

Req 5  Audit Processing in a Conventional Porting Configuration

NPAC SMS shall, when processing the audit query results from a conventional Local SMS (Service Provider Audit OptionalData Only tunable parameter set to FALSE), audit the attributes, as defined in requirement R8-3 (Service Providers Specify Audit Scope).

Option 2 Only:

Req 1  Channel for LSMS Unbundled Enhancement Tunable

NPAC SMS shall provide a Service Provider Channel for LSMS Unbundled Enhancement tunable parameter which defines whether an LSMS supports OptionalData objects.

Req 2  Channel for LSMS Unbundled Enhancement Tunable – Default

NPAC SMS shall default the Service Provider Channel for LSMS Unbundled Enhancement tunable parameter to FALSE.

Req 3  Channel for LSMS Unbundled Enhancement Tunable – Modification

NPAC SMS shall allow NPAC Personnel, via the NPAC Administrative Interface, to modify the Service Provider Channel for LSMS Unbundled Enhancement tunable parameter.

Req 4  Sending of OptionalData Objects when CLUE Channel is Active

NPAC SMS shall send OptionalData objects for a particular Service Provider across a CLUE channel when it is active.

Req 5  Subscription Version OptionalData Objects Recovery

NPAC SMS shall provide a mechanism that allows an LSMS to recover subscription version OptionalData objects downloads that were missed during a broadcast to the LSMS.

Req 6  Subscription Version OptionalData Objects Recovery Only in Recovery Mode

NPAC SMS shall allow an LSMS to recover OptionalData objects ONLY in recovery mode.

Req 7  Subscription Version OptionalData Objects Recovery – Order of Recovery

NPAC SMS shall recover all OptionalData objects download broadcasts in time sequence order when OptionalData objects are requested by the LSMS.

Req 8  Subscription Version OptionalData Objects Recovery – Time Range Limit

NPAC SMS shall use the Maximum Download Duration Tunable to limit the time range requested in an OptionalData objects recovery request.

Req 9  Subscription Version OptionalData Objects Recovery – SWIM

NPAC SMS shall allow an LSMS to recover OptionalData objects using a SWIM recovery request.

Req 10  Subscription Version OptionalData Objects Recovery – LSMS Data

NPAC SMS shall allow the LSMS to only recover OptionalData object downloads intended for the LSMS.

Req 11  Subscription Version Information Bulk Data Download – OptionalData Objects

NPAC SMS shall use the Service Provider’s profile (Channel for LSMS Unbundled Enhancement Flag set to TRUE), and only include OptionalData subscription version objects in the subscription version bulk data download file.

Req 12  Subscription Version Information Bulk Data Download – Subscription Version Objects

NPAC SMS shall use the Service Provider’s profile (Channel for LSMS Unbundled Enhancement Flag set to FALSE), and only include regular subscription version objects in the subscription version bulk data download file.

Req 13  Query for Subscription Versions using the OptionalData Object

NPAC SMS shall use the Service Provider’s profile (Channel for LSMS Unbundled Enhancement Flag set to TRUE), and only send a subscription version query for the OptionalData subscription version object in an audit.

Req 14  Query for Subscription Versions using the Subscription Version Object

NPAC SMS shall use the Service Provider’s profile (Channel for LSMS Unbundled Enhancement Flag set to FALSE), and only send a subscription version query for the regular subscription version object in an audit.

IIS:

Option 1 and 2:

None.

Option 1 Only:

None.

Option 2 Only:

Add to the end of Chapter 5:

5.x – CLUE Channel for OptionalData Objects

A Service Provider may connect to the NPAC SMS using a “second” LSMS system (different SPID value), in order to receive OptionalData objects.  The NPAC SMS will send OptionalData objects instead of standard SV/NPB objects when the SP specific tunable, Channel for LSMS Unbundled Enhancement (CLUE), is set to TRUE.  This allows a Service Provider to have the NPAC SMS separate out downloads for convention porting data versus IP data, using the new SV and NPB objects.

 For audit queries, the NPAC will use a combination of the Service Provider profile settings, plus the CLUE indicator to determine if the new OptionalData objects are involved.  If they are involved, the NPAC SMS will queries for the OptionalData objects rather than the conventional SV/NPB objects.  Each LSMS will need to respond back to the NPAC query request, based on current data.  The NPAC will process the responses, compare to the NPAC data, and send any updates if needed.  In the case of a CLUE LSMS, conventional porting data is not expected, so no discrepancies will be reported back to the requesting SOA.

 New message flows for the following:

  1. SV Activate – Download to the LSMS using the OptionalData Object
  2. SV Modify-Active – Download to the LSMS using the OptionalData Object
  3. SV Disconnect – Download to the LSMS using the OptionalData Object
  4. SV Query – Request to the LSMS for the OptionalData Object
  5. NPB Activate – Download to the LSMS using the OptionalData Object
  6. NPB Modify-Active – Download to the LSMS using the OptionalData Object
  7. NPB Disconnect – Download to the LSMS using the OptionalData Object
  8. NPB Query – Request to the LSMS for the OptionalData Object

The basic steps:

  1. NPAC SMS sends message to LSMS, à.
  2. LSMS responds back to NPAC SMS, ß.

Final Resolution:

Moved to closed/no-action.

Related Release:

N/A.

Status: Closed