7.1.1.5.6 State f: "Monitoring"

The SSF enters this State from the Waiting for instructions State (transition e11) upon receiving a Connect, CollectInformation, Continue operation when one or more EDPs are armed or/and there is Call Information Request pending (see subclause 7.1.1.5).
In this state the timer TSSF is not used; i.e., the expiration of TSSF does not have any impact on the SSF FSM.
During this State the following events can occur:

• an EDP-N should be reported to the SCF by sending an EventReportBCSM operation; the SSF FSM should remain in the Monitoring State (transition e16) if one or more EDPs are armed or there are report requests pending. The SSF FSM shall move to the Idle state (transition e12) if there are no remaining EDPs armed and there are no report requests pending;
• an EDP-R should be reported to the SCF by sending an Event Report BCSM operation; the SSF FSM should move to the Waiting for instructions State (transition e10);
• the receipt of an END or ABORT primitive from TCAP has no effect on the call; the call may continue or be completed with the information available. In this case, the SSF FSM transitions to the Idle state (transition e12), disassociating the SSF FSM from the call;
• an operation is received from the SCF: The SSF FSM acts according to the operation received as described below;
• the user abandons or disconnects. This should be processed in accordance with the general rules in subclause 7.1.1.5.

The following operations can be received from the SCF and processed by the SSF with no resulting transition to a different state (transition e16):
RequestReportBCSMEvent
RequestNotificationChargingEvent
SendChargingInformation
The Cancel operation may be received from the SCF and processed by the SSF, causing a state transition to the Idle State (transition e12).
The ReleaseCall operation may be received from the SCF and processed by the SSF, causing a state transition to the Idle State (transition e12). If there is a Call Information Request pending, the SSF sends a CallInformationReport to the SCF.
Any other operation received in this state should be processed in accordance with the general rules in subclause 7.1.1.5.

7.1.1.6 Assisting/Hand-off SSF FSM

The present subclause describes the SSF FSM related to the Assisting/Hand-off SSF. The Assisting SSF is structured as defined in subclauses 7.1.1.1 through 7.1.1.5 of this ETS. The Hand-off FSM for CS1 applies only to the case where final treatment is to be applied. Within this subclause, the term "Assisting SSF" refers to both Assisting and Hand-off SSFs unless an explicit indication to one or the other is provided.
The Assisting/Hand-off SSF State diagram contains the following transitions (events):
ea1: Assist/Hand-off detected
ea2: Assist/Hand-off ended (fail or success)
ea3: User Interaction requested
ea4: User Interaction ended
ea5: Waiting for Instruction state no change
ea6: Waiting for End of User Interaction state no change
The Assisting/Hand-off SSF State diagram contains the following states:
State a: Idle
State b: Waiting for Instructions
State c: Waiting for End of User Interaction

Figure 13: Assisting/Hand-off SSF FSM

7.1.1.6.1 State a: "Idle"

The SSF FSM enters the Idle State when one of the following occurs:

• when sending or receiving an ABORT TCAP primitive due to abnormal conditions in any state;
• given a temporary connection between an upstream SSF and the Assisting SSF, when a bearer channel disconnect is received from the upstream SSF; (transition ea2).

Once in the Idle state, if there are any outstanding responses to send to the SCF, they are discarded by the Assisting SSF.
The Assisting SSF FSM transitions from the Idle State to the Waiting for Instructions state on receipt of an assist indication at the assisting SSF from another SSF (transition ea1).
Any operation received from the SCF while the Assisting 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.6.2 State b: "Waiting for Instructions"

This State is entered from the Idle State on receipt of a connect at an SSF from another SSF indicating that an assist is required, based on an implementation dependent detection mechanism(transition ea1).
In this State the SSF sends an AssistRequestInstructions operation to the SCF and the Assisting SSF FSM is waiting for an instruction from the SCF; call handling is suspended and an application timer (TSSF) should be set on entering this State.
During this State the following events can occur:

• the application Timer TSSF expires: the Assisting SSF FSM moves to the Idle State (transition ea2) and the expiration is reported to the maintenance functions and the transaction is aborted;
• an operation is received from the SCF: The SSF FSM acts according to the operation received as described below;
• a bearer channel disconnect is received and the FSM moves to the Idle state (transition ea2).

The following operations may be received from the SCF and processed by the Assisting SSF with no resulting transition to a different state (transition ea5):
ResetTimer
FurnishChargingInformation
ApplyCharging
SendChargingInformation
The following operations can be received from the SCF and processed by the Assisting SSF, causing a state transition to Waiting for End of User Interaction state (transition ea3):
ConnectToResource
The following operations can be received from the SCF and processed by the Hand-off SSF, causing a state transition to Idle State (transition ea2):
ReleaseCall
Note that the above operation is allowed only in the Hand-off SSF. In the case where an implementation is not capable of differentiating between a Hand-off or an assisting SSF case, it may execute the ReleaseCall operation in the assisting SSF.
Any other operation received in this state should be processed in accordance with the general rules in subclause 7.1.1.5.

NOTE:

Multiple Hand-off procedures are not covered by this ETS.

7.1.1.6.3 State c: "Waiting for End of User Interaction"

The Assisting SSF enters this State from the Waiting for Instructions State (transition ea3) on the reception of one of the following operations:
ConnectToResource
During this State the following events can occur:

• a valid SCF-SRF operation (i.e., Play Announcement, Prompt & Collect User Information and Cancel Announcement) for relaying is received and is correct, the operation is transferred to the SRF for execution. The SSF FSM remains in the Waiting for End of User Interaction State (transition ea6);
• a valid SRF-SCF operation (i.e., Specialized Resource Report and Return Result from Prompt and Collect user Information) for relaying is received and is correct, the operation is transferred to the SCF. The SSF FSM remains in the Waiting for End of User Interaction State (transition ea6);
• when the SRF indicates to the Hand-off SSF the end of user interaction by initiating disconnection the Hand-off SSF FSM returns to the Waiting for Instructions State (transition ea4);
• the application Timer TSSF expires: the SSF FSM moves to the Idle State, the CCF routes the call if possible (e.g., default routing to a terminating announcement), the TSSF expiration is reported to the maintenance functions and the transaction is aborted;
• an operation is received from the SCF: The SSF FSM acts according to the operation received as described below.
• a bearer channel disconnect is received from the initiating SSF. The assisting SSF FSM moves to the Idle state, the connection to the SRF is released and the transaction is aborted.

The following operations can be received from the SCF and processed by the SSF with no resulting transition to a different state (transition ea6):
ResetTimer
The DisconnectForwardConnection operation may be received from the SCF and processed by the Assisting SSF in this state, causing a transition to the Waiting for Instructions state (transition ea4). This procedure is only valid if a ConnectToResource was previously processed to cause a transition into the Waiting for End of User Interaction state.
Any other operation received in this state should be processed in accordance with the general rules in subclause 7.1.1.5.