Embed Size (px)
Citation preview
Name: ___________________________ Date: ____________________
Requirements:
Based on the “RFP” given in subsequent pages:
1) Please explain what service is required by the RFP.
2) Please present the system architecture for the proposed ICT Platform (onlydescription on logical entity is required). Please highlight the types of protocolsyou will be proposing and present your proposal accordingly.
3) Please present 5 main features that could be delivered, and how they could bedelivered.
4) Please present 5 features that could not be delivered, and explain accordingly.
5) Please present the “Table of Content” for the technical proposal to besubmitted.
Note:
There is no “perfect answer” to these questions. The objectives are to access:
The approach adopted by the candidate in responding to technicalrequirements (even those that are not familiar to them);
The approach adopted by the candidate in problem solving; The level of confidence in problem solving; The level of proficiency in system knowledge; The level of proficiency in applying existing knowledge.
Request for Proposal
For
In Call Tone (ICT)
Table of Contents
1 Objective .............................................................................................5
2 Introduction.......................................................................................5
3 Information........................................................................................6
3.1 Product overview Documents ................................................................................... 6
3.2 Call/message flows ........................................................................................................ 7
3.3 Vendor Road Map & Commercial References .................................................... 7
3.4 Product Documentation ................................................................................................... 7
3.5 Project plan & Project management...................................................................... 7
3.6 Training and Training Material ................................................................................. 7
3.7 Infrastructure requirements...................................................................................... 7
4 Scope of the project....................................................................8
4.1 Proposed ICT network Architecture ....................................................................... 8
4.2 Solution overview ............................................................................................................. 10
4.3 End user interfaces .......................................................................................................... 11
4.4 Integration Required................................................................................................... 12
4.5 Statistic server ............................................................................................................. 13
4.6 Test bed ............................................................................................................................ 13
4.7 Data migrations ............................................................................................................. 13
6 Capacity requirements ............................................................13
6.1 Expected License model and capacity requirements................................... 13
7 Other Requirements..................................................................14
7.1 Redundancy..................................................................................................................... 14
7.2 Hardware Requirements............................................................................................ 14
7.3 OS and 3rd party software requirements........................................................... 14
7.4 Backup and Recovery ................................................................................................. 14
7.5 System Security ............................................................................................................ 15
7.6 Test equipment.............................................................................................................. 15
7.7 Miscellaneous.................................................................................................................. 15
8 Operation and maintenance ................................................15
8.1 Centralized Admin GUI .............................................................................................. 15
8.2 Alarm Monitoring & Log Reports ........................................................................... 17
8.3 Statistics and Reports ................................................................................................ 18
8.4 Customer care................................................................................................................ 19
9 Support and maintenance ....................................................19
9.1 Service Level Agreement (SLA)s........................................................................... 19
9.2 Support Services........................................................................................................... 21
9.3 Spares................................................................................................................................ 23
9.4 Audit Reports/RCAs ..................................................................................................... 23
9.5 Changes Requests........................................................................................................ 23
10 Technical contacts ...................................................................24
1 Objective
The purpose of the RFP is to request the vendor to provide technical and commercialproposals for the ICT installation together with the additional features required. Theproposed solution is intended to replace the current ICT system and the bidders areexpected to match current end user experience for both pre paid and post paidsubscribers.
Vendors need to implement the ICT application logic using VXML standard 2.0communicating with Operators existing IVR systems and are free to propose a suitablearchitecture capable in operating with Operator’s multi-vendor core network. Short listedvendors will be invited to do a PoC. If the PoC is successful, Operator will enter into acontract with the vendor to procure the system. If the PoC fails, next vendor will beinvited to do a PoC. Venders who are willing to do a full capacity PoC (load testing usinglive traffic) will be placed at an advantage.
The commercial proposal should be on pure revenue share basis and bidders need topropose their intended revenue share component. The necessary servers for the systemwill be provided by Operator.
2 IntroductionOperator a leading mobile operator serving over 1 million subscribers through itsunmatched and superior quality coverage. Coupled with its portfolio of innovative VASproducts, it has consistently strived to provide the best of services always. In recognitionof this, Operator has been the recipient of GSM Global Awards for four consecutive years.
Operator has continuously introduced VAS for its clientele such as PRBT, Call Screening,Missed Called Alert, USSD Call-back, Welcome SMS, Optimal Routing, IVR based servicesand Pre-paid Roaming.
Operator launched ICT (In Call Tone) service in 2005 to broaden the revenue drivers andas a step towards improving the ICT feature Operator intends to replace the currentsystem with a more robust and feature rich system with VXML as the primarycommunication protocol.
With ICT service customers have the facility to add personalized tones according to thereinterests in the midst of conversation to spice it up which results in the potential increasein call frequency & duration thus contributing to increase revenue. This RFP is intended tolayout Operator’s technical requirements for the platform replacement.
Proof of concepts
Vendor should provide the proof of concept with features as specified on above technicalsection under following categories. Also having full capacity system (trial) on proof ofconcept would be an added advantage for the vendor
Non Committed (Commercially) Trial Demo setup Site visit
Answering structure
Vendor should use the below Table 1.2 compliance matrix format whenproviding their responses. In case of any additional features (if there’s any) pleasemention them separately. Also should fill the vendor compliance column in the Systemrequirements (Table 1.2) by using following tags (in Table 1.1) to indicate the degree towhich the proposals comply with the requirements.
COM The function is in the standard system (Compliant)
ALT An alternate method is used to support this function (explain indetail)
MOD The function could be met by the standard system by makingsuitable modifications
NA The function will not be supported by the proposed software
NV Available in the next version*
Table 1.1 - * Time of the availability of the version should be clearly defined.
Any further remarks can be indicated in the Comments column. Any entry left blank willbe deemed to have answered with a “NA” response. Reference to detailed explanationsshould be Specified with the document no, the particular section and the page number.Unless it will be deemed to have noted that no details supplied.
VendorCompliance(COM + Offered,COM + OptionalALT, COM + NotOffered,MOD, NA, NV)
Feature is offered or notoffered, in the case ofoffered need to mentionwhich phase (Phase 1or phase2), In the caseof Next version - shouldmention the exact timelines
Comments/Description(Answers ofinformationrelatedclarifications)
1 Clients
1.1 Please submit theInstallable/Embedded clientlist
COM Offered + Phase 1 NokiaN73,Nokia6680 & etc,.
1.2 Client list offeredto Operator in theinitial clientpackage
2. HardwarePlatform
2.1 Etc,.
Table 1.2
“COM + Optional’ items should price separately in the price quotation and clearly should listif those optional items included in the hosted model
3 Information
Vendor should provide the information requested under this section
3.1 Product overview Documents
Vendor should separately provide detailed documents about product & its components(separately annexed in the response)
3.2 Call/message flows
3.2.1 Vendor should provide following calls/message flows very clearly under eachcall scenarios
3.3 Vendor Road Map & Commercial References
3.3.1 Vendor Road Map
Vendor should provide Product Road map documents with target time lines
3.3.2 Commercial references
Provide a detailed list of references / case studies for each of the proposedsolutions in following categories.
3.3.2.1. Trial network references.3.3.2.2. Commercial network references.3.3.2.3. Inter Operability Test (IOT) references in terms of integration with
different vendor nodes.
3.4 Product Documentation
Vendor should provide product specification documents and the administration manualsand mention the number of copies that will be provided.
3.5 Project plan & Project management
3.5.1 Include the project plan to implement the solution and mention the numberof weeks to implement the system from the date of contract signing. vendorshould provide Gantt chart detailing key milestones.
3.5.2 Provide details of the project management team along with the teammembers’ relevant experience and the hierarchical arrangement. Thereshould be one contact point for all issues relating to the implementation.
3.6 Training and Training Material
3.6.1 Pre UAT on the job training - Provide the following with regard to the basicjob training before the UAT (Documentation should be provided for all thetrainees)
3.6.1.1 Number of persons (maximum)3.6.2.2 Location of the training3.6.3.3 Number of days & course content
3.6.2 Post UAT professional training - Professional Training & documentation(Documentation should be provided for all the trainees)
3.6.2.1 Number of persons3.6.2.2 Location of the training3.6.2.3 Number of days & course content
3.7 Infrastructure requirements
3.7.1 All servers required for the implementation will be provided byOperator.
3.7.3 E1 connectivity, signaling connectivity will be managed by OperatorIVR server
3.7.2 Vendors ICT solution need to interface with Operators IVR servers viastandard VXML 2.0
4 Scope of the project
4.1 Proposed ICT network Architecture
Fig 2.0 – Propose Operator ICT Infrastructure
4.1.1 Vendor should provide basic overview of ICT solution
4.1.2 Vendor should map his product components by carefully observing proposedICT network architecture proposed under Figure 2.0. Vendor shouldanalyze and study existing ICT network setup.
4.1.3 Vendor should mention reasons for proposing above components to map theexpected solution as depicted in fig 2.0 (Both advantages anddisadvantages should specify)
4.1.4 All applications should interface with Operator’s IVRs over VXML standard2.0
4.2 Solution overview
A Party will dial B number adding a prefix to the B, so that the dialed number format willbe <Prefix><B PARTY NUMBER>. Then ICT call would be forwarded the request to theICT platform. Platform would validate the sender, receiver and appropriate profiles will beloaded from the ICT application via VXML protocol, with channels allocated for the 2 DTMFlegs. Then the call would route back to the receiver via the same MSC after confirmationfrom the ICT platform.
4.2.1 ICT call dialing prefix will be specified by Operator. Then the ICT system should beable to handle for any prefix specified by Operator.
4.2.1 Platform should be able to bridge the call to the B Party and A party to use the ICTservice.
4.2.1 ICT platform should be able to extract A and B Party numbers and retrieves relevantcustomer profiles for each of them via VXML from the ICT application server.
4.2.1 Operator should be able to enable/disable ICT call access to A party Operatorsubscribers according to given number range, wildcard or for a specific number. Anyadditions or deletions on the list should be updated without restarting the system.
4.2.1 If A or B party or both do not have their own profile created, they should beattached to a common default profile (if necessary) and this default profile will be definedby Operator.
4.2.1 Operator should be able to enable/disable and edit default profile feature any timewithout system restart.
4.2.1 Customer will be able to create his/her own profile through IVR/Web interface.
4.2.1 At own profile creation Operator should have the option to either make available anew blank profile to the user or if required give a copy of the current default profile (withthe current tones/songs in default profile and the key settings) as the initial user profile.But if the latter is done for tone/songs in the new profile the existing validity periods willbe applicable and if the tone/song expires user will be charged for reordering (initiallyonly the current tones will be attached to user profile free of charge).
4.2.1 User should have the option to delete his/her own profile where the default profile isassigned thereafter.
4.2.1 Operator should be able to maintain a black list for default profile access for B partyaccording to a given number range, wildcard or for a specific number. Any additions ordeletions on the list should be updated without restarting the system.
4.2.1 Operator should be able to define, enable/disable tone request and backgroundsong keys (e.g. 1-9).
4.2.1 Operator should be able to assign few of selected tone keys (which is defined onrequirement 5.1.4) with few of selected tone IDs for the Operator default profile.
4.2.1 Operator should be able to assign few of background songs (with Ids) to Operatordefault profile (if necessary).
4.2.1 Background song playing should be activated, only when A party makes anactivation request while on the ICT call conversation.
4.2.1 Background song playing should stop playing, once the user sends a song playdeactivation request while on the ICT conversation
4.2.1 During the conversation both A and B must be able to initiate tone requests as onthe user profile or default, unless the feature is blocked for that party.
4.2.1 Only A party should be able to activate and deactivate own background song, andB party should be barred for this facility, even if B party has own song lists for his/herprofile.
4.2.1 Platform should be able to play current tone/song list requests made by both A & Bfrom the time when A/B party profile is modified if done so.
4.2.1 A party should be able to activate another play list, while different play list isrunning on the ICT call conversation.
4.2.1 A party tone/song list request key press should be suppressed for B party leg andonly relevant tone or song list granted must be heard.
4.2.1 Operator should be able to define the system acceptable duration for granting twotone/song list requests. Any request during the specified duration will be rejected by thesystem.
4.2.1 If either party makes tone request, while platform is playing song list, systemshould hold the song play and grant the tone request. Only after completion of toneshould the song list resume.
4.2.1 Vendor should specify the noise factor introduced by the ICT server in the voicepath.
4.2.1 ICT server should detect multiple profile-loading requests for a single party profile(one MSISDN) as a ICT call conferencing scenario or as multiple calls of which some callsare on hold and provide solution addressing both issues.
4.2.1 Any other additional features that the vendor wishes to add should also be stated.
4.2.1 The communication protocol between ICT application node(s) and Operator IVRsshould be standard VXML version 2.0
4.3 End user interfaces
4.3.1 Accessing through IVR
4.3.1.1 The IVR should be accessible through a short code, which will bedefined by Operator.
4.3.1.2 When a user accesses the IVR, user will be given an option to createhis/her own profile. Operator may decide to automatically create a profile atthe first time IVR access at our discretion.
4.3.1.2 Once the user creates own profile, user will be able to downloadsongs or tones from the list of on-shelf tones and assign tones for thephone keys.
4.3.1.3 User should have the option to delete own profile & go back to usingdefault profile if he/she wishes.
4.3.1.4 User will be given an option to add (from downloaded songs) orremove songs to his/her own song play lists.
4.3.1.5 User will be able to play Operator on-shelf tones, or userdownloaded tones with an option on the IVR menu.
4.3.1.6 User will be able to reorder expired Tones or Songs or delete them.
4.3.1.7 User will be given an option of downloading tones/songs by enteringtone/song ID, by scanning through the entire on-shelf collection
4.3.1.8 Tones or Songs will be categorized by Operator or, by scanningthrough the top contents, with most popular songs/tones.
4.3.1.9 User should be able to specify whether it is tone or song downloadwhile down loading.
4.3.1.10 If the IVR is designed and developed by the vendor there should bereports generated for hits to each and every option.
4.3.1.11 There should be a flexibility to modify the IVR according to populardemand or marketing requirements.
4.3.1.12 The IVR files should be hosted separately in IVR application serverand interfaced with the Operators IVR via standard VXML 2.0
4.3.2 Accessing through Web
4.3.2.1 User should be able to login to ICT web page through Operator home page.
4.3.2.2 User accessed Operator WEB URL for ICT (who do not have a personal profile),will give an option to create his/her own profile. Also Operator can decide to have anoption of automatically creating a profile at the first time URL access at our discretion.
4.3.2.3 Once the user creates own profile, user should be able to download songs andtones from the Operator on-shelf list.
4.3.2.4 User should have the option to delete own profile & go back to using defaultprofile if he/she wishes.
4.3.2.5 User downloaded tones must be able to assign for phone keys.
4.3.2.6 User should be given an option to modify/delete keys for the tones.
4.3.2.7 User should be able to play available tones (as an option on the web page),which are on the Operator shelf or on the user profile.
4.3.2.8User should be able to reorder expired Tones or Songs or delete them.4.3.2.9 User should be given an option of downloading songs by entering tone or songID, by scanning through the entire on-shelf collection
4.3.2.10Tones or Songs will be categorized by Operator or by scanning through thetop contents, with most popular songs/tones.
4.3.2.11 When down loading user should be able to specify whether itis tone or song download.
4.3.2.12 User should be able to search for Operator on-shelf contentby artist name etc
4.3.2.13 User should be able to sort web content according topopularity, freshness etc.
4.3.2.14 Flexibility should be there to modify the web interface byOperator.
4.4 Integration Required
4.4.1 Operator IVR platform(s) via VXML 2.0
4.4.2 SMSC (SMPP) for SMS interface
4.4.3 USSD via vxml to implement USSD end user interface
4.4.4 Charging gateway to implement event based charging
4.4.5 Centralized authentication api for end users (MyOperator)
4.4.6 Centralized authentication api for customer care agent (Active directory)
4.4.7 Centralized content management system
4.4.8 Centralized content management system (CMS)ICT system should be integrated
with Operators CMS in phase-2
4.4.8.1 ICT system should fetch actual content from CMS
4.4.8.2 ICT system should fetch all content meta data from CMS
4.4.8.3 All existing content in ICT system needs to be migrated to CMS during
integration
4.5 Statistic server
4.5.1 Statistic and reporting module (more details are under operation andmaintenance)
4.6 Test bed
4.6.1 ICT test bed is required which can be used to verify settings and do testingbefore applying it to the live system
4.7 Data migrations
4.7.1 Current ICT profiles in Existing ICT4.7.2 Where applicable vendor should provide detailed step wise data migrationplans:
Pre migration procedure During cutover procedure Post migration procedure
5. Content provider interfaces
5.1 Each and every content provider should have their own login to upload songs intoproper Categories.
5.2 Uploaded songs can only become Operator on-shelf after they are accepted byOperator.
5.3 Content provider should be able to set an expiry date for the content at the contentprovider interface.
5.4 Content provider should be able to play the song or tone after uploading.
5.5 Content provider API
5.5.1 A separate API over a standard protocol (eg:- SOAP) should be available to developcontent provider interface externally5.5.2 All content provider related functions should be available via the API5.5.3 Vendor shall provide detailed API specifications
6 Capacity requirements
6.1 Expected License model and capacity requirements
6.1.1 Operator will provide the necessary E1 capacity for ICT calls and IVR purposes.
6.1.2 Vendor shall provide initial customer profile capacity of 100,000 accounts andupgrade capacity when usage reaches 80%
6.1.3 System should run a periodic cleanup script to remove inactive accounts
7 Other Requirements
7.1 Redundancy7.1.1 System should implement redundancy on following arrears
7.1.1.1 Hardware
7.1.1.2 Geographical
7.1.1.3 Network
7.1.1.4 Power
7.1.1.5 Cable (Ex- Power and network)
7.2 Hardware Requirements
7.2.1 Operator will provide the necessary servers for the system.
7.2.2 Standard HP or SUN hardware will be provided.
7.3 OS and 3rd party software requirements
7.3.1 Preferred OS Linux/Unix based Operating systems7.3.2 Preferred Database – Oracle, Ldap, Mysql7.3.3 Vendor should include necessary Database and Operating system licensesand technical support for those7.3.4 Operating system needed to be hardened and should pass Operator
vulnerability tests
7.4 Backup and Recovery
7.4.1 Should support for automatic daily basis incremental backups, that saves allthe information kept in the system, includes user related information’s
7.4.2 Should support for the same tape utilized for incremental backups.
7.4.3 Detailed backup procedures should be provided under following categories
Backup Expectation
7.4.3.1 Configurations backup Last 10 configurationmodifications
7.4.3.2 User Profile Backup Weekly
7.4.3.3 CDR backup Daily
7.4.4 System should has tape backup module with necessary software to backupthe system
7.4.5 There should be a process to clean up the old log and expire duration shouldbe configurable from server sideAll log files should rotate in daily basis.
Old files should be renamed. Recommended name format – include what isI WN SMSC
7.5 System Security
7.5.2 Vendor should accept the network security recommendation suggest byOperator and finally system security should certified by Operator beforesystem acceptance
7.5.3 Solution should pass the security vulnerability test carried out by Operator
technical team before final technical acceptance . Details of test tools can
be provided
7.5.4 If vendor is proposing windows servers then such servers should be installed
with virus guard. Virus guard should be updated form the repository and a
full system scan should be scheduled every week
7.5.5 All External web and mail connections has to be made via Operator reverse
proxy and mail relays and there shouldn’t be a direct connections to System
through internet
7.5.6 Admin GUI web service should run in separate port by having separate web
instance
7.5.7 Customer care web service should run in separate port by having separate
web instance
7.5.8 Static/Dynamic NATs to public IPs are not supported
7.6 Test equipment
7.6.1 Vendor should provide all test equipment including test phones and test
SIMs
7.7 Miscellaneous
7.7.1 Every network element should time synchronized against Operator timing
servers (based on NTP protocol) and all logs should have this time stamp
7.7.2 SSH and SFTP should be enabled in all servers
7.7.3 For all music content related services offered – as applicable, an audio
signature should be appended to all the audio files to maintain sound quality.
An application would be provided by Operator which appends a 20 Hz signature to
the wave clip. This would be detected by the Voice quality enhancement devices
installed in the Operator network. And any level control, background noise
reduction etc. would not be performed on the wave clips as it does for a normal
call.
8 Operation and maintenance
8.1 Centralized Admin GUI
8.1.1 Administrator should be able to start/stop applications at any given time.
8.1.2 Administrator should be able to create different levels of user logins for system touse.
8.1.3 Configuring different components in the system should be done through singleAdmin GUI
8.1.4 To minimize the system downtime, any system configuration changes done by thesystem administrator should be updated online (no system restart) (eg. Blocking for Bparty DTMF to play a default tone based on country code, operator code or for a givennumber).
8.1.5 ICT server should run auto recovery process when applications malfunction.
8.1.6 Under any circumstance if ICT server is down it should reject prefix based calls.
8.1.7 System should have proper number analysis scheme to dispose garbage B numbersbefore processing.
8.1.8 Only one level of authorized user should be able to accept/decline content provideruploaded songs/tones
8.1.9 The operator should have the flexibility to categorize songs & tones on shelf at hisdiscretion.
8.1.10 The operator should be given an interface to handle customer complain scenariosthrough an appropriate login. For example to check/verify whether a particular MSISDNhas its own profile or tone/song pool content, key assignments made, song play listcreated and expiry of tones/songs for the user and a history log for user modifications tohis/her profile.
8.1.11 By default on shelf song/tones should not expire, but option to setting an expirydate option must be given.
8.1.12 At any given time, Operator should be able to remove tones/songs from theOperator on-shelf tone/song profile. But tones that were previously downloaded by usersshould be able to be played until they expire for that particular user.
8.1.13 If Tones/Songs are not already removed from the operator on-shelf, users shouldbe able to renew expired tones, which are on their profile.
8.1.14 If any of a tone/song is not on-shelf at Operator, tone renewal option must bedisappeared or disabled from user profile to reorder the specific tone/song after it expires.
8.1.15 System should be able to notify the user with a SMS, once their downloadedtone/song is expired. Actual messages and when to send the message should beconfigurable by administrator.
8.1.16 Daily basis system process is needed to set an expiry flag for each expiredTone/Song. But those expired Tone/Songs settings should not be removed from userprofiles (e.g. key assignments for tones which was set before the expiry should remain asit is after reordering them, so that the user will have the same key settings, if he reordersthe tones).
8.1.17 Operator should be able to play a special message or send an sms, if user pressesa key for an expired tone. But it should not play the actual tone and the originator of thetone request should only hear tone. The special message will be decided and will be setby Operator. Only the requested party must hear the special message, it must be blockedto the other leg.
8.1.18 When the user request for a play-list activate command to play background songlist while on the ICT conversation, expired songs on the song play list can’t be played (butunexpired songs should be played), If all of the songs are expired on song- list, system
should have a option to play special message and send an SMS (if necessary) only to theICT call originator. The special message will be decided and should be able to set byOperator. Only the requested party must hear the special message, it must be blocked tothe other leg.
8.1.19 The system should be capable of handling each song/tone expiry date for each andevery MSISDN, which have been downloaded, based on song/tone validity period definedon the Operator on-shelf profile.
8.1.20 If a song/tone is off shelf and validity periods are expired for all users,administrator should be able to delete the item from the ICT platform or automaticdeletion will activate.
8.1.21 When a Song/Tone is in expired state for user/s and it is moved off shelf, thereordering option should be made unavailable at the moment it is transferred off shelf.
8.1.22 Operator should be able to define time period to give the users to reorder on shelftone/songs before reordering option becomes unavailable.
8.1.23 Ability to set user accounts to expire globally or individually, if the user has notused the service for the specified time period.
8.1.24 Ability to set regular processors to check and provide a report if all the userstones/songs have expired or has not requested for ICT calls for a defined duration.8.1.25 Real time centralized interface to monitor the status of all elements in the ICTplatform
8.1.25.1 CPU Usage8.1.25.2 Memory usage8.1.25.3 System utilization
8.2 Alarm Monitoring & Log Reports
8.2.1 System should have a setup to store history of alarms, configuration
changes done to the system
8.2.2 Different Log level should be possible and this Log should in MIS
specifications
8.2.2.1 Debug
8.2.2.2 Notice
8.2.2.3 Error
8.2.2.4 Etc
8.2.3 Alarm should be categorized according to following
8.2.3.1 Critical – Service Interruption
8.2.3.2 Major - Service interruption to some extend
8.2.3.3 Minor - No service interruption
8.2.4 SNMP integration for remote alarm monitoring and system performance
monitoring. Following SNMP version should support
8.2.4.1 SNMP v1
8.2.4.2 SNMP v2c
8.2.4.3 SNMP v3
8.2.5 SNMP traps should send to Operator centralized network monitoring system
(OMC) and SNMP polling should be possible from Centralized OMC. Vendor
should provide sample MIB files.
8.2.6 All critical & Major Alarms should trigger Operator central Network
monitoring via SNMP
8.2.7 Describe the alarm indication mechanisms deployed for the operator to
inform operation team faster, more effectively and more accurately (Ex:- email
client, SMS messages).
8.3 Statistics and Reports
8.3.1 Call summary logs report should be provided for a given period. This shouldincludes number of tone requests sent by A, B, total tones sent by A and B, no of songplay list requests, type of profile used (personal or default) for each & every call, holdingtime, release causes, etc..
8.3.2 ICT call debugging logs should be generated for all successful/unsuccessful calls tofacilitate call-debugging process.
8.3.3 Detailed call reports should be generated for all successful/unsuccessful ICT callswith necessary fields. Operator should have flexibility to add additional required fields ifrequired.
8.3.4 Daily reports should be generated specifying no. of successful ICT calls, no. ofunsuccessful/rejected ICT calls with the causes, average holding times, ASR, etc..
8.3.5 Daily report with the following information should be created. Number of newprofiles created, down loads with top tones, songs, tone/song requests, and number ofdefault profiles & own profiles used. Also totals for a specified duration with above shouldbe provided (preferably as a graphical display if possible).
8.3.6 A graphical display for the usage of default profiles on operator wise basis and thetotals (E.g. Percentage of default profiles used by Operator customers) should beprovided for given period.
8.3.7 Daily basis profile usage report (default, personal) in respect to no of MSISDNs.(E.g. slabs of profiles 0-50, 51-100, above 100, will be specified by Operator). Also thecumulative figures (default + personal) must be given for daily basis and final total for thegiven period.
8.3.8 Ability to get a daily basis report on hit rate of each tone and song usage for a givenperiod
8.3.9 Prepaid, postpaid, activations via IVR or WEB activations report must be providedon daily basis and also the totals.
8.3.10 Report on number of tone and song downloads per given period. This shouldinclude break up for each tone, song, total tones and total songs figure (order by mostlydemanding song/tone with the total revenue for them).
8.3.11 Daily basis report on real time system E1 link utilization, ICT voice & IVR trafficcapacity for the specified duration.
8.3.12 Daily basis report for IVR usage with feature wise break up should be provided.
8.3.13 Appropriate error reports & alarms should be generated for all foreseeablescenarios.
8.3.14 Report for average number of calls per second (every hour of the day) and dailytotals on ICT platform calls for a given period. (Graphical display is preferred)
8.3.15 ICT server should have SNMP module to support SNMP compatible monitoring.
8.3.16 All reports and counters should be real time
8.3.17 Content providers analysis
8.3.18 Statistics on Capacity utilization.
8.3.18.1 Details on actual capacity utilization
8.3.18.2 Subscriber type wise break down on capacity utilization
8.3.18.3 Different levels of alarm when capacity utilization reaches different levels.
8.3.8 Flexible reporting engine for business intelligence
8.3.9 System should provide a ASCII log to extract statistics for MIS\Revenue assurancepurposes
8.4 Customer care
8.4.1 Customer care Interface should be a web based interface where differentuser levels are possible (mainly used for customer care purposes)
8.4.2 System shall not maintain user names and passwords of CC agents.Customer care module should be integrated with an Active Directory(centralized username and password database) and customer care agentsshould authenticate against Active directory user names
8.4.3User activity logging should be available
8.4.3.1 Viewing each user actions8.4.3.2Viewing login details8.4.3.3Quarrying CC history
8.4.5 Changing user profiles.
8.4.6 Customer care web service should run in separate port by having separateweb server instance.
9 Support and maintenance
9.1 Service Level Agreement (SLA)s
9.1.1 SLA Definitions
Vendor should agree to the classify faults and understand the response &resolution times as following definitions
FaultClassification
Description
9.1.2 Response and resolution times
Vendor should provide response time and guaranteed resolution times
9.1.2.1 Software issue
FaultClassification
Response TimeWorkaround to beProvided In
ResolutionTime
CriticalWithin TEN (10)Minutes
Within HALF ANHOUR (0.5) Hour
Within TWO (2)Hours
MajorWithin TWENTYFIVE (20) Minutes
Within ONE (1) HourWithin THREE(3) Hours
MinorWithin ONE (01)Hour
-TWENTY FOUR(24) Hours
InformationRequest
Within ONE (01)day
Detailed information to be provided withinFIVE (05) working days
9.1.2.2 Hardware Issue
FaultClassification
Response TimeWorkaround to beProvided In
Resolution Time
SL1 – Critical • Serious defect, problem and/or disturbance in the Value AddedServices, which is causing the Value Added Services severely disturbedor a severe performance degradation.
• A complete outage of any network system
• A significant number of customers (more than 40% of the total)experience service degradations or such potential.
• Users are unable to access the system or service
• Service security measures and controls have been compromised
SL2 – Major • System or application experiencing a service-affecting interruptionand there may be a risk of recurrence
• Service is still available, but one or more functions are unavailable
• Recent modifications to the system cause a critical service to operatein a way that is different from
1. That described in the Product Definition and
2. That accepted in User Acceptance Testing
• Fault which may cause Customer to suffer inconvenience inperforming regularly used functions of the Standard Software
SL3 - Minor • Problem has no measurable or perceivable business impact
• A fault that has no current impact on the Customer’s operations
• Immediate attention is not required and problems identified on an off-shift can wait until next day to be evaluated
• An acceptable workaround may exist, but permanent fix cannot bedeferred beyond target time
• Request for upgrades, new functionality or other changes which maynot be handled by the support team
• Immediate attention is not required
CriticalWithin TEN (10)Minutes
Within FOUR (04)Hours
FOUR HOURS (4)Hours
MajorWithin TWENTY (20)Minutes
Within SIX (06)Hours
SIX HOURS (6)Hours
MinorWithin ONE (01)Working Day
Within ONE (01)Working Day
TWO (2) WorkingDays
InformationRequest
Within ONE (01)Working day
Detailed information to be provided withinFIVE (05) working days
9.1.3 Exclusions to SLAs (if any)
Vendor is responsible for highlighting exceptions. Otherwise it isdeemed to have no such exceptions exists.For example support from 3rd party SW/HW vendor is required for finalresolution.
9.1.4 Escalation contacts for SLAs
Vendor should provide escalation levels as follows
9.1.4.1 Software services
Severity Level 1 -Escalation
Level 2 -Escalation
Level 3 -Escalation
Critical Immediately 1 Hour 2 hour
Major Immediately 1.5 Hour 3 hour
Minor Immediately 24 hour 48 hours
9.1.4.2 Hardware services
Severity Level 1 -Escalation
Level 2 -Escalation
Level 3 -Escalation
Critical Immediately 2 Hour 4 hour
Major Immediately 3 Hour 6 hour
Minor Immediately 24 hour 48 hours
9.1.4.3 Escalation contacts to be defined as follows
Escalation Level Name Phone Designation E-mail
1st level
2nd level
3rd level
9.2 Support Services
Vendor should confirm following support services are offered to Operator
9.2.1 Helpdesk/ 24x7 hotline
a) Helpdesk number for call logging (24x7)b) E-mail supportc) Web based call logging (optional if call logging is possible with b )
ExampleThe Help desk can be contacted as follows:
9.2.2 Procedure for 24x7 support
Vendor should provide for the procedure for 24x7 supports
a) opening support callsb) support responsec) update of call statusd) call closure etc ….
ExampleDuring Singapore working hours (9.00 – 6.00 SG time), telephone calls willbe answered by one of our Help Desk agents. They can log any new call;give you progress on already logged calls or put you through to the upperlevel engineer who is working on a logged call.
During out of Singapore office hours, all calls to the Help Desk will bedirected to one of the current support agent by phone. Upon which therelevant support agent will gather more information related to the problemor pass the query to a peer support agent or a next level engineer. Itshould be noted that only service effecting support calls (SL1 & SL2) shouldbe placed out of Singapore office hours.
Each call raised with the Vendor Help Desk will be assigned a faultclassification. The classification will depend on the nature of the call. Adescription of each follows. You should refer to these in order to decidewhat level you think is applicable. This will in turn help you to decide whichis the most appropriate method to use to log the call (email, telephone,fax).
9.2.3 Remote Support
If vendor is providing support remotely then connections to the system should bedone via a VPN (Virtual Private Network) System should support SSH (SecureShell) and SFTP
ExampleThere is a trained Customer engineer on site who is trained to performrestoration activities. The Purchaser provides Contractor access to dial intothe site via a dedicated phone line or an active internet connection such asVPN. And the necessary system backups are taken as recommended by thecontractor. The Restore Times are calculated from the moment Purchaserhas informed the Contractor’s Help Desk and logged a call about the defect,problem and/ or disturbance in the system and until the VALUE ADDEDSERVICES is back into operation and Commercial Service.
9.2.4 On site support
ExampleThere is a trained Customer engineer on site who is trained to performrestoration activities. The Purchaser provides Contractor access to dial intothe site via a dedicated phone line or an active internet connection such asVPN. And the necessary system backups are taken as recommended by thecontractor. The Restore Times are calculated from the moment Purchaserhas informed the Contractor’s Help Desk and logged a call about the defect,problem and/ or disturbance in the system and until the VALUE ADDEDSERVICES is back into operation and Commercial Service.
By phone +65 11 XXXXXXX
By email [email protected] fax +65 11 YYYYYYY
9.2.5 Emergency Support
If procedure for emergency support is different from above to be mentioned.
9.2.6 Software Support services
Section should cover minor version upgrades and bug fixes provided to Operatorduring the support period. These should be provided free of charge. Furthermaintenance for upgraded/bug fixed software to be arranged free of charge.
ExampleDuring the term of this Agreement Operator shall be entitled to a copy ofthe latest updates, patches, fixes, alterations and related on-linedocumentation of purchased modules of the current versions/releases freeof charge, and shall also be entitled to new modules, product upgrades,new versions/releases free of charge which Vendor publishes from time totime under and by virtue of the Principal Agreement.
The updates shall be installed by Vendor with permission from Operator inaccordance to procedures given to Operator by Vendor.
Operator may at its sole discretion purchase additional feature modules asavailable with Vendor.
9.3 Spares
Spares to be arranged by supplier or Operator. Critical spare list to be provided bythe vendor if spares are arranged by vendor. Spare replacement strategy to bestated if vendor is responsible for maintaining spares.
9.4 Audit Reports/RCAs
9.4.1 Periodic system audits on the system to be carried-out by the supplier9.4.2 System monitoring and health checks after service affecting system faults9.4.3 RCA to be provided for critical and major faults within 7 days since reporting
the call
9.5 Changes Requests
Allowed change requests under the contract and basis for pricing change requestto be identified.
ExampleDaily rates are applicable for Change Requests raised for all VendorSystems installed at Operator. No additional allowances to be paid otherthan the rates below. Number of man days has to be mutually agreedbetween Vendor and user division on case by case basis.
Resource Category Daily rate
Technical Engineers XXX USD
Technical Specialist XXX USD
Resource category definition
Resource Category Qualification CriteriaTechnical Engineer Technical Engineer
B.Sc. Degree from a recognized university/institution.Very Good experience in product development.3-5 years experience in Software Engineering.
Good technical knowledge in Telecommunicationproduct areas
Technical Specialist Technical Specialist
B.Sc. degree from a highly recognized university.3-5 years working experience inTelecommunication product development.Excellent knowledge in Telecommunicationconcepts and protocols.Experience in product design and architecture.
10 Technical contacts
For any queries with regard to the contents hereof, the vendor may contact any of thefollowing persons.
