7.1.2.5.2 State 2: "Preparing SSF Instructions"

In this state, the SCF determines how to further process.
The following events are considered in this state:

To further describe the procedures relevant to this state, the state is divided into three sub-states, which are described in the following three subclauses (this subdivision is illustrated in figure 18).

NOTE 1:
Including Call Information Request and Apply Charging with report request.
NOTE 2:
Including Call Information Report, Apply Charging Report, and Event Notification Charging.
NOTE 3:
Including Call Information Report and Apply Charging Report.

Figure 18: Partial Expansion of the State 2 FSM

7.1.2.5.2.1 State 2.1: "Preparing SSF Instructions"

State 2.1, Preparing SSF Instructions, is where the initial decision is made on whether the SDF information or a Specialized Resource is needed, whether queueing is supported, etc. In addition, the EDP-R-related processing is also performed in this state.
On entering this state, the SCSM starts or resets the timer TSCF-SSF.
The following events are considered in this state:

This event causes a transition back to State 2.1, Preparing SSF Instructions.

This event maps into the SCSM event (e4).

In addition, one or more of the following operations may be issued to the SSF prior to one of the operations listed above:

This event causes a transition into State 2.3, Waiting for Notification or Request.

7.1.2.5.2.2 State 2.2 "Queueing FSM"

When the SCF is processing the Query from the SSF/CCF, it may find that the resource to which the call shall be routed is unavailable. One possible reason causing the resource to be unavailable is the "busy" condition.

NOTE:
The manner in which the status of the resources is maintained is described in subclause 7.1.2.4.3.

Such a resource may be an individual line or trunk or a customer-defined group of lines or trunks. In the latter case, the word "busy" means that all lines or trunks in the group are occupied; and the word "idle" means that at least one line or trunk in the group is idle.
If the resource is busy, the SCF may put the call on queue and resume it later when the resource is idle. The following operations can be sent in this state:

The following events are considered in this state:

This state further expands into an FSM, which is depicted in figure 19.
This FSM does not explicitly describe all possible combinations of resource monitoring functions used for queueing. The following possibilities may be used in implementations:

In the rest of this subclause, the state-by-state description of the FSM is followed by the description of the supporting mechanisms of the SCME.

Figure 19: Partial Expansion of the State 2 FSM as Related to Queueing

7.1.2.5.2.2.1 State 2.2.1: Preparing SSF Instructions

In this state, the SCSM prepares the instructions for the SSF to complete the call. The following events are considered in this state:

7.1.2.5.2.2.2 State 2.2.2: "Queueing"

In this state, the SCSM is awaiting an indication from the RCO to proceed with routing a call to an idle trunk/line. The support of playing various announcements is also provided when the SCSM is in this state. In this ETS, the relevant further expansion of the state is not provided; it is, however, not different from that of the SCSM States 3 and 4. However, if announcements are completed before the call is dequeued and the SSF FSM has transitioned to state Waiting for Instructions, the ResetTimer operation should be sent to set the TSCF-SSF with an appropriate value. Once the SCSM enters this state, the Queueing Timer is started, and the TSCF-SSF is reset. The respective roles of these timers are as follows:

  1. the Queueing Timer limits the time that a call can spend in the queue, and its value may be customer-specific;
  2. the TSCF-SSF signals when the Reset Timer operation shall be sent to the SSF/CCF lest the latter abandons the call. Hence, the value of this timer is set in agreement with that of the relevant timer TSSF within the SSF/CCF.

The FurnishChargingInformation operation may also be sent to the SSF at this time to indicate the initiation of queuing for call logging purposes.
The following events are considered in this state:

7.1.2.5.2.3 State 2.3: "Waiting for Notification or Request"

In this state, the SCSM waits for a notification or a request from the SSF.
On entering this state the SCSM stops the timer TSCF-SSF.
The following events are considered in this state:

This event causes a transition to State 2.1 Preparing SSF Instructions.

In this case, there is still an outstanding armed EDP or an outstanding Call Information Report or Apply Charging Report operations. This event causes a transition to back to State 2.3 Waiting for Notification or Request.

In this case, there is no outstanding armed EDP and no outstanding Call Information Report or Apply Charging Report operations. This event maps into the SCSM event (e4).
This concludes the description of State 2 Preparing SSF Instructions.

7.1.2.5.3 State 3: "Routing to Resource"

The resource is any SRF facility (e.g., Intelligent Peripheral).
In this state, interactions with the SSF are necessary. Accordingly, the following events cause transitions out of this state:

To further describe the procedures relevant to this state, the state is divided into two sub-states, which are described in the following two subclauses (this subdivision is illustrated in figure 20).

Figure 20: The State 3 FSM

7.1.2.5.3.1 State 3.1: "Determine Mode"

In this state, the SCSM determines the User Interaction mode to connect the call to SRF. The following events are considered in this state:

7.1.2.5.3.2 State 3.2: "Waiting for Assist Request Instructions"

In this state, the SCSM waits for the Assist Request Instructions operation from the Assisting SSF (SSF relay case) or from the SRF (Direct SCF-SRF case). On entering this state the SCSM starts the Timer TASSIST/HAND-OFF, and resets the timer TSCF-SSF. The following events are considered in this state:

7.1.2.5.4 State 4: "User Interaction"

In this state, the SCF requests the SRF to provide user interaction (e.g., collect additional information and/or play announcements). When an interaction is finished the SCF can instruct the SSF to disconnect the bearer between SSF and SRF. Alternatively, it can send a user interaction operation to the SRF containing an indication that allows the SRF initiated disconnect.
On entering this state the SCSM resets the timer TSCF-SSF.
The following events cause transitions out of this state:

To consider the processing of this state in more detail, it is expanded into a separate FSM depicted in figure 21.

Figure 21: State 4 FSM

7.1.2.5.4.1 State 4.1 "Waiting for Response from the SRF"

In this state, the SCF waits for the response to the previously sent operation and evaluates this response. The following events are considered in this state:

It should be noted that the bearer connection between the SSF and the SRF is disconnected when the SCSM exits from this state.

Section 7 Procedures Contents Page