The definition of the protocol is split into three Clauses:
The SACF/MACF rules are defined in prose. The operation definitions
are in Abstract Syntax Notation 1 (ASN.1, see CCITT Recommendation X.208
[14]), and the actions are defined in terms of state transition
diagrams. Further guidance on the actions to be performed on receipt of
an operation can be gained from Clause 6 and from the relevant detailed
procedures in Clause 7.
The INAP is a Remote Operations Service
Element (ROSE) user protocol (see CCITT Recommendations X.219 [16] and
X.229 [17]). The ROSE protocol is contained within the Digital
Subscriber Signalling System No. One (DSS1, see ETS 300 196-1 [4]) and
the Component Sublayer of the Transaction Capabilities Application Part
(TCAP, see ETS 300 287 [5]).
The protocol will support any mapping of functional to Physical
Entities (PEs), see ETS 300 348 [6] (ITU-T Recommendation Q.1215). It is
the responsibility of network operators and equipment manufacturers to
decide how to co-locate FEs to the best possible advantage as this may
vary between manufacturers and between network operators. Therefore the
protocol is defined assuming maximum distribution (i.e. one PE per FE).
The figures depicted in this subclause show how INAP would be supported
in an SS No. 7 network environment. This does not imply that only SS No.
7 may be used as the network protocol to support INAP.
When TCAP
appears in one of the following figures, it shall be understood as
representing the TCAP functionalities associated with a single dialogue
and transaction (as opposed to a TCAP entity).
For each physical
scenario, the typical SRF control procedures to be applied are shown in
subclause 7.1.3.5.
The interface between remotely located SCF and
SDF will be INAP using TCAP which in turn, uses the services of the
connectionless SCCP and MTP (see figure 1). The SDF is responsible for
any interworking to other protocols to access other types of networks.
A number of example scenarios have been identified for support of the
SCF, SSF and SRF FEs as PEs. These are illustrated as Figures 2 to 6.
Each example is characterised by:
Figure 1: Physical interface
between SCP and SDP
Table 1 summarizes the selection of
features for each figure.
Table 1
Figure 2: Example architecture
for supporting SRF, Case 1
(SRF in IP connected to SSP and
accessed by SCP through direct SS No. 7 connection)
Figure 3: Example Architecture
for supporting SRF, Case 2
(SRF in IP connected to SSP and
accessed by SCP through D-channel via SSP)
Figure 4: Example Architecture
for supporting SRF, Case 3
(SRF in SSP and accessed via AP of
SSP)
Figure 5: Example Architecture
for supporting SRF, Case 4
(SRF in IP connected to SSP and
accessed by SCP through ISUP via SSP)
Figure 6: Example Architecture
for supporting SRF, Case 5
(SRF in IP connected to SCP and SSP
and accessed via both SS No. 7 link and D-channel, respectively)
Many of the terms used in this subclause are based on the OSI
Application Layer Structure as defined in ISO IS-9545 [18].
The
INAP protocol architecture can be illustrated as shown in figure 7.
Figure 7: INAP protocol
architecture
A PE has either single interactions (case a) or
multiple co-ordinated interactions (case b) with other PEs.
In case
a, SACF provides a co-ordination function in using Application Service
Elements (ASEs), which includes the ordering of operations supported by
ASE(s), (based on the order of received primitives). The Single
Association Object (SAO) represents the SACF plus a set of ASEs to be
used over a single interaction between a pair of PEs.
In case b,
MACF provides a coordinating function among several SAOs, each of which
interacts with an SAO in a remote PE.
Each ASE supports one or more
operations. Description of each operation is tied with the action of
corresponding FE modelling (see ITU-T Recommendation Q.1214 [11] and
Clause 7 of this ETS). Each operation is specified using the operation
macro described in figure 8.
Figure 8: Operation Description
The use of the Application Context (AC) negotiation mechanism (as
defined in ETS 300 287 [5]) allows the two communicating entities to
identify exactly what their capabilities are and also what the
capabilities required on the interface should be. This should be used to
allow evolution through capability sets.
If the indication of a
specific AC is not supported by a pair of communicating FEs, some
mechanism to pre-arrange the context shall be supported.
The same type of procedure shall apply as defined for ISDN User Part
signalling congestion control. The INAP procedures for signalling
congestion control shall as far as possible be aligned with the ISDN
User Part signalling congestion control procedures as specified in ETS
300 121 [3] (CCITT Recommendation Q.767, � D.2.11), i.e. on receipt of
N-PCSTATE indication primitive with the information "signalling point
congested" from SCCP, the INAP shall reduce the traffic load (e.g.
InitialDPs and InitiateCallAttempts) into the affected direction in
several steps.
The above procedure may only apply to traffic which
uses MTP Point Code addressing in the affected direction.
SCCP Global Title (see ETS 300 009 [2]) and MTP Point Code
addressing (see ETS 300 008 [1]) ensure that PDUs reach their physical
destination (i.e. the correct point code) regardless of which network it
is in.
Within a node, it is the choice of the network
operator/implementor as to which SSN or SSNs (Sub System Numbers) are
assigned to INAP.
Regardless of the above, any addressing scheme
supported by the SCCP may be used.
Table 2 gives a complete list of information flows. These map one to one with operations except where indicated.
This subclause specifies the compatibility mechanisms that shall be
used for INAP, in this subclause referred to as ETSI INAP to avoid
confusion with INAP according to ITU-T Recommendation Q.1218 [12].
Two major categories of compatibility are handled by these mechanisms:
The second category has three sub-categories of compatibility dealt with in this subclause:
On receipt of an operation according to ITU-T Recommendation Q.1218 [12] which is not part of the ETSI INAP or is part of the ETSI INAP but which contains parameters which are not part of the ETSI INAP:
Additionally, tagging of ETSI INAP additions to ITU-T Recommendation Q.1218 [12] are specifed from 30 downwards to avoid overlap with future additions in ITU-T Q.1218 INAP.
In order to support the introduction of major functional changes, the protocol allows a synchronisation between the two applications with regard to which functionality is to be performed. This synchronisation takes place before the new function is invoked in either application entity, in order to avoid complicated fall-back procedures. The solution chosen to achieve such a synchronisation is use of the AC negotiation provided in ETS 300 287 [5].
The extension mechanism marker shall be used for future standardized minor additions to INAP. This mechanism implements extensions differently by including an "extensions marker" in the type definition. The extensions are expressed by optional fields that are placed after the marker. When an entity receives unrecognised parameters that occur after the marker, they are ignored (see ITU-T Recommendation X.68x [18]).
This mechanism is based on the ability to explicitly declare fields of any type via the Macro facility in ASN.1 at the outermost level of a type definition. It works by defining an "ExtensionField" that is placed at the end of the type definition. This extension field is defined as a set of extensions, where an extension can contain any type. Each extension is associated with a value that defines whether the terminating node should ignore the field if unrecognised, or reject the message, similar to the comprehension required mechanism described in the previous subclause. Refer to ITU-T Recommendation Q.1400 [13] for a definition of this mechanism.
Contents Page
