SIST ETS 300 138-1 E1:2005
(Main)Integrated Services Digital Network (ISDN); Closed User Group (CUG) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification
Integrated Services Digital Network (ISDN); Closed User Group (CUG) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification
ISDN User-Network Layer 3 Signalling Protocols for Supplementary Services
Digitalno omrežje z integriranimi storitvami (ISDN) - Dopolnilna storitev: zaprta skupina uporabnikov (CUG) - Protokol digitalne naročniške signalizacije št. 1 (DSS1) - 1. del: Specifikacija protokola
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-julij-2005
'LJLWDOQRRPUHåMH]LQWHJULUDQLPLVWRULWYDPL,6'1'RSROQLOQDVWRULWHY]DSUWD
VNXSLQDXSRUDEQLNRY&8*3URWRNROGLJLWDOQHQDURþQLãNHVLJQDOL]DFLMHãW
'66GHO6SHFLILNDFLMDSURWRNROD
Integrated Services Digital Network (ISDN); Closed User Group (CUG) supplementary
service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol
specification
Ta slovenski standard je istoveten z: ETS 300 138-1 Edition 1
ICS:
33.080 Digitalno omrežje z Integrated Services Digital
integriranimi storitvami Network (ISDN)
(ISDN)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
EUROPEAN ETS 300 138-1
TELECOMMUNICATION May 1992
STANDARD
Source: ETSI TC-SPS Reference: T/S 46-33H
ICS: 33.080
ISDN, supplementary service
Key words:
Integrated Services Digital Network (ISDN);
Closed User Group (CUG) supplementary service;
Digital Subscriber Signalling System No. one (DSS1) protocol;
Part 1: Protocol specification
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
F-06921 Sophia Antipolis CEDEX - FRANCE
Postal address:
650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
Office address:
c=fr, a=atlas, p=etsi, s=secretariat - secretariat@etsi.fr
X.400: Internet:
Tel.: +33 92 94 42 00 - Fax: +33 93 65 47 16
Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1992. All rights reserved.
New presentation - see History box
Page 2
ETS 300 138-1: May 1992
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 138-1: May 1992
Contents
Foreword.5
1 Scope .7
2 Normative references .7
3 Definitions.8
4 Symbols and abbreviations.9
5 Description .9
6 Operational requirements.9
6.1 Provision and withdrawal .9
6.2 Requirements on the originating network side.10
6.3 Requirements on the destination network side .10
7 Coding requirements.11
7.1 ASN.1 description of coding requirements .11
7.2 Coding of the Cause information element .12
8 State definitions .12
9 Signalling procedures at the coincident S and T reference point .13
9.1 Activation, deactivation and registration.13
9.2 Invocation and operation.13
9.2.1 Call originating from a user with the CUG supplementary service (explicit
request). 13
9.2.1.1 Normal operation.13
9.2.1.2 Exceptional procedures.13
9.2.2 Call originating from a user with the CUG supplementary service (default
request). 14
9.2.2.1 Normal operation.14
9.2.2.2 Exceptional procedures.14
9.2.3 Call originating from a user without the CUG supplementary service.15
9.2.3.1 Normal operation.15
9.2.3.2 Exceptional procedures.15
9.2.4 Call terminating at a user with the CUG supplementary service.15
9.2.4.1 Normal operation.15
9.2.4.2 Exceptional procedures.16
9.2.5 CUG checks at the originating and destination network.16
10 Procedures for interworking with private ISDNs .19
11 Interactions with other networks .19
12 Interactions with other supplementary services .19
13 Parameter values (timers).19
14 Dynamic description (SDL).19
14.1 The closed user group process .19
14.2 Relation to basic call control. 20
Page 4
ETS 300 138-1: May 1992
Annex A (informative): Signalling flows .25
Annex B (informative): Diagrammatic description of coding requirements .28
B.1 CUG call invoke component (typical example).28
B.2 CUG call return error component .29
History .30
Page 5
ETS 300 138-1: May 1992
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) Closed User Group
(CUG) supplementary service, 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".
In accordance with CCITT Recommendation I.130, the following three level structure is used to describe
the supplementary telecommunications services as provided by European public telecommunications
operators under the pan-European Integrated Services Digital Network (ISDN):
- Stage 1: is an overall service description, from the user's stand-point;
- Stage 2: identifies the functional capabilities and information flows needed to support the service
described in stage 1; and
- Stage 3: defines the signalling system protocols and switching functions needed to implement the
service described in stage 1.
This ETS details the stage 3 aspects (signalling system protocols and switching functions) needed to
support the Closed User Group (CUG) supplementary service. The stage 1 and stage 2 aspects are
detailed in ETS 300 136 (1992) and ETS 300 137 (1992), respectively.
This reprint includes all previous Corrigenda as shown in the History box at the last page.
Page 6
ETS 300 138-1: May 1992
Blank page
Page 7
ETS 300 138-1: May 1992
1 Scope
This first part of ETS 300 138 specifies the stage three of the Closed User Group (CUG) supplementary
service for the pan-European Integrated Services Digital Network (ISDN) as provided by European public
telecommunications operators at the T reference point or coincident S and T reference point (as defined in
CCITT Recommendation I.411 [1]) by means of the Digital Subscriber Signalling System No. one (DSS1).
Stage three identifies the protocol procedures and switching functions needed to support a
telecommunications service (see CCITT Recommendation I.130 [2]).
In addition this standard specifies the protocol requirements at the T reference point where the service is
provided to the user via a private ISDN.
This standard does not specify the additional protocol requirements where the service is provided to the
user via a telecommunications network that is not an ISDN.
The CUG supplementary service enables users to form groups, to and from which access is restricted. A
specific user may be a member of one or more closed user groups. Members of a specific closed user
group can communicate among themselves but not, in general, with users outside the group.
The CUG supplementary service is applicable to all telecommunication services.
Further parts of this standard specify the method of testing required to identify conformance to this
standard.
This standard is applicable to equipment, supporting the CUG supplementary service, to be attached at
either side of a T reference point or coincident S and T reference points when used as an access to the
public ISDN.
2 Normative references
This ETS incorporates by dated and undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are 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.411 (1988): "ISDN user-network interfaces -
Reference configurations".
[2] CCITT Recommendation I.130 (1988): "Method for the characterisation of
telecommunications services supported by an ISDN and network capabilities of
an ISDN".
[3] CCITT Recommendation I.112 (1988): "Vocabulary of terms for ISDNs".
[4] CCITT Recommendation I.210 (1988): Principles of telecommunication services
supported by an ISDN and the means used to describe them".
[5] CCITT Recommendation E.164 (1988): "Numbering plan for the ISDN era".
[6] ETS 300 136 (1992): "Integrated Services Digital Network (ISDN); Closed User
Group (CUG) supplementary service; Service description".
[7] ETS 300 195-1: "Integrated Services Digital Network (ISDN); Supplementary
service interactions; Digital Subscriber Signalling System No. one (DSS1)
protocol; Part 1: Protocol specification".
[8] CCITT Recommendation X.208 (1988): "Open Systems Interconnection (OSI);
Model and Notation: Service definition: Specification of Abstract Syntax Notation
One (ASN.1)".
Page 8
ETS 300 138-1: May 1992
[9] CCITT Recommendation X.209 (1988): "Open Systems Interconnection (OSI);
Model and Notation: Service definition: Specification of basic encoding rules for
Abstract Syntax Notation One (ASN.1)".
[10] ETS 300 102-1 (1990): "Integrated Services Digital Network (ISDN); User-
network interface layer 3; Specifications for basic call control".
[11] ETS 300 102-2 (1990): "Integrated Services Digital Network (ISDN); User-
network interface layer 3; Specifications for basic call control; Specification
Description Language (SDL) diagrams".
[12] ETS 300 196-1: "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".
[13] CCITT Recommendation X.219 (1988): "Remote Operations: Notation and
Service Definition".
[14] CCITT Recommendation Z.100 (1988): "Functional Specification and Description
Language (SDL)".
3 Definitions
For the purpose of this standard, the following definitions apply:
Basic telecommunication service: a bearer service or teleservice. The terms "bearer service" and
"teleservice" are defined in CCITT Recommendation I.112 [3], § 2.2, definitions 202 and 203.
CUG call: see ETS 300 136 [6], Clause 3.
CUG index: the closed user group index is a parameter used by the calling user to select a particular
closed user group when originating a call. The index is also used by the network to indicate to the called
user the closed user group from which an incoming call has originated. This index has only local
significance, i.e. the index used by the calling user is, in general, different from the index used by the called
user to identify the same closed user group.
CUG interlock code: this is a means of identifying closed user group membership within the network. At
the calling side, if a closed user group match exists, the CUG index identifying a closed user group maps to
the closed user group interlock code for that closed user group. If a closed user group match exists at the
called side the closed user group interlock code identifying a closed user group maps to the CUG index
representing that closed user group. Closed user group interlock code is not an access concept, but is
used for clarity during the descriptions of signalling procedures and flows.
Default number: an ISDN number registered within the public ISDN following prior agreement between the
third user and the public ISDN.
Incoming access: see ETS 300 136 [6], Clause 3.
Incoming calls barred within a closed user group: see ETS 300 136 [6], Clause 3.
Integrated Services Digital Network (ISDN): see CCITT Recommendation I.112 [3], § 2.3, definition
308.
ISDN number: a number conforming to the numbering plan and structure specified in CCITT
Recommendation E.164 [5].
Network: the DSS1 protocol entity at the network side of the user-network interface.
Outgoing access: see ETS 300 136 [6], Clause 3.
Page 9
ETS 300 138-1: May 1992
Outgoing calls barred within a closed user group: see ETS 300 136 [6], Clause 3.
Preferential CUG: a closed user group user subscribing to preferential closed user group nominates a
CUG index which the network uses as a default to identify the required closed user group in the absence of
any closed user group information in the outgoing call request. A preferential closed user group applies to
an ISDN number (or to an ISDN number/service - see subclause 6.1) and not to a specific closed user
group.
Service; Telecommunications service: see CCITT Recommendation I.112 [3], § 2.2, definition 201.
Supplementary service: see CCITT Recommendation I.210 [4], § 2.4.
User: the DSS1 protocol entity at the user side of the user-network interface.
4 Symbols and abbreviations
CES Connection Endpoint Suffix
CUG Closed User Group
DSS1 Digital Subscriber Signalling System No. one
IA Incoming Access
ICB Incoming Calls Barred within a closed user group
ISDN Integrated Services Digital Network
OA Outgoing Access
OCB Outgoing Calls Barred within a closed user group
5 Description
Essentially normal call establishment procedures shall apply but, additionally, to provide the CUG
supplementary service, the network shall analyse the call request from the calling user in conjunction with
the closed user group attributes associated with both the calling and called users (as identified by their
ISDN numbers). As a result of this analysis the call can either fail for CUG supplementary service reasons
or be allowed to proceed.
The network provider may define the maximum number of closed user groups of which a user can be a
member.
Since the fundamental purpose of the CUG supplementary service is to prevent certain connections the
network shall strictly control interactions with some other supplementary services to protect closed user
group integrity.
6 Operational requirements
6.1 Provision and withdrawal
The provision of the CUG supplementary service to a new member and also the assignment of the various
CUG supplementary service options to a new or existing member, shall require a prior arrangement
between the member and the network provider.
The CUG supplementary service shall be provided on a subscription basis. As a network provider option,
the CUG supplementary service may be offered with subscription options.
Page 10
ETS 300 138-1: May 1992
The options can be divided into two groups:
a) the options shown in table 1 shall apply per ISDN number. The option values may be
assigned individually for each basic service, or set of basic services, available at the
ISDN number with the CUG supplementary service.
b) the option shown in table 2 shall apply per closed user group provided at the ISDN
number with the CUG supplementary service.
Table 1: Options available per ISDN number
�˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜´˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜¿
‡Option (NOTE) ‡ Values ‡
ˆ˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜·
‡1) Preferential CUG ‡ Nominated CUG index, ‡
‡ ‡ or none designated. ‡
ˆ˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜·
‡2) Outgoing access ‡ Allowed, or ‡
‡ ‡ not allowed. ‡
ˆ˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜·
‡3) Incoming access ‡ Allowed, or ‡
‡ ‡ not allowed. ‡
ˆ˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜`˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜·
‡NOTE: If, for a user with the CUG supplementary service, a ‡
‡basic service, or set of basic services, is not included in ‡
‡at least one closed user group, then: ‡
‡- preferential CUG shall have the "none designated" option ‡
‡ value; ‡
‡- outgoing access shall have the "allowed" option value if ‡
‡ normal outgoing calls using that basic service, or set of ‡
‡ basic services, are required; ‡
‡- incoming access shall have the "allowed" option value if ‡
‡ incoming calls using that basic service, or set of basic ‡
‡ services, are required. ‡
�˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜�
Table 2: Options available per closed user group
�˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜´˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜¿
‡Option ‡ Values ‡
ˆ˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜·
‡1) Barring within the ‡ None, ‡
‡ closed user group ‡ incoming calls, or ‡
‡ ‡ outgoing calls. ‡
�˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜`˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜�
The options assigned to a closed user group member shall be stored in the network.
Withdrawal of the CUG supplementary service shall be as a result of network provider action either at the
request of a particular member, or for administrative reasons.
6.2 Requirements on the originating network side
For correct interactions with certain other supplementary services, the originating network side shall store,
for the duration of the call, details of whether a normal or a CUG call was requested in the information sent
to the destination network side. The CUG interlock code (if any) of the call request to the destination
network side shall also be retained. However, if the network knows that such interactions are not possible
(e.g. the user has only the CUG supplementary service) then the information may be discarded.
6.3 Requirements on the destination network side
For correct interactions with certain other supplementary services, the destination network side shall store,
for the duration of the call, details of whether a normal or a CUG call request was passed to the called
user. The CUG interlock code (if any) of the call request shall also be retained. However, if the network
knows that such interactions are not possible (e.g. the user has only the CUG supplementary service) then
the information may be discarded.
Page 11
ETS 300 138-1: May 1992
7 Coding requirements
7.1 ASN.1 description of coding requirements
Table 3 provides an Abstract Syntax Notation one (ASN.1) description of the coding of the Facility
information element components necessary to support this service in accordance with CCITT
Recommendations X.208 [8] and X.209 [9] and uses the OPERATION and ERROR macro as defined in
figure 4/X.219 of CCITT Recommendation X.219 [13].
Table 3
Closed-User-Group-Service-Operations
{ccitt identified-organisation etsi (0) 138 operations-and-errors (1)}
DEFINITION ::=
BEGIN
EXPORTS CUGCall, InvalidOrUnregisteredCUGIndex.
RequestedBasicServiceViolatesCUGConstraints,
OutgoingCallsBarredWithinCUG, IncomingCallsBarredWithinCUG,
UserNotMemeberOfCUG,
InconsistencyInDesignatedFacilityAndSubscriberClass
IMPORTS OPERATION,
ERROR
FROM Remote-Operation-Notation
{joint-iso-ccitt remote-operations(4) notation(0)},
notSubscribed, basicServiceNotProvided
FROM General-Errors
{ccitt identified-organisation etsi (0) 196 general-errors};
CUGcall ::= OPERATION
-- in Facility information element. Invoked from calling user to
-- originating network side. Also from destination network side
-- to called user
ARGUMENT SEQUENCE {
OARequested DEFAULT FALSE,
CUGIndex OPTIONAL}
-- in SETUP message
ERRORS {
invalidOrUnregisteredCUGIndex,
requestedBasicServiceViolatesCUGConstraints,
outgoingCallsBarredWithinCUG,
incomingCallsBarredWithinCUG,
userNotMemberOfCUG,
basicServiceNotProvided,
incosistenceyInDesignatedFacilityAndSubscriberClass,
notSubscribed}
-- in clearing message to calling user. Also to destination
-- network side.
Page 12
ETS 300 138-1: May 1992
Table 3 (concluded)
InvalidOrUnregisteredCUGIndex ::= ERROR
RequestedBasicServiceViolatesCUGConstraints ::= ERROR
OutgoingCallsBarredWithinCUG ::= ERROR
IncomingCallsBarredWithinCUG ::= ERROR
UserNotMemberOfCUG ::= ERROR
InconsistenceyInDesignatedFacilityAndSubscriberClass ::= ERROR
OARequested ::= [1] IMPLICIT BOOLEAN
CUGIndex ::= [2] IMPLICIT INTEGER (0.32767)
cUGCall CUGCall ::= 2
invalidOrUnregisteredCUGIndex InvalidOrUnregisteredCUGIndex ::= 16
requestedBasicServiceViolatesCUGConstraints RequestedBasicServiceViolatesCUGConstraints ::= 17
outgoingCallsBarredWithinCUG OutgoingCallsBarredWithinCUG ::= 18
incomingCallsBarredWithinCUG IncomingCallsBarredWithinCUG ::= 19
userNotMemberOfCUG UserNotMemberOfCUG ::= 20
inconsistencyInDesignatedFacilityAndSubscriberClass InconsistencyInDesignatedFacilityAndSubscriberClass
::= 21
END -- of Closed-User-Group-Service-Operations
7.2 Coding of the Cause information element
The cause value for use in the Cause information element in certain CUG service related circumstances (as
described in Clause 9 and Clause 11) is defined in table 4.
Table 4
�˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜´˜˜˜˜˜˜˜˜´˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜´˜˜˜˜˜˜˜˜˜˜˜˜˜¿
‡ Cause value ‡ ‡ ‡ ‡
ˆ˜˜˜˜˜˜˜´˜˜˜˜˜˜˜˜· Cause ‡ ‡ ‡
‡ Class ‡ Value ‡ number ‡ Cause ‡ Diagnostics ‡
‡ bits ‡ bits ‡ ‡ ‡ ‡
‡ 7 6 5 ‡ 4 3 2 1‡ ‡ ‡ ‡
ˆ˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜˜˜·
‡ ‡ ‡ ‡ ‡ ‡
‡ 1 0 1 ‡ 0 1 1 1‡ 87 ‡ User not a member of CUG ‡ - ‡
‡ ‡ ‡ ‡ ‡ ‡
�˜˜˜˜˜˜˜`˜˜˜˜˜˜˜˜`˜˜˜˜˜˜˜˜`˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜`˜˜˜˜˜˜˜˜˜˜˜˜˜�
8 State definitions
No specifically defined ETS 300 102-1 [10] protocol control states shall be required for the CUG
supplementary service.
Page 13
ETS 300 138-1: May 1992
To facilitate understanding of the service the following closed user group process states are used in the
dynamic description (SDL):
- CUG idle;
- outgoing CUG;
- incoming CUG.
These states are specified for the purpose of the protocol definition; these states need not be provided in
an implementation.
9 Signalling procedures at the coincident S and T reference point
9.1 Activation, deactivation and registration
Not applicable.
9.2 Invocation and operation
The CUG supplementary service shall be invoked by:
- a call originating from a CUG supplementary service user. The user may explicitly
request the CUG supplementary service, but in the absence of an explicit request the
CUG supplementary service default procedures shall be automatically applied;
- a call terminating at a CUG supplementary service user.
9.2.1 Call originating from a user with the CUG supplementary service (explicit request)
9.2.1.1 Normal operation
To request explicitly the CUG supplementary service the calling user shall include in the outgoing SETUP
message a Facility information element containing a cUGCall invoke component. If no Calling party number
information element is included by the calling user in the SETUP message, the default number stored in the
originating network shall be used for the assignment of the closed user group.
The network shall perform internal checks appropriate to the originating network based on the contents of
the cUGCall invoke component and the closed user group attributes of the calling user. The outcomes of
these checks are defined in table 5 (including notes).
NOTE: the network may respond to the SETUP message with a SETUP ACKNOWLEDGE or
CALL PROCEEDING message or the call may be cleared for some reason unrelated
to the CUG supplementary service before the checks are completed.
If the result of the checks relevant to the originating network side allows the call to proceed then the
destination network shall perform further internal checks based on the closed user group attributes (if any)
of the called user. The outcomes of these checks are defined in table 6 (including notes).
If the call is successfully offered to the called user, then basic call control procedures shall apply at the
calling user's interface.
9.2.1.2 Exceptional procedures
If, as a result of the checks relevant to either the originating or destination network, the network cannot
allow the call to proceed for a CUG supplementary service related reason, then the network shall fail the
call attempt and include in the first clearing message returned to the calling user (before the alerting
phase) a Facility information element containing a cUGCall return error component with the appropriate
indication as defined by tables 5 and 6 (including notes).
Page 14
ETS 300 138-1: May 1992
The cause in the clearing message conveying the cUGCall return error component should be #29 "facility
rejected".
If the call attempt fails for a reason unrelated to the CUG supplementary service, then a Facility
information element containing a cUGCall return error component indicating "basicServiceNotProvided"
should be included in the first clearing message returned to the calling user (before the alerting phase).
The cause cited shall be determined by the event causing the failure. If there is no cUGCall return error
component present in the first clearing message, then the user shall abandon the CUG call operation and
continue normal clearing.
The possibility of "simultaneous" failure for a CUG supplementary service related reason and a reason
unrelated to the CUG supplementary service is not precluded. In this case, if the cUGCall return error
component can be sent, it shall contain an indication as defined by tables 5 and 6 (including notes), but the
cause shall be determined by the event not related to the CUG supplementary service which caused the
call failure.
9.2.2 Call originating from a user with the CUG supplementary service (default request)
9.2.2.1 Normal operation
If the calling user does not include in the outgoing SETUP message a Facility information element
containing a cUGCall invoke component, the network shall perform internal checks appropriate to the
originating network based on the closed user group attributes of the calling user. The outcomes of these
checks are defined in table 5 (including notes). If no Calling party number information element is included
by the calling user in the SETUP message, the default number stored in the originating network shall be
used for the assignment of the closed user group.
NOTE: the network may respond to the SETUP message with a SETUP ACKNOWLEDGE or
CALL PROCEEDING message or the call may be cleared for some reason unrelated
to the CUG supplementary service before the checks are completed.
If the result of the checks relevant to the originating network allows the call to proceed then the destination
network shall perform further internal checks based on the closed user group attributes (if any) of the
called user. The outcomes of these checks are defined in table 6 (including notes).
If the call is successfully offered to the called user then basic call control procedures shall apply at the
calling user's interface.
9.2.2.2 Exceptional procedures
If, as a result of the checks relevant to either the originating or destination network, the network cannot
allow the call to proceed for a CUG supplementary service related reason, then the network shall initiate
call clearing using one of the following causes:
- #87 "user not a member of CUG" if the corresponding cUGCall return error component
value would have been "userNotMemberOfCUG" using the explicit request procedures;
- #29 "facility rejected" in the case of all other CUG supplementary service related
reasons.
When a call fails for a reason unrelated to the CUG supplementary service then no CUG supplementary
service related procedures shall apply.
Page 15
ETS 300 138-1: May 1992
9.2.3 Call originating from a user without the CUG supplementary service
9.2.3.1 Normal operation
A user without the CUG supplementary service can make a call to a user with the CUG supplementary
service. If such a calling user does not include in the outgoing SETUP message a Facility information
element containing a cUGCall invoke component, then table 5 (including notes) shall apply.
The destination network shall then perform further internal checks based on the closed user group
attributes (if any) of the called user. The outcomes of these checks are defined in table 6 (including notes).
9.2.3.2 Exceptional procedures
If the calling user includes in the outgoing SETUP message a Facility information element containing a
cUGCall invoke component and if the network can recognise this cUGCall invoke component, then the
network shall fail the call and initiate clearing with cause #50 "requested facility not subscribed". The
network shall include in the first clearing message returned to the calling user a Facility information element
containing a cUGCall return error component with the appropriate indication as defined by table 5 (including
notes), i.e. "notSubscribed".
If the calling user includes in the outgoing SETUP message a Facility information element containing a
cUGCall invoke component but the network cannot recognise this supplementary service request, then the
procedures defined in subclause 8.4 of ETS 300 196-1 [12] shall apply.
If the calling user does not include in the outgoing SETUP message a Facility information element
containing a cUGCall invoke component and the call fails as a result of the checks relevant to the
destination network, then the network shall fail the call attempt and initiate clearing with cause #87 "user
not a member of CUG". No other CUG supplementary service related indication shall be conveyed to the
calling user.
If the call attempt fails for a reason unrelated to the CUG supplementary service, then no CUG
supplementary service related procedures shall apply.
9.2.4 Call terminating at a user with the CUG supplementary service
9.2.4.1 Normal operation
If the internal checks defined in table 6 (including notes) result in a requirement for a CUG call to the called
user, then the incoming SETUP message shall include a Facility information element containing a cUGCall
invoke component to convey the necessary CUG call information (as defined by table 6).
The network shall then expect either:
a) an ALERTING or CONNECT message according to basic call control received from a
connection endpoint identifier if the call is successfully offered in the user's domain
represented by that connection endpoint identifier; or
b) a cUGCall return error component in a Facility information element in the first clearing
message received from a connection endpoint identifier (before the alerting phase) if
the call is failed by the terminal equipment represented by that connection endpoint
identifier. The network shall continue clearing that connection endpoint identifier.
Page 16
ETS 300 138-1: May 1992
If the network knows that a point to point configuration exists then the error value shall
be relayed by the network to the originating network and an appropriate indication
(depending on the calling user's CUG supplementary service invocation being explicit or
default) shall be delivered in the first clearing message to the calling user.
In case of a SETUP message sent via the broadcast datalink, the network may, as a
network option, retain the return error component along with the ETS 300 102-1 cause
retained according to subclause 5.2.5.3. of ETS 300 102-1 [10]. If there are multiple
clearing messages containing return error components, the indication in the return error
component contained in the first clearing message will be sent back to the calling user.
If there are multiple clearing messages containing return error components, the
indication in the return error component contained in the clearing message with the
highest priority will be sent back to the calling user. In addition to the basic call
procedures defined in ETS 300 102-1 [10], when a user receives a SETUP message
with a Facility information element containing a cUGCall invoke component and the user
can recognise CUG call invocation procedures, the user may:
1) initiate appropriate user domain closed user group procedures and, if the call
fails for CUG supplementary service related reasons, may include in the first
clearing message returned to the network (before the alerting phase) a Facility
information element containing a cUGCall return error component; or
2) include in the first clearing message returned to the network (before the alerting
phase) a Facility information element containing a cUGCall return error
component with value "inconsistencyInDesignatedFacilityAndSubscriberClass" if
the call fails for a reason unrelated to the CUG supplementary service.
9.2.4.2 Exceptional procedures
If the cUGCall return error component is absent in the first clearing message received from a connection
endpoint identifier the destination network shall continue clearing that connection endpoint identifier for
reasons unrelated to the CUG supplementary service. In addition, if the destination network knows that a
point-to-point configuration exists it shall abandon the CUG call operation and initiate normal call clearing
towards the calling user including, if appropriate, a cUGCall return error component indicating
"inconsistencyInDesignatedFacilityAndSubscriberClass".
If no cUGCall return error component is received by the destination network during an unsuccessful call
offering process, then the destination network shall abandon the CUG call operation and initiate call
clearing towards the calling user with the appropriate cause derived from basic call control (e.g. cause #18
"no user responding", or the highest priority cause saved) including, if appropriate, a cUGCall return error
component indicating "inconsistencyInDesignatedFacilityAndSubscriberClass".
When a user receives a SETUP message with a Facility information element containing a cUGCall invoke
component and the user cannot recognise this supplementary service request, then the procedures defined
in subclause 8.4 of ETS 300 196-1 [12] shall apply.
9.2.5 CUG checks at the originating and destination network
Table 5 shall be used to determine the type of call request sent to the destination network or rejection
indication returned to the calling user.
Page 17
ETS 300 138-1: May 1992
Table 5: Closed user group checks at the originating network
�˜˜˜˜˜˜˜˜˜˜˜˜˜´˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜¿
‡CUG ‡ CUG information received from calling user in SETUP ‡
‡attributes ofˆ˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜´˜˜˜˜˜˜˜˜˜˜˜·
‡calling user ‡ CUG Call Invoke received ‡no CUG Call‡
‡for requestedˆ˜˜˜˜˜˜˜˜˜˜˜´˜˜˜˜˜˜˜˜˜˜˜´˜˜˜˜˜˜˜˜˜˜˜´˜˜˜˜˜˜˜˜˜˜˜·Invoke ‡
‡basic service‡OA not req.‡OA req. ‡OA not req.‡OA req. ‡received ‡
‡ ‡CUG index ‡CUG index ‡no CUG ind.‡no CUG ind.‡ ‡
ˆ˜˜˜˜˜˜˜˜˜´˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜·
‡No Pref. ‡not‡CUG call ‡CUG call ‡ ‡ ‡ ‡
‡CUG ‡ocb‡IC=spec CUG‡IC=spec CUG‡ ‡ ‡ ‡
‡OA ‡ ‡ (*1)‡ (*1)‡rejected ‡rejected ‡rejected ‡
‡not ˆ˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜·RE value= e‡RE value= e‡no RE ‡
‡allowed ‡ ‡rejected ‡rejected ‡ (*4)‡ (*4)‡ (*4)‡
‡ ‡ocb‡RE value= d‡RE value= d‡ ‡ ‡ ‡
ˆ˜˜˜˜˜˜˜˜˜¯˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜·
‡No Pref. ‡not‡CUG call ‡CUG call ‡ ‡ ‡ ‡
‡CUG ‡ocb‡IC=spec CUG‡IC=spec CUG‡ ‡ ‡ ‡
‡OA ‡ ‡ (*1)‡ (*1)‡normal ‡normal ‡normal ‡
‡allowed ˆ˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜·call ‡call ‡call ‡
‡ ‡ ‡rejected ‡rejected ‡ (*4)‡ (*4)‡ (*4)‡
‡ ‡ocb‡RE value= d‡RE value= d‡ ‡ ‡ ‡
ˆ˜˜˜˜˜˜˜˜˜¯˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜·
‡Pref. CUG‡not‡CUG call ‡CUG call ‡CUG call ‡ ‡CUG call ‡
‡nominated‡ocb‡IC=spec CUG‡IC=spec CUG‡IC=pref CUG‡ ‡IC=pref CUG‡
‡OA ‡ ‡ (*2)‡ (*2)‡ ‡rejected ‡ ‡
‡not ˆ˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜·RE value= aˆ˜˜˜˜˜˜˜˜˜˜˜·
‡allowed ‡ ‡rej. (*3)‡rej. (*3)‡rej. (*5)‡ ‡rej. ‡
‡ ‡ocb‡RE value= d‡RE value= d‡RE value= d‡ ‡no RE (*5)‡
ˆ˜˜˜˜˜˜˜˜˜¯˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜·
‡Pref. CUG‡not‡CUG call ‡CUG call ‡CUG call ‡ ‡CUG call ‡
‡nominated‡ocb‡IC=spec CUG‡IC=spec CUG‡IC=pref CUG‡ ‡IC=pref CUG‡
‡OA ‡ ‡ (*2)‡ (*2)‡ ‡normal ‡ ‡
‡allowed ˆ˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜·call ˆ˜˜˜˜˜˜˜˜˜˜˜·
‡ ‡ ‡rej. (*3)‡rej. (*3)‡rej. (*5)‡ ‡rej. ‡
‡ ‡ocb‡RE value= d‡RE value= d‡RE value= d‡ ‡no RE (*5)‡
ˆ˜˜˜˜˜˜˜˜˜`˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜¯˜˜˜˜˜˜˜˜˜˜˜·
‡not a CUG ‡rejected ‡rejected ‡rejected ‡rejected ‡normal ‡
‡user ‡RE value= a‡RE value= a‡RE value= a‡RE value= a‡call (*6)‡
�˜˜˜˜˜˜˜˜˜˜˜˜˜`˜˜˜˜˜˜˜˜˜˜˜`˜˜˜˜˜˜˜˜˜˜˜`˜˜˜˜˜˜˜˜˜˜˜`˜˜˜˜˜˜˜˜˜˜˜`˜˜˜˜˜˜˜˜˜˜˜�
NOTE: The type of call request derived from this table shall determine the linkage to table 6.
NOTES to table 5:
IC: CUG interlock code.
RE: cUGCall return error component.
RE value a: "notSubscribed".
RE value b: "invalidOrUnregisteredCUGIndex".
RE value c: "requestedBasicServiceViolatesCUGConstraints".
RE value d: "outgoingCallsBarredWithinCUG".
RE value e: "inconsistencyInDesignatedFacilityAndSubscriberClass".
*1: assumes match between CUG index and IC exists for the requested basic service. If
no match exists then:
- if the CUG index exists but is not appropriate to the requested basic service the
call shall be rejected with RE value=c. This includes the case when the
requested basic service is not included in any closed user group;
- if the CUG index does not exist the call shall be rejected with RE value=b.
Page 18
ETS 300 138-1: May 1992
*2: assumes match between CUG index and IC exists for the requested basic service. If
no match exists then:
- if the CUG index exists but is not appropriate to the requested basic service the
call shall be rejected with RE value=c;
- if the CUG index does not exist the call shall be rejected with RE value=b.
*3: if the CUG index identifies the preferential CUG then this combination of CUG attribute
values is not recommended.
*4: this includes the case when the requested basic service is not included in any CUG.
*5: this combination of CUG attribute values is not recommended.
*6: this represents the normal case of a user without the CUG supplementary service
making a normal call.
Table 6 shall be used to determine the type of call request sent to the destination user or the type of
rejection indication returned to the calling user.
Table 6: Closed user group checks at the destination network
�˜˜˜˜˜˜˜˜´˜˜´˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜´˜˜˜˜˜˜˜˜¿
‡Type of ‡ ‡
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...