Evolution of the Network This section provides a synopsis of the various IN phases. As noted in the introduction, a number of stages have introduced additional capabilities. How they fit together into a coherent view of what currently comprises the IN can be difficult to understand. The focus here is more on the progression of the different phases and what each phase introduces, and less on the actual dates on which they were introduced. Figure 11-4 shows the progression. Figure 11-4. IN Evolutionary Progression [View full size image] The IN began with IN/1, which Bellcore introduced in the 1980s. This brought the SSP to SCP communication exchange into existence. Following IN/1, Bellcore p ublished a series of specifications under the new title, the AIN. This series of specifications included version numbers; each moved in increments towards a full realization of an IN-centric network in which the SCP had full control of service p rocessing logic at each stage of call processing. This was known as AIN 1. The AIN series created a structured call model, which evolved from a simple model in AIN 0 to a much more complete representation in AIN 0.2. When the AIN 0.1 specification was published, the ITU-T adopted the IN concept and created a set of standards known as the IN Capability Set 1 (CS-1). The capabilities of CS-1 aligned fairly well with the AIN 0.1 release. The idea was to p ublish a series of IN standards that described the set of capabilities added with each release as the IN continued to evolve, much in the same manner as the AIN incremental version numbers. The IN CS-2 was later published; it aligns with AIN 0.2 with minimal differences. More recent CS-3 and CS-4 editions have continued to expand the list of capabilities in the IN domain. The following specification series defines the ITU IN recommendations. The "x" in the series number represents a number from 1 to 9 because each suite contains multiple documents. • Q.120x— General Intelligent Network Principles • Q.121x— Intelligent Network Capability Set 1 • Q.122x— Intelligent Network Capability Set 2 • Q.123x— Intelligent Network Capability Set 3 • Q.124x— Intelligent Network Capability Set 4 • Q.1290— Intelligent Network Glossary of terms The following specifications define Telcordia AIN standards. The latter two documents define what most people in the industry refer to as the AIN 0.2 standards, even though the documents do not carry the version number in the name. • TR-NWT-001284, Advanced Intelligent Network (AIN) 0.1 Switching Systems Generic Requirements • TR-NWT-001285, Advanced Intelligent Network (AIN) 0.1 Switch-Service Control Point (SCP Application Protocol Interface Generic Requirements) • GR-1298-CORE, AINGR: Switching Systems • GR-1299-CORE, AINGR: Switch-service Control Point (SCP)/Adjunct Figure 11-5 shows the hierarchal view of IN standards. The AIN standards developed by North America have been largely adopted and generalized for global use by the ITU. The ITU standards now represent the specifications from which national variants should be based. Beneath the ITU are the AIN standards for N orth America and Europe's INAP standards. At the call model level, the ITU and AIN standards are functionally very similar. However, the TCAP message encoding between AIN and ITU remain quite different. The ETSI INAP standards use the ITU encoding, while AIN uses the ANSI TCAP encoding. Figure 11-5. IN Standards Bodies The existence of a standard does not always signify that its capabilities have been implemented and deployed. There has been a reasonably widespread deployment of IN/1, which has been superceded by the deployment of AIN 0.1 in many cases. AIN 0 saw very limited deployment because it was more of an interim step on the p ath to AIN 0.1. AIN 0.1 and CS-1 are deployed in many networks; there is a smaller deployment of AIN 0.2 and CS-2 in existence. Inside each of these releases is also a vendor implementation progression, particularly with the larger scope of capabilities in CS-1/AIN 0.1 and CS-2/AIN 0.2. Switching vendors has implemented the SSP software to support portions of the capability set over time and has responded to customer demands for the most important services. While the ultimate goal of service providers is to remove the dependence on switching vendors for services, the SSP software must be modified significantly to support the new processing logic. Having established the reasons for the IN and the progression of the various p hases, the following sections explore the major phases in more detail. < Day Day Up > < Day Day Up > IN/1 Bellcore defined the first phase of the IN at the request of a few of the Regional Bell Operating Companies and began deployment during the 1980s. This phase p rimarily used the TCAP operation codes and parameters defined by the ANSI TCAP standard but also included some private Bellcore parameters. These message codes do not provide a context of the call processing sequence as do the messages that were encountered later in the AIN network. Each message is p rocessed in an atomic manner based on the contents of the message, without explicit knowledge of what stage of call processing is occurring at the SSP. Later IN releases resolved this problem by adopting a formal call model with generic messages that are defined for each stage of call processing. I nitial Services IN/1 was only used for a small number of services—primarily number services. N umber services use the dialed number as a SAC for identifying a call that requires access to special services. The following are examples of the early services offered by IN/1. • Enhanced 800 (E800) • Automatic Calling Card Service (ACCS) • Private Virtual Network (PVN) Placing hooks in the call processing software to trigger queries to the SCP modified the SSP control logic. For example, during digit analysis or number translations, a check for the SAC would determine whether a query should be sent to the SCP. I N/1 Tol l -Free (E800) Example The E800 toll-free service, as implemented in the United States, is chosen as an example to walk through an IN/1 message flow. There are several good reasons to use this as an example. It was among the first IN/1 services available, and it has an AIN version of the same service that provides for a comparison between them. The section "AIN Toll-Free Service Example " further discusses the toll-free services and describes it for the AIN architecture. The 800 Portability Act of 1993 was a significant business driver for SS7 and, to a large degree, for IN deployment in North America. Before this act, LECs could route toll-free calls to the correct carrier based on the dialed number's NXX (where N XX represents the 3 most significant digits after 800). The 800 portability act allowed businesses to choose a different carrier for 800 service, while retaining the same toll-free number. This meant that switches could no longer statically route calls to a particular carrier based on the NXX codes. Instead, they first had to determine the carrier for the toll-free number and route to that carrier. The IN p rovided an efficient way of managing the dynamic service by having the SSP query an SCP to determine a call's carrier. The carrier could be changed at the SCP without having to update all of the network switches. The new IN-based version of toll-free service was called Enhanced 800 (E800). Figure 11-6 shows how the E800 service is implemented in the United States. Figure 11-6. IN/1 Toll-free Service This example shows the simplest case. The SCP has determined that the LEC will handle the toll-free call. The SCP returns a special Carrier Code Identification along with the destination number in the Routing Number field for completing the call. However, if the SCP had determined that another carrier were to handle the toll-free call, that carrier's Carrier Code would be returned with the original dialed number in the Routing Number field. Rather than routing the call based on the routing number, SSP A would then route the call to an SSP in the carrier's network based on the carrier code. The carrier would perform another query to determine the call's final routing number. Because IN/1 does not define a formal call model, hooks are placed at some point in the call processing software to provide the necessary information for routing the call. As shown in Figure 11-7 , when the 800 SAC is identified at SSP A during digit translation, a query is sent to the SCP. Note that the 800 number is a service- specific code that must be recognized by the SSP. This outlines one of the important differences between IN/1 and AIN. The AIN version discussed in "The Advanced Intelligent Network (AIN 0.X, IN CS-X)" section uses a generic trigger mechanism to identify service codes. Figure 11-7. IN/1 Trigger Mechanism [View full size image] Example 11-1 shows the messages exchanged between the two nodes. These messages are representative of the requirements specified in Bellcore TR-NWT- 000533, but they can vary depending on the particular call. Be aware that the entire TCAP messages are not shown—only the key components. The following are the key components of the query that are sent to the SSP. Example 11-1. SSP Query TCAP Component Operation Family: Provide Instructions Operation Specifier: Start Parameter: Service Key Parameter: Digits (Dialed) Parameter: Digits (Calling) Parameter: Digits (LATA) Parameter: Origination Station Type (Bellcore specific parm) The query to the SCP does not contain any information that indicates the current Point-In-Call (PIC) processing at the SSP. This is another key difference between the service-specific interface of IN/1 and the service-independent interface in the later IN revisions. The SCP applies its service logic based on the incoming message and sends a response to the SSP with instructions about how to direct the call. This is the point at which the SCP logic accesses the data associated with the toll-free number and determines such information as carrier code, routing number, and billing information to be returned to the SCP. The Response message includes the following key components and parameters. Example 11-2. SCP Response TCAP Component Operation Family: Connection Control Operation Specifier: Connect Parameter: Service Key Parameter: Digits (Carrier) Parameter: Digits (Routing Number) Parameter: Billing Indicator (Specific Billing data to collect) Parameter: Origination Station Type (ANI Information digits) Parameter: Digits (Billing) When the SSP receives the Response message, it resumes call processing using the information the SCP returns to perform translations and route the call. The Query and Response messages shown are for a simple, successful toll-free query. In some instances, additional TCAP components can be sent between the SSP and SCP. For example, the SCP can send Automatic Call Gapping (ACG) to request that calls be throttled. This instructs the SSP to skip some calls and can be p articularly useful during high-volume calling. Another request that the SCP might make is for the SSP to send a notification when the call is disconnected. The SCP can include a Send Notification/Termination component in the message to the SSP for this purpose. The toll-free service can also involve messages other than the ones shown. For example, if the toll-free number is being dialed from outside of a particular service band (the geographic area within which the toll-free number is valid), a message is sent to the caller with a TCAP operation of Caller Interaction/Play Announcement. These are just examples of common message exchanges for an IN/1 toll-free service in the U.S. network and do not include all possible variations. Errors, missing data records at the SSP, and other errata have their own defined set of interactions between the SSP and SCP and are handled in the toll-free specifications for the particular network being used. . network and do not include all possible variations. Errors, missing data records at the SSP, and other errata have their own defined set of interactions between the SSP and SCP and are handled. N orth America and Europe's INAP standards. At the call model level, the ITU and AIN standards are functionally very similar. However, the TCAP message encoding between AIN and ITU remain. largely adopted and generalized for global use by the ITU. The ITU standards now represent the specifications from which national variants should be based. Beneath the ITU are the AIN standards for