SIST EN 301 061-1:2001
(Main)Integrated Services Digital Network (ISDN); Digital Subscriber Signalling System No. one (DSS1) protocol; Generic functional protocol for the support of supplementary services at the b service entry point for Virtual Private Network (VPN) applications; Part 1: Protocol specification
Integrated Services Digital Network (ISDN); Digital Subscriber Signalling System No. one (DSS1) protocol; Generic functional protocol for the support of supplementary services at the b service entry point for Virtual Private Network (VPN) applications; Part 1: Protocol specification
To enhance the DSS1 protocol to support VPN generic functional protocol at the b service entry point
Digitalno omrežje z integriranimi storitvami (ISDN) - Protokol digitalne naročniške signalizacije št. 1 (DSS1) - Generični funkcijski protokol za podporo dopolnilnih storitev v vstopni točki "b" storitve za aplikacije navideznega zasebnega omrežja (VPN) - 1. del: Specifikacija protokola
General Information
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Integrated Services Digital Network (ISDN); Digital Subscriber Signalling System No. one (DSS1) protocol; Generic functional protocol for the support of supplementary services at the b service entry point for Virtual Private Network (VPN) applications; Part 1: Protocol specification33.080Digitalno omrežje z integriranimi storitvami (ISDN)Integrated Services Digital Network (ISDN)ICS:Ta slovenski standard je istoveten z:EN 301 061-1 V1.2.23SIST EN 301 061-1:en01-GHFHPEHU3SIST EN 301 061-1:SLOVENSKI
STANDARD
EN 301 061-1 V1.2.2 (1998-04)European Standard (Telecommunications series)Integrated Services Digital Network (ISDN);Digital Subscriber Signalling System No. one (DSS1) protocol;Generic functional protocol for the support ofsupplementary services at the "b" service entry point forVirtual Private Network (VPN) applications;Part 1: Protocol specificationSIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)2ReferenceDEN/SPS-05110-1 (9to90ipc.PDF)KeywordsDSS1, generic, ISDN, supplementary service,VPNETSIPostal addressF-06921 Sophia Antipolis Cedex - FRANCEOffice address650 Route des Lucioles - Sophia AntipolisValbonne - FRANCETel.: +33 4 92 94 42 00
Fax: +33 4 93 65 47 16Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/88Internetsecretariat@etsi.frhttp://www.etsi.frhttp://www.etsi.orgCopyright NotificationNo part may be reproduced except as authorized by written permission.The copyright and the foregoing restriction extend to reproduction in all media.© European Telecommunications Standards Institute 1998.All rights reserved.SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)3ContentsIntellectual Property Rights.5Foreword.51Scope.62Normative references.63Definitions and abbreviations.73.1Definitions.73.2Abbreviations.74Coexistence of generic protocols for the control of supplementary services.84.1Support of various generic protocols.84.2Coexistence of generic protocols.84.3Arrangements by which coexistence of protocols may be supported by a network.85General principles applied for the functional control of supplementary services.85.1Introduction.85.2Scope of the procedures.85.3Categories of procedures.85.4VPN services in the context of CN.96Control of supplementary services using the separate message approach.97Control of supplementary services using the common information element approach.97.1General.97.1.1Introduction.97.1.2Scope of the procedures.97.1.3Distinction between public network and VPN context.97.2Procedures applicable for signalling in a VPN context.107.2.1Transport of components.107.2.1.1Bearer-related transport mechanism.107.2.1.1.1Protocol control requirements.107.2.1.1.2Generic Functional Transport (GFT)-Control requirements.107.2.1.2Connection-oriented bearer-independent transport mechanism.117.2.1.2.1Protocol control requirements.117.2.1.2.1.1Connection establishment at the originating interface.117.2.1.2.1.1.1Connection request.117.2.1.2.1.1.2Invalid connection information.117.2.1.2.1.1.3Call proceeding.127.2.1.2.1.1.4Connection connected.127.2.1.2.1.1.5Connection rejected.127.2.1.2.1.2Connection establishment at the destination interface.127.2.1.2.1.2.1Incoming connection.137.2.1.2.1.2.2Connection confirmation.137.2.1.2.1.2.3Called user clearing during incoming connection establishment.137.2.1.2.1.2.4Connection failure.137.2.1.2.1.2.5Connection accept.137.2.1.2.1.2.6Active indication.137.2.1.2.1.3Connection clearing.147.2.1.2.1.3.1Exception conditions.147.2.1.2.1.3.2Clearing initiated by the user.147.2.1.2.1.3.3Clearing initiated by the network.157.2.1.2.1.3.4Clear collision.157.2.1.2.1.4Interaction with restart procedure.157.2.1.2.1.5Interaction with call rearrangements.157.2.1.2.1.6Handling of error conditions.157.2.1.2.1.7Protocol timer values.167.2.1.2.2GFT-Control requirements.16SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)47.2.1.3Connectionless bearer-independent transport mechanism.168Generic notification procedures applicable in a VPN context.168.1Categories of notifications.168.2Non-standardized notifications.168.3Protocol control requirements.178.4GFT-Control requirements.179Application layer requirements.179.1Coordination Function requirements.179.2ROSE requirements.179.3ACSE requirements.179.4DSE requirements.179.5Non-standardized operations and non-standardized additions to standardised operations.1710Other generic procedures.1811Coding requirements.1811.1Message functional definitions and content.1811.1.1Messages for bearer-related signalling.1811.1.1.1FACILITY.1811.1.1.2NOTIFY.1911.1.2Messages for bearer-independent, connection-oriented signalling.1911.1.2.1CALL PROCEEDING.1911.1.2.2CONNECT.2011.1.2.3CONNECT ACKNOWLEDGE.2011.1.2.4FACILITY.2011.1.2.5RELEASE.2111.1.2.6RELEASE COMPLETE.2211.1.2.7SETUP.2311.1.2.8STATUS.2311.1.2.9STATUS ENQUIRY.2411.2General message format and information element coding.2411.2.1Facility.2411.2.2Notification indicator.2511.2.3Bearer capability.2611.2.4Channel identification.26Annex A (normative):Dynamic descriptions.28A.1Dynamic description of the Hold and Retrieve functions.28A.2Dynamic description of the status request procedure.28A.3Dynamic description of the supplementary service management function.28A.4Dynamic description of the connection oriented bearer independent transport mechanism.28Annex B (normative):Formal definition of data types.29Annex C (normative):Flow control.30History.31SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)5Intellectual Property RightsIPRs essential or potentially essential to the present document may have been declared to ETSI. The informationpertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be foundin ETR 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect ofETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the ETSIWeb server (http://www.etsi.fr/ipr or http://www.etsi.org/ipr).Pursuant to the ETSI Interim IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. Noguarantee can be given as to the existence of other IPRs not referenced in ETR 314 (or the updates on the ETSI Webserver) which are, or may be, or may become, essential to the present document.ForewordThis European Standard (Telecommunications series) has been produced by ETSI Technical Committee SignallingProtocols and Switching (SPS).The present document is part 1 of a multi-part European Standard (Telecommunications series) covering the IntegratedServices Digital Network (ISDN); Digital Subscriber Signalling System No. one (DSS1) protocol; Generic functionalprotocol for the support of supplementary services for Virtual Private Network (VPN) applications, as identified below:Part 1:"Protocol specification";Part 2:"Protocol Implementation Conformance Statement (PICS) proforma specification";Part 3:"Test Suite Structure and Test Purposes (TSS&TP), user";Part 4:"Abstract Test Suite (ATS), user";Part 5:"Test Suite Structure and Test Purposes (TSS&TP), network";Part 6:"Abstract Test Suite (ATS), network".National transposition datesDate of adoption of this EN:3 April 1998Date of latest announcement of this EN (doa):31 July 1998Date of latest publication of new National Standardor endorsement of this EN (dop/e):31 January 1999Date of withdrawal of any conflicting National Standard (dow):31 January 1999SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)61ScopeThe present document specifies the generic functional protocol for the pan-European Integrated Services DigitalNetwork (ISDN) applicable at the "b" service entry point (as defined in EN 301 060-1 [3]). It is part of the DigitalSubscriber Signalling System No. one (DSS1) protocol.The generic functional protocol is based on the Facility information element and the FACILITY message, as well as onother specific functional messages. The protocol is symmetrical, and it is applicable to both basic and primary rateinterfaces.The generic functional protocol defined in the present document provides the means to exchange signalling informationfor the control of supplementary services over a Virtual Private Network (VPN). It does not by itself control anysupplementary service but rather provides generic services to specific supplementary service control entities.The application of the present document to individual supplementary services is outside the scope of the presentdocument and is defined in those standards which specify the individual supplementary services.Further part(s) of the present document specify the method of testing required to identify conformance to the presentdocument.The present document is applicable only to point-to-point access configurations.NOTE 1:The exchange of signalling information relating to the "b" service entry point is distinguished from theexchange of signalling information that is used to access public network services at the T reference point.The generic functional protocol applicable in a public network context is supported in accordance with therequirements of EN 300 196-1 [1]. The generic functional protocol specifically applicable in a VPNcontext is supported in accordance with the present document. The requirements have been defined suchthat both contexts can coexist on the same access, and this is expected to be a typical implementation.There is no requirement that when the provisions of the present document are implemented, the exchangeof signalling information relating to the T reference point also need to be implemented on the sameaccess. Where both contexts are implemented, the access resources are common to both contexts.NOTE 2:A service provider may support supplementary services applicable for public network calls in a VPNcontext. In this case the applicability of the individual public network supplementary services to a call in aVPN context is beyond the scope of the present document.2Normative referencesReferences may be made to:a)specific versions of publications (identified by date of publication, edition number, version number, etc.), inwhich case, subsequent revisions to the referenced document do not apply; orb)all versions up to and including the identified version (identified by "up to and including" before the versionidentity); orc)all versions subsequent to and including the identified version (identified by "onwards" following the versionidentity); ord)publications without mention of a specific version, in which case 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 samenumber.[1]EN 300 196-1: "Integrated Services Digital Network (ISDN); Generic functional protocol for thesupport of supplementary services; Digital Subscriber Signalling System No. one (DSS1) protocol;Part 1: Protocol specification".[2]EN 300 403-1: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling SystemNo. one (DSS1) protocol; Signalling network layer for circuit-mode basic call control; Part 1:Protocol specification [ITU-T Recommendation Q.911 (1993), modified]".SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)7[3]EN 301 060-1: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling SystemNo. one (DSS1) protocol; Basic call applications: enhancement at the "b" service entry point forVirtual Private Network (VPN) applications; Part 1: Protocol specification".[4]ETS 300 402-2: "Integrated Services Digital Network (ISDN); Digital Subscriber SignallingSystem No. one (DSS1) protocol; Data link layer; Part 2: General protocol specification [ITU-TRecommendation Q.921 (1993), modified]".[5]ISO/IEC 11582 (1995): "Information technology - Telecommunication and information exchangebetween systems - Private Integrated Services Network - Generic functional protocol for thesupport of supplementary services - Inter-exchange signalling procedures and protocol".[6]ITU-T Recommendation X.219 (1988): "Remote operations: Model, notation and servicedefinition".[7]ITU-T Recommendation X.229 (1988): "Remote operations: Protocol specification".[8]ISO/IEC 15056 (1997): "Information technology - Telecommunications and information exchangebetween systems - Private Integrated Services Network - Inter-exchange signalling protocol -Transit counter additional network feature".3Definitions and abbreviations3.1DefinitionsClause 3 of EN 300 196-1 [1] shall apply with the following addition:Corporate telecommunication Network (CN): Consists of sets of equipment (Customer Premises Equipment and/orCustomer Premises Network) which are located at geographically dispersed locations and are interconnected to providenetworking services to a defined group of users.NOTE 1:The ownership of the equipment is not relevant to this definition.NOTE 2:In the present document, even equipment which is not geographically dispersed (e.g. a single PrivateIntegrated services Network eXchange (PINX) or Centrex-provided services to users at a single location)may form a CN.Call control message: A message as defined in EN 301 060-1 [3], subclause 7.1, which on sending or receipt causes achange of the call state at either the network or the user. Call control messages also include the INFORMATIONmessage and PROGRESS message.3.2AbbreviationsFor the purposes of the present document, the following abbreviations apply:ACSEAssociation Control Service ElementBCBearer CapabilityCNCorporate telecommunication NetworkDSEDialogue Service ElementDSS1Digital Subscriber Signalling System No. oneGFTGeneric Functional TransportISDNIntegrated Services Digital NetworkNCICSNetworked Call Independent, Connection-oriented SignallingNFENetwork Facility ExtensionNT2Network Termination 2
PINXPrivate Integrated services Network eXchangePSS1Private Signalling System No. OneTETerminal EquipmentVPNVirtual Private NetworkSIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)84Coexistence of generic protocols for the control ofsupplementary services4.1Support of various generic protocolsSubclause 5.1 of EN 300 196-1 [1] shall apply.4.2Coexistence of generic protocolsSubclause 5.2 of EN 300 196-1 [1] shall apply.In addition, the protocol described in the present document incorporates the functionality of the generic functionalprotocol described in EN 300 196-1 [1].4.3Arrangements by which coexistence of protocols may besupported by a networkSubclause 5.3 of EN 300 196-1 [1] shall apply.5General principles applied for the functional control ofsupplementary services5.1IntroductionThis subclause specifies the general principles applied for the functional control of supplementary services at the "b"service entry point (as defined in EN 301 060-1 [3]). The generic protocol utilizes functions and services provided byEN 300 403-1 [2] basic call procedures, as extended by EN 301 060-1 [3], and the functions of the data link layer asdefined in ETS 300 402-2 [4].5.2Scope of the proceduresThe procedures defined in the present document specify the basic methodology for the control (e.g. invocation,notification, deactivation, etc.) of supplementary services. The procedures are independent of whether or not the user-network interface is at a basic or primary rate access.5.3Categories of proceduresTwo categories of procedures are defined.The first category deals with the control of supplementary services in a public network context. For this category,subclause 6.3 of EN 300 196-1 [1] shall apply.The second category deals with the control of supplementary services in a VPN context.The entity that establishes a signalling relation shall indicate by means of the presence or absence of the VPN indicatorinformation element in which context the signalling information is to be interpreted. The VPN indicator informationelement and the associated procedures are described in EN 301 060-1 [3] and in subclause 7.1.3 of the presentdocument.SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)95.4VPN services in the context of CNSee subclause 5.1 of EN 301 060-1 [3].6Control of supplementary services using the separatemessage approachThese procedures shall be used only in a public network context. Clause 7 of EN 300 196-1 [1] shall apply.7Control of supplementary services using the commoninformation element approach7.1General7.1.1IntroductionIn the common information element approach, the Facility information element is used to transport information for thecontrol of supplementary services, conveying components as application-oriented elements complemented by thenecessary procedures for operations and transport mechanisms. Operations and transport mechanisms may either berelated to a connection or may be used independently of a connection.The common information element approach is modelled as remote operations as specified in ITU-T RecommendationsX.219 [6] and X.229 [7]. According to this model, one entity requests that a particular operation be performed whilst theresponding entity attempts to perform the operation and responds to the invoking entity. Therefore an operation of thecommon information element approach is regarded as a request/reply interaction, supported by the application functionand carried out within the context of an application association.An error is used to report the unsuccessful outcome of an operation. For each operation the appropriate errors, ifrequired, need to be indicated.7.1.2Scope of the proceduresSubclause 8.1.2 of EN 300 196-1 [1] shall apply.7.1.3Distinction between public network and VPN contextAn indication is necessary to distinguish between a public network or a VPN context.If an entity sends a message that establishes a call reference in a VPN context, it shall include a VPN indicatorinformation element in this message. If an entity sends such a message in a public network context, it shall not include aVPN indicator information element in this message.If an entity receives a message that establishes a call reference, and this message contains a VPN indicator informationelement, then the procedures for signalling in a VPN context shall apply for all messages that use this call reference.If an entity receives a message that establishes a call reference, and this message does not contain a VPN indicatorinformation element, then the procedures for signalling in a public network context shall apply for all messages that usethis call reference.If an entity receives a FACILITY message with the dummy call reference, and this message does not contain a VPNindicator information element, then the procedures for signalling in a public network context shall apply.SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)10If an entity receives a FACILITY message with the dummy call reference, and this message contains a VPN indicatorinformation element, then the procedures for signalling in a VPN context shall apply.NOTE:The present document does not specify the use of the dummy call reference in the FACILITY message.The receipt of a FACILITY message with the dummy call reference in a VPN context is an error, anderror handling procedures are applied.7.2Procedures applicable for signalling in a VPN context7.2.1Transport of components7.2.1.1Bearer-related transport mechanism7.2.1.1.1Protocol control requirementsThis subclause defines the transport of components using the messages for the establishment and the clearing of calls.The procedures for basic call control are described in EN 301 060-1 [3]. These procedures are not influenced by thecomponents carried. Bearer-related transport procedures and operations shall follow the specified procedures andtransport capabilities of bearer connections according to EN 301 060-1 [3]. The SETUP message shall contain the VPNindicator information element.For bearer-related transport of components, the call state of the bearer connection shall be in a state (or about to enter astate) other than the Null state (U0, N0). For transport, any call control message as defined in EN 301 060-1 [3] (exceptthe STATUS and STATUS ENQUIRY messages), or the FACILITY message defined in subclause 11.1.1.1 of thepresent document, may be used to carry the components in a Facility information element. These messages shall use thecall reference of the bearer connection.NOTE:If the call establishment request has not reached the addressed PINX, the component included in theFACILITY message may not reach its intended destination. There is no requirement for any entity toavoid this by storing the information.For general rules, format and coding of call reference values, subclause 4.3 of EN 300 403-1 [2] shall apply.The call reference provides the means to correlate messages belonging to the same signalling transaction of aconnection. When a supplementary service affects more than one connection, different call references are used toidentify each connection individually. This implies the use of different messages in order to manage each connectionseparately.The implicit call-control association provided by an EN 300 403-1 [2] call reference shall always be cleared when aconnection is released.The Cause information element shall only be used to report information element content errors outside the componentportion of the Facility information element (octets 1 - 3). When no protocol error outside the component portion isfound, the Cause information element shall convey cause #31, "normal unspecified". For protocol errors in thecomponent portion of the Facility information element (octets 3.1, etc) see subclauses 7.2.1.1.2 and 9.1.7.2.1.1.2Generic Functional Transport (GFT)-Control requirementsFor those nodal entities that terminate the GFT-Control protocol, subclause 7.1.2 of ISO/IEC 11582 [5] shall apply.NOTE:For those nodal entities that do not terminate the GFT-Control protocol, the Facility information elementwill be transferred to the next entity regardless of the contents of the destinationEntity element of theNetwork Facility Extension (NFE). Examples of this type of nodal entity include a Transit PINX withreduced functionality as well as a Relay Node.SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)117.2.1.2Connection-oriented bearer-independent transport mechanism7.2.1.2.1Protocol control requirements7.2.1.2.1.1Connection establishment at the originating interfaceBefore these procedures are invoked, a reliable data link connection shall be established between the user (TE/NT2) andthe network. All layer 3 messages shall be sent to the data link layer using a DL-DATA request primitive, using the datalink services described in ETS 300 402-2 [4].7.2.1.2.1.1.1Connection requestTo initiate a Networked Call Independent, Connection-oriented Signalling (NCICS) connection establishment, the usershall transfer a SETUP message across the user-network interface. Following the transmission of the SETUP message,the connection shall be considered by the user to be in the Call Initiated state. The SETUP message shall always containa call reference, selected according to the procedures given in subclause 4.3 of EN 300 403-1 [2]. In selecting a callreference, the dummy call reference value shall not be used.Furthermore the SETUP message shall contain the Channel identification information element and all of the information(i.e. address and facility requests) necessary for connection establishment. Refer to subclause 11.1.2.7 for the contents ofthe SETUP message.The physical PINX at the originating interface shall include the VPN indicator information element in the SETUPmessage.If the network receives a VPN indicator information element that does not contain a CN identifier in a SETUP message,and a CN identifier is registered as a default for the access, then the network shall use the default CN identifier. If theVPN indicator information element does not contain a CN identifier and there is no CN identifier registered as a defaultfor the access, then the network shall reject the request with cause #50, "requested facility not subscribed". If the VPNindicator information element indicates a CN which is not associated with the access, then the network shall reject therequest with cause #50, "requested facility not subscribed".The user shall start timer T303 upon transmission of the SETUP message and enter the Call Initiated state. If the userdoes not receive a response to the SETUP message prior to the expiry of timer T303, the user shall retransmit theSETUP message and restart timer T303. If the user does not receive any response to the retransmitted SETUP messageprior to the expiration of timer T303, then the user shall send a RELEASE COMPLETE message to the network withcause #102, recovery on timer expiry and internally clear the NCICS connection.On receipt of a bearer-independent SETUP message, the network shall:-if the request is valid and can be processed, follow the procedures of subclause 7.2.1.2.1.1.3; or-if the request is invalid or cannot be accepted, follow the procedures of subclause 7.2.1.2.1.1.2.The FACILITY message shall be exchanged only once the NCICS connection has reached the Active state.7.2.1.2.1.1.2Invalid connection informationIf the NCICS connection request is invalid or cannot be accepted, the network shall:-return a RELEASE COMPLETE message;-release the call reference; and-remain in the Null state.The RELEASE COMPLETE message shall contain an appropriate cause value. If the network determines that a bearer-independent signalling connection is not authorized or available, cause #63, "service or option not available,unspecified", shall be used.SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)127.2.1.2.1.1.3Call proceedingIf the NCICS connection request is valid and can be processed, the network shall:-return a CALL PROCEEDING message;-enter the Outgoing Call Proceeding state; and-attempt to establish the NCICS connection towards the terminating entity (for example, see subclause7.2.1.2.1.2).Upon receipt of the CALL PROCEEDING message, the user shall:-stop timer T303;-enter the Outgoing Call Proceeding state; and-start timer T310.If timer T310 expires, the user shall initiate NCICS connection clearing towards the network in accordance withsubclause 7.2.1.2.1.3 using cause # 102, "recovery on timer expiry".7.2.1.2.1.1.4Connection connectedUpon the network receiving an indication that the NCICS connection request has been accepted, the network shall senda CONNECT message across the originating user-network interface, and either:-enter the Active state; or-start timer T313 and enter the Connect Request state.This message indicates to the originating user that a NCICS connection has been established through the network.On receipt of the CONNECT message, the originating user shall:-send a CONNECT ACKNOWLEDGE message;-stop timer T310; and-enter the Active state.On receipt of a CONNECT ACKNOWLEDGE message, the network shall:-if it perceives the NCICS connection to be in the Active state, take no action; or-if in the Connect Request state, stop timer T313 and enter the Active state.If timer T313 expires before a CONNECT ACKNOWLEDGE message is received, the network shall initiate NCICSconnection clearing with a RELEASE message using cause #102, „recovery on timer expiry“.7.2.1.2.1.1.5Connection rejectedUpon receiving an indication that the network or the terminating entity is unable to accept the NCICS connectionrequest, the network shall initiate NCICS connection clearing at the originating user-network interface as described insubclause 7.2.1.2.1.3, using the cause provided by the terminating network or the terminating entity.7.2.1.2.1.2Connection establishment at the destination interfaceBefore these procedures are invoked, a reliable data link connection shall be established between the user (TE/NT2) andthe network. All layer 3 messages shall be sent to the data link layer using a DL-DATA request primitive, using the datalink services described in ETS 300 402-2 [4].The call reference contained in all messages exchanged across the user-network interface shall contain the call referencevalue specified in the SETUP message delivered by the network. In selecting a call reference, the dummy call referenceshall not be used in conjunction with NCICS connections.SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)137.2.1.2.1.2.1Incoming connectionTo initiate a NCICS connection establishment, the network shall
transfer a SETUP message across the interface. Referto subclause 11.1.2.7 for the contents of the SETUP message. The network shall include the Channel identificationinformation element and the VPN indicator information element containing a CN identifier in the SETUP message.If the PINX receives a SETUP message and can determine that the indicated CN is not associated with the access, thenthe connection shall be rejected with cause #50 „Requested facility not subscribed“. After sending the SETUP message,the network shall start timer T303, and enter the Call Present state. If the network does not receive a response to theSETUP message prior to the expiry of timer T303, the network shall retransmit the SETUP message and restart timerT303.The FACILITY message can only be exchanged when the NCICS connection is in the Active state.7.2.1.2.1.2.2Connection confirmationWhen the user determines that sufficient NCICS connection set-up information has been received, the user shall respondwith a CALL PROCEEDING message and enter the Incoming Call Proceeding state.Upon receipt of the CALL PROCEEDING message, the network shall:-stop timer T303;-enter the Incoming Call Proceeding state; and-start timer T310.7.2.1.2.1.2.3Called user clearing during incoming connection establishmentIf a RELEASE or RELEASE COMPLETE message is received before a CONNECT message has been received, thenetwork shall:-stop timer T303 or T310 (if running);-continue to clear the terminating entity as described in subclause 7.2.1.2.1.3; and-clear the NCICS connection to the originating entity with the cause received in the RELEASE or RELEASECOMPLETE message.7.2.1.2.1.2.4Connection failureIf the network does not receive any response to the retransmitted SETUP message prior to the expiration of timer T303,then the network shall initiate clearing procedures towards the originating entity with cause #18, "no user responding".The network shall also initiate clearing procedures towards the terminating entity in accordance withsubclause 7.2.1.2.1.3, using cause #102, "recovery on timer expiry".If the network has received a CALL PROCEEDING message, but does not receive a CONNECT, RELEASE, orRELEASE COMPLETE message prior to the expiration of timer T310, then the network shall initiate clearing towardsthe terminating entity. The terminating entity shall be cleared in accordance with subclause 7.2.1.2.1.3, using cause#102, "recovery on timer expiry". In addition, the network shall initiate clearing towards the originating entity inaccordance with subclause 7.2.1.2.1.3, using cause #18, "no user responding".7.2.1.2.1.2.5Connection acceptTo indicate acceptance of an incoming NCICS connection, the user shall send a CONNECT message to the network.Upon sending the CONNECT message, the user may start timer T313.7.2.1.2.1.2.6Active indicationOn receipt of a CONNECT message, the network shall:-stop timers T303 and T310 (if running);SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)14-complete the NCICS connection;-send a CONNECT ACKNOWLEDGE message to the terminating entity;-initiate procedures to send a CONNECT message towards the originating entity; and-enter the Active state.The CONNECT ACKNOWLEDGE message indicates completion of the NCICS connection. There is no guarantee ofan end-to-end connection until the originating entity receives a CONNECT message. Upon receipt of the CONNECTACKNOWLEDGE message, the user shall stop timer T313, if running, and enter the Active state.If timer T313 expires prior to receipt of a CONNECT ACKNOWLEDGE message, the user shall initiate clearing inaccordance with subclause 7.2.1.2.1.3, using cause #102, "recovery on timer expiry".The exchange of FACILITY messages can start once the NCICS connection has reached the Active state.7.2.1.2.1.3Connection clearing7.2.1.2.1.3.1Exception conditionsTo clear a NCICS connection , the user or the network shall send a RELEASE message and follow the proceduresdefined in subclauses 7.2.1.2.1.3.2 and 7.2.1.2.1.3.3 respectively. The only exception to the above rule is the following:in response to a SETUP message, provided no other response has previously been sent, the user or network can reject aNCICS connection by:-responding with a RELEASE COMPLETE message;-releasing the call reference; and-entering the Null state.7.2.1.2.1.3.2Clearing initiated by the userApart from the exception identified in subclauses 7.2.1.2.1.3.1 and 7.2.1.2.1.6, to initiate clearing, the user shall:-send a RELEASE message;-start timer T308; and-enter the Release Request state.On receipt of a RELEASE message, the network shall:-send a RELEASE COMPLETE message;-release the call reference; and-enter the Null state.On receipt of the RELEASE COMPLETE message the user shall:-stop timer T308;-release the call reference; and-enter the Null state.If timer T308 expires for the first time, the user shall retransmit the RELEASE message and restart timer T308. Inaddition, the user may include a second Cause information element with cause #102, "recovery on timer expiry". If noRELEASE COMPLETE message is received from the network before timer T308 expires a second time, the user shallrelease the call reference and enter the Null state.SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)157.2.1.2.1.3.3Clearing initiated by the networkApart from the exception identified in subclauses 7.2.1.2.1.3.1 and 7.2.1.2.1.6, to initiate clearing, the network shall:-send a RELEASE message;-start timer T308; and-enter the Release Request state.On receipt of a RELEASE message, the user shall:-send a RELEASE COMPLETE message;-release the call reference; and-enter the Null state.On receipt of the RELEASE COMPLETE message the network shall:-stop timer T308;-release the call reference; and-enter the Null state.If timer T308 expires for the first time, the network shall retransmit the RELEASE message and restart timer T308. Inaddition, the network may include a second Cause information element with cause #102, "recovery on timer expiry". Ifno RELEASE COMPLETE message is received from the user before timer T308 expires a second time, the networkshall release the call reference and enter the Null state.7.2.1.2.1.3.4Clear collisionClear collision can occur when both sides simultaneously transfer RELEASE messages related to the same call referencevalue. The entity receiving such a RELEASE message whilst within the Release Request state shall stop tim
...
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Integrated Services Digital Network (ISDN); Digital Subscriber Signalling System No. one (DSS1) protocol; Generic functional protocol for the support of supplementary services at the b service entry point for Virtual Private Network (VPN) applications; Part 1: Protocol specification33.080Digitalno omrežje z integriranimi storitvami (ISDN)Integrated Services Digital Network (ISDN)ICS:Ta slovenski standard je istoveten z:EN 301 061-1 Version 1.2.2SIST EN 301 061-1:2001en01-februar-2001SIST EN 301 061-1:2001SLOVENSKI
STANDARD
EN 301 061-1 V1.2.2 (1998-04)European Standard (Telecommunications series)Integrated Services Digital Network (ISDN);Digital Subscriber Signalling System No. one (DSS1) protocol;Generic functional protocol for the support ofsupplementary services at the "b" service entry point forVirtual Private Network (VPN) applications;Part 1: Protocol specificationSIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)2ReferenceDEN/SPS-05110-1 (9to90ipc.PDF)KeywordsDSS1, generic, ISDN, supplementary service,VPNETSIPostal addressF-06921 Sophia Antipolis Cedex - FRANCEOffice address650 Route des Lucioles - Sophia AntipolisValbonne - FRANCETel.: +33 4 92 94 42 00
Fax: +33 4 93 65 47 16Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/88Internetsecretariat@etsi.frhttp://www.etsi.frhttp://www.etsi.orgCopyright NotificationNo part may be reproduced except as authorized by written permission.The copyright and the foregoing restriction extend to reproduction in all media.© European Telecommunications Standards Institute 1998.All rights reserved.SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)3ContentsIntellectual Property Rights.5Foreword.51Scope.62Normative references.63Definitions and abbreviations.73.1Definitions.73.2Abbreviations.74Coexistence of generic protocols for the control of supplementary services.84.1Support of various generic protocols.84.2Coexistence of generic protocols.84.3Arrangements by which coexistence of protocols may be supported by a network.85General principles applied for the functional control of supplementary services.85.1Introduction.85.2Scope of the procedures.85.3Categories of procedures.85.4VPN services in the context of CN.96Control of supplementary services using the separate message approach.97Control of supplementary services using the common information element approach.97.1General.97.1.1Introduction.97.1.2Scope of the procedures.97.1.3Distinction between public network and VPN context.97.2Procedures applicable for signalling in a VPN context.107.2.1Transport of components.107.2.1.1Bearer-related transport mechanism.107.2.1.1.1Protocol control requirements.107.2.1.1.2Generic Functional Transport (GFT)-Control requirements.107.2.1.2Connection-oriented bearer-independent transport mechanism.117.2.1.2.1Protocol control requirements.117.2.1.2.1.1Connection establishment at the originating interface.117.2.1.2.1.1.1Connection request.117.2.1.2.1.1.2Invalid connection information.117.2.1.2.1.1.3Call proceeding.127.2.1.2.1.1.4Connection connected.127.2.1.2.1.1.5Connection rejected.127.2.1.2.1.2Connection establishment at the destination interface.127.2.1.2.1.2.1Incoming connection.137.2.1.2.1.2.2Connection confirmation.137.2.1.2.1.2.3Called user clearing during incoming connection establishment.137.2.1.2.1.2.4Connection failure.137.2.1.2.1.2.5Connection accept.137.2.1.2.1.2.6Active indication.137.2.1.2.1.3Connection clearing.147.2.1.2.1.3.1Exception conditions.147.2.1.2.1.3.2Clearing initiated by the user.147.2.1.2.1.3.3Clearing initiated by the network.157.2.1.2.1.3.4Clear collision.157.2.1.2.1.4Interaction with restart procedure.157.2.1.2.1.5Interaction with call rearrangements.157.2.1.2.1.6Handling of error conditions.157.2.1.2.1.7Protocol timer values.167.2.1.2.2GFT-Control requirements.16SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)47.2.1.3Connectionless bearer-independent transport mechanism.168Generic notification procedures applicable in a VPN context.168.1Categories of notifications.168.2Non-standardized notifications.168.3Protocol control requirements.178.4GFT-Control requirements.179Application layer requirements.179.1Coordination Function requirements.179.2ROSE requirements.179.3ACSE requirements.179.4DSE requirements.179.5Non-standardized operations and non-standardized additions to standardised operations.1710Other generic procedures.1811Coding requirements.1811.1Message functional definitions and content.1811.1.1Messages for bearer-related signalling.1811.1.1.1FACILITY.1811.1.1.2NOTIFY.1911.1.2Messages for bearer-independent, connection-oriented signalling.1911.1.2.1CALL PROCEEDING.1911.1.2.2CONNECT.2011.1.2.3CONNECT ACKNOWLEDGE.2011.1.2.4FACILITY.2011.1.2.5RELEASE.2111.1.2.6RELEASE COMPLETE.2211.1.2.7SETUP.2311.1.2.8STATUS.2311.1.2.9STATUS ENQUIRY.2411.2General message format and information element coding.2411.2.1Facility.2411.2.2Notification indicator.2511.2.3Bearer capability.2611.2.4Channel identification.26Annex A (normative):Dynamic descriptions.28A.1Dynamic description of the Hold and Retrieve functions.28A.2Dynamic description of the status request procedure.28A.3Dynamic description of the supplementary service management function.28A.4Dynamic description of the connection oriented bearer independent transport mechanism.28Annex B (normative):Formal definition of data types.29Annex C (normative):Flow control.30History.31SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)5Intellectual Property RightsIPRs essential or potentially essential to the present document may have been declared to ETSI. The informationpertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be foundin ETR 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect ofETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the ETSIWeb server (http://www.etsi.fr/ipr or http://www.etsi.org/ipr).Pursuant to the ETSI Interim IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. Noguarantee can be given as to the existence of other IPRs not referenced in ETR 314 (or the updates on the ETSI Webserver) which are, or may be, or may become, essential to the present document.ForewordThis European Standard (Telecommunications series) has been produced by ETSI Technical Committee SignallingProtocols and Switching (SPS).The present document is part 1 of a multi-part European Standard (Telecommunications series) covering the IntegratedServices Digital Network (ISDN); Digital Subscriber Signalling System No. one (DSS1) protocol; Generic functionalprotocol for the support of supplementary services for Virtual Private Network (VPN) applications, as identified below:Part 1:"Protocol specification";Part 2:"Protocol Implementation Conformance Statement (PICS) proforma specification";Part 3:"Test Suite Structure and Test Purposes (TSS&TP), user";Part 4:"Abstract Test Suite (ATS), user";Part 5:"Test Suite Structure and Test Purposes (TSS&TP), network";Part 6:"Abstract Test Suite (ATS), network".National transposition datesDate of adoption of this EN:3 April 1998Date of latest announcement of this EN (doa):31 July 1998Date of latest publication of new National Standardor endorsement of this EN (dop/e):31 January 1999Date of withdrawal of any conflicting National Standard (dow):31 January 1999SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)61ScopeThe present document specifies the generic functional protocol for the pan-European Integrated Services DigitalNetwork (ISDN) applicable at the "b" service entry point (as defined in EN 301 060-1 [3]). It is part of the DigitalSubscriber Signalling System No. one (DSS1) protocol.The generic functional protocol is based on the Facility information element and the FACILITY message, as well as onother specific functional messages. The protocol is symmetrical, and it is applicable to both basic and primary rateinterfaces.The generic functional protocol defined in the present document provides the means to exchange signalling informationfor the control of supplementary services over a Virtual Private Network (VPN). It does not by itself control anysupplementary service but rather provides generic services to specific supplementary service control entities.The application of the present document to individual supplementary services is outside the scope of the presentdocument and is defined in those standards which specify the individual supplementary services.Further part(s) of the present document specify the method of testing required to identify conformance to the presentdocument.The present document is applicable only to point-to-point access configurations.NOTE 1:The exchange of signalling information relating to the "b" service entry point is distinguished from theexchange of signalling information that is used to access public network services at the T reference point.The generic functional protocol applicable in a public network context is supported in accordance with therequirements of EN 300 196-1 [1]. The generic functional protocol specifically applicable in a VPNcontext is supported in accordance with the present document. The requirements have been defined suchthat both contexts can coexist on the same access, and this is expected to be a typical implementation.There is no requirement that when the provisions of the present document are implemented, the exchangeof signalling information relating to the T reference point also need to be implemented on the sameaccess. Where both contexts are implemented, the access resources are common to both contexts.NOTE 2:A service provider may support supplementary services applicable for public network calls in a VPNcontext. In this case the applicability of the individual public network supplementary services to a call in aVPN context is beyond the scope of the present document.2Normative referencesReferences may be made to:a)specific versions of publications (identified by date of publication, edition number, version number, etc.), inwhich case, subsequent revisions to the referenced document do not apply; orb)all versions up to and including the identified version (identified by "up to and including" before the versionidentity); orc)all versions subsequent to and including the identified version (identified by "onwards" following the versionidentity); ord)publications without mention of a specific version, in which case 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 samenumber.[1]EN 300 196-1: "Integrated Services Digital Network (ISDN); Generic functional protocol for thesupport of supplementary services; Digital Subscriber Signalling System No. one (DSS1) protocol;Part 1: Protocol specification".[2]EN 300 403-1: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling SystemNo. one (DSS1) protocol; Signalling network layer for circuit-mode basic call control; Part 1:Protocol specification [ITU-T Recommendation Q.911 (1993), modified]".SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)7[3]EN 301 060-1: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling SystemNo. one (DSS1) protocol; Basic call applications: enhancement at the "b" service entry point forVirtual Private Network (VPN) applications; Part 1: Protocol specification".[4]ETS 300 402-2: "Integrated Services Digital Network (ISDN); Digital Subscriber SignallingSystem No. one (DSS1) protocol; Data link layer; Part 2: General protocol specification [ITU-TRecommendation Q.921 (1993), modified]".[5]ISO/IEC 11582 (1995): "Information technology - Telecommunication and information exchangebetween systems - Private Integrated Services Network - Generic functional protocol for thesupport of supplementary services - Inter-exchange signalling procedures and protocol".[6]ITU-T Recommendation X.219 (1988): "Remote operations: Model, notation and servicedefinition".[7]ITU-T Recommendation X.229 (1988): "Remote operations: Protocol specification".[8]ISO/IEC 15056 (1997): "Information technology - Telecommunications and information exchangebetween systems - Private Integrated Services Network - Inter-exchange signalling protocol -Transit counter additional network feature".3Definitions and abbreviations3.1DefinitionsClause 3 of EN 300 196-1 [1] shall apply with the following addition:Corporate telecommunication Network (CN): Consists of sets of equipment (Customer Premises Equipment and/orCustomer Premises Network) which are located at geographically dispersed locations and are interconnected to providenetworking services to a defined group of users.NOTE 1:The ownership of the equipment is not relevant to this definition.NOTE 2:In the present document, even equipment which is not geographically dispersed (e.g. a single PrivateIntegrated services Network eXchange (PINX) or Centrex-provided services to users at a single location)may form a CN.Call control message: A message as defined in EN 301 060-1 [3], subclause 7.1, which on sending or receipt causes achange of the call state at either the network or the user. Call control messages also include the INFORMATIONmessage and PROGRESS message.3.2AbbreviationsFor the purposes of the present document, the following abbreviations apply:ACSEAssociation Control Service ElementBCBearer CapabilityCNCorporate telecommunication NetworkDSEDialogue Service ElementDSS1Digital Subscriber Signalling System No. oneGFTGeneric Functional TransportISDNIntegrated Services Digital NetworkNCICSNetworked Call Independent, Connection-oriented SignallingNFENetwork Facility ExtensionNT2Network Termination 2
PINXPrivate Integrated services Network eXchangePSS1Private Signalling System No. OneTETerminal EquipmentVPNVirtual Private NetworkSIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)84Coexistence of generic protocols for the control ofsupplementary services4.1Support of various generic protocolsSubclause 5.1 of EN 300 196-1 [1] shall apply.4.2Coexistence of generic protocolsSubclause 5.2 of EN 300 196-1 [1] shall apply.In addition, the protocol described in the present document incorporates the functionality of the generic functionalprotocol described in EN 300 196-1 [1].4.3Arrangements by which coexistence of protocols may besupported by a networkSubclause 5.3 of EN 300 196-1 [1] shall apply.5General principles applied for the functional control ofsupplementary services5.1IntroductionThis subclause specifies the general principles applied for the functional control of supplementary services at the "b"service entry point (as defined in EN 301 060-1 [3]). The generic protocol utilizes functions and services provided byEN 300 403-1 [2] basic call procedures, as extended by EN 301 060-1 [3], and the functions of the data link layer asdefined in ETS 300 402-2 [4].5.2Scope of the proceduresThe procedures defined in the present document specify the basic methodology for the control (e.g. invocation,notification, deactivation, etc.) of supplementary services. The procedures are independent of whether or not the user-network interface is at a basic or primary rate access.5.3Categories of proceduresTwo categories of procedures are defined.The first category deals with the control of supplementary services in a public network context. For this category,subclause 6.3 of EN 300 196-1 [1] shall apply.The second category deals with the control of supplementary services in a VPN context.The entity that establishes a signalling relation shall indicate by means of the presence or absence of the VPN indicatorinformation element in which context the signalling information is to be interpreted. The VPN indicator informationelement and the associated procedures are described in EN 301 060-1 [3] and in subclause 7.1.3 of the presentdocument.SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)95.4VPN services in the context of CNSee subclause 5.1 of EN 301 060-1 [3].6Control of supplementary services using the separatemessage approachThese procedures shall be used only in a public network context. Clause 7 of EN 300 196-1 [1] shall apply.7Control of supplementary services using the commoninformation element approach7.1General7.1.1IntroductionIn the common information element approach, the Facility information element is used to transport information for thecontrol of supplementary services, conveying components as application-oriented elements complemented by thenecessary procedures for operations and transport mechanisms. Operations and transport mechanisms may either berelated to a connection or may be used independently of a connection.The common information element approach is modelled as remote operations as specified in ITU-T RecommendationsX.219 [6] and X.229 [7]. According to this model, one entity requests that a particular operation be performed whilst theresponding entity attempts to perform the operation and responds to the invoking entity. Therefore an operation of thecommon information element approach is regarded as a request/reply interaction, supported by the application functionand carried out within the context of an application association.An error is used to report the unsuccessful outcome of an operation. For each operation the appropriate errors, ifrequired, need to be indicated.7.1.2Scope of the proceduresSubclause 8.1.2 of EN 300 196-1 [1] shall apply.7.1.3Distinction between public network and VPN contextAn indication is necessary to distinguish between a public network or a VPN context.If an entity sends a message that establishes a call reference in a VPN context, it shall include a VPN indicatorinformation element in this message. If an entity sends such a message in a public network context, it shall not include aVPN indicator information element in this message.If an entity receives a message that establishes a call reference, and this message contains a VPN indicator informationelement, then the procedures for signalling in a VPN context shall apply for all messages that use this call reference.If an entity receives a message that establishes a call reference, and this message does not contain a VPN indicatorinformation element, then the procedures for signalling in a public network context shall apply for all messages that usethis call reference.If an entity receives a FACILITY message with the dummy call reference, and this message does not contain a VPNindicator information element, then the procedures for signalling in a public network context shall apply.SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)10If an entity receives a FACILITY message with the dummy call reference, and this message contains a VPN indicatorinformation element, then the procedures for signalling in a VPN context shall apply.NOTE:The present document does not specify the use of the dummy call reference in the FACILITY message.The receipt of a FACILITY message with the dummy call reference in a VPN context is an error, anderror handling procedures are applied.7.2Procedures applicable for signalling in a VPN context7.2.1Transport of components7.2.1.1Bearer-related transport mechanism7.2.1.1.1Protocol control requirementsThis subclause defines the transport of components using the messages for the establishment and the clearing of calls.The procedures for basic call control are described in EN 301 060-1 [3]. These procedures are not influenced by thecomponents carried. Bearer-related transport procedures and operations shall follow the specified procedures andtransport capabilities of bearer connections according to EN 301 060-1 [3]. The SETUP message shall contain the VPNindicator information element.For bearer-related transport of components, the call state of the bearer connection shall be in a state (or about to enter astate) other than the Null state (U0, N0). For transport, any call control message as defined in EN 301 060-1 [3] (exceptthe STATUS and STATUS ENQUIRY messages), or the FACILITY message defined in subclause 11.1.1.1 of thepresent document, may be used to carry the components in a Facility information element. These messages shall use thecall reference of the bearer connection.NOTE:If the call establishment request has not reached the addressed PINX, the component included in theFACILITY message may not reach its intended destination. There is no requirement for any entity toavoid this by storing the information.For general rules, format and coding of call reference values, subclause 4.3 of EN 300 403-1 [2] shall apply.The call reference provides the means to correlate messages belonging to the same signalling transaction of aconnection. When a supplementary service affects more than one connection, different call references are used toidentify each connection individually. This implies the use of different messages in order to manage each connectionseparately.The implicit call-control association provided by an EN 300 403-1 [2] call reference shall always be cleared when aconnection is released.The Cause information element shall only be used to report information element content errors outside the componentportion of the Facility information element (octets 1 - 3). When no protocol error outside the component portion isfound, the Cause information element shall convey cause #31, "normal unspecified". For protocol errors in thecomponent portion of the Facility information element (octets 3.1, etc) see subclauses 7.2.1.1.2 and 9.1.7.2.1.1.2Generic Functional Transport (GFT)-Control requirementsFor those nodal entities that terminate the GFT-Control protocol, subclause 7.1.2 of ISO/IEC 11582 [5] shall apply.NOTE:For those nodal entities that do not terminate the GFT-Control protocol, the Facility information elementwill be transferred to the next entity regardless of the contents of the destinationEntity element of theNetwork Facility Extension (NFE). Examples of this type of nodal entity include a Transit PINX withreduced functionality as well as a Relay Node.SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)117.2.1.2Connection-oriented bearer-independent transport mechanism7.2.1.2.1Protocol control requirements7.2.1.2.1.1Connection establishment at the originating interfaceBefore these procedures are invoked, a reliable data link connection shall be established between the user (TE/NT2) andthe network. All layer 3 messages shall be sent to the data link layer using a DL-DATA request primitive, using the datalink services described in ETS 300 402-2 [4].7.2.1.2.1.1.1Connection requestTo initiate a Networked Call Independent, Connection-oriented Signalling (NCICS) connection establishment, the usershall transfer a SETUP message across the user-network interface. Following the transmission of the SETUP message,the connection shall be considered by the user to be in the Call Initiated state. The SETUP message shall always containa call reference, selected according to the procedures given in subclause 4.3 of EN 300 403-1 [2]. In selecting a callreference, the dummy call reference value shall not be used.Furthermore the SETUP message shall contain the Channel identification information element and all of the information(i.e. address and facility requests) necessary for connection establishment. Refer to subclause 11.1.2.7 for the contents ofthe SETUP message.The physical PINX at the originating interface shall include the VPN indicator information element in the SETUPmessage.If the network receives a VPN indicator information element that does not contain a CN identifier in a SETUP message,and a CN identifier is registered as a default for the access, then the network shall use the default CN identifier. If theVPN indicator information element does not contain a CN identifier and there is no CN identifier registered as a defaultfor the access, then the network shall reject the request with cause #50, "requested facility not subscribed". If the VPNindicator information element indicates a CN which is not associated with the access, then the network shall reject therequest with cause #50, "requested facility not subscribed".The user shall start timer T303 upon transmission of the SETUP message and enter the Call Initiated state. If the userdoes not receive a response to the SETUP message prior to the expiry of timer T303, the user shall retransmit theSETUP message and restart timer T303. If the user does not receive any response to the retransmitted SETUP messageprior to the expiration of timer T303, then the user shall send a RELEASE COMPLETE message to the network withcause #102, recovery on timer expiry and internally clear the NCICS connection.On receipt of a bearer-independent SETUP message, the network shall:-if the request is valid and can be processed, follow the procedures of subclause 7.2.1.2.1.1.3; or-if the request is invalid or cannot be accepted, follow the procedures of subclause 7.2.1.2.1.1.2.The FACILITY message shall be exchanged only once the NCICS connection has reached the Active state.7.2.1.2.1.1.2Invalid connection informationIf the NCICS connection request is invalid or cannot be accepted, the network shall:-return a RELEASE COMPLETE message;-release the call reference; and-remain in the Null state.The RELEASE COMPLETE message shall contain an appropriate cause value. If the network determines that a bearer-independent signalling connection is not authorized or available, cause #63, "service or option not available,unspecified", shall be used.SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)127.2.1.2.1.1.3Call proceedingIf the NCICS connection request is valid and can be processed, the network shall:-return a CALL PROCEEDING message;-enter the Outgoing Call Proceeding state; and-attempt to establish the NCICS connection towards the terminating entity (for example, see subclause7.2.1.2.1.2).Upon receipt of the CALL PROCEEDING message, the user shall:-stop timer T303;-enter the Outgoing Call Proceeding state; and-start timer T310.If timer T310 expires, the user shall initiate NCICS connection clearing towards the network in accordance withsubclause 7.2.1.2.1.3 using cause # 102, "recovery on timer expiry".7.2.1.2.1.1.4Connection connectedUpon the network receiving an indication that the NCICS connection request has been accepted, the network shall senda CONNECT message across the originating user-network interface, and either:-enter the Active state; or-start timer T313 and enter the Connect Request state.This message indicates to the originating user that a NCICS connection has been established through the network.On receipt of the CONNECT message, the originating user shall:-send a CONNECT ACKNOWLEDGE message;-stop timer T310; and-enter the Active state.On receipt of a CONNECT ACKNOWLEDGE message, the network shall:-if it perceives the NCICS connection to be in the Active state, take no action; or-if in the Connect Request state, stop timer T313 and enter the Active state.If timer T313 expires before a CONNECT ACKNOWLEDGE message is received, the network shall initiate NCICSconnection clearing with a RELEASE message using cause #102, „recovery on timer expiry“.7.2.1.2.1.1.5Connection rejectedUpon receiving an indication that the network or the terminating entity is unable to accept the NCICS connectionrequest, the network shall initiate NCICS connection clearing at the originating user-network interface as described insubclause 7.2.1.2.1.3, using the cause provided by the terminating network or the terminating entity.7.2.1.2.1.2Connection establishment at the destination interfaceBefore these procedures are invoked, a reliable data link connection shall be established between the user (TE/NT2) andthe network. All layer 3 messages shall be sent to the data link layer using a DL-DATA request primitive, using the datalink services described in ETS 300 402-2 [4].The call reference contained in all messages exchanged across the user-network interface shall contain the call referencevalue specified in the SETUP message delivered by the network. In selecting a call reference, the dummy call referenceshall not be used in conjunction with NCICS connections.SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)137.2.1.2.1.2.1Incoming connectionTo initiate a NCICS connection establishment, the network shall
transfer a SETUP message across the interface. Referto subclause 11.1.2.7 for the contents of the SETUP message. The network shall include the Channel identificationinformation element and the VPN indicator information element containing a CN identifier in the SETUP message.If the PINX receives a SETUP message and can determine that the indicated CN is not associated with the access, thenthe connection shall be rejected with cause #50 „Requested facility not subscribed“. After sending the SETUP message,the network shall start timer T303, and enter the Call Present state. If the network does not receive a response to theSETUP message prior to the expiry of timer T303, the network shall retransmit the SETUP message and restart timerT303.The FACILITY message can only be exchanged when the NCICS connection is in the Active state.7.2.1.2.1.2.2Connection confirmationWhen the user determines that sufficient NCICS connection set-up information has been received, the user shall respondwith a CALL PROCEEDING message and enter the Incoming Call Proceeding state.Upon receipt of the CALL PROCEEDING message, the network shall:-stop timer T303;-enter the Incoming Call Proceeding state; and-start timer T310.7.2.1.2.1.2.3Called user clearing during incoming connection establishmentIf a RELEASE or RELEASE COMPLETE message is received before a CONNECT message has been received, thenetwork shall:-stop timer T303 or T310 (if running);-continue to clear the terminating entity as described in subclause 7.2.1.2.1.3; and-clear the NCICS connection to the originating entity with the cause received in the RELEASE or RELEASECOMPLETE message.7.2.1.2.1.2.4Connection failureIf the network does not receive any response to the retransmitted SETUP message prior to the expiration of timer T303,then the network shall initiate clearing procedures towards the originating entity with cause #18, "no user responding".The network shall also initiate clearing procedures towards the terminating entity in accordance withsubclause 7.2.1.2.1.3, using cause #102, "recovery on timer expiry".If the network has received a CALL PROCEEDING message, but does not receive a CONNECT, RELEASE, orRELEASE COMPLETE message prior to the expiration of timer T310, then the network shall initiate clearing towardsthe terminating entity. The terminating entity shall be cleared in accordance with subclause 7.2.1.2.1.3, using cause#102, "recovery on timer expiry". In addition, the network shall initiate clearing towards the originating entity inaccordance with subclause 7.2.1.2.1.3, using cause #18, "no user responding".7.2.1.2.1.2.5Connection acceptTo indicate acceptance of an incoming NCICS connection, the user shall send a CONNECT message to the network.Upon sending the CONNECT message, the user may start timer T313.7.2.1.2.1.2.6Active indicationOn receipt of a CONNECT message, the network shall:-stop timers T303 and T310 (if running);SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)14-complete the NCICS connection;-send a CONNECT ACKNOWLEDGE message to the terminating entity;-initiate procedures to send a CONNECT message towards the originating entity; and-enter the Active state.The CONNECT ACKNOWLEDGE message indicates completion of the NCICS connection. There is no guarantee ofan end-to-end connection until the originating entity receives a CONNECT message. Upon receipt of the CONNECTACKNOWLEDGE message, the user shall stop timer T313, if running, and enter the Active state.If timer T313 expires prior to receipt of a CONNECT ACKNOWLEDGE message, the user shall initiate clearing inaccordance with subclause 7.2.1.2.1.3, using cause #102, "recovery on timer expiry".The exchange of FACILITY messages can start once the NCICS connection has reached the Active state.7.2.1.2.1.3Connection clearing7.2.1.2.1.3.1Exception conditionsTo clear a NCICS connection , the user or the network shall send a RELEASE message and follow the proceduresdefined in subclauses 7.2.1.2.1.3.2 and 7.2.1.2.1.3.3 respectively. The only exception to the above rule is the following:in response to a SETUP message, provided no other response has previously been sent, the user or network can reject aNCICS connection by:-responding with a RELEASE COMPLETE message;-releasing the call reference; and-entering the Null state.7.2.1.2.1.3.2Clearing initiated by the userApart from the exception identified in subclauses 7.2.1.2.1.3.1 and 7.2.1.2.1.6, to initiate clearing, the user shall:-send a RELEASE message;-start timer T308; and-enter the Release Request state.On receipt of a RELEASE message, the network shall:-send a RELEASE COMPLETE message;-release the call reference; and-enter the Null state.On receipt of the RELEASE COMPLETE message the user shall:-stop timer T308;-release the call reference; and-enter the Null state.If timer T308 expires for the first time, the user shall retransmit the RELEASE message and restart timer T308. Inaddition, the user may include a second Cause information element with cause #102, "recovery on timer expiry". If noRELEASE COMPLETE message is received from the network before timer T308 expires a second time, the user shallrelease the call reference and enter the Null state.SIST EN 301 061-1:2001
ETSIEN 301 061-1 V1.2.2 (1998-04)157.2.1.2.1.3.3Clearing initiated by the networkApart from the exception identified in subclauses 7.2.1.2.1.3.1 and 7.2.1.2.1.6, to initiate clearing, the network shall:-send a RELEASE message;-start timer T308; and-enter the Release Request state.On receipt of a RELEASE message, the user shall:-send a RELEASE COMPLETE message;-release the call reference; and-enter the Null state.On receipt of the RELEASE COMPLETE message the network shall:-stop timer T308;-release the call reference; and-enter the Null state.If timer T308 expires for the first time, the network shall retransmit the RELEASE message and restart timer T308. Inaddition, the network may include a second Cause information element with cause #102, "recovery on timer expiry". Ifno RELEASE COMPLETE message is received from the user before timer T308 expires a second time, the networkshall release the call reference and enter the Null state.7.2.1.2.1.3.4Clear collisionClear collision can occur when both sides simultaneously transfer RELEASE messages related to the same call referencevalue. The entity receiving such a RELEASE message whilst within the Release Request sta
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...