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