(Version 1.01 Updated 10/28/97)

Issue Number

1

Issue Title

LNP Query

Submitted By

California Task Force

Priority

Requirement

Reference Document

ICC Requirements 4.1.1.1

REQ-IL-GR-0140V1

Status

Closed

Issue

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.

Vendor change request status: No change request required.

 

 

Discussion

 

9/10/97 - Switch vendors have included these already.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

2

Issue Title

Need to track measurements by N-1 provider.

Submitted By

California Task Force

Priority

Requirement

Reference Document

ICC Requirements 4.8.1 Measurements Optional

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

Status

Open

Issue

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.

Vendor change request status: No change submitted. This Delta is dependent on the ability to pass N-1 SPID info to the ISCP. See #12.

 

 

Discussion

10/15/97 - We discussed whether Delta’s #2 & 3 requirements are still needed and agreed that they are.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

3

Issue Title

Need N-1 provider information for query billing

Submitted By

California Task Force

Priority

Requirement

Reference Document

4.8.4 - 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

Status

Open - Need SPID signaling resolution

Issue

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.

Vendor change request status: No change submitted. This Delta is dependent on the ability to pass N-1 SPID info to the ISCP. See #12.

Discussion

9/10/97 - See WWW.PORTED.COM, Western Region Requirements Issues #47 and 59 for additional information on this issue.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

4

Issue Title

Appending the LNP module at an Originating Switch

Submitted By

California Task Force

Priority

Requirements Missing (Originating LNP modules on all AMA from ported numbers)

Reference Document

4.5.4.2.1.1

Status

Open - Need SPID signaling resolution

Issue

All AMA from ported numbers must have LNP module attached.

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.

Vendor change request status: Change request submitted by Calif. Task Force to CGS, Ericsson, NORTEL, Lucent and Siemens. Lucent #99-CP-4322

 

Discussion

9/10/97 - See WWW.PORTED.COM, Western Region Requirements Issues #47 and 59 for additional information on this issue.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

5

Issue Title

Appending the LNP module at an Originating Switch

Submitted By

California Task Force

Priority

Requirement Missing

Reference Document

4.5.4.2.1.1

Status

Open

Issue:

Need a way to force recordings for flat rate customers.

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

1. Conditional, based on LNP query

2. 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).

Vendor change request status: Calif. Task Force submitted change request

 

Discussion

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

6

Issue Title

Appending the LNP module at an Originating Switch

Submitted By

California Task Force

Priority

Requirement

Reference Document

4.5.4.2.1.1

FUT-IL-GR-1127V1.02

Status

Open

Issue:

Calls originating from ported numbers at a remote switch must have a unique LRN assigned.

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).

Vendor change request status: Calif. Task Force submitted change request

 

 

Discussion

9/10/97 - See related Delta Issues 16 & 17

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

7

Issue Title

Appending the LNP module at a Terminating Switch

Submitted By

California Task Force

Priority

Requirement

Reference Document

4.5.4.2.1.4

FUT-IL-GR-1199V1.01

Status

Open

Issue:

Calls terminating to ported numbers served by a remote switch must have a unique LRN

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.

Vendor change request status: Calif. Task Force submitted change request

 

Discussion

 

9/10/97 - See related Delta Issues 16 & 17

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

8

Issue Title

Appending the LNP Module at a Terminating Switch

Submitted By

California Task Force

Priority

Future

Reference Document

4.5.4.2.1.4

Missing - Last Resort AMA

Status

Open

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.

Add Bellcore requirements (GR-2936-CORE, Issue 1, 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.

Vendor change request status: Calif. Task Force submitted change request, but change is dependent SPID being signaled through the network, so this is a future request.

 

Discussion

9/10/97 - If a last resort query is done at the point of interface, the 722 record is not required. This Delta deals with a situation where a default routed call comes through Company A’s tandem and for some reason the LNP query is not performed, so the call continues over intra-office trunks, to Company A’s donor end office, and the LNP query is performed there. No AMA is generated in this situation today.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

9A

Issue Title

Appending the LNP Module at a Terminating Switch

Submitted By

California Task Force

Priority

Future

Reference Document

4.5.4.2.1.4 - Missing

Status

Open

Issue:

Append originating LNP module to terminating IXC, INC and CMC recordings. This should be an office wide option so that companies can decide whether or not they want to record this information.

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).

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 and Mutual Compensation). With this information in the AMA, the accuracy of the data exchange would be maximized, since both parties would be correctly identified.

Vendor change request status: Calif. Task Force submitted change request.

 

Discussion

9/10/97 - There was a discussion about whether JIP should only be signaled when the originating party is ported. Note that IXC’s use the JIP to identify the originating facility provider for casually dialed (10xxx) calls. They use this information in order to send the billing records to the correct company. One concern was that sending JIP on a conditional basis might force the IXC’s into doing originating queries on all incoming calls, since they couldn’t be sure if the JIP should have been sent. This is addressed in OPT-IL-GR-1220V1. It is believed that wireless carriers also use the JIP field today, possibly to identify where you are calling from when you’re roaming (?).

10/16/97 - This was a "future" requirement, but some switch vendors are producing these originating modules now.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

9B

Issue Title

4.2.2.1.2 ISUP Signaling Formats

Submitted By

National Billing Forum

Priority

Future (Optional)

Reference Document

REQ-IL-GR-0460V1.03

Status

Open

Issue:

Create an option to only signal JIP if the originating TN is ported-in.

 

REASON:

When Delta #9A is implemented, ALL terminating records will include an originating LNP module, regardless of whether or not the originating TN was ported. This will cause unnecessary expense to store and process the LNP modules for unported numbers.

Vendor change request status: Not submitted

 

 

Discussion

9/10/97 - Need to discuss the potential negative impact on IXC’s and resellers and reach consensus on whether this change is necessary. Signaling experts will also need to be consulted. See comments for Delta #9A.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

10

Issue Title

Appending the LNP module at a Terminating Switch

Submitted By

California Task Force

Priority

Requirement

Reference Document

4.5.4.2.1.4

REQ-IL-GR-1198V1.01

Status

Open

Issue:

Generate terminating LNP module based on switch data at terminating switch, if not received in signaling, and the terminating number is marked as ported-in. Add CMC call codes to existing requirement.

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 switch information (no additional query). Illinois requirement REQ-IL-GR-1198V1.01 addresses IXC/CMC 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 [239].

Vendor change request status: Calif. Task Force submitted change request.

 

Discussion

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

11

Issue Title

Rules for Generating Connecting Network Access Record

Submitted By

California Task Force

Priority

Requirement

Reference Document

4.5.4.3

REQ-IL-GR-1330V1.02

Status

Open

Issue:

When the CNAT option is turned on, ensure that all SC625/CTC 720 recordings for ported numbers have terminating LNP modules

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. Note that this would only apply if the unconditional CNAT option was turned on, because the AMA record would not be generated unless an LNP query was performed if the Conditional option was selected.

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 a 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.

Vendor change request status: Calif. Task Force submitted change request.

 

Discussion

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

12

Issue Title

LNP Module and Associated BAF Tables

Submitted By

California Task Force

Priority

Future

Reference Document

Appendix A

Status

Open

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 modules (orig/term) whenever a calling or called number is ported would greatly reduce errors. OCN would be used for SPID.

Note: Bellcore is in the process of developing GR-2970 - Identification of Service Provider Capability Specification. Contact Bill Krall at Bellcore (908 758-4296) for additional information.

Vendor change request status: Not submitted, pending Bellcore work effort.

 

Discussion

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

13

Issue Title

Appending the LNP module at an Originating Switch

Submitted By

California Task Force

Priority

Requirement Missing

Reference Document

4.5.4.2.1.1

Status

Open

Issue:

Append terminating LNP module for intraswitch calls to ported numbers

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.

Vendor change request status: Calif. Task Force submitted change request.

 

 

Discussion

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

14

Issue Title

Appending the LNP module at an Originating Switch

Submitted By

California Task Force

Priority

Future with Options Missing

Reference Document

4.5.4.2.1.1

Status

Open

Issue:

Need a way to force recordings for busy, attempts and unanswered calls.

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.

Vendor change request status: Calif. Task Force submitted change request.

 

 

Discussion

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

15A

Issue Title

Need option to populate Orig. NPA/Number with trunk group "Billing Number"

Submitted By

Pat Witte - SWBT

Priority

Required

Reference Document

4.5.4.3 - Rules for Generating Connecting Network Access Record.

REQ-IL-GR-1330V1.02

Status

Open

Issue:

Illinois requirements state that ANI will be recorded in the Originating Number field on the AMA, when received in incoming signaling. Some companies require that the "billing number" on the trunk group be recorded in this field.

NEW OPTION

The switch must provide the "record billing number" option to always record the billing number provisioned against the CNAT trunk group in the Originating Number of the BAF CTC 720 record. The default for this option is OFF - Originating number recorded per the following requirements.

Note: This is a terminating AMA record

 

Populated in the Originating Number in

Incoming SS7 IAM BAF CTC 720 Record

No CPN, No ChN, No OLIP Provisioned Trunk Group Billing #

CPN, No ChN, No OLIP Provisioned Trunk Group Billing #

CPN, No ChN, OLIP CPN

CPN, ChN, OLIP ChN

No CPN, ChN, OLIP ChN

CPN, ChN, No OLIP ChN

* IN the case of call forwarding, CPN is not reliable for LNP purposes. CPN may not match ANI (e.g. may be special billing number).

This issue gives you trunk group billing number for all. If this issue is not active give us the above table.

IAM = Initial Address Message

CPN = Calling Party Number

ChN = Charge Number

(Note: for call forwarding, ChN will change to new number, but CPN will not)

OLIP = Originating Line Information Parameter

BTN = Trunk Group Billing Number

REASON:

Illinois requirements indicate that ANI will record if it’s received. Based on their billing system, some companies require that the "billing number" take precedence.

Vendor change request status: Not submitted.

 

 

Discussion:

A call scenario is:

A calls B - call forwards to

B calls C

to C "B" is ANI

ANI is the old MF term for Charge Number the ANI was typically forwarded from the called line and is lost in a call forward situation. In this issue If the option is active you always get BTN. If this option is not active you will get the recording as listed in the table above.

This should be a switch wide option and not a trunk group option in the switch. This will only impact Call Code 720 type records on CNA type trunks.

9/10/97 - The team needs to agree that this should be an office wide option vs. a trunk option.

10/15/97 -

  • Scott Frey said that this issue was also presented to the AMATSG team. He believes that their recommendation was to make it an office-wide option, however the table listed in Issue 15A was not accepted by AMATSG.
  • Consensus was reached, contingent on confirmation from USWEST by 10/24/97. The office wide parameter will be used.
  • The table still needs to be addressed by the team, pending input from AMATSG.
  • Ericsson warned that this proposal differs from how ANI is determined today. Is this requirement solely for the CC720 record or are we requesting changes to how ANI is determined in general?
  • ChN only gets modified by events like call forwarding.
  • Companies are using CNAT records for more than query billing.

 

Issue Number

15B

Issue Title

Create option to record Module 164 on CNAT records

Submitted By

Pat Witte - SWBT

Priority

Required

Reference Document

4.5.4.3 - Rules for Generating Connecting Network Access Record. REQ-IL-GR-1330V1.02

Status

Open

Issue:

If Delta 15A is turned on, the trunk group billing number would be recorded in the Orig Number field in the CTC 720 AMA record. Companies may also want to receive ANI information.

 

NEW OPTION

Create office based option to provide the capability to append BAF module 164 containing the CPN or ChN received in signaling for the CNAT AMA recording (CTC 720). The default for this option would be OFF - no Module 164 appended. If both CPN and ChN are received, follow the table in Issue 15A to decide what the record in Module 164. This option is dependent on Delta Item #15A being turned on.

 

REASON:

This would allow companies to receive both "billing number" and CPN or ChN in the CNAT record.

Vendor change request status: Not submitted.

 

 

Discussion

Warning: Realize the per trunk group JIP should be assigned on direct trunk groups and not shared groups. Provisioning a JIP in a shared situation could result in incorrect recording.

This may not be any different than provisioning a BTN against the incoming trunk group.

ICC covers incoming CAMA IXC (provision JIP/LRN per trunk group) AMA + Signaling.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

15C

Issue Title

Allow capability to provision a JIP on a CNAT trunk and record it as originating LRN .

Submitted By

Pat Witte - SWBT

Priority

Required

Reference Document

4.5.4.3 - Rules for Generating Connecting Network Access Record. REQ-IL-GR-1330V1.02

Status

Open

Issue:

In cases where JIP is not signaled and there’s a need for an N-1 identifier, allow the capability to provision a JIP against a CNAT trunk.

NEW OPTION

Allow the provisioning of JIP against CNAT trunks. If JIP is received in incoming signaling, Delta #9 will create an originating LNP module, using JIP to populate the LRN field. If JIP is not received in incoming signaling, record the provisioned JIP, if available, in the originating LRN module. If there is no JIP, then do not produce the originating LNP module.

 

REASON:

This will allow companies to determine the N-1 provider.

Where combined traffic is received over a CNAT trunk, the per trunk group JIP should not be provisioned.

Vendor change request status: Not submitted.

 

 

Discussion

This is related to Issue 9.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

16

Issue Title

Ability to derive a 10-digit LRN based on switch data.

Submitted By

National Billing Forum

Priority

Required

Reference Document

4.5.4.2.1.1-Appending the LNP module at an Originating Switch

4.5.4.2.1.4 - Appending the LNP module at a Terminating Switch

Status

Open

Issue:

There are cases where companies want to populate the line number field of the LRN. In cases where the LRN is derived, based on switch data, there’s a need to derive a 10 digit LRN , per office or remote. This would be for AMA purposes only.

 

REASON:

Where a remote doesn’t have a unique NPA/NXX, being able to assign a unique line number in the LRN would allow billing systems to build logic to properly rate access calls.

Note: This issue is not limited to remote switches. It applies to any switch vendor who does not have the capability to derive a 10 digit LRN from switch data.

Vendor change request status: Not submitted.

 

 

Discussion

This is asking for the ability to derive a 10 digit LRN from switch data. This would apply to LRN’s derived from switch data in either an originating or terminating LNP module.

10/15/97 - This issue would provide the capability to derive a 10 digit JIP from switch data and populate it in the LNP module. only 6 digits would be signaled.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

17

Issue Title

Signal 10 digit JIP

Submitted By

US West - M. J. Anderson

Priority

Required

Reference Document

4.5.4.2.1.1-Appending the LNP module at an Originating Switch

4.5.4.2.1.4 - Appending the LNP module at a Terminating Switch

Status

Open

Issue:

 

 

Delta issue #9, which relates to appending the originating LRN on the terminating access recordings. This LRN would be created using the JIP of the originating switch, which is 6 digits. This requirement is to signal a 10 digit Originating LRN.

 

REASON:

May be required if the LRN significant digits go to more than 6 digits.

Note: This could be generic to more than just CNAT but will effect all

Originating LNP recordings.

Vendor change request status: Not submitted.

 

Discussion

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

18

Issue Title

Terminating Account Owner LSPI is required in terminating access records.

Submitted By

National Billing Forum

Priority

Required

Reference Document

4.5.4.2.1.4 - Appending the LNP module at a Terminating Switch

Status

Pending Closure - Not LNP but Resale

Issue:

Where a tandem company is providing tandem transit service and needs to forward AMA records to other companies, they need to identify the correct terminating company. The current LNP requirements would pass the facility provider LSPI.

 

REASON:

The tandem provider needs to know the Account Owner LSPI. The Account Owner SPID is not populated in the SCP today.

Vendor change request status: Not submitted.

 

 

Discussion

It was discussed that this appears to be a Local Comp issue and not a LNP issue. LRN information is considered Facility Provider information only and not the actual Account Owner.

10/15/97 - This issue is covered by the LSPI effort (Proposed GR-2970). Note: Non-SSP switches will not be able to pass LSPI. LSPI is available separate from LNP.

800 issue; without LSPI, 800 provider/pots routeable provider may not get all of the usage to bill. Some companies may error usage instead of forwarding it.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

19

Issue Title

Need to signal originating LRN in the TCAP message for the purpose of deriving owner of originating switch.

Submitted By

National Billing Forum

Priority

Required

Reference Document

4.5.4.2.1.41- Appending the LNP module at a Originating Switch

Status

Open

Issue

If originating NPA/NXX look-ups are done at any databases (e.g. 800, AIN), it will be necessary to signal new information in the query, possibly JIP or 10 digit originating LRN, to identify the originating switch, when the originating party is ported.

Recommend that a new OLRN parameter be developed.

Aggregate AMA records will have bill validation problems.

REASON:

Any application that keys off of the originating number where the originating party is ported

This would address the issue where a company needs to know which company/wire center is originating a call. It will not solve "location" type problems (e.g. 1-800-PIZZA, where the originating NPA/NXX is used to determine which PIZZA branch to route the call to).

Vendor change request status: Not submitted.

 

 

 

Discussion

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

20

Issue Title

Need the ability to assign LRN at the rate center level or on a per line basis in the switch for derived LRN information.

Submitted By

National Billing Forum

Priority

Required

Reference Document

4.5.4.2.1.41- Appending the LNP module at a Originating Switch

Status

Open

Issue

Should we request that switch vendors build the capability to signal an LRN per rate center or even per line level.

NEED TO DEFINE REQUIREMENT

 

REASON:

Vendor change request status: Not submitted.

 

 

 

Discussion

10/15/97 - This issue will be addressed by a sub-team. This team will develop requirements language for Delta 20.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

21

Issue Title

Multiple Tandems within a Rate Center

Submitted By

National Billing Forum - Debi Ferguson

Priority

Required

Reference Document

 

Status

Open

Issue

When the following conditions exist:

  • Multiple tandems reside within the same rate center
  • A number is ported from an end office subtending tandem A to an end office subtending tandem B
  • A call to the number is default routed to tandem A. Tandem A launches the LNP query. The LRN that is returned is an NPA/NXX that subtends Tandem B. The call will either fail or have to be tandem to tandem switched to complete.

When the call originator or N-1 carrier fails to do the LNP query, based on LERG Routing, the call will be routed to the tandem hosting the portable dialed NPA/NXX.. That switch will launch the LNP query. If the LRN returned does not subtend that tandem, the call may fail. One possible solution is to allow tandem to tandem routing for any misdirected call, not just calls to ported numbers.

Call failures create customer confusion and complaints. Yet tandem to tandem switching is in conflict with FCC and state regulatory directives. This also creates billing issues, i.e. incorrect transport measurements.

NEED TO DEFINE REQUIREMENT

 

REASON:

Vendor change request status: Not submitted.

 

 

Discussion

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

22

Issue Title

Create option to use LRN and call type to select toll vs. EAS trunk

Submitted By

National Billing Forum - Raj Udeshi

Priority

Required

Reference Document

 

Status

Open

Issue

Where the LRN of a switch is in a different rate center than the ported, dialed number, there is a possibility that the wrong trunk will be selected (toll vs. EAS) to route the call to the terminating switch. This will cause billing issues.

NEED TO DEFINE REQUIREMENT

 

REASON:

Vendor change request status: Not submitted.

 

 

 

Discussion

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

23

Issue Title

Invalid originating LRN’s on access records generated at intermediate switch when call is from a wireless customer.

Submitted By

National Billing Forum - Debi Ferguson

Priority

Required

Reference Document

REQ-IL-GR-1070V1.02

Status

Open

Issue

Illinois REQ-IL-GR-1070V1.02 states that when an Intermediate switch that performs IC or INV Access Recording is creating an originating AMA record, it will use SS7 ISUP signaling - IAM JIP to create an originating LNP module (if JIP is not available, trunk group LRN would be used).

This is causing a problem:

1. Sample scenario: Wireless provider’s customer calls an interlata 800 number. The originating access record (call code 141) is created at the tandem provider’s switch. The wireless provider signals JIP. Companies are seeing originating LNP modules with LRN’s from a different state. Are the wireless provider’s using JIP for a different purpose? Are they signaling the originating cellular phone number in the JIP when a customer is roaming? These foreign LRN’s will cause billing problems. We may need to request special handling for wireless trunks.

NEED TO DEFINE REQUIREMENT

 

REASON:

Vendor change request status: Not submitted.

 

 

 

Discussion

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Issue Number

24

Issue Title

FGA Issue - Need different LNP modules

Submitted By

National Billing Forum - Karen Albers

Priority

Required

Reference Document

 

Status

Open

Issue

The Illinois requirements state that originating access records will have originating LNP modules attached and that terminating access records will have terminating LNP modules. FGA service is "backwards". The originating FGA recording is used to bill "terminating" traffic. We may need the terminating LNP module on an originating FGA AMA record (Call code 131) and an originating LNP module on a terminating FGA AMA record (Call code 132).

Some companies are planning to allow FGA TN’s to port. From a priority point of view, the end user is more likely to be ported, vs. the FGA TN itself. Priority should be placed on ensuring that appropriate modules appear on the FGA AMA for any ported end users.

There is a lot of confusion around FGA. We will discuss at the next meeting and clarify our requirements.

 

 

NEED TO DEFINE REQUIREMENT

 

REASON:

Vendor change request status: Not submitted.

 

 

 

Discussion