citycell cms rfp december 2009

In Confidence to Citycell and the Recipient

Content Management System (CMS): Introduction

Content Management System (CMS) Request for Proposal

Pacific Bangladesh Telecom Limited, December 2009



Section 1………………………………………………………………………………………………….6

1.1 Overview……………………………………………………………………………………………..7

1.2 Company Overview…………………………………………………………………………………7

1.3 Scope of Work………………………………………………………………….……………………7

1.3.1 Implementation Services… ..………………………………………..…………………7

1.3.2 Functionality.....……………………………………………………………..……………7

1.4 Documentation………………………………………………………………………………………8

1.4.1 RFP Documents…………….……………………………………………………….…...8

1.4.2 Responses…………………………………………………………………………………8

1.5 Operational Overview…..……….………………………………………………….………………8

1.5.1 User Locations……………………..……………………………….……………………8

1.5.1.1 Corporate Office………………………………………………..………………8

1.5.1.2 Regional Offices…………………………………………………..……………8

1.5.1.3 Customer Care Points………………………………………….……..………8

1.5.2 Citycell Network……………………………………………………….………………8

1.5.2.1 Network Technology and Vendor..………..………….………..…………8

1.5.2.2 Electronic Top-up…………………………….………………….……………9

1.5.3 Sizing……..………………………………………………………….……………………9

1.5.3.1 Subscriber Base..…………..………………………...………………………9

1.5.3.2 Users….……………………………………………………………….……….9

1.6 Definitions…………………………………………………………………………..………………9

Section 2…………………………………………………………………………….……………………12

2.1 Introduction ………………………………………………………………………………………13

2.2 Responses…………………………………………………………………………………………13

2.2.1 General……………………………………………………………………………..………13

2.2.1.1 Respondent Costs…………………………………………………………………13

2.2.1.2 Scope of Proposals……………………………………………………..…………13

2.2.1.3 Acceptance………………………………………………………….………………13

2.2.1.4 Format of Proposals………………………………………………………………13

2.2.1.5 Validity of Offer…………………………………………………….……………..13



2.3 Compliance…………………………………………………………………………..……………13

2.3.1 General…………………………………………………………………………..…………13

2.3.2 Modification to Software………………………………………………..………………13

2.3.3 Non-Conformances………………………………………………………………………13

2.3.4 Clarifications………………………………………………………………………………13

2.4 Variation of Proposal………..……………………………………………………………………14

2.4.1 Complete Proposal…………………………………………………………….…………14

2.4.2 Changes after Submission………………………………………………...……………14

2.4.3 Errors and Omissions……………………………………………………………………14

2.5 Administrative Proposal..………………….……………………………..……………………...14

2.5.1 Respondent’s Organization.……………………………………………………………14

2.5.2 Prime Contractor Details……………………………………………………..…………14

2.5.3 Sub-Contractor Details…………………………………………………………..………14

2.5.4 Prime Contractor and Sub-contractors…………………………………….…………15

2.5.5 Respondent Experience.…………………………………………………………………15

2.5.6 Quality Assurance...…………………..…………………………………………….……15

2.5.7 Present Commitments……………….……………………………………………..……15

2.5.8 Proposed Project Organisation…….………………………………………………..…15

2.5.9 Program of Work and Completion Date…….………………………...…..…………15

2.5.10 Implementation Methodology……………………………………………....…….…15

2.5.11 Work Breakdown………………………………………………………….……………..15

2.5.12 Respondent Location…………………………………………………...………………15

2.6 Financial Proposal ……………….…….………………………..……………………..…………16

2.6.1 General…………………………………………………..…………………………………16

2.6.2 Currency……………………………………………………………………………………16

2.6.3 Taxes……………………………………………………..…………………………………16

2.6.4 Validity………………………………………………………………………………………16

2.7 Technical Proposal…………….……….…………………………………………………………16

2.7.1 Compliance Sheets…………………………………………….…………………………16

2.7.2 Technical Details……………………………………………….………...………………16

2.7.3 Proposed Test Procedures………………………………………………………………16

2.8 Maintenance and Upgrading ……………………………………………………………………16

2.8.1 General………………………………………………………………….……………………16



2.9 Queries…………………………..……………………………………………..……………………16

2.9.1 Submission of Queries and Clarifications…………………………..…………………16

2.8.1 Response..………………………………………………………………...…………………16

2.10 Language………………………..………………………………..…………….…………………16

2.11 Submission of Proposals……………………………………………………….………………17

2.12 Closing Date……………………………………………………………………….……………17

2.13 Evaluation and Acceptance of Proposals…………………………………….……………17

2.13.1 Evaluation and Basis of Acceptance………………………..…………….…………17

2.13.1.1 Evaluation Committee…………………...……………………………..………17

2.13.1.2 Clarifications…………………………………………………..…………………17

2.13.1.3 Award………………………………………………………………………………17

2.13.1.4 Right to Reject…………………………………………………...………………17

2.13.1.5 Acceptance…………………………………………………………..……………17

2.14 Other Conditions……………………………………….…………………………...…………17

2.14.1 Confidentiality………………………………….……………………….………………18

Section 3…………………………………………………………………………………………………19

3.1 System Administrator……………….……………………………….…………………………20

3.2 System and Access Channel Integration……………………………………………………20

3.3 System Engines………………………..…………………………………………………………21

3.4 Alert and Notification…………………...………………………………………………………21

3.5 Content Management …………………….……………….……………………………………21

3.6 Supporting Types of Files …………………..…………………………………………………21

3.7 Help Module………………………………………………………………………………………22

3.8 Content Charging……………………………………………………..…………………………22

3.9 Reporting …………………………………………...……………………………………….……22

3.9.1 Generation of Reports……………………...………………………………………22

3.9.2 Report Templates……………………………………………………………………22

3.9.3 Revenue and Other Reports…………………….…………………………………22

3.10 Data Warehouse………………………………………..………………………………………23



Section 4…………………………………………………….…..………………………………………24

4.1 Power Requirements…………………..……………….…………………………………………25

4.2 System Physical Specification………..……………….…………………………………………25

4.3 Time Synchronization and DST Capability..……….…………………………………………25

4.4 Tracing Management..………………………..……………………………………….…………25

4.4.1 Interface message tracing..…………………..…….……………….…..………………25

4.4.2 Subscriber interface tracing………………...……………………….……..……………25

4.4.3 Message explanation..………………………………………..………….…….…………25

4.4.4 Online and offline tracing review……..……….……………………….….…..………25

4.5 Performance Management…………………………..…………………………….…….………25

4.6 System Security……………………………..………….………………………….…...…………25

4.7 Secure Socket Layer………………………..…………..…………………...……………………25

4.8 Secure File Transfer Protocol……………...…………..………………………….....…………25

4.9 Three (03) Tier Architecture to Upload Contents ……………………………….....………25

4.10 N Tier Architecture for Database Security………………..………………...………………26

4.11 System Compatibility …………………………………………………………..………………26

4.12 Remote Access ……………………………………………….……..…………..………………26

4.13 Support Unicode………………………………………………………..……….…...…………26

4.14 Language ………………………………………………………………….……….……..………26

4.15 Disaster Recovery…………………………………………………………...……..……………26

4.16 Monitoring and System Audit………………………………..…………...……..……………26

4.17 Billing Requirements………………………………………..……………………..……………26

4.18 Service Control Gateway…………………………….……..……..………………..………….27

Section 5………………………………………………………………………………………………….28 Appendix ……..………………………………………………….………………………………………28




Section 1: Introduction

Notice This documentation is provided in strict confidence. No part of this documentation may be copied,

distributed or transmitted by any means whatsoever, or disclosed to third parties, without the express written permission of the Chief Executive Officer, Pacific Bangladesh Telecom Limited.



1.1 Overview These documents describe the requirements for a content management system (CMS) to be deployed by Pacific Bangladesh Telecom Limited (Citycell). The requirements cover a number of core (mandatory) features, as well as optional features that are subject to feasibility and cost-effectiveness. This system shall be a central repository to host, deliver, and charge contents. Citycell seeks Proposals from suitably qualified and experienced Vendors who can offer a proven, scalable and cost-effective solution.

1.2 Company Overview Pacific Bangladesh Telecom Limited, trading as Citycell, is a public limited company incorporated under the laws of the Bangladesh. Citycell operates on a national network based on CDMA 2000-1x / EV-DO standards, and offers a full array of mobile Services for consumers and businesses that are focused on the unique needs of the Bangladeshi community. Citycell is a customer-driven organisation whose mission is to deliver advanced telecommunication Services to Bangladesh. Its growth strategy is to integrate superior customer Service, highest standard technology and choice of packages at affordable rates. In particular, Citycell will focus on the introduction of new, high-speed data Services. Citycell is seeking to support its strategy by implementing content management system (CMS). To fulfil this requirement, Citycell is seeking a suitable solution which is robust, scalable, readily deployable with minimum customisation, and offers the flexibility to meet both current and emerging business needs.

1.3 Scope of Work Citycell requires that this project will be a Primary Contractor Undertaking. The Respondent must show that they have the demonstrated capability to manage the entire project on a revenue share basis, with all project management, works and equipment necessary to provide an operational system ready for commercial Service. Vendor should also provide cost of upfront purchase, and other pricing options.

1.3.1 Implementation Services This will include:

• Project management. • Solution design. • Hardware and Software procurement and installation. • Software configuration and customisation. • Testing. • Training. • Post-implementation support and services.

1.3.2 Functionality The requirements are contained in Section 3 and 4, and have been broken down into a number of logical functional groupings, which consist of a combination of mandatory and optional functions. These groupings are for convenience of presentation only, and Citycell welcomes any proposal that meets the core objectives described within them.

The requirements comprise the following areas:

• Business Requirements • Technical Requirements



1.4 Documentation

1.4.1 RFP Documents The documentation, of which this introductory section forms part, is composed of the following sections:

• Section 1: Introduction • Section 2: General Conditions • Section 3: Business Requirements • Section 4: Technical Requirements • Section 5: Appendix

1.4.2 Responses All responses should be completed using the Compliance Sheet supplied separately

(attached as Appendix in Section 5).

Respondents should provide full details of the capabilities of their system against the compliance list, and in addition are welcome to provide further details of any features; functions or capabilities that their system may possess that are not referenced in these documents.

1.5 Operational Overview An overview of Citycell’s operations is valuable in understanding these requirements and also in proposing an optimum solution.

1.5.1 User Locations

1.5.1.1 Corporate Office The major users of the system are situated in various locations around Bangladesh, with the bulk being located in or around the corporate office at 14 Mohakhali C/A, Dhaka. The major corporate functions will be performed from these areas, such as:

• Bill generation • System administration • System maintenance • CDR collection • Marketing • Finance

1.5.1.2 Regional Offices Citycell has a number of regional offices that provide a full range of customer service functions, as well as limited administrative functions. These locations all have dedicated connectivity to the corporate office via Citycell’s Data Communication Network and are located at:

• Chittagong • Sylhet • Rajshahi • Khulna

1.5.1.3 Customer Care Points Citycell has over 500 Customer Care Points located throughout the country, often in remote areas, which provide a localised, one-stop customer support role. Access to the current systems is via Citycell’s Zoom Mobile Internet solution.

1.5.2 Citycell Network The following is selected information that may assist respondents in properly understanding the requirements and offering a suitable solution.

1.5.2.1 Network Technology and Vendor



Citycell operates a CDMA 2000/1X network on the 800MHz frequency. EV-DO capabilities are being progressively rolled out into the network. Citycell’s major network supplier is Huawei Technologies, who also manages the network on its behalf under a Managed Services Agreement. Unless otherwise stated it may be assumed that all network elements referred to in these documents are supplied by Huawei, although other vendors may be introduced into the network in future.

1.5.2.2 Electronic Top-up Citycell uses an eTop-up solution provided by Utiba. The eTop-up servers are all located in Dhaka.

1.5.3 Sizing The following data are provided as guidance for the sizing and on-going growth of the system, and will be subject to further refinement should the Response be considered for implementation.

1.5.3.1 Subscriber Base Assumed active subscriber base at time of implementation is 2.25 million. Out of this sub-base, they CMS system should support approximately 1 Million customers. We expect the target sub-base to be supported by CMS to have a 100% growth in the initial years. Future growth pattern will be projected 1 (one) year after the commercial launch of the system.

1.5.3.2 Users Assumed number of concurrent users is at least 1000 (one thousand).

1.6 Definitions The following terms, abbreviations and acronyms are used in these documents: AAA Authentication, Authorisation and Accounting server for data users.

Account A point in the Customer Hierarchy at which charges are aggregated and bills are produced. A single Account can contain many Services and can contain one or more Aggregation Points.

Administrator Full option enabled application user.

Aggregation Point

A point at which charge information is aggregated for purposes other than billing, for example to provide reports to customers on the total spending across multiple Accounts.

AR Accounts Receivable. ARPU Average Revenue Per User. BDT Bangladesh Taka, commonly abbreviated as Tk.

Bill A formal document requesting payment. Bills create Accounts Receivable records.

BREW Binary Runtime Environment for Wireless. BREW ADS Binary Runtime Environment for Wireless Application Delivery System. BTRC Bangladesh Telecommunications Regulatory Commission.

CAPTCHA A program that can generate and grade tests that humans can pass but current computer programs cannot.

CCC Customer Care Centre, a fully functional sales and customer Service centre comprising multiple staff.

CCP Customer Care Point, a small customer Service touch-point, often located in a remote area.

CDR Call Detail Record(s). Any charge record generated by Citycell’s network or other external sources.

Citycell Trading name of Pacific Bangladesh Telecom Limited. Pacific Bangladesh



Telecom Limited is referred to as “Citycell” throughout these documents.

Contact(s) Any interaction between Citycell and a customer, including complaints, enquiries, requests for service or general feedback.

Content life cycle Management Tool

This tool is for content all over management (e.g. creation, publishing, modifying, removing and so on.)

Content Management System (CMS)

A central repository platform to host, deliver and charge contents through different access channels.

Content Provider The vendor who will provide contents.

CRBT Customised Ring Back Tones Server.

Credit Credit values in this document refer to values that decrease a customer’s liability, such as payments.

Customer A point in the Customer Hierarchy representing a legal entity that has contracted with Citycell for the provision of products and Services. A single customer can be responsible for many Accounts.

Customer Hierarchy

A structure that provides a logical representation of the Accounts, Aggregation Points, Services, etc belonging to a Customer.

Debit Debit values in this document refer to values that increase a customer’s liability, such as usage charges.

Deposit(s) A sum of money paid by a customer and held by Citycell as security against future bad debt.

DST (Day light savings)

A way of getting more light out of the day by advancing clocks by one hour during the summer. Summertime as it is called in many countries.

Firefox Web browser. FTP File transfer protocol. GL General Ledger System. GMSC Gateway Mobile Switching Centre(s).

Hot Standby A method of redundancy in which the primary and secondary (i.e., backup) systems run simultaneously. The data is mirrored to the secondary server in real time so that both systems contain identical information.

HLR Home Location Register.

IMSI International Mobile Subscriber Identification Number(s), a unique number contained in the customer’s SIM/RUIM card.

IN Intelligent Network. Internet Explorer Web browser.

IN-SCP Intelligent Network Service Control Point, used for the management of prepaid subscriber balances.

International Payment Gateway

A payment gateway provides a secure connection between operator and Internet merchant account.

IN-VMS Intelligent Network Voucher Management System, used for the creation and management of scratch card details.

IVR Interactive Voice Server. LMT (Local Maintenance Terminal)

Operation and Maintenance client for any system.

MDN Mobile Directory Number; the Service Number identifying a mobile customer. MSC Mobile Switching Centre(s).



NE Network Element(s). For the purpose of this RFP, any component of Citycell’s network with which the system is expected to interface or interact with.

NOC Network Operation Centre.

NRC Non-Recurring Charge(s), a one-time charge other than a usage charge generated by a CDR.

Package A group of products that are offered to customers as a single logical offering. Packages may be charged for at a different rate than the sum of the component products.

PDSN Packet Data Serving Node.

PLMN-ID Public Land Mobile Network Identification. A code used to uniquely identify the host network in a CDR.

Product

A component of a Service that is subscribed by a customer, representing a network facility offered (such as SMS) or a billing-only facility (such as itemised call statements). Products may be offered as part of a Package, or on a stand-alone basis. Some products may be mandatory (such as the basic mobile subscription) or optional (such as value-added Services).

RC Recurring Charge(s), such as a monthly subscription fee. Respondent A person or corporation submitting a Proposal in response to this RFP RFP Request for Proposal.

RUIM Removable User Identity Module, essentially the CDMA equivalent of a GSM SIM.

SAARC South Asian Association for Regional Cooperation. A grouping of South Asian countries, including Bangladesh, India, Pakistan, Sri Lanka and others.

SCP Service Control Point, a component sub-system of the IN.

Service Defines a customer subscription, for example a mobile Service Number. A single Service can subscribe to multiple products.

SFTP Secured file transfer protocol. SMP Service Management Point. SMSC Short Message Service Centre. SSL Secured socket layer.

Statement A document providing an indication of charges on an Account at a point in time, or providing details of charges already included in a Bill. Statements are not a formal request for payment and do not result in Accounts Receivable records.

Transcoding

The processes of converting a media file or object from one format to another. Transcoding is often used to convert video formats (i.e., Beta to VHS, VHS to QuickTime, QuickTime to MPEG). It is also used to fit HTML files and graphics files to the unique constraints of mobile devices and other Web-enabled products. These devices usually have smaller screen sizes, lower memory, and slower bandwidth rates. In this scenario, transcoding is performed by a transcoding proxy server or device, which receives the requested document or file and uses a specified annotation to adapt it to the client.

TCP/IP Transmission Control Protocol/Internet Protocol is the basic communication language or protocol of the Internet.

Telnet Protocol

A user command and an underlying TCP/IP protocol for accessing remote computers.

Unicode A computing industry standard allowing computers to represent and manipulate text expressed in most of the world's writing systems consistently.

USD United States Dollars. User The system user who will have access to the CMS application. VMSC Visited Mobile Switching Centre. VPN Virtual private network. WAP-GW Wireless Application Protocol Gateway. Work The full scope of work as described in these documents.


Content Management System (CMS): General Conditions Page 1


Section 2: General Conditions





2.1 Introduction The attention of Respondents is directed to these General Conditions governing the terms of this RFP, which will form the basis of any eventual contract for the Work awarded.

2.2 Responses

2.2.1 General

2.2.1.1 Respondent Costs Costs of preparation of responses to this RFP are the sole responsibility of the Respondent. Citycell will have no obligation to pay or reimburse any costs whatsoever incurred by the respondent.

2.2.1.2 Scope of Proposals The Proposal shall include the design, supply, delivery, construction, permits, installation, integration and testing of the Work in accordance with these conditions. Warranty and security measure would be considered therein. In addition, the entire solution shall be based on the standard of ITU/ISO/IETF/IEEE.

2.2.1.3 Acceptance Citycell is not bound to accept the lowest or any proposal. No correspondence will be entered into with unsuccessful vendors.

2.2.1.4 Format of Proposals Proposals shall be presented in three separate documents as follows. The content of each document is described further under the relevant sections in this RFP.

• Document 1: Administrative Proposal • Document 2: Financial Proposal • Document 3: Technical Proposal

2.2.1.5 Validity of Offer The Respondent’s offer shall remain valid and be capable of acceptance by Citycell for a period of one hundred and eighty (180) calendar days from the closing date for submissions under this RFP.

2.3 Compliance

2.3.1 General The Work offered in this RFP shall comply with Citycell’s Conditions of RFP, Specification and Annexes. Respondents shall complete the Compliance Sheet and describe the techniques to be used to comply with Citycell’s requirements.

2.3.2 Modification to Software

Should the Respondent’s standard system need to be modified to comply with the Specification, the Respondent shall describe how the modification/s shall be made. Provision for further modification would be included therein.

2.3.3 Non-Conformances

In the event that the Respondent cannot conform to the Conditions of RFP, Conditions of Contract, Requirements or Annexes, the Respondent shall describe the limitations that prevent compliance.

2.3.4 Clarifications

It is anticipated that some matters of detail may need to be clarified following the examination of Proposals; as such, Citycell reserves the right to request any written clarification or additional information whenever required.



2.4 Variation of Proposal

2.4.1 Complete Proposal The Respondent is advised to study this RFP carefully and to make all necessary clarifications before submission of their Proposal. The onus is on the Respondent to ensure that a completed and detailed Proposal is submitted.

2.4.2 Changes after Submission The Respondent may not change or modify his Proposal subsequent to its submission without the written consent of Citycell.

2.4.3 Errors and Omissions Citycell is not bound to accept any request made after the RFP is closed for variation or submission of additional quotes for items left out in the original Proposal on any grounds whatsoever. The Respondent shall be solely responsible for all such omissions or errors and the consequences arising.

2.5 Administrative Proposal

2.5.1 Respondent’s Organisation The Respondent shall provide a description of the organisation proposed to execute the Work. This description shall include, but not be limited to, identification of:

• The legal prime contractor. • All sub-contractors. • Teaming arrangements between prime and sub contractors. • Roles of the involved parties.

2.5.2 Prime Contractor Details The Respondent shall provide a detailed description of the Prime Contractor including, but not limited to:

• Full legal company name. • Place and date of incorporation. • Major shareholders and/or controlling interest. • Major areas of business activity. • Number of employees: Corporate, South Asia, Bangladesh. • Address of Head Office, with contact details for contact person related to this

RFP. • Address of office responsible for this RFP, with contact details for person

responsible for this RFP. • Address of Bangladesh office, with contact details for person responsible for

this RFP. • Description of support organisation in Bangladesh and South Asia.

If the supplier of the application software is different to the Prime Contractor, the same details listed above shall be provided for the sub-contractor responsible for providing the application software.

2.5.3 Sub-Contractor Details For each main Sub-Contractor the following information shall be provided:

• Full legal company name. • Place and date of incorporation. • Address of Head Office and Bangladesh Office, with contact details for contact

person related to this RFP. • Description of current Bangladesh organisation. • Major areas of business activity. • Number of employees: Corporate, South Asia, Bangladesh.



2.5.4 Prime Contractor and Sub-contractors The total responsibility for the Work shall be borne by the Prime Contractor. The Prime Contractor may not assign his responsibilities under this contract either in whole or in part to Sub-Contractors or any other parties. Citycell reserves the right to terminate the Contract in whole or in part if the Prime Contractor submits any fraudulent information or performs any fraudulent activity.

2.5.5 Respondent Experience Respondents shall have experience in planning, design, engineering, developing, supply, installation and maintenance of identical or similar Work, and shall supply a list of client references, including the following information:

• Client name and location. • Nature of client’s business, Example mobile (specify if GSM / CDMA, etc), fixed

line, etc. • Contract start and completion dates. • System solution (hardware, software and network solution, including software

name and version number). • Number of customers / Services and users supported. • Client contact details. • Length of experience (where applicable).

2.5.6 Quality Assurance The Respondents shall describe their Quality Assurance (QA) system, which will include project management, software development, system installation, training, documentation, and maintenance and support.

2.5.7 Present Commitments The Respondent should submit a summary tabulation of present and anticipated commitments to be undertaken during the likely period of the Work. The type of project, summary schedule and value of the Respondent’s participation should be included.

2.5.8 Proposed Project Organisation The Respondent should provide details of the organisation structure proposed to perform the Work. This should include profiles of key personnel proposed, as well as details of expected Citycell support and involvement, in particular headcount numbers and skill sets required.

2.5.9 Program of Work and Completion Date Respondents shall provide a detailed program of system implementation. This program should clearly establish milestones for key deliverables (especially Acceptance Tests) and a firm timetable for achievement of these milestones beginning from the contract signing date.

2.5.10 Implementation Methodology The Respondent shall submit his proposed methodology for the scheduling, design, delivery, installation, testing, interconnection and commissioning of the system, including training of Citycell personnel, which will enable the Respondent to ensure that the Work will be completed by the due dates.

2.5.11 Work Breakdown The Respondent will demonstrate in his Proposal how he will develop the following aspects of the work program:

• Identification and relationship of activities and events. • Responsibility Assignment Matrix and an Organisational Breakdown Structure. • Time estimate for each activity. • Schedule of dates for each milestone. • Integration of all hardware and software.

2.5.12 Respondent Location It is preferred that Respondents have a local presence in Bangladesh, either directly or through a local partner, and are able to accept payment in local currency.



2.6 Financial Proposal

2.6.1 General Citycell requires that the vendor will supply a CMS solution on a revenue sharing basis. Revenue sharing may be based on a combination of a percentage share of revenue generated, as well as the number of successful transactions.

2.6.2 Currency Citycell will pay all payments to the vendor only in Bangladeshi Taka (BDT) to a local account via agreeable banking instrument except cash.

2.6.3 Taxes Citycell shall deduct all applicable Taxes and other payable amounts as per Bangladesh Government’s regulation and provide all related vouchers/documents to the vendor.

2.6.4 Validity The price quoted in this Proposal shall remain valid and be capable of acceptance by Citycell for a period of one hundred and eighty calendar (180) days from the closing date for submissions under this RFP. The price agreed in the final contract will remain valid until the issue of the Final Acceptance Certificate.

2.7 Technical Proposal

2.7.1 Compliance Sheets The Respondent will submit a Statement of Compliance in the format contained in Section 5 (as Appendix).

2.7.2 Technical Details The Respondent shall submit complete and unambiguous details of the proposed design, assembly, installation, and training in connection with the provision of the Work. The Respondent is at liberty to present, organise and arrange his proposals in the manner he deems best, however the proposals should be stated with sufficient detail as to allow Citycell to assess the adequacy and suitability of the proposed design.

2.7.3 Proposed Test Procedures The Respondent shall submit detailed proposals for testing procedures to be performed prior to final acceptance that demonstrate that the Work meets the Specification.

2.8 Maintenance and Upgrading

2.8.1 General The respondent must take care of all maintenance and upgrading activities related to the CMS system as and when required. Citycell shall not bear any cost for this.

2.9 Queries

2.9.1 Submission of Queries and Clarifications Any query that may arise with regard to the clarification or interpretation of these specifications is to be sent to Mr. Masrur-ul Huq by e-mail not less than seven (07) business days (December 15 2009) prior to the closing date. The e-mail address is [email protected].

2.9.2 Response All questions and answers will be transmitted simultaneously to all who have been invited to respond, with no indication as to the source of the enquiry.

2.10 Language All documentation, Proposals and communication relating to this RFP between the parties shall be in the English language.



2.11 Submission of Proposals The Proposal shall be placed in a sealed envelope and delivered to: Masrur-ul Huq Business Development and Strategic Initiatives Pacific Bangladesh Telecom Limited Level 05 14 Mohakhali C/A Dhaka 1212 BANGLADESH The Respondent should provide Proposals in secured PDF format. In addition, Pricing should be provided in both secure PDF and Excel formats. Proposals received after the RFP closing date and time are invalid and will not be accepted.

2.12 Closing Date Responses must be lodged no later than 6:00PM (Bangladesh Time) on Thursday, December 24 2009.

2.13 Evaluation and Acceptance of Proposals

2.13.1 Evaluation and Basis of Acceptance

2.13.1.1 Evaluation Committee Citycell will establish an evaluation committee responsible for evaluating all technical, functional and commercial aspects of the Proposals against these Requirements.

2.13.1.2 Clarifications Citycell reserves the right to submit questions or clarifications to Respondents to assist in the evaluation of Proposals.

2.13.1.3 Award The Work will normally, but not necessarily, be awarded to the Respondent demonstrating the highest level of compliance to these specifications at the lowest price.

2.13.1.4 Right to Reject Citycell reserves the right, at its absolute discretion and without stating any reason whatsoever, to reject any or all Proposals, without any cost to Citycell. Citycell will not be bound to accept any, or the lowest price, of any Proposal.

2.13.1.5 Acceptance No Proposal shall be deemed to be accepted until such time as a Letter of Intent has been issued, or a contract signed with, the successful Respondent.

2.14 Other Conditions

2.14.1 Canvassing, Gifts, Commission Prospective Respondents or their agents must not canvass, offer, give or agree to give any person employed by Citycell any gift, commission, or consideration of any kind as an inducement or reward for doing, influencing, or carrying out any act in relation to the obtaining or execution of this Work.

Breach of this clause will render the Proposal invalid and / or enable any contract to be rescinded.



2.14.2 Confidentiality Except to the extent required by law, neither Citycell nor Respondents may communicate, use or disclose any confidential information or permit the communication or use of any Confidential Information to or by any person other than its own shareholders, lenders, management, or personnel who need to know or use such information for the purposes of this RFP.

Confidential information means all technical and commercial information in whatever form that is received by Citycell or the Respondent as a result of, or in connection with, this RFP and which is not in the public domain. All information marked as “Confidential” or “In Confidence” by Citycell or a Respondent shall be treated for all purposes as confidential information under this clause. The provisions of this clause shall survive for a period of five (05) years from the closing date of this RFP.


Content Management System (CMS): Business Requirements Page 1


Section 3: Business Requirements





3.1 System Administrator Provide a System Administrator function for the creation, modification and termination of User-IDs. No other user may perform this function.

3.1.1 Allow for the definition of a unique User-ID for each authorised user. Once assigned, User-IDs cannot be reused.

3.1.2 Allow for definition of standard user profiles. User profiles will control the following: • The information that each user is authorised to access. • The functions that they can perform. • Whether they have the ability to read, modify, delete or view data.

3.1.3 Support definition of standard user profiles (templates) based on two dimensions - the job role and the level of the user.

3.1.4 Passwords for user login shall be encrypted, alphanumeric, and a length of at least 8 characters enforced. The following characteristics shall be definable by the System Administrator:

• Validity period for passwords. • Password repetition frequency. • Unsuccessful login attempts before locking User-ID.

3.1.5 For unsuccessful login and user account lock, provide notification through pop up. 3.1.6 Allow System Administrator to define a period of time, within which if the user

account is unused the account shall be locked. 3.1.7 Prevent the use of “copy and paste” functions for all User-ID and passwords.

3.2 System and Access Channel Integration

3.2.1 Integration of post paid billing system and prepaid billing system (IN) to charge and exchange balance information.

3.2.2 Integration of BREW Platform with the Content Management System. CMS must have the capability to receive content request and deliver contents to BREW ADS server/ BREW Portal.

3.2.3 Integration with Access Channels - Web Portal, WAP, SMS push pull and so on. 3.2.4 Ability to integrate with a central IVR (future integration). For interim solution, CMS

should have a built in IVR, or bundled with an IVR. 3.2.5 System should have the provision to integrate with a central data ware house

(future integration). 3.2.6 Open Application Programming Interface (API) to integrate with third-party

content-stores, applications, and services. These services shall be available to all or defined access channels.



3.3 System Engines System shall have a list of engines to perform the following:

3.3.1 A search engine to facilitate optimized and user friendly search option for both customers and users. The engine shall also be able to find files/contents by type, category (music, application) etc.

3.3.2 A transcoding engine to modify content (picture, audio, etc) size based on request from destination device. (Example if a high resolution picture is requested from a low resolution handset, the system shall be able to modify the picture as per handset specification).

3.3.3 An Intelligent Advertising Engine shall be available for advertisement based on content download and access pattern. Example: Different advertisements will be displayed on users Web Portal pages based on content access/download patterns

3.3.4 An engine to profile customers based on usage pattern, package, MDN group, tenure, ARPU and any other configurable logic. There shall also be a provisioning to profile off net Web portal customers. The engine shall perform the following: 3.3.4.1 Create dynamic categories like 'Top', 'New', 'Recommendation'. Example: top

charts based on content browse, download history. 3.3.4.2 Create event based promotion of contents for campaign management.

Example: offer promotional price through push message alert to select group of customers.

3.3.4.3 Suggest similar type of content after successful purchase of a particular type of content via SMS or E-mail.

3.3.4.4 Setup and run various loyalty schemes. Example: loyalty points for high ARPU customers to download free contents.

3.4 Alert and Notification

3.4.1 Auto Alert notification shall to be sent on monthly, weekly, or daily basis with subscription, or content expiry notification based on a configurable preset logic.

3.4.2 CMS shall have the capability to generate and send confirmation of successful and unsuccessful delivery of contents through all the access channels (example: IVR, WAP, SMS, etc). The notifications shall be sent through SMS, IVR and e-mail.

3.5 Content Management

3.5.1 Provisioning for a web based GUI for content provider to register, upload and download contents. CP shall require a secured login mechanism; Example CAPTCHAs or reCAPTCHA to prevent abuse and ensure security.

3.5.2 Provision for an interactive interface with step by step upload process (Example: step1: agree to terms and condition, step2: provide content information, and so on).

3.5.3 Provisioning of automatic blocking of content upload if insufficient content information is provided by content providers.

3.5.4 Provisioning for Meta Data file (content information file) for filtering objectionable contents. This shall also be used for optimizing performance of the search engine.

3.5.5 Provisioning for Digital Right Management (DRM) to provide authentic digital content to customers, upon request.

3.5.6 Provisioning for content life cycle management tool to manage activities such as version control, archiving, rollback of contents.

3.5.7 Provision to support dynamic publishing and instant update of contents via any access channel (SMS, IVR, Brew, WEB, WAP, etc.). Example: breaking news alert can be uploaded to CMS through any access channels.

3.6 Supporting Types of Files CMS shall support the types of files for all access channels described below:

3.6.1 Audio streaming files for IVR. 3.6.2 Wallpaper, screensavers, themes, video, applications, games, monophonic ring

tones, polyphonic ring tones, true tunes, audio, video streaming file or any other related content types for BREW and WAP.

3.6.3 Known file types (e.g .mp3, .wav, .doc, .txt, etc) and applications for Web portal. 3.6.4 Text for SMS.



3.7 Help Module There should be a provision of help, tips for every module for the system users and content provider. 3.8 Content Charging

3.8.1 Provisioning for time, duration, volume, session, and content based charging. Charging parameters shall be flexible.

3.8.2 Capability for MT based (Message Termination) charging. This means CMS shall charge only after receiving confirmation on successful content delivery from access channel.

3.8.3 Capability for dynamic charging of contents. CMS shall have the provision for different amount of charging for various categories of contents. (Example: different rates for news, jokes and horoscope. Or, different rates for news headlines and details).

3.8.4 Provision for both flat and multi-level charging for menu, content access. Example: in IVR :

• Flat charging for accessing menu. • Multilevel charging for accessing different levels of the menu.

3.8.5 Capacity to charge registration fee for various services through any access channel (SMS, IVR, BREW, WEB, WAP).

3.8.6 Provision to bundle contents at discounted rates, offer time based discounts (happy hour, off peak hour) for specific user groups, based on MDN, specific list, range, package, usage pattern, etc.

3.8.7 Suggest contents that are affordable based on account balance or credit limit. (Example: if the customer has tk 20 in his balance and requests for content worth tk 50, then system should be able to suggest contents worth tk 20 or less).

3.8.8 Provision to charge external contents from remote sites that are not hosted in the CMS.

3.9 Reporting

3.9.1 Generation of Reports Support the generation of reports as follows:

3.9.1.1 Batch: Reports are run at predefined times and are available for collection by or transmission to users.

3.9.1.2 On-request: Reports can be generated upon user request. Such reports may involve the use of input information, such as date ranges etc.

3.9.1.3 Event: Reports will be automatically generated when certain events occur. 3.9.2 Report Templates

Provide tools for the easy and rapid definition of report templates and the modification of existing templates.

3.9.3 Revenue and Other Reports 3.9.3.1 All reports shall be access channel specific. 3.9.3.2 Revenue reports on successful content download, subscription and other

revenue generating activities shall be available. 3.9.3.3 Reports on content download history shall be available. 3.9.3.4 Query based (Example 300 tk to 500 tk) ARPU report by MDN, plan etc

should be generated. 3.9.3.5 Reports shall be generated with the following sample fields for revenue

assurance and operations activities. The fields shall be configurable. A list of sample fields can be found below:

• Date range • Channel type • CP name • Content name • Service number • CP code • Channel type (IVR/SMS push-pull/Brew/WAP/Web) • Content type • Content code • CP name • Uploaded date/time



• Published date/time • Expiry date/time • Target Service number • Status (success/failure) • VAT • Total charge • Citycell revenue portion as per percentage • CP revenue portion as per percentage • CP address • CP agreement date/time • CP revenue sharing mode (percentage/periodic)

3.9.3.6 Revenue report for BREW contents with the following sample fields: • MDN • Timestamp • Event type • ISV name • Developer price • Price method • Retail price

3.9.3.7 Revenue reports shall be generated for CPs for their own contents. 3.9.3.8 Status report of contents (upload, download, published, unpublished) shall

be generated for CPs. 3.10 Data Warehouse A data warehouse should be available to capture all transactions and activities for research and analysis. Customized query based reports should be available on request.


Content Management System (CMS): Technical Requirements Page 1


Section 4: Technical Requirements

Notice This documentation is provided in strict confidence. No part of this documentation may be copied, distributed or transmitted by any means whatsoever, or disclosed to third parties, without the express written permission of the Chief Executive Officer, Pacific Bangladesh Telecom Limited.



4.1 Power Requirements System supplier shall clearly specify the power requirements and specifications of the system in order to maintain suitable and optimum power infrastructure. The secondary power supply is required in active/standby backup to ensure the reliability of the system. 4.2 System Physical Specification System supplier shall provide dimension (H x W x L), weight and photograph of the each equipment. The provided equipment rack should comply with the industry standards as per se. The Vendor should also submit complete and comprehensive network diagram/equipment layout plan. 4.3 Time Synchronization and DST Capability The system should have the ability to synchronize with Operator’s Time Server. It should also have the capability to customize DST (Daylight Saving Time). 4.4 Tracing Management The system should provide graphical interface for tracing management. Tracing management helps to verify data and remove faults (if any). The tracing management includes:

4.4.1 Interface message tracing: Traces the messages on IN-interface, SMSC interface, WAP interface, WEB interface and BREW interface.

4.4.2 Subscriber interface tracing: Traces the messages of a subscriber on specified interfaces.

4.4.3 Message explanation: Provides detailed explanation of traced messages. 4.4.4 Online and offline tracing review: Exports tracing results to the LMT (Local

Maintenance Terminal) so that it can be review the results online (by logging in to the LMT) or offline.

4.5 Performance Management System should have provisioning for performance management to provide rich performance information, such as traffic flow, interface utilization, TPS (Transaction per second) in various directions and quality of service. This information is useful for equipment management, network performance optimization, and so on. It also should be able to generate System/Hardware health status report on a real-time basis and as per the requirement.

4.5.1 Performance Specifications: Vendor should provide a system to support 15 TPS (Transaction per second) and it should be scalable as the traffic increases.

4.5.2 On-Site Support: Vendor has to provide on-site administrative support for management and maintenance of the system for the entire service life of the solution.

4.6 System Security 4.6.1 System Security: CMS system must have Antivirus, Antispyware, proactive threat

and network threat protection. 4.6.2 Network Security: CMS shall be protected from the threats from internet by firewall

policies. 4.6.3 Application Security: To ensure secure communication through web services the

following shall be included in the system:

4.7 Secure Socket Layer Open SSL for secure authentication, individual security certificate shall be issued for each content provider. 4.8 Secure File Transfer Protocol SFTP for secure content upload by the content provider. 4.9 Three (03) Tier Architecture to Upload Contents A 3-tier architecture shall be used to ensure secure content uploading.

• Tier – 1: Access. • Tier – 2: Content filter and policy matching. • Tier – 3: Transfer to permanent storage.



4.10 N Tier Architecture for Database Security The application shall follow N-tier architecture to secure the access to database. Also include Caching feature to eliminate timely database queries. 4.11 System Compatibility The system shall be platform independent, browser independent and compatible with at least Internet Explorer and Firefox. 4.12 Remote Access The system must use VPN (Virtual Private Network) for remote access of system administrator. 4.13 Support Unicode The system shall make provision to support Unicode. 4.14 Language CMS shall have the provision to choose Bengali and English language. 4.15 Disaster Recovery There should be a replica of the system in another location (physical) for hot standby (Disaster recovery).

4.16 Monitoring and System Audit 4.16.1 System shall have a provision of alarm management to detect and report the

faults or anomalies of hardware and system on a real-time basis. When a fault occurs, the alarm box will give out audible and visual alarms to NOC of the operator. The LMT client at NOC shall also have a display of relevant alarm information considering three basic alarm types with different color and troubleshooting suggestions. The category of severity and notification recipient is illustrated in the following table

Severity Notification Recipients Critical System Owner and Central

Alarm Major System Owner and Central

Alarm Minor System Owner

4.16.2 Alarm management system shall also have provisioning of alarm notification

through: • SMS • E-mail • Audio Visual (Beep/Voice, Popup, Blinking Light based on severity)

4.16.3 Provisioning for a tool to monitor problems such as disruption of services, troubleshooting and bug reporting. System shall be intelligent to detect any unsuccessful activity, and anomaly of any process. Beside this there shall be an option of self generating alerts or notification at different levels and flexibility of handling specific module or service. For example: if the search engine is not functioning then system shall generate an alert or notification.

4.16.4 Provisioning for a system log to capture all user activities in the system. Log entries cannot be modified. Log reports shall be generated for system audit.

4.17 Billing Requirements 4.17.1 Provision to check and synchronize post-paid subscriber status (Active/TD/PD)

and credit limit during registration, subscription, download, or content browsing. 4.17.2 Provision to send query to IN billing system, virtual account to check balance in

customer account before delivery of contents and subscription based services. 4.17.3 Provision to charge contents from Post-paid Account (CDR with Charge

information), Pre-paid IN account, and Virtual Pre-paid IN Account (M Wallet), Bank Account and International Payment Gateway (i.e. Paypal, VISA).



4.17.4 Provision to calculate final billable amount for service used by subscriber and prepare necessary chargeable information for post-paid billing system.

4.17.5 Provision to declare charge amount both inclusive (for IN) and exclusive (for post paid) of TAX/VAT.

4.17.6 The system shall generate registration and deregistration CDRs for both pre-paid and post-paid. Fields in the CDR should be configurable.

4.17.7 Post-paid CDR shall be in pre-defined file format which shall contain billable (final) information for postpaid subscriber. CDR file shall contain single or multiple unique records of transaction. The format of the file shall be configurable. Attributes of CDR are described below:

4.17.8 CMS shall store CDRs for a minimum of six (06) months. 4.17.9 CDRs should include both incoming and outgoing CDRs (request received and

request delivered). 4.17.10 File content format: The CDR file shall be generated in readable ASCII format. 4.17.11 File name: CDR file shall maintain a sequential file naming convention with

generation date identifier. 4.17.12 File extension: The file extension shall be *.cdr 4.17.13 Field separator: Each individual data field shall be separated by symbol, tab etc. 4.17.14 Required data field: Following necessary data MUST be present in each billable

record. Data fields should be configurable. • Charging MDN (11 digit service no). • Date of service. • Charge type identifier shall be present, which indicate

Monthly/weekly/usage charges. • Channel identifier key, Example: if subscriber access content through

SMS then CDR may contain identifier as 111 for BREW platform or 222 or any types of numeric identifier to identify channel.

• Content category ID, Example: This ID shall identify the content category like for “Joke” it may be 1001 or any numeric identifier which shall represent only one content category.

• Content ID, CMS shall provide unique sequence number of the content.

• Charge amount. • Duration, volume, etc. • Transaction time.

4.17.15 Availability of a unique location, network path, and directory name. The location should be the source for billing system to collect CDR. Access to this location shall be password protected.

4.17.16 Provision to use FTP / SFTP / Telnet protocol for file transfer from CMS to billing system. CMS shall provide necessary TCP/IP port address.

4.17.17 Provision to charge roaming customers for downloading contents. As the Roaming customer’s MDN/IMSI pattern is different system shall implement PLMN code and respective IMSI to track roaming customer and generate CDR accordingly.

4.18 Service Control Gateway There should be a provision for Service Control Gateway (SCG) to perform Deep Packet Inspection to check and block malicious data, and attacks from virus. The module should also manage and monitor optimum bandwidth allocation and utilization (throttling), and prioritization of bandwidth for special contents.




Section 5: Appendix

Notice This documentation is provided in strict confidence. No part of this documentation may be copied, distributed or transmitted by any means whatsoever, or disclosed to third parties, without the express written permission of the Chief Executive Officer, Pacific Bangladesh Telecom Limited.


Content Management System (CMS): Appendix Page 2

The Respondent will submit a Statement of Compliance in the following format: Requirement

No. Comply (C)

Non-Comply (NC)

Partially Comply (PC)

Reason / Comments

2.1 2.2 2.2.1 2.2.1.1 2.2.1.2 2.2.1.3 2.2.1.4 2.2.1.5 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.4 2.4.1 2.4.2 2.4.3 2.5 2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 2.5.6 2.5.7 2.5.8 2.5.9 2.5.10 2.5.11 2.5.12 2.6 2.6.1 2.6.2 2.6.3 2.6.4 2.7 2.7.1 2.7.2 2.7.3 2.8 2.8.1 2.9 2.9.1 2.9.2 2.10 2.11

Gen

eral

Con

ditio

ns

2.12



2.13 2.13.1 2.13.1.1 2.13.1.2 2.13.1.3 2.13.1.4 2.13.1.5 2.14 2.14.1 2.14.2

Requirement No.

Comply (C)

Non-Comply (NC)


Reason / Comments

3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.4.1 3.3.4.2 3.3.4.3 3.3.4.4 3.4 3.4.1 3.4.2 3.5 3.5.1 3.5.2 3.5.3 3.5.4

Bus

ines

s R

equi

rem

ents

3.5.5



3.5.6 3.5.7 3.6 3.6.1 3.6.2 3.6.3 3.6.4 3.7 3.8 3.8.1 3.8.2 3.8.3 3.8.4 3.8.5 3.8.6 3.8.7 3.8.8 3.9 3.9.1 3.9.1.1 3.9.1.2 3.9.1.3 3.9.2 3.9.3 3.9.3.1 3.9.3.2 3.9.3.3 3.9.3.4 3.9.3.5 3.9.3.6 3.9.3.7 3.9.3.8 3.10

Requirement No.

Comply (C)

Non-Comply (NC)


Reason / Comments

4.1 4.2 4.3 4.4 4.4.1 4.4.2 4.4.3 4.4.4 4.5 4.5.1 Te

chni

cal R

equi

rem

ents

4.5.2



4.6 4.6.1 4.6.2 4.6.3 4.7 4.8 4.9 4.1 4.11 4.12 4.13 4.14 4.15 4.16 4.16.1 4.16.2 4.16.3 4.16.4 4.17 4.17.1 4.17.2 4.17.3 4.17.4 4.17.5 4.17.6 4.17.7 4.17.8 4.17.9 4.17.10 4.17.11 4.17.12 4.17.13 4.17.14 4.17.15 4.17.16 4.17.17 4.18