SIST-TP ETSI/ETR 024 E1:2005

Signalling Protocols and Switching (SPS); Intelligent Networks switching aspects

Define the influence of IN-concepts on requirements for switching system functionalities

Signalizacijski protokoli in komutacija (SPS) - Komutacijski vidiki inteligentnega omrežja

General Information

• Status: Published
• Publication Date: 31-Mar-2005
• Withdrawal Date: 30-Sep-2003
• ICS: 33.040.30 - Switching and signalling systems
• Technical Committee: SPN - Services and Protocols for Networks
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Apr-2005
• Due Date: 01-Apr-2005
• Completion Date: 01-Apr-2005
• Ref Project: ETSI ETR 024 ed.1 (1991-05) - Signalling Protocols and Switching (SPS); Intelligent Networks switching aspects

Standards Content (Sample)

SLOVENSKI STANDARD
SIST-TP ETSI/ETR 024 E1:2005
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
SIST-TP ETSI/ETR 024 E1:2005 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST-TP ETSI/ETR 024 E1:2005

---------------------- Page: 2 ----------------------

SIST-TP ETSI/ETR 024 E1:2005
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 - [e-mail]
X.400: Internet:
Tel.: [phone] - Fax: [phone]
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: 3 ----------------------

SIST-TP ETSI/ETR 024 E1:2005
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: 4 ----------------------

SIST-TP ETSI/ETR 024 E1:2005
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: 5 ----------------------

SIST-TP ETSI/ETR 024 E1:2005
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: 6 ----------------------

SIST-TP ETSI/ETR 024 E1:2005
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: 7 ----------------------

SIST-TP ETSI/ETR 024 E1:2005
Page 6
ETR 024:1991
Blank page

---------------------- Page: 8 ----------------------

SIST-TP ETSI/ETR 024 E1:2005
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: 9 ----------------------

SIST-TP ETSI/ETR 024 E1:2005
Page 8
ETR 024:1991
Blank page

---------------------- Page: 10 ----------------------

SIST-TP ETSI/ETR 024 E1:2005
Page 9
ETR 024:1991
Part 1: The Connection Control Model (CCM)

---------------------- Page: 11 ----------------------

SIST-TP ETSI/ETR 024 E1:2005
Page 10
ETR 024:1991
Blank page

---------------------- Page: 12 ----------------------

SIST-TP ETSI/ETR 024 E1:2005
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: 13 ----------------------

SIST-TP ETSI/ETR 024 E1:2005
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: 14 ----------------------

SIST-TP ETSI/ETR 024 E1:2005
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: 15 ----------------------

SIST-TP ETSI/ETR 024 E1:2005
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: 16 ----------------------

SIST-TP ETSI/ETR 024 E1:2005
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,
a
...