|
|
||
|
SCORVA 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. Questions or Comments? Contact us at info@atso.com.
|
||
| Resources | ||
|
|
||
Copyright
2010 (Advanced Technologies & Services, Inc.) All Rights Reserved