Office of the Chief General Manager

National Centre for Electronic Switching

ARA Centre, Mezzanine Floor
E-2, Jhandewalan Extension, New Delhi-55
Tel No: 23670334, Fax No: 23552387
No. ND/ NCES/ 26-1 (Pt.)/

Dated: 27.01.2007

All CGMs Telecom Circles/ Districts

All CGMs Maintenance Regions
Sub: Maintenance support (AMC for hardware and software) for EWSD
New Technology Switches: Improvement in CCR (call completion ratio)
Kindly refer to the AMC agreement signed with Siemens for maintenance support
of EWSD New Technology Exchanges in BSNL network.
2.
It has been expressed by Telecom Circles during various zonal quarterly
performance review meetings of AMC of New Technical Exchanges that after yearly
preventive maintenance visits by the AMC vendor, the exchanges should achieve the targets
of critical performance parameters (CCR, ASR, PE, CSR etc). AMC vendors represented that
during preventive maintenance visits, they are basically trying to remove all the alarms and
faults in the exchange.
3.
In this context, CGM, NCES mentioned that as nearly two years of AMC
operations are over and issues of AMC are more or less stabilized, hence it is high time to use
the services of AMC vendors in more prudent manner such as to improve the CCR of NT
exchanges and provision exists for the same in the AMC agreement.
4.
Siemens was requested to generate a technical note for improvement of CCR in
EWSD exchanges. Siemens has submitted the technical note regarding improvement of CCR
in EWSD exchanges and the same is enclosed herewith for kind reference.
5.
It is suggested that Circle nodal officers [PGM(O)/GM(O)/GM(Mtce)] may kindly
coordinate with Siemens so as to arrange for demonstration of the implementation of enclosed
technical note in one of the EWSD exchanges by Siemens in the Circle, which exchange incharges of other EWSD exchanges of the Circle may also attend. Thus, the technical note
submitted by Siemens may be implemented in all EWSD exchange for improvement of CCR
and thereby resulting into increased revenue.
6.
Copy of this letter is also available at BSNL Intranet portal
(http://intranet.bsnl.co.in) under the heading BSNL UNITS Specialized Units NCES.
7.

This issues with the approval of CGM, NCES, New Delhi.

(V. K. KANAUJIA)
Dy. General Manager (Technical)
Tel: 011 - 2351 6108
Enclosure: Technical note of Siemens: CCR Calculation, Analysis and improvement
(26 pages)
Copy to:
1. Director (Operations), BSNL, Statesman House, New Delhi
2. Sr. DDG (MS), BSNL Corporate Office, Statesman House, New Delhi
3. DDG (NM), BSNL Corporate Office, Statesman House, New Delhi

Regd. Office: B-148, Statesman House, Barakhamba road, New Delhi-110 001
Corporate Office: B-148, Statesman House, Barakhamba road, New Delhi-110 001 Website: www.bsnl.co.in

Documentation
CCR Calculation, Analysis and
Improvement
BSNL AMC

CONTENTS
1. Critical Performance Parameters
2. CCR Analysis & Improvement
3. Common Error Counters

_______________________________________________________________________

1. CRITICAL PERFORMANCE PARAMETERS:

1. Processing Efficiency:
This is calculated as (Processed Transit Calls/ Offered Calls)*100. This indicates the percentage of
processed transit calls out of the total offered calls. A benchmark value for this parameter is 95%.

Processing Efficiency

Processed Calls
------------------------ *100
Offered Calls

2. (b) Circuit Seizure Efficiency:

This is calculated as (Calls that seized a circuit/ Processed Transit Calls)*100. This indicates the percentage of the calls
that seize an outgoing circuit out of the processed transit calls. A benchmark value for this parameter is 90%.
Circuit Seizures
Circuit Seizure Efficiency
=
------------------------*100
Processed Calls

3. Answer to Seizure Ratio/Efficiency (ASR):

This is calculated as (Effective Transit Calls/ Calls that seized a circuit)*100. This indicates the percentage of
effective transit calls out of the total calls that seized a circuit.

Answer to Seizure Ratio (ASR)

4.

Answered Calls
------------------------- *100
Circuit Seizures

Overall Call Processing Efficiency (CCR):

This is calculated as (Effective Transit Calls/ Offered Calls)*100. This indicates the percentage of the effective transit
calls out of the total offered calls.

Overall Call Processing Efficiency (CCR)

5.

Answered Calls
-----------------------*100
Offered Calls

Traffic/1000 BHCA:
This is calculated as (Total Transit Traffic*1000)/BHCA. This indicates the useful transit traffic in erlangs created for
every 1000 offered calls. A benchmark value for this parameter is 25.

Traffic / 1000 BHCA

6.

Total Transit Traffic

------------------------- *1000
Offered Calls

BHCA:
Sum of Total Calls Carried for the busiest hour i.e. for Four consecutive intervals in which the Traffic Carried figure is
highest in the day.

___________________________________________________________________________________________
Page:3

Basic Parameters used in the calculation of the critical parameters:

1. Offered Calls:
No. of calls attempted/coming to the Exchange during Busy Hour. This is the Sum of "CC" figures (National Incoming
Traffic) of the four 15 minute periods. This can be taken from the RECGOS output and you can sum up the values of
CC:INC (First Column of detailed RECGOS report) for all Traffic types/directions for all the four intervals. It can also
be calculated from Sum of Total Calls for the busiest hour i.e. for Four consecutive intervals in which the Traffic Carried
figure is highest in the day in the RECGOS report ( with SEL=EXCH ).
RECGOS(SEL=EXCH)
RECGOS

= SUM OF TOTAL CALLS OF THE BUSY HOUR

= CC:INC+ CC:INC INAT+ CC:ORIG

2. Processed Calls:
Processed Calls means calls offerred to CP. This can be calculated using any of the following methods
RECGOS

= [Offered Calls] [Sum of "CC Rerouting" figures ]

= CC:INC+CC:ORIG+CC:INAT -CC RER:INC -CC RER:INAT - CC RER:ORIG

RECEXCH

= OFFERRED SEIZURES - CCU INT PROT MECH

3. Circuit Seizures:
This means SUCCESSFUL CALLS or CALLS CARRIED i.e. Calls for which SN through connection was successful in
the own Exchange. This can be calculated using any of the following methods
RECGOS

Sum of "CCS (Sub/Trunk/Pbx ) figures of the four 15 minute periods.

RECEXCH

CC

CCS:SUB+CCS:TRUNK+CCS:PBX

4. Answered Calls:
Sum of "CCS with Answer" figures (National Incoming Traffic: Transit National) This can be calculated using any of the
following methods
RECEXCH
RECGOS
RECGOS(SEL=EXCH)

CCS WITH ANSWER

CCS WITH ANSWER:TERMINATE + CCS WITH ANSWER:TRANSIT NAT
ANSWERED CALLS

5. Total Traffic:
Sum of Traffic Carried TC(DERL) for the busiest hour i.e. for Four consecutive intervals in which the Traffic Carried
figure is highest in the day.
[Sum of "TC: Exchange (DERL)" figures (National Incoming Traffic) of the four 15 minute periods ] / 4
RECGOS
RECGOS(SEL=EXCH)

TC (DERL) : TERMINATE + TC (DERL) :TRANSIT NAT

TC (DERL)

6. BHCA (Busy Hour Call Attempts)

No. of calls attempted/coming to the Exchange during Busy Hour.
BHCA
= OFFERRED CALLS IN THE BUSY HOUR
RECGOS(SEL=EXCH) = SUM OF TOTAL CALLS OF THE BUSY HOUR
RECGOS
= CC:INC+ CC:INC INAT+ CC:ORIG
___________________________________________________________________________________________
Page:4

Exchange Grade of Service (REC GOS)

This command activates the recording function for grade-of-service data for the entire exchange.
Prerequisites: - System time must be secure when the command is entered.
- The name of the measurement file is displayed on the OMT if disk output of traffic data is requested.
- Only one measurement job can be started.
- The traffic data are output to MDD file every 15 minutes within the selected measurement intervals.
- UNIT=OMT is not permissible for the grade-of-service measurement.
- At least 15 minutes elapse before the first data are output with immediate start.
- The measurement can be stopped with STOP JOB, except jobs with UNIT=MDD-DAILY.
- This command starts a semipermanent job. It can be canceled with CAN JOB. Input format
REC GOS : UNIT=

[,BEG=]

[,TER=]

[,IV=]

[,PER=] ;

UNIT = MDD-DAILY (for continous measurements: daily files are opened)

MDD-SINGLE (then single file is opened and the job can only start from the next
BEG = Begin date, TER = Last date , IV = Interval time ;

day )

TO OBTAIN RESULTS
GET TRAFILE : FILE=

[,SEL=]

[,BEG=]

[,TER=]

[,IV=] ;

If parameter SEL=EXCH is specified, then we get a filtered/summarised output of RECGOS.

COUNTERS PROVIDED BY REC GOS

When specifying selection parameter SEL=EXCH in command GET TRAFILE, the following counters are displayed on the
NetManager. These counters are calculated from selected measured values of the REC GOS measurement They pro-vide the
operator with an overview of the load status of the network node.
TC
Sum of traffic carried for incoming traffic (national & international incoming traffic) and for the originating traffic in dErl.
TOTAL CALLS
Total calls offered to the network node CP. The value of the counter is calculated as follows:
TOTAL CALLS= CC:KO+CC:KO INAT+ CC:ORIG.
SUCCESSFULL CALLS
Total number of successful calls of the network node. Successful calls are all calls for which the SN was through-connected
successfully. Counter values CCS REROUT-ING:TRTYP are subtracted from the total number of successful connections:

SUCCESSFULL CALLS = CCS SUB:TRTYP+ CCS PABX:TRTYP+ CCS TRUNK:TRTYP

- CCS REROUTING:TRTYP
ANSWERED CALLS
Total number of successful calls with answer of the B-subscriber terminal of the relevant traffic types (for traffic types, see counter
CCS WITH ANSWER ).

___________________________________________________________________________________________
Page:5

NTTAX/A39336D5000/INDCPK1V16314266/003
7131
OMT-01/JTOMTC
2893/06181
TRAFFIC MEASUREMENT : GRADE OF SERVICE
DATA QUALITY : SECURE
TC:EXCHANGE (DERL) =

06-06-26

12:16:33

06-06-26

11:30

91.107
N A T I O N A L

I N C O M I N G TRAFFIC
TERMINATE TRANSIT NAT
--------------------+------------+------------+------------+-----------TC (DERL)
0
87.398
TC WITH ANSWER(DERL)
0
64.674
CC
350.773
4
337.757
CCS WITH ANSWER
4
70.962
TC INTERCEPT (DERL)
6
0
381
CC ICEPT NO FAILURE
0
0
0
CC ICEPT FAILURE
560
0
9.807
CCS ICEPT NO FAIL SN
0
0
0
CCS ICEPT FAILURE SN
54
0
4.565
TC REROUTING (DERL)
7.307
0
7.277
CC REROUTING
49.206
0
39.131
CCU REROUTING
0
0
0
CCU RER BUSY
0
0
CCU RER FALLBACK
0
0
CCS REROUTING
0
49.206
CCS RER ANSWER
0
0
CCS RER BUSY
0
0
CCS RER INT TECHN I
0
17.742
CCS RER EXT TECHN I
0
31.464
CCS RER NO ANSWER
0
0
CCS SN REROUTING
0
20.675
CC QUEUING
0
0
CC QUEUING NOT POSS
0
0
CCU QUEUED CALL REL
0
0
CC PRECEDENCE
0
0
0
CC IN
0
CC IN NON CALL ASS
0
CC IN SERVICE FILTER
0
CC IN CONGESTION
0
CC IN SCP SER LOG ER
0
CC IN SCP NO ANSW
0
CC IN SERV NOT ACT
0
CC IN UNALL NUM
0
TC NO DIAL (MERL)
6
CC NO DIAL REL A
4
CC NO DIAL TIOUT
0
TC TEST CIRC (DERL)
0
CC TEST OF CIRCUIT
0
CC TEST OF TRUNK
1
CC LNP QUERY ON REL
0
CC LNP QUERY ON DA
0
CCU SN BUSY
0
0
0
CCU SUB BUSY
0
CCU TGRP BUSY
0
0
126.004
CCU TRUNKRESERVATION
0
0
CCU CMP DIAL REL A
6
0
0
CCU INCMP DIAL REL A
1.270
0
0
CCU INCMP DIAL TIOUT
515
0
0
CCU NM BLOCKING
0
CCU NM CANCEL TO
0
0
CCU NM CANCEL FROM
0
0
CCU INT TECHN IRREG
0
0
0
CCU EXT TECHN IRREG
10.085
0
0
CCU UNALL NUM
1.129
0
374
CCU TGRP BLOCKED
0
0
0
CCU NO SERV AUTH
0
0
CCU SUB NO CUG
0
0
CCU SP CONN REJ
0
CCU BLO BY SCREENING
18
0
CCU CTM SUB ABSENT
0
CCU PREEMPTED
0
0
0
CCU CCS7 DPC OLOAD
0
0
0
CCU CCS7 CCNC OLOAD
0
0
CCU IN SCP END
0
0
0
CCS SUB
4
CCS PABX
0
CCS TRUNK
211.414
CCS CALL FORWARDED
0
CCS CMP DIAL REL A
0
44.776
CCS CMP DIAL TIOUT
0
793
CCS INCMP DIAL REL A
0
228
CCS INCMP DIAL TIOUT
0
0

___________________________________________________________________________________________
Page:6

CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS

INT TECHN IRREG

EXT TECHN IRREG
COC FAIL ACT SN
LINK FAILURE
O/DEX SUB BUSY
O/DEX TGRP BUSY
O/DEX UNALL NUM
O/DEX TERM NCON
O/DEX SUB NO CUG
O/DEX CALL REJ
O/DEX SP CON REJ
NO SERV AUTH
RELORIG ENDTOEND
PREEMPTED
CCS7 NORM UNSPEC
CCS7 MAINT F A
CCS7 MAINT F B
IN SCP END

0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0

0
2.613
0
12.942
10.403
1.379
216
0
54
0
49
0
0
17.792
0
0
0

END TEXT JOB 7131

Now in the above sample for Fifteen minutes

OFFERRED CALLS

CC:TER+ CC:TR+ CC:TR NAT-INAT+ CCU:INC x)+ CC TEST:INC y)

=
=

CC:INC

BHCA

=
=

OFFERRED CALLS IN THE BUSY HOUR

350,783

PROCESSED CALLS

=
=

CALLS OFFERRED TO CP
CC:INC+ CC:INC INAT+ CC:ORIG - CC REROUTING:INC
- CC REROUTING:INC INAT - CC REROUTING:ORIG
350773 - 49206

350,783

=
=

301567

CIRCUIT SEIZURES

=
=
=

CCS SUB+CCS PBX+CCS TRUNK

211414 + 4 + 0
211418

ANSWERED CALLS

=
=
=

CCS WITH ANSWER:TERMINATE + CCS WIT ANSWER:TRANSIT

4 + 70962
70966

With the help of these basic parameters, we can calculate the Critical Exchange Performance Parameters as follows

1. Processing Efficiency

=
=
=

( Processed Calls / Offerred Calls ) * 100

( 301567 / 350783 ) * 100
85.97 %

2. Circuit Seizure Efficiency

=
=
=

( Circuit Seizures / Processed Calls ) * 100

( 211418 / 301567 ) * 100
70.11 %

3. A.S.R.

=
=
=

( Answered Calls / Circuit Seizures ) * 100

( 70966 / 211418 ) * 100
33.56 %

4. C.C.R.

Note :-

=
( Answered Calls / Offerred Calls ) * 100
=
( 70966 / 350783 ) * 100
=
20.23 %
Similarly the above calculations can be done for any duration e.g. One hour or One day by summing
up the corresponding counter values for all fifteen minute records in that duration.

___________________________________________________________________________________________
Page:7

Exchange grade-of-service and load measurement (GOS:SEL=EXCH)

If parameter SEL=EXCH is specified, then we get a filtered/summarised output of RECGOS as given
below.
TRAFFIC MEASUREMENT : EXCHANGE
DATE

TIME

TC (DERL)

TOTAL
SUCCESSFUL ANSWERED
DATA
CALLS
CALLS
CALLS
QUALITY
--------+------+----------+----------+----------+-----------+----------02-04-09 18:00
17820
30683
29950
9261
SECURE
02-04-09 18:15
18341
32637
31772
9241
SECURE
02-04-09 18:30
19006
36382
33961
9396
SECURE
02-04-09 18:45
18682
35814
33352
9289
SECURE
02-04-09 19:00
19744
35527
34688
9588
SECURE
02-04-09 19:15
21882
42001
41065
10426
SECURE
02-04-09 19:30
24224
45470
44344
11270
SECURE
02-04-09 19:45
26855
52154
51024
12330
SECURE
02-04-09 20:00
29513
56052
54695
13286
SECURE
02-04-09 20:15
44253
89291
87034
19008
SECURE
02-04-09 20:30
52037
106818
102605
21417
SECURE
02-04-09 20:45
53492
108116
103812
21535
SECURE
02-04-09 21:00
54621
105770
102449
22016
SECURE
02-04-09 21:15
60248
110373
106012
24007
SECURE
02-04-09 21:30
60801
102603
99361
23647
SECURE
02-04-09 21:45
63040
99502
96302
24128
SECURE
02-04-09 22:00
59577
83874
81182
22082
SECURE
02-04-09 22:15
56239
73391
70038
20211
SECURE
02-04-09 22:30
45565
56505
53694
16396
SECURE
02-04-09 22:45
48146
53374
50844
17532
SECURE
02-04-09 23:00
40604
38586
37476
14945
SECURE
02-04-09 23:15
34022
32793
32035
11197
SECURE
02-04-09 23:30
23761
21799
21392
6898
SECURE
02-04-09 23:45
17197
15174
14896
4684
SECURE
From the above output for one full day, we can find out the busiest hour of the day i.e. Four consecutive intervals in
which the Traffic Carried figure i.e. TC(DERL) is highest
BUSY HOUR

21:15 to 22:15

=
=

TC1 + TC2 + TC3 + TC4

------------------------------------ Erlang
4*10
( 60248+60801+63040+59577 ) / 40
6091.65 Erlang

BHCA

=
=
=
=

Sum of Total Calls of the BUSY HOUR

Total calls 1 + Total calls 2 + Total calls 3 + Total calls 4
110373+102603+99502+83874
396352

Traffic/1000 BHCA

Traffic Carried X 1000

----------------------------BHCA

Traffic Carried in BUSY HOUR =

( 6091.65 X 1000 ) / 396352

15.37

___________________________________________________________________________________________
Page:8

Exchange Grade of Service (REC EXCH)

This command is used to record exchange load and traffic data of calls carried and rejected due to network
management and internal protection mechanisms.
Prerequisites:
- System time must be secure when the command is entered.
Notes:
- The name of the measurement file is displayed on the OMT if disk output of traffic data is requested.
- A maximum of 1 job of this type may be entered at the same time.
- The traffic data are output every 15 minutes within the selected measurement intervals.
- At least 15 minutes elapse before the first data are output with immediate start.
- The measurement can be stopped with STOP JOB, except jobs with UNIT=MDD-DAILY.
- This command starts a semipermanent job. It can be canceled with CAN JOB.
Input format
REC EXCH : UNIT=

[,BEG=]

[,TER=]

[,IV=]

NTTAX/A39336D5000/INDCPK1V16314266/003
7850
OMT-01/JTOMTC
2889/08463

[,PER=] ;
06-06-28

TRAFFIC MEASUREMENT : EXCHANGE DATA

12:33:56

06-06-26

11:30

DATA QUALITY : SECURE

PROCESSOR LOAD
CALL PROCESSING LOAD
OFFERED SEIZURES
CC
CCU LEAKY BUCKET
CCU TRUNK RESERVATION
CCU CANCELTO
CCU ALL TRUNKS BUSY
CCU INT PROT MECH
CCS WITH ANSWER
CONGESTION LEVEL

841
744
304909
211418
0
0
0
126004
3332
70966
0

END TEXT JOB 7850

OFFERRED SEIZURES

= No. of Calls offered to the EXCH / LTG

= 304909

PROCESSED CALLS
OR
CALLS OFFERRED TO CP

= OFFERRED SEIZURES CCU INT PROT MECH

= 304909 3332
= 301577

CIRCUIT SEIZURES

= SUCCESSFUL CALLS
= CC
= 211418

ANSWERED CALLS

= CCS WITH ANSWER

= 70966

___________________________________________________________________________________________
Page:9

Now in the above sample for Fifteen minutes

1. Processing Efficiency

=
=
=
=

2. Circuit Seizure Efficiency

= ( Circuit Seizures / Processed Calls ) * 100

= ( 211418 / 301577 ) * 100
= 70.11 %

3. Answer to Seizure Ratio

= ( Answered Calls / Circuit Seizures ) * 100

= ( 70966 / 211418 ) * 100
= 33.56 %

4. C.C.R.

= ( Answered Calls / Offerred Calls ) * 100

= ( 70966 / 304909 )
= 23.27 %

Note :-

( Processed Calls / Offerred Calls ) * 100

( OFFERED SEIZURES - CCU INT PROT MECH)*100 / OFFERED SEIZURES
( 301577 / 304909 ) * 100
98.90 %

Similarly the above calculations can be done for any duration e.g. One hour or One day by summing
up the corresponding counter values for all fifteen minute records in that duration.

COUNTERS PROVIDED BY REC EXCH

PROCESSOR LOAD
This counter specifies the mean load (in mErl) of all CP processors. The mean load is determined from the load values
of the base processors (BAP master and BAP spare) and of the switching processors (CAP0...CAP9).
CALL PROCESSING LOAD
This counter specifies the mean call processing load (in mErl) of all CP processors. Themean value is determined
from the call processing load values of the base processors (BAP master and BAP spare) and the switching
processors (CAP0...CAP9).
CONGESTION LEVEL
This counter comprises the exchange overload level. The counter can output any of the following values: 0, 1, 2, 3.
The output values are generated as follows from the overload level of the exchange:
Overload level
Congestion level

0
0

123
1

456
2

7
3

OFFERED SEIZURES
This counter specifies the number of offered calls at the exchange. The output value is the total of the corresponding
counter values for all active and conditionally blocked LTGs in the exchange.
CCU INT PROT MECH
Number of seizures rejected by GP of trunk circuits and subscriber circuits due to internal protective measures of the
LTG. Reasons for the rejection of the seizures are LTG-/CP-CPU overload, SEIZURE_A call rate too high, lack of GP
resources such as heap deficit or the threshold value in the task queue / available queue is exceeded. Seizures
rejected due to a lack of code receivers are not logged. The output value is the sum of the corresponding counter
values for all active and conditionally blocked LTGs in the ex-change.
CC
Total of accepted calls in the network node. The counter value is calculated from the counters of the REC GOS
measurement in the following way:
CC = CCS SUB+CCS PBX+CCS TRUNK.
___________________________________________________________________________________________
Page:10

CCU CANCELTO
Number of rejected calls for outgoing and bidirectional trunks due to network management activity CANCELTO.
Parameter CANTO (command ENTR NMCNTL) deter-mines the type of control for searching
for free lines of certain trunks.
CCU LEAKY BUCKET
Number of rejected calls which are released in the home exchange due to network management activity LEAKY
BUCKET before SN through-connection. The leaky bucket mechanism allows the traffic to be directed dynamically
onto specific trunk groups. The threshold value for the seizures of a trunk group can be set with parameter LBUCLCR
(command CR CBPGRP).
CCU ALL TRUNK BUSY
Number of unsuccessful seizures in the home exchange because the serving line to the following exchange (traffic
directions OUTOR, OUTOR INAT, TR, TR INAT NAT, TR INAT INAT, and TR NAT INAT) is occupied (recognized
before SN through-connection). All PBX lines busy is not recorded by this counter.
CCU TRUNK RESERVATION
Number of connections rejected before SN through-connections due to trunk reservation in the accessed outgoing
trunk of the exchange.
CCS WITH ANSWER
Sum of the number of seizures with answer from the called subscribers terminal in the specified traffic directions. The
counters are updated only at the end of the connection. DATA QUALITY and AVAILABILITY
The measurement REC EXCH is a measurement for the entire network node and supplements the measurement REC GOS.
It records the ex-change load, the number of accepted calls, and the number of calls rejected due to network management
activities.

TRUNK GROUP OBSERVATION ( REC TGRP )

This command enables trunk group data to be recorded.
- The name of the measurement file is displayed on the OMT if disk output of traffic data is requested.
- A maximum of 8 jobs of this type may be entered at the same time.
- The same measurement object may not be specified in more than one job.
- The traffic data are output every 15 minutes within the selected measurement intervals.
At least 15 minutes elapse before the first data are output with immediate start.
- The measurement can be stopped with STOP JOB, except jobs with UNIT=MDD-DAILY.
This command starts a semipermanent job. It can be canceled with CAN JOB.
Input format
REC TGRP : TGNO= [,OPMODE=]
[,TGRPTYP=] [,FORMAT=] ,
[,TER=] [,IV=] [,PER=] ;

UNIT= [,BEG=]

___________________________________________________________________________________________
Page:11

Take The following parameters from RECTGRP Output

TRAFFIC MEASUREMENT : TRUNK GROUP

05-08-30

19:15

TGNO
:
BAFZ
BARTL
BBDX
BBGM
OPMODE/TGRPTYP :
BW
BW
BW
BW
AVAILABILITY
:
--------------------+---------+-------+-------+-------+-------+------CC:I
42
0
697
52
TC:I (DERL)
59
0
409
45
CCS WITH ANSWER:I
20
0
202
13
TC ANSWER:I (DERL)
43
0
308
30
CC:O
148
0
380
89
TC:O (DERL)
61
0
312
98
CCS WITH ANSWER:O
39
0
151
42
CONNECTED LINES
30
0
215
60
NO OF BLO LINES(ERL)
0
0
0
0
SEMI BLOCKED LINES
0
0
0
0
TRANS BLOCKED LINES
0
0
0
0
TGRP BLO TIME:O(SEC)
0
0
0
0
ATB TIME (SEC)
0
900
0
0
NUMBER OF ATB
0
0
0
0
CCS CONGESTION
0
0
8
0
CCS INCMP DIAL
0
0
3
3
CCS UNALL NUM
25
0
28
4
CCS RELORIG ENDTOEND
0
0
0
0
CCS SUB BUSY
68
0
64
18
CCS INT TECHN IRREG
0
0
0
0
CCS EXT TECHN IRREG
4
0
13
0
CCS UNANSWERED
9
0
90
15
CCU SUM OFL/LOSS
0
0
0
0
CCU LOST CALLS
0
0
0
0
CCU NM TGRP BLOCKING
0
0
0
0
CCU TECHN IRREGULAR
0
0
0
0
CCU TGRP BLOCKED
0
0
0
0
CCU TRUNKRESERVATION
0
0
0
0
CCU ALL TRUNKS BUSY
0
0
0
0
QOS TRAFFIC CONTROL
0
0
0
0
NUMB CCS7 DPC OLOAD
0
0
0
0
CCS7 DPC OLOAD (SEC)
0
0
0
0
CCS CCS7 NORM UNSPEC
0
0
13
0
CCU CCS7 CCNC OLOAD
0
0
0
0
CCU CCS7 DPC OLOAD
0
0
0
0
CCU CCS7 DPC OL ACC
0
0
0
0
CC PRECEDENCE:I
0
0
0
0
CC PRECEDENCE:O
0
0
0
0
CC PREEMPTED:I
0
0
0
0
CC PREEMPTED:O
0
0
0
0

O/G Calls Processed: This shall be applicable to OG & BW TRUNK GROUP(TGNO)

In case of OG TGNO it shall be the summation of CC:O for the specified date/time range for all the 15 minute
intervals.In case of BW TGNO it shall be the summation of CC:O for the specified date/time range for all the 15 minute
intervals.
I/C Calls Processed:This shall be applicable to IC & BW TRUNK GROUP(TGNO)
In case of IC TGNO it shall be the summation of "CC:I" for the specified date/time range for all the 15 minute
intervals.In case of BW TGNO it shall be the summation of "CC:I" for the specified date/time range for all the 15 minute
intervals.
O/G Calls Answered: This shall be applicable to OG & BW TRUNK GROUP(TGNO)
In case of OG TGNO it shall be the summation of "CCS WITH ANSWER:O" for the specified date/time range for all the
15 minute intervals.In case of BW TGNO it shall be the summation of "CCS WITH ANSWER:O" for the specified
date/time range for all the 15 minute intervals.
I/C Calls Answered: This shall be applicable to IC & BW TRUNK GROUP(TGNO)
In case of IC TGNO it shall be the summation of "CCS WITH ANSWER:I" for the specified date/time range for all the
15 minute intervals.In case of BW TGNO it shall be the summation of "CCS WITH ANSWER:I" for the specified
date/time range for all the 15 minute intervals.
O/G CCR % ={(O/G Calls Answered)/(O/G Calls Processed)}100
I/C CCR % ={(I/C Calls Answered)/(I/C Calls Processed)}100
___________________________________________________________________________________________
Page:12

2. CCR ANALYSIS & IMPROVEMENT

For analysing reasons for Low CCR, it is necessary to initiate and analyse the traffic recordings for Grade of Service,
Exchange and Trunk Groups. From these measurements, information can be obtained for example
-

from GOS and TGRP reports regarding the CCU TGRP BUSY and ATBT cases.
from GOS and TGRP reports regarding calls failures due to own System/Network
from GOS and TGRP reports regarding calls failures due to Partner Exchange or Network.
from GOS and TGRP reports regarding calls failures due to Subscriber behaviours.

Accordingly action can be taken depending upon the reasons of call failures e.g. If the TGRP BUSY / ATBT event is
occurring significantly for a TGRP then provisioning of additional trunks may be required to improve the CCR.If
rejection is coming from the partner exchange or network then the matter should be taken up with your Partner
Exchanges.
You are therefore requested to initiate and analyse Traffic measurements in EWSD and also send us the same for
further comments. We are attaching information containing General suggestions for CCR improvement. Also inform
us in detail
1.
2.
3.
4.
5.

How you are analyzing and calculating CCR and other critical performance parameters?
What CCR and other parameter values you are getting ?
What are the prominent causes for call failures observed by you?
What is the Call failure rate during high and low traffic hours?
Output of various Traffic reports running in the EWSD, e.g. RECGOS,RECTGRP and RECDLU

The following commands can be used to initiate Traffic Jobs in EWSD

RECGOS:UNIT=MDD-DAILY
RECEXCH:UNIT=MDD-DAILY
RECTGRP:UNIT=MDD-DAILY, TGNO=____;
To extract the output, please use the following commands
GETTRAFILE : FILE = TS.GOSX.MO1;
GETTRAFILE : FILE = TS.EXCH.MO1;
GETTRAFILE : FILE = TS.TGRP.MO1;
For further analysis, please send us the soft copy of GETTRAFILE output for peak hour of above traffic reports
alongwith the concerned raw traffic file ( e.g. TS.GOSX.MO1, TS.EXCH.MO1, TS.TGRP.MO1 etc.) and the
calculations done by you regarding CCR and other Critical Performance parametres by email at the following address
SPCNL.TAC2@SIEMENS.COM
Please send us the data asap to analyse the case further.

___________________________________________________________________________________________
Page:13

Suggestions for CCR Improvement:

In order to analyse and improve Low CCR, we would like you to perform the following actions at your end to reduce
the possibility of call failures due to fault in your own Exchange
1. Monitor the status of PCM for SLIPS/Flicks etc. using DISPPCMAC command.
2. Check Charging database of your Exchange for missing charging info (e.g. missing ZOPT, CHB No. etc.)
3. Check Routing database of your Exchange for some undefined or incomplete routing of some codes. (e.g.
missing Code points or missing routes etc.)
4. To find the reason for low CCR, Traffic measurements on TGRP, DEST, DLU, EXCH and Grade of Service
(GOS) should be started and analysed. From these reports you can identify the TGRPs / Codes etc. where
the maximum number of calls are failing along with some reasons for the call failures. Those TGRPs/Codes
etc. can be individually analysed to identify the prominent reasons for call failures.
5. Since there are so many error counters which get incremented due to a lot of reasons, therefore it is not
possible to make a general comment. Kindly analyze a few calls which fail using SIGN TRAC or any other
protocol analyzer. The protocol analyser will have to be connected to the TGRP to trace calls on this TGRP
and then the exact analysis of the same will have to be carried out to find where the problem exists.
6. If Protocol analyser is not available, Signal tracer may be used but it may not provide the exact scenario as it
traces only one call at a time.The Protocol analyzer Log / Signal Trace along with the created database may
then be analysed. After the various cases of call failure have been found, each of these will have to be tackled
separately.
7. For call failures due to subscriber behaviours e.g. CCS INCMP DIAL, CCS SUB BUSY, CCS UNANSWERED
etc., nothing much can be done about it and hence no suggestion/activity required.
8. Additionaly in case of counters which get incremented due to calls rejected by the partner Exchange/Network,
the various reasons have to be taken up with the partner Exchange individually.
By following the above steps you can eliminate or minimize reasons of Low CCR at your Exchange. For reasons
pertaining to subscriber behaviour nothing much can be done apart from educating the subscribers and for reasons
related call rejection due to network or partner Exchanges, please take up the matter with your partner Exchange and
get the same sorted out.
Please note that the CCR depends on the network planning of the resources. The CCR can be improved by analyzing
the traffic recordings for TGRP and GOS. For example, information can be obtained from these recordings regarding
the CCU TGRP BUSY(GOS) and ATBT (TGRP) cases. If the TGRP BUSY / ATBT event is occurring significantly for a
TGRP then provisioning of additional trunks may be required to improve the CCR.
The following commands can be used to initiate Traffic Jobs in EWSD
RECGOS:UNIT=MDD-DAILY
RECEXCH:UNIT=MDD-DAILY
RECTGRP:UNIT=MDD-DAILY, TGNO=____;
To extract the output, please use the following commands
GETTRAFILE : FILE = TS.GOSX.MO1;
GETTRAFILE : FILE = TS.EXCH.MO1;
GETTRAFILE : FILE = TS.TGRP.MO1;
For further analysis, please send us the soft copy of GETTRAFILE output of above traffic reports alongwith the raw
traffic file ( e.g. TS.GOSX.MO1, TS.EXCH.MO1, TS.TGRP.MO1 etc.) by email at the following address
SPCNL.TAC2@SIEMENS.COM
___________________________________________________________________________________________
Page:14

3. : COMMON ERROR COUNTERS:

1. CCU INT TECHN IRREG:TRTYP
Number of call attempts that were unsuccessful due to internal technical irregularities (recognized before SN through
connection).The release event detected by the call-processing software in the CP is sent as a reason for call
termination (RCT) in a command, e.g. TERMINATE, to the A-side LTG and in some cases also to the B-side LTG.
The call is then prematurely terminated.
The reasons for call termination listed below cause the above counter to be updated if received before SN throughconnection:
RCT_NO_REASON
RCT_CALL_REJ
RCT_UPDATE_PARN_FAIL
RCT_NETWORK_OUT_OF_ORDER
RCT_NETWORK_FAILURE
RCT_CALL_PICK_UP_FAILURE
RCT_CALL_CANCELLED
RCT_SUB_LINE_TMP_OUT_OF_ORDER
RCT_INTERNAL_CONGESTION_ROTL
RCT_LACK_OF_RESOURCES
RCT_LACK_OF_CHRS
RCT_OVERLOAD_CP
RCT_PORT_BLOCKED
RCT_A_SIDE_BLOCKED_TRANS
RCT_UNEQUIPPED_CIC_RECEIVED
RCT_PARTNER_LTG_NAC
RCT_CHR_NOT_SECURABLE
RCT_DATABASE_FAILURE
RCT_INVALID_MESSAGE_DATA
RCT_INVALID_LINKAGES
RCT_SPL_EXCEEDED
RCT_CONFL_NUM_OF_PARTIES_EXCEED
RCT_CONFL_RECOURCES_UNAVAILABLE
RCT_FORCE_REL_WITH_SIGN
RCT_TENTATIVE_REL_WITH_SIGN
RCT_FORCE_REL_WITHOUT_SIGN
RCT_TENTATIVE_REL_WITHOUT_SIGN
RCT_MISROUTE_CALL_TO_PORTED_NUM
RCT_PREEMPTION
RCT_PREEMPTION_CIRC_RES_FOR_REUS
RCT_RESERVE_

0
8
15
21
22
29
37
42
121
125
126
129
147
148
153
157
158
160
161
162
173
179
180
181
182
183
184
191
232
233
185; ..._255,

The release event detected by the call-processing software in the LTG (GP) is sent as a reason for call failure (RCF)
in the LTG release message to the CP. The call is then prematurely terminated. The reasons for call failure listed
below cause the following counters to be updated if received before SN through-connection:
RF_A_SIDE_CALL_CANCELLED
137
RF_INTERNAL_FAILURE_A_SIDE
192
RF_A_SIDE_RESTART
195
RF_A_SIDE_NEWSTART
197
RF_TIME_OUT_WAIT_FOR_CP_REACTION 201
RF_NO_ZONE_VALUE_AT_ANSWER_TIME 205
___________________________________________________________________________________________
Page:15

RF_A_SIDE_MODULE_REMOVED
RF_A_SIDE_DIU_FAILURE

206
210

___________________________________________________________________________________________
Page:16

2. CCS INT TECH IRREG

Number of calls terminated after SN through-connection due to technical irregularities on the route between the
originating exchange and the own Exchange or in the own Exchange. Internal technical reasons for call failure
detected by the LTG after SN through-connection. This Field is mainly incremented due to relaese of Call from A-Side
e.g incomplete dialing / Digit Timeout after few digits have been received and B-Side has been seized. Additionally,
some database problem e.g non exisiting charge bands in the exchange.
The release event detected by the call-processing software in the LTG (GP) is sent as a reason for call failure (RCF)
in the LTG release message to the CP. The call is then prematurely terminated.
The reasons for call failure listed below cause the above counter to be updated if received after SN throughconnection:
RF_RESPONSE_TO_STATUS_ENQUIRY 30
RF_PERM_FRAMEM_CONN_OUT_OF_SERV 39
RF_PERM_FRAMEM_CONN_OPERATIONAL 40
RF_CHANNEL_GLARE 132
RF_PORT_GLARE 133
RF_SWITCH_GLARE 134
RF_TEST_CALL_GLARE 136
RF_A_SIDE_CALL_CANCELLED 137
RF_B_SIDE_CALL_CANCELLED 138
RF_INTERNAL_FAILURE_A_SIDE 192
RF_INTERNAL_FAILURE_B_SIDE 193
RF_CALL_FAILURE_INTERN 194
RF_A_SIDE_RESTART 195
RF_B_SIDE_RESTART 196
RF_A_SIDE_NEWSTART 197
RF_B_SIDE_NEWSTART 198
RF_TIME_OUT_WAIT_FOR_CP_REACTION 201
RF_ISDN_NO_TCB 203
RF_UPDATE_PARTN_FAILURE 204
RF_NO_ZONE_VALUE_AT_ANSWER_TIME 205
RF_A_SIDE_MODULE_REMOVED 206
RF_B_SIDE_MODULE_REMOVED 207
RF_A_SIDE_DIU_FAILURE 210
RF_B_SIDE_DIU_FAILURE 211
RCT_LTG_RELEASED 16
( Forced Release e.g. Audit )

Internal Technical Irregularity

The Figure of Internal Technical Irregularity in the Report can be because of the following reasons :

Some faults in the Hardware LTG/DLU/SN.

Some faults in the cable between DLULTG /LTGSN.
LTG local recoveries
SLIPS / Flicks on the PCM

To analyse the same, we request you

-to diagnose the LTGs / DLUs / SN and remove the faults if any.
-Observe the OMT for any messages of LTG recoveries and report them to us.
-Observe for slips on the PCM using command DISPPCMAC.
___________________________________________________________________________________________
Page:17

___________________________________________________________________________________________
Page:18

3. CCS EXT TECH IRREG

Number of calls terminated after SN through-connection due to external technical irregularities in the downstream
Exchange. The release event detected by the call-processing software in the LTG (GP) is sent as a reason for call
failure (RCF) in the release message from the LTGs (A-side and B-side) to the CP. The call is then prematurely
terminated. The reasons for call failure listed below cause the above counter to be updated if received in the release
message, e.g. RELEASE C, after SN through-connection:
RF_MFC_TIME_OUT_FAILURE_A_SIDE
10
RF_MFC_TIME_OUT_FAILURE_B_SIDE
11
RF_MFC_INVALID_MFC_SIGNAL_A_SIDE
12
RF_MFC_INVALID_MFC_SIGNAL_B_SIDE
13
RF_NETWORK_OUT OF_ORDER
38
RF_TEMPORARY_FAILURE
41
RF_ACCESS_INFORMATION_DISCARDED
43
RF_INVALID_CALL_REFERENCE_VALUE
81
RF_IDENTIF_CHNL_DOES_T_EXIST
82
RF_SUSP_CALL_EX_BUT_THIS_ID_NOT
83
RF_CALL_IDENTITY_IN_USE
84
RF_NO_CALL_SUSPENDED
85
RF_CALL_REQ_ID_HAS_BEEN_CLEARED
86
RF_INVLD_TRANSIT_NETW_SELECTION
91
RF_INVALID_MESSAGE_UNSPECIFIED
95
RF_MANDATORY_INFO_ELEM_MISSING
96
RF_MSG_TYPE_NOT_EXIST_NOT_IMPL
97
RF_MSG_N_COM_W_CALLS_NONEX_NOTI
98
RF_INFO_ELEM_PARAM_NONEX_NOTIMP
99
RF_INVALID_INFO_ELEM_CONTENTS
100
RF_MSG_NOT_COMP_WITH_CALL_STATE
101
RF_RECOVERY_ON_TIMER_EXPIRY
102
RF_PARAM_NONEX_NOTIMPL_PASSD_ON
103
RF_MSG_W_UNREC_PARAM_DISCARDED
110
RF_PROTOCOL_ERROR_UNSPECIFIED
111
RF_INTERWORKING_UNSPECIFIED
127
RF_NON_FAILURE_CASE_FOR_INTERCEPT
128
RF_TRUNK_GLARE
135
RF_OPERATOR_REJECT
140
RF_OPERATOR_PORT_GLARE
141
RF_OPERATOR_SPEECH_CHANNEL_GLARE
142
RF_ASSISTANCE_CANCELED
143
RF_DISCONNECT_OPERATOR_FROM_CONN
144
RF_OPERATOR_SYSTEM_REJECT
146
RF_IN_ANI_FAILURE
152
RF_CONTINUITY_FAILURE_OUTGOING
166
RF_CONTINUITY_FAILURE_INCOMING
167
RF_BLO_MSG_RECEIVED
173
RF_IMMEDIATE_RELEASE
191
RF_A_SIDE_DLU_FAILURE
212
RF_A_SIDE_CARRIER_FAILURE
216
F_B_SIDE_CARRIER_FAILURE
217
RF_A_SIDE_SUBSCRIBER_FAILURE
218
RF_B_SIDE_SUBSCRIBER_FAILURE
219
RF_A_SIDE_SIGNALING_FAILURE
220
RF_B_SIDE_SIGNALING_FAILURE
221
RF_B_SIDE_SIGN_FAILURE_WITH_REROUTE
222
RF_NO_SEIZURE_RESPONSE
224
RF_ANI_FAILURE
226
___________________________________________________________________________________________
Page:19

4. CCU EXT TECHN IRREG:TRTYP

Number of call attempts that were unsuccessful due to external technical irregularities (recognized before SN through
connection).The release event detected by the call-processing software in the LTG (GP) is sent as a reason for call
failure (RCF) in the LTG release message to the CP. The call is then prematurely terminated.
The reasons for call failure listed below cause the above counter to be updated if received before SN throughconnection.
RF_A_SIDE_DLU_FAILURE
RF_A_SIDE_CARRIER_FAILURE
RF_A_SIDE_SIGNALLING_FAILURE
RF_MFC_TIME_OUT_FAILURE_A_SIDE
RF_MFC_INVALID_MFC_SIGNAL_A_SIDE

212
216
220
10
12

5. CCU TECH IRREGULARITIES

The parameter CCU Tech Irregularity means that the call was not successfully switched through the switching network
of your own exchange. i.e. CALLS CARRIED UNSUCCESSFUL due to Technical irregularities. These are the Number
of calls prematurely terminated in the own exchange prior to connection through the SN due to internal blocking in the
SN, number unobtainable or internal or external technical irregularities from the originating exchange.
Following could be the reasons for CCU Tech. Irregularity,
* Due to internal blocking in the SN
* Number unobtainable
* Technical irregularities at the interface from the originating exchange.
Actions: Following are some actions to be done in your exchange.
1. Diagnose the switching network to rule out any HW fault in the SN.
2. Ask the originating exchange to increase the depth of analysis of codes so that less unallocated codes reach you.
3. Connect a K1205 tracer on the link towards the originating side for let us say in the busy hour and observe if there
are CFN (Confusion) messages or REL causes like Normal Unspecified, Resource Unavailable Unspecified. Etc
CCU TECHN IRREGULAR: Number of unsuccessful attempts to seize the TGRP due to a technical fault, e.g.
- Database fault/inconsistency
- Unsuccessful entering the trunk busy state
- SN blocking (no access to outgoing trunk)
- Force Release before SN-through connection
- Echo-Control-Device Loop could not be inserted
- Invalid message-data or an data-base-failure or a come-again-request for code-processing
- Not able to seize internal resources (not able to secure CHR, not able to release B-side CHR from maintenance, not
able to select a speech channel)
- ...
This reason results in Lost calls (no overflow).

___________________________________________________________________________________________
Page:20

6. CCS CCS7 CALL FAIL

Number of calls successfully switched to an outgoing server i.e. successfully connected through the SN (speech
channel and outgoing line seized) in the home exchange but terminated because the call was rejected in the
subsequent/downstream exchange with line signal CALL FAILURE,NORMAL_UNSPECIFIED, ANI_FAILURE,
CALL_DIVERSION etc.
Number of calls released after trunk group seizure (CC:O) because line signal CALL FAILURE (TUP) was received or,
in the case of ISUP, after receiving certain line signals (IUC) in CCS7 messages from which RCF CALL FAILURE is
derived. This field is mainly incremented for call with Reason of Call failure as Normal Un-Specified.
Since these counters are incremented due to a lot of reasons, it is not possible to make a general comment.
Kindly analyse a few calls which fail using SIGN TRAC or any other protocol analyser. After the various cases of call
failure have been found, each of these will have to be tackled separately.
If Protocol analyser is not available, Signal tracer may be used but it may not provide the exact scenario as it traces
only one call at a time.
The Protocol analyser Log / Signal Trace along with the created database may then be analysed.
7. UNALLOCATED NUMBER
CC IN UNALL NUM:TRTYP
Number of IN calls released because the subscriber dialed an invalid IN number
CCU UNALL NUM:TRTYP
Number of call attempts to unavailable (not created, not zoned, or blocked) destinations in the own exchange prior to
SN through-connection.
CCS O/DEX UNALL NUM:TRTYP
Number of unsuccessful calls after SN through-connection to unavailable destinations (not created, not zoned, or
blocked) in a downstream exchange or in a DID PBX
CCS UNALL NUM:O
Number of unsuccessful calls (terminations) after seizure of the subscriber CC:O (SN through-connection completed),
because the calls were rejected by the called LTG due to absence of authorization at the called subscriber. The
reasons for this are:
the offered semi-permanent connection is not allowed
the subscriber does not belong to the subscriber group that the calling subscriber is allowed to access
as call destination
the offered service of the call is not allowed.
CCS UNALL NUM
Number of calls released after trunk group seizure (CC:O) because the dialed directory number was not created or
because the calling party is not authorized to make calls to this destination (SPCONN, CUG and service).Number of
calls terminated after connection through the SN (in the own exchange) due to number unobtainable in a
downstream exchange.
Note: If the traffic measurement destination is an ISDN called party of a direct-dial PBX (with DID) in the own
exchange, this counter is also updated if a non-assigned directory number is dialed.
Suggestion: Check the Routing database created in the own Exch. along with the partner Exch. and see if there is
some error in database creation. In case any numbering Scheme / prefixing of digits have been done in the past, then
specifically check that database.

___________________________________________________________________________________________
Page:21

8. CCS CONGESTION
Number of calls released after trunk group seizure (CC:O) because the backward signal for congestion (all trunks
busy) was received from downstream exchanges (transit or destination exchange).
Suggestion: Check the reason of congestion with the partner exch.
9. CCS SUB BUSY
Number of calls released after trunk group seizure (CC:O) because the backward signal subscriber terminal busy
was received.
Suggestion: This is a subscriber behavior. However check if the subscribers are actually busy. Check the same with
the terminating exch. Traffic reports can be used to check the same.
10. CCU SUB BUSY
Suggestion: This is a subscriber behavior. However check how many subscribers of the exch. are in PG (Line Lockout
Condition). If this figure is high then the cases of SUB BUSY can be more.
11. CCS UNANSWERED
Number of calls released after trunk group seizure (CC:O) because the called party terminal does not answer (timeout
of ringing time supervision) or because the calling party releases the connection after end of dial status is reached in
the home exchange and before the called subscriber answers.
Suggestion: This is a subscriber behavior. However check the same with the originating and terminating exch.
12. CS LINK FAILURE
Number of calls rejected in the LTG after SN through-connection due to failure of a link between CP and LTG or
between LTG and DLU
Suggestion: This can be due to the link failure between the LTG and remote DLUs. In case these failures are High
then this failure will be more.
13. CCU TGRP BUSY
This is due to the All Trunk Busy in the trunk group.
Suggestion: Check if all the trunks in the trunk groups (OBWG, OATL, ODMS etc.) remains busy or not. If these are
actually busy then augment these trunk groups.
14. CCU COMP DIAL REL A:TRTYP
Number of seizures with complete dialing which are released by the A-subscriber before SN through connection. This
counter is usually counted in conjunction with feature use, e.g. if the A-subscriber has dialed the complete B-directory
number, but cannot be switched through to the B-subscriber due to the active feature Do not disturb.
Suggestion: This is a subscriber behavior. However check how many subscribers are using the Do not disturb
feature.
15. CCS O/DEX SUB BUSY:TRTYP
Number of unsuccessful calls due to "subscriber busy" after SN through-connection in the own exchange (ISDN traffic)
or in the destination exchange
Suggestion: Check if the lSDN subscriber lines are in disturbed condition.
___________________________________________________________________________________________
Page:22

16. CCU CCS7 DPC OL ACC

Number of calls offered to a circuit group with SS7 signaling which overflowed (high-usage circuit group) or were rejected
(final circuit group or only-choice circuit group) due to DPC overload in the destination exchange or a downstream
exchange.because the transmission buffer of the links for the selected outgoing server was full.
There is Problem in the TAX exchange and the CCS7 equipment in the tax seems to be overloaded.
In CCS7, once an MSU is sent to the partner exchange, it is kept in the re-transmission buffer till an acknowledgement for
the same is received. Since Tax is not able to read the data sent to it and sent the confirmation of the same so the same is
not deleted from our links which is leading to out transmission buffers getting full and the further calls to this exchange are
rejected.
Possible Solution :
1.Increase the Number of links to the Tax.
2.Discuss the same with Tax Personal and some expansion should be done in the CCS7 equipment of the Tax.
3.Converting some PCMs on MFCR-2 and creation of a TGRP Clusture.
17. CCS CCS7 NORM UNSPEC:TRTYP
Number of calls successfully switched to an outgoing server but terminated because the call was rejected in a downstream
exchange with line signal CALL FAILURE (TUP) respectively Cause NORMAL UNSPECIFIED (ISUP). Lists of reasons for
termination which cause the EWSD network node with SS7 signaling to send line signal CALL FAILURE (TUP) respectively Cause
NORMAL UNSPECIFIED (ISUP).
These events are detected in the LTG (basic TUP and TUP+) of the EWSD destination exchange and cause it to send the CALL
FAILURE line signal in the TUP orders (SS7 messages). If the CALL FAILURE order is received by the upstream exchange, CALL
FAILURE is sent as the reason for call failure in the release message (A-side and B-side) to the CP and recorded by the following
counters:CALL FAILURE is derived from the following reasons for call failure (RCF) in the EWSD destination exchange:
RCFs that result in order CALL FAILURE in the TUP+ (Telekom):
RF_FORCED_RELEASE/ NO_FAILURE
RF_NORMAL_UNSPECIFIED
RF_PORT_GLARE
RF_SWITCH_GLARE
RF_TRUNK_GLARE
RF_TEST_CALL_GLARE
RF_A-SIDE_CALL_CANCELLED
RF_B-SIDE_CALL_CANCELLED
RF_TERMINATED_BY_CP
RF_OPERATOR_PORT_GLARE
RF_OPERATOR_SPEECH_CHANNEL_GLARE
RF_ASSISTANCE_CANCELLED
RF_DISCONN_OPERATOR_FROM_CONNECT
RF_OPR_ABANDONED_CALL_DURING_DI
RF_IN_SCP_INITIATED_END
RF_IN_CCS7_GLOBAL_OVERLOAD
RF_IN_SCP_DIALOGUE_FAILED
RF_CTX_FEATURE_NOT_SUBSCRIBED
RF_INVALID_FEATURE_INTERACT
RF_CTX_NON_FAILURE_REROUTE
RF_CTX_CAMP_ON_UNSUCC_NO_REPLY
RF_HW_FAIL_ORIENT_BWD_BLOCKED_B
RF_B-SIDE GROUP RESET CIRCUIT
RF_BLOCKING_MESSAGE_RECEIVED
RF_CALL_FORWARDING_REFUSED
RF_SCI_FEATURE_UNSUCCESSFUL
RF_CALL_FAILURE_INTERN

___________________________________________________________________________________________
Page:23

RF_UPDATE_PARTNER_FAILURE
RF_NO_ZONE_VALUE_AT_ANSWER_TIME
RF_B-SIDE_MODULE_REMOVED
RF_A-SIDE_SUBSCRIBER_FAILURE
RF_B-SIDE_SUBSCRIBER_FAILURE
RF_RELEASE_BY_ORIGIN_END_TO_END
RF_ANI_FAILURE
RF_CALL_DIVERSION
RCFs that result in CALL FAILURE in the basic TUP
RF_NO_ROUTE_TO_SPEC_TRANSIT_NET
RF_CHANNEL_UNACCEPTABLE
RF_CALL_AWARDED_DEL_ESTAB_CHNL
RF_PREEMPTION
RF_PREEMPTION_CIRC_RSVD_F_REUSE
RF_NORMAL_CALL_CLEARING
RF_NO_USER_RESPONDING
RF_NO_ANSWER_FROM_USER
RF_NON_SELECTED_USER_CLEARING
RF_RESPONSE_TO_STATUS_ENQUIRY
RF_NORMAL_UNSPECIFIED
RF_PERM_FRAMEM_CONN_OUT_OF_SERV
RF_PERM_FRAMEM_CONN_OPERATIONAL
RF_TEMPORARY_FAILURE
RF_ACCESS_INFORMATION_DISCARDED
RF_REQ_CIRCUIT_CHNL_NOT_AVAILA
RF_PRECEDENCE_CALL_BLOCKED
RF_RESOURCE_UNAVAILABLE_UNSPECI
RF_QUALITY_OF_SERVICE_UNAVAILAB
RF_REQ_FACILITY_NOT_SUBSCRIBED
RF_BEARER_CAPAB_NOT_AUTHORIZED
RF_BEARER_CAPAB_NOT_PRES_AVAIL
RF_INCONS_OUTG_ACC_INF_SUBCLASS
RF_CHANNEL_TYPE_NOT_IMPLEMENTED
RF_REQ_FACILITY_NOT_IMPLEMENTED
RF_RSTR_DIG_INF_BEARER_CAPAB_AV
RF_SERV_OR_OPT_NOT_IMPLM_UNSPEC
RF_INVALID_CALL_REFERENCE_VALUE
RF_IDENTIF_CHNL_DOES_NOT_EXIST
RF_SUSP_CALL_EX_BUT_THIS_ID_NOT
RF_CALL_IDENTITY_IN_USE
RF_NO_CALL_SUSPENDED
RF_CALL_REQ_ID_HAS_BEEN_CLEARD
RF_USER_NOT_MEMBER_OF_CUG
RF_NON_EXISTENT_CUG
RF_INVLD_TRANSIT_NETW_SELECTION
RF_INVALID_MESSAGE_UNSPECIFIED
RF_MANDATORY_INFO_ELEM_MISSING
RF_MSG_TYPE_NOT_EXIST_NOT_IMPL
RF_MSG_N_COM_W_CALLS_NONEX_NOTI
RF_INFO_ELEM_PARAM_NONEX_NOTIMP
RF_INVALID_INFO_ELEM_CONTENTS
RF_MSG_NOT_COMP_WITH_CALL_STATE
RF_RECOVERY_ON_TIMER_EXPIRY
RF_PARAM_NONEX_NOTIMPL_PASSD_ON
RF_MSG_W_UNREC_PARAM_DISCARDED
RF_INTERWORKING_UNSPECIFIED
RF_NON_FAILURE_CASE_FOR_INTERCE
RF_ANNOUNCEMENT_TIMEOUT
RF_CONVERSATION_TIME_LIMIT_EXPI
RF_TEST_CALL_GLARE
RF_A_SIDE_CALL_CANCELLED

___________________________________________________________________________________________
Page:24

RF_B_SIDE_CALL_CANCELLED
RF_TERMINATED_BY_CP
RF_ASSISTANCE_CANCELLED
RF_DISCONNECT_OPERATOR_FROM_CON
RF_OPR_ABANDONED_CALL_DURING_DI
RF_OPERATOR_SYSTEM_REJECT
RF_IN_SCP_NO_ANSWER
RF_IN_SCP_INITIATED_END
RF_IN_CCS7_GLOBAL_OVERLOAD
RF_IN_SCP_DIALOGUE_FAILED
RF_CTX_FEATURE_NOT_SUBSCRIBED
RF_CTX_INVALID_FEATURE_INTERACT
RF_CTX_NON_FAILURE_REROUTE
RF_CONTINUITY_FAILURE_INCOMING
RF_HW_FAIL_ORIENT_BACKW_BLOCK_B
RF_STOP_TRAFFIC_B_SIDE
RF_B_SIDE_GROUP_RESET_CIRCUIT
RF_TRUNK_OFFERING_REFUSED
RF_SUB_FREE_TRUNK_OFFER_REFUSED
RF_CALL_FORWARDING_REFUSED
RF_CALL_ABAND_AFTER_FIRST_DIGIT
RF_INTERNAL_FAILURE_A_SIDE
RF_INTERNAL_FAILURE_B_SIDE
RF_CALL_FAILURE_INTERN
RF_A_SIDE_RESTART
RF_B_SIDE_RESTART
RF_A_SIDE_NEWSTART
RF_B_SIDE_NEWSTART
RF_COC_RETRY_FAILURE
RF_TIMEOUT_WAIT_FOR_CP_REACTION
RF_TIMEOUT_WAIT_FOR_CODE_RECEIV
RF_ISDN_NO_TCB
RF_UPDATE_PARTNER_FAILURE
RF_NO_ZONE_VALUE_AT_ANSWER_TIME
RF_A_SIDE_MODULE_REMOVED
RF_B_SIDE_MODULE_REMOVED
RF_A_SIDE_DIU_FAILURE
RF_B_SIDE_DIU_FAILURE
RF_A_SIDE_DLU_FAILURE
RF_B_SIDE_DLU_FAILURE
RF_DLU_CONGEST_REROUTE_NOT_POSS
RF_A_SIDE_CARRIER_FAILURE
RF_B_SIDE_CARRIER_FAILURE
RF_A_SIDE_SUBSCRIBER_FAILURE
RF_B_SIDE_SUBSCRIBER_FAILURE
RF_A_SIDE_SIGNALING_FAILURE
RF_B_SIDE_SIGNALING_FAILURE
RF_INVALID_DIGIT_RECEIVED
RF_RELEASE_BY_ORIGIN_END_TO_END
RF_EXT_UNSUCCESSFUL_BACKW_INFO
RF_CHANGED_DID_NUMBER
The CALL_FAILURE event sent in the ISUP line signal normal unspecified by the EWSD destination exchange to the upstream
exchange is recorded in the following counters:
RF_NORMAL_UNSPECIFIED
RF_OPERATOR_PORT_GLARE
RF_OPERATOR_SPEECH_CHANNEL_GLARE
RF_ASSISTANCE_CANCELLED
RF_DISCONNECTED_OPERATOR_FROM_CONNECTION
RF_OPR_ABANDONED_CALL_DURING_DIAL
RF_IN_SCP_NO_ANSWER
RF_IN_SCP_INITIATED_END

___________________________________________________________________________________________
Page:25

RF_IN_SCP_DIALOGUE_FAILED
RF_HW_FAIL_ORIENT_BACKW_BLOCK_A
RF_HW_FAIL_ORIENT_BACKW_BLOCK_B
RF_B_SIDE_GROUP_RESET_CIRCUIT
RF_BLO_MSG_RECEIVED
RF_UPDATE_PARTNER_FAILURE
RF_NO_ZONE_VALUE_AT_ANSWER_TIME
RF_CALL_DIVERSION

18. CCU UNSPECIFIED

The counter is the default counter for the number of unsuccessful calls rejected prior to connection through the SN in
the own network node. In the counter all the other reason are counted which are not registered in one of the other
specific CCU counters CCU CONGESTION, CCU NM CODE BLOCKING, CCU NM TGRP BLOCKING or CCU
TECHN IRREGULAR.
Such reasons are e.g.
internal blocking in the SN
number unobtainable
internal technical irregularities
blocked number
no service authorization
blocked by screening

Please investigate for the above causes on call by call basis, you can activate signal trace for such calls wherein the failure rate i
high and then observe various RCF (reasons for call failure). Also perform the diagnosis and testing of complete SN.

___________________________________________________________________________________________
Page:26