Signaling System No.7 Protocol Architecture And Sevices part 42

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.
Nội dung trích xuất từ tài liệu:
Signaling System No.7 Protocol Architecture And Sevices part 42The Advanced Intelligent Network (AIN 0.X, IN CS-X)The term Advanced Intelligent Network can be misleading. People oftenconsider AIN a separate entity from the IN. It is simply part of the evolution of theoriginal IN concept. AIN is a term that is primarily used in North America todescribe the evolution of the IN beyond the IN/1 phase. The AIN specificationsintroduced by Bellcore solidified and extended the concepts introduced by theearly IN standards. AIN 0 was the first version released. However, it is only givena brief introduction here because AIN 0.1 and AIN 0.2 have made it obsolete. BothAIN 0.1, and 0.2 are incremental releases toward the IN concept documented inAIN 1. As explained earlier, beginning with AIN 0.1, the ITU IN and BellcoreAIN standards align fairly well; although ITU uses the term IN and Bellcore usesthe term AIN, they both describe the same general architecture and call model. Thefollowing sections discuss IN CS-1 and AIN 0.1 as well as IN CS-2 and AIN 0.2together. Message encodings remain incompatible because of the differencesbetween ITU TCAP and ANSI TCAP. The examples use AIN messages withANSI TCAP encodings.Basic Call State Models (BCSM)One of the key differences between IN/1 and the succeeding AIN/IN CS phases isthe introduction of a formal call model. A call model is a definition of the callprocessing steps that are involved in making a call. During call processing in aswitch, 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 constitutedeach phase and what transitional events marked the entry and exit of each stage.Even within a vendors implementation, the delineation of stages could beambiguous. IN defines a Basic Call State Model (BCSM), which identifies thevarious 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 isessential for distributing service processing between the SSP and SCP because theSCP must identify the PIC processing that has been reached by SSPs from anumber of different vendors. The SCP can determine the call-processing contextbased on messages sent from specific DP, thereby allowing it to apply its ownlogic 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 ofentry events define the transitional actions that constitute entering into a PIC. Exitevents mark the completion of processing by the current PIC. The entry and exitevents provide a means of describing what constitutes being in a particular PICbecause the exact point at which one stage has been processed completely and thenext stage is beginning can be vague. The ITU and Bellcore standards specify thelist of events that constitute each of these PICs. Within each PIC, the switchsoftware performs call processing for that stage of the call. This is the same callprocessing that existed before the introduction of IN, except with a cleardelineation between processing stages. Figure 11-8. Call Model ComponentsDetection 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 havingexited the previous PIC and encountering the DP. IN processing can be invoked tocommunicate with the SCP to determine further information about the call orrequest instructions about how the call should be handled.DP is a generic term that identifies the insertion point for IN processing. Morespecifically, each DP is either a Trigger Detection Point (TDP) or an EventDetection Point (EDP).Trigger Detection Point (TDP)The TDP is a point at which the SSP can set triggers that execute when the TDP isencountered. The trigger represents an invocation point for an IN service. Triggersare provisioned at the SSP based on what call-processing events need interventionfrom the SCP. When a trigger has been subscribed for a particular TDP and theTDP is encountered, the SSP software launches a query to the SCP. Triggers canbe subscribed with different granularities, ranging from an individual subscriberline to the entire SSP. The following are the different levels for which triggers canapply. • 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 definethe trigger types that can be encountered at each TDP. For example, the IN CS-2defines 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 isarmed to request that the SCP be notified when the particular EDP is reachedduring call processing. The SCP can then determine how the call should be furtherdirected. For example, the SCP might want to be notified before a user isconnected to a busy treatment so that a call attempt can be made to anothernumber without the phone user being aware that a busy signal has beenencountered.An EDP can be one of two types: an EDP-Request or an EDP-Notification. AnEDP-R requests that the SSP stop call processing (except in the case ofO_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 theSSP send an EDP-Notification but continue call processing. The SCP does notrespond to the notification. The S ...