CALNP Rating and Billing Task Force

.

ASSUMPTIONS

-	Switch Vendors will implement requirements as stated in the Illinois Generic Switching and Signaling Requirements to Number Portability (Issue 1.03 September 04, 1996.) The Rating and Billing task force used the Illinois document as a base. This document identifies missing elements in the Illinois Requirements that billing will need and supplies a Bellcore GR-2936 requirement where one exists.
-	California will implement LNP with rate center consistency.
-	Query on Release (QOR) was not addressed by the billing task force, pending further FCC rulings. The team will address QOR at a later date if the FCC approves it.
-	The billing task force may need to meet on an ongoing basis pending any issues that come out of Illinois’ LNP testing or issues identified by the other task forces.
-	Analysis only addresses Service Provider Portability
-	All Bellcore Requirements referenced in this document are from GR-2936 CORE, Issue 2, December 1996.

*Item #*	*Calif* Prior	Illinois Document Section	*Requirement Number*	Comments
1	REQ	4.1.1.1 - LNP Query	REQ-IL-GR-0140V1	Change #5: An LNP Query shall be sent when ALL of the following apply: 1. When the incoming trunk is MF or when the FCI for an ISUP trunk indicates that the number is not translated. This item does not apply to an originating switch. 2. When the called number has - an LNP trigger. 3. When the called number is not served by this switch. 4. When the route is not destined for an operator. 5. When the call is not to an interexchange carrier, presubscribed carrier or 10XXX, 101XXXX dialed. REASON: Carriers will be expected to do the LNP query in these situations, not the LEC.
2	REQ	4.8.1 - Measurements Issue: Need to track measurements by N-1 provider. (NOTE: This delta is against the Generic Requirements for SCP Application and GTT Function for Number Portability document. Issue 0.95, September 4, 1996)	<OPT> Note: Requirements for Traffic Study/Switch Measurement level/frequency of data will need to be addressed by the OPI Sub-committee) This is section 4.5.2 of the Generic Switching Requirements	Change requirement to read: The SCP shall track the following application measurements on an hourly and daily basis: - LNP queries per originating system by point code (SSP or Operator system) and within Point Code, by the N-1 Network’s Service Provider ID (OCN- Operating Company Number)) causing the query. - LNP queries for ported numbers per LRN - LNP queries for non-ported numbers per NPA- NXX. - LNP query failures. REASON: The Illinois document does not include adequate detail about query measurements. For cost recovery and reporting purposes, we need to know on whose behalf an LNP query is being done. The measurement information might be used to bill for contracted SCP access (in the absence of AMA) as well as for Regulatory reporting.

*Item #*	*Calif* Prior	Illinois Document Section	*Requirement Number*	Comments
3	REQ	4.8.4 - Billing Issue: Need N-1 provider information for query billing (NOTE: This delta is against the Generic Requirements for SCP Application and GTT Function for Number Portability document. Issue 0.95, September 4, 1996)	<OPT>	Change requirement to read: The counts for billing that have been identified are: - LNP queries per originating system by point code (SSP or Operator system) and within Point Code, by N-1 network’s Service Provider ID (OCN - Operating Company Number) causing the query. - LNP queries for ported numbers per LRN - LNP queries for non-ported numbers per NPA- NXX A new structure code should be developed that is similar to a 223 record (GR-1100). REASON: Some companies may want to bill for contracted SCP access as well as last resort queries off of SCP measurements and/or AMA. The Illinois requirements do not contain any provisions for billing. In addition, in order to bill for last resort queries off of SCP AMA/measurements, they must identify the N-1 carrier, who will be the billed party.
4	REQ	4.5.4.2.1.1-Appending the LNP module at an Originating Switch Issue: All AMA from ported numbers must have LNP module attached.	Missing (Originating LNP modules on all AMA from ported numbers)	Add Bellcore Requirements (GR-2936-CORE Issue 2, December 1996) R4-222 [ 378] through R4-224 [380]. While Bellcore requires appending a 719 module, appending a 720 module is acceptable. See Issue 12. REASON If the originating number is recorded in the originating number AMA field or the billing DN in the AMA record is ported, and the call is from a ported number, attach an originating LNP module to the AMA record. The task force requires that all AMA generated from ported DN’s include an originating LNP module, not just access recordings. For Mutual Compensation, identification of the real service provider is critical to avoid settlements with the incorrect company. In the event of delayed service orders, the originating LNP module will enable the ported-in company to identify the call as theirs, not as an Outcollect.
Item #	*Calif* Prior	Illinois Document Section	*Requirement Number*	Comments
5	REQ with Options	4.5.4.2.1.1-Appending the LNP module at an Originating Switch Issue: Need a way to force recordings for flat rate customers.	Missing	Add Bellcore Requirements (GR-2936-CORE) R4-205[185] through R4-213[193] to allow switch to generate switch-based AMA for an LNP query even if the call would not otherwise generate AMA (e.g. flat rated lines). This would be a new Call Type Code 721 with LNP module attached. Options: Office Wide Conditional, based on LNP query Conditional, based on LNP query and LRN returned. REASON: Illinois document does not address flat rate service. We need the ability to record local calls for cost recovery purposes. In addition, for Mutual Compensation these recordings are needed in order to calculate PLU (Percent Local Usage) in a Bill and Keep scenario. This would replace the ICC’s 220/047 recording at the end office. The options are to allow the companies to avoid creating extraneous local records that will not be used in billing (flat rate/dip done/called number not ported). Recording for unanswered, abandoned and busy calls should be treated the same way as existing local call codes (ability to turn recording on/off).
6	REQ	4.5.4.2.1.1-Appending the LNP module at an Originating Switch Issue: Calls originating from ported numbers at a remote switch must have a unique LRN assigned.	FUT-IL-GR-1127V1.02	Change from FUT to REQ. REASON: In California, we have host/remote situations and need to have this capability in order to calculate correct mileage for access billing. AMA from the remote must have a unique LRN (NPA/NXX belonging to the remote).
7	REQ	4.5.4.2.1.4-Appending the LNP module at a Terminating Switch Issue: Calls terminating to ported numbers served by a remote switch must have a unique LRN.	FUT-IL-GR-1199V1.01	Change from FUT to REQ. REASON: In California, we have host/remote situations and need to have this capability in order to calculate correct mileage for access billing. AMA terminating at the remote must have a unique LRN (NPA/NXX belonging to the remote). The LRN of the remote should be derived from the remote switch’s information if the LRN is not received in the incoming signaling and the called party is ported.

*Item #*	*Calif* Prior	Illinois Document Section	*Requirement Number*	Comments
8	FUT	4.5.4.2.1.4 - Appending the LNP Module at a Terminating Switch Issue: If a last resort query is done at a donor switch, need to be able to create an AMA record (call code 722), with LNP module attached in order to bill for the query. Need N-1 SPID information in AMA.	Missing - Last Resort AMA	Add Bellcore requirements (GR-2936-CORE, Issue 2, December 1996) R4-250[225] through R4-253[228] for "Last Resort" default AMA records. The Bellcore requirements apply only to donor switches, not tandems. The California requirement would also apply to any donor network switch (tandem and donor switches). REASON: If a call is received at any donor network switch over any Trunk Group not provisioned to record AMA on an incoming basis and for which a "Last Resort" query is launched, an AMA record will be required in order to bill for the LNP query. This recording would need to identify the N-1 service provider. The LNP module would be for the terminating , ported number.
9	FUT	4.5.4.2.1.4 - Appending the LNP Module at a Terminating Switch Issue: Append originating LNP module to terminating IXC, INC and CMC recordings.	Missing	AMA recordings made at a terminating network’s tandem or end office should include an originating LNP module if the calling number was ported. The originating LNP module would be generated at the originating switch based on a line attribute and passed down through the signaling via JIP to the terminating switch(es). An originating LNP module should ONLY be generated if the originating number is ported. REASON: There are cases where AMA billing records have to be exchanged between companies in order for correct billing to be done (e.g. 800, Mutual Compensation, INWATS). With this information in the AMA, the accuracy of the data exchange would be maximized, since both parties would be correctly identified.
10	REQ	4.5.4.2.1.4 - Appending the LNP module at a Terminating Switch Issue: Generate LNP module based on	REQ-IL-GR-1198V1.01	If a call is received at a recipient switch over an MF trunk, an LNP query will not be done, since the called number resides on that switch. In this situation, if the LNP module information is not passed in the signaling, the LNP module should be generated, based on
Item #	*Calif* Prior	Illinois Document Section	*Requirement Number*	Comments
		switch data at terminating switch, if not received in signaling. Add CMC call codes to existing requirement.		switch information (no additional query). Illinois requirement REQ-IL-GR-1198V1.01 addresses IXC/INC connections. The task force requires that the module be attached to any AMA created at the recipient switch for a call to a ported number, including calls to ported numbers at a host or a remote. CMC call codes (065 and 066) must be included. This is covered in Bellcore requirement R4265 [240].
11	REQ	4.5.4.3 Rules for Generating Connecting Network Access Record Issue: Ensure that all CNAT recordings for ported numbers have terminating LNP modules	REQ-IL-GR-1330V1.02	Add Bellcore Requirements from GR-2936-CORE Issue 2, December 1996: R4262 [237],through R4-267[242], While Bellcore requires appending a 719 module, appending a 720 module is acceptable for 10/97. See Issue 12. REASON: The terminating LNP module should be attached to the Connecting Network Access Record SC625/CTC 720 AMA records for non-query scenarios: TANDEM/END OFFICE COMBINATION 1. For calls incoming to a switch over a Trunk Group with the Connecting Network Access Recording Options set to on, for which an LRN is received in the incoming signaling from an interconnecting network and the DN is allocated on the switch, the switch shall generate a BAF Call Type Code 720 AMA record and append the LNP Core Module. This scenario would address a situation where a tandem is also serving as an end office. SERVING END OFFICE 2. If a call to a ported # is received over an MF trunk or unqueried over an SS7 trunk at an end office that serves a terminating ported DN allocated on the switch, append an LNP module to any CNAT records created, using the LRN of the terminating switch. The LNP Module should also include a party identifier set to "Terminating Party Data", a LRN Source indicator in the Supporting Information field set to "Switch Data", and
Item #	*Calif* Prior	Illinois Document Section	*Requirement Number*	Comments
				Query Status Indicator in the Supporting Information field set to "No Query Done". If the call terminates to a non-ported DN, then the switch should not generate an LNP module for the call.
12	FUT	Appendix A - LNP Module and Associated BAF Tables Issue: A separate AMA SPID module is required that would have indicators for LNP (orig/term/billed/N-1), resale, unbundling and RAO Exhaust/Operator Services needs.		Change Appendix to use Bellcore’s LNP BAF Module 719 with an optional 338 BAF Module for Service Provider ID (Office Wide - Translation Settable, shipped in OFF position), instead of ICC’s LNP BAF module 720. Make SPID a required element. REASON: The Bellcore document puts the SPID into a separate module (338) so that multiple SPID modules can be attached with an identifier field to indicate the type of provider. (e.g. reseller vs. billing provider. This information could be used to bill a reseller for LNP database dips. In a last resort scenario, the SPID of the N-1 provider would be required. In addition, the ability to attach a 338 module to normal usage would allow us to identify resale usage, which would allow one day migration of a ported line to a resale line. The ICC document does not allow for this type of flexibility. The reseller’s SPID would be provisioned at the line level, the facility based company’s SPID would be in the LNP database. (Also see ICC OSS Doc. Section 4.2). There is also a significant issue dealing with situations where billing systems need to exchange records in order to bill the end user. For example, if a customer from CLC A calls an 800 number belonging to another company, CLC A has to send a copy of the AMA record to the 800 owning company so that they can bill the 800 provider. If CLC A’s switch is not LNP capable, they will send the AMA record to the donor company, not the recipient company. The recipient company would have to rely on the donor to figure out who owned the customer at the time of the call and forward the AMA record to the correct company. Having SPID
Item #	*Calif* Prior	Illinois Document Section	*Requirement Number*	Comments
				modules (orig/term) whenever a calling or called number is ported would greatly reduce errors. OCN would be used for SPID. Note: Bellcore has a SPID requirements development proposal available in 1997 so the task force will defer requirements work until Bellcore’s proposal is reviewed.
13	REQ	4.5.4.2.1.1-Appending the LNP module at an Originating Switch Issue: Append terminating LNP module for intraswitch calls to ported numbers.	Missing	Add Bellcore requirements (GR-2936-CORE, Issue 2, December 1996) R4-217[197] through R4-218[198] for intra-switch calls to ported DNs. While Bellcore requires that a module 719 be appended, a 720 module is acceptable for 10/97. See Item #12 REASON: For calls made at an originating switch and completed to a ported DN on the same switch, no query is performed. In the case of unbundling (where a CLC may buy switch capacity to serve their customer) an LRN is needed on the terminating side to identify the correct wire center in order to calculate the mileage component of unbundling charges. The LRN should be derived from the master switch level LRN. This request would add the requirement to append an LNP module to any existing intra-switch AMA.
14	FUT with Options	4.5.4.2.1.1-Appending the LNP module at an Originating Switch Issue: Need a way to force recordings for busy, attempts and unanswered calls.	Missing	NEW OPTION For all call codes, create office based options to create AMA for busy, attempts and unanswered calls if an LNP query is done. There should be two options: 1. When LNP query is made 2. When LNP query is made and LRN is returned. REASON: To offer the option to create AMA in these types of situations if there is a need to bill for the LNP query.