1

Request for Proposal

For

GSM/ HSPA Network

For deployment in MTML Mauritius

Requested by: Mahanagar Telephone (Mauritius) Ltd.

(A subsidiary of Mahanagar Telephone Nigam Ltd-A Govt. of India Enterprise )

MTML Tower, 30, Dr Eugene Laurent St, Port Louis

Mauritius Phone(230)-2943333, FAX(230)-2940606, Email: mtmltd@intnet.mu

2

RFP No.:MTML/ GSM/ RFP/ 1 Dated 14.10.2009

TENDER DOCUMENT

Ref: Global Tender Notice No. MTML/GSM/ RFP/1 dated 14.10.2009 for procurement

of 200,000 GSM/ HSPA Equipment (in 2 phases) based on 2G & 3G Technology in MTML Mauritius on turn key basis.

Please find enclosed the following bid documents to be used for submission of the bid.

S.No. Title Section Page No. 1. Notice Inviting Tender (NIT) I 3 2. Instructions to bidders II 5 3. General (commercial) conditions of contract III 19 4. (a) Special Conditions of Contract IV-A 30 4. (b) Detailed Technical Requirements IV-B 41 5. Schedule of Requirements V 191 6. Delivery Schedule VI 199 7. Price Schedule for Equipments VIII Table I 200 8. Price Schedule for Services VIII Table II 200 9. Price Schedule for AMC VIII Table III 201 10. List/ price of Spares VIII Table IV 201 11. Bid Security Form Annex-I 202 12. Performance Security Guarantee Bond Annex-II 203 13. Letter of Authorisation for attending Bid

Opening Annex-III 204

14. Manufacturer’s Authorization Form Annex-IV 205

15. AMC Terms & Conditions Annex-V 206

16. Existing Network information Annex-VI 209

Your offer complete in all respects as per enclosed documents must reach latest by 15.00 Hrs. of 16.11.2009 at the following address:

Chief Technical Officer Mahanagar Telephone (Mauritius) Limited,

‘MTML Tower’, 30, Eugene Laurent Str, Port Louis Mauritius The “Instructions to Bidder” and “General (Commercial) conditions” are applicable for this Tender. However, the clauses mentioned in the “Special Conditions of Contract” & “Technical Specifications” will supersede the General (Commercial) Conditions.

Tender bids shall be opened at 15.30 Hrs.on 16.11.2009. The representatives of the bidders who wish to be present during tender opening may kindly make it convenient to attend the same. Thanking you,

Yours faithfully,

RAJESH RAI

CTO MTML

3

SECTION-1

GLOBAL NOTICE INVITING TENDER

Tender Enquiry No. & Date : MTML/GSM / RFP/1 Dated 14.10.2009

Sale of tender document : 14.10.2009

Closing date of sale of tender document

: 04.11.2009

Last date for seeking clarifications : Up to 17:00 Hrs on 05.11.2009

Last date for issuing clarifications : 07.11.2009 Last Date of Submission : Up to 15:00 Hrs on 16.11.2009

Date of opening : At 15:30 Hrs on 16.11.2009

-- All timings given above are Mauritius Local time. 1. MTML intends to call for global open tender for 200,000 lines of GSM/ 3G (HSPA)

network in two phases in Mauritius as per details below:

Subscriber base

2G Plus

3G Total Remarks

Phase-I 100,000 - 100,000

Phase-II 50,000 50,000 100,000 Ordering may be done in any proportion as per requirement envisaged at that time.

Total 150,000 50,000 200,000

2. ELIGIBILITY REQUIREMENT FOR VENDORS:

Please see Clause 3 of section II of RFP.

3. SCOPE:

(i) The two stage tender calls for 200,000 lines GSM/3G (HSPA) network of MTML on turnkey basis in entire service area in Mauritius in two phases.

(ii) The scope of the tender includes planning, engineering, supply, Installation, testing and commissioning of the entire 2G network of GSM phase 2+ (latest version) and 3G network of Release 5 WCDMA technology and higher version.

(iii) The scope also includes planning, engineering, supply, Installation, testing and commissioning of other associated network elem ents such as IN, SMSC, MMS, Value added services, Battery, Power Plant, towers, shelters, air conditioning, antennas etc. The core network so provided has to be common for both – the planned GSM and existing CDMA network (of 110k lines provided by M/s Huawei Tech.). The scope includes replacing/ upgrading/ integrating the existing CDMA core network elements (MSC, HLR, IN, SMSC, VMS etc) and Billing & Customer Care System, with the proposed GSM/3G core network elements so that only one common core network & billing system for both GSM & CDMA is there.

4

(iv) While planning the above network, the existing network elements viz. Huawei make CDMA MSC, HLR, IN, BSS elements and infrastructure, Packet core network (PDSN), Billing and customer care system, VMS, SMS etc. in the present CDMA network , ZTE make EVDO Rev A network and NEC Microwave equipments installed in MTML should be taken into account for the best utilization of the existing infrastructure and interworking of the equipm ent procured against this tender with the existing equipment, wherever technically feasible

(v) The 200,000 capacity will be taken in two phases of 100,000 each. However, the evaluation will be on the entire scope of phase I and II and the detailed network design also should be submitted for the entire scope, to be implemented in two phases.

For details regarding equipment, technical requirements & special conditions/requirements please refer to RFP. Bid security in the form of bank guarantee will be USD 40,000 (Forty Thousand Dollors only). Intending Bidders may download the document from MTML W eb site www.mtmltd.net or collect the same from CFO MTML, Port Louis, Mauritius from 14.10.2009 to 04.11.2009 on all working days on payment of USD 1000/- (USD One thousand only) non-refundable crossed demand draft/ TT in favour of MTML Mauritius. Bidders who have downloaded the tender document shall have to submit non-refundable crossed demand draft/ TT in favour of MTML for USD 1000/- along with their bids. In case of failure to submit the same, the bid will not be accepted.

Sd /- (Rajesh Rai) CTO MTML

5

SECTION - II

INSTRUCTIONS TO BIDDERS A. 1. INTRODUCTION Mahanagar Telephone (Mauritius) Ltd (MTML) intends to call for global open tender for 2G /3G GSM /HSPA network supply, installation and commissioning on turnkey basis for 200,000 lines in Mauritus in two phases as per details given below: Subscriber base

2G Plus 3G Total Remarks

Phase-I 100,000 - 100,000

Phase-II 50,000 50,000 100,000 Ordering may be done in any proportion as per requirement envisaged at that time

Total 150,000 50,000 200,000

INSTRUCTIONS TO PARTICIPANTS 1. Introduction

Mahanagar Telephone (Mauritius) Ltd. (hereinafter referred to as “Purchaser”) invites offers for implementation on turn-key basis to carry out survey, design, planning, engineering, supply, installation, testing, commissioning of the goods, materials, services and equipment (such goods, material, services and equipment hereinafter referred to as ‘Goods’) as described in Schedule of Requirements, Section-V, at Mauritius and making over the system to the Purchaser. Subsequent warranty support and AMC (Annual Maintenance Contract) after warranty period shall also come within the scope of this RFP.

2. Definitions a) “The Purchaser” means the Mahanagar Telephone (Mauritius) Ltd(MTML). b) “The Vendor” means the individual or company who / which participates in

this RFP and submits his / its offer. c) “The Proposal” or “The Offer” means the offer submitted by the Vendor in

response to the RFP. d) “The Goods” mean all the equipment, machinery and other materials which

the Vendor is required to supply/provide to the Purchaser under the contract for commissioning/proper operation of the system and also includes any spares for the equipment.

e) “Letter of Intent (LOI)” means letter indicating the intention of the Purchaser to place Purchase Order on the successful Vendor.

f) “The Purchase Order” means the order placed by the Purchaser on the Contractor duly signed by the Purchaser and includes all attachments and appendices thereto and all documents incorporated by reference therein. The purchase order shall be deemed to be the contract, which is defined below.

g) “Contract” means the agreement between the Purchaser and the successful Vendor

6

h) “The Contractor” means the successful Vendor with whom Purchaser has entered in to contract for the execution of the works including supply of all documents to which reference may be made in order to ascertain the rights and obligations of the parties and shall include the Instructions to Participants, General Conditions of Contract, Special Conditions of Contract, Addenda, Supplementary Agreement(s) (if any) as part of the Contract.

i) “The Contract Price” means the price payable to the Contractor under the purchase order for the complete fulfillment and proper performance of its contractual obligations to the satisfaction of the Purchaser.

j) “Contract Date” means the date on which the Contract comes into effect. k) “Certificate of Acceptance” means the certificate issued by the Purchaser to

the Contractor upon completion of the acceptance tests of the Equipment/W orks.

l) “Progress Report” means the reports prepared by the Contractor containing details of the progress and implementation of the project as required by the Purchaser.

m) “Site” means the place(s) other than the Contractor’s premises, to which the Equipment(s) and System(s) are to be delivered and installed.

n) “Variation Orders” means a written agreement entered between the parties varying the items mentioned in the Schedule of Prices.

o) “W orks” means the jobs undertaken by the Contractor in order to complete the tasks falling within the scope of the Contract.

p) “Commissioning” means successful completion of acceptance testing procedures as may be prescribed by the Purchaser and three months of successful trial operation i.e. stabilization period, thereafter.

q) “Testing” is a process of testing the equipments & services as per the Requirements as spelt out in various sections of the RFP.

3. Vendors Eligibility Criteria

(I) The Vendor should be registered for manufacturing the tendered item(s) OR a registeredTelecom Company, duly authorised by the original manufacturer of the tendered item(s), to submit the offer on their behalf and having Memorandum of Understanding (MOU) with the original manufacturer for supply, installation, commissioning, warranty and Annual maintenance Contract(AMC) of the tendered item(s) & equipment during the contract period. The registration certificate, proof of manufacturing the requested items(s) OR registration to manufacture telecom equipment in the country of manufacturing, authorisation by the manufacturer to submit the offer against this RFP and MOU shall form part of the Offer.

II (i) GSM experience.

(a) The bidder or their parent company or the OEM must posses experience in supply, installation and commissioning of at least a total of 2 million lines of GSM 900 and/or GSM 1800 network equipment including B&CCS, IN, GPRS or EDGE in not less than 2 countries.

(b) Out of above mentioned 2 million lines, the bidder or their parent company or the OEM should also have supplied, installed and commissioned at least one GSM network including IN & BCCS of not less than 1 million lines and working satisfactory for a minimum period of 2 years at the time of NIT.

II (ii) WCDMA Experience

7

(a) The bidder or their parent company should have supplied, installed & commissioned a minimum of 200 Node Bs of UTRAN of R5 version or higher. These 200 node Bs should be from not more than two networks and should be other than the country of origin.

(b) The bidder or their parent company should have at least one WCDMA network of 3GPP R5 or higher version in a country other than the country of origin. This network should have been commercially operational for at least one year as on the date of NIT. The bidder or parent company should have successfully completed IOT test of their NSS/ UTRAN with at least two other vendors.

III The bidder shall submit references in the form of a certificate with company seal from the network operator signed by the senior official of the company (including name, designation, telephone number, fax numbers and e-mail id of the signatory and that of the company) of all such existing networks in operation. References shall be considered valid provided the networks mentioned thereof are existing and are in operation for the period as mentioned above. References shall also mention performance of network equipment supplied and installed.

IV Bidder shall give an undertaking for network elements to support both 2G & 3G technologies for next 7 years with a product portfolio & roadmap till 3GPP R7.

V The bidder should submit an undertaking to set up necessary infrastructure in Mauritius for project implementation, O&M support and annual maintenance contract within 3 months of issue of LoI.

VI The bidder should have a minimum turnover of USD 100 million each in the last two years

(i.e. 2006-07 & 2007-08).The turnover of the parent company in case of a local subsidiary would be taken into consideration.

4. Cost of Participation in RFP

The Vendor shall bear all costs associated with the preparation and submission of the offer against this RFP. The Purchaser, will in no case, be responsible or liable for these costs, regardless of the conduct or outcome of the RFP process.

5. RFP Documents 5.1 The goods and services required, RFP procedure and contract terms are

prescribed in the RFP Document. The RFP document include the following:

S.No. Title Section 1. Notice Inviting Tender (NIT) I 2. Instructions to bidders II 3. General (commercial) conditions of contract III 4. (a) Special Conditions of Contract IV-A 4. (b) Detailed Technical Requirements IV-B 5. Schedule of Requirements V 6. Delivery Schedule VI 7. Price Schedule for Equipments VIII Table I 8. Price Schedule for Services VIII Table II

8

9. Price Schedule for AMC VIII Table III 10. List/ price of Spares VIII Table IV 11. Bid Security Form Annex-I 12. Performance Security Guarantee Bond Annex-II 13. Letter of Authorisation for attending Bid Opening Annex-III

14. Manufacturer’s Authorization Form Annex-IV

15. AMC Terms & Conditions Annex-V

16. Existing Network information Annex-VI

5.2 The Vendor is expected to examine all instructions, forms, terms and

specifications in the RFP Documents. Failure to furnish all information required as per the RFP Documents or submission of offers, which are not substantially responsive to the RFP Documents in every respect, may result in rejection of the offer.

In respect of interpretation/clarification of each and every clause of this RFP and in respect of any matter relating to this RFP, the decision of CEO,MTML will be final.

6 Clarifications to RFP 6.1 A prospective Vendor, requiring any clarification of the RFP may request the

Purchaser in writing at the Purchaser’s mailing address indicated in the Clause 6.2 below. The Purchaser may, but shall not be obliged to, respond in writing to any request for clarification of the RFP, which is received within the time frame as specified in Section-I of the RFP. Copies of the queries (without identifying the source) and clarifications by the Purchaser may be sent to all the prospective Vendors who have purchased the RFP documents.

6.2 Address for communication: Chief Executive Officer, Mahanagar Telephone

(Mauritius) Ltd, 30 Dr Eugene Laurent Str, Port Louis, Mauritius. Fax No. (230) -2940606.

7 Amendment to RFP Document 7.1 At any time, prior to the scheduled date for submission of offers, the Purchaser

may for any reason, whether at its own initiative or in response to a clarification requested by a prospective Vendors, modify/alter any terms & conditions of the RFP by amendments as long as they are uniformly applied to all.

7.2 The amendments shall be notified in writing to all prospective Vendors who had

purchased the RFP and these amendments will be binding on them. For this reason, prospective Vendors purchasing the RFP shall provide the Purchaser with their contact details, failing which the Purchaser shall be under no obligation to notify them of any amendment under this clause.

9

7.3 In order to give prospective Vendors reasonable time to take the amendments into account while preparing their offers or for any other reason, the Purchaser may, at its discretion, extend the last date / time for the submission of offers suitably.

7.4 Vendors who have downloaded the tender forms from the web-site are required

to take the amendments issued from time to time from the Purchaser’s web site www.mtmltd.net .

8 Preparation of the Offers 8.1 Language of Offer

The offer prepared by the Vendor and all correspondence and documents relating to the offer exchanged by the Vendor and the Purchaser shall be written in English language, provided that any printed literature furnished by the Vendor may be written in another language but it is to be accompanied by an English translation of its pertinent passage(s) duly signed and verified as true English translation. The responsibility for the correctness of the translation will be solely and completely on the Vendor and the Purchaser shall not be responsible for any loss/likely loss due to error in translation whatsoever. In such cases, for the purpose of interpretation of the offer, the English translation shall only govern.

8.2 Documents comprising the Offer The offer prepared by the Vendor shall comprise the following documents:

a) Authorization to the person signing the offer.

b) Documents supporting Vendors eligibility to submit offers as per the eligibility conditions given in Clause 3 above.

c) Bid Security in format as per Annexure. d) A Clause by Clause compliance of the goods/services offered with the

various terms & conditions spelt out in the sections II, III, IV, V and VI of this RFP, along with a separate annexure containing summary of clauses/specifications not being complied giving detailed reasons. “Compliant” shall be written against the clauses where the offer meets the RFP requirements fully. “Non Compliant” shall be written against the clauses where the offer does not meet the RFP requirements fully. In case of unclear/ ambiguous statements of compliance for any specified requirement e.g. “Noted & Understood”, “Noted” etc. shall be taken as “Non Compliant”. Mere “Compliant” shall also not be sufficient. Reference to the enclosed documents showing compliances must be given. An offer without clause-by clause compliance shall not be considered.

e) A copy of price schedule with all relevant tables incorporating all items

without prices. This is to be enclosed with techno-commercial offer and shall constitute bill of material.

10

f) A certificate that all the pages (printed, typed, literature etc.) in the original copy of the offer document have been signed and sequentially numbered, indicating total number of pages in the offer.

g) Documentary evidence of the goods and services in conformity to the RFP document may be in the form of literature, drawings and data. It may comprise of:

A detailed description of the goods with essential technical and

performance characteristics and sketches, drawings and circuit diagram, physical and technical parameters for all equipments offered including constituent of set of maintenance spares.

Detailed project implementation schedule covering all the activities of the work and Bar/Pert Chart.

The Vendor shall note that the standards for the workmanship, material and equipment and reference to the brand names or catalogue number, designated by the Purchaser in its Technical specifications are intended to be descriptive only and not restrictive.

9. Currencies

The prices shall be quoted in US DOLLAR ONLY as provided in Price Schedule (Section-VII).

10. Prices 10.1 The prices quoted shall be CIF at Mauritius and shall be in US DOLLAR for all

items as per the schedule of requirement (Section-V) and other items, if any, strictly in appropriate price schedule tables attached to these documents as per Section VII. The Purchaser shall be responsible for paying all the duties/ levies on equipment & software within Mauritius and the duties/ levies outside Mauritius shall be responsibility of the Vendor.

10.2 Vendors shall quote itemized basic price for each item of equipment. These

may be consolidated as indicated in Price Schedule in Section VII. Separate Annexure giving the detailed quantity and break-up of prices shall be provided in support of the consolidated prices arrived in each table of Price Schedule. The formats are strictly to be complied with while quoting.

10.3 The prices quoted by the Vendor shall remain fixed during the entire period of

contract and shall not be subject to variation on any account. An offer submitted with an adjustable price quotation will be treated as non-responsive and rejected.

10.4 The unit prices quoted by the Vendor shall be in sufficient detail to enable the

Purchaser to arrive at prices of equipment/system as offered. 10.5 ‘DISCOUNT’, if any, offered by the Vendor shall not be considered

unless they are specifically indicated in the price schedule. Vendor desiring to offer discount, should therefore, quote clearly net price taking all such factors like Discount, free supply, etc. into account.

11

10.6 The quoted price shall be all-inclusive and payment of income tax/any other

taxes by recipient of payments under this clause shall not be the responsibility of the Purchaser either at the time of supply of equipment or at any time thereafter.

10.7 It shall be mandatory for the Vendors to undertake the work of Annual

maintenance contract (AMC) as detailed in Annexure. 11. Bid Security 11.1 The bid security is required to protect the Purchaser against the risk of

Vendor’s conduct, which would warrant the forfeiture of the security. 11.2 The bid security of US $ 40,000 (US Dollar Fourty thousand only), valid for

180 days shall be submitted in one of the following forms:

a) A Bank Guarantee as per enclosed Proforma at Annexure-I issued by a First Class Commercial Bank in Mauritius in favour of the Purchaser.

b) Demand draft in favour of Mahanagar Telephone (Mauritius) Ltd payable at Mauritius.

11.3 In case the security is submitted in the form of a Demand draft, the Purchaser

will be entitled to encash the same. In the case of return of the bid security, the Vendor shall not be entitled to claim any interests thereon from the Purchaser.

11.4 An offer without bid security of required amount & validity shall not be

considered further. 11.5 The bid security of the unsuccessful Vendor will be returned as promptly as

possible and in any event not later than 45 days after the placement of firm Purchase Order by the Purchaser or on expiry of the offer validity whichever is earlier.

11.6 The successful Vendor’s bid security will be discharged upon the Vendor’s

acceptance of the Letter of Intent (LOI) and furnishing the performance security as per Clause 4 of Section III.

11.7 The bid security may be forfeited:

a) If a Vendor withdraws his offer during the period of validity of the offer or

b) In the case of a successful Vendor, if the Vendor fails to furnish performance security in accordance with clause 28.

12. Period of Validity of Offers 12.1 Offer shall remain valid for 180 days after the date of opening prescribed by

the Purchaser. The Purchaser shall reject offers valid for a shorter period, as non-responsive.

12

12.2 In exceptional circumstances, the Purchaser may request the Vendor’s consent for an extension to the period of offer validity. The requests and responses thereto shall be made in writing. The bid security provided under clause 11 shall also be suitably extended. A Vendor may refuse the request without forfeiting his bid security. A Vendor accepting the request and granting the extension, will not be permitted to modify his offer.

13. Format and Signing of Offers 13.1 The Vendor shall prepare Two copies of his offer, clearly marking one as

‘Original Offer’ and the other as copy. In the event of any discrepancy between them the ‘Original Offer’ shall govern/prevail.

13.2 The original and copy of the Offer shall be typed or printed, numbered

sequentially and shall be signed with date, by the Vendor or a person or persons duly authorized to bind the Vendor to the contract. The letter of authorization shall be indicated by written power-of-attorney accompanying the offer. The offer submitted shall be sealed properly.

13.3 The offer shall contain no interlineations, erasures or overwriting except as

necessary to correct errors made by the Vendor in which case such corrections shall be initialed by the person or persons signing the offer with date.

14. Procedure for Submission of Offers 14.1 Offers along with documents as indicated in clause 8.2 shall be submitted in

the following manner in separately sealed envelopes duly super scribed as below: -

Part ‘A” - Techno-Commercial Offer Part “B” - Financial Offer 14.2 Part “A” shall contain, in one envelope, one original and a copy of Techno

Commercial Offer complete with all technical and commercial details along with unpriced bill of material i.e. copy of the price schedule without mention of prices.

THE ORIGINAL BID SECURITY OF REQUISITE VALUE MUST BE

ENCLOSED IN A SEPARATE COVER WHICH WILL BE OPENED FIRST. 14.3 Part “B” (Financial Offer) shall contain in, in one envelope, one original and a

copy super scribing on the sealed envelope “Financial Offer”. 14.4 At least original Copy of ‘Techno-Commercial Offer’ and ‘Financial Offer’

should be signed by the Vendor on each page. 15 Sealing and Markings of Offers 15.1 The Vendor shall seal the original and each copy of the offer in an envelope

duly marking the envelopes as ‘Original’ and ‘copy’. Unsealed offers will not be accepted. Unsealed offers will neither be opened nor evaluated. The seal should be the official seal of Vendors.

13

15.2 The envelopes shall

(a) be addressed and sent at the following address: Chief Executive Officer Mahanagar Telephone (Mauritius) Ltd., 30, Dr Eugene Laurent Str Port Louis Mauritius

(b) bear Name of works “GSM/ 3G Infrastructure for deployment in

Republic of Mauritius”, the RFP No. and the words “DO NOT OPEN BEFORE (date and time of opening of offers as indicated in RFP)”

15.3 In addition to above, the envelopes shall indicate the name and address of

the Vendor to enable the offer to be returned unopened in case it is received ‘Late’.

15.4 Outstation offers shall either be sent by registered post or delivered in

person. The responsibility for ensuring that outstation offers are delivered in time would vest with the Vendor.

16. Deadline for Submission of Offers 16.1 Offers must be received by the Purchaser at the address specified under

clause 15.2 and not later than the date & time mentioned in section I. 17. Late Offers

Any offer received by the Purchaser after the prescribed time for submission of the offer as per Clause 16, shall be rejected and returned unopened to the Vendor.

18. Modifications and Withdrawal of Offers 18.1 The Vendor may modify or withdraw his offer after submission provided that

written notice of the modification or withdrawal is received by the Purchaser prior to the deadline prescribed for submission of offers.

18.2 The Vendor’s modification or withdrawal notice shall be prepared, sealed,

marked and dispatched as required in the case of offer submission in accordance with the provision of clause 13. A withdrawal notice may also be sent by FAX but shall be followed by a signed confirmation copy, post marked not later than the deadline for submission of offers.

18.3 No offer shall be modified subsequent to the deadline for submission of offers. 19. Opening of Offers/ Proposals 19.1 The Purchaser will open Techno-Commercial Offers, in the presence of

authorised representatives of Vendors who choose to attend, at the date and time specified in Notice Inviting Proposals. The Vendors’ representatives,

14

who are present, shall sign an attendance register. Authority letter to this effect shall be submitted by the Vendor/representative before they are allowed to attend the opening. Techno Commercial offers shall be opened first and Financial offers of only technically and commercially eligible Vendors shall be opened subsequently. In the event that the specified date of opening of offers is declared a holiday by the Purchaser, offer opening shall take place on the next working day, time and venue remaining unaltered. Similar would be in the case of last date for submission of the offers.

19.2 Subject to the requirements contained in Clause 19.1 above, a maximum of

two representatives for any Vendor shall be authorized and permitted to attend the opening.

20. Clarifications from Vendors

To assist in the examination, evaluation and comparison of offers, the Purchaser may, at its discretion, ask the Vendor for any clarification(s) of its offer. The request for clarification and the response shall be in writing and no change in the price substance of the offer shall be sought, offered or permitted.

21. Evaluation of Techno-Commercial Offers

21.1 During the technical-commercial evaluation, Purchaser at its discretion may

call upon the Vendors to give presentation on their offer, to explain their capability to undertake the project and to respond to any question from Purchaser.

21.2 The Purchaser will determine the substantial responsiveness of each offer to

the RFP conditions. A substantially responsive offer is one, which conforms to all the terms and conditions of RFP Documents without material deviation. The Purchaser shall, at its entire discretion, determine what constitutes a “material deviation” and its decision thereon shall be final and conclusive.

21.3 An offer determined as not substantially responsive will be rejected by

the Purchaser and may not subsequently be made responsive by the Vendor by correction of the non-conformity.

21.4 Further examination of only such offers determined to be substantially

responsive will be taken up and Techno-Commercial clarifications/discussions, if considered necessary, obtained/held with such Vendors to determine the acceptability of the offers.

22. Evaluation of Financial Offers

22.1 The financial offers of the technically and commercially acceptable Vendors

will be opened in the presence of Vendor’s authorized representative(s) who choose to attend on the date and time of opening of financial offers. The financial bids of those bidders who are not technically acceptable, would be returned to them unopened.

22.2 Evaluation of the financial offers and ranking of the Vendors shall be based on

15

the following criteria:

The Net Present Value (NPV) of CIF prices of the equipment & software quoted by the Vendor for two phases shall be arrived at by discounting the phase II prices @ 12% and adding it to the phase I price. Any discount which has been indicated by the Vendor in their price quotes and calculations will be suitably factored in by the Purchaser while arriving at the final price. Cost of AMC for a period of three years calculated to present value at a discount rate of 12% per annum for evaluation. Cost of Spares to be handed over at the end of three year AMC period shall be discounted @12% per annum as per clause 6 of AMC. Purchaser has the right to negotiate the prices with the overall lowest quote Vendor on total quoted package price and make counter offer on the prices quoted. The negotiations would be on total package price and/ or itemized prices.

Note: Arithmetic errors will be rectified on the following basis. If there is a

discrepancy between the unit price and the total price that is obtained by multiplying the unit price and quantity, the unit price shall prevail and total price will be corrected. If there is a discrepancy between the total offer amount and the sum of total prices, the sum of total prices shall prevail and the total offer amount will be corrected. If anywhere, prices are quoted in figures and words and if there were discrepancy between the two, words would prevail. Vendors shall accordingly be bound by the terms of their respective offers corrected in accordance with this paragraph.

23. Contacting the Purchaser 23.1 Subject to Clause 18, no Vendor shall try to influence the Purchaser on any

matter relating to its offer, from the time of the offer opening till the time the contract is awarded.

23.2 Any effort by a Vendor to influence the Purchaser in the Offer

Evaluation, comparison or contract award decisions may result in the rejection of his offer.

23.3 The Purchaser shall in its entire discretion decide on what constitutes

“influence” under this Clause and its decision thereon shall be final and conclusive.

24. Award of Contract

The Purchaser may consider award of contract for commercial supplies on that Vendor whose offer has been found technically, commercially and financially acceptable.

25. Award Criterion

Subject to Clause 27 below, the Purchaser may award the contract to successful Vendor whose offer has been determined to be substantially responsive, technically and commercially acceptable and has been

16

determined as the lowest evaluated price offer provided further that Vendor is determined by the Purchaser to be fully qualified to perform the contract satisfactorily.

26. Purchaser’s Right to Vary quantities 26.1 The Purchaser reserves the right to increase or decrease up to 25% of the

quantity of goods and services specified in the schedule of requirements, without any change in the unit prices and other terms and conditions as applicable at the time of award of contract, at its entire discretion.

26.2 In exceptional situation where the requirement is of an emergent nature and it

is necessary to ensure continued supplies from the existing Contractors, the Purchaser reserves the right to place repeat order up to 50% of the quantities of goods and services contained in the running contract within a period of twelve months from the date of purchase order, at the same rate or a rate negotiated (downwardly) with the existing Contractors considering the reasonability of rates based on prevailing market conditions.

27. Purchaser’s Right to Accept any Offer and to Reject any or all Offers: 27.1 The Purchaser reserves the right to accept or reject any offer, and to annul

the RFP process and reject all offers, at any time prior to award of contract without assigning any reasons whatsoever and without thereby incurring any liability to the affected Vendor(s) on the grounds of the Purchaser’s action.

27.2 Purchaser reserves the right to disqualify such Vendor(s) who have a poor

track record of not meeting the contractual obligations, against earlier contracts either entered into directly with the Purchaser, its subsidiary/principals/joint venture companies or acquired as a result of the vendor(s) acquiring interest in other companies.

28. Notification of Award (Issue Of Letter Of Intent) 28.1 Prior to the expiry of the period of offer validity, the Purchaser will notify the

successful Vendor in writing through a Letter of Intent (LoI) by Registered letter or FAX which will be confirmed in writing by Registered letter.

28.2 Upon the successful Vendor furnishing the Performance Bank Guarantee

pursuant to Clause 4 of General Conditions of Contract (Section-III) and unconditional/unequivocal acceptance of the LOI, the Purchase Order shall be issued.

28.3 The issue of purchase order on the receipt of unconditional acceptance of LOI

along with the performance security shall constitute the award of the contract on the Vendor.

28.4 The Purchaser will promptly discharge the bid security to each unsuccessful

Vendor. 29. Signing Of Contract

17

29.1 The issue of Purchase order shall constitute the award of contract on the

Vendor. 29.2 Upon the Vendor furnishing the Performance Bank Guarantee, the

Purchaser shall discharge its bid security. 30. Annulment of Letter of Intent:

Failure of the successful Vendor to comply with the requirement of clause 28.2 above shall constitute sufficient ground for the annulment of the acceptance of the offer and forfeiture of the bid security in which event the Purchaser may make the offer to any other Vendor at its discretion or call for new RFP. The annulment may be effected by the Purchaser without recourse to a Court of law and the Vendor shall not be entitled to make any claim whatsoever against the Purchaser on an annulment properly effected under this Clause.

31. Quality Assurance (QA) Requirements The Contractor shall have a Quality Management System supported and evidenced by the following: - A Quality Policy. - A management representative with authority and responsibility for fulfilling

QA requirements and for interfacing with Purchaser in matters of Quality. - Procedure for controlling design/production engineering, material, choice

of components/Vendors manufacturing and packaging process for supplying quality products.

- System of Inwards Goods Inspection. - System to calibrate and maintain required measuring and test equipment. - System for tracing the cause for non-conformance(traceability) and

segregating products which do not conform to specifications. - Configuration management and change-control mechanism. - A Quality Plan for the product. - Periodical internal quality audits.

32. Outright Rejection of the Non-Compliant Offers While all the conditions specified in the RFP Documents are critical and are to be complied with, special attention of Vendor is invited to the following clauses of the RFP document, non-compliance of any one of which shall result in outright rejection of the offer. (i) Clause 15.1 of Section II-The offers will be recorded/returned

unopened, if covers are not properly sealed (ii) Clause 11.3 Section II-The offers will be rejected at opening stage if

bid security is not submitted as per Clasuse11.3 and offer validity is less than the prescribed in Clause 12.1 mentioned above.

(iii) Clause 3 Section II-If the eligibility condition as per clause 3, Section II is not met and/or the documents prescribed to establish the eligibility are not enclosed, the offers will be rejected without further evaluation.

18

(iv) Section-III “General Conditions of Contract” and Section-IV “Special Conditions of Contract” & Section-VI “Technical Section” compliance if given using ambiguous words like ‘Noted: Understood’, ‘Noted & Understood’ shall not be accepted as compliance. Mere ‘Complied’ will also not be sufficient. Reference to the enclosed document showing compliances must be given.

(v) Section-VII - Price Schedule: Prices are not filled in as prescribed in price schedule.

19

SECTION - III

GENERAL CONDITIONS OF CONTRACT 1. Application The General conditions shall apply in contracts made by the Purchaser for the

procurement of Goods. 2. Standards

The goods supplied under this contract shall confirm to the standards prescribed in the Technical Section of this RFP.

3. Patent Rights

The Vendor shall indemnify the Purchaser against all third-party claims/actions of infringement of patent, trademark or industrial design rights arising from use of the goods or any part thereof.

4. Performance Bank Guarantee 4.1 Within 15 days after the receipt of the LoI, the Vendor shall furnish

Performance Bank Guarantee (PBG) for the sum equal to 12% of the value of contract price. This guarantee shall be valid for a period of 2 years.

4.2 In the event, guarantee of full value has not been submitted within the

stipulated period, LoI will stand automatically cancelled without any further reference or notice unless time is extended in writing by CEO, MTML as the case may be pursuant to the request received from the Vendor prior to expiry of the period disclosing sufficient reasons for grant of further time.

4.3 The proceeds of the performance security shall be forfeited in favour of the

Purchaser as compensation for any loss resulting from the Contractor’s failure to complete its obligations under the contract.

4.4 The PBG shall be in the form of a bank guarantee issued by First Class

Commercial Bank in Mauritius and in the form provided in the RFP in Annexure-II.

4.5 The PBG will be discharged/released by the Purchaser after completion of the

Contractor’s performance obligations on the successful completion of warranty period, unless there are specific reasons, on record, for not to release the PBG.

5. Factory Inspection and Acceptance Tests 5.1 Factory Inspection 5.1.1 The Purchaser or his representative shall have the right to inspect and test

the goods for their conformity to the Specifications. The test schedule will be decided by Purchaser keeping in mind the facilities of testing & system design. W here the Purchaser decides to conduct such tests on the premises of the Contractor or its sub-contractor(s), all reasonable facilities and assistance like Testing Instruments and other test gadgets including access

20

to drawings and production data shall be furnished to the inspectors at no charge to the Purchaser. Number of personnel to be deputed for the purpose of inspection, testing etc. shall be decided by Purchaser and the costs such as air ticket, lodging and local transportation, daily allowances etc. shall borne by the Purchaser. Any other expenses relating to such inspection testing shall be borne by the Contractor.

5.1.2 Testing/inspection of equipment will be carried out after necessary mutual

discussions while taking into consideration the facilities of testing and system design.

5.1.3 The Contractor shall give a schedule of factory testing and acceptance testing

in field against specifications as indicated in Technical Section indicating the type of test and duration of test. It shall be the prerogative of Purchaser to decide on the final test schedule.

5.1.4 In case of retesting of equipment, on account of failure of the equipment

during the process of tests, the complete expense of retesting including the air ticket, lodging and local transportation, daily allowances etc. of the representatives of Purchaser, shall be borne by the Contractor and no extension of delivery schedule on this account shall be given to the Contractor without liquidated damages.

5.1.5 Should any inspected or tested goods fail to conform to the specifications, the

Purchaser may reject them and the Contractor shall either replace the rejected goods or made all alterations necessary to meet specification requirements free of cost to the Purchaser.

5.2 Acceptance Testing: Notwithstanding the pre-supply tests and inspections

prescribed in clause 5.1 above, the equipment and accessories, if any, on receipt in the Purchaser’s premises will also be tested during and after installation before “take over” and if any equipment or part thereof are found defective, the same shall be replaced free of all costs to the Purchaser as laid down in clause 5.3 below within such time so as not to delay the project commissioning.

5.3 If any equipment or any part thereof, before it is taken over, is found to be

defective or fails to fulfil the requirements of the contract, the Purchaser shall give notice to the Contractor setting forth details of such defects or failure and the Contractor, shall make the defective equipment good, or alter the same to make it comply with the requirements of the contract forthwith and in any case within a period not exceeding two weeks of the initial report. These replacements shall be made by the Contractor free of all charges at site. Should it fail to do so within this time, the Purchaser reserves the discretion to reject and replace at the cost of the Contractor, the whole or any portion of the equipment as the case may be. Also, any additional cost arising due to such delay shall be borne by the Contractor. This shall also include the cost of extra stay of inspection team etc. The cost of any replacement made by the Purchaser or additional cost referred above shall be deducted from the amount payable to the Contractor.

5.4 When all performance tests to the satisfaction of Purchaser are carried out as

per details in Clause 5.3 above and commissioning (Clause 2(p) of Section-

21

II), the Purchaser will issue a “Taking Over Certificate”. The Purchaser shall not delay the issue of any “Taking Over Certificate” contemplated by this clause on account of minor defects in the equipment, which do not materially affect the commercial use thereof provided that the Contractor shall undertake to make good the same in a time period not exceeding six weeks.

5.5 Nothing in this clause shall in any way release the Contractor from any

warranty or other obligations under this contract. 5.6 Inspection and testing shall be as per provisions in the Technical Section

(Section-VI) or as per details finalized between Contractor and Purchaser. 6. Delivery & Warehousing 6.2. The delivery of the equipment shall commence as specified and be completed

within time schedule specified in schedule of requirements and this along with completion of the turnkey project as per schedule shall be the essence of the contract.

6.2. The vendor will make his own arrangement for the storage of the goods at

Mauritius. He will transport the goods to the required Site as per the requirement of the turnkey project at his cost including transportation, handling charges etc.

6.3 The goods shall remain at the risk of the Contractor until completion of the

turnkey project i.e. issue of ‘Taking Over Certificate”. 7. Training 7.1 The Contractor shall provide training for 30 man weeks to personnel

(Technical and Finance) of the Purchaser, free of cost at the Contractor’s factory site. The training shall be thorough and effective so that the trainees shall get adequate knowledge of whole system including planning, installation, operation/ maintenance etc. of the various system & subsystems including Billing & Customer Care System and after training the trainees should be able to independently handle the installation operation and maintenance of the various system. The location of the training along with details of training to be conducted shall be indicated by the Contractor.

7.2 The travel expenses, boarding and lodging for the trainees shall be borne by

the Purchaser. 7.3 The Contractor shall also deliver 100 man-weeks of on job training to

personnel of the Purchaser in O&M of various systems & sub systems e.g. MSC, BSC, BTS, High Speed Data Network, IN Services, Billing & Customer Care System, OSS, RF Network design & Optimization, Microwave, various infrastructure items like battery, power plant etc.

7.4 The Contractor shall provide all training materials and documents and training

aids free of cost.

22

8 Warranty 8.1 The Contractor shall warrant that stores supplied shall be new and free from all

defects and faults in material, workmanship and manufacture and shall be of the highest grade and consistent with the established and generally accepted standards for materials of the type ordered and shall perform in full conformity with the specifications and drawings. The Contractor shall be responsible for any defects that may develop under the conditions provided by the Contractor and under proper use, arising from faulty materials, design or workmanship such as corrosion of the equipment, inadequate quality of material to meet equipment requirements, inadequate contact protection, deficiencies in circuit design and or otherwise and shall remedy such defects at his own cost when called upon to do so by the Purchaser who shall state in writing in what respect stores is faulty. The warranty shall survive inspection or payment for, and acceptance of goods, but shall expire except in respect of complaints notified prior to such date, one year after the equipments have been taken over under clause 5.4. W arranty shall also include replacement of faulty software.

8.2 If, it becomes necessary for the Contractor to replace or renew any defective

portion/portions of the equipment under this clause, the provisions of the clause shall apply to the portion/portions of equipment so replaced or renewed or until the end of the above mentioned warranty period. If any defect is not remedied within a reasonable time, the Purchaser may proceed to do the work at the Contractor’s risk and expenses, but without prejudice to any other rights, which the Purchaser may have against the Contractor in respect of such defects.

8.3 To meet the warranty obligations, the Contractor shall store requisite spares at

the Purchaser’s site. The turn around time for repairs of the faulty equipments shall be same as during the AMC period. The system availability shall be more than 99.99% during warranty period. The spares stocks shall be maintained by the contractor based on detailed MTBF of different components.

8.4 Replacement under warranty clause shall be made by the Contractor, free of all

charges at site, including freight, insurance and other incidental charges.

9 Spares 9.1 The Vendor shall quote his prices of complete equipment as per Price Schedule,

keeping in view the free supply of all spares for one year during warranty period. For this purpose, the Vendor shall submit a detailed list of these spares in the offer itself. These spares shall be supplied along with main equipment. A certificate to ensure that these spares shall be sufficient for system maintenance during the warranty period, shall have to be given by the Contractor and any additional spares, if required shall be supplied free of cost. The Purchaser shall have the right to use these spares during warranty period and these shall be stored at MTML Mauritius as per requirement.

9.2 (a) Vendor shall ensure the availability of these spares for at least 10

years after successful completion of warranty period.

(b) In the event of termination of production of the spare parts:

23

(i) Advance notification to the Purchaser of the pending termination

(not less than 2 years) in sufficient time to permit the Purchaser to procure needed requirement; and

(ii) Following such advance intimation of termination, furnishing at no cost to the Purchaser, the blue prints, drawings and specifications of spare parts, if and when requested.

9.3 AMC shall include supply, repair and a turn around of spares. Transportation

and return of spares shall be borne by the Vendor.

10 Payment Terms Payment shall be made in USD as specified in the contract in the following manner:

10.1 For Equipment Supplies

a) 15% of the total invoice value of goods would be paid on delivery through LC . This LC will be opened by the purchaser at least two weeks in advance before the expected date of dispatch. To enable the purchaser to make the LC, the supplier shall intimate the expected date of delivery 30 days in advance. For clearing the LC, the following documents are to be sent to our bankers through whom the LC is established.

(a) Proforma invoice based on the BOQ (b) BoQ & Packing List (c) Certificate of origin (d) Airway/Bill of lading (e) Insurance certificate (f) A copy of manufacturers guarantee certificate (g) A copy of the contractor’s factory inspection certificate.

b) 35% of the CIF value of the goods on commissioning & issue of take over certificate shall be paid through wire transfer on submission of A/T Certificate from the purchaser.

c) Balance 50% shall be paid by wire transfer after warranty period of

one year is over. 10.2 For Services

a) 80% payment after successful installation, Acceptance testing and commissioning of the system and issuance of “Taking Over Certificate”.

b) Balance 20% payment by wire transfer after one year of warranty period is over

10.3 Payment for AMC shall be made on quarterly basis in advance as indicated in

AMC conditions.

24

11 Change in Orders 11.1 The Purchaser may, at any time, by a written order to the Contractor, make

changes within the general scope of the contract, without affecting the delivery schedule, in any one or more of the following:

a) Drawings, designs or specifications, where goods to be furnished

under the contract are to be specifically manufactured for the Purchaser;

b) The method of transportation or packing; c) The place of delivery.

11.2 If any such change causes an increase or decrease in the cost or the time

required for the execution of the contract, an equitable adjustment shall be made in the contract price or delivery schedule, or both, and the contract shall accordingly be amended. Any proposal by the Contractor for adjustment under this clause must be made within thirty days from the date of receipt of the change in order.

12 Sub-Contracts 12.1 The Contractor cannot assign/transfer and sub-contract its

interests/obligations under the contract without the prior written permission of the Purchaser.

12.2 The Contractor shall notify the Purchaser in writing of all sub contracts

awarded under this contract if not already specified in his offer. Such notification, in his original offer or later shall not relieve the Contractor from any liability or obligation under the contract.

13 Delays in the Contractor’s Performance 13.1 Deliveries of the goods and performance of services shall be made by the

Contractor in accordance with the time schedule specified by the Purchaser in its purchase order.

13.2 Delay by the Contractor in the performance of its delivery obligations, shall

render the Contractor liable to any or all of the following sanctions; forfeiture of its PBG, imposition of liquidated damages and/or termination of the contract for default.

13.3 If at any time during the performance of the contract, the Contractor or its sub Contractor(s), if permitted under Clause 12.1, should encounter conditions impeding timely delivery of the goods and performance of service, the Contractor shall promptly notify the Purchaser in writing of the fact of the delay, its likely duration and its cause(s). As soon as practicable after receipt of the Contractor’s notice, the Purchaser shall evaluate the situation and may at its discretion extend the period for performance of the contract (on the merit of the case after mutual discussion with the Contractor).

14 Progress Report

The Contractor shall, at its own costs, compile, prepare and submit on time, periodical progress reports (fortnightly or as required by the Purchaser) on the

25

progress of delivery, implementation or both, whichever applicable, in respect of purchase order issued by the Purchaser.

15 Liquidated Damage 15.1 The date of delivery of the stores and Installation Commissioning stipulated in

the acceptance of the tender should be deemed to be the essence of the contract and delivery/Installation & Commissioning must be completed not later than the dates specified therein. Extension will not be given except in exceptional circumstances. Should, however, deliveries be made/installation & commissioning is delayed after expiry of the contracted delivery period, without prior concurrence of the purchaser and be accepted by the consignee, such delivery/installation & commissioning will not deprive the purchaser of his right to recover liquidated damage under clause 15.2 below. However, when supply is made within 21 days of the contracted original delivery period, the consignee may accept the stores and in such cases the provision of clause 15.2 will not apply.

15.2 (a) For delivery of Stores:

Should the supplier fails to deliver the store or any consignment thereof within the period prescribed for delivery, the purchaser shall be entitled to recover 0.5 % of the value of the delayed supply for each week of delay or part thereof for a period up to 10 (TEN) weeks and thereafter at the rate of 0.7% of the value of the delayed supply for each week of delay or part thereof for another TEN weeks of delay. In the case of package supply where the delayed portion of the supply materially hampers installation and commissioning of the systems, L/D charges shall be levied as above on the total value of the concerned package of the Purchase Order. However, when supply is made within 21 days of QA clearance in the extended delivery period, the consignee may accept the stores and in such cases the LD shall be levied upto the date of QA clearance.

15.2 (b) Installation & Commissioning:

Should the supplier fail to install and commission the project within the stipulated time the purchaser shall be entitled to recover 0.5% of the value of the purchase order for each week of delay or part thereof for a period upto 10 (TEN) weeks and thereafter @ 0.7% of the value of purchase order for each week of delay or part thereof for another 10 (TEN) weeks of delay. In cases, where the delay affects installation & commissioning of part of the project and part of the equipment is already in commercial use, then in such cases, LD shall be levied on the affected part of the project. In case of delays beyond the normal time for granting permits for new BTS installation by the local authorities, which are beyond the control of the vendor, the LD during the delayed portion for that BTS, will not be applicable.

15.2 (c) Migration of data bases and integration with existing systems: The vendor will be solely responsible for migrating the existing databases for the common network elements like IN, HLR, Billing, SMS, VMS etc. through coordination with existing equipment suppliers/ database administrators. The migration of all the elements need to be completed within the delivery schedule mentioned in RFP. The purchaser will provide whatever information

26

it has but the liasioning with the existing equipmet suppliers will be the responsibility of the vendor. The vendor has to make all efforts to complete the task within the time schedule. However, for any delay beyond the control of the vendor in this regard, which is accepted by the purchaser, LD shall not be applicable.

15.3 Quantum of liquidated damages assessed and levied by the purchaser shall be final and not challengeable by the supplier.

15.4 The total LD amount to be recovered in no case shall exceed 12% of the PO

value. 15.5 This clause will not come under the provisions of Arbitration Clause 20.

16. Insurance

Insurance should cover Contractor’s all risks valid up to issue of “Taking Over Certificate”. It should cover Third Party Insurance, accident or injury to workmen and Transit Insurance for 110 % of value of goods.

The insurance shall be for an amount equal to 110 % of the CIF value of the goods from "warehouse to warehouse" on "all risks" basis including risks of TPND, SRCC and war clauses. All the items shall be fully insured by the Contractor up to the final destination.

Any item/part damage / lost shall be replaced by the Contractor free of charge at first and the insurance claim shall be made by the Contractor to recover the cost of damaged/ lost goods. The insurance policy shall remain valid till the date of issuance of Taking Over Certificate.

17. Force Majeure 17.1 If at anytime, during the continuance of this contract, the performance in

whole or in part by either party of any obligations under this contract shall be prevented or delayed by reason of any war, or hostility, acts of the public enemy, civil commotion, sabotage, fires, floods, explosions, epidemics, quarantine restriction, strikes, lockouts or act of God (Hereinafter referred to as events) provided notice of happenings, of any such eventuality is given by the either party to the other within 21 days from the date of occurrence thereof, neither party shall by reason of such event be entitled to terminate this and contract shall be resumed as soon as practicable after such event may come to an end or cease to exist, and the decision of the Purchaser as to whether the deliveries have been so resumed or not shall be final and conclusive, provided further that if the performance in whole or part of any obligation under this contract is prevented or delayed by reason of any such event for a period exceeding 60 days either party may, at its option terminate the contract.

17.2 Provided also that if the contract is terminated under this clause, the

Purchaser shall be at liberty to take over from the Contractor at a price to be

27

fixed by the Purchaser, which shall be final, all unused, undamaged and acceptable materials, bought out components and stores in course of manufacturer in possession of the Contractor at the time of such termination of such portions thereof as the Purchaser may deem fit excepting such materials / bought out components and stores as the Contractor may with concurrence of the Purchaser elect to retain.

18. Termination for Default 18.1 The Purchaser may, without prejudice to any other remedy for breach of

contract, by written notice of default, sent to the Contractor, terminate this contract in whole or in part,

a) if the Contractor fails to deliver any or all of the goods/services within

the time period(s) specified in the Contract, or any extension thereof granted by the Purchaser pursuant to Clause 13.3.

b) if the Contractor fails to perform any obligation(s) under the Contract; and

c) if the Contractor, in either of the above circumstances, does not remedy his failure within a period of 30 days (or such longer period as the Purchaser may authorize in writing) after receipt of the default notice from the Purchaser.

18.2 In the event that the Purchaser terminates the contract in whole or in part,

pursuant to clause 18.1, the Purchaser may procure, upon such terms and in such manner as it deems appropriate, goods similar to those undelivered and the Contractor shall be liable to the Purchaser for any excess cost for such similar goods. This liability shall be without prejudice to any other claim which the Purchaser shall be entitled to make against the Contractor. However, the Contractor shall continue performance of the contract to the extent not terminated. The Purchaser may, without prejudice, on the happening of any of circumstances, to its other rights under law or the contract provided elsewhere, purchase the balance quantity of the goods at the risk and cost of the Contractor and look to him for the payments thereof and can also claim a set off of any dues payable under the contract to the Contractor against his any dues under the contract or any previous contract.

19. Termination for Insolvency

The Purchaser may at any time terminate the contract by giving written notice to the Contractor, without compensation, if the Contractor becomes unwilling, bankrupt or otherwise insolvent, provided that such termination will not prejudice or affect any right of action or remedy which has accrued or will accrue thereafter to the Purchaser.

20. Arbitration & Conciliation

Any dispute, which remains to be resolved through amicable and good faith discussions between the parties within 180 days of the beginning of such discussion, shall be resolved in accordance with the Rules of United Nations Commission for International Trade Law (UNCTRIAL). The venue of arbitration shall be Mauritius. The laws of the Republic of Mauritius shall be applicable in arbitration. The language used in arbitration proceedings shall

28

be in English. Each party shall bear its own cost for making submission to the Arbitration. The Arbitrator shall be appointed by the common consent of both parties, failing which by the Judge in Chambers of the Supreme Court of Mauritius on the application of either or both parties.

21. Subject Laws and Jurisdiction

The contract shall be governed by Laws and the Courts at Mauritius will have jurisdiction to entertain any dispute or claim arising on the contract.

22. Set Off

Any sum of money due and payable to the Contractor (including security deposit refundable to him) under this contract may be appropriated by the Purchaser or the Govt. or any other person or persons contracting through the Purchaser and set off the same against any claim of the Purchaser or Govt. or such other person or persons for payment of a sum of money arising out of this contract or under any other contract made by the Contractor with the Purchaser i.e. the Purchaser or Govt. or such other person or persons contracting through the Purchaser or Govt.

It is an agreed term of the contract that the sum of money so appropriated under this clause by the Purchaser or Government will be kept withheld as such by the Purchaser or Government till his claim arising out of the same contract or any other contract is either mutually settled or determined by the competent court and that the Contractor shall have no claim for interest or damages whatsoever on this account or on any other ground in respect of any sum of money withheld under this clause and duly notified as such to the Contractor.

23. Notices 23.1 Any notice given by one party to the other pursuant to the contract shall be

sent in writing or by FAX or cable and confirmed in writing, by registered post. For the purposes of this Clause, the contact details of the Purchaser shall be as follows: Mahanagar Telephone (Mauritius) Ltd Attention of: Mr. Sanjay Garg 30, Dr Eugene Laurent Str, Port Louis, Mauritius. Fax: (230)-2940606

23.2 The Purchaser shall notify the Contractor in accordance with Clause 23.1

above in case of any amendment of the contact details specified in the said Clause 23.1.

23.3 The Contractor shall similarly notify the Purchaser of its contact details and any

subsequent amendment thereto in accordance with Clauses 23.1 and 23.2. 23.4 A notice shall be effective when delivered or on the notice’s effective date,

whichever is later.

29

24. Confidentiality

The Contractor agrees that the terms of the contract shall remain confidential. The Contractor and its agents, employees and/or representatives may not disclose any term or condition of the agreement without the prior written authorisation of the Purchaser.

30

SECTION –IV (A)

SPECIAL CONDITIONS OF CONTRACT

1. The special conditions of the contract shall supplement the 'Instructions to the Bidders' as contained in Section II & "General Conditions of the Contract" as contained in Section III and wherever there is a conflict, the provisions under special conditions of contract shall prevail over those in any other section of this RFP. The bidder is required to take note of all points in this section which are to be com plied with and bid submitted accordingly, evenif there is no mention of any item in any other place in the RFP or it is contradictory.

2. If the date fixed for opening of bids is subsequently declared as holiday by the Government of Mauritius, the revised schedule will be notified. However, in absence of such notification, the bids will be opened on the next working day, time and venue remaining unaltered.

3. A soft copy of the techno-commercial bid shall be supplied duly sealed. In case of any discrepancies between the hard and soft copies of the bid, the former shall prevail.

4. (a) The bank guarantee for bid security shall be submitted along with the bids in a separate cover. The bank guarantee so submitted shall be as per format given in Section -VIII on prescribed judicial paper with stamps of proper value and should contain full address of the issuing branch of the bank with its Telephone num ber and FAX number. This cover should be superscribed as "BID SE CU RITY FOR TE ND ER N O. MTML/RFP/GSM/1.

(b) In case where the documents of bid security are not submitted in the manner prescribed under clause 4(a) above, cover containing the commercial, technical and financial offers SHALL BE REJECTED AND RETURNED TO THE BIDDER UNOPENED.

5. (i) The supply of equipment /stores will strictly adhere to the schedule as described in the Purchase Order.

(ii) For third party branded items such as computers, servers, storage-devices, computer-peripherals, LAN switches etc. NEBS-3 (GR-63 core/Bellcore-63 compliant) by third party accredited labs would also be acceptable in place of QM-333. The certification is to be submitted along with the equipment.

6. Purchaser reserves the right to disqualify such bidders who have a record of not meeting contractual obligations against earlier contracts entered into with the purchaser.

7. Any clarification issued by the purchaser in response to query raised by prospective bidders shall form an integral part of bid documents and it will amount to amendment of relevant clauses of the bid docum ents.

8. Purchaser reserves the right to blacklist a bidder in case he fails to honour his bid without sufficient grounds.

9. AWARD CRITERIA:

MTML reserves the right to award the contract to the successful bidder whose bid has been determined to be substantially responsive, technically and commercially acceptable and has been determined as the lowest evaluated price bid provided further that bidder is determined by the purchaser to be fully qualified to perform the contract satisfactorily.

31

(a) The purchaser reserves the rights to counter offer price(s) against the price(s) quoted by any bidder. For the existing network elements, the bidders are free to quote either for expnsion/upgradation or replacement with new network element. There should be only one option out of above.

(b) Purchaser requires that bidder shall quote for complete bill of material and all other items of cost for complete scope of work, meeting fully and completely the tendered technical specification for total demand as given in Section-V and Section-VII. Any deficiency in bill of material, Hardware, software or other items of cost will be provided by the bidder free of cost for successful implementation of the project.

In case bidder has not quoted for some of the items which are essential for turnkey solution, it will be presumed that cost of such items is covered and is part of some other subsystem and no extra amount is payable by purchaser. In the evaluation of bids, cost of such item shall be taken as ‘nil’ while the same shall be made available to purchaser as per requirement without any additional cost. The successful bidder will be required to supply all material/goods required to make the equipment operative, after integrating with the existing network (even if it is not shown in the Bill of Material).

10. The existing network is based on CDMA 1x EVDO architecture provided by M/s Huawei Technologies and consists of one MSC, HLR, IN, SMSC, VMS, BSC and 51 BTSs which are being expanded to 56 BTSs. In addition to this, a parallel BSS network is planned to be installed by M/s ZTE Corp for EVDO Rev A services, wherein 51/56 new BTSs (distributed architecture) are being provided alongwith one BSC, PDSN & AAA. The backbone connectivity is through Microwave links of NEC. The GSM/3G network being envisaged through this RFP is to planned taking into consideration the existing network so as to utilize the available resources to the extent possible to minimize the cost. The bidder has to study the existing network carefully before submitting the bid. All arrangements for providing any solution for utilizing the available resources at the best possible manner (like extending tower height for putting additional antenna or increasing the power plant capacity etc.) will have to be made by the successful bidder at his cost, thus the bid should be prepared accordingly.

11. It is planned to have one common core network, including billing & customer care for both GSM & CDMA. This would require provisioning of more capacity in core network elements to accommodate 110k CDMA lines. The migration of the data from CDMA HLR, IN, SMSC, Billing etc to the new common network elements will have to be done and would be the responsibility of the successful bidder. After having common core, it should be possible to have the existing CDMA mobile number opened as GSM number. The common billing system will generate one bill for a customer having CDMA mobile, fixed and GSM connections. For purpose of implementing common core, the vendor can either expand/upgrade the existing network elements or provide the new ones and integrate with the existing ones to have one seemless network or replace the existing ones with the new elements.

12. The bidder should confirm that all its supplied equipments and interfaces are compliant to international standards including but not limited to 3GPP, ITU, IEEE and are capable to interconnect with other vendors’ equipments like those of Ericssion, Nokia-Siemens, Alcatel-Lucent, Huawei & ZTE. The successful bidder shall commit to provide full support for any inter-working with other vendors as and when it is required by the purchaser, without any additional charges atleast till AMC period.

13. For the purpose of understanding in this RFP, existing 51/56 BTS sites would be called ‘MTML sites’ where infrastructure is available. The additional sites required in the GSM/ 3G network will be referred as ‘New Sites’.

14. Purchaser will be allocated a bandwidth of 5MHz (continuous) in P-GSM band (890-915 MHz). The network should be designed keeping this in view. For future expansions, Purchaser may get additional bandwidth either in E-GSM or in 1800 MHz band and 3G spectrum in 2100 Mhz band. The system provided now should be capable of handling these frequency bands.

32

15. It is estimated that a minimum of 110 BTSs would be required to provide the desired coverage in Phase I and a total of 150 in Phase II. However, the bidder is required to carry out its own RF planning to ensure the coverage and capacity requirement fulfillment as per RFP conditions, and quote accordingly. If the bidder estimate is for more number of BTSs, the same should be clearly indicated and quoted for the same. But if the estimate is for lees than the estimated numbers, the bidder has to quote for 110/ 150 BTSs only, as estimated. The responsibility to provide the desired coverage is solely of the bidder and if the coverage is not met, the bidder would be required to provide additional BTSs free of cost to meet the requirement.

16. The supply shall include complete 2G & 3G equipment including all essential elements like MSC servers, Media gateways, HLR, VLR, AUC, EIR, BTS and Node Bs (or equivalent for HSPA), SCP, OMC, IN system, SMSC, MMS, CBC, GPRS, EDGE, LBS, roof top and ground based towers, antennae, feeder cables, power cables, fix tures and accessories, testing and m easuring instrum ents, Power Plant and battery etc. as a complete package. Additional antenna fixtures, Waveguide (feeder cable) racks (horizontal and vertical), gantry, platforms with hand rails for the new and existing towers, wherever required, shall be provided by the bidder as per the actual requirem ents. All such items which are to be deployed in outdoor conditions shall be made of galvanized iron material. The complete network planning, engineering & optimization of the equipment and transmission equipment shall be the responsibility of the successful bidder. The successful bidder shall also be responsible for tuning & optimization of the equipment for entire warranty, AMC period and also during expansions.

Railing / parapet wall should be provided for safe access around BTS, DG set and shelter wherever installed. Appropriate clear path should be maintained from the boundary for easy access. Ladder should be provided for access to terrace and shelter.

17. The common control equipment provided in crucial network elements like GMSC server/ MSC server/MGW/ HLR/VLR/BSC/RNC/Transcoder/ GGSN/SGSN/IN/UMS etc. shall be provided in redundant hot stand by mode. All power supply units shall be in redundant mode. The bidders shall indicate the redundancy provided in the system as part of the bid document. The system availability shall be 99.999% m easured over a period of one year. In case of overload, system should not go into reboot/ reload mode.

17. Transmission back-haul at all existing MTML sites is on microwave and the same needs to be upgraded to cater to the existing requirement of CDMA/ EVDO and that required for GSM/ 3G. The detailed list of microwave links is given in annexure.

18. Each of the network elements and associated equipments in the network elements, including the hardware and software to be supplied shall conform to latest 3GPP R5 or higher standards. The number and configuration of BTS/Node B and other network elements indicated in SOR are minimum requirement. However, the bidders are fully responsible for meeting the coverage & capacity requirements as per the tender specification. In case a bidder quotes more no of BTS/Node B/any other network element over and above those indicated in SOR as per his design, the quantities so quoted shall be considered for evaluation and ordering.

19. The successful bidder shall carry out the simulation of coverage and generate prediction maps for phase 1 and phase 2 networks. The prediction maps so generated and agreed upon shall form the basis for Acceptance Testing of the coverage for meeting tender requirements.

20. The purchaser shall provide the space, commercial AC mains power supply and air

conditioning at existing MTML sites for installation of various components of equipm ent. The bidders shall indicate the space and power required for each equipm ent like MSC SERVER, MEDIA GATEWAY, HLR, SCP, OMC, OSS, BSC/RNC,

33

BTS/Node B, GPR S, MMS, LBS, Battery, Power Plant, Roof top Tower, Ground based tower etc. AC/DC voltage stabilizers, Inverters and UPS together with adequate battery backup, Runways, cables & cabletrays, wherever required shall be the responsibility of the bidder. The bidder has to arrange supply & installation of PCM cable/Tie cable, DDF terminations & Junper wires etc in respect of all network elem ents. The bidder shall arrange for extension of DC power supply, AC power supply, earthing etc from the existing available points at MTML sites to the equipments.

21. Information regarding the existing MTML sites is available at Annex. The same may be

utilized to the extent feasible for the purpose of design, simulation, coverage prediction and finally implem entation.

22. The civil / electrical works for installation of BTS/Roof top/Ground based Towers

etc. at all sites shall be executed by the bidder as part of the project and in conformity with guidelines in vogue in MTML/ local authorities. It will be the responsibility of the successful bidder to obtain the structural safety certificates from the agencies nominated by the local authorities which includes standard seismic, wind load considerations. All statutory permissions & “No Objection Certificate” from local agencies like Municipal bodies, ICTA, Defence authorities etc. and site owners shall be responsibility of the successful bidder. However the charges payable to government bodies shall be borne by MTML on production of proof of payment by the successful bidder.

23. For those BTS sites for which no suitable site belonging to purchaser is available,

the bidders shall indicate at least three alternate candidate sites so that the purchaser m ay take action for its acquisition. In case three such suitable sites are not available, MTML would consider lesser num ber also after due verifications. The successful bidder shall arrange to get electricity connection of suitable capacity for BTSs proposed to be located on these sites in the name of MTML from the concerned authorities. Any coordination with the agencies in this regard shall be the responsibility of the bidder. The payment to agencies shall be reimbursed by MTML and prior approval of expenditure shall be taken from MTML for such payments.

24. All New Sites (the new sites other than existing MTML sites) shall be with outdoor

BTS and with pole/ roof top/ Ground Based Towers. The outdoor BTS cabinet shall be water/ dust prrof and should have arrangement for proper cooling and atleast 4 hour battery backup. The arrangem ent should also be possible to have 8 hrs battery backup wherever required by MTML. For this purpose, unit cost of additional battery bank in outdoor cabinet should be quoted in the bid. The outdoor BTS cabinet should be strong enough and should be firmly fitted into the foundation base, so as to protect it from theft. No additional shelter/ air conditioners would be required in case of outdoor BTSs.

25. There is no need to provide DG sets for backup power at any of the sites. To meet the

requirem ent of major power breakdown, a total of four (4) m obile DG sets of atleast 15KVA capacity, duly installed at mobile trollies and with sufficiently long power cables are required to be provided.

26. The bidders shall submit the design of the RTT and GBT alongwith necessary approvals

in the bid. Ground based towers shall be ordered as per the requirement and shall conform to the relevant specifications. At 250 KMPH wind speed, the RTTs/GBTs supplied shall be capable of carrying a minimum of at least 12 GSM/ WLL antennae along with 4 numbers of 0.6M dish antennae access Microwave. The RTT/GBT shall survive a wind velocity of up to 320 Kmph for short duration in cyclone conditions. The aviation lam p should be provided on all towers.

27. The responsibility of obtaining clearance from various authorities for construction of

towers (RTT or GBT) on behalf of the purchaser shall entirely rest with the bidder.

34

The purchaser shall furnish the necessary data to the extent available. MTML shall reimburse charges payable to such agencies on proof of payment.

28. The earthing arrangement at each BTS site/tower, both existing and new, including tower

earth ing in all MTM L and New sites shall be the bidder's responsibility. However at MTML existing sites, existing earthing can also be used subject to technical feasibility. It shall be ensured that each site is provided with the necessary surge protection as required. Necessary corrective actions including supply and installation of required devices will have to be done by the bidder to ensure that the site is fully and comprehensively protected against all k inds of h igh voltage and lightning hazards.

29. Radio network planning

The details of the levels for the various specified requirements for 95% of the time, are as follows:

a) Indoor Coverage: Signal level measured at street level shall be better than -65dbm.

b) In car coverage: S ignal level m easured at street level shall be better than -75 dbm. The in car coverage shall be provided in all the residential areas, tourist spots, roads, lanes, high ways, bypasses .

c) Outdoor Coverage: For rem aining open uninhabited places not covered in a to c above like forest, agricultural land, inaccessible places, signal level to be m easured at the nearest accessible point and shall be better than -85 dbm.

d) The bidder shall be fully responsible to make preliminary RF survey to monitor specific RF interference from any other sources such as other mobile operators in the entire service area and furnish the details along with the recommended remedial action.

e) For W CDMA RF performance, the receive signal levels and interference requirements i.e. minimum Eb/No, under UMTS mobility model shall be ensured by the bidder. The average Ec/Io of the network shall be greater than –15dB for the pilot.

30. The bidders shall provide micro BTS and outdoor/ indoor coverage solutions like repeaters/ boosters etc to cover the hot spots/ dark spots to ensure coverage at important locations.

31. The successful bidder shall be required to connect the system with the existing CRBT system provided by Cellebrum.

32. The bidder shall quote any new/enhanced services/features which may be required for com petitive advantage of MTML for inclusion at the discretion of MTML as an optional item.

33. The bidder shall furnish the details about make, m odel no., supplier and the cost of each item separately. The bidder shall quote for only one m ake, model and manufacturer for each of the network elem ents. Once quoted in the bid, no change of make, model or manufacturer shall ordinarily, be permitted. Not more than one independent and complete offer shall be permitted from the bidder.

34. For third party infrastructure items such as battery, p/plant, tower, shelter, DG set, airconditioners etc, the bidder m ay give maximum two options clearly indicating as option I & option II conforming to the tender requirem ents and specifications so as to meet the time

35

lim its of delivery schedule by sourcing these items from more than one source. However, for ordering purposes, lower of the two prices for these options shall be used while for evaluation higher of the two shall be considered. All third party equipm ent should be of proven technology and supported by docum ents for its successful operation of similar or higher configuration for minimum one year in any other network.

35. The Numbering schem e for the proposed serv ice shall be in accordance with approved numbering plan. Any changes, including those in software, required in the network due to changes in the technical, licencing and / or regulatory environment shall be implemented by the successful bidder free of cost during the life span of equipment. It is mentioned that presently 7 digit numbering is available which is likely to be changed to 8 digit in future which should be implemented by bidder as and when required to do so, without any extra charge.

36. The bidder shall ensure that the bid is complete and comprehensive as regards detailed card level BoM. The bidders shall provide unpriced Bill of Materials (BoM) for each of the network elements with complete details of PC Bs contained in each M odule/unit together with their quantity required to meet the performance requirement sought for in the tender in the Techno-Commercial bid. The detailed specification of generic items such as laptop and desktop computers, Printers, inverters, UPS etc shall form part of the Techno-Commercial bid.

37. The bidders shall furnish detailed project implementation schedule by means of PERT chart in the bid detailing the various activities involved, their time frame for completion and the dependency on other activities. The bidder shall be responsible for arranging all the clearances for commercial launch of service.

38. Lawful interception and monitoring facility as per 3GPP Release 4, TS 33.106 & TS 33.107 for voice, SMS, MMS, data shall be provided. The facility for monitoring shall have to be provided for at least four independent agencies for simultaneous monitoring. The system shall provide perform ance monitoring of mobile calls/numbers through call conferencing facility to any m obile/PSTN/CDMA telephone. The system shall be capable of m onitoring 100 mobile calls/numbers simultaneously through call conferencing facility at any time in the network. The system should also be capable to provide online call details such as date, time, call duration, IMSI no., IMEI no., cell ID, calling & called no., etc. The system should be capable to monitor SMS Data and provide the SMS details. The system shall be capable of converting raw SMS data / details into readable text form at as per requirem ent of monitoring agencies.

39. The Equipm ent Identity Register (EIR) shall be provided as part of the core network and shall have the provisions for gray list/ black list for tracing/ blocking calls from the lost mobile phones in the network. The EIR m ay be required to interact with the EIRs of other GSM operator networks for taking data of lost m obiles in the whole country.

40. All software licenses like IN, VoMS etc. shall be in the name of MTML allowing for multi users and for unlimited period.

41. In case of long duration calls, an automatic a lert should be generated along with LOG and the duration of long calls should be configurable.

42. SOFTWARE

(i) Software version of the equipment being supplied should be latest & must be indicated in the bid.

(ii) All the software licenses supplied against this tender shall be perpetual without any limitations on use.

(iii) All the system software loaded in the various network elem ents shall be supplied in m edia suitable for re-loading of the software in the network element, if needed.

(iv) All the Software updates and /or patches required for the maintenance of the system supplied will be intimated within one month of its release and implem ented free of cost within another one month at each site for 7 years by the successful bidder. The

36

successful bidder shall get one such representative network elem ent / system inspected technically by MTML after the implementation of Software updates/ Patches in each system.

(v) Software Support Centre: - Successful bidder shall establish Software Support Centre in M auritius within Six m onths of award of contract to ensure smooth functioning of equipm ent supplied and to m eet additional requirem ents from tim e to time free of charge. The bidders shall submit details of location, num ber of personnel, facility to be made available for Software Support Centre in the bid. No remote access to foreign country shall be allowed except for catastrophic failures.

43. ACCEPTANCE TESTING

(i) Purchaser reserves the right to appoint any testing authority for carrying out acceptance testing of the network and its network elements. The acceptance test schedule generally covers the following:

(a) Check on cabling and wiring.

(b) Functional test for various network elements.

(c) Functional test on individual equipm ent/network.

(d) Coverage and capacity test

(e) traffic trials.

(ii) The successful bidder shall submit a comprehensive and com plete test schedule together with test set-up and procedure for conducting Acceptance Testing on each of the network elem ents to be supplied under this project. The successful bidder, after incorporating modifications and / or additions as per MTM L requirements, if any, shall finalize Acceptance Test schedule at least one m onth in advance of scheduled date of A/T as per the PERT chart. The Acceptance Test Schedule shall clearly indicate the specifications / clause(s) of tender verified by each test.

(iii) The bidder shall make available the software programs and testers required for carrying out the acceptance tests as per the schedule. The bidder shall indicate whether the software package includes programs for testing the nodes under full load conditions and overload conditions by creation of artificial traffic.

(iv) Any component(s) or module(s) failing during the acceptance tests shall be replaced free of cost at site by the bidder. These will be delivered within one month of the initial reports.

44. PACKAGE DISCIPLINE:

The bidders as part of their bid, shall indicate the sequence of supply of various items to appropriately take care the different lead times required for commissioning of the individual network elements. The successful bidder shall schedule his supplies to ensure completion of installation, testing, validation and commissioning as per schedule.

45. Supply/Installation/Commissioning: The commencement of Supply and Installation of the systems should start within 2 months of placement of P.O. for Phase-I and commissioning of Phase-I equipment should be completed within 10 months of placement of Purchase Order. The

37

month-wise schedule for completion of supply, installation commissioning shall be as follows:

Sl.

No

From the Date of P.O

% of Installation & Commissioning

Rem arks

1 End of 6th month

40 % All core network elements and BTSs at exiting MTML sites should be commissioned.

2 End of 8th month

80 % 75% of the New site BTSs, BCCS, Value added services should be comm issioned.

3 End of 10th month

100 % Com pletion of the project including m igration of IN, HLR, B&CCS and other items wherever required.

The delivery schedule and installation & commissioning of Phase-II equipment shall be 8 months from the date of the Phase-II P.O. on similar lines.

Non-adherence to Installation & Commissioning as detailed above shall invite LD charges as per the Clause 17, Section –III.

46. Operation and Maintenance: The successful bidder shall carry out all the functions of operation and maintenance during the first 3 months of commercial launch of the Phase-I equipment. The successful bidder shall fully associate the staff of MTML during this period so that they are able to operate & maintain independently. During this period, the successful bidder shall put into operation the set of m aintenance procedures, periodic test schedules, Traffic Report generation & analysis and rem edial measures to be taken if required, Extraction of perform ance statistics from the various OMCs and other network elements, Statistics regarding in-roamers and out-roam ers in various form ats and classification as required by the purchaser, M anagem ent Information System (MIS) parameters for fault, performance and planning of network expansion. The successful bidder shall also help MTML to put into practice maintenance schedules viz opening of appropriate registers for log, test schedule and performance and fault recording.

47. All the network elem ents and software units supplied for the system shall be fully downward com patible with the existing system and inter work seamlessly without any lim itation.

48. Technical audit of system Performance MTML reserves the right to carry out technical audit of the network through any designated agency from time to time and bidder shall take necessary corrective measures to conform to the performance parameters stipulated in the tender document within the period of performance guarantee.

49. Annual Maintenance Contract- a) The bidders shall quote for a year wise comprehensive Annual Maintenance

contract for 3 years. MTML will have the discretion whether to sign the AMC contract or not for each year separately. The AMC for 1 st year is to be signed at the end of warranty period and then for each year separately. The cost shall be quoted as a lump sum including visit of the engineers as and when required. The terms and conditions for AMC are given in Annexure.

b) During the warranty period, the successful bidder shall perform all the functions as enunciated under the AMC, free of cost. All the penalty clauses shall be applicable during the period of warranty in case of failure on part of supplier.

c) The bidder shall, at the time of submitting the bid, also submit the proposal specifying the Fault Control Center Location and how the bidder proposes for carrying out repair under AMC. The bidder shall also indicate what spare will be kept in different locations. The infrastructure planned to be created by the bidder to meet his obligations under AMC and his action plan to deal with the

38

various situations arising out of hardware and software faults shall be clearly indicated.

50. General Points:

(a) The advantage of reduction of taxes/ duties during evaluation of tender / execution of contract shall be passed on to the purchser i.e. MTML and no benefit of increase will be permitted to the supplier.

(b) The equipment envisaged in this tender shall be capable of supporting IP version –6 (IPv6) as and when required.

(c) The purchaser reserves the right to commercially exploit the installed equipments after the delivery linked payment are made as indicated in payment terms or after the prescribed period stipulated for the initial roll out to commence whichever is earlier. Such comm ercial utilization of the network after the completion of the prescribed delivery schedule and before commissioning of the network shall not entail the successful bidder to claim deemed completion or otherwise incomplete obligations under the terms and conditions of this tender and shall not relieve bidder of the liability under the relevant clauses arising out of such non-completion.

51. Fraud Management: The bidder shall supply a suitable fraud control & management center(FMCC) as per 3GPP TS 22.031 & 32, TS 23.031 and 35 to interface with all the network elements including MSC SERVER AND MEDIA GATEW AY,IN platform, GPRS, EDGE charging gateway, W CDMA, and B&CCS etc. Broad outline of the requirement for detection and monitoring shall be as follows:

Roaming Frauds-National/International

SIM card duplicate and cloning

Detection of Organised fraudsters

Call volume/duration frauds

Detection over packet services

Subscription frauds

Abnormal behaviour

The system shall ensure apart from detection and monitoring of ab ove frauds,need to provide management reports and also should be configurable in the field to ensure defining rule based detection.system should be upgradable to manage new and evolving fraud methods.The fraud management and detection and detection shall be in near real time basis.

52. International Roaming: The system so provided must be capable of handling

international roaming service for both voice and data. The billing system provided should take care of Roaming billing for in-roamers as well. Prepaid roaming should also be available with the operators who support it.

53. Location Based Services: The bidder will provide the location based

services like vehicle tracking system, cell broadcost services (CBS) for a particular cell or in the whole area, location name displayed on the mobile phone screen etc. The system should support third party application based

39

on location for integration into the system. Location Based Applications should be provided to have the competitive advantage.

54. Push Mail Service: The system should provide Push E-Mail functionality

wherein the mails received on customer’s email id are pushed to his mobile phone if the service is subscribed.

55. Billing & Customer Care Centre: MTML presently has the B&CCS for its

CDMA subscribers. The bidder may upgrade the same or replace it with the new one to meet the enhanced requirements as mentioned in the technical section of this RFP. The billing system should be able to generate one bill for the customer who is having CDMA & GSM both connections. The responsibility for migrating the existing database to new system would be of the bidder. The B&CCS will also provide the call centre functionality with IVRS and monitoring facilities.

56. Upgradation to HSPA: W hich is normally planned for Phase II expansion in the RFP, may also be asked for earlier in part of Phase I BTSs to cover some area. The price in financial bid for HSPA upgradation should be quoted ‘Per BTS’ taking into consideration all Hardware, software and service charges.

57. E-Top Up/ E-PIN syetem: This syetem can be provided either as part of IN or a separate system. It should be possible to manage distributor/ retailor network for recharge PIN transfers for crediting the customers account through USSD/SMS. The system should keep the proper records for all transactions and should send the SMS notifications to the affected parties on the required transaction execution.

58. Push To Talk (PTT): The BSC shall support inter-working with PTT Dispatch System (PDS) easily to provide Push-to-talk (PTT) service without adding or changing any BTS.The vender can provide this feature either on the existing CDMA BSS or on the planned GSM network. The PTT service should include but not limited to the following services: a) Basic services: .Private call; .Group call; .Broadcast call; .Floor management; .Mobility management; .Billing management; .Trunking service management; b) Supplementary services: .Service Priority; .PTT Call Priority; .Group Member Priority(Floor Taken); .PTT Emergency call; .Late-Entry; .Talking Time Limitation; .Incoming call alert on busy (Call Alert); .Group Number Presentation; .Barring of Calls; .Floor Queue;

40

.Floor Status Alert; .Out of Dispatch Service Area Indication; .Group Management In W ireless Mode; .Dispatch Service Area Selection; .Function Number; .Do Not Disturb; .PTT Call Forwarding; .Group Member Status Query In W ireless Mode; .Short Number Dialing; .Pre-emptive Priority Call; .User Number Identification Presentation/ Restriction; .Fall Back;

59. Missed Call Alert: The system should provide the SMS notification for missed calls (in case of customer powered off/ out of coverage area or busy). This can be implemented as part of MSC or as a separate system.

60. Mobile Number Portability: The system should support MNP, as and when it is implemented in the country as per ICTA guidelines. However, MNP in our own network i.e. from CDMA to GSM should be available immediately.

61. Mobile BTS (CoW): To meet the requirement of hot spots during a specific period, the vendor needs to provide two mobile BTSs (Cell on Wheel – CoW ) with all required accessories. The equipments should be installed at a trolley so that tt should be possible to take it to the required place and start the service within couple of hours.

62. Other Services: The vendor should ensure that at least those services which are available presently should be available in the new system as well. The special attention is drawn towards the capability of MSC as Gateway MSC for handling various signaling protocols for successful completion of all voice, data calls for local & roaming scenario and SMS/ MMS working with local/ international systems.

63. Airport region: The bidders should take note of the fact that several BTS

towers will come in Airport Flying Zone where restrictions are in place for maximum tower height. In those areas its difficult to have clearance for tower heights more than 25-30 meters (exact height depends on the location and should be confirmed from the concerned authority). The bidder should consider it while planning the network and also while executing the tower construction work.

64. Core Network Site: The purchaser is planning to have the core network site

at a different location in Cyber City, Ebene, which may be a separate site than the present CDMA core network site in Port Louis. The new building work is going on and a decision for using the existing location or the new location would be taken at the time of placing the purchase order to the successful bidder. Meanwhile, for the purpose of planning and bidding, the bidder should assume that the core network location will be the same that is at ‘MTML tower’Port Louis. The bidder is also requested to give the additional cost for all equipment and services required if the site is decided to be the new one at Cyber City, Eben.

41

SECTION –IV (B)

DETAILED TECHNICAL REQUIREMENTS

1. INTRODUCTION

Mahanagar Telephone (Mauritius) Limited (MTML) presently operating on CDMA 2000 1x EVDO Technology dimensioned for 110K lines supplied by M/s Huawei with 51 BTS sites (being expanded to 56 BTSs) operational over the Main island since 2005. The existing NSS and BSS element details along with present MW setup are available in Annexure. In addition to this, a parrel BSS network is being installed by M/s ZTE for EVDO Rev A services. MTML has decided to establish GSM based subscriber access network with 200K lines along with HSPA in two phases and Main Switching System which should support national as well as international gateway functionalities.

2. Coverage and Capacity requirements:

MTML intends to deploy 200K lines of GSM & HSPA network all over Mauritius in two phases as detailed below:

2.1 Phase – I is planned for 100K of GSM with GPRS & EDGE network all over

the main island. The network elements should be HSPA enabled. The network is to be designed with 1.5 BHCA and 25 Milli Erlang per subscriber. However, the system shall be capable of configuring for more number of subscribers subject to the limitation of the total erlangs traffic and total BHCA, whichever is achieved earlier without any other limitation.

2.2 In Phase – II, the entire service area of Mauritius main island is to be provided with full HSPA coverage. Additional capacity of 100K will be ordered in any proportion of 2G and 3G lines depending on the actual subscriber growth and market conditions. However for the purpose of tender evaluation, 50k HSPA addition will be considered for Phase-II. The HSPA shall be an overlay to the GSM network. The network should have seamless handover between 2G to 3G and vice versa for service continuity for both voice & data. The system should be able to support the transmission of BSC – BTS interface over satellite for the BTSs to be located in the remote and inaccessible areas places like islands. Further, these BTSs are also compatible to work on E1 links on DCME. BSC should also have facility to interface with E1 links, with or without DCME, on satellite media. The network should support handover of the voice calls and data calls in progress, when the subscriber moves from one BTS to other. The voice calls and data calls should not get disconnected even if the subscriber moves at the speed of 120 Kmph.

Vendor shall be fully responsible for complete survey, engineering & design of the network to provide RF coverage as per the technical specifications provided in this RFP, while considering to co-locate with the existing all 51/ 56

42

CDMA BTS sites and propose the additional BTS sites required to meet the coverage requirements as per the RFP. The vendor shall provide suitable solution (Micro BTSs/Repeaters) for covering the Black-Spots. The maximum number of Micro BTSs/Repeaters shall be limited to 20% of the total number of BTSs. The vendor shall provide complete GSM+HSPA system including hardware & software. The vendor shall also provide detail description regarding its capacity and capability expansion. All the BTSs shall be expandable to minimum 6TRX per sector without any hardware addition under same frequency band.

3. SPECTRUM :

a. For the proposed 2G/ 3G network, the spectrum available is 5 MHz (continuous) in 900 MHz band. In addition, for launching 3G services, initially one 5 MHz HSPA carrier may be assumed in 2100 MHz band as per HSDPA/HSPA specifications.

b. Ordering of HSPA equipment is subject to the allocation of 3G spectrum by

ICTA. In case the allocation of 3G spectrum is delayed or MTML decides not to go for HSPA, the order for only 2G portion would be made.

4. ENGINEERING & PLANNING OF THE NETWORK 4.1 The complete network survey, design, planning, engineering, supply,

installation, testing & commissioning of all systems & subsystems including software’s shall be responsibility of the vendor.

4.2 Design parameters:

i. BHCA Per Subscriber = 1.5 on A interface (both post paid and pre paid). (An end-to-end call attempt i.e., MO-MT or MO-PSTN or PSTN-MT shall be treated as one BHCA)

ii. Average Traffic per subs for both pre paid and post paid = 25 mErl

iii. Common Core network for GSM and HSPA.

iv. MSC server with media gateway

v. The network should have seamless handover between 2G to 3G and vice

versa for service continuity for both voice & data. 4.3 Following would be the subscriber distribution:

Voice Subscribers 100% Data Subscribers

43

a) GPRS & EDGE 20% b) HSDPA / HSPA 10%

4.4 Following is the traffic assumption for voice & data calls:

Voice Calls BHCA per subscriber 1.5 Average Call Duration 60 sec. Traffic per subscriber 25 mE Packet Data Calls Busy Hour active mode per subscriber 0.8 Peak data rate a)HSDPA -7.2Mbps

DL/ 300Kbps UL b)HSPA-7.2Mbps DL/1.75Mbps UL c)GPRS-144 kbps d)EDGE-384 kbps

Average Call (Session)Duration 300 sec. Simultaneous data users 10% of data

subscribers 4.5 Following are the Grade of Service (GOS) Requirements:

MSC to PSTN 0.1% MSC to MSC (to other nw)

0.1%

MSC – BSC 0.1% BSC – BTS 0.1% BTS – RS 2%

4.6 Call performance parameters

Call Set up time <6sec. Call Set up success >98% Call Drop Rate <1% Data call Success Rate >90%

4.7 Call Mix may be taken as follows:

(a) W ith in our GSM Network : 15% (b) GSM to Fixed Line Network: 25%

(c) GSM to other mobile Networks: 40% (d) ILD own subs/ transit/ Special Service Calls: 5% (e) GSM to MTML CDMA Network : 15% (f) Percentage of packet data customers: 30% (10% of which are

simultaneously active)

44

4.8 Provision of 60E1 ports to be kept for International Gateway Operation. Incase, International Gateway functionality is integrated in the MSC, provision of required E1 ports to be kept in MSC or suitable provision for E1 ports to be kept in the proposed International Gateway Switch.

4.9 Radio Design Parameters

S.No. Parameters Value 1. Frequency Band of Operation 5 MHz bandwidth in 900

MHz Band. 2. Number of Sectors Generally 3 sectors will

be used. However, for specific requirements such as road coverage etc. 1 or 2 sector BTSs may be used.

3. Penetration Loss Dense Urban (>6 storied bldgs) 24dB Urban (2 – 6 storied bldgs) 20dB Sub urban ( 2 storied bldgs) 15dB Rural/ In car ( 1 storied bldgs) 10dB 4. Cell Loading Percentage 70% 5. BTS antenna gain >=17 dBi 6. Desired hand-off percentage 35% 7. Desired cell area coverage 95%

4.10 The vendor shall submit detailed link calculations in support of his meeting of

coverage,Microwave & other RF requirements. 4.11 The network envisaged is a hybrid of GSM & HSPA. Data users shall be both

type. A data subscriber when visits a cell without HSPA shall get data access through GPRS/EDGE. Handing off of data calls from GPRS/EDGE to HSDPA/HSPA cell and vice versa shall be without disconnection of the call.

4.12 Each call shall carry full CLI through out the network. 4.13 RF Coverage Requirements

Mauritius is a group of islands consisting of one mainland island, one main satellite island (Rodrigues) & other small satellite islands. Total main island area is about 1850 sq. kms. Mauritius has wet humid tropical weather with rains almost through out the year and temperature varies from 10 to 34o C. In Mauritius, the population density is very high of the order of over 600 inhabitants per sq. kms and the Coverage objective under this RFP is to cover the main island only. Mauritius is a tourist destination and a large number of tourist visit this country every year. Coverage objective is to cover all residential areas, Business Centers, Industrial Areas, Shopping Centers, Cyber City, Race Course, Stadiums, Exhibition Ground, Airport, Hotels, Beaches & Tourist Places, National High Way (Motorway), Main Roads, Coastline Roads, Secondary & regularly maintained Roads. The vendor may propose BTS repeaters/ Micro BTSs or other solutions for providing indoor coverage.

45

At some places (five municipalities) as tabulated below, 4/6 TRX BTSs are required to be deployed to meet capacity as well as coverage objectives:

S.No. Name of Municipalities Earlang Traffic 1. Port Louis

i. Down Town (Main Business Center) 700 ii. Residential Urban 262 iii. Residential Sub Urban 88 iv. Industrial 105

2. Rose Hill & Beau Bassin 350 3. Quatre Bornes 300 4. Vacoas & Phoenix 420 5. Curepipe 350

These numbers are indicative and the supplier will be fully responsible for Survey, Design, Planning, Engineering, Supply, Installation & Commissioning of the complete project and vendor to quote the number of BTS required to meet the specifications of the RFP.

4.14 RANGE OF SERVICES

1 Voice Voice Calls and emergency Calls 2 Data Services: Circuit Switched

a. Asynchronous Data (14.4 Kbps) b. Group-3 FAX Services, to be supported on the network for the following: i. Fax machine to Fax machine

ii. Fax machine to PC iii. Fax machine to PC and iv. PC to Fax machine

Packet Switched GPRS/EDGE High Speed Data Services (HSDPA/HSPA)

3 PCO Provisioning 16 KHz and Polarity Reversal for home metering for at least 2% of the subscribers.

4.15 Supplementary Services:

In addition to the services listed in above table, the following features / functions and supplementary will also be provided:

a) Voice Messaging Service/ Short Message Service/ Multi Media Service (MMS) as per 3GPP standard. It shall be possible to deliver a short message to a subscriber terminal

even if the terminal is engaged in a call.

46

In a mobile –originated SMS, it shall be possible for a subscriber to send a text message to the Message centre while the terminal is idle or during a voice conversation.

b) Call forwarding ( for 100% subscribers): Basic Remote call Forwarding Call Forwarding Unconditional (CFU), Call Forwarding W hen Busy (CFB) Call Forwarding when No Answer or Not Available(CFNA) Call Forwarding on call W aiting User Selective Call forwarding

c) Calling Number ID presentation (CNIP) – (100% subscribers) d) Calling Number ID Restriction (CNIR) – (100% subscribers) e) Call Transfer (CT) – (100% subscribers) f) Call W aiting (CW ) – (100% subscribers) g) Call Hold (CH) – (100% subscribers) h) Three way calling– (10% subscribers) i) Closed User group (CUG) j) ISDN inter-working services (As per 3GPP ) k) Distinctive ringing m) Support of Position Location Service

This service provides for the transfer of position location data between the RS and the Network {3GPP Standard}

n) Prepaid Service (PP) for data :

GGSN/SGSN shall perform real time usage tracking on a per pre paid user basis , and compare the usage of that session against a pre paid account balance ( measured in real time or bytes ) sent to the GGSN/SGSN during call set up W hen the usage for the current session depletes the account balances the GGSN/SGSN shall either kill the call or redirect the traffic to a registration server . This service shall be dimensioned for 100% of data subscribers.

0) Auto provisioning of Data subscribers:

All new wireless data users may be given a default user name and password. The system may allow multiple concurrent logins for that default user name and password. The system can redirect all user traffic to a default sign up website ( blocking access to all other wireless data sites and services ) that will take care of user registration . User profile information can then be downloaded to the server upon successful completion of new user registration .

u) Dynamic call baring & enabling– (100% subscribers)

v) Call Hunting Facility– (5% subscribers)

w) Support for Point of sales machines accounting/ financial services on GPRS/EDGE

47

For the/ features not supported, the capability and the road map to support them in future may be indicated.

5.0 ENVIRONMENTAL CONDITIONS 5.1 Ambient conditions are as follows:

Temperature -5 to + 50 degrees Centigrade Relative Humidity Maximum 99% Thunderstorms 60 thunderstorms days / year of intensity 10

KV/m of duration 6 to 10 micro sec (1000 strikes per year).

Dust Filtration Total dust contents is less than 0.05 mg/cubic meter (with 95% of the dust content less than 5 microns)

W ind Velocity During Cyclones up to 320 km/hr 5.2 The vendor shall furnish the necessary graphs, table or charts depicting the

tolerance capacities of their equipment with respect to various environmental parameters like temperature, humidity HSL & wind velocity etc.

The bidders shall furnish the calculations of the link budget mentioning various assumptions, if any, and shall submit the detailed engineering to arrive the BTS count for coverage requirements of the tender mentioning values of following parameters considered for design. Service type Uplink Thermal noise power density dBm/Hz Noise figure dB Eb/No dB User rate Bps RBS Sensitivity dBm UL Loading % Interference margin dB Mobile station output power dBm Mobile station antenna gain dBi Soft handover gain uplink dB Power control margin dB Body Loss dB Building penetration loss dB Car penetration loss dB BS Antenna gain dB Feeder loss dB Jumper and connector loss dB Duplexer loss dB Diplexer loss dB Uplink polarization loss (Slant) dB LNF margin dB Maximum path loss dB BS antenna height m MS antenna height m

48

Maximum range (as per propogation model used)

Km

Site-to-site distance Km Any other parameter

6.0 TECHNICAL SPECIFICATIONS

6.1 MSC based Core network for GSM & HSPA System

6.1.1 Introduction

This document lists the technical requirements for a Softswitch architecture GSM/UMTS CS network. It describes the target architecture and formulates and a single, common set of requirements and expectations regarding the functionality / capabilities, performance and delivery of MSC Servers & Media Gateways.

Figure 1: Softswitch Target Architecture of GSM/UMTS CS Core Network

6.1.2 This target architecture of core network will meet the following high level requirements, which the vendor’s solution will have to support:

a) The proposed Circuit Switched Domain System shall be in Split Architecture as defined by 3GPP in Release 4 and Release 5.

b) The Bidder shall describe how its Circuit Switched products can be mapped on the reference architecture defined by 3GPP in Release 4/R5 (23.002, and 23.205 for layered architecture).

c) The proposed Circuit Switched Domain System shall simultaneously support UTRAN (3G) and GERAN (2G) accesses. The Vendor should explain how the resources are shared between UTRAN and GERAN

49

access. d) The proposed system, Mobile Softswitch, must be a mature commercial

system. e) The supplier will give an overview description of his 3GPP R4 solution,

with layered architecture for Circuit Core Network (VMSC server, GMSC server, TMSC Server, MGW, and HLR/AUC) in order to fill functionalities such as Control Service Function (CSF), gateway functional node, transit function, VLR, gsmSSF, Signaling Gateway (SG), Bearer Control Function (BCF), Bearer Interworking Function (BIW F).

f) The Vendor shall depict all protocol layers for each supported interface and provide statement about compliancy with relevant 3GPP standards or other standards (RFC, ITU-T, IEEE) for each protocol layer.

g) The Proposed CS products shall have large capacity with high density in order to save the Carrier ’s CAPEX and OPEX. Furthermore, the CS products shall be modularized designed and have reasonable flexibility for the future capacity expansion.

h) The proposed CS core network shall support the carrier network based on TDM and IP. From Carrier’s Perspective, IP should be chosen as preference, and the common IP/MPLS backbone should be used for transport of control & user plane.

6.1.3 Signaling & Bearer transmission

a) The proposed CS solution shall support all IP networking, including Nb over IP, Nc over IP, Mc over IP, MAP over IP, CAP over IP, IU over IP, A over IP and etc.

b) MSC Server shall support BICC to interwork with other MSC Servers, support SIP to interconnect with fixed network.

c) The proposed Mobile Softswitch Based Core Network shall support TDM and IP based transport network. Considering the aspects of technique maturity, service capability, future development and investment protection, Carrier prefer to choose IP/MPLS as the transport network. The Vendor should support the QoS solutions for CS on IP transport, such as MPLS, DiffServ, VPN, IP CAC, TrFO, MGW based QoS enhanced function and etc.

d) The proposed Circuit Switched system shall provide dual-pane mechanism to guarantees IP network reliability and must support to use BFD and IP FRR to realize fast switchover.

e) The proposed Circuit Switched System shall provide redundancy backup mechanisms for both IP interface board and interfaces on IP board. The vendor should state the detailed mechanisms.

50

f) The Bidder shall indicate if and when SS7 over IP is supported specifying the protocol stack over the involved nodes. The Bidder shall indicate if this functionality requires additional dedicated hardware. The proposed CS system shall support at least M3UA/SCTP/IP stack as defined in TS 29.202.

g) The proposed Circuit Switched CS System shall support M3UA/M2UA/SCTP/IP protocol stack to support legacy BSC connecting (for legacy BSC does not support M3UA networking)

h) Nb interface shall support both IP and TDM simultaneously to make the network smoothly evolve to all IP solution.

i) ATM based Iu-cs interface (STM-1 preferred) is the current mandatory requirement, but the option for medium to long term evolution to IP based Iu-cs (with Fast Ethernet or preferably Gigabit Ethernet interfaces on RNC and MGW ) should be supported.

j) The proposed Circuit Switched CS System shall also support IP based A interface to save the TC resource and to realize 2G/3G resource completely shared

6.1.4 Compliance with 3GPP specifications

a) The Vendor shall state compliance with all relevant 3GPP Release 4, Release 5 and Release 6 Core Network Technical Specifications. If the Vendor is non-compliant to mandatory requirements in any of these specifications, plans and roadmaps for future compliance for these specifications shall be provided.

6.1.5 Network synchronization

a) The Proposed Circuit Switched System shall support at least two types of external clock reference:

i. Providing 2MHz or 2Mbit/s incoming clock source through BITS ii. Providing 2MHz incoming clock source through E1 line.

b) The proposed Circuit Switched System shall support internal clock output interface. The Vendor is requested to describe the mechanism.

c) The provided timing synchronization shall meet the requirements of ITU-T Recommendation G.812.

d) The proposed Circuit Switched shall provide at least Stratum 2 clocks. e) The proposed Circuit Switched system shall support NTP (Network Time

Protocol), and the NTP server shall be provided. 6.1.6 Interworking

a) The Vendor shall be responsible for integration of the proposed CS core network entities to the other entities in the core network, the entities in

51

the radio access network and service platforms of CARRIER including the Billing and Provisioning System.

b) In order to avoid upgrade of the GSM, reduce the investment for the initial network deployment, unidirectional handover form UMTS to GSM in CS domain shall be supported. The Vendor shall describe the interworking mechanism.

c) The Vendor shall describe interworking between UMTS and legacy GSM/R99 network and PSTN/ISDN networks.

6.1.7 Roadmap

a) The Vendor should mention the roadmap forecasted of the platform proposed and specify the procedure to meet the 3G technology and future requirements and indicate whether the upgrades are software only or require hardware changes.

6.1.8 The core network will be common for planned GSM/ HSPA network. The

Core Network shall be based on 3GPP standards.This Core Network shall be required to work with the Radio Network (RN) and the Packet Core Network.

The core network shall comprise of MSC servers, Media gateways, HLR/AC, Equipment Identity Register (EIR) and Operation & Maintenance Centre and shall be compliant to various 3GPP standards.

6.1.9 The functions and features of MSC based core network can be

categorized into the following main functional areas: -

(a) Call processing (b) Mobility Management (c) Supplementary Services (d) Radio Resource Management (e) Terrestrial Facility Management

Call Processing: This refers to the steps required in the MSC to set up and release wireless calls. Basic Call Processing functions include Remote Station Origination and Remote Station Termination call set up, as well as Call Clearing Scenarios initiated by the Remote Station, the BSC and the MSC. This functional area also includes the call failure scenarios such as timer expiration and unsuccessful resource allocation. Mobility Management: These procedures are needed to manage the registration and access status of individual Remote Station subscribers. These procedures include management of Mobile parameters such as Mobile location, Mobile identity, and authentication status in the Visitor Location Register (VLR) and Home Location Register (HLR). Through mobility management, wireless subscribers can roam freely within a network and across networks. Mobile Management Functions also include

52

Authentication which is a technique used to ensure the security and privacy of wireless Mobile subscribers in a network. Supplementary Services: These are wireless subscriber features that provide capabilities other than basic voice and data services. Over-the-Air Service Provisioning (OTASP) and other services as detailed in the chapter on ‘Range of Services’. Radio Resource Management: This refers to allocating radio channels for both voice and data traffic. This function includes the management of hand-offs within a BSC, between BSCs and across MSCs. Terrestrial Facility Management: This is the function in the MSC that manages the terrestrial signaling links, routes and voice circuit resources.

6.1.10 Network Architecture: Following are the various components of the MSC based Core Network: MSC/VLR: MSC (Mobile Switching Center) is responsible for call establishment, route selection, call control, radio resource allocation, mobility management, location registration and channel handoff in switching areas. In addition, it generates bill information, coordinates services between it and the PSTN. VLR (Visitor Location Register) acts as a dynamic database and stores the temporary information (all data necessary to set up call connections) about the users roaming to the local MSC area.

HLR/AUC/EIR: HLR (Home Location Register) is responsible for storing subscription information (telecom service subscription information and user status), RS location information, MDN, IMSI (MIN), etc. The AUC (Authentication Center) is physically combined with the HLR. It is a functional unit of the HLR, specially dedicated to the security management of the CDMA / GSM system. It stores the authentication information and ciphering key and prevents unauthorized users from accessing the system and prevents the unauthorized radio interception. HLR can be an integrated HLR with MSC or a stand alone HLR. The EIR (Equipment Identitiy register) will have the gray/ black list to trace/ block calls made from stolen mobile phones and will co-ordinate with other network EIR for the same.

Operations and Maintenance Centre (OMC): The Operations and Maintenance Centre (OMC) allows the centralized operation of the various units in the system and the functions needed to maintain the sub systems. The OMC provides the dynamic monitoring and controlling of the network management functions for operation and maintenance.

6.2. MSC SERVER :

MSC shall be the soft switch and will have the connectivity through Media Gateway.

53

(i) MSC or STP should have GTT capacity and its SCCP accounting for

interoperator bill settlement for international roaming.

(ii) MSC should support multi SP feature and high link toward STP.

(iii) MSC should be able to generate hot bills for 1% of total subscriber

capacity.

(iv) MSC should support selective optimal routing feature.

(v) MSC should support A party analysis in case of routing feature.

(vi) GMSC/MSC/IN should have USSD call back feature.

The MSC server CPU processing capability, traffic model for MSC server CPU sizing and supplementary and other services shall be provided as per various 3GPP/ 3GPP2 standards.

6.2.1 General Requirements

6.2.1.1 Hardware and software design

a) The MSC Server/VLR proposed shall conform to all relevant ETSI GSM and 3GPP Release 4, Release 5 specifications. The Vendor shall list and give compliance statements to relevant ETSI GSM and 3GPP specifications for the support of GSM and UMTS circuit switched services and the integration with GPRS and UMTS packet domain networks.

b) The HW platform of proposed MSC Server shall be the common and mature platform which can be used in NGN, W CDMA/GSM core networks.

c) The system architecture of MSC Server shall be designed as modularization, and can be expanded flexibly by cascading.

d) The Vendor shall provide detailed description of HW /SW design and architecture of MSC Server/VLR. Main requirements include:

a) System Architecture. b) Operation and Maintenance. c) Electromagnetic Compatibility Specifications. d) External Interface Specification. e) General block layout and functional layout. f) Description the way how the system works, e.g. centralized,

distribute or hierarchical control, incorporation of I/O devices, ports and buses, distribution of timing and management functions.

g) Figures of offered HW. h) List of all racks, cabinets, cartridges, modules, units, cards, I/O

devices, interfaces, power supply units, synchronization and clock

54

units, etc. the network node consists of. Description of their function in details and possible impact on service if the certain unit fails.

i) Redundancy. W hat redundancy principles are used for backing up a particular unit, e.g. hot-standby, cold standby, N+1, 2N, which units/modules/cards are/aren’t hot swappable, how does the unit switchover affect the system performance, are there any necessary restarts to activate backup unit? W hich units/modules/cards in the entity are not redundant? How their outage impacts services?

j) Explanation of the concept and redundancy of power supply for both a whole network node and individual components.

k) The hardware (card, module, unit, I/O device, etc.)MTBF per board shall be at least 15 years. If not compliant specify in detail.

l) Please provide parameters of system load as following: Start up time since the entity is powered on until full operation

(all units are fully loaded and processes traffic), state it for minimum and maximum configuration.

Shut down time since the command for shutdown has been issued in full operation until the time you can power off the device safely or it starts booting.

Reboot time for each kind of restart, e.g. total cold restart, warm restart, entity/partial/unit/card restart. Please describe also their impact on service (currently opened sessions, incoming and outgoing session requests) and differences.

6.2.1.2 Interface description and characteristics

a) The offered MSC Server shall provide abundant open standard interfaces. This implies that the Vendor shall share all necessary information with other vendors when inter-operation is required in CARRIER’s network. Any deviations from this rule shall be explicitly stated by the vendor for each network entity and interfaces described in this RFP.

b) The network elements shall provide UMTS/GSM relevant interfaces as specified in 3GPP standards. The Vendor shall depict all protocol layers for each supported interface and provide statement about compliancy with relevant 3GPP standards or other standards (RFC, ITU-T, IEEE) for each protocol layer.

c) The Vendor shall provide information and specifications on any proprietary protocols or protocol elements used on the interfaces of the proposed MSC Server.

d) The interface between MSC Server and SCP shall base on CAMEL phase3 and be backward compatible with CAMEL phase2.

55

e) The Vendor shall describe number of logical links/connections possible per one interface and whole entity, recommended/maximum load of interface that can be processed by interface unit, recommended/maximum load of fully configured entity.

f) Signaling system No.7 a) The link that transports SS7 signaling shall be capable of being

inserted in any time slot (other than time slot 0) of a 2 Mbit/s link. The capability shall also exist for more than one signaling link to be carried within one 2 Mbit/s link.

b) The Vendor shall describe redundancy techniques for the SS7 links, terminals and destination routes.

c) The Vendor shall describe the load sharing mechanisms provided between signaling links in a linkset, between signaling linksets and between signaling routes.

d) The Vendor shall also state what overload mechanisms are available.

e) The MSC Server shall support at least ISUP v2 according to ITU-T Recommendations Q.761 – Q.764 (03/93) modified by ETS 300 356-1 (February 1995).

f) The MSC Server shall support SIGTRAN protocol group: The MSC Server shall support SCTP according to RFC 2960. The MSC Server shall support M2UA according to RFC 3331. The MSC Server shall support M3UA according to RFC 3332.

g) The MSC Server shall support BICC protocol according to ITU-T Recommendation Q.1902. The BICC message can be transferred over IP transport network. The relevant protocol stack shall be BICC/SCTP/IP and BICC/M3UA/SCTP/IP.

h) The MSC Server, together with MGW, shall provide A interface to support GSM networking and MGW shall support SIGTRAN to work as Signaling Gateway to transfer the A interface signaling.

i) The Mc interface protocol of MSC Server shall be H.248, in order to promote the efficiency of message transfer; the relevant protocol stack shall be H.248/SCTP/IP and H.248/M3UA/SCTP/IP.

j) The MSC Server shall support Multi-signaling-point (Multi-SP) function to enable large-capacity offices to break the limitation of Signaling System No. 7. The maximum number of SP supported shall be up to 16.

k) The MSC Server shall support SCTP multi-homing to ensure the reliability of IP based signaling interface.

6.2.1.3 Functionality and Feature Requirements of the MSC Server/VLR

a) The MSC Server /VLR shall perform all the call control functionality,

56

mobility management, Connection Management and service provision functions as specified in the relevant ETSI GSM and 3GPP release 4 standards.

b) The MSC Server shall support the VMSC Server, GMSC Server and TMSC Server functionality.

c) The VMSC Serve’s in CARRIER’s network shall contain the VLR functionality.

d) The MSC Server/VLR shall include integrated SSP functionality in order to interwork with external SCP. The signaling shall be based on CAMEL phase 3 and compatible with previous phases to provide abundant CAMEL services. The SSP in the MSC Server /VLR shall be able to interwork with SCP from other vendors.

e) The MSC Server shall support Color Ring Back Tone functionality which is implemented based on CAMEL 4. Especially ICA and ML operations shall be supported.

f) The Vendor shall support the handling of emergency calls and state compliance with the relevant ETSI GSM, 3GPP standards and the local regulations.

g) The Core network shall support video telephony service for mobile stations supporting H.324M. If the calling party originates an unsuccessful VP call, a “USSD” will be returned immediately. Because the call originated by calling party is video one, it is impossible to play announcement directly, so the system should send a “USSD” message to notify the subscriber the release reason once the call is not connected.

h) The Core network shall support the unique identification of video telephony calls in CDRs.

i) The MSC Server shall support TrFO control function in order to improve the quality of speech as well as reduce the equipment investment of Transcoder.

j) The MSC Server shall support TFO-TrFO interworking. k) The MSC Server shall provide overload mechanisms on all interfaces and

internal systems that allows overload to occur without causing performance degradation or failure. The Vendor’s MSC Server will provide maintenance information that shows where overload occurred and the resultant impact. Mechanisms for load control and overload protection shall be stated.

l) The MSC Server shall support enhanced roaming restriction function which is based on the Zone Code, location area, roaming type and IMSI of current roaming subscriber to implement flexible roaming restriction.

m) The MSC Server shall support allocating roaming number based on location area cell or MSC ID.

57

n) The MSC Server shall support announcement based on IMSI function to let operators set an announcement language according to the IMSI of international roaming subscribers. International roaming subscribers can listen to alert tones in their native languages.

o) The MSC Server shall support the testing of a designated tones function to realize the fast availability test of the MGW and physical paths such as A-interface circuit and trunk circuit without blocking the other paths or circuits.

p) The MSC Server shall support the automatic routing of incomplete call function to reroute un-completed call to a preset number, such as voice mailbox, according to failure causes.

q) The MSC Server shall support the redundancy transmission in data services / Fax to provide a reliable transport mechanism for data services / Fax over IP bearer.

r) The system should support MNP. The Mobile Number Portability (MNP) allows Universal Mobile Telecommunications System (UMTS) or GSM mobile subscribers to change the subscription networks within a country, and to preserve the original MSISDNs at the same time. All the services of the subscriber are provided by the new network. They are not affected by the original network. The new network also assigns a new International Mobile Subscriber Identity (IMSI) to the MNP subscriber.

s) The MSC Server shall support Hybrid IP and TDM Networking and support both Load-sharing mode and Sequence mode for those two bearer. This function makes it possible to migrate from TDM to IP smoothly.

t) The MSC Server shall support Single MSISDN with Multiple IMSI(SIM card).

u) The MSC Server shall support ICA (Intelligent Call Assistant) Service. By using ICA service, roamer from other country can use same dial method or dial some special number as in it’s HPLMN. For example, roamer from Germany, they can dial Germany subscriber with same dial method in Germany. SCP will convert the short number to international number format with INT prefix(00) and return to MSC, MSC analyzes the converted number and route out.

v) The MSC Server shall support check IMEI service.

6.2.1.4 Networking Capability

a) The MSC Server/VLR shall support UMTS R4 and R5 networking. b) The MSC Server/VLR shall support integrated GSM/UMTS networking. It

can access GSM and UMTS radio access network simultaneously.

58

c) The MSC Server/VLR shall support dual-homing solution for MSC Server redundancy function. One MGW can connect to 2 MSC Servers; these MSC Servers are working in backup or mutual work mode. W hen one server has an accident, the other server controls the bearing equipment immediately.

d) The MSC Server/VLR shall support Mini-flex solution for MGW redundancy function. One RNC/BSC can connect to multiple MGWs controlled by a MSC Server.

e) The MSC Server/VLR shall support the function of multi-MGW networking. Speech path connecting between MGWs must support IP and TDM bearers.

f) The MSC Server/VLR shall support service based handover and load based handover

6.2.1.5 Performance, capacity and connectivity

a) The proposed MSC Server shall have large capacity (>= 1 million subs), high performance.

b) The Vendor shall give a description about physical and logical network element connectivity for minimum configuration.

c) The vendor is requested to fill the table of the following information for MSC Server:

Parameter Specification Maximum number of subscribers BHCA VMSC Server

GMSC Server TMSC Server

Number of SS7 signaling links

(64 kbit/s) (2 Mbit/s)

Supported SPC type Maximum number of originating signaling points

Maximum number of destination signaling points

Maximum number of IP (FE) interfaces

Maximum number of E1 interfaces (carrying narrow-band SS7)

Maximum number of controllable MGW s

Maximum number of controllable RNCs

Maximum number of controllable BSCs

59

Bill storage capacity Bill processing capability Clock stratum

6.2.1.6 Evolution Path and Characters

a) The Vender shall describe all necessary hardware and software changes associated with migration of the network element Release 4 to network element fully compliant with 3GPP Release 5/6.

b) The Vender shall describe upgrade procedure and describe out of service phases. Required modification of cooperating systems shall be stated.

c) Is it possible to migrate to 3GPP Release 5 network only via software upgrades? W hat is the performance impact of such upgrade? And will be possible use all R5/R6 features or is necessary to make any additional HW upgrades?

d) The Vendor shall describe the roadmap for this, including the integration and inter-working with the packet domain core network and ancillary network nodes.

6.2.1.7 O&M

a) The vendor shall provide Operation and Maintenance system for MSC Server with customized man-machine interface to offer fault management, configuration management, alarm management, performance measurement and security management.

b) The MSC Server O&M system can not only be controlled through the local console, but also be managed by EMS in a centralized way by accessing the local maintenance center of EMS.

c) The MSC Server O&M system shall support the following functions: d) Configuration Management:

The data configuration and database management function is used to add, delete, modify or query the configuration data necessary for system operation, as well as managing the database necessary in keeping the data consistent between host system and BAM, and in data backup. The data configuration of the MSC Server O&M system which is based on database management shall provide the following functions:

i. Offline and online data configuration ii. Remote and local data configuration iii. Data backup and restoration iv. Online upgrade v. Data verification.

e) Fault Management Fault management function helps you check, locate and fix the MSC Server system faults during its operation. In addition, useful

60

tools are available for routine maintenance of the system and against the occurrence of faults. Fault management includes the following items:

i. System self-test ii. Alarm management iii. Maintenance management.

f) Trace Management Tracing management of the MSC Server offers graphic interface. It checks data and removes faults by tracing the interface/signaling messages. Tracing management of the MSC Server shall support the functions as follows:

i. Providing message tracing of standard interfaces, such as A, C/D/E/G, Gs, Iu-CS, CAP, Mc, and Nc.

ii. The MSC/VLR shall support the feature of Specify subscriber identifier (such as MSISDN or IMSI number) at centralized network management system for tracing. All network elements (NE) replicate subscriber call messages and output them to centralized network management console. After resolution, centralized network management console displays resolution information to facilitate locating problems of whole call process Tracing messages of a designated signaling, like MTP3, MTP3B, TCAP, SCCP, BICC and H.248.

iii. Message explaining, that is, offering detailed descriptions of the messages of the interface/signaling traced.

iv. On/Off-line tracing retrieval, that is, saving the result of the message tracing to the O&M console for further use, which is accessible through either on-line query (by logging in to the local O&M system) or offline query.

g) Security Management The MSC Server system supports multiple users. For the purpose of security and convenience, the system shall support authority management and log management.

i. Authority Management The authority of operators and workstations is under the hierarchical management. In the O&M system of MSC Server, the execution of a MML command is subject to two conditions: the authority of the operator and the authority of the workstation. The command cannot be executed if any of these conditions is not satisfied.

ii. Log management It enables the querying of MML operation records. By querying the operation log, you can specify any operation has been conducted to endanger the normal operation of the system.

6.2.1.8 Standards Compliant & Multi-Vendor Support: System shall be

supported by multiple vendors. The MSC based system shall be capable of finally migrating to an all IP based Core Network. It shall be possible to upgrade the system to support HSPA/LTE.

61

6.2.1.9 Field Proveness and interoperability: The equipment shall be fully solid state, field proven and shall adopt latest state-of-the-art technology. The equipment quoted should have been field deployed commercially across multiple countries and networks and for at least two years.

6.2.1.10 The MSC based Core Network shall support Radio Network (Base

Station Controller & Base Transceiver Station) systems based on GSM & HSDPA/HSPA standards.

6.2.1.11 Dimensioning: The equipment supplier shall provide engineering

rules/guidelines for dimensioning the capacity of the network components. 6.2.1.12 The system shall optionally allow voice (or circuit data service) and packet

data service to operate concurrently (within the limits of the air interface system capacity).

6.2.1.13 The system shall support QoS parameters as defined in 3GPP Standards.

6.2.1.14 The system shall have the capability to support all the registration methods

specified in GSM standards. Pooling of resources such as vocoders, Echo cancellers etc. shall be there.

6.2.1.15 The system shall support the architecture of the GSM & HSDPA/HSPA

system in terms of different layers for specific functions conforming to the following 3GPP standards:

- Physical layer - C.S0002 - Link layer-MAC sub-layer - C.S0003 LAC sub-layer - C.S0004 - Upper layers - C.S0005

6.2.1.16 Backhaul shall be packet based. However IP based back haul shall be

highly desirable. In case of non IP based back haul such as ATM, possibility of migrating to IP in future shall be indicated.

6.2.1.17 Possibility to upgrade the system to support IPv6 protocol in future shall be

indicated. 6.2.2. Ease of Expansion: Expansion techniques of the system shall be easy,

economical and shall not interrupt a working system. Expansion shall be required when the number of subscribers (capacity) in the area is increased or when the geographical coverage is increased. The equipment shall be modular in construction permitting expansion, without any major hardware changes by simply adding shelves and modules.

6.2.3 Quality Requirements 6.2.3.1 Redundancy: The Power Supply as well as the control equipment in the

case of all components of the Core Network including the OMC shall be provided with 1+1 hot standby mode redundancy. Any other redundancy provided shall be indicated by the equipment supplier. The redundancy provided shall ensure reliability of 99.99%.

62

6.2.3.2 Automated Service Provisioning: Along with manual service provisioning, automated provisioning capabilities shall also be provided to facilitate optimal utilization of network resources and real time service provisioning (limiting human involvement to a minimum). Once a service is provided to a customer, the provisioning system shall constantly monitor its availability and quality. During an outage, it shall be possible to re-provision or provide an alternative support to the customer. Auto provisioning shall be available for both voice and data subscribers.

6.2.3.3 Design Objectives: The design objectives with regard to Quality of

Service shall meet the below mentioned statistical values under normal operating conditions :

(i) Time to connect Mobile to Mobile call: The total time for a mobile to

mobile call origination shall be less that 10 seconds for 90% of calls with the system running at rated capacity. This is the time from when the originating subscriber hits the SEND until the time that the terminating mobile receives the alert.

(ii) Time to connect Mobile to Fixed (PSTN) call: The call setup delay for a

mobile to land call shall not exceed 5.0 seconds for 90% of calls with the system running at rated capacity. This is defined as the time period from processing the SEND button to out pulse complete.

(iii) Time to connect Fixed (PSTN) to Mobile call: The time to alert the

mobile of land to mobile call shall be no greater than 6.5 seconds for 90% of mobile terminating calls which respond to the first page with the system running at rated capacity. For mobile terminated calls, it is defined as the period between the complete address information being received at the MSC from a PSTN interconnect link to the start of handset alerting.

(iv) Time to release call (RS originated – RS connection part) : The

maximum time from initiating the DISCONNECT command to when this command is passed to the called network shall be less than 2 seconds.

(v)Time to invoke or change a supplementary service : The maximum time

from initiating a Supplementary Service Request (INITIATE command) till this service has become available or changed (as requested by the user) shall be less than 10 seconds including authentication, if required.

6.2.4 Operational Requirements 6.2.4.1 Billing/Charging: MSC shall be capable of generating CDRs in AMA/ IS-

124B/ DAS/ASN.1/ASCII format for end user billing as well as inter carrier accounting details. Some of the features to be provided by the CDRs are as follows:

i. Selected Subscriber’s Dump: It shall be possible to immediately output

the CDRs for a selected subscriber after each call is completed.

63

ii. Dialed Digits: The CDR shall provide the exact digits dialed by the subscriber including # and *.

iii. Record for feature code – The system shall generate the CDR even for

the feature code dialed by the subscriber.

iv. CDR log shall be possible for an audit trail.

v. Intermediate CDR for long call with respect to time, charge etc.

vi. It shall be possible to view / access the data in the CDRs randomly as well as sequentially.

The CDRs generated by MSC/ MSCs shall be based on industry open standards and it shall be ensured that CDRs from MSC/ MSCs are fully compatible to the proposed Billing & Customer Care system (B&CCS). The MSC CDR shall be output to the Billing System on real-time basis to facilitate hot billing. The vendor shall fully describe the CDR format and required interfaces, that the MTML will pass to its B&CCS to ensure that the systems are compatible. The vendor shall clearly explain the CDR record format and will contain, at least following information.

a. originating MSC scenario b. Serving MSC scenario. c. Location ID d. record sequence number e. block number f. record type g. calling number h. calling number (MSN) i. dialed number j. called number (call forwarded number) k. start date and time (DD:MM:YYYY:HH:MM:SS) l. duration (HH:MM:SS) m. charge units/pulse n. incoming trunk group identity o. outgoing trunk group identity p. calling party category q. called party category r. supplementary services s. channel number t. bearer service u. message service v. additional service, (if any)

MSC that interconnects with PSTN & other operators shall be capable of generating CDR records for end user billing as well as inter carrier accounting details.

IARA (Inter Administration Revenue Accounting): The MSC shall have the facility to measure the incoming, outgoing and transit route-wise traffic for the purpose of Inter-Administration revenue sharing. The IARA registration shall have counters for call attempts, seizures, answers, total conversation time, average holding time etc. MSC shall generate records

64

for end user billing as well as inter carrier accounting details. 6.2.4.2 It shall be possible to transfer the billing information i.e. CDRs over X.25 or

TCP/IP links to the billing centre using any standard file transfer protocol like FTP, FTAM etc.. Any additional hardware /software if required for such an on line transfer of billing information i.e. CDRs to the billing centre shall be provided by the supplier. In addition, it shall also be possible to locally take the billing information in standard magnetic/optical media. Necessary hardware/software required to retrieve the information from the standard magnetic/optical media shall also be provided.

6.2.4.3 In order to ensure international roaming, the roamer billing standard

CIBER as specified in ANSI-41D, shall be supported. 6.2.4.4 Hand-off: The action of switching a call in progress i.e. hand-off from one

sector to another sector of same or adjacent BTS of same or different BSCs of same MSC or different MSCs of same PDSN or different PDSN shall be automatic and smooth without the user noticing it. Continuous control of call quality shall be maintained automatically to get the optimum transmission quality.

6.2.4.5 Supervision: Supervision of complete network shall be both automatic

and operator controlled and centralized at OMC. 6.2.4.6 Alarm Indications: In case of all major alarms (any event that leads to

system switch-over or service disruption) both audio and visual alarm indications shall be provided. In case of minor alarms visual alarm indications shall be provided and provision of audio alarms is desirable. It shall be possible to define the major and minor alarm conditions and set the threshold values thereof. The OMC shall provide the flexibility to forward the alarm triggered by faulty operations to a pager, a short message service system, an electronic mail or additional alarm windows on the OMC interface. The operator shall be able to redefine and configure the alarm forwarding destination. Facility shall exist for audio/visual alarm indication in the event of ‘Route Busy’, poor network performance in terms of under utilisation of BTS or too many blocked calls etc., or when the processor load exceeds a certain preset value. Alarm indication shall exist in the event of fan failure.

6.2.4.7 Fraud Management: The system shall be capable of prohibiting the use

of stolen units or use by unauthorized callers. For this, the OMC shall provide fraud management tools with all necessary features.

6.2.4.8 Security: The system shall provide confidentiality, subscriber

authentication features and high security. Latest digital encryption technology to support secure communications for message and voice privacy shall be provided.

6.2.4.9 Announcements/ Prompts: Provision shall be available for

announcements to give information regarding the following: - (i) Barring service (ii) Absent subscriber service (iii) Changed number service

65

(iv) Closure of service (v) Service not available etc.

Electronic device with recording facility shall be provided in the MSC. The announcement device record at least 100 messages each of 20 seconds long. It shall be possible to connect the announcement message for an operator defined time or indefinitely. It shall also be possible to deliver messages of longer duration. The announcement device will be working in 1+1 active and standby configuration. If the main unit fails, the standby unit shall automatically switch over to active mode. The vendors shall indicate the details about how many subscribers can hear the message simultaneously. The announcement device shall be provided with recording, storing and playback facility. The recording facility shall include microphone, audio storing facilities and distribution facilities and medium (disk, tape etc.) so that recorded announcement can be transferred to several announcement machines without multiple recordings.

6.2.4.10 Synchronization: The system shall have integrated synchronization

equipment with a layer 2 clock, i.e. with a minimum clock stability of 1x10 -

10 per day. The acceptable slip rate shall be in accordance with ITU-T Recommendation G.822.

6.2.4.11 Carrier Selection: The subscriber shall have the flexibility to choose

the carrier for international long distance calls. The system shall support both carrier pre-selection (through System Administrator) and carrier selection on a per call basis (subscriber controlled). The equipment shall support at least 24 digit dialing. The maximum number of digit- dialing that can be supported may also be indicated.

6.2.4.12 The equipment supplier shall provide detailed information regarding extent

of implementation in his equipment, to support international roaming w.r.t. all issues related to International Roaming, such as numbering issues, dialing issues, signaling issues, Fraud issues, Billing issues, Services issues and other miscellaneous issues, as per standards.

6.2.4.13 Connectivity/ Interconnectivity: It shall have capability to be connected

to various elements. The core network shall be capable of interfacing/ interconnecting with all the existing & future networks of other fixed line/ mobile/ International Long Distance Operators’ Switches and transmission equipment based on Standards currently existing. The vendor shall make provision of adequate numbers of E1 ports for catering to the interconnection requirements with various networks for the 100K subscribers in first year, upgradable to cater requirements for ultimate capacity of 200K subscribers.

6.2.4.14 The MSC/VLR shall support the following functions besides the

conventional functions provided for switching equipment.

(A) Call processing

66

(i) MSC shall support outgoing call, incoming call, and transit call. It shall process outgoing call and incoming call for all legal subscribers within its covering area, and provide corresponding services for each subscriber as per user profile in HLR.

(ii) It shall be able to provide functionality of Gateway MSC (GMSC). (iii) It shall be able to provide functionality of Mobile tandem. (iv) In case of TAX call connection, MSC shall be able to provide calling

number and calling number attribute to TAX or other MSC. (v) It shall be able to provide functionality of STP. (vi) In addition to normal switching function, the MSC shall provide

Integrated Service Switching Point (SSP) functionality for supporting the Intelligent Network (IN) services.

(vii) It shall support malicious call tracing. (viii) It shall play voice announcements in case of user busy, user

unreachable etc. It shall be able to provide up to 100 voice announcements.

(ix) It shall support access to various service station/desk, capable of choosing the nearest emergency call center to connect.

(x) It shall be able to perform DTMF signal conversion. (xi) It shall support Either Party release. (xii) It shall automatically perform number upgrading (increasing the

number of digits of MDN). (xiii) It shall support Call admission feature for overload control.

(B) Number storing and translation

(i) Receiving and storing up to 24 digits. (ii) Number inserting, deleting and translation. (iii) Number delivering: supports group delivering or overlap delivering. (iv) Capable of handling different lengths of numbers within one area. (v) Supports various numbering systems (vi) It may support Global Title Translation (GTT).

(C) Time Monitoring and Forced Call Release: The MSC switching equipment shall contain a time monitoring device, which monitors various connection status. W hen the monitoring time limit is reached, it shall immediately force to release the circuit and send the busy tone (or instructions) to the related subscriber, or establish corresponding connection in accordance with various connecting status.

(D) Route selection functions

(i) It shall be possible that the number of trunk routes and the number of

circuits of each route can be assigned according to the requirements and can be changed by man-machine commands.

(ii) MSC shall have capability of selecting direct routes or alternative routes and avoiding circuitous route.

(iii) It shall have capability to analyze up to 24digits of number and then decide the route selection.

(E) Echo cancellation: It shall provide Echo cancellation for calls to/from

PSTN. It shall control the access of echo canceller and indicate the subsequent exchanges to access the echo canceller or not.

67

(F) Overload control functions: The system shall have capability to detect

following overload conditions and apply overload mechanism:

(i) Access overload control: The MSC shall work within RN to prevent occurrence of access overload. The MSC shall be capable of gradually and automatically restricting the access of normal call with the restricted calls and distributed among all subscribers evenly. Overload control shall not break on-going call.

(ii) Internal overload control: The system shall provide overload control by

means of man-machine commands with an adjustable controlling rate.

(G) Mobility management functions: MSC shall be able to support the following types of handoff:

Inter BSC soft handoff within a MSC. Inter BSC hard handoff within a MSC. Hard handoff between different MSC (including inter carrier handoff

between MSCs supplied by different vendors) Soft hand-off intra-BSC

(H) Registration

(i) MSC/VLR shall be able to support registration and de-registration in all

cases as specified in GSM standards. (ii) It shall support domestic and international automatic roaming for

subscribers using equipment of various vendors. Roaming shall not affect the services provided to subscribers.

(iii) When a Mobile subscriber appears in a new location area, or when a registration, call setup or supplementary service operation message is received from the Mobile, the system shall send a registration notification to the HLR.

(iv) It shall be possible that if a subscriber does not appear in the MSC/VLR area within 24 hours or as required by HLR, the VLR can delete the data pertinent to this subscriber, and notify the HLR.

(v) It shall have provision for time based registration. W hen related timer expires, no registration and call processing shall be possible for this RS and VLR shall perform de-registration for this RS.

(vi) MSC shall give an alarm when ‘unknown subscriber’ or ‘illegal subscriber’ appears in the registration message. It shall also print out a report & maintain a log for errors such as “authorization denied”.

(vii) MSC shall be able to support Mobile inactive function.

(I) Security and authentication: The following features are applicable in case of integrated HLR only:

(i) Authentication and SSD updating during registration, call connection,

supplementary service processing. (ii) The possible occasions for authentication implementation in CDMA

system are as follows: - Registration - RS origination - SSD (shared secret data) update

68

- RS termination - Data burst

(iii) The authentication algorithm is authentication part of Cellular Authentication and Voice Enciphering (CAVE), Enhanced Cellular Message Encryption Algorithm (ECMEA) / Encapsulating Security Payload (ESP) / Advanced Encryption Standard (AES)

(iv) If MSC receives some error such as ‘deny access’, MSC shall print out a report & maintain a log of such errors.

(v) Subscriber information encryption shall be provided.

(J) Resource management: MSC shall have following features: (i) Responsible for assigning selected circuit time slots between BSC and

MSC. (ii) Indicating the type of wireless channel suited for different processing

phases to Radio Network(RN) (iii) Receiving and processing RN blocking-circuit, RN resetting-circuit

messages. (iv) Sending resetting-circuit message to RN. (v) Receiving and processing resetting message. (vi) Sending resetting message to RN.

6.2.4.15 Numbering Requirements

a) The system shall adhere to the latest local numbering requirements. At present, seven digit numbering scheme is applicable for both mobile & fixed telephones which is likely to be upgraded to 8 digits in near future. As such system should be flexible for adopting any number digit length in any format as per international standards applicable.

6.2.4.16 Inter Working Facility (IWF)

The vendor shall provide the feature interactions when a mobile is in circuit switched data mode e.g. availability of call waiting, voice mail notification etc.

V.42 compression should to be supported for more efficient use of the RF links.

Both RS originated and terminated calls for asynchronous data and Fax services shall be supported .

6.3 MEDIA GATEWAY i) Media Gateways shall comply with 3GPP standards and should support all

international signaling standards so that the international calls and SMSs are successful.

ii) Standalone signaling gateway shall be provisioned. ii) The bill of materials provisioned by the bidder shall provide full flexibility in

determination of price model for any mix of 2G and 3G subscribers. The same shall be utilized by MTML while ordering equipment for Phase-I & II.

69

iii) In MEDIA GATEWAY, CDR module capable of monitoring the parameters like rate of transfer of CDR, rate of hourly generation of CDRs, on-line back up on storage media in case of link failure or congestion should be provided.

iv) Media Gateway shall have an integrated announcement server supporting

minimum 1024 announcements & 256 tones. 6.3.1 Hardware and software design

a) The MGW in CARRIER’s combined UMTS/GSM network shall conform to all relevant ETSI GSM and 3GPP release 4, Release 5 specifications. The Vendor shall list and give compliance statements to relevant ETSI GSM and 3GPP specifications for the support of GSM and UMTS circuit switched services and the integration with GPRS and UMTS packet domain networks.

b) The HW platform of proposed MGW shall be the common and mature platform which can be used in NGN, W CDMA/GSM core networks.

c) The system architecture of MGW shall be designed as modularization, and can be expanded flexibly by cascading.

d) The Vendor shall provide detailed description of HW /SW design and architecture of MGW. Main requirements include:

i. System Architecture

ii. Operation and Maintenance

iii. Electromagnetic Compatibility Specifications

iv. External Interface Specification

v. General block layout and functional layout.

vi. Description the way how the system works, e.g. centralized, distribute or hierarchical control, incorporation of I/O devices, ports and buses, distribution of timing and management functions.

vii. Figures of offered HW.

viii. List of all racks, cabinets, cartridges, modules, units, cards, I/O devices, interfaces, power supply units, synchronization and timing units, etc. the network node consists of. Description of their function in details and possible impact on service if the certain unit fails.

ix. Redundancy. W hat redundancy principles are used for backing up a particular unit, e.g. hot-standby, cold standby, N+1, 2N, which units/modules/cards are/aren’t hot swappable, how does the unit switchover affect the system performance, are there any necessary restarts to activate backup unit? W hich units/modules/cards in the entity do not have redundancy? How their outage impacts services?

x. Description of typical layout of racks, cabinets, cartridges, modules, units, cards, I/O devices, interfaces, power supply units, synchronization and timing units, etc.

xi. Explanation of the concept and redundancy of power supply for both a whole network node and individual components.

xii. MTBF characteristics for each hardware component (card, module, unit, I/O device, etc.).

70

xiii. Please give us those parameters:

Start up time since the entity is powered on until full operation (all units are fully loaded and processes traffic), state it for minimum and maximum configuration.

Shut down time since the command for shutdown has been issued in full operation until the time you can power off the device safely or it starts booting.

Reboot time for each kind of restart, e.g. total cold restart, warm restart, entity/partial/unit/card restart. Please describe also their impact on service (currently opened sessions, incoming and outgoing session requests) and differences.

xiv.Description of software architecture in terms of running OS (operating system) and running SW modules and packages.

xv. Description of software upgrade procedure and correction (patch) installation. Is it necessary to replace whole running package or only certain pieces of software may be upgraded/patched?

xvi.How is the node configuration and hardware setup stored? Is there any centralized configuration file or are there multiple files to save it? Is there any choice to select configuration file/files during booting up the node if there are archive configuration files stored in I/O device?

xvii. How is the software fallback created? How long does the procedure take? Is fallback only for the whole node or it is possible to perform fallback per unit/module/card?

e) The proposed MGW shall be GSM/UMTS converged, packet processing unit based on Network Processor, TDM switching shall be native without TDM to IP conversion in order to reduce the delay and jitter for GSM TDM switching.

6.3.2 Interface description and characteristics

a) The offered MGW shall provide open standard interfaces. This implies that the Vendor shall share all necessary information with other vendors when inter-operation is required in CARRIER’s network. Any deviations from this rule shall be explicitly stated by the Vendor for each network entity and interfaces described in this RFP.

b) The network elements shall provide UMTS/GSM relevant interfaces as specified below. The Vendor shall depict all protocol layers for each supported interface and provide statement about compliancy with relevant 3GPP standards or other standards (RFC, ITU-T, IEEE) for each protocol layer.

Interface

Connected entitie

Singal and Protocol

Bear Type

Physical Port

71

Iu-CS MGW —RNC IP FE/GE

Mc MGW-MSC Server IP FE/GE

Nb MGW —MGW IP FE/GE

Nb UP MGW —MGW IP FE/GE

A MGW-BSC IP FE/GE

ISUP MGW-PLMN/PSTN TDM E1/STM-1

PRA MGW-PBX IP/TDM FE/E1 c) The Vendor shall provide information and specifications on any

proprietary protocols or protocol elements used on the interfaces of the proposed MGW.

d) The vendor shall provide UMTS relevant interfaces as specified in 3G TS 23.002. The vendor shall depict all protocol layers for each supported interface and provide statement about compliancy with relevant 3GPP standards or other standards (RFC, ITU-T, IEEE) for each protocol layer.

e) The Mc interface shall comply with 3GPP TS 29.232 and the stack shall be H.248/SCTP/IP.

f) The proposed MGW shall provide ATM over E1 function in Iu-CS interface.

g) The MGW shall support Nb interface over IP and TDM. The vendor shall state the protocol stacks of each type of bearer.

h) The MGW shall support Multi-signaling-point (Multi-SP) function to enable large-capacity offices to break the limitation of Signaling System No. 7.

i) The proposed MGW shall support ATM cross-connection using for Iu-PS transport from RNC to SGSN through MGW.

j) The proposed MGW shall support ATM cross-connection using for Iur transport between two RNCs through MGW.

k) The MGW shall provide FE and GE for Nb interface, the GE based Nb interface shall work on the load-sharing mode to lower the risk of peak traffic.

l) The MGW shall support SIGTRAN, including M2UA, IUA, M3UA (including both transfer mode and agent mode), to network flexibly.

6.3.3 Functionality and Feature Requirements of the MGW

a) The proposed MGW shall interact with MSC Server for resource control, and support the following networking applications: i. Serving as the (G) MGW with a (G)MSC Server in a GSM core

network

72

ii. Serving as the bearer device in a UMTS R4 network

iii. Networking as IM-MGW in IMS domain

b) In the event of A interface ,The transcoders in the proposed MGW shall support the following GSM codec: i. GSM FR - GSM Full Rate (13.0 kbit/s)

ii. GSM EFR - GSM Enhanced Full Rate (12.2 kbit/s)

iii. FR AMR - Full Rate Adaptive Multi-Rate

iv. HR AMR - Half Rate Adaptive Multi-Rate

c) In the event of PSTN interface, The transcoders in the proposed MGW shall support the following codec: i. G.711 ц-law and A-law (64 kbit/s) ii. G.723 (5.3 kbit/s)

iii. G.726 (40,32,24,16 kbit/s)

iv. G.729 (8 kbit/s)

d) The transcoders in the proposed MGW shall support all the 8 types of rates range form 4.75kbps to 12.2k bps of AMR, AMR2 and W B-AMR.

e) The core network shall support fax bearer service. Fax services are applied in the GSM or the UMTS network, including automatic fax and alternative voice/fax service. They allow category-3 facsimile apparatus to connect with the mobile station (MS) of the GSM PLMN, and to set up fax connection between the PSTN/ISDN and the GSM PLMN or within the GSM PLMN.

f) In the proposed MGW, appropriate measures for overload protection have to be implemented. The measures shall guarantee a satisfactory performance of the network entities in an overload case.

g) The core network shall support TFO (Tandem Free Operation). The TFO implementation shall support the EFR, AMR and FR codec.

h) The core network shall support TrFO (Transcoder Free Operation). The vendor shall state in detail how it is implemented in the proposed MGW.

i) The core network shall support TFO-TrFO interworking. The vendor shall state in detail how it is implemented in the proposed MGW.

j) The proposed MGW shall support Voice enhancement function voice quality promotion ,e.g. EC(Echo Canceller or Control), AEC(Acoustic Echo Control), VAD, BNR, CNG, DJB, EFC, GC, LPC and NS.

k) The MGW shall support Embedded Signalling Gateway function which supports MTP3b-M3UA, MTP2- M2UA and MTP3-M3UA adaptation and forwarding

l) The MGW shall support the H.248.11 overload control protocol and the H.248.10 congestion control protocol to realize the self overload

73

protection function. m) The MGW shall support RTP header multiplex which is defined in ITU-T

G.769 and Y.1242. n) The MGW shall support DTMF over IP function which is based on RFC

2833. 6.3.4 Networking Capability

a) The proposed MGW shall support UMTS R4 and R5 networking. b) The proposed MGW can work as VMSC, GMSC and TMSC in GSM and

UMTS network. c) The proposed MGW shall support integrated GSM/UMTS networking. It

can access GSM and UMTS radio access network simultaneously. d) The proposed MGW shall support Nb interface based on IP bearing as

required by the actual transmission network in the following scenarios, and provide FE、GE、POS hardware interface.

i. Acting as 2G TMSC, MGW supports G.711, G.723, G.726, G.729 and AMR over IP.

ii. Acting as 2G VMSC, MGW supports G.711 and AMR over IP.

iii. Acting as 3G V/GMSC, MGW supports G.711, AMR and AMR2 over IP.

iv. Acting as 2G/3G G/TMSC, MGW supports that identifying and converting 3.1 K audio speech to AMR/AMR2 over IP.

e) The proposed MGW shall support adapting satellite transmission at Mc and Nb interface. This feature enhances the networking flexibility of MGW. And it enables MGW to fit various geographical environments and cover a long distance.

f) The interface for SS7 over IP can be dedicated FE interface or be together with the IP-based Nb interfaces, such as FE, GE, STM-1 POS or STM-4 POS. It has no constraints on the use of node interfaces. The interface for SS7 over IP implements 1+1 backup configuration.

6.3.5 Performance, capacity and connectivity

a) The proposed MGW shall have large capacity (>= 70k Erl) and abundant of interfaces.

b) The Vendor shall give a description about physical and logical network element connectivity for minimum configuration.

c) The vendor is requested to fill the following information for MGW:

Interface Type Physical interface Number of Ports

TDM E1 STM-1

74

ATM E1 STM-1

IP

FE GE POS 155M

POS 622M

6.3.6 Evolution Path and Characters

a) The proposed Media Gateway shall comply with the 3GPP R4 and shall be able to migrate to release 5 and 6 by re-utilization of the existing platform. In case of additional Hardware and Software being required for migration to release 5 and 6, the vendor shall state the need in detail.

b) The vendor shall describe all necessary hardware and software changes associated with migration of the network element Release 4 to network element fully compliant with 3GPP R5/R6.

c) The Vendor is request to describe how Media Gateways can be used in IMS architecture. In case of additional Hardware and Software being required, the vendor shall state the need in detail.

6.3.7 O&M

a) The vendor shall provide Operation and Maintenance system for MGW with customized man-machine interface to offer fault management, configuration management, alarm management, performance measurement and security management.

b) The MGW O&M system can not only be controlled through the local console, but also be managed by EMS in a centralized way by accessing the local maintenance center of EMS.

c) The MGW O&M system shall support the following functions: d) Device Management

i. The graphical interface shall be supported; device configurations, board cascading situation, board status and power distribution status can be viewed through GUI. Through right-mouse menu operations, the operator can query, display, switch, reset, isolate, block and activate boards and interfaces.

ii. MML commands shall be used to manage hardware, system resources, signaling links, clock system and physical ports of the MGW.

e) Data Management The data configuration and database management function is used to add, delete, modify or query the configuration data necessary for system operation, as well as managing the database necessary in keeping the data consistent between host system and BAM, and in data backup.

75

The data configuration of the MGW O&M system which is based on database management shall support the following functions: i. Offline and online data configuration ii. Remote and local data configuration iii. Data backup and restoration iv. Online upgrade v. Data verification.

f) Alarm Management The function is to receive and deal with alarms. According to the alarm type and level, the alarm terminal (for example, an alarm box or the alarm management system) delivers the corresponding voice and optical signals, and sends the translated alarm information to the network management through. In addition, the function also enables to save alarm information, display history alarm records and set alarm processing way.

g) Environment and Power Supply Monitoring The function is to monitor and control the environment, power supply and other intelligent devices in the central or remote equipment room even when no one is on duty.

h) Security Management The MGW system supports multiple users. For the purpose of security and convenience, the system shall support authority management and log management.

i. Authority Management The authority of operators and workstations is under the hierarchical management. In the O&M system of MGW, the execution of a MML command is subject to two conditions: the authority of the operator and the authority of the workstation. The command cannot be executed if any of these conditions is not satisfied.

ii. Log management iii. It enables the querying of MML operation records. By querying the

operation log, you can specify any operation has been conducted to endanger the normal operation of the system.

6.4 Wireless Intelligent Network (WIN) 6.4.1 MTML presently has Huawei make IN dimensioned for 100K CDMA

subscribers. Existing, Huawei make IN is planned to be replaced with a common IN which should handle both CDMA & GSM subscribers. The new IN equipment shall be dimensioned accordingly with one Voucher Management System (VOMS) for existing as well as new IN. The new IN should be dimensioned with a provision to serve 100% subscribers of this tender as pre paid and all 110k CDMA subsricbers. The responsibility of migrating the data of old IN to new IN lies with the successful bidder. The bidder, if feasible, can use the existing IN hardware/ software. W hile migrating/ integrating it is to be ensured that the services currently running are not affected and customers don’t see outage.

76

6.4.2 The bidders also have the option to expand and upgrade the existing IN for

providing CDMA/ GSM/3G services seamlessly to the existing as well as new capacity, with the modified features to all customers.

6.4.3 Design Aspects:

a) Traffic Profile for IN subscribers same as post paid subscribers. b) Common IN for GSM, CDMA and HSDPA/HSPA.

c) The IN solution proposed by the bidder should be expandable to at least 310K

subscribers.

d) Voice and data services including pre-paid roaming between IN platforms supplied by different vendors should be supported.

e) The SCP shall be able to cater to multiple MSC SERVER AND remote MEDIA

GATEWAYs from different vendors without any limitations. f) Pre paid Data service should be supported and should provide content

charging function such as charging by volume, charging by content etc. g) New common VOMs for existing capacity 1 million vouchers + new 2 million

vouchers (Total 3 million vouchers) in active/ idle state should be supported. There should not be any limitation of the total vouchers/ PINs used. The used vouchers should get deleted and capacity created for new vouchers.

h) Voucherless recharge feature (E-PIN) based on ATM, SMS, USSD, W eb

etc. should be provided including server & related H/W as required & interfaces.

i) All features/ services available in current IN should be provided in the new IN also.

6.4.4 The CCS7 links should be suitably dimensioned to take care of signaling load

as per tender requirements. 6.4.5 New IN platform should be configured as separate SDP , SCPs , OCS for

ease of expansion. 6.4.6 All the new IN platforms and SSPs shall work with CAMEL Phase III &

Diameter protocol upgradable to CAMEL IV. Online charging of all services including MMS should be available from date of commissioning of network.

6.4.7 The Voucher Management System (VoMS) may be integrated with IN or may

be on a separate server with capability to interface with TCP/IP and SS7. It shall provide facility for topping-up of the pre-paid account over-the-air in conjunction with the proposed OTA server or ISO 8583 interface. The bidder shall ensure that the OTA server/IN system interfaces with Credit card clearing house, ECS etc with whom MTML has an agreement for payment realization and update the customer account in VoMS/IN with appropriate

77

credit. All such transactions shall be implemented with secure signatures from the SIM and signature validation by the OTA server.

6.4.8 The pre-paid service shall be IN based supporting over the air charging by the

subscriber compliant to 3GPP. Prepaid services shall contain service bonus function including preferential rate, free discount or free SMS based on accumulated usage, monthly usage or the time in network. It shall be possible to provide any combination of unprohibited teleservices and supplementary services, WAP services, SMS, MMS, GPRS and EDGE etc to the pre-paid subscribers and charge them ON-LINE as per the prescribed tariff. ON-LINE charging shall be in real time and shall do differential charging based on the customer category, destination number and also based on the content provided by the SMS & MMS content providers. It shall also interface with the GMLC or LBS application server for the location based services to the prepaid-subscribers and ensure online charging of such subscribers. The system shall ensure that adequate balance is available in the account of the pre-paid subscriber before the service is provided. The bidder shall provide all necessary components required for IN based prepaid service including IVRS. The IVRS shall be provided in 4 (four) languages namely English, French, Mandarine and Hindi. The customer should be given an option to select the language and set it for all calls by dialing a short code. It should support prepaid roaming both national and international. The pre-paid service should have data security features for fraud prevention. The pre-paid service application should be able to determine the duration of the call to the nearest of the 1sec and update the subscriber's account on real time basis to record the new available balance. It should be able to notify subscriber regarding low balance during session or in the beginning as per the case. It should also be possible to send sms notification for a defined low balance.

6.4.9 Accounting of all IN services shall be in the IN system and it shall be possible

to send the Consolidated Accounting information (CDR) to B&CCS for the purpose of reconciliation and compilation of accounts.

6.4.10 The system shall provide all necessary data required for scratch cards. The

scratch card data shall be protected against all type of frauds. Encryption/ decryption software shall be provided by the bidders.

6.4.11 Full flexibility of change in recharge voucher value and validity from front end

any time after loading on the IN platform should be available. 6.4.12 IN and MSC SERVER should be capable of providing traces in SCP as well

as signaling side for troubleshooting and monitoring.

6.4.13 The proposed IN solution shall support following broad features :

Prepaid service (PPS) both voice & data Friend & Family Number (F&F) Closed user group (CUG) Virtual private Network (VPN) Premium Number (PRN) – numbers on which the calls are to be

charged at higher rates International prepaid dialing for other network numbers

78

Account calling card – any customer (of any operator) can use this to create his prepaid account for International calls

E-PIN/ E-TopUp Tele-voting services

A. PPS – Basic Features

- Password Modification - Multi Language support - Black list - Claim of missing/missing claim dismiss - Balance Inquiry - Low balance alarm - Voice prompt - Real- time charging - Real time charging for SMS/MMS - Account recharge - Charging notification - Help desk Calling - Call barred - Call forwarding - Electronic recahring through internet

B. PPS – Advanced Features

- USSD recharge/query/transfer - SMS recharge/query/transfer - DTMF recharge/query for third party recharge - Bonus status query - Class of service - Volume/duration based online data service charging - Intra- MSC roaming - First – call greeting - Daily / weekly/ monthly deduction of some amount for any specified

package tariff of voice/ SMS/ VMS/ GPRS/ MMS etc. - Friend & Family number - Pre- paid home zone - Charging for Pre- paid CRBT service - Multiple bonus offering - Flexible status definition - USSD callback - Deactivation of account if no call is made/ received for a particular

duration or no recharge takes place in the specified period. - Different tariff plans for charging with different recharge coupons - Recharge coupons only for the specified services like SMS/ VMS/

MMS/ GPRS etc.

C. Bonus and packages - Monthly flat fee with/without usage limitation - Expenditure/duration based graded discount - Expenditure/duration based package - Timed prepayment consumption e.g. 100 minutes of on-net calls

free on topup of a specified amount - Installment for mobile phone i.e the charges for mobile phone to be

reduced from the customer account in defined monthly installments

79

- Free call numbers - Pre- load in new card - Number segments based rate - Bonus on Account creation - Bonus on Account activation - Bonus on Recharge operation - Bonus on Amount of recharge - Bonus of Number of recharge - Bonus on Expenditure accumulation for outgoing calls - Bonus on total incoming call duration - Bonus on number of SMSs/ MMSs sent in a period - Bonus on data usages volume - Bonus on Life time accumulation - Point bonus - Special date bonus (e. g, birthday ,festivals) - Any Bonus can be either a fixed amount or percentage of the

recharge value and can be restricted only for the use of voice/ data/ SMS/ MMS etc either in own network calls or all calls.

- Bonus should be possible to be credited over a period of the specified duration in equal installments.

- Bonus is based on individual definition. It can be set according to some certain conditions defined by operator.

D. USSD Short Number

- For Recharging - For Balance querying - For Balance/ credit transfer

E. Credit Transfer via SMS/USSD - Subscriber can transfer his balance to other user via SMS/USSD

F. Class of Service (Brand)

- Pre-customizing user brands for different groups. - The brands differ in charging plans, call limiters, call rights, etc.

G. Master – Slave Account - One master account can have some associated slave accounts. - Slave accounts can not have their slave accounts again. - If slave account runs out of money, the call charges will be

deducted from his master account with the allowed limit. - Master account can transfer part of his balance to his dedicated

slave accounts. - When master account deregisters, the remained money in slave

accounts should be returned, and slave accounts be deleted.

H. Prepaid Home Zone Different tariff based on

- Different time - Different geographic location

I. Cell and Time Charging

- Subscribers can be charged flexibly according to the calling time (time) and the locations of the calling/called party (Cell).

80

- It is mainly used to implement discount tariff for some areas/time

periods with Lower traffic, thus encourage them to call at the time/area.

J. Tariff Packages

- Monthly/ weekly/ Daily Flat Fee with/without Limitation Voice (local, national or whole voice services) SMS/ MMS

Data/ GPRS - Discount

Voice ( local, national or whole voice services ) SMS/ MMS Data/ GPRS

K. Customer Categories – Various customer categories should be available wherein different tariffs are applicable. The customer category can be changed by recharging with any predefined special recharge voucher.

6.4.14 In case of VPN, there shall not be any restriction on the number of VPN accounts that can be created. The size of the VPN group can be as small as two and can be as large as the total capacity being ordered. All the bonus packages mentioned above should be applicable for VPN subscribers also.

6.4.15 The system shall provide all necessary data required for scratch cards. The

scratch card data shall be protected against all type of frauds. Full arrangements for random number generation/ encryption should be made. The system should support atleast one million active recharge PINs at any given point of time. There should not be any license limit for total number of scratch cards/ PINs generated and loaded in the system. Each recharging card has its own period of validity and the period expires, all the documents of the recharge card shall be cleared. The system shall allow the user to set the valid period of the mobile phone number. W hen the account balance is zero, the phone number is kept within the valid period, during which the user has to recharge the account or the documents shall be cleared. The subscriber can buy a recharge card and recharge their account by USSD or IVR by dialing a public number. The third party recharge through IVRS is also to be provided.

It shall be possible to put limitations on the prepaid subscribers: Limit on roaming: the subscriber is not permitted to roam to some

predefined locations; Forbidden prefix: called numbers with certain prefix are forbidden to

dial; Lock on incoming calls: the incoming calls can’t be picked up; Lock on outgoing calls: the outgoing calls can’t be made; Limit on user configuration;

The subscriber can buy the recharge card anywhere as long as the relationship between service providers is formally established. All records will be available from the system to facilitate settlement among different service providers;

81

The prepaid user shall be able to use a short number to call the operator for assistance, resembling the function of a customer service center. The user shall be able to dial a short number by the mobile phone and shall tell promptly the capital remained. The system shall be able to set a certain numbers as the free call such as the recharging number. The system must be capable of “partitioning”, to allow different category of the prepaid system, such as corporate users groups like hotels, business enterprises. Each category of customers may have a different tariff plan. The system shall be able to notify callers of balances remaining on the account in terms of monitory units or time, before the call is placed and after the end of the call through SMS. The system shall generate break in warning messages 2 minute and 1 minute and at the balance depletion point, before the call is ended. The prepaid shall support both rechargeable and non rechargeable prepaid account. The prepaid shall support the use of pre-defined rechargeable cards. Consequently interfaces to financial institutions e.g. bank shall be supported. Rate shall be selected based on local, trunk, international, inter-operator, regional codes. All data, operational and historical shall be maintained in a standard database management system allowing use of a wide range of query and report packages. The offered prepaid system shall support 10 workstations with possible extension of 40 workstations which shall serve as customer care terminal. The user interface must be user friendly and provide the interface to various reports on individual and group accounts (like detail account information, account balance, call history data). The interface shall work on standard GUI based software. The system shall generate at least following traffic statistics. Various other reports and their formats would be prescribed to the vendor, as per requirements and shall have to be provided.

numbers of calls per prepaid number average call duration holding time per subscriber during busy hour average call duration per subscriber number of call unsuccessful due to system number of call unsuccessful due to caller

The system shall generate at least following Application specific statistics.

number of times each menu/command selected.

82

Number of erroneous caller entry Number of times each language item is played. Number of times messages are played.

Apart from the availability of prepaid services, as above, to the purchaser’s GSM & CDMA customers, necessary provisions shall be made by the contractor to provide scratch card based prepaid services to customers of other fixed line & mobile operators such as prepaid international long distance service. These customers should also be able to use the same recharge card. This is a mandatory requirement.

6.4.16 E-Top Up/ E-PIN: This system should be provided to enable paper less recharging. The E-PINs would be transferred from one distributor to a retailer and finally to customers through SMS/ USSD. Proper security checks should be done to avoid fraudulent cases.

6.4.17 There would be only one type of recharge cards generated in the system which are to be used for all prepaid services viz. CDMA, GSM and Internation Calling Cards.

6.5 HLR/AUC 6.5.1 MTML presently has Huawei make CDMA HLR diamentioned for 110K

Subscribers. Existing HLR should be suitably upgraded and integrated with a new HLR of capacity as envisaged in this tender to provide 2G & 3G services seamlessly to the existing CDMA subscribers as well as new subscribers. The new HLR shall be dimensioned accordingly. The responsibility of interworking of new HLR with existing HLR of MTML / other network lies with the successful bidder.

6.5.2 Alternatively, the successful bidder may replace the existing HLR with new

HLR of higher capacity which will include existing HLR capacity. In this case, the migration of existing HLR capacity to the new HLR will be the responsibility of the successful bidder.

6.5.3 The bidders also have the option to expand and upgrade the existing HLR

for providing 2G/3G services seamlessly to the existing as well as new capacity.

6.5.4 Home Location Register (HLR) serves as the primary database repository

for subscriber information that is used to provide control and intelligence within mobile networks. Mobile subscriber profiles, locations and activities, and information about supplementary subscriber services are all seamlessly managed for the Mobile operator by the HLR. The HLR contains a record of each subscriber who has subscribed to a Mobile telephony service within the home area. One HLR can serve one or more MSC. HLR stores the related information of subscribers such as ESN, MDN, IMSI, MIN, selected services, current location, and authorized effective period etc.

Authentication Center (AUC) is the primary repository for managing and processing authentication information used to verify and validate a Mobile identity within networks. This information consists of security and

83

authentication features, as well as complex validation algorithms, which enable authentication procedures used to prevent fraudulent use of network resources. The AUC also incorporates database functions used to store the encryption and authentication. One AUC can serve one or more MSC via one or more HLR, which serves as gateways. The functional entity of HLR/ AUC may be physically integrated with logical separation or it can be stand alone HLR/AUC. All requirements mentioned in this clause for HLR/AUC are applicable to both stand alone HLR (S-HLR) and Integrated HLR (I-HLR) unless it is specifically mentioned otherwise. HLR/AUC shall be developed based on 3GPP standards, providing open interfaces.

Equipment Identitiy Register (EIR) will form part of the system for blacklisting the stolen mobiles and should be provided as per GSM standards.

6.5.4 General Requirements

This specification sets out the requirements to be met by the Bidder to provide all Equipment, including hardware, software including related services of GSM/UMTS HLR/AUC in accordance with the Relevant Standards and Recommendations and the Specifications stated herein. The vendor’s solution will have to support: a) The Bidder shall provide an Operation and Maintenance Centre

(OMC) as part of System and shall interconnect and integrate with existing Network Management System (NMS).

b) The Proposed HLR/AUC products shall have large capacity with high density in order to save the Carrier’s CAPEX and OPEX. Furthermore, the products shall be distributed designed and have reasonable flexibility for the future capacity expansion.

c) The proposed HLR/AUC shall support the carrier network based on TDM and IP.

d) The Bidder shall list all the outsourcing HW and SW .

6.5.5 Hardware and software design

a) Systems with a distributed architecture that features a centralized database and service logics separated from the database and the FE should be data-less.

b) The following Service Logics must be supported currently or at roadmap as separate features: HLR HSS SAE HSS EIR AAA

84

c) The HW platform of proposed HLR shall be the common and mature platform which can be used in Mobile soft-switch, packet switch, IMS-CSCF and SAE.

d) The system architecture of HLR shall be designed as distributed, and can be expanded flexibly by cascading.

e) The Vendor shall provide detailed description of HW /SW design and architecture of HLR. Main requirements include: i. System Architecture ii. Operation and Maintenance iii. Electromagnetic Compatibility Specifications iv. External Interface Specification v. General block layout and functional layout. vi. Description the way how the system works, e.g. centralized,

distribute or hierarchical control, incorporation of I/O devices, ports and buses, distribution of timing and management functions.

vii. Figures of offered HW . viii. List of all racks, cabinets, cartridges, modules, units, cards, I/O

devices, interfaces, power supply units, synchronization and timing units, etc. the network node consists of. Description of their function in details and possible impact on service if the certain unit fails.

ix. Redundancy. W hat redundancy principles are used for backing up a particular unit, e.g. hot-standby, cold standby, N+1, which units/modules/cards are/aren’t hot swappable, how does the unit switchover affect the system performance, are there any necessary restarts to activate backup unit? W hich units/modules/cards in the entity are not redundant? How their outage impacts services?

x. Description of typical layout of racks, cabinets, cartridges, modules, units, cards, I/O devices, interfaces, power supply units, synchronization and timing units, etc.

xi. Explanation of the concept and redundancy of power supply for both a whole network node and individual components.

6.5.6 Signaling

a) Automatic load redistribution on the links which are available in the combined linkset

b) 2Mbit High Speed Signaling Data link ITU Q703 c) Maximum values as regards Point Codes, linksets, S7 links, types of

GTT and other limiting factors.

85

d) Load sharing support in SCCP (combined routesets) and MTP level e) Load sharing for all the SCCP destinations (Global Title) or MTP3

destinations (Point Code) f) Load sharing among multiple STPs using GTT Alias Point Codes for

STP addressing g) The HLR/AUC shall support SIGTRAN protocol group: The HLR/AUC shall support SCTP according to RFC 2960. The HLR/AUC shall support M3UA according to RFC 3332.

h) The HLR/AUC shall support Multi-signaling-point (Multi-SP) function to enable large-capacity offices to break the limitation of Signaling System No. 7. The maximum number of SP supported shall be up to 256.

i) The HLR/AUC shall support SCTP multi-homing to ensure the reliability of IP based signaling interface.

6.5.7 Interface description

a) The offered HLR shall provide abundant open standard interfaces. This implies that the Vendor shall share all necessary information with other vendors when inter-operation is required in Operator’s network. Any deviations from this rule shall be explicitly stated by the vendor for each network entity and interfaces described in this RFP. Impact and internal protocol

Connected entities

Any proprietary feature or protocol

detail

MSC INAP … VLR … … SMC

SGSN GGSN

gsmSCF GMLC

b) The network elements shall provide HLR relevant interfaces as

specified below. The Vendor shall depict all protocol layers for each supported interface and provide statement about compliancy with relevant 3GPP standards or other standards (RFC, ITU-T, IEEE) for each protocol layer. Connected entities

Interface name

Applied protocol

Physical Interface

Specifications

MSC VLR

86

Connected entities

Interface name

Applied protocol

Physical Interface

Specifications

SMC SGSN GGSN

c) The Vendor shall describe number of logical links/connections possible per one interface and whole entity, recommended/maximum load of interface that can be processed by interface unit, recommended/maximum load of fully configured entity. Interface Internal/

External Physical Interface

Max Port number

Max Link number

C External E1 IP ATM D External E1 IP ATM J External E1 IP ATM Lh External E1 IP ATM Gr External E1 IP

6.5.8 Functions and Features

a) The HLR shall be shared by the circuit switched (CS) domain and packet switched (PS) domain in UMTS/GSM system. It shall integrate the functions of AUC.

b) The HLR shall provide USSD (Unstructured Supplementary Services Data) functionality and interface which shall be compliant with GSM and 3GPP specifications TS 29.002.

c) The HLR shall support CAMEL Phase 3 services. The HLR shall provide O-CSI (Originating CAMEL Subscription Information), T-CSI (Terminating CAMEL Subscription Information), SS-CSI (Supplementary Service Invocation Notif ication CAMEL Subscription Information), TIF-CSI (Translation Information Flag CAMEL Subscription Information), U-CSI(USSD CAMEL Subscription Information) and UG-CSI (USSD General CAMEL Subscription Information), they include GPRS-CSI(GPRS CAMEL Subscription Information), SMS-CSI(Short Message Service CAMEL Subscription Information), D-CSI(Dialed Service CAMEL Subscription Information), M-CSI(Mobility Management event CAMEL Subscription Information)

87

and VT-CSI(VMSC Terminating CAMEL Subscription Information). d) The HLR shall support General packet radio service (GPRS). e) The HLR shall support any time interrogation (ATI) operations initiated

by a service control point (SCP). Through this operation, the SCP and HLR provide the location and status of mobile terminals.

f) The HLR shall support providing LCS service subscription function and supports four standard subscription modes: Universal, Call related, Non-call related and PLMN operator. And the HLR shall support the Lh interface with GMLC and provides LCS routing function.

g) The proposed HLR should support the function of CAMEL restriction. This function enables operator to flexibly configure CAMEL service processing in HLR based on subscriber according their requirements.

h) The proposed HLR should support the function of SMC address filtering.

i) The Vendor shall provide information and specifications on any proprietary protocols or protocol elements used on the interfaces of the proposed HLR/AUC.

j) At least 254 different virtual HLR, which are independent and can be completely distinguished.

k) Configuration of multiple virtual HLR in the same physical equipment. l) Flexible roaming restriction and Roaming Profiles which can be

configured per Subscriber. m) Roaming restriction per network element, group of elements for GSM,

UMTS and/or GPRS. n) Identif ication and Differentiation between 2G and 3G subscribers.

6.5.9 Redundancy and Reliability

a) The HLR shall be designed in such a way that single faults in the software shall not cause a system failure or service interruption or degradation of system performance. Under faulty conditions, the System shall continue to operate normally without reduced grade of service or quality of service.

b) No single point of failure in one site/node. All hardware have its backup in local site.

c) The HLR shall be designed in such a way that the HLR can be duplicated on geographically separated locations.

d) The hardware reliability of the HLR shall be ensured by: i. Exception Protection ii. Redundancy and Backup Design

88

iii. Flow Control iv. Reliable Power Supply

e) The data reliability of the HLR shall be ensured by: i. Data backup between different boards ii. Data backup to local harddisk iii. Data backup to DiskArray

f) The proposed HLR shall have at least 20 specifically redundancy commercial cases used all over the world. The detailed information should be listed.

g) All the elements must be dimensioned for the purpose of achieving 99.999% reliability (simple node) and 99.99999% (redundant nodes)

h) For redundancy solution, the HLR/AUC should support manually and automatically switch over, and can be configured by operator.

6.5.10 Performance & Capacity

a) The proposed HLR/AUC shall have large capacity up to 3M active subscribers (one FE).

b) The AuC capacity must be atleast 1.2 times to that of the HLR c) The HLR/AuC Technical Specification should be provided as following

form Item Ability Max capacity Density(footprint/per10M sub, rack footprint)

Provision speed Max commercial deployed capacity in one network

TDM 2M Links TDM 64K Links IP Sigtran links Range of temperature Power Consumption(xxW /1m Sub)

6.5.11 Network Evolution

a) The Vender shall describe all necessary hardware and software changes associated with migration of the HLR to HSS.

b) Is it possible to migrate to 3GPP Release 5 network only via software upgrades? W hat is the performance impact of such upgrade?

c) The Vendor shall describe the roadmap for this, including the integration and interworking with the packet domain core network and ancillary network nodes.

89

6.5.12 HLR/AUC shall support the following features.

(i) Logical Group (Applicable to S-HLR only):A logical group shall contain a collection of subscribers which the operator may create to maintain subscribers in different groups for administrative purposes.

(ii) Group Profile (Applicable to S-HLR only): The group profile contains a set of default features automatically assigned to the subscriber. Operators shall be able to group a set of subscriber features together into group profiles and thus avoid having to assign each feature individually when creating the profiles for new subscribers.

(iii)Administration of Cooperating Exchanges (Applicable to S-HLR only)

A cooperating exchange is an MSC that accesses the HLR for subscriber information. Means shall be provided to specify, delete, modify, and print cooperating exchange data. The data shall specify the following:

a. Exchange identity (Global Exchange Name)

b. Roaming type (automatic or manual)

c. Routing Interrogation Code (how the interrogating exchange should route the call)

d. Signalling network information

e. Signalling protocol to be used for routing to a destination in the network.

(iv) Tables in the HLR

The provision shall be there for setting up and maintaining all data related to the HLR. The data stored in the table shall include:

a. Forward-to-number analysis table

b. PIC to CIC translation table

c. Procedure code analysis table

d. Announcement code analysis table

e. Restricted digits table

f. Cooperating exchange table

6.5.13 Alarms and Notifications

Alarms: The HLR shall generate an alarm when an error or fault occurs within the system. Provision shall be there for these alarms requiring human intervention in order for them to be acknowledged or cleared.

90

The HLR shall log all alarms and presents them to the user via the GUI (Live Alarm Display). The operator shall be automatically presented with the relevant procedure in order to resolve a given alarm.

Notifications: A notification shall report the occurrence of a specific event in the system. In general, a notification shall not require operator intervention.

6.5.14 The AUC shall have provision for security measure for fraud prevention by implementing a series of standard authentication procedures to protect the Mobile network.

6.5.15 Authentication Procedures: AUC shall support authentication according to the standard GSM/ UMTS protocols.

6.6 INTERFACES a) Full Technical details regarding implementation of interfaces (at each standard

reference point) amongst different network elements as well as with other networks shall be provided and no interface shall be proprietary in nature. It shall be possible for the MSC to interface with external network elements such as Short Message Entity (SME), OTAF, IN etc. through standard interfaces.

b) All standard interfaces shall be supported by the system as per the requirement.

6.7 SMSC

6.7.1 MTML presently has Huawei make SMSC diamentioned for 100K Subscribers. Existing SMSC should be suitably upgraded and integrated with a new SMSC of capacity as envisaged in this tender to provide 2G & 3G services seamlessly to the existing CDMA subscribers as well as new subscribers. The new SMSC shall be dimensioned accordingly. The responsibility of interworking of new SMSC with existing SMSC of MTML / other network lies with the successful bidder.

6.7.2 Alternatively, the successful bidder may replace the existing SMSC with new

SMSC of higher capacity which will include existing SMSC capacity. In this case, the migration of existing SMSC capacity to the new SMSC will be the responsibility of the successful bidder.

6.7.3 The bidders also have the option to expand and upgrade the existing SMSC

for providing 2G/3G services seamlessly to the existing as well as new capacity.

6.7.4 Design Aspects:

i. Common SMSC for 2G &3G services (GSM & HSDPA/HSPA) in any proportion.

ii. Must support content based charging for post paid and prepaid subs. iii. 2 BHSM per subscriber may be considered for each Phase. iv. GUI based faults and reports including failure reports for SMPP, VMS, IN

related SMS.

91

v. CDR based reports to be made available. vi. New SMSC should cater to at least 1 Million BHSM. vii. It shall be possible to charge differentially for premium messages, pre-

paid subscribers on the basis of SMPP port, content of SMS, SMS profile of subscriber, type of SMS, Broadcast list, location from where it is originated and charging of content provider in case of advertisements.

6.7.5 Maximum length of SMS message - 160 characters. Messages of size at least

equivalent to 10 SMS should be sent as multiple SMS for concatenation at MS and vice-versa.

6.7.6 The SMSC shall provide storage for all undelivered message for the duration

of atleast one week. The SMSC shall provide multiple re-trial profiles based on the cause-code of non-delivery together with programmable re-trial duration for each cause-code through MMI commands.

6.7.7 Core Requirement a) The vendor’s solution must support Gd interface for message delivery on

2.5G and 3G packet switch environment b) Solution must support Interworking MSC & Gateway MSC combined in one

´Mobile Network-Interface c) Message tracing based on a given specific number should be available d) The solution must support deliver multi messages with only one time to send

routing information operation. e) The solution should provide a GUI for the operator to inquire the location of a

cell phone f) The vendor’s SMSC networks must be simple and the system should has

massive capacity(no less than 1000 messages per second) and the vendor should make a detail description about how to support such massive messages processing capability.

g) The Vendor must describe SMSC system capability per node. h) All the messages should be stored for no less than 3 months, and at the same

time, a GUI should be provided to do such inquiring jobs i) The solution should simultaneously support GSM/CDMA/TDMA signaling j) For CDMA scenario, the solution should support MMS push and WAP PUSH k) The SMS must support diameter, real time charging interface.

6.7.8 The SMSC shall have the facility of SMPP service for interconnectivity to

facilitate multiple content providers to extend their services to MTML subscribers. A minimum of 128 content providers are to be provided access to the SMSC. The SMSC shall have suitable firewall to ensure security of the SMS platform. It should be possible to differentially charge based on the destination number and also based on the content provided by the content providers for both post and prepaid subscriptions. It should accordingly interface with IN platform for ON-LINE charging in real time and shall generate data for differential charging for the prepaid subscribers. SMSC should have in-built capability of SMS gateway for HTTP push and pull services.

6.7.9 Feature Requirement

a) The solution must support a flexible subscriber database b) The solution must support Store and Forward, and Forward and Store of

messages

92

c) The solution shall support SRI for SMS with high priority, and make a delivery attempt for this message

d) The vendor’s solution shall be able to configure different priority by origination and destination number or number segments

e) The system shall offer extremely high peak traffic throughput by means of intelligent retry mechanism. The system shall have a dynamic handling of retries such that during high traffic periods, SMS with high retry counts will not be retried. The retry counter for these SMS’s shall not be incremented. Instead a new counter shall be introduced for each SMS that will show the number of times a retry was postponed due to a period of peak traffic. The number of retries performed on SMS before peak traffic handling is enabled shall be configurable

f) It shall be possible to configure maximum validity period based on source and destination address of the SMS

g) The SMSC shall support delivery of SMS with 20-character A-party and B-party MSISDN

h) Combined fast store and save store depending on message type i) The ability to use a fully redundant set of centrally located SS7 interfaces so

that each SMSC in a multi-node environment does not have to have individual direct connections to the MSCs and STPs

j) The SMSC should provide sending group and short number short message based on the web portal for enterprises

6.7.10 It shall be possible to schedule the SMSC for acceptance and transmission of

push messages from the content providers. It shall also be possible to define priorities for the different ports for acceptance of SMS from Content Providers.

6.7.11 It shall be possible in the SMSC to define criteria based filters to block

transmission of SMS satisfying the defined criteria. The SMSC shall route all such messages to an appropriate database and provide an analysis and management report of such messages through interactive and intelligent GUI in the OMC. The report and analysis shall be as per the customization requirements of MTML.

6.7.12 The SMSC shall have suitable interface (IS 41-C) to interwork with CDMA-1X

systems with assumption that 15% of total SMS will be sent to CDMA network. It shall be possible to exchange Short Messages between the CDMA and GSM systems. The SMSC should be common for 2G and 3G services and compliant to 3GPP TS 23.040.

6.7.13 SMSC shall provide for multiple local language support in the UNICODE

format. Details of implementation for the same may be furnished. 6.7.14 It shall be possible for the subscribers to send and receive e-mail messages,

as SMS and the same shall be handled by the SMSC through appropriate interface to MTML email server and suitably protected through firewall.

6.7.15 The vendor’s solution is required to support the creation of an event type field,

which will be assigned based on other information in the CDR. This field will initially not appear on the CDR. The event type field will be required to differentiate between different types of messages, such as MO or MT

93

messages, premium MO or MT messages, SMS copies, SMS resends, etc. This field should be populated as part of a post-processing job, which will give the possibility of using other fields to determine this field. The manner in which this field is determined should be fully configurable.

6.7.16 The solution must be capable of placing CDRs in a flat text file 6.7.17 Statistics & Reporting:

a) The SMSC must provide comprehensive system statistics. The statistics must be available in flat file format and must be available to the System Administrator from the System Administration GUI

b) Statistic shall be provided at both the platform level and application level

c) The following statistics shall be provided by the SMSC i. SMS based Activity Statistics ii. SS7 interface Statistics iii. SMPP interface Statistics iv. Platform Statistics

d) The vendor shall supply a detailed list and description of the statistics that are stored on the platform

e) The statistics shall be presented to the System Administrator in ‘real time’. The data refresh rate should be configurable. The maximum data refresh rate should be no greater than 30seconds

6.8 MMSC: 6.8.1 MTML presently has MMSC from M/s. Huawei for CDMA network. Existing

MMSC should be suitably upgraded and integrated with a new MMSC of capacity as envisaged in this tender to provide 2G & 3G services seamlessly to the existing subscribers as well as new subscribers. The new MMSC shall be dimensioned accordingly. The responsibility of interworking of new MMSC with existing MMSC of MTML / other network lies with the successful bidder.

6.8.2 Alternatively, the successful bidder may replace the existing MMSC with new

MMSC of higher capacity, which will include existing MMSC capacity. In this case, the migration of existing MMSC capacity to the new MMSC will be the responsibility of the successful bidder.

6.8.3 The bidders also have the option to expand and upgrade the existing MMSC

for providing 2G/3G services seamlessly to the existing as well as new capacity.

6.8.4 It shall be possible to charge differentially for premium messages, pre-paid

subscribers etc. 6.8.5 For design of MMSC solution, 0.2 BHMM per subscriber may be considered for

each Phase. The solution proposed shall be expandable to support one million BHMM.

6.8.6 Requirements: a) Specify if the MMS-C is divided into more then one functional modules,

e.g. HTTP-Proxy and PPG-Proxy, and describe clearly in a organized list the functions and features of each of its blocks

94

b) Describe the proposed solution from a functional perspective. An overall figure must be provided, which will be used as a reference (functional/physic) architecture for the following sections. The figure should show clear how this architecture integrates into a mobile operator network and how its components are mapped with different functional nodes compounding the solution

c) Pre-paid credit verification nodes d) Provisioning nodes e) Billing/charging nodes/systems f) O&M nodes/systems g) Describe the ability of MMS-C to support the several types of media

content formats (text, audio/video, SMIL,). Please specify the supported versions per media content

h) Describe the terminal manufactures and products supported by your MMS-C solution

6.8.7 The MMS shall be with Architecture as specified in 3GPP Release 4 document

and subsequent enhancements. It should be possible to differentially charge based on the destination number and also based on the content provided by the content providers for both post and prepaid subscriptions. It should accordingly interface with IN platform for ON-LINE charging in real time and shall generate data for differential charging for the prepaid subscribers. MTML will arrange the content through its internal resources/tie ups.

6.8.8 The vendor should provide MMS Service solution with the following service features:

i. MO-MT MMS (Intra-operator and Inter-operator) ii. MO-AT MMS iii. AO-MT MMS iv. MMS to Email v. Email to MMS vi. Content Adaptation and Legacy Phone Support by terminal

capability negotiation/database 6.8.9 The MMS Solution provided should be compliant to the relevant and popular

industry standard(s) as following

i. 3GPP ii. OMA – MMSC Interoperability Compliance

6.8.10 Describe the communication protocols used for the connection

1. Describe the SMTP implementation used by the MMS platform. Indicate the supported standard and the functions supported by this interface

2. Describe the interface implemented between the MMS platform and the WAP platforms. Indicate the supported standard (WAPFORUM specifications) and the functions supported by this interface

6.8.11 Please describe the access architecture to the network

o HLR/VLR: describe the integration architecture with HLR of GSM network. o GPRS: describe the integration architecture with GPRS nodes

95

6.8.12 Is MMS-C provided with a statistic gathering/analyzing tool? Describe which

and if making part of the MMS-C platform or separate module/node/platform 6.8.13 Can messages going through MMS-C be traced and monitored and how?

Describe tracing/log mechanism specifying how it is complete and user-friendly 6.8.14 The MMS platform provided should support the following features in addition

to normal submission or reception of MMS by mobile/application

i. Delivery Report ii. Read Report iii. Forwarding of MMS iv. Address Hiding v. Multi-Recipients vi. Prepaid interface support vii. MNP support (local database (ENUM/proprietary) or SS7) viii. Desired Delivery Time ix. Expiry Time x. Different Types of medias (text, audio, still image, and video

(streaming)) 6.8.15 The MMS Solution should support the following charging option

i. Real time charging for the Prepaid subscribers ii. Real time CDR Generation iii. Per Message Charging Only iv. Per Message with volume class Charging v. Per Content Charging vi. Surcharge for IOMMS,

6.8.16 The MMS platform should support Direct Push solution, with which the Push

message can be sent to the SMSC without passing through the W AP GW . The push policies can be configured

6.8.17 The MMS push notification message can be sent through SMS directly, push message should be compressed in one message

6.8.18 WAP gateway supporting WAP version 2.0 for handling SMS and MMS traffic

meeting the tender requirements may be quoted alongwith expansion required in Phase-II.

6.8.19 Billing Requirement :

a) Vendor must provide some basic and customized CDR generated by MMS-C

b) Is real-time billing for pre-paid customers available (describe please its interface/protocol if applicable)

c) Can real-time pre-paid billing logic be created and configured accordingly to customer’s pre-paid system requirements

6.8.20 Describe key-factors/parameters defining relation between MMS-C’s

performance/dimension and network (LAN) dimensioning support 6.8.21 Describe MMS-C dimension dependency on CPU/Memory capacity

96

6.8.22 If vendor does package upgrades of each of its MMS-C solution consisting of HW /SW upgrades describe performance characteristics of each upgrade for each commercial MMS-C solution

6.9 Additional Requirements of MMSC, SMSC and Packet Core Network

6.9.1 CDRs generated by the various network elements such as MMSC, SMSC,

GGSN, SGSN, WAP and any other network elements, the services of which are to be charged in respect of the pre-paid subscribers, shall be charged on-line.

6.9.2 The SMSC, MMSC and GPRS etc shall generate CDRs in formats compatible

for transmission to B&CCS and to IN platform for each of the message handled. The network elements shall provide the facility of tagging CDRs by exception on the basis of lookup tables. It shall be possible to-define lookup tables through MMC. Additional mediation device necessary for routing the CDRs to B&CCS and IN platform shall be supplied.

6.9.3 The system shall through suitable procedure verify the balance available for

pre-paid subscribers before accepting their message for processing in SMSC/MMSC/GPRS/EDGE etc. The SMSC/MMSC/GPRS/EGDE etc shall, however, allow service messages to be delivered to such subscribers.

6.9.4 7.1 UMS shall be dimensioned to provide Voice Messaging Service to 100% subscribers with sufficient storage capacity.

6.9.5 UMS shall have SMSC, which shall be dimensioned for 100% of total

subscribers 6.9.6 Assuming 10 messages ( 10 MO & 10 MT) per subscriber per day. Maximum

length of SMS message will be 160 characters.

a) SMSC shall provide storage for at least 40% undelivered message. Retrial attempts of un-delivered SMs shall not impact BHSM of SMSC as defined in this section. Expiry time for undelivered message & retrial duration (multiple retrial profiles based on the cause-code of non-delivery) shall be programmable through MMI command.

b) SMSC shall have the facility for interconnectivity to facilitate multiple

content providers. A minimum of 128 content providers are to be provided access to SMSC. SMSC shall have suitable firewall to ensure security of SMS platform. It should be possible to differentially charge based on the destination number and also based on content provided by the content providers for both post paid & prepaid subscribers. It should accordingly interface with IN Platform for ON-LINE charging in real time and shall generate data for differential charging for prepaid subscribers.

c) It shall be possible to schedule the SMSC for acceptance and

transmission of messages from the content providers. It shall also be possible to define priorities for the different ports for acceptance of SMs from content providers.

97

d) SMSC shall have suitable open interface to interwork with GSM systems. It shall be possible for exchange of SMs between CDMA & GSM systems.

e) SMSC shall provide multiple local language support.

f) SMSC shall have gateway functionality to configure for International SMS for both GSM and CDMA networks.

6.9.7 The SMSC, MMSC etc. shall generate CDRs in formats compatible to

B&CCS and IN platform for each of the message handled. Mediation device necessary for handling he CDRs to B&CCS and IN Platform shall be supplied.

6.9.8 The system shall through suitable procedure verify the balance available for

pre-paid subscribers before accepting their message for processing in SMSC, MMSC etc. In case adequate balance is not available to charge the subscriber, he shall be notified appropriately. The SMSC, MMSC etc. shall, however, permit service messages to be delivered to such subscribers.

6.9.9 SMSC & MMSC shall be dimensioned for BHSM of 0.5 & BHMM of 0.3 per

subscriber respectively. 6.9.10 The system shall be configured with unlimited subscriber license restricted

only by the total Earlang traffic. All necessary hardware and related software licenses including databases in all network elements shall be dimensioned and equipped accordingly, except for those network elements for which higher capacity, if any, has been specified elsewhere.

6.10 HIGH SPEED PACKET DATA NETWORK This document lists the technical requirements for a GPRS/UMTS PS network architecture. It describes the target architecture and formulates and a single, common set of requirements and expectations regarding the functionality/ capabilities, performance and delivery of SGSN & GGSN.

98

Figure: General Architecture of GPRS/UMTS PS Network

6.10.1 This PS domain target architecture will meet the following high level

requirements, which the Vender’s solution will have to support:

a) The proposed PS System shall comply as defined by 3GPP in Release 6. b) The proposed PS System shall simultaneously support GPRS and UMTS

accesses. c) The system won’t be any hardware changes when upgrading from 2.5 to

3G. d) The vender must describe in detail the various phases of a 3G

communication by indicating the various implied entities (SGSN, GGSN, DNS, FW, Radius…), the various protocols used (GTP, SNDCP, IP…)

e) The network elements shall provide PS system relevant interfaces as specified in 3GPP TS 23.060.

f) The Proposed PS equipments shall have large capacity with high density in order to save the Carrier ’s CAPX and OPEX. Furthermore, the PS equipments shall be modularized designed and have reasonable flexibility for the future capacity expansion.

g) The vendor is requested to provide the qualifications to show that their PS equipment has at least one application with more than 1.5 million subscribers in commercial networks.

6.10.2 Network Evolution

a) The Proposed PS equipments shall support evolution from 2G to 3G. b) The Proposed PS equipments shall support architectural evolution form

R99 to R4 and form R4 to R5/R6. c) The SGSN shall be capable of supporting direct tunnel concept

99

according to the 3GPP standards whereby the GTP User plane and control plane are split. The User plane shall be directly tunneled from UTRAN to GGSN and the GTP Control plane shall be handled via the SGSN.

d) The Proposed PS equipments shall support evolution to SAE architecture without hardware change.

e) Vendor shall provide a detailed description of the SGSN and GGSN HW evolution.

f) Vendor shall describe a detailed feature roadmap for SGSN/GGSN evolution per planned software release and it also should include the capacity of each release.

6.10.3 Network synchronization

a) The Proposed PS System shall support at least two types of external clock synchronization and shall meet the requirements of ITU-T Recommendation G.812.:

1. Providing 2MHz or 2Mbit/s incoming clock source through BITS 2. Providing 2MHz incoming clock source through E1 line.

b) The proposed PS System shall support internal timing output interface. The Vender is requested to describe the mechanism.

c) The proposed PS system shall support NTP(Network Time Protocol), and the NTP server shall be provided.

6.10.4 Interface description and characteristics

a) The network elements shall provide GPRS/UMTS relevant interfaces as specified below. The Vender shall depict all protocol layers for each supported interface and provide statement about compliancy with relevant 3GPP standards or other standards (RFC, ITU-T, IEEE) for each protocol layer.

100

Gf

Uu

Um

D

GiIu-PSGc

CE

Gp

Gs

MSC-Server/VLR

TE MT UTRAN TEPDN

GrIu-CS

HLR

Other PLMN

SGSN

GGSN

Gd

SMSCSMS-GMSC Server

SMS-IWMSC

GGSN

EIRSGSN

GnCGF

GaGa

Billing

System

Gb

TE MT BSS

R

A

R

Gn

GMLC

Lg

SCP

Ge

Figure 2: Interface of GPRS/UMTS PS Network

The vender should state the physical interface, the rate and the physical protocol of each logical interface as the table below: Logical Interface Physical

Interface Rate

Iu-PS Gn/Ga/Gi/X1-

1/X2p/X3p

Gr/Gd/Gf/Ge/Gs/Lg

Gb

b) The Vender shall describe redundancy principles applied on

interfaces. c) The Vender shall describe number of logical links/connections

possible per one interface and whole entity, recommended/maximum load of interface that can be processed by interface unit, recommended/maximum load of fully configured entity.

d) The system shall provide the following physical interfaces: Ethernet/Fast Ethernet Gigabit Ethernet PPP E1, FR E1 POS STM-1, POS STM-4.

101

6.10.5 Reliability and Availability

a) The Vender shall describe in detail the Reliability and Availability architecture the offered GSN System is based on. The GSN should comprise of the following components: 1.5.a.1 SGSN (Serving GPRS Support Nodes) 1.5.a.2 GGSN (Gateway GPRS Support Nodes) 1.5.a.3 Charging Gateway (CG) 1.5.a.4 NAU (Network Auxiliary Unit) such as DNS, DHCP, Firewall,

Border Gateway router, etc. b) In the event of failure of one or more parts of each core node, the normal

functioning mode of the rest of the core node shall not, in any way be affected.

c) The proposed SGSN should support Iu-flex and Gb-flex as defined in 3GPP Standard.

d) Core nodes shall not have a single point-of-failure, all hardware boards, power supply units and interfaces shall be duplicated and redundant in either active-standby or load-sharing modes.

e) Total availability for each core node shall exceed 99,999%.

6.10.6 Overload protection

a) The proposed PS system shall be capable to handle signaling and traffic overloads in an orderly and controlled manner.

b) The proposed PS system shall detect and analyze an overload condition and produce reports and alarm information to the OMC. Data calls in progress shall not be affected under overload conditions and particular attention must be given to ensure that the mobility management is not impaired due to any overload condition.

6.10.7 Software Design and Upgrade

a) The GSN system shall be modular in design. The GSN system shall be upgradeable to a higher software release with minimal impact to the normal system operation.

b) The upgrade of the GSN network elements shall be described. The mechanisms to maintain the integrity of the mobility data have to be considered in the Vender’s answer.

c) The Vender shall describe the change in architecture and the migration to 3GPP Release6 and Release7 in terms of hardware and software upgrades of existing nodes and the introduction of new functional entities and interfaces/reference points.

d) The system shall be able to produce copies of the system program and

102

data and to load them automatically triggered by a restoration or recovering process.

e) The GSN shall be capable to handle signaling and traffic overloads in an orderly and controlled manner.

f) The overload protection should apply if one or more processors are involved in the handling. The Vender is required to provide details of the overload protection of all units.

g) The GSN system shall support different levels of system authorization. The GSN shall provide access control and authorization management functions to prevent unauthorized access to sensitive data. The Vender is required to describe the different authorization levels.

6.10.8 Roadmap Overall description

The Vender shall provide a detailed description of PS CN evolution during 3 YEARS GPRS and UMTS. The description should take into account: the architectural, functional and technological aspects making reference to the 3GPP release it is based on. Moreover, the Vender shall provide for each system under quotation the roadmap underlying the following items:

a) Hardware and Software Roadmap; b) Capacity Roadmap c) Network features roadmap; d) State of Compliance respect to Standards.

6.10.9 Packet Core: i) Succesful vendor shall provide SGSN/GGSN of capacity as envisaged in this

tender to provide 2G & 3G services seamlessly. The SGSN/GGSN shall be dimensioned accordingly.

ii) The bidders also have the option to expand and upgrade the existing

SGSN/GGSN for providing 2G/3G services seamlessly to the existing as well as new capacity.

iii) The GGSN SGSN shall support the standard GPRS / UMTS interfaces. iv) The GGSN/SGSN shall support CAP III protocol. The GGSN/SGSN shall

provide all services for pre-paid and post-paid subscribers and charged the pre-paid subscribers real time. Bidder shall indicate evolution path for support of diameter protocol.

v) GGSN/SGSN shall support all four UMTS QoS classes – Background,

Interactive, Streaming and Conversational. Application required for back-tracing of Global IPs (Netted IPs) to local IPs (assigned to mobile) should be stored for minimum one month to provide the details to security agencies.

vi) Following call profile may be utilized for subscriber capacity.

103

S.No. Description 1.

Traffic requirements: 2G (GPRS + EDGE)

a) Average Traffic dem and at IP layer per active context, at busy hour, downlink+uplink

300 bps

b) Ratio = Downlink / (Downlink+Uplink)

80%

c) Average packet size (at IP layer)

256 bytes

2.

Traffic requirements: 3G (UMTS R4 + HSDPA)

a) Average Traffic dem and at IP layer per active context, at busy hour, downlink+uplink

600 bps

b) Ratio = Downlink / (Downlink+Uplink)

80%

c) Average packet size (at IP layer)

256 bytes

vii) Design Aspects:

a) Common SGSN/GGSN for 2G & 3G services (GSM & W CDMA) in any proportion within the total data requirements envisaged in the tender.

b) Must support content based charging for post paid subs and prepaid subs

c) Shall include all requisite Hardware and Software for DNS, NTP, Firewall, LAN, Border Gateway, CG, LIB/LIC and Switches etc.

d) Throughput for simultaneous access should be dimensioned based on one PDP Context per subs for 50 % of 3G subs and one PDP context per subs for 20 % of 2G subs. However, subscription for 100% 2G & 3G subs should be provisioned for data services. The SGSN/GGSN should be expandable to one million PDP contexts capacity.

e) The offered SGSN/GGSN solution should comply with GSM standards.

f) Intelligent Packet Solution for content based charging shall be provided. The solutions should be capable to analyse network, transport and application lyer protocols. The packet inspection included in the solution should support protocols like IP, TCP, UDP, HTTP 1.1, WAP 2.0, MMS, RTSP, SMTP, POP3, IMAP4 etc. and should provide analysis of content types. The system should support diameter protocol for charging of pre-paid subscribers.

6.10.10 Requirements for SGSN

Hardware and software design

a) The system architecture of SGSN shall be designed as modularization, and can be expanded flexibly by cascading.

b) The total planned down time for each core node shall not exceed 45 minutes / year, e.g. due to hardware and software upgrades.

104

c) The signaling plane and the user plane in SGSN should be separately designed to avoid the influence on each other.

d) The SGSN provided should be act as Serving GW to support evolution smoothly to SAE.

6.10.11 Functionality and Feature Requirements of the SGSN a) The SGSN shall perform all Packet data routing and transferring,

Encryption and authentication, Session management, Mobility management functions as specified in the relevant ETSI GSM and 3GPP release4 standards.

b) The SGSN will produce information of management of taxation and mobility to be gathered by the Charging Gateway (CGF) functionality.

c) The SGSN will have to be interfaced via GPRS Service Switching Function with Service Function Control for optional Camel sessions and cost control service support.

d) The SGSN will be capable of inter operate with GPRS/EDGE Networks and UMTS Networks.

e) The SGSN shall support the following Roaming / Sharing functions in accordance with 3GPP specifications: Multiple PLMNs Seamless National Roaming Regional Roaming restrictions based on certain LA or based on

IMSI series Selective equivalent PLMN (3GPP TS 24.008)

f) The SGSN shall support CAMEL phase 3. g) The SGSN shall support Multiple Signaling Point and High Speed Link

(2M SS7) technology. h) The SGSN shall support Iu over IP (3G) and Gb over IP (2G). i) The SGSN shall support MVNO function. It should support divide MVNO

by MNC+MCC or IMSI series. The different Authentication method and ePLMN List should provided according to different MVNO. The SGSN should define subscriber number, PDP number, Short Message function, LCS function, encryption function, compression function for each MVNO.

j) The SGSN shall support hardware dual stack (IPv4 and IPv6). k) The SGSN shall support hardware engine for data compression over Gb

interface as defined in ITU-T v.42bis. l) The SGSN shall provide OSPF, BGP, RIP & Static IP routing functionality. m) The SGSN shall support SIGTRAN function. n) The SGSN shall support IMSI series based routing to different GGSNs. o) The proposed SGSN shall provide all the features and functions listed.

The list should includes the following information: Network Elements involved in the implementation of the feature

105

The feature is included in UMTS or GPRS or both of them The Vender’s feature code

6.10.12 Performance, capacity and connectivity a) The proposed SGSN shall have large capacity (>=1 million attached

subs, 1 million PDP contexts simultaneous activation ). b) The proposed SGSN shall have large throughput to support high speed

services (>=10Gbps). c) The Vender shall give a description about number of SAU, PDP, physical

and logical network element connectivity for minimum configuration and per each additional capacity step up to maximum configuration.

d) The SGSN can support flexible configuration of PDP to SAU ratio. It should configure PDP to SAU ratio at least but not limited as 1:20, 1:10, 1:5, 1:2, 1:1, 2:1.

e) The Vender shall state the maximum number of BSC/PCU supported by SGSN.

f) The Vender shall state the maximum number of RNCs supported by SGSN

g) The SGSN shall be designed, built and developed on a carrier grade platform.

h) The SGSN shall allow the application of patches / corrections without impact to subscribers. The Vender shall provide details on patch/correction process for their platform.

i) The SGSN shall be designed such that capacity expansions without impact to existing subscribers.

j) The Vender shall describe the scale and number of IP interfaces supported per SGSN.

k) The Vender shall state the impact of the packet size on the throughput capability of the GGSN and the SGSN.

l) The Vender is requested to describe the performance information with the following information for SGSN: Minimal and Maximal Capacity in terms of subscribers, throughput,

and the expansion step. Number of PDP context supported Number of types of interfaces supported The capability of signaling processing

6.10.13 Charging Functionalities a) Record type and Information field

106

The CN nodes provided by the vender should collect the mandatory information (record Type, served IMSI etc.) specified in 3GPP TS 32. 015 for each of the following record type:

GPRS charging data in SGSN (S-CDR) GPRS charging data in GGSN (G-CDR) GPRS mobile station mobility management data in SGSN (M-CDR) GPRS MO SMS data in SGSN (S-SMO-CDR) GPRS MT SMS data in SGSN (S-SMT-CDR)

b) Partial records Please indicate if partial records, specified in 3GPP TS 32.015, are supported. Please indicate the foreseen CN/node SW release and date. c) GTP' charging protocol Please indicate if the GTP' charging protocol is supported. Please indicate the foreseen CN/node SW release and date. d) Correlation between PS and IMS charging The Vender should provide the proposal for the correlation of PS and IMS charging in SGSN and GGSN. e) On line charging system The Vender should provide the online charging system proposal. f) IP bearer flow charging The Vender should provide the flow based charging proposal and give the impacts over CN nodes.

6.10.14 Requirements for GGSN

Hardware and software design

a) The system architecture of GGSN shall be designed as modularization, and can be expanded flexibly by cascading.

6.10.15 Functionality and Feature Requirements of the GGSN

i) The GGSN (Gateway GPRS Support Node) is a functional entity for providing packet data services. It is in charge of the routing and encapsulation of the packet data between the GPRS/UMTS network and the external PDN.

ii) The proposed GGSN should provides the function that Receive data from the MS and then routing to the external PDN, or receiving data from the external PDN and then sending to the SGSN according to the destination address by selecting a transport channel through the GRPR/UMTS network.

iii) The proposed GGSN should provide postpaid service. The GGSN generates and outputs call bills, reflecting how users make use of the external network.

iv) The proposed GGSN should provide prepaid service. As a service switching point (SSP), the GGSN serves as connection point between a

107

radio communications network and an intelligent network, providing call control function and service switch function. The GGSN should support CAMEL phase 3 protocol and Diameter.

v) The proposed GGSN shall provide the following routing protocols interfaces:

a) Static Route b) RIP c) OSPF d) BGP v4 e) MPLS f) VRRP

vi) The proposed GGSN shall provide the following methods of IP Address allocation:

a) Static or Dynamic IP Addressing b) Local GGSN Pools c) DHCP d) RADIUS

vii) The proposed GGSN shall provide the following tunneling protocols: a) IPsec b) L2TP (PDP type: IP/PPP). c) GRE d) IP-in-IP e) VLAN f) MPLS

viii)The proposed GGSN shall provide the following QoS functions: a) QoS Support (3GPP TS 23.107, 24.008, 29.060 GSM 04.08, 09.60,

RFC 791, 2474, 2475) b) Admission Control. c) Configurable QoS Mappings. d) DiffServ Marking. e) Policing & Filtering

ix) The system shall provide packet filtering options, as well as, IPsec for security to protect the GGSN against intrusion or denial of service attacks. This shall include filtering on:

a) source IP address, b) destination IP address, c) port number and d) source routing.

x) The GGSN shall support NTPv3 for time synchronization as per RFC1305. xi) The GGSN shall support Mobile IP function. xii) The GGSN shall support HSDPA (maximum 16Mbps QoS bit rate and

guarantee bit rate).

108

xiii)The GGSN shall support internal DHCP Server. xiv) The inter-working with PDN shall be based on IP as specified in RFC

791. The interface towards external PDNs shall support: a) 10 and 100 Mbit/s Ethernet in accordance with IEEE 802.3, IEEE

802.3u. b) Gigabit Ethernet in accordance with IEEE 802.3z and 802.3ab c) IP version 4 in accordance with IETF RFC 791. d) IP version 6 in user plane in accordance with IETF RFC 2460. e) Routing protocols as follows: OSPF version 2, RIP version 2.

xv) Multiple routing instances (virtual routers functionality) shall be available for use in different APN

xvi) The GGSN shall be able to interface multiple PDNs simultaneously. xvii) Both transparent and non-transparent access to external PDNs shall

be supported. xviii) Radius user authentication shall be supported. xix) The offered equipment shall provide open standard interfaces. This

implies that the Vender shall share all necessary information with other Venders when inter-operation is required in Carrier ’s network. Any deviations from this rule shall be explicitly stated by the Vender for each network entity and interface described in this RFP.

6.10.16 Policy Charging and Control requirements

i) The supplier shall provide a detailed statement of compliance to any relevant 3GPP standards or IETF RFC documents relating to PCC architectures. The used version number of these standards shall be stated.

ii) The GGSN charging function shall be protocol transparent for user data, at both IP and TCP/UDP level.

iii) It shall be possible to provide the same charging mechanisms for both postpaid (offline) and prepaid charged customers.

iv) All charging functionality shall be supported for a subscriber using multiple PDP contexts or secondary contexts. Each context shall be treated independently with its own quotas.

v) The GGSN shall allow frequent internal securing of billing information onto non-volatile memory without the need to produce partial CDRs to ensure that minimal billing information is lost during restart or other exceptional circumstances. In the event of recovery from such restarts or exceptional circumstances, the GGSN shall produce CDRs from any billing information that has not generated a CDR.

vi) Flow based charging shall be supported for all packet switched bearers GPRS, UMTS, EDGE HSDPA / HSUPA.

109

vii) The GGSN shall support data volume, time counters per individual service data flows, for both uplink and downlink packets.

viii)It shall be possible to charge based on a combination of volume and time. ix) The GGSN shall record used data volume in Bytes. x) The usage counters shall record all payload (content transfers) on the

GGSN Gn interface. This should include all payload headers and any signaling traffic used by the Gi. This is all bytes above and including the IP layer; the volume of the data link layer shall not be counted.

xi) It shall be possible to avoid counting traffic that does not route beyond the GGSN, e.g. broadcast, multicast messages.

xii) W ith higher layer charging rules (L7) the GGSN should be able to associate the used traffic flow in-order to account for any lower layer signaling traffic in the same counters. E.g. HTTP URL rules should include any associated TCP traffic. WAP URL rules should include any WTP messages (connections etc).

xiii)The GGSN shall provide the subscriber profile in use to the OCS via every DCC CCR messages.

xiv) It shall be possible for the OCS to change the subscriber profile used by the GGSN mid session via DCC CCA, RAR messages.

xv) An online charging service authorization shall be triggered on the first use per PDP context of a predefined charging service through the GGSN.

xvi) The GGSN shall support per service quota authorizations with volume quota in bytes, time quota in seconds.

xvii) It shall be possible to configure the GGSN to block unauthorized charging services or to redirect the service to a web page.

xviii) Prepaid service blocking should function accurately with HTTP pipelining, HTTP fragmentation/continuation, W SP fragmentation/continuation and W SP concatenated requests. W here a method request contains a mix of blocked and allowed requests, the blocked request should be dropped; the allowed requests should be extracted and sent.

xix) The vendor shall state any additional delay in the PDP setup time (not including PPS and data n/w latencies) when the end user is pre-pay and authorized against a Pre-pay system instead of postpaid.

xx) R.463. The vendor shall state any additional delay (not including PPS and data n/w latencies) in initial data transfer for a pre-pay customer with service authorization compared to a postpaid customer.

xxi) The Vendor should describe the supported solution for “content”, “volume” and “time” based charging including on-line charging mechanisms for home and roaming use-cases.

xxii) The vendor should describe the signaling process capability on GGSN

110

when Diameter interface is used.

6.10.17 GGSN Service Control Functionality i) All GGSN service control functions shall be configurable to be applied:

globally across a GGSN on a per APN On a subscriber / service profile level.

ii) It shall be possible for a subscriber to be assigned subscriber profile(s) by RADIUS on authorization and authentication of their PDP Context. The profile(s) shall determine the GGSN functions and services used for that subscriber.

iii) R.390. If a subscriber profile is used, this profile shall supersede any global or APN level profiles. The order of precedence (highest first) shall be:

Subscriber Profile APN GGSN

iv) It shall be possible to set a default subscriber profile per for an APN for users who do not have any subscriber profile defined. Any subscriber profile provided in RADIUS Access response will over-ride the default subscriber profile.

v) The vendor shall provide information of other functions that may be defined on a per subscriber profile / service profile level.

vi) The GGSN shall support Single APN functionality to enable the use of a single APN for a subset of customers (e.g. corporate customers) and yet be able to invoke services on a per subscriber basis including VPN membership, tunnel set, and services based on RADIUS service profile attributes returned.

vii) The solution shall be able to identify services using a combination of application and protocol awareness using state full (flow based) detection.

viii)The Protocol Analyzer shall be capable of detecting protocols based on a combination of destination IP address, source IP address, source/destination TCP/UDP port number (or range), URL or IP protocol identifier.

ix) The protocol and application detection calls for (flow based) packet inspection of OSI layers 2 & 3 + URL. Deep packet inspection is the ability to further analysis flows based on OSI layers 3-7 and using trends across packets.

x) The GGSN Protocol Analyzer shall be capable of state fully detecting protocols to Layer 7, utilizing where required heuristic analysis or pattern recognition to find a statistically certain match.

xi) The GGSN shall support complex, heuristic or statistical signatures to

111

detect HTTP HTTPS WAP i-mode FTP TFTP MSN Messenger 7.5+ Yahoo! Messenger SMTP POP3 SKYPE Google Talker

xii) The DPI function must be integrated in GGSN itself. xiii)The vendor shall describer the GGSN throughput in the following models:

(1) Normal(without DPI) (2) 100% L3/L4 inspection (3) 100% L7 inspection

xiv) The GGSN shall support PDP Contexts using Rel. 97 QoS xv) The GGSN shall support PDP Contexts using Rel. 99 QoS. xvi) The GGSN shall be able to diffserv mark packets according to the R97

or R99 QoS parameters. xvii) The mapping of 3GPP QoS to diffserv shall be operator definable to

bitcode level to allow further flexibility. xviii) The GGSN shall recognize diffserv markings and apply operator

defined policies based on these markings. The policies shall include mechanisms to perform the following based on diffserv mark:

xix) The GGSN shall ensure that any 3GPP Release 5 extensions for HSDPA are accurately captured in RADIUS, G-CDRs and prepaid.

xx) The proposed PS must support the statistics based on the following parameters and mixed:

(1) Bandwidth (2) Connections (3) Transactions (4) Protocol/Application (5) Service server (6) Websites (7) Subscribers

xxi) The statistics can be output as defined format, such as: PDF or CSV. xxii) The display of statistics output can be table, chart(area), chart (lines),

etc. xxiii) The file of statistics can be scheduled to send to configured email when

available.

112

6.10.18 Performance, capacity and connectivity

i) The proposed GGSN Server shall have large capacity with activate 3 million Packet Data Protocol (PDP) contexts at the same time, high performance with handling as much as 30Gbit/s of throughput and abundant of interfaces.

ii) The Vender shall give a description about physical and logical network element connectivity for minimum configuration and per each additional capacity step up to maximum configuration.

iii) The Vender shall give a detailed description of the capacity steps and limits of any variants/models of all GGSNs. The descriptions shall, when applicable, include the following per variant/model:

a) Number of simultaneously active PDP contexts, per capacity step and maximum per entity.

b) Throughput measured in packets/second and kbit/s, per capacity step and maximum per entity.

c) Interface characteristics (number of links/connections possible per interface, capacity per interface), per capacity step and maximum per entity.

iv) The GGSN shall be designed, built and developed on a carrier grade platform.

v) The GGSN shall allow the application of patches / corrections without impact to subscribers. The vender shall provide details on the patch / correction process for their platform.

vi) The GGSN shall be designed such that any hardware / software fault is localized and impact to subscribers is minimal. The vender shall provide details of software/hardware fault handling process for their platform.

vii) All the boards in the GGSN should 1+1 hot backup redundancy and should support hot-swap.

viii)The Vender shall detail the number of concurrent active attaches and active PDP sessions supported in the various configurations of the GGSN.

ix) The Vender shall give a detailed description of overload protection mechanism.

6.10.19 Evolution

i) The Vender shall describe all necessary function migration from 3GPP Release 4 to Release 6.

ii) The proposed GGSN shall support evolution to SAE GW.

6.10.20 O&M i) The vender should introduce the structure and functions of the O&M

system of proposed GGSN, including:

113

a) Alarm management b) Equipment management c) Message tracing d) Data configuration management e) Security management f) Log management

ii) The O&M system should signaling tracing and interface based signaling tracing. (include Gb, Iu, Gn, Gp, Gi, Gr, Gd, Gf, Ge, Gs, Go, Gx, Gy, Lg). The signaling tracing function should have signaling analyzing function. This function should not from the third party’s software.

iii) The O&M system should support subscriber tracing by IMSI or MSISDN

6.10.21 Requirements for CG(Charging Gateway)

General requirements for CG

The proposed CG(Charging Gateway) equipment is a product developed with well compliance with relevant 3GPP standards for UMTS solutions. It can help Carriers to construct cost-efficient and future-oriented mobile communication networks.

i) The proposed CG equipment is located between the UMTS network entities (including GGSN and SGSN) and the billing center, and provides the mechanism to transfer charging information from the UMTS network entities to the billing center. It shall support R98/R99/R4/R5 protocol and related functions:

a) Collecting CDRs from the UMTS network entities. b) Intermediating CDR storage buffering. c) Processing CDR data. d) Transferring the CDR data to the Billing Centre.

ii) The proposed CG should support ANS.1 format and FTP/FTAM/SFTP transmission protocol.

iii) The Vender shall provide Charging Gateway (CG) as a centralized separate network element.

iv) The Vender shall describe the CGF implementation for UMTS and GPRS network nodes with reference to relevant 3GPP standards

v) The Vender shall describe supported formats of CDRs. a) G-CDR; b) S-CDR; c) M-CDR; d) S-SMO-CDR; e) S-SMT-CDR; f) LCS-MO-CDR; g) LCS-MT-CDR;

114

h) LCS-NI-CDR; vi) The Vender shall list all CG supported interfaces with network elements

and billing system. vii) The Vender shall describe supported file management and transfer

mechanisms towards billing systems. viii)The CG shall be able to buffer CDRs from a number of packet core

network elements for a period of time. ix) The Vender is requested to provide capacity figures for the CG, e.g. buffer

sizes, number of CDRs processed per second, etc. x) Partial and periodical output of charging data shall be supported. The

Vender shall provide information on each supported mechanisms. xi) Fail over mechanism shall be described. CDR duplication prevention

mechanism shall be implemented.

6.10.22 Requirements for NAU (Network Auxiliary Unit)

i) General

In addition to the GSN core portion (SGSN & GGSN) and CG, the Vender shall include internet support server nodes to support GPRS/UMTS services.

ii) DNS

The Vender shall support the Domain Name Server Function which resolves logical GSN names (Internet domain and host name) to GSN addresses according to RFC 1034. Such functionality allows resolution of any name for GSN's and other nodes within the packet domain PLMN backbone network. The GSN system shall also have a redundancy DNS server.

iii) DHCP

The GSN system shall support DHCP for the management of IP address allocation. The Vender shall provide details on the solution offered.

iv) BG

Two intra-PLMN backbone networks are connected via the Gp interface using Border Gateways (BGs) and an inter-PLMN backbone network. The inter-PLMN backbone network is selected by a roaming agreement that includes the BG security functionality. The BG is not defined within the scope of the packet domain in the 3GPP specifications. The inter-PLMN backbone can be a Packet Data Network, e.g., the public Internet or a leased line.

a) It shall be possible to interface other 2G and 3G PLMNs. Administration and security on these interfaces shall be handled by Border Gateways (BGs). A BG may be a separate entity or it may be integrated into a GGSN.

b) The PLMNs shall be inter-connected via a PDN, but as the

115

characteristics of this interface will depend on roaming agreements with other PLMNs, the BG needs to be configurable.

c) Sessions between Carrier's own GGSNs may also be done via BGs. The BG shall constitute router and firewall functionality.

v) FW

a) The interconnection to external PDNs or inter-PLMN (GRX) backbone shall be done via Firewalls (FW s). FW s can be implemented either as stand-alone devices or as resident functionality in the GGSN and BG.

b) The FW shall support the following functions: 1. Stateful firewall 2. Packet filtering based on IP address or IP address pools … 3. Application level gateway (proxy) 4. Network address translating – NAT, NAPT 5. Access control lists 6. Secure IPSec connection with DES, 3DES, … encryption 7. Advantage is support for traffic shaping (per interface, per user

session, per flow) 8. Logging of all events with important pieces of information as a date,

time, IP addresses, interfaces 9. Static routing 10. Dynamic routing protocols OSPF v. 2 and RIP v. 2. 11. In case of NAT/NAPT there shall be possibility to log time and

combination of public IP, private IP and ports, which was used by one customer.

6.11 Over-the-Air (OTA) Server:

6.11.1 The OTA platform shall be suitably dimensioned to cater to an extent of 60% of the Subscriber Capacity.

6.11.2 OTA platform should be capable of Over the Air updates to SIM/USIM cards from all SIM/USIM vendors without any dependence on any SIM/USIM card manufacturer. If required, the OTA platform shall be able to manage the existing SIM cards also. The OTA platform shall be capable of generating Public and Private keys for writing to individual SIM cards at a Point of Sale(MTML Registration Authority) and be capable of writing the keys to the SIM card using a card reader as per PKCS 15 Standard.

6.11.3 The OTA platform should be able to manage menu structure on SIM card whereby SIM applets should be able to interact with application using SMS as bearer transport to OTA server. The Browser shall be able to encrypt and sign application data as per the PKCS 7 standard for mobile commerce and

116

authentication applications using SIM based private keys stored on the SIM card as per PKCS#15 standards. Additionally, the browser shall be able to execute symmetric security schemes for signature and ciphering to enable secure m-commerce applications.

6.11.4 The OTA platform shall be capable of storing network information, such as to provide cell-id / landmark based subscriber location information to SIM browser applications.

6.11.5 OTA platform shall have the capability to send and receive 7 bit and 8 bit encoding messages.

6.11.6 OTA platform shall communicate with the GSM/W CDMA network entity using the SS7 interface, so as to provide higher capacity on the messaging interface.

6.11.7 The OTA platform shall have SS7 interface towards GMSC or MSC SERVER AND MEDIA GATEWAY and shall be able to perform the message transport functions as per GSM 03.48, without using the MTML SMSC.

6.11.8 OTA platform shall have interfaces to directly interconnect with gateway MSCs of each licensed service area.

6.11.9 OTA platform shall have the functionality to receive MO messages over SMPP interface.

6.11.10 OTA platform shall have GUI interfaces for operations management and administration activities

6.11.11 OTA platform shall support message concatenation 6.11.12 OTA platform shall have "More Messages to Send" feature to enable faster

delivery of concatenated messages 6.11.13 OTA platform shall provide service menu management on the SIM card for

at least two levels. I.e. it should be possible to modify a service by adding or deleting second level SIM Service Menus, without deleting or adding the Main Service Menu.

6.11.14 OTA platform shall provide self-provisioning feature for the subscriber on web interface as well as by the subscriber on SIM card using the menu options. OTA platform shall be suitably protected through a firewall to be provided by vendor.

6.11.15 OTA platform shall support Batch OTA updates for bulk updates and shall also be able to push 8-bit messages.

6.11.16 Services integrated with OTA platform

6.11.16.1 Preferred Roaming Application

a) The OTA server must have capability to provide MTML a Preferred Roaming application, that enables its subscribers to remain in the Preferred Roaming networks configured in the subscribers SIM, while roaming.

b) The Roaming Management capability in OTA shall be able to facilitate

automatic (without subscriber intervention or knowledge) preferred network selection in a visited Network, where GSM service exists from two or more GSM Service Providers, and MTML has Roaming agreements with those other networks.

c) The OTA shall be able to connect to the SS7 roaming links of MTML, and use

dynamic network information such as VLR registration, to detect a subscriber's PLMN selection, check the SIM subscription information for preferred networks, and be able to make OTA updates to the SIM card

117

attributes, that facilitates the movement of subscriber from the non-preferred network to the Preferred Network in real time.

d) The Preferred Roaming application should be able to make differential SIM

updates depending on the Handset capability. The Handset capability shall be either discovered automatically in real time, or be configurable in the OTA database such as to make the SIM update procedure selection in real time.

e) The purchaser must be able to configure such timers, as can facilitate

masking of the SIM updates for a time since the last SIM update activity. The purchaser must also be able to configure the preferred vs Non-preferred PLMN information on the OTA database. It shall also be able to configure a set of 'In consequential' PLMNs, where no SIM update activity is carried out for purposes of Roaming Management.

6.11.16.2 Device Configuration for GPRS / MMS / WAP Settings (i) MTML's networks shall be GPRS & MMS capable, and a solution shall be

provided for automatic over the air setup of Handsets for GPRS, WAP, and MMS & E-MAIL settings.

(ii) The Solution should maintain a repository of Terminal IMEI vs Terminal

Capabilities. The Solution should be able to send Handset specific WAP, MMS, GPRS settings over the Air.

(iii) The OTA systems solution should be able to automatically detect the Phone

IMEI, each time a SIM is inserted into a New Phone using network based detection mechanism. The Solution should then be able to Over the Air setup the Device with the handset specific, Network specific settings for WAP / GPRS / MMS / E-mail.

(iv) There should be an alternate Web interface for Customer Care to set up a

subscriber's device. 6.12 APPLICATION AND ADVERTISEMENT PUSH SERVER: 6.12.1 The server shall interface towards WAP server and OTA server. The

solution shall be able to dispatch W ML pages, carrying New Applications or Promotional Messages, to a targeted set of subscribers (10% through WAP & remaining through OTA) Such messages should provide an interactive capability for the subscriber to respond with the click of a Menu Item to reach Internet Pages embedded in the W ML page.

6.12.2 The server shall be dimensioned for meeting the requirement of 60% subscribers.

6.13 OPERATIONS SUPPORT SYSTEM (OSS)

6.13.1 Operations Support System to meet the requirements as envisaged in the relevant TEC GRs may be quoted.

6.13.2 The OSS should be centrally located to control, configure and monitor faults and performance of the complete network elements. It shall provide all the functionalities and features as defined in TEC GR pertaining to configuration management, performance management and fault

118

management etc. In addition, the system shall provide following functionalities and features-

i. Periodic presentation, at settable intervals, of brief as well as detailed status/analysis of network in network wise, BSC wise, Cell wise forms indicating major parameters as applicable such as:

(I) Call Volume (II) Call Set up success rate (III) Call success rate (IV) Drop rate (V) Traffic in erlangs (VI) Congestion Key/Grade Of Service (VII) Hand over failure rate (VIII) Call Minutes (l/c, 0/G) (IX) TCH/SDCCH Congestion (X) Max TCH Available/used (%) (XI) Max SDCCH Available /Used (%) (XII) BSC-TXCDR trunk usage

ii. The above parameters/measurements shall be presented in EXCEL sheets in tabular as well as well as in chart forms. Facility to display Snap shots of selected parameters during different periods shall be provided. It shall also be possible to display all sorts of dynamics in continuous as well as discreet modes. (E.g. Total BSC W ise traffic on different days of the same week or on the same day of different weeks, the build up of congestion on new year eve etc)

iii. Quality Checks: The OSS shall be equipped with appropriate tools to perform all kinds of analyses based on quality related parameters such as interference levels, BERs, FERs, hand overs, etc. It shall provide analysis such as:

a. Percentage of calls with RXQual 0 to 3 in a particular cell or Average RxQual/CSSR for TA between 0 to 5 as against the same for TA between 6 to 10.

b. RXQual in a cell over different periods of the day

iv. Periodic automated reporting of downtimes of network elements such as BTSs, BSCs etc on triggers, which are time-based as well as severity-based thresholds.

6.13.3 The hardware and software implementation should be independent of the current OMCs and should be server based with a minimum of seven clients. The dimensioning should be such that all the data required for post processing can be stored for a minimum one months on line and there should be provision for storage one year externally.

6.13.4 There also should be an integrated or separate tool with user friendly menus for call traces based on IMSI, TMSI, IMEI or MSISDN to give the Timing Advance, Current RX Quality, Time slot, TRX Et cell identity, CIC etc in order to facilitate problem isolation as well as other operational purposes.

6.13.5 GUI display showing menu driven options of various network elements for display of event/ alarms, configuration management, performance

119

management, security management, fault management down to board level and network statistics.

6.13.6 Historical data for a minimum period of one month to generate detailed daily reports and summary weekly, fortnightly, monthly, quarterly, half yearly and yearly reports should be available online and there should be provision for storage one year externally.

6.13.7 The OMC(R) and OMC (S) shall also support full functionality for GPRS, EDGE & W CDMA. The OMC(R) shall provide on-line configuration and administration of EDGE carriers and for GPRS TCHs in BTS. Performance monitoring system (PMS) shall provide all statistical reports for GPRS, EDGE & W CDMA for usage analysis, performance analysis and for future planning. Necessary post-processing tools shall also be provided along with OMC for this purpose.

6.14 GSM BSS :

Base Station Sub System as per GSM 3GPP Standards is to be quoted.

6.14.1 General requirements 1. Products specifications shall be provided in sufficient detail to enable full

understanding the GERAN products offered by the Tender Participant.

2. The tender participant shall specify the SW version proposed in tender.

3. The supplied system shall have no effect on service when BTS expansion and frequency modification with in the same band.

120

6.14.2 BSC/TC (Transcoder) architecture 1. The supplied BSC shall be based on IP platform. It shall support both TDM

switching for the TDM based services and IP switching for the IP based services.

2. The supplied BSC shall support embedded PCU which shall be formed as boards. The tender participant shall specify the embedded PCU architecture.

3. The supplied BSC shall support embedded TC which shall be formed as boards. It is important if the BSC is deployed together with the core network. The tender participant shall specify the embedded TC architecture.

4. Only one High Capacity BSCs should be provided.

6.14.3 BSC/TC dimensioning, feature, configurations and capacity 1. The tender participant shall indicate the capacity & configurations of

BSC/TC provided.

2. The BSC shall support at least 1000 TRX which shall be accommodated just in one cabinet. The same single BSC cabinet shall also be possible to accommodate PCU and TC.

3. The supplied BSC capacity and performance shall not be decreased because of Packet Service. The Tender Participant should specify the TRX capacity of single cabinet BSC when 50% channels are used as EPDCH.

4. The Transcoders shall fully support Full Rate, Half Rate and AMR FR/HR speech coding dynamically allocated in a common transcoder pool per BSC. The tender supplier shall specify the mechanism of TC pooling, any influences on capacity by type of used codec shall be pointed out.

5. The Tender Participant shall state typical downtime caused by BSC/TC capacity upgrade, if any.

6. The supplied BSC shall support Multi-band Sharing in one BSC.

7. The Tender Participant should provide full support of ciphering in BSC/TC.

6.14.4 Interface 1. The Tender Participant shall specify the maximum number of ports for

available BSC/TC configurations, including the flexibility with mixing different physical interface types.

2. The Tender Participant shall describe the boards available to support these physical interfaces and give the number of ports for each board.

3. The Tender participant should support BSC/TC configuration with High Speed Link (HSL).

6.14.5 Power supply requirements and power consumption 1. The BSC/TC shall operate with -48V DC.

121

2. The BSC/TC shall support redundant power supply to ensure the system operation keeping working without power interruption in case that either fails. The tender participant shall specify the redundancy arrangement.

3. The tender participant shall specify the power consumption of the supplied BSC/TC. The tender participant could list the power consumption values of typical configuration.

6.14.6 BSC/TC mechanical construction 1. The Tender Participant shall state the weight, cabinet dimension, maximum

floor loading and necessary area for proposed configuration.

6.14.7 BSC/TC reliability 1. All the critical modules/units of the BSC shall support 1+1 redundancy mode

and resource pooling processing modules/units shall support N+1 redundancy mode. The tender participant shall specify the mechanism of module/units redundancy of BSC.

2. The Tender Participant has to describe the hardware availability performance of the BSC/TC. The target availability should exceed 99.999 %.

3. The Tender Participant shall describe all types BSC/TC restart and their impact on service. The Tender participant shall give restart time for each type of restart and indicate if the BSC/TC is partly or completely out of service during the restart.

6.14.8 Transcoder 1. Average Traffic per subscriber – 25mE

2. Transcoder should preferably work in pool so as to give optimum

performance.

3. Entire Transcoder capacity for all codes (AMR/FR/EFR).

6.15 Base Transceiver Station

6.15.1 BTS requirements

Supplier shall present his full range of BTS equipment. This includes indoor and outdoor cabinets of different sizes, purposes and capabilities. In addition to the general GSM requirements, Purchaser wants to emphasize the following issues:

6.15.2 BTS equipment

1. The successful bidder may quote distributed BTS (SDR) containg BBU & RRU units. The BBU & RRU can be software upgradable to HSPA under the same frequency band.

2. The minimum number of BTS sites expected to provide the desired coverage, as per our estimation, is 110. However, if the bidder feels that more number of

122

BTSs are required to meet the desired coverage/ capacity requirements, the same should be quoted accordingly.

3. Purchaser plans to deploy around 50 indoor BTSs (BBU only) in the existing shelters and remaining 60 outdoor type BTSs. The efforts should be made to use the maximum number of existing CDMA BTS (51/56 sites) infrastructure (shelter, tower, power etc.).

6.15.3 BTS product specification

Specification BTS

Indoor

BTS Outdoor BTS BBU

Capacity 1 Nb. of TRX / cabinet 2 Nb. of carrier / site 3 Nb. of cell / site

4 Nb. of transmission

Port Performance 1 Frequency band

2 Transmitter power

output

3

TOC (Top of cabinet) output power per carrier

4

Receive sensitivity level (static, 2-way, 4-way)

Engineering

Parameters

1 Dimensions (H*W *D

mm) 2 W eight (Kg) 3 Power supply 4 W orking temperature 5 Cooling mode Reliability 1 System Availability 2 MTBF 3 MTTR

6.15.4 BTS architecture and layout

1. The Tender Participant shall describe and illustrate the general architecture for each BTS type including radio units, baseband, control, and transport/transmission parts.

2. The supplied BTS shall be equipped with Dual Density Transceiver Unit at least.

3. All supplied BTS shall support GPRS/ EDGE for each sector of sites.

123

4. The supplied BTS shall support Abis over IP.

5. The supplied BTS shall be design with simplified modular design, in order to easy upgrade, fast engineering and convenient maintenance.

6. The supplied macro BTS shall be with high integration architecture, it can support stack installation. The tender shall specify the stack mode.

7. The tender participant shall propose distributed type BTS for fast deployment. The supplied BTS can be separated to install separately. The RF unit can be mounted on pole or tower where close to antenna in order to eliminate feeder loss to get better coverage. The supplier shall explain if there are any limitations while installing distributed type BTS near to the antenna.

8. The tender participant shall clearly explain the others flexibility of installing the distributed type BTS.

9. The supplied remote RF unit shall be designed on nature cooling mode to reduce noise, lower power consumption, and to improve reliability.

10. The supplied BTS shall be able to provide multi-carrier Transceiver Unit or in the roadmap, at least 6 TRX/Unit. The tender participant shall specify the specification multi-carrier Transceiver Unit.

11. In case of multi-carrier Transceiver unit configuration, the supplied BTS shall not be configured with combiner.

6.15.5 BTS configuration and capacity 1. The supplied BTS equipment shall support multi-band cells in one rack.

2. In case of chain networking, the supplied BTS shall support Abis bypass to guarantee no effect on other BTS operation when one of them is broken.

3. The Tender Participant shall provide full HW support of ciphering in BTS.

4. The tender participant shall provide configuration principle of provided BTSs.

6.15.6 BTS power consumption and power supply requirements 1. The tender participant shall state the typical and maximum power

consumption for every type of supplied base stations by filling in the following table.

The output power of TOC in S222 configuration shall be 30W at least (Cabinet Type BTS), 30W at least (Distributed type BTS) per career;

The output power of TOC in S333 configuration shall be 20W at least (Cabinet Type BTS), 20W at least (Distributed type BTS) per career.

6.15.7 BTS Reliability 1. The Tender Participant shall specify the BTS MTBF from maintenance point of

view by combining the MTBF figures of all plug-in units in the configuration.

124

2. The Tender Participant shall describe all types of BTS restart and their impact on service. The Tender Participant shall give restart time for each type of restart and indicate if the BTS is partly or completely out of service during the restart.

3. BBU control card should support active and standby configuration. 4. The vendor shall provide external lightning proof device for outdoor BTS.

6.15.8 Environment characteristics 1. The Tender Participant shall aim to minimize any audible noise from their

equipment and explain means to achieve this.

6.15.9 Outdoor solution requirements 1. The supplied out BTS equipments shall fulfil W eather Proof Protection based on

ETSI Standard. The tender participant shall specify the water proof and dustproof level of supplied outdoor units.

2. The Tender Participant’s outdoor BTS’s shall utilize a natural air flow or forced air cooling mechanism. It shall not be necessary to use an air conditioner as a cooling mechanism for any of these BTS although this may be offered as an option.

3. The supplied outdoor BTS equipment shall withstand the local atmospheric and weather conditions. The outdoor units’ working temperature shall range from -40oC to 45oC without air conditioner.

4. Supplier shall purpose mini outdoor BTS for medium and low capacity configuration which may have flexible installation mode like installation on the poles, walls, tower etc. The tender participant shall state the different installation modes and limitations.

6.15.10 Future evolution 1. The supplied BTS shall support 2G/3G configuration and be able to share cabinet

with NodeB. The tender participant shall specify the 2G/3G configuration.

2. The Tender Participant shall provide a roadmap for the introduction of new BTS hardware, hardware modules or software.

3. The Tender Participant shall describe his solutions for efficient co-siting of 2G and 3G base stations.

4. The supplied BTS shall use the same platform with 3G NodeB so that it can easily be upgraded to 3G NodeB and support flexible configuration between 2G BTS and 3G NodeB as per the user demand.

5. The supplied Macro BTS shall mix configuration or inter-changeable with 2G RF unit and 3G RF unit in one cabinet. Any limitation of mix configuration shall be stated.

6. The Tender Participant shall specify all dedicated hardware and software required in the supplied BTS to support advanced GERAN services.

7. Regarding future evolution, most units of supplied BTS shall be reused. The tender participant shall specify all dedicated hardware and software required in the supplied BTS to upgrade from 2G to 3G.

125

6.16 GERAN features requirements Purchaser is aiming to build a high-quality network with state of the art functionality and features. The tender participant shall detail all his GERAN network features. All other network elements, which are influenced by such features (MSC, BSC, BTS, and OMC) shall be addressed clearly. Any dependencies between features of BSS and features required in other network elements shall be clearly stated. The full range of BSC/BTS Equipment tendered shall support the following GERAN functionality and features. W here any feature is not available, the availability date shall be stated in the GERAN feature roadmap.

6.16.1 General requirements 1. The Tender Participant shall clearly indicate SW version proposed in the Tender.

2. That software updates and new software releases shall be loaded to GERAN network elements with minimal downtime and impact on live traffic. The tender participant shall declare any impacts during the activation of the new software.

3. The supplied system shall support full multi-band networking.

6.16.2 Transmission 1. The tender participant shall describe its dynamic resource allocation for Abis

resources when it is supported in the PS service and CS service.

2. The supplied system shall support flex assignation on Ater interface. This function will assign Ater interface resources according to the needs, e.g. while using HR this function will assign 8K TS transmission resource for Ater interface instead of assigning 16K TS transmission resource.

3. The supplied system shall support local switching function both on BSC and on BTS to reduce transmission, as and when the standards are frozen from 3GPP. The tender participant shall also specify, whether there is any modification on GERAN part.

4. While supporting local switching, there shall not be any impact on NSS part and GERAN part can work with the NSS part provided by any other vendor.

5. The tender participant shall support Abis/A/Ater/Gb over satellite

6. The tender participant shall support EDGE over satellite.

7. The supplied system shall support Gb over IP

8. The supplied system shall support 2G and 3G co-transmission based on TDM or IP.

6.16.3 Intelligent power management 1. The supplied system shall support assign the TCH to the TS of BCCH carrying

TRX unit in priority.

126

2. The supplied system shall support intelligent power shutdown of PA based on TS level. The tender participant shall describe the TS level power shutdown mechanism.

6.16.4 Voice Service 1. The supplied system shall support EFR/FR/HR. The tender participant shall state

the limitations in capacity of BSS product while supporting HR.

2. The supplied system shall support AMR FR/ AMR HR. The tender participant shall list all necessary additional hardware and software requirements on the BTS/BSC/TC, if any.

3. The supplied system shall support dynamic adjustment between FR/HR, AMR FR/ AMR HR during a call to balance the capacity and voice quality. The tender participant shall specify the dynamic adjustment mechanism.

4. The supplied system shall support TFO/TrFO, support AMR TFO.

5. The tender participant shall provide at least 5 references of their HR applications out of the country of origin. Out of which two should at least have 2000TRX in use.

6. The tender participant should provide application list and references for their AMR application out of the country of origin.

7. The supplied system shall support AMR coding rate threshold adaptive adjustment.

6.16.5 Handover The supplied system shall support kinds of handover as follows:

Description

Basic Handover: intra-BSC handover (supporting intra-cell handover and intra-BTS inter-cell handover), inter-BSC intra-MSC handover inter-MSC handover PBGT Handover Signal Level Rapid Fall Handover: This handover algorithm is sensitive to the signal level change of the users. It can effectively reduce the call drops due to the rapid change of signal level. Load Handover Layered and Hierarchical Handover Directed Retry SDCCH Handover

6.16.6 System reliability 1. The supplied system shall support BCCH TRX Cooperation and baseband FH

TRX cooperation, in case of BCCH TRX failure or baseband FH TRX failure. The cell can handle it automatically through the TRX Cooperation function, and cell services wouldn’t be affected.

2. The supplied system shall support MSC pool. Any limitation shall be stated.

127

3. The supplied system shall support SGSN pool. Any limitation shall be stated.

4. The boards of supplied system, except those of the resource pool, shall support 1+1 board backup. W hen the active board is faulty or needs replacing, the services would be switched to the standby board for continuous operation of the system. The tender participant shall specify the duration of active/standby board switchover, and shall state the effect on ongoing service.

6.16.7 Coverage enhancement 1. The supplied system shall support Power Amplfying Technology, which can

increase the TRX output power.

2. The supplied system shall support Transmit Diversity and 4-way receiver Diversity.

3. The tender participant shall support radio head remote installation, which enables fewer feeders’ loose to improve the coverage effect.

6.17 GPRS/EDGE service

6.17.1 General requirements 1. The supplied system shall be EDGE enabled for all BTSs.

2. The supplied system shall support GPRS CS1~CS4, EDGE MCS1~MCS9.

3. To improve the efficiency of G-Abis, the supplied system shall support the unit of 16 kbit/s TS assignment for PS service on Aibs. The tender participant shall specify the TS allocation mode on Abis for PS service.

4. The supplied EDGE system shall support Link Adaptation and Incremental Redundancy in UL/DL.

6.17.2 GPRS/EDGE enhancement 1. The supplied PS system shall support extended TBF.

2. The supplied PS system shall support Extended Dynamic Allocation.

3. The supplied system shall provide functions which reduce access delay, such as Immediate Assignment Function Moved down to the BTS. The tender participant shall describe these functions.

4. The supplied system shall support NACC (Network Assisted Cell Change)

6.17.3 GPRS/EDGE resource enhancement 1. The supplied PS system shall support load sharing of channels in order to balance

the load between heavy load channel and light load channel.

128

2. The supplied system shall support adaptive adjustment of uplink and downlink channels according to data service load.

3. The supplied system shall support PDCH dynamic adjustment, which allows dynamic PDCH/TCH channels can be converted in real time based on the data service and the voice service.

6.17.4 QoS The QoS class shall be up to Streaming.

6.17.5 Public Voice Group/ Broadcast Call Service 1. The supplied system shall support public voice group call service.

2. The supplied system shall support public voice broadcast call service.

6.17.6 O&M 1. The supplied system shall be able to manage 2G and 3G network at the same

time, including RAN and Core part.

2. The supplied system shall support CORBA, OpenDB, SNMP, FTP north-bound interface.

3. The supplied BSS equipments shall support remote upgrade.

4. The supplied system shall support BTS Antenna System Connection Detection to locate the problems in the BTS antenna system.

5. The supplied OM system shall support script development platform which provides script edit, script debug, run script, time mission, etc. easier for the operator create their own automatic daily OM procedure.

6. The supplied system should support signalling tracing for A, Ater, Gb, Abis, Um etc.

7. The supplied system should support signalling tracing upto user level (both CS and PS user).

8. In order to avoid the fault in the network, the offered system should be able to do periodic health check up for the following items and automatically output a network quality report, including BSC running status check, alarm check, KPI status check, version matching check, etc. The tender participant shall state whether these check up can be done automatically as per user defined items and time.

6.17.7 General requirements 1. Products specifications shall be provided in sufficient detail to enable full

understanding the GERAN products offered by the Tender Participant.

2. The tender participant shall specify the SW version proposed in tender.

3. The tender participant shall provide at least 5 contract reference (at least 3 networks with more than 10000 TRXs/ reference) for the proposed BSS Network.

4. The supplied system shall keep no effect on service when BTS expansion and frequency modification.

129

5. The tender participant shall provide a figure for All IP BSS solution. It should include Abis, A and Gb interface in the BSS network.

6. The tender participant shall specify clear what kinds of new NEs or equipments needs to be added when the BSS network evolves from A over IP only to All IP Network.

The tender participant shall provide at least 1 BSS contract reference for the commercial All IP.

OPERATION & SUPERVISORY SYSTEM 6.18.1 The communication facilities provided for exchange of information between

the system and the maintenance and operating personnel shall include facilities for a system test and control and alarm indication.

6.18.2 Input/output terminals shall be capable of transmitting/receiving characters of

a subset of the Alphabet No.5 as specified in ITU-T recommendation Z.314. The printing/display device shall print/display different graphic symbols for the digit zero and the capital letter O. The Input/Output terminal shall have the English Keyboard. Capabilities of visual display terminals shall be as per ITU-T Recommendation Z-322. Terminal emulation software and any standard operating system shall be available in the PC.

6.18.3 Adequate number of man-machine interfaces shall be available to facilitate

various types of system administrations listed. 6.18.4 If provision is made for monitoring from a remote terminal, it shall be ensured

that the data links conform to the ITU-T Recommendation Q.513. Care shall be taken that the reliability of the data links does not, in any way affect the reliability of the system. Special provision shall also be made for transmission of a failure signal even when the system is unable to transmit an output message.

6.18.5 A suitable alarm and display system shall be provided for a continuous

indication of the system status. The alarm system shall also provide an alarm to indicate the failure of power supply to the alarm circuits themselves. Provision shall be available to extend indications to a centralized place.

6.18.6 On a fault condition the system shall identify the faulty sub-system

automatically and takes it out of service. This shall automatically bring in the diagnostic programmes for diagnosis. In such cases the details of the sub-systems taken out for executing diagnostic programmes shall be printed out. Availability of Intelligent terminal (PC) to display the location of bay, shelf, PCB on the screen would be desirable. The dimensioning of processing capacity shall be such that the normal call processing is not effected due to invocation of any diagnostic program.

6.18.7 Operations and Maintenance Centre (OMC)

a) The OMC allows the centralized operation of the various units in the

system and the functions needed to maintain the sub systems. The OMC provides the dynamic monitoring and controlling of the network

130

management functions for Operation and Maintenance (O&M). The OMC shall support Graphical User Interface (GUI) for operation and standard TMN interfaces as specified in ITU-T Rec. M-3010 & M-3020.

b) The overall objective of OMC is that neither equipment failure nor

human error in the OMC implementation should render the OMC and /or the part of the network it supervises, out of service.

c) OMC shall be a carrier grade system with full redundancy and

scalability. It shall be possible to have remote workstations with the OMC, with complete GUI tools for O & M of the system at the remote locations. It shall support north-bound interface like SNMP, Corba, TCP / IP, CMIP etc., to enable it to work with a remote NMS.

d) The Operation & Maintenance Centre (OMC) shall be capable of

performing the following functions: -

(i) Event/Alarm Management: Alarms shall be presented to the operator via software programs and tools for easy presentation and interpretation, for easy maintenance and to locate faults of all managed elements of the network. Events shall be logged for future use.

(ii) Configuration Management: OMC shall provide real time configuration database access to manage the software loading and version tracking, support for addition, deletion and change of network element parameters.

(iii) Performance Management: OMC shall provide tools for the collection of statistics and call information into a database and logging file. Data shall be viewed using tabular or graphical reports on the GUI terminal.

(iv) Security Management: OMC shall provide password and login access to the system to prevent any unauthorized access to the system.

(v) Fault Management: OMC shall provide capability to query and change device states and provide control for system diagnostics. It shall be possible to monitor different protocols in real-time.

(vi) Network statistics: OMC shall provide data related to channel occupancy, rejected calls etc. with visual display of faulty elements of the network.

6.19 GENERAL ENGINEERING AND MAINTENANCE REQUIREMENTS 6.19.1 Equipment Practice 6.19.1.1 Dimensions, Weight & Mounting: The equipment shall each be of self

supported cabinet or rack type. Maximum height of rack shall be restricted to 2100mm. To have greater flexibility for operations, front-only serviceable racks are preferred. The outdoor RN equipment shall be self - supported weather proof cabinet and capable of mounting on suitable structure. Actual dimension and weight of each of the equipment shall be indicated by the equipment supplier. Accessories for mounting equipment, Antenna and feeder cable (if required) shall be specified & supplied along with the equipment.

131

6.19.1.2 Power Supply: The power supply unit shall form an integral part of the

equipment and shall have protection against input over-voltage, short circuit, input reverse polarity protection & shall have visual indication for input under voltage.

6.19.1.3 General Equipment Practices:

(i) All cards of the same type and design shall be interchangeable without necessitating special adjustments.

(ii) All metal parts of frames, supports, etc. shall be mechanically rugged and constructed of corrosion resistant material or treated with anti-corrosive finish. All equipment shall have a tropical finish.

(iii) Suitable test access points and displays shall be provided for facilitating maintenance. Test access points shall preferably be located on the front side of the bay. All visual display devices shall be located in a position attracting immediate attention of the operating and maintenance personnel. Suitable extension boards shall be provided to facilitate access to components on a printed card.

(iv) The material used for all printed boards shall be expoxy or equivalent (FR4). It shall not buckle due to a load of the assembled board or due to temperature changes occurring under normal circuit operations.

(v) The supplier shall indicate whether printed board connectors are of edge type or plug-and-socket type. They shall not be easily damaged during replacements and removals. The contact particulars as well as life test performance on contact resistance for each type of connector shall be supplied.

(vi) All components and material used in the equipment shall be non inflammable or in absence of it, self-extinguishable. They shall be fully tropicalised.

(vii) The supplier shall indicate the various types of cables and wires used in the system. Detailed particulars of any special wires and cables like standardized coaxial, screened cable, etc. shall be furnished with their actual usage in the system.

(viii) The buses, if any, shall be suitably protected against electrical and magnetic interference from neighbouring systems (like electromechanical systems, fluorescent tubes, motors, etc). The supplier shall indicate the care taken in the design and location of the bus system for such interference.

(ix) The points for connecting the power supplies to the different plug-in cards shall be standardized and mechanically interchangeable. Otherwise suitable mechanical safeguards shall be provided to prevent damage due to accidental inter-change of cards.

(x) The supplier shall indicate the requirement at the external interface against induced voltages and currents due to lightning, high power system, etc.

(xi) The system shall provide for isolation and protection from accidental high voltage power contact.

132

6.19.2 Markings

(i) Equipment on the bay, whether of fixed or plug-in type, shall be suitably marked. Identification of type of cards in its connector shall be possible without necessitating its removal. Any plug-in component shall be marked with sufficient information for its complete identification.

(ii) The marking on the equipment and the cables shall be the same as that used on the schematic drawings, cabling lines etc., in the documentation supplied with the equipment.

(iii) All instructions, labels, or any other marking on the equipment shall be perfectly legible and in the English language.

(iv) Colour code used for power feeding bus-bars/cables and earth shall be identical for a given voltage throughout the equipment.

(v) Fuses shall have a suitable marking for the different ratings to enable easy identification and replacement.

(vi) Marking shall ensure easy traceability. (vii) The plug-in units whose removal or insertion (while the equipment is

in operation) might endanger the reliability or performance of the equipment -shall have suitable protection and caution marking.

(viii) Each sub-assembly shall be clearly marked to show its functions and circuit reference so that its complete description can be located in the handbook.

(ix) The components shall be marked with their schematic references so that they are identifiable from the component layout diagram in the handbook.

(x) All controls, switches, indicators etc. shall be clearly marked to show their circuit designations and functions.

(xi) Each terminal block and terminal shall be marked with an identifying code.

6.19.3 Processors

(i) Adequate backup memory shall be provided. Direct memory access, with suitable safeguards, is preferred for information flow between the backup memories on the one and the main memories and the input/output devices on the other.

(ii) Provision shall be made to prevent the loss/alteration of memory contents due to power failures, improper operating procedures and the procedures for restoring the system to its normal state, etc.

(iii) Dimensioning standards shall be evolved for the various types of memories used. This shall also include standards for provisioning of the required spare memory capacity.

(vi) The system shall support hard-disk (in duplicate) of suitable capacity, to provide storage of charging information, detailed billing information, traffic statistics, command log, system software, office data etc.

6.19.4 Software 6.19.4.1General

(i) The software shall be modular and structured.

133

(ii) The design of the software shall be such that the system is easy to handle both during installation and day-to-day operations as well as during expansions.

(iii) The functional modularity of the software shall permit introduction of changes wherever necessary with least impact on other modules.

(iv) The architecture of the software shall be open ended so that the growth and addition of new features can be handled in practice without any need of redesign of the software.

(v) Adequate flexibility shall be available to easily adopt changes in service features and facilities and technological evolution in hardware.

(vi) The design shall be such that propagation of software faults is contained.

(vii) The software shall provide sufficient checks to monitor the correct functioning of the system.

(viii) Test programs shall include fault tracing for detection and localisation of system faults.

(ix) The normal operation of the system should not be adversely affected while undertaking : (a) Extension to system (Hardware expansion) (b) Enhancement of system facilities. (c) Correction to programs or functional blocks.

(x) The software supporting documentation shall be in English. Any update in the software at a later stage to overcome deficiencies of the system due to bugs, compatibility etc., shall be provided free of cost by the equipment supplier.

(xi) The equipment supplier shall undertake to supply on continuing basis all software updates. These updates may include new features and services and other maintenance updates. The software up-gradation shall be possible with minimum interruption to the service.

(xii) The equipment supplier shall provide any software modification necessary due to modification of software in the inter-working with other network elements.

6.19.4.2 Diagnostic programs to localise hardware faults

(i) On a faulty condition, the software shall provide for isolating the faulty sub-system and then automatically bring in the diagnostic programs for diagnostic purposes.

(ii) It shall preferably be possible to diagnose to single PCB level in atleast 95% of the types of PCBs.

6.19.4.3 Software of charge records

(i) Arrangements shall exist for dumping the charging information to non-volatile backup memories automatically at periodic intervals.

(ii) Facility shall be available for changing this interval by a Man-Machine Command.

(iii) The charging information records shall be sufficiently protected against modifications by man-Machine Commands.

134

6.19.4.4 Right to use: There shall be no imposition of any sort of precondition on the ‘Right to Use’ of software.

6.19.5 Man-Machine Communication (MMC)

6.19.5.1 Man-Machine Language (MML)

(i) Man-machine interface language shall be based on ITU-T Recommendations Z 301 to Z 341.

(ii) The Man-Machine Language (MML) shall be in English. Commands shall be English based and responses shall be in English.

(iii) The MML shall be easy to learn and to use, easy to input commands and to interpret outputs.

(iv) The MML shall contain Man-Machine Commands (MMC), outputs, control actions and procedures sufficient to ensure that all relevant functions for the operation, maintenance, installation and testing of the system can be performed.

(v) The MML shall have an open-ended structure such that any new function or requirement added will have no influence on the existing ones. The language structure shall be such that subsets can be created.

(vi) The character set used in the MML shall be a sub-set of the ITU-T alphabet No. 5 as recommended in ITU-T Z.314.

(vii) The command codes shall be function oriented. There shall be only one command per function. The codes shall be mnemonic. All the command codes in a particular application shall preferably consist of the same number of characters.

(viii) The output in response to input commands shall have the same format and use the same identifiers, codes, and labels, as the corresponding input command.

(ix) The MML shall provide facilities for cancelling and aborting the execution of commands.

(x) The MML shall provide facilities for inputting the parameters, for a command, in any sequence and the optional parameters need to be inputted only when they are required. Screen editing facilities for modifying the commands and parameters shall be available.

6.19.5.2 Input/Output

(i) The input and output information shall be presented in a compact form.

(ii) The automatic output, not made in response to an input command shall: a) Include the time and date.

135

b) Use standard telephone terminology. It is preferred if the automatic output is differentiated by colour or special characters from the output in response to an input command.

(iii) To facilitate filling and retrieval of recorded information in MML; the information shall be recorded on forms or pages with an identification header on top of each page with the date and time.

(iv) Special information shall be provided on priority printouts indicating emergent situations.

6.19.5.3 Man-machine dialogue

(i) The MMC shall offer the facility for a conversational mode of operation.

(ii) The MMC shall have facility for restricting the use of certain commands or procedures to certain staff/terminals.

(iii) Where several man-machine terminals are in use on a single system, a mechanism shall be available to avoid clashes.

(iv) The execution of any command shall not result in malfunctioning and/or over loading of the system. It shall also be ensured that the operator is not locked out by the system.

(v) The MMC shall be implemented in such a way that errors in commands or control actions shall not cause the system to stop or unduly alter the system configuration.

(vi) Command errors detected by the system shall be indicated by the output of error messages.

(vii) Possibility of priority messages to interrupt an input or output message of lower priority is desirable.

6.19.5.4 Checks and safeguards :Sufficient checks and safeguards shall be built into the implementation of the MMC so as to ensure reliable operation of the system.

6.19.6 Diagnostics/Testing: The equipment shall support diagnostic capabilities

(which will run as background tasks) to verify the equipment’s proper operation within the network. Built-in test capabilities shall be provided which will run at specific events or on demand. Health monitoring signals shall be continuously passed between the various modules to ensure the detection of any failure in a module. Individual channel element functionality shall be also be monitored to prevent call blocking due to a lack of channel element resources.

6.19.7 The system hardware and software shall not pose any problem, due to

changes in date and time caused by events such as leap year etc., in the normal functioning of the system.

6.19.8 Maintenance Aspects

136

(i) Maintenance philosophy is to replace faulty units after quick analysis of monitoring and alarm indications. Actual repair will be undertaken at a repair centre. The supplier shall ensure the repair of faulty equipment during and after warranty period.

(ii) It shall be possible to isolate Interface points for testing purposes. (iii) The equipment shall have easy access for servicing and

maintenance. (iv) All important switches/controls on front panel shall be provided with

suitable safeguards such as interlock system to avoid accidental operation by the maintenance personnel.

(v) Procedure for repair of equipment giving full details of testing instruments shall be provided by the equipment supplier. Test jigs, fixtures required for maintenance/repair shall also be provided.

(vi) Extensive facilities for testing, supervision and monitoring functions shall be provided for quick isolation and rectification of faults. These functions shall be performed by OMC. Any additional instruments required shall be provided by the equipment supplier with details.

(vii) The supplier shall provide information regarding the failure rate of the PCBs and accordingly supply number of spare cards depending on the size of the system, for a period of two years.

(viii) The maintenance spares supplied shall take into account the MTTR. At least one spare PCB of each type shall be supplied.

6.19.9 Electromagnetic Compatibility (EMC)

The equipment shall conform to the EMC requirements as per the following standards and limits indicated therein. A test certificate and test report shall be furnished from test agency. The test agency for EMI/EMC compliance shall be an accredited one and details of accreditation shall be submitted. a) Conducted and radiated emissions: - RNC, OMC & Indoor RN shall comply

with CISPR 22 {2003} “Limits and methods of measurement of radio disturbance characteristics of Information Technology Equipment” as per Class A. The outdoor RN shall comply as per Class B.

b) Electrostatic discharge:- To comply with IEC 61000-4-2 {2001 } “Testing and measurement techniques of Electrostatic discharge immunity test” under following test levels:

Contact discharge level 2 {+ 4 kV}; Air discharge level 3 {+ 8 kV};

c) Fast transients common mode (burst):- To comply with IEC 61000-4-4 {1995 with Amendment 1 (2000) and Amendment 2 (2001)} “Testing and measurement techniques of electrical fast transients/burst immunity test” under Level 2 {1kV for DC power lines; l kV for signal control lines};

d) Immunity: IEC 61000-4-3{2002} Radiated RF Electromagnetic Field

Immunity test under test level 2 (test field strength 3 v / m) for general purpose in frequency range 80 MHz to 1000 MHz and under test level 3 (10 v/ m) for protection against digital radio telephones in frequency ranges 800 MHz to 960 MHz and 1.4 GHz to 2.0 GHz;

e) Surges line to earth coupling and line to line coupling :- To comply with IEC 61000-4-5 {2001} "Test & Measurement techniques for Surge immunity

137

tests" under test levels of 0.5kV for line to line coupling and 1kV for line to earth coupling;

f) Radio frequency common mode: To comply with IEC 61000-4-6 {2001} "Immunity to conducted disturbances induced by radio frequency fields” under the test level 2 {3 V r.m.s.}; clamp injection method for DC lines and Signal Control lines.

6.19.10 Safety Requirements

a. The operating personnel shall be protected against shock hazards as per IS 8473 (1993) – Guide on the effects of current passing through the human body (equivalent to IEC publications 479-1 (1984).

b. The equipment shall conform to IS 13252 (1992) – Safety of

information technology equipment including electrical business equipment (equivalent to IEC publication 95 (1986) and IEC 215 (1987) Safety requirements of radio transmitting equipments (for Radio equipments only)

The manufacturer/supplier shall submit a certificate in respect of compliance to these requirements.

6.19.11 Lightning Protection: The equipment including Antenna & feeder,

shall have adequate protection against lightning & power surges. All equipment shall have provision for grounding. For lightning protection of Antenna the provision shall be there for direct ground.

6.20 Backbone Network

6.20.1 The BTSs shall be connected with their BSCs with state of art digital radio links. 6.20.2 The radio links shall work on 8/ 11/ 13 GHz frequency. The vendor shall quote radio

links in any of the above frequency bands depending on their engineering & design. The

capacity of the equipment shall be Nx2.048Mbps. N shall be determined by the vendor

based on the system design. In case, N>16, the STM-1 link would be preferred. The

design shall take rain attenuation into consideration for higher frequency bands. System

availability shall be 99.99%.

6.20.3 MTML presently has NEC Pasolink/Pasolink+ make MW equipment. The same is being

upgraded for EVDO Rev A expansion being done by M/s ZTE. Existing NEC make MW

equipment, as upgraded in EVDO expansion, should be suitably upgraded and integrated

with a new MW equip of capacity as envisaged in this tender to provide 2G & 3G

network seamlessly to the existing CDMA as well as new GSM network. The new MW

shall be dimensioned accordingly. The responsibility of interworking of new MW with

existing MW of lies with the successful bidder. 6.20.4 Alternatively, the successful bidder may replace the existing MW with new MW of higher

capacity which will include existing MW capacity. In this case, the migration of existing

MW capacity to the new MW will be the responsibility of the successful bidder. 6.20.5 The bidders also have the option to expand and upgrade the existing MW for providing

2G/3G services seamlessly to the existing as well as new capacity. 6.20.6 The successful bidder shall keep atleast 2 E1’s as spare in all the radio links for MTML

future capacity expansions.

138

6.20.7 Detailed system performance calculations/ link calculations meeting relevant ITU -T recommendations shall be provided by the vendor.

6.20.8 Equipment details such as transmitter and receiver characteristics, equipment test points, order wire, supervisory system, antenna system etc. shall be provided by the vendor.

6.20.9 The vendor shall provide in-built multiplex equipment to provide 2 Mbps PCM interface as per ITU-T G703 at the input and output of the equipment. The 2 Mbps input/output ports shall be both 120 Ohm balanced.

6.20.10 The equipment shall be in 1+0 configuration for capacity up to 2x2 Mbps. Higher capacity equipment shall be in 1+1 configuration.

6.20.11The equipment shall have the following features.

- Forward error correction (FEC) - Local Maintenance Terminal (LMT) with window based software

application. - Easy configuration for vertical/horizontal polarization. - Software controlled variable transmit attenuator. - Field tunable carrier frequencies - Local, remote and input loop back test - BER test through LMT. - TX-RX separation as per ITU-R recommendations. - Frequency selection through LMT. - Transmit power control through LMT.

6.20.12 The overload point of the receiver and range of transmit power control shall

be indicated by the vendor. 6.20.13 The vendor shall submit detailed connectivity chart displaying the

capacity of various radio links (no. of 2.048 Mbps), frequency band width in air etc.

6.20.14 A centralized Network Management System (NMS) shall be provided by the

vendor for centralized addition, deletion, modifications of any link in the network, monitoring the health of all the links, Fault detection and attending etc. The NMS so provided should manage the complete Microwave network, including the existing ones.

6.21 INFRASTRUCTURE ITEMS 6.21.1 Towers 6.21.1.1 The vendor shall quote for towers/RTT/Mono pole for GSM and

Microwave Transmission Systems (MTS) required at BTS/MTS sites. The vendor shall be responsible for the design of towers including foundation, supply of materials, transportation, storage where necessary, construction for foundation, erection of tower and installation of related facilities such as Earthing and detailed design of the towers would be submitted by the vendor. A certificate regarding the design of the tower meets the technical requirements of the RFP from Govt body/certified agency is to be produced by the vendor.

139

6.21.1.2 Heights & number of towers shall be decided by the supplier based of their

detailed survey & engineering. The towers shall be able to withstand the loads imposed by the antennae. In the design of the tower antennae required to be mounted in future shall also be taken into account. The wind loading on structure and antenna shall be based on wind velocity of 250 kmph. The performance shall not degrade at this speed. The structure shall survive at wind speeds of 320 kmph. Allowance shall be made for the effective wind area of feeder runway, feeder, platforms guardrails, ladder and ladder guard. Vendors shall get the towerdesign certified by authorized agency/Govt. Body to meet the technical specifications of the RFP.

In the South area, restrictions for the tower height is specified by the

Airport authorities . W hile designing the tower heights, this is to be taken into account

6.21.1.3 All steel work and fitting used in the assembly of the tower, except those

used in the concrete foundation, shall be galvanized by the hot dip process after fabrication at factory. The thickness of galvanization shall be more than 500 gms per sq. meter.

6.21.1.4 Nuts and head of bolts shall be of hexagonal type. Bolts and nuts shall be

hot dip galvanized. All bolts shall be fitted with spring washers or retaining nuts. Spring washers or retaining nuts shall be galvanized by the hot dip process.

6.21.1.5 Platforms covering sufficient area of the structure to provide safe working

conditions shall be provided at each antenna level including antennae to be mounted in future. Platforms decking shall be made of expanded metal or similar material, adequately supported on steel members of appropriate size.

6.21.1.6 A feeder runway shall be provided on the tower. Each feeder runway shall

be located about the center of tower and extending vertically from ground level to the top of the tower. Vendor shall provide a ladder type feeder runway to support and protect the feeder cable between the vertical runway and the station building. The installation of supporting gantry shall provide satisfactory strength to resist against the mechanical stress. Adequate protection shall be provided against falling objects.

6.21.1.7 Lightening protection and Earthing system is to be provided by the vendor.

The earthing strip should of GI and (not copper cable) of appropriate dimension to avoid theft. If vendor feels that GI strip is not likely to provide proper earthing, he should provide insulated copper strip, but not the cable. The strips are to be welded at various locations on tower.

6.21.1.8 The tower shall be complete with antenna mounting steelwork to which the

BTS/MTS antenna may be rigidly attached by means of mounting hardware supplied as part of antenna system.

6.21.1.9 Aircraft W arning Painting shall be provided for the self-supporting

towers.

140

6.21.1.10 Three coats of paint shall be applied as follows.

a) A primary coat of calcium plummet primer b) An intermediate coat of high quality exterior under coat c) A finishing coat of high quality exterior gloss finishing enamel

6.21.1.10 Aircraft Warning Lighting (Aviation Lamp)

i) The vendor shall provide Aircraft W arning Lighting for the towers. ii) At the top of the structure, double lights shall be mounted 35 cm above

the top part of the structure but below the lightning arrestor. iii) At the intermediate level, two lights shall be fitted so that the light is

visible from every angle of azimuth. The intermediate lights shall be fitted at a height of approximately half that of structure.

iv) The lighting unit shall be of low power consumption type. v) Supplier shall supply junction box to be located 2 meters above ground

level to control the complete warning lighting system. vi) At the intermediate level, the lighting unit shall be installed in such a

position as to be readily accessible from a platform. vii) Two independent lightning circuits shall be provided between the

junction box and the lights. viii) The cable shall be installed within galvanized screwed conduit, which

shall be attached to tower. ix) The lighting units shall be DC operated and have photo-sensor control to

switch it off during day time. x) The DC power necessary for the lighting units shall be incorporated in

power system of BTSs. 6.21.2. Antenna

6.21.2.1 The vendor shall determine the type of antenna for getting desired coverage and performance of the system. Fixtures for antenna mounting at BTSs and RSs shall be included as part of antenna supply for both BTSs as well as Microwave Transmission Systems. The proposed antenna system shall withstand the adverse weather condition such as heavy rain falls etc. Concepts of diversity receptions shall be implemented for required reception of the radio signals.

6.21.2.2 The vendor shall indicate antenna configuration at Base Stations, Subscriber Units and Microwave Transmission Systems. Microwave antenna shall be with low beam-width & high front to back ratio so as not to cause interference to other links (MTML or other operators).

141

6.21.2.3 Feeder: The vendor may decide type of feeder cable for getting desired coverage and performance of the system. The vendor shall furnish detail specifications (technical as well as mechanical) of the feeder cables.

6.21.3 Digital Distribution Frame (DDF) DDF is required at BSC and all BTSs to allow flexibility of connection of 2

Mbps streams from exchange to BSC and BSC to BTSs. The vendor shall supply DDFs with patching panels, jumpers and connectors. Connectors shall 120 Ohms balanced impedance and 75 Ohms unbalanced impedance at 2 Mbps level. At least 10% additional terminating capacity on the line side of DDF should be provided for flexibility. Suitable length of HF screen cable shall be supplied between DDF and transmission room.

6.21.4 D.C. Power Supply System

i. The vendor can expand the existing power system at all location or insatall

its own power systems. The vendor shall quote for upgradation or complete power supply system for all the systems & sub systems e.g. switches, BSS, Microwave transmission system etc. The Power Plant shall be based on high frequency switched mode techniques i.e SMPS to be used in auto float-cum-charge mode as a regulated power supply source. The power supply system capacity shall be able to meet 2nd year end power requirement. It shall be feasible to expand the system to meet further future requirement. The MTBF of the system shall not be less than 100,000 hours. Based on this figure, the vendor shall stock necessary spares during warranty & AMC periods. The equipment availability shall exceed 99.99%

ii. The equipment shall operate at –48V DC with positive terminal earthed.

The voltage variation may range from –42V DC to –56V DC. iii. The vendor shall state the power consumption of the equipment in all the

network nodes. iv. The vendor shall provide –48V DC power supply equipment including float

rectifiers/ charger, batteries and accessories for all the sites. The Power Plant shall consist of a Distribution/ Switching/ Control/ Monitoring/ Alarm management based on menu driven micro processor controlled, rectifiers/ chargers in a rack and shall employ modular configuration for flexible provision of DC power. There shall be suitable AC/ DC digital meters/ displays to read the voltage & currents of the system, any of the battery or any of the float rectifier/ charger.

v. The float rectifiers/ chargers shall work in N+1 configuration and shall be

provided with over voltage, under voltage, short circuit and surge protections.

vi. The float rectifiers/ chargers shall operate from single phase AC mains of

230V+/- 10%, 50 Hz+/- 2% and/or three phase AC mains supply of 400V+/-10%, 50Hz+/-2%.

142

vii. The vendor shall provide any additional power equipment e.g, inverters, DC/DC converters, required for any equipment operating on power supply other than –48V DC.

6.21.5 Batteries

i. The vendor can expand existing batteries to the extent possible or may

install new batteries. The batteries shall be maintenance free/sealed MF VRLA batteries with immobilised electrolyte and leak proof with cover seal. The container shall be made of flame retardant PVC or equivalent. Battery banks shall be provided in stackable modules. Stackable batteries shall have air flow channels between cells for cooling. VRLA batteries shall be manufactured in accordance with International Quality Standard ISO-9001-2000 for which manufacturer shall be duly accredited. The steel racks, containing batteries, shall be painted with acid-resistant paint.

ii. The cells of batteries shall not explode or burn when an electrostatic

discharge of 15 KVA is applied to any of its part exposed to contact. iii. The Ampere-Hour (AH) capacity of the batteries shall be enough to

provide the following back up:

MSC/BSC sites : 6 Hours BTS sites : 4/8 Hours. The outdoor cabinet will have inbuilt

battery capacity of 4 hours and the additional cabinet will provide 4 more hours and will be placed wherever asked for.

Failure of one or two cells shall not cause the failure of the battery and shall be able

to provide uninterrupted power supply.

iv. The capacity shall be decided by the vendor as per the power consumption of the equipment at each node of the network. The capacity of the each battery shall be calculated at 18 - 33 OC room temperature variations. The vendor shall provide the discharge tables of battery at C/3, C/4, C/5, C/6, C/8, C/10, C/20, C/72 & C/120 rate of discharge to enable MTML staff to set the charge controller voltage low disconnect to ensure that the batteries are not allowed to discharge beyond 80% of its rated capacity.

v. Batteries used for Float applications are normally 24cell/48V batteries. These batteries are formed by connecting 24 cells or cell modules each of 2V of the rated capacity, in series subject to compliance of the following conditions.

1 The internationally adopted design practice shall be followed. The

partial plating of cell is not permitted. Paralleling of cells externally for enhancement of capacity up to 1500AH is not permitted. For higher capacity, the number of such paralleling shall be restricted to 4 only, subject to the compliance of the following clauses and minimum capacity of the basic cell is not less than 1000AH.

143

2 Cell matching is essential for optimum life and performance of the battery. For the purpose of cell matching, the following clauses shall be met.

a) Voltage Matching:

i) Parallel Cell Matching: The difference between cell voltages in the cell module string, with the highest & lowest open circuit voltage shall be less than 0.02V. Throughout the discharge, the difference between the float voltages of cells having the lowest and the highest float/charge voltage. In the cell module string shall be less than 0.02V. The average float voltage of each cell shall be within +/- 0.01V of the specified float voltage during float/charge.

ii) Series Cell Matching: The difference between cell voltages in a cell module & cell modules in the battery string, with the highest & lowest open circuit voltage shall be less than 0.1V. Throughout the discharge, the difference between the float voltages of cells having the lowest and the highest float voltage in the cell module/battery string shall be less than 0.1V. The average float voltage of each cell shall be within +/- 0.05V of the specified float voltage during float & charge.

b) Capacity Matching: i) Parallel Capacity Matching: The difference between the highest and lowest cell capacities on a cell module string shall not be more than 4% of their rated capacity.

ii) Series Capacity Matching: The difference between the highest and lowest cell capacities in a cell module & cell modules in a battery string shall not be more than 5% of their rated capacity.

6.21. 6 Power Distribution Box

1. AC Power Distribution Box (ACDB) shall be supplied for distribution of AC power to rectifying equipment.

2. DC Power Distribution Boxes (DCDB), ACDB and other facilities shall be

provided as per the requirements of each site. 3. ACDB and DCDB shall be of wall mounted type. 4. Power Distribution Boxes (PDB) shall have appropriate ratings so as to meet

at least first two years requirements. 5. PDB shall be equipped with a main circuit breaker and branch circuit

breakers.

144

6. Distribution Boxes shall be provided with digital displays for current & voltage readings.

6.21.7 Diesel Generator (DG) set

1. The vendor shall quote for mobile DG sets (total 4) of appropriate capacity.

2. The diesel engine shall be of air-cooled type/ canopy type for installation in

outdoor conditions.

3. AC generator shall be provided with static type automatic voltage regulator and shall be of the self-excited type. The generator shall be fully protected against overload and short-circuit.

4. Automatic charging device for charging the starting batteries on float basis

shall be provided to maintain the batteries in fully-charged condition.

5. Lubricating oil reservoir for the engine shall be provided sufficiently to cater for seven hundred (300) hour continuous operation without change of such oil.

6. Diesel Engine Generator set shall be provided together with following

accessories: a) Starting battery b) Fuel supply and lubricating system including Fuel Tank c) Exhaust system b) Dummy Load

e) Necessary Tools for maintenance

7. Fuel tank with sufficient capacity with direct reading fuel gauge, air vent facility and fuel level switch for level alarm shall be supplied. Separate fuel tank as indicated below shall be supplied.

Service Fuel tank: 8 hours continuous operation at full load

Reserve Fuel tank: 24 hours continuous operation at full load

8. Fuel motor pump shall be provided for automatic feeding of fuel from reserve

fuel tank to service fuel tank. Hand pump shall also be provided for use in the case of failure of fuel motor pump. Reserve Fuel tank shall be installed on the ground.

9. One set of maintenance tools shall be provided for each generator.

10. The capacity of the diesel engine generator set shall be determined based on at least 1.5 times the ultimate station load (after 2 years) including Air Conditioning equipment, equipment load, battery charging, lighting etc.. Altitude and climatic conditions may be kept in view while calculating capacities of generator sets (de-rating factor). The generator shall be capable of operating at 10% overload for one hour. Single phase and three phase DG Sets depending on capacity & design of the vendor shall be supplied.

145

11. The technical characteristics of diesel engine generator shall be as follows:

a) Speed : 1,500 rpm b) Speed variation : 5% or less under full load c) Nominal output voltage : 230 V, single-phase

400 V, three-phase d) Nominal frequency : 50 Hz e) Voltage fluctuation : +5% or less smooth variations from no load to full load (except for any quick variation in load) f) Voltage adjustability : more than +5% of nominal value (in case of manual adjustment)

12. Diesel engine generator shall start automatically when reserve capacity of the battery decreases to specified limit. W hen reserve capacity of battery increases to specified upper limit or AC mains is restored the diesel engine generator shall stop automatically. The start/stop control by means of manual operation shall also be possible.

13. The control Cubicle shall be provided with voltmeter, ammeter, frequency and run hour, alarm indications and terminal for alarm extension. The cubicle shall have the following supervisory functions:

Integrated failure signal Fuel level low signal Operation signal of diesel engine generator Time-up signal for change of lubricating oil.

14. Mechanical protection for the engine such as, low lubricating oil pressure,

high cylinder head temperature, low fuel level for fuel tank etc. and electrical protection such as, overload, under voltage, overload on DG set etc shall be provided.

6.21.11 Electrical system

1. An AC distribution system shall be provided to distribute the AC power to the various electrical equipment such as, rectifier panel, air conditioning units etc. and lighting sections. Standby power from the Diesel Generator Set is also fed to this distribution system.

2. The AC Distribution Board (ACDB) shall be made of processed and powder coated steel sheet. It shall consist of MCBs and terminals, the ratings of which shall be calculated as per the actual load requirements.

3. A programmable logic controller (PLC) based Alarm Monitoring & Fault (AMF)

panel shall be provided. The functions of the panel shall be as follows:

(i) Automatic starting of diesel generator set in the event of AC mains voltage falling below preset value.

146

(ii) Automatic shutting down of the DG set when the AC mains

supply is restored, after a preset idle running period. The stability of the AC mains supply shall be monitored for a preset time period and then load shall be automatically transferred to the AC mains.

(iii) Generation of an alarm in case the DG set fails to start in three

attempts. (iv) Generation of low fuel alarm of the DG set.

4. The supply of AC from mains as well as from Diesel Generator set and fire and intruder detection sensor shall be controlled by the PLC. The PLC shall control the logic for mains failure for control of the diesel generator set and all alarm generation.

5. Digital Ammeter and Voltmeter with selector switch shall be provided.

6. The following cables and wires shall be provided.

(i) Cable from mains supply to ACDB (ii) Cable from DG set to ACDB (iii) Control cable from DG set to AMF panel (iii) Cable from ACDB to the rectifier unit (v) Cable from ACDB board to the air conditioning units

(vi) Cable from ACDB board to the lighting section (vii) Cable from ACDB board to power sockets

(viii) Control cable for smoke detector/ fire detector and intruder

alarm system (ix) Cable for Earthing

(x) PVC channel/ Aluminum trunking for carrying cable (xi) Cable glands and lugs as per cable

7. The following lighting items shall be provided. (i) Lighting as per lux requirements of the shelter/ equipment

room (ii) Emergency light with charging system (iii) Aviation obstruction lamp alongwith twilight photoswitch

147

(iv) External light using halogen lamps of adequate wattage with standard accessories

8. Isolation transformer shall be provided between incoming AC supply and the

load for suppression of electrical transients.

9. Outdoor housing for electrical consumption meter made up of steel sheet with proper installation accessories shall be provided.

10. A change over switch along with 8 way control switch and terminal box for

connecting mobile DG set shall be provided.

6.21.12 Earthing System & Lightening Protection. Adequate Earthing system shall be provided at each site as per the

requirements of system operations. All equipments shall be connected to the earthing system. Earth resistance shall be less than 1 ohm for switching and transmission system. Suitable lightening protection shall be provided at equipment side. All stations including shelter shall be provided with lightening protection system.

6.22 TOOLS AND TESTERS 6.22.1 The vendors shall quote one set of essential tools and testers for day-to-day

operation of the system. A detailed list containing each item and quantity which forms part of it, may be indicated along with the price of each individual item.

6.22.2 The Purchaser reserves the right to procure either complete set of tools and

testers or any of the constituent items.

6.22.3 The vendors shall quote the following Measuring Instruments/Planning and allied tools:

6.22.3.1 RF Planning tool (GSM/GPRS/UMTS/3G)

i. Planning tool for Coverage prediction, Frequency Planning and Performance planning etc shall be supplied. The successful bidder shall supply the soft copy of the latest digital maps of Mauritius used for coverage simulation, prediction map with the BTS simulated for the cities, highways and rail routes duly loaded on the planning tool. The digital maps supplied shall also be compatible with the planning tools NetPlan/ASSET and there shall be no restriction, whatsoever, in the use of these maps by the purchaser. The soft copy of the Coverage prediction maps jointly agreed to by the successful bidder and purchaser shall be available in the planning tool, a jointly signed hard copy of which is to be made over to the purchaser as part of the planning and engineering exercise. The server shall be supplied along with 21 inch VDU/LCD display, AO plotter and A3-Colour Laser printer. The Installation and commissioning of the planning tool in the desired configuration shall be done by the successful bidder.

148

ii. The software of Planning tool shall be licensed in the name “of MTML(unlimited period). One copy of the Planning software with necessary license and maps shall be supplied with suitable lap top computer with CD-RW for easy backing up of data.

iii. The software of Planning tool shall be licensed in the name of MTML (unlimited period) and should have the following General Features -

A) The RF Planning tool should be able to perform 2G/ 2.5G and 3G Network Planning on the same platform simultaneously without having to switch between different modes.

B) The RF Planning Tool should support Full 2G, 2.5G and 3G integration including joint technology neighbour planning and joint technology Monte Carlo simulations, providing planners with the ability to accurately plan 2G, 2.5G and 3G handover scenarios.

C) The RF Planning Tool should be able to perform Automatic Cell Planning and Network optimization.

D) The planning tool model should be able to get updated using the data from the drive test tool.

E) RF planning tool should be capable of Network Performance analysis and problem area identification

F) RF planning tool should be capable of Network Fine tuning and validation with Data measurements

G) RF planning tool should be able to capture in optimization mechanisms and real world design issues and constraints

H) RF planning tool should be capable of handling the existing/implemented network plan and should be able to perform analysis/expansion activity on the existing database.

I) RF planning tool should be able to automatically optimize the physical network configuration to maximise capacity for the range of services and traffic demands.

J) RF planning tool should be able to Automatically optimize design parameters like antenna and power settings for multi-technology networks

K) RF planning tool should be able to Utilize an extensive range of survey measurement and network statistics data to tune the modelled network and facilitate area performance optimisation

L) RF planning tool should be able to Automate and improve the efficiency of the iterative process of ongoing planning and optimisation

M) RF planning tool should be able to Support 'real world' performance targets and network configuration constraints

N) RF planning tool should provide a choice of various radio propagation models.

O) RF planning tool should be seamlessly integrated to a single relational database “Oracle”.

P) Accurately simulate current and future capacity scenarios using static and dynamic simulators

Q) 3G data service QoS analysis R) Automatic Frequency Planning and Code planning S) Location Service Planning T) Sophisticated statistics generation and reporting. U) Advanced propagation model support including: Auto tuning of

models, and support for 3rd party models.

149

V) The tool should have a powerful embedded GIS or should be seamlessly integrated with 3rd party GIS tools.

W) The tool should have powerful filtering capabilities based on object attributes.

X) The tool should have the flexibility to store additional attributes per object type (strings, pick lists, numbers, integers, Boolean etc.).

Y) The tool should support both OS & Oracle authentication, and should have built in administration accounts.

Z) RF planning tool should have the capability to use propagation models for both macro-cell as well as micro-cell.

AA) The tool should support static analysis for faster results. BB) The RF Planning tool should have the ability to handle terminals

moving at different speeds. CC) The RF Planning tool should have embedded latest deterministic

models to avoid tuning if required. DD) The RF Planning tool should allow the user to create arrays that

combine coverage predictions and the effects uplink/downlink loads have on them

EE) The tools should support integrated dual band planning. FF) The RF Planning tool should have accurate modeling of RRM

algorithms and service characteristics to accurately predict QoS. iv. Capabilities for Predictions and propagation

a. Should support fast predictions using different propagation models. b. Should incorporate more than two diffraction models. c. The user should be able to tune the propagation models and include

customized models. d. Should have capability to define separate models for different cell

layers/cells. e. Interactive azimuth reorientation for the map view should be available. f. Should have option to display predictions on site basis, filtered sites or

map view. g. Should have the facility for background prediction h. Should support multiple CW data formats.

v. Capabilities for Interference and Automatic Frequency Planning

a. The handover hysterious margin and underlay/overlaid sub cells should be considered in the calculation.

b. Should support base band and synthesizer frequency hopping, DTX and group planning.

c. Should support MA List definition. d. Should support HSN/MAIO/TSC planning. e. BSIC planner should allow for exclusion of selected BCC’s and NCC’s f. Should calculate C/I and C/A cell interference calculations and display

it on the map view.

vi. Capabilities for Traffic Planning

a. Allows the utilization of user defined traffic forecasts or live traffic carried by network

b. Employs Erlang B or C model.

150

c. Permits dynamic cell dimensioning according to traffic in Underlay/overlay situations.

6.22.3.2 Drive Test Tool

i. The bidder shall provide Phone and Receiver based drive test tool capable of testing GSM,GPRS & HSDPA/HSPA networks and realtime mapping of multiple parameters with at least four phones and GPS receiver for achieving optimisation of the Network and its expansions together with post processing tools.

ii. It should be possible to upload the data captured by the drive test tool into the Planning tool for fine tuning the propagation model for further planning as per user requirement.

iii. General Features:

a. The C/I measurements on the BCH carrier should be done by the Digital Receiver in very accurate form support the full dynamic range required for GPRS and EDGE measurements. The Receiver should support both uplink and downlink frequency bands

b. Digital Receiver for HSDPA/HSPA should be capable of performing Scrambling Code Analysis, Primary Synch Search , and should be able to provide for all significant pilots found measuremts like Ec, Ec/Io (both peak and Aggregate), PSCH Ec/Io, SSCH Ec/Io, Delay Spread etc. The Digital Receiver should have the capability to allow trade off between measurement samples and sampling rate.

c. Ability to verify intersystem handovers and cell-reselection should be available, along with a display of HSDPA/HSPA and GSM neighbours together to check for Inter-RAT and compressed mode behavior.

d. A Protocol stack browser for viewing air-interface messages should be available. Also facility to view data in Maps, Graphs and reports should be provided.

e. Standard applications like HSDPA/HSPA Missing Neighbour, Pilot Pollution, Soft Handover Analysis, Drop Call Analysis, Problem Summary Analysis, Protocol Messages Failure Cause Analysis, Pilot Availabillity, Pilot Dominance Interference Analysis, GSM-HSDPA/HSPA (Inter RAT) Handover Analysis, GSM – HSDPA/HSPA combined drive analysis, GSM co-channel, adjacent channel interference analysis should be provided. Analysis like Pilot Pollution, Missing Neighbour, Handovers etc should be available on live basis and in Tabular and Graphical form.

f. An automated radio network data collection, analysis, presentation and reporting system should be supplied.

g. This system should have remote data collection probes which can be installed in vehicles and are capable of remotely uploading collected log files to a central server automatically using standard Radio Bearer. The probes and calling patterns should be controllable from a central server.

h. Facility to view GSM/GPRS/W CDMA radio parameters and layer 3 messages should be available.

i. The system should provide speech quality testing using standard algorithms.

j. The system should have the capability to generate customer views, flexible Boolean logic based Alarms.

151

k. System should be capable to export data into CSV, text and Mapinfo format. l. Data Testing Suite should be provided for doing both End to End Data with

a Test Server and Applications Analysis

6.22.3.3 Post Processing Tool

(i) The Post Processing tool should be able to load and analyse data from 2G, 2.5G and 3G Networks & data measurements.

(ii) The Post Processing tool should support integrated 2G/3G Data Analysis.

(iii) The Post Processing tool should be able to merge different drive test data in to single files for comprehensive analysis.

(iv) The PP tool should have Event Navigation functionality on a Time line , which will display from Start to end of Drive all events like Call Start, Call End, Drop Call, Blocl Call, Data Sessions etc along with colour coded carrier and channel indications. W hen clicking on any event or near to event it should update the map and charts and messages window immediately.

(v) The Post Processing tool should have a powerful and flexible graphing system with replay functionality.

(vi) Any data can easily be displayed on the 2D View - indicate best server Ec, Ec/Io, pilot polluted areas, throughputs, call drops, call failures etc.

(vii) The Post Processing tool should be able to perform Layer 3 decoding and analysis with easy to use search and find capabilities.

(viii) The Post Processing tool should be able to perform Comparison and synchronisation of digital receiver and UE (User Equipment) data.

(ix) The Post Processing tool in conjunction with drive test tools should have Benchmarking capabilities - compare 4 or more networks.

(x) The Post Processing tool should be capable of Reporting via MS excel or HTML or PDF or MS W ORD generated reports, shipped with a standard set of reports (Ec, Ec_Io distribution, Bler distribution, neighbour analysis, drop analysis etc).

(xi) The Post Processing tool shall provide graphical and tabular reports for various features of GSM /UMTS related performance of the network. The list of features supported may be indicated.

(xii) The system is to be supplied with Desk Top Computer configuration with four perpetual licenses.

(xiii) It shall import and export data from/to drive test tools to be supplied by the bidders and also from/to the existing drive test tools like Agilent E6474 A, TEMS etc and also Planning Tools like NETPLAN, PLANET etc. without any restrictions. The tool shall enable drive-test data files to be automatically concatenated.

152

(xiv) The tool shall provide Protocol stack browser for viewing air-interface messages.

(xv) The system should be supplied with features to display maps, Charts and spreadsheets. It shall interface with Maplnfo to view the results on a map.

6.22.3.4 Protocol Analyser for Iub, Iur, Iu, Gn, Gi interfaces:

i. Protocol Analyser alongwith 8 Nos. of probes to monitor both the GSM interface protocols including the proprietary ones, if any, used in the network as well as for W CDMA interfaces will be provided.

ii. Protocol Analyser should have following features:-

a. The Protocol Analyser should provide fully automated online and offline UMTS 3GPP Iu-b deciphering of control and user (speech, circuit, and packet data) plane data. Support for single-session/multi-services, macro-diversity (session control and user plane data sent across multiple Iub links), cell-FACH/cell-DCH transitions scenarios

b. Support for multi port E1 links (single-port, IMA, and channelization modes)

c. Protocol support for GSM/GPRS A and Abis interfaces including call traces and tabular statistics profiles

d. Support for standard TRAU 16K decode e. Support for H.324 (H.223/H.245 decode) PDU reassembly and

analysis on Iub interface f. Support for real-time 3GPP R99/R4 Gb deciphering g. Support for FP and RLC/MAC real time high speed downlink packet

access (HSDPA) analysis h. AMR playback on Iu interface i. Session buffer replay- the entire traffic buffer can be replayed for

correction to MAC logical channel settings. User can update the MAC logical channel settings in configuration and these settings will be used for decoding and reassembling the RLC/MAC PDUs during buffer replay operation. Buffer replay is also for reassembling the following protocols’ data in offline mode: UMTS: RLC/MAC and H.223/H.245

j. Ability to listen to voice play out in the middle of call in both Iub and Iu interface

k. Real-time capture and offline playback per IMSI/VPI/VCI l. Gn/Gi correlation to other interfaces like Iub and Iu m. SS7 subset n. Support for up to 8 full duplex STM-1 interfaces for greater network

visibility. o. Multi user server-client support. p. Call manager. q. Data mining support for long term data storage, reporting and analysis. r. Monitor and troubleshoot interoperability of handsets with existing

networks with the power call trace features. s. Handles inter system handover between GSM/EDGE and UMTS. t. IP-based UMTS core network, e.g. Iu over IP, MAP over etc

153

Call Trace Features

a. Macro-diversity call traces b. 2G and 3G handover call trace (2 ways handover, 2G-3G and 3G-2G).

support both PS and CS calls c. 3GPP Iub and Iub/Iu call traces to group in the soft handover legs for a

single session together. This also provides intuitive information on the number of macro-diversity legs in each call

d. 3GPP Iub/Iu/Iur call traces to group in the soft handover legs that extend to DRNC for a single session together

e. RP (TCP option) call trace that keeps track of TCP resends f. RP tabular statistics to perform statistical analysis based on cell ID,

IMSI, NID, sector ID, serving PCF, SID and user name. g. Iub/Iu/Gn call traces h. 3GPP call traces to group the messages exchanged across the Iub, Iu

and Gn interfaces of UMTS networks. This also allows intuitive grouping of Iub/Gn or Iu/Gn traffics.

i. Iub and Iub/Iu call traces- vendors variant call traces that also group in the handover messages

j. Iub/Iu/Iur call traces- 3GPP call trace that also group in the FP frames. k. Iub/Iu/Map call traces l. Iub and Iur RLC stats m. ISUP, BICC over IP call traces n. Iu/GCP binary combined call trace o. Iu/IuUP/H.245 combined call trace p. Iu/H.245 combined call trace

i. Protocol support

a. GSM/GPRS A interface including call traces and tabular statistics analysis

b. GSM/GPRS Abis interface including call traces and tabular statistics analysis

c. 3GPP R4 June 2003 release d. 3GPP R99 September 2002, R99 June 2003 and R99 December 2003 e. H.324M (H.223/H.245 decode) f. 3GPP R5 release g. 3GPPSABP and PCAP R5 Decode h. Iu, Iub, Iur, NAS decodes and call traces i. SIGTRAN (M3UA)

ii. Data mining software features

a. The tool shall provide detailed insight into RAN quality and performance in a large area down to a per cell or user granularity

b. Iur analysis - where a subset of the KPI’s and analysis available on Iub can be used to monitor and troubleshoot inter RNC handovers.

c. Video telephony analysis, handset analysis via IMEI, user centric analysis around IMSI, voice channel analysis, network performance and service performance.

154

d. packet switched services such as MMS, FTP, email etc. e. KPI and statistic report.

iii. Interface Requirement :

Following interfaces are required to be supplied to monitor Iub, Iur,Iu, Gn,Gi on network proposed/supplied by the bidder. Ports are to be full duplex.

STM-1– 8 ports, Optical/ electrical E1 – 8 ports FE – 2 port, Optical

Handheld GPS Receiver with position accuracy of 20-25m - The GPS receiver casing shall be waterproof. W hile the GPS Receiver shall operate with rechargeable AA size batteries, the GPS receiver shall be supplied with Cigarette Lighter Adapter, necessary cables and accessories to connect to the 12-Volt DC car power supply. Data transfer cable for facilitating data transfer between GPS receivers and PC Kit interface cable for connection to the PC through the USB port shall also be supplied. Any software for the PC required to extract and import the data from GPS receiver shall also be supplied.

BTS Tester with GSM scanner, GSM transmitter measurement, Spectrum Analyser, E1 testing, Digital VSW R Cum Waveguide fault detector meter with distance to fault measurement facility, and GPS receiver. It should be a single handheld compact unit working on battery and portable in nature. Power measurement with +/-0.25dB total accuracy to be provided.

HSDPA/HSPA (UMTS) Transmitter Analyser to measure frequency, frequency error, Code Domain Noise Floor, Carrier Feedthrough, Channel Power, Average Power, Pilot Channel Power, Difference in amplitude between key control channel. HSDPA/HSPA (UMTS) Over the Air Analyser to measure frequency error, scramble code, noise floor, Carrier feedthrough, pilot dominance, multipath power, Utilisation (Peak and Average), Amplifier Capacity (Peak and Average), code domain power measurement. Interference Analysis should be possible with Spectogram display for viewing intermittent or busted interfering signals. It should have built in signal identification capability to identify possible interferer/ distinguish between HSDPA/HSPA, CDMA, GSM transmitter.

6.22.3.5 Engineering Handsets- The model shall be the latest and the model number of the handset shall be specified. The user manual of the engineering features with complete explanation is also to be supplied.

6.22.3.6 All the accessories required for comprehensive use of the Measuring Instruments/Planning and allied tools shall be included as part of this package.

6.23 Layout of Equipment:

155

6.23.1 The supplier shall furnish the equipment layout for complete floor clearly indicating equipment planned in Phase-I and Phase-II respectively.

6.23.2 Layout of all equipment shall be so planned that available space in the equipment room/ pre fabricated shelters is optimally utilised.

6.24 PERIPHERALS:

In addition to system specific peripherals, the following shall be provided:

6.24.1. Testing equipment / PC Documentation pre-loaded on disk.

6.24.2 PCs with Laser printer shall be provided for MSC SERVER AND MEDIA GATEWAY, BSC and other major network element sites.

6.24.3 PCs shall have following minimum configuration:

CPU: at least Pentium IV, RAM: 512 MB, HDD: 80 GB, LAN port

15 Inch Colour Monitor, 2 USB ports, latest anti virus software.

6.24.4. The system shall support Input/ Output terminal which can be exclusively used to enter password controlled commands. It shall not be possible to load any software form this terminal through floppy/CD drive etc., (which means floppy/CD drives are not to be provided with this PC)

6.24.5. It shall be possible to support file transfer on IP through designated PC.

6.24.6. In addition, one PC shall be provided to receive information over X.25 link for billing /CDR/NMS data and to transfer this data to remote billing/CDR/NMS systems over IP for all configurations.

6.25 Digital Distribution Frame (DDF):

6.25.1. DDF and associated items shall be supplied for the MSC SERVER AND MEDIA GATEWAY, XCDR, BSC and BTSs. At least 10% additional terminating capacity on the line side of DDF should be provided for MSC SERVER AND MEDIA GATEWAY, XCDR and BSC, for flexibility. No protection is envisaged for DDF.

6.25.2. The supplier shall provide all the cabling from the exchange side of the DDF to the equipment room. The Jumpers required for extending 2 Mbps PCM streams between line side and the exchange side shall also supplied by the supplier. Minimum of 50 M of 16 pair HF screen cable per length (Run) between DDF and transmission room shall be supplied.

6.25.3. For STM-1 interface, a minimum of 60-meter pre-connectorised optical cable length with suitable connectors shall be provided.

156

6.25.4. These shall form part of the MSC SERVER AND MEDIA GATEWAY, XCDR, BSC and BTS packages.

6.26 NSTALLATION MATERIALS , MAINTENANCE SPARES & CONSUMABLES:

6.26.1. All installation material and installations consumables shall be provided to enable the proper installation of equipment supplied (like Runways & other accessories for fixing runways & lugs, Media Cleaning Solution, Alcohol Isopropyl, Soft Cotton, Soft Brushes, Solder W ire, Printer Papers, Adhesive Tape, Mag Tapes 2400-P, optical disc drive, Floppy Diskettes 3.5 inch, Various sizes of Fuses/ Connectors, Covers, Hand Gloves, MCBs, Fuses for batteries, Spare Fuses for DC Distribution Cabinet, Spares for Control Panel of SMPS Power Plant etc.,). Any other materials and consumables, which are technology dependent and required for installation, but not quoted shall also be supplied free of cost.

6.26.2. Item-wise details of installation materials required for installation has to be furnished along-with its unit price and quoting of installation materials in LOTS is not acceptable.

6.26.3. One set of complete maintenance spares & consumables is to be provided to each site to cater to the needs for three years. Spare parts/Spare Units for Hard disks, optical drives, PCs, Printers, CD-ROM & CD-ROM drive, SMPS Modules etc. are to be provided.

6.26.4. Besides system specific spares, sufficient number of consumables like Media Cleaning Solution, Alcohol Isopropyl, Soft Cotton, Soft Brushes, Solder W ire, Printer Papers, Adhesive Tape, Mag Tapes 2400-P, optical disc drive, Floppy Diskettes 3.5 inch, Various sizes of Fuses/ Connectors, Covers, Hand Gloves, MCBs, Fuses for batteries, Spare Fuses for DC Distribution Cabinet, Spares for Control Panel of SMPS Power Plant etc.,) are also to be supplied to cater the need for three years for the maintenance of the equipment supplied. Any other materials and consumables, which are technology dependent and required for maintenance, but not quoted shall also be supplied free of cost.

6.26.5. Complete details of each and every item of installation materials, maintenance spares and maintenance consumables shall be provided.

6.26.6. PCB level break-up along with price of each module shall be furnished.

6.26.7. In the spare list, details of module(s) in which each spare PCB proposed to be supplied is to be used shall also be given.

6.27 TOOLS AND TESTERS (FOR INSTALLATION):

6.27.1 One complete set of Tools, Testers, simulators instruments etc. is to be supplied for each site needed for installation of various network elements of the project.

6.27.2 Traffic Generator for generating 512 Simultaneous calls (256 originating and 256 terminating) on A-interface together with compatible PCs shall be made

157

available by the supplier for carrying out the load test of the MSC SERVER AND MEDIA GATEWAY.

6.27.3 The MSC SERVER AND MEDIA GATEWAY shall provide in-built tracer for taking trace of CCS#7 (ISUP, MTP, SCCP, TCAP and CAP) and other protocol signals on the specified time slot of specified PCM system. System not supporting this facility shall provide separate tester free of cost.

6.27.4 TOOLS AND TESTERS (FOR MAINTENANCE):One complete set of Tools, Testers, simulators, instruments etc. for maintenance is to be provided for MSC SERVER AND MEDIA GATEWAY.

6.28 Billing & Customer Care Centre 6.28.1 The existing B&CCS of 110K capacity (of CDMA) installed should be expanded to

210K for serving both existing CDMA & Proposed GSM subscribers or replaced with new B&CCS of 210K capacity including the existing capacity. The offered B&CCS solution should be expandable to 310K with additional hardware & software for phase II expansion.

6.28.2 Billing & Customer Care System (B&CCS) provided must conform to the standards. 6.28.3 Billing and customer care system shall be an integrated customer care, billing &

accounting platform and shall support billing for wide range of GSM/CDMA services, viz. Tele-services, Bearer services, Supplementary services, GPRS, WAP, MMS, UMS, SMS, PTT, Cell broadcast, International Roaming and content based services. .

6.28.4 OTA applications, Location based and IN services etc.- B&CCS shall take care

of activation, suspension, deactivation & change in the subscribed services. The service creation/modification request shall be dealt by the customer administration module and forwarded via Service Provisioning module to the various databases in the network. Service requests shall be processed in real time and non -real time. It shall also be capable of producing flexible billing depending upon the use of service. The billing system shall also be capable of providing electronic versions of bills to the customers over the Internet and various bill event notifications through SMS automatically.

6.28.5 B&CCS shall support the following major functions:

a. Collection, Checking, filtering and validation of Call Detail Records from Mobile Switching Centres (MSC), MGW , SMSC, SGSN, GGSN, MMSC, Application Server of Location based services, GMLC, W AP server, OTA server, CBC, PTT and all other network elements as applicable.

b. Distribution of Call Detail Records to various applications. c. Rating & billing of voice & data calls of post-paid customers. d. Rating of Prepaid calls for interconnect settlement and reconciliation. e. Rating & billing of SMS, MMS, GPRS, Content & Data etc. in respect of post-

paid customers. f. Rating & Billing of Roaming calls for international roaming CDRs for our

outroamers and transferring Inroamer CDRs, alongwith roaming revenue settlement among operators

g. Providing timely information/data for effective and efficient customer service.

158

h. Timely and accurately invoicing of Call Details. i. Providing various discounting schemes to the subscribers. j. Providing multiple Billing Cycles (license service area) of same or different billing

period. k. Support of differential tariffs. l. Support of cross-product discounting. m. Support of charging for various types of existing and new services. n. Provisioning of services, for both pre-paid and post-paid billing. o. Customers care for service requests and bill inquiry. p. Provisioning of automatic suspension, disconnection and reconnection of service

based upon outstanding payment. q. CDRs processing in real time and/or batch mode r. Interconnect Rating, Billing & Accounting, Reconciliation, settlement of payment

and report generation. s. Revenue sharing, Content Settlement and Reconciliation with Content Providers

& Aggregators. t. Invoice calculation, formatting, dispatch and on-demand billing. u. Number (MSISDN) inventory, IMSI, SIM (ICCID) management and Voucher

Management System. v. Accounting of payments & receivables. w. Standard and ad-hoc reporting and Churn analysis. x. Roaming support and billing in Transfer Accounts Procedures (TAP3) format or

latest as defined by BARG/ TADIG of GSM Association. y. Flexible and customizable bill presentment. z. Order management aa. Trouble Ticket Management. bb. Payment acceptance through cash, draft, cheque, credit card, debit card, bank,

ATM, EFT, and from other billing systems cc. Bill presentation dd. The system should send the bills automatically through email to the subscribers

having email id in addtion to generating the print file. ee. SMS notification should be send to all the subscribers automatically for bill

amout & due date of payment. 6.28.6 B&CCS shall support the provisioning, rating, billing and accounting for the following

services:

i. Tele-services, Supplementary Services and Bearer Services of GSM ii. General Packet Radio Services iii. W ireless Application Protocol Services iv. Universal Mobile Telecommunication System and 3G Services v. Content Charging for subscriber and revenue sharing for content provider vi. Data Services vii. Messaging Services such as SMS, MMS, UMS etc. viii. Location Based Services such as Fleet Management, Navigational,

Informational, Entertainment, Advertisem ent etc. ix. Push To Talk over Cellular x. Cell Broadcast Services xi. Over The Air Services such as content down load using SIM browser

6.28.7 Billing system shall offer flexible and efficient rating engine for pre-paid and post-paid

usage. It shall perform the following processes:

i. Real time and batch usage processing and the advanced usage rating capabilities

ii. Handling and tracking of usage from end-to-end, including re-rating and errored usage utilities

iii. Real time and batch invoice calculation

159

iv. Post-paid threshold and pre-paid billing v. W holesale and third-party billing vi. Systems administration processes (including multi-level password

management vii. Authentication, Authorisation and Accounting capabilities for pre-paid

subscriber. viii. Quick Customer Registration W izard, in addition to the normal registration

interface.

6.28.8 The system should have the capability to calculate franchise’s commission and generate the invoice. Commission calculation should be flexible enough to define various schemes

6.28.9 The Mediation System Platform shall be able to collect usage events from different

network elements of GSM, CDMA, PSTN network for Voice, SMSCB, MMS, internet, data from MSC, W AP, SGSN, GGSN, Location based services application server, SMSC, MMSC, GMLC, UMTS and 3GPP on the same Platform.

6.28.10 The system must have a rules based logic configuration for mapping MTML’s

business processes. 6.28.11 The system should have Automatic Service Provisioning module, Credit

Control Module (including auto-messaging thru SMS, warning messages), Payment accounting module, Accounting report module etc.

6.28.12 SMS CDRs should be polled from SMSC so as to make SMS charging based

on the destination content 6.28.13 The latest TAP-3 should be available. Migration to any future version should

be possible. 6.28.14 All CSR counters should have the facility of online payment collection 6.28.15 Audio visual alarm indicating the failure of CDRs polling from any of the

MSC’s should be generated by the system 6.28.16 The network elements generated CDRs in ASCII/ASN.1 format shall be

transferred to B&CCS over FTP/TCP-IP or FTAM/X.25 interface 6.28.17 The system shall have exhaustive built in statistical and reporting capabilities

with option for on-screen viewing, printing and shall have relevant software for generation of custom reports by the users. It shall have a friendly GUI so that adhoc reports and MIS graphics can be generated easily. It shall be possible to generate various administrative reports, Rule set reports, collection and transmission reports, verification & processing reports, Record processing accounting rep ort (to provide details of mediation modules) etc. apart from system log on errors, commands & events. Apart from the above auditing reports, it shall be possible to define information to be collected that is as per the user requirement (tailor-made reports). Reports should be customized as per the MTML requirements.

6.28.18 The system shall be based on Relational Database Management system 6.28.19 Billing system shall be customized as per MTML requirements / MTML

business process. For this purpose, the bidder or his collaborator / MoU partner should have software development in Mauritius System shall be customized as per the MTML requirements (including reports) captured in the “Statement of W ork (SoW )” mutually agreed by MTML and the successful bidder.

160

6.28.20 The Network Management System is aimed at providing a set of robust

applications and functionality for managing the servers, SAN, router elements of the wide area network and the infrastructure required to connect MSCs as well as to support Customer Terminals. It shall have provision for following functions:

a. Security Management b. Fault Management c. Traffic Management d. Performance Management e. Configuration Management f. Remote management and display export of CSR terminals from a single

console 6.28.21 Enterprise grade anti-virus system shall be provided. Anti-virus client software

shall run on all windows based machines. It shall allow automatic antivirus patch downloads.

6.28.22 B&CCS shall interface for CDR data collection as well as service provisioning and seamlessly integrate with the existing network elements in the MTML GSM network

6.28.23 In case the bidder opts to replace the existing billing system, it will be completely successful bidder’s responsibility to -

(a) migrate the complete data to the new billing system and run at least two parallel

bill runs. Only when results of these parallel bill runs are acceptable to MTML, the system shall be put in commercial use.

(b) seamlessly integrate with all the existing network elements for service

provisioning and data collection -

- Huawei MSC - Huawei IN - Huawei SMSC - VMS - PDSN/ AAA - Cellebrum;’s CRBT - any other network element generating billable events - Content based third party applications

(c) get into a definitive agreement with the existing suppliers for integration.

6.28.24 The bidder shall provide a roadmap for future releases of the proposed system. 6.28.25 The bidder shall provide a description of the approach that the bidder would take in data migration from legacy system to the bidder application. 6.28.26 The bidder shall provide a project plan for the implementation of the MTML project and state the assumptions and dependencies. The bidder shall provide project organization structure, detailing the roles and responsibilities of each person including details of the expectations of resources required from MTML for implementation. 6.28.27 The bidder shall impart training to personnels of MTML in all aspects of

B&CCS installation, operation and maintenance. 6.29 B&CCS System requirements

161

6.29.1 General System

a. The system shall conform to open system standards and support distributed processing

b. The system shall be open multi services system.

c. The system shall operate in three (3) environments, namely Production, Test and Train. And it shall be possible to transfer production environment data to Test/Train environment.

d. The system shall be a client/server architecture based in minimum of 3 tier structure.

e. The system must be capable of processing unit transaction (e.g. add, update, delete etc.) for users of the system shall be less than 6 (six) seconds.

f. The proposed B&CCS shall be based on Relational Database Management System (RDBMS) of latest version. The system shall support open standard to function with any standard RDBMS.

g. On delivery of the system, the vendor shall modify/customize the offered system locally as per the requirements. Such possibility shall also be open to the user whenever the situation arises.

h. The offered system shall be modular and object oriented in design with flexibility to add, remove and update modules to a specific configuration.

i. Basically, the Mauritius currency shall be used in the system. However, the system shall support use of other currencies.

j. The B&CCS system shall support all types of switches and services available in the switches. The vendor shall provide the types of Mobile switches supported by the offered B&CCS system.

k. The proposed B&CCS system shall have Master and Standby (1+1) server configuration.

l. The system shall have provision to online transfer of data from Master to Standby server all the time.

m. The system shall support multiple connections, disconnection & reconnection of customers within a day immediately and/or as scheduled.

n. The system shall support connection with network printers to print the bill and locally connected dot matrix printers to print receipt/invoice.

o. Remote bill printing and receipt/invoice printing shall be possible in the offered system

p. System support & spares of the printer shall be available in the African region.

162

q. The system shall support the function of sending customer related billing

& other information to individual customer through SMS.

r. In case of detection of missing or erroneous data related to customers or connections, the system shall have provision to exclude such data from the current processing and to include them by correcting only after successful completion of the whole process.

6.29.2 System Capacity (Customers)

i. The proposed system shall be capable to store and process all the

information required to administer customer information, CDR collection, rating of call data, bill production, collection of dues and other payments, manage customer’s ledger and fraud.

ii. The proposed B&CCS system shall be capable to handle at least 210,000 normal subscribers (310,000 in phase II) including at least 10% of Hot Rated subscribers to run the system smoothly without exertion of the disk space and connection of at least 30 terminals.

iii. 50 (Fifty) Client terminals based on PC with 15” LCD monitor will have to be provided by the vendor.

iv. The system shall have capability to provide hot rating and software enabled connection and disconnection of customers for all type of switches.

v. Centralized customer ledger keeping with provision for several levels of branch activities of collection, maintaining and controlling customer accounts. The central ledger shall be reflected with the changes in real time but updates and reconciliation shall be made at the end of the day.

vi. Fully integrated customer ledger and cash collection system such that the customers can pay their bills at any collection centers, banks and/or through different types of cards and debit account systems.

vii. The system shall handle all types of services available in the proposed switch.

viii. The system shall support new services that may be incorporated in the switch within the project period.

6.29.3 Call Detail records

i. The offered system shall be able to handle the call data volume considering a minimum of 100 CDRs/UDRs per subscriber per day.

ii. The offered system shall be capable for on-line CDR collection from all types of switch.

6.29.4 Bill Production

The proposed bill system shall be able to produce at least 50,000 invoices/day and bill production shall be possible to run without affecting cash collection and normal customer care service operation

6.29.5 Online data storage The system shall keep online CDR data and bill images for at least six months. Bill amounts and collection data shall be available online until the

163

account is audited. Minimum audit period shall be considered as 18 months. All other data including customer details, suspended data, bad debts, deposits, connection, and customer history shall be available till it is required.

6.29.6 Hardware/OS

i. The system shall have hardware and OS to support the B&CCS application software to handle the customer base and user terminals

ii. The system shall have adequate hardware and software interfaces for online CDR collection from the switch simultaneously.

iii. The system shall be offered with adequate Hardware and software including tools and utilities to operate and monitor the system effectively.

6.29.7 Connections

a. The system shall be a centralized system with direct and remote terminals

access from all customer care, billing and accounting centers, collection counters and switches.

b. Generally provisioning/Deprovisioning of services in the switch shall be done through the near by terminals. However it shall be possible to handle those tasks from other terminals also with privileged users only.

c. The system shall provision for connections of more than one user from one/multiple terminals at the same time.

d. The system shall have provision of interfaces to connect to B&CCS system and its database from third party software’s.

6.29.8 Tools

a. Tools for file transfer from proposed B&CCS system to MS windows

’98/2000/XP. b. The system shall be equipped with hardware interfaces and software tools

to establish connections with the switches and perform rating, billing and accounting functions.

c. The system shall provide with software tools for system, network and database administration of the proposed system.

d. Software development tools required for system customization and development of additional sub modules, screens, reports shall be provided.

e. The system shall have software tools to manage administrative and billing data of different types of services and facility available in the switches.

f. Following tools shall be provided i) Report generation and designing tools ii) Report layouts configuration tools iii) Ad-hoc reporting iv) Dynamic Querying facilities v) Online and offline backup/Restore management tool

6.29.9 User Interface

a. The system shall support Graphical user interface (GUI). b. The software design shall be such that it is user friendly and allows for

quick menu/screens access and data entry. c. The following guide lines shall be incorporated in design of user interfaces

i) Error message , guide message, system message

164

ii) Field description iii) Value list of acceptable values for a particular filed iv) Pull down lists with selection capabilities v) Uniformity and similarity in colors and sizes, buttons, layouts of

information through screens and menus vi) Online help provisioning vii) Easy maintenance of messages, text, values etc. without modifying

program.

6.29.10 Security a. The system shall be secured with different levels of user and job access b. The system shall provide extensive securities features at many levels for

all modules. Such security’s shall be provisioned through a) OS level b) Database level c) Application level

c. All types and levels of securities provisioned in the system shall be user configurable through user interfaces as and when required.

d. Jobs shall be grouped by the level of security required. e. The system shall have provision that Application users shall not be able

to login through database. S/He shall be restricted to application only. f. It shall be possible to classify the users into twenty five (25) different

categories with different access rights to the system. At least fifteen (15) users of each category shall be able to access the system simultaneously.

g. An individual user shall be restricted to access only those applications relevant to his/her job function.

h. User shall be grouped by their functions e.g. operator, supervisors, developers, privileged users, manager, administrator etc.)

i. Users shall be restricted to install and modify the subscribers’ services to their locations only. However privileged user shall install and modify the subscribers’ services of all locations.

j. Some operations and queries shall be performed by privileged groups of users only.

k. The system shall support grace logins, concurrent logins, timed logins and logouts on idle conditions.

l. The vendor shall also provide details of access level security that shall be made available in the system.

m. System checks and user input checks shall be performed to verify information consistency throughout the system.

n. Log history of activities of all users shall be recorded. o. Some users shall be restricted to his location only.

6.29.11 Backup/Restore

i. The system shall have backup facilities at every check point of processing. Such backup shall be conducted Automatic without degrading performance of ongoing process.

ii. System shall have provision for recovery from backup in order to continue processing from the checkpoint onwards.

iii. The system shall have efficient and reliable backup and recovery on regular basis.

iv. The system shall also have external devices for backup and it shall have provision to make backup in internal devices as well as external devices.

165

v. The system shall have at least three methods of external back-up devices to keep the back-up, one of which shall be as of switch back up media so that in case of failure of EDI connection between switch and billing system, CDR files can be loaded in to the billing system.

vi. The system shall provide backup management utilities for the proper management of backup and recovery.

6.29.12 Flexible system

a. The proposed system shall be accurate, user friendly and flexible b. It shall enable user to modify as per requirements c. The system shall provide interfaces for inserting sub modules in the

system and provision for addition of modules by the user. d. The system shall have provision for addition and changes of reports,

screens, and queries.

6.29.13 Scaleable

a. The system shall be scaleable in terms of performance and functionality. b. Most batch applications performing volume processing shall run on the

servers making use of SMP servers. c. Many online and batch processes shall run concurrently making use of

multi processing environment. d. Running of batch processes and online processes simultaneously shall not

degrade the performance of the system.

6.29.14 Fault Tolerance

a. In case of failure, system shall restart incomplete processes from the last check point.

b. Each update process or any other process affecting changes in data shall be committed to the database only after successful completion of the whole process.

c. The vendor is also required to provide other features available in the proposed B&CCS to achieve maximum flexibility, scalability and fault tolerance in the system, if available.

6.29.15 History Keeping

a. The system shall have provision to keep history of all changes to systems, tariff and user operations.

b. The system shall keep history of all the data entered, modified and stored in the database.

6.29.16 Control

i. The system shall have a control mechanism to co ordinate and control all types of online, batch or parallel process, transactions executed in the system in order to provide timely and accurate information required from the system.

ii. The system shall run efficiently and accurately with the minimum manual checks.

166

iii. The system shall have control facilities to allow partial or full access to B&CCS database by an individual user and a group of users.

6.30 Hardware

The vendor is required to quote the hardware as per the Schedule of Requirement and the quantity given below. Any additional equipment required to meet the requirement specified in the RFP specification shall be included in the offer. The vendor shall provide additional hardware free of cost to meet performance of the system as per MTML’s requirement in this RFP.

6.30.1 RISC server with Storage System

The RISC server shall be in 2 (two) units configure as 1+1 high availability active and standby configuration

6.30.2 RISC processors

The offered server shall be equipped with 4 (four) or more SMP RISC processors in each server. The offered server shall have the capacity to accommodate at least additional two or four more SMP RISC processors in each server

6.30.3 Main Memory

The offered server shall be equipped with minimum 4 (four) GB of RAM in each server The offered server shall be able to increase the memory capacity to 64 GB RAM by adding memory modules. The internal data bus of the offered server shall be at least 64 bit

6.30.4 Storage Capacity The offered server shall have sufficient storage capacity to process 200,000 normal and 10% hot rated customers. The vendor shall provide the detail of space calculation base on average 100 CDRs/ UDRs per customer per day. The offered server shall have enough space for creating three environment of B&CCS i.e. Production, Test and Training.

6.30.5 Other Accessories Two Consoles(X Terminals) should be supplied for operation of the

servers.

The offered server shall be equipped with DVD Drive The offered server shall be equipped with Ethernet Network Interface card with RJ45 port

167

The offered Network Interface card shall be capable to work in 100baseT and 10 base T Ethernet Network with strapping or software setting in the card. The system shall be equipped with at least one serial port. The offered server shall have SCSI-2 port to connect external devices like optical drive, DLT drive autoloader etc. The vendor shall supply all necessary connectors and cables to connect offered peripherals.

The vendor shall supply necessary equipments (Router, Hub, Media converter, Switch, Cable etc) required for LAN and W AN network connectivity of all locations. The server shall be supplied with 15” color display, whose resolution shall be minimum of 1280*1024. The monitor shall be multi-sync monitor, in which the standard 15 pin VGA interface cable shall be installed The server shall be equipped with VGA interface card The offered server shall have port to connect UPS monitoring port of UPS for automatic power supply fail support. The mediation device required for service provisioning and CDR collection for switch shall be connected with 1+1 active standby configuration. The vendor shall supply full set of Operation and Installation manuals.

6.30.6 Backup device

The vendor shall supply 2 (two) units of 5.2 GB optical rewritable 5.25” drive, cables, connectors, software necessary for full function of drive. The vendor shall supply 2 (two) units of 100/200 GB DLT drive Autoloader, cables , connectors, software necessary for full function of drive . Software management tool fro backup/recovery for managing all internal and external backup devices.

6.30.7 Spare parts

i. 4 set of Memory Modules of capacity as used in the server. ii. 4 units of spare hard disks iii. 5 units of network interface cards iv. One hundred (100) units of optical rewritable disk for offered disk drive v. One hundred (100) units of DLT Tape cartridge for offered DLT drive

Autoloader vi. 2 units of power supply system vii. 100 (eighty) units of cartridge for dot matrix viii. Twelve(12) units of toner for Laser printers

168

6.30.8 Operating system on Server i. The offered system shall have UNIX operating system. Sufficient

licences should be provided. ii. The offered system shall support Symmetrical Multiprocessors on the

RISC servers. iii. The offered system shall work on client/server architecture iv. The offered operating system shall have utility for online backup and

recovery of files. v. The vendor shall specify and include the necessary software tools to

establish link from client’s terminal to the server in the offer. IBM compatible PC terminals shall be used for client terminals.

vi. The offered operating system shall work on TCP/IP protocol vii. The vendor shall specify and provide necessary software with manuals

to operate and manage whole networks. viii. The vendor shall plan IP address for sub networks under private IP

address range ix. The vendor shall specify and supply all necessary drivers to fully operate

all the accessories offered under this RFP x. The proposed OS shall support facilities for virus detection and removal

6.30.9 ORACLE RDBMS 1 . The offered RDBMS shall be ORACLE RDBMS and it shall be fully

compliant with offered operating system 2 . The offered RDBMS shall support Symmetrical Multiprocessors on the

RISC servers 3 . The offered RDBMS shall support client/server architecture including

following functions: i) Remote database query ii) Remote database update

4 . The offered RDBMS shall be supplied with Multiple server user licenses for Twenty (20) terminals. The vendor shall quote unit price of the user license.

5 . The offered RDBMS software shall capable to run multiple database in one server at least for Production, Test and Train purpose

6 . The vendor shall quote additional memory, hard disks and other items if required to fulfill the function of above database

7 . The offered RDBMS shall have tools to trace for problem diagnostic 8 . The offered RDBMS shall have commit and rollback for a unit of work 9 . The offered RDBMS shall have two Network committing 10 The offered RDBMS shall have replication feature to replicate to other

databases. The replication feature shall include selective tables replication and complete database replication

11 The offered RDBMS shall have Multithreading within single task 12 The offered RDBMS shall be capable of load balancing across CPU for

executing threads 13 The offered Memory in each unit of the RISC servers shall be enough for

connecting total number of users license specified in the requirement. If the specified amount of RAM is not sufficient then additional RAM shall be provided by the vendor free of cost to MTML.

14 License shall be issued directly by the manufacturer of the RDBMS software.

15 The vendor shall install and operate the system in redundant mode. That means if one server fails, then next server shall be ready to start without any interruption in system

169

16 The vendor shall supply necessary tools to install offered two (2) sets of RDBMS in two different locations.

17 The proposed RDBMS shall include Diagnostic and Tuning Packs for database tuning, diagnostics and monitoring for enhancement of performance.

18 The proposed RDBMS shall be provided with necessary Partition Option. 19 The vendor shall provide Report Generation and Designing Tolls. 20 The vendor shall provide FULL SET OF oracle MANUALS.

6.30.10 Printer

(A) Laser Printer i. The vendor shall provide two (2) units of Network printers for

printing customer bill printing. ii. The printers shall be of laser type. iii. The system shall have provision to print the bills simultaneously

in both the printers. iv. The offered printer shall also meet following features:

Printing speed of at least 100 pages per minute Cut sheets up to 5000 sheets input Up to 5000 sheets output Paper sizes A4/A3/letter Universal duplex printing OPC drum 1000000 pages per drum parallel and 10/100 base T Ethernet interface Remote printing features One units of installed toner for each printer Power and printer cables and necessary accessories Operation and maintenance manuals Auto stapling feature (Optional)

(B) Dot Matrix Printer

The vendor shall provide thirty (30) units of 9 pin dot matrix printers with continuous paper.

6.30.11 Installation and commissioning of B&CCS system

The vendor shall provide the procedure to test separate modules and the complete system including billing system’s application software, all the functional features and inter connectivity of the system with the switch. The detailed test procedures for acceptance test and final acceptance test shall be carried out in the presence of authorized representatives of the vendor. The vendor shall quote for the services required for installation and commissioning of the system, The vendor shall provide necessary tools , equipments etc and any additional cost, if any, shall be borne by the vendor

170

Complete network diagram representing the configuration for the offered billing system including integration to the switch shall be provided by the vendor. All equipment (hardware/software) to operate such a system and network shall be included in the offer.

6.30.12 Source Code

Source code for the core module of the application software is not required. However, source code covering following modules shall be provided so that MTML can add, modify and generate queries, screens, and reports and insert new sub modules as and when required.

Database structure including structure of all data items Entry Screens Reports Queries Insertion of additional sub modules

6.30.13 Documents

The application software user screens and documentation shall be in English language. Two soft copies of documents shall be provided. One set of hard copy documentation shall be provided, if available. On delivery of the system, following documents shall be provided:

i. CDR Formats, naming conventions for transferred files from MSC ii. Data flow diagrams, ER Diagram iii. Recovery, restart and reconstruction procedures iv. Details of files, tables, structures v. Report specification vi. Screen specification vii. User guide for different level of operations, use of software tools viii. Training manuals for different level of user training ix. Documents on functions and features and limitations of the system x. Screen, form and layouts xi. Menu structures xii. Technical manual on system installation, configurations, error

messages, trouble shootings

6.30.14 All the user licenses of the software products shall be licensed to MTML.

6.30.15 The successful bidder may use existing billing hardware available in MTML to the

extent possible. 6.30.16 The offered Billing & Customer Care System (B&CCS) must be integrated with call centre of 30 seats. Presently 10 seater call centre is operational in MTML Mauritius, This shall be upgraded to 30 seats and a new software for call centre integrating the existing CDMA network and the proposed GSM net work shall have to be provided. The new call centre solution to be provided by the bidder must have IVRS (in atleast tw o languages – English & French) and monitoring/ supervisory functionalities. It should have the provision of voice recording for atleast 5 ports which should be possible to be scheduled automatically to cover all agent positions. The reports related to agent performance and effective call handling would be provided as per the requirements finalized in discussion with MTML.

171

6.30.17 The Storage shall support multi-tier architecture to support different performance requirement of storage for different kind of data depending upon the policy defined by user. High performance, mid performance, low performance and off-line storage shall be supported.

6.30.18 The storage shall support GUI based storage management software tools for

management. The management software shall enable storage administrator to view, monitor, automate, provision and report on host storage resources, networks, and storage across the entire information environment from a single console.

6.30.19 Local Mirroring : Business continuity volume

a. It shall support a point-in time consistent copy of the data (full volume copy) for taking on-line Backups, Application testing, Data warehousing, MIS reporting etc.

b. It shall be possible to create at least 4 Business continuity volume (BCV) of the data

c. At least 2 BCV shall have a separate and independent relationship with the production volume.

d. Shall support instant split of BCV from the production volume e. Shall support incremental re-establish from the production data to each of the

BCV f. Shall support incremental restore from any of the BCV to the production data

6.30.20 Bidder must submit a detailed systems sizing document containing at least

the following :

S.N. Items Sizing Parameter Taken

1. Pre-paid / Post paid subscribers Mix

In any com bination/ proportion of total subscribers

2. Retention of billed data 6 m onths bill im age and billed usage 3. Retention of unbilled data 2 m onths unbilled usage 4. CDRs/day/subscriber 20 5. Bill Cycle 8

6. CDR split factor 1.6 7. Usage size 511 bytes 8. Treatm ent of prepaid CDRs Stored in the SAN 9. Bill run duration per bill cycle Less than 4 hours

10. Rating per day Less than2 hours 11. SIM inventory m anagem ent 200% of total subscribers

6.30.21 The inventory managem ent and reconciliation of SIM cards for both pre-paid

and post paid subscribers shall be maintained in the B&CCS platform and shall be fully integrated with the IN system. The inventory management and reconciliation module shall cater to at least twice the capacity of lines being tendered and shall be independent of the capacity of the B&CCS being planned.

6.30.22 The system should have feature of notifying the subscriber over SM S regarding any

change in service or welcom e message once it is provisioned by B&CCS system. The system should also notify the subscribers with a welcome m essage w hile registering in the system on roaming.

172

6.30.23 The Device for taking the full monthly backup of the B&CCS data shall be adequately dimensioned to ensure that the entire backup operation is performed within 4 hours and without interruptions affecting the normal functioning of the B&CCS.

6.30.24 The main features of existing B&CCs are annexed below. It should be

ensured that all exisitng features available in the current system are made available in the proposed new B&CCS.

6.31 EXISTING Billing & Customer Care Module 6.31.1 Customer Care Module

Customer care module shall handle at least following operations with different privileges for different operations. All customers related activities like provisioning, De-provisioning, modification shall be done everyday at any time.

6.31.1.1 Registration

The primary function of the registration shall be to enter the customer data from the application form submitted by a probable customer. The system shall generate a registration ID after data entry and immediately shall print the registration slip automatically. The screen format for registration shall be easily configurable by user as and when required.

6.31.1.2 Installation

The proposed B&CCS system shall have provision to handle the following at user options immediately after required data is entered and/or at scheduled date and time:

i) Customer Installation: Data retrieved from the registration and additional customer data as well as subscriber data shall be used for customer installation.

ii) Incomplete Installation: W hen all data required for installation is not entered, the system shall store the input as incomplete installation. The installation shall be completed after entering the missing customer and subscriber data. The user with same or higher level of access shall be able to retrieve the incomplete installation data and complete it by entering missing data.

iii) The screen format for customer installation shall be easily configurable by user as and when required.

6.31.1.3 Change of Ownership: The proposed billing system shall handle Change

of ownership (Name) on customer and/or phone users with and /or without new customer ID keeping all other information same

6.31.1.4 Change of Customer ID: The proposed billing system shall handle Change of customer ID keeping all other information same

6.31.1.5 Change of Phone Numbers: The proposed billing system shall handle Change of phone numbers without changing other information.

173

6.31.1.6 Enquiry and update

a. The system shall have provision to enquire the customer/Subscriber data by read only users as well as other authorized users.

b. The system shall have provision to enquire and update the customer/Subscriber data by authorized users only.

6.31.1.7 Customer Information

The system shall have provision to view and update the following customer’s information by inputting ant one of phone number, customer name, phone user name, customer ID etc. as and when required by the user.

Customer Name, Address, Contact No. etc. Customers’ subscription, credit limit, connection, reconnection, status etc. Customers’ personal information like Profession, designation, salutation etc. Customer’s payment and adjustment history with details Customers’ phone number history with status

6.31.1.8 Customer Services

The system shall have provision to provide the following services as and when required:

i) Allocation of features and services available in switch, any one and/or more of them

ii) Connection, disconnection and reconnection of lines iii) Viewing and updating of customer history and services used by the

customers iv) Reconnection of the disconnected customer manually and/or

automatically after payment is made.

6.31.1.9 Billing information The proposed billing system shall have the following provisions:

i) Entering all billing related data ii) Barring of subscribers manually and automatically iii) Immediately Unbarring of subscribers manually and automatically after

payment is made iv) Viewing and updating of customers’ bill history and details like bill

amount, calls related to bill etc. v) Viewing of hot rated calls immediately vi) Viewing of the chargeable calls

6.31.1.10 Ledger Information

The billing system shall provide followings: i) To view and update the deposit history with details ii) To review all comments of all transactions iii) To view and update equipment information iv) To view all the bills issued, amended, payments made and their detail v) To view all the services provided to a customer

174

6.31.2 Fraud Management

6.31.2.1The primary function of Fraud Management is to control the customers who are making calls more than the credit limits defined in the system. It shall continuously check the total billed amount and unbilled amount of the calls made by the customers. If it is greater than the credit limit amount, the system shall initiate the action to the customers as defined in the system.

The following provisions shall be made in the system.

i) To group customers in different group of fraud management ii) To define any number of credit limits to different group of customers iii) To change credit limit as and when required iv) To define any number of actions on each limit v) The system shall have provision to check credit limit amount defined in

the system with total billed amount and unbilled amount with taxes during the processing of fraud management and take the necessary action as defined in the system for the limit.

vi) The system shall have at least three levels of credit limit with different actions for each level.

vii)The system shall produce the report with actions taken as the fraud management process completes automatically daily, period wise etc.

The system shall support Fraud management system according to MTML’s requirement as and when required.

6.31.2.2 Follow ups

The primary function of Follow ups is to generate information for the users regarding the actions to be taken to handle the customer related actions. The Follow up actions on a customers’ account is entered into the system. If some transactions to be carried out on a certain customer. after completion of the job, the follow ups entry shall be automatically removed. The system shall have provision to view and update the follow ups actions to be taken care of. It shall also have provisioned to remove the follow ups actions immediately after the job has been done.

6.31.3 Reports Module

Different Reports/ Queries Generated by the Billing and Accounting Sub-system under the following Categories shall be possible :

(i) Reports for Management. (ii) Reports on which routine action is required to be taken. (iii) Exception Reports on which immediate action is required. (iv) Archival Reports.

Reports to be generated in Billing & Accounting Modules shall be customizable. Some of the indicative reports are given below: Various reports generated by a system shall broadly fall under the following categories;

(i) Management Reports :

175

a) Revenue collected in a month. b) Revenue per DEL. c) Comparison of Revenue per DEL with previous year. d) Annual Revenue per DEL. e) Cumulative Revenue collection in a Financial Year.

(ii) Action Reports :

a) Disconnection List. b) Ringing List. c) Excess Payments. d) List of unaddressed bills. e) Short Payments. f) List of Abnormal STD/ISD calls. g) List of Outstanding Bills at any point of time. h) List of cheques dishonoured.

(iii) Exception Reports:

a. List of Bills Cancelled b. List of Bills Adjusted c. List of voluntary Deposits Adjustments. d. List of Deposit Adjustments e. MIS Reports

(iv) Archival Reports

a. Local call statement b. Trunk Call statement c. Bill Register d. Outstanding Register e. Subscriber Record Cards f. List of Reconciled Payments g. List of UN-Accounted/ Excess Payments h. Sub-Ledger Accounts.

The system shall provide unlimited enquiry capabilities to all users of the system. These enquiries shall include enquiry on advice notes, bills, customer record, deposits, demand notes, wait list, working line request, payments etc. All the enquiries shall be able to take unlimited combinations of parameters and display maximum information on the screen. These enquiries screens shall from the front end of customer Service Centre, and of an operator at the call centre and also to all the officers of the organization.

The proposed system shall have provision to generate and print the reports as and when required. The reports indicated above are indicative and actual requirements can be finalized later.

6.31.4 CDR Collection and Bill Processing Module

6.31.4.1 Online Data Transfer i. The proposed billing system shall collect online Call Detail Records

(CDR) from the switch. ii. The proposed billing system shall collect online Call Detail Records

(CDR) from multiple switches of different make and model.

176

iii. The proposed billing system shall collect CDRs to B&CCS from switches on hourly basis in scheduled mode or as and when requested by user.

iv. The online CDR transfer in scheduled mode shall be user configurable v. For Hot Rating subscribers, the CDRs shall be transferred immediately

near real time. vi. Hot Rated calls shall be handled separately. vii. All necessary tools, software and hardware interface for such EDI

transfer shall be provisioned in the system. viii. The CDR data shall consist of all types calls specified in the call data

requirement ix. The proposed billing system shall have provision to retransfer the

CDRs if required.

6.31.4.2 Off Line Data transfer

The proposed billing system shall have provision to transfer the CDRs from switches to B&CCS system from offline media, in case of EDI failure.

Off line data transfer or received shall be identified by users in later dates.

6.31.4.3 CDR data conversion

i. The system shall manage all types of CDR formats collected from different types of switches

ii. All CDR retrieved from different switches using above mentioned methods

shall be converted by a common format conversion method

iii. The proposed billing system shall be able to manage and support fixed and variable formats.

iv. The proposed billing system shall support and manage CDRs of

variable/fixed record lengths of usage data retrieved.

v. The system shall also provide CDR filters for call selections and filtering.

vi. The billing system shall also support assembling of partial records.

6.31.4.4 CDR Data Validation

i.The proposed billing system shall have capability to recognize duplicate CDRs and report such occurrence but in the mean time avoid retrieval of such data.

ii.The proposed billing system shall have possibilities for allowing manual corrections to CDRs and transfer to billable data through a well defined user screen.

iii.The proposed billing system shall have provision to isolate calls of certain duration, overlapped duration.

177

iv.The proposed billing system shall validate the contents of the CDR as per the error types defined. It shall report such errors.

v.The system shall have provision to discard or correct those error CDRs and re process if required.

6.31.4.5 CDR Data Rating i. The proposed billing system shall rate each CDR based on rate tables on near

real time or on scheduled mode automatically , which shall be easily configurable by users

ii. The rating process shall also be started by user request. iii. The proposed billing system shall have provision to carry out the rating

process many times a day.

iv. In case of Hot Rating, system shall rate the calls on real time basis immediately after completion of calls.

v. The B&CCS shall calculate the usage charges of a detail records based on services and tariffs associated to the rating plan.

vi. The billing system shall report the error calls, which are not rated due to incorrect

or missing tariffs, during rating process as per the error types defined. vii. The system shall have provision to discard or correct those error calls and re

process if required through well defined user screen. viii. The system rate the calls depending upon Outgoing call, Incoming call,

Forwarded call, Event record etc. with base station wise, switch wise etc. ix. The proposed billing system shall rate the calls of one switch’s subscribers

but making calls from different switch while roaming.

6.31.4.6 Tariff

The system shall provide a versatile and flexible tariff system, easily configurable by user as and when required

The B&CCS system shall provide different prices for different subscription types, which can have different services, facilities, events.

It shall apply different kinds of charge for the following:

Fixed Charges Connection and monthly charges for services and subscription Charging for both outgoing and incoming calls Data volume sends or received

It shall charge the call depending upon

Called Number Calling Date Calling Time Duration Cell ID Day

178

Holidays Switch Size of data

The B&CCS shall assign any tariff rate to any charging zone and to any cell Id for both outgoing and incoming calls. It shall be configurable by use as and when required. It shall support at least 50 different groups of rate for national and international calls, which shall be configurable by user as and when required. The B&CCS system shall consist of time packages to cover 24 hours, 7 days time intervals and different types of special days. Outgoing and incoming calls’ usage charges shall be calculated separately. It shall handle additional fees and discounts It shall have provision to rate for the transferred calls. The system should support Closed User Group (CUG) billing. The CUG can be the groups in which the calls are restricted within the group or allowed outside group for some members of the group. There should not be any limit in the number of members in a group or total number of groups. The system shall have provision to create and apply the tariff immediately or as scheduled by user. The system shall keep the history of all tariff changed with date and time.

6.31.4.7 Discounts

The B&CCS system shall have provision to

a. apply flat discount b. to use different discount scheme for different customer groups c. to define volume discounts scheme for different customer group

The discount shall be based either on Duration and/or amount and/or combination of Duration & Amount with at least three different limits for customer groups. The B&CCS system shall support discounts both on outgoing and incoming calls. The B&CCS system shall support discounts on different services like data, voice etc. separately.

The system shall provide different discounts on different types of calls like local, STD, ISD etc.

The system shall provide discounts on

a. Amount b. Percentage

179

c. Amount and Percentage

6.31.4.8 Preparation for Bill creation

a. The system shall have provision for processing of usage data from any switch for the purpose of testing or production of traffic and error analysis reports as and when required without causing any malfunctions in the regular bill production process and financial transaction

b. It shall have provision to check and verify completion of preceding tasks before initializing bill generation.

c. Some checking’s and verifications shall be done in the system for the bill productions.

6.31.4.9 Credit Control

a. The proposed billing system shall have various levels of credit limits. b. The system shall check the credit limit against billed and unbilled amounts

with taxes automatically, whenever rating is done. However, such checks shall be done on user request

c. The fraud management initialized as a result of this checks. d. The credit limits and levels shall be easily configurable by user. e. It shall support the different credit limits for different customer group. f. It shall generate reports on all customers, subscribers that have exceeded

their limits during credit limit check.

6.31.4.10 Billing Modes of Operation

Normal Bill Run The billing shall support billing of all customers for a selected bill cycle. On Demand Bill run The system shall have provision of immediate billing of a customer or group of customers without financial implication in the system.

6.31.4.11 Bill type

Following different types of bill for the customer shall be provided in the system.

Normal bills on Subscriber/customer basis Consolidated bills for the customer using more than one connection Department/Level wise bills for large organization Summary and itemized bills as per customer requirements

6.31.4.12 Billing Cycle

a. The proposed billing system shall support multiple billing cycles within a

bill period for different group of customers b. The system shall have at least 8 (Eight) different billing cycles. c. The bill processing shall be in multiple bill cycles. d. The bill cycle shall be assigned to a single customer or group of

customers. e. The system shall have provision to transfer one bill cycle to another for a

customer or group of customer f. The vendor shall mention number of billing cycles in system, if any.

180

6.31.4.13 Billing period

a. The B&CCS system shall have provision for generation of a number of

customer’s bills for all the customers in one month. b. It shall be possible to adjust the billing periods by user as required. c. The B&CCS shall have facilities to handle multiple billing periods for

different group.

6.31.4.14 Bill generation

a. The B&CCS system shall calculate summary charges for each customer by relating to rated calls and their subscription charges.

b. The system shall calculate short period rental for initial billing, based on date of installation or transfer.

c. The system shall calculate previous dues. d. The proposed billing shall manage different due dates for different

customers. e. The system shall also calculate summary charges as following items:

Rental Supplementary Services charges Administrative charges Local call charges National Call charges International Call charges Discount Fines Taxes etc.

f. It shall also summarize consolidated bills for customer paying for many

subscribers and or services g. The system shall process billing generation of different group of

customers in different billing cycles. h. It shall have provision to produce on demand bill as per MTML

requirements. i. During Bill generation Printing will be done centrally. j. During Bill Generation, calls up to the end day of the defined Billing

period only shall be included even though next billing periods calls are already rated in the system.

6.31.4.15 Bill Production.

The production of customer bills shall be flexible and support the following functions: Production of hard copy bills (in English) for a specified time period Updating sales ledger Individual bill production or a copy of a bill between periods on request Call details (Call details shall be flexible and for specified categories

i.e. ISD , STD , Local and Incoming) Facilities to print a number of selected customers’ bill from host

terminal & also from remote terminal.

181

Facilities to print general messages on bills to all or specific group of customers by users at any time

Facilities to handle debts from previous bills

It shall be possible to configure and to apply at least 50 different rates of Late payment charges on different due dates on different customers independently by user at any time. Facilities to handle different types of taxes as applicable in Mauritius and easily configurable by user as and when required. Facilities to provide discount, adjustment, rebate, fine etc. on periodic bill Facilities to produce the bill of permanently disconnected customers as required by MTML. System shall have provision to produce the bill of a customer of group of customers as and when required by MTML. The system shall provide the tools for selecting, combining and modifying bill layouts. The system shall execute bill production for multiple groups.

Facilities to produce different types of bills on paper direct debit records to banks EDI (Electronic Data Interchange) bills

6.31.4.16 Hot Rating:

The system shall rate the call real time for hot rating subscribers. Such calls shall be accessed by customer by various means of secured communication link; Dialup, Leased, Internet. Necessary interface units and secured access method shall be provided.

6.31.4.17 Bill statement

The proposed billing system shall provide tools for layout configuration of bill formats and receipts. It shall have the facilities to generate multiple formats as and when required. The Bill printing should have the information required for payment matching in standard BARCODE to be scanned by collection centres. The customer bill statement as per MTML requirement shall be designed & developed during system study.

6.31.4.18 Reports on CDR collection and Bill processing

182

All major reports shall be generated by the system on completion of the major process and also shall be generated by user as and when required. The reports shall be produced by entering one and/or multiple fields contained in the report. The report shall be for selected period of time The produced report shall be printed as required. (A) CDR collection report

The system shall generate this file transfer report daily, weekly, monthly basis weekly at least following items:

File name Date & time of transfer File status Name of switch Size of file Start and end date, time of data in the file User id

List of file rejected or unsuccessful with reason List of retransferred files

(B) Conversion report i. The system shall generate this file conversion report daily, weekly,

monthly basis with at least following items: File name Date & time of conversion File status Name of switch Size of file Start and end date, time of data in the file Total processed calls User id

ii. List of calls rejected with reason

(C) Call rating Report i. The system shall generate the Summary of calls rated daily weekly,

monthly and as and when required with at least following items: Name & size of files Total calls, duration, and charge by call type Total calls rejected by error type and call type Date & time file was rated

ii. List of rejected calls by error type for each CDR file daily , monthly, certain period, as and when required

iii. Reports for traffic analysis shall be produced on each rated file: Hour-wise totaling of calls, duration, charge by call type Day-wise totaling of calls, duration, charge by call type Month-wise totaling of calls, duration, charge by call type Given period wise totaling of calls, duration, charge by

call type iv. Total unbilled call charge report per file by call type v. Report on Corrected calls

(D) Bill creation and Production report

183

i) Report of each bill run for billing cycles ii) Error report during each bill cycle iii) Summary of charges for each bill cycles for all customers individually

and/or totally iv) Discount report v) Fine report vi) Adjustment report

(E) Summary Control Reports

i) Summary of calls , duration, CDR files used for each bill group of the billing period

ii) Total no. of calls for different types of calls. iii) Total no. of calls and duration summary report by customer iv) List of high paying customers for each billing period v) Credit/Debit card reports vi) Report of calls before and after invoice run for a billing period vii) Report of calls that was not billed due to some reason for a billing

group 6.31.5 Customer Ledger and Cash Collection Module

6.31.5.1 General

The proposed Ledger and Cash Collection module of B&CCS system shall help maintain up-to- date accounts of all customers of MTML and provide on-line cash collection services. It shall also generate various relevant reports for operations and management of customer accounts. The ledger and cash collection module of the B&CCS shall be centralized connected with different accounting centers/Collection centres. Customers shall be able to make ledger inquires at any counter or accounting center. Customers shall have the options to pay dues and/ or any other payment at any MTML counter, Banks listed by MTML, through credit cards and/ or direct debit of accounts in banks against any bill received from MTML. Information on customer dues of any customer shall be available in any MTML counter. The proposed system shall have multiple levels of hierarchy and higher shall perform all lower hierarchy job while lower shall not have authorization to higher level. The offered system shall support at least 5 levels of accounting units: Head office, regional office, Accounting centers, collection counters and collection points Besides the requirements, specified in this RFP, the vendor shall also propose additional relevant features available in the offered system for efficient management and maintenance of the accounting and collection system.

6.31.5.2 Cash/ Debtor collection

The system shall support for on-line cash collection and on-line updating of the ledger system. It shall also be possible to update the customer ledgers on batch mode.

184

This module shall manage collections through different counters of MTML. Collection details shall be reflected in the central database in order to provide the respective up- to- date information in all the collection centers. The transfer to Central Collection Daybook shall be initialized after verification of the transactions at each collection counter. The system shall always recognize collection items of each counter and manage accordingly. The collections made at bank shall be transferred, verified and updated after automatic checking of all payable amounts including taxes, penalties etc.

(A) Debtor collection

Collection amounts: The collection amounts for debtor collection shall mainly consist of followings:

Bill amount (total amount as per Bill Statement) Previous dues Service Charge VAT amount Other Taxes Penalty amount Reconnection charge

The system shall have provision to increase or decrease the number of items under collection amounts. The rules and logic for calculations shall also differ. The system shall be flexible enough to handle all such requirements through user interfaces. In case of partial payment of the bill amount, the system shall calculate Taxes (TSC, VAT and other Taxes) based on the submitted cash/ cheque amount.

It shall collect payment from the customer by phone number, Customer ID, Invoice No., Consolidate Account ID. The system shall also collect for a group of customers and receipts shall be generated for each such customer. The collections shall be against each bill or several bills or all dues. The system shall be able to generate one receipt for such type of collections. The system shall always clear oldest dues on collection. System shall accept partial payment against any account and shall automatically clear the oldest dues. System shall accept amount equivalent to a single bill, groups of bills or all bills and generate a single receipt for the receipt. The system shall accept partial and/or full payments from the customers. The tax amount shall be calculated accordingly. This system shall make provision for granting rebate to the customers, which shall easily configurable by user as and when required. System shall calculate penalty as per MTML rules and regulations.

185

Collections shall be in cash, cheque, credit card and/or their combination. The system shall have the facility for bank collections on-line and in batch mode. The system shall automatically generate the penalty amounts, check the penalty payments and generate reports if required. The system shall have the provision to wave penalty fully or partially by a privileged user.

(B) Deposit collection

This system shall accept deposits from customers by a) Phone No. b) Customer ID c) Customer name Provisions shall be made for refunding of deposits in all cases. During new installations, other charges shall be accepted along with the deposit. However, separate receipts shall be generated for such charges. The proposed billing system shall provide Depositors’ lists with detail ledger and its history. Interest on customer’s deposit shall be calculated and posted by the system as per MTML’s rule

(C) Cash sales

Besides debtor and deposit collections, other payments against cash sales such as followings shall be acceptable in this system. Registration fee Installation charge Ownership charge Sale of handsets, accessories etc. Ownership transfer charge Contract change charge Taxes for above charges Charge of detail bill print out The system shall have provision to increase or decrease the number of items under cash sales. The rules and logic for calculations shall also differ. The system shall be flexible enough to handle all such requirements through user interfaces.

(D) Advanced collection

186

The system shall accept advance payments and automatically allocate them under appropriate account heads w hen dues are posted. (For fraud management purposes, the credit limit shall be adjusted accordingly.)

(E) Receipts Receipts once entered and issued to the customer shall not be modified in any case. However, the system shall have the provision to make amendments if errors are detected through vouchers raised by cashier/manager only. The system shall also have provision to cancel receipts before update by a privileged user. The system shall have provision for reprint of receipts immediately and control mechanism for such reprints. Receipts layouts shall be flexible and the system shall be provided with tools to modify them. There shall be provision for using pre-printed receipts, which shall be different as per collection types and services. The system shall generate continuous serial numbers of the collection receipts. The system shall also have provision to reprint the collections receipt. The summary report shall indicate the number of reprints and their serial numbers. The receipts shall be printed on local printer attached to the terminals.

(F) Verification on collection and updating of accounts

This system shall be able to generate various reports, for verification, as follows. By counter cashier At the end of the day, the counter cashier shall be able to generate Summary reports indicating amount tendered by each customer, amount refunded by counter cashier, collection amount, total collections under different headings e.g. Bill amount, Penalty amount, Tax amounts, Deposit amount etc. Collection by Cash, Credit and/or Cheque shall also be indicated clearly in the summary report. In case of cheque collection, bank wise listing of cheque with number and amounts shall be produced. Similar reports shall also be generated for collections by Credit Cards. Individual entry list (in order of Receipt numbers) with collection details shall be generated. By cashier (Manager) Individual Cash Collection Report Cancellation list (Individual) Consolidated Cash Collection Report with amounts itemized under account heads.

(G) Centralized cash system

187

The proposed billing system shall have provision to query and generate the following reports:

Collection Report of each collection counters. Accounting Center-wise Collection Report Region-wise Collection Report (daily) Corporate Collection (Daily) Report Summary Report of different taxes collected (daily) Collection Report for late payment (daily, monthly) List of adjustment vouchers relate to collections

6.31.5.3 Ledger This system shall maintain and control all customer ledgers. The system shall

have high accuracy and security controls in all the functions performed.

(A) Bill posting

Bill posting and updating of debtor accounts and other related account heads shall be possible. The bill posting and updating of accounts shall be carried out by using invoice run batch code or selected customer or accounting center wise etc. Bill posting to the related account heads shall be committed only after automatic verification by the system. The system shall have provision for reverse posting. The system shall have provision for consolidated accounts. (B) Cash collection and update

This system shall have the provision to post collected cash details to relevant

account heads. The posting shall be carried out only after verification of the cash collection reports.

(C) Debtor management Reports and queries

a) Listing of debtors by customer status (government, corporate, private

customer etc. b) Listing of debtors for given (a) range of period and/or (b) balance

amount. c) Debtor list (a) by switch, (b) accounting center wise, (c) region-wise

and (e) Credit Limit. d) Detail ledger of all customers. e) Queries on debtor collections by respective accounting center. f) Queries on debtor collection of the customers located in other

accounting center. g) Queries on customers’ up- to- date balance and detail ledgers based

on period and balance amount. h) Customer history with individual accounts details.

188

i) Billing summary Report.

Summaries of all fields of billing statement are to be ascertained in these reports from periodic billing statement issued to the date. Reports shall be produced by GOVT., Company/consolidated, Service, Individual and shall show the following Data fields:

Customer ID, Periodic Prorate Rental Charge, ATC, Incoming: Duration- amount, Outgoing: Duration – Amount, STD: Duration, amount, ISD: Duration, amount, Roaming: National, International, Supplementary/ Value added service charges, Discount, Sub- Total Amount, Rebate, Fine, Total amount (Before TSC & VAT), Total Taxes, Total bill Amount (Including TSC & VAT).

Age wise classification of debtor balance

The system shall be able to classify debtor balance for various periods

(ages). The classifications shall be based on age groups from one month to 6 months in steps of one month.

(D) Defaulter management

This system shall identify such subscriber who has not cleared dues (bill payment) in time. The system shall prepare defaulter list according to customer status, total due amounts and outstanding amounts in each defined period. The system shall allow users to make dynamic queries by different parameters regarding defaulters in various categories. Some of the user inputs are

- Dues not cleared for one month - Two months - More than two months - Dues more than entered months - Dues of certain period and amount

If payment is not made within a certain period of time, the system shall generate list of customers. A defaulter status shall be maintained to flag defaulters for future references. The B&CCS shall compare the customer’s credit limit with the total of the billed and unbilled amounts. Based on the different amount, the fraud management system shall apply call restrictions. For example,

a) Send SMS b) Outgoing calls barred c) Incoming calls barred d) Both outgoing and incoming barred

In case of Cheque dishonour, the system should generate a notice to customer and it should keep record of customers and shall not allow them to make payment by cheque again unless otherwise permitted by the authorized person.

189

(E) Voucher Entry All adjustments to the ledger system shall be done though voucher entries.

The voucher entries shall be manual and/or system generated for certain defined tasks. The system shall have the following possibilities: Voucher entry to adjust accounts of all account heads and updates by only certain user group. Adjustments to some account heads shall be restricted to privileged users only. The system shall have provision for manual entry, verification and update through vouchers of (a) receipts (b) bank statement against collections made off-line. Listing of vouchers from daybook (collection counter-wise or accounting center-wise) Provision for correcting wrongly entered data in daybook. The updated vouchers shall not be modified. Records marked as posted or updated shall not be modified. The system shall have provision for correcting posted data by generating relevant approved vouchers only. The system shall create and generate vouchers for bulk adjustments. The criteria for such adjustment shall be defined by user input. During entry and update of vouchers, automatic verification of debit/credit amount shall be carried out. It shall be possible to identify vouchers by entry users, counters, accounting centers, entry and transaction dates, voucher types, etc. (F) Trial balance

The system shall provide the following: Provisions for uptodate Trial Balance accounting center-wise, region-wise and in total. Trial balance generation for a user defined period. Automatic generation of trial balance report after each batch of updates resulting changes in amounts. Summary of balance of all Customers ledger shall be summarized in Trial Balance on daily basis. The Trial Balance shall be produced on daily basis as per the MTML’s requirement formats. The system should having the facility of creating flat files by the required tools to export/import data to other systems like financial systems as required by the users.

190

(G) Other queries

The offered B&CCS system shall provide the following queries: a) Query for cash in transit b) Query for up- to- date balance of all account heads defined in the system

(H) Date format All transactions in the system shall have fields to store English Calendar date.

All system operations such as entry, posting, viewing, reporting, etc, shall use English calendars.

(I) Flexibility for the module

The proposed system shall have provisions for following operations:

- Adding account heads - Creating and removing levels of account heads (main, sub, sub-sub,

detail, etc.) - Adding collection counters/ accounting centers - Application of different taxation rates as per government notice. - Application of penalty rates as per prevalent rules - Application of prevalent rebate schemes

6.31.6 Disputes management

The system shall register complains on bills. The system shall have the possibility to retrieve full history of all disputes raised

by a customer. The system shall have credit adjustment possibilities for settlement of disputes.

6.31.7 Inter connect Management

The system shall handle inter connect billing and collection of data for such billing. The system shall have interfaces to enter, update or delete various operators’ information, tariff, discounts and other agreement details The system shall provide such agreements with GSM, PSTN, Local and internationals. The proposed system shall have provision for generation of queries and reports on charges to be claimed from other operators. The report shall contain total no. of calls, total duration, total amount in different currencies like US$, Mauritian Rupee etc. and it shall be destination-wise, origination-wise, period-wise etc. for each operator The B&CCS have provision to compare and verify those data received from other operators with the data contained in the system.

191

The system shall support different tariff plan. The system shall have provision to the sharing reports both for outgoing and incoming calls

6.31.8 Fault Management System The main functions of the Fault Management system shall be as follows:

i. Complaint Booking ii. Initial Testing iii. Sub-Fault Control iv. Final Testing v. Clearance of Faults vi. Batch Mode Booking of Faults and Complaints vii. Report and statistics on complaints/faults for MIS and SLA viii. Automatic Rebate calculation based on downtime

6.31.9 Directory Enquiry System

The main requirements of the system are: i) Should be flexible to adapt timely to new requirements. ii) Automatic updating of DQ information based change in customer

status should be provided. iii) Possible to search the database with different combination of elements. iv) should support complex searches and search arguments such as starts

with , End in etc. v) Should be able to provide data for Directory printing

* * * * * * *

Section V

SCHEDULE OF REQUIREMENTS

Sl No.

Description Unit Phase 1 Phase 2 Total Remarks

1 NSS Common core for GSM 2G/3G

1.1 GMSC/MSC/ VLR System 1 - 1 Design as per RFP

1.2 MGW x - x As per vendor design

192

1.2 HLR/AUC/EIR System 1 - 1 Capacity atleast 310,000 subscriber, including existing CDMA

1.3 HLR upgrade to HSS architecture for R5 support 0 1 1

MTML reserves the right to order this upgrade independent of Phase-II P.O.

2 IN System including IVR for Prepaid (2G & 3G Subs) Common for both

CDMA & GSM/3G

2.1 Hardware For 500 K subs 1 0 1 It shall be possible to

expand the IN to support 1M Subs. 2.2 Software For 500 K

Subs 1 0 1

2.3 New comm on VOMS & Adm in system

For 500 K Subs 1 0 1 Shall support 1M

active recharge PINs. No limit should be on total PINs generated in IN.

2.4 E-Top Up/ E-PIN system 1 0 1

3 Operation & Maintenance System

3.1 (a) Comm on 2G / 3G / CDMA OSS for com plete network (Hardware)

1 - 1 OSS supplied in Phase-I shall required to be expanded for Phase-II requirem ents free of cost.

(b) Comm on 2G/3G/ CDMA OSS for com plete network (software) 1 - 1

3.2 OMC-S

Hardware & S/W Per PLMN 1 - 1

3.3 OMC-R (comm on for GERAN & UTRAN)

a Hardware & Software Per PLMN 1 - 1

OMC – R supplied in Phase-I shall be expanded for Phase-II requirem ents.

Sl No. Description Unit Phase 1 Phase 2 Total Remarks

4 Combined Packet Core Network for 2G & 3G Subs

4.1 2G / 3G GGSN

a 2G / 3G GGSN Hardware For 50K

PDP Contexts

1 0 1

b 2G / 3G GGSN Software For 50K

PDP Contexts

1 1 2

4.2 2G / 3G SGSN

a 2G / 3G SGSN Hardware For 50K

PDP Contexts

1 0 1

b 2G / 3G SGSN Software For 50K

PDP Contexts

1 1 2

193

5 SMSC

5.1 Hardware For 200 K BHSM 1 0 1

5.2 Software For 200 K BHSM 1 0 1

6 Location Based Services

6.1 GMLC For 100 K subs 1 0 1

Equipm ent supplied in Phase-I shall be expanded for Phase-II requirem ents.

6.2 SMLC For 100 K subs 1 0 1

6.3 Location Based Application Server For 100 K subs 1 0 1

6.4 Location Based Software license Transaction per second 10 0 10

6.5 Cell Broadcast System (CBS) 1 0 1

7 Push to Talk System (PTT) This item is optional. However, the sam e w ill be considered for evaluation.

7.1 PTT Hardware For 20K Subs 1 0 1

7.2 PTT Software 20K Subs 1 0 1

7.3 PTT handsets 25 0 25

8 Multi-Media Messaging Syste m (MMS)

8.1 MMSC Hardware For 10K BHMM 1 0 1 Equipm ent supplied

in Phase-I shall be expanded for Phase-II requirem ents.

8.2 MMSC Software For 10K BHMM 1 0 1

8.3 W AP Gateway

1 0 1

9 OTA server 1 0 1

10. BSC

10.1 BSC Hardware X Y X+Y As per bidder’s design

10.2 BSC Software Per TRX

TRX count for m icro BTS and expansion in Phase-II m ay be included. Calculation sheet for the total num ber of TRX for each phase m ay be attached.

10.3 Transcoder

10.4 PCU Per BSC X Y X+Y As per bidder’s design

194

11 GSM BTS ( All new BTS/ TRXs should include EDGE hardware)

11.1

900 MHz Macro BTS (distributed architecture BBU+RRU) 3+3+3 Configuration (Indoor type) should be support EGSM/ 1800/ 2100 band also in future by adding only RRUs

Per BTS 50 50

11.2

900 MHz Macro BTS (distributed architecture BBU+RRU) 3+3+3 Configuration (Outdoor type) should be support EGSM/ 1800/ 2100 band also in future by adding only RRUs.

Per BTS 60 40 90

The num ber of BTSs m entioned are

minim um. The bidder should quote m ore if its design requires so

for m eeting requirem ents

11.3 Micro BTS Per BTS - - - As per bidder design

11.4 Cell on W heel (CoW ) – Mobile BTS alongwith all accessories, tower and trolly

Per BTS 2 0 2 Optional Item but w ill be considered for evaluation.

11.5 EDGE TRU software One per BTS 110 40 150

11.6 2G BTS repeater of 2 W att power 10 0 10

11.7 UPS w ith 2 hour back up for BTS repeater 10 0 10

12 BTS Expansion Kits

12.1

BTS Expansions from 3+3+3 to 6+6+6 (3+3+3 in 900MHz & 3+3+3 in 1800 or EGSM band

Per BTS 0 40 40

12.2 Upgradation to HSDPA/ HSUPA Per BTS 0 150 150

The order for this m ay be placed before the Phase II order also for som e BTSs only.

12.3 HSPA Software Upgrade Per BTS 0 150 150

HSDPA should be available in all sectors of one carrier per BTS.

13 BSC/ RNC Hardware & Software for HSPA - X X As per bidder’s

design

14 Infrastructure Equipment for Non MTML sites

14.1

Roof Top Tower 9 Meters

Including Set of 9 Antenna Mounting fixture per tower.

15 10 25 These quantities are for evaluation purposes. Ordering of this item shall be as per actual requirem ent of MTML.

14.2 Roof Top Tower 12 Meters -do- 5 5 10

14.3 Roof Top Tower 15 Meters -do-

5 5 10

14.4 Roof Top Tower 21 Meters -do-

5 5 10

195

14.5 Poles 6 Meter Set of 9 Poles per site

5 5 10

14.6 GBT 30 Meter -do-

10 5 15

14.7 GBT 45 Meter -do-

15 5 15 These quantities are for evaluation purposes. Ordering of this item shall be as per actual requirem ent of MTML.

14.8 Any m odification/ expansion required in existing MTML site towers/ shelter

Per site

50 0 50

14.9 Palm Tree type tower (30 Meter) for asthetic look m atching the environm ent

5 0 5

Optional item but w ill be considered for evaluation.

15 Battery and power plant

15.1 Additional Outdoor Battery cabinet having 4 hr backup Per Set 30 20 50

These quantities are for evaluation purposes. Ordering of this item shall be as per actual requirem ent of MTML.

15.2 Expansion of MTML sites power plant and batteries if required Per Site 50 0 50

15.3

Indepenedent Power Plant (SMPS) and Batteries for Core Network Site, if it is separate than the present CDMA site

1 0 1 Optional item s but w ill be considered for evaluation

15.4 DC Power Distribution Board (DCPDB) of suitable capacity Per site 60 40 100

15.5 Battery sets for BSC/ RNC sites if planned separately X Y X+Y

15.6 Battery sets for MSC/ MGW sites if planned separately 1 0 1

15.7 SMPS Power plant for BSC/RNC X Y X+Y

15.8 Expansion of SMPS power plant for

comm on core n/w elements site if the existing site is used

1 0 1

15.9 UPS/ Inverter for MSC/ OMC etc 1 0 1

16 Installation Material

16.1 BSC/ RNC Installation Material Per Site X Y X+Y

16.2 BTS Installation Material - New Sites Per Site 60 40 100 These quantities are for evaluation purposes. Ordering of this item shall be as per actual requirem ent of MTML.

16.3 BTS Installation Material – MTML sites Per Site 50 0 50

16.4 Feeder Cable 7/8" - BTS Per site 110 40 150

These quantities are for evaluation purposes. Ordering of this item shall be as per actual requirem ent of MTML.

196

16.5 Additional items if the core network is tobe installed at a separate location

1 0 1 Optional item but w ill be considered for evaluation

17 Antennae with mounting fixtures All 3G antennae w ith rem ote variable electrical down tilt shall be quoted.

17.1 65 degree beamwidth (Gain >=17 dbi) Dual Band Per site 110 40 150

These quantities are for evaluation purposes. Ordering of this item shall be as per actual requirem ent of MTML.

17.2 65 degree beamwidth (Gain>=17 dbi) Tri band - For W CDMA 3 sector sites

Per site 110 40 150

18 Transmission Media for all sites

18.1 (a) SDH M/W links Per Hop 50 20 70 These quantities are

for evaluation purposes. Ordering of this item shall be as per actual requirem ent of MTML.

18.2 (b) NMS for SDH 1 0 1

18.3 PDH augm entation Per Hop 50 20 70

18.4 Installation Material including Antennae, cables etc. Per Hop 100 50 150

18.5

Additional transm ission links, including the cost of accessories if the core network is installed at a separate location than the existing MTML site

Optional item but would be considered for evaluation

19 Tools and testers

19.1 RF Planning Tool

1 0 1

19.2 Drive test tool

1 0 1

19.3 Post Processing Tool w ith digital

m ap 1 0 1

19.4 Protocol Analyser

1 0 1

19.5 Hand held GPS receiver

2 0 2

19.6 BTS/ Node B tester

2 0 0

.

19.7 W CDMA (UMTS) Transm itter

Analyser 1 0 1

19.8 W CDMA (UMTS) Over the Air

Analyser 1 0 1

19.9 Engineering Handsets

5 2 7

20 B&CCS expansion/ upgradation or replacement with new one

1 0 1

20.1 CSR terminals 30 20 50

20.2 Call center interface for 30 seats

1 0 1

197

23 Lawful Interception & Monitoring 1 0 1

24 FMCC (Fraud Management Control Centre) 1 0 1

25 Push Mail Server

1 0 1

Optional item but w ill be considered for evaluation

26 Spares for three years after

warranty & AMC 1 set 1 set

27

Outdoor BTS cabinet (without BTS) for putting existing CDMA

BBUs 50 0 50

Optional item but w ill be considered for evaluation

28a

Any Other Item not mentioned in RFP, but is required for

completion of project as per RFP

28b

Any Other Item not mentioned in RFP and not required for project

but which bidder feels would help MTML in competing effectively &

providing better services

These would be optional items and w ill not be included for evaluation but m ay be considered for ordering.

Services: The price of services for respective quantities

mentioned above against each item may be quoted.

Sl No. Description Unit Phase 1 Phase 2 Total Remarks

29 Installation and Commissioning

29.1 MSC server

29.2 Media Gateway

29.3 HLR

29.4 IN

29.4 STP

29.5 Packet Core Network

29.6 SMSC Installation

29.7 LBS Installation

29.8 PTT Installation

29.9 MMS Installation

29.10 BSC Per unit X Y X+Y

29.11 (a)

GSM BTS Installation -New Per BTS

29.11 (b) GSM BTS - Expansion

198

29.11 (c) GSM BTS installation – SW AP site

29.11 (d) Micro BTS Installation Per BTS

29.11 (e) GSM TRX Expansion Per TRX

29.12 RNC Per unit A B A+B

29.13 (a) NODE B Installation Per Node B

29.13 (b) Micro Node B Installation Per Node B

29.13 (c) W CDMA TRX/carrier Expansion Per TRX

29.14 (a) Roof Top Tower (9,12, 15,18 m )

29.14 (b) Poles

29.14 (c)

Ground Based Tower (GBT) of 20, 30 & 40 m eter

29.14 (d) Delta Poles 6 meters and 9 m eters

29.15 Power System & Battery Installation Per Set

29.16 (a) Transmission Media – SDH Per Hop

29.16 (b) Transmission Media – PDH Per Hop

29.17 B&CCS Installation Per Unit

29.18 RF Survey

29.19 Project Managem ent Per PLMN

29.20 Operation support for 3 m onths of Commercial launch

29.20 Decomm issioning &

Recomm issioning of any network elem ent envisaged.

29.21 Upgradation of existing elem ents

30 Annual Maintenance Contract

30.1 Year 1 30.2 Year 2 30.3 Year 3

31 Any other item /Services to meet the tender requirem ent. (Details to be given)

Note: - The quantities indicated in above Bill of Materials are m inim um except for those item s where specifically it has been m entioned in rem arks colum n that “These quantities are for evaluation purposes. Ordering of this item shall

199

be as per actual requirem ent of MTML”. Bidders shall quote for the actual B.O.M required to m eet the tender obligations for successful com pletion of project.

Section VI

Delivery Schedule

A. Completion of Factory Inspection at

Manufacturer’s Premises, if required by MTML

Within 3(Three) months from the date of PO.

B Commencement of Supply of Equipments

W ithin 4(Four) months from the date of PO.

C Commissioning of Core Network and BTSs at existing MTML sites

Within 7(Seven) months from the date of PO.

D Commissioning of IN, B&CCS and Within 11(Eleven) months from

200

75% of the balance BTSs the date of PO. E Completion of entire Turnkey project

with installation, commissioning after successful Acceptance Testing, including migration of HLR, IN, B&CCS and other elements wherever required.

W ithin 14(Fourteen) months from the date of PO.

201

SECTION-VII

BID FORM & PRICE SCHEDULE

TABLE-I A

(EQUIPMENT & SOFTWARE in Phase I)

Figures in USD S.No. Item

Description

(As per

Schedule of Requirement)

Quantity Basic

Unit

Price

Taxes &

Duties

(Out side

Mauritius)

Freight,

Forwarding,

Packaging

Insurance Any

Other

Charges

Basic all

inclusive

Price

{(4)+(5)+(6) +(7)+(8)}

Discounts Total

Price

{(9)-

(10)}x (3)

1 2 3 4 5 6 7 8 9 10 11

TABLE-I B

(EQUIPMENT & SOFTWARE in Phase II)

Figures in USD S.No. Item

Description

(As per

Schedule of

Requirement)

Quantity Basic

Unit

Price

Taxes &

Duties

(Out side

Mauritius)

Freight,

Forwarding,

Packaging

Insurance Any

Other

Charges

Basic all

inclusive

Price

{(4)+(5)+(6)

+(7)+(8)}

Discounts Total

Price

{(9)-

(10)}x

(3)

1 2 3 4 5 6 7 8 9 10 11

Note: MTML may take a decision to go for upgradation to HSPA to all or only in some BTS

areas depending on requirement, even before Phase II order is placed. Thus for Table IB, the

price quoted should be on per BTS basis. For evaluation purposes, full cost for upgradation to

HSPA for whole network depending on total BTSs in phase II would be taken.

TABLE-II

(SERVICE CHARGES)

Figures in USD

S.No. Item description Phase 1 Phase 2

1. Installation, Testing, & Commissioning

Note:

The vendor shall give break up of the Installation, Testing & Commissioning costs for

various systems & sub systems. This may facilitate the purchaser, at its sole discretion, to

consider payment to the Contractor for different services at different times as per

completion of the same.

202

TABLE-III

COMPREHENSIVE ANNUAL M AINTENANCE CONTRACT (EQUIPMENT &

SOFTWARE) FOR 3 YEARS AFTER WARRANTY PERIOD

S.No. Item Description Year wise AMC Charges

Year 1 Year 2 Year 3

Note:

Year wise AMC charges shall be quoted for different systems, subsystems & software so as

to cover whole system and it should be possible for the Purchaser to enter into part AMC also

at a later date.

TABLE-IV

LIST OF SPARES TO BE HANDED OVER BY THE VENDOR TO THE PURCHSER

ON EXPIRY OF THREE YEARS AMC PERIOD AS PER AMC TERMS &

CONDITIONS

Figures in USD S.No. Item

Description

Quantity Basic

Unit

Price

Taxes &

Duties

(Out side

Mauritius)

Freight,

Forwarding,

Packaging

Insurance Any

Other

Charges

Basic all

inclusive

Price

{(4)+(5)+(6)

+(7)+(8)}

Discounts Total

Price

{(9)-

(10)}x

(3)

1 2 3 4 5 6 7 8 9 10 11

203

Annexure-I Bid Security Form

RFP No. ………………. Dated ………

Ref No. :…………… Date :…….. To Mahanagar Telephone (Mauritius) Limited 30, Dr Eugene Laurent Str, Port Louis Mauritius. Whereas [Name of Vendor] hereinafter called “The VENDOR” has submitted its Offer dated [date of submission] for the project as per the above RFP in Republic of Mauritius” hereinafter called “The Equipment”. KNOW ALL PEOPLE that we [name of bank] of [name of country] having our registered office at [Address of Bank] hereinafter called “The BANK” are bound unto Mahanagar Telephone (Mauritius) Limited, hereinafter called “The MTML” by the amount of US $ ……….. (mention amount as per RFP) willingly and truly to be paid out to the said MTML upon entering any of the conditions specified below. The BANK, binds itself, its successors and assigns by these presents sealed with the common seal of the said bank this ……………….. day of ………………….. 200 . The conditions of this obligation are: a ) If the VENDOR withdraws its Offer during the period of Offer validity specified by the VENDOR in its offer submitted to MTML; or b) If the VENDOR is selected for the second stage of the bidding process by the MTML, and is notified accordingly during the period of Offer validity if selected for award of contract fails to sign the contract within one month from the date of acknowledgement of Letter of Intent (LoI) and furnish the Performance Security in accordance Clause 28.2 of Section II and Clause 4 of Section III, General Condition of Contract. We, the BANK , undertake to pay to the MTML up to the above mentioned amount upon receipt of its first written demand without the MTML having to substantiate its demand, provided that in its demand the MTML will note the amount claimed by it is due to the occurrence of one or both of the two conditions indicated above, specifying the occurred condition or conditions. This guarantee will remain valid for ….. days from the date of submission and any demand in respect thereof should reach the bank not later than ……. date. Signature of Bank

Seal of Bank

204

Annexure-II Performance Guarantee Form

RFP No. ……………………. Dated …………

Ref No. :…………… Date :…….. To Mahanagar Telephone (Mauritius) Limited 30, Dr Eugene Laurent Str, Port Louis, Mauritius. Whereas [Name of Vendor] hereinafter called “The VENDOR” has agreed for the executing the project as per the above RFP in Republic of Mauritius hereinafter called “The Equipment”. as per the conditions of Letter of Intent (LoI) issued to the VENDOR by Mahanagar Telephone (Mauritius) Limited, hereinafter called “The MTML” AND W HEREAS it has been stipulated by you in the said Letter of Intent that the VENDOR shall furnish you with a bank guarantee by a reputed first class commercial bank located in Mauritius specified therein as security for compliance with the VENDOR’s performance obligations. AND W HEREAS we have agreed to give the appointed VENDOR a guarantee: THEREFORE, we hereby affirm that we are guarantors and responsible to you on behalf of the VENDOR up to a total of US DOLLAR………………… {Amount of the Guarantee in W ords]. W e undertake to pay you, upon your first written demand declaring the VENDOR to be in default of its obligations and without cavil or argument, any sum or sums within the limits of [Amount of Guarantee] as aforesaid, without your needing to provide or to show grounds or reasons for your demand or the sum specified therein. This guarantee is valid until the ………………….. day of ……………………. 200 Signature of Bank Seal of Bank

205

Annexure-III

LETTER OF AUTHORISATION FOR ATTENDING OPENING OF OFFERS (to reach CEO MTML before date/ time of opening of offers)

Sub: Authorization for attending opening offers on _______ against RFP

RFP No. ………………….. Dated …………………..

Following persons are hereby authorized to attend the opening of offers for the RFP mentioned above on behalf of _____________________________________________ (Name of Vendor) in order of preference given below:

1. Name_________________________________

Specimen Signatures_________________________________

2. Name_________________________________

Specimen Signatures_________________________________

Signature of vendor or Officer authorized to sign the offer

on behalf of the Vendor (Attested copy of Attorney must be attached) Note: Maximum of two representatives may be permitted to attend opening of offers. In case where it is restricted to one, first preference will be allowed. Permission for entry to the hall where offers are opened, may be refused in case, authorization as prescribed above is not received.

206

Annexure-IV MANUFACTURERS AUTHORISATION FORM

To The Chief Executive Officer Mahanagar Telephone (Mauritius) Ltd. 30, Dr Eugene Laurent Str, Port Louis Mauritius.

Dear Sir,

RFP No. ……………………………….. Dated …………………… W e _______________________________________ who are established and reputed manufacturers of GSM/ HSPA equipment having factories at ___________ and _____________________ do offer, negotiate and conclude the contract with you against RFP No. …………… Dated ……. for the above goods manufactured by us. No company or firm or individual other than M/s. __________________________ are authorized to offer, negotiate and conclude the contract in regard to this business against this specific RFP. W e hereby extend our full guarantee and warranty as per clause 8 of the General Terms & Conditions (Section-III of RFP) of the contract for the goods offered for supply against this RFP by the above firm. Yours faithfully, (Full Name) for and on behalf of M/s (name of manufacturer) Note: This letter of authority should be on the letter head of manufacturing concern and should be signed by a person competent and having the power of attorney to bind manufacturer

207

Annexure-V

ANNUAL MAINTENANCE CONTRACT (AMC) SCOPE OF CONTRACT 1. Annual Maintenance Contract shall start immediately after expiry of the

warranty period. The comprehensive Annual Maintenance Contract (Herein after called AMC) shall be three years.

2. During the period of AMC the successful vendor ( herein after called contractor)

shall :

i) Diagnose the hardware and software faults ii) Rectify the hardware/ software faults detected iii) Repair / replace the faulty PCB and any other part etc. of the equipment. i) Carry out the periodic preventive maintenance ii) Upkeep, the software periodically iii) Upgrade the software to latest version

3. The vendor shall provide service / maintenance to the purchaser in the

presence of user, at the locations where hardware and software product will be installed. The vendor shall ensure the availability of service to all the subscribers at all the time.

TERMS AND CONDITIONS 1. Any fault affecting quality of service / availability of service of 5% or more of the

links/ subscribers shall be treated as major fault. All major faults shall be rectified within four hours of its reporting to the contractor.

1.1 Any fault affecting quality of service/ availability of less than 5% of the links /

subscribes shall be treated as minor fault. All minor fault shall be rectified within 24 hours of its reporting to the contractor.

2. The contractor if fails to rectify major/ minor faults within stipulated duration

shall be liable to pay penalty for the entire period of breakdown including Saturdays, Sundays and holidays as under.

- Major fault USD 2 per day per subscriber - Minor fault USD 50 per day

3. The vendor shall at the time of submitting the offer submit the proposal

specifying the fault control centre location and how vendor proposes for carrying out repair under AMC. He shall also indicate what spare will be kept in different locations. The spares have to be kept within the space provided and in custody of MTML. The infrastructure planned to be created by the vendor to his obligations under AMC and his action plan to deal with the various situations arising out of hardware and software faults shall be clearly indicated.

208

3.1 The MTML will report the fault on telephone / through FAX / Email etc. to the fault control centre of the contractor.

4. The AMC charges shall be paid by the purchaser to the contractor on half

yearly basis at the beginning of the respective half year and the contractor shall submit performance back guarantee for the amount of AMC at the time of signing of the AMC agreement.

5. The contractor shall maintain spare / stock of printed circuit board, sub

assemblies and accessories for the purpose of rectifying the fault and shall keep an up to date records.

5.1 The entire process of repair/ replacement of defective components have to be

completed within 30 days. In case of delay beyond 21 days the vendor shall be charged penalty at the rate of USD 80 per day for 30 days and beyond that @ USD200 per day.

6. After the expiry of warranty/ annual maintenance contract, it shall be optional

for MTML not to enter the AMC contract further with the contractor. In such circumstances the contractor will be bound to hand over the spare parts / sub assembles / printed circuit boards etc. to MTML. For this reason the vendor shall quote, in the offer the price of these parts / sub assemblies / PCBs to be paid by MTML at that time. For the purpose of evaluation of RFP, sum of these price will be discounted @ 12% per annum to arrive at the present price. However, if additional spare parts are needed the vendor shall supply them at the same rate.

7. The contractor shall prepare the schedule of preventive maintenance for each

quarter and shall submit the same to MTML in advance. The preventive maintenance shall not affect the normal functioning of the system.

8. The contractor shall maintain a consolidated log book at its central location and

also at each site ( to be kept with MTML) wherein the corrective / preventive maintenance undertaken by the contractor shall be entered and same shall be countersigned by the system in-charge.

9. Replacement of any part should be done with the approval of MTML personnel

and a record is to be maintained with the system in charge. 10. FORCE MEJEURE

Neither the MTML nor the system maintenance firm shall be liable to the other for any delay in or failure of performance of their respective obligation under the agreement caused by occurrences beyond the control of MTNL or the system maintenance firm ( as the case may be ) including but not limited to fire ( including failure or reductions), acts of God, acts to the public enemy, war, insurrections, riots, strikes, lockouts, sabotage, any low, status or ordinance, thereof any other local authority, or any compliance therewith or any other causes, contingencies of circumstances similar to the above. Either party shall promptly but not later than twenty days thereafter notify the commencement and cessation of such contingencies and if such contingencies continues

209

beyond three month. Both parties agree upon the equitable solution for termination of these agreement or otherwise decide the course of action to be adapted.

11. The successful vendor shall supply all global software updates issued by the

firm to MTML free of cost as part of the AMC as well the maintenance of these upgrades.

11.1 The fees quoted for maintenance service of software shall be valid for the

software provided at the time of installation and commissioning of the system and subsequent upgrades till the expiry of the AMC.

12. The successful vendor will be solely responsible for the maintenance and repair

of the software/ hardware systems, equipments and parts, thereof and MTML shall not be liable to interact with any of the partners / collaborators or the sub contractors of the contractor.

13. Termination Clause: If the purchaser is not satisfied with the performance of

the vendor during AMC he should be able to terminate the AMC during its currency, after giving three months notice to the vendor and in such an event will hand over all the spares as indicated in clause 6.