1、INTERNATIONAL STANDARD lSO/IEC 11572 Second edition 1997-06-l 5 Information technology - Telecommunication and information exchange between systems - Private Integrated Services Network - Circuit mode bearer services - Inter-exchange signalling procedures and protocol Technologies de Iinforma tion -
2、 T - MORE-INFORMATION-REQUEST/INDICATION for 3 ISO/IEC 11572: 1997(E) ISOAEC - - - - - - - - PSSl Control PSSl Protocol I PSSl Si nallin La er PSSl lIJ Call Control PSSl Signalling Carriage Mechanism PSSl Signalling j Carriage ! Mechanism ! .I I .-. -. . - PINX to PINX Connection Figure 2 - Control
3、Plane Protocol Model requesting more destination addressing intormation during call establishment; INFORMATION-REQUEST/INDICATION for provid- ing more destination addressing information during call establishment; PROCEED-REQUEST/INDICATION for indicating that sufficient destination addressing inform
4、ation has been received and call establishment is pro- ceeding; ALERTING-REQUEST/INDICATION for indicating that the destination user is being alerted; PROGRESS-REQUEST/INDICATION for indicating interworking conditions and/or the availability of in- band patterns; REJECT-REQUEST/INDICATION for the im
5、medi- ate rejection of a call; DISCONNECT-REQUEST/INDICATION for the initi- ation of call release; RELEASE-REQUEST/INDICATION for the comple- tion of call release. DL-RESET-INDICATION for indicating to Call Con- trol that a SCM reset has occurred. 6.3 Mechanism Services required of the Signalling Ca
6、rriage _ _ The services required of the Signalling Carriage Mecha- nism can be defined in terms of the services provided by ISO/IEC 8886. Protocol Control uses the following acknowledged information transfer services and their asso- ciated primitives: - Data transfer (i.e. Protocol Control message t
7、rans- fer), using the DL-DATA-REQUEST/INDICATION primitives; - Establishment, using the DL-ESTABLISH- REQUEST/INDICATION/CONFIRM primitives; - Termination, using the DL-RELEASE-REQUEST/ INDICATION primitives. NOTE - An implementation is not constrained to use the ISO/IEC 8886 Protocol in order to pr
8、ovide these primitives 7 Protocol Control states Protocol Control procedures for calls and layer manage- ment are specified in terms of: 4 messages which are transferred across the Inter- PINX link, b) the primitives to and from Call Control at each PINX, c) the -information processing and actions t
9、hat take place within Protocol Control at each PINX, and d) the states that can exist within Protocol Control at each PINX. State machines are deemed to exist for each circuit-mode call. Further state machines are deemed to exist for layer management. 7.1 States for circuit-mode Call Control The sta
10、tes below are used in association with call refer- ences other than the global call reference. 7.1.1 Null State (0) No call exists. o ISO/IEC lSO/lEC 11572:1997(E) 7.1.2 Call Initiated (1) This state exists for an outgoing call when the Outgoing Side has sent a request for call establishment to the
11、Incom- ing Side but has not yet received a response. 7.1.3 Overlap Sending (2) 7.1 .I1 Disconnect Request (11) This state exists when a Side has sent to the other Side a request to disconnect the user information connection and iswaiting for a response. 7.1.12 Disconnect Indication (12) This state e
12、xists for an outgoing call when the Outgoing Side has received acknowledgement that the Incoming Side is able to receive additional call information in overlap mode. 7.1.4 Outgoing Call Proceeding (3) This state exists for an outgoing call when the Outgoing Side has received acknowledgement that the
13、 Incoming Side has received all call information necessary to effect call establishment. 7.1.5 Call Delivered (4) This state exists for an outgoing call when the Outgoing Side has received from the Incoming Side an indication that the called user is being alerted. 7.1.6 Call Present (6) This state e
14、xists for an incoming call when the Incoming Side has not yet responded to the request from the Outgo- ing Side for call establishment. This state exists when a Side has received from the other Side a request to disconnect the user information connec- tion and has not yet responded. 7.1 .I 3 Release
15、 Request (19) This state exists when a Side has sent to the other Side a request to release the call and has not yet received a response. 7.1.14 Overlap Receiving (25) This state exists for an incoming call when the Incoming Side has sent acknowledgement to the Outgoing Side that it is able to recei
16、ve additional call information in overlap mode. 7.2 States for layer management The states below are used in association with the global call reference. 7.2.1 Null State (Rest 0) 7.1.7 Call Received (7) This state exists for an incoming call when the Incoming Side has indicated to the Outgoing Side
17、that the called user is being alerted. 7.1.8 Connect Request (8) This state exists for an incoming call when the Incoming Side has indicated to the Outgoing Side that the called user has answered the call. NOTE - answered is the act of the end user accepting the call. No transaction exists. 7.2.2 Re
18、start Request (Rest 1) This state exists for a restart transaction when the Side has sent a restart request to the other Side but has not yet received an acknowledgment. 7.2.3 Restart (Rest 2) This state exists for a restart transaction when the Side has received a restart request from the other Sid
19、e but has not yet sent an acknowledgement. 7.1.9 Incoming Call Proceeding (9) 8 Call Control This state exists for an incoming call when the Incoming Side has sent to the Outgoing Side acknowledgement that it has received all call information necessary to effect call establishment. 7.1.10 Active (10
20、) This state exists for an incoming call when the Incoming Side has received from the Outgoing Side an acknowl- edgement of the indication that the called user has answered the call. This state exists for an outgoing call when the Outgoing Side has received from the Incoming Side an indication that
21、the called user has answered the call. NOTE - answered is the act of the end user accepting the call. In addition to specifying Protocol Control, this International Standard also specifies those aspects of Call Control which are necessary for PlNXs to cooperate in the control of calls through a PISN
22、. Although the behavior of a Protocol Con- trol entity with respect to a call is dependent on whether the PINX is the Outgoing Side or the Incoming Side of the Inter-PINX link, its behavior is independent of whether the PiNX is a Transit PINX, an End (Originating or Terminating) PINX, or a Gateway P
23、INX. Call Control requirements, on the other hand, are dependent on whether the PINX is a Transit PINX, an Originating PINX, a Terminating PINX, an Incoming Gateway PINX or an Outgoing Gateway PINX. Subclause 10.4 specifies the special Call Control require- ments of a Transit PINX for coordinating t
24、he two Protocol Control entities. The requirements of subclause 10.4 are in addition to the requirements of Protocol Control, which are 5 lSO/lEC 11572:1997(E) 0 ISO/IEC to be satisfied for both the Incoming Inter-PINX link and the Outgoing Inter-PINX link. An SDL representation of Call Control for
25、a Transit PINX appears in annex F. Subclause 10.5 specifies the special Call Control require- ments for Originating PINXs. The requirements of sub- clause 10.5 are in addition to the requirements of Protocol Control, which are to be satisfied on the Outgoing Inter- PINX link. Subclause 10.6 specifie
26、s the special Call Control require- ments for Terminating PINXs. The requirements of sub- clause 10.6 are in addition to the requirements of Protocol Control, which are to be satisfied on the Incoming Inter- PINX link. Subclause 10.7 specifies the special Call Control require- ments for Incoming Gat
27、eway PINXs. The requirements of subclause 10.7 are in addition to the requirements of Proto- col Control, which are to be satisfied on the Outgoing Inter- PINX link. Clause 10.8 specifies the special Call Control requirements for Outgoing Gateway PINXs. The requirements of sub- clause 10.8 are in ad
28、dition to the requirements of Protocol Control, which are to be satisfied on the Incoming lnter- PINX link. 8.1 States for Transit PINX Call Control The states below are used in association with calls in Call Control of a Transit PINX . NOTE - These states are used in order to describe the behavior
29、of the Transit PINX Call Control function. These inter- nal states are a descriptive tool and are not intended to con- strain implementations. 8.1 .l TCC-Idle (0) No call exists. 8.1.2 TCC-Await Digits (1) This state exists when Call Control has received a request for call establishment from the Pre
30、ceding PINX and is awaiting additional call information in order to select a route to the Subsequent PINX 8.1.3 TCC-Await Additional Digits (2) This state exists when Call Control has sent a request for call establishment to the Subsequent PINX and is awaiting possible additional call information fr
31、om the Preceding PINX. 8.1.4 TCC-Overlap (3) This state exists when Call Control is awaiting possible additional call information from the Preceding PINX, having received acknowledgement that the Subsequent PINX is able to receive additional call information in overlap mode. 8.1.5 TCC-Incoming Call
32、Proceeding (4) This state exists when Call Control has determined that it has received all call information necessary to effect call establishment and has informed the Preceding PINX, but no response to the request for call establishment has been received from the Subsequent PINX. 8.1.6 TCC-Transit
33、Call Proceeding (5) This state exists when Call Control has received from the Subsequent PINX a response to the request for call estab- lishment and is no longer expecting additional call informa- tion to pass to the Subsequent PINX in overlap mode. 8.1.7 TCC-Call Alerting (6) This state exists when
34、 Call Control has received from the Subsequent PINX an indication that the called user is being alerted and has relayed the indication on to the Preceding PINX . 8.1.8 TCC-Call Active (7) This state exists when Call Control has received from the Subsequent PINX and relayed on to the Preceding PINX a
35、n indication that the called user has answered the call. NOTE - answered is the act of the end user accepting the call. 8.1.9 TCC-Await Incoming Release (8) This state exists when Call Control has initiated call clear- ing towards the Preceding PINX and is awaiting an acknowledgement. 8.1 .I0 TCC-Aw
36、ait Outgoing Release (9) This state exists when Call Control has initiated call clear- ing towards the Subsequent PINX and is awaiting an acknowledgement. 8.1.11 TCC-Await Two-Way Release (10) This state exists when Call Control has initiated call clear- ing towards the Preceding PINX and towards th
37、e Subse- quent PINX and is awaiting an acknowledgement from each. 8.1.12 TCC-Await Incoming Disconnect (11) This state exists when Call Control has applied an in-band tone or announcement towards the Preceding PINX and is awaiting the initiation of clearing procedures. 8.1.13 TCC-Await Outgoing Disc
38、onnect (12) This state exists when Call Control has applied an in-band tone or announcement towards the Subsequent PINX and is awaiting the initiation of clearing procedures. 8.1.14 TCC-Await Two-Way Disconnect (13) This state exists when Call Control has applied an in-band tone or announcement towa
39、rds both the Preceding PINX and the Subsequent PINX and is awaiting the initiation of clearing procedures. 6 0 ISO/IEC lSO/lEC 11572: 1997(E) 9 General procedures 9.1 Use of the services of Signalling Carriage Mechanism 9.2.2 Message too short When a message is received that is too short to contain
40、a complete message type information element, that message shall be ignored. This clause specifies the use by PSSl of the services of the Signalling Carriage Mechanism. 9.2.3 Call reference error NOTE - The SCM provides a defined service of quality. 9.2.3.1 Invalid call reference format 9.1.1 Establi
41、shment of a Signalling Carriage Mecha- nism connection Before the procedures for Call Control, layer management or any of the general procedures in clauses 9.2 and 9.3 can be performed, a SCM connection shall be established. If a SCM connection has not already been established, Proto- col Control sh
42、all request establishment by sending a DL- ESTABLISH-REQUEST primitive to the Signalling Carriage Mechanism. Receipt of a DL-ESTABLISH-CONFIRMA- TION primitive or a DL-ESTABLISH-INDICATION primitive from the Signalling Carriage Mechanism indicates that a SCM connection has been established. 9.1.2 Tr
43、ansfer of data A PSSl message (or message segment) is transmitted by including it with a DL-DATA-REQUEST primitive to the Sig- nailing Carriage Mechanism. A PSSl message (or message segment) appears included with a DL-DATA-INDICATION primitive from the Signalling Carriage Mechanism. 9.1.3 Signalling
44、 Carriage Mechanism reset Receipt of a DL-ESTABLISH-INDICATION primitive from the Signalling Carnage Mechanism subsequent to estab- lishment of the SCM connection indicates a spontaneous SCM reset. The procedures specified in subclause 9.2.8 shall apply. 9.1.4 Signalling Carriage Mechanism failure R
45、eceipt of a DL-RELEASE-INDICATION primitive from the SCM indicates a SCM malfunction. The procedures speci- fied in subclause 9.2.9 shall apply. 9.2 Handling of protocol error conditions The procedures of clauses 9.3, 10, 11 and 12 of this speci- fication are applicable only to those messages which
46、pass the checks described in subclauses 9.2.1 through 9.2.7. Subclauses 9.2.1 through 9.2.7 are listed in order of prece- dence. 9.2.1 Protocol discriminator error If the Call reference information element octet 1, bits 5 through 8 do not equal “OOOO”, then the message shall be ignored. If octet 1,
47、bits 1 through 4 of the call reference information element indicates a length greater than the maximum length supported by the receiving equipment, then the message shall be ignored. If a message containing the Dummy call reference is received, except when used in the context of other Stan- dards wh
48、ich define its use, the message shall be ignored. 9.2.3.2 Call reference procedural errors Whenever any message except SETUP, STATUS, RELEASE or RELEASE COMPLETE is received specifying a call reference (other than the global call reference) which is not recognised as relating to an active call or to
49、 a call in progress, the receiving entity shall send a RELEASE COM- PLETE message and remain in the null state. The RELEASE COMPLETE message shall contain the call ref- erence of the received message and cause number 81, “invalid call reference value”. Alternatively, the receiving entity may send a RELEASE message (in place of the RELEASE COMPLETE message) in this situation, but this is not the preferred option. The RELEASE message shall contain the call reference of the received message and cause number 81, “invalid call refer- ence value”. When a SETUP message is received specif
