Q2 2009
The ATS Network & Billing Update is published by Advanced Technologies & Services, Inc. (www.atso.com), a revenue and service assurance solutions provider. This free newsletter is a guide to telecommunications OSS, billing, and revenue assurance news and other telecom industry analysis. To unsubscribe, contribute an article, or for offbeat news, please scroll to the end. Feel free to forward this newsletter to your friends and co-workers!
In this issue:
ATS Developers' Corner
By: Paul Gilbert,
Senior Software Engineer, ATS
Sometimes engineers need to be careful what they say. What gets scribbled on a napkin one day may become dogma the next.
So it was with a SimCall module developed in 1997. This module was requested to validate that CLEC codes were being opened by the ILECs in a "timely", competition- fostering way. The CLECs were claiming that the ILECs were deliberately inefficient in the opening of new codes for their new competitors.
The ILECs counter-claim was that there was no conspiracy. They were simply incompetent, and needed a tool to help them audit where and when the process of opening new codes for CLECs was not being performed. In the end, it was the CLECs failing to arrange for trunking that accounted for many of the cases of late code openings.
Even so, the "crisis" was brought to the SimCall team to see if SimCall could help the ILEC corporation identify all CLEC routing and validate that routing XLTNs were in place when expected, to quiet the anti-competitive claims being made by the CLECs.
To perform said validation, SimCall needed more data about the RTE result of a simulated call than SimCall was then providing.
Thus the name "SimCall Code-Opening and Routing Validation Add-on" was coined. Pressed for an easier moniker, I created the acronym 'SCORVA', which has persisted to this day.
Since SimCall already performed Code-Opening validation, this moniker is internally known as 'RVA', or 'Routing Validation Add-on'. The focus was on CLEC Code Openings, which accounts for the popularized use of 'SCORVA', rather than simply 'RVA'.
In the end, SCORVA was, and is, used as a general Routing Validation tool. SimCall's original mandate was to find billing errors, and so it only categorized the Route Result as one of LEC, IEC, OPR, ANN, etc., rather than furnish details about signaling, outpulsing, and destination of the trunking used to route the call.
This RVA module requires 2 additional data sources to perform its validation:
1. 'pc2clli' A file relating the "Point Code" to the CLLI is needed. The "Point Code" is the equivalent of an IP Address, but on the SS7 network. Unfortunately, the SS7 network has nothing resembling a DNS (Domain Name service), so getting a good 'pc2clli' file requires the cooperation of the client's "Network Engineering" group.
2. 'rva.fmt' A file set relating dialed NPA-NXXs to Far-End CLLIs and Near-End Tandem CLLIs. This file "set" is a hierarchy of similar format files that contain locale-specific overlays of LERG-derived data. The file name is always 'rva.fmt', but its location determines its level of specificity.
How SCORVA works in overview:
First, the assumption is made that only SS7 trunking can be validated. All significant trunking was converted to SS7 in the early 90's, so this is a reasonable assumption.
This is where the 'pc2clli' file comes in. The problem in general was that there was no reliable method of determining the LERG-standard destination CLLI of a Trunk Group within translations themselves. However, every SS7 TGN must have a "Destination Point Code" in XLTNs in order to route over the SS7 network. The RVA module could derive the DPC from XLTNs and then "determine" the correct far-end CLLI from the 'pc2clli' file. In summary for this part, using XLTNs and the 'pc2clli' file, SimCall could say, "If I dial from NPA-NXX A to NPA- NXX Z, I will use TGN X, which has DPC A-B-C, which goes to Office B, which may be a Tandem or an End Office. Therefore, the RVA module's ACTUAL result depends heavily on the accuracy of the 'pc2clli' file.
To find Routing Errors, the RVA module makes no assumptions about whether the TGN number is correct. It can't assume that TGN numbers have any pattern across client companies and switch types.
The 'rva.fmt' file set is used to perform the validation side of the RVA module.
The RVA Routing Rule: If NPA-NXX Z is dialed from NPA-NXX A, then Z's Tandem is where the TGN is supposed to go unless there is a Direct TGN to the End Office. Further, if no TGN exists to either of the End Office or Z's Tandem, then the TGN should go to A's Tandem.
Routing realities are never that simple however. What if there are no TGNs to the Tandems named in the 'rva.fmt' file? Or what if there are, but an office is Routed differently for some reason?
This is why 'rva.fmt' is a file hierarchy, not just a file. LOC A- specific versions of 'rva.fmt' can be created to overlay more general versions, allowing the client to fully specify, down to Rate Centers within a CLLI, where dialed NPA-NXXs should end up.
Implied in the RVA Routing Rules above is the assumption that if a Direct TGN exists to the Z End Office, it is always the preferred route. Using this assumption allows the RVA Module to perform partial validation without a completely accurate 'rva.fmt' file set.
At start-up, the RVA module accumulates all the End Office CLLIs in the "Intralata Arena", and runs through all the office TGNs to take their DPCs to the 'pc2clli' file. It therefore, derives a list of those End Office CLLIs for which a Direct TGN exists in the office. This allows the RVA Module to detect when an available Direct TGN is not used, even if the Tandem information from 'rva.fmt' file set is incorrect or not populated.
The "initial" rva.fmt file is created from a join of LERG6 and LERG7SHA on the CLLI and SHA fields. The script that does this has a rule set built it regarding which order among the tandem fields populated in LERG7SHA to join on, and therefore associate with the NPA-NXX. The idea is to derive the "Home Tandem" for each NPA-NXX seen as "in service" in LERG6.
Client specific data can overlay this file and/or create CLLI-specific changes or additions of NPA-NXX associations. In addition, an Editing Interface in the GUI allows manually-created overlays or additions to any auto-generated portion of the 'rva.fmt' file set. The GUI also has an extensive FILTER capability over the data generated when the RVA module is enabled for a SimCall run.
Let us know what you think of this on-going work at info@atso.com.
- [Top of Page]
OBF
#106 - Indian Wells, CA
By: Ken Babcock,
VP of Regulatory Services, ATS
As hinted in my last report, OBF#106, which was held in conjunction with other ATIS groups under the umbrella title of ATIS Meeting of Committees (AMOC), at Indian Wells, CA from April 20-24, 2009 was worth the price of admission.
The joint meetings with the PTSC Packet Technologies and Systems Committee (PTSC) and the Telecommunications Operations and Management Committee (TMOC)were most enlightening and more than somewhat positive.
Although, Indian Wells, CA turned out to be not the easiest of places to reach in terms of airline connections it was a reasonably-priced location with access by rental car to all manner of off-hour amusements and restaurants. However, the extent of attendance was not materially different than at previous OBFs.
Overall, I believe that the IPNNI Committee continues to be “on the right track”. The committee’s approach to ordering Next Generation Network (NGN) services and for Call Detail Record (CDR) charging specifications were both given a boost as a result of OBF#106.
As pointed out in my last report, the PTSC and TMOC are standards-setting bodies for everything that is network and while the IPNNI comes at defining the Next Generation Network (NGN) from a very different perspective, meaningful dialogue did take place among the groups. This is not to say that there was no controversy
The issues surrounding the NGN in terms of an “N-1” vs end-to-end approach were not changed materially as a result of AMOC 2009 but there was what I would call a tacit acceptance by the network types of the need for the work that the OBF IP-NNI Committee is doing.
On the other hand, the challenge that is present in attempting to read, digest and apply the mountain of documentation that has existed for some time on the underlying Session Initiation Protocol (SIP) in combination with both Diameter and IPDR streaming protocols is daunting, at best.
In fact, I am struggling to balance the requirements of my “day-job” with the need to invest a sizable chunk of time in just getting up-to-speed with the basic signaling technology underpinnings of what we are referring to as NGN.
AMOC 2009 did little to resolve the dispute between the PTSC and TMOC over whether Diameter or the IPDR streaming protocol should be the basis for NGN event/session charging elements. The PTSC position remains fixed on the Diameter protocol which is widely used today in the mobile/cellular services world. As reported previously, Diameter has been endorsed by the international 3GPP standards bodies as well as the International Telecommunications Union (ITU-T) as the primary signaling protocol for AAA and mobility management in the IP Multimedia Subsystem (IMS).
The TMOC, on the other hand, now recognizes at least that its insistence that the Diameter protocol lacks efficiency and satisfactory performance and therefore Internet Protocol Detail Record (IPDR) streaming protocol is the better choice for which protocol should drive NGN event/session charging puts it in direct opposition to the position of the PTSC and other international standards bodies.
As a result, TMOC will begin to address the issue and provide direction on how the two charging protocol alternatives can be managed as alternate choices in the telecommunications operations environment.
In the meantime, I offer the following inventory of documents that the IP-NNI Committee has identified as being necessary precedents for whatever work is done in documenting NGN charging and record exchange standards. All of these documents are available on the Internet.
As more documents and use case diagrams become available, I will pass them along for your consideration and use as appropriate.
The OBF IP-NNI Committee intent is to put together a single overview document as described in Issue Number 3314 which will serve as the basis for more detailed definition and design by OBF companies. Whether this new document is made part of Multiple Exchange Carrier Access Billing has not been determined yet.
The ball is now definitely in our court and time will tell if the OBF can rise to meet the challenge of what is required.
- [Top of Page]
R.I.P. POTS - or Not?
Courtesy of
Voice Report
In a world of digital T-1s and VoIP, the lowly analog POTS line seems like a dinosaur slowly plodding toward extinction. But are POTS lines really becoming obsolete, or is the situation more aptly characterized by Mark Twain’s quote, “The reports of my death are greatly exaggerated”?
Believe it or not, there are instances where POTS lines make sense in today’s digital and wireless environment. Here are just a few examples:
Emergency and Bypass Phone Lines
If you lose electricity at your site, your PBX will shut down and you will lose telephone services (unless you have battery backup). With analog (POTS) lines, the telephone company provides electricity. That is why your landline still maintains power and you can place calls when you lose electricity at your home.
Some companies will use their digital T-1s as their primary means to receive/place calls. They will also have a few analog circuits connected to their PBXs. They have programmed their PBXs so these analog lines are automatically connected to specific, designated (bypass) phones if (when) the PBX goes down.
Click Here for the full story.
- [Top of Page]
Offbeat News:
Prototype Nokia Phone Recharges Without Wires
Courtesy of Yahoo Tech
Pardon the cliche, but it's one of the holiest of Holy Grails of technology: Wireless power. And while early lab experiments have been able to "beam" electricity a few feet to power a light bulb, the day when our laptops and cell phones can charge without having to plug them in to a wall socket still seems decades in the future.
Nokia, however, has taken another baby step in that direction with the invention of a cell phone that recharges itself using a unique system: It harvests ambient radio waves from the air, and turns that energy into usable power. Enough, at least, to keep a cell phone from running out of juice.
Click Here for the full story.
- [Top of Page]
_______________________________________________________________
If you find this newsletter valuable, then please pass it on to any colleagues or friends who may benefit from this information. Thank you!
Comments? Questions? Suggestions? Please do e-mail us at info@atso.com.
Subscription Instructions:
Terms
of Use l Privacy
Statement l
Contact Us
Copyright
2010 (Advanced Technologies & Services,
Inc.) All Rights Reserved
ATS Finds Money in Your Network:
SimCall™: Revenue & Service Assurance at the Switch™ ROI Estimator
MTP™: Automation at the Switch™
AMADEUS™: CDR Mining and Analysis for Recip Comp/CABS
RCM™: Corporate Definitions of Routing and Charging Expectations