No changes were made.

The WNPSC approved the mission and scope for the Wireless Operations Team. The Wireless Operations Team will hold their kick of meeting in La Jolla CA (San Diego) on February 15^th. All carriers are requested to bring their busy hour / busy day data to the kickoff meeting.

The WNPSC reviewed presentations for the CTIA Critical Issues Forum on wireless number portability.

The earliest inter-SP wireless number portability testing can start is October 2001. Inter-SP testing will follow wireless service provider turn-up testing with the NPAC.

The Slow Horse subcommittee did not meet in January. The following slow horse discussions were part of the LNPA meeting.

The Canadian Consortium has established an LSMS % Availability requirement effective shortly, with data collected manually until NANC 219 is implemented with Release 4.0 to automatically collect and report such data. The LSMS availability requirement is 99%, on a rolling three-month average and at least 90% availability in any given month. If a service provider fails to meet this LSMS availability level, the SP will be required to prepare a report to the Canadian Consortium explaining the failure.

The SOA/NPAC traffic data report we had requested has been offered by Neustar in the form of SOW 27 and will be considered at the LLC meeting later this month.

When it was reported that the LLC had not received the monthly slow horse report (mid-November to mid-December), Neustar explained that they had sent it out December 22^nd, but apparently it was not delivered; Gene Johnston will re-send it to the PEs. Expectation is that we will have received the second month's report, for mid-December through mid-January, in time to discuss the Slow Horse results at next month's LNPA-WG meeting.

SBC presented brief paper on LSMS performance testing. The thrust of SBC's paper was that it should not be necessary to do LSMS performance certification testing, but they have no objection to having an LSMS performance requirement. Written positions on LSMS and SOA requirements matters again were requested for eventual discussion at Slow Horse subcommittee.

PIM-1: Porting with Resellers. OBF is still working on reseller process flows.

PIM-5: Unilateral Back-out of Inadvertent Port.

One carrier related three recent anecdotes of situations where an inadvertent port needed to be backed out. These included inadvertent porting of a hospital, a poison control line, and a doctor where the porting provider could not be contacted.

Further discussion revealed that the case of the doctor was not a port in error. It was a case of a customer who ported to a company who subsequently went out of business, terminated his service, and stranded his TN. The PIM-5 process was not intended for this type of scenario, although there is nothing in the process as currently defined to prevent it from being used for this type of situation.

Another carrier sited examples of carriers whose published contact numbers were not working. Service Providers are contractually required to maintain contact numbers with Neustar, but some providers have not been complying with this. Neustar has had several cases where they can not contact a carrier because the contact information on file is not valid.

Neustar’s concern with this request is that their contract states that they are not allowed to be involved in this type of activity. They believe this would require a change to the master agreement. The service providers pointed out that an SOW approved by the LLC is a change to the master agreement, so this objection should not be a concern. Neustar stated that they still have other concerns.

Few carriers were able to comment on the frequency that situations described in PIM-5 occur. One of the RBOCs stated they encountered these situations approximately once a month. The LNPA agreed to review this again internally, and discuss again next month.

PIM-6: End User Move Indicator (EUMI)

The LNPA agreed that the EUMI should be a mandatory field on the LSR so Old SPs would know that they should do a delete and insert rather than an unlock and migrate. OBF has not come to agreement on this request. Most providers at OBF favor requiring either a Yes or No in the EUMI field, but some carriers would prefer a blank EUMI field default to No and orders with a Yes entry required when applicable.

The only change in the wireless test plan since it was reviewed at the Banff LNPA meeting (Oct 2000) is the addition of a fixed document date. (Previously the date was updated by MS Word each time the document was viewed or printed.) The wireless members would like us to post the test plan on the LNPA website. The LNPA members stated that they do not think that LNPA needs to sanction or approve the test plan, but LNPA agrees that the test plan should be posted on the Neustar website in the LNPA documents section under WNPSC documents.

One of the CLEC SPs asked why a wireline company who is currently porting with other wireline carriers would want to test? The following reasons were cited:

The working group accepted the updated calculation of service provider maintenance window that was distributed in the revised NANC 219 change order.

How the service provider maintenance window is accounted for in the SP availability calculation was clarified: The NANC 219 change order creates a screen for the NPAC administrator to enter the date and time of the start and end of each industry-agreed service providers’ maintenance window. Association, or lack of association during the maintenance window counts neither for the time an SP’s LSMS is available in the numerator of the calculation, nor in the total availability in the denominator. (Service provider maintenance outside of the industry agreed window, whether planned or not, will be deducted from the service provider’s time available in the numerator, but will not be deducted from the total available time in the denominator. Service provider % availability will be reduced by downtime outside of the industry-agreed window.)

Clarifications were requested on how the current requirement as written will treat:

The requirements will be modified to make this more clear.

The working group agreed to modify how SP availability is treated after NPAC downtime. A ten-minute window for service providers to rebind will be added after the NPAC comes back up. This is because a finite period of time is needed for local systems to rebind.

A suggestion that a ten-minute period should also be added after the scheduled maintenance window was rejected because it is understood that the time needed to rebind is part of the maintenance window. The NPAC maintenance window is shorter than the SP maintenance window, and service providers are expected to bring their systems up and complete their rebind prior to the end of the maintenance window. None of the SPs at the meeting objected to this approach.

One of the SPs pointed out that in the Northeast region NPAC, there are approximately 100 NPA-NXXs that are incorrectly open in the region. There was general consensus that there is clearly a business need for this change order.

The Canadian region does not need this edit. We decided to make the change order optional by region so the Canadian region will not have to pay for this development.

The first line in the description of change was expanded to reflect that network data can be entered in multiple ways: over a SOA, over an LSMS, over LTI, or through the NPAC administrative GUI.

The error messages as currently described in the change order will require application level error messages and greatly increase the complexity of the change order. The working group simplified the change order details to be compatible with standard CMIP error messages. As an example, requirement 4 requested that when an SP attempts to enter network data for an NPA-NXX for which data already exists, the error message will indicate the SP who has previously entered data for this NXX. The standard CMIP error message is "duplicate object error". See revised change order for details of the simplified requirements.

The title of this change order was changed from "NPAC Edit of Service Provider Network Data" to "Regional NPAC NPA Edit of Service Provider Network Data - NPA-NXX data".

NANC 321 was accepted by the LNPA

This change order was accepted by the LNPA.

The NPAC will access the BDD response file from the SVs FTP site. The clean up file will be generated both from a delta download file and from a full bulk data download. LNPA discussed whether special security is needed at the FTP sites.

There is a need to identify the timestamp of Bulk Data Download files used by SPs to update their networks so that any failed SVs which failed after the BDD file was created are not removed from the failed list.

NANC 246, NPA-NXX Filters for Bulk Data Download Files of SVs, is now a separate change order rather than part of NANC 169, Delta Download File Creation by Time Range for SVs.

The group decided that the make up of release 5.0 needs to be totally reassessed. Therefore, we will consider all change orders that were part of the release 5.0 to be simply "accepted change orders". The weighted averages will be removed from the documentation.

The NPAC performance requirement currently used for performance testing is a very simple model chosen before we had any production data. The LLC will be meeting with Neustar and additional technical representatives in Jan 23 and 24^th in Washington DC. This is an LLC meeting, so concerns should be channeled through your LLC representative. Sample statistics describing the current production traffic will be e-mailed ahead of the meeting to the LLC reps.

The agenda is

This discussion is an LLC activity because exhibit N is part of the contract between the LLC and Neustar. The plan is to develop actual revised requirements by June of 2001.

All of the Northeast service providers have completed group testing. The next round of group testing for the super region carriers is scheduled to begin Monday March 16^th.

Neustar is discussing with the LLC how long the platform must be stable before it can be migrated to production. Currently the LLCs are looking for 3 or 4 weeks of running without the system going down, patches, or other modifications.

The test platform has been up & down since the 3.0.1.1 load due to replication issues, performance issues, v-back issues. Until this meeting the service providers represented at LNPA believed that replication was turned on the week of December 18^th. Neustar stated that replication was not turned on until Friday 12/29. This means replication was not turned on during the 12/18 to 12/22 group testing period.