_____________________________________________________________________

TECHNICAL REQUIREMENTS FOR SHORT MESSAGING SYSTEM (SMS)

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

Technical Specification for Short Messaging System

_____________________________________________________________________

TECHNICAL SPECIFICATION FOR SHORT MESSAGING SYSTEM (SMS)

1
1.1

Introduction
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
2.1 1.

System Requirements.
General Specification Compliance The SMS platform should be in compliance with the latest release of relevant 3GPP Specifications including: 2.1.1.1 2.1.1.2 2.1.1.3 2.1.1.4 2.1.1.5 2.1.1.6 2.1.1.7 2.1.1.8 3GPP TS 29.002 Mobile Application Part 3GPP TS 23.012 Location Management Procedure 3GPP TS 22.004 General on Supplementary Services 3GPP TS 23.078 CAMEL Ph x, stage 2 3GPP TS 22.078 CAMEL service description stage 1 3GPP TR 23.039 SMS SME 3GPP TS 23.040 SMS Technical Realisation 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. The SMSC shall be able to interface with Mobile Network Operator (MNO) MSC/GMSC/STP/other SMSC/etc for SMS delivery

3.

Technical Specification for Short Messaging System

_____________________________________________________________________ 4. 5. The SMSC shall be able to support receipt notification of SMS 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 The Bidder must describe this solution making reference to the following points: 2.1.6.1 Nature of protocol used 2.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 COs 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. 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 The Bidder must state the protocols used to support integration with prepaid platforms. The SMSC must be able to integrate with the current billing system used in TELCO PROV CO

6.

2.1.6.5

2.1.6.6 2.1.6.7

2.

SMS core services and features

The SMSC should be able to provide the services listed below 2.2.1 2.2.2 2.2.3 2.2.4 Peer-to-peer SMS Any-to-peer SMS Peer-to-any SMS Any-to-Any SMS

Technical Specification for Short Messaging System

_____________________________________________________________________ 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. 2.3.1 SMS Architecture SMS User Databases 2.3.2.1 2.3.2.2 2.3.2 The SMS user databases shall be capable of being integrated with existing TELCO PROV CO databases The Bidder must describe their database architecture.

Message Type & Format 2.3.3.1 2.3.3.2 Other object types besides text that the SMSC can support should be described by the bidder. 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. 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

2.3.3.3

The Bidder shall describe any other features supported by their SMS platform. 4. 2.4.1 SMSC Interface General 2.4.1.1 The system shall be capable of interfacing to the TELCO PROV COs signalling gateway that is done over IP M3UA. 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

2.4.1.2

Technical Specification for Short Messaging System

_____________________________________________________________________ a.b) What is required at the mobile network side to provide such connectivity 2.4.1.4 2.4.1.5 2.4.1.6 The Bidder shall also state if any such connection has been tested or commercially implemented The Bidder must describe supported platforms. The Bidder shall provide the list of terminals, PDAs, and/or other such devices where inter-operability test has been or will be conducted The SMS platform supplier shall provide the system API to TELCO PROV CO so that additional applications could be built around SMS 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 Mcommerce 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. 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 The platform should support throttling function 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.1.7

2.4.1.8

2.4.2.2

2.4.2.3 2.4.2.4

2.4.3

SMS Addressing

Technical Specification for Short Messaging System

_____________________________________________________________________ 2.4.3.1 2.4.3.2 2.4.3.3 The system shall support use of MSISDN (E.164) addressing scheme. The System should support SMPP v3.4 and higher. Also, the BIND connection should support Tx, Rx and TRx. 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 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. 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). The Bidder shall state how the system resolves/translates address for delivery purpose for e.g. MSISDN to email or email address to MSISDN This shall apply for both subscribers/addresses within the delivery/routing to a foreign SMS-C delivery SMS-C of and

2.4.3.4

2.4.3.5

2.4.3.6

2.4.3.7

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. This system shall allow TELCO PROV CO to define on a per service class basis if anonymous SMS submission is allowed At the same time, the subscriber shall also have an option to state if they want to receive anonymous SMS

2.4.3.9

2.4.3.10

Technical Specification for Short Messaging System

_____________________________________________________________________ 2.5 2.5.1 Security General 2.5.1.1 2.5.1.2 The system should safeguard against unauthorised access to the system The Bidder should highlight different access levels that can be assigned (e.g. for the operator, development and administrator) A restricted version of the user/operator interface shall be developed for TELCO PROV COs 24-hour fault control centre to check the system operating status, view user profile and perform some basic operations to meet daily operation requirements. 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. The system shall automatically purge expired audit log entries / files on a regular basis without user intervention. 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. 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. 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. The Bidder shall provide information on any IP security functionality supported.

2.5.1.3

2.5.1.4

2.5.1.5 2.5.1.6

2.5.1.7

2.5.1.8

2.5.1.9

Technical Specification for Short Messaging System

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

3
3.1

Roaming and Interconnect Requirements

Since TELCO PROV CO is riding on MNOs interconnect agreements, flexibility in routing is needed since SMS brokers are used. TELCO PROV CO subscribers roaming in foreign countries will use TELCO PROV CO SMSC to send SMS

3.2

4
4.1

Platform Characteristics
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 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 IOT reports should be made available for the following equipment manufacturers Ericsson NSS elements Alcatel-Lucent NSS elements Nokia-Siemens network NSS elements Huawei NSS elements Other equipment vendors NSS elements

Technical Specification for Short Messaging System

_____________________________________________________________________

5
5.1 5.1.1

Operations and Reliability

General The equipment hardware maintenance shall comprise of the following: 5.1.1.a.1 Preventive maintenance according to the Bidder's handbooks and manuals 5.1.1.a.2 Functional and technical monitoring with scheduled measurements 5.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 replaceable 5.1.1.a.5 Functional control after repair or replacement of units 5.1.1.a.6 Adequate spares to minimize recovery time TELCO PROV CO technical personnel shall carry out maintenance on site. The Bidder shall take this requirement into consideration in his offer on training courses, on the job training, documentation, test equipment and spare parts. This requirement shall cover both hardware and software. Any units that are not field-repairable shall be listed out in the submission. Operation & Maintenance General Requirements 5.2.1.1 The operational and maintenance of the system shall include the following aspects: a) Power Requirements b) Storage Requirements c) Remote Access Requirements d) Alarm Detection/Fault Clearing Requirements Administration Requirements Activity logging of all changes to any entity in the system must be implemented 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-

5.1.2 5.1.3

5.1.4 5.2 5.2.1

5.2.1.2 5.2.1.3

Technical Specification for Short Messaging System

_____________________________________________________________________ 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 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.1.5

5.2.2

Power Requirements 5.2.2.1 5.2.2.2 All hardware modules within the system should be equipped with redundant power inputs 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. 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 / DC b) Number of power point needed c) Power requirement of each power point expressed as voltage requirements and current capacity

5.2.2.3

5.2.3

Storage Requirements 5.2.3.1 5.2.3.2 A disk-mirroring concept for data storage shall be applied Automated backup e.g. in the form of disk/tape array shall be provided for all programs, system/user data for restoring the system 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

5.2.3.3

Technical Specification for Short Messaging System

10

_____________________________________________________________________ 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 Redundancy should be made available in the form of disk duplexing of RAID 0, 1, 4 or 5 configuration All HDD configurations must be configured with SCSI2/3 interface. When data redundancy is critical, RAID 0,1, 4 or 5 must be implemented 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 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.3.5 5.2.3.6

5.2.3.7

5.2.3.8

5.2.4

Remote Access Requirements 5.2.4.1 5.2.4.2 5.2.4.3 5.2.4.4 The system shall be equipped with remote access functionalities. The Bidder shall state the security measures employed for the remote access functionalities The system can be left unattended and be maintained and operated from a remote site All maintenance functions with the exception of work that requires human intervention shall be able to be carried out remotely A GUI user interface shall be provided for ease of service administration remotely

5.2.4.5

Technical Specification for Short Messaging System

11

_____________________________________________________________________ 5.2.4.6 The SMSC should also be manageable using command line interface. The protocols supported shall be stated by the Bidder. There should not be any need for the Operations staff to monitor the console or GUI for outage constantly

5.2.4.7 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 For the hardware fault, the corresponding alarm shall indicate the location of the faulty equipment. For software fault, the system shall report the faulty software functional module, and automatically attempt a recovery The Alarms shall be classified into Critical, Major and Minor fault. A minor fault should never masked out a critical/major fault There shall be a provision to send e-mail, page and route all alarms to TELCO PROV COs NMS for fault reporting (e.g. using SNMP) 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 Hardware and software fault tracing facilities shall be provided in online and offline operation modes If a major software malfunction is detected, an appropriate system restart shall be performed automatically 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

5.2.5.2 5.2.5.3

5.2.5.4

5.2.5.5

5.2.5.6

5.2.5.7 5.2.5.8

5.2.5.9

Technical Specification for Short Messaging System

12

_____________________________________________________________________ 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 5.2.6.2 5.2.6.3 Data and management information on the system shall be collected by the system automatically For Unix-based system, appropriate scripts should be set up via cronjob to automate all tasks The system should provide the following information: a) System status: To indicate the equipment whether is active, standby or out of service b) Operation Status: To indicate the active equipment is busy, idle or out of service c) System statistics: To indicate the number of access, database overflow, database fragmentation where applicable. The data shall be presented in hourly intervals All statistics collected for traffic measurement shall be automated and spooled via HP Openview/SNMP. The relevant MIB schema should be made available 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 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.6.4

5.2.6.5

5.2.6.6

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

Technical Specification for Short Messaging System

13

_____________________________________________________________________ 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 subscribers 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 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 The Bidder shall state whether remote link - up via dial up lines and leased lines/dedicated lines is supported 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 Details on the technical data and cost for the proposed protocol shall be provided for TELCO PROV COs consideration as an option. The Bidder shall also state the support of flash drives or any other media for mass updating of subscriptions status The registration/modification function through command line interface shall allow for: a) b) c) d) e) 5.2.7.8 Activation/deactivation of the subscription Change of service plans Temporary suspension of the subscriber Deletion of the subscriber Any other useful parameter(to be indicated by Bidder

5.2.7.3

5.2.7.4 5.2.7.5

5.2.7.6

5.2.7.7

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

Technical Specification for Short Messaging System

14

_____________________________________________________________________ 5.2.7.9 5.2.7.10 The method of activation/deactivation shall be on-line and can be done remotely via Telnet or dial-up 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 1.

Performance Data Collection, Measurement and Reports The performance data collection and measurement contains functions for the evaluation of the usage of the systems resources. The measurements and data collected shall encompass at least traffic, quality of service and timeslot availability 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 usage 5.3.2.a.3 Statistics on the volume of SMS for each service plan 5.3.2.a.4 Subscriber profiles in a particular or combination of states 5.3.2.a.5 Any other usage statistics

2.

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 These reports shall be generated based on a configurable date or interval defined by TELCO PROV CO The performance management functions shall include, but not limited to the following functionality: 5.3.5.a.1 Scheduling of measure 5.3.5.a.2 Log measurements for post processing 5.3.5.a.3 Defining of configurable thresholds and notifications 5.3.5.a.4 Interfacing & forwarding measurement information to an external network performance system 5.3.5.a.5 Producing counters and gauges for the various logical and physical entities 5.3.5.a.6 Graphical display of measurement data 5.3.5.a.7 Projection of system capacity 5.3.5.a.8 System Change Operation & Control

4. 5.

Technical Specification for Short Messaging System

15

_____________________________________________________________________ 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. A software/application/hardware upgrade should be done without any service downtime The system change control function shall provide for the following: 1. 2. 3. 9. System configuration administration Data acquisition for change operation System data administration The Bidder is required to submit details on how this function is supported in the system System Basic Design 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 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 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 plugin units that may be replaced by non-specialist technician without further alignment 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 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.

7. 8.

5.4 5.4.1

5.4.2

5.4.3

5.4.4

5.4.5

Technical Specification for Short Messaging System

16

_____________________________________________________________________ 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 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 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 The database will be capable of acting as the central database that can contain common subscription information across all applications Operation and Maintenance Spares 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 Test Equipment and Tools 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 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 Provision of all test equipment and tools required for installation, testing and commissioning of the system shall be the Bidder's responsibility

5.4.7

5.4.8

5.4.9

5.5 5.5.1

5.6 5.6.1

5.6.2

5.6.3

Technical Specification for Short Messaging System

17

_____________________________________________________________________ 5.7 5.7.1 System Reliability & Availability 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 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 Redundancy and Backup The system shall be designed for fail-safe operation 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 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. 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 Equipment status indicators that clearly indicate the on-line/offline status of sub-systems or units shall be provided at the front panel

5.7.2

5.8 5.8.1 5.8.2

5.8.3

5.8.4

5.8.5

Technical Specification for Short Messaging System

18

_____________________________________________________________________ 5.8.6 Hardware and software control shall be provided for manual reconfiguration. No physical connection/disconnection of cables shall be required for re-configuration. In other words, re-configuration should be pre-wired 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 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 reconfiguration period The Bidder shall give a detailed block diagram to show the items of equipment that are 5.8.9.a.1 5.8.9.a.2 5.8.9.a.3 5.8.9.a.4 Dual redundant with automatic change-over Dual redundant with manual change-over Provided with 1:N standby No standby

5.8.7

5.8.8

5.8.9

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 database 5.8.13.a.2Critical system data 5.8.13.a.3System date and time 5.8.13.a.4Billing information. 5.8.13.a.5Statistical information 5.8.13.a.6System error logging information, if available

Technical Specification for Short Messaging System

19

_____________________________________________________________________ 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 5.9.1 Reliability/Design Features 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 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 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.1.2

5.9.1.3

Technical Specification for Short Messaging System

20

_____________________________________________________________________ 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 subsystem 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 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.9.6.2

Technical Specification for Short Messaging System

21

_____________________________________________________________________ 5.10 Managed services

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

6
6.1 6.1.1

Element Manager & External Interface

Element Manager 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 6.1.2.1 Architecture 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. It shall be scalable in order to support more than 1 NE network Unix-based system is preferred. The EM server shall be able to provide service extension to limited number of client, but shall not be lower than 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 database c) The database shall be able to handle current and historical alarms

6.1.2.2 6.1.2.3 6.1.2.4

6.1.2.5

Technical Specification for Short Messaging System

22

_____________________________________________________________________ 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 used b) Listed below are the important attributes Attribute Managed Object Class Managed Object Instance Probable Cause Probable Cause (name) Reservation Status Reservation Time Reservation User Name Acknowledgement Status Acknowledgement Time Acknowledgement User Name Expiration Status Attribute Additional Text User Note Notification Identifier Current Alarm Id Correlated Notification Flag Repetition Counter Perceived Severity Friendly Name SpecificProblem Event Date Event Time Clearing Status Clearing Time AlarmType/EventType Description

Description

Critical, Major, Minor, Intermediate, Warning, Clear

CommunicationAlarm, qualityofServiceAlarm, equipmentAlarm, processingErrorAlarm,

Technical Specification for Short Messaging System

23

_____________________________________________________________________ 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 used i) Critical ii) Major iii) Minor iv) Intermediate v) Warning vi) 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 6.1.4.4.3 Report types must be configurable. The bidder might propose report types that can be used with the SMSC

Technical Specification for Short Messaging System

24

_____________________________________________________________________ 6.1.4.4.4 According to business needs, TELCO PROV CO will request for additional report types without any commercial implications. Threshold Setting a) b) c) d) 6.1.4.4.6 All principal performance parameters shall be assigned with threshold value Threshold value shall be included in all related reports EM shall actively perform test to check the level of all principal performance parameters. In the event of threshold value is crossed, an alarm shall be triggered to acknowledge the user.

6.1.4.4.5

Graphical User Interface a) b) c) A user friendly interface shall be provided Text and graph reports shall be available and selective for the type of report outputs. The output reports shall be able to be save into file

6.1.5 Configuration Management 6.1.5.5.1 Data Collection a) b) d) 6.1.5.5.2 EM shall record the important system configuration A log file shall be available to monitor any configuration changes In the event of failure in any of data collection process, alarms shall be triggered for notification

Graphical User Interface a) b) c) A user friendly interface shall be provided Graphical method is preferred to view system architecture User is allowed to enter comment or memo as notification for each main component and subcomponent

6.2

External Interface 1. Objective

Technical Specification for Short Messaging System

25

_____________________________________________________________________ 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. 2. 3. 4. 5. 2. 1. 2. 3. 1. 2. Socket TCP/IP shall be used as the transport medium to forward / to pull events/alarms to / by external OSS EMS is given the choice to behave as client or server Once TCP/IP connection is established, an application to application shall take over for forwarding / pulling of events/alarms It has the capability to restart itself if the service is down The heartbeat capability shall be available and duration of heartbeat shall be easily configured Format The above mentioned attributes shall be included in every event/alarm Space shall not be used as the separator for each field Filtering Filtering capability shall be easily turn on or off for the alarm forwarding The specification for filtering should include the following as the parameter a) b) c) d) severity eventType probableCause specificProblem

Technical Specification for Short Messaging System

26

_____________________________________________________________________ 6.4 Performance Collection 1. Protocol 1. 2. 3. 2. 1. 2. The performance data shall be made available in ASCII/text format file The file shall be updated in hourly basis ftp, rcp and rsh functions shall be allowed to be used to transferred the files in hourly basis Format The files shall be preceded with counter names The performance counter value shall be separated with coma or semicolon

6.5

Configuration Collection 1. Protocol 1. 2. 3. 2. 1. 2. The performance data shall be made available in ASCII/text format file The time period to update the file shall be easily configured ftp, rcp and rsh functions shall be allowed to be used to transferred the files in hourly basis Format The files shall be preceded with parameter names 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.

Technical Specification for Short Messaging System

27

_____________________________________________________________________ 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 7.1.4.2 7.1.4.3 7.1.4.4 7.1.4.5 7.1.4.6 Country IMSI range (configurable) SMS Broker used Any other criteria that are configurable Short codes 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

Technical Specification for Short Messaging System

28

_____________________________________________________________________ 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. Support Facility 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. 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. 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. In addition, the billing subsystem shall provide a facility to generate SDR call records for testing and verification purposes. On-Line File Transfer Distribution to External Systems 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 COs consideration.

7.3 7.3.1

7.3.2

7.3.3

7.3.4

7.4 1.

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

Technical Specification for Short Messaging System

29

_____________________________________________________________________ 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. 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. 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: Save and analyse information at a point where a fault occurs, in the system crash dump area during system on-line operation. Select and trace the checkpoints of the system such as states, resources, etc. during system on-line operation. The Bidder is required to furnish a detailed description on how the above requirements are met. The system clock should not deviate from the standard GMT time by more than 1 second over a period of 1 month. 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. 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.4

8.5

8.6 8.7 8.8 8.9 8.10

8.11

Technical Specification for Short Messaging System

30

_____________________________________________________________________ 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. The system shall continuously execute checks at regular intervals to verify the availability of their resources such as: 8.13.1 CPU utilization 8.13.2 Memory utilization 8.13.3 Disk space utilization 8.13.4 Database utilization (e.g. overflow, page fault swapping, fragmentation, etc) 8.13.5 Channel/peripheral utilization 8.13.6 File system utilization 8.13.7 LAN utilization e.g.<1 % congestion 8.13.8 Application statistics Data and management information on the system shall be collected by the system automatically. For Unix-based system, appropriate shell/awk/perl scripts should be setup via crontab to automate all tasks. The operational functionality: 8.16.a.1 8.16.a.2 8.16.a.3 8.16.a.4 8.16.a.5 8.16.a.6 8.16.a.7 8.17 software supplied shall cover the following

8.13

8.14 8.15 8.16

Data structure/schema of the files and tables, databases, indexes, triggers, rules, procedures. Event and error logging facilities. Database maintenance and log files management. Backup/restore facility Recovering and restart processes Appropriate automated restart if a software malfunction is detected. Online and offline diagnostics to troubleshoot system malfunctions or failures.

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

Technical Specification for Short Messaging System

31

_____________________________________________________________________ 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. The operational software should be free of memory leaks and should not require a warm/cold restart within 3 months. 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. 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 COs provisioning system and the throughput supported over the interface. The SMS provisioning system shall be able to control the provisioning based on services. 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.

8.20 8.21

8.22

8.23 8.24

9 System Testing
9.1 1. General 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 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 Types of Tests to be Included in the CAT Test Plan System Tests

2.

9.2 9.2.1

Technical Specification for Short Messaging System

32

_____________________________________________________________________ 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. The acceptance test cases should include but not limited to the following: a) b) c) Automated heartbeat/monitor for any IPC/RPC communications. Availability of visual and audible alarms on the various hardware platform(s). 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 Backup and recovery of the system. Shutdown of the system. Warm/Cold/Reload of the system from root disk or tape. Verification of the redundancy functionality. Verification of hot-swapping and load-sharing functionality. Verification of interconnection to external nodes. Verification of end-user interfaces. Verification of database configuration and environmental variables. Verification of operating system setup, including the automatic purging of audit and error log entries. Verification of security and access controls. Breakage and resumption (synching) of disk mirroring, etc. Elimination of database overflow pages, fragmentation, etc. Freeing of system, database resources (e.g. semaphores, monitors, flags) upon application shutdown. (e.g. ipcrm) Software patching process. Verification on the accuracy of statistics, performance measurements and other counters, pegs generated on the system. Automation of all O&M tasks. This can be achieved either via cron-Unix or the Schedule Service-Win NT/2000. Date change (bring forward /backdate)

9.2.1.2

d) e) f) g) h) i) j) k) l) m) n) o) p) q) r) s) t)

Technical Specification for Short Messaging System

33

_____________________________________________________________________ 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. 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. The system shall satisfactorily operate continuously without a) adjustment, changes or part replacement of equipment, b) changes to computer software c) interruptions, errors or malfunctions of equipment d) 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. 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. The tests shall also be designed to demonstrate the practicability and suitability of the preventive operation maintenance aspect of the system

9.2.1.4

9.2.1.5

9.2.2

9.2.2.2

Technical Specification for Short Messaging System

34

_____________________________________________________________________ 9.2.3 9.2.3.1 Test Plans and Procedures The test plans and procedures shall include, at a minimum, the following: a) b) c) d) e) Description and objective of the test Scope of tests Expected or desired results Criteria for successful acceptance Designation of all inputs that are required to test each function f) 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 9.3.1 9.3.1.1 Facilities and Set-Up Requirements Test Facilities 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. 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. 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 The Bidder should highlight which tools and test equipment are part of the offer and which are optional Where applicable, the Bidder shall propose discounts for TELCO PROV CO to purchase the tools and test equipment. 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.1.2

9.3.1.3

9.3.1.4 9.3.1.5

9.3.1.6

Technical Specification for Short Messaging System

35

_____________________________________________________________________

9.3.2 9.3.2.1

Responsibility of Quality Assurance 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.

10Technology 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 10.2.1 General 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. Introduction of new functionality shall be introduced as software changes. Changes to the hardware shall be minimized. 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. Product Roadmap 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 -

10.2.2 10.2.3

10.3 10.3.1

Technical Specification for Short Messaging System

36

_____________________________________________________________________ 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. QoS

10.4 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 11.2 The Bidder must agree to provide support free of charge during the warranty period 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. 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 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. 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.3

11.4

11.5

Technical Specification for Short Messaging System

37

_____________________________________________________________________ 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 Definitions are as follows
Description Affecting service completely) Affecting billing Affecting maintenance (partially or Service Availability required 99.99% Penalty 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 To be finalised by TELCO PROV CO mgmt during meeting with the Bidder

11.7

Categor y Critical

Major

Affecting administration, O&M

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 11.9

Service availability will be calculated monthly based on the number of days of the month (28, 29, 30 or 31) 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%
Technical Specification for Short Messaging System

38

_____________________________________________________________________ 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 offpeak period

Peak hours are from 0800 until 2200 Since 1 hour during peak period is equal to 5 hours in the off-peak period, lets 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 period Outage = 1 hour Availability = 480 1 = 479 hours Availability percentage = 479/480 = 99.79% Outage scenario 2: 1 hour during off-peak period Outage = 1 => divided by 5 => 0.2 hour Availability = 480 0.2 = 479.8 Availability percentage = 479.8/480 = 99.95% Outage scenario 3: 0.5 hour during peak and 0.5 hour during offpeak period Outage = 0.5 + 0.5/5 = 0.6 Availability = 480 0.6 = 479.4 Availability 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.

Technical Specification for Short Messaging System

39

_____________________________________________________________________ 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

Technical Specification for Short Messaging System

40