Request for Proposal

For

GSM/ HSPA Network

For deployment in
MTML Mauritius

Requested by:
Mahanagar Telephone (Mauritius) Ltd.
(A subsidiary of Mahanagar Telephone Nigam Ltd-A Govt. of India
Enterprise )

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

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

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

TENDER DOCUMENT

Ref: Global Tender Notice No. MTML/GSM/ RFP/1 dated 14.10.2009 for procurement
of 200,000 GSM/ HSPA Equipment (in 2 phases) based on 2G & 3G Technology
in MTML Mauritius on turn key basis.

Please find enclosed the following bid docum ents to be used for subm ission of the bid.

S.No. Title Section Page No.

1. Notice Inviting Tender (NIT) I 3
2. Instructions to bidders II 5
3. General (comm ercial) conditions of contract III 19
4. (a) Special Conditions of Contract IV-A 30
4. (b) Detailed Technical Requirem ents IV-B 41
5. Schedule of Requirem ents V 191
6. Delivery Schedule VI 199
7. Price Schedule for Equipm ents VIII Table I 200
8. Price Schedule for Services VIII Table II 200
9. Price Schedule for AMC VIII Table III 201
10. List/ price of Spares VIII Table IV 201
11. Bid Security Form Annex-I 202
12. Perform ance Security Guarantee Bond Annex-II 203
13. Letter of Authorisation for attending Bid Annex-III 204
Opening
14. Manufacturer’s Authorization Form Annex-IV 205
15. AMC Term s & Conditions Annex-V 206
16. Existing Network inform ation Annex-VI 209

Your offer com plete in all respects as per enclosed docum ents must reach latest by
15.00 Hrs. of 16.11.2009 at the following address:

Chief Technical Officer

Mahanagar Telephone (Mauritius) Lim ited,
‘MTML Tower’, 30, Eugene Laurent Str, Port Louis
Mauritius

The “Instructions to Bidder” and “General (Comm ercial) conditions” are applicable for
this Tender. However, the clauses m entioned in the “Special Conditions of Contract” &
“Technical Specifications” will supersede the General (Comm ercial) Conditions.

Tender bids shall be opened at 15.30 Hrs.on 16.11.2009. The representatives of the
bidders who wish to be present during tender opening m ay kindly m ake it convenient to
attend the sam e.

Thanking you,

Yours faithfully,

RAJESH RAI
CTO MTML

2
 SECTION-1

GLOBAL NOTICE INVITING TENDER

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

Sale of tender docum ent : 14.10.2009

Closing date of sale of tender : 04.11.2009

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

Last date for issuing clarifications : 07.11.2009

Last Date of Subm ission : Up to 15:00 Hrs on 16.11.2009

Date of opening : At 15:30 Hrs on 16.11.2009

-- All timings given above are Mauritius Local tim e.

1. MTML intends to call for global open tender for 200,000 lines of GSM/ 3G (HSPA)
network in two phases in Mauritius as per details below:

Subscriber base 2G 3G Total Remarks

Plus
Phase-I 100,000 - 100,000

Phase-II 50,000 50,000 100,000 Ordering may be done in

any proportion as per
requirement envisaged at
that time.

Total 150,000 50,000 200,000

2. ELIG IBILITY RE QUIRE ME NT FOR VENDO RS:

Please see Clause 3 of section II of RFP.

3. SCOPE:

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

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

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

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

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

For details regarding equipm ent, technical requirem ents & special
conditions/requirem ents please refer to RFP.

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

Intending Bidders m ay download the docum ent from MTML W eb site

www.mtmltd.net or collect the sam e from CFO MTML, Port Louis, Mauritius from
14.10.2009 to 04.11.2009 on all working days on paym ent of USD 1000/- (USD
One thousand only) non-refundable crossed dem and draft/ TT in favour of MTML
Mauritius. Bidders who have downloaded the tender docum ent shall have to
submit non-refundable crossed dem and draft/ TT in favour of
MTML for USD 1000/- along with their bids. In case of failure to subm it the
sam e, the bid will not be accepted.

Sd /-
(Rajesh Rai)
CTO MTML

4
 SECTION - II

INSTRUCTIONS TO BIDDERS

A. 1. INTRODUCTION

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

Subscriber base 2G Plus 3G Total Remarks

Phase-I 100,000 - 100,000

Phase-II 50,000 50,000 100,000 Ordering may be done in

any proportion as per
requirement envisaged at
that time
Total 150,000 50,000 200,000

INSTRUCTIONS TO PARTICIPANTS

1. Introduction

Mahanagar Telephone (Mauritius) Ltd. (hereinafter referred to as “Purchaser”)

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

2. Definitions

a) “The Purchaser” means the Mahanagar Telephone (Mauritius) Ltd(MTML).

b) “The Vendor” means the individual or company who / which participates in
this RFP and submits his / its offer.
c) “The Proposal” or “The Offer” means the offer submitted by the Vendor in
response to the RFP.
d) “The Goods” mean all the equipment, machinery and other materials which
the Vendor is required to supply/provide to the Purchaser under the contract
for commissioning/proper operation of the system and also includes any
spares for the equipment.
e) “Letter of Intent (LOI)” means letter indicating the intention of the Purchaser to
place Purchase Order on the successful Vendor.
f) “The Purchase Order” means the order placed by the Purchaser on the
Contractor duly signed by the Purchaser and includes all attachments and
appendices thereto and all documents incorporated by reference therein. The
purchase order shall be deemed to be the contract, which is defined below.
g) “Contract” means the agreement between the Purchaser and the successful
Vendor

5
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 Agreem ent(s) (if any) as part of the Contract.
i) “The Contract Price” means the price payable to the Contractor under the
purchase order for the complete fulfillment and proper performance of its
contractual obligations to the satisfaction of the Purchaser.
j) “Contract Date” means the date on which the Contract comes into effect.
k) “Certificate of Acceptance” means the certificate issued by the Purchaser to
the Contractor upon completion of the acceptance tests of the
Equipment/W orks.
l) “Progress Report” means the reports prepared by the Contractor containing
details of the progress and implementation of the project as required by the
Purchaser.
m) “Site” means the place(s) other than the Contractor’s premises, to which the
Equipment(s) and System(s) are to be delivered and installed.
n) “Variation Orders” means a written agreem ent entered between the parties
varying the items mentioned in the Schedule of Prices.
o) “W orks” means the jobs undertaken by the Contractor in order to complete
the tasks falling within the scope of the Contract.
p) “Commissioning” means successful completion of acceptance testing
procedures as may be prescribed by the Purchaser and three months of
successful trial operation i.e. stabilization period, thereafter.
q) “Testing” is a process of testing the equipments & services as per the
Requirements as spelt out in various sections of the RFP.

3. Vendors Eligibility Criteria

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

II (i) GSM experience.

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

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

II (ii) WCDMA Experience

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

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

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

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

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

VI The bidder should have a minimum turnover of USD 100 million each in the last two years
(i.e. 2006-07 & 2007-08).The turnover of the parent company in case of a local subsidiary
would be taken into consideration.

4. Cost of Participation in RFP

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

5. RFP Documents

5.1 The goods and services required, RFP procedure and contract terms are
prescribed in the RFP Document. The RFP document include the
following:

S.No. Title Section

1. Notice Inviting Tender (NIT) I
2. Instructions to bidders II
3. General (comm ercial) conditions of contract III
4. (a) Special Conditions of Contract IV-A
4. (b) Detailed Technical Requirem ents IV-B
5. Schedule of Requirem ents V
6. Delivery Schedule VI
7. Price Schedule for Equipm ents VIII Table I
8. Price Schedule for Services VIII Table II

7
 9. Price Schedule for AMC VIII Table III
10. List/ price of Spares VIII Table IV
11. Bid Security Form Annex-I
12. Perform ance Security Guarantee Bond Annex-II
13. Letter of Authorisation for attending Bid Opening Annex-III
14. Manufacturer’s Authorization Form Annex-IV
15. AMC Term s & Conditions Annex-V
16. Existing Network inform ation Annex-VI

5.2 The Vendor is expected to examine all instructions, forms, terms and
specifications in the RFP Documents. Failure to furnish all information
required as per the RFP Documents or submission of offers, which are not
substantially responsive to the RFP Documents in every respect, may result
in rejection of the offer.

In respect of interpretation/clarification of each and every clause of this RFP

and in respect of any matter relating to this RFP, the decision of CEO,MTML
will be final.

6 Clarifications to RFP

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

6.2 Address for communication: Chief Executive Officer, Mahanagar Telephone

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

7 Amendment to RFP Document

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

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

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

7.4 Vendors who have downloaded the tender forms from the web-site are required
to take the amendments issued from time to time from the Purchaser’s web
site www.mtmltd.net .

8 Preparation of the Offers

8.1 Language of Offer

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

8.2 Documents comprising the Offer

The offer prepared by the Vendor shall comprise the following documents:

a) Authorization to the person signing the offer.

b) Documents supporting Vendors eligibility to submit offers as per the

eligibility conditions given in Clause 3 above.

c) Bid Security in format as per Annexure.

d) A Clause by Clause compliance of the goods/services offered with the

various terms & conditions spelt out in the sections II, III, IV, V and VI of
this RFP, along with a separate annexure containing summary of
clauses/specifications not being complied giving detailed reasons.

“Compliant” shall be written against the clauses where the offer meets the
RFP requirements fully. “Non Compliant” shall be written against the
clauses where the offer does not meet the RFP requirements fully. In case
of unclear/ ambiguous statements of compliance for any specified
requirement e.g. “Noted & Understood”, “Noted” etc. shall be taken as
“Non Compliant”. Mere “Compliant” shall also not be sufficient. Reference
to the enclosed documents showing compliances must be given. An offer
without clause-by clause compliance shall not be considered.

e) A copy of price schedule with all relevant tables incorporating all items
without prices. This is to be enclosed with techno-commercial offer and
shall constitute bill of material.

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

g) Documentary evidence of the goods and services in conformity to the RFP

document may be in the form of literature, drawings and data. It may
comprise of:

 A detailed description of the goods with essential technical and

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

 Detailed project implementation schedule covering all the activities of

the work and Bar/Pert Chart.

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

9. Currencies

The prices shall be quoted in US DOLLAR ONLY as provided in Price

Schedule (Section-VII).

10. Prices

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

10.2 Vendors shall quote itemized basic price for each item of equipment. These
may be consolidated as indicated in Price Schedule in Section VII. Separate
Annexure giving the detailed quantity and break-up of prices shall be provided
in support of the consolidated prices arrived in each table of Price Schedule.
The formats are strictly to be complied with while quoting.

10.3 The prices quoted by the Vendor shall remain fixed during the entire period of
contract and shall not be subject to variation on any account. An offer
submitted with an adjustable price quotation will be treated as non-
responsive and rejected.

10.4 The unit prices quoted by the Vendor shall be in sufficient detail to enable the
Purchaser to arrive at prices of equipment/system as offered.

10.5 ‘DISCOUNT’, if any, offered by the Vendor shall not be considered

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

10
10.6 The quoted price shall be all-inclusive and payment of income tax/any other
taxes by recipient of payments under this clause shall not be the responsibility
of the Purchaser either at the time of supply of equipment or at any time
thereafter.

10.7 It shall be mandatory for the Vendors to undertake the work of Annual
maintenance contract (AMC) as detailed in Annexure.

11. Bid Security

11.1 The bid security is required to protect the Purchaser against the risk of
Vendor’s conduct, which would warrant the forfeiture of the security.

11.2 The bid security of US $ 40,000 (US Dollar Fourty thousand only), valid for
180 days shall be submitted in one of the following forms:

a) A Bank Guarantee as per enclosed Proforma at Annexure-I issued by a

First Class Commercial Bank in Mauritius in favour of the Purchaser.
b) Demand draft in favour of Mahanagar Telephone (Mauritius) Ltd payable
at Mauritius.

11.3 In case the security is submitted in the form of a Demand draft, the Purchaser
will be entitled to encash the same. In the case of return of the bid security,
the Vendor shall not be entitled to claim any interests thereon from the
Purchaser.

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

11.5 The bid security of the unsuccessful Vendor will be returned as promptly as
possible and in any event not later than 45 days after the placement of firm
Purchase Order by the Purchaser or on expiry of the offer validity whichever
is earlier.

11.6 The successful Vendor’s bid security will be discharged upon the Vendor’s
acceptance of the Letter of Intent (LOI) and furnishing the performance
security as per Clause 4 of Section III.

11.7 The bid security may be forfeited:

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

b) In the case of a successful Vendor, if the Vendor fails to furnish

performance security in accordance with clause 28.

12. Period of Validity of Offers

12.1 Offer shall remain valid for 180 days after the date of opening prescribed by
the Purchaser. The Purchaser shall reject offers valid for a shorter period, as
non-responsive.

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

13. Format and Signing of Offers

13.1 The Vendor shall prepare Two copies of his offer, clearly marking one as
‘Original Offer’ and the other as copy. In the event of any discrepanc y
between them the ‘Original Offer’ shall govern/prevail.

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

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

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

14. Procedure for Submission of Offers

14.1 Offers along with documents as indicated in clause 8.2 shall be submitted in
the following manner in separately sealed envelopes duly super scribed as
below: -
Part ‘A” - Techno-Commercial Offer
Part “B” - Financial Offer

14.2 Part “A” shall contain, in one envelope, one original and a copy of Techno
Commercial Offer complete with all technical and commercial details along
with unpriced bill of material i.e. copy of the price schedule without mention of
prices.

THE ORIGINAL BID SECURITY OF REQUISITE VALUE MUST BE

ENCLOSED IN A SEPARATE COVER WHICH WILL BE OPENED FIRST.

14.3 Part “B” (Financial Offer) shall contain in, in one envelope, one original and a
copy super scribing on the sealed envelope “Financial Offer”.

14.4 At least original Copy of ‘Techno-Commercial Offer’ and ‘Financial Offer’

should be signed by the Vendor on each page.

15 Sealing and M arkings 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.

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

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

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

15.3 In addition to above, the envelopes shall indicate the name and address of
the Vendor to enable the offer to be returned unopened in case it is received
‘Late’.

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

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

16. Deadline for Submission of Offers

16.1 Offers must be received by the Purchaser at the address specified under
clause 15.2 and not later than the date & time mentioned in section I.

17. Late Offers

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

18. M odifications and Withdrawal of Offers

18.1 The Vendor may modify or withdraw his offer after submission provided that
written notice of the modification or withdrawal is received by the Purchaser
prior to the deadline prescribed for submission of offers.

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

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

18.3 No offer shall be modified subsequent to the deadline for submission of offers.

19. Opening of Offers/ Proposals

19.1 The Purchaser will open Techno-Commercial Offers, in the presence of

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

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

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

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

20. Clarifications from Vendors

To assist in the examination, evaluation and comparison of offers, the

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

21. Evaluation of Techno-Commercial Offers

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

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

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

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

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

21.4 Further examination of only such offers determined to be substantially

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

22. Evaluation of Financial Offers

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

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

14
 the following criteria:

The Net Present Value (NPV) of CIF prices of the equipment & software
quoted by the Vendor for two phases shall be arrived at by discounting the
phase II prices @ 12% and adding it to the phase I price. Any discount which
has been indicated by the Vendor in their price quotes and calculations will be
suitably factored in by the Purchaser while arriving at the final price.

Cost of AMC for a period of three years calculated to present value at a

discount rate of 12% per annum for evaluation. Cost of Spares to be handed
over at the end of three year AMC period shall be discounted @ 12% per
annum as per clause 6 of AMC.

Purchaser has the right to negotiate the prices with the overall lowest quote
Vendor on total quoted package price and make counter offer on the prices
quoted. The negotiations would be on total package price and/ or itemized
prices.

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

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

23. Contacting the Purchaser

23.1 Subject to Clause 18, no Vendor shall try to influence the Purchaser on any
matter relating to its offer, from the time of the offer opening till the time the
contract is awarded.

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

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

23.3 The Purchaser shall in its entire discretion decide on what constitutes
“influence” under this Clause and its decision thereon shall be final and
conclusive.

24. Award of Contract

The Purchaser may consider award of contract for commercial supplies on

that Vendor whose offer has been found technically, commercially and
financially acceptable.

25. Award Criterion

Subject to Clause 27 below, the Purchaser may award the contract to

successful Vendor whose offer has been determined to be substantially
responsive, technically and commercially acceptable and has been

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

26. Purchaser’s Right to Vary quantities

26.1 The Purchaser reserves the right to increase or decrease up to 25% of the
quantity of goods and services specified in the schedule of requirements,
without any change in the unit prices and other terms and conditions as
applicable at the time of award of contract, at its entire discretion.

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

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

27. Purchaser’s Right to Accept any Offer and to Reject any or all Offers:

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

27.2 Purchaser reserves the right to disqualify such Vendor(s) who have a poor
track record of not meeting the contractual obligations, against earlier
contracts either entered into directly with the Purchaser, its
subsidiary/principals/joint venture companies or acquired as a result of the
vendor(s) acquiring interest in other companies.

28. Notification of Award (Issue Of Letter Of Intent)

28.1 Prior to the expiry of the period of offer validity, the Purchaser will notify the
successful Vendor in writing through a Letter of Intent (LoI) by Registered
letter or FAX which will be confirmed in writing by Registered letter.

28.2 Upon the successful Vendor furnishing the Performance Bank Guarantee
pursuant to Clause 4 of General Conditions of Contract (Section-III) and
unconditional/unequivocal acceptance of the LOI, the Purchase Order shall
be issued.

28.3 The issue of purchase order on the receipt of unconditional acceptance of LOI
along with the performance security shall constitute the award of the contract
on the Vendor.

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

29. Signing Of Contract

16
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

W hile all the conditions specified in the RFP Documents are critical and are to
be complied with, special attention of Vendor is invited to the following
clauses of the RFP document, non-compliance of any one of which shall
result in outright rejection of the offer.

(i) Clause 15.1 of Section II-The offers will be recorded/returned

unopened, if covers are not properly sealed
(ii) Clause 11.3 Section II-The offers will be rejected at opening stage if
bid security is not submitted as per Clasuse11.3 and offer validity is
less than the prescribed in Clause 12.1 mentioned above.
(iii) Clause 3 Section II-If the eligibility condition as per clause 3, Section II
is not met and/or the documents prescribed to establish the eligibility
are not enclosed, the offers will be rejected without further evaluation.

17
 (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 W ithin 15 days after the receipt of the LoI, the Vendor shall furnish
Performance Bank Guarantee (PBG) for the sum equal to 12% of the value of
contract price. This guarantee shall be valid for a period of 2 years.

4.2 In the event, guarantee of full value has not been submitted within the
stipulated period, LoI will stand automatically cancelled without any further
reference or notice unless time is extended in writing by CEO, MTML as the
case may be pursuant to the request received from the Vendor prior to expiry
of the period disclosing sufficient reasons for grant of further time.

4.3 The proceeds of the performance security shall be forfeited in favour of the
Purchaser as compensation for any loss resulting from the Contractor’s failure
to complete its obligations under the contract.

4.4 The PBG shall be in the form of a bank guarantee issued by First Class
Commercial Bank in Mauritius and in the form provided in the RFP in
Annexure-II.

4.5 The PBG will be discharged/released by the Purchaser after completion of the
Contractor’s performance obligations on the successful completion of
warranty period, unless there are specific reasons, on record, for not to
release the PBG.

5. Factory Inspection and Acceptance Tests

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

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

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

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

5.1.3 The Contractor shall give a schedule of factory testing and acceptance testing
in field against specifications as indicated in Technical Section indicating the
type of test and duration of test. It shall be the prerogative of Purchaser to
decide on the final test schedule.

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

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

5.1.5 Should any inspected or tested goods fail to conform to the specifications, the
Purchaser may reject them and the Contractor shall either replace the
rejected goods or made all alterations necessary to meet specification
requirements free of cost to the Purchaser.

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

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

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

5.4 W hen 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-

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

5.5 Nothing in this clause shall in any way release the Contractor from any
warranty or other obligations under this contract.

5.6 Inspection and testing shall be as per provisions in the Technical Section
(Section-VI) or as per details finalized between Contractor and Purchaser.

6. Delivery & Warehousing

6.2. The delivery of the equipment shall commence as specified and be completed
within time schedule specified in schedule of requirements and this along with
completion of the turnkey project as per schedule shall be the essence of the
contract.

6.2. The vendor will make his own arrangement for the storage of the goods at
Mauritius. He will transport the goods to the required Site as per the
requirement of the turnkey project at his cost including transportation,
handling charges etc.

6.3 The goods shall remain at the risk of the Contractor until completion of the
turnkey project i.e. issue of ‘Taking Over Certificate”.

7. Training

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

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

7.3 The Contractor shall also deliver 100 man-weeks of on job training to
personnel of the Purchaser in O&M of various systems & sub systems e.g.
MSC, BSC, BTS, High Speed Data Network, IN Services, Billing & Customer
Care System, OSS, RF Network design & Optimization, Microwave, various
infrastructure items like battery, power plant etc.

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

21
8 Warranty

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

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

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

8.4 Replacement under warranty clause shall be made by the Contractor, free of all
charges at site, including freight, insurance and other incidental charges.

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

9.2 (a) Vendor shall ensure the availability of these spares for at least 10
years after successful completion of warranty period.

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

22
 (i) Advance notification to the Purchaser of the pending termination
(not less than 2 years) in sufficient time to permit the Purchaser to
procure needed requirement; and
(ii) Following such advance intimation of termination, furnishing at no
cost to the Purchaser, the blue prints, drawings and specifications
of spare parts, if and when requested.

9.3 AMC shall include supply, repair and a turn around of spares. Transportation
and return of spares shall be borne by the Vendor.

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

10.1 For Equipment Supplies

a) 15% of the total invoice value of goods would be paid on delivery

through LC. This LC will be opened by the purchaser at least two
weeks in advance before the expected date of dispatch. To enable the
purchaser to make the LC, the supplier shall intimate the expected
date of delivery 30 days in advance. For clearing the LC, the following
documents are to be sent to our bankers through whom the LC is
established.
(a) Proforma invoice based on the BOQ
(b) BoQ & Packing List
(c) Certificate of origin
(d) Airway/Bill of lading
(e) Insurance certificate
(f) A copy of manufacturers guarantee certificate
(g) A copy of the contractor’s factory inspection certificate.

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

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

one year is over.

10.2 For Services

a) 80% paym ent after successful installation, Acceptance testing and

commissioning of the system and issuance of “Taking Over
Certificate”.
b) Balance 20% paym ent 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.

23
11 Change in Orders
11.1 The Purchaser may, at any time, by a written order to the Contractor, make
changes within the general scope of the contract, without affecting the
delivery schedule, in any one or more of the following:

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

under the contract are to be specifically manufactured for the
Purchaser;
b) The method of transportation or packing;
c) The place of delivery.

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

12 Sub-Contracts

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

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

12.2 The Contractor shall notify the Purchaser in writing of all sub contracts
awarded under this contract if not already specified in his offer. Such
notification, in his original offer or later shall not relieve the Contractor from
any liability or obligation under the contract.

13 Delays in the Contractor’s Performance

13.1 Deliveries of the goods and performance of services shall be made by the
Contractor in accordance with the time schedule specified by the Purchaser in
its purchase order.

13.2 Delay by the Contractor in the performance of its delivery obligations, shall
render the Contractor liable to any or all of the following sanctions; forfeiture
of its PBG, imposition of liquidated damages and/or termination of the
contract for default.

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

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

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

15 Liquidated Damage

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

15.2 (a) For delivery of Stores:

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

15.2 (b) Installation & Commissioning:

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

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

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

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

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

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

16. Insurance

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

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

Any item/part damage / lost shall be replaced by the Contractor free of charge
at first and the insurance claim shall be made by the Contractor to recover the
cost of damaged/ lost goods.

The insurance policy shall remain valid till the date of issuance of Taking Over
Certificate.

17. Force M ajeure

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

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

18. Termination for Default

18.1 The Purchaser may, without prejudice to any other remedy for breach of
contract, by written notice of default, sent to the Contractor, terminate this
contract in whole or in part,

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

the time period(s) specified in the Contract, or any extension thereof
granted by the Purchaser pursuant to Clause 13.3.
b) if the Contractor fails to perform any obligation(s) under the Contract;
and
c) if the Contractor, in either of the above circumstances, does not
remedy his failure within a period of 30 days (or such longer period as
the Purchaser may authorize in writing) after receipt of the default
notice from the Purchaser.

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

19. Termination for Insolvency

The Purchaser may at any time terminate the contract by giving written notic e
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

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

21. Subject Laws and Jurisdiction

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

22. Set Off

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

It is an agreed term of the contract that the sum of money so appropriated

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

23. Notices

23.1 Any notice given by one party to the other pursuant to the contract shall be
sent in writing or by FAX or cable and confirmed in writing, by registered post.
For the purposes of this Clause, the contact details of the Purchaser shall be
as follows:

Mahanagar Telephone (Mauritius) Ltd

Attention of: Mr. Sanjay Garg
30, Dr Eugene Laurent Str, Port Louis, Mauritius. Fax: (230)-2940606

23.2 The Purchaser shall notify the Contractor in accordance with Clause 23.1
above in case of any amendment of the contact details specified in the said
Clause 23.1.

23.3 The Contractor shall similarly notify the Purchaser of its contact details and any
subsequent amendment thereto in accordance with Clauses 23.1 and 23.2.

23.4 A notice shall be effective when delivered or on the notice’s effective date,
whichever is later.

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

29
 SECTION –IV (A)

SPECIAL CONDITIONS OF CONTRACT

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

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

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

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

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

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

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

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

7. Any clarification issued by the purchaser in response to query raised by prospective

bidders shall form an integral part of bid documents and it will amount to amendment of
relevant clauses of the bid docum ents.

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

9. AWARD CRITERIA:

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

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

(b) Purchaser requires that bidder shall quote for com plete bill of m aterial and all
other item s of cost for com plete scope of work, m eeting fully and complet ely the
tendered technical specification for total dem and as given in Section -V and Section-
VII. Any deficiency in bill of m aterial, Hardware, software or other item s of cost will
be provided by the bidder free of cost for successful implem entation of the project.
In case bidder has not quoted for som e of the item s which are essential for
turnkey solution, it will be presum ed that cost of such item s is covered and is part of
som e other subsystem and no extra am ount is payable by purchaser. In the
evaluation of bids, cost of such item shall be taken as ‘nil’ while the same shall be
m ade available to purchaser as per requirem ent without any additional cost. The
successful bidder will be required to supply all m aterial/goods required to m ake the
equipm ent operative, after integrating with the existing network (even if it is not shown
in the Bill of Material).

10. The existing network is based on CDMA 1x EVDO architecture provided by M/s Huawei
Technologies and consists of one MSC, HLR, IN, SMSC, VMS, BSC and 51 BTSs which
are being expanded to 56 BTSs. In addition to this, a parallel BSS network is planned to
be installed by M/s ZTE Corp for EVDO Rev A services, wherein 51/56 new BTSs
(distributed architecture) are being provided alongwith one BSC, PDSN & AAA. The
backbone connectivity is through Microwave links of NEC. The GSM/3G network being
envisaged through this RFP is to planned taking into consideration the existing network so
as to utilize the available resources to the extent possible to minimize the cost. The bidder
has to study the existing network carefully before submitting the bid. All arrangements for
providing any solution for utilizing the available resources at the best possible manner (like
extending tower height for putting additional antenna or increasing the power plant
capacity etc.) will have to be made by the successful bidder at his cost, thus the bid should
be prepared accordingly.
11. It is planned to have one common core network, including billing & customer care for both
GSM & CDMA. This would require provisioning of more capacity in core network elements
to accommodate 110k CDMA lines. The migration of the data from CDMA HLR, IN, SMSC,
Billing etc to the new common network elements will have to be done and would be the
responsibility of the successful bidder. After having common core, it should be possible to
have the existing CDMA mobile number opened as GSM number. The common billing
system will generate one bill for a customer having CDMA mobile, fixed and GSM
connections. For purpose of implementing common core, the vendor can either
expand/upgrade the existing network elements or provide the new ones and integrate with
the existing ones to have one seemless network or replace the existing ones with the new
elements.
12. The bidder should confirm that all its supplied equipments and interfaces are compliant to
international standards including but not limited to 3GPP, ITU, IEEE and are capable to
interconnect with other vendors’ equipments like those of Ericssion, Nokia-Siemens,
Alcatel-Lucent, Huawei & ZTE. The successful bidder shall commit to provide full support
for any inter-working with other vendors as and when it is required by the purchaser,
without any additional charges atleast till AMC period.
13. For the purpose of understanding in this RFP, existing 51/56 BTS sites would be called
‘MTML sites’ where infrastructure is available. The additional sites required in the GSM/
3G network will be referred as ‘New Sites’.
14. Purchaser will be allocated a bandwidth of 5MHz (continuous) in P-GSM band (890-915
MHz). The network should be designed keeping this in view. For future expansions,
Purchaser may get additional bandwidth either in E-GSM or in 1800 MHz band and 3G
spectrum in 2100 Mhz band. The system provided now should be capable of handling
these frequency bands.

31
15. It is estimated that a minimum of 110 BTSs would be required to provide the desired
coverage in Phase I and a total of 150 in Phase II. However, the bidder is required to carry
out its own RF planning to ensure the coverage and capacity requirement fulfillment as per
RFP conditions, and quote accordingly. If the bidder estimate is for more number of BTSs,
the same should be clearly indicated and quoted for the same. But if the estimate is for
lees than the estimated numbers, the bidder has to quote for 110/ 150 BTSs only, as
estimated. The responsibility to provide the desired coverage is solely of the bidder and if
the coverage is not met, the bidder would be required to provide additional BTSs free of
cost to meet the requirement.
16. The supply shall include complete 2G & 3G equipment including all essential elements
like MSC servers, Media gateways, HLR, VLR, AUC, EIR, BTS and Node Bs (or
equivalent for HSPA), SCP, OMC, IN system, SMSC, MMS, CBC, GPRS, EDGE, LBS, roof
top and ground based towers, antennae, feeder cables, power cables, fixtures and
accessories, testing and m easuring instrum ents, P ower Plant and battery etc. as a
com plete package. Additional antenna fixtures, W aveguide (feeder cable) racks
(horizontal and vertical), gantry, platforms with hand rails for the new and existing
towers, wherever required, shall be provided by the bidder as per the actual
requirem ents. All such items which are to be deployed in outdoor conditions shall be
m ade of galvanized iron m aterial. The complete network planning, engineering &
optimization of the equipment and transmission equipment shall be the responsibility of
the successful bidder. The successful bidder shall also be responsible for tuning &
optimization of the equipment for entire warranty, AMC period and also during
expansions.

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

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

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

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

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

20. The purchaser shall provide the space, com m ercial AC m ains pow er supply and air
conditioning at existing MTML sites fo r installation of various com ponents of
equipm ent. The bidders shall indicate the space and pow er required for each
equipm ent like MSC SERVER, MEDIA GATEW AY, HLR, SCP, OMC, OSS, BSC/RNC,

32
 BTS/Node B, GPR S, MMS, LBS, Battery, Power Plant, Roof top Tow er, Ground based
tow er etc. AC/DC voltage stabilizers, Inverters and UPS together with adequate
battery backup, Runw ays, cables & cabletrays, w herever required shall be th e
responsibility of the bidder. The bidder has to arrange supply & installation of
PCM cable/Tie cable, DDF term inations & Junper wires etc in respect of all
netw ork elem ents. The bidder shall arrange for extension of DC power supply, AC power
supply, earthing etc from the existing available points at MTML sites to the equipments.

21. Information regarding the existing MTML sites is available at Annex. The same may be
utilized to the extent feasible for the purpose of design, simulation, coverage prediction
and finally implem entation.

22. The civil / electrical w orks for installation of BTS/Roof top/Ground based Tow ers
etc. at all sites shall be executed by the bidder as part of the project and in
conform ity with guidelines in vogue in MTML/ local authorities. It will be th e
responsibility of the successful bidder to obtain the structural safety certificates
from the ag encies nom inated by the local authorities which includes standard
seism ic, wind load considerations. All statutory perm issions & “No Objection
Certificate” from local agencies like Municipal bodies, ICTA, Defence authorities etc.
and site owners shall be responsibility of the successful bidder. However the
charges payable to governm ent bodies shall be borne by MTML on production of
proof of paym ent by the successful bidder.

23. For those BTS sites for which no suitable site belonging to purchaser is available,
the bidders shall indicate at least three alternate candidate sites so that th e
purchaser m ay take action for its acquisition. In case three such suitable sites
are not available, MT ML w ould consider lesser num ber also after due
verifications. The successful bidder shall arrange to get electricity con nection of
suitable capacity for BTSs proposed to be located on these sites in the name of MTML
from the concern ed authorities. Any coordination with the agencies in this regard
shall be the responsibility of the bidder. The paym ent to agencies shall be
reim bursed by MTML and prior approval of expenditure shall be taken from MTML for
such paym ents.

24. All New Sites (the new sites other than existing MTML sites) shall be with outdoor
BTS and with pole/ roof top/ Ground B ased Towers. The outdoor BTS cabinet shall be
water/ dust prrof and should have arrangement for proper cooling and atleast 4 hour
battery backup. The arrangem ent should also be possible to have 8 hrs battery backu p
wherever required by MTML. For this purpose, unit cost of additional battery bank in
outdoor cabinet should be quoted in the bid. The outdoor BTS cabinet should be stron g
enough and should be firmly fitted into the foundation base, so as to protect it from
theft. No additional shelter/ air conditioners would be required in case of outdoor BTSs.

25. There is no need to provide DG sets for backup power at any of the sites. To meet th e
requirem ent of major power breakdown, a total of four (4) m obile DG sets of atleast
15KVA capacity, duly installed at mobile trollies and with sufficiently long power cables
are required to be provided.

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

27. The responsibility of obtaining clearance from various authorities for construction of
towers (RTT or GBT) on behalf of the purchaser shall entirely rest with the bidder.

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

28. The earthing arrangement at each BTS site/tower, both existing and new, including tower
earthing in all MTM L and New sites shall be the bidder's responsibility. However at MTML
existing sites, existing earthing can also be used subject to technical feasibility. It shall be
ensured that each site is provided with the necessary surge protection as required.
Necessary corrective actions including supply and installation of required devices will have
to be done by the bidder to ensure that the site is fully and comprehensively protected
against all kinds of high voltage and lightning hazards.

29. Radio network planning

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

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

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

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

d ) The bidder shall be fully responsible to make preliminary RF survey to monitor

specific RF interference from any other sources such as other mobile operators in the
entire service area and furnish the details along with the recommended remedial
action.

e) For W CDMA RF perform ance, the receive signal levels and interference
requirem ents i.e. m inimum Eb/No, under UMTS m obility m odel shall be
ensured by the bidder. The average Ec/Io of the network shall be greater
than –15dB for the pilot.

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

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

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

33. The bidder shall furnish the details about make, m odel no., supplier and the cost of each
item separately. The bidder shall quote for only one m ake, model and manufacturer for
each of the network elem ents. O nce quoted in the bid, no change of m ake, m odel or
m anufacturer shall ordinarily, be perm itted. Not m ore than one independent and
com plete offer shall be perm itted from the bidder.

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

34
 limits of delivery schedule by sourcing these items from more than one source. How ever,
for ordering purposes, low er of the tw o prices for these options shall be used w hile for
evaluation higher of the tw o shall be considered. All third party equipm ent should b e
of proven technology and supported by docum ents for its successful operation of
sim ilar or higher configuration for m inim um one year in any other netw ork.

35. The Numbering schem e for the proposed service shall be in accordance with approved
numbering plan. Any changes, including those in software, required in the network due to
changes in the technical, licencing and / or regulatory environment shall be implemented by
the successful bidder free of cost during the life span of equipment. It is mentioned that
presently 7 digit numbering is available which is likely to be changed to 8 digit in future which
should be implemented by bidder as and when required to do so, without any extra charge.
36. The bidder shall ensure that the bid is complete and comprehensive as regards detailed card
level BoM. The bidders shall provide unpriced Bill of Materials (BoM) for each of the network
elements with complete details of PC Bs contained in each M odule/unit together with their
quantity required to meet the performance requirement sought for in the tender in the Techno-
Commercial bid. The detailed specification of generic items such as laptop and desktop
computers, Printers, inverters, UPS etc shall form part of the Techno-Commercial bid.
37. The bidders shall furnish detailed project im plem entation schedule by means of PERT
chart in the bid detailing the various activities involved, their tim e fram e for com pletion and
the dependency on other activities. The bidder shall be responsible for arranging all the
clearances for commercial launch of service.
38. Lawful interception and monitoring facility as per 3GPP Release 4, TS 33.106 & TS 33.107
for voice, SMS, MMS, data shall be provided. The facility for m onitoring shall have to be
provided for at least four independent agencies for sim ultaneous m onitoring. The system
shall provide perform ance monitoring of mobile calls/numbers through call conferencing
facility to any m obile/PS TN/CDMA telephone. The system shall be capable of m onitorin g
100 mobile calls/num bers sim ultaneously through call conferencing facility at any tim e in
the network. The system should also be capable to provide online call details such as date,
time, call duration, IMSI no., IMEI no., cell ID, calling & called no., etc. The system should be
capable to monitor SMS Data and provide the SMS details. The system shall be capable of
converting raw SMS data / details into readable text form at as per requirem ent of
m onitoring agencies.
39. The Equipm ent Identity Register (EIR) shall be provided as part of the core netw ork
and shall have the provisions for gray list/ black list for tracing/ blocking calls from the
lost m obile phones in the netw ork. The EIR m ay be required to interact with the EIR s
of other GSM operator netw orks for taking data of lost m obiles in the w hole country.
40. All software licenses like IN, VoMS etc. shall be in the name of MTML allowing for m ulti users
and for unlimited period.
41. In case of long duration calls, an automatic alert should be generated along with LOG and the
duration of long calls should be configurable.

42. SOFTWARE

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

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

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

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

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

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

43. ACCEPTANCE TESTING

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

(a) Check on cabling and wiring.

(b) Functional test for various network elements.

(c) Functional test on individual equipm ent/netw ork.

(d) Coverage and capacity test

(e) traffic trials.

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

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

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

44. PACKAGE DISCIPLINE:

The bidders as part of their bid, shall indicate the sequence of supply of various item s
to appropriately take care the different lead tim es required for comm issioning of th e
individual network elem ents. The successful bidder shall schedule his supplies to
ensure com pletion of installation, testing, validation and comm issioning as per
schedule.

45. Supply/Installation/Commissioning:
The comm encem ent of Supply and Installation of the system s should start within 2
m onths of placem ent of P.O. for Phase-I and commissioning of Phase-I equipm ent
should be com pleted within 10 m onths of placem ent of Purchase Order. The

36
 m onth-wise schedule for com pletion of supply, installation commissioning shall be
as follows:

Sl. From the Date % of Installation & Rem arks

of P.O Commissioning
No
th
1 End of 6 40 % All core netw ork elements and BTSs at exiting MTML
month sites should be commissioned.
th
2 End of 8 80 % 75% of the New site BTSs, BCCS, Value added
month services should be comm issioned.
th
3 End of 10 100 % Com pletion of the project including m igration of IN,
month HLR, B&CCS and other items w herever required.

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

Non-adherence to Installation & Commissioning as detailed above shall invite LD

charges as per the Clause 17, Section –III.
46. Operation and Maintenance: The successful bidder shall carry out all the functions
of operation and m aintenance during the first 3 m onths of comm ercial launch of the
Phase-I equipm ent. The successful bidder shall fully associate the staff of MTML during
this period so that they are able to operate & m aintain independently. During this period,
the successful bidder shall put into operation the set of m aintenance procedures, periodic
test schedules, Traffic Report generation & analysis and rem edial measures to be taken if
required, Extraction of perform ance statistics from the various OMCs and other network
elements, Statistics regarding in-roamers and out-roam ers in various form ats and
classification as required by the purchaser, M anagem ent Information System (MIS)
parameters for fault, performance and planning of network expansion. The successful
bidder shall also help MTML to put into practice maintenance schedules viz opening of
appropriate registers for log, test schedule and performance and fault recording.
47. All the network elem ents and software units supplied for the system shall be fully
downward com patible with the existing system and inter work seamlessly without any
limitation.
48. Technical audit of system Performance
MTML reserves the right to carry out technical audit of the network through any
designated agency from tim e to tim e and bidder shall take necessary corrective
m easures to conform to the perform ance param eters stipulated in the tender
docum ent within the period of perform ance guarantee.
49. Annual Maintenance Contract-
a) The bidders shall quote for a year wise com prehensive A nnual Maintenance
contract for 3 years. MTML will have the discretion whether to sign the AMC
contract or not for each year separately. The AMC for 1 st year is to be signed at
the end of warranty period and then for each year separately. The cost shall be
quoted as a lum p sum including visit of the engineers as and when required.
The term s and conditions for AMC are given in Annexure.
b) During the warranty period, the successful bidder shall perform all the functions
as enunciated under the AMC, free of cost. All the penalty clauses shall be
applicable during the period of warranty in case of failure on part of supplier.
c) The bidder shall, at the tim e of subm itting the bid, also subm it the proposal
specifying the Fault Control Center Location and how the bidder proposes for
carrying out repair under AMC. The bidder shall also indicate what spare will be
kept in different locations. The infrastructure planned to be created by the
bidder to m eet his obligations under AMC and his action plan to deal with the

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

50. General Points:

(a) The advantage of reduction of taxes/ duties during evaluation of tender /
execution of contract shall be passed on to the purchser i.e. MTML and no
benefit of increase will be perm itted to the supplier.
(b) The equipm ent envisaged in this tender shall be capable of supporting IP
version –6 (IPv6) as and when required.
(c) The purchaser reserves the right to comm ercially exploit the installed
equipm ents after the delivery linked paym ent are m ade as indicated in paym ent
term s or after the prescribed period stipulated for the initial roll out to
comm ence whichever is earlier. Such comm ercial utilization of the network
after the com pletion of the prescribed delivery schedule and before
commissioning of the network shall not entail the successful bidder to claim
deem ed com pletion or otherwise incom plete obligations under the term s and
conditions of this tender and shall not relieve bidder of the liability under the
relevant clauses arising out of such non-com pletion.

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

 Roam ing Frauds-National/International

 SIM card duplicate and cloning
 Detection of Organised fraudsters
 Call volum e/duration frauds
 Detection over packet services
 Subscription frauds
 Abnorm al behaviour
The system shall ensure apart from detection and m onitoring of ab ove frauds,need
to provide m anagem ent reports and also should be configurable in the field to
ensure defining rule based detection.system should be upgradable to m anage new
and evolving fraud m ethods.The fraud m anagem ent and detection and detection
shall be in near real tim e basis.

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

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

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

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

54. Push M ail Service: The system should provide Push E-Mail functionality
wherein the mails received on customer’s email id are pushed to his
mobile phone if the service is subscribed.

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

56. Upgradation to HSPA: W hich is normally planned for Phase II expansion in

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

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

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

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

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

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

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

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

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

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

40
 SECTION –IV (B)

DETAILED TECHNICAL REQUIREMENTS

1. INTRODUCTION

Mahanagar Telephone (Mauritius) Limited (MTML) presently operating on

CDMA 2000 1x EVDO Technology dimensioned for 110K lines supplied by
M/s Huawei with 51 BTS sites (being expanded to 56 BTSs) operational over
the Main island since 2005. The existing NSS and BSS element details
along with present MW setup are available in Annexure. In addition to this, a
parrel BSS network is being installed by M/s ZTE for EVDO Rev A services.

MTML has decided to establish GSM based subscriber access network with
200K lines along with HSPA in two phases and Main Switching System which
should support national as well as international gateway functionalities.

2. Coverage and Capacity requirements:

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

2.1 Phase – I is planned for 100K of GSM with GPRS & EDGE network all over
the main island. The network elements should be HSPA enabled. The
network is to be designed with 1.5 BHCA and 25 Milli Erlang per subscriber.
However, the system shall be capable of configuring for more number of
subscribers subject to the limitation of the total erlangs traffic and total BHCA,
whichever is achieved earlier without any other limitation.

2.2 In Phase – II, the entire service area of Mauritius main island is to be
provided with full HSPA coverage. Additional capacity of 100K will be ordered
in any proportion of 2G and 3G lines depending on the actual subscriber
growth and market conditions. However for the purpose of tender evaluation,
50k HSPA addition will be considered for Phase-II. The HSPA shall be an
overlay to the GSM network. The network should have seamless handover
between 2G to 3G and vice versa for service continuity for both voice & data.

The system should be able to support the transmission of BSC – BTS

interface over satellite for the BTSs to be located in the remote and
inaccessible areas places like islands. Further, these BTSs are also
compatible to work on E1 links on DCME. BSC should also have facility to
interface with E1 links, with or without DCME, on satellite media.

The network should support handover of the voice calls and data calls in
progress, when the subscriber moves from one BTS to other. The voice calls
and data calls should not get disconnected even if the subscriber moves at
the speed of 120 Kmph.

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

41
 CDMA BTS sites and propose the additional BTS sites required to meet the
coverage requirements as per the RFP.

The vendor shall provide suitable solution (Micro BTSs/Repeaters) for

covering the Black-Spots. The maximum number of Micro BTSs/Repeaters
shall be limited to 20% of the total number of BTSs.

The vendor shall provide complete GSM+HSPA system including hardware &
software. The vendor shall also provide detail description regarding its
capacity and capability expansion. All the BTSs shall be expandable to
minimum 6TRX per sector without any hardware addition under same
frequency band.

3. SPECTRUM :

a. For the proposed 2G/ 3G network, the spectrum available is 5 MHz

(continuous) in 900 MHz band. In addition, for launching 3G services, initially
one 5 MHz HSPA carrier may be assumed in 2100 MHz band as per
HSDPA/HSPA specifications.

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

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

4. ENGINEERING & PLANNING OF THE NETWORK

4.1 The complete network survey, design, planning, engineering, supply,

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

4.2 Design parameters:

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

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

iii. Common Core network for GSM and HSPA.

iv. MSC server with media gateway

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

versa for service continuity for both voice & data.

4.3 Following would be the subscriber distribution:

Voice Subscribers 100%

Data Subscribers

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

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

Voice Calls
BHCA per subscriber 1.5
Average Call Duration 60 sec.
Traffic per subscriber 25 mE
Packet Data Calls
Busy Hour active mode per subscriber 0.8
Peak data rate a)HSDPA -7.2Mbps
DL/ 300Kbps UL
b)HSPA-7.2Mbps
DL/1.75Mbps UL
c)GPRS-144 kbps
d)EDGE-384 kbps

Average Call (Session)Duration 300 sec.

Simultaneous data users 10% of data
subscribers

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

MSC to PSTN 0.1%

MSC to MSC (to other 0.1%
nw)
MSC – BSC 0.1%
BSC – BTS 0.1%
BTS – RS 2%

4.6 Call performance parameters

Call Set up time <6sec.

Call Set up success >98%
Call Drop Rate <1%
Data call Success Rate >90%

4.7 Call Mix may be taken as follows:

(a) W ith in our GSM Network : 15%

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

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

4.9 Radio Design Parameters

S.No. Parameters Value

1. Frequency Band of Operation 5 MHz bandwidth in 900
MHz Band.
2. Number of Sectors Generally 3 sectors will
be used. However, for
specific requirements
such as road coverage
etc. 1 or 2 sector BTSs
may be used.
3. Penetration Loss
Dense Urban (>6 storied bldgs) 24dB
Urban (2 – 6 storied bldgs) 20dB
Sub urban ( 2 storied bldgs) 15dB
Rural/ In car ( 1 storied bldgs) 10dB
4. Cell Loading Percentage 70%
5. BTS antenna gain >=17 dBi
6. Desired hand-off percentage 35%
7. Desired cell area coverage 95%

4.10 The vendor shall submit detailed link calculations in support of his meeting of
coverage,Microwave & other RF requirements.

4.11 The network envisaged is a hybrid of GSM & HSPA. Data users shall be both
type. A data subscriber when visits a cell without HSPA shall get data access
through GPRS/EDGE. Handing off of data calls from GPRS/EDGE to
HSDPA/HSPA cell and vice versa shall be without disconnection of the call.

4.12 Each call shall carry full CLI through out the network.

4.13 RF Coverage Requirements

Mauritius is a group of islands consisting of one mainland island, one main

satellite island (Rodrigues) & other small satellite islands. Total main island
area is about 1850 sq. kms. Mauritius has wet humid tropical weather with
rains almost through out the year and temperature varies from 10 to 34o C. In
Mauritius, the population density is very high of the order of over 600
inhabitants per sq. kms and the Coverage objective under this RFP is to cover
the main island only. Mauritius is a tourist destination and a large number of
tourist visit this country every year.

Coverage objective is to cover all residential areas, Business Centers,

Industrial Areas, Shopping Centers, Cyber City, Race Course, Stadiums,
Exhibition Ground, Airport, Hotels, Beaches & Tourist Places, National High
W ay (Motorway), Main Roads, Coastline Roads, Secondary & regularly
maintained Roads. The vendor may propose BTS repeaters/ Micro BTSs or
other solutions for providing indoor coverage.

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

S.No. Name of Municipalities Earlang Traffic

1. Port Louis
i. Down Town (Main Business Center) 700
ii. Residential Urban 262
iii. Residential Sub Urban 88
iv. Industrial 105
2. Rose Hill & Beau Bassin 350
3. Quatre Bornes 300
4. Vacoas & Phoenix 420
5. Curepipe 350

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

4.14 RANGE OF SERVICES

1 Voice Voice Calls and emergency Calls

2 Data Services:
Circuit Switched a. Asynchronous Data (14.4 Kbps)

b. Group-3 FAX Services, to be supported

on the network for the following:
i. Fax machine to Fax machine
ii. Fax machine to PC
iii. Fax machine to PC and
iv. PC to Fax machine

Packet Switched GPRS/EDGE

High Speed Data Services (HSDPA/HSPA)
3 PCO Provisioning 16 KHz and Polarity Reversal for home
metering for at least 2% of the subscribers.

4.15 Supplementary Services:

In addition to the services listed in above table, the following features /

functions and supplementary will also be provided:

a) Voice Messaging Service/ Short Message Service/ Multi Media Service

(MMS) as per 3GPP standard.

 It shall be possible to deliver a short message to a subscriber terminal

even if the terminal is engaged in a call.

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

b) Call forwarding ( for 100% subscribers):

 Basic Remote call Forwarding

 Call Forwarding Unconditional (CFU),
 Call Forwarding W hen Busy (CFB)
 Call Forwarding when No Answer or Not Available(CFNA)
 Call Forwarding on call W aiting
 User Selective Call forwarding

c) Calling Number ID presentation (CNIP) – (100% subscribers)

d) Calling Number ID Restriction (CNIR) – (100% subscribers)
e) Call Transfer (CT) – (100% subscribers)
f) Call W aiting (CW ) – (100% subscribers)
g) Call Hold (CH) – (100% subscribers)
h) Three way calling– (10% subscribers)
i) Closed User group (CUG)
j) ISDN inter-working services (As per 3GPP )
k) Distinctive ringing
m) Support of Position Location Service
This service provides for the transfer of position location data between
the RS and the Network {3GPP Standard}

n) Prepaid Service (PP) for data :

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

0) Auto provisioning of Data subscribers:

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

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

v) Call Hunting Facility– (5% subscribers)

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

GPRS/EDGE

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

5.0 ENVIRONM ENTAL CONDITIONS

5.1 Ambient conditions are as follows:

Temperature -5 to + 50 degrees Centigrade

Relative Humidity Maximum 99%
Thunderstorms 60 thunderstorms days / year of intensity 10
KV/m of duration 6 to 10 micro sec (1000
strikes per year).
Dust Filtration Total dust contents is less than 0.05
mg/cubic meter (with 95% of the dust
content less than 5 microns)
W ind Velocity During Cyclones up to 320 km/hr

5.2 The vendor shall furnish the necessary graphs, table or charts depicting the
tolerance capacities of their equipment with respect to various environmental
parameters like temperature, humidity HSL & wind velocity etc.

The bidders shall furnish the calculations of the link budget mentioning
various assumptions, if any, and shall submit the detailed engineering to
arrive the BTS count for coverage requirements of the tender mentioning
values of following parameters considered for design.

Service type Uplink

Thermal noise power density dBm/Hz
Noise figure dB
Eb/No dB
User rate Bps
RBS Sensitivity dBm
UL Loading %
Interference margin dB
Mobile station output power dBm
Mobile station antenna gain dBi
Soft handover gain uplink dB
Power control margin dB
Body Loss dB
Building penetration loss dB
Car penetration loss dB
BS Antenna gain dB
Feeder loss dB
Jumper and connector loss dB
Duplexer loss dB
Diplexer loss dB
Uplink polarization loss (Slant) dB
LNF margin dB
Maximum path loss dB
BS antenna height m
MS antenna height m

47
 Maximum range (as per propogation Km
model used)
Site-to-site distance Km
Any other parameter

6.0 TECHNICAL SPECIFICATIONS

6.1 M SC based Core network for GSM & HSPA System

6.1.1 Introduction

This document lists the technical requirements for a Softswitch

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

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

6.1.2 This target architecture of core network will meet the following high level
requirements, which the vendor’s solution will have to support:
a) The proposed Circuit Switched Domain System shall be in Split
Architecture as defined by 3GPP in Release 4 and Release 5.
b) The Bidder shall describe how its Circuit Switched products can be
mapped on the reference architecture defined by 3GPP in Release 4/R5
(23.002, and 23.205 for layered architecture).
c) The proposed Circuit Switched Domain System shall simultaneously
support UTRAN (3G) and GERAN (2G) accesses. The Vendor should
explain how the resources are shared between UTRAN and GERAN

48
 access.
d) The proposed system, Mobile Softswitch, must be a mature commercial
system.
e) The supplier will give an overview description of his 3GPP R4 solution,
with layered architecture for Circuit Core Network (VMSC server, GMSC
server, TMSC Server, MGW, and HLR/AUC) in order to fill functionalities
such as Control Service Function (CSF), gateway functional node, transit
function, VLR, gsmSSF, Signaling Gateway (SG), Bearer Control
Function (BCF), Bearer Interworking Function (BIW F).
f) The Vendor shall depict all protocol layers for each supported interfac e
and provide statement about compliancy with relevant 3GPP standards
or other standards (RFC, ITU-T, IEEE) for each protocol layer.
g) The Proposed CS products shall have large capacity with high density in
order to save the Carrier’s CAPEX and OPEX. Furthermore, the CS
products shall be modularized designed and have reasonable flexibility
for the future capacity expansion.
h) The proposed CS core network shall support the carrier network based
on TDM and IP. From Carrier’s Perspective, IP should be chosen as
preference, and the common IP/MPLS backbone should be used for
transport of control & user plane.

6.1.3 Signaling & Bearer transmission

a) The proposed CS solution shall support all IP networking, including Nb

over IP, Nc over IP, Mc over IP, MAP over IP, CAP over IP, IU over IP, A
over IP and etc.
b) MSC Server shall support BICC to interwork with other MSC Servers,
support SIP to interconnect with fixed network.
c) The proposed Mobile Softswitch Based Core Network shall support TDM
and IP based transport network. Considering the aspects of technique
maturity, service capability, future development and investment
protection, Carrier prefer to choose IP/MPLS as the transport network.
The Vendor should support the QoS solutions for CS on IP transport,
such as MPLS, DiffServ, VPN, IP CAC, TrFO, MGW based QoS
enhanced function and etc.
d) The proposed Circuit Switched system shall provide dual-pane
mechanism to guarantees IP network reliability and must support to use
BFD and IP FRR to realize fast switchover.
e) The proposed Circuit Switched System shall provide redundancy backup
mechanisms for both IP interface board and interfaces on IP board. The
vendor should state the detailed mechanisms.

49
 f) The Bidder shall indicate if and when SS7 over IP is supported specifying
the protocol stack over the involved nodes. The Bidder shall indicate if
this functionality requires additional dedicated hardware. The proposed
CS system shall support at least M3UA/SCTP/IP stack as defined in TS
29.202.
g) The proposed Circuit Switched CS System shall support
M3UA/M2UA/SCTP/IP protocol stack to support legacy BSC connecting
(for legacy BSC does not support M3UA networking)
h) Nb interface shall support both IP and TDM simultaneously to make the
network smoothly evolve to all IP solution.
i) ATM based Iu-cs interface (STM-1 preferred) is the current mandatory
requirement, but the option for medium to long term evolution to IP based
Iu-cs (with Fast Ethernet or preferably Gigabit Ethernet interfaces on
RNC and MGW ) should be supported.
j) The proposed Circuit Switched CS System shall also support IP based A
interface to save the TC resource and to realize 2G/3G resource
completely shared

6.1.4 Compliance with 3GPP specifications

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

a) The Proposed Circuit Switched System shall support at least two types of
external clock reference:
i. Providing 2MHz or 2Mbit/s incoming clock source through BITS
ii. Providing 2MHz incoming clock source through E1 line.
b) The proposed Circuit Switched System shall support internal clock output
interface. The Vendor is requested to describe the mechanism.
c) The provided timing synchronization shall meet the requirements of ITU-
T Recommendation G.812.
d) The proposed Circuit Switched shall provide at least Stratum 2 clocks.
e) The proposed Circuit Switched system shall support NTP (Network Tim e
Protocol), and the NTP server shall be provided.
6.1.6 Interworking

a) The Vendor shall be responsible for integration of the proposed CS core

network entities to the other entities in the core network, the entities in

50
 the radio access network and service platforms of CARRIER including
the Billing and Provisioning System.
b) In order to avoid upgrade of the GSM, reduce the investment for the
initial network deployment, unidirectional handover form UMTS to GSM in
CS domain shall be supported. The Vendor shall describe the
interworking mechanism.
c) The Vendor shall describe interworking between UMTS and legacy
GSM/R99 network and PSTN/ISDN networks.
6.1.7 Roadmap

a) The Vendor should mention the roadmap forecasted of the platform

proposed and specify the procedure to meet the 3G technology and
future requirements and indicate whether the upgrades are software only
or require hardware changes.

6.1.8 The core network will be common for planned GSM/ HSPA network. The
Core Network shall be based on 3GPP standards.This Core Network shall
be required to work with the Radio Network (RN) and the Packet Core
Network.

The core network shall comprise of MSC servers, Media gateways,

HLR/AC, Equipment Identity Register (EIR) and Operation & Maintenance
Centre and shall be compliant to various 3GPP standards.

6.1.9 The functions and features of MSC based core network can be
categorized into the following main functional areas: -

(a) Call processing

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

Call Processing: This refers to the steps required in the MSC to set up
and release wireless calls. Basic Call Processing functions include
Remote Station Origination and Remote Station Termination call set up, as
well as Call Clearing Scenarios initiated by the Remote Station, the BSC
and the MSC. This functional area also includes the call failure scenarios
such as timer expiration and unsuccessful resource allocation.

M obility M anagement: These procedures are needed to manage the

registration and access status of individual Remote Station subscribers.
These procedures include management of Mobile parameters such as
Mobile location, Mobile identity, and authentication status in the Visitor
Location Register (VLR) and Home Location Register (HLR). Through
mobility management, wireless subscribers can roam freely within a
network and across networks. Mobile Management Functions also include

51
 Authentication which is a technique used to ensure the security and
privacy of wireless Mobile subscribers in a network.

Supplementary Services: These are wireless subscriber features that

provide capabilities other than basic voice and data services. Over-the-Air
Service Provisioning (OTASP) and other services as detailed in the
chapter on ‘Range of Services’.

Radio Resource M anagement: This refers to allocating radio channels

for both voice and data traffic. This function includes the managem ent of
hand-offs within a BSC, between BSCs and across MSCs.

Terrestrial Facility M anagement: This is the function in the MSC that

manages the terrestrial signaling links, routes and voice circuit resources.

6.1.10 Network Architecture: Following are the various components of the MSC
based Core Network:

M SC/VLR: MSC (Mobile Switching Center) is responsible for call

establishment, route selection, call control, radio resource allocation,
mobility management, location registration and channel handoff in
switching areas. In addition, it generates bill information, coordinates
services between it and the PSTN. VLR (Visitor Location Register) acts as
a dynamic database and stores the temporary information (all data
necessary to set up call connections) about the users roaming to the local
MSC area.

HLR/AUC/EIR: HLR (Home Location Register) is responsible for storing

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

Operations and M aintenance Centre (OM C): The Operations and

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

6.2. M SC SERVER :

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

52
 (i) MSC or STP should have GTT capacity and its SCCP accounting for
interoperator bill settlement for international roaming.
(ii) MSC should support multi SP feature and high link toward STP.
(iii) MSC should be able to generate hot bills for 1% of total subscriber
capacity.
(iv) MSC should support selective optimal routing feature.
(v) MSC should support A party analysis in case of routing feature.
(vi) GMSC/MSC/IN should have USSD call back feature.

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

6.2.1 General Requirements

6.2.1.1 Hardware and software design

a) The MSC Server/VLR proposed shall conform to all relevant ETSI GSM
and 3GPP Release 4, Release 5 specifications. The Vendor shall list and
give compliance statements to relevant ETSI GSM and 3GPP
specifications for the support of GSM and UMTS circuit switched services
and the integration with GPRS and UMTS packet domain networks.
b) The HW platform of proposed MSC Server shall be the common and
mature platform which can be used in NGN, W CDMA/GSM core
networks.
c) The system architecture of MSC Server shall be designed as
modularization, and can be expanded flexibly by cascading.
d) The Vendor shall provide detailed description of HW /SW design and
architecture of MSC Server/VLR. Main requirements include:
a) System Architecture.
b) Operation and Maintenance.
c) Electromagnetic Compatibility Specifications.
d) External Interface Specification.
e) General block layout and functional layout.
f) Description the way how the system works, e.g. centralized,
distribute or hierarchical control, incorporation of I/O devices, ports
and buses, distribution of timing and management functions.
g) Figures of offered HW.
h) List of all racks, cabinets, cartridges, modules, units, cards, I/O
devices, interfaces, power supply units, synchronization and clock

53
 units, etc. the network node consists of. Description of their function
in details and possible impact on service if the certain unit fails.
i) Redundancy. W hat redundancy principles are used for backing up a
particular unit, e.g. hot-standby, cold standby, N+1, 2N, which
units/modules/cards are/aren’t hot swappable, how does the unit
switchover affect the system performance, are there any necessary
restarts to activate backup unit? W hich units/modules/cards in the
entity are not redundant? How their outage impacts services?
j) Explanation of the concept and redundancy of power supply for
both a whole network node and individual components.
k) The hardware (card, module, unit, I/O device, etc.)MTBF per board
shall be at least 15 years. If not compliant specify in detail.
l) Please provide parameters of system load as following:
 Start up time since the entity is powered on until full operation
(all units are fully loaded and processes traffic), state it for
minimum and maximum configuration.
 Shut down time since the command for shutdown has been
issued in full operation until the time you can power off the
device safely or it starts booting.
 Reboot time for each kind of restart, e.g. total cold restart, warm
restart, entity/partial/unit/card restart. Please describe also their
impact on service (currently opened sessions, incoming and
outgoing session requests) and differences.
6.2.1.2 Interface description and characteristics

a) The offered MSC Server shall provide abundant open standard

interfaces. This implies that the Vendor shall share all necessary
information with other vendors when inter-operation is required in
CARRIER’s network. Any deviations from this rule shall be explicitly
stated by the vendor for each network entity and interfaces described in
this RFP.
b) The network elements shall provide UMTS/GSM relevant interfaces as
specified in 3GPP standards. The Vendor shall depict all protocol layers
for each supported interface and provide statement about compliancy
with relevant 3GPP standards or other standards (RFC, ITU-T, IEEE) for
each protocol layer.
c) The Vendor shall provide information and specifications on any
proprietary protocols or protocol elements used on the interfaces of the
proposed MSC Server.
d) The interface between MSC Server and SCP shall base on CAMEL
phase3 and be backward compatible with CAMEL phase2.

54
 e) The Vendor shall describe number of logical links/connections possible
per one interface and whole entity, recommended/maximum load of
interface that can be processed by interface unit,
recommended/maximum load of fully configured entity.
f) Signaling system No.7
a) The link that transports SS7 signaling shall be capable of being
inserted in any time slot (other than time slot 0) of a 2 Mbit/s link.
The capability shall also exist for more than one signaling link to be
carried within one 2 Mbit/s link.
b) The Vendor shall describe redundancy techniques for the SS7 links,
terminals and destination routes.
c) The Vendor shall describe the load sharing mechanisms provided
between signaling links in a linkset, between signaling linksets and
between signaling routes.
d) The Vendor shall also state what overload mechanisms are
available.
e) The MSC Server shall support at least ISUP v2 according to ITU-T
Recommendations Q.761 – Q.764 (03/93) modified by ETS 300
356-1 (February 1995).
f) The MSC Server shall support SIGTRAN protocol group:
 The MSC Server shall support SCTP according to RFC 2960.
 The MSC Server shall support M2UA according to RFC 3331.
 The MSC Server shall support M3UA according to RFC 3332.
g) The MSC Server shall support BICC protocol according to ITU-T
Recommendation Q.1902. The BICC message can be transferred over IP
transport network. The relevant protocol stack shall be BICC/SCTP/IP
and BICC/M3UA/SCTP/IP.
h) The MSC Server, together with MGW, shall provide A interface to support
GSM networking and MGW shall support SIGTRAN to work as Signaling
Gateway to transfer the A interface signaling.
i) The Mc interface protocol of MSC Server shall be H.248, in order to
promote the efficiency of message transfer; the relevant protocol stack
shall be H.248/SCTP/IP and H.248/M3UA/SCTP/IP.
j) The MSC Server shall support Multi-signaling-point (Multi-SP) function to
enable large-capacity offices to break the limitation of Signaling System
No. 7. The maximum number of SP supported shall be up to 16.
k) The MSC Server shall support SCTP multi-homing to ensure the
reliability of IP based signaling interface.
6.2.1.3 Functionality and Feature Requirements of the M SC Server/VLR

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

55
 mobility management, Connection Management and service provision
functions as specified in the relevant ETSI GSM and 3GPP release 4
standards.
b) The MSC Server shall support the VMSC Server, GMSC Server and
TMSC Server functionality.
c) The VMSC Serve’s in CARRIER’s network shall contain the VLR
functionality.
d) The MSC Server/VLR shall include integrated SSP functionality in order
to interwork with external SCP. The signaling shall be based on CAMEL
phase 3 and compatible with previous phases to provide abundant
CAMEL services. The SSP in the MSC Server /VLR shall be able to
interwork with SCP from other vendors.
e) The MSC Server shall support Color Ring Back Tone functionality which
is implemented based on CAMEL 4. Especially ICA and ML operations
shall be supported.
f) The Vendor shall support the handling of emergency calls and state
compliance with the relevant ETSI GSM, 3GPP standards and the local
regulations.
g) The Core network shall support video telephony service for mobile
stations supporting H.324M. If the calling party originates an
unsuccessful VP call, a “USSD” will be returned immediately. Because
the call originated by calling party is video one, it is impossible to play
announcement directly, so the system should send a “USSD” message to
notify the subscriber the release reason once the call is not connected.
h) The Core network shall support the unique identification of video
telephony calls in CDRs.
i) The MSC Server shall support TrFO control function in order to improve
the quality of speech as well as reduce the equipment investment of
Transcoder.
j) The MSC Server shall support TFO-TrFO interworking.
k) The MSC Server shall provide overload mechanisms on all interfaces and
internal systems that allows overload to occur without causing
performance degradation or failure. The Vendor’s MSC Server will
provide maintenance information that shows where overload occurred
and the resultant impact. Mechanisms for load control and overload
protection shall be stated.
l) The MSC Server shall support enhanced roaming restriction function
which is based on the Zone Code, location area, roaming type and IMSI
of current roaming subscriber to implement flexible roaming restriction.
m) The MSC Server shall support allocating roaming number based on
location area cell or MSC ID.

56
 n) The MSC Server shall support announcement based on IMSI function to
let operators set an announcement language according to the IMSI of
international roaming subscribers. International roaming subscribers can
listen to alert tones in their native languages.
o) The MSC Server shall support the testing of a designated tones function
to realize the fast availability test of the MGW and physical paths such as
A-interface circuit and trunk circuit without blocking the other paths or
circuits.
p) The MSC Server shall support the automatic routing of incomplete call
function to reroute un-completed call to a preset number, such as voice
mailbox, according to failure causes.
q) The MSC Server shall support the redundancy transmission in data
services / Fax to provide a reliable transport mechanism for data services
/ Fax over IP bearer.
r) The system should support MNP. The Mobile Number Portability (MNP)
allows Universal Mobile Telecommunications System (UMTS) or GSM
mobile subscribers to change the subscription networks within a country,
and to preserve the original MSISDNs at the same time. All the services
of the subscriber are provided by the new network. They are not affected
by the original network. The new network also assigns a new
International Mobile Subscriber Identity (IMSI) to the MNP subscriber.
s) The MSC Server shall support Hybrid IP and TDM Networking and
support both Load-sharing mode and Sequence mode for those two
bearer. This function makes it possible to migrate from TDM to IP
smoothly.
t) The MSC Server shall support Single MSISDN with Multiple IMSI(SIM
card).
u) The MSC Server shall support ICA (Intelligent Call Assistant) Service. By
using ICA service, roam er from other country can use same dial method
or dial some special number as in it’s HPLMN. For example, roamer from
Germany, they can dial Germany subscriber with same dial method in
Germany. SCP will convert the short number to international number
format with INT prefix(00) and return to MSC, MSC analyzes the
converted number and route out.
v) The MSC Server shall support check IMEI service.

6.2.1.4 Networking Capability

a) The MSC Server/VLR shall support UMTS R4 and R5 networking.

b) The MSC Server/VLR shall support integrated GSM/UMTS networking. It
can access GSM and UMTS radio access network simultaneously.

57
 c) The MSC Server/VLR shall support dual-homing solution for MSC Server
redundancy function. One MGW can connect to 2 MSC Servers; these
MSC Servers are working in backup or mutual work mode. W hen one
server has an accident, the other server controls the bearing equipment
immediately.
d) The MSC Server/VLR shall support Mini-flex solution for MGW
redundancy function. One RNC/BSC can connect to multiple MGW s
controlled by a MSC Server.
e) The MSC Server/VLR shall support the function of multi-MGW
networking. Speech path connecting between MGW s must support IP
and TDM bearers.
f) The MSC Server/VLR shall support service based handover and load
based handover

6.2.1.5 Performance, capacity and connectivity

a) The proposed MSC Server shall have large capacity (>= 1 million subs),
high performance.
b) The Vendor shall give a description about physical and logical network
element connectivity for minimum configuration.
c) The vendor is requested to fill the table of the following information for
MSC Server:
Parameter Specification
Maximum number of subscribers
BHCA VMSC Server
GMSC Server
TMSC Server
Number of (64 kbit/s)
SS7 (2 Mbit/s)
signaling
links
Supported SPC type
Maximum number of originating
signaling points
Maximum number of destination
signaling points
Maximum number of IP (FE)
interfaces
Maximum number of E1 interfaces
(carrying narrow-band SS7)
Maximum number of controllable
MGW s
Maximum number of controllable
RNCs
Maximum number of controllable
BSCs

58
 Bill storage capacity
Bill processing capability
Clock stratum
6.2.1.6 Evolution Path and Characters

a) The Vender shall describe all necessary hardware and software changes
associated with migration of the network element Release 4 to network
element fully compliant with 3GPP Release 5/6.
b) The Vender shall describe upgrade procedure and describe out of service
phases. Required modification of cooperating systems shall be stated.
c) Is it possible to migrate to 3GPP Release 5 network only via software
upgrades? W hat is the performance impact of such upgrade? And will be
possible use all R5/R6 features or is necessary to make any additional
HW upgrades?
d) The Vendor shall describe the roadmap for this, including the integration
and inter-working with the packet domain core network and ancillary
network nodes.
6.2.1.7 O&M

a) The vendor shall provide Operation and Maintenance system for MSC
Server with customized man-machine interface to offer fault
management, configuration management, alarm management,
performance measurement and security management.
b) The MSC Server O&M system can not only be controlled through the
local console, but also be managed by EMS in a centralized way by
accessing the local maintenance center of EMS.
c) The MSC Server O&M system shall support the following functions:
d) Configuration Management:
The data configuration and database management function is
used to add, delete, modify or query the configuration data
necessary for system operation, as well as managing the
database necessary in keeping the data consistent between host
system and BAM, and in data backup.
The data configuration of the MSC Server O&M system which is
based on database management shall provide the following
functions:
i. Offline and online data configuration
ii. Remote and local data configuration
iii. Data backup and restoration
iv. Online upgrade
v. Data verification.
e) Fault Management
Fault management function helps you check, locate and fix the
MSC Server system faults during its operation. In addition, useful

59
 tools are available for routine maintenance of the system and
against the occurrence of faults. Fault management includes the
following items:
i. System self-test
ii. Alarm management
iii. Maintenance management.
f) Trace Management
Tracing management of the MSC Server offers graphic interface.
It checks data and removes faults by tracing the
interface/signaling messages.
Tracing management of the MSC Server shall support the
functions as follows:
i. Providing message tracing of standard interfaces, such as A,
C/D/E/G, Gs, Iu-CS, CAP, Mc, and Nc.
ii. The MSC/VLR shall support the feature of Specify subscriber
identifier (such as MSISDN or IMSI number) at centralized network
management system for tracing. All network elements (NE) replicate
subscriber call messages and output them to centralized network
management console. After resolution, centralized network
management console displays resolution information to facilitate
locating problems of whole call process Tracing messages of a
designated signaling, like MTP3, MTP3B, TCAP, SCCP, BICC and
H.248.
iii. Message explaining, that is, offering detailed descriptions of the
messages of the interface/signaling traced.
iv. On/Off-line tracing retrieval, that is, saving the result of the
message tracing to the O&M console for further use, which is
accessible through either on-line query (by logging in to the local
O&M system) or offline query.
g) Security Management
The MSC Server system supports multiple users. For the purpose
of security and convenience, the system shall support authority
management and log management.
i. Authority Management
The authority of operators and workstations is under the
hierarchical management. In the O&M system of MSC Server, the
execution of a MML command is subject to two conditions: the
authority of the operator and the authority of the workstation. The
command cannot be executed if any of these conditions is not
satisfied.
ii. Log management
It enables the querying of MML operation records. By querying the
operation log, you can specify any operation has been conducted
to endanger the normal operation of the system.

6.2.1.8 Standards Compliant & M ulti-Vendor Support: System shall be

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

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

6.2.1.10 The MSC based Core Network shall support Radio Network (Base
Station Controller & Base Transceiver Station) systems based on GSM &
HSDPA/HSPA standards.

6.2.1.11 Dimensioning: The equipment supplier shall provide engineering

rules/guidelines for dimensioning the capacity of the network components.

6.2.1.12 The system shall optionally allow voice (or circuit data service) and packet
data service to operate concurrently (within the limits of the air interface
system capacity).

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

6.2.1.14 The system shall have the capability to support all the registration methods
specified in GSM standards. Pooling of resources such as vocoders, Echo
cancellers etc. shall be there.

6.2.1.15 The system shall support the architecture of the GSM & HSDPA/HSPA
system in terms of different layers for specific functions conforming to the
following 3GPP standards:

- Physical layer - C.S0002

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

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

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

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

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

6.2.3 Quality Requirements

6.2.3.1 Redundancy: The Power Supply as well as the control equipment in the
case of all components of the Core Network including the OMC shall be
provided with 1+1 hot standby mode redundancy. Any other redundancy
provided shall be indicated by the equipment supplier. The redundancy
provided shall ensure reliability of 99.99%.

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

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

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

(i) Time to connect Mobile to Mobile call: The total time for a mobile to
mobile call origination shall be less that 10 seconds for 90% of calls
with the system running at rated capacity. This is the time from when
the originating subscriber hits the SEND until the time that the
terminating mobile receives the alert.

(ii) Time to connect Mobile to Fixed (PSTN) call: The call setup delay for a
mobile to land call shall not exceed 5.0 seconds for 90% of calls with
the system running at rated capacity. This is defined as the time period
from processing the SEND button to out pulse complete.

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

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

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

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

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

6.2.4 Operational Requirements

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

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

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

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

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

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

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

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

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

The CDRs generated by MSC/ MSCs shall be based on industry

open standards and it shall be ensured that CDRs from MSC/ MSCs are
fully compatible to the proposed Billing & Customer Care system
(B&CCS). The MSC CDR shall be output to the Billing System on real-time
basis to facilitate hot billing. The vendor shall fully describe the CDR
format and required interfaces, that the MTML will pass to its B&CCS to
ensure that the systems are compatible. The vendor shall clearly explain
the CDR record format and will contain, at least following information.
a. originating MSC scenario
b. Serving MSC scenario.
c. Location ID
d. record sequence number
e. block number
f. record type
g. calling number
h. calling number (MSN)
i. dialed number
j. called number (call forwarded number)
k. start date and time (DD:MM:YYYY:HH:MM:SS)
l. duration (HH:MM:SS)
m. charge units/pulse
n. incoming trunk group identity
o. outgoing trunk group identity
p. calling party category
q. called party category
r. supplementary services
s. channel number
t. bearer service
u. message service
v. additional service, (if any)

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

IARA (Inter Administration Revenue Accounting): The MSC shall have

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

63
 for end user billing as well as inter carrier accounting details.

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

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

CIBER as specified in ANSI-41D, shall be supported.

6.2.4.4 Hand-off: The action of switching a call in progress i.e. hand-off from one
sector to another sector of same or adjacent BTS of same or different
BSCs of same MSC or different MSCs of same PDSN or different PDSN
shall be automatic and smooth without the user noticing it. Continuous
control of call quality shall be maintained automatically to get the optimum
transmission quality.

6.2.4.5 Supervision: Supervision of complete network shall be both automatic

and operator controlled and centralized at OMC.

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

6.2.4.7 Fraud M anagement: The system shall be capable of prohibiting the us e

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

6.2.4.8 Security: The system shall provide confidentiality, subscriber

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

6.2.4.9 Announcements/ Prompts: Provision shall be available for

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

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

Electronic device with recording facility shall be provided in the MSC. The
announcement device record at least 100 messages each of 20 seconds
long. It shall be possible to connect the announcement message for an
operator defined time or indefinitely. It shall also be possible to deliver
messages of longer duration.

The announcement device will be working in 1+1 active and standby

configuration. If the main unit fails, the standby unit shall automatically
switch over to active mode. The vendors shall indicate the details about
how many subscribers can hear the message simultaneously.

The announcement device shall be provided with recording, storing and

playback facility. The recording facility shall include microphone, audio
storing facilities and distribution facilities and medium (disk, tape etc.) so
that recorded announcement can be transferred to several announcement
machines without multiple recordings.

6.2.4.10 Synchronization: The system shall have integrated synchronization

equipment with a layer 2 clock, i.e. with a minimum clock stability of 1x10 -
10
per day. The acceptable slip rate shall be in accordance with ITU-T
Recommendation G.822.

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

6.2.4.12 The equipment supplier shall provide detailed information regarding extent
of implementation in his equipment, to support international roaming w.r.t.
all issues related to International Roaming, such as numbering issues,
dialing issues, signaling issues, Fraud issues, Billing issues, Services
issues and other miscellaneous issues, as per standards.

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

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

6.2.4.14 The MSC/VLR shall support the following functions besides the
conventional functions provided for switching equipment.

(A) Call processing

65
 (i) MSC shall support outgoing call, incoming call, and transit call. It shall
process outgoing call and incoming call for all legal subscribers within
its covering area, and provide corresponding services for each
subscriber as per user profile in HLR.
(ii) It shall be able to provide functionality of Gateway MSC (GMSC).
(iii) It shall be able to provide functionality of Mobile tandem.
(iv) In case of TAX call connection, MSC shall be able to provide calling
number and calling number attribute to TAX or other MSC.
(v) It shall be able to provide functionality of STP.
(vi) In addition to normal switching function, the MSC shall provide
Integrated Service Switching Point (SSP) functionality for supporting
the Intelligent Network (IN) services.
(vii) It shall support malicious call tracing.
(viii) It shall play voice announcements in case of user busy, user
unreachable etc. It shall be able to provide up to 100 voice
announcements.
(ix) It shall support access to various service station/desk, capable of
choosing the nearest emergency call center to connect.
(x) It shall be able to perform DTMF signal conversion.
(xi) It shall support Either Party release.
(xii) It shall automatically perform number upgrading (increasing the
number of digits of MDN).
(xiii) It shall support Call admission feature for overload control.

(B) Number storing and translation

(i) Receiving and storing up to 24 digits.

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

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

(D) Route selection functions

(i) It shall be possible that the number of trunk routes and the number of
circuits of each route can be assigned according to the requirements and
can be changed by man-machine commands.
(ii) MSC shall have capability of selecting direct routes or alternative routes
and avoiding circuitous route.
(iii) It shall have capability to analyze up to 24digits of number and then
decide the route selection.

(E) Echo cancellation: It shall provide Echo cancellation for calls to/from
PSTN. It shall control the access of echo canceller and indicate the
subsequent exchanges to access the echo canceller or not.

66
 (F) Overload control functions: The system shall have capability to detect
following overload conditions and apply overload mechanism:

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

(ii) Internal overload control: The system shall provide overload control by
means of man-machine commands with an adjustable controlling rate.

(G) M obility management functions: M SC shall be able to support the

following types of handoff:
 Inter BSC soft handoff within a MSC.
 Inter BSC hard handoff within a MSC.
 Hard handoff between different MSC (including inter carrier handoff
between MSCs supplied by different vendors)
 Soft hand-off intra-BSC

(H) Registration

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

cases as specified in GSM standards.
(ii) It shall support domestic and international automatic roaming for
subscribers using equipment of various vendors. Roaming shall not
affect the services provided to subscribers.
(iii) W hen a Mobile subscriber appears in a new location area, or when a
registration, call setup or supplementary service operation message is
received from the Mobile, the system shall send a registration
notification to the HLR.
(iv) It shall be possible that if a subscriber does not appear in the
MSC/VLR area within 24 hours or as required by HLR, the VLR can
delete the data pertinent to this subscriber, and notify the HLR.
(v) It shall have provision for time based registration. W hen related timer
expires, no registration and call processing shall be possible for this RS
and VLR shall perform de-registration for this RS.
(vi) MSC shall give an alarm when ‘unknown subscriber’ or ‘illegal
subscriber’ appears in the registration message. It shall also print out a
report & maintain a log for errors such as “authorization denied”.
(vii) MSC shall be able to support Mobile inactive function.

(I) Security and authentication: The following features are applicable in

case of integrated HLR only:

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

supplementary service processing.
(ii) The possible occasions for authentication implementation in CDMA
system are as follows:
- Registration
- RS origination
- SSD (shared secret data) update

67
 - RS termination
- Data burst
(iii) The authentication algorithm is authentication part of Cellular
Authentication and Voice Enciphering (CAVE), Enhanced Cellular
Message Encryption Algorithm (ECMEA) / Encapsulating Security
Payload (ESP) / Advanced Encryption Standard (AES)
(iv) If MSC receives some error such as ‘deny access’, MSC shall print out
a report & maintain a log of such errors.
(v) Subscriber information encryption shall be provided.

(J) Resource management: MSC shall have following features:

(i) Responsible for assigning selected circuit time slots between BSC and
MSC.
(ii) Indicating the type of wireless channel suited for different processing
phases to Radio Network(RN)
(iii) Receiving and processing RN blocking-circuit, RN resetting-circuit
messages.
(iv) Sending resetting-circuit message to RN.
(v) Receiving and processing resetting message.
(vi) Sending resetting message to RN.

6.2.4.15 Numbering Requirements

a) The system shall adhere to the latest local numbering requirements. At

present, seven digit numbering scheme is applicable for both mobile &
fixed telephones which is likely to be upgraded to 8 digits in near future.
As such system should be flexible for adopting any number digit length in
any format as per international standards applicable.

6.2.4.16 Inter Working Facility (IWF)

 The vendor shall provide the feature interactions when a mobile is in
circuit switched data mode e.g. availability of call waiting, voice mail
notification etc.
 V.42 compression should to be supported for more efficient use of the
RF links.
 Both RS originated and terminated calls for asynchronous data and Fax
services shall be supported .

6.3 M EDIA GATEWAY

i) Media Gateways shall comply with 3GPP standards and should support all
international signaling standards so that the international calls and SMSs are
successful.

ii) Standalone signaling gateway shall be provisioned.

ii) The bill of materials provisioned by the bidder shall provide full flexibility in
determination of price model for any mix of 2G and 3G subscribers. The
same shall be utilized by MTML while ordering equipment for Phase-I & II.

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

iv) Media Gateway shall have an integrated announcement server supporting

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

a) The MGW in CARRIER’s combined UMTS/GSM network shall conform to all

relevant ETSI GSM and 3GPP release 4, Release 5 specifications. The
Vendor shall list and give compliance statements to relevant ETSI GSM and
3GPP specifications for the support of GSM and UMTS circuit switched
services and the integration with GPRS and UMTS packet domain networks.
b) The HW platform of proposed MGW shall be the common and mature
platform which can be used in NGN, W CDMA/GSM core networks.
c) The system architecture of MGW shall be designed as modularization, and
can be expanded flexibly by cascading.
d) The Vendor shall provide detailed description of HW /SW design and
architecture of MGW. Main requirements include:
i. System Architecture
ii. Operation and Maintenance
iii. Electromagnetic Compatibility Specifications
iv. External Interface Specification
v. General block layout and functional layout.
vi. Description the way how the system works, e.g. centralized, distribute
or hierarchical control, incorporation of I/O devices, ports and buses,
distribution of timing and management functions.
vii. Figures of offered HW.
viii. List of all racks, cabinets, cartridges, modules, units, cards, I/O
devices, interfaces, power supply units, synchronization and timing
units, etc. the network node consists of. Description of their function in
details and possible impact on service if the certain unit fails.
ix. Redundancy. W hat redundancy principles are used for backing up a
particular unit, e.g. hot-standby, cold standby, N+1, 2N, which
units/modules/cards are/aren’t hot swappable, how does the unit
switchover affect the system performance, are there any necessary
restarts to activate backup unit? W hich units/modules/cards in the
entity do not have redundancy? How their outage impacts services?
x. Description of typical layout of racks, cabinets, cartridges, modules,
units, cards, I/O devices, interfaces, power supply units,
synchronization and timing units, etc.
xi. Explanation of the concept and redundancy of power supply for both a
whole network node and individual components.
xii. MTBF characteristics for each hardware component (card, module,
unit, I/O device, etc.).

69
 xiii. Please give us those parameters:

 Start up time since the entity is powered on until full operation (all units
are fully loaded and processes traffic), state it for minimum and
maximum configuration.
 Shut down time since the command for shutdown has been issued in
full operation until the time you can power off the device safely or it
starts booting.
 Reboot time for each kind of restart, e.g. total cold restart, warm restart,
entity/partial/unit/card restart. Please describe also their impact on
service (currently opened sessions, incoming and outgoing session
requests) and differences.

xiv.Description of software architecture in terms of running OS (operating

system) and running SW modules and packages.
xv. Description of software upgrade procedure and correction (patch)
installation. Is it necessary to replace whole running package or only
certain pieces of software may be upgraded/patched?
xvi.How is the node configuration and hardware setup stored? Is there any
centralized configuration file or are there multiple files to save it? Is
there any choice to select configuration file/files during booting up the
node if there are archive configuration files stored in I/O device?
xvii. How is the software fallback created? How long does the procedure
take? Is fallback only for the whole node or it is possible to perform
fallback per unit/module/card?

e) The proposed MGW shall be GSM/UMTS converged, packet processing

unit based on Network Processor, TDM switching shall be native without
TDM to IP conversion in order to reduce the delay and jitter for GSM
TDM switching.
6.3.2 Interface description and characteristics

a) The offered MGW shall provide open standard interfaces. This implies
that the Vendor shall share all necessary information with other vendors
when inter-operation is required in CARRIER’s network. Any deviations
from this rule shall be explicitly stated by the Vendor for each network
entity and interfaces described in this RFP.
b) The network elements shall provide UMTS/GSM relevant interfaces as
specified below. The Vendor shall depict all protocol layers for each
supported interface and provide statement about compliancy with
relevant 3GPP standards or other standards (RFC, ITU-T, IEEE) for each
protocol layer.

Interfac Connected Singal and Bear Physical

e entitie Protocol Type Port

70
 Iu-CS MGW —RNC IP FE/GE

MGW -MSC
Mc IP FE/GE
Server

Nb MGW —MGW IP FE/GE

Nb UP MGW —MGW IP FE/GE

A MGW -BSC IP FE/GE
MGW -
ISUP TDM E1/STM-1
PLMN/PSTN
PRA MGW -PBX IP/TDM FE/E1

c) The Vendor shall provide information and specifications on any

proprietary protocols or protocol elements used on the interfaces of the
proposed MGW.
d) The vendor shall provide UMTS relevant interfaces as specified in 3G TS
23.002. The vendor shall depict all protocol layers for each supported
interface and provide statement about compliancy with relevant 3GPP
standards or other standards (RFC, ITU-T, IEEE) for each protocol layer.
e) The Mc interface shall comply with 3GPP TS 29.232 and the stack shall
be H.248/SCTP/IP.
f) The proposed MGW shall provide ATM over E1 function in Iu-CS
interface.
g) The MGW shall support Nb interface over IP and TDM. The vendor shall
state the protocol stacks of each type of bearer.
h) The MGW shall support Multi-signaling-point (Multi-SP) function to enable
large-capacity offices to break the limitation of Signaling System No. 7.
i) The proposed MGW shall support ATM cross-connection using for Iu-PS
transport from RNC to SGSN through MGW.
j) The proposed MGW shall support ATM cross-connection using for Iur
transport between two RNCs through MGW.
k) The MGW shall provide FE and GE for Nb interface, the GE based Nb
interface shall work on the load-sharing mode to lower the risk of peak
traffic.
l) The MGW shall support SIGTRAN, including M2UA, IUA, M3UA
(including both transfer mode and agent mode), to network flexibly.
6.3.3 Functionality and Feature Requirements of the M GW

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

71
 ii. Serving as the bearer device in a UMTS R4 network
iii. Networking as IM-MGW in IMS domain

b) In the event of A interface ,The transcoders in the proposed MGW shall

support the following GSM codec:
i. GSM FR - GSM Full Rate (13.0 kbit/s)
ii. GSM EFR - GSM Enhanced Full Rate (12.2 kbit/s)
iii. FR AMR - Full Rate Adaptive Multi-Rate
iv. HR AMR - Half Rate Adaptive Multi-Rate

c) In the event of PSTN interface, The transcoders in the proposed MGW

shall support the following codec:
i. G.711 ц-law and A-law (64 kbit/s)
ii. G.723 (5.3 kbit/s)
iii. G.726 (40,32,24,16 kbit/s)
iv. G.729 (8 kbit/s)

d) The transcoders in the proposed MGW shall support all the 8 types of
rates range form 4.75kbps to 12.2k bps of AMR, AMR2 and W B-AMR.
e) The core network shall support fax bearer service. Fax services are
applied in the GSM or the UMTS network, including automatic fax and
alternative voice/fax service. They allow category-3 facsimile apparatus
to connect with the mobile station (MS) of the GSM PLMN, and to set up
fax connection between the PSTN/ISDN and the GSM PLMN or within
the GSM PLMN.
f) In the proposed MGW, appropriate measures for overload protection
have to be implemented. The measures shall guarantee a satisfactory
performance of the network entities in an overload case.
g) The core network shall support TFO (Tandem Free Operation). The TFO
implementation shall support the EFR, AMR and FR codec.
h) The core network shall support TrFO (Transcoder Free Operation). The
vendor shall state in detail how it is implemented in the proposed MGW.
i) The core network shall support TFO-TrFO interworking. The vendor shall
state in detail how it is implemented in the proposed MGW.
j) The proposed MGW shall support Voice enhancement function voice
quality promotion ,e.g. EC(Echo Canceller or Control), AEC(Acoustic
Echo Control), VAD, BNR, CNG, DJB, EFC, GC, LPC and NS.
k) The MGW shall support Embedded Signalling Gateway function which
supports MTP3b-M3UA, MTP2- M2UA and MTP3-M3UA adaptation and
forwarding
l) The MGW shall support the H.248.11 overload control protocol and the
H.248.10 congestion control protocol to realize the self overload

72
 protection function.
m) The MGW shall support RTP header multiplex which is defined in ITU-T
G.769 and Y.1242.
n) The MGW shall support DTMF over IP function which is based on RFC
2833.
6.3.4 Networking Capability

a) The proposed MGW shall support UMTS R4 and R5 networking.

b) The proposed MGW can work as VMSC, GMSC and TMSC in GSM and
UMTS network.
c) The proposed MGW shall support integrated GSM/UMTS networking. It
can access GSM and UMTS radio access network simultaneously.
d) The proposed MGW shall support Nb interface based on IP bearing as
required by the actual transmission network in the following scenarios,
and provide FE、GE、POS hardware interface.
i. Acting as 2G TMSC, MGW supports G.711, G.723, G.726, G.729 and
AMR over IP.
ii. Acting as 2G VMSC, MGW supports G.711 and AMR over IP.
iii. Acting as 3G V/GMSC, MGW supports G.711, AMR and AMR2 over
IP.
iv. Acting as 2G/3G G/TMSC, MGW supports that identifying and
converting 3.1 K audio speech to AMR/AMR2 over IP.

e) The proposed MGW shall support adapting satellite transmission at Mc

and Nb interface. This feature enhances the networking flexibility of
MGW. And it enables MGW to fit various geographical environments and
cover a long distance.
f) The interface for SS7 over IP can be dedicated FE interface or be
together with the IP-based Nb interfaces, such as FE, GE, STM-1 POS or
STM-4 POS. It has no constraints on the use of node interfaces. The
interface for SS7 over IP implements 1+1 backup configuration.
6.3.5 Performance, capacity and connectivity

a) The proposed MGW shall have large capacity (>= 70k Erl) and abundant
of interfaces.
b) The Vendor shall give a description about physical and logical network
element connectivity for minimum configuration.
c) The vendor is requested to fill the following information for MGW :

Physical
Interface Type Number of Ports
interface
E1
TDM
STM-1

73
 E1
ATM
STM-1
FE
GE
IP POS 155M
POS 622M

6.3.6 Evolution Path and Characters

a) The proposed Media Gateway shall comply with the 3GPP R4 and shall
be able to migrate to release 5 and 6 by re-utilization of the existing
platform. In case of additional Hardware and Software being required for
migration to release 5 and 6, the vendor shall state the need in detail.
b) The vendor shall describe all necessary hardware and software changes
associated with migration of the network element Release 4 to network
element fully compliant with 3GPP R5/R6.
c) The Vendor is request to describe how Media Gateways can be used in
IMS architecture. In case of additional Hardware and Software being
required, the vendor shall state the need in detail.
6.3.7 O&M

a) The vendor shall provide Operation and Maintenance system for MGW
with customized man-machine interface to offer fault management,
configuration management, alarm management, performance
measurement and security management.
b) The MGW O&M system can not only be controlled through the local
console, but also be managed by EMS in a centralized way by accessing
the local maintenance center of EMS.
c) The MGW O&M system shall support the following functions:
d) Device Management
i. The graphical interface shall be supported; device configurations,
board cascading situation, board status and power distribution status
can be viewed through GUI. Through right-mouse menu operations,
the operator can query, display, switch, reset, isolate, block and
activate boards and interfaces.
ii. MML commands shall be used to manage hardware, system
resources, signaling links, clock system and physical ports of the
MGW.
e) Data Management
The data configuration and database management function is used to
add, delete, modify or query the configuration data necessary for
system operation, as well as managing the database necessary in
keeping the data consistent between host system and BAM, and in
data backup.

74
 The data configuration of the MGW O&M system which is based on
database management shall support the following functions:
i. Offline and online data configuration
ii. Remote and local data configuration
iii. Data backup and restoration
iv. Online upgrade
v. Data verification.
f) Alarm Management
The function is to receive and deal with alarms. According to the alarm
type and level, the alarm terminal (for example, an alarm box or the
alarm management system) delivers the corresponding voice and
optical signals, and sends the translated alarm information to the
network management through. In addition, the function also enables
to save alarm information, display history alarm records and set alarm
processing way.
g) Environment and Power Supply Monitoring
The function is to monitor and control the environment, power supply
and other intelligent devices in the central or remote equipment room
even when no one is on duty.
h) Security Management
The MGW system supports multiple users. For the purpose of
security and convenience, the system shall support authority
management and log management.
i. Authority Management
The authority of operators and workstations is under the hierarchical
management. In the O&M system of MGW, the execution of a MML
command is subject to two conditions: the authority of the operator
and the authority of the workstation. The command cannot be
executed if any of these conditions is not satisfied.
ii. Log management
iii. It enables the querying of MML operation records. By querying the
operation log, you can specify any operation has been conducted to
endanger the normal operation of the system.

6.4 Wireless Intelligent Network (WIN)

6.4.1 MTML presently has Huawei make IN dimensioned for 100K CDMA
subscribers. Existing, Huawei make IN is planned to be replaced with a
common IN which should handle both CDMA & GSM subscribers. The new
IN equipment shall be dimensioned accordingly with one Voucher
Management System (VOMS) for existing as well as new IN. The new IN
should be dimensioned with a provision to serve 100% subscribers of this
tender as pre paid and all 110k CDMA subsricbers. The responsibility of
migrating the data of old IN to new IN lies with the successful bidder. The
bidder, if feasible, can use the existing IN hardware/ software. W hile
migrating/ integrating it is to be ensured that the services currently running are
not affected and customers don’t see outage.

75
6.4.2 The bidders also have the option to expand and upgrade the existing IN for
providing CDMA/ GSM/3G services seamlessly to the existing as well as new
capacity, with the modified features to all customers.

6.4.3 Design Aspects:

a) Traffic Profile for IN subscribers same as post paid subscribers.

b) Common IN for GSM, CDMA and HSDPA/HSPA.

c) The IN solution proposed by the bidder should be expandable to at least 310K

subscribers.

d) Voice and data services including pre-paid roaming between IN platforms

supplied by different vendors should be supported.

e) The SCP shall be able to cater to multiple MSC SERVER AND remote MEDIA
GATEWAYs from different vendors without any limitations.

f) Pre paid Data s ervice should be supported and should provide content
charging function such as charging by volum e, charging by c ontent etc.

g) New c om m on VOMs for existing capacity 1 million vouchers + new 2 million

vouchers (Total 3 million vouchers) in active/ idle state should be
supported. There should not be any limitation of the total vouchers/ PINs
used. The used vouchers should get deleted and c apacity created for new
vouchers.

h) Voucherless recharge feature (E-PIN) bas ed on ATM, SMS, USSD, W eb

etc. should be provided including s erver & related H/W as required &
interfac es.
i) All features/ services available in current IN should be provided in the new
IN also.

6.4.4 The CCS7 links should be suitably dimensioned to take care of signaling load
as per tender requirements.

6.4.5 New IN platform should be configured as separate SDP , SCPs , OCS for
ease of expansion.

6.4.6 All the new IN platforms and SSPs shall work with CAMEL Phase III &
Diameter protocol upgradable to CAMEL IV. Online charging of all services
including MMS should be available from date of commissioning of network.

6.4.7 The Voucher Management System (VoMS) may be integrated with IN or may
be on a separate server with capability to interface with TCP/IP and SS7. It
shall provide facility for topping-up of the pre-paid account over-the-air in
conjunction with the proposed OTA server or ISO 8583 interface. The bidder
shall ensure that the OTA server/IN system interfaces with Credit card
clearing house, ECS etc with whom MTML has an agreement for payment
realization and update the customer account in VoMS/IN with appropriate

76
 credit. All such transactions shall be implemented with secure signatures from
the SIM and signature validation by the OTA server.

6.4.8 The pre-paid service shall be IN based supporting over the air charging by the
subscriber compliant to 3GPP. Prepaid services shall contain service bonus
function including preferential rate, free discount or free SMS based on
accumulated usage, monthly usage or the time in network. It shall be possible
to provide any combination of unprohibited teleservices and supplementary
services, W AP services, SMS, MMS, GPRS and EDGE etc to the pre-paid
subscribers and charge them ON-LINE as per the prescribed tariff. ON-LINE
charging shall be in real time and shall do differential charging based on the
customer category, destination number and also based on the content
provided by the SMS & MMS content providers. It shall also interface with the
GMLC or LBS application server for the location based services to the
prepaid-subscribers and ensure online charging of such subscribers. The
system shall ensure that adequate balance is available in the account of the
pre-paid subscriber before the service is provided. The bidder shall provide all
necessary components required for IN based prepaid service including IVRS.
The IVRS shall be provided in 4 (four) languages namely English,
French, M andarine and Hindi. The customer should be given an option to
select the language and set it for all calls by dialing a short code. It should
support prepaid roaming both national and international. The pre-paid servic e
should have data security features for fraud prevention. The pre-paid service
application should be able to determine the duration of the call to the nearest
of the 1sec and update the subscriber's account on real time basis to record
the new available balance. It should be able to notify subscriber regarding low
balance during session or in the beginning as per the case. It should also be
possible to send sms notification for a defined low balance.

6.4.9 Accounting of all IN services shall be in the IN system and it shall be possible
to send the Consolidated Accounting information (CDR) to B&CCS for the
purpose of reconciliation and compilation of accounts.

6.4.10 The system shall provide all necessary data required for scratch cards. The
scratch card data shall be protected against all type of frauds. Encryption/
decryption software shall be provided by the bidders.

6.4.11 Full flexibility of change in recharge voucher value and validity from front end
any time after loading on the IN platform should be available.

6.4.12 IN and MSC SERVER should be capable of providing traces in SCP as well
as signaling side for troubleshooting and monitoring.

6.4.13 The proposed IN solution shall support following broad features :

 Prepaid service (PPS) both voice & data

 Friend & Family Number (F&F)
 Closed user group (CUG)
 Virtual private Network (VPN)
 Premium Number (PRN) – numbers on which the calls are to be
charged at higher rates
 International prepaid dialing for other network numbers

77
  Account calling card – any customer (of any operator) can use this
to create his prepaid account for International calls
 E-PIN/ E-TopUp
 Tele-voting services

A. PPS – Basic Features

- Password Modification
- Multi Language support
- Black list
- Claim of missing/missing claim dismiss
- Balance Inquiry
- Low balance alarm
- Voice prompt
- Real- time charging
- Real time charging for SMS/MMS
- Account recharge
- Charging notification
- Help desk Calling
- Call barred
- Call forwarding
- Electronic recahring through internet

B. PPS – Advanced Features

- USSD recharge/query/transfer
- SMS recharge/query/transfer
- DTMF recharge/query for third party recharge
- Bonus status query
- Class of service
- Volume/duration based online data service charging
- Intra- MSC roaming
- First – call greeting
- Daily / weekly/ monthly deduction of some amount for any specified
package tariff of voice/ SMS/ VMS/ GPRS/ MMS etc.
- Friend & Family number
- Pre- paid home zone
- Charging for Pre- paid CRBT service
- Multiple bonus offering
- Flexible status definition
- USSD callback
- Deactivation of account if no call is made/ received for a particular
duration or no recharge takes place in the specified period.
- Different tariff plans for charging with different recharge coupons
- Recharge coupons only for the specified services like SMS/ VMS/
MMS/ GPRS etc.

C. Bonus and packages

- Monthly flat fee with/without usage limitation
- Expenditure/duration based graded discount
- Expenditure/duration based package
- Timed prepayment consumption e.g. 100 minutes of on-net calls
free on topup of a specified amount
- Installment for mobile phone i.e the charges for mobile phone to be
reduced from the customer account in defined monthly installments

78
 - Free call numbers
- Pre- load in new card
- Number segments based rate
- Bonus on Account creation
- Bonus on Account activation
- Bonus on Recharge operation
- Bonus on Amount of recharge
- Bonus of Number of recharge
- Bonus on Expenditure accumulation for outgoing calls
- Bonus on total incoming call duration
- Bonus on number of SMSs/ MMSs sent in a period
- Bonus on data usages volume
- Bonus on Life time accumulation
- Point bonus
- Special date bonus (e. g, birthday ,festivals)
- Any Bonus can be either a fixed amount or percentage of the
recharge value and can be restricted only for the use of voice/
data/ SMS/ MMS etc either in own network calls or all calls.
- Bonus should be possible to be credited over a period of the
specified duration in equal installments.
- Bonus is based on individual definition. It can be set according to
some certain conditions defined by operator.

D. USSD Short Number

- For Recharging
- For Balance querying
- For Balance/ credit transfer

E. Credit Transfer via SM S/USSD

- Subscriber can transfer his balance to other user via SMS/USSD

F. Class of Service (Brand)

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

G. M aster – 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.
- W hen 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).

79
 - It is mainly used to implement discount tariff for some areas/time
periods with Lower traffic, thus encourage them to call at the
time/area.

J. Tariff Packages
- Monthly/ weekly/ Daily Flat Fee with/without Limitation
Voice (local, national or whole voice services)
SMS/ MMS
Data/ GPRS
- Discount
Voice ( local, national or whole voice services )
SMS/ MMS
Data/ GPRS
K. Customer Categories – Various customer categories should be available
wherein different tariffs are applicable. The customer category can be
changed by recharging with any predefined special recharge voucher.

6.4.14 In case of VPN, there shall not be any restriction on the number of VPN
accounts that can be created. The size of the VPN group can be as small
as two and can be as large as the total capacity being ordered. All the
bonus packages mentioned above should be applicable for VPN
subscribers also.

6.4.15 The system shall provide all necessary data required for scratch cards. The
scratch card data shall be protected against all type of frauds. Full
arrangements for random number generation/ encryption should be made.
The system should support atleast one million active recharge PINs at any
given point of time. There should not be any license limit for total number
of scratch cards/ PINs generated and loaded in the system. Each
recharging card has its own period of validity and the period expires, all the
documents of the recharge card shall be cleared. The system shall allow the
user to set the valid period of the mobile phone number. W hen the account
balance is zero, the phone number is kept within the valid period, during
which the user has to recharge the account or the documents shall be
cleared. The subscriber can buy a recharge card and recharge their account
by USSD or IVR by dialing a public number. The third party recharge
through IVRS is also to be provided.

It shall be possible to put limitations on the prepaid subscribers:

 Limit on roaming: the subscriber is not permitted to roam to some
predefined locations;
 Forbidden prefix: called numbers with certain prefix are forbidden to
dial;
 Lock on incoming calls: the incoming calls can’t be picked up;
 Lock on outgoing calls: the outgoing calls can’t be made;
 Limit on user configuration;

The subscriber can buy the recharge card anywhere as long as the
relationship between service providers is formally established. All records
will be available from the system to facilitate settlement among different
service providers;

80
 The prepaid user shall be able to use a short number to call the operator
for assistance, resembling the function of a customer service center. The
user shall be able to dial a short number by the mobile phone and shall tell
promptly the capital remained.

The system shall be able to set a certain numbers as the free call such as
the recharging number.

The system must be capable of “partitioning”, to allow different category of

the prepaid system, such as corporate users groups like hotels, business
enterprises. Each category of customers may have a different tariff plan.

The system shall be able to notify callers of balances remaining on the

account in terms of monitory units or time, before the call is placed and
after the end of the call through SMS.

The system shall generate break in warning messages 2 minute and 1

minute and at the balance depletion point, before the call is ended.

The prepaid shall support both rechargeable and non rechargeable

prepaid account.

The prepaid shall support the use of pre-defined rechargeable cards.

Consequently interfaces to financial institutions e.g. bank shall be
supported.

Rate shall be selected based on local, trunk, international, inter-operator,

regional codes.

All data, operational and historical shall be maintained in a standard

database management system allowing use of a wide range of query and
report packages.

The offered prepaid system shall support 10 workstations with possible

extension of 40 workstations which shall serve as customer care terminal.
The user interface must be user friendly and provide the interface to
various reports on individual and group accounts (like detail account
information, account balance, call history data). The interface shall work
on standard GUI based software.

The system shall generate at least following traffic statistics. Various other
reports and their formats would be prescribed to the vendor, as per
requirements and shall have to be provided.
 numbers of calls per prepaid number
 average call duration
 holding time per subscriber during busy hour
 average call duration per subscriber
 number of call unsuccessful due to system
 number of call unsuccessful due to caller

The system shall generate at least following Application specific statistics.

 number of times each menu/command selected.

81
  Number of erroneous caller entry
 Number of times each language item is played.
 Number of times messages are played.

Apart from the availability of prepaid services, as above, to the purchaser’s

GSM & CDMA customers, necessary provisions shall be made by the
contractor to provide scratch card based prepaid services to customers of
other fixed line & mobile operators such as prepaid international long
distance service. These customers should also be able to use the same
recharge card. This is a mandatory requirement.

6.4.16 E-Top Up/ E-PIN: This system should be provided to enable paper less
recharging. The E-PINs would be transferred from one distributor to a retailer
and finally to customers through SMS/ USSD. Proper security checks should
be done to avoid fraudulent cases.
6.4.17 There would be only one type of recharge cards generated in the system
which are to be used for all prepaid services viz. CDMA, GSM and Internation
Calling Cards.

6.5 HLR/AUC

6.5.1 MTML presently has Huawei make CDMA HLR diamentioned for 110K
Subscribers. Existing HLR should be suitably upgraded and integrated
with a new HLR of capacity as envisaged in this tender to provide 2G & 3G
services seamlessly to the existing CDMA subscribers as well as new
subscribers. The new HLR shall be dimensioned accordingly. The
responsibility of interworking of new HLR with existing HLR of MTML /
other network lies with the successful bidder.

6.5.2 Alternatively, the successful bidder may replace the existing HLR with new
HLR of higher capacity which will include existing HLR capacity. In this
case, the migration of existing HLR capacity to the new HLR will be the
responsibility of the successful bidder.

6.5.3 The bidders also have the option to expand and upgrade the existing HLR
for providing 2G/3G services seamlessly to the existing as well as new
capacity.

6.5.4 Home Location Register (HLR) serves as the primary database repository
for subscriber information that is used to provide control and intelligence
within mobile networks. Mobile subscriber profiles, locations and activities,
and information about supplementary subscriber services are all
seamlessly managed for the Mobile operator by the HLR. The HLR
contains a record of each subscriber who has subscribed to a Mobile
telephony service within the home area. One HLR can serve one or more
MSC. HLR stores the related information of subscribers such as ESN,
MDN, IMSI, MIN, selected services, current location, and authorized
effective period etc.

Authentication Center (AUC) is the primary repository for managing and

processing authentication information used to verify and validate a Mobile
identity within networks. This information consists of security and

82
 authentication features, as well as complex validation algorithms, which
enable authentication procedures used to prevent fraudulent use of
network resources. The AUC also incorporates database functions used
to store the encryption and authentication. One AUC can serve one or
more MSC via one or more HLR, which serves as gateways. The
functional entity of HLR/ AUC may be physically integrated with logical
separation or it can be stand alone HLR/AUC. All requirements mentioned
in this clause for HLR/AUC are applicable to both stand alone HLR (S-
HLR) and Integrated HLR (I-HLR) unless it is specifically mentioned
otherwise. HLR/AUC shall be developed based on 3GPP standards,
providing open interfaces.

Equipment Identitiy Register (EIR) will form part of the system for
blacklisting the stolen mobiles and should be provided as per GSM
standards.

6.5.4 General Requirements

This specific ation sets out the requirem ents to be m et by the Bidder to
provide all Equipm ent, including hardware, software including related
servic es of GSM/U MTS HLR/AUC in acc ordanc e with the Relevant
Standards and Rec omm endations and the Specifications stated herein.
The vendor’s s olution will have to support:
a) The Bidder shall provide an Operation and M aintenanc e Centre
(OMC) as part of S ystem and shall interconnect and integrate with
existing Network M anagem ent S ystem (NMS).
b) The Proposed HLR/AUC products shall have large capacity with high
density in order to s ave the C arrier’s CAPEX and OPE X. Furtherm ore,
the products shall be distributed designed and have reas onable
flexibility for the future capacity expansion.
c) The propos ed HLR/AUC shall support the c arrier network bas ed on
TDM and IP.
d) The Bidder shall list all the outsourcing HW and SW .

6.5.5 Hardware and software design

a) Systems with a distributed architecture that features a centralized

databas e and service logics separated from the databas e and the FE
should be data-less.
b) The following Servic e Logics must be supported currently or at
roadm ap as separate features:
 HLR
 HSS
 SAE HSS
 EIR
 AAA

83
 c) The HW platform of propos ed HLR shall be the com m on and m atur e
platform which can be used in M obile soft-switch, packet switch, IMS-
CSCF and SAE.
d) The system architecture of HLR shall be designed as distributed, and
can be expanded flexibly by c ascading.
e) The Vendor shall provide detailed description of HW /SW design and
architecture of HLR. M ain requirem ents include:
i. System Architecture
ii. Operation and M aintenanc e
iii. Electrom agnetic Com patibility Specific ations
iv. External Interfac e Specification
v. General block layout and functional layout.
vi. Description the way how the s ystem works, e.g. c entralized,
distribute or hierarchical control, incorporation of I/O devices, ports
and bus es, distribution of timing and m anagem ent functions.
vii. Figures of offered HW .
viii. List of all racks, cabinets, c artridges, m odules, units, cards, I/O
devices, interfac es, power supply units, synchronization and
timing units, etc. the network node consists of. Description of their
function in details and possible impact on s ervic e if the certain unit
fails.
ix. Redundanc y. W hat redundanc y principles are used for backing up
a particular unit, e.g. hot-standby, c old standby, N+1, which
units/m odules/cards are/aren’t hot swappable, how does the unit
switchover affect the system perform anc e, are there any
necessary restarts to activate backup unit? W hich
units/m odules/cards in the entity are not redundant? How their
outage impacts services?
x. Description of typical layout of racks, cabinets, cartridges,
m odules, units, c ards, I/O devic es, interfac es, power supply units,
synchronization and timing units, etc.
xi. Explanation of the concept and redundancy of power supply f or
both a whole network node and individual components.

6.5.6 Signaling

a) Autom atic load redistribution on the links which are available in the
com bined linkset
b) 2Mbit High Speed Signaling D ata link ITU Q703
c) M aximum values as regards Point Codes, linksets, S7 links, types of
GTT and other limiting factors.

84
 d) Load sharing support in SCCP (combined routes ets) and MTP level
e) Load sharing for all the SCCP destinations (Global Title) or M TP3
destinations (Point C ode)
f) Load sharing am ong multiple STPs using GTT Alias P oint Codes for
STP addressing
g) The HLR/AUC shall support SIGTRAN protocol group:
 The HLR/AUC shall support SCTP according to RFC 2960.
 The HLR/AUC shall support M3UA according to RFC 3332.
h) The HLR/AUC shall support M ulti-signaling-point (Multi-SP) function to
enable large-capacity offic es to break the limitation of Signaling
System N o. 7. The m aximum number of SP supported shall be up to
256.
i) The HLR/AUC shall support SCTP m ulti-homing to ensure the
reliability of IP based signaling interfac e.

6.5.7 Interface description

a) The offered HLR shall provide abundant open standard interf aces.
This implies that the V endor shall share all necessary inform ation with
other vendors when inter-operation is required in Operator’s network.
Any deviations from this rule shall be explicitly stated by the vendor for
each network entity and interfac es described in this RFP. Impact and
internal protoc ol
Any detail
Connected proprietary
entities feature or
protoc ol
MSC INAP …
VLR … …
SMC
SGSN
GGSN
gsmSCF
GMLC

b) The network elem ents shall provide HLR relevant interfac es as

specified below. The Vendor shall depict all protoc ol layers for eac h
supported interfac e and provide statem ent about complianc y with
relevant 3GPP standards or other standards (RFC, ITU-T, IEEE ) for
each protocol layer.
Connected Interfac e Applied Physical Specific atio
entities nam e protoc ol Interfac e ns
MSC
VLR

85
 Connected Interfac e Applied Physical Specific atio
entities nam e protoc ol Interfac e ns
SMC
SGSN
GGSN
c) The Vendor shall describe number of logical links/connections
possible per one interf ace and whole entity, recom m ended/m aximu m
load of interf ace that can be proc ess ed by interf ace unit,
recom m ended/m aximum load of fully configured entity.
Interfac e Internal/ Physical M ax P ort M ax Link number
External Interfac e num ber
C External E1
IP
ATM
D External E1
IP
ATM
J External E1
IP
ATM
Lh External E1
IP
ATM
Gr External E1
IP

6.5.8 Functions and Features

a) The HLR shall be shared by the circuit switched (CS) dom ain and
packet switched (PS) dom ain in UMTS/GSM system. It shall integrat e
the functions of AUC.
b) The HLR shall provide USSD (Unstructured Supplem entary S ervices
Data) functionality and interfac e which shall be compliant with GS M
and 3GPP specifications TS 29.002.
c) The HLR shall support CAMEL Phas e 3 s ervic es. The HLR shall
provide O-CSI (Originating CAMEL Subscription Inform ation), T-CSI
(Terminating CA MEL Subscription Inf orm ation), SS-CSI
(Supplem entary Service Invoc ation Notification CAME L Subscription
Inform ation), TIF-CSI (Translation Inform ation Flag CAME L
Subscription Inform ation), U-CSI(USSD CAMEL Subscription
Inform ation) and UG-CSI (USSD General CAME L Subscription
Inform ation), they include GPRS-CSI(GPRS CAMEL Subscription
Inform ation), SM S-CSI(Short M essage Service CAME L Subscription
Inform ation), D-CSI(Dialed Service CAM EL Subscription Inf orm ation),
M-CSI(M obility M anagem ent event CAME L Subscription Inform ation)

86
 and VT-CSI(VMSC T erminating CA MEL Subscription Inform ation).
d) The HLR shall support G eneral packet radio service (GPRS).
e) The HLR shall support any tim e interrogation (ATI) operations initiated
by a s ervic e control point (SCP). Through this operation, the SCP and
HLR provide the loc ation and status of m obile terminals.
f) The HLR shall support providing LCS s ervice subscription function
and supports four standard subscription m odes: Univers al, Call
related, Non-c all related and PLMN operator. And the HLR shall
support the Lh interf ace with GMLC and provides LCS routing
function.
g) The propos ed HLR should support the function of CAME L restriction.
This function enables operator to flexibly configure CAMEL servic e
proc essing in HLR bas ed on subscriber acc ording their requirem ents.
h) The propos ed HLR should support the function of SMC address
filtering.
i) The V endor shall provide inform ation and specific ations on any
proprietary protoc ols or protoc ol elem ents used on the interf aces of
the propos ed HLR/AUC.
j) At least 254 different virtual HLR, which are independent and c an be
com pletely distinguished.
k) Configuration of multiple virtual HLR in the sam e physic al equipm ent.
l) Flexible roaming restriction and Roaming Profiles which can be
configured per Subscriber.
m) Roaming restriction per network elem ent, group of elem ents for GSM,
UMTS and/or GPRS.
n) Identific ation and Differentiation between 2G and 3G subscribers.

6.5.9 Redundancy and Reliability

a) The HLR shall be designed in such a way that single faults in the
software shall not caus e a system failure or service interruption or
degradation of system perform anc e. Under faulty conditions, the
System shall c ontinue to operate norm ally without reduced grade of
servic e or quality of service.
b) No single point of failure in one site/node. All hardware have its
backup in loc al site.
c) The HLR shall be designed in such a way that the HLR can be
duplicated on geographically separated locations.
d) The hardware reliability of the HLR shall be ensured by:
i. Exc eption Protection
ii. Redundanc y and B ackup D esign

87
 iii. Flow C ontrol
iv. Reliable P ower Supply
e) The data reliability of the HLR shall be ensured by:
i. Data backup between different boards
ii. Data backup to local harddisk
iii. Data backup to DiskArray
f) The proposed HLR shall have at least 20 specifically redundanc y
com m ercial cas es used all over the world. The detailed inform ation
should be listed.
g) All the elem ents must be dim ensioned for the purpose of achieving
99.999% reliability (sim ple node) and 99.99999% (redundant nodes)
h) For redundanc y s olution, the HLR/AUC should support m anually and
autom atic ally switch over, and can be configured by operator.

6.5.10 Performance & Capacity

a) The propos ed HLR/AUC shall have large capacity up to 3M active

subscribers (one FE).
b) The AuC capacity must be atleast 1.2 tim es to that of the HLR
c) The HLR/AuC T echnical Specification should be provided as following
form
Item Ability
M ax c apacity
Density(footprint/per10M
sub, rack footprint)
Provision speed
M ax c omm ercial deployed
capacity in one network
TDM 2M Links
TDM 64K Links
IP Sigtran links
Range of temperature
Power
Consumption(xxW /1m Sub)

6.5.11 Network Evolution

a) The Vender shall describe all nec essary hardware and softwar e
changes associated with migration of the HLR to HSS.
b) Is it possible to migrate to 3GPP Releas e 5 network only via softwar e
upgrades? W hat is the perform anc e impact of such upgrade?
c) The Vendor shall describe the roadm ap for this, including the
integration and interworking with the packet dom ain core network and
ancillary network nodes.

88
6.5.12 HLR/AUC shall support the following features.

(i) Logical Group (Applicable to S-HLR only):A logical group shall contain
a collection of subscribers which the operator may create to maintain
subscribers in different groups for administrative purposes.

(ii) Group Profile (Applicable to S-HLR only): The group profile contains a
set of default features automatically assigned to the subscriber. Operators
shall be able to group a set of subscriber features together into group
profiles and thus avoid having to assign each feature individually when
creating the profiles for new subscribers.

(iii)Administration of Cooperating Exchanges (Applicable to S-HLR only)

A cooperating exchange is an MSC that accesses the HLR for

subscriber information. Means shall be provided to specify, delete,
modify, and print cooperating exchange data. The data shall specify
the following:

a. Exchange identity (Global Exchange Name)

b. Roaming type (automatic or manual)

c. Routing Interrogation Code (how the interrogating exchange should

route the call)

d. Signalling network information

e. Signalling protocol to be used for routing to a destination in the

network.

(iv) Tables in the HLR

The provision shall be there for setting up and maintaining all data
related to the HLR. The data stored in the table shall include:

a. Forward-to-number analysis table

b. PIC to CIC translation table

c. Procedure code analysis table

d. Announcement code analysis table

e. Restricted digits table

f. Cooperating exchange table

6.5.13 Alarms and Notifications

Alarms: The HLR shall generate an alarm when an error or fault occurs
within the system. Provision shall be there for these alarms requiring human
intervention in order for them to be acknowledged or cleared.

89
 The HLR shall log all alarms and presents them to the user via the GUI (Live
Alarm Display). The operator shall be automatically presented with the
relevant procedure in order to resolve a given alarm.

Notifications: A notification shall report the occurrence of a specific event in

the system. In general, a notification shall not require operator intervention.

6.5.14 The AUC shall have provision for security measure for fraud prevention by
implementing a series of standard authentication procedures to protect the
Mobile network.

6.5.15 Authentication Procedures: AUC shall support authentication according to

the standard GSM/ UMTS protocols.

6.6 INTERFACES

a) Full Technical details regarding implementation of interfaces (at each standard

reference point) amongst different network elements as well as with other
networks shall be provided and no interface shall be proprietary in nature. It shall
be possible for the MSC to interface with external network elements such as
Short Message Entity (SME), OTAF, IN etc. through standard interfaces.

b) All standard interfaces shall be supported by the system as per the requirement.

6.7 SM SC

6.7.1 MTML presently has Huawei make SMSC diamentioned for 100K
Subscribers. Existing SMSC should be suitably upgraded and integrated with
a new SMSC of capacity as envisaged in this tender to provide 2G & 3G
services seamlessly to the existing CDMA subscribers as well as new
subscribers. The new SMSC shall be dimensioned accordingly. The
responsibility of interworking of new SMSC with existing SMSC of MTML /
other network lies with the successful bidder.

6.7.2 Alternatively, the successful bidder may replace the existing SMSC with new
SMSC of higher capacity which will include existing SMSC capacity. In this
case, the migration of existing SMSC capacity to the new SMSC will be the
responsibility of the successful bidder.

6.7.3 The bidders also have the option to expand and upgrade the existing SMSC
for providing 2G/3G services seamlessly to the existing as well as new
capacity.

6.7.4 Design Aspects:

i. Common SMSC for 2G &3G services (GSM & HSDPA/HSPA) in any

proportion.
ii. Must support content based charging for post paid and prepaid subs.
iii. 2 BHSM per subscriber may be considered for each Phase.
iv. GUI based faults and reports including failure reports for SMPP, VMS, IN
related SMS.

90
 v. CDR based reports to be made available.
vi. New SMSC should cater to at least 1 Million BHSM.
vii. It shall be possible to charge differentially for premium messages, pre-
paid subscribers on the basis of SMPP port, content of SMS, SMS
profile of subscriber, type of SMS, Broadcast list, location from where it
is originated and charging of content provider in case of advertisements.

6.7.5 Maximum length of SMS message - 160 characters. Messages of size at least
equivalent to 10 SMS should be sent as multiple SMS for concatenation at
MS and vice-versa.

6.7.6 The SMSC shall provide storage for all undelivered message for the duration
of atleast one week. The SMSC shall provide multiple re-trial profiles based
on the cause-code of non-delivery together with programmable re-trial
duration for each cause-code through MMI commands.
6.7.7 Core Requirement
a) The vendor’s solution must support Gd interface for message delivery on
2.5G and 3G packet switch environment
b) Solution must support Interworking MSC & Gateway MSC combined in one
´Mobile Network-Interface
c) Message tracing based on a given specific number should be available
d) The solution must support deliver multi messages with only one time to send
routing information operation.
e) The solution should provide a GUI for the operator to inquire the location of a
cell phone
f) The vendor’s SMSC networks must be simple and the system should has
massive capacity(no less than 1000 messages per second) and the vendor
should make a detail description about how to support such massive
messages processing capability.
g) The Vendor must describe SMSC system capability per node.
h) All the messages should be stored for no less than 3 months, and at the sam e
time, a GUI should be provided to do such inquiring jobs
i) The solution should simultaneously support GSM/CDMA/TDMA signaling
j) For CDMA scenario, the solution should support MMS push and W AP PUSH
k) The SMS must support diameter, real time charging interface.

6.7.8 The SMSC shall have the facility of SMPP service for interconnectivity to
facilitate multiple content providers to extend their services to MTML
subscribers. A minimum of 128 content providers are to be provided access
to the SMSC. The SMSC shall have suitable firewall to ensure security of the
SMS platform. It should be possible to differentially charge based on the
destination number and also based on the content provided by the content
providers for both post and prepaid subscriptions. It should accordingly
interface with IN platform for ON-LINE charging in real time and shall
generate data for differential charging for the prepaid subscribers. SMSC
should have in-built capability of SMS gateway for HTTP push and pull
services.
6.7.9 Feature Requirement

a) The solution must support a flexible subscriber database

b) The solution must support Store and Forward, and Forward and Store of
messages

91
 c) The solution shall support SRI for SMS with high priority, and make a delivery
attempt for this message
d) The vendor’s solution shall be able to configure different priority by origination
and destination number or number segments
e) The system shall offer extremely high peak traffic throughput by means of
intelligent retry mechanism. The system shall have a dynamic handling of
retries such that during high traffic periods, SMS with high retry counts will not
be retried. The retry counter for these SMS’s shall not be incremented.
Instead a new counter shall be introduced for each SMS that will show the
number of times a retry was postponed due to a period of peak traffic. The
number of retries performed on SMS before peak traffic handling is enabled
shall be configurable
f) It shall be possible to configure maximum validity period based on source and
destination address of the SMS
g) The SMSC shall support delivery of SMS with 20-character A-party and B-
party MSISDN
h) Combined fast store and save store depending on message type
i) The ability to use a fully redundant set of centrally located SS7 interfaces so
that each SMSC in a multi-node environment does not have to have individual
direct connections to the MSCs and STPs
j) The SMSC should provide sending group and short number short message
based on the web portal for enterprises

6.7.10 It shall be possible to schedule the SMSC for acceptance and transmission of
push messages from the content providers. It shall also be possible to define
priorities for the different ports for acceptance of SMS from Content Providers.

6.7.11 It shall be possible in the SMSC to define criteria based filters to bloc k
transmission of SMS satisfying the defined criteria. The SMSC shall route all
such messages to an appropriate database and provide an analysis and
management report of such messages through interactive and intelligent GUI
in the OMC. The report and analysis shall be as per the customization
requirements of MTML.

6.7.12 The SMSC shall have suitable interface (IS 41-C) to interwork with CDMA-1X
systems with assumption that 15% of total SMS will be sent to CDMA
network. It shall be possible to exchange Short Messages between the CDMA
and GSM systems. The SMSC should be common for 2G and 3G services
and compliant to 3GPP TS 23.040.

6.7.13 SMSC shall provide for multiple local language support in the UNICODE
format. Details of implementation for the same may be furnished.

6.7.14 It shall be possible for the subscribers to send and receive e-mail messages,
as SMS and the same shall be handled by the SMSC through appropriate
interface to MTML email server and suitably protected through firewall.

6.7.15 The vendor’s solution is required to support the creation of an event type field,
which will be assigned based on other information in the CDR. This field will
initially not appear on the CDR. The event type field will be required to
differentiate between different types of messages, such as MO or MT

92
 messages, premium MO or MT messages, SMS copies, SMS resends, etc.
This field should be populated as part of a post-processing job, which will give
the possibility of using other fields to determine this field. The manner in
which this field is determined should be fully configurable.

6.7.16 The solution must be capable of placing CDRs in a flat text file
6.7.17 Statistics & Reporting:
a) The SMSC must provide comprehensive system statistics. The
statistics must be available in flat file format and must be available to
the System Administrator from the System Administration GUI
b) Statistic shall be provided at both the platform level and application
level
c) The following statistics shall be provided by the SMSC
i. SMS based Activity Statistics
ii. SS7 interface Statistics
iii. SMPP interface Statistics
iv. Platform Statistics
d) The vendor shall supply a detailed list and description of the statistics
that are stored on the platform
e) The statistics shall be presented to the System Administrator in ‘real
time’. The data refresh rate should be configurable. The maximum
data refresh rate should be no greater than 30seconds

6.8 MM SC:

6.8.1 MTML presently has MMSC from M/s. Huawei for CDMA network. Existing
MMSC should be suitably upgraded and integrated with a new MMSC of
capacity as envisaged in this tender to provide 2G & 3G services seamlessly to
the existing subscribers as well as new subscribers. The new MMSC shall be
dimensioned accordingly. The responsibility of interworking of new MMSC with
existing MMSC of MTML / other network lies with the successful bidder.

6.8.2 Alternatively, the successful bidder may replace the existing MMSC with new
MMSC of higher capacity, which will include existing MMSC capacity. In this
case, the migration of existing MMSC capacity to the new MMSC will be the
responsibility of the successful bidder.

6.8.3 The bidders also have the option to expand and upgrade the existing MMSC
for providing 2G/3G services seamlessly to the existing as well as new
capacity.

6.8.4 It shall be possible to charge differentially for premium messages, pre-paid

subscribers etc.

6.8.5 For design of MMSC solution, 0.2 BHMM per subscriber may be considered for
each Phase. The solution proposed shall be expandable to support one million
BHMM.
6.8.6 Requirements:
a) Specify if the MMS-C is divided into more then one functional modules,
e.g. HTTP-Proxy and PPG-Proxy, and describe clearly in a organized
list the functions and features of each of its blocks

93
 b) Describe the proposed solution from a functional perspective. An
overall figure must be provided, which will be used as a reference
(functional/physic) architecture for the following sections. The figure
should show clear how this architecture integrates into a mobile
operator network and how its components are mapped with different
functional nodes compounding the solution
c) Pre-paid credit verification nodes
d) Provisioning nodes
e) Billing/charging nodes/systems
f) O&M nodes/systems
g) Describe the ability of MMS-C to support the several types of media
content formats (text, audio/video, SMIL,). Please specify the
supported versions per media content
h) Describe the terminal manufactures and products supported by your
MMS-C solution

6.8.7 The MMS shall be with Architecture as specified in 3GPP Release 4 document
and subsequent enhancements. It should be possible to differentially charge
based on the destination number and also based on the content provided by
the content providers for both post and prepaid subscriptions. It should
accordingly interface with IN platform for ON-LINE charging in real time and
shall generate data for differential charging for the prepaid subscribers. MTML
will arrange the content through its internal resources/tie ups.
6.8.8 The vendor should provide MMS Service solution with the following service
features:

i. MO-MT MMS (Intra-operator and Inter-operator)

ii. MO-AT MMS
iii. AO-MT MMS
iv. MMS to Email
v. Email to MMS
vi. Content Adaptation and Legacy Phone Support by terminal
capability negotiation/database

6.8.9 The MMS Solution provided should be compliant to the relevant and popular
industry standard(s) as following

i. 3GPP
ii. OMA – MMSC Interoperability Compliance

6.8.10 Describe the communication protocols used for the connection

1. Describe the SMTP implementation used by the MMS platform. Indicate the
supported standard and the functions supported by this interface
2. Describe the interface implemented between the MMS platform and the W AP
platforms. Indicate the supported standard (W APFORUM specifications) and
the functions supported by this interface

6.8.11 Please describe the access architecture to the network

o HLR/VLR: describe the integration architecture with HLR of GSM network.

o GPRS: describe the integration architecture with GPRS nodes

94
6.8.12 Is MMS-C provided with a statistic gathering/analyzing tool? Describe which
and if making part of the MMS-C platform or separate module/node/platform
6.8.13 Can messages going through MMS-C be traced and monitored and how?
Describe tracing/log mechanism specifying how it is complete and user-friendly
6.8.14 The MMS platform provided should support the following features in addition
to normal submission or reception of MMS by mobile/application

i. Delivery Report
ii. Read Report
iii. Forwarding of MMS
iv. Address Hiding
v. Multi-Recipients
vi. Prepaid interface support
vii. MNP support (local database (ENUM/proprietary) or SS7)
viii. Desired Delivery Time
ix. Expiry Time
x. Different Types of medias (text, audio, still image, and video
(streaming))

6.8.15 The MMS Solution should support the following charging option

i. Real time charging for the Prepaid subscribers

ii. Real time CDR Generation
iii. Per Message Charging Only
iv. Per Message with volume class Charging
v. Per Content Charging
vi. Surcharge for IOMMS,

6.8.16 The MMS platform should support Direct Push solution, with which the Push
message can be sent to the SMSC without passing through the W AP GW . The
push policies can be configured
6.8.17 The MMS push notification message can be sent through SMS directly, push
message should be compressed in one message

6.8.18 WAP gateway supporting W AP version 2.0 for handling SMS and MMS traffic
meeting the tender requirements may be quoted alongwith expansion required
in Phase-II.
6.8.19 Billing Requirement :

a) Vendor must provide some basic and customized CDR generated

by MMS-C
b) Is real-time billing for pre-paid customers available (describe
please its interface/protocol if applicable)
c) Can real-time pre-paid billing logic be created and configured
accordingly to customer’s pre-paid system requirements

6.8.20 Describe key-factors/parameters defining relation between MMS-C’s

performance/dimension and network (LAN) dimensioning support
6.8.21 Describe MMS-C dimension dependency on CPU/Memory capacity

95
6.8.22 If vendor does package upgrades of each of its MMS-C solution consisting of
HW /SW upgrades describe performance characteristics of each upgrade for
each commercial MMS-C solution

6.9 Additional Requirements of M M SC, SM SC and Packet Core Network

6.9.1 CDRs generated by the various network elements such as MMSC, SMSC,
GGSN, SGSN, W AP and any other network elements, the services of which
are to be charged in respect of the pre-paid subscribers, shall be charged
on-line.

6.9.2 The SMSC, MMSC and GPRS etc shall generate CDRs in formats compatible
for transmission to B&CCS and to IN platform for each of the message
handled. The network elements shall provide the facility of tagging CDRs by
exception on the basis of lookup tables. It shall be possible to-define lookup
tables through MMC. Additional mediation device necessary for routing the
CDRs to B&CCS and IN platform shall be supplied.

6.9.3 The system shall through suitable procedure verify the balance available for
pre-paid subscribers before accepting their message for processing in
SMSC/MMSC/GPRS/EDGE etc. The SMSC/MMSC/GPRS/EGDE etc shall,
however, allow service messages to be delivered to such subscribers.
6.9.4 7.1 UMS shall be dimensioned to provide Voice Messaging Service to 100%
subscribers with sufficient storage capacity.

6.9.5 UMS shall have SMSC, which shall be dimensioned for 100% of total
subscribers
6.9.6 Assuming 10 messages ( 10 MO & 10 MT) per subscriber per day. Maximum
length of SMS message will be 160 characters.

a) SMSC shall provide storage for at least 40% undelivered message.

Retrial attempts of un-delivered SMs shall not impact BHSM of SMSC
as defined in this section. Expiry time for undelivered message & retrial
duration (multiple retrial profiles based on the cause-code of non-
delivery) shall be programmable through MMI command.

b) SMSC shall have the facility for interconnectivity to facilitate multiple

content providers. A minimum of 128 content providers are to be
provided access to SMSC. SMSC shall have suitable firewall to ensure
security of SMS platform. It should be possible to differentially charge
based on the destination number and also based on content provided
by the content providers for both post paid & prepaid subscribers. It
should accordingly interface with IN Platform for ON-LINE charging in
real time and shall generate data for differential charging for prepaid
subscribers.

c) It shall be possible to schedule the SMSC for acceptance and

transmission of messages from the content providers. It shall also be
possible to define priorities for the different ports for acceptance of SMs
from content providers.

96
 d) SMSC shall have suitable open interface to interwork with GSM
systems. It shall be possible for exchange of SMs between CDMA &
GSM systems.

e) SMSC shall provide multiple local language support.

f) SMSC shall have gateway functionality to configure for International

SMS for both GSM and CDMA networks.

6.9.7 The SMSC, MMSC etc. shall generate CDRs in formats compatible to
B&CCS and IN platform for each of the message handled. Mediation device
necessary for handling he CDRs to B&CCS and IN Platform shall be
supplied.

6.9.8 The system shall through suitable procedure verify the balance available for
pre-paid subscribers before accepting their message for processing in
SMSC, MMSC etc. In case adequate balance is not available to charge the
subscriber, he shall be notified appropriately. The SMSC, MMSC etc. shall,
however, permit service messages to be delivered to such subscribers.

6.9.9 SMSC & MMSC shall be dimensioned for BHSM of 0.5 & BHMM of 0.3 per
subscriber respectively.

6.9.10 The system shall be configured with unlimited subscriber license restricted
only by the total Earlang traffic. All necessary hardware and related software
licenses including databases in all network elements shall be dimensioned
and equipped accordingly, except for those network elements for which
higher capacity, if any, has been specified elsewhere.

6.10 HIGH SPEED PACKET DATA NETWORK

This document lists the technical requirements for a GPRS/UMTS PS network
architecture. It describes the target architecture and formulates and a single,
common set of requirements and expectations regarding the functionality/
capabilities, performance and delivery of SGSN & GGSN.

97
 Figure: General Architecture of GPRS/UMTS PS Network

6.10.1 This PS domain target architecture will meet the following high level
requirements, which the Vender’s solution will have to support:

a) The proposed PS System shall comply as defined by 3GPP in Release 6.

b) The proposed PS System shall simultaneously support GPRS and UMTS
accesses.
c) The system won’t be any hardware changes when upgrading from 2.5 to
3G.
d) The vender must describe in detail the various phases of a 3G
communication by indicating the various implied entities (SGSN, GGSN,
DNS, FW, Radius… ), the various protocols used (GTP, SNDCP, IP…)
e) The network elements shall provide PS system relevant interfaces as
specified in 3GPP TS 23.060.
f) The Proposed PS equipments shall have large capacity with high density
in order to save the Carrier’s CAPX and OPEX. Furthermore, the PS
equipments shall be modularized designed and have reasonable flexibility
for the future capacity expansion.
g) The vendor is requested to provide the qualifications to show that their PS
equipment has at least one application with more than 1.5 million
subscribers in commercial networks.

6.10.2 Network Evolution

a) The Proposed PS equipments shall support evolution from 2G to 3G.

b) The Proposed PS equipments shall support architectural evolution form
R99 to R4 and form R4 to R5/R6.
c) The SGSN shall be capable of supporting direct tunnel concept

98
 according to the 3GPP standards whereby the GTP User plane and
control plane are split. The User plane shall be directly tunneled from
UTRAN to GGSN and the GTP Control plane shall be handled via the
SGSN.
d) The Proposed PS equipments shall support evolution to SAE
architecture without hardware change.
e) Vendor shall provide a detailed description of the SGSN and GGSN HW
evolution.
f) Vendor shall describe a detailed feature roadmap for SGSN/GGSN
evolution per planned software release and it also should include the
capacity of each release.

6.10.3 Network synchronization

a) The Proposed PS System shall support at least two types of external clock
synchronization and shall meet the requirements of ITU-T Recommendation
G.812.:
1. Providing 2MHz or 2Mbit/s incoming clock source through BITS
2. Providing 2MHz incoming clock source through E1 line.
b) The proposed PS System shall support internal timing output interface. The
Vender is requested to describe the mechanism.
c) The proposed PS system shall support NTP(Network Time Protocol), and the
NTP server shall be provided.

6.10.4 Interface description and characteristics

a) The network elements shall provide GPRS/UMTS relevant interfaces as

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

99
 SMS-GMSC Server
SMSC
SMS-IWMSC

E C
Gd GMLC SCP

MSC-Server/VLR HLR Lg
D Gr Ge
Iu-CS Gs
A
R Uu Iu-PS Gc Gi
TE MT UTRAN SGSN GGSN PDN TE
Gn
Ga
Gb Ga
TE MT BSS Gp
Gn Billing
R Um CGF
System
GGSN
SGSN Gf EIR
Other PLMN

Figure 2: Interface of GPRS/UMTS PS Network

The vender should state the physical interface, the rate and the
physical protocol of each logical interface as the table below:
Logical Interface Physical Rate
Interface
Iu-PS
Gn/Ga/Gi/X1-
1/X2p/X3p

Gr/Gd/Gf/Ge/Gs/Lg

Gb

b) The Vender shall describe redundancy principles applied on

interfaces.
c) The Vender shall describe number of logical links/connections
possible per one interface and whole entity,
recommended/maximum load of interface that can be processed by
interface unit, recommended/maximum load of fully configured
entity.
d) The system shall provide the following physical interfaces:
 Ethernet/Fast Ethernet
 Gigabit Ethernet
 PPP E1, FR E1
 POS STM-1, POS STM-4.

100
 6.10.5 Reliability and Availability

a) The Vender shall describe in detail the Reliability and Availability

architecture the offered GSN System is based on. The GSN should
comprise of the following components:
1.5.a.1 SGSN (Serving GPRS Support Nodes)
1.5.a.2 GGSN (Gateway GPRS Support Nodes)
1.5.a.3 Charging Gateway (CG)
1.5.a.4 NAU (Network Auxiliary Unit) such as DNS, DHCP, Firewall,
Border Gateway router, etc.
b) In the event of failure of one or more parts of each core node, the normal
functioning mode of the rest of the core node shall not, in any way be
affected.
c) The proposed SGSN should support Iu-flex and Gb-flex as defined in
3GPP Standard.
d) Core nodes shall not have a single point-of-failure, all hardware boards,
power supply units and interfaces shall be duplicated and redundant in
either active-standby or load-sharing modes.
e) Total availability for each core node shall exceed 99,999%.

6.10.6 Overload protection

a) The proposed PS system shall be capable to handle signaling and traffic

overloads in an orderly and controlled manner.
b) The proposed PS system shall detect and analyze an overload condition
and produce reports and alarm information to the OMC. Data calls in
progress shall not be affected under overload conditions and particular
attention must be given to ensure that the mobility management is not
impaired due to any overload condition.

6.10.7 Software Design and Upgrade

a) The GSN system shall be modular in design. The GSN system shall be
upgradeable to a higher software release with minimal impact to the
normal system operation.
b) The upgrade of the GSN network elements shall be described. The
mechanisms to maintain the integrity of the mobility data have to be
considered in the Vender’s answer.
c) The Vender shall describe the change in architecture and the migration to
3GPP Release6 and Release7 in terms of hardware and software
upgrades of existing nodes and the introduction of new functional entities
and interfaces/reference points.
d) The system shall be able to produce copies of the system program and

101
 data and to load them automatically triggered by a restoration or
recovering process.
e) The GSN shall be capable to handle signaling and traffic overloads in an
orderly and controlled manner.
f) The overload protection should apply if one or more processors are
involved in the handling. The Vender is required to provide details of the
overload protection of all units.
g) The GSN system shall support different levels of system authorization.
The GSN shall provide access control and authorization management
functions to prevent unauthorized access to sensitive data. The Vender is
required to describe the different authorization levels.

6.10.8 Roadmap Overall description

The Vender shall provide a detailed description of PS CN evolution during 3

YEARS GPRS and UMTS. The description should take into account: the
architectural, functional and technological aspects making reference to the
3GPP release it is based on.
Moreover, the Vender shall provide for each system under quotation the
roadmap underlying the following items:
a) Hardware and Software Roadmap;
b) Capacity Roadmap
c) Network features roadmap;
d) State of Compliance respect to Standards.

6.10.9 Packet Core:

i) Succesful vendor shall provide SGSN/GGSN of capacity as envisaged in this

tender to provide 2G & 3G services seamlessly. The SGSN/GGSN shall be
dimensioned accordingly.

ii) The bidders also have the option to expand and upgrade the existing
SGSN/GGSN for providing 2G/3G services seamlessly to the existing as well as
new capacity.

iii) The GGSN SGSN shall support the standard GPRS / UMTS interfaces.

iv) The GGSN/SGSN shall support CAP III protocol. The GGSN/SGSN shall
provide all services for pre-paid and post-paid subscribers and charged the pre-
paid subscribers real time. Bidder shall indicate evolution path for support of
diameter protocol.

v) GGSN/SGSN shall support all four UMTS QoS classes – Background,

Interactive, Streaming and Conversational. Application required for back-tracing
of Global IPs (Netted IPs) to local IPs (assigned to mobile) should be stored for
minimum one month to provide the details to security agencies.

vi) Following call profile may be utilized for subscriber capacity.

102
 S.No. Description

1. Traffic requirements: 2G (GPRS + EDGE)

a) Average Traffic dem and at IP layer per active context, at busy hour, 300 bps
dow nlink+uplink

b) Ratio = Dow nlink / (Downlink+Uplink) 80%

c) Average packet size (at IP layer) 256 bytes

2. Traffic requirements: 3G (UMTS R4 + HSDPA)

a) Average Traffic dem and at IP layer per active context, at busy hour, 600 bps
dow nlink+uplink

b) Ratio = Dow nlink / (Downlink+Uplink) 80%

c) Average packet size (at IP layer) 256 bytes

vii) Design Aspects:

a) Common SGSN/GGSN for 2G & 3G services (GSM & W CDMA) in any

proportion within the total data requirements envisaged in the tender.

b) Must support content based charging for post paid subs and prepaid subs
c) Shall include all requisite Hardware and Software for DNS, NTP, Firewall,
LAN, Border Gateway, CG, LIB/LIC and Switches etc.
d) Throughput for simultaneous access should be dimensioned based on one
PDP Context per subs for 50 % of 3G subs and one PDP context per subs
for 20 % of 2G subs. However, subscription for 100% 2G & 3G subs should
be provisioned for data services. The SGSN/GGSN should be expandable
to one million PDP contexts capacity.
e) The offered SGSN/GGSN solution should comply with GSM standards.
f) Intelligent Packet Solution for content based charging shall be provided.
The solutions should be capable to analyse network, transport and
application lyer protocols. The packet inspection included in the solution
should support protocols like IP, TCP, UDP, HTTP 1.1, W AP 2.0, MMS ,
RTSP, SMTP, POP3, IMAP4 etc. and should provide analysis of content
types. The system should support diameter protocol for charging of pre-
paid subscribers.

6.10.10 Requirements for SGSN

Hardware and software design

a) The system architecture of SGSN shall be designed as modularization,

and can be expanded flexibly by cascading.
b) The total planned down time for each core node shall not exceed 45
minutes / year, e.g. due to hardware and software upgrades.

103
 c) The signaling plane and the user plane in SGSN should be separately
designed to avoid the influence on each other.
d) The SGSN provided should be act as Serving GW to support evolution
smoothly to SAE.
6.10.11 Functionality and Feature Requirements of the SGSN
a) The SGSN shall perform all Packet data routing and transferring,
Encryption and authentication, Session management, Mobility
management functions as specified in the relevant ETSI GSM and 3GPP
release4 standards.
b) The SGSN will produce information of management of taxation and
mobility to be gathered by the Charging Gateway (CGF) functionality.
c) The SGSN will have to be interfaced via GPRS Service Switching
Function with Service Function Control for optional Camel sessions and
cost control service support.
d) The SGSN will be capable of inter operate with GPRS/EDGE Networks
and UMTS Networks.
e) The SGSN shall support the following Roaming / Sharing functions in
accordance with 3GPP specifications:
 Multiple PLMNs
 Seamless National Roaming
 Regional Roaming restrictions based on certain LA or based on
IMSI series
 Selective equivalent PLMN (3GPP TS 24.008)
f) The SGSN shall support CAMEL phase 3.
g) The SGSN shall support Multiple Signaling Point and High Speed Link
(2M SS7) technology.
h) The SGSN shall support Iu over IP (3G) and Gb over IP (2G).
i) The SGSN shall support MVNO function. It should support divide MVNO
by MNC+MCC or IMSI series. The different Authentication method and
ePLMN List should provided according to different MVNO. The SGSN
should define subscriber number, PDP number, Short Message function,
LCS function, encryption function, compression function for each MVNO.
j) The SGSN shall support hardware dual stack (IPv4 and IPv6).
k) The SGSN shall support hardware engine for data compression over Gb
interface as defined in ITU-T v.42bis.
l) The SGSN shall provide OSPF, BGP, RIP & Static IP routing functionality.
m) The SGSN shall support SIGTRAN function.
n) The SGSN shall support IMSI series based routing to different GGSNs.
o) The proposed SGSN shall provide all the features and functions listed.
The list should includes the following information:
 Network Elements involved in the implementation of the feature

104
  The feature is included in UMTS or GPRS or both of them
 The Vender’s feature code

6.10.12 Performance, capacity and connectivity

a) The proposed SGSN shall have large capacity (>=1 million attached
subs, 1 million PDP contexts simultaneous activation ).
b) The proposed SGSN shall have large throughput to support high speed
services (>=10Gbps).
c) The Vender shall give a description about number of SAU, PDP, physical
and logical network element connectivity for minimum configuration and
per each additional capacity step up to maximum configuration.
d) The SGSN can support flexible configuration of PDP to SAU ratio. It
should configure PDP to SAU ratio at least but not limited as 1:20, 1:10,
1:5, 1:2, 1:1, 2:1.
e) The Vender shall state the maximum number of BSC/PCU supported by
SGSN.
f) The Vender shall state the maximum number of RNCs supported by
SGSN
g) The SGSN shall be designed, built and developed on a carrier grade
platform.
h) The SGSN shall allow the application of patches / corrections without
impact to subscribers. The Vender shall provide details on
patch/correction process for their platform.
i) The SGSN shall be designed such that capacity expansions without
impact to existing subscribers.
j) The Vender shall describe the scale and number of IP interfaces
supported per SGSN.
k) The Vender shall state the impact of the packet size on the throughput
capability of the GGSN and the SGSN.
l) The Vender is requested to describe the performance information with
the following information for SGSN:
 Minimal and Maximal Capacity in terms of subscribers, throughput,
and the expansion step.
 Number of PDP context supported
 Number of types of interfaces supported
 The capability of signaling processing

6.10.13 Charging Functionalities

a) Record type and Information field

105
 The CN nodes provided by the vender should collect the mandatory
information (record Type, served IMSI etc.) specified in 3GPP TS 32. 015 for
each of the following record type:
 GPRS charging data in SGSN (S-CDR)
 GPRS charging data in GGSN (G-CDR)
 GPRS mobile station mobility management data in SGSN (M-CDR)
 GPRS MO SMS data in SGSN (S-SMO-CDR)
 GPRS MT SMS data in SGSN (S-SMT-CDR)
b) Partial records
Please indicate if partial records, specified in 3GPP TS 32.015, are
supported. Please indicate the foreseen CN/node SW release and date.
c) GTP' charging protocol
Please indicate if the GTP' charging protocol is supported. Please indicate
the foreseen CN/node SW release and date.
d) Correlation between PS and IMS charging
The Vender should provide the proposal for the correlation of PS and IMS
charging in SGSN and GGSN.
e) On line charging system
The Vender should provide the online charging system proposal.
f) IP bearer flow charging
The Vender should provide the flow based charging proposal and give the
impacts over CN nodes.

6.10.14 Requirements for GGSN

Hardware and software design

a) The system architecture of GGSN shall be designed as modularization,

and can be expanded flexibly by cascading.

6.10.15 Functionality and Feature Requirements of the GGSN

i) The GGSN (Gateway GPRS Support Node) is a functional entity for
providing packet data services. It is in charge of the routing and
encapsulation of the packet data between the GPRS/UMTS network and
the external PDN.
ii) The proposed GGSN should provides the function that Receive data from
the MS and then routing to the external PDN, or receiving data from the
external PDN and then sending to the SGSN according to the destination
address by selecting a transport channel through the GRPR/UMTS
network.
iii) The proposed GGSN should provide postpaid service. The GGSN
generates and outputs call bills, reflecting how users make use of the
external network.
iv) The proposed GGSN should provide prepaid service. As a service
switching point (SSP), the GGSN serves as connection point between a

106
 radio communications network and an intelligent network, providing call
control function and service switch function. The GGSN should support
CAMEL phase 3 protocol and Diameter.
v) The proposed GGSN shall provide the following routing protocols
interfaces:
a) Static Route
b) RIP
c) OSPF
d) BGP v4
e) MPLS
f) VRRP
vi) The proposed GGSN shall provide the following methods of IP Address
allocation:
a) Static or Dynamic IP Addressing
b) Local GGSN Pools
c) DHCP
d) RADIUS
vii) The proposed GGSN shall provide the following tunneling protocols:
a) IPsec
b) L2TP (PDP type: IP/PPP).
c) GRE
d) IP-in-IP
e) VLAN
f) MPLS
viii)The proposed GGSN shall provide the following QoS functions:
a) QoS Support (3GPP TS 23.107, 24.008, 29.060 GSM 04.08, 09.60,
RFC 791, 2474, 2475)
b) Admission Control.
c) Configurable QoS Mappings.
d) DiffServ Marking.
e) Policing & Filtering
ix) The system shall provide packet filtering options, as well as, IPsec for
security to protect the GGSN against intrusion or denial of service attacks.
This shall include filtering on:
a) source IP address,
b) destination IP address,
c) port number and
d) source routing.
x) The GGSN shall support NTPv3 for time synchronization as per RFC1305.
xi) The GGSN shall support Mobile IP function.
xii) The GGSN shall support HSDPA (maximum 16Mbps QoS bit rate and
guarantee bit rate).

107
 xiii)The GGSN shall support internal DHCP Server.
xiv) The inter-working with PDN shall be based on IP as specified in RFC
791. The interface towards external PDNs shall support:
a) 10 and 100 Mbit/s Ethernet in accordance with IEEE 802.3, IEEE
802.3u.
b) Gigabit Ethernet in accordance with IEEE 802.3z and 802.3ab
c) IP version 4 in accordance with IETF RFC 791.
d) IP version 6 in user plane in accordance with IETF RFC 2460.
e) Routing protocols as follows: OSPF version 2, RIP version 2.
xv) Multiple routing instances (virtual routers functionality) shall be available
for use in different APN
xvi) The GGSN shall be able to interface multiple PDNs simultaneously.
xvii) Both transparent and non-transparent access to external PDNs shall
be supported.
xviii) Radius user authentication shall be supported.
xix) The offered equipment shall provide open standard interfaces. This
implies that the Vender shall share all necessary information with other
Venders when inter-operation is required in Carrier’s network. Any
deviations from this rule shall be explicitly stated by the Vender for each
network entity and interface described in this RFP.

6.10.16 Policy Charging and Control requirements

i) The supplier shall provide a detailed statement of compliance to any
relevant 3GPP standards or IETF RFC documents relating to PCC
architectures. The used version number of these standards shall be
stated.
ii) The GGSN charging function shall be protocol transparent for user data, at
both IP and TCP/UDP level.
iii) It shall be possible to provide the same charging mechanisms for both
postpaid (offline) and prepaid charged customers.
iv) All charging functionality shall be supported for a subscriber using multiple
PDP contexts or secondary contexts. Each context shall be treated
independently with its own quotas.
v) The GGSN shall allow frequent internal securing of billing information onto
non-volatile memory without the need to produce partial CDRs to ensure
that minimal billing information is lost during restart or other exceptional
circumstances. In the event of recovery from such restarts or exceptional
circumstances, the GGSN shall produce CDRs from any billing information
that has not generated a CDR.
vi) Flow based charging shall be supported for all packet switched bearers
GPRS, UMTS, EDGE HSDPA / HSUPA.

108
 vii) The GGSN shall support data volume, time counters per individual service
data flows, for both uplink and downlink packets.
viii)It shall be possible to charge based on a combination of volume and time.
ix) The GGSN shall record used data volume in Bytes.
x) The usage counters shall record all payload (content transfers) on the
GGSN Gn interface. This should include all payload headers and any
signaling traffic used by the Gi. This is all bytes above and including the IP
layer; the volume of the data link layer shall not be counted.
xi) It shall be possible to avoid counting traffic that does not route beyond the
GGSN, e.g. broadcast, multicast messages.
xii) W ith higher layer charging rules (L7) the GGSN should be able to
associate the used traffic flow in-order to account for any lower layer
signaling traffic in the same counters. E.g. HTTP URL rules should include
any associated TCP traffic. W AP URL rules should include any W TP
messages (connections etc).
xiii)The GGSN shall provide the subscriber profile in use to the OCS via every
DCC CCR messages.
xiv) It shall be possible for the OCS to change the subscriber profile used
by the GGSN mid session via DCC CCA, RAR messages.
xv) An online charging service authorization shall be triggered on the first use
per PDP context of a predefined charging service through the GGSN.
xvi) The GGSN shall support per service quota authorizations with volume
quota in bytes, time quota in seconds.
xvii) It shall be possible to configure the GGSN to block unauthorized
charging services or to redirect the service to a web page.
xviii) Prepaid service blocking should function accurately with HTTP
pipelining, HTTP fragmentation/continuation, W SP
fragmentation/continuation and W SP concatenated requests. W here a
method request contains a mix of blocked and allowed requests, the
blocked request should be dropped; the allowed requests should be
extracted and sent.
xix) The vendor shall state any additional delay in the PDP setup time (not
including PPS and data n/w latencies) when the end user is pre-pay and
authorized against a Pre-pay system instead of postpaid.
xx) R.463. The vendor shall state any additional delay (not including PPS
and data n/w latencies) in initial data transfer for a pre-pay customer with
service authorization compared to a postpaid customer.
xxi) The Vendor should describe the supported solution for “content”,
“volume” and “time” based charging including on-line charging
mechanisms for home and roaming use-cases.
xxii) The vendor should describe the signaling process capability on GGSN

109
 when Diameter interface is used.

6.10.17 GGSN Service Control Functionality

i) All GGSN service control functions shall be configurable to be applied:
 globally across a GGSN
 on a per APN
 On a subscriber / service profile level.
ii) It shall be possible for a subscriber to be assigned subscriber profile(s) by
RADIUS on authorization and authentication of their PDP Context. The
profile(s) shall determine the GGSN functions and services used for that
subscriber.
iii) R.390. If a subscriber profile is used, this profile shall supersede any
global or APN level profiles. The order of precedence (highest first) shall
be:
 Subscriber Profile
 APN
 GGSN
iv) It shall be possible to set a default subscriber profile per for an APN for
users who do not have any subscriber profile defined. Any subscriber
profile provided in RADIUS Access response will over-ride the default
subscriber profile.
v) The vendor shall provide information of other functions that may be
defined on a per subscriber profile / service profile level.
vi) The GGSN shall support Single APN functionality to enable the use of a
single APN for a subset of customers (e.g. corporate customers) and yet
be able to invoke services on a per subscriber basis including VPN
membership, tunnel set, and services based on RADIUS service profile
attributes returned.
vii) The solution shall be able to identify services using a combination of
application and protocol awareness using state full (flow based) detection.
viii)The Protocol Analyzer shall be capable of detecting protocols based on a
combination of destination IP address, source IP address,
source/destination TCP/UDP port number (or range), URL or IP protocol
identifier.
ix) The protocol and application detection calls for (flow based) packet
inspection of OSI layers 2 & 3 + URL. Deep packet inspection is the ability
to further analysis flows based on OSI layers 3-7 and using trends across
packets.
x) The GGSN Protocol Analyzer shall be capable of state fully detecting
protocols to Layer 7, utilizing where required heuristic analysis or pattern
recognition to find a statistically certain match.
xi) The GGSN shall support complex, heuristic or statistical signatures to

110
 detect
 HTTP
HTTPS
WAP
i-mode
FTP
TFTP
MSN Messenger 7.5+
Yahoo! Messenger
SMTP
POP3
SKYPE
Google Talker
xii) The DPI function must be integrated in GGSN itself.
xiii)The vendor shall describer the GGSN throughput in the following models:
(1) Normal(without DPI)
(2) 100% L3/L4 inspection
(3) 100% L7 inspection
xiv) The GGSN shall support PDP Contexts using Rel. 97 QoS
xv) The GGSN shall support PDP Contexts using Rel. 99 QoS.
xvi) The GGSN shall be able to diffserv mark packets according to the R97
or R99 QoS parameters.
xvii) The mapping of 3GPP QoS to diffserv shall be operator definable to
bitcode level to allow further flexibility.
xviii) The GGSN shall recognize diffserv markings and apply operator
defined policies based on these markings. The policies shall include
mechanisms to perform the following based on diffserv mark:
xix) The GGSN shall ensure that any 3GPP Release 5 extensions for
HSDPA are accurately captured in RADIUS, G-CDRs and prepaid.
xx) The proposed PS must support the statistics based on the following
parameters and mixed:
(1) Bandwidth
(2) Connections
(3) Transactions
(4) Protocol/Application
(5) Service server
(6) W ebsites
(7) Subscribers
xxi) The statistics can be output as defined format, such as: PDF or CSV.
xxii) The display of statistics output can be table, chart(area), chart (lines),
etc.
xxiii) The file of statistics can be scheduled to send to configured email when
available.

111
6.10.18 Performance, capacity and connectivity
i) The proposed GGSN Server shall have large capacity with activate 3
million Packet Data Protocol (PDP) contexts at the same time, high
performance with handling as much as 30Gbit/s of throughput and
abundant of interfaces.
ii) The Vender shall give a description about physical and logical network
element connectivity for minimum configuration and per each additional
capacity step up to maximum configuration.
iii) The Vender shall give a detailed description of the capacity steps and
limits of any variants/models of all GGSNs. The descriptions shall, when
applicable, include the following per variant/model:
a) Number of simultaneously active PDP contexts, per capacity step
and maximum per entity.
b) Throughput measured in packets/second and kbit/s, per capacity
step and maximum per entity.
c) Interface characteristics (number of links/connections possible per
interface, capacity per interface), per capacity step and maximum
per entity.
iv) The GGSN shall be designed, built and developed on a carrier grade
platform.
v) The GGSN shall allow the application of patches / corrections without
impact to subscribers. The vender shall provide details on the patch /
correction process for their platform.
vi) The GGSN shall be designed such that any hardware / software fault is
localized and impact to subscribers is minimal. The vender shall provide
details of software/hardware fault handling process for their platform.
vii) All the boards in the GGSN should 1+1 hot backup redundancy and
should support hot-swap.
viii)The Vender shall detail the number of concurrent active attaches and
active PDP sessions supported in the various configurations of the GGSN.
ix) The Vender shall give a detailed description of overload protection
mechanism.

6.10.19 Evolution
i) The Vender shall describe all necessary function migration from 3GPP
Release 4 to Release 6.
ii) The proposed GGSN shall support evolution to SAE GW.

6.10.20 O&M
i) The vender should introduce the structure and functions of the O&M
system of proposed GGSN, including:

112
 a) Alarm management
b) Equipment management
c) Message tracing
d) Data configuration management
e) Security management
f) Log management
ii) The O&M system should signaling tracing and interface based signaling
tracing. (include Gb, Iu, Gn, Gp, Gi, Gr, Gd, Gf, Ge, Gs, Go, Gx, Gy, Lg).
The signaling tracing function should have signaling analyzing function.
This function should not from the third party’s software.
iii) The O&M system should support subscriber tracing by IMSI or MSISDN

6.10.21 Requirements for CG(Charging Gateway)

General requirements for CG

The proposed CG(Charging Gateway) equipment is a product developed with well

compliance with relevant 3GPP standards for UMTS solutions. It can help
Carriers to construct cost-efficient and future-oriented mobile communication
networks.
i) The proposed CG equipment is located between the UMTS network
entities (including GGSN and SGSN) and the billing center, and provides
the mechanism to transfer charging information from the UMTS network
entities to the billing center. It shall support R98/R99/R4/R5 protocol and
related functions:
a) Collecting CDRs from the UMTS network entities.
b) Intermediating CDR storage buffering.
c) Processing CDR data.
d) Transferring the CDR data to the Billing Centre.
ii) The proposed CG should support ANS.1 format and FTP/FTAM/SFTP
transmission protocol.
iii) The Vender shall provide Charging Gateway (CG) as a centralized
separate network element.
iv) The Vender shall describe the CGF implementation for UMTS and GPRS
network nodes with reference to relevant 3GPP standards
v) The Vender shall describe supported formats of CDRs.
a) G-CDR;
b) S-CDR;
c) M-CDR;
d) S-SMO-CDR;
e) S-SMT-CDR;
f) LCS-MO-CDR;
g) LCS-MT-CDR;

113
 h) LCS-NI-CDR;
vi) The Vender shall list all CG supported interfaces with network elements
and billing system.
vii) The Vender shall describe supported file management and transfer
mechanisms towards billing systems.
viii)The CG shall be able to buffer CDRs from a number of packet core
network elements for a period of time.
ix) The Vender is requested to provide capacity figures for the CG, e.g. buffer
sizes, number of CDRs processed per second, etc.
x) Partial and periodical output of charging data shall be supported. The
Vender shall provide information on each supported mechanisms.
xi) Fail over mechanism shall be described. CDR duplication prevention
mechanism shall be implemented.

6.10.22 Requirements for NAU (Network Auxiliary Unit)

i) General

In addition to the GSN core portion (SGSN & GGSN) and CG, the Vender
shall include internet support server nodes to support GPRS/UMTS services.

ii) DNS

The Vender shall support the Domain Name Server Function which resolves
logical GSN names (Internet domain and host name) to GSN addresses
according to RFC 1034. Such functionality allows resolution of any name for
GSN's and other nodes within the packet domain PLMN backbone network.
The GSN system shall also have a redundancy DNS server.

iii) DHCP

The GSN system shall support DHCP for the management of IP address
allocation. The Vender shall provide details on the solution offered.

iv) BG

Two intra-PLMN backbone networks are connected via the Gp interface using
Border Gateways (BGs) and an inter-PLMN backbone network. The inter-
PLMN backbone network is selected by a roaming agreement that includes
the BG security functionality. The BG is not defined within the scope of the
packet domain in the 3GPP specifications. The inter-PLMN backbone can be
a Packet Data Network, e.g., the public Internet or a leased line.
a) It shall be possible to interface other 2G and 3G PLMNs. Administration
and security on these interfaces shall be handled by Border Gateways
(BGs). A BG may be a separate entity or it may be integrated into a
GGSN.
b) The PLMNs shall be inter-connected via a PDN, but as the

114
 characteristics of this interface will depend on roaming agreements with
other PLMNs, the BG needs to be configurable.
c) Sessions between Carrier's own GGSNs may also be done via BGs. The
BG shall constitute router and firewall functionality.

v) FW

a) The interconnection to external PDNs or inter-PLMN (GRX) backbone

shall be done via Firewalls (FW s). FW s can be implemented either as
stand-alone devices or as resident functionality in the GGSN and BG.
b) The FW shall support the following functions:
1. Stateful firewall
2. Packet filtering based on IP address or IP address pools …
3. Application level gateway (proxy)
4. Network address translating – NAT, NAPT
5. Access control lists
6. Secure IPSec connection with DES, 3DES, … encryption
7. Advantage is support for traffic shaping (per interface, per user
session, per flow)
8. Logging of all events with important pieces of information as a date,
time, IP addresses, interfaces
9. Static routing
10. Dynamic routing protocols OSPF v. 2 and RIP v. 2.
11. In case of NAT/NAPT there shall be possibility to log time and
combination of public IP, private IP and ports, which was used by one
customer.

6.11 Over-the-Air (OTA) Server:

6.11.1 The OTA platform shall be suitably dimensioned to cater to an extent of

60% of the Subscriber Capacity.
6.11.2 OTA platform should be capable of Over the Air updates to SIM/USIM cards
from all SIM/USIM vendors without any dependence on any SIM/USIM card
manufacturer. If required, the OTA platform shall be able to manage the
existing SIM cards also. The OTA platform shall be capable of generating
Public and Private keys for writing to individual SIM cards at a Point of
Sale(MTML Registration Authority) and be capable of writing the keys to the
SIM card using a card reader as per PKCS 15 Standard.
6.11.3 The OTA platform should be able to manage menu structure on SIM card
whereby SIM applets should be able to interact with application using SMS
as bearer transport to OTA server. The Browser shall be able to encrypt and
sign application data as per the PKCS 7 standard for mobile commerce and

115
 authentication applications using SIM based private keys stored on the SIM
card as per PKCS#15 standards. Additionally, the browser shall be able to
execute symmetric security schemes for signature and ciphering to enable
secure m-commerce applications.
6.11.4 The OTA platform shall be capable of storing network information, such as
to provide cell-id / landmark based subscriber location information to SIM
browser applications.
6.11.5 OTA platform shall have the capability to send and receive 7 bit and 8 bit
encoding messages.
6.11.6 OTA platform shall communicate with the GSM/W CDMA network entity
using the SS7 interface, so as to provide higher capacity on the messaging
interface.
6.11.7 The OTA platform shall have SS7 interface towards GMSC or MSC
SERVER AND MEDIA GATEWAY and shall be able to perform the message
transport functions as per GSM 03.48, without using the MTML SMSC.
6.11.8 OTA platform shall have interfaces to directly interconnect with gateway
MSCs of each licensed service area.
6.11.9 OTA platform shall have the functionality to receive MO messages over
SMPP interface.
6.11.10 OTA platform shall have GUI interfaces for operations management and
administration activities
6.11.11 OTA platform shall support message concatenation
6.11.12 OTA platform shall have "More Messages to Send" feature to enable faster
delivery of concatenated messages
6.11.13 OTA platform shall provide service menu management on the SIM card for
at least two levels. I.e. it should be possible to modify a service by adding or
deleting second level SIM Service Menus, without deleting or adding the
Main Service Menu.
6.11.14 OTA platform shall provide self-provisioning feature for the subscriber on
web interface as well as by the subscriber on SIM card using the menu
options. OTA platform shall be suitably protected through a firewall to be
provided by vendor.
6.11.15 OTA platform shall support Batch OTA updates for bulk updates and shall
also be able to push 8-bit messages.
6.11.16 Services integrated with OTA platform

6.11.16.1 Preferred Roaming Application

a) The OTA server must have capability to provide MTML a Preferred Roaming
application, that enables its subscribers to remain in the Preferred Roaming
networks configured in the subscribers SIM, while roaming.

b) The Roaming Management capability in OTA shall be able to facilitate

automatic (without subscriber intervention or knowledge) preferred network
selection in a visited Network, where GSM service exists from two or more
GSM Service Providers, and MTML has Roaming agreements with those
other networks.

c) The OTA shall be able to connect to the SS7 roaming links of MTML, and use
dynamic network information such as VLR registration, to detect a
subscriber's PLMN selection, check the SIM subscription information for
preferred networks, and be able to make OTA updates to the SIM card

116
 attributes, that facilitates the movement of subscriber from the non-preferred
network to the Preferred Network in real time.

d) The Preferred Roaming application should be able to make differential SIM

updates depending on the Handset capability. The Handset capability shall be
either discovered automatically in real time, or be configurable in the OTA
database such as to make the SIM update procedure selection in real time.

e) The purchaser must be able to configure such timers, as can facilitate

masking of the SIM updates for a time since the last SIM update activity. The
purchaser must also be able to configure the preferred vs Non-preferred
PLMN information on the OTA database. It shall also be able to configure a
set of 'In consequential' PLMNs, where no SIM update activity is carried out
for purposes of Roaming Management.

6.11.16.2 Device Configuration for GPRS / M M S / WAP Settings

(i) MTML's networks shall be GPRS & MMS capable, and a solution shall be
provided for automatic over the air setup of Handsets for GPRS, WAP, and
MMS & E-MAIL settings.

(ii) The Solution should maintain a repository of Terminal IMEI vs Terminal

Capabilities. The Solution should be able to send Handset specific WAP,
MMS, GPRS settings over the Air.

(iii) The OTA systems solution should be able to automatically detect the Phone
IMEI, each time a SIM is inserted into a New Phone using network based
detection mechanism. The Solution should then be able to Over the Air setup
the Device with the handset specific, Network specific settings for W AP /
GPRS / MMS / E-mail.

(iv) There should be an alternate W eb interface for Customer Care to set up a

subscriber's device.

6.12 APPLICATION AND ADVERTISEM ENT PUSH SERVER:

6.12.1 The server shall interface towards W AP server and OTA server. The
solution shall be able to dispatch W ML pages, carrying New Applications or
Promotional Messages, to a targeted set of subscribers (10% through W AP
& remaining through OTA) Such messages should provide an interactive
capability for the subscriber to respond with the click of a Menu Item to
reach Internet Pages embedded in the W ML page.
6.12.2 The server shall be dimensioned for meeting the requirement of 60%
subscribers.

6.13 OPERATIONS SUPPORT SYSTEM (OSS)

6.13.1 Operations Support System to meet the requirements as envisaged in the

relevant TEC GRs may be quoted.
6.13.2 The OSS should be centrally located to control, configure and monitor faults
and performance of the complete network elements. It shall provide all the
functionalities and features as defined in TEC GR pertaining to
configuration management, performance management and fault

117
 management etc. In addition, the system shall provide following
functionalities and features-

i. Periodic presentation, at settable intervals, of brief as well as detailed

status/analysis of network in network wise, BSC wise, Cell wise forms
indicating major parameters as applicable such as:

(I) Call Volume

(II) Call Set up success rate
(III) Call success rate
(IV) Drop rate
(V) Traffic in erlangs
(VI) Congestion Key/Grade Of Service
(VII) Hand over failure rate
(VIII) Call Minutes (l/c, 0/G)
(IX) TCH/SDCCH Congestion
(X) Max TCH Available/used (%)
(XI) Max SDCCH Available /Used (%)
(XII) BSC-TXCDR trunk usage

ii. The above parameters/measurements shall be presented in EXCEL

sheets in tabular as well as well as in chart forms. Facility to display Snap
shots of selected parameters during different periods shall be provided. It
shall also be possible to display all sorts of dynamics in continuous as
well as discreet modes. (E.g. Total BSC W ise traffic on different days of
the same week or on the same day of different weeks, the build up of
congestion on new year eve etc)

iii. Quality Checks: The OSS shall be equipped with appropriate tools to
perform all kinds of analyses based on quality related parameters such
as interference levels, BERs, FERs, hand overs, etc. It shall provide
analysis such as:

a. Percentage of calls with RXQual 0 to 3 in a particular cell

or Average RxQual/CSSR for TA between 0 to 5 as against
the same for TA between 6 to 10.
b. RXQual in a cell over different periods of the day

iv. Periodic automated reporting of downtimes of network elements such as

BTSs, BSCs etc on triggers, which are time-based as well as severity-
based thresholds.

6.13.3 The hardware and software implementation should be independent of the

current OMCs and should be server based with a minimum of seven clients.
The dimensioning should be such that all the data required for post
processing can be stored for a minimum one months on line and there
should be provision for storage one year externally.
6.13.4 There also should be an integrated or separate tool with user friendly menus
for call traces based on IMSI, TMSI, IMEI or MSISDN to give the Timing
Advance, Current RX Quality, Time slot, TRX Et cell identity, CIC etc in order
to facilitate problem isolation as well as other operational purposes.
6.13.5 GUI display showing menu driven options of various network elements for
display of event/ alarms, configuration management, performance

118
 management, security management, fault management down to board level
and network statistics.
6.13.6 Historical data for a minimum period of one month to generate detailed daily
reports and summary weekly, fortnightly, monthly, quarterly, half yearly and
yearly reports should be available online and there should be provision for
storage one year externally.
6.13.7 The OMC(R) and OMC (S) shall also support full functionality for GPRS,
EDGE & W CDMA. The OMC(R) shall provide on-line configuration and
administration of EDGE carriers and for GPRS TCHs in BTS. Performance
monitoring system (PMS) shall provide all statistical reports for GPRS,
EDGE & W CDMA for usage analysis, performance analysis and for future
planning. Necessary post-processing tools shall also be provided along with
OMC for this purpose.

6.14 GSM BSS :

Base Station Sub System as per GSM 3GPP Standards is to be quoted.

6.14.1 General requirem ents

1. Products specifications shall be provided in sufficient detail to enable full
understanding the GERAN products offered by the Tender Participant.

2. The tender participant shall specify the SW version proposed in tender.

3. The supplied system shall have no effect on service when BTS expansion and
frequency modification with in the same band.

119
6.14.2 BSC/TC (Transcoder) architecture
1. The supplied BSC shall be based on IP platform. It shall support both TDM
switching for the TDM based services and IP switching for the IP based
services.

2. The supplied BSC shall support embedded PCU which shall be formed as
boards. The tender participant shall specify the embedded PCU architecture.

3. The supplied BSC shall support embedded TC which shall be formed as

boards. It is important if the BSC is deployed together with the core network.
The tender participant shall specify the embedded TC architecture.

4. Only one High Capacity BSCs should be provided.

6.14.3 BSC/TC dimensioning, feature, configurations and capacity

1. The tender participant shall indicate the capacity & configurations of
BSC/TC provided.

2. The BSC shall support at least 1000 TRX which shall be accommodated just
in one cabinet. The same single BSC cabinet shall also be possible to
accommodate PCU and TC.

3. The supplied BSC capacity and performance shall not be decreased

because of Packet Service. The Tender Participant should specify the TRX
capacity of single cabinet BSC when 50% channels are used as EPDCH.

4. The Transcoders shall fully support Full Rate, Half Rate and AMR FR/HR
speech coding dynamically allocated in a common transcoder pool per BSC.
The tender supplier shall specify the mechanism of TC pooling, any
influences on capacity by type of used codec shall be pointed out.

5. The Tender Participant shall state typical downtime caused by BSC/TC

capacity upgrade, if any.

6. The supplied BSC shall support Multi-band Sharing in one BSC.

7. The Tender Participant should provide full support of ciphering in BSC/TC.

6.14.4 Interface
1. The Tender Participant shall specify the maximum number of ports for
available BSC/TC configurations, including the flexibility with mixing different
physical interface types.

2. The Tender Participant shall describe the boards available to support these
physical interfaces and give the number of ports for each board.

3. The Tender participant should support BSC/TC configuration with High

Speed Link (HSL).

6.14.5 Power supply requirements and power consumption

1. The BSC/TC shall operate with -48V DC.

120
 2. The BSC/TC shall support redundant power supply to ensure the system
operation keeping working without power interruption in case that either fails.
The tender participant shall specify the redundancy arrangement.

3. The tender participant shall specify the power consumption of the supplied
BSC/TC. The tender participant could list the power consumption values of
typical configuration.

6.14.6 BSC/TC mechanical construction

1. The Tender Participant shall state the weight, cabinet dimension, maximum
floor loading and necessary area for proposed configuration.

6.14.7 BSC/TC reliability

1. All the critical modules/units of the BSC shall support 1+1 redundancy mode
and resource pooling processing modules/units shall support N+1
redundancy mode. The tender participant shall specify the mechanism of
module/units redundancy of BSC.

2. The Tender Participant has to describe the hardware availability

performance of the BSC/TC. The target availability should exceed 99.999 %.

3. The Tender Participant shall describe all types BSC/TC restart and their
impact on service. The Tender participant shall give restart time for each
type of restart and indicate if the BSC/TC is partly or completely out of
service during the restart.

6.14.8 Transcoder
1. Average Traffic per subscriber – 25mE
2. Transcoder should preferably work in pool so as to give optimum
performance.
3. Entire Transcoder capacity for all codes (AMR/FR/EFR).

6.15 Base Transceiver Station

6.15.1 BTS requirements

Supplier shall present his full range of BTS equipment. This includes indoor and
outdoor cabinets of different sizes, purposes and capabilities. In addition to the
general GSM requirements, Purchaser wants to emphasize the following issues:

6.15.2 BTS equip ment

1. The successful bidder may quote distributed BTS (SDR) containg BBU &
RRU units. The BBU & RRU can be software upgradable to HSPA under the
same frequency band.

2. The minimum number of BTS sites expected to provide the desired coverage,
as per our estimation, is 110. However, if the bidder feels that more number of

121
 BTSs are required to meet the desired coverage/ capacity requirements, the
same should be quoted accordingly.

3. Purchaser plans to deploy around 50 indoor BTSs (BBU only) in the existing
shelters and remaining 60 outdoor type BTSs. The efforts should be made to
use the maximum number of existing CDMA BTS (51/56 sites) infrastructure
(shelter, tower, power etc.).

6.15.3 BTS product specification

BTS
Specification BTS Outdo
Indoor or BTS BBU
Capacity
1 Nb. of TRX / cabinet
2 Nb. of carrier / site
3 Nb. of cell / site
Nb. of transmission
4 Port
Performance
1 Frequency band
Transmitter power
2 output
TOC (Top of cabinet)
output power per
3 carrier
Receive sensitivity
level (static, 2-
4 way, 4-way)
Engineering
Parameters
Dimensions (H*W *D
1 mm)
2 W eight (Kg)
3 Power supply
4 W orking temperature
5 Cooling mode
Reliability
1 System Availability
2 MTBF
3 MTTR

6.15.4 BTS architecture and layout

1. The Tender Participant shall describe and illustrate the general architecture for
each BTS type including radio units, baseband, control, and
transport/transmission parts.

2. The supplied BTS shall be equipped with Dual Density Transceiver Unit at
least.

3. All supplied BTS shall support GPRS/ EDGE for each sector of sites.

122
 4. The supplied BTS shall support Abis over IP.

5. The supplied BTS shall be design with simplified modular design, in order to
easy upgrade, fast engineering and convenient maintenance.

6. The supplied macro BTS shall be with high integration architecture, it can
support stack installation. The tender shall specify the stack mode.

7. The tender participant shall propose distributed type BTS for fast deployment.
The supplied BTS can be separated to install separately. The RF unit can be
mounted on pole or tower where close to antenna in order to eliminate feeder
loss to get better coverage. The supplier shall explain if there are any
limitations while installing distributed type BTS near to the antenna.

8. The tender participant shall clearly explain the others flexibility of installing the
distributed type BTS.

9. The supplied remote RF unit shall be designed on nature cooling mode to

reduce noise, lower power consumption, and to improve reliability.

10. The supplied BTS shall be able to provide multi-carrier Transceiver Unit or in
the roadmap, at least 6 TRX/Unit. The tender participant shall specify the
specification multi-carrier Transceiver Unit.

11. In case of multi-carrier Transceiver unit configuration, the supplied BTS shall
not be configured with combiner.

6.15.5 BTS configuration and capacity

1. The supplied BTS equipment shall support multi-band cells in one rack.

2. In case of chain networking, the supplied BTS shall support Abis bypass to
guarantee no effect on other BTS operation when one of them is broken.

3. The Tender Participant shall provide full HW support of ciphering in BTS.

4. The tender participant shall provide configuration principle of provided BTSs.

6.15.6 BTS power consumption and power supply requirements

1. The tender participant shall state the typical and maximum power
consumption for every type of supplied base stations by filling in the following
table.

The output power of TOC in S222 configuration shall be 30W at least (Cabinet
Type BTS), 30W at least (Distributed type BTS) per career;

The output power of TOC in S333 configuration shall be 20W at least (Cabinet
Type BTS), 20W at least (Distributed type BTS) per career.

6.15.7 BTS Reliability

1. The Tender Participant shall specify the BTS MTBF from maintenance point of
view by combining the MTBF figures of all plug-in units in the configuration.

123
 2. The Tender Participant shall describe all types of BTS restart and their impact on
service. The Tender Participant shall give restart time for each type of restart and
indicate if the BTS is partly or completely out of service during the restart.
3. BBU control card should support active and standby configuration.
4. The vendor shall provide external lightning proof device for outdoor BTS.

6.15.8 Environment characteristics

1. The Tender Participant shall aim to minimize any audible noise from their
equipment and explain means to achieve this.

6.15.9 Outdoor solution requirements

1. The supplied out BTS equipments shall fulfil W eather Proof Protection based on
ETSI Standard. The tender participant shall specify the water proof and dustproof
level of supplied outdoor units.

2. The Tender Participant’s outdoor BTS’s shall utilize a natural air flow or forced air
cooling mechanism. It shall not be necessary to use an air conditioner as a
cooling mechanism for any of these BTS although this may be offered as an
option.

3. The supplied outdoor BTS equipment shall withstand the local atmospheric and
weather conditions. The outdoor units’ working temperature shall range from -
40o C to 45o C without air conditioner.

4. Supplier shall purpose mini outdoor BTS for medium and low capacity
configuration which may have flexible installation mode like installation on the
poles, walls, tower etc. The tender participant shall state the different installation
modes and limitations.

6.15.10 Future evolution

1. The supplied BTS shall support 2G/3G configuration and be able to share cabinet
with NodeB. The tender participant shall specify the 2G/3G configuration.

2. The Tender Participant shall provide a roadmap for the introduction of new BTS
hardware, hardware modules or software.

3. The Tender Participant shall describe his solutions for efficient co-siting of 2G
and 3G base stations.

4. The supplied BTS shall use the same platform with 3G NodeB so that it can
easily be upgraded to 3G NodeB and support flexible configuration between 2G
BTS and 3G NodeB as per the user demand.

5. The supplied Macro BTS shall mix configuration or inter-changeable with 2G RF

unit and 3G RF unit in one cabinet. Any limitation of mix configuration shall be
stated.

6. The Tender Participant shall specify all dedicated hardware and software
required in the supplied BTS to support advanced GERAN services.

7. Regarding future evolution, most units of supplied BTS shall be reused. The
tender participant shall specify all dedicated hardware and software required in
the supplied BTS to upgrade from 2G to 3G.

124
6.16 GERAN features requirements
Purchaser is aiming to build a high-quality network with state of the art functionality
and features. The tender participant shall detail all his GERAN network features. All
other network elements, which are influenced by such features (MSC, BSC, BTS,
and OMC) shall be addressed clearly. Any dependencies between features of BSS
and features required in other network elements shall be clearly stated.
The full range of BSC/BTS Equipment tendered shall support the following GERAN
functionality and features. W here any feature is not available, the availability date
shall be stated in the GERAN feature roadmap.

6.16.1 General requirements

1. The Tender Participant shall clearly indicate SW version proposed in the Tender.

2. That software updates and new software releases shall be loaded to GERAN
network elements with minimal downtime and impact on live traffic. The tender
participant shall declare any impacts during the activation of the new software.

3. The supplied system shall support full multi-band networking.

6.16.2 Transmission
1. The tender participant shall describe its dynamic resource allocation for Abis
resources when it is supported in the PS service and CS service.

2. The supplied system shall support flex assignation on Ater interface. This
function will assign Ater interface resources according to the needs, e.g. while
using HR this function will assign 8K TS transmission resource for Ater interface
instead of assigning 16K TS transmission resource.

3. The supplied system shall support local switching function both on BSC and on
BTS to reduce transmission, as and when the standards are frozen from 3GPP.
The tender participant shall also specify, whether there is any modification on
GERAN part.

4. W hile supporting local switching, there shall not be any impact on NSS part and
GERAN part can work with the NSS part provided by any other vendor.

5. The tender participant shall support Abis/A/Ater/Gb over satellite

6. The tender participant shall support EDGE over satellite.

7. The supplied system shall support Gb over IP

8. The supplied system shall support 2G and 3G co-transmission based on TDM or

IP.

6.16.3 Intelligent power management

1. The supplied system shall support assign the TCH to the TS of BCCH carrying
TRX unit in priority.

125
2. The supplied system shall support intelligent power shutdown of PA based on
TS level. The tender participant shall describe the TS level power shutdown
mechanism.

6.16.4 Voice Service

1. The supplied system shall support EFR/FR/HR. The tender participant shall state
the limitations in capacity of BSS product while supporting HR.

2. The supplied system shall support AMR FR/ AMR HR. The tender participant
shall list all necessary additional hardware and software requirements on the
BTS/BSC/TC, if any.

3. The supplied system shall support dynamic adjustment between FR/HR, AMR
FR/ AMR HR during a call to balance the capacity and voice quality. The tender
participant shall specify the dynamic adjustment mechanism.

4. The supplied system shall support TFO/TrFO, support AMR TFO.

5. The tender participant shall provide at least 5 references of their HR applications

out of the country of origin. Out of which two should at least have 2000TRX in
use.

6. The tender participant should provide application list and references for their
AMR application out of the country of origin.

7. The supplied system shall support AMR coding rate threshold adaptive
adjustment.

6.16.5 Handover
The supplied system shall support kinds of handover as follows:

Description
Basic Handover: intra-BSC handover (supporting intra-
cell handover and intra-BTS inter-cell handover), inter-
BSC intra-MSC handover inter-MSC handover
PBGT Handover
Signal Level Rapid Fall Handover: This handover
algorithm is sensitive to the signal level change of the
users. It can effectively reduce the call drops due to
the rapid change of signal level.
Load Handover
Layered and Hierarchical Handover
Directed Retry
SDCCH Handover

6.16.6 System reliability

1. The supplied system shall support BCCH TRX Cooperation and baseband FH
TRX cooperation, in case of BCCH TRX failure or baseband FH TRX failure.
The cell can handle it automatically through the TRX Cooperation function, and
cell services wouldn’t be affected.

2. The supplied system shall support MSC pool. Any limitation shall be stated.

126
3. The supplied system shall support SGSN pool. Any limitation shall be stated.

4. The boards of supplied system, except those of the resource pool, shall support
1+1 board backup. W hen the active board is faulty or needs replacing, the
services would be switched to the standby board for continuous operation of the
system. The tender participant shall specify the duration of active/standby board
switchover, and shall state the effect on ongoing service.

6.16.7 Coverage enhancement

1. The supplied system shall support Power Amplfying Technology, which can
increase the TRX output power.

2. The supplied system shall support Transmit Diversity and 4-way receiver
Diversity.

3. The tender participant shall support radio head remote installation, which
enables fewer feeders’ loose to improve the coverage effect.

6.17 GPRS/EDGE service

6.17.1 General requirements

1. The supplied system shall be EDGE enabled for all BTSs.

2. The supplied system shall support GPRS CS1~CS4, EDGE MCS1~MCS9.

3. To improve the efficiency of G-Abis, the supplied system shall support the unit of
16 kbit/s TS assignment for PS service on Aibs. The tender participant shall
specify the TS allocation mode on Abis for PS service.

4. The supplied EDGE system shall support Link Adaptation and Incremental
Redundancy in UL/DL.

6.17.2 GPRS/EDGE enhancement

1. The supplied PS system shall support extended TBF.

2. The supplied PS system shall support Extended Dynamic Allocation.

3. The supplied system shall provide functions which reduce access delay, such as
Immediate Assignment Function Moved down to the BTS. The tender participant
shall describe these functions.

4. The supplied system shall support NACC (Network Assisted Cell Change)

6.17.3 GPRS/EDGE resource enhancement

1. The supplied PS system shall support load sharing of channels in order to balance
the load between heavy load channel and light load channel.

127
2. The supplied system shall support adaptive adjustment of uplink and downlink
channels according to data service load.

3. The supplied system shall support PDCH dynamic adjustment, which allows
dynamic PDCH/TCH channels can be converted in real time based on the data
service and the voice service.

6.17.4 QoS
The QoS class shall be up to Streaming.

6.17.5 Public Voice Group/ Broadcast Call Service

1. The supplied system shall support public voice group call service.

2. The supplied system shall support public voice broadcast call service.

6.17.6 O&M
1. The supplied system shall be able to manage 2G and 3G network at the sam e
time, including RAN and Core part.

2. The supplied system shall support CORBA, OpenDB, SNMP, FTP north-bound
interface.

3. The supplied BSS equipments shall support remote upgrade.

4. The supplied system shall support BTS Antenna System Connection Detection to
locate the problems in the BTS antenna system.

5. The supplied OM system shall support script development platform which provides
script edit, script debug, run script, time mission, etc. easier for the operator create
their own automatic daily OM procedure.

6. The supplied system should support signalling tracing for A, Ater, Gb, Abis, Um
etc.

7. The supplied system should support signalling tracing upto user level (both CS and
PS user).

8. In order to avoid the fault in the network, the offered system should be able to do
periodic health check up for the following items and automatically output a network
quality report, including BSC running status check, alarm check, KPI status check,
version matching check, etc. The tender participant shall state whether these
check up can be done automatically as per user defined items and time.

6.17.7 General requirements

1. Products specifications shall be provided in sufficient detail to enable full
understanding the GERAN products offered by the Tender Participant.

2. The tender participant shall specify the SW version proposed in tender.

3. The tender participant shall provide at least 5 contract reference (at least 3
networks with more than 10000 TRXs/ reference) for the proposed BSS Network.

4. The supplied system shall keep no effect on service when BTS expansion and
frequency modification.

128
5. The tender participant shall provide a figure for All IP BSS solution. It should include
Abis, A and Gb interface in the BSS network.

6. The tender participant shall specify clear what kinds of new NEs or equipments
needs to be added when the BSS network evolves from A over IP only to All IP
Network.

The tender participant shall provide at least 1 BSS contract reference for the
commercial All IP.

OPERATION & SUPERVISORY SYSTEM

6.18.1 The communication facilities provided for exchange of information between

the system and the maintenance and operating personnel shall include
facilities for a system test and control and alarm indication.

6.18.2 Input/output terminals shall be capable of transmitting/receiving characters of

a subset of the Alphabet No.5 as specified in ITU-T recommendation Z.314.
The printing/display device shall print/display different graphic symbols for the
digit zero and the capital letter O. The Input/Output terminal shall have the
English Keyboard. Capabilities of visual display terminals shall be as per ITU-
T Recommendation Z-322. Terminal emulation software and any standard
operating system shall be available in the PC.

6.18.3 Adequate number of man-machine interfaces shall be available to facilitate

various types of system administrations listed.

6.18.4 If provision is made for monitoring from a remote terminal, it shall be ensured
that the data links conform to the ITU-T Recommendation Q.513. Care shall
be taken that the reliability of the data links does not, in any way affect the
reliability of the system. Special provision shall also be made for
transmission of a failure signal even when the system is unable to transmit an
output message.

6.18.5 A suitable alarm and display system shall be provided for a continuous
indication of the system status. The alarm system shall also provide an alarm
to indicate the failure of power supply to the alarm circuits themselves.
Provision shall be available to extend indications to a centralized place.

6.18.6 On a fault condition the system shall identify the faulty sub-system
automatically and takes it out of service. This shall automatically bring in the
diagnostic programmes for diagnosis. In such cases the details of the sub-
systems taken out for executing diagnostic programmes shall be printed out.
Availability of Intelligent terminal (PC) to display the location of bay, shelf,
PCB on the screen would be desirable. The dimensioning of processing
capacity shall be such that the normal call processing is not effected due to
invocation of any diagnostic program.

6.18.7 Operations and M aintenance Centre (OM C)

a) The OMC allows the centralized operation of the various units in the
system and the functions needed to maintain the sub systems. The
OMC provides the dynamic monitoring and controlling of the network

129
 management functions for Operation and Maintenance (O&M). The
OMC shall support Graphical User Interface (GUI) for operation and
standard TMN interfaces as specified in ITU-T Rec. M-3010 & M-3020.

b) The overall objective of OMC is that neither equipment failure nor

human error in the OMC implementation should render the OMC and
/or the part of the network it supervises, out of service.

c) OMC shall be a carrier grade system with full redundancy and

scalability. It shall be possible to have remote workstations with the
OMC, with complete GUI tools for O & M of the system at the remote
locations. It shall support north-bound interface like SNMP, Corba, TCP
/ IP, CMIP etc., to enable it to work with a remote NMS.

d) The Operation & Maintenance Centre (OMC) shall be capable of

performing the following functions: -

(i) Event/Alarm M anagement: Alarms shall be presented to the

operator via software programs and tools for easy presentation and
interpretation, for easy maintenance and to locate faults of all
managed elements of the network. Events shall be logged for future
use.
(ii) Configuration M anagement: OMC shall provide real time
configuration database access to manage the software loading and
version tracking, support for addition, deletion and change of network
element parameters.
(iii) Performance M anagement: OMC shall provide tools for the
collection of statistics and call information into a database and
logging file. Data shall be viewed using tabular or graphical reports
on the GUI terminal.
(iv) Security M anagement: OMC shall provide password and login
access to the system to prevent any unauthorized access to the
system.
(v) Fault M anagement: OMC shall provide capability to query and
change device states and provide control for system diagnostics. It
shall be possible to monitor different protocols in real-time.
(vi) Network statistics: OMC shall provide data related to channel
occupancy, rejected calls etc. with visual display of faulty elements
of the network.

6.19 GENERAL ENGINEERING AND M AINTENANCE REQUIREM ENTS

6.19.1 Equipment Practice

6.19.1.1 Dimensions, Weight & M ounting: The equipment shall each be of self
supported cabinet or rack type. Maximum height of rack shall be restricted
to 2100mm. To have greater flexibility for operations, front-only
serviceable racks are preferred. The outdoor RN equipment shall be self -
supported weather proof cabinet and capable of mounting on suitable
structure. Actual dimension and weight of each of the equipment shall be
indicated by the equipment supplier. Accessories for mounting equipment,
Antenna and feeder cable (if required) shall be specified & supplied along
with the equipment.

130
6.19.1.2 Power Supply: The power supply unit shall form an integral part of the
equipment and shall have protection against input over-voltage,
short circuit, input reverse polarity protection & shall have visual
indication for input under voltage.

6.19.1.3 General Equipment Practices:

(i) All cards of the same type and design shall be interchangeable without
necessitating special adjustments.
(ii) All metal parts of frames, supports, etc. shall be mechanically rugged
and constructed of corrosion resistant material or treated with anti-
corrosive finish. All equipment shall have a tropical finish.
(iii) Suitable test access points and displays shall be provided for
facilitating maintenance. Test access points shall preferably be located
on the front side of the bay. All visual display devices shall be located
in a position attracting immediate attention of the operating and
maintenance personnel. Suitable extension boards shall be provided
to facilitate access to components on a printed card.
(iv) The material used for all printed boards shall be expoxy or equivalent
(FR4). It shall not buckle due to a load of the assembled board or due
to temperature changes occurring under normal circuit operations.
(v) The supplier shall indicate whether printed board connectors are of
edge type or plug-and-socket type. They shall not be easily damaged
during replacements and removals. The contact particulars as well as
life test performance on contact resistance for each type of connector
shall be supplied.
(vi) All components and material used in the equipment shall be non
inflammable or in absence of it, self-extinguishable. They shall be fully
tropicalised.
(vii) The supplier shall indicate the various types of cables and wires used
in the system. Detailed particulars of any special wires and cables like
standardized coaxial, screened cable, etc. shall be furnished with their
actual usage in the system.
(viii) The buses, if any, shall be suitably protected against electrical and
magnetic interference from neighbouring systems (like
electromechanical systems, fluorescent tubes, motors, etc). The
supplier shall indicate the care taken in the design and location of the
bus system for such interference.
(ix) The points for connecting the power supplies to the different plug-in
cards shall be standardized and mechanically interchangeable.
Otherwise suitable mechanical safeguards shall be provided to prevent
damage due to accidental inter-change of cards.
(x) The supplier shall indicate the requirement at the external interface
against induced voltages and currents due to lightning, high power
system, etc.
(xi) The system shall provide for isolation and protection from accidental
high voltage power contact.

131
6.19.2 M arkings

(i) Equipment on the bay, whether of fixed or plug-in type, shall be

suitably marked. Identification of type of cards in its connector shall be
possible without necessitating its removal. Any plug-in component
shall be marked with sufficient information for its complete
identification.
(ii) The marking on the equipment and the cables shall be the same as
that used on the schematic drawings, cabling lines etc., in the
documentation supplied with the equipment.
(iii) All instructions, labels, or any other marking on the equipment shall be
perfectly legible and in the English language.
(iv) Colour code used for power feeding bus-bars/cables and earth shall be
identical for a given voltage throughout the equipment.
(v) Fuses shall have a suitable marking for the different ratings to enable
easy identification and replacement.
(vi) Marking shall ensure easy traceability.
(vii) The plug-in units whose removal or insertion (while the equipment is
in operation) might endanger the reliability or performance of the
equipment -shall have suitable protection and caution marking.
(viii) Each sub-assembly shall be clearly marked to show its functions and
circuit reference so that its complete description can be located in the
handbook.
(ix) The components shall be marked with their schematic references so
that they are identifiable from the component layout diagram in the
handbook.
(x) All controls, switches, indicators etc. shall be clearly marked to show
their circuit designations and functions.
(xi) Each terminal block and terminal shall be marked with an identifying
code.

6.19.3 Processors

(i) Adequate backup memory shall be provided. Direct memory access,

with suitable safeguards, is preferred for information flow between the
backup memories on the one and the main memories and the
input/output devices on the other.
(ii) Provision shall be made to prevent the loss/alteration of memory
contents due to power failures, improper operating procedures and the
procedures for restoring the system to its normal state, etc.
(iii) Dimensioning standards shall be evolved for the various types of
memories used. This shall also include standards for provisioning of
the required spare memory capacity.
(vi) The system shall support hard-disk (in duplicate) of suitable capacity,
to provide storage of charging information, detailed billing information,
traffic statistics, command log, system software, office data etc.

6.19.4 Software

6.19.4.1General

(i) The software shall be modular and structured.

132
 (ii) The design of the software shall be such that the system is easy to
handle both during installation and day-to-day operations as well as
during expansions.
(iii) The functional modularity of the software shall permit introduction of
changes wherever necessary with least impact on other modules.
(iv) The architecture of the software shall be open ended so that the
growth and addition of new features can be handled in practice without
any need of redesign of the software.
(v) Adequate flexibility shall be available to easily adopt changes in service
features and facilities and technological evolution in hardware.
(vi) The design shall be such that propagation of software faults is
contained.
(vii) The software shall provide sufficient checks to monitor the correct
functioning of the system.
(viii) Test programs shall include fault tracing for detection and localisation
of system faults.
(ix) The normal operation of the system should not be adversely affected
while undertaking :
(a) Extension to system (Hardware expansion)
(b) Enhancement of system facilities.
(c) Correction to programs or functional blocks.
(x) The software supporting documentation shall be in English. Any update
in the software at a later stage to overcome deficiencies of the system
due to bugs, compatibility etc., shall be provided free of cost by the
equipment supplier.
(xi) The equipment supplier shall undertake to supply on continuing basis
all software updates. These updates may include new features and
services and other maintenance updates. The software up-gradation
shall be possible with minimum interruption to the service.
(xii) The equipment supplier shall provide any software modification
necessary due to modification of software in the inter-working with
other network elements.

6.19.4.2 Diagnostic programs to localise hardware faults

(i) On a faulty condition, the software shall provide for isolating the faulty
sub-system and then automatically bring in the diagnostic programs for
diagnostic purposes.

(ii) It shall preferably be possible to diagnose to single PCB level in atleast

95% of the types of PCBs.

6.19.4.3 Software of charge records

(i) Arrangements shall exist for dumping the charging information to

non-volatile backup memories automatically at periodic intervals.

(ii) Facility shall be available for changing this interval by a Man-Machine

Command.

(iii) The charging information records shall be sufficiently protected

against modifications by man-Machine Commands.

133
6.19.4.4 Right to use: There shall be no imposition of any sort of precondition on
the ‘Right to Use’ of software.

6.19.5 M an-M achine Communication (MM C)

6.19.5.1 M an-M achine Language (M M L)

(i) Man-machine interface language shall be based on ITU-T

Recommendations Z 301 to Z 341.

(ii) The Man-Machine Language (MML) shall be in English. Commands

shall be English based and responses shall be in English.

(iii) The MML shall be easy to learn and to use, easy to input commands
and to interpret outputs.

(iv) The MML shall contain Man-Machine Commands (MMC), outputs,

control actions and procedures sufficient to ensure that all relevant
functions for the operation, maintenance, installation and testing of the
system can be performed.

(v) The MML shall have an open-ended structure such that any new
function or requirement added will have no influence on the existing
ones. The language structure shall be such that subsets can be
created.

(vi) The character set used in the MML shall be a sub-set of the ITU-T
alphabet No. 5 as recommended in ITU-T Z.314.

(vii) The command codes shall be function oriented. There shall be only
one command per function. The codes shall be mnemonic. All the
command codes in a particular application shall preferably consist of
the same number of characters.

(viii) The output in response to input commands shall have the same format
and use the same identifiers, codes, and labels, as the corresponding
input command.

(ix) The MML shall provide facilities for cancelling and aborting the
execution of commands.

(x) The MML shall provide facilities for inputting the parameters, for a
command, in any sequence and the optional parameters need to be
inputted only when they are required. Screen editing facilities for
modifying the commands and parameters shall be available.

6.19.5.2 Input/Output

(i) The input and output information shall be presented in a compact form.

(ii) The automatic output, not made in response to an input command

shall:
a) Include the time and date.

134
 b) Use standard telephone terminology. It is preferred if the
automatic output is differentiated by colour or special characters
from the output in response to an input command.

(iii) To facilitate filling and retrieval of recorded information in MML; the

information shall be recorded on forms or pages with an identification
header on top of each page with the date and time.

(iv) Special information shall be provided on priority printouts indicating

emergent situations.

6.19.5.3 M an-machine dialogue

(i) The MMC shall offer the facility for a conversational mode of operation.

(ii) The MMC shall have facility for restricting the use of certain commands
or procedures to certain staff/terminals.

(iii) W here several man-machine terminals are in use on a single system, a

mechanism shall be available to avoid clashes.

(iv) The execution of any command shall not result in malfunctioning and/or
over loading of the system. It shall also be ensured that the operator is
not locked out by the system.

(v) The MMC shall be implemented in such a way that errors in commands
or control actions shall not cause the system to stop or unduly alter the
system configuration.

(vi) Command errors detected by the system shall be indicated by the

output of error messages.

(vii) Possibility of priority messages to interrupt an input or output message

of lower priority is desirable.

6.19.5.4 Checks and safeguards :Sufficient checks and safeguards shall be

built into the implementation of the MMC so as to ensure reliable operation of
the system.

6.19.6 Diagnostics/Testing: The equipment shall support diagnostic capabilities

(which will run as background tasks) to verify the equipment’s proper
operation within the network. Built-in test capabilities shall be provided which
will run at specific events or on demand. Health monitoring signals shall be
continuously passed between the various modules to ensure the detection of
any failure in a module. Individual channel element functionality shall be also
be monitored to prevent call blocking due to a lack of channel element
resources.

6.19.7 The system hardware and software shall not pose any problem , due to
changes in date and time caused by events such as leap year etc., in the
normal functioning of the system.

6.19.8 M aintenance Aspects

135
 (i) Maintenance philosophy is to replace faulty units after quick analysis
of monitoring and alarm indications. Actual repair will be undertaken at
a repair centre. The supplier shall ensure the repair of faulty
equipment during and after warranty period.
(ii) It shall be possible to isolate Interface points for testing purposes.
(iii) The equipment shall have easy access for servicing and
maintenance.
(iv) All important switches/controls on front panel shall be provided with
suitable safeguards such as interlock system to avoid accidental
operation by the maintenance personnel.
(v) Procedure for repair of equipment giving full details of testing
instruments shall be provided by the equipment supplier. Test jigs,
fixtures required for maintenance/repair shall also be provided.
(vi) Extensive facilities for testing, supervision and monitoring functions
shall be provided for quick isolation and rectification of faults. These
functions shall be performed by OMC. Any additional instruments
required shall be provided by the equipment supplier with details.
(vii) The supplier shall provide information regarding the failure rate of the
PCBs and accordingly supply number of spare cards depending on the
size of the system, for a period of two years.
(viii) The maintenance spares supplied shall take into account the MTTR.
At least one spare PCB of each type shall be supplied.

6.19.9 Electromagnetic Compatibility (EM C)

The equipment shall conform to the EM C requirements as per the

following standards and limits indicated therein. A test certificate and
test report shall be furnished from test agency. The test agency for
EM I/EM C compliance shall be an accredited one and details of
accreditation shall be submitted.

a) Conducted and radiated emissions: - RNC, OMC & Indoor RN shall comply
with CISPR 22 {2003} “Limits and methods of measurement of
radio disturbance characteristics of Information Technology Equipment” as
per Class A. The outdoor RN shall comply as per Class B.
b) Electrostatic discharge:- To comply with IEC 61000-4-2 {2001 } “Testing
and measurement techniques of Electrostatic discharge immunity test”
under following test levels:
Contact discharge level 2 {+ 4 kV};
Air discharge level 3 {+ 8 kV};
c) Fast transients common mode (burst):- To comply with IEC 61000-4-4
{1995 with Amendment 1 (2000) and Amendment 2 (2001)} “Testing and
measurement techniques of electrical fast transients/burst immunity test”
under Level 2 {1kV for DC power lines; l kV for signal control lines};

d) Immunity: IEC 61000-4-3{2002} Radiated RF Electromagnetic Field

Immunity test under test level 2 (test field strength 3 v / m) for general
purpose in frequency range 80 MHz to 1000 MHz and under test level 3 (10
v/ m) for protection against digital radio telephones in frequency ranges 800
MHz to 960 MHz and 1.4 GHz to 2.0 GHz;
e) Surges line to earth coupling and line to line coupling :- To comply with IEC
61000-4-5 {2001} "Test & Measurement techniques for Surge immunity

136
 tests" under test levels of 0.5kV for line to line coupling and 1kV for line to
earth coupling;
f) Radio frequency common mode: To comply with IEC 61000-4-6 {2001}
"Immunity to conducted disturbances induced by radio frequency fields”
under the test level 2 {3 V r.m.s.}; clamp injection method for DC lines and
Signal Control lines.

6.19.10 Safety Requirements

a. The operating personnel shall be protected against shock hazards as
per IS 8473 (1993) – Guide on the effects of current passing through
the human body (equivalent to IEC publications 479-1 (1984).

b. The equipment shall conform to IS 13252 (1992) – Safety of

information technology equipment including electrical business
equipment (equivalent to IEC publication 95 (1986) and IEC 215 (1987)
Safety requirements of radio transmitting equipments (for Radio
equipments only)

The manufacturer/supplier shall submit a certificate in respect of compliance

to these requirements.

6.19.11 Lightning Protection: The equipment including Antenna & feeder,

shall have adequate protection against lightning & power surges. All
equipment shall have provision for grounding. For lightning protection of
Antenna the provision shall be there for direct ground.

6.20 Backbone Network

6.20.1 The BTSs shall be connected with their BSCs with state of art digital radio links.
6.20.2 The radio links shall work on 8/ 11/ 13 GHz frequency. The vendor shall quote radio
links in any of the above frequency bands depending on their engineering & design. The
capacity of the equipment shall be Nx2.048Mbps. N shall be determined by the vendor
based on the system design. In case, N>16, the STM -1 link would be preferred. The
design shall take rain attenuation into consideration for higher frequency bands. System
availability shall be 99.99%.

6.20.3 MTML presently has NEC Pasolink/Pasolink+ make MW equipment. The same is being
upgraded for EVDO Rev A expansion being done by M/s ZTE. Existing NEC make MW
equipment, as upgraded in EVDO expansion, should be suitably upgraded and integrated
with a new MW equip of capacity as envisaged in this tender to provide 2G & 3G
network seamlessly to the existing CDMA as well as new GSM network. The new MW
shall be dimensioned accordingly. The responsibility of interworking of new MW with
existing MW of lies with the successful bidder.
6.20.4 Alternatively, the successful bidder may replace the existing MW with new MW of higher
capacity which will include existing MW capacity. In this case, the migration of existing
MW capacity to the new MW will be the responsibility of the successful bidder.
6.20.5 The bidders also have the option to expand and upgrade the existing MW for providing
2G/3G services seamlessly to the existing as well as new capacity.
6.20.6 The successful bidder shall keep atleast 2 E1’s as spare in all the radio links for MTML
future capacity expansions.

137
 6.20.7 Detailed system performance calculations/ link calculations meeting relevant
ITU -T recommendations shall be provided by the vendor.
6.20.8 Equipment details such as transmitter and receiver characteristics, equipment
test points, order wire, supervisory system, antenna system etc. shall be provided
by the vendor.
6.20.9 The vendor shall provide in-built multiplex equipment to provide 2 Mbps PC M
interface as per ITU-T G703 at the input and output of the equipment. The 2
Mbps input/output ports shall be both 120 Ohm balanced.
6.20.10 The equipment shall be in 1+0 configuration for capacity up to 2x2 Mbps. Higher
capacity equipment shall be in 1+1 configuration.
6.20.11The equipment shall have the following features.

- Forward error correction (FEC)

- Local Maintenance Terminal (LMT) with window based software
application.
- Easy configuration for vertical/horizontal polarization.
- Software controlled variable transmit attenuator.
- Field tunable carrier frequencies
- Local, remote and input loop back test
- BER test through LMT.
- TX-RX separation as per ITU-R recommendations.
- Frequency selection through LMT.
- Transmit power control through LMT.

6.20.12 The overload point of the receiver and range of transmit power control shall
be indicated by the vendor.

6.20.13 The vendor shall submit detailed connectivity chart displaying the
capacity of various radio links (no. of 2.048 Mbps), frequency band width in
air etc.

6.20.14 A centralized Network Management System (NMS) shall be provided by the

vendor for centralized addition, deletion, modifications of any link in the
network, monitoring the health of all the links, Fault detection and attending
etc. The NMS so provided should manage the complete Microwave network,
including the existing ones.

6.21 INFRASTRUCTURE ITEM S

6.21.1 Towers

6.21.1.1 The vendor shall quote for towers/RTT/Mono pole for GSM and
Microwave Transmission Systems (MTS) required at BTS/MTS sites. The
vendor shall be responsible for the design of towers including foundation,
supply of materials, transportation, storage where necessary, construction
for foundation, erection of tower and installation of related facilities such as
Earthing and detailed design of the towers would be submitted by the
vendor. A certificate regarding the design of the tower meets the technical
requirements of the RFP from Govt body/certified agency is to be produced
by the vendor.

138
6.21.1.2 Heights & number of towers shall be decided by the supplier based of their
detailed survey & engineering. The towers shall be able to withstand the
loads imposed by the antennae. In the design of the tower antennae
required to be mounted in future shall also be taken into account. The wind
loading on structure and antenna shall be based on wind velocity of 250
kmph. The performance shall not degrade at this speed. The structure shall
survive at wind speeds of 320 kmph. Allowance shall be made for the
effective wind area of feeder runway, feeder, platforms guardrails, ladder
and ladder guard. Vendors shall get the towerdesign certified by authorized
agency/Govt. Body to meet the technical specifications of the RFP.

In the South area, restrictions for the tower height is specified by the
Airport authorities . W hile designing the tower heights, this is to be taken
into account

6.21.1.3 All steel work and fitting used in the assembly of the tower, except those
used in the concrete foundation, shall be galvanized by the hot dip process
after fabrication at factory. The thickness of galvanization shall be more
than 500 gms per sq. meter.

6.21.1.4 Nuts and head of bolts shall be of hexagonal type. Bolts and nuts shall be
hot dip galvanized. All bolts shall be fitted with spring washers or retaining
nuts. Spring washers or retaining nuts shall be galvanized by the hot dip
process.

6.21.1.5 Platforms covering sufficient area of the structure to provide safe working
conditions shall be provided at each antenna level including antennae to be
mounted in future. Platforms decking shall be made of expanded metal or
similar material, adequately supported on steel members of appropriate
size.

6.21.1.6 A feeder runway shall be provided on the tower. Each feeder runway shall
be located about the center of tower and extending vertically from ground
level to the top of the tower. Vendor shall provide a ladder type feeder
runway to support and protect the feeder cable between the vertical runway
and the station building. The installation of supporting gantry shall provide
satisfactory strength to resist against the mechanical stress. Adequate
protection shall be provided against falling objects.

6.21.1.7 Lightening protection and Earthing system is to be provided by the vendor.

The earthing strip should of GI and (not copper cable) of appropriate
dimension to avoid theft. If vendor feels that GI strip is not likely to provide
proper earthing, he should provide insulated copper strip, but not the cable.
The strips are to be welded at various locations on tower.

6.21.1.8 The tower shall be complete with antenna mounting steelwork to which the
BTS/MTS antenna may be rigidly attached by means of mounting hardware
supplied as part of antenna system.

6.21.1.9 Aircraft W arning Painting shall be provided for the self-supporting

towers.

139
6.21.1.10 Three coats of paint shall be applied as follows.

a) A primary coat of calcium plummet primer

b) An intermediate coat of high quality exterior under coat
c) A finishing coat of high quality exterior gloss finishing enamel

6.21.1.10 Aircraft Warning Lighting (Aviation Lamp)

i) The vendor shall provide Aircraft W arning Lighting for the towers.

ii) At the top of the structure, double lights shall be mounted 35 cm above
the top part of the structure but below the lightning arrestor.

iii) At the intermediate level, two lights shall be fitted so that the light is
visible from every angle of azimuth. The intermediate lights shall be fitted
at a height of approximately half that of structure.

iv) The lighting unit shall be of low power consumption type.

v) Supplier shall supply junction box to be located 2 meters above ground

level to control the complete warning lighting system.

vi) At the intermediate level, the lighting unit shall be installed in such a
position as to be readily accessible from a platform.

vii) Two independent lightning circuits shall be provided between the

junction box and the lights.

viii) The cable shall be installed within galvanized screwed conduit, which
shall be attached to tower.

ix) The lighting units shall be DC operated and have photo-sensor control to
switch it off during day time.

x) The DC power necessary for the lighting units shall be incorporated in

power system of BTSs.

6.21.2. Antenna

6.21.2.1 The vendor shall determine the type of antenna for getting
desired coverage and performance of the system. Fixtures for antenna
mounting at BTSs and RSs shall be included as part of antenna supply for
both BTSs as well as Microwave Transmission Systems. The proposed
antenna system shall withstand the adverse weather condition such as
heavy rain falls etc. Concepts of diversity receptions shall be implemented
for required reception of the radio signals.

6.21.2.2 The vendor shall indicate antenna configuration at Base Stations,

Subscriber Units and Microwave Transmission Systems. Microwave
antenna shall be with low beam-width & high front to back ratio so as not
to cause interference to other links (MTML or other operators).

140
6.21.2.3 Feeder: The vendor may decide type of feeder cable for getting desired
coverage and performance of the system. The vendor shall furnish detail
specifications (technical as well as mechanical) of the feeder cables.

6.21.3 Digital Distribution Frame (DDF)

DDF is required at BSC and all BTSs to allow flexibility of connection of 2

Mbps streams from exchange to BSC and BSC to BTSs. The vendor shall
supply DDFs with patching panels, jumpers and connectors. Connectors shall
120 Ohms balanced impedance and 75 Ohms unbalanced impedance at 2
Mbps level. At least 10% additional terminating capacity on the line side of
DDF should be provided for flexibility. Suitable length of HF screen cable
shall be supplied between DDF and transmission room.

6.21.4 D.C. Power Supply System

i. The vendor can expand the existing power system at all location or insatall
its own power systems. The vendor shall quote for upgradation or
complete power supply system for all the systems & sub systems e.g.
switches, BSS, Microwave transmission system etc. The Power Plant shall
be based on high frequency switched mode techniques i.e SMPS to be
used in auto float-cum-charge mode as a regulated power supply source.
The power supply system capacity shall be able to meet 2nd year end
power requirement. It shall be feasible to expand the system to meet
further future requirement. The MTBF of the system shall not be less than
100,000 hours. Based on this figure, the vendor shall stock necessary
spares during warranty & AMC periods. The equipment availability shall
exceed 99.99%

ii. The equipment shall operate at –48V DC with positive terminal earthed.
The voltage variation may range from –42V DC to –56V DC.

iii. The vendor shall state the power consumption of the equipment in all the
network nodes.

iv. The vendor shall provide –48V DC power supply equipment including float
rectifiers/ charger, batteries and accessories for all the sites. The Power
Plant shall consist of a Distribution/ Switching/ Control/ Monitoring/ Alarm
management based on menu driven micro processor controlled, rectifiers/
chargers in a rack and shall employ modular configuration for flexible
provision of DC power. There shall be suitable AC/ DC digital meters/
displays to read the voltage & currents of the system, any of the battery or
any of the float rectifier/ charger.

v. The float rectifiers/ chargers shall work in N+1 configuration and shall be
provided with over voltage, under voltage, short circuit and surge
protections.

vi. The float rectifiers/ chargers shall operate from single phase AC mains of
230V+/- 10%, 50 Hz+/- 2% and/or three phase AC mains supply of
400V+/-10%, 50Hz+/-2%.

141
 vii. The vendor shall provide any additional power equipment e.g, inverters,
DC/DC converters, required for any equipment operating on power supply
other than –48V DC.

6.21.5 Batteries

i. The vendor can expand existing batteries to the extent possible or may
install new batteries. The batteries shall be maintenance free/sealed MF
VRLA batteries with immobilised electrolyte and leak proof with cover seal.
The container shall be made of flame retardant PVC or equivalent. Battery
banks shall be provided in stackable modules. Stackable batteries shall
have air flow channels between cells for cooling. VRLA batteries shall be
manufactured in accordance with International Quality Standard ISO-9001-
2000 for which manufacturer shall be duly accredited. The steel racks,
containing batteries, shall be painted with acid-resistant paint.

ii. The cells of batteries shall not explode or burn when an electrostatic
discharge of 15 KVA is applied to any of its part exposed to contact.

iii. The Ampere-Hour (AH) capacity of the batteries shall be enough to

provide the following back up:

MSC/BSC sites : 6 Hours

BTS sites : 4/8 Hours. The outdoor cabinet will have inbuilt
battery capacity of 4 hours and the additional cabinet will provide 4
more hours and will be placed wherever asked for.

Failure of one or two cells shall not cause the failure of the battery and shall be able
to provide uninterrupted power supply.

iv. The capacity shall be decided by the vendor as per the power
consumption of the equipment at each node of the network. The capacity
of the each battery shall be calculated at 18 - 33 O C room temperature
variations. The vendor shall provide the discharge tables of battery at C/3,
C/4, C/5, C/6, C/8, C/10, C/20, C/72 & C/120 rate of discharge to enable
MTML staff to set the charge controller voltage low disconnect to ensure
that the batteries are not allowed to discharge beyond 80% of its rated
capacity.
v. Batteries used for Float applications are normally 24cell/48V batteries.
These batteries are formed by connecting 24 cells or cell modules each of
2V of the rated capacity, in series subject to compliance of the following
conditions.

1 The internationally adopted design practice shall be followed. The

partial plating of cell is not permitted. Paralleling of cells externally for
enhancement of capacity up to 1500AH is not permitted. For higher
capacity, the number of such paralleling shall be restricted to 4 only,
subject to the compliance of the following clauses and minimum
capacity of the basic cell is not less than 1000AH.

142
 2 Cell matching is essential for optimum life and performance of the
battery. For the purpose of cell matching, the following clauses shall be
met.

a) Voltage Matching:
i) Parallel Cell Matching: The difference between cell
voltages in the cell module string, with the highest &
lowest open circuit voltage shall be less than 0.02V.
Throughout the discharge, the difference between the
float voltages of cells having the lowest and the
highest float/charge voltage. In the cell module string
shall be less than 0.02V. The average float voltage of
each cell shall be within +/- 0.01V of the specified float
voltage during float/charge.
ii) Series Cell Matching: The difference between cell
voltages in a cell module & cell modules in the battery
string, with the highest & lowest open circuit voltage
shall be less than 0.1V. Throughout the discharge, the
difference between the float voltages of cells having
the lowest and the highest float voltage in the cell
module/battery string shall be less than 0.1V. The
average float voltage of each cell shall be within +/-
0.05V of the specified float voltage during float &
charge.

b) Capacity Matching:
i) Parallel Capacity Matching: The difference between the
highest and lowest cell capacities on a cell module string shall
not be more than 4% of their rated capacity.

ii) Series Capacity Matching: The difference between the

highest and lowest cell capacities in a cell module &
cell modules in a battery string shall not be more
than 5% of their rated capacity.

6.21. 6 Power Distribution Box

1. AC Power Distribution Box (ACDB) shall be supplied for distribution of AC

power to rectifying equipment.

2. DC Power Distribution Boxes (DCDB), ACDB and other facilities shall be

provided as per the requirements of each site.

3. ACDB and DCDB shall be of wall m ounted type.

4. Power Distribution Boxes (PDB) shall have appropriate ratings so as to meet

at least first two years requirements.

5. PDB shall be equipped with a main circuit breaker and branch circuit
breakers.

143
 6. Distribution Boxes shall be provided with digital displays for current & voltage
readings.

6.21.7 Diesel Generator (DG) set

1. The vendor shall quote for mobile DG sets (total 4) of appropriate capacity.

2. The diesel engine shall be of air-cooled type/ canopy type for installation in
outdoor conditions.

3. AC generator shall be provided with static type automatic voltage regulator

and shall be of the self-excited type. The generator shall be fully protected
against overload and short-circuit.

4. Automatic charging device for charging the starting batteries on float basis
shall be provided to maintain the batteries in fully-charged condition.

5. Lubricating oil reservoir for the engine shall be provided sufficiently to cater for
seven hundred (300) hour continuous operation without change of such oil.

6. Diesel Engine Generator set shall be provided together with following

accessories:
a) Starting battery
b) Fuel supply and lubricating system including Fuel Tank
c) Exhaust system
b) Dummy Load
e) Necessary Tools for maintenance

7. Fuel tank with sufficient capacity with direct reading fuel gauge, air vent facility
and fuel level switch for level alarm shall be supplied. Separate fuel tank as
indicated below shall be supplied.

Service Fuel tank: 8 hours continuous operation at full load

Reserve Fuel tank: 24 hours continuous operation at full load

8. Fuel motor pump shall be provided for automatic feeding of fuel from reserve
fuel tank to service fuel tank. Hand pump shall also be provided for use in the
case of failure of fuel motor pump. Reserve Fuel tank shall be installed on the
ground.

9. One set of maintenance tools shall be provided for each generator.

10. The capacity of the diesel engine generator set shall be determined based on
at least 1.5 times the ultimate station load (after 2 years) including Air
Conditioning equipment, equipment load, battery charging, lighting etc..
Altitude and climatic conditions may be kept in view while calculating
capacities of generator sets (de-rating factor). The generator shall be capable
of operating at 10% overload for one hour. Single phase and three phase DG
Sets depending on capacity & design of the vendor shall be supplied.

144
 11. The technical characteristics of diesel engine generator shall be as follows:

a) Speed : 1,500 rpm

b) Speed variation : 5% or less under full load

c) Nominal output voltage : 230 V, single-phase

400 V, three-phase
d) Nominal frequency : 50 Hz
e) Voltage fluctuation : +5% or less smooth variations from
no load to full load (except for any quick variation in load)
f) Voltage adjustability : more than +5% of nominal value (in case
of manual adjustment)

12. Diesel engine generator shall start automatically when reserve capacity of the
battery decreases to specified limit. W hen reserve capacity of battery
increases to specified upper limit or AC mains is restored the diesel engine
generator shall stop automatically. The start/stop control by means of manual
operation shall also be possible.

13. The control Cubicle shall be provided with voltmeter, ammeter, frequency and
run hour, alarm indications and terminal for alarm extension. The cubicle shall
have the following supervisory functions:

 Integrated failure signal

 Fuel level low signal
 Operation signal of diesel engine generator
 Time-up signal for change of lubricating oil.

14. Mechanical protection for the engine such as, low lubricating oil pressure,
high cylinder head temperature, low fuel level for fuel tank etc. and electrical
protection such as, overload, under voltage, overload on DG set etc shall be
provided.

6.21.11 Electrical system

1. An AC distribution system shall be provided to distribute the AC power to the

various electrical equipment such as, rectifier panel, air conditioning units etc.
and lighting sections. Standby power from the Diesel Generator Set is also
fed to this distribution system.

2. The AC Distribution Board (ACDB) shall be made of processed and powder

coated steel sheet. It shall consist of MCBs and terminals, the ratings of which
shall be calculated as per the actual load requirements.

3. A programmable logic controller (PLC) based Alarm Monitoring & Fault (AMF)
panel shall be provided. The functions of the panel shall be as follows:

(i) Automatic starting of diesel generator set in the event of AC

mains voltage falling below preset value.

145
 (ii) Automatic shutting down of the DG set when the AC mains
supply is restored, after a preset idle running period. The
stability of the AC mains supply shall be monitored for a preset
time period and then load shall be automatically transferred to
the AC mains.

(iii) Generation of an alarm in case the DG set fails to start in three

attempts.
(iv) Generation of low fuel alarm of the DG set.
4. The supply of AC from mains as well as from Diesel Generator set and fire
and intruder detection sensor shall be controlled by the PLC. The PLC shall
control the logic for mains failure for control of the diesel generator set and all
alarm generation.

5. Digital Ammeter and Voltmeter with selector switch shall be provided.

6. The following cables and wires shall be provided.

(i) Cable from mains supply to ACDB

(ii) Cable from DG set to ACDB

(iii) Control cable from DG set to AMF panel

(iii) Cable from ACDB to the rectifier unit

(v) Cable from ACDB board to the air conditioning units

(vi) Cable from ACDB board to the lighting section

(vii) Cable from ACDB board to power sockets

(viii) Control cable for smoke detector/ fire detector and intruder
alarm system

(ix) Cable for Earthing

(x) PVC channel/ Aluminum trunking for carrying cable

(xi) Cable glands and lugs as per cable

7. The following lighting items shall be provided.

(i) Lighting as per lux requirements of the shelter/ equipment

room

(ii) Emergency light with charging system

(iii) Aviation obstruction lamp alongwith twilight photoswitch

146
 (iv) External light using halogen lamps of adequate wattage with
standard accessories

8. Isolation transformer shall be provided between incoming AC supply and the

load for suppression of electrical transients.

9. Outdoor housing for electrical consumption meter made up of steel sheet with
proper installation accessories shall be provided.

10. A change over switch along with 8 way control switch and terminal box for
connecting mobile DG set shall be provided.

6.21.12 Earthing System & Lightening Protection.

Adequate Earthing system shall be provided at each site as per the

requirements of system operations. All equipments shall be connected to
the earthing system. Earth resistance shall be less than 1 ohm for
switching and transmission system. Suitable lightening protection shall be
provided at equipment side. All stations including shelter shall be provided
with lightening protection system.

6.22 TOOLS AND TESTERS

6.22.1 The vendors shall quote one set of essential tools and testers for day-to-day
operation of the system. A detailed list containing each item and quantity
which forms part of it, may be indicated along with the price of each individual
item.

6.22.2 The Purchaser reserves the right to procure either complete set of tools and
testers or any of the constituent items.

6.22.3 The vendors shall quote the following Measuring Instruments/Planning and
allied tools:

6.22.3.1 RF Planning tool (GSM /GPRS/UM TS/3G)

i. Planning tool for Coverage prediction, Frequency Planning and Performance

planning etc shall be supplied. The successful bidder shall supply the soft
copy of the latest digital maps of Mauritius used for coverage simulation,
prediction map with the BTS simulated for the cities, highways and rail routes
duly loaded on the planning tool. The digital maps supplied shall also be
compatible with the planning tools NetPlan/ASSET and there shall be no
restriction, whatsoever, in the use of these maps by the purchaser. The soft
copy of the Coverage prediction maps jointly agreed to by the successful
bidder and purchaser shall be available in the planning tool, a jointly signed
hard copy of which is to be made over to the purchaser as part of the planning
and engineering exercise. The server shall be supplied along with 21 inch
VDU/LCD display, AO plotter and A3-Colour Laser printer. The Installation and
commissioning of the planning tool in the desired configuration shall be done
by the successful bidder.

147
 ii. The software of Planning tool shall be licensed in the name “of
MTML(unlimited period). One copy of the Planning software with necessary
license and maps shall be supplied with suitable lap top computer with CD-
RW for easy backing up of data.

iii. The software of Planning tool shall be licensed in the name of MTML
(unlimited period) and should have the following General Features -

A) The RF Planning tool should be able to perform 2G/ 2.5G and 3G

Network Planning on the same platform simultaneously without having
to switch between different modes.
B) The RF Planning Tool should support Full 2G, 2.5G and 3G
integration including joint technology neighbour planning and joint
technology Monte Carlo simulations, providing planners with the ability
to accurately plan 2G, 2.5G and 3G handover scenarios.
C) The RF Planning Tool should be able to perform Automatic Cell
Planning and Network optimization.
D) The planning tool model should be able to get updated using the
data from the drive test tool.
E) RF planning tool should be capable of Network Performance
analysis and problem area identification
F) RF planning tool should be capable of Network Fine tuning and
validation with Data measurements
G) RF planning tool should be able to capture in optimization
mechanisms and real world design issues and constraints
H) RF planning tool should be capable of handling the
existing/implemented network plan and should be able to perform
analysis/expansion activity on the existing database.
I) RF planning tool should be able to automatically optimize the
physical network configuration to maximise capacity for the range of
services and traffic demands.
J) RF planning tool should be able to Automatically optimize design
parameters like antenna and power settings for multi-technology
networks
K) RF planning tool should be able to Utilize an extensive range of
survey measurement and network statistics data to tune the modelled
network and facilitate area performance optimisation
L) RF planning tool should be able to Automate and improve the
efficiency of the iterative process of ongoing planning and optimisation
M) RF planning tool should be able to Support 'real world' performance
targets and network configuration constraints
N) RF planning tool should provide a choice of various radio
propagation models.
O) RF planning tool should be seamlessly integrated to a single
relational database “Oracle”.
P) Accurately simulate current and future capacity scenarios using
static and dynamic simulators
Q) 3G data service QoS analysis
R) Automatic Frequency Planning and Code planning
S) Location Service Planning
T) Sophisticated statistics generation and reporting.
U) Advanced propagation model support including: Auto tuning of
models, and support for 3rd party models.

148
 V) The tool should have a powerful embedded GIS or should be
seamlessly integrated with 3 rd party GIS tools.
W) The tool should have powerful filtering capabilities based on object
attributes.
X) The tool should have the flexibility to store additional attributes per
object type (strings, pick lists, numbers, integers, Boolean etc.).
Y) The tool should support both OS & Oracle authentication, and
should have built in administration accounts.
Z) RF planning tool should have the capability to use propagation
models for both macro-cell as well as micro-cell.
AA) The tool should support static analysis for faster results.
BB) The RF Planning tool should have the ability to handle terminals
moving at different speeds.
CC) The RF Planning tool should have embedded latest deterministic
models to avoid tuning if required.
DD) The RF Planning tool should allow the user to create arrays that
combine coverage predictions and the effects uplink/downlink loads
have on them
EE) The tools should support integrated dual band planning.
FF) The RF Planning tool should have accurate modeling of RRM
algorithms and service characteristics to accurately predict QoS.

iv. Capabilities for Predictions and propagation

a. Should support fast predictions using different propagation models.

b. Should incorporate more than two diffraction models.
c. The user should be able to tune the propagation models and include
customized models.
d. Should have capability to define separate models for different cell
layers/cells.
e. Interactive azimuth reorientation for the map view should be available.
f. Should have option to display predictions on site basis, filtered sites or
map view.
g. Should have the facility for background prediction
h. Should support multiple CW data formats.

v. Capabilities for Interference and Automatic Frequency Planning

a. The handover hysterious margin and underlay/overlaid sub cells should

be considered in the calculation.
b. Should support base band and synthesizer frequency hopping, DTX
and group planning.
c. Should support MA List definition.
d. Should support HSN/MAIO/TSC planning.
e. BSIC planner should allow for exclusion of selected BCC’s and NCC’s
f. Should calculate C/I and C/A cell interference calculations and display
it on the map view.

vi. Capabilities for Traffic Planning

a. Allows the utilization of user defined traffic forecasts or live traffic

carried by network
b. Employs Erlang B or C model.

149
 c. Permits dynamic cell dimensioning according to traffic in
Underlay/overlay situations.

6.22.3.2 Drive Test Tool

i. The bidder shall provide Phone and Receiver based drive test tool capable of
testing GSM,GPRS & HSDPA/HSPA networks and realtime mapping of
multiple parameters with at least four phones and GPS receiver for achieving
optimisation of the Network and its expansions together with post processing
tools.

ii. It should be possible to upload the data captured by the drive test tool into the
Planning tool for fine tuning the propagation model for further planning as per
user requirement.

iii. General Features:

a. The C/I measurements on the BCH carrier should be done by the Digital
Receiver in very accurate form support the full dynamic range required for
GPRS and EDGE measurements. The Receiver should support both uplink
and downlink frequency bands
b. Digital Receiver for HSDPA/HSPA should be capable of performing
Scrambling Code Analysis, Primary Synch Search , and should be able to
provide for all significant pilots found measuremts like Ec, Ec/Io (both peak
and Aggregate), PSCH Ec/Io, SSCH Ec/Io, Delay Spread etc. The Digital
Receiver should have the capability to allow trade off between measurement
samples and sampling rate.
c. Ability to verify intersystem handovers and cell-reselection should be
available, along with a display of HSDPA/HSPA and GSM neighbours together
to check for Inter-RAT and compressed mode behavior.
d. A Protocol stack browser for viewing air-interface messages should be
available. Also facility to view data in Maps, Graphs and reports should be
provided.
e. Standard applications like HSDPA/HSPA Missing Neighbour, Pilot Pollution,
Soft Handover Analysis, Drop Call Analysis, Problem Summary Analysis,
Protocol Messages Failure Cause Analysis, Pilot Availabillity, Pilot Dominance
Interference Analysis, GSM-HSDPA/HSPA (Inter RAT) Handover Analysis,
GSM – HSDPA/HSPA combined drive analysis, GSM co-channel, adjacent
channel interference analysis should be provided. Analysis like Pilot Pollution,
Missing Neighbour, Handovers etc should be available on live basis and in
Tabular and Graphical form.
f. An automated radio network data collection, analysis, presentation and
reporting system should be supplied.
g. This system should have remote data collection probes which can be
installed in vehicles and are capable of remotely uploading collected log files
to a central server automatically using standard Radio Bearer. The probes
and calling patterns should be controllable from a central server.
h. Facility to view GSM/GPRS/W CDMA radio parameters and layer 3
messages should be available.
i. The system should provide speech quality testing using standard
algorithms.
j. The system should have the capability to generate customer views, flexible
Boolean logic based Alarms.

150
 k. System should be capable to export data into CSV, text and Mapinfo format.
l. Data Testing Suite should be provided for doing both End to End Data with
a Test Server and Applications Analysis

6.22.3.3 Post Processing Tool

(i) The Post Processing tool should be able to load and analyse data from 2G,
2.5G and 3G Networks & data measurements.
(ii) The Post Processing tool should support integrated 2G/3G Data Analysis.
(iii) The Post Processing tool should be able to merge different drive test data in
to single files for comprehensive analysis.
(iv) The PP tool should have Event Navigation functionality on a Time line , which
will display from Start to end of Drive all events like Call Start, Call End, Drop
Call, Blocl Call, Data Sessions etc along with colour coded carrier and
channel indications. W hen clicking on any event or near to event it should
update the map and charts and messages window immediately.
(v) The Post Processing tool should have a powerful and flexible graphing
system with replay functionality.
(vi) Any data can easily be displayed on the 2D View - indicate best server Ec,
Ec/Io, pilot polluted areas, throughputs, call drops, call failures etc.
(vii) The Post Processing tool should be able to perform Layer 3 decoding and
analysis with easy to use search and find capabilities.
(viii) The Post Processing tool should be able to perform Comparison and
synchronisation of digital receiver and UE (User Equipment) data.
(ix) The Post Processing tool in conjunction with drive test tools should have
Benchmarking capabilities - compare 4 or more networks.
(x) The Post Processing tool should be capable of Reporting via MS excel or
HTML or PDF or MS W ORD generated reports, shipped with a standard set of
reports (Ec, Ec_Io distribution, Bler distribution, neighbour analysis, drop
analysis etc).
(xi) The Post Processing tool shall provide graphical and tabular reports for
various features of GSM /UMTS related performance of the network. The list
of features supported may be indicated.
(xii) The system is to be supplied with Desk Top Computer configuration with four
perpetual licenses.
(xiii) It shall import and export data from/to drive test tools to be supplied by the
bidders and also from/to the existing drive test tools like Agilent E6474 A,
TEMS etc and also Planning Tools like NETPLAN, PLANET etc. without any
restrictions. The tool shall enable drive-test data files to be automatically
concatenated.

151
(xiv) The tool shall provide Protocol stack browser for viewing air-interface
messages.
(xv) The system should be supplied with features to display maps, Charts and
spreadsheets. It shall interface with Maplnfo to view the results on a map.

6.22.3.4 Protocol Analyser for Iub, Iur, Iu, Gn, Gi interfaces:

i. Protocol Analyser alongwith 8 Nos. of probes to monitor both the GSM

interface protocols including the proprietary ones, if any, used in the network
as well as for W CDMA interfaces will be provided.

ii. Protocol Analyser should have following features:-

a. The Protocol Analyser should provide fully automated online and offline
UMTS 3GPP Iu-b deciphering of control and user (speech, circuit, and
packet data) plane data. Support for single-session/multi-services, macro-
diversity (session control and user plane data sent across multiple Iub
links), cell-FACH/cell-DCH transitions scenarios
b. Support for multi port E1 links (single-port, IMA, and channelization
modes)
c. Protocol support for GSM/GPRS A and Abis interfaces including call
traces and tabular statistics profiles
d. Support for standard TRAU 16K decode
e. Support for H.324 (H.223/H.245 decode) PDU reassembly and
analysis on Iub interface
f. Support for real-time 3GPP R99/R4 Gb deciphering
g. Support for FP and RLC/MAC real time high speed downlink packet
access (HSDPA) analysis
h. AMR playback on Iu interface
i. Session buffer replay- the entire traffic buffer can be replayed for
correction to MAC logical channel settings. User can update the MAC
logical channel settings in configuration and these settings will be used for
decoding and reassembling the RLC/MAC PDUs during buffer replay
operation. Buffer replay is also for reassembling the following protocols’
data in offline mode: UMTS: RLC/MAC and H.223/H.245
j. Ability to listen to voice play out in the middle of call in both Iub and Iu
interface
k. Real-time capture and offline playback per IMSI/VPI/VCI
l. Gn/Gi correlation to other interfaces like Iub and Iu
m. SS7 subset
n. Support for up to 8 full duplex STM-1 interfaces for greater network
visibility.
o. Multi user server-client support.
p. Call manager.
q. Data mining support for long term data storage, reporting and analysis.
r. Monitor and troubleshoot interoperability of handsets with existing
networks with the power call trace features.
s. Handles inter system handover between GSM/EDGE and UMTS.
t. IP-based UMTS core network, e.g. Iu over IP, MAP over etc

152
 Call Trace Features

a. Macro-diversity call traces

b. 2G and 3G handover call trace (2 ways handover, 2G-3G and 3G-2G).
support both PS and CS calls
c. 3GPP Iub and Iub/Iu call traces to group in the soft handover legs for a
single session together. This also provides intuitive information on the
number of macro-diversity legs in each call
d. 3GPP Iub/Iu/Iur call traces to group in the soft handover legs that
extend to DRNC for a single session together
e. RP (TCP option) call trace that keeps track of TCP resends
f. RP tabular statistics to perform statistical analysis based on cell ID,
IMSI, NID, sector ID, serving PCF, SID and user name.
g. Iub/Iu/Gn call traces
h. 3GPP call traces to group the messages exchanged across the Iub, Iu
and Gn interfaces of UMTS networks. This also allows intuitive
grouping of Iub/Gn or Iu/Gn traffics.
i. Iub and Iub/Iu call traces- vendors variant call traces that also group in
the handover messages
j. Iub/Iu/Iur call traces- 3GPP call trace that also group in the FP frames.
k. Iub/Iu/Map call traces
l. Iub and Iur RLC stats
m. ISUP, BICC over IP call traces
n. Iu/GCP binary combined call trace
o. Iu/IuUP/H.245 combined call trace
p. Iu/H.245 combined call trace

i. Protocol support

a. GSM/GPRS A interface including call traces and tabular statistics

analysis
b. GSM/GPRS Abis interface including call traces and tabular statistics
analysis
c. 3GPP R4 June 2003 release
d. 3GPP R99 September 2002, R99 June 2003 and R99 December 2003
e. H.324M (H.223/H.245 decode)
f. 3GPP R5 release
g. 3GPPSABP and PCAP R5 Decode
h. Iu, Iub, Iur, NAS decodes and call traces
i. SIGTRAN (M3UA)

ii. Data mining software features

a. The tool shall provide detailed insight into RAN quality and
performance in a large area down to a per cell or user granularity
b. Iur analysis - where a subset of the KPI’s and analysis available on Iub
can be used to monitor and troubleshoot inter RNC handovers.
c. Video telephony analysis, handset analysis via IMEI, user centric
analysis around IMSI, voice channel analysis, network performance
and service performance.

153
 d. packet switched services such as MMS, FTP, email etc.
e. KPI and statistic report.

iii. Interface Requirement :

Following interfaces are required to be supplied to monitor Iub, Iur,Iu, Gn,Gi

on network proposed/supplied by the bidder. Ports are to be full duplex.

STM-1– 8 ports, Optical/ electrical

E1 – 8 ports
FE – 2 port, Optical

Handheld GPS Receiver with position accuracy of 20-25m - The GPS receiver
casing shall be waterproof. W hile the GPS Receiver shall operate with
rechargeable AA size batteries, the GPS receiver shall be supplied with
Cigarette Lighter Adapter, necessary cables and accessories to connect to the
12-Volt DC car power supply. Data transfer cable for facilitating data transfer
between GPS receivers and PC Kit interface cable for connection to the PC
through the USB port shall also be supplied. Any software for the PC required
to extract and import the data from GPS receiver shall also be supplied.

BTS Tester with GSM scanner, GSM transmitter measurement, Spectrum

Analyser, E1 testing, Digital VSW R Cum W aveguide fault detector meter with
distance to fault measurement facility, and GPS receiver. It should be a single
handheld compact unit working on battery and portable in nature. Power
measurement with +/-0.25dB total accuracy to be provided.

HSDPA/HSPA (UMTS) Transmitter Analyser to measure frequency, frequenc y

error, Code Domain Noise Floor, Carrier Feedthrough, Channel Power,
Average Power, Pilot Channel Power, Difference in amplitude between key
control channel.

HSDPA/HSPA (UMTS) Over the Air Analyser to measure frequency error,

scramble code, noise floor, Carrier feedthrough, pilot dominance, multipath
power, Utilisation (Peak and Average), Amplifier Capacity (Peak and Average),
code domain power measurement.

Interference Analysis should be possible with Spectogram display for viewing

intermittent or busted interfering signals. It should have built in signal
identification capability to identify possible interferer/ distinguish between
HSDPA/HSPA, CDMA, GSM transmitter.

6.22.3.5 Engineering Handsets- The model shall be the latest and the model
number of the handset shall be specified. The user manual of the engineering
features with complete explanation is also to be supplied.

6.22.3.6 All the accessories required for comprehensive use of the Measuring
Instruments/Planning and allied tools shall be included as part of this
package.

6.23 Layout of Equipment:

154
6.23.1 The supplier shall furnish the equipment layout for complete floor clearly
indicating equipment planned in Phase-I and Phase-II respectively.
6.23.2 Layout of all equipment shall be so planned that available space in the
equipment room/ pre fabricated shelters is optimally utilised.

6.24 PERIPHERALS:

In addition to system specific peripherals, the following shall be provided:

6.24.1. Testing equipment / PC Documentation pre-loaded on disk.

6.24.2 PCs with Laser printer shall be provided for MSC SERVER AND MEDIA
GATEWAY, BSC and other major network element sites.

6.24.3 PCs shall have following minimum configuration:

CPU: at least Pentium IV, RAM: 512 MB, HDD: 80 GB, LAN port

15 Inch Colour Monitor, 2 USB ports, latest anti virus software.

6.24.4. The system shall support Input/ Output terminal which can be
exclusively used to enter password controlled commands. It shall not be
possible to load any software form this terminal through floppy/CD drive etc.,
(which means floppy/CD drives are not to be provided with this PC)

6.24.5. It shall be possible to support file transfer on IP through designated PC.

6.24.6. In addition, one PC shall be provided to receive information over X.25 link for
billing /CDR/NMS data and to transfer this data to remote billing/CDR/NMS
systems over IP for all configurations.

6.25 Digital Distribution Frame (DDF):

6.25.1. DDF and associated items shall be supplied for the MSC SERVER
AND MEDIA GATEWAY, XCDR, BSC and BTSs. At least 10% additional
terminating capacity on the line side of DDF should be provided for MSC
SERVER AND MEDIA GATEW AY, XCDR and BSC, for flexibility. No
protection is envisaged for DDF.

6.25.2. The supplier shall provide all the cabling from the exchange side of the
DDF to the equipment room. The Jumpers required for extending 2 Mbps
PCM streams between line side and the exchange side shall also supplied by
the supplier. Minimum of 50 M of 16 pair HF screen cable per length (Run)
between DDF and transmission room shall be supplied.

6.25.3. For STM-1 interface, a minimum of 60-meter pre-connectorised optical

cable length with suitable connectors shall be provided.

155
6.25.4. These shall form part of the MSC SERVER AND MEDIA GATEWAY,
XCDR, BSC and BTS packages.

6.26 NSTALLATION MATERIALS , MAINTENANCE SPARES & CONSUMABLES:

6.26.1. All installation material and installations consumables shall be provided

to enable the proper installation of equipment supplied (like Runways & other
accessories for fixing runways & lugs, Media Cleaning Solution, Alcohol
Isopropyl, Soft Cotton, Soft Brushes, Solder W ire, Printer Papers, Adhesive
Tape, Mag Tapes 2400-P, optical disc drive, Floppy Diskettes 3.5 inch, Various
sizes of Fuses/ Connectors, Covers, Hand Gloves, MCBs, Fuses for batteries,
Spare Fuses for DC Distribution Cabinet, Spares for Control Panel of SMPS
Power Plant etc.,). Any other materials and consumables, which are
technology dependent and required for installation, but not quoted shall also
be supplied free of cost.

6.26.2. Item-wise details of installation materials required for installation has to

be furnished along-with its unit price and quoting of installation materials in
LOTS is not acceptable.

6.26.3. One set of complete maintenance spares & consumables is to be

provided to each site to cater to the needs for three years. Spare parts/Spare
Units for Hard disks, optical drives, PCs, Printers, CD-ROM & CD-ROM drive,
SMPS Modules etc. are to be provided.

6.26.4. Besides system specific spares, sufficient number of consumables like

Media Cleaning Solution, Alcohol Isopropyl, Soft Cotton, Soft Brushes, Solder
W ire, Printer Papers, Adhesive Tape, Mag Tapes 2400-P, optical disc drive,
Floppy Diskettes 3.5 inch, Various sizes of Fuses/ Connectors, Covers, Hand
Gloves, MCBs, Fuses for batteries, Spare Fuses for DC Distribution Cabinet,
Spares for Control Panel of SMPS Power Plant etc.,) are also to be supplied
to cater the need for three years for the maintenance of the equipment
supplied. Any other materials and consumables, which are technology
dependent and required for maintenance, but not quoted shall also be
supplied free of cost.

6.26.5. Complete details of each and every item of installation materials,

maintenance spares and maintenance consumables shall be provided.

6.26.6. PCB level break-up along with price of each module shall be furnished.

6.26.7. In the spare list, details of module(s) in which each spare PCB
proposed to be supplied is to be used shall also be given.

6.27 TOOLS AND TESTERS (FOR INSTALLATION):

6.27.1 One complete set of Tools, Testers, simulators instruments etc. is to be

supplied for each site needed for installation of various network elements of
the project.

6.27.2 Traffic Generator for generating 512 Simultaneous calls (256 originating and
256 terminating) on A-interface together with compatible PCs shall be made

156
 available by the supplier for carrying out the load test of the MSC SERVER
AND MEDIA GATEWAY.

6.27.3 The MSC SERVER AND MEDIA GATEW AY shall provide in-built tracer for
taking trace of CCS#7 (ISUP, MTP, SCCP, TCAP and CAP) and other protocol
signals on the specified time slot of specified PCM system. System not
supporting this facility shall provide separate tester free of cost.

6.27.4 TOOLS AND TESTERS (FOR MAINTENANCE):One complete set of Tools,

Testers, simulators, instruments etc. for maintenance is to be provided for
MSC SERVER AND MEDIA GATEWAY.

6.28 Billing & Customer Care Centre

6.28.1 The existing B&CCS of 110K capacity (of CDMA) installed should be expanded to
210K for serving both existing CDMA & Proposed GSM subscribers or replaced with
new B&CCS of 210K capacity including the existing capacity. The offered B&CCS
solution should be expandable to 310K with additional hardware & software for
phase II expansion.

6.28.2 Billing & Custom er Care System (B&CCS) provided m ust conform to the standards.

6.28.3 Billing and custom er care system shall be an integrated custom er care, billing &
accounting platform and shall support billing for wide range of GSM/CDMA services,
viz. Tele-services, Bearer services, Supplem entary services, GPRS, WAP, MMS,
UMS, SMS, PTT, Cell broadcast, International Roam ing and content based services.
.

6.28.4 OTA applications, Location based and IN services etc.- B&CCS shall take care
of activation, suspension, deactivation & change in the subscribed services. The
service creation/m odification request shall be dealt by the custom er adm inistration
m odule and forwarded via Service Provisioning m odule to the various databases in
the network. Service requests shall be processed in real tim e and non -real tim e. 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
custom ers over the Internet and various bill event notifications through SMS
autom atically.

6.28.5 B&CCS shall support the following m ajor functions:

a. Collection, Checking, filtering and validation of Call Detail Records from Mobile
Switching Centres (MSC), MGW , SMSC, SGSN, GGSN, MMSC, Application
Server of Location based services, GMLC, W AP server, OTA server, CBC, PTT
and all other network elem ents as applicable.
b. Distribution of Call Detail Records to various applications.
c. Rating & billing of voice & data calls of post-paid custom ers.
d. Rating of Prepaid calls for interconnect settlem ent and reconciliation.
e. Rating & billing of SMS, MMS, GPRS, Content & Data etc. in respect of post-
paid custom ers.
f. Rating & Billing of Roam ing calls for international roam ing CDRs for ou r
outroam ers and transferring Inroam er CDRs, alongwith roam ing revenu e
settlem ent am ong operators
g. Providing tim ely inform ation/data for effective and efficient custom er service.

157
 h. Tim ely and accurately invoicing of Call Details.
i. Providing various discounting schem es to the subscribers.
j. Providing m ultiple Billing Cycles (license service area) of sam e or different billing
period.
k. Support of differential tariffs.
l. Support of cross-product discounting.
m. Support of charging for various types of existing and new services.
n. Provisioning of services, for both pre-paid and post-paid billing.
o. Custom ers care for service requests and bill inquiry.
p. Provisioning of autom atic suspension, disconnection and reconnection of service
based upon outstanding paym ent.
q. CDRs processing in real tim e and/or batch m ode
r. Interconnect Rating, Billing & Accounting, Reconciliation, settlem ent of paym ent
and report generation.
s. Revenue sharing, Content Settlem ent and Reconciliation with Content Providers
& Aggregators.
t. Invoice calculation, form atting, dispatch and on-dem and billing.
u. Number (MSISDN) inventory, IMSI, SIM (ICCID) m anagem ent and Voucher
Managem ent System.
v. Accounting of paym ents & receivables.
w. Standard and ad-hoc reporting and Churn analysis.
x. Roam ing support and billing in Transfer Accounts Procedures (TAP3) form at or
latest as defined by BARG/ TADIG of GSM Association.
y. Flexible and customizable bill presentm ent.
z. Order m anagem ent
aa. Trouble Ticket Managem ent.
bb. Paym ent acceptance through cash, draft, cheque, credit card, debit card, bank,
ATM, EFT, and from other billing system s
cc. Bill presentation
dd. The system should send the bills autom atically through em ail to the subscribers
having em ail id in addtion to generating the print file.
ee. SMS notification should be send to all the subscribers autom atically for bill
am out & due date of paym ent.

6.28.6 B&CCS shall support the provisioning, rating, billing and accounting for the following
services:

i. Tele-services, Supplem entary Services and Bearer Services of GSM

ii. General Packet Radio Services
iii. W ireless Application Protocol Services
iv. Universal Mobile Telecomm unication System and 3G Services
v. Content Charging for subscriber and revenue sharing for content provider
vi. Data Services
vii. Messaging Services such as SMS, MMS, UMS etc.
viii. Location Based Services such as Fleet Managem ent, Navigational,
Inform ational, Entertainm ent, Advertisem ent etc.
ix. Push To Talk over Cellular
x. Cell Broadcast Services
xi. Over The Air Services such as content down load using SIM browser

6.28.7 Billing system shall offer flexible and efficient rating engine for pre-paid and post-paid
usage. It shall perform the following processes:

i. Real tim e 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 tim e and batch invoice calculation

158
 iv. Post-paid threshold and pre-paid billing
v. W holesale and third-party billing
vi. System s adm inistration processes (including m ulti-level password
m anagem ent
vii. Authentication, Authorisation and Accounting capabilities for pre-paid
subscriber.
viii. Quick Custom er Registration W izard, in addition to the norm al registration
interface.

6.28.8 The system should have the capability to calculate franchise’s comm ission and
generate the invoice. Commission calculation should be flexible enough to define
various schem es

6.28.9 The Mediation System Platform shall be able to collect usage events from different
network elem ents of GSM, CDMA, PSTN network for Voice, SMSCB, MMS, internet,
data from MSC, W AP, SGSN, GGSN, Location based services application server,
SMSC, MMSC, GMLC, UMTS and 3GPP on the sam e Platform .

6.28.10 The system m ust have a rules based logic configuration for m apping MTML’s
business processes.

6.28.11 The system should have Autom atic Service Provisioning m odule, Credit
Control Module (including auto-m essaging thru SMS, warning m essages), Paym ent
accounting m odule, Accounting report m odule etc.

6.28.12 SMS CDRs should be polled from SMSC so as to m ake SMS charging based
on the destination content

6.28.13 The latest TAP-3 should be available. Migration to any future version should
be possible.

6.28.14 All CSR counters should have the facility of online paym ent collection

6.28.15 Audio visual alarm indicating the failure of CDRs polling from any of the
MSC’s should be generated by the system

6.28.16 The network elem ents generated CDRs in ASCII/ASN.1 form at shall be
transferred to B&CCS over FTP/TCP-IP or FTAM/X.25 interface

6.28.17 The system shall have exhaustive built in statistical and reporting capabilities
with option for on-screen viewing, printing and shall have relevant software for
generation of custom reports by the users. It shall have a friendly GUI so that adhoc
reports and MIS graphics can be generated easily. It shall be possible to generate
various adm inistrative reports, Rule set reports, collection and transm ission reports,
verification & processing reports, Record processing accounting rep ort (to provid e
details of m ediation m odules) etc. apart from system log on errors, comm ands &
events. Apart from the above auditing reports, it shall be possible to define
inform ation to be collected that is as per the user requirem ent (tailor-m ade reports).
Reports should be custom ized as per the MTML requirem ents.

6.28.18 The system shall be based on Relational Database Managem ent system

6.28.19 Billing system shall be custom ized as per MTML requirem ents / MTML
business process. For this purpose, the bidder or his collaborator / MoU partner
should have software developm ent in Mauritius System shall be customized as per
the MTML requirem ents (including reports) captured in the “Statem ent of W ork
(SoW )” m utually agreed by MTML and the successful bidder.

159
6.28.20 The Network Managem ent System is aim ed at providing a set of robust
applications and functionality for m anaging the servers, SAN, router elem ents of the
wide area network and the infrastructure required to connect MSCs as well as to
support Custom er Term inals. It shall have provision for following functions:

a. Security Managem ent

b. Fault Managem ent
c. Traffic Managem ent
d. Perform ance Managem ent
e. Configuration Managem ent
f. Rem ote m anagem ent and display export of CSR term inals from a single
console

6.28.21 Enterprise grade anti-virus system shall be provided. Anti-virus client software
shall run on all windows based m achines. It shall allow autom atic antivirus patch
downloads.
6.28.22 B&CCS shall interface for CDR data collection as well as service provisioning
and seam lessly integrate with the existing network elem ents in the MTML GSM
network
6.28.23 In case the bidder opts to replace the existing billing system , it will be
com pletely successful bidder’s responsibility to -

(a) m igrate the com plete 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 comm ercial use.

(b) seam lessly integrate with all the existing network elem ents for service
provisioning and data collection -

- Huawei MSC
- Huawei IN
- Huawei SMSC
- VMS
- PDSN/ AAA
- Cellebrum ;’s CRBT
- any other network elem ent generating billable events
- Content based third party applications

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

6.28.24 The bidder shall provide a roadm ap for future releases of the proposed system .

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

6.28.26 The bidder shall provide a project plan for the im plem entation of the MTML project
and state the assum ptions 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 im plem entation.

6.28.27 The bidder shall im part training to personnels of MTML in all aspects of
B&CCS installation, operation and m aintenance.

6.29 B&CCS System requirem ents

160
6.29.1 General System

a. The system shall conform to open system standards and support

distributed processing
b. The system shall be open multi services system.

c. The system shall operate in three (3) environments, namely Production,

Test and Train. And it shall be possible to transfer production
environment data to Test/Train environment.

d. The system shall be a client/server architecture based in minimum of 3

tier structure.

e. The system must be capable of processing unit transaction (e.g. add,

update, delete etc.) for users of the system shall be less than 6 (six)
seconds.

f. The proposed B&CCS shall be based on Relational Database

Management System (RDBMS) of latest version. The system shall
support open standard to function with any standard RDBMS.

g. On delivery of the system, the vendor shall modify/customize the offered

system locally as per the requirements. Such possibility shall also be
open to the user whenever the situation arises.

h. The offered system shall be modular and object oriented in design with
flexibility to add, remove and update modules to a specific configuration.

i. Basically, the Mauritius currency shall be used in the system. However,

the system shall support use of other currencies.

j. The B&CCS system shall support all types of switches and services
available in the switches. The vendor shall provide the types of Mobile
switches supported by the offered B&CCS system.

k. The proposed B&CCS system shall have Master and Standby (1+1)
server configuration.

l. The system shall have provision to online transfer of data from Master to
Standby server all the time.

m. The system shall support multiple connections, disconnection &

reconnection of customers within a day immediately and/or as
scheduled.

n. The system shall support connection with network printers to print the bill
and locally connected dot matrix printers to print receipt/invoice.

o. Remote bill printing and receipt/invoice printing shall be possible in the

offered system

p. System support & spares of the printer shall be available in the African
region.

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

r. In case of detection of missing or erroneous data related to customers or

connections, the system shall have provision to exclude such data from
the current processing and to include them by correcting only after
successful completion of the whole process.

6.29.2 System Capacity (Customers)

i. The proposed system shall be capable to store and process all the
information required to administer customer information, CDR
collection, rating of call data, bill production, collection of dues and
other payments, manage customer’s ledger and fraud.
ii. The proposed B&CCS system shall be capable to handle at least
210,000 normal subscribers (310,000 in phase II) including at least
10% of Hot Rated subscribers to run the system smoothly without
exertion of the disk space and connection of at least 30 terminals.
iii. 50 (Fifty) Client terminals based on PC with 15” LCD monitor will have
to be provided by the vendor.
iv. The system shall have capability to provide hot rating and software
enabled connection and disconnection of customers for all type of
switches.
v. Centralized customer ledger keeping with provision for several levels of
branch activities of collection, maintaining and controlling customer
accounts. The central ledger shall be reflected with the changes in real
time but updates and reconciliation shall be made at the end of the
day.
vi. Fully integrated customer ledger and cash collection system such that
the customers can pay their bills at any collection centers, banks
and/or through different types of cards and debit account systems.
vii. The system shall handle all types of services available in the proposed
switch.
viii. The system shall support new services that may be incorporated in the
switch within the project period.

6.29.3 Call Detail records

i. The offered system shall be able to handle the call data volume
considering a minimum of 100 CDRs/UDRs per subscriber per day.
ii. The offered system shall be capable for on-line CDR collection from all
types of switch.

6.29.4 Bill Production

The proposed bill system shall be able to produce at least 50,000

invoices/day and bill production shall be possible to run without affecting cash
collection and normal customer care service operation
6.29.5 Online data storage

The system shall keep online CDR data and bill images for at least six
months. Bill amounts and collection data shall be available online until the

162
 account is audited. Minimum audit period shall be considered as 18 months.
All other data including customer details, suspended data, bad debts,
deposits, connection, and customer history shall be available till it is required.
6.29.6 Hardware/OS

i. The system shall have hardware and OS to support the B&CCS

application software to handle the customer base and user terminals
ii. The system shall have adequate hardware and software interfaces for
online CDR collection from the switch simultaneously.
iii. The system shall be offered with adequate Hardware and software
including tools and utilities to operate and monitor the system effectively.

6.29.7 Connections

a. The system shall be a centralized system with direct and remote terminals
access from all customer care, billing and accounting centers, collection
counters and switches.
b. Generally provisioning/Deprovisioning of services in the switch shall be
done through the near by terminals. However it shall be possible to handle
those tasks from other terminals also with privileged users only.
c. The system shall provision for connections of more than one user from
one/multiple terminals at the same time.
d. The system shall have provision of interfaces to connect to B&CCS
system and its database from third party software’s.

6.29.8 Tools

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

’98/2000/XP.
b. The system shall be equipped with hardware interfaces and software tools
to establish connections with the switches and perform rating, billing and
accounting functions.
c. The system shall provide with software tools for system, network and
database administration of the proposed system.
d. Software development tools required for system customization and
development of additional sub modules, screens, reports shall be
provided.
e. The system shall have software tools to manage administrative and billing
data of different types of services and facility available in the switches.
f. Following tools shall be provided
i) Report generation and designing tools
ii) Report layouts configuration tools
iii) Ad-hoc reporting
iv) Dynamic Querying facilities
v) Online and offline backup/Restore management tool

6.29.9 User Interface

a. The system shall support Graphical user interface (GUI).

b. The software design shall be such that it is user friendly and allows for
quick menu/screens access and data entry.
c. The following guide lines shall be incorporated in design of user interfaces
i) Error message , guide message, system message

163
 ii) Field description
iii) Value list of acceptable values for a particular filed
iv) Pull down lists with selection capabilities
v) Uniformity and similarity in colors and sizes, buttons, layouts of
information through screens and menus
vi) Online help provisioning
vii) Easy maintenance of messages, text, values etc. without modifying
program.

6.29.10 Security

a. The system shall be secured with different levels of user and job access
b. The system shall provide extensive securities features at many levels for
all modules. Such security’s shall be provisioned through a) OS level b)
Database level c) Application level
c. All types and levels of securities provisioned in the system shall be user
configurable through user interfaces as and when required.
d. Jobs shall be grouped by the level of security required.
e. The system shall have provision that Application users shall not be able
to login through database. S/He shall be restricted to application only.
f. It shall be possible to classify the users into twenty five (25) different
categories with different access rights to the system. At least fifteen (15)
users of each category shall be able to access the system
simultaneously.
g. An individual user shall be restricted to access only those applications
relevant to his/her job function.
h. User shall be grouped by their functions e.g. operator, supervisors,
developers, privileged users, manager, administrator etc.)
i. Users shall be restricted to install and modify the subscribers’ services to
their locations only. However privileged user shall install and modify the
subscribers’ services of all locations.
j. Some operations and queries shall be performed by privileged groups of
users only.
k. The system shall support grace logins, concurrent logins, timed logins
and logouts on idle conditions.
l. The vendor shall also provide details of access level security that shall
be made available in the system.
m. System checks and user input checks shall be performed to verify
information consistency throughout the system.
n. Log history of activities of all users shall be recorded.
o. Some users shall be restricted to his location only.

6.29.11 Backup/Restore

i. The system shall have backup facilities at every check point of processing.
Such backup shall be conducted Automatic without degrading
performance of ongoing process.
ii. System shall have provision for recovery from backup in order to continue
processing from the checkpoint onwards.
iii. The system shall have efficient and reliable backup and recovery on
regular basis.
iv. The system shall also have external devices for backup and it shall have
provision to make backup in internal devices as well as external devices.

164
 v. The system shall have at least three methods of external back-up devices
to keep the back-up, one of which shall be as of switch back up media so
that in case of failure of EDI connection between switch and billing system,
CDR files can be loaded in to the billing system.
vi. The system shall provide backup management utilities for the proper
management of backup and recovery.

6.29.12 Flexible system

a. The proposed system shall be accurate, user friendly and flexible

b. It shall enable user to modify as per requirements
c. The system shall provide interfaces for inserting sub modules in the
system and provision for addition of modules by the user.
d. The system shall have provision for addition and changes of reports,
screens, and queries.

6.29.13 Scaleable

a. The system shall be scaleable in terms of performance and functionality.

b. Most batch applications performing volume processing shall run on the
servers making use of SMP servers.
c. Many online and batch processes shall run concurrently making use of
multi processing environment.
d. Running of batch processes and online processes simultaneously shall not
degrade the performance of the system.

6.29.14 Fault Tolerance

a. In case of failure, system shall restart incomplete processes from the last
check point.
b. Each update process or any other process affecting changes in data shall
be committed to the database only after successful completion of the
whole process.
c. The vendor is also required to provide other features available in the
proposed B&CCS to achieve maximum flexibility, scalability and fault
tolerance in the system, if available.

6.29.15 History Keeping

a. The system shall have provision to keep history of all changes to systems,
tariff and user operations.
b. The system shall keep history of all the data entered, modified and stored
in the database.

6.29.16 Control

i. The system shall have a control mechanism to co ordinate and control all
types of online, batch or parallel process, transactions executed in the
system in order to provide timely and accurate information required from
the system.
ii. The system shall run efficiently and accurately with the minimum manual
checks.

165
 iii. The system shall have control facilities to allow partial or full access to
B&CCS database by an individual user and a group of users.

6.30 Hardware

The vendor is required to quote the hardware as per the Schedule of

Requirement and the quantity given below. Any additional equipment required
to meet the requirement specified in the RFP specification shall be included in
the offer. The vendor shall provide additional hardware free of cost to meet
performance of the system as per MTML’s requirement in this RFP.

6.30.1 RISC server with Storage System

The RISC server shall be in 2 (two) units configure as 1+1 high availability
active and standby configuration

6.30.2 RISC processors

The offered server shall be equipped with 4 (four) or more SMP RISC
processors in each server. The offered server shall have the capacity to
accommodate at least additional two or four more SMP RISC processors in
each server

6.30.3 M ain M emory

The offered server shall be equipped with minimum 4 (four) GB of RAM in

each server

The offered server shall be able to increase the memory capacity to 64 GB

RAM by adding memory modules.

The internal data bus of the offered server shall be at least 64 bit

6.30.4 Storage Capacity

The offered server shall have sufficient storage capacity to process 200,000
normal and 10% hot rated customers. The vendor shall provide the detail of
space calculation base on average 100 CDRs/ UDRs per customer per day.

The offered server shall have enough space for creating three environment of
B&CCS i.e. Production, Test and Training.

6.30.5 Other Accessories

Two Consoles(X Terminals) should be supplied for operation of the

servers.

The offered server shall be equipped with DVD Drive

The offered server shall be equipped with Ethernet Network Interface card
with RJ45 port

166
 The offered Network Interface card shall be capable to work in 100baseT and
10 base T Ethernet Network with strapping or software setting in the card.

The system shall be equipped with at least one serial port.

The offered server shall have SCSI-2 port to connect external devices like
optical drive, DLT drive autoloader etc.

The vendor shall supply all necessary connectors and cables to connect
offered peripherals.

The vendor shall supply necessary equipments (Router, Hub, Media

converter, Switch, Cable etc) required for LAN and W AN network connectivity
of all locations.

The server shall be supplied with 15” color display, whose resolution shall be
minimum of 1280*1024.

The monitor shall be multi-sync monitor, in which the standard 15 pin VGA
interface cable shall be installed

The server shall be equipped with VGA interface card

The offered server shall have port to connect UPS monitoring port of UPS for
automatic power supply fail support.

The mediation device required for service provisioning and CDR collection for
switch shall be connected with 1+1 active standby configuration.

The vendor shall supply full set of Operation and Installation manuals.

6.30.6 Backup device

The vendor shall supply 2 (two) units of 5.2 GB optical rewritable 5.25” drive,
cables, connectors, software necessary for full function of drive.

The vendor shall supply 2 (two) units of 100/200 GB DLT drive Autoloader,
cables , connectors, software necessary for full function of drive .

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

6.30.7 Spare parts

i. 4 set of Memory Modules of capacity as used in the server.
ii. 4 units of spare hard disks
iii. 5 units of network interface cards
iv. One hundred (100) units of optical rewritable disk for offered disk drive
v. One hundred (100) units of DLT Tape cartridge for offered DLT drive
Autoloader
vi. 2 units of power supply system
vii. 100 (eighty) units of cartridge for dot matrix
viii. Twelve(12) units of toner for Laser printers

167
6.30.8 Operating system on Server
i. The offered system shall have UNIX operating system. Sufficient
licences should be provided.
ii. The offered system shall support Symmetrical Multiprocessors on the
RISC servers.
iii. The offered system shall work on client/server architecture
iv. The offered operating system shall have utility for online backup and
recovery of files.
v. The vendor shall specify and include the necessary software tools to
establish link from client’s terminal to the server in the offer. IBM
compatible PC terminals shall be used for client terminals.
vi. The offered operating system shall work on TCP/IP protocol
vii. The vendor shall specify and provide necessary software with manuals
to operate and manage whole networks.
viii. The vendor shall plan IP address for sub networks under private IP
address range
ix. The vendor shall specify and supply all necessary drivers to fully operate
all the accessories offered under this RFP
x. The proposed OS shall support facilities for virus detection and removal
6.30.9 ORACLE RDBM S
1 . The offered RDBMS shall be ORACLE RDBMS and it shall be fully
compliant with offered operating system
2 . The offered RDBMS shall support Symmetrical Multiprocessors on the
RISC servers
3 . The offered RDBMS shall support client/server architecture including
following functions:
i) Remote database query
ii) Remote database update
4 . The offered RDBMS shall be supplied with Multiple server user licenses
for Twenty (20) terminals. The vendor shall quote unit price of the user
license.
5 . The offered RDBMS software shall capable to run multiple database in
one server at least for Production, Test and Train purpose
6 . The vendor shall quote additional memory, hard disks and other items if
required to fulfill the function of above database
7 . The offered RDBMS shall have tools to trace for problem diagnostic
8 . The offered RDBMS shall have commit and rollback for a unit of work
9 . The offered RDBMS shall have two Network committing
10 The offered RDBMS shall have replication feature to replicate to other
databases. The replication feature shall include selective tables
replication and complete database replication
11 The offered RDBMS shall have Multithreading within single task
12 The offered RDBMS shall be capable of load balancing across CPU for
executing threads
13 The offered Memory in each unit of the RISC servers shall be enough for
connecting total number of users license specified in the requirement. If
the specified amount of RAM is not sufficient then additional RAM shall be
provided by the vendor free of cost to MTML.
14 License shall be issued directly by the manufacturer of the RDBMS
software.
15 The vendor shall install and operate the system in redundant mode. That
means if one server fails, then next server shall be ready to start without
any interruption in system

168
 16 The vendor shall supply necessary tools to install offered two (2) sets of
RDBMS in two different locations.
17 The proposed RDBMS shall include Diagnostic and Tuning Packs for
database tuning, diagnostics and monitoring for enhancement of
performance.
18 The proposed RDBMS shall be provided with necessary Partition Option.
19 The vendor shall provide Report Generation and Designing Tolls.
20 The vendor shall provide FULL SET OF oracle MANUALS.

6.30.10 Printer

(A) Laser Printer

i. The vendor shall provide two (2) units of Network printers for
printing customer bill printing.
ii. The printers shall be of laser type.
iii. The system shall have provision to print the bills simultaneously
in both the printers.
iv. The offered printer shall also meet following features:
 Printing speed of at least 100 pages per minute
 Cut sheets up to 5000 sheets input
 Up to 5000 sheets output
 Paper sizes A4/A3/letter
 Universal duplex printing
 OPC drum 1000000 pages per drum
 parallel and 10/100 base T Ethernet interface
 Remote printing features
 One units of installed toner for each printer
 Power and printer cables and necessary accessories
 Operation and maintenance manuals
 Auto stapling feature (Optional)

(B) Dot M atrix Printer

The vendor shall provide thirty (30) units of 9 pin dot matrix printers
with continuous paper.

6.30.11 Installation and commissioning of B&CCS system

The vendor shall provide the procedure to test separate modules and the
complete system including billing system’s application software, all the
functional features and inter connectivity of the system with the switch.

The detailed test procedures for acceptance test and final acceptance test
shall be carried out in the presence of authorized representatives of the
vendor.

The vendor shall quote for the services required for installation and
commissioning of the system,

The vendor shall provide necessary tools , equipments etc and any additional
cost, if any, shall be borne by the vendor

169
 Complete network diagram representing the configuration for the offered
billing system including integration to the switch shall be provided by the
vendor. All equipment (hardware/software) to operate such a system and
network shall be included in the offer.

6.30.12 Source Code

Source code for the core module of the application software is not required.
However, source code covering following modules shall be provided so that
MTML can add, modify and generate queries, screens, and reports and insert
new sub modules as and when required.
 Database structure including structure of all data items
 Entry Screens
 Reports
 Queries
 Insertion of additional sub modules

6.30.13 Documents

The application software user screens and documentation shall be in English

language. Two soft copies of documents shall be provided. One set of hard
copy documentation shall be provided, if available.

On delivery of the system, following documents shall be provided:

i. CDR Formats, naming conventions for transferred files from MSC
ii. Data flow diagrams, ER Diagram
iii. Recovery, restart and reconstruction procedures
iv. Details of files, tables, structures
v. Report specification
vi. Screen specification
vii. User guide for different level of operations, use of software tools
viii. Training manuals for different level of user training
ix. Documents on functions and features and limitations of the system
x. Screen, form and layouts
xi. Menu structures
xii. Technical manual on system installation, configurations, error
messages, trouble shootings

6.30.14 All the user licenses of the software products shall be licensed to MTML.
6.30.15 The successful bidder may use existing billing hardware available in MTML to the
extent possible.
6.30.16 The offered Billing & Custom er Care System (B&CCS) must be integrated with call
centre of 30 seats. Presently 10 seater call centre is operational in MTML Mauritiu s, This
shall be upgraded to 30 seats and a new software for call centre integrating the existing
CDMA network and the proposed GSM net work shall have to be provided. The new call
centre solution to be provided by the bidder m ust have IVRS (in atleast tw o languages –
English & French) and m onitoring/ supervisory functionalities. It should have the provision of
voice recording for atleast 5 ports which should be possible to be scheduled autom atically to
cover all agent positions. The reports related to agent perform ance and effective call
handling would be provided as per the requirem ents finalized in discussion with MTML.

170
6.30.17 The Storage shall support m ulti-tier architecture to support different
perform ance requirem ent of storage for different kind of data depending upon the
policy defined by user. High perform ance, m id perform ance, low perform ance and
off-line storage shall be supported.

6.30.18 The storage shall support GUI based storage m anagem ent software tools for
m anagem ent. The m anagem ent software shall enable storage adm inistrator to view,
m onitor, autom ate, provision and report on host storage resources, networks, and
storage across the entire inform ation environm ent from a single console.

6.30.19 Local Mirroring : Business continuity volum e

a. It shall support a point-in tim e consistent copy of the data (full volum e 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 volum e (BCV) of th e
data
c. At least 2 BCV shall have a separate and independent relationship with the
production volum e.
d. Shall support instant split of BCV from the production volum e
e. Shall support increm ental re-establish from the production data to each of the
BCV
f. Shall support increm ental restore from any of the BCV to the production data

6.30.20 Bidder m ust submit a detailed system s sizing docum ent containing at least
the following :

S.N. Items Sizing Parameter Taken

1. Pre-paid / Post paid subscribers In any com bination/ proportion

Mix of total subscribers
2. Retention of billed data 6 m onths bill im age and billed usage
3. Retention of unbilled data 2 m onths unbilled usage
4. CDRs/day/subscriber 20
5. Bill Cycle 8
6. CDR split factor 1.6
7. Usage size 511 bytes
8. Treatm ent of prepaid CDRs Stored in the SAN
9. Bill run duration per bill cycle Less than 4 hours
10. Rating per day Less than2 hours
11. SIM inventory m anagem ent 200% of total subscribers

6.30.21 The inventory managem ent and reconciliation of SIM cards for both pre-paid
and post paid subscribers shall be maintained in the B&CCS platform and shall be fully
integrated with the IN system . The inventory m anagem ent and reconciliation module
shall cater to at least twice the capacity of lines being tendered and shall be independent
of the capacity of the B&CCS being planned.

6.30.22 The system should have feature of notifying the subscriber over SM S regarding any
change in service or welcom e message once it is provisioned by B&CCS system. The system
should also notify the subscribers with a welcome m essage w hile registering in the system
on roaming.

171
6.30.23 The Device for taking the full monthly backup of the B&CCS data shall be adequately
dimensioned to ensure that the entire backup operation is perform ed within 4 hours
and without interruptions affecting the norm al functioning of the B&CCS.

6.30.24 The main features of existing B&CCs are annexed below. It should be
ensured that all exisitng features available in the current system are
made available in the proposed new B&CCS.

6.31 EXISTING Billing & Customer Care M odule

6.31.1 Customer Care M odule

Customer care module shall handle at least following operations with different
privileges for different operations. All customers related activities like
provisioning, De-provisioning, modification shall be done everyday at any
time.

6.31.1.1 Registration

The primary function of the registration shall be to enter the customer data
from the application form submitted by a probable customer. The system shall
generate a registration ID after data entry and immediately shall print the
registration slip automatically. The screen format for registration shall be
easily configurable by user as and when required.

6.31.1.2 Installation

The proposed B&CCS system shall have provision to handle the following at
user options immediately after required data is entered and/or at scheduled
date and time:
i) Customer Installation: Data retrieved from the registration and
additional customer data as well as subscriber data shall be used
for customer installation.
ii) Incomplete Installation: W hen all data required for installation is not
entered, the system shall store the input as incomplete installation.
The installation shall be completed after entering the missing
customer and subscriber data. The user with same or higher level
of access shall be able to retrieve the incomplete installation data
and complete it by entering missing data.
iii) The screen format for customer installation shall be easily
configurable by user as and when required.

6.31.1.3 Change of Ownership: The proposed billing system shall handle Change
of ownership (Name) on customer and/or phone users with and /or without
new customer ID keeping all other information same

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

6.31.1.5 Change of Phone Numbers: The proposed billing system shall handle
Change of phone numbers without changing other information.

172
6.31.1.6 Enquiry and update

a. The system shall have provision to enquire the customer/Subscriber data

by read only users as well as other authorized users.
b. The system shall have provision to enquire and update the
customer/Subscriber data by authorized users only.

6.31.1.7 Customer Information

The system shall have provision to view and update the following customer’s
information by inputting ant one of phone number, customer name, phone
user name, customer ID etc. as and when required by the user.
Customer Name, Address, Contact No. etc.
Customers’ subscription, credit limit, connection, reconnection, status etc.
Customers’ personal information like Profession, designation, salutation
etc.
Customer’s payment and adjustment history with details
Customers’ phone number history with status

6.31.1.8 Customer Services

The system shall have provision to provide the following services as and
when required:
i) Allocation of features and services available in switch, any one and/or
more of them
ii) Connection, disconnection and reconnection of lines
iii) Viewing and updating of customer history and services used by the
customers
iv) Reconnection of the disconnected customer manually and/or
automatically after paym ent is made.

6.31.1.9 Billing information

The proposed billing system shall have the following provisions:

i) Entering all billing related data
ii) Barring of subscribers manually and automatically
iii) Immediately Unbarring of subscribers manually and automatically after
payment is made
iv) Viewing and updating of customers’ bill history and details like bill
amount, calls related to bill etc.
v) Viewing of hot rated calls immediately
vi) Viewing of the chargeable calls

6.31.1.10 Ledger Information

The billing system shall provide followings:

i) To view and update the deposit history with details
ii) To review all comments of all transactions
iii) To view and update equipment information
iv) To view all the bills issued, amended, payments made and their detail
v) To view all the services provided to a customer

173
6.31.2 Fraud M anagement

6.31.2.1The primary function of Fraud Management is to control the customers who

are making calls more than the credit limits defined in the system. It shall
continuously check the total billed amount and unbilled amount of the calls
made by the customers. If it is greater than the credit limit amount, the system
shall initiate the action to the customers as defined in the system.

The following provisions shall be made in the system.

i) To group customers in different group of fraud management
ii) To define any number of credit limits to different group of customers
iii) To change credit limit as and when required
iv) To define any number of actions on each limit
v) The system shall have provision to check credit limit amount defined in
the system with total billed amount and unbilled amount with taxes
during the processing of fraud management and take the necessary
action as defined in the system for the limit.
vi) The system shall have at least three levels of credit limit with different
actions for each level.
vii)The system shall produce the report with actions taken as the fraud
management process completes automatically daily, period wise etc.
The system shall support Fraud management system according to MTML’s
requirement as and when required.

6.31.2.2 Follow ups

The primary function of Follow ups is to generate information for the users
regarding the actions to be taken to handle the customer related actions. The
Follow up actions on a customers’ account is entered into the system. If som e
transactions to be carried out on a certain customer. after completion of the
job, the follow ups entry shall be automatically removed.

The system shall have provision to view and update the follow ups actions to
be taken care of. It shall also have provisioned to remove the follow ups
actions immediately after the job has been done.

6.31.3 Reports M odule

Different Reports/ Queries Generated by the Billing and Accounting Sub-

system under the following Categories shall be possible :

(i) Reports for Management.

(ii) Reports on which routine action is required to be taken.
(iii) Exception Reports on which immediate action is required.
(iv) Archival Reports.

Reports to be generated in Billing & Accounting Modules shall be

customizable. Some of the indicative reports are given below:

Various reports generated by a system shall broadly fall under the following
categories;

(i) Management Reports :

174
 a) Revenue collected in a month.
b) Revenue per DEL.
c) Comparison of Revenue per DEL with previous year.
d) Annual Revenue per DEL.
e) Cumulative Revenue collection in a Financial Year.

(ii) Action Reports :

a) Disconnection List.
b) Ringing List.
c) Excess Paym ents.
d) List of unaddressed bills.
e) Short Payments.
f) List of Abnormal STD/ISD calls.
g) List of Outstanding Bills at any point of time.
h) List of cheques dishonoured.

(iii) Exception Reports:

a. List of Bills Cancelled
b. List of Bills Adjusted
c. List of voluntary Deposits Adjustments.
d. List of Deposit Adjustments
e. MIS Reports

(iv) Archival Reports

a. Local call statement
b. Trunk Call statement
c. Bill Register
d. Outstanding Register
e. Subscriber Record Cards
f. List of Reconciled Payments
g. List of UN-Accounted/ Excess Payments
h. Sub-Ledger Accounts.

The system shall provide unlimited enquiry capabilities to all users of the
system. These enquiries shall include enquiry on advice notes, bills,
customer record, deposits, demand notes, wait list, working line request,
payments etc. All the enquiries shall be able to take unlimited combinations
of parameters and display maximum information on the screen. These
enquiries screens shall from the front end of customer Service Centre, and of
an operator at the call centre and also to all the officers of the organization.

The proposed system shall have provision to generate and print the reports as
and when required. The reports indicated above are indicative and actual
requirements can be finalized later.

6.31.4 CDR Collection and Bill Processing M odule

6.31.4.1 Online Data Transfer

i. The proposed billing system shall collect online Call Detail Records
(CDR) from the switch.
ii. The proposed billing system shall collect online Call Detail Records
(CDR) from multiple switches of different make and model.

175
 iii. The proposed billing system shall collect CDRs to B&CCS from
switches on hourly basis in scheduled mode or as and when requested
by user.
iv. The online CDR transfer in scheduled mode shall be user configurable
v. For Hot Rating subscribers, the CDRs shall be transferred immediately
near real time.
vi. Hot Rated calls shall be handled separately.
vii. All necessary tools, software and hardware interface for such EDI
transfer shall be provisioned in the system.
viii. The CDR data shall consist of all types calls specified in the call data
requirement
ix. The proposed billing system shall have provision to retransfer the
CDRs if required.

6.31.4.2 Off Line Data transfer

The proposed billing system shall have provision to transfer the CDRs from
switches to B&CCS system from offline media, in case of EDI failure.

Off line data transfer or received shall be identified by users in later dates.

6.31.4.3 CDR data conversion

i. The system shall manage all types of CDR formats collected from different
types of switches

ii. All CDR retrieved from different switches using above mentioned methods
shall be converted by a common format conversion method

iii. The proposed billing system shall be able to manage and support fixed
and variable formats.

iv. The proposed billing system shall support and manage CDRs of
variable/fixed record lengths of usage data retrieved.

v. The system shall also provide CDR filters for call selections and filtering.

vi. The billing system shall also support assembling of partial records.

6.31.4.4 CDR Data Validation

i.The proposed billing system shall have capability to recognize duplicate

CDRs and report such occurrence but in the mean time avoid retrieval of such
data.

ii.The proposed billing system shall have possibilities for allowing manual
corrections to CDRs and transfer to billable data through a well defined user
screen.

iii.The proposed billing system shall have provision to isolate calls of c ertain
duration, overlapped duration.

176
 iv.The proposed billing system shall validate the contents of the CDR as per the
error types defined. It shall report such errors.

v.The system shall have provision to discard or correct those error CDRs and re
process if required.

6.31.4.5 CDR Data Rating

i. The proposed billing system shall rate each CDR based on rate tables on
near
real time or on scheduled mode automatically , which shall be easily
configurable by users
ii. The rating process shall also be started by user request.
iii. The proposed billing system shall have provision to carry out the rating
process
many times a day.
iv. In case of Hot Rating, system shall rate the calls on real time basis
immediately after completion of calls.
v. The B&CCS shall calculate the usage charges of a detail records based on
services and tariffs associated to the rating plan.
vi. The billing system shall report the error calls, which are not rated due to
incorrect
or missing tariffs, during rating process as per the error types defined.
vii. The system shall have provision to discard or correct those error calls and re
process if required through well defined user screen.
viii. The system rate the calls depending upon Outgoing call, Incoming call,
Forwarded call, Event record etc. with base station wise, switch wise etc.
ix. The proposed billing system shall rate the calls of one switch’s subscribers
but
making calls from different switch while roaming.

6.31.4.6 Tariff

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

The B&CCS system shall provide different prices for different subscription
types, which can have different services, facilities, events.

It shall apply different kinds of charge for the following:

 Fixed Charges
 Connection and monthly charges for services and subscription
 Charging for both outgoing and incoming calls
 Data volume sends or received

It shall charge the call depending upon

 Called Number
 Calling Date
 Calling Time
 Duration
 Cell ID
 Day

177
  Holidays
 Switch
 Size of data

The B&CCS shall assign any tariff rate to any charging zone and to any cell Id
for both outgoing and incoming calls. It shall be configurable by use as and
when required.

It shall support at least 50 different groups of rate for national and

international calls, which shall be configurable by user as and when required.

The B&CCS system shall consist of time packages to cover 24 hours, 7 days
time intervals and different types of special days.

Outgoing and incoming calls’ usage charges shall be calculated separately.

It shall handle additional fees and discounts

It shall have provision to rate for the transferred calls.

The system should support Closed User Group (CUG) billing. The CUG can
be the groups in which the calls are restricted within the group or allowed
outside group for some members of the group. There should not be any limit
in the number of members in a group or total number of groups.

The system shall have provision to create and apply the tariff immediately or
as scheduled by user.

The system shall keep the history of all tariff changed with date and time.

6.31.4.7 Discounts

The B&CCS system shall have provision to

a. apply flat discount
b. to use different discount scheme for different customer groups
c. to define volume discounts scheme for different customer group

The discount shall be based either on Duration and/or amount and/or

combination of Duration & Amount with at least three different limits for
customer groups.

The B&CCS system shall support discounts both on outgoing and incoming
calls.

The B&CCS system shall support discounts on different services like data,
voice etc. separately.

The system shall provide different discounts on different types of calls like
local, STD, ISD etc.

The system shall provide discounts on

a. Amount
b. Percentage

178
 c. Amount and Percentage

6.31.4.8 Preparation for Bill creation

a. The system shall have provision for processing of usage data from any switch
for the purpose of testing or production of traffic and error analysis reports as
and when required without causing any malfunctions in the regular bill
production process and financial transaction
b. It shall have provision to check and verify completion of preceding tasks
before initializing bill generation.
c. Some checking’s and verifications shall be done in the system for the bill
productions.
6.31.4.9 Credit Control

a. The proposed billing system shall have various levels of credit limits.
b. The system shall check the credit limit against billed and unbilled amounts
with taxes automatically, whenever rating is done. However, such checks
shall be done on user request
c. The fraud management initialized as a result of this checks.
d. The credit limits and levels shall be easily configurable by user.
e. It shall support the different credit limits for different customer group.
f. It shall generate reports on all customers, subscribers that have exceeded
their limits during credit limit check.

6.31.4.10 Billing M odes of Operation

Normal Bill Run

The billing shall support billing of all customers for a selected bill cycle.

On Demand Bill run

The system shall have provision of immediate billing of a customer or group of
customers without financial implication in the system.

6.31.4.11 Bill type

Following different types of bill for the customer shall be provided in the
system.
 Normal bills on Subscriber/customer basis
 Consolidated bills for the customer using more than one connection
 Department/Level wise bills for large organization
 Summary and itemized bills as per customer requirements

6.31.4.12 Billing Cycle

a. The proposed billing system shall support multiple billing cycles within a
bill period for different group of customers
b. The system shall have at least 8 (Eight) different billing cycles.
c. The bill processing shall be in multiple bill cycles.
d. The bill cycle shall be assigned to a single customer or group of
customers.
e. The system shall have provision to transfer one bill cycle to another for a
customer or group of customer
f. The vendor shall mention number of billing cycles in system, if any.

179
6.31.4.13 Billing period

a. The B&CCS system shall have provision for generation of a number of

customer’s bills for all the customers in one month.
b. It shall be possible to adjust the billing periods by user as required.
c. The B&CCS shall have facilities to handle multiple billing periods for
different group.

6.31.4.14 Bill generation

a. The B&CCS system shall calculate summary charges for each customer
by relating to rated calls and their subscription charges.
b. The system shall calculate short period rental for initial billing, based on
date of installation or transfer.
c. The system shall calculate previous dues.
d. The proposed billing shall manage different due dates for different
customers.
e. The system shall also calculate summary charges as following items:
 Rental
 Supplementary Services charges
 Administrative charges
 Local call charges
 National Call charges
 International Call charges
 Discount
 Fines
 Taxes etc.

f. It shall also summarize consolidated bills for customer paying for many
subscribers and or services
g. The system shall process billing generation of different group of
customers in different billing cycles.
h. It shall have provision to produce on demand bill as per MTML
requirements.
i. During Bill generation Printing will be done centrally.
j. During Bill Generation, calls up to the end day of the defined Billing
period only shall be included even though next billing periods calls are
already rated in the system.

6.31.4.15 Bill Production.

The production of customer bills shall be flexible and support the following
functions:
 Production of hard copy bills (in English) for a specified time period
 Updating sales ledger
 Individual bill production or a copy of a bill between periods on request
 Call details (Call details shall be flexible and for specified categories
i.e. ISD , STD , Local and Incoming)
 Facilities to print a number of selected customers’ bill from host
terminal & also from remote terminal.

180
  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 M auritius and

easily configurable by user as and when required.

Facilities to provide discount, adjustment, rebate, fine etc. on periodic bill

Facilities to produce the bill of permanently disconnected customers as
required by MTML.

System shall have provision to produce the bill of a customer of group of

customers as and when required by MTML.

The system shall provide the tools for selecting, combining and modifying bill
layouts.

The system shall execute bill production for multiple groups.

Facilities to produce different types of bills

 on paper
 direct debit records to banks
 EDI (Electronic Data Interchange) bills

6.31.4.16 Hot Rating:

The system shall rate the call real time for hot rating subscribers.

Such calls shall be accessed by customer by various means of secured

communication link; Dialup, Leased, Internet.

Necessary interface units and secured access method shall be provided.

6.31.4.17 Bill statement

The proposed billing system shall provide tools for layout configuration of bill
formats and receipts.

It shall have the facilities to generate multiple formats as and when required.

The Bill printing should have the information required for paym ent matching in
standard BARCODE to be scanned by collection centres.

The customer bill statement as per MTML requirement shall be designed &
developed during system study.

6.31.4.18 Reports on CDR collection and Bill processing

181
 All major reports shall be generated by the system on completion of the major
process and also shall be generated by user as and when required. The
reports shall be produced by entering one and/or multiple fields contained in
the report. The report shall be for selected period of time
The produced report shall be printed as required.

(A) CDR collection report

The system shall generate this file transfer report daily, weekly, monthly
basis weekly at least following items:
 File name
 Date & time of transfer
 File status
 Name of switch
 Size of file
 Start and end date, time of data in the file
 User id
List of file rejected or unsuccessful with reason
List of retransferred files

(B) Conversion report

i. The system shall generate this file conversion report daily, weekly,
monthly basis with at least following items:
File name
Date & time of conversion
File status
Name of switch
Size of file
Start and end date, time of data in the file
Total processed calls
User id
ii. List of calls rejected with reason

(C) Call rating Report

i. The system shall generate the Summary of calls rated daily weekly,
monthly and as and when required with at least following items:
 Name & size of files
 Total calls, duration, and charge by call type
 Total calls rejected by error type and call type
 Date & time file was rated
ii. List of rejected calls by error type for each CDR file daily , monthly,
certain period, as and when required
iii. Reports for traffic analysis shall be produced on each rated file:
 Hour-wise totaling of calls, duration, charge by call type
 Day-wise totaling of calls, duration, charge by call type
 Month-wise totaling of calls, duration, charge by call type
 Given period wise totaling of calls, duration, charge by
call type
iv. Total unbilled call charge report per file by call type
v. Report on Corrected calls

(D) Bill creation and Production report

182
 i) Report of each bill run for billing cycles
ii) Error report during each bill cycle
iii) Summary of charges for each bill cycles for all customers individually
and/or totally
iv) Discount report
v) Fine report
vi) Adjustment report

(E) Summary Control Reports

i) Summary of calls , duration, CDR files used for each bill group of
the billing period
ii) Total no. of calls for different types of calls.
iii) Total no. of calls and duration summary report by customer
iv) List of high paying customers for each billing period
v) Credit/Debit card reports
vi) Report of calls before and after invoice run for a billing period
vii) Report of calls that was not billed due to some reason for a billing
group

6.31.5 Customer Ledger and Cash Collection M odule

6.31.5.1 General

The proposed Ledger and Cash Collection m odule 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 als o
propose additional relevant features available in the offered system for
efficient management and maintenance of the accounting and collection
system.

6.31.5.2 Cash/ Debtor collection

The system shall support for on-line cash collection and on-line updating of
the ledger system. It shall also be possible to update the customer ledgers on
batch mode.

183
 This module shall manage collections through different counters of MTML.
Collection details shall be reflected in the central database in order to provide
the respective up- to- date information in all the collection centers. The
transfer to Central Collection Daybook shall be initialized after verification of
the transactions at each collection counter. The system shall always
recognize collection items of each counter and manage accordingly. The
collections made at bank shall be transferred, verified and updated after
automatic checking of all payable amounts including taxes, penalties etc.

(A) Debtor collection

Collection amounts:
The collection amounts for debtor collection shall mainly consist of
followings:
 Bill amount (total amount as per Bill Statement)
 Previous dues
 Service Charge
 VAT amount
 Other Taxes
 Penalty amount
 Reconnection charge

The system shall have provision to increase or decrease the number of

items under collection amounts. The rules and logic for calculations
shall also differ. The system shall be flexible enough to handle all such
requirements through user interfaces.

In case of partial payment of the bill amount, the system shall calculate
Taxes (TSC, VAT and other Taxes) based on the submitted cash/
cheque amount.

It shall collect payment from the customer by phone number, Customer

ID, Invoice No., Consolidate Account ID. The system shall also collect
for a group of customers and receipts shall be generated for each such
customer.

The collections shall be against each bill or several bills or all dues.
The system shall be able to generate one receipt for such type of
collections. The system shall always clear oldest dues on collection.

System shall accept partial payment against any account and shall
automatically clear the oldest dues. System shall accept amount
equivalent to a single bill, groups of bills or all bills and generate a
single receipt for the receipt.

The system shall accept partial and/or full payments from the
customers. The tax amount shall be calculated accordingly.

This system shall make provision for granting rebate to the customers,
which shall easily configurable by user as and when required.

System shall calculate penalty as per MTML rules and regulations.

184
 Collections shall be in cash, cheque, credit card and/or their
combination.

The system shall have the facility for bank collections on-line and in
batch mode.

The system shall automatically generate the penalty amounts, check

the penalty payments and generate reports if required.

The system shall have the provision to wave penalty fully or partially by
a privileged user.

(B) Deposit collection

This system shall accept deposits from customers by

a) Phone No.
b) Customer ID
c) Customer name
Provisions shall be made for refunding of deposits in all cases.

During new installations, other charges shall be accepted along with

the deposit. However, separate receipts shall be generated for such
charges.

The proposed billing system shall provide Depositors’ lists with detail
ledger and its history.

Interest on customer’s deposit shall be calculated and posted by the

system as per MTML’s rule

(C) Cash sales

Besides debtor and deposit collections, other paym ents against cash sales
such as followings shall be acceptable in this system .
 Registration fee
 Installation charge
 Ownership charge
 Sale of handsets, accessories etc.
 Ownership transfer charge
 Contract change charge
 Taxes for above charges
 Charge of detail bill print out

The system shall have provision to increase or decrease the number of

items under cash sales. The rules and logic for calculations shall also
differ. The system shall be flexible enough to handle all such
requirements through user interfaces.

(D) Advanced collection

185
 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 m odified in any
case. However, the system shall have the provision to make am endments if
errors are detected through vouchers raised by cashier/manager only. The
system shall also have provision to cancel receipts before update by a
privileged user.

The system shall have provision for reprint of receipts immediately and
control mechanism for such reprints.

Receipts layouts shall be flexible and the system shall be provided with
tools to modify them.

There shall be provision for using pre-printed receipts, which shall be

different as per collection types and services.

The system shall generate continuous serial numbers of the collection

receipts. The system shall also have provision to reprint the collections
receipt. The summary report shall indicate the number of reprints and
their serial numbers.

The receipts shall be printed on local printer attached to the terminals.

(F) Verification on collection and updating of accounts

This system shall be able to generate various reports, for verification, as

follow s.
By counter cashier
At the end of the day, the counter cashier shall be able to generate Summary
reports indicating amount tendered by each custom er, am ount refunded by
counter cashier, collection am ount, total collections under different headings
e.g. Bill am ount, Penalty am ount, Tax am ounts, Deposit am ount 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

186
 The proposed billing system shall have provision to query and generate
the following reports:
 Collection Report of each collection counters.
 Accounting Center-wise Collection Report
 Region-wise Collection Report (daily)
 Corporate Collection (Daily) Report
 Summary Report of different taxes collected (daily)
 Collection Report for late payment (daily, monthly)
 List of adjustment vouchers relate to collections

6.31.5.3 Ledger

This system shall maintain and control all customer ledgers. The system shall
have high accuracy and security controls in all the functions performed.

(A) Bill posting

Bill posting and updating of debtor accounts and other related account heads shall be
possible. The bill posting and updating of accounts shall be carried out by using
invoice run batch code or selected custom er or accounting center wise etc.

Bill posting to the related account heads shall be committed only after
automatic verification by the system.

The system shall have provision for reverse posting.

The system shall have provision for consolidated accounts.

(B) Cash collection and update

This system shall have the provision to post collected cash details to relevant
account heads. The posting shall be carried out only after verification of
the cash collection reports.

(C) Debtor management

Reports and queries

a) Listing of debtors by customer status (government, corporate, private

customer etc.
b) Listing of debtors for given (a) range of period and/or (b) balance
amount.
c) Debtor list (a) by switch, (b) accounting center wise, (c) region-wise
and (e) Credit Limit.
d) Detail ledger of all customers.
e) Queries on debtor collections by respective accounting center.
f) Queries on debtor collection of the customers located in other
accounting center.
g) Queries on customers’ up- to- date balance and detail ledgers based
on period and balance amount.
h) Customer history with individual accounts details.

187
 i) Billing summary Report.

Summaries of all fields of billing statement are to be ascertained in

these reports from periodic billing statement issued to the date.
Reports shall be produced by GOVT., Company/consolidated, Service,
Individual and shall show the following Data fields:

Customer ID, Periodic Prorate Rental Charge, ATC, Incoming:

Duration- amount, Outgoing: Duration – Amount, STD: Duration,
amount, ISD: Duration, amount, Roaming: National, International,
Supplementary/ Value added service charges, Discount, Sub- Total
Amount, Rebate, Fine, Total amount (Before TSC & VAT), Total Taxes,
Total bill Amount (Including TSC & VAT).

Age wise classification of debtor balance

The system shall be able to classify debtor balance for various periods
(ages). The classifications shall be based on age groups from one
month to 6 months in steps of one month.

(D) Defaulter management

This system shall identify such subscriber w ho has not cleared dues (bill payment) in
time. The system shall prepare defaulter list according to customer status, total due
am ounts 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 paym ent by cheque again unless otherwise permitted by the authorized
person.

188
 (E) Voucher Entry

All adjustments to the ledger system shall be done though voucher entries.
The voucher entries shall be manual and/or system generated for certain
defined tasks.

The system shall have the following possibilities:

Voucher entry to adjust accounts of all account heads and updates by only
certain user group. Adjustments to some account heads shall be restricted to
privileged users only.

The system shall have provision for manual entry, verification and update
through vouchers of (a) receipts (b) bank statement against collections made
off-line.

Listing of vouchers from daybook (collection counter-wise or accounting

center-wise)

Provision for correcting wrongly entered data in daybook.

The updated vouchers shall not be modified. Records marked as posted or

updated shall not be modified. The system shall have provision for correcting
posted data by generating relevant approved vouchers only.

The system shall create and generate vouchers for bulk adjustments. The
criteria for such adjustment shall be defined by user input.

During entry and update of vouchers, automatic verification of debit/credit

amount shall be carried out.

It shall be possible to identify vouchers by entry users, counters, accounting

centers, entry and transaction dates, voucher types, etc.

(F) Trial balance

The system shall provide the following:

Provisions for uptodate Trial Balance accounting center-wise, region-wise and

in total.

Trial balance generation for a user defined period.

Automatic generation of trial balance report after each batch of updates

resulting changes in amounts.

Summary of balance of all Customers ledger shall be summarized in Trial

Balance on daily basis. The Trial Balance shall be produced on daily basis as
per the MTML’s requirement formats.

The system should having the facility of creating flat files by the required tools
to export/import data to other systems like financial systems as required by
the users.

189
 (G) Other queries

The offered B&CCS system shall provide the following queries:

a) Query for cash in transit
b) Query for up- to- date balance of all account heads defined in the system

(H) Date format

All transactions in the system shall have fields to store English Calendar date.
All system operations such as entry, posting, viewing, reporting, etc, shall
use English calendars.

(I) Flexibility for the module

The proposed system shall have provisions for following operations:

- Adding account heads
- Creating and removing levels of account heads (main, sub, sub-sub,
detail, etc.)
- Adding collection counters/ accounting centers
- Application of different taxation rates as per government notice.
- Application of penalty rates as per prevalent rules
- Application of prevalent rebate schemes

6.31.6 Disputes management

The system shall register complains on bills.

The system shall have the possibility to retrieve full history of all disputes raised
by a customer.

The system shall have credit adjustment possibilities for settlement of disputes.

6.31.7 Inter connect M anagement

The system shall handle inter connect billing and collection of data for such
billing.

The system shall have interfaces to enter, update or delete various operators’
information, tariff, discounts and other agreement details

The system shall provide such agreements with GSM, PSTN, Local and
internationals.

The proposed system shall have provision for generation of queries and reports
on charges to be claimed from other operators.

The report shall contain total no. of calls, total duration, total amount in different
currencies like US$, Mauritian Rupee etc. and it shall be destination-wise,
origination-wise, period-wise etc. for each operator

The B&CCS have provision to compare and verify those data received from
other operators with the data contained in the system.

190
 The system shall support different tariff plan.

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

6.31.8 Fault M anagement System

The main functions of the Fault Management system shall be as follows:

i. Complaint Booking
ii. Initial Testing
iii. Sub-Fault Control
iv. Final Testing
v. Clearance of Faults
vi. Batch Mode Booking of Faults and Complaints
vii. Report and statistics on complaints/faults for MIS and SLA
viii. Automatic Rebate calculation based on downtime

6.31.9 Directory Enquiry System

The main requirements of the system are:
i) Should be flexible to adapt timely to new requirements.
ii) Automatic updating of DQ information based change in customer
status should be provided.
iii) Possible to search the database with different combination of elements.
iv) should support complex searches and search arguments such as starts
with , End in etc.
v) Should be able to provide data for Directory printing

*******

Section V

SCHEDULE OF REQUIREMENTS

Description Unit Phase 1 Phase 2 Total Remarks

Sl No.

Common core for

1 NSS
GSM 2G/3G

1.1 GMSC/MSC/ VLR System 1 - 1 Design as per RFP

1.2 MGW x - x As per vendor design

191
 Capacity atleast
310,000 subscriber,
1.2 HLR/AUC/EIR System 1 - 1
including existing
CDMA

MTML reserves the

HLR upgrade to HSS architecture right to order this
1.3 0 1 1
for R5 support upgrade independent
of Phase-II P.O.

IN System including IVR for Common for both

2
Prepaid (2G & 3G Subs) CDMA & GSM/3G

For 500 K It shall be possible to

2.1 Hardw are 1 0 1
subs expand the IN to
For 500 K support 1M Subs.
2.2 Software 1 0 1
Subs

New comm on VOMS & Adm in For 500 K Shall support 1M

2.3 1 0 1 active recharge PINs.
system Subs
No limit should be on
2.4 E-Top Up/ E-PIN system 1 0 1 total PINs generated
in IN.

3 Operation & Maintenance System

OSS supplied in
3.1 (a) Comm on 2G / 3G / CDMA OSS 1 - 1 Phase-I shall required
for com plete netw ork (Hardware) to be expanded for
(b) Comm on 2G/3G/ CDMA OSS Phase-II requirem ents
1 - 1 free of cost.
for com plete netw ork (softw are)

3.2 OMC-S

Hardw are & S/W Per PLMN 1 - 1

OMC-R (comm on for GERAN &

3.3
UTRAN)
OMC – R supplied in
Phase-I shall be
a Hardw are & Softw are Per PLMN 1 - 1 expanded for Phase-II
requirem ents.

Sl No. Description Unit Phase 1 Phase 2 Total Remarks

Combined Packet Core Network

4 for 2G & 3G Subs

4.1 2G / 3G GGSN

For 50K
a 2G / 3G GGSN Hardw are PDP 1 0 1
Contexts
For 50K
b 2G / 3G GGSN Softw are PDP 1 1 2
Contexts

4.2 2G / 3G SGSN

For 50K
a 2G / 3G SGSN Hardw are PDP 1 0 1
Contexts
For 50K
b 2G / 3G SGSN Softw are PDP 1 1 2
Contexts

192
 5
SMSC

For 200 K
5.1 Hardw are 1 0 1
BHSM

For 200 K
5.2 Software 1 0 1
BHSM

6 Location Based Services

For 100 K
6.1 GMLC 1 0 1
subs Equipm ent supplied
in Phase-I shall be
For 100 K
6.2 SMLC 1 0 1 expanded for Phase-
subs
II requirem ents.
For 100 K
6.3 Location Based Application Server 1 0 1
subs

Transaction
6.4 Location Based Softw are license 10 0 10
per second

6.5 Cell Broadcast System (CBS) 1 0 1

This item is optional.

How ever, the sam e
7 Push to Talk System (PTT)
w ill be considered for
evaluation.
For 20K
7.1 PTT Hardw are 1 0 1
Subs

7.2 PTT Softw are 20K Subs 1 0 1

7.3 PTT handsets 25 0 25

Multi-Media Messaging Syste m

8
(MMS)

For 10K Equipm ent supplied

8.1 MMSC Hardware 1 0 1 in Phase-I shall be
BHMM
expanded for Phase-
For 10K II requirem ents.
8.2 MMSC Softw are 1 0 1
BHMM

8.3 W AP Gatew ay 1 0 1

9 OTA server 1 0 1

10. BSC

As per bidder’s
10.1 BSC Hardware X Y X+Y
design
TRX count for m icro
BTS and expansion
in Phase-II m ay be
included. Calculation
10.2 BSC Softw are Per TRX
sheet for the total
num ber of TRX for
each phase m ay be
attached.

10.3 Transcoder

As per bidder’s
10.4 PCU Per BSC X Y X+Y
design

193
 GSM BTS ( All new BTS/ TRXs
11
should include EDGE hardware)

900 MHz Macro BTS (distributed

architecture BBU+RRU) 3+3+3
11.1 Configuration (Indoor type) should Per BTS 50 50
be support EGSM/ 1800/ 2100 band
also in future by adding only RRUs
The num ber of BTSs
m entioned are
900 MHz Macro BTS (distributed
minim um. The bidder
architecture BBU+RRU) 3+3+3
11.2 Per BTS 60 40 90 should quote m ore if
Configuration (Outdoor type) should
its design requires so
be support EGSM/ 1800/ 2100 band
for m eeting
also in future by adding only RRUs.
requirem ents

11.3 Micro BTS Per BTS - - - As per bidder design

Cell on W heel (CoW ) – Mobile BTS Optional Item but w ill

11.4 alongw ith all accessories, tow er and Per BTS 2 0 2 be considered for
trolly evaluation.
One per
11.5 EDGE TRU softw are 110 40 150
BTS

11.6 2G BTS repeater of 2 W att pow er 10 0 10

UPS w ith 2 hour back up for BTS

11.7 10 0 10
repeater

12 BTS Expansion Kits

BTS E xpansions from 3+3+3 to

12.1 Per BTS 0 40 40
6+6+6 (3+3+3 in 900MHz & 3+3+3 in
1800 or EGSM band
The order for this
m ay be placed before
12.2 Upgradation to HSDPA/ HSUPA Per BTS 0 150 150 the Phase II order
also for som e BTSs
only.

HSDPA should be
12.3 HSPA Software Upgrade Per BTS 0 150 150 available in all
sectors of one carrier
per BTS.

BSC/ RNC Hardware & Software As per bidder’s

13 - X X
for HSPA design

Infrastructure Equipment for Non

14
MTML sites
14.1
Including
Set of 9
Antenna
Roof Top Tow er 9 Meters 15 10 25
Mounting
fixture per These quantities are
tow er. for evaluation
purposes. Ordering
of this item shall be
14.2 Roof Top Tow er 12 Meters -do- 5 5 10 as per actual
requirem ent of
-do- MTML.
14.3 Roof Top Tow er 15 Meters 5 5 10

-do-
14.4 Roof Top Tow er 21 Meters 5 5 10

194
 Set of 9
14.5 Poles 6 Meter Poles per 5 5 10
site
-do-
14.6 GBT 30 Meter 10 5 15

-do- These quantities are

14.7 GBT 45 Meter 15 5 15 for evaluation
purposes. Ordering
Per site of this item shall be
Any m odification/ expansion required as per actual
14.8 50 0 50
in existing MTML site towers/ shelter requirem ent of
MTML.
Palm Tree type tow er (30 Meter) for Optional item but w ill
14.9 asthetic look m atching the 5 0 5 be considered for
environm ent evaluation.

15 Battery and power plant

Additional Outdoor Battery cabinet These quantities are

15.1 Per Set 30 20 50 for evaluation
having 4 hr backup
purposes. Ordering
of this item shall be
Expansion of MTML sites pow er as per actual
15.2 Per Site 50 0 50 requirem ent of
plant and batteries if required
MTML.

Indepenedent Pow er Plant (SMPS)

Optional item s but
and Batteries for Core Netw ork Site,
15.3 1 0 1 w ill be considered for
if it is separate than the present
evaluation
CDMA site
DC Pow er Distribution Board
15.4 Per site 60 40 100
(DCPDB) of suitable capacity

Battery sets for BSC/ RNC sites if

15.5 X Y X+Y
planned separately

Battery sets for MSC/ MGW sites if

15.6 1 0 1
planned separately

15.7 SMPS Pow er plant for BSC/RNC X Y X+Y

Expansion of SMPS pow er plant for

15.8 comm on core n/w elements site if 1 0 1
the existing site is used

15.9 UPS/ Inverter for MSC/ OMC etc 1 0 1

16 Installation Material

16.1 BSC/ RNC Installation Material Per Site X Y X+Y

These quantities are

16.2 BTS Installation Material - New Sites Per Site 60 40 100 for evaluation
purposes. Ordering
of this item shall be
as per actual
BTS Installation Material – MTML requirem ent of
16.3 Per Site 50 0 50
sites MTML.

These quantities are

for evaluation
purposes. Ordering
of this item shall be
16.4 Feeder Cable 7/8" - BTS Per site 110 40 150
as per actual
requirem ent of
MTML.

195
 Additional items if the core netw ork Optional item but w ill
16.5 is tobe installed at a separate 1 0 1 be considered for
location evaluation
All 3G antennae w ith
rem ote variable
17 Antennae with mounting fixtures
electrical dow n tilt
shall be quoted.
65 degree beamw idth (Gain >=17 These quantities are
17.1 Per site 110 40 150 for evaluation
dbi) Dual Band
purposes. Ordering
of this item shall be
65 degree beamw idth (Gain>=17 as per actual
17.2 dbi) Tri band - For W CDMA 3 sector Per site 110 40 150 requirem ent of
sites MTML.

18 Transmission Media for all sites

18.1
SDH M/W links Per Hop 50 20 70 These quantities are
(a)
for evaluation
18.2 purposes. Ordering
NMS for SDH 1 0 1
(b) of this item shall be
as per actual
18.3 PDH augm entation Per Hop 50 20 70 requirem ent of
MTML.
Installation Material including
18.4 Per Hop 100 50 150
Antennae, cables etc.
Additional transm ission links,
including the cost of accessories if Optional item but
18.5 the core netw ork is installed at a w ould be considered
separate location than the existing for evaluation
MTML site

Tools and testers

19

RF Planning Tool 1 0 1
19.1

Drive test tool 1 0 1

19.2
Post Processing Tool w ith digital
1 0 1
19.3 m ap

Protocol Analyser 1 0 1
19.4
Hand held GPS receiver
2 0 2
19.5

BTS/ Node B tester 2 0 0

19.6 .
W CDMA (UMTS) Transm itter
1 0 1
19.7 Analyser

W CDMA (UMTS) Over the Air

1 0 1
19.8 Analyser

Engineering Handsets 5 2 7
19.9
B&CCS expansion/ upgradation or 1 0 1
20 replacement with new one

30 20 50
20.1 CSR terminals

Call center interface for 30 seats 1 0 1

20.2

196
 Lawful Interception & Monitoring 1 0 1
23
FMCC (Fraud Management
1 0 1
24 Control Centre)
Optional item but w ill
Push Mail Server 1 0 1 be considered for
25 evaluation
Spares for three years after
1 set 1 set
26 warranty & AMC
Outdoor BTS cabinet (without Optional item but w ill
BTS) for putting existing CDM A 50 0 50 be considered for
27 BBUs evaluation
Any Other Item not mentioned in
RFP, but is required for
28a completion of project as per RFP
These w ould be
Any Other Item not mentioned in
optional items and
RFP and not required for project
w ill not be included
but which bidder feels would help
for evaluation but
MTML in competing effectively &
m ay be considered
providing better services
28b for ordering.

Services: The price of services for respective quantities

mentioned above against each item may be quoted.

Sl No. Description Unit Phase 1 Phase 2 Total Remarks

29 Installation and C ommissioning

MSC server
29.1

29.2 Media Gatew ay

29.3 HLR

29.4 IN

29.4 STP

29.5 Packet Core Netw ork

29.6 SMSC Installation

29.7 LBS Installation

29.8 PTT Installation

29.9 MMS Installation

29.10 BSC Per unit X Y X+Y

29.11 GSM BTS Installation -New

Per BTS
(a)

29.11
GSM BTS - E xpansion
(b)

197
 29.11
GSM BTS installation – SW AP site
(c)

29.11
Micro BTS Installation Per BTS
(d)

29.11
GSM TRX E xpansion Per TRX
(e)

29.12 RNC Per unit A B A+B

29.13
NODE B Installation Per Node B
(a)

29.13
Micro Node B Installation Per Node B
(b)

29.13
W CDMA TRX/carrier Expansion Per TRX
(c)

29.14
Roof Top Tow er (9,12, 15,18 m )
(a)

29.14
Poles
(b)

29.14 Ground Based Tow er (GBT) of 20,

(c) 30 & 40 m eter

29.14
Delta Poles 6 meters and 9 m eters
(d)

29.15 Pow er System & Battery Installation Per Set

29.16
Transmission Media – SDH Per Hop
(a)

29.16
Transmission Media – PDH Per Hop
(b)

29.17 B&CCS Installation Per Unit

29.18 RF Survey

29.19 Project Managem ent Per PLMN

Operation support for 3 m onths of

29.20
Commercial launch

Decomm issioning &

29.20 Recomm issioning of any netw ork
elem ent envisaged.

29.21
Upgradation of existing elem ents

30 Annual Maintenance Contract

30.1 Year 1
30.2 Year 2
30.3 Year 3
Any other item /Services to meet the
31 tender requirem ent. (Details to be
given)

Note: - The quantities indicated in above Bill of Materials are m inim um except for those item s w here specifically it has
been m entioned in rem arks colum n that “These quantities are for evaluation purposes. Ordering of this item shall

198
 be as per actual requirem ent of MTML”. Bidders shall quote for the actual B.O.M required to m eet the tender
obligations for successful com pletion of project.

Section VI

Delivery Schedule

A. Completion of Factory Inspection at W ithin 3(Three) months from the

Manufacturer’s Premises, if date of PO.
required by MTML

B Commencement of Supply of W ithin 4(Four) months from the

Equipments date of PO.

C Commissioning of Core Network and W ithin 7(Seven) months from

BTSs at existing MTML sites the date of PO.
D Commissioning of IN, B&CCS and W ithin 11(Eleven) months from

199
 75% of the balance BTSs the date of PO.
E Completion of entire Turnkey project W ithin 14(Fourteen) months
with installation, from the date of PO.
commissioning after
successful Acceptance
Testing, including migration of
HLR, IN, B&CCS and other
elements wherever required.

200
 SECTION-VII

BID FORM & PRICE SCH EDULE

TABLE-I A
(EQUIPM ENT & SOFTWARE in Phase I)
Figures in USD
S.No. Item Quantity Basic Taxes & Freight, Insurance Any Basic all Discounts Total
Description Unit Duties Forwarding, Other inclusive Price
(As per Price (Out side Packaging Charges Price {(9)-
Schedule of Mauritius) {(4)+(5)+(6) (10)}x
Requirement) +(7)+(8)} (3)
1 2 3 4 5 6 7 8 9 10 11

TABLE-I B
(EQUIPM ENT & SOFTWARE in Phase II)
Figures in USD
S.No. Item Quantity Basic Taxes & Freight, Insurance Any Basic all Discounts Total
Description Unit Duties Forwarding, Other inclusive Price
(As per Price (Out side Packaging Charges Price {(9)-
Schedule of Mauritius) {(4)+(5)+(6) (10)}x
Requirement) +(7)+(8)} (3)
1 2 3 4 5 6 7 8 9 10 11

Note: MTML may take a decision to go for upgradation to HSPA to all or only in some BTS
areas depending on requirement, even before Phase II order is placed. Thus for Table IB, the
price quoted should be on per BTS basis. For evaluation purposes, full cost for upgradation to
HSPA for whole network depending on total BTSs in phase II would be taken.

TABLE-II

(SERVICE CH ARGES)
Figures in USD
S.No. Item description Phase 1 Phase 2
1. Installation, Testing, & Commissioning

Note:
The vendor shall give break up of the Installation, Testing & Commissioning costs for
various systems & sub systems. This may facilitate the purchaser, at its sole discretion, to
consider payment to the Contractor for different services at different times as per
completion of the same.

201
 TABLE-III

COM PREHENSIVE ANNUAL M AINTENANCE CONTRACT (EQUIPM ENT &

SOFTWARE) FOR 3 YEARS AFTER WARRANTY PERIOD

S.No. Item Description Year wise AMC Charges

Year 1 Year 2 Year 3

Note:

Year wise AMC charges shall be quoted for different systems, subsystems & software so as
to cover whole system and it should be possible for the Purchaser to enter into part AMC also
at a later date.

TABLE-IV

LIST O F SPARES TO BE H ANDED O VER BY THE VENDOR TO THE PURCH SER

ON EXPIRY O F THREE YEARS AM C PERIOD AS PER AM C TERM S &
CONDITIONS

Figures in USD
S.No. Item Quantity Basic Taxes & Freight, Insurance Any Basic all Discounts Total
Description Unit Duties Forwarding, Other inclusive Price
Price (Out side Packaging Charges Price {(9)-
Mauritius) {(4)+(5)+(6) (10)}x
+(7)+(8)} (3)
1 2 3 4 5 6 7 8 9 10 11

202
 Annexure-I
Bid Security Form

RFP No. ………………. Dated ………

Ref No. :… ……… … Date :…… ..

To
Mahanagar Telephone (Mauritius) Limited
30, Dr Eugene Laurent Str, Port Louis
Mauritius.

W hereas [Name of Vendor] hereinafter called “The VENDOR” has submitted its
Offer dated [date of submission] for the project as per the above RFP in Republic
of Mauritius” hereinafter called “The Equipment”.

KNOW ALL PEOPLE that we [name of bank] of [name of country] having our
registered office at [Address of Bank] hereinafter called “The BANK” are bound
unto Mahanagar Telephone (Mauritius) Limited, hereinafter called “The MTML” by
the amount of US $ …… ….. (mention amount as per RFP) willingly and truly to
be paid out to the said MTML upon entering any of the conditions specified
below. The BANK, binds itself, its successors and assigns by these presents
sealed with the common seal of the said bank this … ……… …….. day of
………… ……… .. 200 .

The conditions of this obligation are:

a ) If the VENDOR withdraws its Offer during the period of Offer validity specified by
the VENDOR in its offer submitted to MTML;
or
b) If the VENDOR is selected for the second stage of the bidding process by the
MTML, and is notified accordingly during the period of Offer validity if selected for
award of contract fails to sign the contract within one month from the date of
acknowledgement of Letter of Intent (LoI) and furnish the Performance Security in
accordance Clause 28.2 of Section II and Clause 4 of Section III, General Condition of
Contract.

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

203
 Annexure-II
Performance Guarantee Form

RFP No. ……………………. Dated …………

Ref No. :… ……… … Date :…… ..

To
Mahanagar Telephone (Mauritius) Limited
30, Dr Eugene Laurent Str, Port Louis,
Mauritius.

W hereas [Name of Vendor] hereinafter called “The VENDOR” has agreed for the
executing the project as per the above RFP in Republic of Mauritius hereinafter
called “The Equipment”. as per the conditions of Letter of Intent (LoI) issued to
the VENDOR by Mahanagar Telephone (Mauritius) Limited, hereinafter called
“The MTML”

AND W HEREAS it has been stipulated by you in the said Letter of Intent that the
VENDOR shall furnish you with a bank guarantee by a reputed first class
commercial bank located in Mauritius specified therein as security for compliance
with the VENDOR’s performance obligations.

AND W HEREAS we have agreed to give the appointed VENDOR a guarantee:

THEREFORE, we hereby affirm that we are guarantors and responsible to you

on behalf of the VENDOR up to a total of US DOLLAR……… …… …… {Amount
of the Guarantee in W ords]. W e undertake to pay you, upon your first written
demand declaring the VENDOR to be in default of its obligations and without
cavil or argument, any sum or sums within the limits of [Amount of Guarantee] as
aforesaid, without your needing to provide or to show grounds or reasons for your
demand or the sum specified therein.

This guarantee is valid until the …… ……… …….. day of …… ……… ………. 200

Signature of Bank

Seal of Bank

204
 Annexure-III

LETTER OF AUTHORISATION FOR ATTENDING OPENING OF OFFERS

(to reach CEO M TM L 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.

205
 Annexure-IV
M ANUFACTURERS AUTHORISATION FORM
To
The Chief Executive Officer
Mahanagar Telephone (Mauritius) Ltd.
30, Dr Eugene Laurent Str, Port Louis
Mauritius.

Dear Sir,

RFP No. ……………………………….. Dated ……………………

W e _______________________________________ who are established and

reputed manufacturers of GSM/ HSPA equipment having factories at ___________
and _____________________ do offer, negotiate and conclude the contract with you
against RFP No. …… ……… Dated ……. for the above goods manufactured
by us.

No company or firm or individual other than M/s. __________________________ are

authorized to offer, negotiate and conclude the contract in regard to this business
against this specific RFP.

W e hereby extend our full guarantee and warranty as per clause 8 of the General
Terms & Conditions (Section-III of RFP) of the contract for the goods offered for
supply against this RFP by the above firm.

Yours faithfully,

(Full Name)

for and on behalf of M/s

(name of manufacturer)

Note: This letter of authority should be on the letter head of manufacturing

concern and should be signed by a person competent and having the power of
attorney to bind manufacturer

206
 Annexure-V

ANNUAL MAINTENANCE CONTRACT (AMC)

SCOPE OF CONTRACT

1. Annual Maintenance Contract shall start immediately after expiry of the

warranty period. The comprehensive Annual Maintenance Contract (Herein
after called AMC) shall be three years.

2. During the period of AMC the successful vendor ( herein after called contractor)
shall :

i) Diagnose the hardware and software faults

ii) Rectify the hardware/ software faults detected
iii) Repair / replace the faulty PCB and any other part etc. of the equipment.
i) Carry out the periodic preventive maintenance
ii) Upkeep, the software periodically
iii) Upgrade the software to latest version

3. The vendor shall provide service / maintenance to the purchaser in the

presence of user, at the locations where hardware and software product will be
installed. The vendor shall ensure the availability of service to all the
subscribers at all the time.

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

207
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 M EJEURE

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

208
 beyond three month. Both parties agree upon the equitable solution for
termination of these agreement or otherwise decide the course of action to be
adapted.

11. The successful vendor shall supply all global software updates issued by the
firm to MTML free of cost as part of the AMC as well the maintenance of these
upgrades.

11.1 The fees quoted for maintenance service of software shall be valid for the
software provided at the time of installation and commissioning of the system
and subsequent upgrades till the expiry of the AMC.

12. The successful vendor will be solely responsible for the maintenance and repair
of the software/ hardware systems, equipments and parts, thereof and MTML
shall not be liable to interact with any of the partners / collaborators or the sub
contractors of the contractor.

13. Termination Clause: If the purchaser is not satisfied with the performance of
the vendor during AMC he should be able to terminate the AMC during its
currency, after giving three months notice to the vendor and in such an event
will hand over all the spares as indicated in clause 6.

209