The Advanced Intelligent Network (AIN 0.X, IN CS-X)

The term "Advanced Intelligent Network" can be misleading. People often consider AIN a separate entity from the IN. It is simply part of the evolution of the original IN concept. AIN is a term that is primarily used in North America to describe the evolution of the IN beyond the IN/1 phase. The AIN specifications introduced by Bellcore solidified and extended the concepts introduced by the early IN standards. AIN 0 was the first version released. However, it is only given a brief introduction here because AIN 0.1 and AIN 0.2 have made it obsolete. Both AIN 0.1, and 0.2 are incremental releases toward the IN concept documented in AIN 1. As explained earlier, beginning with AIN 0.1, the ITU IN and Bellcore AIN standards align fairly well; although ITU uses the term IN and Bellcore uses the term AIN, they both describe the same general architecture and call model. The following sections discuss IN CS-1 and AIN 0.1 as well as IN CS-2 and AIN 0.2 together. Message encodings remain incompatible because of the differences between ITU TCAP and ANSI TCAP. The examples use AIN messages with ANSI TCAP encodings.

Basic Call State Models (BCSM)

One of the key differences between IN/1 and the succeeding AIN/IN CS phases is the introduction of a formal call model. A call model is a definition of the call processing steps that are involved in making a call. During call processing in a switch, a call progresses through various stages, such as Digit Collection, Translations, and Routing. These stages existed before the introduction of the IN; however, there was no agreement between vendors on exactly what constituted each phase and what transitional events marked the entry and exit of each stage. Even within a vendor's implementation, the delineation of stages could be ambiguous. IN defines a Basic Call State Model (BCSM), which identifies the various states of call processing and the points at which IN processing can occur—known as Points In Call (PIC) and Detection Points (DP), respectively. This is essential for distributing service processing between the SSP and SCP because the SCP must identify the PIC processing that has been reached by SSPs from a number of different vendors. The SCP can determine the call-processing context based on messages sent from specific DP, thereby allowing it to apply its own logic in a more intelligent way.

Point in Call (PIC)

The BCSM assigns a formal name, known as a PIC, to each call processing state. Figure 11-8 illustrates the components that are used to define the BCSM. A set of entry events define the transitional actions that constitute entering into a PIC. Exit events mark the completion of processing by the current PIC. The entry and exit events provide a means of describing what constitutes being in a particular PIC because the exact point at which one stage has been processed completely and the next stage is beginning can be vague. The ITU and Bellcore standards specify the list of events that constitute each of these PICs. Within each PIC, the switch software performs call processing for that stage of the call. This is the same call processing that existed before the introduction of IN, except with a clear delineation between processing stages.

Detection Point (DP)

DPs between the various PICs represent points at which IN processing can occur. The DP detects that the call has reached a particular state, as indicated, by having exited the previous PIC and encountering the DP. IN processing can be invoked to communicate with the SCP to determine further information about the call or request instructions about how the call should be handled.

DP is a generic term that identifies the insertion point for IN processing. More specifically, each DP is either a Trigger Detection Point (TDP) or an Event Detection Point (EDP).

Trigger Detection Point (TDP)

The TDP is a point at which the SSP can set triggers that execute when the TDP is encountered. The trigger represents an invocation point for an IN service. Triggers are provisioned at the SSP based on what call-processing events need intervention from the SCP. When a trigger has been subscribed for a particular TDP and the TDP is encountered, the SSP software launches a query to the SCP. Triggers can be subscribed with different granularities, ranging from an individual subscriber line to the entire SSP. The following are the different levels for which triggers can apply.

• Individual line or Trunk Group

• Business or Centrex Group

• Office-wide (meaning they apply to an entire SSP)

Multiple triggers can be defined at a given TDP. The IN and AIN standards define the trigger types that can be encountered at each TDP. For example, the IN CS-2 defines the Off_Hook_Immediate trigger type at the Origination Attempt TDP. Section "IN CS-2/AIN 0.2" discusses the TDPs and specific triggers in detail.

Event Detection Point (EDP)

An EDP is a point at which the SCP "arms" an event at the SSP. The event is armed to request that the SCP be notified when the particular EDP is reached during call processing. The SCP can then determine how the call should be further directed. For example, the SCP might want to be notified before a user is connected to a "busy" treatment so that a call attempt can be made to another number without the phone user being aware that a busy signal has been encountered.

An EDP can be one of two types: an EDP-Request or an EDP-Notification. An EDP-R requests that the SSP stop call processing (except in the case of O_No_Answer and T_No_Answer DPs) and send an EDP-R message to the SCP. No further action is taken until a response is received. An EDP-N requests that the SSP send an EDP-Notification but continue call processing. The SCP does not respond to the notification. The SCP can use the notification for billing, statistics, or other purposes.

When the SCP has received a message from the SSP, TCAP can establish a transaction. This is known as having an open transaction in IN. It is only within the context of an open transaction that the SCP can arm events. The SSP always initiates the transaction, so the SCP must wait for a message from the SSP before arming an EDP. There is one exception to this rule. AIN 0.2 introduced the Create_Call message, which allows the SCP to initiate an IN message to the SSP without previous communication from the SSP. The function of the Create_Call message is to have the SSP initiate a call to a specified destination. The Create_Call message can include a request to arm events on the SSP.

IN CS-2 and AIN differ slightly in the way events are armed. Each EDP is treated separately for IN CS-2. In AIN, a single component can contain a list of events, called a Next Event List (NEL). IN CS-2/AIN 0.2 introduced EDPs; specific EDP types are discussed in more detail in the "Event Detection Point" section.

Trigger and Event Precedence

Because multiple triggers and events can exist at a single DP, it is necessary to establish precedence for the order in which processing should occur. The following lists the generally followed order in which triggers and events are processed, beginning with the highest precedence.

• Event Notifications

• Trigger Notifications

• Event Requests

• Triggers Requests

There are exceptions to the generalized precedence listed. For example, in AIN 0.2, if an AFR trigger and a Network Busy Event are armed at the same DP, the AFR trigger takes precedence because its purpose is to provide more route selections, and the Network Busy Event is intended to indicate that all routes have been exhausted. Triggers are assigned at a particular level or scope. The precedence of trigger processing at each level, beginning with the highest priority, includes the following:

• Individually subscribed triggers (triggers against an ISDN service profile have precedence over triggers subscribed against the line)

• Group triggers (for example, centrex groups)

• Office-wide triggers

Multiple triggers, such as multiple individually subscribed triggers on the same line, can also be subscribed within the same scope. An example that applies to trunks is the Collected Information TDP, in which Off_Hook_Delay, Channel_Setup_PRI, and Shared_Interoffice_Trunk triggers can be assigned. The complete set of precedence rules for triggers occurring at the same scope can be found in the AIN 0.2 specifications [120].

Escape Codes

At times it is desirable for a trigger to be bypassed for certain calls. Escape codes provide a means for a subscriber with the Off_Hook_Delay trigger to make certain calls without invoking the trigger. Although any valid code can usually be provisioned as an escape code, common examples include emergency (911) calls and 0 calls to an operator. In the case of emergency calls, if the SS7 routes from the SSP to the SCP are down and the SSP triggers on the emergency number, the caller would not be able to make an emergency call unless the trigger could be bypassed.

Originating and Terminating Call Models

From the perspective of an SSP, each phone call can be described as two separate call halves: an originating call half and a terminating call half. The originating call half is established whenever the SSP detects an incoming call. The terminating call half is established when the SSP is setting up the outgoing portion of the call. In Figure 11-10, a line originates a call to SSP A. The incoming call from the subscriber line represents the originating call half. The call proceeds through call processing and connects to a trunk. The terminating call half is represented by the trunk connected to SSP A. When the call comes into SSP B, the trunk represents the originating call half from the perspective of SSP B. The call proceeds through call processing and terminates to a subscriber line, representing the terminating call half.

Beginning with IN CS-1/AIN 0.1, an IN BCSM model has been created for each call half.

• Originating Basic Call State Model (OBCSM)— Represents the originating call half.

• Terminating Basic Call State Model (TBCSM)— Represents the terminating call half.

This allows the originator or terminator who is involved in a call to be handled independently under the direction of the IN.

This section provides a general understanding of the IN/AIN call model and how it fits into the existing SSP call-processing domain. The later sections that cover IN CS-1/AIN 0.1 and IN CS-2/AIN 0.2 discuss the specifications of each model.

Network Architecture

A modern IN network consists of several components that work collectively to deliver services. Figure 11-11 shows a complete view of an IN network, with all elements in place to support the AIN and IN Capability Set.

Figure 11-11. AIN Network Architecture

[View full size image]

The architecture from a network point of view has remained constant from the initial concept released as IN/1. The evolutionary changes have been more focused at the processing within each node. It is important to understand that IN has not replaced the existing PSTN; rather, it has been overlaid onto it. The SSP represents the traditional PSTN switching exchange, but the software has been enhanced to support IN processing. The SCP, Adjunct, and IP are all additional nodes that were added to support the IN architecture.

Service Switching Point (SSP)

The SSP performs basic call processing and provides trigger and event detection points for IN processing. The primary change for enabling the SSP for IN is switching software that implements the IN call model and supporting logic for all of the triggers and events. Different switching vendors can have a limited IN implementation that only supports a portion of the call model. The SSP continues to handle the actual call connections and call state, as well as switch-based features. Currently, IN processing usually occurs at one or perhaps a few Detection Points so the SSP is still directing the majority of the call processing flow.

Service Control Point (SCP)

The SCP stores service data and executes service logic for incoming messages. The SCP acts on the information in the message to trigger the appropriate logic and retrieve the necessary data for service processing. It then responds with instructions to the SSP about how to proceed with the call, thereby providing the data that is necessary to continue call processing. The SCP can be specialized for a particular type of service, or it can implement multiple services.

Adjunct

The Adjunct performs similar functions to an SCP but resides locally with the SSP and is usually on a smaller scale. The Adjunct is often in the same building, but it can serve a few local offices. It handles TCAP queries locally, thereby saving on the expense of sending those queries to a remote SCP—particularly when the SCP belongs to another network provider who is charging for access. The connection between the Adjunct and the SSP is usually an Ethernet connection using the Internet Protocol; however, sometimes SS7 interface cards are used instead. The line between the SCP and Adjunct will continue to blur as the network evolves toward using the Internet Protocol for transporting TCAP data.

Intelligent Peripheral (IP)

The Intelligent Peripheral (IP) provides specialized functions for call processing, including speech recognition, prompting for user information, and playing custom announcements. Many services require interaction with the user and provide voice menu prompts in which the user makes choices and enters data through Dual-Tone Multifrequency (DTMF) tones on the phone keypad or by speaking to a Voice Recognition Unit. In the past, some of these functions have been performed using the SSP, but this occupies an expensive resource. Moving this function into an IP allows the IP to be shared between users and frees up dependency on SSP resources.

Service Management System (SMS)

Most of the IN services require the management of a significant amount of data. As with other IN nodes, multiple vendors exist that provide SMS solutions. The SMS generally consists of databases that can communicate with IN nodes to provide initial data loading and updates. The SMS systems often interface with other SMS systems to allow for hierarchical distribution of data throughout the network. While older SMS systems used X.25 to communicate with IN nodes, TCP/IP is now much more common.

Number services represent large portions of SMS data. LNP and toll-free numbers are examples; they require large amounts of storage with constantly changing data. The SMS provides the needed administration tools for managing these types of services.

Service Creation Environment (SCE)

The SCE allows service providers and third-party vendors to create IN services. The section titled "Service Creation Environment" describes the SCE in more detail.

ITU Intelligent Network Conceptual Model (INCM)

The ITU Intelligent Network Conceptual Model (INCM) divides the network into different "planes." Each plane shows a particular view of the components that make up the IN. The model is an abstract representation that provides a common framework for vendors and service providers, thereby giving IN architects and implementers a common terminology base for discussion and allowing the development of modular network components. The entities shown in Figure 11-12 are examples of how they fit into these planes.

Figure 11-12. Intelligent Network Conceptual Model

[View full size image]

As shown in Figure 11-12, the INCM consists of four planes, or views. While the views create a way of looking at a set of entities from a particular viewpoint, these entities ultimately collapse to tangible software and hardware in order to carry out network service functions. For example, consider that an SSP is a physical switching exchange that contains hardware and software to perform Call Control Functions (CCFs) and Service Switching Functions (SSFs). The Service Switching software is ultimately comprised of collections of Service Independent Building Blocks (SIB) that perform the work of translations, billing, user interaction, and so on for all services supported by the SSP. In the same way, the SCP contains software that performs the Service Control Function (SCF). The SCF is also ultimately comprised of collections of SIBs for performing the work of translations, billing, user interaction, and so on for the services it supports. Following is a brief description of each plane.

• Service Plane— Represents a view of the network strictly from the view of the service. The underlying implementation is not visible from the service plane.

• Global Functional Plane— A view of the common building blocks across the network that comprise service functions and how they interact with Basic Call Processing. The SIB represents each functional building block of a service. A "Basic Call Processing" SIB exists to represent the interactions of those service-related SIBs with call processing. This interaction is more tangibly represented by the call models that are defined in the Distributed Functional Plane (DFP).

• Distributed Functional Plane— A view of the Functional Entities (FE) that compose the IN network structure. The DFP is where the collection of SIB implementations represent real actions in the course of processing actual service functions. The formal term used to describe these functions is Functional Entity Actions (FEA). For example, this plane describes BCSM within the CCF.

• Physical Plane— Represents the physical view of the equipment and protocols that implement the FE that are described in the DFP.

Correlating Distributed Functional Plane and Physical Plane

The ITU describes the concept of a DFP, which maps FEs onto the network. These FEs are a means of describing which nodes are responsible for particular functions: a "functional view" of the network. Table 11-1 shows the mapping of nodes to FE. Not surprisingly, the descriptions are quite similar to the previous node descriptions. Nevertheless, these FE terms are used throughout the ITU standards, so they are introduced here for familiarity.

Table 11-1. IN Physical Plane and Distributed Functional Plane

Physical Plane	Distributed Functional Plane
SSP	Call Control Function (CCF)— Provides call processing and switch-based feature control. This includes the setup, maintenance, and takedown of calls in the switching matrix and the local features that are associated with those calls. Call Control Agent Function (CCAF)— Provides users with access to the network. Service Switching Function (SSF)— Provides cross-functional processing between the CCF and SCF, such as the detection of trigger points for IN processing.
SCP	Service Control Function (SCF)— Directs call processing based on Service Logic Programs. Service Data Function (SDF)— Provides service-related customer and network data for access by the SCF during the execution of service logic.
SMS	Service Management Function (SMF)— Manages the provisioning and deployment of IN services and service-related data. Service Management Access Function (SMAF)— Provides the interface for accessing the SMF.
SCE	Service Creation Environment Function (SCEF)— Provides for the creation and validation of new services. Generates the logic used by the SCF.
IP	Specialized Resource Function (SRF)— Provides resources for end-user interactions, such as recorded announcements and user input via keypads, voice recognition, and so forth.

This concludes the general introduction to the AIN/IN CS network. The following sections focus on the particular versions released in the IN evolution chain.

AIN 0

AIN 0 was a short-lived interim phase for reaching AIN 0.1, so this chapter dedicates little attention to it. AIN 0 was the first IN release to establish a formal call model at the SSP. It was a simple model that used Trigger Checkpoints (TCPs) at the following call points:

• Off hook

• Digit Collection and Analysis

• Routing

This expanded the capabilities of AIN beyond simply doing number services and allowed new features like Automatic Flexible Routing (AFR), which is based on the routing checkpoint. AFR allows the SSP to query the SCP for new routes if all the routes identified by the local switch are busy. AIN 0.1 establishes and supercedes all of the capabilities of AIN 0.

IN CS-1/AIN 0.1

This version of the IN introduced a much richer call model than the interim AIN 0 release. The model is divided into an originating and terminating call model to provide a complete, but basic description of the call. The term Trigger Checkpoints was changed to Trigger Detection Points, and new PICs and DPs were added to the model.

The next two sections examine originating and terminating models, showing the PICs that define each call stage along with their associated DPs.

IN CS-1 OBCSM

Figure 11-13 shows the IN CS-1 PICs and DPs that are supported in this version for the originating call model. The AIN 0.1 version is similar.

Figure 11-13. IN CS-1 OBCSM

[View full size image]

In IN CS-1, the Analyzed Info DP now provides the detection point for the number services that IN/1 originally supported. The Specific_Digit_String (SDS) is the trigger type now used at the DP to trigger a query for services like toll-free calling. In AIN 0.1, The Public Office Dial Plan (PODP) trigger is used for this trigger type. AIN 0.2 converges with the IN CS-2 to replace the PODP trigger with the SDS trigger type. Again, this is part of the continual evolution and standards convergence issues. This particular trigger type is mentioned for reader awareness because it is used in the popular number services and is commonly seen in IN networks.

IN CS-1 TBCSM

Figure 11-14 shows the terminating call model with its supported PICs and DPs.

Figure 11-14. IN CS-1 TBCSM

[View full size image]

Several existing IN networks use the capabilities provided by the AIN 0.1 release. Because the capabilities of IN CS-1/AIN 0.1 are generally a subset of those that are supported in IN CS-2/AIN 0.2, they are explained in the "IN CS-2/AIN 0.2" section.

AIN Toll-Free Service Example

Section "IN/1" discussed the IN/1 version of the toll-free service. The same service is discussed here using AIN messaging instead of IN/1. For a review of how the E800 service works, refer to the example in the "IN/1" section. Because this example is shown using AIN 0.1, note that the PICs, DPs, and trigger type are slightly different than the IN CS-1 counterparts. This is a matter of semantics, and IN CS-1 provides the equivalent functions. Figure 11-15 shows the flow of events for the E800 service.

The same digit collection, translations, and routing software routines shown in the IN/1 example of the service still exist. The major difference with AIN is that they are now represented by discrete PICs. Rather than checking for a particular SAC, the SSP now reaches the Info_Analyzed DP and checks for any triggers that are applicable to the DP. As shown in Figure 11-16, the Called Party Number contains the leading "888" digit string, which has been provisioned as a PODP trigger (equivalent to the IN-CS1 SDS trigger) at the SSP that generates a query to the SCP.

Figure 11-16. AIN Toll-Free Trigger Processing

[View full size image]

The query sent from the SSP is built using information that the SCP needs when processing the message. The query includes the following key components. Note that the entire TCAP messages are not shown—only the key components.

The SCP applies its service logic based on the incoming message and sends the SSP a response that includes instructions on how to direct the call. The key information the SCP provides is either the service provider's carrier code or a routing number if the LEC handles the toll-free service. This decision is made during execution of the service logic at the SCP. When the SSP receives the Response message, it resumes call processing using the information returned by the SCP to perform translations and routing of the call.

Example 11-1. SSP Query

TCAP Component

        Operation Family: Request_Instructions

        Operation Specifier: Info_Analyzed

               Parameter: UserID

               Parameter: BearerCapabilityID

               Parameter: AINDigits (CalledPartyID)

               Parameter: AINDigits (LATA)

               Parameter: TriggerCriteriaType (indicates "npa" or "npaNXX")

               Parameter: AINDigits (ChargeNumber)

               Parameter: AINDigits (CallingPartyID)

               Parameter: ChargePartyStationType (ANI II)

               Parameter: PrimaryCarrier

Example 11-2. SSP Response

TCAP Component

        Operation Family: Connection Control

        Operation Specifier: Analyze_Route

               Parameter: ChargePartyStationType (ANI II)

               Parameter: AINDigits (CalledPartyID)

               Parameter: PrimaryCarrierID

               Parameter: AMALineNumber

               Parameter: AMASLPID

IN CS-2/AIN 0.2

The IN CS-2/AIN 0.2 represents the most recent version of IN that most switching vendors support to date. Of course, this is a moving target, and vendors might not fully comply with the full specifications of the release; therefore, it should be considered a generalization. As noted earlier, the 0.2 version number has actually been dropped from the specifications. The term IN CS-2 is used throughout this section to describe the call models, unless referencing something specific to AIN 0.2, because the two standards are aligned in a very similar manner.

The IN CS-2 call models provide a fairly comprehensive list of PICs to accurately describe call flow in the originating and terminating call halves. Although they are functionally the same, a comparison of the CS-2 and AIN call models shows that naming is often slightly different. The IN CS-2 call model is used here. Even the name of the model is slightly different, with AIN using the term Basic Call Model and ITU using Basic Call State Model. When discussing the call models, explanations are kept as common as possible—aside from the naming conventions.

Originating Basic Call State Model (BCSM)

Figure 11-17 shows the originating call model for IN CS-2. The call model supports several TDPs and EDPs. IN CS-2 is the first call model to support EDPs, thereby giving the SCP greater control of call processing at the SSP.

Figure 11-17. IN CS2 Originating Basic State Call Model (BCSM)

[View full size image]

IN CS-2 OBCSM PICs

Here we examine each of the PICs and DPs of the originating call model to gain an understanding of each stage of call processing and the possible DPs where IN processing might occur. While studying the model, keep in mind that what the model describes is the flow of processing that occurs in modern digital switches for an individual call. Each of the PICs and their transition events represent processing that existed before IN was introduced. This model introduces a standard agreement of the functions represented at each stage (PIC) and defined points for the invocation of IN processing (DP).

• Orig Null— This PIC represents an idle interface (line or trunk), indicating that no call exists. For example, when a phone is on-hook and not in use, it is at the Orig Null PIC.

• Authorize Origination Attempt— Indicates that an origination is being attempted and that any needed authorization should be performed. The calling identity is checked against any line restrictions, bearer capability restrictions, service profile information, and so on to determine whether the origination should be permitted.

• Collect Information— Represents the collecting of digits from the originating party. The number of digits to collect might be done according to the dialing plan, or by specific provisioning data from the switch.

• Analyze Information— Analysis or translation of the collected digits according to the dial plan. The analysis determines the routing address and call type associated with the analyzed digits.

• Select Route— The routing address and call type are used to select a route for the call. For example, a trunk group or line DN might be identified to route the call.

• Authorize Call Setup— Validates the authority of the calling party to place the call to the selected route. For example, business group or toll restrictions on the calling line can prevent the call from being allowed to continue.

• Send Call— An indication requesting to set up the call is sent to the called party. For example, if the call is terminating to an SS7 trunk, an IAM is sent to the far end to set up the call.

• Alerting— The calling party receives audible ringback, waiting for the called party to answer. For example, when terminating to a trunk, the remote office might send ringback in-band over the trunk.

• Active— Answer is received and the connection between the originating and terminating parties is established. The two parties can now communicate. At this point, the call has exited the setup phase and is considered stable.

• Suspended— A suspend indication has been received from the terminating call half, providing notification that the terminating party has disconnected (gone on-hook). For example, the terminating party disconnects on an SS7 signaled interoffice call, and the originating switch receives an ISUP Suspend message.

• Exception— An exception condition, such as an error or other condition that is not associated with the normal flow of processing, has occurred.

IN CS-2 OBCSM TDPs and Trigger Types

The TDPs are closely associated with the PICs because they identify a transition point between the PICs at which IN processing can be invoked. For each TDP, a brief description is given of the transition point being signaled and the trigger types that might be encountered are listed. IN processing only acts on the TDPs if triggers for that particular TDP have been defined.

Origination Attempt

This TDP signals that the originator is attempting to originate a call. It is encountered when an off-hook is detected.

Triggers: Off_Hook_Immediate

Origination Attempt Authorized

This TDP signals that the originator has been authorized to attempt a call. Checks against bearer capability, line restrictions, group restrictions, and so on have been validated.

Triggers: Origination_Attempt_Authorized

Collected Information

AIN 0.2 labels this TDP "Info Collected." It signals that all of the digits have been collected. For example, if the originator is dialing from a line, the expected number of digits has been entered according to the dialing plan.

Triggers:

• Off_Hook_Delay

  - Channel_Setup_PRI

  - Shared_Interoffice_Trunk

Analyzed Information

AIN 0.2 labels this TDP as "Info Analyzed." It signals that the digits have been analyzed and all translations performed, thereby resulting in a routing address and Nature Of Address (for example, subscriber number and national number). Note that AIN 0.2 has replaced the PODP trigger type from AIN 0.1 with the ITU specified SDS trigger type.

Triggers:

• BRI_Feature_Activation_Indicator

• Public_Feature_Code

• Specific_Feature_Code

• Customized_Dialing_Plan

• Specific_Digit_String

• Emergency_Service (N11 in AIN 0.2)

• One_Plus_Prefix (AIN 0.2 only)

• Specified_Carrier (AIN 0.2 only)

  - International (AIN 0.2 only)

  - Operator_Services (AIN 0.2 only)

  - Network_Services (AIN 0.2 only)

Route Select Failure

AIN 0.2 labels this TDP as "Network Busy." It signals that a route could not be selected. The transition back to the Analyze Information PIC can be the result of an individual route being attempted unsuccessfully. A route list often contains a number of routes that might be attempted before routing is considered to have failed. This is particularly true when trunks are involved because different trunk groups are selected from a route list. Also note that AIN 0.2 includes a Route Selected TDP, which is not included in IN CS-2. This is one of the slight differences in the call model. The Route Selected TDP indicates that a route has been successfully selected for sending the call.

Triggers: Automatic Flexible Routing (AFR)

O Called Party Busy

This TDP signals to the originator that the terminating party is busy. For example, the call terminates to a line that is already involved in a call.

Triggers: O_Called_Party_Busy

O Term Seized

This TDP signals to the originator that the terminating party has accepted the call.

O Answer

This TDP signals that the originator has received an O Answer event from the terminating call model.

Triggers: O_ Answer

O No Answer

This TDP signals that the originator has not received an O Answer event before the O No Answer timer expired.

Triggers: O_No_Answer

O Suspend

This TDP signals that the originator has received a suspend indication from the terminating call model. The terminating call model sends the suspend in response to the terminator going on-hook.

O Re-Answer (IN CS-2 DP Only)

This TDP signals that a suspended call has resumed (the terminator has gone back off-hook on the call). This is equivalent to the Called Party Reconnected event in AIN 0.2; however, in AIN 0.2, no DP is supported when this event occurs.

O Midcall

This TDP signals that the originator has performed a hook flash or, in the case of an ISDN line, has sent a feature activator request.

Triggers:

• O_ Switch_Hook_Flash_Immediate

• O_Switch_Hook_Flash_Specified_Code

O Disconnect

This TDP signals that the originating or terminating party has disconnected from the call. When the call is active, this signal might be generated from the originating or terminating call model.

Triggers: O_ Disconnect

O Abandon

This TDP signals that the originating party has disconnected before the call has been answered. For example, this can occur from an originating line going on-hook, an ISDN set sending call clearing, or a REL message from an SS7 trunk occurring before receiving an answer from the terminating call model.

Terminating Basic Call State Model

The IN CS-2 TBCSM represents the stages of a call in the terminating call half. Figure 11-18 shows each of the PICs and TDPs that are supported by the CS-2 model.

Figure 11-18. IN CS-2 Terminating Basic Call State Model

[View full size image]

IN CS-2 TBCSM PICs

The following PICs are defined to support IN processing in the terminating call model:

• Term Null— This PIC indicates that no call exists.

• Authorize Termination Attempt— Determines whether a call has the authority to terminate on the selected interface (for example, DN and trunk group) based on business group restrictions, line restrictions, bearer capability, and so on.

• Select Facility— Determines the busy/idle status of the terminating access.

• Present Call— The terminating access is informed of an incoming call. For example, a line is seized and power ringing applied—or in the case of an SS7 trunk, an IAM is sent.

• Term Alerting— An indication is sent to the originating half of the BCSM that the terminating party is being alerted.

• Term Active— The call is answered and the connection is established in both directions. The call has exited the setup phase and is now stable.

• Term Suspended— The terminator has disconnected (gone on-hook). This occurs only for basic telephone service lines. It does not apply to ISDN or Electronic Key Telephone Set (EKTS)-terminating access types. Release Disconnect timing is started and the connection maintained. For SS7 signaled trunks, a Suspend message is sent in the backwards direction.

IN CS-2 TBCSM TDPs and Trigger Types

The following are the TDPs for the terminating call model. A brief description is given of the transition point being signaled for each TDP. After the descriptions, the trigger types that are applicable to each TDP are listed.

Termination Attempt

This TDP signals an incoming call attempt on the terminating call model.

Triggers: Termination_Attempt

Termination Attempt Authorized

AIN 0.2 labels this TDP as "Call Presented." It signals that the call has been authorized to route to the terminating access. Line or trunk group restrictions, business group restrictions, and bearer capability have all been validated.

Triggers: Termination_Attempt_Authorized

T Busy

This TDP signals that the terminating access is busy (in other words, it is not idle).

Triggers: T_Busy

Facility Selected and Available

This TDP Signals that the terminating access has been chosen and is available (in other words, it is not busy).

Triggers: Term_Resource_Available

Call Accepted

This TDP signals that the terminating interface has accepted the call and is about to be alerted.

T No Answer

This TDP signals that the terminator has not answered within the ring timeout period. The terminating switch starts the ring timer when alerting begins.

Triggers: T_No_Answer

T Answer

This TDP signals that the called party has answered.

Triggers: T_ Answer (not defined for AIN 0.2)

T Suspended

This TDP signals that the called party has disconnected, but the terminating call model is maintaining the connection.

T Disconnect

This TDP signals that a disconnect has been received from the originating or terminating party.

Triggers: T_Disconnect

T Midcall

This TDP signals that the terminating access has performed a flash hook or, in the case of an ISDN interface, sent a feature activator request.

Triggers: T_Switch_Hook_Flash_Immediate

T Re-Answer (IN CS-2 DP Only)

This TDP signals that the terminating access has resumed a previously suspended call (it has gone off-hook). This is equivalent to the Called Party Reconnected event in AIN 0.2, but in AIN 0.2, no DP is supported at the occurrence of this event.

T Abandon

This TDP signals that the originating party abandoned the call before it was set up.

AIN 0.2 Call Control Messages from the SCP

The SSP initiates IN processing. The following is a list of AIN 0.2 call control messages that the SCP can send in response to an SSP message. The SCP can also send several non-call related messages that are not included here. Reference the Bellcore GR-1298 for a complete list of messages.

• Analyze_Route— Requests that the SSP continue call processing using the information provided in the message. Examples of the data returned in this message include an address, route, billing, trunk group parameters, and carrier parameters.

• Continue— Requests that the SSP continue processing the call without any new information returned from the SCP.

• Authorize_Termination— Request for the SSP to continue processing at the Authorize_Termination PIC. This allows the SSP to verify the authority to route the call.

• Forward_Call— Request for the SSP to forward the call using the information provided in the message. The SSP creates a new originating call for the forwarding call leg and merges it back into the terminating call half.

• Offer_Call— This message is sent in response to the T_Busy message that instructs the SSP to offer the call to the called party. This allows a called party with Call Waiting to have the opportunity to accept the call.

• Disconnect_Call— Requests that the SSP disconnect the call.

• Send_To_Resource— Requests the SSP to route the call to a resource such as an IP. For example, the caller hears an announcement and inputs digits to be collected (for example, a pin code, menu choice, and so on).

• Collect_Information— Request for the SSP to return to the Collect Information PIC. This request can come at certain DPs after the Info Collected PIC has been passed in the progression of the call to send the call back to that point. It can be sent in response to the following SSP messages:

  - Info_Analyzed

  - O_Called_Party_Busy

  - O_No_Answer

  - O_Suspended

  - O_Disconnect

AIN 0.2 Time Of Day (TOD) Routing Example

This example demonstrates the use of AIN for TOD routing along with the O_Called_Party_Busy_Event. A fictitious company XYZ is using the TOD Routing service to route calls to their East Coast support center before 4:00 P.M. EST and to their West Coast support center after 4:00 P.M. EST. In addition, if a busy signal is encountered at the east coast center, an attempt is made to reach the west coast. This happens transparently for the customer; they simply dial a number and reach a technical support person.

In Figure 11-19, the subscriber dials the technical support number. SSP A encounters the SDS trigger at the Analyzed Information DP and matches the called number with a provisioned SDS. A query is sent to the SCP with an Info Analyzed component. The called number is coded into a TCAP parameter that belongs to this component, along with other necessary supporting parameters such as calling number, charge number, and so forth. The SCP receives the message and applies the appropriate service logic for the query, which includes a TOD routing decision. The SCP returns an Analyze Route message with a Called Party Number that is based on the current TOD. The Analyze Route is encoded into a TCAP component with an operation code of Analyze Route. In addition, the SCP includes a Request_Report_BCM_event component that contains a NEL. The NEL contains a list of the events that the SCP is requesting. In this case, only one event is being requested: the O Called Party Busy EDP-R. The OCPB event is now "armed," meaning that IN processing will be invoked when the event occurs. The SSP uses the Called Party Number that is returned in the Analyze Route message to continue call processing, going through normal translations and routing. When a termination attempt is made to the destination, the status of the Called Party Number is busy, which causes the SSP to encounter the OCPB DP. Because the OCPB EDP-R is armed, rather than providing a busy treatment to the originator, IN processing is invoked to send a notification to the SCP, thereby allowing it to intervene. The service logic at the SCP determines that another number has been provided if a busy status is encountered at the first number. The SCP responds with another Analyze Route message that contains the west coast center's Called Party Number. Call processing at the SSP resumes with translations and routing of the new number. The call is then completed successfully.

Figure 11-19. Time of Day Routing with OCPB Event

[View full size image]