ETSI Core INAP

INAP Contents Page

When receiving this operation, the SSF handles calls to destinations in a specified manner without request for instructions to the SCF. In the case of service filtering the SSF executes a specific service filtering algorithm. For the transfer of service filtering results refer to the operation "ServiceFilteringResponse".

7.3.1.1.1 Parameters

filteredCallTreatment:

This parameter specifies how filtered calls are treated. It includes information about the announcement to be played, the charging approach, the number of counters used and the release cause to be applied to filtered calls.

sFBillingChargingCharacteristics:: This parameter determines the charging to be applied for service filtering. Its content is network specific.
informationToSend:: This parameter indicates an announcement, a tone or display information to be sent to the calling party. At the end of information sending, the call shall be released.

inbandInfo:: This parameter specifies the inband information to be sent.

messageID:: This parameter indicates the message(s) to be sent, it can be one of the following:

numberOfRepetitions:: This parameter indicates the maximum number of times the message shall be sent to the end-user.
duration:: This parameter indicates the maximum time duration in seconds that the message shall be played/repeated. ZERO indicates endless repetition. When not included, a network specific duration is assumed.
interval:: This parameter indicates the time interval in seconds between repetitions, i.e. the time between the end of the announcement and the start of the next repetition. This parameter can only be used when the number of repetitions is greater than one.

tone:: This parameter specifies a tone to be sent to the end-user.

toneID:: This parameter indicates the tone to be sent.
duration:: This parameter indicates the time duration in seconds of the tone to be sent. ZERO indicates infinite duration.

maximumNumberOfCounters:: This parameter provides the number of counters to be allocated as well as the number of destinations included in the service filtering, i.e. "maximumNumberOfCounters" subsequent destination addresses beginning with the destination address provided in "filteringCriteria" are used for service filtering. One counter is assigned to each of these destination addresses.
The number of counters may only be >1 if the "filteringCriteria" are of the type "addressAndService".
releaseCause:: This parameter provides the cause value used for call release after the "informationToSend" (e.g. announcement) has been sent to the calling party. If "releaseCause" is not present, the default value is the same as the ISUP value decimal 31 (normal unspecified).

filteringCharacteristics:

This parameter indicates the severity of the filtering and the point in time when the "ServiceFilteringResponse" shall be sent. It determines whether the "interval" or the "numberOfCalls" are used.

interval:

After expiration of the interval timer the next call to arrive causes following actions:

sending of an "InitialDP";
sending of an "ServiceFilteringResponse";
starting again the interval timer.

When filtering is started the first interval is started.
An interval of 0 indicates that all calls matching the filtering criteria will result in sending of an "InitialDP" operation and no filtering will be applied (i.e., no "ServiceFilteringResponse" will be sent).
An interval of -1 indicates that none of the calls matching the filtering criteria will either result in sending of an "InitialDP" operation or a "ServiceFilteringResponse" operation.
Other values indicate duration in seconds.

numberOfCalls:

The nth call causes an "InitialDP" and an "ServiceFilteringResponse" operation sent to the SCF. This threshold value is met if the sum of all counters assigned to one service filtering entity is equal to "numberOfCalls".
A number of calls of 0 indicates that none of the calls matching the filtering criteria will result in sending of an "InitialDP" operation and a "ServiceFilteringResponse" operation.

filteringTimeOut:

This parameter indicates the duration of the filtering. When the time expires, a "ServiceFilteringResponse" is sent to the SCF and service filtering is stopped. Two approaches are supported (duration or stopTime):

duration:: If the duration time expires, then service filtering is stopped and the final report is sent to the SCF.
A duration of 0 indicates that service filtering is to be removed.
A duration of -1 indicates an infinite duration.
A duration of -2 indicates a network specific duration.
Other values indicate duration in seconds.
stopTime:: When the "stopTime" is met then service filtering is stopped and the final report is sent to the SCF. If "stopTime" was already met, i.e. the value of the stopTime is less than the value of the actual time but the difference does not exceed the value equivalent to 50 years, then service filtering is immediately stopped and the actual counter values are reported to the SCF. This occurs in cases where the SCF wishes to explicitly stop a running service filtering.

filteringCriteria:

This parameter specifies which calls are filtered based on "serviceKey", "callingAddressValue", "calledAddressValue" or "locationNumber". It is a choice of "servicekey" or "addressAndService".

serviceKey:

This parameter identifies unambiguously the requested IN service for which filtering should be applied.

addressAndService:

This parameter identifies the IN service and dialled number for which filtering should be applied. The geographical area may also be identified ("callingAddressValue" and/or "locationNumber").

serviceKey:
calledAddressValue:: This parameter contains the dialled number towards which filtering shall be applied. The complete called party number shall be specified.
callingAddressValue:: This parameter contains the calling party number which identifies the calling party or geographical origin of the call for which filtering shall be applied.
locationNumber:: This parameter identifies the geographical area from which the call to be filtered originates. It is used when "callingAddressValue" does not contain any information about the geographical location of the calling party.

startTime:

This parameter defines when filtering is started. If "startTime" is not provided or was already met, the SSF starts filtering immediately.

7.3.1.2 Invoking entity (SCF)

7.3.1.2.1 Normal procedure

SCF precondition:

(1)SLPI detects that service filtering has to be initiated at the SSF.

SCF postconditions:

(1)SLPI starts an application timer to monitor the expected end of service filtering.
(2)The SCME is in the state "Waiting For ServiceFilteringResponse".

Sending the "ActivateServiceFiltering" operation causes a transition of the SCME from the state "Service Filtering Idle" to the state "Waiting For SSF Service Filtering Response". The SCME remains in this state until the application timer in the SLPI expires. The SCME is informed by the SLPI about timer expiration. Then it moves to the state "Service Filtering Idle".
If no errors occurred after receiving an "ActivateServiceFiltering" at the SSF an empty Return Result is sent to the SCF. That causes no state transition in the SCME.
To change the parameters of an existing service filtering entity the SCF has to send an "ActivateServiceFiltering" operation with the same "filtering Criteria". The second parameter set replaces the first one.

7.3.1.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.1.3 Responding entity (SSF)

7.3.1.3.1 Normal procedure

SSF precondition:

None.

SSF postcondition:

(1)The SSME FSM is in the state "Non Call Associated Treatment".

If there is no already existing SSME FSM for the "filteringCriteria" provided then a new SSME FSM is created. This SSME FSM enters the state "Non-Call Associated Treatment" and initialises the service filtering for the specified IN calls. The parameters "filteredCallTreatment", "filteringCharacteristics", "filteringCriteria", "filteringTimeOut" and "startTime" are set as provided in the operation. A number of counters will be allocated and reset. In the case of the "startTime" that has not been met yet, the service filtering will be started at the specified point in time.
If the operation "ActivateServiceFiltering" addresses an already existing service filtering entity the parameters "filteredCallTreatment", "filteringCharacteristics" "filteringTimeOut" and "startTime" are modified as provided in the operation. In the case that the addressed service filtering entity is active the SSF reports the counter values to the SCF via the operation "ServiceFilteringResponse". The service filtering process is stopped if an already expired "stopTime" or "duration" equal to ZERO or a new not yet met "startTime" is provided. The SSF then proceeds as described for "ServiceFilteringResponse". In the case of the "startTime" that has not been met yet, the service filtering will be continued at the specified point in time.
If the service filtering proceeds then the SSME FSM remains in the state "Non-Call Associated Treatment". Otherwise the SSME FSM moves to state "Idle Management".
When a call matches several active "filteringCriteria" it should be subject to filtering on the most specific criteria, i.e. the criteria with the longest "callingAddressValue" or "locationNumber", or alternatively the criteria with the largest number of parameters specified.
When performing service filtering with the "filteringCriteria"-"addressAndService" the first parameters checked will always be the "serviceKey" and "calledAddressValue".
If an "ActivateServiceFiltering" operation is passed to the SSF with the "filteringCriteria" "addressAndService" with both callingAddressValue and "locationNumber" present, the following is applicable:
When the SSF receives a call that matches "serviceKey" and "calledAddressValue" (in the active "filteringCriteria"), it investigates whether or not the "locationNumber" is present in the initial address message. If it is present and matches the active "filteringCriteria" the call is filtered. If the SSF finds that the "locationNumber" is absent, then it will check the "callingAddressValue" and perform filtering depending on that parameter.
If no errors occurred after receiving an "ActivateServiceFiltering" on the SSF an empty Return Result is sent to the SCF. That causes no state transition in the SSME FSM.
The following application timers are used:

detect moment to start service filtering (start time);
duration time for service filtering;
interval time for service filtering (for timer controlled approach).

7.3.1.3.2 Error handling

If the SSF detects an error with any of the defined error values then this error is reported to the SCF.
The event is recorded in the SSF and an error condition indicated.
In case a new SSME FSM should be created, the relationship is ended and all concerned resources are released. The SSME FSM remains in the state "Idle Management".
In case there is already an existing SSME FSM, the service filtering data remains unchanged. The SSME FSM remains in the state "Non-Call Associated Treatment".
Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.2 ActivityTest procedure

7.3.2.1 General description

This operation is used to check for the continued existence of a relationship between the SCF and SSF. If the relationship is still in existence, then the SSF will respond. If no reply is received, then the SCF will assume that the SSF has failed in some way and will take the appropriate action.

7.3.2.1.1 Parameters

None.

7.3.2.2 Invoking entity (SCF)

7.3.2.2.1 Normal procedure

SCF preconditions:

(1)A relationship exists between the SCF and the SSF.
(2)The activity test timer expires, TActTest, after which the "ActivityTest" operation is sent to the SSF.

SCF postcondition:

(1)If a Return Result "ActivityTest" is received, the SCME resets the activity test timer and takes no further action.

7.3.2.2.2 Error handling

If a time out on the "ActivityTest" operation or a P-Abort is received from TCAP, this is an indication that the relationship with the SSF was somehow lost. If a time-out is received, SCF aborts the dialogue.
The SLPI that was the user of this dialogue will be informed, the corresponding SCSM FSM will move to the state "idle".

7.3.2.3 Responding entity (SSF)

7.3.2.3.1 Normal procedure

SSF precondition:

(1)A relationship exists between the SCF and the SSF.

SSF postconditions:

(1)The SSME FSM stays in, or moves to the state "Non Call Associated Treatment".
(2)If the Dialogue ID is active and if there is a SSF FSM using the dialogue, the SSME sends a Return Result "ActivityTest" to the SCF. If there are no other management activities, the SSME FSM returns to the state "Idle Management", or
If the Dialogue ID is not active, the TCAP in the SSP will issue a P-Abort, the SSME will in that case never receive the "ActivityTest" operation and thus will not be able to reply.

7.3.2.3.2 Error handling

Not applicable.

7.3.3 ApplyCharging procedure

7.3.3.1 General description

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.
The charging scenarios supported by this operation are scenarios 4.1 and 4.2 (refer to Annex B).

7.3.3.1.1 Parameters

aChBillingChargingCharacteristics:: This parameter specifies the charging related information to be provided by the SSF and the conditions on which this information has to be reported back to the SCF via the "ApplyChargingReport" operation. Its contents is network operator specific.
sendCalculationToSCPIndication:: This parameter indicates that "ApplyChargingReport" operations (at least one at the end of the connection configuration charging process) are expected from the SSF. This parameter is always set to TRUE.
partyToCharge:: This parameter indicates the party in the call to which the "ApplyCharging" operation should be applied. If it is not present, then it is applied to the A-party.

7.3.3.2 Invoking entity (SCF)

7.3.3.2.1 Normal procedure

SCF Preconditions
(1)A control relationship exists between the SCF and the SSF.
(2)The SLPI has determined that an "ApplyCharging" operation has to be sent.

SCF postconditions:

(1)No FSM state transition.
(2)The SLPI is expecting "ApplyChargingReport" operations from the SSF.

The SCSM FSM is in state "Preparing SSF Instructions" or is in state "Queuing FSM". This operation is invoked by the SCF if a SLPI results in the request of interacting with the charging mechanisms within the SSF to get back information about the charging.

7.3.3.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services used for reporting operation errors are described in subclause 7.4.

7.3.3.3 Responding entity (SSF)

7.3.3.3.1 Normal procedure

SSF preconditions:

(1)The SSF FSM is in one of the following states:

"Waiting for Instructions" (state c),
"Waiting for End of User Interaction" (state d),
"Waiting for End of Temporary Connection" (state e), or
the assisting/hand-off SSF FSM is in state: "Waiting for Instructions" (state b)

SSF postcondition:

(1)No FSM state transition

On receipt of this operation, the SSF sets the charging data using the information elements included in the operation and acts accordingly. In addition, the SSF will start the monitoring of the end of the connection configuration and other charging events, if requested.

7.3.3.3.2 Error handling

MissingParameter: This error is indicated if the "sendCalculationToSCPIndication" is not provided.
UnexpectedDataValue: This error is indicated if the "sendCalculationToSCPIndication" is set to FALSE.
Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services used for reporting operation errors are described in subclause 7.4.

7.3.4 ApplyChargingReport procedure

7.3.4.1 General description

This operation is used by the SSF to report charging related information to the SCF as requested by the SCF using the "ApplyCharging" operation.
During a connection configuration the "ApplyChargingReport" operation may be invoked on multiple occasions. For each call party and each connection configuration, the "ApplyChargingReport" operation may be used several times. Note that at least one "ApplyChargingReport" operation is to be sent at the end of the connection configuration charging process.
The charging scenarios supported by this operation are scenarios 4.1 and 4.2 (refer to Annex B).

7.3.4.1.1 Parameters

CallResult: This parameter provides the SCF with the charging related information previously requested using the "ApplyCharging" operation with its "sendCalculationToSCPIndication" parameter set to TRUE. The "CallResult" will include the "partyToCharge" parameter as received in the related "ApplyCharging" operation to correlate the result to the request. The remaining content of "CallResult" is network operator specific. Examples of these contents may be: bulk counter values, costs, tariff change and time of change, time stamps, durations, etc.

7.3.4.2 Invoking entity (SSF)

7.3.4.2.1 Normal procedure

SCF
SCFApplyCharging

(1)If the connection configuration does not change then no FSM state transition shall occur.
If the connection configuration changes then the FSM shall move to:

"Idle" state if there is no other EDP armed and no report requests are pending, or otherwise;
shall remain in the same state.

This operation is invoked if a charging event has been detected that was requested by the SCF. The "ApplyChargingReport" operation only deals with charging events within the SSF itself. Examples of charging events may be: threshold value reached, timer expiration, tariff change, end of connection configuration, etc.

7.3.4.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services used for reporting operation errors are described in subclause 7.4.

7.3.4.3 Responding entity (SCF)

7.3.4.3.1 Normal Procedure

SCF preconditions:

(1)An "ApplyCharging" operation with its "sendCalculationToSCPIndication" parameter set to TRUE has been sent at the request of an SLPI and the SLPI is expecting an "ApplyChargingReport" from the SSF.
SCF postconditions:

(1)No FSM state transition if further reports, including "EventReportBCSM" and "CallInformationReport", are expected, or Transition to the state "Idle" if the report is the last one and no "EventReportBCSM" or "CallInformationReport" is expected.

On receipt of this operation, the SLPI which is expecting this operation will continue.

7.3.4.3.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services used for reporting operation errors are described in subclause 7.4.

7.3.5 AssistRequestInstructions procedure

7.3.5.1 General description

This operation is sent to the SCF by an SSF, which is acting as the assisting SSF in an assist or hand-off procedure, or by a SRF. The operation is sent when the assisting SSF or SRF receives an indication from an initiating SSF containing information indicating an assist or hand-off procedure.

7.3.5.1.1 Parameters

correlationID:: This parameter is used by the SCF to associate the "AssistRequestInstructions" from the assisting SSF or by a SRF with the "InitialDP" from the initiating SSF. The value of the "correlationID" may be extracted from the digits received from the initiating SSF or be all of the digits.
iPAvailable:: This parameter is sent by the assisting or hand-off SSP to indicate whether or not an IP is attached and available (i.e. not exhausted) at the SSP. This parameter is applicable to this operation only in the physical scenarios corresponding to assist with relay or hand-off. The use of this parameter is network operator dependent.
iPSSPCapabilities:: This parameter is sent by the assisting or hand-off SSP to indicate which SRF resources are supported within the SSP and attached and available. This parameter is applicable to this operation only in the physical scenarios corresponding to assist with relay or hand-off. The use of this parameter is network operator dependent.

7.3.5.2 Invoking entity (SSF/SRF)

7.3.5.2.1 Normal procedure

SSF precondition:

(1)An assist indication is detected by the assisting SSF.

SSF postcondition:

(1)The assisting SSF waits for instructions.

On receipt of an assist indication from the initiating SSF, the SSF or SRF shall assure that the required resources are available to invoke an "AssistRequestInstructions" operation in the SSF/SRF and indicate to the initiating SSF that the call is accepted (refer to Q.71). The "AssistRequestInstructions" operation is invoked by the SSF or SRF after the call, which initiated the assist indication, is accepted. The assisting SSF FSM transitions to state "Waiting For Instructions".

7.3.5.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.5.3 Responding entity (SCF)

7.3.5.3.1 Normal procedure

SCF preconditions:

(1)A control relationship exists between the SCF and the initiating SSF.
(2)The SCF waits for "AssistRequestInstructions".

SCF postcondition:

(1)An SSF or SRF instruction is being prepared.

On receipt of this operation in the SCSM state "Waiting for Assist Request Instructions", the SCP has to perform the following actions:
If the "AssistRequestInstructions" operation was received from an assisting SSF, and the resource is available, the SCSM prepares the "ConnectToResource" and "PlayAnnouncement" or "PromptAndCollectUserInformation" to be sent to the assisting SSF.
The SCF determines SSF/SRF by means of "correlationID", "destinationNumber" or network knowledge.
If the "AssistRequestInstructions" operation was received from a SRF, and the resource is available, the SCSM prepares the "PlayAnnouncement" or "PromptAndCollectUserInformation" to be sent to the SRF.

7.3.5.3.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.6 CallGap procedure

7.3.6.1 General description

This operation is used to request the SSF to reduce the rate at which specific service requests are sent to the SCF.

7.3.6.1.1 Parameters

gapCriteria:

This parameter identifies the criteria for a call to be subject to call gapping.

calledAddressValue:: This parameter indicates that call gapping will be applied when the leading digits of the dialled number of a call attempt match those specified in "gapCriteria".
gapOnService:: This parameter indicates that call gapping will be applied when the "servicekey" of a call attempt match those specified in "gapCriteria".
calledAddressAndService:: This parameter indicates that call gapping will be applied when the "serviceKey" and the leading digits of the dialled number of a call attempt match those specified in "gapCriteria".
callingAddressAndService:: This parameter indicates that call gapping will be applied when the "serviceKey" and the leading digits of the calling party number or the location number of a call attempt match those specified in "gapCriteria".

gapIndicators:

This parameter indicates the gapping characteristics.

duration:: Duration specifies the total time interval during which call gapping for the specified gap criteria will be active.
A duration of 0 indicates that gapping is to be removed.
A duration of -1 indicates an infinite duration.
A duration of -2 indicates a network specific duration.
Other values indicate duration in seconds.
gapInterval:: This parameter specifies the minimum time between calls being allowed through.
An interval of 0 indicates that calls meeting the gap criteria are not to be rejected.
An interval of -1 indicates that all calls meeting the gap criteria are to be rejected.
Other values indicate interval in milliseconds.

controlType:

This parameter indicates the reason for activating call gapping.
The "controlType" value "sCPOverloaded" indicates that an automatic congestion detection and control mechanism in the SCP has detected a congestion situation.
The "controlType" value "manuallyInitiated" indicates that the service and or network/service management centre has detected a congestion situation, or any other situation that requires manually initiated controls.
The controlType "manuallyInitiated" will have priority over "sCPOverloaded" call gap.
It should be noted that also non-IN controlled traffic control mechanism can apply to an exchange with the SSF functionality. As the non-IN controlled traffic control is within the CCF, this traffic control has implicit priority over the IN controlled traffic control. The non-IN controlled traffic control may also have some influence to the IN call. Therefore it is recommended to take measures to co-ordinate several traffic control mechanisms. The non-IN controlled traffic control and co-ordination of several traffic control mechanisms are out of the scope of core INAP.

gapTreatment:

This parameter indicates how calls that were stopped by the call gapping mechanism shall be treated.

informationToSend:

This parameter indicates an announcement, a tone or display information to be sent to the calling party. At the end of information sending, the call shall be released.

inbandInfo:: This parameter specifies the inband information to be sent.

messageID:: This parameter indicates the message(s) to be sent, it can be one of the following:

numberOfRepetitions:: This parameter indicates the maximum number of times the message shall be sent to the end-user.
duration:: This parameter indicates the maximum time duration in seconds that the message shall be played/repeated. ZERO indicates endless repetition. When not included, a network specific duration is assumed.
interval:: This parameter indicates the time interval in seconds between repetitions, i.e. the time between the end of the announcement and the start of the next repetition. This parameter can only be used when the number of repetitions is greater than one.

tone:: This parameter specifies a tone to be sent to the end-user.

toneID:: This parameter indicates the tone to be sent.
duration:: This parameter indicates the time duration in seconds of the tone to be sent. ZERO indicates infinite duration.

displayInformation:: This parameter indicates a text string to be sent to the end-user. This information can not be received by a PSTN end-user.
releaseCause:: This parameter indicates that the call shall be released using the given release cause.
both:: This parameter indicates inband information, a tone or display information to be sent to the calling party. At the end of information sending, the call shall be released, using the given release cause.

7.3.6.2 Invoking entity (SCF)

7.3.6.2.1 Normal procedure

SCF preconditions:

(1)The SCF detects an overload condition persists and call gapping has to be initiated at the SSF, or
The SCF receives a manually initiated call gapping request from the SMF.

SCF postcondition:

(1)The SCME FSM remains in the same state upon issuing the "CallGap" operation.

A congestion detection and control algorithm monitors the load of SCP resources. After detection of a congestion situation the parameters for the "CallGap" operation are provided.
If the congestion level changes new "CallGap" operations may be sent for active gap criteria but with new gap interval. If no congestion is detected gapping may be removed.
A manual initiated call gap will take prevail over an automatic initiated call gap.

7.3.6.2.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

7.3.6.3 Responding entity (SSF)

7.3.6.3.1 Normal procedure

SSF preconditions:

(1)Call gapping for gapCriteria is not active, or
Call gapping for gapCriteria is active.

SSF postconditions:

(1)The SSME FSM is in the state "Non call associated treatment".
(2)Call gapping for gapCriteria is activated, or
Call gapping for gapCriteria is renewed, or
Call gapping for gapCriteria is removed.

If there is no already existing SSME FSM for the gap criteria provided then a new SSME FSM is created. This SSME FSM enters the state "Non call associated treatment" and initialises call gapping for the specified IN calls. The parameters "gapIndicators", "controlType" and "gapTreatment" for the indicated gap criteria will be set as provided by the "CallGap" operation.
In general, the manuallyInitiated call gapping will prevail over automatically initiated ("sCPOverloaded"). More specifically, the following rules will be applied in the SSF to manage the priority of different control Types associated with the same "gapCriteria":
If an SSME FSM already exists for the "gapCriteria" provided, then:

1)if the (new) "controlType" equals an existing "controlType", then the new parameters (i.e., "gapIndicators" and "gapTreatment") will overwrite the existing parameter values;
2)if the (new) "controlType" is different than the existing "controlType", then the new parameters (i.e., "controlType", "gapIndicators", and "gapTreatment") will be appended to the appropriate SSME FSM (in addition to the existing parameters). The SSME FSM remains in the state "Non-Call Associated Treatment".

If the SSF meets a TDP, it will check if call gapping was initiated either for the "serviceKey" or for the "calledAddressValue" assigned to this TDP. If not, an "InitialDP" operation can be sent. In case call gapping was initiated for "calledAddressAndService" or "callingAddressAndService" and the "serviceKey" matches, a check on the "calledAddressValue" and "callingAddressValue" (and optionally "locationNumber") for active call gapping is performed. If not, an "InitialDP" operation can be sent.
In case of gapping on "callingAddressAndService" and the parameter "locationNumber" is present, gapping will be performed on "locationNumber" instead of "callingAddressValue".
If a call to a controlled number matches only one "gapCriteria", then the corresponding control is applied. If both "manuallyInitiated" and "sCPOverload" controls are active, then only the manually initiated control will be applied.
If a call to a controlled called number matches several active "gapCriteria", then only the "gapCriteria" associated with the longest called party number should be used, and the corresponding control should be applied. For example, the codes 1234 and 12345 are under control. Then the call with 123456 is subject to the control on 12345. Furthermore, if both "manuallyInitiated" and "sCPOverloaded" "controlType" values are active for this "gapCriteria", then the "manuallyInitiated" control will be applied.
If call gapping shall be applied and there is no gap interval active, an "InitialDP" operation can be sent including the "cGEncountered" parameter according to the specified controlType. A new gap interval will be initiated as indicated by "gapInterval".
If a gap interval is active, no "InitialDP" is sent and the call is treated as indicated by "gapTreatment".
The call gap process is stopped if the indicated duration equals ZERO.
If call gapping proceeds then the SSME FSM remains in the state "Non call associated treatment". Otherwise, the SSME FSM moves to state "idle management".

7.3.6.3.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

7.3.7 CallInformationReport procedure

7.3.7.1 General description

This operation is used to send specific call information for a single call to the SCF as requested by the SCF in a previous "CallInformationRequest" operation.

7.3.7.1.1 Parameters

requestedInformationList:: According to the requested information the SSF sends the appropriate types and values to the SCF.

7.3.7.2 Invoking entity (SSF)

7.3.7.2.1 Normal procedure

(1)At least one party disconnects from a call.
(2)Requested call information has been collected.
(3)"CallInformationReport" is pending due to a previously received "CallInformationRequest" operation.
(4)A control relationship exists between the SCF and the SSF.

SSF postcondition:; (1)The SSF FSM shall move to the "Idle" state in the case where no other report requests are pending and no EDPs are armed otherwise the SSF FSM shall remain in the same state.

If the SSF FSM executes a state transition caused by one of the following events:
A party release;
A party abandon;
B party release;
B party busy;
SSF no answer timer expiration;
route select failure indicated by the network;
release call initiated by the SCF,

and a "CallInformationRequest" is pending then the "CallInformationReport" operation is sent to the SCF.
If a "CallInformationReport" has been sent to the SCF then no "CallInformationReport" is pending, i.e. a further "CallInformationReport", e.g. in the case of follow-on, has to be explicitly requested by the SCF.
If the event causing the "CallInformationReport" is also detected by an armed EDP-R then immediately after "CallInformationReport" the corresponding "EventReportBCSM" has to be sent.
If the event causing the "CallInformationReport" is also detected by an armed EDP-N then immediately before "CallInformationReport" the corresponding "EventReportBCSM" has to be sent.

7.3.7.2.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

7.3.7.3 Responding entity (SCF)

7.3.7.3.1 Normal procedure

SCF preconditions:

(1)An SLPI is expecting "CallInformationReport".
(2)A control relationship exists between the SCF and the SSF.

SCF postcondition:

(1)The SLPI may be further executed.

In any state (except "Idle") the SCSM may receive "CallInformationReport" from the SSF, when the "CallInformationReport" is outstanding.
If "CallInformationReport" is outstanding and the SLP indicates that the processing has been completed, the SCSM remains in the same state until it receives the "CallInformationReport" operation.
When the SCF receives the "CallInformationReport" operation and the SL processing has been completed, then the SCSM moves to the "Idle" state.
When the SCF receives the "CallInformationReport" operation and the SL processing has not been completed yet, then the SCSM remains in the same state (EventReportBCSM or ApplyChargingReport pending).

7.3.7.3.2 Error handling

If requested information is not available, a "CallInformationReport" will be sent, indicating the requested information type, but with "RequestedInformationValue">RequestedInformationValue" filled in with an appropriate default value.
Operation related error handling is not applicable, due to class 4 operation.

7.3.8 CallInformationRequest procedure

7.3.8.1 General description

This operation is used to request the SSF to record specific information about a single call and report it to the SCF using the "CallInformationReport" operation.

7.3.8.1.1 Parameters

requestedInformationTypeList:

This parameter specifies a list of specific items of information which is requested.
The list may contain:

callAttemptElapsedTime:: This parameter indicates the duration between the end of INAP processing of operations initiating call setup ("Connect") and the received answer indication from the called party side.
In case of unsuccessful call setup the network event indicating the unsuccessful call setup stops the measurement of "callAttemptElapsedTime".
callStopTime:: This parameter indicates the time stamp when the connection is released.
callConnectedElapsedTime:: This parameter indicates the duration between the received answer indication from the called party side and the release of the connection.
calledAddress This parameter indicates the incoming called party address that was received by the SSF (i.e., before translation by the SCF).
releaseCause:: This parameter indicates the release cause for the call.

Any set of these values can be requested.

7.3.8.2 Invoking entity (SCF)

7.3.8.2.1 Normal procedure

SCF preconditions:

(1)A control relationship exists between the SCF and the SSF.
(2)The SLPI has determined that a "CallInformationRequest" operation has to be sent by the SCF.

SCF postcondition:

(1)The SLPI is expecting a "CallInformationReport" from SSF.

When the SLP requests call information, the SCF sends the "CallInformationRequest" operation to the SSF to request the SSF to provide call related information.
The "CallInformationRequest" operation specifies the information items to be provided by the SSF.

7.3.8.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.8.3 Responding entity (SSF)

7.3.8.3.1 Normal procedure

SSF preconditions:

(1)Call origination attempt has been initiated.
(2)A control relationship exists between SSF and SCF.

SSF postconditions:

(1)Requested call information is retained by the SSF.
(2)The SSF is waiting for further instructions.

The SSF may receive the "CallInformationRequest" operation within an existing call associated (CA) dialogue only.
The "CallInformationRequest" operation is accepted by the SSF Finite State Machine (SSF FSM) only in the state "Waiting for Instructions". The operation does not lead to any transition to another state.
The SSF allocates a record and stores the requested information if already available and prepares the recording of information items that will become available later, e.g. "callStopTimeValue".

7.3.8.3.2 Error handling

In any other than the "Waiting for Instruction" state the "CallInformationRequest" operation will be handled as "out of context".
Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.9 Cancel procedure

7.3.9.1 General description

The SCF uses this class 2 operation to request the SRF to cancel a correlated previous operation.
The operation to be deleted can be either a "PlayAnnouncement" operation (PA) or a "PromptAndCollectUserInformation" operation (P&C).
The cancellation of an operation is indicated via a respective error indication, "Canceled", to the invoking entity of the cancelled "PlayAnnouncement" or "PromptAndCollectUserInformation" operation.
The "Cancel" operation can also be used to cancel all outstanding requests and enable the state machines (SSF/SRF) to go to idle. In this case the "Cancel" operation does not specify any specific operation to be cancelled.

7.3.9.1.1 Parameters

invokeID:: This parameter specifies which operation is to be cancelled.
allRequests:: This parameter indicates that all active requests for "EventReportBCSM", "EventNotificationCharging", "ApplyChargingReport" and "CallInformationReport" should be cancelled.

7.3.9.2 Invoking entity (SCF)

7.3.9.2.1 Normal procedure

SCF preconditions:

(1)A control relationship exists between the SCF and the SSF/SRF.
(2)An SLPI in the "Waiting for response from SRF" state has determined that a previously requested operation is to be cancelled, or
A SLPI has determined that it is no longer interested in any reports or notifications from the SSF and that the control relationship should be ended.

SCF postcondition:

(1)The SLPI remains in the "Waiting for Response from SRF" state, or
In case all requests are cancelled, the control relationship with the concerned FE (SSF) is ended. If no other relationships persist, the SCSM FSM returns to "idle" state.

7.3.9.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.9.3 Responding entity (SRF)

7.3.9.3.1 Normal procedure

SRF precondition:

(1)A PA/P&C has been received and the SRF is in the "User Interaction" state.

SRF postcondition:

(1)The execution of the PA/P&C has been aborted and the SRF remains in the "User Interaction" state.

7.3.9.3.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.9.4 Responding entity (SSF)

7.3.9.4.1 Normal procedure

SSF precondition:

(1)The SSF FSM is in the states "Waiting for Instructions" or "Monitoring".

SSF postcondition:

(1)All active request for reports and notifications have been cancelled.
(2)In case the SSF FSM was in state "Monitoring" it shall return to idle, or
In case the SSF FSM was in state "Waiting for Instructions" it will remain in that state.
A subsequent call-processing operation will move the SSF FSM state to "Idle". The call, if in active state, is further treated by SSF autonomously as a normal (non-IN) call.

All resources allocated to the dialogue are released.

7.3.9.4.2 Error handling

Sending of return error on cancel is not applicable in the cancel "allRequests" case.

7.3.10 CollectInformation procedure

7.3.10.1 General description

This is a class 2 operation which is used to request the SSF to perform the basic originating call processing actions which will collect destination information from a calling party (it is normally associated with a "RequestReportBCSMEvent" operation to arm DP2 and to specify the number of digits to be collected).
This operation uses only the resources of the SSF/CCF to collect the information, unlike "PromptAndCollectUserInformation", which uses the capabilities of the SRF. It follows that the use of this operation is only appropriate for a call which has not yet left the setup phase.

7.3.10.1.1 Parameters

None.

7.3.10.2 Invoking entity (SCF)

7.3.10.2.1 Normal procedure

SCF precondition:

(1)An SLPI has determined that more information from the calling party is required to enable processing to proceed.

SCF postcondition:

(1)SLPI execution is suspended pending receipt of dialled digits.

This operation is invoked in the SCSM FSM state "Preparing SSF Instructions" if the SLP requires additional information to progress the call. It causes a transition of the FSM to the state "Waiting for Notification or Report".

7.3.10.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.10.3 Responding entity (SSF)

7.3.10.3.1 Normal procedure

SSF precondition:

(1)An "InitialDP" operation has been invoked.

SSF postconditions:

(1)The SSF has executed a transition to the state "Monitoring".
(2)The SSF performs the call processing actions to collect destination information from the calling party. This may include prompting the party with in-band or out-band signals.
(3)Basic Call Processing is resumed at PIC2.

The operation is only valid in the state "Waiting for Instruction" and after having received an operation "RequestReportBCSMEvent" for DP2. The SSP has to perform the following actions:

The SSF cancels TSSF.
When the requisite number of digits (specified when DP2 was armed) has been received, DP2 will be encountered, an "EventReportBCSM" operation will be invoked, and the SSF FSM will return to the state "Waiting for Instruction".

7.3.10.3.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.11 Connect procedure

7.3.11.1 General description

This operation is used to request the SSF to perform the call processing actions to route a call to a specific destination. To do so, the SSF may use destination information from the calling party (e.g. dialled digits) and existing call set-up information (e.g. route index to a list of trunk groups) depending on the information provided by the SCF.

7.3.11.1.1 Parameters

destinationRoutingAddress:: This parameter contains the called party number towards which the call is to be routed. The encoding of the parameter is defined in ETS 300 356-1 [8]. The "destinationRoutingAddress" may include the "correlationID" and "scfID" if used in the context of a hand-off procedure, but only if "correlationID" and "scfID" are not specified separately.
correlationID:: This parameter is used by the SCF to associate the "AssistRequestInstructions" operation from the assisting SSF with the "InitialDP" from the initiating SSF. The "correlationID" is used in the context of a hand-off procedure and only if the correlation id is not embedded in the "destinationRoutingAddress". The network operators has to decide about the actual mapping of this parameter on the used signalling system.
scfID:: This parameter indicates the SCF identifier and enables the assisting SSF to identify which SCF the "destinationRoutingAddress" should be sent to. The scfID is used in the context of a hand-off procedure and only if the SCF id is not embedded in the "destinationRoutingAddress". The network operators has to decide about the actual mapping of this parameter on the used signalling system.
cutAndPaste: This parameter is used by the SCF to instruct the SSF to delete (cut) a specified number of leading digits that it has received from the calling party and to paste the remaining dialled digits on to the end of the digits supplied by the SCF in the "destinationRoutingAddress".
callingPartyNumber: This parameter is used to provide an alternative to the "callingPartyNumber" supplied by the network. It may be used for applications such as UPT, where only the SCF can verify the identity of the calling party. The use of this parameter is operator dependent.
routeList:: This parameter is used to select the outgoing trunk group used for routing the call. A sequence of routes is provided to allow flexible routing for applications such as VPN without increasing the number of queries required for such applications.
callingPartysCategory:: This parameter indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). The use of this parameter in the context of "Connect" operation is to be specified by the network operator.
originalCalledPartyID:: This parameter carries the dialled digits if the call has met call forwarding on route to the SSP or is forwarded by the SCP. The use of this parameter in the context of "Connect" operation is to be specified by the network operator.
redirectingPartyID:: This parameter indicates the directory number the call was redirected from. The use of this parameter in the context of "Connect" operation is to be specified by the network operator.
redirectionInformation:: This parameter contains forwarding related information, such as redirecting counter. The use of this parameter in the context of "Connect" operation is to be specified by the network operator.
alertingPattern:: This parameter indicates a specific pattern that is used to alert a subscriber (e.g. distinctive ringing, tones, etc.). It only applies if the network signalling support this parameter or if SSF is the terminating local exchange for the subscriber.
serviceInteractionIndicators:: This parameter contain indicators sent from the SCP to the SSP for control of the network based services at the originating exchange and the destination exchange.

7.3.11.2 Invoking entity (SCF)

7.3.11.2.1 Normal procedure

SCF preconditions:

(1)A control relationship exists between the SCF and the SSF.
(2)An SLPI has determined that a "Connect" has to be sent by the SCF.

SCF postcondition:

(1)SLPI execution may continue.

In the SCSM FSM state "Preparing SSF Instructions", this operation is invoked by the SCF if the SL results in the request to the SSF to route a call to a specific destination. If no event monitoring has been requested and no reports (CallInformationReport and ApplyChargingReport) have been requested in a previously sent operation, a SCSM FSM transition to state "Idle" occurs. Otherwise, if event monitoring has been requested or any report (CallInformationReport and ApplyChargingReport) has been requested, the SCSM FSM transitions to state "Waiting for Notification or Report". When the "Connect" operation is used in the context of a hand-off procedure, the SCSM FSM transitions to state "Idle". However, in this case, the SCF shall maintain sufficient information in order to correlate the subsequent "AssistRequestInstructions" operation (from the assisting SSF or SRF) to the existing SLPI.

7.3.11.2.2 Error handling

If reject or error messages are received, then the SCSM informs the SLPI and remains in the state "Preparing SSF Instructions".
Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.11.3 Responding entity (SSF)

7.3.11.3.1 Normal procedure

SSF preconditions:

(1)Call origination attempt has been initiated.
(2)Basic call processing has been suspended at a DP.
(3)The SSF waits for instructions.

SSF postcondition:

(1)The SSF performs the call processing actions to route the call to the specified destination.
(2)In the O-BCSM, when only address information is included in the Connect operation, call processing resumes at PIC 3.
(3)In the O-BCSM, when address information and routing information is included in the Connect operation, call processing resumes at PIC 4.

On receipt of this operation in the SSF FSM state "Waiting for Instructions", the SSP performs the following actions:

the SSF cancels TSSF;
if "cutAndPaste" is present, then the SSF deletes ("cut") from the dialled IN number the indicated number of digits and pastes the remaining dialled digits at the end of the "destinationRoutingAddress" parameter delivered by the SCF. The resulting directory number is used for routing to complete the related call;
if "cutAndPaste" is not present, then the "destinationRoutingAddress" parameter delivered by the SCF is used for routing to complete the related call. Note that in the case of hand-off, this results in routing to an assisting SSP or IP;
if the "callingPartyNumber" is supplied, this value may be used for all subsequent SSF processing;
if no EDPs have been armed and no CallInformationReport or ApplyChargingReport has been requested, the FSM goes to state "Idle" (e9). Otherwise, the FSM goes to state "Monitoring" (e11). No implicit activation or deactivation of DPs occurs. Statistic counter(s) are not affected.

Connect completes when the INAP processing of the operation is complete and before the SSP starts the processing necessary to select a circuit.
Therefore in order to detect route select failure after a "Connect" it is necessary to explicitly arm the "Route Select Failure" EDP before sending the "Connect" (although they may be in the same message).

7.3.11.3.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.12 ConnectToResource procedure

7.3.12.1 General description

This operation is used to connect a call from the SSF to a specialised resource. After successful connection to the SRF, the interaction with the caller can take place. The SSF relays all operations for the SRF and all responses from the SRF.

7.3.12.1.1 Parameters

resourceAddress:

This parameter identifies the physical location of the SRF.

iPRoutingAddress:: This parameter indicates the routing address to set up a connection towards the SRF.
none:: This parameter indicates that the call party is to be connected to a predefined SRF.

serviceInteractionIndicators:

This parameter contain indicators sent from the SCP to the SSP for control of the network based services at the originating exchange and the destination exchange.

7.3.12.2 Invoking entity (SCF)

7.3.12.2.1 Normal procedure

SCF preconditions:

(1)A control relationship exists between the SCF and the SSF.
(2)The SLPI has determined that additional information from the call party is needed.
(3)The call party is not connected to any other party.
(4)The SCSM FSM is in the state "Routing to Resource", substate "Determine Mode".
(5)The SLPI has determined that the SRF can be accessed from the SSF.

SCF postconditions:

(1)The SCSM sends out a "PlayAnnouncement" or "PromptAndCollectUserInformation" operation accompanying the "ConnectToResource".
(2)The SCSM FSM moves to the state "User Interaction".

7.3.12.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.12.3 Responding entity (SSF)

7.3.12.3.1 Normal procedure

SSF preconditions:

(1)Basic call processing has been suspended at a DP and a control relationship has been established.
(2)The SSF FSM is in the state "Waiting for Instructions".

SSF postconditions:

(1)The call is switched to the SRF.
(2)A control relationship to the SRF is established.
(3)The SSF FSM moves to the state "Waiting for End of User Interaction". TSSF is set.

NOTE:	The successful connection to the SRF causes a state transition in the SRF FSM from "Idle" to "Connected".

7.3.12.3.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.13 Continue procedure

7.3.13.1 General description

This operation is used to request the SSF to proceed with call processing at the DP at which it previously suspended call processing to await SCF instructions. The SSF continues call processing without substituting new data from the SCF.

7.3.13.1.1 Parameters

None.

7.3.13.2 Invoking entity (SCF)

7.3.13.2.1 Normal procedure

SCF precondition:

(1)SCSM is in the state "Preparing SSF instructions".

SCF postcondition:

(1)SCSM is in the state "Waiting for Notification of Report", in case monitoring was required, or in the state "Idle", in case no monitoring was required.

The SCSM is in state "Preparing SSF instructions". The "Continue" operation is invoked by a SLPI. This causes a SCSM transition to state "Idle" if no subsequent monitoring is required. However, if monitoring is required, like in the case of armed EDPs or outstanding report requests, the SCSM transitions to state "Waiting for Notification of Report".

7.3.13.2.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

7.3.13.3 Responding entity (SSF)

7.3.13.3.1 Normal procedure

SSF preconditions

(1)BCSM: Basic call processing has been suspended at any DP.
(2)SSF FSM is in the state "Waiting for Instructions".

SSF postconditions

(1)BCSM: Basic call processing continues.
(2)SSF FSM is in the state "Monitoring", because at least one EDP was armed, or a "CallInformationReport" or "ApplyChargingReport" was requested, or
SSF FSM is in the state "Idle", because no EDPs were armed and neither the "CallInformationReport" nor the "ApplyChargingReport" was requested.

The SSF FSM is in state "Waiting for instructions". The SSME receives the "Continue" operation and relays it to the appropriate SSF FSM. The SSF FSM transitions to state "Idle" in case no EDPs are armed and no outstanding report requests are present. The SSF FSM transits to state "Monitoring" if at least one EDP is armed, or if there is at least one outstanding report request. Basic call processing is resumed.

7.3.13.3.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

7.3.14 DisconnectForwardConnection procedure

7.3.14.1 General description

This operation is used in the following two cases:

1)To clear a connection to a SRF
This operation is used to explicitly disconnect a connection to a resource (SRF) established previously with a "ConnectToResource" operation. It is used for a forward disconnection from the SSF. An alternative solution is the backward disconnect from the SRF, controlled by the "DisconnectFromIPForbidden" parameter in the "PlayAnnouncement" and "PromptAndCollectUserInformation" operations.

2)To clear a connection to an assisting SSF
This operation is sent to the non-assisting SSF of a pair of SSFs involved in an assist procedure. It is used to disconnect the temporary connection between the initiating SSF and the assisting SSF, and the assisting SSF and its associated SRF.

7.3.14.1.1 Parameters

None.

7.3.14.2 Invoking entity (SCF)

7.3.14.2.1 Normal procedure

SCF preconditions:

(1)A control relationship exists between the SCF and the SSF.
(2)An assist- or a relay procedure is in progress.
(3)An SLPI has determined that a "DisconnectForwardConnection" operation has to be sent by the SCF.

SCF postcondition:

(1)SLPI execution may continue.

The "DisconnectForwardConnection" operation is used to instruct the SSF to disconnect the concerned forward connection to the assisting SSF or the PE containing the SRF.
In the SCSM FSM state "User Interaction", substate "Waiting for Response from the SRF", this operation is invoked by the SCF when the SL determines that user interaction is finished and requests the SSF to disconnect the temporary connection to the assisting SSF or the SRF. The SCSM FSM then transitions to state "Preparing SSF Instructions".
The "DisconnectForwardConnection" operation contains no parameter since there may be only one SRF connection to one call.

7.3.14.2.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

7.3.14.3 Responding entity (SSF)

7.3.14.3.1 Normal procedure

SSF preconditions:

(1)Call origination attempt has been initiated.
(2)Basic call processing has been suspended at a DP.
(3)The initiating SSF is in the state "Waiting for End of User Interaction" or "Waiting for End of Temporary Connection".

SSF postconditions:

(1)The connection to the SRF or assisting SSF is released.
(2)The SSF is waiting for instructions.

The receipt of "DisconnectForwardConnection" results in disconnecting the assisting SSF or the PE containing the SRF from the concerned call. It does not release the connection from the SSF back to the end user.
This operation is accepted in the SSF FSM states "Waiting for End of Temporary Connection" or "Waiting for End of User Interaction". On receipt of this operation in these states, the SSP shall perform the following actions:

the initiating SSF releases the connection to the assisting SSF or the relay SRF;
the SSF resets TSSF;
the SSF FSM goes to state "Waiting for Instructions" (e8). The "DisconnectForwardConnection" operation contains no parameters.

NOTE:	The successful disconnection to the SRF causes a state transition in the SRF FSM to "Idle". A current order ("PlayAnnouncement" or "PromptAndCollectUserInformation") is cancelled and any queued order is discarded.

7.3.14.3.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

7.3.15 EstablishTemporaryConnection procedure

7.3.15.1 General description

This operation is used to create a connection between an initiating SSF and an assisting SSF as part of a service assist procedure. It can also be used to create a connection between a SSF and a SRF, for the case where the SRF exists in a separately addressable PE.

7.3.15.1.1 Parameters

assistingSSPIPRoutingAddress:: This parameter indicates the destination address of the SRF for assist procedure. The "assistingSSPIPRoutingAddress" may contain embedded within it, a "correlationID" and "scfID", but only if "correlationID" and "scfID" are not specified separately.
correlationID:: This parameter is used by the SCF to associate the "AssistRequestInstructions" from the assisting SSF (or the SRF) with the "InitialDP" from the initiating SSF. The "correlationID" is used only if the correlation id is not embedded in the "assistingSSPIPRoutingAddress". The network operators has to decide about the actual mapping of this parameter on the used signalling system.
scfID:: This parameter indicates the SCF identifier and enables the assisting SSF to identify which SCF the "AssistRequestInstructions" should be sent to. The "scfID" is used only if the SCF id is not embedded in the "assistingSSPIPRoutingAddress". The network operators has to decide about the actual mapping of this parameter on the used signalling system.
serviceInteractionIndicators:: This parameter contain indicators sent from the SCP to the SSP for control of the network based services at the originating exchange and the destination exchange.

7.3.15.2 Invoking entity (SCF)

7.3.15.2.1 Normal procedure

SCF preconditions:

(1)A control relationship exists between the SCF and the SSF.
(2)The SL has determined that a connection is needed between the SSF and SRF or between the SSF and an assisting SSF.
(3)The call party is not connected to any other party.

SCF postcondition:

(1)The SCF is "Waiting for Assist Request Instructions".

In the SCSM FSM state "Routing to Resource", this operation is invoked by the SCF when the SL determines that an assisting SSF or a Direct SCF-SRF relation is needed. The SCSM FSM then transitions to state "Waiting for Assisting Requested Instructions".

7.3.15.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.15.3 Responding entity (SSF)

7.3.15.3.1 Normal procedure

SSF preconditions:

(1)Call origination attempt has been initiated.
(2)Basic call processing has been suspended at a DP.
(3)The SSF waits for instructions.
(4)The SSF is not an assisting SSF.

SSF postconditions:

(1)The SSF performs the call processing actions to route the call to the assisting SSF.
(2)The SSF waits for end of temporary connection.

On receipt of this operation in the SSF FSM state "Waiting for Instructions", the SSP has to perform the following actions:

reset the TSSF to TETC;
route the call to assisting SSF using "assistingSSPIPRoutingAddress";
the SSF FSM goes to state "Waiting for End of Temporary Connection" (e7).

7.3.15.3.2 Error handling

Until the connection setup has been accepted (refer to Q.71) by the assisting SSF/SRF, all received failure indications from the network on the ETC establishment shall be reported to the SCF as ETC error ETCFailed (e.g., busy, congestion). Note that the operation timer for ETC shall be longer then the maximum allowed time for the signalling procedures to accept the connection.
Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.16 EventNotificationCharging procedure

7.3.16.1 General description

This operation is used by the SSF to report to the SCF the occurrence of a specific charging event type as requested by the SCF using the "RequestNotificationChargingEvent" operation. The operation supports the options to cope with the interactions concerning the charging (refer to Annex B, Clause B.4).
As several charging events may occur during a connection configuration a possibility exists for the ENC operation to be invoked on multiple occasions. For each connection configuration ENC may be used several times.

7.3.16.1.1 Parameters

eventTypeCharging:: This parameter indicates the charging event type which has occurred. Its content is network operator specific, which may be "charge pulses" or "charge messages".
eventSpecificInformationCharging:: This parameter contains charging related information specific to the event. Its content is network operator specific.
legID:: This parameter indicates the leg id on which the charging event type applies.
monitorMode:: This parameter indicates how the charging event is reported. When the "monitorMode" is "interrupted", the event is reported as a request, if the "monitorMode" is "notifyAndContinue", the event is reported as a notification. The "monitorMode" "transparent" is not applicable for the EventNotificationCharging operation.

7.3.16.2 Invoking entity (SSF)

7.3.16.2.1 Normal procedure

SSF preconditions:

(1)A control relationship exist between the SCF and the SSF.
(2)A charging event has been detected that is requested by the SCF.

SSF postcondition:

(1)No FSM state transition.

The SSF FSM is in any state except "idle". This operation is invoked if a charging event has been detected that is requested by the SCF. The detected charging event can be caused by: a) another SLPI or b) another exchange. Irrespective of by what the charging event is caused the SSF performs one of the following actions on occurrence of the charging event (according to the corresponding monitorMode):

Interrupted:
Notify the SCF of the charging event using "EventNotificationCharging" operation, do not process the event, but discard it. However, call and existing charging processing will not be suspended in the SSF.

NotifyAndContinue:
Notify the SCF of the charging event using "EventNotificationCharging", and continue processing the event or signal.

7.3.16.2.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

7.3.16.3 Responding entity (SCF)

7.3.16.3.1 Normal procedure

SCF precondition:

(1)A "RequestNotificationChargingEvent" has been sent at the request of a SLPI and SLPI is expecting an "EventNotificationCharging" from the SSF.

SCF postcondition:

(1)No FSM state transition.

On receipt of this operation the SLPI which is expecting this notification can continue. If the corresponding monitor mode was set by the SLPI to Interrupted, the SLPI prepares instructions for the SSF if necessary

7.3.16.3.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

7.3.17 EventReportBCSM procedure

7.3.17.1 General description

This operation is used to notify the SCF of a call related event previously requested by the SCF in an "RequestReportBCSMEvent" operation. The monitoring of more than one event could be requested with a "RequestReportBCSMEvent" operation, but each of these requested events is reported in a separate "EventReportBCSM" operation.

7.3.17.1.1 Parameters

eventTypeBCSM:

This parameter specifies the type of event that is reported.

eventSpecificInformationBCSM:

This parameter indicates the call related information specific to the event.

For "CollectedInfo">CollectedInfo" it will contain the "calledPartyNumber".
For "AnalyzedInformation" it will contain the "calledPartyNumber".
For "RouteSelectFailure" it will contain the "FailureCause", if available.
For O- or T-CalledPartyBusy it will contain the "BusyCause", if available.
For O- or T-NoAnswer it will be empty.
For O- or T-Answer it will be empty.
For O- or T-MidCall it will be empty.
For O- or T-Disconnect it will contain the "releaseCause", if available.

legID:

This parameter indicates the party in the call for which the event is reported. SSF will use the option "receivingSideID" only.

receivingSideID:: The following values for "legID" are assumed:
"legID" = 1 indicates the party that was present at the moment of the "InitialDP" (in case of a midcall trigger, the party causing the trigger), or the party that was created with an "InitiateCallAttempt" operation.
"legID" = 2 indicates the party that was created with a "Connect" operation, or in case of a midcall trigger, the party not causing the trigger.

If not included, the following defaults are assumed:; legID = 1 for the events CollectedInfo">CollectedInfo, AnalyzedInformation, O-Abandon and T-Abandon,
legID = 2 for the events RouteSelectFailure, O-CalledPartyBusy, O-NoAnswer, O-Answer, T-CalledPartyBusy, T-NoAnswer and T-Answer.
The "legID" parameter shall always be included for the events O-MidCall, O-Disconnect, T-MidCall and T-Disconnect.

miscCallInfo:

This parameter indicates DP related information.

messageType:: This parameter indicates whether the message is a request, i.e. resulting from a "RequestReportBCSMEvent" with monitorMode = interrupted, or a notification, i.e. resulting from a "RequestReportBCSMEvent" with "monitorMode" = "notifyAndContinue".

7.3.17.2 Invoking entity (SSF)

7.3.17.2.1 Normal procedure

SSF preconditions:

(1)The SSF FSM shall be in the state "Monitoring", or
the SSF FSM may be in state "Waiting for Instructions" if the Disconnect DP is armed and encountered, or
the SSF FSM may be in any state if the Abandon DP is armed and encountered.
(2)The BCSM proceeds to an EDP that is armed.

SSF postconditions:

(1)The SSF FSM stays in the state "Monitoring" if the message type was notification and there are still EDPs armed or a "CallInformationReport" or "ApplyChargingReport" requested.
(2)The SSF FSM moves to the state "idle" if the message type was notification and there are no more EDPs armed, no "CallInformationReport" or "ApplyChargingReport" are requested.
(3)The SSF FSM moves to the state "Waiting for Instructions" if the message type was request. Call processing is interrupted.

For certain service features it is necessary that the same O-BCSM instance is reused. Examples are follow-on calls.
The decision to reuse the same O-BCSM instance can only be taken by the SCF after certain armed EDP-Rs are reported.
The considered EDP-Rs are:

RouteSelectFailure;
O-CalledPartyBusy;
O-NoAnswer;
O-Disconnect.

If a EDP-R is met that causes the release of the related leg all EDPs related to that leg are disarmed and the event is reported via "EventReportBCSM". To allow the reuse of the same O-BCSM instance the BCSM has to store all call related signalling parameters (e.g. "callingPartyNumber", "callingPartysCategory") until the BCSM instance is released.
In the case the respective EDP-R is met (see list above with "O-Disconnect" only for legID = 2), the A-leg will be held, the B-leg will be released and the SCF is informed via "EventReportBCSM".
If the A-party disconnects the call is released whether or not a DP was armed.

7.3.17.2.2 Error handling

In case the message type is request, on expiration of TSSF before receiving any operation, the SSF aborts the interaction with the SCF and instructs the CCF to route the call if necessary, e.g. to a final announcement.
Operation related error handling is not applicable, due to class 4 operation.

7.3.17.3 Responding entity (SCF)

7.3.17.3.1 Normal procedure

SCF preconditions:

(1)A control relationship exists between the SSF and the SCF.
(2)The SCSM FSM is in the state "Preparing SSF Instructions", substate "Waiting for Notification or Request".

SCF postconditions:

(1)The SCSM FSM stays in the substate "Waiting for Notification or Request" if the message type was notification and there are still EDPs armed or a "CallInformationReport" or "ApplyChargingReport" requested, or
The SCSM FSM moves to the state "Idle" if the message type was notification and there are no more EDPs armed, no "CallInformationReport" or "ApplyChargingReport" are requested, or
The SCSM FSM moves to the state "Preparing SSF Instructions" if the message type was request.
(2)The event is reported to a SLPI, based on the dialogue ID. The SCF will prepare SSF or SRF instructions in accordance with the SLPI.

7.3.17.3.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

7.3.18 FurnishChargingInformation procedure

7.3.18.1 General description

This operation is used to request the SSF to generate, register a call record or to include some information in the default call record. The registered call record is intended for off-line charging of the call. A possibility exist for the FCI operation to be invoked on multiple occasions. FCI could be applied at the beginning of the call in order to request to start call record generation. In addition FCI can also be applied at the end of the call or connection configuration (e.g., for follow-on calls). In this case, FCI is used to include charge related information into the call record which was started at the beginning of the call. When additional FCIs are used it is recommended to arm an EDP-R (indicating the end of call or connection configuration) to be able to apply FCI before the termination of the call record generation. The charging scenarios supported by this operation are: scenarios 2.2, 2.3 and 2.4 (refer to Annex B)

7.3.18.1.1 Parameters

FCIBillingChargingCharacteristics:

This parameter indicates billing and/or charging characteristics. Its content is network operator specific. Depending on the applied charging scenario the following information elements can be included (refer to Annex B):

complete charging record (scenario 2.2);
charge party (scenario 2.3);
charge level (scenario 2.3);
charge items (scenario 2.3);
correlationID (scenario 2.4).

7.3.18.2 Invoking entity (SCF)

7.3.18.2.1 Normal procedure

SCF preconditions:

(1)A control relationship exist between the SCF and the SSF.
(2)An SLPI has determined that a "FurnishChargingInformation" has to be sent by the SCF.

SCF postconditions:

(1)No FSM state transition.
(2)SLPI execution may continue.

The SCSM FSM is in state "Preparing SSF instruction" or is in state "Queuing FSM". This operation is invoked by the SCF if a SLPI results in the request of creating a call record to the SSF or to include some billing or charging information into the default call record. In the case of call queuing, this operation may contain information pertaining to the initiation of queuing or the call queuing time duration for call logging purpose. This causes no SCSM FSM state transition.

7.3.18.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.18.3 Responding entity (SSF)

7.3.18.3.1 Normal procedure

SSF preconditions:

(1)SSF FSM: State c, "Waiting for Instructions" or
SSF FSM State d, "Waiting for End of User Interaction" or
SSF FSM State e, "Waiting for End of Temporary Connection" or
Assisting/hand-off SSF FSM State b, "Waiting for Instructions".

SSF postcondition:

(1)No FSM state transition.

On receipt of this operation the SSF performs actions to create the call record according the off-line charging scenario which is applicable using the information elements included in the operation:

registers the complete call record included in the operation;
generates and registers a call record according the information (charge party, charge level, charge items);
include the information received "correlationID" in the default call record which is generated and, registered by default at the SSF.

By means of a parameter at the "FurnishChargingInformation" operation the SCF can initiate the pulse metering function of the SSF.
In that case the SSF shall generate meter pulses according to the applicable charging level, account and record them.
The SSF records charge related data, e.g. the call duration, begin time stamp or end time stamp. Additionally, the SSF records further data if required.
The charging level can be determined by

a)	the SCF; or

b)	the SSF; or

c)	a succeeding exchange; or

d)	the post processing function.

If case a) applies, the charging level is included in the "FurnishChargingInformation" operation.
If case b) applies, the SSF shall determine the charging level based on the corresponding parameters contained in the operation.
If case c) applies, either the "FurnishChargingInformation" operation contains the corresponding parameters indicating that the charging level shall be determined in a succeeding exchange or the SSF detects during the determination of the charging level based on the provided parameters that the charging level shall be determined in a succeeding exchange.
The SSF can either account received pulses or convert any charging messages received from the B-side to pulses. In both cases, the accumulated pulses are included when the IN call record is generated or ignored.

7.3.18.3.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.19 InitialDP procedure

7.3.19.1 General description

This operation is sent by the SSF after detection of a TDP-R in the BCSM, to request the SCF for instructions to complete the call.

7.3.19.1.1 Parameters

serviceKey: This parameter identifies for the SCF unambiguously the requested IN service. It is used to address the correct application/SLP within the SCF (not for SCP addressing).

calledPartyNumber:

This parameter contains the number used to identify the called party in the forward direction, e.g. the Called party number of ISUP (see ETS 300 356-1 [8]).

callingPartyNumber:

This parameter carries the calling party number to identify the calling party or the origin of the call. The encoding of the parameter is defined in ETS 300 356-1 [8].

callingPartysCategory:

Indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber).

originalCalledPartyID:

This parameter carries the dialled digits if the call has met call forwarding on the route to the SSP.

locationNumber:

This parameter is used to convey the geographical area address for mobility services. It is used when "callingPartyNumber" does not contain any information about the geographical location of the calling party (e.g., origin dependent routing when the calling party is a mobile subscriber).

forwardCallIndicators:

This parameter indicates if the call shall be treated as a national or international call. It also indicates the signalling capabilities of the network access, preceding network connection and the preferred signalling capabilities of the succeeding network connection. The network access capabilities do not indicate the terminal type. For example, an ISPBX will have an ISDN type of access, but the end user terminal behind the ISPBX may be ISDN or non-ISDN.

bearerCapability:

This parameter indicates the type of the bearer capability connection to the user:

bearerCap:: This parameter contains the value of the DSS1 Bearer Capability parameter in case the SSF is at local exchange level or the value of the ISUP User Service Information parameter in case the SSF is at transit exchange level.

The parameter "bearerCapability" shall only be included in the "InitialDP" operation in case the DSS1 Bearer Capability parameter or the ISUP User Service Information parameter is available at the SSP.

If two values for bearer capability are available at the SSF or if User Service Information and User Service Information Prime are available at the SSF the "bearerCap" shall contain the value of the preferred bearer capability respectively the value of the User Service Information Prime parameter.

eventTypeBCSM:

This parameter indicates the armed BCSM DP event, resulting in the "InitialDP" operation.

redirectingPartyID:

This parameter indicates the directory number the call was redirected from.

redirectionInformation:

It contains forwarding related information, such as redirecting counter.

iPAvailable:

Indicates whether or not an IP is attached and available (i.e., not exhausted) at the SSP.

iPSSPCapabilities:

Indicates which SRF resource are supported within the SSP an attached and available.

cGEncountered:

This parameter indicates that the related call has passed call gapping.

additionalCallingPartyNumber:

The calling party number provided by the access signalling system of the calling user.

serviceInteractionIndicators:

This parameter contain indicators sent from the SSP to the SCP for control of the network based services at the originating exchange and the destination exchange.

highlayerCompatibility:

This parameter indicates the type of the high layer compatibility, which will be used to determine the ISDN-teleservice of a connected ISDN terminal. For encoding, DSS1 (see ETS 300 403-1 [7]) is used.

7.3.19.2 Invoking entity (SSF)

7.3.19.2.1 Normal procedure

SSF preconditions:
(1)Call origination attempt has been initiated.
(2)An event has been detected at a DP.
(3)Call gapping and SS No. 7 overload are not in effect for the call, and the call is not to be filtered.

SSF postcondition:

(1)A control relationship has been established and the SSF waits for instructions from the SCF.

Following a trigger detection related to an armed TDP-R in the BCSM caused by a call origination attempt, the SSF checks if call gapping, SS No. 7 overload or service filtering are not in effect for the related call segment.
If these conditions are met, then the "InitialDP" operation is invoked by the SSF. The address of the SCF the "InitialDP" operation has to be sent to is determined on the base of trigger related data. The SSF provide as many parameters as available.

NOTE:	This is for further study.

In some service-specific cases, some parameters shall be available (such as "callingPartyNumber" or "callingPartysCategory"). This shall be handled appropriately by the SSF in its trigger table (to know that such parameter are necessary for some triggering conditions) and in conducting the necessary action to get these parameters if they are not available (for instance, if MF signalling is used, it is possible to request the "callingPartysCategory" from a preceding exchange).
Otherwise, the SSF returns call control to the CCF.
A control relationship is established to the SCF. The SSF application timer TSSF is set when the SSF sends "InitialDP" for requesting instructions from the SCF. It is used to prevent from excessive call suspension time.

7.3.19.2.2 Error handling

If the destination SCF is not accessible then the SSF FSM instructs the CCF to route the call if necessary e.g., to a final announcement.
On expiration of TSSF before receiving any operation, the SSF aborts the interaction with the SCF and instructs the CCF to route the call if necessary e.g., to a final announcement.
If the calling party abandons after the sending of "InitialDP", then the SSF aborts the control relationship after the first answer message from the SCF has been received.
Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.19.3 Responding entity (SCF)

7.3.19.3.1 Normal procedure

SCF precondition:

None.

SCF postcondition:

(1)An SLPI has been invoked.

On receipt of "InitialDP" operation the SCSM moves from "Idle" to the state "Preparing SSF Instructions", a control relationship to the related SSF is created. A SLPI is invoked for processing the "InitialDP" operation based on the "serviceKey" parameter. By means of this control relationship, the SCF may influence the Basic Call Processing in accordance with the SL invoked.
The actions to be performed in the SLPI depend on the parameters conveyed via this operation and the SLPI, i.e. the requested IN service, itself.

7.3.19.3.2 Error handling

If the "InitialDP" operation is rejected then the SCSM remains in "Idle". The maintenance function is informed and no SLPI is invoked.
The following error cases are indicated to the SSF:

MissingCustomerRecord:: The SCF has not found the appropriate SL corresponding to the provided service key or the appropriate service subscriber related SL.

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.20 InitiateCallAttempt procedure

7.3.20.1 General description

This operation is used to request the SSF to create a new call to one call party using the address information provided by the SCF. An EDP-R shall be armed on answer and all the call failure events, in order to have the SCF treat this call appropriately when either of these events is encountered.

7.3.20.1.1 Parameters

destinationRoutingAddress:: This parameter contains the called party number towards which the call is to be routed. The encoding of the parameter is defined in ETS 300 356-1 [8].
callingPartyNumber This parameter identifies which number shall be regarded as the calling party for the created call. If this parameter is not sent by the SCF, the SSF may supply a network dependent default value.
alertingPattern:: This parameter indicates a specific pattern that is used to alert a subscriber (e.g. distinctive ringing, tones, etc.). It only applies if the network signalling support this parameter or if SSF is the terminating local exchange for the subscriber.
serviceInteractionIndicators:: This parameter contain indicators sent from the SCP to the SSP for control of the network based services at the originating exchange and the destination exchange.

7.3.20.2 Invoking entity (SCF)

7.3.20.2.1 Normal procedure

SCF preconditions:

(1)An SLPI has been invoked, no control relationship exists between SCF and SSF.
(2)An SLPI has determined that an "InitiateCallAttempt" operation should be sent to the SCF.
(3)The SCSM FSM is in state "Idle".

SCF postconditions:

(1)A control relationship is established between the SCF and SSF.
(2)The SCSM FSM is in state "Preparing SSF Instructions".
(3)SLPI execution continues.

The SCSM FSM moves to state "Preparing SSF Instructions" when the SL invokes this operation. In order to enable the establishment of a control relationship between the SCF and SSF and to allow the SCF to control the created call appropriately, the SLPI shall monitor for the BCSM event(s) which report the result of the created call setup. This includes DP3 or DP4, DP5, DP6 and DP7. Any other non-call-processing instructions may be sent as well. The "InitiateCallAttempt" operation creates a BCSM instance in the SSF but the SSF suspends the call processing of this BCSM. The SLPI shall send a "Continue" operation to request the SSF to route the call to the specified destination. The SCSM FSM shall proceed as specified at the procedure for the "Continue" operation.
The above described procedure shall be part of the establishment of the control relationship, i.e. operations up to and including the "Continue" operation shall be sent together in the same message to the SSF.
The SCF shall start a response Timer TSCF when the "InitiateCallAttempt" operation is sent. The response Timer shall supervise the confirmation of the dialogue from SSF, the value of TSCF shall be equal or less then the network no answer timer.

7.3.20.2.2 Error handling

On expiration of TSCF the SCF shall abort the dialogue, report the abort to the maintenance functions and inform the SLPI on the failure of dialogue establishment. The SCSM FSM moves to the Idle state.
Generic error handling for the operation related errors is described in subclause 7.2, the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.20.3 Responding entity (SSF)

7.3.20.3.1 Normal procedure

SSF precondition:

None.

SSF postconditions:

(1)A new originating BCSM has been created, call processing is suspended at DP1.
(2)The SSF FSM has moved from "Idle" state to state "Waiting for Instructions".

Upon reception of "InitiateCallAttempt", the SSF creates a new originating BCSM and suspends the call processing of this BCSM at DP1. All subsequent operations are treated according to their normal procedures.
The properties and capabilities, normally received from or associated to the calling party, required for the call setup shall have a network dependent default value. If a calling party number is supplied by the SCF, these properties may be dependent on the received calling party number

7.3.20.3.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2, the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.21 PlayAnnouncement procedure

7.3.21.1 General description

This operation is used for inband interaction with an analogue user or for interaction with an ISDN user.

7.3.21.1.1 Parameters

informationToSend:

This parameter indicates an announcement, a tone or display information to be sent to the end user by the SRF.

inbandInfo:: This parameter specifies the inband information to be sent.

messageID:

This parameter indicates the message(s) to be sent, this can be one of the following:

elementaryMessageID:: This parameter indicates a single announcement.
text:: This parameter indicates a text to be sent. The text shall be transformed to inband information (speech) by the SRF. The attributes of text may consist of items such as language.
elementaryMessageIDs:: This parameter specifies a sequence of announcements.
variableMessage:: This specifies an announcement with one or more variable parts.

numberOfRepetitions:

This parameter indicates the maximum number of times the message shall be sent to the end-user.

duration:

This parameter indicates the maximum time duration in seconds that the message shall be played/repeated. ZERO indicates endless repetition.

interval:

This parameter indicates the time interval in seconds between repetitions, i.e. the time between the end of the announcement and the start of the next repetition. This parameter can only be used when the number of repetitions is greater than one.

tone:

This parameter specifies a tone to be sent to the end-user.

toneID:: This parameter indicates the tone to be sent.
duration:: This parameter indicates the time duration in seconds of the tone to be sent. ZERO indicates infinite duration.

displayInformation:

This parameter indicates a text string to be sent to the end-user. This information can not be received by a PSTN end-user.

NOTE:	As the current signalling systems (DSS1/ISUP) do not provide an indication whether or not information can be displayed by the user's terminal, in case of user interaction with an ISDN user two consecutive "PlayAnnouncement" operations are sent. The first contains the display information, the second contains the inband information to be sent to the user. Since the execution of the display information by the SRF should take a limited amount of time, the inband information will be immediately sent by the SRF to the user, in sequence with the display information.

disconnectFromIPForbidden:: This parameter indicates whether or not the SRF should be disconnected from the user when all information has been sent.
requestAnnouncementComplete:: This parameter indicates whether or not a "SpecializedResourceReport" shall be sent to the SCF when all information has been sent.

7.3.21.2 Invoking entity (SCF)

7.3.21.2.1 Normal procedure

SCF preconditions:

(1)The SLPI detects that information should be sent to the user.
(2)A connection between the user and a SRF has been established.
(3)The SCSM FSM is in the state "User interaction", substate "Waiting for response from the SRF".

SCF postconditions:

(1)If "RequestAnnouncementComplete" was set TRUE, the SCSM will stay in substate "Waiting for Response from the SRF" and wait for the "SpecializedResourceReport".
(2)If "RequestAnnouncementComplete" was set FALSE and more information needs to be sent ("DisconnectFromIPForbidden" was set to TRUE), the SCSM will stay in substate "Waiting for Response from the SRF".
(3)If "RequestAnnouncementComplete" was set FALSE and no more information needs to be sent ("DisconnectFromIPForbidden" was set to FALSE), the SCSM will move to the state "Preparing SSF Instructions".

7.3.21.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.21.3 Responding entity (SRF)

7.3.21.3.1 Normal procedure

SRF precondition:

(1)The SRSM FSM is in the state "Connected", or
in the state "User Interaction" if the SRF received previously an operation from the SCF.

SRF postconditions:

(1)The SRF sends the information to the user as indicated by "informationToSend".
(2)The SRSM FSM moves to the state "User Interaction", or
remains in the same state.
(3)If all information has been sent and "RequestAnnouncementComplete" was set TRUE, the SRSM sends a "SpecializedResourceReport" operation to the SCF.
(4)If all information has been sent and "disconnectFromIPForbidden" was set FALSE, the SRSM disconnects the SRF from the user.

The announcement send to the end-user is ended in the following conditions:

if neither "duration" or "numberOfRepetitions" is specified, then the network specific announcement ending conditions shall apply; or
if "numberOfRepetitions" is specified, when all repetitions have been sent; or
if "duration" is specified, when the duration has expired. The announcement is repeated until this condition is met; or
if "duration" and "numberOfRepetitions" is specified, when one of both conditions is satisfied (whatever comes first).

7.3.21.3.2 Error handling

If a Cancel operation is received before or during the processing of the operation then the operation is immediately cancelled and the error "Canceled" is reported to the invoking entity.
Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.22 PromptAndCollectUserInformation procedure

7.3.22.1 General description

This operation is used to interact with a call party in order to collect information.

7.3.22.1.1 Parameters

collectedInfo collectedDigits minimumNbOfDigits If this parameter is missing, the default value is defined to be 1. The "minimumNbOfDigits" specifies the minimum number of valid digits to be collected. maximumNbOfDigits This parameter should always be present and specifies the maximum number of valid digits to be collected. The following applies: "maximumNbOfDigits" "minimumNbOfDigits". endOfReplyDigit This parameter indicates the digit used to signal the end of input. In case the "maximumNbOfDigits" = "minimumNbOfDigits", the "endOfReplyDigit" (could be present but) has no further meaning. This parameter can be one or two digits. In case the "maximumNbOfDigits" > "minimumNbOfDigits" the following applies: If "endOfReplyDigit" is not present, the end of input is indicated: when the inter-digit timer expires, or when the number of valid digits received equals the "maximumNbOfDigits". If "endOfReplyDigit" is present, the end of input is indicated: when the inter-digit timer expires, or when the end of reply digit is received, or when the number of valid digits received equals the "maximumNbOfDigits". When the end of input is attained, the collected digits are send from SRF to the SCF. In the case the number of valid digits received is less than the "minimumNbOfDigits" when the inter-digit timer expires or when the end of reply digit is received, the input is specified as being erroneous. cancelDigit If this parameter is present, the cancel digit can be entered by the user to request a possible retry. All digits already received by the SRF are discarded and the same "PromptAndCollectUserInformation" procedure is performed again, thus e.g. the same announcement to request user information is given to the user and information is collected. This parameter can be one or two digits. If this parameter is not present, the user is not able to request a possible retry. startDigit If this parameter is present, the start digit indicates the start of the valid digits to be collected. The digits that are received by the SRF before this start digit is received, are discarded and are not considered to be valid. This parameter can be one or two digits. If this parameter is not present, all received digits are considered to be valid. firstDigitTimeOut If this parameter is present, the first digit should be received by the SRF before the first-digit timer expiration. In case the first digit is not received before first-digit timer expiration, the input is regarded to be erroneous. After receipt of the first valid or invalid input digit, the corresponding first-digit timer is stopped. If this parameter is not present, then the SRF uses a default value for the first-digit timer in which the first valid or invalid input digit is received. If "startDigit" is present, the first-digit timer is stopped after the start digit is received. interDigitTimeOut If this parameter is present any subsequent valid or invalid digit, should be received by the SRF before the inter-digit timer expires. As result the inter-digit timer is reset and restarted. In case a subsequent valid or invalid digit is not received before the inter-digit timer expires and the number of received valid digits is less than the "minimumNbOfDigits", the input is regarded to be unsuccessful. In case a subsequent valid or invalid digit is not received before the inter-digit timer expires and the number of received valid digits is greater than the "minimumNbOfDigits", and less than or equal to the "maximumNbOfDigits", the input is regarded to be successful. If the "interDigitTimeOut" is not present, then the SRF uses a default value for the inter-digit time. errorTreatment This optional parameter defines what specific action should be taken by the SRF in the event of error conditions occurring. The default value is stdErrorAndInfo. interruptableAnnInd This parameter is optional, where the default value is specified being TRUE. If this parameter is TRUE, the announcement is interrupted after the first valid or invalid digit is received by the SRF. If the announcement is interrupted, a possible start-digit timer will not apply anymore. However, if the announcement has not been interrupted, a possible start-digit timer is started after the announcement has been finished. If this parameter is present and explicitly set to FALSE, the announcement will not be interrupted after the first digit is received by the SRF. The received digits during the announcement are discarded and considered to be invalid. All other specified parameters ("minimumNbOfDigits", "maximumNbOfDigits", "endOfReplyDigit", etc.) do not apply before the announcement has been finished. The possible start-digit timer is started after the announcement has been finished. voiceInformation This parameter is optional, where the default value is specified being FALSE. If the "voiceInformation" parameter is FALSE, all valid or invalid digits are entered by DTMF. If this parameter is present and explicitly set to TRUE, calling user is required to provide all valid or invalid information by speech. The SRF will perform voice recognition and translation of the provided information into digits. A possible end of reply digit will also have to be provided by speech. voiceBack This parameter is optional, where the default value is specified being FALSE. If the "voiceBack" parameter is FALSE, no voice back information is given by the SRF. If this parameter is present and explicitly set to TRUE, the valid input digits received by the SRF will be announced back to the calling user immediately after the end of input is received. The invalid input digits will not be announced back to the calling user. A possible end of reply digit is not voiced back.

disconnectFromIPForbidden:

This parameter indicates whether the SRF should initiate disconnection to the SSF/CCF after the interaction has been completed. If the parameter is not present or set to TRUE, the SRF shall not initiate disconnection.

informationToSend:

This parameter indicates an announcement, a tone or display information to be sent to the end user by the SRF.

inbandInfo:: This parameter specifies the inband information to be sent.

messageID:: This parameter indicates the message(s) to be sent, this can be one of the following:

elementaryMessageID:: This parameter indicates a single announcement.
text:: This parameter indicates a text to be sent. The text shall be transformed to inband information (speech) by the SRF. The attributes of text may consist of items such as language.

numberOfRepetitions:: This parameter indicates the maximum number of times the message shall be sent to the end-user.

duration:: This parameter indicates the maximum time duration in seconds that the message shall be played/repeated. ZERO indicates endless repetition. When not included, a network specific duration is assumed.
interval:: This parameter indicates the time interval in seconds between repetitions, i.e. the time between the end of the announcement and the start of the next repetition. This parameter can only be used when the number of repetitions is greater than one.

tone:: This parameter specifies a tone to be sent to the end-user.

toneID:: This parameter indicates the tone to be sent.
duration:: This parameter indicates the time duration in seconds of the tone to be sent. ZERO indicates infinite duration.

displayInformation:: This parameter indicates a text string to be sent to the end-user. This information can not be received by a PSTN end-user.

NOTE:	As the current signalling systems (DSS1/ISUP) do not provide an indication whether or not information can be displayed by the user's terminal, in case of user interaction with an ISDN user, the "displayInformation" parameter is not used in the "PromptAndCollectUserInformation" operation. Instead a "PlayAnnouncement" operation containing the "displayInformation" parameter followed by a "PromptAndCollectUserInformation" operation containing inband information are sent to the user. Since the execution of the displayed information by the SRF should take a limited amount of time, the inband information will be immediately sent by the SRF to the user, in sequence with the displayed information.

digitsResponse:: This parameter contains the information collected from the end-user.

7.3.22.2 Invoking entity (SCF)

7.3.22.2.1 Normal procedure

SCF preconditions:

(1)The SLPI detects that information should be collected from the end-user.
(2)A connection between the end-user and a SRF has been established.
(3)The SCSM FSM is in state "User Interaction", substate "Waiting for Response from the SRF".

SCF postconditions:

(1)The collected information is received from the SRF as response to the "PromptAndCollectUserInformation" operation.
(2)If the "disconnectFromIPForbidden" was set to FALSE, the SCSM FSM will move to the state "Preparing SSF Instructions".
(3)Otherwise the SCSM FSM remains in the same state.

The SLPI may continue execution before the response is received from the "PromptAndCollectUserInformation" operation, more then one operation may be sent to the SRF before the response is received. The "disconnectFromIPForbidden" parameter may only be set to FALSE if the "PromptAndCollectUserInformation" operation is the last operation sent to the SRF.

7.3.22.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2, the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.22.3 Responding entity (SRF)

7.3.22.3.1 Normal procedure

SRF precondition:

(1)The SRSM FSM is in the state "Connected", or in state "User Interaction" if the SRF received previously an operation from the SCF.

SRF postconditions:

(1)The SRF has sent the information to the end-user as indicated by "informationToSend".
(2)The collected information from the end-user is sent to the SCF as RETURN RESULT of the "PromptAndCollectUserInformation".
(3)If the "disconnectFromIPForbidden" was set to FALSE, the SRF initiates a bearer channel disconnect to the SSF and the SRSM FSM moves to the state "Idle".
(4)Otherwise the SRSM FSM moves to the state "User Interaction", or
remains in the same state.

The announcement send to the end-user is ended in the following conditions:

when the complete announcement is sent; or
if "numberOfRepetitions" is specified, when all repetitions have been sent; or
if duration is specified, when the duration has expired. The announcement is repeated until this condition is met; or
if "duration" and "numberOfRepetitions" is specified, when one of both conditions is satisfied (whatever comes first).

The above conditions are overruled if the parameter "interruptableAnnInd" is not set to FALSE and the end-user has responded with a digit during the sending of the announcement. In this case the announcement is ended immediately. The above procedures apply only to inband information and tones send to the end-user, for "displayInformation" the end conditions are met upon sending, i.e. no interruption can occur.
The parameter "errorTreatment" specifies how the SRF shall treat the error "ImproperCallerResponse". The default value "stdErrorAndInfo" means that the error shall be reported to SCF as specified in subclause 7.2. The value "help" indicates that no error shall be reported to SCF but assistance shall be given to the end-user in form of a network dependent default announcement (which may be dependent on the context, i.e. the sent message). The value "repeatPrompt" indicates that no error shall be reported to the SCF but the prompt shall be repeated to the end-user. The last two procedures shall only be done once per "PromptAndCollectUserInformation" operation.

7.3.22.3.2 Error handling

If a Cancel operation is received before or during the processing of the operation then the operation is immediately cancelled and the error "Canceled" is reported to the invoking entity.
Generic error handling for the operation related errors is described in subclause 7.2, the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.23 ReleaseCall procedure

7.3.23.1 General description

This operation is used to tear down by the SCF an existing call at any phase of the call for all parties involved in the call. This operation may not be sent to an assisting SSF, except in the case of hand-off procedure.

7.3.23.1.1 Parameters

Cause A number giving an indication to the SSF about the reason of releasing this specific call. This may be used by SSF for generating specific tones to the different parties in the call or to fill in the "cause" in the release message.

7.3.23.2 Invoking entity (SCF)

7.3.23.2.1 Normal procedure

SCF precondition:

(1)State 2.1, "Preparing SSF instructions".

SCF postconditions:

(1)State 1, "Idle", if no "CallInformationReport" has to be received from the SSF. All resources (e.g. queue) related to the call are released by the SCF, or
State 2.3, "Waiting for Notification or Request" if a "CallInformationReport" still has to be received from the SSF.

7.3.23.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting errors are described in subclause 7.4.

7.3.23.3 Responding entity (SSF)

7.3.23.3.1 Normal procedure

SSF preconditions:

(1)State C," Waiting for Instructions", or
State F, "Monitoring".

SSF postcondition:

(1)"Idle", state a, after sending any outstanding "CallInformationReport". Possible armed EDPs are ignored. All connections and resources related to the call are released.

7.3.23.3.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting errors are described in subclause 7.4.

7.3.24 RequestNotificationChargingEvent procedure

7.3.24.1 General description

This operation is used to instruct the SSF how to manage the charging events which are received from other FEs not under the control of the SL instance. The operation supports the options to cope with the interactions concerning the charging (refer to Annex B, Clause B.4). As several connection configurations may be established during a call a possibility exists for the RNC operation to be invoked on multiple occasions. For each connection configuration a RNC may be used several times.

7.3.24.1.1 Parameters

Sequence of ChargingEvent: This parameter contains a list of the charging events and the corresponding monitor types and corresponding legs. For each element in the list the following information elements are included:

eventTypeCharging:

This sub parameter indicates the charging event type. Its content is network operator specific, which may be "charge pulses" or "charge messages".

monitorMode:

This sub parameter indicates the monitorMode applicable for the corresponding "eventTypeCharging" sub parameter. Monitor may be "interrupted", "notify" and "continue" or "transparent".

legID:

This sub parameter indicates the leg id of the corresponding event type charging sub parameter.

7.3.24.2 Invoking entity (SCF)

7.3.24.2.1 Normal procedure

SCF preconditions:

(1)A control relationship exist between the SCF and the SSF.
(2)An SLPI has determined that a "RequestNotificationChargingEvent" has to be sent by the SCF.

SCF postconditions:

(1)No FSM state transition,
(2)SLPI execution may continue.

The SCSM FSM is in state "Preparing SSF Instruction" or is in state "Queuing FSM". This operation is invoked by the SCF if a SLPI results in the instruction of SSF how to cope with the interactions concerning the charging. This causes no SCSM FSM state transition.

7.3.24.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.24.3 Responding entity (SSF)

7.3.24.3.1 Normal procedure

SSF preconditions:

(1)SSF FSM State c: "Waiting for Instructions"; or
SSF FSM State d: "Waiting for End of User Interaction"; or
SSF FSM State e: "Waiting for End of Temporary Connection"; or
SSF FSM State f: "Monitoring"; or
Assisting/Hand-off SSF FSM State b: "Waiting for Instructions".

SSF postcondition:

(1)No FSM state transition.

On receipt of this operation the SSF performs actions to cope with the interactions concerning the charging according the information elements included in the operation. The requested charging event can be caused by: a) another SLPI or b) another exchange. Irrespective of by what the charging event is caused the SSF performs one of the following actions on occurrence of the charging event (according the corresponding monitorMode):

Interrupted:

notify the SCF of the charging event using "EventNotificationCharging" operation, do not process the event or propagate the signal. However, call and existing charging processing will not be suspended in the SSF.

NotifyAndContinue:

notify the SCF of the charging event using "EventNotificationCharging", and continue processing the event or signal without waiting for SCF instructions (handled like EDP-N for BCSM events).

Transparent:

do not notify the SCF of the event. This is stop the monitoring of a previously requested charging event.

Requested charging events are monitored until ended by a transparent monitor mode (or in the case of charging events) until the end of the connection configuration.
In the case that multiple "RequestNotificationChargingEvent" operations are received for the same connection configuration with the same "eventTypeCharging" and "legID", only the last received "monitorMode" will apply.

7.3.24.3.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.25 RequestReportBCSMEvent procedure

7.3.25.1 General description

This operation is used to request the SSF to monitor for a call-related event (e.g., BCSM events such as busy or no answer), then send a notification back to the SCF when the event is detected.

7.3.25.1.1 Parameters

bcsmEvents:

This parameter specifies the event or events of which a report is requested.

eventTypeBCSM:: This parameter specifies the type of event of which a report is requested. Values origAttemptAuthorized and termAttemptAuthorized are not valid for the RequestReportBCSMEvent operation.
monitorMode:: This parameter indicates how the event should be reported. When the "monitorMode" is "interrupted", the event shall be reported as a request, if the "monitorMode" is "notifyAndContinue", the event shall be reported as a notification, if the "monitorMode" is "transparent", the event shall not be reported.
legID:: This parameter indicates the party in the call for which the event shall be reported. SCF will use the option "sendingSideID" only.

sendingSideID:: The following values for "legID" are assumed:; legID = 1 indicates the party that was present at the moment of the "InitialDP" (in case of a mid call trigger, the party causing the trigger), or the party that was created with an "InitiateCallAttempt" operation.
legID = 2 indicates the party that was created with a "Connect" operation, or in case of a mid call trigger, the party not causing the trigger.
If not included, the following defaults are assumed:; legID = 1 for the events CollectedInfo">CollectedInfo, AnalyzedInformation, O-Abandon and T-Abandon,
legID = 2 for the events RouteSelectFailure, O-CalledPartyBusy, O-NoAnswer, O-Answer, T-CalledPartyBusy, T-NoAnswer and T-Answer.
The "legID" parameter shall always be included for the events O-MidCall, O-Disconnect, T-MidCall and T-Disconnect.

dPSpecificCriteria:: This parameter indicates information specific to the EDP to be armed.

numberOfDigits:: This parameter indicates the number of digits to be collected by the SSF for the CollectedInfo">CollectedInfo event. If the indicated number of digits is collected, SSF reports the event to the SCF.
applicationTimer:: This parameter indicates the application timer for the NoAnswer event. If the user does not answer the call within the allotted time, the SSF reports the event to the SCF. This timer shall be shorter than the network no-answer timer.

7.3.25.2 Invoking entity (SCF)

7.3.25.2.1 Normal procedure

SCF preconditions:

(1)A control relationship exists between the SCF and the SSF.
(2)The SLPI has decided that a request for an event report BCSM is needed.
(3)The SCSM FSM is in the appropriate state to send "RequestReportBCSMEvent".

SCF postconditions:

(1)The SCSM FSM remains in the same state.
(2)SLPI execution continues.
(3)If all EDPs have been disarmed and no CallInformationReport or ApplyChargingReport is pending, the controlrelationship with the concerned SSF is ended. If no other relationship persist, the SCSM shall return to "Idle" state.

7.3.25.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.25.3 Responding entity (SSF)

7.3.25.3.1 Normal procedure

SSF precondition:

(1)The SSF FSM is in either the state "Waiting for Instructions" or the state "Monitoring".

SSF postconditions:

(1)The requested EDPs have been armed as indicated.
(2)Previously 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.
(3)The SSF FSM remains in the same state.
(4)If all EDPs have been disarmed and no "CallInformationReport" or "ApplyChargingReport" has been requested, the SSF FSM moves to the state "Idle".

7.3.25.3.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.26 ResetTimer procedure

7.3.26.1 General description

This class 2 operation is used by the SCF to refresh the TSSF application timer, in order to avoid the TSSF time-out at the SSF.

7.3.26.1.1 Parameters

timerValue:: This parameter specified the value to which the TSSF is to be set.
timerID:: This parameter has a default value identifying the TSSF timer.

7.3.26.2 Invoking entity (SCF)

7.3.26.2.1 Normal procedure

SCF preconditions:

(1)A control relationship exists between the SCF and the SSF.
(2)An SLPI has determined by the TSCF-SSF guard timer expiration, that the "ResetTimer" operation has to be sent in order to avoid TSSF time-out at the SSF.

SCF postcondition:

(1)The SLPI reset the TSCF-SSF guard timer.

7.3.26.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.26.3 Responding entity (SSF)

7.3.26.3.1 Normal procedure

SSF preconditions:

(1)Call origination attempt has been initiated.
(2)Basic call processing has been suspended at a DP.
(3)The SSF FSM is in the "Waiting for Instruction" state or in the "Waiting for End of User Interaction" state or in the "Waiting for End of Temporary Connection" state.

SSF postconditions:

(1)The TSSF timer has been reset.
(2)The SSF FSM remains in the same state.

7.3.26.3.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.29 SendChargingInformation procedure

7.3.29.1 General description

This operation is used to instruct the SSF on the charging information to be sent by the SSF. The sending of charging information can either be by charge pulses or signalling or internal if SSF is located in the Local Exchange (LE). In the LE, either a charge meter can be updated or a standard call record can be created. A possibility exists for the SCI operation to be invoked on multiple occasions. The charging scenario supported by this operation is: scenario 3.2 (refer to Annex B).

NOTE:	The interworking between SSF and PSTN is network operator specific. This operation has many PSTN/IN interactions.

7.3.29.1.1 Parameters

sCIBillingChargingCharacteristics: This parameter indicates billing and/or charging characteristics. Its content is network operator specific. Depending on the applied charging scenario the following information elements can be included (refer to Annex B):

charge level (scenario 3.2);
chargePulses;
chargeMessages.

legID:

This parameter indicates where the charging information shall be sent.

7.3.29.2 Invoking entity (SCF)

7.3.29.2.1 Normal procedure

SCF preconditions:

(1)A control relationship exist between the SCF and the SSF.
(2)An SLPI has determined that a "SendChargingInformation" has to be sent by the SCF.

SCF postconditions:

(1)No FSM state transition,
(2)SLPI execution may continue.

The SCSM FSM is in state "Preparing SSF Instruction" or is in state "Queuing FSM". The SendChargingInformation procedure shall be invoked by the SCF in accordance with the demands of the SLPI for relevant charging information. If appropriate this information shall be send back down the call path.
This causes no SCSM FSM state transition.

7.3.29.2.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.29.3 Responding entity (SSF)

7.3.29.3.1 Normal procedure

SSF preconditions:

(1)SSF FSM: State c: "Waiting for Instructions", or
SSF FSM State d: "Waiting for End of User Interaction", or
SSF FSM State e: "Waiting for End of Temporary Connection", or
SSF FSM: State f: "Monitoring", or
Assisting/hand-off SSF FSM State b: "Waiting for Instructions".

SSF postcondition:

(1)No FSM state transition.

On receipt of this operation the SSF performs actions to send the charging information. The sending of charging information can either be by charge pulses or signalling or internal if SSF is located in the LE. In the LE, either a charge meter can be updated or a standard call record can be created. The interworking between SSF and PSTN is network operator specific. This operation has much PSTN/IN interactions.
For instance, by sending an operation "SendChargingInformation" the SCF instructs the SSF to initiate the PSTN/ISDN charging functions according to the given information about the charging level to use.
The charging level can be determined either by one of the following functions:

a)the SCF; or
b)the SSF; or
c)the charging function in a succeeding exchange.

In case of the SCF having determined the charging level, the "SendChargingInformation" operation contains the charging level to be applied.
In case of the SSF to determine the charging level, the "SendChargingInformation" operation contains the parameters to determine the charging level.
If the charging level was determined by the IN (SCF or SSF), the SSF provides the charging level to be applied to the PSTN/ISDN charging functions (cases a and b).
In case c), the charging level is determined in a succeeding exchange. The "SendChargingInformation" operation either contains the corresponding parameters indicating this fact or the SSF detects during trying to determine the charging level based on SCF provided parameters that the charging level shall be determined in a succeeding exchange. Based on already existing PSTN/ISDN capabilities the SSF provides the PSTN/ISDN charging functions with the necessary information and backward charge messages shall be transferred down the call path when allowed by the SCF (generated by a succeeding exchange, e.g. an international gateway).
In the scenario described above charging/billing is performed by means of existing mechanisms of the PSTN/ISDN initiated and controlled by the IN.
That means the determination of the charging method (on-line or off-line) and the items to be charged for shall be done in the basic network, just like the charge generation and the charge registration.

7.3.29.3.2 Error handling

Generic error handling for the operation related errors is described in subclause 7.2 and the TCAP services which are used for reporting operation errors are described in subclause 7.4.

7.3.30 ServiceFilteringResponse procedure

7.3.30.1 General description

This operation is used to report the values of counters specified in a previous sent "ActivateServiceFiltering" operation to the SCF.

7.3.30.1.1 Parameters

countersValue:: The parameter contains the count of calls filtered during the filtering period. It is a list of counter identifications and the related values.
filteringCriteria:: This parameter is used to address the concerned SL at the SCF.

7.3.30.2 Invoking entity (SSF)

7.3.30.2.1 Normal procedure

SSF preconditions:

(1)Service filtering is running and the interval time is expired and a call is received, or
(2)Service filtering is running and the threshold value is reached, or
(3)Service filtering has been finished (duration time expired or stop time met), or
(4)The operation "ActivateServiceFiltering" is received and encounters an active service filtering entity.

SSF postcondition:

(1)Service filtering proceeds or is ended depending on the duration time.

The SSF sends the "ServiceFilteringResponse" operation to the SCF. The "filteringCriteria" parameter is provided to enable the addressing of the concerned SL at the SCF.
Before "ServiceFilteringResponse" is sent, it is checked whether call gapping criteria are met. If so, the "ServiceFilteringResponse" is not sent and the counting continues without resetting the counters. The last "ServiceFilteringResponse" (stop time is met or duration time expired) is sent without checking any call gap criteria.
After sending "ServiceFilteringResponse" the service filtering counters are reset.
If service filtering proceeds after sending "ServiceFilteringResponse" (e.g. interval time expired) the SSME FSM remains in the state "Non-Call Associated Treatment".
If service filtering is stopped after sending "ServiceFilteringResponse" (duration time expired or stop time is met) then the SSME FSM moves to the "Idle Management" state. All concerned resources are released, i.e. the SSME FSM is removed as well.

7.3.30.2.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

7.3.30.3 Responding entity (SCF)

7.3.30.3.1 Normal procedure

SCF preconditions:

(1)Service filtering is running.
(2)The SCME is in the state "Waiting for Service Filtering Response".

SCF postcondition:

(1)The SCME forwards the received counter values to the SLPI.

The operation is handled by the Service Filtering FSM part of the SCF Management Entity (SCME). The SCME passes the received counter values to the SLPI where they are added to previously received counter values.
The "filteringCriteria" parameter as provided in "ServiceFilteringResponse" is used to address the SCME and the concerned SL instance.
The Service Filtering FSM of the SCME remains in the state "Waiting For SSF Service Filtering Response" until the internal service filtering duration time in the SLPI expires. Then the SLPI informs the SCME about timer expiration. Now the SCME moves to the state "Service Filtering Idle".

7.3.30.3.2 Error handling

If the SCME is in the state "Service Filtering Idle" an incoming "ServiceFilteringResponse" operation is ignored.

7.3.31 SpecializedResourceReport procedure

7.3.31.1 General description

This operation is used as the response to a "PlayAnnouncement" operation when the announcement completed indication is set.

7.3.31.1.1 Parameters

None.

7.3.31.2 Invoking entity (SRF)

7.3.31.2.1 Normal procedure

SRF preconditions:

(1)The SRSM FSM is in the state "User Interaction".
(2)A "PlayAnnouncement" operation is being executed for which the parameter "RequestAnnouncementComplete" was set TRUE.
(3)All information has been sent to the user.

SRF postconditions:

(1)The SRSM FSM remains in the same state.
(2)If the "DisconnectFromIPForbidden" parameter was set FALSE, the SRSM initiates a bearer channel disconnect sequence to the SSF using the applicable bearer channel signalling system after sending the "SpecializedResourceReport" operation to the SCF. The SRSM FSM moves to the state "Idle".

7.3.31.2.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

7.3.31.3 Responding entity (SCF)

7.3.31.3.1 Normal procedure

SCF precondition:

(1)The SCSM FSM is in the state "User Interaction", substate "Waiting for response from the SRF".

SCF postconditions:

(1)The SCSM FSM remains in the same state.
(2)If the "SpecializedResourceReport" relates to a "PlayAnnouncement" operation with permission of SRF initiated disconnection, the SCSM FSM moves to the state "Preparing SSF Instructions".

7.3.31.3.2 Error handling

Operation related error handling is not applicable, due to class 4 operation.

INAP Contents Page