Reviewed minutes from first National Billing Forum conference call. Purpose of group is to share information with each other in order to identify and find vendor solutions for LNP billing problems.

We will try not to go over where we have been in this forum - try to move forward. We will assume that team members have a good understanding of LNP. Those who have not been covered will seek assistance from others.

1. Issues must impact at least 2 traditional RBOC territories (7 RBOC and 1 Canada).

2. We should focus on Industry level concerns. There will always be unique situations in an individual state.

3. Our objective is to reach closure on issues including documenting requested switch vendor software changes (if required)

Items Discussed:

EMS ISSUE

LRN USE FOR RATING

LRN ASSIGNMENT

DELTA ITEMS 1, 4 AND 9

LRN FOR TAXING

These will be discussed as specific agenda items during the meeting.

Tom reviewed some basic LNP call flows to ensure that the group had a common understanding of LNP basics and terminology. The following California Call Flows were reviewed: Scenarios A, G, H, I, K and Q.

Scenario G:

If you return an AMASLPID, the LNP module would be attached to the 220/047 record. If you set up the trunks as CNAT, you could record a 625/720 record and that record would have a 720 module attached. CNAT records recording at the end office will not have a CIC code if it came in via a tandem. In a direct connect scenario, CIC could be present.

If donor switch is LNP capable but tandem is not and only way out of donor is MF, the call will not complete.

Scenario H:

CNAT records will get derived LNP modules.

Scenario I:

Call Code 721 is listed, but won’t be available in the first release. Check with your vendors to find out availability. CNAT can be turned on as long as trunk does not record FGD, 2A, 2B (which already produce a 625 structure code).

Scenario K:

Operator Handled Call. If billing number is portable, then a 10 digit global title translation is required, to route the LIDB query to the correct carrier. Lucent OSPS switches create different call codes than are listed here.

Scenario Q:

Out of Region Calling Card LIDB validation. Service Provider ID will not be available in operator handled AMA at this time. RAO will be correct if you have the line level RAO override capability loaded when LNP cuts. If the billing number is ported and not in your zone of portability, you will not get the billing LRN in the AMA message.

GTT lookup can be done at STP or SCP. Will STP have all North American Point Code information? GTT may be 6 digit level or 10 digit level. If it’s a distant area, the GTT translation will be done on a 6 digit level.

AREA OF PORTABILITY / WIRE CENTER VS. RATE CENTER Armen Basmajian

(Some of the following is excerpted from Armen’s handouts)

FCC decided to leave the decision on the area of portability to the state commissions. There is a wide variety of opinions regarding how far you can physically re-locate and keep your number (within a rate center).

Armen’s Rule: When a customer ports a number from the ILEC to a CLC, and the customer subsequently wants to move, the CLC must not allow the customer to move his ported number to a location that the ILEC would not have allowed.

Another opinion: We should be consistent, but not necessarily do things exactly like they are done today.

Even if customers don’t want to physically move at all, CLC’s MUST not serve multiple rate centers with one NPA/NXX.

Does the allowable area of portability as defined by Rate Center conform to the guideline in previous paragraph? Answer: Sometimes.

The Illinois operations committee then asked B&R to define Rate Center. Our initial definition was "Rate Centers are telephone company designated geographic locations assigned vertical and horizontal coordinates between which airline mileage is determined for rating and billing purposes".

The following words were added to the definition of rate center ... "Large rate centers (i.e. Chicago) may be further subdivided into Rate Districts. Where Rate Districts are assigned vertical and horizontal coordinates, they will be considered Rate Centers for number portability purposes". There are still issues with this definition. The Chicago Rate Center is not only broken into smaller Rate Districts with their own V&H coordinates, but smaller entities called Rate Zones.

Rate Centers with their V&H coordinates, and Rate Districts with their minor V&H coordinates, are clearly defined in the Terminating Point Master, and probably the LERG as well.

However Rate Zones are only identifiable by careful analysis of local tariffs. Therefor, in order to conform to the guidelines of porting, each CLC operating in a given MSA must be fully cognizant of Local tariffs as well as the easy stuff like Rate Centers and Districts.

Rules may differ by state, but in some cases, the major V&H is used and in others the minor V&H should be used. There may be other situations too.

Why is the above guideline (bold text) in place? Because Service Provider portability is not supposed to effect end user rating and billing. This means that the V&H calculation should be the same if you are calling within the rate center. How a company chooses to bill for that call is up to them. The above guideline applies to any LEC porting a number from any other LEC.

States have jurisdiction over consistent rate centers. If CLCs are allowed to create their own V&H for ported numbers, this could break another companies ability to rate calls for their customers calling the ported numbers.

What are the implications of the guidelines relative to the area of portability? Portability should not break ILEC local rating schemes. ILECs must incorporate CLC NXX’s into their local calling areas.

New service providers in an area must obtain NXX’s in each of the Rate Centers, Rate Zones, Rate Districts, in order to be able to retain their customers, whether gained via porting or new service. Note that this is a controversial issue!

If a LEC has many special rate districts, this could contribute to the number exhaust issue. For example, in Atlanta, there are 49 rate centers. 100 competitors will use up 4900 NPA/NXX’s or 49,000,000 numbers. In order to avoid the number exhaust issue, Location Portability functionality is required (either add rating NPA/NXX to the SCP or create a new rating variable, like GUBB).

Number exhaust is being looked at. Some suggestions are use the LRN solution to port 1000 banks of numbers to a CLC or to consolidate rate centers. The only codes that you can break up and assign by 1000 banks are new codes. Should more emphasis be put on Portability outside the rate center (Location Portability)?

There are local calling plans that depend on agreements between local exchange companies. The Texas region has identified Extended Metro Service as an example. Since the plan is NXX based and works because of LEC agreements, a LEC, end user, or both, may be disadvantaged should a CLC port an NXX of this type. As numbers port, this could impact the ILEC customers calling ported numbers.

There are areas where, for example, intra county calling is free by jurisdiction mandate. Special access and/or mutual compensation agreements may be needed between local service providers existing in and new to these areas.

LRN DISCUSSION: ASSIGNMENT/RATING/TAXING Sarathy Annamraju

In Canada, facility based local carriers are required to open one NPA/NXX per ILEC rate center. There may be some cases where assigning a code by toll rate center is fine. In others, lower level assignment may be required (e.g. rate district within a rate center). From a network point of view, they only need one LRN per switch per lata. That does not meet billing needs.

Will SPLNP be transparent to customers in terms of how they dial and pay? There may be a need to change from 7 to 10 digit dialing, but if this happens, it’s more likely to be a result of number exhaust issues, not LNP.

A "1" is used as a toll indicator today. SPLNP should not cause changes in when a "1" is required when dialing.

There’s confusion about whether or not SPLNP will allow portability across wire centers (within rate centers) or if customers are restricted to wire center boundaries.

With consistent rate centers, companies can continue to rate calls like they do today by looking up the V&H of the calling and called numbers. LRN as currently defined, cannot be used to do end user toll V&H type rating. LRN can be used to determine the wire center V&H for CABS access billing or wire-center based end user local calling plans.

Canada wants an LRN per CLC, per taxing jurisdiction, per rate center, per switch. They would like to be able to use LRN as key part of billing.

Terminology:

• "Location" Portability is only permitted within a Rate Center under SPLNP.
• A Rate Center consists of multiple wire centers, each wire center is assigned a V&H coordinate.
• A Rate Center is assigned a V&H coordinate of only one of its wire centers.
• Long distance calls cross rate centers.
• The distance of the Long Distance call is determined by the distance between the V&H coordinate of the originating Rate Center and the V&H coordinate of the terminating Rate Center.
  

Conventional rating, using the distance between rate centers will not be impacted in an SPLNP environment as portability is restricted within a rate center.

If there are any other types of Long Distance rating which disregard rate center parameters, they may be impacted in an LNP environment.

As a CLC must assign a unique NPA/NXX per ILEC rate center, an LRN could also be available per rate center without causing further number exhaust.

Canada does not have intra-inter lata situations or rate districts. They have local and long distance.

Canada would like LRN per rate center. Lively discussion ensued regarding whether a CLC must open an NPA/NXX if they only want to serve ported customers. If their switch already has an LRN, the CLC may have no need for 10,000 lines when they only want to port-in customers.

For taxing purposes, where a rate center crosses province boundaries, the preference would be to have the CLC open two NPA/NXX’s/LRN’s so that the LRN could be used for determining tax jurisdiction.

States may also have different taxing jurisdiction within rate centers.

Armen reiterated that SPLNP should not change taxing jurisdiction.

There’s a need to look ahead and build solutions that can handle Location Portability. We will have to redesign our systems for GUBB or whatever the Location solution is..

Some companies have different taxing rules for a given NPA/NXX, based on the customer’s physical location (address). Code on the service order identifies the TAR (Tax Area Revenue).

Moving within the rate center may change your tax jurisdiction.

Originating locations’ tax rules apply to the calls in Canada. Operator handled calls would require LRN’s for the originating number.

Why is Canada allowing inter-province porting under SPLNP? Interstate porting is not being allowed in the States?

What will be used to determine a local service provider for the initial phase of LNP? Service Provider ID will not be available in the AMA. LRN may be one way of identifying the local service provider.

As a CLC must assign a unique NPA/NXX per ILEC rate center, the associated LRN should identify the CLC. If a CLC has an NPA/NXX per rate center, it would be good to take LRN down to rate center level.

Reseller id’s will have to be determined in the respective billing systems. The LRN on their calls will be the facility provider company’s.

Sarathy E-Mailed a white paper on LNP which was distributed to all team members today.

LRN PROS & CONS (This was not completed)

It was noted that fraud potential is greater with LNP.

The following test results are from Bell South:

• If JIP is signaled, LRNs will be created at an intermediate switch, regardless of whether originating number was ported or not. This is true for at least Nortel and Lucent.
  
• Records garbage in the LRN field of the LRN module on any call that terminates into the 5ESS and the required information for populating the LRN field is obtained from SS7 trunk signaling. This will be fixed with MRS CCS588465AZ and CCS588465BZ from Lucent.
  
• In one case, the 5ESS indicated that data used to populate the LRN module came from the switch when it is obvious that the data came from trunk signaling (SS7). The Supporting Information field was populated with 2090000. This was fixed by setting the trunk group in the DMS to send the JIP. This was retested and was verified that the Switching System Data was changed to Incoming Signaling.
  
• When a ported out call routes via a 7 digit route to its point of termination, the LRN field of the LRN module is populated with only the NXX and 7 zeroes. Changing the route to a 10 digit route corrects this trouble. This is the most serious trouble uncovered thus far, because if the vendors cannot manage to carry the full 10 digits in the CALLED NUMBER field of the SS7 signaling IAM, and allow 7 digit call processing we may have to move to full 10 digit routing. This will be fixed with Patch UV70197 from Nortel and MRS CCS588465AZ and CCS588465BZ from Lucent.
  
• The DMS100 records a 720 module with a party identifier of 001 on all access recordings (CTC 110, 066, 064 and 119). The understanding is that the originating LNP module is only necessary when an access type call originates from a ported in number. (It appears that NTI decided to make a PI 001 module on any access recording where a ported in number originated a call - requirements only specify for originating access). NORTEL’s response was that this is an optional requirement to provide the originating party ID on all calls that provided a JIP or Home LRN. Per requirement R-122 from NORTEL’s NTP and the ICC requirement 1180. Note that California Delta Item #4 requests that ALL calls from ported numbers have originating LNP modules attached with the originating LRN derived off of the switch.
  
• The billing systems will need to have a mechanism to look up missing LRN data when required. This may cause severe billing cycle run time problems.
  
• Some companies are getting a feed from NPAC/LSMS to keep track of historical ported numbers information.
  
• Illinois Test Plan addresses inter-company testing. California Task Force is also addressing cooperative testing between companies.
  
  

• California Call Flow - Scenario P1 - Call originates from ported number, calling a ported number. We assumed that the call would NOT get an originating LNP module if there’s MF signaling between end office and operator switch. Why not? You can query at operator switch for DMS. Could also provision an LRN on the incoming trunk group and always get an LRN (regardless of whether originating number was ported). The LRN would not be able to identify the service provider if the incoming trunk group is shared by multiple carriers. Lucent and Nortel will offer querying capability. If a company chooses not to query on the originating number, then they would need to look it up in the billing system. Can the originating query be done as "non-critical real time", so that it doesn’t delay the call? Lucent says yes. Won’t add to the post dial delay.
  
• TOPS 07 will provide calling party 338 modules (helpful for reseller identification). This was also done for branding purposes. 338 modules for terminating numbers will be available mid-1998. The 338 module will have service provider id information. OLNS or switch data fill will provide the SPID inf.
  
• LIDB 8.1 will allow the population of SPID into the OLNS. LIDB 8.1 went to GA status on 4/30/97.
  
• 772 structure code will allow 10 digit line number information to be passed.
  
• You can set up your network to do an OLNS query. Done on ANI 7 0+ calls only. Is OLNS a trunk option?
  
• Can you have a line based calling card if you are not the service provider for that line? No.

• Customer went to NY from CA. Used their ported line based Calif. calling card. Billing validation in NY will go to their OSS and it is then sent to a Hub. The Hub sends it over to the donor network STP. The STP through GTT knows it has been ported and then sends it to the STP of the recipient network to reach their LIDB for validation. The Hub bills NY and the donor network because it received the query. It doesn’t know it is a ported number.

• Point code comes from the LIDB so how do we get to the right LIDB. This information can be stored at the STP.

• HUBs are third party vendors and are not required to be LNP capable. They will route the LIDB query based on the NPA/NXX of the donor.

• Scenario U - Busy Line Verification, Voice to Voice Hand Off - Bill to Calling Card or Third Party Number

• An intraLATA call where both OSS(s) are LNP capable.

• The Called Party Number is ported within this zone.

• This is an inter-network call.

• AMA expectation: 1st OSS - get cc 192 with Alt charge module, BLV module, LNP-T module cc198

• 2nd OSS BLV with cc199, no module attached. Will append module if record is received?

• John Mainwaring to follow up and report back to team. Action Item.

• 1st AMA record will be used to bill the caller for the BLV

• AMA record will have both originating and terminating module.

• Terminating side will have terminating LRN module. To get information, it requires assignment on the trunk group. Used to bill for dip. Originating record will be used to bill end user.

• Scenario V: - Third party (Authorization required) - In Three different zones of portability

• The Calling Number, the Called Number and the Third Number have all been ported and are all in the different zones of portability.

• If you tell switch you want 14 digit queries done, it will do query.

• If you don’t tell it to do the query, it won’t.

• Will get SPID but TOPS 6 can’t handle until mid-1998.

• How does LIDB in zone B get line level override information? IF you did 10 digit GTT and get LIDB of recipient, then it will put the RAO in the record.

• Receive Billing Service Provider SPID which is equivalent to RAO. Will receive before AN RAO.

• AN SPID and AN RAO in LIDB.

• Have infrastructure in place to do module 338.

• Do you want SPID populated with Alphanumeric RAO? We really have a need for both.
  
• SPID will help to identify who owns number which will aid in access billing.

• Could we get rid of alternate billed module and just use billing module?

• We can’t change existing due to backward capabilities needed.

• Billing SPID will redefine RAO and will be able to carry An. Two 338 modules.
  

• Billing SPID - according to SR338...3 provider data elements, Facilities provider, account owner, Billing Service provider.
  
• The billing service provider does not have to be in the network. Each company can select their own billing service provider. If you know the account owner, then it will take care of your resale and unbundling needs.
  
• Will only get facilities provider SPID for billing party from LIDB. Identifies where the call came from . The facilities provider is to be used in the Settlement process .
  
• Facilities provider SPID has nothing to do with who is going to pay for the call only who deserves the revenue for the call.
  
• Issues:
• 1. For OSS need Alphanumeric RAO and Account level owner in LIDB.
• 2. On calling number we need an account owner

• Tomorrow morning look at scenarios including billing number ported, calling number ported, called number ported. What SPIDs do you need?