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 primarily 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 processed 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.

Initial Services

IN/1 was only used for a small number of services—primarily number services. Number 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.

IN/1 Toll-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 NXX 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 provided 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.

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 particularly 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.