For the last few days, I’ve been dealing with the stress caused by sub-standard hardware in a networked LSMS which MUST be updated before Wednesday. This slow, unpredictable, unreliable, million+ dollar piece of hardware takes approximately 8 hours to update per dbase, and there are 4 dbases (not including the main one at the LSMS, which takes about 3 or 4 hours to update before you begin the 8-hour procedure). So here’s a little description to help understand the source of my stress…
OK– A short tutorial for the techie or telecom engineer in you. The LSMS (Local Service Management System) I work on is a large Sun database consisting of multiple components in 2 cabinets with built-in redundancy (there’s a active database, and a backup). This dbase contains the information necessary to properly route calls to ported customers (customers who have changed providers but kept their numbers). All telecoms must have one, or have access to one via third-party solution provider, in order to meet the mandated requirement for LNP (Local Number Portability) set by the FCC.
How it works:
When a call is made to a ported number, a “query” is launched from the LNP-capable switch (there are several different types of switches out there, the most popular including Siemens, Lucent and Nortel) that’s supposed to “terminate” the call. There are 2 ways a switch can know to launch a query to route a call to a ported customer– (1) The first six digits (known as the NPA-NXX) are identified in the switch as being portable, so every call made to a number with those six digits at the beginning forces the switch to launch a query to an LNP dbase, or (2) the switch is set up to launch queries to an LNP dbase on every number the switch terminates calls to.
This query goes to the STP, which is a network “gateway” for telecom service providers. In the STP, there is a DSM card, or database line card, that contains either all the information that is in the LSMS, or information filtered specifically for the switches that STP services. If the number being queried is ported, it will be in that dbase with an “LRN” (Location Routing Number). The LRN looks like a plain old 10-digit telephone number, but it acts as an address for the ported customer. So it may identify the customer as being serviced by any provider within that code-owner’s “rate center”. A code-owner is whoever actually owns all the numbers beginning with a specific NPA-NXX.
That info (the LRN) is returned to the switch trying to route the call so it will know where the customer actually is in order to send it to the correct service provider, who will terminate the call (ring the called party’s phone).
That’s all there is to it. The NPAC (Number Portability Administration Center) has this information, these LRNs (along with information necessary for other SS7 services) for every ported number in the US, seperated into 8 neat regions in order to optimize dbase space (1 of the 8 is Canada, which I never have to deal with).
Each service provider has access to an LSMS which downloads the info they need from the NPAC in “real time.” The LSMS, in turn, updates the dbase cards in the STPs with said information, and those cards provide the info to switches in order to properly route calls as needed (ever time a “query” is launched).
Sounds simple, right? Well… Not exactly. You see, telecoms get bought out every day, and in order to properly route calls to numbers they ported, or for the new provider to port more numbers that belonged to that carrier, Several changes have to be made to the information at the main NPAC dbase (mostly with correctly identifying who owns those NPA-NXXs and LRNs). Also, carriers who maintain their own LSMS must know to update their information, as well. This takes alot of time. Because of instances like this, and the occasional failure of the LSMS to get updates in real time, one must monitor the LSMS daily to make sure everything is working properly and all the info is up-to-date. As if that weren’t enough, unpredictable problems crop up like not being able to update one specific network element without updating it’s redundant twin first, and not knowing which one that is until the update fails, or simple network latency, or problems associated with the stability of the admin console, etc. It keeps you on your toes.
That’s my primary job description. I do other stuff, too, as I work in a very small department responsible for the reliability of SS7 in our network (you’ll just have to look up SS7, there’s not enough space here to describe). I don’t have to work on it every day, but I have had to work on it for the past week and a half. Hopefully, I’ll only be doing routine maintenance over the next few weeks so I can concentrate on some other tasks, like reports, number pooling, customer service associated with porting, SS7 troubleshooting, etc.
VS. 
