Smart Card
IC Card Reader & Terminal
Network Security Solution
OTA
USSD
 
 
OTA Server
 

General requirements for OTA Server as follows:
 

1.1 Remote File Management

1.2 Dynamic STK/Application Management

1.3 Phone Auto Configuration

1.4 Preferred Network Solution

1.5 User Management

1.6 Access Channel

1.7 Content Management

1.8 Billing

1.9 OTA Platform Hardware and Software

1.10 Scalability

1.11 Redundancy

1.12 Security and Auditing

1.13 API for External Application Interface

1.14 Message Recovery

 
 

1.1 Remote File Management

The OTA platform shall administrate a (U)SIM card remotely and change its content after the card has been issued.  It shall allow dispatching the information as an individual card or batch, with scheduling capability. All OTA messages must be securely downloaded over-the-air onto the (U)SIM card using GSM 23.048 standard.

The OTA platform must be open to integrate other SIM vendors' libraries for remote file management of existing SIM cards. All integration must be done by winner supplier and doesn't have any charge to the Operator.

The OTA platform must be able to update content in the EFs, example, SMSP, PLMN, etc. It must also be able to send APDU script over-to-air to update contents in the (U)SIM.

 

1.2 Dynamic STK/Application Management

The OTA platform shall support the remote management of Java-based STK (SIM Toolkit) menu and applications. A new applet and/or application and/or new functionalities and/or service menu shall be securely downloaded over-the-air and /or POS (Point of Sales) onto the (U)SIM card using GSM 23.048.

  • Personalize Menu: The OTA platform shall allow the subscribers to customize their own menu via Operator's subscriber web portal, POS (Point of Sales) and SMS (OTA).
  • Update Menu: The OTA platform shall allow the administrator to update the menu via Operator's web portal and/or push the update menu onto the SIM's subscriber via SMS OTA directly.
  • Add Menu: The OTA platform shall allow the administrator to add menu for new services via  Operator's web portal. The subscriber shall be able to add new menu or services via  Operator's subscriber web portal, POS (Point of Sales) and SMS (OTA).
  • Delete Menu: The OTA platform shall allow the administrator to delete menu via  Operator's web portal and/or push delete the menu onto the SIM's subscriber via SMS OTA directly. The subscriber shall be able to delete menu or services via  Operator's subscriber web portal, POS (Point of Sales) and SMS (OTA).
  • Pop-up Menu: The pop-up menu is the pop-up service menu on the user phone screen and user can continue to make selection list is dynamic and can be or not store on the SIM card.
  • Bookmark / My favourite menu: Bookmarking feature provides a faster access to user's favourite service when the user frequently use certain STK application. The subscriber shall save a bookmark frequently service in his favourites menu and preset necessary parameter of each service shall also be stored. The subscriber can trigger the bookmark service under favourites menu without any addition user data input.
  • Multiple Language menu: The service menu on SIM card shall multiple languages supported at least 2 languages e.g. Thai and English. The supplier shall describe how the user change the menu language on his mobile phone e.g. phone setting or download new menu language.
  • SIM Card Memory Management: The OTA platform shall prompt the operator or subscriber when the application or service chosen to download is too large for the remaining memory on the SIM card.
  • SIM Card Memory Fragmentation: The SIM Card shall support the memory fragmentation function when the subscriber or operator add or delete an application and/or applet and/or service menu on the SIM card. The SIM card shall find a remaining total memory space block to install a new application and/or service menu that required. If the space memory block in the SIM card are concatenates but total free memory can fit a new application then the install are complete.
  • Push Service mode/ Interactive Service: The Operator shall initiate to send new service or application e.g. advertisement, announcement and surveys to subscriber mobile phone. These push service / interactive service application shall automatically delete once the subscriber has responded. The push service / interactive service shall de-activate or hidden menu until a time to launch those service. The operator can active or trigger those push / inter active service via SMS.
 

1.3 Phone Auto Configuration

The OTA platform shall allow GPRS/WAP/MMS configurations to be downloaded into the handset.  Supplier shall describe in details the proposed solution.

 

1.4 Preferred Network Solution

The Supplier shall provide Preferred Network Solution which allows operator to edit /set priority of each Roaming Partner in PLMN List.

 

1.5 User Management

The OTA platform shall include a web-based management user interface to allow the maintenance and configuration of the system. It shall allow administrators and customer service representatives to access all the OTA related features via web-based GUI.

 

1.6 Access Channel

The basic interface requirements are SMSC and TCP/IP. However, it will be an added advantage if the OTA platform can support additional MMSC, WAP, Push Proxy services in a single platform. The supplier shall describe the API available for the Content Providers to have access to the above different channel.

The OTA platform shall allow the service to be accessed by the subscriber or the customer service representative via web portal.  There shall be a web portal for administrator to manage the OTA platform.

The OTA platform systems shall connect together via TCP/IP network. Either of TCP/IP, Internet or VPN has been failed; system shall be ability to re-connect automatically with out operator assist. The system shall have SMS notification to predefine particular person.

The SMSC interface shall have the following features:

  • Support Nokia SMSC CIMD2 and SMPP
  • Round robin
  • Weighed load balancing
  • Primary/backup links
  • Scales with increasing message traffic
  • Broadcast messages
  • Ability to handle multiple message charging
 

1.7 Content Management

The proposed OTA platform must support intelligent business rule scripting and routing functions to be able to route the requests (Mobile Originating or Mobile Terminating SMS) to the content providers or other external systems via interface such as HTTP. The supplier shall provide details on the interface.

The OTA platform must be able:

  • To manage the different access channel for each content providers.
  • To provide workflow tools to provision new services, such as Web-based tools that allow  Operator to integrate new content providers and launch new services easily.
  • To manage the traffic for each content provider, for example, by allocating the maximum number of messages per second.
  • Flexible billing management that controls the tariff classes that each content provider use.
  • To generate statistics and reporting for each content providers.
 

1.8 Billing

The platform shall gather statistics and display performance related functions. The tracking and monitoring of the content generated by subscribers shall be provided for administration and billing purposes.

The OTA platform shall support the following billing implementation options:

  • Billing event generation from
    • MO
    • MT
    • Specific contents
    • Others to be proposed by vendor
  • Customizable CDR format
  • Tariff class forwarding to the SMSC/MMSC
  • Direct integration to the pre-paid billing system
 

1.9 OTA Platform Hardware and Software

  1.9.1 Hardware Configuration
 

Details are required for the hardware architecture, processor type, operating system, and memory requirements. Supplier shall also specify the degree of scalability of the architecture.  Supplier shall state the minimum number of message/second supported by the software and hardware recommended. The hardware must be able to mount into the 19 inches standard rack unit.

The OTA platform shall remove or insert board without any interruption on the existing board in the same system. The supplier shall describe which board in the system is hot swap capability.
   
 

1.9.2 Software Configuration

 

Supplier shall list all the software required for the OTA platform, whether provided by the supplier or to be acquired by  Operator, including middleware layers, available operating systems, databases etc.

   
 

1.9.3 Application Programming

 

Supplier shall specify what application development tool is available for the OTA Platform. The supplier include details of testing tools and application programming interface (eg ‘Java', ‘C++', etc.) or availability of development kit for customization.

   
 

1.9.4 Menu Designer Tools

 

The OTA platform shall have menu designer tools for  Operator in house developer and Content provider developer. This tool does not require computer professional skill. User friendly GUI drags and drop feature are supported. A debugging and testing process tools shall be performed before the service menu generated for provisioning service into the database.

   

1.10 Scalability

The OTA platform shall handle increasing usage, changes in VAS business models and upgrades of the network infrastructure. It shall anticipate the following needs, protecting the future investment by providing scalable distributed architecture, the modular framework, and extensive use of open, platform independent standard.  The OTA platform shall provide flexible plug-in architecture for extended server functionality.

The architecture must be scaleable in the sense that it must be possible to expand the capacity according to the actual needs. Capacity extensions must be possible with regard to Number of subscribers, I/O capabilities, data storage, etc.

The supplier shall describe all available and planned capacity steps of his OTA platform system. Each of the capacity steps shall be described and priced separately.

 

1.11 Redundancy

The OTA platform shall provide full redundancy and high availability for critical components.

The supplier shall describe the way in which the proposed OTA platform complies with this essential requirement.  This description shall include details on the types and levels of redundancy which are provided in the solution in terms of hardware, software, databases, additional equipment and system as well as the effect on continuous service availability (e.g down time duration).

 

1.12 Security and Auditing

The OTA platform shall be secured in such a way that all customer sensitive data stored on or passing through the platform is protected from unauthorized access.

All actions of the OTA platform shall be logged for audibility.  This includes a summary of all profile update sessions. These shall be stored either on hard disk or read/writeable CD.  Sufficient storage shall be provided on the OTA platform to ensure at least a full month of logs and statistics can be stored without intervention. 

The OTA platform shall able to produce subscriber-bases log file that contain menu download information. The log shall activity logging file as MO logging, MT logging, End User Registration log, Web access log etc.

 

1.13 API for External Application Interface

The supplier has to give the API for external application to interface with the OTA platform. This API can support application that is developed using Java, C++, etc.

 

1.14 Message Recovery

The concatenate message received missing upon the user requested service application. The OTA platform shall have mechanisms to auto-recover only missed message. The supplier shall describe how platform to recover a missed message.     

 
 
 
 
|
|
|
|