rfp mts security solution 1-10-2013.pdf

Security Solutions - Confidential -

Sistema Shyam Teleservices Ltd. 1

MTS Security Solutions

Request for Proposal (RFP)

Opening Date: < 01 October 2013>

Closing Date: < 18 October 2013 >



Disclosure and Response Confidentiality This RFP is both confidential and proprietary to Sistema Shyam Teleservices Limited (SSTL) and is solely for your companys use in preparation of a proposal. This RFP, as well as any information disclosed by SSTL to your company, is subject to the terms and restrictions outlined in the RFP. In connection with this RFP, SSTL is providing you with various operational, personnel, and other information that is deemed to be proprietary and confidential in nature. Such information is being furnished to you on a confidential basis to be used by you only in connection with your preparation and submission of a proposal in response to this RFP. You agree that such information will be kept confidential and will not, without prior expressed written consent of SSTL, be disclosed by you in any manner whatsoever, in whole or in part. The information will not be used in any manner other than in connection with the preparation and submission of your proposal to SSTL. You further agree that you will not solicit or attempt to solicit any officer, employee, or representative for any business outside of the submission of your proposal in response to this RFP. BY OPENING THIS RFP, YOU REPRESENT AND AGREE THAT YOU ARE WILLING TO COMPLY WITH THE CONFIDENTIALITY PROVISIONS OF THIS RFP.



TABLE OF CONTENTS

1 INTRODUCTION AND SCOPE ....................................................................................................... 4

2 INVITATION ..................................................................................................................................... 8

3 INSTRUCTIONS AND CONDITIONS TO VENDORS ..................................................................... 8

4 CRITICAL DATES .......................................................................................................................... 13

5 CONFIDENTIALITY ....................................................................................................................... 13

6 VENDOR INFORMATION REQUIREMENTS AND SOLUTION SPECIFIC INFORMATION ....... 14

APPENDICES

1 Vendor authority statement

2 Population coverage projections

3 Functional requirements

4 Service levels

5 Device features and actions

6 List of SSTL assets

7 Sales and service delivery related information



1 INTRODUCTION AND SCOPE

1.1 Introduction

Sistema Shyam TeleServices Ltd. (SSTL) is a venture, involving equity participation by Sistema

Joint Stock Financial Corporation of Russia (SISTEMA JSFC), the Russian Federation and the

Shyam Group of India and operating under the MTS brand. Sistema JSFC is the majority

shareholder in the Company. Approximately 2.5% equity stake is held by public. The company

has been awarded Unified Access Services License by the Department of Telecommunication,

Government of India to provide telecom services across 9 telecom circles of India.

SSTL is credited to have introduced a number of innovations in the Indian telecom industry.

The Company is the pioneer of half paisa per second calling in the country. SSTL is also the

first telecom operator in the country to launch prepaid high speed mobile broadband. The

company has taken mobile broadband to another level with the launch of High Speed Data

(HSD) services on National Highways. Today, it is the only telecom operator to provide HSD

services on Delhi - Jaipur and Bangalore - Chennai National Highways.

The objective behind this RFP is to solicit partnerships with firms (hereinafter Vendor) that

are in the business of or is capable of providing security related services through smartphone

applications or over telecommunications network to create a solution which takes care of the

security needs of women. Figure 1.0 gives an over view of the proposed solution. This

solution is intended to be provided to both consumers and enterprises among others. SSTL

intends to market and distribute this product while the vendor is expected to provide the

mobile application and the supporting infrastructure covering computer systems, technical

expertise and customer experience management without limitation. SSTL will own the

customer and the vendor shall provide the requisite level of customer support as per this RFP.

SSTL intends to launch this product in Telecom circles where it currently holds licenses

followed by launches in other geographies and countries. SSTL will use its extensive

enterprise sales infrastructure to sell this product to enterprises and small and medium

enterprises (SME) as well.

SSTL seeks partners who are open to a revenue share engagement.



Figure 1.0

1.2 Product Component Description

1. A Wearable Trigger which would wirelessly pair with a smartphone and can be used to

initiate specific actions through a linked smartphone application. The main use case is to

easily trigger an SOS alarm when under attack or threat. The Wearable Trigger would send a

signal to the smartphone with which it has ben paired.

SSTL would be responsible for procuring the Wearable Trigger. The Vendor is expected to

work closely with the Wearable Trigger manufacturer identified by SSTL at its own cost and

provide the relevant technical inputs and expertise to ensure that the Wearable Trigger

works seamlessly with the App as contemplated. The Vendor is expected to deliver the

features set out in Appendix 3 after accommodating the technical limitations of the Wearable

Trigger identified by MTS. Please refer to Appendix 3 E for an understanding of the device

specifications and the level of customization required.



2. A Smartphone Application (hereinafter the App) which can trigger an SOS alert to pre-

designated guardians. This application should be able to trigger the SOS alert with the latest

GPS coordinates on receiving a wireless signal from the Wearable Trigger and from the phone

itself.

The Vendor is expected to provide SSTL with a white labeled application as per the

specifications of this RFP.

3. An optional Portable Alarm that can be carried by the user on her person or in her

handbag. This is expected to produce a very loud audio alarm which will alert people nearby

on receiving a wireless signal from the phone.

SSTL would be responsible for procuring the Portable Alarm. The Vendor is expected to work

closely with the Portable Alarm manufacturer identified by SSTL at its own cost and provide

the relevant technical inputs and expertise to ensure that the Portable Alarm works

seamlessly with the App as contemplated. In case SSTL decides to launch the Portable Alarm

at a later date and not as part of the initial launch, the Vendor shall ensure that provision is

made for the installed base of the App to work with the Portable Alarm.

4. A Computerized System (hereinafter the SOS Server) which would be utilized to render

the services proposed which would include but is not limited to user onboarding, service

activation, provisioning and receiving and processing the SOS alert from a user.

The SOS Server setup must be physically located in India and all data must be stored within

the sovereign territory of the Republic of India. Vendors must be open to hosting the system

in the SSTL data center.

1.3 Proposed Sales and Service delivery Process

The Wearable Trigger shall be sold through a variety of channels including but not limited to

mass retail, online and institutional sales channels. The box shall include the Wearable

Trigger and an activation key as well as instruction on how to download and install the App



from the relevant operating system linked application store such as iTunes or Google play in

addition to other relevant material.

The user is expected to register himself/herself with the relevant details and input the

correct activation key for the services to be provisioned. The subscription period for the

services rendered by the proposed product shall be one (1) year from the time of activation

of services. The services can be renewed by the user at the end of the subscription period on

the payment of a fee and by inputting an authentication key at one of the account

management interfaces.

In case of an emergency, the user can trigger an alarm by pressing the button. The guardians

configured by the user will receive an automated call triggered by the SOS Server informing

them about the details of the alert. The guardians can stay informed of the last known

location of the user by returning a call to the number from which the automated call

originated. This would be supplemented by SMS, e-mail and social media linked information.

An overview of the proposed processes involved can be found in Appendix 7. The Vendor is

at liberty to propose amendments to the process or a new process entirely provided the

rationale is provided as well.

The Vendor is expected to propose a solution which can enable the above.

1.4 Strategic Alignment

The security product is expected to be the first of a new service line under the MTS brand.

This service line would include security and M2M based services covering family and asset

tracking and security, but is not limited to the mentioned products. The App is expected to be

one of the consolidated touch points through which these different services would be

delivered to the customer. The vendor is expected to have the capabilities to enable 3rd

party inputs to be received by the App. This capability is not expected to be present in the

App for the current product but the Vendor must have the capability and willingness to

enable it as per SSTLs request.



2 INVITATION

Proposals in the form of an electronic response (email) as well as physical copies are invited from the

eligible vendors for supplying, integrating, commissioning, operating and maintaining the App and

the SOS Server.

Two (2) physical copies of the proposal addressed to Apu Martin Thomas shall be submitted in a

sealed envelope at the offices of Sistema Shyam Teleservices Ltd. MTS India Towers, 334, Udyog

Vihar, Phase IV, Gurgaon 122001 on or before 18:00 hrs. on 18- 10-2013.

An electronic version of the proposal shall be submitted through an email at

[email protected] on or before 18:00 hrs. on 18- 10-2013 as well.

The Vendor is requested to make available the latest instance of any smartphone application that the

Vendor may have that is similar to the App mentioned in the RFP for evaluation as well.

3 INSTRUCTIONS AND CONDITIONS TO VENDORS

3.1 General

Vendors shall analyze and respond to RFP, providing sufficient information to allow SSTL to

evaluate the Proposal. Vendors shall ensure that the following requirements for submission

of their responses to this RFP are met.

Each section of the response must clearly identify the corresponding RFP item.

All pages must be numbered.

The RFP must be signed by the submitter or representative of the Vendor.

Vendors may also attach supplementary material.

Vendors must provide RFP "Submitted by" contact information including name, designation,

phone and e-mail contacts and address.

The RFP response should not exceed fifty (50) pages.

3.2 Response Evaluation and Proposal Selection

SSTL reserves the right, without qualification to:

a. Select any proposal as a basis for written or oral discussion with any or all of the Vendors,

when such action is considered to be in the best interest of SSTL;

b. Reject all proposals;

c. Exercise discretion and apply its judgment with respect to any proposals submitted. If after

attempting to obtain competitive bids for material or services and only one (1) bid, proposal



or offer is received and that bid, proposal or offer does not exactly meet our specifications or

budgetary limits, the Procurement and Contracts Management staff shall have the authority

to negotiate with the Bidder to secure an acceptable bid, proposal or offer. SSTL may select

proposals, based on initial proposals received without discussion or after limited discussions

or negotiations. Vendors are therefore advised to submit their initial proposal on the most

favourable terms possible.

3.3 Intellectual Property

In the event that know-how or intellectual property rights evolve or are generated or arise

out of or in the performance of any work carried out by the Vendor in responding to this RFP,

ownership of such rights shall vest in and remain with SSTL.

3.4 Response Format

The proposal shall be provided electronically by email and/or CD-ROM in Microsoft Word

format / MS-Excel for the compliance sheet.

3.5 References and use cases

Vendor needs to provide at least one (1) reference and a case study for an implementation similar to the proposed solution.

3.6 Contacts

All correspondence in relation to this RFP will be send by e-mail to the below addresses. If

phone contact is necessary, below mention contacts are available:

Business Contact:

Apu Martin Thomas

Commerce Function, Corporate Center

Sistema Shyam Teleservices Limited

MTS India Towers, 334, Udyog Vihar, Phase IV, Gurgaon 122001

MTS +91 913 600 1743

Direct +91 124 481 2741

Email: [email protected]



Technology Contact:

Prashant Singh

Head, VAS Applications Division

IT Function, Corporate Center

Sistema Shyam Teleservices Limited

Building No. 387, Udyog Vihar, Phase II, Gurgaon 122001

MTS +91 913 600 1453

Email: [email protected]

3.7 Cost of RFP response

The Vendor shall bear all costs associated with the preparation and submission of the

response up to the final award of the contract. SSTL will in no case be responsible or liable for

those costs, regardless of the conduct or outcome of the procurement process.

3.8 Validity of response

The offer outlined in the proposal must be valid for a minimum period of 90 calendar days

after the later of the closing date or the date of receipt of the RFP response by SSTL . A

proposal valid for a shorter period may be rejected by SSTL. In exceptional circumstances,

SSTL may solicit the bidders consent to an extension of the period of validity. The request

and the responses thereto shall be made in writing. Any Vendor granting the request will not

be required nor permitted to modify its proposal. The Vendor must submit the completely

filled out form in Appendix 1.

Any proposal made by the Vendor that is not submitted in the format and/or using the

templates mandated by SSTL may be considered to be an invalid proposal at SSTLs sole

discretion.

3.9 Receipt of Proposals from Non-invitees

SSTL may, at its own discretion, extend the RFP to Vendor that were not included in the

individual invitation list if this is necessary and in the interest of SSTL.

3.10 Amendments of the RFP

At any time prior to the closing date for submission of proposals, SSTL may, for any reason,

whether on its own initiative or in response to a clarification requested by a Vendor, modify



the RFP by amendment. Amendments could include modification of project scope or

requirements, project timeline expectations or extension of the closing date for submission.

All prospective bidders that have received the RFP will be notified in writing of all

amendments to the RFP.

3.11 Clarification of Proposals

SSTL may, at its discretion, ask any bidder for clarification of any part of its proposal to assist

in the examination, evaluation and comparison of proposals. The request for clarification and

the response shall be in writing. No change in price or substance of the proposal from the

Vendor shall be sought, offered or permitted during this exchange.

3.12 Vendors' Presentations

At the discretion of SSTL, selected Vendors may be invited to supply additional information

on the contents of their proposal during the evaluation period. Such Vendors could be asked

to give a presentation of their proposal followed by a question and answer session. If SSTL

determines that there is such a need, the presentation will be held at SSTL corporate office in

Gurgaon, or by videoconference/Internet. Vendors will be given reasonable time to prepare

for the presentation.

3.13 Warranties

The Vendor will warrant and represent to SSTL as follows:

a. The deliverables shall meet the specifications and shall function in a manner which is fully

adequate to meet its intended purpose. The Vendor furthermore warrants that the

deliverables shall be error-free, in that the Vendor shall correct any errors in the

deliverables, free of charge, within fifteen days after their notification to the Vendor,

during a period of at least six months after completion of the work. It is agreed, however,

that errors and other defects, which have been caused by modifications to the

deliverables made by SSTL without agreement of the Vendor are not covered by this

paragraph.

b. The deliverables shall, to the extent it is not original, only be derived from, or incorporate,

material over which the Vendor has the full legal right and authority to use it for the

proper implementation of any contract resulting from this RFP. The Vendor shall obtain



all the necessary licenses for all non-original material incorporated in the deliverables

including, but not limited to, licenses for SSTL to use any underlying software, application,

and operating deliverables included in the deliverables or on which it is based, so as to

permit SSTL to fully exercise its rights in the deliverables and the software without any

obligation on SSTLs part to make any additional payments whatsoever to any party.

c. The deliverables shall not violate any copyright, patent right, or other proprietary right of

any third party and be delivered to SSTL free and clear of any and all liens, claims,

charges, security interest and any other encumbrances of any nature whatsoever.

d. The Vendor, its employees and any other persons and entities used by the Vendor shall

furthermore not copy and/or otherwise infringe on the copyright of any document or

other material (whether machine readable or not) to which the Vendor, its employees

and any other persons and entities used by the Vendor have access in the performance

of this RFP or the resulting contract if any.

e. Except as otherwise explicitly provided in this RFP or any contract resulting from this RFP

if any, the Vendor shall at all times provide all the necessary on-site and off-site

resources to meet its obligations hereunder. The Vendor shall only use highly qualified

staff, acceptable to SSTL, to perform its obligations hereunder.

f. The Vendor shall take full and sole responsibility for the payment of all wages, benefits

and monies due to all persons and entities used by it in connection with the

implementation and execution of this RFP or the resulting contract if any, including, but

not limited to, the Vendors employees, permitted subcontractors and suppliers.

3.14 Relation between the parties

This RFP does not constitute a partnership between the parties or constitute either party as

the agent of the other. This RFP should not be construed as a commitment by SSTL to award

a contract on the basis of the Vendors responses.

3.15 Officials not to Benefit

The Vendor warrants that no official of SSTL has received or will be offered by the Vendor any

direct or indirect benefit arising from this RFP or the award thereof. The Vendor agrees that

breach of this provision is a breach of an essential term of this RFP or any contract that may

result from it. The Vendor is required to report any matter which falls under the purview of



this section including but not limited to incidents or solicitation for any undue benefits or

unethical practices with all relevant details to [email protected] within one working day.

4 CRITICAL DATES

4.1 Acknowledgement of the Receipt of the RFP

Vendors shall acknowledge receipt of the RFP by 18:00 hours IST on 2-10-2013 by email to

the Business as well as Technical Contacts.

4.2 Communication of Intent to participate

Vendors shall communicate it intention to respond or not respond to the RFP by 18:00 hours

IST on 3-10-2013 by email to the Business as well as Technical Contacts.

4.3 Questions Regarding the RFP

Queries regarding the RFP must be submitted to the Business and Technical Contacts, via E-

mail, by 18:00 hours IST on 7-10-2013. Every attempt will be made to promptly answer all

enquiries from each Vendor.

4.4 Proposal Due Date

Formal, softcopy (MS Word/Excel for the compliance sheet) of responses must be received

no later than 1800 Hrs IST on 18-10-2013. Extensions to the proposal due date will not be

granted without the written authorization of SSTL.

Vendors should be assured that a Non Bid decision for this RFP would not exclude the

Vendor from future consideration.

5 CONFIDENTIALITY

Vendors must recognize and acknowledge that SSTL operates in a highly competitive business

environment and for that reason expects that Vendors will treat all materials and data provided by

SSTL as confidential. Vendors who currently do not have a Non-Disclosure Agreement (NDA) with

SSTL must complete and return a NDA as soon as possible.

The Business Contact must approve in writing the distribution or sharing of this RFP by Vendors with

any other parties. Vendors may disclose relevant parts of this RFP to its relevant business partners



and/or subcontractors provided that the partners and/or subcontractors first have executed a Non-

Disclosure Agreement (NDA) with SSTL.

For the avoidance of doubt, this RFP, SSTLs methods for evaluating responses, and the timing and

content of any meetings, discussions and negotiations between SSTL and the Vendor shall be deemed

Confidential Information for the purposes of the NDA.

SSTL will not share any information from the Vendors response with any other Vendors without the

prior written agreement of the Vendor.

In addition, SSTL and Vendor agree that all Proprietary and/or Confidential Information shall be

handled in accordance with the Non-Disclosure Agreement.

6 VENDOR INFORMATION REQUIREMENTS AND SOLUTION SPECIFIC INFORMATION

The Vendor shall provide information about its organization and its understanding of the proposed

security solution as well as timelines and commercials of the proposed execution. The required

information is described below; the Vendor is to submit the response in the order and manner

described below. SSTL reserves a right to reject responses that are submitted not in the specified

format.

In order to better control operational costs and user experience, SSTL requires that the Vendor

integrate SSTL owned or controlled assets and/or systems with the Vendors proposed solution. A

detailed list of the mandatory SSTL assets can be found in Appendix 6 of this RFP. If a Vendor is of the

opinion that a better alternative is available, the Vendor may inform SSTL of the same including the

justification in the format given in Appendix 6.

6.1 Brief Overview of the Vendors Organization

This shall include office locations, staff numbers and information of the primary location that will carry

out work if the Vendor is selected no more than one (1) MS Word page/two (2) PPT slides.

6.2 IT related Products and Professional Services Overview

A summary of other related products and services offered/created by the Vendor shall be provided

no more than 3 MS Word pages/6 PPT slides.



6.3 Outline of the Technical Solution

The Vendor shall describe his/her vision for the execution of the solution. Any differences between

the proposed system, features, processes etc. for individual users and enterprise or SME users must be

highlighted in the information that the Vendor is providing under this section. The outline should

include

a) Detailed architecture diagrams (physical, logical and network diagrams)

i. Describe how you are dimensioning any internet connections in the case of a remote hosted

solution.

ii. Describe how such a system would scale using the dimensioning assumptions and projected

growth rate.

iii. Describe redundancy and failover configurations

b) Details of technology on which platform has been built (hardware and software)

c) Solution design and technical workflow

d) Integration points with nodes in the SSTL/mobile telecom service provider eco-system, if any

(please provide all details such as nodes to be integrated, purpose of integration, protocols

supported for integration, out-of-box API available or customized integration mechanism to be

developed, typical timelines for creating new integration API, etc.)

e) Data Center Requirements

i. If you propose some systems to be physically hosted within a SSTL data centre, indicate the

space, power, security (logical and physical) and network connectivity requirements.

ii. Describe access requirements for personnel

f) Technical assumptions

g) Detailed deployment project plan

h) Implementation and operations support governance structure with responsibility matrix

i) Operations support model proposed

j) Change request process

k) Risk Matrix with risk mitigation plan

l) Solution for enabling customer care / Helpdesk

m) Solution for monitoring / enhancing Customer Experience & System performance

n) Handset support Roadmap

o) Quality Assurance process and management systems



p) Overview of security for the solution proposed (please provide details of security certificates

obtained for solution, ability to support penetration testing conducted by SSTL, etc.)

q) Subscription management and solution for providing a subscription based service

r) User account management from App and a web portal

s) Business continuity and recovery plans

t) Description of services and features available to enterprise and SME customer

u) Technical expertise and project plan including responsibility matrix for Wearable Trigger

customization and integration including but not limited to testing of the Wearable Trigger and the

integration between the App and the Wearable Trigger.

Please refer to Appendix 5 for a description of the proposed Wearable Triggers features and

information on some technical specifications including the expected level of customization and

customization support required from the Vendor.

6.4 Bill of materials

Please describe all materials required for implementation no more than four (4) MS Word pages/four

(4) PPT slides. This should include:

a) Hardware specifications if applicable

b) Pricing

c) Support pricing for five (5) years.

6.5 Business Models

SSTL invites Vendors to propose a Revenue Share model.

6.6 Compliance sheet

Please refer Appendix 3 for both Functional and Technical requirements. The requirements are in a

compliance sheet format. The vendor will need to respond against each line item mentioned. The

response will be C compliant, PC partially compliant, NC Not compliant. For PC / NC, please

provide additional explanations in the remarks column. For any entries marked as partially compliant,

please state the number of working days the Vendor would require to be fully compliant in an

additional column where applicable. Kindly submit the compliance sheet either in MS Word or MS

Excel format as well.

Description of service levels that will be provided are expected to be furnished in the format attached.

Incident severity and priority will be as defined in Appendix 4.



Please state total projected scheduled down time for the year keeping in mind feature releases.

As the product is expected to be launched under the MTS brand name of which SSTL is a licensee, and

given the sensitive nature of the need this product addresses, the possibility exists that any deficiency

in service on the part of the Vendor will lead to impairment of the brand including but not limited to

loss of reputation, negative publicity and adverse perceptions and may make SSTL liable for damages.

As a safeguard SSTL proposes the measures outlined in Appendix 4 to ensure that service levels are

adhered to.

6.7 Timelines

The Vendor will provide the envisioned timeline of the execution with the phase-wise breakdown no

more than one (1) MS Word pages/two (2) PPT slides.

6.8 Commercials

The Vendor is to provide commercials in the format given in Appendix 2. Any submissions in any other

format or in violation of the instructions given in Appendix 2 or the relevant excel sheet format will not

be considered by SSTL.

The Vendor is required to consider SSTL infrastructure that has to be mandatorily used while creating

the commercial proposal. The list can be found in Appendix 6.

6.9 Strategic Alignment

The Vendor shall provide detailed information on its capability to enable SSTLs vision as spelt out in

Section 1.4 of this RFP.



APPENDIX 1

Vendor Authority Statement

The proposer represents and certifies as part of the Proposal that he/she is authorized to act as an agent

for the corporation responsible for this Proposal.

The costs stated in the Proposal were arrived at independently, without consultation, communication or

agreement with any other proposer or with any competitor, for the purpose of restricting competition.

_____________________________________

Signature of Approving Authority (with Company Stamp)

Title _____________________________________

Date _____________________________________



APPENDIX 2

SSTL intends to launch this product in urban areas in circles for which it currently possesses telecom licenses. Instructions for proposing commercials:

1. All rates have to be inclusive of all taxes, cess, duties etc.

2. All rates have to be in Indian rupees

3. Vendors have to fill the matrix given as is.

4. Cells with a completely black background should not be filled.

5. Activation refers to the point in time when a user's valid activation key inputted into the application is authenticated and services are provisioned

6. Renewal refers to the point in time when an existing user's valid renewal activation key inputted into the application or any other relevant user touch-point is authenticated and services are provisioned

7. Vendors must give their inputs in the attached excel file and submit the same to SSTL in

electronic format as well.



Lower limit Upper limit

Capex Cost per

Activation

Cost per

Activation

Cost per Renewal Cost per

Activation


Activation


Activation

Cost per Renewal

1 5,000

5,001 10,000

10,001 15,000

15,001 20,000

20,001 25,000

25,001 30,000

30,001 35,000

35,001 40,000

40,001 45,000

45,001 50,000

50,001 55,000

55,001 60,000

60,001 65,000

65,001 70,000

70,001 75,000

75,001 80,000

80,001 85,000

85,001 90,000

90,001 95,000

95,001 100,000

Year 1

100,000+

Commercial terms for security solutionBand Year 2 Year 3 Year 4 Year 5



APPENDIX 3

This appendix discusses features of the platform with inbuilt analytics as well as mobile applications.

Legend: C = Fully compliant, NC= Not-compliant, PC= Partial compliant

Note: For clauses that are marked as C or PC, its mandatory to provide explanatory remarks that will

assist in evaluating the response.

A. Functional and Technical requirements - Overall

Feature/Capability Description Compliance (C, NC, PC)

Remarks

Application Capability

1. Device agnostic rich client experience 2. In absence of Data connectivity, critical information transmission via SMS 3. Enterprise module supporting multi-tenancy

Channels Data is primary Channel with SMS as backup

Application Developer framework

Exposes standard APIs where by developer community can use those APIs and create enterprise applications

Partner Capability Partner shall have experience in integrating the solution with other applications such as OSS/BSS systems, etc.

Devices All smart devices running the following Operating systems: Android, iOS, Blackberry OS, Windows Mobile OS

User Sign and Authentication

Provide the users with features like single-sign on, authentication, personalization and customization within all parts of the MTS-owned piece including but not limited to the App and the website.

Self Care, service provision and de- provisioning

The system shall be able to automatically provision or de-provision services depending on business rules.

Subscription Management

1. Manages subscription including scenarios where the device, phone number etc. without limitation are changed 2. Enterprise level licensing and subscription management



Charging/Billing 1. Yearly charging 2. Subscription renewal management

Open Standards

Open Standards to facilitate interoperability and data exchange among different products or services and are intended for widespread adoption

Multitenant architecture

Applications are designed to virtually partition its data and configuration so that each client organization works with a customized instance

Security Policy

User data information is not available to others unless authorized. The vendor should comply with the security policies set as per SSTL. All critical information/data stored within the system should be encrypted. Application should be able to authenticate users based on MDN, UserID, Password. It should have encryption policies on data w.r.t. storage and transit processing.

IPV 6 The platform shall be IPV6 compliant

Test Bed For testing of applications by developer community or MTS before moving to production

MIS/ Reports

The platform shall provide reports as per business and technical requirements (Not limited to) 1. Usage report

2. Subscription report

3. SLA report

Integration

The platform shall be capable of integrating with Telco grade systems including but not limited to 1. Billing

2. Online Provisioning

3. ITSM/NOC tools

4. CRM

5. SMSC

6. IVR



Application Life Cycle Management

The complete application life cycle management process shall be provided by the partner 1. Discovery

2. Delivery

3. Install

4. Configure

5. Upgrade

6. Replace

7. Management

8. Uninstall

Version Management Describe the typical version upgrade process when a new commercial release is available

Operation Support (24*7 )

Partner shall be responsible for day to day operations or would introduce partners capable to do the same

Operations Management

End to End operations management (not limited to) 1. Fault monitoring and alarms

2. Policy Management

3. Network Interfaces

4. Backup

5. Scalability

6. Availability

Help Desk Help desk services for servicing consumer and enterprise customers

Self-monitoring Ability to check the entire app to guardian link for any impairment in quality of service and for system up-time

Web interface for B2B clients

Customizable web interface deployable at an enterprises security control room

Touch point Customizability

All customer touch points must be customizable from a branding perspective and SSTL usability guidelines



VXML 2.0 based Integrated Voice Response (IVR) Application

Application to be developed and hosted at SSTL Data Center for integrating with SSTL IVR for providing location update to Guardians once SOS is initiated by customer. Text-to-Speech (TTS) functionality for streaming voice packets to application hosted on SSTL IVR, and server for hosting VXML application to be provided by vendor



B. Functional and Technical requirements App


Remarks

SMS Alerts from App SMS sent to pre designated numbers with a SOS message

One-touch SOS alert A button on the primary app screen which will trigger the services

SOS alarm with live GPS tracking online

Location tracking once the alert is triggered

Location info in SOS SMS

Last know location included as part of the SMS as an internet link or nearest identifiable address

SMS back-up in case of no data connectivity

App to send location data as part of SMS to back-end server in areas without data connectivity

Stop location tracking option Option to stop tracking location

Non-GPS location Tracking

Network triangulation based location identification

Shake to activate Ability to activate alarm by vigorously shaking the phone

Customizable shake Feature

Ability to adjust the intensity of the shaking needed to trigger the app

Cancel alert feature

Ability to cancel a false alarm. This should include an alert being sent to activate the bands vibration feature whenever an alarm is triggered.

Can trigger audio alarm through phone speakers

Siren using phone speakers to alert passers-by to come to the user's aid

Cancel alert at SOS Server

Alert cancellations must be done at the SOS Server and not at the application level

Geo-tag unsafe locations/incidents

Ability to tag an area as unsafe on a map through the app

e-mail Alert E-mail alert to designated e-mail ids

Social Media Alert posted on users social media sites with location and SOS message

Route map as part of SOS alert

Alert in case of forced shut down of phone

"Check on me alert" incase the phone is shut off when battery is not low and deviates from regular usage patterns

"Track me" feature Alert sent asking people to check on user regularly

SMS location update for every 10 mt change post alarm if no data

Sends location update through SMS/USSD in areas without data coverage if the phone moves 10 mts



link from the last know location

Call me and bail me out feature

Alerts a guardian to call user to provide an escape from an uncomfortable social or other situation

Content through app

Ability to send content related to TG through the app. Eg. - Safety tips, health tips etc.

Safety alerts and tips Location based

Informs users if entering an area which has designated as unsafe by other users

Number of phone numbers to which app triggers SOS calls Five (5)

Number of phone numbers to which app triggers SMS Five (5)

Number of e-mails to which app triggers SMS Five (5)

Run at start-up App automatically starts and runs in the background

Syncs with Device at pre-set time(s)

Syncs with wearable trigger only at pre-set times scheduled - battery conservation

Syncs with Device for pre-set duration

Syncs with wearable trigger only for pre-set durations battery Conservation

Set safe zones Set areas where the app will not be triggered

Prioritize Bluetooth pairing with device in case of Bluetooth conflict

Over rides other Bluetooth devices in pairing priority

Alert user in case entering unsafe zone

Unsafe zones would be decided basis user tagging

Deviation from safe route alert

Alerts user/guardian if any deviations from pre-set route

SOS button available on lock screen

SoS button should be available through a locked screen without having to unlock phone

Block calls feature Block specific numbers from calling user's phone

White listed calls only when active feature

Allow only specified numbers to call user's phone when this feature is active

Block SMS feature Block specific numbers from texting user's phone

SMS Alerts from App SMS sent to pre designated numbers



with a SOS message

Devices supported (please specify all the versions supported)

Android

IPhone

Blackberry

Windows

Others (please specify)

Indoor positioning capability

Ability to locate a device inside a building, especially which storey

Audio recording of customers name during registration

A user must be able to record his/her spoken name in the application which must then be stored on the SOS Server for retrieval during an SOS alert outbound call

Im Here notification to pre-loaded number

Sends a "I'm safe" message on reaching a pre-designated location

Alert on pro-longed signal loss in no coverage areas

If alert is triggered in no-network zone, app will send the SOS whenever a network is detected

User account management

User must be able to modify all customizable aspects of the product from the app itself



C. Functional and Technical requirements SOS Server


Remarks

Communications from back-end

Back-end server which will initiate and control all communications

Outbound call alert Outbound dialer to pre designated numbers with a SOS message and last known location

Online map provider integration for unsafe location alert

Last know location to be easily accessible through an online map services

Tracking subscriber route for duration of alert raised

Route to be mapped once alert has been raised, till alert has been resolved / switched off by user

Alert to nearest subscribers with App enabled

Alerts other app users in the vicinity incase alarm is triggered

One-time emergency tracking code for others

Ability for guardian to track the user location for a single time and for a fixed duration even if an alarm is not raised by user. This feature has to be enabled by user.

Outbound call in Vernacular

Outbound dialer in the language selected by user with the address in an Indian accent

Provisioning with activation key

Service should start only upon receiving a one- time activation key or subscription renewal key as the case may be

User behavior based auto alerts

Ability to analyze user behavior and propose/raise alerts in case of deviations

Web based interface Web based interfaces that can provide critical information to first responders

30 % buffer capacity

Buffer capacity at each node from peak utilization

99.9% Uptime System availability

Status update over IVR

Guardians should be able to obtain the latest information on a user who has raised an alert by calling the number from which the outbound dialer originated

Secure status update for non-guardians

Guardians must be able to share the location of a user who has raised an alarm. This should be accessible to a non-guardian over e-mail, SMS and



phone calls

Opt out for guardians A guardian must be able to opt out of receiving calls related to this service for a unique user alone the first time he/she receives a call from a system pertaining to that user alone. User must be activated if a guardian opts out.

Historical data Availability

Alarm details (including routes) to be available even beyond alert being closed / addressed for a specified duration

Guardian number screening

System should to ensure that guardian numbers are private personal numbers of individuals and not that of the police or any public or govt. entity or any private concern or entity. All numbers have to be local numbers as well.

Location in India The server hardware must be physically located in India and all personal information of the customer must be stored within the sovereign territory of India.

Reporting capabilities Extensive report (summary / detail) producing capabilities. Example: 1. MDN wise list of subscribers

2. Expiration date wise

3. subscriber list

4. Report based on frequency of

alerts raised

5. Report based on geography /

circle from where alerts are

raised

6. Multiple alerts from same

location over a fixed time period

(input for marking that area as

unsafe)

7. Due for renewal list

Indoor positioning Capability

Ability to translate relevant inputs from the App to usable location information

Misuse tracking and Control

Mechanism to monitor and control the usage of the service based on business rules



User account Management

User must be able to modify all customizable aspects of the product from the app itself

D. Functional and Technical requirements Customer Experience


Remarks

CRM Vendor to provide and enable SSTL to interface with Vendor CRM systems. This CRM systems can be cloud based and should be accessible over the internet by SSTL customer care representatives and should be configurable to handle both software and hardware related issues

L2 response All aspects of the product except hardware issues with the Bluetooth bracelet on a 24/7 basis over phone, chat or e-mail.

Product documentation Relevant product documentation must be provided including but not limited to: 1. Training manuals for sales

2. Training manual for customer

service

3. Product manuals for users

Helpdesk support Capability to integrate with SSTL CRM so that complaint / query raised by subscriber (of service) can be routed to vendor issue resolution team automatically

Incident Management Capability to integrate with SSTL ITSM tool for responding & resolving tickets raised within stipulated SLAs



E. Customization and integration requirements Wearable Trigger Please refer to Appendix 5 for a detailed description of the existing features, proposed modifications and additional features that have to be created. The Vendor is expected to provide the technical expertise and project management expertise in coordination with SSTL to ensure that the hardware vendor chosen to provide the Wearable Trigger supplies a device that is compatible with the App and which is optimized for the purpose contemplated in the RFP. For filling up the table given below, please follow the instructions hereunder C The Vendor has the complete set of skill sets and expertise required in-house to enable the function described in the table and can provide the support required PC The Vendor may have only partial levels of the set of skill sets and expertise required in-house to enable the function described in the table but can acquire or obtain the skill sets and expertise required to render support required by the time any commercial agreement that may result out of this RFP is executed NC - The Vendor has neither the complete or partial set of skill sets and expertise required in-house to enable the function described in the table nor can the Vendor acquire or obtain the skill sets and expertise required to render support required by the time any commercial agreement that may result out of this RFP is executed

Event Action description Compliance (C, NC, PC)

Remarks

Mo

dif

icat

ion

s Switching device off Press & hold for 12 seconds

Silence vibration alarm Quick press 1 time

Phone proximity alarm Vibrate 1 time for 1 second in every 3 seconds

Ne

w f

eat

ure

s

Custom signal to application (A) Press & hold between seconds and 4 seconds

Application response to custom signal (B)

Signal

Application activation alert (C) Continuous vibration without break on receiving signal (B) till vibration cancelled

Pairing lost or disconnected Vibrate 1 time for 1 second in every 6 seconds



APPENDIX 4

Service Levels

Service Level Agreements SLA

Severity Level-1 (Critical) issues will be attended to and service restored as per the SLA 95%

Severity Level-2 (High) issues will be attended to and service restored as per the SLA 90%

Severity Level-3 (Average) issues will be attended to resolved as per the SLA 90%

Severity Level-4 (Low) issues will be attended to resolved as per the SLA 90%

Application / System uptime 99.99%

Response time of application for providing current location update of customer to guardian should be less than 5 secs 99.80%

Illustration of Severity Categorization

As per the attached Severity definition document

P1 to P4

Timelines for Operations support (on 24x7 schedule)

Severity Response Workaround/ Restoration/Resolution

Permanent Fix

Sev 1 Critical 30 minutes 2 hours 2 working days

Sev 2 High 1 hour 4 hours 4 working days

Sev 3 Average 1 hour 8 hours 6 working days

Sev 4 Low 2 hours 24 hours 8 working days

Please see addendum below for definitions on severity. Penalty clause

Application/system uptime Rs. 1,00,000 per hour of downtime

Severity Response SLA breach penalty Resolution SLA breach penalty

Sev 1 Critical

Rs. 50,000 per hour pro-rated for peak hours Rs. 30,000 per hour pro-rated for off-peak hours


Sev 2 High



Peak hours till determined by empirical data can be considered to be the hours during which the probability of the services being used is very high.



Incident Management process addendum* Guidelines for categorizing incident:

Incident priority Description

Priority-1: Critical - Impacting Services in one or more circles and no workaround in place. - Anything which prevents users from raising an SOS alarm and/or

Guardians from receiving an SOS alert with time stamp and location/address

- Critical System, network or key application outage (or imminent outage) with critical impact on service delivery.

- Business users or partners of one or more circles are unable to use IT Systems for business transaction.

- Any incident that is directly impacting the revenue of MTS impacts one or more service level commitments.

- Any regulatory requirement. - Any Critical Service degradation (slowness) impacting one or more

circles.

Priority-2: High - Impacting services in one or more circles with work around solution available till the problem is corrected.

- Service degradation of non-critical services impacting one or more circles. - More than 10 % of subscriber base is affected in a particular circle. - Any event/customer activity that may lead to security related incident. - Critical data mismatch in MIS report.

Priority-3: Average - Impacting the critical services for individual customer that may lead to customer dissatisfaction.

- Any service disruption that will affect the productivity of individual business user.

- Data query on MIS report.

Priority-4: Low - Any other incident that affects directly or indirectly the quality of IT services to the end user.

- Individual user complaint with work around possible.

* These definitions are subject to revision



APPENDIX 5

Device features and actions:

Event # Event Action description LED Status Device state Pairing state

Exis

tin

g fe

atu

res

1 Switching device on Press & hold for 3 seconds

Blue - Flicker 3 times

Off Not paired

2 1st time pairing Press & hold for 6 seconds

Blue - Continuously glow for 6 seconds

Off Not paired

3 Pairing after device is on

Info not available Info not available

On Not paired

4 Reject incoming call Quick press 2 times NA On Paired

5 Low battery Vibrate 4 times over 30 seconds

NA On Paired

6 Incoming call Vibrate 2 times in 1 second till call answered, rejected or dropped

NA On Paired

7 Successful pairing Vibrate 1 time after pairing sequence

NA On Paired

Mo

dif

icat

ion

s

1 Switching device off Press & hold for 12 seconds

Blue - Flicker 12 times

On Paired

2 Silence vibration alarm

Quick press 1 time NA On Paired

3 Phone proximity alarm Vibrate 1 time for 1 second in every 3 seconds

NA On Paired

Ne

w f

eat

ure

1 Custom signal to application (A)

Press & hold between 2 seconds and 4 seconds

NA On Paired

2 Application response to custom signal (B)

Signal NA On Paired

3 Application activation alert (C)

Continuous vibration without break on receiving signal (B) till vibration cancelled

NA On Paired

4 Pairing lost or disconnected

Vibrate 1 time for 1 second in every 6 seconds

NA On Not paired



Technical specifications:

Bluetooth version V 2.0

Carrier frequency 2401 MHz-2480MHz

Through-put power 0dBm

Effective range 10m

Continuous operational time 90 hours

Operating temperature range -10C to ~+50C

Storage temperature range -20C to ~ +80C

Charging voltage 5 to ~ 5.3V

Charging period 2 hours

LED colour Blue



APPENDIX 6

List of SSTL assets that have to integrate with the Vendors proposed solution.

Asset Name Description Vendor comments

Converged voice platform HP Internet Usage Manager (IUM) based platform which handles outbound calls and inbound IVR calls

IT Service Management Tool (ITSM)

HP Openview is used by SSTL to measure SLAs and to track operational incidents to closure. This tool is expected to used to monitor SLA adherence.

Smart Sys tool Internal device service request management tool based on an ASP .NET platform.



Appendix 7

1. High level process map for onboarding a new user

User buys device

User downloads application

User registers

User furnishes guardian details

Guardian onboarding

User tests device

functionality

User tests service

User Onboarded

User inputs activation key

User Validated

User provides validation

details

2. Proposed high level outbound SOS alert call process

User Triggers alert

Device provides vibration

alarm

Triggered by mistake

App sends SMS to

GuardiansNo

App triggers after cancel

alarm window time

out

App sends location alert

to server

Server initiates

outbound IVR alert to

Guardians

Guardian calls IVR number

Server screens for

user alarm in last 12 hours

Did user trigger alarm

Server provides last

known location

yesServer

terminates call

No

User cancels alarm

yes

Server informs guardian that location cannot be

provided for more than 12 hours from alert

Server identifies

user mapped to guardians

number

Server terminates

call to Guardian

3. Components of the retail package

a. Bluetooth module

b. Swappable bands in multiple colours

c. Activation key

d. User manual

e. Charger and cable

f. Customer care details

g. Warranty card

------------ End of Document ------------

rfp mts security solution 1-10-2013.pdf

Documents

proposal rfp

confidential basis

mts security solutions

solution specific information

shyam group of india

list of sstl assets

response confidentiality

confidentiality provisions