The Intelligent Network

The IN is an architectural concept; it provides for real-time execution of network services and customer applications in a distributed environment consisting of interconnected computers and switching systems [ITU92a, FAY96]. Until the advent of the IN, services were intimately tied to the switches and were not interoperable across vendor boundaries. The IN decoupled and distributed the call control and service execution to separate network elements; call control took place on switches and the service execution on general-purpose computers having access to fast databases, and on specialized devices to play announcements, collect digits, bridge calls, provide conferencing, etc. All connected to the switches through dedicated signaling links. The IN standardized the communication interfaces between a switch and a service platform as well as the service creation and management between them. The decoupling, distribution of functions, and standardization efforts had a great effect on how services were created and deployed on the PSTN. Services were now independent of the switch; they could be specified and implemented much faster and cheaper than before.

The IN is currently the de facto service architecture for the PSTN; its principles of distributing the intelligence among PSTN entities for service execution are very applicable to Internet telephony [FIN02]. The IN architecture has spawned a sizable number of research efforts [BAR93, CHI00, GBA99, LEN99, LIC01, PET00] and commercial interests — Sun Microsystem's Java Application Programming Interfaces (APIs) for Integrated Networks (JAIN)2 [SUN05] and many industry consortia, primary among them Parlay/Open Services Architecture (OSA) [PAR05] and Telecommunications Information Networking Architecture (TINA) [TEL05]. The precepts of the IN architecture have been enormously influential to the general area of Internet telephony services.

3.1.3 The IN Conceptual Model

The International Telecommunication Union — Telecommunications Standardization Sector's (ITU-T) Recommendation Q.1201 [ITU92a] describes an IN conceptual model as a "framework for the design and description of the IN architecture." This conceptual model is then realized through a set of software protocols, finite-state machines, and associated hardware into a concrete IN architecture. The IN conceptual model has four layers, or planes. Each plane introduces an abstract view of the network entities, which is further made tangible in the plane below it. Starting from the top, these are the service plane, the global functional plane, the distributed functional plane, and the physical plane. Figure 3.2 depicts this hierarchy.

3.1.3.1 Service Plane

The service plane represents the designer's viewpoint of how a service should work. At this plane, services are described in terms of service features. A service feature is a service-independent aspect that describes one particular service but may be applicable to other services as well. An example provides more insight: A call-queuing feature describes the behavior of a call arriving in the network and required queuing if all lines that can service the call are busy. Incoming calls are queued and serviced on a first-come first-served basis as soon as a line becomes available. This

2 In the late 1990s, when Sun initially released the JAIN API, the acronyms originally expanded to Java APIs for Intelligent Networks. However, driven by the nascent Internet telephony movement, the need for programming telephony services was so great that JAIN expanded beyond its IN roots. Thus, besides APIs for IN, there are now JAIN APIs for Internet telephony signaling protocols like SIP and SDP, services like instant messaging (IM), and many others. A complete list of JAIN APIs is provided in [SUN05].

Action

Building Block Pointer

Legend

BCP Basic Call Process EF Elementary Fuction FE Functional Entity FEA Functional Entity

IF Information Flow

PE Physical Entity

POI Point of Initiation

POR Point of Return

SF Service Feature

SIB Service-Independent

Action

Building Block Pointer

Figure 3.2 The IN conceptual model. (After Figure 20 in ITU-T, Principles of Intelligent Network Architecture, Recommendation Q.1201, Geneva, Switzerland, October 1992.)

call-queuing service feature can now be applied to the domain of a call center that has an 800 number for callers to dial in. When all agents are busy, the callers are queued; whenever an agent becomes available, the earliest caller in the queue is assigned to the agent. To observe service independence, note that the same call-queuing service feature can equally be applied to another domain: queuing incoming calls for the directory information (411) service. At this plane, services are described and composed in terms of independent service features.

3.1.3.2 Global Functional Plane

A service programmer observes the IN at this layer. The global functional plane provides a service programmer atomic building blocks from which to construct services. The service features of the service plane are mapped to atomic instructions called Service Independent Building Blocks (SIBs). The SIBs are reusable components and can be chained together to construct a service logic. The object handling the call runs a fixed finite-state machine called the Basic Call Process (BCP). When the BCP reaches a certain point (called point of initialization) that requires it to execute the service, further call execution is suspended and control is passed to the service logic. The service logic executes the SIBs and, upon completion, control is passed back to the BCP (point of return).

3.1.3.3 Distributed Functional Plane

This plane represents the view of a network designer. The entities in the network are viewed as a set of abstract models of software and hardware called functional entities (FEs). The FEs may perform atomic functional entity actions (FEAs) and, as a result of the FEAs, exchange messages — through remote procedure calls (RPCs), function calls, or electronic/fiber signals — called information flows (IFs). The SIBs of the global functional plane are realized by the sequence of FEAs in an FE. Certain FEs in this plane, especially those that model a switch setting up a call, play an important role in this book and will be examined more closely in later sections.

3.1.3.4 Physical Plane

This plane is of primary importance to network operators and equipment providers. The FEs of the distributed functional plane are mapped to physical entities (PEs) in this layer; for instance, the FE that controls the call will be realized as a switch, the FE that performs media services will be realized as a media server, and so on. PEs communicate with each other by exchanging protocol messages (which were represented as IFs in the distributed functional plane).

3.1.4 Physical Entities in an IN-Enabled Network

The IN conceptual model presented in the preceding section is, by design, an abstract model. When it is actually put into practice, the abstract entities are mapped into physical ones. This subsection explores the IN not from the conceptual or abstract model, but rather from a physical one involving the computers and other peripherals that actually render the network intelligent.

First, a high-level overview of how an IN-compliant service is executed will provide the relevant framework for the discussion that follows on the physical entities that make up the IN. An IN-compliant service is first constructed through an FE called the service creation environment function. This FE contains the programming environment, which includes the SIB that a programmer uses to construct an IN-compliant service. Once the service logic is created and tested, it is sent to another FE, the service management function. This FE deploys the service logic to the service execution FEs and allows for service customization.

An IN-enabled switch that is processing a call runs a fixed finite-state machine, the BCP. The BCP represents switch code and defines various control points, such as the point where the destination address has been received from the caller, or the point where the called user has answered the phone. When the BCP arrives at a specific control point, and certain prerequisites for executing a service are met, the BCP can trigger an RPC from the switch to a service execution platform.3 The procedure call in the service execution platform runs the service; for example, the service may have been translating an 800 number by looking into a database. When the procedure call returns, the execution of BCP continues, using the translated number returned by the procedure call. Some services are far more complex than simple number lookup; for instance, a service could require the calling user to authenticate herself by typing in a passcode or uttering a password. Depending on the service logic, the service execution platform may involve other peripherals that provide functions to operate on the media to perform digit detection or analyze a spoken password.

With this high-level view in mind, Figure 3.3 outlines an IN-enabled network that contains the entities described in the service description above. This figure is an abridged version of Figure 1 in Q.1205 [ITU93], which defines all the FEs a PE may contain. For the discussion pertinent to this book, it is important to understand the most critical of the FEs and their corresponding association with a PE.

The PSTN augmented by the IN includes the following critical FEs (as shown in Figure 3.3).

3.1.4.1 Service Switching Point (SSP)

A switch that is capable of providing access to the IN capabilities is called an SSP; not all switches are so capable. The SSP provides users access to the telephone network through the local exchange. It acts as the first entry point into the IN; the detection capabilities of an SSP determine which of the subscribed IN services a user receives when he makes or receives a phone call.

3 The RPC ultimately results in an on-the-wire protocol being sent from the switch to the service execution platform. In IN, this protocol is called Transaction Capabilities Application Part (TCAP) in the United States and Intelligent Network Application Part (INAP) in Europe. Both TCAP and INAP are application-level protocols (residing at the topmost layer of the SS7 protocol stack) and transported over the SS7 packet network.

Legend:

AD Adjunct IP Intelligent Peripheral SCP Service Control Point SDP Service Data Point SCEP Service Creation

Environment Point Service Management Point

Service Node Service Switching Point

SN SSP

Signaling

Transport (Media) Management Provisioning and Control

Signaling

Transport (Media) Management Provisioning and Control

Figure 3.3 The PSTN augmented by the IN. 3.1.4.2 Service Data Point (SDP)

The SDP is a specialized database that contains customer data, which is accessed by the Service Control Point (discussed next) during the execution of an IN service. The SDP contains data that directly relates to the provision or operation of the IN services.

3.1.4.3 Service Control Point (SCP)

An SCP is a general-purpose computer connected to the SSP through the SS7 network. SCPs contain user programs and associated subscriber data (accessible through the SDP) that implement an IN service pertinent to a call. The SCP is brought into an IN service by the SSP; the SCP, in turn, can bring other IN entities into the service flow, if required. For example, when executing a prepaid card service, the SCP may use the services of an IN entity called an Intelligent Peripheral to perform digit collection or voice recognition.

3.1.4.4 Intelligent Peripheral

An intelligent peripheral is a specialized media resource server. It has physical access to the media stream of a phone call (see Figure 3.3); thus, it can provide media-related services such as voice announcements, speech recognition, dual tone multifrequency (DTMF) digit collection, audioconference bridging, tone generation, and text-to-speech synthesis.

3.1.4.5 Adjunct

An adjunct is functionally equivalent to an SCP, but is connected to a single SSP through a high-speed network (such as a local area network (LAN)), instead of an SS7 link. Certain IN features that require a fast response time between the IN service and the SSP can reside in the adjunct to take advantage of the high-speed connection between the SSP and the adjunct.

An SN performs the role of an SCP and an intelligent peripheral. The IN services may reside and execute on the SN (as they do on the SCP) and, if they require DTMF or speech recognition, the SN itself can provide such functionalities (note from Figure 3.3 that much like the intelligent peripheral, the SN also has access to the media stream).

3.1.4.7 Service Creation Environment Point (SCEP)

An SCEP is a general-purpose computer where the IN services are programmed and tested before being deployed.

3.1.4.8 Service Management Point (SMP)

An SMP is a general-purpose computer through which service management and provisioning are performed. Services are loaded to the SCP for execution, and the data for the services is provisioned on the SDP.

3.1.5 The Basic Call State Machine, Points in Call, and Detection Points

The centerpiece of the IN conceptual model is a fixed finite-state machine called the Basic Call State Model (BCSM). A call state model, or call model for short, is a deterministic finite-state machine (FSM). It is represented as a digraph consisting of a set V = (vj, v2, ..., vn-j, vn) of vertices and a set E = (Ej, E2, ..., Em-j, Em) of edges. A vertex is called a state and an edge is called a transition. There may be more than one transition leading into a state, and consequently, there may be more than one transition leading out of a state. Transitions corresponds to the events that occur during the processing of telephone calls, e.g., lifting the receiver to make a call, ringing, picking up the receiver to receive a call, dialing digits, etc.

Figure 3.4 depicts a sample call model with four states and eight transitions. v0 is the initial state (also called the null state), and vj, v2, and v3 are the three subsequent states. Transitions e0, e6, and e7 lead into v0, while ej leads out of it. In certain cases, transitions may lead back into the same state (as is the case with transition e5).

Call models represented as FSMs serve two main purposes: first, they synchronize the various entities in the IN that provide services (SSP, SCP, intelligent peripheral, etc.), and second, they present a consistent view of a call to provide services. The latter deserves further explanation.

Figure 3.4 A call model represented as an FSM.

Calling Party

SSP 1

O_BCSM

T_BCSM

SSP 2

Network

O_BCSM

T_BCSM

Legend:

O_BCSM Originating Basic Call State Model T_BCSM Terminating Basic Call State Model SSP_Service Switching Point(Switch)

r Event/Transition

Peter

Called Partyi

Figure 3.5 Originating and Terminating Basic Call Objects.

The BCSM is called a half-call model because it uses two halves to represent a call. Figure 3.5 contains a logical view of the call model. The half that originates a call is termed an Originating BCSM (O_BCSM); conversely, the half that terminates the call is referred to as a Terminating BCSM (T_BCSM). When a call is originated at an SSP, it initiates the O_BCSM and applies originating-side services4 to the call. The SSP responsible for the ultimate recipient of the call initiates the T_BCSM and applies terminating-side services5 to the call. Note that if the recipient of the call resides on the same SSP, the T_BCSM is attached to the recipient directly and terminating-side services are provided by the same SSP that provides originating-side services.

The BCSM, as stated previously, is a fixed finite-state machine. It has a certain number of states and a set of events that cause a change from one state to the next. The states are referred to as points in call (PICs), and the transitions between them are termed detection points (DPs). The PICs serve to synchronize the entities that participate in a call, while the DPs enable the service to be executed. Recall from the discussion at the beginning of Section 3.1.4 that when an IN-enabled switch reaches a certain control point, and certain prerequisites for executing a service are met, a call is suspended and an RPC is triggered from the switch to the SCP. The control point is a PIC, and the certain prerequisites are a DP being armed and satisfying some criteria associated with the DP.

4 Originating-side services include 900-number blocking, 800-number translation, etc.

5 Terminating-side services include caller identification, call waiting, etc.

DPs operate between the PICs; they delineate points in the model where call processing is suspended and the service execution platform is contacted to perform a service pertinent to that DP. Query messages are associated with each DP; when a query message is received at the service execution platform, the platform knows the exact state of the suspended call. A DP may be either armed or not armed; for the SSP to send a query message to the service execution platform, a DP must be armed and must meet certain trigger criteria. Examples of trigger criteria include bearer capability (DTMF or rotary dialing), presence of feature codes (for example, *70 in the United States is used to disable call waiting), or simply unconditional trigger (in which case, no other criteria are checked). A DP may be armed either statically or dynamically. Static DPs are armed through the SMP, as part of service provisioning. Once armed, a static DP remains so until explicitly disarmed by the SMP. A dynamically armed DP, as its name suggests, is armed on an as-needed basis by the SCP as it implements on the service logic. A dynamic DP remains armed as long as the SCP-to-SSP relationship persists (which is generally the duration of a call).

As far as call processing is concerned, either of the following two actions may be requested of the SSP when a DP is encountered:

1. The state of the call is encapsulated in a query message that requests further instructions from the SCP; the SSP suspends further call processing until a response is received.

2. The call processing continues normally and a notification of the event (the DP encountered) is sent to the SCP.

Accordingly, two attributes, R(equest) and N(otification), are defined for DPs, corresponding respectively to the two actions above.

3.1.6 The IN Capability Sets

The IN has been standardized incrementally, starting with a baseline set of services and associated call models and protocols called Capability Set (CS)-1, standardized in March 1993. CS-1 was intended to support primitive services only, i.e., those services that apply to only one party in a call. Sample services enabled by CS-1 included abbreviated dialing (dialing the last four or five digits to complete a phone call), call forwarding, and originating call screening.

CS-2 followed in September 1997, and in addition to support for CS-1 services, it contained more complex services, including support for personal mobility. Sample services supported by CS-2 included call waiting, multiparty call handling (call transfer, conference calling, etc.), and mobile registration/de-registration. CS-3 was released in December 1999; besides supporting CS-2, CS-3 also included support for IN/Internet interworking for the first time. In addition, CS-3 introduced other services, such as number portability, support for prepaid calling cards, and further work on user and device mobility. In August 2001, CS-4 was released, defining a further evolution of CS-3 services. CS-4 further cements the IN/Internet interworking on many fronts. It supports services such as Internet telephony (i.e., transport of voice over a packet network) and establishes the IN as an overlay service network common to all transport and signaling technologies. In fact, CS-4 uses the ideas developed in Chapters 5 and 6 of this book to interwork portions of the IN and the Internet (see Sections 6.1 and 6.4 of Q.1244 [ITU01], respectively).

3.1.7 Originating BCSM (O_BCSM)

PICs and DPs play an important role in the execution of the IN services and deserve more attention because the work described in this book makes considerable use of them. CS-1 and CS-2 were defined with their own call models, complete with their own PICs and DPs. Both call models are a subset of the IN BCSM defined in Q.1204 [ITU92b]. The BCSM defined in Q.1024 is independent of the capability sets; thus, it serves as a representative BCSM for the work described in this book. The state machine for O_BCSM of Q.1204 is provided in Figure 3.6. It contains 11 PICs and 21 DPs.

Each PIC has certain exit criteria defined in the form of a DP that is set, i.e., the DP is armed and the trigger conditions have been met. Some PICs have more than one exit criterion. PICs 2 through 9 have a common exit criterion in the form of DP 21 (Calling_ Party_Disconnect_and_Abandon) being set. This DP is set if the caller disconnects the call while the call is still active, or prematurely abandons further call processing (i.e., the caller hung up before call processing could be completed). PICs 7, 8, and 9 have another common exit criterion in the form of DP 18 (Mid_Call). This DP is used to implement mid-call services, as is the case when the call-waiting service plays an audible beep to the caller, resulting in the caller pressing the hook-flash to answer the incoming call, or if the caller subscribes to the three-way calling service, he or she may depress the hook-flash to add a third party to an existing call. Because exit through DP 21 and DP 18 is common to many PICs, the description of the PICs below will omit them and discuss other exit criteria in detail.

PIC 1 — O_NULL: This is a catchall PIC that absorbs exceptions resulting from processing the call (see transitions leading from DPs

Figure 3.6 Example Originating Basic Call State Model. (After Figure A.2 in ITU-T, Intelligent Network Distributed Functional Plane Architecture, Recommendation Q.1204, Geneva, Switzerland, March 1993.)

20 and 21 and PIC 11 to this PIC in Figure 3.6). At this point, the call does not really exist. The only way to exit this PIC is through DPI, Origination_Attempt. If DPI is set (armed and trigger conditions have been met, which will always be the case for DPI), control passes to the next PIC.

PIC 2 — Authorize_Origination_Attempt: At this point, the SSP has detected that someone wishes to place a call. Under some circumstances (e.g., use of the line is restricted to a certain time of the day), the SSP may not allow initiation of a call. Such services will be provided in this PIC. In addition to DP 21, PIC 2 has two exit means: through DP 3 (Origination_Attempt_Authorized) to PIC

3, or through DP 2 (Origination_Denied) to PIC 11. The processing of DP 3 leads to termination of the call; otherwise, call processing enters PIC 3.

PIC 3 — Collect_Information: This is the point in the call where the dialing string is collected from the caller. In addition to DP 21, PIC 3 has two exit means: through DP 4 (Collect_Timeout) to PIC 11, or through DP 5 (Collected_Information) to PIC 4. If the format of the dialed string is incorrect, or the activity is timed out, DP 4 is set and the call is terminated. Otherwise, the call enters the PIC 4 through DP 5.

PIC 4 — Analyze_Information: At this point, the complete dial string is being translated to a routing address. In addition to DP 21, PIC 4 has two exit means: through DP 6 (Invalid_Information) to PIC 11, and through DP 7 (Analyzed_Information) to PIC 5. If the dial string cannot be successfully translated to a routing address, DP 6 is set and the call is terminated. Otherwise, DP 7 is set and the call enters PIC 5.

PIC 5 — Select_Route: For the routing address obtained in PIC

4, the SSP selects one or more physical routes toward that routing address. In addition to DP 21, PIC 5 has two exit means: through DP 8 (Route_Select_Failure) to PIC 11, and through DP 9 (Route_Selected) to PIC 6. If one or more physical routes cannot be selected (possibly due to focused network congestion), DP 8 is set and the call is terminated. Otherwise, DP 9 is set and the call enters PIC 6.

PIC 6 — Authorize_Call_Setup: Certain service features may restrict the type of calls that may originate on a given line or trunk. In addition to DP 21, PIC 6 has two exit means: through PIC 10 (Authorization_Failure) to PIC 11, and through DP 11 (Origination_Authorized) to PIC 7. If, for any reason, the authorization fails, DP 10 is set and the call is terminated. Otherwise, DP 11 is set and the call enters PIC 7.

PIC 7 — Call_Sent: At this point, control over the establishment of the call has been transferred to the T_BCSM object, and the O_BCSM object is waiting for a signal confirming that the call has been presented to the called party, or that the called party cannot be reached for a particular reason (it may be busy or did not answer the phone). In addition to DP 18 and DP 21, PIC 7 has four exits: If DP 13 (O_Called_Party_Busy) is set, the call is terminated. DP 12 (Route_Failure) is set if the network experiences congestion on the chosen route; in such a case, control passes to PIC 5 so that a different route can be selected for the call. When the called party is alerted, the T_BCSM informs the O_BCSM of this by setting DP 14 (O_Term_Seized); in such a case, control passes to PIC 8. If the T_BCSM informs the O_BCSM that the called party has answered the phone (possibly as a result of a race condition when the party called just happens to pick up the phone to make a call), DP 16 (O_Answer) is set and control passes to PIC 9 (skipping PIC 8).

PIC 8 — O_Alerting: At this point, O_BCSM is waiting for the called party to answer. Besides DP 18 and DP 21, this PIC has two exits: DP 15 (O_No_Answer) is set if the T_BCSM informs the O_BCSM that a call was not answered within a time period known to the T_BCSM. The processing of DP 15 terminates further processing of the call. If, on the other hand, the called party answers within the specified period, T_BCSM sends a respective message to the O_BCSM, which results in DP 16 (O_Answer) being set; call processing now moves to PIC 9.

PIC 9 — O_Active: At this point, the call is active, i.e., the parties are communicating with each other. In addition to DP 18 and DP 21, this PIC has two exits: If the called party hangs up the phone, DP 19 (O_Disconnect) is set and PIC 10 is entered (note that if the calling party disconnects, DP 21 will be set). If the network experiences problems while the call is active, DP 17 (O_Connection_Failure) is set and the call is terminated.

PIC 10 — O_Disconnect: Note that this PIC is reached when the called party disconnects the phone; i.e., the T_BCSM detects that the called party disconnected and sends a message to the O_BCSM about this event. In this PIC, the O_BCSM performs the necessary cleanup work (releasing call resources, etc.) and sets DP 20 (O_Disconnect_Complete) to terminate the call. DP 20 is the only exit criterion defined in this PIC.

PIC 11 — O_Exception: Except for PIC 1 and PIC 10, control from other PICs is passed into PIC 11 as a result of exceptional conditions arising during call processing. During normal processing of the call in other PICs, many resources may have been allocated (the SSP may have established a link with the SSP, trunks or lines may have been reserved for the call, etc.). If call processing fails, these resources need to be de-allocated. This PIC performs the needed cleanup to de-allocate any resources that may have been allocated during normal call processing. At the end of processing the exception and cleaning up the resource state, PIC 11 enters PIC 1 without any DP associated with this transition.

3.1.8 Terminating BCSM (T_BCSM)

The terminating-half call model state machine of the BCSM defined in Q.1204 [ITU92b] contains 8 PICs and 14 DPs. Figure 3.7 depicts the T_BCSM state machine. Note that the numbering of both the PICs and DPs continues from that of O_BCSM, instead of starting afresh. Thus, the first PIC of T_BCSM is numbered 12, and the first DP is numbered 22. As was the case with O_BCSM, some PICs have a common exit criterion. Namely, PICs 13 to 17 have a common exit criterion in the form of DP 35 (T_Calling _Party_Disconnect_and_Abandon). This DP is set if the calling party disconnects the call while it is in the middle of being set up at the T_BCSM, or if the called party prematurely abandons further call processing. Processing of DP 35 always results in a transition to PIC 12. PIC 16 and 17 also have an additional exit criterion in the form of DP 32 (T_Mid_Call). This DP serves the same purpose for the called party as DP 18 did for the calling party, i.e., it implements mid-call services. For the T_BCSM, because exit through DP 32 and 35 is common to many PICs, the description below will omit these and discuss other exit criteria in detail.

PIC 12 — T_Null: This is a catchall PIC that absorbs exceptions resulting from processing the call (see transitions leading from DPs 34 and 35 to this PIC in Figure 3.7). At this point, the call does not really exist; however, a message has been received from PIC 7 of the O_BCSM informing the T_BCSM to set up a call. DP 22 (Termination_Attempt) is set and the control passes to PIC 13. PIC 13 — Authorize_Termination_Attempt: This PIC verifies whether the call is to be passed to the terminating party. PIC 2, which is a counterpart in the O_BCSM to this PIC, ascertains whether the caller is authorized to initiate a call; this PIC establishes that the called party is authorized to receive a call, that its line has no restrictions against this type of call, and that the bearer capabilities of the caller and called party match. Besides DP 35, there are two exit criteria from this PIC: DP 23 (Termination_Denied) is set if the called party is not authorized (or has incompatible bearer

T_Calling_Party_Disconnect &

T_Calling_Party_Disconnect &

Figure 3.7 Example Terminating Basic Call State Model. (After Figure A.3 in ITU-T, Intelligent Network Distributed Functional Plane Architecture, Recommendation Q.1204, Geneva, Switzerland, March 1993.)

capabilities) to receive the call. In this case, the call is terminated. DP 24 (Termination_Authorized) is set otherwise, and the call proceeds to the next PIC.

PIC 14 — Select_Facility: At this PIC, the terminating resource (i.e., a line or trunk) is selected. Note that the T_BCSM object may reside on an originating or intermediate switch (not only on the terminating one), which means that on these switches it performs the job of finding a trunk to the next switch. Besides DP 35, there are two exit criteria from this PIC: DP 25 (T_Called_Party_Busy) is set if there are no resources to set up a call or if the called party is busy. In this case, the call is terminated. DP 26 (Terminating_Resource_Available) is set otherwise, and the call proceeds to the next PIC.

PIC 15 — Present_Call: At this PIC, the called party is alerted (via AN audible ringing tone) of an incoming call. Besides DP 35, there are three exit criteria from this PIC: through DP 27 (Presentation_Failure), DP 28 (T_Term_Seized), and DP 30 (T_Answer). DP 27 is set if the T_BCSM cannot, for any reason, alert the called party. Processing DP 27 results in the call being terminated. DP 28 is set if the called party is successfully alerted, in which case control enters PIC 16 and the O_BCSM is notified, causing it (the O_BCSM) to go into PIC 8 (O_Alerting). If the called party answers the phone, DP 30 is set and control passes to PIC 17 (bypassing PIC 16).

PIC 16 — T_Alerting: Note that the called party was already alerted in PIC 15; thus, this PIC may seem redundant. However, it serves the purpose of defining an upper bound on how long the called party is alerted. Such an upper bound is needed to prevent indefinite holding of network resources (trunks, lines, or computing resources) that have been acquired to process the call thus far. If within a preconfigured time at the T_BCSM no one picks up the phone, DP 29 (T_No_Answer) is set and the call is terminated. If the called party answers, DP 30 (T_Answer) is set and control passes to PIC 17. DP 35 is set if exceptional conditions warrant the termination of the call. DP 32 is set for mid-call services (control is passed back to PIC 16 on processing DP 32). PIC 17 — T_Active: At this point, the call enters the active state. As a result of processing DP 30, the O_BCSM is notified so that it also enters PIC 9, its equivalent of the active state. This PIC has four exit criteria. If the network experiences problems maintaining the active call, DP 31 (T_Connection_Failure) is set and the call is terminated. If the called party (i.e., the party corresponding to the T_BCSM) disconnects the call, DP 33 (T_Disconnect) is set and the processing enters the next PIC. If the calling party (i.e., the party associated with O_BCSM) disconnects the call, DP 35 is set and the call is terminated. If a mid-call event occurrs, DP 33 (T_Mid_Call) is set; after the service has been performed, control is passed back to PIC 17.

PIC 18 — T_Disconnect: This PIC is reached when the called party disconnects the call. The T_BCSM sends a message to the O_BCSM, causing the O_BCSM to set DP 19 and enter PIC 10. There is only one exit criterion from this PIC: DP 34 (T_Disconnect_Complete). This DP terminates further processing of the call by releasing any resources accrued thus far in maintaining the call.

PIC 19 — T_Exception: With the exception of PICs 12 and 18, control from other PICs is passed into PIC 19 as a result of an exceptional condition arising during call processing. During normal processing of the call in other PICs, many resources may have been allocated (the SSP may have established a link with the SSP, trunks or lines may have been reserved for the call, etc.). If call processing fails, these resources need to be de-allocated. This PIC performs the needed cleanup to de-allocate any resources that may have been allocated during normal call processing. After the processing of the exception is complete and the resource state has been cleaned up, PIC 19 enters PIC 12 without any DP associated with this transition.

+1 0

Post a comment