ETSI ETR 024 ed.1 (1991-05)

SLOVENSKI STANDARD
01-april-2005
Signalizacijski protokoli in komutacija (SPS) - Komutacijski vidiki inteligentnega
omrežja
Signalling Protocols and Switching (SPS); Intelligent Networks switching aspects
Ta slovenski standard je istoveten z: ETR 024 Edition 1
ICS:
33.040.30 Komutacijski in signalizacijski Switching and signalling
sistem systems
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

ETSI ETR 024
TECHNICAL May 1991
REPORT
UDC:
Key words: .
Signalling Protocols & Switching (SPS);
Intelligent Networks switching aspects
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
F-06921 Sophia Antipolis CEDEX - FRANCE
Postal address:
650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
Office address:
c=fr, a=atlas, p=etsi, s=secretariat - secretariat@etsi.fr
X.400: Internet:
Tel.: +33 92 94 42 00 - Fax: +33 93 65 47 16
Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1996. All rights reserved.
New presentation - see History box

Page 2
ETR 024:1991
Whilst every care has been taken in the preparation and publication of this document, errors in
content, typographical or otherwise, may occur. If you have comments concerning its accuracy,
please write to “ETSI Standards Management Dept.” at the address shown on the title page.

Page 3
ETR 024:1991
Contents
Foreword.7
Introduction .7
Part 1: The Connection Control Model (CCM).9
1 Objectives and description of the modelling .11
1.1 Objectives.11
1.2 The Connection Control Model (CCM).12
1.2.1 The Basic Call Model (BCM) .12
2 Technical details of the CCM.13
2.1 Connection Control Socket .13
2.1.1 CC-Provide-instruction.13
2.1.2 CC-CREATE a leg.13
2.1.3 CC-FREE a leg.14
2.1.4 CC-JOIN legs .15
2.1.5 CC-SPLIT a leg.16
2.1.6 CC-MONITOR events on a leg.16
2.1.7 CC-GENERATE an event on a leg.17
2.1.8 CC-EVENT received on a leg.17
2.1.9 CC-SEND-RECEIVE information on a leg.18
2.1.10 CC-RESUME basic call .18
2.1.11 CC-DETACH a leg.19
2.1.12 CC-AITACH a leg .20
2.1.13 CC-MODIFY a leg .20
2.1.14 CC-SEND information on a connection point .21
2.2 Data Management Socket.21
2.2.1 DM-Create primitive.21
2.2.2 DM-Delete primitive.21
2.2.3 DM-Modify primitive.21
2.2.4 DM-PoII primitive.22
2.2.5 DM-Event primitive.22
2.2.6 DM-Monitor primitive.22
2.2.7 Parameters used in primitives of the Data Management
Socket.22
2.3 Status Monitoring Socket. .23
2.3.1 SM - Start Status Monitoring Primitive.23
2.3.2 SM - Cancel Status Monitoring Primitive .24
2.3.3 SM - Poll Status Primitive .24
2.3.4 SM - Event Status Primitive.25
2.4 Traffic Management Socket .25
2.4.1 TM-CREATE primitive.25
2.4.2 TM-CANCEL primitive.27
2.4.3 TM-EVENT primitive.27
2.4.4 TM-MODIFY primitive.27
2.5 Resource Control Socket .27
2.5.1 RC-RESERVE RESOURCE Primitive.28
2.5.2 RC-ALLOCATE RESOURCE Primitive .28
2.5.3 RC-RELEASE RESOURCE Primitive .29
2.5.4 RC-SEND & RECEIVE Primitive .29

Page 4
ETR 024:1991
3 Technical background and rationale.30
3.1 Connection Control Socket .31
3.1.1 Objects in the Connection Control Socket.31
3.1.2 Primitives on the Connection Control Sooket objects.32
3.2 Data Management Socket.32
3.3 Status Monitoring Socket .33
3.4 Traffic Management Socket .33
3.4.1 Objectives of IN Traffic Management .33
3.4.2 Technical aspects of IN Traffic Management .34
3.5 Resource Control Socket .36
4 Switching perspective of the connection control model.38
4.1 Introduction .38
4.2 The bottom up basis for the IN studies .38
4.3 Physical Entity Connections.39
4.4 Control Fields and Transition Points .39
4.5 Subscriber Legs, Internal Paths, Incoming- and Outgoing Trunk Legs .40
4.6 Control Field functions related to Connection Control.41
4.7 Applied symbols of Physical Entity Connections.44
4.8 An initial discussion of connections.45
4.9 An initial discussion of Connection Control and Service Control .46
4.10 Some characteristics of Connection Control and Service Control .46
4.11 Connections.48
4.12 A Bidirectional Symmetrical Basic Call Model.49
4.13 Symmetrical Extended Basic Call .51
4.14 Asymmetrical Extended Basic Call Model.53
Annex 1: Formal specification of CCM primitives .55
Part 2: The Service Switching Functions (SSF).57
1 Introduction.59
1.1 Rationale .59
1.2 SSF Domains .59
1.3 Processing capabilities.63
2 Rules for the specification of SSF Domains .65
2.1 SSF DOMAIN specification criteria .65
2.2 SSF DOMAIN representation/modelling rules.66
3 Interactions .68
3.1 Introduction .68
3.2 Interactions between operations .69
3.3 Interactions between sockets.70
3.4 Interactions between instances of FES.70
4 Connection Control Domain (CCD) .71
4.1 Overview.71
4.2 SCFAM.73
4.3 INFM.73
4.3.1 TMF activities .74
4.3.2 TMF operation.74
4.3.3 Interaction with non-lN traffic management .76
4.4 FIM.76

Page 5
ETR 024:1991
4.5 BCM.80
4.5.1 Introduction.80
4.5.2 The case for segmentation .80
4.5.3 Representation.81
4.5.4 Segment description.81
4.5.5 Detailed description of PICS.86
4.5.5.1 Incoming-terminator segment .86
4.5.5.1.1 I_Null.86
4.5.5.1.2 Authorise Origination At&empt.86
4.5.5.1.3 I_Proceeding.86
4.5.5.1.4 I_Alerting.87
4.5.5.1.5 I_Active.87
4.5.5.1.6 I_Disconnect.87
4.5.5.1.7 I_Exception.88
4.5.5.2 Associator segment.88
4.5.5.2.1 A_Null.88
4.5.5.2.2 Collect_lnformation.88
4.5.5.2.3 Analyse Information.89
4.5.5.2.4 Select Route.89
4.5.5.2.5 Authorise Call Setup .90
4.5.5.2.6 A_Proceeding .90
4.5.5.2.7 A_Alerting .91
4.5.5.2.8 A_Active.91
4.5.5.2.9 A_Disconnect.92
4.5.5.2.10 A_Exception.92
4.5.5.3 Outgoing terminator segment .92
4.5.5.3.1 O_Null.92
4.5.5.3.2 Authorise Termination Attempt .93
4.5.5.3.3 Select Facility.93
4.5.5.3.4 Present Call.93
4.5.5.3.5 O_Alerting.94
4.5.5.3.6 O_Active.94
4.5.5.3.7 O_Disconnect.94
4.5.5.3.8 O_Exception.95

Page 6
ETR 024:1991
Blank page
Page 7
ETR 024:1991
Foreword
ETSI Technical Reports (ETRs) are informative documents resulting from ETSI studies which
are not appropriate for European Telecommunication Standard (ETS) or Interim - European
Telecommunication Standard (I-ETS) status. An ETR may be used to publish material which is
either of an informative nature, relating to the use or application of ETSs or I-ETSs, or which is
immature and not yet suitable for formal adoption as an ETS or I-ETS.
This ETR has been produced by the Signalling Protocols & Switching (SPS) Technical
Committee of the European Telecommunications Standards Institute (ETSI).
Introduction
The information contained in this report reflects initial studies on switching aspects in
Intelligent Networks (IN). The objectives of these studies were to develop a general
understanding of IN switching aspects with a view to creating a basis for future IN studies in
SPS3.
The studies were conducted prior to recent efforts in ETSl and CClTT which focus on the first
standardisation phase targeted for 1992 and is known as the so-called Capability Set Number
1 (CS1).
Some of the information in the report may be relevant for both Capability Set Number 1 and/or
longer term Capability Sets. Other information may be either beyond the scope of CS1, or may
become obsolete as current studies on IN are progressed.
This report is divided in two parts:
Part 1 deals with the Connection Control Model (CCM). The contents of sections 1 to 3
is related to the functional plane of the IN conceptual model developed by ETSI
STC/NA6;
Part 2 identifies different functional entities of IN especially the Service Switching and
Call Control functional entities (SSF & CCF). A detailed study of the logical behaviour of
SSF and CCF is started. The concept of trigger table are introduced and the behaviour
of connection segment objects is described. Different chapters have reached different
degrees of detail.
The result present in this technical report is an intermediate result and should be considered
as a state-of-the-art at the end of 1990.

Page 8
ETR 024:1991
Blank page
Page 9
ETR 024:1991
Part 1: The Connection Control Model (CCM)

Page 10
ETR 024:1991
Blank page
Page 11
ETR 024:1991
OBJECTIVES & DESCRIPTION OF THE MODELLING
Objectives
1.1
The Connection Control Model is used to describe the interaction bet-
ween functional entities (principally the SSF and SCF) in the functio-
nal plane of the IN conceptual model.
The Connection Control Model establishes a framework for the interac-
tion between the SSF and SCF in a service- and vendor implementation-
independent environment.
The CCM should only be used in order to provide a description of the
seen from
SSF/CCF functions (triggers, events, operations, etc.) as
outside the SSF/CCF. It is not intended to place any constraint on
implementations.
el (CCM)
1.2 The Connection Control Mod
The following is a general description of the Connection Control Model
(CCM). The full description is contained in the Draft Technical Report
ETSI DTR/NA-6001 produced by NA6.
The CCM is a model of the interactions between the Service Control
Function and the Service Switching function in an Intelligent Network
in order to provide telecommunications and supplementary servi-
(IN),
ces related to calls in an IN-structured network.
A call
Therefore, the CCM is centred around the concept of a “call”.
can be defined as a temporary relation between two or more users of a
telecommunications network, for the provision of telecommunications
services and possible associated supplementary services (a user can be
establis-
a human, a machine, a system, etc.). A call, in order to be
hed, maintained and released, involves resources of the telecommunica-
tions network.
An “IN call” can be defined as a call that involves resources belon-
ging to an Intelligent Network architecture.
Typically, the life-cycle of an IN call is composed of the following
phases:
and
a) a call request is issued by a telecommunications network user,
non-IN switch-based processes are activated in order to fulfill
such a request
b) a Trigger Point is encountered and the Trigger Condition is fulfil-
led: subsequent call processing implies the interaction between IN
entities (SSF, SCF, etc.)<1>.
--------------------- ----
<1> Phases a) and b) are missing if the service is triggered by the Service
Control Function (e.g. “wake-up service”). In this case the SCF creates
the socket autonomously and phase c) follows

Page 12
ETR 024:1991
c) a socket (or more than one) is opened and interactions between SSF
and SCF occur through this socket
d) call processing can proceed without the interaction between IN en-
tities, therefore the socket is closed and non-IN switch-based call
processing is resumed
e) the call is finally terminated.
The Socket Models apply to phase c) of the call. They can be viewed as
“window” between the two functional blocks (SSF and SCF), through
a
which they can see each other and interact in terms of pre-defined
objects and operations on the objects.
interactions between SSF and SCF will not be associated to any
Some
specific call. To distinguish between call-related and non call-rela-
ted interactions, different “socket types” are used, i.e. connection
socket,
control socket, data management status monitoring socket,
traffic management socket and resource control socket.
The Connection Segment Relationship Model also applies to phase c) of
the call, to cater for the interactions between different sockets and
different service features (both provided in an IN fashion and provi-
ded locally by switch-based processes) related to the same call.
The Basic Call Model applies to phases b) and d) of the call. It is a
model of the logical states of a call and of the points (states or
transitions between states) in which the socket “window” can be opened
and closed.
The three models together form the Connection Control Model.
1.2.1 The Basic Call Model (BCM)
Utility of the BCM: its main purpose is to limit, acceptable
to an
degree, the flexibility of choice of Trigger Points (TP’s) within a
call life-cycle. Once the set of allowed points is specified, additio-
nal information can be associated to each of them, to form the Trigger
Table.
Consistency of the BCM with the other models and with call processing
in general: at the time of socket opening, sufficient information must
be sent from SSF to SCF in order to allow for a correct sequence of
During the interactions through the socket(s), con-
call processing.
sistency depends on the correctness of modelling objects/operations
and of service logic. At the time of socket closing a correct resump-
tion of basic switch processing must be ensured.
The BCM is described in detail in Part II of this Technical Report.

Page 13
ETR 024:1991
2 TECHNICAL DETAILS OF THE CCM
The general description of the use of the different socket types in
the Connection Control Model is described in
the NA6 Draft Technical
Report ETSI DTR/NA-6001.
This section contains the requirements on the parameters and primiti-
ves related to the objects available in the different socket types, in
order to constitute an input for the consequent definition of applica-
tion protocol elements.
2.1 Connection Control Socket
The connection control (CC) socket is used by the SCF to
operate con-
nection control related objects in a CCF/SSF, namely legs
and connec-
tion points.
The primitives on the objects and the corresponding parameters are
described in detail in these sections.
Note(s): Error replies are not specified.
CC-Provide-Instruction
2.1.1
The SSF uses this primitive to indicate service activation to the SCF,
to request instructions from it.
The CC-PROVIDE-INSTRUCTION includes parameter(s) to describe the pre-
sent content of the socket; i.e. the objects which exist within the
socket namely leg and connection point identifiers, as well as infor-
condition (service activated, event
mation identifying the trigger
which triggers the service).
Calling-
Other parameters like CalledPartyNumber, CallingPartyNumber,
PartyCategory, UserServiceInformation, CUGInterlockCode, Redirection-
which are all
Information, RedirectingNumber, OriginalCalledNumber,
similar to ISUP parameters, indicate detailed characteristics of the
leg(s) which exist(s) in the socket.
Information that needs to be exported from SSF to SCF is defined rela-
ted to trigger conditions.
2.1.2 CC-CREATE a leg
The SCF uses this primitive to request the creation of a leg by the
SSF to an addressable entity.
The CC-CREATE includes the following parameters:
- “leg identifier” to identify the leg to create

Page 14
ETR 024:1991
-
“addressable
entity identifier” to identify the addressable entity.
-
"leg attributes”, like CallingPartyNumber,
CallingPartyCategory,
UserServiceInformation,
CUGInterlockCode, RedirectionInformation,
RedirectingNumber, OriginalCalledNumber, similar to ISUP parameters,
to indicate detailed characteristics of the leg to create.
-
"other leg identifier”, identifying a leg already existing whithin
the socket, indicating that this legs may be joined with the created
one in the near future.
- "completion condition”, to indicate, when
the CC-CREATE can be con-
sidered as completed by the SSF (when the next operation on this leg
can start).
The “other leg identifier” parameter, identifies a leg already exis-
ting whithin the socket. When this parameter is present, the SSF deri-
ves missing information for the created leg (e.g. CallingPartyNumber,
. .) from this other leg. Otherwise, default values (t.b.d.) are used.
Possible values of “completion condition” may be: “Local processing
complete”, “alerting”, “answered”.
It indicates when the next operati-
on on the created leg can start.
Note(s): Issues such as the need to distinguish between different ty-
pes of adressable entities towards which legs are created (Could that
be a leg characteristic? Should there be any difference between a leg
to a “normal” party and another to an SRF?) are not specified.
2.1.3 CC-FREE a
leg
The SCF uses this primitive to request the SSF to release a leg and
all associated resources.
The CC-FREE includes the following parameters:
- “leg identifier” to identify the leg which must be freed
- “release cause” (similar to ISUP CauseIndicators)
- “when” to indicate whether the leg must be released immediately, any
other operation on this leg being stopped, or only after the comple-
tion of ongoing operation(s) on this leg
The “leg identifier” parameter, which identifies the leg to release,
it must identify an unjoined leg.
The parameter used to identify the release cause is “translated” by
the SSF, depending on the signalling system used for the leg.
Another parameter indicates whether the leg must be released
immedia-
tely, any other operation on this leg being stopped, or only after the
completion of ongoing operation(s) on this leg.

Page 15
ETR 024:1991
2.1.4 CC-JOIN legs
The SCF uses this primitive to request the SSF to link either one or
two leg(e) or a connection point to a connection point and to through-
connect the corresponding physical resources.
The CC-JOIN includes the following parameters:
- “leg identifier”(s) to identify the leg(s) concerned;
- “connection point identifier”(s) to identify the CP(s) concerned
When used to connect two separate legs on a non existing connection
point, a parameter “leg identifier” identifies the first leg, a para-
meter “other leg identifier” identifies the other leg to connect and a
parameter “CP identifier” identifies the connection point.
before after
Figure 1. socket before and after CC-JOIN (first case)
When used to connect a leg to an existing connection point, a parame-
ter “leg identifier” identifies the leg and a parameter “CP identifi-
er” identifies the connection point. In this case, several legs may
already be connected to the connection point.
I I
before after
Figure 2. socket before and after CC_JOIN (second case)
When use to connect two existing connection points together, two para-
meters “CP identifier” identify the connection points. As a result of
this operation,
all legs connected to both connection points end up
connected to a single connection point.

Page 16
ETR 024:1991
before after
Figure 3. socket before and after CC-JOIN
2.1.5 CC-SPLIT a leq
The SCF uses this primitive to request the SSF to separate a leg from
discar-
a connection point, or all the legs from a connection point,
ding the connection point.
The CC-SPLIT includes the following parameters:
- “leg identifier" to identify the leg concerned, or
- "connection point identifier” to identify the CP concerned.
When only a connection point identification is present, all legs con-
nected to it are split off, and the connection point is released.
When only a leg identification is present, only the indicated leg is
split off from the connection point on which it was connected. (a leg
can only be connected to one connection point at a given time).
Note: Application of this primitive for the splitting of one CP into
two separate CP’s is not specified here.
2.1.6 CC—MONITOR events on a leg
The SCF uses this primitive to request the SSF to assign or update the
mode” to some or all events on one leg in the SSF.
“event processing
Event mode may be: transparent, intercepted, duplicated, ignored.
The CC-MONITOR includes the following parameters:
- “leg identifier”, to identify the leg which is concerned

Page 17
ETR 024:1991
- for each event: “event mode”,
to identify in which processing mode
the SSF must handle the event.
- “other leg identifier”, to identify the leg on which transparent or
duplicated event must be reflected.
The “leg identifier” parameter identifies the leg concerned. Another
parameter defines in which processing mode the SSF must handle events.
If an event is asked to be in transparent or duplicated mode, another
“leg identifier” parameter must indicate on which other leg the event
must be reflected (sent/transmitted).
CC-GENERATE an event on a leg
2.1.7
The SCF uses this primitive to request the SSF to generate on a leg
the signalling message corresponding to an event. Information relative
to this message is given by the SCF in a way. It is up to the SSF to
translate it in the right signalling system.
The CC-GENERATE includes the following parameters:
- “leg identifier” to identify the leg on which the event has to be
generated
- “event identifier”, to indicate which event must be generated
- “event parameter”, to describe the parameter of this event.
The “leg identifier” parameter to identifies the leg on which the
event must be generated. The “event descriptor” parameter describes
the event.
Limitations on which events can be generated are not specified. Howe-
ver, events that can be “generated” by other operations are excluded
(eg: CC-GENERATE Release is excluded, as CC-FREE is available).
2.1.8 CC-EVENT received on a leg
The SSF uses this primitive to report information on events to the
SCF. This event has been previously assigned one of the two modes:
intercepted or duplicated.
The CC-EVENT includes the following parameters:
- “leg identifier” to identify the leg on which the event occurs
- “event identifier” to indicate which event was received
- “event parameter” to describe the parameters of this event

Page 18
ETR 024:1991
- “event date" to indicate when the event occurs.
CC-SEND-RECEIVE information on a
2.1.9 leg
The SCF uses this primitive to request the SSF to send and/or receive
specific information to and/or from a call participant.
The CC-SEND-RECEIVE includes the following parameters:
- “leg identifier” to identify the leg on which the information has to
be exchanged
- InformationToSend
This subparameter contains the specification of the information to
be send Tone Identity Announcement Identity other Identities are not
specified
- SendStopOptions
subparamater
This contains one of the following stop options: Num-
berOfRepetitions Duration InformationReceived NextOperationReceived
- InformationToReceive
This subparameter contains the number of digits to be received
- ReceiveStopOpt.
This subparameter contains the receive parameters: InitialCharacter-
TimeOut InternalCharacterTimeOut TotalElapsedTimeOut EndOfInput-
Delimiter AllDigitsReceived Others are not specified.
2.1.10 CC-RESUME basic call
The SCF uses this primitive to resume object control to the SSF. With
this operation, the SCF gives control back to the SSF on some objects,
like leg(s) or connection point(s), which will then be handled with
the basic call control.
The CC-RESUME includes the following parameters:
- “connection point identifier”
The SCF can only give back control on a connection point, to which two
legs are connected.
Page 19
ETR 024:1991
(SCF view)
I
after
before
Figure 4. example of CC_RESUME
2.1.11 CC-DETACH
a leg
The SCF uses this primitive to request the SSF to remove a leg from
the socket and to asign it an absolute (i.e. unique network wide) re-
ference, so that it can be transferred to another socket instance, to
which the seg was/will be attached by means of the CC-ATTACH primitive
using the same absolute reference.
The CC-DETACH includes the following parameters:
- “leg identifier”,
to identify the leg to detach
- “absolute reference”
, which allows to find the socket where the
leg
has to be attached.
Only unjoined legs can be detached.

Page 20
ETR 024:1991
If a CC-ATTACH with the same absolute reference was already received
by the SSF, the concerned leg is transferred from one socket to the
other. Otherwise, the SSF sets a timer. When the timer elapses, if the
leg transfer has not been done, an error response is given to the SCF
for this CC-DETACH operation.
2.1.12 CC-ATTACH a leg
The SCF uses this primitive to request the SSF to include a leg in the
current socket. The leg is transferred from another socket, to which
the service logic will send (or has already sent) a CC-DETACH primiti-
ve with the same absolute reference.
The CC-ATTACH includes the following parameters:
- “leg identifier”, will identify the leg after it has been attached
- “absolute reference”, which allows to find the leg to attach.
If a CC-DETACH with the same absolute reference was already received
by the SSF, the concerned leg is transferred from one socket to the
other. Otherwise, the SSF sets a timer. When the timer elapses, if the
SCF
an error response is given to the
leg transfer has not been done,
for this CC-ATTACH primitive.
After CC-ATTACH, all events on the leg are in the intercept mode until
the next CC-MONITOR.
socket 1 socket 2
socket 1 socket 2
after
before
Figure 5. example of CC_ATTACH in socket 1 and CC_DETACH in socket 2
2.1.13 CC-MODIFY a leq
The SCF uses this primitive to request the SSF to modify some charac-
teristics of an existing leg in the current socket (eg. to change the
charging rate applied to the leg, or to change the bandwith associated
with the leg, . .).
Page 21
ETR 024:1991
CC-SEND information on a connection point
2.1.14
The SCF uses this primitive to request the SSF to broadcast informati-
on (eg. tones or announcements) to all legs connected to a connection
point.
The CC-SEND includes the following parameters:
- “connection point identifier”, to identify the connection point to
which the broadcast applies
- “information to send”, to identify the information which has to be
broadcast.
2.2 Data Management socket
This section contains a detailed description of primitives in the DM-
socket and related parameters.
DM-Create primitive
2.2.1
The SCF uses this primitive to create a new data item in the SSF. This
does not include the creation of a new table but only the creation of
a new record in en existing table. The primitive should include the
following parameters
DataItemId BufferSize
DataItemType BufferBehaviour
CounterIncrementUnit
DataItemInformation
2.2.2 DM-Delete Primitive
The SCF uses this primitive to delete a data item in the SSF. The pri-
mitive should include the following parameters:
DataItemId
2.2.3 DM-Modify primitive
The SCF uses this primitive to update an existing data item. The pri-
mitive should include the following parameters:
DataItemId
DataItemInformation
CounterIncrementValue
CounterIncrementUnit
Page 22
ETR 024:1991
2.2.4 DM-Poll primitive
The SCF uses this primitive to interrogate the value of a given data
item. The primitive should include the following parameters:
DataItemId
CounterResetIndicator
DataItemInformation
2.2.5 DM-Event primitive
The SSF uses this primitive to inform the SCF of either a reception of
a DM-Modify primitive from another IN entity, or an updating of a data
item due to internal reasons or to an end user - the primitive should
include the following parameters:
DataItemId
DataItemInformation
EventCause
2.2.6 DM-Monitor tive
primi
The SCF uses this primitive to specify the treatment of a data modifi-
cation attempt. This primitive should include the following parame-
ters:
DataItemId
MonitorMode
2.2.7 Parameters used ives of the Data Management Socket
in primit
DataItemId : This parameter specifies the data item identifier
as it is known by the SSF or the SCF. The parameter
should specify the detailed addressing of the data
to be accessed. (e.g. up to the specification of
the field within a table entry.
DataItemType : This parameter specifies the type of the
DataItemIdentifier
Possibilities: - Record
- Counter
- Buffer
BufferSize : This parameter specifies the storage capacity in
case the DataItemIdentifier specifies a buffer.
BufferBehaviour : This parameter specifies the action to be taken in
case the buffer is full:
Possibilities: - override the oldest value
- override the latest value
- reject near storage requests
Counter
IncrementUnit : This parameter specifies the value by where a

Page 23
ETR 024:1991
.
counter should be
incremented each time a counter
increment request is received.
Counter
IncrementValue : This parameter specifies the value by which a
specified counter should be incremented. This
parameter specifies a single action.
CounterReset
Indicator : This parameter specifies that the counter after
being read should be reset.
EventCause : This parameter specifies the reason for an event
reporting.
Possibilities:
EndUser (line identity)
Internal
DM-Modify primitive (IN entity
address)
MonitorMode : This parameter specifies the action to be taken on
the specified DataItemIdentity
Possible actions to be taken when an attempt to
access the data is made:
-
lock without reporting (similar to Discard in the
CCSocket)
-
lock with reporting (similar to Intercept in the
CCSocket)
unlock without reporting (similar to Transparent
-
in the CCSocket)
unlock with reporting (similar to Duplicate in
-
the CCSocket)
DataItemInfor-
mation : This parameter specifies the contents of the
DataItemIdentity
2.3 Status Monitoring Socket
In the following primitives on the objects contained in the Status
Monitoring Socket are described in detail.
2.3.1 SM- Start Status Monitoring Primitive
The SCF application uses this primitive to request the monitoring and
reporting of busy/free status changes of a specified object (resour-
ce). Note that the possibility to request the reporting of the next
status change and the reservation of the object at the moment the sta-
te changes to free is not specified.

Page 24
ETR 024:1991
The primitive should include the following parameters:
MonitoringReference: This parameter contains a reference
This reference is used
allocated by the SCF.
by the SCF to correlate the replies from the
SSF/SRF to the requested monitoring. This
parameter is to be used in all further
communication (by the SCF as well as by the
SSF/SRF) related to the requested
monitoring.
ResourceType: This parameter identifies the type of
resource for which the monitoring request
should be executed.
This parameter contains the resource
ResourceIdentity:
identification as known by the SSF/SRF.
Possibilities:
- E.164 number
- DTMF Receiver
- Announcement Sender
- Other are FFS
MonitorIndicator: This paramater contains the request type of
monitoring
Continuously
Next Change
2.3.2 SM - Cancel Status Monitoring Primitive
The SCF application uses this primitive to request the cancellation of
a previously requested monitoring.
The primitive should include the following parameters:
MonitoringReference
2.3.3 SM- Poll Status Primitive
The SCF application uses this primitive to request the present state
of the specified object.
The primitive should include the following parameters:
ResourceType
ResourceIdentity
Page 25
ETR 024:1991
The reply
on this primitive contains the present state (i.e Busy or
Free).
2.3.4 SM- Event Status Primitive
This primitive is used by the SSF/SRF to report a state change on an
object, previously placed under supervision by the SCF. The state
changes to be reported are: from Busy to Free or from Free to Busy.
The primitive should include the following parameters:
MonitoringReference: The same parameter value is used as received in
the request.
ResourceState: This parameter contains the resource state of the
resource placed under monitoring by the SCF.
nt Socket
2.4 Traffic Manageme
In the following, primitives and related parameters on the objects
contained in the Traffic Management Socket are described in detail.
imitive
2.4.1 TM—CREATE pr
The TM-CREATE primitive is used by the SCF to request the creation of
1 logical filter object in the socket. This implies, in the SSF, the
activation of the corresponding physical filter. The primitive may
include<1> the following parameters: filter SCOpe, filter type, filter
severity , filter duration and call treatment.
The combination of filter scope and filter type may be used as an
identifier of the filter.
scope This parameter is composed of three sub-parameters, i.e.
Trigger Check Point (TCP), F Addressing Information (SAI)
SC
and SCF Export Information (SEI). It must be noted that such
sub-parameters are in fact characteristics of IN calls, as
they define the specific subset of IN calls passing through
the SSF onto which the filtering mechanism (defined by the
last 3 parameters) must be applied. Moreover, these sub-pa-
rameters are information contained in each entry of the
Trigger Table. The function of each parameter is g
...