Alcatel 1000 S12 Functional Description PDF

HANDOUT
A1000 S12
 1998 ALCATEL BELL N.V. ALL RIGHTS RESERVED
FUNCTIONAL DESCRIPTION
Edition : 06
770 00924 0120–VHBE i BELL EDUCATION CENTRE

The Bell Education Centre put in a great effort to give you this document. In case you have
any remarks, do not hesitate to send us your comments.
Our Training Directory describes all training programmes and modules this document (and
others) is used in.
This document was especially written for use during class instruction.
The contents of this document is generic. It deals with concepts and principles, rather than
with the latest releases of and modifications to the product delivered to the customers.
International audiences use this document. It is therefore written in a clear, concise and
above all, consistent language.
BELL EDUCATION CENTRE ii 770 00924 0120–VHBE

PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1. A1000 S12 OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Exchange structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.3 Equipment practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Configurations and applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Supplementary Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.1 Centrex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4.2 Business Communication Group (BCG) . . . . . . . . . . . . . . . . . . . . 17
1.5 Operation, Administration & Maintenance (OA&M) . . . . . . . . . . . . . . . 18
2. A1000 S12 HARDWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1 The Digital Switching Network (DSN) . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.2 Digital Switching Element (Multiport) . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.3 Switching in the Multiport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.4 Network Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.5 Network addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.1.6 Blocked Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.1.7 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2 Generic structure of a module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2.1 Terminal Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.2.2 Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.2.3 Physical implementation of the Control Element . . . . . . . . . . . . . 50
2.2.4 The On Board Controller (OBC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.3 Description of the different hardware modules . . . . . . . . . . . . . . . . . . . 56
2.3.1 The Analogue Subscriber Module (ASM) . . . . . . . . . . . . . . . . . . . 56
2.3.2 Digital Trunk Module (DTM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.3.3 High–performance Common Channel Module (HCCM) . . . . . . . 83
2.3.4 Service Circuit Module (SCM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
2.3.5 Trunk Testing Module (TTM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
2.3.6 Clock & Tone Module (CTM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
2.3.7 Digital Integrated Announcement Module (DIAM) . . . . . . . . . . . . 110
2.3.8 Peripheral & Load Module (P&L) . . . . . . . . . . . . . . . . . . . . . . . . . . 112
2.3.9 ISDN Subscriber Module (ISM) . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
2.3.10 Mixed Subscriber Module (MSM) . . . . . . . . . . . . . . . . . . . . . . . . . . 122
2.3.11 ISDN Trunk Module (ITM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
2.3.12 The Data Link Module (DLM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
2.3.13 EPM: Extended Peripheral Module . . . . . . . . . . . . . . . . . . . . . . . . 124
2.3.14 ISDN Remote Subscriber Unit (IRSU)
ISDN RSU Interface Module (IRIM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
2.4 Remote Terminal Sub Unit (RTSU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
3. A1000 S12 SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
3.1 Functional subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
iii BELL EDUCATION CENTRE

770 00924 0120–VHBE
3.2 Software concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
3.2.1 Finite Message Machine (FMM) . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
3.2.2 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
3.2.3 System Support Machine (SSM) . . . . . . . . . . . . . . . . . . . . . . . . . . 157
3.3 Communication between processes . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
3.3.1 Communication within the same CE . . . . . . . . . . . . . . . . . . . . . . . 161
3.3.2 Communication over a virtual path (VP) . . . . . . . . . . . . . . . . . . . . 162
3.3.3 Communication over a user controlled path (UCP) . . . . . . . . . . . 168
3.3.4 Communication with the internal packet protocol (IPP) . . . . . . . 171
3.4 Software modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
3.4.1 Logical grouping of the Call Handling software into call control planes . . . . . . . .
174
3.4.2 Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
3.4.3 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
3.4.4 Device handler FMMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
3.4.5 Signalling system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
3.4.6 Call Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
3.4.7 Auxiliary Resources TCE Allocator . . . . . . . . . . . . . . . . . . . . . . . . 194
3.4.8 Analysis of the Called Party Digits . . . . . . . . . . . . . . . . . . . . . . . . . 195
3.4.9 Subscriber analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
3.4.10 Trunk Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
3.4.11 Device Interworking Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
3.4.12 Private Access Resource Management (PARM) . . . . . . . . . . . . . 218
3.4.13 Physical mapping of the software onto control elements . . . . . . 223
4. A1000 S12 EXCHANGE CONFIGURATION . . . . . . . . . . . . . . . . . . . 225
4.1 Input/Output exchange devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
4.2 Control Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
4.2.1 Control element configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
4.2.2 Terminal Control Elements (TCEs) . . . . . . . . . . . . . . . . . . . . . . . . . 228
4.2.3 System Control Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
4.2.4 Auxiliary Control Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
4.3 Software principles and organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
4.3.1 Programs and data on mass storage media . . . . . . . . . . . . . . . . . 234
4.3.2 Memory organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
4.3.3 CE logical and physical identities . . . . . . . . . . . . . . . . . . . . . . . . . . 235
4.4 J–Rack family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
4.5 Training Exchange (TREX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
4.5.1 Rack alarm gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
5. CALL HANDLING OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
5.1 dtuaPossible accesses to an exchange . . . . . . . . . . . . . . . . . . . . . . . . 253
5.2 Overview of the call types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
5.3 Call handling blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
5.3.1 Terminating or Local Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
5.3.2 Transit or Outgoing Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
5.3.3 Hunting to lines/trunks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
770 00924 0120–VHBE

BELL EDUCATION CENTRE iv
5.4 Overview of the call phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
5.4.1 Originating exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
5.4.2 Incoming exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
5.5 Generic call scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
5.5.1 Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
5.5.2 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
5.5.3 Release (Local Call only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
6. CALL HANDLING EXAMPLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
6.1 Local call with analogue subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
6.1.1 Seize A–party . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
6.1.2 Start scanning for digits / Send dial tone to A–party . . . . . . . . . . 281
6.1.3 Activate call control / Perform A–party analysis . . . . . . . . . . . . . . 288
6.1.4 Receive prefix digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
6.1.5 Perform prefix analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
6.1.6 Receive remaining digits / Release receiver . . . . . . . . . . . . . . . . 293
6.1.7 Perform B–party analysis / Request DID . . . . . . . . . . . . . . . . . . . 296
6.1.8 Seize B–party / Start ringing phase . . . . . . . . . . . . . . . . . . . . . . . . 298
6.1.9 Activate charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
6.1.10 Pass to stable state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
6.1.11 Detect ring trip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
6.1.12 Stop charging / Release A–party . . . . . . . . . . . . . . . . . . . . . . . . . . 307
6.1.13 Release B–party . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
6.2 Local call with ISDN subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
6.2.1 Example of an ISDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
6.2.2 Overview of the ISDN protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
6.2.3 Layer three: the network layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
6.2.4 Layer two: the data link layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
6.2.5 Layer one: the physical layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
6.2.6 Terms and definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
6.2.7 Handling of a Q.931 message in S12 . . . . . . . . . . . . . . . . . . . . . . 321
6.2.8 Local ISDN call overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
6.2.9 Local ISDN call in detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
6.3 Outgoing / incoming call with CCS N7 signalling . . . . . . . . . . . . . . . . . 330
6.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
6.3.2 CCS N7 overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
6.3.3 Outgoing / incoming N7 call overview . . . . . . . . . . . . . . . . . . . . . . 339
6.3.4 Outgoing / incoming N7 call in detail . . . . . . . . . . . . . . . . . . . . . . . 346
6.4 Transit N7 call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
6.5 Outgoing / incoming call with CAS/R2 signalling . . . . . . . . . . . . . . . . . 355
6.5.1 CAS line signalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
6.5.2 R2 register signalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
6.5.3 Outgoing / incoming R2 call overview . . . . . . . . . . . . . . . . . . . . . . 366
6.5.4 Outgoing / incoming R2 call in detail . . . . . . . . . . . . . . . . . . . . . . . 368
7. FACILITY HANDLING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
7.1 Overview of some of the supplementary services . . . . . . . . . . . . . . . . 373
v BELL EDUCATION CENTRE

770 00924 0120–VHBE
7.2 Facility handling model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
7.2.1 General structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
7.2.2 Call and Facility Control System (CFCS) architecture . . . . . . . . 380
7.3 Supplementary service data structures. . . . . . . . . . . . . . . . . . . . . . . . . 381
7.3.1 Semi permanent data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
7.3.2 Dynamic data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
7.4 Triggers to activate supplementary services. . . . . . . . . . . . . . . . . . . . . 385
7.4.1 Trigger from the Originating profile. . . . . . . . . . . . . . . . . . . . . . . . . 385
7.4.2 Trigger from the Prefix Analysis result. . . . . . . . . . . . . . . . . . . . . . 386
7.4.3 Trigger from the terminating profile. . . . . . . . . . . . . . . . . . . . . . . . . 387
7.4.4 Recall pulse from the subscriber received. . . . . . . . . . . . . . . . . . . 387
7.4.5 Trigger from received signalling events (Event monitoring). . . . 388
7.4.6 Busy/free changes of a subscriber line (Monitor Access). . . . . . 390
7.5 Facility handling examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
7.5.1 Subscriber Control (SC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
7.5.2 Call Completion to Busy Subscriber (CCBS) . . . . . . . . . . . . . . . . 395
7.5.3 Malicious Call Identification (MCI) . . . . . . . . . . . . . . . . . . . . . . . . . 401
8. CHARGING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
8.1 Charging functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
8.2 Different ways to charge calls... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
8.2.1 Bulk billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
8.2.2 Detailed billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
8.2.3 Detailed billing observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
8.2.4 Toll ticketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
8.2.5 Automatic Message Accounting (AMA) . . . . . . . . . . . . . . . . . . . . . 409
8.2.6 Division of revenue (accounting) . . . . . . . . . . . . . . . . . . . . . . . . . . 409
8.2.7 Charging statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
8.2.8 Limit of credit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
8.2.9 Advice of charge (AOC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
8.2.10 Facility charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
8.3 Charging methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
8.3.1 Unit charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
8.3.2 Continuous charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
8.4 Charging analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
8.4.1 Charging analysis with MMC commands . . . . . . . . . . . . . . . . . . . 413
8.4.2 Charging parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
8.4.3 Software involved with charging analysis . . . . . . . . . . . . . . . . . . . 423
8.5 Charging generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
8.6 Charge scale change–over . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
8.7 Charging collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
8.7.1 Bulk billing collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
8.7.2 Detailed billing collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
8.7.3 Division of revenue collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
8.8 Charging output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
8.8.1 Bulk billing output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
770 00924 0120–VHBE

BELL EDUCATION CENTRE vi
8.8.2 Detailed billing output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
8.8.3 Division of revenue output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
9. MAINTAINING AN A1000 S12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
9.1 System and microprocessor initialization . . . . . . . . . . . . . . . . . . . . . . . 439
9.1.1 CE initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
9.1.2 System initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
9.1.3 OBC initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
9.2 Introduction to maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
9.3 Hardware and software used in maintenance . . . . . . . . . . . . . . . . . . . 455
9.4 Maintenance concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
9.4.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
9.4.2 Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
9.4.3 Security block states and state transitions . . . . . . . . . . . . . . . . . . 463
9.4.4 SBL management on CE Level (SBL=CTLE) . . . . . . . . . . . . . . . . 465
9.4.5 Automatic error handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
9.4.6 Corrective maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
9.4.7 Alarm system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
9.4.8 Preventive maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
9.4.9 Summary report for all scheduled routine tests . . . . . . . . . . . . . . 480
10. OPERATING AN A1000 S12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
10.1 IOS overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
10.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
10.1.2 IOS functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
10.1.3 Overall structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
10.2 Hardware configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
10.3 File–oriented interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
10.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
10.3.2 Logical file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
10.3.3 Logical device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
10.3.4 Physical and virtual devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
10.4 The MMC interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
10.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
10.4.2 MMC–dialogue–interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
10.4.3 MMC–monologue–interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
10.4.4 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
10.5 Exchange administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
11. ADMINISTRATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
11.2 Traffic measurements collection and supervision . . . . . . . . . . . . . . . . 508
11.2.1 Measurements based on statistical counters . . . . . . . . . . . . . . . . 508
11.2.2 Call observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
11.2.3 Supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
11.3 Exchange management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
11.3.1 Analogue and ISDN subscriber line administration . . . . . . . . . . . 514
vii BELL EDUCATION CENTRE

770 00924 0120–VHBE
11.3.2 Routing administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
11.3.3 Prefix administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
11.3.4 Charging administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
11.4 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
11.4.1 Destination controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
11.4.2 Routing controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
11.4.3 Machine congestion analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
11.5 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532

770 00924 0120–VHBE

BELL EDUCATION CENTRE viii
1.
PREFACE
Alcatel 1000 System 12 (A1000 S12) offers the main advantage of having fully distributed
control. As a consequence, the hardware and software are structured in separate modules,
each module interacting with others by means of well defined interfaces. Because of this
modular structure it is possible to study each module separately.
The System Overview was the basis to gather fundamental information about System 12.
Only general topics of every domain were treated.
The main objective of the ’Functional Description’ is not only to give the reader more
information about every module (hardware and software), but first of all to link all these
modules together. These links are explained by describing a local and an outgoing
telephone call in more detail.
The intention is that after this course, a trainee understands exactly which hardware and
software parts are involved in a telephone call. From each part he will posses the functional
knowledge.
It is certainly not the purpose of this course that detailed information is given by the trainer.
Detailed material is explained in separate courses, that follow the Functional Description. At
certain points in the text, references to the detailed courses are made.
To arrive to those objectives, a good knowledge and understanding of the following items is
necessary before getting started :
- General knowledge of digital telephony and data communication
- System Overview: 770 00435 6560–VHBE
770 00924 0120–VHBE 1 BELL EDUCATION CENTRE

1.
2 BELL EDUCATION CENTRE

770 00924 0120–VHBE
1.
1. A1000 S12 OVERVIEW
1.1 Introduction
During the first years of this century the role of the telephone industry was that of providing a
worldwide network dedicated, above all, to voice communication. For that purpose,
Analogue and mechanical nodes and transmission means were developed.
However, the appearance of new technologies, such as the computer and the capacity for
the large scale integration of circuits, has led to great changes. These changes are, on the
one hand, the automation of the telephone networks through the incorporation of stored
program switching nodes and digital transmission mechanisms; and on the other, the
emergence of needs for non–voice communication: data, images, etc., which in turn impacts
the design and development of communication networks.
Therefore, at present a series of alternative networks are being created. These new
networks must by means of international standards and strategies, in order to create a single
integrated service network. In this context A1000 S12 presents itself as a switching system
that is applicable to almost all existing networks and adaptable to future needs and services.
A1000 S12 is designed mainly for use in the Public Switched Telephone Network (PSTN),
providing access to Analogue subscribers, ISDN, mobiles, private branch exchanges,
remote units, etc. Furthermore, the system can be incorporated into the Packet Switching
Network (PSN), Broadband ISDN, Intelligent Networks, Telecommunication Management
Network, Alcatel MAN, etc.

1.
Figure 1 : A1000 S12 environment
Public
Remote Subscriber Switched
Unit (RSU) Telephone
Private Exchange Network
(PBX)
Packet
Switching
Network
Broad Band
Network Service Centre A1000 S12
Network
(NSC)
Cellular
Network
Analogue Subscriber ISDN Subscriber
From a user point of view, access to A1000 S12 is provided by a set of I/O interfaces in
order to use its services and control its operation.
Telephonic interfaces allow telecommunication network users to connect each other to

exchange information (voice and data). The most basic interface is the two wireloop,
although there are also more powerful ways of access by using high quality carrier systems.
Thus, digital exchanges are connected to each other by means of multiplexed lines (digital
trunks). This means that several conversations are transmitted by just one physical cable. In
addition, data links are used to gain access to O&M remote centres or data processing
centres.
The simplest known interface is obviously the subscriber loop. This subscriber loop is made
up of a couple of wires used for full duplex transmission. It goes without saying that the line
features allow the transmission of Analogue signals within the band from 300 to 3400 Hz.
Subscribers’ telephone sets employ either decadic or multifrequency dialling. This sort of line
is used for voice communication as well as for data communication by means of modems.
BELL EDUCATION CENTRE 4 770 00924 0120–VHBE

1.
Figure 2 : Analogue subscribers

Analogue telephone set
A1000 S12
Power
ÏÏÏÏÏÏÏÏ
ÏÏÏÏÏÏÏÏ
ÏÏÏÏÏÏÏÏ freq.
Modem ÏÏÏÏÏÏÏÏ
300 3400
Another interface, defined according to the same type of physical connection, is the set of
basic accesses to ISDN. As we already know, sophisticated digital transmission and
reception equipments can use a couple of wires for the emission of two 64 Kb/s channels
(voice or data) and additionally one 16 Kb/s channel used for signalling.

1.
Figure 3 : ISDN subscribers

ISDN telephone set
NT
A1000 S12
B1: 64 Kbps
B1 B2 D B2: 64 Kbps
PC
D : 16 Kbps
An upper level is the access to the telephonic network from Private Branch Exchanges.
These PBXs are connected to the host exchange through different types of interfaces.
The most basic interface consists of a set of lines (couples of wires) in charge of distributing
the outgoing calls, with the host exchange handling the incoming calls directed to the
subscriber’s line. Another method is to use high–quality lines (PCM Links). This allows
advanced control access by using a signalling channel (usually #16). Finally, PBXs can be
connected to ISDN exchanges by means of the PRA interface (Primary Rate Access) whose
structure is similar to PCM but which uses a different signalling protocol.
In order to provide global telephone service, all the telephone network exchanges are
connected to each other by means of trunks. Usually digital, these trunks forward the
information through 2048 Kb/s PCM frames supported on coaxial cables, radiolinks, or
optical fiber.

1.
Figure 4 : ISDN PABX

ISDN telephone set
NT
ISDN PABX
30 B D
Coaxial Cable
B1 B2 D
PC
B1: 64 Kbps
B2: 64 Kbps
D : 16 Kbps
A1000 S12
Finally, let us consider the access to network management centres. The most commonly
used systems are the N7 signalling and X.25 data protocols. The O&M and Taxation users
(OMUP and TAXUP respectively) are usually connected to the Network Service Centre
(NSC) through the N7 signalling network. The X.25 protocol is used as link between the
exchange and some data processing centres (EDPC).

1.
Figure 5 : Exchange interconnection
Remote Exchange
Remote Exchange
PCM format
30 +1+1
Coaxial Cable
Coaxial Cable
A1000 S12

1.
Figure 6 : Management centres

NETWORK
SERVICE
N7 CENTRE
NETWORK
N7
N7 X.25
X.25
PSN
A1000 S12
X.25
X.25
ELECTRONIC
DATA PROCESSING
CENTRE
1.2 Exchange structure
The A1000 S12 exchanges are characterized by two essential properties: digital technology
and distributed control.
First, A1000 S12 is said to use digital technology because its control and functions are
performed by programs that are executed on microprocessors, and the information internal
handling (switching and transmission) is carried out by fully digital techniques. These
features make the system capable of handling any piece of information, whatever its nature
(speech, data, text, etc.), as long as it is digitized, thus ensuring a better quality thanks to the
actual advantages of digital transmission and the absence of moving or mechanical parts.
Secondly distributed control means that the functions carried out by the system, from a
global point of view, are divided into sets of tasks which are grouped in a homogeneous way
and assigned to specific and specialized control elements. This idea allows to obtain of a
very reliable system for failures of control elements do not entail a meaningful impact on the
system. Furthermore, the way in which the different functions are organized allows new ones
to be added without having to redesign the system and, therefore, permits the easy
adaptation to new needs and services as they arise in the market.
The implementation of a system with these characteristics is achieved with the design of an
internal digital switching network that interconnects the different system modules to transmit

1.
internal control information as well as user data over the same paths. This internal network
can be easily extended by the addition of new modules. Furthermore, the network switching
control is of the gradual type (non–centralized) which simplifies its use. Another factor
contributing to the reliability of the System is that the network allows to link two modules
through multiple paths in order to ensure minimum blocking probability.
Another significant advantage is the use of customized integrated circuits (CLSI – Custom
Large Scale Integration –), which allows the optimization of the number of functions
performed by each printed circuit board, making possible the building of extremely compact
and reduced equipment.
1.2.1 Hardware
The A1000 S12 functional structure is remarkably simple; it consists of an internal switching
network to which a variety of terminal modules are connected according to the size of the
exchange and the services and facilities offered.
The A1000 S12 functional diagram has, therefore, a spider look (’Spider Diagram’) where
the nucleus is the internal switching network and the extremities are the modules. These
modules are connected to the network through transmission PCM links modified for their
adaptation to the functions required by the system interior.
The internal switching network (DSN –Digital Switching Network–) is formed by a set of
basic switching elements arranged under a folded topology. Given that the DSN’s number of
stages and planes can be increased with great easiness, there are two potential ways of
expansion: the number of inlets (terminals connected), and the possibility of alternative
paths (traffic flow capacity).
On the other hand, all the modules are connected to the network through two modified PCM
links presenting a single input and output protocol irrespective of the module. All the
modules contain a common part called Control Element or CE , composed of a
microprocessor and its memory, and a standard interface circuit towards the switching
network. These CEs are classified into two groups: Terminal Control Elements or TCEs, and
Auxiliary Control Elements or ACEs .
The TCEs are those control elements that are connected to a cluster or circuitry associated
with the specific module functions, for example line circuits, trunk circuits, etc.. The interface
towards the cluster circuits is also standard. However, there are other control elements
which are exclusively dedicated to performing support functions for the TCEs. They carry out
specific tasks such as error handling, prefix analysis, local subscriber identification, etc.,
without including any cluster or circuitry aside from the actual CE. These control elements
are called ACEs.

1.
Figure 7 : System diagram

AUXILIARY CONTROL
ELEMENTS
SUBSCRIBER MODULES
TRUNK MODULES
ACE Analogue
TRUNK TCE
TCE CIRCUITS
CIRCUITS
DIGITAL SIGNALLING
C&T
HANDLING MODULES TCE
CIRCUITS
DIGITAL Digital
SIGNALLING TCE Switching
CIRCUITS
Network CLOCK & TONE MODULES
SERVICE P&L
CIRCUITS
TCE TCE CIRCUITS
PERIPHERAL &
SERVICE MODULES LOAD MODULES
Some of the major A1000 S12 modules are briefly described below:
- Analogue Subscriber Module:
Composed of a control element and a set of line circuits that provide access to
Analogue subscribers. The different types of Analogue subscribers (regular, public
coinbox, priority class, etc.) are all supported through the same type of line circuit.
There are other similar modules for access to ISDN subscribers, mobile subscribers,
etc.
- Digital Trunk Module:
Consists of a CE and the digital trunk circuits required to provide access to external
systems (telephone exchanges, private automatic branch exchanges, remote
subscriber units, etc.) through a standard PCM link. The same piece of equipment is
able to handle different signalling types (MF or digital) that can be supported by
specialized signalling modules (Services Circuit Modules and Digital Signalling
Handling Modules).
- Peripheral & Load Module:
This module performs functions to access pieces of equipment such as peripherals

(Man Machine Communication terminals, printers, tapes, disks, etc.) and panels
and alarm lamps.

1.
- Clock & Tone Module:
Provides the system synchronization signal and generates the necessary telephonic
tones.
- ACE :
They perform auxiliary functions depending on the associated set of programs and
data. These programs define the name given to the ACEs.
These and other modules will be described in detail later in this document.
The singular structure described above allows the original design to be maintained for the
whole range of A1000 S12 applications.
1.2.2 Software
The software is organized under the support of an operating system and a data base that
are specific to the system and over which a set of application programs or software modules
are arranged.
The operating system is made up of a series of software functions that allow for the
management of all the system resources (CPU time scheduling, memory management,
communication through the network, etc.). This software subsystem is distributed over the
system microprocessors.
The data base consists of the information it contains in the form of tables or relations
(relational data base), and the programs to manage and access the data contained. These
two elements, the data and the programs, are also distributed over the system, yet all the
information can be accessed by any microprocessor.
The programs in charge of performing the actual system functions, such as signalling,
switching, charging, etc., are designed as independent modules. These modules reside in
the control element or elements where they must carry out their tasks. The exchange of data
between different software modules, whether they reside in the same CE or not, is
coordinated making use of the services provided by the operating system and carried out by
means of data units called Messages .
1.2.3 Equipment practice
The A1000 S12 digital exchanges are extremely compact and can be installed in regular
commercial buildings.
As regards the equipment’s physical appearance, the System consists of printed circuit
assemblies, panels, subframes (also called ’shelves’) and racks.

1.
As mentioned before, the use of the customized circuit manufacturing technique (CLSI)
allows the integration of a great number of functions in a single printed board. These
small–sized boards are inserted into slots, inside subframes laid in racks, which are
accessible from the front as well as from the back. These racks are arranged in rows that
appropriately interconnected form the exchange floor over a small area.
Each module is composed of one or more PBAs, which may be equipped in different
locations of several racks. This means that the rack equipment layout is variable.
Furthermore a set of DC/DC converters are provided to supply different voltages to the
circuits (5V, 12V,...)
Figure 8 : A1000 S12 Exchange floor

RACK
SYSTEM 12
SUBRACK
ROW
PBA
EXCHANGE FLOOR
1.3 Configurations and applications
The A1000 S12 modular structure accommodates a wide range of different configurations
using the same basic elements and similar equipment structures.
All possible configurations, from small remote units to large local exchanges, are covered.
Furthermore, the system can be set to offer the most advanced user facilities whatever the
configuration.
A brief list of the A1000 S12 product range is outlined on the following page:
- Local, transit (toll) and combined exchanges

From 512 to 256 000 lines
Up to 60 000 trunks

1.
- International exchanges
- Small capacity exchanges:

SSA (Small Stand Alone)
From 256 to 3 840 lines
VSSA (Very SSA)
From 16 to 768 lines.
- Remote applications
Remote Subscriber Units
Up to 976 Analogue lines
- Other configurations
Network Service Centre
SSP in intelligent networks
1.4 Supplementary Services

From a subscriber point of view, A1000 S12 offers a wide range of supplementary services.
Some of these supplementary telephone services, such as the following ones, are common
to Analogue and ISDN subscribers:
- Fixed Destination call:
The exchange provides a preprogrammed number without digits send.
- Abbreviated dialing:
Using a short number the user can establish calls to public subscribers.
- Do not disturb:
If active, the exchange considers the user as being busy, and every terminating call to
the user is released.
- Call forwarding on no reply:
Calls to the user are forwarded only on no reply after a time–out.
- Completion of calls to busy subscriber:
The exchange manages the calls to the user holding the incoming call until the
terminating subscriber is free.
- Malicious call identification
Information about terminating calls to the user is stored in case a defined signal is
incoming from the called subscriber.

1.
- etc.
Other facilities, as those outlined below, are exclusively for ISDN subscribers:
- Advise of charge:
The user is informed about charging throughout the call duration or/and at the end of
the call. The information is shown on the display of the telephone set.
- User–to–user signalling:
ISDN users are able to send their own information through the ISDN using the
particular features of the N7 signalling system.
- etc.
Also, we can mention here some services like Centrex ., Wide Area Centrex (WAC), and
Business Communication Group (BCG).
1.4.1 Centrex
First of all, Centrex is an implementation of a private telecommunication network

exchange that is not located on the premises of the private network operator but which is
part of a public local exchange. The users of a Centrex have the impression of being
connected to one homogeneous private telecommunication network, which is invisible to
them. The Centrex service is able to provide supplementary services inside the Centrex
Group. However, a Centrex subscribers must be connected to the same local exchange.

1.
Figure 9 : Centrex Structure
Subscriber 1
A1000 S12
PBX 1
Subscriber N CENTREX
PBX P
Centrex user 1
Centrex user M
The Wide Area Centrex service improves the basic Centrex to support extensions connected
to different exchanges. The main limitation of WAC is that it has a private numbering plan
which is completely associated with the public numbering plan.

1.
Figure 10 : Wide Area Centrex
Centrex B subscribers
EXCH B
EXCH C
EXCH A
Centrex C subscribers
Centrex A subscribers
1.4.2 Business Communication Group (BCG)
To solve the above problems, A1000 S12 supports also the Business Communication Group
service. Business Communication is a service that allows business user belonging to
different exchanges to have a virtual private telecommunication network. ISDN and
Analogue subscribers belonging to Centrex, and private exchanges, can be connected by
this service. Using a private numbering plan, BC users establish calls for voice or data
purposes in the Business Communication Group. Of course, using the public numbering
plan, users can reach any subscriber outside the group. This private numbering plan can
have a different structure compared to the public numbering plan.

1.
Figure 11 : Business Communication Group
Centrex B subscribers
PBX
PBX
PBX
PBX EXCH B
EXCH C
EXCH A
Centrex C subscribers
Centrex A subscribers
1.5 Operation, Administration & Maintenance (OA&M)
The administration of the A1000 S12 is made easier with the creation of a powerful
man–machine communication system. This communication mechanism supplies the
operator with simple and easy access to all the information related to subscribers, trunks,
etc., and, of course, provides all the necessary output messages regarding operating
troubles or other events that should be notified. The only requirements for the use of this
system are a series of input–output devices (specific VDU, PC with emulator, printers, etc.)
that permit the introduction of action–to–take orders in the form of operation commands, and
the output of messages in the form of text lists either on screen or on the printer.
All the commands that can be executed by the system are arranged in different specialized
areas related to subscribers, trunks, charging, etc.

1.
2. A1000 S12 HARDWARE
2.1 The Digital Switching Network (DSN)
2.1.1 Introduction
The key element in the distributed control possible is the Digital Switching Network. This
network is a device that carries out space–time switching, i.e., it transfers the contents of an
incoming PCM channel to another channel time of a different PCM link .
Figure 12 : Space–time switching

LINK 1
LINK 1
CHANNEL 5
LINK 2
LINK 2
LINK 8 LINK 8
CHANNEL 12
The network is used to switch PCM channels that carry speech samples from the terminal
circuits as well as messages between control elements.

1.
Figure 13 : Communication between processors

TCE TCE
SPEECH
SWITCH SAMPLES
SWITCH
ÏÏÏÏ
ÏÏÏÏ ÏÏÏÏ
ÏÏÏÏ ÏÏÏÏ
SWITCH
ÏÏÏÏ ÏÏÏÏ
TCE
ÏÏÏÏÏ ÏÏÏÏ ÏÏÏÏ TCE
ÏÏÏÏÏ ÏÏÏÏ
NETWORK
CONTROL CONTROL
DATA DATA
The network presents a folded structure, that is, all the modules are connected to the same
side of the network and the procedure used to access a module from any other module is
always the same irrespective of the modules involved.
The channels supporting every communication progress through the network up to a

reflection point before they reach their destination.
This structure allows the use of the same basic design for all applications and facilitates
future extensions.

1.
Figure 14 : Communication progress through the network
ÌÌÌÌÌ
SOURCE
ÌÌÌÌÌ
CH X
ÌÌÌÌÌ ÌÌÌ
ÌÌÌÌÌ ÌÌÌ
ÌÌÌ
ÌÌÌ
ÌÌÌ
ÌÌÌ
ÌÌÌ
ÌÌÌ
ÌÌÌ
REFLECTION
POINT
ÌÌÌ
ÌÌÌ
ÌÌÌ
ÌÌÌ
ÌÌÌÌÌ ÌÌÌ
ÌÌÌ
DESTINATION
ÌÌÌÌÌ CH Z
ÌÌÌ
ÌÌÌÌÌ ÌÌÌ
ÌÌÌÌÌ
2.1.2 Digital Switching Element (Multiport)
The network is made up of a series of identical units called Digital Switching Elements or
Multiports. The Multiports are interconnected by 32–channel PCM links.
The multiport has the ability to carry out space–time switching between the channels of 16
incoming PCM links and those of 16 outgoing PCM links. Each incoming PCM link ends at
one of the 16 receiver ports in the multiport, and each outgoing PCM link starts at one of the
16 transmitter ports.
Physically, the multiport is made up of 1 LSI mounted onto a printed circuit board. This LSI
contains 16 receiver and 16 transmitter ports, and is called SWEL.

1.
Figure 15 : Multiport structure
line adaptation (Amplifiers)
ports
PCM link 0 8
. .
SWEL . .
7 15
communication
bus
To facilitate the representation of the network, a multiport is depicted with the ports
numbered 0 to 7 on its left and those from 8 to 15 on its right, without implying any functional
change. Ports 8 to 11 are named ’Low Ports’, and ports 12 to 15 ’High Ports’.
Figure 16 : Multiport representation
0 8 low numbered
ports
1 9
2 10
3 11
4 12 high numbered
ports
5 13
6 14
7 15

1.
2.1.3 Switching in the Multiport
The content of each channel is stored, upon arrival, in a memory when it arrives. At the
appropriate moment it is read to be transmitted towards the correct destination. In this way
the switching network has progressive control.
The first two of the 16 bits in each channel are the protocol bits. If a channel is not to be
switched, the protocol is 00 (CLEAR); on the other hand, if switching is to be initiated
through a channel, these two bits is 01: SELECT command. The remaining bits are used for
different purposes.
There are several types of SELECT command. The first is called “SELECT Fixed Port, Fixed
Channel”. Here, the remaining bits indicate the outgoing port and the outgoing channel. This
data relating the input with the output is stored in a special memory. Once the SELECT has
appeared, the switching step has already bee carried out through the storage in the memory,
using a common bus mainly composed of: four destination port number lines, five
destination channel number lines, and sixteen data lines.
The figure shows a multiport switching scheme. The channel X content is saved in an input
memory. At the time of its creation, the stored protocol is compared against the previous
channel state. If the state is IDLE and the protocol is clear, nothing happens and the state
remains the same. If the state is IDLE, but the protocol is SELECT, the saved channel and
port destination identities are stored in the state memory, and the channel state changes to
BUSY.
On the other hand, if the channel is already BUSY, and the protocol different from CLEAR,
the saved channel content is sent to the addressed transmitter to be stored there in its
output memory (into the word addressed by the destination channel identity). To do this, the
lines of the common bus are used. The channel state remains BUSY.
The arrival of two consecutive CLEAR idles the channel state.
Protocol overview:
- 00 : IDLE protocol
- 01 : SELECT protocol
- 10 : ESCAPE protocol
- 11 : SPATA protocol

1.
Figure 17 : Multiport switching

BUS
RECEIVE PORT
CH X 0 0
1 1
4 TRANSMIT PORT
2 2
OUTPUT MEMORY
DEST.
IDENTITY 0
PORT
VERIFY 1
5
2
DEST.
CHANN. ADDRESS
16 CH Y
31 31
INPUT STATE DATA
MEMORY MEMORY
ÌÌÌÌ
31
DEST. DEST.
STATE
PORT CHANN.
The speech samples representing analogue signals are bytes that are sent as successive
contents of the same channel. The messages between microprocessors are transmitted as
bytes (in some cases 12 bits are used), and sent in the same way. The following consecutive
contents of the same channel will come with a protocol 11 (SPATA) if they are speech
samples, or 10 (ESCAPE) if they are data (message between Ps).

1.
Figure 18 : Communication between processors

MULTIPORT
TCE
CX CX MULTIPORT
MEMORY
CY CY TCE
CZ CZ
µP
ÏÏ
ÌÌÌÌ
MEMORY
8 BITS
10
ÏÏ
ÌÌÌÌ
ESCAPE
µP
16 BITS
MESSAGE TRANSMISION
MULTIPORT
TCE
MULTIPORT
A/D CX CY
TCE
CZ
CI CX
ÌÌÌÌ
µP D/A
8 BITS
11
ÌÌÌÌ
SPATA
µP
SPEECH TRANSMISSION
However, another possibility is the arrival of other SELECTs that are addressed to multiports
located deeper in the network. These SELECTs will be handled as SPATA or ESCAPE. The
multiport will handle all of them the same way, driving the channel contents through the
outgoing channel pointed out in the memory. The situation will continue as described until it
is “cleared” with the arrival of two consecutive CLEAR (00) protocols which will release the
association between the incoming and the outgoing channels.
The selection indicating the output port and channel is too strict and for this reason other
types of SELECT commands are used more often. These other SELECTs may indicate only
the outgoing port, allowing the actual transmitter to choose a channel from those it has free.
This SELECT command is called “SELECT Fixed Port Any channel”.
In the most extreme case, neither the port nor the channel is indicated. For this latter case,
the receiver has stored in its memory the identity of the ports that have at least one free
channel. When one of these SELECT types is used, the transmit port is requested to provide
the identity of the channel that will be used.

1.
Figure 19 : Port memory with free transmit port channels
CHOOSE ONE
RECEIVE PORT CHANNEL TRANS. PORT 8
INPUT STATE
MEMORY MEMORY
0 0
1 1 LOGIC
2 2
SELECTED
CHANNEL
31 31
0 1 8 15
1 TRANS. PORT 15
PORTS WITH FREE CHANNELS

EVERY TRANSM.
PORT WRITES
PERIODICALLY INTO
THIS MEMORY
1 = AT LEAST ONE FREE CHANNEL
0 = NO FREE CHANNELS
This SELECT command is called “SELECT Any port, any channel”. This command chooses
any channel of a port in the set 8–to–15. This allows the progression of the incoming
channel deeper through the network (right side on the drawings). There are other SELECTs
that are used for a very particular case of progression through the network which will be
seen later. These commands are the SELECT “Any Low port, any channel” (any channel of
the port 8, 9, 10 or 11), and SELECT “Port P or P+4, any channel”.
In order to allow for the proper operation of everything seen thus far, every incoming PCM
link contains an alignment pattern in all its zero channels to allow the recognition of the
start of each frame.
The transmitter ports emit this pattern through their zero channels.

1.
Figure 20 : Patterns emitted by the transmit port

0 0
Rx Tx
p q
Tx Rx
0 31 0
Multiport A Multiport B
Pattern Alignement
2.1.4 Network Structure

The switching network is made up of a set of multiports that are connected in such a way
that there is full accessibility between the terminals and the probability of internal blocking is
minimal.
First, we will study the connection of the modules to the network and then, the
interconnection of the multiports.
a. Connection of the modules to the network
The modules are connected through a pair of multiports called Access Switches (AS).
Each PCM link outgoing from the TI is connected to the first port in each AS.
Depending on the traffic carried by the modules, eight or four of them are connected to
two multiports making up a structure called TSU (Terminal Sub–Unit).
In this example, if the modules are subscriber modules, a TSU can contain a maximum
of 1024 subscriber lines.

1.
Figure 21 : TSU structure for subscriber modules

0 8
TO GROUP
MODULE 0 9
SWITCHES
1 10
ACCESS 11
SWITCH 12
13
14
7 15
MODULE 1
0 8
9 TO GROUP
SWITCHES
10
1
ACCESS 11
SWITCH 12
13
MODULE 7 14
7 15
In order to allow the interconnection of modules belonging to different TSUs, ports 8 of

the eight access switches are linked together, using the first eight ports (0–7) of a
multiport as shown in the figure below. This multiport is called Group Switch (GS).This
structure is called TU (Terminal Unit).

1.
Figure 22 : TU structure
ÌÌ ÌÌÌ GS
ÌÌ ÌÌÌ
ÌÌ ÌÌÌ
0 8 0
1
ÌÌ ÌÌÌ
ÓÓÓ
2
ÌÌ TI
ÓÓÓ 1 8
3
4
ÓÓÓ
5
6
ÑÑÑ 7
ÑÑÑ 2 ONLY ONE MULTIPORT
ÑÑÑ
1st TSU 8
IN FIRST STAGE
Ï ÏÏÏ
ÑÑÑ
Ï ÌÌ ÏÏÏ
Ï ÏÏÏ
3 8
Ï ÌÌ ÌÌÌ
ÏÏÏ
Ï ÌÌ ÌÌÌ
TI
ÌÌ ÌÌÌ 4 8
ÌÌ TI
ÌÌÌ
ÓÓÓ
4th TSU
ÓÓÓ 5 8
ÓÓÓ
ÑÑÑ
ÓÓÓ
ÑÑÑ
Ï ÑÑÑ
6 8
Ï ÏÏÏ
ÑÑÑ
Ï ÏÏÏ
Ï ÏÏÏ 7 8
ÏTI ÏÏÏ
Thus, four TSUs form a Terminal Unit (TU). The eight access switches are numbered
from 0 to 7 and connected to the same port number in the GS. AS 0 and 4 belong to
the first TSU, 1 and 5 to the second one, 2 and 6 to the third one and, 3 and 7 to the
fourth one.
b. Interconnection of Group Switches
If there is more than one TU, it will be necessary to interconnect them. This is achieved
with multiports in a second network stage.
Up to eight TUs are connected under a structure named SECTION . A Section is

established by connecting the eight GS in the first stage with another eight multiports in
the second stage, using a multipath–topology.

1.
Figure 23 : Section structure

0 8 0 8
9 1
FROM 1st
TU 0 0
7 15 7 15
0 8 0 8
9 1
FROM 2nd
TU 1 1
7 15 7 15
0 8 0 8
9 1
FROM 8th
TU 7 7
7 15 7 15
1st STAGE 2nd STAGE

SECTION
The algorithm that defines the connection between the 1st and 2nd stages is as
follows:
1st stage multiport no. = 2nd stage port no.

1st stage port no. – 8 = 2nd stage multiport no.
If there is more than one section, up to 16, it will be necessary to interconnect all of
them through a third stage. This third stage must be the last stage, thus all ports are
oriented to the sections. The third stage is made up of groups. Each group is formed by
eight multiports, each of them connected to all sections via one PCM link.

1.
Figure 24 : Network structure

ACCESS 1st STAGE 3rd STAGE
2nd STAGE
SWITCHES
8 0 8 0 8
0 0
0 0 0
1 8
TI 0
7 15 7 15
15
2 8
3 8
4 8
TI 7 5 8
6 8
7 8
0 8 0 8
0
7 7 7
7 15 7 15
15
GROUP 0
SECTION 0
0 8 0 8 0
0 0 0
7 15 7 15 15
0 8 0 8 0
7 7 7
7 15 7 15 15
GROUP 7
SECTION 15
The interconnection of the 2nd and 3rd stages is defined by the following equations:
2nd stage port no. – 8 = 3rd stage group no.

2nd stage multiport no. = 3rd stage multiport no.
2nd stage section no. = 3rd stage port no.
Although one group interconnects all the sections, a maximum of eight groups may be
implemented in order to increase the number of possible paths and minimise the
internal blocking.

1.
The set of sections and groups is called PLANE . As mentioned before, the access
switches of each TU are connected to the plane through port 8. If, due to traffic needs,
more paths must be provided, up to three more planes can be connected to ports 9, 10
and 11 of the access switches (at least two planes are equipped). Ports 12 to 15 are
used to connect the ACEs (ACEs are also connected to ports 4 to 7 for low traffic
TSUs), the Clock & Tone modules and the Peripheral and Load modules.
Figure 25 : Network structure with four planes

SECTION 15 GROUP 7
7 7 7
0 0 0
SECTION 0 GROUP 0
7 7 7
7 15 7 15 15
0 0 0
8 0 8 0 8 0
STAGE 1 STAGE 2 STAGE 3
PLANE 1
9
PLANE 2
10
PLANE 3
11 PLANE 4
TERMINAL
ACCESS
INTERFACE
SWITCHES
The exchange sizing up rules define the number of group switches per plane necessary
for a given number of terminals, while the value of the expected traffic flow gives the
number of planes, bearing in mind that the equipment is identical in all planes and that
two planes are always equipped for security purposes.

1.
Figure 26 : Network growth
1 STAGE 2 STAGES 3 STAGES

TRAFFIC
4 PLANES
3 PLANES
2 PLANES
NUMBER OF
TERMINALS
2.1.5 Network addresses
A network path will be established with consecutive SELECT commands that a control
element will emit through one of the channels that link it to the access switches. This way,
the path will be established gradually, advancing towards the interior of the network up to the
reflection point in order to reach the destination module.
This path will be the shortest possible one, in such a way that, for modules of the same TSU,
the reflection will take place at the access switch, for modules of the same TU at the 1st
stage, for modules of the same section at the 2nd stage and, at the 3rd stage when they
belong to different sections. This means that the number of SELECT commands used will be
1, 3, 5 and 7 respectively.

1.
The following figure shows an example of a path established between the CEs A and B, with
a single SELECT command, that is, the reflection point is at the access switch. The
command used is the following one (on this figure and on the following ones, only the first
plane is represented):
Step (1) – SELECT PORT 4, ANY CHANNEL.
Figure 27 : Reflection at the Access Switch

2
1st STAGE 2nd STAGE 3rd STAGE
TI 0 (1)
0 8 0 8 0 8 0
4
0 0 0 0
4
15 7 15 15
CE A 0 8
4
4
TI 3
8
0 8 0
7 7 7
15 7 15 15
CE B
SECTION 0 GROUP 0
0 0 8 0
0 0
0
15 7 15 15
8 0 8 0
7
7 15
15
15 7 15
SECTION 15 GROUP 7

1.
The following figure shows a path set with 3 SELECT commands, that is, the reflection point
is located in the first stage. The commands used are:
(1) SELECT LOW PORT, ANY CHANNEL

(2) SELECT PORT 2/2+4, ANY CHANNEL
(3) SELECT PORT 2, ANY CHANNEL
Figure 28 : Reflection at the first stage

1st STAGE
(1) (2) 2nd STAGE

3rd STAGE
TI 0
0 8
0 8 0 8 0
2 0 0
0 4 0
6 15
7 15 15
CE A
0 8
4
TI 2
8 0 8 0
2 8 7 7 7
2
15 7 15 15
GROUP 0
(3) SECTION 0
CE B
2 8
6
8 0 8 0
0 0 0
15 7 15 15
1 8 0 8 0
7 7 7
5 15 7 15 15
GROUP 7
SECTION 15

1.
The following figure shows a path established with 7 SELECT commands, that is, the
reflection point is located at the third stage. The commands used are:
(1) SELECT LOW PORT, ANY CHANNEL.

(2) SELECT ANY PORT, ANY CHANNEL
(3) SELECT ANY PORT, ANY CHANNEL
(5) SELECT PORT 7, ANY CHANNEL.
(6) SELECT PORT 1/1+4, ANY CHANNEL
Figure 29 : Reflection at the third stage

(1) (2) 1st STAGE 2nd STAGE 3rd STAGE
TI 0
0 8 8 0 8 0
2
2 0 0 0
6 15 7 15 15
(3)
CE A 0 8
6
(4)
8 0 8 0
7
7 7
7 15 15
15
SECTION 0 GROUP 0
8 0 8
0
0 0
0
15 7 15
15
(7)
(5)
TI 2
2 8 1 8 0 8 0
(6)
1 7 7 7
5 15 7 15 15
GROUP 7
CE B SECTION 15
2 8
5
In order to be able to connect two modules through a path, it is necessary that each module
is unequivocally defined. This is achieved with the coordinates of network addresses,
indicated with the codes ZYXW or DCBA :

1.
Z: Indicates the section number (0–15).

Y: 1st stage multiport number to which its TU is connected (0–7).
X: Lowest access switch number to which its TSU is connected (0–3).
W: Control element number within its TSU (0–7 and 12–15).
Another view of coordinates is related in the following figure:
Figure 30 : Meaning of the coordinates
15
15
8
0 0
15
7 15
ACCESS
TI 2 SWITCH
2 8 1 8 8
1 7 7
5 15
7 15
15
GROUP 7
SECTION 15
CE B
2 8
5
COORDINATE W COORDINATE X COORDINATE Y COORDINATE Z
Input ports to Input ports to Input ports to Input ports to

Access Switch 1st Stage 2nd Stage 3rd Stage
2.1.6 Blocked Paths
As we have seen, the path establishment process is progressive through the network and, to
a large extent, random since the exact path that is going to be selected is not known
beforehand.

1.
When a SELECT command is executed in a multiport, the transmitter port involved sends an
acknowledgement signal to the receiver, provided that the switching can be carried out.
Thus, when executing the SELECT “port P, any channel”, if the transmitter port P has no free
channels it will not send the acknowledgement signal, whereby the incoming channel passes
to the “not acknowledged” state (NACK) , which is memorized at the receiver.
The switching steps that have been established up to the NACK point are then no longer of
any use and the path must be released. For this, the processor that originated the SELECT
command is notified making use of channel 16 of the PCM links parallel to those along
which the path was thus far established.
Figure 31 : NACK sending through the network

2
1
7 SWITCHING
NOT POSSIBLE
TI 4
16 0 8
6 3
5 16
1
µP 6
TRANSMISSION NACK BACKWARDS
T5 WITH NO
FREE CHANNELS
(1), (2), (3): The path is set up to the first stage. At this stage switching is not pos-
sible.
(4): Using backward channel 16 the input channel identity (i.e. 4) is sent
back towards the first stage.
(5): The multiport at this first stage sends back the identity of the input
channel with in channel 16, using the connection related data.
(6): The microprocessor reads this identity and is able to make another at-
tempt.

1.
2.1.7 Tunnels
When a loss of sync occurs at a pair of ports or in the event of a hardware failure, alarm
information is transmitted through channel 0 towards a microprocessor. The arrival of the
alarm is marked by changing the channel 0 protocol from CLEAR to SPATA.
Since this information travels through channel 0 and this channel is not switched using
SELECT commands as for the other channels, switching is performed through preset
hardware switches at every multiport in such a way that the HIGH and LOW ports are linked
together. This association is named Tunnel, meaning that is, whatever reaches receiver port
P at channel 0 time, leaves through transmitter port P+8 also at channel 0 time; and
whatever arrives at receiver port P+8 leaves through transmitter port P. This way, in a totally
equipped network, the alarm information will reach two microprocessors. In these
microprocessors, when channel 0 with SPATA protocol arrives, the channel 0 content is
stored in a specified position of the CE RAM, where the microprocessor can read it.
In the case of a network that is only partially equipped, the alarm may reach only one
microprocessor. If this is the case, the “tunnel” is called cave . However, in some cases of
partial equipment the alarm may not reach any microprocessor; therefore, it will be
necessary to implement enough HW jumpers or cross–links for these paths to be at least
caves so that the alarms can reach at least one microprocessor.

1.
Figure 32 : Alarm Information reaching the processors

CONTROL
ELEMENT
0 8
µP CH 0 CH 0
SYNCHRONISATION
LOST IN RECEPTION
CH 0
7 15
6 14
CH 0
ALARM ALARM
0
CH 0 8
1 9
CONTROL CH 0
ELEMENT
0 8 2 10
CH 0 CH 0
µP
ALARM
CHANNEL ZERO
11 ALIGN. PATTERN
16
SPATA
–SYNCHRONISATION LOST
ALARM
–POINTER: ORIGIN OF THE ALARM
2.2 Generic structure of a module
An A1000 S12 exchange is made up of a set of functional modules linked to each other
through the digital switching network. Each module is formed by a series of circuits that
perform similar functions, whether of a telephonic or non–telephonic type.
Generally, all the modules have the structure shown in the following figure:

1.
Figure 33 : Module structure
MODULE TERMINAL
CIRCUITS INTERFACE
PROCESSOR
&
MEMORY
CONTROL ELEMENT
Two basic parts can be distinguished in the figure: the specific module circuitry which is
specific to each particular case, and the Control Element (CE) . which is common to all
system modules. The latter in turn is formed by a microprocessor with its main memory,
where the main programs that control the module functions are executed, and a device
called Terminal Interface (TI) , which allows the communication between the module and
the other modules in the exchange through the switching network.
There will be modules in the system that have no associated circuitry. These modules are
known as ACEs (Auxiliary Control Elements) and their only relation with the exchange HW
is their connection to the network through the Terminal Interface. Therefore, these modules
will perform support auxiliary functions for the rest of the system. Given their HW
independence, the functions are assigned to these control elements with more flexibility than
to the others, and they may be replaced by others in case of failure. Some examples of
functions that will be carried out by the ACEs are: prefix analysis, charge analysis, trunk
resource allocation, statistics, etc.
We will first study the structure of each of the Control Element parts and then their functions
and the circuits associated with each specific module are discussed.

1.
2.2.1 Terminal Interface
The terminal interface is the component that enables the control element to use the
channels of the network PCM links. Thanks to the TI, a control element will be able to
transmit data packets addressed to another TCE, and also to receive data packets coming
from other control elements.
Another important function of the TI is to accept the two PCM links originated at the module
circuitry (line circuits, trunks, etc.) and establish the port and channel switching towards the
network. All these functions are performed under processor control or, in some cases, are
commanded by the channel content in the same way as the switch works.
The TI employs four pairs of receiver/transmitter ports, two pointing towards the network and
two towards the module circuitry, to perform its functions. There is a fifth receiver port
connected to tone distribution in such a way that a tone can be sent to a line circuit. Each
receiver has two software selectable inputs, one of which (except for port 5) is always
connected to the pair transmitter port, for test loop purposes. This structure is depicted in the
figure below.
The link that arrives at port 5 from the tone generator carries the samples of each specific
tone along fixed channels. Therefore, the emission of a given tone towards a terminal will
simply consist of port and channel switching under the control of the processor. Port 5
receives two input PCM link, and has no transmitter.
Furthermore, the TI includes a 2 or 4 KWord RAM memory called Packet RAM . The
microprocessor uses it for the transmission and reception of data packets. The packets to be
sent are written into a specific part of the RAM, which contains the Select commands for
setting up the path through the network and the data to be transmitted. The data must be 64
words length or less. On the other hand, the receiving packets are not written into RAM
randomly, instead, discrete areas of 64 consecutive words must be used. The
microprocessor uses two specific words from its memory map for carrying out its orders over
the TI.

1.
Figure 34 : Terminal Interface basic structure
T1 R2
R1 T2
TO / FROM TO / FROM
NETWORK
CIRCUITS
T3 R4
R3 T4
TONES A
R5 TONES B
Therefore, the final structure of the TI is as shown in the following figure.
Figure 35 : Terminal Interface structure
T1 R2
ORDERS
R1 AND T2
DATA
PACKETS
T3 R4
R3 T4
2/4
KWORD
R5
MICROPROCESSOR
Before we see how the processor handles the above–mentioned memory, let us enumerate
some of the most important channel states, that is, the possible states of the channels
arriving at the receivers and of those leaving the transmitters. Thus, looking at a receiver, the
incoming channels may be in one of following states:

1.
- FREE: The channel is not switched, and clear protocols are received in each frame.
- PUT TO RAM: The channel content is written into a specific RAM address each time it is
received:
Figure 36 : ’PUT TO RAM’ state
CH X CH X
- CUT THROUGH: The channel is linked to a transmitter outgoing channel:
Figure 37 : ’CUT THROUGH’ state
CH X
CH Y
- RECEIVE PACKET: The channel is receiving a data packet sent by another control
element through the network. Every time this channel time is reached, its content is
loaded into consecutive positions of the RAM starting at a specific initial address:

1.
Figure 38 : ’RECEIVE PACKET’ state
CH X CH X
Similarly, the transmit channels may be in one of the following main states:
- IDLE : The channel is not assigned to any channel of any receiver to establish a
switching step with it, nor is it being used by the processor for data transmission. A
channel in this state sends CLEAR protocols.
- LAUNCH : A channel in this state will launch the data contained in a RAM area starting at
a specific initial address provided by the processor:
Figure 39 : ’LAUNCH’ state
CH X CH X

1.
- FETCH : A transmitter channel in this state will go to RAM to “fetch” (extract) the content
of a single memory position indicated by the processor:
Figure 40 : ’FETCH’ & ’INDIRECT CUT THROUGH’ states
CH X CH X
CH Z CH Z
Using the FETCH state in combination with the corresponding PUT–TO–RAM of a receiving
channel, it is possible to join both channels. This feature is called
INDIRECT–CUT–THROUGH.
- CUT THROUGH : In this state, the transmitter channel is linked to a receiver channel:
Figure 41 : ’CUT THROUGH’ states
CH X
CH Y

1.
The COMMANDs procedure is used to modify the behavior of the channels. The
COMMANDs are orders written by the processor into two reserved memory words and read
by the port whose identity is written into a third register.
Figure 42 : Transmission of orders to Ports
T1 4 R2
R1 T2
T3 3 R4
R3 T4
COMMAND WORDS
O
PORT IDENTITY R5
P P
1 2
ORDER & DIRECTED

PARAMETERS TO PORT P
µ P
1. The micro writes the command code (’o’) and the parameters (’p’) into the com-
mand words.
2. The micro writes the target port id. into a register.
3. Every port periodically scans this register. Only the addressed port is triggered.
4. This port reads the command order (’o’+’p’), and executes it.
With the above–described procedure, the processor will order the transmission of a data
packet addressed to another Control Element:

1.
Figure 43 : Packet transmission

6
CH X
6
ÌÌÌÌ
PACKET
RAM
5
4
01
ÌÌÌÌ 8
ÌÌÌÌ
ÌÌÌÌ
ÌÌÌÌ
COMMAND WORDS
PORT IDENTITY
16
2 3
1
µ P
1. Writing of packet to be sent:
– SELECTs to establish network path
– SOP (Start Of Packet flag)
– Data
– EOP (End Of Packet).
2. Writing of command:
– Launch packet through any free channel
– Memory address where the packet is located.
3. Writing of the identity of the port to be used for the launch.
4. All ports read this register.
5. The “called” port reads the command words.
6. The command is executed by writing the words as successive contents of the chosen
channel.

1.
The packet launched is received, through the network, by the TI of the destination Control
Element. The reception proceeds is as follows:
Figure 44 : Packet reception
SOP
CH X CH X CH X EOP 2 3
4 EVENT
4
PACKET
EVENT CONTENT: FIFO RAM
–PACKET RECEIVED
ÌÌÌÌ
– USED ADDRESS EVENT R. 1
ÌÌÌÌ
FREE
6
5 7
µ P
1 The receiver detects the Start Of Packet indicator, SOP.
2. It looks in a FIFO for the address of a free packet area in the P.RAM.
3. Starting at this address, it writes the successive channel contents (packet).
4. When the receiver detects the EOP, it enters the event into a register:
– Arrival
– Incoming channel
– Address.
5. This situation is recorded in an external register, indicator of ports that have

events. This register is periodically read by the processor.
6. When the processor reads in the register that a receiver has an event, it reads
the event (by executing a command), and finds out that a packet has arrived and
where the packet is in RAM.

1.
7. Finally, the processor reads the packet and registers the packet address as free
in the FIFO so that it can be used again.
In some A1000 S12 System modules, the module circuitry contains a local processor, the
OBC (On Board Processor) . This processor has the asset of being able to send and receive
messages to/from another OBC or another system Control Element, by establishing a path
in the TI as if it were one more network stage.
Figure 45 : OBC – OBC communication

MULTIPORT
CLUSTER TCE
MULTIPORT
CX
TI
CY
OBC TCE CLUSTER
CZ
TI
OBC
MULTIPORT
This is possible because the incoming channels of the TI receiver ports accept selection
commands in the same way as multiport ones do. These commands carry out the operation
called TRANSPARENT SELECTION.
2.2.2 Processor
The processor will be the part of the Control Element in charge of coordinating the module
performance. To achieve this, the processor will basically carry out two types of operations
through the Terminal Interface:
- Set up space–time switching between the channels of the different ports.
- Occupy channels in the outgoing PCM links to send data packets (messages) to other
CEs through the network, or to the actual module circuitry.
The information that goes from the TI to the network through the different channels of the
PCM links, will undergo successive space–time switching steps to arrive at the destination
Control Element through the appropriate channel. There, it will be captured by the processor
(in the case of messages) or switched towards the circuitry of the module in question.
For the processor to be able to carry out its functions, it must be provided with a 1, 4 or
8–Mbyte memory, where the different programs to be executed at any given moment will be
stored.
2.2.3 Physical implementation of the Control Element
Originally, the Terminal Interface occupied a whole board known as TERI, while the
processor occupied several boards, one with the actual processor and several with the

1.
memory. Later, the processor and the memory were integrated into one board called
TCPA/B. Nowadays, the whole control element is contained in a single board of which there
are several different versions:
MCUA : In this particular version, the microprocessor used is the 8086 or a compatible. The
microprocessor is clocked at 8 MHz and addresses 1 Mbyte of memory. In this example the
PBA is used as TCE for subscriber and service circuit modules.
Figure 46 : MCUA structure
TO
TO
NETWORK
CLUSTER
TI
C&T
PROM
RAM
8086
1 Mbyte
PROT. RAM
PROG. CLOCK
INTERR. MEMORY
CONTROLLER. BUS
SERIAL OUTPUT
MCUB : The microprocessor used is the 80386 or a compatible. In System 12, a 4 MB, 8
MB and a 16 MB variant of the MCUB are used. The microprocessor is clocked at 16 MHz. It
is used in some modules (i.e. Peripheral and Load TCE, N7 Digital Trunk modules,..), and
for the ACEs. Besides the larger RAM capacity, the memory bus goes out as a “multimaster”
bus, allowing the MCUB RAM access to be shared with an external processor.

1.
Figure 47 : MCUB structure and RAM sharing
TO
TO
CLUSTER TI NETWORK
C&T
PROM
RAM
80386 up to
16
PROG. CLOCK LOCK RAM
Mbyte
INTERR.
Controller
EXTERNAL
SERIAL BUS MULTIMASTER
INTERFACE CONTROL MEMORY
LINES BUS
RAM
80386
MCUB
RQ
BUS shared
CONTROLLER accesses
BUS
GRANT
RQ
OTHER
PROCESSOR
MCUC : The microprocessor used is the 80486DX2–66 or a compatible. In System 12 a 16

MB, a 32 MB and a 64 MB variant are foreseen. The MCUC is primarily used for ACEs,
especially for the SCALSV.

1.
Figure 48 : MCUC structure
TO
TO
CLUSTER TI NETWORK
C&T
PROM
Cache RAM
8Kb
up to
80486 64 Mbyte
PROG. CLOCK LOCK RAM
INTERR.
Controller
EXTERNAL
SERIAL BUS MULTIMASTER
CONTROL MEMORY
INTERFACE
LINES BUS
RAM
80486
MCUB
RQ
BUS shared
CONTROLLER accesses
BUS
GRANT
RQ
OTHER
PROCESSOR
MCUE : due to the unavailability of 8086 and compatible processors, a new board has been
developed, fully compatible with the MCUA, and used to replace the MCUA in new
exchanges or when existing exchanges are extended, and this for modules such as line
modules, improved service circuits modules, high performance common channel signalling
modules, ... .
The microprocessor used on the MCUE is the 32–bit 80386EX, running at a speed of 25
Mhz. In System 12, an 8 MB version is provided, extendable to maximum 16 MB. Compared
to the MCUA, a performance improvement of factor 4 has been noted.

1.
Note : Although the MCUE has initially been developed to replace the MCUA, and therefore has
been provided with a low speed bus (LSB), the devolpment has been done in such a way that it can
also be used instead of a MCUB. This is valid for modules such as the ISDN Subscriber Module, the
ISDN Remote Interface Module, ...
The following table gives an overview of main characteristics of the existing MCUx’s.
Table 1 : CE Overview
MCUA MCUB MCUC MCUE

8086 80386 80486 80386
8 Mhz 16 Mhz 66 Mhz 25 Mhz
1 Mbyte on board up to 16 Mbyte on up to 64 Mbyte on up to 16 Mbyte on
RAM board RAM board RAM board RAM
Current variants: 2, Current variants: 16, Current variants: 8
4, 8 and 16 Mbyte 32 and 64 Mbyte and 16 Mbyte
serial output serial output serial output serial output
Multiplexed bus HSB/MMB HSB/MMB LSB (special variant)

LSCB (special HSB presently not
variant)
i ) required
i d ((update
d iis
possible)
Note : The name MCUE given to that new module suggests that there should also be another
module, called MCUD. This is indeed the case : the MCUD is a high–performance Pentium–based
processor–board. It is not mentionned in the previous list, because up to now, it is not used in any
EC7.4 SW release.
All MCUx have three LEDs whose meaning is shown on the figure. The fast test is
performed by a PROM stored program which tests the TI, the memory, and the bootstrap
checksum.
If this fast test is successful, the Bootstrap program is started which requests the CE
downloading. If not one of three possible failures is shown.

1.
Figure 49 : MCUx LEDs meaning

X = BLINKING
1
1 = LIGTHING
0 = OFF
1
1
0 LOAD REQUEST
1 OK 0
FAST
TEST
RUNNING
0 END OF LOAD
0 INDICATION
0
OK
0 Bootstrap–
1
1 Checksum X
1 TI failure
0 failure X ACTIVE
0
1
X
0 RAM failure
1
2.2.4 The On Board Controller (OBC)
In many modules, the module circuitry contains its own resident processor which is in charge
of routine and initialization tasks, relieving the Control Element of these functions. For this
On–Board Processor to work, a standardized interface is located in the module circuitry. This
interface is called OBCI (On–Board Controller Interface) and allows for the OBC–TCE
dialogue and the direct handling of channels by the OBC, and also for the dialogue with
other OBCs/TCEs in the network:

1.
Figure 50 : OBC communication
MCUx
OBCI
PCM PCM PCM
LINK LINKS LINKS
OTHER TCEs
OR OBCs
OBC µP
Similar to the terminal interface, the OBCI contains some PCM ports. With in channel
commands sent to the correct OBCI (using an address because more than one OBCI can be
connected in parallel) connections can be established to send data, ... Also connections
towards the OBC processor are possible (the OBC is connected via a parallel bus using
DMA channels to pass data to and from the OBCI).
For packet sending between the TCE and the OBC, it is possible to establish temporary
paths. For call connections (e.g: trunks ) it is possible to make fixed connections which exist
until a release command is given.
2.3 Description of the different hardware modules
2.3.1 The Analogue Subscriber Module (ASM)
Each of the A1000 S12 modules is dedicated to a specific task. The Analogue Subscriber
Module provides the line end circuit for the analogue subscribers.
Each module is made up of ALCN boards (Analogue Line Circuit board type N) and
each board handles sixteen analogue subscribers. The module is composed of eight ALCN
boards, thus serving, 128 subscribers. There exists also a RNGF boards for ring current
generation, the TAUC for testing and the RLMC board for alarms (these PBAs only
implemented in some of ASM modules: two TAUC and two RMLC per rack). All these PBAs
are connected to a MCUA/E type control element via two PCM links. Every two control
elements of the subscriber modules are connected in such a way that each has access to
the ALCN boards of both, and all of these sixteen boards may be handled by one of the two
control elements in the case of failure of the other one. In A1000 S12, this connection mode
is known as CROSSOVER (represented as ’X–OVER’).
Note : Besides the ALCN, another board can be used : the ALCP, which makes also uses of the
latest CLSI techniques, but only provides connections to maximum 8 subscribers. This board was

1.
developed in such a way that it is compatible with ELC technology, and can therefore be used as
replacement of the older ALCB on the E–Rack family. In the following text, we will only refer to the
ALCN. The reader should be aware that the text is also valid for an ALCP.
Figure 51 : Analogue Subscriber Module structure

4
1
0 MCUA/E
A
ALCN
15 B TO THE
NETWORK
16 x 4 = 64
64 x 2 = 128 LINES
8
5
0
A
ALCN
B
15
ASM ’A’
TAUC/RLMC
8 RNGF ASM ’B’
5 MCUA/E
0 A
ALCN TO THE
B
15 NETWORK
16 x 4 = 64
64 x 2 = 128 LINES
4
1
0 PCM LINKS
A 4 Mb/s
ALCN
B
15
The following functional blocks are found in each ALCN board:
1. Input resistance and relay contacts to the test (TAU) and ring (RING) buses, in general:
Input interface.
2. Transmission interface (one per line).
3. Digital signal processing block (analogue to digital conversion). (One block per every four
lines.)
4. MCUA/E interface block. One per board.

1.
Figure 52 : ALCN functional blocks

12,15
4 x 4 = 16 LINES 8,11
4,7
0,3
0 TRANSM.
INTERFACE
INTERFACE
1 WITH THE
CE (MCUA/E)
DIGITAL
SIGNAL
PROCESS. DPTC
2
PCM LINKS
TO MCUA/E
TAU RING
BUS BUS ALCN
The main functions of every block are:
- Input interface
– High Voltage protection (=line protection)
– Relays to connect the line, send ringing current, execute in/outward tests,...
– Resistors to detect off hook and on hook
– Overcurrent protection.
- Transmission Interface
– Couples voice band signals to the line
– Supplies DC current to the subscriber (48/60V)
– 2 to 4 wire conversion.
- Digital Signal Processing
– A/D and D/A converters: conversion of the analogue speech signal into an 8–bit
logarithmic sample and vice versa

1.
– digital and analogue filters
– gain control: switching an attenuation / amplification network into the subscriber

terminal circuit in order to maintain a specified transmission level
– echo cancellation.
- DPTC (Dual Processor Terminal Controller)
– Interface between subscriber terminals and even/odd TCEs
– Control of the line functions upon reception of TCE commands
– Informing the TCEs about HW events (errors, off hook, ...).
The PCM inputs and outputs of the four digital processing blocks are joined and connected
to the processor interface (DPTC) . There, they enter into channel switches that, according
to the appropriate control, associate the fixed channel of each line with one of the channels
of the two PCM links that go towards the two MCUA/Es (X–OVER).
The controls are performed by the control element based on the transmission of messages
through channel 16, which is reserved for this use. The messages are delimited with the
SOP–EOP (Start and End of Packet) flags. After the SOP, a DPTC address byte is used to
drive the message towards a particular DPTC. The data bytes contain codes that are used
to read or write from/into different control registers contained in the DPTC and, significantly,
the bytes of a memory composed of 16 sets of eight bytes each (one set per line), also
contained in the DPTC. Each bit of the bytes in these sets handles a certain control of the
line associated with this set. In order to send the different controls, the bits are transmitted
serial, periodically sweeping the memory, towards the four digital processing blocks and,
from each of these, to the four transmission interfaces. Each line will take only the controls
that are addressed to it.

1.
Figure 53 : Control Paths

X_OVER
DIGITAL
SIGNAL PCM
PROCESSING 4 Mb.
ÌÌÌÌÌÌ ONLY
CHAN. 16
TO / FROM
MCUA/E
0
LINE 1
SERIAL CONTROL OUTPUT
7
REGISTERS
0
LINE 16
7
SERIAL EVEN RECEPTION CONTROL MEMORY
INTERFACE WITH PROCESSOR (DPTC)
- Working principle:
The DPTC contains some registers and 16 maps with data (one map/subscriber). Whenever
something happens (subscriber on hook, ...) it is stored in the correct map (a bit toggle).
Then it is up to the DPTC to inform the TCE. This is done by sending a CH0 alarm which is
received in the Packet RAM of the terminal interface. The SW reads this location regularly to
detect the CH0 alarm in time. Upon detection, the SW sends commands towards the DPTCs
(the CH0 alarm doesn’t explain ’what’ has happened and doesn’t explain ’which’ DPTC
generated the alarm).
When the DPTCs receive this polling command, they will report the events (e.g: DPTC of the
2nd ALCN, the 3th subscriber lifted the handset) This information is also called a mismatch.
All DPTCs have the opportunity to report their events one by one (a cyclic., timed
multiplexed algorithm).
It is also possible to send information towards the hardware. E.g: to switch the relays (to
send ringing current), the SW launches commands towards the correct DPTC to change
data in the map of the correct subscriber (1..16). After that the DPTC sends this information
to a decoder to drive the relays.
Remember:
– The HW informs the TCE about events by sending a CH0 alarm (subscriber
mismatch, HW error or SW error)

1.
– The TCE SW can send commands to the HW and/or retrieve information from the
HW by sending and/or receiving information via CH16.
- The module is completed with a RNGF board for ring current generation. The function of
this board is to generate the ringing signal to send through any of the lines. To perform
this function, the board contains two current generators from which two pairs of wires go
out, each covering 64 subscribers. In each of these boards the ring current is applied or
cut with the adequate cadence, by closing the appropriate relay. For more information
about the ringing, see the chapter of the local call in PART II.
- Rack layout
Given the high integration of each board, up to twelve line modules may be located in a
single rack , connecting the control elements of every two modules according to the
X–OVER method.
Figure 54 : ASM location

X_OVER
RACK TYPE
AIR BAFFLE JA00
Ì Ì
1 2 8 1 2 8
Ì Ì
ALCN
MCUA/E RNGF MCUA/E RNGF
One module occupies only ten of the sixteen slots in each subframe side, leaving six free
slots for other boards and converters. One rack contains two measuring boards, TAUC (one
per side), that depend upon the two control elements of two concrete modules. Each of
these boards sends a measurement bus, that covers all the modules on one side (right or
left).

1.
Figure 55 : Measurement bus distribution
Ì Ì
Ì Ì
Ì Ì
Ì
Ì
Ì
MCUA/E
AIR BAFFLE
Ì TAUC
Ì Ì
ALCN
Ì Ì
Ì Ì
PCM LINK
(X_OVER)
METERING
BUS
The two RLMC PBAs are connected in a similar way, .
- TAUC description
Each TAUC board, used to carry out measurements, is formed by two distinct parts: one that
physically takes the measurement and another one that processes it.
For the physical measurement, the TAUC contains a series of measuring devices and
generators connected to the test bus by relays. The contacts are closed, assigning one
device or another, according to what is written in the interface with the control element
similar to that used in the ALCN boards (DPTCs). To connect the test bus to the subscriber
line, a command is sent towards the correct ALCN to close the relays.The TAUC executes
the measurement and evaluates the result (Digital Signal Processing part). Test results can
be sent to the TCE via a dedicated channel and further on to the maintenance.
Thus a measuring circuit is used to observe the line voltage, for a fixed measurement range,
and to send it, converted to digital, to the control element through the assigned channel. The
measurement will be carried out over the terminating resistance previously arranged for it.
This circuit will serve as an encoder for the transmission of audio signal samples, by closing
the loop with the adequate impedance and fixing the precise range.
In the outgoing direction, the circuit will be able to feed the measurement bus with a
programmable DC or AC voltage by connecting the signal generator, to transmit audio
signals that obey the samples received from the control element through the adequate
channel.

1.
The TAUC may be used to carry out different measurements by performing the appropriate
connections through accurate controls. For example, one measurement that may be taken is
the resistance, RL, between the two wires, a and b, of one of the lines.
In the TAUC, there is a processor that is responsible for the required algorithms, such as the
RL calculation in the above example. This processor is specialised in Digital Signal
Processing (DSP). It is related to the control element through the same interface used in the
ALCN board, the DPTC.
Different types of measurements may be taken, not only electrical but also audio signal
evaluations. Following the figure examples, a program in the DSP generates a signal with
known frequency and power. The signal is sent to the MCUA/E and from there to the line to
be measured (step 1 of the figure). The line pair is deviated to the measurement bus through
which it enters the TAUC where it ends at the simulated ’subscriber’ termination [2].The
measuring circuit takes samples of the signal received, the samples are sent back via the
MCUA/E and re–enter the DSP which evaluates them [3]. Finally, the result is sent to the
control element (MCUA/E)[4].
All test procedures are always triggered by the maintenance software. Therefore the results
are sent to this software at the end of the process.
Figure 56 : Measurement example
CHANNEL ASSIGNMENT MCUA/E
ALCN DIGITAL
1 1
NETWORK
ÌÌ
DPTC
2
ÌÌ ÌÌ
ÌÌ
TAUC
600 Ohm.
1
ÌÌ
3
ANALOGUE PART
MEAS.
CIRCUIT
ÌÌ 3
FREQ. GEN.
1
DSP 3 RESULT
3
4
ALGORITHM MCUA/E
4 DPTC
RESULT
DIGITAL PART

1.
2.3.2 Digital Trunk Module (DTM)
The function of the digital trunk module is to act as interface between a transmission PCM
link at 2 Mb/s and the system internal links at 4 Mb/s, as well as, in some cases, to act as
interface between the signalling used in the trunk and the exchange control.
Figure 57 : Digital Trunk Module
ÌÌ
DIGITAL TRUNK
NETWORK
ÌÌ ÌÌ
DIGITAL
2 Mb/s ÌÌ 4 Mb/s
ÌÌ ÌÌÌÌ
LINK
ÌÌ ÌÌÌÌ
VOICE CONTROL
SIGNALLING
We may find trunks with multifrequency signalling or with signalling through messages
(common channel signalling). All the different trunk modules will have to perform some
common tasks:
- Clock extraction and conversion of line code to binary
In order to read the incoming bits properly, a 2 MHz clock must be regenerated
resembling as closely as possible the one used at the transmitter side. This
regeneration is carried out by a circuit through the observation of the incoming pulses.
If the incoming signal were to present too many consecutive zeros the clock
regeneration would be a difficult task. For this reason, the information is not transmitted
directly in binary, but so–called ’line codes’ are used:
Figure 58 : Binary transmission
1 0 0 0 0 0
?
The line code, HDB3 code in Europe (AMI in USA), consists of the transmission of
three different logical levels (–1, 0, +1). The ’1’s are transmitted alternately as ’+1’ and
’–1’. If more than three consecutive zeros are to be transmitted, the fourth zero is
changed to 1 with the same sign as that of the last coded 1.

1.
Figure 59 : HDB3 transmission

1 0 1 0 0 0 0 0 0 0 0 0 0
1
IS SENT –1 –1
Therefore, it is necessary to reconvert the signal from HDB3 line code to binary at the
receiver side, by performing the inverse task as that performed at the transmitter side.
- Retiming
Each exchange sends data through the transmission link with its own clock, which may
vary to some extent from that of the receiver exchange. Therefore, it is necessary to
perform ’retiming’ or adaptation to the clock signal at the receiver side. This is
achieved through the use of a memory buffer where the data is written according to one
clock, and read according to the other clock. If the difference between the read clock
and the write clock remains for a ”longer time” then using this buffer maximum 1 frame
is skipped or read twice (this is called: SLIP). CCITT allows only one slip in 70 days.
Figure 60 : Retiming
HDB3 / BIN
RETIMED
SIGNAL
ADDRESSES ADDRESSES
RETIMING
BUFFER 1/2
PULSE 2 Mb/s 2 Mb/s 4 Mb/s
MEMORY
SLOPES
WRITING READING INTERNAL
CLOCK LOGIC LOGIC CLOCK
REGENERATION
EXTERNAL
CLOCK
- Frame alignment detection
In the transmission link, the start of each of the 32–channel PCM frames is marked by
the repetitive transmission of an alignment pattern every two frames. Therefore it is
necessary to recognize this pattern in order to detect the start of each frame.

1.
Figure 61 : Frame alignment
PCM ERROR
LINK COUNTER
HDB3 / BIN
LOSS OF FRAME
ALIG. ALARM
FRAME ALIGNMENT DETECTOR
To ensure this recognition, an alignment detector will observe if the pattern is repeated
in channel zero every two frames. The third time that this process fails, the system falls
in the alignment loss state and an alarm is produced.
It is possible that the alignment pattern is not observed where it should be, but if this
does not occur three consecutive times, the system will not fall in the mentioned state.
These error situations are counted and read by the control which, when a threshold is
exceeded, produces an excessive error rate (ERR) alarm.
- CRC4 detection
As an added protection procedure, CCITT recommends the use of the Cyclic

Redundancy Code CRC4, which consists of the elaboration of a 4–bit checking code
taking as input all the bits in eight frames. The code, C1C2C3C4, is sent in the first bit
of the four zero channels that carry the frame alignment pattern in the eight following
frames. This first bit is not used for alignment since the alignment pattern consists of
seven bits only.
The receiver side elaborates its own C1C2C3C4 character every eight frames and
compares it with the one it receives in the eight following frames. With the comparison
result, the receiver side accepts the reception as valid or not, and produces an alarm in
the second case.
Figure 62 : CRC4
FRAME 0 FRAME 7
FRAME 0 FRAME 7
0 0 0 0
CRC CODE C1 C2 C3 C4
C1 F.A.P. C3 F.A.P.
C2 F.A.P. C4 F.A.P.
F.A.P.= FRAME ALIGNMENT PATTERN

1.
a. Modules that handle multifrequency signalling:

Digital Trunk Module Low
The PCM transmission link has its frames organized into groups of sixteen frames
each, called multiframes. The groups are recognized by a specific pattern that travels
through channel 16 of frame 0. The channels 16 of the subsequent frames are used for
the line signalling of two of the link channels: channel 16 of frame 1 for the signalling of
channels one and seventeen, that of frame 2 for channels two and eighteen, etc. Four
bits are used for the line signalling of each channel.
Figure 63 : CAS signalling
ÌÌÌ
FRAME 0
ÌÌÌ
FRAME 1
ÌÌ
FRAME 2
ÌÌÌ 16
ÌÌÌ 16
ÌÌ16
MULTIFRAME
ALIGNMENT
a b c d a b c d a b c d a b c d
LINE SIGN. LINE SIGN.

CHAN. 1 CHAN. 2
LINE SIGN. LINE SIGN.

CHAN. 17 CHAN. 18
These four bits will represent the line signalling variations corresponding to the most
commonly used trunks, in the same way as the E and M pair are used in an E and M
analogue trunk to indicate the trunk status.
Figure 64 : Line signalling
M E
E M
M = + E = + Ready
Ready E = + M = +
M = – E = – Trunk seizure
Acknowledgement E = – M = –
Taking this system as an example, bit ’a’ would be sufficient for the exchange of
signalling.

1.
Figure 65 : CAS encoding
FRAME 1
16
A XXXX
1 M = +
0 M = –
This line signalling method is called CAS (Channel Associated Signalling).
Register signalling (transmission of digits and different dialogue controls between

exchanges), is carried out with different multifrequency signalling systems. The
telephonic events to be exchanged are represented by a pair of frequencies out of a
specific set of, usually, six different frequencies. In order to detect this signalling, it will
be necessary to deviate the channel towards a service module made up of a DSPA
board (similar to the one described in chapter 2.3.4). This board will have the adequate
programs loaded in the DSP, since each service module will be able to receive and
analyze up to 32 channels of up to eight different signalling systems, such as R2, ...
Figure 66 : MF treatment
X 16
ÌÌ
ÌÌ
Y
CAS
MF CODE
ANALYSIS
DSPA
SCM

1.
Figure 67 : Trunk & DSPAs
X Y
Z SCM
X Y A
Z B ANALYSIS
DSPA
A B
X + Y + Z +.......+ A + B = 32
TRUNKS
The outgoing codes to be transmitted are also generated at the service module, from
where they are sent through the network towards the corresponding trunk.
Figure 68 : MF codes transmission
Y DSPA
CODE TO
BE SENT
TRUNK
In the A1000 S12 system, there exists two modules which perform all the different
tasks of the CAS digital trunk mentioned here : these modules are called Digital Trunk
Module Low (DTM–L), and both consist of only one board : the DTUA and the DTUE.

1.
Figure 69 : DTUA/E
2 Mb/s
D T U A/E
DIGITAL DIGITAL
TRUNK NETWORK
The DTUA/E contains the Terminal Interface, the processor and the TCE memory, plus
the typical trunk functions included in a single block.
As shown on the next figure, the board consists of: a digital trunk physical interface
block that contains the adapting and isolation transformers, the loop that allows the
feed–back of the outgoing signal and the circuit to extract the 2 MHz clock (this
extracted clock may be wired with the Clock and Tone modules to serve there as a
master reference –see further–).
The Trunk Access circuit (TRAC) contains, in a single LSI circuit, the logic for
HDB3–to–binary conversion, retiming, frame alignment handling, CAS extraction,
multislot handling and management of the different alarms (Trunk Interface).
The circuits that act as the TI and the actual control element are also located on the
same board. The control element is composed of the processor, its PROM and RAM
memories, and a number of associated circuits (interrupts, clock, etc).
Using the DTUA/E, the processor reads the CAS received for each channel from the
TRAC memory, and writes the CAS to emit. The conversation channels are switched
towards their destination at the on–board TI. This destination may be another trunk, an
analogue subscriber or a service circuit, depending on the current call phase.
The next table gives an overview of the main characteristics of both DTM–L’s. The next
figure shows schematically the layout of the DTUA.
Table 2 : DTUA vs. DTUE
DTM–L
DTUA DTUE
1 PBA = 1 module 1 PBA = 1 module
Single trunk Single trunk
CAS or no signalling CAS or no signalling
Blue Book (CRC4/Ebit) Blue Book (CRC4/Ebit)
8086 80386EX

1.
1 Mbyte 8 Mbyte (up to 16 Mbyte)

2 x QUAP+ POCO 2 x QUAP + POCO
TRAC TRAC
No FW Loadable FW
Not DTRE compatible Not DTRE compatible
No RLMA connection No RLMA connection
No X–over No X–over
Figure 70 : DTUA block diagram
ACCESS CIRCUIT
TO TRUNK (TRAC)
PHYSICAL INTERFACE
WITH THE LINE
HDB3 /BIN
RETIMING
FRAME ALIGN.
2 Mb/s CRC4 TI PART
MULTI–SLOT
ALARMS
8 / 16 BITS
EXTERNAL RECOVERED
CLOCK (2 Mb/s)
TO C&T PROM, RAM

MODULE
8086
PROCESSOR
DTUA PBA
The DTUE is designed as a low cost alternative to replace the DTUA. The functionality of the
DTUA is limited by
- The restricted performance of the on–board processor
- The 1 Mbyte memory capacity
These restrictions are erased with the inroduction of the DTUE. Based on a MCUE (with
80386EX microprocessor) as TCE part and the implementation of minimum 8 Mbyte (up to
16 Mbyte) of memory capacity, the DTUE stands for an increased performance with at least
a factor 3 compared to the DTUA.

1.
The DTUE shalll support both the real mode and protected mode operation by providing the
Virtual Machine Motor (VMM) and the Common CE–SW Interface (CCSI) in one FPROM.
The DTUE will run the same real mode code as the DTUA. This will be realised by the
VMM.In addition a hardware independent CCSI shall be provided for protected mode
operation. This shield avoids direct HW accesses by the SW. This funtion will be
implemented on all new processor boards to avoid SW impact in case of future HW changes
in the processor area.
Figure 71 : Signalling & speech channels path
TI
16 X X MCUA/E ALCN
Y Z
16
0
1
31
CAS
CE
DTUA/E
The CAS digital trunk module (DTM_L), based on the DTUA/E board, are linked to the
network forming high traffic TSUs, that is, TSUs of four modules each. A JH00 rack may
hold up to fifteen of these TSUs. Where such a large implementation is not required, the
DTM–L modules may be located in several positions of other rack types:

1.
Figure 72 : DTM–L physical situation
1 2 3
4 5 6
7 8 9
RACK TYPE
AIR BAFFLE JH
10 11 12
13 14 15 DTUA/E
SWITCH
ÌÌÏÏ Ì ÏÏÏ
ÌÌÏÏ Ì ÏÏ
ÌÌ Ì Ï
RACK TYPE
AIR BAFFLE JB
Ì
Ì
DTUA/E
ÌÏ
ACE
Ï
Ï
SWITCH ISCM
b. Modules that handle common channel signalling:

Digital Trunk Module High.
In common channel signalling, one channel of one of the links that make up a route is
used for the transmission of signalling messages. These messages, conform to CCITT
Number 7 recommendation, may be related to any route channel, that is, to channels of
the same link carrying the signalling or channels of a different link. A route is usually
formed by at least two links for reliability purposes. In A1000 S12, links that do not

1.
carry N7 signalling are implemented with Digital Trunk Module Low as seen in the
previous section.
Figure 73 : Common channel signalling
4
EXCHANGE A EXCHANGE B
SIGNALLING
ANY CHANNEL IN ANY LINK A –B
MESSAGE
CHANNEL WITH SIGN. MESSAGE
The N7 signalling messages have the following structure:
The 64 Kb/s of a signalling channel are organized into frames delimited by two 8–bit
flags. These frames are given a sequence number when sent forward (FSN: Forward
Sequence Number) and recognized backwards on the basis of the said number (BSN:
Backward Sequence Number). The frame data field is used for the transmission of the
actual message. This field contains the following sub–fields: the message length, the
origin, the destination and the trunk and channel identity within the trunk to which the
message is referred (CIC) .

1.
Figure 74 : Number 7 protocol

2 Mb/s
ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ
ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ
0 1 2 3 4 5 6 7
CHANNEL DEDICATED TO SIGNALLING
ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ (USUALLY CHANNEL 16)
ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ NEXT FRAME
ÌÌÌÌ
ÌÌÌÌ
FLAG CRC FSN BSN FLAG LEVEL 2 FRAMES
64Kb/s
8 16 MESSAGE 8
FIRST BIT TO BE SENT

VERIFICATION
CODE BSN
LENGTH FRAME N. RECEIVED

ORIGIN
DESTINATION
BIB: TOGGLED TO REQUEST RETRANSMISSION
CIC: LINK / CHANNEL
CIRCUIT
FSN
IDINTIFICATION
CODE BODY
(LINK & CHANNEL) OF THE
MESSAGE FRAME N IS FORWARDED
FIB: TOGGLED TO INDICATE START OF RETRANSMISSION
A digital trunk with N7 signalling will look for the channel dedicated to signalling at the
beginning of each frame, check its uncorrupted reception (CRC ) and send the
acknowledgement for the frame uncorrupted arrival in the next transmission in the
opposite direction. From the actual message data, the trunk will determine whether the
message is directed to ’this’ exchange or to another one. In the first case, the trunk will
pass the message to the digital trunk module in charge of receiving the link and voice
channel to which the message is referred. In the second case, the trunk will send the
message to the trunk handling the outgoing signalling channel that will reach the
destination point. This function is named Signalling Transfer Point. In the N7 protocol,
all these functions are named MTP (Message Transfer Part) level 3 discrimination,
distribution and routing functions.

1.
Figure 75 : Routing and distribution

DTM HIGH
CH 16
DTM HIGH
CH 16 ROUTING
Destination
CH 16
DISTRIBUTION
DTM LOW
BSN = FSN RECEIVED
ÌÌ
O.K. CIC
BIB = 0, FRAME OK DTUA
– detects the frame (flags) and checks CRC

– if OK, acknowledges uncorrupted reception
– if the destination is:
. this exchange, sends message to the digital trunk that receives
the indicated channel, identified by the CIC indicator (distribution).
. another exchange, sends message to the digital trunk that handles
the appropriate signalling channel (routing).
A continuous flux of ’filling’ frames or FISUs, i.e. frames without data field, is sent
between the frames with data fields (messages), called MSUs (Message Signalling
Units). The FISUs do not increment the FSN field, but may use the BSN field for
acknowledgements.
There are two different types of DTM–H which are capable of handling N7 signalling
messages : the IPTM and the DTUB.
- The IPTM – module :
The IPTM basically consists of two boards : a DTRI and a MCUB. In the first board, the
DTRI, we find the same digital trunk physical interface as the one used in the DTUA,
with the possibility of setting the test loop; and, also, the same Trunk interface with the
common functions of HDB3–to–binary conversion, retiming, CRC4, frame alignment
and multislot service, but without making use of the CAS extraction function. The voice
channels, once time–adjusted and converted from 8 to 16 bits, pass through the TRAC
and go to the MCUB for subsequent routing through the network.

1.
ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ
Figure 76 : IPTM structure
TRAC
2 Mb/s
PHYSICAL
INTERFACE OBCI MCUB
CH X, CH Y
1 2
LIN / OUT
EXTERNAL
CLOCK 3
ILC
4
OBC (386)
ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ MEMORY BUS
RAM DTRI
IPTM
Although channel 16 is usually the signalling channel, there may be as many as four.
The signalling channel passes through the TRAC, also in a transparent manner, but is
switched through the TI, reflected in the Access Switch, sent back through the TI and at
the OBCI towards the ILC.
This ILC circuit (Integrated Link Controller), which is, pre–programmed by the on–board
processor OBC, observes the arrival of the messages (flag detection). The ILC then
passes these frames to a memory and notifies the OBC when this process ends. The
OBC deals with the level 2 & MTP level 3 distribution and routing functions. Therefore
the OBC sends the message through the OBCI, the MCUB and the network to the
DTUA that handles the associated speech channel or to the IPTM that reroutes the
message to the destination exchange (Signalling Transfer Point).
The channel 16 loop is handled in this way to make it common, from a software point of
view, in case an IPTM module handles the incoming signalling channel that is received in
another DTM or when a specific HCCM N7 treatment module is used.

1.
Figure 77 : Message routing and distribution
ÌÌ
CH 16 TRAC
ÌÌ
CH 16
2 Mb/s
Ì
Ì
CH Y
CH X
MCUB
1 2
OBCI CH Y
3
ILC
4
DMA DISTRIBUTION
ÏÏÏ
DMA
AND ROUTING
ÏÏÏ ÌÌ
MESSAGE
CH A
ÏÏÏ
DTUA
DTRI
RAM
LEVEL 2 TREATMENT
MTP LEVEL 3 FUNCTIONS
OBC
IPTM
ÌÌ
CH 16
Therefore, a route with N7 signalling is composed of a certain number of links without any
signalling channel, based on the DTUA board (CAS handling logic omitted), and at least two
links with a signalling channel each (usually channel 16), used to transmit and receive the
N7 messages. These signalling links are based on the DTRI board.
Figure 78 : Route structure
DTUA DTUA
SPEECH CHANNELS
ÌÌÌ ÓÓ ÓÓ ÌÌÌ
IPTM IPTM
ÌÌÌ ÓÓ ÓÓ ÌÌÌ
EXCHANGE A ÌÌÌ ÌÌÌ EXCHANGE B
MESSAGES RELATIVE TO ALL THE

SPEECH CHANNELS IN THE ROUTE
Since the IPTMs (Integrated Packet Trunk Modules) do not handle all the links of a route, but
only those links carrying N7 signalling, only a few of them are implemented. The exact
number of IPTMs that is equipped per route depends on the actual route traffic flow. These

1.
modules are combined into high traffic TSUs, four modules per TSU. Therefore, one of these
TSUs is implemented inside a subframe of the JH rack.
Figure 79 : Rack JH00 look
ÓÓÓÓÓÓ ÓÓ RACK JH
ÓÓÓ
ÓÓÓÓÓ
1
ÓÓ ÓÓ
ÓÓÓ
2 3
ÓÓÓ
ÓÓÓÓ
ÓÓÓÓ
ÓÓÓ ÓÓÓ ÓÓÓ
4 5 6
ÓÓÓÓÓ ÓÓ ÓÓÓ ÓÓÓ

1 15
7 8 9
ÓÓ ÓÓÓÓÓ
MODULES WITHOUT
SIGNALLING (DTUA)
ÓÓ ÓÓÓÓÓ
10 11 12
ÓÓ ÓÓÓÓÓ
ÓÓ ÓÓÓÓÓ
13 14 15
ÓÓ
ÌÌ
ÏÏ
ÌÌÓÓÓ
ÌÌÏÌÓ
ÓÓ
ÌÌ
ÏÏ
ÌÌÓÓÓ
ÌÌÏÌÓ
SUBRACK
ÓÓ
ÌÌ
ÏÏ
ÌÌÓÓÓ
ÌÌÏÌÓ
ÓÓ
ÌÌ
ÏÏ
ÌÌÓÓÓ
ÌÌÏÌÓ
ÓÓ
ÌÌ
ÏÏ
ÌÌ
ÏÏÓÓÓ
ÌÌÏÌÓ
Ì ÏÏ
PBAs
SWITCH
DTRI
MCUB
RACK JF
Ì Ì
Ì Ì
Ì
ÌÌ
DTML (DTUA)
ÌÌ
ÌÌ
DTMH
(DTRI + MCUB)

1.
Where such a large number of trunks are not needed, the DTM–Ls (DTUA) and the IPTMs
may be equipped in different positions of the other racks, such as the JF. These possibilities
are show on the previous figure.
- The DTUB – module :
This module combines MCUB and DTRI functions on one board and offers a second 2
Mbit/s trunk interface for optional use. The reduction of the HW from 2 to one PBA offers
considerable cost improvements.
In the first implementation step (from EC74 on), DTUB will replace the current PRA and
Frame Handling (PHI) applications of the IPTM module. For low end PRA applications, like «
partial » PRA, not making concurrent use of all 30 PRA user channels, the DTUB–variant
with the second trunk interface will offer a further considerable cost improvement.
In further implementation steps (EC75 or later) the one board trunk module could with
comparable, or slightly improved performance replace the present and some further planned
IPTM applications, which require HDLC channels with various protocols (e.g. : IPTM/CCS
and IPTM/X.25). Cross–over configurations and connections to the RLMA cannot be
supported by DTUB bacsue of non–accessability of cluster links.

The next two figures represent the two DTUB variants. The first is called the 1–trunk variant,
having two ILC’s connected to one trunk. In this example the board can terminate up to 4
HDLC–channels for that one trunk. The other is called the 2–trunk variant, having two ILC’s
connected to one trunk each. Here a DTUB can terminate up to 2 HDLC–channels per
trunk.
The following table shows a comparison between both available DTM–H’s.
Table 3 : IPTM vs. DTUB
DTM–H
IPTM DTUB
DTRI + MCUB 1 PBA = 1 module
Single trunk Dual / Single trunk
Nr7, ISDN–PRA, X31, X25 Nr7, ISDN–PRA, X31, X25
Blue Book (CRC4/Ebit) Blue Book (CRC4/Ebit)
80386SX (+80386) 80386DX
4 Mbyte 8 Mbyte
OBCI 2 x QUAP + POCO
TRAC 2 x / 1 x TRAC
2 x ILC 2 x ILC
Loadable FW Loadable Firmware
DTRE pin compatible DTRE pin compatible
RLMA connection RLMA connection
No X–over No X–over

1.
Figure 80 : DTUB –1 trunk
2Mbit trunk DSN
TRK I/F TRAC QUAP 0
DSN
QUAP 1
Tone
POCO
I/F
ILC 1 ILC 2
INTI
SRAM BA
80386 DRAM
(8Mbyte)

1.
Figure 81 : DTUB – 2 trunks
2Mbit trunk DSN
TRK I/F TRAC QUAP 0

1 1
2Mbit trunk DSN
TRK I/F TRAC QUAP 1

2 2
Tone
POCO I/F
ILC 1 ILC 2
INTI
SRAM BA
80386 DRAM
(8Mbyte)
If the processing capacity of the IPTM/DTUB is insufficient to handle the signalling

messages, the DTUA board may be used to deviate the signalling channels to a special
module in a semi– permanent way. This special module is called HCCM (High–performance

1.
Common Channel Module) and is able to handle N7 signalling messages from up to eight
different origins. The structure of this module is described in the following section.
2.3.3 High–performance Common Channel Module (HCCM)
Figure 82 : HCCM structure

DTUA
MCUA/E
ch 16
8
ANY CHANNEL WITH 2

SIGNALLING MESSAGE 1
SLTA
ILC
2 1
FLAG
3
DMA
4 OBCI
ROUTING
AND
RAM
DISTRIBUTION
SIGN.
LEVEL 2 CONTR.
PROCESS (8086)
OBC DUAL
(80186) PORT
MEMORY
RAM
SLTA
The HCCM is composed of a control element and up to eight SLTA boards (Signalling Link
Termination type A). Each SLTA handles one signalling link. With the HCCM, a mucher
higher amount of signalling traffic can be handled : with an HCCM, a total traffic of 8 x 700

1.
MSU/s can be treated, which allows a traffic of almost 1E per link. An IPTM has a much
lower capacity : as the 4 possible signalling links must all be treated by the same OBC, the
total capacity is restricted to 540 MSU/s, for the 4 links together (this means a traffic of
approximately 0.2 E per signalling link).
The signalling channel is conveyed through the network up to the MCUA/E in charge of the
eight SLTAs and, from there, sent by a fixed channel i assigned to each SLTA. Once in the
SLTA, this fixed channel is switched at an OBCI towards a fixed channel of port 1, which is
then received by an ILC. When the ILC detects the frames, it passes them (without the flags)
to a memory by means of DMA.
A dedicated process, known as Signalling Controller, checks the frame uncorrupted

reception (level 2 analysis), and passes the message to a double port memory, notifying the
on–board processor or OBC. The OBC then reads the message and continues the process
according to the message destination address. Therefore, it routes the message towards the
digital trunk (DTUA) that receives the CIC voice channel, or towards the SLTA associated
with the outgoing signalling channel that will be used to reach the destination.
2.3.4 Service Circuit Module (SCM)
This module is necessary for the detection, analysis and generation of the codes of the
different multifrequency signalling systems used between exchanges, for the detection and
the analysis of the multifrequency line codes (DTMF), as well as for the realisation of
multiparty calls.
Figure 83 : Subscriber MF signalling analysis

samples
a/d Service Circuit Module
ch x ch b
fx+fy ALCN
ch a
ch a ch b
ch y
Signalling X
Trunk Present code of
the interexchange
ch i Present code of signalling
subscriber MF System X
DTUA
signalling system
MF code f1+f2 samples
The analysis to find out the multifrequency code present in the incoming channels consists
of the use of Finite Impulse Response (FIR) digital filters. These filters consist on the
application of an algorithm based on the multiplication of a set of samples of the signal to be

1.
analyzed by a set of coefficients or weighting factors. These coefficients are specific to the
frequency which presence is to be confirmed. The result of the addition of all those
successive products provides the instantaneous amplitude value that the frequency being
analyzed presents in the channel.
The more coefficients used, the greater the detection precision, but also the longer the time
required (t = n*125 micros). The use of 128 coefficients is a sensible choice since that
amount is sufficient to comply with the requirements of all the signalling methods.
The receiver will apply the algorithm multiplications and accumulates to find, or not, one and
only one pair of frequencies that present an amplitude higher than a set minimum. It will
carry out this process several times until it accepts the detection as valid for a time longer
than a minimum specified in each system: persistency test.
When multifrequency signalling is used, the Service Circuit Module not only must be able to
analyse the incoming multifrequency signals, but must also be able to emit multifrequency
codes.
Figure 84 : Service Circuit Module

fx+fy
ch i
MF signalling ch a
Trunk
Service Circuit Module
ch j
ch b
ch d
fw+fz
ch c ch b
ch c
SENDING
ANALYSIS
(TRANSMITTER)
(RECEIVER)
The SCM specific hardware has sufficient processing power to analyse the incoming
multifrequency codes of up to 32 input–channels (these codes may be MF as well as DTMF
signalling codes, with a maximum of eigth different sets of frequencies), and emit at the
same time all the multifrequency codes of maximum two different signalling systems (each
signalling system consisting of a set of frequencies in the forward direction, and a set of
other frequencies in the backward direction). This emission is done by placing each fixed
code (e.g. f1+f4) into a fixed channel, dedicating 2 times 15 channels to each multifrequency
system (15 channels for the forward MF signals and 15 channels for the backward MF
signals).
These codes are then to be distributed by the control element to the different TCEs.

1.
Figure 85 : Used channels on the PCM
ch i
S1 S2 Total number of
input channels=
1 15 17 31 32
MCUA/E
ch j
S3 S4 SCM
HARDWARE
1 15 17 31
The whole logic required to handle the thirty–two incoming channels of up to eight
multifrequency systems and to emit the corresponding codes in four sets of fifteen channels
each, is located in a single board called DSPA (Digital Signal Processor type A). This PBA
contains a specialised processor for digital signalling handling named DSP, with its own
RAM memory, a set of programmable FIFOs contained in the queues RAM (64Kx16), and
the queues RAM interface LSI named QRC (Queue RAM Controller).
An On Board Controller (80186 or compatible) controls the queues RAM using the QRC and
handshakes with the DSP.

1.
Figure 86 : SCM structure

DSPA PBA
Queue
RAM
CE 64K x 16
MCUA/E PBA SIGNAL
PROCESSOR
0 31
Queue DSP
TI 0 31 RAM
interface
RAM
MICRO
PROCES-
SOR.
RAM
OBC
PROM 80186
RAM
interrupt
The OBC in the board initializes the queue RAM interface (QRC), assigning one FIFO to
each incoming channel. This FIFO will receive the samples of the code to be analyzed.
On the other hand, a certain RAM area is reserved in the queues RAM for the exchanges
between the OBC and the Digital Signal Processor (DSP), which will carry out the adequate
algorithms. A third RAM area is used for the TCE–OBC message exchange.
The CE sends a message, through channel 16, containing a task performance request. The
message is sequentially written into the queue RAM area that was assigned to channel 16
during the initialization.

1.
Figure 87 : Message to DSPA OBC
Area assigned to
the channel 16
(Message)
CH 16
TI
Message read
by the OBC
RAM Message to the
MICRO OBC:
PROCES- – Request for
SOR OBC
a receiver 80186
– Ch 1, Sign X PROM
CE
MCUA/E PBA RAM
The OBC, using this interface area, assigns a FIFO to the successive contents of the
channel to analyze.
The OBC then writes the task performance request to the DSP, indicating the FIFO and the
MF system, into an exchange memory area. It then interrupts the DSP which will read the
command.

1.
Figure 88 : Task performance request to DSP

Queue RAM
5
CE FIFO N OBC–DSP
ÏÏÏ
memory
MCUA/E PBA interface
Queue RAM interface
CH 1
TI 2 4 DSP
RAM
MICRO 1
PROCES- RAM
SOR OBC
3
1.– OBC command : assign FIFO N to input channel 1
2.– The OBC requests the DSP to run system X algorithm with FIFO N samples
3.– The OBC interrupts the DSP
4.– The DSP reads the OBC command.
In the assigned incoming channel the CE sends the samples to be analyzed. Through the
QRC these are written into successive FIFO addresses. Taking into account the read
command, the DSP runs the filtering algorithm.

1.
Figure 89 : Filtering algorithm running on the DSP
Queue RAM
sample 3
sample 2 Filtering algorithm running

CE sample 1
MCUA/E PBA
CH 1
TI DSP
Queue
RAM
interface
RAM
MICRO
PROCES-
SOR RAM
The DSP, when it arrives at a conclusion, it writes the result into the DSP–OBC interface
zone of the queue RAM and notifies the OBC by means of an interruption. The OBC then
reads the result.
Figure 90 : Algorithm results
CE Q–RAM
MCUA PBA
Q–RAM–ITF
CH 1
TI DSP
RAM RAM
MICRO
INT OBC
The CE sends periodically requests towards the OBC, to ask for results.The OBC prepares
a message, with the result found, in the queue RAM area associated with channel 16. The
message will be transmitted sequentially, through the interface, as contents of this channel
(16).

1.
Figure 91 : Sending of results to the CE
CE CH 16
Q–RAM
Result
MCUA PBA assoc. RAM Msg
Q–RAM–ITF
TI
CH 16
RAM
MICRO
OBC
In parallel with all this, the DSP must be writing, periodically, the FIFOs associated to the
channels outgoing towards the TCE that will carry the different multifrequency codes of the
different systems.
Figure 92 : Writing the FIFO
ÑÑÑÑÑÑÑÑ Queue RAM

CH1, LINK 1
ÑÑÑÑÑÑÑÑ f1+f2. System 1
CH1 LINK 1 ÑÑÑÑÑÑÑÑ

ÑÑÑÑÑÑÑÑ f2+f3. System 1
CH 31, LINK 2
ÑÑÑÑÑÑÑÑ
ÑÑÑÑÑÑÑÑ
ÑÑÑÑÑÑÑÑ
f’5+f’6. System 2
1 2
TI DSP
Periodic
Updating
31
RAM
MICRO RAM
PROC. Queue RAM interface
These writings to the FIFOs must be performed within the appropriate period so that the
FIFO is never emptied, taking into account that the emission period is 125 micros.
Another task carried out by the DSPA is that related to the multiple conference. It offers the
Conference Bridge service for, typically 3 or 5 parties, but with a capacity for up to 10
parties. The speech samples of the different subscribers involved in the multiple conference
are carried to the DSPA, where the DSP adds them and outputs them through different
channels of the link going towards the MCUA/E.

1.
Figure 93 : Conference Bridge

DSPA
ÌÌÌ
ÌÌÌ
Speech A B+C A
B
ALCN A
ÏÏÏ
ÌÌÌ
C
ÏÏÏ
A+C
MCUA/E A+B
ÏÏÏ
A+C
Speech B CA B
B+C
B
ALCN +
DSP
C A+C
Speech C B+C
OBC
ALCN A+B Initialisation
A+B Task Request

The multiple conference may be performed in a simplified way, by simply adding the different
contributions, or in a complex way, by amplifying the weaker signals and not amplifying the
stronger signal at any given moment.
Taking this into account, the DSPA, depending upon the loaded software, may have different
configurations, with different combinations of senders, receivers and conference bridges.
The following table shows some examples of these configurations:

1.
Figure 94 : Possible SCM Configurations
Senders Receivers SCB3 SCB5

60 0 0 0
60 16 0 0
60 32 0 0
45 0 0 0
45 16 0 0
45 32 0 0
30 0 0 6
30 0 10 0
30 0 0 0
30 16 0 6
30 16 10 0
30 16 0 0
30 32 0 0
15 0 0 6
15 0 10 0
15 0 0 0
15 16 0 0
15 32 0 0
0 0 10 6
0 0 0 6
0 0 0 0
0 16 0 6
0 16 0 0
Simplified Simplified
Conference Conference
Bridge for 3 Bridge for 5
Subscribers Subscribers

1.
The Service Circuit Module is a high–traffic module and is therefore arranged in TSUs of
four modules each:
Figure 95 : Service Circuit Module TSU
Access Switch
0 8
DSPA 1
MCUA/E
2
3
4
5
DSPA MCUA/E 6
7 15
Access Switch
DSPA MCUA/E 0 8
1
2
3
4
DSPA MCUA/E 5
6
7 15
The whole Service TSU may be implemented in a single subframe:
Figure 96 : Location in JH00 rack

RACK JH00
SWITCH
ÌÌ
ÓÏÏ
ÌÌ
ÓÓÓ
ÌÌ
ÏÌÓ
ÓÏÏ
ÌÌÌÌ
ÓÓÓ
ÌÌ
ÏÌÓ
SUBRACK
ÓÏÏ
ÌÌÌÌ
ÓÓÓ
ÌÌ
ÏÌÓ
ÓÏÏ
ÌÌÌÌ
ÓÓÓ
ÌÌ
ÏÌÓ
MCUA+DSPA
Same PBAs

1.
2.3.5 Trunk Testing Module (TTM)
This module is used to perform trunk tests for fault detection, and, for periodic checking of
the service quality offered by the trunks. Several operations may be carried out on the trunks
using of this module, which consists of a Control Element (MCUA/E) plus specific hardware.
The TTM will be able to perform measurements on trunks that end in exchanges that,
although not A1000 S12, are equipped with devices conforming to the CCITT
recommendations.
Figure 97 : TTM Module
TTM
CLUSTER
PBAs MCUA/E
Thus, TTM will be able to evaluate the power and noise level of a voice signal received
through any channel of a link, and to generate any type of voice frequency tone in the
opposite direction. The two ends of the link to be measured may ’understand’ each other
through the exchange of multifrequency signalling based on the CCITT Number 5 code
(ATME2 ). This code may be detected and passed to the CE, and also, generated by it.
The CAS signalling is inserted in the unused bits (1 to 4) of each digital link channel, and
switched towards the TTM where it is observed. The following figures show, some of the
TTM test facilities.
On the sender side the TTM function is called DIRECTOR and on the receiving side the
function is called RESPONDER.
The TTM is also capable of executing ”Service Quality Tests”. This test generates a number
of calls to specified directory numbers in remote exchanges.These DNs are called robot
numbers because they do not correspond with a normal subscriber. A robot is nothing else
than an automatic answer circuit which can be an external device connected at MDF–level
or a TTM if the remote exchange is a A1000 S12 exchange. The test result indicates the
number of successful calls (answer).
The test result give a good idea of the service quality of the exchange since the hardware
and the normal call handling software is used.

1.
Figure 98 : In band filters

Digital Trunk
Module
ch x
Trunk DSN
Exchange ’A’
Test equipment
CLUSTER MCUA/E
– Signal Filtering and evaluating
( Typical used Filters: Sofometric

and broad band (400/2800 Hz))
Figure 99 : On demand signal generation

Digital Trunk
Module
ch x
DSN
Exchange ’A’
Test
Equipm. CLUSTER MCUA/E
– Any combination of three tones in the vocal

band with variable power.
– Aleatory Noise

1.
Figure 100 : In–channel CAS and frame alignment tests
ÏÏ
ÏÏ ÌÌ ÏÏÏÏ
ÌÌÌÌÌ
0 1 15 16 17 30 31
ÏÏ
ÏÏ ÌÌ ÏÏÏÏ
ÌÌÌÌÌ
4 1
SYNC CAS Signalling ÏÏÏÏ

ÌÌÌÌÌ
Sample CAS
Digital Trunk
Module CH 1
DSN
PCM CAS
X
Exchange ’A’ Y
CH 0
CLUSTER MCUA/E
ÏÏ
– SYNC Pattern Observation
ÏÏ
ÌÌ
ÌÌ
– CAS Signalling Obervation
Figure 101 : BER and fixed pattern tests
Digital Trunk
ÌÌ Module
ÌÌ
CH P
ÌÌ
DSN
X
Exchange ’A’ 1110111.......11111
Periodic CCITT pattern
or
Z
Fixed data sample
CLUSTER MCUA/E
– Periodic Pattern Check or

– Delivering to the Control Element of the
fixed data sample

1.
Figure 102 : Two wires and V.24–RS232 interfaces

Digital Trunk
ÌÌ
Module
ÌÌCH P X
DSN
Exchange ’A’
CLUSTER MCUA/E
1
2
V24–1 V24–2 16
2 wire interface External
Test Equipment
External Test Equipment

based on PC
Figure 103 : In–channel CAS

DIGITAL TRUNK
CH X
ÌÌÌÌÌ ÌÌÌÌÌÌ
ÌÌÌÌÌÌ
CH X CH 16 4 1
ÌÌÌÌÌ ÌÌÌÌÌÌ
1 1 X CAS
8 8
TTM Processing
CH X CAS
The TTM is also able to check the uncorrupted reception of the frame alignment pattern from
any link (Line Error Rate or LER test). This module can also generate and check the cyclic
patterns to be inserted into a channel to be tested, as recommended by the CCITT, (Bit Error
Rate or BER test); or fix the sample value to be sent through a channel, invariably the same,
and check it at the other end.
Another test that can be performed by the TTM consists of converting to analogue and
offering to the exterior, the signal received through a certain digital link channel. In the same

1.
way, it can offer the contents of a channel to one of two V.24 interfaces for its connection to
the corresponding measuring device.
All of this is achieved using specific hardware based on the DSPA board, practically the
same board as that used in the Service Circuit Module. The only difference is that the DSPA
used here incorporates of an OBCI since without it, it would not be possible to chain the two
DSPAs contained in the TTM to the TCE links.
The module is completed with a MIRB (Modem Interface and Rate Adapter Board) that
passes the contents of a channel to V.24, and a TDAA (Test Desk Adapter Board) which
converts up to six channels to analog. These two boards are optional.
Figure 104 : TDAA / MIRB location
ÌÌÌÌÌÌ
ÌÌÌÌÌÌ
ÌÌÌÌÌÌ
ÌÌÌÌÌÌ MCUA/E
ÌÌÌÌÌÌ
TDAA MIRB
ÌÌÌÌÌÌ
ÌÌÌÌÌÌ
ÌÌÌÌÌÌ DSPA
ÌÌÌÌÌÌ
1 2
ÌÌÌÌÌÌ
1 2 3 6
V–24
Both, the structure and the operation of the DSPA are similar to those of the board used in
the Service Circuit Module, with the before mentioned exception of the OBCI inclusion. This
interface provides the means to discriminate between the TCE messages that are
addressed to one DSPA or to the other, given that these messages start with an OBCI
address that the DSPAs recognize. This configuration makes possible the simultaneous
analysis of up to 30 channels.
2.3.6 Clock & Tone Module (CTM)
This module, essential for the system, is in charge of the generation of the 8 MHz basic
clock that will be distributed to all the multiports and control elements, ensuring the system
synchronism. It is also responsible for the generation of exchange supervision tones as well
as real time. These functions are so important that the module is always duplicated, the two
CTMs working in active/hot–standby mode.

1.
Figure 105 : Clock and tones module

Double distribution
from unique source of clock
Remote Exchange DTUA/DTRI
Selection
Digital
Trunk Double tone
Selection distribution
2Mbps
Clock MCUB
Generation
External Feed Back

References
DSN
Tone Generation CTM 2

CTM 1
Each Clock & Tone Module sends its 8 MHz output signal to the other one. Within each
module, the two 8 MHz signals enter a selection circuit where the same signal is selected by
both modules so that, the two parallel clock distributions end up distributing the same clock
signal. That is, the two clocks reaching all the multiports and control elements are taken from
the same source: the output of the active CTM. The selector changes automatically from one
signal to the other when it does not receive a clock from the selected CTM.
The tones are distributed in parallel to all the control elements. They enter the control
elements through TI port 5 with a fixed channel pattern that is Administration dependent.

1.
Figure 106 : Clock and tone distribution

DSE
0 8
1
MCUA/MCUB 2
CLOCK A 3
TI 4
TONE 5
LINK PCM 5 6
7 15
CLOCK B 8 MHz 8 MHz
TONE
LINK PCM
Tone Link PCM
0 1 2 3 4 31
– Tenth of hours (2 bits)

– Tenth of Seconds – Hours (4 bits) Tone 2 Samples
– Seconds – Tenth of minutes (3 bits) Tone 1 Samples
– MInutes (5 bits)
Each module is made up of the MCUB, the two boards, RCCB and CCLA, for clock
generation, and one DSGA board for tone generation. The DSGA contains the interface
registers used by the control element (MCUA/E) to send and read data to and from the OBC
(8086) located in the RCCB.
The CTM performs a priority–based selection at the RCCB of one reference signal. The
RCCB receives four external synchronization signals at 2 MHz from four exchanges linked to
this one by digital trunks, one atomic clock signal that is the same for all the exchanges, the
oscillator output of the other CTM and its own oscillator output. The CCLA will track the
selected reference signal and, with it, will produce an 8 MHz clock that enters a second
selector that also receives the clock produced by the other module. Both modules’ selectors
are initially set for the selection of one of the clocks, namely the one produced by the module
defined as A by a backpanel connection. Therefore, at power–up, module A will be the
active and module B the hot–standby module.

1.
Figure 107 : RCCB and CCLA structure
MODULE A CCLA 8 MHz
Active
8 KHz 8 MHz
From Digital Trunks

RCCB PLL MCUA/E
+ Priority
1 1
2 2
3 3
2 MHz
4 4
5 8 KHz
6 Selector
ATOMIC Divisor
CLOCK 7
1
OBC OSC
8086
DSGA
TONES
MODULE B CCLA 8 MHz
Hot Stand By
8 KHz 8 MHz
From Digital Trunks
RCCB PLL MCUA/E
+ Priority
1 1
2 2
3 3
2 MHz
4 4
5 8 KHz Selector
ATOMIC 6
Divisor
CLOCK 7
OSC
0
OBC
8086
DSGA
TONES
The two OBCs (A and B) must periodically activate a circuit that supervises the proper
operation of the firmware. If, at the active CTM, this periodic activation does not take place
or, the CCLA stops providing a clock signal, the output selector will automatically switch to
the other input in order to receive the signal produced by the other module, which from that
moment on will be the active one. Given that the two modules’ selectors are joined, the
selector will also switch at the other module for it to output its own clock signal since it is the
active CTM.
If all the external references fail, the OSC (oscillator) output is taken as a reference. Each
module takes the output of the other one as the highest priority reference.

1.
The RCCB and CCLA boards have LEDs on their stiffener whose meanings are indicated on
the figure below.
Figure 108 : RCCB and CCLA LEDs
Fast test
Fast test
FLL Alarm
OBC Alarm PLL Alarm

R Clock outgoing Alarm C
C C
C L
B A
P P
B B
A Voltage to the PLL A
out of range
(BELLOW)
Voltage to the PLL

out of range
(ABOVE)
The output of each CCLA/RCCB pair is sent towards a distribution PBA which is called
CLTD (Cock & Tone distribution). From there the clock is distributed again towards each lead
rack (every tenth rack), in which another CLTD is located (if there are more than 10 racks,
more than one CLTD is needed). From there, the CLTDs distribute the clock signals (both
from the same source) to the other 10 racks which contain RCLA boards for further clock
distribution.

1.
Figure 109 : Clock distribution

Switching or CE PBA
CLTD
JA00
ÏÏÏ ÏÏÏ
ÌÌÌ ÏÏÏ ÏÏÏ
ÓÓ
ÌÌÌ ÏÏÏ ÏÏÏ
Ó
ÌÌÌÌ
ÓÓ
ÌÌÌ ÏÏÏ
ÌÌÌÏÏÏ
Ó
ÌÌÌÌ
ÌÌÌ ÌÌÌ
Distribution
ÌÌÌÌ ÌÌÌ
ÌÌÌÌ
ÌÌÌ
to all CEs and
ÌÌÌÌ
SWITCH PBA inside
the rack
ÏÏÏ
ÌÌÌ
ÏÏÏ
ÏÏÏ
ÌÌÌ
ÏÏÏ ÌÌÌÌ
ÏÏÏ
ÌÌÌ
ÏÏÏ
ÏÏÏ
ÌÌÌ
ÏÏÏ ÌÌÌÌ
ÏÏ ÏÏÏ
ÌÌÌ
ÏÏÏ
ÏÏÏ
ÌÌÌ
ÏÏÏ
ÏÏÏ
ÌÌÌ
JB00
CCLA
ÌÌ
ÏÏ
ÏÏ ÏÏÏ
ÌÌÌ
ÏÏÏ
RCCB
CLTD
RCLA
ÌÌ
ÌÌ JF00
Figure 110 : Clock distribution scheme

Row Lead Rack Any Rack in the same row
ÏÏ
RCLA
CLTD
Active
ÏÏ
ÏÏ
A
RCCB CCLA CLTD PLL
ÏÏ
RCLA
CLTD
ÏÏ
ÏÏ
PLL B
ÏÏÏ
ÏÏÏ
RCCB CCLA B
ÏÏÏ
CLTD PLL A
Hot Stand By
8 MHz
SWITCH or
CE PBAs
The CLTD is simply a distribution board. It may deliver a signal to up to 20 different

destinations using of no special logic except for the logic necessary to detect the absence of

1.
a clock signal. If it detects such lack of signal, it lights up the LED on the board stiffener and
sends an alarm to the rack alarm board which, in turn, sends it to Defence.
Figure 111 : CLTD board

ALARM
INPUT LED ON
1
20
The RCLA board is, somehow, more complex. It collects the signals from the two distribution
buses, re–shapes the pulses and randomly selects one of the two signals. To ensure smooth
switching to the non–selected signal, when required, the RCLA aligns the two signals. This
board uses the selected clock signal as reference for an oscillator that, in an autonomous
manner, tracks it and produces the 8 MHz clock to be distributed to all the multiports and
control elements in the rack.
As you can see in the next figure, the RCLA may produce two alarms. When the second
alarm is produced, the RCLA outputs are blocked and it warns the other board for it not to
reach the same block situation.

1.
Figure 112 : RCLA alarms
RCLA
1
A chain
14
B Chain
Output Blocking
– Difference
between select – There is not reference
and stand–by Report to the pair
branches > treshold – Difference between PLL output PBA in the rack for
and reference > treshold not blocking

– Extreme correction
to the PLL – No PLL output
Alarm 1 Alarm 2
To the Alarm PBA
Chain A clock
input lost
Chain B clock
input lost
Clock output lost
Chain A tone
input lost
Chain B tone
input lost
Chain selection: on(B) – off(A)
The RCLA PBA have three LEDs with the meaning showed in previous figure.
Every multiport or control element receives the two clock signals from the two RCLAs in its
rack and, in turn selects one of them randomly and, using it as reference for an oscillator,
regenerates the 8 MHz clock necessary for the board operation. As before, if the selected
signal is not received, the selector will switch to receive the other one.

1.
Figure 113 : Clock distribution into the rack

Sending to
another PBA 2 MHz 4 MHz 8 MHz MCUA
in the module
Aleatory selection
1 1 14
14
Two RCLA of
sub–rack
RCLA RCLA
The tones are generated by the DSGA board. This board contains the physical interface
between the OBC and the RCCA board, and the control element processor. Therefore,
without this board, the ’clock’ part of the module could not communicate with the processor.
The samples of the different exchange tones, as well as, the controls required for their
orderly reading and transmission through the pre–fixed channel, are stored in a PROM
located on the actual board.
The RCCA OBC writes the Time Of Day (TOD) into a DSGA register every 100 ms., for its
transmission through two fixed channels.

1.
Figure 114 : Tone and Time of day (’TOD’) generation

Tone 1 Samples
Time of Day
Tone 2 Samples
DISTRIBUTION
Tone Link PCM
0 1 2 3 4 31
RCCA DSGA MCUB
Samples
and
control
OBC PROM +
time indication
R
A
M
Micro
processor
Time of day
OBC Bus
Register
The tones are subsequently distributed in parallel with the clock signals via the CLTD and
RCLA boards. Every control element receives the two tones through its TI port 5 and can
choose the appropriate channel of any of the two receivers, to send the required tone
through any of the channels of the transmitter ports in the TI.

1.
Figure 115 : Tone distribution

DSGA Row Header Rack Any Rack in the same row
RCLA
CLTD
1
MCUB
CLTD 1
1 6
20 Clock
RCLA
TI 20 CLTD
1
1
DSGA C&T MODULES
6
20 Clock
MCUB
TI
CLTD
1
Clock Regeneration 5
MCUA
TI 20
The TSAB (Test Signal Analyzer board) is connected to the free MCUB port (3) towards the
module side. This board performs the same test analysis functions as the signal processor
contained in the TAUC board. The TSAB is implemented in the cases where the TAUC is
not; for example, in toll exchanges where it might be necessary to perform some measuring
algorithm concerning tones or announcements.
Figure 116 : TSAB location

MCUB
ÌÌÌÌÌÌ
ÌÌ
CLOCK & TONES
ÌÌÌÌÌÌ
ÌÌ 1
ÌÌ
TSAB
ÌÌ ÌÌ 3
ÌÌ
ÌÌÌÌ
ÌÌ
ch 1
S/P
ÌÌ
ÌÌÌÌ
ÌÌ ÌÌ
DSP ch 1
ÌÌ ÌÌ
ÌÌ
MICRO
PROCESSOR
PROM RAM
ÌÌÌÌÌÌ
ÌÌ
ÌÌÌÌÌÌ
The MCUB processor is related to the signal processor in the TSAB through readings and
writings from/to a RAM. This RAM will also be used to load the program to be executed by

1.
the DSP if it is not in the PROM. The data, signal samples, go through channel 1 of the PCM
link that connects the two boards, the TSAB and the MCUB.
The C&T modules are always equipped in the JF rack at the fixed 001D and 001C network
addresses. The CLTDs used for the distribution towards the ”leading rack CLTDs”, are
located in the same subrack as the CTMs. The first leading rack is the JF00 rack itself, so
another CLTD pair is provided within the rack.
Figure 117 : Clock and Tone modules in the JF rack
RACK JF00
TO OTHER RCLAs IN THE ROW
ÌÌ Ì
ÌÌ Ì
ÌÌ Ì
ÌÌ
CLTD
Ì
CLTD
RCLA RCLA
MCUB CLTD
ÌÌÏÏ ÓÌ Ì Ï ÓÌÌ
C&T ’A’ C&T ’B’
CCLA
RCCB TO OTHER ROW
HEADER RACK
DSGA
TSAB
2.3.7 Digital Integrated Announcement Module (DIAM)
The announcements module is used to send the different messages required to notify the
calling subscribers about certain situations such as, for example, that the called subscriber’s

1.
phone number has changed. This module will also be used to send the time, that is, the
’talking’ clock.
The DIAM consists of a single board called Dynamic Integrated Announcements PBA
(DIAA), whose memory can optionally be extended with the AMEA board.
The announcements are sent to the Clock & Tone Module to be distributed by the tone bus,
if they are fixed announcements; or, through the network towards their destination if, they
are variable. The variable announcements, such as the message giving the new phone
number of a called subscriber, are composed by the control element of the DIAM from
elementary ones.
Figure 118 : Announcements distribution

Fixed Announc.
ÌÌ ÏÏ
DIAA
ÌÌ
Time and
ÏÏÏÏ
ÌÌ
Tones
ÏÏ
MCUA
ÌÌ
ÌÌ
ALCNs
ÌÌ
Varriable Announc.: New subscrber’s number
RCCA
CCLA
5
DSGA
RCLA MCUA ALCNs

CLTD CLTD
0 1 2 3 4 x y 31
time
ann–1
tone–1
–Tone Distribution ann–2
tone–2
For the elaboration of the announcements, the DIAA contains a processor specialized in
signal processing, a DSP; a Queue RAM, where the samples to be sent through each
channel are stored as blocks; and the corresponding Queue RAM Controller, QRC, which
operates similarly to the one seen in the DSPA. The control element is also located in this
same board.

1.
Figure 119 : DIA structure
ÌÌÌÌÌÌ
FIFO RAM
ÌÌÌÌÌÌ ch X
DSP TI
Program
RAM
PROM
Sample RAM
RAM 8086
(4 MB)
DIAA PBA
AMEA PBA
!6 MBytes
With the configuration shown above, up to 524 seconds of announcement time may be
stored in the DIAA and, up to 42 minutes if the AMEA is implemented.
2.3.8 Peripheral & Load Module (P&L)
The P&L module is responsible for all communication between the exchange control and the
peripheral devices, and for the download of the microprocessors equipped in the system. An
exchange is always equipped with two P&L, working in active/standby mode.
Regarding its peripheral functions, the P&L modules handles the MMC system in order to
collect the operation commands and present their results to the operator using the VDU and
printer peripherals. It also controls the access to the mass storage peripherals like tape,
magnetic and optical disk, which contain the programs and data of all the CEs in the
exchange.
Furthermore, the P&L module is responsible for loading the different exchange CEs during
the initial exchange load or later individual reloads.
Due to the importance of this module functions, it is always duplicated and the pair works
in ACTIVE/STANDBY mode. In this way there is always one working, the other being ready
(updated memory) and waiting to take over if the former one fails. Both P&L modules are
connected to fixed network addresses: 000C and 000D.

1.
Therefore, when any control element receives the power (power–on), or it has received a
message from maintenance software forcing its reload, a BOOTSTRAP program (stored in
PROM) will be started. This program sends messages requesting a reload to both P&L
TCEs. One P&L module replies to the requesting CE and reads the software packages
related to that CE from disk, sending it, through the network, to the starting module.
Figure 120 : CE down loading

Load Bid
Control Element Request
RAM A ACTIVE
DSN
ÌÌÌÌ P&L
ÏÏÏÏÏ ÏÏ
ÏÏÏÏÏ ÏÏ
B STAND BY
ÏÏÏÏÏ P&L
Micro
PROM
Reply and
Software Loading
Besides the tasks related to the load of the software, the P&L module is in charge of the
following functions:
– Coordinate the maintenance actions and manage the tests started as consequence
of a corrective or preventive maintenance action.
– Handle the Man–Machine Communication system, in order to receive operation

commands and present their results.
– Control the mass storage peripherals for the performance of the reload, the load of
overlay programs, the charging data collection, etc. These peripherals are: tapes,
magnetic disks and optical disks which will replace the tapes in the future.
– Handle and coordinate the system extensions.
– ...
The structure of the P&L module is shown in the following figure.

1.
Figure 121 : P&L board structure
16 alarms
fire,intrusion,.. alam readings/lamp commands
Inputs
CH 16 MCUB
DPTC
Multimaster
Bus
20 CLMA
RAM
ÏÏÏ
active 8 MB 80386
lamps shared
ÏÏÏ
memory
urgent
alarm
non urgent
alarm
request and
grant lines
MMCA (optional) serial

local chans 80186
SCSI
RAM
ctrller
ROM
FIFO
80186
RAM
PROM DMCA
Magnetic
Disk
SCSI
four more devices Bus
Optical
Disk
Adapt Formater
TAPE
Up to 8
SCSI devices
The module is composed of the control element (MCUB), DMCA board (Direct Memory
Controllers), the CLMA (Central alarm PBA) and, optionally, the MMCA (Man–Machine
Controller).

1.
The MCUB, as the control element, can handle up to eight mass storage peripherals with a
standard interface called SCSI (Small Computer System Interface) and with the support
of the DMCA for the performance of the purely mechanical tasks. The devices may be either
magnetic or optical disks, or magnetic tapes with their corresponding formatters and
adapters to the SCSI. The MCUB can also handle two asynchronous terminals or up to four
of them if one MMCA extension board is implemented. A maximum of two MMCAs can be
equipped per P&L module, allowing the connection of eight more terminals, or else the
terminals may be connected in a ’shared’ mode.
Figure 122 : Simplex configuration
DMCA A DMCA B
MMCA A MMCA B

1.
Figure 123 : Duplex Configuration
DMCA A DMCA B
Request line
4
MMCA A 4 MMCA B
Request line
The figure above shows how to connect two MMCAs with four shared terminals. Although
the diagram shows the connections of only two MMCAs, when four of them are equipped,
the connections are done in the exact same way.When a MMCA is going to work with one
terminal, it activates the request line so that the terminal will be ’captured’ by that side (that
MMCA) and the other side will not be able to close the access relays for that terminal.
The CLMA communicates with the MCUB through channel 16 messages that are collected
by a DPTC interface. This message collection is done in a way similar to that in the ALCN
(line board). When the MCUB sends a message to the CLMA, four bytes are written into a
memory that is later emptied into a control register. This register handles the periodic
erasure of a counter that, when not preset, produces an alarm: Dual failure . This alarm is
wired together with the alarm of the other module so that both CLMAs must fail
simultaneously before the alarm signal is sent to the Main Panel for Alarms (MPA).
The CLMA LEDs have the following meaning:
1. active board
2. urgent alarm
3. non–urgent alarm.
The MCUB can read up to 16 floor alarms (fire, intrusion, etc.) and the status of four keys,
from the main panel (MPA).
Optionally a second CLMA can be connected which will simply receive and light up more
alarms while the ’dual failure’ handling mechanism is deactivated.

1.
The two P&L modules, as well as the two CTMs, are located in the same rack: the JF00
rack.
Figure 124 : P&L into the rack JF00
1st and 2nd (opt)

CLMA
DMCA
MCUB air
baffle
ÏÏ
ÏÏ
ÌÌ
ÌÌ ÏÏ
ÏÏ
ÌÌ
ÌÌ
ÏÏ
ÏÏ
ÌÌ
ÌÌ ÏÏ
ÏÏ
ÌÌ
ÌÌ
ÏÏ
ÏÏ
ÌÌ
ÌÌ ÏÏ
ÏÏ
ÌÌ
ÌÌ
ÏÏ
ÏÏ
ÌÌ
ÌÌ ÏÏ
ÏÏ
ÌÌ
ÌÌ
ÏÏ
ÏÏ
ÌÌ
ÌÌ ÏÏ
ÏÏ
ÌÌ
ÌÌ
ÏÏ
ÏÏ
ÌÌ
ÌÌ ÏÏ
ÏÏ
ÌÌ
ÌÌ
1st and 2nd (opt)
MMCA Access switch
2.3.9 ISDN Subscriber Module (ISM)
The ISDN Subscriber Module is prepared to receive a ’U–interface’ . This interface provides
for the digital transmission and reception to/from the subscriber of two 64 Kb/s channels for

1.
speech or data, and one 16 Kb/s channel for signalling or X.25 packets, using the same pair
of wires of the actual analogue subscribers.
Figure 125 : Basic access diagram

Four wires A1000 S12 EXCHANGE
B B D
S
interface 8 8 4
a
ISDN
NT Subscriber
b
Module
subscriber loop
4
(two copper wires)
2
2
TA
TA
PC
Up to eight terminals can be connected to the subscriber side. They will be connected
directly if they are ISDN terminals, or through a Terminal Adapter (TA) in the case of
non–ISDN terminals.
To allow for the transmission of the 144 Kb/s (the two B plus the D channels) through the
pair of wires, the line codes of three or four levels are used. These line codes are the
’4B/3T’, which sends a ternary symbol representing a four–bit pattern; or the ’2B/1Q’, which
sends a quaternary symbol representing a two–bit pattern. These line codes reduce the
speed to 3/4 or 1/2 of the original speed, depending on the code used. The subscriber
module will be in charge converting this code to binary.
Besides the code adaptation, the subscriber module must also separate the two
transmission directions and cancel the incoming echo.
The line signalling of the eight possible terminals consists of the transmission of messages
through the D channel. Therefore, the eight terminals must ’compete’ for the use of the
available 16 Kb/s available. Conceptually, these messages are similar to the N7 messages
between exchanges. A link level is used to protect the transmission of these messages, i.e.
the messages are sent in HDLC (High–level Data Link Controller) frames of a particular
format called LAPD (Link Access Procedure D). This format allows the transmission or
reception of messages to/from more than one terminal since it contains a terminal identity
field.

1.
Figure 126 : Signalling levels

ISDN Subscriber Internal dialogue
Module
Terminal + TA
ÌÌ ÌÌ
D
Call Control
Dialling
ÌÌ D
Level 2
Level 3
flag CRC DATA control address flag Level 2 Frame
– Terminal identity (1/8): TEI

– Service Type (Signalling or packet): SAPI
speech SETUP
Frame type:
audio 3.1 Type of info establishment or
information or
Called Number receiver ready or
digital
etc.
Calling number
Facilities
Level 3 information
The ISDN subscriber module is made up of eight ISTA/ISTB/ISTC boards (ISDN Subscriber
Termination type A PBA). Each board handles eight subscribers, so the ISM provides access
to a total of 64 ISDN subscribers. In the same way as for the analogue subscriber module,
every two ISMs are connected in crossover (X–OVER).

1.
Figure 127 : ISM PBA composition

TO THE OTHER CE
(Cross–Over)
a
1
b
8
ISTA/B/C
MCUB
8
ISTA/B/C
8 x 8 = 64 Subscriber loops
1. The ISTA board, which is used when the U–interface uses the 4B/3T coding,
almost contains the same circuits as the DTRI board used in the N7 trunk module. Thus, we
have the ILC for the partial handling of level 2, and the OBCI as the local space–time
switching element. These circuits plus the UIC (U–Interface Controller), which performs the
above–described functions of code adaptation and echo cancellation, make up the ISTA
board (see figure 128).
Each UIC receives clock signals (channel time strobe) that it uses to order its output.
Four ILCs, each with two HDLC frame handlers, are programmed by the OBC to check if
there are frames, delimited by flags, in the eight possible D channels: ILC1 will check the
first D channel and the second D channel, and so on. When one HDLC in one ILC finds a
frame, it puts it in memory and notifies the OBC. The OBC then analyzes the level 2 fields
and eventually responds by extracting the signalling message and sending it, through the
OBCI, to the control element (MCUB). At the request of the CE, the OBC drives the
switching of the speech channel in the OBCI.

1.
Figure 128 : ISTA structure

ch1: B1 OBCI
7
7
4B/3T
0
T/4B
clock sending
UICs 1 2 3 4 to CE
ILC ILC ILC ILC
– Echo cancellation
– Decodig to binary
V* Interface
found
frame
1 2 3 4 5 6 7 8 ...............32 – Level 2 Analysis
–Level 3 extraction
found
B1 B2 B3 B4 .............. – Ordering of
frame
D1 D2 PROM switching the
speech channels
OBCI switching
RAM
OBC
2. For the 2B/1Q line code, a similar board, differing only in respect of the UIC LSI,
has been designed. This board is named ISTB.
3. Recently, a new board has been developed : the ISTC, which can be used for
both 4B/3T and 2B/1Q coding.
This card exists in different hardware variants
ISTC–T –—–> 4B3T coding for the U–interface (replacing the ISTA)
ISTC–Q –—–> 2B1Q coding for the U–interface (replacing the ISTB)
ISTC(+)–T –—–> 4B3T coding for the U–interface (replacing the ISTA)
ISTC(+)–B –—–> 2B1Q coding for the U–interface (replacing the ISTB)
(ISTC(+) supports HDLC tunnel.)
Compared to its predecessors, this ISTC is an enhanced ISDN board in terms of use of state
of the art technology leading to increased performance. In line with cost control, technical
improvements are introduced: technological progress, corrections needed to meet changed
standards and functionality.
To cope wuth these new features, memory size is increased allowing more OBC–code and
software resources, but also the ”double memory” feature for future support of ’software
replacement with Zero Outage Time (ZOT) and Stable Call Preservation (SCP)’.

1.
The functional enhancements are
1) compliance to newest standards of ETSI
2) Support of Zero Outage Time (ZOT) and Stable Call Preservation (SCP)
3) HW Identification
4) HDLC Frame concentration function for B–channels

Because of ISDN subscriber demands for internet, there is an increasing demand for
HDLC frame handling no longer only on D–channels but as well on B–channels. Up to
now we handled packet traffic on B–channels circuit switched. This strategy must be
extended because of internet calls are characterized by other/new traffic values. Those
are
– in average a much longer call holding time a low average data rate (compared
to 2*B–channel bandwidth)
– an unbalanced average data rate from subscriber to network compared to from

network to subscriber
– traffic peaks using the complete bandwidth to one subscriber
Because of those characteristics a frame concentration function shall be implemented,

which allows concentration of packet traffic from several (amount is traffic dependent )
B–channel to a single 64 Kbit/s channel on a cluster link. In average a concentration
factor of 8 is envisaged.
Therefore each B–channel shall be terminated by a HDLC controller.
5) HDLC Tunnels and Cluster Bus Contention Mechanism

The basic characteristic of a HDLC–tunnel is, that it provides between two modules of
A1000–S12 and across the DSN a permanently established 64 Kbit/s channel, which is
terminated on both ends by a hardware HDLC controller.
Examplary an HDLC–tunnel can be accessed on the cluster bus of subscriber module

by multiple (OBC–)processors (sharing the same channels), while it ends on the other
side in a single processor, which handles the concentrated traffic.
2.3.10 Mixed Subscriber Module (MSM)
Besides the Analogue Subscriber Module (ASM) and ISDN Subscriber Module, a third type
of subscriber module exists, which consists of a MCUB, and a number of ALCx and ISTx,
allowing to connect to the same module a number of analogue and/or ISDN subscribers.
2.3.11 ISDN Trunk Module (ITM)
The subscriber access previously studied provides only two channels for speech/data at 64
Kb/s and is called basic access. For high traffic subscribers such as an ISDN PABX, a

1.
different access, called primary access, is used. This access is based on a digital
32–channel PCM link where one channel is reserved for the signalling of all the others.
Figure 129 : Primary Rate Access
31 X 16 0
SIGNALLING CHANNEL:
– Sending of point to point LAPD frames

TEI = 0, SAPI= signalling
with signalling messages related to the
rest of the channels
In the A1000 S12 system, the module that receives such interface is the ITM. This module is
made up of a DTRI and an MCUB board, identical to those used in the N7 trunk module but
with different software. The ITM boards contain the software required to handle the ISDN
levels two and three.
Figure 130 : IPTM functions in PRA
CH X
CH X
CH Y
TRAC
CH 16
SIGNALLING
MESSAGES
– HDB3 / BIN LEVEL 3
TREATMENT
– RETIMING
ILC
– FRAME ALIGNEMENT LAP–D MCUB
TREATMENT
FRAMES
– 8 / 16 BITS
PROM
OBC
RAM 386 DTRI
LEVEL 2 ANALYSIS

1.
2.3.12 The Data Link Module (DLM)
The A1000 S12 modules do not support modem connections (e.g: HCCM, IPTM, ...) When
an analogue modem connection is required (e.g: connections towards an Electronic Data
Processing Centre (EDPC) through the Packet Switching Network (PSN), analogue N7
connections, ...), an additional module is used: the Data Link Module.
The Nr7 message is prepared in the HCCM (or IPTM) module. From there it is transmitted
towards the DLM module which is connected to the modem using a V24 functional interface.
The DLM is composed of two PBAs: the MCUA/E and the MIRB. The MCUA/E contains the
CE and the TI. The MIRB PBA is responsible for the physical data transmission to the
EDPC.
ÌÌÌ Figure 131 : Analogue N7 connection
ÌÌÌ DATA TO BE SENT
ÌÌÌ
ACE
DLM
IPTM X.25 modem
MCUA/E MIRB
modem
DTE1
DTE4
modem
X.25 PKT LAPB
ÌÌÌ
GENERATION
ÌÌÌ X.25 PACKET
ÌÌÌ
DCE
PSN
2.3.13 EPM: Extended Peripheral Module
Extended Peripheral Module (EPM) provides the means of interworking between S12 and
Local Area Network (LAN), which is combined with TCP/IP on transport and network layer
and 10 BaseT Ethernet on data link layer and physical layer.
As a node in a local area network (LAN) which uses 10 BaseT Ethernet as a backbone,
EPM allows S12 to interconnect with all nodes of a LAN by means of TCP/IP protocol. The
advantages of developing EPM module is that :

1.
- By using TCP/IP functions in EPM, as an interface between S12 and LAN, application
programs can be developed on the WSs/PCs
- Because of the powerful tools and libraries to design graphic user interface (GUI) with a
workstation, such as X windows, MOTIF, Sunview, etc. S12 programmers can develop
user friendlier interfaces
- An alternate for S12 to provide other I/O channel devices. For example, the network
measurement data or the charging data can be sent directly to a workstation or a PC
disk. I
- High speed transmission channel toward PC/WS, compared with RS232.
The EPM module will be implemented as a system ACE in phase 1. More than one EPM
module is possible in one exchange which act as nodes for different LANs. The number of
EPM modules depends on the traffic load of various applications. The maximun traffic load
per EPM will be evaluated during testing.
An interesting board in the EPM is the LAN Module Controller (LMCA) PBA. This PBA
interfaces to a twisted pair ETHERNET LAN (10baseT) external device or HUB. It will be
used in the S12 EPM for LAN applications. The PBA–LMCA environment in the S12 system
is presented in the next figure.

1.
Figure 132 : LMCA
TERMINAL
INTERFACE
TERMINAL PART
CLUSTER DSN
INTERFACE
BUFFER
PROCESSOR
DEMUX MMB/HSB
ETHERNET
I/F LAN
PROCESSOR
MEMORY
PART
SERIAL INTERFACE
LMCA
The processor (D229) is a 32–bit Intel 80386 compatible microprocessor
The memory includes up to 8 Mbytes of on–board memory.
The ETHERNET LAN interface circuits comprise the following areas:
- Serial network interface controller (SNIC). The serial network interface used in
PBA–LMCA is NS DP83902 (Serial Network Interface Controller, SNIC) D1701. It
provides a comprehensive single chip solution for 10BASE–T IEEE 802.3 networks.
- Address ID PROM. This is used to store a unique network address.
- Buffer memory. The buffer memory (D1601,D1602) is used for temporary storage of
receive and transmit packets.

1.
- I/O ports . The I/O ports are the buffer which interface between processor and SNIC.
- 16/32 Bit data Bus buffer. The data bus buffers (D1604 and D1607 or D1613 and
D1616) are used for 16–bit bidirection data transfer.
- LED Indicator. These LEDs are used to indicate the status of LAN chip.
2.3.14 ISDN Remote Subscriber Unit (IRSU)

ISDN RSU Interface Module (IRIM)
The IRSU is a mixed analog/ISDN telephone line concentrator, designed for use in both rural
and urban environments. Subscribers connected to an IRSU receive the same services and
facilities as if they were connected to a subscriber module.
An IRSU allows the remote connection of up to 976 analogue subscribers, 480 ISDN
subscribers or a combination. The proportion of analogue and ISDN can be varied to meet
changing requirements, using the ratio of one ISDN to two analogue subscribers. Several
IRSUs can be connected to an A1000 S12 exchange, which is called the multidrop
configurations. This multidrop configuration consists of a maximum of eight IRSUs, providing
access to up to 1024 analogue or 512 ISDN subscribers or a combination. The interface
module used in the A1000 S12 exchanges is the so called IRIM. The actual interface is
realised with digital links.
Figure 133 : IRSU point to point configuration

IRSU
Up to
976 Analogue
or PCM LINKS IRIM
480 ISDN
subscriber
A1000S12

1.
Figure 134 : Multidrop configuration

UP TO 1024 OR 512
IRSU IRSU IRSU
1 2 8
IRIM
The multidrop configuration can be easily extended till the maximum number of 8 IRSUs by
adding new IRSUs. The dialogue between the IRIM and each IRSU in the multidrop is based
on the control of a series of multiplexers , named K1 and K2. These multiplexers make
possible the isolation of the IRSU (e.g. when the feeding fails), or the closing of the loop
from one IRSU on, as well as, the option to insert messages or not into channel 16, or letting
the messages addressed to another IRSU or to the IRIM pass through.
Figure 135 : Multiplexers in the multidrop configuration
K2 (LOOP)
CH 16
IRIM
LAST
IRSU K1 (BY PASS)
ALL
CHANNELS MIO DATA
CH 16
ÌÌÌÌ
LOOP
CH 16
CONTROL
ÌÌÌÌ
IRSU 8 IRSU 1 IRSU
TOKEN
K2 ADDRESS
IRSU TO IRIM
IRIM TO IRSU

1.
Let’s suppose that the K1 and K2 muxes are in the position shown in the figure. The channel
16 loop mux is in the position that lets channel 16 go forward to be transmitted by the IRIM.
After the complete loop channel 16 will come back to this mux.
Using the token and the address field in the signalling frames, the IRIM starts the procedure
to exchange data in the multidrop. The token is passed in a circular way and only the IRSU
which has the token can send CCS Nr7 messages to the IRIM and at the same time, receive
MSUs from the IRIM.
Both the IRSU and the IRIM consist of several specific boards, mainly the DTRH or the
digital trunk,the CALC for the simplified clock and alarms; the control element board (MCUB)
in the IRIM, the subscriber PBAs (ALCN and /or ISTA/B) in the IRSU, with the addition of the
RNGF and the TAUC PBAs for ringing and testing functions. Furthermore, the optional
boards for transmission, the TMIA and LPFA, can be added.

1.
Figure 136 : IRSU structure at PBA level

32 ALCN / ISTA + RNGF + TAUC
HIGH LINES
LAST IRSU
OBCI TRAC
CLOCK
TMIA AMPLIFIERS
K1
OBC OBC ILC

K2
CALC DTRH
TMIA
OBCI
CLOCK TRAC
OBC
OBC
ILC
CALC
DTRH
32 ALCN / ISTA + RINGF

LOW LINES
ÌÌÌÌÌ ÌÌÌÌÌ
STANDARD PCM TANSMITION EQUIPMENT
TWO PCM LINKS
TRAC TRAC
OBC OBC
DTRH DTRH
OBCI OBCI
IRIM
X_OVER
MCUB MCUB
TI TI
The DTRH board has the following structure:

1.
Figure 137 : DTRH PBA structure
OBCI
CH 16
2 Mb/s
CH 16
CH 1
CH 1
LOOP
ILC CONTROL
OBC
USART 256 K 1K
80386
PROM RAM
DTRH
V24 TEST INTERFACE
First we find the same physical interface (transformers and loop) used in the DTUA and the
DTRI and also the same trunk interface circuit for HDB3 binary conversion, retiming and
frame alignment handling. Then we find a PCM link at 4 Mb/s (16 bits/channel) that goes to
the OBCI. In the OBCI, channel 16 is switched towards the ILC to monitor the messages.
Also the multiplexer is shown via which the CH16 loop can be opened or closed (see
explanation before).
On the other hand, the CALC board (Clock & Alarms) contains a simplified clock circuit that
produces the internal clock, using the 2 Mb/s clocks regenerated from the PCM links. These
reference clocks are sent by the clock regeneration circuit contained in the physical interface
circuit of each DTRH. This board is duplicated in each IRSU. Each CALC controls the clock
to be selected (choice between their own or the partner clock). In that way, only one single
clock is distributed. In each CALC, the selected clock is supervised, and a switching is
performed in case of failure.
The CALC also contains the logic required for the handling of the alarms and the control of
the TMIA loops.

1.
An 8031 processor collects the IRSU alarms (converters, etc.), writes alarm indicators, and
reports changes to SW in the host. The processor handles the TMIA loops, through a
’programmable interface’ contained in a chip, and also controls the ring current and its
assignment to one of the board by closing the appropriate relays.
It must be clearly understood that, with this architecture, the call and the PCM link channels
used are under the control of the IRIM control elements (MCUBs). A possible call scenario
could then be as follows:
Figure 138 : Call Handling simplified scenario for IRSUs
5
ALCN
DTRH DTRH MCUB

1
Ì ÌÌ
DPTC CH 16 X Y
Ì ÌÌ
O O
B B TONES
4
C C
I I
2 3
OBC OBC
4
2 DTRH DTRH
CH 16
O O
B B
C C
I I
3
OBC OBC
1. The related DPTC line collects the hook off event.
2. This event is read by both OBCs of the two DTRH PBAs

3. Using the token protocol, both OBCs send a message containing the event to the
mate OBCs in the IRIMs
4. These OBCs, knowing from the message content that the related line is a high one,
transfer the event to the high MCUB (if it is on line).
5. The MCUB software selects a speech channel (’Y’) in the MCUB DTRH link, and
another one (’X’) is selected in the PCM link towards the IRSU. In the DTRH, both
channels are joined, allowing the tones to reach the IRSUs over this path.
The IRSU is informed of this speech channel assignment by a channel 16 message.
The Call Control software continues, using this strategy, with a message flow
IRSU–IRIM, and vice versa, to perform the different Call Control decisions in the host
exchange.

1.
To increase the traffic capacity of the IRSU multidrop, calls between subscribers connected
to the same IRSU are switched internally (within the IRSU), whereas calls between
subscribers connected to different IRSUs on the same multidrop are switched locally, using
only a channel of the PCM link in each direction for each call.
In case the communication between the IRSU and the host exchange is lost, the IRSU will
be switched to stand–alone mode. Functions to be performed depend on whether an
optional Emergency Call Feature (EFC) is equipped or not. If so, up to 23 stable calls
between subscribers connected to the same IRSU can be handled.
If required by the traffic, the number of available PCM channels can be doubled by
duplicating the number of PCM links. To do so, the DTRF board is used instead of the DTRH
as the former has two PCM links.
Figure 139 : DTRF PBA structure

LINK 1 TRAC OBCI
LINK 2 TRAC OBCI
LSCM
OBC
RAM
ILC
DTRF
With this, the IRSU structure would be:

1.
Figure 140 : IRSU structure using DTRF PBAs
ALCN/ISTA
CALC DTRF DTRF MCUB
DTRF DTRF MCUB

CALC
ALCN/ISTA
IRIM
IRSU
The IRSU contains maximum 61 ALCNs or 60 ISTAs, as the ALCN boards may be
substituted by ISTA boards (some exceptions for some positions). In case of maximum
capacity (976 analogue lines or 480 ISDN subscribers), one IRSU is placed in half a JR03
rack, occupying three subframes (shelves). One rack may hold up to two IRSUs, the
transmission equipment being installed separately.

1.
Figure 141 : IRSU Rack distribution and IRSU alternatives
ALCN
1 16 1 16
Ñ
ÑÓ
ÏÌ ÓÏÌ Ñ
Ñ
1 14 1 15 TAUC
ÏÓ
ÑÌ ÓÏÌ Ï
ÏÓ
ÑÌ ÓÏÌ Ï
ÏÓ
ÑÌ ÓÏÌ
AIR BAFFLE
ÏÌ
RNGF
Ì
Ì DTR M/F
ÌÓ
– TRANSMISSION EQUIPMENT
Ó
Ó
– BATTERIES CALC
CONVERTERS
480
ISDN LINES
240
FRAME WITH 3 SHELVES
112 FRAME WITH 2 SHELVES
FRAME WITH
40 1 SHELF OR
CABINET
24
32 64 96 256 512 976

ANALOG LINES
The TMIA and CALC boards have some LEDs and keys on their stiffener that have the
following meaning:
Remark: Going signal = from previous IRSU and Back signal = from next IRSU.

1.
Figure 142 : CALC and TMIA PBAs

Urgent Alarm Pass done
Going signal lost

Non Urgent Alarm
Back signal lost

Sanity Timer Expired
”By pass” mux switch

Loop mux switch
Loop bypass activated

Loss of synchronisation
CALC Loop done
2.4 Remote Terminal Sub Unit (RTSU)
In addition to IRSUs, and in particular for larger subscriber clusters, it is possible to optically
remote entire parts of an Alcatel 1000 S12 exchange, including some subscriber modules
and their access switches to the Digital Switching Network. These segregated parts are
named RTSU (Remote Terminal Sub Units), which can be equipped with one or more
analogue or ISDN TSUs – Terminal Sub Units–, linked to the host by means of optical fiber.
As explained in previous chapters, every subscriber TSU is composed of up to eight

analogue or ISDN modules connected to ports 0 to 7 in two Access Switches. Further
modules (Auxiliary Control Elements, P&L TCE, C&T TCE, etc.) can be connected to ports
12 to 15. The Access Switches use ports 8 to 11 to connect to the group switches in planes
0, 1, and optionally 2, and 3. The figure shows an example of these TSUs for a four–plane
DSN.

1.
Figure 143 : ’TSU structure’

SUBSCRIBER 0 8
9
MODULE 0 1 10
ACCESS
11
SWITCH
12 N 8
13
9
14 10
SUBSCRIBER N 1
7 15 ACCESS 8 11
9
MODULE 1 SWITCH 12
1 10
N ACCESS 8 11 13
SWITCH 9 12 14
1 7 10 13 15
N ACCESS 8 11
14
SWITCH 9 12
7 10 15
0 8 GROUP 13
11
9 N+4 SWITCH 14
12
1 10 7 15
ACCESS 11 13
SWITCH 12 14
SUBSCRIBER 15
13
14
MODULE 7 7
15 0
PLANES
1
2
NOT SUBSCRIBER
NOT SUBSCRIBER
NOT SUBSCRIBER
NOT SUBSCRIBER
MODULE
3
MODULE
MODULE
MODULE
If, as in the above TSU example, subscribers are located in a remote area, an RTSU can be
used to provide telephone access to these subscribers. The figure represents a scheme of
that possible configuration.
Figure 144 : Remote Terminal Sub Unit

REMOTE AREA HOST SITE
MODULE 0
ACCESS
SWITCH Optical 1
MODULE 1 Fiber 1
1 7 0
7
GROUP 1
SWITCH
7 2
3
ACCESS
SWITCH
MODULE 7
The concept of RTSU –remote subscribers and optical links– makes possible to spread
subscriber lines of an exchange to be spread over a vast area, entailing copper pair cost
saving and allowing long distances from the subscriber cluster to the host exchange. All
these remote subscribers are offered the same functionality as the local ones.
In case of isolation, due to a link failure, the RTSU must make it possible to set up internal
calls. Therefore, for MF analysis purposes, some SCMs are equipped in the RTSU. Another

1.
feature of the RTSU is the possibility of connecting a VDU to it for on–site Operation and
Maintenance purposes.
The link to the host is realised by extending all the 4 Mbps PCM links between the access
switch and the group switch in the first stage of the Digital Switching Network. Every Access
Switch offers a 4 Mbps link to every equipped plane in the host. These links are multiplexed
at both ends using one or more multiplexers, which are implemented as standard Alcatel
1000 S12 PBAs. These multiplexers can combine up to eight 4 Mbps PCM links in a 34
Mbps CCITT G.703 link and a binary interface to an EOC (electro–optical coupler). This
EOC can also be provided in a standard Alcatel 1000 S12 PBA.
The transmission system also gathers the clock and tone provision in the cluster from the
host. The tone link is sent as a 4 Mbps PCM link, and the clock is extracted from the 34
Mbps link by the multiplexer. This clock is the reference used by the SCLA –Simplified
CLock version A– PBA, to produce and distribute the internal clock in the RTSU. This board
includes a PLL circuit that is able to provide a clock signal in the case of a link failure. This
SCLA board plus the control board is named the RTSU Emergency Clock & Tone Module
–RECM–.
The figure shows an RTSU architecture for one TSU with 1024 analogue lines – approx.
0.15 Erlang per line–, or 512 ISDN subscribers. Two optical lines –therefore two
multiplexers– are always used for reliability reasons.

1.
Figure 145 : RTSU architecture and connection

1
0 8
ASM/ISM 1 ACCESS
SWITCH M
11
2 N 12 E
U O
7 15 C
ASM/ISM
X
0
8
1 ACCESS
8 SWITCH
11
N+4 M
12
E
ASM/ISM O
7 15 U
C
1
X
SCM
SCM (opt)
2
Clock
RECM Tone
C&T
Distribution
Optical
Fiber
M
E
U N 8
O
9
C 10
1
X N ACCESS 8 11
9
SWITCH 12
1 10
ACCESS 8 11 13
N
SWITCH 9 12 14
1 7 10 13 15
ACCESS8 11
14
SWITCH9 12
N 7 15
10 0
GROUP 13
11
SWITCH 14
N+4 7 12 1
15
13
M
E 14
15 2
O
U
C
3
X
PLANES
Clock Tone
For more than one TSU segregation –multi–RTSU–, it is not necessary to provide eachTSU
with its own multiplexer (one or two). It is possible to take advantage of the eight inputs of
the multiplexer to mix the links of each TSU. The second example on the next page shows a
multi RTSU example which supports three TSU accesses using four multiplexers.
In these multi–RTSU configurations, where three or more 34 Mbps connections are needed,
it is generally more economical to multiplex the links (G.703 outlet) to a higher order –e.g.
140 Mbps– using a commercial multiplexer and EOC.

1.
Figure 146 : Multi–RTSU example
TSU 0
4 Mbps
Access
Switch
M 34 Mbps
Access x
Switch
TSU 1 M
U
Access x
Switch
M 140 Mbps
Access M x
Switch
U
x
TSU 2
Access
Switch M
x
Access
Switch
The RTSU is implemented in the JA02 rack. This rack, fully equipped, supports up to 12
subscriber modules (ASM or ISM ones), 3 service modules, 6 RTSU Emergency C&T
modules, 6 multiplexers, and up to 6 Access Switches. The EOC PBAs can be equipped in
the air baffle area of the rack. In the host, the RTSU optical links are connected to a set of
EOCs and multiplexers located in the rack type JJ02. This rack has the same configuration
as the JJ00 rack (see the Exchange configuration chapter), but includes a number of slots
for the multiplexer PBAs.

1.
Figure 147 : JA02 Rack
ÌÏÏ ÌÏÏ ÏÏ
ÌÏÏ ÌÏÏ ÏÏ
ALCN / ISTX
ÓÓ ÌÏÏÌ ÌÏÏ
1
ÓÌÌ
8
ÏÏ 1 8
ÌÌ
ÌÌ
Subscriber
ÓÓ
ÓÌÌ Ì ÌÌ
Module
ÓÓ ÌÏÏ
ÓÌÌ Ì Ì ÏÏ
Ï Ï ÓÓ
ÌÌÓ
MCUB
1 8 1 8
ÌÏÏ Ì ÏÏ
Ï Ï ÓÓÓ
ÌÏÏ Ì ÏÏ
Ï Ï ÓÓÓ
SCM
ÌÏÏ ÌÏÏ ÏÏ ÓÓ
ÏÓ
1 8 1 8
ÏÏÏ
AIR BAFFLE
Multiplexer
ÓÓ
ÓÌÌ ÓÓ
Ó Ì Ï
ÓÓ
ÓÌÌ ÓÓ
Ó Ì Ï
ÏÏ
ÓÓ
ÓÌÌ Ó
ÓÓÌ Ï
ÏÏ
RECM
1 8 1 8
ÌÌÌ ÓÓ
ÓÓ
Ó Ó ÌÌÌÏÏÏÏ Ï
ÏÏ
Ì
Ì ÌÌ Ì Ï Ï
SWCH
1 8 1 8
ÏÏÌÌ ÌÏÏ
Ì ÌÌ
ÏÏÌÌ
ÌÌ
ÏÏÌÌ
1 8 1 8
ÌÌ
ÏÏÌÌ
This rack is used to equip three different sizes of TSU. For traffic reasons, an exchange
should not have a mixture of different RTSU sizes, except in those cases where RTSUs
have not reached their final size to allow for future extensions. The quantity of ASM/ISM per
TSU is defined by the traffic per line according to the following list:
- Low traffic RTSU (less than 0.151 Erlang/Line): 8 Subscriber modules/TSU
- Medium traffic RTSU (less than 0.201 Erlang/Line):6 Subscriber modules/TSU
- High traffic RTSU (less than 0.275 Erlang/Line):4 Subscriber modules/TSU.

According to this ratios, the maximum capacity of the JA02 rack is of three –high
traffic–TSUs .
The following figures contain two schematics of rack and RTSU configurations for high and
low traffic TSUs. The first one shows a three high traffic TSU RTSU configuration –twelve
subscriber modules–. The second one shows, a three low traffic TSU RTSU –24 subscriber
module–. In the second case, two racks JA02 are needed.

1.
Figure 148 : RTSU Rack for High Traffic TSU
Module 2 Module 3
TSU 2 TSU 2
Module 0 Module 1
TSU 2 TSU 2
Module 2 Module 3
TSU 1 TSU 1
AIR BAFFLE
Module 0 Module 1
TSU 1 TSU 1
Module 2 Module 3
TSU 0 TSU 0
Module 0 Module 1
TSU 0 TSU 0
Figure 149 : RTSU rack configuration for Low Traffic TSU
Module 2 Module 3 Module 6 Module 7

TSU 1 TSU 1 TSU 2 TSU 2


AIR BAFFLE AIR BAFFLE
Module 4 Module 0 Module 1

Module 5
TSU 0 TSU 2 TSU 2
TSU 0
Module 2 Module 6 Module 7

Module 3
TSU 0 TSU 1 TSU 1
TSU 0


1.
3. A1000 S12 SOFTWARE
3.1 Functional subsystems
The Alcatel 1000 S12 software provides all the exchange services by managing the relevant
circuits. The main service is the call handling function, with a series of additional facilities
(abbreviated address, three party, detailed billing, etc..). In addition, the software offers to
the administration a broad range of features intended for operation, administration, and
maintenance tasks.
This software is broken down into a series of subsystems by grouping common functions.
Furthermore, by successively breaking down these functions they are grouped into areas
and finally modules.
The software breaks down into six basic subsystems :

- Operating System
- Database
- Call Handling
- Telephonic support
- Maintenance
- Administration.

1.
Figure 150 : Software building blocks
ADMINISTRATION
CALL
MAINTENANCE
HANDLING
TELEPHONIC
SUPPORT
DATA OPERATING
BASE SYSTEM
Every subsystem breaks down into a series of software areas.
- The Operating System and the Data Base contain the following software areas:
– Operating System Nucleus
– Network Handler
– Input/Output
– Man Machine SW
– Load and initialization
– Clock, Tone and Calendar
– Data Base Management System
- The Telephonic Support subsystem is made up of:
– Telephonic Device and Signalling Adaptation

1.
– Signalling Handling
– Charging
– Remote Subscriber Unit
– Network Service Centre
– Packet Switching
– CCITT N7 Common Channel Signalling Message Transfer
- The Call Handling consists of the following areas:
– Call Handling and Facilities
– Call Service
- Maintenance covers the areas:
– Maintenance SW
– Status and Alarm SW
– Line and Trunk testing SW
– Test Signal Analyzer and Test Access Unit SW
- Finally, the Administration subsystems contains:
– Administration SW (Traffic and performance measurements)
– Extensions
At the lowest level are the software modules. The software areas are divided into modules
that are completely independent of each other. These modules are called Finite Message
Machines (FMMs) and System Support Machines (SSMs). The communication between
FMMs is carried out through normalized data structures known as messages. The
interaction between FMMs and SSMs is performed by means of procedure calls in the FMM
––> SSM direction, and through messages in the SSM ––> FMM direction.
All these software modules are distributed over the different hardware modules. As can be
seen in the figure, the software is distributed among the different modules. This distribution
is not carried out in an arbitrary way, instead each module contains that part of the software
it needs for its operation.
The support software (Operating System Nucleus, Network Handler, Data Base SW, and so
on) is distributed over all CEs in the exchange.

1.
3.2 Software concepts
3.2.1 Finite Message Machine (FMM)
a. Definition and characteristics
An FMM is the basic software–building functional block and has the following
properties:
– It can communicate with other FMMs but only through messages.
– From the outside, an FMM is a “black box”, i.e. its internal structure is not known to
the rest of the system. Its functional behavior is uniquely defined by the set of
messages it sends and receives.
– It may be in one of several different states and transactions between these are
allowed. A limited set of messages is defined for each state. After receiving a
message, the FMM may generate and transmit output messages and its state may
change.
Figure 151 : An FMM as a black box
M3_INFO_LDC
M1_ORIG
FMM M4_SLCT_CH
M2_CH_INFO
M5_ACT_CACO
FMM INTERFACE:
M1_ORIG M3_INFO_LDC & M4_SLCT_CH
M2_CH_INFO M5_ACT_CACO
b. Finite State Machine (FSM)
By definition, we know that an FMM may be in one of several states. The FMM may
emit one or more output messages and/or change from one state to another upon
receipt of a message. This state change mechanism brings us to the FINITE STATE
MACHINE concept.
For a proper understanding of this concept, we will study the example shown in next
figure. It shows how the FMM can receive messages A, B and C and, in turn, send

1.
messages D and E. The functional behavior of the FMM is completely defined when the
message reception and transmission sequence is known. The sequence in our
example will be: For the FMM to send message D, it must first receive either message
A, or C and then B. To send message E, it must receive message B before A.
This FMM may be built with three states. Figure 152 shows the way the FMM works.
The three states are:
– INIT:
This state indicates that the FMM is waiting for message A, B or C. If it receives
message A, it sends message D and changes to the INIT state. If it receives
message B, it changes to the B_REC state. If it receives message C, it changes to
the C_REC state.
– B_REC:
This state indicates that the FMM received message B and is now waiting to receive
message A. When this message arrives, the FMM will send message E and go back
to the INIT state.
– C_REC:
This state indicates that the FMM received message C and is waiting to receive
message B. When it arrives, the FMM will send message D and go back to the INIT
state.

1.
Figure 152 : FSM structure

START FMM
INIT
STATE
WAITING
MESSAGES
INIT B_REC C_REC
A B C A B
STATE STATE
D E D
B_REC C_REC
INIT INIT
INIT
STATE STATE
STATE
c. Types of FMMs
Before studying the different types of FMMs to be found in the system, we must first
define a term that is very important in all FMM executions : the PROCESS. An FMM
consists of a part that is pure code, called process definition, and another part with
the data, known as process data. The execution of a process definition with its
associated process data is known as process.
Let us now study the different types of FMMs with the help of some practical examples.
– Monoprocess FMM
First, let us have a look at the FMM that analyzes the prefix. When executed, this FMM
will establish, among other things, the call destination, i.e. whether the call is local or
outgoing. The FMM will start its execution (process definition) using the data area
(process data) at the moment it receives a request in the form of a message. When the
execution ends, the FMM will output a message and the data area will no longer be
needed for this request. When a new message arrives at the FMM, asking it to analyze
of a prefix, the same process definition will be executed again and the same data area
will be used. This means that a single data area is required for this type of FMM. These

1.
FMMs are therefore called MONOPROCESS since only one process may be active at
any given moment.
Figure 153 : Monoprocess FMM
PROCESS DEFINITION
PROCESS DATA
– Multiprocess FMM
For the second example, let’s take the FMM that handles the call setup. When a call is
set up, a process is created which uses a data area to store all the information required
for this call. This FMM will be handling one subscriber for a more or less prolonged
time; if during this time, another subscriber starts a call, the FMM will have to store data
for this second call. The FMM will then not be able to use the same data area, since it
has already been taken by the first call. If the FMM must handle multiple calls
simultaneously, independent data areas (one for each call) have to be created.
The FMMs that are implemented in this way are called MULTIPROCESS FMMs. In this
case, an independent data area is created for each new request. When the execution
of a request is completed, the data area used for it is released. The FMM part that is in
charge of creating and releasing the data area is called SUPERVISORY PART and has
its own data area. The FMM part responsible for carrying out the actual FMM function,
is called APPLICATION PART.
The execution of the supervisory part is known as a supervisory process, and the
execution of the application part on one data area is called an application process.
This means that multiprocess FMMs always have one supervisory process and a
variable number of application processes.

1.
Figure 154 : Multiprocess FMM

SUPERVISORY PART
PROCESS DEFINITION
PROCESS DATA
APPLICATION PART
PROCESS DEFINITION
PROCESS DATA
– Monoprocess multidevice FMM
Up to now, we have seen two different types of FMM – monoprocess and multiprocess
– each having its own specific structure and operating mode. As seen before, a
monoprocess FMM can only handle one execution request at a time. There is,
however, a special type of FMMs which has a single process but can handle more than
one request simultaneously.
Let us consider an FMM that scans the line circuits. The number of these circuits is
fixed and known beforehand; furthermore, the scan must be executed continuously.
Under these conditions, one data area per circuit will be required but the number of
these areas is also fixed.
We could implement this FMM as a multiprocess one. In this case, the FMM
supervisory part would have to create an application process per circuit only once, at
the initialization time. All these processes, however, would have to exist forever since
the scan must be performed continuously.
This solution does not seem to be the smartest, nor the most adequate. The alternative
is a monoprocess FMM that uses one data area per device. The result is then a single
process that controls a fixed number of circuits. This type of FMM, i.e. implemented in
this way, is known as a MONOPROCESS MULTIDEVICE.

1.
Figure 155 : Monoprocess Multidevice FMM
PROCESS DEFINITION
DEVICE 1
DEVICE 2
DEVICE N
d. Overlay FMMs
There are kinds of FMM which do not require a periodic performance or/and which
occupy too much memory. FMMs with these properties are not resident (permanently)
in the CE memory, and are therefore called OVERLAY FMM –OFMM–. They are stored
on the system disk and will only be loaded into CE memory when their performance is
needed. At this moment the FMM program code and data will be set up in a particular
zone of the CE, called ’Overlay Zone’.
e. Shell based systems
The FMMs that we saw so far are implemented as one software unit. There are a
number of drawbacks though with this implementation:
– the maximum size of a software unit is 64 kB;
– if the software is CDE dependent a lot of variants have to be written and maintained;
– if the software handles signalling, possibly different versions of signalling have to be

handled, so again a lot of variants have to be written and maintained.
To solve all of these problems, an FMM can be implemented as a so–called Shell

Based System (SBS). The FMM contains a shell and a number of entities. Each entity
performs a specific task. Figure 156 gives an example.

1.
Figure 156 : Shell based system

S12 messages

S12 messages
internal messages

Usually the shell is implemented as an FMM. The entities can be:
– a part of the FMM;
– an SSM (with interface procedures);
– a procedure that is linked with the FMM to form one software unit.
There are a number of rules in an SBS. Here are a few:
– only the shell can receive S12 messages from other software units;
– both the shell and the entities can send messages to other FMMs;
– the entities communicate indirectly with each other, via the shell;
– internal messages are used:
– for the communication between the entities;

– for the communication between the shell and the entities.
– the shell and the entities use shared data.
3.2.2 Messages
a. Standard messages
In the previous section, we have seen how the communication between FMMs is
performed through normalized information structures, called MESSAGES. These
messages have the following properties:

1.
– When a message is sent, the information will be placed into a 64–byte data
structure, called MESSAGE BUFFER. Each Control Element (CE) will have a certain
stock (pool) of message buffers.
– The message buffer structure consists of two parts: header and body. The header
is used to route the message towards the destination FMM and occupies 16 bytes. It
includes among others, the following information fields: a number (msg_identity),
which uniquely defines the message; a priority; message type; etc, as shown in the
next figure. The body, in turn, is divided into two parts. The first part is the text, or
the actual information, which occupies 40 bytes. The second part is reserved for use
by the Operating System and occupies 8 bytes.
– Each message structure is defined “off_line” and is known by different FMMs which
must use them. When an FMM has to send a message, it must first request one of
the free message buffers. The Operating System will search for a free buffer and
return a pointer with the message buffer starting address to the requesting FMM.
This pointer will be used to copy the message to the message buffer. In the same
way, a pointer will be passed to the destination FMM, where it will be used to read
the message information.
Figure 157 : Message structure
INFORMATION LENGTH HEADER

MSG–IDENTITY
PRIORITY
TYPE
DESTINATION
SOURCE
BODY
TEXT (40 BYTES MAXIMUM)
RESERVED WORDS
b. Types of standard messages
Although up to now, we have basically referred to the messages as the communication

means between FMMs, they are actually used for the intercommunication of FMM
processes. The messages will always be sent/received through the “message buffer”
mechanism. There are two main types of messages depending on whether the
destination process is known by the originating process or not. These two types are:

1.
– BASIC MESSAGE:
This type of message is sent from an FMM (process) to another FMM (process). The
actual destination process is not specified when the message is sent. Determination of
the destination process will be a function of the Operating System.
As an example of this type of messages, let us take the FMM which handles the call set
up. When a new call is set up, there is no active process for its handling; thus, the first
message that the FMM (which detected the call set up), sends to the former FMM, is
the one without a specific destination, a basic message.
– DIRECTED MESSAGE:
This type of message is sent by a process to a known destination process.

In the above example, when the call set up continues, the originating process already
knows which process is attending to it. Therefore, in this case, the originating process
will send the events to the destination process in the form of directed messages.
There are two rules to be taken into account when sending and receiving messages.
These rules, graphically represented in the next figure, are:
– A supervisory process may send and receive basic as well as directed messages.
– An application process may only receive directed messages; however, it may send
either basic or directed ones.
The same rules that apply to the supervisory part of a multiprocess FMM also apply to
the monoprocess FMMs. Therefore, the only process of a monoprocess FMM, will be
called supervisory process.
Figure 158 : Rules for sending & receiving messages
BASIC
BASIC
SUPERVISORY PROCESS
DIRECTED DIRECTED
BASIC
DIRECTED
APPLICATION PROCESS
DIRECTED

1.
c. Creation of application processes
Now that we have studied the different types of FMMs and messages that are generally
found in the system, we can describe the mechanism used to create an application
process for a multiprocess FMM. The steps followed to achieve this creation are shown
in the next figure.
[1]
A basic message is sent from a process to the supervisory process of an FMM.
As a result, this supervisory process decides to create an application process that
will handle the request received in the message.
[2]
The supervisory process will use the O.S. services to create the application
process. The new process will have an identity that is known, from the time of its
creation, by the supervisory process.
[3]
At this point, the supervisory process can send a DIRECTED message to the
created application process since it knows its identity. This message will contain
all the information that the supervisory process received in the basic message.
[4]
The application process reads the information received in the directed message
and starts its execution. The result of this execution may be either a basic
message to another process or a directed message to the process that sent the
first basic message. From now on, the originating process will communicate with
this application process through DIRECTED messages (remember that the
application processes can only receive directed messages).
[5]
When the application process has completed its task, it will notify this and the
resources assigned to it will be released (process data).

1.
Figure 159 : Application process. Creation
ÏÏÏÏÏÏÏ
2
BASIC
ÏÏÏÏÏÏÏ
PROCESS SUPERVISORY PROCESS
ÏÏÏÏÏÏÏOPERATING
1
ÏÏÏÏÏÏÏ SYSTEM
ÏÏÏÏÏÏÏ
ÏÏÏÏÏÏÏ
3
DIRECTED
5
APPLICATION PROCESS
DIRECTED
4
BASIC 4 ANY
OTHER FMM
(PROCESS)
d. User buffer
When a process has to send more than fourty bytes, it uses two buffers: a message
buffer and a user buffer. The user buffer is a memory area that can have any size up to
64 kB. The user buffers are organised in memory pools. Each memory pool contains a
number of buffers of a particular size. Within a control element you can have up to 10
different memory pools. A control element can therefore have user buffers of 10
different sizes.
The message buffer is organized exactly as seen before; however, the header contains
an indicator notifying that it has a user buffer associated with it, while the text includes
a field indicating the length and the address of the user buffer.
When a process wants to send a message with a user buffer, it delivers them to OS.
OS then puts the message in a delivery queue and presents it when appropriate. The
process that receives the message obtains the length and address of the user buffer to
read the information contained therein.

1.
Figure 160 : Message buffer with associated user buffer
MESSSAGE
BUFFER
HEADER USER
DATA BUFFER
1
POINTER
TEXT LENGHT
DATA
e. Compound messages
The messages discussed so far have a fixed structure: both the length of these
messages and the layout of the messages is fixed. When the higher level FMMs
communicate, the same message has to be sent a number of times during a call, but
the layout may differ depending on circumstances, such as when the message is sent
and what kind of facilities the subscribers have.
For ISDN subscribers there is an extra difficulty: they communicate with the exchange
with ISDN signalling, that uses optional components. These messages have to be sent
from one FMM to an other in the form of a S12 message. The standard S12 messages
do not support optional components.
To cope with these restrictions of the standard S12 messages, a different type of S12
message can be used: the compound message. A compound message contains a
number of message blocks. Each message block has a message block identifier
(MBID), a length indication and the contents part.
3.2.3 System Support Machine (SSM)
a. Definition and characteristics

Generally, the software modules are implemented as FMMs and written in the high
level language CHILL. The FMM not only offers specific advantages (modularity and
flexibility), it also has some drawbacks:
– Many times, the software must be available and ready to attend to certain events,
e.g. a hardware interrupt. This readiness is not furnished by the FMM model since,
as mentioned earlier, the FMMs are only started through the reception of messages.

1.
– In the case of common support routines which we want to group into independent
SW modules, we could actually use FMMs. However, every time one of those
routines were to be used, a message would then have to be sent to the FMM
containing them. This would involve a great shuffle of messages and overload, with
the subsequent loss of time for their reception and transmission.
The reasons exposed here are more than enough to think out a different module, one
module to complement the FMMs and solve the above problems. This software module
is known as SYSTEM SUPPORT MACHINE (SSM).
An SSM is designed as a set of routines, all within the same module, that carry out
some support function for one or more FMMs. These routines are not started through
messages, but through procedure calls; although they can actually send messages to
the FMMs.
b. Types of routines in a SSM

– Interface routines
These routines are started by FMM processes through procedure calls. In this case, the
routines are executed as if they were part of the calling program. The interface routines
may send and receive directed messages, such as the answer–back message from the
FMM to which a message was previously sent. The routines of this type are the only
ones that may be called by an FMM process. Furthermore, for a process to be able to
make use of these routines, the process and the SSM interface routine must be in the
same CE.
– Clocked procedures
These routines are run periodically. They are mainly used for scanning telephonic
devices. The interrupts are masked out during the execution of these routines, so they
will not be interrupted by a timer or any hardware event.
– Interrupt procedures
These routines are executed whenever a hardware interrupt takes place. Just as the
clocked procedures, they also run with the interrupts masked out.
For this reason, both the periodic and the interrupt procedures must have a short
execution time so that no hardware interrupts are missed. Consequently, these routines
will not be able to send or receive messages as this would take too long. Thus,
functions that require a longer execution time, or the sending of messages, will not be
designed with these type of routines; instead, they will be designed as Event Handlers.
– Event Handlers
These routines run with the interrupts allowed and, therefore, will be able to send
messages.Their main function is to prepare and send messages based on the data

1.
provided to them by the periodic and/or interrupt procedures. These routines have an
associated flag (event flag) that, when set by the periodic and/or interrupt procedures,
or even FMMs processes, indicates to the Operating System that the Event Handler
must be started. Once the execution of the Event Handler has ended, control is given
back to the Operating System.
Figure 161 : Interconnection of an SSM and other modules
MESSAGE
FMM O. S.
SSM
DIRECTED
INTERRUPT EVENT
INTERFACE CLOCKED
HANDLER
PROCEDURE PROCEDURE PROCEDURE
MESSAGES
SSM ROUTINES
MESSAGES
MESSAGES
3.3 Communication between processes
As we already know, the software stored in the different control elements is organized in the
form of FMMs, SSMs, and OS modules. Of all these software tools, the FMMs are those
used to create processes that perform the application functions. These processes exchange
information with each other by means of standardized messages.
The transfer of these messages, from the originating to the destination process, is carried
out via the OS, and may be established within a single microprocessor or, between different
CEs through the internal switching network. The following figure shows an example of the
transmission of messages between the A, B and Y FMMs resident in the CE1 and CE2
control elements.

1.
Figure 162 : Communication between processes
FMM FMM
A B
OPERATING SYSTEM
CE 1
DSN
CE 2
FMM
Y
OPERATING SYSTEM
This transfer works as follows: the originating process must first obtain a message buffer
and fill it in correctly and then it must ask the OS for its transmission. Thanks to the
Operating System, the transmission of these messages is completely transparent to the
processes involved. The destination process is known from the type of message and the
information contained in the message header, and the path to follow is established by an
algorithm called routing. The routing result may be ’internal’ (communication within the
actual CE) or ’external’ (communication between different CEs).
There are two different ways to start the routing procedure, depending on whether the
message is a directed or a basic one. If it is a directed message, the originating process
knows the identity of the destination process, and writes it into the message header. This
destination process identity contains the identity of the CE where the process is executed.
Therefore, the routing will consist of comparing the two CE identities (origin and destination)
and deciding whether the message is internal or external.
In the case of a basic message, the originating process does not know the identity of the
destination process. In this case, routing is essentially based on the message number. For
this situation, the OS data provides a set of tables called MRT ’Message Routing Tables’ in
each system control element. These tables contain for every message the information
necessary to find out the destination process identity or the CE where the destination FMM
resides.

1.
Figure 163 : Routing of ’Basic’ and ’Directed’ messages

Ps–1
Ps–1
External External
FMM Internal FMM
A Internal
B
Pa–1
Pa–1
HEADER OPERATING SYSTEM
HEADER OPERATING SYSTEM
INFO
INFO
MRT
BASIC
MESSAGE DIRECTED
MESSAGE
As we already know, the basic difference between the two types of messages is that,
directed messages may be sent to any type of process (supervisory or application), whereas
basic messages may be sent only to supervisory processes. The reason for this is that the
routing result is the identity of the destination FMM and this identity only provides a link to
the supervisory process in an unambiguous manner.
3.3.1 Communication within the same CE
If the routing result indicates that the message is internal, the Operating System must
complete the transmission by presenting the message to the destination process. This
presentation is not carried out immediately, instead the message is inserted in the delivering
queues with its corresponding priority. The message stays in this queue until the moment
when it is presented to the destination process.

1.
Figure 164 : Internal communication
FMM
FMM
B P2
A
P1
HEADER
OPERATING SYSTEM
INFO
MESSAGE INTERNAL
MRT
DELIVERING QUEUES
3.3.2 Communication over a virtual path (VP)
Virtual Paths (VP) are temporary paths that are used exclusively for the transmission of a
message and are released after the message is completely received. This is the most
commonly used type of path and it is dedicated to the support of individual exchanges of
information.
As we already know, a path can be released by sending two or more ’Idle’ or ’Clear’
commands through the actual path. The message arrival acknowledgements are also sent
through virtual paths.
a. Communication with messages
On the other hand, if the Operating System decides, based on the routing result, that
the message is external, it will be necessary to establish a communication path through
the network with the remote control element that contains the destination process.
Once the identity of the destination CE is known, the Operating System must see to the
transmission of the message. This transmission is carried out in accordance with the
steps.
[1]
Copy the message buffer to the TI memory.
First a launching buffer is reserved in the TI Packet RAM. The message is copied
from the Main Memory into this buffer. Of course, the message will be preceded
by the SELECT commands required to establish the path towards the destination

1.
CE, and the SOP or Start Of Packet indicator. Furthermore, a CRC and the EOP
or End Of Packet command are appended to it.
[2]
Order to launch the buffer:
Once the buffer is copied, the OS orders its launching using of the TI control
registers, where a command is given to launch the packet in any free channel. In
the response command the TI indicates the chosen channel identity. The TI
hardware sends the message–words from the buffer to the chosen channel, in an
autonomous way. Once the launch is completed, the TI notifies the OS which
releases the associated buffer of the actual TI packet RAM.
Figure 165 : Transmission of an external message
TI
TI
P–RAM
P–RAM
4
3 DSN
5
1
MICRO
MICRO
Main
Main
Memory
Memory
[3]
Progress through the network:
The SELECT commands, written at the beginning of the packet, establish a
network path that terminates at the TI of the required control element.
[4]
Collection and storage in the destination TI:
The SELECT commands of the packet sent stay in the different network
multiports, so that the first word arriving at the TI is the Start Of Packet, SOP. This
indicator causes the TI hardware to collect all the incoming information until the
arrival of the EOP and store it in its internal memory.
[5]
Copy the buffer to the main memory of the destination CE:

1.
Once the EOP is detected, the TI notifies the microprocessor through the
appropriate registers. This provokes the entry of the OS which transfers the
message to the main memory, checks the CRC, and releases the buffer used.
After the message is copied to the destination, the Operating System again
analyzes the message in order to obtain the identity of the destination process
and stores it in a presentation queue.
Besides the well–known NACK mechanism (backward information), provided by the

network when the continuation of the path establishment proves impossible, the
Operating System uses an error protection protocol. This protocol consists of the
transmission of an acknowledgement with CRC. This acknowledgement is materialized
in the transmission of an acknowledgement message (ACK).
If the message does not arrive within a specified period of time (’To’ in the figure), the
originating Operating System retries the message launch a certain number of
consecutive times (usually three). If the acknowledgement is still not received, apart
from other actions to be taken, the appropriate error reports are generated and sent
towards the defence CE responsible for error handling.
Figure 166 : Error protection
CE1 CE2 DEF

Message 1 (1)
Ack
Message 2 (1)
To
Message 2 (2)
Message 2 (N)
To
Error Report
However, this whole operation is transparent to the processes involved and they are not
notified of the correct or incorrect message arrival. Therefore, the actual processes must
support, if required, their own acknowledgement protocol.

1.
To continue with these ideas, there are basically two strategies to establish a path
through the switching network: the virtual paths and the user paths.
b. Communication with user buffers
The user buffer transmission is carried out by splitting it up into 64–byte portions (due
to the mapping of the Terminal Interface P–RAM). These portions are sent through the
network using a held–up path towards the destination CE. This path is established by
the first packet sent and is held by ’SPATA’ words until the transmission of the last
packet. The destination OS assembles the incoming portions using the previously
reserved area.
Difference must be made between ”small user buffers” (up to 128 bytes) and ”large
user buffers”.

1.
Figure 167 : UB transfer indication
U.B. up to 128 bytes

USER OS OS USER
ÉÉ ÉÉ
MSG_UB
ÉÉ ÉÉ
MSG MSG (keep conn.) Get UB
ÁÁ ÁÁ
ÁÁ ÁÁ
Held UB[1]
UB
ÁÁ ÁÁ É
ÁÁ
Path
(UB[2]) (clr conn.)
ACK É MSG
Á
MSG_UB
Á
UB
Á
U.B. 256 bytes or more
USER OS OS USER
ÉÉ MSG_UB Get UB
ÉÉ
MSG Get U.B. (VP)
ÁÁ
ACK
ÁÁ UB ACK_UB (VP)
ÁÁ ACK
ÁÁ
ÁÁ ... ÁÁ
UB[1](keep conn.)
Via
ÁÁ
2
ÁÁ
Held (UB[n]) (clr conn.)
Path
ÉÉ É MSG
ÉÉ
s MSG (VP)
ACK MSG_UB
Á
Á UB
Á
– User Buffers up to 128 bytes
In this case the user sends the ”message with user buffer” to OS (see figure 167). OS
transmits this message and the user buffer to the remote side via the DSN. The first
packet sets up the connection and the last packet clears the connection. At the end an
acknowledgement is sent back to the originating OS. The first packet contains the
message itself (standard S12 message). The header information indicates the

1.
presence of a user buffer, so that the destination OS can allocate a user buffer. At the
end of the scenario the ”message with user buffer” is sent towards the user.
– User Buffers of 256 bytes or more
This scenario also starts with the transmission of the ”message with user buffer”
towards the OS. In this case the originating side sends a request (message via virtual
path) to the destination side for a user buffer. The destination OS allocates a buffer and
sends an acknowledge back (also message via a virtual path). This ACK_UB message
contains the pointer to the user buffer (in the destination CE). Then the user buffer is
transmitted via two held paths (see figure 168, the first packet makes the connection
and the last packet clears the connection for each held path). Finally the A1000 S12
MSG is sent via a virtual path. This message already contains the new pointer (points
to the user buffer in the destination CE). The complete ”message with user buffer” is
delivered to the user.
Figure 168 : Transmission of a user buffer via two held paths

TI
TI
DSN P–RAM
P–RAM
VP 1
VP 2
11 1
2 11 2
1
33 2 3
2
3 33
N N
SPLIT 1
N N SPLIT 1
SPLIT 2
SPLIT 2
Another strategy used to save transfer time is to pack the data in the outgoing channel.
Up to now, we have seen that eight of the sixteen bits of an A1000 S12 PCM channel
are used to carry data through the network. For user buffer transfers the ’bit
packing’ method is used. This new method consists on carrying 12 bits instead of 8
on each PCM channel thus achieving a better transfer time.

1.
Figure 169 : Packing strategy
1 Protocol Bits BYTE 1

2 Protocol Bits BYTE 2 UNPACKED
3 Protocol Bits BYTE 3
8
1 Protocol Bits B2–L BYTE 1

2 Protocol Bits B2–H BYTE 3 PACKED
3 Protocol Bits B5–L BYTE 4
4 8
Note: Another way to send information greater than fourty bytes is to organize it in successive
message buffers. This strategy saves the time spent in the search for the user buffers and in the
splitting up of the buffer, but increases the transmission time as it involves the routing of each and
every one of the messages making up the series to be sent.
3.3.3 Communication over a user controlled path (UCP)
There are also User Controlled Paths (UCP). The main feature of these user paths is
their two–way and lasting nature. The paths are assigned to two processes, one at each
path end. These two processes are considered the path users. This type of path is primarily
used to create a conversation path between two subscribers or two trunks located in
different control elements, but also for the massive exchange of control data between CEs.
Therefore, unlike the virtual paths, the UCPs are established and released under direct user
control. These two functions, path establishment and release, are performed using the
services offered by the operating system.
When a user, for instance the process PA, seeks to establish a UCP towards the remote
process, PB; it asks the OS for a user path.(step 1). This request assigns, from this moment
on and in a bi–univocal manner, the process PA to the identity of the path that will be
created. This means that all the messages that arrive through the created UCP will
automatically be sent to process PA.

1.
Figure 170 : Request of an UCP
DSN
O.S. O.S.
PA P
B
CE 1 CE 2
Now the originating process PA has to associate the UCP to the destination process, PB. In
order to achieve this, PA requests the transmission of a basic message via the UCP (step 2).
As a consequence of the request, the Operating System sends a message notifying the
creation of the UCP to the destination side OS (step 3). The latter, defines a new UCP
identity that will be significant within that CE (CE 2), and responds with the creation of the
return path (step 4). At this moment, the two–way path is established in the network,
although it has not yet been assigned to any process on the destination side.
All messages transmitted through a UCP carry a UCP identifier which is relevant on the
originating side within the message body; therefore, once the message has reached the
destination CE (step 5), the OS there must change that identity into one that is locally
significant. This is done in a similar way for each message arriving through a UCP. However,
the first message must be sent by use of the routing algorithm (basic message), for no
process has yet been assigned to the UCP. Once the OS finds out the destination process, it
places the message in a queue and hands it over to process PB when required (step 6).

1.
Figure 171 : Notification to the destination process
DSN 3
O.S. O.S.
4
2 6
5
PA P
B
CE 1 CE 2
The receiving process must now ask the OS for its association to the created UCP (step 7).
Figure 172 : Answer from the destination process
DSN
O.S. O.S.
PA P
B
CE 1 CE 2
Once the path is established, and the processes involved are identified, the path can be
used for the fast exchange of messages. However, these user paths are used above all for
the connection of telephonic devices; that is, subscriber to subscriber, subscriber to trunk,
subscriber to service circuit, trunk to service circuit, etc. In order to carry out these
connections, it is necessary to link the established user path with the port and channel
corresponding to the external telephonic device. This link is performed through a request to
the operating system. The OS orders the Terminal Interface internal switching to establish
the duplex connection by a ’Cut through’ operation. This task is performed in the two CEs
involved.

1.
Figure 173 : Switching in the Terminal Interface

TERMINAL INTERFACE
CH N CH A
Tx Tx UCP
CLUSTER
Rx Rx
CH M CH B
P–RAM
Figure 174 : Connection of a subscriber to a UCP
TERMINAL INTERFACE TERMINAL INTERFACE
ASM CH N CH A CH C CH O
ASM
HARDWARE
HARDWARE
CH M CH B CH D CH P
DSN
Either process (origin or destination) may ask the Operating System for the release of the
user path while it is being used. As a consequence of this release request, the respective
OSs release the established communication and notify the associated processes.
3.3.4 Communication with the internal packet protocol (IPP)
The communication mechanisms discussed so far provide services that are sufficiently
generic for the transmission of messages. Yet there still are some limitations:
- the time that a message must wait in the delivery queues
- none of the previous procedures allows for the transmission of messages to remote
OBCs
- the routing algorithm can provoke a work overload in some control elements, especially
those associated with packet handling (N7, X.25, ISDN,...).

1.
These problems are solved by the use of a new internal communication protocol called IPP
(’Internal Packet Protocol’). This protocol was introduced to support the transfer of
messages between an N7 user, resident in the module that provides access to the speech
channel, and the module that provides access to the associate signalling trunk. This
introduction considerably increased the performance of the message transfer between them,
and its use was subsequently extended to include the data and packet communication
areas.
Figure 175 : IPP protocol in N7
UCP ACE
UCP
INCOMING OUTGOING
DTM DTM
ch x ch y
IPP IPP
N.7 DTM N.7 DTM

ch 16 ch 16
IPP
P&L C&T
Due to design reasons, there are different types of IPP users: for N7 application, for X.25,
OSI stack, etc. These software modules are called interworkings (IWs), and, as we will see
later, in order to take full advantage of the IPP protocol, it is suggested to code them under a
particular structure so that they can be activated from any other software module by
procedure calls.
The part of the Operating System responsible for managing this protocol can support only
one kind of user, a module called Common IPP (CIPP) or IPP Handler is added between the
interworkings and the actual OS.
The functions of this new module are to provide multiple users with access to the IPPs, to
receive and route the messages towards their corresponding points, to reserve the required
channels in the network as well as in the cluster PCM links for the transparent transfer of
IPP packets to the OBC/s through the Terminal Interface, etc.
When a process needs to transmit data using the IPPs, it stores the information into a
memory buffer and through the corresponding IW, passes the buffer to the Common IPP
with the identity of the destination CE or OBC and the destination IPP user identification in
that CE.
The Common IPP adds an IPP header –with the identities related to the transfer over IPPs–
to the packet and transmits it to the destination CE.

1.
An important factor to be taken into account is the size of the information to be sent. If the
information is too long to be sent in a single message, the Common IPP must find an
alternative way for its transmission. The most commonly used procedure is to place the
information in a message buffer and a user buffer – ’Segmenting’–. If the information to
transfer is excessively long, the previous procedure becomes too slow. Therefore, the
transfer time can be reduced by using of a transmission mechanism similar to the user
buffer, that is, splitting up the information into two halves, and sending them through two
paths – ’Splitting’–. Both procedures are invalid for communication with OBCs, given the
need to use held–up paths (not supported by the OBC Operating System).
Figure 176 : Transference of an IPP packet

MESSSAGE
CE or OBC Identity BUFFER
IW Identity
HEADER
IPP HEADER
IPP PACKET
DATA TEXT
DATA
The transmission of medium length messages (similar to the N7 packet size) or to/from
OBCs, is carried out by a strategy called ’Chopping’. This mechanism consists of dividing
up the information into multiple portions that form a set of separated but related messages.
For very small messages the data from several users are grouped – ’Grouping’ – and sent
as a whole in a single message buffer, thereby significantly improving the traffic flow
between micros.
At the destination the message is passed to the Common IPP of that side, which stores it in
a new buffer and hands it over to the destination IW through the ’procedure call’.
As we have seen, one reason that supports the advance in performance is the fact that the
IPP implementation offers a dedicated message transfer. By dedicated, we mean that the
messages are directly handed over to the corresponding user module, without having to
pass through the routing or message presentation queue steps. However, one first drawback
is that the destination user (IW) must be designed as an SSM routine. Furthermore, the
users must have knowledge of the different identities of the CEs, OBCs and IWs involved in
the communication.

1.
Figure 177 : IPP levels
FMMs SSMs
IPP IPP
PACKET PACKET
S–12
MESSAGES INTERWORKING
Internal
Interface
Common IPP
OPERATING SYSTEM
NH BYPASS
DIGITAL SWITCHING NETWORK
The Common IPP or IPP Handler supports the two protocol types: connection oriented and
connection–less. The connection oriented protocol is mainly designed for the communication
with OBCs. In this case, the CIPP manages a table to link the connection identities with the
associated OBC identities. The second case (connection–less) allows the transmission of
data units to CEs or OBCs without any sequence number.
3.4 Software modules
3.4.1 Logical grouping of the Call Handling software into call control planes
In every access module (ASM, ISM, IPTM, ...) there is software to handle a call. Figure 178
shows the building blocks in the call origination and in the call termination modules. The
building blocks are always present, independent of the type of access: BA, PRA, analogue
line or trunk.

1.
Figure 178 : Call Handling building blocks

AUXILIARY CONTROL ELEMENTS
SUBSCRIBER PREFIX TRUNK

PARM
IDENTIFICATION ANALYSIS SEARCH
SIGNALLING CALL AND FACILITY

HANDLING CONTROL SYSTEM
CALL ORIGINATION CALL TERMINATION
SIGNALLING
SIGNALLING
HANDLING
HANDLING
DSN DEVICE
DEVICE
HANDLING
HANDLING
BA BA
PRA PRA
Analogue Line Analogue Line
Trunk (CAS or Nr7) Trunk (CAS or Nr7)
These different blocks can be placed in 3 planes:
- Call Control Plane;
- Protocol Plane;
- Connection Plane.
Each of these planes performs tasks within their own area.

1.
Figure 179 : Call Handling Planes
DEFINE CALLED DEVICE
Prefix Subscriber Trunk

PARM
Analysis Identification Search
Call and Facility CALL CONTROL

Control System PLANE
Signalling Signalling PROTOCOL

PLANE
Handling Handling
Device Device CONNECTION

Handling Handling PLANE
a. Connection Plane (Device Handling)
The main tasks are:
– cluster handling (seizure and release);
– speech path control (join, release, ...);
– Allocation of devices to various requesters.
In general it consists of an FMM and SSM. It also keeps the busy/free status of the
devices (therefore the FMM part is a monoprocess multidevice). The type of device is
also dependent upon the module, e.g: trunks for a DTM, subscriber lines for an ASM,
B–channels for a PRA, ...
Not only access modules contain a device handler. The Service Circuit Module for
example, also contains a device handler where the devices are the senders/receivers.
b. Protocol Plane (Signalling Handling)
One of the major tasks of the exchange during the setup of a call is signalling.
– Line signalling:

1.
Hardware events coming from the Device Handler (changes in the state of the
subscriber line) are sent towards the signalling software. These events must be
translated into telephonic events which can be passed to a higher software level.
Conversely, logical telephonic signals coming from the higher level software must
be translated into commands for the operation of the subscriber’s line equipment.
Examples: off–hook of a subscriber, trunk seizure, clear forward/backward, ...
The line signalling function is performed by the signalling handling software.
– Register signalling:
Register signalling deals with the supervision of transmitting and receiving

identities. These identities can be sent by the subscriber via his push button set or
dial set, or via MF/R2 or No7 for incoming/outgoing calls.
For a push button set the DTMF code is detected in the hardware of the SCM.
The device handler collects the result from the hardware and delivers it towards
the signalling handling software. The same principle is used for trunks with MF
signalling.
For a dial set the digits enter the ASM by means of line events, and are therefore
detected in the device handler of this module. The device handler delivers the
digits (after counting the pulses) to the signalling handling software.
For incoming trunks with No7, the messages enter the signalling handling
software and contain the digits.
– Combining line and register signalling:
When using more sophisticated signalling systems, it becomes possible to

combine some events in one message. E.g: if a Q931_SETUP (ISDN) message
enters the exchange, it combines the seizure (line signalling) and the digits
(register signalling) in one message. The same applies for the Nr7 messages
used on trunks.
Conclusion:
Whatever type of signalling is used, the result is always the same. The signalling
handling software will collect the digits so they can be transmitted towards the higher
software level, the Call Control.
Summary of the main functions:
– Protocol interpretation and translation into Call Control plane terminology and vice
versa.
– Protocol interpretation and translation into Connection plane terminology and vice
versa.

1.
– Establishing a datalink.
– Communication within the protocol plane (=inter–signalling communication)
– Administration of timers and call references used in call control procedures.
– Administration of access resources.
– Handling of auxiliary devices such as senders and receivers.
c. Call Control Plane
This is the highest software level within the module. It controls the setup and the
release (during unstable phase) of the call. When events enter the signalling handling
software, it can check in the data if call control should be informed or if the event is
treated locally.
The main tasks are:
– Number Analysis
– Routing
– Call configuration management (complex facilities)
– Registration / erasure / activation / deactivation of features ordered by the

subscriber
The call control plane is signalling independent
The call control plane is steered by data coming from the building blocks within the
group: ”DEFINE CALLED DEVICE”. These building blocks are discussed in the next
chapters.
Figure 180 gives a more detailed view of the call handling planes. The software blocks
are described in the following chapters.

1.
Figure 180 : Call handling planes
CALL CONTROL PLANE

CALL SERVICES
TRA TRC PATED LSIF ARTA
CALL AND FACILITY CONTROL SYSTEM

CFCS
PROTOCOL PLANE
SIGNALLING SIGNALLING SIGNALLING

SIG SIG SIG
CONNECTION PLANE
DEVICE HANDLER DEVICE HANDLER DEVICE HANDLER

DH DH DH
ÁÁÁÁÁÁÁÁÁÁ ÁÁÁÁÁÁÁÁÁÁ ÁÁÁÁÁÁÁÁÁ

OPERATING SYSTEM and DATABASE
ÁÁÁÁÁÁÁÁÁÁ
ASM HARDWARE ÁÁÁÁÁÁÁÁÁÁ ÁÁÁÁÁÁÁÁÁ
ÁÁÁÁÁÁÁÁÁÁ ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
SCM HARDWARE DTM HARDWARE
3.4.2 Operating System
The A1000 S12 software is divided into nine subsystems. Each subsystem has its specific
function.

1.
Figure 181 : Software Subsystems
ADMINISTRATION
MAINTENANCE DATABASE OPERATING

SYSTEM
CALL CHARGING RESOURCE

CONTROL MANAGER
CALL DEVICE
SERVICES HANDLER
CALL TELEPHONIC FUNCTIONS

HANDLING
The Operating System is the subsystem that provides support to the rest of the system, by
managing the own resources of each processor. These resources are, as in any other
processor system, the time and the memory of each one of them.
Regarding the time, the Operating System is in charge of its management, since it is the
Operating System which determines the task to be performed at any given moment.
The memory, having a limited capacity, will also be controlled by the Operating System,
which is in charge of its distribution among the programs that require it.
For these reasons, the Operating System will be stored in all the CEs of the different
modules.
Given its control over time and memory, the Operating System will be essential for the
existence of the FMMs and the SSMs since it will allow the communication through
messages and will take part in the activation process of the different SSM routines.
This subsystem will also handle the clock and peripheral interrupts, thereby allowing the
execution of the appropriate SSM routine. Another function of the Operating System will be
to control the switching network and the Terminal Interface, since it will establish the physical
communication paths between the different system modules.
Finally, it will be in charge of the reloading and recovery of the different control elements for
which purpose it is equipped with error handling elements. Once an error is detected, the
Operating System will interact with the Maintenance modules for subsequent recovery.

1.
The main functions of the Operating System can thus be summarized as follows:
- Manage processor time: For the OS to be able to perform this function, there is a series
of different tasks to be carried out by the processor. The operating system indicates at all
times which of these tasks is executed according to the previously assigned priority. The
OS will have FIFO queues for managing each of these priorities.
- Manage main and mass memory: When creating a process, the Operating System
provides it with a data area, and when it terminates the Operating System releases this
area so that it may be allocated to a new process. The OS provides the message buffers
allowing these processes to intercommunicate. It also controls the memory areas
reserved for the overlay programs, indicating the relevant areas and their respective
contents.
- Timing: The OS will start the clocked procedures (inside SSMs) at a fixed time interval
per routine.
Other processes (FMMs) can start relative and absolute timers (periodic or not) and the
OS will inform the process upon expiration of the timer(s).
- Message Handling: OS will deliver the messages to the appropriate processes according
to their priority.
- Control the switching network and the Terminal Interface: The OS allows for the
transmission and reception of messages by controlling the Terminal Interface memory,
ports and channels. It also controls the switching network since it will be in charge of
writing the network control commands for the establishment and release of paths.
- CE load and initialization: A set of OS modules are responsible for requesting the load,
when necessary, of the different programs loaded in the processor memory. They are
also responsible for managing the initialization process of the different programs.
- Control the man–machine communication peripherals: The whole input/output system is

part of the Operating System; the OS will therefore contain the controllers for the
different peripherals.
- Control the loading and execution of overlay programs: The OS will control the loading
and execution of these programs when required.
Functionally, the Operating System can be broken down into several functions, all of them
independent of each other. This basic breakdown is as follows:
- Programs support: Creates the conditions necessary for the execution of the different
FMMs and SSMs. It supports the sequential execution of the processes, for which
purpose it “handles the processes” (creates, activates and terminates them) and performs
the process time planning. It provides time services for the implementation of time–outs.
It collects, controls and initiates local actions for all errors detected. It allows for the
execution of Overlay programs.
- CEs communication interface: carrying out allows the rest of the Operating System, to
send/receive messages to/from the Operating System of other modules.

1.
- Network Handler: Directly controls the TI and the switching network.
- Loaders and Initializers: They obtain the load packet, load it into memory and initialize the
different programs.
- Input/Output System (IOS): In charge of the peripherals, the man–machine

communication and direct memory access.
Figure 182 : Operating System functional breakdown
NETWORK & ALL

CIRCUITRY CEs
HANDLER
CEs PROGRAMS LOADERS

INTERFACE SUPPORT &
INITIALISERS
INPUT /
OUTPUT
SYSTEM
P&L
All the kernel OS functions are loaded in all the CEs, but specific functions are loaded only in
the corresponding CEs. In the above example, the Operating System controls the cross–
over in the line TCEs, the input/output system in the P&L TCE, etc.
3.4.3 Database
So far we have seen that all software functions are implemented as FMMs, SSMs or specific
OS modules which will have to handle subscriber and exchange data. In previous systems,
each program had its own data file. This method has two drawbacks: REDUNDANCY, which
means that a piece of data can be stored in more than one place and be used by more than
one program, and INCONSISTENCY, which occurs when a program updates a piece of data

1.
in its own data file, without changing it in the data files of the other programs in which the
same piece of data is stored.
a. Objectives and use
Given modular structure of the software , a piece of data can be used by different
FMMs (data users) not necessarily belonging to the same subsystem and, due to the
A1000 S12 distributed control, these users will probably be executed in different
control elements. Therefore, a solution must be found so that the data can be shared
by the different users. The two above–mentioned drawbacks can thus be obviated.
In summary, a DATABASE can be defined as a “common pool” of consistent data,

shared by different programs.
This DATABASE concept covers two objectives: no data redundancy and data
consistency.
How then are we to implement our DATABASE so as to bring it in line with the FMM
and SSM concepts?
The data will to be stored in zones of the CE memory and/or on disks. If one FMM
requires a piece of data, it will only have to search for that piece of data in that place.
The problem remains how the FMM calculates the physical address of the piece of
data. This problem is resolved with the introduction of programs that handle the data
directly. The function of these programs will consist of accepting data requests from the
FMMs in the form of procedure calls (not through messages), localizing the specific
piece of data in that place and, giving the piece of data back to the user that requested
it.
This set of programs is called DATABASE CONTROL SYSTEM (DBCS).
As a result of the introduction of these programs, data independence is achieved with

respect to the data user programs. This increases the modularity and the future
security of the data. Possible changes in the DATABASE itself will not have any effect
on the programs that use it. Bearing in mind the “Virtual Machine” concept, it can be
stated that the data and the DBCS that handle them form a virtual machine with respect
to the data user FMMs.
Besides convenient data access, another basic database property is that of data
SECURITY, so that the data is protected against unauthorized access and also during
dangerous situations such as data copy or update. The system in charge of providing
this security is the DATA BASE SECURITY SYSTEM (DBSS), which is contained in the
Peripheral & Load module.

1.
Figure 183 : Data Base overview
DATA BASE
CONTROL SYSTEM
DATA
CE 1 CE 2 CE N
PROCESS 1 PROCESS N
b. A1000 S12 relational database
– Definitions.
The Database used by A1000 S12 has a relational structure, i.e. the data is organized
into bi–dimensional tables called relations.
A RELATION is a bi–dimensional matrix where the rows are known as TUPLEs. The
tuples are divided into fields, called DOMAINs, which are the matrix columns. All the
tuples in a relation have the same domains.
An example of a relation, i.e. a bi–dimensional representation of data, is shown in the

next figure.
In the relations, KEY is the name given to the domain or set of domains that uniquely
identify a certain tuple. The different programs achieve the data access, always, by
getting one whole tuple.

1.
ÏÏÏ
Figure 184 : Example of a relation
ÏÏÏ
ÏÏÏ
ÏÏÏ
ÏÏ
ÏÏÏ
ÏÏÏ
ÏÏÏ
ÏÏÏ
ÏÏÏ
ÏÏÏ
ÏÏÏ
ÏÏÏ
ÏÏ
ÏÏÏ
ÏÏÏ
ÏÏÏ
ÏÏÏ
ÏÏÏ
ÏÏÏ
ÏÏÏ
ÏÏ
ÏÏÏ
ÏÏÏ
ÏÏÏ
ÏÏÏ
ÏÏÏ
ÏÏÏ
TUPLE
ÏÏÏ
ÏÏÏ
ÏÏÏ
DOMAIN
KEY
– Types of relations.
The database system distinguishes two types of relations according to whether the
relations exist physically or only logically (such a relation exists only for the user):
1. REAL relations, are relations that are physically stored in memory or disk,
as they have been defined. If a user requires a tuple, it will be presented as a
whole.
2. VIRTUAL relations, are relations that do not physically exist but are supported
by a set of real relations.
There are different types of virtual relations depending on how they are made up:
– REDEFINED.
– MULTITARGET.
– PROCEDURAL.
A REDEFINED VIRTUAL relation is supported by a single base relation and its

domains are a subset of the base relation domains. The key of the redefined relation
must be the key of the base real relation.
Whenever a user asks for a tuple of a redefined relation, the DBCS will search for the
tuple in the corresponding real relation. Only the subset of domains defined for the
redefined relation, will be extracted and presented to the user. This new relation will
have a name different from that of the base real relation.

1.
Figure 185 : Redefined relation

REAL RELATION (ONLY ONE TUPLE REPRESENTED)
D_KEY D_1 D_2 D_3
R_1 A B C D
D_KEY D_3
REDEFINED RELATION
A D
(USER VIEW)
A MULTITARGET VIRTUAL relation is made up of domains of two or more real

relations. Of this set of relations, constituting a multitarget, one is the starting base
relation, the key domain of the multitarget relation being the same as that of the base
real. The joining with the rest of the relations that originate the virtual one, is performed
through the common domains and by means of a JOIN operation.

1.
Figure 186 : Multitarget relation

D_KEY D_1
REAL RELATION R_1 A B
D_KEY D_1 D_2
REAL RELATION R_2 B C D
JOIN
MULTITARGET
RELATION A C D
(USER VIEW)
D_KEY (R_1) D_1(R_2) D_2(R_2)
A PROCEDURAL VIRTUAL relation will be built up by a special procedure when the

regular procedures provided by the database prove inadequate.
Obviously, the relation is not physically stored in memory and is based on one or more
real relations.
Whenever a user requires a tuple of a procedural relation, the DBCS calls the
procedure that searches for the requested information within the relevant real relations.
This procedure will build the requested tuple and present it to the user that asked for it.

1.
Figure 187 : Procedural relation

R_A R_B R_N
A11 A12 A13 B11 B12 B13 N11 N12 N13
PROCEDURE
A13 B12 N11 USER VIEW
A property common to all types of virtual relations is that it is absolutely necessary that
all the base relations are in the same control element as the FMM that requested the
virtual relation.
– Physical location of the relations.
A relation need not necessarily be stored entirely within one CE, nor does it have to be
in a single CE. In other words, a relation may be split up and distributed among a set of
CEs, or copied entirely to more than one CE, or even both.
It is, however, also possible that neither of these two conditions are present; in this
case the relation is called NORMAL.
A relation is said to be DISTRIBUTED when it is split up among a set of CEs. Each of

these CEs has a set of tuples in storage depending on the value of one or more of the
relation domains; these domains are called distribution domains. In this way only that
part of the relation needed in the CE is loaded.

1.
Figure 188 : Distributed relation
DISTRIBUTION
CE_1 CE_2 CE_3
DATA DATA DATA

USER
BASE BASE BASE
DBCS DBCS DBCS
R_1 R_1 R_1
1 6
11
2 7
12
3 8 13
4 9
14
5 10
15
A relation is called REPLICATED when there is an entire copy of the relation in several
CEs. One of the CEs, called master, will control the modifications of the relation tuples
which is important to maintain the data consistency. A replication control procedure can
find which CEs contain a copy of the relation.
Figure 189 : Replicated relation
REPLICATION
CE_1 CE_2 CE_3
DATA DATA DATA

USER
BASE BASE BASE
DBCS DBCS DBCS
R_1 R_1 R_1
1 1 1
2 2 2
3 3 3
4 4 4
5 5 5

1.
When both possibilities occur together, the result will be a DISTRIBUTED and
REPLICATED relation. The distribution always taken place first, and then each of the
parts into which the relation is divided, is replicated on a set of micros..
c. Communication between the user and the DBCS
In order for a user (FMM) to be able to obtain a piece of data from the database, it will
have to call an “interface” procedure that is a component of the DBCS. When the FMM
calls this procedure, a pointer (p) to a data area within the FMM is passed, as a call
parameter, to the DBCS. This data area, that belongs to the FMM, is known as the
USER WORK AREA (UWA) and it is used as the communication area between the
calling process (user) and the DBCS.
Figure 190 : User – DBCS interface

FMM
ÉÉ
UWA
P
ÉÉ
DB STATUS
RUWA
R1
R2
R3
ÉÉÉÉÉÉÉÉÉÉÉÉÉ
ÉÉÉÉÉÉÉÉÉÉÉÉÉ DATA
ÉÉÉÉÉÉÉÉÉÉÉÉÉ R1 R3
DBCS R2
In this FMM data area (the UWA), amongst others, the following main fields may be
found:
1. DB_STATUS:
This field will contain information about the result of the operation requested after
getting back from the DBCS.

1.
2. RUWA:
Relation User Work Area. In this area, one tuple for each of the relations that the
FMM has access to, may be stored.
We will explain the way to make this communication effective with an example.
Let’s suppose that a FMM process (data user) requires to read a tuple of the relation
R_1. The steps to follow are:
1. The call to access the data is done by the process to the DBCS. As said before,
a pointer to the UWA is passed as a call parameter.
2. The DBCS is the system in charge of searching for the data in the data storage
device (memory or disk) and of obtaining the requested relation tuple.
3. If the tuple is found, it is copied into the RUWA for the R_1 relation.
4. An indicator of satisfactory result of the operation will be written into the

DB_STATUS field.
5. The control will be given back to the calling FMM process.
Figure 191 : UWA handling
FMM
1 CALL
GET R_1
5 RETURN DBCS
UWA
DB_STATUS 4 SET
DB_STATUS
RUWA
R_1 DATA
D1 D2 D3 D4
3
R_1
COPY
TUPLE
D1 D2 D3 D4

1.
d. Direct Access Relations
Even though the use of the DBCS for the access to the data stored in the database,
has many advantages, it also has a great inconvenience that we cannot obviate: The
calls to the DBCS take up execution time.
In order to reduce the time necessary to find the requested information, the users are,
in some cases, allowed to access the database by themselves. To accomplish this, the
users look for the relation start address in the database only once, at the initialization
time. For the subsequent accesses, the users simply fetch the data directly from the
database, knowing the relation start position beforehand.
This type of access has an important restriction: it is valid only for read actions on real
relations. For the performance of relation modifications, it will be necessary to call the
DBCS.
3.4.4 Device handler FMMs

The device handlers manage different devices depending on the module used:
a. Device handler in the ASM
In the ASM there are 128 subscribers (256 in X–over) and the ring circuits. They are
handled by the Subscriber Module Device Handler FMM (SMD). The SMD is a
monoprocess multidevice FMM with a separate data zone for each device. The task of
SMD is to manage the busy / free status of the devices.
In addition to the FMM there is an SSM. The SSM is called the Line Circuit, Ring
Circuit Device Handler SSM (LCRC DH SSM). The SSM contains:
– clocked procedures and event handlers to scan the hardware for events;
– interface procedures to drive the hardware (hardware of the subscribers and the
ringing PBA).
b. Device handler in the ISM
In the ISM you find the same device handling software as in an ASM. The device
handler can handle both analogue and ISDN subscribers.
c. Device handler in the DTM
In the DTM there are 31 trunks, which are looked after by the Trunk Circuit Device
Handler FMM (TC DH FMM). The TC DH is a monoprocess multidevice FMM (why ?).
When a DTM is selected, and a trunk request enters, the TC DH selects a free trunk
and marks it busy.
Also the TC DH FMM has an SSM counterpart to perform scanning and driving of the
hardware: the Trunk Circuit Device Handler SSM (TC DH SSM).

1.
d. Device handler in the SCM
In the SCM there are maximum 32 DTMF receivers . The FMM that manages these
devices is called the Service Circuit Device Handler FMM (SC DH FMM). The SC DH
FMM is a monoprocess multidevice FMM.
The SC DH FMM is complemented with the Service Circuit Device Handler SSM (SC
DH SSM). The SSM takes care of the driving of the senders and the scanning of the
receivers. It receives DTMF digits from subscribers and R1 or R2 information from
trunks. It passes the digits one–by–one to the signalling subsystem.
3.4.5 Signalling system
In every access module the signalling is handled by a corresponding signalling system.
In the case of a subscriber module (ASM or ISM) and the trunk modules (DTM or IPTM), the
signalling system has quite a large number of functions. If these access modules have at
least 4 MB memory, the whole signalling system can be present in the access module. If
however the access module only has 1 MB memory, the signalling system is split into two
parts:
- the terminal related functions are stored in the TCE (the access module);
- the call related functions are stored in an ACE. Typically this is the System ACE for Call
Services (SCALSV).
a. Signalling system in the ASM
All subscriber events pass via the signalling FMM (line and register signalling).
For each event signalling ”knows” (from a table) if call control should be notified or not.
The signalling system is called the Analogue Subscriber Signalling System (ASSS).
Since the ASM only has 1 MB memory, ASSS is split into ASSS_TSIG (in the ASM)
and ASSS_ASIG (in a SCALSV).
b. Signalling system in the ISM
The signalling system in the ISM is the ISDN Signalling System (ISS). An ISM has 4
MB memory, so the whole ISS is kept in this TCE.
Because of the CDE dependency of the ISDN signalling systems, ISS is implemented
as a SBS. There are different entities for the different ISDN versions, but also different
entities to handle the different layers in ISDN signalling.
c. Signalling system in the DTM
This signalling depends on the signalling used for the trunk (to which trunkgroup it
belongs). DTM signalling takes care of the line and register signalling between the
exchanges. Here again you can have a split signalling system. Depending on the
signalling type, you have:

1.
– CAS_ASIG (in the SCALSV) and CAS_TSIG (in the DTM);
– ISUP_TUP_ASIG (in the SCALSV, handling both ISUP and TUP signalling) and
ISUP_TSIG, TUP_TSIG (in the DTM).
d. Signalling in the SCM
Here the Register Signalling SSM (RSIG SSM) collects the digits one–by–one from
the SC DH SSM. Once a certain number of digits has been received, RSIG reports
them to the requesting signalling system. The RSIG is always informed about the
requested number of digits, so it knows when the digits should be transmitted in bunch
towards the requesting signalling system.
3.4.6 Call Control
- This plane contains Call and Facility Control System (CFCS). CFCS is a multiprocess
FMM.
CFCS handles:
– the basic call set–up for subscribers;
– the basic call set–up for trunks;
– supplementary services;
– the interface towards the SSF for IN services.
Whenever a call starts, the FMM is activated. Activation means the creation of an application
process.
CFCS is implemented as a SBS:
- the shell is part of the application process.
- each entity has it’s specific task. Entities can be common or CDE. This depends on the
main call control functions they logically belong to:
– basic call set–up: these entities are common;
– supplementary services: these enities are CDE;
– interface to IN: these entities are common.
3.4.7 Auxiliary Resources TCE Allocator
ARTA stands for Auxiliary Resource TCE Allocator. Resource means a DTMF receiver or an
R2 sender / receiver.

1.
ARTA finds a Service Circuit Module that contains the correct receiver or sender and that is
available. Its implemented as a monoprocess FMM and is located in the System ACE for
Call Services.
The actual search for a SCM is performed by a procedural relation. This relation is consulted
by ARTA. Figure 192 explains how the procedural relation works:
Figure 192 : ARTA procedural relation
Procedural Relation
INDEX 1 SCM 1 AVAIL

a 2 SCM 2 UNAVAIL
2
3 SCM 3 UNAVAIL b
d 4 SCM 4 AVAIL
5 5 SCM 5 AVAIL
6 SCM 6 AVAIL
c
ARTA
RUWA
4 SCM 4 AVAIL
Following steps are taken in the procedural relation :
[a]
The index is used to select a tuple from the relation.
[b]
Starting from this index, a sequential search is done until an SCM with the status
AVAILABLE is found.
[c]
The tuple is copied to the RUWA of the ARTA FMM.
[d]
The index is updated to make sure that the next search starts with the next SCM in the
list.
Then we return from the procedural relation.
3.4.8 Analysis of the Called Party Digits
Based upon the received digits, the destination of the call has to be defined. This is done by
an FMM, called PATED (Prefix Analysis and Task Element Definition).

1.
PATED consists of two functional parts
- Prefix Analysis. This part provides a digit preparation and analysis, resulting in a
Condensed Prefix (CPX), a Cause or a request for more digits.
The CPX is a number assigned to all digit combinations which result in a common set of
tasks : all subscribers connected locally, which must be charged in the same way have a
same CPX, while all digit combinations leading to the selection of the same outgoing
route (for outgoing calls) have another CPX assigned to it.
A cause is a number indicating which faulty situation occurred. The cause value found by
PATED could for instance be a value indicating ’DN Not Assigned’.
In the case of a CPX or a Cause, the result is passed to the second part for further
analysis.
In the case of a request for more digits, a message is sent back to CFCS to receive more
digits from the originating side.
- Task Element Definition. This part receives the result from the previous part (CPX or
Cause) and retrieves information about the tasks to be executed to complete the call.
These tasks are : destination information, charging parameters, restrictions, numbering

type and signalling information.
These tasks not only depend on the received digits (CPX), but some of them are also a
function of the time of day, the type of call (normal call, operator call,...) or the origin of the
call (subscriber, incoming trunk,...).
Figure 193 gives an overview of the structure of PATED. We will describe the different
blocks in greater detail.

1.
Figure 193 : PATED Structure
Prefix Analysis Task Element Definition

Request more digits
Received digits Digit preparation
CPX
&
Digit Analysis CAUSE
Tasks
ÉÉ
ÉÉ
ÉÉ
ÉÉ
Task
ÉÉ
ÉÉ
Element
Type of call Category Definition
Analysis
Origin Origin
Analysis
Time Time
Analysis
a. Category Analysis
Here, the Type of call is analysed. Possibilities are : Operator call, Data call, Test call,
normal call, priority call,...
The result of this analysis serves as input for the Task Element Definition and for the
Digit Preparation.
b. Origin Analysis
In this block the origin of the call is defined. This origin is a combination of :
– Type of Numbering Plan (telephone, telex, private numbering plan,...)
– Nature of Address : The Nature of Address specifies the layout of the received digit
stream (International, National, Network Specific,...). This value indicates whether
or not the country code is inserted in the received digit stream, whether or not the
trunk code is inserted ... .
– SourceCode : Defines the type of originating equipment (Subscriber, trunk, test

equipment,...) and the group (subscriber group , trunkgroup,...) to which the
originating device belongs.

1.
The result of this analysis serves as input for the Task Element Definition and for the
Digit Preparation & Analysis.
c. Time Analysis
Here, the time of day is analysed. This analysis result serves as input for the Task
Element Definition block.
d. Digit Preparation
The function of digit preparation is to adapt the layout of the received digit stream to a
standard digit stream layout, used inside the exchange.
Example :
Suppose the standard layout in the exchange is :
0 P Q A B C D E ...
Where P Q = The zone prefix

A B C = The exchange prefix
D E ... = The subscriber identity inside the exchange
If the received digit stream has layout A B C D E..., digits 0 P Q have to be inserted
before the A.
The digit preparation depends on
– The received digits
– The type of call
– The origin of the call (Source code + nature of address + Numbering plan indicator)
Figure 194 gives an overview of the digit preparation.

1.
Figure 194 : Digit preparation

Received digit stream
Origin Digit
Adapted
Preparation digit stream
Type of call
Received digits Origin Type of call Adapted digit stream

Sourcecode Nataddr. Numb. plan
0 P Q A B C D E ... Subscr unknown E164 Normal Call 0 P Q A B C D E ...
A B C D E ... Subscr unknown E164 Normal Call 0 P Q A B C D E ...
P Q A B C D E ... Incoming National E164 Normal Call 0 P Q A B C D E ...

I1 I2 I3 P Q A B C D E ... Incoming Internat. E164 Normal Call 0 P Q A B C D E ...
... ... ... ... ... ...
e. Digit Analysis
In this block the received digits are analysed to define the destination and the tasks to
be executed to reach that destination. For the analysis of the digits, we use a tree
structure. Figure 195 shows the layout of this tree. Each element of the tree contains
16 entries. The first digit, D1 is used as an index in the first element. Here we find a
pointer to a next element. Now we use the second digit, D2 as index in this new
element. Again we will find a pointer to a new element.
We will continue with this algorithm, each time using the next received digit (D3, D4,...),
until we find an indication that the prefix has been analysed. In the last entry we will
find a Condensed Prefix (CPX) or a CAUSE. This result is now passed to the last
block, the Task Element Definition.
The result of digit analysis not only depends on the received digits, but also on the
origin of the call. This is implemented by making the entry point in the tree structure
origin dependent. In the block Origin Analysis, we will find the entry point in the tree
structure. From this entry point on, we will start analysing the received digits. This
implies that for another origin, we will follow a completely different branch in the tree
and so the final result will be different.

1.
Figure 195 : PATED Tree structure

Numbering plan
indicator
Nature of address Origin
0
Analysis 1
SourceCode D1 ...
...
15
... D2 ... ...
... ... ...

... ... D3 ...
... ... ...
Digit Analysis
Result
(CPX or CAUSE)
f. Task Element Definition
This block defines the tasks that have to be executed to reach the desired destination.
Most tasks depend not only on the Analysis result (CPX),, but also on the origin, the
type of call and even the time of day. Therefore the outputs of all 4 blocks of the prefix
analysis part (see figure 196) serve as input for this Task Element Definition block.
The most important information we find here includes :
– Do we have a terminating or an outgoing call
– Do we have open numbering or closed numbering. What is the length of the

number.
– Is it a priority call or not
– If we have an outgoing call, after how many digits do we start trunk selection
– ...

1.
Type of
Extra Information
call
LOCAL DNET of Called Subscriber
OUTGOING Routecode , start selection point, ...
So far, we have only discussed the successful analysis of an existing prefix. Now let us
see what happens if something goes wrong.
– We did not receive enough digits (yet) to find a Condensed prefix.

Suppose we received 3 digits from the originating device. After having analysed the
third digit, we still have not found a CPX. In that case, PATED will send a message
back to Call Control, asking for one or more digits. After having received some
more digits, Call Control will send all digits back to PATED, where digit analysis
continues.
REMARK: The number of digits, which is sent to PATED, is always greater than or
equal to the number of requested digits retrieved from OLCOS . For example: an
ISDN subscriber provides all the called digits in one message, so all the digits are
transmitted to PATED and there will not be a request for more digits.
– Another possibility is that the received number does not exist. Instead of finding a
condensed prefix (CPX), the digit analysis output will give us a CAUSE. Now we will
have to find out what we have to do to end the call properly (e.g. It will tell us that we
have to send a congestion tone to the calling subscriber.)
This is done by the same Task Element Definition block. This time we will send the
CAUSE value instead of the CPX to the Task Element Definition. Now we will find a
list of tasks that have to be executed to end the call. Just as in the normal case,
these tasks are also a function of the Origin, Type of Call and Time of day.
– This feature of PATED is also useful if we find other problems during the call
handling. (e.g. we can not find a free DTMF receiver, A timer expires, a Q931
protocol error is detected,...)
Each possible problem is identified with a CAUSE value. When such a problem
occurs, we will send the corresponding CAUSE value to PATED. In PATED, the
Digit Analysis step is skipped and we jump immediately to the Task Element
Definition step. Here, too, we find a list of tasks to solve the problem.

1.
Figure 196 : PATED for CAUSE analysis
Digit preparation
&
Digit Analysis
CAUSE
Tasks
ÉÉ
ÉÉ
ÉÉ
ÉÉ
Task
ÉÉ
ÉÉ
Type of call Category Element
Analysis Definition
Origin Origin
Analysis
Time Time
Analysis
3.4.9 Subscriber analysis
a. Subscriber data in general

During a call a lot of information about subscribers is needed. Some of the data is
required to set up the call, other information describes the facilities that a subscriber
may have. Since the amount of data is so big, the data is stored in two locations:
– the data that is required to set up the call is stored in the subscriber’s TCE itself. We
call this the subscriber data at TCE level. The data is retrieved by the device handler
FMMs and the signalling FMMs;
– the rest of the subscriber data, including possible facility data, is stored in an ACE.
This ACE contains both the originating and the terminating profiles . The FMM
that retrieves all the subscriber data in the ACE is the Local Subscriber
Identification (LSIF) FMM. We therefore talk about the subscriber data at LSIF
level.
The ACE that is mentioned here is the SACELSIF. Please refer to chapter 4.2.4..c for
more information on this ACE. At this moment it is important to know a little about the
configuration of this ACE.

1.
The SACELSIF works in an active / stand–by configuration. The amount of subscribers

a SACELSIF can handle is limited. So in a medium, and certainly in a large exchange
there will be a number of these SACELSIF pairs. The problem then of course is to
know which one of these pairs to choose when the subscriber data at LSIF level is
required. The directory number equivalent thousands (DNET) of the subscriber that
is anlysed, is used for that purpose. This applies to both an originating subscriber, as to
a terminating subscriber.
First let us have a look at the subscriber data itself. Figure 197 shows the organisation
and location of the subscriber data.
Figure 197 : Subscriber Data location
COL
COS
DNE
OLCOS DNE analysis facility_1
TCE level facility_2
LSIF level
The next chapters describe these data blocks one by one.
b. Class Of Line (COL)
The COL gives information about the physical line that is connected to the exchange.
For an analogue subscriber it indicates amongst others:
– the settings of the hybrid on the ALCN board;
– the type of set (push button set, dial pulse set, combined set);
– whether a hardware key is used on the set.
c. Originating Line Class of Service (OLCOS)
This is the data we need when a subscriber originates a call. The OLCOS data is the
bare minimum data to set up a call. The most important fields of this OLCOS are:
– the terminal number or data key. This is the index into this data;
– the directory number equivalent (DNE). Such a DNE consists of the directory
number equivalent thousands (DNET) and the directory number equivalent units
(DNEU) ;

1.
– if the tuple represents a subscriber’s line, the equipment number (EN) is given. The
EN consists of the LCE identity of the TCE and the terminal number or datakey;
– if the line belongs to a PABX, the PABX identity is given;
– the tone map, that indicates which dial tone to apply.
d. DNE analysis
The DNE analysis indicates:
- the type of directory number (DN). Some possibilities are:
– not assigned number;
– normal subscriber line;
– Multi–Subscriber Number (MSN);

– Direct Dialling–In Extension (DDI–Ext).
– depending on the type of DN, further information is given:
– if the DN represents a single subscriber line, the equipment number (EN) is

given. The EN consists of the LCE identity of the TCE and the terminal number
or datakey;
– if the DN represents a line of a PABX, the PABX identity is given.
e. Class Of Service (COS)
The COS data gives information about both public subscribers (analogue and ISDN)
and BCG subscribers.
The COS data contains both the originating COS data and the terminating COS data.
f. Facility data
The data that describes the different facilities is stored in separate relations. As an
example there is a relation that holds the abbreviated dialling information, an other
relation that holds the call forwarding information, and so on.
If a subscriber does not have any facilities, no tuple out of these relations are allocated
to this subscriber.
If an operator assigns a facility to a subscriber, a tuple from the relation that describes
that facility is allocated to the subscriber. The tuple is then linked to the subscriber’s
COS data. If a second facility is assigned, a tuple from an other relation is allocated
and linked to the COS data as well. The COS data and the facility data thus form a
chained structure. The reason for implementing the facility data in a chained structure,

1.
is that you only have to use a tuple of a particular facility relation if the subscriber has
that facility.
In the example of figure 197 the subscriber appears to have two facilities.
g. Retrieval of data for originating subscribers
To describe the subscriber data in detail and how it is retrieved, let us have a look at an
example. Let us assume closed numbering with seven digits. Let us call the digits
D1D2D3D4D5D6D7. Figure 198 indicates how the DN can be broken up into the DNET,
the DNEU and the DNEH.
Figure 198 : DNET, DNEU and DNEH

DNEU
D1 D2 D3 D4 D5 D6 D7
DNET
DNEH
Figure 199 gives an overview of the subscriber data structure.
Figure 199 : Subscriber data in detail

TCE level LSIF level
COS link
TN or DK DN analysis chain
00
DNET block
formula of COS
OLCOS DNEU
D5 100
DNEH tuples
facility_1
99
DNEH
analysis 00
facility_2
D6D7
99
The subscriber data is retrieved in the following sequence:

1.
[1]
The OLCOS data is retrieved in the TCE. The key to this data is the terminal number
(TN) or the data key (DK). The DNET is amongst others used in the SCALSV to find
the correct SACELSIF.
Note : An analogue subscriber can only have one profile stored at TCE–level in R_OLCOS; that
profile is stored against the TN. An ISDN BA can have up to 8 MSN’s assigned to the same access,
thus to the same TN, and for each of these MSN’s, a separate profile can be stored. For each MSN,
a tuple has to be stored in R_OLCOS. At TCE–level, a specific procedural relation, called the
SCREENING PROCEDURE, will translate the TN and MSN in a new parameter called the DataKey
(DK), which is used as a key in R_OLCOS.
[2]
In the SACELSIF the first action is to find the directory number equivalent hundreds
(DNEH). The DNEH is calculated with a formula: DNEH = (DNET – 1) * 10 + D5 + 1.
[3]
The DNEH is then analysed. The DNEH can represent:
– a block of 100 DNs for normal subscribers;
– a block of 100 DNs reserved for an indialling PABX;
– an unused block of 100 tuples.
If we assume that the DNEH represents a block of 100 DNs for normal subscribers,
then the DNEH analysis gives a link into the DN analysis block.
[4]
To find the correct entry in the DN analysis block, you have to take the link as provided
by the DNEH analysis and increment it with the last two digits of the DN (D6D7, in the
range of 0 to 99). The DN analysis gives the information as presented in chapter d.
This includes the type of DN and further information. If we assume a single subscriber
line, the ’further information’ also contains a link to the COS link chain.
[5]
The COS link chain always contains at least one link: the link to the COS. This data is
always required. If the subscriber has facilities, then further links can link all the
additional tuples (in different relations) together.
[6]
The COS data was described in chapter e. The facility data was described in chapter f.
h. Retrieval of data for terminating subscribers
In the case of a terminating call, PATED gives us:
– an indication that it is a terminating call;
– the DNET value of the terminating subscriber. This value was derived during digit
analysis.

1.
In CFCS, we collect the remaining digits (D5, D6 and D7) from signalling. We use the
DNET value to find the appropriate SACELSIF and send a request to LSIF to start
subscriber identification. As in figure 201 LSIF retrieves the EN of the terminating
subscriber, together with the subscriber data. With the EN we have know the location
of the B–party.
i. Restriction match
In the case of a terminating call, LSIF has to examine if the call is allowed to continue.
This check is called the restriction match. Figure 200 shows how it is implemented.
Figure 200 : Restriction match

Access Status
normal line dataline coinbox operator line

normal call
priority call
Calling
Party
Category
operator call CAUSE CAUSE CAUSE
testcall
– No CAUSE
– Destination restricted
There is a restriction match table. We select a row using the Calling Party Category
(CPC) as index. For originating calls, the CPC comes from the COS data. For
incoming calls, the CPC value is retrieved from the remote exchange via signalling
(sent from the remote exchange as a Type Of Call (TOC)).
In the selected row, we use the access status as index to pick out one element. The
access status was retrieved from the TLCOS. The value in the selected element tells
us if the call is allowed (no Cause) or not (destination restricted).

1.
Figure 201 : LSIF

LSIF
DNET,DNEU RETRIEVAL OF
OLCOS OLCOS
originating subscriber
terminating subscriber
Prefix DNET
Digits RETRIEVAL OF
PATED DNEU TLCOS
OK/
NOK
CALLING PARTY Restriction
CATEGORY Match
3.4.10 Trunk Search
Figure gives an example of (a part of) a network. Suppose that a subscriber from exchange
A wants to call a subscriber from exchange D. In the following chapters you find a number of
definitions that are used in the routing of this call.

1.
Figure 202 : Routingblock – Route
Exch C
Exch A Exch D
Exch B
a. Trunk
A trunk corresponds with one channel of a PCM link. A trunk is bi–directional. To avoid
that the exchanges at either side of the trunk try to seize the trunk simultaneously, two
possibilities exist:
– you can declare some of the trunks as outgoing and the rest of the trunks as
incoming. The fact whether a trunk is outgoing or incoming only reflects which
exchange can seize the trunk: an exchange can only seize the outgoing trunks. As a
result, the trunks that are declared as outgoing in one exchange, have to be
declared as incoming in the exchange at the other end of the PCM link and vice
versa.
– you can also declare the trunks as bothway trunks. In this case both exchanges can
seize the trunk. In this case the possibility of a collision exists. The software then
has to solve the problem.
Every trunk has to be handled by a particular signalling system. This way the seizure
and all the other events of the trunk can be reported to the exchange at the other side
of the trunk, but also the digit information can be reported.
Note : Let us abbreviate trunk to TK.
b. Trunkgroup
Trunks that have the same characteristics can be grouped into a trunkgroup. Typically
”the same characteristics” means:

1.
– interconnecting the same exchanges;
– having the same direction (outgoing, incoming or bothway);
– using the same signalling system (for example MFC, CCS N7).
Figure 203 : trunkgroups – Trunks
30 trunks
DTM 1 DTM 1
30 trunks
DTM 2 DTM 2
Trunkgroup AB1
R2 trunks
Exch A Exch B
30 trunks
IPTM 1 IPTM 1
31 trunks
DTM 3 DTM 3
30 trunks
IPTM 2 IPTM 2
Trunkgroup AB2
Nr7 trunks
In figure 203 exchange A is connected to exchange B with 5 PCM links. There are two
trunkgroups: trunkgroup AB1, with R2 trunks and trunkgroup AB2 with CCS N7 trunks.
The equipment number of a trunk consists of the LCE identity of the trunk module +
the channel number, or the trunkgroup identity and the trunk sequence number.
In the figure, trunkgroup AB1 contains 60 trunks, spread over 2 DTMs, while trunkgroup
AB2 contains 91 trunks, spread over 2 IPTMs and one DTM.
Note : Let us abbreviate trunkgroup to TKG.

1.
c. Route
The collection of all the trunkgroups between two exchanges is called a route. At
present this definition is primarily used for administrative and traffic management
purposes.
d. Trunkgroup combination
At present subscribers can demand a certain minimum bearer capability of the

network. Possible bearer capabilities are:
– speech;
– 3.1 kHz audio;
– 64 kb/s unrestricted digital.
In addition, if the subscriber has activated certain facilities, possibly a minimum

signalling dependency is also required. Possible signalling dependencies are:
– any;
– digital mandatory;
– ISDN signalling preferred;
– ISDN signalling mandatory;
– ISUP signalling mandatory.
Hence, when a call is outgoing and a trunk has to be selected, it is possible that not all
the trunkgroups can be used, if they do not support the minimum bearer capability or
signalling dependency. Therefor a restriction has to be built in to the trunk search
mechanism. Observe the following figure.

1.
Figure 204 : Definition of trunkgroup combination lists and trunkgroup combinations
trunkgroup Characteristics
4 ISUP Digital transmission tkgcom AC3
5 ISUP Analogue transmission
6 R2 Analogue transmission Exch C
6
5
tkgcom AC1
4
trunkgroups tkgcom AC2
Exch A
3
tkgcom AB3
2 tkgcom AB2
trunkgroup Characteristics
1 ISUP Digital transmission Exch B
2 TUP Analogue transmission
3 R2 Analogue transmission
tkgcom AB1
Routingblock to Exchange B :
BC Sign. System subrouteblock Route AB Route AC

Speech , Audio any subroutingblock 3 tkgcom AB3 tkgcom AC3
Digital any subroutingblock1 tkgcom AB1 tkgcom AC1
Speech , Audio digital signalling subroutingblock 2 tkgcom AB2 tkgcom AC2
Digital digital signalling subroutingblock 1 tkgcom AB1 tkgcom AC1
Speech , Audio ISUP preferred subroutingblock 2 tkgcom AB2 tkgcom AC2
Digital ISUP preferred subroutingblock 1 tkgcom AB1 tkgcom AC1
Speech , Audio ISUP mandatory subroutingblock 4 tkgcom AB1 tkgcom AC2
Digital ISUP mandatory subroutingblock 1 tkgcom AB1 tkgcom AC1
In the route AB there are three trunkgroups:
– trunkgroup 1 (ISUP signalling);
– trunkgroup 2 (TUP signalling);

1.
– trunkgroup 3 (R2 signalling).
Suppose that you need a trunk from exchange A to exchange B. If a bearer capability
of digital and a signalling dependency of ISUP mandatory is requested, then only a
trunk of trunkgroup 1 can be selected. If however a bearer capability of speech and a
signalling dependency of ISDN preferred is requested, then both trunkgroups 1 and 2
comply.
So based on the required bearer capability and signalling dependency, a subset of the
trunkgroups from a route can be declared. This subset is called a trunkgroup
combination.
Note : Let us abbreviate trunkgroup combination to TKGCOM.
e. Subroutingblock
In figure 205 you can see three exchanges. For a particular call from exchange A it
may be possible that both a trunk via exchange B or a trunk via exchange C can be
selected. The collection of trunkgroup combinations that lead to the correct destination
is called a subroutingblock.
The definition of a subroutingblock is important for the routing of a call, since it only
contains trunks that (eventually) lead to the correct destination. The definition of a
subroutingblock also guarantees that it only contains trunks that comply with a
particular bearer capability and a signalling dependency.
Note : Let us abbreviate subroutingblock to SRTGBL.
f. Routingblock
The collection of all the trunkgroups that (possibly) lead to the correct destination, is
called a routingblock. This destination does not have to be an adjacent exchange.
Note : Remark that the definition of a routingblock does not indicate any dependency. It only
indicates the routing of a call.

1.
Figure 205 : Routingblock – Route
Exch C
Route AC
Exch A Exch D
Route AB
Exch B
In Exchange A : RoutingBlock Destination Routes

1 Exch B Route AB + Route AC
2 Exch C Route AC + Route AB
3 Exch D Route AB + Route AC
The table in figure 205 gives an overview of all the routingblocks, defined in exchange
A. We see that exchange A is not connected to exchange D, yet we define a
routingblock to that exchange D (routingblock 3). If we want to set up a call to
exchange D, we can select route AB or route AC, because exchange D is reachable
through exchange B or exchange C.
A routingblock is identified with a routingcode. For outgoing calls, PATED translates

the dialled digits into a routingcode, which is used to select a free trunk to reach the
correct exchange.
When PATED gives a routingcode, the restrictions for bearer capability and signalling
dependency have to be built in. We call this the routingcode modulation. The result is
a subroutingblock.
Note : Let us abbreviate routingblock to RTGBL.
g. Trunkgroup combination list
In the previous chapters we collected the trunkgroup combinations that lead to the
same destination into a subroutingblock. If you require traffic distribution over the
trunkgroup combinations is required, or if you require overflow possibilities, you can

1.
define a step in between the subroutingblock and the trunkgroup combinations: the
trunkgroup combination list. Observe the following example:
Figure 206 : Example of trunkgroup combination lists
Exch B
50%
Exch C
first choice
30%
20%
Exch A
Exch D
overflow choice
50%
Exch E
50%
Exch F
The first choice is via exchanges B, C or D, with a respective traffic distribution of 50%,
30% and 20%. The overflow choice is via exchanges E or F, with a traffic distribution of
50% and 50%. The result is the following hierarchy:
Note : Let us abbreviate trunkgroup combination list to TKGCOML.
Figure 207 : Routing hierarchy with trunkgroup combination lists

SRTGBL
first choice overflow choice
TKGCOML_1 TKGCOML_2
50% 30% 20% 50% 50%
TKGCOM_1 TKGCOM_2 TKGCOM_3 TKGCOM_4 TKGCOM_5
Trunkgroup combination lists are optional in the routing hierarchy !
h. Distribution group
If in a country several carriers operate the telephone network, it is possible that to

reach a certain destination, the traffic has to be distributed between these carriers.
These carriers have defined complete subroutingblocks. As a result the traffic

1.
distribution has to be defined between the routingblock (indication of the destination)

and the subroutingblocks.
Therefore distribution groups have been defined. A distribution group contains a

number of subroutingblocks, each corresponding with a particular carrier, and indicates
the traffic distribution values between them.
Distribution groups are optional in the routing hierarchy !
Note : Let us abbreviate distribution group to DISTRG
i. Routing hierarchy
Figure 208 : Routing hierarchy
RTGBL
distrg Y
needed?
DISTRG
N
SUBRTGBL
tkgcoml Y
needed?
TKGCOML
ROUTE N
TKGCOM
TKG
TK
j. FMMs involved
There are three FMMs involved in the selection of a trunk.
– Trunk Request Coordinator (TRC) : responsible for the routingcode modulation, the
selection of a trunkgroup combination and the selection of a trunkgroup within that
trunkgroup combination. The selected trunkgroup identity is sent to the next FMM,

1.
the Trunk Resource Allocator (TRA). The TRC is located in the same CE as CFCS,
i.e. in each SCALSV.
– Trunk Resource Allocator (TRA) : selects a DTM with free trunks belonging to the
requested trunkgroup. The LCE–Identity of the selected DTM is sent back to CFCS.
Also the Device Interworking Data is retrieved here (see figure 209). All TRA’s in an
on–line exchange are located in dedicated CE’s called SACETRA.
– The Trunk Circuit Device Handler (TC DH FMM) : selects a free trunk belonging to
the requested trunkgroup and establishes a UCP towards the DH of the incoming
side (SMD FMM or TC DH FMM)
Figure 209 : Trunk selection

Prefix BC
PATED CFCS
Routingcode Sign.Type
TRC
Trunkgroupcombination
Trunk group
TRA
DTM–id
DID–data
REMARK: The inputs indicate information, so these arrows are no messages.
3.4.11 Device Interworking Data
Apart from the selection of a free and compatible trunk, another very important task remains
to be done : retrieval of the Device Interworking Data (DID) .
The DID is a task map describing all necessary tasks to connect the originating device
(calling subscriber or incoming trunk) to the selected terminating device (outgoing trunk or
terminating subscriber).

1.
The originating device is identified by the subscriber group identity in the case of an
originating subscriber or by the trunkgroup number in the case of an incoming call.
The data is retrieved by the TRA FMM and sent back to CFCS.
The Device Interworking Data are subdivided into:
- incoming tasks: these tasks are executed by the incoming signalling. Examples:
– new value for inter–digit time–out;
– send a call–in–progress tone to the incoming device.
- outgoing tasks: these tasks are executed by the outgoing signalling. Examples:
– digit forward sending point;
– digit preparation;
– calling line identification restriction;
– moment of through connection (upon address complete, upon answer,...).
- common tasks: these comprise additional tasks or call control. Examples:
– perform charging or not.
3.4.12 Private Access Resource Management (PARM)
So far, we have discussed two types of called devices :
- Subscriber lines : In this case LSIF is called to translate the called DN into the EN of the
called subscriber.
- Outgoing trunks : Here, we call the Trunk Search FMMs is called to select an outgoing
trunk to the correct destination.
In this chapter we will discuss a third type of called device : The Private Automatic Branch
Exchange (PABX).
A PABX is a switching network, located on the customer’s premises, serving a number of

extensions. It is connected to the public exchange by means of a number of lines (Analogue
or BA) and/or a number of trunk connections (Analogue trunks, Digital CAS–trunks or
PRAs).
Figure 210 gives an overview of a few PABX types.
- PABX without indialling : The PABX is identified by means of the General Directory
Number (GDN) . For a call to this GDN, we have to select a free access towards the

1.
PABX. The process of selecting a free access is called hunting. Inside the PABX, the
call is routed to an attendant . This person is responsible for routing assistance. The
attendant can establish a further through connection between the incoming call and the
desired PABX extension . The extensions are invisible to the public exchange.
- PABX with indialling : In such a PABX, the extensions can be reached immediately from
the public exchange. Apart from the GDN, we assign a DDI range (Direct Dialling In
range) to the PABX. In the figure the DDI range is from 00 to 99. Each number
inside this DDI range corresponds to one extension.
To identify an extension in the public network, we take a Prefix value, assigned to the
PABX, in combination with the extension number. In the example the PABX prefix is
24037. To reach extension 69, the DN = 2403769 has to be dialled.
The signalling towards the PABX must contain at least the dialled extension number. This
is used to establish a connection inside the PABX towards the correct extension.
In the public exchange, hunting is based on the dialled prefix, not on the GDN. In such a
case the GDN is only needed to uniquely identify the PABX.
- Hunt group : We can also group a number of individual lines into a hunt group. This
hunt group is also identified via a GDN. A call towards this GDN will give a hunting over
the lines.
Each line is also assigned an individual DN (IDN) . A call towards this individual DN is
also possible, but in this case no hunting is involved.

1.
Figure 210 : PABX types
PABX without indialling : Attendant
Call routed
to attendant
.
PABX .
(GDN = 2403600)
.
Hunting on GDN
00
PABX with indialling : Attendant

01
Call routed
to extension 02
PABX .
.
(GDN = 2403700) .
99
Hunting on prefix 24037
Huntgroup :
IDN1 = 2403801
IDN2 = 2404523
IDN3 = 240 2534
Hunting on GDN = 2403800
In System 12, the Private Access Resource Manager (PARM) is responsible for the hunting
process and the class provision of PABXs or hunt groups. PARM is located in a dedicated
System ACE, working in Active/Standby mode. Following tasks have to be executed :

1.
a. Class provision
All classes (originating as well as terminating) of PABXs, hunt groups or citylines

are stored in the system ACE where PARM is located. PARM is responsible for the
retrieval of these classes for originating and terminating calls. Figure 213 shows the
retrieval of classes.
Figure 211 : Class provision

A. Originating calls.
DNET,DNEU PABX–Id
TN OLCOS LSIF PARM
Originating classes
B. Terminating Calls.
Remaining
digits
Prefix DNET PABX–Id

PATED LSIF PARM
digits
Terminating classes
Restriction match
b. Hunting
In the case of a terminating call towards a PABX or hunt group, PARM selects a free
access towards the PABX. Figure 214 gives an overview.

1.
Figure 212 : Hunting

Hunt Id. (Derived from PABX–Id)
Signalling System
BC Reduced Hunting
Hunt group Modulation
Hunting Hunting Hunting

Subgroup block Subgroup block Subgroup block
LineGroup TrunkGroup
EN EN DTM–Id DTM–Id
First of all, the Hunt Identity has to be defined. This hunt identity is derived from the
PABX identity. It can be compared with a RouteCode identity in the case of trunk
search (see TRC–TRA). The hunt identity defines a HuntGroupBlock.
Each Hunt group block is further subdivided into Hunting Subgroup blocks. The
selection of a subgroup block depends on :
– The Hunt Identity
– The required Bearer Capability
– The required signalling system
– A Reduced Hunting indication. In the case of reduced hunting, we will only select
free accesses from a subset of all available accesses. This can be useful during low
traffic periods, when only a few lines of a hunt group are being served.
This selection process is almost identical to the Route code Modulation used in Trunk
Search.
Each hunting subgroup block consists of a number of line groups and/or trunkgroups.
A line group consists of a number of individual lines (analogue or BA) having the same
characteristics. A trunkgroup was already been defined in the chapter on trunk search.
In the case of a line group, the hunting procedure will select a free line belonging to that
group. This line is identified by its EN.

1.
In the case of a trunkgroup, PARM selects a DTM with free trunks belonging to the
selected trunkgroup. The selection of a free trunk within this DTM is left to the TC DH
FMM.
c. Queue service
If all accesses towards a PABX or hunt group are busy, it is possible exists to queue a
call until an access becomes free. This process of queuing is done by the PARM FMM.
Whenever a line or trunk towards a PABX/hunt group becomes free, the DH informs
PARM. Here, the queue is checked. If there is a call on the queue, it will be offered to
this access.
3.4.13 Physical mapping of the software onto control elements

Figure 213 : Physical mapping of the software onto control elements
SCALSV
PATED TRC ARTA
TRA
CFCS SACETRA
LSIF PARM
ASSS_ASIG ... _ASIG
SACELSIF SACEPBX
ASSS_TSIG ISSS ... _TSIG RSIG
SMD FMM SMD FMM TC DH FMM SC DH FMM
LCRC DH SSM LCRC DH SSM TC DH SSM SC DH SSM
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
HARDWARE HARDWARE HARDWARE HARDWARE
ASM
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ ISM DTM SCM

1.

1.
4. 1000 S12 EXCHANGE CONFIGURATION
4.1 Input/Output exchange devices
From the administrator point of view, access to Alcatel 1000 S12 is provided by a set of I/O
interfaces which provide a set of tools to maintain and operate the exchange. This
administration device can be split into the following two groups: Man–Machine
Communication and Mass Storage.
The Man–Machine communication (MMC) devices are basically VDUs and printers. The
VDUs can be system specific VDUs or PCs on which VDU simulation programs are
executed. Their main objective is to control the whole exchange by entering the proper
orders (Operator Request Jobs). Both VDUs and printers are used to dump autonomous
system reports and ORJ reply reports.
These devices are connected to the P&L modules by serial channels – 1200 b/s using the
DMCA PBA or, 9600 b/s using the MMCA PBA–. After the activation procedure, each of
these connections is named ’MMC channel’.
Figure 214 : Man Machine Communication devices
VDU & PCs
Serial Lines
EXCHANGE
PRINTERS
On the other hand, there are also mass storage devices. These devices are used to store
the software and the data of the exchange as well as statistical and charging data which are
very useful for the administration of the exchange. It is important to note that the size of the
exchange is sometimes small and the quantity of required data large. In such cases, the new
data is transmitted to a remote center (NSC, EDPC..), where it is processed.

1.
The mass storage devices are mainly the Magnetic Tape Unit, the Magnetic Disk and the
Optical Disk.
The Magnetic Tape is the most commonly used device with large capacity and sequential
access. The digital recording is carried out by using a plastic tape covered with a layer of
magnetic liquid. This magnetic tape is moved by two reels and the data is read/written by a
R/W head.
On the other hand, magnetic disk memories are large capacity memories with a lower cost
than random access memories. A disk is made of metal coated with a ferromagnetic
material, and rotating under one or more read/write heads. The reading and writing principle
is the same as for magnetic tape.
These hard disks have an embedded controller that performs all address calculating and
address translating functions, as well as driving functions of the hard disk. To the outside
world, the hard disk looks like a SCSI device. The hard disks support re–selection, which
means that they can act as an initiator in an SCSI environment.
The re–writable optical disk combines the advantages of two capacity worlds: the medium
and the high. It ranges in the order of 600 MB. The information carrying medium of an optical
disk is a 5.25” cassette that contains a compact disk (CD). This CD consists of an alloy of
transition and rare–earth materials. The alloy can be magnetized only when it is hot, but it
keeps its magnetic field when it is cool.
Therefore, the writing principle of the optical disk consists of a laser heating up the spot to
be written just before the head of the optical disk writes the information in a magnetic way.
The reading is based on the laser scanning the disk’s surface and detecting any difference
in the angle of reflection caused by upward or downward pointing magnetic fields. So the
read write principle of the optical disk is in fact a magneto–optical principle.
The optical disk used in A100S12 is equipped with an embedded SCSI controller. This
controller handles all the driving functions for the optical disk, and makes it look like an
ordinary SCSI device to the outside world. The most common specifications of optical disk
are 652 MB of capacity and 1.4 MB per seconds as transfer rate (at SCSI interface).
This optical disk might be used as system disk instead of the magnetic disk, but it presents
two problems at the moment: first, the writing/reading operations are performed in a
sequential way, therefore the data access time is slower than for the magnetic disk, and
second, the writing towards the optical disk is limited.
There are other special I/O devices such as MPTMON (Multi–processor Test Monitor).
This terminal is mainly used for integration tests, although it is also useful for other purposes
such as installation and maintenance.
It may be a specific VDU or one PC running the suitable simulation program. In any case,
the terminal is connected to the associated CE via a serial line. The CE is called PTCE
(Permanent Test Control Element). This CE contains the software necessary to carry out its
functions (e.g. access to target CEs, debugging of programs, message traces, etc...). The

1.
results are displayed on the screen for further analysis. The software located in this CE
provides access to the target CE memory as well.
Figure 215 : MPTMON architecture
ACE
LTCE
TTCE PTCE
DSN
PLTCE MPTMON
VDU OR PC
4.2 Control Elements
4.2.1 Control element configurations
As seen in the previous chapters, the A1000 S12 control is distributed among the exchange
processors. These processors are located in different modules, each of them performing a
specific function in the system.
The function of a particular module may be critical to the whole system operation, therefore it
must be replaced immediately after a malfunction. On the other hand, the replacement of
CEs that perform non critical functions may be delayed. Taking this fact into account, the
system modules will work in different modes:
a. Simplex
For CEs with non critical functions. Only one module is equipped to control a cluster.
b. Active/Hot stand–by
The module function is critical to the system operation and one pair of modules must be
equipped. The two modules work in parallel and provide exactly the same output. A
specific device must at all times select one of the two outputs.
c. Active/stand–by
The module function is critical, but the pair of modules do not work in parallel. The
stand–by module collects the output information from the active one in order to update
its own data so that it is ready to take over in case of failure of the active one. The
updating refers only to the data, since the complete set of programs are stored in its
memory.

1.
d. Load sharing
The functions will be shared among several modules that form a group. When
requested, one of the modules in the group performs the function. This way, the failure
of one of the modules simply increases the work load of the others.
e. Spare
If another CE goes off line, then a spare CE can be loaded with the correct GLS, DLS
and PLS to take over from the malfunctioning CE. The take over should be defined in
database (per CE).
f. Cross–over
In this case, two CEs are able to reach two different clusters via hardware links. Each
CE is assigned to control one of the two clusters but, in case of failure of one of them,
the other CE takes the control of both clusters. This CE simply increases its work load.
The cluster data is updated in both CEs, but only the software functions that are in a
stable phase can be taken over when the control switch is produced (i.e. only calls in a
stable state are maintained).
4.2.2 Terminal Control Elements (TCEs)
The TCEs are CEs which control a cluster (lines, trunks, etc.). The main TCE names and
functions are described below:
a. Analogue Subscriber Module (ASM)
The associated TCE is named JLTCE. This TCE can handle up to 128 analogue
subscribers having an average traffic flow of 0,275 E per line. These modules work in
Cross–over.
b. ISDN Subscriber Module (ISM)
The associated TCE is named ISMTCE. This CE can handle up to 64 basic accesses,
having a total traffic flow of 35,2 E, or an average flow of 0,275 E per B channel. These
modules work in Cross–over. The equipped OBC is known as ISMOBC.
c. IRSU Interface Module (IRSUIM)
The associated TCE is named IRSUIMTCE and, connected to a set of IRSUs in

multidrop, handles up to 8 mixed analog/ISDN subscriber IRSUs. These TCEs work in
Cross–over mode. The maximum number of subscribers to be handled by a pair of
IRSUIMTCEs is 1024 analogue lines, 512 digital or a combination. The equipped OBC
is known as IRSUOBC.
d. Digital Trunk Module Low (DTML)
The name of the TCEs associated with these modules depends on the kind of
signalling to be handled. For example:

1.
. DCASTCE: For CAS signalling.

. DISUPTCE: For N7–ISUP (the N7 ISUP user is handled by this module,
but the signalling link is handled by the DTM
High modules).
These modules work in Simplex mode.
e. Improved Service Circuit Module (ISCM)
The associated TCE name depends on the MF signalling system to be handled and on
the supported simplified conference bridge. Two common types of modules are:
. ISVCE–A: To control 32 MFC R2 or DTMF.

. ISVCE–B: To control 16 MFC R2 or DTMF, and 6 SCB.
In case of handling 32 MF signalling inputs, the overall maximum traffic flow supported
is 22,8 E; however, if only 16 inputs are handled, the traffic flow becomes 9,5 E.
These CEs work in Load sharing mode, having one CE group for each signalling type.
The equipped OBC is known as ISVOBC.
f. Digital Announcement Module (DIAM)
The associated TCE is named DIAMTCE and provides up to 58 simultaneous

announcements that are distributed through the DSN or the tone PCM link. These
modules work in Load sharing mode. The associated OBC is known as DIAMOBC.
g. Digital Trunk Module High (DTMH)
This module performs, among others, the analysis of the digital signalling protocols, up
to four inputs in parallel (i.e. N7 MTP part, X.25, etc.) and, sometimes, the typical
functions of the DTM Low.
The module is also called IPTM (Integrated Packet Trunk Module). The associated
TCE name depends on the protocol to be handled:
. IPTMN7 : For N7 signalling (with IPTMN7OBC).

. IPTMU : For Primary Rate Access (with IPTMUOBC).
. IPTMN : As Protocol Handler Interface –ETSI PSN access Case A or B–
(with IPTMNOBC).
. IPTMX25 : To act as a X.25 DTE in the exchange connection to a EDPC (with
IPTMX25OBC).
The analysis capacity of this module is 400–500 messages/s and 300–400 frames/s.
These modules work in Load sharing mode.
4.2.3 System Control Elements
The System Control Elements are CEs always equipped in every exchange. These are:

1.
a. Peripheral and Load (P&L)
These modules cover the main functions related to the system initialisation, the CEs
and OBCs downloading, backup data, etc.. They handle the rack alarms and the
master panel for alarms.
The associated processor is named PLADMCE.
Two PLADMCEs, working in Active/Stand by mode, are always equipped in every
exchange.
b. Clock and Tones (C&T)
It generates and distributes the master clock towards every exchange CE and Switch in
the DSN. It also generates and distributes the tones towards every TI.
The processor is named CTCE.
Two CTCEs, working in Active/Hot Stand by mode, are always implemented in every
exchange.
c. Monitor Module (MONI)
It provides a set of features in order to perform different management and test

functions. The associated CE is named MONI (or PTCE). Usually, one MONI working in
Simplex mode is equipped per exchange.
d. Improved Trunk Testing Module (ITTM)
It provides trunk testing facilities. The associated processor is known as ITTMTCE, and
its OBC as ITTMOBC. Usually, one ITTMTCE, working in Simplex mode, is equipped
per exchange.
4.2.4 Auxiliary Control Elements
The ACEs contain centralized software and data, and perform support functions for the
TCEs. Actually, all the ACEs are implemented with a 80386 or a compatible processor and 8
MB RAMs. The main functions performed by the ACEs are: Call Services, PBX and
Charging data storage, Exchange Defense, Operation & Maintenance remote software, N7
management, Data Collection and Trunk Resource Management, Intelligent Network and
OSI Stack handling.
Each group of functions are stored on several ACEs named as follows:
a. Defense ACE (DFCE)
These ACEs work in Active/Stand–By mode. There is one pair per exchange. The pair
performs the following function:
– Exchange defense (failure gathering, report analysis and defense procedure

triggering)

1.
b. System ACE for Call Services (SCALSV)
These ACEs work in load sharing and perform the following functions related to Call
Handling:
– Prefix Analysis and Task Element Definition (PATED)
– Call and Facility Control System (CFCS)
– Charging analysis (CHAN and CGC)
– Trunk request coordination (TRC).
– Auxiliary Resource Allocation (ARTA)
Figure 216 : SCALSV configuration

loadsharing
LSSG_1 SCALSV1 SCALSV2 SCALSV3 SCALSV4

LCE_id of TCE
LSSG_2 SCALSV5 SCALSV6 SCALSV7
LSSG_3 SCALSV8 SCALSV9 SCALSV10
c. System ACE for Subscriber Analysis (SACELSIF)
The SACELSIF handles the subscriber analysis function. It contains the static and
dynamic subscriber data. The SACELSIF works in active/standby pairs. There may be
a number of these pairs per exchange, depending on the number of subscribers. The
SACELSIF pair is determined by the DNET of the subscriber that has to be analysed.
Figure 217 : SACELSIF configuration
active standby
DNET
active standby
active standby

1.
d. System ACE for PABX Resource Management (SACEPBX)
The SACEBPX handles the PABX resource management. It contains the PABX data,
which is managed by the PARM FMM. The ACE works in active/standby configuration.
Since there could be a large number of PABXs, there may be a number of ACE pairs.
The correct pair is determined by the PABX identity.
Figure 218 : SACEPBX configuration
active standby
PABX_id
active standby
active standby
e. System ACE for Administration (SACEADM)
The SACEADM handles the administrative function of the exchange. Amongst others it
receives the measurements data from the LDCs. There is one SACEADM pair per
exchange, working in active/standby configuration.
f. System ACE for Charging (SACECHRG)
The SACECHRG handles:
– meter count collection (MCC): the bulk counters are stored and updated in the
memory of this ACE and saved on disk at fixed intervals
– automatic message accounting (AMA): the detailed billing information is kept in

memory and saved on disk at fixed intervals
– local tax layouting (LTL).
The SACECHRG works in active/standby pairs. Each pair serves a dedicated number
of lines.
g. System ACE for Local Data Collection (SACELDC)
The SACELDC handles the local data collection (LDC). This implies the collection of all
call handling events, such as a seizure, a call release and prefix analysis. With these
events local counters are updated.
h. System ACE for Trunk Resource Allocation (SACETRA)
The SACETRA handles the trunk resource allocation (TRA) function. This ACE works
in a very special and unique configuration: if traffic measurements indicate that N ACEs

1.
are needed, then one extra ACE is equipped. We therefore call this an N+1
configuration. The spare SACETRA is a hot–spare ACE: it already contains the correct
software; it only has to initialise it’s data when it has to take over from one of the other
SACETRAs.
i. System ACE for Intelligent Network (SACEIN)
These ACEs work in load sharing mode. They perform the SSP functions in the IN.
j. System ACE for OSI Stack (SACEOSI)
These ACEs work in load sharing mode. They provide the OSI Stack interface for the
CEs that need to transfer data to the EDPC via X.25.
k. System ACE for CCS N7 (and OMUP) (SACEN7 and SACEN7O)
The SACEN7 handles the CCS N7 network functions. If also the Operations and
Maintenance User Part (OMUP) is equipped, the ACE is called the SACEN7O. There is
one pair of these ACEs (if required). The pair works in active/standby mode.
l. Spare
On the other hand, some ACEs that have no specific function assigned, are equipped
in every exchange. These ACEs are named SPARE. Their main function is to take over
the functions of any other ACE in case of failure.
m. Special configurations
Depending on the size of the exchange and the type of traffic it handles, a number of
ACE functions can be combined into one ACE, or can be unbundled. Some examples:
– the SCALSV can be unbundled into a specific SCALSV for lines (SCALSVL) and a
specific SCALSV for trunks (SCALSVT);
– the IN function (SACEIN) and the OSI function (SACEOSI) can be bundled into the
SINOSI;
– the defense function (DFCE) and the CCS N7 function (SACEN7O) can be bundled
into the DFN7OCE;
– the PARM function (SACEPBX) and the charging function (SACECHRG) can be
combined into the SACEPBCH.
4.3 Software principles and organisation
In the previous chapters we have seen that the system software is composed of application
programs, called FMMs or SSMs, and of support software, such as the Operating System
and the Data Base Management System software. These programs are classified into

1.
resident programs, memory resident because they are frequently run; and overlay programs,
which are loaded into memory from disk when required.
On the other hand, we can find different kinds of data: the data related to the program code
(data segment) and the data belonging to the actual database.
In summary, the complete system software can be said to consist of programs and data.
4.3.1 Programs and data on mass storage media
When the SW is produced, the final result is a system magnetic tape or a system optical
disk. At system initialization, all the information (programs and data) must be transferred to
the system from this tape or optical disk. In order to organize the system SW on this mass
storage devices, it will be necessary to define a set of files according to the system structure.
There is a set of files that form the so called GENERIC LOAD SEGMENT (GLS) which
contain the resident programs (code and data segment) for a certain CE. Other files contain
pieces of database data that are related to a certain microprocessor and form the DATA
LOAD SEGMENT (DLS).
On the other hand, the PLS (PATCH LOAD SEGMENT) is a code file containing a set of
patches to be loaded into a CE, together with the GLS. This set of patches is produced to
improve or correct the original software included in the GLS, once this GLS has been
produced.
As said before, a GLS contains the set of programs that are associated to a CE. Therefore,
all the CEs that have the same function will have the same set of programs, i.e., the same
GLS. For example, let us think about the JLTCEs (J–rack Line TCEs). All the line TCEs will
have the same GLS and therefore, only one JLTCE GLS will be stored on disk. The same
reasoning applies to the PLS.
Regarding the DLS, the situation is different. A certain CE will only have in storage those
pieces of database data that it uses. In the previous example, one given JLTCE will have in
storage the data specific to the subscriber lines that it controls (directory numbers, telephone
set types, etc.).
There is one more set of files that contain the overlay programs. These files are named
GENERIC OVERLAY SEGMENT (GOS) . Each GOS contains the code and its patches,
together with the associated code data, for a specific overlay program.
4.3.2 Memory organization
Every CE memory is organized by splitting it up into several functional areas. This is done by
assigning different addresses and sizes for different memory contents, i.e., by mapping the
memory. The memory map is then provided to the Operating System allowing it to optimally
manage the CE memory resources.

1.
The resident programs (resident related FMMs, all related SSMs, required part of the
Operating System and of the Data Base Management System) are contained in the GLS,
together with their associated data segments. These programs are permanently loaded into
a fixed area of the CE memory assigned to them.
As said before, there is a set of patches (the CE PLS) associated with the resident
programs. These patches are also loaded into a fixed memory area.
The pieces of database data related to a CE make up the its own DLS. The DLS varies for
the different system CEs, since they all contain different data, however, the DLS size and
structure is identical for all the CEs of the same type. This data is permanently stored in a
fixed memory area reserved for this purpose.
Another memory area is reserved for loading the overlay programs when required. The size
of this area is defined as a function of the overlay programs that must be concurrently
executed in the CE in question.
Furthermore, there are other memory mapped areas that are reserved for different
purposes. For example, one area will contain the message buffers, another one the user
buffers and process stack segments, a third one the TI PRAM, etc.
Figure 219 : Simplified memory layout

PATCHES AREA
DATABASE AREA
OVERLAY RESERVED AREA
DATA SEGMENT AREA
CODE SEGMENT AREA
USER BUFFER AND STACK AREA
BUFFER MESSAGE AREA
ROM AREA
4.3.3 CE logical and physical identities
The complete set of functions to be performed by the system are distributed among all the
CEs. Using the TREX example seen in the previous chapter, we can see that the analogue
subscriber connections are performed by twelve JLTCEs, the call control service functions
by two SCALSVs, the defence functions by two DFN7OCEs, the MF analysis and generation
by four ISVCEs, etc.
Moreover, within every functional set of CEs, each CE has a specific function: each JLTCE
supports 128 particular subscribers, one of the two DFN7OCE is active while the other one

1.
is in stand–by, etc. According each function is identified by a number called Logical Identity.
A particular Logical Identity is related to a particular function and, therefore, associated with
the exchange CE that performs this function.
On the other hand, every system CE is connected to a particular point of the DSN, i.e., every
CE is at a permanent location defined by the coordinates W, X, Y, and Z. This set of
coordinates is called CE Network Address or Physical Identity.
The relationships between the logical and physical identities of the CEs are defined by the
configuration data. At system initialization, a basic configuration data set (provided for every
exchange in the system tape or optical disk) drives both P&Ls to download the CEs, and
thus, assign the logical and physical identities for every CE. These relationships between
both identities must be stored in all CEs, and updated when necessary since they will
change throughout service life of the exchange.
Let us see two examples. First, when a SCALSV fails it can be substituted by the SPARE
one. In this situation, the logical identity of the first ACE will be linked to the physical identity
of the SPARE, once the latter has been loaded with the SCALSV GLS, DLS, and PLS from
disk. Secondly, let’s take two JLTCEs connected in X–over. If one of these two JLTCEs fails,
its logical identity will be assigned to its mate which will then have two logical identities : its
own plus that of the faulty JLTCE.
4.4 J–Rack family
In the A1000 S12 system exchange implementation, up to seven different rack types are
used: the J–Family Rackset. Each of these rack types can contain a fixed number of
modules with their related PBAs. However there is no relation between the rack type and the
type of modules inserted in it. A variable module means that different type of modules can
be inserted in the same position within the rack.
Each rack layout is flexible, allowing different rack contents to be defined for different
exchanges. To cope with all this, four variable modules are defined: the V01M, V02M, V03M,
and V04M .
In the rack documents the PBA positions are indicated as follows:
VnnMCxx or VnnMTxx
nn = variant type (01, .., 04)

xx = numbering within the rack
C = CE position (MCUA,...)
T = Terminal position (ALCN, DTRI, ...)
The V01M module type defines all modules composed of only one PBA (i. e. the ACEs
–MCUB PBA–). The V02M module type includes all modules composed of two PBAs (i.e.
the IPTM – MCUB+DTRI PBAs–). The V03M includes those modules that have up to eight
cluster PBAs (i.e. the ASM –MCUA/E+ 8 ALCN PBAs–).

1.
On the other hand, the DIAM module is a special case, that can be only equipped into
defined locations in some of the racks. Thus, a fourth variable module type is defined, the
V04M one, which covers all the two–PBA modules as well as the DIAM one.
Inside a rack, when an slot is defined to equipped a V02 module, also any V01 module may
be equipped into that slot. The following table shows some of the major module groups.
Figure 220 : Variable modules
Module Control Cluster V01 V02 V03 V04
Auxiliary Control Element (ACE) MCUB – x x x

Analogue Subscriber Module (ASM) MCUA/E ALCN x
High Digital Trunk Module (DTM–H) MCUB DTRI x x
Low Digital Trunk Module (DTM–L) DTUA/E – x x x
ISDN RSU Interface Module (IRIM) MCUB DTRF/H x x
Improve Service Circuit Module (ISCM) MCUA/E DSPA x x
ISDN Subscriber Module (ISM) MCUB ISTA/B/C x
An exception to the previous grouping are the system modules: the PLADMCE, the CTCE,
the DFN7OCE, the MONI, and the ITTMTCE, which are always equipped in fixed positions
in the JF00 rack.
The following table shows the different rack types in the J–Family, and the corresponding
module type provisioning and switch PBAs included in it (Access Switch and Group Switch
stages 1, 2, and 3). The full rack capacity is considered.
Figure 221 : Rack Types
Rack DSN
V01 V02 V03 V04 ACE PTCE C&T P&L TTM DEF AS GS GS
Type 1/2 3
JF00 4 2 6 9 1 2 2 1 2 6 32
JA00 12 8 10
JB00 6 8 10 10 32
JH00 80 18 32
JH01 20 48 22
JJ00 54 18 22 32
JJ01 40 10 16 64
As an example, the JF00 rack type can be taken. The following figure shows its simplified
rack layout. Notice the fixed PBA locations for the DFN70CE?, PLADMCE, CTCE, MONI,
and ITTMTCE.

1.
PBAs in black represent the SWITCH PBAs.
MCUB slots have to be equipped with the system ACEs (no V01M modules), and MCUX
slots identifies the slot for a MCUA or MCUB PBA. MDS represents the Magnetic Disk
System.

1.
Figure 222 : JF00 simplified rack layout

JF00
16 SWITCH PBAs 16 SWITCH PBAs 2
V02 V02
MCUB MCUB
V01
V01 3
V02 V02
MCUB MCUB
control PBA control PBA
V03 4
V03
cluster cluster
DEF V02 DEF V02
PLCE
MONI
PLCE MCUX 6
MCUB MCUB
MCUB MCUB
CTCE CTCE 7
VO1 VO1
MDS MDS ITTMTCE 8

1.
4.5 Training Exchange (TREX)
At this point, it is useful to have a look at the equipment of a real exchange and its
implementation in different racks. This exchange will be called Training Exchange (TREX).
The exchange has to provide services in the following environment:
- 1536 analogue subscriber lines
- 512 ISDN Basic Accesses
- 2 ISDN Primary Rate Accesses
- 1 multidrop IRSU link
- 180 CAS–R2 Trunks (Route–1) to exchange A
- 60 CAS–R2 Trunks (Route–2) to exchange B

- 120 ISUP Trunks (Route–3) to exchange C
- X.25 PSN 2 Mb/s digital link (via Protocol Handler Interface)
Figure 223 : Training Exchange environment

LOCAL CONNECTIONS REMOTE CONNECTIONS
IPBAX
1
PRA EXCHANGE A
180
Trunks
ALCATEL1000 S12
ROUTE–1
1 EXCHANGE CAS R2
IRSU EXCH. B
60 Trunks
2
PCM ROUTE–2
CAS R2
EXCHANGE C
1
120 Trunks
BAs ROUTE–3
512
N7–ISUP
PSN–NODE
ANALOG
PHI
1536 1
According to the dimensioning rules, the types and the number of the different modules
required for the exchange are:

1.
- – 12 analogue line modules ( 12 modules * 128 lines/module = 1536 lines)
- 8 ISDN line modules ( 8 modules * 64 lines/module = 512 lines)
- 8 DCASTCE–R2 modules ( 8 modules * 30 trunks = 240 trunks).

To handle MF signalling, 4 ISVCE modules are equipped.
- 2 DISUP plus 2 IPTMN7 modules ( 4 modules * 30 trunks/module = 120 trunks).

The N7 signalling is handled by both IPTMN7.
- 1 IPTMX25 to perform the DTE functions
- 1 IPTMN to link with the PSN using Case A or B ETSI scenarios
- 2 IPTMU (one module per PRA link)
- 2 IRSUIM (two PCM links towards one multidrop)

- 2 P&L, 2 C&T (system modules)
- Requried System ACEs
- Other modules.
Figure 224 : TREX spider diagram

2 1 10 – SLDCTRA (2)
1 – SACEPBCH (2)
– SINOSI (2)
DIAM
MONI SACEs – DFN70CE(2)
SPARE – SCALSV (2)
4
12
ISVCE
2 JLTCE
8
IPTMN7
DSN
ISMTCE
DISUPTCE
1
ITTM
2
DCASTCE
2
PLADMCE
8
IPTMU
IPTMN
1 2
2 CTCE
IPTM X.25 IRSUIMTCE
1 2

1.
As we will see later on, all these modules are distributed into 10 TSUs, which are connected
to the planes using 3 Group Switches in the first stage. Therefore, three TUs and thus, one
section must be implemented.
Regarding the dimensioning rules, only six switches, in the second stage, and four planes
are needed to achieve the traffic goals.
Physically, all these modules grouped as TSUs, and the DSN are located in three racks: the
JF, the JB, and the JA.
Figure 225 : TREX rack contents

JF JB JA
PLANE 0 PLANE 2
PLANE 1 PLANE 3
3 TSUs
– Analogue lines
– CAS Trunks 4 TSUs
– ISUP Trunks 3 TSUs
– Analogue lines – ISDN Lines
– Services – CAS Trunks – Analogue LInes
– P&L – ISDN Lines – CAS Trunks
– C&T – Services
– ACEs – Trunk PHI
– Link X.25
– Link PRA
– IRSU int.
– iSUP Trunks
The connection between the multiports for this two–stage and four–plane DSN is shown
below:

1.
Figure 226 : DSN architecture

STAGE 1 STAGE 2
0 8 8
0
1 0 1 0 9
13 2
7 15
7 15
0 8
4 TSUs 0 8 1 1 9
1 1
13 2
7 15
7 15
0 8
1
2 9
2
0 8
1 2
13 7 15
7 15 0 8
2 TSUs
1 3 9
2
7 15
0 8
1 4 9 PLANE 3
2
PLANE 2
7 15
0 PLANE 1
8
4 TSUs 1 5 9
2
PLANE 0
7 15
The complete list of TREX CEs is given is the following table. It also includes the CE
Network Addresses, the rack type, and the subrack and slot numbers where they are
located. The list is sorted by the Network Addresses.

1.
Figure 227 : TREX CEs (a)
NA CE RACK TYPE SUBRACK SLOT
0000 JLTCE JF 04 01
0001 JLTCE JF 04 33
0002 DIAM JF 06 31
0003 DIAM JF 06 63
0006 MONI JF 06 23
0007 ITTM JF 08 55
000C PLADMCE JF 06 13
000D PLADMCE JF 06 4
000E SCALSV JF 06 25
0010 IPTMN7 JF 03 11
0011 IPTMU JF 03 43
0012 DISUPTCE JF 07 23
0013 DISUPTCE JF 07 55
0016 SACEPBCH JF 03 31
0017 SINOSI JF 03 63
001C CTCE JF 07 17
001D CTCE JF 07 49
001F SCALSV JF 07 57
0020 ISVCE JF 03 25
0021 ISVCE JF 03 57
0022 DCASTCE JF 03 29
0023 DCASTCE JF 03 61
0027 SPARE JF 06 25
002C DEFN7OCE JF 06 21
002D DEFN7OCE JF 06 53
002E SINOSI JF 03 01
002F SACEPBCH JF 03 33
0030 ISMTCE JB 08 13
0031 ISMTCE JB 08 33
0032 JLTCE JB 07 01
0033 JLTCE JB 07 45
0034 DCASTCE JB 03 29
003E SLDCTRA JB 03 01

1.
Figure 228 : TREX CEs (b)
NA CE RACK TYPE SUBRACK SLOT
003F SLDCTRA JB 03 33
0100 ISMTCE JA 06 19
0112 DCASTCE JA 04 31
0113 DCASTCE JA 04 63
0200 IRSUIM JB 06 31
0201 IRSUIM JB 06 63
0202 IPTMU JB 04 31
0203 IPTMN7 JB 04 63
0210 IPTMX25 JB 08 03
0211 IPTMN JB 07 35
0220 JLTCE JB 06 19
0221 JLTCE JB 06 51
0222 JLTCE JB 04 19
0223 JLTCE JB 04 51
0224 ISVCE JB 03 25
0225 ISVCE JB 03 57
0230 JLTCE JA 08 13
0231 JLTCE JA 08 33
0232 JLTCE JA 07 01
0233 JLTCE JA 07 45
Next, the structures of the 3 TUs are shown:

1.
Figure 229 : TU 0 structure

PLANES
TU 0
ÑÑ
Module CE
0 JLTCE
ÑÑ
1 JLTCE
2 DIAMTCE
0
ÌÌ
ÑÑ
3 DIAMTCE 0 0
6 MONI
ÌÌ
7 ITTMTCE
1 3
12
Module CE
ÏÏ
ÌÌ
1 2 5 0
ÏÏ
0 IPTMN7
1 IPTMU
ÏÏ
JF 2 DISUPTCE
3
6
DISUPTCE
SACEPBCH
2 Module CE
12 PLADMCE
7 SINOSI
ÑÑ
13 PLADMCE
3 14 SCALSV
ÑÑ
Module CE
0 ISVCE Module CE
JF
ÌÌ
ÑÑ
1 ISVCE 12 CTCE
2 DCASTCE
4 13 CTCE
ÌÌ
3 DCASTCE 15 SCALSV
7 SPARE
ÌÌ
Module CE
5 12 DFN7OCE
ÏÏ
13 DFN7OCE
Module CE 14 SINOSI
ÏÏ
0 ISMTCE 15 SACEPBCH
1 ISMTCE 6
JB 2 JLTCE
3 JLTCE Module CE
4 DCASTCE 14 SLDCTRA
5 DCASTCE
7 15 SLDCTRA JB
ACCESS SWICTHES

PLANES
Module CE
TU 1
0 ISMTCE
1 ISMTCE
2 ISMTCE
3 ISMTCE 0 0 0
JA
1 2 3
Module CE
1 0 1
0 ISMTCE 2 5
1 ISMTCE
2 DCASTCE
3 DCASTCE
5
ACCESS SWICTHES

1.

PLANES
Module CE
TU 2
ÑÑÑ
0 IRSUIMTCE
1 IRSUIMTCE
ÑÑÑ 0
2 IPTMU
0 0
ÌÌÌ
ÑÑÑ
3 IPTMN7
1 3
ÌÌÌ
1
ÏÏÏ
2
Module
0
1
CE
IPTMX25
IPTMN
ÌÌÌ
ÏÏÏ
2 5 0 1
ÏÏÏ
JB 2
3
DCASTCE
DCASTCE
2
3
Module CE
ÑÑÑ
ÑÑÑ
0 JLTCE
1 JLTCE
4
ÌÌÌ
ÑÑÑ
2 JLTCE
ÌÌÌ
3 JLTCE
4 ISVCE
ÌÌÌ
5 ISVCE
5
Module CE
ÏÏÏ
ÏÏÏ
0 JLTCE
JA 6
ÏÏÏ
1 JLTCE
2 JLTCE
3 JLTCE
7
ACCESS SWICTHES
Finally, a simplified rack layout of the exchange is given on the next three figures. Only main
PBAs are shown. The Access Switch PBAs are drawn in black.

1.
Figure 232 : JF rack simplified layout
JF00
SWITCH SWITCH 2
13 15 17 31 33 35 47 49 63
002E 0010 0020 0022 0016 002F 0011 0021 0023 0017
ISVCE ISVCE
SINOSI S.PBCH
DCAS DCAS 3
IPTMN7 IPTMU
S.PBCH SINOSI
1 25 33
11 29 31 43 57 61 63
0000 0001
mcua mcua
JLTCE JLTCE 4
alcn alcn
1 33
000C 002C 0006 000E 0002 000D 002D 0027 0003
mcub DFN70CE DIAM DFN70CE

mcub DIAM
MONI 6
SPARE
PLADMCE
SCALSV PLADMCE
31
13 21 23 25 45 53 55 63
001C 0012 001D 0013 001F
ccla mcub ccla mcub SCALSV

rccb
rccb 7
CTCE DISUP CTCE DISUP
17 23 49
55 57
0007
mcua
8
MDS MDS
ITTMTCE
55

1.
Figure 233 : JB rack simplified layout
JB00
SWITCH SWITCH
2
1 3 17 33 49
003E 0212 0224 0034 003F 0213 0225 0035
ISVCE ISVCE
SLDCTRA
SLDCTRA
DCAS DCAS 3
DCAS DCAS
1
11 25 29 33 43 57 63
0222 0202 0223 0203

mcua mcua
IPTMU IPTMN7
JLTCE JLTCE 4
alcn alcn
19 31 51 63
0220 0200 0221 0201
mcua mcua
IRSUIM IRSUIM
JLTCE JLTCE
6
alcn alcn
19 31 51 63
0032 0211 0033
mcua mcua
IPTMN
JLTCE JLTCE 7
alcn alcn
1 35 45
0210 0030 0031
mcub mcub
IPTMX25
ISMTCE ISMTCE
8
ista ista
3 13 33

1.
Figure 234 : JA rack simplified layout
JA00
0110 0111
mcub mcub
ISMTCE ISMTCE
3
ista ista
13 45
0102 0112 0103 0113

mcub mcub
DCAS DCAS
ISMTCE ISMTCE
4
ista ista
51 63
19 31
0100 0101
mcub mcub
ISMTCE ISMTCE
6
ista ista
19 51
0203 0233
mcua mcua
JLTCE JLTCE
7
alcn alcn
1
45
0230 0231
mcua mcua
JLTCE JLTCE
8
alcn alcn
13 33

1.
4.5.1 Rack alarm gathering
In every rack there are some events, not directly controlled by the Control Elements included
in it, which have to be reported to the maintenance software. These events are, for instance,
malfunctions in the DC/DC converters, the fuses and the clock and tones distribution.
In order to gather all these events from the rack circuitry, a new PBA is provided: the RLMC
(Rack aLarM version C). Two of these PBAs are equipped in every rack, and they are
associated to two Control Elements. These CE are responsible for managing the reports
generated in the RLMC.
This alarm board is composed of a group of alarm inputs which are connected to a memory
register that stores the occurred events. A DPTC circuit is responsible for the protocol
communication with the associated CE, in a similar way as used for the ALCN board of the
ASM.
Figure 235 : Simplified RLMC board

INPUT ALARMS
RLMC
REGISTER
DPTC
PCM Links
Taking the TREX as example, two RLMC PBAs are equipped in each of the three racks. In
the JF00 rack, both PBAs are associated with the PLADMCEs, and in the JB00 and the
JA00, the boards are associated with the line modules, as the following figure shows:

1.
Figure 236 : The RLMC boards in the TREX

JF00 JB00 JA00
2 2 2
3 3 3
4 4 4
air baffle air baffle air baffle
6 6 6
7 7 7
8 8 8
JLTCE
ISMTCE
RLMC PLADMCE RLMC RLMC JLTCE

1.
5. CALL HANDLING OVERVIEW
5.1 Possible accesses to an exchange
Figure 237 : Incoming/Outgoing accesses
ASM ASM
BA BA
ISM ISM
PRA PRA
IPTM DSN IPTM
PABX PABX
CAS
DTM DTM
CAS
CAS CAS
DTM DTM
Nr7 Nr7
DTM DTM
- An analogue subscriber telephone set is connected to an exchange via the a– and

b–wire. In chapter 2.3.1 we saw that analogue lines are connected to A1000 S12 via an
Analogue Subscriber Module (ASM).
- An ISDN subscriber is connected via a Basic Access (BA) which is a digital access using
two B–channels and one D–channel. The BAs are connected to an ISDN Subscriber
Module (ISM)
- An IPABX is connected via 1 or more PRAs which consist of 30 B–channels and 1

D–channel. An IPTM (Integrated Packet Trunk Module) can handle a PRA when loaded
with the correct software.
In general, accesses used for traffic towards PBXs can be of the following types :
– analogue line
– basic access
– PRA channel

1.
– Trunk channel
- Connections to other exchanges are via trunks (PCM) which can use different signalling
systems like No7, R2/CAS, R1, Nr5, ... The drawing below shows a DTM (Digital Trunk
Module) as access module. From chapter 2, we know that this can be an DTUA/E for
CAS, and an IPTM/DTUB or DTUA/E + IPTM/DTUB/HCCM for No7.
- Definitions:
– When both the originating access and the terminating access are subscribers, the
call is named a local call. The switching is done within the exchange.
– When the origination is a subscriber and the dialled digits result in a trunk channel
selection, the call is named an outgoing call.
– When the call enters the exchange via a trunk channel and terminates towards a
subscriber, it is named an incoming call.
– When the call enters via a trunk channel and leaves the exchange towards the next
exchange, it is named a transit call.
5.2 Overview of the call types
During a call setup it is possible that different accesses are combined. Figure 238 gives the
overview and can be used for all call types:
- [1] + [2] in the same exchange = Outgoing Call
Examples:
– Analogue to No7 or MF/R2 trunk.
– ISDN to No7 or MF/R2 trunk.
- [3] + [4] in the same exchange = Incoming Call
Examples:
– No7 or MF/R2 trunk to analogue
– No7 or MF/R2 trunk to ISDN.
- [1] + [4] in the same exchange = Local Call
Examples:
– Analogue to analogue subscriber
– Analogue to ISDN subscriber and vice versa.
- [3] + [2] in the same exchange = Transit Call
Examples:
– No7 to No7 trunk

1.
– MF/R2 to MF/R2 trunk

– No7 trunk to MF/R2 trunk or vice versa.
However in all these cases the scenarios are similar. Most of the differences are related to
signalling differences.
Figure 238 gives some call possibilities for analogue subscribers and N7 trunks.
Figure 238 : Overview Call Types
ACE
SCM IPTM
1 No7
2
ASM DSN IPTM
Originating Exchange
STP
Destination Exchange (No7)
ACE
ASM IPTM
3 No7
4
IPTM
DSN
The modules perform the following functions :
- ASM
This is the Analogue Subscriber Module
- SCM
If the subscriber is allowed to have a PBR telephone set, we need a SCM to detect the
DTMF. This is of course only necessary in the originating exchange.
- IPTM
The IPTM (Integrated Packet Trunk Module) is used for two purposes:
(1) Speech connection (via a trunk channel)

1.
(2) Inter exchange signalling (No7)
The drawing shows two IPTMs per exchange to indicate that the speech connection
and the signalling path are independent of each other. It is possible that the No7
messages are transmitted via the same IPTM as the speech connection, but they may
also be transmitted via another link, possibly via a Signalling Transfer Point (STP).
It is also possible to use a DTUA/E + HCCM for the No7 link, or HCCM + IPTM, or
DTUA + IPTM, or .... For more information see also PART I.
- ACE
This function is necessary for software support such as, call control, prefix analysis,
trunk search, subscriber identification.
– The call is an example for Belgium. This means :
– Closed numbering;
– Zone with Directory Number (DN) = 7 digits, represented by D1......D7;
– Number of prefix digits = 3.
5.3 Call handling blocks
Figure 239 shows the possible accesses for CALL ORIGINATION and CALL
TERMINATION which were discussed in the previous chapters. The figure will be used to
briefly explain the call flow. CFCS is drawn over the links between the different blocks,
because we know from the previous chapter that CFCS is used during the call setup.
- Prefix Analysis

1.
Figure 239 : Prefix analysis
CFCS
Analogue Analogue
Line Line
Subscriber
ISDN BA Identif. ISDN BA
Prefix
ISDN PRA PARM ISDN PRA
Analysis
Trunk(CAS) Trunk Trunk(CAS)

Search
Trunk(No7) Trunk(No7)
CALL CALL
ORIGINATION DEFINE CALLED DEVICE TERMINATION
This block will receive the digits coming from the Call Origination. During call setup the
necessary number of prefix digits is retrieved from database. Prefix analysis checks
these digits and can ask for more digits if necessary.
The result can be LOCAL or OUTGOING.
In case the result is OUTGOING CALL, the trunk search building block is accessed.
In case the result is LOCAL, the subscriber identification building block is accessed.
This results in three cases, which are explained in the following paragraphs.

1.
5.3.1 Terminating or Local Call
Figure 240 : Terminating or Local Call
CFCS
Analogue Analogue
Line Line
Subscriber
ISDN BA Identif. ISDN BA
Prefix
Analysis

Search
CALL CALL
ORIGINATION DEFINE CALLED DEVICE TERMINATION
- Subscriber Identification
In this case prefix analysis found that the call is LOCAL. However, from the point of
view of the exchange the call is LOCAL if the call originates in this exchange, and the
call is TERMINATING if the call origination is a trunk.
In both cases it is up to the subscriber identification to identify the call termination,

which is an analogue line or a Basic Access.

1.
5.3.2 Transit or Outgoing Call
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Figure 241 : Transit or Outgoing Call
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ CFCS
Analogue Analogue
Line Line
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ Subscriber
ISDN BA
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ Identif. ISDN BA
Prefix
Analysis
Search
DEFINE CALLED DEVICE
CALL ORIGINATION ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ CALL TERMINATION
- Trunk Search
In this case prefix analysis found that the call is OUTGOING. However from the point of
view of the exchange the call is OUTGOING if the call originates in this exchange, and
the call is a TRANSIT if the call origination is a trunk.
In both cases it is up to the Trunk Search mechanism to define a module to switch to

the next exchange (=Trunk module No7 or CAS)

1.
5.3.3 Hunting to lines/trunks
Figure 242 : Hunting to lines/trunks
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ CFCS
Analogue Analogue
Line Line
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ Subscriber
ISDN BA
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ Identif. ISDN BA
Prefix PARM
ISDN PRA ISDN PRA
Analysis
Search
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍDEFINE CALLED DEVICE
CALL ORIGINATION ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ CALL TERMINATION
- Private Access Resource Manager (PARM)
In this case prefix analysis found that the call is LOCAL. As in chapter 5.3.1 the call can
be local or terminating. Therefore the subscriber identification is accessed. The result
of subscriber identification is a PABX identity which is passed towards PARM.
PARM executes line hunting in case the destination is BA or an analogue line. In the
case of an (I)PABX connected to a PRA or CAS trunks, trunk hunting is executed to
find an outgoing trunk or PRA. This function is similar to the trunk search the previous
chapter.
5.4 Overview of the call phases
5.4.1 Originating exchange
Figure 243 is the flowchart for the originating (local or outgoing) exchange.
The call origination is an analogue subscriber using a PBR telephone set.
After prefix analysis the call is LOCAL or OUTGOING. The ”end of dialling” and the ”release
of the receiver” are still common, but the subsequent actions are different for the local and

1.
the outgoing call. However many actions are similar and are therefore printed on the same
horizontal level.
The flowchart is read from top to bottom. Every time the flow is interrupted, this means that
the exchange is waiting for an external action, which is a subscriber action or a No7
message.
With this flowchart it is possible to handle two call types: the left branch is the LOCAL CALL
and the right branch is the OUTGOING CALL.

1.
Figure 243 : Originating Exchange
SUBSCRIBER
SEIZURE
PREPARE & SEND

DIAL TONE
DETECTION OF
PREFIX DIGITS
PREFIX ANALYSIS
LOCAL OUTGOING
END OF DIALLING
RELEASE RECEIVER
SUBSC. IDENTIFICATION OUTGOING TK SELECTION

IAM
TERMINATING SEIZURE OUTGOING TK SEIZURE
ACM
PASS TO STABLE PHASE PASS TO STABLE PHASE
ANC
ANSWER ANSWER
CONVERSATION
CLF
FORWARD RELEASE FORWARD RELEASE
RLG
CLEAR

1.
5.4.2 Incoming exchange
In the incoming exchange the origination is a trunk (see figure 244). In this example a No7
trunk is used, so the incoming seizure is a Nr7 IAM (Initial Address Message) coming from
another exchange.
After the prefix analysis there are again two possibilities:
- The call is local and terminates in this exchange (an analogue subscriber in our example)
This is an INCOMING CALL.
- The call is outgoing and will leave the exchange via a trunk (No7 trunk in this example).
This is called a TRANSIT CALL.
Figure 244 : Incoming Exchange

TRUNK
IAM
SEIZURE
PREFIX ANALYSIS
LOCAL OUTGOING

ACM IAM
ACM ACM
ANC ANC ANC
ANSWER ANSWER
CONVERSATION
CLF CLF CLF

RLG RLG
RLG
CLEAR
These two flowcharts will be used in the description of the different call types.

1.
5.5 Generic call scenario
The previous chapter discussed the various possible accesses. Depending upon the
combination, a call can be local, outgoing, incoming or transit.
This chapter outlines a common scenario which is independent of the access and can be
used for all types of call.
The discussion of the scenarios includes the prefix analysis, subscriber identification and
trunk search items. In the paragraphs following the scenarios, these items are explained in
greater detail because of their importance. As shown in figure 245, these software blocks
are called Call Services.
5.5.1 Call Setup
This scenario shows the interface between call services, CFCS, signalling and device
handling.
- 1 : SETUP or Origination message
After reception of the off–hook event for an analogue subscriber or the SETUP
message for an ISDN subscriber or the IAM for No7 trunks or the Seizure on a CAS
trunk, the call is activated in Signalling.
Signalling stores a reference for this call, which is used during the call handling to
identify the call. In other words, a transaction is created for each call request from
a user (the information is stored in a Transaction Control Block which is a unique
number). A transaction is also created whenever a situation occurs where extra
resources are needed that cannot be catered for within the existing transaction.
A transaction can contain references to three paths :
– a main path (=speech path in stable phase)

– a temporary path (=intermediate for 3 party service, ...)
– a system path (=towards SCM,...)
If these three paths are not sufficient, another transaction is created.
- 2 : SELECT CHANNEL
The device handler (DH) selects a free cluster path for the duration of this call. This is a
channel on the cluster side of the terminal interface.
The seized device is also put ’available busy’ by the DH.
The message also contains ’join information’. Later in the setup phase a path is
established between the SCM and the analogue subscriber for DTMF. So, for an

1.
analogue subscriber this join information means a connection between the cluster path
and the SCM–path. This is not true for an ISDN subscriber. For the latter the join
information means a connection between the cluster path and the path leading to the
call termination, when it is defined later.
- 3 : CHANNEL INFORMATION
This message also indicates a positive acknowledgement that the cluster channel is
available.
At this point CFCS can be activated. However, in parallel with the CFCS activation, it is
possible to request an auxiliary device (e.g: SCM receiver, if needed for DTMF or MF). This
means that [4] and [4’] are transmitted in parallel.
- 4’ : SELECT AUXILIARY DEVICE
The device can be a DTMF receiver (for an analogue subscriber) or an MF

sender/receiver (for CAS trunks). The selection of a SCM is executed by a separate
FMM (ARTA : Auxiliary Resource TCE Allocator). The selection mechanism is

explained in chapter 6. The selected SCM establishes a path towards the origination
module where it is joined to the cluster path. Via this path the SCM receives the DTMF
tones coming from the subscriber or the MF signalling between the two exchanges.
In the case of a DTMF receiver, dial tone is already transmitted towards the subscriber
and the SCM is ready to detect DTMF tones.
- 4 : ACTIVATE CFCS
CFCS is activated for this call using the call reference (identity) mentioned earlier.
- 5 : ACKNOWLEDGEMENT
Acknowledgement towards Signalling of the successful activation of CFCS.

1.
Figure 245 : Call Setup
CALL SERVICES
Subscriber Prefix Trunk
Identification Analysis Search
/PARM
14,6 7,15 10 11 14’ 15’
CFCS
22 24
13,9,4 5,8,12,16,23
4’
1 18
Signalling Signalling
19 21
17,2 3
Device 20 Device
Handler Handler
- 6 : GET CLASSES
The data profile of the calling subscriber is retrieved from Subscriber Identification.
Also the dial tone type and the required amount of prefix digits can be indicated here
depending on the facilities of the subscriber.
- 7 : CLASSES RESULT
The results are sent back towards signalling. Based upon the facilities the number of
digits required for prefix analysis can change. This is also retrieved here.

1.
- 8 : DIGIT REQUEST
Signalling receives the number of digits (=prefix digits) needed and passes them to the
SCM.
- 9 : DIGITS
Signalling sends the digits towards CFCS. For analogue subscribers, e.g., the digits
were received from the SCM.
Signalling sends all the digits it has received up to then, but the minimum is the number
of digits required. For ISDN subscriber and for No7 all the digits were received
”en–block” (if applicable).
- 10 : PREFIX ANALYSIS
The digits are transmitted to ”Prefix Analysis” to be analysed. More details on the prefix
analysis will be given later in this chapter.
- 11 : PREFIX ANALYSIS RESULT
As explained before, the result can be LOCAL or OUTGOING.
Prefix Analysis also detects the remaining number of digits required.
- 12 : DIGIT REQUEST
Request to signalling for the remaining number of digits.
Again for an analogue subscriber, the request is further transmitted towards the SCM.
The latter will send the digits to signalling after reception. The SCM is then released
because it is no longer needed.
- 13 : DIGITS
Signalling sends the remaining digits towards CFCS. Remember that there were two
possibilities : LOCAL or OUTGOING.
LOCAL : Subscriber Identification is accessed (see [14] and [15])
OUTGOING : Trunk Search is accessed (see [14’] and [15’]).
- 14 : SUBSCRIBER IDENTIFICATION
Here, the prefix analysis result and the remaining digits are used to fetch the profile of
the called party and define the call termination module.
- 15 : RESULT
The result is passed to CFCS

1.
- 14’ : TRUNK SEARCH
The prefix analysis result and some other information is sent to trunk search.
- 15’ : RESULT
Trunk search has retrieved the identity of the terminating trunk module (for more details
on the trunk search mechanism, see later in this chapter).
- 16 : INFORM SIGNALLING
Signalling is informed about the termination identity.
After analysis is complete, determination of the destination of the call, and selection of
the terminating resource (see above), a seizure is sent.
- 17 : JOIN INFO
This message is sent only for analogue subscribers, because the previously mentioned
join information for analogue subscribers indicated a path coming from the SCM. Now
an indication is given that the main path, coming from the termination device is being
established.
- 18 : TERMINATING SEIZURE
This message is sent from signalling A to signalling B. In the termination module a

reference is created for this call.
- 19 : SELECT CHANNEL
On the termination side, signalling requests a channel to the device handler. This
means a cluster path and a network path, and the join information.
The ringing current and tone are started (if requested).
- 20 : SETUP SPATA PATH
The result of this message between the device handlers is the creation of a UCP (User
Controlled Path). The device handler on the A side will join this path towards the cluster
path.
- 21 : CHANNEL INFORMATION
This message is also a positive acknowledgement indicating that the connections have
been allocated.
- 22 : ACKNOWLEDGE
This message is the acknowledgement towards CFCS, because it is the latter which
has started the terminating seizure with message [16]. It is also an indication that the
alerting phase has started.

1.
Depending on the signalling system, this message can be split into two messages.
E.g: for ISDN signalling, message 22 indicates an acknowledge and an indication to
wait for alerting. The signalling scenario is as follows. The called terminal is activated
with a Q931 SETUP message. One or more terminals will send a CALL PROCEED and
an ALERTING message backwards. When this alerting message from the terminating
side is received, a second message is transmitted towards CFCS.
At this moment CFCS activates charging. Charging is not further explained here
because it is handled in PART IV.
- 23 + 24 : PASS TO STABLE PHASE
CFCS sends the stable call data to signalling A and signalling B and terminates. The
answer and release is handled by the signalling (protocol) planes.
Customer dependent a ”wait for answer” timer is running in signalling B.

5.5.2 Answer
When the called subscriber answers, an event is received. Depending on the termination
device, the event can enter via the ASM hardware reporting mechanism,or via a Q931
message, ...
See figure 246:
- 1 : ANSWER
The answer event enters the signalling (protocol) plane. Customer dependent, the ”wait
for answer” timer is cancelled.
- 2 : JOIN
Signalling dependent, the ringing tone and/or ringing current are removed. The cluster
path is joined to the network path.
- 3 : PASS EVENT
The answer message is passed to signalling A because signalling A will start the
taxation.

1.
Figure 246 : Answer
3 1
Signalling Signalling
Device Device
Handler Handler

5.5.3 Release (Local Call only)
The following scenario describes an autonomous release of the calling subscriber. Like the
previous scenarios, this scenario is access type independent.
See figure 247 :
- 1 : RELEASE
The on–hook condition enters the signalling (protocol) plane. Signalling will inform
charging to stop the taxation for this call.
- 2 : INFORM DEVICE HANDLER
The DH will release the network path and the cluster path and put the line or trunk
available free (for a new call).
- 3 : INFORM B–SIDE
Signalling B is informed about the forward release.
- 4 : ACKNOWLEDGEMENT
This is the acknowledgement for the release trigger. On receiving this message the
originating signalling knows that the release event was received.
- 5 : INFORM DEVICE HANDLER–B
The release event is passed to the DH. The B–side is put in parking. The cluster path is
deallocated.
- 6 : ON–HOOK B–SIDE

1.
- 7 : RELEASE
The B–subscriber is put available free.
Figure 247 : Release

3
1 6
Signalling 4 Signalling
2 5,7
Device Device
Handler Handler

1.

1.
6. CALL HANDLING EXAMPLES
In this chapter many figures use numbers to indicate a sequence. In the text you can find a
reference to these numbers. This is done by repeating the number in the text between
square brackets, [number].
6.1 Local call with analogue subscribers
Figure 248 summarises the hardware which is used during the local call.
Figure 248 : Local Call
ACE
SCM
1 4
ASM DSN ASM
Figure 249 sketches the major steps in the treatment of a local call. Every block in the figure
corresponds with a chapter.
To work out a complete example, we will have to make a number of assumptions during the
call. Some of these assumptions are listed here:
- closed numbering
- seven digit number for the subscribers
- neither the A–party, nor the B–party have any facilities active
- the number of prefix digits is three.
In the figures that indicate a sequence of actions in the software:
- a full line represents a S12 message;
- a dotted line (with indented text) represents a procedure call.

1.
Figure 249 : Local call overview
A–party A1000 S12 B–party

hook off seize A–party
start scanning for digits
dial tone send dial tone to A–party
activate call control
perform A–party analysis
dial digits receive prefix digits
perform prefix analysis

receive remaining digits
release receiver
perform B–party analysis
request DID
seize B–party
start ringing phase
prepare charging
ringing tone pass to stable state ringing current
detect ring trip hook off
activate charging
conversation conversation
hook on stop charging
release A–party
release B–party hook on

1.
6.1.1 Seize A–party
a. Actions in the hardware and operating system
Figure 250 : Hook off

.
.
ALCN 7 MCUA
1 ALCN 0
2 3 PRAM
0 DSN
. L A 4
. O
. G
I
C .
15 B
. To OS
cross–over
DH
5
SIG
[1]
When the subscriber lifts the handset, the loop resistance is low and the current
through the subscriber’s line increases.
[2]
This increase in current is detected by the hardware of the subscriber line. This
detection is translated into the setting of a bit. The digital logic of the subscriber sends
this information towards the common logic of the PBA.
[3]
This common logic is the communication link towards the control element processor.
The processor can send commands to the logic (via CH16 = drive) and the logic can
send the results back in CH16 (=scan). If there is an event in the hardware (hook–off,
hook–on, HW fault, ...) then the logic sends a CH0 alarm towards the processor.
In our case (hook–off) the logic sends a CH0 alarm towards the terminal interface
PRAM.
[4]
The CH0 alarm is received and detected by the OS which periodically scans the Packet
RAM with a clocked procedure. Then a command is sent to the logic to ”ask” what has
happened in the hardware. The result is again received in the PRAM via CH16 and is
read by the OS.

1.
The received information explains what happened (subscriber hook–off) and gives the
subscriber’s identity.
It consists of two words: one word indicates hook–off and the second word is the
identity. The latter is called the PTN = Physical Terminal Number.
All this information is passed to the LCRC DH SSM as follows. The OS places the
information in a queue which belongs to the LCRC DH SSM. The latter reads this
queue periodically (clocked procedure) and detects the creation of a new entry.
[5]
The LCRC DH SSM then sends the first A1000 S12 message towards the signalling
subsystem (ASSS_TSIG). Since the message indicates the start of a new call, it is
called the origination message.
At this point the software is activated. The scenario is summarised in figure 251. This
figure starts with step 5 out of the previous figure, where the LCRC DH SSM sends the
first message of the call to ASSS_TSIG.
b. Actions in the software
Figure 251 : Seize A–party
ASSS_TSIG
A
2
3
LCHG
5
SMD FMM
4
LCRC DH SSM
1
ASM (orig)
Note: Because of the cross–over connections, this hook off event is also received in the cross–over
module. However, in a normal situation the software detects that the subscriber is handled by its own
module. This is detected after the PTN to TN translation. In this case the message to
ASSS_TSIG is only sent in the own module.
In a cross–over situation the active module takes care of all the subscribers.

1.
When a subscriber hooks off, the software has to mark the subscriber as busy.
Furthermore, since there are only a limited number of cluster paths, one has to be
allocated to the new
call.
TN = 1...128 EVEN MODULE SUBSCRIBERS

TN = 129...256 ODD MODULE SUBSCRIBERS.
[1]
origination
When ASSS_TSIG receives the origination message, it allocates a transaction
control block (TACB) for this call, further on labeled as ASSS_TSIG_A. During call
set–up, this reference is passed from one software block to the other in the messages.
So this reference identifies this call.
[2]
ASSS_TSIG_A calls an interface procedure within the LCRC DH SSM to remove
the terminal from origination scanning list.
Next ASSS_TSIG_A checks whether the subscriber has priority during overload. This
priority is only important if the CE has an overload condition. The priority level is part of
the Class Of Line (COL) data. This data is stored in a relation. There is one tuple per
subscriber in the relation. The key to the relation is the TN.
[3]
select channel
The actions of the SMD FMM are combined in figure 252.

1.
Figure 252 : Actions of the SMD FMM
INITIALISATION
ACTIONS
STATE FREE
MSG_WAIT
STATE:FREE STATE:BUSY
SELECT
CHAN
. . .
. . .
POWER ON . . .
GET CLUSTER
PATH
STATE BUSY
GET COL
CHAN
INFO
[4]
SMD FMM calls an interface procedure to request a cluster path. Some of the
sub–actions include:
– power on the the ESLIC and DSP chips on the ALCN board:
To limit power dissipation in the module, the speech path only receives power when
it is needed. This is when the subscriber’s line becomes busy. The LCRC DH SSM
therefore sends a packet over channel 16 to the ALCN logic.
– allocate a cluster path (see figure 253):

The allocation of a cluster path is done via an OS primitive. This primitive allocates a
free Rx / Tx channel pair. Then OS sends a packet to the ALCN logic to indicate that

1.
subscriber X is connected to Rx/Tx channel pair Y. In this way the hardware knows
in which channel the samples are going to be transmitted and received.
Figure 253 : Cluster path allocation

MCUA
ALCN 0 1 2
0 R R
A
. L T T
. O DSN
. G 3 4
I R R
C T T
15 B
Cluster Channel pair OS

e.g: CH 7
DH
SIG
SMD FMM changes the state of the subscriber from available_free to available_busy.
Also SMD FMM checks some COL data. The data needed by the device handler are
transmission parameters:
– the receive and the transmit gain;
– the settings of the hybrid on the ALCN board.
[5]
channel information
The SMD FMM sends the result to ASSS_TSIG_A. This message includes the channel
identity and the COL information.
ASSS_TSIG_A checks some additional COL data:
– the type of set: this can be dial pulse set (also called rotary set), push button set (or
DTMF set), or combined set. Let us assume that the subscriber has a combined set.
In other words: the software doesn’t know whether a dial pulse set or a push button
set will be used. In this case both types of scanning have to be triggered. As soon
as the first digit is detected, the redundant scanning type can be switched off.

1.
– the priority during catastrophic condition: an exchange can be put in a catastrophic

condition, for example if there is an earthquake, to avoid originating traffic from an
exchange;
– the presence of a hardware key is checked. A hardware key can be used to switch
on or off a particular Outgoing Call Barring (OCB) level.
Also some Originating Line Class Of Service (OLCOS) data is checked. This data is
stored in a relation. The most important information is the dial tone type.
A subscriber who hasn’t activated any facility, may receive normal dial tone, whereas a
subscriber who has activated a Call Forwarding Unconditional (CFU) facility, may
receive a special dial tone.
Note: The OLCOS relation mentioned only contains part of the COS data. This data is the absolute
minimum COS data that is necessary to start the call. It contains the dial tone type to send the dial
tone as quickly as possible. The more advanced COS data is stored at LSIF level. Refer to chapter
3.4.9.

1.
6.1.2 Start scanning for digits / Send dial tone to A–party
Figure 254 : Start scanning for digits and send dial tone to A–party
SCALSV
PATED TRC CHAN CGC
CFCS
4
ASSS_ASIG
5 ARTA
A
6
2 3
A
7
SC DH FMM
ASSS_TSIG
1
8
LCHG
10 RSIG
SMD FMM
9
LCRC DH SSM SC DH SSM
ASM (orig) SCM
Signalling starts dial pulse scanning, finds a DTMF receiver and starts DTMF
scanning.
Note: Time–out handling:

During the register phase, several time–outs are used:
– wait–for–first–digit time–out;
– overall–dialling time–out;
– inter–digit time–out.
These time–outs are started in the signalling software block. Depending on the dialling type, the
time–outs are running in different CEs. The table below gives an overview.

1.
PB set only dial pulse set only combined set

overall–dialling time–out ASSS_ASIG_A ASSS ASIG_A ASSS ASIG_A
wait–for–first–digit time–out RSIG ASSS TSIG_A ASSS TSIG_A
inter–digit time–out RSIG ASSS TSIG_A ASSS TSIG_A or
RSIG
dial tone SCM ASM SCM
[1]
ASSS_TSIG_A calls an interface procedure within the LCRC DH FMM to start dial
pulse scanning.
Because we assumed that the dial type is combined, we are not sure at this moment if
our subscriber is using a PBR set or a dial pulse set.
In case of dial pulse scanning the digit value is determined by the number of pulses
coming in. The pulses are created by changing the loop status from high to low and
vice versa.
This generates events in the subscriber line hardware in the same way as was the case
for lifting the handset. These events are reported to the LCRC DH SSM. The SSM
checks the ”making” and the ”breaking” times to verify whether they are within the limit.
If the ”inter–digit” time is exceeded, then the number of pulses gives the digit value. In
figure 255 the detected digit is two.
Figure 255 : Dial pulse scanning

inter–digit
time–out
66 ms
OPEN LOOP
CLOSED LOOP
33 ms
digit detected
[2]
loadsharing intra signalling
ASSS_TSIG_A now has to link with ASSS_ASIG. ASSS_ASIG is stored in the SCALSVs. To
obtain an equal distribution of originating traffic over the SCALSVs, the message to trigger
ASSS_ASIG is sent in loadsharing.
The message contains the information that ASSS_TSIG_A has collected so far:
- the COL data
– dial set type;
– priority level during overload;

1.
– priority level during catastrophic condition;
– presence of a hardware key.
- the OLCOS data: primarily the dial tone type.
To check whether the linking was successful, ASSS_TSIG_A starts a time–out for the
acknowledgement from ASSS_ASIG.
The first action of ASSS_ASIG is to allocate a TACB of it’s own, further on labeled as
ASSS_ASIG_A. The information received from ASSS_TSIG_A is then copied into the TACB.
[3]
intra signalling
ASSS_ASIG_A sends an acknowledgement to ASSS_TSIG_A. The latter then stops the
time out.
[4]
activate CFCS
The actions that are performed by CFCS and the subsequent steps are explained in the next
chapter.
[5]
select device
To detect DTMF digits, a DTMF receiver has to be allocated in a SCM. This allocation is
performed in two steps:
1. a SCM has to be found that first of all has receivers of the correct type and that is
available maintenance–wise;
2. the chosen SCM has to be contacted, to check whether it still has a free receiver.
To find an available SCM with the correct device type, a message is sent to the Auxiliary
Resources TCE Allocator (ARTA) FMM. ARTA uses a procedural relation to find a SCM.
Please refer to chapter 3.4.7 for more information on how the procedural relation works.
In the meantime a time–out is running in ASSS_ASIG_A. Three possibilities exist:
– The SCM selects a free receiver and replies to ASSS_ASIG_A via SMD FMM;
– The SCM replies with a message to indicate that no receiver is available. In this
case ASSS_ASIG_A starts a new time–out and sends a new request to ARTA, until
maximum number of retries is reached;
– The time–out in signalling expires. ASSS_ASIG_A sends a retry to ARTA and the
latter puts the SCM unavailable for 30 s.
Note: Queuing is also possible but is not further discussed here.

1.
[6]
select device
Now, ARTA sends a message to the selected SCM to continue the search for a free DTMF
receiver within the SCM. Because of the distribution of the traffic (via this cyclic search
mechanism) the possibility of finding an SCM with a free DTMF receiver is very high.
The SC DH FMM selects a free receiver and changes it’s state to available busy.
[7]
seized MF register
The SC DH FMM sets up UCP to the ASM. It is a duplex path that is held until one of the
DHs (SMD FMM or SC DH FMM) asks to disconnect it. This path will be used in the
direction from SCM to subscriber to send dial tone, and in the direction from subscriber to
SCM to send the DTMF digits, if at least the subscriber has a push button set. To set up the
UCP the following steps are performed:
1. the DH asks a SPATA channel via an OS primitive. The NA of the ASM (destination
CE) is given as an input parameter. The identity of the allocated path is returned as an
output parameter, so that it can be used by the process to send the message.
2. when control is returned to the SC DH FMM, the BASIC message can be sent VIA
that UCP. (get a message buffer, fill in the message buffer and send the message )
3. OS finds out that the message is sent via a UCP, so it starts a 3 packet sequence
(refer to figure 256):

1.
Figure 256 : Setup of a UCP
1 a 2 2 1
R R R a R
ÉÉ ÉÉ
T T a T T
3 4 4 3
R R R R
T T DSN T T
ASM SCM
1 2 2 b 1
ÉÉ ÉÉ
R b R R R
T T b T T
3
R
ÉÉ 4
R
DSN
4
R
ÉÉ 3
R
T T T T
ASM SCM
1 c 2 2 1
R R
ÉÉ ÉÉ
R c R
T T T T
c
3
R
T
ÉÉ 4
R
T DSN
4
R
T
ÉÉ 3
R
T
ASM SCM
[a]
Contains information to set up and hold a simplex path through the DSN from the
SCM towards the ASM (selects and EOP hold). The OS in the ASM is informed to
establish a return path.
[b]
Contains information to set up and hold a simplex path through the DSN from the
ASM towards the SCM (selects and EOP hold). The OS in the SCM is informed to
send the actual message via the existing path towards the SMD FMM.
[c]
This packet does not contain select words because the path already exists. It is
the only packet which contains data (message data) to be delivered to the SMD
FMM.

1.
When the BASIC VIA message is received in the SMD FMM, it will connect the UCP
path to the cluster path pair. This is done by calling an OS primitive which executes the
join. The join is a duplex cut–through connection. For the result see figure 257.
Figure 257 : Join the A–party

Cluster channels
1 2
R R
T T
3 4
R R
DSN
T T
ASM
[8]
start receiving
The dial tone type was retrieved from OLCOS and the dial tone should be connected as
soon as possible. Also the receiver is connected to the UCP:
[9]
start scanning
RSIG triggers a procedure in SC DH SSM to start scanning for DTMF digits.
To connect the receiver, the Rx channel of the UCP is PUT TO RAM, so the samples are
received in the PRAM. Then a FETCH is created to connect the PRAM location towards the
channel of the receiver.
The dial tone is available in one of the channels of the tone port. At initialisation the tone
channels are PUT TO RAM to adjacent PRAM locations. Therefore, to send the dial tone to
the subscriber, it is sufficient to FETCH from the correct PRAM location towards the UCP Tx
channel. For the result see figure 258.

1.
Figure 258 : Connect receiver and send dial tone

Receiver
2 1
R R
T T
DSN 4 3
R R
T T
5 DT
SCM
[ 10 ]
seized register
The ASSS_TSIG_A is informed about the successful DTMF receiver selection. Now
ASSS_TSIG_A can cancel the time–out which has been running since the selection started
via ARTA.
Figure 259 gives an overview of the connections made so far in the hardware.
Figure 259 : Subscriber connections

DT
1 2 2 1
R R R R
ÉÉ
T T T T
3 4 4 3 Receivers
É
R R R R
T T DSN T T
R
ASM SCM
At this moment the subscriber receives dial tone and the exchange is waiting for the digits
coming from the subscriber. The overall dialling time–out and wait–for–first–digit time–out
are running. To continue the call, let us assume that the subscriber has a push button set.

1.
6.1.3 Activate call control / Perform A–party analysis
Figure 260 : Activate call control and perform A–party analysis

SCALSV
PATED TRC CHAN CGC
SACELSIF
2
CFCS LSIF
3
1
A ARTA
ASSS_ASIG
An application process is created to control the call and the A–party’s profile is
retrieved.
[1]
call control to signalling
This message is merely an acknowledgement to ASSS_ASIG_A.
[2]
data request
CFCS requests the A–party’s profile. Remember that the DNET of the A–party is used to
find the correct SACELSIF.
The profile contains:
– the Originating Line Class Of Service (OLCOS) data. One of the most important
parameters at this moment is the amount of prefix digits. This represents the
minimum amount of digits that have to be collected before CFCS submits them to
PATED. Let us assume that the number of prefix digits is set to three.
Note: In chapter 6.1.1 ASSS_TSIG already collected the basic OLCOS data from a relation in the
TCE. Here the more advanced OLCOS data is retrieved from a number of relations.
– the facility data.
[3]
data result
LSIF returns the results from analysis. Let us assume that the subscriber does not have any
particular facility active.

1.
6.1.4 Receive prefix digits
Figure 261 : Receive prefix digits
SCALSV
PATED TRC CHAN CGC
CFCS
1
17
2 ARTA
A
ASSS_ASIG
8
A
ASSS_TSIG SC DH FMM
LCHG
16
6
7
RSIG
SMD FMM
4,10,13 9,11,12,14,15
5
LCRC DH SSM SC DH SSM
ASM (orig) SCM
When the first digit is received the dial tone is removed and the redundant scanning
type is stopped. The first three digits are sent to call
control.
[1]
CFCS passes the A–party profile to ASSS_ASIG_A. The message also contains a digit
request. The number of prefix digits was found in chapter 6.1.3. We assumed that three
digits are requested.

1.
[2]
digit request
ASSS_ASIG_A forwards the digit request to SC DH FMM.
[3]
intra signalling
ASSS_ASIG_A forwards the digit request to ASSS_TSIG_A.
ASSS_TSIG_A starts the wait_for_first_digit time–out.
[4]
signal
The digit detection principle was explained in the chapter about the SCM. The first digit
is detected by the hardware and delivered to the SC DH FMM. The digit is passed to
the RSIG.
RSIG analyses the received DTMF code. Digits with code 0..9 and ’*’ or ’#’ are
accepted. Other codes are considered as a bad digit. The digits are stored in a local
digit buffer. They are collected there until all three prefix digits have been received.
[5]
first PBR digit
Because the subscriber is using a PBR set, the ASM has to be informed to stop the
time–outs and to stop the dial pulse scanning. SC DH SSM therefore reports the event to
SMD FMM.
[6]
disconnect tone
RSIG reports the event to SC DH FMM to disconnect dial tone.
[7]
event
SMD FMM reports the event to ASSS_TSIG_A. ASSS_TSIG_A cancels the
wait–for–first–digit time out and the overall–dialling time–out.
The overall time–out in the SCM, however, is still running.
[8]
switch off dial pulse scanning
ASSS_TSIG_A stops the dial pulse scanning and puts the terminal in the busy scan
list.
[9]
start time–out
RSIG starts an interdigit time–out.
[ 10 ] [ 13 ]
signal
The next digits are detected. The actions are similar to those executed after the reception of
the first digit.

1.
– cancel the interdigit time–out [ 11 ] [ 14 ];
– start a new one [ 12 ] [ 15 ];
– check the MF code for a bad digit;
– increment the number of received digits and store the digit in the buffer;
– check if the required number of digits have been received (e.g: 3).
[ 16 ]
address in bunch
The first three digits are sent in bunch to ASSS_ASIG_A.
[ 17 ]
signalling to call control
The first three digits are sent in bunch to CFCS.
6.1.5 Perform prefix analysis
Figure 262 : Perform prefix analysis

SCALSV
PATED TRC CHAN CGC
2
1
CFCS
ASSS_ASIG ARTA
A
The first three digits that were dialled, are analysed.
[1]
call control to PATED
CFCS sends the first three digits to PATED.
For our example, the message to PATED contains the following information:
- digits D1, D2 and D3 received from the subscriber.
- Type of Call (TOC), retrieved from the COS data, where it is called Calling Party Category
(CPC). E.g: Normal call.

1.
- Numbering Plan Indicator (NPI). For originating analogue subscribers CFCS fills in E164.
- Nature of Address (NATADDR) . For our analogue subscriber it is set to ”unknown”.
- source code, which consists of:
– an indication of the source code type: here it is set to subscriber;
– a value that depends on the type. For subscribers the value is the subscriber group.
- the time of day (TOD) is retrieved from the tone port (CH1 and CH2).
Figure 263 : Input for PATED

Request more digits
Received digits
Digit preparation
D1,D2,D3 & CPX

Digit Analysis CAUSE
ÉÉ
ÉÉ
Tasks
ÉÉ
ÉÉ
Task –LOCAL
Type of call
ÉÉ
Element –DNET
CPC (OLCOS) Definition
Category –tasks
(Normal Call) ...
Analysis
Origin
NPI (E164)
NATADDR (unknown)
SOURCECODE Origin
Type Analysis
(Subscriber)
Subgrp (OLCOS)
Time Time
TOD Analysis
[2]
PATED to call control
The results of the analysis are sent back to CFCS.
The result from PATED is: Request for more digits. This is passed to CFCS which sends the
request to ASSS_TSIG_A. From there the SCM is requested for one more digit and upon
receipt the RSIG transmits it to ASSS_TSIG_A and further to CFCS. This intermediate
scenario is not shown in the figures because the principle remains the same.
CFCS accesses PATED for a second time. Now four digits are presented to PATED.
PATED now finds that the call is LOCAL. In that case also a DNET is retrieved from
database and all this is sent to CFCS.

1.
PATED also delivers some tasks:
– destination allowance check: according to the originating and destination

restrictions, it is checked whether the destination may be accessed or not;
– start selection point: indicates the number of digits which should be received before
trunk selection starts (not for our local call);
– charging information (=input for charging);
– priority check: if the call has priority or not;
– numbering type check: indicates open or closed numbering. For closed numbering
the number of digits of the DN is given. For open numbering a minimum and
maximum is given. Let us assume closed numbering with seven digits.
6.1.6 Receive remaining digits / Release receiver
Figure 264 : Receive remaining digits and release receiver

SCALSV
PATED TRC CHAN CGC
CFCS
1
9
2 ARTA
A
ASSS_ASIG
SC DH FMM
8
7
RSIG
5,6
4 repeated
SC DH SSM
SCM

1.
The remaining digits are requested by call control. Signalling supplies them.
[1]
digit request
Since we assumed closed numbering with seven digits, and we have already received four
digits, CFCS requests three more digits. In addition CFCS indicates that this will be the last
request. This makes an autonomous release of the receiver possible (see later).
In case of open numbering, the SCM will pass every received digit to the ASM. This will
continue until the called DN is complete. In other words, when the called device is defined.
Only then will CFCS trigger the release of the SCM.
[2]
digit request
ASSS_ASIG_A requests three more digits.
[3]
digit request
SC DH FMM indicates the next amount of digits to RSIG.
[4]
signal
The next digit is detected.
[5]
stop time–out
RSIG stops the running inter–digit time–out.
[6]
start time–out
RSIG starts a new inter–digit time–out.
Actions 4,5 and 6 are repeated for every next digit, except for the last digit: then RSIG
stops the running inter–digit time–out and the overall–dialling time–out and stops the
scanning as well. This is an example of autonomous release.
[7]
address in bunch
The remaining digits are sent in bunch to ASSS_ASIG.
[8]
disconnect
RSIG sends a request to SC DH FMM to release the UCP. This happens in three steps:
1. Join a null pattern to the receiver:
Remember that during the operation the receiver was connected from the PRAM
towards a cluster transmit channel (FETCH). Now a null pattern is sent to the receiver.

1.
This is done by changing the FETCH from a new PRAM location. This new location
contains the null pattern for the receiver. In this way the receiver is released.
2. Release the UCP:
Figure 265 : Release UCP
1 c b 2 2 1
R R e
R R
T
3
T
4
d a T
4 ÉÉ T
3 Receivers
R
T
R
T DSN R
T É R
T
R
ASM SCM
This is done by calling an OS primitive.

[a]
On command of the OS, the IDLE pattern is sent via the Transmit channel of the
terminal interface to the DSN. After reception of the IDLE pattern during 2
consecutive frames, the connection is broken by the DSEs. The idles enter the
TERI in the ASM. The hardware reports this to the OS.
[b]
Because of the idle pattern received by the receive channel at the network side,
the cut–through to the transmit channel at the cluster side is broken automatically.
Also this event is reported to the OS.
[c]
Processing of the events: The event in the transmit channel at the cluster side is
detected by the OS which breaks the other cut–through connection between the
corresponding receive channel at the cluster side and the transmit channel at the
network side.
[d]
The event in the receive channel at the network side is also processed and the
OS detects that the path that was released, belongs to a duplex connection. It
takes actions to release the other part of the UCP. This is also done by sending
the IDLE protocol over the network. The path is released and the same type of
event is created in the receive channel of the SCM.
[e]
The PUT TO RAM between the receive channel and a PACKET RAM location is
disconnected automatically.
From this moment on there is no longer a relation between our subscriber and the
DTMF receiver.

1.
When the release of the path was successful, both DHs (in the ASM as well as in the
SCM) are informed. OS sends a message to both device handlers (not shown in the
overview figure !).
3. Set the receiver idle:
The receiver is brought to the idle state.
[9]
The three digits are sent to CFCS.
6.1.7 Perform B–party analysis / Request DID
Figure 266 : Perform B–party analysis and request DID

SCALSV
PATED TRC CHAN CGC TRA
3 4 SACETRA
CFCS
1 2
SACELSIF
ASSS_ASIG ARTA LSIF

A
The B–party’s profile and the DID are retrieved.
[1]
data request
CFCS requests B–party analysis.
The message towards LSIF contains:
– DNET: this code was retrieved from PATED;
– the remaining digits: D5, D6 and D7 in our example.
[2]
data results
In chapter 3.4.9 we explained how LSIF uses this information to determine the destination.
Via a conversion to DNEH an index is found, and together with the last two digits the correct
tuple can be identified. LSIF finds:

1.
- Equipment Number (EN);
This includes the LCE–identity and the TN of the destination subscriber. The EN
uniquely identifies the subscriber within this exchange.
- Terminating Line Class Of Service (TLCOS)
This is the data of the B–party. It contains amongst others:
– Facility indications and allowance flags (Call transfer, ...)
– Access status: Normal line, coinbox, operator, priority line, ...
– Allowed Basic Services and Bearer Capabilities (see also ISDN calls)
- Restriction Match
As explained in the chapter or LSIF, the restriction match checks the Calling Party
Category (CPC) against the access status (normal line, operator, dataline, coinbox, ...)
The result indicates if the call can continue or results in a CAUSE. With this CAUSE
PATED is accessed to define what to do next (see CAUSE analysis). In our example
the call will continue.
[3]
DID request
CFCS requests the Device Interworking Data (DID). The DID is handled by the Trunk
Resource Allocator (TRA). Refer to chapter 3.4.11 for more details on the DID.
[4]
DID data
TRA returns the DID results to CFCS.

1.
6.1.8 Seize B–party / Start ringing phase
Figure 267 : Seize B–party and start ringing phase

SCALSV
PATED TRC CHAN CGC
CFCS
1
13
ASSS_ASIG ARTA
2
A B
ASSS_TSIG
4
15 3
14
A B
ASSS_TSIG 11
ASSS_TSIG
5,12 6
LCHG LCHG
10
SMD FMM 8 SMD FMM

7,9
LCRC DH SSM LCRC DH SSM
ASM (orig) ASM (term)
The B–party’s profile and the DID are retrieved.
[1]
CFCS sends the B–party’s profile to ASSS_ASIG_A.
[2]
join
For analogue calls the new join information is transmitted to the device handler because
very soon the UCP between both subscribers will to be connected.

1.
REMARK: It is possible that the information is queued if the SCM is not yet released.
[3]
signalling to signalling
To set–up the terminating call ASSS_ASIG_A allocates new TACB, which will be labeled
from now on as ASSS_ASIG_B.
[4]
intra signalling
The ASSS_TSIG of the terminating side is triggered, resulting in the creation of a new
TACB, from now on labeled as ASSS_TSIG_B. Depending on the cross–over state, the
message is received in the own ASM or in the mate ASM of the destination subscriber.
However in both cases the actions in software remain the same.
The message also contains the destination TN to identify the B–party in ASM_B.
Note: If the destination subscriber is busy, a message is returned to ASM_A. There (PA)TED is
accessed with a CAUSE to define how to terminate this call. The result indicates that a busy tone
should be transmitted to the A–party. This tone is retrieved from the tone port (see dial tone) but this
time the connections are established in the terminal interface of the ASM instead of the SCM.
[5]
remove terminal from the origination scanning list.
[6]
select channel
ASSS_TSIG_B sends a request to the device handler to:
– indicate the device state busy;
– [7]
get cluster handler path
send a command to the hardware to power on the subscriber line;
select a cluster channel towards the ALCN. The identity is also transmitted to the
ALCN logic (compare with A–party);
– set up a UCP towards ASM_A;
– send ringing tone to the originating subscriber;
– request for ringing current to the B–party;
– relink with CFCS . In the message also the channel identity is returned. CDE
dependent a ”wait for answer” is started in ASSS_TSIG_B.
Some of these actions are discussed in more detail below.

1.
[8]
set up spata path
The setup of a UCP was also discussed in chapter 3.3.3. The DH_B transmits a BASIC VIA
to the DH_A after requesting a spata channel to the OS.
Upon receipt of this message in the SMD FMM_A, the latter makes a duplex cut–through
between the UCP and the cluster path.
SMD FMM_B connects ringing tone to UCP towards A–party.
The RT is connected to the UCP via a FETCH command.
First, immediate ringing tone is sent to the subscriber (500 ms) The samples for this
tone are available in a fixed PRAM location.
Second, after the 500 ms time–out the interrupted ringing tone is sent (e.g: 1 second
tone and 3 seconds silence, ...)
[9]
request ringing active
SMD FMM_B requests ringing current towards the B–party.
The hardware situation at this moment (except for the ringing current) is shown in figure 268.
Figure 268 : Ringing phase
1 2 2 1
R R R R
T T T T
3 4 4
É 3
É
R R R R
T T DSN T T
R
ASM ASM Ring.Gen.
- Request ringing current
To provide the subscribers with ringing current (=RC), there is one RNGF PBA for
every ASM.
The main function of the RNGF PBA is to generate a stabilised AC ringing signal in
addition to the DC voltage of the ’a’ and ’b’ wire.
One RNGF contains two identical ring circuits and provides a RC source for up to 128
subscribers. It can provide asymmetric (the 2 buses serve 64 subscribers each) as well
as symmetric ringing current (the 2 buses are combined to serve 128 subscribers).
a. Hardware
– The RNGF PBA

1.
The ringing PBA is connected to the cluster link of the own terminal interface and
the cross–over terminal interface (in case of cross–over, the mate processor must
access the ring PBA). The processors can send commands to the PBA (via
CH16) to activate or deactivate the circuit.
When the circuit is activated, it generates a continuous AC signal. This signal is
received on all subscriber circuits of all ALCNs, but it is not connected. To connect
the signal (so that the telephone starts ringing), the processor must transmit a
command to the appropriate ALCN to close the switch (relay). The cadence of the
RC (e.g: 1 second ringing and 3 seconds silence, ...) is done by opening and
closing (activating and deactivating) the relays.
This is clarified in figure 269.
Figure 269 : Switching of RC

RC
To own TERI ALCN
CH16 ...
Commands
To other ALCNs
RNGF
Ringbus
CH16 Ringing
Commands
Generator
To cross–over TERI
– Ring phases
Let us consider the example of 1 second RC and 3 seconds silence. It is possible

for the RNGF PBA to send RC to maximum 8 subscribers. This means that
maximum 8 different subscriber relays are activated.
During the silent phase, however, the relays are deactivated and nobody is
receiving RC. During this phase it is possible to send RC to other subscribers, etc.

1.
This can be done for 4 phases and the result is shown in figure 270. In this way it
is possible to send RC to maximum 32 subscribers.
Figure 270 : Ringing Phases

on
RC
off Phase 1 Phase 1
on
RC
off Phase 2 Phase 2
on
RC
off Phase 3
on
RC
off Phase 4
b. Software
– Ring phases
The switching of the phases is implemented in the software. The DH receives a

time out message every 200 ms. In this way it can count the 4 phases with a 200
ms resolution.
Each time a phase change occurs, the DH opens all the relays of the subscribers
receiving RC and closes the relays of the subscribers belonging to the next
phase.
If all 4 phases are empty (no subscribers assigned), then a command is sent
towards the RNGF PBA to switch off the ringing generator.
Note: The switching of the relays is called ”dry switching”. This means that the ringing generator is
switched off before the relays are opened and switched on again when the other relays are closed.
– Ringing current request
When the DH wants to send RC to a subscriber, it must assign a phase to the

subscriber. Then the subscriber receives RC according to the phase switching
mechanism explained above.
The phase selection is done according to the flowchart below.

1.
Figure 271 : Phase selection
Ringing Request
Time left in N
current phase
<400ms
NEXT PHASE
N
Nbr of assigned
subscribers = 8
Assign to the
Y selected phase
N All phases
checked ? Connect
immediate RC
(Activate switches)
CAUSE
In the above flowchart, one of the actions is: ’Connect immediate RC’. This is when a
subscriber is assigned to a phase which is not the current one. In this case the subscriber
switches are closed at any rate, and the normal cadence starts when the subscriber’s phase
is reached.
[ 10 ]
channel info
SMD FMM_B replies with the channel information.
[ 11 ]
intra signalling
ASSS_TSIG_B acknowledges the terminating seizure.

1.
[ 12 ]
transmission parameters
ASSS_TSIB_B initialises receive and transmit values.
[ 13 ]
The final acknowledgement: linking of the terminating side is complete.
[ 14 ]
signalling to signalling
Acknowledgement of the seizure of the B–party.
[ 15 ]
intra signaling
Acknowledgement of the seizure of the B–party.
6.1.9 Activate charging

Figure 272 : Activate charging

3 SCALSV
PATED TRC CHAN CGC
2
1 4
CFCS
ASSS_ASIG
A B ARTA
ASSS_TSIG
A
5
LCHG
SMD FMM
LCRC DH SSM
ASM (orig)

1.
The charging information is picked up and a taxation cell is allocated.
In most countries charging is activated at this moment. For more details refer to chapter 8.
In this chapter only an overview is given.
[ 1 ] charging request
Charging is activated via a message from CFCS. It is up to the charging FMMs to define the
charging for ”our” subscriber (method, number of pulses, rate, ...). The charging FMMs also
allocate a taxation cell for the call (1 or more depending on the supplementary services of
the subscriber). Then the result is sent back to CFCS. The most important information
received from charging is the identity of the taxation cell(s).
[ 2 ] request charging information
[ 3 ] send charging information

[ 4 ] request allocation of charging cell
[ 5 ] charging start–up acknowledge
6.1.10 Pass to stable state
Figure 273 : Pass to stable state

SCALSV
PATED TRC CHAN CGC
CFCS
1 2
A B
ASSS_ASIG ARTA
Once the B–party has been seized and the ringing phase has started, the only task left
to do is to wait until the B–party answers. Therefore there is no need for high–level software
to be active. Remember that CFCS controlled the whole call and kept all the data about the
call in a datazone. At this moment the CFCS passes part of it’s information to the signalling
in ASM_A, and part of it’s information to signalling in ASM_B. The application process may
then terminate.

1.
[ 1 ] [ 2 ] pass to stable state

The stable call data is passed to signalling.
ASSS_ASIG_A stops the overall–dialling time–out.
ASSS_ASIG_A also received the taxation cell identity because it is ASSS_ASIG_A that
warns the charging FMM about the on–going events, like B–party answer and A–party or
B–party hook–on. These events can then be used by the charging FMM to start or stop the
charging.
At this moment we are in stable state which means that the A–party is receiving ringing tone
and the destination set is ringing. The A–party and the exchange are both waiting for
answer.
6.1.11 Detect ring trip

Figure 274 : Detect ring trip
SCALSV
PATED TRC CHAN CGC
CFCS
ASSS_ASIG ARTA
7
A B
3
A B
ASSS_TSIG 4 ASSS_TSIG
2
LCHG LCHG
SMD FMM SMD FMM

1 5

1.
When the B–party answers the signalling has to be informed and the charging has to
start.
[ 1 ] ring trip
The detection of answer is the same as the hook–off detection. The hardware reports
towards OS which triggers the LCRC DH SSM_B.
LCRC DH SSM must remove the ringing current as soon as possible. If the subscriber is in
the silent period, the SSM removes the subscriber from the ringing queue. However, if the
subscriber receives ringing current at this moment, the SSM first deactivates the relay before
removing the subscriber from the queue.
LCRC DH SSM then reports the ring trip to ASSS_TSIG_B.
[ 2 ] put terminal in busy scan with recall.

[ 3 ] intra signalling
ASSS_TSIG_B reports the answer to ASSS_ASIG_B.
[ 4 ] join
SMD FMM_B removes the ringing tone and joins the B–party to the UCP.
[ 5 ] request ring idle.
[ 6 ] signalling to signalling
ASSS_ASIG_B reports the answer to ASSS_ASIG_A.
[ 7 ] charging event
ASSS_ASIG_A indicates the answer to charging (e.g. to start the collection of charging
pulses)
ASSS_ASIG_A also cancels the answer time–out.
6.1.12 Stop charging / Release A–party
a. Clear forward (forward release)
If the release of the call is initiated by the A–party we call this a clear forward or a
forward release.

1.
Figure 275 : Stop charging and release A–party
SCALSV
PATED TRC CHAN CGC
CFCS
ASSS_ASIG
A B ARTA
4,11
3,10
5
2,7
A B
ASSS_TSIG ASSS_TSIG
8 6
LCHG LCHG
SMD FMM SMD FMM

1
9
When the A–party hooks on, the subscriber has to be released and the charging has to
be stopped.
[ 1 ] hook on
LCRC DH SSM_A indicates to ASSS_TSIG_A that the A–party hooked on.
[ 2 ] put terminal in busy scan list
ASSS_TSIG_A reports the hook–on to ASSS_ASIG_A.
ASSS_ASIG_A reports the hook–on to ASSS_ASIG_B and starts a time–out for delayed
congestion tone (e.g. 12 s).

1.
ASSS_ASIG_A indicates the necessary actions to ASSS_TSIG_A:
– release the A–party;
– report the charging event.
[ 6 ] charging event
ASSS_TSIG_A reports the hook–on to charging (e.g. to stop the charging).
[ 7 ] remove terminal from busy scan list
[ 8 ] release
SMD FMM_A executes the release of the UCP and the cluster path.
[ 9 ] return cluster path
(the principles of UCP release were explained in the chapter on the DTMF
receiver release)
put terminal in origination scanning list
The terminal can originate a new call and is powered down.
Also the subscriber state is changed to ’available free’. When the UCP is released, OS
sends this event to both DH FMMs (not indicated in the overview figure !).
ASSS_TSIG_A acknowledges the release.
ASSS_ASIG_A indicates the release to ASSS_ASIG_B.
From the COL the software retrieved the information whether or not the subscriber should
receive a parking tone (see retrieval of COL before). Depending on this information, two
cases are possible:
- Silent parking
ASSS_TSIG_B sends the clear forward to the DH. The latter puts the subscriber in the
parking state. The cluster path is released and the line is put in power down. When the
B–party replaces the handset, the event is sent to the DH and the subscriber is put
available free.
- Parking with tone
The ASSS_TSIG_B starts a time–out and sends a request to the DH to connect this
tone and to enter the parking state.
If the subscriber replaces the handset within this time–out, then the time–out is stopped
and the DH is triggered to disconnect the tone and put the subscriber available free.

1.
If the time–out expires, then ASSS_TSIG checks in database if a second tone has to
be connected. If not, the silent parking actions are started.
b. Clear backward
If the release of the call is initiated by the B–party we call this a clear backward or a
backward release. Because of the similarity of the scenario (same principle as clear
forward), no scenario is given here.
Upon receipt of the called hook–on, ASM_B informs ASM_A. There, charging is
informed because CDE dependent charging can continue, change or be temporarily
stopped.
Moreover, a reanswer time–out is started to give the B–party the chance to lift the
handset of the same or another set connected to the same line. Three possibilities
exist:
– A–party hooks on:

The hook–on results in the same actions as the clear forward. Only this time the
B–party is available free instead of being put in the parking state.
– Reanswer time–out expires:
ASSS_TSIG_B receives the time–out message. Actions are taken to put the
B–party available free and release all the connections and the cluster path.
The originating ASM is informed to stop charging and to put the A–party in the
parking state until hook–on.
– B–party hooks off again:
The event is translated to REANSWER and the reanswer time–out is stopped.

Also the originating ASM is informed to send the event to charging (if the charging
was modified or stopped, it will resume with the previous charging) The
conversation can continue.

1.
6.1.13 Release B–party
Figure 276 : Release B–party

SCALSV
PATED TRC CHAN CGC
CFCS
ASSS_ASIG ARTA
B
3
B
2,5
ASSS_TSIG
4
LCHG
SMD FMM
1
LCRC DH SSM
ASM (term)
The B–party’s telephonic state is changed to available free.
[ 1 ] hook–on
LCRC DH SSM detects that the B–party hooked on.
ASSS_TSIG_B reports the hook–on to ASSS_ASIG_B.
ASSS_ASIG_B indicates the necessary action to ASSS_TSIG_B:
– release B–party.
[ 4 ] release
SMD FMM releases the B–party: the cluster path is released and the telephonic state is
changed to available free.

1.
ASSS_TSIG_B acknowledges the release.
6.2 Local call with ISDN subscribers
6.2.1 Example of an ISDN
Figure 277 : Example of an ISDN
Ç
S–interface
Ç
U–interface
NT1 ISM
subscriber’s premises A1000 A12
Ç ISDN
PRA
Ç
IPTM
PABX
Ç
2 Mb/s PCM
IRSU
Ç
IRIM
Ç
1.
a. The S interface
The S–interface has a four wire configuration.

It allows to connect up to eight ISDN terminals. The terminals are simply connected in
daisy chain.
b. The basic rate access interface
The basic rate access interface is an interface with many names:
– basic rate access (BRA);
– basic access (BA);
– 2B+D interface.
Technically the more interesting name is 2B+D interface, because it sheds some light
on the capacity of the interface: the interface contains two B channels and a D channel.
The B channels are used for any type of circuit switched communication, such as:
– speech;
– circuit switched data transmission;
– video transmission.
The B channels are allocated for the duration of a call. They have a bit rate of 64 kb/s
each.
The D channel is used for:
– signalling, for example to set up and release a call;
– packet switched data transmission;
– telemetry.
The signalling information and possibly the data packets are all multiplexed into the
same channel. The D channel has a bit rate of 16 kb/s.
The total bit rate on a BRA interface is thus 2*64 kb/s + 16 kb/s = 144 kb/s.
The line coding on the BRA interface is either 4B3T or 2B1Q.
– With 4B3T 4 binary digits (bits) are converted into 3 ternary digits. As a result the
signalling rate on a BRA is 120 kBaud (144 *3 /4 + control signals).
– With 2B1Q line coding 2 bits are converted into 1 quaternary digit. As a result the
signalling rate on a BRA is 80 kBaud (144 /2 + control signals).

1.
The BRA interface has a two wire configuration.

To provide a full duplex transmission, echo cancellation is used.
c. The primary rate access interface
A primary rate access (PRA) has 30 speech channels (B) and one signalling channel
(D). It is therefore called a 30B+D interface. Each channel operates at a bit rate of 64
kb/s.
Note: The D channel of a PRA has a bit rate of 64 kb/s, as opposed to the bit rate of the D channel
of a BRA, which has a bit rate of 16 kb/s
The bit rate on a PRA is 2.048 Mb/s. The PRA uses a frame of 32 channels, numbered
from 0 till 31. The channels have the following functions:
channel 0 synchronisation
channel 16 conveys the D channel information

channels 1–15 and 17–31 contain the 30 B channels
A PRA is typically used to connect an ISDN PABX to an exchange. The distance

between the user and the network is unlimited, provided that regenerators are used.
6.2.2 Overview of the ISDN protocols
Figure 278 : The OSI model for a BRA

speech / video / data
data (circuit switched) signalling (packet switched) telemetry
layer three B1 entity B2 entity S entity P entity T entity
layer two B1 entity B2 entity LAPD entity
layer one physical entity
The ISDN standards are compatible with the bottom three layers of the open systems
interconnection (OSI) reference model. Figure 278 demonstrates this for a BRA.
In layer three, the network layer, you find the entities that represent the two B channels and
three entities for the D channel: the signalling entity, the packet switching entity and the
telemetry entity.

1.
In layer two, the data link layer, the D channel follows a data link protocol of the high–level
data link control (HDLC) type. That protocol is called link access protocol on the D
channel (LAPD).
In layer one, the physical layer, a frame structure has been defined to convey the bits on a
BRA or a PRA. It is only on this level that a distinction between BRA and PRA is made !
The following table compares the OSI definitions with the ITU–T standards.
layer OSI model ITU–T standard

3 network layer Q.931
2 data link layer Q.921
1 physical layer I.430 / I.431
6.2.3 Layer three: the network layer

The network layer performs the routing functions and handles the signalling messages and
signalling procedures.
The signalling at layer three is referred to as digital subscriber signalling one (DSS1).
Figure 279 : Generic layout of a DSS1 message

1 byte
protocol discriminator
length of
0 0 0 0
call reference
call reference
message type
information element optional and repeatable
Figure 279 gives the generic layout of a DSS1 message. It contains the following
components:
- Protocol discriminator
The protocol discriminator indicates the layer three protocol. The most important value here
is H’08 indicating Q.931 user–network call control messages.
- Call reference
The call reference uniquely identifies a call within a logical link connection on a
user–network interface. It has no end–to–end significance. This means that the call

1.
reference value that identifies a call between the A–party and the exchange and the call
reference value that identifies the same call between the exchange and the B–party can be
totally different.
The call reference is a layer three parameter. It has a length of one byte for a BA and one or
two bytes for a PRA. The following figure gives possible layouts of the call reference.
The call reference value is allocated by the originator on the user–network interface.
Typically this would be the A–party’s telephone set on the first user–network interface and
the exchange on the second user–network interface.
- Message type
The message type is a 7 bit value that indicates the type of DSS1 message, such as set–up
message, connect message and so on.
- Information element
The real information is carried in a number of information elements.

6.2.4 Layer two: the data link layer
The data link layer performs the error control functions and the flow control functions.
a. Layer two packet layout
Figure 280 : Layer two packet layout
layer three information
layer two flag address control frame check flag

sequence
8b 16 b 16 b N*8 b 16 b 8b
The packet contains the following fields:
– flag:
The flag is used to separate two messages. It has a fixed layout: B’0111 1110.
– address:
Since there can be up to eight terminals on a BA, each terminal has to be addressable
in a unique way. This is achieved with two layer two parameters: the terminal endpoint
identifier (TEI) and the service access point identifier (SAPI).
The terminal endpoint identifier (TEI) identifies the physical terminal on a BA. It is a
number from 0 to 127. The values have the following purpose:

1.
TEI purpose
0 – 63 non–automatic TEI assignment
64 – 126 automatic TEI assignment
127 broadcasting
The values for non–automatic TEI assignment have to be programmed into the ISDN
equipment by the user.
The values for automatic TEI assignment are dynamically allocated when the first call is
started from a newly connected terminal.
The service access point identifier (SAPI) identifies the type of call. It is a value from
0 to 63 with the following assignment:
SAPI purpose
0 call control part (circuit switched call)
16 packet switched call

63 management call
The combination of the TEI and the SAPI uniquely identifies a data link.
With a SAPI value of 16 the packet switching network can be accessed. This requires
interworking between the D–channel and the PS network. The System12 module that
takes care of this is the IPTMN.
– control:
The control field contains a sequence number and flow control information. It is used to
acknowledge messages or to request retransmission.
– information:
The information is passed by layer three.
– frame check sequence:
The frame check sequence (FCS) is calculated by the sending side and transferred
together with the message. The receiving side recalculates the FCS and compares the
found value with the FCS value from the message. If they are equal, the message is
assumed to be received correctly. If the two values are different, the message is
discarded.
b. Layer two packet carrying a layer three packet
If a terminal sends a layer three packet, it first passes the packet to layer two. Layer
two then adds a number of fields, as explained in the previous chapter. Eventually the

1.
packet arrives in the ISM. The packet is passed to the ISS FMM in the form of a
System12 message. The data part contains the terminal number (TN) and the TEI. The
actual layer two packet, including the layer three cargo, is attached as a user buffer.
c. Layer two packet sequences
Figure 281 : Layer two packet sequences

TE NT
UI
TEI assignment
UI
SABME
data link set–up
UA
RR
receiver ready
RR
– TEI assignment
When a terminal requests a TEI, it broadcasts the request to the host. The host
allocates a TEI and sends the TEI value over the broadcast data link to the terminal.
Since it is possible that several terminals request a TEI simultaneously, the requesting
terminal includes a random number with it’s request. When the host replies, it includes
that number as well. This way each terminal knows which reply it has to use.
– data link set–up
To set up a data link a set asynchronous balanced mode extended (SABME)

message is sent. The response is an unnumbered acknowledgement (UA).
– receiver ready
This layer two message is sent every 10 seconds if a data link is established.
6.2.5 Layer one: the physical layer
The physical layer is described by three types of recommendations:
– electrical recommendations;
– mechanical recommendations;

1.
– functional recommendations.
According to these recommendations the S interface has a four wire configuration; two wires
in either direction. The wires are connected via an RJ45 plug (8–pins).
6.2.6 Terms and definitions
a. High layer compatibility
The high layer compatibility (HLC) is a value that is used by the terminating side to
perform compatibility checks. It represents the type of equipment that is used. The
purpose is to connect a telephone set to an other telephone set, a facsimile machine to
an other facsimile machine and so on. Typical values include:
– telephony;
– facsimile group 2/3;
– facsimile group 4, class I;
– facsimile group 4 class II/III;
– teletex services;
– message handling systems (MHS);
– OSI applications.
b. Low layer compatibility
The low layer compatibility (LLC) is a value that is used by the terminating side to
perform compatibility checks. It contains data that describes the lower level of the
equipment that is used, such as the information transfer rate, the transfer mode, the
number of stop bits and data bits, and so on. If provided by the call originator, the LLC
is passed to the termination transparently through the ISDN.
c. Bearer capability
The bearer capability indicates the requested bearer service to be provided by the
network. Typical possibilities are:
– UNR_DIG
– SPEECH
– AUD_3_1K

1.
d. Basic service
The basic service (BS) represents the meaningful combinations of a bearer capability
and a high layer compatibility. The purpose is to allow certain facilities to be defined per
basic service. If all the combinations of BC and HLC were defined, too much data
would be required.
e. Multi–subscriber number
The multi–subscriber number (MSN) allows an operator to assign multiple directory

numbers to the same ISDN subscriber. The subscriber would then program his
terminals with different numbers. The purpose can be diverse:
– an A party can dial one of these numbers to arrive at one terminal in particular;
– the ISDN subscriber can request different facilities for the different MSNs;
– the B party will see this MSN as the originator (providing CLIP for B party and no
CLIR for A party);
– the MSN can be used for charging to indicate the A party.
For call handling one of the MSNs is declared as the default. This is amongst others
important for the location of the subscriber data, which depends on the DNET. All the
data associated with that ISDN subscriber will be stored in the same SACELSIF, even if
he has MSNs with different DNET values !
f. Subaddress
The subaddress is a number additional to the directory number of a subscriber. The

directory number identifies an S interface, whereas a subaddress allows to distinguish
between different terminals on the same S interface. The subaddress is passed
transparently through the ISDN. If a subscriber wishes to use subaddresses, he has to
program the value on his equipment.
If an originator passes a subaddress in a set–up message, then at the termination only

the terminal that has that subaddress will react to the set–up message.
Note: Also the terminals that do not have a subaddress programmed will react !!
g. Interworking directory number
An interworking directory number (IWDN) allows an operator to assign different DNs to

an ISDN subscriber. The numbers can only be used in calls terminating at one of those
numbers. The terminating exchange translates the IWDN into the real DN of the
terminating ISDN subscriber and a subaddress and a HLC.
This is the only way an analogue subscriber can reach a particular type of equipment,
represented by the HLC, at the terminating subscriber (except for the default HLC).

1.
It can also be used, in addition to the MSN, to allow an analogue subscriber to reach
one of the terminals in particular at the terminating side.
h. User–to–user signalling
User–to–user signalling (UUS) allows an ISDN subscriber to send information (typically
text or numbers) via the D channel to an other ISDN subscriber. This information can
then be displayed on the telephone set, or used by the B party’s PC.
There are four types of UUS:
– UUS1: UUS during the call set–up and clearing;
– UUS2: UUS during the alerting;
– UUS3: UUS during the active phase of the call;
– UUS4: UUS without allocating a B channel.

6.2.7 Handling of a Q.931 message in S12
Figure 282 : Q931 messages

ISM
D–CH
...
BA D–CH L1
... DSN
ILC L2
MEM PROC
DH
L2
SIG L3
PROC
L3
L2
L1
D

1.
Figure 282 shows which elements in S12 handle the different layers of the D channel.
- The Q931 is received via the D–channel of the BA. The D–channel is read by the ILC
(ISDN Link Controller).
This LSI executes the hardware L2 functions: Flag insertion and detection, bit(de)stuffing,
FCS (Frame Check Sequence) generation and checking, generate Tx fillers and delete
Rx fillers (flags or all ones).
- The ILC writes the message in the memory and informs the processor (interrupt).
- The processor can check the FCS result from the ILC and executes the remaining layer 2
functions (handling the sequence numbers, TEI and SAPI, flow control, ...)
- The processor then transmits the message (layer 3 information only!) to the control
element.
Because of the limited size of the PRAM buffers, the processor partitions the Q931
message into several parts (if necessary) and transmits them one by one. Again to
provide error free transmission, the packets are labelled and a sequence check (with
acknowledge) is used (similar to CCS N7 using FIB,BIB). This principle is not shown in
figure 282.
- The packets are received one by one in the DH and transmitted as a whole (A1000 S12
message) to the ISS.
- ISS is responsible for the layer 3 actions.
The principle of message sending is the same in the other direction and is therefore not
repeated here.
6.2.8 Local ISDN call overview
The following figure sketches a local call scenario, displaying only the DSS1 messages
exchanged between the subscribers and the exchange. The figure indicates the scenario in
case the B party has two terminals (of the requested type).

1.
Figure 283 : ISDN local call scenario

B–party
A party
term_1 term_2
A dials B’s DN
set–up set–up
call proceed call proceed
call proceed
alert alert
A1000 S12
alert
ringing ringing ringing
term_1 answers
connect connect
connect acknowledge connect acknowledge

release
release complete
conversation conversation
A hooks on
disconnect disconnect
release term_1 hooks on

release
release complete
release complete
A couple of remarks:
- if the B–party hooks on first, the release of the call is the same as above with the bottom
6 messages mirrored;
- the scenario assumes en–bloc sending, where the set–up message contains the full
B–party number (DN and possibly SA). An alternative is overlap sending, where the
set–up message contains either only a part of the B–party number or no number at all.
The further digits are then sent in information messages;
- the scenario excludes the data link set–up and release.
a. Scenario from A–party towards S12
This scenario is given for a BA.
When a call is generated in an ISDN set, the called DN is entered manually or from the
set’s database and a key (or multiple keys) is pressed to start the call setup.

1.
At this moment the set wants to send a Q931 SETUP message but a BA is normally
powered down. Therefore the subscriber’s equipment (NT1) activates layer 1 (power
up) by sending a fixed pattern.
Then layer 2 is activated via the SABME and UA sequence.
Then the set can transmit the layer 3 Q931 SETUP message. This message contains
the following layer 3 information:
– Call reference;
– Bearer Capability:
This was explained before, in our example it is speech.
– Channel identification:
Identity of the B–channel on the BA (B1 or B2). From the subscriber to the ISM
this field is optional because the host is responsible for the channel assignment
(SMD FMM).
– B–party Number (DN) and Subaddress;
– A–party Number (DN) and Subaddress;
– LLC and HLC;
– User to User Signalling (UUS).
The host responds by sending the CALL PROCEEDING backwards. This message
contains the channel identity (B1 or B2) to be used for this call.
The ALERTING message indicates that the B–party is reached and that the call has
entered the stable phase (ringing).
When the CONNECT is received from the called party the set will acknowledge with a
CONNECT–ACK. The connect message can indicate the ’connected address’ which
can be displayed on the display.
From now on we are in conversation phase.
For an ISDN subscriber the clear forward and clear backward are treated in the same
way because the reanswer possibility does not exist in ISDN. This is because an ISDN
subscriber can use the SUSPEND and RESUME messages to switch to another set or
temporarily suspend a call.
When the subscriber finishes the call, a DISCONNECT is transmitted to the exchange.
This is a request to release the call.

1.
If the request is accepted, the exchange transmits a RELEASE backward, which is also
acknowledged with RELEASE COMPLETE.
The final actions are the termination of layer 2. This is done by sending the DISC and
UA frames.
b. Scenario from S12 towards B–party
This scenario is different compared to the originating scenario because here we use
Call Offering. This means that the call is offered to all compatible terminals and one
terminal can connect the call.
This is done by sending a Q931 SETUP Broadcast message (after activating L1 and
L2). This message contains the channel identity (B1 or B2).
Broadcast means that the message contains the TEI = 127. In this case the message is
accepted by all the terminals. When the terminals check the information (HLC) only the
compatible terminals will respond. When a subaddress is available only that terminal
will respond.
In our example, 2 terminals will respond (two telephone sets).
Terminal 1 responds by activating its layer 2 (SABME and UA) and sending the CALL
PROCEED. Then the set starts ringing and indicates this via the ALERTING message.
The same procedure is repeated by terminal 2. Both telephone sets use the same call
reference but the difference between the message for terminal 1 or terminal 2 is made
by the TEI values. Each set connected to the same BA uses a different TEI.
In our example, terminal 1 answers by sending the CONNECT message.
The host responds by sending the CONNECT ACK back to terminal 1. However, the
second terminal is still in the alerting phase. Therefore the host sends the RELEASE to
this terminal which responds with a RELEASE COMPLETE. Also the L2 of terminal 2 is
disconnected (DISC and UA).
We are now in conversation phase. The call release scenario is the same as for the
originating call and is therefore not repeated.
6.2.9 Local ISDN call in detail
Figure 284 gives the call phases for an ISDN local call. The principles for an outgoing or
incoming call are the same as explained before (see case study). That is why only the local
call is indicated.
The Q931 messages are also indicated in this figure. Their meaning and contents were
already discussed in the previous paragraphs, so they are not repeated here.
Only some differences with the analogue local call are explained in the following paragraphs.

1.
The phases are more or less the same, except that for an ISDN subscriber some phases are
omitted. This is because of the powerful Q931 signalling system (compatible with CCS N7)
which doesn’t need a receiver. These phases are deleted from the scenario (see crosses)
but are still visible to clearly indicate the differences with analogue scenarios.
Remark: the A–party Q931 messages are on the left side of the pages and the B–party messages
are printed on the right side.

1.
Figure 284 : Local Exchange
SUBSCRIBER
SETUP
SEIZURE
CALL PROC
PREPARE & SEND

DIAL TONE
DETECTION OF
PREFIX DIGITS
PREFIX ANALYSIS
LOCAL OUTGOING
END OF DIALLING
RELEASE RECEIVER

SETUP IAM
TERMINATING SEIZURE CALL PROC OUTGOING TK SEIZURE
ALERT ALERT
ACM
PASS TO STABLE STATE PASS TO STABLE PHASE
CON CON
ANC
ACK ANSWER ACK ANSWER
CONVERSATION
DISC DISC CLF

REL REL FORWARD RELEASE
FORWARD RELEASE
REL_C REL_C RLG
CLEAR
a. Seizure
SETUP

1.
– The setup contains all the necessary information to start the call. Because all the
information in the message is digital, there is no need for a receiver to detect the
digits. The dial tone is generated locally in the set.
– Signalling creates a transaction for this call and allocates a transaction control block
(see local call).
– SCREENING (figure 285)
Screening applies to ISDN subscribers and to analogue subscribers in case they

are connected to a Mixed Subscriber Module (MSM), Mixed–RSU or ISDN
Concentrator (ICON).
Figure 285 : Screening
Screening
A–party DN
DK
Translate
Scrn_grp
& OK/NOK
Scrn_grp
TN
Translate (Default DN/DK)
The TN (only 1 TN / BA) and the A–party DN are translated into a screening group
number (scrn_grp). Both numbers must be equal to have an ’OK’ condition. At the
same time the DN is translated into the DataKey (DK). This key was mentioned
before. Each data key (read: Directory Number) can have a different data profile.
There is a one to one relation between the DK and the DN, but the DK is easier to
use to access database (index instead of the binary search using the DN).
If the A–party DN is not found (E164, PBX number or Private Number [see
facilities]), then the call is REJECTED.
In case the A–party DN is not provided or the screening procedure is not used
(depends upon the administration), the TN can be translated into the default
A–party DN and DK which will be used during the further call setup.
– A cluster path is allocated and connected to the B–channel
– ISS gets the OLCOS from the database using the DK as input.
DNET: used to define the LSSG for this subscriber to access the LSIF data (done
later by CFCS)
Subscriber group

1.
Calling Party Category = CPC (normal subscriber, coinbox, data line, test call,...)
Charging information
Number of prefix digits required
Facility allowance (abbreviated dialling, hotline, ...)
Indication if CFCS must access the data at ACE level
...
– CFCS is activated. The global scenario can be compared with figure 254, but the
access to ARTA is not included.
CFCS sends a request to LSIF to retrieve the data (the DNET and the digits are
used to define the index in the LSIF relations):
Facility related data: abbreviated dialling, full three party service, hotline
information, password for subscriber control (SC), ....
Changed number (can be used to send announcement)
Selective scanning list. This is a list of DNs of which the calls can be rejected,
different ringing or forward their incoming calls.
Specific ISDN information: CUG information (Closed User Group), UUS (User to
User Signalling), Advice of Charge (AOC), DNs presentation (restrictions and
override), ...
Basic Service dependent facilities: Call forwarding, Incoming and Outgoing

Barring, ... (remember BS=0 for analogue subscribers)
Call Proceed
b. Prefix Analysis
– All the digits were received ’en–bloc’. So all the digits are transmitted towards
PATED. For the input and output of PATED see the case study.
– For an outgoing call the actions were discussed detailed in the case study. For the
local call we terminate towards an ISDN subscriber. Because this is new, we
consider a local call.
Reception of the remaining digits and release of the receiver are not needed for
an ISDN call.
c. Subscriber identification and terminating seizure
– The terminating seizure scenario is similar to that of the analogue call (see also
figure 249).

1.
– For the terminating seizure some messages are transferred to the terminating
equipment (in our example only one set responds to the broadcast)
SETUP
Call Proceed
d. Pass to stable state
– Chapter 5.5.1, message [22] mentioned the fact that signalling waits for the
ALERTING coming from the B–party’s equipment, before sending this alerting event
to CFCS. It is only then that CFCS activates charging and goes stable.
Alerting Alerting
– At this moment the called terminal is ringing and the calling terminal receives RT
from the exchange.
e. Answer
– Upon answer (CONNECT msg) the RT is disconnected, the through connection is

established and taxation is started.
Connect Connect
Connect Ack Connect Ack
f. Forward release
Disconnect
Start release actions Disconnect
Stop taxation
Release
Release
Release Com B–ch free
B–ch free Release Com
All connections are cleared and the subscriber is free again.
6.3 Outgoing / incoming call with CCS N7 signalling
6.3.1 Introduction
Figure 286 shows the situation for an outgoing / incoming call using N7 signalling.

1.
Figure 286 : Overview Outgoing / Incoming Call

Origination Exchange
ACE
SCM IPTM
1 N7
2
ASM DSN IPTM
STP
(N7)
ACE
ASM IPTM
3 N7
4
DSN IPTM
Destination Exchange
Figures 287 and 288 show the different phases in the outgoing and the incoming exchange.
It is left up to the reader to go through the flowcharts. In the subsequent chapters these
phases are discussed in more detail while references will be made to the local call because
many actions are the same or similar.

1.
Figure 287 : Originating Exchange
SUBSCRIBER
SEIZURE
PREPARE & SEND

DIAL TONE
DETECTION OF
PREFIX DIGITS
PREFIX ANALYSIS
LOCAL OUTGOING
END OF DIALLING
RELEASE RECEIVER

IAM
ACM
ANC
ANSWER ANSWER
CONVERSATION
CLF
RLG
CLEAR

1.
Figure 288 : Incoming Exchange
TRUNK
IAM
SEIZURE
PREFIX ANALYSIS
LOCAL OUTGOING

ACM IAM
ACM ACM

ANC ANC ANC
ANSWER ANSWER
CONVERSATION
CLF CLF CLF

RLG RLG
RLG
CLEAR
6.3.2 CCS N7 overview
Before we continue with the call discussion, some information is given concerning the N7
signalling in A1000 S12. For more details we refer to document 770 00438 0590–VHBE.
a. CCS N7 network
It is possible that the N7 signalling messages are sent directly from the outgoing
towards the incoming exchange without an intermediate STP (Signalling Transfer Part).
However, to make the call as generic as possible, we will discuss the situation WITH an
STP (see figure 289).
OP = Origination Point, the exchange where the N7 message originates.

STP = Signalling Transfer Point, the exchange where the N7 message passes.
DP = Destination Point, the exchange where the N7 message terminates.

1.
Figure 289 : Outgoing / Incoming Call with N7 (STP)

STP
N7 N7
Speech
OP DP
b. CCS N7 message layout
The CCS N7 system is a message oriented signalling system, which means that all the
user information is placed in one or more N7 messages. A N7 message is called a
signal unit.
The CCS N7 system can be divided into two distinct parts (figure 290).

1.
Figure 290 : CCS N7 structure
USER PART
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
MTP
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ SIGNALLING NETWORK FUNCTIONS
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁDISCRIMINATION
layer 3 Y
DPC = DISTRIBUTION
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ own PC
?
N
ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ ROUTING
layer 2
SIGNALLING LINK FUNCTIONS
layer 1 SIGNALLING DATA LINK FUNCTIONS
To / From remote exchange
– The Message Transfer Part (MTP) is capable of transporting information without

errors between two end points. This part is common to all N7 users. It is subdivided
into three functional levels (levels 1, 2 and 3).
– A number of different User Parts, which are situated on level 4. Each User Part
takes care of a specific function. E.g: the Telephonic User Part (TUP) is responsible
for the signalling handling. It uses the MTP to pass the signalling information to the
other exchange. Other examples are the ISDN User Part (ISUP), the Taxation User
Part (TAXUP), ...
Besides the User information, the signal unit contains some information to execute
layer 2 functions (error detection and correction) and layer 3 functions (routing). The

1.
message layout is shown in figure 291. Some of the fields will be used in the following
explanation of how A1000 S12 handles the N7 messages.
Figure 291 : MTP structure
user part message header

first bit
transmitted
layer three CIC OPC DPC SSF SI
layer two flag CRC LI FIB FSN BIB BSN flag

layer one flag CRC message header CIC OPC DPC SSF SI LI FIB FSN BIB BSN flag
8b 16b N*8b 8b 12b 14b 14b 4b 4b 6b 1b 7b 1b 7b 8b
– Circuit identification code (CIC)

Since in a N7 environment speech can follow a different path from the signalling,
there is a need to be able to indicate the speech trunks unambiguously. This is
done by numbering them. The exchanges at either end of a trunk have to indicate
that trunk with the same number. This number is the circuit identification code
(CIC).
– Point Code
Every N7 exchange has a unique 14 bit number: the point code. Whenever an
exchange sends a N7 message to an other exchange, it includes its point code as
the Originating Point Code (OPC) and the point code of the other exchange as the
Destination Point Code (DPC).
An exchange can have one point code per network level.
– Sub Service Field (SSF)

The SSF indicates the network level. It is a 4 bit field, therefor giving 16
possibilities. The two least significant bits are not used however, so that only two
bits are used effectively. This gives four possibilities:
Sub Service Field network level

00XX international 1
01XX international 2
10XX national 1
11XX national 2

1.
In practice only international layer 1 and the national level are used. In Belgium
the local level is used as the network to transport the charging messages
(TAXUP).
– Service Indicator (SI)
The SI indicates the type of user part, such as TUP, ISUP, SCCP, and so on.
– Length Indicator (LI)
Per definition the length indicator indicates the number of bytes between the LI
field and the CRC field. However the following possibilities exist:
length indicator purpose name of the signal unit

0 empty message fill in signal unit (FISU)
1–2 link status link status signal unit (LSSU)
3 – 62 real length of the user part message signal unit (MSU)

63 user part > 62 B message signal unit (MSU)
– Forward Indicator Bit (FIB)
The FIB is toggled by the sending exchange to indicate start of retransmission.
– Forward Sequence Number (FSN)
The FSN indicates the sequence number of the message. It is allocated by the
sending exchange and is used by the receiving exchange to detect missing
messages. The FSN ranges from 0 till 127. Only the messages that contain a
layer three message get a new FSN. The other messages repeat the last FSN.
– Backward Indicator Bit (BIB)
The BIB is toggled by the receiving exchange to request retransmission.
– Backward Sequence Number (BSN)
The BSN contains the number of the last message that was received correctly. It
is used by the sending side to know which messages it may deallocate from the
retransmission buffer. The BSN ranges from 0 till 127.
– Cyclic Redundancy Check (CRC)
The CRC is calculated by the sending side and transferred together with the
message. The receiving side recalculates the CRC and compares the found value
with the CRC value from the message. If they are equal the message is assumed
to be received correctly. If the two values are different, the message is discarded.
– Flag

1.
The flag is used to separate two messages. It has a fixed layout: B’0111 1110.
– Header
The header indicates the type of message. The header consists of two 4–bit
fields: H1 and H0.
Figure 292 gives an overview of the working of the N7 system. A user part in exchange
A wants to send some information to a user part in exchange B. There is no direct
signalling connection between exchange A and exchange B. Therefore, the information
will be routed via exchange C. The originating exchange (A) is called the Origination
Point. The destination exchange (B) is called the Destination Point and the
intermediate exchange (C) is called the Signalling Transfer Point. It is left up to the
reader to understand the flow.

1.
Figure 292 : Signal Unit flow
exchange C USER PART
ÁÁÁÁÁÁÁÁÁÁÁ
MTP
layer 3
DISCRIMINATION
DPC = Y
DISTRIBUTION
own PC
?
N
ROUTING
layer 2
ÁÁÁÁÁÁÁÁÁÁÁ layer 1
OP STP DP
exchange A USER PART exchange B USER PART
ÁÁÁÁÁÁÁÁÁÁÁ ÁÁÁÁÁÁÁÁÁÁÁ
MTP MTP
layer 3 layer 3
DISCRIMINATION DISCRIMINATION
DPC = Y DPC = Y
DISTRIBUTION DISTRIBUTION
own PC own PC
? ?
N N
ROUTING ROUTING
layer 2 layer 2
layer 1 layer 1
6.3.3 Outgoing / incoming N7 call overview
The example below considers only an OP exchange and a DP exchange (figure 293). It is
left up to the reader to extend the example to include an STP, although some information
about STP N7 handling will be given at the end of the chapter.
The exchanges are shown in more detailed in figure 294 (OP) and figure 296 (DP). The Call
Handling software, via the TRC, has selected a speech DTM which uses N7 signalling

1.
(=bottom DTM in the drawings). The selection of such a trunk was based on the
requirements of the calling subscriber (he could have asked for a minimum signalling
dependency), and based on the content of the routing tables, as tey are populated by the
administration.
The OP will send a message to the DP. To do this, an IPTM/HCCM is selected to transmit
the message via a N7 link.
Note: The connection between the two circuits of the IPTM/HCCM is called a Signalling link. The
part of this link between the DTMs (CH16) is called the Data link.
Figure 293 : Outgoing / incoming N7 call

N7
Speech
OP DP

1.
a. Actions in the Origination Point
Figure 294 : Sending a N7 message (OP)
SCALSV
routing
L3
USER PART
(ASIG)
DTM CIC–id
IPP
speech
L1
USER PART
(TSIG) DH
DSN IPTM/HCCM
(L3) L2
L1
UCP
DTM
CH16
L1
SLS=xxx0
The user part decides to send a message. In our example the user part is TUP. It is
situated at the signalling level. The TUP signalling system consists of TUP_ASIG

1.
(situated in the SCALSV) and TUP_TSIG (situated in the trunk module with the speech
trunk).
The TC DH FMM has selected a trunk channel within this module.
TUP_ASIG delivers the message to the block ”TR/ROUT”.

TR stands for ”TRanslate”, which means translating the message from A1000 S12
(Chill modes) into TUP modes.
ROUT stands for ”ROUTing”, because we have to find out which signalling link will be
used. This function can find the signalling link (LCE–id + TN) for every TN (trunk).
Figure 295 : Message sending
USER PART
TN (Speech Trunk)
ROUTING
(L3) TN IDX CIC DPC SSF
key
SLS
0 . . . . 15
IDX .... .....
LCE–id (IPTM/HCCM)
TN (N7 link)
To IPTM/HCCM using LCE–id
L2
FLAGS
FCS
FSN/FIB
BSN/BIB
To N7 CH16 using TN
Note: Please note that the representation in this figure is a simplified representation !! It in no way
reflects the relations that are used to store this information.
Using the TN of the trunk speech channel, the DPC, CIC, SSF are found to include
them in the N7 message (figure 291). Also the own OPC is filled in. Then also the

1.
LCE–id of the HCCM or IPTM which handles the link, is found together with the TN of
the link within the module.
For the LCE–id and TN of the signalling, loadsharing is applied using the 4–bit SLS
field as parameter.
Using the retrieved LCE–id, the N7 message is sent towards the HCCM or IPTM. There
the correct link is selected using the TN.
Layer 2 adds the FSN, FIB, BSN, BIB, FCS and the FLAGS before the message is put
on the signalling link towards the next exchange (L1).
b. Actions in the Destination Point
The message is received via L1 in the HCCM or IPTM of the destination exchange.
L2 checks if the frame is without errors and if the sequence number is correct. If the
frame is accepted, L2 delivers it towards L3 discrimination.
L2 also delivers the real message length. Remember that if the LI = 63, it means that
the real length is > 63. In this case L2 receives the real number of bytes from the
hardware reception logic.
It is up to the discrimination part to find out if this exchange is DP or STP. This is done
by comparing the own OPC with the received DPC code from the message (also the
SSF is used, which indicates whether the type is NAT or INTAL)
In our example the exchange is DP (own OPC=DPC) so the message is delivered
towards distribution.

1.
Figure 296 : Receiving a N7 message (DP)
SCALSV
USER PART
(ASIG)
CIC–id DTM
speech
L1
USER PART
DH (TSIG)
IPP
IPTM/HCCM
distribution
DSN
discrimination
L2 L1
UCP
DTM
CH16
L1
SLS=xxx0
The distribution part uses the OPC, SSF and bits 5...11 of the CIC to define the
LCE–id of the user part DTM.
The speech channel is retrieved from bits 0...4 of the CIC code.
The SI field indicates the correct user part (TUP in our example).

1.
Note: The way that the distribution is described is a simplified way. Further it only applies to a normal
CIC distribution. If random CICs are used, the distribution function is more complex.
Using the retrieved LCE–id the message is sent to the TUP_TSIG of the destination
speech DTM. In the DTM the translation part translates the TUP modes into A1000 S12
modes.
Figure 297 : Message receiving
USER PART
To DTM using LCE–id
DISTRIB.
(L3)
LCE–id (DTM)
SI = TUP TN of trunk (=CIC bits 0...4)
OPC SSF CIC(bit 5...11)
key
DPC=own OPC
ROUTING
DISCRIM. (L3)
(L3) CHECK DPC/SSF
WITH OWN OPC/SSF DPC<>own OPC
L2 FLAGS
FCS
FSN/FIB
BSN/BIB
From N7 CH16
c. Actions in a Signalling Transfer Point

In the above example, there was no STP. However, in the case of an STP the HCCM or
IPTM L3 will access the L3 routing (see also figure 298 ) This routing is different from
the routing in the speech DTM, because in an STP it is not possible to use the TN of
the trunk speech channel to define the outgoing N7 link.
In this case, the DPC and the SSF of the message are used to define the HCCM or
IPTM LCE–id and the TN of the N7 link. Also loadsharing is used based upon the SLS.

1.
The selection mechanism is shown in the figure below.

REMARK: The newly selected HCCM/IPTM can be the same (or different) but it is
obvious that the outgoing N7 link (CH16) is different from the incoming link.
Figure 298 : Routing in STP
ROUTING key
(L3)
DPC SSF IDX
key
SLS
0 . . . . 15
IDX .... .....
LCE–id (IPTM/HCCM)
TN (N7 link)
To IPTM/HCCM using LCE–id DPC<>own OPC

DISTRIB.
(L3)
DISCRIM.
(L3) CHECK DPC/SSF
WITH OWN OPC DPC=own OPC
L2 FLAGS
FCS
FSN/FIB
BSN/BIB
To No7 CH16 From N7 CH16

using TN
6.3.4 Outgoing / incoming N7 call in detail
In the next chapters, the call phases are discussed for the outgoing and the incoming
exchange. The phases were shown in figures 287 and 288. The call is discussed in
sequential order, which means that after transmitting the IAM, the discussion continues in
the destination exchange. With the ACM the call continues in the originating exchange.
Thus, it may be confusing for the reader to know at all times in which exchange the actions
are taking place. To solve this problem, the title of each chapter indicates whether the
actions happen in the originating exchange (O), or in the destination exchange (D).
a. Prefix analysis (O)
All actions from the moment of hook–off until the start of the prefix analysis are of
course exactly the same for a local call and an outgoing call because until the prefix

1.
analysis result is known it is not yet clear whether the call is local or outgoing.
Therefore these actions are not repeated here and we start with the prefix analysis. For
a refresh of the actions we refer to the local call.
After the required number of prefix digits have been received, they are transmitted
towards PATED. The input parameters are the same as in the local call (see figure
262). The results from PATED are different:
– PATED finds that the call is OUTGOING.
– A ROUTECODE is found, which is used later to define the outgoing direction (see
TRC and TRA)
– Start selection point: indicates the number of digits to be received before trunk
selection starts (in our example this is 7, which means that the entire DN is received
before the trunk selection starts).
– Signalling information (second dial tone, ...)
– ... (see local call)
These results are transmitted back to CFCS which informs signalling of the remaining
digits to be received.
The outgoing exchange and the software blocks involved are shown in the figure below.

1.
Figure 299 : Outgoing exchange

ACE
TRC TRA
PATED LSIF ARTA

SCM CFCS TUP_ASIG ASSS_ASIG
DTMF
Rec. IPTM
MTP
DTM
SIG N7 Lk
DSN DTM
DH HW
ASM DTM
Speech
ASM DTM
HW HW
ASSS_TSIG TUP_TSIG
DH DH ROUT
Note: The ACE in the figure in fact represents a number of ACEs, such as the SCALSV, the
SACELSIF and the SACETRA.
Note: It is up to the teacher and/or the reader to use the exchange drawings. This means, try to
know at any moment in which module the actions are taking place and also try to indicate the
connections in all the modules and to clear them when necessary (UCPs, tones, cluster connections,
...).
b. End of dialling (O)
The result – 4 more digits required – is sent to the SCM.
When all the requested digits have been received they are transmitted towards CFCS.
c. Release receiver (O)
The actions to release the receiver are exactly the same as for the local call.

1.
d. Outgoing trunk selection (O)
CFCS sends the necessary information towards the TRM (Trunk Resource
Management). As explained before, it is up to TRM (=TRC + TRA) to define a DTM
with at least one trunk speech channel free.
The following information is sent to TRC:
– ROUTECODE. This routing code was retrieved in PATED and depends upon:
Origin (subscriber or trunk, for trunk the same outgoing signalling type could be
requested);
Destination (routing depends upon the dialled prefix);
TOC (priority calls or operators can be routed via high quality trunks);
Time (e.g: different routing during night time);

Circuit or Packet switched call.
– BC (Bearer Capability). A subscriber can request on a per call basis a certain BC for
his call (e.g: bandwidth and quality of the connection) The request for a certain BC
results in release of the call if the request cannot be fulfilled.
– Signalling type: certain services (e.g: for ISDN) can only be provided via a fully
digital signalling (ISUP).
For our example the three parameters are:
Routecode X
BC = speech, default retrieved from DB for analogue subscriber who cannot

provide this information.
Signalling type = any, because BC=speech and no facilities are used.
The selection mechanism was explained in chapter 3.4.10 and is therefore not
repeated here. The result coming back from the TRM is the following:
– Identity of the outgoing DTM which will be used for the speech.
– DID data for the outgoing trunk (time–out values, signalling information (N7, R2, ...),
hardware parameters, ...).
All this information is received in CFCS.
e. Outgoing trunk seizure (O)
The outgoing trunk seizure can be compared with the terminating seizure in the case of
an analogue local call (see before). The selected module is contacted and a UCP is

1.
established between the selected module and the originating module. Also the
connections in the terminal interface are established.
The scenario is the same as in figure 267. The differences are: destination ASM should
be replaced by DTM and the actions [1] and [2] are access to TRM instead of LSIF.
Also RC and RT are not connected here.
However, for an outgoing call an additional action is required. It is up to the outgoing

exchange to inform the remote exchange about the trunk seizure. This is done by
sending a seizure. In our example we are using N7, so the seizure means sending an
IAM (Initial Address Message). The sending of N7 messages has been explained
before.
The IAM contains more information than the seizure indication:
– Entire Called DN ( ”en–bloc” )

– Calling Party Category (normal call)
– A–party DN (optional)
– ...
IAM
f. Seizure (D)
The IAM message is received in the destination exchange. However, it is only after the
prefix analysis that the software knows if this is the terminating exchange or a transit. In
our example it will be terminating, so the situation is shown in figure 300.
In the chapter on N7 it was explained that the incoming exchange can retrieve the
speech channel from the N7 message (bits 0...4 of the CIC). In the incoming DTM a
cluster path is allocated and connected to the speech trunk channel.
For bothway trunks (N7 always), the TRA FMM is informed that the incoming trunk is
involved in an incoming call and may not be selected for an outgoing call.
CFCS is activated. This FMM has the same functionality as the CFCS for originating
subscriber calls.

1.
Figure 300 : Incoming exchange

ACE
TRC TRA
PATED LSIF
IPTM CFCS TUP_ASIG ASSS_ASIG

MTP
DTM
N7 Lk DSN
DTM
HW
DTM ASM
Speech DTM ASM

HW HW
TUP_TSIG ASSS_TSIG
DH ROUT DH
Note: The ACE in the figure in fact represents a number of ACEs, such as the SCALSV, the
SACELSIF and the SACETRA.
g. Prefix analysis (D)
The prefix digits are sent to PATED. In this case all digits are sent to PATED, because
they were all received ’en–bloc’.
The input parameters for PATED are:
– Digits received in IAM.
– TOC (Calling Party Category: Normal Call received in IAM)
– NPI and NATADDR: E164 and National, received from IAM or filled in by CFCS.
– Sourcecode: Type = trunk and trunk group number retrieved from DB.
– TOD
The result coming from PATED indicates a local call. The parameters provided in this
case were already discussed in the Local Call chapter and are not repeated here.

1.
h. Subscriber identification (D)
LSIF is accessed to define the terminating subscriber. The input and the results are the
same as for a local call.
i. Terminating seizure (D)
Here the terminating subscriber module is informed about the call. If the subscriber is
free, all connections are established and the ringing phase is started.
CFCS sends a request to TRM to retrieve the incoming DID.
The scenario starting with the subscriber identification and ending with a positive
acknowledgement towards CFCS is the same as for the local call in figure 267,
replacing CFCS by CFCS and the incoming ASM by the DTM.
Now it is also possible to inform the originating exchange about the successful call
setup. This is done by sending the ACM to the originating exchange.
There exist ACM messages with different meanings. The ACM which is sent in our
example is of the AFC type. In this case the ACM contains the following information:
– Address complete (no more digits required).
– The B–party is Free.
– Charging has to be applied.
At this moment RC is sent to the B–party and RT is sent from the called ASM to the
A–party via the connections. We are now in the ringing phase.
ACM
j. Pass to stable (D)
CFCS passes all the stable data to ASSS_ASIG and TUP_ASIG and terminates.
k. Pass to stable (O)
The ACM message is received in TUP_ASIG in the originating exchange.
CFCS is informed and activates the charging.
Then CFCS passes all the stable data to ASSS_ASIG and TUP_ASIG.
At this moment both exchanges are waiting for answer of the B–party.
l. Answer (D)
As soon as the B–party lifts the handset, the RC and RT are removed and the through
connection is established. It is up to the destination exchange to inform the originating
exchange of this event to start the taxation.

1.
To do so, ASSS_ASIG sends the answer signal to TUP_ASIG which transmits the N7
ANC (ANSWER) message.
The message content indicates:
– ANswer
– with Charge.
ANC
m. Answer (O)
The N7 answer message is received in TUP.SIG which forwards the event to

ASSS_TSIG. The latter will actually start the taxation. Both subscribers are now in
conversation.
CONVERSATION
n. Forward release (O)
When the A–party finishes the call, it is called a Clear Forward and this means that the
call will be released.
ASSS_ASIG stops the taxation for this call.
Via the DHs all the connections are released and the DTM will send the Clear Forward
event to the destination exchange. This is done via the message CLF.
CLF
o. Forward release (D)
The CLF is received in the destination exchange, where actions are taken to release all
the connections and make the trunk free again.
The fact that the trunk has become free, is sent towards TRA.
The clear forward message is acknowledged with another N7 message, called RLG
(Release Guard).
RLG

1.
p. Clear (O)
Upon receipt of the RLG the trunk is indicated free again, and TRA is informed.
REMARK:
For ISUP some of the messages have different abbreviations but the main principles
remain the same (in some messages also different (more) parameters are used):
– ANC becomes ANM (Answer Message)
– CLF and CBK become REL (Release)
– RLG becomes RLC (Release Complete)
6.4 Transit N7 call

Figure 301 shows the situation for a transit call using N7 signalling.
Figure 301 : Transit Call
Transit Exchange
ACE
N7 N7
IPTM IPTM
3
2
speech speech
IPTM DSN IPTM
Figure 302 gives the different call phases. The actions are all similar to or the same as those
explained in the previous chapters (see local and outgoing/incoming call).
Because there is nothing new to explain, it is up to the trainee to make the transit scenario.
Note that a transit exchange is transparent for the signalling when the incoming and
outgoing connections have been established.
REMARK:
A transit exchange should never be confused with a signalling transfer point (STP). A transit
exchange is for speech and an STP is for signalling.

1.
Figure 302 : Transit Exchange
TRUNK
IAM
SEIZURE
PREFIX ANALYSIS
LOCAL OUTGOING

ACM IAM
ACM ACM

ANC ANC ANC
ANSWER ANSWER
CONVERSATION
CLF CLF CLF

RLG RLG
RLG
CLEAR
6.5 Outgoing / incoming call with CAS/R2 signalling
6.5.1 CAS line signalling
CAS stands for Channel Associated Signalling. In this chapter a brief explanation is given of
the CAS handling in A1000 S12. However for more details we refer to the corresponding
Signalling courses.
CAS is used to transmit and receive line events, in other words line signalling. The
changes in line states are transmitted in CH16 of a digital PCM connection. For every
speech trunk a nibble is reserved so a change in line state results in the change of the bit
pattern (nibble).
To know which nibble belongs to which speech channel, a multiframe structure is used. In

1.
this way it is possible to send for every speech channel (one speech channel is used for one
call) the line events in the nibble of the dedicated CH16.
Figure 303 shows a PCM channel structure with the CH0 frame alignment pattern. Also
notice the CRC4 + E–bit which was introduced in the CCITT Blue Books. However the
CRC4 multiframe structure (not shown here) may not be confused with the CAS multiframe
structure.
The CAS multiframe structure is shown in figure 304. The ”first” CH16 contains the
multiframe alignment pattern and the remaining fifteen CH16s each contain the CAS bits for
two speech channels.
Figure 303 : PCM frame alignment.
MULTIFRAME (2ms)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
FRAME (125 µs)

0 1 2 3 4 5 6 7 8 9 10 21 22 23 24 25 26 27 28 29 30 31
Channel TS (3.9 µs)

C 0 0 1 1 0 1 1 (EVEN frames)
Frame alignment pattern
CRC4 + synchronisation
National use + E–bit
C 1
ÍÍÍÍÍÍÍÍ
Y N N N N N (ODD frames)
Remote Junction Alarm (RJA)

1.
Figure 304 : CAS multiframe structure

MULTIFRAME (2ms)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Multiframe
Alignment
Pattern CH16
0 0 0 0 1 Y 1 1
Multiframe align.
alarm
CH16
a b c d a b c d
for CH1 for CH17

CH16
a b c d a b c d
for CH2 for CH18
.
.
.
. a,b,c,d = CAS information
CH16
a b c d a b c d
for CH15 for CH31
- Working principle
The CAS line signalling is sent and received by the trunk hardware. Figure 305 shows
the principle.
[a]
The processor in the DTM wants to send a CAS line event to a remote exchange. The
new bit values (abcd) are transmitted towards the processor of the trunk hardware.
REMARK: This does not apply to the DTUA, because it uses only one processor.
[b]
The processor copies the abcd bit values into the CAS memory. The lay–out of this

1.
memory is easy to understand. It contains 16 adjacent memory locations (words), each

location being the CH16 content for transmission in the multiframe (=16 frames).
[c]
If the hardware is initialised for CAS, it will fetch the correct word (=CH16 content) into
the correct frame.
This is repeated for as long as CAS is applicable.
REMARK: If the DTM is not initialised for CAS, it will not execute the above mentioned
procedure. In this case CH16 can be used for speech or CCS (Common Channel
Signalling).
As long as the CAS bits are not changed by the software, the hardware keeps sending
the same bit values in CH16 of each multiframe.
[d]
This is the reception of a CAS line signalling event. Every CH16 is written in a receive
buffer(in memory) on 16 consecutive locations (one specific CH16 in the multiframe

structure will overwrite the same location, multiframe after multiframe).
If the received bits have changed, the hardware takes no action.
[e]
It is up to the processor to check the received CAS bits with the previous value
(therefore the processor checks and copies the CAS buffer on a regular basis).
[f]
If a mismatch is encountered, the processor sends the CAS line event towards the CE
processor.
Figure 306 shows the relevant software blocks in the DTM control element. The CAS
events are transmitted to and received from the hardware by means of the Device
Handler (DTM.DH). The events were triggered by or reported to the Signalling level,
which is responsible for the line signalling (=R2.SIG).

1.
Figure 305 : CAS handling

DTM
CH16
c
CAS
CH16 d MEM
DSN
b,e f
a
SIG
PROC
DH
PROC
Figure 306 : CAS software

DTM.CE =R2.SIG
SIG
=DTM.DH
CAS Line
Events DH
To/From DTM
HW trunk processor
6.5.2 R2 register signalling
The MF–R2 register signalling system sends MF codes during the register phase. To
transmit the digits to a remote exchange, a combination of 2 frequencies out of 6 is used.
This frequency combination is sent in the speech channel from a sender towards the
receiver in the next exchange and vice versa.
There are 2 groups of 6 frequencies. One group is used for the Forward direction, the other
for the Backward direction (see figure 307).

1.
Figure 307 : R2 signalling

f1...f6
2 freq. out of 6
Forward MF/R2
Backward MF/R2
Outgoing Incoming
Exchange Exchange
2 freq. out of 6
f’1...f’6
Forward: signals sent from the outgoing to the incoming exchange.
Backward: signals sent from the incoming to the outgoing exchange.
Two frequencies out of six makes a total of 15 combinations. This is multiplied by two
because of the two groups (see figure 308).

1.
Figure 308 : R2 registers signals

FORWARD
SIGNAL GROUP I (In response to A1) GROUP II (In response to A3/A5)
MEANING MEANING
1 DIGIT 1 NORMAL SUBSCRIBER

2 DIGIT 2 PRIORITY CALL
3 DIGIT 3 MAINTENANCE EQUIPMENT CALL NAT.
4 DIGIT 4 SPARE USE
5 DIGIT 5 OPERATOR CALL
6 DIGIT 6 DATA TRANSMISSION CALL
7 DIGIT 7 SUBSCRIBER CALL
8 DIGIT 8 SPARE
9 DIGIT 9 SPARE
10 DIGIT 10 OPERATOR CALL
11 ACCESS TO OPERATOR SPARE
12 ACCESS TO DELAY OPERATOR SPARE
13 ACCESS TO MAINTENANCE INTERNAT. USE
EQUIPMENT SPARE
14 INSERT HALF ECHO SUPPRESSOR
(Only for very long lines) SPARE
15 END OF PULSING SPARE
BACKWARD
SIGNAL GROUP A GROUP B
MEANING MEANING
1 SEND NEXT DIGIT (n+1) SPARE

2 SEND LAST BUT 1 DIGIT (n–1) TRANSFERRED SUBSCRIBER
3 CHANGE OVER TO B SERIES SUBSCRIBER BUSY
4 CONGESTION CONGESTION
5 SEND NATURE OF ORIGINATOR UNALLOCATED SUBSCRIBER/
SWITCHING STAGE NOT WIRED
6 SET–UP SPEECH CONDITIONS SUBSCRIBER FREE WITH CALL
CHARGING
7 SEND DIGIT (n–2) SUBSCRIBER FREE WITHOUT
CALL CHARGING
8 SEND DIGIT (n–3) SUBSCRIBER LINE OUT OF ORDER
9 SPARE SPARE
10 SPARE SPARE
11 SEND INTERNATIONAL TRANSIT NAT.
INDICATION SPARE USE
12 SEND LANGUAGE OR
DISCRIMINATING DIGIT SPARE
13 SEND CODE OF INTERNATIONAL
TRANSIT EXCHANGE SPARE INTERNAT. USE
14 SPARE (ECHO SUPPRESSOR) SPARE
15 CONGESTION SPARE
The MF–R2 signalling system is compelled. Compelled means that every action
(appearance and disappearance of the MF frequency code) is acknowledged by the remote
exchange in the following way:

1.
– Exchange A starts sending the MF code (Forward)

– Exchange B detects this MF code.
– Exchange B starts sending the MF code (Backward)
– Exchange A detects this MF code.
– Exchange A stops sending the MF code (Forward)
– Exchange B detects the MF code disappearance.
– Exchange B stops sending the MF code (Backward)
– Exchange A detects the MF code disappearance.
- Implementation in A1000 S12
The MF–R2 senders / receivers are implemented in the A1000 S12 SCM. The hardware part
of the SCM generates 15 forward and 15 backward register signals. Each signal is sent in a
fixed channel and enters the terminal interface receive port. From there the channels are in
a PUT TO RAM status to 30 consecutive PRAM locations (all this is done at initialisation of
the SCM). If a register signal has to be transmitted, a connection is made between the
corresponding PRAM location and the transmit channel of the UCP (the UCP is further
connected to the outgoing speech channel in the DTM)
If the MF code is disconnected, then the connection (FETCH) is moved from an MF code
PRAM location towards a location which contains the quiet pattern, otherwise rubbish is sent
to the remote receiver.
All this is illustrated in figures 309 and 310. The latter shows also the connection of the
receiver. This principle was already explained for the local call, because it is the same for a
MF receiver and a DTMF receiver, although in both cases the hardware will use different
filters.

1.
Figure 309 : Outgoing / Incoming exchange for R2
MF MF
Rx/Tx. Rx/Tx.
SIG SCM SCM SIG
DH DH
D D
S S
N ACEs ACEs N
Speech
DTM DTM
HW MF HW
MF
SIG SIG
DTM DTM
DH DH
outgoing exchange incoming exchange

1.
Figure 310 : R2 sender receiver
R2
FORWARD
MF SIGNALS
SENDER
RECEIVER
R2
BACKWARD
SIGNALS
Quiet pattern
SIG
DH

1.
Figure 311 : Register signalling
RSIG RSIG
a d e h b c f g
SC DH SC DH
a e a
Forward
c g
Backward
Figure 311 describes the MF sending mechanism in A1000 S12. The software involved
is the DH and SIG of the SCM.
[a]
The RSIG calls the DH to make a connection between the transmit channel of the UCP
and the PRAM location corresponding to the forward register signal. The register signal
is then transmitted to the destination receiver.
[b]
In the destination exchange the signal is detected by the DH and reported to the RSIG
(e.g: the first digit).
[c]
RSIG stores the digit and calls the DH to start sending the backward signal: ’Send Next
Digit’.
[d]
The backward signal is detected and reported to RSIG.
[e]
Now the RSIG calls the DH to disconnect the MF code (FETCH quiet pattern).

1.
[f]
The disappearance of the forward signal is detected in the next exchange and reported
to RSIG.
[g]
The backward signal is also disconnected.
[h]
The disappearance of the backward signal is detected, so RSIG can order the next
forward signal to be transmitted (start again at (a) ).
6.5.3 Outgoing / incoming R2 call overview
Figures 312 and 313 give an overview of the call phases for an outgoing / incoming call
using R2 signalling. If you compare these drawings with these of the N7 call, you will notice
the similarity between them. They differ only with respect to the limitation of the R2 signalling
compared to the N7 signalling. The additional new blocks are indicated in the following
ÍÍÍ
pattern:
ÍÍÍ
In the following paragraphs, only some remarks and differences are given for some of the
call phases, because all the other necessary information to understand the call was already
given in the case study.

1.
Figure 312 : Outgoing / Incoming Call using R2 (A)
SUBSCRIBER
SEIZURE
PREPARE & SEND

DIAL TONE
DETECTION OF
PREFIX DIGITS
PREFIX ANALYSIS
OUTGOING
END OF DIALLING
RELEASE RECEIVER
TRUNK
OUTGOING TK SELECTION
SEIZURE
OUTGOING TK SEIZURE SEIZURE
ÍÍÍÍÍÍÍÍÍÍ ÍÍÍÍÍÍÍ
SEIZ. ACK
D1
NEXT
REGISTER PHASE REGISTER PHASE
D2
NEXT
ÍÍÍÍÍÍÍÍÍÍ
D3
NEXT PREFIX ANALYSIS
LOCAL
D4
REGISTER PHASE NEXT
D5
ÍÍÍÍÍÍÍÍÍÍ NEXT. ÍÍÍÍÍÍÍ
REGISTER PHASE
ÍÍÍÍÍÍÍÍÍÍ . ÍÍÍÍÍÍÍ
ÍÍÍÍÍÍÍÍÍÍ .
ÍÍÍÍÍÍÍ
ÍÍÍÍÍÍÍÍÍÍ D7
ÍÍÍÍÍÍÍ

1.
Figure 313 : Outgoing / Incoming Call using R2 (B)
SUBSC. IDENTIFICATION
TERMINATING SEIZURE
ÍÍÍÍÍÍÍÍÍÍ ÍÍÍÍÍÍÍÍÍÍÍ
CHANGE TO B
NORMAL SUB.
RELEASE
RELEASE
SUB.FREE
ANSWER
ANSWER ANSWER
CONVERSATION
CLF
RLG
CLEAR
6.5.4 Outgoing / incoming R2 call in detail
Note: The title of each chapter indicates whether the actions happen in the originating exchange (O),
or in the destination exchange (D).
Note: The line signalling (CAS) events are printed in dotted lines and the register signalling (MF–R2)
is printed in normal lines.
a. Prefix analysis (O)
PATED finds out that the call is outgoing and also retrieves the requested number of
digits before the trunk selection. It is possible that after the outgoing trunk selection
more digits are needed from the incoming side to obtain the complete number.
However, the digits collected thus far can be sent out.
b. End of dialling + Release receiver (O)
c. Outgoing trunk selection (O)
CFCS receives the identity of a DTM which uses R2 signalling.

1.
d. Outgoing trunk seizure (O)
Because the selected DTM uses R2 signalling, the DTM will access ARTA (cf. local
call) for the selection of an MF sender receiver. In the Tx direction a quiet pattern is
connected. In the DTM a duplex connection is established.
Then the outgoing seizure (CAS) is transmitted from the R2.SIG.
Seizure
e. Seizure (D)
The incoming DTM knows the identity of the incoming speech channel. For N7 the
identity is indicated in the CIC and for CAS indicated by the ’CH16 number’ within the
multiframe).
The specified trunk channel is indicated busy and the seizure is acknowledged.
Seizure acknowledge
Also in the destination exchange an MF sender / receiver is selected and connected to

the speech trunk. The sender also transmits quiet pattern and the receiver is waiting for
the first digit.
f. Register phase (O)
This part is different compared to the N7 call. This is because N7 transmits the seizure
and the digits in one message. Here we still have to transmit the dialled digits. The
principle of MF sending receiving was explained in chapter 6.5.2.
The receiver is connected to receive the backward signals.
The digits were transmitted to the RSIG from where they are transmitted one by one.
Digit 1
g. Register phase (D)
Upon receipt the RSIG sends the MF signal: ’SEND NEXT DIGIT’ until the requested
number of prefix digits have been received.
Next
Digit 2
Next
Digit 3

1.
h. Prefix Analysis (D)
The result is local call
Next
Digit 4
Next
.
.
.
Digit 7
i. Subscriber identification (D)

j. Terminating seizure (D)
The called ASM is contacted to check if the B–party is free and to connect the ASM
(UCP + cluster path)
k. Release receiver (D)
CFCS can always request additional information. For example:
– A–party number for malicious call (A9)
– Calling Party Category (A5)
– ...
Also the address complete message must be transmitted as does the signal indicating
that the B–party is free. However this is a signal of the second group (II) of MF signals.
This is done by first sending the signal ’CHANGE TO B SERIES (A3)’. Now the
originating exchange must answer with a forward signal. Usually this will be the Calling
Party Category signal. The register phase is closed by the backward signal
’SUBSCRIBER FREE WITH CHARGING’.
Change to B
Normal Sub.
Sub. Free
When the receiver is released actions are taken to connect the DTM trunk to the
subscriber UCP and in the ASM RT and RC is activated.

1.
According to the DID information, the full joining can be delayed until answer or
address complete.
l. Release receiver (O)
Also in this exchange the subscriber is connected to the trunk channel.
m. Pass to stable phase (O)
n. Pass to stable phase (D)
o. Answer (D)
Disconnect RT and RC and send ANSWER to the originating exchange to start

taxation.
Answer
p. Answer (O)
Start taxation.
CONVERSATION
q. Forward release (O)
The actions are the same as for the No7 call. Also Clear Forward (CLF) and Release
Guard (RLG) are transmitted. However, these messages are CAS line signalling and
therefore transmitted in the CH16 multiframe.
CLF
r. Forward release (D)
RLG
s. Clear (O) (D)
All connections are cleared and the trunk is free again.
ASSIGNMENT:
Try to map all the CAS/R2 signals onto the No7 messages (IAM = ?, ...).

1.

1.
7. FACILITY HANDLING
7.1 Overview of some of the supplementary services
Supplementary services exist in a wide variety. The list below gives an overview of the most
important supplementary services. Some of the services are only available for analogue
subscribers while others are only available for ISDN subscribers and some are available for
both. It is beyond the scope of this document to give a detailed explanation of these services
and their availability.
In the next chapters some of the services are used to explain the implementation in A1000
S12.
- Abbreviated Address (AA)

Allows a user to make a call by sending a short code instead of the complete number.
- Add–On Conference (CONF)
Provides a user with the ability to set up a multi–connection call, i.e. a simultaneous
communication between more than two parties.
- Advice of Charge (AOC)
The possibility for a user to receive information about the charging rates at call setup
time and possible change of charging rates during the call.
- Alarm Call (AC)
This supplementary service allows the served user to order alarm calls to be made to
his line at times specified in advance by the user.
- Call Deflection (CD)
Allows the called user to respond to an incoming call offered by the network by
requesting redirection of that call to another address specified in the response. This is
possible before or after the alerting starts.
- Call Forwarding Busy (CFB)
Permits a served user to have the network send all incoming calls, or just those
associated with a specified basic service, which meet busy and are addressed to the
served user’s ISDN number, to another number. The served user’s originating service
is unaffected.
The busy condition can be detected by the network or indicated by the subscriber. This
classification is called:

1.
– NDUB = Network Defined User Busy
– UDUB = User Defined User Busy
- Call Forwarding to Fixed Announcements (CFFA)
Permits a served user to have the network send all incoming calls carrying speech
information addressed to the served user’s ISDN number to a fixed announcement.
The served user’s originating service is unaffected. If this service is activated, calls
carrying speech information are forwarded no matter what the condition of the
termination is.
- Call Forwarding No Reply (CFNR)
Permits a served user to have the network send all incoming calls or just those
associated with a specified basic service, which meet No Reply and are addressed to
the served user’s ISDN number, to another number. The served user’s originating
service is unaffected.
- Call Forwarding Unconditional (CFU)
Permits a served user to have the network send all incoming calls or just those
associated with a specified basic service, addressed to the served user’s ISDN
number, to another number. The served user’s originating service is unaffected. If Call
Forwarding Unconditional is activated, calls are forwarded no matter what the state of
the termination is. It can be fixed (operator command) or variable (programmed by the
subscriber).
- Call Hold (HOLD)
Allows a user to interrupt communications on an existing call and then subsequently, if

desired:
– re–establish communications
– make an additional call to another user, switch from one call to another as required
(privacy being provided between the two calls), and/or release one call and return to
the other.
- Call Pick–up (CPU)
Enables the served user to pick up a call alerting at another terminal within a
predefined group, eg. Centrex. The user may subscribe to Group Call Pick–up or both.
- Call Transfer (CT)
Enables a user to transfer an established (i.e. active) call to another user. The served
user must be the called user of at least one of the calls. (i.e. at least one of the calls
must be incoming). For users within a BC network, this service differs from the Call

1.
Diversion supplementary services in that the Call Diversion services deal only with
incoming calls that have not yet reached the “fully established” state, whereas in the
case of Call Transfer an established end–to–end connection exists.
- Call Waiting (CW)
Permits a subscriber to be notified of an incoming call with an indication that no

interface information channel is available. The user then has the choice of accepting,
rejecting or ignoring the waiting call.
- Calling Line Identification Presentation (CLIP)
Makes it possible for the called party to receive identification of the calling party.
- Calling Line Identification Restriction (CLIR)
Enables the calling party to restrict presentation of its number to the called party.
- Closed User Group (CUG)

Enables users to form groups, to and from which access is restricted. A specific user
may be a member of one or more CUGs. Members of a specific CUG can
communicate among themselves but not with users outside the group. Specific CUG
members can have additional capabilities that allow them to originate calls outside the
group, and/or to receive calls from outside the group.
- Coinbox (CB)
Allows charging information related to outgoing calls to be transmitted to a terminal

(coin box) for the purpose of immediate charging fee payment.
- Completion of Calls to Busy Subscriber (CCBS)
Enables a calling user A, encountering a busy destination B, to have the call completed
when the busy destination B becomes not busy, without having to make a new call
attempt.
- Completion of Calls on No Reply (CCNR)
Enables a calling user A, encountering a busy destination B, to be notified when the

destination B becomes not busy after having terminated an active call and to have the
service provider reinitiate the call to the specified destination B.
- Connected Line Identification Presentation (COLP)
Provides the ability to indicate the ISDN number of the connected line with possible
additional address information to the calling party when the call is established.
- Connected Line Identification Restriction (COLR)
Offered to the connected party to restrict presentation of the connected party’s

ISDN–number and subaddress information (if any), to the calling party.

1.
- Credit Card Calling (CRED) – Credit Calling – IN service
Allows the automatic charging of a call to a particular account not associated with the
subscriber line on which the call originates. The use of an Account Number (AN), in
combination with a confidential code, permits the Served User to charge calls to an
account, which may either be associated with a particular connection to the network
(ISDN number) or independent of any physical network termination.
- Credit Card Validation (CCV) – IN service
Validates Credit Cards issued by Credit Card companies and Bank Cards issued by
Banks. The validation must be based on an agreement between the Administration and
Credit Card companies and Banks.
- Direct Dialling In (DDI)
Enables a user to call directly another user on an ISPBX or other private system
without attendant intervention.
- Emergency Call Service (EMERG)
Enables the termination of emergency calls in predetermined installations all over the
country. Any customer who calls an emergency number will be connected to a
predetermined installation. Different numbers will be allocated for different purposes,
e.g. police, fire department or medical personnel.
- Fixed Destination Call (FDC)
Allows a user to make a call to a number, nominated by the user, without sending
address information to the network.
- General Deactivation (GD)
Allows the user to deactivate certain supplementary services which he has subscribed
to.
- Green Numbers (GN) – IN service
Allows the Served User having one or several installations to be reached from all parts
of the country with a Green Number and to be charged for these calls.
- Group Call Pick–up (G–CPU)
Invoking this service allows, the served user to pick–up any call alerting at one of the
terminals in the group.
- Home Meter (HM)
Call charge units being added to the served user’s meter in the network are also
registered on a call charge meter at the subscriber’s premises.

1.
- Incoming Call Barring (ICB)
Makes it possible for a subscriber to prevent all incoming calls to his access/line or just
those associated with a specific basic service. The ability of the served user to originate
calls remains unaffected.
- Individual Call Pick–up (I–CPU)
To pick up a call using I–CPU, the served user must specify the ISDN number (E.164 or
PNP number) of the terminal at which the call is alerting.
- Interception of Calls (INTCP)
When call attempts or supplementary service manipulations for some reason do not
give the expected response, the calling or served user is given information on the
reason for the unsuccessful outcome.
- Line Hunting (LH)

Enables the automatic selection of a free information channel on an access from a

group of accesses servicing a subscriber, on receipt of a call to that subscriber’s Line
Hunting number (LH–number) or Universal Access Number (UAN).
- Malicious Call Identification (MCI)
Enables a user to request that the source of an incoming call be identified and
registered in the network.
- Meet–Me Conference (MMC)
Provides a user with the ability to arrange for a call between more than two participants
with all participants accessing conference bridge.
- Multiple Subscriber Number (MSN)
Allows multiple ISDN numbers to be assigned to a single interface. Each number can
be given a different data profile.
- Outgoing Call Barring (OCB)
Makes it possible for a subscriber to prevent all outgoing calls or just those associated
with a specific basic service, which are intended to be originated from his access. The
ability of the served user to receive calls remains unaffected. The ability of the served
user to set up emergency calls also remains unaffected.
- Priority (PRI)
Provision is made to give preferential treatment to calls originating from and/or

addressed to certain numbers for call establishment.
- Private Numbering Plan (PNP)

1.
Allows a Private Telecommunication Network (PTN) Operator to define a Private

Numbering Plan (PNP) with a different structure than the public numbering plan; to
identify extensions in the PTN, the Operator may give each extension in the PTN an
individual private number. Calls between different extensions in the PTN can be
established over the public ISDN by using PNP.
- Queue Service (QS)
Enables the called party to have incoming calls placed in a queue when the called
party’s capability is in a busy state.
- Reverse Charging (REV)
A service allowing the served (called) user to be charged for some or all calls. Only
usage–based charging may be charged to the called party.
- Subaddressing (SUB)
Allows the called (served) user to expand his addressing capacity beyond the one
given by the ISDN number.
- Televoting (TVOT) – IN service
A supplementary service that makes it possible for the subscriber to record the number
of calls to one or more specific TVOT–numbers. It is possible to forward some or all
calls to a voice response system or an operator.
- Terminal Portability (TP)
Allows an ISDN user to move a terminal from one socket to another or to move a call
from one terminal to another within one basic access, during the active state of a call.
- Three Party Service (3 PTY)
Enables a user to establish a Three–Party Conversation i.e. a simultaneous

communication between the served user and two other parties.
- Universal Access Number (UAN) – IN service
A served user with several installations in different parts of the country can be reached
from anywhere in the country by a calling user dialling one given number. Calls from
subscribers in a predetermined area will be routed to installations chosen (with certain
restrictions) for that area by the Served User.
- User to User Signalling (UUS)
Allows an ISDN user to send/receive information to/from another ISDN user over the
signalling channel in association with a call to the other ISDN user.

1.
7.2 Facility handling model.
7.2.1 General structure
Supplementary services exist in a wide variety. From an implementation point of view it is

appropriate and even necessary to split the set of supplementary services into a number of
groups:
- Services which can be handled within the context of the call, during the call setup phase
and requiring no complex additional logic.
The required logic for this type of services will be handled by the existing common call
handling software.
- Services which can be handled within the context of the call, but outside the call setup
phase or requiring complex additional logic.
Since the actions required by the service have to be executed outside the call setup
phase, or because they require too complex scenarios to be implemented in the
existing common call handling software, either additional functionalities are needed
within the call handling software, or the service has to be handled by the signalling
modules (when those services are closely related to the protocol).
- Services which include multiple parties (three or more)
These services will be handled by some dedicated functionalities of the existing call
handling software.
- User profile manipulation
The manipulation of the user profile by the user himself (user control) can be defined
either as an inidividual supplementary service or as an option of another supplementary
service.
Since user profile update is a very specific call type which does not fit in with the two
party call concept, again the treatment has to be done by some dedicated
functionalities of the call handling software.
The handling of supplementary services can be handled on two locations in A1000–S12:
a. Signalling
Some supplementary services are treated by SIG. When a user invokes such a service,
it has to be checked whether the user has subscribed to the service. The class marks
belong to the subscriber’s profile data.
E.g: Call Hold, Call Waiting, ...

1.
b. Call Control
In chapter 3.4.6 you learned that CFCS is a multiprocess FMM. When we talk about
supplementary services it is interesting to know a little bit more about the CFCS
environment.
In CFCS more and more functions have to be performed which are project specific. The
most important features of this kind are abbreviated dialling, call diversion, keypad
facilities, signalling requirements and allowance checks.
7.2.2 Call and Facility Control System (CFCS) architecture
CFCS can execute:
– All classes that can be executed by CFCS.

– Call Deflection (CD), after Alert.
– CFNR
– ...
CFCS FMM is implemented as a multiprocess FMM with a number of linked procedures

(CDE). Whenever the supervisory process of the CFCS FMM receives an activation
message, an application process is created.
The CDE nature of supplementary services implies that the CFCS has to be a Shell Based
System (SBS) (see chapter 3.2.1.e.).
The linked procedures are also called ”SW entities”. Each entity has its specified task to
perform. This task is only a part of the complete scenario. It is not the intention to have an
entity that handles a specific supplementary service.
Not all the entities are linked to the FMM. Some of them can be accommodated in one or
more CDE SSM(s).
Functions of some of the entities :
- When a service is requested, one of the entities will decide at any moment what to do
next. It will link all the necessary entities (by calling them one by one) together to
complete the service.
- To determine which services can be invoked by a served and how this can be done.
- Execute the call completion of a 2 party call setup as part of a supplementary service.
This function depends on the required service and is therefore CDE.
- CDE charging

1.
- To handle the CDE part of the stable data.
- A lock function to prevent concurrent data changes
- To allocate a conference bridge by sending a request to ARTA.
- ...
The functions of some of the common entities are:
- To retrieve data of a user.
- Interface towards signalling to request digits,...
- Interface towards PATED.
- Terminating seizure: to treat terminating line or trunk seizure, to set up a path.
- Common charging interface

- To handle the common part of the stable call data
- To handle the release of all resources in a basic call
- To handle the connection of a tone or announcement
- Interface towards the Dynamic Data Manager (DDM, see later)
- ...
The above list of functions makes it clear that the common entities can also be used for
other purposes than call setup.
E.g: Interface towards PATED to analyse the stimuli for the invocation of a service.
The condition is that they are all common.
7.3 Supplementary service data structures.
Remember from chapter ’3.4.9 Subscriber analysis’ that most of the subscriber data is
stored at LSIF level. This subscriber data can be subdivided into semi permanent data and
dynamic data. The following chapters expand on these two types of data.
7.3.1 Semi permanent data
The semi permanent data, also called Low Penetration Data, is the part of the subscriber
profile that has a long life–span. It gives a description of all services, applicable to this
subscriber. For each service a subscriber is allowed to use, we find here all necessary
parameters in order to handle the service.

1.
For example: if a subscriber has a call forwarding facility, then the semi permanent data
indicates what kind of call forwarding it is and possibly to which DN a call is forwarded.
a. Location of the semi permanent data
Figure 314 : Location of the semi permanent data
SCALSV
LSIF DDM
DNET SACELSIF
PATED
PABX_id
TCE
PABX_id
ISSS CFCS PARM DDM
SACEPBX
ASSS ASSS PABX_id

BCG_id
TSIG ASIG
PNP_XL DDM
SACEBCG
Figure 314 gives an overview of the semi permanent data of normal subscribers,
PABX lines and BCG users.
– semi permanent data of normal subscribers
The semi permanent data of normal subscribers is stored in the SACELSIF. This ACE
works in an active / stand–by configuration. Since the semi permanent data is fairly
important, both ACEs, active and stand–by, contain that data. The semi permanent
data is therefore replicated over the two ACEs.
Since in an exchange you can have a number of SACELSIF pairs, it is important to find
the correct one. Correct means, the SACELSIF that handles the data of the subscriber
that is analysed. The choice of SACELSIF is made with the DNET of the subscriber.
This applies to both originating and terminating subcribers. As in any active / stand–by
configuration, the active ACE will normally be accessed.
The subscriber data is retrieved by the Local Subscriber Identification (LSIF) FMM.
– semi permanent data of PABX lines
If the DN that is analysed belongs to a PABX, then at some point the PABX identity is
retrieved. This can happen in the TCE, where the PABX identity may be indicated in the
OLCOS data, or in LSIF.
The PABX data is stored in a specific ACE: the SACEPBX. Also this ACE works in
active / stand–by pairs. And again, depending on the number of PABXs, you can have

1.
a number of theses pairs in an exchange. So to retrieve the data of a particular PABX,

you have to access the correct SACEPBX pair. The pair is chosen with the PABX
identity. All the data that describes a PABX is stored in the same ACE pair.
The PABX data is retrieved by the PABX Resource Manager (PARM).
– semi permanent data of BCG users
The semi permanent data of BCG users is stored in the SACEBCG. The ACE
configuration is similar to the previous cases. The correct SACEBCG pair is determined
by the BCG identity.
7.3.2 Dynamic data
a. Definition
Dynamic data is defined as data which only lasts during a call or the time it takes to
execute a facility. This can be from a few seconds to a few minutes.
Here is an example. Remember from the previous chapter that if a subscriber has a call
forwarding facility, then the semi permanent data indicates the type of call forwarding
and possibly the DN that the call is forwarded to. If a call is made to this subscriber,
then the call is clearly forwarded, but temporarily (this means during this call), a counter
is kept to count the number of calls that are forwarded simultaneously. This data is the
dynamic data.
Dynamic data is created by the service handling software and has to be stored for the
time it takes to execute the service. The data is stored in memory only relations.
The dynamic data is also stored in the SACELSIF, just like the semi permanent data.
However the approach for the static (replication over the two SACELSIFs of a pair) can
not be used for the dynamic data. If the dynamic data were replicated over the two
ACEs of one pair as well, this would cause a big overhead (the number of updates on
dynamic relations is rather high).
The dynamic data is only stored in the active ACE of a SACELSIF pair ! The
SACELSIF pair that is mentioned here is the same pair that also holds the semi
permanent data of that subscriber. The correct ACE is again determined by the DNET
of the subsciber.
To store and access the data, a separate FMM is designed. This FMM is called the
Dynamic Data Manager (DDM). This FMM is a multiprocess FMM. However it is not a
normal multiprocess because the tasks are executed by the supervisory process. The
applications are created to perform time supervision on the services (audit function).
b. Dynamic data users
– Normal users

1.
For normal users the dynamic data is stored in the SACELSIF as explained in the
previous chapters, and it is handled by the normal DDM.
The data is fully distributed which means that the data is available as long as the CE is
on line. The data survives a restart but is cleared after a reload. If the active ACE is
down, the stand–by ACE takes over and becomes the active ACE.
– MSN users
The dynamic data for the MSN users is stored in the same ACEs as for the normal
users and is handled by the normal DDM.
REMARK: if a subscriber uses multiple MSNs then the semi permanent data could be
stored in different ACEs because each MSN is connected to a DNET and the DNET
can be different for each MSN. However to make data updates easier (for operator
commands), the semi permanent data for all the MSNs that belong to the same
subscriber is stored in one ACE. This is the ACE of the default MSN and if a data
request is sent to another ACE (for the other MSNs) then the DNET of the default MSN
is retrieved and the request is forwarded to the default MSN ACE. This ACE also
contains the dynamic data.
– PBX users
The dynamic data for PBX users is stored in the SACEPBX (active/standby). Unlike the
PABX data which is replicated over an active/standby pair, the dynamic data is not
replicated.
Since the dynamic data is only updated in the active CE, it is lost when the standby
takes over (e.g. after a restart). To avoid old (=wrong) data being used, the relations
are updated after a restart.
– Trunks (remote users)
The dynamic data of trunks is stored in the SCALSVT, together with the DDM.
The data survives a restart but is lost after a reload.
c. Overview of dynamic data functions
– Call forwarding
This function stores information on how many simultaneous CFs exist for the same
user (per basic service). When the maximum is reached, an additional CF will not be
allowed and the call is released.
– CCBS & CCNR
This function stores information necessary to set up a call to the busy or no–answering
party when he becomes free.

1.
– Queue service
The DDM manipulates the FIFO queue of priority and non–priority waiting calls and
ensures that the maximum number of queue cells is not exceeded.
– Simultaneous access inhibition for Subscriber Control
The service maintains a ”busy indication” for updating subscriber data, so that only one
process can have access at a time. If simultaneous access were allowed, data
inconsistency could occur.
– Malicious call identification
The service provides for the intermediate storage of MCI data to give the subscriber the
opportunity to request the data output.
– ....
7.4 Triggers to activate supplementary services.
There are different triggers for the activation of a supplementary service. Let us have a look
at the different possibilities.
7.4.1 Trigger from the Originating profile.
The trigger for some services comes from information retrieved from the originating profile.
Figure 315 shows a part of the Common Call scenario up to the retrieval of the originating
profile (message 7). By analysing this profile, CFCS knows that a service has to be
executed and from this moment on a deviation from the standard scenario can occur.

1.
Figure 315 : Trigger from the originating profile
Subscriber
analysis
1: SETUP or origination message

6 7
2: Select Channel
3: Channel Information
CFCS
4: Activate Call Control
5 5: Acknowledgement
4
6: Get Originating Classes
1 7: Classes Result
Signalling
2 3
Device
Handler
Examples :
- Fixed Destination Call : In this case we do not need to collect digits from the originating
subscriber. The semi permanent data contains the DN to where we have to setup a call.
This DN can now be passed to PATED for digit analysis. From here on, we follow the
normal Call Handling scenario.
- Call Completion allowed : If the originating subscriber is allowed to use Call Completion,
we have to store all information about this call in the dynamic data (upon request of the
subscriber, see later). This information can be retrieved when the destination subscriber
becomes free.
7.4.2 Trigger from the Prefix Analysis result.
The trigger for a service may also come from the Prefix Analysis result.

1.
Figure 316 : Trigger from Prefix Analysis
Subscriber Prefix
analysis Analysis
1: SETUP or origination message

6 7
2: Select Channel
10
3: Channel Information
CFCS
4: Activate Call Control
11
5: Acknowledgement
4,9 5,8
6: Get Classes
1 7: Classes Result
Signalling
8: Digit Request
2 3 9: Digits
10: Prefix Analysis

Device
11: Prefix Analysis result
Handler
Example : If a subscriber uses Subscriber Control to change his profile, he dials subscriber
control codes (*SC*...#) instead of a normal DN. The received digits are sent to PATED for
prefix analysis. The PATED result indicates a facility call. From this moment on, the CFCS
passes control to the facility handling software to deal with the service.
7.4.3 Trigger from the terminating profile.
In the case of a terminating call, we pass the DNET value (retrieved by PATED) together
with the last three digits to LSIF. Here, we determine the physical location of the called
subscriber (Terminal Number) and we retrieve the terminating profile. This profile can hold
information about terminating services (like call forwarding). So this is yet another possible
trigger to leave the standard call flow in order to execute a service.
7.4.4 Recall pulse from the subscriber received.
A Recall pulse is a signal, generated by an analogue subscriber during the stable state of
the call. It is used to activate a service. Depending on the subscribed services, different
actions can be taken.
Examples
- If a subscriber is subscribed to Malicious Call Identification, the recall pulse is a signal to

the exchange to register the terminating call. As a result, a printout of the call is made.

1.
- If a subscriber is subscribed to Three Party Service, the recall pulse is used to set up a
call to a third party. In the exchange, a receiver is joined to the subscriber and dial tone is
sent.
The following figure gives a brief overview of the scenario in the case of a recall pulse.
Figure 317 : Recall pulse received
Subscriber
Identification
1: Recall pulse
4 5
2: Activate CFCS
CFCS 3: Acknowledgement
4: Get classes
2 3 5: Classes result
1
Signalling
Whenever a recall pulse is received in signalling, the Call and Facility Control System will be
activated (actions 1 to 3). Here, the classes of the subscriber are retrieved. (actions 4 and
5). Depending on these classes, different actions can be taken. (connect receiver and send
dial tone, register the malicious call, book Call Completion, ...)
7.4.5 Trigger from received signalling events (Event monitoring).
a. Definition
The purpose is to have a general, service independent mechanism for SIG for its event
treatment, so as to avoid that the SIG modules have to do service specific checks to
find out whether an event can be treated autonomously or has to be passed to the call
control level. At Call Control level, modules that may be interested in an event include:
– CFCS
– DDM
– PARM
– BCGRM
– Call Control function for intelligent networks.

1.
When there is interworking between some services (e.g: supplementary service and an
IN service), more than one of the above mentioned modules may be interested in an
event.
To cope with all this, a data driven mechanism is created inside SIG.
b. Working principle
Figure 318 shows that there exists a pool of tables. One such table contains events
received by SIG for which the treatment may vary. E.g: a release event can be handled
by SIG autonomously , while in some cases another module has to be activated to treat
the event.
Events for which the treatment is fixed are not indicated in the table. E.g: Register
recall events are always passed to CFCS.
Figure 318 : Event monitoring

TACB
SIG
POOL
Treat Report Link to Send to

Local CFCS CFCS SIG B
Answer Y/N Y/N Y/N Y/N

Release Y/N Y/N Y/N Y/N
On hook Y/N Y/N Y/N Y/N
... Y/N Y/N Y/N Y/N
.
.
.
The meaning of the different options in the table is as follows:
– Treat local
This indication specifies whether ’Signalling Actions’ can be performed by SIG

receiving the event at its side.
– Report to Call Control
Indication whether a call control module has to be informed about the event or not.
Signalling will not receive a reply. The module where the event has to be reported to is
also specified.

1.
– Link to Call Control
Indication whether a call control module has to be activated and linked to SIG. SIG will
receive a reply message containing the process identity of the call control module. In
this case too, the destination module is specified.
– Send to remote Signalling
Indication whether the event has to be reported to the remote SIG at the other side.
Each TACB is linked to a table, because for a basic call without any service involved,
one table is necessary per TACB.
As mentioned before it is possible that multiple destinations have to be informed.

Therefore there may be more than one link in the TACB. In case of interworking it is
sometimes necessary to combine the tables, e.g: perform an ’AND function’ to
determine if local treatment is possible.
Note : Only one link can exist for an unstable call because SIG then reports to the destination where
it is linked to.
Some of the tables (like normal call and specific services) are fixed and only the link to
these tables has to be inserted in the TACB. Other tables are created at CFCS level
and downloaded to SIG (e.g: result of an IN access)
7.4.6 Busy/free changes of a subscriber line (Monitor Access).
a. Definition
The LCE–id of the DDM is stored in the DH. This data is overwritten whenever it
becomes obsolete.
In addition, several call services (e.g: CCBS, CCNR, QS, ...) require a supervision
mechanism based upon the identity of the physical access of a subscriber (LCE–id &
TN). This mechanism is used only for lines (analogue or ISDN) and not for trunks.
To cope with all this, a feature ”Monitor ACcess” (MAC) is defined. This is a
mechanism which uses data stored in the DH.
b. Working principle
Figure 319 shows the working principle.

1.
Figure 319 : Monitor Access

Request MAC
Report reservation
busy
free Timer1 Timer2 free
(1) (2) (3) (4)
(1) One or more channels of the access are free but there is no reply (e.g: CCNR) As a
consequence, the service can request to supervise the access .
(2) Access is occupied (e.g: CCBS) Also in this case a service can request to supervise
the access.
(3) When the line becomes free (on hook), the DH is informed (=release). Timer 1 is
started (e.g: 5s) during which period the subscriber can originate a new call. Any
terminating call is refused.
When the subscriber originates a new call, the timer is stopped, the access becomes
busy again but the MAC request remains booked.
(4) At this moment the MAC requestor is informed. At the same time a timer 2 (e.g:
10s) is started during which period the subscriber can start a new call or terminating
calls are accepted if they are initiated by the MAC requestor (DDM, PARM). Therefore
the call setup must contain a ”MAC indicator” to distinguish this set up from another
”normal” setup.
(5) Access free. Any incoming or terminating call is accepted.
The required functionality can be summarized as follows:
– When a subscriber cannot be seized (e.g: busy or no reply) some services may
want to reserve one of the channels and request to report its availability whenever
it becomes free.
– When a subscriber releases the call, he is given some time to originate a new call
(timer1)
– After this time out, the requesting facility should be given precedence on this access
for terminating calls for a limited time (timer2)
– Also the DDM LCE–id is stored in this datastructure.

1.
c. Interfaces
– Storage of the DDM LCE–id.
The DH stores the LCE of the DDM per subscriber. During the set up of a call, this
information is passed to SIG and further to CFCS.
– Request to supervise a subscriber access.
It is possible to check a subscriber access to verify when it becomes free and to pass
this information towards the ”monitor access” requestor.
A requestor can be: DDM, PARM, CFCS, BCGRM (=Business Communication Group
Resource Manager), ...
Figure 320 gives an example of this principle:
Figure 320 : Monitor Access request

SCALSV
1
2
CFCS 3 DDM
3
1
ASM B
3
SIG B
ON HOOK
3 1
2
DH
(1) CFCS received the information that the B subscriber is busy and queue
service is applicable. In this case a request is sent to the DDM which in turn
requests monitor access to the DH via SIG.
(2) The necessary acknowledgements are sent backwards and the CFCS
terminates. All the necessary information (dynamic data) is stored and the
subscriber line is in monitoring.
(3) When the subscriber goes on–hook the DH is informed (release). Timer 1 is
started (see before) to give the B–subscriber the opportunity to start a new call.
When the timer expires the DDM is informed, which retrieves the necessary
information to start the call. The call setup is started by activating the CFCS.

1.
For lines belonging to a hunt group PARM is always informed when a line becomes
free. Individual DNs (IDN) can have also timer 1 running (see above). However, GDNs
cannot have this timer as the access is seized immediately when it becomes free.
7.5 Facility handling examples
7.5.1 Subscriber Control (SC)
a. Facility description.
Subscriber Control allows a subscriber to activate, deactivate, register and invoke

certain supplementary services. There are different procedures for analogue and ISDN
subscribers.
We will here discuss the case of an analogue subscriber.
Figure 321 : Subscriber Control Procedure

Subscriber Exchange
OFF_HOOK
DialTone
SC–Digits
Confirmation Tone
In case of registration, activation or invocation, the SC – Digits are :
*SC[*PW][*SD]#
In case of cancellation or deactivation, the SC – Digits are :
#SC[*PW][*SD]#
SC: Service Code : Identifies the service to be manipulated.
PW: Password : This is a secret code, assigned on an individual basis. The

assignment, changing and deleting of a password is done by the administration.
For some services the use of a password is mandatory.
SD: Service Data : This is a set of parameters, necessary for the manipulation of
the corresponding service. The layout of this service data is different for each
service.

1.
b. Implementation.
The following scenario shows how the subscriber control is handled in the Call
Handling. The scenario starts from the moment the prefix digits are received in
Signalling. In case that the number of prefix digits is 3, the first digits that will be
received are : *SC or #SC. These digits are passed to PATED for analysis. The result
from PATED indicates that we have a Subscriber Control procedure and from here on a
deviation from the general Call Scenario.
Figure 322 : Subscriber Control Scenario

8
PATED LSIF DDM SDM
9
3 10
4 5
2 6 7
CFCS
6
11
1
5
SIG–A
(1) The received prefix digits from the subscriber (*SC or #SC) are passed to CFCS.
(2) From CFCS, they are passed to PATED for prefix analysis.
(3) PATED analyses the prefix digits and returns as result :
– Type of call = Facility Call
– The type of facility that is being manipulated. This is derived from the analysis of the
SC.
– The Facility action (activation, deactivation, invocation, ...) This is derived from the
leading * or #.
– The layout of the expected parameters. For each type of facility, PATED can find in
a database relation a list of expected parameters, with their layout and an indication
whether the parameter is optional or mandatory.
All this information is sent back to CFCS. Now CFCS has to perform the following
tasks:

1.
(4) Pick up the profile of the calling subscriber to check if this subscriber is
allowed to invoke Subscriber Control for this service. This is done by sending a
request to LSIF to retrieve the Originating Classes of the subscriber.
(5) Send a request to the Dynamic Data Manager (DDM) to make sure that no
other process is updating the profile for this subscriber. At this moment, a busy
indication for the CFCS is set, so that from now on CFCS has exclusive access to
the subscriber data.
(6) Perform the combinability check. Again a request is sent to LSIF to collect all
necessary information to check if the service that is being manipulated can be
combined with the already active services.
(7) Now the updating of the subscriber’s profile can be initiated. The update itself
is performed by a dedicated FMM, called the Subscriber Data Manager (SDM).
Therefore, CFCS sends a command to SDM to start the updates.
(8) First, the SDM will pass its process identity to the DDM. The exclusive access
that was assigned in DDM (see message 8) is now associated to the SDM
process.
At this stage the SDM will perform all required Database updates.
(9) At the end of the updates, the exclusive access in DDM has to be released.
SDM sends a message to DDM, where the busy indication is reset.
(10) SDM finally sends an acknowledgement to CFCS.
(11) CFCS gives a command to SIG–A to send a confirmation tone to the

subscriber and terminates.
7.5.2 Call Completion to Busy Subscriber (CCBS)
a. Facility Description
This facility allows a calling user A, encountering a busy destination B, to have the call
completed when the destination B becomes free, without having to make a new call
attempt. When user A encounters a busy destination, user A can activate the
supplementary service. The service monitors the destination on becoming free. When
the destination becomes free a connection is first set up towards A and when A
answers, a connection is setup towards B.

1.
Figure 323 : CCBS Procedure

Subscr. A Exchange Subscr. B
Setup call to B
Check state of B : Busy

Busy Tone
Recall
Connect Receiver
Dial Tone
Digits : *SC#
Start monitoring B
Confirmation tone
On_hook
On_hook
Set up connection to A
Ringing Current
Answer
Set up connection to B
Ringing tone Ringing Current
Answer
Conversation

1.
b. Implementation
Figure 324 : A sets up na call to B
DDM–A
CFCS
1 6
4
2
SIG–A SIG–B
DH–B
The scenario starts with the setup of the terminating call. LSIF has already found the
profile of the called subscriber and has performed the restriction match.
Remark :
– The profile of the calling subscriber contains a flag indicating that CCBS booking is
allowed.
– The profile of the called subscriber contains a flag indicating that CCBS can be
booked against B.
(1) CFCS sends an indication to SIG–A to set up a terminating call towards B.
(2) SIG–A sets up a terminating call towards SIG–B.
(3) SIG–B sends a request to the DH–B to allocate a channel towards B. Now the DH
returns with an indication that subscriber B is busy.
(4) The Busy indication is sent to CFCS.
(5) Since CCBS is allowed (see remark above) and B is busy, the possibility exists that
subscriber A will book a CCBS. Therefore a request is sent to the DDM–A to store all

1.
necessary information to handle the booking.
In the DDM, the following information is stored :
– Calling DN
– Called DN
– Terminal Number of A
– Indication that this is an originating CCBS booking.
– Indication that this is only a temporary tuple. The A–subscriber has to activate
CCBS booking within a predefined time period. After this period is passed, the tuple
will be removed.
– ...
(6) Now CFCS will send a command to SIG–A to return Busy tone to the calling
subscriber. Then CFCS terminates.
Figure 325 : A books CCBS
LSIF PATED DDM–A DDM–B
8 15 9
3 10
CFCS
14
16 11
4 13
7
2
1
6
SIG–A SIG–B
17 5
12
DH–B
This scenario shows what happens if subscriber A books CCBS.

1.
(1) Subscriber A hits the Recall button. This event is reported to SIG–A
(2) Whenever Recall is received, SIG–A activates CFCS.
(3) CFCS sends a request to LSIF to pickup the profile of the calling subscriber. This is
necessary to check if the subscriber is allowed to use the Recall pulse and to decide
what to do when recall is received. For CCBS booking, the subscriber must dial the
Service Code (*SC#). Therefore,
(4) an indication is sent to SIG–A to allocate a receiver and to send dial tone (5) to the
calling subscriber. Also the number of expected digits is passed to SIG–A.
At this point, SIG–A will send a message to ARTA to start the selection of a
DTMF–receiver. This action is not shown in the scenario. We continue the scenario
when the expected number of digits has been received (6).
(7) The received digits are delivered to CFCS.

(8) CFCS sends the digits to PATED for analysis. The result from PATED indicates that
this is a CCBS booking.
(9) First a request is sent to DDM–A to check if the previously stored information (see
figure 324, (5)) is still stored. It is possible that subscriber A waited too long for the
booking and that the tuple has already been deleted.
(10) Now a request is sent to DDM–B to store also all necessary information on behalf
of the called subscriber. This is necessary, because if later B becomes free, the call
has to be set up again from that side.
Stored information :
– Calling DN
– Called DN
– Terminal Number of B
– Indication that this is a terminating CCBS booking.
– ...
(11)..(13) DDM–B requests to start monitoring the access of subscriber B.
(14) A confirmation is returned to the CFCS.
(15) CFCS sends a message to DDM–A to indicate that the CCBS is now really active.
The tuple at A–side which was marked as temporary, is now changed to active, so it
will not be removed.
(16) CFCS sends a command to SIG–A to send confirmation tone to the A–subscriber
and terminates.

1.
(17) Sending of the confirmation tone.
Figure 326 : B becomes free
LSIF DDM–A DDM–B
6
15 23 5 24
16
CFCS 4
7
8 13 20 3
12 17
21 22
11
18 1
SIG–A SIG–B
10
9 14 2
19
DH–A DH–B
Actions when B ends his previous call and the CCBS is triggered.
(1) On_hook of the B–subscriber.
(2) The RLS event is passed to the device handler. Here, a timer is started, giving B
the time to originate a new call.
(3) When this timer expires. the DDM–B is informed.
(4) DDM–B reads the CCBS data and activates the CFCS.
(5) In CFCS, first the Dynamic data of the A–subscriber is picked up.
(6) Access to LSIF to get the terminating classes of A. This is necessary because the
exchange first sets up a terminating call to the A subscriber.
(7) Command to set up a terminating call to A
(8) Acknowledgement
(9) Allocation of a channel to A.

1.
(10) Send ringing current to the A subscriber. This is a special ringing current to
indicate to A that this is the recall from the exchange.
(11) A answers the call
(12) The answer event is reported to CFCS.
(13), (14) CFCS gives the command to send a special tone to A to indicate that a call to
B is going to be set up.
(15) LSIF access to pick up the originating profile of A.
(16) LSIF access to pick up the terminating profile of B.
(17), (18) Terminating Call set up to B
(19) Select a channel to the B–subscriber.

(20) Acknowledgement of the terminating call set up.
(21), (22) CFCS passes the stable call data to SIG–A and SIG–B
(23), (24) CFCS sends a command to DDM–A and DDM–B to remove the dynamic
data for this CCBS. CFCS terminates.
7.5.3 Malicious Call Identification (MCI)
a. Facility Description
This supplementary service enables a user to request that the source of an incoming
call be identified and registered in the network. The following items are registered :
– Time and date of the request.
– Called party number.
– Calling party number (and possibly subaddress).
Depending on the subscription option, the supplementary service may be invoked

during or after the active phase of the call, but in any case before expiration of the MCI
invocation request timer.
b. Implementation
Malicious call identification is a terminating service. Therefore the scenario starts when
the terminating call is set up.

1.
Figure 327 : MCI call setup scenario
LSIF DDM–B
2
1
9
CFCS
3 10 11
4
SIG–A SIG–B
5
7
6
DH–A DH–B
(1) Access to LSIF to pick up the profile of the terminating subscriber.
(2) Profile of B is returned. This profile includes an indication that MCI is allowed.
(3), (4) Terminating call setup, via SIG–A to SIG–B
(5) Request to select a channel towards the called subscriber
(6) Set up a connection between called subscriber’s module and calling subscriber’s
module.
(7) Identity of selected channel is returned to SIG–B
(8) Acknowledgement to CFCS
(9) Since MCI is allowed, CFCS sends a request to DDM–B to create a tuple, holding
Calling and Called DN and the current time and date.
(10) CFCS passes stable call data to SIG–A.
(11) CFCS passes stable data to SIG–B. This stable data will hold a monitor table,
used by SIG–A to report events to DDM–B and a monitor table, used to activate CFCS.
The layout of this monitor table is shown in the next figure.

1.
Figure 328 : MCI monitor tables

Monitor table towards CFCS

Local CFCS CFCS SIG–A
Answer Y N N Y
Release N N Y Y
On–Hook Y N N Y
Info Y N Y Y
Remote answer Y N N N
Remote release N N Y N
... ... ... ... ...
Monitor table towards DDM–B


Local CFCS CFCS SIG–A
Answer Y Y N Y
Release Y Y N Y
On–Hook Y N N Y
Info Y N N Y
Remote answer Y Y N N
Remote release Y Y N N
... ... ... ... ...
According to the Monitor table towards CFCS, SIG–B will start up CFCS whenever :
– Subscriber B releases. In this case the CFCS will send a request to DDM–B to
update the tuple.
– Subscriber A releases. Here, too, a request is sent to DDM–B to update the tuple.
– Subscriber B sends an INFO message (ISDN only). This is the request from B to
generate a report about this call. Now CFCS will send a request to DDM–B to
retrieve the recorded information. Then this information is sent to a dedicated FMM
for subsequent printing.
An analogue subscriber indicates a malicious call by generating a Recall pulse. In the

case of a Recall, SIG–B will always activate CFCS. From this point onwards, the
actions are the same as for an ISDN subscriber generating an INFO message.
The monitor table towards DDM–B is used by SIG–B to know which events should be
reported to DDM–B for logging. According to the table, SIG–B will inform DDM–B

1.
about : a local answer, a remote answer, a local release and a remote release. The
DDM–B will update the information.
The following scenario shows what happens if B answers the call.
Figure 329 : MCI, B answers
DDM–B
4 1
SIG–A SIG–B
2
DH–A DH–B
(1) B answers
(2) SIG–B sends a request to the device handler to connect the calling and called party.
This is the result of the column ”Local Treatment” in both monitor tables. This column
indicates two times YES.
(3) Send a report to DDM–B. This is the result of the second monitor table (towards
DDM–B). Here the column ”Report CFCS” states YES. No reply is expected.
(4) Send the answer event to the SIG–A. This is the result of the columns ”Send to
SIG–A” of both monitor tables. Both columns have the indication YES.
The following scenario shows the actions when a Recall is received. This is the case of
an analogue subscriber. For the ISDN subscriber, this corresponds to the reception of
an INFO message.

1.
Figure 330 : MCI, Recall from B received
Alarm
LSIF DDM–B
Call
FMM
3
4
5
CFCS
1
SIG–A SIG–B
(1) Recall event received.
(2) Whenever a Recall is received, CFCS is activated. When activated, CFCS returns
its process id to SIG–B.
(3) CFCS accesses LSIF to retrieve the profile of the B–subscriber. This is necessary
because we have to check if no other services requiring a Recall, are active. In that
case, we will have to connect a receiver and send dial tone to B. Then B can pass the
Service Code, corresponding to ”MCI request”.
We consider the case where no other services are active. This implies that the Recall
must be an MCI request. So no receiver will be connected.
(4) Request to DDM–B to retrieve the information from dynamic data and to delete the
allocated tuple. The data is passed back to CFCS.
(5) CFCS sends the data to a dedicated FMM where the necessary actions are taken to
print out the report. These actions are not shown in the scenario.

1.

1.
8. CHARGING
8.1 Charging functions
Figure 331 : Charging functions

charging charging charging charging
analysis generation collection output
N7 X25 NSC
call
handling taxation
centre
X25 billing
centre S
BILL chg acc
Ç 2S
S
S S
chg = charging
acc = accounting
The different functions of charging:
- charging analysis;
- charging generation;
- charging collection;
- charging output;
- accounting.
These components can be situated in the same exchange as the call handling, but each of
them individually can be located in a different node. As an example consider a situation
where the charging generation is done in the own exchange, whereas the charging analysis
is performed in an other exchange.

1.
Figure 332 : Charging analysis in an other exchange

own exchange A–party DN other exchange
B–party DN
charging analysis
tariff code
charging generation
The other exchange can be a higher–order exchange, a transit exchange or any other type
of exchange. The own exchange supplies the other exchange with the A–party DN and the
B–party DN. The other exchange then checks which tariff is applicable to this call.
To allow charging generation in the own exchange, the information about the tariff, in the
form of a tariff code, is returned to the local exchange. The tariff code is translated in the
local exchange into a tariff group and a tariff identity (see chapter 8.4.2).
8.2 Different ways to charge calls...

8.2.1 Bulk billing
During the conversation a counter is incremented. After the call the counter value is added
to the subscriber’s bulk counter.
8.2.2 Detailed billing
Every call is charged in such a way that a detailed billing record is provided at the end of the
call. The contents of this record is very administration dependent, but it may contain
amongst others:
- the A–party number;
- the B–party number;
- the start and end time of the call;
- the amount of pulses accumulated during the call;
- certain facilities that were triggered during the call.
8.2.3 Detailed billing observation
Detailed billing observation is similar to detailed billing. The difference is that detailed billing
observation is a facility that is assigned to a subscriber, for example if he complains about

1.
his bills. The purpose of detailed billing observation is only to obtain a detailed record of the
call. The standard charging is still applicable as well to charge the call.
8.2.4 Toll ticketing
Toll ticketing should be considered as a combination of detailed billing and bulk billing : only
for calls to specific directions the detailed billing will be used, while for other directions the
bulk billing method should be used.
8.2.5 Automatic Message Accounting (AMA)
AMA is an other name for any type of detailed billing.
8.2.6 Division of revenue (accounting)

The purpose of Division Of Revenue is to split the collected revenues between different
administrations, in case more than one administration is envolved for setting up calls
between two subscribers. The reason why the DOR function exists, is the fact that the
calling subscriber will only receive a bill from the administration he is connected to, while the
revenue for that call should be divided over the two administrations.
In order to know how much of the money collected by the administration should be paid to
the other administration, the S12 keeps track of :
– the number of calls
– the number of pulses
– the total conversation time
– the amount of seizures
– the amount of seizure seconds
as a function of the destination and time.
8.2.7 Charging statistics
The purpose of the charging statistics is to investigate on which calls the most money is
earned. Its implementation is based on the DOR implementation, whereby some extra
accounting classes are defined to which only the number of calls and the number of pulses
are associated.

1.
8.2.8 Limit of credit
Limit of credit is assigned to a separate counter per subscriber. When this counter reaches
a certain limit of tariff pulses within a predefined time limit, some types of outgoing calls will
be barred.
8.2.9 Advice of charge (AOC)
Advice of charge is a facility of an ISDN–subscriber, allowing him to receive charging

information on an individual call basis (requested at seizure), or permanently for all calls the
subscriber makes.
The charging information is sent to his telephone set or to the PC connected to his basic
access.
Three variants of this facility are defined :
– AOC at call set–up;
– AOC during the call;
– AOC at the end of the call.
8.2.10 Facility charging
Whenever a subscriber activates, deactivates, invokes or interrogates a facility, he may be

charged for it. The charging type in this case is facility charging.
8.3 Charging methods
8.3.1 Unit charging
Unit charging is understood as a charging method whereby a number of pulses is defined

per time interval. Each of these pulses represents a certain cost, which is the same for all
pulses charged during the call. Pulses are charged to the subscriber at the beginning of
every time interval, or at the end of every time interval, depending on the charging method.
a. Unit Fee
The charging counter associated with the call is incremented only once with a certain
number of pulses at the moment charging needs to be started, e.g. upon answer of the
called subscriber.

1.
b. Periodic metering
The charging counter is incremented periodically with a number of pulses after each
elapsed time interval. The time interval between two increments is called the rate.
Different methods use a different starting point for the periodic pulses.
Figure 333 : Unit Charging Methods

start of charging end of charging
Unit Fee a rate
Periodic
b b b b b b
a: unit fee pulses
b: periodic pulses
8.3.2 Continuous charging
Continuous charging is understood as a charging method whereby a price is determined per

time interval. If the length of the call is not a multiple of this time interval, the price is
calculated, up to a certain granularity, taking into account the exact call duration.
Total cost = call set–up cost + SUM taken over all tariff periods (price per time unit * call
duration)
E.g. : price = 500 centimes per 6 min

call duration = 230 sec
call set up price = 300 centimes
granularity = 1 sec
cost of the call = 300 + ( (500/(6*60)) * 230) = 619 centimes (see figure 334).

1.
Figure 334 : Continuous charging

COST
(centimes)
unit
1500
1000 continuous
619
500
call set–up .
price
TIME
230 360 720 1080 (seconds)

1.
8.4 Charging analysis
8.4.1 Charging analysis with MMC commands
Figure 335 : Charging analysis with MMC commands

charging details
ORCHG charging tariff

modulators modulators
DISPLAY DISPLAY DISPLAY

DESTCH TZ DISPLAY TG/TI TG’/TI’ RATE
TARIFF TARIFF CHARGING
CHARGING MODULAT
ZONE TARIFF
TG’
DISPLAY
DATE CHARGING DAYCAT
RATESEQ
CALENDAR: holiday
HOCAL
DISPLAY
CHARGING
SCALE
DISPLAY
DAY OF CHARGING DAYCAT not holiday
WEEK CALENDAR:
WEEKCAL TIME
TZ = tariff zone
TG = tariff group
TI = tariff identity
This overview is used in the following chapter to explain the different charging parameters.
8.4.2 Charging parameters
a. origin for charging

Each subscriber line or incoming trunk connected to the exchange is, for charging
purposes, identified by an origination code. This code has been created to group the
geographical origins that are considered by the charging system as unique origins. This
code is called the origin for charging, abbreviated to ORCHG in figure 335. It is derived
from the source code which in turn defines the originator of the call (subscriber group,
incoming trunkgroup).
E.g. see figure 336: subscriber 1 (belonging to an RSU) and subscriber 2 are
connected to the same exchange. Because they have a different origin for charging,
they can be charged at a different rate for the same destination.
b. destination for charging
This parameter is used to group destinations that are considered by the charging
system as unique destinations. This code is derived from the dialled prefix. Refer to
DESTCH in figure 335.

1.
c. tariff zone
The tariff zone defines a measure of distance between the charging origin and the
charging destination. Refer to figure 336: if a subscriber with origin for charging A
makes a call with destination for charging 1, then the tariff zone is A1. If an other
subscriber, with origin for charging B, makes the same call, with the same destination
for charging 1, then the tariff zone is B1.
Figure 336 : Charging Overview

AREA 1 AREA 2
Subscr 1
RSU Exch 1 Exch 2 Exch 3
orig chg A dest chg 1

tariff zone A1
dest chg 2
tariff zone A2
Subscr 2
orig chg B dest chg 1

dest chg 2
tariff zone B1
tariff zone B2
The following MMC command demonstrates how the destination for charging that was
obtained from prefix analysis (DESTCH = 2), is translated in a tariff zone, depending on
the origin for charging (ORGCH 0 – 3 give TARZONE 3, ORGCH 4 gives TARZONE 4).

1.
ÊÊ
DISPLAY–TARIFF–ZONE:DESTCH=2.
DISPLAY–TARIFF–ZONE SUCCESSFUL
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
TARIFF ZONE
ORGCH ORGUSE DESTCH UNIQUE TARZONE BCGTARZONE

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
0 IN USE 2 NUNI 3 NO
d. modulators
Modulators are extra parameters that may influence the final result of the charging
analysis. Modulators can operate on two levels:
– charging modulators can change the charging task that was found in a completely
new charging task;
– tariff modulators can only change the tariff group and tariff identity that were found
to new values.
The following parameters can be used as modulators:
– type of call;
This parameter defines the calling party category (CPC) , eg. normal subscriber,
priority subscriber, coinbox, and so on. This code is retrieved from the class of
service.
– bearer capability;
For ISDN–calls the charging may also depend on the bearer capability requested
for the call. This parameter is received from the calling ISDN subscriber in the
SETUP message. It allows the administration to charge a subscriber in relation to
the minimum quality of the connection requested by the subscriber.
– high layer compatibility;
– tariff type indicator (TTI), used in IN;
– BCG indication;

1.
– analogue/ISDN indication.
Note : A parameter can be used as either a charging modulator, or a tariff modulator.
The tariff modulators can be displayed with a specific MMC command:
ÊÊ
DISPLAY–TARIFF–MODULAT:TARGRPID=1&1,TYPE=INT.
DISPLAY–TARIFF–MODULAT SUCCESSFUL
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
TARIFF MODULATOR
TYPE : INT
TARGRPID : 1 & 1
MOD1 = BCG MOD2 = HLC MOD3 = FAXSTR MOD4 = ANALISDN

MOD5 = IIBERCOM MOD6 = FULLHALF
MOD1 MOD2 MOD3 MOD4 MOD5 MOD6 TARMOD

GRP ID
–––––– –––––– –––––– –––––– –––––– –––––– –––––––
0 1 FALSE ANLOG FALSE HALF 2 1
0 0 FALSE ANLOG FALSE HALF 34 1
e. charging details (or charging task)

The above mentioned parameters define a unique charging task. This task includes:
– charging pattern: when to start and stop the charging;
– charging type: bulk billing, toll ticketing;
– charging analysis point: own exchange, higher order exchange;
– charging generation point: own exchange, not own exchange;
– recording point for bulk billing: own exchange, not own exchange;
– class of meter: to which subscriber’s meter are the pulses added;
– tariff group and tariff identity : they indicate which charging method, rate, number of
pulses will be used.
An example is given with the following MMC command and the resulting output. From
the prefix analysis we received a destination for charging (= 5) and an origin for
charging (=0), which is used as input in the operator command.

1.
ÊÊ
DISPLAY–CHARGING:TARZONE=3
DISPLAY–CHARGING SUCCESSFUL
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
TARZONE
=======
3
TARIFF TARIFF CHPAT

ANALP RECPFBK GP & ID CLASS START STOP LNGCOMSI
===== ======= ======= ====== ================== ========
CHOWN SCP 1 5 5 CHSUBASW ANNMSTOP 0
RECIND CHANRES
KIND COMB PARTY TYPTRAF CHSEL INC OUTG CHGENPT
=================== ======= ====== ================= =======
NOIND COSPR CG INT SINGLE CHINCNON CHOGNONE CHOWN
LINEMTR
TOTCHSTA CHSTAALW NOAOCH NOPLSTAR 1 2 RSEQSND
======== ======== ====== ======== ======== =======
0 FALSE FALSE FALSE 0 0 FALSE
AMADCR
========
DBLNG
The output gives us tariff group 1 and tariff identity 5. We also find that charging has to
start at answer and stop at an announcement.
f. Tariff group
In every exchange, we can define 8 calendar types, consisting of a week calendar and
a holiday calendar. This calendar type will give each day a day category : a workday, a
week–end day, a holiday and a special day.
The function of the calendar type is to allow administrations to charge international calls
according the local calendar of the destination. Since in the USA Saturday is
considered to be a workday, a call to the USA on a Saturday will be charged against a
normal tariff, and on a Sunday against a reduced tariff. A call on a Saturday to a
Nordic country, however, will be charged against a reduced tariff.
To determine the day category, first the holiday calendar has to be checked:

1.
ÊÊ
DISPLAY–CHARGING–CALENDAR:HOCAL,YEAR=1996.
DISPLAY–CHARGING–CALENDAR SUCCESSFUL
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
OPTION = BASIC HOLIDAY CALENDAR

––––––––
CALENTYP – YEAR – MONTH – DAY –––> DAYCAT DAY OF WEEK

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––
1 – 1996 – JAN – 1 HOLIDAY MO
1 – 1996 – APR – 8 HOLIDAY MO
1 – 1996 – MAY – 1 HOLIDAY WE
1 – 1996 – MAY – 16 HOLIDAY TH
1 – 1996 – MAY – 27 HOLIDAY MO

1 – 1996 – JUL – 21 HOLIDAY SU
1 – 1996 – AUG – 15 HOLIDAY TH
1 – 1996 – NOV – 1 HOLIDAY FR
1 – 1996 – NOV – 11 HOLIDAY MO
1 – 1996 – DEC – 25 HOLIDAY WE
If a particular date is not a holiday, then the week calendar has to be checked with the
weekday.

1.
ÊÊ
DISPLAY–CHARGING–CALENDAR:WEEKCAL.
DISPLAY–CHARGING–CALENDAR SUCCESSFUL
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
OPTION = BASIC WEEK CALENDAR

––––––––
CALENTYP SU MO TU WE TH FR SA TABLE
––––––––––––––––––––––––––––––––––––––––––––––––––––––––
1 WKA WDA WDA WDA WDA WDA WKA ACTIVE
2 WKA WDA WDA WDA WDA WDA WDA ACTIVE
3 WDA WDA WDA WDA WDA WDA WDA ACTIVE

1 WKB WDB WDB WDB WDB WDB WKB PASSIVE
2 WKB WDB WDB WDB WDB WDB WDB PASSIVE
3 WDB WDB WDB WDB WDB WDB WDB PASSIVE
8 WDA WDA WDA WDA WDA WDA WDA PASSIVE
A tariff group corresponds with one calendar type and one charging scale. A charging
scale specifies for each day category (workday, holiday, week–end, ...) and for each
switch–over time in that day category, the corresponding rate sequence number
(normal, reduced) to be used. This is shown in the next example :

1.
ÊÊ
DISPLAY–CHARGING–SCALE:TARGRP=1.
DISPLAY–CHARGING–SCALE SUCCESSFUL
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
OPTION = BASIC SCALE

TABLE = BOTH TABLE WITH A ACTIVE
ACTIVE TABLE
SCALE
GROUP CALENTYP DAYCAT HOUR : MIN RATESEQ
–––––––––––––––––––––––––––––––––––––––––––––––––
1 1 WD A 0: 0 RATESEQ1A
1 1 WK A 0: 0 RATESEQ4A
1 1 HO A 0: 0 RATESEQ4A
1 1 SP A 0: 0 RATESEQ5A
PASSIVE TABLE
SCALE
GROUP CALENTYP DAYCAT HOUR : MIN RATESEQ
–––––––––––––––––––––––––––––––––––––––––––––––––
1 1 WD B 0: 0 RATESEQ1B
1 1 WK B 0: 0 RATESEQ4B
1 1 HO B 0: 0 RATESEQ4B
1 1 SP B 0: 0 RATESEQ5B
On workdays the following rate sequences apply:
– from midnight till 8 Hr: rate sequence 1A
– from 8 Hr till 9 Hr: rate sequence 2A
– from 9 Hr till 12 Hr: rate sequence 3A
– from 12 Hr till 13.30 Hr: rate sequence 2A

1.
– from 13.30 Hr till 17 Hr: rate sequence 3A
– from 17 Hr till 18.30 Hr: rate sequence 2A
– from 18.30 Hr till midnight: rate sequence 1A.
You also find the rate sequences for week–end days, holidays and special days.
Note : Although the parameter “rate sequence” usually only takes the values ”rates1”and ”rates2”
(normal and reduced), other values may be applied. If the administration decides to employ a special
tariff for calls made during the busy hour, then the parameter rate sequence can be assigned the
value ”rates3”. This new rate sequence will result in a different charging method, different pulses,
different period.
Note : In the database some data is stored in an active table and in a passive table. This allows
the operator to first implement new data changes in the passive tariff plan. After having checked all
his inputs, he can then switch over from passive to active table via an operator command.
g. Tariff identity
A tariff identity defines the content of the different rate sequences. There may be
different tariff identities for the same charging scale (= same tariff group).

1.
ÊÊ
DISPLAY–CHARGING–TARIFF:TARGRPID=1&2,TABLE=ACTIVE.
DISPLAY–CHARGING–TARIFF SUCCESSFUL
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
TABLE : ACTIVE TABLE A

TARGRPID : 1 & 2
TARCLS : 2
TARKIND : FIX
TARCLSGP : 0
BCGIND : OFF
SUBTKDTO : OFF
MINTIME LINEMTR
RATESEQ : CHMETH RATE RATETYPE CHGTYPE TAX NRC

––––––– –––––––––––––––––––––––––––––––––––––––––––––––
RATESEQ1 : UNFSYN 0 DECISEC CHSTRMEX 15 15
PHASE TIMES PULSES RATE RATETYPE NEXTPHASE

––––––––––––––––––––––––––––––––––––––––––––––––––––––
0 1 1 3600 DECISEC 1
1 ENDCALL 1 3600 DECISEC 1
MINTIME LINEMTR
––––––– –––––––––––––––––––––––––––––––––––––––––––––––

––––––––––––––––––––––––––––––––––––––––––––––––––––––
0 1 1 1800 DECISEC 1
MINTIME LINEMTR
––––––– –––––––––––––––––––––––––––––––––––––––––––––––

––––––––––––––––––––––––––––––––––––––––––––––––––––––
0 1 1 1500 DECISEC 1
The examples show that for tariff group 1 and tariff identity 2 the charging method is
unit fee synchronised, with one unit fee pulse and one periodic pulse. The period is:
– 3600 deciseconds (=360 seconds = 6 minutes) for rate sequence 1 and 4;

1.
– 1800 deciseconds (=180 seconds = 3 minutes) for rate sequence 2;
– 1500 deciseconds (=150 seconds = 2.5 minutes) for rate sequence 3.
The tariff identity thus specifies which rate will be used at a specific time.
A tariff group covers tariff identities for which the same charging scale and calendar
type are used.
Up to 64 tariff groups each comprising maximum 32 tariff identities are allowed.
8.4.3 Software involved with charging analysis
This paragraph describes a general call charging scenario. The charged call can be one of
the following : an analogue subscriber, an ISDN subscriber, a trunk call. Depending on the
case, the charging is handled in different modules : ASM, ISM, DTM, ITM, SCM.
Depending on the requirements of the administration, charging of an analogue call will be

activated :
– when the calling subscriber goes off–hook;
– after indialling the prefix;
– after indialling the complete number.
For an ISDN call there is no indialling because all the digits are received at once.
Nevertheless the moment of activation can also be after prefix analysis, ...
Figure 337 gives an overview of the software actions on activation of the charging
subsystem.

1.
Figure 337 : Activation of charging
1 2
CFCS 6 CGC 3 CHAN
TCAS MCCA
SSM SSM
SCALSV
4 5
LCG
TCE
[1]
Request from CFCS sent to Charge Generation Control (CGC) to activate the charging
together with the parameters charging needs (origin for charging, destination for charging,
type of call, bearer capability ..). CGC allocates a temporary buffer in which all charging
information for this call is stored.
[2]
CGC needs the following information:
– charging method;
– rate;
– number of pulses (unit fee and periodic);
– facilities;
– division of revenue;
– detailed billing.
To receive it, CGC sends a message to Charging Analysis (CHAN) with the necessary
parameters retrieved from CFCS.
[3]
CHAN completes the charging analysis and sends the data back to CGC in one or more
messages. CGC copies this data to the already seized buffer.

1.
[4]
CGC translates the taxation directory number received from CFCS into a so called charging
key. This key determines in a unique way the location where the subscriber meter is stored.
This function is performed by the Meter Counts Collection Access (MCCA) SSM.
CGC passes all this information to the Local Charge generation FMM, situated at TCE level.
Then CGC releases its own buffer. LCG in turn allocates one or more taxation cells (e.g. in
case of facilities). The cells that belong to the same call are linked together.
The cells contain the charging data from CHAN, a counter to add the pulses and space to
store the time stamps needed for detailed billing.
Note : In case both the A–party and the B–party have to be charged (for example for a split charging
facility call), then CGC sends a message to both the TCE of the A–party and the TCE of the B–party.
[5]
Finally LCG sends a report message to CGC. This message contains the taxation cell
identity and the task that CGC has to perform. The task here is to inform CFCS. Now LCG
waits for the start charging event.
[6]
CGC sends the acknowledgement to CFCS.
8.5 Charging generation
Figure 338 : Charging generation
1 Metering
SIG events
LCG SSM
TCAS
SSM
2 AOC
SSM
TCE
[1]
Each call event detected by Signalling (SIG) is reported to the LCG FMM (e.g. answer, clear
back, clear forward, forced release...). These events are compared with the start and stop
charging events.

1.
In case of the start charging event (e.g. at answer), the charging meter in the taxation cell is
stepped up depending on the charging method used. For periodic charging a timer is
started.
In case of the stop charging event (e.g. clear forward), LCG stops accumulating the
subscriber meter and cancels the periodic time–out.
LCG uses three SSMs:
- Metering SSM: this SSM increments at the correct time the subscriber’s counter in the tax
cell;
- Advice Of Charge (AOC) SSM: this SSM calculates the charging amount the subscriber
has to pay up to now and informs signalling at the time that was requested by the
subscriber [ 2 ] . Signalling sends the AOC information to the subscriber’s ISDN set.
- Taxation cell access SSM (TCAS): access to the taxation cell is performed via a common
interface: the TCAS SSM. This SSM is also present in the SACE, because some of the
LCG functions are now handled in the SACE.
8.6 Charge scale change–over
This function allows to change from one set of charging parameters (charging method,
number of pulses, periodic rate ...) to another one as a function of the day of the year and
the time of day.
This function is handled by an FMM situated in an Active/standby pair ACE, called Charge
Scale Change Over FMM (CSCO). Via database relations, the FMM knows for each tariff
group the current and the next rate sequence (normal, reduced..) to be used. It informs (see
figure 339):
– all CHAN FMMs to ensure that all new calls apply this new rate sequence.
– all LCG FMMs to ensure that all calls in conversation are switched over to the new
tariff corresponding to this rate sequence.
– maintenance to set/reset the day/night indicator on the master alarm panel (MAP), if
required by the customer.
At switch–over time, CHAN is informed of the current and new rate sequence number for
each tariff group via the normal message routing principle.
This principle is not used to update all the LCGs in the line and trunk modules because this
would take too much time. Instead the broadcast principle is used. The messages are sent
to an FMM in the CTM modules where they are inserted in the tone link in a specific channel
and thus sent to all the TERIs port 5.
So, at switch–over time, all LCGs receive via the broadcast mechanism all data they need
for both well the current and the next switch–over time (rate sequence number, tariff group

1.
and identity, tariff method, number of pulses ...). This data is stored in the LCG.
The LCG then starts a time–out for the next switch–over time. When this timer runs out,
LCG already has the charging data applicable at that moment from the previous broadcast
message of CSCO. If there are cells with a difference between the current charging and the
new one, a switch–over action is done.
Figure 339 : Charge scale change–over
MASTER ALARM
PANEL
SYSTEM 12
MAINTENANCE Switch ON/OFF
SW DAY/NIGHT tariff
LOCAL CHARGE
GENERATION
Trigger LCG
OPERATING Switch–over
SYSTEM Actual Next
Rate
CHARGE Rate
SCALE :
CHANGE :
OVER : :
: :
Actual Next
BROADCAST Rate Rate
SW
New Tariff Info
Switch over to next tariff

CHARGE
ANALYSIS
8.7 Charging collection
In this chapter different possibilities are shown for handling the charging results after a call.
The results can be stored locally in the exchange on disk or sent directly to a taxation centre
via a N7 link. Another possibility is immediate billing to an external device : e.g. to a printer
in a hotel.
8.7.1 Bulk billing collection
The collector FMM for bulk billing is the Meter Counts Collection (MCC) FMM . MCC is
stored in the SACECHRG, an active/stand–by ACE. There can be a number of ACE pairs in

1.
an exchange (minimum two) according to the size of the exchange (number of equipped
subscribers) and administration requirements.
The bulk billing data is sent to the MCC on a per call basis. The bulk billing data is sent
either at the end of the call or at some intermediate points during the call, reaching
thresholds of pulses and/or chargeable duration in time.
To secure the transport between the TCE where the charging data is generated and the
centralised collection function, a sequence numbering is used.
The collection function will then accept messages carrying these sequence numbers in a
window, allowing it to detect missing and retransmitted messages.
The sending of bulk billing data towards MMC is shown in figure 340.
Figure 340 : Scenario bulk billing collection
Local Charge 3
Meter Counts checksum

Generation Collection charging key
counters
tax cell SACECHRG (stand–by)
TCE
1 2
Meter Counts checksum 4

Collection charging key
counters
SACECHRG(active)
LCG sends the charging data to the active MCC. The active MCC forwards the data to the
stand–by MCC. The stand–by MCC finally sends an acknowledgement to LCG.
Periodically all the counters are stored on disk (always duplicated ). The time interval is a
CDE parameter. The transfer from memory to disk is done in blocks of 2K Bytes.
8.7.2 Detailed billing collection
The detailed billing records can be handled in two ways, depending on whether local storage
or central storage is used:
- local storage
The records are kept in a buffer and stored on a disk file when this buffer is full .

1.
- central storage
The detailed billing records are stored in a temporary buffer and sent on–line to a
remote taxation centre for further processing.
a. local storage of detailed billing records
There are a number of ways to sort the detailed billing records:
– sorting per day

Records are written in 31 files, depending on the day of the month. Only records
that satisfy the selection criteria are written to disk.
– sorting of charging observation

This function is called time period detailed billing observation (TPDBO). The
purpose is to record all calls generated by specified subscribers, meeting certain
criteria. The selection criteria determines to which files selected records are
written. An example is to store the records per subscriber.
– chronological sequential output

Here a file, or a group of files are used per charging record type. The records are
written to disk in the same order as they appear.
Figure 341 sketches the chronological collection.
Figure 341 : Chronological collection
SACECHRG master SACECHRG slave
3 4 5
CHRONO TXCS CHRONO TXCS
TDFM TDFM
TCE
6
LCG
TL SSM

1.
The following software is involved:
– Chronological collector (CHRONO) FMM:
The CHRONO FMM receives the charging records from LCG. CHRONO then
checks the sequence and the checksum.
– Taxation Collector (TXCS) SSM:
The SSM is responsible for the memory storage of the records, the interface with
the mate processor and the determination of the master / slave state.
– Tax layouter (TL) SSM:
This SSM performs the layouting of the charging records.
– Taxation Disk File Manager (TDFM) FMM:

TDFM handles the interface with the input/output system. It also selects a file or a
file group. TDFM transfers the records to disk when either the relation where the
records are stored in memory, is full, or when a timer expires.
b. central storage of detailed billing records
After generating and collecting the detailed billing records of a subscriber, the records
can be transferred to a centralised point in real time. This point is called a taxation
centre. A taxation centre can be a stand–alone system, or it can be collocated in an
exchange.
The detailed billing records are stored on disk or tape for later transfer to a billing
centre. Here finally the records are processed, resulting in the bills that are presented
to the subscribers.
There are two FMMs for the specific central storage actions:
– Taxation Collector (TAXCOL) FMM;
– Originating Taxation User Part (OTAXUP) FMM.
The beginning of the central storage is identical to the local storage. Please refer to
figure 341. Then the following happens:
– TXCS triggers the TAXCOL FMM when the relation where the records are stored, is
full, or when a timer expires. TAXCOL then stores the records in a taxation buffer.
– at fixed intervals OTAXUP checks whether the taxation buffer is full. If the buffer is
full, the records are sent to the Destination Taxation User Part (DTAXUP) in the
taxation centre via the N7 network. When TAXUP receives an acknowledgement
from DTAXUP, it deletes the records from the taxation buffer.

1.
For security reasons OTAXUP can send the records to two taxation centres: the normal
or the alternate taxation centre.
8.7.3 Division of revenue collection
a. Accounting principle
Division of revenue (DOR) is used when the fee for a certain outgoing call has to be
divided between different administrations. This is done by gathering the number of
pulses, call duration, number of calls, seizure duration and number of seizures in
counters as a function of the destination and time period.
DOR makes no reference to individual calls or to the individual subscribers. The pulses
are accumulated in counters defined by an accounting class.
For the purpose of DOR between administrations, 6000 accounting classes are
provided.
Each accounting class provides 5 counters :
– number of conversation minutes (time between answer and release)
– number of pulses
– number of calls
– number of seizure seconds (time between seizure and release)
– number of seizures.
b. Method of Collecting Division of Revenue
The Division of Revenue Collection is distributed over:
– CHRONO and TXCS;
– an Intermediate Division of Revenue Collector (IDRC) in the SACECHRG;
– several Division of Revenue Collectors (DORC) in SACECHRGs.
After a call, where DOR is required, the following happens (see figure 342):

1.
Figure 342 : Division of revenue collection
4
checksum
IDRC accounting class
number of seizures
seizure duration 7
DORC
3 number of calls
call duration
TXCS number of pulses
.
2 .
.
CHRONO Buffer
5
6
SACECHRG (active)
SACECHRG(stand–by)
1
checksum
accounting class
number of seizures
seizure duration
DORC number of calls
LCG call duration
number of pulses
.
.
.
TCE
[1]
At the end of the call, LCG sends the charging cell to CHRONO in a loadsharing way.
[2]
CHRONO stores the information in temporary buffers.
[3]
When a buffer is full, TXCS informs IDRC.
[4]
IDRC finds out which DORC is used for a specific accounting class.
[5]
DORC passes the updated information to it’s mate.
[6]
The stand–by DORC sends an acknowledgement to the IDRC, which can release the
cell.

1.
[7]
At regular intervals all counters are stored to disk. To save the counters on disk two
alternatives are provided:
– read before write;
– write only.
8.8 Charging output
The collected charging results can be treated in different, customer dependent ways :
- transfer data to magnetic tape, optical disk or system printer.
- transfer charging data to a Network Service Centre (NSC).

- transfer charging data via an X25 link to a billing centre.
The master program of all charging output activities is the Charge Recording Manager
(CRM). All charging requests, both manual and automatic, are passed via the CRM to the
different FMMs depending on the charging data type.
The activation of the charging output can be done :
- manually via an operator command in the exchange;
- automatically as populated in database;
- requested by TDFM when a file is full;
- requested by the NSC : scheduled or via an operator command;
- requested by the billing centre.
8.8.1 Bulk billing output
The bulk billing data was collected at ACE level by the MCC FMM . This data is further
processed for output by the Output Meter Block (OMB) FMM . OMB performs the
formatting required by the administration. Here, 2 possibilities exist :
- transfer the formatted data to magnetic tape, optical disk or system printer.
- transfer the formatted data to a disk file. Disk files can be used as an intermediate
storage for formatted files , before this information is sent to the Network Service Centre.
The CRM is the controller for the OMB. All requests are routed through and verified by the
CRM. A request originating in the NSC is passed to the CRM via the Exchange OMUP

1.
(Operations and Maintenance User Part) Subuser(EOS). Local operator commands are
routed via Man machine to the CRM.
The function of the OMB is: (see also figure 343):
- fetch the unformatted data
OMB sends a request to the active MCC FMM(s). Receiving data from the MCC gives
us the possibility of getting recent data taken from memory or data already stored on
disk (chosen via a flag in database). The data is sent in blocks of 2 kB to the OMB.
- format the data
OMB sorts the meters per DN and omits the non–equipped DNs. The data is formatted
into codes required by the administration (ASCII, EBCDIC, BCD) and by the output
device (tape,disk, printer, binary devices). This is completely data driven.
- transfer the data to a specified output device
Via the Input/Output SW, OMB requests a file on disk or tape (or optical disk) to copy
the formatted data or it sends the data to a printer or binary device.

Figure 343 : Output of bulk billing
TO/FROM NSC
operator CHARGE EXCHANGE

request RECORDING OMUP
MANAGER SUBUSER
Output to NSC via EOS
METER COUNTS
COLLECTION
unformatted OUTPUT formatted

BUFFER
data METER data
Tape or OD
BLOCK
unformatted data I/O

SOFTWARE
I/O SOFTWARE
8.8.2 Detailed billing output
Via the TDFM the AMA records were written on twin disk files. When a big amount of
detailed billing records are generated in an exchange, one collector or one disk pair may not

1.
satisfy. In that case several collectors (TDFM) and disk pairs may exist. So besides the
PLCE module, one or more Peripheral and Backup Database CE (PBDCE) pairs can be
equipped.
An interface is required between the CRM and the collectors (TDFMs): the Collector
Controller (COLC). This FMM determines which input file of which collector needs to be
formatted next for output. The COLC FMM is a multi–process FMM because it must handle
requests for different AMA call types, different disks and different collectors at the same
time. It is located in the same ACE as the CRM: the SACE Command handler and Output
(SACECP).
a. Detailed billing output to tape, optical disk or NSC
All output requests, whether they are automatic requests because of a threshold that is
reached, or whether the request is triggered by an operator or by an NSC, are passed
to the CRM. The input for CRM is an unformatted file. CRM then formats the file into a
suitable layout for tape. The output file is called the formatted file. Via database the
CRM defines the identity of the output file.
In case of transfer to an NSC, the requestor of the dump is always the NSC. The output
file is formatted and transferred to an intermediate disk file, waiting to be copied by the
NSC.
For the output of the AMA files, we need two FMMs:
– the AMA File Formatter (AFF) FMM;
The AFF formats and transfers the files. The formatting is completely data–driven.
The AFF FMMs are distributed over all CEs that contain output devices. This
includes the P&L and the PBDCE.
– the AMA File Formatter Controller (AFFC) FMM.
The AFFC controls the AFFs. The AFFC is located in the same active/stand–by
ACE as the CRM and the COLC: the SACECP.
The CRM passes the request to dump the file(s) to the AFFC. The AFFC needs
information about the input files, like the file identity, the start read pointer, the end read
pointer. This information is retrieved by the Taxation Disk File Manager (TDFM) FMM,
via COLC. The information is then passed to the involved AFFs.
The FMMs involved and a scenario are shown in figure 344.

1.
Figure 344 : Detailed billing output to tape, optical disk or NSC
PBDCE or PLCE SACECHRG
AFF SSM
TDFM
AFF
stand–by SACECP
active SACECP
AFFC COLC
CRM
b. Detailed billing output to a billing centre

If the detailed billing records have to be transferred to a billing centre, the File
Transfer, Access and Management (FTAM) protocol is used over X.25 links. FTAM
allows to:
– request files. This includes open, transfer and close a file;
– deallocate files.
Every file that has to be transferred has a unique virtual file name. FTAM supports
several virtual file stores. the Virtual File Store (VFS) FMM is located in the IPTMOX25.
This module also handles the X.25 link to the billing centre.
The output to a billing centre is handled by two FMMs:
– the Massive Charging Provider (MCP) FMM:
MCP formats the files and transfers them to the billing centre. MCP is located in
the IPTMOX25.
– the Massive Charging Reader (MCR) FMM:
MCR reads the files from disk and transfers them to MCP. MCR is located in the
PBDCE or the PLCE.
In addition also a Q3 interface can be used to transfer the detailed billing records to a
billing centre. In this case a dialogue is possible between the billing centre and the local
exchange.

1.
8.8.3 Division of revenue output
The Division Of Revenue Collector Output FMM (DORO) is responsible for the formatting
and transmission of the accounting results, collected by DORC. The counters can be sent to
tape, NSC or/and printer.
The DORC–files are reformatted by DORO into DORO– files. DORO gets the data to format
from DORC via 2K buffers, while the backup process keeps running in DORC.
These actions of DORO are scheduled in time :
- every 24 H: DORO stores the counters for output in a daily file. For security also the last
two daily files are kept.
- every of month: the monthly accumulated files are adapted. Two files are kept for the last
2 months.
On the same times, also a printout is generated of the same data. This can also be
requested immediately by the operator.
At the request of the CRM (via NSC or Man Machine), DORO can be asked to output its
daily and monthly files to tape or NSC.
In case the operator requests current counter values, DORO sends a request to DORC.

1.

1.
9. MAINTAINING AN A1000 S12
9.1 System and microprocessor initialization
Before the system is started, it is necessary to transfer the software from the disks to all
system microprocessors (CEs and OBCs). This operation is called System Initialization.
Furthermore, during the operational life of the exchange, certain CEs and/or OBCs may
have to be downloaded again from disk due to failures. Each individual load is known as
Reload.
However, some failure situations will be solved by simply starting up the software already
contained in the memory of the faulty CE. This software ’start’ is also performed after a CE
load (at system initialization), as well as after a reload. This procedure is known as Restart.
9.1.1 CE initialization
The CE download consists of the transfer of the software packets (GLS, PLS and DLS) from
disk into the microprocessor memory due to power–on, the detection of certain types of CE
failures (eg. when there is strong evidence that the write–protected memory has been
mutilated), following a forced request from the maintenance software or an operator
command.
Every microprocessor has a program called Bootstrap stored in ROM. This program, which
allows for the download and the initialization of the control element, is identical for all the
Control Elements.
First, the Bootstrap decides, based on the reason for its triggering and/or on the data in the
request message, whether or not it is necessary to perform a series of fast tests to verify the
correct operation of the CE elements (TI, memory and CPU). When the tests are finished or
when the Bootstrap has decided that they are not necessary (’reload’ operation), the
Bootstrap program continues by trying to obtain its load packet.
Since the PLADMCEs are the only CEs able to access to the system tape and disks, they
are responsible for sending the load packets to the requesting CEs through the DSN. Their
download process is therefore different from the other. Thus, first of all, the Bootstrap
program must check if it is located inside a PLADMCE or in another CE. To do so, the
program tries to reach the DMCA board, an operation that will only be successful if the CE
requesting the load is a PLADMCE.

1.
Figure 345 : Bootstrap triggering

ANY MODULE
– Power–on
– Forced
– Error detection CE ROM
Triggering reason
Bootstrap program
BOOTSTRAP ? RELOAD
Fast Test
Not OK
? OK DMCA access attempt
OK ? Not OK
CE failure
PLADMCE Any other CE
If the CE is not a PLADMCE, the Bootstrap program continues by requesting the download
from the P&L modules. The Bootstrap program needs to establish a path through the
network in order to send a message requesting the load. Although it knows the message
destination address because the PLADMCEs are located at the same addresses in all the
exchanges, it does not know its own, the origin address. Because of this, the Bootstrap
applies a special algorithm to be able to send the request message to both PLADMCEs from
any CE address and any DSN equipment.
The algorithm involves of the sending of a set of sequential messages as follows:
First attempt:
Three stage message to PLADMCE–1

Three stage message to PLADMCE–0
Second attempt:
Two stage message to PLADMCE–1

Two stage message to PLADMCE–0
and so on.
Whatever the number of DSN stages equipped, one of these attempts will reach the
PLADMCEs successfully.

1.
Let us take the TREX example again, where the JLTCE (NA=0220) tries to reach the
PLADMCEs (NA=000C and NA=000D) .
The first attempt consists of two messages with seven SELECT commands. The sequence
is:
A. Switching towards any low port of the AS
B. Switching towards any port of the first stage GS
C. Attempt to switch towards any port of the second stage GS
D. Since there are only two stages, this last command is not acknowledged, and the
whole
attempt becomes unsuccessful.
Figure 346 : Unsuccessful JLTCE–to–PLADMCE connection

STAGE 1 STAGE 2
12
0
13 0 8 0 8
1 9
ÉÉÉÉÉ
4 0 2 0
13
ÉÉÉÉÉ
15 7 15
12
ÉÉÉÉÉ
4 0 8
13 0 8 1 9
2 1
1 2
PLADMCE 1 13 C
1 7 15
7 15
0 8
1 9
8 2 2
2 D
B 7
2 13 15
6
A 0 15 0 8
1 9
2 2 3
JLTCE 7 15
0 8
0 1 9
2 4
6
7 15
0 8
1 9
2 5
7 15
After a time–out, the JLTCE Bootstrap program again tries sending two more messages with
five SELECTs commands. These are:
A. Select low port

B. Select any port
C. Select port 0
D. Select port 0
E. Select port C (in one case) or D (in the other one).

1.
As we can see in the figure below, the attempt is successful with this set of commands.
Figure 347 : Successful JLTCE–to–PLADMCE connection
12
E STAGE 1 STAGE 2
0
13 0 8 0 8
D 1 9
4 0 2 0
13
ÉÉÉÉÉ 15 7 15
ÉÉÉÉÉ
12
4 0 8
ÉÉÉÉÉ
13 0 8 1 9
2 1 2 1
PLADMCE 1 13 C
1 7 15
7 15
0 8
1 9
8 2 2
B 2
2 13 7 15
6 15 0 8
A 0
1 9
2 2 3
JLTCE 7 15
0 8
0 1 9
2 4
6
7 15
0 8
1 9
2 5
7 15
In order to provide the PLADMCE with the requesting CE Network Address, the DSN
supports a special kind of ESCAPE protocol called ESCAPE INTERROGATE which is
characterized by an Interrogate Flag set to ’True’. This command includes three fields
containing a pointer, a port number and a channel number.
A set of these commands, with decreasing pointer values, are stored at the end of the load
request message. When this command is switched at a multiport, the pointer value is
decreased by one. If the new pointer value is not equal to zero, the command is simply
passed to the output port. If, on the contrary, the pointer value is equal to zero, the multiport
writes the input port and channel numbers into the corresponding fields and sets the pointer
to seven. In this way a trace of the path already covered by the message is kept.
The figure shows how this method works in the first multiport of the established path for
reasons of simplicity the channel number field is not shown.

1.
Figure 348 : Escape Interrogate example
12
STAGE 1 STAGE 2
0 13= 3 0
POINTER–1 8 0 8
1 9
4 0 2 0
ÉÉÉÉÉ
POINTER–1 =13
4
15 7 15
ÉÉÉÉÉ
12
0
4 0 1
8
ÉÉÉÉÉ
13 8 9
2 1 2 1
PLADMCE 1 POINTER–1 = 5
7
1 15
7 15
0 8
1 9
8 2 2
2
7 15
2
6
POINTER–1 =6 0
0 15 8
1 9
2 2 3
POINTER–1 = 0
7 15
JLTCE
0 8
1 9
0 ESCAPE INT. FLAG INPUT PORT NUMBER = 0 POINTER
4 =7
2
6 7 15
0 8
1 9
2 5
ESCAPE INT. FLAG INPUT PORT NUMBER FIELD POINTER = 1 7 15
The complete load request message will therefore have the same structure as shown on the
figure below:
Figure 349 : Structure of the load request message
UP TO 7
SELECT COMMANDS
TO REACH A PLADMCE
LOAD BIT PACKET
DATA
7 ESCAPE INTERROGATE
Once the request is accepted and the address of the requesting CE known by the P&L
modules, the associated load packets are split up into blocks and sent through a held path to

1.
the requesting CE. The Bootstrap program collects all the blocks received and stores them
into memory.
On completion of the CE load, the Bootstrap function terminates and a new RAM module
takes control of the CPU to drive the initialization of the CE. This initialization, called Restart,
consists mainly of cleaning all the Operating System data (queues, pointer, etc.) and
creating all the FMM supervisory processes.
If the CE reload is requested through an operator command, it is possible to indicate

whether the reload should be complete or partial. In the case of a partial reload, the request
could e.g. inidcate to reload only the GLS and PLS packets, or only the DLS packet.
The Bootstrap sequence for PLADMCE is quite different. First, it tries to get the load packet
from its mate P&L module through the network (as seen for any other CE) (step A on the
figure below). However, if this operation fails for some reason (eg. the other PLADMCE is
not on–line) the Bootstrap starts the ’Query–VDU’ procedure.
This procedure starts by placing a question mark on the VDU screen connected to a MMC
channel (step B1). Then, if the operator answers ’O’ to the question, the packet is loaded
from Optical Disk (OD) or if the operator answers ’Y’, the packet is loaded from tape (step
B2); if, on the other hand, the answer is a negative or there is no answer before a time–out,
the packet will be loaded from its own disk (step C).
Figure 350 : PLADMCE download sources

PLADMCE 1
– Power–on
– Forced
– Error detection CE ROM
Triggering reason
ÉÉÉÉÉÉÉÉÉÉ
Bootstrap
ÉÉÉ
ÉÉÉÉÉÉÉÉÉÉ ÉÉÉ
C
ÉÉÉÉÉÉÉÉÉÉ A
ÉÉÉ
B2
ÉÉÉ
PLADMCE 2
B1
In the first case, when the operator replies ’Y’ or ’O’ to the query after placing the System
Load Tape on the Magnetic Tape Unit or the System Load Disk in the OD (steps 1 and 2 on

1.
the figure below), the software is loaded into the P&L module (GLS, DLS and PLS, step 3).
This procedure is called the disk–build, which is necessary to copy all the software from tape
(OD) towards the system disk.
As soon as the disk–build procedure is completed (step 4), the PLADMCE will reboot (step
5).
Figure 351 : Disk Build
ÉÉÉÉÉ
ÉÉÉÉÉÉÉ
4 PLADMCE 1
ÉÉÉÉÉ
5
ÉÉÉÉÉÉÉ
ÉÉÉÉÉÉÉ
ÉÉÉÉÉÉÉ
ÉÉÉÉÉÉÉ
4
4
3 PLADMCE 2
2B
2A
’ YES ’
Once the download is completed, a request is sent from this CE to its mate to solve the
Active/Stand–By status. If there is an answer to this request, the mate CE takes the Active
status and the just–loaded CE the Stand–By one. If, on the contrary, there is no answer, the
CE considers its mate to be off–line and takes the Active role.
9.1.2 System initialization
a. Network Loading
The System Initialization or System Start–Up consists of loading the system

microprocessors (CEs and OBCs) from disk and their start–up. This procedure is triggered
by the operator, and driven by a set of configuration and load data on disk.

1.
The System Start–Up may be performed as part of the system installation or when the
operator judges that only a full system initialization will recover the system from a
catastrophic failure (Emergency Start–Up).
When both PLADMCEs are on–line and at least one disk is mounted, it is possible to carry
out the System Init. To start–up the system, the operator uses a MMC command, which
triggers the P&L software responsible for this task.
First, the software asks the operator for the system start–up confirmation. If it is confirmed,
the initialization software inhibits, in both P&L, the triggering of the load software in order to
avoid individual CE download requests.
The download of all CEs in the system is shared between the active and the stand–by P&L
modules. The software of each P&L module collects the download information that contains
the list of the CEs to be loaded from the Database. The Active module sees to the CEs
included in that list and the Stand–By one takes care of the remaining CEs.
Since the GLS and PLS are the same for all CEs of the same type, the initialization software
follows the ’cascade’ procedure. This procedure is as follows:
1. In order to place all CEs in a download request state, the initialization software
forces all of them to trigger the Bootstrap program (forced bootstrap).
2. A handshaking overlay module is distributed from the PLADMCEs to all CEs.
3. Once this particular module is loaded in all CEs, the PLADMCE selects one
processor of each type to act as the ’source’ CE. Then, using the handshaking module,
the PLADMCE loads it with the common part (GLS and PLS) and a task list indicating
which other CEs have to be loaded.

1.
Figure 352 : Distribution of the handshaking module
ACEs
PLADMCE 1
JLTCEs
CE list
HANDSHAKING
MODULE
DCASTCE
PLADMCE 2
CE list IPTMN7
ISVTCE
HANDSHAKING
MODULE
Figure 353 : Load of the Common Part files into the source CEs
SCALSV
PLADMCE 1
DFN7OCE
CE list JLTCE
CE
COMMON
PART
FILES
DCASTCE
PLADMCE 2
IPTMN7
CE list
ISVCE
CE
COMMON
PART
FILES

1.
Steps 2 and 3, as described above, are then repeated by the ’source’ CEs according to their
task lists. This process is chained until all CEs of the same type are loaded.
Figure 354 : Download in Cascade
SCALSV DFN7OCE JLTCE
JLTCE
SCALSV DFN7OCE
JLTCE JLTCE
JLTCE JLTCE JLTCE
JLTCE JLTCE
JLTCE
DCASTCE
DCASTCE
DCASTCE
JLTCE
DCASTCE
IPTMN7 JLTCE
ISVTCE
JLTCE
IPTMN7
ISVTCE
ISVTCE
ISVTCE IPTMN7
As for the load of the DLSs, the P&L module will not follow the previous process since the
they are different for each CE. Instead, it will send the DLSs one by one to each CE.
Since the PLADMCE memory is used as interface between the disk and the CEs during the
system load, it must be cleaned at the end of the process. Therefore, a bootstrap operation
will be carried out in both PLADMCEs.
Where only a partial system initialization is required a parameter in the

’SYSTEM–START–UP’ command will be used. This parameter allows either the reload of a
certain set of CEs through the definition of a list of CE types, or the load of only the new
ones (in the case of an exchange extension). In this partial system init, only a PLADMCE
working in simplex mode is used to perform the load.
b. Tonebus System Loader
The tonebus system loader software is a recently developed system which utilizes the tone
bus for down–loading, from system disk :
– the GLS’s which are common to a large number of CE/OBC processor types

1.
– the replicated data (i.e. any part of a DLS which is replicated in a large number of
CE’s)
The Tone Bus System Loader software, however, still uses the Digital Switching Network
(DSN), for downloading from system–disk :
– the GLS’s which are common only to a small number of CE/OBC processor types
– the DLS’s
By using the tone bus, the GLS’s and replicated data that are common to a large number of
CE/OBC processors, can be distributed in parallel, without any switching involvement from
the DSN.
Prior to the distribution of this information itself, first the Tone Bus System Loader software
must be loaded in all CE’s of the exchange. The Tone Bus System Loader software consists
of three parts :
- the Master software runs on the P&L, and controls the entire loading operation, which
involves the following items :
– loading the load sources with the Load Source Master software, load tables ,
non–tone bus GLS’s and DLS’s
– loading of the Tone Bus Slave Loader software into the target CE’s
– loading, via the tone bus, the common GLS’s and replicated data into the target
CE’s
- the Load Source Master software runs on the load sources, and is responsible for the
loading of the non–tone bus GLS’s/DLS’s into their respective CE’s.
- the Tone Bus Slave Loader software is loaded into the target CE’s and into the Clock
and Tones Module (CTM); this software is necessary in the target CE’s for the correct
reception of the load packets via the tone bus, and in the CTM for preparing these
packets for sending over the tone bus.
Figure 355 shows the distribution of the Tone Bus System Loader software within the CE’s
and also the data paths that are used during the loading process.
The Master software is activated by an operator command to begin the loading process.
When activated, the Master software accesses the hardware configuration files on the
system disk to obtain the identities of all equipped CE’s with their network addresses. The
Master software then enters the stand–alone operating mode by gaining control of the P&L
and stopping all software running in it.

1.
Figure 355 : Tone Bus System Loader

Stand–by
P&L CE Active Spare CE
Load
MASTER Load Source Master
Sources
System
Disk
Stand–by
Active CE
CTM TCE Target
Tone Bus Slave Loader CE’s
Tone Bus Slave Loader
(See note 4)
Tone Port
Tone Port
Tone Bus
Note : 1. = Bulk Data Paths
2. = User Controlled Path
3. CE = Control Element, CTM = Clock & Tone Module
4. The channels of the tone bus por are routed via the DSN Access Switch to
the network ports of the CE
After activation and entering the stand–alone working mode, the Master software performs
some preparation functions, such as :
– arranging the data into sorted tables, where the information is assembled regarding
CE’s/OBC’s which require the same GLS’s
– initialising the load sources by sending a boot–request message
– setting up a bulk–data path to each load source, and send to each of them the Load
Source Master software, and the actual GLS’s and DLS’s which are to be loaded
over the DSN into the target CE’s
– initialising the target CE’s by sending a boot–request message
Before the target CE’s can receive their load packets via the tone bus, they first must load
the Tone Bus Slave Loader software : this loading is shared by both the Master software and
the Load Source Master software :
– the Load Source Master software first loads via the DSN, a first part of the Tone Bus
Slave Loader software, enabling these CE’s to accept packets from the tone bus
– the Master software then sends over the tone bus the second part of the Tone Bus
Slave Loader software, which comprises the OBC Slave Loader software, and the
Debug software.

1.
Once the target CE’s are loaded with the Tone Bus Slave Loader software, the real loading
can start :
– the common GLS’s and replicated data via the DSN to the Clock and Tone Module
for distribution over the tone bus
– the load sources, loaded with the DLS’s and GLS’s which are common only to a
small number of CE/OBC processor types, now begin loading each of their
associated target CE’s via a DSN bulk data path
– the OBC GLS’s are loaded by the OBC Slave Loader software
After the loading phase, each target CE reports the success, or failure of the loading to the
Master software, which then :
– sends a tone bus broadcast message to all target CE’s, instructing them to run the
newly–loaded software
– presents the report of the loading process on the system printer
– returns control of the P&L to its operational software by rebooting it
c. Warm Start–Up
A strategy different from the complete system start–up is the ’Warm Start–Up’. The Warm
Start– Up provides a fast reload for package replacements in on–line exchanges. This
procedure keeps most of the exchange CEs on–line during most of the time spent on the
package replacement. This kind of system start–up, ’Warm–Start–Up’, is triggered by an
operator command.
One of the disks will hold the old SW (current package), while the other disk is built from the
new System Load Tape or optical disk. The PLADMCE associated with this magnetic disk is
loaded with the new package (following the above–described PLADMCE download
procedure) and isolated from the rest of the system.
The following figure shows how this strategy works.

1.
Figure 356 : Warm Start Up triggering
ÉÉÉÉÉ
ÉÉÉÉÉÉ ÉÉÉ PLADMCE 1
ÉÉÉÉÉ
ÉÉÉ
ÉÉÉÉÉÉ ÉÉÉ2 2
ÉÉÉÉÉÉ ÉÉÉ
ÉÉÉÉÉÉ ÉÉÉ
ÉÉÉ 2
ÉÉÉ
ÉÉÉ
only one disk with PLADMCE 2
3
ÉÉÉ
new SW version
ÉÉÉ
ÉÉÉ
1
3 New SW version
package
’ WARM START UP ’
The procedure to be followed by the initialization software in this case, is very similar to the
previous one (known as ’Cold Start–Up’). In order to keep the system CEs on–line, only a
limited set of selected ’source’ CEs (which will start the dumping of the common part in
cascade) are booted (driven off–line) and loaded with a GLS or different DLSs, together with
a task list.
The selection of the ’source’ CEs is made in such a way that the normal operation of the
exchange is not significantly disturbed (i.e. SPARE, MONI, ITTMTCE, etc.). In case of an
exchange extension, the new CEs are used as ’source’ CEs.
Once this process is finished, the other CEs are booted and loaded from the different load
sources.
At the end of a Warm System Start–Up, all the source CEs must be reloaded with their own
load packets.
During an on–line replacement, whereby the message and data interfaces are changed, the
initialization software must make sure that the two packages do not communicate with each
other.
The following figures show the Warm Start–Up cascade process.

1.
Figure 357 : Download of some of the source CEs in the TREX
PLADMCE 1
JLTCE FILES
CE list MONI
COMMON DCASTCE FILES

PART
FILES
SPARE
PLADMCE 2 IPTMN7 FILES

ITTMTCE
Figure 358 : Download from the source CEs in cascade
JLTCE
JLTCE
JLTCE JLTCE
MONI JLTCE JLTCE
JLTCE JLTCE
JLTCE
DCASTCE
SPARE
DCASTCE
JLTCE
DCASTCE
ITTMTCE JLTCE
JLTCE
IPTMN7
IPTMN7

1.
9.1.3 OBC initialization
All the TCEs that contain loadable OBCs, contain some resident modules to carry out the
OBC load control.
These modules manage the OBC status and are able to drive an OBC restart or a reload
triggered by an operator command or by failure conditions. In the case of an OBC reload,
these modules send a request message to the PLADMCEs in order to get the OBC load files
and send them to the requesting module. These OBC management modules collect the load
packets and send them, through the OBCI, towards the OBC memory. Finally, an OBC
restart is forced.
Figure 359 : OBC download
PLADMCE 1
CE – GLS + PLS
IPTMN7 CE Load Source
CE – GLS + PLS
CE DLS
IPTMN7
TI
ÉÉÉÉ
ÉÉÉÉ
OBCI OBC
ÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉ OBC – GLS + PLS
ÉÉÉÉ
CE
ÉÉÉÉ
CE memory OBC memory
On the other hand, the system start–up (Cold or Warm) includes the OBC initialization. The
OBC packet is a GLS and optionally a PLS. The packet is loaded from the PLADMCE into
the TCE memory, using a reusable area such as, for example, the overlay zone or another
free zone if enough memory is available.
When the exchange is started, the SW of the corresponding TCE transfers the OBC file from
that memory into its own OBC (or OBCs), in the same way as seen above. This task is part
of the TCE initialization.
The OBC doesn’t receive a DLS. The necessary data is retrieved from relations included in
the DLS of the CE. This data is extracted and transmitted towards the OBC(s) by FMM(s).

1.
9.2 Introduction to maintenance
The maintenance function of an ALCATEL 1000 S12 exchange deals with the task of
maintaining the system at the highest possible grade of service level. The maintenance
functions can be divided into two main categories:
- Preventive maintenance
- Corrective maintenance
Preventive maintenance includes those tasks that identify potential faults before they occur.
Corrective maintenance includes those tasks that isolate and correct fault conditions
An ALCATEL 1000 S12 exchange has extensive self–monitoring and fault handling facilities
which ensure that a hardware or a software fault has a minimum effect on the exchange
operations. The objectives of the ALCATEL 1000 S12 maintenance strategy are to ensure
that the system effectiveness is met. System effectiveness is defined as a measure of an
exchange’s ability to function normally and to cope with internal hardware and software
failures or other events that could disturb normal operations.
The ALCATEL 1000 S12 exchange maintenance is designed around self–supervisory and
self–diagnostic procedures. The strategy calls for the performance of maintenance tasks
with a minimum interruption of normal traffic. The necessary maintenance tasks include
rapid detection, analysis, identification, alarm signalling and detailed fault reporting. The fault
reporting includes internal software notation and a printed report to the exchange personnel
for these tasks. The functional maintenance software is called the MAINTENANCE
SUBSYSTEM and the hardware is arranged in functional units called SECURITY BLOCKS.
Whenever the analysis by the maintenance subsystem determines that a hardware fault
exists, the functional unit which carries the fault will be put out of service. The maintenance
strategy reduces to a minimum the effect of a fault on the exchange’s call carrying capacity.
9.3 Hardware and software used in maintenance
The functions of the maintenance subsystem are divided into a so–called centralized part
and a decentralized part. The centralized functions are located in a special System–ACE,
which is called DFCE (Defence Control Element) and the P&L (Alarm system), the
decentralized functions are located in every CE:
- Centralized functions
– Coordination of all maintenance functions and central control of decentralized

maintenance functions
– Frequent access to maintenance data
– Interface to mass memory devices and I/O–devices

1.
– Central fault analysis
– Treatment of alarms
– Fault localization (tests)
- Decentralized maintenance functions
– direct access to the supervised module
– fast local error handling, fault detection
– Alarm detection
The corresponding Hardware is shown in the following picture:
Figure 360 : Hardware configuration

VDU
P&L CE CE
PTR MCUB
CLMA RLMC MCUB TAUC
MTU
MAP switch
Alarm Clock &
MD switch Tones
Inputs
ODK
DSN
CE CE DTM
switch PCM
MCUB
CTM TTM
Clock CE CE Test
& Tones TSA MCUB

Equip-
distribution ment
CE CE PTCE
CE
MCUB
MPTMON
Terminal

1.
Figure 361 : Maintenance SW distribution
LEA ASM
P&L LEA
DH–FMM/SSM
Alarm handling DH–FMM/SSM
I/O treatment Rack alarm DH
Alarm reporting
LEA DFCE
DH–FMM/SSM DTM
Reconfiguration LEA
Test (Fault localisa- DH–FMM/SSM
tion) Rack alarm DH
Operator Maint. cmds
System Defense
CTM TTM
LEA
DH–FMM/SSM
DSN LEA
Test Resources DH–FMM/SSM
(TSA)
CE
LEA
DH–FMM/SSM
CE
LEA
DH–FMM/SSM LEA
DH–FMM/SSM
PTCE

1.
9.4 Maintenance concepts
9.4.1 Definitions
a. Security block
Until now, errors in functional units usually led to their failure. Many errors, however,
only affect a few circuits with limited subfunctions of a unit, so it can be wise to isolate
these circuits and allow the remaining functions of the unit to continue to work. In order
to do this, it is necessary to define clearly delimited areas whose operational status can
be controlled under security aspects.
Such an area is called Security block (SBL)
– A security block (SBL) consists of a limited number of circuits in the hardware which
perform certain related functions.
– Should one function fail then all other functions within the affected SBL also fail.
– Therefore it is possible to remove the entire security block from operation by

software without further affecting total system operation.
– Security blocks thus represent the smallest subunits in the system which, if
necessary, can be reconfigured by software.
– The sum of all SBLs covers the whole system.
b. Replaceable item (RIT)
is the smallest identifiable unit which can be replaced for maintenance purposes
(PBAs, power supply units, cables, I/O–Devices ...). Each security block thus consists
of one or more replaceable items.
Use:
As part of automatic error correction (error localization) a diagnostic program has the
task of identifying the replaceable items (RIT) suspected of being faulty within a failing
security block (SBL). When finished, the following information is given:
– the SBL type (with address)
– the RITs
– the RIT location coordinates (suite, rack, subrack, location).

1.
c. Repair block (RBL)
Before replacing a replaceable item, it is necessary to remove from exchange traffic all
security blocks contained in the appropriate repair block. These security blocks are
then switched off. Because this action represents a reduction of redundancy, repair has
to be done as quickly as possible in order to reestablish full redundancy.
Example:
The power supply must sometimes be switched off in order to replace a faulty RIT. All
SBLs which belong to the RBL being fed by the corresponding converter must first be
switched off by use of special MMC–Commands.
d. Device
The system can also be split up into functional units or so–called devices. This concept
is only used by the device handlers and maintenance has knowledge about it when
interworking with device handlers.
The device type specifies the type of the device and is different from the SBL type, so it
is possible to have different hardware devices hidden behind the same SBL type
(realization of different interface conditions, signalling procedures,...).
9.4.2 Relationship
a. SBL – RIT
A RIT can contain different SBLs, e.g. a line RIT can contain 6 or 8 line SBLs. An SBL
can also consist of more than one RIT, e.g. the SBL CTLE can consist of a processor
RIT and a converter RIT.

1.
Figure 362 : SBL–RIT Assignment

SBL/RIT Assignment
SBL=TASL
1 2 0
3 4 1
5 SBL=TOPT
7
PROC SWITCH PBA

CE PBA SBL=ACSW
SBL=CTLE
Functional Units which
can be handled by the
Converter maintenance subsystem
b. SBL – RBL
A repair block can but usually will not coincide with the SBL. A RIT can contain several
SBLs. There are hierarchical dependencies among SBLs, that a lower level SBL cannot
be in service if a repair is being done on a higher level SBL, and the repair block will
also contain the lower level SBLs.
When the PBA to be replaced is not ’hot insertable’ the power unit has to be switched
off before the repair. That power unit can be common to other SBLs (e.g. common
converter for different modules), so the repair block will also contain the other SBLs fed
by the same power unit.

1.
Figure 363 : Repair Block
Repair Block
(example)
Converter
CE1 CE2 CE3 CE4 CE5

CTLE CTLE CTLE CTLE CTLE
c. SBL – device
The mapping of SBL type to device type is not always one to one. The device types are
necessary, because a special SBL type can map onto different device types! For
example:
SBL – Type Device – Type
ASST Printer
VDU
(ASST = asynchronous shared
terminal)
d. Security block hierarchy

The SBL hierarchy shows the dependencies between different SBLs with respect to the
accessibility seen from the DSN. So when a ’higher level’ SBL is out of service, the
SBLs which are ’lower’ in hierarchy are not accessible any more. This will be reflected
in their maintenance states. Therefore in case an SBL has to be taken out of service,
all its lower level SBLs will also be taken out of service.
– The SBL hierarchy of a control element, which is the SBL–Type with the highest
level, comprises maximum five levels.
– If a security block is removed from operation, all its subordinate security blocks are
generally also (automatically) taken out of operation since they would not be
functional alone.

1.
– Information about the hierarchy of SBLs is given in the Support Information SI05.
Figure 364 : SBL–dependencies
SBL
IN TRAFFIC
SBL Hierarchy
High
As a result of error analysis this
SBL is switched off in order to
isolate the error.
ERROR
FAILING
SBL
SBL SBL Low

SWITCHED SUBORDINATE SBLs ARE SWITCHED
OFF SWITCHED OFF AUTOMATI- OFF
CALLY
e. Security block categories

Although all SBLs are treated more or less in the same way. Some differences exist.
Also some SBLs require a similar kind of treatment. Therefore the whole number of
SBLs are grouped in five categories.
– Control element (CE)

All control elements
– Network (NET)
comprises all SBLs within the Digital switching network such as Switch elements,
Links between Switch elements...
– Telephonic (TEL)
groups all SBLs related to lines, trunks, receivers....
– Peripherals (PERI)
includes disks, tapes, printers...

1.
– System (SYS)
all SBLs related to the clock and tone system,...
9.4.3 Security block states and state transitions
Security blocks can be in different states whereby each state specifies in which manner the
security block is part of the operation or isolated from the operation. An overview of these
states is given below:
- IT In Traffic:
An SBL in service is able to carry traffic, it is in full operation.
- EF External Fault:
The SBL cannot carry traffic if the fault on the SBL is external to the exchange.
- FIT Faulty, but in Traffic:

If a small error is detected during a diagnostic test, the SBL keeps on handling traffic, but
maintenance is informed of the error
- FLT Faulty:
(error detected by the system) Due to the function in the SBL itself, more than a
predetermined number of service–affecting faults have been encountered and the
maintenance subsystem has confirmed these faults. The derived state is FLT. The SBL is
initialized automatically by the maintenance subsystem when the fault has been
corrected.
- FOS Faulty out of Service:

Similar state to FLT, but the SBL is not initialized automatically by the system after the
fault has been corrected. The SBL initialisation in this case is a task of the operator.
- OPR Operator out of Service:

Following the request of an operator to take a particular SBL out of service. These SBLs
can only be restored to service when the operator allows it.
- SOS Software out of Service:

Due to a failure of another SBL, the SBL itself is not faulty but a higher level SBL in the
same control chain has been taken out of service, or the repair block to which this SBL
belongs has been taken out of service. The SBLs out of service for this reason can be
returned into service as soon as the system allows it. This is done automatically by the
system.
- The following states are not accessible for maintenance:
NEQ Not Equipped:

The SBL is not equipped hardwarewise and no data is foreseen softwarewise. The SBL is
not declared in the configuration.

1.
PEQ Partially Equipped:

This state is only used for Network Link SBLs
EQAWL Equip allowed:

The SBL is declared in the configuration, but not physically present.
a. SBL state transitions
An ALCATEL 1000 S12 – Exchange in top condition consists of SBLs in traffic only.
The SBL states NEQ, PEQ and EQAWL are not taken into account because the
corresponding hardware is physically not present in the exchange.
The maintenance state of an SBL can change due to maintenance actions requested
by the operator, or autonomous actions supported by the Maintenance Subsystem.
Three basic maintenance actions on SBL are possible:
– DISABLE
The SBL will be put out of service.
– TEST
A diagnostic test will be started on the SBL.
– INITIALIZE
The SBL will be put into service.
These three actions can be started internally by the Maintenance Subsystem or by the
operator via the corresponding MMC–Commands.
The combinations of two or more basic actions are called combined actions:
– VERIFY
This command consists of three basic actions, first the SBL will be disabled, then it
will be tested, and if the test is successful, it will be initialized.
– REQUALIFY
This command consists of two basic actions, first the SBL will be tested, and if the

1.
test is successful, it will be initialized.
SBL–state transitions
Maintenance action Begin state End state
Internal disable after external fault IT EF

Internal put faulty FIT
Internal disabled/Verify FLT/FOS
Internal/Operator Maintenance
action disable on higher level SBL SOS
Operator disable OPR
Operator disable EF OPR

Internal initialize IT
Operator disable FIT OPR

Operator disable FOS/FLT OPR

Operator requalify (Test o.k.) IT
Operator test (test o.k.) OPR OPR

(test not o.k.) FLT
Operator initialize OPR IT

Operator Requalify (test o.k.) OPR
(test n.o.k.) FLT
Internal/operator maintenance action

Initialize on higher level SBL SOS IT
9.4.4 SBL management on CE Level (SBL=CTLE)
SBL Management on CTLE, e.g. disabling or initialising, is the same as the handling of all
other SBLs. There is an extended number of commands for this SBL–Type that affect the
SBL states involved and their hierarchical organisation.
Redundancy (modes of operation)
- Duplication of critical modules having a great failure impact, e.g.:
– Peripheral and load – module (P&L)
– Defence module
– Clock and Tone Module

1.
– Auxiliary control element (ACE) for collecting charging information (CSAC)
- ”SPARE” redundancy for less critical modules having a lower failure impact, e.g.:
– Auxiliary control element for traffic measurement tasks (MSAC)
– Auxiliary control element for administrative tasks (ASAC)
Modules having a low failure impact do not have redundancy for economical reasons (e.g.
Spare – ACE).
Low failure impact along with expected reliability means that it is unjustified to provide
additional redundance (redundance becomes more expensive the closer it must be
implemented to the line (HW) which itself is not redundant!)
Spare replacement is applicable to CEs with spare redundancy. Spare replacement can be
triggered on different conditions.
When internal or operator requested actions decide to replace a certain CE by a spare or to

interchange two TCEs, the initial configuration is disturbed. The return to the initial
configuration consists of the replacement of faulty ACEs by spare CEs and interchanging
TCEs which are not in their initial configuration.
The ALCATEL 1000 S12 exchange is in its initial configuration after a System–Start–Up or
when a special MMC–Command is successfully executed. In the meantime the configuration
can be changed by the operator or by autonomous maintenance actions.
Initial configuration means that the function of each CE, fixed to a so–called logical CE
identity, is stored at a predetermined network address, the physical CE–identity. Due to
spare replacement, the logical CE identity and thus the function of a CE can move to
another network address within the same exchange. The initial configuration is then
changed.

1.
Figure 365 : Operational modes of control elements.
Standby concept/characteristics
Duplication Each duplicated control element is loaded with

/Active/Standby) the corresponding user software and constantly
(A/S) updated (with data). In case of faults, a fast
switchover is possible.
Spare pool A spare control element (spare CE) is NOT yet

loaded with the corresponding application soft-
ware. In case of an error it must first be assigned
to the failing exchange control element type (re-
configuration/reloading is necessary) This is
called takeover
Simplex (SI) No redundancy

2 X Simplex (Act/Act) Duplication, both active (e.g: module for clock

signals and tones), quickest switchover.
Loadsharing/Spare The load is divided between several equivalent

Lo/Sp control elements (with the same or even different
data). If one unit fails, the spare CE takes over.
Loadsharing/ Several equivalent control elements share the

Active/Standby load, each being protected by a standby CE.
Lo/A/s
Crossover Duplication of TCEs especially for subscriber

connections.
Normal operation: both modules are simplex.
In case of failure (failure of a control element,

CE): takeover of the connection traffic by the re-
maining CE.
9.4.5 Automatic error handling
With regard to:
- Rapid detection of the occurrence of a fault
- Analysis of the detected fault
- Isolation of the fault
- Alarm signalling about the fault

1.
- Detailed fault reporting
A fault can be either a software or a hardware fault. For software faults we assume the
correctness of the own program, so a check must be done on the data used . The program
denotes the software package running in the control element where the fault occurs. The
data used denotes the data stored in the local database DLS or the data retrieved from
incoming messages.
- Faults will be identified by
– ERROR TYPE
i.e. every failure gets a number and is attached to an Error Class
– ERROR CLASS
more detailed description of the kind of fault, e.g.:

• HW fault
• SW fault (OSN, application program)
• Notify only to operator
- Rapid detection of the occurrence of a fault. The rapid detection of the occurrence of a
fault is necessary to avoid the degeneration of the exchange call carrying capacity. Fault
conditions on hardware can be detected by monitoring the hardware devices, periodic
scanning, performing read after write checks when giving commands to the device, or
checking completion codes, or interpreting the interrupts received from the device. These
checks are performed by the responsible Device handlers.
- Analysis of the detected fault. The fault analysis will be done on different levels. The
lower level is in the control element where the fault occurs. This is part of the
decentralized maintenance functions, the responsible modules are called ERROR
HANDLER (Part of the OSN) and the LOCAL ERROR ANALYZER (LEA). On this level
some recovery actions can also be done. The higher level of error analysis takes place in
the DFCE control element (centralized part of maintenance functions), which has to
decide on the action to be taken (e.g Internal Disable, Internal Verify,...)
The following autonomous recovery actions (”recovery level”) are possible:
1. No recovery (autonomous)
2. Abortion of process that causes the problem
3. Takeover to active (RAM Restart)
4. Restart (ROM Restart)
5. Reload (Bootstrap)

1.
Transfer of information to centralized maintenance – SW
No recovery action CE restart

or process abortion or CE bootstrap
Anomaly report to centralized Restart/bootstrap buffer to centralized

maintenance SW for further errormaintenance SW (after restart/bootstrap is
handling executed and end–of–restart message
is sent to centralized maintenance SW)
- The choice is determined by the error class and the fault origin
– In each case the central maintenance part in the DFCE will be informed.
– Overflows between the recovery levels are possible (by using timers, threshold
values)
- Isolation of the fault

For hardware faults, the fault has to be verified, the faulty equipment has to be isolated so
it will not be used any more by the call handling actions of the exchange and the operator
must be warned because the faulty equipment must be repaired and replaced by properly
functioning equipment.
- Alarm signalling about the fault

Alarm signalling is necessary to warn the operator of the occurrence of a fault, which will
be done by an audible tone and a visual indication on the master alarm panel.
- Detailed fault reporting

A report with all details of the fault will be printed on the system printer to give the
operator all the parameters needed for the action to be taken.

1.
Figure 366 : Main functions of maintenance
MAINTENANCE
Preventive Corrective
Maintenance Maintenance
Scheduled RT Manual RT Autonomous Manual actions

by the system by the operator actions by the operator
Calendar
scheduler in Schedule plan Self monitoring error treatment
the system automatic error
handling
RT on devices Maintenance actions

(different device types) – on SBLs, except CTLE
– on SBL–type CTLE

1.
9.4.6 Corrective maintenance
Figure 367 : Corrective maintenance

SELF–
PERMANENT SELF–MONITORING MONITORING
ERROR
ERROR DETECTION
Error reporting to
Local Error Analyzer
ERROR ANALYSIS (LEA) AUTOMATIC

ERROR
After Analysis DFCE HANDLING
will be informed
SYSTEM DEFENCE
DFCE decides which action

has to be performed
ERROR LOCALIZATION (DT)
After completion of the autonomous

action the operator will be informed
by a detailed system report
SYSTEM REPORTS
SYSTEM REPORT
TO THE OPERATOR
A specific task has to be
performed by the operator
REPAIR ACTION OPERATOR TASK
a. Corrective maintenance by maintenance personnel
Repair of an exchange is necessary in the following cases:
– for errors detected during preventive maintenance of input/ output devices or other
operator actions (”Error correction due to malfunctions”)
– Error indications after routine tests automatically generated error reports (alarms)
– Error indicators for connected exchanges/subscribers (”Error handling due to

external messages”)
The following tools are available for handling the errors:

1.
– Diagnostic test protocols and/or
– TP/DP (Area: C = corrective maintenance)
With the help of these it is almost always possible to replace the replaceable item
suspected of error or to remove the error by readjusting mechanical items.
Procedure upon receiving a corrective maintenance task
Figure 368 : Corrective maintenance task
Repair Task
Task List O&M : TL(C)
Task Procedure O&M : TP(C)
O&M : DP...
USI
Detailed task description
O&M : Lists
and Tables
Additional lists and tables
O&M : Report
descriptions
– Routine Tests. They run periodically under system control or upon operator request.
Routine tests are intented to check the functions of devices in traffic (call handling is
not affected). (No influence on traffic).
9.4.7 Alarm system
Objective:
To make sure that in case of certain fault conditions the maintenance personnel will be
informed.

1.
Such faults, leading to an alarm, are handled in a specific way by special HW and SW parts.
==> Alarm system
a. Alarm type / Alarm groups
In order to distinguish the variety of possible alarm conditions the following is defined:
Alarm type:
Identified by: Name or identification number (e.g. CONV/43)
As certain alarm types will be treated by the alarm system in an identical way, several
alarm types are organised in an
Alarm group
Main alarm groups (defined in the Support information):

– Module alarms (Converter failures)
– Rack alarms
– General alarms
– external alarms (e.g. rectifier alarm, power failure, Master Alarms Panel)
– internal alarms related to AC FMM (e.g. overflow of alarm category or alarm list)
– SW alarms (e.g. malicious call)
– Miscellaneous alarms
– SBL alarms
– CE concerning (CTLE)
– other SBL Alarms
– SBL alarm: SBL state = FLT/FOS alarm on SBL state = IT alarm
– SBL group alarm: If the number of SBLs of the same type (e.g. digital trunk
channels, asynchr. I/O–devices) being in the state faulty exeeds a certain
threshold value, a SBL group alarm of a higher category than the single SBL
alarm is issued.
b. Alarm class / categories
Information about the urgency of an alarm :
– Disabled

1.
– Print only
– Non urgent (not critical)
– Urgent (critical)
Every alarm has two categories (Alarm Category (ALMCAT) and a reduced
category (REDCAT)). The purpose is to implement an easy ’category switch’ at a
certain time of the day. E.g. during low traffic hours some alarms are not as
important as during high traffic hours, so the corresponding category could be set
lower.
The appropriate maintenance action to be taken by the operator personnel depends on

the urgency and the operational administration concept.
c. Alarm indicators
The most common alarm indicators are:
– Alarm panel
– System printer
– LED on PBAs (on CLMA–PBA)
– Alarms sent to Network service centers (NSC)
d. Components and functions
– The alarm system is part of the implemented exchange maintenance functions
– It can be attached to the following basic functions:
– Fault detection leading to alarms (alarm detection)
– Handling of alarm reports issued via alarm indicators
– Alarm causes can be HW or SW related.
– For implementation of the described tasks the alarm system consists of:
– Alarm HW Components (PBAs)
– Alarm SW Components (FMM / SSM)
e. HW–Alarm–Reporting Chain
HW–alarms are detected by two different Device–Handler(DH)–types, the

Rack–alarm–DH and the Central–alarm–DH.

1.
The established alarm condition is signalled to the error handler by the DH by means of
an ERROR_REPORT. The error handler sends a message to the DFCE via LEA.
The information on the alarm condition detected by the DH is then supplied to the FMM
Alarm Control (leads to an alarm output).
There is an acknowledgement mechanism via a DB relation in order to inform the DH

which detected the alarm condition that the message has reached Alarm Control and
that corresponding maintenance actions will be carried out.
To clarify this, the acknowledgement process for a HW–alarm is described below.
Figure 369 : Example: HW–Alarm reporting chain

HW Alarm Inputs
Alarm report to IO system
1 Indicators (e.g: Master Alarm Panel)
6 4
Rack/Central ALARM R_ALRECE
Alarm device DATABASE CONTROL

Handler SSM
List of active
8 7 alarms
Indicator located in P&L
Drive Message
9
Rack/Central
Alarm device
5 Handler FMM 5
2 Error reported to Alarm report to

the ERROR HANDLER alarm system
(ERROR_REPORT)
3
in every CE
DFCE
Anomaly
report DFCE
ERROR LEA Maintenance
HANDLER
to DFCE FMMs
Example of alarm treatment:
The general treatment of an alarm condition is described in the following scenario:

1.
Figure 370 : Scenario

RACK ALARM ALARM DH DATA BASE EH/MAINT. ALARM CONTROL
PBA SW SW SW FMM
1. Alarm–PBA is scanned for Alarm Inputs

1
2. Change of Alarm Bit State is reported to ERROR–HANDLER
2
3. Maintenance Software sends Alarm Report
3
4. Alarm Control Software acknowledges Alarm Report and changes the
indicator states.
4
5. Alarm DH Software is told to read DATA BASE

5
6. Alarm DH Software requests Indicator data from DATA BASE

6
7. Alarm PBA is told to activate Indicators
7
8. Alarm DH Software requests Alarm acknowledge data from DATA BASE
8
9. Alarm bits not acknowledged are reported again
9
Explanation of the individual processes:
Alarm–PBA is scanned on a cyclic basis for changes in the input states by the
alarm–DH–software (64 alarm–bits).
If a change in the input state is established, the alarm–DH–software generates an

alarm report (alarm=on, alarm=off), which informs the Error Handler (EH) about
the change
The EH sends an error report message to maintenance software. The latter in turn
generates an alarm report, which is sent to alarm control software.
Alarm control evaluates alarm reports, enters the alarm in the database and
generates a new state pattern for alarm indication.
ALC then informs the alarm DH software that a change in the alarm indication
state has occured and that this is available from the database.

1.
Alarm DH software fetches the corresponding data from the database.
Alarm DH software switches the alarm indicators on the alarm PBA in accordance
with a new state pattern.
The alarm DH SW checks whether alarm control has acknowledged the alarm
report within six minutes after the error report was sent to the error handler (step
2).
If there was no acknowledgement, the error report (step 2) is sent again.
– Device Handler for Module and Rack Alarms (Rack Alarm DH)
Software is resident in the modules which have a corresponding RLMC PBA (2

per rack)
Scanning of the connected HW signals (voltages, clocks ...)

In case of alarm the respective error handler is initiated
The error handler sends a message to the Defence Processor, whose alarm
control initiates the further procedure. (Printout on printer, alarm indicators).
– Central Alarm Device Handler / Master Alarm DH (CAL–DH)
Software is resident in P&L
Driving the functions of the Central Alarm PBA (CLMA)
Scanning for external alarms
In case of alarm triggering of the Alarm Control FMM or the Error Handler
(depends on the Alarm type) and triggering by the Alarm Control FMM for
indicator driving
– Alarm Control FMM
Central SW module within the Alarm system SW
Software resident in P&L
Analyses the alarm event in the arriving messages and alarm identification
Controls the appropriate alarm treatment (data–driven)
Generates commands to switch on alarm indicators
On request, display of an active alarm at a specific time
On request, removal of a redundant active alarm from the system

1.
On request, display and/or modification of an alarm category of a specific alarm

type
– Alarm identification
* Alarm identification by
– Alarm type
– Alarm group
– Alarm address
– Routing of alarm reports
It is possible to route special Alarm reports based on Network address, Alarm type and
Alarm number to certain output sets. The operator is able to modify the ’normal’ Alarm
routing .
9.4.8 Preventive maintenance

Preventive maintenance for an exchange encompasses manual activities which must be

carried out according to a fixed schedule to avoid failures in the hardware.
– Objects for scheduled maintenance
– Peripheral devices
– Exchange devices (telephonic devices, system devices,...)
– Tools
– Routine test programs (manual or automatically started)
– Built in HW–self test (after power on)
– device manuals
– Directions
– proceeding according to operation and maintenance guide (O & M–Manual: Task

area (S))
– schedule: depends primarily on customer administration
– recording of the activities
a. Routine test
– Method of fault detection for preventive maintenance
– Functional tests of devices, not related to SBLs

1.
– Necessary: some Test recources
– Fault detection with test result restriction: GO/NOGO
– For functions not monitored by on–line or alarm supervision
– No operational disturbance as it runs only when devices are not under traffic (low
priority level) Important: starting the routine test is only possible on SBL–state IT!
– Periodically scheduled automatically by the system itself or once called by operator.
– Execution with help of overlay test programs (TEX–FMMs=TEST EXECUTION) and

possibly some Test HW (TAU, TSA).
Telephone exchanges require a minimum amount of test and preventive maintenance

tasks, which have to be performed in definite time intervals (”Scheduled
Maintenance”)
b. Scheduling
Information about scheduling intervals, given in tables, are recommended values and
can be changed on the basis of operational experience gained during system
operation.
– Possible time intervals (I/O–Devices)
– yearly
– monthly
– weekly
– daily
– Recommendations about time intervals
– In appropriate preventive maintenance TP for the specified device (O & M

Manual)
––> scheduling plan
– Scheduling
– Manually triggered by personnel when a fault is suspected.
– Automatically triggered (once, periodically) by system according to current

scheduling plan (normally already on SLT!), mostly during low traffic period
– monthly, weekly, daily

1.
– Change possibilities
– When required, change of the scheduling plan by operator commands (MMC)
– Manually triggerable of a routine test or premature abort by MMC
– For every routine test a total result is output
9.4.9 Summary report for all scheduled routine tests
It is possible to start a routine test (scheduled!) for the whole number of devices in the
network (Device–Type: NETWORK). This test will run a very long time, (dependent on the
number of devices in the network) and will produce a lot of system reports with the results of
the test. Therefore a number of Commands have been created to make it easier for the
operator to check those results by using a so–called test summary report. This summary
report includes the
– Test number and device type
– number of devices to be tested
– number of devices witout fault
– number of faulty devices
– number of busy devices, untested
– number of untested devices for other reasons (for example: no test resources
available)
- Preventive Maintenance for peripheral devices
– include manual activities by maintenance personnel
– tasks like functional checks, cleaning, adjustments etc.
Examples of peripherals:
– VDU
– VDU on PTCE
– Line printer
– Magnetic tape unit
– Master panel for alarms

1.
– Preventive Maintenance Activities
– Kind of device checks:
– Visibility check
– Functional test
– Built–in self test
– On–line check
– Kind of activities on the device:
– Cleaning (box etc.)
– Lubricating (moveable mechanic parts)

– Adjusting (write/read head etc.)
– Replacement of used up parts (filter etc.)
– Additional activities:
– Make a protocol
– Possibly repair the device*
If during preventive maintenance a malfunction is detected whereby the device must be

repaired, then a corrective maintenance action has to be performed, e.g. replacement
procedure. ”Error correction due to malfunction”
– Principle task procedure for preventive maintenance
– Prerequisites:
– Follow O&M–Manual (TL, TP, DP etc.)
– Preparation of aids
– Make a protocol (related to the device)
– Establish a definite SW state (SBL related)
– Establish a definite HW state (Device related)
– Important notes:
– Set the devices in or out of operation only in accordance with to the instructions
– Take notice of notes and precautions

1.
Figure 371 : Preventive maintenance
Preventive Maintenance
Task
Task List O&M : TL(S)...

Task Procedure
O&M : TP(S)
Scheduled Maintenance
Detailed Procedure O&M : DP

USI–Manual
Additional lists and tables O&M : Lists and
Tables (Support
Information)
Device Manuals
Manuals
Execution
Functional no,
Error ok
yes
Error correction by
maintenance personnel
(Corrective Maintenance)

1.
10.OPERATING AN A1000 S12
10.1 IOS overview
10.1.1 Introduction
The Input/Output System Software is a part of the Alcatel 1000 S12 Operating System and
its evolution is specified by the so called System Kernel Release (S.K.R.). An example is
shown in figure 372.
It interfaces to the common Operating System modules, especially the Operating System
Nucleus which always runs in the background for support of resources such as processor
time, memory space and timer, and the internal communication interfaces such as the
Message Handler, Network Handler, Cluster Handler, Message Interface, etc.
For data access the IOS needs help from the Data Base Management System.
With the above mentioned support the IOS acts as a SW interface for communication
between the operator with his peripheral devices and Alcatel 1000 S12 application
programs, to enable him to maintain and administer the exchange for fulfilling its task of
connecting subscribers by phone calls.
The IOS is the interface between the application programs and the peripheral devices for file
access to get, store, modify, create or remove data if necessary, e.g. charging information.

1.
Figure 372 : SW specification for A1000 S12
System Kernel Release :

S.K.R. 7.1
HW–family (J–family)
Operating
System
HW+ +
Firmware
Data Base
Evolutionary Call Handling (E.C.)

Software Package
10.1.2 IOS functions
The main tasks of the IOS are to support the operator facilitaties for exchange administration
jobs such as:
- File Administration
- ORJ Control and Scheduled Job Administration
- Command Administration
- Report Routing
- Password Administration
- Peripheral Device Administration Magnetic Tape and Optical Disk Handling
- Hard Disk Synchronization
- Device Anomaly Handling

1.
- Time and Date Administration
- Backup Generation
- Logging
Besides these tasks the following functions are performed by the IOS:
- Device Control
- Report and Command translation and queuing
- File synchronisation and recovery
- Translation between application programs, which have a logical view and the peripheral
devices which have to be accessed physically
- ’Twin’ and ’Fallback’ Device Organization.

For all these duties the IOS consists of some FMMs and SSMs (with specific communication
interfaces (MSGs) and influencing several control relations.)
The I/O System (IOS) connects the user software inside the exchange with the computer
peripheral devices. There are mass storage media like optical and magnetic disks, and
magnetic tapes. There are also the devices connecting the exchange with the outside world
like the VDU, PC, printer or the modem for connection to remote devices.
Input/Output–System tasks (see figure 373):
- File Oriented tasks,
- Man Machine Communication (MMC) tasks
On the one hand, the user software inside the system requires access to data residing on
mass storage devices and it also writes data to the printer or the VDU. Since the data is
organized in files, these actions are called file oriented tasks.
On the other hand, the MMC tasks handle all the communication between the supervising
personnel (operators) and the exchange. Operator Requested Jobs (ORJs) are
submitted via the IOS to the responsible command handler software, which performs the
required jobs. The command handler software or any other user software module informs
the operators by submitting a report to the IOS. The IOS routes it to the desired
peripheral devices.

1.
Figure 373 : IOS functions
file oriented interface MMC – interface
logical :
– file, record – CRN
– device application – RRN
– ID ”USER” – JSQ
– ... programs
– ...
report MSG

ORJ

PSW and syntax

check, translation,

report routing,
device control,...
PSW,
command
read,
write,
modify
report
Physical:
– NA
– block
– name
– ...
– command syntax
or form
– report layout
– input/output device

10.1.3 Overall structure
The software for the Input/Output System is mainly located (see figure 2–3) in the Peripheral
and Load Module (P&L). In addition, there may be another module, the Administration
Support and Peripherals Module (A&P), which relieves the P&L and of which more than one

1.
pair may be fitted to an exchange, for a Network Service Center (NSC) or an additional
Operator System).
One main task of the Input/Output System software is to translate logical data into physical
data and vice versa between application programs (users) and the peripheral devices.
The user’s view of the IOS is a logical one. The user software must specify three attributes
to get access to the data.
Logical view :
- Logical device
- Logical file
- Logical record.
A logical device is where logical files reside. It hides most of the properties related to the
physical device which it represents. Logical devices may be one of two types:
- Single device, which defines one primary and one additional fallback physical device
- Twin device, which maps two physical devices onto one logical device.

1.
Figure 374 : Logical and Physical View of the IOS
A&P standby
A&P active
P&L standby
P&L active
IOS
IOS–MMC–
interface
”user” general
remote IOS_utilities
peripheral
(application
program)
I/O devices
interface
IOS–file
oriented
interface
log.device device type

network address
device number
log.file phy.file
log.record phy.record
A logical file is a collection of logical records. It appears to the user as a contiguous

information space in a linear arrangement (a string of adjacent records without gaps and
branches).
The logical record defines the minimum amount of data which can be transferred at a time.
The I/O System maps the logical items onto their physical equivalents. For each logical
device, one or more physical devices are defined in a device assignment relation
(DASSIGN). On the physical devices, the logical files have their equivalent in physical files,
as have the logical records with the physical blocks. This assignment is treated by the
responsible file handler software.

1.
A physical device is identified by its type, the particular control element to which it is
connected, and a device number by which distinguishes it from several devices of the same
type connected to the same CE.
Device types :
- disks
- magnetic tapes
- printers
- VDUs
- binary devices
- virtual devices.
The logical view will be mapped step by step onto its physical representation (see figure
375). The user software must specify only the logical items. The general remote I/O interface
maps the logical device to the network address to which it is assigned, the device type with
the responsible file handler and the specific device number. The next step is performed by
the responsible IOS interface which locates the physical file on the device and accesses the
data in physical blocks.

1.
Figure 375 : Functional Block diagram of the IOS

job
management
logging MMC– autorisation

translation check
report
routing
”user” Device
(application general remote
Control
program) I/O–interface
peripheral
devices
file
management
IOS utilities
(support functions)
10.2 Hardware configuration
The hardware independent software (the I/O System software, will be considered in this
document) run in the MCUB of the P&L or A&P. When an action must be performed to drive
the peripherals, this hardware related action is ordered by the MCUB, which will pass the
responsibility to the DMCA. The firmware of the DMCA executes the desired peripheral
oriented job. The peripheral processor of the DMCA and the I/O processor of the MCUB
communicate via the multimaster bus (see figure 376). The mass storage media are
connected via the SCSI bus to the DMCA. The SCSI bus supports up to 8 device units:
- 4 disks (magnetic and optical)
- 2 DIL adapters with up to 16 magnetic tape units
- 1 streamer
- the DMCA itself
Two serial devices are connected to on–board channels 1 and 2 of the DMCA. Via the
peripheral bus up to 4 MMCA boards can be connected to channel numbers 9....24).

1.
Figure 376 : IO HW configuration
64 ALARM INPUTS
RLMC 4 rack alarm lamp driver outputs
MCUB
16 EXTERNAL ALARM INPUTS
TO
DSN TERI CLMA 20 LAMP DRIVER OUTPUTS
2 remote lamp outputs
FROM PART
C&T ITF inter CLMA link
80386 MULTIMASTERBUS
.. .. DMCA
system printer
3 .. .. MTUF
system VDU
4 0 SCSI BUS PERIPHERAL BUS
5 .. .. MTUF DIL
DIL
8844 02
.. ..
6 1 8844 01
9
7 4x
SYSTEM DISK
8 MMCA0
12
MAGNETIC 06
13
MAGNETIC
OR 4x
OPTICAL
DISK
MMCA1
16
05
17
MAGNETIC
OR 4x
OPTICAL
DISK
MMCA2
20
04
21
MAGNETIC
OR 4x
OPTICAL
DISK
MMCA3
24
03
STREAMER
00
The P&L and A&P modules are always duplicated and the pair works in active/standby
mode. This means that when the active module fails, the standby module will take over
without loss of service.

1.
It will, however, not be possible for a certain side of the P&L or A&P pair (active, standby) to
reach a peripheral as long as it is not connected to that side. Using shared devices (see
figure 377) solves this problem for MMC peripherals connected to the MMCA or DMCA
boards. This means that one serial device is connected to both sides, to the active and
standby side. So it is possible to reach this peripheral from both P&L modules. Only the
active member of the P&L pair has the right to use the shared device. Each serial channel of
the DMCA and MMCA boards may be of shared or private configuration.

1.
Figure 377 : Shared Devices
Optical
Disk
Magnetic
Disk
Formatter
DIL– Tape
adapter
Printer O&M
Terminal
Peripheral bus
SCSI bus 16 Printer O&M
15 Terminal
MMCA 14
13
12 O&M
11 Terminal
MMCA 10
9
Printer
2
DMCA
1
ext. Alarms
Multimasterbus
CLMA MAP
MCUB Printer
RLMC
DSN Rack Alarms
RLMC
O&M
Terminal
MCUB
CLMA MAP
Multimasterbus
ext. Alarms
1
DMCA
2
Printer
9
10
MMCA 11
12
13
14 O&M
MMCA 15 Terminal
16 O&M
Printer Terminal
O&M
Printer Terminal
Formatter
DIL–
adapter Tape
Magnetic
Disk
Optical
Disk

1.
10.3 File–oriented interface
10.3.1 Introduction
All manipulation of information via the IOS file–oriented interface is bound to the Logical File.
Transfers (read, write) occur within boundaries of that file for which exclusive ownership is
granted.
Within a file, the subunits of information handled during data transfer are Logical Records.
The IOS maps the logical items onto their physical equivalents:
- For each Logical Device, one or more Physical Devices are defined in the IOS data. On
the other hand, one or more logical devices may be assigned to the same combination of
physical devices.
- On the Physical Devices, the Logical Files have their equivalent in Physical Files, as well
as the Logical Records with the Physical Records. (Blocks)
The IOS has a remote part in each Control Element, which needs file access (to store,
remove or modify data or for data requests), that means an application program resides in
such a CE, which uses the file–oriented interface of the IOS via a general remote I/O
interface. This remote interface is responsible for translating the logical device given by the
user into a physical or logical device with the help of an assignment list. With the physical
information the IOS can be accessed in the responsible P&L (or A&P).
The next job for the IOS is to check the availability of the destination device and file to
access the requested data in the correct way. This way the functions of device control and
file management are covered by the IOS.

1.
Figure 378 : File oriented interface of the IOS
Which physical device(s)

stand behind the given logical device–ID Is the physical device equipped,
Device Status available, in traffic,...
Log. Device Device
List Characteristics
... ... peripheral
How is the
requested physical device
devices
defined (type, protocol,
configuration,...)
”user”
(application general remote file access device
program) I/O–interface data transfer control
file management
& recovery
mechanism
file
directory
file status
file description
Where is the logical file

physically stored (blocks) ?
Is the requested
file available, uncorrupted,...
How is the requested file
defined (length, type, access,...)
10.3.2 Logical file
A Logical File in Alcatel 1000 S12 is a collection of Logical Records identified by the
combination of a Logical File Identity (a number) and the identity of the Logical Device on
which it resides. It appears to the user as a contiguous information space in a linear
arrangement.
A file is viewed as a sequence of consecutive logical records.
The size of a Logical Record is defined in the File Descriptor Block (FDB) of the logical file
and can range from 1 to 2048 bytes. The record is numbered inherently by its offset from the
beginning of the Logical File, the ’record offset’ (see figure 379).
For each Logical File to be used in the system, a logical and physical file description (record
size, access type, data type, authorization, maximum length, etc.) has to be set up and
maintained for on line use. This information is part of a File Descriptor Block (FDB). The
FDBs of all files in the system (max. 5000) are combined to a common directory called the
File Descriptor Table (FDT) which is itself a Logical File in the system.

1.
The FDT is produced off line and it knows about all files that are possible in the system (per
definition). For all files an entry is available in the FDT. When a new file is introduced, this
predefined entry is modified. For this purpose, a utility is provided to enter new items into the
FDT. Similarly, file descriptors may be deleted or (in a restricted manner) modified. For each
file access the relevant FDB must be read by the IOS to prevent the file from being misused.
An important part of the file description is the time constraints put on to the access of the
Logical File, which is supervised by the IOS.
Figure 379 : Logical File
logical view of SW
file 1 file 2 file 3 . . . file n

0 0 0 0
1
1 2 1
2 3 2
3
1
4
6 record
length
record offset
In addition to administering the file definitions in the file descriptor table, the “file
management” of the IOS has to check the actual file status in the file status list to see if it is
available on the given physical device or not. There is an entry for each file, which is either
held by another user or intended for a recovery action or left in an abnormal condition by the
last user. If the file access is not allowed, the IOS gives an error message back to the
requesting user. The operator can display all entries of the file status list or just some
statistics of it.
10.3.3 Logical device
The view of an Input/Output Device to the file oriented user is a Logical Device. This is
where Logical Files (see before) reside, and it hides most of the properties related to the

1.
actual Physical Device which it represents. In Alcatel 1000 S12, a Logical Device may be
either:
– a Single Device or
– a Twin Device.
The Single Device defines a Physical Device for primary use (Primary Device) and,
optionally, one or more Fallback Devices to be used when the Primary Device has failed.
Also optionally, a Logical Device may have a default Logical File associated with it. As a
result, the user can access a file with the specification of the Logical Device alone.
The Twin Device (only for mass storage media, usually the disk) maps two Physical Devices
onto one Logical Device to achieve secure information storage and/or transfer. This
duplication is invisible to the user FMM. An exception to this is when one of the twin devices
is not available. In this case the user receives a warning, indicating that the write operation is
only performed on one device. The user does not need to take notice of this warning,
because the IOS starts an automatic recovery action during which the write operation is
performed on the second twin device.
Such files, which reside with the same definition in the FDB and the same contents on two
physical devices as one logical twin device are called “Twin Files”. Twin files are marked with
a recovery flag in the FDB. The file management of the IOS is responsible for synchronising
the twin files.
Write, modify and remove operations for a twin file will be performed on both Physical
Devices simultaneously. Even if one of the two is unavailable, the Input/Output System will
allow the operation to continue (entry in the file status list). When the device becomes
available again, a recovery action will be performed for the file by the file management of the
IOS.
- SOFTINIT
Synchronisation of files stored in the file status list by periodically scanning the list or by
request.
- HARDINIT
The operator can trigger a Softinit for all twin files by a Hardinit and can display the
actual status periodically.
- Emergency Recovery
To save twin files with an entry in the status list before taking one device out of service.
- Sector Recovery
To save twin files from physically destroyed sectors.

1.
Read operations from Twin Device will be performed on either of the physical devices.
10.3.4 Physical and virtual devices
From the user’s view, there is no difference between Physical and Virtual Devices.
A Physical or Virtual Device is identified by its type, the particular Control Element (CE) to
which it is connected, and a number which distinguishes from several devices of the same
type connected to the same CE. The combination of device type, network address and
device number is called the Physical Device Identity. The following list is an extract of the
actually available physical and virtual device types:
DEVICE TYPE DEVICE TYPE NUMBER
DISK 1
MAGTAPE UNIT 2
PRINTER 4
VDU 5
BINARY DEVICE 7
MPTMON 130 (virtual device)
REMOTE MMC 131 (virtual device)
DISK INIT COMM FACILITY 135 (virtual device)
The term Physical Device refers to what is connected as a peripheral to a control element for
communication with human beings (VDU, BINDEV, printer), for mass storage and/or
transport of machine readable data (disk, magnetic tape), or for communication with systems
outside the exchange environment (remote links to devices or EDP centres). A Virtual
Device can be defined as a process (an application of an FMM) which looks as if it provides
access to a real computer peripheral. A Virtual Device can be used for inter–processor
communication (e.g. DICF or MPTMON).
For each device access the device control of the IOS has to read the characteristics of the
relevant physical device, which are defined in a list. The operator can display and change
these characteristics for HW modifications. Device type, protocol, (baud rate, parities),
configuration (with or without modem/shared or private), the whole interface peripheral
device/device driver must be specified for each physical device. A second list permanently
presents the actual device states.
A device can be
– unequipped (no HW)
– unavailable (out of service)

1.
– available (free, busy or passive)
For operator devices automatic–in–service–routines exist, meaning that the IOS will
periodically try to bring them in service again.
For mass storage media with random access (disks) a file directory resides on it to translate
the logical file into a “physical file”, i.e. to find the different parts of the file (records) on the
correct blocks (sectors, tracks) distributed over the physical device. This directory
administers the free space of the device.
10.4 The MMC interface
10.4.1 Introduction
The Man Machine Communication (MMC) software is a part of the I/O System and provides
communication between supervising personnel (operators) and the exchange (see figure
380). It forms a component of the interface between the man machine terminals (Visual
Display Units, printers, ...) and the software application programs. The application programs
(users) perform the functions requested by operators and/or generate automatic reports.
Communication between an exchange and the operators is divided into two parts:
- dialogue Handling, or the command interface:
ORJs are entered via the terminals to request the desired functions. Responses
are generated by the MMC software to make the dialog. These responses are not the
result of the functions being performed, but are related to the initial input data.
- monologue Handling, or the report oriented interface:
Output messages like reports and alarms are generated automatically, either as a
result of a previously given ORJ (solicited report) or as an indication of events detected
within an exchange (unsolicited report). Each report or alarm is identified by a unique
number, the Report Reference Number (RRN).

1.
Figure 380 : Communication with A1000 S12
DIALOGUE
ACTION
FUNCTIONS
ALCATEL 1000 S!2

OPERATOR
REACTION
EVENTS
MONOLOGUE
LINE PRINTER ALARMS
REPORT
SYSTEM 12
MASTER ALARM PANEL
10.4.2 MMC–dialogue–interface
The operator initiates a dialogue session by sending a ’BREAK’ to the device control of the
IOS. The device control identifies the input device and prompts the operator for a password.
When entered the password is not displayed on the screen.

1.
The authorization check looks for the password in a password list. There are two possibilities
for this list : the passwords are either stored as mnemonics (a password consists of up to 8
characters and is taken as it is entered) or encrypted. In the second case a password
consists of at least 6 up to 12 characters and has to be encrypted before the list is accessed.
The password must be unique in this list.
The password list consists of 999 possible passwords. To each password a set of command
areas is assigned. All acceptable commands are distributed to 128 different command
areas. Further the authorisation check controls a second list, which assigns a set of
command areas to all possible input devices. The combination of both gives the list of
commands for which the operator with his password and input device is authorized.
If the password is found in the password list the IOS sends a dialogue header, containing the
exchange name, date, time, day of week, the physical address of the input device and a
logical password identification (internal password index as a pseudo–user–ID) back to the
input device and prompts for a command input. Otherwise the dialogue session is
terminated with an error message.
Then the command input is checked to determine, whether the authorization is given for the
actual session. A command list gives the responsible command area for all acceptable
commands. For all other inputs the session terminates with an error message.
To perform the syntax check and translation of the ASCII input into binary format, which is
understandable for the system SW, the dialogue data is accessed. Each command area is
handled in one disk file. A directory of all dialogue files is written in the prologue file. Each
file access is performed by the IOS file oriented interface. The MMC translation sends a
prompt for all missing mandatory–parameters to the input device. The response of each
input is taken from a response list. A command can have up to 63 parameters and several
arguments per parameter.
After the correct command input is completed, the job management creates an ORJ by
performing an entry in the actual joblist to administer the job. The entry consists of the job
sequence number (job counter, which is incremented by one for each new job), date, input
device, logical password, index and the process ID of the command handler process which
is called to perform the task initiated by the given command. The job sequence number,
date, command reference number and the job state ’JOB SUBMITTED’ are displayed to the
operator.
After the translated command string is launched to the responsible application process the
semantic check is performed by the command handler (arguments valid). If no errors are
detected, the new job state ’RESULT DELAYED’ is updated in the job list and displayed on
the input device.
Beside this single command input procedure the MMC dialogue interface can handle batch
files. Files, stored on disk or externally, containing a list of commands. The compound
dialogue works through the batch file by performing the requested tasks sequentially. The
operator decides if the dialogue should be aborted or continue in case of an unsuccessful
job and where the results should be stored.

1.
Figure 381 : MMC interface of the IOS
What is the actual

job state of all all
status running jobs
list
...
Device Status
MMC–tables Device
& files Characteristics
job command
management
operator
Logging
general tables Device
”user” remote Logging and MMC– Authorisation
(e.g. command I/O–itf files translation Check Control
handler)
report
routing
Password
list
Log. ...
device is the operator
list with his input device
to which authorised for the given command
report output devices
routing should the given report be sent ?
tables
...
10.4.3 MMC–monologue–interface
The MMC–Monologue–Interface of the IOS performs all functions concerning the output of
reports to the desired devices. A report is a type of message launched in order to pass
information given Alcatel 1000 S12 to a human being. There are three types of report.
- Solicited reports are responses to operator requests. The report is defined by a certain
Report Reference Number (RRN) depending on the triggering command and belongs to
the created ORJ specified by the Job Sequence Number (JSQ).
- Unsolicited reports are messages without an external trigger. Their JSQ is set to 0,
because they are not ORJ triggered.
- Alarm reports are special unsolicited reports. They are treated with a higher priority and
signal the change of an alarm state (on/off) in the system.
All reports are routed via a general remote I/O interface in the control element of the sending
user to the IOS in the standby PLCE. First report routing launches the binary report
message to the MMC translation, which is responsible for translating data into ASCII and

1.
bringing it into a specific layout, depending on the RRN. All report layouts are stored in the
MMC monologue file on disk. The report is sent back to report routing in an easily readable
format for the operator.
The user sends an Output Set Identification with the report message to report routing for
individual distribution to several output devices, depending on the contents of the report.
Each combination of an RRN and an Output Set ID is linked to a group (report group) of
maximum 8 logical devices, which represent different output channels, with optional
alternatives such as fallback as defined in the device assignment list.
Additionally the report may, if specified in the routing tables, be sent back to the input device.
Further, the operator can specify an individual output device for each command by means a
special parameter.
If a desired output device is not available, the report routing queues the reports for later
output, depending on their priority.
A displayed report consists of a monologue header with the same contents as the dialogue
header of the triggering command, the JSQ, the result (successful or not), a repetition of
command and parameters, additional information about the result and the RRN. With the
RRN the operator can find further information in the Manuals to interpret the report. The ORJ
is deleted in the job status list, after the output of the final report to all desired devices.
10.4.4 Logging
The Logging subsystem provides a logbook of the MMC interface. All inputs and outputs of
the system SW via the dialogue or monologue interface can be stored in special files on the
disk. There are five different log types, which are handled separately:
– all inputs entered by the operator with his peripheral device;
– all commands accepted by the job management (with access rights and correct
syntax);
– all solicited reports;
– all unsolicited reports;
– all alarms.
For each type the Logging function can be switched on and the stored data can be
controlled and saved. Several search parameters exist to display the subsets of the logged
data.
– log type;
– time and data slice;

1.
– input device;
– LPN;
– CRN or RRN;
– exchange identification.
Any combination of the search parameters is allowed. The found subset of logged data for
accept commands can be executed again. All commands which are selected by the operator
are translated into ASCII and stored in a temporary file, which is handled as a batch file.
10.5 Exchange administration
The IOS provides several functions, called I/O utilities, for the operator to install his
administration environment, and to support the application SW with help functions.
A main task is to save the system SW periodically, so as to have an actual fallback in case of
a crash. There are two possibilities supported and described in detail by task procedures in
the Manuals depending on the destination backup media, which are optical disks or
magnetic tapes.
The amount of maximum 5000 files is divided into unchangeable files for the system load
part, and changeable files for the data load part; referring to the file type stored in the file
descriptor block. The two parts can be saved separately.
The operator has to administrate the volumes of the changeable mass storage media
(format, mount, etc.) for the backup generation. Further he can save logged data, charging
or statistic data individually. For this purpose file handling features are available. Single files
and the whole contents of mass storage media can be copied, and the file status and file
definition can be controlled.
Most of the commands can be submitted with a time schedule for later execution. Start date,
time of job execution and time period for periodically executed jobs can be specified. The
operator may control the job status and schedule.
In addition he can influence the report routing tables to decide which output devices should
display a certain report identified by its RRN and Output set ID. The logical device
assignment and the physical device characteristics are changeable and the device status
can be supervised by MMC commands.
Another important task is to prevent the system from misuse. Therefore, commands are
assigned to command areas, command areas to passwords and to input devices and
passwords to users (operators). Each device and each operator has an individual
authorization profile. Only commands belonging to specified tasks are accessible for the
operator, depending on his duties.

1.
The IOS utilities treat the system SW in a common way without referring to its telephonic
applications. They can be triggered by any program which needs help. General information
about the SW version and all SW parts are available. Load and initialization procedures are
supported, and recovery actions are performed.

1.

1.
11.ADMINISTRATION
11.1 Introduction
The Administration subsystem is one of the nine subsystems into which the A1000 S12
software has been divided. It occupies the highest level in the A1000 S12 software where it
is distributed within the different modules that make up the software.
Figure 382 : Subsystem interface
ADMINISTRATION
CALL HANDLING MAINTENANCE
TELEPHONIC
SUPPORT
OPERATING SYSTEM
AND DATABASE
CONTROL ELEMENT
HARDWARE
TELEPHONIC SWITCHING PERIPHERAL

DEVICES NETWORK DEVICES
(DSN)
This subsystem provides the software necessary for the exchange operation, that is, the
execution and support of all operational functions. This software executes the exchange
measurements and statistical functions including data collection and display and printout of
the measurements taken. Furthermore, this administration software manages the storage of
the measurements and other associated data on mass storage devices.

1.
This subsystem uses the other subsystems mentioned before to gather the data necessary
to accomplish its task.
The programs that make up the software of this subsystem are generally not critical in time.
The majority of these programs are therefore stored on disk and copied into the overlay
zones of the different CEs when required.
The Administration software is divided into the following areas:
– traffic performance and measurement collection;
– exchange management;
– network management administration;
– HW and SW extensions.
11.2 Traffic measurements collection and supervision
The A1000 S12 is capable of carrying out statistical and traffic measurements.
All main statistical events are continuously collected by the exchange software and they are
used to update a great amount of software counters. These counters are used to provide all
the different types of measurements that can be requested.
Measurements are intended primarily to determine the trend of carried traffic volume and the
grade of service, to obtain warnings of abnormal conditions, to investigate temporary
abnormal traffic situations, etc.
The types of measurements performed by the administration software are related to the
exchange type and customer requirements. These can be general statistics (e.g. number of
incoming terminating calls, number of hook–off events during a certain period), occupancy
monitoring, call sampling (e.g. call recording on one specific call in every N), observation for
different types of calls, CE load and overload measurements, etc.
11.2.1 Measurements based on statistical counters
The statistical system is divided into two different levels in order to perform its functions:
- Report generation level. This level is the interface with the operator and is active only
when the operator so requires.
- Collection level. This level is always active. The data collected by this level is used by
the control level.

1.
Figure 383 : System statistics structure
IO
SUBYSTEM
ACTIVATION PERIODICAL
INFORMATION
REPORT
OPERATIONS
GENERATION
AND
LEVEL
REPORTS DATA
REQUEST
COLLECTION
LEVEL
a. Collection level
The A1000 S12 system is continuously collecting data and updating counters. Local
Data Collectors (LDCs) are used to collect statistical data, and a Central Data Collector
(CDC) groups the data distributed among all the LDCs.
– Local Data Collector (LDC).
The statistical events are reported to the Local Data Collectors SW (LDCs) mainly by
the Call Handling subsystem. The LDCs update and manage the counters associated a
those events. This software LDC and the counters are located in the SLDCTRAs.
– Central Data Collector (CDC).
Most LDC counters are periodically collected by the Central Data Collector SW (CDC)
using a polling strategy. The Central Data Collector is located at a duplicated ADMCE
or PLADMCE. These data are summed up and stored in a centralized database.
The number of seizures per trunk, for example, is stored in the SLDCTRA related to the
specific trunk, while the average number of seizures per trunk group is stored in the
CDC. The counters are collected every five minutes for network management and
trunk monitoring functions and every fifteen minutes for general measurement
functions.

1.
Figure 384 : Collection Level
LINE TCEs SCALSV_1
EVENTS SLDCTRA_1
POLLING
TRUNK TCEs
ADMCE
or
PLADMCE
SLDCTRA_1
EVENTS
LINE TCEs
SCALSV_1 CENTRAL
LOCAL
DATA DATA
TRUNK TCEs COLLECTOR COLLECTOR
b. Generation report level

As previously mentioned, the generation report level SW acts as an interface with the
operator and uses the collection level to provide statistical data.
The interrogation of counters is performed by the Administration SW, which has the
interface with the collection level, LDC or CDC, depending on the type of
measurement.
The exchange statistics can be requested by defining a complex time pattern (different
days, different times, etc.). A schedule module is in charge of sending a message for
the different analysis periods. This message will start or stop the measurement.
It is possible for the operator to display the requested statistics at any time, obtaining
detailed information about the measuring plans under way.
This generation report level manages most of the system counters. It allows the
indication of several entities and several objects for each entity, over which to take the
measurements, in a single request. It is possible to indicate, the precise moment to
start and stop the measurements, the period of the measurements, and the device on
which the results will be output.
There may be several active requests at any given moment. The collection method
used the compatibility of each measurement. This is so because the method is always
cumulative and the values are calculated from the difference between the value at the
moment the measurement starts and at the moment it is given to the operator.

1.
Basically, this SW decodes the operator requests, it drives the starting and ending of
the collection periods, collects the values of the corresponding counters from the
collection level, and formats the monologues containing the requested counter values.
Figure 385 : Report generation level
REPORT
GENERATION
LEVEL
SCHEDULER
LDC
IO ADMINISTRATION
SUBYSTEM
DISPLAY
MEASUREMENTS CDC
Certain events are not collected by the usual statistical system because they have
special characteristics. These are referred to the overload of the Control Elements.
These events are handled directly by the Operating System. A special FMM is in
charge of these events. This FMM belongs to both levels, the collection level and the
report generation level, so it both updates counters it manages operator commands
while being in charge of the corresponding output reports.
Two main counters are provided:
– number of times an overload is encountered;
– duration of the overload.
11.2.2 Call observation
The Alcatel 1000 S12 SW contains an observation function to obtain an evaluation of the
quality of service performed by the exchange itself and the peripheral exchanges. This
function is started by an operator request. The results are supplied in the exchange in the
form of reports (VDU or printer).
Call observation in the Alcatel 1000 S12 involves three types of measurements:
- Signalling register
The measurements are performed on one selected trunk. Mainly, the signal
interchange between both exchanges through the trunk, the trunk identity, the service
circuit identity and the time are recorded.

1.
This function can be applied to any type of signalling CAS or CCS –ISUP, TUP, etc..–.
- Call sampling
One out of every N calls of a certain type (national, international, etc.) is sampled. The
sample provides an estimation of the traffic in the exchange, and determine the grade
of service for the basic and the supplementary services.
- Single Line Observation
All events that occur on incoming calls from local subscribers or trunks are collected.
The time at which each event occurs is also recorded.
The observation breaks down into three different phases: activation, collection, and output.
In the Activation phase, the SW modules in charge of managing the call observation are
activated by operator command. It is possible to start, modify or stop the call observation
using a set of ORJs directed to these two modules. When indicated by the generation report
SW, the Call Observation SW puts the lines or trunks in observation (or removes them from
this state), notifying the Call Handling SW. This subsystem determines which call must be
sampled and starts the transmission of the events to the collection level SW.
In the event collection phase, the call handling events relating to the observation types are
collected at the time at which they occur.
Finally, in the output phase, the module in charge of this function receives a buffer
containing a set of observation data of a call. It carries out the translation, using a specific
format, to a binary file of the system. Upon operator request from a PC, the translation to
ASCII is performed and this information is stored on a PC disc.

1.
Figure 386 : Observation data collection
OPERATOR
PHASE
SLO CS SR
ACTIVATION
CALL HANDLING
DATA PHASE
COLLECTION COLLECTION
UNPACK
OUTPUT
PHASE
PRINTER
DISK
11.2.3 Supervision
The main objective of this function is to provide a permanent surveillance of the exchange
and the network performance.
The objects under observation are mainly:
- The exchange itself
- Control elements
- Single trunks
- Trunk groups
- Routes
- Service circuit types and modules

1.
- Analog & ISDN lines
- X25 links
- etc.
The supervision is based on the measurement subsystem. In fact a set of statistics counters
are interrogated, processed and compared to some threshold values (which can be modified
by MMC). The counter values are provided in an Nx5 minutes period.
Based on this action, it is possible to report that something may be wrong –adding indicators
or ratios– and to activate or deactivate alarms. Sometimes automatic tests on some objects
which are suspected of being faulty are triggered. If, after checking, the ’faulty’ condition is
confirmed, the object is set to unavailable until the cause has disappeared.
Some examples of analog line supervision are:
- Unavailability of lines. This function allows to supervise the relationship between the
unavailable lines and the total lines. This feature can be activated for homogeneous
groups and for a specified time.
- Dial tone delay. If the dial tone delay exceeds an administrable threshold, the call is
considered as delayed. If at least one delayed call is found, a report with the percentage
of delays calls and the average dial tone delay will be output.
- etc.
11.3 Exchange management
The Exchange Management software handles operator requests to change the Semi–
Permanent Data of the exchange.
The Semi–Permanent Data (SPD) define the configuration of the exchange in terms of
features, facilities, and associated information, such as subscriber and trunk facilities,
charging information, allocation of routes, etc. All these data are created in the software
production phase and are held in the relation of the exchange database.
When some of these data have to be updated, the operator can use a set of ORJs which are
translated, by the Administration software, into data modification commands executed by the
Data Base Management System.
All these ORJs are organized into homogeneous groups, mainly Subscriber, Routing, Prefix,
and Charging administration.
11.3.1 Analogue and ISDN subscriber line administration
Some of the ORJs enable the exchange personnel to manage the data associated with the
subscriber (analogue and ISDN) lines. Allocation, changing and removing a subscriber’s

1.
class of service, class of line, as well as interrogation are possible. Also ORJs for
management of the PABX Semi–Permanent Data are provided. Introduction and removal of
PABXs, updating and displaying of the PABX organization plan are available to the operator.
A set of commands, known as ’Handle Line’, have been developed to manage either
analogue or ISDN individual lines. Both of them, subscribers connected directly to the A1000
S12 host exchange and subscribers connected remotely via a IRSU, are handled in a same
way. The identity of the subscriber is indicated by the Equipment Number (EN) , Directory
Number (DN) or even Multi Subscriber Number (MSN). The EN is commonly used when
the DN has not yet been defined.
This set provides the following commands :
- ’Create’ allows the operator to introduce new subscribers into the system. No facilities
can be introduced during the creation phase.
- ’Modify’ and ’Display’ allow to update or display the subscriber’s featuresand classes.
- ’Remove’ is used to remove or intercept the subscriber specified in the input.
Another set of commands, known as ’Handle PABX’, is used to create and maintain PABX
related software data. The PABX can be linked to the system by means of analogue or ISDN
lines, by Primary Rate Access (PRA), by digital trunks, or other combinations.
It is possible to create a new PABX plan in the system. The corresponding ORJ allows the
administration to set up the PABX layout and to define the main PABX features. These
features, e.g. : line/trunk group organization, search mechanism, etc., can be modified or
displayed on the VDU. In addition part of the PABX or the whole PABX can be removed from
the exchange.
On the other hand, the so called ’Complex facilities’ are managed by a set of commands that
allow the creation, modification, and removal of abbreviated dialling, Closed User Groups,
ISDN Packet Switching, etc.
An example of this command area is the command used to display a subscriber. To execute
this command only the DN or the EN is needed:
<DISPLAY–SUBSCR:DN = K’4995060;
When the command is entered, the job is submitted:
ÊÊ
SEQ=6807.920624 9002
COM=4296
JOB SUBMITTED 9000
RESULT FOLLOWS
This command causes all features and characteristics of the subscriber, both analogue or
ISDN, to be displayed:

1.
OTES5_N4_1_213 1992–06–24 15:03:04 WE

001 0130/0006/0003
SEQ=6807.920624 04263
SUBSCRIBER ADMINISTRATION
DISPLAY SUBSCR SUCCESSFUL
FINAL RESULT 1 –
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
EN PHYS (LOG)/ENICONC DN A/I MSNDFLT GDN
H’30 (H’6C0 ) & 93 04995060 A

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
BCAUTH : SPEECH AUD_3_1K

CHARGING METERS : 0
SERVICES :
SUBGRP : 1
SUBSIG : CBSET
SUBCTRL : CFWDBSUB CFWDFIXA CFWDNOR
CFWDUVAR
CFWD : CFWDUVAR 04992345 ACTIVE
COL : NORMSUB
BLNGLEV : 0
MAXCFWD : CFWDU 1
CFWDFIXA 1
CFWDBSUB 1
CFWDNOR 1
DEFLECT 1
LAST REPORT NO = 04263
11.3.2 Routing administration
The purpose of routing administration is to maintain the routing info in an exchange by

means of ORJs. The basic routing info in an exchange is:
- Trunk: The necessary elements to branch one user channel between two exchanges.
- Trunkgroup:A number of trunks between two end points, sharing the same facilities
(signalling, direction, etc).
- Route: All trunkgroups directly connecting two points.

1.
- Routeblock: A number of routes which can be selected to reach an indicated destination

(prefix). In each routeblock there is one preferred route which is called primary route. The
other routes in the same routeblock are called alternative routes. These routes are
chosen only in case of congestion or unavailability of the primary route.
The main SPD of the trunks are:
– – the terminal number of the trunk
– the identity of the trunkgroup the trunk to which
– the control element identity
– the trunk state
– particular features (semi–permanent connection, etc.)

Figure 387 : Routing basic concepts

Announcement
Centre
D
TRKGR AD
TRKGR DE
RouteBlock AE
RouteBlock AB
C
TRKGR CE E
TRKGR AC
TRKGR BC
A TRKGR AB1
TRKGR BE
B Subscriber
TRKGR AB2
Subscriber Route AB Subscriber

1.
Figure 388 : Relation between trunks

RouteBlock AB
Route AB Route AC
TrkGrp AB1 TrkGrp AB2 TrkGrp AC

Trunk 1 Trunk 2 Trunk 1 Trunk 2 Trunk 1 Trunk 2
A trunk has to be seized by the operator in order to update its associated data. When the
operation is executed successfully, no more calls are allowed on the trunks. The trunks can
be specified with their terminal control element identity and terminal number or with the
identity of the trunkgroup they belong and the trunk sequence number within the trunkgroup.
Once a trunk is seized, the modify and display commands can be used by the operator to
change or/and display the call handling related data of this trunk.
The trunk can then be released from operations. After this command is executed, only calls
or trunk test calls are allowed and data manipulations are no longer possible.
Another possibility is to move trunks. This command performs the reallocation of trunks from
one trunkgroup to another. In other words, this command functionally performs a decrease
in the call handling capability through a trunkgroup, followed by an increase on the extended
trunkgroup. The operator has to change the GLS of the TCE involved, if the new signalling
type of the trunks is not covered by the currently loaded GLS.
The trunkgroups can be divided into two main groups: the incoming and the outgoing ones.
For these trunkgroups some of the associated Semi–Permanent Data are:
– – the trunkgroup identity
– the list of the associated trunks
– the signalling type
– the identity of the route to which the trunkgroup belongs

1.
– the reference trunkgroup for DID
– the preselection digits
– etc..
as well as the nature of address and destination point code for the N7 trunks.
Taking into account all these parameters, it is possible to create or remove trunkgroup, or
modify the data of an existing one. The data can also be displayed. Removal of a trunkgroup
is only allowed if it is not allocated to a routeblock and does not contain trunks.
The commands to reduce or extend trunkgroups are used to decrease or increase the
number of trunks within a trunkgroup. The command creates the relationship between the
trunk terminal control element identity and the terminal number at one side, and the
trunkgroup identity, the trunk sequence number and the trunk terminal control element
sequence number within the trunkgroup at the other side. It also copies the trunk related
data defined at the trunkgroup level to the trunk level. The operator has to change the GLS
of the TCE involved, if the new signalling type of the trunks is not covered by the currently
loaded GLS.
In addition, the route administration software provides a set of tools to handle all the data
related to the routes and the routeblocks. The main commands are create, modify, remove,
display, etc..
When a route is created, it is included in the DataBase. The route number will be generated
by the ORJ for internal use. Once the route exists, a series of trunkgroup can be allocated to
it, using the modify command. This command can also be used to change the status of the
route (in–service, out–of–service, etc.).
Analogue features exist for the routeblocks. The create feature is used to introduce a new
routeblock, and subsequently, a new node in the routing–plan. This routeblock will later be
used by the Prefix Administration ORJs to connect it to a prefix. The bearer and the
signalling dependencies have to be specified by the introduced subroute–block (a
hierarchical set of subroutes). The trunkgroups are sorted into subroutes which are selected
according to their priority: first the primary subroute, then the first alternative one, and so on.
11.3.3 Prefix administration
In an exchange, a number of specific call handling tasks have to be performed during call
set–up and call release. These tasks can be charging, signalling and destination related
(e.g. local or outgoing call, numbering type, signalling type). The decision on how to perform
these tasks is based on three parameters: the originator of the call (subscriber or
trunkgroup), the destination of the call (prefix), and the type of call (normal, coinbox, etc.).
This information is used inside PATED. With these input parameters, PATED will be able to
select the specific tasks for every call. If the call set–up cannot proceed, the underlying

1.
cause is presented to the call service subsystem (=CAUSE) and a specific task will be
performed to release the call set–up in a defined way.
Most of the information related to prefix analysis is in Semi–Permanent Data form. Some of
the data is administration dependent and a lot more data is exchange dependent. By means
of man machine communication, the operator can get access to all of these data.
The main key parameters used to handle the PATED data are:
- The source code: A number reference to the type of originator of the call in the
exchange.
- The nature of address: Only relevant for a call on an incoming trunk. It indicates where
the call originated.
- The Prefix: Used in the exchange to route the call.
- Type of call: Indicates the calling party category (normal, coinbox, etc.).
With these input parameters it is possible to find a specific origin and destination of the
different tasks. All this data can be retrieved by means of the display feature. For instance, it
is possible to display, for a given prefix, an overview of the input parameters and next the
information of every digit of the prefix. This result may be a CPX, a Cause, and the number
of digits that are still required.
It is, of course, also possible to create a new prefix. When you create a prefix you have to
define all the necessary data for that prefix. You can also modify a prefix data profile.
11.3.4 Charging administration
The charging administration of the A1000 S12 exchange provides tools to change the
charging calendar, the charging scale, the tariff, the charge accounting (revenue sharing
between operating companies), etc.
To define the charging information. such as method, rate, number of pulses, etc., the
charging programs require four codes:
- The originating code for charging: This code is derived form the source code and the
nature of address.
- The destination code for charging: This parameter is used to group destinations that
are considered as a unique destination by the charging system. It is derived from the
dialled prefix.
- The type of call: This code is retrieved from the class of service.
- The calendar: Up to eight calendar types can be defined. This calendar gives a category
for every day: workday, weekend day, holiday, and special day.

1.
The operator has some commands to handle charging data. It is possible to display the
prefix tasks for charging to a destination or to a supplementary service, as well as to modify
this data. Also, the different types of calendar, the charging tariff, the rate, the number of
pulses and the charging method used for each tariff group and their corresponding
switch–over times, can be displayed or modified.
Example : To display the charging calendar, with two possible parameters, either the week
calendar or the year one, the execution of the command would be as follows:
ÊÊ
<DISPLAY–CHARGING–CALENDAR:WEEKCAL ,TABLE=2;
SEQ=6817.920624 9002
COM=0752
JOB SUBMITTED 9000
RESULT FOLLOWS
Once the job is submitted, the charging assigned to every day in the week is shown:

1.
OTES5_N4_1_213 1992–06–24 15:28:20 WE

001 0130/0006/0003
SEQ=6817.920624 00766
AREA=CHARGING ADMINISTRATION
DISPLAY CHARGING CALENDAR SUCCESSFUL

FINAL RESULT 1 –
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
OPTION = BASIC WEEK CALENDAR
CALENTYP SU MO TU WE TH FR SA TABLE
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
LAST REPORT NO = 00766
11.4 Network management
The reason for implementing a Network Management system is to ensure to efficient

operation and to maximize the traffic handling capacity of the network during periods of
traffic overload.
Overload occurs when there are insufficient traffic handling resources in the network to
handle the incoming traffic. Causes of overload can be switching or transmission equipment
failures, natural disasters, family–oriented holidays, underestimated growth in demand for
services, etc.
Overload has an undesirable effect on an uncontrolled network. When traffic is low and the
available quantities of all the various types of resources needed to set up any call are
sufficient to handle the traffic, all offered traffic is carried out. When traffic increases, the

1.
resources needed to complete some calls become unavailable and these calls are blocked.
Since most of the calls are immediately (or soon) reattempted, further demands are placed
on the network’s resources. The result is that, due to deadlocks, above some higher level of
offered traffic, a congested network without Network Management begins to carry less traffic
than at lower traffic levels.
Moreover, calls initiated at the (usually) less congested periphery of the network in general
encounter congestion near the middle, after having already utilized several stages of
intermediate resources which therefore cannot be utilized by other traffic. Under conditions
of extreme overload, this congestion can result in the inability to complete any call in the
network.
The ideal action of the Network Management would to cause a reduction in the offered traffic
to a point just below the critical level at which deadlocks begin to occur, thereby maximizing
the traffic handling capacity of the overloaded network. This can be accomplished by
several methods, e.g.: cancelling offered traffic at the periphery of the network, delaying or
preventing reattempts on incomplete calls, minimizing the resources used to set up and
complete the calls by restricting alternately routed call attempts, etc.
The Network Management in the A1000 S12 provides the facilities necessary for the
network managers to maintain the efficient operation of the network during periods of traffic
overload. First, it provides tools which enable network managers to obtain timely network
performance data. Second, it provides tools that can be used to modify the network traffic
flow in order to reduce overload and thus increase the number of calls that can be
completed by the network.
Since overload conditions cannot be predicted and do not affect the different equipments
within the network to the same extent, the Network Management system must be flexible,
resilient, and for most of its actions rely on the timely application of the experience and
wisdom of the network managers controlling it.
The strategy for Network Management in the A1000 S12 is based on the use of centralized
intelligence: the Network Service Centre or a particular administration dependent centre,
which communicates with the depending exchanges. These exchanges give the necessary
indicators to the NSC and react to the requests received from the NSC.
Conclusion: Network Management can be defined as the whole of operations intended to

exploit an existing network with maximum efficiency, and to restore normal operation when
the proper working has for some reason been disturbed. Network Management can also be
used as a planning tool to avoid network problems in the future.
The main objectives of the Network Management are to provide real time response to
unexpected network conditions and pre–planned actions to deal with regularly recurring and
predictable conditions, as well as to work out methods to restore service after an overload.
In order to carry out the above mentioned objectives some indicators have to be provided.
These indicators are related to interesting phenomena from a network management point of

1.
view, e.g.: indicator of traffic that has a low probability to reach a destination, trunk
occupancy indicators, exchange overload indicator (i.e. too many calls not accepted by the
system), etc.
Based on these indicators, certain actions can be initiated in the exchange:
- actions which affect only the internal behaviour of the exchange: exchange load control;
- actions which have an influence in the network: network load control.
11.4.1 Destination controls
Destination controls are used to limit traffic which has a small probability of reaching a
specified destination.
Some of the implemented controls are: Code Blocking, Hard–To–Reach, Explosive Traffic
Control and Call Gapping.
a. Code blocking
Code blocking control can be used to block traffic towards destination codes, which
have a small chance of being completed. This capability is used to limit traffic surges to
a destination. It can also be used to limit traffic early in the network to an office or code
that is partially or completely out–of–service, thereby conserving network resources
and preventing local congestion from being propagated through the network.
A code blocking destination can be defined as a dialled digit string from 2 to 12 digits in
length. Calls can be restricted to certain areas, specific exchanges, or even individual
subscribers, and these calls are directed to a specific announcement. The cancellation
of calls is done on a percentage basis.
Figure 389 : Code Blocking
CALLS ATTEMPTS
TO A DESTINATION
A1000 S12 HANDLE A PERCENTAGE
OF CALLS (X%)
PSTN
YES
Calling – TELEPHONE AREA
Subscribers IS CODE BLOCKING – AN EXCHANGE
CONTROL TRIGGERED?
CANCEL A PERCENTAGE – INDIVIDUAL
OF CALLS (100–X%) SUBSCRIBERS

1.
b. Hard–to–reach
Traffic which has a low probability of completion is named hard–to–reach. Since certain
destinations may become hard–to–reach only at certain times, especially under high
traffic conditions, it is desirable to block calls only during the time they are experiencing
congestion. Hard–to–reach analysis is used to determine when the relevant
destinations are congested. The analysis also determines when the congestion has
been relieved. Since the exchange does not automatically determine which
destinations are involved (or are potentially hard–to–reach), this control can be
considered as semi–automatic.
To determine whether a destination code is hard–to–reach four thresholds are used,

namely: the lower & the upper ’call attempts’ thresholds, and the lower & the upper
’answer/bid ratio’ thresholds. When the hard–to–reach analysis is triggered, these
thresholds are compared to the actual real–time call attempts and call completion
measurement data counters. To establish the hard–to–reach condition on a destination,
the number of call attempts towards the destination during the previous data–collection
period must exceed the upper ’call attempt’ threshold, and the collected answer/bid
ratio towards the destination must be less than the lower ’answer/bid ratio’ threshold.
The hard–to–reach blocking is removed from the destination when one of the following
conditions is met: the number of call attempts towards the destination during the
previous data collection period falls below the lower ’call attempts’ threshold, or the call
completion ratio towards the destination during the previous data collection period
exceeds the upper ’answer/bid ratio’ threshold.
A hard–to–reach destination can be also defined as any dialled string from 2 to 12

digits in length. Calls can be restricted to certain areas, specific exchanges, or even
individual subscribers.

1.
Figure 390 : Hard–to–reach control

CALL ATTEMPTS
TO A DESTINATION
A1000 S12 HANDLE A PERCENTAGE
OF CALLS (X%)
PSTN
YES
Calling – TELEPHONE AREA
Subscribers HARD–TO–REACH – AN EXCHANGE
FLAG SET?
CANCEL A PERCENTAGE – INDIVIDUAL
OF CALLS (100–X%) SUBSCRIBERS
c. Explosive traffic control
Explosive traffic control is used to avoid that calls to certain prefixes seize all resources
(trunks).
The number of call attempts towards a certain prefix over a certain time period is
compared with a threshold, namely the maximum allowed number of call attempts. If
the maximum number of allowed call attempts determined to be towards a certain
prefix is not reached then the actual number of call attempts is incremented and the call
is handled. If, however, the actual number of call attempts towards that prefix is equal
to the maximum allowed number of call attempts, then the call is cancelled and an
announcement is returned. After a timeout, a value is subtracted from the actual
number of call attempts.
Because the PATED processors handle the traffic in load sharing, the maximum
number of call attempts specified by the operator is proportionate part of the maximum
value of the complete exchange.
An Explosive Traffic Control destination can be defined as a dialled digit string from 2 to
12, so that calls can be restricted to certain areas, specific exchanges, or even
individual subscribers.

1.
Figure 391 : Explosive Traffic control

CALLS ATTEMPT
TO A DESTINATION
A1000 S12
PSTN
YES
Subscribers – TELEPHONE AREA

IS THE NUMBER OF – AN EXCHANGE
CALL ATTEMPTS
CANCEL THE CALL GREATER THAN A – INDIVIDUAL
THRESHOLD? SUBSCRIBERS
d. Call gapping
This control limits the number of call attempts routed to the specified destination over a
particular period of time. The affected traffic will be routed to a special announcement.
The call attempts are treated by different PATED processors (load sharing). Therefore,
the Call Gapping control will be given to one processor at a time. This requires a
scheduling of the PATED processors to accept the call attempts for destinations under
Call Gapping control.
During a defined period of time a PATED can be open or closed. The open period, also
called Gap Time, is given by the operator. This Gap Time multiplied by the number of
processors will be the Gap Cycle time.
There are several possibilities for Call Gapping. The first defines that a call will only be
accepted when it is the first call in an open period. The following call attempts in the
same open period and the call attempts in a closed period will be rejected and routed to
an announcement. Another possibility, which is used when traffic is low, defines that a
call will be accepted when it is the first call in an open period and that a call attempt in a
closed period will be accepted, when there was no call during the previous open period.
In all other cases the call is rejected and routed to an announcement.

1.
Figure 392 : Call Gapping control

CALLS ATTEMPT
TO A DESTINATION
A1000 S12
PSTN
NO
Subscribers – TELEPHONE AREA

IS THE FIRST ATTEMPT – AN EXCHANGE
IN AN OPEN PERIOD?
CANCEL THE CALL – INDIVIDUAL
SUBSCRIBERS
11.4.2 Routing controls
As explained before, in the ’Trunk Search’ chapter, the interconnections between exchanges
are organized as routeblocks, routes, trunkgroups, and trunks. Some tables belong to the
Trunk Resources Management software used to carry out the selection of a trunk for the
outgoing calls. These data can be modified by Network Management tools to avoid overload
or blocking of trunks, routes, or routeblocks.
The following figure shows an environment of exchange interconnections which will be used
as an example. The exchanges are A (local), B (local and transit), C (transit), D (transit and
announcement centre), and E (local). The different trunkgroups among them can be seen on
the figure. Trunkgroups AB1 and AB2 form route AB, trunkgroup AC forms route AC, and so
on. Routes AB and AC form routeblock AB, route AD and route AC form routeblock AE, and
so on.

1.
Figure 393 : Network environment

Announcement
Center
D
TRKGR AD
TRKGR DE
RouteBlock AE
RouteBlock AB
C
TRKGR CE E
TRKGR AC
TRKGR BC
A TRKGR AB1
TRKGR BE
B Subscriber
TRKGR AB2
Subscriber Route AB Subscriber
The trunk search scheme to reach a subscriber from exchange A to B and to E, is as

follows:
Figure 394 : Routeblock AB

RouteBlock AB
Route AB Route AC
TrkGrp AB1 TrkGrp AB2 TrkGrp AC
Trunk 1 Trunk 2 Trunk 1 Trunk 2 Trunk 1 Trunk 2

1.
Figure 395 : Routeblock AE

RouteBlock AE
Route AC Route AD
TrkGrp AC TrkGrp AD
Trunk 1 Trunk 2 Trunk 1 Trunk 2 Trunk 3
a. Routeblock controls
This network management control is related to a routeblock. Two types of control are
provided: Cancel Alternative Routing and Temporary Alternative Routing.
The cancel ’alternative routing’ control prevents traffic towards a destination from
overflowing from the high usage primary route to alternate routes after a fixed position
in the sequential routing plan. It has a restrictive effect because it prevents the seizing
of trunks from a certain point during the selection of a route in a routeblock.
Taking the previous figure as example, route AC is both the primary route for routeblock
AE and the alternative route for routeblock AB. If that route is congested by the
overflow of calls coming from the route AB, it could be necessary to cancel all the calls
coming from AB to increase the number of successful calls to exchange E. This is
made possibile by the appropriate operator command.
On the other hand, the temporary alternative routing redirects traffic from congested
routes to other routes not normally available which have idle capacity at the time. A
temporary alternative routing consists of a list of different route alternatives.
In our example, although route AD is not included in routeblock AB, it may be

necessary to modify the alternative routeblock list to provide an alternative temporary
path to the calls from A to B: the A–D–E–B path. In this particular scenario, loops would
probably be created between exchange A and D.

1.
b. Route controls
Route controls are used to limit traffic to a specified route or to expand routing within
the normal in–chain routes during congestion periods.
Some types of manual route controls are implemented to regulate the maximum call
rate to keep the network at peak performance during periods of overload: ’cancel–to’,
’cancel–from’, ’skip’ and ’announcement’ controls.
’Cancel–to’ control is used to deny access to a route. Traffic is cancelled and directed
to a specific announcement. Calls are cancelled on a percentage basis from 0% to
100%, in steps of 1%. Still following the figure example, when trunkgroups AB1 and
AB2 are congested, the ’Cancel–to’ operator command can be used to cancel a
percentage of calls trying to reach route AB.
’Cancel–from’ control is used to deny access from a route which would normally
overflow to an alternate route. Overflow traffic is canceled and directed to a specific
announcement, on a percentage basis. In our example, in case of congestion on

alternative route AC of routeblock AB, the operator can deny the overflow of calls
coming from route AB. The command ’Cancel–from’ cancels a percentage of these
calls.
’Skip’ control is used to force traffic to the next in–chain route. Calls are skipped on a
percentage basis.
’Announcement’ control is used on a final in–chain route to alter the normal recorded
announcement. This control may be used, for example, to advise callers to postpone
reattempts (especially of non–critical calls), until a later time, rather than redialling
immediately.
c. Trunkgroup controls
Trunkgroup controls are used to limit traffic to a specified trunkgroup to expand routing
within the normal in–chain trunkgroups during times of congestion. Several trunkgroup
controls are implemented to regulate the maximum call rate to keep the network at
peak performance during periods of overload.
’Cancel–to’ control is used to deny access to a trunkgroup. ’Cancel–from’ control is

used to deny access from a trunkgroup which would normally overflow to an alternate
one. ’Skip’ control is used to force traffic to the next in–chain trunkgroup.
’Announcement’ control is used on a final in–chain trunkgroup to alter the normal
recorded announcement.
’Reservation’ control is used to regulate the traffic flow on trunkgroups by reserving a

number of trunks for certain types of traffic. The affected traffic is skipped to the next
available trunkgroup or cancelled if no alternate trunkgroups are available. The traffic
category is defined as a function of the origin and the destination, the type of call, the
hard–to–reach status, the bearer capability, etc..

1.
11.4.3 Machine congestion analysis
In addition to network overloads due to unavailability of trunks, digital exchange overloads

due to excess demands on internal resources (receivers, senders, processor time, memory,
data bus capacity, etc.) can occur.
The functions, collectively titled Machine Congestion Analysis, are performed in the A1000
S12 exchanges in order to implement dynamic overload control within the telephone
network. Machine Congestion Analysis functionality requires cooperation with the network
management centre to which this exchange is connected. A machine congestion report is
sent to the network manager so that he can perform the necessary manual controls to solve
the overload problem in a certain exchange. In a centralized point, the operator can better
estimate the consequences of his actions on the network because he has a complete
overview of the network in the NSC.
For purposes of dynamic overload control, four levels of machine congestion are defined: no
system overload, moderate system overload, severe system congestion, and complete
inability of the exchange to handle incoming and transit traffic.
11.5 Extensions
This part of the administration software controls all operator requests to perform equipment
extensions in the existing on–line environment of the A1000 S12 exchange. The main
extension objectives are to increase the traffic capacity of an exchange, to add new facilities,
or to adapt the exchange to network extensions.
Hardware extensions add more hardware modules to an exchange as well as the

corresponding non CE hardware required as a result of their addition (e.g. DSN, clock &
tone distribution, etc). The main steps to be followed are as follows : updating the database
relations to describe the new hardware configuration, modifying of the hardware
configuration by installing the new modules, testing this hardware, and starting up (on–line)
those modules.
Software extensions are used to add new features to an exchange, to enhance the existing
features or to add a new software package (i.e. to support the above hardware extensions).
This procedure involves the addition or the replacement of programs and data in some or all
of the control elements.
The system start–up is developed as mentioned in the previous part of the document
(’System– Start–Up’ and ’Warm–Start–Up’).
The A1000 S12 extension strategy is subject to a number of requirements. Thus, there shall
be no significant interference with normal exchange operation. This implies that call handling
capability shall be maintained, that the loss of calls in the set–up phase or conversation
phase shall not exceed the number of calls lost during normal maintenance activities, and

1.
that the system availability requirements shall be met. In every step of the extension,
however, the system must be able to roll back to the original configuration.

1.

1.
ANNEX A : LIST OF ABBREVIATIONS
ABS Alternate Billing Services

AC Alarm Control
ACE Auxiliary Control Element
ACM Address Complete Message
AFF AMA File Formatter
AFFC AMA File Formatter Control
ALCN Analogue Line Circuit type N
ALCP Analogue Line Circuit type P
AMA Automatic Message Accounting

AMEA Additional Memory Board (DIAM)
ANC Answer with Charging
AOC Advice Of Charge
A&P Administration Support and Peripherals Module
ARTA Auxiliary Resource TCE Allocator
ARU Automatic Recording Unit
ASAC Administration System ACE
ASCII American Standard Code of Information Interchange
ASM Analogue Subscriber Module
BA Basic Access
BC Bearer Capability
BCG Business Communication Group
BCGRM Business Communication Group Resource Manager
BIDH Binary Interface Device Handler
BPA Backpanel
BS Basic Service
BSN Backward Sequence Number
BUT Backup Tape
BUTG Backup Tape Generator

1.
C
CACO Call Control
CAE Customer Application Engineering
CALC Control and Alarm PBA type C
CAS Channel Associated Signalling
CB Clear Backward
CCBS Call Completion to Busy Subscriber
CCITT International Telegraph and Telephone Consultative Comittee
CCLA Central Clock Advanced
CCLD Central Clock Distribution
CCNR Call Completion on No Reply
CCS Common Channel Signalling
CD Call Deflection
CDC Central Data Collector
CDE Customer Design Engineering
CDM Compound Dialogue Manager
CE Control Element
CFB Call Forwarding on Busy
CFFA Call Forwarding to Fixed Announcement
CFNR Call Forwarding on No Reply
CFU Call Forwarding Unconditional
CGC Charge Generation Control
CH Cluster Handler
CHAN Charging Analysis
CHIR Charging Information Request
CIC Circuit Identification Code
CLF Clear Forward
CLIP Calling Line Identification Presentation
CLIR Calling Line Identification Restriction
CLMA Central Alarm PBA type A
CLTD Clock and Tones Distribution
COL Class Of Line
COLP Connected Line Presentation
COLR Connected Line Restriction
CPC Calling Party Category
CPU Central Processing Unit

1.
CPX Condensed Prefix

CRC Cyclic Redundancy Check
CRM Charge Recording Manager
CSAC Charging System ACE
CSCO Charge Scale Change Over
CTCE Clock and Tones CE
CTLE Control Element SBL
CTM Clock and Tone Module
CUG Closed User Group
CW Call Waiting
D
DAHU Device Anomaly Handling Utility
DASSIGN Device Assignment relation

DB Database
DBCS DataBase Control System
DBSS DataBase Security System
DBU Disk Backup Utility
DDDG Dynamic Data Distribution Group
DDI Direct Dialling In
DDM Dynamic Data Manager
DH Device Handler
DIAA Digital Integrated Announcement PBA type A
DIAM Digital Integrated Announcement Module
DIL Digital Interface Limited
DK Data key
DLM DataLink Module
DLP Data Load Partition
DLS Data Load Segment
DLT Data Load Tape
DMCA Direct Memory Controller type A
DN Directory Number
DNE Directory Number Equivalent
DNEH Directory Number Equivalent Hundred
DNET Directory Number Equivalent Thousand
DOR Division Of Revenue
DORC Division Of Revenue Collector

1.
DORO Division Of Revenue Output

DPC Destination Point Code
DPLF Defense Pair Load Failure
DPTC Dual Processor Terminal Controller
DSDR Device Status Disk Recovery
DSE Digital Switching Element
DSGA Digital Signal Generator type A
DSN Digital Switching Network
DSP Digital Signal Processor
DSPA Digital Signal Processor PBA type A
DT Dial Tone
DT Diagnostic Test
DTCL Digital Trunk Common Logic
DTM Digital Trunk Module

DTMF Dual Tone Multi Frequency
DTRF Digital Trunk PBA type F
DTRH Digital Trunk PBA type H
DTRI Digital Trunk PBA type I
DTUA Digital Trunk Unit PBA type A
E
EBCDIC Extended Binary Coded Decimal Interchange Code
ECMA 13 EUROPEAN Computer Manufactures Association
Standard 13
EDPC Electronic Data Processing Centre
EF External Fault
EOP End Of Packet
ETSI Eurpean Telecommunications Standards Institute
EQAWL Equipment Allowed
F
FBK Fallback
FCS Frame Check Sequence
FCU File Comparison Utility
FD File Directory
FDB File Descriptor Block
FDBM File Descriptor Block Maintenance Utility

1.
FDT File Descriptor Table

FDTA File Descriptor Table Administrator
FISU Fill In Signal Unit
FIT Faulty, but In Traffic
FLT Faulty
FMM Finite Message Machine
FSM Finite State Machine
FSN Forward Sequence Number
FW Firmware
G
GD Ground Detection
GDN General Directory Number
GIOR General I/O Remote

GIOUTY General I/O Utility
GLS Generic Load Segment
GLSC GLS code
GOS Generic Overlay Segment
GSM Generic Segment Module
H
HCCM High Performance Common Channel Module
HDB3 High–Density Bipolar Excess 3
HDLC High Level Data Link Control
HIAU Hardinit Audit Utility
HLC High Layer Compatibility
HM Home Meter
HSB High Speed Bus
HSCB High Speed Cluster Bus
HW Hardware
I
IAM Initial Address Message
ICB Interrupt Control Block
ICLP Internal Connectionless Protocol
ID Identification

1.
IDC Intermediate Data Collector

IDN Individual Directory Number
ILC ISDN Link Controller
I/O Input/Output
IOC Input/Output Control
IOS Input/Output System
IPABX ISDN Private Automatic Branch Exchange
IPP Internal Packet Protocol
IPTM Integrated Packet Trunk Module
IRIM ISDN RSU Interface Module
IRSU ISDN Remote Subscriber Unit
ISDN Integrated Services Digital Network
ISM ISDN Subscriber Module
ISTA ISDN Subscriber Termination PBA A

ISTB ISDN Subscriber Termination PBA B
ISUP ISDN User Part
IT In Traffic
ITM ISDN Trunk Module
IW Interworking
J
JSQ Job Sequence Number
L
LAPB Link Access Procedure Balanced
LAPD Link Access Procedure in D–channel
LCACO Line Call Control
LCE Logical Control Element
LCE–ID Logical Control Element Identity
LCG Local Charge Generator
LCS Local Charge Synchroniser
LDC Local Data Collector
LED Light Emitting Diode
LH Line Hunting
LI Length Indicator
LLC Low Layer Compatibility
LPFA Line Power Feed type A

1.
LSB Low Speed Bus

LSI Large Scale Integration
LSIF Local Subscriber Identification
LSSG Load Sharing SubGroup
LTL Local Tax Layouter
MAC Monitor Access

MCC Metering Counts Collector
MCI Malicious Call Identification
MCUA Module Control Unit type A
MCUB Module Control Unit type B
MDF Main Distribution Frame

MF Multi Frequency
MH Message Handler
MIM Mobile Interworking Module
MIO Multidrop Information Octet
MIRB Modem Interface and Rate Adaptation PBA type B
MMB Multi Master Bus
MMC Man Machine Communication
MMCA Man Machine Controller type A
MMCH MMC Channel
MMCM MMC Maintenance
MMT Man Machine Translation
MONI MPTMON CE
MPA Master Panel for Alarms
MPM Maintenance and Peripheral Module
MPTMON Multi Processor Test Monitor
MSAC Measurement System ACE
MSG Message
MSM Mixed Subscriber Module
MSN Multiple Subscriber Number
MTP Message Transfer Part
MTTR Mean Time To Repair
MTU Magnetic Tape Unit
MTUF Magnetic Tape Unit Formatter

1.
N
NDUB Network Defined User Busy
NEQ Not Equipped
NMI Non Maskable Interrupt
NPI Numbering Plan Indicator
NSC Network Service Center
O
OBC On Board Controller
OBCI On Board Controller Interface
OCB Overlay Control Block
OD Optical Disk
ODK Optical Disk

OLCOS Originating Line Class Of Service
OMB Output Meter Block
OMUP Operations and Maintenance User Part
OPC Originating Point Code
OPR Operator Out of Service
ORJ Operator Requested Job
OS Operating System
OSI Open Systems Interconnection
OSN Operating System Nucleus
P
PABX Private Automatic Branch Exchange
PARM Private Access Resource Manager
PATED Prefix Analysis & Task Element Definition
PB Push Button
PBA Printed Board Assembly
PBR Push Button Receiver
PBX Private Branche Exchange
PC Personal Computer
PCM Pulse Code Modulation
PD Peripheral Device
PERI Input/Output Device
PEQ Partially Equipped

1.
P&L Peripheral and Load Module

PLCE Peripheral and Load Control Element
PLS Patch Load Segment
PNP Private Numbering Plan
PRA Primary Rate Access
PSM Packet Switching Module
PSN Private Switching Network
PSTN Public Switched Telephone Network
PTCE Peripheral Terminal CE
PTN Physical Terminal Number
Q
QRC Queue Ram Controller
QS Queue Service
R
RAL Rack Alarm
RBL Repair–Block
RC Ringing Current
RCCA Reference Clock Control type A
RCLK Rack Clock
RIT Replaceable Item
RLG Release Guard
RLMC Rack Alarm PBA type C
RNGF Ring PBA type F
ROM Read Only Memory
RRAM Remote Report and Alarm Module
RRN Report Reference Number
RSU Remote Subscriber Unit
RT Ringing Tone
RTSH Report and Task Supervision Handler
RTSU Remote Terminal SubUnit
RUWA Relation User Work Area
S
SABME Set Asynchronous Balanced Mode Extended
SACE System ACE

1.
SAPI Service Access Point Identifier

SBL Security Block
SCALSV Subscriber Call Services ACE
SCB Simplified Conference Bridge
SCDH Service Circuit Device Handler
SCM Service Circuit Module
SCSI Small Computer System Interface
SI Service Indicator
SIG Signalling
SKR System Kernel Release
SLP System Load Partition
SLS Signalling Link Selection
SLT System Load Tape
SLTA Signalling Link Termination type A

SOS Software Out Of Service
SPATA Speech & Data protocol
SSA Small Stand Alone
SSF Sub Service Field
SSM System Support Machine
SSP Service Switching Point
STAT Statistic data
STP Signalling Transfer Point
SW Software
T
TA Terminal Adaptor
TACB Transaction Control Block
TAU Test Access Unit
TAUC Test Access Unit type C
TAX Taxation data
TAXUP Taxation User Part
TCACO Trunk Call Control
TCE Terminal Control Element
TDM Time Division Multiplexed
TED Task Element Definition
TEI Terminal Endpoint Identifier
TEL Telephonic Devices

1.
TERA/I Terminal Interface type A/I

TI Terminal Interface
TKG Trunk Group
TL Task List
TLCOS Terminating Line Class Of Service
TMIA Transmission and Multidrop Interface type A
TOC Type Of Call
TOD Time Of Day
TP Task Procedure
TRA Trunk Resource Allocator
TRAC Trunk Access Circuit
TRC Trunk Request Coordinator
TREX Training Exchange
TRM Trunk Resource Manager

TS Time Slot
TSA Test Signal Analyzer
TSAB Test Signal Analyser type B
TSU Terminal Sub Unit
TTM Trunk Test Module
TU Terminal Unit
TUP Telephonic User Part
U
UA Unnumbered Acknowledge
UAN Universal Access Number
UCP User Controlled Path
UDUB User Defined User Busy
UIC U–interface Circuit
USI User System Interface
UUS User to User Signalling
UWA User Work Area
V
VCIAU Volume Control Information Access Utility
VDU Visual Display Unit
VP Virtual Path
VSSA Very Small Stand Alone

1.

1.
ANNEX B : DEFINITION BOXES
A
Access Status, 534
ACE = Auxiliary Control Element, 534
ALCN = Analogue Line Circuit, 534
Alignment Pattern, 534
Attendant, 535
B
Basic Service, 535
BC = Bearer Capability, 535
BCG = Business Communication Group, 536
C
CAE = Customer Application Engineering, 536
Cause, 536
Cave, 536
CDE = Customer Design Engineering, 537
CE = Control Element, 537
Centrex, 537
Cityline, 537
Command, 538
Common (Call Handling), 538
CPC = Calling Party Category, 538
D
DDI = Direct Dialling In, 539
DH = Device Handler, 539
DID = Device Interworking Data, 540
DLS = Data Load Segment, 540
DN = Directory Number, 541
DNEH = Directory Number Equivalent of Hundreds, 541
DNET = Directory Number Equivalent of Thousands, 542
DNEU = Directory Number Equivalent of Units, 542
E
EDPC = Electronic DataProcessing Centre, 542

1.
EN = Equipment Number, 543
F
File, 544
Finite Message Machine, 545
G
GDN = General Directory Number, 545
Generic, 545
Generic Load Segment, 545
GOS = Generic Overlay Segment, 546
H
HDLC = High level DataLink Controller, 546
L
LAPD = Link Access Procedure on D–channel, 546
LCE = Logical Control Element Identity, 546
Low penetration data, 547
M
Man Machine Language, 547
MMC = Man Machine Communication, 547
MSN = Multiple Subscriber Number, 547
N
NATADDR = Nature of Address, 548
O
OLCOS = Originating Line Class Of Service, 548
ORJ = Operator Requested Job, 548
P
PABX = Private Automatic Branch eXchange, 549
PCE = Physical Control Element Address, 549

1.
Peripheral Device, 550

PLS = Patch Load Segment, 550
Profile, 550
PTN = Physical Terminal Number, 551
R
RBL = Repair Block, 551
Report, 551
RIT = Replacable Item, 551
Route – Subroute, 552
Routeblock –Subrouteblock, 553
RouteCode, 553
S
SBL = Security Block, 554
SCSI = Small Computer System Interface, 554
SDN = Search Directory Number, 554
SourceCode, 555
Subscriber Group, 555
T
TLCOS = Terminating Line Class Of Service, 555
TN = Terminal Number, 556
Transaction, 556
Trunkgroup, 556
TSU = Terminal SubUnit, 557
TU = Terminal Unit, 557
U
UCP = User COntrolled Path, 558
User Buffer, 557
V
Virtual Machine, 558
Virtual Path, 558

1.
Access Status (see LSIF)
The Access Status specifies the type of called device

Possible values are :
– Normal Line
– Priority Line
– Coinbox
– Test equipment
– ...
ACE = AUXILIARY CONTROL ELEMENT

ACE is the name given to the modules in the system that have no
associated circuitry. Their only relation with the exchange HW is their con-
nection to the network through the Terminal Interface. Therefore, these mod-
ules will perform support auxiliary functions for the rest of the system. Given
their HW independence, the functions to perform are assigned to these Con-
trol Elements with more flexibility than to the others, and they may be re-
placed by others in case of failure.
ALCN = Analogue Line Circuit type N
This is the name of the subscriber line board that serves 16 analog lines.
ALIGNMENT PATTERN
Binary information that travels through channel 0 of the PCM links. This pat-
tern is used to recognize each of the 32 PCM channels.
This information is inserted on every second PCM link.
The PCM link that does not contain the alignment pattern is used to send
alarm information.

1.
Attendant
An attendant is a person responsible for traffic assistance.

In case of a call towards a PABX without indialling, the call will be routed to
the attendant of the PABX. The attendant can now establish a further
through connection towards the desired extension.
Basic Service
The Basic Service is a compressed value of Bearer Capability (BC) and

High Layer Compatibility (HLC).
The BC is a value between 0 and 15 and the HLC is a value between 0 and
32.
Not all combinations of BC + HLC are meaningful
Therefore all meaningful combinations are compressed into the Basic Ser-
vice (BS), a value between 0 and 63.
Basic Service 0 corresponds to any BC and any HLC. This is the only valid
value for Analogue subscribers.
Some ISDN classes are Basic Service dependent. This implies that in-
formation about these classes has to be provided for each allowed BS.
BC = Bearer Capability
The BC is a parameter generated by the originating subscriber.

The BC specifies what kind of connection the subscriber wants to establish.
The BC is a value between 0 and 15
Most commonly used values are :
– Speech
– 3.1 kHz audio
– 64kBit/s digital
– 128 kBit/s digital
– ...

1.
BCG = BUSINESS COMMUNICATION GROUP
The BCG is a service that allows business users belonging to different ex-
changes to have a virtual private telecommunication network, supporting
analog and ISDN subscribers as well as PBXs connected to the Public
Switching Telephone Network.
CAE = Customer Application Engineering
Software / Data which is applied to customise each physical installation to

meet its specific requirements.
It comprises HW related information (LCE–identities, PCE–identities,...)
and Call Handling related information (RouteCodes, DNET ranges,...)
Cause
A Cause is used to identify each abnormal situation during the setup or re-
lease of a call.
Examples :
– unassigned prefix dialled
– No free DTMF receiver could be found,
– signalling protocol error
– ...
The cause value is sent to PATED for Cause analysis.
PATED uses the cause value to retrieve a task map. This task map de-
scribes the actions to be taken to deal with the abnormal situation.
Remark : Some signalling systems (TUP, ISUP, Q931,...)use also CAUSE

values to define abnormal situations. It is up to the signalling handling soft-
ware in System 12 to translate the System 12 CAUSE into a signalling spe-
cific CAUSE or vice versa.
CAVE
Tunnel with only one CE in an end.

1.
CDE = Customer Design Engineering
CDE is software which is applicable to one market only. E.g. Signalling, sub-
scriber facilities, certain operator requested tasks,...
CE = CONTROL ELEMENT
The Control Element is the part of the module in charge of the communica-
tion with the other modules; the Control Element, also houses al the soft-
ware assigned to the module. Two basic parts may be distinguished in the
CE:
–The microprocessor with its main memory, where the main programs that
control the module functions are executed.
–The Terminal Interface (TI), which allows for communication between the
module and the other modules in the exchange through the switching net-
work.
CENTREX
Centrex is an implementation of a private telecommunication network ex-

change located on the premises of the public local exchange.
Cityline
A cityline is an extension of a PABX, having a separate DN and a separate

profile.
A call towards the GDN of the PABX or a DDI extension will use the PABX
profile, whereas a call towards the Cityline DN will use the Cityline profile.

1.
Command
A command is a key sent by the operator to the system SW to

initiate a specific action. To do the requested task for each key
a certain Command Handler FMM exists as the destination FMM for the giv-
en command. The operator has different possibilities to send the command.
Beside the different input devices he can specify the command by a certain
key–word or a certain number,
the Command Reference Number (CRN).
A command may have different (optional and mandatory–) parameters for
detailed task specification with several arguments. All possible combina-
tions of command, parameters and arguments with special separators build
up the predefined syntax.
Common (Call Handling)
Common software, sometimes called Common Call Handling (CCH) is soft-

ware which can be kept common to several markets. E.g. Call Control, Call
Services, Resource Management, ...
The evolution of these items is defined in Common Call Handling releases

(EC5, EC6, EC7.1, EC7.3, ...)
CPC = Calling Party Category
The CPC field is used to identify the Type of Call.

– Normal Subscriber
– Priority Subscriber
– National Operator
– International Operator
– Data Call
– Test Call
– Mobile subscriber,
– ...

1.
DDI = Direct Dialling In
Direct Dialling In or Indialling refers to a PABX where the extensions can be

reached immediately from the public network.
In the example (see below), extension 69 can be reached by dialling the
PABX prefix = 24037, together with the desired extension = 69, so DN =
2403769
Remark : The extensions do not have an individual profile. So, for the call
to DN= 2403769, the PABX profile (for GDN = 2403700) is used.
PABX with indialling :

00
Call routed
01
to exten-
S12
sion
IPABX .
.
(GDN = 2403700) .
99
Hunting on prefix 24037
DH = DEVICE HANDLER
A single software module that controls, directly, each of the different ex-
change circuits.
JLTCE_DH SVTCE_DH
LINE
SERVICE
CIRCUIT
CIRCUIT
SENDER /
RECEIVER

1.
DID = Device Interworking Data
The Device Interworking Data (DID) are a set of data in the exchange to en-
able the interworking between the originating device and the terminating de-
vice (device = Trunk or Subscriber)
S12
DID
Device DSN Device

There are two types of DID:

– Incoming DID
– Outgoing DID
E.g: Data concerning echo suppression, suppress backward answer, gain

parameters, start sending point, pre–answer timeout, ...
DLS = DATA LOAD SEGMENT
DLS is a file on disk and on tape which contains all database data re-
lated to a particular CE. Since each CE in the system has a different
set of database data, each specific CE has its own DLS on disk.

1.
DN = Directory Number
The Directory Number (DN), the number which appears in the telephone di-
rectory, is the subscriber’s logical identification.
It is the number that is dialled when another subscriber is called.
It is constructed according to the CCITT E.164 Specifications.
Three cases have to be distinguished:
A. International calls :
Internat. Country National Subscriber

Prefix Code Destination Number
Code
e.g. 00 32 3 240 3769

B. National calls :
Trunk National Subscriber

Prefix Destination Number
Code
e.g. 0 3 240 3769
C. Zonal calls :
Subscriber
Number e.g. 240 37 69
DNEH = Directory Number Equivalent of Hundreds
The DNEH value points to a block of 100 consecutive DNs. The last two
digits of the DN are an index in this block.
The DNEH value is calculated with the formula :
DNEH = (DNET – 1)*10 + C + 1,
with C the third last digit of the DN

1.
DNET = Directory Number Equivalent of Thousands
The DNET points to a block of 1000 consecutive DNs. The last three digits
of the DN are used as index in this block. For each block of 1000 DNs in an
exchange, a DNET is assigned.
Example : DN range DNET
240 0 000 – 240 0 999 1

240 1 000 – 240 1 999 2
... ...
240 9 000 – 240 9 999 10
253 0 000 – 253 0 999 11
253 1 000 – 253 1 999 12
... ...
253 9 000 – 253 9 999 20
DNEU = Directory Number Equivalent of Units
The DNEU value corresponds to the last three digits of the DN.
Suppose the last three digits are C, X and I,,
DNEU = 100*C + 10*X + I
EDPC = ELECTRONIC DATA PROCESSING CENTRE
An EDPC is a processing centre, made up of high capacity processors,

which deals with specific data such as charging data in the telephone envi-
ronment.

1.
EN = Equipment Number
The Equipment Number (EN) represents the physical identification of the

subscriber line in the exchange.
It consists of the physical or logical Control Element identity of the module
and the terminal number (TN) within this module (E.G:TN = 1...256 for an
ASM)
EN = PCE + TN
or
EN = LCE + TN

1.
File
A file is a box or space reserved for different entries which belong logically
together (e.g. charging data of a group of subscribers). In Alcatel 1000 S12
each file has an offline predefined meaning and characteristic (line size, for-
mat, structure, ...). From the logical point of view each file is subdivided into
records like a register of a document is subdivided into chapters and chap-
ters into paragraphs to build up small logical units which can be treated sep-
erately (create, modify, write). Each file is identified by a logical file number
and the records are specified by their start point, which is called offset (com-
parable to a line number in a document).
There are different possibilities to organise a logical file physically, depend-
ing on the physical medium. We can put everything which logically belongs
together into the same area, like a register or chapter of a document into
one binder, or we can distribute parts of one file to different physical areas to
organise them in another way (e.g. refering to the record size). The smallest
physical unit where we can store different records is one block of 2 Kbyte
size, like a fixed number of lines per page or characters per line; therefore
the maximum size of one record is 2 Kbyte (miniumum size: 1 byte).
"filing"
1. File
1.1 Record
1.2 block
File
File 1
File 2
File 3
File 4
Dir
A-E F-P O-T U-Z
006BC011.DRW

1.
FMM = FINITE MESSAGE MACHINE
An FMM is the basic software building functional block and has the follow-
ing properties:
–It can communicate with other FMMs, but only through messages.
–From the outside, an FMM is a “block box”, i.e., its internal structure is not
known to the rest of the system. Its functional behaviour is unambiguously
determined by the set of mesages it sends and receives.
–It may be in one of several different states and the transactions between
them are allowed. There is a limited set of messages defined for each state.
After receiving a message, the FMM may generate and transmit output mes-
sages and
its state may change.
GDN = General Directory Number
The GDN of a PABX is used as a unique identity of the PABX in System 12.
The profile of the PABX is stored on behalf of this GDN.
Calls towards this GDN result in hunting all accesses towards the PABX.
Generic
Software which is fundamental to the system and is kept generally applica-

ble to all markets. E.g. Operating System, Database, Input/Output mecha-
nisms,...
The evolution of such items is defined in System Kernel Releases (R5.2, R6,
R7.1, R7.2,...)
GLS = GENERIC LOAD SEGMENT
File on disk or tape which contains the resident programs code and data
segment for a particular CE in the system. One GLS is used to load every
CE of the same type.

1.
GOS = GENERIC OVERLAY SEGMENT
File on disk or tape which contains the code and data segment, and the
patches, for an overlay program.
HDLC = High level DataLink Controller
A general and universally accepted way of formatting the link level frames.
The LAPB of X25 and the LAPD of ISDN belong to this family.
LAPD = Link Access Procedure on D–channel
This is the HDLC link level frame format, used in the subscriber link in the
ISDN environment to protect the sending of the signalling messages by the

D channel.
LCE = Logical Control Element Identity
Besides a PCE (Physical Control Element Address) every module receives

also a Logical Control Element (LCE) identity. When FMMs send messages
to other CEs, then usually the LCE–id is used. Inside the Operating System
this LCE–id is translated into the PCE–address so it is possible to calculate
the selects and send the message.
How is the LCE used?
Originating ASM modules contact destination ASMs by means of the LCE–
id. Remember also that ASMs have a X–over partner.
E.g: An ASM sends a message to ASM1 (LCE–A). If the latter is out of ser-
vice, the operating system knows about this and will route the message to
the X–over partner ( LCE–A is linked to PCE–B), which is ASM2.
ASM (Normal Routing) ASM (X–over Routing)
LCE–A PCE–A (=ASM1) LCE–A PCE–A (=ASM1)
LCE–B PCE–B (=ASM2) LCE–B PCE–B (=ASM2)

1.
Low penetration data
The Low penetration data is the part of the subscriber data, describing the
facilities of the subscriber. It consists of both originating and terminating
data.
The Low penetration data is always stored at LSIF level.
Examples :
– Basic service dependent data (only for ISDN subscribers)
– Abbreviated dialling information
– Call forwarding data
– ...
MMC = MAN MACHINE COMMUNICATION

By means of particular communication channels between several devices and ter-

minals and the P&L modules, the operator can manage all the exchange functions.
To do this, a multitude of commands are provided. Each of these commands starts
a software module that performs the required function.
Man Machine Language
The Man Machine language is used by an operator (man) to give commands

to and receive results from the System 12 exchange (machine).
The Man Machine language is conform to the CCITT recommendation for
man–machine language for telephonic exchanges (see CCITT Yellow Book,
Volume VI Part II, Recommendations Z311–Z317, and the contributions of
Study Group XI).
MSN = Multiple Subscriber Number
A subscriber can subscribe to more than one Directory Number (DN).The

different DNs are called MSN1 ... MSNx (x=8 maximum). Every MSN can
have its own data profile with its own facilities.
E.g: MSN1 is the normal subscriber number.
MSN2 is given to business people who are transferred to the
office in case of no answer.

1.
NATADDR = Nature of Address
The Nature of Address specifies the layout of the received digit stream.
– INTAL (international)
– NATIONAL
– ABD (Abbreviated Dialling)
– Unknown
– ...
OLCOS = Originating Line Class Of Service
The OLCOS data is that part of the subscriber profile that is needed to set
up an originating call from that subscriber.
Most important fields are :

– Dial Type (Rotary, PB receiver, Combined set)
– DNET and DNEU value of subscriber
– Subscriber Group identity
– Number of digits to be dialled before prefix analysis starts,
– ...
ORJ = Operator Requested Job
An operator Requested Job is created by the IOS for each syntactically cor-
rect input of a command and identified by a Job Sequence Number (4 digits
as a job counter) and date of the input, the address of the input device and
the operator and exchange identification. A job exists till the final result is
sent to all specified output devices.

1.
PABX = Private Automatic Branch eXchange
A PABX is a switching network, located on the customer’s premises, serving

a number of extensions forming a single subscriber group. It is connected to
the exchange by means of a number of single lines (Analogue or BA) and/or
a number of trunks (Analogue, CAS digital or PRA).
The PABX is identified by means of a General Directory Number (GDN).
The extensions of the PABX are invisible to the public exchange.
In the case of an indialling PABX (DDI), the extensions can be reached from
the public network, but no individual profile is allocated to those extensions.
For a call to/from an extension, the profile assigned to the GDN of the PABX
is used.
00
01
S12 PABX .
.
(GDN = 2403700) .
99
Collection of
single lines
and/or trunks
PCE = Physical Control Element Address
This is the physical address of the module . Every module connected to the
digital switching network has a unique Network Address, which is also called
the DCBA–Address. The only way to change this address for a specific mod-
ule is by changing its physical position in the racks so that it is conected to a
different access switch and/or access switch port.

1.
Peripheral Device
In addition to telephonic devices (e.g. subscriber set) the peripheral devices

(PC, printer, disk, magnetic tape, ...) are the operational tools connected to
Alcatel 1000 S12 exchanges. Each device is physically defined by its HW
configuration, that means what kind of HW is connected in which way to
which HW of the exchange. This can be described by a mnemonic, which
consists of an abbreviation for the type of the device, one character to speci-
fy the CE, which is responsible for controlling the device and a number to
count the devices controlled by the same CE (e.g. a PC controlled by PLCE
with NA H’C may have the mnemonic VDUA1; VDU stands for visual display
unit – independent of the manufactures). Logically each peripheral device is
defined by one or several numbers, the Logical Device Identities (LDE-
VID). The physical configuration which stands behind the LDEVID is data
driven. Standard values are defined in the O&M Manuals (SI 69) with some
general rules to translate logical devices into physical and vice versa.
PLS = Patch Load Segment
PLS is a file on disk and on tape, which contains the patches to the pro-
grams for a particular GLS. These patches are created to improve or to cor-
rect the programs designed for a CE.
Profile
A profile is the collection of all data of one subscriber.

It consists of
– Originating Line Clas Of Service (OLCOS)
– Terminating Line Class Of Service (TLCOS)
– ISDN related data
– Low penetration data

1.
PTN = Physical Terminal Number
This is a word received from the hardware which uniquely identifies a sub-
scriber. The layout is as follows:
PTN = L1L00d dddd 0000 tttt
* L1 = 1 if the subscriber PBA is connected to port pair 3 of

the terminal interface.
* L0 = 1 if the subscriber PBA is connected to port pair 1 of
the terminal interface.
* ddddd : indicates the PBA number of the subscriber
(for ALCN = 00000 upto 00111)
* tttt : indicates the subscriber number for the indicated PBA.
(for ALCN = 0000 up to 1111)
REMARK: The PTN is translated into the TN (see Terminal Number).
RBL = Repair Block
An RBL is the minimum group of SBLs which must be taken out of service to
allow an RIT to be replaced. The SBLs must be taken out of service before
the RIT can be removed.
Report
A report is the answer from the system SW to a certain command sent by

the operator to display the result of an ORJ or a message of the system SW
to the operator. Each report–layout (independent of the contents) initiated by
different commands or the system SW itself, is defined by a Report Refer-
ence Number (RRN) and described in the O&M Manual (System reports).
RIT = Replaceable Item
A Replaceable Item is the smallest item which can be replaced.
E.g.: A printed board, a VDU, a DC/DC converter,....
From the exchange point of view, the RIT is the basic unit of hardware and
can be a part of a SBL or consist of several SBLs, depending on its type.

1.
Route – Subroute
A Route is the collection of all trunks between two adjacent exchanges.
Route Subroutes Trunkgroups

A route can be subdivided into subroutes, depending on the requested BC

and the required signalling system.
Example : We can reserve some trunk groups for speech calls only and some
for 64Kbit/s digital calls. In this case we define two subroutes. The selection
of subroute within the route is in this case based upon the BC.

1.
Routeblock – Subrouteblock
A Routeblock is the collection of all Routes to reach a certain destination.

This destination does not have to be an adjacent exchange.
Route AB Exch B
Exch D
Exch A Route AC
Exch C
Routeblock Routes Exch E

To Exch B Route AB + Route AC
To Exch C Route AC + Route AB
To Exch D Route AB + Route AC
To Exch E Route AC
A Routeblock can be subdivided into Subrouteblock depending on the re-
quired signalling system and the requested BC. Each subrouteblock con-
sists of a number of subroutes. The selection of a subrouteblock within a
routeblock is based upon the BC and required the signalling system.
RouteCode
A RouteCode is used to identify a RouteBlock. In the case of an outgoing

call, PATED translates the dialled prefix into the Routecode, used for Trunk-
Search.
The Trunk Search programs (TRC/TRA) use this RouteCode, together with
the requested signalling system and BC, to select an appropriate subroute-
block.
This procedure is called RouteCode Modulation.

1.
SBL = Security Block
An SBL is a group of hardware circuits which perform a set of functions. The

SBLs are arranged in such a way that if one of the functions is malfunction-
ing, the remaining functions can no longer be used by the exchange. The
entire set (read: SBL) can therefore be removed from service.
In case of problems, there are test programs (Diagnostic Tests) which are
able to couple the error to an SBL, in other words to locate the faulty SBL.
In case of failure, the corresponding SBL(s) is (are) taken out of service. In
this way an SBL can have a number of different states, each indicating
whether the SBL is contributing to the functioning of the exchange.
SBLs do not overlap but are organized on a hierarchical basis so that failure
of an SBL causes any lower level SBLs to become ineffective. These depen-
dent SBLs are automatically taken out of service along with the primary sus-
pect SBL.
An exchange is the grouping of all the SBLs defined within it.
SCSI = SMALL COMPUTER SYSTEM INTERFACE
The SCSI is a parallel, multimaster I/O bus that provides a standard inter-
face between computer and peripheral devices. It implements complete log-
ical commands and true peer– to–peer communication.The former simply
means that all SCSI devices use the same communication protocol. All pe-
ripheral devices, in the P&L modules, are connected a to the CE by the cor-
responding PBA which drive the SCSI bus and drive the devices.
SDN = Search Directory Number
The Search Directory Number of a PABX or huntgroup is used to identify the

accesses towards this PABX/huntgroup. A call towards this SDN results in
the hunting of all connections defined by this SDN.

1.
SourceCode
The SourceCode identifies the type of calling equipment.

The sourcecode consists of 3 parameters :
A. Type of equipment (Subscriber, trunk, test equipment, operator,...)
B. SourceCode Number :further classification of the type of equipment.
For trunks, this is the Trunkgroup number
For subscribers, this is the Subscribergroup number,...
C. An indication whether a Packet switched or Circuit switched call is in-
volved.
Subscriber Group
All subscribers having the same treatment in the exchange are grouped in
one subscriber group.

Example : If subscribers, connected to an RSU receive a different treatment,
all RSU subscribers are grouped in one subscriber group. All non–RSU
subscribers are then grouped in another subscriber group.
TLCOS = Terminating Line Class Of Service
The TLCOS is that part of the subscriber data that is needed to set up calls
towards that subscriber.
Most important fields are :
– Type of connected device (Coinbox, normal line, operator,...)
– Call forwarding information,
– reverse charging indication,
– ...

1.
TN = Terminal Number
This number uniquely identifies the subscriber within the X–over paired mod-
ules. Because there are up to 128 subscribers connected to one module, the
number is in a range of 1 to 256.
1 ... 128 = Even module.

129 ... 256 = Odd module
The software receives the PTN (see PTN) from the hardware and translates
it into the TN and vice versa. In the software the TN is used for database ac-
cess.
REMARK: For ISDN subscribers there are only 8 subscribers/PBA

compared to the 16 subscribers/PBA for analogue. Both modules (ASM or
ISM) use the same BPA which means 16 TNs / slot for analogue and 8 TNs /
slot for ISDN. This is done by skipping 8 TNs for the ISDN. So the ISDN TNs
are in the ranges: 1...8, 17...24, ... , 241...248, which is a total of 128 sub-
scribers.
Transaction
In the Protocol plane (SIG), we talk about a Transaction, whenever a call is

established to/from a subscriber or a trunk.
The SIG allocates a Transaction Control Block to keep information about
each transaction. This information comprises : Cluster path identity, Net-
work path Identity, TN of subscriber/trunk, ...
Remark: A subscriber can have more than 1 transaction at the same time.
E.g: ISDN subscribers have 2 B channels, so they can set up 2 calls at a
time. Analogue subscribers can place an existing call (transaction) in hold
and start a second call (transaction)
Trunkgroup
A trunk Group is the collection of all trunks towards an adjacent exchange,

having the same properties :
Same signalling system(R2, TUP, ISUP, ...),
Same Transmission characteristics (analogue, digital, ...)
...

1.
TSU = TERMINAL SUB–UNIT
Group of modules connected to the network, using two Access Switches.
0 8
TO GROUP
MODULE 0 9
SWITCHES
1 10
ACCESS 11
SWITCH 12
13
14
7 15
MODULE 1
0 8
9 TO GROUP
SWITCHES
10
1
ACCESS 11
SWITCH 12
13
MODULE 7 14
7 15
TU = TERMINAL UNIT
Set of 4 TSUs joined to the same multiport that belongs to the first stage.
USER BUFFER
The user buffer is a memory area to support the sending of messages with
more than 40 bytes of data. There are different sizes of user buffers: 64,
128,256, 512, 1024, 2048, and 4096 bytes long. These memory areas are
located in a particular memory zone, and are managed by the operating sys-
tem. When a process needs a user buffer, it requests the buffer to the oper-
ating system, which locates a free one in the pool zone and associates it to
the requesting process. Once the user buffer has been used to send the
data, the process returns it to the pool by requesting to the operating sys-
tem.

1.
UCP = USER CONTROLLED PATH
User controlled path are two–way paths that are established and released
by the user (process) request.These paths are associated to two processes,
one of them in each CE connected to the path, and every message that en-
ters to the CE via the UCP is directly delivered to the associated process by
the operating system.
VIRTUAL MACHINE
Set composed by a real machine (example: line circuit), plus the programs that pro-
vide abstract operations to the users of this machine (in the example, JLTCE–DH).
LINE OTHER
JLTCE_DH USERS OF
CIRCUIT LINE CIRCUIT
VIRTUAL MACHINE
VIRTUAL PATH
Virtual Paths are one–way temporary paths established through the Digital
Switching Network, to send a message buffer from one CE to another.The
usual procedure is to establish the path, by means of SELECT commands,
to send the message buffer (using the ESCAPE protocol), and finally, to re-
lease it by means of more than two CLEAR commands.

Alcatel 1000 S12 Functional Description PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Alcatel 1000 S12 Functional Description PDF

Uploaded by

Copyright:

Available Formats

HANDOUT

770 00924 0120–VHBE i BELL EDUCATION CENTRE

BELL EDUCATION CENTRE ii 770 00924 0120–VHBE

iii BELL EDUCATION CENTRE

770 00924 0120–VHBE

v BELL EDUCATION CENTRE

770 00924 0120–VHBE

vii BELL EDUCATION CENTRE

     

    

770 00924 0120–VHBE

- General knowledge of digital telephony and data communication

- System Overview: 770 00435 6560–VHBE

770 00924 0120–VHBE 1 BELL EDUCATION CENTRE

2 BELL EDUCATION CENTRE

1. A1000 S12 OVERVIEW

770 00924 0120–VHBE 3 BELL EDUCATION CENTRE

Figure 1 : A1000 S12 environment

Analogue Subscriber ISDN Subscriber

Telephonic interfaces allow telecommunication network users to connect each other to

BELL EDUCATION CENTRE 4 770 00924 0120–VHBE

Figure 2 : Analogue subscribers

770 00924 0120–VHBE 5 BELL EDUCATION CENTRE

Figure 3 : ISDN subscribers

BELL EDUCATION CENTRE 6 770 00924 0120–VHBE

Figure 4 : ISDN PABX

770 00924 0120–VHBE 7 BELL EDUCATION CENTRE

Figure 5 : Exchange interconnection

BELL EDUCATION CENTRE 8 770 00924 0120–VHBE

Figure 6 : Management centres

1.2 Exchange structure

770 00924 0120–VHBE 9 BELL EDUCATION CENTRE

BELL EDUCATION CENTRE 10 770 00924 0120–VHBE

Figure 7 : System diagram

- Analogue Subscriber Module:

- Digital Trunk Module:

- Peripheral & Load Module:

This module performs functions to access pieces of equipment such as peripherals

770 00924 0120–VHBE 11 BELL EDUCATION CENTRE

- Clock & Tone Module:

1.2.3 Equipment practice

BELL EDUCATION CENTRE 12 770 00924 0120–VHBE

Figure 8 : A1000 S12 Exchange floor

1.3 Configurations and applications

- Local, transit (toll) and combined exchanges

770 00924 0120–VHBE 13 BELL EDUCATION CENTRE

- Small capacity exchanges:

1.4 Supplementary Services

- Fixed Destination call:

The exchange provides a preprogrammed number without digits send.

- Call forwarding on no reply:

Calls to the user are forwarded only on no reply after a time–out.

- Completion of calls to busy subscriber:

- Malicious call identification

BELL EDUCATION CENTRE 14 770 00924 0120–VHBE

First of all, Centrex is an implementation of a private telecommunication network

770 00924 0120–VHBE 15 BELL EDUCATION CENTRE

Figure 9 : Centrex Structure

BELL EDUCATION CENTRE 16 770 00924 0120–VHBE

Figure 10 : Wide Area Centrex

1.4.2 Business Communication Group (BCG)

770 00924 0120–VHBE 17 BELL EDUCATION CENTRE

Figure 11 : Business Communication Group