NANC CHANGE ORDER SUMMARY
FOR
NPAC SMS FUNCTIONALITY

Rev: 82
to be used for July 2001 (Ottawa) meeting

06/28/01

Table of Contents

Open Change Orders	3
Accepted Change Orders	8
Next Documentation Release Change Orders	26
Release 4.0 Change Orders	29
LTI Change Orders	56
Cancel – Pending Change Orders	57
Current Release Change Orders	58
MR Change Orders	59
Summary of Change Orders	60

Open Change Orders
Open Change Orders	
Chg Order #	Orig. / Date	Description	Priority	Category	Proposed Resolution	Level of Effort	
						NPAC	SOA LSMS	
NANC 147	AT&T
8/27/97	Version ID rollover strategy
Currently there is no strategy defined for rollover if the maximum value for any of the id fields (sv id, lrn id, or npa-nxx id) is reached.  One should be defined so that the vendor implementations are in sync.  Currently the max value used by Lockheed is a 4 byte-signed integer and for Perot it is a 4 byte-unsigned integer. 

Sep 99 LNPA-WG (Chicago), since the version ID for all data is driven by the NPAC SMS, the rollover strategy should be developed by Lockheed.  SPs/vendors can provide input, but from a high level, the requirement is to continue incrementing the version ID until the maximum ([2**31] –1) is achieved, then start over at 1, and use all available numbers at that point in time when a new version ID needs to be assigned (e.g., new SV-ID for a TN).	High	FRS	Func Backwards Compatible:  NO

A strategy on how we look for conflicts for new version id’s must be developed as well as a method to provide warnings when conflicts are found.

Oct 98 LNPAWG (Kansas City), it was requested that we begin discussing this in detail starting with the Jan 99 LNPAWG meeting.  Beth will be providing some information on current data for the ratio of SV-ID to active TNs (so that we can get a feel for how much larger the SV-ID number is compared to the active TNs).

Sep 99 LNPA-WG (Chicago), Lockheed will begin developing a strategy for this.

Jun 00 LNPA-WG (Chicago), AT&T analysis and calculation (using current and projected porting volumes) indicate that a need for a version ID rollover strategy is more than five years away.  Therefore, this change order is removed from R5, and will be discussed internally by Neustar technical staff.

Jul 2000 meeting: Neustar will track the problem.  It will be a Neustar internal design.  Change order to stay on open list for possible later Document Only changes.	High	High? / High?	
NANC 329	Neustar 06/13/01	Prioritization of SOA Notifications

Business Need: With the deployment of the NPAC Release 3.0 in the Northeast region a SOA – NPAC Interface problem has surfaced.  The improved performance of NPAC Release 3.0 and the faster hardware platform that this software is running on is resulting in transactions being processed for broadcast to the industry quicker than the SOA – NPAC interface can transmit them. During peak periods the interface cannot support the volumes of notifications that the NPAC SMS is generating, thus there is a long delay in notification delivery that results in operational issues.  At the current time it is the ILEC that is primarily affected by this problem because the ILEC receives the largest volume of SOA notifications but the problem has the potential of affecting any Service Provider. The NAPM, LLC has decided not to go forward with the deployment of NPAC Release 3.0 until this interface problem has been mitigated.  Neustar is proposing that SOA Notifications be prioritized and transmitted over the interface based on priority.  This would allow for more timely delivery of Service Providers high priority notifications.

(continued)
	High	FRS	Func Backwards Compatible:  YES

Jul 2001 meeting:  CMA to work with Neustar to develop first draft of the requirements which will be reviewed by the LNPA WG via Conference Call on Thursday, 06/28/2001.
	Med	N/A / N/A	
NANC 329 cont’d		Description of Change:  Currently SOA notifications are not prioritized so they are generated by the NPAC SMS and then transmitted on a ‘first in, first out’ basis. During a large porting volume peak this model can produce major delays in the transmission of notifications through the SOA – NPAC interface, resulting in operational issues.  This change order would prioritize SOA notifications and allow requests and notifications with the highest priority to be transmitted first.  The SOA notifications would have four categories: high, medium, low, and none.  The category of none would indicate that a Service Provider did not want to receive a particular notification. One of the other three categories would be assigned to each notification on a per region basis.  A Service Provider would have the option of overriding the default value.

								

								

								

Accepted Change Orders
Accepted Change Orders	
Chg Order #	Orig. / Date	Description	Priority	Category	Proposed Resolution	Level of Effort	
						NPAC	SOA LSMS	
ILL 5	AT&T 10/15/96	Round-Robin Broadcasts across LSMS associations 
The NPAC SMS would support additional LSMS associations and manage the distribution of transactions in a round robin algorithm across the associations.  For example, due to performance conditions a Service Provider may want to start another LSMS association for network/subscription downloads.  The NPAC SMS would accept the association, manage security, and distribute network/subscription PDUs across the 2 or more associations using the round robin algorithm (One unique PDU will be sent over one association only.)	Medium Low	NPAC SMS functionality / IIS	Func Backwards Compatible:  NO

This feature may already be implemented in the Lockheed Martin developed NPAC SMS.	Low	N/A / High	
NANC 151	Bellcore 9/4/97	TN and Number Pool Block addition to notifications
It has been requested that the TN for the subscription version be added to all notifications that currently contain SV-ID but not TN from the NPAC SMS.  It is possible for a SOA in a disconnect or modify-active situation, to not have the SV record in their database.  Therefore, when the attribute/status change notification comes from the NPAC SMS, there is no way to correlate its version id with the TN on the disconnect or modify request in SOA.

Jun 00 LNPA-WG meeting, additionally, the same type of change should be done for Number Pool Block (i.e., add the NPA-NXX-X to all notifications that currently contain Block-ID but not NPA-NXX-X).	Low	IIS	Func Backwards Compatible:  NO

This would be a deviation from the standard since the TN would not have been an attribute that has changed.

This is an "OLD" Release 2.0 change order, that has been moved into the "Accepted" category, awaiting prioritization	Low	Low / N/A	
NANC 169	Bellcore
5/23/97	Delta Download File Creation by Time Range for SVs
It has been requested that requirements be added to the FRS to allow for creation of a delta download file by date and time range, for SVs.

During Dec ’98 Natl N Pool meeting, discussed need to change functionality when requesting SV BDD with a time range.  Currently, the NPAC provides all “active” SVs based on Activation Broadcast Complete Timestamp.  This creates an issue for modifications that are within the specified time range window, but the Activation was prior to the specified time range.  There is also an issue for Activation Failures.

During Jan LNPAWG meeting, proposed changes to handle two issues, include:
1.  Incorporate the start and end time ranges into the file name.
2.  Need to capture all SV activity (activation, modification, disconnect) into the file, when doing time range.

(continued)	Medium	FRS	Pure Backwards Compatible:  YES

This item is on hold until further experience is gained with download. This change is expected to help a service provider catch-up faster after an extend outage when the database becomes large.

It was indicated that this functionality is already available in the Lockheed Martin NPAC SMS implementation.  Delete Pending

This change order was re-opened for discussion during the Dec ’98 LNPAWG meeting.

Dec LNPAWG (Atlanta), verify start and end timestamps embedded in filename.  Update documentation to state Activation Broadcast Complete Timestamp is used for comparison.

Update:  The start and end timestamps are NOT embedded in the filename.

The proposal from the Natl N Pool Sub-Committee is to use the Last Modified Timestamp attribute in the SV, to determine whether or not an SV fits in the specified time range.

(continued)	Med	N/A / N/A	
NANC 169 (con’t)	Continued	For #1 (new words in larger print italics), in FRS Appendix E, Download File Examples, 
Subscription versions in the download file are selected by an NPA-NXX begin and end range.  The file name for the Subscriptions download file, where a time range is NOT selected, will be in the format:
NPANXX-NPANXX.DD-MM-YYYYHH24MISS
The NPANXX-NPANXX values map to the selection criteria and the time stamp maps to the current time (Central Time - standard/daylight).
The Subscriptions file given in the example would be named:
	303123-303125.10-13-1996081122

In the case where a time range is selected, the file name for the Subscriptions download file with a time range, will be in the format:
NPANXX-NPANXX.DD-MM-YYYYHH24MISS. DD-MM-YYYYHH24MISS. DD-MM-YYYYHH24MISS.TIMEZONE
The NPANXX-NPANXX values map to the selection criteria, the first time stamp maps to the current time (when the file is generated), the second time stamp maps to the start time range, and the third time stamp maps to the end time range.  All three time stamps are represented in Central Time (standard/daylight), even though the Subscription Versions are stored in the NPAC in Greenwich Mean Time.  The TIMEZONE value will contain one of two values, either CST or CDT, depending on the current time zone in the Central Time Zone (when the file is generated).
The Subscriptions file with a time range given in the example would be named:
	303123-303125.10-13-1996081122.10-10-
           1996000000.10-12-1996115959.CST

(continued)		Jan LNPAWG (Atlanta), proposed changes were discussed.  CMA will include proposed changes in next version of the change management list.

Feb LNPAWG (San Ramon), updated multiple points for the change order (both file name and requirements).

NOTE:  The baseline for this change order is R2.  Therefore, when this change order gets merged into R3, need to change req 9 to reflect the EDR Flag, and filter out LNP Type of POOL  (ref. SV-521).

ACTION ITEM:  Jim will look at the broadcast timestamp for the SV Object, and how the NPAC Data Model attributes match up to the broadcast to the LSMSs.
CLOSED, Mar 99.  Activations are using the Activation Broadcast Timestamp in SV Data Model.

Mar LNPAWG (Denver), reviewed updated words.  Modifications will be reviewed in Apr.

Apr LNPAWG (DC), reviewed updates.  Move to Accepted List.

Refer to R4 Change Orders for current proposed resolution.	
NANC 169 (con’t)	Continued	Also for #1, no functional requirements or IIS flows are affected by this change.

For #2, new requirements are proposed (see below)

Req 1	Subscription Version Information Bulk Download File Creation – Subscription Versions
NPAC SMS shall allow NPAC personnel to request a bulk data download file for Subscription Version data via the NPAC Administrative Interface.  (existing NPAC SMS functionality)
Req 2	Subscription Version Information Bulk Download File Creation – Selection Criteria
NPAC SMS shall include the Requesting Service Provider, Active/Disconnect Pending/Partial Failure Subscription Versions Only or Latest View of Subscription Version Activity Choice, Time Range in Central Time (standard/daylight), and TN Range as Selection Criteria fields for the Subscription Version bulk data download file via the NPAC Administrative Interface.
Req 3	Subscription Version Information Bulk Download File Creation – Active/Disconnect Pending/Partial Failure Subscription Versions Only or Latest View of Subscription Version Activity Choice
NPAC SMS shall allow NPAC Personnel to select either Active/Disconnect Pending/Partial Failure Subscription Versions Only or Latest View of Subscription Version Activity, and shall use the selected choice, for Subscription Version data.
Req 4	Subscription Version Information Bulk Download File Creation – Data in Active/Disconnect Pending/Partial Failure Subscription Versions Only Choice
NPAC SMS shall use the Active/Disconnect Pending/Partial Failure Subscription Versions Only selection to only include Subscription Versions with a status of either Active, Disconnect Pending or Partial Failure in the Subscription Version Bulk Data Download file.

(continued)	
NANC 169 (con’t)	Req 5	Subscription Version Information Bulk Download File Creation – Data in Latest View of Subscription Version Activity Choice
NPAC SMS shall use the Latest View of Subscription Version Activity selection to include all Subscription Versions, regardless of status, in order to capture activation, modification, and deletion transactions for Subscription Version data, but only include the latest instance of the TN in the Subscription Version Bulk Data Download file, for a given NPA-NXX, when a Subscription Version has more than one activity (e.g., addition, then modification) within the specified time range.
Req 6	Subscription Version Information Bulk Download File Creation – Time Range Fields
NPAC SMS shall use the Start Time Range entry field as an inclusive start range in Central Time (standard/daylight), and the End Time Range entry field as an inclusive ending range in Central Time (standard/daylight), for Subscription Version data that were broadcast during the specified Time Range.
Req 13	Subscription Version Information Bulk Download File Creation – Time Range Fields and SV Data Model
NPAC SMS shall use the Start and End Time Range entry fields to include Subscription Version data, based on the Activation Broadcast Time Stamp, Modify Broadcast Time Stamp, and Disconnect Broadcast Time Stamp, in the NPAC’s Subscription Version Data Model, when generating the file for the Latest View of Subscription Version Activity selection.
Req 7	Subscription Version Information Bulk Download File Creation – TN Range Fields
NPAC SMS shall use the first TN Range entry field as an inclusive start range, and the second TN Range entry field as an inclusive ending range, for Subscription Version data.
(continued)	
NANC 169 (con’t)	Req 8	Subscription Version Information Bulk Download File Creation – Selection Criteria Combinations
NPAC SMS shall edit the selection criteria combination as shown in the table below:
                                                           | Time Range | TN Range
--------------------------------------------------------------------------
Active/Disconnect Pending/
Partial Failure SVs Only                    | Rejected     | Optional
Latest View of SV Activity               | Required     | Optional

Such that a combination of:
•	Active with a Time Range shall be rejected.
•	Latest View shall require a Time Range.
•	TN Range shall be optional for both Active and Latest View.
Req 9	Subscription Version Information Bulk Data Download – Subscription Version Results
NPAC SMS shall provide a bulk data download file, based on the selection criteria, that contains all Subscription Versions in the NPAC SMS.
Req 10	Subscription Version Information Bulk Data Download – Subscription Version Results Sort Order
NPAC SMS shall sort the Subscription Version Bulk Data Download file, in ascending order based on the value in the TN attribute.
 (continued)	
NANC 169 (con’t)	Req 11	Subscription Version Information Bulk Data Download – Filters for Subscription Versions
NPAC SMS shall apply NPA-NXX Filters to Subscription Versions in the creation of bulk data download files.
Req 12	Subscription Version Information Bulk Data Download – FTP Sub-Directory
NPAC SMS shall automatically put the bulk data download file into the FTP sub-directory of the Service Provider, based on SPID, that requested the creation of the bulk data download file.	
NANC 193	NANC T&O 1/23/1998	TN processing during NPAC SMS NPA Split Processing
There was group consensus that NPAC behavior would not change until the start of permissive dialing.  An example would be an audit that occurred during split processing one-minute before the start of permissive dialing.  The NPAC should act as if permissive dialing has not yet started for the audit initiated during split processing.  The Split processing should have no effect on operations of the system.

A clarification requirement should be added as follows:

NPAC SMS shall processes requests during split processing prior to the start of permissive dialing as if the split processing has not yet occurred.

Additional clarification requirement:

NPAC SMS shall in a download request made after permissive dialing start for subscription version data sent prior to permissive dialing start, return the new NPA-NXX for subscription versions involved in an NPA Split.

The above requirements do not reflect the current Lockheed NPAC SMS implementation.
	Medium High	FRS	Pure Backwards Compatible:  YES

Lockheed in release 1.2 currently holds requests until the NPA Split processing completes (regardless of the NPA or NPA-NXX).  Nortel/Perot rejects the requests during NPA split processing.  It was not clear if errors were for all requests or just requests related to the NPA or NPA-NXX being split.

Desired behavior would be to have no errors occur.  Requests put on hold or queued would only be those related to NPA-NXX’s involved in the NPA split being processed.

Lockheed in Release 1.3 will perform NPA- NXX locking.

The following questions need to be answered by vendors:

What will the SOA do if it sends an old NPA-NXX prior to PDP and the NPAC returns the new SV with the new NPA-NXX?  What would happen for a create/audit/query?
What will LSMS systems do if an audit is sent for new NPA prior to PDP?
Are there LSMS that will not be able to handle audits on new NPA-NXX right at the start of PDP?

(continued)	High +	N/A / N/A	
NANC 193
(con't)	Continued		How long does it take for NPAC/SOA/LSMS to split an NPA-NXX?
What is the NPAC behavior for recovery spanning time before & after PDP?
If NPAC splits starting at midnight and SOA sends new NPA-NXX for an NPA-NXX not in split what would  happen?

After reviewing the above questions.  It was determined that the NPAC should act as if the split had not occurred during split processing prior to permissive dialing.

A matrix of answers received above has been created.

It was discussed that this requirement would have to be implemented by SOA, LSMS, and NPAC vendors.  This requirement would shorten the window when errors could occur for the change of an NPA.  It was requested that we review and document on behavior in the following situations: When the NPAC receives a request sent before the splits after the split start, how should it respond?  Also when an SOA or LSMS receives a request sent before the split after the split start, how should it respond?

IIS flows for error scenarios will be created.  If an active is received by the NPAC SMS before PDP it will be rejected.  If the old SP is received after the end of PDP it will be treated as the old NPA-NXX if that NPA- NXX is still a valid portable NPA-NXX in the NPAC SMS otherwise it will be rejected.  Download requests after the start of PDP for information occurring before PDP should reflect the new NPA- NXX for subscription versions involved in a Port.

The matrix was finalized on the 5/22 T&O call.	
NANC 246	National Number Pooling Sub-Committee 11/19/98	NPA-NXX Filters for Bulk Data Download files of SVs
When the NPAC generates Bulk Data Download (BDD) files of SV data, NPA-NXX filters for a Service Provider are NOT incorporated in the BDD file generation process.

It has been requested that the NPAC be changed to incorporate the filters when generating the SV BDD files.

This change order is a subset of NANC 169 (same as requirement 11 in 169), which is shown below.
Req 1	Subscription Version Information Bulk Data Download – Filters for Subscription Versions
NPAC SMS shall apply NPA-NXX Filters to Subscription Versions in the creation of bulk data download files.	Low	FRS	Pure Backwards Compatible:  YES

Dec LNPAWG (Atlanta), accepted as is.  However, low priority.

December 2000 Meeting:  This change order had been merged into NANC 169.  At the December 2000 LNPA WG meeting it was decided to break out use it to apply filters to the Bulk Data Download files.  NANC 169 has a requirement to apply filters to the Delta Bulk Data Download files and the group wanted the same function applied to the regular Bulk Data Download files.	Low	N/A / N/A	
NANC 299	LNPA-WG 9/15/99	NPAC Monitoring of SOA and LSMS Associations via Heartbeat
This is an extension of NANC 219 and NANC 301.  Instead of utilizing a TCP Heartbeat and an abort message, the NPAC SMS would utilize an application level heartbeat message on every association.  If a response was not returned for any given application level heartbeat message, an alarm would be initiated for NPAC Personnel.

Oct LNPAWG (KC), this change order is designed to establish the application level heartbeat process (which requires an interface change to both the NPAC and the SOA/LSMS).  This process will allow two-way communication and allow either side to initiate the application level heartbeat message.  The application level heartbeat process should be set up so that the functionality can be optionally set up per association.

The alarming process is the same as 219, such that an alarm would be initiated whenever application level heartbeat responses are not sent by the NPAC or SOA/LSMS.  When these alarms occur, the NPAC Personnel would contact the affected Service Provider to work the problem and ensure the association is brought back up.	High	FRS, IIS, GDMO, ASN.1	Func Backwards Compatible:  NO

The current working assumption is that this heartbeat would be a new message, it would not have any access control, it would be at a low level in the protocol stack, this heartbeat would occur on the same port as the association, this message would only occur if no traffic was sent/received after a configurable period of time, and this heartbeat would be two-way to allow either side to initiate this message.

All parties still need to examine if there might be an issue with filtering in their firewalls.
The need for both a network level heartbeat and application level heartbeat still needs to be decided.

Jan 00 LNPAWG meeting, the group has not been able to determine the feasibility of implementing an application level heartbeat.  It was agreed to put this change order on hold, pending the outcome of NANC 301 (NPAC TCP Level Heartbeat [transport layer]).  The functionality documented in this change order needs further review before this change order can be considered “accepted and ready for selection into a release”.

(continued)	Med	Med -High / Med -
High	
NANC 299 (con’t)	continued				May 00 LNPAWG (Atlanta), leave open until further analysis of NANC 219 and NANC 301 (i.e., after R4 implementation).

June 00 LNPAWG meeting, group consensus (during R5 discussion) is to move to cancel-pending.

July 2000 meeting – LNPA WG consensus is that they do not want to cancel this change order but move it back to an accepted change order for a future release.  Metrics and reports that will be provided after R4.0 will give more information to determine whether or not this change order is needed.
			
NANC 300	LNPA-WG 12/6/99	Resend Exclusion for Number Pooling
This is an extension of NANC 227.  During the Dec 99 LNPA-WG meeting, it was proposed to remove Number Pooling functionality from NANC 227, and create a new change order for this functionality.
		FRS/GDMO	Functional Backwards Compatible:  NO

	Med	Med-Low	
NANC 311	GTE 6/5/00	Query Message of SP Association Status
Provide information of the current service status (TBD) for all LSMS associations in each NPAC region.  This query would be initiated by SOAs only. This would be an enhancement to NANC 219 and 301 (Association Monitoring) which both will be fully deployed in NPAC SMS Release 4.0.

Jun 00 LNPAWG meeting, at the suggestion of the CMA, the group discussion migrated away from a dynamically updated web site, to a query message that could be used by the soon-to-be-activating Service Provider, to determine if all associations are available.  This new query would be a CMIP message (M-ACTION) that would allow a query on an NPA-NXX, where the NPAC SMS would take into account all filters for that given NPA-NXX, and return a list of all SPIDs that are currently not available that should be available (i.e., the New SP is expecting an empty unavailable SP List).
		FRS	Functional  Backwards Compatible:  NO

December 2000 meeting:  LNPA WG decided to remove this change order from the Release 5.0 group but to keep it as an active change order until the results of the association monitoring that are being implemented in Release 4.0 (NANC 219) can be evaluated.  This change order, as it currently exists in the Release 5.0 package, will be removed from the Release 5.0 package and kept as a separate document until such time as it is determined if this change order should be implemented or closed.	Med	Med / N/A	
NANC 312	Nextlink 6/14/00	Different User Levels on the LTI
Provide two user security levels for the LTI.  One would have access to the reports option, and the second would not have this access.  All other access would be identical for the two user levels.
		FRS	Pure Backwards Compatible:  Yes

	Med	N/A	
NANC 316	LNPA WG 8/16/00	Change the NSAP Field Size Declaration in ASN.1 – ASN.1 Recompile
As described in change order NANC 315, the NSAP field currently uses only 12 of the 20 octets declared as the field size. The other 8 are for a port number but this is not currently used. The ASN.1 should be updated to be a field of size 12 octets. This would eliminate the need for the NPAC software to truncate the data sent by the SOAs and LSMSs.
ASN.1 Update:
OSI-Address ::= SEQUENCE {
    nsap    OCTET STRING(SIZE(2012)),
    tsap    OCTET STRING(SIZE(1..4)),
    ssap    OCTET STRING(SIZE(1..4)),
    psap    OCTET STRING(SIZE(1..4))
}
	?LOW	ASN.1	Func Backwards Compatible:  NO

Need to determine when to implement this change order

This change affects the Modify Customer Profile only.

October 2000 meeting:  Move to Accepted	???	???	
NANC 319	Verizon
10/25/00	NPAC Edit to Ensure NPA-NXX of LRN is in Same LATA as NPA-NXX of Ported TN

Local Number Portability (LNP) standards require that service providers assign at least one Location Routing Number (LRN) per switch per LATA that the switch serves.  Post-query LNP call processing in the various switch types requires that the NPA-NXX of an LRN that is returned from the database must be in the same LATA as the NPA-NXX of the dialed number.  
Currently, the NPAC does not perform any edits on a New Service Provider CREATE or MODIFY messages in order to ensure that the NPA-NXXs of both the LRN and the ported TN are in the same LATA.
When a call is placed to a ported TN associated with an LRN from an NPA-NXX in a different LATA, the call fails in the originating switch, resulting in a service-affecting condition that is predominantly identified only after customer complaints. 
This proposed Change Order is a request for an NPAC edit on New Service Provider CREATE and MODIFY messages that would reject any CREATE or MODIFY if the NPA-NXXs of the LRN and ported TN contained in the CREATE or MODIFY are not in the same LATA.  This edit would eliminate this particular service-affecting condition as well as the expense of trouble-shooting the cause and working with the New Service Provider to modify their LRN. 
		FRS	Func Backwards Compatible:  ???

November 2000 meeting: Currently the NPAC has no concept of a LATA.  When a new NPA-NXX is opened the LERG assigns a LATA ID.  An NPA can cross LATAs.  Every NPA-NXX has a LATA association.  It is a 3-digit number. There is one LRN per LATA but there can be multiple NPAs in a LATA and multiple LATAs in an NPA.  This edit would ensure that the NPA-NXX of the TN and the NPA-NXX of the LRN is the same. LATAs can cross NPAC regions.  The LERG would be the source of the LATA information rather than the Service Providers. If there is no LATA in the LERG information for the NPA-NXX or the LRN then the NPAC would reject the create request.  If there were a modification of an LRN to active SVS or in a Mass Update this edit would have to be applied.  This would also apply to Pooled Blocks.  LATA should not be criteria for Mass Update.

December 2000 Meeting:  Group accepted this change order.  It was also determined that the change order needed to cover Modifies as well as Creates.
	???	N/A / N/A	
NANC 321	WorldCom 12/13/00	Regional NPAC NPA Edit of Service Provider Network Data - NPA-NXX Data
Business Need:
When a service provider submits a message to the NPAC in order to create a pending subscription version, the NPAC verifies that the old service provider identified in the message is the current service provider and that the number to be ported is from a portable NPA-NXX.  If the telephone number already is a ported number, the NPAC will look at the active SV for that number to determine the identity of the current SP as shown in the active SV.  If no active SV exists, then the number is not currently ported and the NPAC determines the current SP instead based on NPA-NXX ownership as shown in the NPAC's network data for each service provider.  The NPAC also looks at the network data to confirm that the NPA-NXX has been identified as open to portability.

If a service provider has entered an NPA-NXX in its network data but has done it for its network data associated with the wrong region, then the correct NPAC region, when receiving create messages involving numbers in that NPA-NXX, will be unable to see that the TNs involve a portable NPA-NXX; in this case the create message will be rejected by NPAC.  Furthermore, another service provider could erroneously enter the NPA-NXX in its network data for the correct NPAC region.  Then the NPAC's portable NPA-NXX validation would pass, but the current service provider validation would fail.  In either case the telephone number could not be ported until the service provider network data error were corrected.
	???	FRS	Functional Backwards Compatible:  Yes

January 2001 meeting:  Accepted pending review of the final write-up in February.

February 2001 meeting:  Accepted	???	N/A / N/A	
NANC 321 (cont’d)		It is important therefore to assure that service provider NPA-NXX network data be populated only in the proper NPAC region and to allow only the LERG-assignee to populate the data.  The introduction of an NPA edit function, to validate that an NPA-NXX input is to network data associated with the NPAC region encompassing the involved NPA will effectively serve both functions.  Such an edit function would not allow a service provider to put its NPA-NXX data in the wrong NPAC region's database and it consequently would not allow the improper LERG-assignee entries to remain long undetected.  

Description of Change:

Network Data is submitted by service providers over their SOA/LSMS interfaces or via the NPAC Administrative OpGUI or the SOA LTI.  A provider is required to enter each portable NPA-NXX for which it is the LERG assignee.  The NPAC uses this service provider network data to perform certain validation functions of subscription version data -- to confirm current SPID correct and that TN is from portable NXX -- and to determine TN ownership in snap-back situations.

Detailed requirements are as follows:

1.  The NPAC will reject an NPA-NXX network data entry attempt if the NPA involved is not encompassed by the NPAC region to which the data is being submitted.

2.  A table of valid NPAs will be established for each regional NPAC.

3.  Each table of valid NPAs open in the NPAC service area will be maintained by NPAC personnel for each regional NPAC.

4.  The NPAC will obtain information on new NPAs from the LERG.

5. The change order would be implemented on a regional basis.

NANC 322	LNPA WG 12/13/00	Clean Up of Failed SP Lists based on Service Provider BDD Response File
Business Need:
During discussion of change order NANC 169 at the December 2000 LNPA WG meeting it was decided to write a new change order to address the clean up of Failed SP Lists once a service provider received and processed a Bulk Data Download File or a Delta Bulk Data Download File and responded to the NPAC with its Service Provider Response File.

Description of Change:
It has been requested that NPAC clean up Failed SP Lists using data received in the Service Provider Response File resulting from the processing of a Bulk Data Download File or a Delta Bulk Data Download File.
	???	FRS	Pure Backwards Compatible: Yes

January 2001 meeting:  Accepted	???	N/A / ???	
NANC 323	LNPA WG 01/10/01	During the January 2001 LNPA WG meeting there was much discussion on the NANC 217 change order and it was decided that it would be best to have two change orders for updating of SPIDs.  NANC 217 would be retained and used to cover the simple case where a SPID is being completely retired (merger or acquisition) and a new change order created to cover the partial update of a SPID.  	???	FRS	When there is a need to migrate a portion of one SPIDs data to another SPID a mass update with Service Provider notifications suppressed will be used.  Service Providers receive a file from NPAC with information they can use to update their databases.

February 2001 meeting:  Accepted 
	 High	???/???	
NANC 328	Wireless Ops SC 3/20/01	Tunable for Long and Short Business Days

Business Need:  Currently, per RR3-30 in the FRS, the NPAC SMS has Long Business Days defined as Monday through Saturday excluding NPAC operations-defined holidays.  This means that short timers only run Monday through Saturday. Wireless Service Providers need short timers to run on Sundays as well so they can port in a 2½ hour window on all days of the week.  To meet this need Long Business Days need to be Monday through Sunday.

April 2001 LNPA WG Meeting:  AT& T Broadband requested that the change order include making Short Business Days a tunable also.  The LNPA WG accepted this request.

Description of Change:  Wireless Service Providers are requesting that Long Business Days be defined as a tunable with a default value of Monday through Sunday.

April 2001 LNPA WG Meeting:  The change order will be revised to make both Long and Short Business Days a tunable. 

(cont’d)	High	FRS	Pure Backwards Compatible: Yes

April 2001 Meeting: AT&T Broadband requested that the change order include making Short Business Days a tunable also.  This was accepted by the LNPA WG and the CMA was directed to revise the change order accordingly and present it again at the May 2001 meeting.

May 2001 Meeting:  Modifications to include Short Business Days accepted.

	Low
	N/A / N/A	
NANC 328 (cont’d)		Requirements:
Req 1	Long Business Days Tunable Parameter
NPAC SMS shall provide a Long Business Days tunable parameter that defines the days of the week that are valid for operations involving business time calculation excluding NPAC operations-defined holidays.

Req 2	Long Business Days Tunable Parameter – Default Value
NPAC SMS shall default the Long Business Days tunable parameter to Monday through Sunday.

Req 3	Long Business Days Tunable Parameter – Valid Values
NPAC SMS shall use days of the week as valid values for the Long Business Days tunable parameter.

Req 4	Short Business Days Tunable Parameter
NPAC SMS shall provide a Short Business Days tunable parameter that defines the days of the week that are valid for operations involving business time calculation excluding NPAC operations-defined holidays.

Req 5	Short Business Days Tunable Parameter – Default Value
NPAC SMS shall default the Short Business Days tunable parameter to Monday through Friday.

Req 6	Short Business Days Tunable Parameter – Valid Values
NPAC SMS shall use days of the week as valid values for the Short Business Days tunable parameter.

								

Next Documentation Release Change Orders
Next Documentation Release Change Orders	
Chg Order #	Orig. / Date	Description	Priority	Category	Proposed Resolution	Level of Effort	
						NPAC	SOA LSMS	
NANC 305	CMA 1/24/00	R3 ASN.1 documentation-only updates

1.
SystemType ::= ENUMERATED {
    soa(0),
    local-sms(1),
    soa-and-local-sms(2), -- value not
                             supported
    npac-sms(3)  -- value is only valid for
                    AccessControl definition
}

The comment for the second enumeration should be changed from   “value not supported”
to   “it is assumed this value will not be sent by any local system”.		ASN.1	Pure Backwards Compatible:  YES
	N/A	N/A	
NANC 324	AT&T 01/25/01	IIS Document Only Change – Flow B.5.4.7.3: Subscription Version Disconnect With Effective Release Date

The text in line 5 of the flow is incorrect. 

Currently it states 
	M-EVENT-REPORT subscriptionVersionDonorSP-DisconnectDate

It should be
	M-EVENT-REPORT subscriptionVersionStatusAttributeValueChange
		IIS	February 2001 meeting:  Accepted 	N/A	N/A / N/A	
NANC 325	AT&T 01/25/01	GDMO Document Only Change – 4.0 LNP Subscription Version Cancel Action

Need to add some additional text to the subscriptionVersionCancelBehavior BEHAVIOUR
Postconditions to cover the cancellation of a disconnect-pending.

Current text:

subscriptionVersionCancelBehavior BEHAVIOUR

Postconditions: The service provider has set the version status to cancel-pending if the other service provider has concurred, or to cancel if the other service provider has not concurred. An error will be returned if there is no version that can be canceled or the service provider is not authorized.

Proposed text:

subscriptionVersionCancelBehavior BEHAVIOUR

Postconditions: If the status was pending or conflict, the service provider has set the version status to cancel-pending if the other service provider has concurred, or to cancel if the other service provider has not concurred. If the status was disconnect-pending, the service provider has set the version status back to active. An error will be returned if there is no version that can be canceled or the service provider is not authorized.
		GDMO	February 2001 meeting:  Accepted 	N/A	N/A / N/A	
NANC 326	AT&T 02/02/01	IIS Document Only Change – Flow B.5.6: Subscription Version Query

The query return data list in step 2 is missing one item. It should contain “subscriptionVersionId”. 

Currently it states: 

     The query return data includes:

	subscriptionTN (SOA, LSMS)
	subscriptionLRN (SOA, LSMS)
	subscriptionNewCurrentSP (SOA, LSMS)
	…

Change to:

     The query return data includes:

	subscriptionVersionId (SOA, LSMS)
	subscriptionTN (SOA, LSMS)
	subscriptionLRN (SOA, LSMS)
	subscriptionNewCurrentSP (SOA, LSMS)
	…

		IIS	February 2001 meeting:  Accepted 	N/A	N/A / N/A	
NANC 327	Neustar 3/19/01	FRS Document Only Change – Update Appendix C – System Tunables

Currently the Subscription Tunables Table in Appendix C has Short Business Days and Long Business Days listed as tunables.  Per requirements RR3-11 and RR3-30 this is incorrect.  Requirement RR3-11 states “NPAC SMS short business days shall be Monday through Friday excluding NPAC operations-defined holidays”.   Requirement RR3-30 states “NPAC SMS long business days shall be Monday through Saturday excluding NPAC operations-defined holidays”.   

(continued)		FRS	Proposed Resolution: Remove the Short Business Days and Long Business Days items from the Subscription Tunables Table in Appendix C of the FRS. 

April 2001 Meeting: Accepted.  The update will be made in the next release of the FRS, date 	N/A	N/A / N/A	
NANC 327 (cont’d)	Current Table:
Subscription Tunables	

Tunable Name	
Default Value	
Units	
Valid Range	

Long Initial Concurrence Window	
9	
business hours	
1-72	

The hours subsequent to the time the subscription version was initially created by which both Service Providers using long timers are expected to authorize transfer of service if this is an Inter-Service Provider port. (T1 timer)	

…	

	

Long Business Day Start Time	
TBD	
hh:mm	
00:00 - 24:00	

Parameter tunable to the value specified by the contracting region for long business days.  	

Short Business Days	
Monday – Friday	
Days	
Monday – Sunday	

The business days available for Service Providers using short business days.	

Long Business Days	
Monday – Sat.	
Days	
Monday - Sunday	

The business days available for Service Providers using long business days.	

(continued)	
NANC 327 (cont’d)	Revised Table:
Subscription Tunables	

Tunable Name	
Default Value	
Units	
Valid Range	

Long Initial Concurrence Window	
9	
business hours	
1-72	

The hours subsequent to the time the subscription version was initially created by which both Service Providers using long timers are expected to authorize transfer of service if this is an Inter-Service Provider port. (T1 timer)	

…	

	

Long Business Day Start Time	
TBD	
hh:mm	
00:00 - 24:00	

Parameter tunable to the value specified by the contracting region for long business days.  	

	

	

	

	

								

 Release 4.0 Change Orders
Release 4.0 Change Orders	
Chg Order #	Orig. / Date	Description	Priority	Category	Proposed Resolution	Level of Effort	
						NPAC	SOA LSMS	
ILL 130	AT&T 
1/6/97	Application Level Errors
Errors in the SOA and LSMS interfaces are being treated as CMIP errors and it may sometimes be difficult for a SOA to know the true reason for an error from the NPAC SMS and therefore indicate a meaningful error message to its users.  It has been requested that application level errors be defined where appropriate and returned as text to the SOA.	High	FRS, IIS, GDMO, ASN.1	Func Backwards Compatible:  NO

Application level errors would be defined in the IIS.

Refer to R4 Change Orders for current proposed resolution.	High	High / High	
NANC 138	CMA
8/11/97
	Definition of Cause Code Values – REVISITED
NANC 54 defined the cause code values and the FRS was to be updated.  Due to an oversight this update was not made in the FRS.  The change was going to be applied in FRS 1.4 and 2.2.  However, a discrepancy as found. The defined values specified in NANC 54 where are as follows:

The values less than 50 were reserved for SMS NPAC internal use.

Other defined values are:

0 – NULL (DO NOT MODIFY)
1 -	NPAC automatic cancellation
50 -	LSR Not Received
51 -	FOC Not Issued
52 -	Due Date Mismatch
53 -	Vacant Number Port
54 -	General Conflict

In table in the FRS the following cause code is defined:  NPAC SMS Automatic Conflict from Cancellation

There is no corresponding code defined in Change Order NANC 54.  Is there a numeric value or is this cause code valid?	Medium Low	FRS	Func Backwards Compatible:  NO

Update to be made to the FRS.

Pending review by the vendors.  Lockheed does not set a cause code when the NPAC SMS automatically puts a cancelled order into conflict.  Perot is reviewing their implementation.

There is not a requirement in the FRS for a cause code of NPAC SMS Automatic Conflict from Cancellation.
 
Operations flows are being reviewed. In figure 6, box 3.

Perot like Lockheed does not use the cause code in question.

A SOA vendor has been asked to evaluate the impact of not receiving a cause code value with a status of conflict.

Flows in Appendix A also need to be updated.	Low	Low / Low	
NANC 138
(cont.)	Continued	Requirements for the cause code addition would be as follows:

RR5-36 should be renumbered to RR5-36.2.

RR5-36.1 Cancel Subscription Version – Cause Code for New SP Timer Expiration 

NANC SMS shall set the cause code to “NPAC SMS Automatic Conflict from Cancellation” after setting the Subscription Version status to conflict from cancel-pending when the new Service Provider has not acknowledged cancellation after the Cancellation-Final Concurrence Window. 

2 will be the value defined for the “NPAC SMS Automatic Conflict from Cancellation” cause code.		Awaiting sizing from NPAC vendors, and validation of functionality (reference existing requirements) from cancellation to conflict.

SOA vendors heard from to date do not have a problem with the cause code not being present.

This is an "OLD" Release 2.0 change order, that has been moved into the "Accepted" category, awaiting prioritization

Refer to R4 Change Orders for current proposed resolution.	
NANC 179	Lockheed Martin 11/25/97	TN Range Notifications
Currently notifications for TN range related operations come as individual notifications for each TN in the range.  It has been suggested that the notifications for all TN’s in a range be combined into one notification.

After further analysis, it was determined that this should be revised to include all appropriate status attribute value changes and attribute value changes, plus return to donor notifications.	Medium	FRS, IIS, GDMO, ASN.1	Func Backwards Compatible:  NO

An additional write-up of this change order implementation was provided to the group.  Lockheed is currently doing some preliminary sizing.

SPs should be discussing the downsized version internally.

Refer to R4 Change Orders for current proposed resolution.	Med	Med-High / N/A	
NANC 187	AT&T
1/7/98	Linked Action Replies
It has been requested that all action replies be reviewed to determine if they should be linked replies.

Sep 99 LNPA-WG (Chicago), it was requested to merge the NANC 186 text into this change order.

NANC 186 text -- It has been requested that the notification recovery action reply be a linked reply.  This would be done to control the size of the response sent back to the Local SMS systems.	High	FRS, IIS, GDMO	Func Backwards Compatible:  NO

Related to NANC 186 and NANC 183.

Actions that were identified as issues were the network and subscription version recovery actions. It is suggested that service providers that cannot handle large PDUs request network or subscription version recovery in smaller time intervals.  A request has been made to Lockheed to document this in M&P.

NANC 186 text -- Related to ILL 79, NANC 183, and NANC 184.  As a work around to the large PDU size in the interim.  It is suggested that service providers that cannot handle large PDUs request notification recovery in smaller time intervals.

Refer to R4 Change Orders for current proposed resolution.	Med	Med / Med	
NANC 191	Ameritech 1/19/1998	DPC/SSN value edits
It has been requested that DPC and SSN values be edited to make sure that if a SSN is specified that the DPC is specified.  This functionality was requested due to a problem with a large port were the DPC and SSN information entered by the originator was invalid.  Currently the NPAC SMS does no validity checks on the SSN and DPC information other than it is of the format and type defined in the IIS and FRS.	High	FRS, GDMO	Pure Backwards Compatible:  YES

The edits need to be verified by industry experts to insure they are correct.  Gary Sacra has taken an action item to obtain more information from T1/S1.6.

The following information was provided by Gary for DPC/SSN edits:

•	The 9-digit point code (DPC) is broken down into three components:  3-digit
•	Network ID - valid range=001-255
•	3-digit Cluster ID - valid range=000-255
•	3-digit Member number - valid range=000-255
•	Subsystem Number (SSN) is a separate three digit number with a valid range of 000-255.
•	It does not make sense in the network to have a DPC without an SSN or vice versa.

Refer to R4 Change Orders for current proposed resolution.	Low	N/A / N/A	
NANC 192	T&O Conference Call 
1/23/1998	NPA Split NPAC SMS Load File
It was requested that a file be used to load NPA Split information into the NPAC SMS.  This would prevent manual data entry that could introduce errors when entering the NPA Split information.	High	FRS, IIS	Pure Backwards Compatible:  YES

John Malyar from Bellcore gathered some information for the group as to whom, how, and when for files containing the data that are distributed in the industry currently.

John indicated that NANPA identifies and announces the split.  The LERG has tools to pull data for a split and distribute it electronically.  This is one source from which a file can be obtained.

Refer to R4 Change Orders for current proposed resolution.	Med	N/A / N/A	
NANC 200	AGCS 2/28/1998	Notification of NPA Splits
It has been requested that to facilitate synchronization during NPA split, the NPAC via the mechanized interface should notify the SOA and LSMSs. The preferred method would be to have a new managed object that contains all split information. It would still be up to the respective system to perform the splits, but all systems would be in sync. A second alternative would be to have the NPAC issue a notification that states the NPAC is start/ending split processing.	High	FRS, IIS, GDMO, ASN.1	Func Backwards Compatible:  NO

This change order is related to change order NANC 192 that proposes getting the split information from the LERG.

Refer to R4 Change Orders for current proposed resolution.	Med / Low	Med / Med	
NANC 217	Sprint 5/22/1998	Mass Update of SPID
It has been requested that Mass Update functionality be enhanced to allow SPID to be changed for all network data and subordinate subscription data.  The current NPAC functionality allows mass updates to LRN, GTT data, and optional data (e.g., billing ID) for all active subscriptions currently serviced by that specific Service Provider, by NPA-NXX.

Having this functionality would facilitate a situation where one Service Provider (SP1) purchases/merges with another Service Provider (SP2), and all LNP data needs to be consolidated into a single SPID (on the NPAC).

Today, the NPAC requires all active subscriptions to be disconnected, and all pending subscriptions to be cancelled, by NPA-NXX for all NPA-NXXs owned by SP2.  Next, SP2 would delete all LRNs, then delete all NPA-NXXs.  SP1 would then have to add the NPA-NXXs and LRNs that were just deleted by SP2.  Finally, the pending and activated SVs would need to be “re-created” under the presumption that SP1 is now the code holder for the NPA-NXXs.

The proposed solution with this change order is the NPAC would perform all of this processing “under the sheets”, and not require SP1 and SP2 to perform all of these steps.

The issue of notifications (whether to send or suppress) is NOT addressed at this point in time.

(continued)	High	IIS, FRS	Func Backwards Compatible:  NO

After much discussion on the 7/8/98 telecon, it was decided that the scope of this change order is huge, and its frequency of use is undetermined at this point in time (speculation is relatively small).

Additionally, AT&T requested that all SPs look at the possibility of performing some type of database migration/conversion instead of having the NPAC perform all of the updates, then have to broadcast to all SPs.  The database migration/conversion could potentially be accomplished by using a new NPAC “bulk download file” to update the local database.

The current position for this change order is to have a brief discussion at the Wed, 7/15 meeting in Chicago.  The group will seek volunteers for a sub-committee to further analyze this change order in the context of how to accomplish a “merger” using today’s functionality, and investigate potential solutions using a “bulk download file” approach, and a full NPAC solution with notifications across the interface.

July T&O (Chicago).  Beth Watkins (AT&T) agreed to coordinate the first telecon for this sub-committee.

(continued)	High	High / High	
NANC 217
(con’t)	Continued	After further analysis it was determined that the current NPAC implementation includes 23 tables that contain a customer SPID.  Each will have to addressed (at a business level) to determine correct NPAC processing should the SPID be modified.

The other issues to determine include:

1.  length of time to complete this update.
2.  which notifications need to be sent out over the SOA interface, since we are modifying numerous objects.
3.  what do we do with current Network and Subscription records (update them with new SPID; or create new ones for the new SPID, and move the previous ones to OLD).		Sep LNPAWG (Seattle), a telecon has been scheduled for 9/29, 1p Central, 2 hours.  In this initial telecon, the sub-committee will determine the scope of the discussion, and set ground rules for subsequent meetings on this change order.

Participants include, AT&T (Beth), Bellcore (John), ESI (Jim), GTE (Gene), MCI (Gustavo), PacBell (Jackie), and Sprint (Dave).  Others are welcome to join.

The subcommittee will also talk about the potential of a "partial cut" from one SPID to another (possibly do on a market by market basis, or NPA by NPA basis).

Oct LNPAWG (Kansas City), the 9/29 telecon was cancelled.  The make-up call is 10/21, 1p Central.  Beth to send out bridge info.

Nov LNPAWG (Dallas), The 10/21 call did not have any Lockheed representation, so discussion did not get far.  The next call is scheduled for Mon, 11/23, 1p Central, 2 hours.

During the 11/23 telecon, it was determined that Beth’s proposed short term solution would not be easy to accomplish.  Details on the telecon will be available at the Dec LNPAWG meeting.

Dec LNPAWG (Atlanta), Mass update is the long term solution, but wanted to have short term solution.  In the case of MCI and Brooks, they deleted the SVs, deleted the network data, then put it back out there under the new SPID.

What we looked at for an NPAC manual update, then produce BDD, would require code changes.  Plus, BDD would be all records instead of just changed ones.  Also, SVs would be modified instead of activated, so the current BDD by time range would NOT pick these up.

(continued)	
NANC 217
(con’t)	Continued			Current solution is customer impacting.  Two long term options are the actual mass update of this change order, or having the NPAC internally update the SPID, then create appropriate BDD files that capture the changes within the time range.

Leave on open list for now.

Jan LNPAWG (Atlanta), Beth to set up another telecon (possibly end of Jan) to discuss next step.
During follow-up discussion with several members of the 217 analysis group, bandwidth (for meeting) was limited, due to Natl N Pool meetings.

Feb LNPAWG (San Ramon), backburner due to Natl N Pool commitments.

Refer to R4 Change Orders for current proposed resolution.

December 2000 meeting:  Sprint re-opened discussion on this change order.  As a result of the discussion additional information was added to both the Business Need and Description of Change to cover the situation of a single SPID being split into multiple SPIDs or a portion of a service provider’s subscription versions being moved to another SPID.

January 2001 meeting:  After much discussion on this change order the LNPA WG decided that it would be best to have two change orders for updating of SPIDs.  A new change order, NANC 323, would be created to cover the partial update of a SPID and most of the information in this change order would be moved into the new change order.  This change order, NANC 217, would be used to cover the simple case where a SPID is being completely retired (merger or acquisition).

NANC 218	Sprint 6/5/1998	Conflict Timestamp Broadcast to SOA
It has been requested that when a subscription gets placed in conflict, that the time that the subscription version was placed into conflict be broadcast in the status attribute value change notifications to the SOA.  Currently it is defined in the IIS on page 262 (version 1.8) that NPAC is not required to send the timestamp information.  This change would prevent the service provider SOA from having to query the NPAC anytime they need to retrieve a timestamp.  This conflict timestamp is needed so that the new service provider knows when the 6-hour timer has expired and so that they can remove it from.  Also the presence of this timestamp indicates if the subscription has been placed into conflict before.	Med	IIS	Pure Backwards Compatible:  NO
Func Backwards Compatible:  YES

It was noted that a SOA could work around this issue, by automatically querying the NPAC for the conflict timestamp, anytime the SP receives a conflict status for an SV.

Leave on open list for now.

Refer to R4 Change Orders for current proposed resolution.	Low	Low / N/A	
NANC 219	AT&T 6/5/1998	NPAC Monitoring of SOA/LSMS Associations
It has been requested that NPAC Monitoring of SOA and LSMS associations be put into the NPAC SMS at the application (CMIP) layer.  The approach suggested by the requestor would be to alarm whenever aborts are received or sent by the NPAC.  When these alarms occur, the NPAC Personnel would contact the affected Service Provider to work the problem and ensure the association is brought back up.

From this point forward, this change order will deal with the alarm abort option.  The heartbeat abort option is NANC 299.	High	FRS	Pure Backwards Compatible:  YES

Sep LNPAWG (Seattle), discussed various options for working the problem of dropped associations (i.e., causes partial failures for the new SP trying to activate).

Options include, 
1.)  sending a notification to all SPs that "an SP is currently not associated", then another notifications once it is back up, "all SPs associated".
2.)  stopping an activation request, because an association is down.
3.)  sending a notification to the New SP when an activate is received, that an association is down, "do you still want to activate?".

NEXT STEP:  all SPs should consider issues and potential options for activates during a missing association that will cause a partial failure.

Oct LNPAWG (Kansas City), the conversation migrated away from the three options discussed in Seattle, and back to the NPAC proactively monitoring the association.  This would require the NPAC to provide an attendant notification that a Service Provider is down, then notifying them of their missing association.

(continued)	Low (alarm abort)

Med (heartbeat abort)

High (ops costs for all options)	N/A / N/A	
NANC 219
(con't)	Continued				So, anytime the NPAC receives an abort from a Service Provider, an NPAC alarm should be triggered, and an M&P should kick in where NPAC personnel notify the downed SP.

This has been moved into the "Accepted" category, awaiting prioritization.

Refer to R4 Change Orders for current proposed resolution.	
NANC 227	MCI
8/7/98	10-digit TN Filters (previously know as "Ability to Modify/Delete of Partial Failure SV")
OLD TEXT:  The NPAC SMS currently rejects a request to "modify active" or "delete" an SV that has a partial failure status.  Nothing can be done to the SV until the discrepant LSMS(s) come back on line, and either recover the broadcast, or accept a re-send from the NPAC.

OLD TEXT:  A business scenario arose whereby a partial failure was affecting a customer's main number, and the New SP couldn't do anything to the SV until the partial failure was resolved.

NEW TEXT:  The NPAC should provide a mechanism that allows 10-digit filters, in order to clean up partial failure SVs that need to be subsequently modified or deleted, by the New SP.

Jun 99, during the Pooling Assumptions walk-thru, four SV requirements were modified, and the functionality was moved into this change order.  Basically, the “partial failure/failed” text is moved to this change order.  The affected requirements are listed below:

SV-230 Modification of Number Pooling Subscription Version Information – Subscription Data
SV-240 Modification of Number Pooling Subscription Version Information – Status Update to Sending
SV-270 Modification of Number Pooling Subscription Version Information – Status Update
SV-280 Modification of Number Pooling Subscription Version Information – Failed SP List
	High	FRS, GDMO	Func Backwards Compatible:  NO

Discussed during 8/12/98 face-to-face T&O meeting (Detroit).

OLD TEXT:  It was determined that the business scenario was primarily human error, and the NPAC should NOT be modified to allow a partial failure to go to active, but still have out-of-sync LSMS(s).

OLD TEXT:  A workaround (available with 1.3 [with the exception of PTO]) would be to temporarily set up a filter for the discrepant LSMS(s), do a re-send which would clear up the failed-SP-List and set the SV to active, then remove the filter.

OLD TEXT:  NEXT STEP:  all SPs and vendors should evaluate if this is an acceptable solution.

OLD TEXT:  Sep LNPAWG (Seattle), this potential M&P work-around has been forwarded to NPAC Operations (Jan Trout-Avery) for further analysis, and will be discussed at the x-regional in New Orleans.

(continued)	High	Med-Low / N/A	
NANC 227
(con't)	Continued	This change order is related to NANC 254.			OLD TEXT:  This change order will be left open pending the discussion in New Orleans.

Oct LNPAWG (Kansas City), after discussions in New Orleans at the x-reg meeting, it was requested by Service Providers that Lockheed use the M&P for "partial failures where the customer is out of service" only.

Jan will be doing an M&P on this, and will accumulate data on the frequency of this situation.  Everyone should be aware that the risk for the M&P is that any other SVs that are coming down in the NPA-NXX will NOT be sent to the LSMS.  From an NPAC functional perspective, a potential problem is the complexity of having to keep "versions" of versions, when you have an activate that fails, then allow a modify on top of this.

Jim Rooks provided info on this, to state that he is uncomfortable with the modify of a partial failure.  We further discussed the potential of a 10-digit filter that would override the existing 6-digit filter.  This should be the same change order, but will replace the title from modify partial failure to 10-digit filter.

Nov LNPAWG (Dallas), re-capped discussion from KC.  Desire of this functionality is to have NPAC Personnel perform this activity (of putting up 10-digit filters), and NOT allow SPs to send this over the interface.

This has been moved into the “Accepted” category, awaiting prioritization.  The group will flush out the details once this gets placed into a specific release.

Jul LNPAWG (Ottawa), no comments on pooling additions.

Refer to R4 Change Orders for current proposed resolution.	
NANC 230	Sprint
8/12/98	Allow a Donor SOA to Create a Port-to-Original on an intra-service provider port
The current NPAC SMS functionality does not allow a Donor SOA to create a PTO SV with LNPType = LISP.

The business scenario is that a customer is “home'd” to switch A, then moves down the street and is “home'd” to switch B (still in same rate center, so was LISP-ed to switch B), then moves back up the street (and needs to be re “home'd” to switch A, but is still a working number).
In this scenario, the SP should send an LISP PTO create and activate.
	High	FRS, IIS, GDMO	Func Backwards Compatible:  NO

August T&O (Detroit).  This change order was opened to replace its "sister" change order, NANC 223.

NEXT STEP:  all SPs and vendors should evaluate if this is an acceptable solution, or if there are any operational issues with sending an LISP PTO.

Sep LNPAWG (Seattle), All SPs are O.K. with this change order.
Jim Rooks will look at this, since there may be an NPAC issue.  In some current processing the NPAC needs the LNP type and if it is not available, the NPAC looks at the SPID values, and if they are the same, then the NPAC assumes it is LISP.  Jim's point is that there may be an interface change.  He will report at the next meeting.

Oct LNPAWG (Kansas City), Jim reported that this will NOT require an interface change.  It does, however, require a change to the NPAC processing rules.  Some of the changes for Pooling help to minimize changes to the NPAC.

This should be moved into the "Accepted" category, awaiting prioritization

Refer to R4 Change Orders for current proposed resolution.	Med	Med / N/A	
NANC 232	MetroNet
8/14/98	Web Site for first port notifications
Currently all SOAs and LSMSs receive "first port" notifications.  A request has been submitted to provide this information on the NPAC Web Site.

Sep LNPAWG (Seattle).  This change order was introduced by MetroNet as a means for LTI users to obtain "first port" notifications.

The current process does NOT send this information to the LTI user (unlike SPs that have a CMIP-based SOA), but requires the LTI user to "query" the NPAC for notifications contained in the NPAC notification log (for that specific SP).  Currently, this log contains the most recent 25 notifications for that SP.  The user may also generate an NPAC report of all notifications for that SP.

The desire is to have these "first port" notifications on the web, similar to the NPA-NXX openings that are on the web today.	High	FRS	Pure Backwards Compatible:  YES

Sep LNPAWG (Seattle).  This change order was discussed by those in attendance.  It was agreed that this change order was acceptable, and should be moved to the "Future Release CLOSED" List, and await prioritization from the group.

NOTE:  This change order is similar to the existing requirements, R3-10 and R3-11 (Web bulletin board updates of NPA-NXXs and LRNs).

Refer to R4 Change Orders for current proposed resolution.	Low	N/A / N/A	
NANC 240	LNPA WG
10/15/98	No cancellation of SVs based on expiration of T2 timer
During the discussion of NANC 198, it was mentioned that Service Providers end up doing more work if the NPAC cancels an SV, at the expiration of the T2 timer, when a New SP does NOT send up a matching Create message.

Therefore, this change order has been opened to explore the possibility of changing the NPAC to cancel the SV, "at some later date", than the expiration of T2, which is what the current functionality requires (R5-23.4 New Service Provider Fails to Authorize Transfer of Service).

This change order is related to NANC 198.

During the Sep LNPA-WG meeting, another option was proposed by Ameritech.  After T2 has expired and the New SP has NOT sent up a matching SV create, the NPAC SMS sets the SV to conflict (instead of cancel).  The conflict would go to cancel after a tunable (currently set to 30) number of days (i.e., self cleaning), reference tunable “Conflict Expiration Window”.	High	FRS, IIS, GDMO, ASN.1	Func Backwards Compatible:  NO

Jim will look into NPAC functionality to determine if there are any issues.

Service Providers should evaluate internal issues with the LSR/FOC process, as well as operational impacts that may occur if this change order is implemented.  Specifically, the New SP should evaluate if they could use the T1 expiration timer notification, as a mechanism to take an action, and send up the matching Create message to the NPAC.

MCI has requested that the following be considered for the processing steps:

When the T2 timer expires before a new SP Create message is  received by NPAC, the NPAC shall:

1. send notification to both old SP and new SP that T2 timer has expired, and

2. start the T3 timer (tunable).

Upon receipt of the new SP create before expiration of the T3 timer, the NPAC shall stop the T3 timer.

(continued)	Med / High	? / N/A (? depends on implementation)	
NANC 240
(con’t)	Continued			Upon expiration of the T3 timer before new SP create message is received by NPAC, the NPAC shall:

1. cancel the pending SV, and

2. send notification to both old SP and new SP that pending SV is canceled due to missing new SP create.

Nov LNPAWG (Dallas), spirited discussion by the group.  One thing to keep in mind that if we determine we do NOT want the NPAC to auto cancel at the expiration of T2 (and want some later date), then we need to separate this from the T2 timer.  Need to add the option that we may need to incorporate this auto cancel into some type of housekeeping, and not have it scheduled like today’s T1 and T2 timers.

Move to accepted, even though the words are still very uncertain, we haven’t decided on the actual solution, and we need to perform further analysis.  The T3 option proposed by MCI is just one of several potential options that need to be hashed out when this change order gets prioritized to a specific release.

Refer to R4 Change Orders for current proposed resolution.	
NANC 249	Sprint 12/9/98	Modification of Dates for a Disconnect Pending SV
The NPAC should be changed to allow a Service Provider to modify the CDD (Customer Disconnect Date) and ERD (Effective Release Date) for an SV that has a status of “disconnect pending”.	High	FRS, IIS, GDMO	Func Backwards Compatible:  NO

The current Service Provider would send a subscriptionVersionModify using an M-ACTION.

subscriptionCustomerDisconnectDate and subscriptionEffectiveReleaseDate would need to be added as modifiable attributes.

A new IIS flow needs to be developed (Subscription Version Modify Disconnect Pending Version Using M-ACTION by a Service Provider SOA).

If the newly modified ERD is the current date or a previous date, the NPAC will follow the “immediate disconnect” flow (6.5.4.1).  Otherwise, it’s BAU for the future dated ERD (6.5.4.2).

R5-25 needs to be changed to allow for a modification of an SV with a status of disconnect pending.

R5-36 and R5-38.1 needs the CDD and ERD attributes added to the list.

R5-41 and RR5-41.x need to perform exception processing (i.e., NOT send to LSMSs at this time) of modifications where the new ERD is a future date.

(continued)	Low	Med / N/A	
NANC 249 (con’t)	Continued				New requirements:
1.	NPAC SMS shall reject a modification request of an SV with a status of disconnect pending, where the CDD value is zero.

Jan LNPAWG (Atlanta), group O.K. with this change order.  Move to accepted list.

Refer to R4 Change Orders for current proposed resolution.	
NANC 254	LNPA
WG 1/12/99	NPAC Requirements - Subsequent Ports of Active SV with a Failed SP List
The Failed SP List should be zeroed out (on the old SV), once the new SV gets activated.
Req 1 – NPAC SMS shall remove a Service Provider from a Subscription Version’s Failed SP List, where the Subscription Version’s status is Old, once a subsequent port for that TN has started the broadcast of subsequent activity to the LSMSs.
NOTE: For Req 1 above, “subsequent activity” refers to activations, modify actives, disconnects, and PTO of a TN that has been previously ported.

A Service Provider should only be allowed on the Failed SP List for 1 (one) SV for any given TN.
Req 2 – NPAC SMS shall allow a Service Provider to only be on the Failed SP List for one Subscription Version, for a given TN, at any given point in time.

A Service Provider should be capable of recovering an SV download, even though the Failed SP List has been cleaned up for the previously active SV.
Req 3 – NPAC SMS shall support the recovery of subscription data for a Service Provider over an NPAC SMS to Local SMS association, for a previously active Subscription Version which contained that given Service Provider on the Failed SP List, then had that given Service Provider removed from the Failed SP List as a result of a subsequent port, all which occurred while that given Service Provider did NOT have an active association to the NPAC SMS.		FRS, GDMO	Func Backwards Compatible:  NO

Jan LNPAWG (Atlanta).  This change order was opened to replace its "sister" change order, NANC 245.

Feb LNPAWG (San Ramon), leave on open list for now.  BST evaluating 245 and 254, to see if O.K. with clearing out the Failed List on previous port, when they are the Old SP.

Mar LNPAWG (Denver), BST O.K. with this.  Move to accepted category.

This change order is related to NANC 227.

Refer to R4 Change Orders for current proposed resolution.	High	Med-Low / N/A	
NANC 285	LNPA WG
5/12/99	SOA/LSMS Requested Subscription Version Query Max Size
A SOA/LSMS request for a Subscription Version query that exceeds the maximum size tunable (“Maximum Subscriber Query”), returns an error message to the SOA.

Similar to the processing in NANC 273, it has been requested the NPAC return SVs up to the max tunable amount instead.  The SOA/LSMS would accept this message, then use it’s contents to send another query to the NPAC, starting with the next TN, and so on until all SVs are returned to the SOA/LSMS.

It will be up to the SOA/LSMS to manage the data returned from the NPAC and determine the next request to send to the NPAC in order to get the next set of SVs.

The NPAC will continue to return SVs that meet the selection criteria.  However, the NPAC will not return a “count” to the SOA/LSMS for number of records that match the selection criteria.

This solution will resolve the problem described in NANC 279 (SOA Resynchronization for Large Ranges), where a problem exists for recovering the SOA for large ranges, because the SV time stamp that the NPAC users for recovery is the same for large ranges.

The example used for NANC 279 was, if all the TNs in the range contain the same time stamp (e.g., 17 minutes and 20 seconds after 3p, 15:17:20), and the number of TNs in the range exceeds the tunable allowed for queries, the SOA cannot recover since the NPAC, for any time range, will respond with an error for maximum TN query reached.	High	FRS, IIS, GDMO	Func Backwards Compatible:  NO

June LNPAWG (San Ramon), discussed in conjunction with NANC 279.  Group decided to close out 279, and merge the requested functionality into this change order, since this is query functionality issue, and not just a recovery issue.

Jim Rooks will provide additional information on a proposed solution given the inclusion of NANC 279 into this change order.

Jim’s response is shown below:

This change order requests the 'more' capability that will be supported by queries in the LTI.  This implementation requires 2 changes.

#1, the NPAC must be modified to always return the first n (tunable) records on the SV query.  Currently, the NPAC determines that the query will return more than n records and returns an error.

(continued)	Low	Med-High / Med-High	
NANC 285 (con’t)	continued				#2, the service providers should modify their systems to support the following SV query operations to the NPAC:
a.	When data is returned from an SV Query and there are exactly n (tunable) records returned, the SP must assume that they didn't get all the data from their query.
b.	After processing the first n records, they should send a new query that picks up where the data from the prior query ended.
c.	The SV data returned from the NPAC for SV queries will be sorted by TN and then by SVID so a filter can be created to pick up where the prior query ended.
d.	For example, if a SOA query to the NPAC returns exactly 150 records and the last SV returned was TN '303-555-0150' with SVID of 1234.  The filter used on the next query would be:
All SVs where ((TN > 303-555-0150) OR (TN = 303-555-0150 AND SVID > 1234).
The NPAC does support OR filters.
e.	Once the results from the NPAC returns less than 150 records, the SP can assume they received all records in the requested query.

Refer to R4 Change Orders for current proposed resolution.			
NANC 287	AT&T
5/27/99	ASN.1 Change for required field in VersionNewNPA-NXX and VersionNewNPA-NXX-Recovery notification
The current ASN.1 has incorrect field definition.  The requested change is to make the service-prov-npa-nxx-value of the VersionNewNPA-NXX notification and VersionNewNPA-NXX-Recovery notification a required field instead of  'optional'.

Current asn.1:
VersionNewNPA-NXX ::= SEQUENCE {
    service-prov-npa-nxx-id NPA-NXX-ID,
    service-prov-npa-nxx-value NPA-NXX OPTIONAL,
    service-prov-npa-nxx-effective-time-stamp GeneralizedTime,
    service-prov-id ServiceProvId,
    access-control LnpAccessControl
}

Proposed:
VersionNewNPA-NXX ::= SEQUENCE {
    service-prov-npa-nxx-id NPA-NXX-ID,
    service-prov-npa-nxx-value NPA-NXX,
    service-prov-npa-nxx-effective-time-stamp GeneralizedTime,
    service-prov-id ServiceProvId,
    access-control LnpAccessControl
}

Current asn.1:
VersionNewNPA-NXX-Recovery ::= SEQUENCE {
    service-prov-npa-nxx-id NPA-NXX-ID,
    service-prov-npa-nxx-value NPA-NXX OPTIONAL,
    service-prov-npa-nxx-effective-time-stamp GeneralizedTime,
    service-prov-id ServiceProvId
}

Proposed:
VersionNewNPA-NXX-Recovery ::= SEQUENCE {
    service-prov-npa-nxx-id NPA-NXX-ID,
    service-prov-npa-nxx-value NPA-NXX,
    service-prov-npa-nxx-effective-time-stamp GeneralizedTime,
    service-prov-id ServiceProvId
}	Med	ASN.1	Pure Backwards Compatible:  NO
Func Backwards Compatible:  YES

June LNPAWG (San Ramon), this also applies to the recovery notification (in addition to the first port notification that is listed in the change order).  Update to add recovery notification and review next month.

Jul LNPAWG (Ottawa), it was noted that this is not considered backwards compatible, since it requires a recompile.  Move to accepted category.

Refer to R4 Change Orders for current proposed resolution.	Low	Low / Low	
NANC 291	Bell Atlantic/ Sprint 7/7/99	SSN Edits in the NPAC SMS
The NPAC SMS should edit and prevent a new Service Provider CREATE message from specifying final Global Title Translations for CLASS, LIDB, CNAM, ISVM MWI, and WSMSC.

Description of Issue:
There have been instances when the new Service Provider, upon sending the new SP CREATE message to NPAC, has provided final Global Title Translation data for the Destination Point Codes and Subsystem Numbers for CLASS, LIDB, CNAM, and/or ISVM MWI.  This final GTT data is broadcasted by NPAC to all applicable subtending service providers in the Region.  This has resulted in TCAP routing errors for subtending service providers who do not have route sets built based on final GTT to the new SP.	High	FRS,GDMO	Pure Backwards Compatible:  YES

Proposed Change Order:
Implement an edit in NPAC that will reject a new SP CREATE message if the message contains a Destination Point Code with a non-zero (000) Subsystem Number for CLASS, LIDB, CNAM, ISVM MWI, or Wireless Short Message Service.  This edit shall be settable (active or inactive) on a Regional NPAC basis.  It shall apply to all DPCs associated with ported and pooled DNs.  For 1K block pooling, the NPAC SMS will reject creation of block data containing a non-zero Subsystem Number, whether by NPAC personnel or via the new SP's SOA, if the edit is active.

Jul LNPAWG (Ottawa), lots of discussion.  Some SPs using final, but not sure how much of a problem this is creating.  In all cases discussed, led to new SP changing SSN to gateway value instead of final value.

Homework for all SPs for next month.  Figure out requirement to broadcast final GTT instead of gateway, and willingness to change this approach.  SPs will need to substitute final in their own network.  SPs should understand that if no arrangement is set up between the providers, then routing errors (to the new SP’s customer) will occur.  This affect creates, modifies, and mass updates.	Low	N/A / N/A	
NANC 291 (con’t)	continued				Aug LNPAWG (Portland), since the conference bridge was not available at the time this was discussed, the group agreed to postpone the discussion until September (assuming a conference bridge was available at that point in time).

Sep LNPAWG (Chicago), much discussion.   A vote 10 (for) to 1 (against) was taken to move this change order into the accepted category.

Refer to R4 Change Orders for current proposed resolution.			
NANC 294	LNPA WG 8/11/99	Changing Due Date Edit Functionality in the NPAC SMS for 7p on Due Date Problems
Service Providers involved in last minute emergency porting situations, cannot create/concur/activate SVs that are created after 7p (eastern standard time) on the due date.  Since those created after 7p EST, equate to after midnight GMT the next day on the NPAC SMS, the old SP cannot concur to the port, and the new SP cannot activate at this point in time since timers have not expired.

Sep LNPAWG (Chicago), after much discussion the group agreed that this problem exists for initial creates as well as concurs, if either one happens after 7p EST.

Option #1 from Portland is a huge effort, and does not resolve the issue (it just narrows the window).  Option #2 from Portland was deemed to be the best solution at this point.  However, the back-dating needs to be limited to ensure this functionality does not open the window for “pamming” (port slamming) 

Oct LNPAWG (KC), the back-dating capability allows the SP (local side thinks it’s still the current date) to send a previous day’s date, even though the NPAC has already rolled to the next day.

This back-dating still allows an SP to send up yesterday’s date with zeros in the time portion.  This will accommodate SPs that always sends all zeros in SV create messages (even though this would be more than the 4-10 hour back-dating range).	High	FRS, IIS, GDMO	Pure Backwards Compatible:  YES

Aug LNPAWG (Portland), the group talked about two options: 1.) change the NPAC SMS to run and store in central time; 2.) change the NPAC SMS edit to allow a concurrence in the past (i.e., back-dated concurrence).  It was noted that the first option still has a problem with ports in the western region, west coast region, and hawaii, albeit the problem window is smaller.  This will be discussed in more detail next month.

Sep LNPAWG (Chicago), using option #2, a new tunable (“Back-Dating Due Date Differential”) per region would only open the window for back-dating to the largest differential time zone in that region from the NPAC (i.e., from a map perspective, the left most time zone [“prevailing time zone”] in that specific region).  The time zone would be adjusted for standard/daylight, and the tunable would have a valid range of 4-10 hours (4 hours is EDT, 10 hours is Hawaiian standard time).

Oct LNPAWG (KC), the desired functionality may require two tunables per region (to account for both standard time and daylight time).	Med	N/A / N/A	
NANC 297	Sprint 9/15/99	Sending SV Problem During Recovery
If an LSMS is down during the broadcast, and the NPAC SMS has sent out the final retry, the LSMS will not be able to recover this broadcast (either in recovery or once recovery is complete and normal processing continues).

It was discussed that the way to ensure the recovering LSMS gets the sending SVs, is to include any of these SVs.  By including these, along with the appropriate download reason; the LSMS would be able to recover sending SVs.

New Requirements:

NPAC SMS shall include Subscription Versions with a status of sending, at the time subscription data recovery is requested by the LSMS.

NPAC SMS shall remove a Service Provider from the Failed SP List of a Subscription Version with a status of sending, even if there are additional retry attempts, at the time subscription data recovery is requested by the LSMS of that Service Provider.	High	FRS, GDMO	Pure Backwards Compatible:  YES

Sep LNPAWG (Chicago), need to add priority during Oct meeting in KC.

Oct LNPAWG (KC), could have a problem if the SV is sent twice (once for the recovery, and once at the next retry attempt), so the group wants the failed list updated for the recovering SP.

Refer to R4 Change Orders for current proposed resolution.	Med-Low	N/A / N/A	

LTI Change Orders
LTI Change Orders	
Chg Order #	Orig. / Date	Description	Priority	Category	Proposed Resolution	Level of Effort	
						NPAC	SOA LSMS	

								

Cancel – Pending Change Orders
Cancel - Pending Change Orders	
Chg Order #	Orig. / Date	Description	Priority	Category	Proposed Resolution	Level of Effort	
						NPAC	SOA LSMS	

								

								

Current Release Change Orders
Current Release Change Orders	
Chg Order #	Orig. / Date	Description	Priority	Category	Proposed Resolution	Level of Effort	
						NPAC	SOA LSMS	
		See Implemented List for details on Release 3.						

MR Change Orders
MR Change Orders	
Chg Order #	Orig. / Date	Description	Priority	Category	Proposed Resolution	Level of Effort	
						NPAC	SOA LSMS	

Summary of Change Orders

Release # / Target Date	Change Orders	Backwards Compatible	
Open	NANC 147 – Version ID rollover strategy
		
Accepted	ILL 5 – Round Robin LSMS
NANC 151 – TN and Number Pool Block addition to notifications
NANC 169 – Delta Download File Creation by Time Range for SVs
NANC 193 – TN Processing during NPAC SMS NPA Split Processing
NANC 246 – NPA-NXX Filters for Bulk Data Download Files of SVs
NANC 299 – NPAC Monitoring of SOA and LSMS Associations via Heartbeat
NANC 300 – Resend Exclusion for Number Pooling
NANC 311 – Query Message of SP Association Status
NANC 312 – Different User Levels on the LTI
NANC 316 – Change the NSAP Field Size Declaration in ASN.1 – ASN.1 Recompile
NANC 319 – NPAC Edit to Ensure NPA-NXX of LRN is in Same LATA as NPA-NXX of Ported TN
NANC 321 – NPAC Edit of Service Provider Network Data – NPA-NXX Data
NANC 322 – Clean Up of Failed SP List based on Service Provider BDD Response File
NANC 323 – Mass Update of SPID (Partial)
NANC 328 – Tunable for Long and Short Business Days
		
Next Documentation Release
	NANC 305 – R3 ASN.1 documentation-only updates
NANC 324 – IIS Document Only Change – Flow B.5.4.7.3: Subscription Version Disconnect With Effective
                      Release Date
NANC 325 – GDMO Document Only Change – 4.0 LNP Subscription Version Cancel Action
NANC 326 – IIS Document Only Change – Flow B.5.6: Subscription Version Query
NANC 327 – FRS Document Only Change – Update Appendix C – System Tunables
		
Release 4.0
	ILL 130 – Application Level Errors (ASN.1 impact)
NANC 138 – Definition of Cause Code Values-REVISITED
NANC 179 – TN Range Notifications
NANC 187 – Linked Action Replies
NANC 191 – DPC/SSN Value Edits
NANC 192 – NPA Split NPAC SMS Load File
NANC 200 – Notification of NPA Split
NANC 217 – Mass Update of SPID
NANC 218 – Conflict Timestamp Broadcast to SOA
NANC 219 – NPAC Monitoring of SOA/LSMS Associations
NANC 227 – 10-digit TN Filters (previously know as:  “Ability to Modify/Delete of Partial Failure SV”)
NANC 230 – Allow a Donor SOA to Create a Port-to-Original on an intra-service provider port
NANC 232 – Web Site for first port notifications
NANC 240 – No cancellation of SVs based on expiration of T2 timer
NANC 249 – Modification of Dates for Disconnect Pending SV
NANC 254 – NPAC Requirements – Subsequent Ports of Active SV with a Failed SP List
NANC 285 – SOA Requested Subscription Version Query Max Size
NANC 287 – ASN.1 Change for required field in VersionNewNPA-NXX and
                      VersionNewNPA-NXX-Recovery notification
NANC 291 – SSN Edits in the NPAC SMS
NANC 294 – Changing Due Date Edit Functionality in the NPAC SMS for 7p on Due Date Problems
NANC 297 – Sending SV Problem During Recovery
		
LTI
			
Cancel-Pending
			
Current Release
	See Implemented List for details on R3
		
MR