Euro ISDN Protocol EDSS1

N
e
w

p
r
e
s
e
n
t
a
t
i
o
n

-

s
e
e

H
i
s
t
o
r
y

b
o
x
EUROPEAN ETS 300 196-1
TELECOMMUNICATION August 1993
STANDARD
Source: ETSI TC-SPS Reference: T/S 46-32B
ICS: 33.080
Key words: ISDN, generic functional protocol, DSS1
Integrated Services Digital Network (ISDN);
Generic functional protocol for the support of
supplementary services;
Digital Subscriber Signalling System No. one (DSS1) protocol;
Part 1: Protocol specification
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE
Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: secretariat@etsi.fr
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 1993. All rights reserved.
Page 2
ETS 300 196-1: August 1993
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 Editing and Committee Support Dept." at the address shown on the title page.
Page 3
ETS 300 196-1: August 1993
Contents
Foreword........................................................................................................................................... 7
1 Scope ...................................................................................................................................... 9
2 Normative references ................................................................................................................ 9
3 Definitions............................................................................................................................... 10
3.1 General definitions .................................................................................................... 10
3.2 Remote Operations definitions ................................................................................... 12
3.3 Definition of procedures using the common information element approach ..................... 12
4 Symbols and abbreviations....................................................................................................... 12
5 Coexistence of generic protocols for the control of supplementary services ................................. 13
5.1 Support of various generic protocols........................................................................... 13
5.2 Coexistence of generic protocols................................................................................ 13
5.3 Arrangements by which coexistence of protocols may be supported by a network ......... 13
6 General principles applied for the functional control of supplementary services............................. 13
6.1 Introduction............................................................................................................... 13
6.2 Scope of the procedures ........................................................................................... 13
6.3 Categories of procedures .......................................................................................... 13
6.4 Supplementary service functions................................................................................. 14
7 Control of supplementary services using the separate message approach................................... 14
7.1 Hold and Retrieve functions........................................................................................ 15
7.1.1 Messages for the Hold and Retrieve function............................................ 15
7.1.2 Auxiliary states for the Hold and Retrieve function..................................... 15
7.2 Hold procedures........................................................................................................ 16
7.2.1 Initiating entity........................................................................................ 17
7.2.1.1 Normal operation............................................................ 17
7.2.1.2 Exceptional procedures................................................... 17
7.2.2 Responding entity................................................................................... 17
7.3 Call Held auxiliary state.............................................................................................. 18
7.4 Retrieve procedure.................................................................................................... 18
7.4.1 Initiating entity........................................................................................ 18
7.4.2 Responding entity................................................................................... 19
7.4.2.2 Exceptional procedures........................................................................... 19
7.5 Parameter values (timers).......................................................................................... 20
7.6 Clearing of a held call ................................................................................................ 20
8 Control of supplementary services using the common information element approach..................... 20
8.1 General .................................................................................................................... 20
8.1.1 Introduction............................................................................................ 20
8.1.2 Scope of the procedures......................................................................... 21
8.2 Application of operations............................................................................................ 21
8.2.1 Definitions.............................................................................................. 21
Page 4
ETS 300 196-1: August 1993
8.2.2 Procedures for operations....................................................................... 21
8.2.2.1 Invocation....................................................................... 21
8.2.2.2 Return result................................................................... 22
8.2.2.3 Return error ................................................................... 22
8.2.2.4 Reject ............................................................................ 22
8.2.2.5 Formal definition of Data Types ....................................... 24
8.3 Transport of components........................................................................................... 24
8.3.1 Bearer-related transport ......................................................................... 24
8.3.1.1 Point-to-point transport mechanism.................................. 24
8.3.1.1.1 Normal operation................................ 24
8.3.1.1.2 Exceptional procedures....................... 25
8.3.1.2 Broadcast transport mechanism....................................... 25
8.3.2 Bearer-independent transport .................................................................. 26
8.3.2.1 Point-to-point transport mechanism (connection-oriented) .. 26
8.3.2.1.1 Connection establishment.................... 26
8.3.2.1.2 Data transfer phase............................ 27
8.3.2.1.3 Connection release............................. 28
8.3.2.2 Point-to-point transport mechanism (connectionless).......... 29
8.3.2.3 Broadcast transport mechanism (connection-oriented) ....... 30
8.3.2.4 Broadcast transport mechanism (connectionless) .............. 30
8.4 Error procedures....................................................................................................... 31
8.4.1 Component error handling ....................................................................... 31
8.4.2 Error handling of mistyped data values..................................................... 31
8.5 Response to multiple supplementary service invocations............................................... 31
9 Generic notification procedures ................................................................................................ 31
9.1 General .................................................................................................................... 31
9.2 Categories of notification procedures.......................................................................... 32
9.3 Transport of bearer-related notifications...................................................................... 32
9.3.1 Normal operation.................................................................................... 32
9.3.2 Exceptional procedures........................................................................... 33
9.4 Transport of bearer-independent notifications .............................................................. 33
10 Other generic procedures ........................................................................................................ 33
10.1 Network-side channel reservation function................................................................... 33
10.1.1 Implicit reservation.................................................................................. 34
10.1.1.1 Implicit reservation creation ............................................. 34
10.1.1.2 Implicit reservation use.................................................... 35
10.1.1.3 Implicit reservation cancellation........................................ 35
10.1.2 Explicit reservation.................................................................................. 35
10.1.2.1 Explicit reservation control ............................................... 36
10.1.2.2 Explicit reservation management ...................................... 37
10.1.2.3 Explicit reservation cancellation........................................ 37
10.1.2.4 Effect of reservation on channel selection for a new call..... 38
10.1.2.5 Interaction between implicit and explicit network-side
channel reservation functions on the same CEI.................. 38
Page 5
ETS 300 196-1: August 1993
10.2 Generic procedures for supplementary service management ........................................ 38
10.2.1 Introduction............................................................................................ 38
10.2.2 Activation............................................................................................... 39
10.2.2.2 Activation exceptional procedures .................................... 40
10.2.3 Deactivation........................................................................................... 40
10.2.3.2 Deactivation exceptional procedures ................................ 41
10.2.4 Interrogation .......................................................................................... 41
10.2.4.2 Interrogation exceptional procedures................................ 42
10.2.5 Status notification................................................................................... 42
10.2.6 State definitions ..................................................................................... 43
10.2.7 Parameter values (timers)....................................................................... 43
10.3 Generic status request procedure .............................................................................. 44
10.3.1 Introduction............................................................................................ 44
10.3.4 Parameter values (timers)....................................................................... 47
11 Coding requirements................................................................................................................ 47
11.1 Message functional definitions and content .................................................................. 47
11.1.1 Additional messages for bearer-related supplementary service control ....... 48
11.1.1.1 FACILITY ...................................................................... 48
11.1.1.2 HOLD............................................................................ 48
11.1.1.3 HOLD ACKNOWLEDGE................................................. 49
11.1.1.4 HOLD REJECT .............................................................. 49
11.1.1.5 RETRIEVE..................................................................... 50
11.1.1.6 RETRIEVE ACKNOWLEDGE.......................................... 50
11.1.1.7 RETRIEVE REJECT....................................................... 51
11.1.2 Messages for bearer-independent supplementary service control............... 51
11.1.2.1 FACILITY ...................................................................... 51
11.1.2.2 REGISTER.................................................................... 52
11.1.2.3 RELEASE...................................................................... 52
11.1.2.4 RELEASE COMPLETE................................................... 53
11.1.2.5 STATUS ........................................................................ 54
11.1.2.6 STATUS ENQUIRY......................................................... 54
11.1.3 Messages used with the dummy call reference......................................... 55
11.1.3.1 FACILITY ...................................................................... 55
11.1.3.2 NOTIFY......................................................................... 55
11.2 General message format and information element coding............................................. 56
11.2.1 Message type........................................................................................ 56
11.2.2 Other information elements ..................................................................... 56
11.2.2.1 Facility........................................................................... 57
11.2.2.1.1 Treatment of existing ETS 300 102-1
information elements as parameters .... 57
11.2.2.2 Notification indicator........................................................ 58
11.2.2.3 Call state ....................................................................... 59
11.2.2.4 Extended facility information element................................ 59
Annex A (normative): Dynamic descriptions .................................................................................. 61
A.1 Dynamic description of the Hold and Retrieve functions .............................................................. 61
A.2 Dynamic description of the status request procedure ................................................................. 72
A.3 Dynamic description of the supplementary service management function ..................................... 76
Page 6
ETS 300 196-1: August 1993
Annex B (informative): Guidelines for the application of the generic procedures for the design of
individual supplementary services ................................................................. 85
B.1 Introduction............................................................................................................................. 85
B.2 Separate message category .................................................................................................... 85
B.2.1 Application of the separate message categories for new services defined by CCITT...... 85
B.2.2 Application of the separate message category for new services defined by ETSI ........... 85
B.2.3 Application of the separate message category for supplementary services defined by
other organisations.................................................................................................... 85
B.3 Common information element category...................................................................................... 85
B.3.1 Application of the common information element category for services defined by CCITT. 86
B.3.2 Application of the common information element category for services defined by ETSI ... 86
B.3.3 Application of the common information element category for supplementary services
defined by other organisations.................................................................................... 86
B.4 Notification category ................................................................................................................ 86
B.4.1 Application of the notification category for services defined by CCITT ........................... 87
B.4.2 Application of the notification category for services defined by ETSI.............................. 87
B.4.3 Application of the notification category for supplementary services defined by other
organisations ............................................................................................................ 87
Annex C (informative): ASN.1 subtypes and proposed mechanism for enhancements of the future
protocol...................................................................................................... 88
Annex D (normative): Formal definition of data types ..................................................................... 90
D.1 Component types .................................................................................................................... 90
D.2 Definition of generally applicable errors ..................................................................................... 91
D.3 Definition of address types....................................................................................................... 92
D.4 Definition of Q.931 information elements ................................................................................... 95
D.5 Formal definition of basic services ............................................................................................ 95
D.6 Operations and errors for explicit channel reservation control...................................................... 97
D.7 Operation for status request procedure..................................................................................... 99
D.8 Types for notification procedures............................................................................................ 100
Annex E (informative): Formal definition of remote operations notation............................................ 101
Annex F (informative): Coding examples....................................................................................... 102
F.1 Coding of component types.................................................................................................... 102
F.2 Embedding of existing ETS 300 102-1 information elements ..................................................... 104
Annex G (informative): Assignment of object identifier values.......................................................... 105
History ........................................................................................................................................... 106
Page 7
ETS 300 196-1: August 1993
Foreword
This European Telecommunication Standard (ETS) has been produced by the Signalling Protocols and
Switching (SPS) Technical Committee of the European Telecommunications Standards Institute (ETSI).
This ETS is part 1 of a multi-part standard covering the Digital Subscriber Signalling System No. one
(DSS1) protocol specification for the Integrated Services Digital Network (ISDN) generic functional
protocol for the support of supplementary services, as described below:
Part 1: "Protocol specification";
Part 2: "Protocol Implementation Conformance Statement (PICS) proforma specification";
Part 3: "Test Suite Structure and Test Purposes (TSS&TP) specification for the user";
Part 4: "Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing
(PIXIT) proforma specification for the user";
Part 5: "TSS&TP specification for the network";
Part 6: "ATS and partial PIXIT proforma specification for the network".
This reprint includes all previous Corrigenda as shown in the History box at the last page.
Page 8
ETS 300 196-1: August 1993
Blank page
Page 9
ETS 300 196-1: August 1993
1 Scope
This first part of ETS 300 196 specifies the functional protocol for the pan-European Integrated Services
Digital Network (ISDN) as provided by European public telecommunications operators for the application to
a range of supplementary services at the T reference point or coincident S and T reference point (as
defined in CCITT Recommendation I.411 [3]) by means of the Digital Subscriber Signalling System No. one
(DSS1) protocol.
The functional protocol is based on the use of the Facility information element and the FACILITY message,
as well as on other specific functional messages specified in subclause 11.1. The protocol is symmetrical,
and is applicable to both the basic and primary rate access structures.
To be functional this protocol requires knowledge of supplementary services supported by the user
equipment. This facilitates user equipment operation without human intervention by defining semantics for
the protocol elements which user equipment can process on its own.
The procedures specified in this ETS can be used for:
- activation and deactivation;
- invocation and operation;
- interrogation;
- status request; and,
- status notification.
of supplementary services in association with existing calls or outside any existing call.
In addition, this ETS specifies the generic procedures for the channel reservation function performed by the
network as it is applied by several supplementary services (e.g. call hold).
Furthermore, the functional signalling procedures that support the delivery of notifications at the user-
network interface are covered.
The application of this ETS to individual supplementary services is outside the scope of this ETS and is
defined in those standards which specify the individual supplementary services.
Further parts of this ETS specify the method of testing required to identify conformance to this ETS.
This ETS is applicable to equipment, supporting supplementary services using the functional protocol, to be
attached at either side of a T reference point or coincident S and T reference point when used as an
access to the public ISDN.
2 Normative references
This ETS incorporates by dated or undated reference, provisions from other publications. These normative
references are cited at the appropriate places in the text and the publications listed hereafter. For dated
references, subsequent amendments to or revisions of any of these publications apply to this ETS only
when incorporated in it by amendment or revision. For undated references the latest edition of the
publication referred to applies.
[1] CCITT Recommendation I.112 (1988): "Vocabulary of terms for ISDN".
[2] CCITT Recommendation I.210 (1988): "Principles of telecommunication services
supported by an ISDN and the means to describe them".
Page 10
ETS 300 196-1: August 1993
[3] CCITT Recommendation I.411 (1988): "ISDN user-network interfaces -
Reference configurations".
[4] CCITT Recommendation Q.9 (1988): "Vocabulary of switching and signalling
terms".
[5] CCITT Recommendation Q.931 (1988): "ISDN user-network interface layer 3
specification for basic call control".
[6] CCITT Recommendation X.208 (1988): "Specification of Abstract Syntax
Notation One (ASN.1)".
[7] CCITT Recommendation X.209 (1988): "Specification of Basic Encoding Rules
for Abstract Syntax Notation One (ASN.1)".
[8] CCITT Recommendation X.219 (1988): "Remote Operations: Model, Notation
and Service Definitions".
[9] CCITT Recommendation X.229 (1988): "Remote Operations: Protocol
Specification".
[10] CCITT Recommendation Z.100 (1988): "Specification and Description Language
(SDL)".
[11] ETS 300 052-1 (1991): "Integrated Services Digital Network (ISDN); Multiple
Subscriber Number (MSN) supplementary service; Digital Subscriber Signalling
System No. one (DSS1) protocol; Part 1: Protocol specification".
[12] ETS 300 061-1 (1991): "Integrated Services Digital Network (ISDN);
Subaddressing (SUB) supplementary service; Digital Subscriber Signalling
System No. one (DSS1) protocol; Part 1: Protocol specification".
[13] ETS 300 102-1 (1990): "Integrated Services Digital Network (ISDN); User-
network interface layer 3; Specifications for basic call control".
[14] ETS 300 122-1 (1992): "Integrated Services Digital Network (ISDN); Generic
keypad protocol for the support of supplementary services; Digital Subscriber
Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".
[15] ETS 300 125 (1990): "Integrated Services Digital Network (ISDN); User-network
interface data link layer specification; Application of CCITT Recommendations
Q.920/I.440 and Q.921/I.441".
[16] ETS 300 267-1: "Integrated Services Digital Network (ISDN); Telephony 7 kHz
and videotelephony teleservices; Digital Subscriber Signalling System No. one
(DSS1) protocol; Part 1: Protocol specification".
3 Definitions
3.1 General definitions
For the purpose of this ETS, the following definitions apply:
All services: if for the control of supplementary services the parameter basic service is set to "all
services", then all the basic services shall be affected that the user is subscribed to, and for which the
supplementary service applies and is subscribed to, at the point in time that the request is received.
Auxiliary state: a state as defined in subclause 7.1.2. An auxiliary state may exist for a call reference in
parallel with the call state.
Page 11
ETS 300 196-1: August 1993
Basic access: see CCITT Recommendation Q.9 [4], 1, definition 1551.
Basic service: a bearer service or teleservice. The terms "bearer service" and "teleservice" are defined in
CCITT Recommendation I.112 [1], 2.2, definitions 202 and 203.
Call control message: a message as defined in ETS 300 102-1 [13] subclause 3.1, which on sending or
receipt causes a change of the call state at either the network or the user. Call control messages also
include the INFORMATION message and PROGRESS message.
Call reference: (excluding dummy call reference) an identifier of a signalling transaction. The signalling
transaction may either be bearer related, in which case the signalling transaction can be used to control
that bearer, or bearer independent, in which case there is no bearer associated with that signalling
transaction. Where there is only one bearer required for a call, then the call reference of the associated
bearer-related signalling transaction may be used to identify the call.
Call state: a state as defined in ETS 300 102-1 [13] subclause 2.1 for either the user or the network as
appropriate. A call state may exist for each call reference value (and for each additional responding
Connection Endpoint Identifier (CEI) in the incoming call states).
Call: see CCITT Recommendation Q.9 [4], 2.2, definition 2201.
Component: data structure as defined in Annex D, Clause D.1.
Connection: see CCITT Recommendation Q.9 [4], 0, definition 0011. In this ETS the use of this term is
taken to include a bearer and its associated control signalling.
Data link connection endpoint identifier; Connection Endpoint Identifier (CEI): identifier used by a
layer 3 protocol entity to address its peer entity.
Dummy call reference: a null value indicating that the message is not applicable to an identified signalling
transaction. Other rules specify the association of DSS1 protocol entities.
Functional protocol: a functional protocol consists of a sequence of functional information elements. A
functional information element requires a degree of intelligent processing by a terminal in either generation
or analysis.
Initiator: an entity (user or network) requesting establishment of a signalling connection between an
initiator and the responder.
Integrated Services Digital Network (ISDN): see CCITT Recommendation I.112 [1], 2.3, definition
308.
Network: the DSS1 protocol entity at the network side of the user-network interface.
Primary rate access: see CCITT Recommendation Q.9 [4], 1, definition 1552.
Responder: the entity (user or network) responding to a request from an initiator on establishing a
signalling connection.
Service; telecommunications service: see CCITT Recommendation I.112 [1], 2.2, definition 201.
Signalling connection: an association of DSS1 protocol entities using the bearer-independent
supplementary service procedure with the connection-oriented transport mechanism.
Stimulus protocol: a stimulus protocol consists of a sequence of stimulus information elements. A
stimulus information element is generated as a result of a single event at the user-network interface or
contains a basic instruction from the network to be executed by the user.
Supplementary service: see CCITT Recommendation I.210 [2], 2.4.
Page 12
ETS 300 196-1: August 1993
User: the DSS1 protocol entity at the user side of the user-network interface.
3.2 Remote Operations definitions
The common information element category makes use of the following terms defined in CCITT
Recommendation X.219 [8]:
- Remote Operation;
- Operation;
- Operation classes (class 1 to class 5);
- Association (initiator; responder);
- Invoking (application entity; invoker).
Invoke component: see subclause 8.2.2.1. Where reference is made to an "xxxx" invoke component, an
invoke component is meant with its operation value set to the value of the operation "xxxx".
Return result component: see subclause 8.2.2.2. Where reference is made to an "xxxx" return result
component, a return result component is meant which is related to an "xxxx" invoke component.
Return error component: see subclause 8.2.2.3. Where reference is made to an "xxxx" return error
component, a return error component is meant which is related to an "xxxx" invoke component.
Reject component: see subclause 8.2.2.4.
3.3 Definition of procedures using the common information element approach
Bearer-related transport mechanism: a procedure tied to the procedures for basic call control and tied
to a connection in progress, active or in the clearing phase. The call reference used by the basic call
control procedure is adopted by the bearer-related service invocations to correlate with the appropriate
basic call control transaction.
Bearer-independent transport mechanism: a procedure independent of the procedures for basic call
control and not correlated to a connection.
Connection-oriented transport mechanism: a mechanism requiring the establishment of a data link and
a transport association between the service requesting entity and the service provider. It provides a facility
to access common information element category operations where success and/or failure reporting is
required. It provides a call reference within the transport association as a means to associate uniquely
among the related transport messages.
Connectionless transport mechanism: a mechanism where no transport association exists but a single
transport message transfer is provided using the dummy call reference.
4 Symbols and abbreviations
For the purpose of this ETS, the following abbreviations apply:
ASN.1 Abstract Syntax Notation One
BER Basic Encoding Rules
CEI Connection Endpoint Identifier
DSS1 Digital Subscriber Signalling System No. one
ISDN Integrated Services Digital Network
LSB Least Significant Bit
MSB Most Significant Bit
ROSE Remote Operations Service Element
SDL Specification and Description Language
Page 13
ETS 300 196-1: August 1993
5 Coexistence of generic protocols for the control of supplementary services
5.1 Support of various generic protocols
Networks may support more than one generic protocol for the control of supplementary services, e.g. the
keypad protocol and the functional protocol. The support of multiple generic protocols is a network option.
Users shall be informed by the service provider at subscription time of the supplementary services
available, and of the generic protocols supported on their access.
5.2 Coexistence of generic protocols
As a general rule, the functional protocol shall be used unless the network specifies the use of a stimulus
protocol for the control of certain supplementary services.
Networks may support one or more of the generic protocols; it is a network option as to whether one or
more generic protocols are supported on a given access.
In general, the keypad protocol, as defined in ETS 300 122-1 [14], has only local significance while the
functional protocol may have other than local significance.
For a given call instance, the protocol applied at a local interface may be different from the one applied at
a remote user's interface. For example, one of the stimulus protocols may be used at the requesting user's
interface, while a functional protocol may be applied at the remote user's interface.
5.3 Arrangements by which coexistence of protocols may be supported by a network
Some networks may support only one of the generic protocols per user access for the control of
supplementary services. Other networks may choose to support a single generic protocol for the control of
supplementary services, depending on the user-network interface type (e.g. keypad on the basic access,
functional on the basic access and primary rate access). This has to be arranged at subscription time.
Networks supporting multiple generic protocols per access in the user-to-network direction will implicitly
recognise the protocol option chosen by the user on the basis of the received message type or information
element type.
Networks supporting multiple generic protocols per access in the network-to-user direction (i.e. at the
remote-user interface) may choose to apply a particular protocol depending on the supplementary services
involved.
6 General principles applied for the functional control of supplementary
services
6.1 Introduction
This Clause specifies the general principles applied for the functional control of supplementary services at
the user-network interface. The generic protocol utilises functions and services provided by
ETS 300 102-1 [13] basic call control procedures and the functions of the data link layer as defined in
ETS 300 125 [15].
6.2 Scope of the procedures
The procedures defined in Clauses 7 to 10 specify the basic methodology for the control (e.g. invocation,
notification, deactivation, etc.) of supplementary services. The procedures are independent of whether or
not the user-network interface is at a basic or primary rate access.
6.3 Categories of procedures
Two categories of procedures are defined for the functional control of supplementary services. The first
category, called the separate message approach, utilises separate message types to indicate a desired
Page 14
ETS 300 196-1: August 1993
function. The HOLD and RETRIEVE family of messages are used for this category. This approach is used
when synchronisation of resources between the user and the network is required.
The second category, called the common information element approach, utilises the Facility information
element and applies only to supplementary services that do not require synchronisation of resources
between the user and the network.
Both categories are specified in a symmetrical manner and can be signalled both in the network-to-user
and the user-to-network directions.
6.4 Supplementary service functions
The control of supplementary services by either the network or the user includes the following functions:
a) the control of supplementary services during the establishment of a call;
b) the control of supplementary services during the clearing of a call;
c) the control of bearer-related supplementary services during the Active call state of a call;
d) the control of supplementary services independent from an active call;
e) the control of multiple, different supplementary services within a single message;
f) the control of supplementary services related to different calls;
g) the provision of notifications.
The correlation of a bearer-related supplementary service and the call which it modifies is provided by use
of the call reference [functions a), b), c), e), f) and g) listed above].
The correlation of bearer-independent supplementary service requests and their responses, is provided by
the combination of the call reference of the message containing the Facility information element and the
invoke identifier present within the Facility information element itself [refer to functions d), e) and g)].
The identification of different supplementary service requests within one single message is provided by the
invoke identifier of the corresponding Facility information element [refer to functions e) and g)]. The
identification of supplementary service requests related to different calls is provided by different messages
with the corresponding call reference of the appropriate call and connection [refer to function f)], i.e.
different call reference values are used to identify each call individually.
7 Control of supplementary services using the separate message approach
The messages defined in this Clause are specified as separate functional messages for invoking specific
functions which require changes of the resources and auxiliary states and also require synchronization of
the peer-to-peer state machines. These functions cannot be performed in conjunction with the call
establishment and clearing procedures relying on call states alone. They are used in conjunction with a
two-dimensioned state model which enables the specification of functions which require synchronization of
resources in the context of call establishment and call clearing procedures. These functions may be used
to perform various supplementary service applications. The functions of these messages are not to be
duplicated or overlapped by those of the common information element approach.
Page 15
ETS 300 196-1: August 1993
7.1 Hold and Retrieve functions
7.1.1 Messages for the Hold and Retrieve function
The Hold function is used to release a B-channel from a connection. The call reference of the held call shall
be retained for subsequent call actions.
The Retrieve function is used to reconnect a B-channel to the connection.
The Hold and Retrieve functions may be used in a symmetrical manner, i.e. the initiator of a hold request or
a retrieve request may reside at either side of the interface. Furthermore, the initiating entity of the Hold
function can be the responding entity of the Retrieve function, and vice versa.
The invocation of the Hold or Retrieve function does not affect the existing call state.
The Hold and Retrieve procedures use the following messages which are defined in subclauses 11.1.1.2 to
11.1.1.7.
- HOLD;
- HOLD ACKNOWLEDGE;
- HOLD REJECT;
- RETRIEVE;
- RETRIEVE ACKNOWLEDGE;
- RETRIEVE REJECT.
The error handling procedures defined in subclause 5.8 of ETS 300 102-1 [13] are applicable to these
messages.
NOTE: The Hold and Retrieve functions do not support calls requiring more than one
connection.
7.1.2 Auxiliary states for the Hold and Retrieve function
The Hold and Retrieve function may be performed in the call states specified in subclause 7.2.1.1. The
concept of a two dimensional state model is being introduced to ensure state synchronization between the
user and the network. In this way, two states will be associated with each call. The first will be an
ETS 300 102-1 [13] call state and the second will be an auxiliary state associated with the Hold and
Retrieve function. If a call state transition occurs, the first coordinate is updated. If a call is put on hold, the
second coordinate is updated. When the held call is reconnected, the second coordinate is updated again.
There shall be six auxiliary states associated with the Hold and Retrieve functions:
- Idle;
- Hold Request: a request has been made for the Hold function;
- Hold Indication: a request has been received for the Hold function;
- Call Held: the call is held;
- Retrieve Request: a request has been made for the Retrieve function;
- Retrieve Indication: a request has been received for the Retrieve function.
Page 16
ETS 300 196-1: August 1993
If the call state enters the Idle call state or one of the call states not listed in subclause 7.2.1.1 with the
exception of the U12, N12 Disconnect Indication call state then:
- for a call in the Hold Request or Retrieve Request auxiliary state, the entity shall stop the
appropriate timer (i.e. T-HOLD or T-RETRIEVE) and enter the Idle auxiliary state;
- for a call in the Hold Indication, Retrieve Indication or Call Held auxiliary state, the entity shall enter
the Idle auxiliary state.
If the call enters the U12, N12 Disconnect Indication call state then:
- for a call in the Hold Request auxiliary state, the entity shall stop the appropriate timer (i.e. T-HOLD)
and enter the Idle auxiliary state;
- for a call in the Hold Indication auxiliary state, the entity shall enter the Idle auxiliary state;
- for a call in the Call Held or Retrieve Request or Retrieve Indication auxiliary state, no change in
auxiliary state shall occur.
EXAMPLE: When a call is in the Outgoing Call Proceeding call state, the two-dimensioned
state shall be:
(Outgoing Call Proceeding, Idle).
Then the user requests the Hold function, the two-dimensioned state shall
become:
(Outgoing Call Proceeding, Hold Request).
The call shall then be put on hold. The user shall become aware of this upon
receiving the HOLD ACKNOWLEDGE message from the network. The two-
dimensioned state shall now be:
(Outgoing Call Proceeding, Call Held).
The user may receive subsequent call progress messages which shall change
the two-dimensioned state to:
(Active, Call Held).
Then the user requests the Retrieve function. The two-dimensioned state shall
become:
(Active, Retrieve Request).
When the call is reconnected, the two-dimensioned state shall be:
(Active, Idle).
7.2 Hold procedures
If both sides of an interface have requested the Hold function, a message collision pertaining to a given call
reference may occur. In this case priority shall be given to the network initiated Hold function according to
the procedure of subclause 7.2.2.1.
Page 17
ETS 300 196-1: August 1993
7.2.1 Initiating entity
7.2.1.1 Normal operation
The Hold function shall be initiated by sending a HOLD message containing the call reference of the call to
be put on hold to the responding entity. On sending of the HOLD message, the initiating entity shall start
timer T-HOLD (the value of timer T-HOLD is specified in subclause 7.5), enter the Hold Request auxiliary
state and wait for a HOLD ACKNOWLEDGE message. The auxiliary states are described in
subclause 7.1.2.
The call to be put on hold shall be allocated to a single Connection Endpoint Identifier (CEI), and a B-
channel must be selected for the call and/or for the CEI. Therefore the Hold function shall only be invoked
in the Idle auxiliary state and the following call states:
- Outgoing Call Proceeding (U3, N3);
- Call Delivered (U4, N4);
- Call Received (U7, N7) (NOTE);
- Connect Request (U8, N8) (NOTE);
- Incoming Call Proceeding (U9, N9) (NOTE);
- Active (U10, N10).
NOTE: Applicable only if a point-to-point configuration exists.
On receipt of a HOLD ACKNOWLEDGE message in the Hold Request auxiliary state the initiating entity
shall stop timer T-HOLD, release the B-channel and enter the Call Held auxiliary state.
7.2.1.2 Exceptional procedures
On receipt of a HOLD REJECT message in the Hold Request auxiliary state, the initiating entity shall stop
timer T-HOLD and enter the Idle auxiliary state.
If timer T-HOLD expires, the initiating entity shall enter the Idle auxiliary state.
7.2.2 Responding entity
On receipt of a HOLD message:
- in the Idle auxiliary state and one of the call states specified in subclause 7.2.1.1, the responding
entity shall enter the Hold Indication auxiliary state and determine whether the Hold function is
permitted;
- in the Hold Request auxiliary state for the user, the responding entity shall stop timer T-HOLD, enter
the Hold Indication auxiliary state and determine whether the Hold function is permitted;
- in the Hold Request auxiliary state for the network, the responding entity shall ignore the received
HOLD message and remain in the Hold Request auxiliary state.
Determination of whether the Hold function is permitted is supplementary service specific and shall be
specified in the appropriate supplementary service ETS.
If the Hold function is permitted, the responding entity shall release the B-channel, send a HOLD
ACKNOWLEDGE message to the initiating entity and enter the Call Held auxiliary state.
Page 18
ETS 300 196-1: August 1993
If the HOLD message is received in an auxiliary state other than Idle and Hold Request, then the receiving
entity shall send a HOLD REJECT message with cause #101 "message not compatible with call state" to
the initiating entity and remain in the same auxiliary state it was in prior to the reception of the HOLD
message.
If the HOLD message is received in a call state not listed in subclause 7.2.1.1, except for the call states
U12, N12 Disconnect Indication, and U19, N19 Release Request, then the responding entity shall send a
HOLD REJECT message with cause #101 "message not compatible with call state" to the initiating entity
and remain in the Idle auxiliary state.
If the HOLD message is received for a call in the process of being cleared which is in the call states U12,
N12 Disconnect Indication or U19, N19 Release Request, the responding entity shall ignore the request
and remain in the Idle auxiliary state.
If the Hold function is not permitted, then the responding entity shall send a HOLD REJECT message
containing an appropriate cause to the initiating entity and remain in the Idle auxiliary state. The cause
value shall be specified in the appropriate supplementary service ETS.
7.3 Call Held auxiliary state
While in the Call Held auxiliary state, a B-channel shall not be allocated even if an event occurs that would
cause a B-channel connection according to the procedures of ETS 300 102-1 [13] (e.g. receipt of a
CONNECT message).
7.4 Retrieve procedure
If both sides of an interface have implemented the Retrieve function as both initiating and responding entity,
a message collision pertaining to a given call reference may occur. In this case priority shall be given to the
network initiated Retrieve function according to the procedure of subclause 7.4.2.1.
7.4.1 Initiating entity
The Retrieve function shall be initiated by sending a RETRIEVE message containing the call reference of
the held call to the responding entity.
The RETRIEVE message shall only be sent in the Call Held auxiliary state.
On sending the RETRIEVE message, the initiating entity shall start timer T-RETRIEVE (the value of timer
T-RETRIEVE is specified in subclause 7.5), enter the Retrieve Request auxiliary state and wait for a
RETRIEVE ACKNOWLEDGE message.
The Retrieve function shall provide channel selection procedures according to ETS 300 102-1 [13]
subclause 5.1.2 (if the RETRIEVE message is sent by the user) or according to subclause 5.2.3.2 (if the
RETRIEVE message is sent by the network), using the Channel identification information element in the
RETRIEVE message. If the RETRIEVE message is sent by the network, the network shall not use the
codepoint "no B-channel available" in the Channel identification information element.
If the initiating entity indicated "Channel is indicated, no acceptable alternative" or "Channel is indicated,
any alternative acceptable" in the RETRIEVE message then on receipt of a RETRIEVE ACKNOWLEDGE
message without a Channel identification information element, the initiating entity shall stop timer T-
RETRIEVE, connect to the selected B-channel if appropriate for this call state under normal operation, and
enter the Idle auxiliary state.
If the initiating entity did not indicate "Channel is indicated, no acceptable alternative" in the RETRIEVE
message then on receipt of a RETRIEVE ACKNOWLEDGE message, with a Channel identification
Page 19
ETS 300 196-1: August 1993
information element, the initiating entity shall stop timer T-RETRIEVE, connect to the indicated B-channel
and enter the Idle auxiliary state.
On receipt of a RETRIEVE REJECT message in the Retrieve Request auxiliary state the initiating entity
shall stop timer T-RETRIEVE, release the B-channel, if applicable, and enter the Call Held auxiliary state.
At expiration of timer T-RETRIEVE, the initiating entity shall release the B-channel if applicable, and enter
the Call Held auxiliary state.
7.4.2 Responding entity
On receipt of a RETRIEVE message:
- in the Call Held auxiliary state, the responding entity shall complete B-channel selection procedures
according to the procedures of ETS 300 102-1 [13] subclause 5.1.2 (if the RETRIEVE message is
received by the network) or according to subclause 5.2.3.2 (if the RETRIEVE message is received
by the user), enter the Retrieve Indication auxiliary state and determine whether the Retrieve
function is permitted;
- in the Retrieve Request auxiliary state, the user shall stop timer T-RETRIEVE, release the B-channel
if one has been selected, complete B-channel selection procedures according to the procedures of
ETS 300 102-1 [13] subclause 5.2.3.2, enter the Retrieve Indication auxiliary state and determine
whether the Retrieve function is permitted;
- in the Retrieve Request auxiliary state, the network shall ignore the received RETRIEVE message
and remain in the Retrieve Request auxiliary state.
Determination of whether the Retrieve function is permitted is supplementary service dependent and shall
be specified in the appropriate supplementary service ETS.
If the Retrieve function is permitted the responding entity shall:
- if in the Active call state, connect to the selected B-channel and if not in the Active call state,
optionally connect to the selected B-channel; and,
- send a RETRIEVE ACKNOWLEDGE message to the initiator;
- if the responding entity selected the B-channel, then the RETRIEVE ACKNOWLEDGE message
shall indicate the selected B-channel to be used as "Channel is indicated, no acceptable alternative"
in a Channel identification information element; and,
NOTE: If the responding entity accepts the B-channel indicated in the RETRIEVE message,
then the responding entity need not include a Channel identification information element
in the RETRIEVE ACKNOWLEDGE message.
- enter the Idle auxiliary state.
If the RETRIEVE message is received in an auxiliary state other than Call Held and Retrieve Request, then
the receiving entity shall send a RETRIEVE REJECT message with cause #101 "message not compatible
with call state" to the initiating entity and remain in the same auxiliary state it was in prior to the reception
of the RETRIEVE message.
If the RETRIEVE message is received in the Call Held auxiliary state and other than the call states as
listed in subclause 7.2.1.1 and in addition call state U12, N12 Disconnect Indication, then the responding
Page 20
ETS 300 196-1: August 1993
entity shall respond with a RETRIEVE REJECT message containing cause #101 "message not compatible
with call state" and remain in the Call Held auxiliary state.
If a RETRIEVE message indicates an "exclusive" B-channel, and that channel is not available to retrieve
the held call, then the receiving entity shall send a RETRIEVE REJECT message with cause value #44
"requested circuit/channel not available" to the initiating entity.
If a RETRIEVE message indicates a "preferred" or "any" B-channel, or if a Channel identification
information element is not included, and no channel is available to retrieve the held call, then the receiving
entity shall send a RETRIEVE REJECT message with cause value #34 "no B-channel available" to the
initiating entity.
If the Retrieve function is not permitted then the responding entity shall send a RETRIEVE REJECT
message containing an appropriate cause to the initiating entity and move to the Call Held auxiliary state.
The cause value shall be specified in the appropriate supplementary service ETS.
7.5 Parameter values (timers)
Table 1 shows the timers used for the Hold function and the Retrieve function.
Table 1
|Timer |Time out |Cause for |Normal stop |At expiry |

|value |value |start | | |
||||||
|T-HOLD |4 s |HOLD sent |Receipt of |Return to Idle |
| | | |HOLD ACKNOWLEDGE |auxiliary state|
| | | |or | |
| | | |HOLD REJECT | |
||||||
|T-RETRIEVE|4 s |RETRIEVE sent|Receipt of |Return to Call |
| | | |RETRIEVE ACKNOWLEDGE|Held auxiliary |
| | | |or |state |
| | | |RETRIEVE REJECT | |
!++++!
7.6 Clearing of a held call
A call in the Call Held auxiliary state may be cleared in either direction by sending a DISCONNECT
message via the user-network interface in accordance with the call clearing procedure of
ETS 300 102-1 [13] subclause 5.3. On receiving or sending of a RELEASE COMPLETE message the held
call shall move to the Idle auxiliary state.
8 Control of supplementary services using the common information element
approach
8.1 General
8.1.1 Introduction
In the common information element approach the Facility information element and the Extended facility
information element are used to transport information for the control of supplementary services, conveying
components as application-oriented elements complemented by the necessary procedures for operations
and transport mechanisms. Operations and transport mechanisms may either be related to a connection or
may be used independent of a connection.
The common information element approach is modelled as remote operations as specified in CCITT
Recommendation X.219 [8] and X.229 [9]. According to this model, one entity requests that a particular
operation be performed whereas the responding entity attempts to perform the operation and responds to
the invoking entity. Therefore an operation of the common information element approach is regarded as a
request/reply interaction, supported by the application function and carried out within the context of an
application association (for definitions see Clause 3).
Page 21
ETS 300 196-1: August 1993
An error is used to report the unsuccessful outcome of an operation. For each operation the appropriate
errors, if required, need to be indicated.
In the following part of this Clause 8 each time the term "Facility information element" is used this shall be
interpreted as "Facility or Extended facility information element".
8.1.2 Scope of the procedures
The common information element approach applies only to supplementary services where no
synchronization of resources is required between the two signalling entities. However, the user equipment
is required to have the capability to track the operation of the supplementary service procedures through
various states.
8.2 Application of operations
8.2.1 Definitions
For the appropriate definitions see Clause 3.
8.2.2 Procedures for operations
The specification of procedures for operations of this subclause is in alignment with the definition of
elements of procedure of CCITT Recommendation X.229 [9] but uses only those elements which are
specified for application within the Facility information element of this ETS. In addition, this subclause
includes some extensions to ROSE concerning the error procedures.
The common information element approach procedures for operations are defined in terms of the
interactions between peer-to-peer protocol machines through the use of a transport mechanism of the
DSS1 protocol. The operation protocol comprises of the following procedures:
- invocation;
- return result;
- return error; and,
- reject.
The structure, contents and encoding of the appropriate components are defined in Clause 11 of this ETS.
Dependent on the specific operation, return result and return error components can be applicable. This is
specified in the ETSs of the individual supplementary services.
In the following subclauses a summary of the procedures of each of these components is given as far as
applicable to this ETS.
8.2.2.1 Invocation
An application entity (invoker) shall use the invocation procedure to initiate an operation to be performed by
the other application entity (performer). The invocation procedure shall use the invoke component as
described in table D.1. The invoke component shall be delivered towards the remote peer entity within a
Facility information element sent within an appropriate transport message (e.g. call control messages,
FACILITY or REGISTER).
The operation value shall be used to identify the operation to be invoked, e.g. a specific supplementary
service, a part of a specific supplementary service or a generic function.
The invoke identifier shall be used to identify the request of a ROSE-invoke service (CCITT
Recommendation X.219 [8], 10.1) and to correlated this request with the corresponding replies. The
value is assigned by the invoker.
Page 22
ETS 300 196-1: August 1993
The invoke identifier shall be significant within a certain call reference value. The value (invoke identifier,
call reference, data link connection endpoint identifier) shall uniquely identify an instance of an operation. In
this respect the dummy call reference shall be regarded as a call reference as well.
An invoke identifier value shall not be re-used as long as a response is expected pertaining to the
invocation identified by this invoke identifier.
The linked identifier shall be used within a ROSE-invoke service (CCITT Recommendation X.219 [8],
10.1), when the invoked operation is a child operation and this parameter identifies the linked parent
operation.
8.2.2.2 Return result
An application entity (performer) shall use the return result procedure to request the transfer of the result
of a successfully performed operation to the other application entity (invoker). The return result procedure
shall use the return result component as described in table D.1.
The return result component shall be delivered towards the remote peer entity in a Facility information
element within an appropriate transport message.
8.2.2.3 Return error
An application entity (performer) shall use the return-error procedure to request the transfer of the error
information in the case of an unsuccessfully performed operation to the other application entity (invoker).
The return error procedure shall use the return error component as described in table D.1. Error values
shall be defined specifically for each individual operation.
The return error component shall be delivered towards the remote peer entity in a Facility information
element within an appropriate transport message.
8.2.2.4 Reject
An application entity shall use the reject procedure to reject the request (invocation) or reply (result or
error) of the other application entity. The reject procedure shall be used by the receiver when the received
request or reply cannot be processed because of errors in the received component (e.g. mistyped
component or unrecognised operation). The receipt of a reject component shall not result in the start of a
reject procedure.
The reject procedure shall use the reject component as described in table D.1 and shall use the definition
of problems as specified in table 2. The reject component shall be delivered towards the remote peer
entity in a Facility information element within an appropriate transport message.
Table 2: Problem code definitions
General-problem
- unrecognized-component signifies that the type of the component, as evidenced by its type
identifier, is not one of the four defined in Annex D, Clause D.1 of this
ETS
- mistyped-component signifies that the structure of the component does not conform to
Annex D, Clause D.1 of this ETS
- badly-structured-component signifies that the structure of the components does not conform to
the standard notation and encoding, defined in CCITT
Recommendations X.208 [6] and X.209 [7]
Page 23
ETS 300 196-1: August 1993
Table 2: Problem code definitions (concluded)
Invoke-problem
- duplicate-invocation signifies that the invoke-identifier parameter violates the assignment
rules of CCITT Recommendation X.219 [8]
- unrecognized-operation signifies that the operation is not one of those agreed between the
user and the network
- mistyped-argument signifies that the type of the operation argument supplied is not that
agreed between the user and the network (NOTE 2)
- resource-limitation the performing user or network is not able to perform the invoked
operation due to resource limitation
- initiator-releasing the application is not willing to perform the invoked operation
because it is about to attempt to release the connection oriented
transport mechanism
- unrecognized-linked-identifier signifies that there is no operation in progress with an invoke-
identifier equal to the specified linked-identifier
- linked-response-unexpected signifies that the invoked operation referred to by linked-identifier is
not a parent-operation
- unexpected-child-operation signifies that the invoked child-operation is not one that the invoked
parent-operation referred to by the linked-identifier allows
Return-result-problem
- unrecognized-invocation signifies that no operation with the specified invoke-identifier is in
progress
- result-response-unexpected signifies that the invoke operation does not report a result
- mistyped-result signifies that the type of the result parameter supplied is not that
Return-error-problem
- unrecognized-invocation signifies that no operation with the specified invoke-identifier is in
progress
- error-response-unexpected signifies that the invoked operation does not report failure
- unrecognized-error signifies that the reported error is not one of those agreed between
the user and the network
- unexpected-error signifies that the reported error is not one that the invoked operation
may report
- mistyped-parameter signifies that the type of the error parameters supplied is not that
NOTE 1: The above definitions are adapted from 7.4.4.2 and 7.5.4.2 of CCITT
Recommendation X.229 [9].
Page 24
ETS 300 196-1: August 1993
NOTE 2: This problem code shall not be used if all values (data elements) which are neither
optional nor have default values assigned are correctly received (see subclause 8.4.2).
8.2.2.5 Formal definition of Data Types
The formal definition of the OPERATION and ERROR macro shall be as given in figure 4/X.219 of CCITT
Recommendation X.219 [8] and is described in ASN.1 using the ASN.1 macro concept. These macros shall
be used in the ETSs of the individual supplementary services to define the required operations and errors.
NOTE: These definitions are reproduced in Annex E.
8.3 Transport of components
The transport function for operations is performed by the exchange of components via DSS1-messages as
specified in ETS 300 102-1 [13] and in Clause 11 of this ETS. Procedures described in subclause 8.3
specify the rules governing the relation between supplementary service operations and basic call control
messages.
A supplementary service functional protocol (using the Facility information element) may use an existing
bearer-related call reference if it is to be coupled to the connection, or it may use a bearer-independent
call reference.
8.3.1 Bearer-related transport
NOTE: The definition of "Bearer-related transport mechanism" is given in subclause 3.3.
This subclause defines the transport of components using the messages for the establishment and the
clearing of connections. The procedures for connection control are described in ETS 300 102-1 [13],
Clause 5. These procedures are not influenced by the components carried. Bearer-related transport
procedures and operations shall operate independently of each other, however operations shall follow the
specified procedures and transport capabilities of bearer connections according to basic call control
(ETS 300 102-1 [13]).
The bearer-related transport mechanisms are divided into the following two categories:
- point-to-point transport mechanism;
- broadcast transport mechanism.
8.3.1.1 Point-to-point transport mechanism
8.3.1.1.1 Normal operation
For bearer-related point-to-point transport of components the call state of the bearer connection must be
in a state (or about to enter a state) other than the Null call state (U0, N0). For transport, any call control
message as defined in ETS 300 102-1 [13] subclause 3.1 (except STATUS, STATUS ENQUIRY and
NOTIFY, see subclause 11.2.2.1 of this ETS), and the messages defined in subclause 11.1.1 of this ETS,
may be used to carry the components in a Facility information element.
For general rules, format and coding of call reference values, subclause 4.3 of ETS 300 102-1 [13] is
applicable.
The call reference provides the means to correlate messages belonging to the same signalling transaction
of a connection. When a supplementary service affects more than one connection, different call references
are used to identify each connection individually. This implies the use of different messages in order to
manage each connection separately.
The implicit call-control association provided by an ETS 300 102-1 [13] call reference shall always be
cleared when a connection is released.
Page 25
ETS 300 196-1: August 1993
The Cause information element shall only be used to report ETS 300 102-1 [13] errors outside the
component portion of the Facility information element (octets 1-3). When no ETS 300 102-1 [13] protocol
error is found, the Cause information element shall convey cause #31 "normal unspecified". For protocol
errors in the component portion of the Facility information element (octets 4, etc.) see subclause 8.4.1.
8.3.1.1.2 Exceptional procedures
If for some reason the network or user recognises a supplementary service request but is not able to
process the bearer-related invocation of a supplementary service contained in a received SETUP
message, then the following options shall apply:
- the network or user may clear the call request and reject the supplementary service invocation by
means of an appropriate call-clearing message which contains the Cause information element and a
return error or reject component type with the appropriate parameters in the Facility information
element;
- the network or user may continue to process the call request according to the call control
procedures of ETS 300 102-1 [13], and reject the supplementary service invocation by including a
return error or reject component type with the appropriate parameters in the Facility information
element by means of a FACILITY message or in an appropriate call control message;
- the network or user may continue to process the call request according to the call control
procedures of ETS 300 102-1 [13], and ignore the supplementary service invocation.
The option to be used depends on the individual supplementary service procedures which are the subject
of other ETSs.
If the user, or network, begins clearing and there is an outstanding request, the network, and user, shall
continue with the clearing procedures. If the call reference value is released before a response can be
sent, the resulting status of the supplementary service depends on the individual supplementary service
specifications which are the subject of other ETSs. No response message shall be sent after the call
reference value has been released.
The procedures of subclause 8.3.1.1 are an extension to the procedures of ETS 300 102-1 [13] and as
such the general error handling procedures as defined in subclause 5.8 of ETS 300 102-1 [13] apply. The
handling of errors in components is specified in subclause 8.4 of this ETS. The procedures for the
treatment of outstanding supplementary service requests is subject to the ETSs for the individual
supplementary services.
8.3.1.2 Broadcast transport mechanism
If it is required for the network to deliver a component to the user in a SETUP message and a multipoint
configuration exists, then the network shall include the component in a Facility information element in the
SETUP message, and send the SETUP message to the user according to the procedures of
subclause 5.2.1 of ETS 300 102-1 [13].
On receipt of a SETUP message containing a component, the user shall proceed according to
subclause 8.3.1.1. In response to a broadcast supplementary service invocation the network may receive
different basic call control messages (ALERTING, RELEASE COMPLETE, CALL PROCEEDING etc.)
carrying different component-types (e.g. Return result, Return error). The processing of these responses
is application dependent and shall be specified in the context of the individual supplementary services. After
processing of the responses on a broadcasted invocation the transport mechanism is in the point-to-point
mode and follows the procedures as specified in subclause 8.3.1.1.
The user shall not send a FACILITY message in call state Call Present (U6), i.e. as a first response to a
broadcasted SETUP message.
Page 26
ETS 300 196-1: August 1993
The exceptional procedures for receipt of a component on the broadcast data link are given in
subclause 8.3.1.1.2.
8.3.2 Bearer-independent transport
This subclause defines the transport functions employed for operations independent of a connection. These
transport functions are provided at the user-network interface by means of message exchange according
to ETS 300 102-1 [13] and this ETS and utilises the data link services as described in ETS 300 125 [15].
The messages used for transport (i.e. REGISTER, FACILITY, RELEASE and RELEASE COMPLETE)
carry the Facility information elements containing the application oriented operation components.
The context among the various transport messages is provided by means of the call reference value of
each message.
For general rules, format and coding of call reference values see subclause 4.3 of ETS 300 102-1 [13].
The bearer-independent transport functions are divided into the following four categories:
- point-to-point (connection-oriented) (NOTE);
- point-to-point (connectionless) (NOTE);
- broadcast (connection-oriented);
- broadcast (connectionless).
NOTE: A definition of the terms "connection-oriented" and "connectionless" is given in
subclause 3.3.
Within this subclause, DL-service primitives are used to illustrate the communication between protocol
layers and are not intended to specify or constrain implementations.
8.3.2.1 Point-to-point transport mechanism (connection-oriented)
The transport mechanism described in this subclause is symmetrical, i.e. both the user and the network
can initiate the procedure. Therefore the procedures in this subclause use the terms initiator and responder
instead of user and network.
For the purpose of this transport mechanism the following call states are identified:
- Null (U0, N0): No signalling connection exists;
- Bearer Independent Transport (U31, N31): This state exists when a signalling connection is active;
- Release Request (U19, N19): This state exists when a protocol entity has requested the peer entity
to release the signalling connection and is waiting for a response.
8.3.2.1.1 Connection establishment
8.3.2.1.1.1 Normal operation
To establish a signalling connection towards the responder, the initiator shall first establish, if not already
available, a reliable data link connection between the initiator and the responder using the DL-ESTABLISH-
REQUEST service primitive as described in ETS 300 125 [15]. Establishment of the data link connection is
confirmed by the DL-ESTABLISH-CONFIRM primitive. Only this data link connection shall be used by the
connection-oriented transport mechanism.
Page 27
ETS 300 196-1: August 1993
Once the data link has been established the initiator shall initiate establishment of the signalling connection
by sending a REGISTER message towards the responder using the DL-DATA-REQUEST service primitive
and enter the Bearer Independent Transport call state (U31/N31). The responder, on receiving the
REGISTER message, shall also enter the Bearer Independent Transport call state (N31/U31).
The signalling connection is identified by the call reference included in the REGISTER message. The call
reference value shall be chosen in compliance to the procedures of ETS 300 102-1 [13] subclause 4.3.
The initiator may send data (i.e. the component structures) to the responding entity by including a Facility
information element in a REGISTER message.
NOTE: If the REGISTER message contains a Facility information element a clear distinction
between connection establishment and data transfer phase cannot be made.
8.3.2.1.1.2 Exceptional procedures
If a REGISTER message is received indicating a call reference value that is currently in use, it shall be
ignored and a STATUS message with a Cause information element indicating cause value #101 "message
not compatible with call state" and a Call state information element indicating the appropriate call state
shall be returned using the call reference of the received REGISTER message.
If a Facility information element is received with an invalid protocol profile, the REGISTER message shall
be discarded. The responder shall respond by sending a RELEASE COMPLETE message containing
cause #100 "invalid information element contents" using the call reference of the received REGISTER
message.
Other protocol errors shall be handled according to ETS 300 102-1 [13] subclause 5.8 incorporating the
following amendments:
- change in subclause 5.8.3.2 item a) and d) "SETUP" to "SETUP, REGISTER";
- change in subclause 5.8.6.1 "SETUP" to "SETUP, REGISTER";
- change in subclause 5.8.6.2 "SETUP" to "SETUP, REGISTER".
8.3.2.1.2 Data transfer phase
After establishment, the signalling connection can be used to exchange data between the initiator and the
responder involved in the connection. The initiator and the responder are completely free to send data, i.e.
there exists no predetermined sending scheme.
To transfer data to the peer entity, the entity shall send a FACILITY message to the peer entity using the
DL-DATA-REQUEST service primitive. Sending a FACILITY message shall not affect the call state. The
call reference identifying this connection shall be included in this FACILITY message. The data, i.e. the
component structures, shall be included in the Facility information element.
Only the FACILITY message, RELEASE message, RELEASE COMPLETE message, STATUS message,
and the STATUS ENQUIRY message shall be sent using the call reference that was assigned by a
REGISTER message. If any other message is received, the entity shall ignore it and shall return a
STATUS message with cause value #100, "message not compatible with call state", and a Call state
information element indicating call state U31, N31 Bearer Independent Transport".
Page 28
ETS 300 196-1: August 1993
If a Facility information element is received with an invalid protocol profile, the FACILITY message shall be
discarded. The receiver shall respond by sending a STATUS message with cause value #100 "invalid
information element contents" using the call reference of the received FACILITY message.
The procedures for sending and receiving a STATUS ENQUIRY message are as defined in
subclause 5.8.10 of ETS 300 102-1 [13]. The procedures on receipt of a STATUS message are defined in
subclause 5.8.11 of ETS 300 102-1 [13].
If either protocol entity receives an indication that the data link has been released via the DL-RELEASE-
INDICATION primitive, it shall release the call reference, enter the Null call state (U0, N0) and regard the
signalling connection as released.
If either protocol entity receives an indication that the data link has spontaneously been reset via the DL-
ESTABLISH-INDICATION primitive, it shall send a RELEASE COMPLETE message with the appropriate
call reference, and with the Cause information element indicating cause value #41 "temporary failure",
release the call reference, enter the Null call state (U0, N0) and regard the signalling connection as
released.
Other protocol errors shall be handled according to ETS 300 102-1 [13] subclause 5.8.
8.3.2.1.3 Connection release
The release procedure shall be considered as symmetrical, i.e. both the initiator and the responder can
initiate connection release.
To release the signalling connection, a protocol entity shall send a RELEASE message using the DL-
DATA-REQUEST primitive, start timer T308, as defined in subclause 9.6 of ETS 300 102-1 [13] and enter
the Release Request state (N19, U19). The Cause information element shall indicate an appropriate
cause.
The call reference identifying this signalling connection shall be included in the RELEASE message.
On receipt of a RELEASE message, as indicated by the DL-DATA-INDICATION primitive, the protocol
entity shall send a RELEASE COMPLETE message using the DL-DATA-REQUEST primitive, release the
used call reference and enter the Null call state (U0 or N0).
On receipt of the RELEASE COMPLETE message, as indicated by the DL-DATA-INDICATION primitive,
the protocol entity shall stop timer T308, release the used call reference and enter the Null call state (U0 or
N0).
A protocol entity may send data (i.e. the component structures) to the other protocol entity by including a
Facility information element in the RELEASE or RELEASE COMPLETE message.
NOTE: If the RELEASE or RELEASE COMPLETE message contains a Facility information
element, then a clear distinction between connection release and the data transfer
phase cannot be made.
The Cause information element shall only be used to report ETS 300 102-1 [13] errors outside the
component portion of the Facility information element (octets 1-3). When no ETS 300 102-1 [13] protocol
error is found, the Cause information element shall convey cause #31 "normal, unspecified". For protocol
errors in the component portion of the Facility information element (octets 4, etc.) see subclause 8.4.1.
Page 29
ETS 300 196-1: August 1993
If timer T308 expires the first time, the protocol entity shall retransmit the RELEASE message including the
cause value and restart timer T308.
If timer T308 exipires the second time, the protocol entity shall release the call reference and enter the Null
call state (N0, U0).
NOTE: If timer T308 expires the second time, and after consideration of other usage of the
interface, the restart procedure as defined in subclause 5.5 of ETS 300 102-1 [13]
could be used.
8.3.2.2 Point-to-point transport mechanism (connectionless)
If a point-to-point data link is known to exist or can be established, a connectionless transport mechanism
can be used using a reliable data link connection.
The connectionless transport mechanism is based on FACILITY messages like the connection-oriented
transport mechanism. However, the connectionless transport mechanism shall only use the dummy call
reference value as specified in ETS 300 102-1 [13] subclause 4.3.
Before data can be sent the user shall first establish, if not already available, a reliable data link connection
between the user and the network using the DL-ESTABLISH-REQUEST service primitive as described in
ETS 300 125 [15]. Completion of establishment of this connection is indicated by a DL-ESTABLISH-
CONFIRM primitive.
The FACILITY message is used to carry the "user" information, i.e. the component structures in the Facility
information element.
The contents of the FACILITY message can be extended by the Called party number and Called party
subaddress information elements.
When the multiple subscriber number supplementary service is provided to the user, and the network is to
address the user with a multiple subscriber number, then the network shall send the multiple subscriber
number to the user in a Called party number information element in the FACILITY message. The Called
party number information element shall be coded according to subclause 9.2.1 of ETS 300 052-1 [11].
When the subaddressing supplementary service is provided to the user, and the network is to address the
user with a subaddress provided by the same or another user, then the network shall send the subaddress
to the user in a Called party subaddress information element in the FACILITY message. The Called party
subaddress information element shall be coded according to ETS 300 061-1 [12].
If the Called party number or Called party subaddress information elements are included in the FACILITY
message, the receiving user shall check the identity according to ETS 300 102-1 [13] Annex B, Clause B.3
with the exception that "SETUP" must be replaced with "FACILITY".The FACILITY message shall be sent
using the DL-DATA-REQUEST service primitive as described in ETS 300 125 [15].
If a Facility information element is received with an invalid protocol profile, the receiving entity shall discard
the FACILITY message.
If a FACILITY message is received and it does not contain the Facility information element, the receiving
entity shall discard the FACILITY message.
Page 30
ETS 300 196-1: August 1993
When a message other than FACILITY is received using the dummy call reference, and which does not
apply to some other application of the dummy call reference, the receiving entity shall discard the
message.
INDICATION primitive, or that the data link has spontaneously been reset via the DL-ESTABLISH-
INDICATION primitive, then the procedures as they affect the higher layer protocol are outside the scope
of this ETS.
NOTE: The handling of layer 2 errors is supplementary service dependent and shall therefore
be specified in the individual supplementary services referencing this subclause.
8.3.2.3 Broadcast transport mechanism (connection-oriented)
Currently not specified in this ETS or elsewhere.
8.3.2.4 Broadcast transport mechanism (connectionless)
The connectionless transport mechanism is based on FACILITY messages which are sent from the
network to the user. However, the connectionless transport mechanism shall only use the dummy call
reference value as specified in ETS 300 102-1 [13], subclause 4.3.
The contents of the FACILITY message may be extended by the Called party number and Called party
subaddress information elements.
When the multiple subscriber number supplementary service is provided to the user, and the network is to
address the user with a multiple subscriber number, then the network shall send the multiple subscriber
number to the user in a Called party number information element in the FACILITY message. The Called
party number information element shall be coded according to subclause 9.2.1 of ETS 300 052-1 [11].
When the subaddressing supplementary service is provided to the user, and the network is to address the
user with a subaddress provided by the same or another user, then the network shall send the subaddress
to the user in a Called party subaddress information element in the FACILITY message. The Called party
subaddress information element shall be coded according to ETS 300 061-1 [12].
If a Called party number, or Called party subaddress information element is included in the FACILITY
message, the receiving user shall check the identity according to ETS 300 102-1 [13] Annex B, Clause B.3
with the exception that "SETUP" must be replaced by "FACILITY".
The FACILITY message is used to carry the "user" information, i.e. the component structures in the Facility
The network shall send this FACILITY message, using the DL-UNIT DATA-REQUEST service primitive for
the broadcast datalink as described in ETS 300 125 [15].
If a Facility information element is received with an invalid protocol profile, the receiving entity shall discard
the FACILITY message.
If a FACILITY message is received and it does not contain the Facility information element, the receiving
entity shall discard the FACILITY message.
When a message other than FACILITY is received using the dummy call reference, and which does not
message.
Page 31
ETS 300 196-1: August 1993
INDICATION primitive, or that the data link has spontaneously been reset via the DL-ESTABLISH-
INDICATION primitive, then the procedures as they affect the higher layer protocol are outside the scope
subclause of this ETS.
NOTE: The handling of layer 2 errors is supplementary service dependent and shall therefore
be specified in the individual supplementary services referencing this subclause.
8.4 Error procedures
8.4.1 Component error handling
If a network or user receives a Facility information element containing errors in a component, then the
receiving entity shall reject the component by invoking the reject procedure defined in sublause 8.2.2.4.
The problem code shall be one of those defined in table 2 of this ETS. On invoking the reject procedure the
entity shall proceed as if the component had not been received, e.g. if the component was transported in a
SETUP message, then basic call handling according to ETS 300 102-1 [13] shall continue, or if the invoke
component was transported in a REGISTER message, then the receiving entity shall still establish the call
reference and enter the Bearer Independent Transport call state (N31, U31).
The receipt of a reject component shall be dealt with according to the procedures defined in the individual
supplementary service ETSs.
NOTE: If the receiving entity does not implement Clause 8 of this ETS, then the receipt of a
Facility information element containing a component shall be handled according to the
procedures of ETS 300 102-1 [13] subclause 5.8.7.
8.4.2 Error handling of mistyped data values
If an unknown value (data element) is received in an argument, result or parameter, and if all values which
are neither optional nor have default values assigned are correctly received, the receiving entity shall not
reject these components with problem code of "mistyped argument", "mistyped result" or "mistyped
parameter". The receiving entity shall ignore these unknown values.
8.5 Response to multiple supplementary service invocations
The possible correlation of responses to multiple supplementary service invocations is subject of future
ETSs and currently not applicable.
9 Generic notification procedures
9.1 General
This Clause specifies the functional signalling procedures that support the delivery of notifications at the
user-network interface.
Notifications can be characterised by the following properties:
- they do not cause any change of state on either side of the user-network interface;
- they represent a one-way flow of information that shall not generate a response; and,
- they provide additional information that can be discarded without the need for significant error
recovery if they are unrecognised by a user.
As a consequence of these properties it is possible to provide a generic set of procedures optimised to
support the delivery of notifications at the user-network interface.
Page 32
ETS 300 196-1: August 1993
9.2 Categories of notification procedures
The generic procedures for the delivery of notification can be categorised by the type of information
contained in the notification.
Procedures are defined for three types of notification information, as follows:
a) the delivery of simple notification "indicators" based on the Notification indicator information element,
with codepoints as defined in ETSs for individual supplementary services;
b) within the range of the allowed maximum message length the delivery of notification "parameters"
that are specified as information elements using the encoding scheme defined in subclause 4.5.1 of
ETS 300 102-1 [13] including information elements defined in ETS 300 102-1 [13], in this ETS and in
ETSs for individual supplementary services;
c) the delivery of notification "indicators" and "parameters" using an extension codepoint in octet 3 of
the Notification indicator information element and Basic Encoding Rules (BER) encoded information
in subsequent octets.
When no "parameters" are present, option a) shall be used. When "parameters" are present, individual
supplementary services shall specify which options are applicable.
An application requiring notification shall encode the required information in the Notification indicator
information element or some other specified information element. The notification shall be sent using the
appropriate transport mechanism, as specified by the application, and as defined in subclause 9.3 or
subclause 9.4.
9.3 Transport of bearer-related notifications
These procedures are provided as part of the basic call and do not require subscription to any individual
supplementary service.
This subclause enhances in a compatible manner the basic call control procedures specified in
subclause 5.9 of ETS 300 102-1 [13].
9.3.1 Normal operation
The delivery of bearer-related notifications shall use an active call reference of the call the notification is
associated with and its underlying data link connection. In this context a call reference shall be active from
the initiation of call establishment (including the SETUP message) to the completion of call clearing
(including the RELEASE COMPLETE message).
If the delivery of the notification coincides with call establishment or clearing procedures, the notification
information can be carried in the associated call control messages. If the delivery of the notification
indication coincides with the sending of a FACILITY message, the notification information can be carried in
that message. In all other cases, the notification information shall be delivered in a NOTIFY message. In
addition a NOTIFY message may be sent or received by the user or by the network only after the first
response to a SETUP message has been sent or received and before clearing of the call reference is
initiated.
If a notification is received by the network, the network shall: optionally ensure that the contents of the
notification are a valid coding; and forward the notification to the other user involved in the call.
No call state change shall occur at either side of the interface following the sending or receipt of a NOTIFY
message.
Page 33
ETS 300 196-1: August 1993
9.3.2 Exceptional procedures
If a user does not recognise an information element in a NOTIFY message or a new codepoint or
extension contents of the Notification indicator information element, it shall handle it according to the
procedures in subclause 5.8 of ETS 300 102-1 [13].
NOTE: The preferred option is to discard the unrecognised information in this instance.
If a notification is received by the network and the contents of the notification are determined to be an
invalid or unrecognised coding, the notification shall be discarded and not forwarded to the other user
involved in the call.
9.4 Transport of bearer-independent notifications
The procedures specified enable the network to notify a user of supplementary service related events
when no appropriate call reference is active.
The application of these procedures in the direction user to network is not specified in this ETS.
The delivery of bearer-independent notifications requires the underlying services of the data link layer.
Bearer-independent notifications are delivered using the NOTIFY message defined in subclause 11.1.3.2
with the dummy call reference. The dummy call reference is specified in subclause 4.3 of
ETS 300 102-1 [13].
If it is known that a point-to-point configuration exists at the access, then the NOTIFY message shall be
sent using the DL-DATA-REQUEST primitive as described in ETS 300 125 [15], otherwise the NOTIFY
message shall be sent using the DL-UNIT DATA-REQUEST primitive as described in ETS 300 125 [15].
If a user does not recognise information in the NOTIFY message then that information shall be discarded.
When a message other than NOTIFY is received using the dummy call reference, and which does not
message.
10 Other generic procedures
10.1 Network-side channel reservation function
The network-side channel reservation function allows the user to improve the success of a subsequent
channel selection by making a channel unavailable for use by another user on the same access.
The user shall be identified by the CEI. Reservations may only be used by a call associated with the same
CEI (and thus the same user).
The network-side channel reservation function is limited to calls requiring single 64 kbit/s channels. Calls
requiring broadband channels (greater than 64 kbit/s channels) are outside the scope of this ETS;
however, where a reservation action is provided for a 64 kbit/s call, active broadband calls with the same
CEI shall be treated as active calls.
Calls requiring packet-mode connections shall be treated as active calls for a given CEI.
Two methods of reservation are defined: implicit and explicit reservation. Both methods may coexist on the
same user access configuration.
Page 34
ETS 300 196-1: August 1993
10.1.1 Implicit reservation
Implicit reservation allows user control of the network-side channel reservation function by means of
invocation of other functions from the user, e.g. by use of the Hold and Retrieve functions.
10.1.1.1 Implicit reservation creation
On creation of a reservation the network shall reserve a channel against a specified CEI. This reservation
renders a channel busy, such that another call may be rejected or enter a call waiting condition, even
though not all channels are allocated to active calls.
A call allocated to a CEI with a channel selected is a call:
a) in one of the following call states: Overlap Sending (N2), Outgoing Call Proceeding (N3); Call
Delivered (N4) with an Idle or Hold Request auxiliary state; Active (N10) with an Idle or Hold
Request auxiliary state; and,
b) where a point-to-point configuration is known to exist: the Call Received (N7), Connect Request
(N8), Incoming Call Proceeding (N9) and Overlap Receiving call states (N25); and,
c) in one of the following call states where that call state was reached via one of the call states listed
in (a) or where appropriate (b): Disconnect Request (N11); Disconnect Indication (N12); Release
Request (N19).
The following actions on an active call shall create a reservation, if no reservation already exists:
a) if no other existing call for that CEI has a channel selected, then the receipt or sending of a HOLD
ACKNOWLEDGE message shall create a reservation against the CEI for which that message was
received or sent;
b) if an existing call (1) has a channel selected, and if no reservation already exists, and if an existing
call (2) is in the Call Held or Retrieve Request or Retrieve Indication auxiliary state, and if no other
existing call for that CEI has a channel selected, then the receipt or sending of a RELEASE
COMPLETE message for the call (1) shall create a reservation against the CEI for which that
message was received or sent;
c) if an existing call (1) has a channel selected, and if no reservation already exists, and if an existing
call (2) is in the Call Held or Retrieve Request or Retrieve Indication auxiliary state, and if no other
existing call for that CEI has a channel selected, then the sending of a SUSPEND ACKNOWLEDGE
message for the call (1) shall create a reservation against the CEI for which that message was sent;
NOTE 1: On call suspension, the channel is allocated to a call identity, and not to a particular
user, as identified by its CEI.
d) if an existing call is in the Call Held or Retrieve Request or Retrieve Indication auxiliary state; and if
no other existing call for the CEI has a channel selected (apart from the call with the channel being
restarted); then the receipt or sending of a RESTART ACKNOWLEDGE message, when the Restart
indicator information element contained in the original RESTART message specified "indicated
channels" where that channel is allocated to an existing call, shall create a reservation against the
CEI for which that message was received or sent.
NOTE 2: The network or the user may have already begun clearing the call by means of a
DISCONNECT, RELEASE and RELEASE COMPLETE sequence of messages, in
which case item b) applies.
Page 35
ETS 300 196-1: August 1993
10.1.1.2 Implicit reservation use
On use of a reservation the network shall perform the associated channel selection procedures applicable
to the events concerned and delete the reservation against that CEI.
The following actions shall use a reservation, if such a reservation exists against the CEI for which the
action was performed:
- the sending of a SETUP ACKNOWLEDGE, CALL PROCEEDING, ALERTING or CONNECT
message to the user in response to a received SETUP message;
- the sending of a CONNECT ACKNOWLEDGE message to the user in response to a received
CONNECT message;
- the sending of a RETRIEVE ACKNOWLEDGE message in response to a received RETRIEVE
message;
- the reception of a RETRIEVE ACKNOWLEDGE message in response to the sending of a
RETRIEVE message;
- where a point-to-point configuration is known to exist, the receipt of a SETUP ACKNOWLEDGE,
CALL PROCEEDING, ALERTING or CONNECT message from the user in response to a sent
SETUP message.
10.1.1.3 Implicit reservation cancellation
On reservation cancellation the network shall delete the reservation against that CEI.
The following actions shall cancel a reservation if such a reservation exists against the CEI for which the
action was performed:
- if only one call related to a specified CEI is in the Call Held or Retrieve Request or Retrieve
Indication auxiliary state, the sending or receipt of a RELEASE COMPLETE message for the call
which is in the Call Held or Retrieve Request or Retrieve Indication auxiliary state;
- the sending of a RESUME ACKNOWLEDGE message;
NOTE: A reservation is not used for call resumption, as a channel is permanently allocated to
the suspended call.
- the sending or receipt of a RESTART ACKNOWLEDGE message when the Restart indicator
information element contained in the original RESTART message specified "single interface" or "all
interfaces";
- the receipt of a DL-RELEASE-INDICATION primitive.
10.1.2 Explicit reservation
Explicit channel reservation provides user control of the network-side channel reservation function by
explicit operations which may use a reservation indicator generated, issued and managed by the network.
This allows the user to reserve B-channel resources for use by several held calls.
NOTE: This subclause provides operations for the creation, management and cancellation of
reservations which the user may use in parallel with the procedures specified in
subclause 10.1.1.
The formal definition of the explicit network side channel reservation function shall be as shown in
table D.7.
Page 36
ETS 300 196-1: August 1993
10.1.2.1 Explicit reservation control
To control channel reservation explicitly the user shall include an ExplicitReservationCreationControl invoke
component carried by a Facility information element in an appropriate bearer-related transport message.
The invoke component may contain an argument specifying one of three options:
- no reservation required (NOTE 1);
- reservation required without reservation indicator;
- reservation required with reservation indicator (NOTE 2).
NOTE 1: This option can be used to overrule an implicit reservation.
NOTE 2: The purpose of the reservation indicator is to identify a specific reservation related to a
given CEI.
If no parameter is included in the invoke component then "reservation required without reservation
indicator" is assumed by the network.
On receipt of an ExplicitReservationCreationControl invoke component requesting reservation required,
with or without reservation indicator, and the network is able to provide the requested function, the network
shall include an ExplicitReservationCreationControl return result component carried by a Facility information
element in an appropriate transport message related to the same call. If appropriate (by a subscription
parameter, or, as requested in the invoke component), the network shall include a reservation indicator
parameter; if this parameter is provided, the network shall store this parameter against the reservation,
and shall only grant use of the reservation when this reservation indicator value is included in the
ExplicitReservationManagement invoke component as defined by subclause 10.1.2.2. If the
ExplicitReservationCreationControl invoke component was included in a message that released a channel
resource or is about to release a channel resource on acknowledgement (i.e. a RELEASE, a RELEASE
COMPLETE, a HOLD or a HOLD ACKNOWLEDGE message), that channel resource shall not be
allocated to another call if it is required to meet the reservation requirements.
On receipt of an ExplicitReservationCreation control invoke component requesting no reservation required,
and the network is able to provide the requested function, the network shall include an
ExplicitReservationCreationControl return result component carried by a Facility information element in an
appropriate transport message related to the same call. Furthermore the network shall not provide an
implicit reservation.
If the network is unable to provide the requested function, the network shall include an
ExplicitReservationCreationControl return error component carried by a Facility information element in an
appropriate transport message related to the same call. Appropriate errors are:
- maximum number of reservations reached. The maximum number of reservations (default = one)
already exists for this CEI;
- function "notAvailable";
- function "notSubscribed";
- unwanted reservation created.
On receipt of the ExplicitReservationCreationControl return result component, the user shall retain
knowledge of the reservation indicator, if provided.
Page 37
ETS 300 196-1: August 1993
10.1.2.2 Explicit reservation management
To manage the use of channel reservation the user shall include an ExplicitReservationManagement invoke
component carried by a Facility information element in an appropriate bearer-related transport message
performing channel selection (i.e. SETUP, SETUP ACKNOWLEDGE, CALL PROCEEDING, ALERTING,
CONNECT, CONNECT ACKNOWLEDGE, RETRIEVE or RETRIEVE ACKNOWLEDGE). If required by the
network (on all reservations as indicated by a subscription parameter, or, as requested in the
ExplicitReservationCreationControl invoke component which generated the reservation), the user shall
include a reservation indicator parameter since the network shall only grant use of the reservation when the
required reservation indicator value is included in the ExplicitReservationManagement invoke component.
If no ExplicitReservationManagement invoke component is included in a call control message selecting a
channel then any existing implicit reservations shall be used by the network. If no implicit reservations exist,
then any existing explicit reservations shall remain available.
If the user requires that an existing implicit reservation is not to be used by the call control message
selecting a channel, then the user shall include an ExplicitReservationManagement invoke component in the
call control message. If an explicit reservation with a reservation indicator has been created, then the
invoke component shall include the reservation indicator.
If the network is able to provide the requested management function, the network shall include an
ExplicitReservationManagement return result component carried by a Facility information element in an
appropriate transport message related to the same call.
If the network is unable to provide the requested function, the network shall include an
ExplicitReservationManagement return error component carried by a Facility information element in an
appropriate transport message related to the same call. Appropriate errors are:
- no explicit reservation exists, or invalid reservation indicator;
- function "notSubscribed";
- implicit reservation used.
NOTE: Failure of the explicit reservation management operation will not necessarily result in
channel selection failure, solely in failure to manage the reservation.
On receipt of the ExplicitReservationManagement return result component, the user shall remove
knowledge of the reservation indicator, if used.
10.1.2.3 Explicit reservation cancellation
To cancel an explicit channel reservation the user shall include an ExplicitReservationCancel invoke
component carried by a Facility information element in an appropriate call related transport message.
If the network is able to cancel the reservation, the network shall include an ExplicitReservationCancel
return result component carried by a Facility information element in an appropriate transport message
related to the same call. If required by the network (by a subscription parameter, or, as requested in the
invoke component) the user shall include a reservation indicator parameter and the reservation shall only
be cancelled if this reservation indicator value is included in the ExplicitReservationCancel invoke
component.
Reservation cancellation shall only cancel a single reservation; if multiple reservations exist, multiple
reservation cancellations must be invoked.
Page 38
ETS 300 196-1: August 1993
If the network is unable to cancel the reservation, the network shall include an ExplicitReservationCancel
return error component carried by a Facility information element in an appropriate transport message
related to the same call. Appropriate errors are:
- no explicit reservation exists or invalid reservation indicator;
- function "notSubscribed".
On receipt of the ExplicitReservationCancel return result component the user shall remove knowledge of
the reservation indicator, if used.
The network shall cancel all reservations on:
- the sending or receipt of a RELEASE COMPLETE message for the last call on that CEI;
- the sending or receipt of a RESTART ACKNOWLEDGE message when the Restart indicator
information element contained in the original RESTART message specified "single interface" or "all
interfaces";
- the receipt of a DL-RELEASE-INDICATION primitive.
There is no signalling protocol specific to the Reservation function associated with this action. The user
shall likewise remove all knowledge of any reservation indicators.
10.1.2.4 Effect of reservation on channel selection for a new call
For an incoming call using the channel selection procedures as defined in subclause 5.2.3 of
ETS 300 102-1 [13], the "no B-channel available" condition shall be determined if the number of channels
available for use by a user, minus the number of reserved channels, is zero. An implicitly reserved channel
shall not be used by this call unless the call is subsequently allocated to the CEI for which the reservation
exists. An explicitly reserved channel shall not be used by this call unless an explicit request to use that
channel is received according to the procedures of subclause 10.1.2.2.
10.1.2.5 Interaction between implicit and explicit network-side channel reservation functions
on the same CEI
When an implicit reservation exists at the same time as an explicit reservation, then all call control
messages not containing an explicit reservation invoke component, that affect channel selection, shall
follow the procedures for implicit reservation in subclause 10.1.1.
10.2 Generic procedures for supplementary service management
10.2.1 Introduction
Subclause 10.2 provides for common generic procedures for supplementary service management functions
to support particular supplementary service procedures (e.g. diversion supplementary services) at the
user-network interface. The procedures described provide the management activities that manage
supplementary service specific resource configurations, routing information or other types of
supplementary service specific data resident at the service providers database. The type of supplementary
service management data may differ depending on supplementary service specific requirements and is the
subject of the individual standards of these services.
Certain supplementary services can be activated for an individual attribute value, such that management is
required for each attribute value, e.g. an individual basic service or a multiple subscriber number. This is
known in the subsequent procedures as management of an instance of the supplementary service. These
procedures assume that an operation manages only a single instance of the supplementary service. The
management of multiple instances of a supplementary service within a single invoke component is outside
the scope of this ETS and can be covered in the ETSs of the individual supplementary services.
Page 39
ETS 300 196-1: August 1993
The procedures described in subclause 10.2 assume the supplementary service management procedures
to be independent of the existence of a bearer.
The required supplementary service management operations are supported by the transport mechanisms
as specified in subclause 8.3. The supplementary service management information exchange between
served user and service provider may be divided into the following three groups:
- activation of supplementary services. The activation function effects the initiation of certain
supplementary services and is employed by the user of the supplementary service. The function may
carry supplementary service specific data (e.g. address-information, compatibility information, etc.)
which is identified in the standards of the individual supplementary services concerned;
- deactivation of supplementary services. The supplementary service may be deactivated by the user
according to the user's requirements;
- interrogation. The interrogation procedure supplies the user with supplementary service specific data
stored by the service provider (e.g. which supplementary services are activated, which parameters
are specified, etc.). Interrogation is a read-only function and does not change stored data but may
require authorization codes. Specific requirements are to be identified within the standards of
individual supplementary services using interrogation.
The following subclauses contain the generic procedures for the following operations:
- activation;
- deactivation;
- interrogation;
- status notification.
These operations are specified as a data exchange between certain state machines. The transport
protocol messages to be used for transmission of these operations must be specified in the individual
supplementary service standards where applicable.
The states referred to in the following subclauses, and defined in subclause 10.2.6 refer only to the state
of a specific supplementary service management request. The state of the service as seen by the user or
network is covered by the individual supplementary services referencing these procedures, e.g. the Idle
state indicates that no request is in progress, but the service may be activated, or deactivated.
The occurence of multiple instances of a supplementary service invoke component is to be specified in the
ETSs of the appropriate individual supplementary services.
10.2.2 Activation
Having subscribed or being registered to a supplementary service, in order to activate an instance of that
service, the served user shall:
- send an activate invoke component to the network, in an appropriate bearer-independent transport
message as specified in subclause 8.3.2.2;
- start timer T-ACTIVATE; and,
- enter the Activate Request state.
Timer T-ACTIVATE is specified in subclause 10.2.7. The invoke component is specified in table D.1; an
appropriate activate invoke component shall be specified in the individual supplementary service
specification.
Page 40
ETS 300 196-1: August 1993
The network, on receiving such an activate invoke component shall enter the Activate Request state.
The service provider may verify that the specific supplementary service parameters are valid before
accepting the activation. This verification is done by a check of the specific supplementary service
arguments. Furthermore, the service provider may verify whether any restrictions stored (e.g. such as call
barring) are applicable. Detailed descriptions of the checks to be performed, if any, shall be given in the
appropriate supplementary service descriptions.
If the instance of the supplementary service is successfully activated the network:
- shall send an activate return result component to the user in an appropriate bearer-independent
transport message as specified in subclause 8.3.2.2;
- may send as appropriate to the supplementary service being activated a status notification (see
subclause 10.2.5);
- shall enter the Idle state.
The user, on receiving such an activate return result component shall stop timer T-ACTIVATE and enter the
Idle state.
The user may change the supplementary service data for an existing instance of a supplementary service
by using the procedures of subclause 10.2.2 without deactivating this instance first, thus causing any
previous activation for that instance of the supplementary service to be overridden.
10.2.2.2 Activation exceptional procedures
If the network is unable to activate an instance of the supplementary service or one of the supplementary
services, as correctly requested with an activation invoke component, the network shall send an activation
return error component to the user in an appropriate bearer-independent transport message as described
in subclause 8.3.2.2 and return to the Idle state.
On receiving such an activation return error component, the user shall stop timer T-ACTIVATE and return
to the Idle state.
On expiration of timer T-ACTIVATE, the user shall enter the Idle state. Any subsequent action is
dependent on the application.
The procedures on receipt of a reject component by the user or the network are covered in the ETSs of
the individual supplementary services.
If an entity receives a DL-RELEASE-INDICATION primitive in the Activate Request state, then the entity
shall abort the activation without informing the other entity, and enter the Idle state.
If an entity receives a DL-ESTABLISH-INDICATION primitive in the Activate Request state, then the entity
shall ignore the indication and remain in the current state.
10.2.3 Deactivation
In order to deactivate an instance of the supplementary service, the served user shall:
- send a deactivate invoke component to the network, in an appropriate bearer-independent transport
message as specified in subclause 8.3.2.2;
- start timer T-DEACTIVATE; and,
- enter the Deactivate Request state.
Page 41
ETS 300 196-1: August 1993
Timer T-DEACTIVATE is specified in subclause 10.2.7. The invoke component is specified in table D.1; an
appropriate deactivate invoke component shall be specified in the individual supplementary service
specifications.
The network, on receiving such a deactivate invoke component shall enter the Deactivate Request state.
If the requested instance of the supplementary service is successfully deactivated the network:
- shall send a deactivate return result component to the user in an appropriate bearer-independent
- may send as appropriate to the supplementary service being deactivated a status notification (see
subclause 10.2.5);
- shall enter the Idle state.
On receiving such a deactivate return result component, the user shall stop timer T-DEACTIVATE and
enter the Idle state.
10.2.3.2 Deactivation exceptional procedures
If the network is unable to deactivate an instance of the supplementary service, as correctly requested
with a deactivate invoke component, the network shall send a deactivate return error component to the
user in an appropriate bearer-independent transport message as described in subclause 8.3.2.2 and return
to the Idle state. The network shall retain the supplementary service specific data as stored before the
deactivation request in this case.
On receiving such a deactivate return error component, the user shall:
- stop timer T-DEACTIVATE; and,
- return to the Idle state.
On expiration of timer T-DEACTIVATE the user shall enter the Idle state. Any subsequent action is
If an entity receives a DL-RELEASE-INDICATION primitive in the Deactivate Request state, then the entity
shall abort the deactivation without informing the other entity, and enter the Idle state.
If an entity receives a DL-ESTABLISH-INDICATION primitive in Deactivate Request state, then the entity
shall ignore the indication and remain in the current state.
10.2.4 Interrogation
The interrogation procedure enables the served user to obtain information about the data stored in the
network.
In order to interrogate an instance of the supplementary service, the served user shall:
- send an interrogate invoke component to the network, in an appropriate bearer-independent
- start timer T-INTERROGATE; and,
- enter the Interrogate Request state.
Page 42
ETS 300 196-1: August 1993
Timer T-INTERROGATE is specified in subclause 10.2.7.
The network, on receiving such an interrogate invoke component shall enter the Interrogate Request state.
After having requested this procedure the network shall return the following information:
- in response to a request to interrogate all instances of a supplementary service the served user
shall be given a list of all active instances of the specified supplementary service including the
specific supplementary service argument values in one component;
- in response to a request to interrogate a specific instance of a supplementary service, the served
user shall be informed whether or not the supplementary service is active or registered, and if so,
what specific supplementary service argument values are in use.
If the requested data has been successfully collected the network shall:
- send an interrogate return result component to the user in an appropriate bearer-independent
transport message as specified in subclause 8.3.2.2; and,
- return to the Idle state.
The user, on receiving such an interrogate return result component shall stop timer T-INTERROGATE and
return to the Idle state.
10.2.4.2 Interrogation exceptional procedures
If the network is unable to provide the information requested, as correctly requested with an interrogate
invoke component, the network shall send an interrogate return error component to the user in an
appropriate bearer-independent transport message as described in subclause 8.3.2.2 and return to the
previous state.
The user, on receiving such an interrogate return error component shall stop timer T-INTERROGATE and
return to the state prior to the interrogation request.
On expiration of timer T-INTERROGATE, the user shall enter the Idle state. Any subsequent action is
If an entity receives a DL-RELEASE-INDICATION primitive in the Interrogate Request state, then the entity
shall abort the interrogation without informing the other entity, and enter the Idle state.
If an entity receives a DL-ESTABLISH-INDICATION primitive in the Interrogate Request state, then the
entity shall ignore the indication and remain in the current state.
10.2.5 Status notification
The status notification procedure enables the served user and all other users at the same access and
identified by the served user's number to receive information about the present status of the access due to
activation or deactivation of an instance of the supplementary service (e.g. activation of the call forwarding
unconditional supplementary service).
Page 43
ETS 300 196-1: August 1993
The status notification information is provided by the network at the instant and with the information content
as specified in the individual operation of the supplementary services concerned.
For transport of status notifications the procedures as specified in subclause 8.3.2.4 are applicable.
NOTE: The status notification is usually carried as a class 5 operation (asynchronous, outcome
not reported).
On receipt of an unrecognised Facility information element or on receipt of mistyped components the
receiving entity shall apply the normal error handling procedures as specified in subclause 8.4.
10.2.6 State definitions
The following states are conceived for the supplementary service management procedures associated with
a specific request at the served user's access and are applicable to both the network and the user. The
states only refer to the state of the request and not the state of a particular supplementary service:
- Idle state. There are no supplementary service management procedures in progress;
- Activate Request state. The user has requested that a supplementary service be activated;
- Deactivate Request state. The user has requested that a supplementary service shall be
deactivated;
- Interrogate Request state. The user has requested that a supplementary service be interrogated.
10.2.7 Parameter values (timers)
Table 3 shows the timers used for the supplementary service management procedures.
NOTE: The procedures for activation, deactivation and interrogation make use of the bearer-
independent connectionless transport mechanism as specified in subclause 8.3.2. Since
no transport association exists when this mechanism is used, the timers specified in this
subclause cannot be associated with a call reference. Therefore, these timers shall be
considered as belonging to the application process in progress.
Table 3
|Timer |Time out |Cause for |Normal stop |At expiry |

||||||
|T-ACTIVATE |(NOTE) |activate |activate |Return to Idle |
| | |invoke sent |return result| |
| | | |received | |
||||||
|T-DEACTIVATE |(NOTE) |deactivate |deactivate |Remain in |
| | |invoke sent |return result|Activated |
| | | |received |state |
||||||
|T-INTERROGATE|(NOTE) |interrogate |interrogate |Remain in the |
| | |invoke sent |return result|state prior to |
| | | |received |the invoke |
!++++!
NOTE: The timeout values are application dependent and shall therefore be specified in the
ETSs of the individual supplementary services.
Page 44
ETS 300 196-1: August 1993
10.3 Generic status request procedure
10.3.1 Introduction
The status request procedure allows the network to check whether compatible and incompatible
terminal(s) are connected to an interface and whether these terminal(s) are free or busy. This procedure
can be used for supplementary services that require the characteristics of the terminals to be known (e.g.
completion of calls to busy subscriber supplementary service and freephone supplementary service).
Subclause 10.3 specifies the generic portion of the procedure only. How a supplementary service makes
use of the information obtained using these procedures has to be specified in the individual ETSs referring
to subclause 10.3.
The status request procedure is based on the StatusRequest operation. The formal definition of this
operation is given in Annex D, Clause D.7, table D.8.
To start the status request procedure the network shall perform the following actions:
a) start timer T-STATUS;
b) request the operation using one of the following procedures:
- if a point-to-multipoint configuration is known to exist the network shall send a StatusRequest
invoke component to the user following the procedures of subclause 8.3.2.4;
- if a single point configuration is known to exist, the network shall send a StatusRequest invoke
component to the user following the procedures of subclause 8.3.2.2.
In both procedures the StatusRequest invoke component shall contain the compatibilityMode and the
relevant basic service(s) as defined by the Bearer capability, and optionally Low layer compatibility
and High layer compatibility information elements for which the status is required. The
compatibilityMode shall be set to indicate the appropriate compatibility mode. Furthermore, if the
network is to address the user with a multiple subscriber number, or subaddress then the FACILITY
message shall contain the Called party number, and/or Called party subaddress information
elements as defined in subclauses 8.3.2.2 and 8.3.2.4.
If the network wants to determine the status for a single basic service, then the invoke component
shall contain a single Bearer capability information element, and optionally, single High layer
compatibility and Low layer compatibility information elements. The compatibilityMode is not
significant and shall be set the "allBasicServices" or "oneOrMoreBasicServices".
If the network wants to determine the status for multiple basic services, then the invoke component
shall contain one or more Bearer capability information elements, and optionally one or more High
layer compatibility information elements, with the condition that at least one of these information
elements shall be present more than once. The invoke component shall not contain a Low layer
compatibility information element. The specification of multiple basic services shall be according to
ETS 300 267-1 [16]. If compatibility to all indicated basic services is required, then the
compatibilityMode shall be set to "allBasicServices". If compatibility to at least one basic service is
required, the compatibilityMode shall be set to "oneOrMoreBasicServices";
c) enter the Waiting Status state.
Page 45
ETS 300 196-1: August 1993
On receipt of a StatusRequest invoke component the user shall provide compatibility checking on the given
Bearer capability, Low layer compatibility and High layer compatibility information elements.
If the StatusRequest invoke component contains a single Bearer capability information element, and
optionally a single High layer compatibility and Low layer compatibility information element, then the user
shall provide compatibility checking as defined in Annex B, subclauses B.3.2 and B.3.3 of
ETS 300 102-1 [13]. If the invoke component contains more than one Bearer capability information element
or High layer compatibility information element, then the user shall provide compatibility checking for each
basic service as indicated by all valid combinations of Bearer capability and High layer compatibility
information element as defined in subclause 5.5.5 of ETS 300 267-1 [16].
The user shall send a StatusRequest return result component containing a StatusResult parameter to the
network according to the procedures of subclause 8.3.2.2. The StatusResult parameter shall indicate:
- "compatibleAndFree", if the compatibilityMode indicated "allBasicServices", and the user is free to
accept a call for all of these basic services;
- "compatibleAndFree", if the compatibilityMode indicated "oneOrMoreBasicServices", and the user is
compatible with at least one of the indicated basic servce, and the user is free to accept a call for at
least one of these basic services;
- "compatibleAndBusy", if the compatibilityMode indicated "allBasicServices", and the user is
compatible with all basic services, and the user is not free to accept calls for all of these basic
services;
- "compatibleAndBusy", if the compatibilityMode indicated "oneOrMoreBasicServices", and the user is
compatible with at least one of the indicated basic services, and the user is not free to accept a call
for any of these basic services;
- "incompatible", if the compatibilityMode indicated "allBasicServices" and the user is not compatible
with all the indicated basic services;
- "incompatible", if the compatibilityMode indicated "oneOrMoreBasicServices" and the user is not
compatible with any of the indicated basic services.
Whilst in the Waiting Status state, the network shall:
a) on receipt of a StatusRequest return result component:
- note the result;
- in a point-to-multipoint configuration remain in the same state. In a point-to-point configuration
stop timer T-STATUS, enter the Idle state, and terminate the status request procedure.
b) on expiry of timer T-STATUS:
- enter the Idle state and terminate the status request procedure.
On termination of the status request procedure, the network will have determined that:
a) in a point-to-point configuration:
- if a "compatibleAndFree" result has been received then the terminal is compatible and free;
- if a "compatibleAndBusy" result has been received then the terminal is compatible and busy;
- if a "incompatible" result has been received then the terminal is incompatible;
- if no result has been received then the terminal does not support the status request procedure
and its compatibility and free/busy status is unknown.
Page 46
ETS 300 196-1: August 1993
b) in a point-to-multipoint configuration:
- if one or more "compatibleAndFree", or "compatibleAndBusy" results have been received,
then compatible terminal(s) are present;
- if one or more "compatibleAndFree" results have been received, then compatible and free
terminal(s) are present;
- if one or more "compatibleAndBusy" results have been received, then compatible and busy
terminal(s) are present;
- if one or more "incompatible" results have been received, then incompatible terminal(s) are
present;
- if no response has been received then there are no terminals present that support the status
request procedure and their compatibility and free/busy status is unknown.
NOTE: Even when StatusRequest return result component(s) have been received there may be
terminal(s) present that do not support the status request procedure and their
compatibility and free/busy status is unknown.
A supplementary service utilising the status request procedure in a point-to-multipoint configuration may
obtain information it requires before the status request procedure is terminated, e.g. it is known on receipt
of the first "compatibleAndFree" result that at least one compatible terminal is present.
Whilst in the Waiting Status state and a reject component is received, with an invoke identifier, the network
shall:
- note the result;
- in a point-to-point configuration stop timer T-STATUS, enter the Idle state and terminate the status
request procedure;
- in a point-to-multipoint configuration remain in the same state.
On termination of the status request procedure the network will have determined that:
a) in a point-to-point configuration:
- the terminal does not support the status request procedure;
b) in a point-to-multipoint configuration:
- terminal(s) that do not support the status request procedure are present;
- if only reject components have been received, then there are no terminals present that
support the status request procedure.
Page 47
ETS 300 196-1: August 1993
10.3.4 Parameter values (timers)
Table 4 shows the timer used for the status request procedure.
Table 4
|Timer |Time out |Cause for |Normal stop|At expiry |

||||||
|T-STATUS |(NOTE 1) |status |Status |Return to Idle |
| | |Request |Request | |
| | |invoke sent|return | |
| | | |result | |
| | | |received | |
| | | |(NOTE 2) | |
!++++!
NOTE 1: The timeout value is application dependent and shall therefore be specified in the ETSs
of the individual supplementary services.
NOTE 2: Only if a point-to-point configuration exists.
11 Coding requirements
11.1 Message functional definitions and content
This section should be read in conjunction with Clause 3 of ETS 300 102-1 [13]. All messages are
additional to those defined in that Clause and the following tables should be interpreted according to the
introduction of ETS 300 102-1 [13].
In the following subclauses each time the term "Facility information element" is used, this shall be
interpreted as "Facility or Extended facility information element". If a key in the Reference column indicates
"196/11.2.1" this shall be interpreted as "196/11.2.1" resp. "196/11.2.4".
In the following sub-clauses the key as described below applies to the "Reference" column.
Key: 102-1/nn: reference to subclause nn in ETS 300 102-1 [13];
196/nn: reference to subclause nn in this ETS.
The segmentation rules as given in Annex K of ETS 300 102-1 [13] shall also apply to the messages
defined in this ETS.
To determine an information element specified in this standard is allowed to be included in the following
messages, see subclause 11.2.
Information elements not defined in subclause 11.2 are only allowed to be included in the following
message when explicitly indicated in the message structure.
Page 48
ETS 300 196-1: August 1993
11.1.1 Additional messages for bearer-related supplementary service control
11.1.1.1 FACILITY
This message may be sent by the network or the user to control a supplementary service. The
supplementary service to be invoked, and its associated parameters, are specified in the Facility
information element. The structure of the FACILITY message is shown in table 5.
Table 5: FACILITY message content
Message type: FACILITY
Significance: local (NOTE 1)
Direction: both
| Information | Reference | Direction | Type | Length|

| element | | | | |
||||||
|Protocol | | | | |
|discriminator | 1021/4.2 | both | M | 1 |
||||||
|Call reference | 1021/4.3 | both | M | 2-3 |
||||||
|Message type | 196/11.2.1 | both | M | 1 |
||||||
|Facility | 196/11.2.2.1| both | M | 8-* |
||||||
|Display | 1021/4.5 | n -> u | O (NOTE 2)| 2-34 |
!++++!
NOTE 1: This message has local significance; however it may carry information of global
significance.
NOTE 2: Included if the network provides information that can be presented to the user.
11.1.1.2 HOLD
This message is sent by the network or the user to request the hold function for an existing call. The
structure of the HOLD message is shown in table 6.
Table 6: HOLD message content
Message type: HOLD
Significance: local
Direction: both

| element | | | | |
||||||
|Protocol | | | | |
||||||
||||||
||||||
|Display | 1021/4.5 | n -> u | O (NOTE) | 2-34 |
!++++!
NOTE: Included if the network provides information that can be presented to the user.
Page 49
ETS 300 196-1: August 1993
11.1.1.3 HOLD ACKNOWLEDGE
This message is sent by the network or the user to indicate that the hold function has been successfully
performed. The structure of the HOLD ACKNOWLEDGE message is shown in table 7.
Table 7: HOLD ACKNOWLEDGE message content
Message type: HOLD ACKNOWLEDGE
Significance: local
Direction: both

| element | | | | |
||||||
|Protocol | | | | |
||||||
||||||
||||||
|Display | 1021/4.5 | n -> u | O (NOTE) | 2-34 |
!++++!
11.1.1.4 HOLD REJECT
This message is sent by the network or the user to indicate the denial of the hold function. The structure of
the HOLD REJECT message is shown in table 8.
Table 8: HOLD REJECT message content
Message type: HOLD REJECT
Significance: local
Direction: both

| element | | | | |
||||||
|Protocol | | | | |
||||||
||||||
||||||
|Cause | 1021/4.5 | both | M | 4-32 |
||||||
|Display | 1021/4.5 | n -> u | O (NOTE) | 2-34 |
!++++!
Page 50
ETS 300 196-1: August 1993
11.1.1.5 RETRIEVE
This message is sent by the network or the user to request the retrieval of a held call. The structure of the
RETRIEVE message is shown in table 9.
Table 9: RETRIEVE message content
Message type: RETRIEVE
Significance: local
Direction: both

| element | | | | |
||||||
|Protocol | | | | |
||||||
||||||
||||||
|Channel | | | | |
|identification | 1021/4.5 | both | O (NOTE 1)| 2-* |
||||||
|Display | 1021/4.5 | n -> u | O (NOTE 2)| 2-34 |
!++++!
NOTE 1: Mandatory in the network to user direction. Optional in the user to network direction
except when the user wants to indicate the channel. If not included, its absence is
interpreted as any channel acceptable.
11.1.1.6 RETRIEVE ACKNOWLEDGE
This message is sent by the network or the user to indicate that the retrieve function has been successfully
performed. The structure of the RETRIEVE ACKNOWLEDGE message is shown in table 10.
Table 10: RETRIEVE ACKNOWLEDGE message content
Message type: RETRIEVE ACKNOWLEDGE
Significance: local
Direction: both

| element | | | | |
||||||
|Protocol | | | | |
||||||
||||||
||||||
|Channel | | | | |
|identification | 1021/4.5 | both | O (NOTE 1)| 2-* |
||||||
|Display | 1021/4.5 | n -> u | O (NOTE 2)| 2-34 |
!++++!
NOTE 1: Mandatory in all cases except when the sender accepts the specific B-channel
indicated in the RETRIEVE message. If included, a channel is indicated and specified
as exclusive.
Page 51
ETS 300 196-1: August 1993
11.1.1.7 RETRIEVE REJECT
This message is sent by the network or the user to indicate the inability to perform the requested retrieve
function. The structure of the RETRIEVE REJECT message is shown in table 11.
Table 11: RETRIEVE REJECT message content
Message type: RETRIEVE REJECT
Significance: local
Direction: both

| element | | | | |
||||||
|Protocol | | | | |
||||||
||||||
||||||
|Cause | 1021/4.5 | both | M | 4-32 |
||||||
|Display | 1021/4.5 | n -> u | O (NOTE) | 2-34 |
!++++!
11.1.2 Messages for bearer-independent supplementary service control
11.1.2.1 FACILITY
Direction: both

| element | | | | |
||||||
|Protocol | | | | |
||||||
||||||
||||||
|Facility | 196/11.2.2.1| both | M | 8-* |
||||||
|Display | 1021/4.5 | n -> u | O (NOTE 2)| 2-34 |
!++++!
significance.
Page 52
ETS 300 196-1: August 1993
11.1.2.2 REGISTER
This message is sent by the network or the user to establish a new signalling connection for bearer-
independent transactions. The structure of the REGISTER message is shown in table 13.
Table 13: REGISTER message content
Message type: REGISTER
Direction: both

| element | | | | |
||||||
|Protocol | | | | |
||||||
||||||
||||||
|Facility | 196/11.2.2.1| both | O (NOTE 3)| 8-* |
||||||
|Display | 1021/4.5 | n -> u | O (NOTE 2)| 2-34 |
!++++!
significance.
NOTE 3: Included if the network or user provides supplementary service specific information.
11.1.2.3 RELEASE
This message is sent by the user or the network to indicate that the entity sending the message intends to
release the signalling connection and the call reference, and that the receiving entity shall release the
signalling connection and prepare to release the call reference after sending RELEASE COMPLETE. The
structure of the RELEASE COMPLETE message is shown in table 14.
Table 14: RELEASE message content
Message type: RELEASE
Direction: both

| element | | | | |
||||||
|Protocol | | | | |
||||||
||||||
|Message type | 1021/4.4 | both | M | 1 |
||||||
|Cause | 1021/4.5 | both | M | 4-32 |
||||||
||||||
|Display | 1021/4.5 | n -> u | O (NOTE 2)| 2-34 |
!++++!
significance.
Page 53
ETS 300 196-1: August 1993
11.1.2.4 RELEASE COMPLETE
This message is sent by the user or the network to indicate that the entity sending the message has
released the signalling connection and the call reference, and that the receiving entity shall release the call
reference. The structure of the RELEASE COMPLETE message is shown in table 15.
Table 15: RELEASE COMPLETE message content
Message type: RELEASE COMPLETE
Direction: both

| element | | | | |
||||||
|Protocol | | | | |
||||||
||||||
||||||
|Cause | 1021/4.5 | both | O (NOTE 4)| 4-32 |
||||||
||||||
|Display | 1021/4.5 | n -> u | O (NOTE 2)| 2-34 |
!++++!
significance.
NOTE 4: Mandatory in the first clearing message, including when the RELEASE COMPLETE
message is sent as a result of an error handling condition.
Page 54
ETS 300 196-1: August 1993
11.1.2.5 STATUS
This message is sent from the user or the network in response to a STATUS ENQUIRY message or at any
point in time to report certain error conditions. The structure of the STATUS message is shown in table 16.
Table 16: STATUS message content
Message type: STATUS
Significance: local
Direction: both

| element | | | | |
||||||
|Protocol | | | | |
||||||
||||||
||||||
|Cause | 1021/4.5 | both | M | 4-32 |
||||||
|Call state | 1021/4.5 | both | M | 3 |
||||||
|Display | 1021/4.5 | n -> u | O (NOTE) | 2-34 |
!++++!
11.1.2.6 STATUS ENQUIRY
This message is sent by the user or the network at any time to solicit a STATUS message from the peer
layer 3 entity. Sending a STATUS message in response to a STATUS ENQUIRY message is mandatory.
The structure of the STATUS ENQUIRY message is defined in table 17.
Table 17: STATUS ENQUIRY message content
Message type: STATUS ENQUIRY
Significance: local
Direction: both

| element | | | | |
||||||
|Protocol | | | | |
||||||
||||||
||||||
|Display | 1021/4.5 | n -> u | O (NOTE) | 2-34 |
!++++!
Page 55
ETS 300 196-1: August 1993
11.1.3 Messages used with the dummy call reference
11.1.3.1 FACILITY
Direction: both

| element | | | | |
||||||
|Protocol | | | | |
||||||
|Call reference | 1021/4.3 | both | M | 1 |
||||||
||||||
|Facility | 196/11.2.2.1| both | M | 8-* |
||||||
|Called party | 1021/4.5 | n -> u | O | 2-23 |
|number | | | | |
||||||
|Called party | 1021/4.5 | n -> u | O | 2-23 |
|subaddress | | | | |
||||||
|Display | 1021/4.5 | n -> u | O (NOTE 2)| 2-34 |
!++++!
significance.
11.1.3.2 NOTIFY
This message is sent by network to indicate information pertaining to a supplementary service. The
structure of the NOTIFY message is shown in table 19.
Table 19: NOTIFY message contents
Message type: NOTIFY
Direction: n -> u

| element | | | | |
||||||
|Protocol | | | | |
|discriminator | 1021/4.2 | n -> u | M | 1 |
||||||
|Call reference | 1021/4.3 | n -> u | M | 1 |
||||||
|Message type | 1021/4.4 | n -> u | M | 1 |
||||||
|Notification | 196/11.2.2.2| n -> u | M | 2-* |
|indicator | | | | |
||||||
|Display | 1021/4.5 | n -> u | O (NOTE 2)| 2-34 |
!++++!
significance.
Page 56
ETS 300 196-1: August 1993
11.2 General message format and information element coding
This subclause should be read in conjunction with Clause 4 of ETS 300 102-1 [13] and contains the coding
of the information elements specifically used by the procedures described in this ETS.
11.2.1 Message type
The additional message type codings for the purpose of this ETS are defined in table 20.
Table 20: Message types
| Bits |
| 8 7 6 5 4 3 2 1 |
| |
| 0 0 1 - - - - - ETS 300 102-1 [13] call information |
| phase message group |
| 0 0 1 0 0 HOLD |
| 0 1 0 0 0 HOLD ACKNOWLEDGE |
| 1 0 0 0 0 HOLD REJECT |
| 1 0 0 0 1 RETRIEVE |
| 1 0 0 1 1 RETRIEVE ACKNOWLEDGE |
| 1 0 1 1 1 RETRIEVE REJECT |
| |
| 0 1 1 - - - - - ETS 300 1021 [13] miscellaneous |
| message group |
| 0 0 0 1 0 FACILITY |
| 0 0 1 0 0 REGISTER |
!!
11.2.2 Other information elements
Table 21 shows the additional information elements defined for supplementary service control and those
information elements of ETS 300 102-1 [13] which are extended for this purpose.
Table 21: Information elements specific to supplementary service control
|Bits |Section |Maximum |

| 8 7 6 5 4 3 2 1 |reference|length |
| | |(octets)|
| 0 - - - - - - - Variable length |||
| elements | | |
| 0 0 1 1 1 0 0 Facility |11.2.2.1 | NOTE 2 |
| 0 1 0 0 1 1 1 Notification indicator |11.2.2.2 | NOTE 2 |
| 0 0 1 0 1 0 0 Call state |11.2.2.3 | NOTE 3 |
| 0 0 0 1 1 0 1 Extended facility |11.2.2.4 | NOTE 3 |
| | | |
| All other values are reserved (NOTE 7)| | |
| | | |
!++!
NOTE 1: The reserved values with bits 5-8 coded "0000" are for future information elements for
which comprehension by the receiver is required (see 5.8.7.1 of
ETS 300 102-1 [13]).
NOTE 2: The maximum length of the Facility and Notification indicator information elements is
application dependent consistent with the maximum length of the message and not
exceeding 255 octets.
NOTE 3: The maximum length of the Extended facility information element is application
dependent consistent with the maximum length of the message.
Page 57
ETS 300 196-1: August 1993
11.2.2.1 Facility
The purpose of the Facility information element is to carry components. For the purposes of this ETS these
components are used to control supplementary services.
The Facility information element can be included in all call control messages and all messages defined in
this ETS except for the NOTIFY, STATUS and STATUS ENQUIRY messages.
Figure 1 shows the structure of the Facility information element. Table 22 shows the value of the protocol
profile field applicable for supplementary services.
8 7 6 5 4 3 2 1 Octets
| | Facility |
| 0 | 0 0 1 1 1 0 0 | 1
| | Information element identifier |
|+|
| Length of facility contents | 2
||
| 1 | 0 0 | |
| Ext. | Spare | Protocol profile | 3
|++|
| Component(s) (NOTE) | 4, etc.
!!
NOTE: One or more components may be included depending on specific service requirements.
Multiple components may be sent in one Facility information element or in more than
one (individual) Facility information elements. It is a sender's choice to use either one or
several Facility information elements taking into account the maximum length of the
Facility information element.
Figure 1: Facility information element
Table 22: Facility information element protocol profile
|Protocol profile |
| |
| Bits |
| 5 4 3 2 1 |
| |
| 1 0 0 0 1 | Remote operations protocol |
| |
| |
| All other values are reserved and their |
| usage is the subject of other ETSs |
!!
The component structures are defined in table D.1 using ASN.1 as specified in CCITT Recommendation
X.208 [6]. For illustrative purposes an example of the coding of component structures is shown in Annex H.
All data structures in the Facility information element (octet 4, etc.) shall be encoded according to the
Basic Encoding Rules (BER) as specified in CCITT Recommendation X.209 [7].
11.2.2.1.1 Treatment of existing ETS 300 102-1 information elements as parameters
Supplementary service protocol specifications are expected to require new parameters to be defined and
to require existing ETS 300 102-1 [13] information elements.
New parameters shall be defined using CCITT Recommendation X.209 [7] coding if they do not appear
elsewhere in ETS 300 102-1 [13] messages.
Supplementary service protocol specifiers may elect to encapsulate one or more existing
ETS 300 102-1 [13] information elements within a CCITT Recommendation X.209 [7] data element,
thereby retaining the ETS 300 102-1 [13] coding for these information elements. When this option is
chosen, all the ETS 300 102-1 [13] information elements should be grouped together as the content
following the ETS 300 102-1 [13] information elements tag. This data element may appear by itself or as a
member of a sequence or set.
Page 58
ETS 300 196-1: August 1993
Encapsulation of the Facility information element within Facility information elements shall not be used.
A formal definition of this mechanism using ASN.1 is given in Annex D, Clause D.4, table D.4.
11.2.2.2 Notification indicator
The following revised definition of the Notification indicator information element complements that given in
ETS 300 102-1 [13].
The purpose of the Notification indicator information element shall be to indicate information pertaining to a
call, for example a supplementary service operating at some other user within that call.
The Notification indicator information element can be included in all call control messages and the
messages defined in subclauses 11.1.1 and 11.1.3 except for the STATUS and STATUS ENQUIRY
message.
The Notification indicator information element shall be coded as shown in figure 2 and table 23. The
maximum length of the information element shall be application dependent consistent with the maximum
length of the message.
The Notification indicator information element can be repeated in a message.
8 7 6 5 4 3 2 1 Octets
| | Notification indicator |
| 0 | 0 1 0 0 1 1 1 | 1
|+|
| Length of notification indicator contents | 2
| |
||
| 0/1 | Notification description | 3
| Ext.| (NOTE 3,4) |
|||
| 1 | Notification description |
| Ext.| (NOTE 3) | 3a*
|+|
| | 4*, etc.
| NotificationDataStructure (NOTE 1) | (NOTE 2)
!!
NOTE 1: One or more NotificationDataStructures (as defined in table D.9) may be included
depending on specific service requirements.
NOTE 2: Octet 4 shall only be included when the notification description in octet 3 indicates the
extension to Basic Encoding Rules (BER) encoded data structure usage.
NOTE 3: Bit eight in octet 3 is used to extend the notification description field. If bit eight is 0,
then another octet follows; if bit eight is 1, then octet 3 is the last octet. The value for a
one octet field range from 1 to 127. For a multi-octet field, the order of bit values
progressively decreases as the octet number increases.
NOTE 4: The codepoints for the Notification description are defined in the ETSs of the individual
supplementary services that use notifications.
Figure 2: Notification indicator information element
Page 59
ETS 300 196-1: August 1993
Table 23 shows the notification description value to be used to indicate the use of extended notifications.
Table 23: Notification indicator information element notification description
| Notification description (octet 3) |

| |
| Bits |
| 7 6 5 4 3 2 1 |
| |
| 0 0 0 0 0 1 1 Discriminator for BER |
| encoded notification extension |
| |
| All other values are reserved or defined |
| in the ETSs of individual supplementary |
| services. |
!!
Table D.9 shows the NOTIFY macro to be used in the ETSs of the individual supplementary services to
define a particular extended notification. Further this table shows the notification data structure which will
carry the notification information.
11.2.2.3 Call state
The Call state information element shall be coded as shown in figure 4.13 of ETS 300 102-1 [13] and
table 4.7 of ETS 300 102-1 [13]. Table 24 contains an additional codepoint required for use within
supplementary service control.
Table 24: Call state information element
| Call State value (Octet 3) |

| |
| Bits |
| 6 5 4 3 2 1 |
| ___________ |
| 0 1 1 1 1 1 Bearer Independent |
| Transport |
| |
!!
11.2.2.4 Extended facility information element
The Extended facility information element serves the same purposes as the Facility information element. It
does however allow the inclusion of components which would be too long to be included in the Facility
information element. The Extended facility information element can be used in any message that can
contain a Facility information as a replacement for Facility information elements, or used together with
Facility information elements.
The Extended facility information shall only be used to convey a component when that component cannot
be included in a Facility information element without other components.
NOTE: Application of the Extended facility information element in implementations where
maximum I-frame length is set to the default value specified in ETS 300 125 [15] (i.e.
260 octets) will usually require the support of the message segmentation procedures
as specified in Annex K of ETS 300 102-1 [13].
Only the coding of the information element identifier and the length of the Extended facility information
element contents are different from the Facility information element. Figure 3 shows the structure of the
Facility information element.
Page 60
ETS 300 196-1: August 1993
8 7 6 5 4 3 2 1 Octets
| | Extended facility |
| 0 | 0 0 0 1 1 0 1 | 1
|+|
| Length of extended facility contents | 2
| | 2.1
| | 2.2*, etc.
||
| 1 | 0 0 | |
| Ext. | Spare | Protocol profile | 3
|++|
| Component(s) (NOTE) | 4, etc.
!!
NOTE: One or more components may be included depending on specific service requirements.
Multiple components may be sent in one Extended facility information element or in
more than one (individual) Extended facility information elements. It is a sender's choice
to use either one or several Extended facility information elements.
Figure 3: Extended facility information element
The length of the Extended facility information element shall be encoded as follows:
1) the length octets shall consist of two or more octets, and shall represent the number of octets of the
information element following the length octets;
2) the length octets shall consist of an initial octet and one or more subsequent octets. The initial octet
shall be coded as follows:
a) bit 8 shall be one;
b) bits 7 to 1 shall encode the number of subsequent octets in the length octets with bit 7 as the
most significant bit;
c) the value 1 1 1 1 1 1 1 1 shall not be used. This value is reserved for future extensions;
3) subsequent octets of the length of information element contents shall be encoded as follows:
Bits 8 to 1 of the first subsequent octet, followed by bits 8 to 1 of the second subsequent
octet, followed in turn by bits 8 to 1 of each further octet, up to and including the last
subsequent octet shall represent an unsigned binary integer equal to the information element
length with bit 8 of the first subsequent octet as the most significant bit.
Page 61
ETS 300 196-1: August 1993
Annex A (normative): Dynamic descriptions
A.1 Dynamic description of the Hold and Retrieve functions
This Clause contains the Specification and Description Language (SDL) description for the Hold and
Retrieve functions for the initiating and receiving side.
The description consists of the following figures specified according to CCITT Recommendation
Z.100 [10]:
Figure A.1: Hold function initiating entity SDL diagrams;
Figure A.2: Retrieve function initiating entity SDL diagrams;
Figure A.3: Hold function responding entity SDL diagrams;
Figure A.4: Retrieve function responding entity SDL diagrams;
Figure A.5: SDL diagram of channel selection macro.
Page 62
ETS 300 196-1: August 1993
Process HoldRetrieve SE0196_FA1.1(9)
Idle
HOLD
request
Test call
state
HOLD
reject
--------
The call shall be in the states
specified in subclause 7.2.1.1
HOLD
reject
--------
Identify
CEI
HOLD
To the
responder
SET
(NOW+4sec,
T-HOLD)
Hold
Request
Call state U/N12 or U/N19 Unsuccessful Successful
Figure A.1 (sheet 1 of 2): Hold function initiating entity SDL diagrams
Page 63
ETS 300 196-1: August 1993
Hold
Request
HOLD
Network
side?
--------
RESET
(T-HOLD)
HOLD
reject
A See figure A3
Hold request
from user is
rejected
From the initiator
(only if a hold
collision occurs)
Call state
change
NOTE: Any basic call condition
that causes a transition to a
basic call state not listed in
subclause 7.2.1.1.
RESET
(T-HOLD)
ABORT
indication
Idle
T-HOLD
HOLD
reject
Idle
HOLD
REJECT
From the
responder
RESET
(T-HOLD)
HOLD
ACKNOWLEDGE
From the
responder
RESET
(T-HOLD)
Release
B-channel
HOLD
confirm
Call
Held
YES
NO
Figure A.1 (sheet 2 of 2): Hold function initiating entity SDL diagrams
Page 64
ETS 300 196-1: August 1993
Call
Held
Call state
change
subclause 7.2.1.1 and other
than the Disconnect Indication
(U12, N12) call state.
ABORT
indication
Idle
RETRIEVE
request
Identify CEI
Channel
selection
RETRIEVE
reject
--------
RETRIEVE
To the
responder
SET
(NOW+4sec,
T-RETRIEVE)
Retrieve
Request
Unsuccessful Successful
Figure A.2 (sheet 1 of 3): Retrieve function intiating entity SDL diagrams
Page 65
ETS 300 196-1: August 1993
Retrieve
Request
T-RETRIEVE
RETRIEVE
reject
Release
B-channel,
if selected
Call
Held
RETRIEVE
REJECT
From the
responder
RESET
(T-RETRIEVE)
RETRIEVE
ACKNOWLEDGE
From the
responder
RESET
(T-RETRIEVE)
Complete
channel
selection
Connect
to B-channel
RETRIEVE
confirm
Idle
Figure A.2 (sheet 2 of 3): Retrieve function initiating entity SDL diagrams
Page 66
ETS 300 196-1: August 1993
Retrieve
Request
Call state
change
RESET
(T-RETRIEVE)
ABORT
indication
Release
B-channel,
if selected
Idle
RETRIEVE
From the
initiator (only
if Retrieve collision
occurs
Network
side?
--------
RESET
(T-RETRIEVE)
Release
B-channel,
if selected
RETRIEVE
reject
B
See
figure A.4
Retrieve request
from user is
rejected
YES
NO
Figure A.2 (sheet 3 of 3): Retrieve function initiating entity SDL diagrams
Page 67
ETS 300 196-1: August 1993
NOTE 1: The call shall be in the states as specified in
subclause 7.2.1.1.
NOTE 2: This signal is sent to the appropriate individual
supplementary service entity using the Hold function
(e.g. the call hold supplementary service).
A
Test basic call
state
--------
NOTE 1
HOLD
REJECT
(cause #101)
To the
initiator
--------
HOLD
service
request
NOTE 2
Hold
Indication
Idle
HOLD
From the
intitiator
Call state U/N12 or U/N19 Unsuccessful Successful
Figure A.3 (sheet 1 of 2): Hold function responding entity SDL diagrams
Page 68
ETS 300 196-1: August 1993
NOTE 1: This signal is received from the appropriate individual supplementary
service entity using the Hold function (e.g. the call hold supplementary service).
NOTE 2: The cause value is supplementary service specific.
NOTE 3: Any basic call condition that causes a transition to a basic call state
not listed subclause 7.2.1.1.
Hold
Indication
HOLD
service
reject
NOTE 2
HOLD
REJECT
To the
initiator
Idle
Call state
change
NOTE 3
ABORT
indication
Idle
HOLD
service
confirm
NOTE 1
Release
B-channel
HOLD
ACKNOWLEDGE
To the
initiator
Call
Held
Figure A.3 (sheet 2 of 2): Hold function responding entity SDL diagrams
Page 69
ETS 300 196-1: August 1993
B
Channel
selection
RETRIEVE
REJECT
(cause #101)
To the
initiator
--------
RETRIEVE
service
request
Retrieve
Indication
Call
Held
RETRIEVE
From the
initiator
Call state
change
ABORT
indication
Idle
Unsuccessful Successful
Figure A.4 (sheet 1 of 2): Retrieve function responding entity SDL diagrams
Page 70
ETS 300 196-1: August 1993
Retrieve
Indication
RETRIEVE
service
reject
Release
selected
B-channel
RETRIEVE
REJECT
To the
initiator
Call
Held
Call state
change
Release
selected
B-channel
ABORT
indication
Idle
RETRIEVE
service
confirm
"Call state
=
Active?"
Connect to
selected
B-channel
RETRIEVE
ACKNOWLEDGE
To the
initiator
Idle
"Connect during
establishment
of clearing?"
YES
NO
NO
YES
Figure A.4 (sheet 2 of 2): Retrieve function responding entity SDL diagrams
Page 71
ETS 300 196-1: August 1993
Macro ChannelSelection SE0196_FA5(1)
NOTE: This channel selection procedure is defined
in ETS 300 102-1 [13], subclauses 5.1.2 and 5.2.3.2.
Channel
selection
Channel
identification
selection
Specific
required channel
available?
Unsuccessful
Retrieval on
specific
B-channel
Successful
Is there a
B-channel
available?
Unsuccessful
Retrieval on
available
B-channel
Preferred
channel
available?
Retrieval on
preferred
B-channel
Exclusive
NO
YES
Any or no channel
NO
YES
Preferred
NO
YES
Figure A.5: SDL diagram of channel selection macro
Page 72
ETS 300 196-1: August 1993
A.2 Dynamic description of the status request procedure
This Clause contains the SDL description for the status request procedure for the user and the network.
Z.100 [10]:
Figure A.6: user SDL diagrams;
Figure A.7: network SDL diagrams.
Page 73
ETS 300 196-1: August 1993
Process USER_STATUS SE0196_FA6(1)
Idle
FACILTY
(StatusRequest
invoke)
Compatible?
FACILITY
(StatusRequest
return result
(incompatible))
--------
Free?
FACILITY
(StatusRequest
return result
(compatibleAndBusy))
--------
FACILITY
(StatusRequest
return result
(compatibleAndFree))
--------
NO YES
NO
YES
Figure A.6: Status request procedure - user SDL diagrams
Page 74
ETS 300 196-1: August 1993
Process NETWORK_STATUS SE0196_FA7.1(2)
Idle
STATUS
request
SET
(NOW+STATUS,
T-STATUS)
FACILITY
(StatusRequest
invoke)
Waiting
Status
Figure A.7 (sheet 1 of 2): Status request procedure - network SDL diagrams
Page 75
ETS 300 196-1: August 1993
Process NETWORK_STATUS SE0196_FA7.2(2)
Waiting
Status
DL-ESTABLISH-
INDICATION
--------
DL-RELEASE-
INDICATION
RESET
(T-STATUS)
ERROR
indication
Idle
T-STATUS
STATUS
confirm
(final)
Idle
FACILITY
(StatusRequest
return result)
Point-to-point?
STATUS
confirm
(intermediate)
--------
RESET
(T-STATUS)
STATUS
confirm
(final)
Idle
NO
YES
Figure A.7 (sheet 2 of 2): Status request procedure - network SDL diagrams
Page 76
ETS 300 196-1: August 1993
A.3 Dynamic description of the supplementary service management function
This Clause contains the SDL description for the supplementary service management procedures for the
user and the network.
Z.100 [10]:
Figure A.8: user SDL diagrams;
Figure A.9: network SDL diagrams.
Page 77
ETS 300 196-1: August 1993
Process USER_SS_MANAGE SE0196_FA8.1(4)
NOTE: The request may be a request for multiple
instances of a supplementary service, or may be
a request for only one instance of a supplementary
service.
Idle
INTERROGATE
request
SET (NOW+
INTERROAGTE,
T_INTERROGATE)
FACILITY
(Interrogate
invoke)
Interrogate
Request
DEACTIVATE
request
SET (NOW+
DEACTIVATE,
T_DEACTIVATE)
FACILITY
(Deactivate
invoke)
Deactivate
Request
ACTIVATE
request
SET (NOW+
ACTIVATE,
T_ACTIVATE)
FACILITY
(Activate
invoke)
Activate
Request
Figure A.8 (sheet 1 of 4): Supplementary service management procedures - user SDL diagrams
Page 78
ETS 300 196-1: August 1993
Activate
Request
DL-ESTABLISH-
INDICATION
--------
DL-RELEASE-
INDICATION
RESET
(T-ACTIVATE)
ERROR
indication
Idle
T-ACTIVATE
ERROR
indication
Idle
FACILITY
reject
RESET
(T-ACTIVATE)
ERROR
indication
Idle
FACILITY
Activate
return error
RESET
(T-ACTIVATE)
ACTIVATE
reject
Idle
FACILITY
Activate
return result
RESET
(T-ACTIVATE)
ACTIVATE
confirm
Idle
Page 79
ETS 300 196-1: August 1993
Deactivate
Request
DL-ESTABLISH-
INDICATION
--------
DL-RELEASE-
INDICATION
RESET
(T-DEACTIVATE)
ERROR
indication
Idle
T-DEACTIVATE
ERROR
indication
Idle
FACILITY
reject
RESET
(T-DEACTIVATE)
ERROR
indication
Idle
FACILITY
Deactivate
return error
RESET
(T-DEACTIVATE)
DEACTIVATE
reject
Idle
FACILITY
Deactivate
return result
RESET
(T-DEACTIVATE)
DEACTIVATE
confirm
Idle
Page 80
ETS 300 196-1: August 1993
Interrogate
Request
DL-ESTABLISH-
INDICATION
--------
DL-RELEASE-
INDICATION
RESET
(T-INTERROGATE)
ERROR
indication
Idle
T-INTERROGATE
ERROR
indication
Idle
FACILITY
reject
RESET
(T-INTERROGATE)
ERROR
indication
Idle
FACILITY
Interrogate
return error
RESET
(T-INTERROGATE)
INTERROGATE
reject
Idle
FACILITY
Interrogate
return result
RESET
(T-INTERROGATE)
INTERROGATE
confirm
Idle
Page 81
ETS 300 196-1: August 1993
Process NETWORK_SS_MANAGE SE0196_FA9.1(4)
Idle
FACILITY
Interrogate
invoke
INTERROGATE
indication
Interrogate
request
FACILITY
Deactivate
invoke
DEACTIVATE
indication
Deactivate
request
FACILITY
Activate
invoke
ACTIVATE
indication
Activate
request
Figure A.9 (sheet 1 of 4): Supplementary service management procedures - network SDL diagrams
Page 82
ETS 300 196-1: August 1993
Activate
Request
DL-ESTABLISH-
INDICATION
--------
DL-RELEASE-
INDICATION
ERROR
indication
Idle
ACTIVATE
reject
FACILITY
(Activate
return error)
Idle
ACTIVATE
response
FACILITY
(Activate
return result)
Idle
FACILITY
(Status
Notification
invoke)
to all
users
No status
notification
Status
notification
Page 83
ETS 300 196-1: August 1993
Deactivate
Request
DL-ESTABLISH-
INDICATION
--------
DL-RELEASE-
INDICATION
ERROR
indication
Idle
DEACTIVATE
reject
FACILITY
(Deactivate
return error)
Idle
DEACTIVATE
response
FACILITY
(Deactivate
return result)
FACILITY
(Status
Notification
invoke)
to all
users
Idle
Status
notification
No status
notification
Page 84
ETS 300 196-1: August 1993
Interrogate
Request
DL-ESTABLISH-
INDICATION
--------
DL-RELEASE-
INDICATION
ERROR
indication
Idle
INTERROGATE
reject
FACILITY
Interrogate
return error
Idle
INTERROGATE
response
FACILITY
Interrogate
return result
Idle
Page 85
ETS 300 196-1: August 1993
Annex B (informative): Guidelines for the application of the generic
procedures for the design of individual supplementary
services
B.1 Introduction
This Annex provides guidelines for the application of either the generic procedures specified in this ETS or
other mechanisms for the design of individual supplementary services.
The main text of this ETS specifies a set of generic procedures that can be used to design individual
supplementary services, i.e.:
- the separate message category;
- the common information element category; and,
- the notification category.
The functions and procedures of the above categories are described in Clause 7, Clause 8 and Clause 9,
respectively. The functions provided by one category do not overlap with the functions of the other
categories. Consequently, one generic function cannot be used to provide the functions of another
category. The generic functions may however be used in combination, concurrently and sequentially, in
order to provide more complex functionality.
In addition, a number of supplementary services use mechanism that are not based on the generic
functions and procedures described above. These supplementary services use normal call control
messages and information elements described in ETS 300 102-1 [13]. The transfer of these messages
and information elements provides functions that correspond to the common information element category,
and to the notification category. The procedures for these mechanisms are outside the scope of this ETS.
New supplementary services requiring new codings shall use the generic functions and procedures
specified in this ETS.
B.2 Separate message category
B.2.1 Application of the separate message categories for new services defined by CCITT
If a new supplementary service requires procedures that change resources, also new messages defined
by CCITT shall be used.
B.2.2 Application of the separate message category for new services defined by ETSI
If a new supplementary services requires procedures that change resources, also new messages defined
B.2.3 Application of the separate message category for supplementary services defined by
other organisations
If a new supplementary service requires procedures that change resources, also new messages defined
B.3 Common information element category
Two procedures are defined for the delivery of information:
a) the delivery of "indicators" and "parameters" using the Facility or Extended facility information
element and ASN.1 encoded information in subsequent octets;
b) the delivery of "indicators" and "parameters" that are specified as information elements using the
encoding scheme defined in subclause 4.5.1 of ETS 300 102-1 [13] including the information
elements defined in ETS 300 102-1 [13].
Page 86
ETS 300 196-1: August 1993
Procedures using option b) are outside the scope of this ETS.
B.3.1 Application of the common information element category for services defined by CCITT
Either option a) or option b) shall be used.
When option b) is used information elements may also be embedded in the component structure of the
Facility or Extended facility information element.
Unless existing information elements defined in ETS 300 102-1 [13] can be used, option a) is the preferred
option.
B.3.2 Application of the common information element category for services defined by ETSI
When option a) is used, operations shall be defined with operation values defined using object identifiers.
option.
B.3.3 Application of the common information element category for supplementary services
defined by other organisations
When option a) is used, operations shall be defined with operation values defined using object identifiers.
option.
B.4 Notification category
There are three types of notification information, which may be used in procedures:
a) the delivery of simple notification "indicators" based on the Notification indicator information element,
using codepoints defined in the ETSs for individual supplementary services;
b) the delivery of notification "parameters" that are specified as information elements using the
encoding scheme defined in subclause 4.5.1 of ETS 300 102-1 [13] including information elements
defined in ETS 300 102-1 [13];
c) the delivery of notification "indicators" and "parameters" using an extension codepoint in octet 3 of
the Notification indicator information element and ASN.1 encoded information in subsequent octets.
Procedures using option b) are outside the scope of this ETS.
Page 87
ETS 300 196-1: August 1993
B.4.1 Application of the notification category for services defined by CCITT
When no parameters have to be delivered, option a) shall be used.
When parameters have to be delivered, the individual supplementary service shall specify which options
have to be applied in a given situation. In this case, the notification indicator shall be carried using either
option a) or option c). When option a) is used, the parameters can only be carried using also option b).
Where option c) is used, the transfer of parameters is possible. In addition, information elements, as
defined for option b), may also be embedded in the component structure of the Notification indicator
B.4.2 Application of the notification category for services defined by ETSI
When appropriate codings defined by CCITT are available, these codings shall be used in accordance with
the application rules of subclause B.4.1.
In all other cases, option c) shall be used.
The notification may be supplemented by extra parameters using CCITT or ETSI defined information
elements as defined in option b). These information elements may be embedded in the component
structure of the Notification indicator information element or provided as separate information elements.
When option c) applies, the notification shall be defined with notification values using object identifiers.
B.4.3 Application of the notification category for supplementary services defined by other
organisations
When appropriate codings defined by CCITT or by ETSI are available, these codings should be used in
accordance with the application rules in subclause B.4.1.
In all other cases, option c) shall be used.
The notification may be supplemented by extra parameters using CCITT, or ETSI, or other organisation
defined information elements, as defined in option b). These information elements may be embedded in the
component structure of the Notification indicator information element or provided as separate information
elements.
When option c) is used, the notification shall be defined with notification values using object identifiers.
Page 88
ETS 300 196-1: August 1993
Annex C (informative): ASN.1 subtypes and proposed mechanism for
enhancements of the future protocol
ASN.1 is defined in CCITT Recommendation X.208 [6], "Section 4 - Subtypes" a mechanism to define
subtypes. A subtype specifies a restriction which must be met by the data values, e.g. only some specific
integer values are used for the encoding of an error value of a specific operation.
The enhanced data types of a future protocol shall be such that the previous protocol is a subtype of the
future protocol. In this case all data values of the previous protocol belong also to the future protocol.
The enhancements are applicable for primitive and constructed types as well as for the data types which
are used within another constructed data type. Therefore a "data value" can be e.g. an argument or the
result of an operation or it may be a parameter within another data value.
The following enhancements may be possible. The order of topics is according to CCITT Recommendation
X.208 [6], 37 "Subtype Value Sets".
- for Single Value:
New data values of a specific data type may be specified; e.g. new values for parameter of integer
or enumeration types.
- for Value Range:
The range (i.e. the lowerbound and/or upperbound) of an integer or real subtype may be extended.
- for Size Constraint:
For string types, sequence-of types and set-of types the number of data elements within the
constructed data type can be restricted. These restricted number of elements may be extended in
future versions of the protocol.
- for Permitted Alphabet:
The characters allowed within a character string can be restricted to a subset.
In future versions of the protocol this restriction may be enhanced up to the "maximum" alphabet of
the data type in the previous protocol. The "maximum" alphabet is specific for each character string
type within ASN.1.
- for Inner Subtyping:
In the subtype of a constructed type the presence or absence of optional parameters can be
specified.
In future versions of the protocol additional optional data elements may be specified within sequence
types or set types. In a sequence type the additional data elements should only be included at the
end of the sequence. This will enable the ASN.1 decoder to detect missing data elements of the
previous protocol.
The data types of the included parameters may be different from the parameters of the previous
protocol according to CCITT Recommendation X.208 [6], 20.3 and 22.3. Therefore new
parameters can be distinguished by type and/or position from these ones of the previous protocol.
Page 89
ETS 300 196-1: August 1993
To avoid unnecessary complexity of the future protocol and to allow error handling for the previous protocol
a data type should never be changed in any protocol version, i.e. in the future protocol the tag of any data
type should be the same as in any previous protocol. This should also apply for data types within
constructed data types.
If it shall be possible in the future to use different data types for one data value, then this must already be
specified in the previous protocol. For examlpe, in the current DSS1 protocol the data value for remote
operations is specified as a choice of a local integer or of an object identifier. This will enable future
protocols to use an integer value instead of an object identifier in the current version.
Page 90
ETS 300 196-1: August 1993
Annex D (normative): Formal definition of data types
This Annex provides the ASN.1 modules defined for the purpose of this ETS.
D.1 Component types
Table D.1 shows the formal definition of the component data types used in the functional protocol.
Table D.1: Component types
Facility-Information-Element-Components {ccitt identified-organization etsi(0) 196
facility-information-element-component(3)}
DEFINITIONS ::=
BEGIN
EXPORTS InvokeIDType, Components;
IMPORTS OPERATION, ERROR
FROM Remote-Operation-Notation
{joint-iso-ccitt remote-operations(4) notation(0)};
Components ::= CHOICE {
invokeComp [1] IMPLICIT InvokeComponent,
returnResultComp [2] IMPLICIT ReturnResultComponent,
returnErrorComp [3] IMPLICIT ReturnErrorComponent,
rejectComp [4] IMPLICIT RejectComponent}
InvokeComponent ::= SEQUENCE {
invokeID InvokeIDType,
linked-ID [0] IMPLICIT InvokeIDType OPTIONAL,
operation-value OPERATION,
argument ANY DEFINED BY operation-value OPTIONAL}
-- ANY is filled by the single ASN.1 data type following the keyword
-- ARGUMENT in the type definition of a particular operation.
InvokeIDType ::= INTEGER (-32768..32767)
ReturnResultComponent ::= SEQUENCE {
SEQUENCE {
operation-value OPERATION,
result ANY DEFINED BY operation-value
-- ANY is filled by the single ASN.1 data type following the
keyword
-- RESULT in the type definition of a particular operation.
}OPTIONAL}
ReturnErrorComponent ::= SEQUENCE {
error-value ERROR,
parameter ANY DEFINED BY error-value OPTIONAL}
-- ANY is filled by the single ASN.1 data type following the keyword
-- PARAMETER in the type definition of a particular error
RejectComponent ::= SEQUENCE {
invokeID CHOICE {
InvokeIDType,
NULL},
problem CHOICE {
[0] IMPLICIT GeneralProblem,
[1] IMPLICIT InvokeProblem,
[2] IMPLICIT ReturnResultProblem,
[3] IMPLICIT ReturnErrorProblem}}
Page 91
ETS 300 196-1: August 1993
Table D.1: Component types (concluded)
GeneralProblem ::= INTEGER { -- ROSE-provider detected
unrecognizedComponent (0),
mistypedComponent (1),
badlyStructuredComponent (2)}
InvokeProblem ::= INTEGER { -- ROSE-user detected
-- supplementary service entity
duplicateInvocation (0),
unrecognizedOperation (1),
mistypedArgument (2),
resourceLimitation (3),
initiatorReleasing (4),
unrecognizedLinkedID (5),
linkedResponseUnexpected (6),
unexpectedChildOperation (7)}
ReturnResultProblem ::= INTEGER { -- ROSE-user detected
unrecognizedInvocation (0),
resultResponseUnexpected (1),
mistypedResult (2)}
ReturnErrorProblem ::= INTEGER { -- ROSE-user detected
unrecognizedInvocation (0),
errorResponseUnexpected (1),
unrecognizedError (2),
unexpectedError (3),
mistypedParameter (4)}
END -- of Facility-Information-Element-Components
D.2 Definition of generally applicable errors
Table D.2 contains the ASN.1 specification of errors which are applicable to supplementary services using
the common information element category of the functional protocol as specified in Clause 8.
Table D.2: Definition of generally applicable errors
General-Errors {ccitt identified-organization etsi(0) 196 general-errors(2)}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
EXPORTS notSubscribed, notAvailable, notImplemented, invalidServedUserNr,
invalidCallState, basicServiceNotProvided, notIncomingCall,
supplementaryServiceInteractionNotAllowed, resourceUnavailable;
IMPORTS ERROR
{joint-iso-ccitt remote-operations(4) notation(0)};
notSubscribed ERROR ::= 0
-- The requested service or function has not been subscribed for the basic service, and
-- optionally the served user's ISDN number, included in the activation invoke component.
-- Alternatively the basic service may not have been subscribed.
notAvailable ERROR ::= 3
-- The requested supplementary service or function is not available for the basic service,
-- and optionally the served user's ISDN number (e.g. temporary fault).
Page 92
ETS 300 196-1: August 1993
Table D.2: Definition of generally applicable errors (concluded)
notImplemented ERROR ::= 4
-- The supplementary service or function requested is not implemented for the basic
-- service, and optionally the served user's ISDN number (e.g. service not provided).
invalidServedUserNr ERROR ::= 6
-- The served user's number provided is not a valid number.
invalidCallState ERROR ::= 7
-- The supplementary service or function cannot be requested in the current basic call state
-- or auxiliary state.
basicServiceNotProvided ERROR ::= 8
-- The served user has not subscribed to the basic service (bearer and/or teleservice) for
-- which the supplementary service or function was requested.
notIncomingCall ERROR ::= 9
-- The supplementary service or function was not requested for an incoming call.
supplementaryServiceInteractionNotAllowed ERROR ::= 10
-- The performance of the requested supplementary service or function is prohibited
-- by another supplementary service or function.
resourceUnavailable ERROR ::= 11
-- The resources required to perform adequately the requested supplementary service or
-- function are not available.
END -- of General-Errors
D.3 Definition of address types
Table D.3 contains the ASN.1 definition of general applicable address and number types.
Table D.3: Definition of address types
Addressing-Data-Elements {ccitt identified-organization etsi(0) 196 addressing-data-elements(6)}
BEGIN
EXPORTS PresentedAddressScreened, PresentedAddressUnscreened,
PresentedNumberScreened, PresentedNumberUnscreened,
Address, PartyNumber, PartySubaddress,
ScreeningIndicator, PresentationAllowedIndicator;
PresentedAddressScreened ::= CHOICE {
presentationAllowedAddress [0] IMPLICIT AddressScreened,
presentationRestricted [1] IMPLICIT NULL,
numberNotAvailableDueToInterworking [2] IMPLICIT NULL,
presentationRestrictedAddress [3] IMPLICIT AddressScreened }
PresentedAddressUnscreened ::= CHOICE {
presentationAllowedAddress [0] IMPLICIT Address,
presentationRestrictedAddress [3] IMPLICIT Address}
Page 93
ETS 300 196-1: August 1993
Table D.3: Definition of address types (continued)
PresentedNumberScreened ::= CHOICE {
presentationAllowedNumber [0] IMPLICIT NumberScreened,
presentationRestrictedNumber [3] IMPLICIT NumberScreened}
PresentedNumberUnscreened ::= CHOICE {
presentationAllowedNumber [0] PartyNumber,
presentationRestrictedNumber [3] PartyNumber}
AddressScreened ::= SEQUENCE {
PartyNumber,
ScreeningIndicator,
PartySubaddress OPTIONAL}
NumberScreened ::= SEQUENCE {
PartyNumber,
ScreeningIndicator}
Address ::= SEQUENCE {
PartyNumber,
PartySubaddress OPTIONAL}
PartyNumber ::= CHOICE {
unknownPartyNumber [0] IMPLICIT NumberDigits,
-- the numbering plan is the default numbering plan of the
-- network. It is recommended that this value is used.
publicPartyNumber [1] IMPLICIT PublicPartyNumber,
-- the numbering plan is according to
-- CCITT Recommendation E.163 and E.164.
dataPartyNumber [3] IMPLICIT NumberDigits,
-- not used, value reserved.
telexPartyNumber [4] IMPLICIT NumberDigits,
privatePartyNumber [5] IMPLICIT PrivatePartyNumber,
nationalStandardPartyNumber [8] IMPLICIT NumberDigits}
PublicPartyNumber ::= SEQUENCE {
publicTypeOfNumber PublicTypeOfNumber,
publicNumberDigits NumberDigits}
PrivatePartyNumber ::= SEQUENCE {
privateTypeOfNumber PrivateTypeOfNumber,
privateNumberDigits NumberDigits}
NumberDigits ::= NumericString (SIZE(1..20))
PublicTypeOfNumber ::= ENUMERATED {
unknown (0),
-- if used number digits carry prefix indicating type of number
-- according to national recommendations
internationalNumber (1),
nationalNumber (2),
networkSpecificNumber (3),
-- not used, value reserved
subscriberNumber (4),
abbreviatedNumber (6)}
-- valid only for called party number at the outgoing access,
-- network substitutes appropriate number.
Page 94
ETS 300 196-1: August 1993
Table D.3: Definition of address types (concluded)
PrivateTypeOfNumber ::= ENUMERATED {
unknown (0),
level2RegionalNumber (1),
level1RegionalNumber (2),
pTNSpecificNumber (3),
localNumber (4),
abbreviatedNumber (6)}
PartySubaddress ::= CHOICE {
UserSpecifiedSubaddress,
-- not recommended
NSAPSubaddress}
-- according to CCITT Recommendation X.213
UserSpecifiedSubaddress ::= SEQUENCE {
SubaddressInformation,
oddCountIndicator BOOLEAN OPTIONAL}
-- used when the coding of subaddress is BCD
NSAPSubaddress ::= OCTET STRING (SIZE(1..20))
-- specified according to CCITT Recommendation X.213. Some
-- networks may limit the subaddress value to some other
length,
-- e.g. 4 octets
SubaddressInformation ::= OCTET STRING (SIZE(1..20))
-- coded according to user requirements. Some networks may
limit
-- the subaddress value to some other length, e.g. 4 octets
ScreeningIndicator ::= ENUMERATED {
userProvidedNotScreened (0),
-- number was provided by a remote user terminal equipment, and
-- has been screened by a network that is not the local public
-- or local private network.
userProvidedVerifiedAndPassed (1),
-- number was provided by a remote user terminal equipment (or
-- by a remote private network), and has been screened by the
-- local public or local private network.
userProvidedVerifiedAndFailed (2),
-- not used, value reserved
networkProvided (3)}
-- number was provided by local public or local private network
PresentationAllowedIndicator ::= BOOLEAN
END -- of Addressing-Data-Elements
Page 95
ETS 300 196-1: August 1993
D.4 Definition of Q.931 information elements
Table D.4 contains the ASN.1 definition of a general applicable type used to include CCITT
Recommendation Q.931 [5] information elements in ASN.1 definitions.
The Q.931 information elements to be used shall be indicated as comment at the point where the type
Q931InformationElement is used.
Table D.4: Definition of Q.931 information elements
Embedded-Q931-Types {ccitt identified-organization etsi(0) 196 embedded-q931-types(7)}
BEGIN
EXPORTS Q931InformationElement;
Q931InformationElement ::= [APPLICATION 0] IMPLICIT OCTET STRING
END -- of Embedded-Q931-Types
D.5 Formal definition of basic services
For a number of reasons it may be necessary that the network unambiguously identifies the
telecommunications service it shall handle. The service information may be applied, e.g.:
- when a service is subscribed to and registered;
- for charging purposes;
- in the case of service interworking;
- in the case of supplementary service management, because some of the supplementary services
can be managed individually per basic service (e.g. call forwarding and closed user group
supplementary services).
In the DSS1 protocol, a telecommunications service is specified by a combination of values (codepoints) of
the High layer compatibility information element and the Bearer capability information elements. The
progress indicator shall not effect the selection of the basic service.
Table D.5 specifies the relationship between combinations of Bearer capability and High layer compatibility
information element values and a basic service.
Page 96
ETS 300 196-1: August 1993
Table D.5
|High layer | |
|compatibility| Bearer capability (octet 3) (NOTE 1) |
|(octet 4) ||
| |Speech |3,1 kHz |Unrestricted|Unrestricted |Other |
| | |audio |digital |digital | |
| | | |information |information | |
| | | | |with tones/ | |
| | | | |announcements| |
| |00000 |10000 |01000 |10001(NOTE 6)| |
|=========|========|============|=============|======|
| j | | | | |
|Telephony jTelephony|Audio |Unrestricted|Telephony |NOTE 4|
|(000 0001) j3,1 kHz |3,1 kHz |digital |7 kHz | |
| j(NOTE 5) | |information |(NOTE 5) | |
|j|||||
|Facsimile jSpeech |Telefax |Unrestricted|NOTE 7 |NOTE 4|
|Group 2/3 j |group2/3|digital | | |
|(000 0100) j |(NOTE 5)|information | | |
| j | | | | |
| j | | | | |
|j|||||
|Facsimile jSpeech |Audio |Telefax |NOTE 7 |NOTE 4|
|Group 4 j |3,1 kHz |group 4 | | |
|class 1 j | |class 1 | | |
|(010 0001) j | |(NOTE 5) | | |
| j | | | | |
|j|||||
|Teletex jSpeech |Audio |Teletex |NOTE 7 |NOTE 4|
|Basic mode j |3,1 kHz |(NOTE 5) | | |
|(011 0001) j | | | | |
| j | | | | |
| j | | | | |
|j|||||
|Videotex jSpeech |Audio |Videotex |NOTE 7 |NOTE 4|
|(011 0010) j |3,1 kHz |syntax | | |
| j | |based | | |
| j | |(NOTE 5) | | |
| j | | | | |
|j|||||
|Audiovisual jSpeech |Audio |Video |Video |NOTE 4|
|(110 0000) j |3,1 kHz |telephony |telephony | |
| j | |(NOTE 2,5) |(NOTE 3,5) | |
|j|||||
|Other or no jSpeech |Audio |Unrestricted|NOTE 7 |NOTE 4|
|HLC present j |3,1 kHz |digital | | |
| j | |information | | |
| j | | | | |
| j | | | | |
!"++++!
NOTE 1: This table assumes that octet 4 of the Bearer capability information element is encoded
with "circuit mode" and "64 kbit/s". Actions for other values in octet 4 will require study.
NOTE 2: Used for the second connection of the video telephony teleservice.
NOTE 3: Used for the first connection of the video telephony teleservice.
NOTE 4: The use of other information transfer capabilities shall be rejected.
NOTE 5: If the indicated teleservice is not supported by the network, then the basic service
related to the bearer service shall apply.
NOTE 6: In ETS 300 102-1 [13] known as "7 kHz audio".
NOTE 7: No defined appropriate ETSI basic service. Networks and users may implement an
appropriate bearer service which is outside the scope of this ETS.
Page 97
ETS 300 196-1: August 1993
Table D.6 contains the ASN.1 definition of ISDN basic services.
Table D.6: Formal definition of basic services
Basic-Service-Elements {ccitt identified-organization etsi(0) 196 basic-service-elements(8)}
BEGIN
EXPORTS BasicService;
BasicService ::= ENUMERATED {
allServices (0),
speech (1),
unrestrictedDigitalInformation (2),
audio3k1Hz (3),
unrestrictedDigitalInformationWithTonesAndAnnouncements (4),
telephony3k1Hz (32),
teletex (33),
telefaxGroup4Class1 (34),
videotexSyntaxBased (35),
videotelephony (36),
telefaxGroup2-3 (37),
telephony7kHz (38)}
END -- of Basic-Service-Elements
NOTE: The result of using the value "allServices" for the control of supplementary services
shall be identical to the subsequent use of the individual basic services the user has
subscribed to and for which the supplementary service applies and is subscribed to at
the point of time the request is received.
D.6 Operations and errors for explicit channel reservation control
Table D.7 defines the operations and errors necessary for the explicit channel reservation procedures.
Table D.7: Explicit network controlled channel reservation
Explicit-Network-Controlled-Channel-Reservation {ccitt identified-organization etsi(0) 196
explicit-network-controlled-channel-reservation(4)}
DEFINITIONS ::=
BEGIN
EXPORTS ExplicitReservationCreationControl, ExplicitReservationManagement,
ExplicitReservationCancel, MaximumNumberOfReservationsReached,
NoExplicitReservationExistsOrInvalidReservationIndicator,
UnwantedReservationCreated, ImplicitReservationUsed, ReservationIndicator;
{joint-iso-ccitt remote-operations(4) notation(0)}
notAvailable, notSubscribed
FROM General-Errors
{ccitt identified-organization etsi(0) 196 general-errors(2)};
Page 98
ETS 300 196-1: August 1993
Table D.7: Explicit network controlled channel reservation (concluded)
ExplicitReservationCreationControl ::= OPERATION
ARGUMENT controlOption ENUMERATED {
noReservationRequired (0),
reservationRequiredWithReservationIndicator (1),
reservationRequiredWithoutReservationIndicator (2)} -- optional
RESULT ReservationIndicator -- optional
ERRORS { maximumNumberOfReservationsReached,
notAvailable,
notSubscribed,
unwantedReservationCreated}
ExplicitReservationManagement ::= OPERATION
ARGUMENT ReservationIndicator -- optional
RESULT
ERRORS { noExplicitReservationExistsOrInvalidReservationIndicator,
notAvailable,
notSubscribed,
implicitReservationUsed}
ExplicitReservationCancel ::= OPERATION
ARGUMENT ReservationIndicator -- optional
RESULT
ERRORS { noExplicitReservationExistsOrInvalidReservationIndicator,
notAvailable,
notSubscribed}
MaximumNumberOfReservationsReached ::= ERROR
NoExplicitReservationExistsOrInvalidReservationIndicator ::= ERROR
UnwantedReservationCreated ::= ERROR
ImplicitReservationUsed ::= ERROR
ReservationIndicator ::= INTEGER (-128..127)
explicitReservationCreationControl ExplicitReservationCreationControl ::= 20
explicitReservationManagement ExplicitReservationManagement ::= 21
explicitReservationCancel ExplicitReservationCancel ::= 22
maximumNumberOfReservationsReached MaximumNumberOfReservationsReached ::= 33
noExplicitReservationExistsOrInvalidReservationIndicator
NoExplicitReservationExistsOrInvalidReservationIndicator ::= 34
unwantedReservationCreated UnwantedReservationCreated ::= 35
implicitReservationUsed ImplicitReservationUsed ::= 36
END -- of Explicit-Network-Controlled-Channel-Reservation
Page 99
ETS 300 196-1: August 1993
D.7 Operation for status request procedure
Table D.8 defines the operations necessary for the statust request procedure.
Table D.8
Status-Request-Procedure {ccitt identified-organization etsi(0) 196 status-request-procedure(9)}
DEFINITIONS EXPLICIT TAGS::=
BEGIN
EXPORTS StatusRequest;
{joint-iso-ccitt remote-operations(4) notation(0)}
Q931InformationElement
FROM Embedded-Q931-Types
{ccitt identified-organization etsi(0) 196 embedded-q931-types(7)};
StatusRequest ::= OPERATION
ARGUMENT SEQUENCE {
compatibilityMode CompatibilityMode,
q931InformationElement Q931InformationElement}
-- The BC, HLC (optional) and LLC (optional) information
-- elements shall be embedded in q931InfoElement
RESULT StatusResult
StatusResult ::= ENUMERATED {
compatibleAndFree (0),
compatibleAndBusy (1),
incompatible (2)}
CompatibilityMode ::= ENUMERATED {
allBasicServices (0),
oneOrMoreBasicServices (1)}
statusRequest StatusRequest ::= {ccitt identified-organization etsi(0) 196
status-request-procedure(9) statusRequest-operation(1)}
END -- Status-Request-Procedure
Page 100
ETS 300 196-1: August 1993
D.8 Types for notification procedures
Table D.9 defines the types and data structures used for the notification procedures.
Table D.9: ASN.1 definition of the Notification Indicator
Notification-Indicator-IE-Data-Structure {ccitt identified-organization etsi(0) 196
notification-data-structure(5)}
DEFINITIONS ::=
BEGIN
EXPORTS NOTIFICATION;
NOTIFICATION MACRO ::=
BEGIN
TYPE NOTATION ::= Argument
VALUE NOTATION ::= value (VALUE CHOICE {
localValue INTEGER,
globalValue OBJECT IDENTIFIER})
Argument ::= "ARGUMENT" NamedType
NamedType ::= identifier type | type
END -- of NOTIFICATION MACRO
NotificationDataStructure ::= SEQUENCE {
notificationTypeID NOTIFICATION,
notificationArgument ANY DEFINED BY notificationTypeID}
-- ANY is filled by the single ASN.1 type following the keyword
-- ARGUMENT in the type definition of a particular notification.
END -- of Notification-Indicator-IE-Data-Structure
Page 101
ETS 300 196-1: August 1993
Annex E (informative): Formal definition of remote operations notation
Table E.1: Formal definition of remote operations data types
(extract of CCITT Recommendation X.219 figure 4/X.219)
Remote-Operation-Notation {joint-iso-ccitt remote-operations(4) notation(0)}
DEFINITIONS ::=
BEGIN
EXPORTS OPERATION, ERROR;
-- macro definition for operations
OPERATION MACRO ::=
BEGIN
TYPE NOTATION ::= ArgumentResultErrorsLinkedOperations
localValue INTEGER,
Argument ::= "ARGUMENT" NamedType | 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 operation
-- value is specified
END -- of OPERATION MACRO
-- macro definition for operations errors
ERROR MACRO ::=
BEGIN
TYPE NOTATION ::= Parameter
localValue INTEGER,
Parameter ::= "PARAMETER" NamedType | empty
END -- of ERROR MACRO
END -- end of Remote-Operation-Notation
Page 102
ETS 300 196-1: August 1993
Annex F (informative): Coding examples
F.1 Coding of component types
Although the coding of the component types is defined by application of the basic encoding rules to the
abstract syntax, this Annex gives some examples of the coding for illustrative purposes.
Tables F.1, F.2, F.3 and F.4 show the component structure after encoding according to the Basic
Encoding Rules as specified in CCITT Recommendation X.209 [7]
Table F.1: Invoke component
| Invoke component |Mandatory |Octet|

| |indication| |
||||
| Component type tag |Mandatory | 4 |
| Component length (NOTE 1) | | 5 |
| |||
| |Invoke identifier tag |Mandatory | 6 |
| |Invoke identifier length | | 7 |
| |Invoke identifier | | 8 |
| ||||
| |Linked identifier tag |Optional | 9 |
| |Linked identifier length | | 10 |
| |Linked identifier | | 11 |
| ||||
| |Operation value tag |Mandatory | 12 |
| |Operation value length | | 13 |
| |Operation value | | 14 |
| ||||
| |Argument (NOTE 2) |Optional | 15, |
| | | | etc.|
!+++!
NOTE 1: The component length is coded to indicate the number of octets contained in the
component (excluding the component type tag and the component length octets).
NOTE 2: This is a parameter of the invoke component type.
Table F.2: Return result component
| Return result component |Mandatory |Octet|

| |indication| |
||||
| |||
| ||||
| | Sequence tag |Optional | 9 |
| | Sequence length (NOTE 4)|(NOTE 1) | 10 |
| | |||
| | | Operation value tag |Optional | 11 |
| | | Operation value length|(NOTE 2) | 12 |
| | | Operation value | | 13 |
| | ||||
| | | Result (NOTE 5) |Optional | 14, |
| | | | | etc.|
!++++!
NOTE 1: If the return result component does not include any result, then the sequence and
operational value shall be omitted.
NOTE 2: If a result is included, then the operation value is mandatory and is the first element in
the sequence.
Page 103
ETS 300 196-1: August 1993
NOTE 4: The sequence length is coded to indicate the number of octets contained in the
sequence (excluding the sequence type tag and the sequence length octets).
NOTE 5: This is a parameter of the return result component type.
Table F.3: Return error component
| Return error component |Mandatory |Octet|

| |indication| |
||||
| |||
| ||||
| |Error value tag |Mandatory | 9 |
| |Error value length | | 10 |
| |Error value | | 11 |
| ||||
| |Parameter (NOTE 2) |Optional | 12, |
| | | | etc.|
!+++!
NOTE 2: This is a parameter of the return error component type.
Table F.4: Reject component
| Reject component |Mandatory |Octet|

| |indication| |
||||
| Component length (NOTE) | | 5 |
| |||
| ||||
| |Problem tag |Mandatory | 9 |
| |Problem length | | 10 |
| |Problem | | 11 |
!+++!
NOTE: The component length is coded to indicate the number of octets contained in the
Page 104
ETS 300 196-1: August 1993
F.2 Embedding of existing ETS 300 102-1 information elements
Figure F.1 gives an diagrammatic description of the coding resulting of embedding ETS 300 102-1 [13]
information elements in components. The tag is defined in table F.5.

| Parameter set/sequence tag |
||
| Length |
|| |
| . | |
| . | |
| | |
| | Q.931 information elements tag | | |
| || | |
| | Q.931 information elements length | | |
| || | | |
| | | | | |
| | First Q.931 information element | | | |
| | | | | |
| || | | |
| | | | | |
| | Second Q.931 information element | | | |
| | | | | |
| || | | |
| | . | | | |
| | . | | | |
| || | | |
| | | | | |
| | Last Q.931 information element | | | |
| | | | | |
| !!<! | |
| . | |
| . | |
!!<!
Figure F.1: Encapsulation of Q.931 information elements
Table F.5: Q.931 information elements tag
| | 8 7 6 5 4 3 2 1 |
|||
| Q.931 information elements | 0 1 0 0 0 0 0 0 |
!+!
NOTE: All other values are reserved but this approach may also be applied in the future to
coding structures from other ETSs by defining other tags as required.
Page 105
ETS 300 196-1: August 1993
Annex G (informative): Assignment of object identifier values
The following values are assigned in this ETS:
{ccitt identified-organization etsi(0) 196 general-errors(2)}
{ccitt identified-organization etsi(0) 196 facility-information-element-component(3)}
{ccitt identified-organization etsi(0) 196 explicit-network-controlled-channel-reservation(4)}
{ccitt identified-organization etsi(0) 196 notification-data-structure(5)}
{ccitt identified-organization etsi(0) 196 addressing-data-elements(6)}
{ccitt identified-organization etsi(0) 196 embedded-q931-types(7)}
{ccitt identified-organization etsi(0) 196 basic-service-elements(8)}
{ccitt identified-organization etsi(0) 196 status-request-procedure(9)}
{ccitt identified-organization etsi(0) 196 status-request-procedure(9) statusRequest-operation(1)}
Page 106
ETS 300 196-1: August 1993
History
Document history
August 1993 First Edition
January 1994 Corrigendum to First Edition
April 1994 Corrigendum to First Edition: change to part 1 of a multi-part standard
March 1996 Converted into Adobe Acrobat Portable Document Format (PDF)
and incorporation of all prior Corrigenda

Euro ISDN Protocol EDSS1

Uploaded by

Copyright:

Available Formats

Euro ISDN Protocol EDSS1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Euro ISDN Protocol EDSS1

Uploaded by

Copyright:

Available Formats

N

|Timer |Time out |Cause for |Normal stop |At expiry |

|Timer |Time out |Cause for |Normal stop |At expiry |

|Timer |Time out |Cause for |Normal stop|At expiry |

| Information | Reference | Direction | Type | Length|

| Information | Reference | Direction | Type | Length|

| Information | Reference | Direction | Type | Length|

| Information | Reference | Direction | Type | Length|

| Information | Reference | Direction | Type | Length|

| Information | Reference | Direction | Type | Length|

| Information | Reference | Direction | Type | Length|

| Information | Reference | Direction | Type | Length|

| Information | Reference | Direction | Type | Length|

| Information | Reference | Direction | Type | Length|

| Information | Reference | Direction | Type | Length|

| Information | Reference | Direction | Type | Length|

| Information | Reference | Direction | Type | Length|

| Information | Reference | Direction | Type | Length|

| Information | Reference | Direction | Type | Length|

|Bits |Section |Maximum |

| Notification description (octet 3) |

| Call State value (Octet 3) |

| Invoke component |Mandatory |Octet|

| Return result component |Mandatory |Octet|

| Return error component |Mandatory |Octet|

| Reject component |Mandatory |Octet|

You might also like