7.1.1.1 General
7.1.1.2 Model and interfaces
CCF and maintenance functions"
>7.1.1.3 Relations between SSF FSM and the CCF and maintenance functions
7.1.1.4 SSF
Managemet Entity (SSME) FSM
7.1.1.5 SSF
State Transition Diagram
7.1.1.5.1 State
a: "Idle"
7.1.1.5.2
State b: "Trigger Processing"
7.1.1.5.3 State c: "Waiting for Instructions"
7.1.1.5.4 State d: "Waiting for End of User Interaction"
7.1.1.5.5 State e: "Waiting for End of Temporary Connection"
7.1.1.5.6
State f: "Monitoring"
7.1.1.6
Assisting/Hand-off SSF FSM
7.1.1.6.1 State
a: "Idle"
7.1.1.6.2 State b: "Waiting for Instructions"
7.1.1.6.3 State c: "Waiting for End of User Interaction"
This subclause provides the definition of the SSF AE procedures
related to the SSP-SCP interface. The procedures are based on the use of
SS No. 7; other signalling systems may be used (e.g. DSS1, layer 3).
Capabilities not explicitly covered by these procedures may be supported
in an implementation dependent manner in the SSP, while remaining in
line with Clause 6 of this ETS.
The AE, following the architecture
defined in ITU-T Recommendations Q.700 [9] and Q.1400 [13], and ETS
300 287 [11] (ITU-T Recommendation Q.771), includes TCAP and one or
more ASEs called TC-users. The following subclauses define the TC-user
ASE which interfaces with TCAP using the primitives specified in ETS
300 287 [11] (ITU-T Recommendation Q.771); other signalling systems,
such as DSS1 (layer 3), may be used.
The procedure may equally be
used with other signalling message transport systems supporting the
Application Layer structures defined. In case interpretations for the AE
procedures defined in the following differ from detailed procedures and
the rules for using of TCAP service, the statements and rules contained
in the detailed subclauses 7.3 and 7.4 shall be followed.
The functional model of the AE-SSF is shown in figure 9; the ASEs interface to TCAP to communicate with the SCF, and interface to the Call Control Function (CCF) and the maintenance functions already defined for switching systems. The scope of this ETS is limited to the shaded area in figure 9.
Figure 9: Functional model of
SSF AE
The interfaces shown in figure 9 use the TC-user ASE
primitives specified in ETS 300 287 [11] (ITU-T Recommendation Q.771)
(interface (1)) and N-Primitives specified in ETS 300 009 [2] (ITU-T
Recommendation Q.711) (interface (2)). The operations and parameters of
INAP are defined in Clause 6 of this ETS.
The primitive interface between the SSF FSM and the CCF/maintenance
functions is an internal interface and is not subject to standardization
in CS1. Nevertheless, this interface should be in line with the BCSM
defined in ITU-T Recommendation Q.1214 [11], � 4.2.1.2.
The
relationship between the BCSM and the SSF FSM may be described as
follows for the case of a call/attempt initiated by an end user, and the
case of a call/attempt initiated by IN Service Logic (SL):
The management functions related to the execution of operations
received from the SCF are executed by the SSF Management Entity (SSME).
The SSME comprises a SSME-Control and several instances of SSME FSMs.
The SSME-control interfaces the different SSF FSMs and SSME FSMs
respectively and the Functional Entity Access Manager (FEAM). Figure
10 shows the SSF Interfaces.
Figure 10: SSF Interfaces
The
FEAM provides the low level interface maintenance functions including
the following:
The SSME-control maintains the dialogues with the SCF, and SRF on behalf of all instances of the SSF FSM. These instances of the SSF FSM occur concurrently and asynchronously as calls occur, which explains the need for a single entity that performs the task of creation, invocation, and maintenance of the SSF FSMs. In particular the SSME-control performs the following tasks:
The different contexts of the SSME FSMs may be distinguished based
on the address information provided in the initiating operations. In the
case of service filtering this address information is given by
filteringCriteria, i.e. all ActivateServiceFiltering operations using
the same address, address the same SSME FSM handling this specific
service filtering instance. For example ActivateServiceFiltering
operations providing different filtering Criteria cause the invocation
of new SSME FSMs.
The SSF FSM passes call handling instructions to
the related instances of the BCSM as needed. DPs may be dynamically
armed as Event DPs, requiring the SSF FSM to remain active. At some
point, further interaction with the SCF is not needed, and the SSF FSM
may be terminated while the BCSM continues to handle the call as needed.
A later TDP in the BCSM may result in a new instance of the SSF FSM for
the same call.
Consistent with the single-ended control
characteristic of IN service features for CS1, the SSF FSM only applies
to a functionally separate call portion (e.g., the originating BCSM or
the terminating BCSM in a two-party call, but not both).
The SSME FSM State Diagram is described in figure 11. The SSME FSM
is independent of the individual SSF FSMs.
Figure 11:SSME FSM state diagram.
The Non-Call Associated Treatment state is entered from the IdleManagement
State when one of the following non-call associated operations is
received (transition em1):
The CallGap operation may be received inside as well as outside a call context transaction. The ActivityTest operation applies to call associated transactions only. The ActivateServiceFiltering operation may be received outside a call context only. During this State the following events can occur:
All other operations have no effect on the SSME FSMs; the operations are passed by the SSME-Control to the relevant SSF FSM.
Section 7.1.1.5 7.1.1.5 SSF State Transition Diagram Contents Page
