Вы находитесь на странице: 1из 27

Office of the Chief General Manager

National Centre for Electronic Switching


ARA Centre, Mezzanine Floor
E-2, J handewalan 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 in-
charges 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. KANAUJ IA)
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











___________________________________________________________________________________________
Page:3
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%.

Processed Calls
Processing Efficiency = ------------------------ *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.

Answered Calls
Answer to Seizure Ratio (ASR) = ------------------------- *100
Circuit Seizures

4. 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.

Answered Calls
Overall Call Processing Efficiency (CCR) = -----------------------*100
Offered Calls

5. 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.

Total Transit Traffic
Traffic / 1000 BHCA = ------------------------- *1000
Offered Calls

6. 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:4
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) = SUM OF TOTAL CALLS OF THE BUSY HOUR
RECGOS = 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.
CCS:SUB+CCS:TRUNK+CCS:PBX
RECEXCH CC

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 CCS WITH ANSWER
RECGOS CCS WITH ANSWER:TERMINATE +CCS WITH ANSWER:TRANSIT NAT
RECGOS(SEL=EXCH) 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 TC (DERL) : TERMINATE +TC (DERL) :TRANSIT NAT
RECGOS(SEL=EXCH) 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:5
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 J OB, except jobs with UNIT=MDD-DAILY.
- This command starts a semipermanent job. It can be canceled with CAN J OB. 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 day )
BEG =Begin date, TER =Last date , IV =Interval time ;


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:6
NTTAX/ A39336D5000/ I NDCPK1V16314266/ 003 06- 06- 26 12: 16: 33
7131 OMT- 01/ J TOMTC 2893/ 06181

TRAFFI C MEASUREMENT : GRADE OF SERVI CE 06- 06- 26 11: 30
DATA QUALI TY : SECURE

TC: EXCHANGE ( DERL) = 91. 107
N A T I O N A L I N C O M I N G TRAFFI C
TERMI NATE TRANSI T NAT
- - - - - - - - - - - - - - - - - - - - +- - - - - - - - - - - - +- - - - - - - - - - - - +- - - - - - - - - - - - +- - - - - - - - - - - -
TC ( DERL) 0 87. 398
TC WI TH ANSWER( DERL) 0 64. 674
CC 350. 773 4 337. 757
CCS WI TH ANSWER 4 70. 962
TC I NTERCEPT ( DERL) 6 0 381
CC I CEPT NO FAI LURE 0 0 0
CC I CEPT FAI LURE 560 0 9. 807
CCS I CEPT NO FAI L SN 0 0 0
CCS I CEPT FAI LURE SN 54 0 4. 565
TC REROUTI NG ( DERL) 7. 307 0 7. 277
CC REROUTI NG 49. 206 0 39. 131
CCU REROUTI NG 0 0 0
CCU RER BUSY 0 0
CCU RER FALLBACK 0 0
CCS REROUTI NG 0 49. 206
CCS RER ANSWER 0 0
CCS RER BUSY 0 0
CCS RER I NT TECHN I 0 17. 742
CCS RER EXT TECHN I 0 31. 464
CCS RER NO ANSWER 0 0
CCS SN REROUTI NG 0 20. 675
CC QUEUI NG 0 0
CC QUEUI NG NOT POSS 0 0
CCU QUEUED CALL REL 0 0
CC PRECEDENCE 0 0 0
CC I N 0
CC I N NON CALL ASS 0
CC I N SERVI CE FI LTER 0
CC I N CONGESTI ON 0
CC I N SCP SER LOG ER 0
CC I N SCP NO ANSW 0
CC I N SERV NOT ACT 0
CC I N UNALL NUM 0
TC NO DI AL ( MERL) 6
CC NO DI AL REL A 4
CC NO DI AL TI OUT 0
TC TEST CI RC ( DERL) 0
CC TEST OF CI RCUI T 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 TRUNKRESERVATI ON 0 0
CCU CMP DI AL REL A 6 0 0
CCU I NCMP DI AL REL A 1. 270 0 0
CCU I NCMP DI AL TI OUT 515 0 0
CCU NM BLOCKI NG 0
CCU NM CANCEL TO 0 0
CCU NM CANCEL FROM 0 0
CCU I NT TECHN I RREG 0 0 0
CCU EXT TECHN I RREG 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 SCREENI NG 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 I N SCP END 0 0 0
CCS SUB 4
CCS PABX 0
CCS TRUNK 211. 414
CCS CALL FORWARDED 0
CCS CMP DI AL REL A 0 44. 776
CCS CMP DI AL TI OUT 0 793
CCS I NCMP DI AL REL A 0 228
CCS I NCMP DI AL TI OUT 0 0

___________________________________________________________________________________________
Page:7
CCS I NT TECHN I RREG 0 0
CCS EXT TECHN I RREG 0 2. 613
CCS COC FAI L ACT SN 0 0
CCS LI NK FAI LURE 0
CCS O/ DEX SUB BUSY 0 12. 942
CCS O/ DEX TGRP BUSY 0 10. 403
CCS O/ DEX UNALL NUM 0 1. 379
CCS O/ DEX TERM NCON 0 216
CCS O/ DEX SUB NO CUG 0 0
CCS O/ DEX CALL REJ 0 54
CCS O/ DEX SP CON REJ 0 0
CCS NO SERV AUTH 0 49
CCS RELORI G ENDTOEND 0
CCS PREEMPTED 0 0
CCS CCS7 NORM UNSPEC 0 17. 792
CCS CCS7 MAI NT F A 0 0
CCS CCS7 MAI NT F B 0 0
CCS I N SCP END 0 0

END TEXT J OB 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
= 350,783

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
= 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. = ( Answered Calls / Offerred Calls ) * 100
= ( 70966 / 350783 ) * 100
= 20.23 %
Note :- 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:8
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.

TRAFFI C MEASUREMENT : EXCHANGE

DATE TI ME TC ( DERL) TOTAL SUCCESSFUL ANSWERED DATA
CALLS CALLS CALLS QUALI TY
- - - - - - - - +- - - - - - +- - - - - - - - - - +- - - - - - - - - - +- - - - - - - - - - +- - - - - - - - - - - +- - - - - - - - - - -
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
Traffic Carried in BUSY HOUR = ------------------------------------ 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 Carried X 1000
Traffic/1000 BHCA = -----------------------------
BHCA

( 6091.65 X 1000 ) / 396352
= 15.37

___________________________________________________________________________________________
Page:9
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 J OB, except jobs with UNIT=MDD-DAILY.
- This command starts a semipermanent job. It can be canceled with CAN J OB.

Input format

REC EXCH : UNIT= [,BEG=] [,TER=] [,IV=] [,PER=] ;


NTTAX/ A39336D5000/ I NDCPK1V16314266/ 003 06- 06- 28 12: 33: 56
7850 OMT- 01/ J TOMTC 2889/ 08463

TRAFFI C MEASUREMENT : EXCHANGE DATA 06- 06- 26 11: 30

DATA QUALI TY : SECURE

PROCESSOR LOAD 841
CALL PROCESSI NG LOAD 744
OFFERED SEI ZURES 304909
CC 211418
CCU LEAKY BUCKET 0
CCU TRUNK RESERVATI ON 0
CCU CANCELTO 0
CCU ALL TRUNKS BUSY 126004
CCU I NT PROT MECH 3332
CCS WI TH ANSWER 70966
CONGESTI ON LEVEL 0

END TEXT J OB 7850


OFFERRED SEIZURES =No. of Calls offered to the EXCH / LTG
=304909

PROCESSED CALLS = OFFERRED SEIZURES CCU INT PROT MECH
OR = 304909 3332
CALLS OFFERRED TO CP = 301577


CIRCUIT SEIZURES = SUCCESSFUL CALLS
= CC
= 211418


ANSWERED CALLS = CCS WITH ANSWER
= 70966






___________________________________________________________________________________________
Page:10
Now in the above sample for Fifteen minutes

1. Processing Efficiency = ( Processed Calls / Offerred Calls ) * 100
= ( OFFERED SEIZURES - CCU INT PROT MECH)*100 / OFFERED SEIZURES
= ( 301577 / 304909 ) * 100
= 98.90 %

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 :- 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 0 1 2 3 4 5 6 7
Congestion level 0 1 2 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:11
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 J OB, except jobs with UNIT=MDD-DAILY.
This command starts a semipermanent job. It can be canceled with CAN J OB.

Input format

REC TGRP : TGNO= [,OPMODE=] [,TGRPTYP=] [,FORMAT=] , UNIT= [,BEG=]
[,TER=] [,IV=] [,PER=] ;



___________________________________________________________________________________________
Page:12
Take The following parameters from RECTGRP Output


TRAFFI C MEASUREMENT : TRUNK GROUP 05- 08- 30 19: 15

TGNO : BAFZ BARTL BBDX BBGM
OPMODE/ TGRPTYP : BW BW BW BW
AVAI LABI LI TY :
- - - - - - - - - - - - - - - - - - - - +- - - - - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +- - - - - - - +- - - - - - -
CC: I 42 0 697 52
TC: I ( DERL) 59 0 409 45
CCS WI TH 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 WI TH ANSWER: O 39 0 151 42
CONNECTED LI NES 30 0 215 60
NO OF BLO LI NES( ERL) 0 0 0 0
SEMI BLOCKED LI NES 0 0 0 0
TRANS BLOCKED LI NES 0 0 0 0
TGRP BLO TI ME: O( SEC) 0 0 0 0
ATB TI ME ( SEC) 0 900 0 0
NUMBER OF ATB 0 0 0 0
CCS CONGESTI ON 0 0 8 0
CCS I NCMP DI AL 0 0 3 3
CCS UNALL NUM 25 0 28 4
CCS RELORI G ENDTOEND 0 0 0 0
CCS SUB BUSY 68 0 64 18
CCS I NT TECHN I RREG 0 0 0 0
CCS EXT TECHN I RREG 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 BLOCKI NG 0 0 0 0
CCU TECHN I RREGULAR 0 0 0 0
CCU TGRP BLOCKED 0 0 0 0
CCU TRUNKRESERVATI ON 0 0 0 0
CCU ALL TRUNKS BUSY 0 0 0 0
QOS TRAFFI C 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:13
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. How you are analyzing and calculating CCR and other critical performance parameters?
2. What CCR and other parameter values you are getting ?
3. What are the prominent causes for call failures observed by you?
4. What is the Call failure rate during high and low traffic hours?
5. Output of various Traffic reports running in the EWSD, e.g. RECGOS,RECTGRP and RECDLU

The following commands can be used to initiate Traffic J obs 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:14
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 J obs 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:15

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 through-
connection:

RCT_NO_REASON 0
RCT_CALL_REJ 8
RCT_UPDATE_PARN_FAIL 15
RCT_NETWORK_OUT_OF_ORDER 21
RCT_NETWORK_FAILURE 22
RCT_CALL_PICK_UP_FAILURE 29
RCT_CALL_CANCELLED 37
RCT_SUB_LINE_TMP_OUT_OF_ORDER 42
RCT_INTERNAL_CONGESTION_ROTL 121
RCT_LACK_OF_RESOURCES 125
RCT_LACK_OF_CHRS 126
RCT_OVERLOAD_CP 129
RCT_PORT_BLOCKED 147
RCT_A_SIDE_BLOCKED_TRANS 148
RCT_UNEQUIPPED_CIC_RECEIVED 153
RCT_PARTNER_LTG_NAC 157
RCT_CHR_NOT_SECURABLE 158
RCT_DATABASE_FAILURE 160
RCT_INVALID_MESSAGE_DATA 161
RCT_INVALID_LINKAGES 162
RCT_SPL_EXCEEDED 173
RCT_CONFL_NUM_OF_PARTIES_EXCEED 179
RCT_CONFL_RECOURCES_UNAVAILABLE 180
RCT_FORCE_REL_WITH_SIGN 181
RCT_TENTATIVE_REL_WITH_SIGN 182
RCT_FORCE_REL_WITHOUT_SIGN 183
RCT_TENTATIVE_REL_WITHOUT_SIGN 184
RCT_MISROUTE_CALL_TO_PORTED_NUM 191
RCT_PREEMPTION 232
RCT_PREEMPTION_CIRC_RES_FOR_REUS 233
RCT_RESERVE_ 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:16
RF_A_SIDE_MODULE_REMOVED 206
RF_A_SIDE_DIU_FAILURE 210

___________________________________________________________________________________________
Page:17
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 through-
connection:

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:18


___________________________________________________________________________________________
Page:19
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_REJ ECT 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_REJ ECT 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:20
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 through-
connection.

RF_A_SIDE_DLU_FAILURE 212
RF_A_SIDE_CARRIER_FAILURE 216
RF_A_SIDE_SIGNALLING_FAILURE 220
RF_MFC_TIME_OUT_FAILURE_A_SIDE 10
RF_MFC_INVALID_MFC_SIGNAL_A_SIDE 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:21
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:22
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:23
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:24
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:25
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_REJ ECT
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:26
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.

Вам также может понравиться