Standard ECMA-296 D e c e mb e r 1 9 9 9
Standardizing Information and Communication Systems
Broadband Integrated Services Digital Network (B-ISDN) and Broadband Private Integrated Services Network (B-PISN) - Digital Subscriber Signalling System No. two (DSS2), Broadband Inter-Exchange Signalling (B-QSIG), and Signalling System No. 7 (SS7) - Prenegotiation - Part 1: Protocol Specification
Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected]
..
Standard ECMA-296 D e c e mb e r 1 9 9 9
Standardizing Information and Communication Systems
Broadband Integrated Services Digital Network (B-ISDN) and Broadband Private Integrated Services Network (B-PISN) - Digital Subscriber Signalling System No. two (DSS2), Broadband Inter-Exchange Signalling (B-QSIG), and Signalling System No. 7 (SS7) - Prenegotiation - Part 1: Protocol Specification
Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected] IW ECMA-296.DOC
03-01-00 12,19
..
Brief History
This Standard is one of a series of ECMA Standards defining services and signalling protocols applicable to Broadband Private Integrated Services Networks (B-PISNs). The series uses B-ISDN concepts as developed by ITU-T and conforms to the framework of International Standards for Open Systems Interconnection as defined by ISO/IEC. This Standard has been produced by ECMA TC32-TG15 in collaboration with ETSI Technical Committee Signalling Protocols and Switching (SPS) under ETSI work item DEN/SPS-05131-1. The Standard is part 1 of a multi-part standard covering the Digital Subscriber Signalling System No. 2 (DSS2), Broadband Inter-Exchange Signalling (B-QSIG), and Signalling System No. 7 (SS7) protocol specification for Broadband Integrated Services Digital Network (B-ISDN) and Broadband Private Integrated Services Network (B-PISN) Prenegotiation, as described below: Part 1:
"Protocol specification";
Part 2:
"Protocol Implementation Conformance Statement (PICS) proforma specification";
Part 3:
"Test Suite Structure and Test Purposes (TSS&TP) specification";
Part 4:
"Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing (PIXIT) proforma specification".
Part 3 and part 4 will only be produced by ETSI as EN 302 091-3 and EN 302 091-4 respectively. The 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-T, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. This ECMA Standard is technically aligned with EN 302 091-1 published by ETSI in November 1999.
This Standard has been adopted by the ECMA General Assembly of December 1999.
..
- i -
Table of contents 1
Scope
1
2
References
1
3
Definitions
2
3.1
External definitions
2
3.2
Additional definitions
2
Prenegotiation
2
3.2.1 4
Abbreviations
2
5
Description
2
5.1
Overview
2
5.2
Protocol model for PRN
3
6
Operational requirements
4
7
Primitive definitions and state definitions
4
7.1
Service primitives
4
7.2
PRN states
4
7.2.1
PRN Idle
4
7.2.2
PRN Initiated
4
7.2.3
PRN Delivered
4
7.2.4
PRN Present
4
7.2.5
PRN Received
4
Coding requirements
4
Abstract definition of the PRN operations
4
PRN procedures
6
9.1
General
6
9.2
Procedures at an originating or terminating CC entity
8 8.1 9
6
9.2.1
Invoking the PRN operation by the initiating CC entity
6
9.2.2
Responding to the PRN invocation
8
9.2.3
Completion of PRN
9
9.2.4
Error handling
10
9.2.5
Crossing of bearer establishment messages with prenegotiation-related APDUs
10
9.3
Procedures at a transit CC entity
10
10
Interactions
10
11
Interworking with networks not supporting PRN
10
11.1
Calls from other networks to a network supporting PRN
10
11.2
Calls to other networks not supporting PRN
10
- ii -
12
SDL Diagrams
10
Annex A - Information flow diagrams
17
Annex B - Object identifiers defined in this Standard
19
Annex C - Bibliography
21
1
Scope This Standard specifies the signalling protocol for the purpose of prenegotiation at the QB, SB ,TB and co-incident SB/TB reference points within, between and at the access to Broadband Private Integrated Services Networks and within, between and at the access to public European Broadband Integrated Services Digital Networks. The protocol operates between two adjacent call control entities. The protocol is applicable in a separated call and bearer (connection) control environment for the support of calls having none, one or multiple bearers. The protocol is applicable to a two-party call or a multi-party call. However, prenegotiation is performed between two parties. In case of multi-party connections (point-to-multipoint connections), prenegotiation may be performed between the root and the first party. The QB reference point is defined in ISO/IEC 11579-1. The SB and TB reference points are defined in ITU-T Rec. I.327. This Standard is based on the transport capabilities as defined in ETS 300 796-1 and ECMA-254, and is closely related to the call control protocol specification as defined in ECMA-294. The purpose of prenegotiation as specified in this Standard is to allow a user to check compatibility and availability at the remote user with regard to one or more connections the user intends to establish during the lifetime of the call, without reserving connection-oriented resources in the network. Reservation of connection-oriented resources at the remote user is outside the scope of this Standard.
2
References The following documents contain provisions which, through reference in this text, constitute provisions of this Standard. •
References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
•
For a specific reference, subsequent revisions do not apply.
•
For a non-specific reference, the latest version applies.
•
A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same number.
ECMA-254
Broadband Private Integrated Services Network (B-PISN) - Inter-Exchange Signalling Protocol Generic Functional Protocol (B-QSIG-GF)
ECMA-294
Broadband Integrated Services Digital Network (B-ISDN) and Broadband Private Integrated Services Network (B-PISN) - Digital Subscriber Signalling System No. two (DSS2), Broadband Inter-Exchange Signalling (B-QSIG), and Signalling System No. 7 (SS7) - Call Control in a Separated Call and Bearer Control Environment - Part 1: Protocol Specification
ISO/IEC 11579-1
Information technology - Telecommunications and information exchange between systems Private integrated services network - Part 1: Reference configuration for PISN Exchanges (PINX)
ISO/IEC 13247
Information technology - Telecommunications and information exchange between systems Broadband Private Integrated Services Network - Inter-exchange signalling protocol - Basic call/connection control
EN 300 443-1
Broadband Integrated Services Digital Network (B-ISDN); Digital Subscriber Signalling System No. two (DSS2) protocol; B-ISDN user-network interface layer 3 specification for basic call/bearer control; Part 1: Protocol specification [ITU-T Rec. Q.2931 (1995), modified]
ETS 300 796-1
Broadband Integrated Services Digital Network (B-ISDN); Digital Subscriber Signalling System No. two (DSS2) protocol; Generic functional protocol; Core aspects; Part 1: Protocol specification [ITU-T Rec. Q.2932.1 (1996), modified]
EN 302 093-1
Broadband Integrated Services Digital Network (B-ISDN); Digital Subscriber Signalling System No. two (DSS2) protocol; Point-to-point multiconnection bearer control specification in a separated call and bearer environment; Part 1: Protocol specification
- 2 -
ITU-T Rec. I.327
B-ISDN functional architecture
ITU-T Rec. X.680
Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation
ITU-T Rec. X.690
Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rues (CER) and Distinguished Encoding Rules (DER)
ITU-T Rec. X.880
Information technology - Remote operations: concepts, model and notation
CCITT Rec. Z.100 CCITT specification and description language (SDL)
3
Definitions
3.1
External definitions The definitions used in ECMA-254, ECMA-294, ISO/IEC 13247, EN 300 443-1 and ETS 300 796-1 apply.
3.2
Additional definitions For the purposes of this Standard the following additional definitions apply.
3.2.1
Prenegotiation The user action of checking compatibility and availability at the remote user with regard to one or more bearer connections the user intends to establish during the lifetime of the call, without already reserving bearer connection-oriented resources in the network.
4
Abbreviations For the purposes of this Standard, the abbreviations used in ECMA-254, ECMA-294, ISO/IEC 13247, EN 300 443-1, ETS 300 796-1, and EN 302 093-1 apply. In addition, the following abbreviations are used:
5 5.1
CC
Call Control
mp
modification possible (9.2.1.3, figure 2)
PRN
Prenegotiation
T/F
True/False (9.2.1.3, figure 2)
UM
User Mandatory (9.2.1.3, figure 2)
UO
User Optional (9.2.1.3, figure 2)
Description Overview This Standard specifies the procedures, messages, information elements and components needed for the support of Prenegotiation (PRN). PRN is an optional procedure which may be invoked by either the calling or called user at either the SB or the coincident SB/TB reference point. In both cases, it can only be invoked in conjunction with or after call establishment. PRN does not establish connections. PRN is performed between two users. In case of point-to-multipoint connections, it may be performed between the root and the first party. The PRN protocol operates between two adjacent call control entities (points of call and bearer co-ordination). It is not required that the network interprets and processes the contents of the PRN operation, except that incoming call segment identifier and bearer identifiers have to be mapped to the corresponding values on the outgoing side. The network may either relay the related information, or call control entities in the network(s) may also be involved in looking at various parameters of network relevance and may take action/possibly intervene in the PRN procedure. Possible actions/interventions of network nodes based on the interpretation of the contents of the PRN operation are outside the scope of this Standard. In general, all connection related parameters for any number of connections can be prenegotiated.
- 3 -
The purpose of PRN is to check compatibility and availability between the users without already reserving connection-related resources in the network. The response of a user to a PRN request may be: -
positive, if a user is fully compatible with the parameters proposed by the remote party - in this case, the connections may be established with the parameters as proposed by the remote party;
-
positive, if a user is not fully compatible with the parameters proposed by the remote party, but supports a compatible alternative/subset - in this case, the connections may be established with those parameters which were proposed as an alternative;
-
negative, if a user is not compatible with the parameters proposed by the remote party;
-
negative, if a user is compatible with the parameters proposed by the remote party, but the negotiated resources are currently unavailable.
NOTE If PRN is performed in combination with Call Establishment i.e. if no connections are existing/pending, the call might be released if the result of the PRN is negative. The PRN procedures allow a user to return either only one or several alternative acceptable parameter sets per connection.
5.2
Protocol model for PRN For PRN, the basic protocol model outlined in figure 1-1 of ETS 300 796-1 applies. Figure 1 shows how PRN fits into this basic model. It should be noted that figure 1 only shows those ASEs which are directly related to PRN. Telecommunication service application
Prenegotiation
Coordination function
(separated) Call Control ROSE
GFT-Control Transport mech. e.g. CO-BI
SAAL
Figure 1 - PRN within the B-QSIG/DSS2 protocol model
- 4 -
6
Operational requirements PRN may be used within an environment of multiconnection calls. In such an environment, no specific operational requirements exist, and PRN may be invoked according to the procedures of subclause 9.2.1. PRN is based on the transport capabilities as defined in ETS 300 796-1 and ECMA-254, and on the call establishment procedures as defined in ECMA-294.
7
Primitive definitions and state definitions
7.1
Service primitives The following services for PRN are defined:
7.2
Prenegotiate
confirmed
Prenegotiation-Alert
unconfirmed
Error
indication
PRN states For the purpose of PRN the following additional states exist in a Call Control entity (CC entity).
7.2.1
PRN Idle No PRN procedure invoked.
7.2.2
PRN Initiated This state exists at a preceding CC entity when a request for PRN has been sent to the succeeding CC entity but no response has been received.
7.2.3
PRN Delivered This state exists at a preceding CC entity when it has received an indication that PRN alerting has been initiated.
7.2.4
PRN Present This state exists at a succeeding CC entity that has not yet responded to a received request for PRN.
7.2.5
PRN Received This state exists at a succeeding CC entity when PRN alerting has been initiated but the PRN request has not yet been answered.
8 8.1
Coding requirements Abstract definition of the PRN operations Table 1 shows the definition of the operations, errors and types required for PRN using ASN.1 as defined in ITU-T Rec. X.680 and using the OPERATION and ERROR object classes as defined in ITU-T Rec. X.880. APDUs based on these operations shall be of types invoke, returnResult, returnError and reject as defined in table B.1 of ETS 300 796-1. The Basic Encoding Rules (BER) as defined in ITU-T Rec. X.690 shall be applied to the encoding of APDUs based on these operations and errors. Table 1 - PRN operations and errors
Prenegotiation-Operations-and-Errors {itu-t recommendation q 2984 prenegotiation-operations-and-errors (1)} DEFINITIONS AUTOMATIC TAGS ::= BEGIN EXPORTS preNegotiate, PrenegotiationProposal, prenegotiationAlert; IMPORTS OPERATION, ERROR FROM Remote-Operations-Information-Objects {joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} CallSegmentId FROM CC-Operations {itu-t recommendation q 2981 cc-operations (1)} BearerId FROM Call-Object-Class-Definitions {itu-t recommendation q 2981 call-object-class-definitions (5)}; PrenegotiationOperations
OPERATION ::= { preNegotiate | prenegotiationAlert }
- 5 -
preNegotiationOperationsDefinitions OBJECT IDENTIFIER ::= {itu-t recommendation q 2984 prenegotiation-operations-definitions (2)} preNegotiate { ARGUMENT
RESULT
OPERATION ::= SEQUENCE { prenegotiationProposal callAssociation CHOICE } SEQUENCE { prenegotiationProposal callAssociation CHOICE
PrenegotiationProposal, { callSegmentId CallSegmentId, callId CallIdValue }
PrenegotiationProposal, { callSegmentId CallSegmentId, callId CallIdValue }
} RETURN RESULT TRUE ERRORS { prenegotiateErrorSimple | prenegotiateErrorItemised } SYNCHRONOUS FALSE ALWAYS RESPONDS TRUE CODE global : { preNegotiationOperationsDefinitions 1 } } CallIdValue ::= OCTET STRING (SIZE (1..3)) PrenegotiationProposal
::= SEQUENCE OF ConnectionProposal
ConnectionProposal ::= SEQUENCE { connectionSubject ConnectionSubject, connectionReference ConnectionNumber, connectionCallRelation UserMandatory DEFAULT FALSE, bearerId BearerId OPTIONAL } ConnectionSubject ::= CHOICE { connectionProposal Proposal, connectionAccept Accept
}
ConnectionNumber
::=
INTEGER (1..127)
UserMandatory
::=
BOOLEAN
Accept ::= SEQUENCE { accept BOOLEAN, alternativeNo INTEGER OPTIONAL } -- TRUE if proposal is accepted and therefore no counterproposal necessary -- FALSE if proposal is rejected and no counterproposal is possible for UserOptional Connection -- alternativeNo specifies the accepted alternative Proposal ::= SEQUENCE { bearerEstDirection BearerEstDirection, mostPreferredProposal MostPreferredProposal, alternatives SEQUENCE OF Alternative OPTIONAL } BearerEstDirection ::= ENUMERATED { noSpecificRequirements (0), exclusiveByPrenegInvokingEntity (1), exclusiveByPrenegRemoteEntity (2), preferablyByPrenegRemoteEntity (3) } Alternative ::= SEQUENCE { alternativeProposal SEQUENCE OF ProposedItem, alternativeNo INTEGER (1..127) } -- alternativeNo reflects the priority of the alternatives MostPreferredProposal ::= SEQUENCE OF ProposedItem -- specifies one connection with minimum proposal ProposedItem ::= SEQUENCE { item InformationElement, modificationPossible BOOLEAN OPTIONAL } InformationElement
::= OCTET STRING (SIZE (4..4095) -- embedded DSS2 Information Elements -- information elements are listed in 9.2.1.3 -- maximum value depends on information element
- 6 -
preNegotiationOperationsErrors OBJECT IDENTIFIER ::= {itu-t recommendation q 2984 prenegotiation-operations-errors (3)} prenegotiateErrorSimple PARAMETER CHOICE CODE
global :
ERROR ::= { { callSegmentId CallSegmentId, callId CallIdValue } { preNegotiationOperationsErrors 1 } }
prenegotiateErrorItemised ERROR ::= { PARAMETER PrenegotiateErrorItemisedParam CODE global : { preNegotiationOperationsErrors 2 } } PrenegotiateErrorItemisedParam ::= SEQUENCE { callAssociation CHOICE { callSegmentId CallSegmentId, callId CallIdValue }, listOfConnectionErrors SEQUENCE OF ConnectionError } ConnectionError ::= SEQUENCE { connectionSubject ENUMERATED { unspecified (0), compatibleAndCurrentlyUnavailable (1), incompatible (2), ... }, connectionReference ConnectionNumber } prenegotiationAlert OPERATION ::= { RETURN RESULT FALSE SYNCHRONOUS FALSE ALWAYS RESPONDS FALSE CODE global : { preNegotiationOperationsDefinitions 2 } } END -- Prenegotiation-Operations-and-Errors
9
PRN procedures
9.1
General PRN procedures are based on the transport procedures for signalling messages of ECMA-254 / ETS 300 796-1. The specification of this clause shows the specific procedures for PRN that apply in addition to those specified for the underlying transport mechanism. PRN is also closely related to call establishment as specified in ECMA-294.
9.2
Procedures at an originating or terminating CC entity
9.2.1
Invoking the PRN operation by the initiating CC entity PRN is defined in a fully symmetric fashion and can be initiated either by the originating or terminating call control entity, depending on the service/application requirements. PRN may be invoked either together with call establishment or at any time during the active phase of the call, independently of the number of active bearer connections. After invoking PRN, an application-dependent timer T1 may be started. Actions at the expiry of this timer are outside the scope of this Standard. If the PRN invoke is rejected, timer T1 shall be stopped (if running). Additional application-dependent actions on receipt of a reject APDU that is correlated to a preNegotiate invoke are outside the scope of this Standard.
9.2.1.1
Invocation of PRN - relation to call establishment PRN may be invoked either: a)
by the originating CC entity concurrently with the call establishment; in this case the invoke component of the preNegotiate operation is transferred together with the invoke component of the call establish operation, the result of the preNegotiate operation may be transferred either together with the result of the call establish operation or at a later point in time (but not prior to the result of the call establish
- 7 -
operation); the optional PRNAlert operation may be transferred either together with the first end-to-end response of the call establish operation or at a later point in time; or b) by the terminating CC entity concurrently with the first end-to-end response to call establishment; or c)
by either the originating or the terminating CC entity after the first end-to-end response to call establishment.
PRN shall not be invoked between the sending of the invoke component of the call establish operation and the first end-to-end response. 9.2.1.2
Invocation of PRN - relation to bearer connection establishment PRN is initiated prior to the establishment of the related bearer connections. Prenegotiated bearer connections may or may not be established. PRN related to further bearer connections may be invoked independently from the number of already existing bearer connections within a call. Unless specified otherwise by call control procedures taking precedence, bearer connections may be established both from the user initiating the PRN and by the remote user responding to PRN. In order to avoid a concurrent parallel establishment of bearer connections, an indication "BearerEstDirection" shall be used, where the initiating user shall indicate one of the following alternatives: a)
no specific requirements are specified with regard to the direction of the bearer connection establishment;
b) bearer connections shall only be established by the user invoking the PRN; c)
bearer connections shall only be established by the remote user receiving the preNegotiate invoke (the remote user shall not accept the PRN proposal if not possible);
d) the initiating user would prefer the remote user to establish the bearer connections (to be either accepted or denied in the return result APDU returned in response to the invoked preNegotiate operation). 9.2.1.3
Contents of the PRN proposal To initiate PRN, the CC entity shall use the invoke component of the preNegotiate operation containing the prenegotiationProposal. The prenegotiationProposal shall consist of a set of connection proposals referring to the connections the user intends to establish within this call at a later point in time. For each proposed connection, the initiating user may specify a parameter "User Mandatory" (UM). By setting this parameter "true", this user indicates to the remote user to only respond positively to the preNegotiate invoke if the connection(s) marked as "user mandatory" can be accepted (possibly modified). If this parameter is absent for a proposed connection, or set to "false", the initiating user allows the remote user to respond positively to a preNegotiate invoke, even if the remote user cannot support this connection. With regard to the "user mandatory" parameter, no specific action of the network is required. The network shall relay this information. The initiating user may include the label "modificationPossible" for each parameter of the most preferred proposal. If this label is set to "false", or is not included, the responding user is not allowed to modify this parameter. If it is set to "true", the responding user is allowed to modify this parameter. For the parameters of the alternative proposals, this label shall not be used by the initiating user. For each proposed connection, the initiating user shall specify a most preferred proposal, and may specify alternative proposals for the same connections as well. These alternatives shall be ordered by a parameter "alternativeNo" indicating decreasing preference by increasing numbers starting with 1; i.e. alternative No. 1 is regarded as the second best proposal, alternative No. 2 as the third best proposal, etc. The alternative proposals shall only consist of those parameters which are different from the preferred proposal. Figure 2 gives an example illustration of a PRN proposal specified by the initiating user, where one alternative is offered for connection 1, and two alternatives are offered for connection n.
- 8 -
Preference
Connection n (UM) Connection 1 (UM)
UM: User Connection 1 (UM) Mandatory UO: User Optional Par. 1 (mp) mp:modification Par. 2 (mp) possible (T/F) .... Par. m1 (mp)
Connection n (UM) Connection 2 (UO)
Connection n (UM)
Par. 1 (mp) Par. 2 (mp) .... Par. m2 (mp)
Par. 1 (mp) Par. 2 (mp) .... Par. mn (mp)
...
CALL Figure 2 - Example Illustration of a PRN Proposal The negotiable parameters correspond to those service-related information elements which are specified both in ISO/IEC 13247 (B-QSIG Basic Call) and EN 300 443-1. These are: -
ATM adaptation layer parameter;
-
ATM traffic descriptor;
-
OAM traffic descriptor;
-
quality of service parameter;
-
broadband bearer capability;
-
broadband low layer information;
-
broadband high layer information;
-
end-to-end transit delay;
-
narrowband bearer capability;
-
narrowband low layer compatibility;
-
narrowband high layer compatibility.
These information elements will be included in the SETUP message for establishment of the negotiated connection. The Broadband repeat indicator information element shall not be used within the mostPreferredProposal, or within an alternativeProposal, in order to avoid possible ambiguities with the PRN procedures as such. Correspondingly, information elements within the mostPreferredProposal, or within one alternativeProposal shall not be repeated. 9.2.2
Responding to the PRN invocation Receiving a PRN proposal, the responding user shall evaluate the PRN proposal, taking into account the modification restrictions and preference indications of the initiating user. Depending on the proposed connections and the local configuration of the responding user, the terminal equipment may process and answer the request automatically or may present the request to the human user, e.g. in those cases where voice and video connections are involved. In the latter cases, the prengotiationAlert operation shall be invoked and transferred towards the initiating user. If the prenegotiationAlert invoke is rejected, actions on receipt of a reject APDU that is correlated to the prenegotiationAlert invoke are outside the scope of this Standard. The local terminal equipment configuration related to PRN is outside the scope of this Standard. Two examples of local terminal equipment configuration may be: -
instruction to present all PRN requests to the human user.
- 9 -
-
instruction to present those PRN requests to the human user where at least one voice or video connection is included.
As a result of this evaluation, the responding user shall either accept the proposed values, or try to find modified descriptions, or completely reject the PRN request. If the PRN proposal is accepted by the responding user (possibly modified), the responding CC entity shall send back a preNegotiate return result, indicating for each connection proposed either: -
acceptance (set accept to "true");
-
acceptance of a proposed alternative (set accept to "true" and indicate the alternative number accepted);
-
a counterproposal (set accept to "true" and indicate the proposed modified parameters, if any);
-
rejection (set accept to "false"; only possible for non-mandatory connections).
The responding user may send back more than one acceptable parameter set for each connection to indicate that all these sets would be acceptable. For each indicated connection, the responding user shall also evaluate the BearerEstDirection indication (see subclause 9.2.1.2). In case c) (bearer connection establishment exclusively by responding user), the responding user shall not accept a proposed connection, if this connection establishment is not possible. In case d) (bearer connection establishment preferably by responding user), it shall indicate its acceptance or denial of the proposed bearer establishment direction in the return result of the preNegotiate operation, e.g. by selecting BearerEstDirection indications according to alternatives b) or c) in the preNegotiate return result APDU. If the responding user cannot at all accept the proposed connection parameters and does not find acceptable modifications, or cannot at all accept the parameters for one connection marked as "user mandatory", then the responding CCentity shall send back a preNegotiate return error APDU. NOTE If PRN is performed in combination with Call Establishment i.e. if no connections are existing/pending, the call might be released if the result of the PRN is negative. The responding CCentity shall also send back a preNegotiate return error APDU in case the initiating user requests BearerEstDirection exclusively from the responding user for all connections, but the responding user cannot act accordingly. The responding CCentity shall also send back a preNegotiate return error APDU in the case that the negotiated resources are currently unavailable. Specific errors which may be used within the preNegotiate return error are:
9.2.3
-
generic reject of the whole PRN request (without further information);
-
indications of incompatibility or temporary unavailability for specific connections.
Completion of PRN If the initiating user receives an indication of the invocation of a prenegotiationAlert operation, it may start an application dependent timer T2. Actions on the expiry of this timer are outside the scope of this Standard. If the initiating user receives an indication (i.e. a preNegotiate return result APDU) that the responding user accepts the proposed connection(s), the initiating user may begin to establish these connections in accordance with EN 302 093-1 (Bearer control protocol), unless specified otherwise by the BearerEstDirection indication. If receiving a preNegotiate return result where one or more connections have been modified or have not been accepted, the initiating user may either accept the modifications and start establishing connections within this call based on the knowledge gained by the PRN, or may decide not to be able to support the counterproposal of the responding user, and may therefore either try to establish only a subset of the connections. NOTE If PRN is performed in combination with Call Establishment i.e. if no connections are existing/pending, the call might be released if the result of the PRN is negative.
- 10 -
9.2.4
Error handling The error handling mechanisms of ECMA-254 and ETS 300 796-1 apply. In addition, the following applies: If a CC entity receives invalid parameters appearing in a prenegotiationProposal, it may ignore and discard these parameters and continue processing the prenegotiationProposal.
9.2.5
Crossing of bearer establishment messages with prenegotiation-related APDUs In case of crossing of bearer establishment messages with messages containing prenegotiation-related APDUs, or in case of the crossing of two prenegotiation-related APDUs, both flows shall be further processed independently of each other. A user having sent or received a bearer connection establishment message, and then receiving a prenegotiationrelated APDU, may take the bearer establishment process into account for providing a prenegotiation-related response. However, this does not affect the formal protocol handling of the PRN APDUs, and is therefore outside the scope of this Standard.
9.3
Procedures at a transit CC entity The contents of the PRN operations and errors need not be interpreted by transit CC entities. Transit CC entities may either relay the contents of the PRN operations and errors or transit CC entities may also be involved in looking at various parameters of network relevance and may take action/possibly intervene in the PRN procedure. Possible actions of transit CC entities based on the interpretation of the contents of the PRN operations and errors are outside the scope of this Standard.
10
Interactions The specification of interactions with peer-to-peer call control are included in the specifications of subclause 9.2.1.1. Interactions with bearer connection establishment are specified in subclause 9.2.1.2.
11 11.1
Interworking with networks not supporting PRN Calls from other networks to a network supporting PRN The interworking unit between both networks may decide to invoke PRN as specified above. The criteria to initiate PRN are outside the scope of this Standard.
11.2
Calls to other networks not supporting PRN The interworking unit may accept or reject a PRN request, depending on whether the capabilities being prenegotiated can be mapped on compatible services in the other network. NOTE It is assumed that the user is notified at call establishment level, that an interworking situation has occurred. Therefore, no need has been identified to provide any additional specific indication at PRN level beyond a generic reject.
12
SDL Diagrams The diagrams in this Standard use the Specification and Description Language defined in ITU-T Rec. Z.100. The diagrams represent the behaviour of a PRN protocol entity within an originating or terminating call control entity. Possible actions on PRN in a transit CC entity are outside the scope of this Standard. Figures 4 to 9 show the behaviour of a PRN protocol entity when PRN is invoked during the active phase of a call. If PRN is invoked in conjunction with call establishment the same behaviour and states apply in conjunction with the appropriate call states. Input signals from the left and output signals to the left represent primitives to and from the PRN service user. Alsotimer expiry is indicated by an input signal from the left. Input signals from the right and output signals to the right represent APDUs sent to and received from the peer call control entity.
- 11 -
The following abbreviations are used: inv.
invoke APDU
res.
return result APDU
err.
return error APDU
rej.
reject APDU
PRN
Prenegotiate
PRN-Alert
Prenegotiation-Alert
req.
request primitive
ind.
indication primitive
resp.
response primitive
conf.
confirm primitive
(-)
negative response/confirmation
(+)
positive response/confirmation
Telecommunication service user
Outgoing PRN ASE
Incoming PRN ASE
ROSE CO-ORD
Figure 3 - Block diagram
- 12 -
Table 2 - Signal Routes CO-ORD_to_Outgoing-PRN-ASE Primitives: PRN_request
Incoming-PRN-ASE_to_CO-ORD Primitives: PRN_indication
APDUs: prenegotiationAlert_invoke preNegotiate_return_result preNegotiate_return_error preNegotiate_reject
APDUs: prenegotiationAlert_invoke preNegotiate_return_result preNegotiate_return_error
Outgoing-PRN-ASE_to_CO-ORD Primitives: PRN_confirm PRN_ALERT_indication ERROR_indication
CO-ORD_to_Incoming-PRN-ASE Primitives: PRN_response PRN_ALERT_request
APDUs: preNegotiate_invoke
APDUs: preNegotiate_invoke
Process Prenegotiation PRN_Idle
PRN req.
preNegotiate inv.
(optionally) start timer T1
PRN_ Initiated
Figure 4 - SDL for prenegotiation, outgoing direction
- 13 -
Process Prenegotiation
PRN_ Initiated
prenegotia tionAlert inv.
preNegotiate res.
preNegotiate err.
preNegotiate rej.
stop timer T1 (if running)
stop timer T1 (if running)
stop timer T1 (if running)
stop timer T1 (if running)
(optionally) start timer T2
PRN conf. (+)
PRN-Alert ind.
PRN_Idle
Note 1
PRN conf. (-)
Note 2
PRN_Idle
PRN_ Delivered
timer T1 expiry
implementation dependent action (out of scope)
PRN conf. (-)
PRN_Idle
NOTE 1 Connections may be established with the proposed parameters or with the alternative parameters proposed by the remote party. NOTE 2 Remote party incompatible or negotiated resources currently unavailable. Figure 5 - SDL for prenegotiation, outgoing direction
- 14 -
Process Prenegotiation
PRN_ Delivered
preNegotiate res.
preNegotiate err.
timer T2 expiry
stop timer T2 (if running)
stop timer T2 (if running)
implementation dependent action (out of scope)
PRN conf. (+)
PRN_Idle
Note 1
PRN conf. (-)
Note 2
PRN_Idle
PRN conf. (-)
PRN_Idle
NOTE 1 Connections may be established with the proposed parameters or with the alternative parameters proposed by the remote party. NOTE 2 Remote party incompatible or negotiated resources currently unavailable. Figure 6 - SDL for prenegotiation, outgoing direction
Process Prenegotiation PRN_Idle
preNegotiate inv.
PRN ind.
PRN_Present
Figure 7 - SDL for prenegotiation, incoming direction
- 15 -
Process Prenegotiation
PRN_Present
PRN-Alert req.
pre-negotiation request presented to human user
PRN resp. (+)
PRN resp. (-)
Note 3
prenegotia tionAlert inv.
preNegotiate res.
preNegotiate err.
PRN_ Received
PRN_Idle
PRN_Idle
NOTE 3 Prenegotiation request fully accepted, acceptance of a proposed alternative, or counterproposal made. NOTE 4 Not compatible or resources currently unavailable. Figure 8 - SDL for prenegotiation, incoming direction
Note 4
- 16 -
Process Prenegotiation
PRN_ Received
PRN resp. (+)
Note 3
PRN resp. (-)
preNegotiate res.
preNegotiate err.
PRN_Idle
PRN_Idle
Note 4
prenegotia tionAlert rej.
ERROR ind.
PRN_ Received
NOTE 3 Prenegotiation request fully accepted, acceptance of a proposed alternative, or counterproposal made. NOTE 4 Not compatible or resources currently unavailable. Figure 9 - SDL for prenegotiation, incoming direction
- 17 -
Annex A (informative)
Information flow diagrams
This annex shows typical information flows for PRN. The following conventions are used in the figures of this annex: -
the figures show APDUs exchanged between CC entities involved in PRN. Only APDUs relevant to PRN are shown;
-
the figures show protocol states related to PRN on the incoming and outgoing side of a CC entity;
-
the figures show the primitives to and from the PRN service user within the user CC which correspond to the exchanged APDUs.
A.1
Prenegotiation Originating CC
Transit CC
Transit CC
Terminating CC
PRN Idle
PRN Idle
PRN Idle
PRN Idle
Prenegotiate req
preNegotiate inv.
PRN Initiated
preNegotiate inv.
PRN Present / PRN Initiated
Prenegotiate conf
PRN Idle
preNegotiate res.
PRN Idle
preNegotiate inv.
PRN Present / PRN Initiated
preNegotiate res.
PRN Present
preNegotiate res.
PRN Idle
Figure A.1 - Example information flow for PRN
Prenegotiate ind
Prenegotiate resp
PRN Idle
- 18 -
A.2
PRN with optional PRN Alert Originating CC
Transit CC
Transit CC
Terminating CC
PRN Idle
PRN Idle
PRN Idle
PRN Idle
Prenegotiate req
preNegotiate inv.
PRN Initiated
preNegotiate inv.
PRN Present / PRN Initiated
prenegotiationAlert inv.
Preneg.-Alert req
PRN Delivered
preNegotiate res.
Prenegotiate conf
PRN Idle
PRN Idle
PRN Present / PRN Initiated
prenegotiationAlert inv.
PRN Deliv. / PRN Rec.
preNegotiate inv.
PRN Present
prenegotiationAlert inv.
PRN Deliv. /
Prenegotiate ind
Preneg.-Alert req
PRN Received
PRN Rec.
preNegotiate res.
PRN Idle
preNegotiate res.
Prenegotiate resp
PRN Idle
Figure A.2 - Example information flow for PRN with optional PRN alert
- 19 -
Annex B (informative)
Object identifiers defined in this Standard
This annex lists the object identifier values assigned in this Standard and data types, values and macros that are exported from any modules identified by those values. All the object identifiers in this Standard are defined using the ITU-T object identifier tree. This means that each object identifier value is assigned in the tree: prnObjectIdTree ::= itu-t recommendation q 2984 Table B.1 lists the module number values and the data types, values and Macros which are exported from these modules. Table B.1 - ASN.1 Module Object identifiers used in this Standard Object Identifier
Reference
{ prnObjectIdTree prenegotiation-operations-and-errors (1) }
Table 1
{ prnObjectIdTree prenegotiation-operations-definitions (2) }
Table 1
{ prnObjectIdTree prenegotiation-operations-errors (3) }
Table 1
Notes Exports: preNegotiate, PrenegotiationProposal, prenegotiationAlert
- 20 -
- 21 -
Annex C (informative)
Bibliography
The following material, though not specifically referenced in the body of this Standard (or not publicly available), gives supporting information. DEG/SPS-05134
Broadband Integrated Services Digital Network (B-ISDN); Digital Subscriber Signalling System No. two (DSS2) and Broadband QSIG (B-QSIG) protocols; Generic concepts for the support of multiconnection calls in a separated environment; Part 1: Protocol specification
.
.
Free printed copies can be ordered from: ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland Fax: Email:
+41 22 849.60.01 [email protected]
Files of this Standard can be freely downloaded from the ECMA web site (www.ecma.ch). This site gives full information on ECMA, ECMA activities, ECMA Standards and Technical Reports.
ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland See inside cover page for obtaining further soft or hard copies.