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

___________________________________________________________________________________________ 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 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 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/INDCPK1V16314266/003 06-06-26 12:16:33 7131 OMT-01/JTOMTC 2893/06181 TRAFFIC MEASUREMENT : GRADE OF SERVICE 06-06-26 11:30 DATA QUALITY : SECURE TC:EXCHANGE (DERL) = 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:7

CCS INT TECHN IRREG 0 0 CCS EXT TECHN IRREG 0 2.613 CCS COC FAIL ACT SN 0 0 CCS LINK FAILURE 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 RELORIG ENDTOEND 0 CCS PREEMPTED 0 0 CCS CCS7 NORM UNSPEC 0 17.792 CCS CCS7 MAINT F A 0 0 CCS CCS7 MAINT F B 0 0 CCS IN SCP END 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 = 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. 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 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 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=] [,PER=] ; NTTAX/A39336D5000/INDCPK1V16314266/003 06-06-28 12:33:56 7850 OMT-01/JTOMTC 2889/08463 TRAFFIC MEASUREMENT : EXCHANGE DATA 06-06-26 11:30 DATA QUALITY : SECURE PROCESSOR LOAD 841 CALL PROCESSING LOAD 744 OFFERED SEIZURES 304909 CC 211418 CCU LEAKY BUCKET 0 CCU TRUNK RESERVATION 0 CCU CANCELTO 0 CCU ALL TRUNKS BUSY 126004 CCU INT PROT MECH 3332 CCS WITH ANSWER 70966 CONGESTION LEVEL 0 END TEXT JOB 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 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=] , UNIT= [,BEG=] [,TER=] [,IV=] [,PER=] ;

___________________________________________________________________________________________ Page:12

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: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 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: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 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: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_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: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_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: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 ihigh and then observe various RCF (reasons for call failure). Also perform the diagnosis and testing of complete SN.