home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD2.mdf
/
ccitt
/
1992
/
q
/
q775.asc
< prev
next >
Wrap
Text File
|
1991-12-31
|
79KB
|
1,403 lines
The drawings contained in this Recommendation have been done in Autocad.
Recommendation Q.775
GUIDELINES FOR USING TRANSACTION CAPABILITIES
(Melbourne, 1988)
1 Introduction
1.1 General
The purpose of this Recommendation is to provide guidelines to potential
users of Transaction Capabilities (TC-users). The examples given are
illustrations only; they indicate how an application may use TCAP, not how TCAP
must be used in all cases. The technical basis of this document are
Recommendations Q.771 to Q.774; in case of misalignment, these should be
considered as the primary reference.
The main purpose of TCAP is to provide support for interactive
applications in a distributed environment. TCAP is based on Recommendations X.219
and X.229 (ROSE) enhanced as necessary to provide the services needed by
TC-users. Interactions between distributed application entities are modelled by
Operations. An operation is invoked by an (originating) entity: the other
(destination) entity attempts to execute the operation and possibly returns the
outcome of this attempt.
The semantics of an operation (represented by its name and parameters) is
not relevant to TCAP; TCAP provides facilities which are independent of any
particular operation. The TC-user, when defining an application, must:
1) select operations;
2) select TCAP facilities to support these operations. Such facilities
include the handling of individual operations, and the ability to have
a number of related operations attached to an association between
TC-users, called a dialogue;
3) define the application script.
This Recommendation describes the selection process of defining and using
operations. The operations appearing hereafter are fictitious, and are taken for
illustration purposes only. Also described are the facilities offered by TCAP for
handling one or a sequence of operations in a dialogue. The definition of
specific sequences of operations belongs to the application protocol definition
and is beyond the scope of this Recommendation; however, Chapter 4 gives a brief
indication of what information an application specification should contain.
TCAP services are made accessible to TC-users via primitives; these
primitives model the interface between TCAP and its users, but do not constrain
any implementation of this interface.
1.2 Environment
TCAP defines the end-to-end protocol between TC-users which may be located
in a Signalling System No. 7 network, and/or another network supporting TCAP
protocols.
Two broad categories of users have been considered (see Recommendation
Q.771, S 1.3.2). Only the first category is considered here, i.e. those which are
real-time sensitive users, and do not need to exchange large amounts of data. It
is considered that for these users, protocols defined for OSI layers 4 to 6 in
the X series of Recommendations would result in excessive overheads and hence are
not used. A basic service has been specified, using a connectionless network
service approach. Other categories of users might require connection-oriented
network and higher layer services.
Recomme
Recommendation indicates what the connectionless approach cannot do, in order to
help the application designer choose how to support an application.
2 Operations
2.1 Definition
An operation is invoked by an originating TC-user to request a destination
TC-user to perform a given action.
A class is attached to an operation. This indicates whether either a
successful outcome (result), or an unsuccessful outcome (error), or both, or none
have to be reported by the destination. The outcome is reported in a result.
As well as the class, the definition of the operation includes a timer
value indicating when the operation should be completed. This value is not
indicated to the remote TC-user; it is assumed that the application at both ends
has a common understanding of the operations in use.
An operation is defined by:
Fascicle VI.9 - Rec. Q.775 PAGE101
- its operation code and the type of any parameters associated with the
operation request;
- its class;
- if the class requires report of success, the possible results
corresponding to successful executions are defined by a list of
parameters;
- if the class requires report of failure, the possible results
corresponding to situations where the operation could not be executed
completely by the remote TC-user. Each such situation is identified by
a specific error cause; the list of these error causes is part of the
operation definition. Diagnostic information can be added to the error
cause: if present, it is part of the definition;
- the list of possible linked operations, if replies consisting of linked
operations are allowed for this operation. Linked operations have to be
described separately;
- a timer value indicating the interval by which the operation has to be
completed. This timer value is used to manage the component ID
associated with the operation invocation.
2.2 Examples
2.2.1 Simple operations
Note - The operation invocation should fit into one message, and so should
a report of unsuccessful outcome. Reports of success may be segmented using
Return Result-Not last and Return Result-Last.
Class 1 (both success and failure reported):
Translate a freephone number into a called subscriber number; return the
called number if the translation can be performed, otherwise indicate why it
cannot; time allocated: 2 seconds.
No reply being received when the timer expires indicates an abnormal
situation (e.g. the operation invocation may have been lost): the local TC-user
is informed (operation cancel by TCAP).
Class 2 (only failure reported):
Perform a routine test and send a reply only in case something went wrong;
time allocated: 1 minute.
In the case of a class 2 operation, the TC-user is informed if no result
has been received when the timer expires. This is interpreted as a successful
outcome, even if the invocation was lost. This aspect should be considered when
selecting class 2.
Class 3 (only success reported):
Perform a test: this corresponds to a pessimistic view, where failure is
considered as the default option, not requiring any reply.
Timer expiry is indicated to the TC-user: this should be interpreted by
the TC-user as a failure of the operation (but is considered normal by TC, which
considers that the operation has terminated). This aspect should be considered
when selecting class 3.
Class 4 (neither success, nor failure reported):
Send a warning, without expecting a reply or acknowledgement of any kind.
In this case, a result never arises from the invocation of the operation.
The TC-user relies upon TCAP and the network to deliver the invocation.
Notification of the timer expiry is a local matter.
The diagrams in Figure 1/Q.775 illustrate possible sequences of primitives
as seen by the TC-user originating an operation.
PAGE118 Fascicle VI.9 - Rec. Q.775
Fig. 1/Q.775 /T1120760-88 = 25 cm
Comparison with ROSE (Recommendation X.219) operation classes:
ROSE provides for five classes of operations: classes 2 to 5, called
asynchronous classes, are identical to classes 1 to 4 of TCAP. ROSE's class 1 is
a synchronous class; it has no counterpart in TCAP, where full-duplex exchanges
of components are considered. However, a TC-user can decide to operate in a
synchronous manner (see S 3.2.1).
2.2.2 More sophisticated operations
Operations with segmented results
A successfull result may be divided into several segments, each of which
is indicated to the originator of the operation by one primitive. This facility,
using the TC-RESULT-NL primitive, can be used by TC-users to overcome the absence
of segmentation in the underlying layers. The last segment is indicated by the
TC-RESULT-L primitive.
The report of an error cannot be segmented.
Apart from abnormal situations, responses are delivered to the remote
TC-user in the order in which they have been passed to TCAP by the sending
TC-user.
TC cannot identify a specific segment in the case of a segmented result.
Example E1: An operation requests the execution of a test. The result of a
correct execution is segmented in three parts P1, P2 and P3 to be returned to the
originator.
A possible primitive sequence for example E1 is given in Table 1/Q.775
TABLE 1/Q.775
TC USER A TC USER B
TC-INVOKE req TC-INVOKE ind
(Test, Class = 1) (Test)
TC-RESULT-NL req
(P1)
TC-RESULT-NL ind TC-RESULT-NL req
(P1) (P2)
TC-RESULT-NL ind TC-RESULT-L req
(P2) (P3)
TC-RESULT-L ind
(P3)
Time
The diagram in Figure 2/Q.775 illustrates possible sequences of primitives
seen by the originator of an operation (class 1) with segmented results.
Fig. 2/Q.775 /T1120770-88 = 13 cm
Linked operations
Another extension to the basic operation scheme is the ability to link an
operation invocation to another operation invocation.
Typically, this facility covers situations where the destination of the
original (linked-to) operation requires additional information in order to
process this operation: this is the case where menu facilities are used (menu
facilities allow a user to make a sequence of choices, each being dependent on
the previous ones).
Example E2: The operation is the execution of a test with several options;
before the test is executed, these options are offered for selection to the test
originator (TC-user A). Two operations are nested: operation 1 is the test;
operation 2 is the option selection. TC-user A first responds to operation 2
before TC-user B can perform the test with the indicated option(s).
A possible primitive sequence for example E2 is given in Table 2/Q.775.
TABLE 2/Q.775
TC USER A TC USER B
TC-INVOKE req Operation 1 begin
(Test, Class = 1) TC-INVOKE ind
(Test)
TC-INVOKE req Operation 2 begin
(Option-selection,
Class = 1)
TC-INVOKE ind
(Option-selection)
TC-RESULT-L req TC-RESULT-L ind Operation 2 end
(Options) (Options)
TC-RESULT-L req
(Test-result)
TC-RESULT-L ind Operation 1 end
(Test-result)
Time
Fascicle VI.9 - Rec. Q.775 PAGE101
There is no limit to the number of operation invocations which may be
linked to a given operation invocation.
Note that when an operation B is linked to another operation A, they do
not have to be nested. The only condition is that the invocation of B should take
place before the outcome of A is reported; however, operation B does not have to
terminate before operation A.
2.3 Component-related facilities offered to TC-users
2.3.1 Invocation
So far, operations have been considered from the static point of view.
Invocation introduces a dynamic aspect: a specific invocation of an operation has
to be differentiated from other possible concurrent invocations of the same or of
another operation.
Each particular activation of an operation is identified by a component
ID. This component ID must be non ambiguous. It is selected by the TC-user which
originates the operation invocation, and passed to the destination TC-user, which
will reflect it in its reply(ies): therefore it correlates the replies to an
invocation, and the invocation itself.
The TC-user is free to assign any value to the component ID (index,
address, . . .).
The component ID associated with an invocation becomes reusable when the
last or only segment of a result is received, or when certain abnormal situations
are indicated by TCAP; however, the value should not be reallocated immediately
for another operation activation, as immediate reallocation would prevent the
correct handling of some situations (see below).
The period during which a component ID is released, but cannot be
reallocated, is called the freezing period.
As component IDs receive their value dynamically at the time the operation
is invoked, their value cannot appear in the specification of the application
protocols; rather, a "logical" value, to which a real value is substituted at
execution time, should be indicated in order to identify an operation in a single
flow.
Taking component IDs into consideration, the sequence of primitives for
example E2 above becomes as shown in Table 3/Q.775.
TABLE 3/Q.775
TC USER A TC USER B
TC-INVOKE req
(1, Test, Class = 1) TC-INVOKE ind
(1, Test)
TC-INVOKE req
(2, 1, Option-selection,
Class = 1)
TC-INVOKE ind
(2, 1, Option-selection)
TC-RESULT-L req TC-RESULT-L ind
(2, Options) (2, Options)
TC-RESULT-L req
(1, Test-result)
TC-RESULT-L ind
(1, Test-result)
Time
where the first parameter of a primitive indicates an invoke ID. When both
parameters have to be present, the second one is the linked ID. This is a pure
notational convention.
2.3.2 Cancel (by the TC-user)
The TC-user requesting invocation of an operation may stop the activity
associated with the corresponding component ID, for any reason it finds
appropriate. However, cancel should in principle be reserved for abnormal
situations: the normal method for terminating an operation is to receive a result
or to terminate on timer expiry.
Cancelling has local effect only: it does not prevent the remote TC-user
from sending replies to a cancelled operation. When received, these replies will
be rejected by TCAP, as illustrated in the following, which represents a sequence
PAGE118 Fascicle VI.9 - Rec. Q.775
of primitives for the example E1 defined above, where TC-user A cancels the test
after receiving the first segment of the result.
In Table 4/Q.775, part P2 is not received by TC-user A: TCAP detects a
reject situation before delivering it, and any attempt by TC-user B to send more
replies is rejected at A's side.
TABLE 4/Q.775
TC USER A TC USER B
TC-INVOKE req
(1, Test, Class = 1) TC-INVOKE ind
(1, Test)
TC-RESULT-NL req
(1, P1)
LTC-RESULT-NL ind
(1, P1)
Cancel decision:
TC-CANCEL req TC-RESULT-NL req
(1) (1, P2)
TC-L-REJECT ind
(1, Problem Code) ....
....
Time
2.3.3 Reject (by the TC-user)
A TC-user may decide to reject a component for any reason it finds
appropriate, e.g. application protocol error, parameter missing in an operation
or a reply, etc.
TCAP covers a number of cases, identified by the list of Problem Codes in
Recommendation Q.773. In any of these cases, which correspond to situations where
an operation or a reply is not correctly formatted, the TC-user may use the
reject facility. Alternately, he may decide to return a failure indication (error
component), which allows more detailed error and diagnostic information.
operati
operation: no more replies will be accepted for this invocation. Reject of a
linked operation does not affect the linked-to operation.
This is illustrated in Table 5/Q.775 where, in example E2, TC-user A did
not expect the option selection process (it may be an optional feature), and
rejects the operation with the Problem Code "Unexpected Linked Operation".
TC-user B may then decide to execute the test assuming a default option.
TABLE 5/Q.775
TC USER A TC USER B
TC-INVOKE req
(1, Test, Class = 1) TC-INVOKE ind
(1, Test)
TC-INVOKE req
(2, 1, Option-selection,
Class = 1)
TC-INVOKE ind
(2, 1, Option-selection)
TC-U-REJECT req
(2, Problem Code)
TC-U-REJECT ind
(2, Problem Code)
TC-RESULT-L req
(1, Test-result)
TC-RESULT-L ind
(1, Test-result)
Time
Fascicle VI.9 - Rec. Q.775 PAGE101
reinvok
reinvoke it (e.g. the invoke component was corrupted); this would be a new
invocation (new Invoke ID). It may also decide to abort the dialogue. A very
simple dialogue (a question and a response) may not define any recovery
mechanisms, except when the operation is of critical importance (e.g. a database
update).
2.4 ComponentVrelated abnormal situations
2.4.1 Component loss
TCAP assumes a very low probability of message loss in the network; if
this probability is too high for an application, it should use the
connectionVoriented network service approach. If some protocol information needs
an upgraded quality of service (e.g. charging information), the application
should introduce its own mechanisms to obtain higher reliability for this
information.
Loss of an operation invocation
The Table 6/Q.775 sequence illustrates the case, in example E1, where no
response to the test is received before the time limit expires.
TABLE 6/Q.775
TC USER A TC USER B
TC-INVOKE req
(1, Test, Class = 1)
Time limit:
TC-L-CANCEL ind
(1)
Time
When a class 1 operation is lost, the TC-user is informed when the timer
asociated with the operation expires. When a class 1 operation with a single
result is lost, TCAP cannot indicate whether either the operation invocation, or
the reply, was lost. If the application needs to discriminate between these two
cases, it should do it in the application protocol (e.g. using the time-stamping
or acknowledging the operation invocation before replying to it).
For a class 2 operation, loss will be considered as a success (whether the
invocation, or the failure report, was lost). This, considering the probability
of loss, may be acceptable for non critical operations (e.g. statistical
measurements).
failu
failure, whether the invocation, or the success report, has been lost.
For a class 4 operation, loss will not be visible to TCAP.
Loss of a result
- Loss of a non final result is never detected by TCAP.
- Loss of a final result will eventually be indicated to the TC-user when
the time limit is reached, but cannot always be unambiguously
interpreted as the loss of a reply; of no non final result has been
received, it may be that the invocation was lost.
Loss of a linked operation
The loss of a linked operation has the same effect as the loss of a
non-linked operation. It has no effect on the linked-to operation.
Loss of a reject component
This case should be extremely infrequent, and no application should try to
recover from such a situation. If the lost reject concerns an operation
invocation, then when the operation timed out the TC-user which invoked the
operation will consider that the invocation (or the reply) was lost, and react
accordingly; if it concerns a reply, the originator of the reply will consider
that it was correct: it will be up to the originator of the operation to detect
the loss.
2.4.2 Component duplication
As message duplication is very infrequent in the Signalling System No. 7
network, scripts for No. 7 applications need not define sophisticated scenarios
in anticipation of such situations. However, any application in which duplication
would be unacceptable should either define its own duplication detection
mechanism or use a connection-oriented service.
PAGE118 Fascicle VI.9 - Rec. Q.775
Duplicate operation invocation
When an operation invocation is duplicated (by the service provider), the
destination TC-user (B) may, or may not, detect the duplication:
- TC-user B detects the duplication: the best it can do in this case is
to ignore the duplicate; rejection could be interpreted by the remote
TC-user as rejection of the original invocation;
- TC-user B does not detect the duplication: this may happen when there
is a master-slave relationship between A and B, and B executes the
operation with no knowledge of the context.
Assuming the second case in exaple E1, a possible sequence could be as
given in Table 7/Q.775.
TABLE 7/Q.775
TC USER A TC USER B
TC-INVOKE req
(1, Test, Class = 1) TC-INVOKE ind
(1, Test) Undetected duplication of
TC-INVOKE ind invocation
(1, Test)
TC-RESULT-NL req
(1, P1)
TC-RESULT-NL req
(1, P1)
TC-RESULT-NL ind
(1, P1)
TC-RESULT-NL ind
(1, P1)
A detects an abnormal
situation and rejects:
TC-U-REJECT req TC-RESULT-NL req
(1, Problem Code) (1, P2)
TC detects an abnormal TC-U-REJECT ind
situation and rejects P2: (1, Problem Code)
TC-L-REJECT ind
(1, Problem Code)
TC-R-REJECT ind
(1, Problem Code)
Time
In this sequence, TC-user B considers two independent test invocations,
and responds to each of them. The first result P1 is accepted; TC-user A detects
that P1 is received a second time, and rejects it; this terminates the operation,
and causes result P2 to be rejected when received (reject by TCAP). Therefore,
both activities at B's side will terminate on receipt of rejects.
Duplicate non-final result
If a non-final result is duplicated, TCAP cannot detect it, and will
deliver it twice to the TC-user. Detection of this situation is left to the
application.
Duplicate final result
If a final result is duplicated, TCAP can detect the situation: the second
final result is considered as abnormal (the operation has been terminated by the
first "final" result), and TCAP rejects it.
Table 8/Q.775 shows a sequence for example E1 where the third segment of
the result is duplicated (by the network).
TABLE 8/Q.775
TC USER A TC USER B
TC-INVOKE req
(1, Test, Class = 1) TC-INVOKE ind
(1, Test)
TC-RESULT-NL req
(1, P1)
TC-RESULT-NL ind TC-RESULT-NL req
(1, P1) (1, P2)
TC-RESULT-NL ind TC-RESULT-L req
(1, P2) (1, P3)
TC-RESULT-L ind
(1, P3)
Duplication of P3:
TC-L-REJECT ind
(1, Problem Code)
TC-R-REJECT ind
(1, Problem Code)
Time
Fascicle VI.9 - Rec. Q.775 PAGE101
Comment: Discarding of duplicates in all cases by TCAP would probably
appear as a nicer issue. However, it should be noted that:
1) it would require another degree of complexity in TCAP, which
contradicts the basic characteristics of TCAP in the connectionless
approach;
2) it corresponds to a situation which is extremely infrequent, at least
in the No. 7 network.
To cover these situations when required by an application, it would be
better to use a connection-oriented network service approach, since duplication
could then be detected and handled at the lower layers.
2.4.3 Component missequencing
For TCAP, the order of segmented results is not relevant: if the order is
important to the TC-user, appropriate mechanisms should be defined in the
application protocol (e.g. by introducing a numbering scheme to identify
intermediate replies in a parameter of these replies, or by using a
connection-oriented service).
Due to missequencing, a non final result may arive after a final result:
when this occurs the non final result is rejected by TCAP.
The sequence in Table 9/Q.775 illustrates what happens in example E1 when
the last part of the result is received before the second one: both TC-users are
informed.
TABLE 9/Q.775
TC USER A TC USER B
TC-INVOKE req
(1, Test, Class = 1) TC-INVOKE ind
(1, Test)
TC-RESULT-NL req
(1, P1)
TC-RESULT-NL ind
(1, P1) TC-RESULT-NL req
(1, P2)
TC-RESULT-L req
TC-RESULT-L ind (1, P3)
(1, P3)
Missequenced result:
reject
TC-L-REJECT ind
(1, Problem Code)
TC-R-REJECT ind
(1, Problem Code)
Time
If a linked operation invocation is received after the final result of the
linked-to operation (as a result of a missequencing), the linked operation is
rejected.
TCAP assumes a very low probability of missequencing; if the supporting
network is not satisfactory in this respect, the connection-oriented network
service approach should be considered.
2.4.4 Reject of a component by TCAP
A general principle when TCAP receives a component (operation invocation
or reply) which is either not formatted correctly, or received out of context
(e.g. a reply without a prior operation invocation), is to reject it, which means
that:
1) the destination of the faulty component is first informed of the
situation; TCAP provides whatever information is available on the
nature of the component being rejected
2) in reaction to this, the TC-user may decide to abort, continue, or end
the dialogue. In the last two cases, when the TC-user notifies TCAP of
its decision, the peer TC-user is informed of the reject.
Possible cases of reject by TCAP have been encountered in the previous
sections. Whenever the component ID is recognised, rejection by TCAP causes the
termination of the operation: a possible recovery is a new invocation of the
terminated operation. When the rejected component is not identifiable, only the
local TC-user is informed, and abort of the dialogue may be the appropriate
reaction.
PAGE118 Fascicle VI.9 - Rec. Q.775
2.4.5 Operation timer expiry
t
the most unlikely), an implementationVdependent mechanism avoiding premature
reallocation of component IDs is required.
Timer expiry indication corresponds to an abnormal situation only in the
case of a class 1 operation. The TCVuser is then aware that either the
invocation, or the reply, was lost. If no undesirable side effects arise, another
invocation of the same operation can take place after timer expiry. This is
illustrated by the sequence in Table 10/Q.775 for example E1.
TABLE 10/Q.775
TC USER A TC USER B
TC-INVOKE req
(1, Test, Class = 1) TC-INVOKE ind
(1, Test)
Timer expiry:
TC-L-CANCEL ind
(1)
TC-INVOKE req
(2, Test, Class = 1)
Time
Timer expiry for a class 2 operation indicates that no failure was
received nor will be accepted for this invocation: it is a definite indication of
success (for class 2). A parallel situation applied to class 3 in case of
failure. The indication of timer expiry for a class 4 operation is a local
decision.
3 Dialogues
issu
issued, a request is passed to TCAP, but nothing is sent to the remote TCVuser
until a primitive requesting transmission is issued. These primitives, and their
relation with operation handling primitives, are considered now.
3.1 Grouping of components in a message
The effect of TCVuser issuing a component handling primitive (unless this
primitive has local effect only), is to build a component to be included in a
message. The message is not transmitted until the TCVuser requests it.
Note that a component may also be generated as a result of a TCAP reject:
in this case this component is put in the next message for the dialogue unless it
is aborted.
Provided that the maximum size of a message is not exceeded, several
components can be grouped and sent to the remote end as a single message, thereby
saving transmission overhead. This is done under control of the TCVuser, which
explicitly specifies when it wants (a) component(s) to be sent.
Example E3, as given in Table 11/Q.775, shows the beginning of a dialogue
with a network service centre where a switch requests instructions (operation 1)
and receives a request to connect the call to a given destination address, and a
request to send information (e.g. announcement or message to be displayed) to the
calling party. Both components are contained in a single message.
TABLE 11/Q.775
TC USER A TC USER B
TC-INVOKE req
(1, Provide-Instructions, Class
= 1)
TC-BEGIN req
(control parameters)
TC-BEGIN ind
(control parameters)
TC-INVOKE ind
(1, Provide-instructions)
TC-INVOKE req
(2, 1, Connect-Call)
TC-RESULT-L req
(1, Send-Info)
TC-CONTINUE req
(control parameters)
TC-CONTINUE ind
(control parameters)
TC-INVOKE ind
(2, 1, Connect-Call)
TC-RESULT-L ind
(1, Send-Info)
Time
Fascicle VI.9 - Rec. Q.775 PAGE101
TC-BEGIN and TC-CONTINUE are transmission primitives described in S 3.2
below.
There may be one transmission primitive for each component, but the
separation of primitives allows the grouping of components within a message. In
addition, the information contained in the parameters of the transmission
primitives (e.g. addressing information) applies to all the components included
in the message.
At the originating side, the primitive requesting transmission appears
after a component handling primitive; this indicates that transmission of the
preceeding components has to take place immediately; it avoids indicating
specific components to be transmitted with a given transmission primitive, and
allows transmission primitives without any associated component.
At the destination side, the primitive requesting transmission appears
first: it contains control information which is necessary for TCAP to deliver
each of the components (if any) in the message; the last component of the message
is indicated to the TC-user by the "Last Component" parameter. The components are
delivered to the destination TC-user in the same order as they were passed to
TCAP by the originating TC-user.
3.2 Dialogue handling facilities
When two TC-users co-operate in an application, more than one operation
invocation is generally required. The resulting flow of components has to be
identified so that:
1) components of the same flow can be related
i
identified and allowed to run in parallel.
Each such flow is identified, for the TC-user, by a dialogue and a
corresponding Dialogue ID parameter. The dialogue handling facility provided for
this purpose is the structured dialogue.
When only a single message is required to complete a distributed
application, the Unidirectional message of the unstructured dialogue may be used.
The originator does not expect a report of the outcome of the operation (i.e. may
only invoke class 4 operations), but may receive a report of a protocol error if
one occurs.
3.2.1 Structured dialogue
3.2.1.1 General
The use of dialogues allows several flows of components to co-exist
between two TC-users. The Dialogue ID parameter is used in both operation
handling and transmission (dialogue) handling primitives to determine which
component(s) pertain(s) to which dialogue.
The Dialogue ID parameter is represented (by convention) by the first
parameter in these primitives, starting with letter D. Each TC-user has its own
reference for a given dialogue. Local references (those used on the interface)
are represented here; mapping of these local references onto protocol references
included in messages is done by TCAP.
Three primitives have been defined for handling dialogues under normal
circumstances; they indicate dialogue begin (TC-BEGIN), continuation
(TC-CONTINUE) or end (TC-END). Each of these primitives may be used to request
transmission of 0, 1 or several components; these components may contain
information relating to one or several operations.
Table 12/Q.775 illustrates a possible sequence for example E2, where the
test request starts the dialogue, which ends when the test result has been sent.
TABLE 12/Q.775
TC USER A TC USER B
TC-INVOKE req
(D1, 1, Test, Class = 1)
TC-BEGIN req
(D1, Address)
TC-BEGIN ind
(D2, Address)
TC-INVOKE ind
(D2, 1, Test)
TC-INVOKE req
(D2, 2, 1, Option-selection,
Class = 1)
TC-CONTINUE req
(D2)
TC-CONTINUE ind
(D1)
TC-INVOKE ind
(D1, 2, 1, Option-selection)
TC-RESULT-L req
(D1, 2, Options)
TC-CONTINUE-req
(D1)
TC-CONTINUE ind
(D2)
TC-RESULT-L ind
(D2, 2, Options)
TC-RESULT-L req
(D2, 1, Test-result)
TC-END req
(D2)
TC-END ind
(D1, normal)
TC-RESULT-L ind
(D1, 1, Test-result)
Time
PAGE118 Fascicle VI.9 - Rec. Q.775
Note - D1 and D2 are local references for the same dialogue
and map onto transaction IDs which appear in the messages.
Any grouping of components is allowed in the messages of a dialogue: TCAP
does not check, for instance, that a message terminating a dialogue does not
include operation invocations of class 1. Full-duplex exchange of components is
assumed: if a TC-user wants to introduce some restrictions, e.g. working in a
synchronous mode as defined in ROSE, it would have to introduce the necessary
procedures itself.
3.2.1.2 Exchange of messages
Transmission of messages is accomplished with the quality of service of
the underlying layer services: no flow control or error recovery mechanisms are
provided by TCAP.
- The first dialogue handling primitive of a dialogue must indicate
dialogue begin (TC-BEGIN). Further messages must not be sent from the
side originating the dialogue until a message is received in the
backward direction, indicating dialogue continuation.
- If a TC-user tries to send a large number of messages in a short amount
of time, no flow control mechanism in TCAP will prevent it.
- SCCP class 1 in-sequence delivery can be requested as an option,
indicated by the Quality of Service parameter. Note that this option
may not be available end to end when interworking with a network which
does not provide it.
3.2.1.3 Dialogue end
TCAP places no restriction on the ability for a TC-user to request
dialogue end. It follows that messages may be lost if no precautions are taken in
the application on when the dialogue may end. In particular, if the application
protocol allows both TC-users to issue TC-END primitives at about the same time,
and if these primitives trigger transmission of components, it is likely that
some (if not all) of these components will not be delivered to their respective
destination TC-users.
It is up to the application to define, if necessary, its own rules
concerning the right to end a dialogue: TCAP will not check them. Any message
received for a terminated dialogue is discarded if it requests dialogue end, and
otherwise causes the dialogue to be aborted at the remote entity.
The differences between the three ways of ending a dialogue are as
follows.
Prearranged end
A typical application is the access to a distributed database, where the
requesting user (TC-user A) does not know where the information it seeks is
located. TC-user A broadcasts a request to each location which might have the
information required, and will eventually receive a response from the TC-user
which holds this information. Prearranged end avoids messages from the other
destinations saying: "I do not have this information". Only the responding
destination may continue the dialogue (if so wished); all other destination will,
by convention, end the dialogue locally; the originator of the requests will also
end the dialogues with the non-responding destinations locally, when it receives
the response to its request. Note that the convention is between applications:
TCAP does not check that it is respected, nor is it indicated in the TCAP
protocol.
Example E4 in Table 13/Q.775 illustrates this situation, with two
destinations B1 and B2; two dialogues (D1, D2) and (D3, D4) are started; B1
happens to own the requested information, and decides to continue the dialogue.
Fascicle VI.9 - Rec. Q.775 PAGE101
TABLE 13/Q.775
TC USER A TC USER B1 TC USER B2
TC-INVOKE req
(D1, 1, Question)
TC-BEGIN req
(D1, Address)
TC-INVOKE req TC-BEGIN ind
(D3, 1, Question) (D2, Address)
TC-BEGIN req TC-INVOKE ind
(D3, Address) (D2, 1, Question)
TC-BEGIN ind
TC-RESULT-L req (D4, Address)
(D2, 1, Response) TC-INVOKE ind
TC-CONTINUE req (D4, 1, Question)
(D2) B2 does not have the
...... information:
TC-END req
(D4, local)
TC-CONTINUE ind
(D1)
TC-RESULT-L ind
(D1, 1, Response)
D1 goes on
D3 ends locally
TC-END req
(D3, local)
Time
Prearranged end may also be used when a TC-user wants to send information,
and does not expect a reply of any kind afterwards.
PAGE118 Fascicle VI.9 - Rec. Q.775
Basic end
When a TC-user issues the TC-END request primitive, it causes transmission
of any pending components to the remote end. TCAP does not check that all
operation invocations have received a response when dialogue end is requested: no
notification is given to the TC-user that any pending operation invocations have
not received a final result.
At the receiving end, the dialogue is considered terminated when all the
components received within the message indicating the end have been delivered to
the TC-user.
Example: the dialogue ends when the test in example E1, Table 14/Q.775,
receives a response.
TABLE 14/Q.775
TC USER A TC USER B
..... ......
TC-RESULT-NL req
(D2, 1, P1)
TC-RESULT-NL req
(D2, 1, P2)
TC-RESULT-L req
(D2, 1, P3)
TC-END req
TC-END ind (D2, normal)
(D1) End of dialogue for B
TC-RESULT-NL ind
(D1, 1, P1)
TC-RESULT-NL ind
(D1, 1, P2)
TC-RESULT-L ind
(D1, 1, P3)
End of dialogue for A
Time
Abort by the TC-user
The abort facility allows the TC-user to stop the dialogue at any time. A
typical case is when the user abandons the service. The main differences between
this and normal ending are:
- any components for which transmission is pending are not sent to the
peer entity;
- peer-to-peer information can be indicated at the time the abort is
issued, and this is delivered to the remote TC-user.
The sequence given in Table 15/Q.775 shows a user abandonment in example
E2.
3.2.1.4 Message-related abnormal situations
These are considered independently from the effects of such events in the
Component sub-layer.
Fascicle VI.9 - Rec. Q.775 PAGE101
Message loss
TCAP provides no protection against message loss. Three cases are
identified:
1) the message begins a new dialogue: the dialogue will exist at the
originating side only, and no message will be allowed in either
direction. Eventually, an implementation-dependent mechanism of TCAP
ends the dialogue at the originating end;
2) the message continues an existing dialogue: loss is not detected. TCAP
will react (or not) to the loss of included components as indicated in
S 2.4.1 above;
3) the message ends a dialogue: TCAP will eventually react if this message
contained a response to a class 1 operation: otherwise an
implementation-dependent mechanism may end the dialogue at the
destination end.
TABLE 15/Q.775
TC USER A TC USER B
TC-INVOKE req
(D1, 1, Test, Class = 1)
TC-BEGIN req
(D1, Address)
TC-BEGIN ind
(D2, Address)
TC-INVOKE ind
(D2, 1, Test)
TC-INVOKE req
(D2, 2, 1, Option-selection,
Class = 1)
TC-CONTINUE req
(D2)
TC-CONTINUE ind
(D1)
TC-INVOKE ind
(D1, 2, 1, Option-selection)
User abandon:
TC-U-ABORT req
(D1, Cause)
TC-U-ABORT ind
(D2, Cause)
Time
Message duplication
Duplication of a BEGIN message causes two transactions to be opened, as
indicated below: each of these transactions has its own local ID, and the same
destination ID. The TC-user eventually detects that something is wrong, and both
dialogues are aborted.
The sequence given in Table 16/Q.775 illustrates a duplication of the
BEGIN message in Example E2.
TABLE 16/Q.775
TC USER A TC USER B
TC-INVOKE req
(D1, 1, Test, Class = 1)
TC-BEGIN req
(D1, Address)
TC-BEGIN ind
(D2, Address)
TC-INVOKE ind
(D2, 1, Test)
Duplicated BEGIN:
TC-BEGIN ind
(D3, Address)
TC-INVOKE ind
(D3, 1, Test)
Response to the first
Begin
TC-INVOKE req
(D2, 2, 1, Option-select,
Class = 1)
TC-CONTINUE req
TC-CONTINUE ind (D2)
(D1) Response to the second
TC-INVOKE ind Begin
(D1, 2, 1, Option-select) TC-INVOKE ind
(D3, 2, 1, Option-select,
Class = 1)
TC-CONTINUE req
(D3)
TC-CONTINUE ind
(D1)
TC-INVOKE ind
(D1, 2, 1, Option-select)
TC-user considers that
this invocation is
abnormal, and may reject
it, or abort one of the
dialogues:
TC-U-ABORT req
(D1, Cause)
TC-U-ABORT ind
(D3, Cause)
Time
PAGE118 Fascicle VI.9 - Rec. Q.775
At that moment, there is still one dialogue (with local ID D2) at TC-user
B's side, but no dialogue at A's side. TC-user B will receive an indication from
TCAP when operation 2 of dialogue D2 timeouts with no reply (TC-L-CANCEL ind),
and may then decide to abort D2. Note that the situation would be more difficult
to detect, had TC-user B not invoked a class 1 operation.
Duplication of a CONTINUE message is not detected by TCAP.
When an END message is duplicated, the second message is received with an
ID which does not correspond to an active dialogue: TCAP reacts by discarding the
duplicate message.
Missequencing of messages
When the missequenced messages involve neither the beginning, nor the end
of a dialogue, missequencing is not detected by TCAP, and may result in component
missequencing, to which TCAP would react as indicated in S 2.5.3 above.
When a message indicating dialogue continuation arrives after a message
indicating the end of the same dialogue, it is not delivered, and causes TCAP to
abort the dialogue; the TC-user will probably detect the loss when receiving a
premature dialogue end indication. If the application needs to recover from this
case, a new dialogue should be started.
Message corruption
When receiving a corrupted message, TCAP reacts as indicated in
Recommendation Q.774.
Table 17/Q.775 shows the sequence of primitives when TCAP decides to abort
the dialogue after receiving a corrupted message in example E2.
TABLE 17/Q.775
TC USER A TC USER B
TC-INVOKE req
(D1, 1, Test, Class = 1)
TC-BEGIN req
(D1, Address)
TC-BEGIN ind
(D2, Address)
TC-INVOKE ind
(D2, 1, Test)
TC-INVOKE req
(D2, 2, 1, Option-select,
Class = 1)
TC-CONTINUE req
(D2)
Corrupted message:
TC-ABORT ind
(D1, Cause) TC-ABORT ind
(D2, Cause)
Time
3.2.1.5 Relations between dialogue handling and operation handling
Depending on the moment when the dialogue end is requested, the TCAP
facilities associated with an operation will be available until the end of the
dialogue, or not. The following gives some guidelines on when dialogue end can be
requested; if these are not respected, TCAP will not refuse the request for
dialogue end.
The problems that may result from the collision of messages requesting
dialogue end have been considered above.
Normal end should not be requested when:
- there are operation invocations pending for the dialogue;
- the application protocol anticipates that replies being transmitted
with the termination request could be rejected.
In addition, a request for dialogue end must not trigger transmission of
operation invocations, since no reply could be received for these operations.
Many applications might not define recovery scenarios in response to a
Fascicle VI.9 - Rec. Q.775 PAGE101
rejected reply. This legitimises the transmission of replies or of class 4
operations in a message indicating dialogue end. The other applications should
either use the connection-oriented network service approach, or end the dialogue
with a message containing no component, that would be sent only when a reject
indication can no longer be received.
3.2.2 Unstructured dialogue
A Unidirectional message will contain either only class 4 operation
invocations or reports of protocol errors in such invocations. Multiple
components can be transmitted in a Unidirectional message provided that the
maximum size of a message is not exceeded.
4 Application service elements and application entities
4.1 Introduction
This material supplements preceding material providing guidelines on the
usage of TC by describing what needs to be included in an Application Entity (AE)
specification. This material is based on CCITT Recommendations X.219 and X.229
and requires further study.
CCITT Recommendation Q.700, S 3.2.3.6, describes how Application Service
Elements (ASEs) and Application Entities (AEs) are structured and how an AE is
addressed in Signalling System No. 7.
This section illustrates that architecture, considering the functional
decomposition of an application, and describes how AEs, ASEs, operations and
errors should be defined.
4.2 Decomposition of functionality
Application process functions communicate through one or more Application
Entities (AEs). The combination of two peer AEs plus their interaction is called
the Application Context. An AE consists of communications for one or more
functions of an application. Each communications function forms an ASE which is
an integrated set of actions and may be used in more than an AE. TCAP is itself
an ASE which is used by other ASEs as well as being common to AEs (see
S 3.2.3.6/Q.700). An ASE identifies one or more operations and specifies how
those operations are used; that is, which peer entity may invoke which
operations, and in what order. Operations may be selected from one or more
libraries.
An ASE provides a service to the user of the ASE. An ASE is used by two
complementary AEs: the consumer of the service and the supplier of the service.
The consumer of the service is the end that initiates the AE to AE communication.
An ASE user is thus generally asymmetric.
Within an ASE, the mechanism for providing the ASE service is the
invocation of operations by the service requestor on the service provider. Each
operation provides a part of the service in an inherently asymmetric manner since
it is invoked by one AE and executed by the peer AE. An ASE generally includes
more than one operation. An ASE user is, in general, not limited to either
invoking or performing operations, but may both invoke or perform the same or
different operations. Also, an ASE user may exist at a pair of nodes such that
either node may request the same service from the other node. That is, the AEs at
the nodes may be symmetric, both invoking and executing the same operations.
Note - Primitives which provide a standard service interface for the
access of ASEs within AEs are for further study.
Figure 3/Q.775 illustrates the decomposition of this functionality and
provides examples.
Fig. 3/Q.775 /T1120780-88 = 8cm
4.3 How to specify an AE
CCITT Recommendation Q.700, S 3.2.3.6, describes how two Signalling System
No. 7 Application Processes communicate via Application Entities, and also the
structure of an AE.
The application designer should provide a definition for each type of AE.
It should contain:
- A general description of the services supported by the combination of
the two peer AEs and communicating by a dialogue. (In Recommendation
X.229 terminology, this corresponds to the "Application Context").
- A definition of the complete application protcol between the peer AEs
by:
- identifying each ASE constituting the AE, and
- indicating which of the peer AEs initiates the service.
PAGE118 Fascicle VI.9 - Rec. Q.775
- Any special constraints to ensure that peer AEs with different versions
are compatible.
A formal specification of the application context using the Recommendation
X.229 APPLICATION-CONTEXT macro is for further study.
Since each AE constitutes a single coding domain for operation and error
code values (addressed by SCCP subsystem number in a connectionless network
service environment), each operation or error code value must be unique within
the AE (see S 4.5).
4.4 How to specify an ASE
The definition of an ASE is part of the stage 3 of the service description
methodology, as defined by Recommendation I.220.
The ASE description should provide:
- A general description of the ASE and its procedures.
- The information flows between the entities which are communicating to
support the service, based on stage 2, with additions and enhancements
that are needed as part of the protocol design.
- A detailed description of the ASE protocol. This includes the sequence
in which operations may be invoked, and the reaction to abnormal
situations. The definition should include how protocol version
interwork. Dialogue begin, continuation and end should be specified.
This section should describe the interaction between the ASE and the
TCAP component sub-layer expressed in terms of the primitive interface.
- SDL diagrams.
Recommendation X.229 (ROSE) defines an APPLICATION-SERVICE-ELEMENT macro
which may be used to specify an ASE formally. It identifies which operations are
contained in the AE and how they are invoked. The use of this macro in Signalling
System No. 7 is for further study.
4.5 How to specify operations and errors
4.5.1 Information needed to specify operations and errors
To specify an operation, the following items must be defined:
- The operation name.
- The operation code. This may be local or global. See S 4.5.2.
- The operation class. A value in the range 1 to 4 as defined in S 2.2.1.
- The parameters accompanying the operation invocation (input
parameters). Further essential information to supplement that provided
in the parameters with the original invocation may be requested using
linked operations.
- The parameters that may be returned as the result of a successful
outcome (Return Result), whenever the operation reports success
(possitive output parameters). The way these parameters are actually
passed (in a single component or several) is no part of the operation
description.
- The error codes and associated parameters that may be returned as the
result of an unsuccessful outcome (Return Error) of the operation
execution, whenever this operation reports failure (negative output
parameters). An error code must be present when reporting failure, and
all the possible values be defined as part of the operation
description.
- The allowed linked operations (see S 2.2.2).
- The timer value for completion of the operation.
The operation description consists of a Table indicating the eight items
above, together with a short prose description of what the operation does. A
formal definition using Annex A/Q.773 OPERATION and ERROR macros should also be
included to unambiguously indicate which parameters are mandatory, which are
optional with default values as applicable, and which individual, sets or
sequences of parameters are legal as input, positive output, and negative output.
The OPERATION and ERROR type (macro) definitions are exported from the TCAP
definitions (Annex A/Q.773) and need to be imported into the ASE being defined in
order to define operations and errors.
The syntax of the OPERATION MACRO (reproduced from Annex A/Q.773) is as
follows:
OPERATION MACRO ::=
BEGIN
TYPE NOTATION ::= Parameter Result Errors Linked Operations
VALUE NOTATION ::= value{VALUE CHOICE{
Fascicle VI.9 - Rec. Q.775 PAGE101
localValue INTEGER,
globalValue OBJECT IDENTIFIER }}
Parameter ::= "PARAMETER" Named Type | empty
Result ::= "RESULT" ResultType | empty
ResultType ::= NamedType | empty
Errors ::= "ERRORS" "{"ErrorNames"}" | empty
LinkedOperations ::= "LINKED" "{"LinkedOperationNames"}" | empty
ErrorNames ::= ErrorList | empty
ErrorList ::= Error | ErrorList "," Error
Error ::= value (ERROR) -- shall reference an error value
| type -- shall reference an error type if no error value
-- is specified
LinkedOperationNames ::= OperationList | empty
OperationList ::= Operation | OperationList "," Operation
Operation ::= value (OPERATION) -- shall reference an operation
value
| type -- shall reference an operation type if no error
value
-- is specified
NamedType ::= identifier type | type
END
ERROR MACRO ::=
BEGIN
TYPE NOTATION ::= Parameter
VALUE NOTATION ::= value (VALUE CHOICE{
localValue INTEGER,
globalValue OBJECT IDENTIFIER })
Parameter ::= "PARAMETER" NamedType | empty
NamedType ::= identifier type | type
END
The use of local and global values is explained in S 4.5.2.
As an example, the CUGCheck2 operation, which is used to check whether an
incoming call is compatible with the CUG characteristics of the called party, is
described here in both (abbreviated) formal notation, and in the form of a table.
4.5.2 Example of operation description
(Note - Arbitrary section numbers are used in this example.)
3.4.3.1 Description of operations
3.4.3.1.1 CUG check 1
PAGE118 Fascicle VI.9 - Rec. Q.775
