ETSI ETR 186-2 ed.1 (1998-05)
Intelligent Network (IN); Interaction between IN Application Protocol (INAP) and Integrated Services Digital Network (ISDN) signalling protocols; Part 2: Switching signalling requirements for IN Capability Set 2 (CS2) service support in a Narrowband ISDN (N-ISDN) environment
Intelligent Network (IN); Interaction between IN Application Protocol (INAP) and Integrated Services Digital Network (ISDN) signalling protocols; Part 2: Switching signalling requirements for IN Capability Set 2 (CS2) service support in a Narrowband ISDN (N-ISDN) environment
DTR/SPS-03011-2
Inteligentno omrežje (IN) - Medsebojno vplivanje med aplikacijskim protokolom inteligentnega omrežja (INAP) in signalizacijskimi protokoli digitalnega omrežja z integriranimi storitvami (ISDN) - 2. del: Komutacijske signalizacijske zahteve za podporo storitvam nabora zmožnosti 2 (CS2) inteligentnega omrežja (IN) v okolju ozkopasovnega digitalnega omrežja z integriranimi storitvami (N-ISDN)
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-april-2005
Inteligentno omrežje (IN) - Medsebojno vplivanje med aplikacijskim protokolom
inteligentnega omrežja (INAP) in signalizacijskimi protokoli digitalnega omrežja z
integriranimi storitvami (ISDN) - 2. del: Komutacijske signalizacijske zahteve za
podporo storitvam nabora zmožnosti 2 (CS2) inteligentnega omrežja (IN) v okolju
ozkopasovnega digitalnega omrežja z integriranimi storitvami (N-ISDN)
Intelligent Network (IN); Interaction between IN Application Protocol (INAP) and
Integrated Services Digital Network (ISDN) signalling protocols; Part 2: Switching
signalling requirements for IN Capability Set 2 (CS2) service support in a Narrowband
ISDN (N-ISDN) environment
Ta slovenski standard je istoveten z: ETR 186-2 Edition 1
ICS:
33.040.35 Telefonska omrežja Telephone networks
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.
ETSI ETR 186-2
TECHNICAL May 1998
REPORT
Source: SPS Reference: DTR/SPS-03011-2
ICS: 33.020
Key words: IN, ISDN, CS2, interaction, signalling
Intelligent Network (IN);
Interaction between IN Application Protocol (INAP) and
Integrated Services Digital Network (ISDN) signalling protocols;
Part 2: Switching signalling requirements for
IN Capability Set 2 (CS2) service support in a
Narrowband ISDN (N-ISDN) environment
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
Internet: secretariat@etsi.fr - http://www.etsi.fr - http://www.etsi.org
Tel.: +33 4 92 94 42 00 - Fax: +33 4 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 1998. All rights reserved.
Page 2
ETR 186-2: May 1998
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
ETR 186-2: May 1998
Contents
Foreword .5
1 Scope .7
2 References.7
3 Abbreviations and definition .8
3.1 Abbreviations .8
3.2 Definition.9
4 General.9
5 Communication between an ISDN end-user and IN service logic .9
5.1 Signalling configurations.10
5.2 Terminal types .13
5.2.1 Existing terminals .13
5.2.2 Future terminals .14
5.3 Access signalling types.14
5.4 USI signalling requirements.14
5.4.1 IN service and IN service features applicable for user to service
communication .14
5.4.1.1 Call related features.14
5.4.1.2 Call unrelated features.15
5.4.2 Signalling requirements to support an user to service communication
mechanism.16
5.4.2.1 Requirements for a call-related (bearer- related) transport
mechanism .16
5.4.2.2 Requirements for a call-unrelated (bearer-unrelated)
transport mechanism.17
5.4.3 Enhanced Call Unrelated Service Function (CUSF)-SCF operation set of
CS2 core INAP .18
6 Support of mid-call events.19
6.1 Signalling requirements .19
7 Interworking between IN services/features and ISDN supplementary services.21
7.1 Interworking with CCBS/CCNR.21
7.2 Limitations in case of follow-on.21
7.3 COnnected Line idendification Restriction (COLR) support for called IN number.21
7.4 UID capability / UID action indicators.22
8 Support of service/feature interaction handling IN-based to IN-based.23
8.1 Transport of service compatibility indicator.23
9 Signalling requirements from CTM.23
10 Transport of display information.23
11 Transport of called IN number.24
12 Signalling requirements from CPH.24
13 IN support of GVNS configuration #3.25
14 Support of calling user number .26
14.1 Introduction of calling user number in INAP and ISUP .26
Page 4
ETR 186-2: May 1998
14.2 Presentation of the calling party number to the called user . 26
15 Support of DP: Not_Reachable . 26
Annex A (informative): Functional structure of the USI information element . 28
Annex B (informative): Parameters mapping . 29
Annex C (informative): Content and structure of the IN CS2 core INAP parameters. 40
C.1 Content of the "ServiceInteractionIndicators" parameter . 40
C.2 Content of the "INServiceCompatibilityIndication" parameter . 41
Annex D (informative): Proposal for mid-call processing. 42
D.1 Coding proposal for IE to request/withdrawal of the specific midcall events. 42
D.2 Coding proposal for IE to transfer the detected midcall information . 42
Annex E (informative): Message sequence charts for GVNS calls . 44
E.1 GVNS: Outgoing call . 44
E.2 GVNS: Incoming call . 45
History. 46
Page 5
ETR 186-2: May 1998
Foreword
This ETSI Technical Report (ETR) has been produced by the Signalling Protocols and Switching (SPS),
Technical Committee of the European Telecommunications Standards Institute (ETSI).
ETRs are informative documents resulting from ETSI studies which are not appropriate for European
Telecommunication Standard (ETS) or Interim European Telecommunication Standard (I-ETS) status. An
ETR may be used to publish material which is either of an informative nature, relating to the use or the
application of ETSs or I-ETSs, or which is immature and not yet suitable for formal adoption as an ETS or
an I-ETS.
This ETR is part 2 of a multi-part ETR covering the interactions between the Intelligent Network
Application Protocol (INAP) and Integrated Services Digital Network (ISDN) signalling protocols as
described below:
Part 1: "Switching signalling requirements for IN Capability Set 1 (CS1) service support in a
Narrowband ISDN (N-ISDN) environment";
Part 2: "Switching signalling requirements for IN Capability Set 2 (CS2) service support in a
Narrowband ISDN (N-ISDN) environment".
NOTE: Additional parts may cover further development in the IN area.
The standardization works in the fields of ISDN and IN have progressed as parallel, independent activities.
Hence no consideration has been given to the provision of IN based services in an ISDN environment.
The present document seeks to give guidance and clarification to the signalling requirements needed to
fully support IN Capability Set 2 (CS2) services in a Narrowband ISDN (N-ISDN) environment.
Page 6
ETR 186-2: May 1998
Blank page
Page 7
ETR 186-2: May 1998
1 Scope
This second part of ETR 186 specifies the signalling requirements for the interaction between Intelligent
Network (IN) Capability Set 2 (CS2) services and ISUP/DSS1 switched based services in an N-ISDN
environment. It is based on the capabilities supported by the ETSI core Intelligent Network Application
Protocol (INAP) for CS2, EN 301 140-1 [2].
The aspects of private networks in this are limited to show the indirect ISDN TE access to the public
network. In particular the aspect where the private network has access to the SCF of an IN-structured
network via an Intelligent Access Function (IAF) is out of scope of this ETR.
2 References
For the purposes of the present document, the following references apply:
[1] ETS 300 710: "Integrated Services Digital Network (ISDN); Public Switched
Telephone Network (PSTN); Universal Access Number (UAN) service; Service
description".
[2] EN 301 140-1: "Intelligent Network (IN); Intelligent Network Application Protocol
(INAP); Capability Set 2 (CS2); Part 1: Protocol specification".
[3] EN 301 144-1: "Integrated Services Digital Network (ISDN); Digital Subscriber
Signalling System No. one (DSS1) and Signalling System No.7 protocols;
Signalling application for the mobility management service on the alpha
interface; Part 1: Protocol Specification".
[4] ETS 300 779: "Network Aspects (NA); Universal Personal Telecommunication
(UPT); Phase 1; Service description".
[5] EN 301 175: "Cordless Terminal Mobility (CTM); Phase 1; Service Description".
[6] EN 301 070-1: "Integrated Services Digital Network (ISDN); Signalling System
No.7; ISDN User Part (ISUP) version 3 interactions with the Intelligent Network
Application Part (INAP); Part 1: Protocol specification [ITU-T Recommendation
Q.1600 (1997), modified]".
[7] ETR 164: "Integrated Services Digital Network (ISDN); Intelligent Network (IN);
Interaction between IN Application Protocol (INAP) and ISDN User Part (ISUP)
version 2".
[8] ETS 300 374-1 (1994): "Intelligent Network (IN); Intelligent Network Capability
Set 1 (CS1); Core Intelligent Network Application Protocol (INAP); Part 1:
Protocol specification".
[9] ETS 300 710: "Integrated Services Digital Network (ISDN); Public Switched
Telephone Network (PSTN); Universal Access Number (UAN) service; Service
description".
[10] ETS 300 712: "Integrated Services Digital Network (ISDN); Public Switched
Telephone Network (PSTN); Premium Rate (PRM) service; Service description".
[11] ETS 300 779: "Network Aspects (NA); Universal Personal Telecommunication
(UPT); Phase 1 - Service description".
[12] ETS 300 823: "Universal Personal Telecommunication (UPT); UPT phase 2;
Functional specification of the interface of a UPT Integrated Circuit Card (ICC)
and Public Switched Telephone Network (PSTN), Integrated Services Digital
Network (ISDN) and Global System for Mobile communications (GSM) terminals
(one pass and multiple pass authentication)".
[13] ITU-T Recommendation I.112 (1988): "Vocabulary of terms for ISDNs".
Page 8
ETR 186-2: May 1998
[14] ITU-T Recommendation Q.735: "Stage 3 description for community of interest
supplementary services using Signalling System No. 7".
[15] ITU-T Recommendation Q.763: "Signalling System No. 7 – ISDN User Part
formats and codes".
[16] ITU-T Recommendation Q.1224 (1997): "Distributed Functional Plane for IN
CS2".
[17] ITU-T Recommendation Q.1228: "Interface Recommendation for Intelligent
Network Capability Set 2".
[18] ITU-T Recommendation Q.1290 (1994): "Glossary of terms used in the
definition of Intelligent Networks".
[19] EG 201 096-1: "Intelligent Network (IN); Cordless Terminal Mobility (CTM); IN
architecture and functionality for the support of CTM; Part 1: CTM phase 1 for
single public network case".
3 Abbreviations and definition
3.1 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ANM Answer Message (ISUP message)
ASE Application Service Element
BCSM Basic Call State Model
BCUSM Basic Call Unrelated State Model
BRI Basic Rate Interface
CCBS Completion of Calls to Busy Subscriber
CCC Charge Card Calling
CCF Call Control Function
CCNR Completion of Calls on No Reply
CD Call Distribution
CdINNo Called IN number
CLIP Calling Line Identification Presentation
CLIR Calling Line Identification Restriction
COLR COnnected Line idendification Restriction
CPH Call Party Handling
CS1 IN Capability Set 1
CS2 IN Capability Set 2
CTM Cordless Terminal Mobility
CUG Closed User Group
CUSF Call Unrelated Service Function
CURUI Call Unrelated User Interaction
DP Detection Point
DTMF Dual Tone Multi-Frequency
DSS1 Digital Subscriber Signalling System No. one
EDP Event Detection Points
FT Fixed Termination
GUG GVNS User Group
GVNS Global Virtual Network Service
HLR Home Location Register
IAF Intelligent Access Function
IN Intelligent Network
INAP Intelligent Network Application Protocol
IP Intelligent Peripheral
ISDN Integrated Services Digital Network
ISUP ISDN User Part
LE Local Exchange
MCID Malicious Call Identification
MSC Mobile Switching Centre
Page 9
ETR 186-2: May 1998
NNI Node to Node Interface
OCCRUI Out Channel Call Related User Interaction
OPSP Originating Participating Service Provider
PIN Personal Identification Number
PINX Private Integrated Network Exchange
PRI Premary Rate Interface
PRM Premium Rate
PSTN Public Switched Telephone Network
PUI Personal User Identity
QUE Queuing
REL Release Message (ISUP message)
ROSE Remote Operations Service Element
SCF Service Control Function
SCP Service Control Point
SRF Specialized Resource Function
SSF Service Switching Function
SSP Service Switching Point
SUI Service to User Information.
TDP Trigger Detection Points
TE Terminal Equipment
TNRN Terminating Network Routing Number
UAN Universal Access Number
UPT Universal Personal Telecommunication
UNI User to Network Interface
USBS User Signalling Bearer Service
USI User to Service Information
VLR Visited Location Register
3.2 Definition
For the purposes of the present document, terminology is defined in ITU-T Recommendation I.112 [13]
and ITU-T Recommendation Q.1290 [18].
4 General
The signalling requirements specified in the present document are related to the following subjects:
- communication between an Integrated Services Digital Network (ISDN) end-user and an Intelligent
Network (IN) service;
- support of mid-call events;
- interworking with ISDN supplementary services;
- support of service/feature interaction handling IN-based to IN-based;
- requirements from Cordless Terminal Mobility (CTM);
- transport of display information;
- transport of called IN number;
- requirements from Call Party Handling (CPH);
- support of Global Virtual Network Service (GVNS) configuration #3;
- support of calling user number;
- support of Detection Point (DP): Not_Reachable.
5 Communication between an ISDN end-user and IN service logic
The execution of an IN service or an IN service feature may require a communication between an ISDN
end-user and the IN service logic. This communication may include transfer of information from the
terminal of an ISDN end-user to the service logic as well as the provision of information to the ISDN
end-user.
It is, as a general mechanism in the IN architecture, possible to send tones and announcements to an
end-user and to receive additional information in-band, using Dual Tone Multi-Frequency (DTMF)
signalling or speech, from an end-user. This user interaction phase is usually provided by an Intelligent
Peripheral (IP). The user interaction phase with an IP is controlled by the IN service logic. The functional
entity in the IP is named Specialized Resource Function (SRF) which is controlled by the Service Control
Page 10
ETR 186-2: May 1998
Function (SCF). In-band collected information is transferred via the Intelligent Network Application
Protocol (INAP) to the SCF.
IN Capability Set 1 (CS1) only supports in-band user interaction as described above. With
IN Capability Set 2 (CS2) it will be possible to support a User to Service Information (USI) communication
mechanism by using the out-of-band signalling capabilities supported in the ISDN. This mechanism will
provide an information transport between end-user and IN service logic which is transparent in the ISDN
network. The user terminal (ISDN Terminal Equipment (TE)) and the IN service logic run an end-to-end
application protocol on top of the basic network transport mechanism. This end-to-end application protocol
is service feature specific. For example, remote operation procedures Remote Operations Service
Element (ROSE) may be used.
5.1 Signalling configurations
The interaction with an ISDN user should not put any requirements on the network architecture; e.g. it
should not be a requirement to equip the local exchanges with Service Switching Function (SSF) or SRF.
As a consequence the signalling needs to support the following possible configurations for the access of
an ISDN TE to the IN entities in the network:
- Case A: The ISDN TE is connected direct to a local exchange with an SSF;
- Case B: The ISDN TE is connected to a local exchange without an SSF;
- Case C: The ISDN TE is connected to a private network (indirect TE access to the public network);
- Case D: The ISDN TE is within a VPN.
In case A only the Digital Subscriber Signalling System No. one (DSS1) protocol may be affected by the
requirements to support a USI communication. In case B the ISDN User Part (ISUP) may also be
affected.
In case C the SSF functionality may also be located at the local exchange (as case A).
Case D is just an example signalling configuration for VPN; there are other possible permutations for the
allocation of VPN functionality but these options are not discussed here.
As an example, figures 1a and 1b illustrate these signalling configurations for one of the SRF connect
physical scenarios described in ETS 300 374-1 [8], subclause 7.3.5.1.1, case i) in figure 25.
Page 11
ETR 186-2: May 1998
TE
S/T
Reference
Point
TE
S/T
Reference
Point
Figure 1a: Signalling configurations, Cases A and B
Page 12
ETR 186-2: May 1998
Case C:
Private Network Public Network
SCP
SCF
Private SSP
Access
Netw ork
Network
Signalling
Signalling
IP
Signalling
SSF
SRF
PINX PINX LE
CCF
Transport Transport Transport T ransport
ISDN
Integrated SRF Non-Integrated SRF
Terminal
IN
S T
Reference Point Reference Point
Case D:
VPN
Public Network
SCF SCP
SSP
Access Network
Access
Signalling IP Signalling
Signalling
SSF
SRF
LE
CCF
Transport Transport Transport
Integrated SRF Non-Integrated SRF
ISDN
Terminal
IN
Virtual Virtual Transit
Originating Transit PINX
PINX PINX
T
S/T
Reference Point
Reference Point
Figure 1b: Signalling configurations, Cases C and D
Page 13
ETR 186-2: May 1998
5.2 Terminal types
Different ISDN terminal types have to be supported. The terminal type may vary from service to service,
i.e. any particular terminal may support any or all of the following categories over a set of services:
a) Terminals supporting generic keypad protocol;
b) Legacy terminals supporting fixed service logic using the generic functional protocol;
c) Future terminals supporting a service independent generic functional protocol.
5.2.1 Existing terminals
ISDN terminals are already in the market place, and the services they use need to continue to be
supported, whether the network operator chooses to support them in an IN environment or in a fixed
implementation environment. These terminals support a number of generic protocols, which may be used
in the support of any supplementary service. These generic protocols are defined either as stimulus or
functional. They support different kinds of supplementary services, according to the following definitions:
-A stimulus supplementary service is one where the end terminal does not have knowledge of the
service being required. All protocol is transported to/from the human user with only service
independent control of the presentation/coding. No service logic is present within the terminal
implementation. Any service logic required to support the human user is provided in the network on
behalf of the terminal. In an IN environment, this service logic will reside in the SCF with the SRF
providing the user interaction under the control of the SCF. Two mechanisms of stimulus access
are provided, the generic keypad protocol and the feature key protocol.
NOTE 1: The feature key protocol, which is another stimulus protocol, is not supported in ETSI
standards.
-A functional supplementary service is one where the peer entity has knowledge of the service being
provided. The terminal therefore provides service logic in order to support that supplementary
service. As a result, where the peer entity is a terminal equipment, a more intelligent man-machine
interface can be provided.
NOTE 2: The functional protocol is also the only protocol that is applicable at the T reference
point to support private ISDN exchanges and networks. The procedures used at the T
reference point are defined in the individual supplementary service specifications, and
can be either identical to those for the coincident S and T reference point (supporting
an ISDN terminal) or may be entirely different, dependent on the required functionality
of the service.
The generic protocols to be supported in an IN environment are as follows:
- Generic keypad protocol - this is a stimulus protocol which provides for the transfer of keypad
facility information elements in the user to network direction, representing primarily numeric values
of a keypad being keyed by the human user. In the network to user direction, the protocol provides
for the transfer of display information elements, signal information elements and tones and
announcements in the bearer channel. The keypad protocol has affinity with the way that
supplementary services are provided in the Public Switched Telephone Network (PSTN), and
network operators may require a consistent service offering between PSTN services and ISDN
keypad protocol support services.
- Generic functional protocol - this is a functional protocol consisting of a number of procedures for
control of access resources, suspend and resume, resource reservation and common information
elements (the various transport mechanisms).
Unless indicated otherwise, the requirements defined in this document apply to both stimulus and
functional based terminals.
Page 14
ETR 186-2: May 1998
5.2.2 Future terminals
From a terminal perspective, future mechanisms should be an evolution of the existing supplementary
service mechanisms. For example, the keypad protocol, provides a means of supporting services using a
terminal that is service independent. Therefore the existing legacy terminals supporting the keypad
protocol can continue to support new services (in an IN environment or fixed implementation environment)
as and when such new services are designed.
Unlike the keypad protocol, the generic functional protocol is service specific. The IN environment will be
used to create services that are not standardized, and this should be matched by a terminal where all
signalling information is also service independent. Therefore in an IN environment an enhanced generic
functional protocol is required, where service dependence will only exist in the user application within the
terminal.
5.3 Access signalling types
This clause discusses the signalling types applicable for communication between an ISDN end user and
IN service logic in the context of the terminal types identified in the previous subclause.
The communication between an ISDN end-user and the IN service logic in the network is not necessarily
related to the establishment of a call/bearer. Two signalling types are to be distinguished:
a) Call related signalling (bearer related): The signalling procedure is tied to the procedures for basic
call control and tied to a bearer connection in progress, active or in the clearing phase. The
respective IN CS2 network aspect is named Out Channel Call Related User Interaction (OCCRUI);
b) Call unrelated signalling (bearer unrelated): The signalling procedure is independent of a bearer
connection. The respective IN CS2 network aspect is named Call Unrelated User Interaction
(CURUI).
Both signalling types a) and b) are to be supported for the USI mechanism.
5.4 USI signalling requirements
The requirements defined in this subclause is only applicable for functional terminals, since the USI
communication mechanism requires a functional protocol. According to subclause 5.2, USI requires future
terminals with an enhanced generic functional protocol.
5.4.1 IN service and IN service features applicable for user to service communication
This subclause provides a non-exhaustive list of IN services and IN service features that require
communication between an end-user and the IN service logic and which are applicable for USI
communication.
5.4.1.1 Call related features
The following example features require an exchange of information between the end-user and the IN
service logic which are associated with an IN call:
- Terminal authentication
For the CTM service EN 301 175 [5] updating and terminal authentication may occur while the CTM
user is involved in an active call. In this case the Fixed Termination (FT) and the cordless terminal
are temporarily involved in an information exchange with the CTM service logic. The information
between FT and CTM service logic should be exchanged out of band (refer to EG 201 096-1 [19]).
NOTE: The USI mechanism builds the general transport mechanism for the mobility
management operations between FT and SCFmm/SCFsl, i.e. via the DSS1
alpha-interface EN 301 144-1 [3] and INAP.
Page 15
ETR 186-2: May 1998
- Identification
Some IN services require the identification of the service user, e.g. via Personal User Identity (PUI)
for Universal Personal Telecommunication (UPT) service ETS 300 779 [4] or card number for
Charge Card Calling (CCC) service. The identification information is usually collected, during user
interaction phase, by the IN service logic. Based on an application residing in the terminal, the
terminal itself may control the collection of the PUI and send the information to the IN service logic.
- Authentication
Some IN services require the authentication of the service user, e.g. via Personal Identification
Number (PIN) for UPT phase 2 service or the CCC service. The authentication information is
usually collected, during user interaction phase, by the IN service logic. Based on an application
residing in the terminal, the terminal itself may control the collection of the PIN and send the
information to the IN service logic.
- Support of UPT smart card
Support of UPT smart card is required, i.e. call related transport of respective information (e.g. an
authentication request and response) is required between terminal and network (refer to
ETS 300 823 [12]).
Using the USI communication mechanism would allow the inclusion of identification or authentication
information in the call setup messages. When the Service Switching Point (SSP) triggers the IN service,
the identification/authentication information would be included by the SSP in the first query sent to the IN
service logic. This would facilitate or even avoid an user interaction phase between an end-user and an IP
during service logic processing.
- Provision of information to the user
A mechanism should be provided to allow transport of any information from the service logic to the
end user as an uni-directional information transport. This may be provided by the USI
communication mechanism. The treatment of this information in the ISDN TE depends on the
service application protocol, e.g. information may be displayed.
In addition, functional operation may be completed by stimulus operation, e.g. display information
(see clause 10).
5.4.1.2 Call unrelated features
The following example features require an exchange of information between the end-user and the IN
service logic which are not associated with an established IN call:
- Terminal location registration and authentication
The CTM service EN 301 175 [5] may require the terminal location registration information updating
and the terminal authentication while the CTM user or rather the cordless terminal is roaming
without being involved in an active call (refer to EG 201 096-1 [19]). The location registration
procedure is used whenever the cordless terminal roams in a new FT or when it registers without a
previous registration. The respective information should be exchanged between FT and CTM
service logic via a call unrelated user interaction.
NOTE 1: The CTM user is not aware of the terminal location updating procedure since it is
controlled by the logic that resides in the CTM terminal.
NOTE 2: The USI mechanism builds the general transport mechanism for the mobility
management operations between FT and SCFmm/SCFsl, i.e. via the DSS1
alpha-interface EN 301 144-1 [3] and INAP.
- UPT outgoing call registration
Outgoing call registration is a core feature of UPT phase 2. The procedure provides that the
terminal for which an UPT user has registered "becomes his own", i.e. UPT user is allowed to make
outgoing calls from the registered terminal without any additional authentication. It shall be possible
to perform the outgoing call registration independent from a call, i.e. call unrelated user interaction
between the UPT user and the UPT service logic shall be possible (e.g. transport of the respective
information for identification and registration). Outgoing call registration via call unrelated user
interaction is the appropriate procedure since in UPT phase 2 the use of a smartcard and a
smartcard reading terminal are considered as standard.
Page 16
ETR 186-2: May 1998
- Support of UPT smart card
Support of UPT smart card is required, i.e. call unrelated transport of respective information (e.g. an
authentication request and response) is required between terminal and network (refer to
ETS 300 823 [12]).
5.4.2 Signalling requirements to support an user to service communication mechanism
5.4.2.1 Requirements for a call-related (bearer- related) transport mechanism
A call-related (bearer-related) and a call-unrelated (bearer-unrelated) transport mechanism is required for
USI communication.
NOTE 1: The enhancements of the User to Network Interface (UNI) and Node to Node Interface
(NNI) signalling procedures should be as generic as possible. Therefore other
requirements than IN should be taken into account, e.g. for VPN new transport
capabilities are also required.
The ISDN signalling needs to support call-related (bearer-related) USI communication according to the
following requirements:
- The mechanism should provide the service independent exchange of information between
end-users, i.e. ISDN TE, and IN service logic, i.e. Service Control Point (SCP).
- The mechanism should allow transparent information transport between user and SSP in the ISDN ,
i.e. via UNI (DSS1) and NNI ISUP.
- The information elements functionally to be conveyed from the user to the service logic are named
USI and from the service logic to the user Service to User Information (SUI).
The information elements should contain an indication whether they are an USI or a SUI type, a
service indication and a transparent data container (annex A describes the functional structure of
the USI information elements). The length of the data container has to be variable.
- Bi-directional information transport is required at any time during the call, in combination with basic
call control messages and at other times, e.g. during active and alerting phases of the call.
- At the UNI (DSS1), the mechanism should be the same regardless of whether the SSP is located in
the local exchange or in a transit exchange (refer to subclause 5.1, cases A and B).
- An indication of the terminal capabilities has to be conveyed to the service logic, e.g. whether DTMF
is supported by the terminal. Since there are no means in DSS1 to inform the local exchange about
the capabilities of a connected terminal, this information needs to be administered in the local
exchange. In case the SSP is located in the transit exchange, this information shall be conveyed via
NNI (ISUP). CS2 core INAP contains a parameter "terminalType" on which this information is to be
mapped (refer to annex B).
- In the case where the SSP is located in the transit exchange, the mechanism at the NNI (ISUP)
should allow the transparent information transport from local exchange to the SSP (refer to
subclause 5.1, case B).
NOTE 2: The USI mechanism is restricted to the ISDN network equipment (e.g. ISDN TE, smart
card reading terminals) which are enhancable to support USI signalling procedures,
e.g. they have to support the appropriate service feature specific application protocol.
- Security mechanisms are required:
- In order to avoid overload in the ISDN network due to transmission of messages carrying USI
communication information, it should be possible to control the maximum rate of signalling
messages, i.e. the rate of USI signalling events can be limited at the Local Exchange (LE). In
addition the length of the data container needs to be limited to the maximum length
supported at the UNI (DSS1) or NNI (ISUP) respectively. the ISDN TE violates these
limitations, the LE should ignore the USI signalling event.
NOTE 3: It may also be applicable that USI signalling information is sent across network borders
via network to network interface (ISUP). It is for further study whether additional
security checks are required in an appropriate gateway exchange. In this case the USI
service indicator has global significance.
Page 17
ETR 186-2: May 1998
The usage of the USI mechanism by unauthorized users has to be prevented at the LE. In IN
CS2 only the case supported is where USI signalling is allowed according to access
subscription.
The LE should ignore the USI signalling event when the security check is unsuccessful.
The LE should ignore any SUI signalling event received from an ISDN TE.
For security checks the LE has to evaluate the USI/SUI indication (refer to annex A).
5.4.2.2 Requirements for a call-unrelated (bearer-unrelated) transport mechanism
The ISDN signalling shall support a call-unrelated (bearer-unrelated) USI communication according to the
following requirements:
- The mechanism should provide service independent exchange of information between end-users,
i.e. ISDN TE, and IN service logic, i.e. SCP.
- The mechanism should allow transparent information transport between user and SSP in the ISDN,
i.e. via UNI and NNI.
- The information elements functionally to be conveyed from the user to the service logic are named
USI and from the service logic to the user SUI.
The information elements should contain an indication whether it is an USI or a SUI type, a service
indication and a transparent data container (refer to annex A). The length of the data container has
to be variable.
- Bi-directional information transport via call-unrelated (bearer-unrelated), connection-oriented
signalling is required. The call-unrelated (bearer-unrelated) transport of user to service information
should be treated similarly to the call-related (bearer-related) transport in order to facilitate the
procedures. Therefore the USI and SUI information elements should be conveyed in the messages
used for a call-unrelated (bearer-unrelated) signalling connection.
NOTE 1: The enhancements of bearer-unrelated signalling messages in order to allow transport
of user to service information should be considered in the context of similar activities
for UNI and NNI, i.e. introduction of a bearer-unrelated ISDN basic call for the support
of VPN or User Signalling Bearer Service (USBS). In principle, the USI communication
should use the signalling messages of the bearer-unrelated ISDN basic call in the
same way as for the bearer-related ISDN basic call.
- At the UNI (DSS1) the mechanism should be the same regardless of whether the SSP is located in
the local exchange or in a transit exchange.
- Where the SSP is located in the transit exchange, the mechanism at the NNI (ISUP) should allow
the transparent information transport from local exchange to the SSP.
- Security mechanisms are required:
- In order to avoid overload in the ISDN due to transmission of messages carrying USI
communication information, it should be possible to control the maximum rate of signalling
messages, i.e. the rate of USI signalling events can be limited at the Local Exchanges (LEs).
In addition the length of the data container needs to be limited to the maximum length
supported at the UNI or NNI respectively. The ISDN TE violMSMO these limitations, the LE
should ignore the USI signalling event.
NOTE 2: It may also be applicable that USI signalling information is sent across network borders
via network to network interfaces. It is for further study whether additional security
checks are required in an appropriate gateway exchange. In this case the USI service
indicator has global significance.
- The usage of the USI mechanism by unauthorized users has to be prevented at the LE. In
general USI signalling is only allowed according to access subscription. The LE should ignore
the USI signalling event when the subscription check is unsuccessful.
- The LE should ignore any SUI signalling event received from an ISDN TE.
For security checks the LE has to evaluate the USI/SUI indication (refer to annex A).
Page 18
ETR 186-2: May 1998
5.4.3 Enhanced Call Unrelated Service Function (CUSF)-SCF operation set of CS2 core INAP
In order to support call-unrelated (bearer-unrelated) IN treatment, in IN CS2 a new functional entity was
introduced in the SSP, i.e. the CUSF. Therefore also a new type of INAP interface is introduced in CS2
core INAP EN 301 140-1 [2], i.e. the CUSF-SCF interface. This interface is enhanced with respect to the
CUSF-SCF interface specified in IN CS2 ITU-T Recommendation Q.1228 [17].
The CUSF-SCF interface of CS2 core INAP supports two options:
Option 1: The service Application Service Element (ASE) is located in the CUSF and the
CUSF acts as a relay function between the service ASE and the SCF. The SCF
can provide additional information for the connection processing.
The only interworking case with a switched based service which was studied in
detail in the time frame of CS2 is the interworking with Completion of Calls to
Busy Subscriber (CCBS)/Completion of Calls on No Reply (CCNR). The
CUSF-SCF interface provides the capability of triggering during the processing
of the CCBS/CCNR ASE in the SSP and to send some parameter to the IN
service logic. In the SCF to CUSF direction the IN service logic can provide new
address information to be used in the further connection establishment
controlled by the CCBS/CCNR ASE.
NOTE 1: The same IN service logic controls the bearer-related call for which the busy or no
answer event applied.
Option 2: The service ASE is located in the SCF and the CUSF acts as a relay function
between the user and the SCF. The SCF receives and may send USI
information.
The only service standardized in ETSI in the time frame of IN CS2 which will use
the USI mechanism is CTM. For CTM the mobility management ASE is located
in the SCP and in the FT. USI mechanism will be used to convey the mobility
management operations via INAP and DSS1, EN 301 144-1 [3].
NOTE 2: The options are mutually exclusive. This means, when the bearer unrelated INAP
relationship is established in order to exchange USI related information via the
CUSF-SCF interface, the CUSF contains no service ASE which interworks with IN and
no application specific parameters beside USI related parameter are exchanged via
this interface. On the other hand, whenthe CUSF contains a service ASE which
interworks with IN (e.g. a CCBS/CCNR ASE), no USI related parameters are
exchanged via this interface.
Enhanced CUSF-SCF operation set of CS2 core INAP:
Enhanced CUSF-SCF operation Direction Interworking with
set of CS2 core INAP NNI/UNI
InitialAssociationDP relevant
CUSFfiSCF
ConnectAssociation relevant
CUSF‹SCF
ContinueAssociation not relevant
CUSF‹SCF
InitiateAssociation (note 1) CUSF‹SCF relevant
ReleaseAssociation (note 1) relevant
CUSF‹SCF
RequestReportBCUSMEvent not
...
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...