UMA_wIQ_Rel1.7_V1.6

wIQ
For Software Release 1.7
User Manual

wIQ
For Software Release 1.7
User Manual

User Manual Version 1.6 for Software Release 1.7

Copyright © 2005 by ORGA Systems enabling services GmbH

The software, hardware and manuals described here and all their constituent parts are pro-tected by copyright. Without the express permission of ORGA Systems enabling services Gm-bH, any form of use which goes beyond the narrow bounds prescribed by copyright legislation is prohibited and liable to prosecution. This particularly applies to duplication, copying, trans-lation, processing, evaluation, publishing, and storing and/or processing in an electronic sys-tem.

Specifications and data may be changed without notice. We offer no guarantee that this doc-umentation is correct and/or complete. The company assumes no liability for damages, direct or consequential, which may result from the use of the described and/or supplied program material.

Most of the names of hardware and software products mentioned in this documentation are registered trademarks and as such are subject to the usual statutory provisions.

The Zend Engine License, version 0.92Copyright © 1998-2000 Zend Technologies Ltd.

This product includes software developed by the Apache Software Foundation(http://www.apache.org/).

Copyright © 2000 The Apache Software Foundation. All rights reserved.

Copyright © 2000 The PHP Development Team. All rights reserved.

Copyright © 1994-2000 World Wide Web Consortium, (Massachusetts Institute of Technolo-gy, Institut National de Recherche en Informatique et en Automatique, Keio University). All Rights Reserved. This program is distributed under W3C’s Software Intellectual Property Li-cense. This program is distributed in the hope that it will be useful, but WITHOUT ANY WAR-RANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See W3C License http://www.w3org/Consortium/Legal/ for more de-tails.

Copyright © 1995 CERN. „This product includes computer software created and made avail-able by CERN. This acknowledgement shall be mentioned in full in any product which includes the CERN computer software included herein or parts thereof.“

libxml2 License, Version 2.4.21: Copyright (C) 1998-2002 Daniel Veillard. All Rights Reserved.

wIQ

1
Introduction
2
System Description
3
Databases
4
Configuration
5
The Router
6
Additional Features
7
SNMP
A
Appendix
I
Index

C
Contents
1 Introduction ..................................................................... 1

1.1 Conventions .................................................................................1

1.2 Abbreviation List ...........................................................................3

2 System Description.......................................................... 7

2.1 System Overview ..........................................................................7

2.2 Description of the wIQ Process....................................................11

2.3 External Requirements ................................................................11

2.4 HTML to USSD/SMS Conversion..................................................12 2.4.1 wIQ-specific Tags ................................................................... 15

2.4.1.1 Values / Attributes .......................................................... 15

2.5 Using USSD ................................................................................18 2.5.1 Subscribers’ Input Interface.................................................... 18

2.5.1.1 Subscribers’ First Login (Self-registration)......................... 182.5.1.2 Call a wIQ Service ........................................................... 212.5.1.3 Browsing in an Open Session .......................................... 252.5.1.4 Controlled Preinput Processing........................................ 282.5.1.5 Session End..................................................................... 29

2.6 Using SMS ..................................................................................30 2.6.1 Subscribers’ First Login........................................................... 30

2.6.1.1 Call a wIQ Service ........................................................... 30 2.6.2 Supported Types of SMS ........................................................ 32

i

Contents

2.7 Push ...........................................................................................33

2.8 HTML Input Formats ...................................................................33

2.9 Subscribers’ Identity Directly to URLs ...........................................33

2.10 Fast Access to URL with Direct Parameter Passing........................34

2.11 HTML Conversion to Mobile Phone-Specific Character Set ..........34

2.12 Constraints .................................................................................34

2.13 Multiple Language Report...........................................................35 2.13.1 Preferred Language Set in the Subscriber Database ................ 35

3 Databases...................................................................... 37

3.1 Subscriber Database ..................................................................37 3.1.1 Interfaces............................................................................... 37

3.1.1 PHP-Interfaces................................................................. 373.1.1 Commandline Interfaces and Database Tools .................. 41

3.2 Group-Specific USSD to URL Mapping and Valid URL ..................46 3.2.1 Brief Description .................................................................... 46 3.2.2 How to Assign a Subscriber to a Group.................................. 46

4 Configuration................................................................. 49

4.1 Start and Stop Procedure ............................................................49 4.1.1 wIQd..................................................................................... 49 4.1.2 wIQd Process Table ................................................................ 50 4.1.3 wIQd.cfg ............................................................................... 51 4.1.4 Failover.................................................................................. 53 4.1.5 Processtable........................................................................... 60

4.2 Logging ......................................................................................61

4.3 wIQ Internal................................................................................64 4.3.1 Commandline Options........................................................... 64 4.3.2 Signal Handling ..................................................................... 65

4.4 Environment Variables ................................................................65

ii

Contents

4.5 wIQ: Configuration Files .............................................................65 4.5.1 Interface_{processname}.cfg: wIQ Configuration File Variables 66 4.5.2 wIQ.cfg: wIQ Configuration File Variables .............................. 67

4.5.2.1 License ........................................................................... 67

4.6 Configuration Files......................................................................76 4.6.1 Ussd2URL.cfg*: ’USSD to URL Mapping’ Table..................... 78 4.6.2 Solution................................................................................. 80 4.6.3 ValidURL.cfg*: ’Valid URL’ and Variable Inclusion Table......... 84

4.7 SMS2Service.cfg*: ’SMS to Service Mapping’ Table .....................90

4.8 URL2SMS.cfg*: ’URL to SMS Interface Mapping’.........................93 4.8.1 USSD Session Action after a SMS is Requested....................... 96

4.9 DBDefaults.cfg: ’MSISDN-Dependent Database Defaults’ Table ...97

4.10 ProviderMap.cfg .......................................................................100

4.11 wIQ2opsc_in.cfg.......................................................................100

4.12 License File ...............................................................................100

4.13 HotKeySet.cfg: Configuration File for Character Sets................102

5 The Router.................................................................... 105

5.1 Driver Types, Services, and Routing Algorithm ...........................106 5.1.1 Driver Type........................................................................... 106 5.1.2 Service................................................................................. 107 5.1.3 Routing Algorithm............................................................... 107

5.2 General Information .................................................................107 5.2.1 Program Name .................................................................... 107 5.2.2 Command Line Options ....................................................... 108 5.2.3 Regular Termination............................................................. 108 5.2.4 Enable/Disable DEBUG Information ...................................... 108 5.2.5 License ............................................................................... 108

5.3 Configuration Data...................................................................108 5.3.1 Overview of the Configuration Files: .................................... 109

5.3.1.1 Configuring the Connections ........................................ 109

iii

Contents

5.3.1.2 Configuring the Routing Algorithms.............................. 109 5.3.2 File Router.cfg...................................................................... 110 5.3.3 File Driver_<PATTERN>.cfg ................................................... 112 5.3.4 File wIQ_<PATTERN>.cfg...................................................... 114 5.3.5 File wIQRoutingAlgorithm.cfg .............................................. 115 5.3.6 Files Driver<Pattern>_RoutingAlgorithm.cfg......................... 116

6 Additional Features ..................................................... 119

6.1 Billing ......................................................................................119 6.1.1 Introduction......................................................................... 119

6.1.1.1 Billing Mechanism......................................................... 120 6.1.2 Modules .............................................................................. 121

6.1.2.1 Secure HTTP.................................................................. 1216.1.2.2 Price Tag....................................................................... 1216.1.2.3 Provider List/ProviderMap.cfg ........................................ 1216.1.2.4 IN Billing Configuration/wIQ2opsc_in.cfg ...................... 1226.1.2.5 Billing ........................................................................... 1236.1.2.6 Billing Scenarios for Push............................................... 1276.1.2.7 Billing of Regular ESMS ................................................. 1286.1.2.8 Billing of Long ESMS ..................................................... 1296.1.2.9 Different Billing Types ................................................... 129

6.1.3 Licensing ............................................................................. 138 6.1.4 Example............................................................................... 138

6.2 Push Interface ..........................................................................140 6.2.1 General Architecture............................................................ 140 6.2.2 Push-request and Response ................................................. 141

6.2.2.1 Push-request ................................................................. 1426.2.2.2 Push-response............................................................... 143

6.2.3 wIQpush Process.................................................................. 1466.2.3.1 License.......................................................................... 1466.2.3.2 Configuration File ......................................................... 1466.2.3.3 Startup ......................................................................... 1506.2.3.4 Signals .......................................................................... 1516.2.3.5 Configuration Reload.................................................... 1516.2.3.6 Termination .................................................................. 1516.2.3.7 Exit Codes..................................................................... 152

iv

Contents

6.2.3.8 Logging ........................................................................ 152 6.2.4 Use Cases ............................................................................ 153

6.2.4.1 Client Aborts Request ................................................... 1536.2.4.2 Connection Failure ........................................................ 1536.2.4.3 Web Server Timeout...................................................... 1536.2.4.4 Request Timeout........................................................... 1536.2.4.5 wIQ Core Reports Status ............................................... 153

6.2.5 Remark on Billing................................................................. 154

6.3 SMS Center Interfaces ..............................................................155 6.3.1 General ............................................................................... 155

6.3.1.1 CURRY Protocol ............................................................ 1566.3.1.2 OMBmanager ............................................................... 1576.3.1.3 Program Name.............................................................. 1576.3.1.4 General......................................................................... 1576.3.1.5 Signals .......................................................................... 1576.3.1.6 Command Line Options ............................................... 158

6.3.2 Driver Configuration ............................................................ 1586.3.2.1 OMBmgr Configuration ............................................... 161

6.3.3 SMSC Client ........................................................................ 1626.3.3.1 Process Invocation......................................................... 1626.3.3.2 Signals .......................................................................... 1636.3.3.3 Configuration ............................................................... 164

6.4 SMS Services.............................................................................177 6.4.1 Session Settings from HTML Content ................................... 177 6.4.2 Use Cases ............................................................................ 177

6.4.2.1 Push to USSD Display .................................................... 1776.4.2.2 Push to USSD Prompt with Immediate Answer .............. 1786.4.2.3 Push to USSD Prompt with Late Answer ........................ 1786.4.2.4 Push to SMS ................................................................. 1806.4.2.5 Push to FINISH-SMS ...................................................... 1816.4.2.6 License Additions .......................................................... 182

6.4.3 Load Distribution (Push / SMS / USSD )................................. 182

6.5 wIQ Enhanced SMS ..................................................................183 6.5.1 Overview ............................................................................. 185

6.5.1.1 First Octet of a SUBMIT-TPDU........................................ 185 6.5.2 wIQ HTML Language Extension............................................ 189

6.5.2.1 User Data-specific Tags ................................................. 1966.5.2.2 ESMS HTML Tag Processing Rules.................................. 198

v

Contents

6.5.3 wIQPush .............................................................................. 1996.5.3.1 HTTP Interface Extension ............................................... 199

6.5.4 Examples ............................................................................. 2016.5.4.1 Example of a Ringtone ESMS......................................... 2016.5.4.2 Example of a Text ESMS................................................ 2036.5.4.3 Example of a Binary SMS............................................... 2046.5.4.4 Example of a Picture SMS.............................................. 205

6.6 ORGA NSG Driver .....................................................................207 6.6.1 Signals................................................................................. 207 6.6.2 Command Line Options ....................................................... 208 6.6.3 Driver Configuration ............................................................ 208

7 SNMP ............................................................................ 211

7.1 SNMP Trap Configuration .........................................................212 7.1.1 OLS TRAP ............................................................................ 212 7.1.2 Configuration of the SNMP Agent ....................................... 213

7.2 SNMP Support in wIQ Processes................................................218 7.2.1 wIQd / wIQguard ................................................................. 218 7.2.2 wIQ ..................................................................................... 221 7.2.3 Router ................................................................................. 223

A Appendix...................................................................... 225

A.1 Supported Characters from the GSM-Default Alphabet.............225

A.2 Mapping from HTML 3.2 to USSD/SMS.....................................226

A.3 Changes ...................................................................................230 A.3.1 New Features for wIQ 1.0 .................................................... 230 A.3.2 New Features for wIQ 1.1 .................................................... 231 A.3.3 New Features for wIQ 1.2 .................................................... 231 A.3.4 New Features for wIQ 1.3 .................................................... 231 A.3.5 New Features for wIQ 1.4 .................................................... 232 A.3.6 New Features for wIQ 1.5 .................................................... 232 A.3.7 New Features for wIQ 1.6 .................................................... 232

vi

Contents

A.3.8 New Features for wIQ 1.7 .................................................... 232

A.4 HTML Pages for Keytable Configuration....................................232

A.5 Use of the wIQ Web Interface ...................................................234 A.5.1 wIQ Administration Interface ............................................... 235

A.5.1.1 Limited Subscriber Database Interface ........................... 235A.5.1.2 Complete Subscriber Database Interface ....................... 235A.5.1.3 Incore Interface ............................................................. 235A.5.1.4 Incore Manual Page ...................................................... 236

A.5.2 Read-Only Subscriber Database Interface ............................. 236 A.5.3 PHP Information .................................................................. 236

A.6 System Activity Reporter ...........................................................236

A.7 Backup and Restore of the Sun Solaris Operating System ..........237 A.7.1 Introduction to Backup and Restore ..................................... 238 A.7.2 Installing and Using a Tape Drive.......................................... 239

A.7.2.1 Installing a Sun StorEdge Tape Drive.............................. 239A.7.2.2 Using a Tape Drive ........................................................ 240

A.7.3 Using ufsdump and ufsrestore ............................................. 241A.7.3.1 Introduction to the ufsdump Command........................ 241A.7.3.2 Introduction to the ufsrestore Command ...................... 241A.7.3.3 Backing up Several File Systems on a Single Tape .......... 242

A.7.4 Saving and Restoring Partitioning Information...................... 244 A.7.5 Restoring the World Wide Number (WWN) .......................... 245 A.7.6 Creating a Backup of the System’s Root (/) Partition ............. 246 A.7.7 Restoring the System’s Root Partition ................................... 247 A.7.8 Restoring other important system partitions (/usr, /var/, ...) ... 249 A.7.9 Restoring ’normal’ (User) Partitions ...................................... 249 A.7.10 A Note Concerning /tmp...................................................... 249 A.7.11 Backing Up and Restoring of RAID Metadevices ................... 249

A.7.11.1 Troubleshooting Metadevices........................................ 250A.7.11.2 Recovering the DiskSuite Configuration......................... 250A.7.11.3 How to Use the md.cf File to Recover a DiskSuiteConfiguration 251

A.7.12 Backing up and Restoring a System Step by Step ................. 252 A.7.13 Requirements ...................................................................... 252 A.7.14 Creating a Full System Backup Including the Root File System253 A.7.15 Restoring the Primary Hard Drive ......................................... 255

vii

Contents

A.7.16 Restoring the Mirror ............................................................ 257 A.7.17 Restoring the System in General .......................................... 260

A.8 How to Shut Down or Reboot a System Properly.......................260

A.9 Apache Web Server ..................................................................261

A.10 Regular Expression....................................................................262

A.11 Setting of $RANDFILE .............................................................262

A.12 ORGA Alarm Definitions ...........................................................263 A.12.1 ORGA SNMP MIB Definitions ............................................... 263

A.12.1.1 OLS-CommonAlarmTrap.mib ........................................ 263A.12.1.2 OLS-CommonAlarmDefinitions.mib............................... 265

A.12.2 List Of Event Ids ................................................................... 270A.12.2.1 Trap Definitions ............................................................ 270

A.13 Bibliography .............................................................................272

I Index............................................................................. 273

viii

Introduction 1

1

4

5

6

3

2

7

A

I

The wIQ makes Web content (HTML) available to USSD-capable mobile phones. USSD is a feature of the GSM network.

wIQ makes even HTML content available via SMS and offers a Web interface for initiating messages (over USSD or SMS) from the wIQ to a subscriber.

With wIQ, network operators can offer services to their subscribers, which al-lows to gain access to Web content via non-WAP (Wireless Application Pro-tocol) and non-SAT (SIM Application Toolkit) capable phones in an easy, fast and convenient way.

The main advantages of the USSD service against WAP and SAT are:

Very fast connection setup

No WAP or SIM Toolkit capabilities of the phones required

Easy way of implementation of the new services for the network operator

1.1 Conventions

The following notational conventions are used in this manual:

Texts preceded by this symbol are parts of a list.

” ”Texts enclosed by quotation marks are references to other chapters or sec-tions.

1.) Texts preceded by a number describe activities that you must perform in the order indicated.

1

Introduction

1

4

5

6

3

2

7

A

I

BUTTON Push buttons and control boxes

<...> String wild card

File Directory structure or file

Process Processes and commands

Formats

...; * Wildcard ’*’ permitted as an entry

* Telephone key

# Telephone key

S Send button of the MS

d/t Date and time in ISO format (YYYYMMDDhhmmss)

[...] The entry is optionalEntry fields in the menu descriptions without this format defini-tion are mandatory.

{...} List of alternative options

...; RE Regular expression. stands for any character.* stands for any number of character^ must start with the following character$ indicates the end[n-m] specification of range

Text following this marker should be heeded in order to avoid er-rors.

Text following this marker represents general information that should simplify the installation process and avoid incorrect installa-tion.

2

Introduction

1

4

5

6

3

2

7

A

I

Example:^013.* numbers of any length, starting with 013^018[1-3]$ corresponds to 0181, 0182 and 0183^019[2-4]5$ corresponds to 01925, 01935 and 01945

BCD[...] Binary coded digit

boolean true or false, on or off, 1 or 0

n[...] Number string

c[...] Character string

h[...] Hexadecimal number

...[n...m] String with variable length from n to m

i 2 Byte integer number

l 4 Byte integer number

1.2 Abbreviation List

CDR Call Data Record

Dest Destination

e.g. for example

EMS Enhanced Messaging Service

ESMS Enhanced Short Message Service

GSM Global System for Mobile Communication

GUI Graphical User Interface

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

HTTPS Secure HTTP

Id Identity

i.e. this means

3

Introduction

1

4

5

6

3

2

7

A

I

IMEI International Mobile Equipment Identity

IMSI International Mobile Subscriber Identity

IN Intelligent Networks

IN-OPSC OPSC with Intelligent Networks support

IOWIQ Internet Originated wIQ ticket

IP Internet Protocol

ISDN Integrated Services Digital Networks

LOC Location of the cellular network

MAP Mobile Application Part

MIB Management Information Base (for SNMP)

MS Mobile Station

MSISDN Mobile Station ISDN Number

MTWIQ Mobile terminated wIQ ticket

NSG Network Service Gateway

NMS Network Management System

OLS ORGA Logging System

OPSC ORGA Billing System

OUM ORGA Unified Messaging

PDU Protocol Data Unit,

RAID Redundant Array of Inexpensive Disks

RSC Remote System Control

SAT SIM Application Toolkit

SC Service Center

SIM Subscriber Identity Module

SM Short Message

4

Introduction

1

4

5

6

3

2

7

A

I

SNMP Simple Network Management Protocol

Src Source

tcp transmission control protocol

TPDU Transfer Protocol Data Unit

TRID Transaction Id

UDH User Data Header

UDP User Datagram Protocol

URL Uniform Resource Locator

USSD Unstructured Supplementary Service Data

VTOC Virtual Table of Contents

WAP Wireless Application Protocol

WWN World Wide Number

wIQ wireless Information Query

5

Introduction

1

4

5

6

3

2

7

A

I

6

System Description 2

1

4

5

6

3

2

7

A

I

2.1 System Overview

The wIQ system makes HTML content accessible for mobile stations (MS) via USSD service or SMS. It acts as a gateway between the MS and HTML content servers.

For the MS, the USSD and SMS service is used. To access the content server, HTTP protocol is taken.

Because of the limitations of USSD / SMS in terms of display and USSD dialog capabilities, only a limited subset of HTML is supported. Sophisticated fea-tures like preinput and hotkey functions simplify the handling and increase the comfort.

The possibility to pass on subscriber identity information to URLs will also sup-port wIQ operators to realize subscriber-specific access control or personalized information.

1. USSD

Subscribers can request HTML content with their MS by dialing a USSD string (like *101# or *105*7110815# ) and by pressing theS button.

This message is sent to the network and routed to wIQ. The wIQ maps this USSD string to an HTML hyperlink and sends an HTTP request to the content server to request the HTML page.

7

System Description

1

4

5

6

3

2

7

A

I

The HTML page is then converted into a USSD message and sent to the MS.

In case the HTML page contains hyperlinks or input forms, which means that additional user interaction is required, a USSD request message is passed to the MS which waits for further input from the subscriber.

2. SMS

You will have the possibility to send and receive SMSs via wIQ.

Subscribers can request HTML content with their MS by entering an SMS.

This message is sent to the network and routed to wIQ. The wIQ maps this SMS to an HTML hyperlink and sends an HTTP request to the content server to request the HTML page.

You can enter

a URL or

a short cut or

a USSD string, e.g. *100#

(see also the section ”Call a wIQ Service” on page 30)

The type of entry has to be configured in wIQ, see sections 4.7 - 4.13.

The SMS can be internatialized. A different char set than GSM 7 bit can also be used.

You can also request HTML content via SMS by sending a URL or an abbrevi-ation (depending on the configuration) as a content.

Parsing respectively processing can depend on the receiver of the SMS. For dif-ferentSMS receivers, different URLs for the same content can be requested .

3. SMS/USSD

An interaction SMS/USSD can be performed which means that that you can start with a USSD session and get an SMS back, or you start a USSD session

Unlike USSD, no browsing is possible.

8

System Description

1

4

5

6

3

2

7

A

I

by sending an SMS. The following graphic shows this interaction:

If it is defined in HotKeySet.cfg to send the current USSD page as an SMS (’0’), you have to enter 0.

Another interaction between USSD and SMS is performed when an SMS is sent. An USSD session is started by the SMS.The following graphic shows this interaction:

4. Push

wIQ offers an interface which allows to initiate messages from the wIQ to a subscriber; see also the section ”Push Interface” on page 140.

9

System Description

1

4

5

6

3

2

7

A

I

Internet MobileSubscriber

HTTP request

wIQ

USSD/SMS

Acknowledgement

HTTP response

10

System Description

1

4

5

6

3

2

7

A

I

2.2 Description of the wIQ Process

The wIQ process is part of the interface between the mobile subscriber and the intranet/internet. The following diagram shows the purpose of the wIQ process:

wIQ system

The wiqd receives requests to load URLs via the ORGA USSD-GW Interface and serves these requests by connecting to the appropriate sites on the Inter-net. The wiqd listens on a configurable port for USSD-GW requests, translates these requests to URLs and tries to get these URLs from the internet. The wiqd then translates the contents of the URL to the USSD-GW protocol and sends the answer to the appropriate client.

2.3 External Requirements

wIQ is designed to cooperate with USSD implementation according to:

11

System Description

1

4

5

6

3

2

7

A

I

ETSI TS 100 974 V7.1.0 (1999-08)Technical Specification Digital cellular telecommunications system (Phase2+)

Mobile Application Part (MAP) specification (GSM 09.02 version 7.1.0 Release 1998)

2.4 HTML to USSD/SMS Conversion

One of the basic functions of wIQ is converting HTML content enriched by special tags into USSD/SMS text. For USSD, this also includes a very convenient way of browsing through content.

HTML links are numbered with configurable characters on the MS. The corre-sponding link text follows aside. Later input characters are matched to the corresponding link (if it applies).

The following table gives a brief list of possible tags:

Supported HTML Tags

Tag Start Tag End Description

<HTML> </HTML> Defines the HTML content in a document on a Web server, no attributes.

<HEAD> </HEAD> Defines the head section in an HTML docu-ment, no attributes.

<TITLE> </TITLE> Indicates the document’s title. It is dis-played as first line in the display. No attrib-utes.

<BODY> </BODY> Defines the body section in an HTML docu-ment, no attributes can be converted.

<P> New paragraph. It is converted to NEW-LINE.

12

System Description

1

4

5

6

3

2

7

A

I

<BR> Inserts a line break at the current position. Is converted to NEWLINE.

<A HREF=URL> </A> Indicates a document anchor, used to cre-ate links to other resources or to define a location that can be linked to. Each link is converted to a link ID, which is either a number or character according to mobile capability. A text derived from the link description in the content is printed after this link ID. A maximum number of 9 links is supported.

<FORM ACTION=URL METHOD=[GET|POST]>

</FORM> FORM input requests are translated into requests which are sent one by one to the MS.

<INPUT type=["text/hidden"]name=varname, value="value" for hid-den>

If input type is ’hidden’, ’value’ has to be specified. For input type ’text’, a value is not supported.

<meta http-equiv = "Content-Type" content = "text/html"; charset=<charset>"

A HTML tag indicates the character set the HTML page uses. This is done using the tag <meta> which can be used inside the <head> tag.

Supported HTML Tags

Tag Start Tag End Description

13

System Description

1

4

5

6

3

2

7

A

I

Example:

<HTML><HEAD>

<meta http-equiv = "Content-Type" content = "text/ht-ml"; charset=iso-8859-1">

<TITLE> ORGA MENU</TITLE></HEAD><BODY><A HREF="http://www.orga.com/news.html">News</A><BR><A HREF="http://www.orga.com/banking.html">Banking</A><BR></BODY></HTML>

It is recommended that the tag <meta> appears as early as possible in the head element.Even all text before <meta> with attribute content="text/html char-set =" is considered to be coded as defined in the <meta> tag.Only one <meta> tag with attribute content="text/html charset =" can be defined on a HTML page. All other <meta> tags with that attribute will be ignored. A warning will be printed.

Important for <input>:

If the message is UCS2, the value is URL encoded UCS2 UTF-8.

14

System Description

1

4

5

6

3

2

7

A

I

This example is converted by the wIQ to the following USSD output on the MS display; see also section ”HotKeySet.cfg: Configuration File for Character Sets” on page 102:

Example menu on MS display

2.4.1 wIQ-specific Tags

Some special tags which allow to set or override wIQ parameters:

<wIQ [provider="{provider_string}" coins="{coin_value}"]

[bearer="{bearer_string}"]

[aparty="{msisdn}"]

[smsinterface="{interface_string}"]

[ussdmode="{ussd_string}"]

[forcedisplay="{0,1}"]

/>

2.4.1.1 Values / Attributes

There are different session attributes which may be reset by HTML wIQ at-tributes.

All these attributes are optional. Except for ’forcedisplay’, they only override the session attributes if the value is valid and the HTML page has the permis-

15

System Description

1

4

5

6

3

2

7

A

I

sions to override the settings (see the table ”Valid URL : Permissions to Over-ride Session Configuration from HTML Contents” on page 89).

Additional wIQ Tag Attribute Description

Attribute Values Description

bearer(see section ”’SMS to Service Mapping’ Table: Fields” on page 90)

{ FINISH, BROWSE, SMS, FINISH-SMS}

Set the session mode and bearer.Overrides:either ’USSD to URL Mapping’ field ’SessionType’or’SMS to Service Mapping’ field ’Bearer’.

forcedisplay {0,1} Interrupts the processing of preinput.

The following attributes are only used if the response is sent over SMS:

aparty(see section ”’URL to SMS Interface Mapping’ Table: Fields” on page 95)

BCD[1..20] The MSISDN which is used as A-Party.Overrides:’URL to SMS Interface Mapping’ field ’A-Party’

16

System Description

1

4

5

6

3

2

7

A

I

Example HTML Page

<HTML>

<HEAD>

<WIQ PROVIDER="ORGA"

COINS="50"

BEARER="SMS"

USSDMODE="REDISPLAY"

SMSINTERFACE="MAPSMS0"

APARTY="99999999999999"

/>

<TITLE> ORGA SMS PAGE </TITLE>

</HEAD>

<BODY>

smsinterface(see section ”’URL to SMS Interface Mapping’ Table: Fields” on page 95)

{MAPSMS0, MAPSMS1 (optional), MAPSMS2}

The mode for sending SMS.Overrides:’URL to SMS Interface Mapping’ field ’SMSInterface’

ussdmode(section ”’URL to SMS Interface Mapping’ Table: Fields” on page 95)

{FINISH, BROWSE, REDISPLAY}

The action on USSD after sending an SMS.Overrides:’URL to SMS Interface Mapping’ field ’USSDMODE’

Additional wIQ Tag Attribute Description


17

System Description

1

4

5

6

3

2

7

A

I

This page makes its own session settings

</BODY>

</HTML>

2.5 Using USSD

2.5.1 Subscribers’ Input Interface

There are different input scenarios, depending on the current state of interac-tion.

2.5.1.1 Subscribers’ First Login (Self-registration)

Due to the different implementations of the ’prompt’ (USSD input) mode on various types of handsets, a kind of configuration process is needed while the subscriber logs in for the first time.

There are different possibilities to perform this configuration:

Before the subscriber’s first use of the wIQ, the configuration is set up by the operator.

While the subscriber is logging in for the first time by using default values which are configured by the operator.

While the subscriber is logging in for the first time by redirection to a spe-cial HTML page which is designed for subscriber self-configuration.The operator can design this configuration dialog himself, even if there is a default given in wIQ.This dialog is designed in standard HTML with HTML input form and the use of the Web interface of the subscriber-specific database.

All these configuration sequences perform an insertion of a database record for the subscriber’s MSISDN with subscriber-specific configuration data as ex-plained in section ”Subscriber Database” on page 37.

Inside wIQ, three basic components will complete the implementation:

The configuration dialog

This is the task of the wIQ operator, even if wIQ gives a default.

18

System Description

1

4

5

6

3

2

7

A

I

PHP Interface to a subscriber-specific profile data

This is the interface where to put subscriber-specific profile data after a Web-based configuration dialog.

Runtime access to subscriber-specific profile data.

By means of this, wIQ detects not configured MSISDNs, finds the URL mapping table, and picks up the HTTP-access table. It is the interface where to put the statistic session data.

Example for a simple subscriber’s self-configuration:(For HTML-sources, cf. section ”HTML Pages for Keytable Configuration” on page 232).

Subscriber’s redirection to a special HTML-page

To allow a subscriber to change his/her database entries, we suggest to design a second configuration page and to reserve a service number for it.This is needed either if the subscriber does something unexpected during the

19

System Description

1

4

5

6

3

2

7

A

I

first configuration process or if the subscriber changes his handset to another type.

20

System Description

1

4

5

6

3

2

7

A

I

2.5.1.2 Call a wIQ Service

To call a wIQ service, a subscriber has to type a service number which is de-fined by the customer. According to USSD-specification, this number must fol-low one of these formats:

1, 2 or 3 digits from the set (*, #) followed by a numeric service number, and finished with a # S.

A series of * digits can follow this service number. It will be treated as pre-input for a service identified by the service number. This feature is used for RAPID URL access as described in the section ”Rapid URL Access” on page 23 or for direct parameter passing (see the section ”Fast Access to URL with Di-rect Parameter Passing” on page 34).

7Y S, where Y = any number from 0 - 9

If a wIQ service needing further input is called for the first time, a session starts. This means that further input needs no service number in front. Input will be passed directly to the session. Typically, this is browsing through the defined Web pages.

Commands to Start a wIQ Service

Entry Format: <service prefix><service number>[*<preinput>]#S

service prefix 1, 2, or 3 digits from the set (*, #)

has to be defined by the cus-tomer in the USSD to URL Mapping table (see page 78).

service number NNN has to be defined by the cus-tomer in the ’USSD to URL Mapping’ table (see page 78).

preinput A maximum of 19 * digits is used as an input to the desired service

This could be a link number, input to a form, input to a script, or could be used for the ’USSD to URL Mapping’ table.

21

System Description

1

4

5

6

3

2

7

A

I

or alternatively

Entry Format: 7<service number>S1

Example:

*100#Scall the wIQ service *100# http://www.orga.com

#100*1#Scall the wIQ service #100*1# http://www.orga.com/news.html

#101*2*3#Scall the wIQ service #101#. The preinputs 2 and 3 are passed as parameters to the service #101#; see also the table "USSD to URL Mapping Table" on page 78.

*130*100#S

is directly mapped to an URL. The preinput 100 is used for the mapping and not as preinput for the page.

Access URL by Service Number

A list of specific numbers will be mapped to URLs. For a subscriber, these are all possible entry URLs to start browsing.

1 It seems that this can not be handled by all mobiles correctly, e.g. a Siemens C25 or Nokia 8210 makes a call when entering such a code. Only newer mobiles seem to handle this right.

service number N has to be defined by the cus-tomer in the ’USSD to URL Mapping’ table (see page 78).

Processing preinput can be interrupted by using the wIQ-HTML tag attribute’ forcedisplay’.

22

System Description

1

4

5

6

3

2

7

A

I

The table ”Ussd2URL.cfg*: ’USSD to URL Mapping’ Table” on page 78 de-fines the coherence between URL and service number. It has to be maintained by the wIQ operator. At least one is necessary to act as a pointer to an URL.

The decision to use lots of service numbers, to reduce the depth of the brows-ing tree, or to limit the quantity of service numbers and move selection deci-sions down into HTML context is up to the customer.

Rapid URL Access

To speed up access to URL for routine subscribers, preinput is used to wind up the affected Web page tree.

A service number extended with a selection number separated by * (e.g. *105*1#S) which is not matched in total by the mapping table causes automated browsing through the hyperlinks to the destination URL by skipping the pages in between.

Preinput is not affected by HotKeySet.cfg and HandSetID.

The following example gives an illustration:

A subscriber wants to have rapid access to the Weather News of Santiago.

Instead of invoking the index URL with *105#S and selecting the weather link by entering 2S and afterwards going to Santiago with 3S, he just types *105*2*3#S to directly access the Santiago weather page. This will result in skipping the following pages:

A preinput ’1’ will always select the first link!

It may be affected by Ussd2URL.cfg* ? if e.g. the service *105*1# is configured.

23

System Description

1

4

5

6

3

2

7

A

I

The following page is displayed directly:

24

System Description

1

4

5

6

3

2

7

A

I

This allows a direct jump to URL which shortens the browsing time and will also reduce network load.

2.5.1.3 Browsing in an Open Session

The subscriber can call a wIQ service (see section ”Call a wIQ Service” on page 21) or use hotkey functionality in an open session.

Subscribers will be able to go backwards, forward and "Home" during their session. After finishing a session, no history is stored. A maximum context of 10 pages is stored for each session in a first-in-first-out manner.

In addition, a user may go backwards by entering *S and forward (after go-ing backward) by entering #S and “jump” to the carrier-defined homep-age/start page by entering *#S.

Entry Format: <hotkey>[*<preinput>]S

In the following table, some examples are shown:

25

System Description

1

4

5

6

3

2

7

A

I

Examples for HandSetID ’1’:

*S go back one page in history

#S go forward one page in history

*2*3S go back one page and pass the preinput 2 and 3 tothe new service

1*2*3S choose link 1 of the actual page and pass the preinput2 and 3 to the new service.

*#S jump to the carrier defined homepage

##S end of a session

*100#S jump to service number *100#

ID Input Character Set Output Character Set

1 123456789*0# 123456789

2 abcdefghij*0# abcdefghij; see also section ”Hot-KeySet.cfg: Configuration File for Character Sets” on page 102.

26

System Description

1

4

5

6

3

2

7

A

I

Handset which Other handset:switches toalpha mode2:HandSetID=’2’ HandSetID=’1’

Subscriber-specific input interpretation

2 The first character you get by pressing a key is a letter

27

System Description

1

4

5

6

3

2

7

A

I

2.5.1.4 Controlled Preinput Processing

Controlled preinput processing allows to stop automatic processing of a pre-input chain if one or more pages in this chain shall be forced to be displayed. This is done by using an attribute to the wIQ-HTML tag called ’forcedisplay’. If this attribute is set to "1" on a HTML page, no further preinput is processed and the current page is displayed.

Example:

The operator offers a service where the subscriber has to agree the license terms for that special service every time. It shall not be possible to skip this page by preinput. The subscriber has to request the service *100#, and then follow link 1 and then 2 to get to this certain license agreement page.

Link one on that license agreement page will be "Yes, I agree to the license terms and want to continue". So by entering *100*1*2*1# the subscriber would normally skip the license agreement page and directly agree.

Now by writing

<wIQ forcedisplay="1"/>

on the license agreement page, the operator can force to show this page and discard possible remaining preinput.

The subscriber enters the scenario described here:

*100*1*2*1#

Because of the ’forcedisplay’ attribute set to "1" on the license agreement page, the result of

*100*1*2#

is now displayed and the remaining preinput *1 is discarded.

Both subscribers will have to enter *105*2# to get rapid ac-cess to this page. The interpretation of input only differs in the browsing mode and only affects the hotkey functionality.

28

System Description

1

4

5

6

3

2

7

A

I

2.5.1.5 Session End

There are three different methods to end a session:

Subscriber End Command The subscriber ends a session with ## S as an answer to a prompt.

Timeout If the subscriber does not respond to a prompt for a period greater than wIQ.TimeOut or the HTML-page can not be loaded during this period, the wIQ ends the session.

Special Service Numbers If the session starts with a service number which is configured as "FINISH" in the Ussd2URL.cfg* file (see section ”Ussd2URL.cfg*: ’USSD to URL Mapping’ Table” on page 78) then the session ends after displaying the first page without links or forms. If ’BROWSE’ is definded, the session stays until a timeout occurs or the subscriber sends ## S.

29

System Description

1

4

5

6

3

2

7

A

I

2.6 Using SMS

There are different input scenarios, depending on the current state of interac-tion.

2.6.1 Subscribers’ First Login

There is no self-registration when using SMSfor the first time (and USSD has never been used before). If USSD was used before, the setting will be used and an entry from the DBDefaults.cfg is taken instead (see section ”DB-Defaults.cfg: ’MSISDN-Dependent Database Defaults’ Table” on page 97).

2.6.1.1 Call a wIQ Service

SMS

To use SMS with wIQ, the subscriber has to send an SMS to a telephone num-ber. This number is configurable and can be configured inside wIQ.

The content can contain:

1. an URL, e.g. http://www.orga.com

2. a short cut, e.g. LH 10.10.2001 DUS FRA Dep

3. a USSD string, e.g. *1001*1# depending on the configuration.

(see also page 8).

URL by service number and rapid URL access are supported (see page 22).

The following examples are to be seen as customer-dependent configurations and are only to serve as an example.

30

System Description

1

4

5

6

3

2

7

A

I

SMS/USSD Interaction

The following page is displayed:

’0’ is configured as ’Send also as SMS’ (see section ”HotKeySet.cfg: Configu-ration File for Character Sets” on page 102).

USSD

USSD(Browsing)

31

System Description

1

4

5

6

3

2

7

A

I

The following page is displayed directly:

The USSD session is ended now (it may continue for other configurations).

The SMS arrives:

The SMS can now be saved.

2.6.2 Supported Types of SMS

wIQ supports to send short messages as text messages with 7-bit coding. As a normal short message has a maximum length of 160 characters, larger mes-sages will be truncated at this border.

For UCS2 messages the maximum length is 70 characters.

USSD

SMS

32

System Description

1

4

5

6

3

2

7

A

I

2.7 Push

wIQ offers a new interface which allows applications to initiate messages from the wIQ to a subscriber.

2.8 HTML Input Formats

wIQ supports the access to HTML pages which need to get input (HTML forms) which is valid for USSD.

These could be used to poll for PINs or account numbers for example (see also section ”HTML to USSD/SMS Conversion” on page 12).

2.9 Subscribers’ Identity Directly to URLs

The subscriber parameters (see table ”Valid URL Variables” on page 86), e.g. MSISDN and LOC (Location) can be passed directly to URLs. The operator is free to configure who can use it and how to use it.

For example: to permit or restrict access to certain URLs.

Configuration is done in a variable inclusion table (see page 84).

All valid URLs are defined in this table. Therefore regular expressions are al-lowed to minimize the table size.

The wIQ puts these variables and their value (if available) into the HTML con-text environment as

e.g. HTTP_MSISDN and HTTP_LOC

(see also the table ”Valid URL Variables” on page 86).

33

System Description

1

4

5

6

3

2

7

A

I

2.10 Fast Access to URL with Direct Parameter Passing

Depending on the URL tree defined in the ’USSD to URL Mapping’ table (see also the table ”Ussd2URL.cfg*: ’USSD to URL Mapping’ Table” on page 78), the subscriber’s preinput will be passed directly to URLs as an input.

2.11 HTML Conversion to Mobile Phone-Specific Character Set

The possibility to print specific characters in GSM standard alphabet (for ex-ample: $) depends highly on the handset product and the MAP version of net-work and handset.

Because of the limited characters in GSM standard alphabet ( see also page 225), the wIQ uses an internal mapping table to handle special charac-ters from ISO-LATIN-1, which are not supported in GSM standard alphabet. These characters are either displayed as a ’?’ or mapped to a similar looking character (see also section ”Supported Characters from the GSM-Default Al-phabet” on page 225 and section ”Mapping from HTML 3.2 to USSD/SMS” on page 226.

wIQ is prepared to use handset-specific configuration tables in future releases, but the current release is delivered with one default character mapping table only; see also page 225.

wIQ is able to receive UCS2 messages and therefore another character set.

2.12 Constraints

USSD Phase 1 does not support dialog capabilities.For Phase 1 phones, only direct page access is possible without browsing functionality or input dialogs.

Please note that the realization of URL pages defines which input value is used as a selection of a URL or is passed in as an input value to an HTML input form.

34

System Description

1

4

5

6

3

2

7

A

I

With SMS, there is no browsing possible.

2.13 Multiple Language Report

The system supports the use of multiple languages when communicating with subscribers.

The language to be used for the communication with the subscriber is set us-ing the 'Accept-Language' header of a HTTP request, see section X in the ap-pendix of this manual. A Web server interprets this header information and returns the appropriate HTML document in its response, therefore supporting multiple languages 'automatically'.

2.13.1 Preferred Language Set in the Subscriber Database

If the preferred language has been set and is available in the wIQ Subscrib-er Database record of the subscriber, wIQ sets the 'Accept-Language' header of each HTTP request according to the setting in the wIQ Subscrib-er Database.

As a result, all pages requested by the subscriber (either internal wIQ pages or external pages from the CRM) are displayed using the subscriber's preferred language.

35

System Description

1

4

5

6

3

2

7

A

I

36

Databases 3

1

4

5

6

2

3

7

A

I

3.1 Subscriber Database

Due to the very high performance requirements, the ORGA Incore Database is used to store the subscriber-specific data.

The database is automatically set up and restored from the latest Dump and Journal File by the start script wIQd.All changes are logged into $ORGADATA/IncoreJournal/Subscriber_jnl.<number>.Normally the contents of the database are dumped to $ORGADATA/In-coreDump/Subscriber_dmp.<number> once a day.

3.1.1 Interfaces

PHP-Interfaces

wIQ provides a PHP-based interface to access the database. Via this interface it is possible for the operator to set up a registration scenario for the subscrib-er. In addition, the operator can use the same interface to access subscriber-related data via a standard Web browser.

This function may be used in PHP pages on the wIQ´s Web server.

The $DOCUMENTROOT of the Web server is $ORGAROOT/apache/htdocs.

37

Databases

1

4

5

6

2

3

7

A

I

USAGE:

To use the PHP function the following line is needed to load the Incore inter-face:

<?phpdl("libphp_incore.so");...?>

incore_action() allows nearly the same functionality which is possible with the unix commandline interface opsc_adb except select loops. For complete information about the commandline syntax, please read the online manual pages IncoreDatabase and opcs_adb.

Function: $return_array=incore_action($Database-name,$CommandLine);

Arguments: $Databasename The name of the database ("Subscriber")

$CommandLine The CommandLine

Result: The return of the function is an associated array which contains at least one entry.If an error occurs, the function will returnone array entry ["result",<ERROR_CODE>] and another entry with the description of the error ["ERROR",<Description>]ERROR_CODE is always < 0 !

38

Databases

1

4

5

6

2

3

7

A

I

Commandline Syntax:

#d <Search Condition>Deletes a subset of database rows. The returned array contains the entry ["result",<number of deleted lines>] if the command was successful.

#s <Fields> <Search Condition>Select one database row which matches the search condition.

The returned array will contain all given fields with the relating database entry. If the PHP interface does not allow to select loops, the result of a search will always be ’A’, if at least one entry is found that matches the search conditions.

#i <Fields> <Search Condition> <Host Variables>Insert a new database row and set the specified fields.

The returned array of successful insertion would be ["result",1]

#I <Fields>Query about the type of fields in the database and database usage. The returned array will contain all given fields with the information.

#u <Fields> <Search Condition> <Host Variables>Update a subset of fields in rows of the database.

On successful execution the returned array will contain exactly one entry ["result",<number of updated rows>].

<Fields>To identify a set of fields, each field name must be prefaced with a leading colon (:). To separate fieldnames, at least one blank must termi-nate the field name. If a field name was not found, an error is returned.

<Search Condition>$ <comparison type> <field> '<value>'

39

Databases

1

4

5

6

2

3

7

A

I

The search condition always starts with a '$' and is followed by one of the following compare types:

> Greater than

>= Greater or equal

< Less

<= Less or equal

= Equal

~= Case insensitive equal (for strings only)

~<= Case insensitive less or equal (for strings only)

~>= Case insensitive greater or equal (for strings only)

~< Case insensitive less (for strings only)

~> Case insensitive greater (for strings only)

= Equal

!= Not equal

true always true

false always false

To combine two or more compare functions, the following functions which accept only true/false values can be used:

Function Description

and combine two true/false values using the logical and.

or combine two true/false values using the logical or.

40

Databases

1

4

5

6

2

3

7

A

I

<Host Variables>This part always begins with a '&' and is followed by the description from which database fields have to be updated.

Examples:

Delete all MSISDNs with last date of use before 1 March 2000and Tariff-Group = 1: #d $ < and :LastUseDate '20000101000000' = :Tariff-Group '1'

Insert a database row: #i :MSISDN :InstallationDate :HandsetId :UssdGroup\ :TariffGroup :Phase1 & '6763274' '20010101235959' '1' '1' '1' '0'

Get the entries for subscriber with MSISDN '6763274': #s :MSISDN :InstallationDate :HandsetId :UssdGroup\:TariffGroup :Phase1 $ = :MSISDN '6763274'

Change the HandSetId for subscriber with MSISDN '6763274': #u :HandSetId $ = :MSISDN '6763274' & '5'

Commandline Interfaces and Database Tools

There are also a number of unix command line tools for managing the data-base.

opsc_adb Commandline interface to the database.

opsc_createdb Creates the database memory segments

opsc_destroydb Destroys the database and frees all systemresources.

opsc_dumpdb Reads the whole database and writes it to a readable file DumpFile or restores the database from DumpFile.

opsc_showdb Displays information about the structure of the database or about the contained data.

41

Databases

1

4

5

6

2

3

7

A

I

opsc_exadb Examines the OPSC database journal and dump files.

opsc_recoverdb Recovers the Incore database DatabaseName from the dump file DumpFile and optionally the journal files JournalFile. The dump file and the journal files are normally generated by opsc_svrdb.

opsc_svrdb Collects changes to the OPSC Incore database DatabaseName and records them in the current journal file. opsc_svrdb can also dump the Incore database while not affecting application access to the database.

For further information read the unix manual pages located in$ORGAROOT/run/man.

The database contains two different kinds of data relating to a subscriber’s MSISDN:

User-specific configuration data

– handset-specific

– logical

wIQ controls which subscriber is allowed to use what services. This is used for all kind of wIQ requests (SMS and USSD) and will be looked up even if SMS services are not enabled within the wIQ license.

USSD/SMS Messages from or to subscribers who are not allowed to use this wIQ service will be ignored. This are subscribers which have no entry in the field ’AllowedServices’ or not being allowed for a special service.

User-specific statistics

The first one is user-specific configuration data. This kind of data is used by the wIQ for the personalization of the wIQ behavior, e.g. the definition of in-put interpretation or the definition of output style.

Another possibility is the personalization of USSD-code to URL mapping.With this, the operator (or the subscriber himself/herself via an operator de-veloped interface) is able to assign a special group with a relating USSD to URL Mapping’ table. These tables will be implemented as different files in $ORGA-DATA/cnf.

42

Databases

1

4

5

6

2

3

7

A

I

The data are set if the subscriber uses the service for the very first time by re-directing him/her to a special page or using possible given defaults.

In the following table, some important entries are shown:

Entry Type Description

MSISDN BCD[20] Subscriber identification.

HandSetId l Handset identification number.This one is used to determine the character set which should be used for this subscriber.

UssdGroup c[1..63] Assigns the subscriber to a spe-cial USSD to URL Mapping.

Phase 1 0, 1, 2 Determines the map version, supported by the MS.

Services==>AllowedServices

i This field can contain a combina-tion of the following values:

bit 1 NONE: subscriber is not allowed to use any services.

bit 2 ALL: all services are allowed for this subscriber.

bit 3 SMS to SMS: Pure SMS services are allowed for this subscriber.

bit 4 SMS to USSD: An SMS request with USSD answer is allowed for this subscriber.

bit 5 USSD to SMS: SMS initiated by a USSD session is allowed for this subscriber.

43

Databases

1

4

5

6

2

3

7

A

I

bit 6 USSD to USSD: Pure USSD ser-vices are allowed for this sub-scriber.

bit 7 Subscriber is allowed to initiate an SMS to himself.

bit 8 Subscriber is allowed to initiate an USSD message to himself.

bit 9 Subscriber is allowed to initiate an SMS to himself and other subscribers.

bit 10 Subscriber is allowed to initiate an USSD message to himself and other subscribers.

CostInfo 0, 1, 2, 3, 4, 5

See section ”Subscriber Informa-tion” on page 125.

PushCtl 0, 1, 2 Subscriber Push privacy settings:0: No Push allowed to the

subscriber1: Push allowed if sender is

recipient2: Push allowed from anyone

language c[2] Country code of the subscriber’s preferred language, e.g. ’en’ or ’ro’.


44

Databases

1

4

5

6

2

3

7

A

I

IMEIRequestMethodIMEIKeyThe second kind of data is subscriber-statistic data produced by the wIQ which is shown in the following table:

PrefCharSet 0, 1, 3, 5, 7

Values are coded as bits. Valid values are: 0 - ignore language selection1 - SMS locale, USSD locale3 - SMS ISO,

USSD locale5 - SMS locale,

USSD ISO7 - SMS ISO,

USSD ISOlocale = as specified in ’wIQ.localeCharSet’ISO = ISO-LATIN1

IMSI BCD[20] The IMSI is stored in the database as BCD value and can have a length of up to 20 digits.Note that there is no field for the IMSI in DBDefaults.cfg, because it makes no sense to set a default for the IMSI.


PIN BCD[4] The personal identification num-ber (for future use).

InstallationDate d/t The date of database entry cre-ation.

FirstUseDate d/t The date of the first service usage.


45

Databases

1

4

5

6

2

3

7

A

I

3.2 Group-Specific USSD to URL Mapping and Valid URL

3.2.1 Brief Description

In order to make the USSD to URL Mapping more flexible and comfortable, the operator is able to assign subscribers to special groups of subscribers. This can be for example, a group of subscribers with the same tariff group or with the same interests. This allows an operator also to restrict the access to special services.

Each group will have its own ’USSD to URL Mapping’ table in $ORGADATA/cnf.

This feature allows the operator to have different URL mappings for one ser-vice number.

3.2.2 How to Assign a Subscriber to a Group

There are different possibilities to assign a subscriber to a special group.

Only the operator is able to assign a subscriber to a special group.

The subscriber is able to assign himself/herself to a public group.

LastUseDate d/t The date of the last service usage.

SessionNum l Total number of sessions.

SessionTimeLast l Time in seconds of last session.

SessionTimeTotal l Total time in seconds of all ses-sions.

RequestNumTotal l Total number of requests.

RequestsNumSession l Number of requests in last ses-sion.


46

Databases

1

4

5

6

2

3

7

A

I

The subscriber is able to join into public groups, but only the operator is able to assign the subscriber to special private groups.

The configuration data are saved in the subscriber-specific database. So the interface is the same as in the example "Subscriber-specific input interpreta-tion" on page 27.

Example:

The operator defines two different groups of subscribers. The first group of subscribers is assigned to ID ’1’ and the second group is a group of subscribers which is assigned to a group with ID ’2’. A third group of users is unassigned. Unassigned subscribers or subscribers with invalid group number are assigned the global ’USSD to URL Mapping’ table.

The operator now has the possibility to reserve special USSD numbers for spe-cial use only for a special group of users.

Configuration:

There have to be three Ussd2URL files:

If now a subscriber who is assigned to group ’1’ requests the service number *110#, he/she will get the page www.tabacco.xyz. If the same subscriber requests the service *120# he/she will get an error message, as the USSD service 120 is not mapped to any URL for subscriber group 1.

Ussd2URL.cfg.1 Ussd2URL.cfg.2 Ussd2URL.cfg

*110# www.tabacco.xyz *110# www.food.xyz *100# www.orga.com

*120# www.banana.xyz *110# www.weather.cl

*120# www.news.cl

47

Databases

1

4

5

6

2

3

7

A

I

48

Configuration 4

1

2

5

6

3

4

7

A

I

The wIQ daemon (wIQd process) is configurable via the commandline, a con-figuration file, and depends on the license string.

4.1 Start and Stop Procedure

4.1.1 wIQdThe process wIQd sets up the whole enviroment for wIQ including the sub-scriber database and the Web server.

Options:

start [-F] [-A] [-W]Sets up and restores subscriber database,starts the database dumper and logger and starts a number of wIQ main processes.

-F: Forces database start without existing dumps-A: Leaves the database untouched -W:Also starts the Web server

check Reports the state of the started processes, the database.

stop [-A] [-W]Stops all started processes and destroys the database.

-A: Leave the database untouched -W:Also stops the Web server

49

Configuration

1

2

5

6

3

4

7

A

I

reconfigure This will send all wIQ processes a SIGUSR2 which causes a reread of all configuration files (see also section ”Signal Handling” on page 65).

restart [-F] [-A] [-W] Restart missing processes if the processes have been started with wIQd start and have not been stopped with wIQd stop.If no existing database is found, the database will be restored from the latest database dump and journal files.If there is no running server, the Web server is restarted.

-F: Allow a database restart even if no dumps are found.-A: Do not restart the database.-W: Restart Web server if not running.

failover Force a failover if entered at wIQguard local mode machine (rec-ommended: use -w).

-V: Edit the wIQd process table with vi.

Flags that are used by wIQ, but are also passed through to wIQguard are:-D: Switch on debugging output.-W: Start or stop the Web server (depending on command given).

All additional flags will be passed directly to wIQ, e.g.-F: Force database start without dumps.-U: Dump database on start.-A: Leave the database untouched.

4.1.2 wIQd Process Table

The processes started by wIQd have to be listed in the wIQd’s process table $ORGA-ROOT/run/etc/wIQd_proc_table in the following format:

Identifier Command-line

The Identifier is a unique identifier for the instance (e.g. wIQguard). This pa-rameter must not contain any non-printable characters or white space. The Command line parameter contains the complete command line needed for this instance to work. This command line may contain spaces.

50

Configuration

1

2

5

6

3

4

7

A

I

Example:wIQguard wIQguard -t

4.1.3 wIQd.cfg

The following configuration variables (in $ORGADATA/cnf/wIQd.cfg) de-fine wIQd´s behavior if set, otherwise default values are used:

Variable Description

wIQd.Alarming 0 - Alarming is disabled1 - Write alarm file. This will configure the Alarm-Logger accordingly.2 - SNMP support will be enabled Default: 0

wIQd.Logger The Logger command. Usually this should be the AlarmLogger.Default: AlarmLogger

wIQd.AlarmFile Alarm file that is written from AlarmLogger.Default: $ORGADATA/log/Alarm

wIQd.LoggerPipe Unix pipe the logger reads its input from and all processes are redirected to write their output to. Normally there is no need to change this value.Default: $ORGADATA/.logger

wIQd.LoggerTime-out

The timeout period that has to pass before the logger itself is killed after a wIQd stop is done. The logger must live longer than all other pro-cesses!Default: 5

wIQd.Snmp The command started to generate SNMP-Traps Default: stsc_snmp

51

Configuration

1

2

5

6

3

4

7

A

I

Lines starting with a # are treated as a comment. All path names can be ab-solute or relative to $ORGADATA.

Sample wIQd configuration file:

#wIQd Configuration file

#Values are shared with wIQguard

#SNMP(2), AlarmFile (1) or no alarming,(0). Default is 0

wIQd.Alarming=1

#Logger command. Default is AlarmLogger

wIQd.Logger=AlarmLogger

#Logger kill timeout

wIQd.HttpdPidfile Pid file of the Web server. This has to match the definition in the httpd.conf file.Default: $ORGAROOT/apache/logs/httpd.pid

wIQd.StartWeb-server

Should the Web server be included in starting and stopping (1) or not (0). This has the same effect than the –W flag.Default: 1

wIQd.Netcat If you want to use netcat, define its commandline here*.Netcat is not used by default.

* You then should also add the script watch_netcat to wIQguard’s proc table (see 4.1.4) in order to guard netcat (wIQd simply starts and stops netcat).


52

Configuration

1

2

5

6

3

4

7

A

I

wIQd.LoggerTimeout=2

#Alarm File. Defaults to $ORGADATA/log/Alarm

wIQd.AlarmFile=log/Alarm

#Logger pipe. Defaults to $ORGADATA/.logger

#wIQd.LoggerPipe=.logger

#Pid file of httpd according to httpd configuration.

#Defaults to $ORGAROOT/apache/logs/httpd.pid

wIQd.HttpdPidfile=/tmp/apache.pid

#Start webserver (1) or not (0). Default is 1

wIQd.StartWebserver=1

#If you want to use netcat, set the follwoing line to send #alarms there.

wIQd.Netcat="netcat od-scp-1 7334"

4.1.4 Failover

For a working failover, the wIQguard must be started on each server.One wIQguard is started as ’active’, one as ’remote’. When the active process detects that its wIQ processes are not working properly, it exits and stops all wIQ processes. The standby wIQguard detects this and starts. In case of an hardware or network problem, the standby wIQguard will detect this, too. The standby wIQguard will be the active from now on. When both (active and

53

Configuration

1

2

5

6

3

4

7

A

I

standby wIQ server) IP addresses are configured at the NSG, the NSG will switch automatically to the new server in an failover case.

The wIQguard can be called with the following parameters:

- The active wIQguard supervises the running wIQ processes.

- The standby wIQguard synchronizes the database and checks if the active wIQguard is still running.

- The configuration files are synchronized.

- The wIQguard is started automatically when an INIT script exists. (in fact, wIQd is started which will call the wIQguard).

- wIQguard may not be started/stopped directly. It will be started/stopped by using wIQd (which will call wIQguard).

Parameter Description

-l or --local Start wIQguard in local mode (this machine is the active server).

-t or --test-remote If this machine should start in local mode:First try to check if the other side is running in local mode. If it is so, start in remote mode; other-wise start in local mode.

-r or --remote Start wIQguard in remote mode (this machine is the standby server and might become the active one).

-h or --remotehost The host name of the other (active or standby) host.

-c or --config<config. file>

Name (relative to $ORGADATA) of the wIQguard configuration file. Default file name is:cnf/wIQguard.cfg

54

Configuration

1

2

5

6

3

4

7

A

I

-s or --syncconfig<file name>

Name (relative to $ORGADATA) of the file which contains the files or directories (one per line) to sync from the active/running system to the standby system. Default file name is:cnf/wIQguard-sync.cfg

-e or --sync-exclude<file name>

Name (relative to $ORGADATA) of the file which contains the files (one per line) to exclude from sync. Default file name is:cnf/wIQguard-exclude.cfg

-U or --dump Dump database startup

-D or --debug Turn on debugging.

-F or --force Start even if no database dump is available.

-A or --attach Attach to already existing database.

-N or --nodumps Read environment variable NODUMPDBS which defines which databases do not need a dump to start (see also -F).

-W or --webserver Start Web server (Web server will NOT be stopped by wIQguard!)

check or --check Check the status of all processes launched by wIQguard and the remote system.


55

Configuration

1

2

5

6

3

4

7

A

I

The wIQguard can be configured with the following file:$ORGADATA/cnf/wIQguard.cfg

-fs or --force-sync Force sync on startup. All files are replicated from remote host on startup, even if local mode is con-figured. If remote mode is configured and an wIQguard error or too old alive file is replicated from the other host, an immediate failover takes place. Note: Usually this option should not be set, it is used when forcing a failover.

--help Prints usage message.


wIQguard.MaxStart Number of process starts before wIQguard assumes that wIQ and other processes have a problem.Default: 10

wIQguard.LocalSleep-Time

The number of seconds to sleep between wIQ-guard´s local monitoring checks.Default: 30

wIQguard.KillWait-Time

Time to wait between kill -Term and kill -KILL.Default: 5

wIQ-guard.RemoteSleep-Time

The number of seconds to sleep between wIQ-guard´s remote monitoring checks.Default: 60

wIQguard.Remote-Host

The hostname of the guarded server.Default: mandatory, if not set via commandline


56

Configuration

1

2

5

6

3

4

7

A

I

wIQguard.Mode The mode the wIQguard shall start in (local or remote). Local mode can be overridden with the -t flag. This variable will only be read from the config file if wIQguard is started without --local, --remote, –l or –r parameter set!Default: mandatory, if not set via commandline

wIQguard.PingNum The number of times a ping is tried.Default: 3

wIQguard.PingWait The number of seconds to wait between ping tries.Default: 10

wIQguard.OkFile The filename of the OK file.Default: $ORGADATA/wIQGuardStatus.OK

wIQguard.ErrorFile The filename of the error file.Default: $ORGADATA/wIQGuardStatus.Error

wIQguard.SvrdbOptions

Options to be passed to opsc_svrdbDefault: -d1 –h2 –b

wIQguard.DestroydbOptions

Options to be passed to opsc_destroydb. It might be useful to pass ‘-f’ to force destruction when processes are still connected, e.g. CGI scripts.

wIQguard.wIQTime-out

Maximum age of the local alive file (in seconds) before it is believed to be outdated.Default: 90

wIQguard.RemoteTimeout

Maximum age in seconds of the remote alive file (wIQguard.OkFile) before it is believed to be outdated.Default: 120


57

Configuration

1

2

5

6

3

4

7

A

I

wIQguard.RsyncTim-eout

This sets the IO timeout (in seconds) for rsync syncing a file in seconds. This timeout might interrupt transmissions of big files, so be care-ful!Note: 0 means forever what is about 3 minutes, but will not return if the network fails during the rsync working.Default: 180

wIQguard.CheckTim-eout

This sets the timeout (in seconds) for fetching the status from the other machine. This value is only used when wIQguard is called with the check option, e.g. from wIQd check.Default: 15

wIQguard.wIQSplit-Config

Is the wIQ configuration split up in two files (interface_.cfg & wIQ.cfg) (1) or not (0)? The configuration is split up into two files for wIQ version 1.3 or higher.Default: 1

wIQguard.wIQCon-figFile

Where can wIQguard find the global wIQ con-figuration if configuration is split? Default: $ORGADATA/cnf/wIQ.cfg

wIQguard.DBNames Name(s) of database(s) to use. Can be more than one value separated by spaces.Default: Subscriber

wIQguard.DBSizes Size(s) of database(s) to use. Can be more than one value separated by spaces. Should match the license.Default: 100000


58

Configuration

1

2

5

6

3

4

7

A

I

Lines starting with a # are treated as a comment. All pathnames can be abso-lute or relative to $ORGADATA.

Example $ORGADATA/cnf/wIQguard.cfg:

wIQguard.RemoteHost=wiq2

wIQguard.Mode =local

wIQguard.PingNum=10

wIQguard.MaxStart=10

wIQguard.LocalModeName=active

wIQguard.RemoteModeName=standby

wIQguard.LocalModeName

The name of the local mode used in output to commandline and protocol.Default: local

wIQguard.RemoteModeName

The name of the remote mode used in output to commandline and protocol.Default: remote

You can set mode and remotehost with the command line options (-l, -r, -h) in the wIQd process table. This allows you to sync the wIQ-guard.cfg to the other host, too.

Note: On each server for each wIQguard, the path and filename for wIQguard.OkFile and wIQguard.ErrorFile must be the same!


59

Configuration

1

2

5

6

3

4

7

A

I

4.1.5 Processtable

The wIQ processes guarded by wIQguard have to be listed in the wIQguard´s process table $ORGAROOT/run/etc/wIQguard_proc_table in the fol-lowing form:

Flag Identifier Command-line

The Identifier is a unique identifier for the instance (e.g. wIQ_a). This pa-rameter must not contain any non-printable characters or white space. The Command line parameter contains the complete command line needed for this instance to work. This command line may contain spaces. Flag can have these values:

W if this line is used for a wIQ. The wIQ's config file is read. The pro-cess is checked if it is still running. The process is expected to write an alive file.

R if this line is used for a router. The process is checked if it is still run-ning. The process is expected to write an alive file. If at least one line of the type R is present, no connection probing is done.

O if this line is used for other processes writing an alive file. This is the same as R with the difference of not influencing if connection prob-ing is done.

M if this line is used for misc processes writing no alive file. The process is only checked if it is still running.

These values for flags shall be used:

wIQ: W

OMBmgr: M

SMSC Client: M

router: R

Driver Curry: M

Example $ORGAROOT/run/etc/wIQguard_proc_table:

60

Configuration

1

2

5

6

3

4

7

A

I

W wIQ_a wIQ_a -c cnf/wIQ_a.cfg

W wIQ_b wIQ_b -c cnf/wIQ_b.cfg

R router router -c Router.cfg

4.2 Logging

In the file wIQ.cfg, the output for the protocol file can be configured freely.

This is done with the variable ’wIQ.LogInfoMessage’ (see page 71).

The variable ’wIQ.LogInfoMessage’ can contain the following values:

The wIQd process table is used to start up all processes which are not monitored by wIQguard and the wIQguard itself. The wIQguard process table contains all processes monitored by the wIQguard.


$(STATUS) Status

$(METHOD) Method

$(TYPE) The status type of the session:’M’ new mobile initiated request’N’ new network (wIQ) initiated request’C’ request continued’E’ request ended’A’ Abort request’R’ SMS received’S’ SMS sent’P’ received Push request

$(MSISDN) MSISDN

$(LOC) Location

61

Configuration

1

2

5

6

3

4

7

A

I

$(COINS) Amount

$(URL) Requested URL

$(TrAction) TR (internal use)

$(SeAction) Se (internal use)

$(ApAction) Ap (internal use)

$(SessionID) ID

$(TEXT) Text

$(Phase) Phase1 request

$(Alert) Alert

$(Error) Err

$(CODE) Language

$(LastOutType) LastOut

$(Charset) Character set of message

$(Parameter) Parameter

$(BrowseMode) Browse or Finish

$(ISODATE)

$(CREATEDBENTRY) Create

$(:REQUESTSNUMSES-SION)

Number of requests in this session

$(:REQUESTSNUMTOTAL) Total number of requests

$(:HandsetID) ID


62

Configuration

1

2

5

6

3

4

7

A

I

Example:

wIQ.LogInfoMessage =$(TYPE) $(STATUS):$(MSISDN):$(PARAME-TER)=>$(URL) $(METHOD) $(:REQUESTSNUMSESSION)/$(:SESSIONNUM)/$(HTTPREQTIME)

may have the following output as a result:

I:HT_LOADED:94763577:*100#=>http://servint2/wiq/ussd100.php Get 1/54/0.006

The logging output from all processes is piped to $ORGADATA/log/Protocol.There are different types of log messages.

:D: Debug-Messages

:I: Information

:W: Warning may produce simple program errors

:E: Error may produce bad program flow errors

:P: Panic unable to continue -- exiting

The logging of the PHP Incore interface can be found in $ORGADATA/log/PHPIncore.log.

$(:TARIFFGROUP) Tariff

$(:USSDGROUP) Grp

$(:INSTALLATIONDATE) IDate

$(HTTPREQTIME) Time used for the HTTP request


63

Configuration

1

2

5

6

3

4

7

A

I

4.3 wIQ Internal

These interfaces should not be used, wIQd (see section ”wIQd” on page 49) is the administration command interface.

It is mentioned here for reasons of completeness.

4.3.1 Commandline Options

The wIQ process supports the following commandline options:

To reload new configuration files, the wIQ has to be stopped and started again.This can be done by wIQd stop -A to leave the database untouched, and then start it again with wIQd start -A.

Another method is to send a TERM signal to the wIQ processes and wait for the automatic restart, if you have made a crontab entry for restarting hanging processes.Database entries are read once per session.

Option Description

-D Turns on debugging.

-c ConfigFile Specifies the configuration file (relative to other $ORGADATA) for this instance of the wIQd process.If this option is not given, the file $ORGADATA/cnf/wIQ.cfg is used.

-h Displays the usage message.

64

Configuration

1

2

5

6

3

4

7

A

I

4.3.2 Signal Handling

The following unix signals are handled:

SIGTERM, SIGINT Controlled termination of the wIQ

SIGUSR1 Toggle debugging infos

SIGUSR2 Configuration reload. All configuration files will be read again and will become immediately active for all new sessions. All open sessions will belong to the old configuration.

4.4 Environment Variables

$ORGAROOT: This variable sets the base directory of installed software.

$ORGADATA: This variable sets the base directory of the software data area.

4.5 wIQ: Configuration Files

The wIQ main process which is also called wIQ uses different kinds of config-uration data.

To avoid confusion, this process is called wIQ core in the following.

Because you may start more than one wIQ core process, it is useful to differ-entiate between

local configuration data which must be different for each core process (for example to configure the port on which the process waits for a tcp con-nection)

and

A corrupt configuration file causes the wIQ to exit! The Interface_wIQ.cfg is not loaded! If the port or the host have been changed, the wIQ must be restarted again (wIQ stop/start).

65

Configuration

1

2

5

6

3

4

7

A

I

global configuration data, which should be the same for all wIQ core pro-cesses.

4.5.1 Interface_{processname}.cfg: wIQ Configuration File Variables

The following fields are read from a process-specific configuration file. The de-fault name and location for this file is:

$ORGADATA/cnf/Interface_{processname}.cfg

This means that a process which is called wIQ_a always tries to read

Interface_wIQ_a.cfg

This file must contain the following fields:

This file is host dependent !

Therefore is must not be synchronized from any other hosts !

Variable Type Description

wIQ.Port i Port on which the USSD gateway system connects to this wiqd instancemandatory no default value

wIQ.Interface IP address:n[1..3].n[1..3].n[1..3].n[1..3].

hostname:c[1..256]

The IP address or host-name of the local host´s interface on which the USSD gate-way system connects to this wiqd instancemandatory no default value

66

Configuration

1

2

5

6

3

4

7

A

I

Example Interface_wIQ.cfg:

#Example Interface_wIQ.cfg

wIQ.Interface =wiq21

wIQ.Port =5834

4.5.2 wIQ.cfg: wIQ Configuration File Variables

4.5.2.1 License

The configuration file $ORGADATA/cnf/wIQ.cfg contains the following variables:

All Push-related items have to check the license entry and are ignored if there is no Push license (see section 6.2 on page 140).


wIQ.AliveFile c[0..256] File name relative to $ORGADATA.This file is refreshed if wIQ receives any message within the last AliveTime interval.optionalDefault:$ORGADATA/tmp/{process-name}.alive

wIQ.AliveTime 0..3600 Interval in seconds. wIQ expects at least one received message during this interval.0 means that no message is expected.mandatoryno default

67

Configuration

1

2

5

6

3

4

7

A

I

wIQ.maxPushRequestsPerHour 0..MaxReqPerHour

Number of maximum Push requests per houroptionalDefault: MaxReqPerHour

wIQ.MissingPingPanic {0,1} Determines the behavior on a miss-ing ping.1=Panic0=close/open socketsoptionalDefault: 0

wIQ.PushBillNegativeCoins {"source","dest"}

Determines the one who is billed for negative contentoptionalDefault: dest

wIQ.PushQuota 0..100 Maximum number of Push requests per hour in dependency from overalloptionalDefault: 100

wIQ.PushSessionTimeout n[0..60] Time in seconds the Push session waits for a result of SMS or USSD interaction. If no result is received during this time, the result of the Push request is SUCCESS.

wIQ.ConfigurationUrl c[1..256] The HTTP-address of the database configuration page. If it is set, the subscriber is redirected to this page if the database contains no entry for his/her MSISDN or it contains invalid entries relating to his/her MSISDN.


68

Configuration

1

2

5

6

3

4

7

A

I

wIQ.DefaultLanguage c[2] Country code of the default lan-guage to be used if not specified by a subscriber. Examples: ’en’, ’’de’, ’ro’.Default: no default

wIQ.DefHandsetID i Handset ID for automatic creation of database entries. It is used if redirec-tion is disabled.optionalDefault: 1

wIQ.FormConfirmationMes-sage

c[1..256] This message will be sent to the subscriber to confirm the input to a form.

wIQ.HistoryEntries l The maximum number of temporary entries in the history list for one ses-sionoptionalDefault: 10

WIQ.HttpSyntaxError c[1..256] On all HTML pages containing syn-tax errors, this message is sent to the mobile station.mandatoryno default

wIQ.HttpError c[1..256] On all Http Errors and on all invalid html pages, this message is sent to the mobile station.mandatoryno default


69

Configuration

1

2

5

6

3

4

7

A

I

wIQ.IMSIrequired TRUE/FALSE

If TRUE, the IMSI has to be stored in the database or sent with the request.optional(necessary if IMSI is used for billing)no defaultDefault: FALSE

wIQ.localeCharSet c[0..256] This variable defines the valid value for the character set (tag <meta>, attribute ’content’, value of ’char-set’) on the HTML page. Only on value is allowed. If the line is miss-ing, the page is considered to be ISO-LATIN1. It also defines the char-acter set which is used for the con-version if the customer sets his preferred char set.

optional

wIQ.LicenseWarn i If the requests per minute are greater than or equalLicenseWarn/100* maxrequests, a warning appears.


localeCharSet

Windows-1251

ISO-LATIN 1

PrefCharSetiso local not set

iso

iso

ucs2

iso

ucs2

iso

70

Configuration

1

2

5

6

3

4

7

A

I

wIQ.LogInfoMessage c[1..] Configuration of the output of the protocol file (see section ”Logging” on page 61)

wIQ.MessageLength [1..182] Number of (7 bit) characters which can be sent to the handset as a maximum (valid for SMS and USSD)optionalDefault: 160

wIQ.MissingInput c[1..256] If the wIQ expects to get n preinput and get less than n preinput, this message is sent to the MS.mandatoryno default

wIQ.NoServiceMessage c[1..256] The message displayed at the hand-set if the license limit is reached. The session is always closed if this mes-sage is sent.mandatoryno default

wIQ.NotFoundMessage c[1..182] The message displayed at the MS if a URL was not foundmandatoryno default

wIQ.PanicMessage c[1..182] The message displayed at the MS if WIQ has an internal problem, e.g. a Session object is not in the Session-List object.mandatory no default


71

Configuration

1

2

5

6

3

4

7

A

I

wIQ.SMSBrowseError c[1..182] The message will be sent to a sub-scriber who requested a SMS that could not be delivered and the mode for the USSD session is BROWSE, e.g. ’SMS could not be delivered!Press * to go back!’.mandatoryno default

wIQ.SMSBrowseMessage c[1..182] The message which will be sent to a subscriber when he requests a SMS service and the mode for the USSD session is to continue the session, e.g. ’An SMS has been sent to you, press * to go back’.mandatoryno default

wIQ.SMSFinishError c[1..182] The message will be sent to a sub-scriber who requested a SMS that could not be delivered and the mode for the USSD session is FIN-ISH, e.g. ’SMS could not be deliv-ered!’mandatoryno default

wIQ.SMSFinishMessage c[0..182] The message which will be sent to a subscriber when he requests a SMS service and the mode for the USSD session is FINISH, e.g. ’An SMS has been sent to you’.optional


72

Configuration

1

2

5

6

3

4

7

A

I

If the parameters ’wIQ.maxPushRequestsPerHour’ and ’wIQ.PushQuota’ are both set, wIQ will take the higher restriction, which means the smaller value for RequestsPerHour for Push.

Example for wIQ.cfg:

#Example wIQ.cfg

#### Time after the session is canceled

wIQ.Timeout =30

wIQ.LicenseWarn =80

wIQ.StatisticBilling on/off Activates statistic billing.optionalDefault: off

wIQ.Timeout l The timeout for a session in sec-onds.mandatoryno default

wIQ.UnexpectedInput c[1..256] If wIQ receives some unexpected input and this message is defined, it is sent to the subscriber. Otherwise if the message is not defined, the last valid HTML page in the history is sent again.optionaldefault: not set

This is a global configuration file which should be the same on all hosts ! (Should be synchronized from every wIQ host !!)


73

Configuration

1

2

5

6

3

4

7

A

I

wIQ.HistoryEntries =10

#The entry is optional, default is 160 and the entry could be 0..182.

#For SMS only 160 chars are allowed!

wIQ.MaxMessageLength = 160

### Push specfic configuration

wIQ.PushSessionTimeout =10

wIQ.PushBillNegativeCoins =dest

wIQ.PushQuota =75

wIQ.PushMaxRequestsPerHour =1000

#### Process supervision

wIQ.AliveTime =60

wIQ.MissingPingPanic =0

#### billing specific configuration

wIQ.Billing =on

wIQ.CoinPrecision =3

wIQ.StatisticBilling =off

### Some Message if something goes wrong

wIQ.NotFoundMessage =Requested service not found

wIQ.TimeoutMessage =Request timed out; try again

wIQ.PanicMessage =Internal error; try again

wIQ.NoServiceMessage =Service currently not available; try again

wIQ.UnexpectedInput =Unexpected Input

wIQ.MissingInput =Missing Input

74

Configuration

1

2

5

6

3

4

7

A

I

wIQ.HttpError =Http Error

wIQ.HttpSyntaxError =Http Syntax Error

wIQ.PostpaidInfo =That will cost you something; proceed?

#The following messages are only relevant if SMS is licensed

wIQ.SMSFinishMessage =An SMS has been sent to you!

wIQ.SMSBrowseMessage =An SMS has been sent to you! Press '*' to go back!

wIQ.SMSFinishError =Unable to deliver page as SMS!

wIQ.SMSBrowseError =Unable to deliver page as SMS!Press '*' to goback!

# Please comment the next line if you want config with defaults

# If subscriber has no entry in the database and the ConfigurationUrl

# is set, he is redirected to it.

# If it is not set the entries are created with defaults.

#wIQ.ConfigurationUrl =http://od-scp-1:8080/wiq_handset.html

wIQ.DefHandSetID =1

# The following Value will be returned by the UrlConversion and

# can be found in $(URLCONV) if the Url was not matched in the

# URLconversion.(pre|post).cfg "<url>" stands for the special

# case that the entire Url shall be inserted if it could not be

# converted.

wIQ.UrlConvUnkPre =<url>

wIQ.UrlConvUnkPost =<url>

#Information log message format

wIQ.LogInfoMessage =$(TYPE) $(STATUS):$(MSISDN):$(PARAMETER)=>$(URL) $(METHOD) $(:REQUESTSNUMSESSION)/$(:SESSIONNUM)/$(HTTPREQTIME)

#IMEI stuff, only valid if IMEI is licensed

75

Configuration

1

2

5

6

3

4

7

A

I

wIQ.IMEI=0

wIQ.IMEINetworkQuery=0

wIQ.MapNetworkTimeout=10

wIQ.IMEIValidityTime=1d

wIQ.IMEIBlacklist=0

wIQ.IMEIBlacklistURL=http://localhost:8080/blacklisted.html

#local charset

#wIQ.localeCharSet=WINDOWS-1251

##EOF

4.6 Configuration Files

wIQ uses the following configuration files:

Interface_{processname}.cfgThis file contains local configuration data.

wIQ.cfgThis file contains global configuration data.

Ussd2URL.cfg*This file explains the configuration and handling of the incoming USSD string.

ValidURL.cfg*This file describes which URL can be accessed.

SMS2Service.cfg*This file is used for mapping from SMS content to URLs.

URL2SMS.cfg*In this file, it is defined how an SMS is sent.

DBDefaults.cfgThis file determines the defaults for database creation in dependence on the MSISDN pattern of the subscriber.

76

Configuration

1

2

5

6

3

4

7

A

I

HotKeySet.cfgThis file gives the mapping table according to which the characters are entered by the subscriber.

wIQ2opsc_in.cfgThis file defines the connection to the OPSC in_tm process(IN billing sys-tem

All these files accept the ";" character to specify comments in the files.

Group-specific Files:

Ussd2URL.cfg*

ValidUrl.cfg*

SMS2Service.cfg*

Url2SMS.cfg*

SMS-specific Files:

SMS2Service.cfg*

Url2SMS.cfg*

General Files (i.e. used for SMS and USSD):

wIQ.cfg

DBDefaults.cfg

HotKeySet.cfg

IN Billing-specific Files

wIQ2opsc_in.cfg

77

Configuration

1

2

5

6

3

4

7

A

I

4.6.1 Ussd2URL.cfg*: ’USSD to URL Mapping’ Table

The wiqd uses group-specific mapping tables to convert the service numbers entered by the subscriber to Internet URLs. These tables are located in $ORGADATA/cnf/Ussd2URL.cfg*] and consists of lines - separated by NEWLINE - of the following fields separated by <TAB>:

SERVICE METHOD URL SESSIONTYPE

They describe how the incoming USSD request is processed in wIQ.

The fields have the following format:

USSD to URL Mapping’ Table: Fields

Field Type Description

SERVICE 1, 2 or 3 digits from the set (*, #) followed by a numeric service number, and finished with a #. A series of * digits can follow this service num-ber as well as * variable where a variable has to start with a letterOR7Y where Y = any number from 0 - 9

The USSD service num-ber

METHOD {"GET","POST"}only one of these strings is allowed

The HTTP request type (GET/POST)

78

Configuration

1

2

5

6

3

4

7

A

I

To enable a group specific homepage, it is possible to define the homepage in the ’Ussd2Url’ mapping table.

The descriptor for the homepage is *#.

The descriptor for default service is *default#. This entry will be used if no service definition maps to the requested one. This has to be the last line in the file.

Example:

*100# <TAB> GET <TAB> http://www\.orga\.com/ussdtest/index\.htm<TAB> BROWSE

*101*par1*par2# <TAB> GET <TAB> http://www\.orga\.com/input\.cgi?var1=par1&var2=par2<TAB> BROWSE

*102 <TAB> GET <TAB> http://www\.orga\.com/end\.html <TAB> FINISH

URL c[1-256] The requested URL

SessionType {"FINISH", "BROWSE", "SMS"}only one of these strings is allowed

If a service is requested by service number, the SessionType is "FINISH" and the page contains no links or forms, the session ends after dis-playing this page. If the SessionType is "BROWSE", the session continues. This field has no influence on USSD phase1 handsets.If the session type is "SMS", an SMS will be selected as the bearer for the selected service.

USSD to URL Mapping’ Table: Fields


79

Configuration

1

2

5

6

3

4

7

A

I

*120# <TAB> GET <TAB> http://www.orga.com/index3.html<TAB> SMS

*# <TAB> GET <TAB> http://www.orga.com/homepage.html<TAB> BROWSE

#100# <TAB> GET <TAB> http://www.orga.com/indexHash.html<TAB> BROWSE

*#100*1*2# <TAB> GET <TAB> http://www.orga.com/indexExtended.html <TAB> BROWSE

*default# <TAB> GET <TAB> http://www.orga.com/default.html <TAB> BROWSE

4.6.2 Solution

It is allowed to define one USSD service number in multiple ways with differ-ent types of preinput. In addition to this, a default rule may be defined which is used if no mapping is found for the current input.

The format of the configurable USSD string is

*ussd_service_number [a number of "*numerical_constant"][a number of "*variable_name]#

where ussd_prefix 1, 2, or 3 digits from the set (*, #)ussd_service_number 100..149numerical_constant is a sequence of numbersvariable_Name is a unique name for a variable which

must be used in the URL definition,too.

The maximum number of ’*’ per line is 20. This means that the number of numerical constants plus the number of variable names must be smaller than or equal to 19.

80

Configuration

1

2

5

6

3

4

7

A

I

Example for a ’USSD to URL Mapping’ Table:

Description of the Matching Algorithm:

a) Search for the highest exact match of service number and numerical prein-put (highest means the highest number of *).

b) If there are any matches from a), search the results for the highest number of matching variable input.

USSD URL Mode

*100# http://www.orga.com BROWSE

*100*1# http://www.orga.com/index_100_1.html

BROWSE

*100*1*10# http://www.orga.com/index100_1_10.html

BROWSE

*100*var1# http://www.orga.com/script.cgi?par1=var1

BROWSE

*100*var1*var2# http://www.orga.com/script.cgi?par1=var1&par2=var2

BROWSE

*101# http://www.orga.com/index101.html BROWSE

*101*1# http://www.orga.com/index101_1.html

BROWSE

*101*1*var1# http://www.orga.com/script2?par1=var1

BROWSE

*101*1*var1*var2# http://www.orga.com/script2?par1=var1&par2=var2

BROWSE

81

Configuration

1

2

5

6

3

4

7

A

I

Example:

The input *101*1*# is mapped the following way:

The results of a) are the following lines:

*101*1*#

*101*1*var1#

*101*1*var1*var2#

Now take the results from a) and search for the highest match:

Result: The line *101*1*var1# is taken for USSD mapping.

This will have the following effect on a USSD session using the mapping table example:

USSD URL

*100# http://www.orga.com

*100*1# http://www.orga.com/index_100_1.html

*100*1*10# http://www.orga.com/index100_1_10.html

*100*2# http://www.orga.com/script.cgi?par1=2

*100*2*10# http://www.orga.com/script.cgi?par1=2&par2=10

*100*1*10*4# http://www.orga.com/index100_1_10.html and the ’4’ is used as a preinput for the result of the request.

*100*2*10*4# http://www.orga.com/script.cgi?par1=2&par2=10and the ’4’ is used as preinput for the result of the request.

*101# http://www.orga.com/index101.html

*101*1# http://www.orga.com/index101_1.html

82

Configuration

1

2

5

6

3

4

7

A

I

This new mapping algorithm allows the operator to perform a very complex configuration of his services.

*101*1*1# http://www.orga.com/script2.cgi?par1=1

*101*1*1*1# http://www.orga.com/script2.cgi?par1=1&par2=2

USSD URL

83

Configuration

1

2

5

6

3

4

7

A

I

4.6.3 ValidURL.cfg*: ’Valid URL’ and Variable Inclusion Table

The wiqd searches the list of valid URLs before requesting a URL from the in-ternet. This list can be found in $ORGADATA/cnf/ValidURL.cfg* with each line - separated by NEWLINE containing the following fields sepa-rated by <TAB>:

<URL><TAB><VARIABLES><TAB><MECAPS><TAB><Billing-Flag><TAB><OverridePermissions>

The ’Valid URL’ table must include at least the <TAB> character for the billing flag, even if no billing is used:

’Valid URL’ Table: Fields


URL RE[1..256] A valid URL as regular expression

VARIABLES Comma-sepa-rated strings as defined in the following table ”Valid URL Vari-ables” on page 86

Allow the URL to access the given variables

84

Configuration

1

2

5

6

3

4

7

A

I

BillingFlag n[1] 0 = No billing is performed for this URL, no price tags are allowed.1 = Billing is performed, but no price tags are allowed in HTML content.2 = Billing is performed, price tags are allowed in HTML content.

OverridePermissions comma-sepa-rated string

This field is taken to prove if this page is allowed to override the session settings.Only session-related settings are controlled by this field. The content cost-specific settings are located in the ’BillingFlag’!If no descriptor is given in this field, the permissions are set to ’NONE’.

’Valid URL’ Table: Fields


85

Configuration

1

2

5

6

3

4

7

A

I

In the following table, the column ’VARIABLES’ lists those variables which can be used in the field ’VARIABLES’ in the table above:

Valid URL Variables

VARIABLES SRC* Description

MSISDN(always available)

MS† The subscriber’s MSISDN.

LANG DB Transmit the ’Accept-Language’ header in HTTP requests for multiple language support.See the section ”Multiple Language Report” on page 35

LOC(optional)

MS The location of the MS.

CODE(optional)

MS Language code or ucs2 (if message was coded in UCS2).

PHASE(always available)

DB‡ / MS If the database entry of PHASE1 is equal to 0, the MAP Phase capabili-ties of handset or network are used. Else the database entry is used.

PIN DB The subscriber’s PIN.

HANDSETID(always available)

DB Handset ID from subscriber data-base.

USSDGROUP(always available)

DB USSDGroup from subscriber data-base

TARIFF (always available)

DB TariffGroup from Subscriber data-base

WIQUSERID(always available)

Anonymous and unique identity for one MSISDN.

86

Configuration

1

2

5

6

3

4

7

A

I

INSTALLDATE DB The creation date of the subscriber´s database entry.

FIRSTUSEDATE DB The subscriber’s first date of use of the wIQ.

LASTUSEDATE DB The subscriber’s last date of use of the wIQ.

SESSIONNUM DB The total number of a subscriber´s sessions.

SESSIONTIMELAST DB The time in seconds of the sub-scriber´s last session.

SESSIONTIMETO-TAL

DB The time in seconds of all sub-scriber´s sessions.

REQNUMTOTAL DB Total number of a subscriber´s requests.

REQNUMSESSION DB The number of requests during the last session.

PREFCHARSET DB The subscriber’s preferred char set settings.

REQCONTENT MS The content of the last USSD or SMS request. If message was coded in UCS2 (sse CODE), the content of the request is encoded as URL encoded ULF-8 UCS2.

REQTYPE MS The type of the request: "SMS" or "USSD"

* SRC: The source of information

Valid URL Variables

VARIABLES SRC* Description

87

Configuration

1

2

5

6

3

4

7

A

I

In the following table, the column ’BillingFlag’ lists those values which can be used in the field ’BillingFlag’ in the URL variables table on page 84:

If the field is left empty, wIQ uses ’0’ as default value. In this case, a <TAB> is needed at the end of the entry.

If the HTML content contains a price tag but the value of the billing flag for this URL is not ’2’, wIQ issues an error message to the subscriber as well as to the wIQ operator.

In the following table, the column ’Descriptor’ lists those values which can be used in the field ’OverridePermissions’ in the URL variables table on page 84.

† MS: Mobile station‡ DB: Subscriber database

Valid URL ’BillingFlag’

BillingFlag Description

0 No billing is performed for this URL, no price tags are allowed.

1 Billing is performed, but no price tags are allowed in HTML content.

2 Billing is performed, price tags are allowed in HTML con-tent.

88

Configuration

1

2

5

6

3

4

7

A

I

The field contains a comma-separated list of one or more of the following de-scriptors. If there is no value given for ’OverridePermissions’, the permissions are set to NONE.

Session settings from pages which are not allowed to override the settings are ignored.

Example:

http://www.orga.com/all.* MSISDN 2 ALLhttp://www.orga.com/sms.* MSISDN 2 SMSINTERFACE, BEARER

It is recommended to define explicitly the pages which include price tags to be accessed via HTTPS (secure HTTP) to prevent misuse (e.g. by payback sniff-ers) of the price tags.

Valid URL : Permissions to Override Session Configuration from HTML Contents

Descriptor Description

NONE No permissions to override session attribute.

BEARER Permissions to override the bearer.

APARTY Permissions to override the A-Party.

SMSINTERFACE Permissions to override the smsinterface.

USSDMODE Permissions to override the ussdmode.

ALL Permissions to override all.

Different ’Valid URL’ tables might be configured for different sub-scriber groups.

89

Configuration

1

2

5

6

3

4

7

A

I

Example:

http://www\.orga\.com/ussdtest/index\.html<TAB> 0

http://www\.orga\.com/ussdtest/banking/.* <TAB> MSISDN <TAB> 0

http://www\.orga\.com/ussdinputtest\.cgi <TAB> MSISDN,IMSI,LOC<TAB> 0

http://www.orga.com/index1.html <TAB> REQCONTENT,WIQID<TAB> 0

4.7 SMS2Service.cfg*: ’SMS to Service Mapping’ Table

This file is used for mapping from SMS content to URLs.

In this file it is defined how an incoming SMS has to be dealt with.

The group related SMS2Service files are located in $ORGADATA/cnf/.

The filenames are SMS2Service.cfg*.

If SMS services are enabled within the wIQ license, at least the default table SMS2Service.cfg* is mandatory. The default table is taken if the file for a special group does not exist.

To access the variable on the requested Web page, you have to enter http_<variable>; see also the section ”Subscribers’ Iden-tity Directly to URLs” on page 33.

’SMS to Service Mapping’ Table: Fields


B-Party ...;RE Used to map the MSISDN of the recipient (wIQ could receive SMS for different numbers).

Content ...;RE Used to map the content of a received SMS to an URL

90

Configuration

1

2

5

6

3

4

7

A

I

Method {"GET", "POST"} The HTTP request type, i.e. the content of the SMS.

URL c[1..256] or string [1..256]: A valid URL; i.e. http://www.orga.com

"USSD_MAPPING" USSD_MAPPING: Use the USSD mapping table of the group in which the subscriber sending the SMS is.If this variable is defined, the Ussd2URL.cfg of the group is taken in which the user who made the request is in.If the content can not be found in Ussd2URL.cfg, nothing hap-pens. If USE_AS_URL is found, the con-tent is taken as URL, but the con-tent must be found in ’Valid URL’ (see page 86).

"USE_AS_URL" USE_AS_URL: Use the content as URL. It will be validated with the ’Valid URL’ table of the group in which the subscriber sending the SMS is.



91

Configuration

1

2

5

6

3

4

7

A

I

Bearer { This field defines- whether the URL is sent back as SMS or

- whether a USSD session is opened (BROWSE) or

- whether the message is sent as USSD without session (FINISH),

- whether the message is sent as USSD or as SMS if USSD is not possible

If the URL is URL=USSD_MAPPING, the bearer and the method are defined in another table and thus ignored here.USSD Push is not possible with a Phase1 handset or in a Phase1 Network.For this reason, nothing happens if BROWSE or FINISH are defined as BEARER,

"BROWSE", BROWSE: USSD with BROWSE mode

"FINISH", FINISH: USSD with FINISH mode

"FINISH-SMS FINISH-SMS: If an error occurs while sending a display message to the subscriber, the message will be sent as an SMS (if this is possi-ble).



92

Configuration

1

2

5

6

3

4

7

A

I

Example:

124873264 <TAB> OG1.* <TAB> GET <TAB> http://www.orga.com/index1.html<TAB> BROWSE

12.* <TAB> SMSNEWS.* <TAB> GET <TAB> http://www.orga.com/sms/new.html<TAB> SMS

.* <TAB> .* <TAB> GET <TAB> http://www.operator.com/howto.html<TAB> SMS

The ’Bearer’ field is of special use if the subscriber is in a phase1 network or has a phase1 handset. In this case the subscriber is not able to initiate a USSD session with an SMS request. If FINISH-SMS is used as BEARER, in an error case (which will happen in the phase1 case) the message will be sent as SMS to the subscriber. If FINISH is used, the message will be thrown away. If an error oc-curs while initiating a USSD BROWSE session, there is no chance to establish this via SMS, so the messages are thrown away.

4.8 URL2SMS.cfg*: ’URL to SMS Interface Mapping’

Another subscriber group-dependent configuration is used to determine the used SMS interface through which a short message will be sent to the sub-scriber. The A-Party of the SMS and the USSDMODE are also configured in these files.

In this file, it is defined how an SMS is sent.Whenever an SMS is sent, the system looks through this file. If an SMS is re-

"SMS", SMS: SMS is used.

""}

empty: The bearer should be empty if USSD_MAPPING is used, because the bearer is already defined in another table. If it is nevertheless defined, it will be ignored.



93

Configuration

1

2

5

6

3

4

7

A

I

quested within a USSD session, the behavior of the USSD session is defined in this file.

USSDMODE is only relevant when you are in a USSD session!

The files are located in $ORGADATA/cnf/.

The filenames are URL2SMS.cfg*.

If SMS services are enabled within the wIQ license, the default file URL2SMS.cfg* is mandatory and all others are optional. If a file for the giv-en group does not exist, the default file is taken.

94

Configuration

1

2

5

6

3

4

7

A

I

If an URL does not match any line of the file, the SMS can not be sent. Add a line with the URL pattern .* as the last line to avoid this behaviour.

’URL to SMS Interface Mapping’ Table: Fields


URL ...;RE or"TEXT"

The URL.

Reserved value for pushing text messages.To enable a mapping for ’TEXT’ Push messages, the descriptor ’TEXT’ may be added in the URL field of the mapping table. The line with this descriptor is taken for Push text messages which should be sent over SMS.

SMSInterface {"MAPSMS[0,1,2]"} This field determines the used SMS interface to send an SMS of this URL.MAPSMS0: fire and forgetMAPSMS1 (optional): pass to SMSC on errorMAPSMS2: pass directly to SMSC

A-Party number The MSISDN which is used as the A-Party.

USSDMODE {"FINISH", FINISH: The session is closed immediately and an acknowl-edgement message (wIQ.SMS-Finish-Message) is sent if not empty.

95

Configuration

1

2

5

6

3

4

7

A

I

USSDMODE is only looked up if a SMS is requested from within an USSD ses-sion, otherwise it will be ignored.

Example:

http://www.orga.com/news.* <TAB> MAPSMS0 <TAB> 123456789<TAB> FINISH

.* <TAB> MAPSMS2 <TAB> 123456789<TAB> REDISPLAY

TEXT <TAB> 7777 <TAB> MAPSMS0<TAB> FINISH

4.8.1 USSD Session Action after a SMS is Requested

If an SMS is requested from within a USSD session, something has to happen with the already established USSD session. To handle this case, the USSD-MODE in the file URL2SMS.cfg* has been added. It determines the behavior on USSD layer after the SMS is delivered correctly with one of the values FIN-ISH, BROWSE or REDISPLAY (see section ”URL2SMS.cfg*: ’URL to SMS Inter-face Mapping’” on page 93).

If sending of the SMS was successful, a message depending on the USSD-MODE will be sent to the subscriber. This will be wIQ.SMSFinishMessage in case of FINISH and wIQ.SMSBrowseMessage in case of BROWSE. If an error occurred while sending the SMS, an error message depending on the USSD-

"BROWSE" BROWSE: The session stays open and an acknowledge-ment message (wIQ.SMS-Browse-Message) is sent.

"REDISPLAY"}

REDISPLAY: The session stays open and the actual page is displayed again.

’URL to SMS Interface Mapping’ Table: Fields


96

Configuration

1

2

5

6

3

4

7

A

I

MODE will be send to the subscriber. This will be wIQ.SMSFinishError in case of FINISH and wIQ.SMSBrowseError in case of BROWSE.

If USSDMODE is REDISPLAY and there was no USSD message sent to the sub-scriber before, the USSD session is closed with the acknowledgement mes-sage wIQ.SMSFinshMessage (if not empty) after the SMS is sent successfully (or wIQ.SMSFinishError else). This case might happen if the response of the first USSD request (e.g. *100#) is an SMS.

If USSDMODE is REDISPLAY and there was an USSD message sent to the sub-scriber before, the USSD session stays open and the actual page is displayed again after the SMS is sent successfully (or wIQ.SMSBrowseError is displayed in case of an error).

4.9 DBDefaults.cfg: ’MSISDN-Dependent Database De-faults’ Table

This configuration is used to determine the defaults for database creation in dependency of the MSISDN pattern of the user. It is useful to sort for example MSISDNs belonging to different operators to different subscriber groups. Fur-ther fields for database creation defaults are defined in wIQ.cfg because it makes no sense to define these defaults in dependency of MSISDN patterns.

The field ’SERVICES’ sets the value of ’AllowedServices’ introduced on page 43.

The file is located in $ORGADATA/cnf/.

The filename is DBDefaults.cfg.

The format of the file is

<MSISDN><TAB><GROUP><TAB><TARIFF><TAB><PHASE1><TAB> <SERVI-CES><TAB><PREPOST><TAB><COSTINFO><TAB><PUSHCTL><TAB><PREF-CHARSET><TAB><CREATEDB>

This file is mandatory even if there is no SMS license!

97

Configuration

1

2

5

6

3

4

7

A

I

At least one line is mandatory in this file.

Note that if a MSISDN does not match an entry in this file, no service at all is allowed for this MSISDN. So it is a good idea to add a line with a default for all MSISDNs as last or only line.

’MSISDN Dependent Database Defaults’ Table: Fields


MSISDN ...;RE Pattern for the subscribers MSISDN.

Group {1..63} The default value for the subscriber group.

TARIFF number The default value for tariff class.

PHASE1 {0, 1, 2} 0 = automatic map phase1 = always assume map phase12 = always assume map phase > 1

SERVICES [ "SMS2SMS" , SMS to SMS: pure SMS services are allowed for this subscriber.

"SMS2USSD" , SMS to USSD: A SMS request with USSD answer is allowed for this subscriber.

"USSD2SMS" , USSD to SMS: SMS initiated by a USSD ses-sion is allowed.

"USSD2USSD" ], USSD to USSD: pure USSD services are allowed for this subscriber.

"PUSH2USSD" Subscriber is allowed to initiate an USSD message to himself.

"PUSH2SMS" Subscriber is allowed to initiate an SMS to himself.

"PUSHALL2USSD" Subscriber is allowed to initiate an USSD message to himself and other subscribers.

98

Configuration

1

2

5

6

3

4

7

A

I

"PUSHALL2SMS"] Subscriber is allowed to initiate an SMS to himself and other subscribers.

or[...],[...] ...or

Note that it is allowed to com-bine several of the above values separated by commas.

"ALL" or

ALL: All services are allowed.

"NONE" NONE: Subscriber is not allowed to use any services.

PREPOST {0, 1, 2} Billing Pre-/Postpaid differentiation.

COSTINFO {0, 1, 2, 3, 4, 5} Billing subscriber information; see section ”Subscriber Information” on page 125.

PUSHCTL l[0,1,2] Subscriber Push privacy settings:0 = No Push allowed to the subscriber1 = Push allowed if sender is recipient2 = Push allowed from anyone.

PREFCHARSET {0, 1, 3, 5, 7} Character set of message (see section ”Pref-CharSet” on page 45)

CREATEDB {0, 1} If CreateDB is set to 1 ("YES") a database entry with the given defaults is inserted for the MSISDN.If CreateDB is set to 0 ("NO") the given default for database insertion is used, but no database entry is inserted.

’MSISDN Dependent Database Defaults’ Table: Fields


99

Configuration

1

2

5

6

3

4

7

A

I

The field ’CREATEDB’ offers the new feature to just use the default values for a subscriber, but not to save them into the database. This means that this val-ues have the same lifetime as the subscribers session.

Example:

4916.* <TAB> 1 <TAB> 1 <TAB> 0 <TAB> ALL <TAB>1 <TAB> 1 <TAB> 1 <TAB> 1

4917.* <TAB> 2 <TAB> 0 <TAB> 1 <TAB> SMS2USSD, SMS2SMS<TAB> 2 <TAB> 2 <TAB> 1 <TAB> 1

.* <TAB> 3 <TAB> 0 <TAB> 1 <TAB> SMS2SMS<TAB> 0 <TAB> 0 <TAB> 1 <TAB> 0

4.10 ProviderMap.cfg

This configuration file is used for billing (see section ”Provider List/Provider-Map.cfg” on page 121).

4.11 wIQ2opsc_in.cfg

This configuration file is used for IN billing (see the section ”IN Billing Config-uration/wIQ2opsc_in.cfg” on page 122).

4.12 License File

$ORGAROOT/run/lib/License

The expiration date of this license, the customer, and the maximum number of subscribers in the database and the maximum number of requests per hour are defined in the license file.

You need an extra license for SMS, CDR, and IN Billing!

100

Configuration

1

2

5

6

3

4

7

A

I

If the maximum number of transactions per minute is reached, all requests will be aborted for the rest of the minute.

You need an extra license for Push!

You need an extra license for SMS client!

You need an extra license for CurryDriver!

You need an extra license for Router!

You need an extra license for binary ESMS!

You need an extra license if you want to use both binary and textual ESMS!

101

Configuration

1

2

5

6

3

4

7

A

I

4.13 HotKeySet.cfg: Configuration File for Character Sets

The wIQ uses a mapping table to convert the characters entered by the sub-scriber to link numbers on the previous menu page and the numbering infor-mation for displaying links. The table must contain at least one line.

This table is located in $ORGADATA/cnf/HotKeySet.cfg and consists of lines (separated by NEWLINE) of the following fields separated by<TAB>:

id inputcharset outputcharset

The fields have the following format:

In the following table, some examples are shown:

The next table shows the relationship between the characters and their func-tionality:

’Configuration File for Character Sets’ Table: Fields


ID i ID

Input Char Set c[12] The input interpretation charset

Output Char Set c[9] The output numbering style charset

HandSetId

Input Character Set Output Character Set

1 123456789*0# 123456789

2 abcdefghij*0# abcdefghij

102

Configuration

1

2

5

6

3

4

7

A

I

Input Set Functionality Output Set Functionality

c [1..9] follow link 1..9 c [1..9] Display number for link 1..9

c [10] free for future implementation

c [11] This is a special character which is used to send the current USSD page as an SMS. If this key is pressed, a SMS request for the current page has to be initiated (only during a USSD session).

This character can be configured independently of the handset. You should pay attention to the fact that the character should not corre-spond to one of the characters rep-resenting a link as otherwise, this link is followed. It is recommended to use the character ’0’.

c [12] free for future implementation

103

Configuration

1

2

5

6

3

4

7

A

I

104

The Router 5

1

4

2

6

3

5

7

A

I

The router distributes the message from the connected drivers to the connected wIQs and vice versa.

A driver can be e.g. the NSG or the SMSC client. It acts as a server for the drivers and as a client in the direction of the wIQs. In both directions, the messages can be directed MSISDN-dependent. Messages of the drivers can also be directed service-dependent. Messages for unavailable wIQs/drivers can be directed from the router to available ones.

It is possible for a wIQ to send messages optionally via a NSG or a SMSC or that messages can be triggered so that wIQ sends them.

For the different protocols (SMPP, CIMD, CMG/UCP), clients can also be connected via the router so that messages can be sent via the corresponding SMSCs.

105

The Router

1

4

2

6

3

5

7

A

I

5.1 Driver Types, Services, and Routing Algorithm

5.1.1 Driver Type

A driver type can be dt_PUSH, dt_SMSC, dt_SMS or dt_USSD (only valid for Push and SC Messages).

dt_PUSH: Push Message

dt_SMS: SMS message.

dt_USSD: USSD message.

dt_SMSC: SMS message which should be sent directly to an SMSC (if con-nected)

106

The Router

1

4

2

6

3

5

7

A

I

5.1.2 Service

Each driver is assigned to a service.

A service is Push, NSG, USSD, CURRY (USSD not supported at the moment).

A driver which is assigned to Push can handle dt_PUSH messages.

A driver which is assigned to USSD can handle dt_USSD messages.

A driver which is assigned to NSG can handle dt_USSD and dt_SMS messages.

A driver which is assigned to CURRY can handle dt_SMS and dt_SMSC messages.

5.1.3 Routing Algorithm

For messages in the direction of wIQs, a routing algorithm can be defined.If so, there is exactly one algorithm which is MSISDN-based.

If there is no routing algorithm, the message is sent round robin (when more than one wIQ of this service is available).

For messages in the direction of the drivers, a routing algorithm can be defined for each driver type (dt_SMS, dt_SMSC, dt_USSD, dt_PUSH). The routing algorithm is also MSISDN-based. If there is a routing algorithm for the driver type, the message is sent according to the routing algorithm of this service. If there is no routing algorithm, the message is sent round robin (when more than one driver of this service is available).

5.2 General Information

5.2.1 Program Name

The executable program name is router. It is located in $ORGAROOT/run/bin.

107

The Router

1

4

2

6

3

5

7

A

I

5.2.2 Command Line Options

-c <filename> Use filename (relative to $ORGADATA) as configu-ration file for the router (instead of the standard name Router.cfg).

-D Enable debug

-V<NUMBER> Set Debug Level

-h Show usage

5.2.3 Regular Termination

The router can be terminated by sending a KILL signal or a TERM signal.

When terminated by a KILL signal, no further action can be performed.

When terminated by a TERM signal, the router will clean up. Sessions are aborted.

5.2.4 Enable/Disable DEBUG Information

When the router receives a USR1 signal, it switches the debug information on.

5.2.5 License

5.3 Configuration Data

The configuration data is stored in UNIX ASCII files. The files are read by the router to get the necessary configuration data.

You need a licence for Router!

- Each wIQ must have a unique name (unique for this router)

- Each driver must have a unique name (unique for this router)

108

The Router

1

4

2

6

3

5

7

A

I

5.3.1 Overview of the Configuration Files:

The main configuration file is Router.cfg. This file configures the router. The File Router.cfg is located in $ORAGADATA/cnf/Router.

Other filenames may be used (see -c option).

Other configuration files configure the connection to the wIQs and the drivers.

5.3.1.1 Configuring the Connections

The file name for the wIQ and driver configuration files is a concatenation of {wIQ, Driver}, <_>, a pattern (characters) and <.cfg>.

For each router, these files are located in a separate directory called $ORGADATA/cnf/Router/<RouterName>/Connections .

There must be one file for each connectable wIQ. To configure the connection to the wIQs, the router reads all files which match the pattern wIQ_*.cfg.

There must be one file for each driver. To configure the connection to the drivers, the router reads all files which match the pattern Driver_*.cfg. There can be only one file for each driver.

5.3.1.2 Configuring the Routing Algorithms

There can be one file for the routing algorithm of the wIQs. To configure the wIQ routing algorithm, the router reads the file

wIQRoutingAlgorithm.cfg.

This file is located in$ORGADATA/cnf/Router/<RouterName>/Algorithms .

There can be files for the routing algorithm of the drivers. To configure the driver routing algorithm, the router reads the file Driver<PATTERN>RoutingAlgorithm.cfg, where <PATTERN> is for the driver type. These files are also located in$ORGADATA/cnf/Router/<RouterName>/Algorithms .

109

The Router

1

4

2

6

3

5

7

A

I

5.3.2 File Router.cfg

This file configures the router.

The file Router.cfg is located in $ORGADATA/cnf/Router.

The format of the configuration file is

Router.<VARIABLE NAME> = <CONTENT><NEWLINE>.

VARIABLE NAME Description

RouterName Mandatory The name of the router. It is the name of a directory for all other configuration files. (One word, no white spaces allowed, characters must be in [a-z, A-Z, 1-9], _)

No default

c[1..80]

CheckOpenAgain Optional. Time in seconds. 0 means no check. When the router has lost the connection to a wIQ, it tries to connect to this wIQ again. This pa-rame-ter sets the time between two tries.

Default 5

n [0...]

PingTimeWIQ Optional Time in seconds. Maximum time period between two PINGs sent to the wIQ (when no message arrives for that wIQ). 0 means no PING.

Default 25

n [0...]

MaxPongWaitCount Optional Used to detect if the other side is down or alive. Sets the number of unanswered PINGS sent to the other side.

Default 3

n[1...]

110

The Router

1

4

2

6

3

5

7

A

I

Example for Router.cfg

Router.RouterName=router_1

Router.CheckOpenAgain=5

Router.PingTimeWIQ=25

Router.PingTimeDriver=25

PingTimeDriver Optional Time in seconds. If no PING or any other message arrives from a driver within’PingTimeDriver’ seconds, the router must send a PING to this driver and wait for a PONG. 0 means no PING.

Default 25

n[0...]

DeliverToSMSC Optional If TRUE, an SMS message which has the tag </smsc> will be delivered according to the routing algorithm of dt_SMSC. If set to FALSE, it will be delivered according to the routing algorithm of dt_SMS.

Default FALSE

TRUE, FALSE

wIQsendBufferSize Optional Size of the internal buffer for messages to the wIQ: The router stores (for each wIQ separately) all messages if the wIQ is busy. If the buffer size reaches this limit (0= no limit), the router will block all new connections.

Default: 0

n[0.. ]

VARIABLE NAME Description

111

The Router

1

4

2

6

3

5

7

A

I

5.3.3 File Driver_<PATTERN>.cfg

These files contain the configuration data for each driver.They are located in

$ORGADATA/cnf/Router/<RouterName>/Connections.

They configure the name, the port on which the driver can connect, and the service used for the defined port.

It is recommended that the <Pattern> contains the unique driver name.

When no Driver_*.cfg file exists, a PANIC message is printed and the router is stopped.

The format for the configuration files is

Driver.VARIABLENAME = <CONTENT><NEWLINE>

All variables are mandatory.

VARIABLE NAME

Type Description

Name c[1..80] Unique name.

Service { NSG | Push | CURRY } Service handled by driver.

Port n Port number for this driver.

Interface c[1..250] Hostname (real name or IP address) on which the driver is started.

112

The Router

1

4

2

6

3

5

7

A

I

On each port, not more than one driver can connect! So each driver must connect to another port.

- The name must be unique for each driver.

- If a port is configured to handle CURRY, new Network Initiated(NI) SMS will be sent to it.

- If a port is configured to handle NSG, new Network Initiated(NI) USSD and SMS will be sent to it.

- If a port is configured to handle Push,new Network Initiated(NI) Push will be sent to it.

113

The Router

1

4

2

6

3

5

7

A

I

Example for Driver_<PATTERN>.cfg

File Driver_GW_1.cfg:

Driver.Name=USSSGW_1

Driver.Service= NSG

Driver.Port=5321

Driver.Interface=od-scp-1.orga.com

5.3.4 File wIQ_<PATTERN>.cfg

These files contain the configuration data for each wIQ. They are located in$ORGADATA/cnf/Router/<RouterName>/Connections .

When no wIQ_*.cfg file exists, a PANIC message is printed and the router is stopped.


wIQ.VARIABLE NAME = <CONTENT><NEWLINE>

All variables are mandatory.

VARIABLE NAME

Type Description

Name c[1..80] Unique Name.

Active {TRUE} Active (TRUE)

Port n[1..1024] Port number.

Host c[1..250] Hostname (real name or IP-address).

- If the values for the field ’Name’ exist more than once for allwIQ_*.cfg files, an error message is printed. The wIQ_*.cfgfile for the duplicate wIQ is ignored.

114

The Router

1

4

2

6

3

5

7

A

I

Example for wIQ_<PATTERN>.cfg

File wIQ_wiq1.cfg:

wIQ.Name= WIQ1

wIQ.Active= TRUE

wIQ.Port= 5444

wIQ.Host= wiq.orga.com

5.3.5 File wIQRoutingAlgorithm.cfg

The file wIQRoutingAlgorithm.cfg contains the complete data for the routing algorithm in the direction of the wIQs. This file is mandatory. It is located in $ORGADATA/cnf/Router/<RouterName>/Algorithms . With this file, the operator can define MSISDN-based routing in the direction of the wIQs.


EXPR<TAB>NAME<NEWLINE> (TAB is Tabulator)

For each line, a MSISDN which fits EXPR is directed to the wIQ called NAME.

Tag Value Description

EXPR {*, any other RE} Regular expression defining the MSDISDN.

NAME c[1..80] Defined as wIQ.Name in {wIQ_*.cfg., ...,}.

- One line with "*" must be defined (the DEFAULT, should be thelast line).

- When more than one line fits, first line fits.

115

The Router

1

4

2

6

3

5

7

A

I

Example:

All messages from a MSISDN starting with 1 and an odd number are directed to WIQ1, the even ones to WIQ2. All other MSISDNs are directed to WIQ3 (this means, WIQ3 is the DEFAULT).

Regular Expression Directed to WIQ... (defined in field NAME)

ˆ1*[13579]$ WIQ1

ˆ1*[24680]$ WIQ2

* WIQ3 (this is the DEFAULT WIQ)

The File wIQRoutingAlgorithm.cfg may look like this:

ˆ1*[13579]$<TAB> WIQ1<NEWLINE>

ˆ1*[24680]$ ]$<TAB> WIQ2<NEWLINE>

*<TAB> WIQ3<NEWLINE>

5.3.6 Files Driver<Pattern>_RoutingAlgorithm.cfg

The files Driver<Pattern>_RoutingAlgorithm.cfg contain the complete data for the routing algorithm in the direction of the drivers.

They are located in $ORGADATA/cnf/Router/<RouterName>/Algorithms.

With these files, the operator can define MSISDN-based routing for a driver-type separately. A routing algorithm can be defined for each driver type.

When no file for a driver type is available, the drivers are selected round robin.

The pattern for the file name must be selected according to this table:

Driver-Type Pattern

dt_SMS SMS

dt_SMSC SMSC

116

The Router

1

4

2

6

3

5

7

A

I

(e.g. for driver-type dt_SMS DriverSMS_RoutingAlgorithm.cfg)


EXPR<TAB>NAME<NEWLINE> (<TAB> is Tabulator)

For each line, a MSISDN which fits EXPR is directed to the driver called NAME.

Example: File DriverSMS_RoutingAlgorithm.cfg

ˆ1*[13579]$<TAB> CURRY1<NEWLINE>

ˆ1*[24680]$<TAB> SMSSD1<NEWLINE>

*<TAB>SMSSD2<NEWLINE>

dt_USSD USSD

dt_PUSH Push

Tag Value Description

EXPR {*, any other RE} Regular expression defining the MSDISDN.

NAME c[1..80] Defined as Driver.Name in any {Driver_*.cfg., ...,}.

- One line with "*" must be defined (the DEFAULT, should be thelast line).

- It is best when the driver can handle the assigned driver type.

- When more than one line fits, the first line fits.

Driver-Type Pattern

117

The Router

1

4

2

6

3

5

7

A

I

118

Additional Features 6

1

4

5

2

3

6

7

A

I

6.1 Billing

6.1.1 Introduction

wIQ bills the subscriber for the general usage of the wIQ system and the op-erator’s GSM infrastructure. This is called ’usage billing’.

Additionally, the wIQ system is able to move money from the subscriber’s ac-count to the content provider’s account for access to the provider’s content. This is called ’content-based billing’.

To calculate the cost of information, a ’price tag’ has to be added to the HTML page the content provider creates. The access to this content should be performed in an encrypted way via HTTPS (secure HTTP) to prevent misuse.

For all features described in this chapter, an extra license must be available.

These features are not included in the wIQ standard license.

You need an extra license for SMS and Billing!

119

Additional Features

1

4

5

2

3

6

7

A

I

6.1.1.1 Billing Mechanism

There are the two types of accounts for subscribers as well as for content pro-viders:

1.) Prepaid

2.) Postpaid

Prepaid accounts hold the owner’s account balance which is decreased with a transaction, while for postpaid accounts the billing system writes e.g. a monthly bill for all transactions which the subscriber has to pay.

The following section shows the impact of prepaid versus postpaid billing on the wIQ.

Prepaid Billing

Prepaid billing is only supported for subscribers, not for providers. For these subscribers, wIQ checks the subscriber’s account balance before the delivery of any content and delivers the content only if the subscriber’s account is suf-ficient for the cost of this transaction. After the delivery of this information, the cost is debited from the subscriber’s account.

For content-based billing, wIQ transfers the part of the cost which is calculat-ed based on a price tag in the HTML page from the subscriber’s account to the content provider’s prepaid account.In case of negative price tags (e.g. as a bonus), wIQ will not contact the IN billing system. It will only write pre-/postpaid CDRs. If the subscriber is unknown to the IN billing system, a prepaid CDR is written for the subscriber.

Postpaid Billing

In case of a postpaid subscriber, wIQ creates standard wIQ CDR tickets for each transaction. It is the task of the operator’s postpaid billing system to bill the subscriber for these transactions appropriately.

If the account of a content provider is a postpaid account, standard wIQ CDR tickets are generated for the content provider’s account for each transaction which includes a HTML page that has defined content-based billing.

120

Additional Features

1

4

5

2

3

6

7

A

I

6.1.2 Modules

This section describes all modules involved in the wIQ billing.

6.1.2.1 Secure HTTP

To e.g. access pages which contain price tags in a secure way, the operator can use the secure HTTP (https://) protocol in the ’Valid URL’ table (see sec-tion ”ValidURL.cfg*: ’Valid URL’ and Variable Inclusion Table” on page 84).Previous versions of wIQ were only capable of handling HTTP access.

6.1.2.2 Price Tag

To allow a content provider to associate a price with his content, a wIQ price tag might be included in the header of these HTML pages.The following example shows the price tag’s XML format:

<wIQ coins="100" provider="ORGA"/>

6.1.2.3 Provider List/ProviderMap.cfg

wIQ accesses the new table to map the provider’s name (included in the price tag) to an account to be charged to.This table includes the provider’s name (exactly as in the price tag) and the provider’s (pseudo) MSISDN (either pre- or postpaid), the IMSI as well as a flag that defines whether this account is handled by the prepaid or by the postpaid billing system (PrePostFlag, see also section ”Prepaid / Postpaid Differentia-tion” on page 129). To allow the handling of (very) different URLs by one content provider ac-count, the lines in this table contain fields with regular expressions for the URLs valid for this provider’s price tags. wIQ interprets all fields behind the Pre-PostFlag as regular expressions defining the URLs which are allowed to con-tain the price tag of the content provider belonging to this configuration line. If no URLs are mentioned in the provider listes, all URLs are allowed to have this provider’s price tag.

It is highly recommended to use HTTPS for all pages which might contain price tags and which are not reached through a secure con-nection.

121

Additional Features

1

4

5

2

3

6

7

A

I

This tab-separated list, with one provider per line, has therefore the following format:

<provider> <TAB> <MSISDN> <TAB> <IMSI> <TAB> <PrePost-Flag> <TAB> <reURL1> <TAB> ... <reURLn>

The file $ORGADATA/cnf/ProviderMap.cfg contains this table.In the following, you will find an example for a line in this file that defines the content provider ORGA with the prepaid MSISDN 1092387456.For this content provider, price tags are allowed on the server www.orga.com and www.agro.com. On orga.com, the secure http might be used.

ORGA 1092387456 454612425879615 1 https?://www\.or-ga\.com/.*http://www\.agro\.com/.*

When a price tag occurs in the content, wIQ checks with this list if the provider tag is valid and if this URL is valid for the subscriber. wIQ rejects the delivery of the content - with a configurable error message to the subscriber - if the provider or the URL is invalid. This file must exist if the wIQ billing is switched on in the configuration

6.1.2.4 IN Billing Configuration/wIQ2opsc_in.cfg

If prepaid billing via an IN billing system is activated (by license and configu-ration), wIQ reads the file $ORGADATA/cnf/wIQ2opsc_in.cfg at startup to connect to the OPSC in_tm process. The file contains only one line with the following (tab-separated) columns:

MSISDNmask <tab> hostname <tab> portnumber <tab> timeout

There can only be one line for each provider, but it is possible that there are several URLs for one provider.

For pushing text or ESMSs directly, there are pseudo-URLs to bill these: "TEXT" and "ESMS". Please see the section ”Push Interface” on page 140 for Push features and the section ”wIQ Enhanced SMS” on page 183 for ESMS features.

122

Additional Features

1

4

5

2

3

6

7

A

I

6.1.2.5 Billing

Every wIQ transaction that includes a URL for which billing is switched on cre-ates a billing event to the subscriber’s account, either prepaid or postpaid. If content-based billing is allowed and the content to be delivered contains a price tag (’wIQ coins’), wIQ also creates a billing event to the content provid-er’s account. Again, this can either be prepaid or postpaid. The prepaid accounts are implemented using the IN functionality of the OPSC.For postpaid accounts, wIQ creates generic wIQ CDR tickets.

If a subscriber requests a billable content and he is prepaid (or unknown) sub-scriber, wIQ reserves the costs in the IN billing system and evaluates the an-swer.

If the connection to the IN billing system breaks down, wIQ tries to reconnect before each new request. The following table describes the reaction of the wIQ to the responses of the IN billing system:

MSISDNmask Not used at the moment

hostname The hostname to connect to the in_tm

portnumber The port to connect to the in_tm

timeout The time (in seconds) until a com-munication to the in_tm proces runs into a timeout (when there is no response from in_tm)

debit OK ask subscriber for costs (if configured by sub-scriber)and evaluate answer

ORsend content and submit reserved costs

not enough debit send (configurable) message to subscriber

123

Additional Features

1

4

5

2

3

6

7

A

I

If the subscriber answers ’YES’ to the costs, wIQ submits the costs to the IN billing system and sends the requested content to the subscriber. If the sub-scriber answers ’NO’, wIQ cancels the reserved costs.

This section describes how the billing of the different accounts is performed and which additional entities are needed to accomplish this.

Valid URL

The ’Valid URL’ table ($ORGADATA/cnf/ValidURL.cfg*, see section ”ValidURL.cfg*: ’Valid URL’ and Variable Inclusion Table” on page 84) is ex-tended to contain an additional billing flag. The new format of the lines in this file therefore is

<URL> <TAB> <PARAMETERS> <TAB> <BillingFlag>

unknown subscriber send (configurable) error message to subscriber and close session

ORsend content and write a prepaid CDR

timeout send (configurable) error message to subscriber and close session

ORsend content and write a prepaid CDR

connection error write HTTP-Error message to subscriber

misc. error write HTTP-Error message to subscriber

124

Additional Features

1

4

5

2

3

6

7

A

I

This flag defines which type of billing wIQ uses for this URL. The following ta-ble shows the values valid for this flag:

If the field is left empty, wIQ uses ’0’ as default value. If the HTML content cotains a price tag but the value of the billing flag for this URL is not ’2’, wIQ issues a warning message to the wIQ operator and the in-formation is delivered without content billing. This prevents a service from be-ing stopped if a service provider accidentally inserts a price tag.

It is recommended to define explicitly the pages which include price tags to be accessed via HTTPS (secure HTTP) to prevent misuse (e.g. by packet sniffers) of the price tags.

Subscriber Information

The subscribers might want to be informed about transactions that will cost something and they might want to cancel the transaction depending on this information. To accomplish this, the subscriber database of the wIQ includes a new field ’CostInfo’, and the wIQ informs the subscriber depending on this value with a configurable message.

Value Description

0 No billing is performed for this URL, no price tags are allowed.

1 Billing is performed, but no price tags are allowed in HTML content.

2 Billing is performed, price tags are allowed in HTML content.

Note that different ’Valid URL’ tables might be configured for differ-ent subscriber groups.

125

Additional Features

1

4

5

2

3

6

7

A

I

The following table shows all valid values for this flag:

URL Conversion

If a billing system is not capable of handling complete URLs in the billing tick-ets, the wIQ can map these URLs to other values by means of the table ’URL-conv’. The table consists of lines with the format

<URL regular expression> <TAB> <Billing value>

wIQ checks this table starting at the top for the first line matching the URL of the actual transaction and uses the <Billing value> for the communica-tion with the billing system instead of the whole URL. If the <Billing val-ue> field is left empty, no conversion is done, the billing system must then be capable of handling URLs in the tickets.

This table exists twice, one table for the use with the prepaid billing system in the file $ORGADATA/cnf/URLconversion.pre.cfg, one for the post-paid billing system in the file$ORGADATA/cnf/URLconversion.post.cfg. This enables the operator to handle the URL conversion differently for the dif-ferent billing systems in use.

Value Description

0 Ask for every transaction which associates cost.

1 Ask if additional content billing will be done. The subscriber accepts the operator’s cost, but not the content provider’s.

2 Do not ask anything. The subscriber is aware of the cost and accepts it.

3 Never ask for Push, otherwise always....

4 .... ask for Push and for additional costs

5 ....ask and do not accept content cost if there is no possibility to ask for

126

Additional Features

1

4

5

2

3

6

7

A

I

If wIQ billing is switched on in the configuration, both tables must exist. wIQ issues an error message if a transaction occurs which needs a conversion table which does not exist.

6.1.2.6 Billing Scenarios for Push

The billing mechanism depends on different values:

Destination MSISDN

– The one who should receive a message and normally would not pay for anything.

Source MSISDN

– The one who ordered the service and normally would pay for every-thing

Provider

– The one who earns money for the page-request and is defined inside the wIQ tag of the HTML page.

Coins

– The definition of cost inside the HTML header (may be negative)

– also called content cost

Transport Costs

– The definition of costs for the data transmission (always greater than orequalling zero)

The pseudo-URLs "TEXT" and "ESMS" are also valid for URL con-version.

127

Additional Features

1

4

5

2

3

6

7

A

I

In the following table, you find an example for different billing scenarios.

This example shows who is when billed for what.

6.1.2.7 Billing of Regular ESMS

A Regular (sized) ESMS integrates seamlessly in the existing billing process flow. It is billed for Transport and content as configured in the respective source (HTML or Push) within the regular wIQ work flow.

Billing Example

Src MSISDN

DestMSISDN

Povider Coins TransportAccount

SrcMSISDN

AccountDest

MSISDN

AccountProvider

PushBillNegativeCoins=source

11111 22222 33333 15 5 -5-15

+15

11111 22222 33333 -15 5 -5+15

-15

PushBillNegativeCoins=dest

11111 22222 33333 15 5 -5-15

+15

11111 22222 33333 -15 5 -5 +15 -15

Please be careful by setting up a browse USSD session. The billing will use the settings from the first Push for the complete session !!

This means the source-MSISDN has to pay for every transaction the subscriber will perform during this session !!

128

Additional Features

1

4

5

2

3

6

7

A

I

6.1.2.8 Billing of Long ESMS

The Long ESMS processing is slightly different. The Long ESMS is split into a set of concatenated SMSs by the LongESMSProcessor module. The content and transport cost for the whole SMS will be billed with the last outgoing con-catenated SMS.

6.1.2.9 Different Billing Types

General Remark:

It is up to the operator’s billing system(s) to compute the actual cost associated with a transaction for both accounts.The wIQ billing tickets include information which is neccessary, especially the wIQ coins defined in the HTML content. The billing systems have to be aware that even negative amounts for wIQ coins are possible to pay the subscriber, e.g. when viewing the content provider’s advertisements.

Prepaid / Postpaid Differentiation

To distinguish between pre- and postpaid subscribers, wIQ adds another field ’Pre-Post’ to the subscriber database which might hold the following informa-tion:

Subscribers unknown to the prepaid billing system are treated as postpaid subscribers or postpaid content providers. After the successful delivery of the content a CDR is written. This second "ticket" targeting the content provider’s account is of the type ’IOWIQ’ (Internet Originated wIQ ticket) in contrast to the ’ticket’ targeting the subscriber’s account which is of the type "MTWIQ" (Mobile Terminated wIQ ticket).

Value Description

0 Unknown.

1 Prepaid subscriber.

2 Postpaid subscriber.

129

Additional Features

1

4

5

2

3

6

7

A

I

The IOWIQ ticket might be viewed as an inversion of the MTWIQ ticket, as the content provider should be debited if the subscriber is credited and vice versa.

It is up to the billing system to compute the actual cost of the transaction.

IN-based Billing

The wIQ uses an OUM-based query to check if an account has sufficient funds for the transaction to be made. For this check, a ’first query’ is used. The cost of the transaction is reserved by this query if the account is found and the bal-ance is sufficient. After the successful delivery of the content, the wIQ issues a ’Call Complete’ message to debit the account with the cost already reserved by the ’first que-ry’.

In case of content which includes a price tag, a query is not only made for the subscriber’s account, but also for the account of the content provider (read from the ’ProviderMap’). This second ’ticket’ targeting the content provider’s account is of the type ’IO-WIQ’ (Internet Originated wIQ ticket) in contrast to the "ticket" targeting the subscriber’s account which is of the type ’MTWIQ’ (Mobile Terminated wIQ ticket). The IOWIQ ticket might be viewed as an inversion of the MTWIQ ticket, as the content provider should be debited if the subscriber is credited and vice versa.

It is up to the billing system to compute the actual cost of the transaction.

Postpaid Billing

As in the prepaid case, the wIQ creates for each transaction a ’MTWIQ’ ticket with targets the subscriber’s account. If there was a price tag in the content, wIQ also creates a ’IOWIQ’ ticket that targets the content provider’s account.

Again, it is up to the billing system to compute the actual cost of the transac-tion.

130

Additional Features

1

4

5

2

3

6

7

A

I

BillingConfiguration

For the configuration of the wIQ billing subsystem, the following variables are added to the wIQ configuration file $ORGADATA/cnf/wIQ.cfg:


wIQ.Billing c[1..5] General switch to switch the billing on/off. ’True’, ’False’, ’On’, ’Off’, ’1’, ’0’, ’IN’ are valid values. If the variable is not found, no billing is performed.If billing is switched off, the other billing variables (see below) are not read.’IN’ activates the IN billing.

wIQ.CoinPrecision i The number of digits in the frac-tional part of coins (in output).

wIQ.PostpaidInfo c[1..256] This is the message wIQ uses to inform the postpaid (if IN billing is enabled)/all (if IN billing is not enabled) subscribers that a transaction will cost something.

wIQ.PrePaidInfo c[1.256] This is the message wIQ uses to inform the prepaid subscribers that a transaction will cost something.(A)*

wIQ.ProviderError c[1..256] This is the message wIQ sends if a content with an unknown provider should be sent.optionalDefault: ""(A)*

131

Additional Features

1

4

5

2

3

6

7

A

I

wIQ.INbillingUnknown-SubscriberMsg

c[1..256] This is the message wIQ sends if a subscriber is unknown to the IN billing system. If not defined (default value), the content will be sent and subscriber gets a prepaid CDR.(A)*

wIQ.INbillingTimeout-Mesg

c[1..256] This is the message wIQ sends if a timeout while the communi-cation to the IN billing system occurred. If not defined, the content will be sent and the subscriber gets a prepaid CDR.Default : ""(A)*

wIQ.INTextPushBillingType i Decide if Text-Push messages should0 - never be billed (default)1 - content billing should be

done2 - usage billing should be doneThis configuration variable does only affect Text-Push messages billed via IN.

wIQ.negativeINbilling i This value defines how to han-dle negative coins for a prepaid subscriber (will receive money):0: just write an INFO message into protocol1: write an prepaid CDRDefault: 0(A)*


132

Additional Features

1

4

5

2

3

6

7

A

I

wIQ.INnotEnoughDebit c[1..256] This is the message wIQ uses to inform prepaid subscribers that they have not enough credit for this content.(A)*

wIQ.maxHostConnections i Maximum number of open con-nections to a host:port combi-nation. If the queued HTTP requests reach this limit, wIQ rejects more USSD requests with an error message.Default: 0 (no limit)(A)*

wIQ.BusyMessage c[1..256] Message sent (to subscriber) if the internal buffer (see ’wIQ.maxHostConections’) with queued HTTP requests exceed the limit.Default: "The system is busy, please try again later."(A)

wIQ.UrlConvUnkPre c[1..256] This string is used for prepaid subscribers as converted URL if no expression in the URL con-version table matches. If the string is <url>, the original URL will be used. This is the default.


133

Additional Features

1

4

5

2

3

6

7

A

I

wIQ.UrlConvUnkPost c[1..256] This string is used for postpaid subscribers as converted URL if no expression in the URL con-version table matches. If the string is <url>, the original URL will be used. This is the default.

wIQ.INbillingNoLoad i If the billing type of the requested page is usage billing (see ValidUrl.cfg) and this parameter is set to 1, the debit of the subscriber is checked before wIQ loads the requested Web page. If the subscriber does not have sufficient debit for the Web page or if the subscriber does not confirm the cost, wIQ does not load the requested Web page.0 - load page before IN reserva-tion1- first do IN reservation/ask for confirmation and then load the page


134

Additional Features

1

4

5

2

3

6

7

A

I

The configuration of what is written to the CDR files is configured in a sepa-rate configuration file $ORGADATA/cnf/Notifications.cfg.

Each configuration line in the file has the following syntax:

<class>.<number>.<variable> = <value>

wIQ.INbillingNoLoadcont.

If the requested page is config-ured for content billing, wIQ must load the page before the IN reservation to check the cost configured in the page.

Therefore this configuration variable has no meaning for content billing.This variable does only take effect if IN billing is used.Default: 0(A)*

* This variable will only be read if IN billing is enabled.

Value Description

class Notification class. At the moment, ’Postpaid’, ’Prepaid’, and ’Statistic’ are supported.

number Consecutive number of the entry starting with '1'.

variable The name of a configuration variable.


135

Additional Features

1

4

5

2

3

6

7

A

I

General configuration variables:

File-specific configuration variables:

Fifo-specific configuration variables:


Type The output type. Currently 'FILE' and 'FIFO' are sup-ported.

Address The target directory for the output.

Format The format of the output string (see below).

File Description

Filename Filename-pattern for the output file (without path name). See below for the tags allowed here.

WorkExtension File extension that is used while the file is open.

FlushTime Maximum time (in seconds) a file is used before a new one is created.

Fifo Description

FlushSize Maximum number of entries that are written to a FIFO file.

FlushTime Maximum time (in seconds) a file is used before a new one is created.

136

Additional Features

1

4

5

2

3

6

7

A

I

The format configuration string might include the following variables:

The filename configuration string might include the following tags:

Value Description

$(MSISDN) MSISDN of the billed party (subscriber with MTWIQ ticket, content provider with IOWIQ ticket).

$(URL) The original URL.

$(URLCONV) The converted URL.

$(LOCATION) The subscriber’s location (empty for the content pro-vider).

$(COINS) The coins from the HTML content (if any).

$(DATE) The date the ticket was caused (Format: YYYYM-MDD).

$(TIME) The time the ticket was caused (Format: HHMMSS).

$(IMSI) The billed parties if IMSI is present.

$(PREPAIDFLAG) The billed parties’ prepaid flag. 1 means prepaid ; anything else is treated as postpaid.

Variable Description Range

%H Hour 00 - 23

%M Minute 00 - 59

%S Seconds 00 - 59

%d Day of month 1 - 31

%m Month 1 - 12

137

Additional Features

1

4

5

2

3

6

7

A

I

6.1.3 Licensing

wIQ uses a license string to verify whether the operator is allowed to use the product on a particular machine.

This licensing mechanism is extended to allow extra licensing for the wIQ bill-ing/IN billing mechanism. Licensing of IN billing will always include (normal = CDR-based) billing.

It is only allowed for an operator to switch on the billing (wIQ.Billing=Yes) or IN billing (wIQ.Billing=IN) if the license string issued by ORGA includes the bill-ing license.

6.1.4 Example

This section describes a typical wIQ session with one transaction which also involves content-based billing.

1.) The subscriber with the MSISDN 1029384756 chooses a service number, e.g. *108# which is mapped by the ’USSD to URL Mapping’ table to a URL which uses the HTTPS protocol.

2.) This URL is defined in the ’ValidURL’ table as valid and has the billing defined as ’2’ (’Billing is done, price tags are allowed in HTML content’).

3.) wIQ fetches the URL from the internet and looks for a price tag. The price tag in this page is <wIQ coins=100 provider=ORGA>

%y Year (last two digits of year) 00 - 99

%Y Year (four digits) 1900 - ...

%s Daylight saving time 0 (no), 1 (yes), x (unknown)

%% The character ’%’ -

%t unix timestamp (the number of seconds since 00:00:00 UTC, January 1, 1970)

-

Variable Description Range

138

Additional Features

1

4

5

2

3

6

7

A

I

4.) wIQ now looks up the provider ORGA in the ProviderMap and gets the provider’s MSISDN, e.g. 5647382910.

5.) Before communicating with the billing system, wIQ checks in the ’URL-conv’ table whether a conversion of the URL should take place. In our case, the URL is converted to the value 357.

6.) wIQ then checks the subscriber database’s field ’PrePost’ for the billing type of this subscriber, in this case it is ’0’ (unknown)

7.) wIQ now checks with the IN-OPSC whether the subscriber is a prepaid one and has sufficient debit for this transaction.

8.) This is the case and the wIQ in return to this query gets the total amount that this transaction costs.

9.) Then this subscriber’s database field ’PrePost’ is updated to the value ’1’ (Prepaid).

10.)wIQ now checks with the IN-OPSC whether the content provider is pre-paid and has sufficient funds for this transaction.

11.)This is not the case, the content provider has a postpaid account.

12.)This subscriber has configured his personal configuration to inform him that a transaction with content-based billing is taking place (CostInfo Flag ’1’, ’Ask if additional content billing will be done.’), so wIQ creates a Mes-sage like ’This transaction will cost 1.02 Euros. Ok?’

13.)The subscriber answers this query with a ’Y’

14.)The wIQ then returns the valuable information it retrieved from the con-tent provider’s HTML page and

15.)wIQ requests the IN-OPSC to perform the billing for the subscriber.

16.)For the content provider’s account, a wIQ CDR is created which the oper-ator’s postpaid billing system uses to credit the content provider.

139

Additional Features

1

4

5

2

3

6

7

A

I

6.2 Push Interface

The Push interface of wIQ initiates Pushes by sending HTTP-requests. You do not have to deal with with protocol internals of wIQ or the router. This allows you to carry out easily your own services on top of this one.

6.2.1 General Architecture

The Web interface for Push is running as a FCGI on the wIQ Web server (or on another FCGI-enabled apache server). Clients can connect to the FCGI via HT-TP. To initiate a Push, the client sends an HTTP-request (see the section 6.2.2.1 on page 142 for the parameters) to it and receives the result of the Push op-eration (e.g. SUCCESSFULL) in the corresponding HTTP-response.

Because the wIQ core has to process these requests, there has to be an inter-face between wIQ and the FCGI Push interface. This is done with the help of the router which connects them.

The wIQ core generates a USSD Push or an SMS (depending on the bearer) from the data, which is then sent to the corresponding driver via the router. The driver finally delivers the Push to the destination mobile phone.

You need an extra license for Push!

140

Additional Features

1

4

5

2

3

6

7

A

I

6.2.2 Push-request and Response

The Push FCGI expects its input parameters in a HTTP-request as post param-eters or query string. The format for every parameter has to be name=value.

The answer containing a status value for the Push operation will be sent back in the body of a HTTP-response of the type text/html.

For performance issues it may be useful to run the FCGI Push inter-face on another machine than the wIQ core. This machine must run an FCGI-enabled apache server.

141

Additional Features

1

4

5

2

3

6

7

A

I

6.2.2.1 Push-request

The following table lists the possible parameters for a Push-request:

Parameters for the FCGI Push Interface

Name ValueMandatory/

Optional

dest The MSISDN of the recipient. Mandatory

src The MSISDN of the Push initiator. Mandatory

data snr: text contains a USSD Servicenum-ber with optional preinput and leading/trailing star and hash characters.url: text contains a URL.txt: text contains a plain text message.

Mandatory

text see data for the possible contents of text

Mandatory

sessiontype none, finish, finish-sms, browse, or sms Optional. Default:finish.

provider For data=txt it is possible to set a pro-vider who gets or pays the number of coins which are defined.

Optional

coins The definition of cost for data=txt messages.Needs to be in combination with pro-vider.

Optional

aparty For sessiontype=sms it is possible to define the sender MSISDN of an outgo-ing short message.

Optional

142

Additional Features

1

4

5

2

3

6

7

A

I

URL encoding has to be used for all special characters in the value field, e.g. space, hash, ...

Example URL with query string:

http://od-scp-1:8888/fcgi-bin/wIQpush?dest=1234567&

src=1234567&data=txt&text=Hello%20world&session-type=finish

6.2.2.2 Push-response

The HTTP-response of the FCGI Push interface includes the status of the Push in the body of the returned page. The layout of the returned page can be set with templates.

There are two types of templates:

1.) One for status values returned by the router/wIQ core. There are status values for success and several types of possible failures.

smsinterface For sessiontype=sms it is possible to define the used method or interface to send the SMS(MAPSMS0, MAPSMS1 (optional), MAPSMS2).

Optional

response This parameter overrides the parameter ’wIQpush.awaitResponse’ in the config-uration file and can take the values 0 and 1 as listed in section 6.2.3.2 on page 146.

Optional

Note that URL encoding is used in the example for the space char-acter (%20).

Parameters for the FCGI Push Interface

Name ValueMandatory/

Optional

143

Additional Features

1

4

5

2

3

6

7

A

I

2.) One for errors generated by the Push FCGI itself.There are situations for the Push FCGI to generate the answer on its own with-out communicating with the wIQ core:

the Push FCGI recognizes that the maximum number of transactions per minute given in the configuration file is reached. Then a response (PUSH_LIMIT_REACHED) is immediately sent back.

A connection error between the Push FCGI and the router/wIQ core has happened, e.g. no connection possible. Then a response (CONNECTION_ERROR) is sent back.

A request from the FCGI to the router/wIQ core has been timed out, i. e. no answer has come back during the timeout period given in the configu-ration file. Then a response (REQUEST_TIMEOUT) is sent back.

The templates are configured in the configuration file (see section 6.2.3.2 on page 146).

During startup, the templates from the template directory are read into inter-nal memory. If you change them, you must send a configuration reload signal to the wIQpush process for them to be reread.

Templates are HTML files with a variable $(status) placed in the directory given by ’wIQpush.TemplateDirectory’. Before printing the template, the vari-able is replaced.

Note that a client using the Push FCGI should be prepared to handle the case that the maximum number of transactions per minute is reached. He should cancel sending requests in this case and try again a minute later.

144

Additional Features

1

4

5

2

3

6

7

A

I

Example: Status Template

Result: wIQ core returned „SUCCESS“

Note that it would be also possible to write just $(status) in the template if you do not want surrounding HTML-tags. If you want the reason for an error to be hidden, you do not include $(sta-tus) in the error template.

<HTML><TITLE>Status</TITLE><BODY>wIQ returned $(status)!</BODY></HTML>

<HTML><TITLE>Status</TITLE><BODY>wIQ returned SUCCESS!</BODY></HTML>

145

Additional Features

1

4

5

2

3

6

7

A

I

6.2.3 wIQpush Process

The process named wIQpush is normally located in $ORGAROOT/apache/fcgi-bin/.

6.2.3.1 License

In a first step, the FCGI itself will not check the license at all. If it sends requests to the wIQ core and the wIQ Push interface is not licensed, they will not be answered and the Push FCGI will send an error after a timeout period.

In further versions, the correct license entry will be checked on startup with a special request that is sent to the wIQ core. It will be answered with the Push license entry if available.

6.2.3.2 Configuration File

The Push FCGI has its own configuration file. Normally it is located in$ORGADATA/cnf/wIQpush.cfg.

If you want to use a different configuration file, you have to set it with the ’AppClass’ directive in the httpd.conf (see section 6.2.3.3 on page 150).

wIQ Push services must have an extra license entry in the wIQ license file. As the Push FCGI must not run on the same machine as the wIQ core does, it may not be able to check the license file directly.

146

Additional Features

1

4

5

2

3

6

7

A

I

The configuration file has the following entries:

Push FCGI Configuration File Entries

Name Type Description

wIQpush.Port Default:Mandatory Port on which the Push FCGI tries to connect to the router/wIQ core.Type: i

wIQpush.Interface Default:Mandatory Interface on which the Push FCGI tries to connect to the router/wIQ core.Type: IP adress or

hostname

wIQpush.Pushes-PerMinute Default:Mandatory Maximum number of Pushes that will be performed per minute. If this entry is set to zero, the Push FCGI is disabled. Note that the overall maxi-mum value is defined by the limit for transactions per minute in the wIQ license file.

Type: 1

wIQpush.Debug Default: 0 (off) Switches debug output on when set to 1, otherwise off.

Type: i {0,1}

wIQpush.DebugLevel Default: 1Type: i {0..9}

Sets the level of debbuging information.

wIQpush.NumberOfThreads Default: 20 Number of threads spawned by the FCGI which will accept requests.

Type: i

wIQpush.Request-Timeout Default. 25 The period in seconds until the answer to a request from the FCGI to the router/wIQ core must have arrived.

Type: i

147

Additional Features

1

4

5

2

3

6

7

A

I

wIQpush.Logfile Default: $ORGA-DATA/log/wIQ-push.log

Path and file name of the log file. This might also be a pipe!

Type: filename

wIQpush.TemplateDir Default: $ORGA-DATA/tem-plates

Path to the directory containing the templates.

Type: path name

wIQpush.ErrorTemplate Default: error Name for the error template.

Type: file name

wIQpush.StatusTemplate Default: status Name for the template used to report status-responses.

Type: file name

wIQpush.awaitResponse

Default: 1 (on) If set to 0, the Push FCGI will generate a "SUCCESS" status-response on its own without waiting for the answer of the router/wIQ core. The router/wIQ core answer will only be written to the logfile!If set to 1, the Push FCGI will wait for the answer of the router/wIQ core.

Type: i {0,1}

Note that ’wIQpush.RequestTimeout’ should be shorter than the HTTP-timeout of the client-requesting the Push. If the client is a browser, the HTTP-timeout is normally 30 seconds.

Push FCGI Configuration File Entries

Name Type Description

148

Additional Features

1

4

5

2

3

6

7

A

I

Lines starting with # will be treated as comments. Lines with unknown vari-ables will be ignored.

149

Additional Features

1

4

5

2

3

6

7

A

I

Example:

#wIQpush example config filewIQpush.Port=5838wIQpush.Interface=od-scp-1wIQpush.Pushes-PerMinute=100wIQpush.Number-OfThreads=20wIQpush.RequestTimeout=25wIQpush.Logfile=/tmp/wIQpush.logwIQpush.TemplateDir=/tmp/templateswIQpush.ErrorTemplate=error_templatewIQpush.StatusTemplate=status_templatewIQpush.awaitResponse=1

6.2.3.3 Startup

FCGI programs will be started automatically from the apache server in its star-tup procedure. In order to achieve this, you have to add lines similar to the following to the apache configuration file httpd.conf in the module con-figuration, e. g. after the CGI configuration. This example assumes that the FCGI will be placed in apache/fcgi-bin/:

PassEnv ORGADATA ORGAROOTFastCgiIpcDir /tmp/fcgiAlias /fcgi-bin/ "/home/wiq/WIQUSSD/apache/fcgi-bin/"

<Location /fcgi-bin>Options -Indexes +ExecCGISetHandler fastcgi-script

</Location>

FastCgiServer "/home/wiq/WIQUSSD/apache/fcgi-bin/wIQpush\"-initial-env ORGADATA\

-initial-env ORGAROOT

The ’FastCgiServer’ directive can take the parameter

-initial-env ConfigFile=filename

which will override the value for the configuration file, e.g.

FastCgiServer "/SCMbd/AGrote/SCMws/WIQUSSD/apache/fcgi-bin/wIQpush"

150

Additional Features

1

4

5

2

3

6

7

A

I

-initial-env ConfigFile=/tmp/wIQpush.cfg

will set the configuration file to /tmp/wIQpush.cfg.

Apache can be started with the command apachectl start or by the wIQ startup sequence.

6.2.3.4 Signals

The following signals will be handled:

TERM: This is considered a request for "clean" shutdown, i.e. finish any-thing you are in the middle of, free resources, and exit. Apache uses this signal to request a "graceful" process shutdown (e.g. it is used by apachectl restart or apachectl stop).

USR1: Toggles debug output on or off.

USR2: This signal will trigger a configuration reload

Make sure that the PID of the wIQpush process gets used.

6.2.3.5 Configuration Reload

The port and interface settings will not be changed by a configuration reload. If you want to change these values, you have to terminate the process. All other values (including the templates) will be reloaded from the configuration file when receiving the signal for reconfiguration.

6.2.3.6 Termination

When the process is terminated by receiving a signal, it will be immediately restarted by the apache server. In order to terminate without automatic re-start, you have to stop the whole apache server (apachectl stop).

151

Additional Features

1

4

5

2

3

6

7

A

I

6.2.3.7 Exit Codes

If a critical error occurs and wIQpush has not yet access to the log file, it exits with the following exit codes:

If possible, errors will be reported to the log file. In this case, the exit code is 1 and the reason is reported to the log file.

6.2.3.8 Logging

The logfile defaults to $ORGADATA/log/wIQpush.log.

If you want it to be shared with the wIQ log file, change it to$ORGADATA/.logger

This is the pipe created by the wIQd which is moved to a new file daily.

Information about processing the requests, errors, warnings etc. are logged into this file. Data is always appended.

Exit Code Reason

11 Cannot read configuration file.

12 Config file has wrong format.

13 Cannot write to logfile.

14 Miscellaneous internal errors.

Note that the exit code will be logged in the apache error log file.

Note that you have to expand the $ORGADATA variable to its actual path, writing $ORGADATA is not possible

152

Additional Features

1

4

5

2

3

6

7

A

I

6.2.4 Use Cases

These use cases regard a client sending a HTTP-request to the Push FCGI. The Push FCGI requests an answer from the wIQ core via the router. If this one comes in, the Push FCGI generates a HTTP-response and sends it back to the client.

6.2.4.1 Client Aborts Request

The client of the Push FCGI aborts the request. As the FCGI library does not signal this to the Push FCGI, it will complete the whole request and try to give the response back to the client. This is the point where it will recognize that the connection was aborted and cancel the request.

6.2.4.2 Connection Failure

If the connection between the Push FCGI and the router/wIQ core is broken, the Push FCGI will generate an error-response on its own (see the section 6.2.2.2 on page 143). The response will be generated out of the error tem-plate and sent back to the client.

6.2.4.3 Web Server Timeout

If the Web server times out the connection from the client to the Push FCGI (e.g. HTTP-timeout) while the Push FCGI is still in progress getting the answer, there is the same situation as with a client abort.

6.2.4.4 Request Timeout

If the response from the router/wIQ core to an request of the Push FCGI takes too long, the Push FCGI will generate an error-response (see the section 6.2.2.2 on page 143). The response will be generated out of the error tem-plate and sent back to the client.

6.2.4.5 wIQ Core Reports Status

If a request of the Push FCGI is answered with a response from the router/wIQ core, the Push FCGI will generate a response (see the section 6.2.2.2 on

153

Additional Features

1

4

5

2

3

6

7

A

I

page 143) for the client. The response will be generated out of the status tem-plate and sent back to the client.

6.2.5 Remark on Billing

If you want to use billing in conjunction with pushing text (data=txt), the URL you have to use for the provider map (see section 6.1.2.3 on page 121) and URL conversion (see the section ”URL Conversion” on page 126) is ’TEXT’.

If you want to bill a directly pushed ESMS, the URL to use in these files is ’ESMS’.

154

Additional Features

1

4

5

2

3

6

7

A

I

6.3 SMS Center Interfaces

6.3.1 General

A driver is used for the communication between the SMSC client and the router. The SMSC client communicates on CURRY via OMB, the router over TCP/IP.

You need an extra license for SMS!

155

Additional Features

1

4

5

2

3

6

7

A

I

The OMB provides single and multiple consumer and producer queues.

6.3.1.1 CURRY Protocol

The CURRY protocol wraps the former SMSC client protocols

SMPP

EMI

156

Additional Features

1

4

5

2

3

6

7

A

I

CIMD.

It is adapted from CIMD.

The CURRY protocol is connection oriented. Nearly every message is an-swered with a response.

6.3.1.2 OMBmanager

The OMBmanager is used to handle the message sent via OMB.

6.3.1.3 Program Name

The executable program name is DriverCurry. It is located in $ORGAROOT/run/bin.

6.3.1.4 General

When started, the DriverCurry tries to connect to the OMBmanager. If it is not possible, it prints an error message and retries to connect every ’Drv.Con-nectAgain’ seconds.

When it has a connection to the OMBmanager, it tries to connect the router. If it gets no connection to the router, it prints an error message and tries again every ’Drv.ConnectAgain’ seconds.

When connected to the router, the router can send messages.

When the connection to the router is lost, it prints an error message and tries to connect every ’Drv.ConnectAgain’ seconds.

When the connection to the OMBmanager is lost, it prints an error message. The router will not send messages and tries to reconnect to the OMBmanager every ’Drv.ConnectAgain’ seconds. The connection to the router stays open. When reconnected, the router can send messages.

6.3.1.5 Signals

When the router receives a USR1 signal, it switches the debug information on.

If the driver receives a USR2 signal, it has to reread the configuration data and maybe close its old connections and open new ones.

157

Additional Features

1

4

5

2

3

6

7

A

I

The status of all messages that had not been sent are not changed.

The messages must be sent over the new connections.

6.3.1.6 Command Line Options

6.3.2 Driver Configuration

The configuration file for DriverCurry is normally located in $ORGADATA.

The Filename is DriverCurry.cfg.

If a pattern is passed with the -c option (for example DriverCurry/Conf.cfg), the driver searches for configuration file$ORGADATA/DriverCurry/Conf.cfg.


Drv.<VARIABLE NAME>=<CONTENT><NEWLINE>

Option Meaning

-c <pattern> Use pattern (relative to $ORGADATA) as configuration file for the router (instead of the standard name$ORGADATA/DriverCurry.cfg).

-D Enable debug.

-V <number> Set debug level.

-h Show usage.

158

Additional Features

1

4

5

2

3

6

7

A

I

If the value for a parameter is invalid, the default value is taken (if it applies, so this is only possible for optional parameters). Otherwise the program ter-minates with a panic.

Variable Name Type Description

Drv.RouterPort Mandatory Port number to wIQ/router

Default: -

Type: n[1024...65535]

Drv.RouterPing Default: 25 Ping time in seconds to router/wIQ

Type: n[0...]

Drv.RtPingTout Default: 25 Time gap in seconds between checks for missing PONGs

Type:n[0...]

Drv.RouterHost Mandatory Host of wIQ/router

Default: -

Type: c[...]

Drv.OmbMgrPort Mandatory Port number of Omb manager

Default: -

Type: n[1024...65535]]

Drv.OmbMgrHost Mandatory Omb manager host

Default: -

Type: c[...]

159

Additional Features

1

4

5

2

3

6

7

A

I

Drv.OmbMgrPing Default: 25 Ping time in seconds to OMBmgr

Type: n[0...]

Drv.ConnectAgain Optional Must be greater than 0.If the connection to the OMB-mgr or the router is lost, the driver tries to connect to that device every ’Drv.ConnectAgain’ seconds.

Default: 5

Type: n[1...]

Drv.SMSCQueueIn Mandatory Name of OMB queue for incom-ing messages (messages from SMSC client).Default: -

Type: c[...]

Drv.SMSCQueueOut Mandatory Name of OMB queue for outgo-ing messages (messages to SMSC client).Default: -

Type: c[...]

Drv.SessionIdStart Optional Start number for TRID on session layer.

Default: 1

Type: n[1...]

Drv.SessionIdDelta Optional Increment of TRID on session layer for each message.

Default: 1

Type: n[1...]


160

Additional Features

1

4

5

2

3

6

7

A

I

Example file DriverCurry.cfg:

Drv.RouterPort=9999

Drv.RouterPing=10

Drv.RouterHost=223.255.255.2 or xxx.orga.com

Drv.OmbMgrPort=8888

Drv.OmbMgrPing=0

Drv.OmbMgrHost=223.255.255.1 or xxx.orga.com

A Ping time with 0 means no PING.

6.3.2.1 OMBmgr Configuration

The OMBmgr is to be started with:

OMBmgr -DCM -p<port> -S

The port number is to be the same as ’Drv.OmbMgrPort’.

When not started with -DCM the SMCS client will not start!

The OMBmgr uses a configuration file called $ORGADATA/Omb/Config. It contains the queues.

Drv.ValidityPeriod Default: 1200

Time in Seconds.This value is added to the actual time on the host to get the VALIDITY_PERIOD_ABSOLUTE (if the message is not delivered to the MS at this date, the mes-sage expires)

Type: n[...]


161

Additional Features

1

4

5

2

3

6

7

A

I

Configfile syntax:

# Queue1QUEUE queueIn TCP# Queue2QUEUE queueOut TCP

In this case the OMBmgr would create two queues one with name queueIn the other named queueOut.

6.3.3 SMSC Client

The SMSC client provides mechanisms for communication with all different SMSCs and their protocols. The SMSC and therefor the used protocol can be defined as a parameter.

In the direction of CurryDriver, the client communicate on the CURRY protocol over OMB. In the other direction on the given protocol (depending on the connected SMSC).

Each SMSC client has a set of configuration parameters which contain the IP address and the port number of the corresponding SMSC.

It is possible to establish 1 receiver connection and n transmitter connections.

6.3.3.1 Process Invocation

The SMSC Client process is named stsc_smsc and invoked by the following command line syntax:

stsc_smsc [-l][-h]

[-S]

[-D] [-v level] [-q]

[-p port] [-o hostname]

where

-S Select Aldiscon/Logica SMPP protocol, default CMG EMI 3.5

-h Display usage

162

Additional Features

1

4

5

2

3

6

7

A

I

-D Start in debug mode, turns on full verbose mode

-DCM Use $ORGADATA/Config file (standard)

-I id Set client identifier (i.e. queue number) to id

-o hostname Use OMB manager on hostname, overwrites configuration

-p port Use port for OMB communications, overwrites configuration

-q Set quiete mode, overwrites trace level (*)

-v level Set trace level to level, restricts verbose mode (*)levels defined per module (maybe ORed):OMB_VERBOSE_BIT 0x80,128SMSC_VERBOSE_BIT 0x40, 64SMPP_VERBOSE_BIT 0x20, 32EMI_VERBOSE_BIT 0x10, 16CIMD_VERBOSE_BIT 0x08, 8MPX_VERBOSE_BIT 0x04, 4NW_VERBOSE_BIT 0x01, 1

All standard debugging options may be used as well.

The process exits with an exit code of 0, if normally terminated, or 1, if a fatal error occurred. In the latter case a panic message is written to the protocol file explaining the reason.

6.3.3.2 Signals

The SMSC Client implements a special behaviour at the time of receiving the following signals:

USR1: Toggle debug mode on/off;

has no effect on running connections

USR2: Re-read configuration;

running connections are dropped.

SIGINT: The process is terminated;

163

Additional Features

1

4

5

2

3

6

7

A

I

running connections are dropped.

SIGTERM: Same as SIGINT.

6.3.3.3 Configuration

The SMSC Client supports the STC Configuration Management and the old fashioned $ORGADATA/Config configuration file through the -DCM option on process invocation. Almost all configuration parameters are described by means of the stsc_smsc.cmt CMT file. Some shared configuration param-eters are covered by etc.cmt.

Since a default value is assigned to each configuration parameter, all param-eters are optional. If the SMSC Client cannot find a configuration parameter (i.e. the parameter is missing from the CMT database or the Config file re-spectively), its default value is used instead. Otherwise a range check is per-formed. If the parameter value lies within the defined boundaries, the value is accepted, otherwise an error message is thrown. It is up to the main module to panic in this situation.

Character values may be surrounded by double quotes. A single dash without leading or trailing blanks is assumed to be a Null value (CMT kludge). A single dash in double quotes ("-") is not a Null value, but is taken literally.

In the following tables the <xxx> replacement defines the Client Identifier (or Queue Number) within the allowed range of 0 - 999.

General Parameters

Parameter Meaning

STSC.OmbPort Type: irange 1024 - 9999

OMB Manager Port number

optional

Default: 8000

164

Additional Features

1

4

5

2

3

6

7

A

I

STSC.OmbHost Type: c[0..64] OMB host name or IP address

optional

Default: "localhost"

Common Protocol Parameters

Parameter Meaning

STSC.SMCLT<xxx>SMSCAddressRX

Protocol:SMPPEMI

SMSC host name or IP address and port number (format host:port) for receiver connections

Type: c [0..64]

optional

Default: "local-host:7600"EMI set to a single dash

STSC.SMCLT<xxx>SMSCAddressTX

Protocol: SMPPEMI

SMSC host name or IP address and port number (format host:port) for transmitter connections

Type:c [0..64]

optional

Default: "local-host:7600"

General Parameters

Parameter Meaning

165

Additional Features

1

4

5

2

3

6

7

A

I

STSC.SMCLT<xxx>Timeout

Protocol: SMPPEMI

Response Timer, i.e. maximum allowed time laps between a request and corresponding response from other partyType: i,

range 0 - 9999 [sec]

optional

Default: 0recommended 10 secs

STSC.SMCLT<xxx>PingTime

Protocol: SMPPEMI

Alive Timer.The life of the corresponding net-work connection is checked by a protocol-dependent mechanism (example: sending ping or alive PDUs)

Type: i,range 0 - 9999 [sec]

optional

Default: 0recommended 30 secs, should be greater than the Response Timer

STSC.SMCLT<xxx>InactivityTout

Protocol: SMPPEMI

Inactivity Timer The corresponding network con-nection is dropped if no activity is detected within the timeout inter-val

Type: i,range 0 - 9999 [sec]

optional

Default: 0recommended 600 secs, should be greater than the Alive Timer


Parameter Meaning

166

Additional Features

1

4

5

2

3

6

7

A

I

STSC.SMCLT<xxx>RetryTime

Protocol: SMPPEMI

Connect Timer

Type: irange 0 - 9999 [sec]

optional

Default: 10If set to 0, no re-con-nect attempt is made

STSC.SMCLT<xxx>MaxTries

not implemented yet, obsolete

STSC.SMCLT<xxx>NumRetries

Protocol: SMPPEMI

Number of retransmission attempts before request is aborted

Type: irange 0 - 9999

optional

Default: 0(no retransmission)


Parameter Meaning

167

Additional Features

1

4

5

2

3

6

7

A

I

STSC.SMCLT<xxx>Fanin

Protocol: SMPPEMI

Number of receiver connections

Type: irange 0 - (OPEN_MAX-10)**

optional

Default: 1Must be set to 0 for EMI

STSC.SMCLT<xxx>Fanout

Protocol: SMPPEMI

Number of transmitter connec-tions


optional

Default 1

STSC.SMCLT<xxx>Backlog

Protocol: SMPP* Number of incoming connections


optional

Default: 0 (reject all attempts)


Parameter Meaning

168

Additional Features

1

4

5

2

3

6

7

A

I

STSC.SMCLT<xxx>BindAddress

Protocol: SMPP Local host name or IP address and port number (format host:port) for outgoing connections in client mode

Type: c[0..64]

optional

Default ":0", which is bound to any interface

STSC.SMCLT<xxx>ServerAddress

Protocol: SMPP* Local host name or IP address and port number (format host:port) for incoming connections in server mode

Type: c[0..64]

optional

Default: ":7500", which is listening on port 7500

STSC.SMCLT<xxx>Password

Protocol: SMPPEMI

The password is used by the SMSC to authenticate the identity of the binding ESME (i.e. the SMSC Cli-ent). The password is encrypted (cf. man stsc_encrypt).

Type: c[0..16](8 after decrypting)

Default left empty (same as a single dash)

STSC.SMCLT<xxx>CongestionDelay

Protocol: All Time in seconds the retransmission of rejected submit requests is delayed if congestion is reported by the SMSC. The error class of the reported error code must be set to C in the corresponding eclass file.

Type: i range 10..9999

optional

Default: 20


Parameter Meaning

169

Additional Features

1

4

5

2

3

6

7

A

I

* Supported in SMPP V3.4 and above (outbind operation), not implementedyet

**The number of open file descriptors per process (OPEN_MAX) is a systemconstant and at least 16 in the POSIX environment, otherwise 64. The sum of all connections (RX, TX and incoming) cannot exceed the maximum as well. Additionally, if incoming connections are configured, one file descriptoris reserved for the listener. Ten file descriptors are reserved for OLS, stdin, stdout and stderr and other library functions.

***The SMSC Client monitors the traffic for SMSC connections. Optionally, thecorresponding connection is dropped auomatically if no traffic was detectedwithin the time interval in seconds defined by InactivityTout. The connectionto the SMSC is established again after waiting another time interval definedby RetryTime. If InactivityTout is set to 0, the connection remains active.RetryTime must be set to a none zero value to enable the re-connectattempt. PingTime may be used to hold the connection in online state. Forthis reason the value of PingTime must always be less than the value ofInactivityTout.

STSC.SMCLT<xxx>ProtoWindow

Protocol: SMPPEMI

Protocol window i.e. number of outstanding unacknowledged messages

Type: irange 10..9999

optional

Default: 20


Parameter Meaning

170

Additional Features

1

4

5

2

3

6

7

A

I

SMPP-related Parameters

Parameter Meaning

STSC.SMCLT<xxx>SMPP.SourceTON


Type of Number (Source Address),cf. GSM 03.40

optional

Default 0, cf. table below

STSC.SMCLT<xxx>SMPP.SourceNPI


Number Plan Indicator (Source Address),cf. GSM 03.40

optional

Default 0,cf. table below

STSC.SMCLT<xxx>SMPP.DestTON


Type of Number (Destination Address),cf. GSM 03.40

optional

Default 1, cf. table below

STSC.SMCLT<xxx>SMPP.DestNPI


Number Plan Indicator(Destination Address), cf. GSM 03.40

optional

Default 1,cf. table below

STSC.SMCLT<xxx>SMPP.NetworkType

Type: ifixed 0 (TCP/IP),cannot be changed

Type of network, fixed 0 (TCP/IP), cannot be changed

171

Additional Features

1

4

5

2

3

6

7

A

I

STSC.SMCLT<xxx>SMPP.SystemID

Type: c[0..15] The system identifier is used to identify an ESME at bind time to the SMSC.Default left empty

STSC.SMCLT<xxx>SMPP.SystemType

Type: c[0..12] The system type is used to catego-rize the type of ESME that is bind-ing to the SMSC. Default left empty

STSC.SMCLT<xxx>SMPP.ProtocolVersion

Type: c, range 2 characters.Fixed "33" which is SMPP version 3.3, cannot be changed

Protocol version in use.

STSC.SMCLT<xxx>SMPP.EsmClass


ESM Class (cf. table below)

optional

Default: 0

STSC.SMCLT<xxx>SMPP.Priority

Type: i,range 0 - 3

Priority0 == non priority1 == priority (normal)2 == priority (urgent)3 == priority (very urgent)

optional

Default: 0

STSC.SMCLT<xxx>SMPP.ServiceType

Type: i[0..6] The service type can be used to indicate the SMSC application ser-vice associated with the message.optional

Default left empty

SMPP-related Parameters

Parameter Meaning

172

Additional Features

1

4

5

2

3

6

7

A

I

The following Type of Number (TON) values are defined:

The following Number Plan Indicators (NPI) values are defined:

TON Value

Unknown 00000000

International 00000001

National 00000010

Network Specific 00000011

Subscriber Number 00000100

Alphanumeric 00000101

Abbreviated 00000110

NPI Value

Unknown 00000000

ISDN (E163/E164) 00000001

Data (X.121) 00000011

Telex (F.69) 00000100

Land Mobile (E.212) 00000110

National 00001000

Private 00001001

ERMES 00001010

Internet (IP) 00001110

WAP Client ID 00010010

173

Additional Features

1

4

5

2

3

6

7

A

I

The EsmClass parameter is used to indicate special message attributes associ-ated with the short message. The EsmClass parameter is encoded as follows in the submit_sm PDUs:

Esm Class Bits7 6 5 4 3 2 1 0

Meaning

x x x x x x 0 0 Default SMSC mode (e.g. Store and Forward)

x x x x x x 0 1 Datagram mode

x x x x x x 1 0 Forward (i.e. transaction) mode messaging mode (bits 1-0)

x x x x x x 1 1 Store and Forward mode (used to select Store and Forward mode if default SMSC mode is non Store and Forward)

x x 0 0 0 0 x x Default message type (i.e. normal message)

x x 0 0 0 1 x x Short Message contains SMSC delivery receipt message type (bits 2 and 5)

x x 1 0 0 0 x x Short Message contains Intermediate delivery notification

x x 0 0 1 0 x x Short Message contains ESME delivery acknowledgement

x x 0 1 0 0 x x Short Message contains ESME manual user acknowledgement ANSI-41 specific (bits 5-2)

x x 0 1 1 0 x x Short Message contains conversation abort (Korean CDMA)

0 0 x x x x x x No specific features selected

0 1 x x x x x x UDHI Indicator (only relevant for MT short mes-sages)

174

Additional Features

1

4

5

2

3

6

7

A

I

1 0 x x x x x x Set Reply Path (only relevant for GSM network) GSM specific (bits 7-6)

1 1 x x x x x x Set UDHI and Reply Path (only relevant for GSM network)

EMI-related Parameters

Parameter Meaning

STSC.SMCLT<xxx>EMIOADC

Type: c Large Account ID (OADC) used for login procedure (OT 60, Session Manange-ment),

optional

Default: "72567"

STSC.SMCLT<xxx>OTOA

Type: c Optional Originator Type of Address, used when the Originating Address starts with a plus character

optional

Default: "1139" in CMT????? in code left empty ????

STSC.SMCLT<xxx>NotifyAddr

Type: c[0..64] IP address and port of NAdC (notify address) of outgoing messages (format n.n.n.n:port or hostname:port). The SMSC will use this address for deliv-ery notifications

optional

Default: "192.168.1.1:5000"

Esm Class Bits7 6 5 4 3 2 1 0

Meaning

175

Additional Features

1

4

5

2

3

6

7

A

I

STSC.SMCLT<xxx>PingAdC

Type: c[0..15] If pings are used this parameter must be set to AdC address for the alert message, i.e. the address or phone number of this SMSC connection.

optional

Default: "1234567890"

STSC.SMCLT<xxx>PingPID

Type: c If pings are used this parameter can be set to the 4 digit protocol identifier PID.

optional

Default: "0539" (i.e. PC over TCP/IP)

STSC.SMCLT<xxx>Priority

Type: c Sets the priority of a request, if not sup-plied by external entity.

optional

Default: 5

EMI-related Parameters

Parameter Meaning

176

Additional Features

1

4

5

2

3

6

7

A

I

6.4 SMS Services

6.4.1 Session Settings from HTML Content

6.4.2 Use Cases

The following use cases should show a schematic flow of messages for Push/USSD/SMS interaction.

For the exact syntax of the HTTP request/response, see section 6.2.

6.4.2.1 Push to USSD Display

177

Additional Features

1

4

5

2

3

6

7

A

I

6.4.2.2 Push to USSD Prompt with Immediate Answer

6.4.2.3 Push to USSD Prompt with Late Answer

This is a special case for USSD prompt messages. After wIQ has sent the USSD message to a subscriber, he might get no response until a timeout on the USSD session appears. Therefore the Push ’session’ has an extra time which should avoid waiting for response. If wIQ receives no error during the ’wIQ.PushSessionTimeout’, it expects everything is fine and sends a success back to the Push client. The ’wIQ.PushSessionTimeout’ has to be set up very carefully to avoid unnecessary waiting for answers and do not miss possible

178

Additional Features

1

4

5

2

3

6

7

A

I

error USSD or SMS error messages. The variable should be set up in depen-dency from the normal network error reaction time. To ensure that wIQ gets error messages from the network, the timeout has to be set up greater as the normal network reaction time. If the ’wIQ.PushSessionTimeout’ is set to ’0’, the wIQ will confirm a correct Push-request immediately without waiting for any responses of the USSD or SMS session. The returned status of the Push-request is then ’DELIVERED_UNCONFIRMED’. This status means that the re-quest is in progress but not confirmed yet.

179

Additional Features

1

4

5

2

3

6

7

A

I

6.4.2.4 Push to SMS

<wiqsetting> : take the values defined in ’URL to SMS Interface Mapping’ ta-ble.

180

Additional Features

1

4

5

2

3

6

7

A

I

6.4.2.5 Push to FINISH-SMS

181

Additional Features

1

4

5

2

3

6

7

A

I

6.4.2.6 License Additions

6.4.3 Load Distribution (Push / SMS / USSD )

It is not possible to set priorities (inside the wIQ core) for the different kinds of requests (USSD, SMS, Push). To ensure that Push services do not block the other services at all, it is possible to define another limit for Push services. This limit may be defined in the wIQ main configuration file ( see section ”wIQ.cfg: wIQ Configuration File Variables” on page 67) and is called

wIQ.MaxPushQuota={0..100} default: 100

or

wIQ.MaxPushRequests={0..maxPushRequestsPerHours}default:maxPushRequestsPerHours

Both parameters are optional. The absolute lowest limit is always taken.

This means, if e.g. MaxPushQuota is 50, only 50 percent of max request per minute might be taken from Push-requests.

Example 1:

max_requests_per_minute=300 License

max_push_requests_per_minute=200 License

wIQ.MaxPushQuota=50 (operator setting)

( or alternatively

wIQ.MaxPushRequest=150 (operator setting)

A maximum number of 150 Push-requests per minute are allowed.

The Push interface contains also the maximum number of licensed Push-requests per minute. The total number of requests per minute is not increased by the Push limit !

182

Additional Features

1

4

5

2

3

6

7

A

I

If the maximum number of Push-requests is reached, there are 150 requests left for other requests.

Example 2:

max_requests_per_minute=300

max_push_requests_per_minute=300

MaxPushQuota=100

If 300 requests per minute are performed, no request for any kind of request is allowed for the rest of the minute.

There are several new and extended fields of the subscriber database. Default Values Needed for Push

For Push text messages, you need some default values to determine session settings.

’wIQ.PushBillNegativeCoins’ is added to wIQ.cfg to configure which is billed for negative coins within Push.

SMS configuration for Push text messages is performed by a new entry in Url2SMS.cfg.

6.5 wIQ Enhanced SMS

This chapter describes the system interface for the wIQ Enhanced SMS.

The system will enable wIQ to process Enhanced SMS including the majority of the SMS parameters specified in /GSM_03.40/ and /GSM_03.38/ as at-tributes.

You need an extra license for binary ESMS!

You need an extra license if you want to use both binary and textual ESMS!

183

Additional Features

1

4

5

2

3

6

7

A

I

Enhanced SMSs are expressed as structured data in form of wIQ HTML or a set of HTTP parameters on the wIQPush interface (see section ”Push Inter-face” on page 140).

The term ESMS is used for Enhanced SMS in the following sections.

wIQ processes an ESMS via its standard HTML interface and sends it to the mobile phone via the NSG and/or the SMSC interface. ESMS are specified by a wIQ service provider and included as plain text in a wIQ HTML file via an extension of the wIQ specific HTML language.

Additionally, ESMS will be processed by the wIQPush interface to provide pushed ESMS services.

The benefits of ESMS for the wIQ Operator or Service Provider are:

Ringtone SMSs can be processed by the system

Long SMSs can be processed by the system

TPDU parameters (according to /GSM_03.40/, /GSM_03.38/) can be uti-lized within an ESMS. These are:

Immediate display of an SMS on the receiving mobile phone

Replacement of SMSs on the mobile SIM card storage, enabling the update of an existing SMS, e.g. for SMS newsticker services

Modification of message indicators (FAX, VOICE, EMAIL) on the receiving mobile phone

There are two types of ESMS the system will process. They are described in the following:

1. Regular ESMS

A Regular ESMS can contain a maximum of 153 characters (value depending on the alphabet) in the user data section, using the GSM default 7bit alpha-bet. The operator or service provider can specify the ESMS user data section in binary or text format (depending on the license). The ESMS allows the dec-laration of additional User Data Header elements and a set of TPDU parame-ters as ESMS attributes within the wIQ HTML language and the HTTP interface of the wIQPush FCGI component. The user data section is encoded according

184

Additional Features

1

4

5

2

3

6

7

A

I

to the alphabet attribute setting. wIQ translates it into the wIQ SC XML pro-tocol commands.

2. Long ESMS

Long ESMSs have a user data section containing more than 153 characters (value depending to the alphabet). Binary SMSs such as ringtones or picture SMSs for the mobile phone are often longer than the valid 153 characters. In order to send them though, such SMSs need to be split into multiple SMSs that are concatenated. The system will implement the splitting of long ESMSs and build concatenated ESMS containing less or exactly 153 characters user data length each, which are then sent sequentially.

6.5.1 Overview

Ring tone and picture SMSs are binary SMSs that have to be provided in binary format (hexadecimal format) to wIQ.The structure of a TPDU and how to model it as a wIQ HTML page will be de-scribed in the following but this is only an overview of the topics.

The SMS-SUBMIT type of TPDU is the TPDU that will be generated by wIQ when sending an SMS via an SMSC.

6.5.1.1 First Octet of a SUBMIT-TPDU

The first octet of the TPDU (SMS-SUBMIT) has the following layout:

The ESMS support feature applies only to the sending of ESMS. It does not specify wIQ capabilities for receiving both types of ESMS.

Structure of the First Octet of a SUBMIT-TPDU

Bit no 7 6 5 4 3 2 1 0

Name TP-RP TP-UDHI TP-SRR TP-VPF TP-VPF TP-RD TP-MTI TP-MTI

185

Additional Features

1

4

5

2

3

6

7

A

I

Flags of the First Octet of a SUBMIT-TPDU

Fieldname Meaning

TP-RP Reply path. Parameter indicating that reply path exists.

TP-UDHI User Data Header indicator. This bit is set to 1 if the User Data field starts with a header.

TP-SRR Status report request. This bit is set to 1 if a status report is requested.

TP-VPF Validity Period Format. Bit4 and Bit3 specify the TP-VP field according to this table: bit4 bit30 0 : TP-VP field not present1 0 : TP-VP field present. Relative format (one octet)0 1 : TP-VP field present. Enhanced format (7 octets)1 1 : TP-VP field present. Absolute format (7 octets)

TP-RD Reject duplicates.Parameter indicating whether or not the SC shall accept an SMS-SUBMIT for an SM still held in the SC which has the same TP-MR and the same TP-DA as a previously submitted SM from the same OA.

TP-MIT Message type indicator. Bits no 1 and 0 are set to 0 and 1 respectively to indicate that this PDU is an SMS-SUBMIT.

186

Additional Features

1

4

5

2

3

6

7

A

I

Example

A first octet of "11" (hex) has the following meaning:

Protocol Identifier (TP-PID)

The TP-Protocol-Identifier parameter consists of one octet. wIQ ESMs can con-figure only a subset of the possible Protocol Identifier octet's binary values. We have fix val-ues for bit 7 = 0, bit 6 = 1, bits 5..0 are used as defined below.

A short message type 0 indicates that the mobile phone must acknowledge receipt of the short message but may discard its contents. The Replace Short Message feature is optional for the mobile phone and the SIM but if imple-mented, it shall be performed as described here.

Sample of a First Octet of a SUBMIT-TPDU

Bit no 7 6 5 4 3 2 1 0

Name TP-RP TP-UDHI TP-SRR TP-VPF TP-VPF TP-RD TP-MTI TP-MTI

Value 0 0 0 1 0 0 0 1

Protocol Identifier Values Valid for wIQ ESMS

Bits 5..0 Description

000000 Short Message Type 0

000001 Replace Short Message Type 1







187

Additional Features

1

4

5

2

3

6

7

A

I

For mobile station short messages, on receipt of a short message from from the SC, the mobile station shall check to see if the associated Protocol Identi-fier contains a Replace Short Message Type code. If such a code is present, the the mobile station will check the originating address and replace any existing stored message having the same Protocol Identifier code and originating ad-dress with the new short message and other parameter values. If there is no message to be replaced, the mobile station shall store the message in the nor-mal way. The mobile station may also check the SC address as well as the Originating Address. However, in a network which has multiple SCs, it is pos-sible for a Replace Message type for a SM to be sent via different SCs and so it is recommended that the SC address should not be checked by the mobile station unless the application specifically requires such a check.

If a Replace Short Message Type code is not present then the MS will will store the message in the normal way.

Data Coding Scheme (TP-DCS)

The TP-Data-Coding-Scheme field, defined in GSM 03.40, indicates the data coding scheme of the TP-UD field, and may indicate a message class. The octet is used according to a coding group which is indicated in bits 7..4.

Validity Period (TP-VP)

Validity period specifies the time when SM expires. If SM is not delivered be-fore that moment, it is discarded by SC. Validity-Period can be in three differ-ent formats: ’Relative’, ’Absolute’, and ’Enhanced’.

Relative:

The TP-Validity-Period comprises 1 octet in integer representation, giving the length of the validity period, counted from when the SMS-SUBMIT is received by the SC. The representation of time is as follows:

188

Additional Features

1

4

5

2

3

6

7

A

I

Absolute

TP-VP field is 7 octets long, containing TP-SCTS formatted time when SM ex-pires. See /GSM 03.40/ for more information.

Enhanced

See /GSM 03.40/ for more information.

6.5.2 wIQ HTML Language Extension

Within this section, the extensions to the wIQ HTML language regarding the ESMS support for wIQ are described.

We will introduce the following new tags:

dcs

msginddcs

pid

msgindudh

udhie

smshead

vp

Values of the TP-VP field of a SUBMIT-TPDU

TP-VP Value Validity period value

0 to 143 (TP-VP + 1) * 5 minutes (i.e. 5 minute-intervals up to 12 hours)

144 to 167 12 hours + ((TP-VP - 143) * 30 minutes)

168 to 196 (TP-VP - 166) * 1 day

197 to 255 (TP-VP - 192) * 1 week

189

Additional Features

1

4

5

2

3

6

7

A

I

The presence policy for all attributes of this tag is optional.

Tag Name: smshead

Presence Optional, unique (0..1)

Synopsis <smsheadrp=v1srr=v2mms=v3>

Description The ’smshead’ tag defines the first octet of a TPDU.

Attributes


rp 0,1 Specifies whether the reply path for the ESMS is set (0) or not (1). When the attribute is set to 1, the reply path information will be delivered to the receiving MS as part of the DELIVER-TPDU (TP-Reply-Path parameter)See /GSM 03.40/, §9.2.3.17Defaults to 0

190

Additional Features

1

4

5

2

3

6

7

A

I

srr 0,1 Indicates that a status report for the delivery of this ESMS will be requested from the SME. If the attribute is set to 1, a Status-Report SMS will be returned to the SMS gateway system when the ESMS has been successfully deliv-ered.Defaults to 0

mms 0,1 Indicates that more messages are waiting in the SC. The attribute is set when concatenated ESMS are sent. Note: This option will only be evaluated by the SME in wIQ mode MAPSMS0 (fire-and-forget).See /GSM 03.40/, §9.2.3.2Defaults to 0

Tag Name: dcs


Synopsis <dcsalphabet=v1class=v2>

Description The ’dcs’ (data-coding-scheme) tag defines the alphabet used for hexadecimal encoding of the User-Data section of an ESMS. Additionally, it defines the message class (of particular func-tional interest may be immediate (class 0) which indicates the receiving mobile station shall immediately display the ESMS).

Attributes


191

Additional Features

1

4

5

2

3

6

7

A

I


Attributes


alphabet default,8bit,UCS2

Specifies the alphabet used for encoding the user data part of the ESMS. Notes that depending on the license, only part of the values may be usable.Defaults to ’default’

class immediate, ME, SIM, TE

Specifies the class of the ESMS. immediate indicates the ESMS shall be immediately dis-played by the receiving mobile station (if supported by the mobile station). If the class attribute is not present, it means the case ’message has no message class’.

Tag Name: msginddcs

Presence Optional, unique (0..1).When present, a potentially also present ’dcs’ tag is ignored.

192

Additional Features

1

4

5

2

3

6

7

A

I


Synopsis <msginddcstype=v1action=v2store=v3>

Description The msginddcs (data-coding-scheme message-indicator) tag defines the alphabet used for hexadecimal encoding of the User-Data section of an ESMS.Additionally, it defines the message class (of particular functional interest may be immediate (class 0) which indicates the receiving MS shall immediately display the ESMS).

Attributes


type voice,fax, email, other

Indicates a message of type voice, fax, email or other is waiting for the receiving mobole station on the SME.

action activate, deactivate

Specifies whether the message indicator defined by the msg-wait-type should be acti-vated or deactivated.

store 0, 1 Specifies, whether the receiving mobile sta-tionshall store the message after setting the message indicator or discard it.

Tag Name: msginddcs

193

Additional Features

1

4

5

2

3

6

7

A

I


Tag Name: pid


Synopsis <pidvalue=v1>

Description The pid (protocol-identifier) tag contains a one byte value in decimal form. It determines vari-ous properties of an ESMS such as the ’mes-sage type’. The message type indicates a posi-tion within the SMS store on the SIM card of the receiving MS. The SMSs stored on that po-sition will be replaced (overwritten) by this ESMS.

Attributes


value 0..255 Specifies the protocil identifier (1 byte in decimal representation) of the ESMS.

Tag Name: vp


194

Additional Features

1

4

5

2

3

6

7

A

I

The presence policy for all attributes of this tag is mandatory. If the tag is not present, no validity-period is assumed.

Synopsis <pidvpf=v1value=v2>

Description The ’vp’ (validity-period) tag defines the Valid-ity-Period TPDU parameter. The Validity-Period defines the period within the ESMS is valid. If that time period exceeds, the SME/SMSC shall not deliver the ESMS to the target MS. The ’vpf’ attribute defines the format in which the value field is provided.

Note: The ’vp’ tag will only be evaluated when the ESMS is sent via SMSC (when the wIQ send mode is MAPSMS2). In other send modes the vp tag definition is ignored.

Attributes


vpf rel,enh,abs

Specifies the format of the value attribute.

value string Specifies the Validity-Period of the ESMS, format of the String depends on the setting of the ’vpf’ attribute.

Tag Name: vp

195

Additional Features

1

4

5

2

3

6

7

A

I

6.5.2.1 User Data-specific Tags

Within this section, HTML tags specifying the User Data section of an ESMS are defined, including the Information Elements of the User Data Header and the User Data section itself.

Tag Name: msgindudh

Presence Optional, multiple (0..*)

Synopsis <msgindudhtype=v1count=v2store=v3>

Description The ’msgindudh’ (user-data-header message-indicator) tag defines the message indicators for FAX, VOICE, E-MAIL and OTHER message types. Attributes define the number of mes-sages waiting and whether the content of this ESMS shall be stored or not.

196

Additional Features

1

4

5

2

3

6

7

A

I


Attributes


type Fax,voice,email, other

Specifies the type of the message indicator defined by this msg-indicator tag.

count 0..255 Defines the value of the message indicator counter for the message type specified by the indicator-type attribute. The counter denotes the number of waiting messages of that type. The value 0 denotes the deactiva-tion of that indicator.

store 0, 1 Specifies whether the ESMS shall be stored by the receiving MS (1) or not (0).

Tag Name: udhie

Presence Optional, multiple (0..*)

Synopsis <udhieid=v1value=v2>

Description The udhie (user-data-header information-ele-ment) tag defines a generic User-Data-Header Information-Element. Attributes define the IE-Identifier and the IE-Data.

197

Additional Features

1

4

5

2

3

6

7

A

I


6.5.2.2 ESMS HTML Tag Processing Rules

Within this section, the rules wIQ applies will be explained when parsing the ESMS HTML tags, e.g. what happend when a tag attribute value is faulty or missing.

Tag Attribute/Value Is Missing

If the attribute is mandatory and there is no default for the attribute, the tag is ig-nored. If the tag is mandatory, the request will be rejected.

If the attribute is not mandatory, the tag is processed

Tag Attribute Value Is Invalid

If a tag attribute value is invalid, the request will be rejected. Neither defaults will be applied nor tag will be ignoreds.

Tag Attribute Parsing

Tag attributes that have values out of a choice of strings are always parsed case insensitive, e.g.

<dcs alphabet= "default" class="ME">

is the same as

Attributes


id hexadeci-mal octet

Defines the type of the message indicator defined by this Information-Element tag. The value must be one byte in hexadecimal for-mat (2 characters, .e.g. B6).

value hexadeci-mal string

Defines the IE-Data section of the informa-tion element. The IE-Data section is a 8bit hexadecimal encoded string.

198

Additional Features

1

4

5

2

3

6

7

A

I

<dcs alphabet= "DEFAULT" class="me">

ESMS HTML Page Validity Rules

Besides of the basic tag/attribute validity rules to reject a HTML page ex-plained above, there are other cases in which an HTML page willl not be sent to the requesting subscriber. These are as follows:

If the DCS tag specifies the 8bit alphabet but the content is not provided in hexa-decimal format, the request will be rejected.

If the HTML page contains no content in the body tag and no User Data Header information elements (UDHIE tags) or message indicator User Data Header information elements (MSGINDUDH tags), meaning both the user data and the User Data Header parts of the ESMS will be empty, the request will be rejected. Notice that this means providing a MSGINDDCS tag as sole information in an HTML page will result in the rejection of that HTML page (although it might make a sense). It is recommended to use the msgindudh tag for message indicator manipulation with empty con-tent pages.

Values expected to be in hexadecimal format must have an even length also, otherwise they are rejected. wIQ does not apply padding of trailing 0s to a hex string because this is likely not leading to the hexadecimal value the author intended

6.5.3 wIQPush

The implementation of the extensions to the wIQPush interface regarding the processing of ESMS involves the following implementation issues.

6.5.3.1 HTTP Interface Extension

In this section, the parameter set extensions for the wIQPush Interface are de-fined. Each tag attribute of the Enhanced SMS additions will be mirrored by

You need an extra license for the Push interface!

199

Additional Features

1

4

5

2

3

6

7

A

I

its own HTTP parameter. The following table lists all new wIQPush HTTP GET/POST parameters. (In the table, Param stands for Parameter, Pre denotes the presence (O= Optional, M= Manadatory) of the parameter)

The Protocol Extension will accept all HTTP GET/POST parameters described above.

Param Pre Values Description

data M ’sms-enh’ Indicates that the Enhanced SMS Features of wIQ and the Push Pro-tocol Version 1.01 will be used.

wIQPush HTTP GET/POST Parameters for ESMS Support (Push Protocol V1.01)


srr O 0, 1 For the description, see page 191.

rp O 0, 1 For the description, see page 190.

mms O 0, 1 For the description, see page 191.

dcs O int For the description, see page 191.

pid 0 int For the description, see page 194.

vpf O rel,enh,abs

For the description, see page 195.

vp O char * For the description, see page 194.

udhi O 0, 1 For the description, see page 197.

200

Additional Features

1

4

5

2

3

6

7

A

I

URL encoding has to be used for all special characters in the value field, e.g. space, hash, ...

6.5.4 Examples

Within this chapter, examples for the translation of an ESMS input from a HTML page are provided. This translation takes place in the wIQ core.

6.5.4.1 Example of a Ringtone ESMS

In the following , a description of a Ringtone ESMS for Nokia 33xx handsets is given. The example was derived from the following original TPDU:

Example:

0791947122723033440C9194719215142100F5205022211315806A06050415810000024A3A7531A59DA1D081B5E48199A5C99404008F1ECAE938C498824D412718A26C511624E312698930C49A624B4126A0A22C5166289C144609370498824CB12618930C499624C4126A0938C512624E4126A09310496824AB12598934049A40009B9B9A

ud M char * The User-Data section of the mes-sage.

udh O Char * The User Data Header, mandatory if ’udhi’ is set to 1. If ’udhi’ is set to 0, ’udh’ attribute must not be present.

Note that binary and text ESMS examples need a suitable ESMS li-cense!

wIQPush HTTP GET/POST Parameters for ESMS Support (Push Protocol V1.01)


201

Additional Features

1

4

5

2

3

6

7

A

I

Translation into wIQ HTML:

<html>

<head><sms_head>

<dcs

alphabet="8bit"

>

<pid

type="0"

>

<udh_ie id="05" value="15810000"></head>

<body>024A3A7531A59DA1D081B5E48199A5C99404008F1ECAE938C498824D412718A26C511624E312698930C49A624B4126A0A22C5166289C144609370498824CB12618930C499624C4126A0938C512624E4126A09310496824AB12598934049A40009B9B9A

</body>

</html>

202

Additional Features

1

4

5

2

3

6

7

A

I

6.5.4.2 Example of a Text ESMS

The following wIQ HTML documents describes a text ESMS with the following properties:

A delivery status report is requested

Reply path is set

The default alphabet is used

Message class 0 (Immediate display) is specified (example 1)

Validity period is set to 25.05.01 12:30:00 00 , GMT+00 time zone

No User Data Header is present

Example:

<html><head>

<sms_head

srr="1"

rp="1"

>

<dcs

alphabet="default"

class="immediate"

>

<vp

format="abs"

value="02250512300000"

>

<pid

value="64"

>

</head>

203

Additional Features

1

4

5

2

3

6

7

A

I

<body>

This is a text ESMS

</body>

</html>

6.5.4.3 Example of a Binary SMS

The following wIQ HTML statement describes an binary ESMS with the follow-ing properties:

No delivery status report is requested

Reply path is not set

The 8bit alphabet is used

Message class 0 (Immediate Display) is specified

Validity period is set to 10.07.02 15:10:00 00 , GMT+00 time zone

No User Data Header is present

<html><head>

<smshead><dcs alphabet="8bit" msgclass="immediate"><vp format="abs" value="02100715100000"><pid value="0"></head>

204

Additional Features

1

4

5

2

3

6

7

A

I

<body>50D1E939283D078541C2B43B2CCF838A6E74D</body></html>

The user data string decoded is ’This is a Binary ESMS’ (8bit hexadecimal en-coding).

6.5.4.4 Example of a Picture SMS

The following wIQ HTML page describes a picture ESMS for Nokia 33xx hand-sets.

<html>

<head><sms_head rp="0" srr="0"><dcs alphabet="8bit" class="ME"><pid value="0"><udh_ie id="05" value="158A0000"></head>

<body>

205

Additional Features

1

4

5

2

3

6

7

A

I

300000045465737402010000481C01FED6A2444200AAB6FFD7BB0032101E455B5BFAD49C81453F1061EDFF5B3E00103F00007FB7D53E18021F87041BEAB53E1C880F9F820F7FAA3E1C2003FFC123EADD3C1C0003FEE095BD601C3C11C7F87097EBA1FFF801FFFC3895FEC3FFF881FEFE3817D547FFE0003C7F0025FDCF3E0000003F8047B00E3E1C2000FFC40DD80C3F7E0003FFC2BFF20C1FFE010FF7CDD7AA401FE7000F8F8CB5F2408F83B00E1F06DFDA200783F0073C1B75F11C63C1F00738255FD08021E0C003BCB5ABF86100F800039C16FEAC0000F000078E0357FD4001E0000F0E00DBEF800FC0000E0700EFBAC01F0000000F017DDFD00E0000001E02D7ED59070000001C5B7F</body></html>

This picture SMS is too long to be sent as one. It will be split into partial (con-catenated SMSs) when sent to the SMSC. There will be 3 resulting partial SMSs received by the Mobile. These are the following TPDUs:

Partial SMS TPDU No.1

0791947122723033400C9194719215142100F5205022213375808C0B0504158A00000003030301300000045465737402010000481C01FED6A2444200AAB6FFD7BB0032101E455B5BFAD49C81453F1061EDFF5B3E00103F00007FB7D53E18021F87041BEAB53E1C880F9F820F7FAA3E1C2003FFC123EADD3C1C0003FEE095BD601C3C11C7F87097EBA1FFF801FFFC3895FEC3FFF881FEFE3817D547FFE0003C7F0025FDCF3E0000


0791947122723033400C9194719215142100F5205022214310808C0B0504158A00000003030302003F8047B00E3E1C2000FFC40DD80C3F7E0003FFC2BFF20C1FFE010FF7CDD7AA401FE7000F8F8CB5F2408F83B00E1F06DFDA200783F0073C1B75F11C63C1F00738255FD08021E0C003BCB5ABF86100F800039C16FEAC0000F000078E0357FD4001E0000F0E00DBEF800FC0000E0700EFBAC01F0000000F017DDFD00E0000001E


206

Additional Features

1

4

5

2

3

6

7

A

I

0791947122723033440C9194719215142100F520502221433080170B0504158A0000000303030302D7ED59070000001C5B7F

6.6 ORGA NSG Driver

The NSG driver is used for communication between wIQ/router and the NSG which does the SS7 connection.

The NSG driver is used for USSD traffic (MO and MT) as well as for Direct SMS.

The Direct SMS feature is used to send SMS messages directly to the subscrib-er via the SS7 network bypassing existing SMSCs.

An SMS is sent directly to the SS7 network only when configured accordingly in wIQ and router (see page 95)!

The NSG driver process is named tedriver.

6.6.1 Signals

The tedriver process handles the following UNIX signals:

The usage of Direct SMS only works with global title translation capability of the connected SCP, as an SMS is addressed to sub-system MSISDN+SSN6.

tedriver Signal Handling

Switch Description

SIGUSR1 Toggle debugging on/off

SIGUSR2 Configuration reload

SIGPIPE Ignore signal

SIGINT, SIGTERM Close all sessions, then terminate process

207

Additional Features

1

4

5

2

3

6

7

A

I

6.6.2 Command Line Options

The driver supports the following command line switches

>tedriver [-D][-C Classlist][-V DebugLevel][-c ConfigFile]

6.6.3 Driver Configuration

The driver uses the configuration file $ORGADATA/cnf/tedriver.cfg by default.

The format of one line of this file is

tedriver.<variablename>=<value><NEWLINE>

The lines are separated by a new line. A starting # marks the line as a com-ment.

tedriver Command Line Switches

Switch Values Description

-D toggle debugging on/off

-V<debuglevel> Debuglevel={1..9} Set the level of debug. 1 means only basic debug information. 9 is all debug infor-mation.Only have effect if debugging is enabled.

-c <configfile> configfile = File name of the configuration file to be used.

Use configuration file instead of $ORGADATA/cnf/tedriver.cfg

208

Additional Features

1

4

5

2

3

6

7

A

I

Consult the manual pages (enter man tedriver.cfg on the wIQ host) for possible configurable variables.

If no default value is defined, the definition of the variable is mandatory in the file. Otherwise it is an optional variable. (BCD = a string of digits)

Example configuration:

#

# Sample file for the configuration of the driver-- tedriver

#

tedriver.localSSN=8

tedriver.localGT=1234567890

tedriver.UserID=40

tedriver.DlgIdMin=1

tedriver.DlgIdMax=10000

tedriver.wIQHost=localhost

tedriver.wIQPort=5348

tedriver.wIQGuardtime=3600

tedriver.AliveFilePeriod=30

tedriver.FailureMessage=Temporary out of service

tedriver.EmptyReplaceMessage=Empty message

tedriver.SessionTimeout=35

209

Additional Features

1

4

5

2

3

6

7

A

I

210

SNMP 7

1

4

5

6

3

7

A

2

I

This manual describes the integration of SNMP (trap) support into wIQ.

wIQ makes use of SNMP (Simple Network Management Protocol) in order to integrate the system into a NMS (Network Management System) at a customer site.

The SNMP Alarm Subsystem implemented for wIQ is meant to deliver alarm messages, clear alarm messages, and heartbeat message to a NMS.

wIQ will use SNMP traps. SNMP traps are spontaneous messages sent by an SNMP agent to the NMS. These messages contain information about the status and health of the (wIQ) system, e.g. they tell the NMS if connections have been lost or reestablished, if the Subscriber database is available, in what kind of mode (local/remote) the wIQ system currently operates, etc., and how critical the current status of the system is (severity).

The SNMP Alarm System traps have to include certain fields which are defined in the MIB (Management Information Base) data structure, and are transported in UDP packets.

The system will only be able to generate/send SNMP alarm traps which are used to send status/alarm messages to the Network Management Console of the operator. The use of SNMP get-request, get-next-request, get-response, and set-request PDUs (Protocol Data Units) which are used to query or set specific data will not be supported by this implementation.

211

SNMP

1

4

5

6

3

7

A

2

I

The SNMP data which is sent out by this implementation can only be used to monitor the wIQ system and its components. It can not be used as a tool to supervise the operating system, e.g. memory or disk usage, CPU load, etc. That kind of data needs to be monitored using a vendor/OS-specific SNMP daemon which is completely separate from wIQ.

7.1 SNMP Trap Configuration

7.1.1 OLS TRAP

The definition of traps is done with the help of the ORGA logging system (OLS). For every process, there is a file defining the logging and trap messages.

The ’TRAP’ processing action statement has the following syntax:

TRAP <severity> <alarmtype> <clearmsgid>

The fields are separated by white space and explained in the following table:

OLS TRAP


TRAP c[...] Keyword to indicate processing action SNMP alarm trap.

212

SNMP

1

4

5

6

3

7

A

2

I

7.1.2 Configuration of the SNMP Agent

The SNMP agent process is responsible for sending out all traps to the NMS..The following configuration parameters are defined in$ORGADATA/cnf/stsc_snmp.cfg:

<severity> n[1] ASCII digit denoting severity:'0' - indeterminate, '1' - critical, '2' - major, '3' - minor,'4' - warning,'5' - clear, '6' - informational.

<alarmtype> c[20] ASCII string identifying the basic type of alarm; suggested keywords (from ISO/IEC DIS 10164-4) are ’COMMUNICATION’, ’ENVIRON-MENTAL’, ’EQUIPMENT’, ’PROCESS-ING’, ’QUALITYOFSERVICE’


ORGA.SNMPAlarm-Address

c[...] IP address and UDP port of the SNMP Alarm System receiving the SNMP alarm traps (n.n.n.n:port or host-name:port).

ORGA.SNMPCommu-nity

c[...] SNMP Community string, default ’public’.

OLS TRAP


213

SNMP

1

4

5

6

3

7

A

2

I

If the process is started with the -DCM switch, the old configuration file mechanism ($ORGADATA/Config) is also supported.

The SNMP Alarm Process transforms each event record into the payload of SNMP trap PDUs and notifies the external Alarm Management System via a TCP/IP connection asynchronously.

Each newly received event record signals one of the defined events:

Alarm set

Alarm clear

Heartbeat

The trap payload is constructed from a MIB-defined variable set.

The following data is contained in a SNMP alarm trap:

ORGA.SNMPVersion n[1] SNMP trap format to be used: 1 = SNMPv1, 2 = SNMPv2, default 1

ORGA.SnmpPipe c[...] Name of the SNMP pipe. If the name starts with a ’/’, an absolute path is assumed otherwise a relative path under $ORGADATA is used. Default .snmppipe in $ORGADATA


214

SNMP

1

4

5

6

3

7

A

2

I

MIB Variable Type Description

caSeverity n[1] Integer denoting severity:'0' - indeterminate,'1' - critical, '2' - major,'3' - minor,'4' - warning, '5' - clear,'6' - informational.

caEventType n[1] Integer identifying the basic type of alarm; suggested keywords (from ISO/IEC DIS 10164-4) are:UNKNOWN=0, COMMUNICATION=1, ENVIRONMENTAL=2, EQUIPMENT=3, PROCESSING=4,QUALITY OF SERVICE=5.

caOriginatingEquipment c[100] Calling program name.

caEventDate d[15] YYYYMMDDhhmmss time stamp of the alarm mes-sage.

caAdditionalData c[64] ASCII string with the dynamic part of the clear alarm message.

caEventNumber n[4] Integer event number.

caEventText c[64] ASCII string with the mes-sage text.

215

SNMP

1

4

5

6

3

7

A

2

I

The <caNotificationID> is a number that uniquely identifies an instance of a given event condition. The notification ID can be used to correlate a set and clear event so that the external Alarm Management System may mark the event as disappeared. When <caNotificationID> achieves the maximum value (0x7FFFFFFF), the variable will wrap back to value 1 when sending the next new alarm set trap.

The <caTrapID> is incremented by one in each trap sent. The Alarm Management System may use this variable to detect if traps are lost. When <caTrapID> achieves the maximum value (0x7FFFFFFF), the variable will wrap back to value 1 when sending the next trap.

The severity variable listed above is set to 'clear' in case the trap represents an alarm clear event.

In case of an heartbeat event generated trap the <caEventText> variable must contain the string ’Heartbeat'.

The following object identifiers are defined in the corresponding MIB:

enterprises OBJECT IDENTIFIER ::= {1.3.6.1.4.1}

company_ORGA OBJECT IDENTIFIER ::= {enterprises 3688}

companyProducts OBJECT IDENTIFIER ::= {company_ORGA 1}

product_OLS OBJECT IDENTIFIER ::= {companyProducts 1}

caNotificationID n Integer number uniquely identifying instance of fault giving rise to the event.

caTrapID n Unsigned integer number which is incremented by one for each trap sent.

MIB Variable Type Description

216

SNMP

1

4

5

6

3

7

A

2

I

alarmTraps OBJECT IDENTIFIER ::= {product_OLS 1}

ca OBJECT IDENTIFIER ::= {alarmtraps 2}

caVars OBJECT IDENTIFIER ::= {ca 1}

MIB Variable Object Identifier

caSeverity 1.3.6.1.4.1.3688.1.1.1.2.1

caEventType 1.3.6.1.4.1.3688.1.1.1.2.2

caOriginatingEquipment 1.3.6.1.4.1.3688.1.1.1.2.3

caEventDate 1.3.6.1.4.1.3688.1.1.1.2.4

caAdditionalData 1.3.6.1.4.1.3688.1.1.1.2.5

caEventNumber 1.3.6.1.4.1.3688.1.1.1.2.6

caEventText 1.3.6.1.4.1.3688.1.1.1.2.7

caNotificationID 1.3.6.1.4.1.3688.1.1.1.2.8

caTrapID 1.3.6.1.4.1.3688.1.1.1.2.9

217

SNMP

1

4

5

6

3

7

A

2

I

7.2 SNMP Support in wIQ Processes

7.2.1 wIQd / wIQguard

To enable SNMP support, you have to set the configuration parameter (see page 51) wIQd.Alarming to ’2’. Then an additional SNMP agent process is started and stopped by wIQd. wIQguard will generate a trap for

every monitored process that is stopped. Whenever this process is coming up again, the trap is cleared. A monitored process is either the database, the Web server or a process on the wIQguard process table.

a wIQguard stop. This is cleared by a start of the wIQguard (with no regards if it comes up in local or remote mode).

a wIQguard that is coming up in remote mode. If this trap is set, you now that there is a wIQguard instance monitoring the local mode wIQguard running elsewhere. This is cleared upon stop or switching to local mode

heartbeats. These heartbeats are generated by a wIQguard running in local mode that includes the script watch_snmp on its process table. Please note: A remote mode wIQguard does NOT send heartbeats!

So if a system is running in operational state, you will see a trap for a system running in remote mode, and you will receive heartbeats from the other system running in local mode.

If you have SNMP support enabled, the file SnmpRestart should be part of the exclude file.

218

SNMP

1

4

5

6

3

7

A

2

I

The following traps are generated: :

Event-ID OLS-Name Description

0000 HEARTBEAT Heartbeat message (not cleared), dynamic part is empty

6001 WIQGUARD.PROCESSUP wIQguard has started a process (e.g. wIQ_a) -> clears 6002, dynamic part contains process name

6002 WIQGUARD.PROCESSDOWN wIQguard recognized process stop -> raise, dynamic part contains process name

6003 WIQGUARD.UP wIQguard is coming up (no matter if local or remote mode) -> clears 6004, dynamic part con-tains host name

6004 WIQGUARD.DOWN wIQguard is terminated (no matter if local or remote mode) -> raise, dynamic part contains host name

6005 WIQGUARD.REMOTEUP wIQguard is started in remote mode ->raise, dynamic part contains host name

6006 WIQGUARD.REMOTEDOWN wIQguard remote mode is quit -> clears 6005, dynamic part contains host name

219

SNMP

1

4

5

6

3

7

A

2

I

Example traps generated from this:

Also a timestamp is included in every trap (EventTime) which is not included in this table.

Even

t-ID

Spec

ific

*

* The ORGA MIB defines CancelEvent for all clear messages and AlarmEvent for all alarm raise.

Seve

rity

Even

tTyp

e

Ori

gin

atin

g-

Equ

ipm

ent

Ad

dit

ion

alD

ata

(Dyn

amic

m

es-s

age

par

t)

Even

tTex

t (M

es-s

age)

6003 Cancel-Event

5 COMMUNI-CATION

wIQguard wIQguard.od-scp-1

STARTED: wIQ-guard on host od-scp-1

6004 Alarm-Event

1 COMMUNI-CATION


STOPPED: wIQguard on host od-scp-1

6001 Cancel-Event

5 COMMUNI-CATION

wIQguard wIQ_a STARTED: wIQ_a

6002 Alarm-Event

2 COMMUNI-CATION

wIQguard wIQ_a STOPPED: wIQ_a

6005 Alarm-Event

6 COMMUNI-CATION


STARTED: wIQguard in remote guard mode on host od-scp-2

6006 Cancel-Event

5 COMMUNI-CATION


STOPPED: wIQguard in remote guard mode on host od-scp-2

0000 Alarm-Event

6 COMMUNI-CATION

wIQguard Heartbeat

220

SNMP

1

4

5

6

3

7

A

2

I

7.2.2 wIQ

The wIQ process itself will be SNMP enabled by using OLS. There will be SNMP traps whenever the wIQ waits for or gets a connection on its TCP/IP ports. This means when wIQ starts up, it will raise an alarm that it waits for a connection and clear this as soon as a connection will be established. When wIQ shuts down, all raised alarms will be cleared.

The following traps are generated via OLS:

The dynamic part will always contain host:port of the wIQ handling the trap.


6196 MAIN.INFO.WAITING Waiting for new connec-tion of a client -> raise

6253 USSD.I.SOCKETCLOSED Socket connection was closed -> raise

6255 USSD.I.NEWCONNECTION A new connection has been established or wIQ is termi-nating -> Clears all above

221

SNMP

1

4

5

6

3

7

A

2

I

Example traps generated from this:

Optional license limit trap (this is disabled by default):

The dynamic part will contain the process name of the wIQ handling the trap.

Even

t-ID

Spec

ific

*


Seve

rity

Even

tTyp

e

Ori

gin

atin

g-

Equ

ipm

ent

Ad

dit

ion

alD

ata

(Dyn

amic

m

es-s

age

par

t)

Even

tTex

t (M

es-s

age)

6196 Alarm-Event

2 COMMUNI-CATION

wIQ_a localhost:3364 Main thread now waiting

6255 CancelEv-ent

5 COMMUNI-CATION

wIQ_a localhost:3364 Got new connection or process terminat-ing

6253 Alarm-Event

2 COMMUNI-CATION

wIQ_a localhost:3364 Client has closed the socket connection


6524 SC_STREAM.I.LICENSELIMIT License limit reached -> raise

Please note that this trap will never be clearedif enabled!

222

SNMP

1

4

5

6

3

7

A

2

I

7.2.3 Router

The router will be SNMP-enabled by using OLS.There will be SNMP traps whenever the router waits for or gets a connection on its ports. This means when the router starts up, it will raise an alarm that it waits for a connection for every driver and wIQ configured to connect to the router, and clear this as soon as a connection will be established to this specific driver or wIQ. When the router shuts down, all raised alarms will be cleared.

The following traps are generated via OLS for driver connections:

The dynamic part will always contain the driver name the trap is related to, so this traps can be raised and cleared separately for all drivers.

The following traps are generated via OLS for wIQ connections:


6900 CONFIG.I.LISTENING The router is listening on a socket for a driver to con-nect -> raise

6917 CONN.I.CONNECTED The router is connected to a driver, or the router is shut-ting down -> Clears above trap


6921 CONN.I.NOTCONNECTEDWIQ The router is not con-nected to a wIQ -> raise

6920 CONN.I.CONNECTEDWIQ The router is connected to a wIQ, or the router is shutting down -> Clears above trap

223

SNMP

1

4

5

6

3

7

A

2

I

The dynamic part will always contain the wIQ name the trap is related to, so this traps can be raised and cleared separately for all wIQ's.

Example traps generated from this: Ev

ent-

ID

Spec

ific

*


Seve

rity

Even

tTyp

e

Ori

gin

atin

g-

Equ

ipm

ent

Ad

dit

ion

alD

ata

(Dyn

amic

m

es-s

age

par

t)

Even

tTex

t (M

es-s

age)

6921 Alarm-Event

2 COMMUNI-CATION

router WIQ1 Waiting for wIQ [WIQ1] to con-nect on local-host:3364

6920 CancelEv-ent

5 COMMUNI-CATION

router WIQ1 wIQ [WIQ1] con-nected on local-host:3364 or router terminat-ing

6900 Alarm-Event

2 COMMUNI-CATION

router SMSC1 Listening for driver [SMSC1] to connect on local-host:6825

6917 CancelEv-ent

5 COMMUNI-CATION

router SMSC1 Driver [SMSC1] connected on port 6825 or router terminat-ing

224

Appendix A

1

4

5

6

2

3

A

7

I

A.1 Supported Characters from the GSM-Default Alpha-bet

Bits per character: 7

SMS User Data Length meaning: Number of characters

CBS/USSD pad character: CR

@ D SP 0 ¡ P ¿ p

£ _ ! 1 A Q a q

$ " 2 B R b r

¥ # 3 C S c s

è ¤ 4 D T d t

é % 5 E U e u

ù & 6 F V f v

ì ’ 7 G W g w

ò ( 8 H X h x

225

Appendix

1

4

5

6

2

3

A

7

I

For the GSM alphabet see GSM 03.38 version 7.2.0 Release 1998.

A.2 Mapping from HTML 3.2 to USSD/SMS

Ç ) 9 I Y i y

LF * : J Z j z

Ø + ; K Ä k ä

ø Æ , < L Ö l ö

CR æ - = M Ñ m ñ

Å ß . > N Ü n ü

å É / ? O § o à

Mapped ASCII characters (displayed as ’?’)

Character HTML name Display

[ ?

\ ?

] ?

^ ?

’ ?

{ ?

| ?

} ?

~ ?

226

Appendix

1

4

5

6

2

3

A

7

I

¢ ¢ ?

¦ ¦ ?

¨ ¨ ?

© © ?

a ª ?

« « ?

¬ ¬ ?

?

® ® ?

¯ ¯ ?

° ° ?

± ± ?

² ² ?

³ ³ ?

´ ´ ?

µ µ ?

¶ ¶ ?

· · ?

¸ ¸ ?

¹ ¹ ?



227

Appendix

1

4

5

6

2

3

A

7

I

The characters in the following table are converted into characters with a sim-ilar appearance because they are not defined in the GSM-alphabet.

°- º ?

» &raquo ?

¼ ¼ ?

½ ½ ?

¾ ¾ ?

Ð Ð ?

× × ?

Þ Þ ?

÷ ÷ ?

Character HTML nameSimilar

character

À À A

Á &Aacute A

Â &Acirc A

Ã Ã A

È È E

Ê Ê E



228

Appendix

1

4

5

6

2

3

A

7

I

Ë Ë E

Ì Ì I

Í Í I

Î Î I

Ï Ï I

Ò Ò O

Ó Ó O

Ô Ô O

Õ Õ O

Ù Ù U

Ú Ú U

Û Û U

Ý &Yacute Y

á á a

â â

ã ã a

ç ç c

ê ê e

ë ë e

í í i

î î i

229

Appendix

1

4

5

6

2

3

A

7

I

A.3 Changes

A.3.1 New Features for wIQ 1.0

1. Subscriber

Subscribers can get a mobile phone-specific configuration data.

Depending on the operator strategy, the subscriber will benefit from a subscriber-specific service number list

2. Operator

The operator is able to set up the configuration:

a) Dialog to select a handset-specific character mapping used for input during wIQ dialog input only

b) Automatic call of the MS configuration dialog

c) Call by service number of the MS configuration dialog

In addition, an individual subscriber profile key can be configured. This profile type will identify the service number - URL mapping table which will be used for this subscriber.

Various subscriber-specific profile data will provide smart overall informa-tion.

ï ï i

ó ó o

ô ô o

õ õ o

ú ú u

û û u

ý ý y

230

Appendix

1

4

5

6

2

3

A

7

I

3. Configuration Data

Character sets for different handsets.

Now two sets of files which contain ’USSD to URL Mapping’ and ’Valid URL’ tables for up to 62 different groups

Main configuration file of the wIQ is extended by some entries to config-ure these new features.


limit of maximum allowed inputs increased to 20

All database fields could be passed to the URL

Characters which are unknown in the GSM alphabet may be mapped to similar looking characters

New error message is sent to the subscriber

Optimized performance

Increase support of incoming GSM characters

Allow reconfiguration during runtime

Termination forces an "abort" of all open sessions

Form input is sent URL-form-encoded

Configuration of multi-level service number

Billing

https support


SMS support


Push interface

Support of hidden input fields

Extended wIQ HTML tags for session settings from an HTML page

231

Appendix

1

4

5

6

2

3

A

7

I

Splitted main configuration file

SMS client

SMPP

Router


ESMS support

IMEI support


Support of SMPP

Support of EMI UCP

New ORGA NSG


SNMP support

LDAP support

Arabic language support


Multiple language support

A.4 HTML Pages for Keytable Configuration

<HTML>

<HEAD><TITLE>ORGA Net</TITLE></HEAD>

<BODY>

Mobile selection<BR>

<FORM method="get"

232

Appendix

1

4

5

6

2

3

A

7

I

action="http://wIQ.orga.com/cgi-bin/keymap1.pl">

1 NOKIA<br>

2 ERICSSON<br>

3 OTHER<br>

<input type="text" name="type">

</FORM>

</BODY>

</HTML>

If the subscriber selects OTHER, a second dialog might follow:

<HTML>

<HTML>

<HEAD><TITLE>ORGA Net</TITLE></HEAD>

<BODY>

Keytable config<BR>

<FORM method="get"

action="http://wIQ.orga.com/cgi-bin/keymap2.pl">

Please press the key 2 once!

<input type="text" name="key">

</FORM>

</BODY>

</HTML>

233

Appendix

1

4

5

6

2

3

A

7

I

A.5 Use of the wIQ Web Interface

To register, you have to access the following entry page through an internet browser with

http://<name of the wIQ Server>:<port>/index.php

Example:

http://wiq21:8080/index.php

Start screen

234

Appendix

1

4

5

6

2

3

A

7

I

You can select one of the links wIQ Administration Interface, Read-Only Subscriber Database Interface, and PHP Information.

A.5.1 wIQ Administration Interface

The wIQ Administration Interface area can be protected by user name and password if this is included in the installation of your system.

When you have selected the wIQ Administration Interface link, you can se-lect one of the following links:

Limited Subscriber Database Interface

Complete Subscriber Database Interface

Incore Interface

Incore Manual Page

A.5.1.1 Limited Subscriber Database Interface

Using this interface, you can create a new subscriber or search for a subscriber in the Subscriber database. The subcriber’s data can be edited, but only a sub-set of the subscriber’s attributes can be changed.

After clicking this link, you are first asked to enter the subscriber’s MSISDN. If he does not yet exist in the database, a new database entry will be created.

If you click the SUBMIT button, the result of your query is displayed. It is spec-ified which entries may be edited.

A.5.1.2 Complete Subscriber Database Interface

Using this interface, you can create a new subscriber or search for a subscriber in the Subscriber database. All the subcriber’s data can be edited.

If you click the SUBMIT button, the result of your query is displayed.

A.5.1.3 Incore Interface

Using this interface, you can adminster the InCore (Subscriber Data) database.

235

Appendix

1

4

5

6

2

3

A

7

I

It allows you to execute any database command so you have to be careful with the commands you enter and you have to be familiar with the Incore da-tabase command line syntax.

If you click the SUBMIT button, the result of your query is displayed.

A.5.1.4 Incore Manual Page

This is the Incore database help page in the style of the PHP HTML manual.

A.5.2 Read-Only Subscriber Database Interface

The Read-Only Subscriber Database Interface area can be protected by user name and password if this is included in the installation of your system.

Using this link in the wIQ Administration Interface, you can query the Sub-scriber Database, but you are not allowed to change any data.

A.5.3 PHP Information

Using this link in the wIQ Administration Interface, you are informed about the PHP version currently installed on this system.

A.6 System Activity Reporter

To maintain system resources and performance, the system activity reporter should be activated. This activation is done with the start-up script in /ect/rc2.d/S21perf.

Example:

# Copyright (c) 1997 by Sun Microsystems, Inc.

# All rights reserved.

#

#ident "@(#)perf.sh 1.7 97/12/08 SMI"

# Uncomment the following lines to enable system activity data gath-ering.

236

Appendix

1

4

5

6

2

3

A

7

I

# You will also need to uncomment the sa entries in the system crontab

# /var/spool/cron/crontabs/sys. Refer to the sar(1) and sadc(1m) man pages for more information.

if [ -z "$_INIT_RUN_LEVEL" ]; then

set -- `/usr/bin/who -r`

_INIT_RUN_LEVEL="$7"

_INIT_RUN_NPREV="$8"

_INIT_PREV_LEVEL="$9"

fi

if [ $_INIT_RUN_LEVEL -ge 2 -a $_INIT_RUN_LEVEL -le 4 -a \

$_INIT_RUN_NPREV -eq 0 -a $ $_INIT_PREV_LEVEL = -o \

$_INIT_PREV_LEVEL = S $ ]; then

/usr/bin/su sys -c "/usr/lib/sa/sadc /var/adm/sa/sa`date +%d`"

fi

An additional crontab -e sys is necessary as well:

#crontab -e sys

0 * * * 0-6 /usr/lib/sa/sa1

20,40 8-17 * * 1-5 /usr/lib/sa/sa1

5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A

A.7 Backup and Restore of the Sun Solaris Operating System

In case of a system failure you need to restore the Sun Solaris Operating Sys-tem from a backup, usually stored on tape. However, when you have to re-place a hard drive by a new one, a full restore of the system requires more

237

Appendix

1

4

5

6

2

3

A

7

I

than "just" the data residing on the root (/) partition, meaning especially the partitioning information (VTOC - Virtual Table of Contents) of the system’s hard drive and its World Wide Number (WWN).

The main focus of this chapter is the backup and restore of the Sun Solaris OS using standard tools like ufsdump and ufsrestore in general without taking RAID configuration into consideration. The configuration, backup, and re-store of RAID devices is covered in section A.7.11 including a step-by-step de-scription of how to restore your system and your RAID (mirror) configuration.

If you just want to restore your system from a backup tape you might as well skip the following detailed introductions and use them just for reference pur-poses. The step-by-step description is basically all you need to know when it comes to restoring a system "from scratch".

These symbols are used in the following sections:

% indicates a shell prompt (when the system is booted up properly)

ok indicates the Boot PROM mini shell environment

rsc> indicates the Remote System Control (RSC) mode

A.7.1 Introduction to Backup and Restore

To backup a file system it has to be inactive, meaning that it either has to be unmounted, or the system has to be in single-user mode so that no writings to the file system will occur. The most important consequence of this fact is that the system will not be able to perform normal operations, e.g. running services, while a backup is being performed.

Therefore, it is recommended to perform a backup of the system’s root (/) par-tition and other important data before it goes into production. However, keep in mind that this backup will only enable you to restore the sys-tem’s state as it was upon ’delivery’.All changes that have been made to the system’s configuration after it has been put into production will be lost.

For all the following backup and restore tasks you have to have super-user privileges, meaning that you have to be logged in as user ’root’. Some of the tasks below also require the system to be booted in single-user mode, interrupting normal system operation.

238

Appendix

1

4

5

6

2

3

A

7

I

A.7.2 Installing and Using a Tape Drive

A.7.2.1 Installing a Sun StorEdge Tape Drive

Backups are usually stored on tape using tape drives such as the Sun StorEdge system. This section briefly describes how to install and use a Sun StorEdge DDS-4 tape drive connected to the SCSI controller. For a more detailed de-scription see the manual of your tape drive.

To connect a tape drive to your server it has to be shut down and power to both the server and the tape drive has to be switched off. To shut down the server properly, issue something similar to the following command (as root):

% shutdown -i0 -g0 -y

After the system is properly shut down you will automatically enter the Boot PROM "shell", indicated by an ok prompt. Within the Boot PROM, issue the following command sequence:

ok setenv auto-boot? false

ok reset (the system will reset itself)

ok probe-scsi (entered after the system has been restartedreset)

The probe-scsi command will provide details about other SCSI components and target Ids used within the system, making it possible to select a SCSI ID for the tape drive to be connected that is not in use. After writing down the used SCSI Ids and configuring the tape drive’s SCSI ID, power off the system to connect the tape drive:

ok power-off

When the server is powered off, you can connect the tape drive to the exter-nal SCSI port. Make sure that its SCSI device ID is properly configured and not used by another system component.

After connecting the tape drive to the SCSI bus, first power on the tape drive and then the server. Upon entering the Boot PROM of the server issue the fol-lowing commands:

ok setenv auto-boot? true

239

Appendix

1

4

5

6

2

3

A

7

I

ok boot -r

The boot -r command is important. This way the system enters a reconfigura-tion mode to scan for new devices, the tape drive in this case. Once the sys-tem is booted, the tape drive should be ready to be used. Check this by using the following command:

% mt -f /dev/rmt/0 status

This should result in a message saying that a Sun StorEdge DDS-4 tape drive is correctly recognized:

DAT tape drive...

The specific Sense Key returned is usually not an issue. Make sure that no oth-er error messages are reported. The command above assumes that the new tape drive is the only one known to the system.

A.7.2.2 Using a Tape Drive

In Solaris, tape drives are recognized and used by logical device names starting with

/dev/rmt/

followed by a logical tape number and possibly additional parameters. A log-ical tape drive name could be one of the following:

/dev/rmt/0(referring to drive number "0" with no additional parameters)

/dev/rmt/0n (referring to drive number "0" with the no rewind option)

Additional parameters are used to indicated the tape density:

– l (low),

– m (medium),

– h (high),

– c (compressed),

– u (ultra compressed).

240

Appendix

1

4

5

6

2

3

A

7

I

The n option (no rewind) indicates that the tape shall not rewind after some data has been written onto it. This is especially important if you want to store several different backups (e.g. different file systems) on one tape. If you do not specify this option, a subsequent ufsdump command will simply overwrite another backup you have just made.

As indicated above, you use the ufsdump and ufsrestore commands to create dumps (backups) of files or file systems.

A.7.3 Using ufsdump and ufsrestore

The Sun Solaris tools used for backup and restore of files and file systems are ufsdump and ufsrestore. This section provides a short introduction to both of these commands. For additional information and usage please refer to the manual pages of both commands.

A.7.3.1 Introduction to the ufsdump Command

The command ufsdump is used to create backups of files or complete file sys-tems, preferably on tape drives. It can be found in /usr/sbin/. You can specify backup levels as well as other parameters in the command line. Please refer to the manual page of ufsdump for a full list of options. The usual call of ufsdump looks like this:

% ufsdump 0uf /dev/rmt/0 /dev/rdsk/c0t0d0s5

This creates a level 0 dump (backup) of the UFS file system residing on slice 5, and also updates the list of updates that have been performed, stored in /etc/dumpdates.

A.7.3.2 Introduction to the ufsrestore Command

The command ufsrestore is used to restore files or file systems from a previ-ously made backup tape. A typical call of ufsrestore looks like this:

% cd /dir/to/be/restored

241

Appendix

1

4

5

6

2

3

A

7

I

% ufsrestore rvf /dev/rmt/0

A.7.3.3 Backing up Several File Systems on a Single Tape

If you do not want to store each file system on a separate tape, e.g. to reduce the number of tapes required for a complete system backup, you have to specify the no-rewind option (n) along with the logical name of the tape drive. Here are some essential steps necessary to back up more than one file system on a single tape:

Insert the tape into the tape drive

Rewind the tape to get it into the "starting position" using the mt command:% mt -f /dev/rmt/0n rewind

Use ufsdump to back up the file system(s), for example:% ufsdump 0uf /dev/rmt/0n /dev/rdsk/c0t0d0s0% ufsdump 0uf /dev/rmt/0n /dev/rdsk/c0t0d0s7

This dumps slices 0 and 7 on one tape without rewinding the tape (and therefore overwriting previously made backups).

Rewind the tape and possibly make it offline (to eject the tape):% mt -f /dev/rmt/0n rewoffl

The following shell script is meant to support your task of backing up several file systems (disk slices) on a single tape. Keep in mind that you have to adjust the slice names to your system configuration. You may also need to remove or add some of the slices. It may be provided by ORGA as /backup.sh.

Please note that ufsrestore always writes the restored data into the current directory, meaning that you usually have to issue a cd com-mand before restoring certain files or file systems! In case of a file system, this also has to be mounted at a certain point to allow the cd command to work properly. Please refer to the manual page of the ufsrestore command for a complete list of options, parameters, and usage.

242

Appendix

1

4

5

6

2

3

A

7

I

#!/sbin/sh# Run this in single user mode as root partition is backed up!

#use tape with options (c)ompressing and (n)orewindTAPEDRIVE="/dev/rmt/0cn"#save rawdevicesPREFIX="/dev/rdsk/"#root and home filesysFILESYS="c1t0d0s0 c1t0d0s7"#Add flag u for writing /etc/dumpdates FLAGS="0f"

echo "Using tape drive $TAPEDRIVE"echo "Backing up filesystems $FILESYS with prefix $PREFIX"echo ""echo "Rewinding tape..."mt -f $TAPEDRIVE rewind

echo "Saving vtoc to tape..."prtvtoc /dev/rdsk/c1t0d0s2 > $TAPEDRIVE

echo "Dumping filesystems..."for X in $FILESYSdo FS=$PREFIX$X /usr/sbin/ufsdump $FLAGS $TAPEDRIVE $FSdone

echo "Rewinding tape..."mt -f $TAPEDRIVE rewoffl

The script mentioned above creates level 0 dumps of the following file sys-tems (disk slices):

/dev/rdsk/c1t0d0s0(sequence number for mt: 0)

/dev/rdsk/c1t0d0s7(sequence number for mt: 1)

which will be stored on a single tape.

To check that all these backups have been successfully performed please check the file

243

Appendix

1

4

5

6

2

3

A

7

I

/etc/dumpdates

which indicates which backups have been successfully performed (when the ’u’ option of the ufsdump command has been specified). After a suc-cessful backup the file should look similar to this:

% cat /etc/dumpdates

/dev/rdsk/c1t0d0s0 0 Fri Feb 8 15:59:08 2002

/dev/rdsk/c1t0d0s7 0 Fri Feb 8 16:04:05 2002

To restore any of these file systems

make sure that you position the tape correctly using either mt or ufsrestore options. For example, if you want to restore the file system stored in slice /dev/rdsk/c1t0d0s7 you have to make sure that the correct starting point of the tape is being used:

% mt -f /dev/rmt/0n asf 1(sequence # for mt is "1", see above)

then issue the ufsrestore command, or directly use% ufsrestore rvfs /dev/rmt/0n 2

For additional details see the manual pages of mt and ufsrestore.

A.7.4 Saving and Restoring Partitioning Information

In order to save the partitioning data (VTOC) of the system’s hard drive, use the prtvtoc command. The output of this command can be used to restore the original partitioning (slice configuration) of the system after a system fail-ure using the fmthard command. To get a listing of partitioning information for a disk, use the prtvtoc command as shown in the example below:

% prtvtoc /dev/rdsk/c1t0d0s2 >/vtoc

This example assumes that /dev/rdsk/c1t0d0s2 is your system’s primary hard drive. The VTOC information is stored in a file named /vtoc (residing

Attention! Add 1 to mt’s sequence #!

244

Appendix

1

4

5

6

2

3

A

7

I

on the root (/) partition). Save this data, e.g. on a floppy disk or by transferring it to another computer using FTP, and also make a hard copy of this file by printing it. Place this printout next to the machine to have it at hand in case of a restore!

After a disk replacement you can use this file containing the VTOC data to re-store the original partitions (slices) by using the fmthard command as in the following example:

% fmthard -s /vtoc /dev/rdsk/c2t0d0s2

This example assumes that you have restored the file /vtoc using a backup and that /dev/rdsk/c2t0d0s2 is your new system’s primary hard drive. If you can not access this VTOC data file, you would have to create it with an editor using your printout.

A.7.5 Restoring the World Wide Number (WWN)

The FC-AL disk drives used in the Sun 280R servers have a so-called World Wide Number. This number uniquely identifies each drive. After a system/drive crash, this number has to be restored. The following basic steps are re-quired to restore a WWN. These are all taken out of the SunSolve document ID "SRDB 17643", please see this document for additional details and refer-ence documentation.

The boot disk fails and is replaced by another disk with a different WWN.

Boot the system into single user from the CDROM or network.

Label the replacement disk to match the slices from the failed one (see fmthard)

Create file systems on all the slices to be restored (using newfs).

Mount the root file system and restore the data from backups (see below).

Install the boot block onto the recovered root slice using the installboot command

With root mounted under /a run the following commands to rebuild the devices tree: % drvconfig -r /a/devices -p /a/etc/path_to_inst

245

Appendix

1

4

5

6

2

3

A

7

I

% cd /devices% find . -print | cpio -pduVm /a/devices

% disks -r /a% devlinks -r /a

Configure the "boot-device" parameter in the EEPROM using the following command (assuming that c1t0d0s0 is your root slice):ok luxadm set_boot_dev /dev/dsk/c1t0d0s0.

Restore the other filesystems on that disk, or comment out the entries for them from /a/etc/vfstab. At least you must have all the Solaris file systems (ROOT, /var, /usr, /opt, etc.) recovered.

Reboot the system from the recovered disk.

A.7.6 Creating a Backup of the System’s Root (/) Partition

Special procedures are required to create a backup of the system’s root parti-tion. Since the root (/) partition can not be unmounted, the system has to be booted into single-user mode to prevent data corruption. The following steps illustrate how you can perform a backup of the root partition:

Log in as user "root" and make sure the system is not in production, i.e. it does not run any critical system/user processes which will otherwise be interrupted.

Bring the system to a halt (runlevel 0) and boot it into single-user mode:% init 0(shutdown messages, followed by the "ok" Boot PROM shell prompt)ok boot -s

Insert an (empty) tape into the tape drive

Use the ufsdump command to create a backup of the root file system:% ufsdump 0uf /dev/rmt/0 /dev/rdsk/c0t0d0s0

This example assumes that your root partition resides on

Note: All the commands described above are mandatory! Do not skip any of these steps!

246

Appendix

1

4

5

6

2

3

A

7

I

/dev/rdsk/c0t0d0s0. Your system configuration may be different. It is also assumed that you do not use this tape to store additional backups on it next to this root partition. If you intend to store additional file systems on the same tape, please use the n option (no rewind) when specifying the tape drive’s name (see above).

Check whether the root file system has been properly backed up:% ufsrestore tvf /dev/rmt/0

Allow the system to boot into runlevel 3 to resume normal operations:% exit (or press CONTROL-D)

A.7.7 Restoring the System’s Root Partition

Restoring the system’s root (/) partition is a delicate procedure. First of all, the system will not be able to boot without a proper root partition. Therefore, you would have to boot the system using a boot CDROM or from the network. After restoring the root partition you also have to make sure to write a suit-able boot block onto the newly restored root partition. This section includes the necessary steps to restore a system’s root partition.

1.) Since the system can not boot without a root partition you will end up in the system’s Boot PROM mini shell, indicated by the "ok" prompt. When booting from the Sun Solaris CDROM please make sure to insert the CD named "Solaris 8 CD 1 of 2" into your CDROM drive. Then boot the sys-tem into single-user mode using the CDROM:ok boot cdrom -s

2.) If necessary, recreate the partitioning information (VTOC data) of the hard drive by using the fmthard command with the previously saved VTOC data. Please refer to the fmthard and format manual pages for additional information. A call of fmthard may look like this:% fmthard -s /tmp/vtoc /dev/rdsk/c0t0d0s2

3.) Create a new file system on the system's root slice, e.g. /dev/rdsk/c0t0d0s0% newfs /dev/rdsk/c0t0d0s0

4.) Mount the newly created file system on an "empty" mount point,e.g. /a, and change into that directory (see the section on ufsrestore on why you should do this):

247

Appendix

1

4

5

6

2

3

A

7

I

% mount /dev/dsk/c0t0d0s0 /a% cd /a

5.) Use the ufsrestore command to restore the root file system from tape:% ufsrestore rvf /dev/rmt/0

If you have stored several different file systems on a single tape (see above) make sure that your tape is positioned at the correct starting point of the root file system data, either using the mt command or appropriate options for ufsrestore!

6.) Delete the file restoresymtable that ufsrestore created in the current directory:% rm restoresymtable

If you can not find this file (before issuing the rm command), this indi-cates that something went wrong during the restore of the file system.

7.) Restore the root file system’s boot block! This is an important step and also dependent on your system. Issue the following sequence of com-mands to restore a proper boot block:% cd /usr/platform/`uname -i`/lib/fs/ufs% installboot bootblk /dev/rdsk/c0t0d0s0

The required boot block information is stored on the CDROM and made available in the directory mentioned above after booting from it. In the example above, you might have to use uname -m instead of uname -i

Unmount the newly created file system:% cd /; umount /a

8.) Check the file system again to make sure it is in a proper state:% fsck /dev/rdsk/c0t0d0s0

9.) Reboot the system:% init 6

10.)For security reason, s you should perform another level 0 backup of the newly created root file system (on another tape) once you have verified that the system is working properly.% ufsdump 0uf /dev/rmt/0 /dev/rdsk/c0t0d0s0

248

Appendix

1

4

5

6

2

3

A

7

I

A.7.8 Restoring other important system partitions (/usr, /var/, ...)

To restore other important system partitions like /usr, /var, etc. you can use basically the same procedure as for the root (/) partition. However, the restore of a boot block is, of course, not necessary for these partitions. Therefore, you skip step 7 in the scenario described above for restoring the root partition.

A.7.9 Restoring ’normal’ (User) Partitions

To restore file systems of ’normal’ (user) partitions like /export or /opt, the system can be booted normally (into runlevel 3), assuming that these parti-tions will not be mounted automatically. You can therefore skip steps 1, 2, 7, and 10 in the scenario described above for restoring the root partition. You still need to create the new file system(s) and mount them manually to restore the data from tape using ufsrestore.

A.7.10 A Note Concerning /tmp

If you have a directory or file system named /tmp on your system, you usually do not need to backup and restore this data. It is sufficient to recreate the par-titioning data as described earlier in this document and create a new file sys-tem using newfs on the partition where /tmp is supposed to reside on. The reason is that /tmp is only used as a temporary storage which will be deleted anyhow during a reboot of the system.

The only important thing regarding /tmp is that you need to restore the ap-propriate access rights to this file system after creating it with newfs:

chmod 777 /tmp

will do this for you.

A.7.11 Backing Up and Restoring of RAID Metadevices

When you are using Solstice DiskSuite to create RAID metadevices, the back-up and restore strategy is different from the procedure described above. The major difference is the device names that are used by the system. For example, you would use /dev/md/rdsk/d11 instead of/dev/rdsk/c0t0d0s0 where md indicates the use of a so-called ’metade-vice’.

249

Appendix

1

4

5

6

2

3

A

7

I

For additional information concerning metadevices and the Solstice DiskSuite software in general, please refer to the Solstice DiskSuite User Manual. This manual can only cover small portions of what is possible with metadevices. The step-by-step description of backup and restore, however, contains further information on metadevices.

Running the metastat command provides you with more details about the set-up of the metadevices. Please refer to the manual page of this command for additional information.

A.7.11.1 Troubleshooting Metadevices

This section basically repeats information that is part of the Solstice DiskSuite User Manual, please refer to that manual for all details!

For proper troubleshooting you have to meet the following prerequisites:

– You must have super-user (root) privileges

– You must have a current backup of the system data

You will need the following at hand for a successful troubleshooting process:

Contents of the /etc/vfstab file

Status of state database replicas, metadevices, and hot spares, either from Disk-Suite Tool or from the output of the metadb and metastat commands

Disk partitioning information, either from the prtvtoc command or Stor-age Manager

A.7.11.2 Recovering the DiskSuite Configuration

From the Solstice DiskSuite User Manual:

The /etc/lvm/md.cf file is a backup file of the DiskSuite configuration for a ’local’ disk-set. Whenever you make a configuration change, the md.cf file is automatically updated (except for hot sparing). You never edit the md.cf file directly.

250

Appendix

1

4

5

6

2

3

A

7

I

If your system loses the information maintained in the metadevice state data-base , and as long as no metadevices were created or changed in the mean-time, you can use the md.cf file to recover your DiskSuite configuration.

A.7.11.3 How to Use the md.cf File to Recover a DiskSuiteConfiguration

The following procedure should only be used if you have experienced a com-plete loss of your DiskSuite configuration. This is usually the case if your root file system (on both mirrored drives) has been destroyed and you have to re-construct the whole system. If only one submirror is destroyed, you can use the remaining submirror to boot the system and repair it. Please refer to the Solstice DiskSuite User Manual for additional details! From the Solstice DiskSuite User Manual: Recover a DiskSuite Configuration

1.) Recreate the state database replicas. A state database replica stores DiskSuite configuration and state information. Before you can use DiskSuite, you must create state database replicas. Use metadb to create these database replicas. For example:% metadb -a -f -c 2 c0t1d0s5 c0t2d0s5

2.) Make a backup copy of the /etc/lvm/md.tab file.

3.) Copy the information from the md.cf file to the md.tab file.

4.) Edit the "new" md.tab file so that: - All mirrors are one-way mirrors. If a mirror’s submirrors are not of the same size, be sure to use the smallest submirror for this one-way mirror. Otherwise data could be lost.

- RAID5 metadevices are recreated with the -k option, to prevent reinitial-ization of the device. (Refer to the metainit man page for more informa-tion on this option.)

5.) Run the metainit command to check the syntax of the md.tab file entries.% metainit -n -a

The md.cf file does not maintain information on active hot spares. Thus, if hot spares were in use when the DiskSuite configuration was lost, those metadevices that were hot-spared will likely be cor-rupted.

251

Appendix

1

4

5

6

2

3

A

7

I

6.) After verifying that the syntax of the md.tab file entries is correct, run the metainit command to recreate the metadevices and hot spare pools from the md.tab file.% metainit -a

7.) Run the metattach command to make the one-way mirrors into multi-way mirrors.

8.) Validate the data on the metadevices.

There is an alternative to the method described above which is using the dd command to write the MetaDB to file(s) on the root partition. These files are then stored on tape during a backup of the root partition. Please see the step-by-step description in the following sections for all the details.

A.7.12 Backing up and Restoring a System Step by Step

The previous sections provide you with a detailed introduction to the backing up and restoring of the Sun Solaris Operating System. This section gives you a list of tasks and commands that you would have to perform or enter in order to back up and restore successfully a Sun Solaris Operating System including RAID mirror devices (metadevices). If anything in this step-by-step description is unclear to you, please have a look at the previous chapter for more detailed descriptions of what the commands do and how they are working.

A.7.13 Requirements

For the following step-by-step description to be successfully completed we as-sume that your Sun Solaris server has the following basic configuration:

Sun Solaris 8 Operating System installed

Solstice DiskSuite installed

A RAID system using two identical mirrored disks

It is also required that you have the Solaris OS boot CD-ROMs available and that you can connect to the system using either RSC (Remote System Control) or a serial console.

252

Appendix

1

4

5

6

2

3

A

7

I

A.7.14 Creating a Full System Backup Including the Root File System

To create a full backup of the system including the root (/) file system follow the steps provided in this section.

1.) Attach a tape drive to the system. Additional details on how to do this are provided in the section ”Installing and Using a Tape Drive” on page 239. You might also want to use a tape drive that is connected to a remote machine. Please refer to the Sun Solaris manuals to find out how to do this.

2.) Save the partitioning information and the MetaDB. The partitioning information is needed to restore the partitions on a hard drive in exactly the same way as it has been before. The MetaDB (metadevice database) is used by Solstice DiskSuite and contains vital information about the RAID mirror configuration.

2.1. Use prtvtoc to print the partitioning information (VTOC) of the system's hard drive to a file named vtoc residing on the root (/) partition. It is only necessary to do this for one of the hard drives because the second one is supposed to be an exact mirror of the first.% prtvtoc /dev/rdsk/c1t0d0s2 >/vtoc

The command mentioned above serves as a "precaution" since you would usually save the partitioning information also as the first file on the backup tape, see step (3) below. However, it is essential that you print out this data and keep it next to your machine!

2.2. Use the metadb command to find out where the MetaDB is stored, for example on slices /dev/dsk/c1t0d0s5 and /dev/dsk/c1t1d0s5. It takes up exactly 2084 bytes (offset_first_block (=16) + 1034 + 1034 = 2084 blocks).

253

Appendix

1

4

5

6

2

3

A

7

I

Example:

2.3. Use dd to save the MetaDB to the root partition in order to back it up along with the rest of the data residing on the system’s root partition later on. Make sure you use the rdsk devices instead of the dsk devices!

% dd if=/dev/rdsk/c1t0d0s5 of=/metadb_c1t0d0s5 bs=512 count=2084

% dd if=/dev/rdsk/c1t1d0s5 of=/metadb_c1t1d0s5 bs=512 count=2084

This creates two files on the root partition, named after the MetaDB slice they contain: metadb_c1t0d0s5 and metadb_c1t1d0s5.

3.) Back up everything on tape. This includes all partitions, especially the root partition. You can use the script /backup.sh provided in the sec-tion ”Backing up Several File Systems on a Single Tape” on page 242 in order to back up all partitions on a single tape. Make sure that you save the partitioning information at the starting position of a new tape. The provided /backup.sh shell script does this automatically.

3.1. Bring the system down into single user mode using the following two commands. These first cleanly shut down the system which you later boot in single user more:

% shutdown -i0 -g0 -y (shuts down the system)ok boot -s (boots the system into single user

mode)

3.2. Start the backup script /backup.sh and wait until it is finished.

% metadb

flags first blk block count

a m p lu 16 1034 /dev/dsk/c1t0d0s5

[...]

254

Appendix

1

4

5

6

2

3

A

7

I

3.3. Bring the system back into normal multi-user mode and resume normal operations.

A.7.15 Restoring the Primary Hard Drive

After a system crash or a hard drive failure the root partition, which is essential for booting the system, may have been destroyed. This section explains to you how to restore this root partition on the primary hard drive.

Here is a step-by-step description telling you how to restore the system after a crash, using the same hard drive (without the need to configure a new WWN):

1.) Boot the system from CDROM. Use the Sun Solaris OS CDROM named "Solaris 8 Software CD 1 of 2" (Version 7/01) to boot the system into sin-gle user mode.rsc> consoleok boot cdrom -s

2.) Restore the partitioning information from tape. Make sure that you insert the correct tape for the machine you are restoring! Since this VTOC data is stored at the starting position of the tape, it has to be rewound:% mt -f /dev/rmt/0cn rewind% cat /dev/rmt/0cn | fmthard -s - /dev/rdsk/c1t0d0s2

The output of fmthard should be something like the following:

fmthard: New volume table of contents now in place.

Note that this sort of a full backup does not need to be per-formed regularly unless you update the operating system or change the system's configuration since it is as-sumed that the data, especially stored on the root partition, will not change signifi-cantly over time.

Note: In case you had to replace the primary (boot) hard drive by another one you have to make sure to configure the World Wide Number correctly. The section A.7.5 explains in more detail what the WWN is and how to configure the system.

Notice the use of the fmthard command which is described in more detail in the previous chapter.

255

Appendix

1

4

5

6

2

3

A

7

I

fmthard can not write a disk label on an unlabeled disk.

Use format in advance for this purpose.

3.) Create new file systems. The following commands create file systems on slices for the root, tmp, and home file systems:

% newfs /dev/rdsk/c1t0d0s0% newfs /dev/rdsk/c1t0d0s6% newfs /dev/rdsk/c1t0d0s7

4.) Mount the new file systems and restore their contents one after the other. This can be done by the following sequence of commands:% mount /dev/dsk/c1t0d0s0 /a% cd /a% ufsrestore rvf /dev/rmt/0cn(use "rf" for no output)% rm restoresymtable% cd /% umount /a% fsck /dev/rdsk/c1t0d0s0

Repeat these steps for slice c1t0d0s7 which holds the /home slice. As mentioned in the previous chapter there is no need to restore the contents of the /tmp slice.

5.) Restore the Boot Block. The boot block resides on the root partition of the primary hard drive and is required for proper booting of the system. Enter the following commands to restore it:

% cd /usr/platform/`uname -i`/lib/fs/ufs% installboot bootblk /dev/rdsk/c1t0d0s0

6.) Restore the MetaDB replicas. If you are using RAID mirror devices you need to restore the MetaDB. This data has been previously stored on the root (/) partition in a file (metadb_c1t0d0s5) that has been restored in the previous step. Use the following sequence of commands to do restore the MetaDB replicas:% mount /dev/dsk/c1t0d0s0 /a

New hard drives coming directly from Sun are already labeled.

256

Appendix

1

4

5

6

2

3

A

7

I

% dd if=/a/metadb_c1t0d0s5 of=/dev/rdsk/c1t0d0s5 bs=512

% umount /a

7.) If you are using a RAID mirror, continue with section 2.4. Otherwise you can reboot your system and assign proper access rights to the /tmp parti-tion:

% reboot% chmod 777 /tmp

A.7.16 Restoring the Mirror

Restoring the mirror device(s) involves some Solstice DiskSuite commands. These commands, and the sequence of the commands is described in this sec-tion.

1.) Restore the partitioning information on the mirror drive. This can be done using the partitioning information of the primary hard drive since both drives are meant to hold the exact same data:% prtvtoc /dev/rdsk/c1t0d0s2| fmthard -s - /dev/rdsk/c1t1d0s2

2.) Remove the mirror drive from the system. This is necessary to reinitiate the synchronization of the mirror.

% shutdown -i0 -g0 -y (shuts down the system)ok set auto-boot? falseok power-off

Now you can safely remove the mirror disk from the system.

3.) Power on the system (without the mirror disk) and boot into single user mode. After booting, enter the maintenance mode.

ok boot -s

The system will prompt you with the following: ’Insufficient metadevice database replicas located’ and you must enter maintenance mode. In maintenance mode you should look for ’unknown’ replicas, indicated by a ’u’ in the following list (example):

257

Appendix

1

4

5

6

2

3

A

7

I

4.) Remove the unknown database replicas. You can safely ignore warning messages like ’wiq22: /etc/lvm/mddb.cf.new: Read-only file system’. Issue the following command to remove the database replicas:% metadb -d /dev/dsk/c1t1d0s5

5.) Perform a complete reboot of the system.

% shutdown -i6 -g0 -y (or % reboot)

6.) Save the MetaDB status file. You may need this file later on.% metastat >/metastat.error

This creates a file named metastat.error on your root partition.

7.) Locate any submirrors using the removed disk and detach them. See the metastat output and look for lines similar to the following example:

You should issue a metadetach command for each submirror that indicates a problem (’Needs maintenance’). While doing so make sure to write down all the metadetach commands you entered. The syntax for

Attention! Do not leave the maintenance mode by logging out!

% metadb

flags first blk block count

a m p lu 16 1034 /dev/dsk/c1t0d0s5

a p l 1050 1034 /dev/dsk/c1t0d0s5

M p unknown unknown /dev/dsk/c1t1d0s5

M p unknown unknown /dev/dsk/c1t1dos5

d8: MirrorSubmirror 0: d6

State: OkaySubmirror 1: d7

State: Needs maintenance

258

Appendix

1

4

5

6

2

3

A

7

I

the metadetach command is as follows: metadetach <mirror> <submirror>.

Example:

% metadetach -f d11 d0

The output should be: d11: submirror d0 is detached

% metadetach -f d8 d7% metadetach -f d9 d5% metadetach -f d10 d3

8.) Halt the system to (re-)attach the mirror disk.


After the system has been halted (re-)attach the mirror disk and boot into sin-gle user mode:

ok boot -s

9.) Add two replicas of the MetaDB to the broken slice. For example, if slice c1t1d0s5 is affected, enter the following command to do so:

% metadb -a -c 2 c1t1d0s5

10.)Reattach the submirrors. You have to use exactly the same mirrors (num-bers) you used during the detachment in step 7.

% metattach d11 d0

The output should be: d11: submirror d0 is attached

% metattach d8 d7% metattach d9 d5% metattach d10 d3

Use the metastat command afterwards to make sure that the resyncing of the mirror is in progress.

11.)You can enter multi user mode. Use ’init 2’ while resyncing of the mirror is in progress.

12.)Enable auto boot. Use the following commands to enable auto-booting again:

% eeprom "auto-boot?=true"

259

Appendix

1

4

5

6

2

3

A

7

I

% eject /cdrom

13.)Finally, set the appropriate rights to /tmp.

% chmod 777 /tmp

A.7.17 Restoring the System in General

This section assumes that the root partition of the system is not affected by a crash and you therefore do not need to restore it. Here are the steps required to restore the system:

1.) Boot the system from hard drive. Since the root partition is not defective, you can use it to boot the system instead of using a CDROM.

2.) Restore any corrupted partitions from tape. Follow the steps in the previ-ous section(s) to restore any corrupted partitions from tape and skip the steps required to restore the root partition, e.g. the creation of the boot block, etc.

Use the mt command to fast forward the tape to the correct position(s) of the backups. For example, if you want to restore the /home partition located on slice c1t0d0s7 - stored at the 3rd position on the backup tape by the backup script - you issue the following command:

% mt -f /dev/rmt/0cn asf 2

Then follow the remaining steps listed in the previous section(s) to restore the partition using ufsrestore.

A.8 How to Shut Down or Reboot a System Properly

1.) Attach to the machine with telnet or rsc

a. telnet:

telnet <hostname>

Enter username and password for wIQ user

Get root:

wiq>su -

260

Appendix

1

4

5

6

2

3

A

7

I

b. rsc:

telnet <hostname-rsc>

Enter username and password for rsc user

Start the console:

rsc> console

Log in as root

2.) Shutdown or reboot:

a. Shut down and turn off power automatically:


b. Reboot:

% reboot

or


c. Shutdown into boot prompt (you will only need this for backup/restore):


A.9 Apache Web Server

The wIQ1.3 is delivered with the apache Web server version 1.3.14 and PHP version 4.0.4pl1.

The Web server is located in $ORGAROOT/apache and the PHP in $ORGA-ROOT/php. If the Web server is started manually, it must have the same $OR-GADATA and $ORGAROOT environments as wIQd!

In any case, you should give the machine about 2 minutes to shut down! If you use rsc, you can watch the console messages and see when the shutdown or reboot has finished.

261

Appendix

1

4

5

6

2

3

A

7

I

Apache log files can be found in $ORGAROOT/apache/logs.

Important Configurations:

MaxRequestsPerChild 200 # needed on Solaris to avoid mem leaks LoadModule php4_module libexec/libphp4.so

AddModule mod_php4.c

AddType application/x-httpd-php .php

AddType application/x-httpd-php-source .phps

A.10 Regular Expression

In database tables, you will find ’...;RE’ which stands for ’Regular expression’.

A regular expression can contain the following information:

. stands for any character

.* stands for any number of character

^ must start with the following character

$ indicates the end

[n-m] specification of range

Example:

^013.* numbers of any length, starting with 013

^018[1-3]$ corresponds to 0181, 0182 and 0183

^019[2-4]5$ corresponds to 01925, 01935 and 01945

A.11 Setting of $RANDFILE

The environment variable $RANDFILE must be set to

$ORGAROOT/run/bin/wIQ

262

Appendix

1

4

5

6

2

3

A

7

I

for HTTPS access.

A.12 ORGA Alarm Definitions

A.12.1 ORGA SNMP MIB Definitions

A.12.1.1 OLS-CommonAlarmTrap.mibe COMPANY-ORGA-ALARM-TRAP-MIB

DEFINITIONS ::= BEGIN

-- ===============================================================

-- Copyright (C) ORGA Kartensysteme GmbH 2000

-- ===============================================================

-- This MIB Module defines common alarm traps More detailed

-- description of the variables and tables is provided in other

-- related documentation.

--

-- Format: SNMP v1 MIB

-- version

-- 1.0 : First version.

--

-- ===============================================================

-- Author : Michael Brandenburg

-- Version : 1.0

-- Last Update : 15-11-2000

--================================================================

IMPORTS

caSeverity, caEventType, caOriginatingEquipment,

caEventTime, caAdditionalData, caEventNumber,

caEventText, caNotificationID, caTrapId

FROM COMPANY-ORGA-ALARM-DEFINITIONS-MIB

263

Appendix

1

4

5

6

2

3

A

7

I

enterprises

FROM RFC1155-SMI

TRAP-TYPE

FROM RFC-1215;

--=============================================================

-- Definitions

--=============================================================

-- OID for ORGA


-- OIDs sorted by ORGA products


-- OID for Orga Logging System (OLS)


-- starting point for the "common alarm trap" MIB


--=============================================================

-- Common trap definition for alarm events

--=============================================================

caAlarmEvent TRAP-TYPE -- Severity : warning,minor,major or critical

ENTERPRISE alarmTraps

-- STATUS mandatory

VARIABLES {caSeverity, caEventType, caOriginatingEquipment,


caEventText, caNotificationID, caTrapId}

264

Appendix

1

4

5

6

2

3

A

7

I

DESCRIPTION "This is common alarm event trap."

::= 1

--=============================================================

-- Common trap definition for cancel events

--=============================================================

caCancelEvent TRAP-TYPE -- Severity : cancel

ENTERPRISE alarmTraps

-- STATUS mandatory

VARIABLES {caSeverity, caEventType, caOriginatingEquipment,


caEventText, caNotificationID, caTrapId}

DESCRIPTION "This is common cancel event trap."

::= 2

END

A.12.1.2 OLS-CommonAlarmDefinitions.mibe COMPANY-ORGA-ALARM-DEFINITIONS-MIB

DEFINITIONS ::= BEGIN

-- ===============================================================

-- Copyright (C) ORGA Kartensysteme GmbH 2000

-- ===============================================================

-- This MIB Module defines common alarm definitions. The

-- alarm traps are defined in other MIB Module. More detailed

-- description of the variables and tables is provided in other

-- related documentation.

--

265

Appendix

1

4

5

6

2

3

A

7

I

-- Format: SNMP v1 MIB

--

-- ===============================================================

-- Author : Michael Brandenburg

-- Version : 1.2

-- Last Update : 31-07-2002

--================================================================

IMPORTS

enterprises

FROM RFC1155-SMI

DisplayString

FROM RFC1213-MIB

OBJECT-TYPE

FROM RFC-1212;

--=============================================================

-- Definitions

--=============================================================

-- OID for ORGA


-- OIDs sorted by ORGA products


-- OID for Orga Logging System (OLS)


--=============================================================

-- OID registration subtrees for this MIB module

--=============================================================

266

Appendix

1

4

5

6

2

3

A

7

I

-- starting point for the "common alarm trap" MIB


-- starting point for the "common alarm definitions" MIB

ca OBJECT IDENTIFIER ::= {alarmTraps 2} -- common alarms

caVars OBJECT IDENTIFIER ::= {ca 1} -- common alarms variables

--=============================================================

-- Payload of the ORGA Common Alarm Traps

-- ca == Common Alarm

--=============================================================

caSeverity OBJECT-TYPE

SYNTAX INTEGER

ACCESS read-only

STATUS mandatory

DESCRIPTION

"Severity of alarm trap: indeterminate(0), critical(1), major(2),

minor(3), warning(4), clear(5), informational(6)"

::= {caVars 1}

caEventType OBJECT-TYPE

SYNTAX INTEGER (0..5)

ACCESS read-only

STATUS mandatory

DESCRIPTION

"The event type : unknown(0),communication(1),environmental(2),

equipment(3),processing(4),quality of service(5)"

::= {caVars 2}

caOriginatingEquipment OBJECT-TYPE

SYNTAX DisplayString (SIZE (0..100))

267

Appendix

1

4

5

6

2

3

A

7

I

ACCESS read-only

STATUS mandatory

DESCRIPTION

"Object identifier is used to distinguish the process sending the

alarm."

::= {caVars 3}

caEventTime OBJECT-TYPE


ACCESS read-only

STATUS mandatory

DESCRIPTION

"This variable contains date and time in format JJJJMMDDHHMMSS"

::= {caVars 4}

caAdditionalData OBJECT-TYPE

SYNTAX OCTET STRING(SIZE (0..64))

ACCESS read-only

STATUS mandatory

DESCRIPTION

"Additional information"

::= {caVars 5}

caEventNumber OBJECT-TYPE

SYNTAX INTEGER (0..9999)

ACCESS read-only

STATUS mandatory

DESCRIPTION

"Event number tells the specific reason of the problem.

The value of this variable also uniquely identifies an

alarm."

::= {caVars 6}

268

Appendix

1

4

5

6

2

3

A

7

I

caEventText OBJECT-TYPE


ACCESS read-only

STATUS mandatory

DESCRIPTION

"Event text of the trap."

::= {caVars 7}

caNotificationID OBJECT-TYPE

SYNTAX INTEGER (0..'7fffffff'h)

ACCESS read-only

STATUS mandatory

DESCRIPTION

"This variable is used as a unique alarm identifier."

::= {caVars 8}

caTrapId OBJECT-TYPE

SYNTAX INTEGER (0..'7fffffff'h)

ACCESS read-only

STATUS mandatory

DESCRIPTION

"caTrapId will be incremented by one in each trap sent by NE to a NMS. When

caTrapId achieves the maximum value, the variable will wrap back to

value 1 when sending the next trap. caTrapId is used by NMS to detect if

traps are lost."

::= {caVars 9}

END

269

Appendix

1

4

5

6

2

3

A

7

I

A.12.2 List Of Event Ids

A.12.2.1 Trap Definitions

This section will summarize the traps defined in this manual:

Co

mp

on

ent

Even

t-ID

OLS

-Nam

e

Des

crip

tio

n

wIQ 6196 MAIN.INFO.WAITING Waiting for new connection of a client -> raise

wIQ 6253 USSD.I.SOCKETCLOSED Socket connection was closed -> raise

wIQ 6255 USSD.I.NEWCONNECTION A new connection has been established or wIQ is terminat-ing -> clear

Router 6900 CONFIG.I.LISTENING The router is listening on a socket for a driver to connect -> raise

Router 6917 CONN.I.CONNECTED The router is connected to a driver, or the router is shutting down -> clear

Router 6921 CONN.I.NOTCONNECTEDWIQ The router is not connected to a wIQ -> raise

Router 6920 CONN.I.CONNECTEDWIQ The router is connected to a wIQ, or the router is shutting down -> clears the trapmen-tioned above

wIQguard 0000 HEARTBEAT Heartbeat message (not cleared), dynamic part is empty

270

Appendix

1

4

5

6

2

3

A

7

I

wIQguard 6001 WIQGUARD.PROCESSUP wIQguard has started a process (e.g. wIQ_a) -> clears 6002

wIQguard 6002 WIQGUARD.PROCESSDOWN wIQguard recognized process stop -> raise

wIQguard 6003 WIQGUARD.UP wIQguard is coming up -> clears 6004

wIQguard 6004 WIQGUARD.DOWN wIQguard is halted -> raise

wIQguard 6005 WIQGUARD.REMOTEUP wIQguard is started in remote mode ->raise

wIQguard 6006 WIQGUARD.REMOTEDOWN wIQguard remote mode is quit -> clears 6005

*wIQ 6524 SC_STREAM.I.LICENSELIMIT License limit reached -> raise

extUSSD-webser-vice

7343 ROUTER.INFO.WAITING Waiting for new connection -> raise

extUSSD- webser-vice

7339 ROUTER.INFO.CONNECTED A new connection has been established or process is termi-nating -> clear


7341 ROUTER.INFO.CLOSE Connection has been closed -> raise

Co

mp

on

ent

Even

t-ID

OLS

-Nam

e

Des

crip

tio

n

271

Appendix

1

4

5

6

2

3

A

7

I

A.13 Bibliography

GSM 03.40

Title: Technical realization of the Short Message Service (GSM 03.40)

Identification:ETSI TS 100 901

Version: V7.4.0

Date: 1998

Publisher: European Telecommunication Standard

GSM 03.38

Title: Alphabets and language-specific information (GSM 03.38)

Identification:ETSI TS 100 900

Version: V7.2.0

Date: 1998

Publisher: European Telecommunication Standard


7260 EXT.STARTUP Process is starting up -> clear


7259 EXTUSSD.I.SHUTDOWN Process is exiting -> set

* Traps listed in italic font are disabled by default

Co

mp

on

ent

Even

t-ID

OLS

-Nam

e

Des

crip

tio

n

272

Index I

1

I

4

5

6

3

2

7

A

A

Abbreviation list .................................... 3Apache Web server ......................... 261Assignment to group .......................... 46

B

Backup ............................................. 237Billing ....................................... 119, 123

Configuration variables .............. 131IN billing ............................... 77, 120Modules ..................................... 121Postpaid ............................ 120, 129Prepaid .............................. 120, 129Types ......................................... 129

Billing mechanism ............................ 120Browsing ............................................ 25

C

Call wIQ service ........................... 21, 30Commandline interfaces .................... 41Commandline options ........................ 64

Comparison types ...............................40Configuration ......................................49Configuration billing

Variables ....................................131Configuration file

Variables ......................................67Configuration tables ....................76, 131Constraints .........................................34Conventions ..........................................1Conversion .........................................12Conversion URL ...............................126

D

Data Coding Scheme .......................188Database

Incore ...........................................37Subscriber ....................................37Tools .............................................41

Database defaults ...............................97Databases ..........................................37Default table .......................................97Direct parameter passing ...................34Direct SMS .......................................207

273

Index

1

I

4

5

6

3

2

7

A

E

End of Session ................................... 29Enhanced SMS ................................ 183Environment variables ....................... 65ESMS ............................................... 183Examples

Binary SMS ............................... 204Picture SMS .............................. 205Ringtone ESMS ......................... 201Text ESMS ................................. 203

External requirements ........................ 11

F

First login ........................................... 18Formats

HTML input formats ..................... 33

H

Handling signals ................................. 65Hotkey

Functionality .......................... 25, 28Functions ....................................... 7Preinput ....................................... 23

Hotkeys ............................................ 102HotKeySet table ............................... 102HotKeySet.cfg .................................. 102HTML

Input formats ............................... 33Tags ............................................. 12

HTTP header ..................................... 86HTTP interface extension ................ 199HTTPS environment variables .... 33, 90,

262

I

IN billing ..............................77, 120, 123configuration ..............................100

Inclusion table ...............................33, 84Incore Database .................................37Information subscriber ......................125Input

Character set ...............................26Formats ........................................33Interfaces .....................................18

Install tape drive ...............................239Interface_wIQ.cfg ...............................65Interfaces ............................................37

Commandline ...............................41PHP ..............................................37Subscriber’s input ........................18

L

Language extension .........................189License file ........................................100Long ESMS ......................................185Long SMS .........................................184

M

MAP ....................................................12Mapping table .....................................78Modules (Billing) ...............................121

274

Index

1

I

4

5

6

3

2

7

A

N

Notification.cfg ................................. 135

O

ORGA NSG driver ............................ 207

P

Parameter passing ............................. 34PHP-Interfaces ................................... 37Postpaid billing ......................... 120, 129Preinput processing ........................... 28Prepaid billing .......................... 120, 129Price tag ........................................... 121Protocol identifier ............................. 187Provider list ...................................... 121ProviderMap.cfg ............................... 121

R

Rapid access to URL ......................... 23Reboot system ................................. 260Regular ESMS ................................. 184Regular expression .......................... 262Requirements, external ...................... 11Restore ............................................ 237Ringtone SMS .................................. 184

S

Secure HTTP ................................... 121Self-registration .................................. 18

ServiceCommands ...................................21Start a ~ ........................................21

Service Number ..................................22Session

Browsing ......................................25End ...............................................29

Shutdown system .............................260Signal handling ...................................65SMS ..............................................30, 77

Supported types ...........................32SMS Conversion .................................12SMS request .......................................96SMS to Service Mapping table ...........90SMS2Service.cfg* ...............................90SNMP ...............................................211SNMP support ..................................218Special characters ..............................34Start wIQ .............................................49Start wIQ service ................................21Stop wIQ .............................................49SUBMIT-TPDU .................................185Subscriber

Assignment to group ....................46Direct parameter passing .............34First login .....................................18Identity to URLs ...........................33IMSI ..............................................33Information .................................125Input interface ..............................18MSISDN .......................................33Self-registration ............................18

Subscriber database ...........................37System description ...............................7System overview ..................................7System reboot ..................................260System shutdown .............................260

275

Index

1

I

4

5

6

3

2

7

A

T

Tag attribute missing ........................ 198Tag attribute parsing ........................ 198Tag processing rules ........................ 198Tags ................................................... 12

dcs ..................................... 189, 191msginddcs ......................... 189, 192msgindudh ......................... 189, 196pid ...................................... 189, 194smshead ............................ 189, 190udhie .................................. 189, 197User-specific .............................. 196vp ....................................... 189, 194

Tape drive ........................................ 239tedriver process ............................... 207TP-DCS ............................................ 188TPDU parameters ............................ 184TP-PID ............................................. 187TP-VP .............................................. 188

U

URLAccess ......................................... 22Conversion ................................ 126Rapid access ............................... 23Valid ~ .................................. 84, 124

Using SMS ......................................... 30Using USSD ....................................... 18USSD ................................................. 18USSD conversion ............................... 12

USSD to URL MappingConfiguration table .......................47Group ...........................................43Group-specific mapping ...............46table .............................................78

V

Valid URL ....................................84, 124Validity Period ...................................188Validity rules .....................................199Variables

Configuration file ..........................67Environment .................................65HTTP header ...............................86Inclusion table ........................33, 84

W

wIQ .......................................................7Call a service .........................21, 30Internal .........................................64Process ........................................11

wIQ.cfg ...............................................67wIQd.cfg .............................................51wIQPush ...........................................199

276

Date post:	04-Oct-2014
Category:	Documents
Upload:	iamsipmaster
View:	107 times
Download:	3 times

UMA_wIQ_Rel1.7_V1.6

Documents