DSI SS7G41 Signaling Server - Dialogic | Cloud-Optimized...

www.dialogic.com

Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual

2

Copyright and Legal Notice Copyright © 2011-2013 Dialogic Inc. All Rights Reserved. You may not reproduce this document in whole or in part without permission

in writing from Dialogic Inc. at the address provided below.

All contents of this document are furnished for informational use only and are subject to change without notice and do not represent a

commitment on the part of Dialogic Inc. and its affiliates or subsidiaries (“Dialogic”). Reasonable effort is made to ensure the accuracy

of the information contained in the document. However, Dialogic does not warrant the accuracy of this information and cannot accept

responsibility for errors, inaccuracies or omissions that may be contained in this document.

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH DIALOGIC® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN

A SIGNED AGREEMENT BETWEEN YOU AND DIALOGIC, DIALOGIC ASSUMES NO LIABILITY WHATSOEVER, AND DIALOGIC DISCLAIMS

ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF DIALOGIC PRODUCTS INCLUDING LIABILITY OR

WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY INTELLECTUAL

PROPERTY RIGHT OF A THIRD PARTY.

Dialogic products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility

applications.

Due to differing national regulations and approval requirements, certain Dialogic products may be suitable for use only in specific countries, and thus may not function properly in other countries. You are responsible for ensuring that your use of such products occurs

only in the countries where such use is suitable. For information on specific products, contact Dialogic Inc. at the address indicated

below or on the web at www.dialogic.com.

It is possible that the use or implementation of any one of the concepts, applications, or ideas described in this document, in marketing

collateral produced by or on web pages maintained by Dialogic may infringe one or more patents or other intellectual property rights

owned by third parties. Dialogic does not provide any intellectual property licenses with the sale of Dialogic products other than a

license to use such product in accordance with intellectual property owned or validly licensed by Dialogic and no such licenses are

provided except pursuant to a signed agreement with Dialogic. More detailed information about such intellectual property is available from Dialogic’s legal department at 926 Rock Avenue, San Jose, California 95131 USA. Dialogic encourages all users of its

products to procure all necessary intellectual property licenses required to implement any concepts or applications and

does not condone or encourage any intellectual property infringement and disclaims any responsibility related thereto.

These intellectual property licenses may differ from country to country and it is the responsibility of those who develop

the concepts or applications to be aware of and comply with different national license requirements.

Dialogic, Dialogic Pro, Dialogic Blue, Veraz, Brooktrout, Diva, Diva ISDN, Making Innovation Thrive, Video is the New Voice, Diastar,

Cantata, TruFax, SwitchKit, SnowShore, Eicon, Eicon Networks, NMS Communications, NMS (stylized), Eiconcard, SIPcontrol,

TrustedVideo, Exnet, EXS, Connecting to Growth, Fusion, Vision, PowerMedia, PacketMedia, BorderNet, inCloud9, I-Gate, Hi-Gate,

NaturalAccess, NaturalCallControl, NaturalConference, NaturalFax and Shiva, among others as well as related logos, are either registered trademarks or trademarks of Dialogic Inc. and its affiliates or subsidiaries. Dialogic's trademarks may be used publicly only

with permission from Dialogic. Such permission may only be granted by Dialogic’s legal department at 926 Rock Avenue, San Jose,

California 95131 USA. Any authorized use of Dialogic's trademarks will be subject to full respect of the trademark guidelines published

by Dialogic from time to time and any use of Dialogic’s trademarks requires proper acknowledgement.

The names of actual companies and products mentioned herein are the trademarks of their respective owners.

This document discusses one or more open source products, systems and/or releases. Dialogic is not responsible for your decision to

use open source in connection with Dialogic products (including without limitation those referred to herein), nor is Dialogic responsible for any present or future effects such usage might have, including without limitation effects on your products, your business, or your

intellectual property rights.

Publication Date: February 2013

Document Number: U01LGD

Dialogic® DSI SS7G41 Signaling Server SWS Developers Manual Issue 4

3

Revision History

Issue Date Description

4 February 2013 Addition of multiple profiles

3 April 2012 Support for SWS Release 1.1.0 added.

2 September 2011 General Availability

1 July 2011 Initial version for Beta release

Contents

Revision History ........................................................................................................... 3

Contents ....................................................................................................................... 3

1 Introduction ........................................................................................................ 7

1.1 Signaling Service Support ........................................................................................................ 7 1.2 Feature Overview .................................................................................................................... 7 1.3 Abbreviations ......................................................................................................................... 7 1.4 Related Information ................................................................................................................ 8

2 SWS Mode Overview ............................................................................................ 9

2.1 Architecture Overview ............................................................................................................. 9 2.1.1 Signaling Topologies ................................................................................................. 10

2.2 Multiple Network Support ....................................................................................................... 13 2.2.1 Protocol Handling for Multiple Network Contexts ........................................................... 13 2.2.2 Inter-SWS Communications ....................................................................................... 15 2.2.3 Transaction-Based Applications .................................................................................. 15 2.2.4 Management of Local SCCP Sub-Systems .................................................................... 15 2.2.5 Alarms .................................................................................................................... 16

2.3 Interfaces ............................................................................................................................ 16 2.3.1 Application Interface ................................................................................................. 17 2.3.2 Configuration Interface .............................................................................................. 17 2.3.3 Management Interface, Trace, and Diagnostics ............................................................. 18 2.3.4 Network Interfaces ................................................................................................... 18

3 Web Services APIs ............................................................................................ 19

3.1 Overview ............................................................................................................................. 19 3.2 Summary ............................................................................................................................. 20

3.2.1 Supported URIs / Methods ......................................................................................... 20 3.2.2 Payload Structure ..................................................................................................... 21 3.2.3 HTTP Response Codes ............................................................................................... 21

3.3 MAP Services Used ................................................................................................................ 22

4 Short Message API ............................................................................................ 23

4.1 Sending an SMS ................................................................................................................... 23 4.1.1 Support for Report SM Delivery .................................................................................. 25

4.2 Receiving an SMS ................................................................................................................. 26 4.3 Sending a binary format SMS ................................................................................................. 27 4.4 Receiving a binary format SMS ............................................................................................... 28 4.5 Sending a concatenated binary format SMS.............................................................................. 29 4.6 Receiving a concatenated binary format SMS ........................................................................... 30 4.7 Mobile Originated SMS ........................................................................................................... 31

Contents

4

4.8 Sending Atomic MT-SMS ........................................................................................................ 32 4.9 Sending a binary format Atomic MT-SMS ................................................................................. 34 4.10 Sending Concatenated Atomic MT-SMS .................................................................................... 35 4.11 Sending Atomic Send Routing Info For SM ............................................................................... 36 4.12 Sending Atomic Report SM Delivery ........................................................................................ 37 4.13 Sending Atomic Ready For SM ................................................................................................ 38 4.14 Receiving Atomic Send Routing Info For SM ............................................................................. 39 4.15 Receiving an Alert Service Centre ........................................................................................... 41

5 USSD API ........................................................................................................... 44

5.1 Mobile Initiated Sessions ....................................................................................................... 44 5.2 Client Application Initiated Session ......................................................................................... 46 5.3 Client Application Initiated - USSD Notify ................................................................................. 47

6 Location and Subscriber Polling API .................................................................. 49

6.1 Location API ......................................................................................................................... 49 6.2 Subscriber State API ............................................................................................................. 50 6.3 Get IMSI API ........................................................................................................................ 51

7 Profiles and Multiple Network Support .............................................................. 52

7.1 Introduction to Profiles .......................................................................................................... 52 7.2 Transmit Profiles ................................................................................................................... 52 7.3 Receive Profiles .................................................................................................................... 53

8 Parameter Reference ......................................................................................... 54

8.1 SMS Service ......................................................................................................................... 54 8.1.1 SMS Deliver parameters ............................................................................................ 55

8.2 Atomic SMS-MT Service ......................................................................................................... 56 8.3 MO-SMS Service ................................................................................................................... 56

8.3.1 SMS Submit parameters ............................................................................................ 57 8.4 Alert Service Centre Service ................................................................................................... 58 8.5 Send Routing Info For SM Service ........................................................................................... 58

8.5.1 Inform Service Centre parameters .............................................................................. 59 8.6 Report SM Delivery Status Service .......................................................................................... 60 8.7 USSD Service ....................................................................................................................... 61 8.8 Location Service ................................................................................................................... 62

8.8.1 Cell Id Parameters .................................................................................................... 62 8.9 Subscriber State Service ........................................................................................................ 63 8.10 Get IMSI Service .................................................................................................................. 64 8.11 Error ................................................................................................................................... 65

8.11.1 Error Code Types...................................................................................................... 65 8.11.2 Error Code Type – internalFailureCodeType ................................................................. 65 8.11.3 Error Code Type – mapErrorCodeType ........................................................................ 65 8.11.4 Error Code Type – userErrorCodeType ........................................................................ 67 8.11.5 Error Code Type – providerErrorCodeType ................................................................... 67 8.11.6 MAP User Errors ....................................................................................................... 67

9 Application Development Guidelines ................................................................. 70

9.1 Application Development Frameworks ..................................................................................... 70 9.2 XML Handling ....................................................................................................................... 70 9.3 HTTP/HTTPS ........................................................................................................................ 70 9.4 Use of Expect: HTTP 100 – Continue ....................................................................................... 70

10 Application Examples ........................................................................................ 71

10.1 Java SWS Test Utility ............................................................................................................ 71


5

10.2 C# SWS Example Application ................................................................................................. 72 10.3 PHP Example ........................................................................................................................ 73

Appendix A. XSD Files ............................................................................................. 74

A.1 SWS XSD Schema ................................................................................................................. 74

Appendix B. Testing Extensions to the API ............................................................. 88

B.1 Receiving Atomic Send Routing Info For SM ............................................................................. 88 B.2 Receiving Ready For SM ......................................................................................................... 89 B.3 Receiving Report SM Delivery ................................................................................................. 91 B.4 Receiving Location Request .................................................................................................... 92 B.5 Receiving Subscriber State Request ........................................................................................ 93 B.6 Transmitting Alert Service Centre Request ............................................................................... 95 B.7 Receiving Get IMSI Request ................................................................................................... 96

Figures Figure 1: Single SWS ...................................................................................................................... 10 Figure 2: Signaling Paths in a Dual Resilient Configuration ................................................................... 11 Figure 3: Single SWS Connected to SSP/SCP or STP ........................................................................... 11 Figure 4: SWS Dual Configuration with Connections to SSP/SCP ........................................................... 12 Figure 5: SWS Dual Configuration with Connections to STP .................................................................. 12 Figure 6: SWS Dual Configuration with Connections to Mated STP Pair ................................................. 13 Figure 7: Module IDs for Use with Multiple Network Contexts .............................................................. 14 Figure 8: Interfaces ........................................................................................................................ 17 Figure 9. Sending an SMS (Network Diagram) .................................................................................... 19 Figure 10: Sending an SMS (Full Message Flow without Report SM Delivery) .......................................... 24 Figure 11: Sending an SMS (Full Message Flow with Report SM Delivery) .............................................. 25 Figure 12: Receiving an SMS ............................................................................................................ 26 Figure 13: Sending a concatenated SMS ............................................................................................ 29 Figure 14: Receiving a concatenated SMS .......................................................................................... 30 Figure 15: Transmitting an Atomic MT-SMS........................................................................................ 33 Figure 16: Transmitting a Concatenated atomic MT-SMS ..................................................................... 35 Figure 17: Transmitting a Send Routing Info For SM ........................................................................... 36 Figure 18: Transmitting a Report SM Delivery .................................................................................... 37 Figure 19: Transmitting a Ready For SM ............................................................................................ 38 Figure 20: Receiving a Send Routing Info For SM ................................................................................ 40 Figure 21: Receiving Alert Service in Auto Mode ................................................................................. 41 Figure 22: Receiving Alert Service in Abort Mode ................................................................................ 42 Figure 23: Receiving an Alert Service Request in Manual Mode ............................................................. 42 Figure 24: Mobile Originated USSD session ........................................................................................ 44 Figure 25: Application Originated USSD session .................................................................................. 46 Figure 26: Application Originated USSD session – with USSD Notify ...................................................... 47 Figure 27: Sending a USSD Notify..................................................................................................... 48 Figure 28: Requesting a mobile location ............................................................................................ 49 Figure 29: Requesting a mobile subscriber state ................................................................................. 50 Figure 30: Requesting the IMSI from the HLR..................................................................................... 51 Figure 31: Java SMS Test Sender...................................................................................................... 71 Figure 32: C# Test Sender ............................................................................................................... 72

Contents

6

Figure 33: PHP Test Sender ............................................................................................................. 73 Figure 34: Receiving a Send Routing Info For SM................................................................................ 88 Figure 35: Receiving a Ready For SM ................................................................................................ 89 Figure 36: Receiving a Report SM Delivery ......................................................................................... 91 Figure 37: Receiving a Location Request ............................................................................................ 92 Figure 38: Receiving a subscriber state Request ................................................................................. 93 Figure 39: Transmitting a Alert Service Centre ................................................................................... 95 Figure 40: Receiving a Get IMSI Request ........................................................................................... 96


7

1 Introduction

The Dialogic® DSI Signaling Interface for Web-Services (SWS) allows access to SS7 and SIGTRAN signaling functionality via the use of a set of web-services high-level APIs. This document focuses on defining the APIs, offering information about developing new applications and providing details of the sample applications that are used to show the API being implemented.

1.1 Signaling Service Support The services supported are focused on three areas:

Short Messaging (SMS)

This provides the ability to send SMS messages to mobile devices based on the mobile number with a simple API call. It enables SMS advertisements,

SMS information services and many other types of services. The API also supports the reception of SMS messages to enable SMS voting applications or activation of other services via SMS.

The normal SMS API call will both perform a routing look-up and send the SMS. If the user requires further control of the separate parts of this procedure then a set of 'atomic' API calls are available to support this.

Unstructured Supplementary Service Data (USSD)

The Unstructured Supplementary Service Data (USSD) function is part of the GSM mobile specifications and permits arbitrary data to be sent and received by compatible mobile devices for such services as mobile top-up menus and information retrieval (e.g., what is the mobile device's number). The API

supports both mobile-originated sessions and application-initiated sessions.

Location Based services

The SWS allows the application to request the location of a mobile station using the MSISDN number via mobile network access. of the mobile station will be returned in the response, giving its longitude and latitude.

1.2 Feature Overview

High Level Application API – simplified interface

Lowers SS7 / GSM MAP protocol knowledge required

Focuses on enabling common services to mobile devices

XML / HTTP Web Service API

Client systems not restricted in language/OS support

Wide range of tool support

1.3 Abbreviations ANSI American National Standards Institute

1 Introduction

8

GPRS General Packet Radio Service

ITU-T International Telecommunication Union (formerly CCITT)

MAP Mobile Application Part

MTP Message Transfer Part

REST Representational State Transfer

SCCP Signaling Connection Control Part

SMS Short Message Service

SWS Dialogic® DSI Signaling Interface for Web-Services

TCAP Transaction Capabilities Application Part

TP Transfer Protocol

USSD Unstructured Supplementary Service Data

WS Web-service

1.4 Related Information Refer to the following for related information:

Dialogic® DSI Signaling Servers SS7G41 Operators Manual

Dialogic® DSI Signaling Servers SS7G41 Hardware Manual

Dialogic® DSI Components Software Environment Programmer’s Manual

The following manual(s) should be read depending on the protocol options installed on the server:

SCCP Programmer’s Manual

TCAP Programmer’s Manual

MAP Programmer’s Manual

SCTP Programmer’s Manual

M3UA Programmer’s Manual

M2PA Programmer’s Manual

MAP GSM specifications

3GPP TS 23.040

3GPP TS 23.030

3GPP 29.002

This manual is applicable to SS7G41 with SWS Mode Release 1.3.0 or later.


9

2 SWS Mode Overview

2.1 Architecture Overview The Dialogic® DSI Signaling Server for Web-Services (SWS) allows client applications to offer services which make use of SMS, USSD and location

functionality. The SWS unit connects into SS7 or SIGTRAN networks and provides APIs to allow one or more instance of a client application to control this functionality. The SS7 configuration parameters are specified in a text file contained within each SWS.

A complete system requires, in addition to the SWS unit, at least one active

client application. The client applications communicate with the SWS using a web-service interface. For a description of the client applicator development

APIs. Refer to section 3 Web Services APIs.

2 SWS Mode Overview

10

2.1.1 Signaling Topologies

A single SWS may be used standalone, or two units may be configured in a dual resilient configuration. Each SWS may support one or more application (host) computers.

The host computer contains the physical resources controlled by the

signaling, such as voice circuits and databases. The SWS extracts SS7 information and conveys it to the application software, which can control the resource accordingly and issue the required responses to the SWS for transport over the SS7 network.

The minimal system consists of a single SWS connected to a single host via

Ethernet as illustrated below. Dashed lines indicate optional equipment.

Figure 1: Single SWS


11

This system may be scaled up at initial system build time or later to a dual resilient configuration connected to the maximum number of hosts supported. See the figure below:

Figure 2: Signaling Paths in a Dual Resilient Configuration

The SWS may connect to a number of adjacent signaling points, the

maximum number being limited only by the maximum number of link sets supported by the unit. The adjacent SS7 nodes may be Signaling Transfer Points (STPs), Signaling Switching Points (SSPs) or Signaling Control Points (SCPs). The following diagrams indicate possible configurations, although these are not exhaustive. The figure below shows a single SWS connected to an adjacent SSP/SCP and/or STP.

Figure 3: Single SWS Connected to SSP/SCP or STP

In a dual resilient configuration, the SWS pair share the same SS7 point code. The figure below shows an SWS pair connected to a single adjacent SSP/SCP.

2 SWS Mode Overview

12

Figure 4: SWS Dual Configuration with Connections to SSP/SCP

The SWS pair may also be connected to a single adjacent STP (or

combination of SSP and STP) as shown below:

Figure 5: SWS Dual Configuration with Connections to STP

The figure below shows an SWS pair connected to a “mated” STP pair. In this configuration, all the links from the first STP must be terminated at SWSA and all the links from the second STP must be terminated at SWSB.


13

Figure 6: SWS Dual Configuration with Connections to Mated STP Pair

2.2 Multiple Network Support The SS7 Network Context together with a signaling point code uniquely

identifies an SS7 node by indicating the specific SS7 network it belongs to. The Network Context may be a unique identifier for a physical SS7 network, for example, to identify an ANSI, ITU, International or National network, or it may be used to subdivide a physical SS7 network into logical sub-networks.

The Signaling Server supports up to four Network Contexts where each Network Context is a different network or different independent local point code within the same network. Selection of which Network context to use is

made when configuring an SWS Profile.

In the configuration commands or MMI commands, Network Contexts are designated NC0, NC1, NC2 or NC3.

2.2.1 Protocol Handling for Multiple Network Contexts

The figure below shows the use of multiple Network Contexts from an

application perspective and provides examples of the module IDs for the various application layers.

2 SWS Mode Overview

14

Figure 7: Module IDs for Use with Multiple Network Contexts


15

2.2.2 Inter-SWS Communications

In a dual resilient configuration (one unit nominated as SWSA, the other as SWSB), two physically independent communication channels exist between the two units.

Control information is exchanged over the Ethernet. Signaling messages are

exchanged (when necessary) over an inter-SWS SS7 link set, which must be configured for correct dual resilient operation.

The preferred route for messages transmitted from an SWS is over the links connecting that unit to the appropriate adjacent point code (a point code that is either the final destination or a route to the final destination). If no

signaling link to an appropriate adjacent point code is available, the transmit

traffic is passed to the other SWS via the inter-SWS link set. If the inter-SWS link set fails, transmit messages fall back to being passed over the Ethernet.

If the inter-SWS link set fails (causing the Ethernet link to be used for transmitted messages), message loss may occur at the point where the preferred route fails.

The SS7 network is free to deliver received messages to either SWS. Special processing at the User Part level ensures that any message received for a call

or transaction being handled by the other unit is routed over the Ethernet.

The inter-SWS link set is configured in the same manner as normal link sets, for details, refer to Configuration in the Dialogic® DSI Signaling Servers SS7G41 Operators Manual.

The inter-SWS link set may consist of one or more signaling links configured on one or more signaling ports (T1/E1), distributed between one or more signaling boards. Resilience on the Inter SWS link set may be achieved by

configuring two links in the inter-SWS link set, each on a separate signaling board. The inter-SWS link may also be conveyed over M2PA or M3UA avoiding the requirement for a TDM link and cabling between the units.

2.2.3 Transaction-Based Applications

Applications that need to exchange non-circuit related information over the SS7 network (such as for the control of a Mobile Telephone Network or for an Intelligent Network application) do so by exchanging information between sub-systems using the services of SCCP. A sub-system is an entity that exchanges data with other entities by using SCCP.

The SWS provides the capability to configure local sub-systems and routing to remote resources. The intelligent functionality of each local sub-system is

provided by the user application running on one or more host computers.

2.2.4 Management of Local SCCP Sub-Systems

The SWS system automatically brings local SCCP sub-systems into service, no application interaction is required.

2 SWS Mode Overview

16

2.2.5 Alarms

The Dialogic® DSI Signaling Server products are able to detect a number of events or alarm conditions relating to either the hardware or the operation of the protocols. Each alarm condition is assigned a severity/class (3=Critical, 4=Major, 5=Minor) and a category and ID, which give more detail about the

alarm. There are a number of mechanisms described below, by which these conditions can be communicated to management systems, and ultimately to the system operator. See Alarm Listing in the Dialogic® DSI Signaling Servers SS7G41 Operators Manual for a list of alarm types, and their reporting parameters.

Active alarms are indicated on the front panel of the Signaling Server with

three LEDs identifying severity; CRT, MJR, MNR.

Active alarms may be indicated remotely from the Signaling Server when the alarm relay outputs are connected to a remote management system.

Alarm events (occurrence and clearing, class, category and ID) may be reported via Management messages to the host application thus permitting remote monitoring and/or logging.

Alarm events may be reported to an SNMP manager. SNMP support is

described in SNMP in the Dialogic® DSI Signaling Servers SS7G41 Operators Manual.

A system operator can obtain a listing of the current alarm status (CLA, CATEGORY, ID and TITLE) using the ALLIP management terminal command described in ALLIP in the Dialogic® DSI Signaling Servers SS7G41 Operators Manual. Test Critical, Major, or Minor may be activated using the ALTEI management command and cleared using the ALTEE

management command.

2.3 Interfaces The SWS offers a number of interfaces, which are described below:


17

Web Services

Application

Application

Manager

Management

Terminal (MMI)

Dialogic®

DSI

Signaling

Interface for Web

Services

Telnet OA&M

Web B

rowser

App O

A&M

We

b S

erv

ice

s

AP

P A

PI

Figure 8: Interfaces

2.3.1 Application Interface

This interface allows client systems to make use of the high-level service-specific API to simplify access to signaling services in the mobile network.

This is done via a web-service API, as detailed Web Services APIs.

2.3.2 Configuration Interface

The SWS can configure many aspects of system operation and signaling functionality. Such configuration is performed for the SS7 stack via a static configuration file on the SWS system. The control of the high-level API and

API service specific functionality is provided via a Web-services based interface, which can be controlled in a browser.

2 SWS Mode Overview

18

Note: System configuration ins described in detail in the Dialogic® DSI Signaling Servers SS7G41 Operators Manual.

2.3.3 Management Interface, Trace, and Diagnostics

The SWS can provide tracing and diagnostic information from modules in the system. This can include tracing at different levels of the protocol stack. The

Man-Machine Interface (MMI) can also be used to provide status and statistics from the system.

Tracing of the Web-service API can be achieved via tools such as Wireshark run on the client system.

2.3.4 Network Interfaces

Internal to the SWS system, the high-level API makes use of other layers of the SS7 stack such as MAP, TCAP and SCCP. The SWS will also connect to the signaling network via the TDM SS7 MTP3 module or SIGTRAN modules such as M3UA or M2PA.


19

3 Web Services APIs

3.1 Overview The web-services interface uses HTTP with an XML payload using a REST architecture. This makes it suitable for implementation on a large number of

client systems using different OSs, languages and frameworks. The diagram below shows an example usage of the SWS with the network elements and message flow.

Network B

Network A

Client

Application

MSC/VLR

HLR

Mobile

Mobile

DSI SWS

BSS

MSC/VLR

HLR

BSS

1 2

3

4

5

67

8

Figure 9. Sending an SMS (Network Diagram)

1 – SMS Request (HTTP PUT)

2 – Send Routing Info for SM Request

3 – Routing Response

4, 5 – Forward Short Message (MT)

6, 7 – Forward Short Message Response (MT)

8 – SMS Response (HTTP PUT Response – 204 No Content)

3 Web Services APIs

20

3.2 Summary

3.2.1 Supported URIs / Methods

All URIs are preceded by the domain and root “/dialogicwebservice/signaling” or “/dialogicwebservice/signaling/profile/<profile_name> (only the initial message should contain the profile). See Section 7 - Profiles and Multiple Network Support for further details on profile support.

If the profile resource is absent then this is equivalent as using the profile for the service with ID that matches 0.

URL Method Action

/<msisdn>/sms PUT Requests an SMS be transmitted

/<msisdn>/sms POST Requests an SMS be transmitted and maintain a dialog open for further SMS to the same mobile.

/<msisdn>/sms/<sessionid> PUT Continuation of an SMS to be transmitted

/sms GET Receive new SMS

/sms/<sessionid> GET Continuation of receiving an SMS

/<msisdn>/smsmo PUT Requests a mobile originated SMS be

transmitted

/smsmp GET Receive a new mobile originated SMS

/<msisdn>/location GET Requests location information

/ussd POST Requests setup of a new application initiated USSD session and a session id is returned.

/ussd GET Receive new mobile initiated USSD session. A session id is returned.

/ussd PUT Sends USSD data to mobile without creating a session using a USSD Notify

/ussd/<sessionid> PUT Sends data, response contains user reply

/ussd/<sessionid > DELETE Ends or aborts a session

/<msisdn>/sriforsm GET Requests a Send Routing Info For Short Message to be transmitted

/alertsc GET Requests a new service centre alert

/<msisdn>/readyforsm PUT Requests a new Ready For SM to be transmitted

/<msisdn>/smsmt PUT Requests an atomic mobile terminated SMS to be transmitted

/<msisdn>/reportsmdeliver PUT Requests a report SM Deliver to be transmitted

All others ANY Return Status 404: Not Found


21

Example:

To send an SMS to the mobile number +44 7777 123456, call an HTTP PUT with the URI:

http://192.168.0.1/dialogicwebservice/signaling/447777123456/sms

To send an SMS to the mobile number +44 7777 123456 using profile TX_SMS_0, call an HTTP PUT with the URI:

http://192.168.0.1/dialogicwebservice/signaling/profile/TX_SMS_0/

447777123456/sms

Note: The MSISDN should include the country code but should not include a ‘+’ or other leading dial prefix.

3.2.2 Payload Structure

The payload is XML encoded with the following general form. This includes a version identifier used to aid compatibility between schema versions. The encoding scheme expected in requests and used by the SWS is UTF-8.

<?xml version="1.0" encoding=’UTF-8’?>

<primitive_type version=”n”>

<parameter1> </parameter1>

<parameter2> </parameter2>

</primitive_type>

3.2.3 HTTP Response Codes

The following set of HTTP response codes are used

Response Code

HTTP Meaning Used when

200 OK Request was processed successfully; the result of the request is contained within the XML body of the response

201 Created Session created

204 No Content Request was successful; no additional content required

400 Bad Request The request could not be parsed

401 Unauthorized A required authentication method was not used

403 Forbidden Invalid resource requested

404 Not Found An invalid method was requested

500 Internal Server Error

The requested method could not be performed due to an error detected at the server

504 Gateway Timeout Service timed-out at the server

3 Web Services APIs

22

3.3 MAP Services Used The SWS system makes use of a number of GSM MAP Services implemented in the underlying SS7/SIGTRAN stack. The table below summarizes these

services used.

API Call Method MAP

Services Used

Notes

/<msisdn>/sms PUT SendRoutingInfoForSM

ForwardSM

ReportSMDelivery

ReportSMDelivery is only sent if configured.

/<msisdn>/sms POST SendRoutingInfoForSM

ForwardSM

/<msisdn>/sms/<sessionid> PUT ForwardSM

ReportSMDelivery

ReportSMDelivery is only sent if configured.

/sms GET ForwardSM

/sms/<sessionid> GET ForwardSM

/<msisdn>/smsmo PUT ForwardSM MO

/smsmo GET ForwardSM MO

/<msisdn>/location GET AnyTime Interrogation

/ussd POST USSD Request

/ussd GET ProcessUnstructred

USSD Request

/ussd PUT USSD Notify

/ussd/<sessionid> PUT USSD Request / Notify

/ussd/<sessionid > DELETE TCAP-End

/<msisdn>/sriforsm GET SendRoutingInfoForSM

InformSC

InformSC is processed if received from the network in response to the send routing info request

/alertsc GET AlertSerivceCentre

/<msisdn>/readyforsm PUT ReadyForSM

NoteSubscriberPresent

ReadyForSM is sent by default, but if configured NoteSubscriberPresent can be sent instead (Version 1 Operation)

/<msisdn>/smsmt PUT ForwardSM

/<msisdn>/reportsmdeliver PUT ReportSMDelivery


23

4 Short Message API

The SMS API has two methods, one for permitting the transmission of an SMS message to a mobile device and the second for reception of a message by the SWS system.

URL Method Action

/<msisdn>/sms PUT Requests an SMS be transmitted

/<msisdn>/sms POST Requests an SMS be transmitted and maintain a dialog open for further SMS to the same mobile.

/<msisdn>/sms/<sessionid> PUT Continuation of an SMS to be transmitted

/sms GET Receive new SMS

/sms/<sessionid> GET Continuation of receiving an SMS

/<msisdn>/smsmo PUT Requests a mobile originated SMS be

transmitted

/smsmp GET Receive a new mobile originated SMS

/<msisdn>/sriforsm GET Requests a Send Routing Info For Short Message to be transmitted

/alertsc GET Requests a new service centre alert

/<msisdn>/readyforsm PUT Requests a new Ready For SM to be transmitted

/<msisdn>/smsmt PUT Requests an atomic mobile terminated SMS to be transmitted

/<msisdn>/reportsmdeliver PUT Requests a report SM Deliver to be transmitted

4.1 Sending an SMS To send an SMS message to a mobile device use the mobile number in the

URI and an HTTP PUT as shown in Figure 10: Sending an SMS (Full Message Flow without Report SM Delivery):

4 Short Message API

24

Client SWS Mobile

Foward Short Message

Forward Short Message - Reponse

PUT

HLR VLR/MSC

Send Routing Info for SM

Send Routing Infor for SM - Reponse

Figure 10: Sending an SMS (Full Message Flow without Report SM Delivery)

When sending the SMS in step 1, the payload XML should have the form

shown below. See Chapter 10, “XSD Files” for the supporting XSD schema.

MT-FORWARD-SHORT-MESSAGE-TX-REQ

<?xml version="1.0" encoding="utf-8"?>

<!—- Example SMS sent -->

<sms version="1">

<message encodingScheme="0" language="en-GB">Hello</message>

<dest noa="1" np="1">447777123456</dest>

<orig noa="1" np="1">447777654321</orig>

</sms>

In the response there will be an appropriate response code, as shown in section 3.2.3 HTTP Response Codes.

Note: The 204 – No Content response code is the expected response to a successfully sent SMS message.

If the error code is returned, it will take the following form:

25




<error>

<code type=”MapUserError”>SystemFailure</code>

<text>TX-MO-SMS(FSM) System Failure</text>

</error>

4.1.1 Support for Report SM Delivery

It is possible to set the SWS system to send an automatic report SM Delivery

to the HLR via the configuration option “Automatic ReportSMDelivery” on the Web MMI. This optional can be found under “System Administration -> MAP Services -> SMS -> Configuration”. It can also be set using the equivalent

MMI command MASMS and the RDEL parameter.

Client SWS Mobile


Forward Short Message - Reponse

200 - OK

PUT

HLR VLR/MSC



Report SM Delivery

Report SM Delivery - Reponse

Figure 11: Sending an SMS (Full Message Flow with Report SM Delivery)

4 Short Message API

26

4.2 Receiving an SMS To collect the next outstanding SMS message received by the SWS use a HTTP GET with a URI of the form as shown below in Figure 12: Receiving an

SMS

HTTP GET

http://192.168.0.1:81/dialogicwebservice/signaling/sms

Client SWS Mobile

Foward Short Message - Response

Forward Short Message200 - OK

GET

Figure 12: Receiving an SMS

The response should include a 200 OK for success. In other cases an appropriate response code will be used as shown in section 3.2.3 HTTP Response Codes.

The returned response will have XML payload of the following form:




<sms version="1">

<message">Goodbye</message>

<orig ton="International" np="ISDN">447777654321</orig>

<imsi>987654321</imsi>

</sms>

Alternatively an HTTP response code, error codes and text will be returned.


27

4.3 Sending a binary format SMS In order to support services requiring more control over the SMS and the format it is sent in the API also supports direct control over the SMS-Deliver

short message transfer protocol data unit as defined in the GSM specifications such as 3GPP TS 23.040 version 9.3.0 Release 9.

In order to send using this format the message element should be replaced with the smsDeliver element. This element is a compound parameter made up of the TP sub-parameters defined to match those in the SMS Deliver structure in the GSM specifications. The TP-UD parameter contains the Unit

Data of the SMS encoded as Base 64. The other elements of the smsDeliver

element control the formatting and additional data relating to the SMS payload.

An example of this format is shown below. These elements are specified in more detail in section 8.1.1.

<?xml version="1.0" encoding="UTF-8"?>

<sms version="1">

<dest ton="Subscriber" npi="ISDN">447777123456</dest>

<smsDeliver>

<mms>false</mms>

<rp>false</rp>

<udhi>false</udhi>

<udl>57</udl>

<sri>true</sri>

<dcs>0</dcs>

<pid>4</pid>

<scts>EUBgAhFyAA==</scts>

<ud>zLe83Aal4fN6G0R+s99y0DxNB4XbZToLNH675+UxvUyvy0FhchqenqfHafcZV

Gan6S4=</ud>

</smsDeliver>

</sms>

4 Short Message API

28

4.4 Receiving a binary format SMS The SWS can also receive messages in a binary SMS format.

The SMS Service Options section of the SMS Configuration Tab of the web

management interface contains a control which selects the handling of non-simple text SMS. The control has the following meaning

Receive only SMS text:

All SMS which can be returned using the simple message format will be sent in that format. All other SMS will be sent as binary SMS format.

Receive SMS network headers

All SMS will be returned as binary format using the smsDeliver element.

The parameters and meanings are the same as for the sending of binary format SMS.


<sms version="1">

<orig ton="International" npi="ISDN">447777654321/orig>

<imsi>987654321</imsi>

<smsDeliver>

<mms>false</mms>

<rp>false</rp>

<udhi>false</udhi>

<udl>57</udl>

<sri>true</sri>

<dcs>0</dcs>

<pid>4</pid>

<scts>EUBgAhJlAA==</scts>


Gan6S4=</ud>

</smsDeliver>

</sms>


29

4.5 Sending a concatenated binary format SMS

Figure 13: Sending a concatenated SMS

In order to send a user concatenated message the user must be making use of the binary message format as discussed in section 4.3. In order to request additional messages to be sent in the same dialog the client application should set the mms (More Messages to Sent) parameter to ‘true’. When the SWS responds to the initial SMS being sent it will then include a session identifier which can be used to link later SMS requests to the first. The last

message in the dialog should be sent with the mms parameter set to ‘false’.

The URIs used for a two concatenated SMS would be as follows:

HTTP POST

http://<server>:81/dialogicwebservice/signaling/<msisdn>/sms

HTTP PUT

http://<server>:81/dialogicwebservice/signaling/<msisdn>/sms/<ses

sionId>

For example:

4 Short Message API

30

HTTP POST

http://192.168.0.1:81/dialogicwebservice/signaling/447777123456/s

ms

HTTP PUT


ms/5

Note: The MMS (More Messages to Send) field in the SMS-Deliver TP parameter takes the value of 1 in the encoded message sent over the SS7 link or SIGTRAN association if there are no more messages to send. A value of 0 indicates there are more messages to send. The SWS API uses a value of ‘true’ when there are more messages and ‘false’ when there are no more messages to send.

4.6 Receiving a concatenated binary format SMS

Client SWS Mobile


Forward Short Message (More Messages)200 - OK

GET (sms)


Forward Short Message (No More Messages)200 - OK

GET (sms/<sessionId>)

Figure 14: Receiving a concatenated SMS

Receiving a concatenated SMS takes a similar approach to that of sending a concatenated SMS in that a session id is returned in order to allow related concatenated SMS to be returned together and collected from the SWS.

The URIs used for receiving two concatenated SMS would be as follows:

HTTP GET

http://<server>:81/dialogicwebservice/signaling/sms

HTTP GET

http://<server>:81/dialogicwebservice/signaling/sms/<sessionId>

For example:


31

HTTP GET

http://192.168.0.1:81/dialogicwebservice/signaling/sms

HTTP GET

http://192.168.0.1:81/dialogicwebservice/signaling/sms/5

4.7 Mobile Originated SMS Transmitting or Receiving Mobile Originated SMS must be performed using the binary format (see sections 4.3 and 4.4).

In order to send a mobile originated SMS the user must use the SMS-Submit

short message transfer protocol data unit as defined in the GSM specifications such as 3GPP TS 23.040 version 9.3.0 Release 9.

The following is an example of this format. These elements are specified in

more detail in Section 8.1 SMS Service.

Example

HTTP PUT


msmo


<sms version="1">


<msc ton="International" npi="ISDN">32143332542/msc>

<destSrvCtr ton="Unknown" npi="ISDN">4235432543/destSrvCtr>

<dest ton="International" npi="ISDN">447777654322/dest>

<smsSubmit>

<rd>false</rd>

<rp>false</rp>

<udhi>false</udhi>

<udl>57</udl>

<srr>true</srr>

<mr>2</mr>

<dcs>0</dcs>

<pid>4</pid>

<tpRel>20</tpRel>


Gan6S4=</ud>

</smsSubmit>

</sms>

http://192.168.0.1:81/dialogicwebservice/signaling/447777123456/smsmo

http://192.168.0.1:81/dialogicwebservice/signaling/447777123456/smsmo

4 Short Message API

32

Receiving an MO-SMS is similar to receiving a binary message as discussed in section 4.4 Receiving a binary format SMS.

HTTP GET

http://192.168.0.1:81/dialogicwebservice/signaling/smsmo


<sms version="1">


<msc ton="International" npi="ISDN">32143332542/msc>

<destSrvCtr ton="Unknown" npi="ISDN">4235432543/destSrvCtr>

<dest ton="International" npi="ISDN">447777654322/dest>

<smsSubmit>

<rd>false</rd>

<rp>false</rp>

<udhi>false</udhi>

<udl>57</udl>

<srr>true</srr>

<mr>2</mr>

<dcs>0</dcs>

<pid>4</pid>

<tpRel>20</tpRel>


Gan6S4=</ud>

</smsSubmi

4.8 Sending Atomic MT-SMS To send an SMS message to a mobile device use the mobile number in the URI and an HTTP PUT as shown below in Figure 15: Transmitting an Atomic

MT-SMS:

http://192.168.0.1:81/dialogicwebservice/signaling/smsmo


33

Client SWS Mobile


Forward Short Message - Reponse200 - OK

PUT

HLR VLR/MSC

Figure 15: Transmitting an Atomic MT-SMS

HTTP PUT


msmt

The payload XML should have the form shown below. See Appendix A.1 for the supporting XSD schema.

MT-FORWARD-SHORT-MESSAGE-TX-REQ


<!—- Example SMS sent -->

<smsmt version="1">

<message>Hello</message>

<imsi>5012423432</imsi>

<msc ton="International" np="ISDN">440044001122</msc>

<orig ton="International" np="ISDN">447777654321</orig>

</smsmt>

In the response there will be an appropriate response code, as shown in section 3.2.3.

The 204 – No Content response code is the expected response to a successfully sent SMS message. If an error response code is returned, it will have payload of the following form:



<error>


<text>Error Text</text>

</error>

4 Short Message API

34

4.9 Sending a binary format Atomic MT-SMS In order to send a user concatenated message the user must be making use of the binary message format as discussed in section 4.3.

An example of this format is shown below. These elements are specified in more detail in section 8.1.1.


<smsmt version="1">

<imsi>234153121235437</imsi>


<smsDeliver>

<mms>false</mms>

<rp>false</rp>

<udhi>false</udhi>

<udl>57</udl>

<sri>true</sri>

<dcs>0</dcs>

<pid>4</pid>

<scts>EUBgAhFyAA==</scts>


Gan6S4=</ud>

</smsDeliver>

</sms>


35

4.10 Sending Concatenated Atomic MT-SMS

Client SWS Mobile



POST (smsmt)

HLR VLR/MSC

PUT (smsmt/sessionid) Foward Short Message


Figure 16: Transmitting a Concatenated atomic MT-SMS

In order to send a user concatenated message the user must be making use of the binary message format as discussed in section 4.3. In order to request additional messages to be sent in the same dialog the client application should set the mms (More Messages to Sent) parameter to ‘true’. When the SWS responds to the initial SMS being sent it will then include a session identifier which can be used to link later SMS requests to the first. The last

message in the dialog should be sent with the mms parameter set to ‘false’.

The URIs used for a two concatenated SMS would be as follows:

HTTP POST

http://<server>:81/dialogicwebservice/signaling/<msisdn>/smsmt

HTTP PUT

http://<server>:81/dialogicwebservice/signaling/<msisdn>/smsmt/<s

essionId>

4 Short Message API

36

For example:

HTTP POST


msmt

HTTP PUT


msmt/5

4.11 Sending Atomic Send Routing Info For SM A client can request that a Send Routing Info For SM be used sent to the HLR. This uses a HTTP PUT request and similar XML payload to the other SMS APIs. See the Figure 27: Sending a USSD Notify below:

Client SWS

200 - OK

PUT

HLR



Figure 17: Transmitting a Send Routing Info For SM

HTTP PUT

http://192.168.0.1:81/dialogicwebservice/signaling/<msisdn>/srifo

rsm

The payload is optional depending on whether the default Type of Number or the Numbering Plan needs to be overridden or any optional fields are required, if so then the XML should have the form shown below. See

Appendix A.1 for the supporting XSD schema.

SEND-ROUTING-FOR-SM-TX-REQ


<!—- Example SRI sent -->

<sriForSm version="1">

<msisdn ton="International" np="ISDN">447777654321</msisdn>

</sriForSm >

The response should include a 200 OK for success. In other cases an appropriate response code will be used as shown in section 3.2.3.


37





<imsi>5012423432</imsi>


</sriForSm>

4.12 Sending Atomic Report SM Delivery A client can request that to transmit a Report SM Delivery to be used sent to the HLR. This uses a HTTP PUT request and similar XML payload to the other SMS APIs. See the Figure 27: Sending a USSD Notify below:

Client SWS

200 - OK

PUT

HLR

Report SM Delivery

Report SM Delivery - Response

Figure 18: Transmitting a Report SM Delivery

HTTP PUT

http://192.168.0.1:81/dialogicwebservice/signaling/<msisdn>/repor

tSMDeliver

The payload is required and the XML should have the form shown below. See Appendix A.1 for the supporting XSD schema.

4 Short Message API

38

REPORT-SM-DELVIER-TX-REQ



<reportSMDeliver version="1">


<deliveryOutcome>successfulTransfer</deliveryOutcome>

</reportSMDeliver>

The 204 – No Content response code is the expected response to a successfully sent Report SM Delivery message, unless the HLR returns a Stored MSISDN in which case a 200-OK will be returned containing the MSISDN. If an error response code is returned, it will have payload of the

following form:



<error>



</error>

4.13 Sending Atomic Ready For SM A client can request that to transmit a Ready For SM (Note Subscriber Present MAP Version 1) to be used sent to the HLR. This uses a HTTP PUT request and similar XML payload to the other SMS APIs. See the Figure 27: Sending a USSD Notify below:

Client SWS

200 - OK

PUT

HLR

Ready For Sm

Ready For Sm - Response

Figure 19: Transmitting a Ready For SM

The payload is required and the XML should have the form shown below. See Appendix A.1 for the supporting XSD schema.


39

Client SWS

200 - OK

GET

SMSC


Send Routing Info for SM - ResponsePUT

200 - OK

READY-FOR-SM-TX-REQ



<readyForSm version="1">

<imsi>234153121235437</imsi>

<alertReason>msPresent</alertReason>

<hlrAddr ton="International" np="ISDN">440044001122</ hlrAddr >

</readyForSm>

The 204 – No Content response code is the expected response to a successfully sent Report SM Delivery message. If an error response code is returned, it will have payload of the following form:



<error>



</error>

4.14 Receiving Atomic Send Routing Info For SM

A client can request to receive a Send Routing Info For SM. This uses a HTTP GET request to receive the request, to respond to the request the HTTP Put request is used

4 Short Message API

40

Figure 20: Receiving a Send Routing Info For SM

HTTP GET

http://192.168.0.1:81/dialogicwebservice/signaling/sriforsm

This will retrieve the first available Send Routing Info For SM, there is no

payload associated with the initial request







<sessionId>4</sessionId>

</sriForSm>

The Client then should return the response to the Send Routing Info request using a PUT request and specifying the sessionId that the request is associated with.

HTTP PUT

http://192.168.0.1:81/dialogicwebservice/signaling/sriforsm/4

If the request is successfully acknowledged then a payload containing the required data shall be included with the HTTP request





<imsi>5012423432</imsi>


<sessionId>4</sessionId?

</sriForSm>

If the request is negatively acknowledged then the payload will contain the

relevant error code


41



<error>



</error>

4.15 Receiving an Alert Service Centre SWS for alert service centre can be configured in the following options:

MAN - The Client will request alert service centre requests from the

network. If no requests are received then an error is returned to the HLR

AUTO - SWS will automatically send back the successful response to the Alert Service Centre Request from the HLR with no interaction from the user.

ABORT - SWS will automatically abort all Alert Service Centre Requests from the HLR.

The message sequence below shows the Auto mode.

Figure 21: Receiving Alert Service in Auto Mode

The message sequence below shows the Abort mode.

4 Short Message API

42

Figure 22: Receiving Alert Service in Abort Mode

In the Manual Mode the user must request an Alert Service Centre from the HLR using the HTTP GET request. The 200-OK will contain the contains of the Alert Service Centre request received from the HLR and will acknowledge the

Alert Service Centre request back to the HLR. The Manual Mode is shown in the figure below:

Figure 23: Receiving an Alert Service Request in Manual Mode

The response should include a 200 OK for success. In other cases an appropriate response code will be used as shown Section 3.2.3 HTTP Response Codes.



43



<alertsc version="1">

<msisdn ton="International" np="ISDN">447777654321</orig>

</alertsc>

5 USSD API

44

5 USSD API

This API allows USSD sessions to be locally initiated or initiated by the mobile device.

URL Method Action

/ussd POST Requests setup of a new application initiated USSD session and send data to the mobile

/ussd GET Receives new ussd session. A session id is returned

/ussd PUT Sends USSD data to mobile without creating a session using a USSD Notify

/ussd/<sessionid> PUT Sends data, response contains user reply

/ussd/<sessionid > GET Receives data

/ussd/<sessionid > DELETE Ends session

5.1 Mobile Initiated Sessions Figure 24: Mobile Originated USSD session below shows a Mobile Originated USSD session:

Client Application SWS Mobile

GET

PUT

PUT + Close Indicator

Process USSD Request

USSD Request

Process USSD Request - Result

USSD Request - Result

200 - OK

204 - No Content

200 - OK

Figure 24: Mobile Originated USSD session

A client requests the next outstanding new mobile initiated session by calling GET on “…/ussd”.


45

HTTP GET

http://192.168.0.1:81/dialogicwebservice/signaling/ussd


<ussd version="1">

<msisdn>447777123456</msisdn>

<alertingPattern>1</alertingPattern>

<ussdString dataCodingScheme="1">Text Here</ussdString>


</ussd>

A session id is returned.

Subsequent data sent to that mobile for the same session uses PUT on “…/ussd/<sessionId>”

HTTP PUT

http://192.168.0.1:81/dialogicwebservice/signaling/ussd/987654321

The response to the PUT contains the response from the mobile device.

Data can be sent back and forth using further PUT and PUT responses.

The session is ended by using the close indication in the PUT.

A DELETE can be used to force the session to end at any time.

HTTP DELETE

http://192.168.0.1:81/dialogicwebservice/signaling/ussd/987654321

5 USSD API

46

5.2 Client Application Initiated Session The figure below shows an Application Originated USSD session (Figure 25: Application Originated USSD

session):

Client SWS Mobile

PUT

USSD Request

USSD Request

USSD Request - Result201 - Created or 200 - OK

POST

DELETE

END204 - No Content

USSD Request - Result200 - OK

Figure 25: Application Originated USSD session

A client should request the start of a new client application initiated session by calling POST on “…/ussd”.

HTTP POST


A session id will be returned together with the response from the mobile device.

Subsequent data sent to that mobile for the same session uses PUT on “…/ussd/<sessionId>”


47

The figure below shows an Application Originated USSD session (Figure 26: Application Originated USSD session – with USSD Notify):

:

Client SWS Mobile

PUT (Notify)

USSD Request

USSD Notify

USSD Request - Result201 - Created or 200 - OK

POST

DELETE

END204 - No Content

USSD Notify Response200 - OK

Figure 26: Application Originated USSD session – with USSD Notify

This session is similar to the previous example but is ended by a USSD Notify.

A client requests a Notify by setting a Notify element in the XML payload sent.

HTTP PUT

http://192.168.0.1:81/dialogicwebservice/signaling/ussd/<sId>

5.3 Client Application Initiated - USSD Notify A client can request that a USSD Notification be used to send data to a mobile. This uses a HTTP PUT request and similar XML payload to the other USSD APIs. See the Figure 27: Sending a USSD Notify below:

Client SWS Mobile

USSD Notify

USSD Notify Response200 - OK

PUT

5 USSD API

48

Figure 27: Sending a USSD Notify

HTTP PUT


As a session does not need to be maintained, a session id is not required.

49

6 Location and Subscriber Polling API

6.1 Location API All URIs are precluded by the domain and root “/dialogicwebservices/signaling”

URL Method Action

/<msisdn>/location GET Requests location information

Figure 28: Requesting a mobile location below shows a client requesting a mobile location:

Client SWS Mobile

ATI - Request

ATI - Response200 - OK

GET

Figure 28: Requesting a mobile location

A client requests the location of the mobile device by calling GET on “…/<msisdn>/location”.

HTTP GET

http://192.168.0.1:81/dialogicwebservice/signaling/location

The XML payload returned will include the longitude and latitude.




<location version="1">

<msisdn ton="International" np="ISDN>447777123456</msisdn>

<latitude>37.56509</latitude>

<longitude>-96.38509</longitude>

</location>

6 Location and Subscriber Polling API

50

6.2 Subscriber State API All URIs are precluded by the domain and root “/dialogicwebservices/signaling”

URL Method Action

/<msisdn>/subscriberstate GET Requests subscriber state information

Figure 29: Requesting a mobile subscriber state below shows a client requesting a mobile subscriber state:

Client SWS Mobile

ATI - Request

ATI - Response200 - OK

GET

Figure 29: Requesting a mobile subscriber state

A client requests the location of the mobile device by calling GET on “…/<msisdn>/subscriberstate”.

HTTP GET

http://192.168.0.1:81/dialogicwebservice/signaling/subscriberstat

e

The XML payload returned will include the current subscriber state




<subscriberstate version="1">

<state state="assumedIdle"/>

</subscriberstate>

51

6.3 Get IMSI API All URIs are precluded by the domain and root “/dialogicwebservices/signaling”

URL Method Action

/<msisdn>/getimsi GET Requests imsi from the HLR

The figure below shows the Client requesting the IMSI from the HLR using the MSISDN of the mobile (Figure 29: Requesting a mobile subscriber

state

Client SWS HLR

Send IMSI - Request

Send IMSI - Response200 - OK

GET

Figure 30: Requesting the IMSI from the HLR

A client requests the imsi of the mobile device by calling GET on

“…/<msisdn>/getimsi”.

HTTP GET

http://192.168.0.1:81/dialogicwebservice/signaling/44776663213/ge

timsi

The XML payload returned will include the imsi of the mobile station




<getimsi version="1">

<imsi>3301231232121</imsi>

</getimsi>

7 Profiles and Multiple Network Support

52

7 Profiles and Multiple Network Support

7.1 Introduction to Profiles Profiles are used across the SWS Web Service API to select specific information required to send network traffic or create criteria for receiving

network requests.

It is possible to have up to 100 profiles in total for all services. The creation of profiles is performed using the Web or Command line MMI.

7.2 Transmit Profiles Profiles allow the user to specify information that will be used in outbound network requests. This information will include the GT address that initiates the request (SCCP calling party number), the network context and specific service information (such as default numbering plans).

The user on creating a request can specify the profile that will be used to generate the network request.

Types of transmit profiles:-

Tx MT-SMS – services using this profile include

o Combined MT-SMS

o Atomic Send Routing Info for SM

o Atomic MT-SMS

o Atomic Report SM Delivery

Tx MO-SMS – services using this profile include

o MO-SMS requests

Ready For SM – services using this profile include

o Ready for SM Requests

USSD– services using this profile include

o USSD

Subscriber - – services using this profile include

o Location Service

o Get Subscriber State

o Get IMSI

HLR Tx – services using this profile include

o Alert Service Centre


53

7.3 Receive Profiles Profiles used for the reception of data, the received data from the network must match the criteria specified in the profile for it to match. This

information will normally include the Service Centre Address that the network request was sent to.

When a user requests to receive data matching a profile, only requests that match the requirements will be returned to the user. A user can create profiles that can receive all network requests for a particular service for the same network context or for all network contexts.

If an incoming network requests matches a specific profile completely and also a generalized profile then it can only be received using the specific

profile.

Types of receive profiles:-

Rx MT-SMS – services using this profile include

o Rx Atomic MT-SMS

Tx MO-SMS – services using this profile include

o Rx MO-SMS

o Rx Alert Service Centre

USSD– services using this profile include

o USSD Mobile Initiated

HLR RX – services using this profile include

o Rx Location Request

o Rx Subscriber Request

o Rx Get IMSI

o Rx Send Routing Info for SM

o Rx Report SM Delivery Status

o Rx Ready For SM

8 Parameter Reference

54


The following sections indicate the parameters used by each service and their respective meanings. The ‘Group’ values in the tables have the following meaning:

Group Meaning

T Top level element structure in XML payload

C Compound XML element with sub-elements

E XML Element

A Attribute of the indicated element

The ‘Req’ and ‘Rsp’ values in the tables have the following meaning:

Req/Rsp Meaning

M Parameter is mandatory

O Parameter is optional

C Parameter is conditionally required. The conditions under which it is needed are indicated.

All of the three services (SMS, Location and USSD) may return error indications stored in an Error XML payload, as defined in section 8.11.

8.1 SMS Service

Parameter Group Req Rsp Details

Sms T M M Top level element for SMS request/responses

Version A O O Attribute of sms

Set to 1

Dest E O n/a Destination Mobile Subscriber ISDN Number

Identifies the mobile number of the device that the SMS is to be sent.

Ton A O O Attribute of dest

Type of number

Npi A O O Attribute of dest

Numbering Plan Indicator

Imsi E n/a M International Mobile Subscriber Identity

The IMSI Is a unique identifier of the SIM in the mobile device.

Message E O C1 UTF-8 Encoded text string

Orig E O O Origination Mobile Subscriber ISDN Number

Identifies the mobile number of the device from which the SMS is sent from.

Ton A O O Attribute of orig

Type of number

Npi A O O Attribute of orig



55

sessionId E M for existing session

O Identifies the sms session being handled. This is returned in the first response to a GET or PUT where multiple concatenated messages are required to be sent or received

smsDeliver E C1 O Compound parameter with sub-elements shown in section 8.1.1 SMS

Deliver parameters.

This used to specify SMS messages which cannot be supported by the simple message format, for example binary or concatenated messages.

Note 1 - Either message or smsDeliver should be present

8.1.1 SMS Deliver parameters


mms E M M TP-MMS flag as specified in 23.040

Boolean, true means more messages are to send.

rp E M M TP-RP flag as specified in 23.040

Boolean, true means Reply path exists

udhi E M M TP-UDHI flag as specified in 23.040

Boolean, true means TP-UD contains a header

sri E M M TP-SRI flag as specified in 23.040

Boolean, true means a status report is requested

pid E M M TP-PID as specified in 23.040

Protocol Identifier

Value between 0..255 representing the protocol used.

dcs E M M TP-DCS as specified in 23.040

Data coding scheme


scts E M M TP-SCTS as specified in 23.040

This is the service centre time stamp encoded as Base64.

udl E M M TP-UDL as specified in 23.040

This is the length of the unit data parameter specified in

If the ud parameter is encoded in GSM 7-bit default alphabet then this represents the number of septets used.

If the ud parameter is encoded in GSM 7-bit default alphabet AND the udhi is set the then this represents the number of septets used in the user data header plus the user data field.

If the ud parameter is encoded using 8-bit data then the udl should indicate the number of octets used.

If the ud parameter is encoded using 8-bit data and the udhi is set then the udl should indicate the number of octets used in the header plus the user data field.

ud E M M TP-UD as specified in 23.040

Contains the SMS user data encoded as Base64


56

8.2 Atomic SMS-MT Service


smsmt T M M Top level element for SMS-MT request/responses

version A O O Attribute of sms

Set to 1

msc E O n/a Mobile Switching Centre ISDN Number

Identifies the MSC that the destination mobile is currently located on.

yon A O O Attribute of msc

Type of number

npi A O O Attribute of msc


imsi E n/a M International Mobile Subscriber Identity


Message E O C1 UTF-8 Encoded text string

Orig E O O Origination Mobile Subscriber ISDN Number

Identifies the mobile number of the device from which the SMS is sent from.

Ton A O O Attribute of orig

Type of number

Npi A O O Attribute oforig


sessionId E M for existing session

O Identifies the sms session being handled. This is returned in the first response to a GET or PUT where multiple concatenated messages are required to be sent or received

smsDeliver E C1 O Compound parameter with sub-elements shown in section 8.1.1 SMS

Deliver parameters.



8.3 MO-SMS Service


SmsMo T M M Top level element for SMS-MO request/responses


Set to 1

Dest E O M Destination Mobile Subscriber ISDN Number

Identifies the destination mobile address for the SMS

Ton A O O Attribute of dest

Type of number

Npi A O O Attribute of dest


orig E O M Origination Mobile Subscriber ISDN Number

Identifies the originating mobile address of the SMS


57

ton A O O Attribute of orig

Type of number

npi A O O Attribute of orig


destSrvCtr E M O SMS Service Centre that SMS is to be sent to

ton A O O Attribute of destSrvCtr

Type of number

npi A O O Attribute of destSrvCtr


Msc E M O MSC ISDN Number

The MSC Address that the SMS-MO originated from

ton A O O Attribute of msc

Type of number

npi A O O Attribute of msc


smsSubmit E C1 O Compound parameter with sub-elements shown in section 8.3.1 SMS

Submit parameters.



8.3.1 SMS Submit parameters


rd E M M TP-Reject-Duplicates flag as specified in 23.040

Boolean, true means reject duplicates is set.

rp E M M TP-RP flag as specified in 23.040

Boolean, true means Reply path exists

udhi E M M TP-UDHI flag as specified in 23.040

Boolean, true means TP-UD contains a header

srr E M M TP-Status-Report-Request flag as specified in 23.040

Boolean, true means a status report is requested

pid E M M TP-PID as specified in 23.040

Protocol Identifier


dcs E M M TP-DCS as specified in 23.040

Data coding scheme


mr E M M TP-Message-Reference as specified in 23.040

Value between 0.255

vpRel E O O TP-Validity-Period (Relative Format) as specified in 23.040

Value between 0.255

vpAbs E O O TP-Validity-Period (Absolute Format) as specified in 23.040

Base 64 encoded.


58

vpEnc E O O TP-Validity-Period (Absolute Format) as specified in 23.040

Base 64 encoded.

udl E M M TP-UDL as specified in 23.040

This is the length of the unit data parameter specified in

If the ud parameter is encoded in GSM 7-bit default alphabet then this represents the number of septets used.

If the ud parameter is encoded in GSM 7-bit default alphabet AND the udhi is set the then this represents the number of septets used in the user data header plus the user data field.

If the ud parameter is encoded using 8-bit data then the udl should indicate the number of octets used.

If the ud parameter is encoded using 8-bit data and the udhi is set then the udl should indicate the number of octets used in the header plus the user data field.

ud E M M TP-UD as specified in 23.040

Contains the SMS user data encoded as Base64

8.4 Alert Service Centre Service


AlertSC T M M Top level element for AlertSC request/responses


Set to 1

msisdn E n/a M Mobile Subscriber ISDN Number

Identifies the mobile address received in the alert Service Centre

ton A n/a O Attribute of msisdn

Type of number

npi A n/a O Attribute of msisdn


8.5 Send Routing Info For SM Service


AlertSC T M M Top level element for Send Routing Info For SM request/responses

Version A O O Attribute of sriForSm

Set to 1

msisdn E M n/a Mobile Subscriber ISDN Number

Identifies the mobile address that the routing information is required for

ton A O n/a Attribute of msisdn

Type of number

npi A O n/a Attribute of msisdn


SmRpPri E O n/a Indicates whether SMS delivery will be attempted even when a service centre address is contained in the Message Waiting Data file in the HLR

Specified in 29.002.


59

gprsSupportIndicator E O n/a If the SMS-GMSC supports of receiving two numbers for HLR

Specified in 29.002

For future expansion

smRpMti E O n/a RP-Message Type Indicator of the Short Message

Specified in 29.002

smRpSmea E O n/a Originating SME-Address of the Short Message Entity

Specified in 29.002

ton A O n/a Attribute of smRpSmea

Type of number

npi A O n/a Attribute of smRpSmea


smDeliveryNotIntended E O n/a This parameter indicates whether the delivery of a short message is not intended.

Specified in 29.002

msc E n/a M Mobile Switching Centre ISDN Number

MSC address that the terminating mobile is located at

ton A n/a M Attribute of smRpSmea

Type of number

npi A n/a M Attribute of smRpSmea


imsi E n/a O International Mobile Subscriber Identity


lmsi E n/a O Mobile local identity specified by residing VLR

gprsNodeIndicator E n/a O Present if SGSN is the primary location of the mobile.

Reserved for future expansion

sgsnNum E n/a O SGSN Address for GPRS Mobiles.


ton A n/a M Attribute of sgsnNum

Type of number

npi A n/a M Attribute of sgsnNum


informSC E n/a O Compound parameter with sub-elements shown in section 8.5.1 Inform Service Centre parameters.

This used to specify contents received in the optional Inform Service Centre.

8.5.1 Inform Service Centre parameters


storedMsisdn E n/a O MSISDN stored in the HLR of the requested mobile

ton A n/a M Attribute of storedMsisdn

Type of number

npi A n/a M Attribute of storedMsisdn



60

mnrf E n/a O Mobile Station Not Reachable flag if present

mcef E n/a O Memory Capacity Exceeded flag if present

mnrg E n/a O Mobile Station Not Reachable for GPRS flag if present


srvCtrSetInHlr E n/a O Service Centre already set in the HLR

absentSubDiagSm E n/a O The reason that the subscriber is absent

Values specified 23.040

addAbsentSubDiagSm E n/a O The reason that the subscriber is absent for GPRS



8.6 Report SM Delivery Status Service


reportSMDeliver T M M Top level element for Report SM Delivery request/responses

bersion A O O Attribute of sms

Set to 1

msisdn E M n/a Mobile Subscriber ISDN Number

Identifies the mobile address received in the alert Service Centre

ton A O n/a Attribute of msisdn

Type of number

npi A O n/a Attribute of msisdn


deliveryOutcome E M n/a Indicates the status of the mobile terminated SM delivery

absentSubDiagSm E O n/a Absent subscriber Diagnostic


gprsSupportInd E O n/a GPRS Support Ind, SMS-GMSC supports handling of two delivery Outcomes

gprsDeliveryOutcome E O n/a Indicates the status of the mobile terminated SM delivery for GPRS

gprsAbsentSubDiagSm E O n/a Absent subscriber Diagnostic for GPRS


imsSupportInd E O n/a IMS Support Ind, SMS-GMSC supports handling of two delivery Outcomes

imsDeliveryOutcome E O n/a Indicates the status of the mobile terminated SM delivery for IMS

imsAbsentSubDiagSm E O n/a Absent subscriber Diagnostic for IMS


storedMsisdn E n/a O MSISDN stored in the HLR of the requested mobile

Ton A n/a O Attribute of storedMsisdn

Type of number

Npi A n/a O Attribute of storedMsisdn



61

8.7 USSD Service


Ussd T M M Top level element for USSD request/responses

Version A O O Attribute of ussd

Set to 1

alertingPattern E O O Optional parameter to set a network specific alerting indication. Values are a single character representing a single byte value.

Close E C2 C

2 Set element to indicate a request to close session. For example, in a

PUT request, that should close the session on completion.

This prevents the need for an unnecessary DELETE request.

Msisdn E M for new session

M for new session

Mobile Subscriber ISDN Number

Identifies the mobile number of the device being located.

Ton A O M Attribute of msisdn

Type of Number

Npi A O M Attribute of msisdn


sessionId E O M for existing session

Identifies the ussd session being handled. Typically this is returned in the first response to a GET on /ussd.

Timeout E n/a n/a For future use.

ussdString E M M3 Represents the text send or received in a USSD message

Imsi E n/a C4 International Mobile Subscriber Identity


dataCodingScheme A O O USSD coding scheme to be used as defined in the CBD Data Scheme in 3GPP 23.038.

Values supported:

0-15 – Default Alphabet with Language

16,17 – Default Alphabet/UCS2

64, 65, 66 – General Data Coding

Notify E O O Sends a USSD Notify to the network instead of a USSD Request

Note 2 – Required to request a session to be closed after processing action. Will be present in responses to indicate session has been closed.

Note 3 – Passed up if available.

Note 4 – If a USSD-REQ or USSD-NOT is requested from the API is the first message in a session and the ussdString is greater than 166 characters then the SWS send two messages. The first will perform the dialogue initiation

before transmitting the USSD string in a later message. This is to permit the longer string to fit into an MSU size limit of 272 characters allowing for the GT

addresses (including MSISDN) are of the maximum size.


62

8.8 Location Service


location T M M Top level element for location responses

version A n/a O Attribute of location

Set to 1

latitude E n/a O Location latitude position in real valued degrees (-180 to +180)

longitude E n/a O Location longitude position in real valued degrees (-90 to +90)

msisdn E n/a O Mobile Subscriber ISDN Number


ton A n/a O Attribute of msisdn

Type of Number

npi A n/a O Attribute of msisdn


cellId C n/a O Cell Id of the location

geodeticinformation C n/a O Location returned in the geodetic format

geographicalinfomationgprs C n/a O Location returned in the geographical format for a GPRS enabled phone

geographicalinformation C n/a O Location returned in the geographical format

8.8.1 Cell Id Parameters


mcc

E M n/a Mobile Country Code as specified in 29.002 section 17.7.8

mnc E M n/a Mobile Network Code as specified in 29.002 section 17.7.8

lac E M n/a Location Area Code as specified in 29.002 section 17.7.8

ci E O n/a Cell Identity as specified in 29.002 section 17.7.8


63

8.9 Subscriber State Service


SubscriberState T M M Top level element for location responses

Version A n/a O Attribute of location

Set to 1

Msisdn E M n/a Mobile Subscriber ISDN Number


State E n/a M Subscriber State of the Mobile Subscriber

state A n/a M Subscriber state

Not Reachable E n/a O Not reachable reason for the mobile subscriber


64

8.10 Get IMSI Service


GetImsi T M M Top level element for Get IMSI responses

Version A n/a O Attribute of location

Set to 1

Msisdn E M n/a Mobile Subscriber ISDN Number


Imsi E n/a M International Mobile Subscriber Identity



65

8.11 Error

Parameter Group Rsp Details

error T M Top level element for error information

Contains details of error

code A M Error code

type A M Attribute of the error

code, defines the

group of error codes

(e.g. MAP User Error

or Internal System

Error

text E M Contains details of error

8.11.1 Error Code Types

Error Code Types

internalFailure

mapUserError

userError

mapProviderError

noDataWaiting

absMandParam

invalidSession

invalidParamLen

servNotSupported

sessionTerminated

localTimeout

parseError

8.11.2 Error Code Type – internalFailureCodeType

Error Code

noResources

invalidGCTFmt

insufficientRpnd

8.11.3 Error Code Type – mapErrorCodeType

Error Code

unknownSubscriber


66

unknownMSC

unidentifiedSubscriber

absentSubscriberSM

unknownEquipment

roamingNotAllowed

illegalSubscriber

bearerServiceNotProvisioned

teleServiceNotProvisioned

illegalEquipment

callBarred

forwardingViolation

cugReject

illegalSSOperation

ssErrorStatus

ssNotAvailable

ssSubscriptionViolation

ssIncompatibility

facilityNotSupported

ongoingGroupCall

noHandoverNumberAvailable

subsequentHandoverFailure

absentSubscriber

incompatibleTerminal

shortTermDenial

longTermDenial

subscriberBusyForMTSMS

smDeliveryFailure

messageWaitingListFull

systemFailure

dataMissing

unexpectedDataValue

pwRegistrationFailure

negativePWCheck

noRoamingNumberAvailable

tracingBufferFull

targetCellOutsideGroupCallArea

numberOfPWAttemptsViolation

numberChanged


67

busySubscriber

noSubscriberReply

forwardingFailed

orNotAllowed

atiNotAllowed

noGroupCallNumberAvailable

resourceLimitation

unauthorizedRequestingNetwork

unauthorizedLCSClient

positionMethodFailure

unknownOrUnreachableLCSClient

mmEventNotSupported

atsiNotAllowed

atmNotAllowed

informationNotAvailable

unknownAlphabet

ussdBusy

Unknown

8.11.4 Error Code Type – userErrorCodeType

Error Code

appIdAbsent

appIdInvalid

appNotActive

invalidState

8.11.5 Error Code Type – providerErrorCodeType

Error Code

appIdAbsent

appIdInvalid

appNotActive

invalidState

8.11.6 MAP User Errors

Error Code

Unknown Subscriber

Unknown MSC


68

Error Code

Unidentified Subscriber

Absent Subscriber SM

Unknown Equipment

Roaming Not Allowed

Illegal Subscriber

Bearer Service Not Provisioned

Teleservice Not Provisioned

Illegal Equipment

Call Barred

Forwarding Violation

CUG_Reject

Illegal SS Operation

SS Error Status

SS Not Available

SS Subscription Violation

SS Incompatibility

Facility Not Supported

PW Registration Failure

Negative PW Check

NO Handover Number Available

Subsequent Handover Failure

Absent Subscriber

Subscriber Busy for MT SMS

SM Delivery Failure

message_waiting_list_full

system_failure

data_missing

unexpected_data_value

resource_limitation

initiating_release

no_roaming_number_available

tracing_buffer_full

number_of_pw_attempts_violation

number_changed

busy_subscriber

no_subscriber_reply

forwarding_failed


69

Error Code

or_not_allowed

ATI_not_allowed

unauthorised_requesting_network

unauthorised_LCS_client

position_method_failure

unknown_or_unreachable_LCS_client

mm_event_not_supported

atsi_not_allowed

atm_not_allowed

information_not_available

unknown_alphabet

ussd_busy

9 Application Development Guidelines

70

9 Application Development Guidelines

9.1 Application Development Frameworks The web-services APIs make use of HTTP with XML payloads and are constructed to follow RESTful principals. This allows many different

development environments and frameworks to be used.

The following environments have been used to create the example applications:

Language Development Environment

Java NetBeans 6.9 IDE

C# Microsoft Visual Studio 2005

PHP Various

Other development environments are available and should provide facilities

suitable for use with the SWS APIs.

9.2 XML Handling In order to support auto-generated handling and validation of XML,

supporting XSD schema files are provided (See Appendix A.1). This schema can be used with supporting XML handling libraries such as JAXB in Java.

9.3 HTTP/HTTPS The URIs and port numbers used in this document assume use of HTTP for

the RESTful interface running at the default port number of 81. The port numbers for HTTP and HTTPS are configurable. Please verify that the correct values are being used on the specific system.

A secure API connection to the SWS system can be created by enabling SSL. This will mean a corresponding change to the URIs and Port numbers used. When enabled, the default port for the RESTful interface over HTTPS is 442.

The method by which SSL/HTTPS is enabled and certificates accepted is system and platform dependent.

9.4 Use of Expect: HTTP 100 – Continue The SWS platform does not respond to requests requiring HTTP 100 – Continue responses. The default behavior of some web-service frameworks (e.g. C#/.NET) may be to expect the 100 – Continue response.

The use of the HTTP 100 – Continue is inefficient and inappropriate for the

APIs being used. This should be disabled for correct behavior. For example:

HttpWebRequest request = WebRequest.Create(uri) as HttpWebRequest;

request.ServicePoint.Expect100Continue = false;


71

10 Application Examples

A number of example applications are available for different environments to show different aspects of the system and provide different sets of test functionality.

10.1 Java SWS Test Utility The SMS test sender application makes use of the ‘Jersey’ API support for RESTful web-services in Java. It also makes use of the JAXB support for conversion of data to and from XML based on the supplied XSD schema files.

The user interface makes use of the Swing framework (Figure 31: Java SMS

Test Sender).

Figure 31: Java SMS Test Sender

The application can be used by entering the server IP address, destination number and message to send. The ‘Advanced‘ tab allows the encoding scheme, type of number and numbering plan identifier settings to be changed

if necessary.

10 Application Examples

72

10.2 C# SWS Example Application This application makes use of a simple GUI and C# components to allow testing of the API with an SWS server and is shown in Figure 32: C# Test

Sender.

Figure 32: C# Test Sender


73

10.3 PHP Example A simple application written in PHP. It gives an example of a scripted language and is shown below in Figure 33: PHP Test Sender.

Figure 33: PHP Test Sender

XSD Files

74

Appendix A. XSD Files

A.1 SWS XSD Schema

<?xml version="1.0" encoding="utf-8" ?>





<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"

xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:simpleType name="versionType">

<xs:restriction base="xs:int">

<xs:minInclusive value="1" />

<xs:maxInclusive value="1" />

</xs:restriction>

</xs:simpleType>

<xs:complexType name="ussdType">

<xs:sequence>

<xs:element minOccurs="0" name="msisdn" type="addressFieldType" />

<xs:element minOccurs="0" name="imsi" type="xs:normalizedString" />

<xs:element minOccurs="0" name="timeout">

<xs:simpleType>



</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element minOccurs="0" name="alertingPattern">

<xs:simpleType>

<xs:restriction base="xs:short">


</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element minOccurs="0" name="ussdString">

<xs:complexType>

<xs:simpleContent>

<xs:extension base="xs:string">

<xs:attribute name="dataCodingScheme" type="xs:unsignedByte" />

<xs:attribute name="language" type="xs:language" />

</xs:extension>

</xs:simpleContent>

</xs:complexType>

</xs:element>

<xs:element minOccurs="0" name="sessionId" type="xs:normalizedString" />

<xs:element minOccurs="0" name="notify" />

<xs:element minOccurs="0" name="close" />

<xs:element minOccurs="0" name="testProcessUssdReq" />

<xs:element name="optionalInfo" type="oiType" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="smsType">

<xs:sequence>

<xs:element minOccurs="0" name="dest" type="addressFieldType" />

<xs:element minOccurs="0" name="orig" type="addressFieldType" />


<xs:element minOccurs="0" name="message">

<xs:complexType>

<xs:simpleContent>

<xs:extension base="xs:string" />

</xs:simpleContent>

</xs:complexType>


75

</xs:element>


<xs:element name="smsDeliver" type="tpType" />

<xs:element minOccurs="0" name="reportSmDeliveryStatus" type="xs:boolean"/>

<xs:element minOccurs="0" name="reportSmDeliveryStatusGprs" type="xs:boolean"/>


</xs:sequence>

</xs:complexType>

<xs:complexType name="locationServiceType">

<xs:sequence>


<xs:element minOccurs="0" maxOccurs="1" name="longitude" type="longitudeType"

/>

<xs:element minOccurs="0" maxOccurs="1" name="latitude" type="latitudeType" />

<xs:element minOccurs="0" maxOccurs="1" name="cellId" type="cellIdType" />

<xs:element minOccurs="0" maxOccurs="1" name="geographicalInformation"

type="geographicalInformationType" />

<xs:element minOccurs="0" maxOccurs="1" name="geodeticInformation"

type="geodeticInformationType" />

<xs:element minOccurs="0" maxOccurs="1" name="geographicalInfomationGPRS"




</xs:sequence>

</xs:complexType>

<xs:complexType name="smsMoType">

<xs:sequence>

<xs:element minOccurs="0" name="dest" type="addressFieldType" />


<xs:element minOccurs="0" name="destSrvCtr" type="addressFieldType" />

<xs:element minOccurs="0" name="msc" type="addressFieldType" />

<xs:element name="smsSubmit" type="moTpType" />


</xs:sequence>

</xs:complexType>

<xs:complexType name="alertSCType">

<xs:sequence>


<xs:element minOccurs="0" name="destSrvCtr" type="addressFieldType" />


</xs:sequence>

</xs:complexType>

<xs:complexType name="readyForSMType">

<xs:sequence>

<xs:element minOccurs="0" name="noteSubPresent" type="xs:unsignedByte"/>


<xs:element minOccurs="1" name="hlrAddr" type="addressFieldType" />

<xs:element minOccurs="0" name="alertReason" type="alertReasonType" />

<xs:element minOccurs="0" name="alertReasonInd" />

<xs:element minOccurs="0" name="additionalAlertReasonInd" />



</xs:sequence>

</xs:complexType>

<xs:complexType name="sriForSmType">

<xs:sequence>


<xs:element minOccurs="0" name="smRpPri" type="xs:boolean" />

<xs:element minOccurs="0" name="gprsSupportInd"/>

<xs:element minOccurs="0" name="smRpMti" type="smRpMtiType" />

<xs:element minOccurs="0" name="smRpSmea" type="addressFieldType" />

<xs:element minOccurs="0" name="smDeliveryNotIntended"

type="smDeliveryNotIntendedType"/>



XSD Files

76

<xs:element minOccurs="0" name="lmsi" type="xs:normalizedString" />

<xs:element minOccurs="0" name="gprsNodeIndicator"/>

<xs:element minOccurs="0" name="sgsnNum" type="addressFieldType" />

<xs:element minOccurs="0" maxOccurs="1" name="informSc" type="informScType"/>



</xs:sequence>

</xs:complexType>

<xs:complexType name="smsMtType">

<xs:sequence>




<xs:element minOccurs="0" name="message">

<xs:complexType>

<xs:simpleContent>

<xs:extension base="xs:string" />

</xs:simpleContent>

</xs:complexType>

</xs:element>


<xs:element name="smsDeliver" type="tpType" />


</xs:sequence>

</xs:complexType>

<xs:complexType name="reportSMDeliverType">

<xs:sequence>


<xs:element minOccurs="1" name="deliveryOutcome" type="smDeliveryOutcomeType"

/>

<xs:element minOccurs="0" name="absentSubDiagSm" type="absentSubDiagSmType" />

<xs:element minOccurs="0" name="gprsSupportInd" />

<xs:element minOccurs="0" name="gprsDeliveryOutcomeInd" />

<xs:element minOccurs="0" name="gprsDeliveryOutcome"

type="smDeliveryOutcomeType" />

<xs:element minOccurs="0" name="gprsAbsentSubDiagSm" type="absentSubDiagSmType"

/>

<xs:element minOccurs="0" name="imsInd" />

<xs:element minOccurs="0" name="imsDeliveryOutcome"

type="smDeliveryOutcomeType" />

<xs:element minOccurs="0" name="imsAbsentSubDiagSm" type="absentSubDiagSmType"

/>

<xs:element minOccurs="0" name="storedMsisdn" type="addressFieldType" />



</xs:sequence>

</xs:complexType>

<xs:complexType name="subscriberStateServiceType">

<xs:sequence>

<xs:element minOccurs="0" name="state" type="subscriberStateType"/>



<xs:element minOccurs="0" name="optionalInfo" type="oiType" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="getImsiServiceType">

<xs:sequence>





</xs:sequence>

</xs:complexType>

<xs:complexType name="anytimeInterrogationServiceType">

<xs:sequence>


77



<xs:element minOccurs="0" name="hlrAddr" type="addressFieldType" />

<xs:element minOccurs="0" name="locationReq">

<xs:complexType>

<xs:attribute name="currentLocation" type="xs:boolean" />

</xs:complexType>

</xs:element>

<xs:element minOccurs="0" name="subscriberStateReq"/>

<xs:element minOccurs="0" name="requestedDomain" type="requestedDomainType"/>

<xs:element minOccurs="0" name="imeiReq"/>

<xs:element minOccurs="0" name="msClassMarkReq"/>

<xs:element minOccurs="0" name="mnpRequestedInfo"/>

<xs:element minOccurs="0" name="tAdsData"/>

<xs:element minOccurs="0" name="requestedNodes" type="requestedNodesType"/>

<xs:element minOccurs="0" name="locationRsp" type="locationRspType"/>

<xs:element minOccurs="0" name="subscriberStateRsp"

type="subscriberStateType"/>

<xs:element minOccurs="0" name="psSubscriberStateRsp"

type="psSubscriberStateType"/>

<xs:element minOccurs="0" name="gprsMsClass" type="gprsMsClassType"/>

<xs:element minOccurs="0" name="imeiRsp" type="xs:normalizedString"/>

<xs:element minOccurs="0" name="msClassMarkRsp" type="xs:normalizedString"/>

<xs:element minOccurs="0" name="mnpInfoRes" type="mnpInfoResType"/>

<xs:element minOccurs="0" name="imsVoiceOverPsSessionsIndication"

type="imsVoiceOverPsSessionsIndicationType"/>

<xs:element minOccurs="0" name="lastUeActivityTime"

type="xs:normalizedString"/>

<xs:element minOccurs="0" name="lastRatType" type="UsedRatTypeType"/>

<xs:element minOccurs="0" name="sessionId" type="xs:normalizedString"/>


<xs:element minOccurs="0" name="epsSubscriberStateRsp"

type="psSubscriberStateType"/>

</xs:sequence>

</xs:complexType>

<xs:element name="sms">

<xs:complexType>

<xs:complexContent mixed="false">

<xs:extension base="smsType">

<xs:attribute name="version" type="versionType" />

</xs:extension>

</xs:complexContent>

</xs:complexType>

</xs:element>

<xs:element name="error">

<xs:complexType>


<xs:extension base="errorType">


</xs:extension>


</xs:complexType>

</xs:element>

<xs:element name="ussd">

<xs:complexType>


<xs:extension base="ussdType">


</xs:extension>


</xs:complexType>

</xs:element>

<xs:element name="smsmo">

<xs:complexType>


XSD Files

78

<xs:extension base="smsMoType">


</xs:extension>


</xs:complexType>

</xs:element>

<xs:element name="location">

<xs:complexType>


<xs:extension base="locationServiceType">


</xs:extension>


</xs:complexType>

</xs:element>

<xs:element name="alertSC">

<xs:complexType>


<xs:extension base="alertSCType">


</xs:extension>


</xs:complexType>

</xs:element>

<xs:element name="sriForSm">

<xs:complexType>


<xs:extension base="sriForSmType">


</xs:extension>


</xs:complexType>

</xs:element>

<xs:element name="smsmt">

<xs:complexType>


<xs:extension base="smsMtType">


</xs:extension>


</xs:complexType>

</xs:element>

<xs:element name="reportSMDeliver">

<xs:complexType>


<xs:extension base="reportSMDeliverType">


</xs:extension>


</xs:complexType>

</xs:element>

<xs:element name="readyForSM">

<xs:complexType>


<xs:extension base="readyForSMType">


</xs:extension>


</xs:complexType>

</xs:element>

<xs:element name="subscriberState">

<xs:complexType>


<xs:extension base="subscriberStateServiceType">

<xs:attribute name="version" type="versionType"/>


79

</xs:extension>


</xs:complexType>

</xs:element>

<xs:element name="anytimeInterrogation">

<xs:complexType>


<xs:extension base="anytimeInterrogationServiceType">


</xs:extension>


</xs:complexType>

</xs:element>

<xs:element name="getImsi">

<xs:complexType>


<xs:extension base="getImsiServiceType">


</xs:extension>


</xs:complexType>

</xs:element>

<xs:complexType name="errorType">

<xs:sequence>

<xs:element minOccurs="1" name="code" type="errorCode"/>

<xs:element minOccurs="1" name="text" type="xs:string"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="errorCode">

<xs:choice maxOccurs="1">

<xs:element name="internalFailureCode" type="internalFailureCodeType"/>

<xs:element name="mapErrorCode" type="mapErrorCodeType"/>

<xs:element name="userErrorCode" type="userErrorCodeType"/>

<xs:element name="providerErrorCode" type="providerErrorCodeType"/>

<xs:element name="absMandParamCode" type="parameterType"/>

<xs:element name="invalidSessionCode" type="xs:normalizedString"/>

<xs:element name="invalidParamLenCode" type="parameterType"/>

<xs:element name="serviceNotSupportedCode" type="serviceType"/>

<xs:element name="sessionTerminated" type="sessionTerminatedType"/>

</xs:choice>

<xs:attribute name="type">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="internalFailure"/>

<xs:enumeration value="mapUserError"/>

<xs:enumeration value="userError"/>

<xs:enumeration value="mapProviderError"/>

<xs:enumeration value="noDataWaiting"/>

<xs:enumeration value="absMandParam"/>

<xs:enumeration value="invalidSession"/>

<xs:enumeration value="invalidParamLen"/>

<xs:enumeration value="servNotSupported"/>

<xs:enumeration value="sessionTerminated"/>

<xs:enumeration value="localTimeout"/>

<xs:enumeration value="parseError"/>

<xs:enumeration value="invalidProfile"/>

</xs:restriction>

</xs:simpleType>

</xs:attribute>

</xs:complexType>

<xs:simpleType name="internalFailureCodeType">


<xs:enumeration value="noResources"/>

<xs:enumeration value="invalidGCTFmt"/>

<xs:enumeration value="insufficientRpnd"/>

XSD Files

80

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="mapErrorCodeType">


<xs:enumeration value="unknownSubscriber"/>

<xs:enumeration value="unknownMSC"/>

<xs:enumeration value="unidentifiedSubscriber"/>

<xs:enumeration value="absentSubscriberSM"/>

<xs:enumeration value="unknownEquipment"/>

<xs:enumeration value="roamingNotAllowed"/>

<xs:enumeration value="illegalSubscriber"/>

<xs:enumeration value="bearerServiceNotProvisioned"/>

<xs:enumeration value="teleServiceNotProvisioned"/>

<xs:enumeration value="illegalEquipment"/>

<xs:enumeration value="callBarred"/>

<xs:enumeration value="forwardingViolation"/>

<xs:enumeration value="cugReject"/>

<xs:enumeration value="illegalSSOperation"/>

<xs:enumeration value="ssErrorStatus"/>

<xs:enumeration value="ssNotAvailable"/>

<xs:enumeration value="ssSubscriptionViolation"/>

<xs:enumeration value="ssIncompatibility"/>

<xs:enumeration value="facilityNotSupported"/>

<xs:enumeration value="ongoingGroupCall"/>

<xs:enumeration value="noHandoverNumberAvailable"/>

<xs:enumeration value="subsequentHandoverFailure"/>

<xs:enumeration value="absentSubscriber"/>

<xs:enumeration value="incompatibleTerminal"/>

<xs:enumeration value="shortTermDenial"/>

<xs:enumeration value="longTermDenial"/>

<xs:enumeration value="subscriberBusyForMTSMS"/>

<xs:enumeration value="smDeliveryFailure"/>

<xs:enumeration value="messageWaitingListFull"/>

<xs:enumeration value="systemFailure"/>

<xs:enumeration value="dataMissing"/>

<xs:enumeration value="unexpectedDataValue"/>

<xs:enumeration value="pwRegistrationFailure"/>

<xs:enumeration value="negativePWCheck"/>

<xs:enumeration value="noRoamingNumberAvailable"/>

<xs:enumeration value="tracingBufferFull"/>

<xs:enumeration value="targetCellOutsideGroupCallArea"/>

<xs:enumeration value="numberOfPWAttemptsViolation"/>

<xs:enumeration value="numberChanged"/>

<xs:enumeration value="busySubscriber"/>

<xs:enumeration value="noSubscriberReply"/>

<xs:enumeration value="forwardingFailed"/>

<xs:enumeration value="orNotAllowed"/>

<xs:enumeration value="atiNotAllowed"/>

<xs:enumeration value="noGroupCallNumberAvailable"/>

<xs:enumeration value="resourceLimitation"/>

<xs:enumeration value="unauthorizedRequestingNetwork"/>

<xs:enumeration value="unauthorizedLCSClient"/>

<xs:enumeration value="positionMethodFailure"/>

<xs:enumeration value="unknownOrUnreachableLCSClient"/>

<xs:enumeration value="mmEventNotSupported"/>

<xs:enumeration value="atsiNotAllowed"/>

<xs:enumeration value="atmNotAllowed"/>

<xs:enumeration value="informationNotAvailable"/>

<xs:enumeration value="unknownAlphabet"/>

<xs:enumeration value="ussdBusy"/>

<xs:enumeration value="Unknown"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="userErrorCodeType">



81

<xs:enumeration value="appIdAbsent"/>

<xs:enumeration value="appIdInvalid"/>

<xs:enumeration value="appNotActive"/>

<xs:enumeration value="invalidState"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="providerErrorCodeType">


<xs:enumeration value="duplicateInvokeId"/>

<xs:enumeration value="notSupportedService"/>

<xs:enumeration value="mistypedParameter"/>

<xs:enumeration value="resourceLimitation"/>

<xs:enumeration value="initiatingRelease"/>

<xs:enumeration value="unexpectedResponseFromPeer"/>

<xs:enumeration value="serviceCompletionFailure"/>

<xs:enumeration value="noResponseFromPeer"/>

<xs:enumeration value="invalidResponseReceived"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="parameterType">


<xs:enumeration value="msisdn"/>

<xs:enumeration value="imsi"/>

<xs:enumeration value="timeout"/>

<xs:enumeration value="imsi"/>

<xs:enumeration value="alertingPattern"/>

<xs:enumeration value="ussdString"/>

<xs:enumeration value="sessionId"/>

<xs:enumeration value="dest"/>

<xs:enumeration value="orig"/>

<xs:enumeration value="message"/>

<xs:enumeration value="scts"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="geographicalInformationType">

<xs:sequence>

<xs:element name="latitude" type="latitudeType" />

<xs:element name="longitude" type="longitudeType" />

<xs:element name="typeOfShape" type="typeOfShapeType" />

<xs:element name="uncertaintyCode" type="uncertantyCodeType" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="geodeticInformationType">

<xs:sequence>

<xs:element name="latitude" type="latitudeType" />

<xs:element name="longitude" type="longitudeType" />

<xs:element name="typeOfShape" type="typeOfShapeType" />

<xs:element name="uncertaintyCode" type="uncertantyCodeType" />

<xs:element name="screeningIndicator" type="screeningIndicatorType" />

</xs:sequence>

</xs:complexType>

<xs:simpleType name="longitudeType">

<xs:restriction base="xs:double" />

</xs:simpleType>

<xs:simpleType name="latitudeType">


</xs:simpleType>

<xs:complexType name="cellIdType">

<xs:sequence>

<xs:element name="mcc" type="xs:normalizedString" />

<xs:element name="mnc" type="xs:normalizedString" />

<xs:element name="lac" type="xs:normalizedString" />

<xs:element minOccurs="0" maxOccurs="1" name="ci" type="xs:normalizedString" />

</xs:sequence>

</xs:complexType>

XSD Files

82

<xs:simpleType name="uncertantyCodeType">


</xs:simpleType>

<xs:simpleType name="typeOfShapeType">



</xs:restriction>

</xs:simpleType>

<xs:simpleType name="screeningIndicatorType">



</xs:restriction>

</xs:simpleType>

<xs:complexType name="addressFieldType">

<xs:simpleContent>

<xs:extension base="xs:normalizedString">

<xs:attribute name="ton">

<xs:simpleType>


<xs:enumeration value="Unknown" />

<xs:enumeration value="International" />

<xs:enumeration value="National" />

<xs:enumeration value="NetworkSpecific" />

<xs:enumeration value="Subscriber" />

<xs:enumeration value="Alphanumeric" />

<xs:enumeration value="AbbreviatedNumber" />

<xs:enumeration value="Reserved" />

</xs:restriction>

</xs:simpleType>

</xs:attribute>

<xs:attribute name="npi">

<xs:simpleType>


<xs:enumeration value="Unknown" />

<xs:enumeration value="ISDN" />

<xs:enumeration value="Reserved2" />

<xs:enumeration value="Data" />

<xs:enumeration value="Telex" />

<xs:enumeration value="ServiceCentreSpecific5" />

<xs:enumeration value="ServiceCentreSpecific6" />


<xs:enumeration value="National" />

<xs:enumeration value="Private" />

<xs:enumeration value="ERMES" />





<xs:enumeration value="Reserved" />

</xs:restriction>

</xs:simpleType>

</xs:attribute>

</xs:extension>

</xs:simpleContent>

</xs:complexType>

<xs:complexType name="tpType">

<xs:sequence>

<xs:element name="mms" type="xs:boolean" />

<xs:element name="rp" type="xs:boolean" />

<xs:element name="udhi" type="xs:boolean" />

<xs:element name="udl">

<xs:simpleType>





83

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="sri" type="xs:boolean" />

<xs:element name="dcs">

<xs:simpleType>




</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="pid">

<xs:simpleType>




</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="scts" type="xs:string" />

<xs:element name="ud" type="xs:string" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="moTpType">

<xs:sequence>

<xs:element name="rd" type="xs:boolean" />

<xs:element name="rp" type="xs:boolean" />

<xs:element name="udhi" type="xs:boolean" />

<xs:element name="srr" type="xs:boolean" />

<xs:element name="mr">

<xs:simpleType>




</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="udl">

<xs:simpleType>




</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="dcs">

<xs:simpleType>




</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="pid">

<xs:simpleType>




</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="ud" type="xs:string" />

<xs:element name="vpRel">

<xs:simpleType>

XSD Files

84




</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="vpAbs" type="xs:string" />

<xs:element name="vpEnc" type="xs:string" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="oiType">

<xs:sequence>

<xs:element minOccurs="0" name="reqCount">

<xs:simpleType>



</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element minOccurs="0" name="indCount">

<xs:simpleType>



</xs:restriction>

</xs:simpleType>

</xs:element>


</xs:sequence>

</xs:complexType>

<xs:simpleType name="serviceType">


<xs:enumeration value="sms" />

<xs:enumeration value="smsmo" />

<xs:enumeration value="ussd" />

<xs:enumeration value="location" />

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="sessionTerminatedType">

<xs:restriction base="xs:int" />

</xs:simpleType>

<xs:simpleType name="alertReasonType">


<xs:enumeration value="msPresent" />

<xs:enumeration value="memoryAvailable" />

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="smRpMtiType">


<xs:enumeration value="SmsDeliver" />

<xs:enumeration value="SmsStatusReport" />

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="smDeliveryNotIntendedType">


<xs:enumeration value="imsi" />

<xs:enumeration value="mmc-mnc" />

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="absentSubDiagSmType">


<xs:enumeration value="noPagingResp" />

<xs:enumeration value="imsiDetached" />

<xs:enumeration value="roamingRestriction" />

<xs:enumeration value="deregisteredHlr" />

<xs:enumeration value="msPurged" />


85

<xs:enumeration value="noPagingRespSgsn" />

<xs:enumeration value="deregisteredHlrGprs" />

<xs:enumeration value="msPurgedGprs" />

<xs:enumeration value="unidentifiedSub" />

<xs:enumeration value="unidentifiedSubSgsn" />

<xs:enumeration value="deregisteredHssIms" />

<xs:enumeration value="noRespIpSmGw" />

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="smDeliveryOutcomeType">


<xs:enumeration value="memoryCapacityExceeded" />

<xs:enumeration value="absentSubscriber" />

<xs:enumeration value="successfulTransfer" />

</xs:restriction>

</xs:simpleType>

<xs:complexType name="informScType">

<xs:sequence>

<xs:element minOccurs="0" name="storedMsisdn" type="addressFieldType" />

<xs:element minOccurs="0" name="mnrf"/>

<xs:element minOccurs="0" name="mcef"/>

<xs:element minOccurs="0" name="mnrg"/>

<xs:element minOccurs="0" name="srvCtrSetInHlr"/>

<xs:element minOccurs="0" name="absentSubDiagSm" type="absentSubDiagSmType" />

<xs:element minOccurs="0" name="addAbsentSubDiagSm" type="absentSubDiagSmType"

/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="locationRspType">

<xs:sequence>

<xs:element minOccurs="0" maxOccurs="1" name="longitude" type="longitudeType"

/>

<xs:element minOccurs="0" maxOccurs="1" name="latitude" type="latitudeType" />

<xs:element minOccurs="0" maxOccurs="1" name="cellId" type="cellIdType" />

<xs:element minOccurs="0" maxOccurs="1" name="geographicalInformation"


<xs:element minOccurs="0" maxOccurs="1" name="geodeticInformation"

type="geodeticInformationType" />

<xs:element minOccurs="0" maxOccurs="1" name="geographicalInfomationGPRS"


</xs:sequence>

</xs:complexType>

<xs:simpleType name="requestedDomainType">


<xs:enumeration value="csDomain" />

<xs:enumeration value="psDomain" />

</xs:restriction>

</xs:simpleType>

<xs:complexType name="requestedNodesType">

<xs:sequence>

<xs:element minOccurs="0" maxOccurs="1" name="mme"/>

<xs:element minOccurs="0" maxOccurs="1" name="sgsn"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="gprsMsClassType">

<xs:sequence>

<xs:element minOccurs="0" maxOccurs="1" name="msNetworkCapability"


<xs:element minOccurs="0" maxOccurs="1" name="msRadioAccessCapability"


</xs:sequence>

</xs:complexType>

<xs:complexType name="mnpInfoResType">

<xs:sequence>

XSD Files

86

<xs:element minOccurs="0" maxOccurs="1" name="routingNumber"


<xs:element minOccurs="0" maxOccurs="1" name="imsi"


<xs:element minOccurs="0" maxOccurs="1" name="msisdn" type="addressFieldType"

/>

<xs:element minOccurs="0" maxOccurs="1" name="numberPortabilityStatus"

type="numberPortabilityStatusType" />

</xs:sequence>

</xs:complexType>

<xs:simpleType name="numberPortabilityStatusType">


<xs:enumeration value="notKnownToBePorted" />

<xs:enumeration value="ownNumberPortedOut" />

<xs:enumeration value="foreignNumberPortedToForeignNetwork" />

<xs:enumeration value="Reserved3"/>

<xs:enumeration value="ownNumberNotPortedOut" />

<xs:enumeration value="foreignNumberPortedIn" />

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="imsVoiceOverPsSessionsIndicationType">


<xs:enumeration value="imsVoiceOverPsSessionsNotSupported" />

<xs:enumeration value="imsVoiceOverPsSessionsSupported" />

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="UsedRatTypeType">


<xs:enumeration value="utran" />

<xs:enumeration value="geran" />

<xs:enumeration value="gan" />

<xs:enumeration value="1HspaEvolution" />

<xs:enumeration value="eUtran" />

</xs:restriction>

</xs:simpleType>

<xs:complexType name="subscriberStateType">

<xs:sequence>

<xs:element minOccurs="0" name="notReachable" type="notReachableType"/>

</xs:sequence>

<xs:attribute name="state">

<xs:simpleType>


<xs:enumeration value="assumedIdle"/>

<xs:enumeration value="camelBusy"/>

<xs:enumeration value="notReachable"/>

<xs:enumeration value="notProvided"/>

</xs:restriction>

</xs:simpleType>

</xs:attribute>

</xs:complexType>

<xs:complexType name="psSubscriberStateType">

<xs:sequence>

<xs:element minOccurs="0" name="notReachable" type="notReachableType"/>

</xs:sequence>

<xs:attribute name="state">

<xs:simpleType>


<xs:enumeration value="notProvided"/>

<xs:enumeration value="detached"/>

<xs:enumeration value="attachedPagingNotReachable"/>

<xs:enumeration value="attachedPagingReachable"/>

<xs:enumeration value="activePagingNotReachable"/>

<xs:enumeration value="activePagingReachable"/>

<xs:enumeration value="notReachable"/>

</xs:restriction>


87

</xs:simpleType>

</xs:attribute>

</xs:complexType>

<xs:simpleType name="notReachableType">


<xs:enumeration value="msPurged"/>

<xs:enumeration value="imsiDetached"/>

<xs:enumeration value="restrictedArea"/>

<xs:enumeration value="notRegistered"/>

</xs:restriction>

</xs:simpleType>

</xs:schema>

Testing Extensions to the API

88

Client SWS

200 - OK

GET

HLR


Send Routing Infor for SM - ReponsePUT

204 - OK

Appendix B. Testing Extensions to the API

B.1 Receiving Atomic Send Routing Info For SM A client can request to receive a Send Routing Info For SM from the network This uses a HTTP GET request and will receive the same XML payload used in

the request. The client will then send a response to send a result to the network using a HTTP PUT request. See the figure below:

Figure 34: Receiving a Send Routing Info For SM

HTTP GET

http://192.168.0.1:81/dialogicwebservice/signaling/sriforsm

The HTTP GET is used to request the next send routing info for SM received by SWS (note that the absence of the MSISDN).

The 20O – OK response code is the expected response to a successfully receive Send Routing Info for SM, it will have payload of the following form:

SEND-ROUTING-FOR-SM-TX-REQ






</sriForSm >


89

Client SWS

200 - OK

GET

HLR

Ready for SM

Ready for SM - ReponsePUT

204 - OK

HTTP PUT

http://192.168.0.1:81/dialogicwebservice/signaling/sriforsm/5

The HTTP Put request is then used to return the result of the Send Routing Info for SM request to the network. For a successful response the XML

payload will have the following form:




<imsi>5012423432</imsi>


</sriForSm>

To include the sending of inform SC then the payload will have the following form:




<imsi>5012423432</imsi>


<informSC>

<storedMsisdn ton="Unknown" np="ISDN">44777765</storedMsisdn>

<mnrf/>

</informSC>

</sriForSm>

B.2 Receiving Ready For SM A client can request to receive a Ready For SM from the network This uses a

HTTP GET request and will receive the same XML payload used in the request. The client will then send a response to send a result to the network using a HTTP PUT request. See the figure below:

Figure 35: Receiving a Ready For SM


90

HTTP GET

http://192.168.0.1:81/dialogicwebservice/signaling/readyforsm

The HTTP GET is used to request the next ready for SM received by SWS (note that the absence of the MSISDN).

The 20O – OK response code is the expected response to a successfully receive Ready For SM, it will have payload of the following form:

READY-FOR-SM-RX-REQ




<imsi>234153121235437</imsi>

<alertReason>msPresent</alertReason>

<hlrAddr ton="International" np="ISDN">440044001122</hlrAddr>


</readyForSm>

HTTP PUT

http://192.168.0.1:81/dialogicwebservice/signaling/readyforsm/2

The HTTP Put request is then used to return the result of the Ready for SM request to the network. For a successful response the XML payload will have the following form:





</readyForSm>


91

Client SWS

200 - OK

GET

HLR

Report SM Delivery

Report SM Delivery - ResponsePUT

204 - OK

B.3 Receiving Report SM Delivery A client can request to receive a Report SM Delivery from the network This uses a HTTP GET request and will receive the same XML payload used in the

request. The client will then send a response to send a result to the network using a HTTP PUT request. See the figure below:

Figure 36: Receiving a Report SM Delivery

HTTP GET

http://192.168.0.1:81/dialogicwebservice/signaling/reportSMDelive

r

The HTTP GET is used to request the next Report SM Delivery received by SWS.

The 20O – OK response code is the expected response to a successfully receive Report SM Delivery, it will have payload of the following form:


<!—- Example Report SM Delivery rcvd -->



<deliveryOutcome>successfulTransfer</deliveryOutcome>


</reportSMDeliver>

HTTP PUT

http://192.168.0.1:81/dialogicwebservice/signaling/reportsmdelive

r/2

The HTTP Put request is then used to return the result of the Report SM

Delivery request to the network. For a successful response the XML payload will have the following form:


92

Client SWS

200 - OK

GET

HLR

ATI (location request)

ATI Response (location)PUT

204 - OK





</reportSMDeliver >

B.4 Receiving Location Request A client can request to receive a Location Request from the network This uses a HTTP GET request and will receive the same XML payload used in the request. The client will then send a response to send a result to the network using a HTTP PUT request. See the figure below:

Figure 37: Receiving a Location Request

HTTP GET

http://192.168.0.1:81/dialogicwebservice/signaling/location

The HTTP GET is used to request the next Location request received by SWS (note that the absence of the MSISDN).

The 20O – OK response code is the expected response to a successfully

receive Location Request, it will have payload of the following form:






</location>

93

Client SWS

200 - OK

GET

HLR

ATI (subscriber state request)

ATI Response (subscriber state)PUT

204 - OK

HTTP PUT

http://192.168.0.1:81/dialogicwebservice/signaling/location/2231

The HTTP Put request is then used to return the result of the Location Request response to the network. For a successful response the XML payload

will have the following form:





<latitude>37.56509</latitude>

<longitude>-96.38509</longitude>


</location >

B.5 Receiving Subscriber State Request A client can request to receive a Subscriber State Request from the network This uses a HTTP GET request and will receive the same XML payload used in the request. The client will then send a response to send a result to the network using a HTTP PUT request. See the figure below:

Figure 38: Receiving a subscriber state Request

HTTP GET


e

The HTTP GET is used to request the next Location request received by SWS

(note that the absence of the MSISDN).

The 20O – OK response code is the expected response to a successfully

receive Subscriber State Request, it will have payload of the following form:


94



<subscriberState version="1">



</subscriberState>

HTTP PUT


e/2231

The HTTP Put request is then used to return the result of the Subscriber State response to the network. For a successful response the XML payload will have the following form:




<state state="assumedIdle"/>


</location >


95

Client SWS

204 - No content

PUT Alert Service Centre

Alert Service Centre - response

Network

B.6 Transmitting Alert Service Centre Request A client can request that an Alert Service Centre be used sent to the Nework. This uses a HTTP PUT request. See the figure below:

Figure 39: Transmitting a Alert Service Centre

HTTP PUT

http://192.168.0.1:81/dialogicwebservice/signaling/alertsc

The payload is mandatory. See Appendix A.1 for the supporting XSD schema.

ALERT-SC-TX-REQ





</sriForSm >



96

Client SWS

200 - OK

GET

HLR

PUT

204 - OK

Send IMSI Request

Send IMSI Response

B.7 Receiving Get IMSI Request A client can request to receive a Get Imsi Request from the network This uses a HTTP GET request and will receive the same XML payload used in the

request. The client will then send a response to send a result to the network using a HTTP PUT request. See the figure below:

Figure 40: Receiving a Get IMSI Request

HTTP GET

http://192.168.0.1:81/dialogicwebservice/signaling/getimsi

The HTTP GET is used to request the next Send IMSI received by SWS (note that the absence of the MSISDN).

The 20O – OK response code is the expected response to a successfully receive Subscriber State Request, it will have payload of the following form:



<getImsi version="1">



</getImsi>

HTTP PUT

http://192.168.0.1:81/dialogicwebservice/signaling/getimsi/2231

The HTTP Put request is then used to return the result of the Get IMSI response to the network. For a successful response the XML payload will have the following form:


97




<imsi>3301212323</imsi>


</location >

DSI SS7G41 Signaling Server - Dialogic | Cloud-Optimized...

Documents

Transcript of DSI SS7G41 Signaling Server - Dialogic | Cloud-Optimized...