Cfa Tariff Book

C-DOT DSS FAMILY

Field Problems Reported at Workshop

held at, ALTTC Ghaziabad

RTC, Jaipur and TTC, Jabalpur

Table of Contents

Problem and Solution ......................................................................................................................................................5

Annexure - I Explanation of the Traffic Report Field 'Any Other Reason' .........................................................27

Annexure - II Handling of Priority Subscribers in MOD-R2/CCS7 Signalling in C-DOT Exchanges................30

Annexure - III CLI Implementation in 256P-RAX ..................................................................................................32

Annexure - IV Procedure to Clear Held-up Alarms ................................................................................................34

Annexure - V IOP Synchronisation Failure - Cause & Remedies.........................................................................35

Annexure - VI Reasons of Call Failure ....................................................................................................................39

Annexure - VII Detail Bill Files (BC Group) Management......................................................................................43

Annexure - VIII Guide Lines for No. of TGP's and Routes to be put under Observation Simultaneously ............44

Annexure - IX Limits for Subscriber Line Parameters...........................................................................................46

Annexure - X Engineering the VU V5.2 Unit) .......................................................................................................48

Annexure - XI Defining TGP Type in Local/TAX/ILT Exchanges at Various Nodes ............................................49

Annexure - XII Implementation of CLI Sending and Presentation (CLIP) in 2_1_7.9_1/2_2_1_6 Software........52

H:\HOME\MAX\WORD\FLDPROBALTTC.DOC October 27, 2003

- 5 -

Name of Site/Circle : Haryana

S.No. Problem Detail Solution/Comments

1. Sometimes `copy-out' is possible but `copy-in' fails for some cartridges.

First probability is the non-compatibility of writing & reading heads of cartridge drive. This can happen with the same cartridge drive or between two different CTDs. Solution is to change the CTD.

2. Sometimes on display of any command, few lines are coming as follows : trnstln-feq (25)

This is due to non-updation of transactions files in one or both IOPs following are the solutions :

i) Shutdown re-boot both IOP's one by one & then synchronize

ii) Fresh s/w loading in IOP may solve the problem.

iii) Remove old transaction files and copy these from BMDC. Then shutdown/reboot IOP. This will definitely solve the problem.

3. Sometimes we see "drive no. slice no." message on VDU. What do they indicate ?

While Loading Unix cartridge in IOP, complete Hard Disk space is partitioned which are called slices and different type of file systems files are loaded on each of these slices.

File Systems Drive/Slice

Root Volume 1 dev/dsk/m320_0S0 i.e. `drive 0', `Slice 0" Code Volume drive 1, Slice 1 Data Volume Drive 0, Slice 4 Exdata Volume Drive 0, Slice 5 'U' Volume Drive 0, Slice 6

4. Sometimes in one directory `free blocks' become zero. How to increase free blocks.

i) Sometimes Shutdown/Reboot IOP solves the problem

ii) Otherwise, in the particular directory relevant files have to be deleted to increase free blocks.

e.g. in case of `/u' directory ;

- Remove unwanted cmd log files, which get created after execution of command files for creation of exchange data in /u/admn/cmdfile directory.

- 6 -


- Remove rgen out put files if any in /u/admn/rgen directory.

- Remove `heal' files from $FDTDIR directory.

- Remove 'ood log' files, if too big, from $TEMP directorye.g. in case of /data directory, do following :-

- Remove `tf' files from /data/dump directory, using

Crp command <del-fgp-file;, tf {from date → To date};

- Remove detail Bill files from /data/dump directory using crp command <del-fgp-file: , bc {from-date → To date}

5. `Copy-out' command gets executed but while using `displ-tape-info' command, if give error" Tape is not in proper formula".

i) If `copy-out' has been taken from IOP having `150' MB `CTD' and `Displ-tape-info' is being taken from IOP having `525'mb CTD or vice-versa, this problem may occur.

ii) `CTD' is not writing `ok' as a result cartridge copied from here, may not be read later. In such a case change of CTD is required..

6. Sometimes one TUI and TIC card works in a particular frame but do not work in another frame.

This could be due to improper connection between the card and the motherboard male/female points.

7. Dynamic locking facility on 95 should be made available. Being provided in S/W releases 2_2_1_6

8. `Displ-tgp-status', should work for TGPs having more than 40 trunks.

Though not possible through 'crp', the same can be seen through 'utility 'tgputil', available in rgen cartridge.

9. In BM-XL `TSU frame' lot of cabling on motherboard should be avoided, instead a composite motherboard should be there.

This is a result of improved system engineering which ensures quick isolation of faults between copy0 & copy1 of TS, BMS & SCIC. More over changing of cables may solve the fault easily.

10. Hotline from DIR-NO. to TEN should be available (P-wire concept). It is not implemented at present.

11. Meter Reading printout in`Bulk' should be implemented for deleted `DIR' NOs. also.

Requirement is noted for future implementation

12. "Rank of Digit" should be associated with route instead of TGP, so that same TGP can be used for `routs' having different ROD's.

Cannot be implemented in near future

13. Traffic reports show anomally while counting various fields.

- 7 -


a) Total no. of calls is not equal to sum of completed and failed calls.

b) Calls failed due to `Any other reason' is not clear. This may be explained in detail.

a) Yes, the figure does not match 100%, but it has beencorrected in 2_1_1_1 S/W to show minimum difference.

b) Calls failed due to any other reason : This has been explained in Annexure-I for ORG-TERM, ORG-OG, OG-TRUNK, I/C-TRUNK traffic reports.

14. Password should be BM associated. Requirement is noted for future implementation.

15. Centrex facility should be available. Requirement is noted for future implementation.

16. In Annc. card announcements should be locally programmable. New announcement card `ASV' supports this facility and can be used in 2_2_1_4 S/W.

17. In CM-XL rearside trough should be provided to protect lot of loose cabling.

Will be taken care in the new CM design.

18. Protection modules at MDF should be such that in case of removal it should not make the lines through. The performance of IPMs is not satisfactory .

For MDF, C-DOT does not suggest any particular design and it is up to BSNL own discretion about which type of MDF to be used. About IPMs performance, the matter can be reported to BSNL QA cell.

19. The subscribers who have not registered their dynamic codes, get locked whenever Base Module is initialised up part-init/code load level.

Only those subs who have once registered their dynamic code get locked after part-init or above level. But it is not true for subs who do not register their code-even once. Same can be verified using "displ-info-fac" command.

20. CCM card should provide 16 KHz to all the `8' ports instead of only 7th & 8th port.

Existing card cannot be modified. But new 16 port CCM card supports 16 KHz on all the ports.

21. `CLIP' facility should be available on all the 8 ports and should be programmable in S/W only.

In the existing `LCC' card this facility can be provided on all the `8' ports after doing prescribed ECN straps. But the new 16 port LCC/CCM (ECL) card, CLIP facility will be available on all the ports.

22. Some kind of protection on LCC/CCM cards or at the connector module should be provided to protect exchange equipment from lightening and accidental AC surges.

It has been taken care in the new LCC/CCM (ECL) card, which will be supported in new VE-BM.

23. Subscriber facilitates which are presently not available should be masked in S/W.

Requirement is logical, but not feasible with present design.

24. Automatic Back-ups for dumps of ED & BD once a day should be provided.

Although directly it is not possible but can be planned using Calendar Administration, once a day, using both IOP's

- 8 -


25. Transaction log status to be given through alarm. In Version 4.19 and 4.26 whenever transaction buffer is full, transactions are not being updated. For clearing the buffer, command should be there in CRP mode instead of reloading complete transactions group files.

Trans log handling to be improved in 2_2_1_6 s/w.

26. After using call-diversion, when tried to normalise it, it is not working. On active-iop, showing msg “error in is_delete div file” often. Only del/cre sub solved the problem.

• Interchange IOP to make other IOP active. Bring previously Active IOP to warm start.

• On Active IOP, give command :- IOP5x>ps - ef| grep iosif Note down Process ids (PIDs) and kill them to recreate iosif processes. IOP5x> kill - 9 PID

• If call diversion starts working, synchronize the IOPs.

Name of Site/Circle : Andhra Pradesh


1. Transaction log status to be given through alarms. For clearing the trans updation error, some crp command should be there instead of fresh loading of trans group files.

In S/W 2_1_7.5_1 & S/W 2_2_4.4_4 trans log corruption has been minimised, though no crp command is there to solve the trans updation problem. Procedure explained at sl.no.2, under Haryana circle problems, should be followed to solve this problem if occurred.

2. CLI based call restriction in I/C TGPs. This feature is being implemented & solution will be provided in NLDO release 2_3_1_6.

3. Whenever RBMs are down due to some problem, reloading of files. Stops at /data/exdata/bpotoa215. dat file, as this files get corrupted or missing, observed frequently.

This is a site dependent problem observed in earlier S/W releases of 2_1_1_1 series. Once this file has been replaced by fresh one problem should not occur. Moreover such type of data corruption has been minimised in S/W release 2_1_7.5_1 own ward.

4. • In large capacity switches, `rgen' utility cannot be used by more than one official working on different terminals of the same IOP.

• For operator password also IOP> prompt should be available.

• This is ok, as `rgen' script file being one, cannot be shared by other on the same IOP. Moreover IOP5x> prompt is not provided to any other account other than `admin' to ensure security to the system `RGEN' utility can be used by two persons working on different IOP's.

• Requirement can be forwarded to TEC.

- 9 -


5. For getting complete CLI in Local Exchange system parameters, `XCHG-TYPE' is configured as '4' (i.e. TAX). What are the repercussions ?

• Since Local Exchange is not connected to many exchanges, normal working is not affected by configuring it as TAX. However I/C calls from group exchanges for 17* (Internet Access) and 16* (IN access) are likely to fail for this I/C TGP should be configured as `TTAX' instead of `ORD'.

• Another repercussion is the addition of one more node in the network for calls originating from Gp. dialling stations of that Local xge. This will cause some delay in call handling specially for destinations involving 6 or 7 nodes in between, causing call failure due to signal time out at originating station.

• Refer Annexure XI for proper definition of TGP type at various nodes.

6. In IN switch (SSP), IOP synchronization problem comes frequently due to various files like tcntrddmm.dat or iodk*, exrp* files etc.

Solution will be provided in subsequent S/W releases meant for IN switches (2_2_1_4(5.4)).

7. Detail Bill of I/C TGP from 'TAX' exchange (Ord/TTAX), shows units as '0' for all the calls (IC-TRM/IC-OG) irrespective of its duration, when viewed through 'rgen' utilities 'TGCBR2'.

This is ok., as exchange is not charging for I/C calls from 'TAX', since we are using charge rate Number '4' ('no-mtr', init-chrg=0) for both I/C terminating & I/C-outgoing calls.

8. It is observed that the call continuity in CCB-PTs. in case of SBM/MBMs with S/W release 2_1_1_1 is not there.

This is as per 'TEC' specification. Call from Local PCOs, has to be cut after pre-determined time duration, say 180 sec, earlier (now it is 90 sec). However, in s/w 2_2_1_3/2_2_1_4, by using sub's category based charging, call continuity on Guaranted PCOs is possible. Here we create PCO with Line Type = CCB-CRD.

9. CLI problem with OCB-283 switches with CCS#7 signalling TGPs, as '0' is being prefixed before area-code.

Matter is to be resolved with TEC.

10. CCB-PCO, problem : Metering takes place on Non-metered routes like '198' without/with inserting the coin. The coin is coming out after completion of the call.

As per implementation metering of CCB-PCO is governed by the Charge-Rate NO. given against system parameter 'PCO-MTR-LCL', which is normally 'FXD-MTD' with 'INI-CHRG = 1'. Thus call made on Non-mtd route will still be metered by referring this parameter.

11. Frequent failure of IFCs is observed in case of RBMs. Mostly due to Media problem in one or more PCM's on BUS-0/BUS-1. Solution is to isolate DTK's, one by one.


12. On line addition of BMs without any problem is required in order to avoid PART-INIT to system.

If both the 'SS' planes in CM are healthy and taking, interchange, then there is no problem of 'BM' equippage, as per prescribed procedure. In case one 'SS' is not working, then only off line procedure is to be used.

13. There should be provision for the administration to put any command on any class for operator management.

Discrimination possible only at class of command level. Command level implementation not envisaged in near future.

14. The maximum limit of char Numbers is to be raised from 127 to meet the IUC requiremen Os.

This will be taken up in version 2_3_1_6 where existing memory boards BME (16 MB) will be replaced with XME (32 MB).

15. There is no provision to seany of the commands. 'ADDan error as "MSN already efor another ISDN line gives

16. In-compatibility is existing exchange i.e. ETS of ITI matogether in the same RSU.

17. Exchange A is connected tconnected to exchange 'C' (exchange calling to Busy suBusy Tone.

18. Even after doing 'ECN' on tone is observed.

19. DTMF functioning is ineffecother than '1' for STD calls g

A B

☎ ☎

CCS7

ge rate t for BS

Memory is a constraint at present.

e 'MSN' DIRNO for any ISDN line with -MSN-DN' command for 2nd MSN gives

DD-MSN-DN' for 1st MSN itself e error.

• 'ADD-MSN-DN' works ok for '5' additional Nos. In Mapped No. field, same DIR No. has to be written. If some error is coming then it can be a site specific data problem.
xist". 'A
the sam

- 10 -

• List of MSN Nos. can be seen using 'DISPL-SUB-LIST' command.

for different makes of ETS cards in the ke & that of BHEL make may not work

No such problem has been repeated earlier. This can be investigated by C-DOT.

o B (TAX) via CCS7 and 'B' is further Local) via CAS/CCS7, then sub 'X' of A b 'Y' of C, gets congestion tone instead of

This problem is coming if transiting exchange 'B' is 'OCB-283' and not observed when exchange 'B' is of some other technology. Some solution has to be provided either at 'OCB' or 'C-DOT'.

PSS/PSM cards, some noise in ring back CDOT can plan further investigation for such sites.

tive on local subs. having "Sub-Priority" oing on CCS7 route.

It is not a case of ineffective functioning. Priority implementation for MOD-R2 and CCS7 is different. It is explained in Annexure - II.

C

☎

CCS7

- 11 -


20. For some ISD calls, non-metering is noticed in No. 7 signalling. Only possible, when charge Band associated to in-correct Charge-Rate Nos. at originating exchange.

21. In CM, IFC card is going to 'OOS' frequently, even if one of the TSC card of the concerned BM is kept OOS. DGN of IFC is ok every time.

This may happen due to transient noise in link between, IFC & TSC of one of the two BM's. 'DGN' will be ok every time. Only solution is to replace Data/clk, cable of both BM's one by one.

22. IOP synchronization problem in Patch 2_1_7.3_1, if NCBR data exist for more than 2 months. Sync fails in step 5.

This is common problem and not related to Patch 7.3. Sometimes sync may fail due to large No. of NCBR files, each of large block size, existing in the Active IOP, so best solution is to delete extra 'BC" after taking Back-up.

23. When 'CCB' subscriber makes IN call on ITC card, metering increases for every IN call. This is causing problem in collection of revenue in Departmental CCB-PT.

i) If CCB PCO is all purpose then metering can not be stopped if used for IN call using ITC card.

ii) If it is a dedicated IN-PCO, then this can be created with LINE-TYPE=CCB-CRD, and Sub-Cat can be changed from '1' to some other unused category (say 10). Then this category can be allowed in 16* routs only with non-metered charge rate No.

24. File related problems occurring in DNP Nos. which are deleted, but when re-created can not be made DNP.

This may happen if some 'DIRNO' which is DNP (BNP-ANNC/BNP-DISC) is deleted without making in normal. This causes mismatch between sub's facility file & DNP status file and can be rectified through datpat only. So before deletion, care should be taken that the No. is not in DNP list.

25. I/C calls fail on sub Nos. having either malicious or 'CLIP' facility. This is not true in all the cases. This may happen due to wrong data creation at transit nodes also. Logically, on seeing malicious/CLIP facility, terminating, exchange places demand for 'CLI' of the Caller to prev. exchange node. Transit TAX exchange should pass this information to originating end & after collecting CLI of caller should pass it to terminating exchange. Due to improper data creation, this process may fail at one node, causing call failure.

26. Noise and cross talk in C-DOT MBM Srikakulam. There are 10 RSU's, 5TK, BMs and 2 BM's (Local).

At some places as the no. of BMs (Specially RBMs) increases, noise problem starts. Initially, this can be rectified by changing ESM/PSS cards. If it can't be solved by changing cards, then there is 'ECN' prescribed for PSM/ESM cards, which has to be carried out at such site. C-DOT can be contacted for this.

- 12 -


27. To bring Trks in CCS7 'Busy' to normal status with a simple command is required. Command 'mod-blk7-sts' takes too much time.

No other option for the time being.

28. As there is acute shortage of CPU-S05 cards in the field, there should be an alternative as CM-L exchanges are still working in the field.

For 'NLDO' feature implementation, new s/w 2_3_1_6 will be required, which is supported in CM-XL version only. As a result, all MAX-L exchanges have to be upgraded to MAX-XL.

29. E1 trunks interfacing with C-DOT causing problems, as most of the junctions go 'INS-FRC' state, and there is no seizure on these trunks, causing traffic congestion.

Problems has been observed at some sites and cause is under investigation.

30. It is not possible to keep a sub. No. Under ORG/TRM/MALCIOUS call observations in S/W 2_1_7.7_1. This problem is observed at srikaknlam, Rajam and Palasa.

Since P7.7 is not working at many places, so no such feed back has come. Now this patch is not being used as its has been upgraded to P7.8/7.9. There after such feed back will be required, if any.

31. MFC circuits go 'oos-sys' frequently at MBM Tekkah and causes excessive call failure.

Problems will be investigated by C-DOT, after feed back from more sites.

Name of Site/Circle : GMTD, Alwar


1. In C-DOT MBM-XL (2_1_6.11_1), whenever internet call is accessed by `ISDN' sub data access stops and sub no. is held up in `cp-bsy' state. This remains so for a long time and does not recover even after making it OOS/INS.

Problem was analysed and fault was due to wrong charge rate number (`PRD-TAX' type) defined for `17*' route opened towards ISDN node. For this `CRG-RTN' to be used should be `PRD-LCL' type with desired pulse rate (i.e. 180/600 sec.).

2. From CCBPCO, an IN call is possible but Exchange counter is incremented by one unit.

Refer solution to Problem No. 23 under Andhra Pradesh.

- 13 -


3. Intra SDCA VPN groups have been created to provide the services. Although VPN services are made available for ALWAR SDCA subscribers but it is not possible to provide these services in another SDCAs of the SSA, because of having the same levels.

Not possible as per implementation.

4. As per charging plan, charging is different for CBT95 and guaranteed CCBPCOs and its is not possible in CDOT switch as system itself define the priority to CCBPCO line.

Refer solution to Problem No. 8 under Andhra Pradesh.

5. Call diversion facility cannot be restricted by the administrator for selected routes or call diversion must only be possible for local charging area.

Implementation is as per TEC specs.

6. While making of "95" calls the STD counter should be incremented instead of Local counter.

Solution will be provided in 2_2_1_6 s/w release.

7. Requirement

i) Change number announcement in case of change of indicator.

ii) It is possible to feed announcement to the routes as and when required.

iii) Abbreviated dialling.

iv) Facility of CENTREX.

v) CLIP-A for all ports.

vi) Facility to extend fire alarm, power fail alarm etc. from RSU to main exchange.

- Not supported in S/W. However 'IVRS' can be utilized for this.

- Desired announcements possible through ASV card (New Annc. Card) support in 2_2_1_6 version.

- Not Planned

- Not Planned

- Yes, only CLIP can be provided on all '8' ports of CCM/LCC cards. ‘CLIP-A’ (RING-CLIP-RING) is not supported.

- Not Planned as yet.

- 14 -

Name of Site/Circle : TDE, Jasalmer (S/W 2_2_2_10.3)


1. IOPs go out of synchronization frequently and even one-month data is not transferred during synchronization.

Mostly in 2_2_1_4 s/w sync Problems is under observation.

2. After up gradation 2_2_1_3, often on numbers local calls not passing in BM_7 while '0'/95' facility remains available even after loading the PPL, Power on is only solution.

• Upgrade s/w to 2_2_4.4_4.

• BM-7 problem got solved after CPU change & code load to BM.

3. In RGEN utility (2_2_1_3), data is not coming. Latest 'RGEN' is available now, which should be loaded in both the IOP's. New RGEN is of block size = 1398.

4. ADP gives false alarms OK • Audit ‘12’ can be run.

• Alarm hanging problem is under observation.

5. SBMs connected with MBM are working on decadic signalling, when signalling changed to MOD R2, loading in respective BMs started.

Data Creation Problem at MBM end. 'BP' Cable can be put on Trk. BM & recoveries noted down. Refer Annexure – XI for proper definition of TGP type at various nodes.

6. Number is under BNP-DISC, even then subscriber is availing the facilities.

• If status is passwd-tmprd, make it normal by 'mod-lin-sta'

• Problem to be fixed in S/W 2_2_1_6.

7. Testing of reversal/16 KHz on CCM card. • 16 KHz, can be checked using external equipment only.

• Reversal is tested during '103' test set

8. Use of Audit commands is to be given in detail. Details are available in Maintenance Procedure document. However only Audit, set '12' should be used frequently.

Name of Site/Circle : GMTD, Jhunjhunu


1. Some time CCS7 links hang, part init to SUM is required. • Much stable in S/W 2_1_7.7_1 own ward

• Patches will be propagated in 2_2_1_6 s/w.

- 15 -


2. Some routes are accessible on MF but not getting on CCS7. • There can be various possibilities. Please refer Annexure - XI for probable cause.

• Proper mapping of Charge Band is must for CCS7 working.

3. Some method for observation of CCS7 calls as MFSA in MF. Suggestion is noted. May be considered in VE BM S/W.

4. 95 locking facility should be provided. To be made available in 2_2_1_6 S/W

5. Some 256 CDOT RAX subs. are not getting STD on CCS7 links through CDOT MBM.

Same as problem '2' above.

6. Diagnostics of cards are not proper. For some of the cards like SPC, TIC, SWC cards, diagnostics are not covered for 100% functions thus reducing the diagnostics time. Here the main functions are definitely covered.

Name of Site/Circle : TDE, Bundi (2_1_4.26_1)


1. Too many stations become unavailable when CAMA parameter yes. • 'CAMA' parameter in 'TGP', becomes effective when TGP type = ORD, system parameters: XHG-TYPE=4, CLI-INFO=1. NUM-ANI should be '10'. Moreover in-Gp-dialling stations, ARCD parameters for prefixing code with CLI should be properly defined.

• At originating (Paranted) stations ‘CLI’ sending along with Area code should be enabled.

• Refer problem ‘2’ below.

2. Calls are not being matured when number of links is more in switching.

Refer Annexure - XI for explanation.

3. Data updation takes much time, even in some cases, PI is required. Problem has been solved in 2_1_7.x_1 series.

- 16 -


4. CM hangs due to frequent ON-OFF of DTK-RBM links. Problem is under observation.

5. Data transfer gets slowdown with the introduction of NSE. Once NSE has been equipped after changing SCK-S04 card in CM, external clock must be selected and SCK-S04 card should get synchronized O/P from "NSE'. If due to any reason, the synchronization is not proper, then system will work on self 'clk' (i.e. with SCK-S04 cards). Since 'SCK-S04' provides very poor quality CLK, so all data calls (Internet) will be affected with low speed & disconnection problem.

- 17 -

Name of Site/Circle : Beawer (Raj.) (S/W 2_1_6.11_1)


1. Whenever any change in trunk data/route data or creation of new module, the charging of whole exchange is being affected, the system is only restored when whole system is initialised at power-on(code-load) level.

Change of trunking/routing data does not disturb charging of the whole exchange. No case has been reported.

2. Suddenly all working directory numbers stop getting updated after numbers are made in “oos-opr”.

Problem was observed in earlier s/w releases & has been solved in S/W 2_1_7.5_1 ownward.

3. Some times locctr & stdctr updation stops. • Delete/Create 'BAP' may solve the problem. On Active IOP, do following :- IOP5x> conp Conp> m 56 mdeb_56> del ~ bap mdeb_56> cre bap 0 0

• Remove old counter files from $DUMPP for affected module. Let fresh files come from 'BP'. Verify after that. Now updated files will be available.

• Contact C-DOT before carrying out the above activity.

4. The system is quite often require, PI or Code-load to the affected modules, specially in case of CCS7 signalling working. This signalling is still giving problem with EWSD switch, even for charging also.

• CCS7 signalling is quits stable in s/w 2_1_7.5_1 ownward.

• Similar stability will be available in 2_2_1_6 s/w

Name of Site/Circle : Ramganj Mandi(Raj)


1. CLI is not possible when one 256 P RAX is transited through another 256 P RAX. Both the exchanges are connected on PCM link with MF signalling & two RMF cards are used.

This happens because of scarcity of MF-Fwd/MF-bwd resources in 256 P RAX, Specially in Transit RAX which has to handle MF signalling with parented RAX as well as towards 'TAX' exchange. The two RMF cards should have only MF Fwd & MF Bwd resources only. DTMF & Ans-ckt should not be defined.

Best solution is to avoid transiting & use direct links toward Tax.

- 18 -


2. Sometimes both the copies of TSC found INS-ACT status, SBY card changes as INS-ACT and ACT copy remains unchanged showing invalid change on INTCHG command why?

This is unit status updation problem in IOP. In such cases, a soft start to system during slack hours will solve the problem. Or one copy of the unit should frc-oos & then frs-ins.

3. While diagnosing the control cards results displayed instantly on pressing E key and always okayed report. It creates confusion. Please clarify the reasons.

In some case, if all the connected links of the unit are non-operational, then diagnostic may be very quick. For example, in case of 'IFC', 'DGN' will be very quick if corresponding TSC's are made OOS. In such cases, one must interchange the higher unit which is conducting the DGN. Lower units must be INS at that time.

4. Reports through command DISPL-OOD-LOG . Only 10 reports (max.) are available , can the no. of reports be increased?

In field 'Last-Rep', value '0' should be given to get all the resports.

5. Procedure for taking details of trunk cct of a TGP, like a DIRNO. It is not required, as all the Trks of one TGP will acquire same characteristics as that of TGP itself.

6. Generally some of the telephones are lying in faulty condition and become okay only on giving SOFT-START to the BM concerned.

In S/W release 2_2_1_4, some case of INS-FRC/INS-NRML/CP-BUSY have been observed. For this observation is being taken to solve the problem. Till than soft start to concerned mode is the solution.

Name of Site/Circle : Chittorgarh(Raj.)


1. Sometimes in /data/dump directory, if we type ‘ls’ command , IOP responses ‘not found’. But data is available in $DUMPP . At this time we can see the ncbr etc. through RGEN. We can copy the data in dump directory from another folder.

This is the case of corruption of File system in IOP. Only solution is to Shutdown & re-boot the IOP. This may correct the file systems and related directory paths in most of the cases. In other cases if problem is same, then complete software loading in IOP will be required.

2. When we see the status of links (CCS7) system shows ‘activated & available’ but the calls through CCS 7 failed with parking tone. If we give PI to SUM , the said problem is solved. But some times if we give PI to SUM , it is not coming to INS level with the error message on OOD ‘ failure in catching SU’.

If the hardware (BPC/HPC/SHM) cards are ok, then such type of problem may not occur in s/w release 2_1_7.5_1 ownward (or in 2_2_4.4_4).

3. If we dial ISDN PRI HGPs PDN from PSTN, we are getting busy tone. we are not getting server’s response tone. When we are di lli t t ti PDN ( Bhil )b di lli STD d

• This may happen if relevant parameters are not defined properly at C1, C2, or C3 nodes of ISP (Mostly Ericison in BSNL N t k) Th b th PSTN & ISDN d t ll

- 19 -


dialling nearest stations PDN (e.g. Bhilwara)by dialling STD code we are getting servers response tone

BSNL Network). There, both PSTN & ISDN data calls are defined separately.

• ISDN PRI working satisfactorily at many sites (Mandsaur, Alwar, Ganganagar, Pathankot etc.)

4. There should be a facility to see the circuit status of PCMs between RSU and Main Exchange.

There is not command to see status of individual ckt of a PCM between RSU & Main. PCM status can be seen through 'DISPL-RBM-DTKs' at Main & through BP. Terminal at RSU end (explained in 'BP Terminal' application note).

5. There is an option for subscriber observation speech-obs if we put this option on a particulars Dirno, how can we retrieve the observed speech and hear?

Speech Monitoring on a 'DIRNO' is available in s/w 2_1_7.8_1. This facility will also be made available is s/w 2_2_1_6.

6. Is there any provision to provide ISDN facility to RSU subs. without installing ISTU

No

7. The main problem in our exchange or many C-DOT exchanges, whenever BHCA reaches up to 50% of its BHCA capacity, the call failure ratio increase and CCR decreases. In minimum BHCA the CCR is good. Why this is happening.

• This is not so. If the traffic analysis on Trk BMs & individual TGP's is done correctly and remedial actions (like shifting of PCMs from full loaded Trk BM to some other BM & increase of trk ckts on high traffic TGP's) are taken immediately, 'CCR' can be improved drastically.

• E.g. 'BHCA' of a Trk. BM should be Calculated as : IC Call Attempts + (0.6 * O/G Call attempts)

• BHCA handling capacity for BM-L = 7500 BHCA handling capacity for BM-XL = 10500

• Tuning of MF resources in a Trk. BM depending upon i/c & o/g Trk. Cckts (Uneq-srv/Equip MFC cards)

8. There is a limitation for rout observation and TGP obs. In C-DOT system this limitation should be removed.

Suggestion is noted.

Name of Site/Circle : Jaitaran (Rajasthan)


- 20 -


1. Sometime in SBM/MBM local counter dump can’t be generated and exchange is running smoothly. Maintenance person due to lack of knowledge give init-sys and BSNL suffering revenue loss. For this some alarms should be generated or other indication should be given to maintenance person to avoid giving PI in such cases.

• Part-init/Code Load to a Module or whole system should be given during night (slack) hours to avoid revenue loss.

• If at all it becomes necessary to give PART-INIT/CODE-LOAD during day time, then following precautions should be taken: i) Verify counter dump time in $DUMPP directory and wait for the latest counter to come. ii) 'Fmt-blg-cntr' and verify meter reading for heavy cadars in each Line BM.

• As far as possible avoid giving Part-init/Code_load to Module/ system. Most of the problems get solved by 'soft-start' to the system/Module.

2. In MBM when TGP signalling #7, if on rout 2nd choice not allotted then call completion successes on odd and even ccts, if R2 TGP given as 2nd choice on rout then call completion only on even ccts and odd ccts gets idle.

Implementation is so.

3. In MBM/SBM transiting 256 exchange on MF signalling. There is no problem in getting all side routes from SBM/MBM but some routs are not getting from 256 RAX.

• 256 RAX exchange does not send '0' as 1st digit of its 'CLI' if demanded by higher level exchange. Some exchanges (specially Gulf region) demand '0' as the 1st digit of CLI in MOD-R2/or 'NAI' = INTERNATIONAL" in CCS7-signalling. In such case call may fail.

• If, '11' digits are asked as 'CLI' from RAX even than call will, fail, as RAX can send only '10' digits. (Refer Annex-III for details).

4. In rural area many times SBM goes directly off due to unavailability of power supply/DC –battery down. In this condition last dump of loc/std counter not possible and recovery of BM is through previous counters only. Can it be saved to check loss of revenue?

In such a case, there is no way out. Only last LOC/STD counters will be down loaded during initialisation of the system.

5. Whenever media fails in between the main exchange and RSU, on restoration of PCM the link between main exchange and RSU is not self restored but after resetting the RSU, the link is established. It should be restored automatically.

• Normally 'RSU' restores automatically once, 'DTKs' are restored. It recovers at 'Stable-CLEAR' level. This is as per strategy.

• Where 'RSU' does not restore automatically then this is a site specific problem.

- 21 -


i) Change ETS/ESM card. ii) Media may not be very healthy. Change of PCMs can help. iii) BPU & TSU Links may be bad, so change of CPU/TSU cards may help.

6. 9 level calls should be recorded in ncbr (like 95x, 94x,98x) which is a field requirement now.

Requirement has already been noted & will be available in s/w 2_2_1_6.

Name of Site/Circle : Barmer(Raj) (2_2_2.10_3)


1. Subs. of V5.2 going oos-opr automatically and not become normal by command put-trm-ins and become okay after deletion and creation.

'VU' related problems have been solved in latest s/w release 2_2_4.4_4, which should be upgraded immediately.

2. VU normal, AI status normal, but calls matured only after soft-start to VU BM.

S/W upgradation to 2_2_4.4_4 will solve the problem.

3. The subs. of AN showing INS-NRM but calls fail. Call only matures after giving oos-opr and put in service of that subs.

• Problem of 'INS-NRM' is under study and solution will follow.

4. IOP gone out and not in sync even if BC available for one month only. Root, code and data space are sufficient, Sync getting aborted at last step. It is ok after software installation.

• In last step of IOP-Synchronization, all the past day dumps (old traffic files, iodk*files, exrp* files, ncbr, tgcbr, frmt files) are transferred. So apart from deleting 'BC', 'tf', 'opbd' gps. should also be deleted. In addition 'old' 'tcntr' files are also required to be deleted using 'rm' command.

• 'Sync' problem is under study.

5. After huge modification in trunk data overloading of AM starts. Only PI is remedy.

Modification of Trk/Route data in 'bulk' should be done during slack traffic hours to ensure proper updation in BM/AM/IOP memory. There should be some gap between each of the two commands.

Crp commands for this purpose should never be aborted by 'Ctrl\’, as this will lead to corruption of exchange data.

6. CMS –1 gone out of service & suspect after every 24 hrs. Tried with another HMS, diagnostics ok but same obs. And as a result the RSUs(18,20,22) not booting up only RSU16 up.

• This indicates that RSUs 18, 20, 22 are not having proper links on Bus-1 (i.e. TSC-1/IFC25,26,27/CMS-2). Loading of RBMs on Copy-1. should be ensured.

- 22 -


• 'CMS-1' Card (HMS) should be changed.

• RBM DTKs of Copy-0 in RBM's should be isolated one by one to detect faulty PCM causing CMS-1 to go suspect.

7. CCS7 signalling after parenting with OCB-283 with same parameters is not functioning.

Normally there is no such problem in CCS7 working with 'OCB-283'. This may be a site specific, problem and parameters at both ends can be verified.

8. Why PI is required for SUM that goes oos-ini at any time what ‘s reason?

• This may be hardware problem is 'SU' frame, which can be rectified by changing BPC/HPC/SHM cards in SUM frame.

• SUM stability in parallel to 2_1_7.8_1 will be provided in S/W release 2_2_1_6

9. At site ‘Balotra’ SU not booting up only BM boots up on giving reset to SU.

• This is a hardware problem in 'SU' frame. Try by changing BPC/HPC/SHM/TUC cards or by 'SUM' frame itself.

• Once 'SUM' data should be unequipped & then equipped afresh.

10. Is 95 locking possible in 2_1_1_1? No. It will be provided in s/w release 2_2_1_6.

11. System parameter 'ARCD-DTG1' should value '0' or '1' by default?. By default this has value '0', which should be changed to '10', while updating for Area Code prefixing, if ‘0’ is to be defined.

12. Calls to particular site is not matured when ‘CAMA =yes’ for I/C TGP from RAX 256(4-2-1).

This may happen only if system parameter 'NUM-ANI' is '11' at SBM/MBM site, as 'RAX' can not send '11' digits CLI.

13. During X-code modification, why audit is required for some files. • During X-Code modification, all the relevant data files are modified. It is possible that some file is lying corrupted in IOP data, for which X-Code utility may fail. Hence it requires audit at some time.

14. In 256 P RAX(4-2-1), Port 11 got automatically inactive and all facilities get withdrawn. What is its remedy?

Yes. Problem is under study.

- 23 -

Name of Site/Circle : Orissa


1. Alarms not getting updated properly in ADP. 'ADP' Performance will be improved in 2_2_1_6 S/W.

2. IOP data not updated immediately. e.g. frc-swu-oos: it will report the so and so not oos. But through RAD, it will show the actual status.

Because of excessive code/patch/Dats in 2_2_1_3/2_2_1_4, IOP updation is slightly slow.

3. One of the IOPs goes out of synchronisation every 3 to 4 days. Before it goes out, some garbage message comes e.g. msgh[read] msg for quid:22 sz:128, Pid 185D0011 dumped …so & so. The above message with different id reports.

Problem is under observation and some solution will be given in 2_2_1_6 S/W.

4. There remains a urgent alarm in the ADP in respect of SUM. Same as at S. No. 1.

5. SUM reloads automatically many times. • 'SUM' stability patches in 2_2_1_4 equivalent to 2_1_7.5_1 will be provided in 2_2_1_6.

• ECN on SHM cards will also help in stability. Details are available with C-DOT.

6. CCS-7 calls to different transit exchanges fails. Metering not ok on some routs.

Proper creation of CRG-RTN's and CHBS is very crucial in CCS7 working. Data should be thoroughly checked at LE.

7. Even the LS status is active and available, status of some of the PCMs in CCS-7 is displayed as INSF-S7BSY.

• Some time 'ETE' of Trk BM having CCS7 Trks is not established with SUM. In this case Interchange of 'SS' plane and initialization of SUM helps.

8. Overloading of trunk BMs handling CCS-7 calls with SRF-SOFTWARE-COUNTER-OVERFLOW.

• Note down type of recoveries as shown on BP Terminal put on Trunk BM & consult C-DOT to decode them.

9. WLL(V5.2) interfaces not stable. Many times the BMs are to be given soft-start or the units DTS & DTC are to be force-out and put-in:status of all link: AN-BLK.

Upgrade s/w version 2_2_4.4_4 or 2_2_1_6.

10. DCR in respect of TGP is not tallying with the TGP counter value. Problem, may be on I/C TGP & terminating calls. Use 'CRG-RTN having 'chrg-mode' as 'SLF-LCL'.

11. IUC implementation: charge rate numbers and duration. How to implement?

Details of the IUC charges per minute & corresponding pulse rates to be used are available in BSNL, Regulation Branch circular F.NO. 208-15/2003-Regn dt. 24/4/03.

- 24 -


12. Summing up duration in DCR. Whether possible or not. If possible then how.

Yes, utility is available in new 'rgen cartridge for 2_2_1_4.

13. Many time message on console comes as add-sbrd-file error in iswrite. This message repeats frequently, what action should be taken.

• Bring IOP in simplex. Recreate ISP process and try dynamic locking on Nos. of different BM's.

• Contact C-DOT for copying fresh file (bpsbrd??.)

14. One of the RBM at Balasore (RBM 8) data modification is not possible. Terminals status can not be changed. The problem can be solved by giving part init to AM. Problem repeats after 5-6 days.

• Solution is to give either 'PI' to BM or soft start to system.

• Precise solution will be provided in 2_2_1_6.

Name of Site/Circle : UP-WEST


1. Provision of Centrex facility in C-DOT Exchange. Effort is going on to provide this facility in subsequent s/w releases (Not planned in 2_2_1_6).

2. Regarding announcment feeding in Dynamic lock password jamming in C-DOT Exchange.

Suggestion to be considered.

3. Excess Metering due to voltage fluctuations/tripping. To make some arrangement in power supply card in C-DOT Exchange to cut off the exchange in the event the voltage goes below a particular level to save excess metering to individual subscriber.

Excess metering due to voltage fluctuation, do not occur in C-DOT SBM/MBM exchange. But may occur in 256 RAX.

4. Decrease of meter reading due to PART-INIT command in BM-3 at Chandpur C-DOT MBM.

This is a site specific problem & does not occur in general.

5. Regarding unsatisfactory working of CCS-7 rack in C-DOT Exchange Bijnor.

Certain 'ECN' in SHM cards will assure CCS7 stability. Details are available with C-DOT.

6. Regarding unsatisfactory working of ISDN service in C-DOT Exchange.

In 2_2_1_4, ISDN working is quite satisfactory.

• ECN in BRL card & revised ITC proms in ISTU are required.

7. Overlapping of detailed bills of different years in CDOT exchanges. This may happen as 'year' stamp is not there is detail Bill files. So 'BC' must be deleted for the previous year.

- 25 -

Name of Site/Circle : RMC, Channai


8. Calls from other stations to a CDOT number on call forwarding facility not getting metered on CCS-7 but ok on R2.

This is a General problem in all the technologies and not with C-DOT only.

9. In call processing efficiency, which constitutes failure calls? • IDT/Partial Dialling

• Wrong prefix (i.e. xcode/Route Code)

• Non availability of Trunk Circuits

• Non availability of Internal Resources

• System overload

• Faulty Signalling

10. How to change lp password? loging intp, lp account

IOP5x> cd /etc > passwd Enter New password in alfanumeric format,

This way password can be changed for any other account.

11. For calls from OCB to CDOT: calls are ok with R2 whereas calls are failing on CCS-7, for some calling line categories like STD PCOs. Problem refered in C-DOT workshop at Jabalpur. Whether solution found.

Problem was analysed and call was failing in 'OCB' due to improper treatment of STD PCO category. This was rectified at OCB.

12. Suggestion of making ROD and CAMA as ROUTE specific instead of TGP specific were noted in the same workshop. Whether implemented.

No and not being planned as yet.

- 26 -


13. Whether Clip related problems (like sending ‘0’ along with CLI or not & presenting ‘CLIP’ along with ‘0’ or not), have been solved.

In C-DOT implementation is being done as per Annexure XII, & available in S/W 2_1_7.9_1 & 2_2_1_6.

- 27 -

Annexure - I

Explanation of the Traffic Report Field 'Any Other Reason'

A. For 'ORG-TERM' calls, calls failed due to any other reasons are :

1. Failure because of feature interaction.

2. Call failing because of non-availability of 3 way time slot (In case of Conference Call).

3. DBE Calls failing due to invalid equipment No./non-availability of service circuits.

4. Calls failing due to user rejection by ISDN Subs.

B. For ORG-OG Calls

1. Calls failing due to no route to requested transits network/no route to destination.

2. No response from ISDN user ring tone out occurs i.e. No Answer is received.

3. Called subscriber out of order.

4. Temporary failure on route.

5. Faulty signalling.

6. Service ckts not available.

7. Incomplete address information.

- 28 -

8. Invalid exchange code/route code.

9. Calls failing because of O/G restrictions.

10. Calls failing due to invalid EQN.

11. Calls failing due to junction faulty/spurious ANSWER.

C. OG TRUNK

1. Ring Time out

2. Called No. was unobtainable (Non Existing/frozen)

3. Called No. in LLO state

4. Called No. is accessed barred

5. Signalling failure

6. Invalid signalling

7. Backward signal permanent

8. Forward signal permanent

9. Congestion in Trunk

10. Remote Congestion

11. Junction faulty

12. Blocking

13. Dual Seizure

14. Spurious Answer

- 29 -

D. IC-TRNK

Same as given in 'C' with two additional reasons :-

1. Remote Congestion (in transit calls)

2. Outgoing Restriction (in transit calls)

E Total successful Calls Attempts

It indicates total local calls which originated from PSTN subscriber/operators, for which information about state of called user was received. Apart from completed calls, they include calls released due to:

i) Abandonment after dialling complete

ii) Calls to CP busy subs.

iii) Calls to subs out of order

iv) Called subs being access barred

v) No Answer at the end of ringing

vi) Number unobtainable

vii) Called No. changed

viii) System terminating calls (i.e. subs initiated features like Activation/deactivation of a supplementary service, automatic line testing, calls which get forwarded.

- 30 -

Annexure - II

Handling of Priority Subscribers in MOD-R2/CCS7 Signalling in C-DOT Exchanges

The Category of the priority is passed from one exchange to the other exchange in Mod-R2/CCS7 signalling. These categories are as under :

Subscriber Category Meaning

1 Ordinary Sub

2 Priority Sub

5 Operator

In C-DOT system, the subscriber can be assigned priorities 1 to 8 by the exchange administrator at the time of subscriber data creation, whereas priorities 9 to 13 are assigned by the system itself. These priorities are mapped to the Calling Line Category as follows :-

Calling Line Category

Subscriber Priority MOD-R2 CCS7

1, 7, 8, 9, 10, 11, 12 1 1

2 to 6 2 1

13 5 13

- 31 -

The subscriber priority parameter is used while creating a route i.e. in the TGP choice (TGP-CHC) field of the 'CRE-ROUT' command. Priority '1' is given to all the ordinary subs (belonging to exchange or coming from network), while '2' is assigned to priority Subscribers & 13 to operator.

- 32 -

Annexure - III

CLI Implementation in 256P-RAX

C-DOT 256P-RAX is capable of sending or receiving 10 digits of Calling Line Identification (CLI) information, without sending trunk prefix i.e. 1st Digit as '0'.

Some of the exchanges in the network send CLI along with Trunk prefix i.e. '0' and hence the total digits of CLI are 11. To take care of receiving all CLI digits i.e. 11, NUM-ANI parameter at MAX exchanges is set to 11. In this case, if CLI is demanded from any RAX exchange parented to this MAX, the signalling sequence will be

- 33 -

After receiving called party number Forward Backward

. . . .

RAX does not have any digits MF-Receiver gets time out & call fails Case (b) : Receiving of CLI

If the RAX demands a CLI from the exchange where CLI is being sent along with 0 which means CLI consists of 11 digits. RAX will demand only 10 digit of CLI and hence last digit will never be received.

Note:

To take care of these network problems, in the next software release of RAX, the CLI digits are modified to 11.

A4

1

A4

1st digit of CLI (Not 0)

A4

10th digit of CLI

A4

- 34 -

Annexure - IV

Procedure to Clear Held-up Alarms

Some times it has been observed that some alarms are generated and not cleared even if the fault is attended. In most of the cases making that particular unit OOS and INS solves the problem. In exceptional cases where it is still not cleared, the following procedure can be followed:

i) Go to the IOP5X> prompt and create alm group using the following command (on both IOPs if they are in duplex).

IOP5X> ls $PRCDATAP/apalmp* >$GRP/alm.grp.

ii) Now go to crp and issue the following command (on both IOPs if they are in duplex).

<DEL-FGP-FILE:,alm;

iii) Now give following command on any of the INS IOP, to initialise the system up to part-init:-

<INIT-SYS:,3; in case of SBM and <INIT-MOD: AM, 3; in case of MBM.

This will clear the pending alarms.

- 35 -

Annexure - V

IOP Synchronisation Failure - Cause & Remedies

IOP synhcronisation in C-DOT may fail due to various reasons. There are 6 steps of IOP synchronisation. Various files updated in OOS-IOP from INS-ACT IOP are lying in PRCDATAP directory by the name of sync_grpx (where x takes values from 0 to 5) Each sync group file contains, different type of data files to be 'updated in OOS-IOP to bring it in sync with the INS-ACT IOP. It may happen that certain file is not getting updated within prescribed time limit and as a result sync process will be aborted in that particular step to which the file belongs. During sync, various steps of “Sync over” messages will be displayed on console terminal, ood-terminal & printer also. Most likely, the exact file name will be flashed on console terminal just before “Sync-Abort' message. Then some action is required regarding that particular file before repeating the sync procedure again. In case no file is shown on console before 'sync_Abort' message, still particulars of failure can be seen through 'sync_log' file in $DUMPP directory, using following commands in ACT-IOP:-

IOP5x> cd $DUMPP

IOP5x> tail -50 sync-log

from this note down the name of file, just before the “sync-abort” message and take appropriate action as stated in the subsequent paras 1 to 7.

GENERAL PRECAUTION

Before synchronisation, do delete unwanted files (after taking desired Back-ups) as per standard procedure for Disk-cleaning e.g. ioh, trnsf, bc, tf groups giving appropriate date options in bc & tf. Also run utility 'cre-space' in both the IOP's. As far as possible synchronise the IOP's during slack hours.

- 36 -

1. ♦ Shutdown/reboot both the IOP’s and give frc-swu-ins from acting IOP.

♦ After giving 'put-swu-ins'/frc-swu-ins command from Active IOP, message “synchronisation of IOP begins” does not appear on console terminal and process creation does not start on OOS-IOP, then, most likely HDL (VHC or VDE) card of one of the IOP is faulty. Try by replacing VHC/VDE card first in OOS IOP and then in Active IOP.

♦ Process creation has started on OOS-IOP (4 lines) but ‘synchronisation of IOP begins” message does not appear on ACT-IOP console, then verify s/w loaded in the IOPs. These may be different.

2. “Synchronisation of IOP begins” has appeared but sync is getting aborted in step 0 itself (i.e. “sync over for step 0” is not coming). Do following:

♦ Run utility cre-space in Active IOP.

♦ If 'cre-space' is not available, then give commands :

IOP5x > cd $TEMP

IOP5x> mv oodlogDD noodlogDD

where 'DD' stands for current date

IOP5x> rm oodlog* result*

IOP5x> mv noodlogDD oodlogDD

♦ Shutdown and Reboot ACTIVE IOP (using init_iop:2,1; & init-iop:1,1;). Then make it INS-ACT (init-IOP: 5,1),

♦ start synchronisation again (put-swu-oos/put-swu-ins)

3. 'Sync-Abort' in step 1 (CURRENT DAY DUMPS)

Note down the file name in sync_log file in $DUMPP directory. If it is a traffic file then delete 'tf' grp for current date and synchronise again. However if 'file' is other than traffic related, then contact C-DOT Control Room for further action. Files are: ncbr, tgcbr, tgcntr, locctr*, stdctr* of current date.

- 37 -

4. Sync-Abort in step 2 (Subs Initiated Feature Related Files)

Repeat sync in late night hours, when no traffic is there. Before synchronization, bring Active IOP to Cold Start (using INIT-IOP:2,1; and INIT-IOP:1,1;). Reboot IOP and make it INS-ACT, by init-iop:5,1; command.

5. Sync-Abort in step 3 (Complete Exchange Data Files)

In this step all Ed files are transferred. Note down the file name and consult CDOT Control Room for further action, as 'ed' files are difficult to handle. In some cases, 'copy-in' old Ed in the active IOP in warm start level and then make it active again. Then give "part-init” and start sync. process again.

6. Sync-Abort in step 4 (Maintenance Initialisated Process Data Files)

IOP5x> find /u -name *.log - print

Note down the directory and *.log file names.

Then go to the particular directory and remove log files by giving full names.

IOP5x>rm abc.log etc. [where abc.log is the file name]

IOP5x>cd $TEMP

IOP5x>rm result*

IOP5x>cd $FDTDIR

IOP5x>rm heal*

Now give 'softstart' to the system, using <init-sys command, in crp mode.

i.e. <init-sys :, Soft-Start;

After System has recovered fully, repeat the synchronisation procedure.

- 38 -

7. Sync-Abort in step 5 (PAST DAY DUMPS)

This is the most probable step of sync failure. In this step, all “Detail Bill Files”, “traffic files” and all “oodlogxx” files are transferred. Normally, by deleting previous 'tf' and 'bc' files will solve the problem.

Otherwise, note down exact file name in 'sync_log' file in $DUMPP directory. Then delete that file using <del-fgp-file command. Remove all 'oodlog' files in $TEMP directory, as mentioned in para 2.

Then repeat the synchronisation process.

Following files for past days (Not current day file) are transferred: All ‘tf’ gp files, ncbr files, tgcbr; tcntr, oodlog files.

- 39 -

Annexure - VI

Reasons of Call Failure

In case a call is failing (Local call or a route call), the cause of call failure can be established by putting the call no. on observation for 'Originating Call' and then checking its 'Call Detail Record' (CDR). For this, use crp command 'mod-sub-obs' to put the calling no. on 'originating observation'. Then make some calls from the calling no. CDR will be generated for these calls, which can be displayed using command 'displ-cdr'. In that CDR, watch for the field "Call Status". After decoding the message written in this field, we can guess the probable reason of call failure. Meaning of the call status field values are given below:

1. 162_TST - 162 line test service.

2. ABANDON - Call abandoned.

3. ABS_SRVC - Absentee service.

4. ACB_RING_OUT - Auto Call Back Ring Time Out.

5. ACCESS_BARRED - Access Barred.

6. ADDRESS_INCOMPLETE - Address Incomplete.

7. ADMN_BSY - Subscriber Admin Busy.

8. ALARM - Alarm offered as a waiting call did not mature (No longer in use)

9. ALM_MON - Alarm monitoring.

10. ANI_N_PSBL - Automatic Number Identification not possible.

11. BILL NOT_PAID - Call failure due to Bill not Paid.

- 40 -

12. BLOCKING - Blocking on the route.

13. BSY_TO_PSBL - Busy & Trunk Offer Possible.

14. BW_SGN_ABSENT - Backward Signalling Absent.

15. BW_SGN_PRMNT - Signalling Fault-Backward Signalling Permanent.

16. CALL FAILURE - Call failed due to Circuit supervision activity

17. CALL KILLED - call failure due to kill call command

18. CALL_WT_CLNG - Failure due to Call Waiting at the calling party.

19. CALL_WT_IND_TM_OUT - Call waiting Indication time out.

20. CHNGD_NUM_ANNC - Changed Number Announcement.

21. CHNL _CONGESTION_REMOTE - Failure due to channel congestion at RBM.

22. CHNL CONGESTION - Failure due to congestion in Channel in DTK for origination at RBM.

23. CLLD_BNP_OOS - Called Party OOS due to Bill not paid.

24. CLR_IMM_PRTY_A - Clear Immediately Party A.

25. CLR_IMM_PRTY_B - Clear Immediate Party B. /* SHELJA

26. CONCKT - Conference circuits

27. CONG_TRNK - Congestion on Trunk.

28. CONGN_LN_GRP - Congestion in Hunt group.

29. CONV_TM_OUT - Conversation Time Out.

30. CP_BSY - Subscriber CP Busy.

31. CSH_TM_OUT - Called Subscriber Held Timeout.

32. DBE - Dial By Eqn,

33. DT_TM_OUT - Dial tone time out.

- 41 -

34. DUAL SEIZURE - Dual Seizure of a trunk.

35. FAC_N_IMP - Facility Not Implemented.

36. FAULTY_CKT - Faulty circuit.

37. FL_AS_DIVERSION_NOT_POSSIBLE - Diversion not possible.

38. FTR_CNCL - Feature cancelled.

39. FTR_INTERACTION - Feature Interaction-

40. FTR_INVC - Feature Invocation.

41. FW_SGN_PRMNT - Forward Signalling Absent.

42. IDT_TM_OUT - Inter Digit Time Out.

43. INV_INVC - Invalid Invocation.

44. INV_SGN - Invalid Signalling.

45. IW_CODE - Wrong Prefix Digit.

46. JN_FAULTY - Junction Faulty.

47. KIL_TRK_L2 - Killer trunks level 2

48. KIL_TRK_LL - Killer trunks level 1

49. LINE_SGN_FAILURE - Line signal failure. This could be due to loopback removal.

50. LLO - Line Locked Out.

51. MH_TM_OUT - Manual Hold Timeout.

52. MTCE_BSY - Subscriber Maintenance Busy.

53. NO_DIAL - No digits dialled.

54. NO_SEIZURE_ACK - No seizure ack received.

55. NU - Called Number Unobtainable.

- 42 -

56. OG_RSTRCTN - Outgoing Restriction.

57. OVERLOAD - Call failure due to overload detection.

58. PART_DL - Partial Dialling

59. REMOTE_CONGN - Remote Congestion.

60. RING_OUT - Ring Time Out.

61. ROUT_OUT_ORDR - Route out of order.

62. ROUT_RECNT_CHGNG Route Recently changed.

63. RSRC_N_ALCTD - Resource Not Allocated-Shortage of service circuits..

64. RSRC_N_AVAIL - Resource Not Available.

65. SGN_FAILURE - Signalling Failure.

66. SPURIOUS_ANS - Spurious ans received on the trunk.

67. SS_BLOCKING - Space Switch Blocking.

68. ST_COND - End of dialling received.

69. SUCC_CALL - Successful Call.

70. SWTCH_BLOCKING - switching Blocking.

71. SYS_REC - System Recovery.

72. TO_N_PSBL - Trunk Offer Not Possible.

73. XCHG_INVC - Exchange Invocation.

- 43 -

Annexure - VII

Detail Bill Files (BC Group) Management

The system creates one file for each day of the year to which entries of the STD calls done by subscribers are made. Thus for 365 days of the year there would be 365 files. These files have date and month stamps but no year stamp.

Failure to do regular disk cleaning can lead to a situation where data corresponding to two identical dates of two consecutive years is present on the disk in one file. Thus data corresponding to 1.5.98 would get appended on the data of 1.5.97 already present on the disk. When detail bill records of 1.5.98 are sought to be displayed, the records of 1.5.97 will also be displayed intermixed with those of 1.5.98. This will lead to discrepancies as the total calls made during the billing cycle will be less than the sum of units shown for the STD calls in the Detailed Bill for that period. Thus by regular disk cleaning, this situation will never arise.

Solution : To avoid such a situation, it is recommended to delete all previous files from the date of commissioning to the present date (After taking back ups). For example if the excahnge was commissioned in 15.7.97 and this command is being executed on 15.4.98 and it is desired to keep one month billing files, then execute from CRP,

<del-fgp-file :, bc{15-7-97 —> 15-3-98} ;

This will delete all previous files. The cleaning should be done every fortnight (after taking required backup) taking care that no day is left uncovered to avoid overlapping of the detailed bill records.

Important : Keep it as a practice to regularly take back-up & delete the old files. The periodicity may vary from 15 days to 3 months depending on the no. of cartridges available, billing cycle, disk space consumption etc.

- 44 -

Annexure - VIII

Guide Lines for No. of TGP's and Routes to be put under Observation Simultaneously

For SBM, there is no restriction on no. of Routes and TGPs to be kept under observation simultaneously.

For MBM, following table indicate no. of Routes and TGPs that can be put under observation simultaneously :

Configuration No. of BMS No. of Routes under Obs. Max. No. of TGPs under Obs.

MBM-L Upto 5 Upto 50 40

51 to 80 35

81 t0 90 30

91 to 100 10

101 to 110 0

Upto 8 Upto 30 40

31 to 40 35

44 to 45 30

46 to 50 10

51 to 54 0

Up to 12 Upto 15 40

16 to 25 30

26 to 30 10

31 to 35 0

13 to 16 Upto 15 40

16 to 21 30

- 45 -

Configuration No. of BMS No. of Routes under Obs. Max. No. of TGPs under Obs.

22 to 27 0

MBM-XL Upto 24 Upto 24 40

25 to 27 10

28 to 30 0

25 to 32 Upto 18 40

19 to 21 10

- 46 -

Annexure - IX

Limits for Subscriber Line Parameters

The limits of insulation resistance, loop resistance and capacitance for different line categories of subscribers are shown in the table below.

The line category of the subscriber has to be assigned depending on the values of insulation resistance capacitance and loop resistance. These may vary depending on the instrument connected. Normally category 2 can be used for DTMF instruments. The default limiting values for different categories are listed below.

Category Insulation Resistance (Low) in

kohms Insulation Resistance (High) in

kohms

a & gnd b & gnd a & b a & gnd b & gnd a & b

1 20.0 20.0 20.0 20000 20000 20000

2 20.0 20.0 20.0 20000 20000 20000

3 20.0 20.0 20.0 20000 20000 20000

4 20.0 20.0 20.0 20000 20000 20000

5 20.0 20.0 20.0 20000 20000 20000

6 20.0 20.0 20.0 20000 20000 20000

7 20.0 20.0 20.0 20000 20000 20000

Contd..

- 47 -

Category Capacitance (micro

farade) Loop Current (milli

Amps) Loop Resistance

(ohms)

LOW HIGH LOW HIGH LOW HIGH

1 1.5 3.0 20.0 36.0 100.0 2400

2 0.15 3.0 15.0 36.0 100.0 3200

3 1.5 3.0 20.0 36.0 75.0 2400

4 0.15 3.0 15.0 36.0 75.0 3200

5 1.5 4.0 15.0 36.0 100.0 3200

6 0.15 4.0 13.0 36.0 100.0 3600

7 1.5 8.0 20.0 36.0 100.0 2400

Note : If external voltage on the line is more than 5.99 volts. no other tests will be conducted.

Limits for Dial Tests

5th closing high 60 msec

5th closing low 16 msec

5th opening high 100 msec

5th opening low 42 msec

Dial Ratio high 4

Dial Ratio low 1

Dial Speed high 12 IPS

Dial Speed low 8 IPS

- 48 -

Annexure - X

Engineering the VU V5.2 Unit

The only growth element in VU is the SHM card. SHM card contains Protocol Handler Controller (PHC) terminal, which can be configured as signalling terminals or internal message protocol (C.85) terminals. Out of the 8 PHC terminals available per SHM card, two (2) C.85 terminals are used for internal message communication of the VU with the processor of the BM in which it is equipped. The remaining terminals are available for utilization of C-Channels for each AI interface to be created. Two terminals per AI will be utilized, if both primary and secondary links are created.

The utilization of C.85 terminals for C-Channels is governed by system parameter "V5-THR". The default value of this parameter in BMDC is 50 (percent). Hence, out of the eight (8) C.85 terminals available per SHM card, four (4) terminals can be used for C-Channel and out of the remaining four (4) terminals, two (2) are utilized for internal message communication of the VU with the processor of the BM in which it is equipped. Hence two C.85 terminals are left spare. So, with one (1) SHM card equipped, we can create only two AI with both primary and secondary links of each AI inservice. If status of any of the four (4) PHC terminals goes OOS-SE, due to same hardware problems then we are left with only four (4) PHC terminals, two (2) for internal communication and two (2) for C-Channels. So, either the primary of both the AI will be inservice and secondary of both the AI will be down or only one interface can be up. To utilize the available C.85 terminals in a proper manner, we can set the system parameter 'V5-THR' to 75 (percent), which will give six (6) C.85 terminals for C-Channels. Set the value of system parameters VU-INT-THR to 25. The sum of parameters V5-THR + VU-INT-THR. But it is advised that at least two (2) SHM cards should always be equipped so that if status of some of the PHC terminal goes OOS-SE, the interface do not go down. By using two (2) SHM cards, we get 16 C.85 terminals out of which 12 terminals can be utilized for C-Channels and four (4) terminals or internal communication (with the value of system parameter V5-THR = 75). Hence, if three (3) interfaces are created with both primary and secondary link inservice, six (6) C.85 terminals are utilized. Still we have six (6) C.85 terminals spare for C-Channels and two (2) C.85 terminals spare for internal communication.

- 49 -

Annexure - XI

Defining TGP Type in Local/TAX/ILT Exchanges at various Nodes

X-1 X-2 X-3 X-4 X-5

X-8 X-7 X-6

N-A N-B N-C N-D N-E N-F N-G N-H

N-L N-K

N-N

N-M

S-A

S-B

S-C S-D

- 50 -

Type Of Exchange XCHG-TYPE

X-1 Local Terminal Exchange 2

X-2 Transit Exchange may be ILT 2

X-3 Leading TAX 4

X-4 Transit TAX 4

X-5 Terminating TAX 4

X-6 Transit Exchange may be ILT 2/4

X-7 Terminal Exchange 2

X-8 Terminal Exchange parented to TAX/ILT working in Multi Exchange mode

2

Network node Type of node TGP-TYPE

MTR-TYP (FOR TAX CALLS)

MTR-TYP ( FOR NON-TAX CALLS)

N-A O/G TGP of X-1 ORD PRD-TAX PRD-LCL

N-B I/C TGP of X-2 ORD - NO-MTR

N-M O/G TGP of X-2 towards group exchange ORD - NO-MTR

N-C O/G TGP of X-2 towards TAX Network TTAX PRD-TAX -

N-D I/C TGP of X-3 ORD - NO-MTR

N-N I/C TGP of X-8 ORD - NO-MTR

N-E O/G TGP of X-3 ORD PRD-LCL -

- 51 -

N-F I/C TGP of X-4 TTAX - NO-MTR

N-G O/G TGP of X-4 ORD NO-MTR -

N-H I/C TGP of X-5 TTAX - NO-MTR

N-I O/G TGP of X-5 ORD NO-MTR -

N-J I/C TGP of X-6 TTAX - NO-MTR

N-K O/G TGP of X-7 ORD NO-MTR -

N-L I/C TGP of X-7 TTAX - NO-MTR

S-A Subscriber at X-1

S-B Subscriber at X-2

S-C Subscriber at X-8

S-D Subscriber at X-7

MTR-TYPE at Incoming node is for the i/c terminating calls defined using command mod-sub-crg.

- 52 -

Annexure - XII

Implementation of CLI Sending and Presentation (CLIP) in 2_1_7.9_1/2_2_1_6 Software

A. Definition of system Parameters

For Asking CLI For Sending Area Code along with CLI

NUM-ANI=10 (Say Area Code = 02345)

ARCD-DGT1 = 10 ARCD-DGT2 = 2 ARCD-DGT3 = 3 ARCD-DGT4 = 4 ARCD-DGT5 = 5

B. In CCS-7 signalling

♦ CLI without 0 will be sent across network.

♦ 'NAI' value will be set to 'NATIONAL'

♦ At Terminating Exchange, 'CLI' on sub's Monitor will be presented with '0' prefixed to Area Code.

C. In MOD-R2 Signalling

♦ CLI without '0' will be sent across network.

♦ At terminating Exchange, 'CLI on sub's Monitor will be presented without '0'

Cfa Tariff Book

Documents

Transcript of Cfa Tariff Book