7.1.2.1 General
7.1.2.2 Model and Interfaces
7.1.2.3 Relationship between the SCF FSM and Service Logic Programs
(SLPs)/maintenance functions
7.1.2.4 Partial SCF Management Entity (SCME) State Transition Diagram
7.1.2.4.1
State M3: "Service Filtering Idle"
7.1.2.4.2 State M4: "Waiting for SSF Service Filtering Response"
7.1.2.4.3 The
Resource Control Object (RCO)
7.1.2.5 The SCF Call
State Model (SCSM)
7.1.2.5.1 State 1:
"Idle"
7.1.2.5.2
State 2: "Preparing SSF Instructions"
7.1.2.5.3
State 3: "Routing to Resource"
7.1.2.5.4
State 4: "User Interaction"
This subclause provides the definition of the SCF AE procedures
related to the SCF-SSF/SRF/SDF interface. The procedures are based on
the use of SS No. 7; other signalling systems can also be used.
In
addition, other capabilities may be supported in an
implementation-dependent manner in the SCP, AD or SN.
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 and SACF/MACF rules, which interface
with TCAP using the primitives specified in ETS 300 287 [11] (ITU-T
Recommendation Q.771).
The procedure may equally be used with
other message-based signalling systems supporting the Application Layer
structures defined. By no means is this text intended to dictate any
limitations to Service Logic Programs (SLPs).
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-SCF is shown in figure 14; the ASEs interface with supporting protocol layers to communicate with the SSF, SRF and SDF, and interface to the SLPs and maintenance functions. The scope of this ETS is limited to the shaded area in figure 14.
Figure 14: Functional
model of SCF AE
The interfaces shown in figure 14 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 SCF FSM and the SLPs/maintenance
functions is an internal interface and is not a subject for
standardization in CS1.
The relationship between the SLP and the
SCF FSM may be described as follows (for cases both a call initiated by
an end user and a call initiated by IN SL):
In either case, the SCF FSM handles the interaction with the SSF FSM
(and the SRF FSM and SDF FSM) as required, and notifies the SLP of
events as needed.
The management functions related to the execution
of operations received from the SCF are executed by the SCF Management
Entity (SCME). The SCME is comprised of the SCME-Control and multiple
instances of SCME FSMs. The SCME-Control interfaces different SCSMs and
the FEAM. Figure 15 shows the SCF FSM structure.
Figure 15: SCF FSM
Structure
The following text systematically describes the
procedural aspects of the interface between the SCF and other functional
entities, with the main goal of specifying the proper order of
operations rather than the functional capabilities of the entities.
Consequently, this text describes only a subset of the SCF functional
capabilities.
The procedural model associates an SCSM with each
query from the SSF. The SCSM maintains dialogues with the SSF, SRF, and
SDF on behalf of SL.
Multiple requests may be executed
concurrently and asynchronously by the SCF, which explains the need for
a single entity that performs the tasks of creation, invocation, and
maintenance of the SCF FSM objects. This entity is called the SCF
Management Entity-Control (SCME-Control). In addition to the above
tasks, the SCME maintains the dialogues with the SSF, SDF, and SRF on
behalf of all instances of the SCF FSMs. In particular, the
SCME-Control:
The different contexts of the SCME 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 SCME FSM handling this specific
service filtering instance. For example, ActivateServiceFiltering
operations providing different filteringCriteria cause the invocation of
new SCME FSMs.
Finally, the FEAM relieves the SCME of low-level
interface functions. The functions in the FEAM include:
The key part of SCF Management Entity (SCME) State Diagram is described in figure 16.
Figure 16: The Service
Filtering FSM in the SCME
The SCME handles the following
operations:
Activate Service Filtering;
Service Filtering Response;
Call Gap; and
Activity Test.
The issuing of the Call Gap and Activity Test
operations does not cause state transitions in the SCME. The procedures
for the rest of the above operations are described below.
The
operations that are not listed above do not affect the state of the
SCME; these operations are passed to the relevant SCSM.
The following event is considered in this state:
In this state, the SCF is waiting for the service filtering response from the SSF. The following events are considered in this state:
When Service Filtering is active, another Service Filtering operation could be sent to the SSF that has the same filtering criteria; this second "filter" replaces the first one.
The RCO is part of the SCF Management Entity that controls data
relevant to resource information.
The RCO consists of:
For the purposes of this ETS, no implementation constraints are placed on the structure. The only requirement to the structure is that, for each supported resource, it:
The following three methods are defined for the RCO:
Figure 17 shows the general State Diagram of the SCSM as relevant to
the procedures concerning the SCF FSM part of the SCP/AD/SN during the
processing of an IN call. Each state is discussed in one of the
following subclauses. Each state, except Idle, SDF Request
Idle and Waiting for SDF Response, has internal sub FSMs
composed of the sub-states.
General rules applicable to more than
one state are as follows:
In every state, if there is an error in a
received operation, the SLP and the maintenance functions are informed.
Generally, the SCSM remains in the same state, however, different error
treatment is possible in specific cases as described in subclause 7.2.
Depending on the class of the operation, the error can be reported to
the SSF, SRF, or SDF (see ETS 300 287 [11] (ITU-T Recommendation
Q.774)).
It also holds that, in every state, if the SCSM is
informed that the dialogue with the SSF is terminated, then it informs
the SLP and returns to the Idle state. In this case, all resources
allocated to that call, including those required for relevant dialogues
with the other functions, shall be de-allocated. To simplify the
diagram, such transitions are not demonstrated in the figures.
When
the SLP requests call information, the SCSM transmits the Call
Information Request operation to the SSF, and then Call
Information Report is outstanding.
In any State (except Idle),
the SCSM may receive the Call Information Report operation from
the SSF, when the Call Information Report is outstanding.
Other pending requests that are treated in the same way as the Call
Information Request is the Apply Charging when the "SendCalculationToSCPIndication"
parameter is set to True.
Figure 17: SCSM FSM
From any State (except Idle), if Call Information Report
is outstanding and the SLP indicates that the processing has been
completed, the SCSM remains in the same state until it receives the Call
Information Report operation.
The general rules for one or a
sequence of components sent in one or more TCAP messages, which may
include a single operation or multiple operations, are specified in
subclause 7.1.1.5 and are not described here.
The SCSM has an
application timer, TSCF-SSF, whose purpose is to reset the timer TSSF,
which is used to prevent excessive call suspension time and to guard the
association between the SSF and the SCF.
Timer TSCF-SSF is set in
the following cases:
In all three cases, TSCF-SSF may respectively have three different
values as defined by the application. The value of TSCF-SSF are smaller
than the respective value of TSSF.
When receiving or sending any
other operation, the SCF should reset TSCF-SSF. In the "Waiting
for Notification or Request" state (see subclause 7.1.2.5.2.3),
TSCF-SSF is not used.
The SCSM also has an application timer,
TASSIST/HAND-OFF, whose purpose is to prevent excessive assist/hand-off
suspension time. The SCSM sets the timer TASSIST/HAND-OFF when the SCSM
sends the Establish Temporary Connection or Connect
operation with a correlation ID. This timer is stopped when the SCSM
receives the Assist Request Instructions operation from the
assisting/handed-off SSF. On expiration of TASSIST/HAND-OFF, the SCSM
informs SL and the maintenance functions, and the SCSM transits to the
Idle state (in case of Hand-off) or to the Preparing SSF
instructions state (in case of assist).
The SCSM has an
additional application timer, TActTest, which guards a dialogue and the
related resources. This timer is set at the beginning of a dialogue. The
timer expiration causes a check of the dialogue and the related
resources at the SSF/SCF via the operation ActivityTest (refer to the
detailed procedure of that operation). In case of successfull processing
of that operation the timer is reset.
The call-control-related
operations relevant to the SCF-SSFinterface (except the SCME related
operations) are categorized into
Call-processing-related operations are grouped into the following two sets:
and
For the first set of call-processing-related operations, the SCF may
not send two operations of the same set in a series of TCAP messages or
in a component sequence to the SSF, but send them only one at a time.
Two operations of the first set shall be separated by at least one EDP-R
message received by the SCSM. The same applies for any operation of the
first set followed by ConnectToResource or EstablishTemporaryConnection.
The non-call-processing operations include the rest of the operations
at the SCF-SSF interface (but not the SCME related operations). When the
SL needs to send operations in parallel, they are sent in the component
sequence.
In what follows, each state is described in a separate
subclause together with the events that cause a transition out of this
state. The outputs are presented within smaller rectangles than the
states are; unlike the states and events, the outputs are not
enumerated.
The following events are considered in this state:
Both events cause a transition to State 2, Preparing SSF Instructions.
Section 7 Procedures Contents Page Next Section
