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 Annexure - II Annexure - III Annexure - IV Annexure - V Annexure - VI Explanation of the Traffic Report Field 'Any Other Reason' .........................................................27 Handling of Priority Subscribers in MOD-R2/CCS7 Signalling in C-DOT Exchanges................30 CLI Implementation in 256P-RAX ..................................................................................................32 Procedure to Clear Held-up Alarms ................................................................................................34 IOP Synchronisation Failure - Cause & Remedies.........................................................................35 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 Annexure - X Annexure - XI Limits for Subscriber Line Parameters...........................................................................................46 Engineering the VU V5.2 Unit) .......................................................................................................48 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

Name of Site/Circle : Haryana

S.No. 1. Problem Detail Sometimes `copy-out' is possible but `copy-in' fails for some cartridges. Solution/Comments 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. This is due to non-updation of transactions files in one or both IOPs following are the solutions : i) ii) Shutdown re-boot both IOP's one by one & then synchronize Fresh s/w loading in IOP may solve the problem.

2.

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

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 Root Volume Code Volume Data Volume Exdata Volume 'U' Volume 4. Sometimes in one directory `free blocks' become zero. How to increase free blocks. i) ii) Drive/Slice 1 dev/dsk/m320_0S0 i.e. `drive 0', `Slice 0" drive 1, Slice 1 Drive 0, Slice 4 Drive 0, Slice 5 Drive 0, Slice 6

Sometimes Shutdown/Reboot IOP solves the problem 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.

-5-

S.No.

Problem Detail -

Solution/Comments 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 directory e.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. `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..

ii)

6. 7. 8. 9.

Sometimes one TUI and TIC card works in a particular frame but do not work in another frame. Dynamic locking facility on 95 should be made available. `Displ-tgp-status', should work for TGPs having more than 40 trunks. In BM-XL `TSU frame' lot of cabling on motherboard should be avoided, instead a composite motherboard should be there. Hotline from DIR-NO. to TEN should be available (P-wire concept). Meter Reading printout in`Bulk' should be implemented for deleted `DIR' NOs. also. "Rank of Digit" should be associated with route instead of TGP, so that same TGP can be used for `routs' having different ROD's. Traffic reports show anomally while counting various fields. -6-

This could be due to improper connection between the card and the motherboard male/female points. Being provided in S/W releases 2_2_1_6 Though not possible through 'crp', the same can be seen through 'utility 'tgputil', available in rgen cartridge. 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. It is not implemented at present. Requirement is noted for future implementation Cannot be implemented in near future

10. 11. 12. 13.

S.No. a) b)

Problem Detail Total no. of calls is not equal to sum of completed and failed calls. Calls failed due to `Any other reason' is not clear. This may be explained in detail. a) b)

Solution/Comments Yes, the figure does not match 100%, but it has been corrected in 2_1_1_1 S/W to show minimum difference. 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. 15. 16. 17. 18.

Password should be BM associated. Centrex facility should be available. In Annc. card announcements should be locally programmable. In CM-XL rearside trough should be provided to protect lot of loose cabling. 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 . The subscribers who have not registered their dynamic codes, get locked whenever Base Module is initialised up part-init/code load level. CCM card should provide 16 KHz to all the `8' ports instead of only 7th & 8th port. `CLIP' facility should be available on all the 8 ports and should be programmable in S/W only.

Requirement is noted for future implementation. Requirement is noted for future implementation. New announcement card `ASV' supports this facility and can be used in 2_2_1_4 S/W. Will be taken care in the new CM design. 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. 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. Existing card cannot be modified. But new 16 port CCM card supports 16 KHz on all the ports. 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. It has been taken care in the new LCC/CCM (ECL) card, which will be supported in new VE-BM. Requirement is logical, but not feasible with present design. Although directly it is not possible but can be planned using Calendar Administration, once a day, using both IOP's

19.

20. 21.

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. Subscriber facilitates which are presently not available should be masked in S/W. Automatic Back-ups for dumps of ED & BD once a day should be provided. -7-

23. 24.

S.No. 25.

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

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

26.

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

S.No. 1. Problem Detail 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. Solution/Comments 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. This feature is being implemented & solution will be provided in NLDO release 2_3_1_6. 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. 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.

2. 3.

CLI based call restriction in I/C TGPs. 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. 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.

4.

-8-

S.No. 5.

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

Solution/Comments 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. 7. In IN switch (SSP), IOP synchronization problem comes frequently due to various files like tcntrddmm.dat or iodk*, exrp* files etc. 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'. 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.

Solution will be provided in subsequent S/W releases meant for IN switches (2_2_1_4(5.4)). 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. 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. Matter is to be resolved with TEC. As per implementation metering of CCB-PCO is governed by the Charge-Rate NO. given against system parameter 'PCO-MTRLCL', which is normally 'FXD-MTD' with 'INI-CHRG = 1'. Thus call made on Non-mtd route will still be metered by referring this parameter. Mostly due to Media problem in one or more PCM's on BUS0/BUS-1. Solution is to isolate DTK's, one by one.

8.

9. 10.

CLI problem with OCB-283 switches with CCS#7 signalling TGPs, as '0' is being prefixed before area-code. 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.

11.

Frequent failure of IFCs is observed in case of RBMs.

-9-

S.No. 12.

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

Solution/Comments 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. Discrimination possible only at class of command level. Command level implementation not envisaged in near future. 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). Memory is a constraint at present. '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. List of MSN Nos. can be seen using 'DISPL-SUB-LIST' command.

13. 14.

There should be provision for the administration to put any command on any class for operator management. The maximum limit of charge rate Numbers is to be raised from 127 to meet the IUC requirement for BSOs. There is no provision to see 'MSN' DIRNO for any ISDN line with any of the commands. 'ADD-MSN-DN' command for 2nd MSN gives an error as "MSN already exist". 'ADD-MSN-DN' for 1st MSN itself for another ISDN line gives the same error.

15.

16.

In-compatibility is existing for different makes of ETS cards in the exchange i.e. ETS of ITI make & that of BHEL make may not work together in the same RSU. Exchange A is connected to B (TAX) via CCS7 and 'B' is further connected to exchange 'C' (Local) via CAS/CCS7, then sub 'X' of A exchange calling to Busy sub 'Y' of C, gets congestion tone instead of Busy Tone.
A

No such problem has been repeated earlier. This can be investigated by C-DOT. 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'.

17.

CCS7

CCS7

18. 19.

CDOT can plan further investigation for such sites. It is not a case of ineffective functioning. Priority implementation for MOD-R2 and CCS7 is different. It is explained in Annexure II.

Even after doing 'ECN' on PSS/PSM cards, some noise in ring back tone is observed. DTMF functioning is ineffective on local subs. having "Sub-Priority" other than '1' for STD calls going on CCS7 route.

- 10 -

S.No. 20. 21.

Problem Detail For some ISD calls, non-metering is noticed in No. 7 signalling. 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. IOP synchronization problem in Patch 2_1_7.3_1, if NCBR data exist for more than 2 months. Sync fails in step 5.

Solution/Comments Only possible, when charge Band associated to in-correct ChargeRate Nos. at originating exchange. 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. 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. i) ii) If CCB PCO is all purpose then metering can not be stopped if used for IN call using ITC card. 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.

22.

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.

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 (BNPANNC/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. 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. 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.

25.

I/C calls fail on sub Nos. having either malicious or 'CLIP' facility.

26.

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

- 11 -

S.No. 27. 28.

Problem Detail To bring Trks in CCS7 'Busy' to normal status with a simple command is required. Command 'mod-blk7-sts' takes too much time. 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. 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. 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. MFC circuits go 'oos-sys' frequently at MBM Tekkah and causes excessive call failure.

Solution/Comments No other option for the time being. 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. Problems has been observed at some sites and cause is under investigation. 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. Problems will be investigated by C-DOT, after feed back from more sites.

29.

30.

31.

Name of Site/Circle : GMTD, Alwar

S.No. 1. Problem Detail 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. From CCBPCO, an IN call is possible but Exchange counter is incremented by one unit. Solution/Comments 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.). Refer solution to Problem No. 23 under Andhra Pradesh.

2.

- 12 -

S.No. 3.

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

Solution/Comments Not possible as per implementation.

4.

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) ii) Change number announcement in case of change of indicator. It is possible to feed announcement to the routes as and when required. 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.

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.

- 13 -

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

S.No. 1. Problem Detail IOPs go out of synchronization frequently and even one-month data is not transferred during synchronization. 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. In RGEN utility (2_2_1_3), data is not coming. ADP gives false alarms OK Solution/Comments Mostly in 2_2_1_4 s/w sync Problems is under observation.

2.

Upgrade s/w to 2_2_4.4_4. BM-7 problem got solved after CPU change & code load to BM.

3. 4.

Latest 'RGEN' is available now, which should be loaded in both the IOP's. New RGEN is of block size = 1398. 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. Number is under BNP-DISC, even then subscriber is availing the facilities. Testing of reversal/16 KHz on CCM card.

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. If status is passwd-tmprd, make it normal by 'mod-lin-sta' Problem to be fixed in S/W 2_2_1_6. 16 KHz, can be checked using external equipment only. Reversal is tested during '103' test set

6.

7.

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

S.No. 1. Problem Detail Some time CCS7 links hang, part init to SUM is required. Solution/Comments Much stable in S/W 2_1_7.7_1 own ward Patches will be propagated in 2_2_1_6 s/w.

- 14 -

S.No. 2.

Problem Detail Some routes are accessible on MF but not getting on CCS7.

Solution/Comments There can be various possibilities. Please refer Annexure - XI for probable cause. Proper mapping of Charge Band is must for CCS7 working.

3. 4. 5. 6.

Some method for observation of CCS7 calls as MFSA in MF. 95 locking facility should be provided. Some 256 CDOT RAX subs. are not getting STD on CCS7 links through CDOT MBM. Diagnostics of cards are not proper.

Suggestion is noted. May be considered in VE BM S/W. To be made available in 2_2_1_6 S/W Same as problem '2' above. 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)

S.No. 1. Problem Detail Too many stations become unavailable when CAMA parameter yes. Solution/Comments 'CAMA' parameter in 'TGP', becomes effective when TGP type = ORD, system parameters: XHG-TYPE=4, CLIINFO=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. 3. Calls are not being matured when number of links is more in switching. Data updation takes much time, even in some cases, PI is required.

Refer Annexure - XI for explanation. Problem has been solved in 2_1_7.x_1 series.

- 15 -

S.No. 4. 5.

Problem Detail CM hangs due to frequent ON-OFF of DTK-RBM links. Data transfer gets slowdown with the introduction of NSE.

Solution/Comments Problem is under observation. 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.

- 16 -

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

S.No. 1. Problem Detail 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(codeload) level. Suddenly all working directory numbers stop getting updated after numbers are made in oos-opr. Some times locctr & stdctr updation stops. Solution/Comments Change of trunking/routing data does not disturb charging of the whole exchange. No case has been reported.

2. 3.

Problem was observed in earlier s/w releases & has been solved in S/W 2_1_7.5_1 ownward. 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. 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

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.

Name of Site/Circle :
S.No. 1.

Ramganj Mandi(Raj)
Problem Detail Solution/Comments 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. - 17 -

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.

S.No. 2.

Problem Detail 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? While diagnosing the control cards results displayed instantly on pressing E key and always okayed report. It creates confusion. Please clarify the reasons.

Solution/Comments 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. In some case, if all the connected links of the unit are nonoperational, 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. In field 'Last-Rep', value '0' should be given to get all the resports. It is not required, as all the Trks of one TGP will acquire same characteristics as that of TGP itself. In S/W release 2_2_1_4, some case of INS-FRC/INS-NRML/CPBUSY have been observed. For this observation is being taken to solve the problem. Till than soft start to concerned mode is the solution.

3.

4. 5. 6.

Reports through command DISPL-OOD-LOG . Only 10 reports (max.) are available , can the no. of reports be increased? Procedure for taking details of trunk cct of a TGP, like a DIRNO. Generally some of the telephones are lying in faulty condition and become okay only on giving SOFT-START to the BM concerned.

Name of Site/Circle :
S.No. 1.

Chittorgarh(Raj.)
Problem Detail Solution/Comments 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. 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).

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. 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 we dial ISDN PRI HGPs PDN from PSTN, we are getting busy tone. we are not getting servers response tone. When we are di lli t t ti PDN ( Bhil )b di lli STD d - 18 -

2.

3.

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

S.No.

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

Solution/Comments 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 'DISPLRBM-DTKs' at Main & through BP. Terminal at RSU end (explained in 'BP Terminal' application note). 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. No 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)

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? Is there any provision to provide ISDN facility to RSU subs. without installing ISTU 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.

6. 7.

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 :
S.No.

Jaitaran (Rajasthan)
Problem Detail Solution/Comments

- 19 -

S.No. 1.

Problem Detail Sometime in SBM/MBM local counter dump cant 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.

Solution/Comments 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/CODELOAD 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 'softstart' 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. 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.

Implementation is so.

3.

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

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

5.

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.

- 20 -

S.No.

Problem Detail

Solution/Comments 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 :
S.No. 1. 2. 3. 4.

Barmer(Raj) (2_2_2.10_3)
Problem Detail Solution/Comments 'VU' related problems have been solved in latest s/w release 2_2_4.4_4, which should be upgraded immediately. S/W upgradation to 2_2_4.4_4 will solve the problem. Problem of 'INS-NRM' is under study and solution will follow. 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.

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 normal, AI status normal, but calls matured only after soft-start to VU BM. The subs. of AN showing INS-NRM but calls fail. Call only matures after giving oos-opr and put in service of that subs. 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.

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

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.

S.No.

Problem Detail

Solution/Comments '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 parameters is not functioning.

with

OCB-283

with

same

Normally there is no such problem in CCS7 working with 'OCB283'. This may be a site specific, problem and parameters at both ends can be verified. 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 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.

8.

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

9.

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

10. 11. 12. 13.

Is 95 locking possible in 2_1_1_1? System parameter 'ARCD-DTG1' should value '0' or '1' by default?. Calls to particular site is not matured when CAMA =yes for I/C TGP from RAX 256(4-2-1). During X-code modification, why audit is required for some files.

No. It will be provided in s/w release 2_2_1_6. By default this has value '0', which should be changed to '10', while updating for Area Code prefixing, if 0 is to be defined. This may happen only if system parameter 'NUM-ANI' is '11' at SBM/MBM site, as 'RAX' can not send '11' digits CLI. 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.

- 22 -

Name of Site/Circle : Orissa

S.No. 1. 2. 3. Problem Detail Alarms not getting updated properly in ADP. 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. 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. There remains a urgent alarm in the ADP in respect of SUM. SUM reloads automatically many times. Solution/Comments 'ADP' Performance will be improved in 2_2_1_6 S/W. Because of excessive code/patch/Dats in 2_2_1_3/2_2_1_4, IOP updation is slightly slow. Problem is under observation and some solution will be given in 2_2_1_6 S/W.

4. 5.

Same as at S. No. 1. '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. 7.

CCS-7 calls to different transit exchanges fails. Metering not ok on some routs. Even the LS status is active and available, status of some of the PCMs in CCS-7 is displayed as INSF-S7BSY. Overloading of trunk BMs handling CCS-7 calls with SRFSOFTWARE-COUNTER-OVERFLOW. 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 putin:status of all link: AN-BLK. DCR in respect of TGP is not tallying with the TGP counter value. IUC implementation: charge rate numbers and duration. How to implement?

Proper creation of CRG-RTN's and CHBS is very crucial in CCS7 working. Data should be thoroughly checked at LE. 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. Note down type of recoveries as shown on BP Terminal put on Trunk BM & consult C-DOT to decode them.

8. 9.

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

10. 11.

Problem, may be on I/C TGP & terminating calls. Use 'CRG-RTN having 'chrg-mode' as 'SLF-LCL'. 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.

- 23 -

S.No. 12. 13.

Problem Detail Summing up duration in DCR. Whether possible or not. If possible then how. Many time message on console comes as add-sbrd-file error in iswrite. This message repeats frequently, what action should be taken. 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/Comments Yes, utility is available in new 'rgen cartridge for 2_2_1_4. 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??.) Solution is to give either 'PI' to BM or soft start to system. Precise solution will be provided in 2_2_1_6.

14.

Name of Site/Circle : UP-WEST

S.No. 1. 2. 3. Problem Detail Provision of Centrex facility in C-DOT Exchange. Regarding announcment feeding in Dynamic lock password jamming in C-DOT Exchange. 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. Decrease of meter reading due to PART-INIT command in BM-3 at Chandpur C-DOT MBM. Regarding unsatisfactory working of CCS-7 rack in C-DOT Exchange Bijnor. Regarding unsatisfactory working of ISDN service in C-DOT Exchange. Overlapping of detailed bills of different years in CDOT exchanges. Solution/Comments Effort is going on to provide this facility in subsequent s/w releases (Not planned in 2_2_1_6). Suggestion to be considered. Excess metering due to voltage fluctuation, do not occur in C-DOT SBM/MBM exchange. But may occur in 256 RAX.

4. 5. 6. 7.

This is a site specific problem & does not occur in general. Certain 'ECN' in SHM cards will assure CCS7 stability. Details are available with C-DOT. In 2_2_1_4, ISDN working is quite satisfactory. ECN in BRL card & revised ITC proms in ISTU are required. This may happen as 'year' stamp is not there is detail Bill files. So 'BC' must be deleted for the previous year.

- 24 -

Name of Site/Circle : RMC, Channai

S.No. 8. Problem Detail Calls from other stations to a CDOT number on call forwarding facility not getting metered on CCS-7 but ok on R2. Solution/Comments 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. Suggestion of making ROD and CAMA as ROUTE specific instead of TGP specific were noted in the same workshop. Whether implemented.

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

12.

No and not being planned as yet.

- 25 -

S.No. 13.

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

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

- 26 -

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. 2. 3. 4. B. Failure because of feature interaction. Call failing because of non-availability of 3 way time slot (In case of Conference Call). DBE Calls failing due to invalid equipment No./non-availability of service circuits. Calls failing due to user rejection by ISDN Subs.

For ORG-OG Calls 1. 2. 3. 4. 5. 6. 7. Calls failing due to no route to requested transits network/no route to destination. No response from ISDN user ring tone out occurs i.e. No Answer is received. Called subscriber out of order. Temporary failure on route. Faulty signalling. Service ckts not available. Incomplete address information.

- 27 -

8. 9. 10. 11. C.

Invalid exchange code/route code. Calls failing because of O/G restrictions. Calls failing due to invalid EQN. Calls failing due to junction faulty/spurious ANSWER.

OG TRUNK 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Ring Time out Called No. was unobtainable (Non Existing/frozen) Called No. in LLO state Called No. is accessed barred Signalling failure Invalid signalling Backward signal permanent Forward signal permanent Congestion in Trunk Remote Congestion Junction faulty Blocking Dual Seizure Spurious Answer

- 28 -

D.

IC-TRNK Same as given in 'C' with two additional reasons :1. 2. Remote Congestion (in transit calls) Outgoing Restriction (in transit calls)

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) ii) iii) iv) v) vi) vii) viii) Abandonment after dialling complete Calls to CP busy subs. Calls to subs out of order Called subs being access barred No Answer at the end of ringing Number unobtainable Called No. changed System terminating calls (i.e. subs initiated features like Activation/deactivation of a supplementary service, automatic line testing, calls which get forwarded.

- 29 -

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 1 2 5 Meaning Ordinary Sub Priority Sub 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 1, 7, 8, 9, 10, 11, 12 2 to 6 13 MOD-R2 1 2 5 CCS7 1 1 13

- 30 -

The subscriber priority parameter is used while creating a route i.e. in the TGP choice (TGP-CHC) field of the 'CREROUT' 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.

- 31 -

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

- 32 -

After receiving called party number Forward

A4 1 A4 1st digit of CLI (Not 0)

Backward

. . . .
A4 10th digit of CLI A4

RAX does not have any digits Case (b) : Receiving of CLI

MF-Receiver gets time out & call fails

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.

- 33 -

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.

- 34 -

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

- 35 -

1.

Shutdown/reboot both the IOPs 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.

- 36 -

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 IOP5x>cd IOP5x>rm IOP5x>cd IOP5x>rm abc.log etc. [where abc.log is the file name] $TEMP result* $FDTDIR 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.

- 37 -

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

- 38 -

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-subobs' 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. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 162_TST ABANDON ABS_SRVC ACB_RING_OUT ACCESS_BARRED ADDRESS_INCOMPLETE ADMN_BSY ALARM ALM_MON ANI_N_PSBL BILL NOT_PAID 162 line test service. Call abandoned. Absentee service. Auto Call Back Ring Time Out. Access Barred. Address Incomplete. Subscriber Admin Busy. Alarm offered as a waiting call did not mature (No longer in use) Alarm monitoring. Automatic Number Identification not possible. Call failure due to Bill not Paid.

- 39 -

12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33.

BLOCKING BSY_TO_PSBL BW_SGN_ABSENT BW_SGN_PRMNT CALL FAILURE CALL KILLED CALL_WT_CLNG CALL_WT_IND_TM_OUT CHNGD_NUM_ANNC CHNL _CONGESTION_REMOTE CHNL CONGESTION CLLD_BNP_OOS CLR_IMM_PRTY_A CLR_IMM_PRTY_B CONCKT CONG_TRNK CONGN_LN_GRP CONV_TM_OUT CP_BSY CSH_TM_OUT DBE DT_TM_OUT

Blocking on the route. Busy & Trunk Offer Possible. Backward Signalling Absent. Signalling Fault-Backward Signalling Permanent. Call failed due to Circuit supervision activity call failure due to kill call command Failure due to Call Waiting at the calling party. Call waiting Indication time out. Changed Number Announcement. Failure due to channel congestion at RBM. Failure due to congestion in Channel in DTK for origination at RBM. Called Party OOS due to Bill not paid. Clear Immediately Party A. Clear Immediate Party B. /* SHELJA Conference circuits Congestion on Trunk. Congestion in Hunt group. Conversation Time Out. Subscriber CP Busy. Called Subscriber Held Timeout. Dial By Eqn, Dial tone time out.

- 40 -

34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55.

DUAL SEIZURE FAC_N_IMP FAULTY_CKT FL_AS_DIVERSION_NOT_POSSIBLE FTR_CNCL FTR_INTERACTION FTR_INVC FW_SGN_PRMNT IDT_TM_OUT INV_INVC INV_SGN IW_CODE JN_FAULTY KIL_TRK_L2 KIL_TRK_LL LINE_SGN_FAILURE LLO MH_TM_OUT MTCE_BSY NO_DIAL NO_SEIZURE_ACK NU

Dual Seizure of a trunk. Facility Not Implemented. Faulty circuit. Diversion not possible. Feature cancelled. Feature InteractionFeature Invocation. Forward Signalling Absent. Inter Digit Time Out. Invalid Invocation. Invalid Signalling. Wrong Prefix Digit. Junction Faulty. Killer trunks level 2 Killer trunks level 1 Line signal failure. This could be due to loopback removal. Line Locked Out. Manual Hold Timeout. Subscriber Maintenance Busy. No digits dialled. No seizure ack received. Called Number Unobtainable.

- 41 -

56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73.

OG_RSTRCTN OVERLOAD PART_DL REMOTE_CONGN RING_OUT ROUT_OUT_ORDR ROUT_RECNT_CHGNG RSRC_N_ALCTD RSRC_N_AVAIL SGN_FAILURE SPURIOUS_ANS SS_BLOCKING ST_COND SUCC_CALL SWTCH_BLOCKING SYS_REC TO_N_PSBL XCHG_INVC

Outgoing Restriction. Call failure due to overload detection. Partial Dialling Remote Congestion. Ring Time Out. Route out of order. Route Recently changed.

Resource Not Allocated-Shortage of service circuits.. Resource Not Available. Signalling Failure. Spurious ans received on the trunk. Space Switch Blocking. End of dialling received. Successful Call. switching Blocking. System Recovery. Trunk Offer Not Possible. Exchange Invocation.

- 42 -

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.

- 43 -

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 MBM-L No. of BMS Upto 5 No. of Routes under Obs. Upto 50 51 to 80 81 t0 90 91 to 100 101 to 110 Upto 8 Upto 30 31 to 40 44 to 45 46 to 50 51 to 54 Up to 12 Upto 15 16 to 25 26 to 30 31 to 35 13 to 16 Upto 15 16 to 21 - 44 Max. No. of TGPs under Obs. 40 35 30 10 0 40 35 30 10 0 40 30 10 0 40 30

Configuration MBM-XL

No. of BMS Upto 24

No. of Routes under Obs. 22 to 27 Upto 24 25 to 27 28 to 30

Max. No. of TGPs under Obs. 0 40 10 0 40 10

25 to 32

Upto 18 19 to 21

- 45 -

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 a & gnd 1 2 3 4 5 6 7 20.0 20.0 20.0 20.0 20.0 20.0 20.0 b & gnd 20.0 20.0 20.0 20.0 20.0 20.0 20.0 a&b 20.0 20.0 20.0 20.0 20.0 20.0 20.0 Insulation Resistance (High) in kohms a & gnd 20000 20000 20000 20000 20000 20000 20000 b & gnd 20000 20000 20000 20000 20000 20000 20000 a&b 20000 20000 20000 20000 20000 20000 20000 Contd..
- 46 -

Category

Capacitance (micro farade) LOW HIGH 3.0 3.0 3.0 3.0 4.0 4.0 8.0

Loop Current (milli Amps) LOW 20.0 15.0 20.0 15.0 15.0 13.0 20.0 HIGH 36.0 36.0 36.0 36.0 36.0 36.0 36.0

Loop Resistance (ohms) LOW 100.0 100.0 75.0 75.0 100.0 100.0 100.0 HIGH 2400 3200 2400 3200 3200 3600 2400

1 2 3 4 5 6 7 Note :

1.5 0.15 1.5 0.15 1.5 0.15 1.5

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 5th closing low 5th opening high 5th opening low Dial Ratio high Dial Ratio low Dial Speed high Dial Speed low 60 msec 16 msec 100 msec 42 msec 4 1 12 IPS 8 IPS
- 47 -

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.

- 48 -

Annexure - XI

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

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

X-1

X-2
N-M

X-3

X-4

X-5

N-N S-A

S-B N-L N-K

X-8

X-7

X-6

S-C

S-D

- 49 -

Type Of Exchange X-1 X-2 X-3 X-4 X-5 X-6 X-7 X-8 Local Terminal Exchange Transit Exchange may be ILT Leading TAX Transit TAX Terminating TAX Transit Exchange may be ILT Terminal Exchange Terminal Exchange parented to working in Multi Exchange mode TAX/ILT

XCHG-TYPE 2 2 4 4 4 2/4 2 2

Network node

Type of node

TGPTYPE ORD ORD ORD TTAX ORD ORD ORD

- 50 -

MTR-TYP (FOR TAX CALLS) PRD-TAX PRD-TAX PRD-LCL

MTR-TYP ( FOR NON-TAX CALLS) PRD-LCL NO-MTR NO-MTR NO-MTR NO-MTR -

N-A N-B N-M N-C N-D N-N N-E

O/G TGP of X-1 I/C TGP of X-2 O/G TGP of X-2 towards group exchange O/G TGP of X-2 towards TAX Network I/C TGP of X-3 I/C TGP of X-8 O/G TGP of X-3

N-F N-G N-H N-I N-J N-K N-L

I/C TGP of X-4 O/G TGP of X-4 I/C TGP of X-5 O/G TGP of X-5 I/C TGP of X-6 O/G TGP of X-7 I/C TGP of X-7

TTAX ORD TTAX ORD TTAX ORD TTAX

NO-MTR NO-MTR NO-MTR -

NO-MTR NO-MTR NO-MTR NO-MTR

S-A S-B S-C S-D

Subscriber at X-1 Subscriber at X-2 Subscriber at X-8 Subscriber at X-7

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

- 51 -

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 NUM-ANI=10 For Sending Area Code along with CLI (Say Area Code = 02345) ARCD-DGT1 ARCD-DGT2 ARCD-DGT3 ARCD-DGT4 ARCD-DGT5 = 10 =2 =3 =4 =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. CLI without '0' will be sent across network. At terminating Exchange, 'CLI on sub's Monitor will be presented without '0'

C.

In MOD-R2 Signalling

- 52 -