Additional IN Service Examples

Two additional services are presented here to reinforce how IN operates in a real network context. The LNP service represents a government mandated service need, while the PVN demonstrates a solution to a common business need. Both services can be implemented using any of the IN versions discussed in this chapter.

Local Number Portability (LNP)

The North American Local Number Portability Act of 1996 relies on IN technology to deliver number portability for subscriber numbers. Prior to LNP, blocks of phone numbers were associated to specific exchanges. Routing of interexchange calls was based on the NPA-NXX portion of the called number. The NPA identifies a particular geographic region, and the NXX identifies the particular exchange. The long-term goal of LNP is to associate the phone number with individual subscribers, effectively removing the network node association and allowing subscribers to keep their numbers. This means that, as users migrate throughout the network, a particular SSP will eventually handle many different NPA-NXX combinations instead of just one or two. Number Portability is being rolled out in phases that are designated by three different types of portability:

• Service Provider Portability

• Service Portability

• Location Portability

Service Provider Portability is the first phase and is currently being implemented. It allows subscribers to choose a different service provider but remain within their local region. More specifically, they must remain within their present rate center, which is generally defined as a local geographic area of billing, such as a Local Access Transport Area (LATA).

Service Portability gives the subscriber the ability to change types of service while keeping their same phone number. For example, a basic telephone service subscriber can switch to ISDN service without changing numbers.

Location Portability allows subscribers to change geographical regions and take their phone numbers with them. At this point, phone numbers will not necessarily represent the geographical area in which they reside.

Because LNP is removing the association between subscriber numbers and network nodes, some means of associating a particular user with a point of network access is required. Each office now has a Location Routing Number (LRN) assigned to it that uses the same numbering scheme that existed before the introduction of LNP. The LRN uses the NPA-NXX-XXXX format to allow compatibility with the existing routing method that is used in the network. In essence, subscribers retain their numbers, while the exchange retains its primary identification number and creates a mapping between the two. This brings us to the point of IN's role in providing the LNP service. When the first subscriber within an NPA-NXX changes service providers, the entire NPA-NXX is considered "ported," which means that this particular NPA-NXX combination has become a portable number and no longer represents a specific exchange. Every call to that NPA-NXX must now determine the LRN of the number that is being called. Because all subscribers with that NPA-NXX no longer necessarily reside in the same exchange, the exchange must be determined before the call can be completed. This immediately creates two needs that are readily satisfied using IN:

• Trigger an LRN request for NPA-NXX codes that have been ported

• Maintain the relationship between subscriber number and LRN

The SSP maintains a list of ported NPA-NXX codes. When the call is being translated, the called number's NPA-NXX can be compared with the list of ported codes to determine whether a query should be sent to the SCP.

The SCP maintains the relationship of subscriber numbers to LRNs. It maps the Called Party Number sent in the query to an LRN and returns the LRN to the SSP. The SSP uses the LRN as the Called Party Number to route the call to the correct exchange and includes the real Called Party Number in the GAP parameter of the ISUP IAM so that the terminating switch can deliver the call to the subscriber. If the SCP determines that the number has not been ported, it simply returns the original Called Party Number, which the SSP uses to route the call. Figure 11-20 shows an example of a subscriber changing service providers, resulting in their DN being ported from SSP B to SSP A. SSP B is considered the donor switch because it is donating a number that once resided at that exchange. SSP A is considered the recipient switch because it is receiving a number that it did not previously have. When the subscriber at SSP C dials the 392-4000 number, SSP C performs a number translation and determines that 919-392 is open to portability. Because the number is portable and does not reside on the local switch, an IN query is sent to the SCP. The SCP returns the LRN of SSP A, which is now the home for the dialed number. The call is then routed from SSP C to SSP A using ISUP signaling. The original dialed number is placed in the ISUP GAP, and the LRN is placed in the Called Party Number (CDPN) field. For more information about how ISUP is used with LNP, refer to Chapter 8, "ISDN User Part (ISUP)."

Figure 11-20. Local Number Portability Service

[View full size image]

The LNP service can be supported using IN/1, IN CS-1, or IN CS-2 call models. Using IN/1, the query sent to the SCP contains a "Provide Instructions/Start" component, while the response from the SCP contains a "Connection Control/Connect" component. In an AIN network, it is triggered at the SSP by the PODP (AIN 0.1) or SDS trigger at the Info_Analyzed DP. The AIN response from the SCP is an Analyze_Route message. Because the query could be performed at different points in the network, the LNP standards identify the N-1 network as the node for sending the query. This is the last network to handle the call before the terminating local network.

Private Virtual Network (PVN)

The PVN is a service that uses public network facilities to create a private network. An organization with geographically separate locations can share an abbreviated dialing plan using IN to translate the dialed numbers into network-routable addresses. From the user's perspective, it appears that they are on a private network. To determine the call's routing address, the SSP that serves the originating access queries an SCP using the called number, ANI, and other information. An IN response is returned to the SSP with the new routing address and call processing is resumed.

Figure 11-21 shows a company with three locations that are virtually networked over the PSTN. The company employees can use an abbreviated dialing plan to access other locations in the same manner as on-campus calls. The number the employee dials must be translated into an address that the PSTN can route. This happens transparently to the originator of the call, using the IN network to retrieve routing information. The call can then be completed across the PSTN to the San Jose location.

Figure 11-21. Private Virtual Network Service

[View full size image]

The PVN service can be supported using IN/1, IN CS-1, or IN CS-2 protocols. Using IN/1, the query sent to the SCP contains a "Provide Instructions/Start" component, while the response from the SCP contains a "Connection Control/Connect" component. In an AIN network, the PODP (AIN 0.1) triggers it at the SSP or the SDS triggers it at the Info_Analyzed DP. The AIN response from the SCP is an Analyze_Route message.