7.1.1.5 SSF State Transition Diagram

Figure 12 shows the State diagram of the SSF part of the SSP during the processing of an IN call/attempt. Each State is discussed in the following subclauses. General rules applicable to more than one state are addressed here.
One or a sequence of components received in one or more TCAP messages may include a single operation or multiple operations, and is processed as follows:

• process the operations in the order in which they are received;
• each operation causes a state transition independent of whether or not a single operation or multiple operations are received in a message;
• the SSF examines subsequent operations in the sequence. As long as sequential execution of these operations would leave the FSM in the same state, it will execute them (e.g., RequestReportBCSMEvent). If a subsequent operation causes a transition out of the state then the following operations should be buffered until the current operation has been executed. In all other cases, await an event that would cause a transition out of the current state (such an event would be the completion of operation being executed), or reception of an external event.

  EXAMPLE:

  The SSF receives the operations FurnishChargingInformation, ConnectTo-Resource, and PlayAnnouncement in a component sequence inside a single TCAP message. Upon receipt of this message, these operations are executed up to and including ConnectToResource while the SSF is in the Waiting for Instruction state. As the ConnectToResource operation is executed (and when, or after the FurnishChargingInformation operation has been completed), the SSF FSM will transition to the Waiting for End of User Interaction state. The PlayAnnouncement operation is relayed to the SRF while the SSF is in Waiting for End of User Interaction state.

• if there is an error in processing one of the operations in the sequence, the SSF FSM processes the error (see below) and discards all remaining operations in the sequence;
• if an operation is not understood or is out of context (i.e. violates the SACF rules defined by the SSF FSM) as described above, the SSF FSM processes the error according to the rules given in subclause 7.4.2 (using TC-U-REJECT or the operation error UnexpectedComponentSequence).

In any State, if there is an error in a received operation, the maintenance functions are informed. Generally, the SSF FSM remains in the same State as when it received the erroneous operation, however different error treatment is possible in specific cases as described in subclause 7.2; depending on the class of the operation, the error could be reported by the SSF to the SCF using the appropriate component (see ETS 300 287 [5] (ITU-T Recommendation Q.774)).
In any State (except Idle), if the calling party abandons the call before it is answered (i.e., before the Active PIC in the BCSM), then the SSF FSM should instruct the CCF to clear the call and ensure that any CCF resources allocated to the call have been de-allocated, then continue processing as follows:

• if the Abandon DP is not armed and there is no Call Information Request pending, then transition to the Idle state;
• if the Abandon DP is not armed and there is a Call Information Request pending, send a CallInformationReport, then transition to the Idle state;
• if the Abandon DP is armed as an EDP-R, send an EventReportBCSM operation, then transition to the Waiting for Instructions state (whether or not there is a pending Call Information Request);
• if the Abandon DP is armed as an EDP-N and there is no Call Information Request pending, send an EventReportBCSM , then transition to the Idle state;
• if the Abandon DP is armed as an EDP-N and there is a Call Information Request pending, send an EventReportBCSM and a CallInformationReport, then transition to the Idle state.

Other pending requests that are treated in the same way as the CallInformationRequest operation in the above list is the ApplyCharging operation when the "SendCalculation ToSCP Indication" parameter is set to True.
In any State (except Idle), if a call party disconnects from a stable call (i.e., from the Active PIC in the BCSM), then the SSF FSM should process this event as follows:

• if the Disconnect DP is not armed for that specific leg and there is no Call Information Request pending, transition to the Idle state;
• if the Disconnect DP is not armed and there is a Call Information Request pending, send a CallInformationReport and transition to the Idle state;
• if the Disconnect DP is armed as an EDP-R for that specific leg, send either an EventReportBCSM and then transition to the Waiting for Instructions state or if a Call Information Request is pending, immediately after the CallInformationReport the corresponding EventReportBCSM has to be sent;
• if the Disconnect DP is armed as an EDP-N and there is no Call Information Request pending, send an EventReportBCSM , then transition to the Idle state;
• if the Disconnect DP is armed as an EDP-N and there is a Call Information Request pending, send an EventReportBCSM and a CallInformationReport, then transition to the Idle state.

Other pending requests that are treated in the same way as the CallInformationRequest operation in the above list is the ApplyCharging operation when the "SendCalculation ToSCP Indication" parameter is set to True.
The SSF has an application timer, TSSF, whose purpose is to prevent excessive call suspension time and to guard the association between the SSF and the SCF.
Timer TSSF is set in the following cases:

• when the SSF sends an InitialDP (refer to subclause 7.1.1.5.3 State c: "Waiting for Instructions") or AssistRequestInstructions operation (refer to subclause 7.1.1.6.2 State b: "Waiting for Instructions" in the assisting/hand-off case). While waiting for the first response from the SCF, the timer TSSF can be reset only once by a Reset Timer operation. Subsequent to the first response, the timer can be reset any number of times;
• when the SSF enters the "Waiting for instructions" state (refer to subclause 7.1.1.5.3) under any other condition as the one listed in the previous case. In this case the SCF may reset the TSSF timer using the Reset operation any number of times;
• when the SSF enters the "Waiting for End of User Interaction" state or the "Waiting for End of Temporary Connection" state (refer to subclauses 7.1.1.5.4 and 7.1.1.5.5). In these cases the SCF may reset TSSF using the Reset Timer operation any number of times.

In the three above cases, TSSF may respectively have three different values as defined by the application.
When receiving or sending any operation which is different from the above, the SSF should reset TSSF to the last used set value. This value is either one associated to the three different cases as listed above, or received in a ResetTimer operation, whatever occured last. In the "Monitoring" state (refer to subclause 7.1.1.5.6) TSSF is not used.
On expiration of TSSF the SSF FSM transitions to the Idle state, aborts the interaction with the SCF and the CCF progresses the BCSM if possible.
The SSF State diagram contains the following transitions (events):

e1: TDP encountered
e2: Trigger fail
e3: Initiate call received
e4: Trigger detected
e5: User Interaction requested
e6: User Interaction ended
e7: Temporary connection created
e8: Temporary connection ended
e9: Idle return from Wait for Instruction
e10: EDP_R encountered
e11: Routing instruction received
e12: EDP_N last encountered
e13: Waiting for End of User Interaction state no change
e14: Waiting for Instruction state no change
e15: Waiting for End of Temporary Connection state no change
e16: Monitoring state no change
e17: Abandon (from any state) (not shown in the SSF state diagram)
e18: Disconnect (from any state) (not shown in the SSF state diagram)
e19: Non call associated treatment from any state (not shown in the SSF state diagram)

The SSF State diagram contains the following states:
State a: Idle
State b: Trigger Processing
State c: Waiting for Instructions
State d: Waiting for End of User Interaction
State e: Waiting for End of Temporary Connection
State f: Monitoring

NOTE:

Abandon and Disconnect transitions are not shown.

Figure 12: SSF FSM

7.1.1.5.1 State a: "Idle"

The SSF FSM enters the Idle state under a variety of conditions, as described below.
The SSF FSM enters the Idle State when sending or receiving an ABORT TCAP primitive due to abnormal conditions in any state.
The SSF FSM enters the Idle State when DP processing fails in the Trigger Processing state (transition e2).
The SSF FSM enters the Idle State when one of the following occurs:

• when the call is abandoned or one or more call parties disconnect in any other state under the conditions identified in subclause 7.1.1.5;
• when a Connect, or Proceed Call Processing operation is processed in the Waiting for Instructions state, and no EDPs are armed and there are no outstanding report requests (transition e9);
• when the application timer TSSF expires in one of the states: Waiting for Instructions, Waiting for End of User Interaction or Waiting for End of Temporary Connection (transition e9);
• when a ReleaseCall operation is processed in Waiting for Instructions (transition e9) or Monitoring (transition e12);
• when the last EDP-N is encountered in the Monitoring State, and there are no EDP-Rs armed and no monitoring is active for charging events (transition e12);
• when the last charging event is encountered in the Monitoring State, and there are no EDPs armed (transition e12).

When transitioning to the Idle state, if there is a Call Information Request pending (see subclause 7.1.1.5), the SSF sends a CallInformationReport operation to the SCF before returning to Idle.
During this State the following call-associated events can occur:

• indication from the CCF that an armed TDP is encountered related to a possible IN call/service attempt: in this case the SSF FSM moves to the State Trigger Processing (transition e1);
• a message related to a new transaction containing an Initiate Call Attempt operation is received from the SCF: in this case the SSF FSM moves to the State Waiting for Instructions (transition e3).

Any other operation received from the SCF while the SSF is in Idle State should be treated as an error. The event should be reported to the maintenance functions and the transaction should be aborted according to the procedure specified in TCAP (see ETS 300 287 [11] (ITU-T Recommendation Q.774)).

7.1.1.5. State b: "Trigger Processing"

Following a trigger detection related to an armed TDP in the BCSM, the SSF FSM is activated and moves from the Idle State to the Trigger Processing State (transition e1).
In this State, the SSF/CCF should:

• perform the DP processing actions specified in ITU-T Recommendation Q.1214 [11], � 4.2.2.5:
  • check if call gapping or service filtering mechanisms are active;
  • check for SCF accessibility;
  • determine if DP criteria are met;
  • handle service feature interactions
• collect and verify necessary parameters for sending a InitialDetectionPoint to the SCF:
  • if successful and the DP is a TDP-R, send a generic InitialDetectionPoint to the SCF, as determined from DP processing, and transition to the Waiting for Instructions state (transition e4);
  • if DP processing fails, return to the Idle state (transition e2). DP processing fails in the following cases:
    • if CallGapping is in effect: the SSF FSM will instruct the CCF to terminate the call with the appropriate treatment;
    • if Service Filtering is in effect: the call is counted (if required) and the SSF FSM instructs the CCF to terminate the call with the appropriate treatment;
    • if a trigger criteria match is not found: the SSF FSM returns call control to the CCF;
    • if the Call is abandoned: the SSF returns call control to the CCF and continues processing as described in subclause 7.1.1.5;
    • if there is insufficient information to proceed (e.g. applies to open numbering plans): the SSF FSM instructs the CCF to terminate the call with a standard terminating treatment;
    • if the destination SCF is not accessible: the SSF FSM will instruct the CCF to route the call if possible (e.g. default routing to a terminating announcement);
    • if there is an existing control relationship for the call: the SSF returns call control to the CCF.