RFP for SMSC Generic

_____________________________________________________________________

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

1

_____________________________________________________________________

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

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

3.

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

Technical Specification for Short Messaging System

2

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

2.1.6.5

2.1.6.6 2.1.6.7

2.

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

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

3

_____________________________________________________________________ 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

2.3.3.3

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

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

Technical Specification for Short Messaging System

4

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

The Bidder shall also state if any such connection has been tested or commercially implemented 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 Mcommerce Gateway etc) a.c) Any other suitable interfaces as proposed by the Bidder a.d) Text file upload

2.4.2

2.4.3

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.

SMS Addressing

Technical Specification for Short Messaging System

5

_____________________________________________________________________ 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 subscribers/addresses within the 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

Technical Specification for Short Messaging System

6

delivery SMS-C

of and

_____________________________________________________________________ 2.5 2.5.1

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

Technical Specification for Short Messaging System

7

_____________________________________________________________________ 2.5.1.10

3

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

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

IOT reports should be made available for the following equipment manufacturers

4.3.1 4.3.2 4.3.3 4.3.4 4.3.5

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

8

_____________________________________________________________________

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

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 Requirements b) Storage Requirements c) Remote Access Requirements d) 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-

Technical Specification for Short Messaging System

9

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

5.2.2

5.2.3

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

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 / DC b) Number of power point needed c) Power requirement of each power point expressed as voltage requirements and current capacity

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

Technical Specification for Short Messaging System

10

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

5.2.4

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.

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

Technical Specification for Short Messaging System

11

_____________________________________________________________________

5.2.5

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

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

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

5.2.6

5.2.7

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

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

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

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 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) 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

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

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

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

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.

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

System configuration administration Data acquisition for change operation 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 plugin 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.

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

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

Technical Specification for Short Messaging System

17

_____________________________________________________________________ 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/offline status of sub-systems or units shall be provided at the front panel

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

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

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.

Technical Specification for Short Messaging System

20

_____________________________________________________________________ 5.9.2

Independence of Equipment Modules 5.9.2.1

5.9.3

On-Line Program Checks 5.9.3.1

5.9.4

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

Protection Against Detrimental Effects of Improper Operation 5.9.5.1

5.9.6

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

Protection Against Technical Failure Causing Loss or Distortion of Data 5.9.4.1

5.9.5

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

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

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

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

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 database c) The database shall be able to handle current and historical alarms

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.

6.1.4.4.5

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.

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

Graphical User Interface a) b) c)

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

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

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.

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

2. 3. 2.

Format

1. 2.

6.5

The files shall be preceded with counter names The performance counter value shall be separated with coma or semicolon

Configuration Collection 1. Protocol 1.

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

2. 3. 2.

Format

1. 2.

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.

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.

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.

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.

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.

8.13

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.