RFP for SMSC Generic

_____________________________________________________________________

TECHNICAL REQUIREMENTS FOR SHORT MESSAGING SYSTEM (SMS)

FORTHE SUPPLY, DELIVERY, INSTALLATION, TESTING, COMMISIONING AND MAINTENANCE OF AN SMSC IN TELCO PROV CO

Technical Specification for Short Messaging System 1

_____________________________________________________________________

TECHNICAL SPECIFICATION FOR SHORT MESSAGING SYSTEM (SMS)

1 Introduction

1.1 Purpose

This document is the technical requirements specification for the provision of a Short Messaging System for TELCO PROV CO network.

1.2 Scope

This technical requirements specification is for the appropriate SMS system equipment, within TELCO PROV CO network.

2 System Requirements.

2.1 General

1. Specification Compliance

The SMS platform should be in compliance with the latest release of relevant 3GPP Specifications including:

2.1.1.1 3GPP TS 29.002 Mobile Application Part2.1.1.2 3GPP TS 23.012 Location Management Procedure2.1.1.3 3GPP TS 22.004 General on Supplementary Services2.1.1.4 3GPP TS 23.078 CAMEL Ph x, stage 22.1.1.5 3GPP TS 22.078 CAMEL service description stage 12.1.1.6 3GPP TR 23.039 SMS – SME2.1.1.7 3GPP TS 23.040 SMS Technical Realisation2.1.1.8 3GPP TS 23.142 VAS for SMS

The bidder shall also specify other specifications to which the SMSC complies.

2. Provision should be made to ensure that the system can be upgraded to comply with future revisions of the specifications. The Bidder must provide a roadmap showing their plans to adapt the system.

3. The SMSC shall be able to interface with Mobile Network Operator (MNO) MSC/GMSC/STP/other SMSC/etc for SMS delivery


_____________________________________________________________________

4. The SMSC shall be able to support receipt notification of SMS

5. SMS details record must be generated for all transactions containing date, timestamp, IMSI A, IMSI B, MSISDN A, MSISDN B, rate, location of A, location of B

6. The Bidder must describe this solution making reference to the following points:2.1.6.1 Nature of protocol used2.1.6.2 Information on how message routing to foreign operators

is implemented and information on addressing schemes and processes for address resolution

2.1.6.3 Statement regarding any interworking tests performed with other network nodes.

2.1.6.4 The SMSC must be capable of integrating with TELCO PROV CO’s prepaid service and provide pre-rating per message. Pre-rating is the ability to determine the charge for delivery of a message against a user's balance and if balance is insufficient the SMSC should refuse to accept the message.

The SMSC should also be capable of allowing certain numbers to send SMS even without credit or low credit. This application is for the usage of customer care agents. The maximum number of SMS sent by these numbers can be customised.

2.1.6.5 The SMSC shall also be capable of handling SMS packages that TELCO PROV CO might offer to subscribers for example free SMS, unlimited SMS for a fixed fee, etc

2.1.6.6 The Bidder must state the protocols used to support integration with prepaid platforms.

2.1.6.7 The SMSC must be able to integrate with the current billing system used in TELCO PROV CO

2. SMS core services and features

The SMSC should be able to provide the services listed below

2.2.1 Peer-to-peer SMS2.2.2 Any-to-peer SMS2.2.3 Peer-to-any SMS2.2.4 Any-to-Any SMS


_____________________________________________________________________

The intended usage capacity for the SMSC is 20,000 (twenty thousand) SMS per minute. This stated capacity must be upgradeable to support higher load.

3. SMS Architecture

2.3.1 SMS User Databases

2.3.2.1 The SMS user databases shall be capable of being integrated with existing TELCO PROV CO databases

2.3.2.2 The Bidder must describe their database architecture.

2.3.2 Message Type & Format

2.3.3.1 Other object types besides text that the SMSC can support should be described by the bidder.

2.3.3.2 The system should support all special characters and unicode charactersets like Chinese, Korean, Japanese , Thai etc. The number of characters per page for these SMSes must be specified by the Bidder.

2.3.3.3 The support of multiple-page (long – more than 160 characters) SMS and EMS is required. The bidder must specify the page size for multiple-page SMS

The Bidder shall describe any other features supported by their SMS platform.

4. SMSC Interface

2.4.1 General

2.4.1.1 The system shall be capable of interfacing to the TELCO PROV CO’s signalling gateway that is done over IP – M3UA.

2.4.1.2 The Bidder shall provide

a.i.a) A network diagram showing the various interface and protocol used by the system to interconnect to the Mobile network

a.i.b) State any proprietary implementation if any

2.4.1.3 The Bidder shall state:

a.a) The transfer protocol used between the client and the SMS Relay/Server


_____________________________________________________________________

a.b) What is required at the mobile network side to provide such connectivity

2.4.1.4 The Bidder shall also state if any such connection has been tested or commercially implemented

2.4.1.5 The Bidder must describe supported platforms.

2.4.1.6 The Bidder shall provide the list of terminals, PDAs, and/or other such devices where inter-operability test has been or will be conducted

2.4.1.7 The SMS platform supplier shall provide the system API to TELCO PROV CO so that additional applications could be built around SMS

2.4.1.8 The SMS platform shall provide the following interfaces:

a.a) SMPP, UCP, CIMD2, HTTP, HTTPS, etc for connection to external Application servers

a.b) Customized to connect to any external Application servers or Service Network where the Bidder shall provide the necessary API (e.g. Connection to the M-commerce Gateway etc)

a.c) Any other suitable interfaces as proposed by the Bidder

a.d) Text file upload

2.4.2 SMS Management

2.4.2.1 The SMSC should be able to provide prioritisation functions in order to prioritise certain SMS from others. The prioritisation should be fully customisable.

2.4.2.2 The SMS platform shall contain a database for the storage of the individual user profile for which the type will be proposed by the Bidder

2.4.2.3 The platform should support throttling function

2.4.2.4 The retry mechanism for SMS must be fully customisable according to conditions that will be set by TELCO PROV CO depending on business needs.

2.4.3 SMS Addressing


_____________________________________________________________________

2.4.3.1 The system shall support use of MSISDN (E.164) addressing scheme.

2.4.3.2 The System should support SMPP v3.4 and higher. Also, the BIND connection should support Tx, Rx and TRx.

2.4.3.3 The Bidder shall state if other types of addressing are supported, especially short dial codes. Also, it should support masking of sender ID with any alphanumeric string example: TelcoProvCo

2.4.3.4 The system should support Short Codes and Long Codes. Apart from the primary shortcode we require xx additional number (called Long codes) that needs to be routed to our connected application. We typically propose the range 32665-000 to 32665-040. However, we are open to use any other range like 3265-00 to 32665-040 or something else. It just needs to be in set of xx consecutive numbers.

2.4.3.5 The SMSC must be able to have restriction schemes to enable blocking of SMS sending to certain IMSI ranges (checking via SRI_SM or pre-defined list or any other methods), country codes and other criteria (MSISDN ranges, etc).

2.4.3.6 The Bidder shall state how the system resolves/translates address for delivery purpose for e.g. MSISDN to email or email address to MSISDN

2.4.3.7 This shall apply for both delivery of subscribers/addresses within the SMS-C and delivery/routing to a foreign SMS-C

2.4.3.8 The system shall support hiding of sender address i.e. anonymous messaging where the sender address is not shown to the recipient. This shall be definable on a per service class basis.

2.4.3.9 This system shall allow TELCO PROV CO to define on a per service class basis if anonymous SMS submission is allowed

2.4.3.10 At the same time, the subscriber shall also have an option to state if they want to receive anonymous SMS


_____________________________________________________________________

2.5 Security

2.5.1 General

2.5.1.1 The system should safeguard against unauthorised access to the system

2.5.1.2 The Bidder should highlight different access levels that can be assigned (e.g. for the operator, development and administrator)

2.5.1.3 A restricted version of the user/operator interface shall be developed for TELCO PROV CO’s 24-hour fault control centre to check the system operating status, view user profile and perform some basic operations to meet daily operation requirements.

2.5.1.4 For any user transaction executed, an audit trail should be captured. The system should allow TELCO PROV CO the flexibility to capture the type of desired information in logs that are opened and closed on a daily basis. The logs should reside on the system for a minimum of 7 days.

2.5.1.5 The system shall automatically purge expired audit log entries / files on a regular basis without user intervention.

2.5.1.6 Any unauthorized actions or login attempts should be logged in the audit trail log, and shall trigger an alarm with configurable priority. Only the system administrator should be allowed to change the logs.

2.5.1.7 If the system is made up of more than 4 Unix-based hardware platforms, NIS+ or LDAP should be set up with 2 main NIS+ or LDAP servers. This allows the administrator to maintain a centralized database of user/passwords at two servers. The Bidder shall propose NIS+ or LDAP or any other methods if applicable.

2.5.1.8 It must be possible for user account passwords to be configured with a preset lifetime e.g. 90 days. Upon expiry, the user shall be forced to change his/her password for access purposes.

2.5.1.9 The Bidder shall provide information on any IP security functionality supported.


_____________________________________________________________________

2.5.1.10 If firewall functionality is supported on the interface towards external PDNs, the Bidder shall provide information on its characteristics

3 Roaming and Interconnect Requirements

3.1 Since TELCO PROV CO is riding on MNO’s interconnect agreements, flexibility in routing is needed since SMS brokers are used.

3.2 TELCO PROV CO subscribers roaming in foreign countries will use TELCO PROV CO SMSC to send SMS

4 Platform Characteristics

4.1 General

The Bidder shall provide a general description of the platform of the tendered SMSC. This description shall include a description of the hardware and software architecture and design principles used

The platform must be fully modular and scalable necessitating zero downtime for capacity/hardware/software/application etc upgrades.

Modifications of routings, configurations and other operational aspects should be feasible during normal working hours.

4.2 Platform Characteristics

The Bidder shall provide company name and contact persons within other operators that have or will integrate the tendered equipment towards platform equipment from other Bidder(s)

4.3 IOT reports should be made available for the following equipment manufacturers

4.3.1 Ericsson NSS elements4.3.2 Alcatel-Lucent NSS elements4.3.3 Nokia-Siemens network NSS elements4.3.4 Huawei NSS elements4.3.5 Other equipment vendors’ NSS elements


_____________________________________________________________________

5 Operations and Reliability

5.1 General

5.1.1 The equipment hardware maintenance shall comprise of the following: 5.1.1.a.1 Preventive maintenance according to the Bidder's

handbooks and manuals5.1.1.a.2 Functional and technical monitoring with scheduled

measurements5.1.1.a.3 Fault location down to changeable units or PCBs

(Printed Circuit Boards) and change of such units or PCBs

5.1.1.a.4 Repair of equipment, which is not easily replaceable5.1.1.a.5 Functional control after repair or replacement of units5.1.1.a.6 Adequate spares to minimize recovery time

5.1.2 TELCO PROV CO technical personnel shall carry out maintenance on site.

5.1.3 The Bidder shall take this requirement into consideration in his offer on training courses, on the job training, documentation, test equipment and spare parts.

5.1.4 This requirement shall cover both hardware and software. Any units that are not field-repairable shall be listed out in the submission.

5.2 Operation & Maintenance

5.2.1 General Requirements

5.2.1.1 The operational and maintenance of the system shall include the following aspects: a) Power Requirementsb) Storage Requirementsc) Remote Access Requirementsd) Alarm Detection/Fault Clearing Requirements

Administration Requirements

5.2.1.2 Activity logging of all changes to any entity in the system must be implemented

5.2.1.3 The information to be logged shall at least include and not be limited to Data Changed, Subscriber and/or Operator Identity and Date/Time Stamp. This includes logging of activities for changes made by remote


_____________________________________________________________________

dial-in/telnet users that can only be disabled by a system administrator profile

5.2.1.4 The dedicated O&M functions and the associated O&M application functions shall be distributed among the network elements

5.2.1.5 The design of the O&M functions in all the network elements shall be user friendly and interactive with extensive computer on-line help facilities which will result in minimum reference to system handbooks or manuals

5.2.2 Power Requirements

5.2.2.1 All hardware modules within the system should be equipped with redundant power inputs

5.2.2.2 UPS will be provided by the data centre but the Bidder should state the power requirements (AC/DC, V, A, KVA, Watts) in order for the data centre to properly dimension the UPS.

5.2.2.3 For expansion purposes, the Bidder should provide a forecast of the amount of power needed for the next 2 years after commissioning of the system. The information should include, but not limited to the following: a) Type of power required : AC / DCb) Number of power point neededc) Power requirement of each power point expressed

as voltage requirements and current capacity

5.2.3 Storage Requirements

5.2.3.1 A disk-mirroring concept for data storage shall be applied

5.2.3.2 Automated backup e.g. in the form of disk/tape array shall be provided for all programs, system/user data for restoring the system

5.2.3.3 There shall be one medium of backup storage for both the system program and data. This is needed so that the O&M personnel do not need to maintain different storage media for backup/recovery purposes. There shall be one medium of backup storage for both the system program and data. This is needed so that the O&M staff do


_____________________________________________________________________

not need to maintain different storage media for backup/recovery purposes

5.2.3.4 Automated backup of system database, logs, billing data, etc for the system shall be provided. A procedure that describes the complete reloading from the backup storage medium to restore the system must be provided as part of system acceptance requirements

5.2.3.5 Redundancy should be made available in the form of disk duplexing of RAID 0, 1, 4 or 5 configuration

5.2.3.6 All HDD configurations must be configured with SCSI2/3 interface. When data redundancy is critical, RAID 0,1, 4 or 5 must be implemented

5.2.3.7 The complete restoration of the system from a raw hard disk should take less than 2 hours. A hot swappable hard disk implementation is preferred

5.2.3.8 Applications supplied with the system (such as any legacy support application) may require very large storage. The Bidder should state how large storage is to be provided on their SMS-C or associated application nodes.

5.2.4 Remote Access Requirements

5.2.4.1 The system shall be equipped with remote access functionalities.

5.2.4.2 The Bidder shall state the security measures employed for the remote access functionalities

5.2.4.3 The system can be left unattended and be maintained and operated from a remote site

5.2.4.4 All maintenance functions with the exception of work that requires human intervention shall be able to be carried out remotely

5.2.4.5 A GUI user interface shall be provided for ease of service administration remotely


_____________________________________________________________________

5.2.4.6 The SMSC should also be manageable using command line interface. The protocols supported shall be stated by the Bidder.

5.2.4.7 There should not be any need for the Operations staff to monitor the console or GUI for outage constantly

5.2.5 Alarms Detection/Fault Clearing Requirements

5.2.5.1 Upon detection of fault in any equipment, the system shall initiate an alarm (both audible and visual) automatically, and provide details of fault message in alarm log

5.2.5.2 For the hardware fault, the corresponding alarm shall indicate the location of the faulty equipment.

5.2.5.3 For software fault, the system shall report the faulty software functional module, and automatically attempt a recovery

5.2.5.4 The Alarms shall be classified into Critical, Major and Minor fault. A minor fault should never masked out a critical/major fault

5.2.5.5 There shall be a provision to send e-mail, page and route all alarms to TELCO PROV CO’s NMS for fault reporting (e.g. using SNMP)

5.2.5.6 Online and offline diagnostics shall be provided. The diagnostics shall be capable of testing, monitoring and evaluating the function within the device under the test. All diagnostics programs should not cause severe degradation to system performance. The activation of the diagnostics programs should not require any form of downtime

5.2.5.7 Hardware and software fault tracing facilities shall be provided in online and offline operation modes

5.2.5.8 If a major software malfunction is detected, an appropriate system restart shall be performed automatically

5.2.5.9 Where applicable, the system should generate a round-trip test call/packet on a periodic basis to ensure that the service is running correctly. The interval between


_____________________________________________________________________

successive round-trip tests should not exceed 1 hour, but not be so large as to allow service to degrade without detection

5.2.5.10 In the event that a UDP or TCP port becomes blocked, there should be facility available to clear the port without rebooting the system.

5.2.6 Administration Requirements

5.2.6.1 Data and management information on the system shall be collected by the system automatically

5.2.6.2 For Unix-based system, appropriate scripts should be set up via cronjob to automate all tasks

5.2.6.3 The system should provide the following information: a) System status: To indicate the equipment whether

is active, standby or out of serviceb) Operation Status: To indicate the active equipment

is busy, idle or out of servicec) System statistics: To indicate the number of

access, database overflow, database fragmentation where applicable. The data shall be presented in hourly intervals

5.2.6.4 All statistics collected for traffic measurement shall be automated and spooled via HP Openview/SNMP. The relevant MIB schema should be made available

5.2.6.5 The system shall automatically generate statistics reports in a presentation/tabulated format. The raw data should be exportable to an MS-Excel file or MS Access database or sent to an upstream performance management system

5.2.6.6 Data entries e.g. MSISDN/email addresses should be made via a GUI without modifying/recompiling the software code or shutting down and restarting the application. For bulk provisioning purposes, it should be possible to enter the data entries using a flat ASCII file import mechanism

5.2.7 Databases Control And Administration

5.2.7.1 The administration of subscriber databases consist of registration of new subscribers, updating of subscriber's


_____________________________________________________________________

attributes and all other functions associated with the subscription of the service. All these functions shall operate on the databases contained in the system. Where applicable, Administration shall also include the ability to reset a subscriber’s ID password

5.2.7.2 The system shall provide the functions for registration, viewing, deletion, and interrogation of subscriber profiles, details, status etc. the system shall log all activities and transactions and allow backup of these logs for later retrieval and for audit trial purposes

5.2.7.3 The means to carry out these functions shall be provided through workstations interface with the system through TCP/IP or any other protocols. The system shall also be equipped to link-up with remote workstations

5.2.7.4 The Bidder shall state whether remote link - up via dial up lines and leased lines/dedicated lines is supported

5.2.7.5 Provision must also be made to perform these functions remotely via a dedicated data link to a Customer Services Centre. The Bidder is to provide details of such a protocol. The Bidder shall ensure that the response time per transaction to every transaction initiated from a remote destination is less than 10 seconds

5.2.7.6 Details on the technical data and cost for the proposed protocol shall be provided for TELCO PROV CO’s consideration as an option. The Bidder shall also state the support of flash drives or any other media for mass updating of subscriptions status

5.2.7.7 The registration/modification function through command line interface shall allow for:

a) Activation/deactivation of the subscriptionb) Change of service plansc) Temporary suspension of the subscriberd) Deletion of the subscribere) Any other useful parameter(to be indicated by Bidder

5.2.7.8 The system shall provide the option for automatic/manual or batch activation/deactivation of subscriber(s), based on a specific number (e.g. IMSI, MSISDN) or a contiguous block of numbers


_____________________________________________________________________

5.2.7.9 The method of activation/deactivation shall be on-line and can be done remotely via Telnet or dial-up

5.2.7.10 The database architecture shall be designed with an open concept. Database access shall be given to the system administrator for him/her to perform read and write operations

5.3 Performance Data Collection, Measurement and Reports

1. The performance data collection and measurement contains functions for the evaluation of the usage of the system’s resources. The measurements and data collected shall encompass at least traffic, quality of service and timeslot availability

2. The system shall be able to generate reports on

5.3.2.a.1 Processor CPU utilization (max, min, average )5.3.2.a.2 Link usage5.3.2.a.3 Statistics on the volume of SMS for each service plan5.3.2.a.4 Subscriber profiles in a particular or combination of states5.3.2.a.5 Any other usage statistics

3. It must be possible for an external performance management system to collect the reports for subsequent storage and processing. The Bidder must state how this requirement is supported by their system

4. These reports shall be generated based on a configurable date or interval defined by TELCO PROV CO

5. The performance management functions shall include, but not limited to the following functionality:

5.3.5.a.1 Scheduling of measure5.3.5.a.2 Log measurements for post processing5.3.5.a.3 Defining of configurable thresholds and notifications5.3.5.a.4 Interfacing & forwarding measurement information to

an external network performance system5.3.5.a.5 Producing counters and gauges for the various

logical and physical entities5.3.5.a.6 Graphical display of measurement data5.3.5.a.7 Projection of system capacity5.3.5.a.8 System Change Operation & Control


_____________________________________________________________________

6. The system Change Operation & Control function shall enable the system operator to upgrade and reconfigure the system. This function shall include changes to system software (application software and operating software) as well as the hardware elements of the system, and the introduction of new system features.

7. A software/application/hardware upgrade should be done without any service downtime

8. The system change control function shall provide for the following:

1. System configuration administration2. Data acquisition for change operation3. System data administration

9. The Bidder is required to submit details on how this function is supported in the system

5.4 System Basic Design

5.4.1 Conservative worst-case design philosophy shall be adopted for all electronic equipment in the system so that a high reliability of equipment can be achieved and only demand maintenance is required. Comprehensive and extensive monitoring features shall be incorporated to ensure proper functioning of the system

5.4.2 Maintenance adjustment shall be easily accessible, preferably at the equipment front panel, and test points shall be provided for adjustment and measurement of operating parameters. Test equipment shall be able to be connected to all test points without degrading the system operation

5.4.3 The design of the equipment shall facilitate ease in preventive maintenance, testing, fault locating, and change of units and repair. Hardware fault clearance of all equipment shall be by means of plug-in units that may be replaced by non-specialist technician without further alignment

5.4.4 As a fundamental necessity, it shall be possible to carry out the maintenance work with no degradation of the system functions and without any safety hazard to the maintenance personnel

5.4.5 It shall be possible for units that are found or suspected to be faulty to be taken off-line for trouble-shooting and repair if necessary.


_____________________________________________________________________

Test equipment, tools and test program shall be provided to enable this to be carried out

5.4.6 All units shall be fitted with alarms indicator to permit rapid identification of a faulty unit. All alarms are to be logged to disk and routed to fault management via SNMP. Alarm logs shall be able to be filtered and manipulated for post processing

5.4.7 The database must be an industry standard and open architecture such as LDAP. The system administrator must have full rights to access the database schema for read and write purposes

5.4.8 The database shall employ high availability techniques and should be fully fault tolerant and fully redundant in design. No outages will be necessary for upgrades of software, OS, CPU, applications, etc

5.4.9 The database will be capable of acting as the central database that can contain common subscription information across all applications

5.5 Operation and Maintenance Spares

5.5.1 If spare parts or components are currently obtained under license or agreement from other company or companies, the Bidder shall state what measures or contractual obligations are in existence to guarantee for the continued supply of such spare parts or components, for the life span of the system

5.6 Test Equipment and Tools

5.6.1 The Bidder shall offer test equipment and tools for operation and maintenance support of the system. A list of the tools and test equipment offered should be submitted as part of the offer

5.6.2 All test equipment and tools shall be deemed to be part of the system and hence, shall comply with all provisions of the Specification wherever applicable e.g. service conditions, handbooks, spare parts etc

5.6.3 Provision of all test equipment and tools required for installation, testing and commissioning of the system shall be the Bidder's responsibility


_____________________________________________________________________

5.7 System Reliability & Availability

5.7.1 The system equipment including the computer software shall be proven in service and capable of operating continuously with a high degree of reliability. The Bidder is required to submit with their offer particulars of existing installations using the type of equipment offered

5.7.2 The system equipment including the computer software shall be proven in service and capable of operating continuously with a high degree of reliability. The Bidder is required to submit with their offer particulars of existing installations using the type of equipment offered

5.8 Redundancy and Backup

5.8.1 The system shall be designed for fail-safe operation

5.8.2 Redundant or backup equipment modules shall be provided so that the failure of an equipment unit in any major sub-system (e.g. processor, memory cards, magnetic disc etc.) shall not cause a total loss or degradation of that sub-system's function. Thus, a single equipment module failure in each major sub-system can occur without causing any loss in total operational capability. The degree of pre-wired redundancy or back-up arrangements shall be provided as follows

5.8.3 Dual redundant provision (i.e. one-to-one standby): This shall be provided for equipment in sub-systems which, if failed, would or may cause a total system or several sub-system break-down. Examples are CPU or computer and associated equipment memory modules, magnetic disc, magnetic tape unit, centralised switch matrix, rectifier, battery bank, and common power supplies, etc.

5.8.4 Partial redundant provision (i.e.1-to-N shared standby). This shall be provided for equipment, which has several identical units working in parallel and operating independently of one another. In the event of a major equipment failure, means shall be provided to reconfigure the system so that the failed equipment unit is removed from operational status and is replaced by its redundant or shared standby but operable counterpart. The Bidder shall list separately what equipment units are automatically re-configured and what equipment units are manually re-configured

5.8.5 Equipment status indicators that clearly indicate the on-line/off-line status of sub-systems or units shall be provided at the front panel


_____________________________________________________________________

5.8.6 Hardware and software control shall be provided for manual re-configuration. No physical connection/disconnection of cables shall be required for re-configuration. In other words, re-configuration should be pre-wired

5.8.7 The re-configuration time (i.e. the time between the detection of an equipment module failure and the resumption of complete operational capability) shall not be more than 15 seconds for automatic re-configuration and 5 minutes for manual re-configuration. The Bidder shall state the re-configuration time for the system offered

5.8.8 During re-configuration time, means for retaining the existing connection of line channels shall be provided. The Bidder shall guarantee that there is no loss of transactions during the re-configuration period

5.8.9 The Bidder shall give a detailed block diagram to show the items of equipment that are

5.8.9.a.1 Dual redundant with automatic change-over5.8.9.a.2 Dual redundant with manual change-over5.8.9.a.3 Provided with 1:N standby5.8.9.a.4 No standby

5.8.10 For case of No Standby, the Bidder shall state the reasons why no standby is proposed

5.8.11 The Bidder shall give a detailed description of the failsafe features which are provided in the proposed system

5.8.12 For proper system recovery and restoration purpose, the system shall have the provision to back up all databases to a central database store such as Legato or to storage media such as magnetic disc, magnetic tape or cartridge

5.8.13 Such backup shall be applied to, at a minimum, the following databases:

5.8.13.a.1Subscriber database5.8.13.a.2Critical system data5.8.13.a.3System date and time5.8.13.a.4Billing information.5.8.13.a.5Statistical information5.8.13.a.6System error logging information, if available


_____________________________________________________________________

5.8.14 Automated backup with 7 (or more) tapes in array shall be provided for all programs, system and user data for restoring the system, if TELCO PROV CO chooses physical backup

5.8.15 There should be one type of backup storage media for both the system program and data. This ensures that the Operations staff do not need to maintain different storage media for backup/recovery purposes

5.8.16 The disk mirroring concept for data storage shall be applied. Redundancy should be made available in the form of disk duplexing of RAID 0, 1, 4, or 5 configurations. A hot swappable hard disk implementation is preferred

5.8.17 All HDD configurations must be configured with SCSI2/3 interface or better. When data redundancy is critical, RAID 0,1,4,or 5 must be implemented

5.9 Reliability/Design Features

5.9.1 Parity And Validity Checks

5.9.1.1 Parity generation/checking and validity checking shall be provided on all data transfers within the system, as well as input into the system. The Bidder shall present a description, preferably in diagram form, of the check and alert arrangements designed into the system and, in connection herewith, indicate remaining risks for erratic information being presented without alert

5.9.1.2 Power Failure Power failure or out-of-tolerance power transients shall not induce any equipment module failures. Stored programs or system data shall not be altered in the case of a power failure or out-of-tolerance transient. The system shall automatically recover normal operations within 30 seconds after the resumption of normal power. The contents of volatile registers shall be stored in non-volatile registers when power failure is sensed, and they shall be automatically retrieved when power supply is restored

5.9.1.3 All hardware modules within the system shall come with dual power input. The Bidder should provide a list of the hardware modules that are not equipped with dual power input.


_____________________________________________________________________

5.9.2 Independence of Equipment Modules

5.9.2.1 Design of the system will be such that a component failure in any one sub-system or equipment module shall not induce a failure in another. Failures in a redundant element or sub-system shall not affect the system operation. It shall be possible to service, power on and off the off-line redundant equipment modules and sub-systems without affecting the operation of on-line equipment modules

5.9.3 On-Line Program Checks

5.9.3.1 The watchdog and diagnostic programs shall also maintain checks over all the redundant hot standby sub-system and an alarm shall be generated to indicate the faulty module

5.9.4 Protection Against Technical Failure Causing Loss or Distortion of Data

5.9.4.1 Facilities for protection of data stored in the system shall be provided aiming at full protection against technical system failures causing loss or distortion of data, especially data that are automatically renewed at a rate that makes a data loss less significant

5.9.5 Protection Against Detrimental Effects of Improper Operation

5.9.5.1 Loss or distortion of data, interference with system functions, etc. due to improper operation by maintenance personnel shall be prevented by suitable protection arrangements

5.9.6 Restoration Procedures

5.9.6.1 The latest version of the databases backup shall be utilised in the restoration procedures to properly and accurately restore the system to the point before the system malfunctioning. The time needed to perform the restoration procedures shall also be indicated in the submission

5.9.6.2 The Bidder shall be responsible to produce and supply a set of documentation with detailed step-by-step commands for the restoration and backup procedures


_____________________________________________________________________

5.10 Managed services

The bidder shall propose managed services team as one of the options in the proposal.

6 Element Manager & External Interface

6.1 Element Manager

6.1.1 Objective

The purpose of this section is to define the requirement of Element Manager System (EMS) for all Network Elements (NE) used / to be used by TELCO PROV CO. It provides the detailed view for each module required by TELCO PROV CO

6.1.2 Architecture

6.1.2.1 The EM shall be a separate machine/server from NE network; hence, the service of NE network shall not be affected in the event of EM failure.

6.1.2.2 It shall be scalable in order to support more than 1 NE network

6.1.2.3 Unix-based system is preferred.

6.1.2.4 The EM server shall be able to provide service extension to limited number of client, but shall not be lower than 5.

6.1.2.5 Dedicated links to be used between EMS and NE.

6.1.3 Alarm Management

6.1.3.1 Data Collection

a) EM shall actively collect/receive events/alarms from NE

b) All events/alarms shall be recorded in databasec) The database shall be able to handle current and

historical alarms


_____________________________________________________________________

d) Current alarm database shall hold all set of events/alarms which are not cleared or resolved

e) Historical alarm database shall hold all set of events/alarms, which have been cleared by system or manual.

f) In the event of data collection failure or any other failure related to it, a notification shall be triggered through e-mail, SMS or console output

6.1.3.4.2 Format

a) ITU.T X.733 Alarm format shall be usedb) Listed below are the important attributes

Attribute DescriptionManaged Object ClassManaged Object InstanceProbable CauseProbable Cause (name)Reservation StatusReservation TimeReservation User NameAcknowledgement StatusAcknowledgement TimeAcknowledgement User NameExpiration StatusAttribute DescriptionAdditional TextUser NoteNotification IdentifierCurrent Alarm IdCorrelated Notification FlagRepetition CounterPerceived Severity Critical, Major, Minor,

Intermediate, Warning, ClearFriendly NameSpecificProblemEvent DateEvent TimeClearing StatusClearing TimeAlarmType/EventType CommunicationAlarm,

qualityofServiceAlarm, equipmentAlarm, processingErrorAlarm,


_____________________________________________________________________

environmentalAlarm

The bidder might propose their own alarm format for consideration but TELCO PROV CO will reserve the rights to select the best format for operational usage.

6.1.3.4.3 Severity

a) A standard severity level shall be usedi) Criticalii) Major iii) Minoriv) Intermediatev) Warningvi) Clear

b) The severity level of events/alarms shall be easily

reconfigured based on the need of TELCO PROV CO

6.1.3.4.4 Graphical User Interface

a) A user friendly interface shall be provided for Alarm Monitoring

b) The attribute fields shall be easily selected or deselected from the view.

c) Filtering capability shall be available to enable user to views the interested events/alarms based on the attributes listed in 1.3.2b

6.1.4 Performance Management

6.1.4.4.1 Data Collection

a) EM shall actively collect performance counters from the Network Elements

b) In the event of failure in any of data collection process, alarms shall be triggered for notification

c) EM shall be able to collect all performance counter required by TELCO PROV CO

6.1.4.4.2 Report types must be configurable.

6.1.4.4.3 The bidder might propose report types that can be used with the SMSC


_____________________________________________________________________

6.1.4.4.4 According to business needs, TELCO PROV CO will request for additional report types without any commercial implications.

6.1.4.4.5 Threshold Setting

a) All principal performance parameters shall be assigned with threshold value

b) Threshold value shall be included in all related reportsc) EM shall actively perform test to check the level of all

principal performance parameters.d) In the event of threshold value is crossed, an alarm

shall be triggered to acknowledge the user.


a) A user friendly interface shall be providedb) Text and graph reports shall be available and selective

for the type of report outputs.c) The output reports shall be able to be save into file

6.1.5 Configuration Management

6.1.5.5.1 Data Collection

a) EM shall record the important system configurationb) A log file shall be available to monitor any

configuration changesd) In the event of failure in any of data collection

process, alarms shall be triggered for notification


a) A user friendly interface shall be providedb) Graphical method is preferred to view system

architecturec) User is allowed to enter comment or memo as

notification for each main component and sub-component

6.2 External Interface

1. Objective


_____________________________________________________________________

The purpose of this section is to defined the protocols and the methods that any EMS shall provide for TELCO PROV CO NMS modules integration 2. Architecture

3. The connectivity between EM and external OSS shall be using TCP/IP

6.3 Alarm Management

1. Protocol

1. Socket TCP/IP shall be used as the transport medium to forward / to pull events/alarms to / by external OSS

2. EMS is given the choice to behave as client or server3. Once TCP/IP connection is established, an application to

application shall take over for forwarding / pulling of events/alarms

4. It has the capability to restart itself if the service is down5. The heartbeat capability shall be available and duration of

heartbeat shall be easily configured

2. Format

1. The above mentioned attributes shall be included in every event/alarm

2. Space shall not be used as the separator for each field

3. Filtering

1. Filtering capability shall be easily turn on or off for the alarm forwarding

2. The specification for filtering should include the following as the parameter

a) severityb) eventTypec) probableCaused) specificProblem


_____________________________________________________________________

6.4 Performance Collection

1. Protocol

1. The performance data shall be made available in ASCII/text format file

2. The file shall be updated in hourly basis3. ftp, rcp and rsh functions shall be allowed to be used to

transferred the files in hourly basis

2. Format

1. The files shall be preceded with counter names2. The performance counter value shall be separated with

coma or semicolon

6.5 Configuration Collection

1. Protocol

1. The performance data shall be made available in ASCII/text format file

2. The time period to update the file shall be easily configured3. ftp, rcp and rsh functions shall be allowed to be used to

transferred the files in hourly basis

2. Format

1. The files shall be preceded with parameter names2. The parameter value shall be separated with coma or

semicolon

7 Charging and Billing Requirements

7.1 Charging

7.1.1 The system shall generate SMS detail records (SDR).

7.1.2 An SDR data logging facility for recording of both SMS/events together with the network resource usage data must be provided. The Bidder shall provide detailed description of each and every field in the SDR data record. The frequency for closure of the SDR files shall be configurable.


_____________________________________________________________________

7.1.3 There must be the ability to bill the recipient (MT billing) for messages sent from External Applications (e.g. email -> mobile). The External Applications Interface must support variable billing tariffs, i.e. the external applications interface must be able to send various configurable billing codes which can be translated to different prices.

7.1.4 There must be the ability to charge the subscribers based on the origin/destinations of the SMS. The origin/destinations of the SMS can be categorized by the following

7.1.4.1 Country7.1.4.2 IMSI range (configurable)7.1.4.3 SMS Broker used7.1.4.4 Any other criteria that are configurable7.1.4.5 Short codes7.1.4.6 Long codes

7.1.5 SDRs may be fixed length records in ASCII format and/or variable length call records in ASN.1 format. The Bidder shall include a detailed description of each and every field in the EDR in their response. The SDR files generated at the system shall be kept for at least seven (7) days after successful transfer to the upstream billing system.

7.1.6 Data integrity shall be monitored and the SDR generation subsystem shall include read after write features for error detection

7.1.7 The relevant hard disk unit shall be regularly monitored to ensure that it has enough storage capacity for storing the call data records

7.1.8 The billing subsystem shall generate an alarm when the storage threshold is reached .The Bidder shall submit details on how this requirement is met

7.1.9 The capacity of the hard disk units shall be sufficient to provide uncompressed storage for SDR files for at least three (3) days operation at full system capacity

7.1.10 It must be possible for the SDR files to be sent to more than one destination. Support for at least five destinations is desirable.

7.2 Backup Facility


_____________________________________________________________________

7.2.1 The billing subsystem must be capable of backup as part of the overall system backup. The Bidder must state that they can support such backup.

7.3 Support Facility

7.3.1 A system utility program for examining the contents of billing files stored on disk media shall be provided. The utility shall also allow the printing of the contents as displayed on the terminal.

7.3.2 Retrieval function using key parameters such as date, time, MSISDN, E-mail address or other parameters shall be provided to facilitate searching of call records stored on disk media. The Bidder shall provide details on the retrieval facility.

7.3.3 The billing subsystem shall provide a facility for an operator to check the transfer status various SDR files, whether they have been successfully delivered to the upstream system.

7.3.4 In addition, the billing subsystem shall provide a facility to generate SDR call records for testing and verification purposes.

7.4 On-Line File Transfer Distribution to External Systems

1. The Billing MD shall support the ftp protocol over the TCP/IP network to interface with the external systems. The Bidder can suggest other protocols for TELCO PROV CO’s consideration.

8 Software Requirements

8.1 The software to be supplied together with the hardware of the system shall consist of all the computer programs and associated software necessary for the operation, development and maintenance of the system as described in the Specification. The software required is divided into the following two categories: Support software and Operational software. The Bidder shall note that the term software in this RFP shall also include the associated firmware.

8.2 The support software shall be a package of application-independent software used in developing, testing, modifying and producing the system operational software. It shall also include software for processing, duplicating and verifying the system data files, and for maintaining, testing, checking and exercising the system hardware.


_____________________________________________________________________

8.3 The operational software includes all software used and developed by the Bidder to perform the functions of the system. It shall include, but not be limited to, workstation software, off-line application programs and software developed by the Bidder for the purpose of facilitating and simplifying the development and modification of the operational software.

8.4 Maximum use of adjustable system parameters (ASP) shall be employed to enable all system parameters to be readily changed by on-line commands or simple software patches. The latter method of inputting the ASP is not preferable as it may interrupt system operations. The Bidder shall submit a full list and detailed explanation of such ASPs in the submission. The Bidder shall also furnish detailed information on how these requirements are satisfied.

8.5 The operational software shall be provided with support tools that facilitate unit/module debugging, stabilisation tests and software debugging to achieve high quality software. It shall include, but not be limited to, the following support tools to:

8.6 Save and analyse information at a point where a fault occurs, in the system crash dump area during system on-line operation.

8.7 Select and trace the checkpoints of the system such as states, resources, etc. during system on-line operation.

8.8 The Bidder is required to furnish a detailed description on how the above requirements are met.

8.9 The system clock should not deviate from the standard GMT time by more than 1 second over a period of 1 month.

8.10 When multiple clocks are running over different hardware platforms/machines within the system, a NTP (network time protocol) daemon should be running to synchronize all clocks from a master server in either broadcast/multicast mode.

8.11 All system logs and subscriber transaction logs shall be configured such that they are limited to a configurable size and number. An automated log rotation mechanism shall be implemented to avoid file system full. A purge facility activated via cron should be in place to remove the expired logs automatically.


_____________________________________________________________________

8.12 The system should be equipped to allow the system administrator to monitor critical software operations in the system. Where applicable, there should be the presence of a heartbeat monitor program to assess that all processes are alive and functioning.

8.13 The system shall continuously execute checks at regular intervals to verify the availability of their resources such as:8.13.1 CPU utilization8.13.2 Memory utilization8.13.3 Disk space utilization8.13.4 Database utilization (e.g. overflow, page fault swapping,

fragmentation, etc)8.13.5 Channel/peripheral utilization8.13.6 File system utilization8.13.7 LAN utilization e.g.<1 % congestion8.13.8 Application statistics

8.14 Data and management information on the system shall be collected by the system automatically.

8.15 For Unix-based system, appropriate shell/awk/perl scripts should be setup via crontab to automate all tasks.

8.16 The operational software supplied shall cover the following functionality:

8.16.a.1 Data structure/schema of the files and tables, databases, indexes, triggers, rules, procedures.

8.16.a.2 Event and error logging facilities.8.16.a.3 Database maintenance and log files management.8.16.a.4 Backup/restore facility8.16.a.5 Recovering and restart processes8.16.a.6 Appropriate automated restart if a software

malfunction is detected.8.16.a.7 Online and offline diagnostics to troubleshoot

system malfunctions or failures.

8.17 The Bidder should provide details on how automated backup of the system elements can be achieved. Steps pertaining to the complete reload from the backup storage medium up to complete recovery should be provided.

8.18 Online and offline trace utility shall be provided to trace the activity of a transaction (e.g. deposit, notification, retrieval). Call interception or event triggers should be incorporated for hot-tracing purposes.


_____________________________________________________________________

8.19 The appropriate billing facilities with call tracing/transaction facility shall be provided. The subscriber records can be converted to a flat ASCII text format for reconciliation purposes.

8.20 The operational software should be free of memory leaks and should not require a warm/cold restart within 3 months.

8.21 Any unnecessary programs/processes that are not required as part of the functionality of the system should not be running under normal conditions, e.g.POP3, NFS, etc.

8.22 Tools for subscriber/service registration, modification, and deletion shall be provided. Tools and utilities for bulk job activation / deactivation / provisioning / deprovisioning should be provided. The Bidder should highlight the type of service provisioning interface to TELCO PROV CO’s provisioning system and the throughput supported over the interface.

8.23 The SMS provisioning system shall be able to control the provisioning based on services.

8.24 In the event that the system resides on the DMZ zone (e.g. Public Internet), the Bidder should indicate if the system has any firewall-like facilities to protect the system from illegal intrusion or hacking.

9 System Testing

9.1 General

1. The Bidder is required to perform tests for the system as specified in this Section. These tests form part of the acceptance requirements by which the Bidder shall demonstrate to the satisfaction of TELCO PROV CO that the system as installed fulfils the specified requirements of TELCO PROV CO

2. As part of the project, the Bidder shall submit a certification and acceptance test (CAT) plan and execute this plan in the presence of TELCO PROV CO staff. TELCO PROV CO must approve the CAT test plan

9.2 Types of Tests to be Included in the CAT Test Plan

9.2.1 System Tests


_____________________________________________________________________

9.2.1.1 The Bidder shall include system tests to verify that all requirements of the relevant SMS specification have been met. These tests shall be designed to cover the total system including the operational software.

9.2.1.2 The acceptance test cases should include but not limited to the following:

a) Automated heartbeat/monitor for any IPC/RPC communications.

b) Availability of visual and audible alarms on the various hardware platform(s).

c) Availability of visual and audible alarms at a remote site, e.g. 24-hour Network Control Center. Connectivity to NMS via SNMP/HP-OVO traps, events must be present

d) Backup and recovery of the system.e) Shutdown of the system.f) Warm/Cold/Reload of the system from root disk or

tape.g) Verification of the redundancy functionality.h) Verification of hot-swapping and load-sharing

functionality.i) Verification of interconnection to external nodes.j) Verification of end-user interfaces.k) Verification of database configuration and

environmental variables.l) Verification of operating system setup, including the

automatic purging of audit and error log entries.m) Verification of security and access controls.n) Breakage and resumption (synching) of disk

mirroring, etc.o) Elimination of database overflow pages,

fragmentation, etc.p) Freeing of system, database resources (e.g.

semaphores, monitors, flags) upon application shutdown. (e.g. ipcrm)

q) Software patching process.r) Verification on the accuracy of statistics,

performance measurements and other counters, pegs generated on the system.

s) Automation of all O&M tasks. This can be achieved either via cron-Unix or the Schedule Service-Win NT/2000.

t) Date change (bring forward /backdate)


_____________________________________________________________________

9.2.1.3 TELCO PROV CO may include additional test items to the acceptance test plans submitted by the Bidder. The Bidder should assist TELCO PROV CO to produce test procedures and test plans for those additional items submitted by TELCO PROV CO.

9.2.1.4 As part of the system test on site, a combined stability and subscriber test (including testing of software) shall be performed at the conclusion of all other items of site acceptance tests. All the system adjustments (including software) shall be made prior to the start of the test and no further adjustments will be allowed for the duration of the stability test. During the stability test, the system shall be subjected to normal operation and traffic capacity. All malfunctions, errors and failures shall be recorded. The length of time for this test shall be a minimum of 21 days continuously.

9.2.1.5 The system shall satisfactorily operate continuously without

a) adjustment, changes or part replacement of equipment,

b) changes to computer softwarec) interruptions, errors or malfunctions of equipmentd) Computer crashes due to software or operational

inputs.

9.2.1.6 If any unsatisfactory result is obtained within this 21-day period, the system shall be adjusted properly and accordingly and the test shall be re-started from then for a further 21-day period.

9.2.2 Maintainability Test

9.2.2.1 Tests shall be designed to prove the suitability of the diagnostics and applicability of all instructions in the technical manual provided by The Bidder. In particular, tests shall be designed to demonstrate the capability of failure isolation, repair and confidence checking to assure that the malfunction has been corrected and that the unit is available for operational use.

9.2.2.2 The tests shall also be designed to demonstrate the practicability and suitability of the preventive operation maintenance aspect of the system


_____________________________________________________________________

9.2.3 Test Plans and Procedures

9.2.3.1 The test plans and procedures shall include, at a minimum, the following:

a) Description and objective of the testb) Scope of testsc) Expected or desired resultsd) Criteria for successful acceptancee) Designation of all inputs that are required to test each

functionf) Test output records including a description of required

outputs, the types of equipment used to observe or measure the outputs, etc. As far as practicable, the input/output shall be expressed in measurable terms and the acceptable tolerances for each measurement shall be provided.

9.3 Facilities and Set-Up Requirements

9.3.1 Test Facilities

9.3.1.1 The Bidder shall provide all test equipment, tools, services and all other facilities required for the preparation, conducting and recording of all tests at its expense.

9.3.1.2 The Bidder should propose to supply a test system that allows the testing of patches and new software loads so as to minimize service disruption to the live system.

9.3.1.3 The Bidder should propose a list of tools and test equipment (hardware and software) for TELCO PROV CO to acquire for daily O&M activities

9.3.1.4 The Bidder should highlight which tools and test equipment are part of the offer and which are optional

9.3.1.5 Where applicable, the Bidder shall propose discounts for TELCO PROV CO to purchase the tools and test equipment.

9.3.1.6 The Bidder should highlight the possible non-intrusive points on the LAN/WAN interfaces for TELCO PROV CO to probe for IP traffic (SMTP, SMPP, etc) without causing system outage in any way.


_____________________________________________________________________

9.3.2 Responsibility of Quality Assurance

9.3.2.1 Notwithstanding any inspection, witnessing or observation of test by TELCO PROV CO representative(s) or any of its staff at any stage of the site acceptance tests, for full turnkey implementation, the Bidder shall be solely responsible for the quality of the system. For semi-turnkey implementation, the Bidder shall be responsible for the quality of the parts of the system that TELCO PROV CO is not responsible for.

10 Technology Evolution

10.1 Introduction

The purchased system will reside in the TELCO PROV CO network for several years to come. It is therefore important to have a picture on the future capability of the tendered system and possible future impact on TELCO PROV CO's network and business.

The Bidder is requested to provide any other information on the future of the tendered system that may be of importance to TELCO PROV CO that is not explicitly requested for below.

10.2 General

10.2.1 The tendered system shall be designed that new functions and services can easily be integrated into the existing configurations with a minimum of changes and disturbance of service.

10.2.2 Introduction of new functionality shall be introduced as software changes. Changes to the hardware shall be minimized.

10.2.3 The tendered system shall be designed that future ETSI, 3GPP, OMA or other defined services and functionality will reuse the platform and functions in the tendered system.

10.3 Product Roadmap

10.3.1 The Bidder shall provide a roadmap for the planned product evolution of the tendered system including the following information: - Description of upgrade (change/new function) - Reason for upgrade -


_____________________________________________________________________

Planned data/time of upgrade - Network element impacted - Nature of upgrade -hardware/software

10.3.2 The Bidder shall provide a roadmap for planned implementation and adaptation of new ETSI/3GPP/OMA defined services and functions that affect the tendered system.

10.4 QoS

10.4.1 The Bidder shall state the features that it will implement in the current and future releases of the platform to support QOS.

10.4.2 The Bidder shall introduce TELCO PROV CO to Content Providers whenever possible.

10.4.3 The Bidder shall state what sort of marketing assistance can be provided to assist TELCO PROV CO with development of the SMS business.

11 Support

11.1 The Bidder must agree to provide support free of charge during the warranty period

11.2 The Bidder shall be responsible to provide full support to TELCO PROV CO maintenance staff in maintaining the system such as software updates for faults found in the system, fault clearing due to design errors, etc. without any charges to be incurred by TELCO PROV CO.

11.3 Hardware maintenance must also be included in the offered support. The hardware can be sourced by TELCO PROV CO but the support agreement with the Hardware Vendor will be managed by the Bidder

11.4 During the warranty period of the system (both hardware and software), The Bidder shall establish a central point of contact to provide primary 24x7 on-call assistance to address troubles reported by TELCO PROV CO and to initiate corrective actions once a reported trouble is diagnosed as a problem.

11.5 The Bidder shall quote the yearly charges for the provision of expert assistance in maintaining the system, in hardware and software after it has been accepted by TELCO PROV CO and warranty has expired.


_____________________________________________________________________

11.6 Faults or issues shall be organised into three classes of severity: Critical, Major and Minor. TELCO PROV CO shall reserve the right to define the severity of the problem

11.7 Definitions are as follows

Category

Description Service Availability required

Penalty

Critical Affecting service (partially or completely)Affecting billingAffecting maintenance

99.99% To be finalised by TELCO PROV CO mgmt during meeting with the Bidder

Major Affecting administration, O&M To be finalised by TELCO PROV CO mgmt during meeting with the Bidder

To be finalised by TELCO PROV CO mgmt during meeting with the Bidder

Minor Affecting other aspects of the system To be finalised by TELCO PROV CO mgmt during meeting with the Bidder

To be finalised by TELCO PROV CO mgmt during meeting with the Bidder

11.8 Service availability will be calculated monthly based on the number of days of the month (28, 29, 30 or 31)

11.9 The Bidder shall provide the problem reporting procedure and the complete root cause analysis (RCA) of the problem

11.10 RCA for critical issues shall be made available 3 days after resolution. Preliminary RCA to be made available 24 hours after resolution

11.11 RCA for major issues shall be made available 5 days after resolution. Preliminary RCA to be made available 24 hours after resolution

11.12 RCA for minor issues shall be made available 10 days after resolution. Preliminary RCA to be made available 24 hours after resolution

11.13 Availability calculations are the following

Based on the statistics, call/SMS distribution is the following (not counting the weekends)- SMS during busy hours: 83.44%- SMS during non busy hours: 16.56%


_____________________________________________________________________

- There are 5.04 times more SMS per hour in the peak period compared to the non peak period

- 1 hour during the peak period is equivalent to 5 hours in the off-peak period

Peak hours are from 0800 until 2200

Since 1 hour during peak period is equal to 5 hours in the off-peak period, let’s consider the 10 hours during off peak period as 10/5 = 2 hours only. Meaning that the total hours per day is 14+2 hours = 16 hours. In a month (30 days), there will be 16 x 30 = 480 hours.

Outage scenario 1: 1 hour during peak periodOutage = 1 hourAvailability = 480 – 1 = 479 hoursAvailability percentage = 479/480 = 99.79%

Outage scenario 2: 1 hour during off-peak periodOutage = 1 => divided by 5 => 0.2 hourAvailability = 480 – 0.2 = 479.8Availability percentage = 479.8/480 = 99.95% Outage scenario 3: 0.5 hour during peak and 0.5 hour during off-peak periodOutage = 0.5 + 0.5/5 = 0.6Availability = 480 – 0.6 = 479.4Availability percentage = 479.4/480 = 99.87%

11.14 Procedures shall be valid during and after the guarantee period. Procedures shall include the response time and the time committed to rectify issues with all sub-systems of the system based on the assigned priority and severity ratings of the issues. Procedures shall also include escalation procedures to higher management if the reported problem is not resolved within the agreed and committed time frame.

11.15 The Bidder should provide 24 x 7 days hardware and software support for O&M support personnel in the event of service affecting outage/faults.

11.16 The Bidder should provide a scheme/methodology on how software patches are to be applied to the operating system, database and application

11.17 The methodology should contain details pertaining to how the patches are made available to the system till the complete application of the patch.


_____________________________________________________________________

11.18 The Bidder should notify the O&M support personnel of all critical/emergency patches that needs to be applied to the system as soon as possible


RFP for SMSC Generic

Documents

Transcript of RFP for SMSC Generic