Signaling System #7, Fifth Edition (McGraw-Hill Computer Communications Series)
| Chapter 10 Local Number Portability | ||
| By far the biggest project to ever hit the telephone industry has been Local Number Portability (LNP). Never before has anything this big been attempted in such a short time frame. There are a lot of questions and issues surrounding LNP, as well as a lot of uncertainties. | ||||
| LNP was defined in the Telecommunications Act of 1996 as the "ability of users of telecommunications services to retain, at the same location, existing telecommunications numbers without impairment of quality, reliability, or convenience when switching from one telecommunications carrier to another." | ||||
| The Telecommunications Act mandated that all telecommunications service providers provide, to the extent technically feasible, number portability in accordance with the requirements prescribed by the Commission. LNP got little attention until the FCC issued a mandate in June of 1996, requiring the implementation of LNP according to a very aggressive schedule. Rather than cite the specifics of the FCC mandate (FCC Docket 95-116), I will leave it to the reader to review the mandate itself, which is being published in three different phases. However, it should be understood that LNP affects everyone involved in wireline and wireless industries. | ||||
| Following are some highlights from the FCC docket: | ||||
| The solution must support existing services and features. | ||||
| LNP must use the existing numbering resources efficiently. | ||||
| LNP cannot require subscribers to change their telephone numbers. | ||||
| There can be no unreasonable degradation in service (such as call setup delays) or network reliability degradation when subscribers switch carriers. | ||||
| No carrier can have a proprietary interest. | ||
| The LNP solution must be able to accommodate location and service portability in the future. | ||||
| There can be no significant adverse impact outside areas where number portability is deployed. | ||||
| The intent of LNP is to open up local telephone service to competition. The authors of the Telecommunications Act feel that the biggest roadblock to competition is the ownership of telephone numbers. Subscribers are reluctant to switch to a new service provider because they have to give up their telephone numbers when they switch to a new service provider. LNP allows subscribers to switch to a new provider while keeping their existing telephone numbers. | ||||
| This presents a huge challenge to the telephone industry. Until now, routing of telephone calls has been based on the first six digits of the telephone number (NPA-NXX, or area code and office code). If a subscriber moves to a new area, or elects to change service providers, this is no longer possible. The telephone switches once identified by the old numbering plan are suddenly faced with servicing numbers from other service providers. | ||||
| If a subscriber moves across the country, the problem becomes more complex. Telephone equipment and software throughout the network have been designed to use the telephone number to determine the geographical location of subscribers. For example, everyone knows that the 212 area code is Manhattan. However, with LNP, a subscriber with a 212 area code could live in California. This problem is compounded when one looks at billing systems, operations support systems (OSSs), and other network subsystems which all rely on the numbering plan for determining a caller's geographic location and service provider. | ||||
| This chapter will outline the impact of LNP on the telecommunications industry, how it works, and how SS7 is used to implement LNP for both wireline and wireless networks. | ||||
| Introduction | ||||
| There are three phases to LNP. The first phase, service provider portability, is being implemented now. This allows a subscriber to select a new local service provider while keeping their existing telephone number. It also allows a subscriber to move within their rate center while maintaining the same telephone number. | ||||
| The next phase of LNP is service portability. This allows subscribers to change the type of service they have while keeping their telephone numbers. For example, if a subscriber changes from a POTS line to an ISDN service, he or she has to obtain a new telephone number, because the switching equipment used to provide the ISDN service supports a different block of numbers. With LNP, the subscriber does not have to give up the telephone number when changing the type of service. | ||
| The most difficult phase of LNP is location portability. This will allow a subscriber to move from city to city, or even state to state, while maintaining the same telephone number. This has a much more global impact. Even subscribers are accustomed to associating geographical areas with telephone numbers. It will be difficult for anyone to determine where he or she is calling once location portability is implemented. | ||||
| Currently, porting is only supported within a rate center. A rate center is a geographic area, usually within a LATA, which is used for determining the time and distance used in billing of phone calls. Rate centers are determined by using (V)ertical and (H)orizontal coordinates. Porting a number outside of a rate center will present many technological challenges in itself, and is being addressed in later implementations of number portability. | ||||
| The Telecommunications Act of 1996 and the FCC mandate (docket 95-116) do not specify exactly how LNP is to be implemented. They simply outline the ground rules to be used when implementing it in the network. The first trial of LNP took place in Illinois, under the direction of the Illinois Commerce Commission (ICC). The ICC specified some rules regarding the actual implementation, such as using a LRN. These have been published in the AT&T specification FSD 30-12-0001. These implementation requirements have become the de facto standard for LNP and have been widely accepted throughout the industry. | ||||
| LNP Impact | ||||
| There have been several proposals for providing LNP, without implementing a database solution. The first solution was call forwarding. This was quickly rejected by the FCC as an interim solution because of the delay imposed on the calling party while the carriers tried to route the call. The FCC did not want subscribers punished for changing providers and it has stringent requirements regarding the level of service provided to subscribers when they switch carriers. | ||||
| Another approach was Query-on-Release (QoR). When a call is routed to a number that has been ported, the receiving switch identifies the number as being vacant, and returns as SS7 REL with an appropriate cause code. The originating switch would then initiate a database query to determine if the number had been ported. This approach certainly reduces the traffic across the SS7 network, and lessens the impact of the database queries, but again it places unnecessary delays on setting up of telephone calls to subscribers who have changed carriers. QoR was also rejected as an interim method. | ||
| The solution that was chosen was the LRN method. The end office switches in the rate center have a table identifying all NPA-NXXs, which have numbers in them that have been ported. The specific number is not provided in the database, so the switch must initiate a query if it is determined that the number dialed was to an NPA-NXX considered as ported. | ||||
| The database provides a Location Routing Number (LRN), which is explained later when we discuss call flows. The LRN method places a higher demand on the SS7 network, but ensures there is no degradation of quality or service for the subscriber who changes carriers. Unfortunately, LRN also imposes huge unrecoverable costs on telephone companies. | ||||
| There has to be some event that causes a query to take place. The industry has agreed that IN/AIN triggers should be used to initiate queries. A trigger expands the call processing capabilities of switches by triggering defined events to take place (like initiating an LNP query) when specific criteria are met. For example, if received dialed digits equal a specific value a query is sent to obtain additional routing instructions. This will require software upgrades in all switching equipment to support IN/AIN triggering. | ||||
| To understand the impact that LNP has on the telephone network routing, you must first understand how networks treat telephone numbers. The first usage of telephone numbers came with the early manual switchboards. Local town operators were finding it difficult keeping up with all of the town's citizens by name. In those days, if you wanted to call someone, the operator had to connect the call for you. There were no telephone numbers; everyone was known by name. It was a doctor who first suggested using a numbering system instead of names, using his own practice as an example (doctors maintain an elaborate and numbered filing system to maintain patient records). | ||||
| The early telephone numbers were sometimes given names for the "exchange" they served. The first three numbers after the area code were given letters; those letters identifying the exchange the telephone number resided in. The exchange was the area that a particular telephone switch (or group of telephone switches) served. For example, in my study is an antique telephone from an office in Los Angeles, with the exchange "MAD" for Madison exchange still on its dial. | ||||
| Over time this changed, and the names were lost, but numbers continue on. Telephone switches are assigned blocks of numbers, with the first three digits (office code) identifying the particular switch or central office the subscriber number is served by. When calls are routed, only the first six digits are used (area code/office code, or NPA/NXX). When the call is delivered to the correct destination central office, the switches recognize the office code as their own and route the call by the last four digits (the subscriber number). | ||||
| Likewise, billing systems use the telephone numbers in much the same way. Telephone companies established rate centers by dividing the "exchanges" into geographical areas. These areas could be measured for distance by using (H)orizontal and (V)ertical coordinates. When a call is placed, the area/office code is used to determine if the calling party is making a local or a long-distance call. If it is long distance, the charges are applied according to a complex formula using the H/V coordinates. What happens if you take that telephone number and use it in another city? You can begin to see the complexity now of Local Number Portability. | ||||
| This complexity is even more severe when you examine the wireless network. Cellular providers face a greater challenge ahead because of the very nature of their networks. Subscribers are already "portable," moving from cell site to cell site. Their billing is determined by a completely different plan and does not match the same system used by wireline providers. | ||||
| Each subscriber is assigned to a "home" Mobile Switching Center (MSC), which falls within a specific wireline rate center. If a mobile subscriber calls a wireline number, the billing is determined by the distance from the MSC to the wireline number. However, that same subscriber could be roaming (outside their home area), making the billing more difficult. Previous to LNP, the cellular subscriber's mobile identification number (MIN) has been used for determining the home MSC and how they would be billed for calls when roaming. If they take that MIN to another cellular provider, it becomes even more difficult to determine what charges should be applied. The MIN is also used for identifying the carrier providing the wireless services. The first six digits of the MIN identify the service provider for that subscriber. This means the MIN can no longer be used for call processing, because the MIN cannot be ported. | ||||
| Wireless networks rely on the MIN for call processing, billing, and virtually every transaction related to a mobile subscriber. However, use of the MIN to address portability would require too many database queries, and impacts global title databases. The wireless industry has elected to change the identification of mobile subscribers by assigning two numbers; the mobile directory number (MDN) and the mobile station identifier (MSID). The MSID can use the MIN format, but the MSID is not portable. The MDN is portable. This changes the way call processing takes place in the wireless networks, impacting virtually every element in the wireless network. | ||
| In international cellular networks, the MIN is not recognized. Instead, networks use what is called the international mobile station identifier (IMSI), which is recognized in any network overseas. These networks are usually based on GSM technology. Cellular providers in the United States have been preparing to change from MIN format to ISMI format, so they could support international roaming. LNP offers an opportunity to use the IMSI format when assigning MSIDs to mobile subscribers. | ||||
| Another impact on wireless networks will be the method used to query databases. Wireline networks have agreed on the IN/AIN triggers for querying databases; however, wireless networks do not necessarily support IN/AIN. The industry is looking at IS-41 and GSM protocols for querying the LNP database. This will place a burden on developers of LNP products, who must be able to support all solutions for both wireline and wireless. Both the IS-41 and GSM protocols are being modified to support additional parameters for LNP. | ||||
| Suffice it to say there are a number of issues surrounding the implementation of LNP in both the wireline networks and the wireless networks. A lot of these issues have been resolved; some are still being investigated. What is clear is that the networks can no longer rely on the telephone number for routing, billing, and network operations. This means that millions of dollars will be spent changing the software in existing equipment and adding new hardware (such as databases, and data links to access those databases) to make LNP work. | ||||
| In addition to changes in the network equipment, SS7 has been modified as well. The solution to LNP has required new parameters to the protocol, mostly in the area of ISUP. Additional information is now required to route calls. The solution agreed upon by the industry was the assignment of a new number, called the LRN. The LRN is assigned to each end office, using the same existing numbering plan in place today. In most cases, if an end office serves, say, the 919-460 area, NPA-NXX; its LRN would be 919-460-0000. This preserves the concept of associating routing with geography, but does require changes to routing tables and software. We'll discuss how this all works a little later. | ||||
| Not all networks support SS7. There are still some networks that rely on multifrequency (MF) signaling. There are interworking procedures defined when SS7 networks must internetwork with MF networks, however, there is an efficiency problem introduced with LNP. | ||||
| If an MF network becomes part of the call path, the information contained in the ISUP IAM message cannot be transferred across the network. This means all LNP data will be lost. If there is an SS7 network on the other side (in other words, the MF network is in between two SS7 networks), then the SS7 network receiving calls routed from the MF network must initiate another query to an LNP database to determine how the call is to be routed. | ||||
| This introduces additional delay on processing the call, and introduces the risk that the call may be handled improperly if for some reason the query cannot be performed at the receiving SS7 network. These conditions are still under study, and procedures are being established for handling calls with MF signaling networks. | ||||
| Databases and operations support systems (OSSs) used throughout the SS7 network face changes. Many of these systems rely on specific fields within the SS7 ISUP messages, which have now been modified to support LNP. These systems will have to be upgraded to understand the new message format. For example, calling number delivery depends on the ISUP IAM calling party field. This may no longer be the actual directory number of the person calling, but the LRN of the calling party's exchange. There are many similar scenarios, all of which have been defined in the Bellcore specification GR-2936-CORE. | ||||
| Congestion within an SCP is a real threat, especially with so many queries being made for LNP. Automatic call gapping (ACG) has been identified as the method for preventing SCP congestion. ACG defines how long (duration) and how often (intervals) transactions should be placed under control. ACG will be supported in both wireline and wireless networks. | ||||
| The FCC mandate provided a schedule for the implementation of LNP. This schedule has been extremely aggressive, and by the time this book has been published, most of the LNP milestones will have been met. The mandate required LNP to be demonstrated within the top 100 MSAs by December 1998. However, the FCC issued a deployment schedule starting as early as October 1997. LNP must be fully operational in the top 100 MSAs by June 1999. | ||||
| Wireless service providers were issued a reprieve, and have until December 1998 to be able to route calls to ported numbers, and June 1999 to have LNP implemented in the top 100 MSAs. They have 9 months to implement LNP when they are requested by another carrier to provide number portability. This means that if a carrier loses a subscriber to another carrier, and that carrier requests the number to be ported, the wireless provider has 9 months to make that happen. Wireline service providers were given 6 months after a request to implement LNP. | ||||
| Smaller service providers are allowed to file for exemption from LNP under certain conditions. If the carrier has fewer than 50,000 access lines, they can be exempt from the LNP requirements. There are other conditions that must be met as well, all published in the FCC mandate. | ||||
| Of major concern to all carriers is the responsibility of sending a query to an LNP database. A carrier could have a subscriber place a call to a number that has been ported, and if they do not have LNP in their network, route the call as normal. The receiving network would be unable to connect the call, because the number would be found as vacant in the switch's database. The receiving network would then be left with the responsibility of sending a query to an LNP database to see if the number had been ported. | ||||
| This impacts other networks and shifts the fiscal responsibility on other carriers, which the FCC mandate clearly cited as a violation. To prevent this type of "dumping," the industry has agreed on an N-1 scheme. The next to the last network in a call route is responsible for making the database query. For example, if there are only two carriers involved in routing a call, the originating network is responsible for sending the database query. | ||||
| If there are several networks involved in routing and connecting the call, the next to the last network (which would be a long-distance carrier) is responsible for sending the database query and routing the call to the appropriate network. This approach is the most equitable way to prevent carriers from dumping calls on other carriers and makes everyone responsible for implementing LNP. | ||||
| The LNP Elements | ||||
| There are several elements required in the network to support LNP. Figure 10.1 shows the general architecture of the LNP network. Each of the elements is described in the following text. | ||||
| Number Portability Administration Centers (NPACs) | ||||
| The Number Portability Administration Center (NPAC) is managed by a third-party company with no interest in the telephone business. | ||||
| Figure 10.1 | ||||
| There are presently two corporations responsible for the management of NPACs, Martin Marietta and Perot Systems. The NPAC is responsible for receiving requests from carriers (recipient carriers) for the porting of telephone numbers (from donor carriers). They then coordinate the porting of the number by sending the data to the donor network, confirming the request has been accepted, and then downloading the ported number data (which is the new LRN for the telephone number, and other routing information) to all of the other networks connected to that NPAC. | ||||
| There are seven NPAC regions, roughly aligned with the regions designated for the Bell Operating Companies. Perot Systems manages the Southeast, West, and West Coast regions. Martin Marietta manages the Midwest, Southwest, Mid-Atlantic, and New England regions. The NPAC network includes a service order administration (SOA) system as well as a service management system (SMS). Their functions are the same as described next. | ||||
| Local Service Order Administration (LSOA) | ||||
| All order information regarding a number being ported is sent to the service order administration (SOA) system. The SOA is used to process a subscriber's order and track the order through completion. It provides all departments a single record location regarding a service order, and is used to coordinate and track service order activities. | ||||
| In the case of LNP, the subscriber data includes the LRN of the serving (donor) carrier, the date/time the number is to be ported to the new carrier (recipient), and other pertinent information. The SOA communicates this information to the SOA in the NPAC, which in turn passes the information to the SOA in the donor network. | ||||
| It is important to understand that the only purpose of the SOA is to track the activities of an order, and in the case of LNP, provide the specifics about when a number is to be ported, and who the donor network is. Some of this information will be used by the billing center, while some of it is passed to provisioning systems to be configured in switches and databases in the new network. | ||||
| Local Service Management System (LSMS) | ||||
| Each carrier has an Local Service Management System (LSMS), which serves as the interface between the carrier networks and the NPAC. The LSMS is responsible for collecting porting data and downloading it to the LNP databases. The LSMS is usually a computer system with database storage, and must be able to verify the data within the database with the data stored at the NPAC. This is accomplished through periodic audits between the LSMS and the NPAC. | ||||
| Likewise, the LSMS also audits the LNP databases within its own network. It is crucial that the data is accurate. If there are discrepancies in the data, then telephone calls cannot be completed to ported numbers properly. The computer systems used for LSMS must have high reliability, and in many networks, they are deployed as mirror systems. | ||||
| A mirrored system is one where a duplicate LSMS is placed in a different geographical location, but contains a mirrored image of the data at its mate system. This configuration provides diversity within the network. Diversity is as crucial with LNP as it is within other parts of the SS7 network. | ||||
| The industry standard interface used between the LSMS and the NPAC is a Q3 interface, using the OSI stack for communications. The protocol used to communicate between the two entities is CMISE and ROSE. The communications protocol is used at the network layers of Q3 and TCP/IP. | ||||
| The interface between the LSMS and the LNP database has not yet been standardized, but Bellcore is actively working on defining Q3 as the interface between these two entities as well. Most systems being implemented today are using this Q3 interface between the LSMS and the LNP database. | ||||
| LNP Database | ||||
| The actual database used to maintain LNP data can be one of two types; a Service Control Point (SCP) or an integrated Signal Transfer Point (STP). The integrated STP solution is more favorable in many cases because of the throughput modern STPs can provide in comparison to SCPs. The top of the line SCP is only capable of 850 transactions per second, while some newer STPs are capable of 20,000 transactions per second and higher. | ||||
| The actual throughput requirement of the database itself will depend on the calculated number of database queries to be performed. To calculate the number of queries (transactions) per second, remember that every call made to an NPA-NXX with a directory number that has been ported will require a database query. This can be significant in some areas. | ||||
| You also have to factor in the average message size of an LNP query. LNP queries average around 120 bytes in length, so if you are using 56-kbps links, you can transmit approximately 58 messages per second, if your link is transmitting at 100% of its capacity (56,000/[120 8]). This of course is never the case, since links are engineered to transmit at 40% capacity. Actual throughput of a 56-kbps link with LNP message size of 120 bytes would be more like 23 LNP transactions per second. | ||||
| Summary | ||||
| These are the basic elements used in an LNP network. Notice that nothing was mentioned about STPs, or SCPs for that matter. The database function itself can reside in either an STP or an SCP. The only connection to the SS7 network provided is the database itself. The LSMS does not connect to the SS7 network, and neither does the NPAC. All communications between these entities is through a private communications link, using Ethernet and TCP/IP protocols. | ||||
| The SS7 network uses the information provided by the LNP database to route calls through the network. This function is much like the database function used in 800 services. Figure 10.2 illustrates the relationship between the SS7 network elements and LNP elements. | ||||
| Now that we understand the elements needed to implement LNP, let's look at how LNP works, first in the wireline network and then in the wireless network. We will review the role of each of the elements in these discussions as well. | ||||
| Figure 10.2 | ||||
| The Wireline Solution | ||||
| In the wireline network, LNP is simpler. This is because the subscribers are all fixed in location. In the wireless network, the subscribers are mobile, making billing applications and OSSs more complicated. Before discussing the specifics about how a number is ported and then routed, let's first look at the changes made within the SS7 ISUP protocol to support LNP. | ||||
| The ISUP IAM message has been modified to include information regarding a ported number. The most significant change is the placement of the LRN. The called party number field is no longer the directory number of the called party, but now is the LRN of the called party if the called party directory number has been ported. The directory number of the called party is moved to the generic access parameter (GAP) of the IAM message. The type of address parameter in the IAM message is ''ported number." | ||||
| The forward call indicators (FCI) field of the IAM now includes a "translated called number field." This 1-bit parameter in the 8-bit field is used to indicate whether or not a number has been translated. This is used by switches to determine if a query is needed, and whether or not routing should be based on the GAP parameter or the called party number field. Even if a number has not been ported, the forward call indicators will still indicate "number translated." | ||||
| The jurisdiction information parameter (JIP) is used for billing purposes. The LRN of the originating end office is placed in the JIP field. Billing systems can then determine how the call is to be processed. Only the first six digits of the LRN are needed. | ||
| Now that we understand the modifications to the SS7 protocol, let's look at how telephone numbers are ported and how calls are routed to ported numbers. | ||||
| Porting a Number in the Wireline Network | ||||
| When a subscriber places an order with a competitive local service provider (recipient carrier), it is up to the new carrier to send a request to have the subscriber's telephone number ported. The request is sent from the recipient network LSOA to the NPAC SOA. The NPAC SOA is then responsible for notifying the original carrier (donor carrier) of the request. | ||||
| The NPAC sends the request down to the donor carriers LSOA, which then verifies the number, is currently assigned in the network, and then confirms receipt of the porting data. The porting data consists of the subscriber's telephone number, the date and time the number is to be ported, and the LRN of the recipient carrier. The NPAC then forwards the confirmation back to the recipient carrier's LSOA. | ||||
| The NPAC then sends the porting information to its own LSMS, which then distributes the porting information immediately down to all of the LNP databases within its region. The number has now been ported and the actual switch from one carrier's switching equipment to the other takes place according to the porting data. Obviously, coordination between the two carriers is critical in order to prevent the subscriber from being disconnected by his or her original carrier before the recipient carrier can active service. | ||||
| The donor carrier is not responsible for notifying the recipient carrier of the services in the subscriber's profile. It is still the responsibility of the subscriber to notify the recipient carrier which services they want to have when they port. If the subscriber disconnects his or her service at any time, the telephone number is returned to the donor carrier (until the LNP service matures and number assignment becomes more universal). | ||||
| Routing a Call with LNP in the Wireline Network | ||||
| Each end office switch is assigned a 10-digit LRN. Each switch is required to support at least two LRNs (in the event the switch previously serviced more than one NPA-NXX). This LRN consists of the same area/office code previously assigned to the end office. The last four digits are typically all zeros. By using an LRN, the existing numbering plan can be utilized. Routing is based on the LRN instead of the dialed telephone number when a number has been ported. | ||||
| When a number is dialed, the originating switch looks up the NPA-NXX of the number in a table. This table will indicate whether or not the NPA-NXX is considered as ported or not. If even one telephone number within an NPA-NXX is ported to another carrier, then the entire NPA-NXX is considered ported. This means every phone call to that NPA-NXX requires a database query, to determine whether or not the dialed number has actually been ported to another carrier, and if so what the LRN of the new carrier is. | ||||
| Before we continue discussing routing, we need to understand why the end-office switch only knows about the NPA-NXX and not the subscriber number. It would be easy to store routing information about every number in the end-office switch, alleviating the requirement to access a database. However, propagating this information to many switches and maintaining that data is a different story altogether. | ||||
| The alternative is to query a database on each and every call, but the impact to SS7 is too large, and the capacities of almost every network would seriously be taxed. It was for these reasons the industry elected to use the LRN method for routing, and propagating only the NPA-NXX information in the individual switches. The impact on networks is still high, but the solution is a compromise to more costly methods. | ||||
| If an end-office switch determines that a number belongs to a ported NPA-NXX, it originates a query to the LNP database (provided the switch has been equipped with that capability). In the event the switch has not been equipped to perform LNP queries, the call is routed as normal through the network to the donor carrier. When the call reaches the donor network's end office, the switch will determine that the call cannot be completed, because that switch no longer services the dialed number. The directory number will appear as vacant in the end-office switches database. | ||||
| The question is then raised as to who is responsible for originating an LNP query. It would be very easy for carriers to simply route calls to neighboring networks without performing queries, thereby alleviating the need to implement any method of LNP in their own networks. Simply let the neighbors bear the cost of implementation and pass all your traffic to them. The FCC recognized the potential of call dumping and passed a ruling, that the next to the last carrier (or network) was responsible for originating the LNP query. This is known as the N-1 method. If there are only two carriers involved in the call setup, the original carrier is responsible for originating the LNP query. | |||
| The LNP database will provide the LRN of the servicing carrier if a number has been ported. This information is placed in the SS7 ISUP message using the called party parameter. The actual called party directory number is moved to the GAP. This is one of the reasons upgrades to virtually every network node in the SS7 network is required to support LNP; ISUP messages have been modified to support this feature. The ISUP parameters that have been modified have been discussed. | ||||
| Let's look at a typical call to a number that has not been ported, but is in an NPA-NXX considered "portable." Figure 10.3 shows an example of the call flow in the case of a nonported number. | ||||
| In Figure 10.3, the calling party dials the number (919) 460-2100. The end-office switch servicing the called party identifies that particular NPA-NXX as one that has been ported. The end-office switch then originates a database query to the LNP database. | ||||
| Figure 10.3 | ||||
| The query is sent to the STP, which then examines the address information in the SCCP portion of the message to determine how to handle the query. The SCCP portion of the message identifies the type of database to direct the query to, if that is known. If the end-office switch does not know the network address of the database, the STP can perform a global title on the SCCP portion to determine the type of query and the database to send the query to. | ||
| The LNP database checks the database, and determines that the called number (919) 460-2100 has not been ported to another carrier, and returns the query results to the end-office switch. The end-office switch then routes the call based on the called party address field in the ISUP message. The call is connected. | ||||
| This is an example of how a call is connected to a nonported number. Now let's look at how a call gets connected to a ported number. In Figure 10.4, a call is made to (919) 460-2100, but this time the called party has switched carriers, and their number has been ported to the new carrier. | ||||
| Figure 10.4 | ||||
| Again, the end office has determined that 919-460 is a ported NPA-NXX, and initiates a query to the LNP database. The LNP database looks for the dialed number in its database. A match is found, and the LNP returns the results back to the end office. | ||
| The end office now has the information needed to route the call. The call is routed based on the LRN instead of the called party number. The originating end office generates an ISUP IAM message with the LRN placed in the called party address field, and the dialed number in the GAP parameter. The JIP parameter identifies the NPA-NXX to be used for billing reference. | ||||
| The call is routed to the recipient network, which routes the call to the subscriber using the dialed digits in the GAP parameter. Billing systems to determine the origin of the call use the LRN in the JIP parameter. The calling party number was used to determine the geographic-specific digits needed by billing systems previous to LNP. | ||||
| This explains the basics of routing a call in the wireline network, using SS7 to deliver the necessary information to the network elements. The wireless network operates differently than the wireline network, and presents challenges of its own. | ||||
| The Wireless Solution | ||||
| In the wireless network, the information needed to route calls to mobile subscribers is somewhat different than what is required in the wireline network. For beginners, the number itself does not render enough information about the location of the called party. They can be anywhere in the network. | ||||
| Each mobile subscriber has a mobile identification number (MIN) which is used to identify the individual subscriber to the network. The wireless network relies on databases to locate the location of mobile subscribers, which changes as they move through the network. We won't go into details about the routing of calls in the wireless network, as that was discussed in the beginning of this book. We will look at how calls are routed using LRN in the wireless network, and the impact LNP has on the wireless network. | ||||
| A cellular telephone is a radio device. The phone must be compatible with the cell site equipment in the areas where it operates. There are cases where a subscriber will not be able to "port" his or her cellular phone. In other words, subscribers may change wireless service providers and maintain their existing telephone numbers, but they will have to buy a new cellular telephone. | ||||
| Another fundamental difference between wireline and wireless is in the billing and network boundaries. In the wireline network, boundaries are set by LATAs. The wireless industry does not recognize LATAs, and the service provider determines the boundaries. This can cause difficulty in determining how LNP is to be supported, because the ruling says that LNP must be supported within a rate center, which is not recognized by the wireless industry. The Cellular Telecommunications Industry Association (CTIA) is currently defining this. Some of the fundamentals of porting a number in the wireless network are discussed in the next section. | ||||
| Porting a Number in the Wireless Network | ||||
| When a subscriber ports to a new wireless service provider, the new carrier must provide service in the same area as the donor network. This is one of the principal requirements, since rate centers are not recognized in wireless networks. In the wireline network, the service provider had to be providing local service within the same rate center as the subscriber. | ||||
| There are other requirements before porting can be supported. The wireline rate center associated with the directory number assigned to the mobile subscriber must be in the same geographic area as the home service area of the subscriber. This is also true of wireline subscribers wishing to port their numbers to a wireless service provider. | ||||
| Routing a Call with LNP in the Wireless Network | ||||
| Routing in wireless networks is different than in wireline networks, because the subscriber is mobile. Databases must be used to locate the mobile subscriber, which results in delays in the call routing. With LNP, we are now introducing yet another database query prior to even locating the proper network. | ||||
| There are several call scenarios in wireless; land-to-mobile, mobile-to-mobile, and mobile-to-land. All are handled somewhat differently. We will start by looking at a simple mobile-to-land call. | ||||
| Figure 10.5 shows the call flow for a mobile-to-land call. When a mobile subscriber dials a number, the receiving MSC establishes a trunk connection with the PSTN. The receiving switch in the PSTN examines the dialed digits and determines that the dialed number is in a portable NPA-NXX. The switch sends a query to the LNP database using IN/AIN triggers to obtain additional routing instructions. The MSC in the serving cellular network can just as easily send this query, if the wireless provider has the capability. | ||||
| The query to the LNP database results in a response, providing the LRN to be used in routing the call. This is no different than the routing procedures used in the wireline network. The actual IN/AIN triggers have been added (Info_Analyze and Analyze_Response) in Figure 10.5. | ||||
| Figure 10.5 | ||||
| Once the switch has the routing information it needs, it generates an ISUP IAM message containing the LRN, dialed number, and the mobile directory number that originated the call. This call flow is not the same when a call is made land-to-mobile, as you are about to see. The location of the subscriber must be obtained first. | ||||
| In Figure 10.6, we see the events that take place in a land-to-mobile call. The end-office switch initiates a query to the LNP database, sending the mobile directory number (MDN). The LRN is returned (if the mobile number has been ported), and the end office establishes a trunk connection with the mobile's home MSC. Notice the IAM Figure 10.6 provides, and the MDN, but not the MSID. | ||||
| The home MSC searches its own HLR to determine the location of the mobile station. The HLR shows the mobile station is in another network and provides the identity of the serving MSC. The HLR then sends a query to the serving MSC's VLR, which will provide location information. | ||||
| The serving VLR returns a response to the HLR, providing the temporary local number (TLDN) used in roaming. The TLDN is a temporary number assigned to the mobile station as long as it is served in the visited network. This number is then assigned to a new mobile station when the previously assigned mobile leaves the network. | ||||
| Figure 10.6 | ||||
| The HLR then sends a response to the home MSC providing the MSID, MDN, and TLDN. The home MSC can now generate the ISUP IAM. In this case, the called party number contains the TLDN, not the MDN. If the mobile station were still in its home network, this parameter would contain the MDN. | ||||
| These call flows have been simplified considerably for ease of reading. There are many other events that must take place to route calls in the wireless network. This should give you an idea how the protocol works in obtaining the necessary routing information when the numbers have been ported in wireless networks. | ||||
| Summary | ||||
| Local number portability will impact everyone. The conventional methods of routing calls are gone, and new procedures will require many modifications to our nation's networks. These changes are not just impacting U.S. networks. The international telephone companies are also looking at implementing LNP in their networks. Many international carriers have already begun choosing solutions for their networks, and have identified deployment schedules. | ||||
| Developers of telecommunications products will also be impacted, but in a positive way. Their products must be modified to support LNP solutions. As seen in our previous discussions about wireline and wireless portability, these solutions will vary. Equipment vendors must support all solutions to market products in both the wireline and wireless markets. This means supporting IN/AIN triggers as well as IS-41 and GSM protocol changes. As LNP moves forward, the subscriber will begin to feel the impact as well, but hopefully in a positive way. As subscribers, we will have many more choices available to us. We will now be able to choose whom we want to provide our local telephone service, as well as long-distance service. In many cases, service providers will provide bundled services. These bundled services will include local, long distance, wireless, paging, and even Internet access. Hopefully, as more competition enters the market, we will also see reduced prices for these services. Don't count on substantial savings, however; these network changes cost millions of dollars, and LNP alone is costing some telephone companies billions of dollars to deploy. These costs have to be recouped somehow, and always trickle back to the subscriber. | ||