Documente Academic
Documente Profesional
Documente Cultură
Edition : 02
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
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
21
21 22
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
33
33 33 34 34 36 36 37
6. TRAFFIC MANAGEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1 CallGap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
43
iii
ALCATEL UNIVERSITY
44 44 45
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. . . . . . . . . . . . . . . . . . .
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
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
1.
Event m . . . Event n
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.
ALCATEL UNIVERSITY
1.
10 1
Orig. Attempt_Authorized
3. Analyse_Info.
3
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
7 9 O_Disconnect 8 O_Mid_Call
5. O_Active
6 O_No_Answer
Transition
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.
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
1.
the support function of the SSF/CCF to collect subsequent digits according to the feature code (trigger criteria).
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.
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.
the connection is established between originating and terminating party and a account/charging data may being collected and call supervision is being provided.
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.
ALCATEL UNIVERSITY
1.
18
Term. _Attempt_Authorized
13
12
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.
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).
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.
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
1.
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.
ALCATEL UNIVERSITY
1.
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
1.
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).
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:
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
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
ALCATEL UNIVERSITY
1.
Service logic
TDPN
Trigger notification Trigger request instructions Responding instruction & request for EDPRa)
TDPR
DP DP
Detection point Trigger detection point Event detection point Request/notification Point in call
ALCATEL UNIVERSITY
1.
ALCATEL UNIVERSITY
10
2.
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,
11
ALCATEL UNIVERSITY
2.
OPERATIONSUSEDDURINGASIMPLEINCALLINITIATEDBYTHESSP
[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.
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
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
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
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
::= 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 }
[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.
13
ALCATEL UNIVERSITY
2.
OPERATIONSUSEDDURINGASIMPLEINCALLINITIATEDBYTHESSP
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
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 -
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
15
ALCATEL UNIVERSITY
2.
OPERATIONSUSEDDURINGASIMPLEINCALLINITIATEDBYTHESSP
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.
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
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
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
17
ALCATEL UNIVERSITY
2.
OPERATIONSUSEDDURINGASIMPLEINCALLINITIATEDBYTHESSP
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.
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
ALCATEL UNIVERSITY
18
2.
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.
19
ALCATEL UNIVERSITY
2.
OPERATIONSUSEDDURINGASIMPLEINCALLINITIATEDBYTHESSP
The Cancel operation can also be used to cancel all outstanding requests of the following operations :
-
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
3.
RequestReportBCSMEvent (DP2, mode = interrupted, DPspecificcriteria = number of digits) CollectInformation The SSP collects the requested info and sends them to the SCP
21
ALCATEL UNIVERSITY
3.
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
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
SCP
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
4.
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.
23
ALCATEL UNIVERSITY
4.
SCP
SCF
CASE A
IP
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
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 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
4.
4.3 The SRF is attached to the SSP but can communicate directly to the SCP (caseB)
CASE B
SCP SCF
SSP
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
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
Setup response
25
ALCATEL UNIVERSITY
4.
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.
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
4.
, OPTIONAL, OPTIONAL,
OPTIONAL
iPSSPCapabilities extensions }
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.
27
ALCATEL UNIVERSITY
4.
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
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
4.
SCP
Initiating
SSP
Assisting SSP
IP
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.
29
ALCATEL UNIVERSITY
4.
Figure 15 : Case D
CASE D
SCP SCF
SSP SSF
IP
SCP
SSP
Exchange
IP
Setup request Establish Temporary Connection Setup request Setup response Setup response
ALCATEL UNIVERSITY
30
4.
SCP
Initiating SSP
Assisting SSP
IP
Setup request
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
Connect
Setup response
Connect To Resource
31
ALCATEL UNIVERSITY
4.
CASE E
SCP SCF
IP
ALCATEL UNIVERSITY
32
5.
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 }
33
ALCATEL UNIVERSITY
5.
PlayAnnouncementArg
::= SEQUENCE { [0] InformationToSend, [1] BOOLEAN, [2] BOOLEAN, [3] SEQUENCE SIZE(1..numOfExtensions) OF ExtensionField OPTIONAL }
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
ALCATEL UNIVERSITY
34
5.
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
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
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
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.
ALCATEL UNIVERSITY
36
5.
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
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
DisconnectForwardConnection Disconnect
ALCATEL UNIVERSITY
38
5.
SCP
SSP
Setup request
IP
Setup response
DisconnectFromIPForbidden = FALSE
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
ConnectToResource
Disconnect
ALCATEL UNIVERSITY
40
5.
SCP
InitialDP
SSP
IP
P&C
DisconnectFromIPForbidden = TRUE
41
ALCATEL UNIVERSITY
5.
ALCATEL UNIVERSITY
42
6.
TRAFFIC MANAGEMENT
6. TRAFFIC MANAGEMENT
Different procedures are foreseen :
-
6.1 CallGap
Call gapping is a traffic management method where a time period is specified between two consecutive calls.
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
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:
-
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
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 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.
ALCATEL UNIVERSITY
44
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, 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,
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 :
-
The location number identifies the geographical area from which the call to be filtered originates.
ALCATEL UNIVERSITY
46
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 }
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
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.
47
ALCATEL UNIVERSITY
6.
TRAFFIC MANAGEMENT
ALCATEL UNIVERSITY
48
7.
Charge Determination Charge Generation Charge Registration Online Charge Information provision Charge Output Offline charging billing and accounting
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.
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
Connect(3)
Local Exchange
IAM
SSP
ALCATEL UNIVERSITY
50
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
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.
ALCATEL UNIVERSITY
52
7.
ApplyChargingArg
::= SEQUENCE { [0] AChBillingChargingCharacteristics, [1] BOOLEAN DEFAULT FALSE, [2] LegID OPTIONAL
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.
53
ALCATEL UNIVERSITY
7.
ApplyChargingReport ARGUMENT ApplyChargingReportArg ERRORS{ MissingParameter, UnexpectedComponentSequence, UnexpectedParameter, UnexpectedDataValue, ParameterOutOfRange, SystemFailure, TaskRefused
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
} The Apply ChargingReportArg contains the information requested for in the ApplyCharging. The contents is operator specific
ALCATEL UNIVERSITY
54
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),
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
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 .
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
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
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
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,
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
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
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
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
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
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 {
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
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,
59
ALCATEL UNIVERSITY
7.
ALCATEL UNIVERSITY
60
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).
61
ALCATEL UNIVERSITY
8.
CHARGING SCENARIOS
SCP
InitialDP with charging request(2) Send Charging information (3)
Charging point
SSP
nonIn charge record
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)
ALCATEL UNIVERSITY
62
8.
CHARGING SCENARIOS
SCP
Furnish Charging and ApplyCharging ApplyCharging report
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.
63
ALCATEL UNIVERSITY
8.
CHARGING SCENARIOS
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)
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
Charging point
ApplyCharging or furnishCharging
SSP
nonIn charge record
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).
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
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.
65
ALCATEL UNIVERSITY
8.
CHARGING SCENARIOS
ALCATEL UNIVERSITY
66
9.
67
ALCATEL UNIVERSITY
9.
SCP > SSP SCP > SSP SCP > SSP SCP > SSP
55
ALCATEL UNIVERSITY
68
9.
Charging
FURNISH CHARGING APPLY CHARGING APPLY CHARGING REPORT SEND CHARGING INFORMATION UPDATE (charging) UPDATE (charging) UPDATE (charging report)
Mass Calling
ACTIVATE SERVICE FILTERING SERVICE FILTERING RESPONSE
Traffic Management
CALL GAP
Others
RESET TIMER ALC JOIN ALC SPLIT ALC FREE
69
ALCATEL UNIVERSITY
9.
ALCATEL UNIVERSITY
70
10.
SCENARIOS
10.SCENARIOS
Figure 30 : A normal call scenario
SCP
InitialDP
SSP
Connect
FurnishChargingInformation
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
ApplyCharging
RequestReportBCSMEvent
71
ALCATEL UNIVERSITY
10.
SCENARIOS
SCP
InitialDP
SSP
Connect to Resource
P&C
DisconnectFromIPForbidden = TRUE
P&C result
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
P&C
DisconnectFromIPForbidden =FALSE
P&C result
Connect
ALCATEL UNIVERSITY
72
10.
SCENARIOS
SCP
Initiate Call Attempt
SSP
EventReportBCSM
ConnectToResource
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
PlayAnnouncement
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
InitialDP ServiceFilteringResponse (counters, N1 calls have been filtered) ConnectToResource PlayAnnouncement ReleaseCall
ALCATEL UNIVERSITY
74
10.
SCENARIOS
SCP
InitialDP
SSP
IP
P&C
DisconnectFromIPForbidden = TRUE
75
ALCATEL UNIVERSITY
10.
SCENARIOS
ALCATEL UNIVERSITY
76
11.
the leg id the release cause and the parameter Immediate execution.
11.2 AlcJoin
E 2000 ALCATEL BELL N.V. ALL RIGHTS RESERVED
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 :
-
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.
77
ALCATEL UNIVERSITY