atmsig - General Telecom B-ISDN Signalling Handout 770...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: General Telecom B-ISDN Signalling Handout 770 00905 0120 VHBE Ed. 02 Status Released Change Note Short Title B-ISDN Signalling All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel. 2 / 297 770 00905 0120 VHBE Ed. 02 Contents Contents Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 18 18 18 21 24 Architecture of B-ISDN Signalling . . . . . . . . . . . . . . . . . . . 29 Layered Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . At the UNI : DSS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . At the NNI : B-ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . . Selection of most relevant Items. . . . . . . . . . . . . . . . . 30 30 32 34 The ATM Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Services provided by the ATM layer : . . . . . . . . . . . . . Signalling channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . Primitives exchanged with the SAAL . . . . . . . . . . . . . . The complete ATM cell header. . . . . . . . . . . . . . . . . . . 38 39 42 44 Common Part of the AAL-5 . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.1 4.2 4 Classification of Signalling Systems. . . . . . . . . . . . . . Brief History of Signalling Systems. . . . . . . . . . . . . . . 1.2.1 Analogue Signalling. . . . . . . . . . . . . . . . . . 1.2.2 CAS Signalling. . . . . . . . . . . . . . . . . . . . . . . 1.2.3 N-ISDN Signalling . . . . . . . . . . . . . . . . . . 1.2.4 B-ISDN Signalling . . . . . . . . . . . . . . . . . . 3.1 3.2 3.3 3.4 3 15 2.1 2.2 2.3 2.4 2 Situation of B-ISDN Signalling . . . . . . . . . . . . . . . . . . . . . . 1.1 1.2 1 13 48 49 49 50 50 50 52 54 55 4.3 4.4 4.5 5 Architecture of the AAL-5 . . . . . . . . . . . . . . . . . . . . . . Services of the AAL-5 Common Part . . . . . . . . . . . . 4.2.1 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Scope Restriction for Signalling Purposes Mechanisms of the AAL-5 Common Part . . . . . . . . . 4.3.1 The CPCS-PDU . . . . . . . . . . . . . . . . . . . . . 4.3.2 The SAR Functionality . . . . . . . . . . . . . . . . Primitives of the AAL-5 Common Part . . . . . . . . . . . 4.4.1 Primitives between the CPCS and the SAR 4.4.2 Primitives between the higher layer and the CPCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 56 59 5.1 5.2 5.3 770 00905 0120 VHBE Ed. 02 SSCOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 62 65 65 Services provided by the SSCOP . . . . . . . . . . . . . . . . . Primitives exchanged between SSCOP and SSCF . . The SSCOP Peer to Peer Protocol . . . . . . . . . . . . . . . . 5.3.1 PDU Types . . . . . . . . . . . . . . . . . . . . . . . . . . 3 / 297 Contents 5.3.2 5.3.3 5.3.4 6 Connection Control . . . . . . . . . . . . . . . . . . Assured Data Transfer . . . . . . . . . . . . . . . . Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 72 76 89 SSCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 6.1 6.2 7 SSCF at the UNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 6.1.1 Services provided by the SSCF. . . . . . . . . . 92 6.1.2 Primitives exchanged between SSCF and layer 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 6.1.3 Restrictions to SSCOP . . . . . . . . . . . . . . . . 93 SSCF at the NNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 6.2.1 Services provided by the SSCF. . . . . . . . . . 95 6.2.2 Primitives exchanged between SSCF and layer 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 6.2.3 Restrictions to SSCOP . . . . . . . . . . . . . . . . 98 6.2.4 SSCF Peer to Peer Communication . . . . . 100 MTP-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 7.1 From Narrowband to Broadband . . . . . . . . . . . . . . . . 7.1.1 The Narrowband Situation . . . . . . . . . . . . 7.1.2 The Broadband Situation . . . . . . . . . . . . . Services of MTP-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . Signalling Message Handling functions . . . . . . . . . . . 7.3.1 DPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.2 OPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.3 NI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.4 SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.5 SLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Primitives exchanged between MTP-3 and B-ISUP . Outlook of an MTP-3 message . . . . . . . . . . . . . . . . . Signalling Network Management Functions . . . . . . . 7.6.1 Traffic Management Functions . . . . . . . . . 7.6.2 Link Management Functions . . . . . . . . . . . 7.6.3 Route Management Functions . . . . . . . . . 104 104 109 110 111 113 115 115 117 118 120 123 124 126 140 141 Q.2931 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 8.1 8.2 150 151 152 154 154 154 154 157 157 7.2 7.3 7.4 7.5 7.6 8 8.3 4 / 297 Q.2931 Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Coding Principles of Q.2931 Messages. . . 8.2.1 Common IEs . . . . . . . . . . . . . . . . . . . . . . . . 8.2.2 Message Type . . . . . . . . . . . . . . . . . . . . . . . 8.2.3 Message Compatibility Information . . . . 8.2.4 Message Length . . . . . . . . . . . . . . . . . . . . . 8.2.5 Message Content . . . . . . . . . . . . . . . . . . . . Q.2931 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Call Setup Messages . . . . . . . . . . . . . . . . . 770 00905 0120 VHBE Ed. 02 Contents 8.4 8.5 8.6 9 8.3.2 8.3.3 Important 8.4.1 Call Release Messages . . . . . . . . . . . . . . . 168 Maintenance Messages . . . . . . . . . . . . . . . 171 Q.2931 Information Elements . . . . . . . . . 175 Information Elements, mainly used in Call Setup Messages . . . . . . . . . . . . . . . . . . . . . 175 8.4.2 Parameters, mainly used in Call Release Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 8.4.3 Parameters, mainly used in Maintenance Control Messages . . . . . . . . . . . . . . . . . . . 193 Interworking with N-ISDN . . . . . . . . . . . . . . . . . . . . . 194 8.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 194 8.5.2 Emulation of N-ISDN services in a B-ISDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 8.5.3 Interworking between UNI protocols . . . . 195 Additional Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . 197 8.6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 8.6.2 Point-to-Multipoint Calls . . . . . . . . . . . . 199 8.6.3 Additional Traffic Parameters . . . . . . . . . . 207 8.6.4 Look-ahead Capability . . . . . . . . . . . . . . 208 8.6.5 Negotiation of Traffic Characteristics during Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 209 8.6.6 Modification of Traffic Characteristics during the Active Phase . . . . . . . . . . . . . . . . . . . . . . . . 212 8.6.7 Call Priority . . . . . . . . . . . . . . . . . . . . . . . . . 215 B-ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 9.1 9.2 218 218 219 219 220 221 224 226 226 232 232 244 246 248 250 251 252 255 255 9.3 9.4 9.5 9.6 770 00905 0120 VHBE Ed. 02 B-ISUP Capability Set 1 Services . . . . . . . . . . . . . . . . General Coding Principles of B-ISUP Messages . . . 9.2.1 Message Type Code . . . . . . . . . . . . . . . . . . 9.2.2 Message Length . . . . . . . . . . . . . . . . . . . . . 9.2.3 Message Compatibility Information . . . . 9.2.4 Message Content . . . . . . . . . . . . . . . . . . . . Assignment Procedure of VPCI/VCI and Bandwidth B-ISUP Instances and Identities . . . . . . . . . . . . . . . . . 9.4.1 B-ISUP Specification Model . . . . . . . . . . . B-ISUP Capability Set 1 Messages. . . . . . . . . . . . . . . 9.5.1 Call Setup Messages . . . . . . . . . . . . . . . . . 9.5.2 Call Release Messages . . . . . . . . . . . . . . . 9.5.3 Suspend and Resume Messages . . . . . . . 9.5.4 Consistency Check Messages . . . . . . . . . . 9.5.5 Confusion Message . . . . . . . . . . . . . . . . . . 9.5.6 Facility Messages . . . . . . . . . . . . . . . . . . . . 9.5.7 Maintenance Control Messages . . . . . . . . Important B-ISUP Capability Set 1 Parameters . . . . 9.6.1 Parameters used in all B-ISUP Messages 5 / 297 Contents 9.6.2 9.7 Parameters, mainly used in Call Setup Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 9.6.3 Parameters, mainly used in Call Release Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 9.6.4 Parameters, mainly used in Suspend / Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 9.6.5 Parameters, mainly used in Consistency Check Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 9.6.6 Parameters, mainly used in Facility Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 9.6.7 Parameters, mainly used in Maintenance Control Messages . . . . . . . . . . . . . . . . . . . 277 Capability Set 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 9.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 9.7.2 Point-to-Multipoint Calls . . . . . . . . . . . . 281 9.7.3 Additional Traffic Parameters . . . . . . . . . . 284 9.7.4 Look-ahead Capability . . . . . . . . . . . . . . 285 9.7.5 Negotiation of Traffic Characteristics during Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 286 9.7.6 Modification of Traffic Characteristics during the Active Phase . . . . . . . . . . . . . . . . . . . . . . . . 286 9.7.7 Call Priority . . . . . . . . . . . . . . . . . . . . . . . . . 286 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Appendix A 6 / 297 289 295 References . . . . . . . . . . . . . . . . . . . . . . . . . 770 00905 0120 VHBE Ed. 02 Contents Figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 Figure 13 Figure 14 Figure 15 Figure 16 Figure 17 Figure 18 Figure 19 Figure 20 Figure 21 Figure 22 Figure 23 Figure 24 Figure 25 Figure 26 Figure 27 Figure 28 Figure 29 Figure 30 Figure 31 Figure 32 Figure 33 Figure 34 Figure 35 Figure 36 Figure 37 Figure 38 Figure 39 Figure 40 Figure 41 770 00905 0120 VHBE Ed. 02 Transmission and Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 B-ISDN Signalling at the UNI and the NNI . . . . . . . . . . . . . . 17 DSS2 and B-ISUP perform both Line- and Register Signalling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 PCM Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 CAS Multi-frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Protocol Stack for DSS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Explicit speech channel identification in CCS #7. . . . . . . . . . 23 Different Transport Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . 25 ATM Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 STM versus ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Protocol Stack for DSS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Protocol Stack for B-ISUP using an ATM network . . . . . . . . . , 32 Protocol Stack for B-ISUP using an ATM network . . . . . . . . . , 33 SVC at the UNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2 SVCs on a Single Interface, Cross Connect, quasi-associated Signalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2 SVCs on Multiple Interfaces, Cross-Connect, quasi-associated Signalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 SVC at the NNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Primitives between the ATM and the SAAL layer . . . . . . . . . . . 43 ATM Cell Header for Signalling Cells at the UNI . . . . . . . . . . 45 ATM Cell Header for Signalling Cells at the NNI . . . . . . . . . . 46 The Structure of the SAAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 The CPCS-PDU Format for the AAL Type 5 . . . . . . . . . . . . . . 51 AAL-5 CP Data Unit Conventions . . . . . . . . . . . . . . . . . . . . . . 53 Handling of a CPCS-SDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Pull-Back . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Selective Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Coding of BGN PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Coding of BGAK PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Coding of BGREJ PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Coding of END PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Coding of ENDAK PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Coding of SD PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Coding of POLL PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Coding of STAT PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Coding of USTAT PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Coding of RS PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Coding of RSAK PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Coding of ER PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Coding of ERAK PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 The Establishment of an SSCOP Connection . . . . . . . . . . . . . 72 The Release of an SSCOP Connection . . . . . . . . . . . . . . . . . . 73 7 / 297 Contents Figure 42 Figure 43 Figure 44 Figure 45 Figure 46 Figure 47 Figure 48 Figure 49 Figure 50 Figure 51 Figure 52 Figure 53 Figure 54 Figure 55 Figure 56 Figure 57 Figure 58 Figure 59 Figure 60 Figure 61 Figure 62 Figure 63 Figure 64 Figure 65 Figure 66 Figure 67 Figure 68 Figure 69 Figure 70 Figure 71 Figure 72 Figure 73 Figure 74 Figure 75 Figure 76 Figure 77 Figure 78 Figure 79 Figure 80 Figure 81 Figure 82 Figure 83 Figure 84 8 / 297 The Resynchronization of an SSCOP Connection . . . . . . . . . 73 The Recovery of an SSCOP Connection . . . . . . . . . . . . . . . . . 75 Resolution of Simultaneous Control Tasks . . . . . . . . . . . . . . . . 76 Invocation of a Service before Completion of a Previous Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Error Free Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Errored Data Transfer, 1 SD is lost . . . . . . . . . . . . . . . . . . . . . . 80 Errored Data Transfer, a Sequence of SDs is Lost . . . . . . . . . 81 Errored Data Transfer, Several Sequences of SDs are Lost . . 83 Errored Data Transfer with USTAT Message . . . . . . . . . . . . . . 85 SSCOP Protocol Timers for Assured Data Transfer . . . . . . . . 88 Local Retrieval of Information . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Format of NNI SSCF PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Processor Outage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 CCS #7 Network Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Signalling Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Hierarchy of a Signalling Link Set . . . . . . . . . . . . . . . . . . . . . . 107 Signalling Links, Linksets, Routes and Route Sets. . . . . . . . . . 108 MTP Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 From NB to BB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Message Discrimination, Message Distribution, Message Routing and the Signalling Message flow . . . . . . . . . . . . . . . . . . . . . . . 112 Outlook of the Service Information Octet (SIO) . . . . . . . . . . . 112 Outlook of the Routing Label . . . . . . . . . . . . . . . . . . . . . . . . . . 113 MTP Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Structure of an international Point Code . . . . . . . . . . . . . . . . . 115 National and International CCS #7 planes . . . . . . . . . . . . . . 116 National and International CCS #7 planes . . . . . . . . . . . . . . 117 Use of SLS for loadsharing purposes. . . . . . . . . . . . . . . . . . . . 119 Reduction of Traffic towards a Congested DPC. . . . . . . . . . . 122 Outlook of an MTP-3 message . . . . . . . . . . . . . . . . . . . . . . . . 124 Traffic Management, Link Management and Route Management functions, and their possible interactions. . . . . . . . . . . . . . . . . 126 Handshake Procedure for Changeover . . . . . . . . . . . . . . . . . . 127 Changeover Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 XCO and XCA Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Handshake procedure for Changeback . . . . . . . . . . . . . . . . . 131 Changeback Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 CBD and CBA format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Forced Rerouting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Controlled Rerouting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 MTP Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 TRA message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Management Inhibit messages . . . . . . . . . . . . . . . . . . . . . . . . . 137 User Part Unavailable message . . . . . . . . . . . . . . . . . . . . . . . . 139 Use of UPU message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 770 00905 0120 VHBE Ed. 02 Contents Figure 85 Figure 86 Figure 87 Figure 88 Figure 89 Figure 90 Figure 91 Figure 92 Figure 93 Figure 94 Figure 95 Figure 96 Figure 97 Figure 98 Figure 99 Figure 100 Figure 101 Figure 102 Figure 103 Figure 104 Figure 105 Figure 106 Figure 107 Figure 108 Figure 109 Figure 110 Figure 111 Figure 112 Figure 113 Figure 114 Figure 115 Figure 116 Figure 117 Figure 118 Figure 119 Figure 120 Figure 121 Figure 122 Figure 123 Figure 124 Figure 125 Figure 126 770 00905 0120 VHBE Ed. 02 TFP TFA and TFR messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . , TFP : Example 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TFP : Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transfer Prohibited . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RST and RSR message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TFC message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RCT message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Layout of a Q.2931 Message . . . . . . . . . . . . . . . . . . Use of the Call Reference Flag . . . . . . . . . . . . . . . . . . . . . . . . . General Layout of a Q.2931 Information Element . . . . . . . . Scenario for Outgoing Call Establishment, User to Network. Scenario for Incoming Call Establishment, User to Network Modifications for Overlap Sending for an Outgoing Call Establishment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modifications for Overlap Sending for Incoming Call Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scenario for Call Release, User Initiated . . . . . . . . . . . . . . . . . Scenario for Call Release, Network Initiated . . . . . . . . . . . . . Scenario for Call Restart, User Initiated . . . . . . . . . . . . . . . . . . Scenario for Call Restart, Network Initiated . . . . . . . . . . . . . . Scenario for Status Enquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATM Cell Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BB Bearer Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BB Repeat Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BB Repeat Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Called Party Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connection Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . End-to-end Transit Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . OAM Traffic Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BB Repeat Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interworking between B-ISDN and N-ISDN . . . . . . . . . . . . Interworking from N-ISDN towards B-ISDN . . . . . . . . . . . . A Unidirectional Point-to-Multipoint Connection . . . . . . . . Establishment of a Point-to-Multipoint Connection, with 2 Leafs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dropping of 2 Parties, Initiated by the Root . . . . . . . . . . . . . . Dropping of 2 Parties, initiated by the Leafs . . . . . . . . . . . . . . Look-ahead : Positive Answer . . . . . . . . . . . . . . . . . . . . . . . . . Successful Connection Modification . . . . . . . . . . . . . . . . . . . . . Modification Refused by the Addressed User . . . . . . . . . . . . . Modification Refused by the Network . . . . . . . . . . . . . . . . . . . B-ISUP Message Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message Compatibility Information . . . . . . . . . . . . . . . . . . . . . B-ISUP Parameter Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameter Compatibility Information . . . . . . . . . . . . . . . . . . . . 142 142 143 143 145 146 147 152 153 155 165 166 167 167 169 170 172 173 174 180 181 184 185 185 187 188 190 193 194 196 199 202 203 204 209 214 214 214 219 220 222 223 9 / 297 Contents Figure 127 Figure 128 Figure 129 Figure 130 Figure 131 Figure 132 Figure 133 Figure 134 Figure 135 Figure 136 Figure 137 Figure 138 Figure 139 Figure 140 Figure 141 Figure 142 Figure 143 Figure 144 Figure 145 Figure 146 Figure 147 Figure 148 Figure 149 Figure 150 Figure 151 Figure 152 Figure 153 Figure 154 10 / 297 Assignment of VPCI/VCI for assigning and non-assigning exchanges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-ISUP Specification Model . . . . . . . . . . . . . . . . . . . . . . . . . . . B-ISUP Model at an Intermediate Exchange . . . . . . . . . . . . . Call Scenario with the use of SIDs . . . . . . . . . . . . . . . . . . . . . . B-ISUP Scenario for Connection Setup (En bloc) . . . . . . . . . Overlap Sending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-ISUP Scenario for Call Release . . . . . . . . . . . . . . . . . . . . . . VPCI/VCI Consistency Check . . . . . . . . . . . . . . . . . . . . . . . . . . DSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATM Cell Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Broadband Bearer Capability . . . . . . . . . . . . . . . . . . . . . . . . . . Broadband High Layer Information . . . . . . . . . . . . . . . . . . . . . Broadband Low Layer Information . . . . . . . . . . . . . . . . . . . . . . Call History Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Called Party Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Called Party's Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Calling Party Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Calling Party's Category . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connection Element Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . OAM Traffic Descriptor Parameter . . . . . . . . . . . . . . . . . . . . . . Subsequent number. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automatic Congestion Level . . . . . . . . . . . . . . . . . . . . . . . . . . . Suspend / Resume Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . Consistency Check Result Information . . . . . . . . . . . . . . . . . . . User-to-user Indicators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resource Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of a Point-to-Multipoint Connection . . . . . . . . . . . Setup of a Point-to-Multipoint connection . . . . . . . . . . . . . . 225 227 229 231 241 243 245 249 256 259 260 261 261 262 263 265 266 268 269 270 271 272 273 274 275 277 283 284 770 00905 0120 VHBE Ed. 02 Contents Tables Table 1 Table 2 Table 3 Table 4 Table 5 Table 6 Table 7 Table 8 Table 9 Table 10 Table 11 Table 12 Table 13 Table 14 Table 15 Table 16 Table 17 Table 18 Table 19 Table 20 Table 21 Table 22 Table 23 Table 24 Table 25 Table 26 Table 27 Table 28 770 00905 0120 VHBE Ed. 02 Coding of the PTI Field of ATM Cells, carrying Signalling Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 PDU Type Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Status field encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Zone encoding for the international Point Codes. . . . . . . . . . 115 NI Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Service Indicator Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Q.2931 Message Types, functions and coding for a Call Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Q.2931 Message Types, functions and coding for a Call Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Q.2931 Message Types, functions and coding for Restart. . 171 Q.2931 Message Types, functions and coding for Restart. . 173 Q.2931 Message Types, functions and coding for Restart. . 174 Q.2931 Parameters names and codes, mainly used in Call Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 AAL Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Q.2931 Parameters names and codes, mainly used in Call Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 B-ISDN Specific Cause Values . . . . . . . . . . . . . . . . . . . . . . . . 192 Q.2931 Parameters names and codes, mainly used in Maintenance Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Q.2971 Message Types, functions and coding for a Call Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Q.2971 Parameters names and codes. . . . . . . . . . . . . . . . . . 205 Actions by the Network for Call Negotiating using the Alternative Traffic Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Handling of the Instruction Indicators for Unrecognized Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Handling of the Instruction Indicators for Unrecognized Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 B-ISUP Message Types, functions and coding for a Call Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 B-ISUP Message Types, functions and coding for a Call Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 ISUP Message Types, functions and coding for a call suspension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 ISUP Message Types, functions and coding for continuity procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 ISUP Message Types, functions and coding in case of confusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 ISUP Message Types, functions and coding for call facilities. 251 B-ISUP Message Types, functions and coding for (un)blocking procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 11 / 297 Contents Table 29 Table 30 Table 31 Table 32 Table 33 Table 34 Table 35 Table 36 Table 37 12 / 297 B-ISUP Message Types, functions and coding for reset procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 B-ISUP Message Types, functions and coding for user part availability procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Parameters Names and Codes, used in all B-ISUP Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 B-ISUP Parameters names and codes, mainly used in Call Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 B-ISUP Parameters names and codes, mainly used in Call Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 ISUP Parameters names and codes, mainly used in Call Suspension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 B-ISUP Parameters names and codes, mainly used in Consistency Check Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 ISUP Parameters names and codes, mainly used in Facility Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 B-ISUP Parameters names and codes, mainly used in Maintenance Control Messages. . . . . . . . . . . . . . . . . . . . . . . . 277 770 00905 0120 VHBE Ed. 02 Preface Preface Obviously, signalling has always played a very important part in the field of telecommunications, since it provides the means of information interchange between the user equipment and the network and between the nodes amongst themselves. The way of performing signalling functions has evolved together with the evolution of the transmission equipment and of the used switching systems. Both of them were originally analogue and evolved into digital systems for Narrowband Integrated Services Digital Network (N-ISDN). As the network evolves further towards a Broadband Integrated Services Digital Network (B-ISDN), also the signalling systems will have to evolve further. The traditional N-ISDN signalling methods are not a subject of this document, though a very brief overview will be given first, to be able to better situate the B-ISDN signalling systems. However, this document does not describe all the B-ISDN signalling systems, neither are the descriptions complete, since this would be too elaborate. It covers the following aspects : " Architecture (ITU-T Q.2010) " Common Part (CP) of the AAL 5 (ITU-T I.363.5) " Service Specific Connection Oriented Protocol (SSCOP) (ITU-T Q.2110) 770 00905 0120 VHBE Ed. 02 13 / 297 Preface " Service Specific Coordination Function (SSCF) (at the User-to-Network Interface (UNI) : ITU-T Q.2130) (at the Network-to-Network Interface (NNI) : ITU-T Q.2140) " Digital Subscriber Signalling System #2 (DSS2) (ITU-T Q.2931 / Q.2961 / Q.2971) " Broadband ISDN User Part (B-ISUP) (ITU-T Q.2761 - Q.2764) 14 / 297 770 00905 0120 VHBE Ed. 02 1Situation of B-ISDN Signalling 1 Situation of B-ISDN Signalling In order to fully appreciate the situation of B-ISDN Signalling, a brief classification and overview of signalling systems is given in this chapter. At the end, the principal differences between STM on one hand, and ATM on the other hand, are explained as well. 770 00905 0120 VHBE Ed. 02 15 / 297 1Situation of B-ISDN Signalling 1.1 Classification of Signalling Systems. Topological Classification In a telecommunication network, two core functions can be found: " The information has to be transported in a cost-efficient way from a source to a destination over a physical line = Transmission. " In a telephone exchange, an inlet has to be through-connected to the correct outlet = Switching. This is shown in figure 1. Exchange Exchange UNI UNI NNI Transmission Transmission Ç Ç Switching Figure 1 User Ç User Transmission Switching Transmission and Switching In order to be able to perform the switching function, a communication will be required between the calling subscriber and his own switching unit. This is the User-to-Network Interface (UNI). A communication will also be required between each switching unit and the next one in the call sequence. This is the Network-to-Network Interface (NNI). Thus, topologically, 2 large families of Signalling Systems can immediately be introduced : " UNI Signalling Systems : D Analogue Subscriber Signalling System (ASSS) D Digital Subscriber Signalling System #1 (DSS1) Commonly called "ISDN-Signalling" or "D-channel protocol". It is the UNI protocol for N-ISDN. It is described in ITU-T Q.921 for the Layer 2 functionality and in ITU-T Q.931 for the Layer 3 functionality. 16 / 297 770 00905 0120 VHBE Ed. 02 1Situation of B-ISDN Signalling D Digital Subscriber Signalling System #2 (DSS2) The adaptation of DSS1 for B-ISDN purposes in an ATM environment. It is a subject of this course. " NNI Signalling Systems : D Channel Associated Signalling (CAS) D Common Channel Signalling System #7 (CCS #7) CCS #7 is a modular, multi-functional system. One of its modules is B-ISUP intended for B-ISDN Signalling in , an ATM environment. It is also a subject of this course. UNI : DSS2 NNI : B-ISUP (< CCS #7) Figure 2 Functional Classification B-ISDN Signalling at the UNI and the NNI Another method of classifying Signalling Systems, is according to their functionality. At least, 2 types of information will always have to be "signalled" between adjacent points : " The intention to seize or to release a local line (in the case of UNI Signalling) or a trunk circuit (in the case of NNI Signalling). = Line Signalling. " The call destination (under the form of the dialled digits) will have to be passed from the "register" of the previous step to the "register" of the next exchange. = Register Signalling. DSS2 and B-ISUP perform both Line- and Register Signalling. Figure 3 770 00905 0120 VHBE Ed. 02 DSS2 and B-ISUP perform both Line- and Register Signalling. 17 / 297 1Situation of B-ISDN Signalling 1.2 1.2.1 Brief History of Signalling Systems. Analogue Signalling. What ? Analogue Signalling is the oldest kind of signalling. The line signalling relies often on a Direct Current (DC) to transport the information. When a subscriber goes off-hook, DC current is allowed to flow from the local exchange through the telephone and back to the exchange ( the switch hook from the telephone set provides the contact closure). In the exchange, a current detector will be used to determine this DC, i.e. if a connection is being requested. Further , the register signalling, i.e., the transport of the dialled digits can rely on different types of mechanisms. The most commonly spread are decadic dialling on one hand or multi-frequency dialling on the other hand. Decadic dialling uses a relay to interrupt the current, thus creating pulses (10 pulses per second). The exchange counts each series of pulse bursts to determine the dialled digit. When Dual Tone Multi-frequency (DTMF) is used, the dial creates a frequency tone, generated by mixing 2 frequencies together. The receiving exchange hears these tones and translates them back into dialled digits. Common DTMF systems are R1 or R2 signalling. Limitations 1.2.2 CAS Signalling. What ? 18 / 297 Obviously, Analogue Signalling has a lot of limitations. The main disadvantage is that only a minimum number of states can be represented by voltages and currents. Thus, Analogue Signalling offers only the basic capabilities required for telephony, like seizure of circuits, a disconnect, etc. When more supplementary services and flexibility can be offered by a network, it goes without saying that, in parallel, also signalling becomes more complicated. Then, Analogue Signalling becomes insufficient. A more recent kind of signalling is CAS Signalling. CAS is generally transported over a digital 2 Mbit/sec PCM-link. A Pulse Code Modulation (PCM)-link transports sequences of frames. Each frame contains 32 bytes, each belonging to 1 out of 32 channels. In general, channel 0 will be used for synchronization purposes (thus it will not transport any user information), while channel 16 will be reserved for the signalling. 770 00905 0120 VHBE Ed. 02 1Situation of B-ISDN Signalling The frame structure, transported over a PCM link is shown in figure 4. 0 15 16 17 1 Synchronization 31 0 Signalling Information 1 frame = 125 µsec Bitrate of 1 channel = Bitrate of the link Figure 4 = 8 bits = 64 Kbit/sec 125 µsec 32 * 64 Kbit/sec = 2,048 Mbit/sec PCM Structure Using CAS, the line signalling information is transported in channel 16, in the following way : " Channel 16 of frame 0 contains multi-frame synchronization. " Channel 16 of frame 1 contains 4 bits information related with channel 1 and 4 bits related with channel 17. " Channel 16 of frame 2 contains 4 bits information related with channel 2 and 4 bits related with channel 18. " Channel 16 of frame 15 contains 4 bits information related with channel 15 and 4 bits related with channel 31. This sequence of 16 frames, shown in figure 5, is repeated continuously and is called a Multi-frame. 770 00905 0120 VHBE Ed. 02 19 / 297 1Situation of B-ISDN Signalling 01 15 Frame 0 16 17 31 Multiframe Synchronization Frame 1 Ch 1 info Ch 17 info Frame 2 Ch 2 info Ch 18 info Ch 3 info Frame 3 Ch 19 info MULTI FRAME ... Ch 15 info Frame15 Figure 5 Ch 31 info CAS Multi-frame Examples of the 4 bit codes used are : " 1001 : IDLE " 0001 : SEIZURE " 1101 : ACK Note that only the line signalling is carried inside channel 16, by means of the CAS protocol. Register signalling, on the other hand, is carried in a digitalized format, in the user channel itself. Limitations A little calculation can show that signalling by means of CAS will be rather inefficient. " The period of a multiframe is 16 * 125 µsec = 2 msec. Thus, in a worst case situation, it can take up to 2 msec to transport information in 1 direction and again 2 msec for the other direction. I.e. the line signalling alone, can take up to 4 msec. The reason for this is that the sender is not free to choose in which frame he transmits his signalling information regarding a specific channel, in other words the time to send is "channel associated". Thus, in a worst case, the sender has to wait even if there is no other signalling information to be send. " 20 / 297 Transportation of only 1 digit, can take up to 100 msec. 770 00905 0120 VHBE Ed. 02 1Situation of B-ISDN Signalling Clearly, CAS line signalling, completed with register signalling over the user channels, is a too inefficient system for modern telecom requirements. 1.2.3 N-ISDN Signalling At the UNI : DSS1 The signalling system at the UNI, intended for the ISDN is called DSS1, also referred to as N-ISDN Signalling" or D-channel protocol". DSS1 has the following characteristics : Out-Band First, one of the goals of ISDN was the separation of the control information from the user information into logically separate (but not necessarily physically separate) paths. Thus DSS1 signalling is out-band. User data is conveyed over a so-called B-channel, while all control information is conveyed over a separate D-channel. This separation offers several benefits, as there are : " " HW intended for user paths can be kept cheaper and faster " Independent optimization of user paths and control paths is possible. " Message-Oriented Potential for integration of signalling for multimedia Voice circuits remain idle, until the distant party answers the call. On the contrary, using in-band signalling systems, voice circuits remain busy, even if the distant party never answers the call, until the calling party hangs up. Thus the utilization of voice circuits will be higher, using out-band systems. By consequence, the availability of voice circuits will be higher and the need for additional circuits decreases. Secondly, DSS1 is message-oriented, i.e. the signalling function comes down to a transport of signalling information from the user equipment to the computer controlling the local exchange, under the form of a message, having a clearly defined contents and functional definition. Thus, any call handling event (line signalling) or item of signalling information (register signalling) is converted by appropriate software into an information message. This information message is transmitted over a dedicated signalling channel to the destination. The processor in the destination will receive the information message and execute the appropriate call handling 770 00905 0120 VHBE Ed. 02 21 / 297 1Situation of B-ISDN Signalling action. Clearly, this approach offers a lot more possibilities and makes DSS1 much more powerful than its predecessors. Protocol Stack In specifying DSS1, ITU-T has also followed a layered model for communication. However, it does not completely map upon the OSI layered model for communication. The DSS1 protocol stack is organized in 3 layers, which are : " a physical conduit level " a reliable message transfer level " a call control level (also called layer 3 control) This DSS1 protocol stack is shown in figure 6. Q.931 Q.921 I.430 : BA I.431 : PRA Figure 6 Layer 3: defines all messages, their function al specification, contents and the corre sponding procedures Layer 2: provides an error-free transmission of signalling messages Physical Layer : for a Basic Access or a Pri mary Rate Access Protocol Stack for DSS1 At the NNI : CCS #7 With the introduction of computer control in the exchanges, a much more efficient signalling system (than the old CAS) came under consideration for the NNI interfaces : Common Channel Signalling System #7. CCS #7 follows the 2 same principles as DSS1, i.e., CCS #7 is also : " " Common Channel 22 / 297 Out-Band Message-Oriented Further, the signalling channel used between the two exchanges is a common transfer path for signalling info between these 770 00905 0120 VHBE Ed. 02 1Situation of B-ISDN Signalling exchanges. It can carry the signalling info for a multiplicity of trunk connections between these exchanges. This has lead to the name of "Common Channel Signalling". Typically, one signalling channel will carry the signalling information for about 1000 voice channels. On the other hand, common channel signalling requires additional measures, such as " Ordered Delivery of the signalling packets. " Addressing information, it has to be communicated quite explicitly which voice channel the signalling is about. This is demonstrated in figure 7. " Agreements concerning the kind of communication will have to be signalled, since not all voice channels will be 100% equivalent. n speech channels 1 2 Figure 7 n 3 1 Signalling channel Explicit speech channel identification in CCS #7. The overall objective of CCS #7 is to provide an internationally standardized, general purpose, Common Channel Signalling System. " that is optimized for operation in digital telecommunications networks " that can meet present and future requirements of information transfer for inter-processor transactions within telecommunication networks for call control, remote control, and management and maintenance signalling. Thus, CCS #7 is intended to be multi-purpose in multi-service networks. " 770 00905 0120 VHBE Ed. 02 that provides a reliable means for transfer of information in correct sequence and without loss or duplication. 23 / 297 1Situation of B-ISDN Signalling 1.2.4 B-ISDN Signalling The logical evolution, after the introduction of Asynchronous Transfer Mode (ATM) cross connects, is the development of ATM switches. The difference in terminology refers to the means by which the exchange is controlled, more precisely, according to Ref [1.], a cross connect is directed by management plane functions, while a switch is directed by control plane functions. Thus, new signalling protocols, suited for ATM have been developed. In the same way as for N-ISDN, these signalling protocols are organized into 2 kinds : one for the User-to-Network interface (UNI) and one for the Network-to-Network interface (NNI). This course is about : " the protocol at the UNI-side, named DSS2 (Digital Subscriber Signalling System 2). " the protocol at the NNI-side, a part of the CCS #7 system, named B-ISUP ATM versus STM Analogy Firemen, aiming to put out a fire, have several options about how to transport the necessary water. One option is to use a fire-hose. The water flows through a real, physical conduit. In fact this is a very inflexible, though simple system. " If the fire is big or little, the same fire-hose is used, and the same amount of work has to be done by the firemen. They have to hold the same hose. In fact, the capacity of the hose, and of the firemen, is not dynamically adaptable, which results in a waste of capacity. " The rate of water that is transported, depends only upon the source. The firemen, holding the hose, can not influence this. Vice versa, if a lot of water flows, or just a little, this has no impact upon the work the firemen have to do. " Even if no water flows at all, the firemen still have to hold the fire-hose. A single fireman can not decide to rest or to do another important job, if he notices no water flows. Even if not used, manpower and material are occupied. Another option for the firemen is to pass buckets of water to each other. This system is more flexible, though it requires more intelligence of each fireman. 24 / 297 770 00905 0120 VHBE Ed. 02 1Situation of B-ISDN Signalling " By passing the buckets slowly or more fast, they can influence directly the rate of water that is transported. " If different colors of buckets were used, they could even extinguish several fire sources, each of them with a dynamically adaptable rate of water. " If no buckets arrive, a fireman can smoke a cigarette, without fatiguing himself. Figure 8 Different Transport Strategies These 2 strategies can be compared to Synchronous Transfer Mode (STM) and ATM, in the sense that : " " 770 00905 0120 VHBE Ed. 02 in ATM, information is transported in cells of a fixed size (cfr. buckets) " Advantages of ATM for STM, there exists a real, physical connection, for the transportation of information, just like the fire-hose in the first example for ATM, there exists no physical connection, but a virtual" one. In the second example, a connection is only there because the firemen have made prior agreements, about the passing of the buckets. In a more complex configuration, different colors of buckets would have to be passed to different persons. ATM offers several advantages : 25 / 297 1Situation of B-ISDN Signalling " In ATM, the number of channels changes dynamically. The maximum is only limited by the requirement that each channel has to be uniquely identifiable by a header of a fixed length. If a channel is needed, it is created at that moment, for as long as required. Even signalling channels can be created dynamically by meta-signalling" procedures. In STM on the other hand, the numbers and sizes of the available channel are static and defined at the startup of the transmission system. " " In STM, the bitrate of each channel is static and unalterable. By consequence, only channels with a certain predefined bitrate can be allocated, which limits the user in his choices, in other words the granularity in STM is quite high. On the other hand, in ATM this bandwidth is dynamically allocated, which leads to a much smaller granularity. " Disadvantages of ATM In ATM, the bitrate of each individual channel is variable and independent of the bitrate of other channels. In STM, allocated channels which are not used, are wasted. In ATM, channels can be allocated and not used, without wasting bandwidth on the transmission carrier. Some disadvantages of ATM are : " In ATM, a certain amount of overhead, will have to be transported as well (cell headers), to identify the cell. An ATM has a total size of 53 bytes, with a payload (user information) of 5 bytes. This gives rise to an overhead of 5/53 per cell. An ATM cell is shown in figure 9. User Information Figure 9 " Cell Header ATM Cell Complexity The differences between STM and ATM are illustrated and summarized in figure 10. 26 / 297 770 00905 0120 VHBE Ed. 02 1Situation of B-ISDN Signalling Synchronous Transfer Mode Asynchronous Transfer Mode Channel 1 Channel 2 .. . Channel n - Reservation of Physical Channels - Reservation of Virtual Channels - Fixed number of channels. - Variable number of channels. - Fixed bitrate of channels. - Variable bitrates of channels. - Low granularity of bitrates. - High granularity of bitrates. - Physical resources are permanently - Physical resources are not used, reserved, even if nothing is if nothing is transmitted. transmitted. Figure 10 STM versus ATM ATM User-Network Traffic Contract In STM, a user can not, but use only his allocated piece of bandwidth, i.e., the channel(s) allocated to him. This channel is agreed upon at connection setup, and is communicated by means of the existing N-ISDN protocols. Also in B-ISDN, an agreement must be made between the user and the network. This agreement is called the User-Network Traffic Contract". Unlike N-ISDN, much more traffic aspects must be agreed upon. The amount, speed, burstiness and other traffic aspects of the user information (which will be transmitted) must be communicated by the B-ISDN protocols. These traffic aspects are described by Traffic Parameters", which must be 770 00905 0120 VHBE Ed. 02 27 / 297 1Situation of B-ISDN Signalling " understandable by the user itself, for possible auto-compliance testing. " be usable to determine if a requested connection can be allowed, i.e., if the network is able to satisfy the requested traffic contract. " be enforceable by the network, i.e. the network can take actions in case a malicious user does not keep the traffic contract. All these aspects increase the required capability of B-ISDN signalling procedures. Indeed, a traffic contract must be communicated or even negotiated. 28 / 297 770 00905 0120 VHBE Ed. 02 2 Architecture of B-ISDN Signalling 2 Architecture of B-ISDN Signalling This chapter describes the protocol stacks used for B-ISDN signalling purposes, at the UNI as well as at the NNI interfaces. These protocol stacks are prescribed by Ref.[18.]. 770 00905 0120 VHBE Ed. 02 29 / 297 2 Architecture of B-ISDN Signalling 2.1 Layered Systems Modularity Telecommunication networks change enormously. The purely telephone network is evolving into a general purpose B-ISDN network capable of transporting all kinds of user information. In order to cope with this changing environment, very flexible signalling systems are required, which can perform signalling functions for all kinds of telecom applications, already existing, or even future applications yet to be defined. In order to obtain this flexibility, layered structures are required. The fundamental principle is the division of functions into a separate layer. The OSI model accepted by the International Telecommunicaton Union (ITU-T) (Ref [59.]) in 1980 offers a structured approach to this problem. It uses a 7 layers model. Unfortunately, this OSI model is not always followed in the defined protocol stacks. Reasons for this are : " Bad timing of the development. Several protocol stacks (e.g. TCP/IP) were already widespread before the OSI model was finished. " Bad technology The OSI model is extraordinary complex. It is difficult and inefficient to implement it. In despite of that, the fundamentals of a layered structure remain in all protocol stacks. A layer, performing a certain functionality, can be reused in other protocol stacks". Or a complete layer, can be changed by another layer, providing the same functionality, without altering the rest of the stack. We will see that this is the case for B-ISDN Signalling. We will describe the protocol stacks for B-ISDN Signalling at the UNI and at the NNI. 2.2 At the UNI : DSS2 DSS2 Protocol Stack Naturally, for DSS2 the necessary adaptions and extensions have been made so it can be used in an ATM environment. First, the protocol stack has been changed since the transport of the messages will be done via ATM cells. Above the ATM layer, which provides transport of ATM cells without any processing like error control, there is an Signalling ATM Adaptation Layer (SAAL). 30 / 297 770 00905 0120 VHBE Ed. 02 2 Architecture of B-ISDN Signalling This SAAL layer is further divided into : " an ATM Adaptation Layer 5 (AAL-5) Common Part " an SSCOP Layer (Service Specific Connection Oriented Protocol) " an SSCF Layer (Service Specific Control Function). The highest layer in DSS2 is described in Q.2931, which is the BB version of Q.931, also called DSS2 Layer 3. It describes all messages and procedures for point-to-point connections. It can be extended by Q.2961 (for additional parameters and procedures) and by Q.2971 (which describes the procedures for point-to-multipoint call control). Even more extensions are made by the ATMForum UNI 4.0 specification, which can replace Q,2931 and Q.2971 all together. The protocol stack for DSS2 is shown in figure 11. Q.2931/61/71. Q.2130 SSCF Q.2110 SSCOP AAL5 Service Specific I.363.5 AAL5 Common Part I.361 ATM Layer I.432 Physical Layer Figure 11 OSI Mapping SAAL Protocol Stack for DSS2 Obviously, the physical layer corresponds to OSI Layer 1. The ATM Layer and the complete SAAL Layer corresponds to OSI Layer 2. Finally, the highest layer Q.2931 corresponds to OSI Layers 3 - 7, just as Q.931 does for the Narrowband case. Starting from DSS1, several Information Elements (IEs), which are the parameters of the signalling messages) have been deleted or some have been added in Q.2931 in comparison to Q.931. Obviously, an ATM connection requires other characteristics to be conveyed by the messages than an STM connection, as there are : 770 00905 0120 VHBE Ed. 02 31 / 297 2 Architecture of B-ISDN Signalling " ATM Traffic Descriptor " OAM Traffic Descriptor " Quality of Service Parameters " Type of AAL " Communication Configuration " etc. Another difference is that, unlike in DSS1, the order of the IEs in a DSS2 message is not restricted. The parameters of a DSS2 message can come in a variable order. Of course, there are prescriptions about which parameters are allowed, mandatory or optional in a message. 2.3 At the NNI : B-ISUP At the NNI, either the ATM network or, as a national option, the existing CCS #7 network can be used for signalling information transfer. Option 1 The first option is shown in figure 12. Q.2761-Q.2764 Q.704. B-ISUP MTP-3 Q.2140 SSCF Q.2110 SSCOP AAL5 Service Specific I.363.5 AAL5 Common Part I.361 ATM Layer I.432 SAAL Physical Layer Figure 12 Protocol Stack for B-ISUP using an ATM network , Note that a lot of layers are the same as the ones for the DSS1 stack. Only the 3 highest layers differ. 32 / 297 770 00905 0120 VHBE Ed. 02 2 Architecture of B-ISDN Signalling Option 2 However, as an intermediate solution, an operator can decide to use his existing CCS #7 network, to provide for the B-ISDN signalling. This means he will reuse his narrowband links, which follow the classical CCS #7 protocol stack. Only B-ISUP will now replace the narrowband ISUP The stack for this option is shown in . figure 13. Q.2761-Q.2764 Q.704. B-ISUP MTP-3 Q.703 MTP-2 Q.702 MTP-1 Figure 13 MTP Protocol Stack for B-ISUP using an ATM network , The lowest layer is the Message Transfer Part (MTP). The overall function of MTP is to serve as a transport system, providing reliable transfer of signalling messages between the locations of communicating user functions. MTP consists out of 3 sub-layers. " MTP-1 (or Signalling Data Link Functions) It takes care of the physical and electrical layer functions of the information transfer; in other words the pure transmission of bits from Signalling Point to Signalling Point. The functionality of this layer corresponds to OSI-layer 1. " MTP-2 (or Signalling Link Functions) It takes care of error-free transmission of messages over one individual signalling link. This layer performs error detection and error correction actions on these messages. The functionality of this layer corresponds to OSI-layer 2. " 770 00905 0120 VHBE Ed. 02 MTP-3 (or Signalling Network Functions) falls into two major categories. 33 / 297 2 Architecture of B-ISDN Signalling D First, it takes care of the "Signalling message handling functions". This functionality includes routing, message discrimination and distribution. In every signal point, MTP-3 will analyze the contained addressing information and message discrimination will decide whether the message has to be routed further, or whether the message has to be delivered to the correct higher layer (= message distribution). D Secondly, MTP-3 will also perform "Signalling network management functionality". These control the current message routing and configuration of the signalling network facilities and in the case of signalling network failures, control the reconfigurations and other actions to preserve or restore the normal message transfer capability. The functionality of MTP-3 corresponds partly to OSI-layer 3. Again, to summarize, the complete MTP is capable of sending messages through the network. In addition, error detection and correction, as well as flow control functionality is provided. User Parts On top of MTP several "User Parts" can run. Each User Part , supports a specific application, and can use its own set of signalling messages and related defined actions for a certain type of user. Note It should be clear that all User Parts make use of MTP which will , deliver the information to the requested destination, in the correct sequence and virtually free of errors. Indeed, this capability is common. B-ISUP is the User Part for the B-ISDN Signalling. 2.4 Selection of most relevant Items. For reasons of conciseness, the complete B-ISDN Signalling system can not be discussed in this document. A selection is made to discuss the most relevant items. They are : " the ATM Layer : see chapter 3. " the Common Part of the AAL 5 : see chapter 4. 34 / 297 770 00905 0120 VHBE Ed. 02 2 Architecture of B-ISDN Signalling " SSCOP : see chapter 5. " SSCF at the UNI and the NNI : see chapter 6. " MTP-3 see chapter 7. " The layer 3 control protocols Q.2931, Q.2961 (for point to point) and Q.2971 (for point to multipoint) see chapter 8 " B-ISUP see chapter 9. Note 770 00905 0120 VHBE Ed. 02 Note : Primitives between layer n+1 and layer n, in other words services requested by layer n+1 and offered by layer n, will always be treated in the chapter concerning layer n, i.e. the offering layer. 35 / 297 2 Architecture of B-ISDN Signalling 36 / 297 770 00905 0120 VHBE Ed. 02 3 The ATM Layer 3 The ATM Layer In this chapter, the services provided by the ATM layer, are presented. In particular, we are interested in which signalling channels must be used, i.e. which VPI/VCI values have to be filled in the cell header. At the end of the chapter, we shall be able to construe a complete cell header, for signalling cells. The ATM layer is completely described in Ref.[6.]. 770 00905 0120 VHBE Ed. 02 37 / 297 3 The ATM Layer 3.1 Services provided by the ATM layer : The services of the ATM layer, according to Ref.[3.], are presented in this section. Common Service for User Plane and Control Plane The following three functions present nothing new, in comparison with the functionality of the ATM layer for the user plane. " Generic Flow Control A slow receiver can give feedback information to a fast sender. " Cell multiplexing /demultiplexing In the transmit direction, the cell multiplexing function combines cells from individual Virtual Paths (VPs) and Virtual Channels (VCs) into a non-continuous composite cell flow.. In the receive direction, the cell demultiplexing function directs individual cells from a non-continuous cell flow to the appropriate VP or VC. " Cell VPI/VCI translation This function occurs at the VP/VC switches and cross-connects. The value of the Virtual Path Identifier (VPI) and/or Virtual Channel Identifier (VCI) fields of each incoming ATM cell is mapped into a new VPI/VCI value. This mapping function can be null. Cell Header However, the following function is specifically important within the scope of this course : " Cell header generation and extraction This function applies at each point where the ATM layer is terminated. For signalling channels, this is in each switch or cross-connect, and at the user equipment. In the transmit direction, the cell header generation function receives a cell information field from a higher layer and generates an appropriate cell header. In the receive direction, the cell header extraction function removes the ATM cell header and passes the cell information field to a higher layer. In this chapter, we have a brief discussion about the signalling channels to be used, in other words which VPI/VCI values have to be filled in in the cell header. At the end of the chapter, we shall be able to construe a complete cell header. 38 / 297 770 00905 0120 VHBE Ed. 02 3 The ATM Layer 3.2 Signalling channels Logical and Physical Separation As previously mentioned, user channels and control channels are separated. In DSS1, this separation was realized using logically separated B and D channels. In DSS2, a separate Signalling Virtual Channel (SVC) is used. Thus, the separation will also be logical, but it can even be physical. A virtual channel upon an interface is completely identified by specifying its VPI (Virtual Path Identifier) and its VCI (Virtual Channel Identifier). We consider only point-to-point signalling VCs. Meta-signalling (the dynamic allocation of SVCs via a meta signalling channel") is not described in this course. Nor are broadcast signalling VCs. Both these concepts are described in detail in Ref [2.]. UNI Ref [6.] prescribes that VPI/VCI= 0 /5 shall be reserved for the user signalling towards the local exchange. This situation is depicted in figure 14. In that case, for VPI values other than 0, the VCI = 5 is reserved for signalling with other signalling entities (e.g. other users or remote networks). SVC : VPI/VCI = 0/5 Local BB User ATM Switch Figure 14 SVC at the UNI However, the rule described above is not followed in the following cases : 770 00905 0120 VHBE Ed. 02 39 / 297 3 The ATM Layer " If a bilateral agreement is made between the user and the network to support associated signalling , a SVC with VPI/VCI = x/5 will have to be installed for each VP . In this context, associated" means that the signalling channel of a user VC will always be VCI = 5 of the same VP . Obviously, associated signalling is unlike the situation of figure 14, which employs quasi-associated" signalling, i.e. VPI/VCI = 0/5 carries the control information of other user VCs, even belonging to another VP . " If VP cross connects are present between the subscriber equipment and his local ATM switch, more than 1 SVC will have to be used. In that case, a Virtual Path Connection Identifier (VPCI) will have to be used to uniquely identify the VP connection on both sides. ATTENTION Meaning of a VPCI The VPCI is an identifier that represents a VPI on a given interface. The value of this field is not identical to the value used in the VP field of the corresponding ATM cell header. The VPCI/VCI value uniquely identifies a particular Virtual Channel, on both sides, even if intermediate VP Cross-Connects are present. Obviously, one SVC with VPI/VCI = 0/5 will not suffice anymore, since different VPs can be cross connected to different ATM switches. Therefore, the signalling information between the user and the VP cross connect will be carried in any VPI/VCI = x/5., which is agreed upon at subscription time. Signalling information is transparent for the VP cross connect and the VPI = x will be connected to a VPI = y. After the VP cross connect, the signalling information will be carried via VPI/VCI = y/5. This situation is depicted in figure 15, where the SVC controls only 1 physical interface, between the user and the VP cross connect. 40 / 297 770 00905 0120 VHBE Ed. 02 3 The ATM Layer SVC1 : VPI/VCI = 20/5 VPI VPCI 20 SVC1 : VPI/VCI = 0/5 SVC2 : VPI/VCI = 2/5 inVPI 0 1 21 22 VP Cross Connect VPI 0 1 1 2 Local ATM switch SVC2 : VPI/VCI = 22/5 BB User 0 1 20 2 VPCI 21 outVPI 0 VPI VPCI 2 22 2 Local ATM switch Figure 15 2 SVCs on a Single Interface, Cross Connect, quasi-associated Signalling As can be seen in figure 15, at the user side the VPCI equals the VPI, if there is only 1 interface between the user and the VP cross connect. Of course, this will not be the case anymore if multiple interfaces are present. In that case the VPCI value will depend upon both the interface value and the VPI. This situation is depicted in figure 16 . In essence, nothing changes as far as the SVC is concerned. It should only be clear that one SVC can even control VCs on multiple interfaces. 770 00905 0120 VHBE Ed. 02 41 / 297 3 The ATM Layer SC1 : VPI/VCI =2 0/5 VPI SC1 : VPI/VCI = 0/5 SC2 : VPI/VCI = 1/5 Itf_id inVPI 0 1 0 21 1 1 31 Local ATM switch SC2 : VPI/VCI = 30/5 VPCI ITFid VPI 1 0 0 1 1 VPCI 0 4 VP Cross Connect 1 3 VPI 0 2 3 30 1 1 21 20 0 BB User 20 outVPI 0 VPCI 1 30 2 31 4 Local ATM switch Figure 16 2 SVCs on Multiple Interfaces, Cross-Connect, quasi-associated Signalling NNI For the NNI, all VPI values, with VC =5 shall be reserved for point-to-point signalling. Associated and Quasi-Associated Signalling can be supported. SVC : VPI/VCI =x/5 ATM Switch Figure 17 3.3 ATM Switch SVC at the NNI Primitives exchanged with the SAAL Primitives The information exchanged between the ATM layer and the upper layer (=SAAL) across the ATM-Service Access Point (SAP) includes only 2 primitives, described in Ref [6.]. " ATM-DATA request (ATM-SDU, ATM_LP_tr, ATM_CI, AUU) This primitive is issued by the SAAL to request the transfer of 48 octets (= ATM-Service Data Unit (SDU)), over the ATM connection. The parameters are required to assign the proper Cell Loss Priority (CLP) and Payload Type Identifier (PTI) fields to the header of the ATM cell. 42 / 297 770 00905 0120 VHBE Ed. 02 3 The ATM Layer " ATM-DATA indication (ATM-SDU, ATM_LP_rec, ATM_CI, AUU) This primitive indicates to the SAAL the arrival of an ATM-SDU over the ATM connection. The parameters were retrieved from the CLP and the PTI fields of the header of the ATM cell. The exchange of the primitives between the ATM layer and the SAAL layer is shown in figure 18. SAAL ATM-DATA request ATM-DATA indication ATM-SAP ATM-SAP ATM Layer transport of the ATM cell Figure 18 Parameters Primitives between the ATM and the SAAL layer The parameters of these primitives are the following : " ATM-SDU (ATM Service Data Unit) This parameter describes the 48 octets of user data, carried in the payload of the ATM cell. " ATM_LP_tr (ATM Loss Priority transmitted) : This parameter indicates the relative importance of the requested transport of the ATM-SDU. It can only take 2 values : D D 770 00905 0120 VHBE Ed. 02 a "0" is used for "high priority" a "1" is used for "low priority" 43 / 297 3 The ATM Layer " ATM_LP_rec : This parameter has the same meaning as ATM_LP_tr but now it refers to the received value. The values of ATM_LP_tr and ATM_LP_rec can be different, when cell tagging has been applied, see Ref [10.]. A high priority cell, can be tagged by a police function, if it does not satisfy the agreed traffic contract. In that case, it becomes a low priority cell ( =tagging). A more radical option is to discard the complete cell. D ATM_CI (ATM Congestion Indication) This parameter is used to indicate that the received ATM-SDU has passed through a network node in congestion. D AUU : ATM-user-to-ATM-user indication. This parameter is transported transparently by the ATM layer. It will be used by the AAL 5 Common Part Layer. Obviously, in the absence of error, the ATM-SDU which was transmitted by means of the ATM-DATA request, equals the ATM-SDU of the ATM-DATA indication. However, absence of error is not guaranteed by the ATM layer, neither is the absence of cell loss or cell misinsertion. These tasks are not performed by the ATM layer by the SAAL. 3.4 The complete ATM cell header. Reference [6.] not only specifies which VPI/VCI values have to be used for ATM cells carrying signalling information. It also specifies which values have to be used for the ATM_LP_tr and the PTI fields. As could be expected, the ATM_LP_tr has to be set to "0", which comes down to saying that cells carrying signalling information have a relatively high importance. The allowed values of the PTI field of cells carrying signalling information, are shown in the next table. 44 / 297 770 00905 0120 VHBE Ed. 02 3 The ATM Layer Table 1 Coding of the PTI Field of ATM Cells, carrying Signalling Information. PTI Coding Interpretation 000 User Data Cell No Congestion AUU = 0 001 User Data Cell No Congestion AUU = 1 010 User Data Cell Congestion AUU = 0 011 User Data Cell Congestion AUU =1 Thus, we do have enough information to specify the complete ATM cell header of transmitted cells carrying signalling information. These headers (for the UNI and the NNI) are shown in figures 19 and 20. 8 7 6 5 4 3 2 GFC 0 0 1 0 0 VCI 0 0 VCI 1 HEC Figure 19 770 00905 0120 VHBE Ed. 02 0 0 0 VCI 0 PTI Bit Octet 1 VPI VPI 0 1 0 0 2 0 0 3 CLP 0 4 5 ATM Cell Header for Signalling Cells at the UNI 45 / 297 3 The ATM Layer 8 7 6 5 4 3 2 1 0 0 1 0 0 0 VCI 0 0 VCI 1 HEC Figure 20 Octet 1 VPI VPI Bit 0 0 0 VCI 0 PTI 0 0 2 0 0 3 CLP 0 4 5 ATM Cell Header for Signalling Cells at the NNI To summarize, the VPI of a signalling cell can take any value , but at the UNI preferably VPI = 0, will be used for signalling to the local exchange. On the other hand, the VCI should always equal 5. Further, as well bit 4 inside the PTI-field (user data cell) and the CLP-field (high priority) should equal 0, when the cell is transmitted. Finally, the GFC-field and bits 2 and 3 inside the PTI-field are available for use by the appropriate ATM layer functions, in the same way as they are for user data cells. Naturally, the HEC-field performs the same error control. This provides us with all information to identify a signalling cell, or in other words, a signalling (virtual) connection, which is the major functionality of the ATM layer. In the next chapter, we jump to the next layer, which adds its own functionality. 46 / 297 770 00905 0120 VHBE Ed. 02 4 Common Part of the AAL-5 4 Common Part of the AAL-5 In this chapter, the detailed architecture of the AAL for Signalling (SAAL), which is AAL-5, is first presented. Further, the Common Part of this SAAL is explored in detail. Its services, mechanisms and primitives are presented. The Common Part of the AAL-5 is described completely in Ref.[9.]. 770 00905 0120 VHBE Ed. 02 47 / 297 4 Common Part of the AAL-5 4.1 Architecture of the AAL-5 The ATM Adaptation Layer used for signalling purposes (SAAL) will be the AAL-5, as is recommended in Ref[19.]. As mentioned previously, the AAL-5 consists of several sublayers. Four basic sublayers can be identified, which are, from top to bottom : " " the CPCS: Common Part Convergence sublayer. " Service Specific and Common Part the SSCOP: Service Specific Connection Oriented Protocol. " CS and SAR the SSCF: Service Specific Coordination Function. the SAR: Segmentation and Reassembly sublayer. On one hand, the SSCOP and the SSCF together form the Service Specific Convergence Sublayer (SSCS). The SSCS together with the Common Part Convergence Sublayer (CPCS) constitutes the complete Convergence Sublayer (CS). In this way, the complete AAL-5 is divided into two major sublayers : the Segmentation and Reassembly (SAR) and the CS. This is shown at the right side of figure 21. On the other hand, another division can be pursued. The two upper layers, the SSCF and the SSCOP are service specific. , Different SSCS services exist and are described in separate recommendations. They constitute the Service Specific Part. This part will, as far as the SAAL is concerned, be described in the next chapter. The two lower layers, the CPCS and the SAR are called the AAL-5 Common Part and are described in Ref [9.]. ATTENTION Although the name Common Part" suggests otherwise, this is rather misleading, since the AAL-5 CPCS is not at all common to the different AAL layers : i.e., AAL-1, AAL-2, etc.... The name Common" rather suggests that CPCS can have several, different users, i.e., CPCS is common to all its users. In this way, the complete AAL-5 is divided into two other major sublayers : the Service Specific Part and the Common Part. This division is shown at the left side of figure 21. 48 / 297 770 00905 0120 VHBE Ed. 02 4 Common Part of the AAL-5 AAL-SAP Service Specific Part SSCF SSCS SSCOP CS CPCS Common Part SAR SAR ATM-SAP Figure 21 The Structure of the SAAL The Common Part of the AAL-5 is explained in this chapter. 4.2 4.2.1 Services of the AAL-5 Common Part Services The Common Part of the AAL type 5 enables the transfer of an CPCS-SDU from one CPCS user to one or more other CPCS users through the ATM network. The following main services are provided by the CPCS and the SAR : " Non-assured data transfer of user data frames (CPCS-SDUs) with any length from 1 to 65 535 octets. " Error detection and handling. Note that the term "handling" by no means implies that errors will be corrected. It simply means that corrupted frames will be either discarded completely, or they will be optionally delivered to the CPCS user, with a suited notification. " Transparent transport of CPCS user-to-user information. " Passing of Congestion Information, between the higher and the lower layers. " Passing of Loss Priority Information, between the higher and the lower layers. How these services are performed by the Common Part of AAL-5 is explained below. However, first we shall introduce two 770 00905 0120 VHBE Ed. 02 49 / 297 4 Common Part of the AAL-5 restrictions to the scope of this layer. Indeed, the functionality of the AAL-5 Common Part is narrowed down if it is used for signalling purposes. 4.2.2 Scope Restriction for Signalling Purposes Message Mode and Streaming Mode First, in Ref.[9.], two modes of service are defined for the CPCS, to wit the "message mode" and "streaming mode". In the message mode, the CPCS-SDU must be delivered in one piece to the CPCS. In the streaming mode, this CPCS-SDU can come in pieces, separated in time, and it will be the responsibility of the CPCS to collect these pieces and pack them together for transport into one CPCS-PDU, which can be gradually transported, even before the complete CPCS-SDU is available. Since Ref. [19.] clearly prescribes that the CPCS for the AAL-5 should operate in the message mode service, we shall not discuss the streaming mode in more detail. Corrupted Data Delivery Secondly, the CPCS can be fitted with a "corrupted data delivery" option. If the CPCS detects an error in a received CPCS-SDU, it will normally discard the whole frame and give not any notification to the CPCS user. However, if the corrupted data delivery option is applied, then the corrupted frame will be delivered to the CPCS user, together with some error flags, like "ok", "illegal CRC", "illegal CPI", or "illegal length", which serve the purpose of helping the CPCS user in recovering from these errors. Since ref.[20.] assumes the CPCS to operate without the option of corrupted data delivery, it shall not be discussed further. 4.3 Mechanisms of the AAL-5 Common Part Now let us get back to the question of how the Common Part of AAL-5 realizes the services described above. 4.3.1 The CPCS-PDU First of all, at the sending side, the CPCS will construe out of the offered CPCS-SDU a CPCS-Protocol Data Unit (PDU), by adding " " 50 / 297 a Padding Field and a CPCS-PDU trailer. 770 00905 0120 VHBE Ed. 02 4 Common Part of the AAL-5 The contents of the CPCS-PDU trailer is shown in figure 22. Padding Field CPCS-SDU 2 1 CPCS-UU Figure 22 3 CPI 4 5 Length 0000 0000 CPCS-PDU Trailer (0...47 octets) (of the CPCS-SDU) (8 octets) 6 7 8 CRC The CPCS-PDU Format for the AAL Type 5 Padding Field CPCS-PDU Trailer The length of the padding field will be choosen such that the CPCS-PDU will consist out of an integral multiple of 48 octets. Therefore, its length can vary from 0 to 47 octets. The CPCS-PDU trailer consists out of : " CPCS_UU : CPCS-user-to-user-indication. This parameter is transported transparently. " CPI: Common Part Indicator. This byte shall always be set to "0000 0000". For the moment, its only function is to align the CPCS-PDU trailer to 8 octets. Additional functions could possibly be the identification of layer management messages, in which case its coding would be different. " Length : This field is used to encode the length of the CPCS-SDU. It allows the receiver to identify the Padding Field (which has a variable length). This is necessary to retrieve the CPCS-SDU. Its length is encoded as number of octets. Since this field has only a length of 2 bytes, this imposes a limitation upon the maximum length of the transported CPCS-SDU of 216 - 1 = 65 535 octets. The length field is also used by the receiver to detect the loss or gain of information. 770 00905 0120 VHBE Ed. 02 51 / 297 4 Common Part of the AAL-5 " CRC : A .Cyclic Redundancy Check (CRC)-32 calculation is performed over the entire contents of the CPCS-PDU, i.e. the CPCS-SDU, the Padding Field and the first four octets of the CPCS-PDU trailer. This calculation allows the receiving CPCS user to detect errors. However, error correction (by retransmission for instance) is not a function of the CPCS. A corrupted frame can be either discarded, or optionally it can be delivered with an error notification. 4.3.2 The SAR Functionality Segmentation After the CPCS functionality, the SAR will divide the received CPCS-PDU into n times 48 octets. Each of these 48 octets will be offered to the ATM layer, as an ATM-SDU, and it will be transported in the payload of 1 ATM cell. No Reassembly However, at the peer side, the SAR does not perform a reassembly, as such. Instead, it passes every SAR-PDU towards the CPCS which will put it in a reassembly buffer. What the SAR does provide is an "end of SAR-SDU" indication, i.e., it will notify the CPCS when the last SAR-PDU has been received. The CPCS will be responsible for the final assembly of the CPCS-PDU and after having stripped of the Padding Field and the CPCS-trailer, it will posses again the original envoyed CPCS-SDU. The complete naming conventions for the AAL-5 Common Part can be seen in figure 23. 52 / 297 770 00905 0120 VHBE Ed. 02 4 Common Part of the AAL-5 CPCS CPCS-SDU CPCS-PDU payload SAR CPCS-PDU trailer SAR-SDU SAR-PDU SAR-PDU SAR-PDU ATM-SAP ATM Layer ATM-SDU Cell header Figure 23 Cell payload AAL-5 CP Data Unit Conventions Last SAR-PDU Now only a few questions remain. One of them is how the receiving SAR is able to find out, when it has received the last ATM-SDU, because it has to pass that information towards the CPCS. Evidently, this information must be transmitted by the transmitting SAR. As we saw in chapter 2, an AUU parameter could be used to convey transparently ATM user-to-user information and this is exactly what shall be done.: " an AUU = 0 shall be transmitted for all cells except the last one. " the last ATM-SDU shall be conveyed in an ATM cell, carrying AUU =1. Finally, recall that the encoding of the AUU happens in the last bit of the PTI field of the ATM cell header. 770 00905 0120 VHBE Ed. 02 53 / 297 4 Common Part of the AAL-5 Congestion and Priority Handling Finally, the AAL-5 Common Part should also perform a congestion information handling and a priority handling. At the sender side, this is absolutely straight-forward. Congestion information and a priority parameter are given as input to the CPCS layer which simply passes them through to the SAR. (Ref.[20.] prescribes that the SSCOP should hand over CPCS_CI =0 and CPCS_LP=0.) The SAR keeps these values in memory and uses them for each ATM-DATA request primitive it issues to the ATM layer. Naturally, at the receiving side, this procedure is not possible. A number of ATM-DATA indications, let us say n, are received by the SAR, each with their own ATM_CI and ATM_LP_rec parameter. All these values will be passed towards the CPCS. But then, the CPCS shall draw only 1 distinct parameter for congestion and 1 parameter for the priority out of these 2 sets of n values, to wit the CPCS_LP and the CPCS_CI. Procedures in Ref.[9.] are defined such that the ATM_CI value, received in the last ATM-DATA indication, will be passed towards the CPCS user as the CPCS_CI. Thus, congestion is only reported to the higher layers, if the last ATM cell experienced it. For the treatment of the priority information, the situation is different. Only the lowest priority of all ATM cells shall be retained. In other words, if at least one ATM-SDU is transmitted with low priority, i.e at least one ATM_LP_rec =1, a CPCS_LP =1 will be passed towards the CPCS user. Otherwise a CPCS_LP = 0 will be passed. 4.4 Primitives of the AAL-5 Common Part Two kinds of primitives are described here. " Primitives between the CPCS and the SAR " Primitives between the higher layer and the CPCS Because no SAPs are defined between sublayers, these primitives will not carry the names "request" and "indication". Instead, they will be called "invoke" and "signal". In fact, this difference in terminology stems from the simple fact that the OSI layer model does not allow sublayering. As far as we are concerned, it is only a difference in name. 54 / 297 770 00905 0120 VHBE Ed. 02 4 Common Part of the AAL-5 4.4.1 Primitives between the CPCS and the SAR The information exchanged between the CPCS and the SAR includes only the following 2 primitives : " SAR-UNITDATA invoke (ID, SAR_LP SAR_CI) , " SAR-UNITDATA signal (ID, More, SAR_LP SAR_CI) , The parameters have the following meaning : " ID : Interface Data. This parameter specifies the interface data unit exchanged between the CPCS and the SAR. It must be an integral multiple of 48 octets. At the receiving side, it will always be exactly 48 octets. " More : this parameter specifies whether the ID contains the end of the SAR-SDU. A value of 0 specifies that it does contain the end. Note that this notation is just the opposite as the one used for the encoding of the AUU. Thus : D D " If an ATM-SDU is received with an AUU =0 (indicating a segment) an SAR-UNITDATA signal with More =1 shall be sent towards the CPCS. Vice versa, if an ATM-SDU is received with an AUU=1(indicating it is the last ATM cell containing a part of the CPCS-SDU), an SAR-UNITDATA signal with More =0 shall be sent towards the CPCS. SAR_LP (SAR Loss Priority) This parameter indicates the loss priority for the associated SAR ID. It is mapped to the ATM_LP_tr on the sending side and copied from the ATM_LP_rec at the receiving side. " SAR_CI (SAR Congestion Indication) This parameter indicates whether the associated SAR ID has experienced congestion. It is mapped to and from the ATM_CI. 4.4.2 Primitives between the higher layer and the CPCS The information exchanged between the CPCS, operating in the message mode, and the upper sublayer (= SSCS) includes only the following 2 primitives : 770 00905 0120 VHBE Ed. 02 55 / 297 4 Common Part of the AAL-5 " " Note CPCS-UNITDATA invoke (ID, CPCS_LP CPCS_CI, , CPCS_UU) CPCS-UNITDATA signal (ID, CPCS_LP CPCS_CI, , CPCS_UU) For the sake of completeness, it should be mentioned that Ref. [9.] describes more primitives, but only if the CPCS operates in streaming mode, i.e primitives for the use of the abort" service. The parameters have the following meaning : " ID (Interface Data) This parameter specifies the interface data unit exchanged between the SSCS and the CPCS. If the CPCS operates in message mode, it corresponds to one complete CPCS-SDU. It is a multiple of one octet, with a maximum of 65 535. " CPCS_LP (CPCS Loss Priority) This parameter indicates the loss priority for the associated CPCS-SDU. " CPCS_CI (CPCS Congestion Indication) This parameter indicates whether the associated CPCS-SDU has experienced congestion. " CPCS_UU (CPCS user-to-user indication) This parameter is transparently transported by the CPCS between peer CPCS users. 4.5 Summary The complete handling, the successful segmentation and reassembly of a CPCS-SDU, together with all the used primitives coming from the CPCS user, via the CPCS and the SAR towards the ATM layer, and back is shown in figure 24. It is worthwile stressing that in fact, the SAR does perform a real segmentation, although it does not perform a real reassembly. It merely passes all SAR-PDU as they come along towards the CPCS where they are collected into a reassembly buffer. The SAR does provide an indication of the last SAR-PDU, and in this way it keeps the control over the reassembly procedure. 56 / 297 770 00905 0120 VHBE Ed. 02 4 Common Part of the AAL-5 SSCS CPCS-UNITDATA invoke CPCS Add Padding Field Add CPCS trailer CPCS-SDU SAR-UNITDATA invoke SAR SAR-SDU SAR-PDU Set AUU bit SAR-PDU SAR-PDU AUU=0 SAR-PDU AUU=0 AUU=0 SAR-PDU AUU=1 SAR-PDU Interpret AUU bit SAR-PDU SAR-PDU CPCS SAR UNITDATA signal SAR UNITDATA signal SAR UNITDATA signal CPCS-SDU SSCS Figure 24 SAR UNITDATA signal Strip Padding Field Strip CPCS trailer CPCS-UNITDATA signal Handling of a CPCS-SDU Sending Side At the sending side, the following rules apply : " 770 00905 0120 VHBE Ed. 02 ATM_CI = SAR_CI = CPCS_CI 57 / 297 4 Common Part of the AAL-5 " ATM_LP_tr = SAR_LP = CPCS_LP Although it is outside the scope of this chapter, it is opportune to mention here that, if SSCOP is the user of CPCS, which will be the case for signalling, then (Ref.[20.]) : D CPCS_CI = 0 The fact that CPCS_CI = 0 results in the fact that ATM cells carrying signalling information are transmitted with the second bit of the PTI field, set to 0, i.e. no congestion. D CPCS_LP = 0 The fact that CPCS_LP = 0, finally results in the fact that ATM cells carrying signalling information will be transmitted with CLP = 0, i.e. high priority. D Receiving Side CPCS_UU = 0 At the receiving side, the following rules aplly : " SAR_CI =ATM_CI " SAR_LP = ATM_LP_rec " CPCS_CI = SAR_CI of the last received SAR-UNITDATA signal " CPCS_LP = max (SAR_LP) of all received SAR-UNITDATA signals, i.e. the lowest priority. In brief, we have achieved thus far : G unassured information transfer of a message G segmentation and reassembly of this message G error detection We shall now proceed with the next layer, which adds additional functionality. 58 / 297 770 00905 0120 VHBE Ed. 02 5 SSCOP 5 SSCOP To specify the SSCOP following topics will be handled in this , chapter : G the primitives between SSCOP and the higher layer SSCF G the SSCOP peer-to-peer protocol Of course, the interactions between SSCOP and CPCS were already treated in chapter 2. Now, for the first time, a treatment of the peer-to-peer protocol is included. This is since SSCOP introduces, amongst other things, the intelligence to handle lost or corrupted user-data and this is exactly what should be agreed upon in a peer-to-peer protocol. First, we shall take a look at the services, introduced by the SSCOP . The SSCOP is described completely in Ref.[20.]. 770 00905 0120 VHBE Ed. 02 59 / 297 5 SSCOP 5.1 Services provided by the SSCOP The following main functions are performed by the SSCOP : " Transfer of user-data, with sequence Integrity The order of SSCOP SDUs, submitted for transfer, is preserved. SSCOP supports both assured and unassured transfer. As far as DSS2 and B-ISUP are concerned, only the assured transfer mode is used. For DSS2, the unassured data transfer is offered by the SSCF ar the UNI, but it is not yet used (see Ref.[46.]), though it might be used in the future (e.g., broadcast signalling). On the other hand, SSCF for the NNI, does not offer the unassured data transfer service at all (see Ref.[22.]). " Error correction Through a sequencing mechanism, the receiving SSCOP can detect missing SSCOP SDUs. Errors can be corrected by the use of Selective Retransmission". A simpler retransmission mechanism, called Pullback", can not request a retransmission in a selective way, i.e., a pullback mechanism can only request a retransmission from a certain point on, even though not all retransmissions were necessary. An example of a pullback is shown in figure 25. It shows that even though M4 and M5 were already correctly received, they still will be retransmitted. 60 / 297 770 00905 0120 VHBE Ed. 02 5 SSCOP Sender M1 M2 M3 M4 M5 M3 M4 M5 M6 M4 and M5 are retransmitted unnecessarily M3 NOK Receiver M3 NOK M1 Figure 25 M2 M3 M4 M5 M3 M4 M5 M6 Pull-Back By contrast, selective retransmission is more intelligent, in the sense that particular SDUs can be identified for retransmission, and only these will be send again. Thus, unnecessary overhead can be avoided. On the other hand, more complexity is required for the receiver, since he will have to store correct, but missequenced SDUs. Sender M1 M2 M3 M4 M5 M3 M6 M3 NOK Receiver M3 NOK M1 Figure 26 770 00905 0120 VHBE Ed. 02 M2 M3 M4 M5 M4 and M5 are not retransmitted, but stored by the receiver. M3 M4 M5 M6 Selective Retransmission 61 / 297 5 SSCOP " Flow Control This function allows an SSCOP receiver to control the rate at which the peer SSCOP transmitter may send information. " Connection Control SSCOP performs simple establishment, release, synchronization and error recovery of an SSCOP connection. These control tasks always affect both transmission directions, i.e., forward and backward. Besides more simple tasks, SSCOP also possesses the intelligence to resolve problem cases, like absence of acknowledgements, contention between services or the invocation of a service before a previous one has been completed. Examples of these control functionalities are worked out in chapter 5.3.2. " Keep Alive SSCOP also takes care that, in the case of a prolonged absence of data transfer , the participating peer entities remain in a link connection established state. This is called the "keep-alive" functionality. " Local Data Retrieval This function allows the local SSCOP user to retrieve PDUs which have not yet been released by the SSCOP entity, i.e., they are still in one of the transmitter's buffers. 5.2 Primitives exchanged between SSCOP and SSCF For the sake of clarity, only the primitives, relevant for signalling purposes are shown here. This means the primitives between SSCOP and SSCS layer management will not be described. These primitives are : " MAA_ERROR " MAA_UNITDATA The same goes for other primitives, which are offered by SSCOP , but not used for B-ISDN signalling purposes. These primitives are : " Primitives 62 / 297 AA_UNITDATA The primitives offered by SSCOP and important for B-ISDN signalling are the following. 770 00905 0120 VHBE Ed. 02 5 SSCOP " Primitives for Connection Establishment : D AA-ESTABLISH request / response (SSCOP-UU, BR) D AA-ESTABLISH indication /confirm (SSCOP-UU) These primitives are used to establish a point-to-point connection for assured information transfer between peer user entities. " Primitives for Connection Termination: D AA-RELEASE request (SSCOP-UU) D AA-RELEASE indication (SSCOP-UU, Source) D AA-RELEASE confirmation ( ) These primitives are used to terminate a point-to-point connection for assured information transfer between peer user entities. " Primitives for Assured Data Transfer : D AA-DATA request (MU) D AA-DATA indication (MU, SN) These primitives are used for assured point-to-point information transfer of SDUs between peer user entities. " Primitives for Connection Resynchronization : D AA-RESYNC request / indication (SSCOP-UU) D AA-RESYNC response / confirmation ( ) These primitives are used to resynchronise the SSCOP connection. Resynchronization is performed on request of the SSCOP user. It takes precedence over the recovery service. " Primitives for Connection Recovery : D AA-RECOVER indication / response ( ) These primitives are used during recovery from protocol errors. Recovery is started upon initiative of the SSCOP itself and is reported to the SSCOP user. " Primitives for Data Retrieval : D 770 00905 0120 VHBE Ed. 02 AA_RETRIEVE request (RN) 63 / 297 5 SSCOP D AA_RETRIEVE indication (MU) These signals are used to retrieve SDUs submitted by the user for transmission but not yet retrieved by the transmitter. D AA_RETRIEVE COMPLETE indication ( ) This signal is used to indicate that there are no additional SDUs to be returned to the SSCOP user. Parameters The parameters, mentioned in the primitives above, have the following meaning : " MU : Message Unit It is used during information to convey a variable-length message, which is an integral multiple of one octet. It maps transparently into the information field of an SSCOP PDU. This parameter has a maximum length of k octets, which is determined, either by bilateral agreement, or it may be specified by the standard of the higher layer. " SSCOP-UU : SSCOP user-to-user information. It is used during connection control to a variable-length user-to-user message, which is an integral multiple of one octet. It maps transparently into the SSCOP-UU field of an SSCOP PDU. Note that this parameter is used during connection control (establishment, release, resynchronization), while an MU is used during information transfer. " SN : Sequence Number The Sequence Number (SN) parameter is used to identify a certain data transfer, which is necessary to support the data retrieval operation. " BR : Buffer Release. The Buffer Release (BR) parameter indicates whether the transmitter may release its transmission buffers and queues upon a subsequent release of the connection. The parameter also allows for the release of selectively acknowledged messages from the transmission buffer. It can assume only 2 values, either "yes" or "no". 64 / 297 770 00905 0120 VHBE Ed. 02 5 SSCOP " Source : This parameter indicates to the SSCOP user whether the SSCOP layer itself or the peer SSCOP user originated the connection release. Its values can be either "SSCOP" or "user". " RN : Retrieval Number : This parameter is used to support data retrieval. The value RN + 1 indicates the sequence number N(S) of the first SD PDU to be retrieved. A value of Unknown" indicates that only the not yet transmitted PDUs are to be retrieved. A value of Total" indicates that all the PDUs in both the transmission buffer and transmission queue are to be retrieved, i.e., the PDUs which have not yet been transmitted or which have been transmitted but are not yet acknowledged. Although it is outside the scope of this chapter, it is opportune to say here how these parameters will be used by the higher layers, i.e., by SSCF for the UNI and SSCF for the NNI. UNI NNI 5.3 5.3.1 For the UNI, things are simple. Ref. [21.] prescribes that neither "Source" nor "SN" will be used. Further, "BR" shall always be set to "yes", since no data retrieval will be supported by DSS2. Finally, the use of "SSCOP-UU" is not excluded for the future, though it is not specifically required at this time. That leaves only the "MU" parameter in the AA-DATA primitives. However, these parameters will be used at the NNI. Since, the data retrieval service can be utilized by the SAAL user at the NNI, the BR" parameter shall always be set to No" by the SSCF at the NNI. The SSCOP Peer to Peer Protocol PDU Types PDU Types This paragraph describes the SSCOP-PDUs exchanged between the SSCOP sending and receiving sides. There are 15 defined PDU types, but only 13 of them are described here. The following 2 types are irrelevant for B-ISDN signalling purposes : " 770 00905 0120 VHBE Ed. 02 UD PDU (Unnumbered Data) 65 / 297 5 SSCOP " MD PDU (Management Data) Each PDU contains a Type-field which is a 4-bit encoding of the PDU-type. Each PDU has exactly one and unique code. These PDUs types (relevant for B-ISDN signalling) and their type codes are summarized in table 2. Table 2 PDU Type Encoding PDU name Code BGN Request Initialization 0001 BGAK Request Acknowledgement 0010 BGREJ Connection Reject 0111 END Disconnect Command 0011 ENDAK Disconnect Acknowledgement 0100 RS Resynchronization Command 0101 RSAK Resynchronization Acknowledgement 0110 ER Recovery Command 1001 ERAK Recovery Acknowledgement 1111 SD Sequenced Data Transfer 1000 POLL Request for Receiver State Information 1010 STAT Sollicited Receiver State Information 1011 USTAT Padding Description Unsollicited Receiver State Information 1100 All PDUs must be an integral multiple of 4 octets. This explains the padding fields in a number of them. This padding field complements the PDU to an integral number of 4 octets. Any coding is acceptable for the padding field. Whenever a padding field is present, so will be the PL-field (Pad Length), which indicates the number of padding octets present in the PDU. Since the padding field can be only 0, 1, 2 or 3 octets long, 2 bits for the PL suffice to describe all possible lengths. Reserved Field Further, each PDU contains a reserved field (R). One function of this field is to achieve 4-octet alignment. Other functions may be defined in the future. This field shall be coded as "0". The meaning of other parameters in the PDUs will be explained in chapter 5.3.2, in which the SSCOP protocol and procedures are explained. 66 / 297 770 00905 0120 VHBE Ed. 02 5 SSCOP Trailer Oriented The SSCOP protocol is trailer oriented, meaning the protocol control information is transmitted last. This becomes obvious, if we describe the different PDU types in more detail. PDUs for Connection Establishment " BGN (Begin) : This PDU is used to establish an SSCOP connection between 2 peer entities. It requests the clearing of the peer's transmitter and receiver buffer, as well as the initialization of all state variables of the 2 peers. 1 2 3 4 1 ... SSCOP-UU n-1 n Pad (0-3 octets) R N(SQ) PL R Type N(MR) 87 65 4321 Figure 27 " Coding of BGN PDU BGAK (Begin Acknowledge) : This PDU is used to acknowledge the acceptance of a connection request from the peer. 1 1 ... 2 SSCOP-UU n-1 n 3 4 Pad (0-3 octets) R PL R Type N(MR) 87 65 4321 Figure 28 " Coding of BGAK PDU BGREJ (Begin Reject) : This PDU is used to reject a connection request from the peer. 770 00905 0120 VHBE Ed. 02 67 / 297 5 SSCOP 1 1 ... 2 3 SSCOP-UU Pad (0-3 octets) n-1 n 4 R PL R Type R 87 65 4321 Figure 29 Coding of BGREJ PDU PDUs for Connection Termination " END (End) : This PDU is used to release an SSCOP connection between 2 peer entities. The S field is mapped into the Source parameter of the AA-RELEASE indication. If the transmission of the END PDU is stimulated by the SSCOP user, this bit is set to "0", if the transmission of the END PDU is stimulated by the SSCOP itself, this bit is set to "1". 1 2 3 4 1 ... SSCOP-UU Pad (0-3 octets) n-1 R n PL R S Type R 87 6 5 4321 Figure 30 " Coding of END PDU ENDAK (End Acknowledge) : This PDU is used to confirm the release of an SSCOP connection. 1 2 1 4 R 2 R 8765 Figure 31 68 / 297 3 Type R 4321 Coding of ENDAK PDU 770 00905 0120 VHBE Ed. 02 5 SSCOP PDUs for Assured Data Transfer " SD (Sequenced Data) : This PDU is used to transfer, across an SSCOP connection, sequentially numbered PDUs containing information fields provided by the SSCOP user. 1 1 3 Info ... n 2 4 Pad (0-3 octets) PL R Type N(S) 87 65 4321 Figure 32 " Coding of SD PDU POLL (Status Request) : This PDU is used to request status information about the peer SSCOP entity. It is used by the transmitter side to get information about which SD have already been received. 1 1 R 2 R 8765 Figure 33 " 2 3 4 N(PS) Type N(S) 4321 Coding of POLL PDU STAT (Sollicited Status Response) : This PDU is used by the receiving SSCOP entity to respond to a status request (POLL) received from the transmitter side. It contains information regarding the reception status and credit information for the peer transmitter. It also contains the sequence number ( N(PS) ) of the POLL PDU to which it is a response. 770 00905 0120 VHBE Ed. 02 69 / 297 5 SSCOP 1 2 3 1 Pad List Element 1 2 Pad List Element 2 l Pad List Element l l+1 R l+3 N(PS) R l+2 N(MR) R Type 8765 Figure 34 " 4 N(R) 4321 Coding of STAT PDU USTAT (Unsollicited Status Response) : This PDU is used by the receiving SSCOP entity to inform the transmitter side about the detection of missing SD PDUs, based on the examination of the sequence number of the PDUs. It contains information regarding the reception status and credit information for the peer transmitter. 1 2 3 1 Pad List Element l 2 Pad 4 List Element 2 3 R 4 R 8765 Figure 35 N(MR) Type N(R) 4321 Coding of USTAT PDU PDUs for Connection Resynchronization " RS (Resynchronization) : This PDU is used to resynchronize the buffers and data transfer state variables of the peers. 70 / 297 770 00905 0120 VHBE Ed. 02 5 SSCOP 1 2 3 4 1 ... SSCOP-UU n-1 n Pad (0-3 octets) R N(SQ) PL R Type N(MR) 87 65 4321 Figure 36 " Coding of RS PDU RSAK (Resynchronization Acknowledge) : This PDU is used to acknowledge the acceptance of a resynchronization requested by the peer SSCOP . 1 2 1 3 4 R 2 R Type 8765 Figure 37 N(MR) 4321 Coding of RSAK PDU PDUs for Connection Recovery " ER (Error Recovery) : This PDU is used to recover from protocol errors. 1 2 1 R 2 R 8765 Figure 38 " 3 Type 4 N(SQ) N(MR) 4321 Coding of ER PDU ERAK (Error Recovery Acknowledge) : This PDU is used to acknowledge the recovery from protocol error. 770 00905 0120 VHBE Ed. 02 71 / 297 5 SSCOP 1 2 1 4 R 2 R 8765 Figure 39 5.3.2 3 Type N(MR) 4321 Coding of ERAK PDU Connection Control Establishment of an SSCOP connection The establishment of an SSCOP connection is very straightforward and is illustrated in figure 40. Only the simplest case is shown here, in which the peer SSCOP accepts the connection and no messages are lost. Evidently, a protocol is foreseen in which the BGN is retransmitted after the expiry of a timer (i.e., Timer_CC), and that for a maximum number of times (i.e., MaxCC). However, this shall not be pursued in detail. SSCOP B SSCOP A AA-ESTABLISH request BGN AA-ESTABLISH indication AA-ESTABLISH confirm Figure 40 BGAK AA-ESTABLISH response The Establishment of an SSCOP Connection Release of an SSCOP connection The release of an SSCOP connection is illustrated in figure 41. Note that at the SSCOP B, no response has to come from the SSCOP user, only an indication is sent. The remark about Timer_CC is also valid for a connection release. 72 / 297 770 00905 0120 VHBE Ed. 02 5 SSCOP SSCOP A AA-RELEASE request SSCOP B END AA-RELEASE indication ENDAK AA-RELEASE confirm Figure 41 The Release of an SSCOP Connection Resynchronization of an SSCOP connection A resynchronization procedure is to be used in the case of user-initiated re-establishment. All buffers, timers and state variables for data transfer will be reset. Resynchronization takes precedence over error recovery. Timer_CC will also be used for resynchronization. The scenario for resynchronization of an SSCOP connection is illustrated in figure 42. SSCOP B SSCOP A AA-RESYNC request RS RSAK AA-RESYNC indication AA-RESYNC response AA-RESYNC confirm Figure 42 The Resynchronization of an SSCOP Connection Recovery of an SSCOP connection The main difference between recovery and resynchronization is that the latter is initiated by the SSCOP user, whereas recovery is initiated by the SSCOP itself, due to certain protocol errors. Thus, protocol errors should normally not invoke the release of the signalling datalink, but recover it. The mentioned protocol errors are all related to the assured data transfer (sequence number problems). More specific, they are : 770 00905 0120 VHBE Ed. 02 73 / 297 5 SSCOP " a duplicate SD PDU. If an SD PDU is received with a valid sequence number, which is already present in the receive buffer. " out of sequence N(S) in POLL PDU. If the sequence number N(S) in the POLL PDU is less than the highest expected SD PDU. The highest expected SD has a sequence number which is one higher than the last received SD. A POLL, containing a N(S) which is less, should represent a POLL, which was transmitted a while ago, which is impossible, since sequence integrity is guaranteed. " reception of a USTAT with invalid values. This happens when : D the N(R) field is not within the range VT(A) to VT(S). VT(A) is the lowest SD, yet to be acknowledged. Every SD, with a sequence number lower than this, has certainly been received. VT(S) is the next SD, to be transmitted for the first time.(i.e. excluding retransmissions). Every SD, with a higher sequence number, has certainly not been received yet (since it has never been transmitted yet). N(R) is the next in-sequence SD to be received, communicated by the receiver to the sender. Clearly, VT(A) <= N(R) < VT(S), or a protocol error has occurred. D D " the list elements are not within the range VT(A) to VT(S) the first list element indicates an SDU, which is not present in the buffer containing the non-acknowledged PDUs. reception of a STAT with invalid values. This happens when : D N(PS) is not within the range VT(PA) to VT(PS) VT(PA) is the poll sequence number of the next STAT to be received. VT(PS) is the current value of the poll sequence number. N(PS) identifies the POLL, to which the STAT is a response. Clearly, VT(PA) <= N(PS) <= VT(PS) or a protocol error has occurred. D 74 / 297 the N(R) field is not within the range VT(A) to VT(S) 770 00905 0120 VHBE Ed. 02 5 SSCOP D the list elements are not smaller then VT(S) D an even list element is smaller than the previous list element D the first list element indicates an SDU, which is not present in the buffer containing the non-acknowledged PDUs. During the recovery phase, no assured data can be communicated. All buffers and state variables will be reset. An indication to the management layer is sent, at the moment recovery is started. On the other hand, the SSCOP user is informed after the datalink has successfully been recovered. Before recovery has been completed, it is hidden from the SSCOP user. The scenario for error recovery is shown in figure 43. SSCOP B SSCOP A ER AA-RECOVER indication ERAK AA-RECOVER response AA-RECOVER indication AA-RECOVER response Figure 43 The Recovery of an SSCOP Connection More complex Control Scenarios Contention between services can be resolved by SSCOP To be . concise about this, one could say that release has priority over resynchronization and recovery, and resynchronization has priority over recovery. An example in which a release overrules a resynchronization is shown in figure 44. 770 00905 0120 VHBE Ed. 02 75 / 297 5 SSCOP SSCOP A AA-RELEASE request SSCOP B END RS AA-RELEASE indication ignored ENDAK AA-RELEASE confirm Figure 44 AA-RESYNCrequest Resolution of Simultaneous Control Tasks Further, if there is an SSCOP connection control service invocation before the previous one was completely treated, the second service will overrule the first. In some case the second service might even trigger some messages, relating to the first. An example of this is shown in figure 45. An establishment following a release which has not yet finished, triggers besides an AA-ESTABLISH indication also an AA-RELEASE confirm. In that way a correct sequence of primitives is preserved. SSCOP B SSCOP A AA-RELEASE request END X ENDAK AA-RELEASE indication AA-ESTABLISH request BGN AA-RELEASE confirm AA-ESTABLISH indication AA-ESTABLISH response BGAK AA-ESTABLISH confirm Figure 45 Invocation of a Service before Completion of a Previous Service 5.3.3 Assured Data Transfer No doubt, the provision of an assured data transfer with sequence integrity is of one of the most important functions of SSCOP . 76 / 297 770 00905 0120 VHBE Ed. 02 5 SSCOP Therefore, we will describe it in more detail than the other SSCOP tasks. Buffers Naturally, in order for this to be possible buffers must exist both at the transmitting side and at the receiving side. The following queues and buffers are assumed. Note however that they are of a purely conceptual nature and should in no way restrict the implementation of the procedures. " at the transmitting side D D a retransmission queue, which contains assured data waiting to be retransmitted. D " a transmission queue, which contains assured data not yet sent. a transmission buffer, which contains assured data already transmitted, but not yet acknowledged. at the receiving side D a receiver buffer, which contains received data which have to be re-sequenced. Note, that if all SD PDUs would arrive in sequence, all data could immediately be passed to the SSCOP user and the receiver buffer would not be required. The consistency and accuracy of these buffers will be maintained by the SSCOP itself. At the transmitting side, they will have to be updated each time an SD is sent or when a STAT or a USTAT is received. At the receiving side they will be updated each time an SD is received. Priorities of PDUs When transmitting PDUs to the peer receiver, the following priority rules have to be respected : " All types of PDUs for connection control purposes (i.e., all types except the SDs) have the highest priority. Indeed, if, e.g., a congestion is detected, data transfer should be temporarily suspended in order to give priority to connection control messages. " Among the SD PDUs, retransmissions have priority over new transmissions. We will now begin to gradually explore the protocol, for assured data transfer, and the meaning of the parameters in the SD, POLL, STAT and USTAT PDUs. The case in which no data frames are corrupted nor lost is the simplest one and we will begin with this. 770 00905 0120 VHBE Ed. 02 77 / 297 5 SSCOP Perfect Case The variable N(S) denotes the sequence number of a dataframe, which is passed together in the SD. It is used to preserve the sequence integrity, as well as to detect missing data PDUs. After a certain period of time, which is defined by the expiry of the Timer_POLL , a status request happens on the initiative of the sender, i.e. a POLL PDU is transmitted by the sender SSCOP This . POLL PDU contains N(PS), the sequence number of the POLL PDU. It will also contain the sequence number N(S) of the next SD ready for transmission for the first time (i.e. retransmissions excluded). SD and POLL PDUs are numbered independently from 0 to a certain maximum n -1, where n is the modulus of the sequence numbers. Since the SD, POLL, STAT, and USTAT PDUs reserve 3 octets to contain N(S) (or N(R), N(PS) or N(MR) ), n has the value 224 -1. In other words, all sequence numbers and the arithmetic operations upon them will be affected by this modulus. The receiving SSCOP answers by sending a STAT message. STAT contains the N(PS) of the POLL message of which it is a response too, and the sequence number N(R) of the next in-sequence SD, expected to be received. Another parameter present in the STAT message is N(MR), which is the sequence number of the first SD not allowed by the receiver. In this way, the receiver can prevent the sender from transmitting SDs which he can not store, because for instance a receiving buffer overflow. In all the following examples N(MR) is chosen such, as if the receiver could keep 5 messages in his receive buffer. Of course, this is not a realistic value. In this perfect example, all messages arrive in sequence, causing the receiver buffer to be always empty. Therefore N(MR) always equals N(R) +5, i.e. 5 higher than the next SD to be received. The message sequence of an error-free data transfer, together with the transmitted parameters is shown in figure 46. 78 / 297 770 00905 0120 VHBE Ed. 02 5 SSCOP SSCOP A (sender) SSCOP B (receiver) AA-DATA request (1) SD (N(S) = 1) AA-DATA request (2) SD (N(S) = 2) AA-DATA request (3) AA-DATA indication (1) AA-DATA indication (2) SD (N(S) = 3) AA-DATA indication (3) Timer_POLL expiry POLL ( N(PS)= 13, N(S) =4) STAT(N(PS) = 13, N(MR)=9, N(R) =4) AA-DATA request (4) SD (N(S) = 4) AA-DATA indication (4) Figure 46 Error Free Data Transfer 1 missing SD The next example we discuss, is one in which one SD PDU was not received by the SSCOP-B. An SD PDU can be missing, if " it was not received by the lower layer, i.e., the CPCS. " It was received by CPCS, but in a corrupted form. In that case, it is not delivered further by the CPCS. In the example of figure 47, when the B-side receives SD(3), it detects that SD(2) was missing and therefore it saves the PDU in a buffer, since sequence integrity has to be guaranteed. In the STAT message, responding to a POLL, it reports that it is still expecting N(2) as the next SD to be received, and that N(MR) = 8. Of course, one place in the receiving buffer is now occupied by SD(2) and therefore it is not able to receive SD(8) anymore, which was the case in the previous example. What is new is the presence of the 3 List Elements in the STAT message which are denoted as {2,3,4}, meaning LE1=2, LE2=3 and LE3=4. The List Elements are used for selective retransmission requests and their meaning is the following. 770 00905 0120 VHBE Ed. 02 79 / 297 5 SSCOP " Every odd element represents the first PDU of a missing gap " Every even element represents the first PDU of a received sequence. In the example, {2,3,4} stands for "retransmit from SD(2) to SD(3) (exclusive), and retransmit everything, beginning from SD(4)". The amount of such List Elements in a STAT message is a predetermined value MaxSTAT. By default, the value of 67 is recommended, but this value can be changed on an implementation basis. The MaxSTAT parameter should not be used by the receiver for length checking, it should only be used by the transmitter for segmentation purposes. SSCOP A (sender) SSCOP B (receiver) AA-DATA request (1) SD (N(S) = 1) AA-DATA indication (1) AA-DATA request (2) AA-DATA request (3) SD (N(S) = 2) X lost frame SD (N(S) = 3) Timer_POLL expiry POLL ( N(PS)= 13, N(S) =4) This PDU is received out of sequence. Therefore, no AA-DATA indication is generated, but the PDU is stored in the receiver buffer. STAT(N(PS) = 13, N(MR)=8, N(R) = 2, This PDU is retrieved from the transmitted buffer, copied in the retransmission queue and finally retransmitted. LE = {2,3,4}) SD (N(S) = 2) AA-DATA indication (2) AA-DATA indication (3) AA-DATA request (4) SD (N(S) = 4) The PDU was retrieved out of the receiver buffer. AA-DATA indication (4) Figure 47 80 / 297 Errored Data Transfer, 1 SD is lost 770 00905 0120 VHBE Ed. 02 5 SSCOP Sequence of missing SDs The example of figure 48 is pretty much the same , except that a sequence of SD PDUs has been lost. When the B-side receives the POLL message, it knows that SD(2) to SD(4) have already been sent but were lost. Indeed, the B-side detects that the POLL message contains N(S) =5. Thus, it sends a STAT message, which contains N(R) =2, since this is still the next SD to be received. Now N(MR) = 7, since the receiver buffers already 3 PDUs. The STAT message now contains the List Elements = {2,5}. It stands for "retransmit from SD(2) to SD(5) (exclusive)". SSCOP A (sender) SSCOP B (receiver) AA-DATA request (1) SD (N(S) = 1) AA-DATA request (2) AA-DATA indication (1) SD (N(S) = 2) AA-DATA request (3) AA-DATA request (4) X SD (N(S) = 3) X SD (N(S) = 4) lost frames X Timer_POLL expiry POLL ( N(PS)= 13, N(S) =5) STAT(N(PS) = 13, N(MR)=7, These PDUs are retrieved from the transmitted buffer, copied in the retransmission queue and finally retransmitted. N(R) = 2, LE = {2,5}) SD (N(S) = 2) SD (N(S) = 3) SD (N(S) = 4) AA-DATA indication (2) AA-DATA indication (3) AA-DATA indication (4) Figure 48 Errored Data Transfer, a Sequence of SDs is Lost 770 00905 0120 VHBE Ed. 02 81 / 297 5 SSCOP Several sequences of missing SDs The example of figure 49 is one in which several sequences of SD PDUs are lost. The only thing, worth mentioning are the parameters of the STAT message. It contains N(R) =2, since this is still the next SD to be received. N(MR) equals 8, since the receiver buffers already 4 PDUs. Thus, only 1 more new SD may be sent. The List Elements are {2,4,5,7} Their meaning is "retransmit from SD(2) to SD(4) (exclusive) and from SD(5) to SD(7) (exclusive)". 82 / 297 770 00905 0120 VHBE Ed. 02 5 SSCOP SSCOP B (receiver) SSCOP A (sender) AA-DATA request (1) SD (N(S) = 1) AA-DATA request (2) AA-DATA request (3) AA-DATA request (4) AA-DATA indication (1) SD (N(S) = 2) X SD (N(S) = 3) X lost frames SD (N(S) = 4) This PDU is received out of sequence. Therefore, no AA-DATA indication is generated, but the PDU is stored in the receiver buffer. AA-DATA request (5) SD (N(S) =5) AA-DATA request (6) X SD (N(S) =6) X Timer_POLL expiry lost frames POLL (N(PS)= 13, N(S) =7) STAT(N(PS) = 13, N(MR)=8, N(R) = 2, These PDUs are retrieved from the transmitted buffer, copied in the retransmission queue and finally retransmitted. LE = {2,4,5,7}) SD (N(S) = 2) SD (N(S) = 3) AA-DATA indication (2) AA-DATA indication (3) AA-DATA indication (4) SD (N(S) = 5) SD (N(S) = 6) The PDU was retrieved out of the receiver buffer. AA-DATA indication (5) AA-DATA indication (6) Figure 49 Errored Data Transfer, Several Sequences of SDs are Lost Unsollicited Status Reporting The last example, shown in figure 50, shows the use of the USTAT message. 770 00905 0120 VHBE Ed. 02 83 / 297 5 SSCOP Just as in the example of figure 49, the receiver knows that some SD PDUs have been lost. Instead of waiting for a POLL message and responding to it with a STAT message, it can also decide to sent an unsollicited status response. In fact, it is even recommended that it does. (Thus, previous examples may have been somewhat incorrect, but they were merely intended for explanatory purposes.) The USTAT message contains almost the same parameters as the STAT, with the exception of two differences. " " 84 / 297 First, it contains no N(PS), since there is no corresponding STAT to which it is a reply. Secondly, it always contains exactly 2 List Elements. This is sufficient, since the only case in which a USTAT message will be sent, is when exactly one missing sequence is detected. As such, only the last missing sequence will be reported by a USTAT. 770 00905 0120 VHBE Ed. 02 5 SSCOP SSCOP A (sender) SSCOP B (receiver) AA-DATA request (1) SD (N(S) = 1) AA-DATA request (2) AA-DATA request (3) AA-DATA request (4) AA-DATA indication (1) SD (N(S) = 2) X SD (N(S) = 3) X lost frames SD (N(S) = 4) USTAT(N(MR)=10, This PDU is received out of sequence. Therefore, no AA-DATA indication is generated, but the PDU is stored in the receiver buffer. N(R) = 2, LE = {2,4}) SD (N(S) = 2) These PDUs are retrieved from the transmitted buffer, copied in the retransmission queue and finally retransmitted. SD (N(S) = 3) AA-DATA indication (2) AA-DATA indication (3) AA-DATA indication (4) The PDU was retrieved out of the receiver buffer. AA-DATA request (5) SD (N(S) = 5) AA-DATA request (6) SD (N(S) = 6) AA-DATA indication (5) AA-DATA indication (6) Figure 50 Errored Data Transfer with USTAT Message ATTENTION Finally, it should be mentioned that the processing of a STAT or a USTAT PDU may not rely on information in other STAT or USTATs. Thus, it should pose no problem to use several STAT PDUs, perhaps reporting the same lost frames, or to use both a STAT and a USTAT reporting the same gap. It is the responsibility of the transmitter to avoid unnecessary retransmissions. 770 00905 0120 VHBE Ed. 02 85 / 297 5 SSCOP State variables In order for the transmitter and the receiver to perform the above protocols, a number of "state variables" have been defined. Most of them have already been mentioned : " at the transmitter side D D VT(A) : Acknowledge state variable. Sequence number of the next in-sequence SD PDU to be acknowledged. Thus, it forms the lower edge of the window of acceptable acknowledgements. It is updated by information from the receiver side, i.e. a STAT or a USTAT PDU. D VT(PA) : Poll Acknowledge state variable. It is the sequence number of the next expected STAT PDU. D VT(MS) : The Maximum Send sequence number is the first sequence number not allowed by the receiver, e.g. because the receiver buffer is full. The transmitter shall not send a new SD if VT(S) w VT(MS). D VT(PD) : The Poll Data state variable. When acknowledgements are outstanding, this state variable represents the number of SD PDUs transmitted after a POLL PDU. It is incremented upon transmission of a SD PDU and reset upon transmission of a new POLL PDU. Its value should never exceed MaxPD, or a POLL must first be sent D VT(CC) : Connection Control state variable. The number of unacknowledged BGN, END, ER or RS PDUs. Its value should never exceed MaxCC, or the SSCOP connection will be released. D 86 / 297 VT(PS) : POLL sequence number. It is the current value of the sequence number of the POLL PDU to be sent. This counter is incremented before transmission of the next POLL PDU. D " VT(S) : Send sequence number. It is the sequence number of the next SD PDU to be sent for the first time (i.e. excluding retransmissions). This counter is incremented after a transmission of a SD PDU for the first time. VT(SQ) : The Transmitter Connection Sequence variable. This state variable is used to allow the receiver to identify retransmitted BG, ER and RS PDUs. at the receiver side 770 00905 0120 VHBE Ed. 02 5 SSCOP D VR(R) : Receive sequence number. It is the sequence number of the next expected in sequence SD PDU. This counter is incremented after receipt of the next in-sequence SD PDU. D VR(H) : Highest Expected state variable. It is the sequence number of the highest expected SD PDU. In "pull back" mechanisms, only in sequence data PDUs are allowed and in that case, only one variable VR(R) is sufficient to keep the necessary knowledge for retransmissions. Selective retransmission is more complex. Another state variable is needed because a range of different SD PDUs will be valid for receipt. VR(H) is updated after receipt of either a new SD or a new POLL PDU . VR(H) becomes N(S) +1 . D VR(MR) : Maximum Acceptable Receive state variable. It is the sequence number of the first SD not allowed by the receiver, e.g. because the receiver buffer is full. The receiver shall discard SDs with N(S) w VR(MR) D VR(SQ) : The Receiver Connection Sequence variable. This state variable is used to identify retransmitted BG, ER and RS PDUs. Timers To ensure an uninterrupted flow of information, a number of timers exist at the transmitter side. With these timers, a SSCOP connection is partitioned into 3 phases : " The Active Phase The active phase" is the phase in which both SD PDUs, as well as POLL PDUs, are transmitted. Two timers operate during the active phase of the connection. D D 770 00905 0120 VHBE Ed. 02 Timer_POLL ensures that the receiver is polled often enough, i.e., each time the timer expires, a POLL PDU will be transmitted. The receiver then returns his status information. Polling is also necessary for advancing the credit window. In addition, to be able to detect a broken connection, another timer, Timer_NO_RESPONSE runs in parallel. This timer indicates the maximum time interval during which at least one STAT PDU has to be received. If this is not the case, the SSCOP connection is aborted. 87 / 297 5 SSCOP " The transient phase In the "transient phase" of the connection, only POLL PDUs are transmitted, but no SD PDUs. The transient phase reverts back to the active phase whenever a new SD is transmitted D " When Timer_POLL expires and there are no outstanding acknowledgements and there are no data, waiting in the transmission buffer, the Timer_POLL is replaced by the timer Timer_KEEP_ALIVE , which is longer. Thus, POLL PDUs are transmitted less often. The idle phase In the "idle phase" of the connection, neither POLL nor SD PDUs are transmitted. Whenever a new SD is transmitted, the active phase is entered again. D When upon receipt of a STAT PDU, the timer Timer_KEEP_ALIVE is still running, both Timer_KEEP_ALIVE and Timer_NO_RESPONSE are stopped and a new Timer _IDLE is started. Timer_IDLE may be considerably greater than Timer_KEEP_ALIVE. At the expiry of Timer_IDLE the transient phase is entered again. The use of these four timers, during assured data transfer is depicted in figure .51. ACTIVE PHASE Timer_POLL Timer_NO_RESPONSE send POLL no SD abort new SD TRANSIENT PHASE Timer_KEEP_ALIVE IDLE PHASE Timer_NO_RESPONSE send POLL STAT received while Timer_KEEP_ALIVE still running abort Timer_IDLE expiry Timer_IDLE Figure 51 88 / 297 SSCOP Protocol Timers for Assured Data Transfer 770 00905 0120 VHBE Ed. 02 5 SSCOP The values of the SSCOP protocol timers are application specific and may be defined in the appropriate recommendation, describing the SSCF on top of it. Thus, the timers are configurable for different operational environments (e.g. signalling versus data transfer environments, or environments including satellite links). NOTICE In MTP-2, two separate types of error correction mechanism are defined, i.e., the Basic Error Correction method, and the Preventive Cyclic Retransmission method. Both are to be used under well defined circumstances. On the other hand, in SSCOP only one method exists, which is , configurable, by adjusting only the defined protocol timers. 5.3.4 Flow Control Credit is granted by the SSCOP receiver to allow the peer SSCOP transmitter to transmit new SDs. The process by which the receiver determines this credit is not subject to standardization, but is related to the buffer availability and the bandwidth of the connection. As previously mentioned, the credit value is conveyed to the transmitter in the N(MR) field of each BGN, BGAK, RS, RSAK, ER, ERAK, STAT and USTAT PDU. This credit value sent is the sequence number of the first SD that the receiver will not accept. Thus, the transmitter should not transmit any SDs, exceeding this credit value, while the receiver discards any SD that exceeds it anyway. Previously granted credit can be reduced in order for the receiver to perform flow control. However, the credit value N(MR) may never be below the value VR(H), which is the highest expected sequence number. In other words, if a receiver has accepted and acknowledged SD with sequence number n, n + 1 must be situated within the credit window. The SSCOP receiver allocates a buffer to support each connection. In principle, the receiver buffer available should match or exceed the credit granted to the transmitter, to avoid the discard of successfully transmitted data. However, if limited buffers are available for a connection, it is possible to grant credit in excess of the available buffer capacity. This method may obtain a higher throughput than can be achieved by limiting the credit. Of course, the receiver 770 00905 0120 VHBE Ed. 02 89 / 297 5 SSCOP " may not discard previously received and acknowledged SDs. " must allocate sufficient buffer capacity to receive and deliver the next in-sequence SD, at all times. Up to the SSCOP layer, we have obtained a powerful message transfer layer, offering : G assured, in-sequence data transfer G flow control G connection control capabilities The capabilities of the described protocol stack is comparable to the capacities of MTP-2, but it uses the more efficient selective retransmission algorithm. 90 / 297 770 00905 0120 VHBE Ed. 02 6 SSCF 6 SSCF SSCF is the highest layer of the SAAL. It maps the services of the SSCOP to the needs of the signalling layer 3 protocols. Therefore, it is also called a coordination function", or mapping function". Different SSCFs exist : G SSCF for the UNI The services and primitives of this function are described first. More particularly, this function will influence the application of the lower layer, the SSCOP Thus, it shall prescribe the values . for SSCOPs configurable parameters. SSCF for the UNI is described completely in Ref. [21.]. G SSCF for the NNI The services and primitives of this function are described af terwards.. Also this SSCF prescribes some values for SSCOPs configurable parameters. SSCF for the NNI is described completely in Ref. [22.]. 770 00905 0120 VHBE Ed. 02 91 / 297 6 SSCF 6.1 SSCF at the UNI 6.1.1 Services provided by the SSCF. SSCF Filtering Function The purpose of SSCF at the UNI is to map the UNI layer 3 protocol (Q.2931) to the service of the next lower layer, which is the SSCOP As such, SSCF merely performs a coordination . function between the services required by the signalling layer 3 and the services provided by SSCOP . In other words, SSCF serves as a filter between the layer 3 protocol and SSCOP i.e., not all services offered by SSCOP will be , offered to the layer 3. To be concrete, in the case of DSS2, neither the functionality of non-assured data transfer, nor the retrieval functionality will be delivered to the Q.2931 layer. Finally, SSCF fixes the configurable parameters of SSCOP which , depend upon the use, condition, link rate, round-trip delay, and receiver resequencing buffer. UNI SAAL Services This leads to the following provision of services of the complete SAAL at the UNI : " Assured Transfer of Data The SAAL service provides for the assured transfer of SAAL service data units on point-to-point ATM connections. The SAAL supports the transfer of octet aligned SDUs up to a maximum of 4096 octets (i.e. maximum information size k in SD PDU). The SAAL service relieves the user from loss, insertion, corruption, and misordering of data which may occur. In some cases due to unrecoverable errors in the ATM adaptation layer, duplication or loss of SDUs may occur. " Transparency of Transferred Information The SAAL service provides for the transparent transfer of SAAL service data units. It does not restrict the content, format or coding of information, nor does it ever need to interpret its structure or meaning. 92 / 297 770 00905 0120 VHBE Ed. 02 6 SSCF " Establishment and Release of SAAL Connections The SAAL service provides a means to establish and release SAAL connections which operate in the assured mode. In some cases, the SAAL service provider may release the SAAL connection. Depending on the conditions, release of an SAAL connection may result in loss of SAAL user-data. 6.1.2 Primitives exchanged between SSCF and layer 3. Primitives The following primitives are offered by SSCF. " AAL-ESTABLISH request / indication / confirm ( ) These primitives are used for establishing assured information transfer between AAL entities at the UNI. " AAL-RELEASE request / indication / confirm ( ) These primitives are used to terminate assured information transfer between AAL entities at the UNI " AAL-DATA request / indication (Parameter Data) These primitives are used for assured information transfer. It is assumed that assured information transfer was initiated with the AAL-ESTABLISH primitive. Parameters The parameter has the following meaning : " 6.1.3 Parameter Data : L3 peer-to-peer message. Restrictions to SSCOP Restrictions on Services The following services of SSCOP are not used by SSCF at the UNI. " " Restrictions on Parameters unassured data transfer local data retrieval The following parameters of SSCOP primitives are defined by SSCF at the UNI. " SSCOP-UU in the primitives for connection establishment and release This parameter is not used. " Source in the AA-RELEASE indication This parameter is not used. 770 00905 0120 VHBE Ed. 02 93 / 297 6 SSCF " SN in the AA-DATA indication. This parameter is not used, since local data retrieval is not supported. " BR in the AA-ESTABLISH request and response This parameter is always set to yes", since local data retrieval is not supported. " MU in the AA-DATA request and indication The length of this parameter is limited to 4096 octets Usage of Configurable Variables The following values are attached to SSCOPs configurable variables by SSCF at the UNI. " MaxPD The maximum number of allowed SDs to be sent, between 2 POLLs. Its value is defined by SSCF to be 25. Usage of Timers The following values are attached to SSCOPs timers by SSCF at the UNI. " TIMER_POLL Its value is set to 750 msec. " TIMER_NO-RESPONSE Its value is set to 7 sec. " Timer_KEEP_ALIVE Its value is set to 2 sec. " TIMER_IDLE Its value is set to 15 sec. 94 / 297 770 00905 0120 VHBE Ed. 02 6 SSCF 6.2 SSCF at the NNI 6.2.1 Services provided by the SSCF. SSCF Filtering Function The purpose of SSCF at the NNI is to map the NNI layer 3 protocol (MTP-3) to the service of the next lower layer, which is the SSCOP As such, SSCF merely performs a coordination . function between the services required by MTP-3 and the services provided by SSCOP . In contrast to the UNI, more services offered by SSCOP will be used. These include the retrieval function. Finally, SSCF fixes the configurable parameters of SSCOP which , depend upon the use, condition, link rate, round-trip delay, and receiver resequencing buffer. UNI SAAL Services This leads to the following provision of services of the complete SAAL at the NNI : " Assured Transfer of Data The SAAL service provides for the assured transfer of SAAL service data units on point-to-point ATM connections. The SAAL supports the transfer of octet aligned SDUs up to a maximum of 4096 octets (i.e. maximum information size k in SD PDU). The SAAL service relieves the user from loss, insertion, corruption, and misordering of data which may occur. In some cases due to unrecoverable errors in the ATM adaptation layer, duplication or loss of SDUs may occur. " Transparency of Transferred Information The SAAL service provides for the transparent transfer of SAAL service data units. It does not restrict the content, format or coding of information, nor does it ever need to interpret its structure or meaning. " Establishment and Release of SAAL Connections The SAAL service provides a means to establish and release SAAL connections which operate in the assured mode. A initial alignment procedure may be applied during connection establishment to verify the signalling connection. Depending on the conditions, release of an SAAL connection may result in loss of SAAL user-data. 770 00905 0120 VHBE Ed. 02 95 / 297 6 SSCF " SDU Retrieval The SAAL user may retrieve SDUs already delivered to the SAAL, but not yet transported by the SSCOP . " Signalling Link Error Monitoring Two signalling link error monitoring functions are provided : D D " one that is employed while a signalling link is in service and which provides one of the criteria for taking the link out of service one that is employed when a link is in the proving state of the initial alignment procedure Flow Control The SAAL service provides, on an implementation dependent basis, indication of local congestion of the signalling link. " Notification of Status SSCF informs the SAAL user of the status of the SAAL connection. 6.2.2 Primitives exchanged between SSCF and layer 3. Primitives The following primitives are offered by SSCF. " AAL-START request ( ) and AAL-STOP request ( ) These primitives are used to establish or inhibit peer-to-peer communications. " AAL-MESSAGE_FOR_TRANSMISSION request( MU ) and AAL-RECEIVED_MESSAGE indication ( MU ) These primitives are used by the AAL user to send data or by the AAL to deliver data to its user. " AAL-RETRIEVE_BSNT request ( ) and AAL-BSNT confirm ( BSNT ) and AAL-BSNT_NOT_RETRIEVABLE confirm ( ) These primitives are used to request the BSNT to be retrieved, to deliver this value, or to indicate that the value can not be retrieved. 96 / 297 770 00905 0120 VHBE Ed. 02 6 SSCF " AAL-RETRIEVE_REQUEST_AND_FSNC request ( FSNC ) and AAL-RETRIEVED-MESSAGES indication ( MU ) and AAL-RETRIEVAL_COMPLETE indication ( ) These primitives are used to retrieve messages, which were already delivered to the SAAL. Each such message is returned into one AAL-RETRIEVED_MESSAGES indication, while an AAL-RETRIEVAL_COMPLETE indication indicates the end of retrieval, i.e., all messages have been returned. When MTP-3 issues an AAL-RETRIEVE_REQUEST_AND_FSNC request to SSCF, SSCF issues an AA-RETRIEVE request to SSCOP The RN parameter . in this request is set to the FSNC value received from MTP-3. The SSCOP returns, in order, message units it has received from SSCF in AA-DATA requests, beginning with the message unit following the one sent in the SD PDU with sequence number RN. This procedure is illustrated in figure 52. MTP-3 SSCOP SSCF-NNI AAL-RETRIEVAL_REQUEST AND_FSNC.req ( X ) AA-RETRIEVE.req (.X ) AA-RETRIEVE ind ( MU X+1 ) AA-RETRIEVE ind ( MU X+2 ) . . . AA-RETRIEVE COMPLETE ind ( ) AAL-RETRIEVED_MESSAGE ind ( MU X+1 ) AAL-RETRIEVED_MESSAGE ind ( X+2) . . . AAL-RETRIEVAl COMPLETE ind() Figure 52 770 00905 0120 VHBE Ed. 02 Local Retrieval of Information 97 / 297 6 SSCF " AAL-LINK_CONGESTION indication ( ) and AAL-LINK_CONGESTION_CEASED indication ( ) These primitives are used to support the flow control functionality. The actual method for this is implementation dependent. " AAL-IN_SERVICE indication ( ) and AAL-OUT_OF_SERVICE indication ( ) These primitives indicate availability or unavailability of the signalling link. " AAL-EMERGENCY request ( ) and AAL-EMERGENCY_CEASES request ( ) These primitives are used to request reduction of the alignment proving period, or to return to normal link proving time. Parameters The parameters have the following meaning : " MU : Message Unit, L3 peer-to-peer message. " FSNC : Forward Sequence Number It is the value of the N(S) parameter of the last in-sequence SD PDU, accepted and acknowledged by the peer side. " BSNT : the Backward Sequence Number to be Transmitted BSNT is the value of the SN parameter of the last received AA-DATA indication received from SSCOP which is equal to , the N(S) parameter of the last received SD PDU. MTP-3 will need this information, e.g., in the case of a changeover, which is explained in the following chapter. When MTP-3 issues an AAL-RETRIEVE_BSNT request, SSCF ensures that it has processed all AA-DATA indications from the SSCOP which is in the idle state or in the process or , releasing the connection. 6.2.3 Restrictions to SSCOP Restrictions on Services The following services of SSCOP are not used by SSCF at the UNI. " Restrictions on Parameters 98 / 297 unassured data transfer The following parameters of SSCOP primitives are defined by SSCF at the UNI. 770 00905 0120 VHBE Ed. 02 6 SSCF " SSCOP-UU in the primitives for connection establishment and release This parameter can be used to transmit an SSCF PDU. " Source in the AA-RELEASE indication This parameter can be set to SSCOP " or User ". " SN in the AA-DATA indication. The Sequence Number indicates the value of the N(S) parameter in an associated received SD PDU which is delivered to SSCF, and is used to support the data retrieval operation. " BR in the AA-ESTABLISH request and response This parameter is always set to No", since the data retrieval service can be utilized at the NNI.. " MU in the AA-DATA request and indication The length of this parameter is limited to 4096 octets Usage of Configurable Variables The following values are attached to SSCOPs configurable variables by SSCF at the UNI. " MaxPD The maximum number of allowed SDs to be sent, between 2 POLLs. Its value is defined by SSCF to be 500. Usage of Timers The following values are attached to SSCOPs timers by SSCF at the UNI. " TIMER_POLL Its value is set to 100 msec. " TIMER_NO-RESPONSE Its value is set to 1,5 sec. " Timer_KEEP_ALIVE Its value is set to 100 msec. " TIMER_IDLE Its value is set to 100 msec. 770 00905 0120 VHBE Ed. 02 99 / 297 6 SSCF 6.2.4 SSCF Peer to Peer Communication PDU Coding Only 1 SSCF PDU type can be sent between peer NNI SSCFs. It has one information field used to indicate the current status of the sending peer. The format of the SSCF PDU is shown in figure 53. 1 2 3 Status Reserved Figure 53 4 Format of NNI SSCF PDU This SSCF PDU can either be sent as the MU of an AA-DATA request, or as the SSCOP-UU of an AA-ESTABLISH or AA_RELEASE request. Since the length of all valid MTP-3 PDUs exceeds 4 octets, a simple discrimination based on message length can prevent SSCF PDUs from being delivered inadvertently to MTP-3. Thus, the following applies : " All received MUs in an AA-DATA indication for which the length = 4 octets are treated as SSCF PDUs. " All received MUs in an AA-DATA indication for which the length > 4 octets are treated as user messages. The status field is coded as follows : Table 3 Status field encoding Code 0000 0001 Out of Service 0000 0010 Processor Outage 0000 0011 In Service 0000 0100 Normal 0000 0101 Emergency 0000 0111 Alignment not Successful 0000 1000 Management Initiated 0000 1001 Protocol Error 0000 1010 100 / 297 Meaning Proving not Successful 770 00905 0120 VHBE Ed. 02 6 SSCF Applications SSCF peer to peer communication can be used for the following reasons. Processor Outage While still being in service, SSCF can be notified of a local processor outage by the management layer. SSCF maintains an internal flag (LPO), corresponding to the status of the local processor, which can take 2 values : " LPO = 0 : indicating no local processor outage " LPO = 1 : indicating local processor outage When a local processor outage occurs, SSCF issues an AA-RELEASE request to SSCOP and an AAL-OUT_OF_SERVICE indication to MTP-3. The SSCOP-UU parameter of the AAL-RELEASE request is used to indicate the processor outage to the peer SSCF. Upon receipt of a status of processor outage in the SSCOP-UU parameter of an AA-RELEASE indication, SSCF issues an AAL-OUT_OF_SERVICE indication to MTP-3. This procedure is shown in figure SSCF UNI AAL-OUT-OFSERVICE indication SSCOP B SSCOP A AA-RELEASE request carrying Processor Outage" in the SSCOP-UU parameter END ENDAK AA-ESTABLISH confirm Figure 54 SSCF UNI AA-RELEASE indication AAL-OUT-OFSERVICE indication carrying Processor Outage" in the SSCOP-UU parameter Processor Outage Alignment and Proving During the alignment procedure, the SSCF passes through several stages, which are : " 770 00905 0120 VHBE Ed. 02 Out of Service 101 / 297 6 SSCF " Alignment " Proving " Aligned Ready " In service During the complete procedure of bringing a link into service, SSCF will transmit several SSCF PDUs. For instance : " " A number of proving PDUs will be sent. Proving PDUs are sent as AA-DATA requests, with the MU indicating the proving period, i.e. Normal or Emergency". " 102 / 297 In the alignment stage, SSCF conveys the proving period Normal" or Emergency" to its peer. SSCF determines this proving period, either by examining local state variables (=user proving state) or it is prescribed by the management layer (= management proving state). SSCF communicates the period to its peer by placing it in the SSCOP-UU parameter of its request to establish the link. When proving has completed SSCF will sent a PDU with an In Service" code, to its peer. 770 00905 0120 VHBE Ed. 02 7 MTP-3 7 MTP-3 While the BB-UNI signalling does not have a networking layer, NNI signalling needs to be more robust, including having the ability to reroute around failed nodes or links. This layer, reused from the NB CCS #7 protocol stack, is MTP-3. In NB networks MTP-1, MTP-2 and MTP-3, together, provide G error-free transportation of signalling information G an extremely reliable transport system, able to react to system and network failures. The first service is already provided, by the protocol stack, we have described previously, more particularly by SSCOP . The second service is added by MTP-3. MTP-3 is described completely in Ref.[12.]. The extensions to MTP-3, suitable for the control of signalling links that provide the services of Q.2140, are described in Ref.[23.]. They are also referred to as MTP-3b. 770 00905 0120 VHBE Ed. 02 103 / 297 7 MTP-3 7.1 From Narrowband to Broadband 7.1.1 The Narrowband Situation CCS #7 In the Narrowband world, Common Channel Signalling System #7 (CCS #7) is far out the most important NNI signalling system. Any CCS #7 network consists out of several network components, which shall be discussed first. Signalling Network Components Signalling Points The CCS #7 network is logically separated from any other network and is used solely for the switching of data messages, pertaining to e.g. call handling for the telephone network. All nodes in the CCS #7 network are called "Signalling Points (SP)". Many kinds of Signalling Points may exist. " Exchanges " Service Control Points (SCP) for the Intelligent Network (IN) " Operation, Administration & Maintenance (OAM) Centers In the scope of this document, two specific kinds of Signalling Points are of interest. " Signalling End Point (SEP) In the scope of CCS #7, this is a local node in a telecommunications network, to which subscriber lines are attached, and which is served by CCS #7. It is a source or a sink of signalling traffic. " Signalling Transfer Point (STP) All CCS #7 messages travel from one SEP to another through the services of a STP The STP switches the messages as . received from the various SEPs through the network to their appropriate destinations, i.e. to the destination SEP or , perhaps first to another STP . In an STP there is no switching-oriented processing of the , signalling message, i.e. the contents of the signalling message is not examined. Three levels of STPs exist : National, International and Gateway. 104 / 297 770 00905 0120 VHBE Ed. 02 7 MTP-3 A typical CCS #7 Network structure is shown in figure 55. Signalling Points are deployed in pairs for redundancy and diversity. To make sure the CCS #7 network is always operational, alternate and multiple paths are provided. Thus, SEPs are connected to at least 2 STPs. Further, multiple paths exist between different STPs. STP STP SEP SEP SEP STP STP SEP Ç Ç Ç Ç Figure 55 SEP SEP SEP CCS #7 Network Structure Ç Ç Ç Ç Ç SEP Note that a Signalling Point can act as an STP for one signalling message, while it can be an SEP for another message. Thus, this classification is on the level of the individual messages. At first, being an SEP or an STP is no property of an exchange, but how an exchange behaves for a particular signalling message. However, if it is certain that a Signalling Point will always act as an STP the classification can be shifted to the node level. Therefore, , Signalling Points can act in the following ways. " " STP " Note SEP Mixed Functionality SEP / STP An STP will rarely be a stand-alone system built for the sole purpose of STP functionality. More typically, it will be integrated in an exchange. Obviously, a message will always be transmitted from one Signalling Point to another. This gives rise to the following terminology : " 770 00905 0120 VHBE Ed. 02 Originating Signalling Point : a Signalling Point at which a message is generated. 105 / 297 7 MTP-3 " Destination Signalling Point : a Signalling Point to which a message is destined. Each Signalling Point is identified with a "point code". This point code identifies the Signalling Point in a unique way inside the (national or international) CCS #7 network. In a similar way, we will use the terms "originating point code" and "destination point code" in order to identify the source and destination of a CCS #7 message. Signalling Relations Any 2 Signalling Points, for which the possibility of compatible communication exists are said to have a "Signalling Relation". This is shown in figure 56. Although SP1 and SP 4 do not have any direct physical line, able to carry signalling information, they do have a Signalling Relation with each other, since they can communicate via SP2 or via SP3, which will act as STPs in that case. Point Code 3 Point Code 2 Point Code 4 Point Code 1 line carrying user information line carrying signalling information signalling relation Figure 56 Signalling Links Signalling Relations CCS #7 uses "Signalling Links" to convey the signalling messages between two Signalling Points. A number of Signalling Links that directly interconnect two Signalling Points constitute a "Signalling Link Set". Typically, though not necessarily, a Signalling Link Set comprises all Signalling Links between 2 Signalling Points. A possible 106 / 297 770 00905 0120 VHBE Ed. 02 7 MTP-3 application of a Signalling Link Set is, for example, that switching equipment will alternate transmission across all the links in a linkset to ensure equal usage of all links. A group of links within a link set that have identical characteristics (e.g. the same bit rate) are called a "Signalling Link Group". All of this is represented in figure 57. SL Point Code A SG1 SL SL SG2 SG1 SG3 Point Code B Signalling Link Set SL = Signalling Link SG = Signalling Link Group Figure 57 Hierarchy of a Signalling Link Set Signalling Routes The pre-determined path, consisting of a succession of STPs and the interconnecting Signalling Links, that a message takes through the CCS #7 network between the originating and the destination point is called the "Signalling Route" for that Signalling Relation. All the Signalling Routes that may be used between an originating and a destination point by a message traversing the CCS #7 network is called the "Signalling Route Set" for that Signalling Relation. The complete terminology of Signalling Links, Signalling Link Sets, Signalling Routes and Signalling Route Sets is shown in figure 58. 770 00905 0120 VHBE Ed. 02 107 / 297 7 MTP-3 SL Point Code B SL Set SR Point Code A Point Code D SR Set SR Point Code C SL = Signalling Link SL Set =Signalling Link Set SR = Signalling Route SR Set= Signalling Route Set Figure 58 Signalling Links, Linksets, Routes and Route Sets. Narrowband MTP MTP In a narrowband CCS #7 network, MTP consisting of MTP-1, , MTP-2 and MTP-3, constitute a error-free transfer system (MTP-2) capable of reacting to and solving failures in the network. The complete Narrowband MTP is illustrated in figure 59. 108 / 297 770 00905 0120 VHBE Ed. 02 7 MTP-3 Layers 3-7 Layer 3 MTP-3 Layer 2 Layer 1 MTP-2 MTP-1 Signalling Link Functions Signalling Data Link Signalling Network Functions Signalling Message Handling TUP Signalling Network Management ISUP MTP B-ISUP Figure 59 MTP Structure Note 7.1.2 Higher layers, i.e., layers above MTP-3 are called the User Parts". The Broadband Situation BB Situation 770 00905 0120 VHBE Ed. 02 In the BB situation, MTP-1 and MTP-2 are replaced by the protocol stack described thus far. This stack replacement is depicted in figure 60. 109 / 297 7 MTP-3 Q.2761-Q.2764 Q.704. B-ISUP MTP-3 Q.2761-Q.2764 Q.704. B-ISUP MTP-3 Q.2140 Q.2110 Q.703 SSCF SSCOP MTP-2 I.363.5 I.361 Q.702 Figure 60 B-ISUP 7.2 MTP-1 CP ATM Layer I.432 Physical Layer From NB to BB Finally, the User Part, above MTP-3 is called B-ISUP It is just . another User Part, just as any other CCS #7 User Part. Services of MTP-3 MTP-3 is described completely in Ref.[12.]. As can be seen in figure 59, it consists of 2 parts : " Signalling Message Handling Functions : The purpose of these functions is to ensure that the signalling messages originated by a particular User Part at an originating Signalling Point are delivered to the same User Part at the destination Signalling Point. This delivery may be made directly (through one signalling link) or indirectly, via one or more intermediate STPs. 110 / 297 770 00905 0120 VHBE Ed. 02 7 MTP-3 " Signalling Network Management Functions : The purpose of these functions is to provide reconfiguration of the signalling network in the case of failures and to control traffic in case of congestion. In order to do this, these functions provide the capability to bypass the faulty links or Signalling Points. Further, they can also activate or align new signalling links. Of course, when the failures are restored, the opposite actions and procedures take place, in order to reestablish the normal configuration of the signalling network. The Signalling Message Handling Functions will be discussed in paragraph 7.3, while the Signalling Network Management Functions are discussed in paragraph 7.6. 7.3 Signalling Message Handling functions Subfunctions Message Handling includes 3 different sub-functions, which are to be performed at each Signalling Point in the CCS #7 network. " Message Discrimination : This function provides an interface to layer 2, concerning received messages. It determines whether the message is destined for another Signalling Point or not. D D " if the destination point is the Signalling Point in question, it will pass the message to Message Distribution. If not, it will pass the message to Message Routing. Message Distribution : This is the mechanism used to deliver a message to its appropriate User Part, in the same Signalling Point, i.e. when the message has already reached its destination Signalling Point. " Message Routing : Message Routing also provides an interface to the lower layer, but this time concerning messages to be sent. Its function is to determine the appropriate outgoing signalling link on which a message has to be transmitted. Possibly, when 2 or more links are used at the same time to carry traffic to the same destination, a "loadsharing" function will also be part of the Message Routing functionality. 770 00905 0120 VHBE Ed. 02 111 / 297 7 MTP-3 Figure 61 shows all these Message Handling Functions and the Signalling Message flow. Message Distribution Message Discrimination Message Routing towards/from User Parts Figure 61 Parameters towards/from MTP-2 Message Discrimination, Message Distribution, Message Routing and the Signalling Message flow The Message Handling functions will be based upon : " The SIO, which is a part of the MTP-3 header. The outlook of this SIO is shown in figure 62. It contains 2 sub-fields : D Network Indicator (NI) : The NI is used to identify an individual CCS #7 network being addressed. D Service Indicator (SI) : The SI is used to identify the User Part to which the message must be delivered. 8 7 ÇÇÇÇÇÇÇ ÇÇÇÇÇÇÇ ÇÇÇÇÇÇÇ NI 6 5 SI 4 3 2 1 First bit transmitted NI Network Indicator SI Service Indicator Figure 62 Outlook of the Service Information Octet (SIO) " The Routing Label, which are the last 4 octets of the MTP-3 header. The outlook of a Routing Label is shown in figure 63. It contains 3 sub-fields : 112 / 297 770 00905 0120 VHBE Ed. 02 7 MTP-3 D Destination Point Code (DPC) : This DPC is a unique identification of the destination exchange in the signalling network. D Originating Point Code (OPC) : The OPC is a unique identification of the originating exchange in the signalling network. D Signalling Link Selection (SLS) : The SLS can be used for loadsharing of the information between a number of signalling links. SLS 4 bits OPC 14 bits DP C 14 bits First bit transmitted DPC Destination Point Code OPC Originating Point Code Signalling Link Selection SLS Figure 63 Outlook of the Routing Label All of these fields will now be discussed in more detail. 7.3.1 DPC This 14 bit code is a unique identification of the destination (exchange) in a CCS #7 network. Routing It will be used by message discrimination to decide whether the current exchange is the destination or not. Further, it will also be used by message routing to route the call to the correct outlet of the exchange. It is noted that the point code is intended to be processed within MTP-3 of each Signalling Point, so there is no direct relationship to telephone, data or ISDN numbering. Each Signalling Point will have a "Routing Table", consisting of assignments between the DPCs and the outgoing Signalling Link Sets for the preferred routes and the spare routes. This is shown in figure 64. 770 00905 0120 VHBE Ed. 02 113 / 297 7 MTP-3 Linkset A Point Code A Point Code 3 Linkset B Point Code 7 MTP Routing Table for A ... DPC 3 ... DPC 7 ... Figure 64 Range Structure of an International Point Code First Route Spare Route ... ... Linkset A Linkset B ... ... Linkset B Linkset A ... ... MTP Routing Table However, the range of this DPC is only 214 = 16 384. Obviously, this is not enough to provide a unique worldwide identification of all exchanges using CCS #7. This problem will be solved by the use of the NI, which is explained further. For the moment, it suffices to say that a point code identifies unambiguously a Signalling Point in a certain CCS #7 network. In each CCS #7 network, DPCs are assigned locally. ITU-T has provided a unique numbering scheme for the coding of the point codes, used in the international network. It is described in Ref. [13.]. Such an International Signalling Point Code (ISPC) consists of three parts: " A 3 bit zone identification, indicating a general, geographical world zone. " A 8 bit area identification, indicating a country or a region, inside a zone. " A 3 bit Signalling Point identification indicating a specific Signalling Point in the related area. This ISPC is shown in figure 65. Zone 3 bits Figure 65 114 / 297 Area SP 8 bits 3 bits Structure of an international Point Code 770 00905 0120 VHBE Ed. 02 7 MTP-3 Clearly, this coding gives rise to 8 world zones, 256 possible areas within each zone, and 8 Signalling Points within 1 area. Note For the moment only 6 world zones are in use. The 000 and 001 codes are reserved for future allocations. ITU-T assigns the zone and area codes, while the assignment of the Signalling Point identifications, will be made by the geographical area itself. As an illustration, the coding of the 6 current world zones is given in table 4. Table 4 Zone encoding for the international Point Codes. 010 Europe 011 North- & Middle America 100 Middle East & Asia 101 Australia 110 Africa 111 South-America As an example, Belgium is situated in world zone 2 and has received the area identifications of 12 and 13. 7.3.2 OPC The header of the signalling message also includes an originating point code. This is used to identify the exchange which originated the message. 7.3.3 NI As already mentioned, the range of the DPC is only 214 = 16 384, which does not suffice to provide a unique worldwide identification of all exchanges using CCS #7. This problem is solved by the use of the NI. The worldwide CCS #7 network is structured into 2 functionally independent levels, to wit, the international level and the national level. Only one CCS #7 international network exists, but there are a large number of national CCS #7 networks. This structure has some advantages : 770 00905 0120 VHBE Ed. 02 115 / 297 7 MTP-3 This 2 level structure is shown in figure 66. International Plane National Plane Country 1 Country 2 National Signalling Point International Signalling Point Figure 66 National and International CCS #7 planes A gateway exchange is an exchange providing access to the international CCS #7 network. It will have an identity in the national as well as an identity in the international CCS #7 network. As a result, this exchange will have two different DPCs, one in each CCS #7 network. The NI identifies the destination exchange as being part of the national CCS #7 network where the message was sent or as a part of the international CCS #7 network. Table 5 enlists the possible values for the NI. Clearly, this NI is only important in international gateway exchanges and will indicate whether the message should be forwarded to the international or to the national CCS #7 network. Table 5 NI Encoding 0 0 or 0 1 International network. 1 0 or 1 1 National network. Figure 67 shows an example of a message, originating in a local CCS #7 network, being passed to the international plane, and finally being delivered again to the national plane (=to another national CCS #7 network). Note that the nodes B and B' 116 / 297 770 00905 0120 VHBE Ed. 02 7 MTP-3 represent the same physical node (= the same exchange). The same goes for C and C'. B' NI = 00 C' International Plane A NI = 10 B C NI = 10 National Plane Figure 67 7.3.4 National and International CCS #7 planes SI If the DPC of the message identifies the receiving Signalling Point, the SI is examined by the Message Distribution Function and the message is delivered to the corresponding User Part. Table 6 lists the most common 4-bit codes for the international CCS #7 network. The allocation of the SI codes for national CCS #7 networks is a national matter. However, it is suggested by ITU-T to allocate the same SI codes. Table 6 Service Indicator Codes 0000 0011 SCCP 0100 TUP 0101 ISUP 0110 DUP 1001 770 00905 0120 VHBE Ed. 02 Signalling Network Management messages. B-ISUP 117 / 297 7 MTP-3 7.3.5 SLS Typically, the DPC will be associated with more than 1 signalling link that may be used to carry the message; the selection of a particular signalling link can be made by the value of the SLS field, thus effecting loadsharing (= traffic distribution) of the information between a number of signalling links. Since this field has a length of 4 bits, 16 routes can be distinguished per DPC. If loadsharing is performed by randomly sending messages on different signalling links, the CCS #7 network cannot guarantee the sequence in which the messages will arrive in the destination. This situation would be unacceptable for most applications. For example, if CCS #7 is used for the transmission of signalling messages in the telephone network, the sequence has to be guaranteed. If a message with a call setup request arrives after a message with extra digits, the call will fail. Therefore, messages belonging to the same "dialogue" must follow the same route. Still, loadsharing is possible but on a higher level, i.e. messages of the same "dialogue" must be kept together, but loadsharing is possible for the different "dialogues", even with the same destination. With the SLS field, the user can select which messages have to be forwarded on which link. An example of this is shown in figure 68. For exchange A, which is routing traffic to D, the following configuration would accomplish loadsharing. SLS = xxx1 Point Code B Point Code A Point Code D SLS = xxx0 Figure 68 Point Code C Use of SLS for loadsharing purposes. By manipulating the SLS field, the User Part can control which messages are sent over the same signalling link, but he should take into account it is used for loadsharing, therefore, the SLS values should be distributed as equally as possible. 118 / 297 770 00905 0120 VHBE Ed. 02 7 MTP-3 If there is a requirement to maintain the order of the transmission of the messages, the field must be coded with the same value for all messages belonging to the same transaction, sent in a given direction. As a result, the network guarantees a delivery of these messages in sequence. In other words, in that case, the CCS #7 network now operates in the quasi-associated mode. To summarize, we will repeat the different actions taken by the Signalling Message Handling Functions. In the originating exchange, the message is assembled and passed to Message Routing. This function will analyze the DPC, the NI and the SLS to find the appropriate signalling link on which the message will be transmitted. Layer 2 guaranties error free transmission to the next exchange. Message Discrimination will receive the message in the next exchange. The DPC and the NI will be examined. Again it can be decided that the message is outgoing. It will then be passed to Message Routing which will use the same information as before to select a signalling link and again the message will be passed to the next exchange. In the terminating exchange, the actions are different. Again Message Discrimination will analyze the DPC and the NI. But since the message has a local destination, Message Distribution will be activated and it will use the Sl to decide on the location of the user part. When the user part has been located, the message will be delivered to it. 7.4 Primitives exchanged between MTP-3 and B-ISUP . Primitives The primitives offered by MTP-3 and used by B-ISUP are the following : " Primitives for Message Transfer : D MTP-TRANSFER request / indication (OPC, DPC, SLS, SIO, User data) This primitive is used to provide the MTP message transfer status. " 770 00905 0120 VHBE Ed. 02 Primitives for Status Indications : 119 / 297 7 MTP-3 D MTP-PAUSE indication (Affected DPC) This primitive is used to indicate to the MTP-3 users the total inability of providing the MTP service to the specified destination. The user is not allowed anymore to send messages to the specified Signalling Point. If B-ISUP receives an MTP-PAUSE, it blocks the VPIs to that DPC for new calls. D MTP-RESUME indication (Affected DPC) This primitive is used to indicate to the MTP-3 users the ability of providing the MTP service to the specified destination. If B-ISUP receives an MTP-RESUME, it unblocks the VPIs to that DPC. 120 / 297 770 00905 0120 VHBE Ed. 02 7 MTP-3 D MTP-STATUS indication (Affected DPC, Cause) This primitive indicates to the users the partial inability of providing the MTP service to the specified destination. The primitive is also used to indicate that a remote corresponding user is unavailable and the cause for unavailability. For B-ISUP the procedure is as follows : after the receipt , of MTP-STATUS, B-ISUP must reduce the traffic load towards the affected DPC. This reduction of traffic is done in several steps as shown in figure . Two different timers are used for this procedure. The Short Signalling Connection Control (SCC) timer (Short SCC) and the long SCC timer (Long SCC). When the first MTP-STATUS which indicates congestion, is received, the traffic load towards the concerned DPC is reduced by 1 step. The short SCC and the long SCC timers are started. During period Short SCC" all received congestion indications for the same DPC are ignored in order not to reduce traffic too rapidly. Reception of a congestion indication after the expiry of the short SCC timer and before expiry of the long SCC timer, traffic is again reduced by 1 step and both the timers are restarted. This stepwise reduction of the B-ISUP signalling traffic is continued until maximum reduction is obtained. If timer Long SCC expires ( and no congestion indication has been received during the period) traffic is increased by 1 step and timer Long SCC is restarted unless full traffic load has been resumed. The number of steps of traffic reduction an the amount of decrease/increase at the various steps are implementation dependent. 770 00905 0120 VHBE Ed. 02 121 / 297 7 MTP-3 Initial Traffic Load towards DPC =3 6 5 4 3 2 1 MTP B-ISUP start short SCC timer MTP-STATUS (DPC=3) MTP-STATUS (DPC=3) MTP-STATUS (DPC=3) X X start long SCC timer ignored 1 ignored MTP-STATUS (DPC=3) 6 5 4 3 2 expiry short SCC timer start short SCC timer stop long SCC timer start long SCC timer 6 5 4 3 2 1 long SCC timer expired 6 5 4 3 2 1 Figure 69 Parameters Reduction of Traffic towards a Congested DPC. The parameters, mentioned in the primitives above, have the following meaning : " DPC : see section 7.3.1. " OPC : see section 7.3.2. " SIO : see sections 7.3.3 and 7.3.4. " SLS : see section 7.3.5. " User Data : The maximum amount of user data supported by MTP-3b for signalling links is 4091 octets. (4096 because of the SSCF limitation minus 5 octets, reserved for the SIO, DPC, OPC and SLS). Note that is value is much higher than the value for MTP-3 (on top of MTP-2), where the maximum amount of user data was 272 octets. 122 / 297 770 00905 0120 VHBE Ed. 02 7 MTP-3 " Cause : The Cause parameter has, at present, 4 values : D D User Part Unavailability : unknown D User Part Unavailability : unequipped remote user D 7.5 Signalling Network Congested User Part Unavailability : inaccessible remote user Outlook of an MTP-3 message As mentioned in the previous chapter, if the payload of an SSCOP SD PDU, has a length, greater than 4 octets, it will be interpreted by SSCF as an MTP-3 message. For certain, every MTP-3 message will have a length, greater than 4 bytes, since it is preceded by a header, containing " SIO " DPC " OPC " SLS which occupies already 5 bytes by themselves. This is illustrated in figure 70. 770 00905 0120 VHBE Ed. 02 123 / 297 7 MTP-3 MTP-3 message Transmission order B-ISUP MESSAGE OPC SLS 4 bits 14 bits DPC SIO 14 bits 1 byte Routing Label SSCOP-PDU (SD) SSCOP SSCOP PDU payload trailer CPCS-PDU trailer ÉÉÉÉÉÉ ÉÉÉÉÉÉ ÉÉÉÉÉÉ CPCS-PDU PAD ATM Cell ATM Cell 7.6 ATM Cell ATM header ATM header Figure 70 CPCS PDU payload ATM header .... Outlook of an MTP-3 message Signalling Network Management Functions Signalling Network Management Functions provide a number of recovery actions intended to make the network more reliable. They provide the actions and procedures required to maintain the signalling service, and to restore normal conditions in the event of disruption in the signalling network, either in signalling links, or at Signalling Points. The disruption can take several forms : " " complete loss of a Signalling Point. " 124 / 297 complete loss of a signalling link. reduced accessibility due to congestion. 770 00905 0120 VHBE Ed. 02 7 MTP-3 The occurrence of, or recovery from failures or congestion generally results in the change of the status of the affected signalling link(s), route(s) and Signalling Points. Subfunctions Whenever a change in the status of a signalling link, route or point occurs, the Signalling Network Management Functions are activated, when appropriate. There are three basic sets of functions. " Traffic Management Functions : These functions are used to divert traffic away from failed links. Traffic Management messages are originated by the Signalling Point, which detects a problem in a link and is sent over an alternate link to inform its adjacent Signalling Point not to route messages over the alternate link. Traffic Management messages are only point-to-point. They are not propagated through the CCS #7 network. The difference between Traffic Management and the use layer 2 link alignment is the fact that layer 2 link alignment can be carried over the signalling link in question. " Link Management Functions : Link Management functions consist of activation or deactivation procedures of locally connected signalling links. These functions trigger the layer 2 alignment procedures and guide them through the various states of alignment. They also supply information about the availability of the signalling links to the Traffic Management Function. " Route Management : Route Management functions are used to divert traffic from a specific Signalling Point. In contrast to Traffic Management, it does not pertain to any one specific link, but to an entire Signalling Point. The possible interactions between the different Signalling Network Management Functions are shown in figure 71. The figure also includes the possible indications between these functions. 770 00905 0120 VHBE Ed. 02 125 / 297 7 MTP-3 Traffic Management Route Management Link Management towards/from towards/from User Parts MTP-2 Figure 71 Traffic Management, Link Management and Route Management functions, and their possible interactions. As can be seen : This layered approach to network management makes CCS #7 a very robust network. Actually, very few network troubles actually cause the network to fail. 7.6.1 Traffic Management Functions Changeover A changeover action will be performed when a link goes out of service. An other link has to take over as quickly as possible, without information loss or missequencing. This new link may be a parallel link, belonging to the same linkset, or it may even be a link belonging to another linkset. As a result from the start of the changeover, all new messages must be rerouted to the new link. Of course, the new link can be carrying its own signalling traffic and this is not to be interrupted by the changeover procedure. Clearly, new messages can not be transmitted immediately over the new link, since there may still be unacknowledged messages in the retransmission buffer or new messages in the transmission buffer of the failed link. As a result, all new messages, to be sent over the new link, will have to be stored temporarily in a "changeover buffer", associated with the new link that will take over. In order to find out which outstanding messages of the failed link have to be transmitted on the new link, a special procedure is started. An Extended Changeover (XCO) message will be sent 126 / 297 770 00905 0120 VHBE Ed. 02 7 MTP-3 over the new link containing the identity of the last received message (received from the remote exchange). NOTICE This is a reason why the SSCF at the NNI, offers the primitives AAL-RETRIEVE_BSNT request ( ) and AAL-BSNT confirm (BSNT). Indeed, the BSNT identifies the last received in-sequence message. MTP-3 needs this value to put it in the XCO message. This message will be answered with an Extended Changeover Acknowledgement (XCA) message. This message will also contain the identity of the last received message of the information stream in the opposite direction. This procedure is called a "hands-shake" procedure. The message flow is shown in figure 72. Failed Signalling Link Point Code A XCO Point Code B XCA Figure 72 Handshake Procedure for Changeover When a changeover takes place, the following actions have to be performed : " Transmission and acceptance of messages on the concerned signalling link is terminated. Meanwhile, new messages to be transmitted are stored into the changeover buffer of the alternative link. " The alternative link is determined. The handshake takes place. " Buffers are updated, i.e. transmission queue and transmission buffers of the signalling link which is taken out of service are copied. The XCA contains the BSNT, which identifies the last received message. The messages from the transmission buffer, which are more "recent" than this BSNT, together with those from the transmission queue are copied to the transmission queue of the alternative link. 770 00905 0120 VHBE Ed. 02 127 / 297 7 MTP-3 NOTICE This is a reason why the SSCF at the NNI, offers the primitives AAL-RETRIEVE_REQUEST_AND_FSNC request ( FSNC ), AAL-RETRIEVED_MESSAGES indication ( MU ) and AAL-RETRIEVAL_COMPLETE indication ( ). Indeed, by this service, the messages which have to be copied to the transmission queue of the alternative link, can be retrieved. " After this the information in the changeover buffer can be added to the transmission queue of the new link. " Signalling traffic is diverted to the alternative signalling link. These actions are shown in figure 73. TRANSMISSION QUEUE TRANSMISSION BUFFER FAILING LINK New messages newer messages are copied to the new link TRANSMISSION QUEUE New messages are stored in the changeover buffer Figure 73 CHANGEOVER BUFFER TRANSMISSION BUFFER Changeover Actions In order to perform these tasks, the XCO message and the XCA contain the following information : " " 128 / 297 the Signalling Link Code (SLC) of the unavailable signalling link. the BSNT of the last message accepted from the unavailable signalling link. This BSNT is necessary to determine the points from whereon the buffers have to be copied to the buffers of the new link. 770 00905 0120 VHBE Ed. 02 7 MTP-3 Signalling network management messages are distinguished by the configuration "0000" for the SI, as was already shown in table 6. The routing label of management messages carries the same OPC/DPC as before. On the other hand, the SLS field now indicates the SLC of the signalling link to which the message is related. Besides the routing label, network management messages have an H0 and an H1 field of 4 bits each. H0 identifies the message group (e.g. extended changeover messages), while H1 identifies the specified message (XCO or XCA). The format of the XCO message and the XCA message is shown in figure 74. Routing Label BSNT 3 octets H1 H0 SLC OPC 4 bits 4 bits H0 = 0001 H1 = 0011 for XCO 0100 for XCA DP C 32 bits SIO 8 bits First bit transmitted SLC = Signalling Link Code Figure 74 Note Emergency Changeover 770 00905 0120 VHBE Ed. 02 XCO and XCA Format For the N-ISDN, a changeover and changeover acknowledgement message are used, which contain a sequence number of 7 bits. Obviously, for the B-ISDN, the size of this sequence number had to be extended to 24 bits, which lead to the names XCO and XCA. An emergency changeover procedure has also been defined. This procedure will only be used if one of both signalling terminals is unable to determine the BSNT, identifying last accepted message over the unavailable link, in other words, if the AAL-RETRIEVE_BSNT request is answered by an AAL-BSNT_NOT_RETRIEVABLE confirm ( ). 129 / 297 7 MTP-3 The procedure is triggered by sending an Emergency Changeover (ECM) message or an Emergency Changeover Acknowledge (EMA) message. An XCO can be acknowledged by a ECA or, vice versa, a ECM can be acknowledged by a XCA. Thus, both sides can independently choose between a normal or an emergency changeover. The only difference between both will be that an emergency changeover does not perform buffer updating or retrieval. Instead, the receiver of a ECM or an ECA will immediately start sending the signalling traffic not yet transmitted on the alternative signalling link. By consequence, some information may be lost, since buffers are not updated. The format of the ECM and the ECA are the same as for the XCO and the XCA respectively, except for 2 differences : " " Changeback the last octet (BSNT of last accepted message) is not present. the value of H0 is changed from "0001" to "0010". When the unavailable link is restored back into service, a changeback procedure will guarantee that the information is restored to the original link, as quickly as possible, without loss, duplication or missequencing. However, the mechanism will be different from the changeover mechanism, in which all traffic had to be stopped instantaneously on a failed link and buffers had to be copied. This will not be the case in a changeback. Suppose a decision is made at a given Signalling Point A to divert a given traffic flow from an alternative link to the signalling link made available again. It is important to realize that both directions of a traffic flow will be independently removed from the signalling link. Therefore, the following actions apply for a uni-directional traffic flow. " " 130 / 297 A will stop the transmission of new traffic on the alternative signalling link; such traffic will be stored in a "changeback buffer" at the A side. However, the PDUs, already present in the transmission queue and transmission buffers will still be handled. a Changeback Declaration (CBD) is sent to the remote Signalling Point B, via the alternative signalling link. This message indicates that no more messages will be sent from A to B, via the alternative signalling link. It is the last message of the concerned traffic flow on the signalling link. 770 00905 0120 VHBE Ed. 02 7 MTP-3 " Note when B receives this CBD, it knows it has not to expect any more traffic via the alternative link, and B will send a Changeback Acknowledgement (CBA) in response. On his turn, this message indicates that all messages relating to the concerned traffic flow via the alternative link have been received. Any available Signalling Route between the 2 Signalling Points can be used to carry the CBA. " Finally, when A receives this CBA, it will copy its changeback buffer to the transmission queue belonging to the restored signalling link. The handshake procedure for changeback is shown in figure 75. Note that here a handshake is necessary for the 2 directions of the traffic flow, which gives rise to 4 messages. Restored Signalling Link Point Code A CBA2 CBA1 Point Code B CBD1 CBD2 Figure 75 Handshake procedure for Changeback In the changeover procedure, it was necessary for both parties to communicate the sequence number of the last received message to each other to obtain synchronization and to know from where on buffers had to be copied. This will not be necessary in the changeback procedure. A CBD or a CBA directly indicates that no more messages will be sent over the alternative link, meaning that at that time the transmission queue and transmission buffer do not contain any more traffic belonging to the traffic flow under consideration. Therefore, no buffer updating will be performed. The actions for changeback are shown in figure 76. 770 00905 0120 VHBE Ed. 02 131 / 297 7 MTP-3 CHANGEBACK BUFFER TRANSMISSION QUEUE TRANSMISSION BUFFER restart sending RESTORED LINK New messages TRANSMISSION QUEUE New messages for the restored link are stored in the changeback buffer TRANSMISSION BUFFER ALTERNATIVE LINK All messages of the traffic flow which is being diverted, will be out of these buffers, before a CBD or a CBA is transmitted. Figure 76 Changeback Actions The outlook of the CBD and CBA message is shown in figure 77. Of course, they resemble the XCO and XCA messages closely. The differences are : " " The field which contained the value of the last accepted message is replaced by a 8-bit field to contain a "Changeback Code". This code allows discrimination between different CBDs and CBAs when more than one sequence control procedure is initiated. " 132 / 297 The values of the H1 field are different. In the case that a Signalling Point intends to initiate changeback in parallel from more than 1 alternative links, a sequence control procedure is accomplished for each involved link. A CBD will be sent on each of them, each with a different changeback code. Stopped traffic will be stored in more changeback buffers. When the CBA is received, traffic can be restarted on the restored link, starting with the content of the corresponding changeback buffer. Indeed, discrimination between the different CBAs is made by means of the changeback code, which is the same as the one sent in the CBD. 770 00905 0120 VHBE Ed. 02 7 MTP-3 Routing Label CB Code H1 H0 SLC 8 bits OPC 4 bits 4 bits H0 = 0001 H1 = 0101 for CBD 0110 for CBA 32 bits DPC SIO 8 bits First bit transmitted CB Code = Changeback Code Figure 77 Forced Rerouting CBD and CBA format. A sequence of signalling links leading to a specific destination is called a Signalling Route. In other words, when the CCS #7 network is working normally, messages between to Signalling Point are sent over a specific Signalling Route. Forced rerouting will be initiated at a Signalling Point, when a Transfer Prohibited (TFP) message, indicating the unavailability of that Signalling Point is received. At that moment, forced rerouting will be used to set up a new set of routing entries. In this way, the destination will become available again, but via an alternative route. During the forced rerouting, the messages are temporarily stored in a forced rerouting buffer. In this way, the amount of messageloss due to rerouting can be minimized. However, in general, since the procedure will often be caused by the fact that a STP has become inaccessible, a probability of message loss exists. Consider the example of figure 78. When the link AB goes out of service, both A and B perform a changeover, so traffic can be sent via C, that will serve as a STP for the messages between A and B. 770 00905 0120 VHBE Ed. 02 133 / 297 7 MTP-3 Point Code B Changeover Point Code A Changeover Point Code C Figure 78 Controlled Rerouting Forced Rerouting The objective of the controlled rerouting procedure is to restore the optimal signalling routing and to minimize missequencing of messages. Controlled rerouting can be used in the following two cases : Controlled rerouting will be initiated at a Signalling Point, when a Transfer Allowed (TFA) message, indicating the availability of a Signalling Point is received. It can also be triggered when a Transfer Restricted (TFR) message is received. 134 / 297 770 00905 0120 VHBE Ed. 02 7 MTP-3 Point Code B Changeback Point Code A Changeback Point Code C Figure 79 MTP Restart Controlled Rerouting When a Signalling Point has been isolated from the CCS #7 network for some time, it can not be sure that its routing data are still valid. Events involving adjacent Signalling Points may have occurred, while it was isolated, and because no messages were routed to the Signalling Point, it can not be aware of this. The objective of the MTP restart procedure is to protect the CCS #7 network and the node whose MTP is restarting. This is done by giving the restarting MTP "sufficient" time to activate sufficient links, and to exchange enough routing data with the CCS #7 network, before user traffic is restarted. A central part of the restart procedure is the exchange of network status information between the restarting MTP and the adjacent nodes. The node, whose MTP layer is restarting, will send Traffic Restart Allowed (TRA) messages towards all its adjacent nodes. In response to this, all adjacent nodes will send all relevant TFP and/or TFR messages, to allow the restarting MTP to update its routing data. When an adjacent node has finished to send all relevant data, it will also send a TRA message to the restarting MTP indicating that all relevant routing information has been sent. , Thus, at the node of the restarting MTP the number of received , TRAs indicates the completeness of the routing data. This is shown in figure 80. 770 00905 0120 VHBE Ed. 02 135 / 297 7 MTP-3 Point Code A TRA Point Code C TFP and TFR finished by TRA Point Code X TFP and TFR finished by TRA Figure 80 TRA TRA TFP and TFR finished by TRA Point Code B TFP and TFR finished by TRA TRA Point Code D MTP Restart The outlook of the TRA message is shown in figure 81. Routing Label H1 H0 SLC 4 bits 4 bits H0 = 0111 H1 = 0001 for TRA Figure 81 Management Inhibiting OPC 32 bits DPC SIO 8 bits First bit transmitted TRA message Signalling link management inhibiting is requested by management when it becomes necessary to make or keep a signalling link unavailable to User Part generated signalling traffic. This can be done e.g. to be able to send maintenance or test messages without interference from any of the User Parts. It is usually a manual procedure, used by maintenance personnel for testing the reliability of a link, e.g., if the link experiences too many changeovers and changebacks in a short period of time. However, it must be stressed that the link still remains available for transmitting these maintenance and test messages, in other words, the link status for level 2 does not change. 136 / 297 770 00905 0120 VHBE Ed. 02 7 MTP-3 The request will be granted provided that the inhibiting action does not cause any previously accessible destinations to become inaccessible at either end of the signalling link. The request may also be refused under certain circumstances such as congestion. A link may be inhibited by sending a inhibit request to the remote end of the signalling link. An inhibit acknowledgement or an inhibit denied message will be sent in response. A signalling link normally remains inhibited until uninhibiting is invoked in the Signalling Point at which inhibiting was initiated. This is called "local uninhibiting". However, if routing control finds out that an inhibited link is a member of a linkset to a route which has become inaccessible, it can uninhibit even a remotely inhibited link. This is called "Forced Uninhibiting". When a signalling link becomes management inhibited, periodic tests are started to guard the inhibition status at each end of the link. Such tests will be started from the side which has inhibited the link ("Local Inhibit Test"), but they will also start from the other side ("Remote Inhibit Test"). The outlook of the inhibiting and uninhibiting messages is shown in figure 82. Routing Label H1 H0 SLC 4 bits 4 bits OPC DP C 32 bits SIO 8 bits First bit transmitted H0 = 0110 H1 = 0001 for Link Inhibit Signal (LIN) 0010 for Link Uninhibit Signal (LUN) 0011 for Link Inhibited Acknowledgement Signal (LIA) 0100 for Link Uninhibited Acknowledgement Signal (LUA) 0101 for Link Inhibit Denied Signal (LID) 0110 for Link Force Uninhibit Signal (LFU) 0111 for Link Local Inhibit Test Signal (LLT) 1000 for Link Remote Inhibit Test Signal (LRT) Figure 82 770 00905 0120 VHBE Ed. 02 Management Inhibit messages 137 / 297 7 MTP-3 Signalling Traffic Flow Control The purpose of traffic flow control is to limit signalling traffic at its source when the signalling network is not capable of transferring all signalling traffic offered by the user. For instance, if message distribution is unable to give the message to level 4 because of a congestion condition, or because the User Part at level 4 is not available, MTP Flow Control is invoked to inform the originator of the problem. Of course, the desired result of the actions is a reduction of traffic being generated for the affected destination, by the user generating it. The intent of the procedures is to deal with congestion at the source, where the messages are being generated. The advantage of this approach is twofold : " Only the User Part experiencing the congestion is affected, rather than for instance the entire Signalling Point. The congestion flow control will be directed at a specific User Part. This allows other traffic to continue without impedance. " Congestion is dealt with at its source, rather than by trying to redirect messages around the congestion. If a particular node is causing congestion, the amount of traffic generated by that node, will be throttled, instead of redirecting all traffic to another destination. In fact , much about flow control is implementation dependent. The standards only identify the need for such procedures, and suggest how they can be addressed. They may be the consequence of a number of events, such as : " Failure in the signalling network (signalling links or Signalling Points). " Congestion of a signalling link or Signalling Point. " Failure of a certain User Part has made it impossible to handle messages, delivered by MTP . Therefore, indications must be provided for following purposes : " " Signalling Route set congestion " Signalling Point congestion " User Part availability/unavailability " 138 / 297 Signalling Route set availability/unavailability User Part congestion 770 00905 0120 VHBE Ed. 02 7 MTP-3 The only message, that is presently defined for flow control is the User Part Unavailable (UPU) message. Its outlook is shown in figure 83. Routing Label ÇÇ ÇÇ ÇÇ User Cause Part ID Destination H1 H0 SLC 4 bits 4 bits 2 OPC 14 bits 4 bits 4 bits DP C 32 bits SIO 8 bits First bit transmitted H0 = 1010 H1 = 0001 for UPU Destination : carries the point code of the failed User Part User Part ID : follow the same coding as the SI Cause = 0000 for Unknown 0001 for Unequipped Remote User Part 0010 for Inaccessible Remote User Part Figure 83 User Part Unavailable message Note that the destination field is not necessarily equal to the OPC. Let us look at the situation, shown in figure 84. Suppose some User Part (e.g., TUP) is unavailable in Signalling Point D. When Signalling Point A sends a message to it, it will be informed of this by a UPU message, coming from D, via C towards A. Even more, if later Signalling Point B tries to do the same, possibly it can be directly Signalling Point C informing B of the unavailability of the TUP in Signalling Point D (provided that C has enough intelligence to keep track of this). 770 00905 0120 VHBE Ed. 02 139 / 297 7 MTP-3 Point Code A UPU(Dest=D, OPC=C) UPU(Dest=D, OPC =D) Point Code C Point Code B Figure 84 7.6.2 Point Code D UPU(Dest=D, OPC=C) Use of UPU message Link Management Functions Signalling Link Management Functions provide a number of procedures to enable you to manipulate individual signalling links. Following procedures are foreseen : Signalling Link Activation When a link is first activated, MTP-3 will direct layer 2 to begin the alignment procedure and place the link in service. Before messages can be actually transmitted over the link, link management will also send test messages over the link, to ensure its integrity. Such a test message will be called a Signalling Link Test Message (SLTM). It will be generated by Link Management and transmitted towards the other side, where it will be acknowledged by a Signalling Link Test Acknowledgement (SLTA) message. After this the link is put into service and traffic is allowed over it. Signalling Link Deactivation This is used when a link is found in error and needs to be placed into alignment. Link Deactivation will first stop all traffic to the link, by invoking traffic management procedures. Signalling Link Restoration When a link is in error, the same alignment procedures will take place to have it restored. Also the same test messages (SLTM and SLTA) will be sent. Link Set Activation 140 / 297 A Signalling Link Set, not having any signalling links in service is started by means of a link set activation procedure. Signalling link activation will start on as many signalling links as possible. All activation procedures are performed in parallel. 770 00905 0120 VHBE Ed. 02 7 MTP-3 Automatic Allocation of Signalling Terminals and Signalling Data Links With this feature, which very few systems offer, links can be automatically disconnected from one linkset and be reassigned to another linkset. The feature is usually invoked by a threshold value, which can be set by the administration. For instance, when a linkset falls below the predefined threshold, another predefined link can be removed from its linkset and reassigned by Link Management to another linkset. The currently defined messages to accomplish this are : " Signalling Datalink Connection Order (DLC) : indicating Signalling Point has decided to reallocate a link and informs the adjacent Signalling Point of the new assignment. " Connection Successful Signal (CSS) : indicating that the signalling link has been connected to his new assignment. " Connection Not Successful Signal (CNS) : indicating that it was not possible to connect the signalling link and that an alternative signalling data link should be allocated. " Connection Not Possible Signal (CNP) : indicating that it was not possible to connect the signalling link and that no alternative signalling data link should be allocated. However, in and ATM network, the current procedures require further study. At a minimum, the current messages must be enhanced to carry ATM connection identifiers and possibly additional parameters relating to the information rate and QoS of the ATM connections to be used for signalling. 7.6.3 Route Management Functions These procedures are used to transfer information related to the availability of Signalling Routes or entire Signalling Points. Following procedures are foreseen : Transfer Prohibited Procedure 770 00905 0120 VHBE Ed. 02 This procedure is performed by a Signalling Point, acting as an STP for messages to a given destination, when it has to notify one or more adjacent Signalling Points that they must no longer route the concerned messages via this STP . 141 / 297 7 MTP-3 The procedure makes use of the Transfer Prohibited message (TFP) which contains the destination for which traffic is no longer possible. It is shown in figure 85. TFPs are always addressed to an adjacent Signalling Point. However, they may use any available Signalling Route that leads to that Signalling Point. Routing Label Ç Ç Ç Destination 2 14 bits H1 H0 SLC OPC 4 bits 4 bits DP C 32 bits SIO 8 bits First bit transmitted H0 = 0100 H1 = 0001 for TFP 0101 for TFA 0011 for TFR Destination : carries the point code of the destination in question Figure 85 TFP TFA and TFR messages. , A TFP relating to a given destination X is sent from STP Y in following cases (not an exhaustive list) : " When STP Y starts to route traffic for X via another STP Z. In that case, a TFP will be sent to Z. Of course, otherwise traffic coming from Z would be looped back to Z and would become caught in an endless loop. This is shown in figure 86. Y X TFP(X) Z Figure 86 " 142 / 297 New Route TFP : Example 1. When STP Y recognizes the inaccessibility of X. In this case, a TFP is broadcasted to all adjacent Signalling Points. This is shown in figure 87. 770 00905 0120 VHBE Ed. 02 7 MTP-3 TFP(X) TFP(X) Y X TFP(X) TFP(X) Figure 87 " TFP : Example 2 To a particular Signalling Point Z if Y receives a message from Z and can not deliver it to X. Of course, a TFP message can have a cascading effect, rippling from one Signalling Point to other adjacent Signalling Points. This situation is shown in figure 88. TFP(B) X A TFP(B) TFP(B) Y Figure 88 B X TFP(B) Y Transfer Prohibited When a Signalling Point receives a TFP it may perform forced , rerouting and if necessary, it may even generate additional TFP messages to other Signalling Points. Transfer Allowed Procedure This procedure does the opposite of the transfer prohibited procedure. The transfer-allowed procedure is performed at a Signalling Point, acting as a STP for messages relating to a given destination, when it has to notify one or more adjacent Signalling Points that they may start to route the concerned messages via this STP . The procedure makes use of the Transfer Allowed message (TFA) which contains the destination for which transfer is now possible. The message structure is the same as the TFP which was , shown in figure 85. 770 00905 0120 VHBE Ed. 02 143 / 297 7 MTP-3 TFAs are always addressed to an adjacent Signalling Point. However, they may use any available Signalling Route that leads to that Signalling Point. A TFA relating to a given destination X is sent from STP Y in following cases (not an exhaustive list) : " When STP Y stops routing traffic for X via another STP Z. In that case, a TFA will be sent to Z, since Z is now allowed to route traffic destined for X via Y. " When STP Y recognizes that it is again able to transfer traffic destined to X. In this case a TRA will be broadcasted to all adjacent Signalling Points (except X of course). When a Signalling Point receives a TFA, it may perform controlled rerouting and if necessary, it may even generate additional TFA messages to other Signalling Points. Transfer Restricted Procedure The transfer restricted procedure is performed at a Signalling Point acting as an STP for messages towards a given destination, when it has to notify one or more adjacent Signalling Points that they should, if possible, no longer route the concerned messages via this STP . However, the restriction does not prevent messages from being transferred from the STP entirely (as was the case in the transfer prohibited procedure). The restriction prevents normal traffic flow, and forces other STPs to find an alternate route for traffic destined for the affected Signalling Point. If there are no alternate routes available, then the traffic can still be routed through the STP like normal. The procedure makes use of the Transfer Restricted message (TFR) which contains the destination for which transfer is restricted. Also this message structure is the same as the TFP , which was shown in figure 85. TFRs are always addressed to an adjacent Signalling Point. However, they may use any available Signalling Route that leads to that Signalling Point. A TFR relating to a given destination X is sent from STP Y when the normal linkset between X and Y experiences a long-term failure. Then a TFR is broadcasted to all adjacent Signalling Points, to suggest alternative routes if possible. This is the "broadcast method". When a significant number of links in a linkset fail, a TFR is sent to adjacent Signalling Points using the "response method". The response method sends the TFR whenever a signalling message is received on a link for transfer to the affected Signalling Point. 144 / 297 770 00905 0120 VHBE Ed. 02 7 MTP-3 When a Signalling Point receives a TFR, it may perform forced rerouting and if necessary, it may generate additional TFR messages to other Signalling Points. Signalling Route-set Test Procedure This procedure is used at a Signalling Point to test whether or not signalling traffic towards a certain destination may be routed via an adjacent Signalling Point or not. A Signalling Route Set Test Message for prohibited destination (RST) or a Signalling Route Set Test Message for restricted destination (RSR) is sent from a Signalling Point after a TFP or a TFR has been received, respectively. In that case, in each certain period of time a RST or RSR is sent to that Signalling Point, until a TFA is received. This is done to ensure that a prohibited or restricted Signalling Point does not get stuck in that condition indefinitely. A RST is used to test a prohibited status, while an RSR is used to test for the restricted condition. At the reception of a RST or RSR, a Signalling Point will compare the actual status of the destination, with that indicated by the message. If they are equal, no further action is taken. If they are different, a TFA, TFR or TFP shall be sent in response, depending on the circumstances, to communicate the actual status of the destination. The format of the RST and RSR messages is shown in figure 89. Routing Label Destination Ç Ç Ç 2 H1 H0 SLC 14 bits 4 bits 4 bits H0 = 0101 H1 = 0001 for RST 0010 for RSR OPC DP C 32 bits SIO 8 bits First bit transmitted Destination : carries the point code of the destination in question Figure 89 Transfer Controlled Procedure 770 00905 0120 VHBE Ed. 02 RST and RSR message In the international CCS #7 network, the Transfer Controlled (TFC) message is used to convey a congestion indication. It contains the identity of the congested destination. Its format is shown in figure 90. 145 / 297 7 MTP-3 In national signalling networks, using multiple congestion states, the spare bits in the TFC are used to carry the congestion status associated with the destination. In that case, the TFC indicates that Signalling Points should no longer send to the concerned destination messages with a given priority or lower. Routing Label Ç Ç Ç Destination 2 H1 H0 SLC 14 bits 4 bits 4 bits OPC DP C 32 bits SIO 8 bits First bit transmitted H0 = 0011 H1 = 0010 for TFC Destination : carries the point code of the destination in question. Figure 90 TFC message Signalling Route-set Congestion Test Procedure The Signalling Route Set Congestion Test (RCT) message is used to update the congestion status associated with a route towards a certain destination. The purpose is to test whether or not signalling messages towards that destination with a given congestion priority or higher may be sent. In this way, the responsibility to continuously monitor the congestion status and to determine when it has changed is placed on the the receiver of a TFC message. Normally, signalling network management messages are assigned the highest congestion priority. However, the congestion priority of the RCT is carried by the spare bits of the SIO. " If after sending a RCT message, a TFC message relating to the concerned destination is received, the congestion status of the Signalling Route can be updated. " If no TFC message is received after a certain time, it can be assumed that the RCT has been passed and the congestion level has changed. However, there is still no indication of what the new congestion status is. Therefore, another RCT message with a priority of one less than the previous one will be generated. This procedure can be repeated until a TFC message is received as a reply. The outlook of the RCT is shown in figure 91. 146 / 297 770 00905 0120 VHBE Ed. 02 7 MTP-3 Routing Label H1 H0 SLC 4 bits 4 bits H0 = 0011 H1 = 0001 for RCT Figure 91 OPC DP C 32 bits SIO 8 bits First bit transmitted RCT message This finishes the chapter of MTP-3. Thus far, we have seen that, on top of the capability of transmitting error-free information (SSCOP), it provides routing and addressing functionality. In addition, it has the capacity of reacting to and possibly solving network and link failures. 770 00905 0120 VHBE Ed. 02 147 / 297 7 MTP-3 148 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 8 Q.2931 This chapter describes the Q.2931 functionality, which is the layer 3 functionality at the UNI of an B-ISDN environment. Its functionality, the message coding, and a subset of its messages and parameters are described in this chapter. Further, also a number of additional capabilities, including Q.2961 and Q.2971 extensions, are presented. 770 00905 0120 VHBE Ed. 02 149 / 297 8 Q.2931 8.1 Q.2931 Services. Q.2931 is based on Q.931, which specifies the protocol for DSS1. There is a high degree of similarity between the used messages. On the other hand, the Information Elements (IEs), which are the parameter messages, are often different. The basic capabilities, which are supported in Q.2931, are listed below : " Support of switched Virtual Channels (VCs). On demand Virtual Paths (VPs) are not supported. On-demand connections can remain active for an arbitrary amount of time but are not automatically re-established after a network failure. These VC connections are point-to-point, either symmetric or asymmetric, i.e., the bandwidth of the forward direction (calling to called party) is independently specified from the bandwidth of the backward direction (called to calling party). The VPCI is used as the way of identifying the Virtual Path across the UNI, with a restriction that there is a one-to-one mapping between VPCI and VPI. " Only Single-connection Calls are supported. In future, multi-connection calls may exist, for instance one call can contain a video and an audio connection. However, for the moment this is not supported by Q.2931. " Error recovery procedures are defined. They include the means for one signalling entity to inform its peer when it has encountered a non-fatal error, to exchange state information, to recover from loss of individual messages and to force calls, VCs and interfaces to an idle state. " Public UNI Addressing Formats for unique identification of ATM endpoints. Public networks will base their addressing and routing on E.164 addresses. " Means to control end-to-end compatibility, intransparant for the network. For this reason, several parameters are specified in the SETUP message, e.g., AAL type", Subaddress", BB High Layer Information" and BB Low Layer Information". " 150 / 297 Interworking with N-ISDN services and provision of N-ISDN services. 770 00905 0120 VHBE Ed. 02 8 Q.2931 " Forward Compatibility. This is based on the use of instruction indicators in messages and information elements, which specify the actions in case message and parameters are not recognized. 8.2 General Coding Principles of Q.2931 Messages. Constituents Every Q.2931 message consists of an integral number of octets and encompasses the following parts : " Common IEs It is defined which Information Elements may appear in which message, mandatory or optionally. However, some IEs are common for all messages. They are : D Protocol Discriminator D Call Reference " The Message Type is an 8 bit field used to uniquely identify a Q.2931 message. " Message Compatibility Information. This defines the behavior if a message is not understood " Message Content. It is precisely defined which Information Elements may appear in which message, mandatory or optionally The general layout of a Q.2931 message is depicted in figure 92. 770 00905 0120 VHBE Ed. 02 151 / 297 8 Q.2931 Bits 8 2 3 0 0 1 7 0 Octets 0 6 5 4 3 2 1 PROTOCOL DISCRIMINATOR 0 0 1 0 0 1 LENGTH OF CALL REF VALUE 0 0 0 0 1 1 Flag 4 CALL REFERENCE VALUE 5 MESSAGE TYPE 6 7 1 0 0 Flag 0 0 Msg. action indicator 8 MESSAGE LENGTH 9 10 Figure 92 8.2.1 MESSAGE DEPENDANT INFORMATION ELEMENTS General Layout of a Q.2931 Message Common IEs Protocol Discriminator The purpose of the Protocol Discriminator is to distinguish the message as a Signalling Message for the B-ISDN UNI, obeying Q.2931. It is 1 octet long and its value equals "00001001" for a Q.2931 message. This parameter is present in all DSS2 messages and always has the same value. The specification of the protocol discriminator does not imply that the protocol may share the signalling VC with other layer 3 protocols. Call Reference The Call Reference IE is 4 octets in length, including octet 2 which contains the length of the Call Reference value, which is always 3. This parameter identifies the call at the local UNI interface to which the message applies. It remains fixed during the lifetime of a call. 152 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 The Call Reference has only local significance and absolutely no end-to-end meaning, i.e., the call references at the two UNI-interfaces of the same ordinary two-party call may be completely different. The call reference includes a call reference flag and a call reference value. Call references are assigned by the originating side of the interface for a call. Of course, these values must be unique within a particular signalling virtual channel. The call reference flag identifies who allocated the call reference value. It is set to "0" if the message is sent from the side that originated the call reference, and it is set to "1" if the message is sent from the other side. Thus, this flag resolves simultaneous attempts to allocate the same call reference value, i.e., it prevents double seizure. This is shown in figure 93. SET UP ( CRF = 0, CRV= 8 ) SET UP ( CRF = 0, CRV=14 ) NE CALL PROCEEDING (CRF = 1, CRV = 8) CALL PROCEEDING (CRF = 1, CRV=14) CRF : Call Reference Flag CRV : Call Reference Value Figure 93 Use of the Call Reference Flag Two special values exist for the call reference value : the global call reference value and the dummy call reference value. " " 770 00905 0120 VHBE Ed. 02 The global call reference value is encoded as "0", i.e. all bits set to "0". It is used to support error procedures. The equipment that receives a message with the global call reference, shall interpret the message as pertaining to all call references associated with the appropriate signalling VC. The global call reference can be used in the RESTART, RESTART ACKNOWLEDGE and the STATUS message. The use of the call reference flag does not change. The call reference value with all bits set to 1 indicates a dummy call reference value. In the future, it may be used for certain supplementary services. Here also, the use of the call reference flag does not change. 153 / 297 8 Q.2931 8.2.2 Message Type The Message Type parameter identifies the function of the message. An incomplete list of DSS2 Message Types together with their identifier coding can be found in tables 7, 8, 9, 10 and 11. 8.2.3 Message Compatibility Information This octet contains information that indicates explicitly how the receiver shall handle unrecognized messages, i.e., a message compatibility instruction indicator. This can be explicitly specified by the sender of the message. The possibilities are : • 0 : instruction field not significant D Flag 1 : follow explicit instructions The flag, set to "0" indicates that normal error handling procedures apply. Otherwise, if the flag equals "1", then explicit instructions as indicated in the message action indicator must be followed. 00 : clear call 01 : discard and ignore D 8.2.4 • D Message Action Ind. 10 : discard and report status Message Length The Message Length is present in every message and gives the length of the content of the message. Excluded are the octets used for the protocol discriminator, the call reference, message type and the message length indication itself. If the message contains no other parameters than the ones described up to now , the message length is coded as "0". 8.2.5 Message Content The Information Elements are the last part of each message. They appear at the end. The coding rules of the specific IEs is formulated in such a way that each equipment which processes a message can find the IEs important to it and yet remain ignorant of the ones not important to that particular equipment. 154 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 Variable Order The IEs in a message may appear in any order except in special cases where certain information elements are repeated. This is a notable difference between Q.931 and Q.2931. Indeed, in Q.931, the IE identifiers for the variable-length IEs were assigned in ascending numerical order, according to the actual order of appearance of each IE in a message, which was fixed. Thus, the receiving equipment could detect the presence or absence of a particular IE without having to scan through the entire message. This is not possible anymore in DSS2. The general layout of a variable length information element is depicted in figure 94. Bits Octets 8 6 5 4 3 2 1 INFORMATION ELEMENT IDENTIFIER 1 2 7 1 Coding Standard Flag Reserved IE action indicator 3 LENGTH OF CONTENTS OF INFORMATION ELEMENT 4 5 Figure 94 IE Identifier CONTENTS OF INFORMATION ELEMENT General Layout of a Q.2931 Information Element The first octet of every information element identifies the information element. An incomplete overview of the most important existing IEs, together with their identifiers is shown in tables 12, 14 and 16. The table also shows which IEs can be found in which messages. An "M" stands for "Mandatory", an "O" for "Optional". The value 1111 1111" for the IE identifier is reserved for an extension mechanism, allowing 65 536 additional IEs , in case that all values for the IE identifier would be exhausted. However, for the moment a length of 1 byte, allows 255 distinct IE identifiers to be discerned, out of which 26 are used in Q.2931. Therefore, it is not worth pursuing this extension mechanism. Coding Standard 770 00905 0120 VHBE Ed. 02 The second octet contains the coding standard field, which indicates ITU-T, ISO/IEC, national standard or others. 155 / 297 8 Q.2931 The other coding standards should only be used when the IE contents can not be represented with the ITU-T standardized coding. 00 : ITU-T 01 : ISO/IEC D 10 : National Standard D Compatibility Instruction Indicator • D Coding Standard. 11 : Standard defined for the network Further, the second octet also contains an element compatibility instruction indicator. It serves the same purposes as the message compatibility instruction indicator, but then on the IE level. The flag, equal to "0" indicates that the regular error handling procedures apply. Otherwise, if it is equal to "1" , the explicit instruction in the IE action indicator must be followed, which can even have consequences upon the message level. 0 : IE instruction field not significant 1 : follow explicit instructions • 000 : clear call D 001 : discard IE and proceed D 010 : discard IE, proceed and report status D 101 : discard message and ignore D IE Action Indicator • D Flag 110 : discard message and report status Reserved Field Bit 4 is a reserved field, for the moment always coded as "0". In the future, it may be used to encode a "pass-along request". Length of IE Contents Length of the IE contents. The third and fourth octet contain the length of the value of the information element, excluding the 4 octets described above. 156 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 8.3 Q.2931 Messages 8.3.1 Call Setup Messages Following messages, shown in table 7 are involved in the establishment of a connection. Table 7 Q.2931 Message Types, functions and coding for a Call Setup. Message Type Function Message Type Code Call Setup Messages SETUP This message is sent by the calling user to the network and by the network to the called user to initiate B-ISDN call and connection establishment. 00000101 SETUP ACKNOWLEDGE MENT This message is sent by the network to the calling user, or by the called user to the net work, to indicate that call establishment has been initiated, but additional information may be required. 00001101 INFORMATION This message is sent by the user or the net work to provide additional information. It may be used to provide information for call establishment (e.g., overlap sending) or mis cellaneous call-related information. 01111011 CALL PROCEEDING This message is sent by the called user to the network or by the network to the calling user to indicate that the requested call establish ment has been initiated and no more call establishment information will be accepted. 00000010 ALERTING This message is sent by the called user to the network and by the network to the calling user to indicate that called user alerting has been initiated. 00000001 CONNECT This message is sent by the called user to the network and by the network to the calling user to indicate call acceptance by the called user. 00000111 CONNECT AC KNOWLEDGEMENT This message is sent by the network to the called user to indicate that the user has been awarded the call. It is also sent by the call ing user to the network to allow symmetrical call control procedures. 00001111 PROGRESS This message is sent by the user or the net work to indicate the progress of a call in the event of interworking. 00000011 770 00905 0120 VHBE Ed. 02 157 / 297 8 Q.2931 These messages are explained in more detail below. SETUP The calling party initiates call establishment by transferring a SETUP message on the SVC across the interface. SAAL However, before this procedure can be started, an assured mode signalling connection must be present between the user and the network, which can be requested by transferring an AAL-ESTABLISH_request primitive towards the SAAL. Upon receipt of an AAL_ESTABLISH_confirm or AAL_ESTABLISH_indication primitive from the SAAL, the layer 3 signalling procedures, which are the subject of this chapter, may begin. The signalling messages are sent to the SAAL using a AAL-DATA_request primitive. Call Reference Mandatory Parameters A lot of calls can be served simultaneously by the same signalling channel. By consequence, in each signalling message a unique identifier for the call is required. This identifier is the Call Reference" parameter. The mandatory parameters in the SETUP message are: " Call reference " ATM traffic descriptor " BB bearer Capability " QoS parameter If en-bloc sending is used, all the information required by the network to process the call will be included, particularly the Called Party Number" and possibly Called Party Subaddress". The BB Sending Complete" IE shall also be included by the B-TEs, to indicate this. Originating Interface At transmission of the SETUP the calling user shall start Timer , T303. If no response is received from the network before a first expiry, then the message shall be retransmitted and the same Timer shall be restarted. If the Timer T303 expires again, the user shall clear the call internally. Two attempts are considered to be enough. Destination Interface At the destination interface, the same procedure happens. After transmission of the SETUP also the network starts Timer T303. , The first timer expiry causes a retransmission of the SETUP The . 158 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 second timer expiry causes a call clearance towards the called user with cause 18 no user responding". Allocation of VPCI/VCI Two different cases exist for the allocation of a VPCI/VCI, to wit associated signalling and non-associated signalling. " In the case of associated signalling, 1 VC signalling channel controls only the VCs carried in the same VPC. " In the case of non-associated signalling, the signalling channel can control VCs in the same but also in other VPCs. It is recommended that non-associated signalling is supported. On the other hand, associated signalling may optionally be supported in the case of a bilateral agreement between the user and the network. Associated Signalling In the case of associated signalling, the user requests a VC in the VPC carrying the signalling VC. In the connection identifier IE , "VP associated signalling" will be indicated. The user can still choose " " Non-Associated Signalling "any VCI" "exclusive VCI" In the case of non-associated signalling, in the SET UP the user shall indicate : " "Exclusive VPCI, any VCI" " "Exclusive VPCI, exclusive VCI" " "No indication" In both cases, the accepted VCI is returned in the first message in response to the SET UP message, which can be a CALL PROCEEDING, an ALERTING or a CONNECT message. If the requested VPCI/VCI combination can not be granted, the response is a RELEASE COMPLETE message with cause 45 "no VPCI/VCI available" or cause 35 "requested VPCI/VCI not available". Originating Compatibility Checks After the receipt of a SETUP at the originating interfaces, the network performs 3 compatibility checks. The network checks if the Call Information is valid and if it can offer the requested Bearer Service. It also checks if it can offer the requested QoS to that user. " 770 00905 0120 VHBE Ed. 02 If the received call information is invalid, then the network shall send a RELEASE message with one of the following causes : 159 / 297 8 Q.2931 D D Cause 3 : "No route to destination" D Cause 22 : "Number changed" D " Cause 1 : "Unassigned number" Cause 28 : "Invalid number format" If the network can not offer the requested bearer service, then it shall send a RELEASE message with one of the following causes : D D Cause 58 : "Bearer capability not presently available" D Cause 63 : "Service or option not available" D " Cause 57 : "Bearer capability not authorized" Cause 65 : "Bearer service not implemented" If the network can not offer the requested QoS or cellrate, then it shall send a RELEASE COMPLETE message with one of the following causes : D D Destination Compatibility Checks Cause 49 : "QoS unavailable" Cause 37 : "User cell rate unavailable" At the destination interface, and upon receipt of the SET UP message, the called user shall also perform 3 kinds of compatibility checking. " First, the addressing information is checked, i.e. the information in the called party number IE and/or called party subaddress is compared to the corresponding part of the number assigned to the user or users subaddress. In case of a mismatch, the user rejects the call. " Secondly, BB Category 1 Compatibility Information should be checked. This information concerns both the network and the called user. More precisely, it concerns the BB Bearer capability, the QoS, the ATM Traffic descriptor and possibly the OAM Traffic descriptor. Also the end-to-end transit delay can be used. If the called user is unable to accept the call because of a mismatch in this category, he will reject the call with one of the following reasons. D D Cause 49 : "QoS unavailable" D 160 / 297 Cause 88 : "Incompatible destination" Cause 47 : "Resource unavailable" 770 00905 0120 VHBE Ed. 02 8 Q.2931 " Thirdly, BB Category 2 Compatibility Information should be checked. This information concerns only the terminal equipment of the called side. More precisely, it concerns the AAL IE, the B-HLI and the B-LLI. If the called user is unable to accept the call because of a mismatch in this category, he will reject the call with cause 88 "incompatible destination". 770 00905 0120 VHBE Ed. 02 161 / 297 8 Q.2931 CALL PROCEEDING The CALL PROCEEDING message is sent by the called user to the network and by the network to the calling user to indicate that the requested call establishment has been initiated and no more call establishment information will be accepted. Originating Interface At the originating side, the calling user, when he receives a CALL PROCEEDING message, shall stop Timer T303 and start Timer T310. Both user and network shall enter the "Call proceeding state". Destination Interface At the destination side, the called user, when he sends a CALL PROCEEDING message, shall enter the "Incoming Call proceeding state". The CALL PROCEEDING can be used by a user which can not respond in time with an ALERTING or a CONNECT message, where in time means before expiry of Timer T303. Thus, the called user can still prevent the unnecessary transmission of a SETUP by the network. If Timer T310 expires before reception of an ALERTING or a CONNECT message, then the user itself shall initiate clearing procedures towards the network with cause 12 "recovery on timer expiry" A CALL PROCEEDING carries, a.o., the Call Reference" and the assigned VPI/VCI to be used for the user plane information. VPCI/VCI Selection Depending upon the content of the SETUP message, VPCI/VCI selection takes place. Finally, the accepted VPCI/VCI is returned in response to the SET UP message. If the requested VPCI/VCI combination can not be granted, the response is a RELEASE COMPLETE message with cause 45 "no VPCI/VCI available" or cause 35 "requested VPCI/VCI not available". NOTICE 162 / 297 This method of VPCI/VCI allocation offers a lot of flexibility. Very simple terminal equipment can delegate VCPI/VCI control completely to the network. On the other hand, more intelligent equipment can maintain its own VPCI/VCI control. 770 00905 0120 VHBE Ed. 02 8 Q.2931 ALERTING The ALERTING message is sent by the called user to the network and by the network to the calling user to indicate that the called user alerting has been initiated. Originating Interface At the originating side, after the receipt of an ALERTING message, the user stops timers T310 and T303 and may begin an internally generated alerting indication. Both user and network enter the Call Delivered state". A new Timer T301 is started Destination Interface At the destination side, after the receipt of an ALERTING message, the network stops timers T310 and T303 and starts Timer T301. 770 00905 0120 VHBE Ed. 02 163 / 297 8 Q.2931 CONNECT The CONNECT message is sent by the called user to the network and by the network to the calling user to indicate call acceptance by the called user. Originating Interface At the originating interface, the CONNECT message indicates to the calling user that a connection has been established through the entire network and it stops possible local alerting. The calling user stops all timers and attaches to the user plane. An acknowledgement is sent as a reply. Destination Interface At the destination interface, the called user, after sending a CONNECT, enters the Connect Request state" and starts Timer T313. After the network has responded with a CONNECT ACKNOWLEDGE , the called user enters the Active state", stops Timer T313 and attaches to the user plane. However, this acknowledgement does not guaranty an end-to-end connection, until a CONNECT is received by the calling user. Outgoing Call Setup The scenario for an outgoing call setup, i.e. the user originates a call towards the network, is shown in figure 95. The scenario is for en bloc sending, i.e. all information to setup the call is contained in one time in the SETUP message. The call control states of the individual call is also shown. Obviously, these states do not apply to the state of the interface, or attached equipment . Indeed, if several B-ISDN calls exist simultaneously at the UNI, then each call may be in a different state. Therefore, there can be no unambiguously defined state of the interface. 164 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 User (Null) U0 (Call Initiated) U1 (Outgoing Call Proceeding) U3 (Call Delivered) Network SET UP U4 (Null) N1 (Call Initiated) N3 (Outgoing Call Proceeding) N4 (Call Delivered) N10 CALL PROCEEDING N0 (Active) ALERTING CONNECT (Active) Figure 95 U10 CONNECT ACK Scenario for Outgoing Call Establishment, User to Network. Incoming Call Setup 770 00905 0120 VHBE Ed. 02 The scenario for an incoming call setup, i.e. the network establishes a call towards the user, is shown in figure 96. Also this scenario is for en bloc sending, i.e. all information to setup the call is contained at once in the SETUP message. Note that both scenarios are identical, only the call states differ. 165 / 297 8 Q.2931 Network (Null) (Call Received) N7 U6 (Call Present) (Incoming Call Proceeding) (Call Received) U8 (Connect Request) U10 N9 CALL PROCEEDING (Null) U7 N6 (Incoming Call Proceeding) SET UP U0 U9 N0 (Call Present) User (Active) ALERTING CONNECT (Connect Request) N8 (Active) N10 Figure 96 CONNECT ACK Scenario for Incoming Call Establishment, User to Network Overlap Sending Until now, neither the SETUP ACKNOWLEDGE message nor the INFORMATION message have been explained yet. These messages are only used for overlap sending. In fact, it is explicitly recommended that Broadband (BB) terminal equipment shall use en bloc sending in a pure B-ISDN. Thus, the option of overlap sending is only provided to allow interworking with a N-ISDN, in which overlap sending is still a valid option. SETUP ACKNOWLEDGE It is sent in response of a SETUP message to indicate that call establishment has been initiated, but additional information may be required. This additional information (some remaining digits for instance) will be provided, using the INFORMATION message. INFORMATION This message is sent by the user or the network to provide additional information. It may be used to provide information for call establishment (e.g. overlap sending) or miscellaneous call-related information. 166 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 At the destination interface, overlap receiving can occur, e.g., with an indialling Private Automatic Branch Exchange (PABX), having implemented overlap receiving. The modified scenarios for overlap sending are shown in figures 97 and 98. After the CALL PROCEEDING message, the original scenarios simply continue. Use r (Null) U0 (Call Initiated) U1 Networ k SETUP N0 N1 (Call Initiated) N2 (Overlap sending) N3 SETUP ACKNOWLEDGE (Null) (Outgoing Call Proceeding) INFORMATION (Overlap sending) U2 CALL PROCEEDING (Outgoing Call Proceeding) Figure 97 U3 ........ Modifications for Overlap Sending for an Outgoing Call Establishment. Network (Null) N0 (Call Present) N6 SETUP SETUP ACKNOWLEDGE Use r U0 (Null) U6 (Call Present) INFORMATION (Overlap sending) N25 U25 (Overlap sending) U9 (Incoming Call Proceeding) CALL PROCEEDING (Incoming Call Proceeding) N9 ........ Figure 98 Modifications for Overlap Sending for Incoming Call Establishment 770 00905 0120 VHBE Ed. 02 167 / 297 8 Q.2931 8.3.2 Call Release Messages The messages, shown in table 8, are involved in the release of a connection. They will be explained in more detail below. Table 8 Q.2931 Message Types, functions and coding for a Call Release. Message Type Function Message Type Code Call Release Messages RELEASE This message is sent by the user to request the network to clear the end-to-end con nection, or is sent the network to indicate that the end-to-end connection is cleared. 01001101 RELEASE COMPLETE This message is sent by the user or the net work to indicate that the equipment sending the message has released its call reference value and, if appropriate, the connection identifier. 01011010 RELEASE If the RELEASE message is sent by the user to request the network to clear the end-to-end connection, we call this an user-initiated release. On the other hand, if this message is sent by the network, we call it a network-initiated release. In that case, the RELEASE indicates that the end-to-end connection is already cleared, and the receiving equipment is asked to release the call reference value and / or connection identifiers after sending a RELEASE COMPLETE. RELEASE COMPLETE Disconnected and Release The RELEASE COMPLETE message is sent by the user or the network to indicate that the equipment sending the message has released its call reference value and / or the connection identifiers. The receiving equipment shall also release its call reference value and /or connection identifiers if this has not been done yet. Perhaps, first the difference between a "disconnected" VC and a "released" VC should be explained. " " 168 / 297 A VC is said to be disconnected when the VC is no longer part of a B-ISDN virtual connection, but is not yet available for use in a new virtual connection. A VC is said to be released when the VC is not part of a B-ISDN virtual connection and is available for use in a new virtual connection. 770 00905 0120 VHBE Ed. 02 8 Q.2931 User-initiated Release When the user wants to initiate a clearing, he will do so by sending a RELEASE message and starting Timer T308. After this he can disconnect the VC and enter the "Release Request" state. After the receipt of this RELEASE message, the network shall also enter the "Release Request" state and disconnect the VC as well. Once this has happened, the network shall send a RELEASE COMPLETE message and release the VC and the call reference. When the user receives this RELEASE MESSAGE, the user shall stop Timer T308, and he will also release the VC and the call reference. If timer T308 expires for the first time, the user shall retransmit the RELEASE message and restart the timer. The second time T308 expires, the user shall place the VC in a maintenance condition. Indeed, the user can have no certainty about the condition of the call reference and connection identifier at the network side, he can not know if the network did receive the RELEASE request and cleared the call accordingly. The maintenance condition means that the equipment shall perform implementation dependant recovery, such as initiating restart procedures. The scenario for a release, initiated by the user is shown in figure 99. User U10 (Active) (Release Request) RELEASE RELEASE COMPLETE U0 N10 (Active) N11 (Release Request) N0 U11 (Null) Figure 99 Network (Null) Scenario for Call Release, User Initiated Network-initiated Release This procedure is completely symmetrical to the above. The few differences are " " 770 00905 0120 VHBE Ed. 02 It is now the network side, who employs Timer T308. By consequence, it will be the network side, controlling the correct reception of a RELEASE COMPLETE from the user, and deciding to put the VC in a maintenance condition. The intermediate state (between the RELEASE and the RELEASE COMPLETE message) is now called "Release Indication" instead of "Release Request". 169 / 297 8 Q.2931 The scenario for a release, initiated by the network is shown in figure 100. Network (Active) N10 (Release Indication) N12 (Null) User N0 Figure 100 RELEASE (Active) U12 (Release Indication) U0 RELEASE COMPLETE U10 (Null) Scenario for Call Release, Network Initiated NOTICE A noticeable difference with the Release scenarios from N-ISDN, is that the Q.931 DISCONNECT message has disappeared In other words, the 3-steps release procedure (disconnect, release, release complete) from N-ISDN is converted into an easier 2-steps release procedure (release, release complete). <Preventive action> Originally, in DSS1, the DISCONNECT message was intended to support procedures, in which a user could request the network connection to be released, without loosing its own connection to the network, i.e. the connection across the UNI would be preserved. However, no applications nor services, using this feature did arise, causing the network to answer with a release message across the UNI, each time a DISCONNECT was transmitted. In this way, the DISCONNECT message became absolutely superfluous. In DSS2, it is completely skipped. 170 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 8.3.3 Maintenance Messages Following messages are involved in maintenance tasks, regarding a connection or a UNI. Restart Table 9 Q.2931 Message Types, functions and coding for Restart. Message Type Function Message Type Code Restart Messages RESTART This message is sent by the user or the net work to request the recipient to restart (i.e., return to an idle condition) the indicated VC, all VCs in a VP or all VCs controlled by the signalling VC. 01000110 RESTART ACKNOWLEDGE This message is sent to acknowledge the re ceipt of a RESTART message and to indicate that the requested restart is complete. 01001110 A restart procedure is used whenever the other side of the interface does not react properly to other call control messages. It can also be triggered as the result of a local failure or maintenance action. Restart procedures return all allocated resources of a VC, such as call references and bandwidth to an idle condition. The VCs, to be rendered idle, are indicated in the Restart Indication IE" in the RESTART message, together with a Connection Identifier IE". The 3 possibilities for the Restart indication are " "indicated VC" " "all VCs in the indicated VPC controlled via SVC" " "all VC controlled by the layer 3 entity" This information is complemented by the information, carried in the Connection Identifier IE". RESTART When the user transmits the RESTART, he shall enter the "Restart Request" state and start Timer T316. The VCs, being restarted, shall not be used to support new calls, while Timer T316 is running. Nor will new RESTART messages be sent. Receipt of a RESTART ACKNOWLEDGE from the network will stop Timer T316 and indicates that the VCs can be freed for reuse, i.e., 770 00905 0120 VHBE Ed. 02 171 / 297 8 Q.2931 the user will release the VCs and call references. After that, he shall enter the "Null" state. If Timer T316 expires for the first time, one ore more (but one by default) subsequent RESTART message may be sent and the timer will be restarted. After this the user shall make no further attempts but an indication will be provided to the appropriate maintenance entity. When this has happened, the VC is considered to be in an out-of-service condition until a maintenance action has been taken. RESTART ACKNOWLEDGE The RESTART ACKNOWLEDGE message is sent to acknowledge the receipt of a RESTART message and to indicate that the requested restart is complete. The scenarios for restart are shown in figures 101 and 102. Again both scenarios are symmetrical, only the states at both sides differ. It should be stressed that these are states relating to the global call reference, i.e. the states the protocol may adopt when the global call reference is used. These states exist simultaneously with the individual call states. Only one global call reference value may exist per SVC. Its value is recommended to equal "0000 0000". Use r Network (Null) Rest 0 RESTART Rest 0 (Any State) (Restart Request) Rest 1 RESTART ACK Rest1 (Restart Request) (Null) Rest 0 Rest 0 (Null) Figure 101 172 / 297 Scenario for Call Restart, User Initiated 770 00905 0120 VHBE Ed. 02 8 Q.2931 User Network (Null) Rest 0 RESTART Rest 0 (Any State) (Restart Request) Rest 1 RESTART ACK Rest1 (Restart Request) (Null) Rest 0 Rest 0 (Null) Figure 102 Scenario for Call Restart, Network Initiated Status Enquiry Table 10 Q.2931 Message Types, functions and coding for Restart. Message Type Function Message Type Code Status Messages STATUS This message is sent by the user or the net work in response to a STATUS ENQUIRY message or at any time to report certain er ror conditions. 01111101 STATUS ENQUIRY This message is sent by the user or the net work at any time to solicit a STATUS message from the peer layer 3 entity. 01110101 STATUS ENQUIRY A STATUS ENQUIRY message is used to check the correctness of the call state at the peer side. This is for instance required in situations where the underlying SAAL indicates a reset or a failure. Upon sending the STATUS ENQUIRY message, timer T322 shall be restarted in anticipation of receiving a STATUS message. While timer T322 is running, only 1 outstanding request for call state information shall be sent, i.e., no further STATUS ENQUIRY messages may be sent, during this time. When timer T322 expires, and no STATUS message was received, the STATUS ENQUIRY message may be retransmitted a number of times. This number is an implementation dependent value. After the maximum number of retransmissions of the STATUS ENQUIRY, and without having received a STATUS message, the call shall be cleared. It is mandatory that it is answered by a STATUS message. 770 00905 0120 VHBE Ed. 02 173 / 297 8 Q.2931 STATUS Upon receipt of a STATUS ENQUIRY message, the receiver shall answer with a STATUS message, reporting the current call state. The states, to be reported, are the higher defined states, i.e., U0 till U12 and U25, and N0 till N12 and N25. The STATUS message can also be sent "spontaneously" at any time to report certain error conditions. The scenario for a STATUS ENQUIRY and a STATUS is shown in figure 103. These messages do not change the states of the individual call, nor do they change the state for the global call reference. Since these scenario's are symmetrical, it suffices to draw them only 1. User or Network Network or User STATUS ENQUIRY No state changes Figure 103 No state changes STATUS Scenario for Status Enquiry Notify Finally, there is only 1 message left which has not yet been described. It is the NOTIFY message, used to transfer information for the control of Supplementary Services. Table 11 Q.2931 Message Types, functions and coding for Restart. Message Type Function Message Type Code Notify Message NOTIFY 174 / 297 This message is sent by the user or the net work to indicate information pertaining to a call/connection. 01101110 770 00905 0120 VHBE Ed. 02 8 Q.2931 8.4 Important Q.2931 Information Elements 26 Information Elements have been defined by ITU-T in Ref.[46.]. In this document, we restrict ourselves to the most important ones. The messages in which the parameters are mandatory will always be put in bold. 8.4.1 Information Elements, mainly used in Call Setup Messages Table 12 Q.2931 Parameters names and codes, mainly used in Call Setup. Parameter Type Meaning Mes sages Parameter Type Code AAL Parameters Information sent in the forward or backward direction to indicate the re quested/proposed ATM Adaptation Lay er attribute values (end-to-end signifi cance) for the ATM Adaptation Layer elements of procedures to be used for the call. The contents is transparent for the network, except for the case of in terworking. CONN, SETUP 01011000 ATM Traffic Descriptor The purpose of the ATM Traffic Descrip tor IE is to specify the set of traffic pa rameters which specify a traffic control capability. SETUP 01011001 BB Bearer Capability Information sent to indicate the re quested BB connection oriented bearer service (F.811) to be provided by the network. SETUP 01011110 BB High Layer Informa tion Information sent in the forward direc tion which should be used by the re mote user for compatibility checking. SETUP 01011101 BB Low Layer Informa tion Information sent in the forward or backward direction to provide a means which should be used for compatibility checking by an addressed entity (e.g. a remote user or an interworking unit or a high layer function network node ad dressed by the calling user). CONN, SETUP , 01011111 BB Repeat Indicator The purpose of the BB Repeat Indicator is to indicate how repeated elements shall be interpreted, when included in a message. SETUP 01100011 770 00905 0120 VHBE Ed. 02 175 / 297 8 Q.2931 Parameter Type Meaning Mes sages Parameter Type Code BB Sending Complete The purpose of the BB SendingCom plete IE is to optionally indicate comple tion of called party number. SETUP , INFO 01100010 Called Party Number Information to identify the called party. SETUP 01110000 Calling party number Information sent in the forward direc tion to identify the calling party. SETUP 01101100 Connection Element Identifier Information sent to identify the ATM virtual connection. It includes the VPCI and the VCI. ALERT, CALL PROC, CONN, SETUP 01011010 End-to-end Transit Delay The purpose of the end-to-end transit delay IE is to indicate the maximum end-to-end delay acceptable on a per call basis, and to indicate the cu mulative transit delay to be expected for a VC. CONN, SETUP 01000010 OAM Traffic Descriptor The purpose of the OAM Traffic Des criptor IE is to provide information re lating to the end-to-end OAM F% in formation flow for performance man agement and user-originated fault management associated with the user connection involved in the call. CONN, SETUP 01011011 These parameters will now be discussed in more detail. In the coding representations, the parameter name, nor the parameter length indicator, nor the compatibility information are shown. 176 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 AAL Parameters The AAL parameter IE indicates the requested ATM adaptation layer parameter values to be used for the call. It contains the parameters selectable by the user for all AAL sublayers. Transparency In general, this IE is transparent for the network, since ATM switches are generally not concerned with the contents of the switched ATM user cells. The only exception is made in the case of BB/NB interworking, since an interworking exchange has to terminate the ATM cell stream. Therefore, it must know the AAL parameters. Of course, the content of this parameter greatly depends on the type of the requested ATM Adaptation Layer. Therefore, we shall not examine its coding format. AAL Type The AAL type can be : • 00000000 : AAL for voice D 00000001 : AAL 1 D 00000010 : AAL 2 D 00000011 : AAL 3/4 D 00000101 : AAL 5 D AAL Type 00010000 : user defined AAL Some criteria for these different AAL types are shown in table 13. Table 13 AAL Types AAL1 AAL2 AAL3/4 AAL5 Connectiontype connection-ori ented connection-ori ented either either Bitrate constant variable variable variable Timing end-to-end end-to-end no no Further, following parameters can be included : AAL1 For AAL1 : 00000000 : Null 00000001 : Voice-band Signal Transport on 64 Kbit/sec D 770 00905 0120 VHBE Ed. 02 • D Subtype 00000010 : Circuit Transport 177 / 297 8 Q.2931 D D 00000101 : Video Signal Transport • 00000001 : 64 Kbit/sec D 00000100 : 1 544 Kbit/sec D 00000101 : 6 312 Kbit/sec D 00000101 : 32 064 Kbit/sec D 00000111 : 44 736 Kbit/sec D 00001000 : 97 728 Kbit/sec D 00010000 : 2 048 Kbit/sec D 00010001 : 8 448 Kbit/sec D 00010010 : 34 368 Kbit/sec D 00010011 : 139 264 Kbit/sec D 01000000 : n x 64 Kbit/sec D CBR Rate 00000100 : High-Quality Audio Signal Transport 01000001 : n x 8 Kbit/sec Multiplier Integer Representation of Multiplier Values for the n x 64 or n x 8 Kbit/sec CBR rates. Source Clock Rec. • 00000000 : null D 00000001 : Synchronous Residual Time Stamp (SRTS) D 00000010 : Adaptive Clock Method • 00000000 : null (no error correction) D 00000001 : for loss sensitive transport D 00000010 : for delay sensitive transport Error Correction. Partially Filled Cells Indicator For more information about these parameters, one is referred to Ref.[7.] AAL 2 AAL 3/4 For AAL 2, no further parameters are included. For AAL 3/4 : Forward Maximum CPCS-SDU size (default 65 535 octets) Backward Maximum CPCS-SDU size (default 65 535 octets) 178 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 MID Field : = Multiplexing Id. (Multiple user connections may be multiplexed upon 1 ATM connection. SCCS Type • 00000000 : null D 00000001 : Data SSCS based on SSCOP (assured) D 00000010 : Data SSCS based on SSCOP (non-assured) D 00000100 : Frame Relay SSCS For more information about these parameters, one is referred to Ref.[8.] AAL 5 770 00905 0120 VHBE Ed. 02 For AAL 5, identical as for AAL 3/4, except that the Multiplexing Identifier (MID) range does not exist. 179 / 297 8 Q.2931 ATM Traffic Descriptor This information element specifies a set of traffic parameters, which together specify an ATM Transfer Capability (ATC). Q.2931 only specifies the ATM Peak Cell Rate (PCR) as defined in Ref [10.]. It specifies the upper bound on the traffic that can be submitted on an ATM connection, being the sum of both the user plane information and all end-to-end OAM F5 flow. 8 7 1 0 6 5 4 3 2 1 Forward Peak Cell Rate Identifier (CLP=0) 0 0 0 0 1 0 Forward Peak Cell Rate (for CLP = 0) Backward Peak Cell Rate Identifier (CLP=0) 1 0 0 0 0 0 1 1 Backward Peak Cell Rate (for CLP=0) Forward Peak Cell Rate Identifier (CLP=0 + 1) 1 0 0 0 0 1 0 0 Forward Peak Cell Rate (for CLP = 0 + 1) 1 Backward Peak Cell Rate Identifier (CLP=0 + 1) 0 0 0 0 1 0 1 Backward Peak Cell Rate (for CLP=0 + 1) Figure 104 180 / 297 ATM Cell Rate 770 00905 0120 VHBE Ed. 02 8 Q.2931 Asymmetrical PCR Other Traffic Parameters The PCR in the forward direction and in the backward direction are separately specified, since they can get different values. This clearly indicates the support of asymmetrical connections. The PCR for CLP=0, as well as the PCR for CLP = 0+1 will be separately specified. On the other hand, in Ref [10.], it is specified that PCR(0) is never needed for any ATM Transfer Capability, i.e., not for DBR, nor for SBR, ABR or ABT. This stems from a discrepancy between ITU-T Study Groups (SG) XI and XIII. While, SG XIII, a.o., specifies the ATM Traffic Control in the user plane, SG XI specifies the signalling procedures and parameters. The encoding of other traffic parameters is specified in Ref [48.], Ref.[49.], Ref.[50.], Ref.[51.] and Ref.[52.]. These can be : " Sustainable Cell Rate (SCR) " Maximum Burst Size (MBS) " Minimum Cell Rate (MCR) " ... BB Bearer Capability This parameter indicates the requested BB connection oriented bearer service. This IE is examined by both the network and the end user equipment. Its coding is shown in figure 105. Ext. Ext. Ext. 7 6 5 4 3 ÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉ ÉÉÉÉÉÉ ÉÉÉÉÉÉ 8 2 1 Bearer Class BB Transfer Capability Susceptibility to Clipping Figure 105 Connection Configuration BB Bearer Capability The BB Bearer Capability IE specifies : BB Bearer Class 770 00905 0120 VHBE Ed. 02 The BB Bearer Class describes a service class, which determines parameters as transfer mode, structure, establishment of communication, Quality of Service (QoS), access protocols. 181 / 297 8 Q.2931 Originally, a BB Bearer Class was intended to include Transfer Rate, ATM Transfer Capability and Communication Configuration, but these are extracted into separate IEs. 00001 : BCOB-A (SDU integrity depends upon other parameters) 00011 : BCOB-C (AAL SDU integrity) D 00101 : Frame Relaying (frame SDU integrity) D ATM Transfer Capability • D BB Bearer Class 10000 : BCOB-X (ATM SDU integrity) An ATM Transfer Capability is intended to support an ATM layer service model through a set of ATM layer traffic parameters and procedures. BB Transfer Capability • 0000111 : DBR D 0001011 : SBR, with end-to-end timing not required D 0010011 : SBR, with end-to-end timing required Deterministic Bitrate (DBR) is used by connections that request a static amount of bandwidth that is continuously available during the connection lifetime. This amount of bandwidth is specified by a PCR. In the Statistical Bitrate (SBR), the end-system uses the standardized traffic parameters Sustainable Cell Rate (SCR) and Intrinsic Burst Tolerance (IBT) to describe in greater detail than just the PCR the cell flow that will be emitted on the connection. Susceptibility to Clipping The Susceptibility to Clipping" indicator, provides more precise information about the time of through connection of the user path. If Susceptible to Clipping" is indicated, the backward direction must be through connected completely at the time the SETUP message arrives at the called party. 182 / 297 00 : Not susceptible to clipping 01 : Susceptible to clipping • 00 : Point-to-point D Connection Config. • D Suscept. to Clipping 01 : Point-to-Multipoint 770 00905 0120 VHBE Ed. 02 8 Q.2931 BB Low Layer Information (B-LLI) The purpose of this IE is to provide a means for compatibility checking by the addressed entity. It specifies a proper entity within the called user ATM device that receives the notification of the incoming call, by describing layer 2 and layer 3 protocol information. BB Low Layer Information (B-LLI) is transferred transparently between the call originating entity and the addressed entity. Layer 2 Protocol Examples of user information layer 2 protocol values are : 00010 : Q.921 00110 : X.25 Link Layer D 01000 : Extended LAPB D 010xx : HDLC D 01101 : X.75 D Layer 3 Protocol • D Layer 2 Protocol 01110 : Q.922 Examples of user information layer 3 protocol values are : 00110 : X.25 Packet Layer 01000 : X.223 D 01001 : X.233, OSI CL Mode D Multiple Occurrence • D Layer 3 Protocol. 01010 : T.70, Minimum NW Layer As already mentioned, the calling user can indicate up to three alternative values for the B-LLI. The first B-LLI IE shall be preceded by the BB repeat indicator IE. The order of the B-LLI IEs indicates the order of preference. The called side makes a selection out of the alternative values offered and put the choice in the B-LLI IE in the CONNECT message. BB High Layer Information (B-HLI) Just as the B-LLI, the purpose of this IE is to provide a means which can be used for compatibility checking by an addressed entity. This addressed entity can be the called user, an interworking unit or a high layer function network node, addressed by the calling user. B-HLI Type 770 00905 0120 VHBE Ed. 02 The BB High Layer Information (B-HLI) can be of different types, which are : 183 / 297 8 Q.2931 • 0000000 : ISO D 0000001 : user-specific D 0000011 : vendor-specific D B-HLI Type 0000100 : Ref to ITU-T Teleservice Recommendation Of course, besides the B-HLI type, the higher layer information itself is also included. BB Repeat Indicator This IE is included if certain IEs appear more than once in the message. The repeat indicator is included immediately before the first occurrence of the IE that will be repeated several times. It indicates how the repeated IEs shall be interpreted, when included in a single message. Its coding is shown in figure 106. 7 6 5 ÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉ 8 Ext. Figure 106 3 2 1 BB Repeat Indication BB Repeat Indicator BB Repeat Indication. • Example 4 0010 : prioritized list for selecting one possibility (descending order of priority) For instance, in a SETUP message, up to 3 BB low layer information IEs (B-LLIs) can be included. The BB repeat indicator IE will precede these B-LLIs with an indication of prioritized list. Thus, the order of appearance of the B-LLIs indicates the order of preference of end-to-end low layer parameters. The called user indicates a single choice from among the options offered in the SETUP message by including this specific B-LLI in the CONNECT message, and only this one. In this way, a primitive form of negotiation is allowed. Unfortunately, the example above is for the moment the only specified use of the BB repeat indicator IE. 184 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 BB sending complete This IE is mandatory when en bloc sending procedures are used, i.e., it indicates the completion of the called party number. It is also used, in case of overlap sending, to indicate the final INFORMATION message. Its coding is shown in figure 107. 8 Ext. 7 6 0 1 Figure 107 5 4 3 BB Sending Complete Indication 0 0 0 2 1 0 1 BB Repeat Indicator Called Party Number The purpose of the called party number IE is to identify the called party of a call. Its coding is shown in figure 108. 8 Ext. 7 6 5 Type of Number Ext. Type of Number 3 2 1 Addressing/Numbering Plan Identification Address Number Digits Ext. Figure 108 4 ... Called Party Number The type of number can be : 000 : unknown 001 : International Number D 010 : National Number D 011 : Network Specific Number D 100 : Subscriber Number D 770 00905 0120 VHBE Ed. 02 • D Type of Number 110 : Abbreviated Number 185 / 297 8 Q.2931 Addressing Numbering Plan The addressing numbering plan can be : • 0000 : unknown D 0001 : ISDN, E.164 D 0010 : NSAP Addressing D Address. Nbr. Plan 1001 : Private Numbering Plan Calling Party Number The calling party number identifies the originator of the call. The coding of this information element is very similar to the coding of the called party, except for some additional parameters, which are the "presentation indicator" and the "screening indicator". Presentation Indicator The presentation indicator" can indicate presentation allowed" or presentation restricted". It indicates whether the calling party number can be presented to the called user. This can be requested on a subscription basis. 00 : Presentation Allowed 01 : Presentation Restricted D Screening Indicator • D Presentation Ind. 10 : Number not Available The screening indicator indicates if the calling number is screened or not, i.e., the user-provided calling number can be validated at the originating UNI, meaning that it is compared with a list of number that are valid for that access. If it is screened, the screening indicator" states whether the screening was positive or negative. If the number is invalid, a default number is filled in. If valid the provided number is sent forward. • 00 : User Provided, not Screened D 01 : User Provided,Verified and Passed D 10 : User Provided, Verified and Failed D Screening Ind. 11 : Network Provided Connection Identifier The Connection Identifier IE identifies the local ATM connection resources on the interface. It identifies the channel over which the user information is transported. 186 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 VPCI/VCI The Connection Identifier is a concatenation of the VPCI and the VCI. Recall that the VPCI is chosen instead of the VPI, because there can be VP cross-connects in the network between the user side and the VC switches. This has already been mentioned before. The coding of the Connection Identifier IE is shown in figure 109. Ext. 7 6 ÉÉÉÉÉÉ ÉÉÉÉÉÉ ÉÉÉÉÉÉ 8 5 4 VP Associated Signalling 3 2 1 Bearer Class VPCI VCI Figure 109 Negotiation Connection Identifier The Connection Identifier is negotiated during call set up. The user can indicate VP-associated signalling" or not. Associated means that the same VPI will be used for the user information as for signalling. • 00 : VP-Associated Signalling D VP Associated Sig. 01 : Explicit Indication of VPCI The user can also indicate a preferred" or exclusive" value for the VPCI/VCI. • 000 : Exclusive VPCI / Exclusive VCI D Preferred/Exclusive. 001 : Exclusive VPCI / Any VCI If Exclusive VPCI /VCI" is included in the SETUP message, no negotiation over the VPCI/VCI is possible. If the Connection Identifier IE is absent in the SETUP it means that any virtual , channel is acceptable. The Connection Identifier is also mandatory in the message, that is the first message in response to the SET UP message. This can be the CALL PROCEEDING, ALERTING or the CONNECT message. 770 00905 0120 VHBE Ed. 02 187 / 297 8 Q.2931 End-to-end Transit Delay This parameter indicates the maximum end-to-end transit delay acceptable on a per-call basis and the cumulative transit delay to be expected for a VC connection. Its coding is shown in figure 110. 8 7 6 5 4 3 2 1 Cumulative Transit Delay Identifier 0 0 0 0 0 0 1 0 Cumulative Transit Delay Value Maximum End-to-end Transit Delay Identifier 0 0 0 0 0 0 1 1 Maximum End-to-end Transit Delay Value Figure 110 End-to-end Transit Delay The transit delay is the end-to-end one-way transit delay of user data , transferred between the calling and the called user. It includes the total processing time in the end user systems (e.g., processing time, AAL handling delay, ATM cell segmentation and reassembly,...) It also includes the propagation delay through the network and the switches. Maximum End-to-end Transit Delay Cumulative Transit Delay 188 / 297 The maximum end-to-end transit delay" value may be indicated by the calling user to specify end-to-end transit delay requirements for this call. The cumulative transit delay" value, included in the SET UP message, is updated along the route of the call. Thus, the CONNECT message will contain the complete end-to-end transit delay, as provided by the called user. 770 00905 0120 VHBE Ed. 02 8 Q.2931 OAM Traffic Descriptor The purpose of the OAM traffic descriptor IE is to provide information relating to the end-to-end OAM F5 flows, which are defined at the ATM layer and cover the VC level. These F5 OAM flows are bidirectional and follow the same physical route as the user-data cells, thus constituting an in-band maintenance flow. Several kinds of F5 OAM flows exist. They are defined in Ref. [11.]. They are : " AIS For reporting defect indications in the forward direction. " RDI For reporting defect indications in the backward direction. " Continuity Check A permanent monitoring stream to guarantee continuity. " Loopback Allows for operation related information to be inserted at one location along a VC and looped back at a different location, without having to take the connection out of service. " Performance Monitoring Blocks of user cells can be monitored by inserting monitoring cells after each block. The performance monitoring results, regarding cell loss or misinsertion can be reported back in the backward direction. It goes without saying that such diversity of F5 OAM flow can change the profile of the user-traffic considerably. Therefore, they should be taken into account when monitoring the user traffic. The OAM Traffic Descriptor IE conveys this information. Its coding is shown in figure 111. 770 00905 0120 VHBE Ed. 02 189 / 297 8 Q.2931 7 Compl Ind. 4 Forward end-to-end F5 flow indicator Figure 111 Shaping Indicator 5 Shaping Indicator Ext. Ext. 6 3 ÉÉÉÉ ÉÉÉÉ ÉÉÉÉ ÉÉÉÉ ÉÉÉÉ 8 2 1 Bearer Class Backward end-to-end F5 flow indicator OAM Traffic Descriptor This indicator gives information regarding to traffic shaping options. Traffic shaping is a mechanism that alters the traffic characteristics of a stream of cells on a VC to achieve a desired modification of these characteristics, e.g. Cell Delay Variation (CDV) reduction, burst length limiting, ... Compliance Indicator • 00 : No user specified requirement D Shaping Indicator. 01 : Aggregate Shaping not Allowed This indicator specifies : Compliance Indicator. • D User-NW Fault Mgmt 1 : Use of end-to-end F5 is mandatory This indicator specifies the amount of user-originated fault management cells, as e.g., loopback cells. User-NW Fault Mgt. • D Forward OAM F5 Flow 0 : Use of end-to-end F5 is optional 000 : No user-originated fault mgmt 001 : Use of user-originated fault mgmt with a rate of 1 cell/sec This indicator specifies the amount of F5 OAM cells as a percentage of the forward PCR indicated in the ATM Traffic Descriptor" IE 000 : 0 % of PCR(0 +1) 001 : 0,1 % of PCR(0 +1) D Backward OAM F5 Flow • D Fwd OAM F5 Flow. 100 : 1 % of PCR(0 +1) This indicator specifies the amount of F5 OAM cells as a percentage of the backward PCR indicated in the ATM Traffic Descriptor" IE Bckwd OAM F5 Flow. • 190 / 297 000 : 0 % of PCR(0 +1) 770 00905 0120 VHBE Ed. 02 8 Q.2931 D 001 : 0,1 % of PCR(0 +1) D 100 : 1 % of PCR(0 +1) The absence of the OAM traffic descriptor IE does not mean that no F5 OAM flow will be used within the call. It does mean that the OAM shall be included in the user-data flow, thus allowing the user to send less traffic than specified in the ATM traffic descriptor IE. 770 00905 0120 VHBE Ed. 02 191 / 297 8 Q.2931 8.4.2 Parameters, mainly used in Call Release Messages Table 14 Q.2931 Parameters names and codes, mainly used in Call Release. Parameter Type Cause Meaning Mes sages Parameter Type Code Information sent in either direction indi cating where and why the call failed or was cleared REL, 00001000 RLC The Cause IE The contents and the use of the cause IE is defined in Ref.[46.]. Several cause values of N-ISDN are reused. They are defined in Ref.[14.]. Some cause values are explicitly added for the sake of B-ISDN. They are : Table 15 B-ISDN Specific Cause Values Cause 35 Requested VPCI/VCI not available 36 VPCI/VCI assignment failure 37 User Cell Rate not available 45 No VPCI/VCI available 93 192 / 297 Definition AAL Parameters can not be supported 770 00905 0120 VHBE Ed. 02 8 Q.2931 8.4.3 Parameters, mainly used in Maintenance Control Messages Table 16 Q.2931 Parameters names and codes, mainly used in Maintenance Control. Parameter Type Meaning Mes sages Parameter Type Code Call State Information to describe the current sta tus of a call/connection. STATUS 00010100 Restart Indicator Information to identify the class of the facility to be restarted REST, REST ACK 01111001 The Call State IE The purpose of the call state information element is to describe the current status of a call. These call states are the states, already mentioned in chapter 8.3, i.e. U0 to U12 and U25, N0 to N12 and N25, and REST0 to REST2. The Restart Indicator IE The purpose of the restart indicator is to identify the class of the facility to be restarted. This information has to be complemented with a Connection Identifier IE". Its coding is shown in figure Ext. Figure 112 Class 7 6 5 ÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉ 8 4 3 2 1 Class BB Repeat Indicator The indicated class can be : 000 : Indicated VC 001 : All VCs in the indicated VPCI D 770 00905 0120 VHBE Ed. 02 • D Class. 010 : All controlled VCs 193 / 297 8 Q.2931 8.5 Interworking with N-ISDN 8.5.1 Introduction What ? Two things are meant by interworking: " B-ISDN should be able to provide 64 kbit/s circuit-mode N-ISDN services. This is also referred to as "N-ISDN emulation". " Interworking of access signalling between N-ISDN and B-ISDN. These 2 cases are illustrated in figure 113. B-ISDN "N-ISDN emulation" "IW of access sig nalling" B-ISDN Terminal B-ISDN Terminal IWF Ç N-ISDN N-ISDN Terminal Figure 113 Interworking between B-ISDN and N-ISDN 8.5.2 Emulation of N-ISDN services in a B-ISDN NB IEs For the provision of N-ISDN services, basically the DSS1 Information Elements "Bearer Capability IE", "High Layer Compatibility IE" and the "Low Layer Compatibility IE" are defined. In DSS2, these IEs are designated as Narrowband Bearer Capability (N-BC)", Narrowband Low Layer Compatibility (N-LLC)" and Narrowband High Layer Compatibility (N-HLC)". 194 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 Naturally, for their application in a B-ISDN, these DSS1 IEs will be modified according to the DSS2 coding rules. Advantage The benefit of taking the DSS1 service related IEs nearly unchanged in DSS2 is that it significantly simplifies the procedures for the access signalling interworking between a B-ISDN and a N-ISDN. Further, these DSS1 IEs are even used for the emulation of N-ISDN services in a pure B-ISDN. The reason for this is that the originator does not know in advance whether a call requesting a N-ISDN service will terminate on a N-ISDN or a B-ISDN, (i.e. the user only knows the services, not the protocols of the crossed networks). 8.5.3 Interworking between UNI protocols N-ISDN towards B-ISDN This clause handles calls that are originated by N-ISDN equipment and routed through the B-ISDN network. The interworking is performed by a Terminal Adaptor (TA) or an Interworking Function (IWF). The procedures are as follows. " The DSS1 BC" IE is mapped on the DSS2 N-BC" IE and coded according to Q.2931. There is no change of contents. " The DSS1 LLC" IE (if included) is mapped on the DSS2 N-LLC" IE and coded according to Q.2931. There is no change of contents. " The DSS1 HLC" IE (if included) is mapped on the DSS2 N-HLC" IE and coded according to Q.2931. There is no change of contents. " The DSS2 B-BC" is created and indicates BCOB-A" and the value Susceptible to clipping". " The ATM Traffic Descriptor" and the QoS" IEs are generated. " The AAL Parameters" IE is generated and indicates AAL type 1". " The End-to-end Transit Delay" and OAM Traffic Descriptor" IEs are not created. All of this is illustrated in figure 114. 770 00905 0120 VHBE Ed. 02 195 / 297 8 Q.2931 B-ISDN IWF DSS2 SET UP N-ISDN DSS1 SET UP map N-BC N-LLC N-HLC generate BC LLC HLC B-BC AAL parameters ATM Traffic Descriptor QoS Figure 114 Interworking from N-ISDN towards B-ISDN B-ISDN towards N-ISDN This clause handles calls that are originated in the B-ISDN network and routed to the N-ISDN network. Obviously, the interworking is also performed by a Terminal Adaptor (TA) or an Interworking Function (IWF). However, in this case the IWF or TA will only process N-ISDN service related IEs. If a B-ISDN specific service is asked but routed to the N-ISDN network the call is rejected by the IWF or TA. As can be expected, the procedures will be more or less the inverse of the previous clause. 196 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 8.6 8.6.1 Additional Capabilities Overview " Point-to-Multipoint Calls Procedures are provided for the setup and release of a call consisting of a single point-to-multipoint, unidirectional connection. The characteristics of this connection, from the originator (root) to the destinations (leaf parties) are all identical. Procedures are provided for the addition and removal of leaf parties from the call. D Addition of leaf parties can only be done by the root party. D Removal of a leaf can be from either the root or the affected leaf party. Additionally, en-bloc" release of the whole point-to-multipoint connection from the root is provided. The procedures are described in Ref.[58.]. " Additional Traffic Parameters Procedures are provided to the support of additional traffic parameters, as there are : D D parameters for the ATM Transfer Capability (ATC) (described in Ref.[49.]). D parameters to support Available Bit Rate (ABR) (described in Ref.[50.]). D parameters to support ATM Block Transfer (ABT) (described in Ref.[51.]). D 770 00905 0120 VHBE Ed. 02 parameters for Sustainable Cell Rate (SCR) (described in Ref.[48.] and Ref.[53.]). parameters to support Cell Delay Variation Tolerance (CDVT) (described in Ref.[52.]). 197 / 297 8 Q.2931 " Look-ahead Capability The look-ahead procedure allows a public or private network to check whether compatible and incompatible terminals are addressed and whether these terminals are free or busy. This procedure can be used prior to the establishment of a call/connection. The procedures are described in Ref.[57.]. " Negotiation of Traffic Characteristics during Call Setup 2 Cases of negotiation are allowed : D Alternative ATM Cell Rate If the bandwidth requirements in the connection request can not be supported by the network, alternative bandwidth requirements, contained in the Alternative ATM Cell Rate" may be used instead, provided that these can be supported. D Minimum ATM Cell Rate If the bandwidth requirements in the connection request can not be supported by the network, a reduced bandwidth allocation may be substituted, provided that this still satisfies a specified minimum ATM cell rate. The procedures are described in Ref.[54.]. " Modification of Traffic Characteristics during the Active Phase Procedures are provided for the modification of traffic parameters (forward and/or backward) of a point-to-point connection. Only the user that originally requested the setup of the connection can request the modification. The procedures, to modify the PCR, are described in Ref.[55.]. The procedures, to modify the SCR, are described in Ref.[56.]. " Call Priority Priority Call Handling is provided for single connection point-to-point calls. The procedures are described in Ref.[47.]. Some of these additional capabilities are discussed in more detail, hereafter. 198 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 8.6.2 Point-to-Multipoint Calls Ref.[58.] enhances DSS2 with the capability to add or remove parties to a connection, in other words point-to-multipoint connections are provided. Unidirectional Prior Arrangement Such a Q.2971 point-to-multipoint connection shall always be unidirectional. The source of a point-to-multipoint is called the "root" of the connection, while the destination sides are called the "leafs". Some service providers may require prior arrangement to be a root. No prior arrangement with the service provider is required to be a leaf. Figure 115 shows an imaginary configuration, in which a number of receivers (the TV-sets) receive the images from a sender (the camera). Note that all leafs will receive the same image at any time. The leafs can not send information back to the sender, nor can they send information to each other. Leaf 1 Leaf 2 Root Leaf 3 Leaf 4 Figure 115 Setup Addition of Leaves 770 00905 0120 VHBE Ed. 02 A Unidirectional Point-to-Multipoint Connection The point-to-multipoint connection is setup by first requesting the establishment of a connection between the root and one leaf, indicating point-to-multipoint in the BB Bearer Capability" IE. After this setup has progressed to alerting or active, additional leaves can be added to the connection by add party requests from the root. As such, leafs will only be added to a call under the 199 / 297 8 Q.2931 control of the root. In other words, no leaf-initiated joining" is provided. Multiple add party requests, pending at the same time are allowed (i.e. the root does not need to wait for a response related to one add party request before issuing the next one). Obviously, this way parties can be added "in parallel", which is a lot more efficient than a setup "in series". Dropping of Leaves On the other hand, leafs can withdraw from a call under the control of the root, but also on their own initiative. In the example above, this means that the receivers can not join the connection by themselves, although they can decide to break the connection to their own TV-set. Multiple drop requests can be pending at the same time. If, as a result of a drop party procedure, there are no leaf parties remaining, the entire call will be released on the initiative of the root. Messages and Scenarios Following additional messages are involved in the establishment of a point-to-multipoint connection. Table 17 Q.2971 Message Types, functions and coding for a Call Setup. Message Type Function Message Type Code Call Setup Messages for Point-to-Multipoint Connections ADD PARTY This message is sent from the root to the net work to request the addition of a party to an existing connection. 10000001 PARTY ALERTING This message is sent from the network to the calling user to indicate the called party alert ing has been initiated 10000101 ADD PARTY AC KNOWLEDGE This message is sent from the network to the user to acknowledge that the add party re quest was successful. 10000011 ADD PARTY REJECT This message is sent from the network to the calling user to acknowledge that the add party request was not successful. 10000010 DROP PARTY This message is sent by the root to the net work or by the network to the root to drop a party from an existing point-to-multipoint connection. 10000011 200 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 Message Type DROP PARTY AC KNOWLEDGE Originating Interface only Scenario for a Call Setup Function This message is sent by the root to the net work or by the network to the root in re sponse to a DROP PARTY message to indi cate that the party is dropped from the con nection. This message has only local signifi cance and does not imply an acknowledge ment of dropping from the remote user. Message Type Code 10000100 It is worthwhile, pointing out that the additional messages (ADD PARTY, PARTY ALERTING, ADD PARTY ACKNOWLEDGE and ADD PARTY REJECT) are never be used at the terminating interface. There, they shall be treated as unrecognized or unexpected messages. Exceptions exist only if the terminating user is a private B-ISDN. The scenario for the successful establishment of a point-to-multipoint connection with 2 leafs is shown in figure 116. The scenario is for en bloc sending. Moreover, overlap scenarios are not even defined for point-to-multipoint connections. This can easily be explained since overlap procedures are only defined to support interworking with N-ISDN, while multicast connections are intended specifically for broadband equipment. The setup procedure of the first party is identical to the Q.2931 procedure. However, if the SETUP message contains a non-zero value for the backward cell rate field in the ATM Traffic Descriptor" IE, the network shall reject the call with cause 73 "unsupported combination of traffic parameters". Further, for a point-to-multipoint setup, the OAM Traffic Descriptor" IE has to be omitted. Indeed, according to Ref.[11.], OAM flows are not supported for point-to-multipoint connections. Subsequent parties can only be added with ADD PARTY messages, until the call is in the "Active" state. This is to make sure that all parties (calling user, called user and network) are in agreement upon the characteristics of the connection. Note that this restriction only applies for the first party. The network shall not enforce this restriction on subsequent add party requests. Party States 770 00905 0120 VHBE Ed. 02 On top of the point-to-point call control states (= link states), complementary party states are maintained in the root, and only there. A separate party state exists for every party, participating in the call. 201 / 297 8 Q.2931 In figure 116 , the call control states are not shown anymore, since these will be identical to the ones shown in the corresponding Q.2931 scenarios. However, 2 party states are drawn (Px and P'x) one for each of the 2 leafs. With the same notation, two distinct destination interfaces (UNI and UNI') are represented. Root User (Null) P0 (Add Party Initiated) P1 Network SET UP CALL PROCEEDING Leaf User Network P0 (Null) P2 (Add Party Received) SET UP CALL PROCEEDING ALERTING (Party Alerting Received) P4 ALERTING P3 (Party Alerting Delivered) CONNECT P7 (Active) CONNECT ACK CONNECT P7 (Active) CONNECT ACK Network' (Add Party Initiated) P'1 SET UP ADD PARTY P'2 (Add Party Received) PARTY ALERTING (Party Alerting Received) (Party Alerting Delivered) P'7 (Active) ADD PARTY ACK P'7 (Active) Figure 116 CALL PROCEEDING ALERTING P'3 P'4 Leaf User' CONNECT CONNECT ACK Establishment of a Point-to-Multipoint Connection, with 2 Leafs Scenario for Call Release The scenario for a call, having 2 parties, and for which the root drops both parties, one after the other, is shown in figure 117. In this case, the network at the originating UNI, answers the first DROP PARTY message, with a DROP PARTY ACKNOWLEDGE. 202 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 However, the second time, it answers with a RELEASE message, since it will detect that it is the last party being dropped, more precisely, all other parties associated with the call are either in the "Null", "Drop Party Initiated" or "Drop Party Received" state. Network Root User (Drop Party Initiated) (Any state) DROP PARTY (Any state) P5 P0 P6 RELEASE (Drop Party Received) P0 DROP PARTY ACKNOWLEDGE Leaf User Network (Null) RELEASE COMPLETE (Null) Network' (Any state) (Drop Party Initiated) (Null) P6 P0 (Drop Party Received) P0 P5 Figure 117 (Any state) DROP PARTY Leaf User' RELEASE (Null) RELEASE RELEASE COMPLETE Dropping of 2 Parties, Initiated by the Root Complete Release In addition to the scenario above, in which leafs are dropped, one by one, the root can also choose to release all parties at once, by sending a RELEASE message to the network. In that case : " " the network shall drop all parties towards the remote users (=the leafs) with a RELEASE message with cause 31 "normal unspecified". " 770 00905 0120 VHBE Ed. 02 the network shall send an ADD PARTY REJECT message to the root for each party being in the "Add Party Received" state. " Party Dropping initiated by the Leaf the network shall enter the "Null" state, for all parties already being in the "Drop Party Initiated" and "Drop Party Received" state. respond towards the root with a RELEASE COMPLETE message. The scenario for a call, having 2 parties, and for which each leaf drops itself, one after the other, is shown in figure 118. 203 / 297 8 Q.2931 In this case, the user at the originating UNI, will answer the first DROP PARTY message, with a DROP PARTY ACKNOWLEDGE. However, the second time, he will answer by a RELEASE message, since he will detect that it is the last party being dropped, more precisely, all other parties associated with the call are either in the "Null", "Drop Party Initiated" or "Drop Party Received" state. Thus, we can conclude that it is the responsibility of both the user and the network sides of the originating UNI, to guarantee that no calls remain without any party being associated to it. Root User (Drop Party Received) P6 P0 P5 RELEASE (Drop Party Initiated) P0 DROP PARTY ACKNOWLEDGE Leaf User (Any state) DROP PARTY (Any state) Network Network (Null) RELEASE COMPLETE (Null) Network' (Any state) (Drop Party Received) (Any state) DROP PARTY P5 (Drop Party Initiated) P0 P6 Figure 118 P0 RELEASE (Null) RELEASE (Null) Leaf User' RELEASE COMPLETE Dropping of 2 Parties, initiated by the Leafs Q.2971 Information Elements Two new IEs have been defined, to support he addition of the Q.2971 capabilities. They are shown in table 18 : 204 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 Table 18 Q.2971 Parameters names and codes. Parameter Type Meaning Messages Parameter Type Code Endpoint Reference This IE uniquely identifies a leaf. ADD PARTY, ADD PARTY ACK, PARTY ALERTING., ADD PARTY REJ., DROP PARTY, DROP PARTY ACK, STATUS, STATUS ENQUIRY 01010100 Endpoint State This IE indicates a party state. STATUS 01010101 Endpoint Reference The purpose of the Endpoint Reference" IE is to identify the individual endpoints of a point-to-multipoint call. The endpoint reference identifier is a 15-bit integer. The first party in a point-to-multipoint call shall always use Endpoint Reference Identifier" value "0". On the other hand, a non-zero value is assigned by the root to uniquely identify the subsequent parties of the call. The reason for this is that the first party should have the chance to negotiate, e.g. over ATM Traffic Descriptor and QoS. The only means by which a leaf can detect that it is the first party is by the endpoint reference value "0". Once the connection has been setup, with agreement between both users and the network upon all parameters, the subsequent parties shall have no opportunity anymore to negotiate. The Endpoint Reference" IE may be present in a STATUS ENQUIRY and a STATUS message, if the enquiry is about a party state. If this is the case, the Endpoint State" IE shall also be present in the STATUS message. Endpoint State Impact on Q.2931 770 00905 0120 VHBE Ed. 02 The purpose of the Endpoint State" IE is to indicate the state of an endpoint of a point-to-multipoint connection. These party states are the states, already mentioned in this section, i.e. P0 till P7. The Endpoint Reference" IE is included in every ALERTING, CALL PROCEEDING, CONNECT, SETUP and NOTIFY message, relating to a point-to-multipoint call, i.e. the user-plane connection configuration field in the BB Bearer Capability" IE should indicate "point-to-multipoint". 205 / 297 8 Q.2931 Further Contents of Messages Each ADD PARTY message contains the same IEs as the original SETUP message, except for the following : " the ATM Traffic Descriptor" and the QoS parameter" IE are not repeated, since the same values must be used for all leafs. Of course, one could not never imagine having a 1 Mbit/sec stream to one leaf, and a 2 Mbit/sec stream to another one, both coming from the same source. However, one can easily imagine to have one certain QoS class for one leaf, while having a higher QoS class serving another leaf (which will correspondingly pay). Though, this appears to be prohibited by the protocol. Finally, since both IE, will not be repeated in the ADD PARTY message, it will be the responsibility of the network side of the originating UNI to maintain this information. " Although the AAL parameters", the B-LLI" and the B-HLI" are repeated in the ADD PARTY, it is still mandatory that their values will be the same as those of the SETUP message. " No Broadband Repeat indicator" may be present before the B-LLI since only the first party may do some negotiation. Subsequent parties may not. " No Connection Identifier" shall be present. Recall that the ADD PARTY message is only used at the originating UNI, and there the VPCI/VCI value has already been agreed upon during the setup of the first party. Obviously, the replication of the ATM cell stream will be done as late as possible, i.e. certainly not before originating UNI. Doing this would mean a complete waste of resources. " An Endpoint Reference" IE is always present Each ADD PARTY ACKNOWLEDGE message contains the same IEs as the CONNECT message, except for the following : " No Connection Identifier" IE is present anymore. " No OAM Traffic Descriptor" IE is present anymore. " An Endpoint Reference" IE is always present Each PARTY ALERTING message contains the same IEs as the ALERTING message, except that " No Connection Identifier" IE is present anymore. " An Endpoint Reference" IE is always present Each DROP PARTY message contains the same IEs as the RELEASE message, except that " 206 / 297 No Connection Identifier" IE is present anymore 770 00905 0120 VHBE Ed. 02 8 Q.2931 " 8.6.3 An Endpoint Reference" IE is always present Additional Traffic Parameters In Ref.[48.], the ATM Traffic Descriptor" IE is extended to include a number of additional traffic parameters. SCR The SCR parameters define a kind of average cell rate, to be maintained in a variable bitrate connection. " " Backward SCR (0) " Forward SCR (0 + 1) " MBS Forward SCR (0) Backward SCR (0 + 1) The MBS parameters define the number of cells, that is maximally allowed, at the PCR. " " Backward MBS (0) " Forward MBS (0 + 1) " Tagging Options Forward MBS (0) Backward MBS (0 + 1) The Tagging Option parameters define what the network should do with non-conforming high-priority cells. Tagging means changing the priority bit from high to low. " " MCR Forward Tagging Option Backward Tagging Option In Ref.[50.], the ATM Traffic Descriptor" IE is extended to include : The MCR parameters indicate minimum cell rate requested by the user. In ABR a user will adapt his traffic to the feedback received from the network, while still requesting a guarantied minimum rate. " " ABR Setup Parameters Forward MCR (0 + 1) Backward MCR (0 + 1) In Ref.[50.], a new IE ATM Setup Parameters" is defined. This IE contains a number of parameters to be agreed upon for an ABR connection. This initial bitrate indicates the initial cell rate for the connection. " 770 00905 0120 VHBE Ed. 02 Forward ABR initial cell rate (0 + 1) 207 / 297 8 Q.2931 " Backward ABR initial cell rate (0 + 1) The transient buffer exposure defines the number of cells which can be supported at startup before the ABR control loop is established.. " Forward ABR transient buffer exposure " Backward ABR transient buffer exposure The RM round-trip time accumulates the sum of all the fixed propagation delays in the round-trip path from the source to the destination and back. " Cumulative RM fixed round-trip time The increase/decrease factors control the rate at which the user cell transmission rates increase/decrease. " " Forward rate decrease factor " 8.6.4 Backward rate increase factor " Note Forward rate increase factor Backward rate decrease factor We shall not go into detail with respect to the additional parameters for ABT and CDVT. Look-ahead Capability At the destination interface, the network can invoke a look-ahead to check whether the addressed entities are " compatible or incompatible " busy or free For this purpose, the network can send a look-ahead invoke to the called party in a FACILITY message. The addressed entity shall return an appropriate result, which can be : " compatibleAndFree" " compatibleAndBusy" " incompatible" An example of a look-ahead, with a successful result, is shown in figure 119. Since the result is successful, the network will continue the call setup as usual. 208 / 297 770 00905 0120 VHBE Ed. 02 8 Q.2931 Network User FACILITY (Look-ahead invoke) FACILITY (Look-ahead result compatibleAndFree") SETUP ALERTING Figure 119 8.6.5 Look-ahead : Positive Answer Negotiation of Traffic Characteristics during Call Setup These procedures specify the signalling protocol for negotiation of characteristics for point-to-point connections and for the first party of point-to-multipoint connections. The negotiation capabilities are only applicable during the establishment phase. In particular, the following capabilities are specified : " negotiation of a set of connection characteristics using an Alternative Traffic Descriptor. In this case, the parameters of the IE are handled as a single indivisible set. Either all the alternative traffic parameters are chosen or none at all. " negotiation of individual traffic parameters using a Minimum Traffic Descriptor. This IE allows allows the specification of a range of values for parameters which are then handled independently for the selection of their respective values. Both methods allow negotiation of any relevant traffic parameter (PCR, SCR, MBS, depending on the ATC actually used for the connection). SETUP 770 00905 0120 VHBE Ed. 02 To allow negotiation, the existing Q.2931 SETUP message is expanded with 2 optional IEs : an Alternative Traffic Descriptor" IE and a Minimum Acceptable ATM Traffic Descriptor" IE. Only one of these may be included in the SETUP message, not both, in other words, one of the above described methods has to be selected. 209 / 297 8 Q.2931 The format of these new IEs is exactly the same as the contents of the ATM Traffic Descriptor", possibly expanded with additional traffic parameters, as explained in section 8.6.3. The following applies : " " Negotiation Procedures for the Alternative Traffic Descriptor A traffic parameter is allowed in the Minimum Acceptable ATM Traffic Descriptor", only if the corresponding traffic parameter is present in the ATM Traffic Descriptor". " CONNECT The alternative bandwidth requirements must be reduced compared to those originally requested. Of course, the idea is that the alternative bandwidth requirements are more easily to fulfil than the original ones. In this way the Alternative Traffic Descriptor" IE offers a "second choice" for the traffic parameters. However, if it is determined that the alternative bandwidth requirements are "greater" than those in the ATM Traffic Descriptor", the "Alternative Traffic Descriptor" may be treated as an IE with content error. The last limitation is not imposed for the Alternative Traffic Descriptor". It can have any combination of traffic parameters that is allowed for the specified ATC. The Q.2931 CONNECT message is extended to include the ATM Traffic Descriptor" IE. This IE is used to return the accepted connection characteristics (i.e., accepted by the network and the called party) back to the calling user. However, if this is not the case, the network shall assume that the characteristics, specified in the ATM Traffic Descriptor" of his original SETUP message shall apply. The following rules are followed for negotiation by means of the Alternative ATM Traffic Descriptor". When the Alternative ATM Traffic Descriptor" is included in the SETUP and the network is able to provide the traffic , parameters specified in both the ATM Traffic Descriptor"and the Alternative ATM Traffic Descriptor", the network shall progress the call with both IEs unchanged. " 210 / 297 " If the network is able to provide the parameters of the ATM Traffic Descriptor", but not the Alternative ATM Traffic Descriptor", the last one will not be transmitted further. Of course, any further transmission of the Alternative Traffic Descriptor" IE becomes useless, since it can not be provided anyway. 770 00905 0120 VHBE Ed. 02 8 Q.2931 " If the network is able to provide the parameters of the Alternative ATM Traffic Descriptor", but not those of the original ATM Traffic Descriptor", the network shall progress the setup request by using the alternative parameters, replacing the parameters of the ATM Traffic Descriptor". From this moment on, only one option for traffic parameters remains available for the farther end of the network and for the called party. " If the network is not able to provide the parameters of the ATM Traffic Descriptor", nor the Alternative ATM Traffic Descriptor", the network shall reject the request. These rules are summarized in table 19. Table 19 Actions by the Network for Call Negotiating using the Alternative Traffic Descriptor The Network is able to provide the traffic parameters specified in the th ATM Traffic Descriptor IE yes no yes progress the call progress the call, copy the contents of the Alternative Traffic Descriptor IE to the ATM Traffic Descriptor IE no progress the call, omit the Al ternative Traffic Descriptor IE release the call Alternative ATM Traf fic Descriptor IE These same rules are followed by the called party. Negotiation Procedures for the Minimum Acceptable Traffic Descriptor 770 00905 0120 VHBE Ed. 02 The following rules are followed for negotiation by means of the Minimum Acceptable ATM Traffic Descriptor". " When the Minimum Acceptable ATM Traffic Descriptor" is included in the SETUP and the network is able to provide the , traffic parameters specified in both the ATM Traffic Descriptor"and the Minimum Acceptable ATM Traffic Descriptor", the network shall progress the call with both IEs. 211 / 297 8 Q.2931 " If the network is not able to provide some of the traffic parameters of the ATM Traffic Descriptor", but able to provide at least their corresponding values in the Minimum Acceptable ATM Traffic Descriptor", the network shall progress the setup request after adjusting the traffic parameter values indication in the ATM Traffic Descriptor" to the values that will be supported. Naturally, these adjusted parameter values will not be smaller than the corresponding minimum acceptable values. If some of the parameters in the Minimum Acceptable ATM Traffic Descriptor"are still less than the corresponding parameters in the modified ATM Traffic Descriptor", then the call shall be progressed with the unmodified Minimum Acceptable ATM Traffic Descriptor" containing all such parameters, in addition to the modified ATM Traffic Descriptor". Otherwise, i.e. if the complete ATM Traffic Descriptor" has been modified to all the values specified in the Minimum Acceptable ATM Traffic Descriptor", the last one can be omitted, since it will have lost its use for the farther end of the network and the called user. These same rules are followed by the called party. 8.6.6 Modification of Traffic Characteristics during the Active Phase These procedures describe the modification of any or all of the traffic parameters which were specified in the ATM Traffic Descriptor" IE at call setup. Point-to-point The procedures are applicable to point-to-point connection only. Modification procedures for point-to-multipoint connection are not yet described. Modification can only be requested by the connection owner. There is only one connection owner per connection. During the modification procedure, the initiating user must be prepared to receive the greater of the existing traffic parameters and of the requested modified parameters. On the other hand, the initiating user may only transmit based on the lesser of the existing traffic parameters and of the requested modified parameters. Additional Messages 212 / 297 In order to support the modification connections, the following additional messages are defined : 770 00905 0120 VHBE Ed. 02 8 Q.2931 " MODIFY REQUEST This message is sent from the user to the network and from the network to the user to request the modification of a single connection. It contains a modified ATM Traffic Descriptor". The modification request may be for all or a subset of the parameters specified during call setup. Thus, a traffic parameter can be modified only if the parameter was specified at call establishment. " MODIFY ACKNOWLEDGE This message is sent by the network or the user to indicate that the modify request is accepted. The addressed user may request confirmation that the connection has actually been modified (in the direction of addressed user to modification initiating user). In order to request this confirmation, he shall use he Report Type IE in the MODIFY ACKNOWLEDGE " MODIFY REJECT This message is sent by the network or the user to indicate that the modify connection request is rejected. " CONNECTION AVAILABLE This message is sent in response to the MODIFY ACKNOWLEDGE message that contains a flag, set by the addressed user requesting that a CONNECTION AVAILABLE message be sent. This message confirms that the network has performed modification in the addressed user to calling direction of transmission. The scenario of a successful connection modification is shown in figure 120. 770 00905 0120 VHBE Ed. 02 213 / 297 8 Q.2931 Network Addressed User Network Initiating User MODIFY REQUEST MODIFY REQUEST MODIFY ACKNOWLEDGE MODIFY ACKNOWLEDGE CONNECTION AVAILABLE CONNECTION AVAILABLE Figure 120 Successful Connection Modification The scenarios of unsuccessful connection modifications are shown in figures 121 and 122. The failure of modification can be due to the addressed user (figure 121) or the network (figure 122). Network Addressed User Network Initiating User MODIFY REQUEST MODIFY REQUEST MODIFY REJECT MODIFY REJECT Figure 121 Addressed User Modification Refused by the Addressed User Network Network Initiatin g User MODIFY REQUEST MODIFY REJECT Figure 122 214 / 297 Modification Refused by the Network 770 00905 0120 VHBE Ed. 02 8 Q.2931 8.6.7 Call Priority The following capabilities are provided : " " The originating side of the network shall provide for screening of the priority to ensure that the user does not exceed the highest assigned priority level. " The network shall transport the priority information on the NNI. " Use The originating user may provide priority information for each call setup request. If not provided, the network shall include the priority information for the lowest priority. The destination UNI shall deliver the priority information to the destination user. The priority information may be used by the network during call establishment. It may also be used by the called user to efficiently manage the incoming calls. The called user may also use this information for actions such as clearing an existing lower priority call and answering a higher priority call. In order to convey this information. the calling user shall include the Priority" IE in the SETUP message. This IE can convey 5 levels of priority, ranging from level 1 (highest priority) to level 5 (lowest priority). 770 00905 0120 VHBE Ed. 02 215 / 297 8 Q.2931 216 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP 9 B-ISUP This chapter describes the B-ISDN User Part, the signalling support required in an B-ISDN environment. Capability Set 1 (CS1) of B-ISUP is described in Refs [42., 43., 44. and 45.]. Its functionality, the message coding, and a subset of its messages and parameters are described in this chapter. Further, also the extensions for CS2 are presented. 770 00905 0120 VHBE Ed. 02 217 / 297 9 B-ISUP 9.1 B-ISUP Capability Set 1 Services The B-ISUP functionality is gradually augmented in several defined Capability Sets (CS). The first Capability Set is CS-1. Its functions are described in Ref.[18.]. They are the following : " Call establishment and release of a point-to-point connection. The connection may provide uni-directional or bidirectional, asymmetric communication. " Transfer of access transport information " Support of some Supplementarty Services (SS) (not described in this document) " Interworking with N-ISDN services Additionally CS2 functionality is described in section 9.7. 9.2 General Coding Principles of B-ISUP Messages For ATM and STM B-ISUP messages are carried on the ATM signalling link by means of SAAL service data units, whose format has been described earlier. However, as a national option (to reuse narrowband links) B-ISUP messages can be carried on the STM signalling link by means of MTP-2 Signal Units. SI B-ISUP Message Recall the SI for B-ISUP is coded as "1001". The MTP-3b information field (for BB), or the Information Field of MTP-2 messages (for NB), containing a B-ISUP message, consists of an integral number of octets and encompasses the following parts. " " The Message Length consists of a 2 octet field and is mandatory for all messages. It indicates the number of octets included in the B-ISUP message content and the message compatibility information fields. " 218 / 297 The Message Type Code is a mandatory 8 bit field used to uniquely identify a certain B-ISUP message. The Message Compatibility Information. This is a one octet field and is also mandatory. It defines the behavior of an exchange if the message is not understood. 770 00905 0120 VHBE Ed. 02 9 B-ISUP " General Layout This Message Content of each message contains a number of parameters. This general layout of a B-ISUP message, is shown in figure 123. Routing Label SIO 32 bits B-ISUP Message 8 bits First bit transmitted Message Type Code 1 byte Message Length 2 bytes Message Compatibility Info 1 bytes Message Content Figure 123 9.2.1 B-ISUP Message Layout Message Type Code The Message Type Code consists of a 1 octet field and is mandatory for all messages. The message type code uniquely defines the function and format of each B-ISUP message. The following rules are followed : " " 9.2.2 Existing N-ISUP message codes, used in B-ISUP have the , same codes in B-ISUP . B-ISUP message codes, not used in N-ISUP should be , marked  reserved" in N-ISUP . Message Length The message length consists of a fixed 2 octet field and is mandatory for all messages. The message length indicates the number of octets included in the message compatibility information and the message content. (It does not include the 770 00905 0120 VHBE Ed. 02 219 / 297 9 B-ISUP routing label octets, the message type code or the message length indicator octets themselves). The code expresses in pure binary representation the number of octets. Bit 8 of octet 1 is the most significant bit and bit 1 of octet 2 is the least significant. In principal 16 bits, allow a length of 216 = 65 536 octets. However, the actual maximum message length is restricted by the lower layers. Recall the maximum size of user data supported by MTP-3b for signalling links is 4091 octets. (4096 because of the SSCF limitation minus 5 octets, reserved for the SIO, DPC, OPC and SLS). 9.2.3 Message Compatibility Information Version compatibility It may happen that an exchange receives unrecognized signalling information, i.e., messages, parameter types or values. This can typically be caused by the upgrading of the signalling system used by other exchanges in the network. The message compatibility information defines the behavior of a switch if the message is not understood. Its format is shown in figure 124. 8 Ext. 7 5 BB/NB Interworking Indicator Figure 124 Type A and Type B Exchanges 6 Pass On not Possible Ind. 4 3 2 Release Discard Send Message Notification Call Ind. Ind. Ind. 1 Transit at Intermed . Exch. Ind Message Compatibility Information Different exchange types are defined, which handle the compatibility information differently. There are 2 types of exchanges : type A and type B exchanges. Type A Originating Exchange Destination Exchange Interworking Exchange Incoming or Outgoing International Exchange Type B National or International Transit Exchanges Obviously, the classification of these exchange types is determined on a per call basis, i.e. an exchange may be of type A for one call and of type B for another call. 220 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP Instruction Indicators As shown in figure 124, the compatibility information consists out of a set of instruction indicators", which are a set of booleans. Depending on the role of the exchange in the connection, i.e., type A or B, only a subset of these indicators is examined, some being ignored. The following rules apply : " Only a Type B exchange examines the Transit at Intermediate Exchange Indicator". If it is set to Transit Interpretation", the other indicators are ignored, otherwise they are interpreted. " A Type A exchange always ignores the Transit at Intermediate Exchange Indicator" " At a type A exchange, which is acting as a BB/NB interworking exchange, the Broadband/Narrowband Interworking indicator" is examined, in stead of the other indicators. " The handling of the Release Call Indicator", the Send Notification Indicator" and the Discard Message Indicator" is shown in table 20. Table 20 Handling of the Instruction Indicators for Unrecognized Messages Release Call Ind Send Notif. Ind. Discard Mess. Ind. Required Action 0 ? 0 Pass On Message 0 0 1 Discard Message 0 1 1 Discard Message and send Notification 1 ? ? Release the Call " 9.2.4 At a type A exchange, where Pass On" has been specified (see table 20), an this is not possible, the Pass On not Possible Indicator" will be examined to determine whether the call should be released, or whether the message should be discarded. Message Content General Layout 770 00905 0120 VHBE Ed. 02 The message content of each message contains a number of parameters. Each parameter has a name which is coded as a single octet. The length of the parameter may be fixed or variable, and a length indicator of fixed length for each parameter is included. Every parameter contains parameter compatibility information. 221 / 297 9 B-ISUP The general layout of a B-ISUP parameter, is shown in figure 125. Parameter Name 1 byte Length Indicator 2 bytes Parameter Compatibility Info 2 bytes Parameter Content Figure 125 Parameter Name B-ISUP Parameter Layout Each parameter has a unique name, which is encoded as a single octet. The following rules are followed : " " Parameter Compatibility Information 222 / 297 B-ISUP parameter name codes, not used in N-ISUP should , be marked  reserved" in N-ISUP . " Parameter Length Existing N-ISUP parameter name codes, used in B-ISUP , have the same codes in B-ISUP . The formats of the parameters, which originate from the access protocol (DSS2), are the same as specified in Ref.[46.]. The coding of their contents is the same, though their name codes can be different. The format of the parameter length indicator is identical to the format of the message length indicator. The parameter compatibility information defines the behavior of a switch if a parameter is not understood. Its format is shown in figure 126. 770 00905 0120 VHBE Ed. 02 9 B-ISUP 8 7 5 Discard Pass On not Possible Parameter Indicator Ind. Ext. 4 3 2 Send Discard Notific. Message Ind. Ind. Figure 126 1 Release Transit at Call Intermed Ind. . Exch. Ind ÉÉÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉÉÉ Ext. 6 BB/NB Interworking Indicator Parameter Compatibility Information The rules for the handling of unrecognized parameters, resemble a lot to the rules for handling unrecognized messages, described in section 9.2.3. Only now, it is also possible for the instruction to require that either only the unrecognized parameter or the whole message is discarded. This provides for the case where the exchange determines that it is not acceptable for the message to continue being processed without this parameter. The handling of the Release Call Indicator", the Send Notification Indicator", the Discard Message Indicator" and the Discard Parameter Indicator"is shown in table 21. Table 21 Handling of the Instruction Indicators for Unrecognized Parameters Release Call Ind Discard Mess Ind. Discard Pa rameter Ind. Required Action 0 0 0 0 Pass On Parameter 0 0 0 1 Discard Parameter 0 0 1 ? Discard Message 0 1 0 0 Pass On Parameter 0 1 0 1 Pass On Parameter and send Notification 0 1 1 ? Discard Message and send Notification 1 770 00905 0120 VHBE Ed. 02 Send Notif. Ind. ? ? ? Release the Call 223 / 297 9 B-ISUP 9.3 Assignment Procedure of VPCI/VCI and Bandwidth Assigning & Non-Assigning Exchanges One side selection of bandwidth and VPCI/VCI values, which allows one exchange to be assigning exchange for both outgoing and incoming calls, is adopted. The advantage of this method is that dual seizure is prevented completely. For each route between 2 exchanges, the following is necessary : " the VPCIs to be used must be assigned unambiguously and identically at both ends of each VPC. " for every VPCI, it must be defined which exchange controls this VPCI, i.e., which is responsible for assigning bandwidth and VPCI/VCI for this VPC. The following default mechanism is defined for determining this designation. " Each exchange will be the assigning exchange for one half of the VPCI values. D The exchange with the highest Signalling Point Code is the assigning exchange for all even numbered VPCI values. D The exchange with the lowest Signalling Point Code is the assigning exchange for all odd numbered VPCI values. If an exchange has to setup a connection, it shall first use a VPCI which it is controlling itself. Thus, a Connection Element Identifier" parameter is put into the setup request. Only, if there is no available bandwidth or VCIs left, the exchange will issue a setup request without the Connection Element Identifier". This can be interpreted as a request to the peer exchange to assign both a VPCI/VCI and bandwidth. This procedure is shown in figure 127. 224 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP Case 1 : Exchange A has resources IAM (VPCI (1,3,5,...) ,VCI) Point Code = 23 Point Code = 35 IAA( ) A = the assigning exchange for the odd VPCIs Case 2 : Exchange A is out of resources IAM ( ) Point Code = 23 IAA(VPCI (2,4,6,...) ,VCI) Point Code = 35 B = the assigning exchange for the even VPCIs Figure 127 No more double seizure Assignment of VPCI/VCI for assigning and non-assigning exchanges. Since it is always the assigning exchange, assigning bandwidth and VCIs, at the time of call acceptance at the assigning exchange, a dual seizure of bandwidth or VCI value can not occur. Any deviation from these assignment procedures shall be responded by a call release with cause VPCI/VCI assignment failure". 770 00905 0120 VHBE Ed. 02 225 / 297 9 B-ISUP 9.4 B-ISUP Instances and Identities B-ISUP is a functionality, situated at layer 7 of the OSI model. Therefore, OSI layer 7 methods are used by ITU-T to describe its functionality. A framework for the common development and evolution of protocol specifications, using OSI concepts is described in Ref.[17.]. It also provides guidance on techniques that should be applied to the detailed specification. OSI Application Layer The structure of the OSI Application layer (layer 7) is different from that of any other layer in the OSI model. Whereas each of the six other layers contains a set of well defined functions within a monolithic layer structure, the OSI Application layer is structured modularly to allow flexibility in function and form, to meet the communication needs of every possible application. The Application layer is the bridge between the work of the application process and the work of the OSI lower layers. Unlike the other layers in the OSI model, the Application model must provide functions that are application specific.. The form and content of the functions in the Application layer are dependent on the needs of the process using these functions. In order to provide flexibility and ease of expansion, the Application layer is defined in an open-ended way, with room for application specific functions, yet still enforcing standard methods of communication. The B-ISUP specifications follow these techniques. 9.4.1 B-ISUP Specification Model The generalized model for the B-ISUP Basic Call application process is shown in figure 128. 226 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP EXCHANGE APPLICATION PROCESS B-ISUP Nodal functions B-ISUP AE B-ISUP SAO Call Control ASE S A C F Bearer Control ASE Maintenance ASE Unrecognized Information ASE Network Interface MTP-3 Figure 128 B-ISUP Specification Model AP The term Exchange Application Process (AP) is used to describe all application functionality in an exchange. B-ISUP is a part of this. The B-ISUP nodal functions are the B-ISUP Application Process functions. AE An Application Entity (AE) is the function that an Application Process uses to communicate with its peers. As such, the B-ISUP Application Entity (AE) provides all the communication capabilities required by the B-ISUP nodal functions. An AP can use several AE types, each of which provides a specific set of communication functions for the AP . An AP may have many AE instances, performing communication functions for it. 770 00905 0120 VHBE Ed. 02 227 / 297 9 B-ISUP SAO For simplicity, a B-ISUP AE is defined as containing just one Single Association Object (SAO). An SAO is the representation of the functions that are needed to communicate over a single association to a certain peer All coordination between B-ISUP signalling associations is performed by the B-ISUP nodal functions. ASE The basic component of the AE is an Application Service Element (ASE). An ASE defines a function or set of functions to help accomplish application communication. The Single Association Control Function (SACF) represents the rules and regulations governing the use of the ASEs, that are being used for communication over a single association to a peer. Incoming & Outgoing Functionality In an intermediate exchange, the Call Control (CC) and the Bearer Connection Control (BCC) ASE both consist of 2 distinct sets of functions. " " 3 Types of SAO One set is used on the incoming side of the exchange. It supports the signalling association with the preceding exchange. The other set is used on the outgoing side of the exchange. It supports the signalling association to the next exchange. The SAO contained in the B-ISUP AE is one of the following types. " Incoming Call and Connection Control This SAO contains the following ASEs : D D Incoming BCC D Maintenance Control (MC) D " Incoming CC Unrecognized Information (UI) Outgoing Call and Connection Control This SAO contains the following ASEs : D D Outgoing BCC D Maintenance Control (MC) D " Outgoing CC Unrecognized Information (UI) Maintenance SAO This SAO contains the following ASEs : 228 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP D Maintenance Control (MC) D Unrecognized Information (UI) This is illustrated in figure 129. EXCHANGE APPLICATION PROCESS B-ISUP Nodal functions B-ISUP AEI B-ISUP AEI B-ISUP SAO B-ISUP SAO CC ASE Out CC ASE Inc Incoming Virtual Circuit S A C F BCC ASE Inc Outgoing Virtual Circuit S A C F BCC ASE Out MC ASE MC ASE UI ASE UI ASE SID = Y SID = X Network Interface MTP-3 Figure 129 B-ISUP Model at an Intermediate Exchange To handle any particular B-ISUP function, the application process creates instances of the B-ISUP AE, as required. Network Interface The Network Interface provides the interface between the B-ISUP AE and MTP-3. There is only 1 instance of the NI in an exchange. It distributes the messages, received from MTP-3 to the appropriate instance of the B-ISUP AE. 770 00905 0120 VHBE Ed. 02 229 / 297 9 B-ISUP SID Each instance of the B-ISUP AE is created for each signalling association required. It is identified within an exchange by a unique Signalling Identifier (SID). This value is allocated when the AEI is created and deallocated when the service provided by the AEI is no longer required and the AEI is deleted. The exchange application process manages the SIDs. This SID is used to label signalling messages relating to this instance. The Network Interface (NI) uses this SID to distribute messages to the correct AEI. " When a message is received by MTP-3, and if the Destination Signalling Identifier (DSID) corresponds to an existing B-ISUP AEI, the message is distributed. " If the message does not contain a DSID, but it does contain an Originating Signalling Identifier (OSID), a new instance of B-ISUP is created. This new instance is allocated a new SID value. The type of the SAO is determined by examination of the received message type. If B-ISUP is used as the signalling system for a new call outgoing from a certain exchange (the exchange is the originator of the signalling association), then the exchange application process creates a new instance of B-ISUP . The Origination Signalling ID A (OSIDA) is assigned by exchange A, when it sends the first message (e.g. the IAM). OSIDA identifies the signalling association at exchange A. OSID B is assigned by exchange B when it receives the IAM . It identifies the signalling association at exchange B. The reply, (e.g., the IAM Acknowledge) contains OSID B and DSIDA to allow a mapping between the sending and the receiving direction. Thus : OSID A = DSID A OSID B = DSID B All subsequent B-ISUP messages to B contain the DSID B, all B-ISUP messages to A contain the DSID A. When the call is released, the B-ISUP instance and all associated information is deleted. Note 230 / 297 Signalling Identifiers are pure local references. They can be very well compared to the source and destination local references, used in the SCCP connection-oriented mode. 770 00905 0120 VHBE Ed. 02 9 B-ISUP The use of the OSID and DSIDs is illustrated in the scenario of figure 130. EXCHANGE A Assign OSIDA EXCHANGE B IAM (OSIDA) Assign OSIDB IAM Ack (DSIDA,OSIDB) Address Complete Message (DSIDA) Answer Message (DSIDA) Release Message (DSIDB) Release OSIDB Release Complete Message (DSIDA) Release OSIDA OSIDA : Origination SID assigned by exchange A OSIDB : Origination SID assigned by exchange B DSIDA : Destination SID A = OSIDA DSIDB : Destination SID B = OSIDB Figure 130 NOTICE Call Scenario with the use of SIDs This B-ISUP method to identify peer B-ISUP instance uses OSIDs and DSIDs. This method is completely different from the N-ISUP which simply , sends the CIC code as a channel identification, along with each message to identify the peer N-ISUP . 770 00905 0120 VHBE Ed. 02 231 / 297 9 B-ISUP 9.5 B-ISUP Capability Set 1 Messages. For CS1, 28 message types have been defined by ITU-T in Ref.[43.]. We restrict ourselves to describing the most important ones. 9.5.1 Call Setup Messages The B-ISUP messages used in a call setup, together with their function and the corresponding message type codes are shown in table 7. Table 22 B-ISUP Message Types, functions and coding for a Call Setup. Message Type Function Message Type Code Call Setup Messages Address Complete (ACM) Sent in the backward direction indicating that all the address signals required for routing the call to the called party have been re ceived. 00000110 Answer (ANM) Sent in the backward direction indicating that the call has been answered. 00001001 Charging of the call to the calling party and measurement of the call duration, can start. Call Progress (CPG) Sent in either direction, during the setup or active phase of the call, indicating that a sig nificant event, which should be relayed to the originating or terminating access, has oc curred. 00101100 Initial Address (IAM) Sent in the forward direction to initiate sei zure of an outgoing virtual channel and to transmit number and other information relat ing to the routing and handling of a call. 00000001 232 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP Message Type Function Message Type Code IAM Acknowledge ment (IAA) Sent in the backward direction in response to an IAM message. The IAA indicates that the IAM has been accepted and the requested bandwidth is available. 00001010 IAM Reject (IAR) Sent in the backward direction in response to an IAM message, indicating call refusal due to resource availability. 00001011 Subsequent Address (SAM) Sent in the forward direction, following an IAM, to convey additional called party num ber information. 00000010 Forward Transfer (FOT) Sent in the forward direction on semi-auto matic calls when the outgoing international exchange operator wants the help of an op erator at the incoming international ex change. 00001000 If the call is automatically set up, the mes sage will normally serve to bring an assis tance operator into the circuit. Network Resource Manage Sent in order to modify network resources associated with a certain call. The message ment (NRM) 00110010 is sent along an established path in any direction in any phase of the call. These messages will now be discussed in more detail. 770 00905 0120 VHBE Ed. 02 233 / 297 9 B-ISUP Initial Address Virtual Channel Selection When an originating local exchange has received the complete selection information from the calling party, and has determined that the call is to be routed to another exchange, selection of a suitable virtual channel takes place. For that purpose, appropriate routing information is either stored at the originating exchange or at a remote database to which a request may be made. The selection of the route will depend on " " the Broadband Bearer Capability", which specifies a requested broadband connection oriented bearer service, to be provided by the network " Propagation Delay Determination the Called party number", which specifies the destination and the required ATM Cell rate", which indicates the number of cells per second that are required for the call. Additionally, if the Maximum End-to-end Transit Delay" parameter is present, this is used, together with the Propagation Delay Counter". " the Maximum End-to-end Transit Delay" indicates the maximum delay requested by the calling user for the requested VPC " the Propagation Delay Counter" indicates the propagation delay of a connection. It is accumulated whilst the parameter is transferred through the network. It is represented by a counter, counting in integer multiples of 1 msec. For that reason, a propagation delay value must be defined for each VP going out of every exchange, for which the exchange is the assigning exchange. Mandatory parameters in the IAM The information used to determine the routing of the call by the originating exchange will be included in the IAM, to enable correct routing at the intermediate exchanges. Each IAM will have the following mandatory parameters : "ATM cell rate", "broadband bearer capability", "called party number", calling party's category" and propagation delay counter". End-to-end Information A number of parameters can be transported from the access unaltered to the destination. These parameters are : " " 234 / 297 AAL Parameters" Broadband Bearer Capability" 770 00905 0120 VHBE Ed. 02 9 B-ISUP " Broadband Low Layer Information" " Broadband High Layer Information" " Narrow-band High Layer Compatibility" " Narrow-band Low Layer Compatibility" " OAM Traffic Descriptor" " Progress Indicator" The IAM conveys implicitly the meaning that the indicated ATM connection elements (VPCI, bandwidth) are reserved. Destination exchange 770 00905 0120 VHBE Ed. 02 Upon receipt of the IAM, the destination exchange will analyse the "called party number" to determine to which party the call should be connected. It will also check the called party's line condition (busy, free) and perform various checks to verify whether or not the connection is allowed. These checks will include correspondence of compatibility checks.. 235 / 297 9 B-ISUP Initial Address Acknowledgement After receiving an IAM, an assigning exchange shall perform the assignment procedures for VPCI/VCI and bandwidth. If this is successful, the IAA shall be issued immediately in the backward direction, carrying the Connection Element Identifier". On the other hand, a non-assigning exchange shall issue the IAA also, but without the Connection Element Identifier". NOTICE The IAA and the IAR messages are new in B-ISUP They do not . exist in ISUP . The reason to introduce these messages is just the fact that possibly the VPCI/VCI identifier has to be communicated backwards (if the originating exchange is the non-assigning one). On the contrary, in ISUP it is always the originating exchange, , performing the reservation of a circuit, causing the occasional problem of double seizure. Completion of transmission path For the originating local exchange, the transmission path will be through connected in the backward direction, immediately after the reception of the IAA. On the other hand, intermediate exchanges will complete the transmission path in both directions, immediately after the reception of the IAA. Finally, the destination exchange will not through connect any direction yet. Initial Address Reject If at any time, a call can not be completed due to lack of resources at the incoming side, the exchange shall respond to the IAM by sending an IAR. This IAR shall contain the Cause" parameter which can indicate : " " No VPCI/VCI available" " 236 / 297 resource unavailable - unspecified" User Cell Rate not available" 770 00905 0120 VHBE Ed. 02 9 B-ISUP Address Complete Destination exchange An ACM will be sent from the destination exchange as soon as it has been determined that the complete called party number has been received, and to convey indications regarding the called party's status and on tones and announcements There are 2 possibilities : " " ATTENTION If no status indication has been received from the ISDN access prior to the destination exchange determining that the complete called party number has been received, the ACM will be sent by the destination exchange with the called party's status indicator" set to "no indication". This is called the "early ACM method". If the destination exchange concludes from the receipt of an indication from the ISDN access that the complete called party number has been received (= by means of the DSS2 ALERTING message), the ACM will be sent with the called party's status indicator" set to "alerting". Although in many scenario's, an ACM will follow after the DSS2 ALERTING message, there is no direct mapping from alerting, received from the access signalling system, to the ACM in the network. One should keep in mind that 2 methods exist : the "early ACM method" or the one in which the ALERTING indication from the B-subscriber is awaited before sending the ACM. Both methods are allowed and it is up to the network provider to choose one of them. Intermediate exchanges Originating exchange Upon receipt of the ACM, an intermediate exchange will send the corresponding ACM to the preceding exchange. Upon receipt of the ACM, the originating exchange will pass an alerting indication to the calling party, if the called party's line status indicates "alerting". The originating exchange also starts an Await Answer timer. If it expires, the call is released, using the cause No answer from user". 770 00905 0120 VHBE Ed. 02 237 / 297 9 B-ISUP Ringing Tone The sending of in-band ringing tone at the destination exchange depends on the type of connection. " " If the called user provides for the sending of in-band tone signals, the destination exchange will through connect the transmission path in the backward direction. " 238 / 297 For connections involving speech, 3.1 kHz audio and unrestricted digital information with tones/announcements, as indicated in the Narrowband Bearer Capability" parameter, the ringing tone is applied on the virtual connection to the calling party from the destination exchange. For other connection types, no ringing tone is applied. 770 00905 0120 VHBE Ed. 02 9 B-ISUP Call Progress Destination exchange A CPG message is sent (only after the ACM) from an exchange in the backward direction, to indicate that an event has occurred during call setup which should be relayed to the calling party. During a basic call, the destination exchange will sent the CPG, to indicate that the called party is being alerted. In that case, the CPG message will contain an "event indicator", set to "alerting". Intermediate exchanges Originating exchanges 770 00905 0120 VHBE Ed. 02 Intermediate exchanges will send the corresponding CPG to the preceding exchange. At the originating exchange, no state change occurs. An alerting indication will be sent to the calling party, if this was not yet the case. 239 / 297 9 B-ISUP Answer Message When the called party answers, the destination exchange connects through the transmission path and the ringing tone is removed (if applicable). An ANM to the preceding exchange is sent. Completion of transmission path The originating exchange and intermediate exchanges will through connect the transmission path in the forward direction after the reception of an ANM. The originating exchange stops the timer Await Answer End-to-end Information The ANM can transport information from the access to the origin in the following parameters : " AAL Parameters" " Broadband Low Layer Information" " Narrowband Bearer Capability" " Narrow-band High Layer Compatibility" " Narrow-band Low Layer Compatibility" " OAM Traffic Descriptor" " Progress Indicator" Call History Information At the destination exchange, the value of the call history" parameter is set according to the stored value of the propagation delay counter", received in the IAM. The call history" parameter is conveyed back in the ANM message. Automatic Answering The ANM message can be issued without having issued a previous ACM, e.g., in the case of an automatic answering terminal. A successful call setup is shown in figure 131. 240 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP DSS2 Cg TERM User A e.g. Lift Hook CCS #7 B-ISUP LOCAL EXCHANGE SETUP CCS #7 B-ISUP TRANSIT EXCHANGE DSS2 LOCAL EXCHANGE Cd TERM User B IAM IAA IAM e.g. Ring SETUP IAA ACM e.g. Start Ringing ALERTING ACM CPG CPG ALERTING CONNECT ANM e.g. Stop Ringing ANM e.g. Hook Off CONN. ACK. CONNECT CONN. ACK. Through connection of the transmission path in the backward direction Through connection of the transmission path in the forward direction Through connection of the transmission path in both directions Figure 131 B-ISUP Scenario for Connection Setup (En bloc) En bloc The described forwarding of addressing information is called "en bloc" sending, because all information is sent in one time, i.e. in the IAM. Overlap If not all information can be transmitted in the IAM, the remaining information will have to be transmitted in one or more supplementary messages. These supplementary messages are 770 00905 0120 VHBE Ed. 02 241 / 297 9 B-ISUP called Subsequent Address Message (SAM), their only purpose is to carry further digits. The IAM will contain only a few digits. A number of SAMs will be used to send the other digits. This method is called "overlap sending". A SAM may contain one or several digits. Efficiency can be gained by grouping together as many digits as possible. The first SAM may not be sent before the IAA has been received. If the number of digits in the called party number are not sufficient to route the call, the routing will be carried out when the intermediate exchange has received additional digits in SAMs. Any address digits received in SAMs during the circuit selection process may be included in the IAM. Any SAMs received after the IAM has been sent, are forwarded to the succeeding exchange as SAMs. Example An example of overlap sending is shown in figure 132. In this example, the local originating exchange can not send an IAM after the DSS2 SETUP because this message does not contain , enough digits to perform the routing. On the assumption that after the first DSS2 INFORMATION message, enough digits are present to route the call further, the originating local exchange will send just 1 IAM containing all the digits of both the DSS2 SETUP and INFORMATION messages. Finally, the second and the third DSS2 INFORMATION message will be translated into two SAMs. In the same way, and under the same assumptions, the transit exchange will use the digits of the IAM and the SAM to generate only 1 IAM. Finally, the terminating local exchange will use the digits of the IAM and the last SAM to generate only 1 DSS1 SETUP message. The remainder of the setup scenario is identical to figure 131, and is not shown anymore. 242 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP DSS1 Cg TERM User A e.g. Lift Hook CCS #7 ISUP LOCAL EXCHANGE CCS #7 ISUP TRANSIT EXCHANGE DSS1 LOCAL EXCHANGE Cd TERM User B SETUP INFORMATION IAM IAA INFORMATION INFORMATION SAM IAM SAM IAA SAM SETUP e.g. Ring Through connection of the transmission path in the backward direction Through connection of the transmission path in both directions Figure 132 Overlap Sending 770 00905 0120 VHBE Ed. 02 243 / 297 9 B-ISUP 9.5.2 Call Release Messages The B-ISUP messages used in a call release are shown in table 23. Table 23 B-ISUP Message Types, functions and coding for a Call Release. Message Type Function Message Type Code Call Release Messages Release (REL) Sent in either direction to indicate that the call/connection is being released due to the indicated cause, and that the resources are ready to be made available for new traffic on receipt of the RLC. 00001100 Release Complete (RLC) Sent in response to the reception of a REL, when the resources of the call/connection have been made available for new traffic . 00010000 2 steps Release Just as the DSS2 release procedures, the B-ISUP release procedures are based on a 2 message (REL, RLC) approach, where the REL message initiates release of the circuit switched connection. The same procedures are used in the network irrespective of whether they are initiated by the calling party, the called party or the network. The scenario is shown in figure 133. Reception of REL The following actions will be performed by an exchange receiving a REL message " " the bandwidth is made available again " Reception of RLC the associated VPCI/VCI is made available again a RLC is returned The following actions will be performed by an exchange receiving a RLC message " " 244 / 297 the associated VPCI/VCI is made available again the bandwidth is made available again 770 00905 0120 VHBE Ed. 02 9 B-ISUP DSS2 USER A Cg TERM LOCAL EXCHANGE CCS #7 B-ISUP TRANSIT EXCHANGE CCS #7 B-ISUP DSS2 LOCAL Cd TERM EXCHANGE RELEASE REL REL e.g. Disconnect Tone e.g. Hook On RELEASE USER B e.g. Hook On RELEASE COMPLETE RLC RLC RELEASE COMPLETE 2 STEPS RELEASE 2 STEPS RELEASE No connection of the transmission path in any direction Figure 133 B-ISUP Scenario for Call Release 770 00905 0120 VHBE Ed. 02 245 / 297 9 B-ISUP 9.5.3 Suspend and Resume Messages The B-ISUP messages used for call suspension are shown in table 24. Table 24 ISUP Message Types, functions and coding for a call suspension Message Type Function Message Type Code Resume and Suspend Messages Suspend (SUS) Sent in either direction indicating that the calling or called party has been temporarily released. 00001101 Resume (RES) Sent in either direction indicating that the calling or called party, after having been sus pended, is reconnected. 00001110 The Suspend/Resume procedures procedures are only applicable in case of interworking with a N-ISDN User part. Suspend The SUS message indicates a temporary cessation of communication without releasing the call. It can only be accepted during the conversion/data phase. N-ISDN The Terminal Portability (TP) Supplementary Service (SS) allows a N-ISDN user to move a terminal from one socket to another (by means of unplugging and reconnecting) within one given Basic Access (BA) during the active state of the call. It also allows a N-ISDN user to move a call from one terminal to another terminal within one given BA during the active phase of a call. In other words, in N-ISDN both the calling and the called party can explicitly trigger a call suspension by means of the DSS1 procedures This is called "user initiated suspension". Interworking Although a Terminal Portability SS is not yet defined for the B-ISDN, B-ISUP supports the Suspend/Resume procedures in case of interworking with a N-ISDN user. Resume A RES message indicates a request to recommence communication. A request to release the call received from the calling party will override the suspend / resume sequence. 246 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP N-ISDN A RES message can also be "user initiated" if it is explicitly triggered by an N-ISDN user. . 770 00905 0120 VHBE Ed. 02 247 / 297 9 B-ISUP 9.5.4 Consistency Check Messages The B-ISUP messages used in consistency check procedures are shown in table 25. Table 25 ISUP Message Types, functions and coding for continuity procedures. Message Type Function Message Type Code Continuity Messages Consistency Check Re quest (CCR) Message sent for maintenance purposes to the exchange at the other end of a virtual path connection to verify the consistent and correct allocation of a VPCI to a virtual path. The test will cause the remote (receiving) ex change to activate an ATM cell monitoring device for the indicated resource. 00000101 Consistency Check Request Message sent in response to a CSR, indicat ing that the ATM cell monitoring device has Ack (CCRA) 00010001 Consistency Check End (CCE) Message sent to the exchange at the other end of a virtual path connection, indicating the end of consistency check sequence and to deactivate the consistency check ATM cell monitoring devices. 00010111 Consistency Check End Ack (CCEA) Message sent in response to a CCE, indicat ing the result of the consistency check and that the consistency check monitoring device has been deactivated. 00011000 been activated for the indicated resource. Use The VPCI consistency check is provided to verify the consistent and correct allocation of a logical VPCI to a VP on an interface in both connected exchanges. The check is performed to guarantee that a user plane information flow is possible between the two adjacent exchanges using the bilaterally agreed logical VPCI. Loopback Cells This is done using the loopback capability", described in Ref.[11.], that operates on the VP level. A segment loopback cell is identified by a ATM header VPI/VCI = VPI/3. The payload of the cell contains the encoding OAM Type = Fault Management" and Function Type = Loopback". Further it contains an identification of the point where the loopback must occur, together with an identification of the source which originated the loopback cell. 248 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP Consistency Check The consistency of the VPCI is checked at the far end by monitoring the receipt of a user plane test flow in the VP and the loopback cells are sent back. " The result of the loopback test is available at the initiating node. It determines whether the VP is available in both directions. " The result of the monitoring function (receipt of loopback cells at the VP level) is available at the adjacent node and is sent back to the initiating exchange. It determines whether the VP is available in the forward direction. The VP to be tested must be blocked when the consistency check procedure is initiated. This is demonstrated in figure 134. CCR CCRA Point Code A CCE Point Code B CCEA (result) Monitoring Monitoring Loopback Cell Insertion Figure 134 VPCI/VCI Consistency Check The procedure can be initiated automatically or manually. The end of the consistency check can only be initiated by the same exchange which initiated the procedure. 770 00905 0120 VHBE Ed. 02 249 / 297 9 B-ISUP 9.5.5 Confusion Message The B-ISUP messages used in case of confusion are shown in table 26. If messages are received without compatibility information, and are not recognized, they are discarded and the CFN message is sent. Table 26 ISUP Message Types, functions and coding in case of confusion. Message Type Function Message Type Code Confusion Message Confusion (CFN) 250 / 297 Sent in response to any message (other than a CFN) if the exchange does not recognize the message or a part of it. 00101111 770 00905 0120 VHBE Ed. 02 9 B-ISUP 9.5.6 Facility Messages The B-ISUP message used for transferring user-to-user information is shown in table 27. Table 27 ISUP Message Types, functions and coding for call facilities. Message Type Function Message Type Code Facility Messages User-to-user Informa tion (USR) 770 00905 0120 VHBE Ed. 02 To be used for the transport of user-to-user signalling, independent of call control mes sages. 00101101 251 / 297 9 B-ISUP 9.5.7 Maintenance Control Messages The B-ISUP messages used for maintenance tasks are shown in tables 28 and 29. Blocking and Unblocking Table 28 B-ISUP Message Types, functions and coding for (un)blocking procedures. Message Type Function Message Type Code (Un)blocking Messages Blocking (BLO) Sent only for maintenance purposes to the exchange at the other end of a virtual path connection, to cause an engaged condition of that resource for subsequent calls outgo ing from that exchange. 00010011 An exchange receiving the BLO message must still be capable of accepting incoming calls on the concerned resource, unless it has also sent a BLO message for that resource. Blocking Ack (BLA) Sent in response to a BLO message, indicat ing that the resource has been blocked. 00010101 Unblocking (UBL) Sent to the exchange at the other end of a virtual path connection to cancel, in that ex change, the engaged condition of the re source caused by a previously sent BLO. 00010100 Unblocking Ack (UBA) Sent in response to an UBL message indicat ing that the resource has been unblocked. 00010110 Use The VP blocking procedure is provided to prevent a VP from being selected for carrying new non-test call/connections. This procedure can be initiated automatically, e.g., under fault conditions, or manually, to permit testing or other exchange management functions, e.g. to perform the VPCI consistency check procedure. Blocking can be initiated by the exchange at either end of a VP At . both ends the VP is put into a blocked state and the bandwidth becomes unavailable. A blocked VP can not be selected for new non-test traffic by either exchange, however, test call/connections can be completed in either direction independent of the blocking state. Test call/connections must not return a VP to service. 252 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP Valid acknowledgements Unblocking An acknowledgement is always required for each BLO and UBL, using the BLA and UBA respectively. The acknowledgement is not sent until the appropriate action has been taken. Unblocking can only be initiated by the same exchange which initiated the blocking procedures sending an UBL or Reset request. At either end, the blocked state is removed and the bandwidth becomes available again. Reset Table 29 B-ISUP Message Types, functions and coding for reset procedures. Message Type Function Message Type Code Reset Messages Reset (RSM) Sent in response to the reception of a REL, when the resources of the call/connection have been made available for new traffic . 00010010 Reset Acknowledge ment (RAM) Sent in response to a RSM indicating that the resources have been released . 00001111 Use The reset procedure is used to return signalling identifiers and connection elements (VPs and VCs) to the idle condition. The procedure is invoked under abnormal conditions; when the current status of the SIDs or the Connection Element Identifiers" are unknown or unambiguous. For example, a switching system that has suffered memory mutilation will not know the status of the SIDs and VCs, e.g. idle, busy,... The identifiers and VCs and any associated bandwidth between the 2 adjacent nodes should therefore be reset to the idle condition. The resources are therefore made available for new traffic. In order to indicate what resource is to be reset, the RSM contains a Resource Identifier" parameter. This can indicate one of the following : " " remote SID " VPCI value " 770 00905 0120 VHBE Ed. 02 local SID VPCI/VCI value 253 / 297 9 B-ISUP The indicated resource, the bandwidth (if the exchange is the controlling exchange) and all associated identifiers on the concerned link will be made available again for new traffic. Any interconnected VP/VC and all associated resources will be released by an appropriate method (e.g., Release). User Part Availability Procedure Table 30 B-ISUP Message Types, functions and coding for user part availability procedures. Message Type Function Message Type Code (Un)blocking Messages User Part Test (UPT) Sent in either direction to test the status of a User Part, marked as unavailable for a Sig nalling Point. 00110100 User Part Available (UPA) Sent in either direction as a response to a UPT, to indicate that the User Part is avail able. 00110101 254 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP 9.6 Important B-ISUP Capability Set 1 Parameters 57 parameters have been defined by ITU-T in Ref.[43.]. In this document, we restrict ourselves to the most important ones. The messages in which the parameters are mandatory will always be put in bold. 9.6.1 Parameters used in all B-ISUP Messages The following parameters are used in (almost) all B-ISUP messages. Table 31 Parameters Names and Codes, used in all B-ISUP Messages. Parameter Type Meaning Mes sages Parameter Type Code Destination Signalling Identifier (DSID) The DSID identifies the call control or maintenance association at the receiv ing end. The first OSID received is re flected as the DSI value All" 00000011 Origination Signalling Identifier (OSID) The OSID is assigned by a node send ing a call control or maintenance mes sage, and it is used to identify the sig nalling association at that end. All" 00000010 We shall now examine these parameters in more detail. In the graphical representations, neither the octet containing the parameter name, nor the octet containing the parameter length, nor the compatibility information will be shown. The presence of these octets will be according to chapter 9.2.4. Destination Signalling Identifier The format of the "Destination Signalling Identifier" parameter is shown in figure 135. 770 00905 0120 VHBE Ed. 02 255 / 297 9 B-ISUP 8 7 6 5 4 3 2 1 Control Id Figure 135 Control ID DSID The Control Id" is a bit string representing in pure binary representation the identification number allocated to the signalling association. Origination Signalling Identifier The encoding of this parameter is identical to the encoding of the DSID. 256 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP 9.6.2 Parameters, mainly used in Call Setup Messages Table 32 B-ISUP Parameters names and codes, mainly used in Call Setup. Parameter Type Meaning Mes sages Parameter Type Code AAL Parameters Information sent in the forward or backward direction to indicate the re quested/proposed ATM Adaptation Lay er attribute values (end-to-end signifi cance) for the ATM Adaptation Layer elements of procedures to be used for the call. The information is of signifi cance to both users and local ex changes. It is transferred transparently between local exchanges. ANM, IAM, REL, USR 01000111 ATM Cell Rate Information classified by the cell rate identifier indicating the number of cells per second that are required for the call. The cell rate value is unchanged as it traverses the B-ISDN network. IAM 00001000 Broadband Bearer Ca pability Information sent in the forward direc tion to indicate the requested broad band connection oriented bearer ser vice (F.811) to be provided by the net work. IAM 01010000 Broadband High Layer Information Information sent in the forward direc tion which should be used by the re mote user for compatibility checking. IAM 01000110 Broadband Low Layer Information Information sent in the forward or backward direction to provide a means which should be used for compatibility checking by an addressed entity (e.g. a remote user or an interworking unit or a high layer function network node ad dressed by the calling user). ANM, IAM 01001111 Call History Information Information sent in the backward direc ANM 00101101 Called Party Number IAM 00000100 ACM, CPG 00010111 IAM 00001010 tion to indicate the accumulated propa gation delay of a connection. Information to identify the called party. Called Party's Indicators Information sent in the backward direc tion consisting of the called party's sta tus indicator and the called party's category indicator. Calling party number 770 00905 0120 VHBE Ed. 02 Information sent in the forward direc tion to identify the calling party. 257 / 297 9 B-ISUP Parameter Type Meaning Calling Party's Category Information sent in the forward direc tion, indicating the category of the call ing party, and in case of semi-auto matic calls, the service language to be spoken by the incoming, delay and as sistance operators. Connection Element Identifier Information sent to identify the ATM virtual connection. It includes the VPCI and the VCI. Maximum End-to-end Information sent in the forward direc tion indicating the maximum delay re Transit Delay Mes sages Parameter Type Code IAM 00001001 IAM, IAA 00000110 IAM 00000111 quested by the calling user for the re quested virtual path connection. OAM Traffic Descriptor Information classified by the cell rate identifier indicating the number of cells per second required for OAM traffic on the virtual connection. ANM, IAM 01001000 Propagation Delay Counter Information sent in the direction to indi cate the propagation delay of a con nection. This information is accumu lated whilst the parameter is transferred through the network. The propagation delay information is represented by a counter, counting in integer multiples of 1 msec. IAM 00110001 Subsequent Number Information sent in the forward direc tion in case of call setup with overlap address signalling, conveying one or more address signals of the called party number. SAM 00000101 These parameters will now be discussed in more detail. In the coding representations, the parameter name, nor the parameter length indicator, nor the compatibility information are shown. 258 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP AAL Parameters This parameter has already been described in section 8.4.1. ATM Cell Rate The format of the "ATM Cell Rate" parameter is shown in figure 104. 8 7 6 5 Ext. 4 3 2 1 Cell Rate Identifier Cell Rate Ext. Cell Rate Identifier Cell Rate Figure 136 Cell Rate Identifier ATM Cell Rate Information sent to identify the applicability of the cell rate. The use of the peak cell rate (and other cell rates for future releases) is specified in Ref.[10.]. 0000000 : not used 0000010 : Forward PCR (0) D 0000011 : Backward PCR (0) D 0000100 : Forward PCR (0+1) D 770 00905 0120 VHBE Ed. 02 • D Cell Rate Identifier 0000101 : Backward PCR (0 +1) 259 / 297 9 B-ISUP Cell Rate This is a code expressing in pure 3 octets integer representation the number of cells per second. Bit 8 of the first octet is the most significant bit and bit 1 of the third octet is the least significant bit. Broadband Bearer Capability This parameter has already been described in section 8.4.1. Its coding is shown in figure 137. 8 Ext. 7 6 Coding Standard 5 4 3 2 1 Reserved Further Contents as in Q.2931, starting with octet 5 Figure 137 260 / 297 Broadband Bearer Capability 770 00905 0120 VHBE Ed. 02 9 B-ISUP Broadband High Layer Information This parameter has already been described in section 8.4.1. Its coding is shown in figure 138. 8 Ext. 7 6 5 4 Coding 3 2 1 Reserved Standard Further Contents as in Q.2931, starting with octet 5 Figure 138 Broadband High Layer Information Broadband Low Layer Information This parameter has already been described in section 8.4.1. Its coding is shown in figure 139. 8 7 6 5 ÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉ Repeat Ind. 4 3 2 1 Priority Further Contents as in Q.2931, starting with octet 5 Figure 139 Repeat Indicator Broadband Low Layer Information Information sent in the forward or backward direction, indicating whether or not the information element is repeated : Priority • 0 : Information Element not repeated D Repeat Indicator 1 : Information Element repeated Information sent in the forward and backward direction, indicating whether or not the repeated information elements are in ascending, descending or no prioritized order : 0000 : No prioritized order 0001 : Prioritized list for selecting 1 possibility, ascending order D 770 00905 0120 VHBE Ed. 02 • D Priority 0010 : Prioritized list for selecting 1 possibility, descending order 261 / 297 9 B-ISUP Call History Information The format of the "Call History Information" is shown in figure 140. 8 7 6 5 4 3 2 1 Delay Value Figure 140 Delay Value 262 / 297 Call History Information. The delay value expresses in pure binary representation the propagation delay value of a call in msec. Bit 8 of octet 1 is the most significant bit and bit 1 of octet 2 is the least significant bit respectively. 770 00905 0120 VHBE Ed. 02 9 B-ISUP Called Party Number The format of the "Called Party Number" parameter is shown in figure 141. 8 7 Odd / Even. INN Ind. 6 5 4 2 1 Nature of Address Indicator ÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉ Numbering Plan Indicator 2nd Address Signal 1st Address Signal ÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉ Filler (if necessary) Figure 141 Odd / Even Indicator 3 n th Address Signal Called Party Number This information is sent in association with an address, indicating whether the number of address signals contained in the address is even or odd. Nature of Address Indicator • 0 : even number of address signals D Odd/even indicator 1 : odd number of address signals This information is sent in association with an address, indicating the nature of that address. Examples of the coding are : 770 00905 0120 VHBE Ed. 02 0000001 : subscriber number 0000011 : national number D Internal Network Number Indicator • D Nature of address 0000100 : international number This information is sent in the destination exchange for specific numbers, e.g. roaming numbers indicating whether or not the number contained in the parameter is generated by the network, e.g. by an IN service like Number Portability (NP) 263 / 297 9 B-ISUP An ordinary subscriber will e.g. not be allowed to route directly to such an internal number, which normally is even unknown to him. Numbering Plan Indicator 0 : routing to internal network number allowed 1 : routing to internal network number not allowed This information is sent in association with a number indicating the numbering plan used for that number. Numbering plan Address Signal • D Internal network nr • 001 : ISDN (ITU-T E.164) An element of information in a network number. The address signal may indicate digit values 0 to 9, code 11 or code 12. One address signal value (ST) is reserved to indicate the end of the called party number. The most significant address signal is sent first. Subsequent address signals are sent in successive 4-bit fields. 0001 : digit 1 0010 : digit 2 D 0011 : digit 3 D 0100 : digit 4 D 0101 : digit 5 D 0110 : digit 6 D 0111 : digit 7 D 1000 : digit 8 D 1001 : digit 9 D 1011 : code 11 D 1100 : code 12 D 264 / 297 0000 : digit 0 D Filler • D Address signal 1111 : ST (Stop Digit) A number of bits used to complete a partially used octet to full octet length. In this case, the filler is used in numbers that are carrying an odd number of digits. The filler code 0000 is inserted after the last address signal. 770 00905 0120 VHBE Ed. 02 9 B-ISUP Called Party's Indicators The format of the "Called Party's Indicators" parameter is shown in figure 106. 8 7 6 5 4 ÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉ Figure 142 Called Party's Category 3 Called Party's Category Called Party's Status This information is sent in the backward direction, indicating the category of the called party. • 00 : no indication D 01 : ordinary subscriber D 10 : payphone Information sent in the backward direction, indication the status of the called party. • 0 : no indication D Called Party's Status 770 00905 0120 VHBE Ed. 02 1 Called Party's Indicators Called Party's Cat. Called Party's Status 2 1 : alerting 265 / 297 9 B-ISUP Calling Party Number The format of the "Calling Party Number" parameter is shown in figure 143. 8 7 6 Odd / Even. 5 4 3 2 1 Nature of Address Indicator Numbering Plan Indicator NI Address Presentation Restricted 2nd Address Signal 1st Address Signal ÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉ Filler (if necessary) Figure 143 Screening n th Address Signal Calling Party Number The coding and the meaning of most fields is identical to the ones of the called party address. Only the new fields are discussed here. Numbering Incomplete This information is sent to indicate whether the included calling party number is complete or incomplete. Address Presentation Restriction • 0 : complete D Number incomplete 1 : incomplete This is information sent in either direction to indicate that the address information is not to be presented to a public network user, but can be passed to another public network. It may also be used to indicate that the address can not be ascertained. 00 : presentation allowed 01 : presentation restricted D 266 / 297 • D Address Pres. Restr 10 : address not available 770 00905 0120 VHBE Ed. 02 9 B-ISUP Screening Indicator This is information sent in either direction to indicate whether the address was provided by the user or by the network. 00 : user provided, not verified 01 : user provided, verified and passed D 10 : user provided, verified and failed D 770 00905 0120 VHBE Ed. 02 • D Screening indicator 11 : network provided 267 / 297 9 B-ISUP Calling Party's Category The format of the "Calling Party's Category" parameter is shown in figure 144. 8 7 6 5 4 3 2 1 Calling Party's Category Figure 144 Calling Party's Category The following are examples of the coding. 00000001 : operator, French 00000010 : operator, English D 00000011 : operator, German D 00000100 : operator, Russian D 00000101 : operator, Spanish D 00001010 : ordinary calling subscriber D 00001011 : calling subscriber with priority D 00001100 : data call D 00001101 : test call D 268 / 297 • D Cl Party's Category 00001111 : payphone 770 00905 0120 VHBE Ed. 02 9 B-ISUP Connection Element Identifier The format of the "Connection Element Identifier" parameter is shown in figure 145. 8 7 6 5 4 3 2 1 VPC Identifier VC Identifier Figure 145 VPC Identifier Connection Element Identifier The Virtual Path Connection identifier identifies the VPC between 2 B-ISDN ATM exchanges. Bit 8 of octet 1 is the most significant bit and bit 1 of octet 2 is the least significant one. The value of this field is not identical to the value used in the VPI field of the corresponding ATM cell header. VC Identifier The Virtual Channel identifier identifies the VC between 2 B-ISDN ATM exchanges. Bit 8 of octet 3 is the most significant bit and bit 1 of octet 4 is the least significant one. The value of this field is identical to the value used in the VCI field of the corresponding ATM cell header. 770 00905 0120 VHBE Ed. 02 269 / 297 9 B-ISUP Maximum End-to-end Transit Delay The format of the "Maximum End-to-end Transit Delay" is identical to the format of the "Call History Information" , which is shown in figure 140. OAM Traffic Descriptor This parameter has already been described in section 8.4.1. Its coding is shown in figure 146. 8 7 Ext. 6 Coding Standard 5 4 3 2 1 Reserved Further Contents as in Q.2931, starting with octet 5 Figure 146 OAM Traffic Descriptor Parameter Propagation Delay Counter The format of the "Propagation Delay Counter" is identical to the format of the "Maximum End-to-end Transit Delay" , which is shown in figure 140. 270 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP Subsequent Number The format of the "Subsequent Number" parameter is shown in figure 147. 8 6 5 2nd Address Signal ÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉ Filler (if necessary) Figure 147 770 00905 0120 VHBE Ed. 02 4 3 2 1 ÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉ Odd / Even. 7 1st Address Signal n th Address Signal Subsequent number. 271 / 297 9 B-ISUP 9.6.3 Parameters, mainly used in Call Release Messages Table 33 B-ISUP Parameters names and codes, mainly used in Call Release. Parameter Type Meaning Mes sages Parameter Type Code Automatic congestion level Information sent to the exchange at the other end of a circuit to indicate that a particular level of congestion exists at the sending exchange. REL, IAR 00100111 Cause indicators Information sent in either direction indi cating where and why the call failed or was cleared ACM, CPG, CFN, REL, RLC, IAR 00010010 Automatic Congestion Level The format of the "Automatic Congestion Level" parameter is shown in figure 148. 8 7 6 5 4 3 2 1 Automatic Congestion Level Figure 148 Automatic Congestion Level The following codes are used in this parameter. • 00000001 : Congestion Level 1 exceeded D Autom. Cong. Level 00000010 : Congestion Level 2 exceeded Cause Indicators The coding of this parameter is defined in Ref.[24.]. 272 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP 9.6.4 Parameters, mainly used in Suspend / Resume Table 34 ISUP Parameters names and codes, mainly used in Call Suspension Parameter Type Meaning Suspend/resume indica tors Mes sages Information sent in the SUS/RES mes sages to indicate whether suspend/re sume was initiated by an ISDN sub scriber or by the network. Parameter Type Code SUS, RES 00100010 We shall now examine these parameters in more detail. Suspend / Resume Indicators The format of the "Suspend / Resume Indicator" parameter is shown in figure 149. It is used to indicate if the suspend or resume procedure is "network initiated" (analogue clearback) or "user initiated" (ISDN user). 8 7 6 5 4 3 2 1 ÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉ Sus / Res Ind Figure 149 Suspend / Resume Indicator The Sus / Res indicator is coded as follows : 770 00905 0120 VHBE Ed. 02 • 0 : ISDN subscriber initiated D Sus / Res indicator 1 : network initiated 273 / 297 9 B-ISUP 9.6.5 Parameters, mainly used in Consistency Check Messages Table 35 B-ISUP Parameters names and codes, mainly used in Consistency Check Procedures Parameter Type Consistency Check Re sult Information Meaning Mes sages Parameter Type Code Information sent indicating the result of the consistency check CCEA 01001010 We shall now examine these parameters in more detail. Consistency Check Result Information The format of the "Consistency Check Result Information" parameter is shown in figure 150. It is merely used to indicate a successful or an unsuccessful outcome of a continuity check. 8 7 6 5 4 3 ÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉ Figure 150 VPCI Check Result Indicator 2 VPCI Check Result Ind. Consistency Check Result Information The VPCI Check Result Indicator indicates the success/failure of the consistency check. It is coded as follows : • 00 : VPCI check not successful D 01 : VPCI check successful D VPCI Check Result 274 / 297 1 10 : VPCI check not performed 770 00905 0120 VHBE Ed. 02 9 B-ISUP 9.6.6 Parameters, mainly used in Facility Messages Table 36 ISUP Parameters names and codes, mainly used in Facility Messages. Parameter Type Meaning Mes sages Parameter Type Code User-to-user indica tors Information sent in association with a request (or a response to a request) for user-to-user signalling SS. ACM, ANM, CPG, IAM, REL, 00101010 User-to-user informa tion Information generated by a user and transferred transparently through the interexchange network between the originating and terminating local ex changes. ACM, ANM, CPG, IAM, REL, USR 00100000 We shall now examine these parameters in more detail. User-to-user Indicators The format of the "User-to-user Indicators" parameter is shown in figure 151. 8 NW Discard Ind Figure 151 Type 7 6 5 Service 3 related 4 Service 2 related 3 2 1 Service 1 related Type User-to-user Indicators. Information sent in either direction to indicate whether the message is a request or a response. • 0 : request D Type 1 : response Service 1 related This field is irrelevant in facility messages. Service 2 related This field is irrelevant in facility messages. 770 00905 0120 VHBE Ed. 02 275 / 297 9 B-ISUP Service 3 related In case the "Type" field indicates a request : • 10 : request, not essential D Service 3 related 11 : request, essential In case the "Type" field indicates a response : Network Discard Indicator • 01 : not provided D Service 3 related 10 : provided This field is irrelevant in facility messages. User-to-user Information This parameter contains the actual user-to-user information. 276 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP 9.6.7 Parameters, mainly used in Maintenance Control Messages Table 37 B-ISUP Parameters names and codes, mainly used in Maintenance Control Messages. Parameter Type Meaning Resource Identifier Mes sages Information sent identifying the re sources to be reset or (un)blocked. Parameter Type Code BLO, RSM, UBL, CCR 00111001 Resource Identifier The format of the "Resource Identifier" parameter is shown in figure 152. Ext. 7 6 5 4 ÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉ ÉÉÉÉÉÉÉÉÉÉÉÉ 8 3 2 1 Resource Indicator Resource Value Figure 152 Resource Indicator Resource Identifier Information sent as a part of the Resource Identifier" to identify the type of resource to be reset or (un)blocked. 000 : local SID 001 : remote SID D 010 : Connection Element Identifier : VPCI/VCI D 770 00905 0120 VHBE Ed. 02 • D Resource Indicator 011 : Connection Element Identifier : VPCI 277 / 297 9 B-ISUP 9.7 Capability Set 2. 9.7.1 Overview An overview of CS2 capabilities is provided by Ref.[25.]. It defines the following capabilities, which are added to the capabilities of B-ISUP CS1 : " Point-to-Multipoint Calls Procedures are provided for the setup and release of a call consisting of a single point-to-multipoint, unidirectional connection. The characteristics of this connection, from the originator (root) to the destinations (leaf parties) are all identical. Procedures are provided for the addition and removal of leaf parties from the call. D Addition of leaf parties can only be done by the root party. D Removal of a leaf can be from either the root or the affected leaf party. Additionally, en-bloc" release of the whole point-to-multipoint connection from the root is provided. The procedures are described in Ref.[26.]. " Additional Traffic Parameters Procedures are provided to the support of additional traffic parameters, as there are : D D parameters for the ATM Transfer Capability (ATC) (described in Ref.[29.]). D parameters to support Available Bit Rate (ABR) (described in Ref.[30.]). D 278 / 297 parameters for Sustainable Cell Rate (SCR) and QoS (described in Ref.[28.]). parameters to support ATM Block Transfer (ABT) (described in Ref.[31.]). 770 00905 0120 VHBE Ed. 02 9 B-ISUP " Look-ahead Capability Procedures are provided for edge-to-edge look-ahead, that allows a network to perform called-terminal availability and compatibility checking without any commitment of network resources. This is an optional capability that can be employed to optimize network resource usage. The procedures are described in Ref.[32.]. " Negotiation of Traffic Characteristics during Call Setup 2 Cases of negotiation are allowed : D Alternative ATM Cell Rate If the bandwidth requirements in the connection request can not be supported by the network, alternative bandwidth requirements, contained in the Alternative ATM Cell Rate" may be used instead, provided that these can be supported. The alternative bandwidth requirements must be reduced compared to those originally requested. D Minimum ATM Cell Rate If the bandwidth requirements in the connection request can not be supported by the network, a reduced bandwidth allocation may be substituted, provided that this still satisfies a specified minimum ATM cell rate. Only negotiation of peak cell rates is supported using the negotiation procedures. In both cases, the final bandwidth is returned in the ATM Cell Rate" parameter and Additional ATM Cell Rate" parameter in the ANM message. If this differs from the bandwidth allocation supported by the network, the network must modify the bandwidth allocation for the connection accordingly. The network passes the final bandwidth information back to the calling user. The procedures are described in Ref.[33.]. 770 00905 0120 VHBE Ed. 02 279 / 297 9 B-ISUP " Modification of Traffic Characteristics during the Active Phase Procedures are provided for the modification of traffic parameters (forward and/or backward) of a point-to-point connection. Only the user that originally requested the setup of the connection can request the modification. No rerouting of the connection is attempted during the connection modification. The procedures, to modify the PCR, are described in Ref.[34.]. The procedures, to modify the SCR, are described in Ref.[35.]. " ATM End System Address Procedures are provided for the transport of the ATM End System Address (AESA). The E.164 format of the AESA is accepted at the originating exchange, and used to derive E.164 number to be carried within the called party number", and used for routing purposes. The AESA is transferred across the network and delivered to the called user. AESA for the calling party is also supported. The procedures are described in Ref.[37.]. " Call Priority Priority Call Handling is provided for single connection point-to-point calls. The procedures are described in Ref.[38.]. " Network Call Correlation Id A network generated identifier is provided to enable the network to correlate records at multiple exchanges for non-real time purposes, e.g., accounting. The procedures are described in Ref.[39.]. " Frame Relay Procedures are provided for the setup and release of a call supporting the frame relay service. The procedures are described in Ref.[41.]. Some of these additional capabilities are discussed in more detail, hereafter. 280 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP 9.7.2 Point-to-Multipoint Calls Call Owner and Party Owner The following concepts are used : Call Owner : There is one call owner per call. It is the party that initiates the call. In CS2, the root is always the call owner. " Capabilities " Party Owner : This is the party that adds the party to the call. In CS2, the root is always the party owner for each party of the call. The following capabilities are supported. " " Establishment of a new party requested by the root of the connection. " Drop of a leaf party from an existing call requested by the root. " Drop of a leaf party from an existing call requested by the party itself. " Setup of the First Party Establishment of a call containing a point-to-multipoint network connection requested by the root of the connection. Release of the call, requested by the call owner. A request for a setup of a point-to-multipoint connection from the B-ISDN access is recognized by the indication of "point-to-multipoint " in the BB Bearer Capability" IE. En bloc signalling must be used. Overlap sending is not supported. In addition of the OSID and the DSID, the following Signalling Identifiers are used. " Originating Connection Link Identifier (OCLID) " Destination Connection Link Identifier (DCLID) These identifiers enable the distinction between different branches of the multicast tree. They identify particular Connection Link Processes (incoming and outgoing) at the intermediate nodes. When the originating exchange has received the complete information from the calling party, it performs routing and VC selection. The exchange creates : " " 770 00905 0120 VHBE Ed. 02 an instance of the Outgoing Connection Link process an instance of the B-ISUP AE 281 / 297 9 B-ISUP The setup of the connection is transferred to the next exchange by means of a usual IAM. However, additional parameter in the IAM are the CLIDs, and also the Leaf Party Type" parameter. Its value depends on the value of the Endpoint Reference" IE received from DSS2. If this parameter has the value 0", which means that it is the first party, then Leaf Party Type" is set to First Endpoint", else it is set to Subsequent Endpoint" . The originating exchange must store the ATM Cell Rate" and the BB Bearer Capability" belonging to that call. These values are required when following IAMs for the addition of parties to the point-to-multipoint connection are issued. Indeed, identical copies of these parameters can be sent in the subsequent IAMs. In intermediate exchanges, after reception of the IAM, an Incoming Connection Link process instance and an incoming B-ISUP AE instance are created. Then, routing is performed. If successful, the exchange shall " " create an instance of the B-ISUP AE " Addition of a Party create an instance of the Outgoing connection Link Process establish a logical association between the incoming and outgoing AEIs used for this call establishment. The originating exchange receives from the access the ADD PARTY message, which contains the same call reference as the SET UP message for the same call. An Endpoint Reference" value different from 0" must be present. The originating exchange selects the route and an adequate VC. The stored ATM Cell Rate" and BB Bearer Capability" IEs are retrieved, and used in the following IAM. Note that the IAM is also used of party additions, there is not an equivalent of the DSS2 ADD PARTY message. The same goes for the ACM, CPG and ANM messages. For the addition of a party at an exchange, a distinction must be made between 2 cases : " " 282 / 297 For the new party, a route is required to an exchange to which not yet a connection link exists for this point-to-multipoint communication. In this case, he same procedures apply as for the setup of the first party. The network connection branches to an exchange to which already a connection link is established for this point-to-multipoint connection. 770 00905 0120 VHBE Ed. 02 9 B-ISUP Indeed, to limit the network traffic, replication of ATM cells (necessary to reach multiple parties) must take place as far towards the leafs as possible. This is shown in figure 153. The described point-to-multipoint connection is initiated by user A and is directed to the users B, C, D and E. A B Local Exchange Local Exchange Transit Exchange C D Transit Exchange Local Exchange E Local Exchange Figure 153 Example of a Point-to-Multipoint Connection In the case a branch already exists, the existing Outgoing Connection Link process instance is accessed. However, a new instance of the B-ISUP AE must be created. Thus, a new OSID and DSID are assigned, but the OCLID and the DCLID are reused. No VPCI/VCI and bandwidth assignment procedures take place. The IAM shall include the Leaf Party Type" set to Subsequent Endpoint". The following figure illustrates the setup of a simple point-to-multipoint call. The used messages are shown together with the used transaction identifiers. 770 00905 0120 VHBE Ed. 02 283 / 297 9 B-ISUP A Local Exchange Transit Exchange Local Exchange Local Exchange IAM (OSI=S01, OCLI=CL01, Cd=B) IAA (DSI=S01, OSI =S11, DCLI=CL01,OCLI=CL11) B C IAM (OSI=S14, OCLI=CL12, Cd=B) IAA (DSI=S14, OSI =S21, DCLI=CL12, OCLI=CL11) D IAM (OSI=S02, DCLI=CL11, Cd=C) IAM (OSI=S15, OCLI=CL13, Cd=C) IAM (OSI=S03, DCLI=CL11, Cd=D) IAA (DSI=S02, OSI= S12, DCLI=CL01) IAA (DSI=S15, OSI=S31, DCLI=CL13, OCLI=CL31) IAA (DSI=S03, OSI= S13, DCLI=CL01) IAM (OSI=S16, DCLI=CL13, Cd=D) IAA (DSI=S16, OSI=S32, DCLI=CL13) OSI : Origination Signalling Identifier DSI : Destination Signalling Identifier OCLI : Origination Connection Link Identifier DCLI : Destination connection Link Identifier Figure 154 Setup of a Point-to-Multipoint connection For reasons of conciseness, we shall not the scenarios for party dropping or connection release. 9.7.3 Additional Traffic Parameters The same additional parameters are defined, but instead of extending the ATM Cell Rate" parameter (which is done in DSS2), a new B-ISUP parameter Additional ATM Cell Rate" has been defined. This parameter contains exactly the extensions described in section 8.6.3, except for the tagging options which are not conveyed over the network. Also, the ABR Setup" parameter is reused from DSS2. 284 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP 9.7.4 Look-ahead Capability The look-ahead facility allows a network to perform called-terminal availability and compatibility checking without any commitment of network resources. Who ? When ? The look-ahead initiating exchange can be any exchange, originating, transit, gateway, destination, ... The network can employ the following criteria, for applying the look-ahead procedure. " High-resource connections D D " The bandwidth exceeds a certain threshold or a value determined by current local circumstances. These values, selected by the network operator, may change according to the time of day, day of week, etc.... NM indicates that the user-plane of the network is under heavy load Number Analysis The connection may be directed to a country with a known low B-ISDN penetration. " Service Indications B-LLI, B-HLI and BC parameters indicate a request for a service that is not recognize or that is known to be very scarce. " Calling Party Indications The calling party is known to make a high proportion of unsuccessful calls. When not ? The network operator might choose to modify the decision based on other criteria that make the procedure inappropriate. The following are examples. " " Result 770 00905 0120 VHBE Ed. 02 The subscription or service information may indicate that that the call setup delay must be minimized. It is the responsibility of the service logic not to invoke the look-ahead procedure when the overall setup delay could be unacceptably high. NM indicates that the signalling network is heavily loaded, while the user-plane of the network is not. Depending upon the received look-ahead result, the look-ahead controlling exchange may decide to start normal call setup, or to clear the call towards the calling party. 285 / 297 9 B-ISUP Implementation The look-ahead application uses : " TCAP which supports the structured dialogue facility " SCCP which supports end-to-end message transfer. 9.7.5 Negotiation of Traffic Characteristics during Call Setup The procedures are identical to the DSS2 procedures, with " " 9.7.6 the B-ISUP Alternative Cell Rate"parameter being the equivalent of the DSS2 Alternative ATM Traffic Descriptor"IE the B-ISUP Minimum Acceptable ATM Traffic Descriptor"parameter being the equivalent of the DSS2 Minimum ATM Cell Rate" IE Modification of Traffic Characteristics during the Active Phase The procedures are identical to the DSS2 procedures, with " " the B-ISUP Modify Acknowledge (MOA) being the equivalent of the DSS2 MODIFY ACKNOWLEDGE. " the B-ISUP Modify Reject (MOR) being the equivalent of the DSS2 MODIFY REJECT. " 9.7.7 the B-ISUP Modify Request (MOD) being the equivalent of the DSS2 MODIFY REQUEST. the B-ISUP Modify Confirm (MOC) being the equivalent of the DSS2 CONNECTION AVAILABLE. Call Priority The call priority format is identical to the DSS2 procedures. Under normal conditions, when the network is not under congestion, and the exchange has the necessary resources to complete it, the call is processed without special treatments. The Priority" parameter shall be passed unchanged. In times of network congestion, when the exchange does not have sufficient resources to complete all of the incoming setup requests, as an option, the exchange may give preferential treatments 286 / 297 770 00905 0120 VHBE Ed. 02 9 B-ISUP based on the priority level. The preferential treatment should include access to reserved network resources, e.g. : " the highest priority calls are given access to available network resources including the resources reserved for highest priority calls. " the second highest priority calls are given access to available network resources including the resources reserved for the second highest priority calls, except for the resources reserved for the highest priority calls, and so on. " calls of the lowest priority level have no access to reserved network resources. Allocation of reserved network resources to specific priority levels is implementation specific. 770 00905 0120 VHBE Ed. 02 287 / 297 9 B-ISUP 288 / 297 770 00905 0120 VHBE Ed. 02 Abbreviations Abbreviations AAL-5 ATM Adaptation Layer 5 ABT ATM Block Transfer ACM Address Complete AE Application Entity ANM Answer AP Application Process ASE Application Service Element ASSS Analogue Subscriber Signalling System ATC ATM Transfer Capability ATM Asynchronous Transfer Mode B-HLI BB High Layer Information B-ISDN Broadband Integrated Services Digital Network B-ISUP Broadband ISDN User Part B-LLI BB Low Layer Information BA Basic Access BB Broadband BCC Bearer Connection Control BLA Blocking Ack BLO Blocking BR Buffer Release CAS Channel Associated Signalling CBA Changeback Acknowledgement CBD Changeback Declaration CC Call Control CCE Consistency Check End CCR Consistency Check Request CCS #7 Common Channel Signalling System #7 CDV Cell Delay Variation CDVT Cell Delay Variation Tolerance CFN Confusion CLP Cell Loss Priority 770 00905 0120 VHBE Ed. 02 289 / 297 Abbreviations CNP Connection Not Possible Signal CNS Connection Not Successful Signal COO Changeover Order COT Continuity CP Common Part CPCS Common Part Convergence Sublayer CPG Call Progress CRC Cyclic Redundancy Check CS Convergence Sublayer CS Capability Set CSS Connection Successful Signal DBR Deterministic Bitrate DC Direct Current DCLID Destination Connection Link Identifier DLC Signalling Datalink Connection Order DPC Destination Point Code DSID Destination Signalling Identifier DSS1 Digital Subscriber Signalling System #1 DSS2 Digital Subscriber Signalling System #2 DTMF Dual Tone Multi-frequency ECM Emergency Changeover EMA Emergency Changeover Acknowledge FOT Forward Transfer IAA IAM Acknowledgement IAM Initial Address IAR IAM Reject IBT Intrinsic Burst Tolerance IE Information Element IN Intelligent Network ITU-T International Telecommunicaton Union IWF Interworking Function MBS Maximum Burst Size MC Maintenance Control 290 / 297 770 00905 0120 VHBE Ed. 02 Abbreviations MCR Minimum Cell Rate MID Multiplexing Identifier MOA Modify Acknowledge MOC Modify Confirm MOD Modify Request MOR Modify Reject MTP Message Transfer Part N-ISDN Narrowband Integrated Services Digital Network NI Network Indicator NI Network Interface NNI Network-to-Network Interface NP Number Portability NRM Network Resource Management OAM Operation, Administration & Maintenance OCLID Originating Connection Link Identifier OPC Originating Point Code OSID Originating Signalling Identifier PABX Private Automatic Branch Exchange PCM Pulse Code Modulation PCR Peak Cell Rate PDU Protocol Data Unit PTI Payload Type Identifier QoS Quality of Service RAM Reset Acknowledgement RCT Signalling Route Set Congestion Test REL Release RES Resume RLC Release Complete RSM Reset RSR Signalling Route Set Test Message for restricted destination RST Signalling Route Set Test Message for prohibited destination SAAL Signalling ATM Adaptation Layer SACF Single Association Control Function 770 00905 0120 VHBE Ed. 02 291 / 297 Abbreviations SAM Subsequent Address SAO Single Association Object SAP Service Access Point SAR Segmentation and Reassembly SBR Statistical Bitrate SCC Signalling Connection Control SCP Service Control Point SCR Sustainable Cell Rate SDU Service Data Unit SEP Signalling End Point SI Service Indicator SID Signalling Identifier SLC Signalling Link Code SLS Signalling Link Selection SLTA Signalling Link Test Acknowledgement SLTM Signalling Link Test Message SN Sequence Number SP Signalling Points SS Supplementarty Service SS Supplementary Service SSCF Service Specific Coordination Function SSCOP Service Specific Connection Oriented Protocol SSCS Service Specific Convergence Sublayer STM Synchronous Transfer Mode STP Signalling Transfer Point SUS Suspend SVC Signalling Virtual Channel TA Terminal Adaptor TFA Transfer Allowed TFC Transfer Controlled TFP Transfer Prohibited TFR Transfer Restricted TP Terminal Portability 292 / 297 770 00905 0120 VHBE Ed. 02 Abbreviations TRA Traffic Restart Allowed UBA Unblocking Ack UBL Unblocking UI Unrecognized Information UNI User-to-Network Interface UPA User Part Available UPT User Part Test UPU User Part Unavailable USR User-to-user Information VC Virtual Channel VCI Virtual Channel Identifier VP Virtual Path VPCI Virtual Path Connection Identifier VPI Virtual Path Identifier XCA Extended Changeover Acknowledgement 770 00905 0120 VHBE Ed. 02 293 / 297 Abbreviations 294 / 297 770 00905 0120 VHBE Ed. 02 Appendix A References 1. ITU-T I.113 : Vocabulary of Terms for Broadband Aspects of ISDN. 2. ITU-T I.311 : B-ISDN - General Network Aspects. 3. ITU-T I.321 : B-ISDN - Protocol Reference Model and its Application. 4. ITU-T I.327 : B-ISDN - Functional Architecture. 5. ITU-T I.330 : ISDN numbering and addressing principles. 6. ITU-T I.361 : B-ISDN - ATM Layer Specification. 7. ITU-T I.363.1 : B-ISDN - ATM Adaptation Layer (AAL) Type 1 and 2 Specification. 8. ITU-T I.363.3 : B-ISDN - ATM Adaptation Layer (AAL) Type 3/4 Specification. 9. ITU-T I.363.5 : B-ISDN - ATM Adaptation Layer (AAL) Type 5 Specification. 10. ITU-T I.371 : Traffic Control and Congestion Control in B-ISDN. 11. ITU-T I.610 : B-ISDN Operation and Maintenance Principles and Functions. 12. ITU-T Q.704 : CCS #7, Signalling Network Functions and Messages. 13. ITU-T Q.708 : Numbering of International Signalling Point Codes. 14. ITU-T Q.850 : DSS1 - General - Usage of Cause and Location in DSS1 and the SS7 ISDN User Part. 15. ITU-T Q.931 : DSS1 - ISDN UNI Layer 3 Specification for Basic Call Control. 16. ITU-T Q.932 : DSS1 - Generic procedures for the control of ISDN supplementary services. 17. ITU-T Q.1400 : Architecture Framework for the Development of Signalling and OAM Protocols using OSI concepts. 18. ITU-T Q.2010 : B-ISDN Overview, Signalling Capability Set 1 19. ITU-T Q.2100 : B-ISDN Signalling ATM Adaptation Layer (SAAL) Overview Description. 20. ITU-T Q.2110 : B-ISDN ATM Adaptation Layer - Service Specific Connection Oriented Protocol. 770 00905 0120 VHBE Ed. 02 295 / 297 21. ITU-T Q.2130 : B-ISDN ATM Adaptation Layer - Service Specific Coordination Function for Support of Signalling at the User Network Interface (SSCF at UNI). 22. ITU-T Q.2140 : B-ISDN ATM Adaptation Layer - Service Specific Coordination Function for Signallint at the Network Node Interface (SSCF at NNI). 23. ITU-T Q.2210 : MTP-3 functions and messages, using the services of ITU-T Q.2140. 24. ITU-T Q.2610 : B-ISDN - Usage of Cause and Location in B-ISDN User Part and DSS2. 25. ITU-T Q.2721.1 : B-ISUP - Overview of the B-ISDN NNI signalling capability set 2, step 1. 26. ITU-T Q.2722.1 : B-ISUP - NNI specification for point-to-multipoint call/connection control. 27. ITU-T Q.2722.2 : B-ISUP - Multiconnection calls at NNI. 28. ITU-T Q.2723.1 : B-ISUP - Support of additional parameters for SBR and QoS. 29. ITU-T Q.2723.2 : B-ISDN - Extensions to the CCS #7 B-ISUP Support of ATC in the BB Bearer Capability . parameter. 30. ITU-T Q.2723.3 : B-ISDN - Extensions to the CCS #7 B-ISUP Signalling Capabilities to support traffic parameters . for ABR. 31. ITU-T Q.2723.4 : B-ISDN - Extensions to the CCS #7 B-ISUP Signalling Capabilities to support traffic parameters . for ABT. 32. ITU-T Q.2724.1 : B-ISUP - Look-ahead without state change for the NNI. 33. ITU-T Q.2725.1 : B-ISUP - Support of negotiation during connection setup. 34. ITU-T Q.2725.2 : B-ISUP - Modification Procedures. 35. ITU-T Q.2725.3 : B-ISDN - Extensions to the CCS #7 B-ISUP - Modification Procedures for SBR parameters. 36. ITU-T Q.2725.4 : B-ISDN - Extensions to the CCS #7 B-ISUP - Modification Procedures with Negotiation. 37. ITU-T Q.2726.1 : B-ISUP - ATM End System Address. 38. ITU-T Q.2726.2 : B-ISUP - Call Priority. 39. ITU-T Q.2726.3 : B-ISUP - Network generated Session identifier. 296 / 297 770 00905 0120 VHBE Ed. 02 40. ITU-T Q.2726.4 : B-ISDN - Extensions to the CCS #7 B-ISUP - User generated identifiers. 41. ITU-T Q.2727 - B-ISUP - Support of Frame Relay. 42. ITU-T Q.2761 : B-ISUP - Functional Description of the B-ISUP of CCS #7. 43. ITU-T Q.2762 : B-ISUP - General Functions of Messages and Signals of the B-ISUP of CCS #7. 44. ITU-T Q.2763 : B-ISUP - CCS #7 B-ISUP - Formats and Codes. 45. ITU-T Q.2764 : B-ISUP - CCS #7 B-ISUP - Basic Call Procedures. 46. ITU-T Q.2931 : B-ISDN - DSS2 - UNI. Layer 3 Specification for Call/Connection Control. 47. ITU-T Q.2959 : B-ISDN - DSS2 - Call Priority. 48. ITU-T Q.2961.1 : Additional Signalling Capabilities to support Traffic Parameters for the Tagging Option and the SCR parameter set. 49. ITU-T Q.2961.2 : B-ISDN - DSS2 - Support of the ATC Capability in the BB Bearer Capability IE. 50. ITU-T Q.2961.3 : B-ISDN - DSS2 - Signalling Capabilities to support Traffic Parameters for ABR. 51. ITU-T Q.2961.4 : B-ISDN - DSS2 - Signalling Capabilities to support Traffic Parameters for ABT. 52. ITU-T Q.2961.5 : B-ISDN - DSS2 - CDVT indication. 53. ITU-T Q.2961.6 : Additional Signalling Capabilities for the support of SBR2 and SBR3. 54. ITU-T Q.2962 : DSS2 - Connection Characteristics Negotiation during Call/Connection Establishment Phase. 55. ITU-T Q.2963.1 : PCR Modification by the Connection Owner. 56. ITU-T Q.2963.2 : B-ISDN - DSS2 - Modification Procedures for SCR Parameters. 57. ITU-T Q.2941.1 : DSS2 - Basic Look Ahead. 58. ITU-T Q.2971 : B-ISDN - DSS2 - UNI Layer 3 Specification for point-to-multipoint call/connection control. 59. ITU-T X.200 : Information Technology - Open Systems Interconnection - Basic Reference Model : the Basic Model. 770 00905 0120 VHBE Ed. 02 297 / 297 ...
View Full Document

This note was uploaded on 08/08/2011 for the course CS 310 taught by Professor Aartisingh during the Spring '11 term at National Institute of Technology, Calicut.

Ask a homework question - tutors are online