Cs1 Core Inap New

HANDOUT
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
ALCATEL IMPLEMENTATION OF ETSI CS1 CORE INAP
Edition : 02
770 00828 0300VHBE
ALCATEL UNIVERSITY
The Alcatel University put in a great effort to give you this document. In case you have any remarks, do not hesitate to send us your comments. Our Training Directory describes all training programmes and modules this document (and others) is used in. This document was especially written for use during class instruction. The contents of this document is generic. It deals with concepts and principles, rather than with the latest releases of and modifications to the product delivered to the customers. International audiences use this document. It is therefore written in a clear, concise and above all, consistent language.
ALCATEL UNIVERSITY
ii
770 00828 0300VHBE
TABLE OF CONTENTS
1. THE BASIC CALL STATE MODEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2. OPERATIONS USED DURING A SIMPLE IN CALL INITIATED BY THE SSP . . 11
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 InitialDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RequestReportBCSMEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EventReportBCSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ReleaseCall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ResetTimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Activity test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operations related to information for a specific call. . . . . . . . . . . . . . . . . . . Cancel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Special circumstances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 13 15 15 16 18 18 18 19 19 20
3. OTHER OPERATIONS USED DURING A CALL . . . . . . . . . . . . . . . . . . .

3.1 CollectInformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 InitiateCallAttempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
21 22
4. SRF CONNECT PROCEDURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.1 Overview of used operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2 IP integrated in SSP or directly attached to it (case A). . . . . . . . . . . . . . . . 24 4.3 The SRF is attached to the SSP but can communicate directly to the SCP (caseB) . 25 4.4 The EstablishTemporaryConnection operation . . . . . . . . . . . . . . . . . . . . . . 26 4.4.1 The assisting SSF receives the ConnectToResource . . . . . . . . . . . . . 26 4.5 The AssistRequestInstructions operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.6 IP integrated or directly attached to an assisting SSP (case C) . . . . . . . . 28 4.7 Case D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.8 The handoff procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5. SENDING ANNOUNCEMENTS AND COLLECTING INFO . . . . . . . . . .

5.1 Operations used to exchange info with the service user . . . . . . . . . . . . . . 5.1.1 PlayAnnouncement (PA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 SpecializedResourceReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.3 PromptAndCollectUserInformation (P&C) . . . . . . . . . . . . . . . . . . . . . . . 5.1.4 Cancel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Disconnection of the SRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
33 33 34 34 36 36 37
6. TRAFFIC MANAGEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1 CallGap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
43
770 00828 0300VHBE
iii
ALCATEL UNIVERSITY
6.2 Service Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Activate Service Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 ServiceFilteringResponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44 44 45
7. CHARGING RELATED OPERATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.1 Charging scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 SendChargingInformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 FurnishChargingInformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 ApplyCharging & ApplyChargingReport . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
49 50 51 52
7.5 An example of the operator specific info available in the charging related operations 55
8. CHARGING SCENARIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
8.1 Scenario 1 Charging completely done in a charging point outside the SSP. . 61 8.2 Scenario 2 charging completely done in the SSP. . . . . . . . . . . . . . . . . . .
62
8.3 Scenario 3 Charging done in as well the SSP as a charging point outside the SSP 63 8.4 Determination of Charging Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9. OVERVIEW OF THE OPERATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10. SCENARIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11. THE ALCATEL ADDED OPERATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.1 AlcFree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 AlcJoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 AlcSplit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67 71 77
77 77 77
770 00828 0300VHBE ALCATEL UNIVERSITY iv
1.
1. THE BASIC CALL STATE MODEL

The Basic Call State Model The BCSM identifies Points In basic Call and connections processing (PICs) or CCF activities, Detection points (DPs) that indicate PICs at which transfer of control between call control and the Service Control Function can occur, transitions between PICs and finally events from and to PICs. Following figure outlines the BCSM functionality. Figure 1 : The BCSM components
Transition
Event m . . . Event n
Events associated with a transition
DP PIC
. . . .
DP PIC
Functional separation is made between the originating half BCSM and terminating half BCSM, each of which is managed by a functional separate BCM in the SSF/CCF. This can be the same BCM in one switch or a separate BCM in another switch. O and T is prefixed to certain originating and terminating DP names. Originating BCSM Following figure illustrates the originating portion of calls of the BCSM.
770 00828 0300VHBE
ALCATEL UNIVERSITY
1.
THE BASIC CALL STATE MODEL
Figure 2 : Originating BCSM

O_Abandon 1. O_Null & Authorize Origination_Attempt 6. O_Exception
10 1
Orig. Attempt_Authorized
2. Collect_Info. Route_Busy 2 Collected_Info.
3. Analyse_Info.
3
Analysed_Info. 4 Route_Select_Failure O_Answer 5 O_Call_Party_Busy
4. Routing & Alerting
7 9 O_Disconnect 8 O_Mid_Call
5. O_Active
6 O_No_Answer
Transition
Detection point (DP)
Point in call (PIC)
The description for each of the PICs in the originating half of the BCSM are described below. 1.O_Null & Authorize_Originating_Attempt: this PIC has following functions:
-
the interface (trunk/line) is idle and supervision is performed, an indication is given from an originating party to place an outgoing call (off hook, N7 IAM (=Initial Address Message), etc.) and the authority/ability to place the call is verified.
2.Collect_Information: this PIC has following functions:

-
initial information package/dialling string (service code, prefixes, etc.) are being collected from the originating party and are examined to detect end of dialling (no further actions are required if the en bloc signalling method is used i.e. N7 IAM message),
ALCATEL UNIVERSITY
770 00828 0300VHBE
1.
the support function of the SSF/CCF to collect subsequent digits according to the feature code (trigger criteria).
3.Analyse_Information: this PIC has following functions:

-
the information of DP2 is analyzed and/or translated according to the numbering plan to determine routing address and call type (e.g. local, transit or international IN exchange call); this determines the location of the SSF.
4.Routing & Alerting: this PIC has following functions:

-
the routing address and call type are interpreted and the next route is selected (with the directory number a path is setup to the physical port), authority of originating party to place this particular call is being verified, the call is being processed by the terminating half BCSM; continued processing of call setup (e.g. ringing) is taking place.
5.O_Active: this PIC has following functions:

-
the connection is established between originating and terminating party and a account/charging data may being collected and call supervision is being provided.
6.O_Exception: this PIC has following functions:

-
default handling of the exception condition is provided to ensure no resources remain inappropriate allocated (error information to SCF closing the relationship SSF/SCF, SCF/SRF, etc.).
Terminating BCSM Following figure illustrates the terminating portion of calls of the BCSM.
770 00828 0300VHBE
ALCATEL UNIVERSITY
1.
Figure 3 : Terminating BCSM

T_Abandon 11. T_Exception 7. T_Null & Authorize Termination_Attempt
18
Term. _Attempt_Authorized
13
12
8. Select_Facility & Present_Call
T_Busy
14
9. T_Alerting
T_No_Answer
15
T_Answer
17
10. T_Active
T_Disconnect
16
T_Mid_Call
The description for each of the PICs in the terminating half of the BCSM are described below. 7.T_Null & Authorize_Terminating_Attempt: this PIC has following functions:
-
the interface (trunk/line) is idle and supervision is performed, an indication is given of an incoming call received from the originating half BCSM and authority to route this call to the outgoing party is being verified.
8.Select_Facility & Present_Call: this PIC has following functions:

-
a particular available resource is being selected and the terminating resource is being informed of an incoming call (ringing, line seizure, Q.931 setup message(ISDN), IAM message).
9.T_Alerting: this PIC has following functions:

-
an indication is sent to the originating half BCSM that the terminating party is alerted; continued processing of call setup and waiting for the call to be answered.
10.T_Active: this PIC has following functions:

-
an indication is sent to the originating half BCSM that the terminating party has answered and the connection is established between originating and terminating party and call supervision is being provided.
ALCATEL UNIVERSITY
770 00828 0300VHBE
1.
11.T_Exception: this PIC has following functions:

-
default handling of the exception condition is provided to ensure no resources remain inappropriate allocated (error information to SCF closing the relationship SSF/SCF, SCF/SRF, etc.).
BCSM Detection Points Certain basic call and connection events may be visible to IN service logic. DPs are the points in call processing at which these events are detected. DPs for the BCSM are identified in previous chapters and shown in following figures.
770 00828 0300VHBE
ALCATEL UNIVERSITY
1.
Figure 4 : OBCSM PICs and DPs
DP 10
Active
DP 8
ALCATEL UNIVERSITY
DP 9

Null PIC 1 DP 1 PIC 2 DP1: Originating Attempt DP2: Collected Info DP3: Analyzed Info DP4: Route Select Failure DP5: OCalled busy DP6: ONo Answer DP7: OAnswer DP!: OMiddCall DP9: ODisconnect DP10: OAbandon DP 2 PIC 3 DP 3 PIC 4
PIC 6

Waiting for terminating end response DP 7 PIC 5
DP 4 DP 5 DP 6
Q.71 or Q.931 state Detection Point Point In Call
770 00828 0300VHBE
1.
Figure 5 : TBSCM PICs and DPs

PIC 11
Detection point PIC
A DP can be armed in order to notify an IN service logic that the DP was encountered, and potentially to allow IN service logic to influence subsequent call processing. If a DP is not armed then the SSF/CCF continues call processing without SCF involvement. Four types of DPs are identified: Trigger Detection Point Request (TDPR), Trigger Detection Point Notification (TDPN), Event Detection Point Request (EDPR), Event Detection Point Notification (EDPN). DPs are characterized by four attributes: a) Arming/disarming mechanism: A DP may be statistically or dynamically armed. TDP are statically armed and disarmed by the operator of the SSF. EDP are dynamically armed by the SCF within the context of a callassociated IN service control relationship. b) Criteria: It is the condition that has to be met in order to notify the SCF that the TDP was encountered (not applicable for EDP). This criteria can be based on individual lines/trunks, groups (Centrex) or offices (PABXs).
770 00828 0300VHBE
Q.71 or Q.931 State
DP12: Terminating Attempt DP13: TCalled bust DP14: TNo Answer DP15: TAnswer DP16: TMid Call DP17: TDisconnect DP18: TAbandon

Null PIC 7 DP 12 PIC 8 Call present PIC 9 Call received DP 15 PIC 10 Active DP 16
DP 18
DP 17
ALCATEL UNIVERSITY
1.
c) Relationship: If a DP is armed and the criteria is met, then the SSF may have a IN relationship with the SCF for the purpose for call/service processing. It is of two kinds:
-
control based relation if the SCF is able to influence call processing, monitor based relation if the SCF is not able to influence call processing.
d) Call processing suspension: The SSF may suspend call processing to allow the SCF to influence subsequent call processing. When it does, it sends an information to the SCF requesting instructions and waits for an answer. When it does not, the SSF notifies the SCF that it had encountered a DP and does not expect an answer. BCSM DP processing DP processing involves:
traffic management determining if DP criteria are met handling service logic interaction when invoking new instances of service (IN or not) logic formulating information flows to send to one or more SCFs
Following figure depicts DP processing for each DP type.
ALCATEL UNIVERSITY
770 00828 0300VHBE
1.
Figure 6 : DP processing for each DP type

CCF BCM SSF SCF
Basic call process function (BCSM PIC) DP DP Resume DP DP Resume DP DP
DP processing Trigger criteria DP not armed
FIM traffic management feature interactions message formulation
Service logic
TDPN
Trigger notification Trigger request instructions Responding instruction & request for EDPRa)
TDPR
INITPIC BCSM PIC DPR arming
Perform instruction & arm EDPR
DP DP
DPR armed EDPR
Event request instructions Responding instruction & request for EDPNa)
INITPIC BCSM PIC DP DP Resume DPN arming DPN armed
Perform instruction & arm EDPN
EDPN Event notification
DP TDP EDP R/N PIC
Detection point Trigger detection point Event detection point Request/notification Point in call
770 00828 0300VHBE
ALCATEL UNIVERSITY
1.
ALCATEL UNIVERSITY
10
770 00828 0300VHBE
2.
OPERATIONS DURING USED SIMPLE INITIATED SSP A IN CALL BY THE
2. OPERATIONS USED DURING A SIMPLE IN CALL INITIATED BY THE SSP

An SSF can be activated via different possibilities :
-
If the CCF indicates that an armed TDP, related to a possible IN call is encountered. Then the SSF must perform following actions: check if call gapping or service filtering mechanisms are active. If service filtering is active, the call is counted and the SSF instructs the CCF to release the call. check if the SCF is accessible. determine if DP criteria are met.
If the previous steps allow it and if the DP is a TDPR ,an InitialDP must be sent to the SCF. The SSF must wait for further instructions of the SCF before continuing.
-
If the SSF receives from the SCF the InitiateCallAttempt related to a new transaction. This will be handled in a separate chapter.
2.1 InitialDP
Via this operation the SSF initiates the dialogue with the SCP for this call. It is sent after the first TDPR is met. If Call gapping and Signalling N7 overload are not there for the call, then the InitialDP operation is sent. InitialDPArg serviceKey calledPartyNumber callingPartyNumber callingPartysCategory cGEncountered iPSSPCapabilities iPAvailable locationNumber originalCalledPartyID highLayerCompatibility serviceInteractionIndicators ::= SEQUENCE { [0] ServiceKey , [2] CalledPartyNumber OPTIONAL, [3] CallingPartyNumber OPTIONAL, [5] CallingPartysCategory OPTIONAL, [7] CGEncountered OPTIONAL, [8] IPSSPCapabilities OPTIONAL, [9] IPAvailable OPTIONAL, [10] LocationNumber OPTIONAL, [12] OriginalCalledPartyID OPTIONAL, [23] HighLayerCompatibility OPTIONAL, [24] ServiceInterActionIndicators OPTIONAL,
770 00828 0300VHBE
11
ALCATEL UNIVERSITY
2.
OPERATIONSUSEDDURINGASIMPLEINCALLINITIATEDBYTHESSP
additionalCallingPartyNumber forwardCallIndicators bearerCapability eventTypeBCSM redirectingPartyID redirectionInformation }
[25] AdditionalCallingPartyNumber OPTIONAL, [26] ForwardCalllIndicators OPTIONAL [27] BearerCapability OPTIONAL, [28] EventTypeBCSM OPTIONAL [29]RedirectingPartyID OPTIONAL, [30]RedirectionInformation OPTIONAL,
The service key is used to address the correct application within the SCF. Previously in the Alcatel INAP operations , the SSN at SCCP level was used to address a correct application. CGencountered indicates the type of call gapping if encountered.
The original calledparty Id can be necessary for instance in the case of forwarding. The location number conveys the geographical area address for mobility services. It is required when the calling party number doesnt contain any information about the geographical location of the calling party. This is required when for instance origin dependent routing is applied and the calling party is a mobile subscriber. The forward call indicators specify if the call will be treated as a national or international call. And also the signalling capabilities of the network access , the preceding network connection and the succeeding network connections. The eventTypeBCSM indicates the armed DP event that caused the InitialDP operation. IP available indicates if an IP is attached and available at the SSP (IP available or IP not available). This will later influence the scenario for sending announcements to the subscribers. See the chapter about SRF connect procedures. IPSSP capabilities indicates which SRF resources are supported within the SSP and available. It is defined by the network operator. We will encode the IPSSPCapabilities as an octet string of 4 bytes. Every bit represents a capability, so maximum 32 capabilities can be indicated.. Every bit is called a Basic Function. If the Basic Function bit is 0, then the capability is not available. The use of it is market dependent. A Basic function can for instance indicate a set of announcements available.
ALCATEL UNIVERSITY
12
770 00828 0300VHBE
2.
2.2 Connect
The SCF orders the SSF to perform call processing actions to route or forward a call to a specified destination. As indicated in the parameters of the operation, the SSF can use calling party information, such as dialled digits. Also existing setup information, such as a list to a trunkgroup can be used for this purpose if provided by the SCF. The connect parameters are the following : ConnectArg destinationRoutingAddress alertingPattern
::= SEQUENCE { [0] DestinationRoutingAddress, [1] AlertingPattern [2] CorrelationID [3] CutAndPaste [7] RouteList [8] ScfID OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL,
correlationID cutAndPaste originalCalledPartyID routeList scfID serviceInteractionIndicators callingPartyNumber callingPartysCategory redirectingPartyID redirectionInformation }
[6] OriginalCalledPartyID OPTIONAL,
[26] ServiceInteractionIndicators OPTIONAL, [27]CallingPartyNumber OPTIONAL, [28]CallingPartysCategory OPTIONAL, [29]RedirectingPartyID OPTIONAL, [30]RedirectionInformation OPTIONAL,
The destinationRoutingAddress can also include a correlation Id and SCF Id if it is used in the context of an handoff procedure. Then the separate parameters correlation ID and SCP ID shouldnt be used. The scfId indicates the SCF identifier such that the assisting SSF knows to which SCF the collected info must be sent. (See the chapter about SRF connect procedures) The correlation id is used by the SCF to associate the AssistRequestInstructions from the assisting SSF with the InitialDP from the initiating SSF. The routeList is used to select an outgoing trunkgroup.
770 00828 0300VHBE
13
ALCATEL UNIVERSITY
2.
Alcatel added some parameters to the Connect operation to support backward compatibility with the Alcatel INAP protocol.
-
doNotJoin [99] IMPLICIT NULL OPTIONAL, legIdA [98] LegId DEFAULT (2), legIdB [97] LegId DEFAULT (1), callingPartyPNP [96] OCTET STRING(SIZE(4..8)) OPTIONAL, calledPartyPNP [95] OCTET STRING(SIZE(4..8)) OPTIONAL, callingPartyBCGIdentity [94] OCTET STRING(SIZE(7)) OPTIONAL, reservedTrunk [93] ReservedTrunkIndicator DEFAULT {0}, genericNumberSet [92] IMPLICIT SEQUENCEgenericNumber[0] IMPLICIT OCTET STRING(SIZEx))} OPTIONAL originatingPTNXIdentity [90] IMPLICIT INTEGER(1..32000) OPTIONAL, originatingPTNXIdentity [90] IMPLICIT INTEGER(1..32000) OPTIONAL,
In order to detect a route select failure after a Connect, it is necessary to explicitly arm the Route Select Failure EDP via the RequestReport BCSM Event before sending a Connect.
ALCATEL UNIVERSITY
14
770 00828 0300VHBE
2.
2.3 Continue
At some DPs the SSF suspends call processing to wait for SCF instructions. With the Continue operation , the SCF orders the SSF to proceed with call processing at the DP, where it suspended and to go to the next PIC in the BCSM. The SSF continues call processing without substituting new data from the SCP.
2.4 RequestReportBCSMEvent
The SCF uses this operation to ask the SSF to monitor callrelated events and send a notification to the SCF when the event is detected. The supplied information consists of a list of information. For every event, it contains :
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED -
EventTypeBCSM monitor mode legID dpSpecificCriteria
Possible BCSM event types are :

-
originating attempt authorized, collected info analyzed information route select failure OCalled Party busy O No answer O answer O Midcall O Disconnect O abandon Terminating attempt authorized T called party busy T No answer
770 00828 0300VHBE
15
ALCATEL UNIVERSITY
2.
T answer T mid call T Disconnect T abandon
The monitor mode can have 3 values :

-
interrupted notifyAndContinue transparent
(0) (1) (2)
Interrupted means that the SSF reports the event received on the indicated leg as a request. This value is also used to end the monitoring of a previously requested charging event.
If the mode is NotifyAndContinue, the event is reported as a notification. This means that the event is also processed on the other leg. In transparent mode, the SCF is not notified, and the event detected on the indicated leg is also processed on the other leg.. The dPSpecificCriteria indicates information specific to the EDP to be armed. DpSpecific criteria can be a number of digits or an application timer. The SCF can specify the number of digits to be collected by the SSF for the CollectedInfo event. When all digits are collected, the SSF reports the event to the SCF. For the No answer event , the SCF can specify a timer. If the user doesnt answer the call within the specified time, the event is reported to the SCP. After receipt of the RequestReportBCSMEvent operation, the SSF arms the requested EDPs as indicated. Requested events are monitored :
-
until ended by a transparent monitor mode, until the end of the call, until the EDPs are detected or until the corresponding leg is released.
2.5 EventReportBCSM
This operation is used from SSF to SCF to report a call related event such as busy or no answer.
ALCATEL UNIVERSITY
16
770 00828 0300VHBE
2.
The reporting of these events is previously requested by the SCF via the RequestReportBCSMEvent. Each of the previously requested events in the RequestReportBCSMEvent is reported in a separate EventReportBCSM operation. The event must be an armed EDP. The information carried by this operation is the following :
-
eventTypeBCSM, event specific information BCSM the Leg id and miscellaneous call info (request > EDPR or notification > EDPN). This indicates whether the event report results from a RequestReportBCSMEventRequest which monitor mode was interrupt or Notify&Continue
The event specific information can be different for each type of BCSM event : collected info analyzed information route select failure OCalled Party busy O No answer O answer O Midcall O Disconnect T called party busy T No answer T answer T mid call T Disconnect The leg id indicates the party in the call for which the event is reported. leg id 1 indicates the party present at the InitialDP, or the party created with an InitiateCallAttempt. leg id 2 indicates the party created with a connect operation. Default leg id =1 for CollectedInfo, AnalyzedInformation OAbandon and TAbandon. Default leg id =2 for RouteSelectFailure, OcalledPartyBusy, ONoAnswer, OAnswer, TCalledPartyBusy,, TNoAnswer and TAnswer. cause cause the called party number the called party number cause cause
770 00828 0300VHBE
17
ALCATEL UNIVERSITY
2.
2.6 ReleaseCall
This operation allows the SCF to instruct the SSF to release an existing call for all involved parties. This operation can also be sent to an assisting SSF, but only in the case of an handoff procedure. The only parameter that can be supplied is a cause.
2.7 ResetTimer
Via this operation, the SCF instructs the SSF to reset certain application timers. This is to avoid timing out in the SSF, for instance used, when announcements are sent and assisting SSFs are used. The supplied info is a timer identity and a timer value.
2.8 Activity test

The ActivityTest is initiated by the SCF to check if a dialogue between SCF and SSF is still existing. It is a class 3 operation . If Everything is OK the SSF should send a result.
ALCATEL UNIVERSITY
18
770 00828 0300VHBE
2.
2.9 Operations related to information for a specific call.

A SCF can ask an SSF to record specific information about a single call via the CallInformation Request. This specific call information is sent by the SSF to the SCF in the CallInformation Report CallInformationRequest ARGUMENT CallInformationRequestArg ERRORS{ MissingParameter, ParameterOutOfRange, RequestedInfoError
SystemFailure, TaskRefused UnexpectedComponentSequence, UnexpectedParameter, } CallInformationReport ARGUMENT CallInformationReportArg Information that can be asked for is for example :
-
call attempt elapsed time, call stop time, call connected elapsed time, called address and release cause.
2.10 Cancel
A Cancel operation can be initiated by the SCF and sent to the SSF or SRF to cancel previous sent PlayAnnouncement and PromptAndCollectUserInformation operations. If the Cancel is used to delete a previously invoked PA or P&C the cancel must include an invoke id.
770 00828 0300VHBE
19
ALCATEL UNIVERSITY
2.
The Cancel operation can also be used to cancel all outstanding requests of the following operations :
-
EventReportBCSM ApplyChargingReport CallInformationReport
2.11 Special circumstances

If the calling party abandons the call before it is answered, then the SSF should instruct the CCF to clear the call and ensure that all resources allocated to the call are released.
-
If a CallInformationRequest is pending, first a CallInformationReport must be sent. If an Abandon DP is armed as an EDPR, an EventReportBCSM operation must be sent. The SSF must wait for instructions of the SCF before continuing. If an Abandon DP is armed as an EDPN, an EventReportBCSM operation must be sent. The SSF can terminate.
In any state of the stable call, one of the call parties can disconnect. The following procedures are similar as in the previous case.
-
If a CallInformationRequest is pending, first a CallInformationReport must be sent. If the Disconnect DP is armed as an EDPR, an EventReportBCSM operation must be sent. The SSF must wait for instructions of the SCF before continuing. If the Disconnect DP is armed as an EDPN, an EventReportBCSM operation must be sent. The SSF can terminate.
ALCATEL UNIVERSITY
20
770 00828 0300VHBE
3.
OTHER OPERATIONS USED DURING A CALL
3. OTHER OPERATIONS USED DURING A CALL

3.1 CollectInformation
With this class 2 operation , the SCF requests the SSF to prompt a calling party to input destination information and collect it according a specific numbering plan. This can for example be used in a VPN call scenario. An SSF can invoke an initial DP. If the SCP determines that more information from the calling party is required before continuing processing, he can send a CollectInformation operation. Then the SSF will collect destination information from the calling. This operation uses only the resources of the SSF and CCF to collect additional information, this in contrast to the PromptAndCollectUserInformation operation. This operation can only be used for a call which is still in set up phase. The CollectInformation operation is normally associated with a RequestReportBCSMEvent operation to arm DP2 (collected info) and specify the number of digits to be collected. When the required number of digits are received, DP2 is encountered and an EventReportBCSM will send the received digits to the SCF. Figure 7 : Collect info procedure After digit analysis Call handling decides SSP it is an international call and only charging info is required SCP Initial DP(calledPartyNumber = 00, eventTypeBCSM = DP3)
RequestReportBCSMEvent (DP2, mode = interrupted, DPspecificcriteria = number of digits) CollectInformation The SSP collects the requested info and sends them to the SCP
After analysis, the SCP decides that additional info is required
EventReportBCSM (DP2, collectedinfo)
770 00828 0300VHBE
21
ALCATEL UNIVERSITY
3.
OTHER OPERATIONS USED DURING A CALL
3.2 InitiateCallAttempt
Some calls are initiated by the SCP , for example the wake up call. Then the SCP sends the InitiateCallAttempt operation to the SSF to create a new call to one call party using the addressing information as provided by the SCF. An EDPR is armed on answer and also for all call failure events. This is because the SCF initiated the call and so has to treat the call when one of the events is encountered. The InitiateCallAttempt shall be sent together with a Continue operation Figure 8 : Wake up SSP InitiatecallAttempt
SCP
RequestReportBCSMEvent (DP=answer, mode = interrupted, DPspecificcriteria = number of digits)
EventReportBCSM (DP=answer)
AN ANNOUNCEMENT IS SENT
Release
The InitiateCallAttempt can also be used to support the feature of Call Duration Advice (CDA)
ALCATEL UNIVERSITY
22
770 00828 0300VHBE
4.
SRF CONNECT PROCEDURES
4. SRF CONNECT PROCEDURES

The InitialDP operation contains the parameter IPSSPcapabilities, which indicates the SRF functions available at the SSP. So the SCP will know whether assisting SSPs are required or not. It can be that the help of another SSP is required to communicate to an IP functionality. If the IP functionality is not required for the call anymore, then 2 possibilities exist :
-
The call responsibility is returned to the initiating or assisting SSP. This is the case in the assisting procedure. The call responsibility is kept in the assisting SSP. This is the case in the handoff procedure.
Several possibilities are described in this chapter.

4.1 Overview of used operations

EstablishTemporaryConnection This operation is used by the SCF to order the SSF to create a connection to a resource (an SRF or an assisting SSF) for a limited period of time. This is used for example to play announcements, to collect user information. It is for example used in the assist procedure. ConnectToResource This class 2 operation is sent from the SCF to the SSF to connect a call from the SSF to the SRF. The ConnectToResource operation contains the physical location of the SRF. This is only used in the case that the SSF relays all operations to the SRF and all responses from the SRF to the SCP. The ConnectToResource is used if the IP cannot communicate directly to the SCP. AssistRequestInstructions This operation is some kind of response to the EstablishTemporaryConnection or Connect (in case of handoff). This operation is sent by the assisting SSF or SRF when the initiating SSF has set up a connection to the SRF or the assisting SSF The use of these operations will become more clear in the discussion of the different connect procedures.
770 00828 0300VHBE
23
ALCATEL UNIVERSITY
4.
4.2 IP integrated in SSP or directly attached to it (case A).
Figure 9 : IP integrated in SSF or directly attached to it.
SCP
SCF
CASE A
IP
(can be integrated or nonintegrated)
SSP SSF CCF SRF
In case A, the IP is integrated in the SSP or directly attached to it. The SCP cannot communicate directly with the IP, so all operations exchanged between SCP and IP are relayed via the SSP. It can for instance be that the SSP has to do a protocol translation. Figure 10 : The case A procedure
SCP
SSP
IP
Setup request Connect to Resource
Setup response
The dotted lines represent a kind of signalling messages between the SSP and IP. It can be that this signalling is based on TCAP or DSS or another system. If SSP and IP are integrated, the communication between them is of course implementation dependent.
ALCATEL UNIVERSITY
24
770 00828 0300VHBE
4.
4.3 The SRF is attached to the SSP but can communicate directly to the SCP (caseB)
Figure 11 : SRF can communicate directly with the SCP
CASE B
SCP SCF
SSP
IP SSF CCF SRF
In case B the IP is directly attached to the SSP. First the SCF orders the SSP to establish a temporary connection to the IP. Since The IP can communicate directly to the SCP, an additional message to the SCP is required to indicate that the IP is ready. This is the Assist Requestinstruction operation. The SCF can communicate directly with the IP, the relaying function of the SSP is not required anymore. Although the SSP can function as an STP. Figure 12 : The case B procedure
SCP
Initiating SSP
Setup request
IP
Establish Temporary Connection

(correlation ID = 1, SCFID = 96)
Setup response
Assist Request Instructions

(correlation ID = 1, SCFID = 96)
770 00828 0300VHBE
25
ALCATEL UNIVERSITY
4.
4.4 The EstablishTemporaryConnection operation

As shown in the previous and following figures the EstablishTemporaryConnection is used to create a connection between an initiating SSF and an assisting SSF in the service assist procedure. It can also be used to create a connection between an SSF and SRF, where the SRF can be separately addressed. Following parameters are defined for the EstablishTemporaryConnection
-
assistingSSPIPRoutingAddress correlationID scfID serviceInteractionIndicators
Only the first parameter is mandatory and it indicates the destination address of the SRF or the assisting SSF for the assist procedure. Part of this address can be a correlation identity and an SCF identity. The correlation id is used by the SCF to associate the AssistRequestInstructions with the InitialDP from the initiating SSF.
4.4.1 The assisting SSF receives the ConnectToResource

The following can happen:
-
A SCFSRF operation is received, the assisting SSF should relay this information to the related SRF. This can be the following SCFSRF operations Play Announcement PromptAndCollectUserInformation Cancel
An SRFSCF operation is received and must be relayed to the SCF. This can be the following SCFSRF operations SpecializedResourceReport a return result from a PromptAndCollectUserInformation.
An assisting SSF becomes idle again after the receipt of a bearer channel disconnect from the initiating SSF.
ALCATEL UNIVERSITY
26
770 00828 0300VHBE
4.
4.5 The AssistRequestInstructions operation

The AssistRequestInstructions is initiated by the assisting SSF or SRF as a reaction to the EstablishTemporaryConnection. The SCF shall ask the initiating SSP to continue the processing of the call in the future. The SCF Identity provided in the EstablishTemporaryConnection identifies the SCF to which the AssistRequestInstructions must be sent. The Assist Request Instructions from the SRF carries a correlation ID to correlate it with the Initial DP from the initiating SSP. AssistRequestInstructionsArg ::= SEQUENCE { correlation ID iPAvailable
[0] CorrelationID [1] IPAvailable [2] IPSSPCapabilities
, OPTIONAL, OPTIONAL,
OPTIONAL
iPSSPCapabilities extensions }
[3] SEQUENCE SIZE(1..numOfExtensions) OF Extensionfield
The value of the Correlation Id may be supplied by the EstablishTemporaryConnection. If the AssistRequestInstructions was received from an assisting SSF, the SCP sends a ConnectToResource, followed by a PlayAnnouncement or a PromptAndCollectUserInformation. If the AssistRequestInstructions was received directly from an SRF, the SCP sends directly a PlayAnnouncement or a PromptAndCollectUserInformation operation. So, if the SRF can communicate directly to the SCP, no ConnectToResource is used.
770 00828 0300VHBE
27
ALCATEL UNIVERSITY
4.
4.6 IP integrated or directly attached to an assisting SSP (case C)

An assisting SSF is activated after the receipt of a connect from another SSF indicating that an assist is required. Then the assisting SSF sends an AssistRequestInstructions to the SCF, and waits for instructions from the SCF. Following operations can be received by the assisting SSF from the SCF :
-
PromptAndCollectUserInformation PlayAnnouncement FurnishChargingInformation, ApplyCharging, SendChargingInformation, ConnectToResource, ReleaseCall (only used in the handoff case). Figure 13 : IP integrated or directly attached to an assisting SSP (case C)
CASE C
SCP SCF
Initiating SSP SSF CCF
Assisting SSP SSF SRF CCF
IP
In case C ,the IP is integrated or directly attached to another SSP (an assisting SSP) than the one communicating with the SCP. But the operations to and from the SCP are relayed via that other SSP, that is the reason why this method is called the assist method. On completion of the interaction with the user for announcement and additional information collection, control is returned to the first SSP.
ALCATEL UNIVERSITY
28
770 00828 0300VHBE
4.
Figure 14 : scenario case C
SCP
Initiating
SSP
Assisting SSP
IP
Setup request Establish Temporary Connection Setup response
Connect To Resource
4.7 Case D
In case D ,the IP is integrated or directly attached to another node then the SSP communicating with the SCP. The SCP can communicate directly with the SRF. An establishment of a transaction to the assisting exchange is not required, so it neednt be an SSP. On completion of the interaction with the user for announcement and additional information collection, control is returned to the first SSP.
770 00828 0300VHBE
29
ALCATEL UNIVERSITY
4.
Figure 15 : Case D
CASE D
SCP SCF
SSP SSF
Exchange CCF CCF SRF
IP
Figure 16 : scenario case D
SCP
SSP
Exchange
IP
Setup request Establish Temporary Connection Setup request Setup response Setup response
ALCATEL UNIVERSITY
30
770 00828 0300VHBE
4.
4.8 The handoff procedure

Case e describes the handoff procedure , the configuration is similar as in case c. The difference is that in the hand off procedure, after user interaction the control is retained at the assisting SSF. Here no Establish Temporary Connection is used, but a Connect operation. This is because after the interaction with the service user and the SRF , the control remains at the assisting SSF. Figure 17 : scenario case E, the handoff case
SCP
Initiating SSP
Assisting SSP
IP
Setup request
Connect
Setup response
Connect To Resource
770 00828 0300VHBE
31
ALCATEL UNIVERSITY
4.
Figure 18 : The hand off procedure
CASE E
SCP SCF
Initiating SSP SSF CCF

Assisting SSP SSF SRF CCF
IP
ALCATEL UNIVERSITY
32
770 00828 0300VHBE
5.
SENDING ANNOUNCEMENTS AND COLLECTING INFO
5. SENDING ANNOUNCEMENTS AND COLLECTING INFO

5.1 Operations used to exchange info with the service user
5.1.1 PlayAnnouncement (PA)

This operation instructs the SRF to play an announcement. In the case of an assist procedure with a second SSP or in the case of a separate IP that can communicate directly to the SCP, it is used by the SCF after an AssistRequestInstructions.
If the IP can communicate directly to the SCP, the PlayAnnouncement is sent after the Assist RequestInstructions. If the SSP or assisting SSP is required to relay info between the SCP and the SRF, the PlayAnnouncement can only be sent after a ConnectToResource operation. The PlayAnnouncement operation can be used for inband interaction with an analogue subscriber. In this case the SRF is usually collocated with the SSF for standard tones and announcements. The SRF can of course also interact with ISDN subscribers. Here follow the parameters of the Play Announcement operation. PlayAnnouncement ARGUMENT PlayAnnouncementArg ERRORS{ Cancelled, MissingParameter, SystemFailure, UnavailableResource, UnexpectedComponentSequence, UnexpectedDataValue, UnexpectedParameter, } LINKED{ SpecializedResourceReport }
770 00828 0300VHBE
33
ALCATEL UNIVERSITY
5.
PlayAnnouncementArg
::= SEQUENCE { [0] InformationToSend, [1] BOOLEAN, [2] BOOLEAN, [3] SEQUENCE SIZE(1..numOfExtensions) OF ExtensionField OPTIONAL }
informationTosend disconnectFromIPForbidden requestAnnouncementComplete extensions
InformationToSend inbandinfo tone displayInformation
::= CHOICE { [0] InbandInfo, [1] Tone, [2] DisplayInformation }
The PlayAnnouncement operation specifies the announcement, tone or display information to be sent to the subscriber by the SRF. The operation also contains the parameter : disconnectFromIPForbidden. This parameter indicates whether or not the SRF can be disconnected from the user when all information is sent. Another parameter is the RequestAnnouncementComplete. It indicates if a SpecializedResourceReport must be sent to the SCF when all information has been sent to the enduser.
Note : The current signalling systems dont provide an indication whether or not info can be displayed by the users terminal. In case of interaction with an ISDN user 2 consecutive PlayAnnouncement operations are sent. The first contains the display info, the second the inband information.
5.1.2 SpecializedResourceReport
The SRF responds the PlayAnnouncement with a SpecializedResourceReport if in the PlayAnnouncement, an requestAnnouncementComplete parameter is set. SpecializedResourceReport ARGUMENT SpecializedResourceReportArg SpecializedResourceReportArg ::= NULL
5.1.3 PromptAndCollectUserInformation (P&C)

This operation is sent from the SCF to the SRF to collect user information. The information to be collected is normally digits. The information to send can again be an announcement, a tone or display information.
ALCATEL UNIVERSITY
34
770 00828 0300VHBE
5.
The operation also contains the parameter : disconnectFromIPForbidden.

Note : The current signalling systems dont provide an indication whether or not info can be displayed by the users terminal. In case of interaction with an ISDN user , the displayInformation parameter is not used in the PromptAndCollectUserInformation operation. Instead the play announcement is used containing the Displayinfo parameter. This is followed by a P&C operation containing inband information.
If the SCP receives an AssistRequestInstructions operation from an assisting SSF, the ConnectToResource and PA or P&C is sent to the assisting SSP. If the SCP receives the AssistRequestInstructions directly from the SRF, the PA or P&C is sent immediately to the SRF. PromptAndCollectUserInformation ARGUMENT PromptAndCollectUserInformationArg
RESULT ReceivedInformationArg ERRORS{ Cancelled, ImproperResponse, MissingParameter, SystemFailure, UnavailableResource, UnexpectedComponentSequence, UnexpectedDataValue, UnexpectedParameter, } PromptAndCollectUserInformationArg collectedinfo disconnectFromIPForbidden informationToSend extensions } Collectedinfo consists of collected digits ReceivedInformationArg consists also of digits
In the following, we will use as an abbreviation for the PlayAnnouncement operation PA. For the PromptAndCollectUserInformation, the abbreviation P&C will be used.
::= SEQUENCE { [0] Collectedinfo, [1] BOOLEAN, [2] InformationToSend, [3] SEQUENCE SIZE91..numOfExtensions) OF ExtensionField OPTIONAL
770 00828 0300VHBE
35
ALCATEL UNIVERSITY
5.
The operations ConnectToResource and the first PA or P&C can be carried in 1 N7 TCAP message.
5.1.4 Cancel
A Cancel operation can be initiated by the SCF and sent to the SSF or SRF to cancel previously sent PlayAnnouncement and PromptAndCollectUserInformation operations. If the Cancel is used to delete a previously invoked PA or P&C the cancel must include an invoke id.
5.2 Disconnection of the SRF

In both the PA and the P&C, the parameter disconnectFROMIPForbidden is present. Via this boolean,the SCF enables or disables the disconnect from the user initiated by the IP. If the SRF initiated disconnect is not enabled, the SCF asks the SRF to inform it of the completion of user interaction . For the PA, this is done by a SpecializedResourceReport, For the P&C the return result is used. The SCF can explicitly order the disconnect by a DisconnectForwardConnection operation. The SRF disconnect is enabled by the SCF within a PA or a P&C operation via the parameter disconnectFromIPForbidden = FALSE. Then the SRF can disconnect on completion of user interaction. If the SCF sets the parameter disconnectFromIPForbidden on TRUE, it shall later on explicitly order the disconnect of the SRF. If a number of PC or P&A operations are to be executed by the same SRF, the SCF certainly inhibits the SRF disconnect for all operations except for the last one. The SCF can also inhibit the SRF initiated disconnect for the last PA or P&C. The SCF either enables the SRF initiated disconnect at the last PA or P&C or the SCF will later explicitly order the disconnect. In the case of the assisting SSF, the SRF initiated disconnect is not used. The assisting SSF doesnt propagate the SRF initiated disconnect to the initiating SSP.
ALCATEL UNIVERSITY
36
770 00828 0300VHBE
5.
In fact the DisconnectForwardConnection is used in 2 cases :

-
To explicitly disconnect a connection to a SRF, established previously with a ConnectToResource operation or an EstablishTemporaryConnection (used to connect a call from the SSF to a specialized resource). To clear the temporary connection between an initiating and an assisting SSF.
5.3 Scenarios
Figure 19 : The SSP with integrated SRF, an SRF initiated disconnect
SCP
SSP
IP
Setup response
PlayAnnouncement
DisconnectFromIPForbidden = FALSE
PlayAnnouncement
SpecializedResourceReport SpecializedResourceReport
Disconnect
770 00828 0300VHBE
37
ALCATEL UNIVERSITY
5.
Figure 20 : The SSP relays messages between the SCF and SRF, SCF initiated disconnect
SCP
SSP
IP
Setup response
Prompt&CollectUserInfo
DisconnectFromIPForbidden =TRUE
Prompt&CollectUserInfo
P&C return result P&C return result
DisconnectForwardConnection Disconnect
ALCATEL UNIVERSITY
38
770 00828 0300VHBE
5.
Figure 21 : Direct SCPIP information transfer
SCP
SSP
Setup request
IP
Establish Temporary Connection
Setup response
Assist Request Instructions Play Announcement

DisconnectFromIPForbidden = FALSE
Specialized resource Report Disconnect
770 00828 0300VHBE
39
ALCATEL UNIVERSITY
5.
As illustrated in figure 22, the SCP uses the operation DisconnectForwardConnection. If the initiating SSF receives this, it releases the bearer channel connection towards the assisting SSP and SRF. Figure 22 : SSP Assist/handoff
SCP
SSP
Assisting SSP
IP
Setup request Establish Temporary Connection Setup response

ConnectToResource
Setup request Setup response
P&C(see note 1) P&C RR for P&C RR for P&C
Disconnect DisconnectForward Connection

Note 1 : Disconnect FromIPForbidden = TRUE.
Disconnect
ALCATEL UNIVERSITY
40
770 00828 0300VHBE
5.
Figure 23 : Account calling card SSP with integrated SRF
SCP
InitialDP
SSP
IP
Setup request Connect to Resource Setup response
P&C
DisconnectFromIPForbidden = TRUE
P&C P&C result
P&C result P&C

DisconnectFromIPForbidden =FALSE
P&C P&C result
P&C result Disconnect Connect
770 00828 0300VHBE
41
ALCATEL UNIVERSITY
5.
ALCATEL UNIVERSITY
42
770 00828 0300VHBE
6.
TRAFFIC MANAGEMENT
6. TRAFFIC MANAGEMENT
Different procedures are foreseen :
-
call blocking call gapping call filtering
6.1 CallGap
Call gapping is a traffic management method where a time period is specified between two consecutive calls.
This class 4 operation is initiated by the SCF to reduce the rate at which specific service requests are sent to the SCF. The CallGap operation may be received inside as well as outside a call context transaction. Following parameters can be present in the CallGap operation:
-
gap criteria gap indicators control type and gap treatment
The Gap criteria indicate which calls are subject to gapping. Following possibilities exist :
-
called address service key called address and service key calling address or location number and service key
The gap indicators specify the duration, during which call gapping for a specified criteria is active and a gap interval. The gap interval is the minimum time between calls being allowed through.
-
gap interval = 0, means that all calls meeting the gap criteria are not rejected, no call gapping is applied, gap interval = 1, means that all calls meeting the criteria are to be rejected
770 00828 0300VHBE
43
ALCATEL UNIVERSITY
6.
TRAFFIC MANAGEMENT
other values indicate an interval in milliseconds. Duration = 0, indicates gapping to be removed, Duration = 1, indicates infinite duration, Duration = 2, network specific duration. Other values indicate a duration in seconds.
The control type is the reason for activating call gapping. At the moment two possibilities are identified :
-
SCP Overloaded and manually initiated
SCP overload indicates that an automatic congestion detecting mechanism in the SCP detected the problem. Manually initiated indicates that the management center initiated call gapping. Gap treatment indicates how calls stopped by the gapping mechanism must be treated. Different possibilities are :
-
Sending information : inband info , tone or textual info release cause or both
If the congestion level changes new call gap operations can be sent with the same active gap criteria but with a new gap interval.
6.2 Service Filtering
6.2.1 Activate Service Filtering

The ActivateServiceFiltering operation is a class 1 operation initiated by the SCP. It is used for televoting or mass call services. After receiving this operation, the SSF handles calls to specified destinations without sending queries to the SCP for every detected call. The relevant counters and announcements can be located at the SSF. The operation initializes the specified counters in the SSF. The ActivateServiceFiltering may only be received outside a call context transaction.
ALCATEL UNIVERSITY
44
770 00828 0300VHBE
6.
TRAFFIC MANAGEMENT
6.2.2 ServiceFilteringResponse
Via this operation, the SSF can send the values of the counters to the SCF in reaction to a previously received ActivateServiceFiltering . Figure 24 : Service filtering SCP SSP
ActivateServiceFiltering(
filteringCharacteristics = 3 calls, nbr of counters =1,service key)
IN call, counted &released IN call, counted &released
IN call, allowed
ServiceFilteringResponse Initial DP
The ActivateServiceFiltering contains following information about how filtered calls are treated : ActivateServiceFilteringArg filteredCallTreatment filteringCharacteristics filteringTimeout filteringCriteria startTime } The parameter filteredCallTreatment contains following information :
-
::= SEQUENCE { [0] FilteredCallTreatment, [1] FilteringCharacteristics, [2] FilteringTimeout, [3] FilteringCriteria, [4] DateAndTime,
Charging approach for filtered calls. This is network operator specific. Announcements, tones or display information to be sent to the calling party. At the end of sending this information, the call is released, the number of counters used,
770 00828 0300VHBE
45
ALCATEL UNIVERSITY
6.
TRAFFIC MANAGEMENT
the release cause used for call release to be applied to filtered calls.
The maximum number of counters is the number of counters to be allocated as well as the number of destinations included in service filtering. If several destination addresses are provided in filtering criteria, one counter is assigned per destination address. This is only possible if filtering criteria are specified via called addresses. The numbers to be filtered are from calledAddressValue up to and including called AddressValue + maximum number of counters 1. The parameter filteringCharacteristics indicates the severity of the filtering and the point in time when the ServiceFilteringResponse will be sent. It determines whether interval or number of calls is used. Interval : After expiration of the interval timer following actions can occur on arrival of a new call ,an Initial DP can be sent together with a ServiceFilteringResponse. The interval timer is started again. Interval = 0 means no filtering is applied, new calls result in an Initial DP. Interval = 1 means no Initial DP or Service Filtering Response. Otherwise, the interval is specified in seconds. number of calls : Every nth call causes an InitialDP and a ServiceFiltering Response. This happens if the sum of all counters assigned to one service filtering entity equals Number of Calls. Filtering Timeout indicates the duration of the filtering. If the time expires a ServiceFilteringResponse is sent and service filtering is stopped. It can be done via specifying a duration or via specifying a stop time.
REMARK ! The ActivateServiceFiltering and the ServiceFilteringresponse are also used to support televoting. The filtering criteria specify which calls are filtered. The filtering can be based on :
-
a service key, a calling address value, a calledAddressValue, or a location number.
The location number identifies the geographical area from which the call to be filtered originates.
ALCATEL UNIVERSITY
46
770 00828 0300VHBE
6.
TRAFFIC MANAGEMENT
To change the parameters of an existing service filtering entity, the SCF sends a second Activate Service Filtering with the same filtering criteria.
The ServiceFilteringResponse operation is used to report the values of counters specified in the ActivateServiceFiltering. ServiceFilteringResponsearg ::= SEQUENCE { countersValue filteringCriteria extensions }
[0] CountersValue, [1] FilteringCriteria, [2] SEQUENCE SIZE91..numOfExtensions) OF Extensionfield

OPTIONAL
The filtering criteria parameter is used to address the concerned SLP instance. It consists of a service key alone or a service key together with a called address. After sending a ServiceFilteringResponse, the service filter counters are reset.
770 00828 0300VHBE
47
ALCATEL UNIVERSITY
6.
TRAFFIC MANAGEMENT
ALCATEL UNIVERSITY
48
770 00828 0300VHBE
7.
CHARGING RELATED OPERATIONS
7. CHARGING RELATED OPERATIONS

7.1 Charging scenarios
With the introduction of IN, charging capabilities will be extended. Charging processes can be activated in the SSP, in the SCP or both. So, it can be that charging processes in the SSP and the SCP have to interwork via exchanging operations. Charging of IN calls follows the following structure, this is :
-
Charge Determination Charge Generation Charge Registration Online Charge Information provision Charge Output Offline charging billing and accounting
The Charge Analysis (Determination) defines

-
the charge party (calling line, IN subscriber or both), the level of charge, the items to be charged,
Charge Generation generates charge pulses, charge related signalling or charge related info for the offline process. Charge Registration updates the charging meters or creates call records or both. Online Charge Information provision, provides charging pulses or signalling information on the user/network interface during the call. The charge output process puts data on magnetic tapes or datalinks for further processing. The introduction of Intelligent Networks with its resulting split of functionality over separate physical entities has placed additional requirements on the charging of such calls. Several operations are defined for communicating charging related information between the SCF and the SSF.
770 00828 0300VHBE
49
ALCATEL UNIVERSITY
7.
7.2 SendChargingInformation
The SCF uses this operation to instruct the SSF on the charging information to be sent by the SSF to a local exchange. Some examples where the SCP input can be required to determine charging in the local exchange are :
-
The charging in the local exchange must be inhibited. The local exchange explicitly asks to determine the traffic at a remote site. Advice of Charge (AOC).
The SSF can transfer this information via signalling or charging pulses. In the local exchange, this information can be used to update the charge meter or to create a standard call record. For example, the SCF can via this operation instruct the SSF to initiate the PSTN or ISDN charging functions according to the given charging level. The supplied information is operator specific. For instance following information can be supplied :
-
the charge level, charge pulses, charge messages. Figure 25 : The use of the SendChargingInformation SCP
Initial DP(1) Send Charging Info(2)
Connect(3)
Local Exchange
IAM
SSP
ALCATEL UNIVERSITY
50
770 00828 0300VHBE
7.
SendChargingInformationArg ::= SEQUENCE { sciBillingChargingCharacteristics legID } The sciBillingChargingCharacteristics is network operator specific. It contains signalling related specific charging info, it can in signalling messages be mapped to the corresponding parameters. The parameter contains signalling related specific charging information. It is passed through by the SSF to signalling where it can be mapped to the corresponding parameters. It can also be used to request the sending of the No charge indicator to the involved signalling. This condition is to be mapped on the appropriate signalling message, e.g. ISUP ACM. If the PIC is passed to pass this No charge indicator, a negative reply to this operation (Task refused) will be transferred to the SCP. [0] SciBillingChargingCharacteristics, [1] LegId
7.3 FurnishChargingInformation
The SCF asks via this operation the SSF to generate, register a call record or to include some info in the default call record. It provides the parameters to influence the charging in thre SSP. This registered call record is intended for offline charging of the call. The FurnishChargingInformation can be used at the beginning of a call to start charge generation. But it can also be invoked at the end of a call or connection configuration. If such additional FurnishChargingInformation operations are used, it is best to arm an EDPR to be able to apply it before the termination of the call record generation. The supplied information by this operation is the FCIBillingChargingCharacteristics. Its content is network operator specific. An example is given : FCIBillingChargingCharacteristics ::= CHOICE{ completeChargingRecord correlationID scenario2Dot3 chargeParty chargelevel chargeItems } }
[0] OCTET STRING, [1] CorrelationID, [2] SEQUENCE { [0] LegID OPTIONAL, [1] OCTET STRING OPTIONAL, [2] Set Of atrribute OPTIONAL
770 00828 0300VHBE
51
ALCATEL UNIVERSITY
7.
Which element out of the CHOICE is taken depends on the scenario (see further) An FCI operation is always linked to a connection section and a FCI can only be received during (or is related with) the call setup. When the connection section releases, the corresponding charge record has to be closed. This way of working solves the problem where a FCI is received for an announcement and afterwards another FCI is received for the connection to the Bparty. When the transfer of the announcement is requested a ConnectToResource or similar operation is received together with the FCI. When the announcement session is finished the SCP will transfer a DisconnectForwardConnection (or similar) operation or the SRF will disconnect automatically (depending on the value of the disconnectFromIpForbidded parameter) resulting in the closure of the corresponding charge record. Examples are: FCI received together with a ConnectToResource operation: The FCI is active until a DisconnectForwardConnection is received or until the SRF releases the connection. An FCI cannot be used by the SCP to ask a send him a call record at the end of the call.
7.4 ApplyCharging & ApplyChargingReport

This operation is used for interacting from the SCF with the SSF charging mechanisms. The ApplyChargingReport operation provides the feedback from the SSF to the SCF. As several connection configurations may be established during a call, a possibility exists for the ApplyCharging to be invoked at the beginning of each connection configuration, for each party. ApplyCharging ARGUMENT ApplyChargingArg ERRORS{ MissingParameter, UnexpectedComponentSequence, UnexpectedParameter, UnexpectedDataValue, ParameterOutOfRange, SystemFailure, TaskRefused }
ALCATEL UNIVERSITY
52
770 00828 0300VHBE
7.
ApplyChargingArg
::= SEQUENCE { [0] AChBillingChargingCharacteristics, [1] BOOLEAN DEFAULT FALSE, [2] LegID OPTIONAL
aChBillingChargingCharacteristics sendCalculationToSCPIndication partyToCharge }
The ApplyChargingArg specifies which charging related information is required from the SSF. Also specified is the conditions under which an ApplyChargingReport is sent. Its contents is network operator specific Examples of charging related information to be provided by the SSF are :
-
bulk counter values, costs, tariff change and time of change, time stamps, durations and so on.
An additional parameter is the partyToCharge. It is the party in the call to which the Apply Charging applies. The sendCalculationToSCPIndication parameter indicates whether ApplyChargingReport operations are expected from the SSF. The AC operation received from the SCP can also indicate the actions to be performed on an active call. The SCP can in this way supervise the charging related aspects of the call and indicate to the SSP following information :
-
Maximum call cost in currency or maximum call duration in seconds. These parameters are exclusive. The SSP starts the supervision immediatly after the Bparty has answered. Warning to be given to the served party at a specified time before the release of the call. How to release the call, Time interval between sending of ACR.
The ApplyChargingReport operation reports the specific charging events as asked by the SCP and sends the requested information.
770 00828 0300VHBE
53
ALCATEL UNIVERSITY
7.
ApplyChargingReport ARGUMENT ApplyChargingReportArg ERRORS{ MissingParameter, UnexpectedComponentSequence, UnexpectedParameter, UnexpectedDataValue, ParameterOutOfRange, SystemFailure, TaskRefused
} The Apply ChargingReportArg contains the information requested for in the ApplyCharging. The contents is operator specific
ALCATEL UNIVERSITY
54
770 00828 0300VHBE
7.
7.5 An example of the operator specific info available in the charging related operations
FCIBillingChargingCharacteristics [0] IMPLICIT SEQUENCE SIZE (1 OF ??)) OF SEQUENCE { chargeRecordIdentifier [0] IMPLICIT INTEGER (1..127) DEFAULT 1, chargeAction [1] IMPLICIT ENUMERATED { networkChargeRecordGenerationRequest (1), serviceChargeRecordGenerationRequest (2), chargeChange (3), suspendCharging (4), resumeCharging (5),
stopCharging (6) } DEFAULT networkChargeRecordGeneration Request, controllingParty [2] IMPLICIT INTEGER (1..127) DEFAULT 1, This parameter contains the value of the leg identity controlling the charge request. When this leg identity releases the involved charge record shall be closed. callPartToBeCharged [3] IMPLICIT ENUMERATED { callingSSP (1), sSPCalled (2), CallingCalled (3) } DEFAULT sSPCalled, additionalChargeRecordStorageReference [4] IMPLICIT INTEGER (1..200) OPTIONAL, It specifies indirectly the file reference in which the charge record is to be stored in addition to the normal storage treatment. doNotGenerateChargePulses [5] IMPLICIT BOOLEAN DEFAULT TRUE, TRUE : Generate pulses if so populated in SSF
FALSE : Do not generate pulses, even if pulse generation is populated in SSF
chargeRecordTreatment [6] IMPLICIT OCTET STRING (SIZE(1)), callingPartyServiceNumber [9] CallingPartyNumber OPTIONAL, This parameter is treated depending on the availability of the calling party number in
the SSP.
This parameter is stored in the charge record without any processing in case the
calling party number is still available in the SSP. In case the calling party number is not available anymore in the SSP, this parameter is stored in the charge record and it is used by the SSP in case charge determination is to be performed in the SSP .
770 00828 0300VHBE
55
ALCATEL UNIVERSITY
7.
calledPartyServiceNumber [10] CalledPartyNumber OPTIONAL, This parameter can be used to store the identity of the called party in the charge record translatedPartyNumber [11] CalledPartyNumber OPTIONAL, chargedPartyIdentityIndicator [12] INTEGER (1..127) DEFAULT 2, surcharge [13] IMPLICIT SEQUENCE (SIZE (1 OF ??)) OF SEQUENCE { surchargeValue [1] IMPLICIT INTEGER (0..255), surchargeType [2] IMPLICIT INTEGER (1..127) } OPTIONAL, 1 = local currency, 2 = tariff units chargeClass [14] IMPLICIT INTEGER (1..1000) OPTIONAL, A numeric value defining the charging to be performed, defined in function of all
charging influencing parameters and comprising switchover moments
chargeRateModulator [15] IMPLICIT SEQUENCE OF SEQUENCE { chargeRateModulatorValue [1] IMPLICIT INTEGER (0..255), chargeModulatorType [2] IMPLICIT INTEGER (1..3) } OPTIONAL, Rate Modulator (1) in %,Currency (fee) Modulator (2) in %,Tariff Table index (3) actualInitialTariffUnits[16] IMPLICIT INTEGER (0..255) OPTIONAL, This parameter contains the tariff units to be added when the charging becomes
active.This parameter is valid before the switchover time.
nextInitialTariffUnits [17] IMPLICIT INTEGER (0..255) OPTIONAL, This parameter contains the initial tariff units after the specified switchover time. actualTariffUnits [18] IMPLICIT INTEGER (0..63) OPTIONAL, This parameter contains the tariff units to be used before the switchover time. nextTariffUnits[19] IMPLICIT INTEGER (0..63) OPTIONAL, This parameter contains the tariff units to be used after the specified switchover time. actualTimeInterval [20] IMPLICIT INTEGER (0..32767) OPTIONAL, This parameter contains the time interval in 1/10 sec accuracy,The value is valid
before the specified switchover time.
nextTimeInterval [21] IMPLICIT INTEGER (0..32767) OPTIONAL, switchoverTime [22] IMPLICIT INTEGER (0..1440) OPTIONAL, startChargingPattern [24] IMPLICIT ENUMERATED { immediately (1), answerReceived (2) } DEFAULT answerReceived, stopChargingPattern [25] IMPLICIT ENUMERATED { suspend (1),
ALCATEL UNIVERSITY
56
770 00828 0300VHBE
7.
release (2) } DEFAULT release, callType [26] IMPLICIT ENUMERATED { circuitSwitched (1), packetSwitched (2) } DEFAULT circuitSwitched, chargeRecordType [27] IMPLICIT ENUMERATED { detailledBilling (1), bulkBilling (2) } DEFAULT detailedBilling, chargeMeterIdentity [28] IMPLICIT ENUMERATED { bulkBillingMeter1 (1), bulkBillingMeter2 (2), ... bulkBillingMeter15 (15) } OPTIONAL,
transparentChargeParameter1 [29] IMPLICIT OCTET STRING (SIZE(1..20)) OPTIONAL, detailedBillingChargeRecordType [45] IMPLICIT INTEGER (1..32) DEFAULT 1 } applyCharging OPERATION ARGUMENT The sendCalculationToSCPIndication parameter indicates that are expected from the SSF. This parameter shall always be set to TRUE. The PartyToCharge parameter indicates the party in the call to which the operation should be applied. If it is not present, then it is applied to the Aparty. SEQUENCE { aChBillingChargingCharacteristics [0] IMPLICIT SEQUENCE SIZE (1 OF 100)) OF SEQUENCE { chargeRecordIdentifier [0] IMPLICIT INTEGER (1..127) DEFAULT 1 chargeAction [1] IMPLICIT ENUMERATED { networkChargeRecordGenerationRequest (1), serviceChargeRecordGenerationRequest (2), chargeChange (3), suspendCharging (4), resume charging (5), stop charging (6) } DEFAULT networkChargeRecordGenerationRequest controllingParty [2] IMPLICIT INTEGER (1..127) DEFAULT 1, callPartToBeCharged [3] IMPLICIT ENUMERATED { ApplyChargingReport operations
ApplyCharging
770 00828 0300VHBE
57
ALCATEL UNIVERSITY
7.
callingSSP (1), sSPCalled (2), CallingCalled (3) } DEFAULT sSPCalled additionalChargeRecordStorageReference [4] IMPLICIT INTEGER (1..200) OPTIONAL, It specifies indirectly the file reference in which the charge record is to be stored in addition to the normal storage treatment. doNotGenerateChargePulses [5] IMPLICIT BOOLEAN DEFAULT TRUE, TRUE : Generate pulses if so populated in SSF FALSE : Do not generate pulses, even if pulse generation is populated in SSF
chargeRecordTreatment [6] IMPLICIT OCTET STRING (SIZE(1)), Layout: see description in this document callingPartyServiceNumber [9] CallingPartyNumber OPTIONAL, This parameter is treated depending on the availability of the calling party number in the SSP. calledPartyServiceNumber [10] CalledPartyNumber OPTIONAL, This parameter can be used to store the identity of the called party in the charge record translatedPartyNumber [11] CalledPartyNumber OPTIONAL, chargedPartyIdentityIndicator [12] INTEGER (1..127) DEFAULT 2, surcharge [13] IMPLICIT SEQUENCE (SIZE (1 OF ??)) OF SEQUENCE { surchargeValue [1] IMPLICIT INTEGER (0..255), surchargeType [2] IMPLICIT INTEGER (1..127) } OPTIONAL chargeClass [14] IMPLICIT INTEGER (1..1000) OPTIONAL, chargeRateModulator [15] IMPLICIT SEQUENCE OF SEQUENCE { chargeRateModulatorValue [1] IMPLICIT INTEGER (0..255), chargeModulatorType [2] IMPLICIT INTEGER (1..3) } OPTIONAL, actualInitialTariffUnits[16] IMPLICIT INTEGER(0..255) OPTIONAL, nextInitialTariffUnits [17] IMPLICIT INTEGER (0..255) OPTIONAL, actualTariffUnits [18] IMPLICIT INTEGER (0..63) OPTIONAL, nextTariffUnits[19] IMPLICIT INTEGER (0..63) OPTIONAL,
ALCATEL UNIVERSITY
58
770 00828 0300VHBE
7.
actualTimeInterval [20] IMPLICIT INTEGER (0..32767) OPTIONAL, nextTimeInterval [21] IMPLICIT INTEGER (0..32767) OPTIONAL, switchoverTime [22] IMPLICIT INTEGER (0..1440) OPTIONAL, chargeLimit [23] IMPLICIT SEQUENCE SIZE (1..??) OF SEQUENCE { chargeLimitType [01] INTEGER (1..127), This parameter contains the type as follows 1 = local currency 2 = time in seconds 3 = pulses chargeLimitValue [02] INTEGER (1..32000), startChargingPattern [24] IMPLICIT ENUMERATED {
immediately (1), answerReceived (2) } DEFAULT answerReceived, stopChargingPattern [25] IMPLICIT ENUMERATED { suspend (1), release (2) } DEFAULT release, callType[26] IMPLICIT ENUMERATED { circuitSwitched (1), packetSwitched (2) } DEFAULT circuitSwitched, chargeRecordType[27] IMPLICIT ENUMERATED { detailledBilling (1), bulkBilling (2) } DEFAULT detailedBilling, chargeMeterIdentity [28] IMPLICIT ENUMERATED { bulkBillingMeter1 (1), bulkBillingMeter2 (2), ... bulkBillingMeter15 (15) } OPTIONAL, transparentChargeParameter1 [29] IMPLICIT OCTET STRING (SIZE(1..20)) OPTIONAL, detailedBillingChargeRecordType [45] IMPLICIT INTEGER (1..32) } DEFAULT 1,
770 00828 0300VHBE
59
ALCATEL UNIVERSITY
7.
ALCATEL UNIVERSITY
60
770 00828 0300VHBE
8.
CHARGING SCENARIOS
8. CHARGING SCENARIOS
The following scenarios will be possible for the charging of IN Calls :
-
scenario 1: Charging completely done in a charging point outside the SSP via nonIN charge record. scenario 2: Charging completely done in the SSP via IN charge records. scenario 3: Charging done in as well the SSP as a charging point outside the SSP: via nonIN charge record in charging point outside SSP. via IN charge record(s) in the SSP.
The choice between the different scenarios is IN service dependent. For each service, the charged parties should be available in the SCP service script, resulting in clear instructions for the charging. Note : The charging point outside the SSP is situated in a previous exchange, in relation to the involved SSP, or in the same exchange where the SSF function is located
8.1 Scenario 1 Charging completely done in a charging point outside the SSP.
The charging point outside the SSP knows, by charge determination that local charging applies. The charging point can generate and determine charging autonomously, but can request input from IN. The charging point will request the sending of charging information by the SSP and the nonIN charge record has to be generated according to the received charging information. The charging information is market dependent and will not be discussed further. The charging request has to be passed via the existing parameters of the InitialDP, for example the ForwardCallIndicator can be used. The SCP upon receipt of the charging request, will request the transfer of a SendChargingInformation operation via the SSP. The SSP has to map the contents of the SCI operation to an information element of the involved signalling system (e.g. ISUP)
Note: As an alternative, the SCP can request the transfer of the SCI without any request from the charging point (decision is again market dependent).
770 00828 0300VHBE
61
ALCATEL UNIVERSITY
8.
CHARGING SCENARIOS
Figure 26 : Charging completely done in a charging point outside the SSP
SCP
InitialDP with charging request(2) Send Charging information (3)
Charging point
Charging information request(1)
SSP
nonIn charge record
Charging information reply(4)

Advice Of Charge Supplementary Service (AOC). As the charging point will be able to generate the AOC, all parameters of the AOC can be determined by taking the received charging information reply together with the local charging information into account.
Homemeter. The charging point has all the information to address the homemeter (same as for AOC)
8.2 Scenario 2 charging completely done in the SSP.

The service definition specifies that for the charging, IN charge records have to be generated by the SSP. In this case the nonIN charging point knows, during charge determination that no charging applies locally. The SCP service script has to request the generation of IN charge records .
ALCATEL UNIVERSITY
62
770 00828 0300VHBE
8.
CHARGING SCENARIOS
Figure 27 : Charging completely done in the SSP
SCP
Furnish Charging and ApplyCharging ApplyCharging report
nonIN charging point taxfree record is possible

SSP
Advice of Charge Supplementary Service (AOC). As the nonIN charging point will not be the charging exchange, it will have to request to the SSP the sending of all parameters related to the AOC. The AOC request is passed to the SCP which in turn will reply the AOC information. The AOC request is only related to the charging of the calling line (owner of the access). The nonIN charging point shall process/generate the charging parameters required for AOC. The nonIN charging point shall have the possibility to generate a tax free record in which the number of pulses charged to the subscriber will be put.
Homemeter The same principle as for AOC is applicable. The nonIN charging point shall calculate the required charging information to be transferred to the homemeter. In other words, charging of the call will be performed in the SSP and in parallel in the nonIN charging point in case Homemeter or AOC is required. The nonIN charging point shall have the possibility to generate a tax free record in which the number of pulses charged to the subscriber will be put.
8.3 Scenario 3 Charging done in as well the SSP as a charging point outside the SSP
The service definition specifies that both the nonIN charging point as well as the SSP shall generate charge records. As an example the nonIN charge record can be used to charge the access and possible the use of the service and the IN charge record(s) generated in the SSP can be used to charge the service provider. In this case the nonIN charging point knows during charge determination that charging applies locally. The nonIN charging point can request the sending of the charging information as is done for scenario 1.
770 00828 0300VHBE
63
ALCATEL UNIVERSITY
8.
CHARGING SCENARIOS
The SCP has to reply via

-
The Send Charging Information operation the charging information for the nonIN charging Point (see scenario 1) The Apply Charging or Furnish Charging operation the request to generate a IN charge record in the SSP (see scenario 2) Figure 28 : Charging done in as well the SSP as a charging ppoint outside the SSP
SCP
InitialDP with charging request(2)
Send Charging information (3)
Charging point
Charging information request(1)
ApplyCharging or furnishCharging
SSP
nonIn charge record
Charging information reply(4)

-
dvice Of Charge Supplementary Service (AOC) The same principles apply as specified in scenario 1. (AOC only for nonIN charge record. In other words, AOC for all charges to be paid by the owner of the physical access).
Homemeter The same principles apply as specified in scenario 1.
8.4 Determination of Charging Information

-
In case the SCP or the nonIN charging point cannot determine the charging information specific market dependent activities are to be performed. These activities can result in releasing the call, with a congestion tone, specific announcement or the call handling can continue as for charge free calls. The Charging Information Request and Advice Of Charge Request are passed via national defined ISUP mechanisms (indicators, parameters, messages) and are not further described in this document.
ALCATEL UNIVERSITY
64
770 00828 0300VHBE
8.
CHARGING SCENARIOS
The Charging Information Reply and AOC reply are passed via national defined ISUP mechanisms (parameters, messages). They contain a tariff class and optionally a charge modulator. The charge modulator is only applicable on the time interval (rate) or currency. Selection between time interval and currency depends on the used charging strategy and is as such market dependent.
The coding of the ISUP details are market dependent and are not further described in this document. In case Home Meter or CoinBox is treated, if a currency modulator is received, the call is released.
770 00828 0300VHBE
65
ALCATEL UNIVERSITY
8.
CHARGING SCENARIOS
ALCATEL UNIVERSITY
66
770 00828 0300VHBE
9.
OVERVIEW OF THE OPERATIONS
9. OVERVIEW OF THE OPERATIONS

InitialDP AssistRequest Instructions EstablishTemporaryConnection DisconnectForwardConnection ConnectToResource Connect ReleaseCall RequestReport BCSMEvent EventReportBCSM CollectInformation Continue InitiateCallAttempt ResetTimer FurnishCharging Information ApplyCharging ApplyCharging Report CallGap ActivateService Filtering ServiceFiltering Response CallInformation Report CallInformation Request SendCharging Information PlayAnnouncement PromptAndCollect UserInformation SCP > SSP SCP > SSP SSP > SCP SSP or SRF > SCP SCP > SSP SCP > SSP SCP > SSP SCP > SSP SCP > SSP SCP > SSP SSP > SCP SCP > SSP SCP > SSP SCP > SSP SCP > SSP SCP > SSP SCP > SSP SSP > SCP SCP > SSP SCP > SSP SSP > SCP SSP > SCP SCP > SSP Class 2 Class 2 Class 2 Class 2 Class 2 Class 2 Class 4 Class 2 Class 4 Class 2 Class 4 Class 2 Class 2 Class 2 Class 2 Class 2 Class 4 Class 2 Class 4 Class 4 Class 2 Class 2 Class 2 Class 1 Class 4 Class 2 0 16 17 18 19 20 22 23 24 27 31 32 33 34 35 36 41 42 43 44 45 46 47 48 49 53
SpecializedResource SSP > SCP Report Cancel SCP > SSP
770 00828 0300VHBE
67
ALCATEL UNIVERSITY
9.
Activity Test ALCFree ALCJoin ALCSplit
SCP > SSP SCP > SSP SCP > SSP SCP > SSP
Class 3 Class 2 Class 2 Class 2
55
ALCATEL UNIVERSITY
68
770 00828 0300VHBE
9.
Figure 29 : Alcatel Operations
ETSI CS1 Protocol

INITIAL DP INITIATE CALL ATTEMPT CONNECT REQUEST NOTIFICATION BCSM EVENT EVENT REPORT BCSM COLLECT INFORMATION CALL INFORMATION REQUEST CALL INFORMATION REPORT RELEASE CALL ACTIVITY TEST
Alcatel INAP Protocol

PROVIDE INSTRUCTION CREATE (without related leg) CREATE MONITOR EVENT GENERATE SIGNAL TRANSFER CONTROL ACTIVITY TEST
Operations used in a normal call flow
Charging
FURNISH CHARGING APPLY CHARGING APPLY CHARGING REPORT SEND CHARGING INFORMATION UPDATE (charging) UPDATE (charging) UPDATE (charging report)
Connection of Announcements / Receive End User Info.

CONNECT TO RESOURCE PLAY ANNOUNCEMENT SPECIALISED RESOURCE REPORT PROMPT AND COLLECT USER INFORMATION PROMPT AND COLLECT USER INFORMATION RESULT ESTABLISH TEMPORARY CONNECTION ASSIST REQUEST INSTRUCTION CANCEL SEND / RECEIVE SEND / RECEIVE SEND / RECEIVE RESULT SEND / RECEIVE SEND / RECEIVE RESULT
Mass Calling
ACTIVATE SERVICE FILTERING SERVICE FILTERING RESPONSE
Traffic Management
CALL GAP
Others
RESET TIMER ALC JOIN ALC SPLIT ALC FREE
UPDATE (WINDOW) UPDATE (BLOCKING)
JOIN SPLIT FREE
770 00828 0300VHBE
69
ALCATEL UNIVERSITY
9.
ALCATEL UNIVERSITY
70
770 00828 0300VHBE
10.
SCENARIOS
10.SCENARIOS
Figure 30 : A normal call scenario
SCP
InitialDP
SSP
Connect
FurnishChargingInformation
ApplyCharging
RequestReportBCSMEvent
EventReportBCSM ApplyChargingReport Release
770 00828 0300VHBE
71
ALCATEL UNIVERSITY
10.
SCENARIOS
SCP
InitialDP
SSP
Connect to Resource
P&C
P&C result
P&C
P&C result
Connect
ALCATEL UNIVERSITY
72
770 00828 0300VHBE
10.
SCENARIOS
Figure 32 : Wake up call SSP has an integrated SRF
SCP
Initiate Call Attempt
SSP
RequestReportBCSM event (T_Answer from B)
EventReportBCSM
ConnectToResource
PlayAnnouncement
770 00828 0300VHBE
73
ALCATEL UNIVERSITY
10.
SCENARIOS
Figure 33 : Televoting or mass calling The service filtering is to be reported every Nth call and is based on some dialled number
SCP
Activateservicefiltering(starttime,stoptime,every nth call)
SSP
ServiceFilteringResponse(counters = 0) DIALOGUE IS ENDED
InitialDP ServiceFilteringResponse (counters, N1 calls have been filtered) ConnectToResource PlayAnnouncement ReleaseCall
ALCATEL UNIVERSITY
74
770 00828 0300VHBE
10.
SCENARIOS
SCP
InitialDP
SSP
IP
Setup request Connect to Resource Setup response
P&C
P&C P&C result
P&C result P&C

P&C P&C result
P&C result Disconnect Connect
770 00828 0300VHBE
75
ALCATEL UNIVERSITY
10.
SCENARIOS
ALCATEL UNIVERSITY
76
770 00828 0300VHBE
11.
THE ALCATEL ADDED OPERATIONS
11.THE ALCATEL ADDED OPERATIONS

11.1 AlcFree
This operation is used by the SCP to release one or more legs related to a call. The parametes present i this operation are :
-
the leg id the release cause and the parameter Immediate execution.
11.2 AlcJoin
This operation is used by the SCP to join a leg with another leg in the same TCAP dialogue. The parametes present in this operation are :
-
the leg id A the leg id B and the parameter Immediate execution.
11.3 AlcSplit
This operation is used by the SCP to request the SSP to separate a leg previously connected to a call or all legs connected to a call, the CallId is discardedd when the last 2 legs of a call are split.
770 00828 0300VHBE
77
ALCATEL UNIVERSITY

Cs1 Core Inap New

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cs1 Core Inap New

Uploaded by

Copyright:

Available Formats

HANDOUT

E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED

ALCATEL IMPLEMENTATION OF ETSI CS1 CORE INAP

770 00828 0300VHBE

E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED

770 00828 0300VHBE

E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED

3. OTHER OPERATIONS USED DURING A CALL . . . . . . . . . . . . . . . . . . .

4. SRF CONNECT PROCEDURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5. SENDING ANNOUNCEMENTS AND COLLECTING INFO . . . . . . . . . .

770 00828 0300VHBE

7. CHARGING RELATED OPERATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . .

770 00828 0300VHBE ALCATEL UNIVERSITY iv

1. THE BASIC CALL STATE MODEL

Events associated with a transition

770 00828 0300VHBE

THE BASIC CALL STATE MODEL

Figure 2 : Originating BCSM

2. Collect_Info. Route_Busy 2 Collected_Info.

Analysed_Info. 4 Route_Select_Failure O_Answer 5 O_Call_Party_Busy

4. Routing & Alerting

Detection point (DP)

Point in call (PIC)

2.Collect_Information: this PIC has following functions:

770 00828 0300VHBE

THE BASIC CALL STATE MODEL

3.Analyse_Information: this PIC has following functions:

4.Routing & Alerting: this PIC has following functions:

E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED

5.O_Active: this PIC has following functions:

6.O_Exception: this PIC has following functions:

770 00828 0300VHBE

THE BASIC CALL STATE MODEL

Figure 3 : Terminating BCSM

8. Select_Facility & Present_Call

E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED

8.Select_Facility & Present_Call: this PIC has following functions:

9.T_Alerting: this PIC has following functions:

10.T_Active: this PIC has following functions:

770 00828 0300VHBE

THE BASIC CALL STATE MODEL

11.T_Exception: this PIC has following functions:

E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED

770 00828 0300VHBE

THE BASIC CALL STATE MODEL

Figure 4 : OBCSM PICs and DPs

E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED

Q.71 or Q.931 state Detection Point Point In Call

770 00828 0300VHBE

THE BASIC CALL STATE MODEL

Figure 5 : TBSCM PICs and DPs

E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED

Detection point PIC

770 00828 0300VHBE

Q.71 or Q.931 State

THE BASIC CALL STATE MODEL

Following figure depicts DP processing for each DP type.

770 00828 0300VHBE

THE BASIC CALL STATE MODEL

Figure 6 : DP processing for each DP type

Basic call process function (BCSM PIC) DP DP Resume DP DP Resume DP DP

DP processing Trigger criteria DP not armed

FIM traffic management feature interactions message formulation