|
Description Issue/Action Item
|
Resp. |
Resolution |
1 |
If there’s a need to have the switch derive more than one LRN on the originating side, the team needs to define the criteria and submit vendor change requests. The request needs to be specific as far as how many originating LRNs/how many terminating LRNs would be need to be derived and what the criteria would be (e.g. one per rate center or lower level). |
All |
|
2 |
Contact your METRG/OBF reps to get the EMR/EMI records put into the national standards document so that they can be openly discussed. This is a key billing issue from a data exchange point of view. |
All |
|
3 |
Baseline the Delta Document. Use revision number going forward |
Debi |
|
4 |
Need the NORTEL patch number for the host/remote change. |
Elizabeth |
|
5 |
If companies have specific number pooling concerns, they should participate in the next Illinois Conference Call. The call is July 15 at 11:00am EDT. Check with Armen or Jill for conference bridge. |
All |
|
6 |
Elizabeth Keddy will check to see what NORTEL is doing in regards to ICC req. 1196 |
Elizabeth |
|
7 |
Re-look access billing needs with AIN service and Delta Item #4 in general for access vs. end user originating module requirements. This team needs to reach consensus on the best solution and submit change requests to the vendors **CHANGE DELTA** |
All |
|
8 |
If your company is interested in participating in the Bellcore SPID requirements definition effort, call Bill Krall at 908 758-4296. |
All |
|
9 |
Should the Account Owner SPID be used in the SCP or the Facilities Owner SPID? Would system changes be required if we mix facilities/end user owners? |
Armen |
|
10 |
LSMS/NPAC Issue: Is the connection SPID the one that gets populated in the SCP entry for a given ported TN or is the new provider OCN from the service order used? |
Tom Santos |
|
11 |
For terminating access records we need terminating Account Owner SPID. Is the AO SPID in the SCP Today (no). **New DELTA** |
Debi |
|
12 |
Each company should research the need for SPID on originating numbers. Queries are not performed on the originating number, so the SPID would have to be a line attribute. Assess whether the SPID would be a critical requirement. **NEW DELTA?** This item will be discussed on the next conference call. |
All |
|
13 |
CNAT Requirements - Request a change to ignore ANI AND CPN and use Billing Account Number provisioned on the trunk instead. **NEW DELTA** Reference is ICC 1330 |
Debi |
|
REVIEW OF PREVIOUS DAYS MEETING
LRN issue was not resolved.
Need to make the meeting more efficient by staying focused on national level issues.
IMPACT OF LNP ON RESALE AND UNBUNDLING Tom Santos
If a call originates from a ported TN from an unbundled switch element or resold line, an originating LNP module is required on the originating AMA. California Delta Item #4 covers this item. FDAF type documents have been submitted to the vendors.
When you buy a port and a loop, are you also buying the TN’s that go with it. It’s TN by TN, like resale, not a bulk purchase.
Leasing facilities is an issue. Is this separate from Unbundling?
Which comes first: number ports in, then gets unbundled, or unbundled switching is purchased and then number gets ported in. Does it matter? Is a separate LRN required for the unbundler? Consensus was that the order doesn’t matter.
At this time, the LRN will belong to the facilities provider. Like resale, the billing system will have to identify that the AMA belongs to an unbundler.
SPID will be the solution for the carrier identification problem.
Can a local carrier restrict porting in at a given switch? If so, they would be restricting what resellers or unbundlers might want to do.
To identify individual ported in TN’s that are resold or unbundled will require a 10 digit "guiding" process.
Scenario A: Intranetwork call originating from an unbundled ported or resold ported TN
- Billing Requirement: Need originating LNP module (Delta #4)
Scenario B: Inter-network call terminating to an unbundled ported or resold ported TN
- Billing Requirement: Need terminating LNP module attached to the terminating AMA record for the unbundled ported or resold ported TN at the recipient switch.
- If there’s a need to create a new call code for calls terminating to an unbundled element, this needs to be communicated to the switch vendors.
- Terminating INWATS in addition to a terminating access record. Will the INWATS get an LNP module?
- Ericsson can attached the LNP module for access records, CNA and all local terminating type records.
- Delta #10 also applies to this item. Ability to derive a terminating LRN based on switch data.
- Siemens is looking into this now, per Raj. He indicated that people should call their Marketing rep to find out which release this will be in.
- CNAT options: Conditional - Only record if an LNP query is done or Unconditional - record every call coming in on that trunk.
- CNAT is not related to unbundling. If you mark a trunk as unconditional CNAT, you record everything, regardless of where it’s terminating.
- CNAT may not be the solution for recording terminating access to unbundled or resold lines.
- Delta #9 addresses the ability to generate an originating LNP module on a terminating recording.
Scenario C: Intranetwork call originating from an unbundled ported or resold ported TN to a LEC
- Billing Requirement: .Need originating LRN (Delta #4)
Scenario D: Internetwork call terminating to a resold ported TN
- Delete - same as Scenario B
Scenario E: Intranetwork/Interswitch call terminating to an unbundled ported TN (local call)
- Billing Requirement: Need terminating LNP module attached to the Originating AMA record for the unbundled ported TN at the recipient switch.
- REQ-IL-GR-1080 and REQ-IL-GR-1100
- Can you have different mutual compensation relationships between switching facilities providers and ported in/resold number owner? This will require contractual agreements. Need to continue to deal with the host. The host will be in control of compensation agreements even if they have pass through agreements.
- Would you have different arrangements for a reseller/unbundler vs. facility provider?
- For instance, facility company does the LNP query.
- Facility provider can be determined based on LRN. AMA will not identify reseller or unbundler. The facility provider’s billing system will have to identify this.
- LNP should not change how reseller/unbundling relations work today.
Scenario F: Intranetwork/Intraswitch call terminating to an unbundled ported TN
- Billing Requirement: On intraswitch calls to unbundled ported TN’s, no query will be done. We require that a terminating LNP module/LRN be derived off of switch data. This is Delta #13. The California Task Force assumed that the Unbundling team would be responsible for generating an AMA record for this intraswitch call. Delta #13 would add a terminating LNP module to the AMA.
- When we discuss the Delta document tomorrow, we need to discuss whether or not these items will be available with the first release of LNP. If any of the items are not available, are workarounds required?
Scenario G: Call originating from an unbundled ported or resold ported TN to an IEC
- Need originating LNP module.
Scenario H: Operator handled call originating from an unbundled ported or resold ported TN to an IEC
- Need originating LNP module on the operator handled call. Operator switch would have to do a query on the originating number.
- Who will be billed for the query? If it being done on behalf of the reseller/unbundler, how will cost recovery be done? Build it into the OSS contract? Find a way to bill them for the query? Policy issue.
RESULTS OF DISCUSSION
Unbundling and resale have no incremental impact on LNP. No unique physical change requirements off the network or usage measurements.
LRN ISSUE REVISITED
- Pennsylvania ruling said that CLC’s only need one NPA/NXX for a toll rate center. They do not need to conform to any lower level LEC requirements (e.g. one NPA/NXX per rate district within a rate center).
- This breaks the Rate Center Consistency rule.
- If the customer makes a PIC’d call, the LNP trigger at the originating switch is ignored and the call is handed off to the toll or intralata toll provider. They are responsible for doing the LNP query.
- Need more than one LRN if you have specialized trunk routing (e.g. Toll vs. EAS).
- Exhaust issues if try to assign LRN per rate center.
- In Pennsylvania, CLC’s would not have enough codes to assign LRN per rate center/zone.
- If the LRN assigned to a switch is from a different rate center than the call being made. For instance an ILEC customer makes a local call to a ported number. The LRN for the ported number is from a different rate center (recipient switch serves more than 1 rate center). Since routing is done based on LRN, a TOLL trunk might be selected when an EAS trunk should have been. Solution may be to assign a local EAS type LRN to this particular ported number in the SCP. This proves that at least 2 LRNs are required.
- SCP will only have one LRN. Whether a call is local or toll depends on who is calling the number. Could be a toll or a local call, but SCP will only have 1 LRN.
- Assign LRN’s by what rate center the recipient is in.
- Time of day routing, toll/EAS and other specialized routing schemes may have a problem. Billing records are determined based on dialed digits, prior to route selection.
- Call gapping may use LRN AND dialed digits.
- May need to request a vendor change to use dialed number and LRN for specialized route selection. This issue should be addressed by a network/switching group. Originating billing should be ok. There may be a downstream issue with access billing.
- The switch knows when an originating number is ported.
- If the number is no longer part of the EAS (EMS issue) there is an issue.
- In Pennsylvania - doing analysis based on dialed digits will cause incorrect billing. Toll boundaries will be ok. It’s rate district/zone billing that’s an issue.
- Host/Remote need for separate LRN’s was driven off a need to identify the wire center location, for access billing. There was not a need to determine rate center based on LRN for this scenario.
- ILECs have an NPA/NXX per rate center. CLC’s do not. They don’t need that many numbers.
- Update on Pennsylvania: Now they may move to assigning numbers in 1000 banks via porting them out. If you pool, makes LRN assignment problem worse. First 6 digits would be the same.
- Current switch software would not allow you to generate more than one LRN for a switch for "derived" LRN’s. In addition, JIP is a 6-digit parameter, so could not accommodate 10 digits. You can assign more than one in the SMS, so if you query, you would get whatever is in the database.
- NXXX proposal being looked at in Illinois and Pennsylvania is likely to become a reality.
- LRN assignment. What do we need: normal vs. NXXX proposal. Use 7 digit LRN?
- Per Arnette, routing uses 3, 6 or 10 digit (not 7 digit)
- Current vendor LRN software has not looked at going down to the line level. JIP is currently defined as 6 digits from ISUP.
- Current rules are that a CLC HAS to get 1 code to be used for the LRN. Will pooling change this?
HOST REMOTE (and misc.) Pat Witte
- Call A: Originating ILEC to St. Louis
In the host, the AMA should look like this:
SC 625 CC110
Module 720 / Party ID = Originating / LRN = host or remote
- Call B: Originating P*B to St. Louis
In the host, the AMA should look like this
Module 720 / Party ID = Originating / LRN = host or remote
- Ericsson cannot assign separate LRNs at this time (derived LRNs). Different LRNs in the SCP is not a problem.
- Siemens supports host LRN only. Siemens is working on providing LRN’s per rate center (future).
- 1A switches can’t support separate LRN for host vs. remote (RSS’ not supported)
- 5E ok.
- NORTEL has this functionality in NA008. Talk to your regional prime to see if it can be patched back to NA0007.
- If there are other types of umbilicals, then the JIP of the SM would be used to create the LRN.
- Assign LRN to remote at the host. Can differ depending on how host/remote is set up.
- If you take the LRN down to a rate center basis it should also identify the correct wire center.
- Number of derived LRN’s is dependent on number of SM’s.
- The Western Region had a maximum of 100 LRN’s in a separate NPA’s assigned to a switch as a working agreement.
- GTE stated that each switch needs to support a maximum of 100 LRN’s. This would allow capability to deal with CLC’s with many remotes/separate NPA/NXX’s. Need to define switch vendor change to define how these LRNs would be used on the originating side (derived). Associate by rate center? What criteria?
- NORTEL can handle a few thousand LRN’s but on the originating side only 1 will be derived per switch. In the case of a host vs. a remote, they will derive one each.
- How common is it for a switch to serve more than one rate center. It is very common and will be even more so for CLC’s.
- In the case of a 5E switch, the switch is comprised of many SM’s (switching modules). These SM’s may be co-located, or in a remote switch. Each SM can serve a finite number of lines/OE. LRN’s can be assigned by SM (via use of JIP).
- SM’s can serve more than one rate center. Lines may be mixed. Up to now, there hasn’t been a requirement to assign rate center LRN’s.
- On the 5E, if you have enough NPA/NXX’s, you can assign a different JIP per SM, but then you’d have to structure your lines on those SM’s to meet your LRN needs (e.g. put all lines for a given rate center into one SM). This may not be realistic from a network point of view.
- For end user billing, the originating and terminating numbers will be used for rating.
- Thought of the day "If we implemented Location Portability, Service Provider Portability would work great".
- There’s a meet point billing OBF issue about adding LRN to data exchange EMR/EMI records. This issue has not been resolved. Overlay LRN in regular TN fields, just send orig/term numbers?
- There are legal issues and standard record format issues at OBF. Bellcore/ATIS issue.
- What can the National Billing Forum do? Should we take on this issue or leave it to our OBF reps?
- A national standard is critical for data exchange records to avoid exception logic by company.
- LRN will be used for data exchange purposes to identify the company to send the record to.
- If you assign based on a DN basis, line picks up rate center, rate center picks up LRN. This is different than pure line level data. Be clear on requirements to switch vendors.
- GUBB could be shared between switches where LRN’s cannot (at least if wire center mileage is important).
- LRN and JIP are separate parameters on the switch. If you want the same NPA/NXX used for both, contact your network group.
- To get a unique LRN on a terminating recording, a unique LRN for the remote should be put into the ISCP.
- JIP is used to generate originating LNP modules on terminating AMA records.
- Ericsson can do this with the initial release
- Lucent cannot - FDAF item (Calif. Delta)
NUMBER POOLING Dave Whitney
- Currently, each CLC is required to get at least 1 LERG code per rate center.
- There will always be an owner for the 6 digit NPA/NXX in the LERG.
- Company A requests a code in RC1. The code is assigned to them in the LERG. Their LRN would have the same first 6 digits.
- Company B comes in and gets their own code in RC2 and uses that code for the LRN.
- Company C comes in and gets their own code in RC2 and uses that code for the LRN.
- All of these codes are in rate center one and two.
- If these 3 companies want to serve rate center three, one company can open a rate center three code on their rate center one switch and port out 1000 banks of numbers to Company B & C. This keeps B&C from having to open their own codes to serve rate center three. It will conserve numbers. A, B, and C have switches in other rate centers that they can use to serve rate center three. Their existing switches already have LRN’s so they don’t need to open a full code for LRN purposes.
- How would you determine the RAO for a pooled NPA/NXX number? Same as you do today.
- For existing codes, it may be hard to find an unused 1000 bank to port. Could also port 100 banks.
- If you’re processing usage/doing rating on someone else’s behalf you can no longer identify the carrier by NPA/NXX. if the number is pooled.
- Ameritech is opening an issue to get the TRA products to go down to the line level. The Illinois Rating & Billing subcommittee had a call on this a couple of days ago. At this point there are no impacts but this is preliminary and the committee reserves the right to readdress.
- The Ill. Billing and Rating subcommittee had a call on this a couple of days ago. At this point there are no impacts but this is preliminary and the committee reserves the right to readdress. Per Arnette, the scenario presented here was not addressed by the Ill. Rating and Billing subcommittee. Anyone who wants to participate in the ICC the next call is 7/15 10:00 Central Time. 8:00 Pacific Time. Armen will contact Judy and tell her of this team’s concerns.
- For operator handled calls, you may need to go down to a lower level to identify which company they are rating for. There will probably be different rating schemes.
- How does a pooling arrangement get generated? Is a service order required to update the SMS and mark the 1000 lines as ported?
- By August 1, Illinois Rating & Billing will make a recommendation - they feel that there is no additional billing impacts. Other systems (e.g. provisioning, network) may have additional impacts.
- This option allows pooling without major switch routing changes (to route on 7 digits).
- A 10 digit expansion for the TRA was discussed but deemed to be too massive.
- Now they are looking at 7 digit tracking.
- You won’t get away from having to look things up in the SMS/SCP because even if a 1000 bank is assigned to a given provider, individual lines in that range will be ported to other carriers.
AIN
- If 3/6/10 digit trigger number is not served by the switch performing the AIN query, the switch cannot generate a ported originating party LNP module.
- The originating number field of the SC220 contains the 3/6/10-digit trigger.
- Example: A calls B. B has an AIN trigger (e.g. follow me service). May look like a call redirection to "C". A to B leg would generate a "normal" call code (e.g. 001, 006). If there’s a SLPID, there would also be a SC 220 for the B to C leg of the call. AIN SC 220 can have other modules (e.g. 307 - AMA line number, 29 - for AMA Alt billing, 40 - alternate dialed number). In the 220 record, the orig number is the trigger number. The trigger number may or may not be on the same switch. The trigger switch may not be able to determine whether or not the trigger number is ported.
- Triggers can be called 3/6/10, PODP or SDS
- Module 307 can contain the original calling number, if the SCP echoes it back down. If you get multiple 307 modules back, how do you know which one is which? No guarantees. Each application has to define the 307 requirements.
- Proposed solution is that no LRN info will be provided on trigger or "sidecar" numbers if LRN is not sent down from the SCP.
- AIN trigger can also happen at an intermediate switch, where there is no "switch" LRN data.
- In the case of originating access records at the tandem (e.g. CC 110)., the LRN of the tandem is recorded in the 110 if an originating LNP query is performed at the tandem. This does not identify the originating end office LRN.
- Whether Access applies from the originating end office or the tandem depends on the AIN service.
- If trigger number is ported, an LNP query is NOT performed.
- If real originating number is ported and appears in a 307 module on the SC 220 record, an LRN is required if access needs to be billed from the originating end office.
- AMASLPID identifies the type of AIN service.
- Could put the AIN querying switches LRN on the 220 record, but it wouldn’t be correct. A 10 digit lookup would still be required. Could take LRN off of incoming JIP or trunk group (if available). Could end up with no LRN.
- Tandems don’t have LRN’s assigned (no NPA/NXX’s assigned to that switch). They would only have a code assigned if they are a tandem/end office type switch.
- 4E is a pure tandem product. They will not have LRN’s.
- Some companies are using Sensor ID to determine the recording office.
- Lucent is using querying switches LRN. Ericsson is doing this too, for all call codes. NORTEL will put the LRN of the querying switch if the trigger number is ported. If not served by that switch, won’t put any LRN. ICC requirements say always put it in. ICC REQ 1196 and 1196.5
- AIN triggers take precedence over LNP triggers. If both orig number and trigger numbers are ported, when the AIN response comes back, it will trigger an LNP query if the NPA/NXX returned is portable. We would see a Term. Module for "C" if it’s portable and an LNP query was performed.
- Bottom line, there is a lot of variety in AIN services and reliability of information when ported numbers are involved is questionable.
- AIN SCP may have to launch an LNP query.
- Do we want to take the position that if the information isn’t accurate, then don’t put any LRN in the record?
- Do we need an LRN for the Alt Billed number (Mod 29)?
- What about special billing numbers?
- PBX served by 1 trunk with special billing number on the trunk. You can mark the PBX trunk as ported and trigger the LNP logic off of that. You cannot port a partial group .NORTEL does not have any requirements for special billing numbers. Lucent isn’t checking special billing number to determine ported status.
- Possibility of putting line attributes on PODP trigger numbers to supply missing info (Raj). This is a Bellcore requirement.
- Siemens is appending an originating LRN for true originating number on the 220/110 record. Is this the right thing to do given the Bellcore requirement?
SPID - SERVICE PROVIDER ID Dave Whitney
- Bellcore has a work effort this year to define SPID requirements.
- Resale, and Unbundling caused the initial need for SPID.
- There are 3 types of SPIDs: Account owner, Facility Provider and Billing Service Provider.
- Facility Provider: Entity owning the switching system servicing the DN of the end user.
- Account Owner: Entity that is responsible for providing the services to an end user and ultimately responsible for rendering a bill to the end user. The person who owns the end user.
- Billing Service Provider: Entity which receives billing records from the various switches and carriers/providers. Third party billing service vendors or could also be a host company.
- Definitions need clarification. If you look at it from an LNP point of view, the definition may be different than if you look at it from an Operator Services point of view.
- In most cases, the account owner, facilities provider and billing service provider will be the same provider.
- SPID is in SCP, we’re already doing a query. Why not pass SPID to reduce lookups and billing cycle run time?
- These are defined in Bellcore SR3895, which is an Operator Services document that deals with RAO exhaust / branding issues and includes a definition for a service provider ID module (338).
- ICC has a field in the 720 module for SPID.
- The Bellcore SR has a 338 module specific to SPID.
MEET POINT BILLING
- Meet Point Billing issue: Ported Party A makes long distance phone call. JIP should be passed if there is SS7 signaling. That is how the IXC will ID the originating party. ANI is always passed with FGD. This could impact the IXC’s validation process. If they’re expecting access billing from the donor company and it comes from a ported company, they won’t be able to validate their access bills. ICC requirements for toll are vague. Are IXC’s recording the JIP info in their AMA? This would be 2 LNP modules: 1 for originating LRN, based on JIP and a second if the term. number is ported.
- IXC’s can get LRN from: 1) the JIP, 2) the LRN provisioned on the trunk group or 3) query on the originating number.
- ICC requirements state that JIP MUST be signaled when originating office is LNP capable, REGARDLESS of whether the originating number was ported or not. JIP has to be provisioned on switch first.
- Is Billing Service Provider ID really necessary?
- Co-use of switches between GTE and LEC does exist. Looks like resale, but it’s not.
- SPID is not required at originating switch if AO and FP at the originating switch are the same. LRN can be used instead.
- EMR/EMI, companies may overlay orig/term numbers with LRN’s. No standards yet.
- How do you know which tandem to send info to? By trunk today.
- In aggregate records, if they store more than one originating number, we will have trouble. This is a general issue, not a meet point issue.
- EMR/EMI can send summary records: summarizing at the NPA/NXX level.
- In an ICO CAMA end office to ILEC tandem to IXC scenario: Will get cc 110 at the tandem with orig. # and LRN of the trunk group or JIP (if provisioned - regardless of whether orig. number was actually ported). IXC could also do an originating query.
- Co-located switches - one LRN or two? CLC MUST have their own LRN. In a co-located situation, the CLC must signal JIP.
- Pooling means that LRNs will not be unique if JIP is generated based on JIP. All "pooled" CLC’s would get the same JIP derived LRN. Queries to the SCP would generate correct LRNs.
- On incoming trunk, if combined, you probably should not assign a trunk group LRN. ** ARNETTE WARNED YOU **
- We don’t need SPID if co-located entities have their own LRN.
- CAMA trunks are mostly MF and dedicated. If they are dedicated, then you can assign a trunk group LRN.
- ICC optional requirements for CAMA say to record in a CAMA recording at a CAMA office the originating LRN. LRN would be received off of incoming signaling or based on trunk group.
- IXC to Tandem to ICO/CLC - Terminating tandem records CC 119. If IXC performed query they will send LRN. Tandem will generate LNP module if terminating number was ported. Module will indicate that LRN was received in incoming signaling. Is SPID required in the 119? If tandem is not LNP capable, no module. In this scenario, the FP is the tandem, the AO is the CLC. Tandem company (for meet point), generates EMR record 110120.
- NPAC ISSUE: Any updates from SOA to NPAC will have ONE SPID. If you update NPAC on behalf of other carriers (ICOs/CLCs) the SPID in the SCP will be YOURS, not the ICO’s or CLC’s. This is an NPAC vendor limitation. They can only support one SPID per connection. They will allow multiple SPIDs in the future. This is ESI’s position (local SMS vendor). May not be true for you depending on your vendor. This could also be a service assurance issue.
- Will company contact info in the SMS also be the updaters?
- SPID from a pure LNP perspective is not really required. We can look it up off of the LRN. It’s a convenience item.
- The 11 record has an OCN field.
- Bellcore OCN does not identify the state. NECA had state specific codes (4000 series of numbers). 5000 series restricted to RBOCS, 6000 wireless, 7000 CLCs.
- How many different OCNs can you get back for a given LRN.
- SCP can only handle one SPID per company (National Level)
- This is an issue for companies that have state level codes.
- There’s an issue over whether AO SPID or FP SPID is required in billing.
- If you make a 119 record at the tandem and the terminating number is resold or unbundled (no LNP query), then the tandem won’t know that the term. number is resold/unbundled, so it could not generate a SPID. Armen indicates that billing system can figure it out.
MUTUAL COMPENSATION Jill Blakeley
- Ported in customer to CLC switch. CLC call goes through ILEC tandem to ILEC EO. Local call. CLC switch generates CC 001. Terminating ILEC switch generates 119. Originating JIP was signaled but not recorded in tandem AMA. ILEC can identify originating office based on CIC/Pseudo CIC on trunk group. CLC is AO/FP and BSP. Does CLC need SPID - No, Does ILEC need SPID - No
- Elizabeth not sure the NORTEL can assign an LRN to all trunk types. ATC trunks are viewed as non-dedicated, so no point in assigning an LRN.
- If you have a trunk type that doesn’t allow a CIC how would ILEC identify the CLC party? You could use the Trunk Group Billing Number.
- You cannot mark a FGD trunk with CNAT option. They are mutually exclusive.
- In translations you can say give me the trunk group billing number, not ANI. ANI has highest priority, then CPN, then record Billing Account Number. Lucent requires Billing Account Number if you mark a trunk as CNAT.
- It’s been suggested that CNAT should ignore ANI and CPN and use the Billing Account Number provisioned on the trunk group. ANI can be misleading if it’s a ported number.
- Charge number not normally used for intra-lata, but the rules have been changed.