1

Request for Proposal

For

Online Charging System, Billing & Customer Care System

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, 63, Cyber City, Ebene

Phone(230)-52943333, FAX(230)-52940606, Email: mtml@mtmltd.et

2

RFP No.: MTML/OCS/B&CCS/RFP/ 2018/1 Dated 24.12.2018

TENDER DOCUMENT

Ref: Global Tender for procurement of Online Charging System, Billing and

Customer Care System 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 18

4. (a) Special Conditions of Contract IV-A 28

4. (b) Detailed Technical Requirements IV-B 38

5. Schedule of Requirements V 96

6. Delivery Schedule VI 98

7. Price Schedule for Equipments VII Table IA, 1B 99

8. Price Schedule for Services VII Table II 99

9. Price Schedule for AMC VII Table III 100

10. List/ price of Spares VII Table IV 100

11. Bid Security Form Annex-I 101

12. Performance Security Guarantee Bond Annex-II 102

13. Letter of Authorisation for attending Bid Opening

Annex-III 103

14. Manufacturer’s Authorization Form Annex-IV 104

15. AMC Terms & Conditions Annex-V 105

16. Existing Network information Annex-VI 108

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

Chief Technical Officer Mahanagar Telephone (Mauritius) Limited,

‘MTML Tower’, 63, Ebene 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 the same day. 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,

SANJAY GARG

CEO, MTML

3

SECTION-1

GLOBAL NOTICE INVITING TENDER

Tender Enquiry No. & Date : MTML/OCS /B&CCS/ RFP/2018/1 Dated 24.12.2018

Sale of tender document starts : 24.12.2018 Last date for seeking clarifications : Up to 17:00 Hrs on 18.01.2019

Last date for issuing clarifications : 19.01.2019

Last Date of Bid Submission : Up to 15:00 Hrs on 31.01.2019

Date of Bid opening : At 15:30 Hrs on 31.01.2019

-- All timings given above are Mauritius Local time.

1. MTML calls for global open tender for Online Charging System, Billing & Customer Care System for its CDMA/GSM/ 3G/ LTEnetwork in Mauritius as per detailed requirements mentioned in the RFP document.

2. ELIGIBILITY REQUIREMENT FOR VENDORS:

Please see Clause 3 of section II of RFP. 3. SCOPE:

(i) The two stage tender calls for supply, installation & commissioning of Online Charging System, Billing & Customer Care System for its CDMA/GSM/ 3G/ LTE network in MTML Mauritius on turnkey basis.

(ii) The scope of the tender includes planning, engineering, supply, Installation, integration with existing core network & VAS platforms, testing and commissioning and migration of data from current OCS, Billing System, CRM,Voucher Management, Interconnect & Roaming provided by ZTE Corp. to the new system.

(iii) The OCS of 500K capacity (including both post paid and prepaid) for Online Charging of Voice, SMS and DATA needs to be deployed including Billing system of 100K is required. The system must be scaleable to 700K using modules, hardware and software in later stages when MTML requires the capacity expansion.

(iV) The Voucher Management System of 30 Million Card Capacity will also need to be supplied as a part of the system. The VoMS must be scaleable to 50 Million if MTML desires to go for expansion in future.

(V) The optional items like PCRF, SPR, SMSC, MCA (Missed Call Alert), e-Top UP/ e-PIN / e-Voucher, AAS (Airtime AdvanceSystem), Mobile Money,USSD Interactive Service, allfor 500K can be quoted separately. It will be MTML’s exclusive right to opt for these or not. And in any case, the integration of new system with these existing items will be required.

4

For details regarding equipment, technical requirements & special conditions/requirements please refer to RFP.

Bid security in the form of bank guarantee will be USD 10,000 (Ten Thousand Dollors only).

Intending Bidders may download the RFP document from MTML Web site www.chili.mu/services or collect the same from CFO MTML, Ebene, Mauritius on all working days till the last date of submission of bid mentioned above, on payment of MUR 3500 or USD 100. Outstaion bidders may transfer USD 100 in the following account and submit proof of payment alongwith the bid document: Beneficiary Name: Mahanagar Telephone (Mauritius) Ltd. Bank Name: Bank of Baroda, Port Louis A/C No.: 94560190000605 Swift Code: BARBMUMUOBU

Sd /- CEO MTML

5

SECTION - II

INSTRUCTIONS TO BIDDERS

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

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

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.

6

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

o) “Works” 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 registered Company, duly authorised by theoriginal 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), authorisation by the manufacturer to submit the offer against this RFP and MOU shall form part of the Offer.

II Billing System experience.

The bidder or their parent company or the OEM must posses experience in supply, installation and commissioning of OCS based billing system handling at least a total of 1 million lines of telecom network with atleast2Mobile service providers in not less than 2 countries.

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 the complete system being provided by it to support for operation and maintenance for atleast next 7 years, including availability of hardware spares and software upgrades.

V The bidder should have a minimum turnover of USD 5 million each in the last two Years.The turnover of the parent company in case of a local subsidiary would be taken intoconsideration.

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.

7

5. RFP Documents 5.1 The goods and services required, RFP procedure and contract terms are prescribed in the RFP Document. The RFP document includes 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 VII Table IA, 1B

8. Price Schedule for Services VII Table II

9. Price Schedule for AMC VII Table III

10. List/ price of Spares VII 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 or through the email 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, 63, Ebene, Mauritius.Fax No. (230) -52940606 and email id: cto@mtmltd.net

8

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.

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.chili.mu/services.

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

9

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.

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

10

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.

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 $ 10,000(US Dollar TenThousand 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 bid 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

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

12

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.

15.2 The envelopes shall

(a) be addressed and sent at the following address: Chief Executive Officer Mahanagar Telephone (Mauritius) Ltd., MTML Tower, 63, Ebene Mauritius

(b) bear Name of works “Billing & Customer Care Infrastructure for

deployment in MTML 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.

13

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

14

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 the following criteria:

The Net Present Value (NPV) of CIF prices of all the equipment & software quoted by the Vendor will be taken after deducting any discount which has been indicated by the Vendor in their price quotes. This will be added to the Net Present value (NPV) of total AMC and spares cost for arriving at the total quoted value of the bidder. Cost of AMC for a period of seven 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 sevenyear AMC period shall be discounted @12% per annum. 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.

15

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

16

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

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.

17

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

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

18

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

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. Where the Purchaser decides to conduct such tests on the premises of the

19

Contractor or its sub-contractor(s), all reasonable facilities and assistance like Testing Instruments and other test gadgets including access 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. 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.

20

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-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.1.1 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 15 man weeks to personnel

(Technical and Finance) of the Purchaser, free of cost at the Contractor’s training centre. 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 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 20 man-weeks of on job training to personnel

of the Purchaser in Operation &Maintenance of various systems & sub systems.

7.4 The Contractor shall provide all training materials and documents and training aids free of cost.

21

8. Warranty

8.1 The warrant shall be for one year after the taking over of equipments. 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. Warranty 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.

22

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:

(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/ Hardware Supplies

a) 70% 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) 30% 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.

10.2 For Software and Services

a) 80% payment will be by wire transfer after successful installation, Acceptance testing and commissioning of the system and issuance of “Taking Over Certificate (TOC)”.

b) 10% payment will be by wire transfer after three months of TOC. c) Balance 10% 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.

10.4 The supplier may ask for advance payment not exceeding 25% of equipment

23

cost against the additional Bank Guarentee of equivalent amount submitted by supplier.The same will deducted from the first payment to be made towards the supplier invoices of equipment part.

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

24

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 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 equipments and Installation/ Commissioning

stipulated in the 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 Equipments:

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.

(c)Migration of data bases and integration with existing systems:

The vendor will be solely responsible for migrating the existing databases from the current systms and integrating with all other network elements wherever required, through coordination with existing equipment suppliers/ database administrators. The migration of all the databases need to be completed within

25

the delivery schedule mentioned in RFP. The purchaser will provide whatever information 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.

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

26

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

27

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 is: Chief Executive Officer Mahanagar Telephone (Mauritius) Ltd MTML Tower, 63, Ebene, Mauritius. Fax: (230)-52940606

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

28

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 complied 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 number and FAX number. This cover should be superscribed as "BID SECURITY FOR TENDER NO. MTML/OCS/B&CCS/RFP/2018/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 core network and VASes, Firewall 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 documents.

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

29

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.

(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 purchaser shall provide the space, commercial AC mains power/ DC

Power and air conditioning at existing MTML premise in Ebene. The bidders shall indicate the space and power required for each equipment The bidder shall arrange for extension of DC power supply, AC power supply, earthing etc from the existing available points at MTML site to the equipments.

11. The bidder has to ensure that all functions, features currently available in the existing

OCS, Billing & Customer Care System which is being replaced by the bidder’s system continue to work seamlessly. The Voucher Management, Interconnect billing and roaming online charging and billing shall also be provided.

12. The system proposed should support both Prepaid and Postpaid subscribers. The proposal should be sent with an executive summary that shall briefly

outlines the key elements of Vendor’s response, highlighting any major

features, functions, or areas of support that differentiate Vendor’s solution in

order for operator to win the competition in the market, as well as the major

reasons why operator has to choose the Vendor. It should include at least

following:

• Vendor understanding of requirements • Vendor experiences in meeting the requirements • High Level overview of the solutions and which elements are included as options. • Key business benefits

• Key project milestone and related deliverables • Vendor commitment to local support, regional support and HQ

30

support. • Key references in the region and globally

13. The successful bidder shall be required to connect the system with the existing

core network equipments namely HSS, HLR, PGw, SGw, SGSN, GGSN, IN, SMSC, CG for CS & PS, etc as per 3GGP standard interfaces as well as to existing CRBT, e-Top UP /e-PIN /e-Voucher, AAS (Airtime Advance System), MCA (Missed Call Alert), IVR, Banks, Payment Gateway and Call Centre system provided by 3rd parties and also with various banks or financial institutions for online payments or recharge.

14. The bidder shall quote any new/enhanced services/features which may be

required for competitive advantage of MTML for inclusion at the discretion of MTML as an optional item. The PCRF, SPR, SMSC, USSD / USSD like platform, AAS, e-Top UP/ e-PIN/ e-Voucher, Mobile Money can be quoted separately as optional items.The solution proposed must be able to meet the capacity and service requirements ensuring redundancy in terms of network topology, hardware, cards, servers, disk arrays and all related elements.

15. The bidder shall furnish the details about make, model no., supplier and the cost of each item separately.The bidder shall quote for only one make, model and manufacturer for each of the network elements. 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.

16. All third party equipment should be of proven technology and supported by documents for its successful operation of similar or higher configuration for minimum three years in any other network.

17. The bidder shall ensure redundancy in terms of network topology, servers, disk arrays, backups, links, interfaces, cards and all the network elements quoted.

18. The bidder shall ensure that the bid is complete and comprehensive as regards to detailed hardware, softwares, license, module level BoM. The bidders shall provide

unpriced Bill of Materials (BoM) for each of the system elements of each Module/unit together with their Quantity required to meet the performance requirement sought for in the tender in the Techno- Commercial bid.

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

20. All software licenses including OS, DB, Oracle, Applications, and all softwares shall be in the name of MTML allowing for multi users and for unlimited period.

21. SOFTWARE

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

31

(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 elements shall be supplied in media 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 implemented free of cost within another one month for 7 years by the successful bidder.

(v) Software Support Centre:- Successful bidder shall have or will establish Software Support Centre within Six months of award of contract to ensure smooth functioning of equipment supplied and to meet additional requirements from time to time free of charge. The bidders shall submit details of location, number of personnel, facility to be made available for Software Support Centre in the bid.

22. ACCEPTANCE TESTING

(i) Purchaser reserves the right to appoint any testing authority for carrying out acceptance testing of the OCS, Billing and Customer Care system (incudling all modules and features) and its network elements. The acceptance test schedule generally covers the following:

(a) Check on hardware installation, cabling and wiring.

(b) Functional test for various network elements.

(c) Functional test on individual equipment/network.

(d) Capacity tests

(e) Backup and restoration, Emergency tests

(e) Service tests & pre & post migration tests for all services.

(f) Other tests as decided by purchaser

(ii) The successful bidder shall submit a comprehensive and complete test schedule together with test set-up and procedure for conducting Acceptance Testing on each of the network elements to be supplied under this project. The successful bidder, after incorporating modifications and / or additions as per MTML requirements, if any, shall finalize Acceptance Test schedule at least one month 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

32

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.

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

24. Operation and Maintenance:

24.1 The successful bidder shall carry out all the functions of operation and maintenance during the first 3 months of commercial launch. 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 maintenance procedures, backups, periodic test schedules, Report generation & analysis and remedial measures to be taken if required, Extraction of performance statistics, Statistics regarding customers in various formats and classification as required by the purchaser, Management 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, backup, test schedule and performance and fault recording.

24.2 All the system elements and software units supplied shall be fully downward compatible with the existing system and inter work seamlessly without any limitation.

24.3 The supplier shall create a test bed inorder to test new services, packages, price plans, scripts etc before moving the to production environment.

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

25. Annual Maintenance Contract-

a) The bidders shall quote for a year wise comprehensive Annual Maintenance contract for 7 years. MTML will have the discretion whether to sign the AMC contract or not for each year separately. The AMC for 1st 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.

33

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 at MTML location. The infrastructure planned to be created by the bidder to meet 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.

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

27. The OCS, Billing and Customer Care: must support 500K capacity and all the exisiting modules, features, functions available on ZTE system to ensure smooth migration of services. Basic functions needed are: Online Charging (of Voice, SMS, Data) for both post paid and prepaid customers, Billing for postpaid customers (email and printable format), Customer Relationship Management (CRM), Product Management, Inventory Management, Dealer Management and POS App, Self Care Portal using Mobile App & web, Provisioning, Mediation, Interconnect Billing, Roaming for both prepaid and postpaid and roaming billing, Accounting and Ledger, Finance/ Revenue module, Voucher Management, Reports module, CSR, SPR etc.

28. Voucher Management System: of 30 Million card capacity scaleable to 50 Million if MTML desires for expansion in future. The expired cards license will be released automatically and should be configurable. There should be no limitations on the card states for the capacity mentioned. The interface connecting the VC to OCS and other elements including USSD, IN, IVR etc will be vendor’s responsibility.The encryption and decryption tool for PINs should have latest versions available and follow the 3GPP standards. Also bidder needs to migrate the vouchers from existing ZTE Voucher Centre to the new system.

29. Network Intergration and Protocol compliance: as per 3GPPspecifications for OCS series, SMPP 3.3 and 3.4 , IETF, ITU-T TCAP, RFC 4006 DCCA specifications for diameter charging, GSMA specifications for roaming. Estabilsh connectivity with all the existing network elements for Online charging of CDMA/GSM/3G/LTE/IMS services, CDR collection and

34

processing, Provisioning of services, Roaming Data Clearing house, Banks, 3rd party systems etc.

All the standard interfaces, adapters, processes shall be supported to achieve the connectivy and provisioning and functional flows for the services. All standard interfaces and adapter for sFTP, web service (for CRM), MML (for IVR), VC, UCIP, USSD, SMPP, MM7, SMTP, JMS and any other needed to intergrate with existing core and VAS systems of MTML for all exsting and as well as enhanced features.

30. Fraud Management: The bidder shall supply a suitable fraud control & management as part of the billing system. Broad outline of the requirement for detection and monitoring shall be as follows:

Roaming Frauds-National/International

Call volume/duration frauds

Detection over packet services

Subscription frauds

Abnormal behaviour

The system shall ensure apart from detection and monitoring of above 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.

31. Interconnect Billing: The system shall ensure collection, processing and rating of CDRs for IUC purpose and generate invoices for interconnect partners or POIs. Rating and billing for interconnections (Voice/ SMS(a2p & p2p) / SIP or VoIP), Reconciliations of records in case of disputes, Corrections, and reports can be generated. Rates for both outbound and incoming traffic can be configured as per partner agreements and will also support triggering to the routing mechanism on gateways. A rate tool will be deployed for control mechanism based on different rates, time, volume etc for routing the calls, SMS etc to different partners. The GUI should be available to view and export the CDR details. IUC invoice generation will be required for the interconnect partners. Revenue and Trafffic Reports Daily, Weekly, Monthly, Quaterly and Yearly to be generated as per MTMLs requirement.

32. International Roaming: The system so provided must be capable of handling international roaming service for Voice, SMS and data. The billing system provided should take care of Roaming billing for in-roamers and Out-roamers. Both Prepaid and Post paid roaming should be available and supported for CDMA, GSM, UMTS, LTE and IMS. All the GSMA standards will be ensured during TAP generation, TAP/RAP processing from roaming partners/ DCH, retail billing, NRTRDE, Clearing House file transfer flows, TAP corrections, RAP file processing, Missing Sequence processing, IOT implementation as per agreement with partners, Invoicing, Revenue and Trafffic Reports Dialy, Weekly Monthly, Quaterly and Yearly to be generated as per MTMLs requirement.

33. Billing: Sytem must be able to generate hot bills, detailed bills, invoices for

customers and interconnect partners.The billing system should be able to send subscriber bills by e-Mail if the customer he has opted for bills via email. Also

35

the bills should be in printable formats as per MTMLs requirement. The customization of bills and fields as per MTMLs requirement should be possible. Also will need to include information for customers,adverts, alerts, promotions etc. For corporates customers care needs to be taken to generate a single bill for all numbers in an account. Detailed billing records can be optionally generated for each number on demand and option should be available to generate detailed bill for customers. Separate charge can be configured for detailed billing records if customers opts for this. All bills and invoices to be generated will be in printable format and need to be made available on web, Mobile app., GUI etc. The bills will also need to be sent through email to customers or partners both. Barcode printing on bills, scanning and payment receipt will need to be supported.

34. e-Top UP/ e-PIN / e-Voucher system: The system can be provided either as part of Voucher Management or a separate system. It should be possible to manage distributor/ retailor network for recharge PIN transfers securely for crediting the customers account through USSD/USSD like/SMS/IVR. 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. The intergration with OCS, VCC, ACC will be ensured to enable single voucher for all services.

35. Airtime Advance Service: The system can be provided either as part of Online Charging System or a separate system. The system should be able to provide small credit to prepaid customers, configurable based on usage and recharge patterns. And should deduct the advance taken when they recharge later, alongwith the applicable service charges. Should be able to generate reports concerning these transactions.

36. USSD system and USSD Interactive Menu: The USSD system should support both the USSD string or short code usage and the Menu driven usage. Must support both USSD for GSM and USSD like for CDMA.The interactive menu must be configurable as per MTML requirement and options can be enabled or disabled in menu. The system should support all types of balance queries, packages, transfers, MSISDN query, ordering of services and packages, integration with banks for payments, recharge etc. Redundancy need to be ensured in terms on servers, network topology and other elements.

37. Balance Transfer Service: The system should provide the facility to

customers to transfer part of their available balance to some other customers. Minimum and Maximum limits should be configuratble as per customer categories.USSD, USSD like, SMS, App and IVR must be supported for balance query, transfer, recharge, family number (provision/ deprovision), querying the MSISDN.

38. VCC (Virtual Card Calling)service: for International calls 1. VCC prepaid service using Carrier Access Code 061 and 2. VCC post paid service Using Carrier Access Code 060 shall be provided. Both the VCC Post paid and Prepaid will be handled by OCS and Billing respectively. The same vouchers need to be used for VCC prepaid, VCC postpaid, Mobile customers on OCS

36

or Billing. The vouchers can also be used by postpaid to increase their credit or bill pay.

39. Notifications and subscriptions based on SMS, USSD, USSD like, SMS

Alerts: Notifications to affected customers to be provided for provisioning of various services on OCS, Billing and CRM. System should be capable of sending balance thresholds alerts in realtime, alerts for service provisioing and orders based on SMS and USSD should be configurable.

40. e-KYC: feature will be provided for registering the customers. The Mobile app

and web can be used to upload the docs, photos, profile data etc to facilitate the registration and verification of the customers and trigger activation of sims.The biometric system of registration and verification will also be supported. The data privacy laws of the land will need to adhered.

41. Enterprise Business Customer (EBS): to implement the business flow,

related products and services, price plans, work order, provision, compliance, handover, Invoicing for data, voice links, products, services, pakages, revenue and traffic and usage reports. Accounting for EBS customers, charging, billing, rentals, recurring charges, differential charging for products and services, complain handling, feedback mechanism, etc is required.

42. Account Receivables: receipts of payment through cash, Credit card, Debit

card, Net banking, ECS, cheque and any other e-transaction methods should be supported. Should integrate with the payment gateways banks or financial institutions. System must be capable to generating reports related to finance, audit, sales and revenue as per MTML requirement.

43. Redundancy, Backup and Emergency Flow: The system should have separate active and standby servers for various functions in order to ensure the overall redundancy of the system. The redundancy should be at hardware level including the Disk Arrays, serves, power modules, network topology, cards, interfaces, switches, router, firewall, connectivity etc and software level including the OS, DBs, VMs, Memory, Applications etc. The auto synchronization should be realtime to the standby servers. In case of failure of one the other server should take the entire traffic and load without disruption of services.The shifting of services between nodes should be realtime and without disruption being noticed at services levels. Resource allocation on demand. Backups must be automatic and realtime. The cold, export, archives, logs, traces etc must be available for restoring the system in no time. Incase MTML decides to go for DR site in future this should a be supported along with backup to remote location on cloud. Each system that holds data to backup, must have available and exclusively dedicated backup communication port or adapter for access to the backup LAN and/or backup SAN to be able for integration in LAN an or SAN based backup architecture. Emergency flow: can be opened automatically in case both the OCS servers fail, this will by pass the Onlinecharging mechanism and on restoration, the reconciliation should be initiated automatically for balance adjustments for the over run Calls, SMS, DATA usages. Spooling CDRs from NEs, rating and billing will need to be syncronised for the emergency period and accommodate all records and transactions accountable.

37

44. Flexible DCC Dispatch & Overload Control: Requests can be dispatched

based on service type, Execute Load sharing for each charging process, Concurrent DCC will be sent to same queue, OLC, TPS, OCDis, OCPro for Control mechanism. The solution's proposed must be redundant with HA.

45. Network Management Sytem & Performance Monitoring: The NMS and PM feature should be available for all the elements of OCS, VC, Billing, CRM, Interconnect and Roaming. The NMS must display realtime alarms on the systems for servers, CPUs, DAs, Memory DB, table spaces, links on network topology, connectivity, backup status, etc Must display realtime CPU, Cache, Memory and Disk space usage, bandwidth consumption on the Ethernet ports etc.Logs and Tracing relatime on OCS, billing, CRM, roaming and for all the elements of system should be possible. Alerts and alarm sending by SMS for performance and faults.

46. Self Care and Universal Contact: Self care portal must be available to

customer on web and Mobile App. for ordering of services, recharging, credit transfer, viewing and paying outstanding dues, service requests, complains. Universal contact with customer using SMS, Social Media like FB, WhatsAPP, We Chat etc should be possible. Integration with a Customer Experience Platform for communication via Social Media. Vendor should provide a mobile application for Customer Self Care which runs on iOS and Android Platform with features supported on the self care portal.

47. Mobile Money: Mobile Money to support, store and manage money in an

account linked to a mobile phone, similar to a bank account. Gateway to digital / cash less pay via unified payment Solution. Handle large traffic increase with simple node addition with zero system downtime. Multiple wallet profile with subscriber transfer. Business rules for subscriber categories. Self-care via web, mobile app, USSD. Store a record of every transaction and account balance, so even if the phone or SIM card is lost or stolen, the user’s money is kept safe. Additionally, every transaction requires identification in the form of a secret PIN / OTP. Reports for finance and audit.

48. Shorten TTM –BPM –based Order Workflow: BPMN 2.0 Compliance or

higher, Drag and Drop BPM Designer, Orchestrate all GUIs, services andbusiness rules, Workflow Import & Export, OOTB Preconfigured TM Compliance Business Process. TM Forum Frameworks compliance TAM, SID, eTOM etc.

49. Other Services: The vendor should ensure that all those services which are available presently on ZTE system should be made available in new system and services to be migrated without interruption. The new system should also provide additonal enhanced features and support for services like IoT billing, M2M billing, WiFi etc.

50. Compliance to Data privacy: The Data Protection Act 2017 of Mauritius and its ammendments regarding the General Data Protection, National Security,

Consumer Protection shall be complied from time to time. System should be PCU-DSS, GDPR compliant

38

SECTION –IV (B)

DETAILED TECHNICAL REQUIREMENTS

1. INTRODUCTION

Mahanagar Telephone (Mauritius) Limited (MTML) is presently operating on CDMA/ GSM/ UMTS/ LTE Technologes. The core network, billing, IN and VAS has been supplied by M/s ZTE Corp and BSS /Radio network is from M/s Huawei Technologies. MTML has decided to replace its current OCS, Billing & Customer Care System along with the Interconnect and Roaming to a new system having following features:

2. Online Charging System, Billing, CRM and Voucher Managemet: 2.1.1 MTML presently has ZTE make IN & OCS dimensioned for 500K handling

CDMA, GSM, UMTS, LTE subscribers. The OCS should be dimensioned with to serve 500K subsricbers for VOICE, SMS, DATA, the subscribers of 100K billing are also included. All prepaid and postpaid need to be charged Online. The system should be scalable to 700K, in case MTML desire to go for expansion in furture. The responsibility of migrating the data of old system to new lies with the successful bidder. While migrating/ integrating it is to be ensured that all the services currently running are not affected and customers don’t see any outage. 2.1.2 The OCS equipment shall be dimensioned accordingly with one Voucher Management System (VOMS) of 30Million card capacity and should be scaleable to 50Million. There should be not any limitations to the card states for the capacity mentioned. The issuance, extension of expiry, activation, deactivation, blocking, unblocking should can be done by individual or batch process.

3. Design Aspects: 3.1.1 Traffic Profile for both Prepaid and Post paid subscribers is based on CAMEL

for Voice. Online Charging System is required for VOICE,SMS & DATA for 500K capacity including 100K for Billing the postpaid customers.

3.1.2 The OCS, Billing and CRM all must have capacity of 500K, which can be

enhanced to 700K in future if MTML desires to go for expansion. This expansion may be achieved by adding additional hardware, modules, software licenses etc.without interruption of services.

3.1.3 Common OCS and Billing for CDMA, GSM, UMTS, LTE and IMS. 3.1.4 The OCS, SCP, IN, SPR solution proposed by the bidder should be of 500K

scaleable to at least 700K subscribers in later stages if MTML needs expansion.

3.1.5 The dimensioning for the OCS, B&CCS, Interconnnect, Roaming and Voucher

39

Manaagent should be sufficient to cater the number of customers and services for capacity mentioned.

3.1.6 Voice, SMS and data services including pre-paid and post-paid roaming

between IN platforms supplied by different vendors should be supported.

3.2 The SCP, OCS shall be able to cater multiple MSCs, GMSCs, SGSNs, GGSNs, SGw, PGw, HLR, HSS, SSP, IN, VC, USSD, MCA, e-Top up, AAS, CRBT, Mobile Money etc from different vendors without any limitations and must support Prepaid and Postpaid charging.

3.3 Online charging for Voice, SMS and Data service should be supported and

should also provide other charging function such as charging by volume,charging by content, charging by application, URL, etc.Support configuring convergent multi-play products e.g. bundling multiple services (Data / voice /SMS) into one product.

3.4 The Voucher Management System should be common for PPS and PPC (Prepaid customers for GSM and CDMA), VCC (Virtual Card Calling), ACC

(Account Card Calling). The total capacity of 30 million vouchers should support all vouchers in active/ idle state should be supported. There should not be any limitation to the states of cards till its full capacity and for total vouchers/ PINs used. The used vouchers should get deleted and capacity created for new vouchers and configurable. All transactions will generate logs, reports etc. Must support 3GPP standards, encryption, decryptions with algorithm / version for key generation as per latest industry standards.

3.5 Voucherless recharge feature (e-PIN/ e-TOP UP/ e-Voucher) based on

ATM, SMS, USSD, IVR, Web, Mobile app etc. should be provided including hardware and software.

3.6 Must support VCC (Virtual Card Calling) prepaid service and post paid service

for International calls using Carrier Access Code 060 and 061 respectively for other operator customers willing to use MTML ILD services. Also should be able to generate bills for the Post paid customers.

3.7 All features/ services available in current SCP, SMP, SCU, SDP and should be provided in the new OCS also.

3.8 Unified Customer Contact: using Voice, SMS, Chat, Video, Social Media like

FB, Whats App etc. System may support to link customer’s profile in CRM with their profile on Social media (Facebook, Twitter, LinkedIn).

3.9 Unified Customer View: across Call Center, CRM, POS, Dealer, Self Care via Web and Mobile App., IVR and USSD self care. Social CRM System may support to link customer’s profile in CRM with their profile on Social media (Facebook, Twitter, LinkedIn) giving a 360 view.

3.10 Provisioning of services to various elements on Core network (HLRe / HLR / HSS /AAA / SPR/PCRF/PGw/GGSN), IN and VAS (CRBT, MCA, AAS, USSD, USSD like, VC, IVR, e-TOP UP/e-PIN/e-Voucher, Mobile Money, SMSC, IN)

3.11 Interconnect and roaming module to support partners as per exisitng system and future relation growth. Should support the IOT or tarriffs for each and also

40

formats specified by GSMA.

3.12 Description, function / diagrams showing the proposed solution architecture and the logical mapping between proposed architecture and the Operator's existing architecture.

Hardware and software architecture, Data model, Business process, functionality of each need to be submitted along with system dimensioning.

3.13 The vendor should make sure the proposed system can be upgrade to new

version smoothly in the future without any migration.

3.14 MNP (Mobile Number Portability): the implementations and integration support

with other elements will be required as CDMA and GSM numbers are portable

within MTML network. Also in case of Inter-operator MNP, the support to

implement MNP, realize connectivity, business flow for port in and port out

synchronization requirements with NPDB to Local DB, request,

processing,acceptance, provisiong of port in and port out, issuance of

notification using SMS, email, social media etc will be need. The functional

aspects and flow of MNP will be as per the regulatory requirements arising in

future.

3.15 Vendor must describe and explain their product roadmap for the next 5years.

3.16 The links, interfaces should be suitably dimensioned to take care of signaling

load as per tender requirements. And TPS capacity must support 100% customers having BHCA of 1.5, BHSM of 1Million, 100% Data users with active PDP for Online Charging and all the CPU transactions needed to handle this along with the database queries and other transactions. TPS should be sufficient to handle the capacity & services mentioned (including the IMS).

3.17 New OCS or IN platform should be configured as separate SDP, SCPs , OCS,

etc for ease of expansion. All the new IN platforms, OCS, SCP and SSPs shall

support all CAMEL versions & Diameter protocol, M2PA, M3UA. Online charging of all services including VOICE, SMS and DATA should be available from date of commissioning of network.

3.18 The Voucher Management System (VoMS) may be integrated with OCS / IN

or may be on a separate redundant servers with capability to interface with TCP/IP and SS7. It shall provide facility for topping-up of the pre-paid account And VCC, ACC services. The bidder shall ensure that the IN system interfaces with Credit card clearing house, ECS, ATMs, Bank Servers etc with whom MTML has an agreement for payment realization and update the customer account in VoMS/IN with appropriate credit. All such transactions shall be implemented with secure signatures from the SIM and signature validation by the OTP and Mobile Apps.

3.19 The pre-paid / post paid service shall be based on OCS and Online Charging

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

41

any combination of unprohibited teleservices and supplementary services, roaming, SMS, GPRS, EDGE, HSDPA/ HSPA, LTE, IMS etc to the pre-paid and post 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. Credit control will be in place for post paid customers from day one. 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. It should support prepaid and post paid 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.

3.20 Accounting of all OCS & IN services shall be possible to send the Consolidated

Accounting information (CDR) to B&CCS for the purpose of reconciliation and compilation of accounts.

3.21 The VoM system shall provide all necessary data required for scratch cards.

The scratch card data shall be protected against all type of frauds. Latest encryption/ decryption software shall be provided by the bidders.

3.22 Full flexibility of change in recharge voucher value and validity from front end

any time after loading on the VoM platform should be available. 3.23 The OCS, VoM, should be capable of providing traces in SCP as well as Signaling side for troubleshooting and monitoring. 3.24 Solution should have a separate product catalog that contains all pricing

information enabling Product Marketing Managers to define and map new product offerings. The product catalog should contain tools that allow rapid configuration of new products and service bundles across all supported lines of business including pricing, complex promotions and discounts.

3.25 Should be able to manage status (life cycle of subscriber) of individual account

of subscriber like Finalize/close account, block an active account, renew expired account, one way , two way blocking etc. And also for the accounts with multiple numbers e.g corporate accounts with status for each.

3.26 The OCS must support these requirements and functions below which are

necessary:

i. Rating (before and/or after service consumption):

unit determination: calculation and reservation of a number of session-related non-monetary units (service units, data volume, time and events);

price determination: calculation of monetary units (price) for a given number of non-monetary units;

42

tariff determination: determination of tariff information based on the subscribers contractual terms and service being requested (e.g. information for AoC);

get/set counters applicable for rating (alternatively these counters can be here or in the subscriber account balance management).

Rating and charging to the precision of at least 3 decimal place for local and TAPs or roaming files with 5-decimal palces as per GSMA should be supported.

ii. Subscriber account balance management:

check account balance;

account balance update (credit/debit);

account balance reservation;

get/set counters;

get/set expiry date of the (prepaid) account.

iii. Charging transaction control:

perform charging control on request basis for bearer and events/services;

immediate charging and charging with reservation;

generation of charging information/CDR per charging transaction.

iv. Advice of charge support:

receive tariff information from external system;

provide Advice of Charge information (tariff and/or cost).

v. To support the correlation requirements, the functions listed below are possible in the OCS:

context handling of bearer, service and IMS charging events related to a given subscriber;

generation of a combined multiple event and session requests to the rating function.

System should support Session based charging to support charging of various session-based services like Data, VoIP, Voice.

System should support flexible charging and rating methods like: Flat Rate, Usage Based Rates, Time Based Rates, Event based, Content Rates, Destination Based Rates.

System should support in-built data charging use-case library by default with easy drag & drop functionality to configure packages for eg. Turbo Boost, FUP, Happy Hour, unlimited etc along with the existing SPR / PCRF packages.

43

Solution should be able to be deliver in deferent schemas, Cloud, hosted, as well as full in-house delivery at customer premises.

The campaign manager shall have option of provisioning bonus, advertisement or a package to subscriber There should be multiple options like ARPU, Churn, Acquisitions to select the target customers for a campaign.

3.27 Billing: The billing system must support following features:

Transparent & Easy Operation.

Multiple billing cycles.

Bill generation: billing cycles, different due dates, accounting.

Bill generation and its stages, process viewing should be GUI based.

Bill access and query using web or Mobile App.

Notificaitons and alerts for bills, outstanding dues, credit limits, dunning actions using SMS and other social media like FB, Whats App.

Debit control and Dunning

Trigger Actions, alerts and notifications for one-way blocking, two-way blocking and suspension etc.

Mechanism for recovery of unpaid or partial paid dues and process cycles.

Mediation and Rating process to be displayed transparently for monitoring the KPIs.

CDR collection, processing and rating.

Solution should support multi-level account hierarchies, parent/child relationships, system defined customer types, multiple addresses, demographics.

Ability to attach and remove products, services and equipment, and all other information necessary to properly bill and collect money from customers.

Support adjustments before and after bill generation.

Account receivables using different channels cash, credit card, debit card, net banking and other e-payment facilities, ECS, post-office payment files, bank files etc.

Receipt generation for all the payments received as per MTML formats.

Bills must in printable format, as well as soft copy can be viewed using apps, web etc.

Bill format will be as per MTML requirement supporting additional notifications, promotions, alerts & adverts if any.

Single bill for corporate customers with different products and many numbers in same or different account.

Detailed billing option, and chargable as per MTML requirement.

Track of dues and payment history atleast for 24 months.

Reports for billing relatd actions: total bill generation, one-way, two-way, active, dues pending, credit limit reached, loyalty score, etc.

Hot billing.

The Late Fees , surcharge should be generated for post paid customers based on the due date.

The payment realization dates received in the payment files from banks and other financial institutions should be taken into account for late fee reversions.

44

Price plans and packages of existing Billing system, SPR and PCRF as well as enhanced features related to these.

Performance & KPI monitoring of system.

3.28 The proposed OCS and Billing solution shall support following broad features:

Prepaid & Post service (PPS) Voice, SMS & 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 (VCC Prepaid)

International postpaid dialing for other network numbers (VCC Postpaid)

Account calling card (ACC)– any customer (of any operator) can use this to create his prepaid account for International calls.

e-PIN/ e-TOP UP / e-voucher

AAS (Airtime Advance System)

Tele-voting services

Enterprise Business Customers

SIM card bundling, loading sim inventory, distribution, provisioning and activation / deactivation

Single or Batch loading, activation, deactivation, modifications of services using web / GUI.

Data Charging must support all the AVP as per 3GPP

Reports for audit, revenue, traffic, ICTA etc

Should be able to create roles for restricting access to sensitive customer data.

Bundled packages with multiple services (voice, sms, data), Data packages for post paid and prepaid customers.

Price plans for prepaid and post paid customers.

Multiple packages for prepaid and post paid customers and prioritization.

Data topup packages which can be used only when the main package is finished or has been limited by QoS on PCRF.

Recurring benfits for services to be given for prepaid and postpaid customers.

Recurring fees to be charged for prepaid and postpaid customers.

Family numbers to which calls are charged at discounted rates.

All exisiting price plans, packages, features for prepaid and post services to be supported.

Transfer of funds from a postpaid to prepaid subscriber's total spend and be subject to the limitations enforced by the credit limit.

A. PPS (Pre-Paid Service) – Basic Features:

- Password Modification - Multi Language support - Black list

45

- Claim of missing/missing claim dismiss - Balance Inquiry - Recharging - Balance Transfer - Low balance alarm - Voice prompt - Real- time charging - Real time charging for SMS/Content/Data/Voice - Account recharge - Charging notification - Help desk Calling - Call barred - Call forwarding - Electronic recharging through net banking, ATM, Banks, cards etc. - Life Cycle Management and transition through various stages. - Life Cycle for Prepaid -should include automatic deletion of suspended,

deactived and unused numbers. The same should be configurable as per regularoty requirement.

- AOC through channels – SMS, USSD, App, IVR, email, announcement etc as per service requirement.

B. PPS (Pre-Paid Service) – Advanced Features:

- USSD and USSD like for recharge/balance query/transfer/MSISDN query, service or package order or cancel etc.

- SMS recharge/query/transfer - MSISDN query and Family number management using USSD - Activation or deactivation of packs and services using USSD - DTMF/IVR 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/ DATA etc. - Friend & Family number - Pre- paid home zone - Charging for Pre- paid CRBT, MCA, VMS, SMS, Voice and Data

service - Multiple bonus offering - Flexible status definition and life cycle management - 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 DATA/SMS/

validity extension/Special pack etc. - The OCS should support Multiple Dedicated packages per account,

Accumulator, Usage Counter, and Usage threshold for same account. - The system shall support Roll over of a balance to next monthly cycle /

bill cycle. The amount of roll over should be configurable. - The OCS Should support White- listing and black- listing of numbers.

46

- Black listing of MSISDN for notification (in case of DND customers). - Welcome pack on first call, rewards and loyalty. - All the advanced features to support LTE and VoLTe

C. Bonus and packages:

- Monthly flat fee with/without usage limitation - Expenditure/duration based graded discount - Expenditure/duration based package - Timed prepayment consumptione.g. 100 minutes of on-net calls free on

TOP UP of a specified amount. - Installment for Mobile phonei.e the charges for Mobile phone to be

reduced from the customer account in defined monthly installments. - 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.

- Bonus as per allowance rules-Stepped Allowance Set & Tired allowance set.

- Reccuring usage allowance for Voice, SMS, DATA based on billing cycles.

- Bonus on incoming calls and all existing bonus features to be supported.

D. USSD / USSD like short codes and USSD Interactive:

- For Recharging - For Balance querying - For Balance/ credit transfer - For querying the MSISDN - For data balance query based on packages - For payment, subscription of service and packs - For adding and removing family numbers - For ordering of packages for voice, sms, data - For quering the Credit available

47

- For recharging Third party - For Call me back service

E. Credit Transfer via SMS, USSD, Mobiel App, IVR: - Subscriber can transfer his balance to other user via SMS/USSD/USSD - like/Mobile App/IVR

F. Class of Service (Brand)

- Pre-customizing user brands for different groups. - The brands differ in charging plans, call limiters, call rights, etc. - Premium and VIP services

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

- 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 -Bundling of services and offers -Discount: based on usage, recurring, subscription, period, on-net, off-net, group, priority or multiple discounts etc

- Accumulators: based on currency, non-currency,periodic, event based usage, volume, support for discounts and promotions.

- Promotions: preferential tarrifs, solutions based on operators - marketing team, realtime, percentage recharge, free usage for specific URL

or App, content etc. - Bonus: based on activation channel, multiple bonus, based on condition for

days or months, based on time, usage, onetime, accumulator value, balance,

48

credit, roaming, on net, off net, international, across services, across product etc.

- Rating TAX: output of price calculation for gross amount, net amount, tax amount and tax rate used for calculation and recorded in CDR.define taxation rules and tax rates by a variety of parameters including, COS, service type.

- DIY Package (Tariff Parameterization): Operator define the plan structure, customer defined the entitlement amount.

- The volume on SPR and PCRF should be updated on realtime basis to ensure proper deduction.

- The Data packages should ensure deduction from the specific package acoount only. In case of two or more packages the system should ensure deduction based on priority in concurrence with SPR.

- Group, Home Zone, Roaming, should be supported on data Packages with SMS alerts.

- Monthly recurring volume for post paid data users and trigger for limiting QoS. - The OCS and billing must support all the existing packages and Priceplans

in addition to enhanced features. - Unlimted& Limited data packages on PCRF, SPR, OCS need to be supported

with QoS control and notifications.

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.

3.32 In case of VPN, there shall not be any restriction on the number of VPNaccounts 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.

3.33 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 30 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. When 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;

49

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;

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, sms, data volume per prepaid & post paid number

average call duration

holding time per subscriber during busy hour

average call duration per subscriber

50

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.

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, HSPA, LTE and IMS 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.

3.34 e-TOP UP/ e-PIN / e-Voucher: 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.

3.34.1 There would be one type of recharge card generated in the system which can be used for all prepaid services viz. CDMA, GSM, UMTS, LTE, IMS and VCC , International Calling Cards. 3.34.2 The vouchers for different services and topup plans can be generated.

3.35 Recharge Channels: The system should support all the exsiting recharge channels. The recharge channels can be CRM, SMS, USSD / USSD like, IVR, ATM, Bank, Web, Mobile App, eTOPUP, AAS etc.

4. Billing & Customer Care Centre 4.1 The existing OCS, B&CCS & VC is serving both existing CDMA/ GSM/ UMTS/LTE

subscribers and will be replaced with new OCS & B&CCS of 500K. The offered OCS, B&CCS solution should be scaleable to 700K with additional hardware & software in case if MTML desires to go for expansion.

4.2 OCS, Billing & Customer Care System (B&CCS) provided must conform to the

standards specified in the section III, section IV-A, section IV-B of RFP. 4.3 Billing and customer care system shall be an integrated customer care, billing &

accounting platform and shall support billing for wide range of services CDMA/ GSM/ UMTS/ LTE / IMS, viz. Tele-services, Bearer services, Supplementary services, GPRS, UMS, SMS, PTT, MCA, CRBT, Cell broadcast, International Roaming and content based services.

4.4 The IN platform, USSD, IVR, VC, OTA applications, Location based services, AAA, USPP/ HLR / HSS, SPR, PCRF, GMSC, MSCs, SGSNs, GGSNs, SGw, PGw, MCA, CRBT, e-TOP UP, AAS, IMS etc all need to be integrated to the OCS or billing to realize all the existing serices and functions available. The 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

51

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, email and will serve various bill event notifications through SMS automatically, email or social media like FB, WhatsApp, WeChat etc.

4.5 B&CCS shall support the following major functions:

1. Collection, Checking, filtering and validation of Call Detail Records from Mobile Switching Centres (MSC, GMSC), MGW, SMSC, SGSN, GGSN, SGw, PGw, MMSC, Application Server of Location based services, GMLC, OTA server, CBC, AAA and all other network elements as applicable.

2. Distribution of Call Detail Records to various applications. 3. Rating & billing of voice, sms & data for post-paid customers and roaming

customers. 4. Rating & charging of voice, sms & data for pre-paid customers and roaming

customers. 5. Rating for roaming and interconnect settlement, reconciliation for Voice Calls,

SIP calls, SMS, Data for IUC and IOT purpose. 6. Rating & Billing of Roaming calls, SMS, Data. Handling of TAP and CDRs for

roamers. And TAP-IN & CDRs for retail billing of out roamers. Transferring of Inroamer TAP-OUT and CDRs to clearing houses for roaming revenue settlement among operators.

7. The system must support the alias TAP codes, NRTRDE codes also in case of Hubs. The TAP-OUT file generation must be possible with actual or alias TAP code, it should be configurable. Also the TAP-IN files received from alias TAP codes must be able to process these to the billing system.

8. Multiple Tarriffs and IOT definitions, IOT discounts would be supported for IUC and Roaming as per agreement with partners.

9. Providing timely information/data for effective and efficient customer service. 10. Timely and accurate invoicing of Voice Call, SMS, DATA records, rental, usages,

product fees, packages etc. 11. Providing various discounting schemes to the subscribers. Discounting must be

supported on pre-process and post-process. Individual billing accounts, corporate accounts, interconnect partner accounts, roaming partner accounts, the discounting should be possible based on usage (Voice, SMS, Data), fix percentage, graded over period of time, volume based, time based e.g hour, day, month, year etc.

12. Providing multiple Billing Cycles (in license service area) of same or different billing period. Billing cycles must be configurable based on customer requiremets. Provision of generating hot bills or bill on demand should be possible.

13. Support of differential tariffs, zones, time based, graded usage, volume, event etc.

14. Support of cross-product discounting, bundling services 15. Support for prioritization of services, packages, plans, tarriffs, events, discounts,

bill cycles, usages, etc. 16. Support of charging for various types of existing and new services as per

standards. 17. Provisioning of services to HLR/HSS/SPR/PCRF/AAA/MCA/CRBT/e-TOP

UP/AAS/VC/IVR/IMS and other network elements for both pre-paid and post-paid customers.

18. Customers care for service requests and bill inquiry, realtime credit availability, usage, rentals must be supported.

19. Provisioning of automatic suspension –one way / both way, disconnection and reconnection of service based upon outstanding payment and credit limits.

20. Provisioning / CDRs processing in real time and/or batch mode.

52

21. Interconnect Rating, Billing & Accounting, Reconciliation, Settlement of payment, Corrections, Reprocessing of interconnect resords and Report generation. The reports must strictly comply to MTML and Regulatory requirement.

22. Revenue sharing, Content Settlement and Reconciliation with Content Providers, Aggregators of SMS, Voice and data services.

23. Invoice calculation, formatting, dispatch and on-demand billing. 24. Number (MSISDN) inventory, IMSI, SIM (ICCID) inventory management and

Voucher Management System. 25. Accounting of payments & receivables. Revenue reports Daily, Montly, Quaterly,

Yearly are required for various services. 26. Pending dues alters and reminders. Reports related to payment, non payment

cases, revenue leakages, reconciliations or corrections. 27. Standard and ad-hoc reporting and Churn analysis. 28. Roaming support and billing in Transfer Accounts Procedures (TAP) as per

standards defined by BARG/ TADIG of GSM Association. 29. Flexible and customizable bill presentment as per MTML requirement including

logos, trademarks etc. 30. Order & Work Order management. Processing of pending, abnormal orders and

work orders related to provisioning, rating, work flows, services. 31. Trouble Ticket Management, Complain registration, Compalin handling, history

tracking, report generation. 32. Payment acceptance through cash, draft, cheque, credit card, debit card, bank,

ATM, EFT, and from other billing systems. 33. Bill presentation and sending via email on generation. Pushing the same for

diplaying on self care portals and Mobile Apps. 34. The system should send the bills automatically through email to the subscribers

having email id in addtion to generating the print file. 35. SMS, Whats app notification etc should be send to all the subscribers

automatically for the bill amount, due date of payment, last payment. 36. All the information and provisioning related to customers profile, bills, payments,

usage, recharging, service and product ordering must be available through USSD, IVR, Web, SMS, Mobile Apps.

37. The IMEI bundling, tracking based on cell ids, blocking etc to be supported as per regulatory requirements.

38. The IMSI and MSISDN bundling / unbundling for provisioning is to be supported. 39. All the service provisioning alerts and notifications should be sent via SMS. 40. The intergration with MNP database, provisioning, rating, billing and support to

implement MNP service is required. 41. IMEI in CDRs, IMEI blocking and unblocking to EIR should be supported. And

the CDRs on OCS and billing must have the IMEI as well. 4.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 / UMTS/ LTE/ IMS

ii. General Packet Radio Services, EPC, QoS, APNs, Static IPs etc iii. Wireless 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 GSM / UMTS/ LTE/ IMS vii. Messaging Services such as SMS, MMS, UMS etc. viii. Location Based Services such as Fleet Management, Navigational, ix. Informational, Entertainment, Advertisement etc. x. Push To Talk over Cellular xi. Cell Broadcast Services xii. Over The Air Services such as content down load using SIM browser

53

4.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 iv. Post-paid threshold and pre-paid billing v. Wholesale 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 Wizard, in addition to the normal registration

interface.

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

4.9 The Mediation System Platform shall be able to collect usage events from different network elements of GSM, CDMA, UMTS, LTE network for Voice, SMS, DATA, CDRs from MSC, SGSN, GGSN, SGw, PGw, Location based services, application server, SMSC, MMSC, GMLC, AAA etc as per 3GPP on the same Platform.

4.10 The system must have a rules based logic configuration for mapping MTML’s business processes. 4.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.

4.12 SMS CDRs should be polled from SMSC so as to make SMS charging based on the

destination and content. Online charging of SMS is required. 4.13 The TAP-3.12 or latest version should be available as per GSMA standards (TD57).

The processing of CDRs to and from TAP files should be as per agreed IOTs with partners. Missing TAP files and RAP files will need to be handled for corrections. Migration to any future version should be possible. 4.14 Transfer of files to DCH and from DCH to the billing system should be available. The

file types can be TAP-IN, TAP-OUT, NRTRDE, RAP, Missing files, etc. This transfer of files between DCH and system will be using secure tunnel GRE or IPSEC for VPN.

4.15 The system must be capable of generating NRTRDE files and process the same for

fraud protection as per GSMA guidelines for both in-roamers and out-roamers. Alerts and alarms must be generated for fraudulent events based on excessive usage, duration or volume etc.

4.16 System must be capable of generating reports, bills and invoices for roaming and

interconnect partners. 4.17 All CSR counters should have the facility of online payment collection. 4.18 Audio visual alarm indicating the failure of CDRs polling from any of the MSC’s,

GMSC, SMSC, SGw, PGw, SGSN, GGSN, AAA etc should be generated by the system.

54

4.19 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 4.20 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 report (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.

4.21 The system shall be based on Relational Database Management system 4.22 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 Work (SoW)” mutually agreed by MTML and the successful bidder.

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

4.25 B&CCS shall interface for CDR data collection as well as service provisioning and seamlessly integrate with the existing network elements in the MTML network.

4.26 The replacement of existing billing system, will be completely bidder’s responsibility.

And must ensure 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 -

-ZTE MSCS -ZTE CG-CS -ZTE CG-PS -PDSN/ AAA

55

-HLRe/HLR/HSS/SPR/PCRF -GGSN/SGSN/PGw/SGw -MCA/CRBT/AAS/VC/e-TOP Up /Banks /Paymet Gateways -Mobile Apps, Web, USSD, IVR platform - any other network element generating billable events - Content based third party applications

(c) get into a definitive agreement with the existing suppliers for integration.

4.27 The bidder shall provide a roadmap for future releases of the proposed system.

4.28 The bidder shall provide a description of the approach that the bidder would take in data migration from legacy system to the bidder application.

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

4.30 The bidder shall impart training to personnels of MTML in all aspects of OCS, B&CCS VC, Interconnect and roaming, routine checks, backup & restoration, operation and maintenance.

5.1 B&CCS System requirements

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

56

i. Basically, the Mauritius currency shall be used in the system. However, the system shall support use of other currencies with precision of 3 decimal places. For TAP (SDR currency) precesion 5 decimal places or more is needed. The same should be configurable.

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 to locally connected 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 shall be available in the African region.

q. The system shall support the function of sending customer related charging, billing & other information to individual customer through SMS and email.

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.

5.1.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 OCS, B&CCS system shall be capable to handle at least 500K normal subscribers postpaid and prepaid (including 100K Billing customers) 100% will be Online subscribers and Hot Billing should also be possible. The system for CRM must support connection of at least 50 terminals simultaneously of access.

iii. The system shall have capability to provide hot rating and software enabled connection and disconnection of customers for all type of switches.

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

57

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

vi. The system shall handle all types of services available in the proposed core network and VAS.

vii. The system shall support new services that may be incorporated in the core network and VAS within the project period.

5.1.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 core network and VAS.

5.1.4 Bill Production

The proposed bill system shall be able to produce at least 100K invoices/day and bill production shall be possible to run without affecting cash collection and normal customer care service operation

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

5.1.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 core network and VAS simultaneously.

iii. The system shall be offered with adequate Hardware and software including tools and utilities to operate and monitor the system effectively.

5.1.7 Connections and Provisioning

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 core network and VASes.

b. Generally provisioning/Deprovisioning of services in the core network and VAS 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.

58

d. The system shall have provision of interfaces to connect to B&CCS system and its database from third party software’s.

e. System should provide end-to-end automatic provisioning towards multiple provisioning targets in varied access networks in an integrated manner to enable service activation and fulfillment with speed and accuracy.

f. Supports multiple communication protocols like web services, http post, http REST, SOAP, socket APIs like Telnet, MML, SMPP etc..

g. Architected for flexibility and asynchronous transactional execution with complete audit trail and automated as well as manual re-execution of provisioning failures.

h. Supports configurable provisioning targets along with commands and correspoding parameters.

i. Maintains logs for failure as well as successful provisioning transactions. Captures the command executed along with the values, timestamp of execution, the error codes and error messages for quick analysis.

j. Smart GUI to view the logs, quickly search and filter through the logs with the help of various search criteria like user id, error code, date, command etc. Erroneous commands can be corrected manually and re-executed.

k. Automated retry of failed transactions at a configurable time interval until the provisioning is successful.

5.1.8 Tools

a. Tools for file transfer from proposed B&CCS system to MS windows latest versions.

b. The system shall be equipped with hardware interfaces and software tools to establish connections with the core network and VASes 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 core network and VASes.

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

5.1.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 ii) Field description iii) Value list of acceptable values for a particular filed iv) Pull down lists with selection capabilities

59

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. d. Should be able to perform operations like post payment, balance

adjustment etc. e Should be able to perform subscriptions related operations like view

cancelled services, expired services, manage services etc. f. Should be able to search for particular EDR data based on time stamp,

IP address etc g. Should be able to view operations history for particular subscriber and

also should be able to search for particular operation based on Time stamp, operation etc.

h. Should be able to manage account credentials of subscriber for self- care portal. i. Should be able to allow/deny access to self-care portal. j. Should be able to view billing details including usage, balance, discounts etc. k. Should be able to view generated invoice for use services, payments made by subscriber, account transactions. l. Should be able to set hotline status for particular subscriber which will

redirect subscriber to notification/dunning portal.

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

60

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.

5.1.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. It must be possible to make a complete system backup online.The system shall provide backup for OS, Application, Configuration, Data and Schema. Detailed backup procedures and proposals for backup intervals shall be provided by the Supplier.

iii. Backup data containing customer data or security related data shall be stored encrypted and access to the encryption key shall be restricted.

iv. System shall have provision for recovery from backup in order to continue processing from the checkpoint onwards.

v. The system shall have efficient and reliable backup and recovery on regular basis.

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

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

viii. The system shall provide backup management utilities for the proper management of backup and recovery. The version of the system backup shall be easily obtained. The operator shall be able to designate one among the available copies to be used for a reload. Under normal circumstances, the backup copy used in a reload will be automatically the latest version

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

5.1.13 Scaleable

a. The system shall be scaleable in terms of performance and functionality. b. Many online and batch processes shall run concurrently making use of

multi processing environment. c. Running of batch processes and online processes simultaneously shall not

degrade the performance of the system. d. Bulk creation, provisioning, distribution, feature modifications,

adjustments, etc should be GUI based.

5.1.14 Fault Tolerance

61

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.

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

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

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.

iv. Access from any shop for a user needs additional security feature.

5.2 Hardware

a. The vendor is required to quote the hardware as per the Schedule of requirement and the quantity needed to realize capacity, features and services

for 500K. 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.

b. The solution's proposed must include redundancy and fault-tolerance features

to ensure 7x24 operation, 99.999% availability for critical components. The

solution design will incorporate component and functional resilience to

eliminate all single points of failure (SPOFs). All modules must be configured

with redundancy, include active-standby mode or N+1 load sharing mode.

c. The solution must support dynamic protect mechanism, handle overload

situations from internal and external interfaces according to the system's real

time running status and performance (response time). System shall guarantee

a full working under heavy load conditions and have control mechanisms to

avoid system overload and service failure.

5.2.1 RISC server with Storage System

62

The RISC servers or higher shall be configured as 1+1 high availability active and standby configuration. This will be ensured for OCS, Billing, Interconnect, Roaming, Voucher Centre, SPR, PCRF, SMSC, USSD etc to achieve redundancy.

5.2.2 RISC processors

The offered server shall be equipped with minimum 8 core RISC processors or equivalent higher capacity in each server. The offered server shall have the capacity to accommodate at least additional four more RISC processors in each server

5.2.3 Main Memory

The offered server shall be equipped with minimum 128 GB of RAM in each server. The offered server shall be able to increase the memory capacity to 256 GB RAM by adding memory modules. At least 16 DIMM slots are required.

5.2.4 Storage Capacity The offered server shall have sufficient storage capacity to process 100K 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.

5.2.5 Other Accessories The vendor shall supply all necessary connectors and cables to connect

offered peripherals.

The offered server shall have port to connect UPS monitoring port of UPS for automatic power supply fail support. The devices, servers, elements, switches, diak arrays, network cards etc shall be connected with 1+1 active standby configuration. The vendor shall supply full set of Operation and Installation manuals.

5.2.6 Backup device

The vendor shall supply 2 (two) units of external backup drive of 16TB, cables, connectors, and software necessary for full function of drive.

Software management tool for backup/recovery for managing all internal and external backup devices.

5.2.7 Spare parts

i. 4 set of Memory Modules of capacity as used in the server. ii. 4 units of spare hard disks

63

iii. 5 units of network interface cards iv. 2 units of power supply system

5.2.8 Operating system on Server

i. The offered system shall have UNIX / LINUX (Redhat, Suse) operating system with licences should be provided.

ii. The mainstream OS system with latest version (released within 3 years) and patch.

iii. The offered system shall support Symmetrical Multiprocessors on the RISC servers.

iv. The offered system shall work on client/server architecture v. The offered operating system shall have utility for online backup and recovery

of files. vi. The vendor shall specify and include the necessary software tools to

establish link from client’s terminal to the server in the offer.

vii. The offered operating system shall work on TCP/IP protocol viii. The vendor shall specify and provide necessary software with manuals to

operate and manage whole networks. ix. The vendor shall plan IP address for sub networks under private IP address

range. x. The vendor shall specify and supply all necessary drivers to fully operate all

the accessories offered under this RFP. xi. The vendor shall describe what is the service life cycle of the OS and whatis

its strategy of aligning with the latest OS version. xii. The solution must include all the licenses of the OS version containing all

functionalities and the support.

xiii. The proposed OS shall support facilities for virus detection and removal

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

64

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

16 The proposed RDBMS shall include Diagnostic and Tuning Packs for database tuning, diagnostics and monitoring for enhancement of performance.

17 The proposed RDBMS shall be provided with necessary Partition Option.

18 The vendor shall provide Report Generation and Designing Tolls. 19 The vendor shall provide FULL SET OF MANUALS. 20 The dabase must support the TPS, speed and capacity required.

5.2.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 core network and VAS. 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 Complete network diagram representing the configuration for the offered billing system including integration to the core network and VAS shall be provided by the vendor. All equipment (hardware/software) to operate such a system and network shall be included in the offer.

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

65

Database structure including structure of all data items

Entry Screens

Reports

Queries

Insertion of additional sub modules 5.2.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

5.2.14 All the user licenses of the software products shall be licensed to MTML including OS, DB, Oracle, Applications etc.

5.2.15 The successful bidder may use existing billing hardware available in MTML

to the extent possible. 5.2.16 The offered OCS, 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. The Call Centre solution to be provided by the bidder with monitoring/ supervisory functionalities. The reports related to agent performance, pending trouble ticket, compalinace and effective call handling would be provided as per MTML requirements.

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

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

66

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

5.2.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 combination/ proportion

of total subscribers

2. Retention of billed data 6 months bill image and billed usage

3. Retention of unbilled data 2 months unbilled usage

4. CDRs/day/subscriber 20

5. Bill Cycle 10

6. CDR split factor 1.6

7. Usage size 511 bytes

8. Treatment of prepaid CDRs

Stored in the SAN

9. Bill run duration per bill cycle

Less than 2 hours

10. Rating per day Less than 2 hours

11. SIM inventory management

200% of total subscribers

12. TPS >20,000 and to support the capacity

13. Data customers 100% active

5.2.21 The inventory management 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. Should be able to add new inventory with name, category, subcategory, description, parameters, search, update, transfer, manage life cycle of inventory, inventory reports etc.

67

5.2.22 The system should have feature of notifying the subscriber over SMS regarding any change in service or welcome message once it is provisioned by B&CCS system. The system should also notify the subscribers with a welcome message while registering in the system on roaming.

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

5.2.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. Voucher Management

6.1.1 Should be able to handle the entire voucher life-cycle from creation of vouchers till expiration of vouchers easily and in efficient manner.

6.1.2 Should be able to create vouchers for any usage like make payments, renew service, top up balance, transfer etc.

6.1.3 Should be able to create voucher template with template name, description, voucher pattern, cost and other parameters necessary for voucher creation.

6.1.4 Should be able to update fields of particular voucher template easily. 6.1.5 Should be able to get list of voucher templates added in system along with

details and can reuse it in future if needed. 6.1.6 Should be able to delete single/multiple voucher templates. 6.1.7 Should be able to create vouchers from selected particular voucher template

present in the list along with fields like batch number, voucher status, total number of vouchers etc.

6.1.8 Should be able to search particular template based on some parameters like template name, status, cost etc.

6.1.9 Should be able to manage status of voucher templates like active/inactive which can be used further for voucher creation.

6.1.10 Should have option for selecting columns to display on page of voucher templates and/or vouchers page.

6.1.11 Should be able to get details of all vouchers present in system like total count of vouchers, status wise count of vouchers etc.

6.1.12 Should be able to change status of vouchers. 6.1.13 Should be able to transfer and/or export vouchers with PINs and Passwords

in CSV/flat file. 6.1.14 Should have password protected vouchers so that these vouchers can be

exported to external system in secure way. 6.1.15 Should be able to manage users accessing VMS by creating roles for

restricting access to pages of VMS. 6.1.16 Should be able to add user in system with mandatory fields like name, id,

email, password, role, and other relevant information. 6.1.17 Should be able to get list of roles present in VMS 6.1.18 Should be able to delete single/multiple roles present in VMS 6.1.19 Should be able to search for particular role added based on some parameters

like role name, parent role etc. 6.1.20 Should have option for selecting columns to display on page of roles and/or

page of users in VMS. 6.1.21 Should be able to add user in system with mandatory fields like name, id,

email, password, role, and other relevant information. 6.1.22 Should be able to reset password of particular user quickly and easily. 6.1.23 Should be able to update details of particular user present in system.

68

6.1.24 Should be able to get list of users added in system along with their descriptions.

6.1.25 Should be able to delete single/multiple users present in system. 6.1.26 Should be able to search for particular user based on some parameters like

user ID, email, first name, role etc. 6.1.27 Should have user friendly and easy, simple GUI 6.1.28 Should be able to show customized, insightful graphical reports based on

voucher status record, vouchers due expiry on particular date etc. 6.1.29 Should be able to perform advance search/ filter operation for all modules like

users, roles, voucher templates, vouchers etc. 6.1.30 Should be able to get details of history of every activity done in system in the

form of audit logs. 6.1.31 Should be able to get details of generation status list of vouchers, transfer

notes of vouchers etc. 6.2.1 The Voucher centre should have the capacity of 30Mil. without any limitations

on status of cards. The same should be expandable to 50Mil. if MTML desires to go for expansion.

6.2.2 The Voucher Centre must ensure the redundancy interms of hardware, cards, interfaces, connectivity etc.

6.2.3 The exisiting Voucher Centre data should be able to migrate to the new system.

6.3 Billing & Customer Care Module 6.3.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.3.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. The NID or Passport ID should be mandatory and may also support the Biometric registration. The registration process will be carried out using Web, Mobile App, e-KYC terminal or App, Dealers, Retailers / Shops etc.

6.3.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: When 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.

69

iii) The screen format for customer installation shall be easily configurable by user as and when required.

6.3.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 / NID keeping all other information same

6.3.1.4 Change of Customer ID: The proposed billing system shall handle Change of customer ID keeping all other information same

6.3.1.5 Change of Phone Numbers: The proposed billing system shall handle Change of phone numbers without changing other information. 6.3.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.3.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.3.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 core network and VAS, 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.3.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

70

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

6.3.2 Fraud Management

6.3.2.1 The 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.3.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.3.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 (Daily, Weekly, Monthly, Quarterly/ Yearly). (ii) Reports on which routine action is required to be taken. (iii) Exception Reports on which immediate action is required.

71

(iii) Archival Reports. (iv) Reports for SHOPS, ICTA, Marketing / Sales, Customer, Customer

care etc (v) Reports for Payament Collection, Sales, Revenue, Churn Report, Audit

Reports and finance reports as per MTML requirememt

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 : 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. f) ARPU g) Chrun

(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 f. Payments from various channnels

(iv) Archival Reports

a. Local call statement b. Trunk, international 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. Ledger and Sub-Ledger Accounts. i. Inventory statement for products j. Notices and received payments, outstanding payments.

The system shall provide unlimited enquiry capabilities to all users of the system. These enquiries shall include enquiry on advice notes, bills,

72

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.3.4 CDR Collection and Bill Processing Module

6.3.4.1 Online Data Transfer i. The proposed billing system shall collect online Call Detail Records

(CDR) from the core network and VAS. ii. The proposed billing system shall collect online Call Detail Records

(CDR) from multiple core network and VASes of different make and model.

iii. The proposed billing system shall collect CDRs to B&CCS from core network and VASes 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.3.4.2 Off Line Data transfer

The proposed billing system shall have provision to transfer the CDRs from core network and VAS 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.3.4.3 CDR data conversion

i. The system shall manage all types of CDR formats collected from different types of core network and VASes

ii. All CDR retrieved from different core network and VASes 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.

73

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

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

The system rate the calls depending upon Outgoing call, Incoming call, Forwarded call, Event record etc. with base station wise, core network and VAS wise etc.

viii. The proposed billing system shall rate the calls of one core network and VAS’s subscribers but making calls from different core network and VAS while roaming.

6.3.4.6 Tariff

The system shall provide a versatile and flexible tariff system, easily configurable by user as and when required

74

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

Holidays

Core network and VAS

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. With multiple Services providers it should be possible to define several MVNEs and Several MVNOs instances independent of each other from a functional point of view. 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.

75

6.3.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, SMS, DATA etc.

The system shall provide discounts on below and conditions specified in DISCOUNTS

a. Amount b. Percentage c. Amount and Percentage

6.3.4.8 Preparation for Bill creation

a. The system shall have provision for processing of usage data from any core network and VAS 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.3.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. g. Credit limit for individual customer should be configurable. Incase of single

account with multiple connections credit limit should be configurable for a particular account as well as individual numbers and for all services seperately.

76

h. Credit limit should be calculated based on credit limit set minus the usage value. For a particular month, the Credit limit should not take into account the current invoiced amount whose due date is later.

i. Notifications for credit control using SMS, USSD, email etc to be provided.

6.3.4.10 Billing Modes of Operation

Normal Bill Run The billing shall support billing of all customers for a selected bill cycle. Billing cycles shall be configurable and customer can be given choice to select any. Bill run should not be restricted for particular time, and should not affect the overall system performance. On Demand Bill or Hot Bill Run The system shall have provision of immediate billing of a customer or group of customers with proper accounting for restoration or closing of accounts. Must enable the customer to pay the dues as on date including the prorated rentals if any along with the usage.

6.3.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.3.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 10 (Ten) 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.

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

77

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, Surcharge, Late Fees

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

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.

78

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

Email, Mobile App

6.3.4.16 Rating: The solution shall support rating parameter for OCS to differentiate charging as following , but not limit to,

- Bearer type (VoLTE, VoWifi, etc.) - Service type (Voice, Video, SMS, RCS Content, RCS Voice, etc.) - Content type and size (jpg, application, etc.) - Call Type (MO, MF, MT, etc.)

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.3.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.3.4.18 Reports on CDR collection and Bill processing

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:

79

File name

Date & time of transfer

File status

Name of core network and VAS

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, missing 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 core network and VAS 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

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

80

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.3.5 Customer Ledger and Cash Collection Module

6.3.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.3.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. 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. Long pending debts reports and mechanism to account and collect should be incorporated.

(A) Debtor collection

Collection amounts:

81

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

82

(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

Products and accessories 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

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.

83

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

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

Cash transaction & bank entry verification

84

6.3.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 core network and VAS, (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. 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,

85

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

86

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

87

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 - Adjustments before and after billing process

6.3.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.3.7 Interconnect 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, SIP providers.

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$, Euro, 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.

The system shall support different tariff plan.

The system shall have provision to the sharing reports both for outgoing and incoming calls.

88

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

7. SMSC:

7.1.1 MTML presently has ZTE make SMSC dimentioned for 500K Subscribers.

Existing SMSC should be suitably integrated with a new SMSC of capacity as envisaged in this tender to provide CDMA, 2G, 3G, 4G services seamlessly to the existing 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.

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

7.1.2 The bidders also have the option to expand and upgrade the existing SMSC

for providing 2G,3G,4G services seamlessly to the existing as well as new capacity.

7.1.3 Design Aspects:

i. Common SMSC for 2G &3G services (CDMA, GSM, UMTS, LTE, IMS) in any proportion.

ii. Must support content based charging for post paid and prepaid subs. iii. 2 BHSM per subscriber. iv. GUI based faults and reports including failure reports for SMPP, VMS,

IN related SMS. 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.

7.1.4 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. And support all the coding formats.

7.1.5 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

89

on the cause-code of non-delivery together with programmable re-trial duration for each cause-code through MMI commands.

7.2 SMSC Core Requirement a) The vendor’s solution must support interface for message delivery on 2G, 3G

and 4G. b) Solution must support Interworking MSC, HLR & 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/UMTS/LTE

signaling. j) The SMS must support diameter, real time charging interface. k) It must handle GSM, CDMA, and SIP protocol in one set of SMSC. Operators

only need one set of SMSC for multiple networks. l) Should support international SMS for GSM/CDMA/TDMA/UMTS/LTE

customers. m) Apropriate SMSC Firewall solution should also be inbuilt in order to block the

spam messages based on GT, destination, source, time. n) Appropriate spoofing solution should be inbuilt in order to block the spam

messages. o) Should be able to support online charging for customers and integrate with

OCS & Billing using standard protocols. p) Interconnects with SMPP (on all versions) need to be supported. q) Should be able to generate reports for number of messages and destination

wise, partner wise, etc r) Modification of calling and called with support for Alphanumeric characters.

7.3 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 256 content providers are to be provided access to the SMSC. The SMSC needs to support connections on SS7 and SMPP both. The SMSC must be able to send transit traffic to other operators and international destinations. 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.

90

7.4 SMSC 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 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, HLRs, and STPs

j) The SMSC should provide sending group and short number short message based on the web portal for enterprises

k) Should be able to handle the International SMS for local and transit. 7.5 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.

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

7.7 The SMSC shall have suitable interface (IS 41-C) to interwork with CDMA-1X

It shall be possible to exchange Short Messages between the CDMA and GSM systems with MNP also. The SMSC should be common for CDMA, 2G, 3G, 4G services and compliant to 3GPP TS 23.040.

7.8 SMSC shall provide for multiple local language support in the UNICODE

format. Details of implementation for the same may be furnished. 7.9 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.

91

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

7.11 The solution must be capable of placing and exporting CDRs in a flat text file

or CSV.

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

8. Airtime AdvanceSystem

8.1 The AAS (Airtime Advance System) is a solution which provides airtime to prepaid subscriber basis on age on network.

8.2 User friendly and easy to use service. 8.3 Credit: Sending a SMS or by dialing an USSD shortcode, subscriber

can access Airtime Advance service and based on subscriber profiling eligible amount will be credited to subscriber mobile number.

8.4 Collection: During subsequent recharge by subscriber, credited amount will be deducted from subscriber's mobile balance. Must ensure recovery with service charges.

8.5 SMS confirmation to subscriber of updated balance. 8.6 Customer Care interface for customer queries. 8.7 Extensive report on transactions and reconciliation. 8.8 Time-based auto-recharge: For example, the system automatically

recharges small amount at the beginning of each month. 8.9 Low balance based auto-recharge. 8.10 X days before subscriber’s active status expiration date auto-

recharge. 8.11 AAS must be able to integrate with OCS or supplied as inbuilt feature

on OCS. All the triggers to IN, eTOPUP, OCS need to be supported along with the interfaces for USSD, SMPP, SOAP etc to realize the function.

92

9. E-TOPUP / e-VOUCHER/ E-PIN

9.1 System must support distribution of scratch card via Dealers and SMS

instead of a physical recharge voucher and transfer the talk time from

Prepaid to Prepaid and Postpaid to Prepaid subscribers.

9.2 Enables complete automation & simplification of the entire ‘Recharge’

process.

9.3 Real-time electronic inventory management allows unprecedented

granularity and transparency for full oversight of the retail channel.

Accurate & error free system.

9.5 Support the sharing of account balances via their phone using STK

menu/SMS message.

9.4 Dealer Management: Creation of Franchisee structure, Adding dealers

and retailers, Association of franchisee to operator manager of that

province, Validation of the dealer, Stock movement validations,

Deletion or termination of the dealer etc.

9.5 Virtual voucher distribution, Stock audits and stock movement

management, Stock allocation by the operator to the dealer or

franchisee.

9.6 Maintaining Primary, Secondary & Tertiary Sales Reports - MIS access

at each level of sale.

10. USSD system and USSD Interactive Menu

10.1 The USSD supports process unstructured supplementary service data requests (PSSRs), which are USSD requests initiated by mobile stations (MSs), and allows a USSD session to involve multiple interactions. 10.2 The USSD supports unstructured supplementary services requests (USSRs), which are USSD requests initiated by service providers (SPs), content providers (CPs), or applications, and allows a USSD session to involve multiple interactions. 10.3 The USSD supports unstructured supplementary service data notifications (USSNs), which are USSD notifications initiated by service providers (SPs), content providers (CPs), or applications, and allows a USSD session to involve multiple interactions. 10.4 The USSD system should provide the channel for Recharging, Balance querying, Balance/ credit transfer, querying the MSISDN, data balance query based on packages, payment, subscription of service and packs, adding and removing family numbers, ordering of packages for voice / sms /data, quering the Credit available, recharging Third party, Call me back service. Two or more languages.

93

10.5 Must support all the 3GPP standard interfaces and integration to OCS, IN. The Unstructured Supplementary Service Data (USSD) will use the Universal Signaling Access Unit (USAU) or Advanced Signaling Access Unit (ASAU) to connect to the Signaling System No.7 (SS7) network. 10.6 The USSD Interactive menu should be configurable as per MTMLs requirement. 10.7 The Unstructured Supplementary Service Data (USSD) supports the messagecontent encoding schemes: 7-bit encoding scheme, 8-bit encoding scheme, Unicode encoding scheme (16-bit encoding scheme), for example, UCS2 encodingscheme (used for Chinese character encoding). 10.8 The system should be able to generate alarms on failure. Reports and performance monitor is required. 10.9 All the exisiting USSD / USSD like services to be migrated to the new system.

11. Missed Call Alert (MCA)

11.1 The MCA system should support Standalone MCA (without having

Mailbox) 11.2 Group notification based on Calling party. 11.3 Consolidated notification by SMS for all missed calls (Busy, No Answer,

Unreachable, Switched OFF. 11.4 The system should be integrable to the core network based on 3GPP

standard interfaces. 11.5 Support querying alerts for user or group. 11.6 Reports can be generated for various MCA based on reason to trigger. 11.7 The existing MCA data should be migrated to new system.

12. PCRF & SPR

13.1 The solution shall be compliant to 3GPP TS 23.002 (Technical

Specification Group Services and System Aspects; Network Architecture), including all optional features mentioned in this standard. Vendor shall state releases/versions supported.

13.2 Authorize QoS resources based on the service information

received from the P-CSCF and other Application Functions via

the Rx interface and/or the subscription information received

from the SPR via the Sp interface.

13.3 Encompass policy control decisions and flow based charging

control functionalities.

13.4 Determine the policy rules for each IP-CAN session and enforce

these rules through the PCEF, which is the entity that handles the

transport plane. The communication between the PCRF and the

PCEF takes place over the Gx interface.

13.5 The vendor shall state their compliancy to the Binding

94

mechanism in compliance with TS 23.203 release 11 or above

version.

13.6 The vendor shall state their compliancy to the Gating control

mechanism in compliance with TS 23.203 release 11 or above

version.

13.7 The vendor shall state their compliancy to the event reporting

mechanism in compliance with TS 23.203 release 11 or above

version.

13.8 The vendor shall state their compliancy to the QoS control

mechanism in compliance with TS 23.203 release 11 or above

version.

13.9 The vendor shall state their compliancy to the IP-CAN bearer

establishment mechanism in compliance with TS 23.203 release

11 or above version.

13.10 The proposed PCRF solution shall support integrating with SPR via Sp interface and also integration of OCS with SPR.

13.11 The PCRF and SPR should support all the existing data packages and there should be no limitations to the number of packages which can be configured. These will also need to be migrated to the new system.

13.12 The SPR must support recurring for postpaid customers.

13.13 The SPR should be able to update the volume to PCRF in

realtime basis and also should be able to query realtime balance usage on PCRF for updating to OCS.

13.14 When subscription changed, SPR should notify this change to PCRF via SOAP.

13.15 Support notifications by SMS and connectivity to SMSC on SMPP.

13.16 The PCRF and SPR shall support Multi-Level Data Backup

Mechanisms.

13.17 The SPR shall receive subscriber profiles updates, limited to selected parameters, from the PCRF via the Sp interface, and from other entities (including OCS) via the SOAP interface.

13.18 The PCRF, SPR & OCS must support all the AVPs as per 3GPP.

12.19 The SPR shall contain the subscriber profile (subscriber class, etc) and also keep track of subscriber activity (session based) with the latest accumulated volume consumption, home location, etc per session and per service/application.

12.20 The information will be retrieved from PCRF as a decision element to

95

assist with the enforcement of a policy in a session and will be available to the operator’s CRM (Customer Relationship Management) systems.

12.21 SPR shall receive the subscriber profile from Provisioning via the External Trigger (for package activation) and Provisioning Interface.

12.22 Performance monitoring, reports and fault alarms on SMS shoud be supported.

* * * * * * *

96

Section V

SCHEDULE OF REQUIREMENTS

Sl No.

Description Unit Total Remarks

1.0 Hardware

1.1 Servers

1.2 Disk Arrays

1.3 LAN Switches, Routers

1.4 Firewall

1.5 Cables (LAN, Serial etc), interfaces

1.6 Power Cables , Adapters

2.0 Software & Services

2.1 OCS

2.2 Billing & Invoicing

2.3 Roaming

2.4 Voucher Management

2.5 Mediation & Provisioning

2.6 Interconnect Management

2.7 Dealer Management

2.8 Inventory Management

2.9 Account & Ledger

2.10 Rating & Charging

2.11 Reports

2.12 SPR

2.13 CRM & Customer Care

97

2.14 SCP, SDP

2.15 Work Order Management

2.16 Package & Price Plan Management

2.17 Alerts, Notifications & Orders (SMS, USSD)

2.18 AAS(Airtime Advance System)

2.19 e-TOPUP / e-Voucher

2.20 Mobile App & Self Care

2.21 e-KYC

2.22 NMS & PMS (Network Management & Performance Management System)

3.0 Optionals Items

3.1 USSD Platform

3.2 SMSC, SMSC Firewall Solution

3.3 Mobile Money

3.4 PCRF

3.5 SSP / IN

4.0 Database & OS

4.1 Oracle RDBMS

4.2 Licenses

4.3 External Backup device & Software

4.4 Operating System

5.0 Other Items

5.1 Hardware

5.2 Client Software

5.3 Licenses

98

Section VI

Delivery Schedule

A. Completion of Factory Inspection at

Manufacturer’s Premises, if required by MTML

Within 2 months from the date of PO.

B Commencement of Supply of Equipments

Within 3 months from the date of PO.

E Completion of entire Turnkey project with installation, commissioning after successful Acceptance Testing, including migration of IN, B&CCS and other elements wherever required.

Within 6 months from the date of PO.

99

SECTION-VII

BID FORM & PRICE SCHEDULE

TABLE-I A

(EQUIPMENT/ HARDWARE )

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

(SOFTWARE & LICENSES)

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

(SERVICE CHARGES)

Figures in USD

S.No. Item description Amount

1. Installation, Testing, & Commissioning

100

TABLE-III

COMPREHENSIVE ANNUAL MAINTENANCE CONTRACT (EQUIPMENT &

SOFTWARE) FOR 5 7 YEARS AFTER WARRANTY PERIOD

S.No. Item Description Year wise AMC Charges

Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7

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

101

Annexure-I Bid Security Form

Ref No. :…………… Date :…….. To Mahanagar Telephone (Mauritius) Limited MTML Tower, 63, Ebene 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 ………………….. 20 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

102

Annexure-II

Performance Guarantee Form Ref No. :…………… Date :…….. To Mahanagar Telephone (Mauritius) Limited MTML Tower, 63, Ebene 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 WHEREAS 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 WHEREAS 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 Words]. We 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 ……………………. 20 Signature of Bank Seal of Bank

103

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.

104

Annexure-IV

MANUFACTURERS AUTHORISATION FORM

To

The Chief Executive Officer Mahanagar Telephone (Mauritius) Ltd.

MTML Tower, 63, Ebene Mauritius.

Dear Sir,

RFP No. ……………………………….. Dated …………………… We _______________________________________ 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. We 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

105

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

106

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 beyond three month. Both

107

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.

108

Annexure-VI Existing Network information We have the below modules available on the present Online Charging System & BSS:

1. Customer Relationship Module (CRM)

2. Product Management & CSR

3. Charging & Billing

4. Mediation & Provisioning

5. IUC (Settlement & Roaming)

6. Self Care

7. Dealer Management

8. Inventory Management

9. Accounting & Ledger

FAQs for existing OCS and BSS:

1. How many subscribers do you have on the network : 500K

2. Is it for voice/sms/data or just one: all is online (voice/SMS/Data)

3. Number of transactions per second for each voice, data and SMS : 20,000 TPS

4. Protocols support needed (radius, SS7, diameter, M3UA, MML): Diameter for

charging, MML for provisioning.

5. IN core provider?: ZTE V3 (use CAMEL for both POST and PREPAID customers and

the CAMEL to Diameter conversion is done by DCC on IN).

6. Installation & Commissioning time line : by March 2019

7. Notification and lifecycle messages?: Yes, support needed for these.

8. Provisioning to CN nodes: Yes needed towards HLR, HSS, SPR (vendor: ZTE V4)

9. Voucher Management is compulsory.

10. Optional: AAS, etopup, USSD platform, PCRF, SPR. PCRF integrated to OCS is

needed if supported (Optional)

11. Other Services supported: 1. VCC Post-paid 060 (Virtual Card Calling) to allow other

network to use MTML’s post-paid ILD services, 2. VCC Prepaid service 061 is on IN

platform, 3. Family number, Packages: Voice, SMS, Data bundling, 4. CUG, 5. PCRF

packages for data, 6. Package activation using SMS and notifications to customer,

Corporate accounts with different services and users.

12. Third party integrations to OCS system: CRBT, Banks, eTop UP, Airtime Advance

System (AAS), Missed Call Alert, USSD query, eKYC.

13. Existing Hardware : IBM720 (1+1), IBM520 (1+1), DA (Fujitsu ETERNUS DX80,

DX60)16TB

MTML confidential

109

MTML confidential