7.1.3.1 General
7.1.3.2 Model and Interfaces
FSM and Maintenance Functions/Bearer Connection Handling">7.1.3.3 Relationship between the SRF FSM and Maintenance Functions/Bearer Connection Handling
7.1.3.4 The SRF Call State Model (SRSM)
7.1.3.4.1 State 1: "Idle"
7.1.3.4.2 State 2: "Connected"
7.1.3.4.3 State 3: "User Interaction"
7.1.3.5 Example SRF Control Procedures
7.1.3.5.1 SRF Connect Procedures
7.1.3.5.2 SRF End User Interaction Procedures
7.1.3.5.3 SRF Disconnection Procedures
7.1.3.5.4 Examples Illustrating Complete User Interaction Sequences
This subclause provides the definition of the SRF AE procedures
related to the SRF-SCF interface. The procedures are based on the use of
SS No. 7; other signalling systems may also be used.
Other
capabilities may be supported in an implementation-dependent manner in
the IP, SSP 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.
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 3.3 and 3.4 shall be
followed.
The functional model of the AE-SRF is shown in figure 22; the ASEs interface to TCAP (to communicate with the SCF) as well as interface to the maintenance functions. The scope of this ETS is limited to the shaded area in figure 22.
Figure 22: Functional Model of
SRF AE
The interfaces shown in figure 22 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 SRF FSM and the maintenance
functions is an internal interface and is not subject for
Standardization in CS1.
The relationship between the Bearer
Connection Handling and the SRF FSM may be described as follows for the
case of a call initiated by the SSF: When a call attempt is initiated by
the SSF, an instance of an SRF FSM is created.
The SRF FSM handles
the interaction with the SCF FSM and the SSF FSM.
The management
functions related to the execution of operation received from the SCF
are executed by the SRF Management Entity (SRME). The SRME interface the
different SRF Call State Models (SRSMs) and the FEAM. Figure 23 shows
the SRF FSM structure.
Figure 23: SRF FSM Structure
The model associates a FSM with each initial interaction request from
the SCF. Thus, multiple initial requests may be executed concurrently
and asynchronously by the SRF, which explains the need for a single
entity that performs the tasks of creation, invocation, and maintenance
of the SRSM objects. This entity is called the SRF Managing Entity
(SRME). In addition to the above tasks, the SRME maintains the dialogues
with the SCF and SSF on behalf of all instances of the SRSM. In
particular, the SRME:
Finally, the FEAM relieves the SRME of low-level interface functions. The FEAM functions include:
The SRSM is presented in figure 24. In what follows, each state is
described in a separate subclause together with the events that cause a
transition out of this state. Finally, the outputs are presented within
smaller rectangles than the states are; unlike the states and events,
the outputs are not enumerated.
Each state is discussed in the
following subclauses. General rules applicable to more than one state
are addressed here.
One component or a sequence of components
received in one or more TCAP messages may include a single operation or
multiple operations, and it is processed as follows:
In any state, if there is an error in a received operation, the
maintenance functions are informed. Generally, the SRSM remains in the
same state in which it received the erroneous operations, 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 SRF to the SCF using the appropriate component (see
ETS 300 287 [11] (ITU-T Recommendation Q.774)).
In any state, if
the dialogue with the SCF (direct SCF-SRF case) is terminated, then the
SRSM returns to Idle state after ensuring that all resources
allocated to the dialogue have been de-allocated.
The SRF shall
remain connected to the SSF as long as it has PA operations active or
buffered. The resources allocated to the call will be de-allocated when
all announcements are completed or when the SSF disconnects the bearer
connection (i.e. call party release).
In any State (except Idle),
if the SSF disconnects the bearer connection to the SRF before the SRF
completes the user interaction, then the SRSM clears the call and
ensures that all SRF resources allocated to the call have been
de-allocated. Then it transits to the Idle state.
The SRSM
has an application timer, TSRF, whose purpose is to prevent excessive
call suspension time. This timer is set when the SRF sends Setup
Response bearer message to the SSF (SSF relay case) or the Assist
Request Instructions operation (Direct SCF-SRF case). This timer is
stopped when a request is received from the SCF. The SRF may reset TSRF
on transmission of the Specialized Resource Report operation or
the Return Result for the Prompt and Collect User Information operation
when there is no queued User Interaction operation. On the
expiration of TSRF, the SRSM transits to the Idle state ensuring
that all SRF resources allocated to the call have been de-allocated.
The Idle state represents the condition prior to, or at the completion of, an instance of user interaction. This state is entered as a result of events E3, e4, E10, e11 and e12. It is exited as a result of event E1.
This state represents the condition of the SRSM when a bearer channel has been established between a user and the SRF but the initial PA/P&C has not yet been received (e.g. when Establish Temporary Connection procedures are used). The method used to provide this bearer channel is not of interest in the FSM.
The User Interaction state indicates that communication is occurring between the user and the SRF via the bearer channel established at the Connected state. This state is entered as a result of event E2. It is exited as a result of events E10, e11 and e12. Events E5, E6, e7, e8 and e9 do not cause a state change. Event E5 also represents additional PA/P&C operations which are buffered as discussed in the procedures.
In addition to these explicitly marked transitions, failure of a user-SRF bearer connection will cause the SRSM to transit to Idle from any state. These transitions are not shown in figure 24 for the purpose of visual clarity.
This subclause provides a detailed description of the SRF
procedures. Arrow diagrams are used for the description of the connect,
interaction with the end user, and disconnect stages.
The SRF
control procedures are based on various physical allocation patterns of
SRF. The various control procedures are described in this subclause in
accordance with the example physical scenarios of protocol architecture
in subclause 4.1.
The Service Assist and Hand-off procedures based
on the physical scenarios are also described in this subclause as
examples.
Several procedures are required for different physical scenarios. The cases to be covered are described below and illustrated in figure 25:
Figure 25: Physical scenarios
In each of the above cases, the operations between the SCP and the SSP
may be SS No. 7 TCAP-based; the messaging between the SSP and the IP
when the SSP does relaying may be DSS1 using the Facility IE (in this
case, the SSP would have to do protocol conversion from SS No. 7 TCAP to
DSS1 Facility IE for the operations and responses it relayed between the
SCP and the IP); the direct messaging between the SCP and the IP may be
SS No. 7 TCAP based; and bearer control signalling may be any system.
Each of the scenarios will now be examined using arrow diagrams.
Case i) is illustrated in figure 26. Note that for the
integrated IP/SSP, the internal activities of the node can still be
modelled in this way, but the details of how this is achieved are left
to the implementor. This approach makes it unnecessary for the SCP to
distinguish between integrated and external but directly connected IPs.
See also a note on the possibility of concatenating the first user
interaction operation with the Connect to Resource operation
discussed in the subclause on user interaction below. The establishment
of the SCF-SRF relationship in this case is implicit.
Figure 26: Connection to
integrated or external IP with SSP relay of IP operations
Case ii) requires that the IP indicate to the SCP that it is
ready to receive operations. The establishment of the SCF-SRF
relationship is explicit. Note that it is necessary to convey a
Correlation ID to ensure that the transaction established between the
SCP and the IP can be correlated to the bearer connection setup as a
result of the preceding operation of the SCP to the SSP.
Figure 27: Connection to IP with Direct
Link to SCP, IP Initiates Interaction with SCP
Case iii) requires that a transaction be opened with the
Assisting SSP so that it may relay operations from the SCP to the IP
(integrated or external). Once the bearer control signalling has reached
the assisting SSP, it triggers on the identity of the called facility,
and initiates an interaction with the SCP that has requested the
assistance (it would also be possible to trigger on other IEs such as
the incoming address). The bearer control signalling shall contain
information to identify the SCP requesting the assistance, and a
Correlation ID. This information may be hidden in the address
information in such a way that non-message based signalling systems may
also be used to establish the bearer connection to the assisting SSP.
After the Assist Request Instructions is received by the SCP,
the procedures are the same as case i. Figure 28 illustrates the
preamble involved.
Figure 28: Preamble for Assist
Case with integrated IP or external IP and SSP relay of SCP-IP messages
Case iv) does not require the establishment of a second
transaction from the assisting exchange, hence it need not be an SSP.
This then becomes a preamble to the procedure shown in figure 27 as
shown in figure 29.
Figure 29: Preamble for Assist
Case with external IP and direct SCP-IP messaging
Case v) merely requires the sending of an operation to the
first SSP to route the call to the handed-off SSP, and then figure 26
applies at handed-off SSP. This is shown in figure 30. Note that the
activity at handed-off SSP represents a new interaction with the SCP and
"Assist Request Instructions" is used. Once the bearer
control signalling has reached the assisting SSP, it triggers on the
identity of the called facility, and initiates an interaction with the
SCP that has requested the assistance (it would also be possible to
trigger on other IEs such as the incoming address). The bearer control
signalling shall contain information to identify the SCP requesting the
assistance, and a Correlation ID. This information may be hidden in the
address information in such a way that non-message based signalling
systems may also be used to establish the bearer connection to the
assisting SSP.
Figure 30: Preamble for Hand-off Case
The End User Interaction procedures allow:
There are only two physical scenarios for user interaction:
Case i) is illustrated in figure 31 below.
Figure 31: SSP Relay of User Interaction Operations and Responses
Case ii) is illustrated in figure 32 below.
Figure 32: Direct SCF-SRF of User Interaction Operations and Responses
It is also necessary to consider the capability of SS No. 7 TCAP to concatenate several Invoke PDUs in one message. This capability allows, for the scenario in figure 26, the Connect to Resource and the first PA/P&C to be carried in one message. This has some advantages in this physical scenario, such as reduced numbers of messages, and possibly better end-user perceived performance.
The disconnection procedures are controlled by the SCF and the
procedure used is selected based on the needs of the service being
executed. The bearer disconnection procedure selected by the SCF is to
either allow the SRF to disconnect on completion of user interaction, or
to have the SCF explicitly order the SSF to disconnect.
SRF
disconnect does not cause disconnection by the SSF/CCF back to the end
user terminal unless the transaction with the SCF has been terminated,
indicating the user interaction completed the call. The SSF/CCF
recognizes that a connection to an SRF is involved because the
operations from the SCF for this purpose are distinct from the
operations that would be used to route the call towards a destination.
There is no impact on bearer signalling state machines as a result of
this since incoming and outgoing bearer signalling events are not simply
transferred to each other, but rather are absorbed in call processing,
and regenerated as needed by call processing. Therefore, to achieve the
desired functionality, call processing need simply choose not to
regenerate the disconnect in the backward direction. Figure 33
illustrates this concept.
Figure 33: Relationship of Incoming and Outgoing Signalling Systems to Call Processing
As for the SRF connection procedures, the SRF disconnection is
affected by the physical network configuration.
In order to
simplify the interface between the SCF and the SRF, a number of
assumptions are made. The assumptions, and the resulting rules, result
in unambiguous procedures from both the SCF and the SRF points of view.
The rules, presented below, refer to the SRF originated disconnect, or
"SRF Initiated Disconnect", and to the SCF originated
disconnect, or "SCF Initiated Disconnect". While other
scenarios are possible, they are not included because they either
duplicate the functionality presented below or they otherwise do not add
value from a service perspective:
The SRF disconnect procedure is illustrated in figure 34. The SRF
disconnect is enabled by the SCF within a PA/P&C operation.
When the SRF receives a PA/P&C enabling disconnection, it
completes the dialogue as instructed by the PA/P&C, and then
initiates the SRF initiated disconnection using the applicable bearer
control signalling. The SSF/CCF knows that it is an SRF disconnecting
and does not continue clearing the call toward the end user. The SSF
returns to the "Waiting for Instructions" state and
executes any buffered operations. In the Hand-off case, the SSP shown in
figure 34 is the "handed-off" SSP.
For the Assisting SSF
case, the SRF initiated disconnect procedures are not used because the
Assisting SSF remains in the "Waiting for Instructions"
state and does not propagate the disconnection of the bearer connection
to the Initiating SSF. The SCF initiated disconnect procedures described
in the following subclause are used for the Assisting SSF case.
For
the Direct SCF-SRF case, the procedures also work in the same manner.
The SRF disconnect is enabled by the SCF within a PA/P&C
operation. When the SRF receives a PA/P&C enabling
disconnection, it completes the dialog as instructed by the PA/P&C,
and then initiates the SRF initiated disconnection using the applicable
bearer control signalling. The Initiating SSF/CCF knows that it is an
SRF disconnecting and does not continue clearing the call toward the
end user. The Initiating SSF returns to the "Waiting for
Instructions" state and executes any buffered operations.
Figure 34: SCF Disconnect for Local, Embedded and Hand-off Scenarios
The SCF initiated disconnect procedure is illustrated in figure 35
(bearer messages are shown with dotted lines). The figure shows only
the Assisting SSF case, and the Direct SCF-SRF case is not shown. To
initiate the SCF initiated disconnection of the SRF, the SCF shall
request and receive a reply to the last PA/P&C operation
requested. The Specialized Resource Report operation contains
an "announcement complete" and Return Result for P&C
contains "collected information."
The SCF initiated
disconnect uses an operation called Disconnect Forward Connection.
Once the Disconnect Forward Connection operation is received by
the SSF, it will initiate a "release of bearer channel connection"
between the PEs containing the SSF and SRF, using applicable bearer
control signalling. Since the SCF (which initiates the disconnect), the
SSF (which instructs bearer signalling to disconnect) and the SRF
(which receives disconnect notification via bearer signalling) are
aware that disconnect is occurring, they are synchronized. Therefore, a
"pre-arranged" end may be used to close the transaction. This
does not preclude the use of explicit end messages for this purpose.
For Assisting SSF case, the initiating SSP, on receipt of the
Disconnect Forward Connection from the SCP, disconnects forward to the
assisting SSP, and this disconnection is propagated to the IP. The
initiating SSP, knowing that the forward connection was initiated as
the result of an Establish Temporary Connection, does not disconnect
back to the user but returns to the "Waiting for Instructions"
state.
Figure 35: SCF Initiated Disconnect for Assist Scenario
The following figures and their accompanying tables provide examples of complete sequences of user interaction operations covering the three stages:
Figure 36: SSP with
integrated SRF
In figure 36 above, the SSP with an integrated
(or embedded) SRF, the procedural scenarios can be mapped as given in
table 4.
Table 4
A simple
extension to this integrated case is the configuration where the SRF is
located in an Intelligent Peripheral locally attached to the SSP. The
SCP-IP operations are relayed via the SSF in the SSP. This is depicted
in figure 37.
Figure 37: SSP Relays Messages
Between SCP and IP
The procedural scenarios for this Relay SSF
with an IP (figure 37) can be mapped as shown in table 5.
Table 5
In some cases,
the IP may have an SS No. 7 or other interface to the controlling SCP.
This case is shown in figure 38. Note that the SCP shall correlate two
transactions to coordinate the activities.
Figure 38: Direct SCP-IP
Information Transfer
In figure 38, the procedural scenarios
can be mapped as shown in table 6.
Table 6
The Assisting
SSF scenario involves straightforward procedural extensions to the basic
cases shown above. One mapping of the assisting SSF case is shown in
figure 39. In this case, SRF initiated disconnect cannot be used. Other
physical mappings can be derived as described in the text following the
figure and its accompanying table.
Note that the integrated SRF and
SSF relay case requires a transaction between the SCP and the assisting
SSP (figure 39) but the SCP direct case does not since the transaction
is directly between the SCP and the IP connected to the remote exchange.
In the latter case, any transit exchanges, including the one the IP
(SRF) is connected to, are transparent to the procedures.
Note also
that the SCP shall again correlate two transactions.
Figure 39: SSP Assist/Hand-off
(Relay SSP)
In figure 39, the procedural scenarios can be
mapped as shown in table 7.
Table 7
Note that the
Assisting SSP case shown in figure 39 can be generalized to cover both
the case where the SRF is embedded in Assisting SSP (as shown), and the
case where the SRF is locally connected to Assisting SSP. In this latter
case, the SRF communication (protocol flows B, C, G, and H) would
conform to the physical scenario shown in figure 37.
The service
hand-off scenario can similarly be viewed as a sequence consisting of an
IN service to route a call from one SSP to another, followed by any one
of the previously described physical user interaction scenarios. For
describing this scenario, figure 39 can be used also.
The following subclause provides additional details on the message sequences for the service assist procedure in figure 39:
The following subclause outlines message sequences for the Hand-off procedure using the protocol flows shown in figure 39:
The same service assist and hand-off procedures can be reused for a direct link to an IP in this and future capability sets.
Section 7 Procedures Contents Page
