Wireless Operations Team:

See separate Wireless Ops minutes for technical discussion details. 

Jim Grasser reiterated that the Wireless Ops team would like to continue to hold their meetings on the Monday afternoon and Tuesday morning preceding LNPA and at the same facilities as the LNPA.  The LNPA agreed that if we will be hosting the Wireless Ops meetings, the wireless companies should host some of the future meetings. 

Slow Horse Subcommittee:

The LLC rejected the SOW for release 4.0, the SOW for SOA reports, and Testing Services.

Problem / Issues Management (PIMs):

PIM-10:   Inter-Carrier Billing Problems on Calls to Ported Numbers

US LEC has been assigning an LRN per rate center because other carriers are basing end user billing on the LRN rather than dialed digits.  The PIM was submitted because CLECs can not get native codes in each rate center in areas that are subject to number pooling. 

Time Warner seconded US LEC’s problem description.  They have also been experiencing other companies, including inter-exchange carriers, charging for calls to the Time Warner customer after they have ported when no charge is justified.  (i.e. there was no charge prior to porting.)

All providers at LNPA agreed that companies only need to assign one LRN per switch per LATA.  Billing must be rated on dialed digits, not on the LRN.    US LEC said they have experienced the problem with multiple carriers, usually only in specific cities.  US LEC described the symptom of the billing problem as:  “Prior to porting the ILEC customer can 7-digit dial the number, after porting the ILEC customers must dial 8 or 11 digits.”   LNPA members felt that this is even a bigger problem than the billing problem. 

LNPA will address this issue by having US LEC (or any other provider) provide detailed descriptions of these incidences to the LNPA representative for the offending carrier.  The LNPA carrier will work internally to find out why the problem is occurring and address the root cause.  Time Warner will also contact the individual carrier rep’s with information on the problems they have identified. 

PIM-9:  Inter-Carrier Trouble Reporting

LNPA plans to forward this issue to NIIF.  The next NIIF meeting is April 30^th, 2001.

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

NANC reviewed this PIM and directed LNPA to look at it again with special focus on the issue of emergency services outages and the requirement for 7x24 support.  They asked to have the 7x24 requirement incorporated into the PIM.  LNPA discussed whether there is an industry requirement for 7x24 support.  Neustar said that there is a requirement for providers to give NPAC a 7 x 24 contact, but NPAC has no enforcement authority to follow up if the support is not maintained, or is referred to personnel without the ability to correct problems. 

Verizon stated that they support mandatory 7x24 contact requirement, but that does not eliminate the need for the PIM 5 emergency port capability, since there will always be cases of inability to reach the 7x24 contact.

NIIF 134 requires 7x24 support for network trouble, but there is disagreement over whether this includes inadvertent porting.  NANC asked that LNPA determine how NIIF 134 should be incorporated into the solution. The NIIF requirement states that the carrier’s 7x24 contact must be LNP trained and qualified.  But it was noted that this might not necessarily mean that the person has the authority or ability to port numbers.  Some members feel that the NIIF contact list is not adequate because it requires a password to access.  LNPA discussed what capability the “LNP capable technician”, referred to in NIIF 134 must be to satisfy the intent of PIM 5.  The discussion centered on having the “ability and authority” to concur to an emergency port. 

It was asked “how are these numbers accidentally getting ported?,  Doesn’t the NPAC notify the Old SP that these numbers are about to be ported?”  The answer is:  “The NPAC does provide that functionality but some service provider’s systems automatically concur to all requests.  Sometimes the old SP is backed up and can not follow up on all port notifications within the allotted 9 hrs, sometimes the new SP fat fingers the SV and the old SP concurs, and sometimes the number in question is accidentally ported as part of a range.”    

Neustar stated that they still do not think the best way to address this problem is with a unilateral port process, but that if their customer demands it, they will provide a statement of work.  LNPA requested that Neustar describe alternatives if they do not wish to do this.  Neustar stated that they would be willing to maintain and provide contact information. 

Charles Ryburn will write a letter to NIIF requesting clarification of the “LNP capable technician” wording in NIIF 134, and share that letter with NANC.  Steve Addicks will prepare a description of the “inadvertent failure to port” scenario and forward it to Charles who will send to Neustar. 

PIM-1:   Porting with Resellers. 

Still being worked by NNPO.

PIM-6:   Modify 911 Record Migration Process  &  End User Move Indicator (EUMI)  

NENA and OBF met by conference call and discussed why the mandatory EUMI is required.  NENA expects OBFs response in the near future. 

Wednesday March 14,  8:30 – 5:00pm

Change Orders:    9:30 – Noon; 1:00-4:00    

NANC 217:  Complete Migration of One SPID to Another SPID

We discussed the need to update the SPID on pending orders in companies internal OSSs at the same time as the NPAC/SOAs/LSMSs are updated.  It was mentioned that work in internal OSSs is out of the scope of the LNPA.  The need for internal systems updates means we will need a formalized carrier notification process that specifies how much notice carriers need prior to a SPID change.  The migration must happen during a quiet period. 

One representative suggested we could build a process similar to NPA splits where there is a period of permissive SPID use where both the old and new SPIDs can be used.  There was a recommendation to modify the SOAs so that from time a SPID change is announced until the Date of Migration, users can use either the new or old SPID but after the effective date only the new SPID could be used.  Prior to the migration date the SOAs would send old SPID, after they will send the new SPID. 

Another representative asked if we have considered having the NPAC manage the permissive use of both SPIDs prior to the effective period. 

Carriers, who are changing a SPID in multiple NPAC regions, probably will want to change the SPID in one region at a time, and there might be significant periods where one SPID is being used in one region and another in other regions.  This may cause confusion for multi NPAC region service providers.

Consensus:  We need to allow SPID migration to occur region by region. 

Action Item – Service providers need to evaluate what internal systems this process impacts and how much time for notification they need for a SPID change.

Action Item – Service providers need to evaluate whether there are internal operational advantages that justify limiting this process to a simultaneous update of the SPID in all regions, or whether we wish to allow changes to be implemented on a region by region basis. 

Neustar will need to set up a procedure and forms for requesting a SPID change.  They have proposed 3-6 month prior to notification of other SPs as a reasonable notification timeframe. 

The current plan is for LTI users to manage the permissive period manually rather than implementing a mediation role into the LTI platform.  Phrased alternately: while SOA developers have the option of creating a system that allows user entry of the new SPID during the “permissive” period and having the SOA determine whether new or old should be sent over the interface, LTI users would have to continue to use the old SV until the cut date, and use new SPID thereafter.   

We reviewed the contributions of the service providers on this process that were e-mailed to the distribution list prior to the meeting.  Only a proposal for managing the migration over the interface generated significant discussion. 

One service provider proposed a process for changing SPIDs that is managed by the NPAC through broadcast activity rather than requiring manual processes by each service providers.  It was stated that we had previously considered this, but that it was rejected as technically infeasible.  One of the technical issues is that the association between SPID and NPA-NXX cannot be changed when there are active SVs using that NPA-NXX.  A second problem is that the database will not allow modification of a primary key over the interface, and SPID is a primary key.  People were also concerned about the interface traffic volume this approach will require.  This proposal was rejected due to technical unfeasibility.    

LNPA agrees that after an old SPID is migrated to a new SPID, the NPAC will no longer accept transactions using the old SPID.  We discussed how long a deleted SPID must be aged before it can be reassigned.  A specific period will be required because the NPAC archives transactions using the old SPID.  Currently there are no requirements for purging these archives so we recommend not reassigning SPIDs. 

Some service providers indicated that they thought 3 months was too long for the total process.  (Notification to SPID change.)  LNPA discussed whether there is a business need to perform a SPID change on an expedited basis.    Verizon noted that in some states they have a regulatory mandate to be the carrier of last resort and provide service for customers who’s provider goes out of business.  Even in these cases Verizon does not see a need for an expedited SPID change process. 

After discussing Neustar’s proposal to require 3-6 months notice before they inform the industry of a SPID migration, the LNPA decided that this time does not need to be defined until we are closer to implementation.  Note:  this is the time between an SP notifying the NPAC, but before Neustar notifies the industry.  

We also discussed whether there needs to be a process and window for backing out a SPID migrate. 

End of Change Order Discussion:  

SOW Process Discussion:  

David Heath said that Neustar is working on a lessons learned document from the 3.0 release experience. 

The NAPM has requested a reconsideration of the process used for NPAC change management.  One of the NAPM members suggested that the current process for requirements and SOW development should be changed.  Based on the maturity of the product and our NPAC vendor, this process could be moved toward a model where the industry develops a business need and the vendor (Neustar), develops software and markets it to the LLCs. 

Two service providers stated that they do not think the LNPA change management and requirements development processes is flawed.  Several players, including Neustar stated that the communication between Neustar and the LLC need to be improved.  Neustar believes that they need to do a better job of communicating the cost drivers to the LLC. 

One provider, who believes the NPAC change process is broken, said that he believes the end users needs are not being met in an expeditious manner. 

It was pointed out that the LNPA process tends to develop requirements for Cadillac features, when we can only afford Chevy prices.  There was general agreement that the LNPA does not have good grasp on the cost of the change orders they develop, and that the LLC may not always have a good grasp on the business need.  There is also concern that the cost feedback doesn’t come until long after the requirements have been set.  But one of the reasons for this is that cost can not be allocated on a requirement by requirement basis.  Due to the nature of development serendipity, $ for rqmt A + $ for rqmt B ¹ $ for (rqmt A + rqmt B)  

Several LNPA members feel that the root cause of the problem is that the requirements developments process is divorced from the cost discussion.  However the LLC members reiterated that it is not appropriate to discuss cost in the LNPA because it is a public forum.  If the process focused entirely on NPAC costs, it would not necessarily have a lower overall implementation cost for service providers, because often NPAC cost can be minimized by pushing the functionality onto the local systems.   One reason we do not discuss costs at LNPA is to prevent collusion between vendors.  (We have multiple SOA vendors)

Thursday  March 15,  8:30 – 12:00 pm

New Business:      

Proposal To Use EDR Functionality to Move Blocks Between Switches within the Same Service Provider within the same Rate Center:  Jim Alton requested comments on a proposal to create a process for moving 1k blocks of numbers between switches in the same rate center within the same company. 

Need For New Co-Chairs and Minutes Taker:  Nominations are needed for all three LNPA co-chairs at the April meeting.  Steve Addicks, CLEC co-chair, will be moving on to new responsibilities and no longer able to attend LNPA.  Brian Egbert, the wireless co-chair, will be leaving LNPA after May 2001, and Charles Ryburn will be stepping down as ILEC co-chair after June. 

With Jim Alton leaving, a new minutes taker is needed.  Maggie Lee will be able to take notes in April and May[TJA1] . 

NPAC 3.0 Readout:          

Rob Coffman provided information for an conference call on Sunday March 18^th at noon central time to make a go/no go decision on NPAC 3.0: 

Next Meetings … April 10 - 12 

Verizon, Portland, Maine

2001 meeting schedule:  

LNPA WG:                                Host:                                                    NANC Meetings:

May 15 – 17                              Bell South, Atlanta                                 May 22 - 23

June 12 – 14                              Sprint, Kansas City                                June 19 - 20

July 10 – 12                               Canadian Consortium, Ottawa

August 14 - 16                           AT&T, Seattle

September 11 - 13                     Verizon, Baltimore                                

October 9 – 11                           SBC, San Antonio

November 13 - 15                       Neustar, New Orleans

December 11 – 13                      Qwest, Phoenix