EUROPEAN COMPUTER MANUFACTURERS ASSOCIATION
STANDARD ECMA-161 PRIVATE TELECOMMUNICATION NETWORKS SIGNALLING AT THE S REFERENCE POINT GENERIC FEATURE KEY MANAGEMENT PROTOCOL FOR THE CONTROL OF SUPPLEMENTARY SERVICES (PTN SSIG-FK)
2nd Edition - June 1993
EUROPEAN COMPUTER MANUFACTURERS ASSOCIATION
STANDARD ECMA-161 PRIVATE TELECOMMUNICATION NETWORKS SIGNALLING AT THE S REFERENCE POINT GENERIC FEATURE KEY MANAGEMENT PROTOCOL FOR THE CONTROL OF SUPPLEMENTARY SERVICES (PTN SSIG-FK)
2nd Edition - June 1993
Brief History
This Standard is one of a series of ECMA standards defining services and signalling protocols applicable to Private Telecommunication Networks (PTNs). The series uses the ISDN concepts as developed by the ITU-TS and is also within the framework of standards for open systems interconnection as defined by ISO. It has been produced under ETSI IMCC work item DE/ECMA-00027. This particular Standard defines the feature key management stimulus protocol for use at the S reference point in support of basic circuit mode services. The feature key management protocol for Private Telecommunication Networks (PTNs) selects options from and complements CCITT Recommendation Q.932. The differences between this Standard and the relevant section of Q.932 and the impact of these differences on terminal interchangeability can be found in annex E. This Standard is based upon the practical experience of ECMA member companies and the results of their active and continuous participation in the work of ISO/IEC JTC1, ITU-TS, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. Compared to the 1st Edition of Standard ECMA-161 (published by ECMA in December 1991), various changes have been made in order to achieve alignment with ETS 300 240 (which is based on the 1st Edition of ECMA-161 but modified during Public Enquiry and published by ETSI in June 1993).
Accepted as 2nd Edition of Standard ECMA-161 by the General Assembly of June 1993.
- i -
Table of contents Page 1
Scope
1
2
Conformance
1
3
References
1
4
Definitions
1
4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14
Access Endpoint Identifier (EID) Feature Feature indication Feature request Private Telecommunication Network (PTN) Private Telecommunication Network Exchange (PTNX) Service profile Service Profile Identifier (SPID) Supplementary Service Terminal Equipment (TE) Terminal Identifier (TID) User User Service Identifier (USID)
1 1 1 1 1 2 2 2 2 2 2 2 2 2
5
Acronyms and abbreviations
2
6
Feature Key Management Protocol
2
6.1 6.1.1 6.1.2 6.1.3 6.2 6.2.1 6.2.2 6.2.3 6.2.4 7 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11
Messages Messages used in association with a Call Reference Messages used in association with the Dummy Call Reference Additional information elements Procedures TE requests PTN responses General aspects Error conditions
3 3 3 3 4 4 5 5 6
Coding of Information Elements
6
Dummy call reference Calling party number Cause Display Endpoint identifier Feature activation Feature indication Information request Keypad facility Signal Service profile identification
6 6 6 6 6 7 8 9 10 10 10
- ii -
7.12
Switchhook
11
Annex A - User Service Profiles and Terminal Identification
13
Annex B - Information Request Procedures
17
Annex C - Illustration of the Feature Key Management Protocol
19
Annex D - Protocol Implementation Conformance Statement (PICS) Proformas
21
Annex E - Relationship to Corresponding Standards for Public ISDNs
29
1
Scope This Standard defines the Feature Key Management signalling protocol for the purpose of supplementary service control at an interface at the S reference point between a Terminal Equipment (TE) and a Private Telecommunication Network (PTN). The Feature Key Management protocol operates in conjunction with the signalling protocol specified in Standard ETS 300 192 for circuit-switched call control. It is based on the use of the two information elements, Feature activation and Feature indication. While the procedures associated with feature key invocation and indication are specified in this Standard, the allocation of actual codes used to designate individual supplementary services is outside the scope of this Standard. This Standard is applicable to the user accesses of PTNs and to TEs which are intended for connection to PTNs.
2
Conformance In order to conform to this Standard, a PTNX shall satisfy the requirements identified in the Protocol Implementation Conformance Statement (PICS) proforma in sub-clause D.3 of annex D. In order to conform to this Standard, a TE shall satisfy the requirements identified in the Protocol Implementation Conformance Statement (PICS) proforma in sub-clause D.4 of annex D.
3
References ECMA-105
Private Telecommunication Networks (PTN) - Signalling at the S Reference Point - Data Link Layer Protocol (SSIG-L2) (1993)
ETS 300 102-1
Integrated Services Digital Network (ISDN); User-network interface layer 3; Specification for basic call control; Application of CCITT Rec. Q.930/I.450 and Rec. Q.931/I.451 (1990)
ETS 300 189
Private Telecommunication Network (PTN); Addressing (1992)
ETS 300 192
Private Telecommunication Network (PTN); Signalling protocol at the S-reference point; Circuit mode basic services (1992)
CCITT Rec. I.112 Vocabulary of terms for ISDNs(1988) CCITT Rec. Q.932 Generic procedures for the control of ISDN supplementary services (1988) ENV 41007
4
Definition of terms in private telecommunication networks (1989)
Definitions For the purpose of this Standard the following definitions apply. 4.1
Access The definition of CCITT Rec. I.112 for "user-network access" shall apply, with "telecommunication network" being interpreted as "PTN".
4.2
Endpoint Identifier (EID) Information used for terminal identification. The endpoint identifier parameters contain a USID and TID and additional information used to interpret them.
4.3
Feature A supplementary service or a user-initiated PTN action which constitutes one specific part of a supplementary service.
4.4
Feature indication An indication of the status of a feature from the PTN to the user.
4.5
Feature request The initiation of a feature by the user.
-2-
4.6
Private Telecommunication Network (PTN) The definition in ENV 41007 shall apply.
4.7
Private Telecommunication Network Exchange (PTNX) The definition in ENV 41007 shall apply.
4.8
Service profile The information that the PTN maintains for a given user to characterize the service offered by the PTN to that user. As an example, this may contain the association of feature identifiers with specific supplementary services. A service profile may for example be allocated to a PTN access interface or to a particular TE or a group of TEs.
4.9
Service Profile Identifier (SPID) Identifies a specific service profile in the case that a TE asks for automatic assignment of a USID and TID by the PTN. The SPID allows the PTN to distinguish between different terminals that would otherwise be indistinguishable (e.g. same PTN number). The SPID value is provided to the user when installing a service profile and should uniquely identify that service profile.
4.10
Supplementary Service A capability provided by a PTN to a PTN user over and above that of a basic call.
4.11
Terminal Equipment (TE) The definition in ENV 41007 shall apply.
4.12
Terminal Identifier (TID) Identifies a terminal uniquely within a given USID. If two TEs on an interface have the same service profile the two TEs will be assigned the same USID. However, two different TIDs are required to uniquely identify each of the two TEs.
4.13
User The definition in ENV 41007 shall apply.
4.14
User Service Identifier (USID) Uniquely identifies a service profile on a PTN access interface.
5
Acronyms and abbreviations CEI CES EID ISDN PICS PTN PTNX SAPI SPID TE TEI TID USID
6
Connection Endpoint Identifier Connection Endpoint Suffix Endpoint Identifier Integrated Services Digital Network Protocol Implementation Conformance Statement Private Telecommunication Network Private Telecommunication Network Exchange Service Access Point Identifier Service Profile Identifier Terminal Equipment Terminal Endpoint Identifier Terminal Identifier User Service Identifier
Feature Key Management Protocol NOTE 1 The text in this clause is based on section 5 of CCITT Rec. Q.932. Differences are indicated by emboldening. The Feature Key management protocol is a mechanism allowing users to invoke supplementary services. As these are stimulus procedures, the protocol elements do not directly identify the service invoked. To determine the service
-3-
invoked requires knowledge of the user's service profile maintained in the PTN. No call state changes occur directly as a result of these procedures. The Feature Key management protocol is based on two information elements: Feature activation and Feature indication. The Feature activation information element is the means by which a user requests a supplementary service. The Feature activation information element contains a feature identifier number which the PTN maps to the corresponding service as indicated by that user's service profile. The TE need not have any knowledge of what service is being indicated by the feature identifier number and the user may send a feature request at any time. Feature indication is the means by which a response to a feature request is indicated by the PTN. The feature identifier number correlates the PTN's response with a user's request and/or an indicator associated with a TE. The Feature indication information element also contains a status indicator. The status indicator indicates the status of the requested service and may be used by theTE as appropriate with its man-machine interface. 6.1 6.1.1
Messages Messages used in association with a Call Reference The Feature activation and Feature indication information elements may be present in several of the messages defined in ETS 300 192. The Feature activation information element may appear in the following messages in the direction TE to PTN: a) b) c) d) e) f) g)
SETUP INFORMATION ALERTING CONNECT DISCONNECT RELEASE RELEASE COMPLETE
The Feature activation information element may be repeated in a single message. NOTE 2 "Activation" as part of the name "Feature activation" should not be confused with the term "activation" used elsewhere, e.g. in stage 1 descriptions. Depending on the context, "Feature activation" can mean invocation, activation, deactivation, interrogation etc. of a supplementary service. The Feature indication information element may be sent in the directionPTN to TE in the following messages: a) b) c) d) e) f) g) h) i) j)
SETUP SETUP ACKNOWLEDGE CONNECT CALL PROCEEDING ALERTING INFORMATION DISCONNECT RELEASE RELEASE COMPLETE CONNECT ACKNOWLEDGE
The Feature indication information element may be repeated in a single message. 6.1.2
Messages used in association with the Dummy Call Reference One or more Feature activation information elements may appear in an INFORMATION message in the direction TE to PTN. One or more Feature indication information elements may appear in an INFORMATION message in the direction PTN to TE.
6.1.3
Additional information elements Several messages may contain further information elements, in addition to those specified in ETS 300 192, according to the following list:
-4-
Calling party number:
May be included in an INFORMATION message with the dummy call reference in the direction TE to PTN for multiple subscriber number arrangements (see ETS 300 189).
Cause:
May be included in an INFORMATION message in the direction PTN to TE (as response to a feature request).
Display:
May be included in every message in the direction PTN to TE.
Endpoint identifier:
May be included in INFORMATION and in SETUP messages (used for the optional terminal identification procedures described in annex A).
Information request:
May be included in an INFORMATION message in the direction PTN to TE (used for the optional information request procedures described in annex B).
Keypad facility:
May be included in INFORMATION and SETUP messages in the direction TE to PTN to provide additional information, e.g. in conjunction with the information request procedures according to annex B.
Signal:
May be included in the direction PTN to TE in the messages: ALERTING CONNECT CONNECT ACKNOWLEDGE DISCONNECT INFORMATION RELEASE RELEASE COMPLETE SETUP SETUP ACKNOWLEDGE
Service profile identification:
May be included in an INFORMATION message in the direction TE to PTN (used for the optional automatic assignment procedure described in sub-clause A.4 of annex A).
Switchhook:
May be included in the direction TE to PTN in the messages: CONNECT DISCONNECT INFORMATION RELEASE SETUP
The coding of these information elements is specified in clause 7. 6.2
Procedures
6.2.1 6.2.1.1
TE requests Feature requests in association with a Call Reference The TE may request a feature by including a Feature activation information element in any of the messages defined in 6.1. The TE shall indicate the desired feature by specifying the appropriate value in the feature identifier number field. An INFORMATION message may be sent at any time after sending or receiving the first response to the SETUP message and before sending or receiving a RELEASE or RELEASE COMPLETE message.
6.2.1.2
Feature requests in association with the Dummy Call Reference The Feature activation information element may be sent in an INFORMATION message using the dummy call reference in situations where it is inappropriate to use an existing call reference or to establish a new call reference for the purpose.
-5-
Before sending an INFORMATION message with the dummy call reference the TE must first ensure that a Data Link connection exists between the TE and the PTN. If a Data Link connection does not exist the TE shall establish a Data Link connection according to the procedures described in sub-clause 6.1.1 of ETS 300 192. 6.2.1.3
Switchhook indication The Switchhook information element may be used to indicate "on-hook" or "off-hook" to the PTN.
6.2.2
PTN responses The PTN may respond to a feature request in several ways. The action chosen is supplementary service and implementation specific.
6.2.2.1
Return of a Feature indication The PTN may return a Feature indication information element in an INFORMATION message or any other appropriate call control message as defined in 6.1. The Feature indication may or may not have the same feature identifier number as was present in the original feature request. The status indicator shall be provided as appropriate to the specific supplementary service requested.
6.2.2.2
Prompting for further information The PTN may prompt the user for more information (e.g. additional information related to a given feature request). The procedures employed are implementation specific, possibilities including the use of tones / announcements, displays, etc.; the TE may send the required information in Keypad facility or other suitable information elements. Optionally the information request procedures defined in annex B may be used.
6.2.2.3
Implicit response The PTN, under certain situations, may not return any explicit indication to the TE after a feature request. In this case the response is implicit, such as the acknowledgement inherent in providing the service.
6.2.2.4
Return of Signal, Cause or Display information elements The PTN may return any combination of Signal, Cause or Display information elements, also in conjunction with other responses specified in 6.2.2. The use of these information elements is supplementary service and implementation specific.
6.2.2.5
Responses during error conditions When an error condition exists (as defined in 6.2.4) thePTN may: −
React with one or more responses according to 6.2.2.1 - 6.2.2.4; or
−
Ignore the feature request and not respond at all.
The PTN may alsoclear appropriate existing calls in conjunction with the above actions. 6.2.3 6.2.3.1
General aspects Use of Feature indication information elements independent of a feature request The PTN may choose to send Feature indication information at any time, independent of the status of any call(s), either in an INFORMATION message or in an appropriate call control message as specified in 6.1.1 and 6.1.2. Multiple Feature indication information elements may be included in a single message if more than one indicator is to be updated.
6.2.3.2
Deactivation procedures When explicitly deactivating a supplementary service, two methods may be used: a)
sending of a feature request with the same feature identifier may deactivate the supplementary service; some supplementary services may be "toggled" on and off;
b)
sending a feature request with a different feature identifier which is explicitly defined (between the TE and the PTN) as the deactivator for that particular supplementary service.
-6-
6.2.3.3
Clearing of a call If a Feature activation information element is sent using the call reference of an active call, and that call is cleared for some reason, then there exists no call reference with which to correlate the feature indication. If a Feature indication information element is to be returned, one of the following options may be used:
6.2.3.4
a)
The PTN may send a Feature indication information element in one of the call clearing messages (i.e., DISCONNECT, RELEASE, or RELEASE COMPLETE).
b)
The PTN may send a Feature indication information element in an INFORMATION message after clearing has occurred, using the dummy call reference.
Sending of multiple feature requests / indications If a sequence of feature requests is received, either in one message or in separate messages, so rapidly that the PTN cannot respond to the first feature request prior to receiving a subsequent feature request, the PTN shall act upon all feature requests in the order received by returning multiple Feature indication information elements or other responses as detailed in 6.2.2. These may be sent in a single message or in multiple messages. If a TE receives a sequence of feature indications, either in one message or in separate messages, it shall act upon each feature indication individually in the order received.
6.2.4
Error conditions The error procedures specified in sub-clause 6.3 of ETS 300 192 shall also apply for the messages and information elements specified in this Standard. Additionally, the following procedures shall apply.
6.2.4.1
Invalid feature request If a TE requests a feature using an invalid feature identifier number, the PTN shall take any of the actions specified in 6.2.2.5, as appropriate. An invalid feature identifier number is one for which the user is not provided a corresponding service, or the value is not understood by the service provider (e.g. out of range).
6.2.4.2
Invalid call reference If a TE uses the dummy call reference in a message other than INFORMATION, or if it sends an INFORMATION message with the dummy call reference when the PTN expects an existing call reference for a particular feature request, the PTN shall not provide the service and shall respond as indicated in 6.2.2.5.
6.2.4.3
Invalid feature indication or PTN response A TE may ignore an invalid Feature indication (e.g. an unknown feature identifier number) or any PTN response which it did not expect or cannot handle correctly. Other actions of the TE are implementation dependent.
7
Coding of Information Elements NOTE 3 This clause is based on section 8 of CCITT Rec. Q.932, with differences indicated by emboldening, and also contains references to ETS 300 192 and ETS 300102-1. 7.1
Dummy call reference Sub-clause 4.3 of ETS 300102-1 shall apply.
7.2
Calling party number ETS 300 192, 11.5.10, shall apply.
7.3
Cause ETS 300 102-1, 4.5.12, shall apply.
7.4
Display ETS 300 102-1, 4.5.15, shall apply.
-7-
7.5
Endpoint identifier The purpose of the Endpoint identifier information element is: −
to indicate the user service identifier and terminal identifier for the purpose of terminal identification; and
−
to indicate a specific terminal for the purpose of terminal selection.
See annex A for the associated procedures. The Endpoint identifier information element is coded as shown in figure 1 and table 1. The default maximum length of the Endpoint identifier information element is four octets. 8
7
6
5
4
3
2
1
1
1
Endpoint identifier 0
0
1
1
1
0
Octet 1
information element identifier Length of Endpoint identifier contents 1 ext 1 ext
Inter pret.
2
User service identifier
3
Terminal identifier
4* * This octet is optional
Figure 1 - Endpoint identifier information element Table 1 - Endpoint identifier information element User service identifier (USID) (octet 3) The USID is a selection parameter which identifies a group of terminals on an interface which share a common service profile and which may be addressed together. Upon receipt of this parameter a terminal will consider itself as being addressed if the value received matches its stored value or if the value received is coded as all ONEs (127). When USID is coded 127, octet 4 shall not be used. Interpreter (octet 4, bit 7) Bit 7 of octet 4 indicates how a terminal is to interpret the TID field received (see TID definition below) if the value of this field is not 63. When set to ZERO the terminal is being addressed only if the TID value matches. When set to ONE, the terminal is being addressed only if the TID received does not match. In the direction TE to PTN this bit shall be set to ZERO. Terminal identifier (TID) (octet 4, bits 1 to 6) The TID is a selection parameter which identifies a single terminal within a group designated by a USID value. For USID=127 the TID does not apply. Upon receipt of this field, a terminal will consider itself addressed if one of the following is true: − the interpreter bit is set to ZERO and the TID value received matches the terminal's stored value; − the interpreter bit is set to ONE and the TID value received does not match the terminal's stored value; − the TID value received is set to all ONEs (63).
-8-
7.6
Feature activation The purpose of the Feature activation information element is to invoke a supplementary service as identified by the feature identifier number. The service associated with the feature identifier number is dependent on that particular user's service profile. The default maximum length of this information element is four octets. The Feature activation information element is coded as shown in figure 2 and table 2. 8
7
6
5
4
3
2
1
0
0
Feature activation 0
0
1
1
1
0
Octet 1
information element identifier Length of Feature activation contents
2
0/1 ext
Feature identifier number
3
1 ext
Feature identifier number (continuation)
3a
Figure 2 - Feature activation information element Table 2 - Feature activation information element Feature identifier number (octet 3 and 3a) The feature identifier number is a unique number assigned to a feature in a service profile. The feature identifier number is part of both the Feature activation and Feature indication information elements. This number identifies the feature that is being requested or updated. The association of a particular number to a particular feature may be different for each user. Bit 8 in octet 3 is used to extend the feature identifier field. If bit 8 is set to ZERO then another octet follows; if bit 8 is set to ONE then octet 3 is the last octet. The identifier numbers 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.
7.7
Feature indication The purpose of the Feature indication information element is to allow the PTN to convey feature indications to the user regarding the status of a supplementary service. The default maximum length of this information element is 5 octets. The coding of the Feature indication information element is shown in figure 3 and table 3.
-9-
8
7
6
5
4
3
2
1
0
1
Feature indication 0
0
1
1
1
0
Octet 1
information element identifier Length of Feature indication contents
2
0/1 ext
Feature identifier number
3
1 ext
Feature identifier number (continuation)
3a
0
0
0 Spare
0
Status indicator
4
Figure 3 - Feature indication information element Table 3 - Feature indication information element Feature identifier number (octet 3 and 3a) See table 2 Status indicator (octet 4) The status indicator field identifies the current status of a supplementary service. Bits 4 3
2
1
Status
Meaning
0
0
0
0
Deactivated
0
0
0
1
Activated
0
0
1
0
Prompt
0
0
1
1
Pending
Feature is in the deactivated state Feature is in the active state Feature prompt (waiting for user input) Feature is pending
Example of possible TE implementation Lamp off Lamp steady on Lamp steady flash Lamp steady wink
All other values are reserved.
7.8
Information request The purpose of the Information request information element is to provide the capability for requesting additional information and signalling completion of the information request (see annex B). The information request information element is coded as shown in figure 4 and table 4. The default maximum length of the Information request information element is three octets.
- 10 -
8
7
6
5
4
3
2
1
1
0
Information request 0
0
1
1
0
0
Octet 1
information element identifier
1 ext
Length of information request contents
2
Info Req. Ind.
3
Type of information
Figure 4 - Information request information element Table 4 - Information request information element Information request indicator (octet 3, bit 7) Bit 7 = 0 Bit 7 = 1
Information request completed Prompt for additional information
Type of information (octet 3, bits 1 to 6) Bits
6
5
4
3
2
1
Bits
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 1 1
0 1 0 1
undefined authorization code address digits terminal identification
All other values are reserved.
7.9
Keypad facility ETS 300 102-1, 4.5.17, shall apply.
7.10
Signal ETS 300 102-1, 4.5.27, shall apply.
7.11
Service profile identification The purpose of the Service profile identification information element is to allow the user to initiate automatic assignment of the user service identifier and terminal identifier (see annex A). The Service profile identification information element is defined in figure 5 and table 5. The default maximum length of the Service profile identification information element is 32 octets.
- 11 -
8
7
6
5
4
3
2
1
Service profile identification 0
0
1
1
1
0
1
0
Octet 1
Length of service profile identification contents
2
information element identifier
0
SPID (IA5 characters)
3 etc.
Figure 5 - Service profile identification information element Table 5 - Service profile identification information element SPID (Octet 3 and following) The service profile identifier parameter is coded in IA5 characters, according to the format specified by the PTN.
7.12
Switchhook The purpose of the Switchhook information element is to indicate the status of the terminal switchhook to the PTN. The Switchhook information element is coded as shown in figure 6 and table 6. The length of this information element is three octets. 8
7
6
5
4
3
2
1
1
0
Switchhook 0
0
1
1
0
1
Octet 1
information element identifier Length of switchhook contents
0
0
0
Spare 0
2 Switch
0
0
0
hook value
Figure 6 - Switchhook information element Table 6 - Switchhook information element Switchhook value (octet 3) Bit
1
meaning
0 1
on hook off hook
3
- 12 -
- 13 -
Annex A (normative)
User Service Profiles and Terminal Identification
NOTE A.1 This annex is based on annex A of CCITT Rec. Q.932, with differences indicated by emboldening.
A.1
Introduction These optional procedures allow a PTN to support identification and selection of specific terminals on a multi-point TE - PTN interface, and also to support multiple user service profiles, in those cases in which ETS 300 192 information elements are not sufficient for such purposes. A TE or PTN supporting such multiple profiles for terminals which could not otherwise be distinguished should support this additional identification procedure. Otherwise, it is completely optional. A TE or PTN that does not recognize the information elements used by this annex shall apply the error procedures defined in 6.3 of ETS 300 192if these elements are received. Figure A.1 shows examples of the relationships of TEs, SPIDs, USIDs and TIDs and their dynamic relationship to TEIs. In this example, TEs 1, 3, 4 and 5 support the automatic endpoint identifier parameter assignment procedure while TE 2 does not, but has the endpoint identifier parameters locally entered. TE 6 does not support terminal identification, therefore it utilizes the specified default service profile. NOTE A.2 TEIs are explained in ECMA-105. NOTE A.3 Items in parentheses indicate values or relationships which are dynamically established by initialization procedures (see A.4). Others are established via administrative actions and stored as a result of manual entry.
- 14 -
PTN User
Multipoint Access
PTN
Service profile A TE 1 SPID=JKL (USID=3) (TID=6) (TEI=71) TE 2 (USID=3) (TID=7) (TEI=82)
Service profile B TE 3 SPID=MNO (USID=4) (TID=11) (TEI=83) TE 4 SPID=PQR (USID=4) (TID=12) (TEI=84) TE 5 SPID=PQR (USID=4) (TID=7) (TEI=75)
Service profile C TE 6 (TEI=76)
(TE=71<-> USID=3, TID=6) Service profile A SPID=JKL USID=3 (TE=82<-> USID=3, TID=7)
(TE=83<-> USID=4, TID=11) Service profile B SPID=MNO and PQR USID=4 (TE=84<-> USID=4, TID=12)
(TE=75<-> USID=4, TID=7) Service profile C USID=126 Default profile No SPID
(TE=76<-> USID=126, TID=1)
Figure A.1 - Relationship of service profile, SPID, USID, TID and TEI
- 15 -
A.2
User service profiles The support of user service profiles requires that the supplementary service requests from a TE are associated by the PTN with a specific profile. A USID is used to identify the profile on a PTN access. The service profile is assigned to a Data Link connection so that the PTN can associate all of the service requests from the corresponding Connection Endpoint Suffix (CES) with the required profile (see NOTE A.4). The assignment of a service profile to a Data Link connection minimizes the per-service request overhead of profile identification. The procedures for assigning a service profile to a Data Link connection are incorporated into the initialization procedures described in A.4. NOTE A.4 CES along with SAPI constitute the CEI (Connection Endpoint Identifier) that is used to identify message units passed between the Data Link Layer (as represented by the TEI) and Layer 3.
A.3
Terminal identification The support of terminal identification requires that a call sent by thePTN can be addressed to: −
all of the TEs of a user service profile;
−
one TE of a user service profile; or
−
all but one TE of a user service profile.
A USID is used to identify the user service profile with a (set of) TE(s) on a PTN access interface, and a TID is used to identify individual TEs within a user service profile on aPTN access. The USID and TID may be entered into the TE by the user as arranged with the service provider, or dynamically downloaded to the TE from thePTN with an automatic assignment procedure. The USID and TID parameters are used by the TE to check the compatibility of a call offered by the PTN. The inclusion of a USID and TID with only access uniqueness minimizes the per-call overhead of supporting terminal addressing. The procedures for downloading the USID and TID to a TE are incorporated into the automatic endpoint identifier allocation and initialization procedures described in A.4. The procedures for using a USID and TID for terminal identification in an offered call sent by thePTN are described in A.5.
A.4
Initialization The initialization procedure provides for the association by the PTN of the supplementary service requests from a TE on a particular Data Link connection (as represented by the TEI) with a user service profile. An additional automatic assignment procedure, which may optionally be used by a TE, provides for automatic assignment of USID and TID parameters and their downloading by thePTN to the TE. Since initialization provides the basis for subsequent association of a service profile with a Data Link connection, normally, a TE that supports initialization is expected to request the initialization procedure (e.g. with the first Layer 3 message after dynamic assignment of a TEI). However, a request for initialization is allowed at any time. The Data Link connection is always associated with the most recently identified service profile. Under some circumstances, the PTN may solicit terminal initialization.
A.4.1
Terminal requested initialization a)
TEs may initialize at any time by sending an Endpoint identifier information element (containing a USID and TID) in an INFORMATION message to the PTN. Subsequent to this, the PTN shall associate the service profile with the Data Link over which the message was sent.
b)
For terminals which support automatic as signment of USID and TID parameters, initialization (that is, association of a service profile with a Data Link connection) is provided as part of the automatic assignment procedure described here.
- 16 -
A TE may initiate automatic assignment of the endpoint identifier by sending a Service profile identification information element in an INFORMATION message with the dummy call reference. The Service profile identification information element should contain the SPID parameter allocated by arrangement with the service provider. The PTN shall associate the Data Link over which the message was received with the identified service profile and acknowledge the initialization by sending an INFORMATION message with the Endpoint identifier information element containing a USID and TID, the values of which are determined by the PTN. When a TE determines that the initialization procedure has failed, it shall assume that the PTN cannot support the procedure and shall not repeatedlyrequest initialization. A.4.2
PTN solicited initialization The PTN may solicit a request for initialization on a Data Link connection by sending an Information request information element with the codepoint "terminal identification" in an INFORMATION message with the dummy call reference. Upon receiving the request, the terminal may respond as described in A.4.1 a) or b) above. When a PTN determines that the initialization procedure has failed, it shall assume that the terminal cannot support the procedures andshall not repeatedly solicit initialization.
A.4.3
Collision When terminal initialization request and PTN solicitation procedures collide, the terminal shall ignore the solicitation from the PTN and the PTN shall proceed as normal upon receipt of the initialization request from the terminal.
A.5
Identification procedures The PTN may offer a call using terminal addressing by including the Endpoint identifier information element in the SETUP message. When a TE receives a SETUP message containing the Endpoint identifier information element, it shall: −
if the Endpoint identifier information element is not supported, handle the information element in accordance with the error procedures defined in sub-clause 6.3 of ETS 300 192 and complete normal compatibility checking procedures; or
−
if the Endpoint identifier information element is supported, test for an address compatibility with the endpoint identifier (EID) in addition to completing the normal compatibility checking procedures.
- 17 -
Annex B (normative)
Information Request Procedures
NOTE B.1 This annex is based on annex B of CCITT Rec. Q.932, with differences indicated by emboldening.
B.1
Introduction This annex specifies optional procedures which allow a PTN to request additional information from a TE. These procedures do not impact the ETS 300 192 call state. This capability shall only be allowed during the Null, Overlap Sending, Outgoing Call Proceeding, Call Delivered and Active Call states. A TE or PTNX that does not recognize the information elements used by this annex shall apply the error procedures defined in 6.3 of ETS 300 192if these information elements are received.
B.2 B.2.1
Procedures Normal procedures The PTN may send an INFORMATION message to the TE to request additional information. The INFORMATION message may be sent with an existing call reference or with the dummy call reference, as appropriate. The INFORMATION message shall contain the Information request information element with the information request indicator set to "prompt for additional information" and type of information set to the appropriate value. After sending the INFORMATION message while in the Overlap Sending state the PTN shall start timer T302; the PTN shall then restart timer T302 on the receipt of every INFORMATION message unless the requested information is complete. In any call state other than Overlap Sending the PTN may apply an implementation-specific timer Ti in a similar way, as appropriate. No ETS 300 192 call state changes shall occur when the INFORMATION message is sent or received. The TE may always send the requested information in Keypad facility information elements contained in one or more INFORMATION messages. However, the TE may include in the INFORMATION message(s) other information elements, too, if appropriate. When the PTN has determined that sufficient information has been received to proceed, it shall stop timer T302 or any implementation-specific timer Ti. It may also send an INFORMATION message to the TE, containing an Information request information element with the information request indicator set to "information request completed" to indicate that the required information has been received correctly. If the additional information was requested during Overlap Sending state, and no additional information is required before the PTN can proceed with processing the call, a CALL PROCEEDING message may suffice to signal the end of information sending. If an existing call reference was used the PTN may also indicate that sufficient information has been received by initiating call clearing according to 7.3 of ETS 300 192.
B.2.2
Abnormal procedures If no response is received from the TE, or if the information received is incomplete upon expiry of timer T302 or an implementation-specific timer Ti, or if the information provided by the user is invalid, then the PTN shall −
either initiate call clearing according to 7.3 of ETS 300 192, if the information request related to a call in progress;
−
or return an INFORMATION message containing a Cause information element with an appropriate cause value, e.g. if the dummy call reference was used.
- 18 -
If the TE responds with a RELEASE COMPLETE message to an INFORMATION message containing the dummy call reference and an Information request information element, then the procedure shall be considered as terminated.
- 19 -
Annex C (informative)
Illustration of the Feature Key Management Protocol
NOTE C.1 This annex is based on section I.3 of Appendix I of CCITT Rec. Q.932, with differences indicated by emboldening. This annex is provided as an illustration of the application of the Feature Key Management protocol. The example shown should not be taken as definitive, since the support of the Feature Key Management protocol implementation is dependent. The signalling sequence shown is not exhaustive and is only intended to illustrate one possible supplementary service control sequence. The example in figure C.1 shows a feature request entered in the Overlap Sending state, with parameters provided in form of digits contained in Keypad facility information elements. The association of the feature identifier number (provided within the Feature activation and Feature indication information elements) with a given supplementary service has to be arranged between theTE and the PTN before the service is provided for the first time.
TE
PTN SETUP (CR=x)
establish call ref.x for call request
feature request provide parameters required for service (digits)
SETUP ACK
INFO (Feature activation) INFO (Keypad) . . . INFO (Keypad)
INFO (Feature indication)
clear call
associate feature identifier
acknowledge service status
DISC (Cause) REL REL COMP
Figure C.1 - Generic example of the use of the Feature key management protocol
- 20 -
- 21 -
Annex D (normative)
Protocol Implementation Conformance Statement (PICS) Proforma
D.1
Introduction The supplier of a protocol implementation which is claimed to conform to this Standard shall complete one of the following Protocol Implementation Conformance Statement (PICS) proformas. The PICS proforma in D.3 is for a PTNX. The PICS proforma in D.4 is for a TE. A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of which capabilities and options of the protocol have been implemented. The PICS can have a number of uses, including use:
D.2 D.2.1
−
by the protocol implementor, as a check list to reduce the risk of failure to conform to the Standard through oversight;
−
by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the capabilities of the implementation, stated relative to the common basis for understanding provided by the Standard's PICS proforma;
−
by the user or potential user of the implementation, as a basis for initially checking the possibility of interworking with another implementation - while interworking can never be guaranteed, failure to interwork can often be predicted from incompatible PICSs;
−
by a protocol user, as the basis for selecting appropriate tests against which to assess the claim for conformance of the implementation.
Instructions for completing the PICS proforma General structure of the PICS proforma The PICS proforma is a fixed-format questionnaire divided into sub-clauses each containing a group of individual items. Each item is identified by an item number, the name of the item (question to be answered), and the reference(s) to the clause(s) specifying the item in the main body of this Standard. The "Status" column indicates whether an item is applicable and if so whether support is mandatory or optional. The following terms are used: m
mandatory (the capability is required for conformance to the protocol);
o
optional (the capability is not required for conformance to the protocol, but if the capability is implemented, it is required to conform to the protocol specifications);
o.<n>
optional, but support of at least one of the group of options labelled by the same numeral <n> is required;
x
prohibited;
c.<cond>
conditional requirement, depending on support for the item or items listed in condition <cond>;
<item>:m
simple conditional requirement, the capability being ma ndatory if item number <item> is supported, otherwise not applicable;
<item>:o
simple conditional requirement, the capability being optional if item number <item> is supported, otherwise not applicable.
- 22 -
Answers to the questionnaire items are to be provided in the "Support" column, by simply marking an answer to indicate a restricted choice (Yes or No), or in the "Not Applicable" column (N/A). D.2.2
Additional Information Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of the PICS. It is not intended or expected that a large quantity will be supplied, and a PICS can be considered complete without any such information. Examples might be an outline of the ways in which a (single) implementation can be set up to operate in a variety of environments and configurations. References to items of Additional Information may be entered next to any answer in the questionnaire, and may be included in items of Exception information.
D.2.3
Exception Information It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any conditions have been applied) in a way that conflicts with the indicated requirement. No pre-printed answer will be found in the Support column for this. Instead, the supplier is required to write into the Support column an x.<i> reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. An implementation for which an Exception item is required in this way does not conform to this Standard. A possible reason for the situation described above is that a defect in the Standard has been reported, a correction for which is expected to change the requirement not met by the implementation.
- 23 -
D.3
PICS proforma for ECMA-161 PTNX Implementations
D.3.1
Implementation identification
Supplier Contact point for queries about the PICS Implementation Name(s) and Version(s) Other information necessary for full identification, e.g. name(s) and version(s) for machines and/or operating systems; system name(s)
Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirement for full identification. The terms Name and Version should be interpreted appropriately to correspond with a supplier's terminology (e.g. Type, Series, Model).
D.3.2
Protocol summary
Protocol version
1.0
Addenda Implemented (if applicable) Amendments Implemented Have any exception items been required (see D.2.3)?
Date of statement
No [ ] Yes [ ] (The answer Yes means that the implementation does not conform to this Standard)
- 24 -
D.3.3
Procedures for the PTNX
Item
Question / feature
References
Status
N/A
Support
A1
Receipt of a feature activation request
6.2.1
m
Yes [ ]
A2
Handling of multiple feature activation requests in the order received
6.2.3.4
m
Yes [ ]
A3
Sending of a feature indication as a response to a feature activation request
6.2.2.1
o
Yes [ ]
No [ ]
A4
Reactions to feature activation requests other than the sending of feature indications
6.2.2
o
Yes [ ]
No [ ]
A5
Sending of feature indications independent of a feature activation request
6.2.3.1
o
Yes [ ]
No [ ]
A6
Information request procedure
Annex B
o
Yes [ ]
No [ ]
A7
Terminal selection by Endpoint identifier
A.5
o
Yes [ ]
No [ ]
A8
Non-automatic terminal initialization
A.4
A7:o.1
[]
o: Yes [ ]
No [ ]
A9
Automatic assignment of an endpoint identifier
A.4
A7:o.1
[]
o: Yes [ ]
No [ ]
- 25 -
D.3.4
Messages and information elements - PTNX requirements
Item
Question / feature
References
Status
N/A
B1
Receipt of INFORMATION messages with the dummy Call Reference
6.1.2 7.1
m
Yes [ ]
B2
Sending of INFORMATION messages with the dummy Call Reference
6.1.2 7.1
o
Yes [ ]
B3
Receipt of a Feature activation information element in ALERT, CONNECT, DISCONNECT, INFORMATION, RELEASE, RELEASE COMPLETE, SETUP
6.1.1 6.1.2 7.6
m
Yes [ ]
B4
Receipt of multiple Feature activation information elements in a single message
6.1.1 6.1.2
m
Yes [ ]
B5
Inclusion of Feature indication information element(s) in one or more of the specified messages
6.1.1 6.1.2 7.7
c.1
m: Yes [ ] o: Yes [ ]
B6
Inclusion of a Signal information element in any of the specified messages
6.1.3 7.10
o
Yes [ ]
No [ ]
B7
Inclusion of a Cause information element in INFORMATION
6.1.3 7.3
o
Yes [ ]
No [ ]
B8
Inclusion of a Display information element in any message
6.1.3 7.4
o
Yes [ ]
No [ ]
B9
Inclusion of an information request information element in INFORMATION
6.1.3 7.8
A6:m
B10
Receipt of a Keypad facility information element in INFORMATION or SETUP
6.1.3 7.9
c.2
B11
Inclusion of an Endpoint identifier information element in SETUP
6.1.3 7.5
A7:m
[]
m: Yes [ ]
B12
Receipt of an Endpoint identifier information element in INFORMATION
6.1.3 7.5
A8:m
[]
m: Yes [ ]
B13
Inclusion of an Endpoint identifier information element in INFORMATION
6.1.3 7.5
A9:m
[]
m: Yes [ ]
B14
Receipt of a Service profile identification information element in INFORMATION
6.1.3 7.11
A9:m
[]
m: Yes [ ]
B15
Receipt of a Switchhook information element in CONNECT, DISCONNECT, INFORMATION, RELEASE, SETUP
6.1.3 7.12
o
Yes [ ]
No [ ]
B16
Receipt of a Calling party number information element in INFORMATION with the dummy Call Reference
6.1.3 7.2
o
Yes [ ]
No [ ]
[]
Support
No [ ]
No [ ]
m: Yes [ ] m: Yes [ ] o: Yes [ ]
No [ ]
- 26 -
D.4
PICS proforma for ECMA-161 TE Implementations
D.4.1
Implementation identification
Supplier Contact point for queries about the PICS Implementation Name(s) and Version(s) Other information necessary for full identification, e.g. name(s) and version(s) for machines and/or operating systems; system name(s)
Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirement for full identification. The terms Name and Version should be interpreted appropriately to correspond with a supplier's terminology (e.g. Type, Series, Model).
D.4.2
Protocol summary
Protocol version
1.0
Addenda Implemented (if applicable) Amendments Implemented Have any exception items been required (see D.2.3)?
Date of statement
No [ ] Yes [ ] (The answer Yes means that the implementation does not conform to this Standard)
- 27 -
D.4.3
Procedures for the TE
Item
Question / feature
References
Status
N/A
Support
C1
Sending of a feature activation request in association with a Call Reference
6.2.1.1
o
Yes [ ]
No [ ]
C2
Sending of a feature activation request in association with the dummy Call Reference
6.2.1.2
o
Yes [ ]
No [ ]
C3
Receipt of feature indications; processing in the order received
6.2.2.1 6.2.3.1
m
Yes [ ]
C4
Information request procedure
Annex B
o
Yes [ ]
No [ ]
C5
Terminal selection by Endpoint identifier
A.5
o
Yes [ ]
No [ ]
C6
Non-automatic terminal initialization
A.4
c5:o.2
[]
o: Yes [ ]
No [ ]
C7
Request for automatic assignment of an endpoint identifier
A.4
c5:o.2
[]
o: Yes [ ]
No [ ]
- 28 -
D.4.4
Messages and information elements - TE requirements
Item
Question / feature
References
Status
N/A
D1
Receipt of INFORMATION messages with the dummy Call Reference
6.1.2 7.1
m
Yes [ ]
D2
Sending of INFORMATION messages with the dummy Call Reference
6.1.2 7.1
o
Yes [ ]
D3
Inclusion of a Feature activation information element in one or more of the specified messages
6.1.1 6.1.2 7.6
c.3
m: Yes [ ]
D4
Inclusion of multiple Feature activation information elements in a single message
6.1.1 6.1.2
D3:o
o: Yes [ ]
D5
Receipt of one or more Feature indication information elements in ALERT, CALL PROCEEDING, CONNECT, CONNECT ACKNOWLEDGE, DISCONNECT, INFORMATION, RELEASE, RELEASE COMPLETE, SETUP, SETUP ACKNOWLEDGE
6.1.1 6.1.2 7.7
m
Yes [ ]
D6
Receipt of a Signal information element in any of the specified messages
6.1.3 7.10
m
Yes [ ]
D7
Receipt of a Cause information element in INFORMATION
6.1.3 7.3
m
Yes [ ]
D8
Receipt of a Display information element in any message
6.1.3 7.4
m
Yes [ ]
D9
Receipt of an Information request information element in INFORMATION
6.1.3 7.8
C4:m
D10
Inclusion of a Keypad facility information element in INFORMATION or SETUP
6.1.3 7.9
c.4
D11
Receipt of an Endpoint identifier information element in SETUP
6.1.3 7.5
C5:m
[]
m: Yes [ ]
D12
Inclusion of an Endpoint identifier information element in INFORMATION
6.1.3 7.5
C6:m
[]
m: Yes [ ]
D13
Receipt of an Endpoint identifier information element in INFORMATION
6.1.3 7.5
C7:m
[]
m: Yes [ ]
D14
Inclusion of a Service profile identification information element in INFORMATION
6.1.3 7.11
C7:m
[]
m: Yes [ ]
D15
Inclusion of a Switchhook information element in CONNECT, DISCONNECT, INFORMATION, RELEASE, SETUP
6.1.3 7.12
o
D16
Inclusion of a Calling party number information element in INFORMATION with the dummy Call Reference
6.1.3 7.2
D2:o
[]
Support
No [ ]
m: Yes [ ] m: Yes [ ] o: Yes [ ]
Yes [ ]
[]
No [ ]
No [ ]
No [ ]
o: Yes [ ]
No [ ]
- 29 -
Annex E (informative)
Relationship to Corresponding Standards for Public ISDNs
The Feature Key Management protocol for PTNs specified in this Standard complements and is compatible with the corresponding services for public ISDNs as specified by CCITT. There are no differences which will prevent terminal interchangeability between PTNs and public ISDNs. NOTE E.1 ETSI has not specified the Feature Key Management protocol for public ISDNs. The differences between this Standard and CCITT Rec. Q.932 (Feature key management protocol) are mainly editorial and can be summarized as follows (differences with a technical impact are indicated by emboldening): −
This Standard allows the inclusion of Feature activation and Feature indication information elements in more messages than Q.932.
−
This Standard allows multiple feature requests and indications; the Feature activation information element may be repeated in a single message, too; multiple requests and indications shall be processed in the order received.
−
There is an explicit list of additional information elements in this Standard.
−
This Standard simply differentiates between feature requests associated with an existing call reference and feature requests associated with the dummy call reference, whereas Q.932 uses the terms "call associated" and "non-call associated", with more complicated rules on the use of call references; the resulting procedures are equivalent.
−
This Standard explicitly states the requirement to establish a Data Link connection if the dummy call reference is used.
−
This Standard covers error handling more completely by explicitly referring to the error handling procedures of the basic call (implicit in Q.932).
−
This Standard contains PICS proformas.
Printed copies can be ordered from: ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland Fax: Internet:
+41 22 849.60.01 [email protected]
Files can be downloaded from our FTP site, ftp.ecma.ch, logging in as anonymous and giving your E-mail address as password. This Standard is available from library ECMA-ST as a compacted, self-expanding file in MSWord 6.0 format (file E161-DOC.EXE) and as a compacted, self-expanding PostScript file (file E161-PSC.EXE). File E161-EXP.TXT gives a short presentation of the Standard. The ECMA site can be reached also via a modem. The phone number is +41 22 735.33.29, modem settings are 8/n/1. Telnet (at ftp.ecma.ch) can also be used. Our web site, http://www.ecma.ch, gives full information on ECMA, ECMA activities, ECMA Standards and Technical Reports.
ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland This Standard ECMA-161 is available free of charge in printed form{ and as a file}. See inside cover page for instructions