Operations Memo

11/12/96




Team, attached are 3 memos for your review prior to our meeting next week.

  1. Memo from NPAC/SMS team concerning NPA splits.

  1. Memo from Brian Baldwin (Switch Requirements Team) with a suggestion for a standard methodology for assigning LRN's.

3 Proposed text for the Cancellation Process Flow from Ed Elkin (AT&T)

Please look over the attached documents prior to the Operation meeting and be prepared to discuss them.

Thanks

Barry




























Attached is an explanation of how NPA splits will be handled in a

ported environment. This explanation is based on current design of the

NPAC SMS.

Any questions please give me a call.

Donna

---------------------------------- Forwarded ----------------------------------

From: Donna_Navickas________________ <>

Subject: Fw: NPA-NXX split rewrite

I had a small typo that could cause great confusion that I am correcting

below.

The words changed are underscored with ^^^^.

Lisa Marie

----------

>

> Subject: NPA-NXX split rewrite

> Date: Wednesday, November 06, 1996 1:13 PM

>

> The following is a rewrite of the NPA-NXX split processing based on all

the e-mail that has been exchanged. I know that things were starting to

get a little hard to follow! This write up will be included in the M&P

document with a little clean up).

>

> Lisa Marie

>

> NPA-NXX Split Processing

> --------------------------------------

>

For an impending NPA Split, there is no communication between each SOA and

the NPAC via an electronic interface (SOA, LSMS, or NPAC OpGUI) other than

providing the NPAC with the new network data (LRNs and NPA-NXXs), if

applicable.

>

The NPAC inputs via the OP GUI the information for the NPAC split (the

current NPA, the new NPA, and the effected NXXs) plus the permissive

dialing period beginning and end. This function of the OP GUI is only

available to the NPAC Operations personnel. A process will be documented

in the M&P document that will define how the NPAC is notified of an

impending split.

This process should be similar to how the Service Providers are notified

of a split today. Note, split information input will not be allowed if

there are any partially failed or sending subscription versions.

>

The NPAC modifies all of the subscription versions associated with the

split to associate the new TN with the subscription Version to support the

permissive dialing period. No updates or information is sent over the SOA

interface or LSMS interface to indicate that a split is occurring.

>

During the permissive dialing the NPAC will accept messages with either

old or new NPA but broadcasts/downloads with the new NPA only. If a delete

request is received it is broadcast with the new NPA. The subscription

version id that the NPAC SMS knows about for the TN is used in the

messages. (Note that the subscription version id does not change during

a split.)

>

The NPAC will update its subscription version records when permissive

dialing ends to the new NPA. Existing records will be modified so that

the new NPA

^^^^^is now the old NPA and the field that held the new NPA during the

^^^^permissive dialing period is deleted. There are no

old or new versions created. An NPA split causes a shift of the data, not

creation of a new entity. By definition, we are changing identity

information for the TN when we change the NPA. This type of a change would

require use of the version ID to find the TN and should not be a problem

because the NPAC uses the version ID, not the TN to track subscriptions

relative to logs and audit data. It is incumbent on the LSMS's to

recognize that a request for data that is log related may show TN

information that was in effect when the log entry was made (If it was

copied into the log most entries are made by reference to subscription

version ID so this should not be a problem). Bottom line is that we are

performing a modification when we do an NPA split that is a special case

because:

>

> 1) it is a change to what users consider identity information

> 2) the modification occurs over the permissive dialing period

> 3) we recognize both identifiers during the permissive period

> 4) We recognize only the new NPA "shortly" after the end of

> the permissive period (on the day after the end date, we

> perform the operation soon after midnight GMT time)

>

> Based on information from the LERG, the service providers will update

their networks/LSMS to accommodate the permissive dialing period and will

update the data in their networks/LSMS after permissive dialing ends.

There is no communication from the NPAC to cause these updates to occur.

No assumptions are made about what the LSMS does with during the

permissive period to track the NPA-NXX split for a subscription version.

After permissive dialing ends the service providers can remove any old

network data that is no longer valid due to the split(LRNs, NPA-NXXs), if

any via an electronic interface (SOA, LSMS, or NPAC OpGUI).












From: Brian Baldwin@ameritech.com

Subject:RE: NPA-NXX split rewrite

Folks:

I'd like to use this opportunity to propose a standard methodology

for assigning LRNs to ported numbers. Some parties have suggested

the assignment of different LRNs for a given (donor) switch, to

identify the terminating rate center. Although today we do assign

separate NXXs for each rate center served by a particular switch, in

the future this will probably not prevail. The current assignment

practices have resulted in premature NPA exhaust situations,

especially in Illinois, and many state PUCs, including the ICC, are

pressing the industry to implement some form of number pooling. As

such, in the future we can expect to see a limit of one NXX per

switch, unless/until all numbers within have been assigned. In

addition, Bellcore has now revised its GUBB proposal for location

portability, and no longer utilizes the last 4 digits of the LRN for

rate center identification.

With this in mind, to facilitate the adoption of a simple assignment

convention for LRNs, I propose that we use the lowest numerical NXX

value assigned to a particular (donor) switch, followed by all

zeroes. For example, if an office has 3 NXXs assigned, i.e.,

708-301, 708-249, 708-636, the LRN value would always be

708-249-0000. Although 1A ESS and 5 ESS switches have a specific

designation for each NXX (e.g., NOC 1, NOC 2, etc.,) Nortel and

Siemens do not. As such, I believe that the only method of adopting

a standard selection would be via numerical order. It must be

remembered that LRNs were only intended to identify the terminating

switch for routing purposes. Use of LRNs for any other purpose may

lead to major problems down the road. It should also be remembered

that the signaling format allows the LRN value to also be a working

(and ported!) number. Attempting to reserve certain numbers in each

switch for LRN assignment seems counter-productive.

Opinions?

- Brian












Barry,

As discussed, here is the Cancellation process flow text.

Thanks,

Ed Elkin

AT&T

(312) 230-2567

------------------------

1. The Cancellation of Service Order process is entered through

various processes:

a. The end-user contacts the Old or New Service Provider and requests

cancellation of their service order.

b. Provision Service process flow: Where the missing or inaccurate

information is from the New Service Provider, and the New Service

Provider fails to respond to NPAC's request for information within18

hours [tunable parameter].

c. Conflict Resolution process flow: Where the conflict remains

unresolved for 30 calendar days [tunable parameter] after the

Subscription Version has been placed in conflict status.

d. Conflict Resolution process flow: Where as a result of the

Conflict Resolution process (at tie-point D) the Old and New Service

Providers mutually agree to cancel the porting request.

e. Conflict Resolution process flow: If the New Service Provider

decides to cancel the porting request, it does not need concurrence

from the Old Service Provider, although the remainder of the

Cancellation process flow is followed (note: this is from the GFRS

section 2.4.5.2, and doesn't show up in the Illinois flows - do we

want to correct for it?).

2. End User contacted Old or New Service Provider?

The End User calls their Old or New Service Provider to cancel the

service order request for the porting of their telephone number. Only

the Old or New Service Provider can initiate this transaction, not

another Service Provider.

The contacted Service Provider gathers information necessary for

sending transactions to the other Service Provider providing

cancellation notification, and to NPAC's SMS requesting the

Subscription Version status be placed in cancel-pending.

3. Old Service Provider obtains End User authorization.

The Old Service Provider obtains authorization from the end user to

cancel the porting request.

4. Old Service Provider sends notification to New Service Provider

Via their inter-company interface, the Old Service Provider fills out

and sends the LSR Request form to the New Service Provider, indicating

that the porting request is to be canceled.

5. Old Service Provider cancels all orders and sends cancellation to

NPAC

The Old Service Provider, either having been contacted directly by the

End-User or else notified by the New Service Provider via their

inter-company interface, sends a cancellation message to NPAC via the

SMS interface.

NPAC sets the Subscription Version status to cancel-pending. Both the

Old and New Service Providers are notified of this change in status by

NPAC via the SMS interface.

6. New Service Provider sends request form to Old Service Provider

noting cancellation.

The End-User contacts their New Service Provider and asks that their

service request be canceled. Via their inter-company interface, the

New Service Provider fills out and sends the LSR Request form to the

Old Service Provider, indicating that the porting request is to be

canceled.

7. New Service Provider sends notification of cancellation to NPAC.

The New Service Provider, either having been contacted directly by the

End-User or else notified by the Old Service Provider via their

inter-company interface, sends a cancellation message to NPAC via the

SMS interface.

NPAC sets the Subscription Version status to cancel-pending. Both the

Old and New Service Providers are notified of this change in status by

NPAC via the SMS interface.

8. Did NPAC receive both notifications in the designated time?

The NPAC applies an 18 hour [tunable parameter] time limit on

receiving Cancellation Orders from both Service Providers.

9. Yes. NPAC logs info and cancels transactions.

The porting request is canceled at this point by changing the

Subscription Version status to canceled. Both Service Providers are

notified of the cancellation via the SMS interface. If the customer

is to be ported, the porting process must be started from the

beginning of the Provision Service process flow.

10. No. NPAC notifies appropriate Service Provider that information

is missing.

The NPAC requests the missing information from the Service Provider

who has not yet provided the cancellation order via the SMS

interface.

11. Does NPAC receive information in the designated time?

NPAC sets the Subscription Version status to cancel-pending. Both the

Old and New Service Providers are notified of this change in status

via the SMS interface.

The NPAC applies an 18 hour [tunable parameter] time limit on

receiving Cancellation Orders from both Service Providers.

12. Yes. Is Response Positive?

NPAC checks to see if the response from the missing service provider

agrees with the cancellation request.

13. No. NPAC logs info, places transaction in "conflict status" and

notifies both service providers that conflict resolution is needed.

The Subscription Version status is set to conflict. The Old and New

Service Providers are notified of the change in status via the SMS

interface.

The Conflict Resolution process is entered at tie-point B.