Summary TCAP provides a standard mechanism for telephony services to exchange information across the network. It is designed to be generic so it can interface with a variety of services. TCAP resides at Level 4 of the SS7 protocol and depends on SCCP's transport services. It is comprised of a transaction sublayer and a component sublayer. The transaction sublayer correlates the exchange of associated messages, while the component sublayer handles the remote operation requests. All information elements in the TCAP message are defined and encoded using the syntax and BER of ASN.1. The ITU Q.771—Q.775 series of specifications defines the TCAP protocol. Specifications such as the ETSI.300.374 INAP series build on the ITU Q Series Recommendations to provide additional information needed for implementing network services. The ANSI T1.114 defines the TCAP specifications for ANSI networks. ANSI defines a number of national operations and parameters on which basic services can be built. Similar to ITU, many specifications build upon the basic TCAP provisions as defined in T1.114. For example, the Telcordia GR-1298 and GR-1299 AIN specifications provide the N orth American equivalent of the ETSI INAP service framework for IN services. TCAP traffic on telephony signaling networks has increased in recent years because of an increase in services such as LNP, Calling Name Delivery, and Short Messaging Service (SMS), which rely on TCAP communication. This upward trend is likely to continue as IN services are more widely deployed, thereby making TCAP an increasingly important component in the role of network services. < Day Day Up > < Day Day Up > Chapter 11. Intelligent Networks (IN) The Intelligent Network (IN) is an architecture that redistributes a portion of the call processing, that is traditionally performed by telephony switches, to other network nodes. This chapter explores how the IN moves service logic and service data out of the SSP, and the rationale behind it. The complete set of IN capabilities has not been fully realized, but it continues to evolve and be implemented over time. It is a radical shift in architecture that requires coordinated changes by both vendors and service providers on a number of levels. Over approximately the last 20 years or so, standards have been p ublished that define a common framework to enable its adoption. A variety of terms are used to describe the various stages of this evolution: IN, IN/1, AIN 0, AIN 1, AIN 0.1, AIN 0.2, IN CS-1, and IN CS-2. The list is only partially complete, and yet it represents a number of views of the Intelligent Network (IN) concept and its progression. The Advanced Intelligent Network (AIN) is a term that Telcordia (formerly Bellcore) uses for North American IN standards that were released in the 1990s. This chapter presents the general concepts of the Intelligent Network (IN) and briefly examines the progression towards IN CS-2/AIN 0.2. The Intelligent N etwork Capability Set 2 (IN CS-2) is the set of standards published by ITU, while the Advanced Intelligent Network 0.2 (AIN 0.2) is the North American equivalent. Because it is the most recent specification that has a considerable amount of implementation at the time of this writing, the AIN 0.2 version of the IN is the p rimary focus of this chapter. N OTE The Telcordia AIN specifications dropped the use of the "0.2" version number from the specifications. These documents are simply referred to as the AIN specifications. Throughout this chapter, the term AIN 0.2 is retained. There are still AIN implementations that are only 0.1 compliant and the version number is useful to discriminate the functionality implemented by each version. Because the terminology can become confusing, the term IN is used generically throughout this chapter to represent all versions of the Intelligent Network. The term AIN is used for the North American releases beyond IN/1. When a specific version is being referenced, the version number (such as AIN 0.2) is included. The call models within this chapter are based on the ITU IN standards, while most of the message examples are based on the North American AIN standards. This chapter includes an INAP section, which provides an example of how the European region uses INAP to provide IN capabilities. < Day Day Up > < Day Day Up > The Intelligent Network In its simplest form, a SSP communicating with a Service Control Point (SCP) to retrieve information about processing a phone call demonstrates an IN. This communication is triggered in different ways, but most often occurs in response to dialing phone numbers that have special significance—such as Service Access Codes (SAC), numbers that have been "ported" by the Local Number Portability (LNP) act, or numbers that have special services subscribed to them, such as the O Called Party Busy feature (described with trigger types in the "IN CS-2/AIN 0.2 " section of this chapter). In the existing telephony network, this exchange of IN messages happens millions of times each day and is transparent to the phone user. Figure 11-1 shows a simple IN message exchange between an SSP and an SCP. Figure 11-1. Simple IN Service The communication between the SSP and the SCP takes place over the SS7 network using the TCAP layer of SS7. As the SSP handles calls, the SCP is queried for information about how to process the call. It does not happen for every call but only for those that require IN services, such as those mentioned previously. While a complete view of the IN architecture includes a number of other nodes with additional functions, these two nodes are at the core of IN processing. We begin with this minimal view to gain an understanding of how the IN model works and why it is needed. < Day Day Up > < Day Day Up > Service Logic and Data The introduction and proliferation of digital switches in the 1970s and 1980s enabled services to flourish. The computer-enabled network allowed software p rograms to process calls in a much more sophisticated manner than its electro mechanical predecessors. This led to a continual growth in features provided by digital switching exchanges. With the continual growth of features also came growth in software program complexity and the data maintained at each switch. These two areas are more formally defined as Service Logic and Service Data and are the central focus for the IN. Service data is the information needed to process a call or a requested feature. Information such as the Line Class Code, Feature Codes, Called Party Number, Routing Number, and Carrier are examples of service data. Service logic is the decision-making algorithms implemented in software that determine how a service is processed. The service logic acts on service data in making these decisions and directing call processing to create the proper connections, perform billing, provide interaction to the subscriber, and so forth. S ervice Lo g ic Until IN was introduced, vendors completely implemented service logic. Service p roviders would submit requests for features to switch vendors. If the feature was accepted, the vendor would design and implement the feature in their switching software and eventually release it for general availability to the service providers. This process was usually quite long because of the stringent standards regarding telephony reliability. From the time the request was submitted to the time it was ready for deployment, it was common for an average feature to take two years or more because of the extensive design and testing involved. Of course the development cycle varied based on the complexity of the service. The importance of this issue increased even more when the introduction of competition created a need for faster service deployment in order to effectively compete in the market. IN introduced the Service Creation Environment (SCE) to allow service providers to create their own service logic modules, thereby implementing the services they choose. This places the service provider in control of which services can be developed and how quickly they are deployed. It provides much greater flexibility, allowing customized services for specific markets to be readily created. The Service Logic Programs (SLP) created by the SCE are executed at the SCP, thereby moving a portion of the services execution environment out of the SSP. This helps to address the complexity of switching software by removing service code from an already complex environment for processing calls and switch-based features. S ervice Data Until IN capabilities were introduced in the 1980s, the service data for the PSTN resided within the telephone switches throughout the network. The expansion of telecom services and the resulting growth in the data maintained by each switching node created several issues with this architecture, including the following: • Increased storage demands • Maintaining synchronization of replicated data • Administrative overhead Service data used by services such as toll-free, premium rate, Automatic Calling Card Service and LNP change frequently, thereby causing increased overhead in maintaining service data. One of the benefits of the IN is centralizing service data in a small number of nodes. Each SSP obtains the information from a central location (SCP) when it is needed during a call's progression. This alleviates the overhead of administering data at each switching node and reduces the problem of data synchronization to a much smaller number of nodes. S ervice Distribution and Centralization The IN redistributes service data and service logic while centralizing them. As discussed, service data and logic previously existed in the telephone switch. Although the network contains many switches, each one can be considered a monolithic platform, because it contains all call-processing functions, service logic, and service data. IN redistributes the service data and logic to other p latforms outside of the switch, leaving the switch to perform basic call p rocessing. The SCP and Adjunct are two new nodes that IN has introduced for hosting service data and logic. They both perform similar functions with the primary difference being scale and proximity. The SCP usually serves a large number of SSPs and maintains a large amount of data. It is typically implemented on larger-scale hardware to meet these needs. The Adjunct is a much smaller platform that normally serves one or possibly a few local offices and is often colocated with the switch. Adjuncts characteristically use generic hardware platforms, such as a network server or even personal computers equipped with an Ethernet interface card or SS7 interface cards. This chapter uses the SCP for most of the examples, although an Adjunct can often perform the same or similar functions. The SSP uses SS7 messages to query an SCP or Adjunct for service data and processing instructions. As shown in Figure 11-2 , service logic in the SCP or Adjunct is applied to the incoming query to provide a response to the SSP with the requested information and further call processing instructions. Figure 11-2. IN Distribution of Service Logic and Service Data [View full size image] The amount of service logic supplied by the SCP has increased with each phase of the IN implementation. In the most recent phases, a call in a fully IN-capable switch can be primarily controlled from the SCP or Adjunct. < Day Day Up > < Day Day Up > IN Services There have been two primary drivers for IN services: regulatory mandates and revenue-generating features. Both toll-free number portability and LNP are examples of regulatory mandates that have greatly expanded the use of IN. The sections on "Intelligent Network Application Protocol (INAP) " and "Additional IN Service Examples" provide examples of these services. When faced with managing number portability issues where large amounts of service data must be maintained, the IN provides a logical solution. From a customer perspective, services like Automatic Flexible Routing (AFR), Time Of Day (TOD) Routing, and Private Virtual (PVN) Networking provide solutions for everyday business needs while generating revenue for service providers. Since IN has been continually evolving, some services have been implemented using IN/1, and then later implemented using AIN. In fact, every service that has been implemented using IN/1 could be implemented using AIN. However, the decision does not only depend on technology. Usually there must be a business j ustification for upgrading a working service to use newer methodologies. The IN networks of today reflect a mix of IN/1 and AIN services. Using the toll-free service within the United States as an example, Bellcore TR-NWT-533 describes toll-free service for IN/1, and GR-2892 describes toll-free service using AIN. Different messages are used in AIN than those of IN/1 so that the service implementations between the two are not compatible; however, the services themselves are functionally equivalent. For example, an IN/1 SCP does not understand AIN messages from an SSP. This is simply a result of the evolutionary nature of the IN. AIN 0.2 was developed to be compatible with AIN 0.1, so compatibility is not as much of a concern within the AIN incremental releases. The services chosen as examples throughout this chapter are only a selected few of the IN services that are available. This is not intended to be a comprehensive list; rather, it is intended to provide examples of some of the more common services and to show how they work. The very nature of the AIN SCE is to allow service p roviders to craft their own services to meet their customers' needs. This means that a number of custom services likely exist in various service provider environments. < Day Day Up > < Day Day Up > IN and the SS7 Protocol With respect to SS7, the IN is an application that uses the SS7 protocol. It is not a p art of the protocol, but is often associated with SS7 because it provides appropriate capabilities for enabling the IN architecture both at the protocol level and the network architecture level. The various IN versions are considered TCAP users functioning at level 4 of the SS7 protocol stack. As shown in Figure 11-3 , the SSP and SCP or Adjunct exchange IN messages using the TCAP layer. Throughout Europe, the Intelligent Network Application Part (INAP), developed by the ETSI standards body, interfaces with ITU TCAP for delivering IN information between nodes. In North America, IN/1 and AIN, developed by Telcordia, interface with ANSI TCAP to deliver the equivalent information. Figure 11-3. INAP/AIN in Relation to the SS7 Protocol As with any SS7 application layer protocol, IN depends on the SS7 transport without explicit knowledge of all the underlying levels. It interfaces directly with TCAP to pass information in the form of components and parameters between nodes. IN capability is, of course, dependent upon correctly functioning SS7 transport layers. . Up > IN and the SS7 Protocol With respect to SS7, the IN is an application that uses the SS7 protocol. It is not a p art of the protocol, but is often associated with SS7 because it provides. component sublayer handles the remote operation requests. All information elements in the TCAP message are defined and encoded using the syntax and BER of ASN.1. The ITU Q .77 1—Q .77 5 series of specifications. enabling the IN architecture both at the protocol level and the network architecture level. The various IN versions are considered TCAP users functioning at level 4 of the SS7 protocol stack.