Chapter 2shodhganga.inflibnet.ac.in/bitstream/10603/6109/10/10_chapter 2.pdfThese numbers are network specific and do not carry the same meaning outside of the home . Chapter 2 Ubiquitous

Chapter 2 Ubiquitous SMS Routing

Ph.D Thesis of Asoke K Talukder 29

Chapter 2

Ubiquitous SMS Routing 2.1 Introduction

For an independent SMS application/service provider, any technology should be open,

interoperable, and operator independent. Carrier-grade SMS-data technology that is used today is

not interoperable. For example, Indian Railways offer advance booking of seats 60 days in

advance. A tourist in London who plans to visit India during vacation should be able to reserve

seats sitting in UK using her mobile phone. This is not possible today; a mobile subscriber cannot

access an application offered by a foreign PLMN. The same challenge persists for other

applications like sensor networks, building automation or SCADA services. In principle, a service

provider should be able to route SMS-data originating from any mobile phone in any network to

any application or origin server.

As mentioned in previous chapter, it has been observed that till date, there are two

technologies available for SMS-data bearer viz., Over-The-Air GSM (OTA-GSMM) modem

technology and Carrier Grade SME (CG-SME) technology. CG-SME is used by the network

operators for voicemail alerts and SMS based content and services. CG-SME is carrier-grade and

scalable; however, CG-SME is network centric and does not allow network neutral SMS-data

routing. OTA-GSMM technology on the other hand is network neutral; but, does not scale. In this

chapter we go deeper into the CG-SME and OTA-GSMM technologies to explore the traffic

throughput.

Fixed line voice calls are interoperable; Mobile voice calls are also interoperable. SMS

point-to-point [GSM-03.40] is interoperable as well. However, when SMS is used as transport-

bearer or data, where one endpoint is a computer application, it is not interoperable. Each service

needs to be configured in the Gateway; and each gateway is identified through a code (generally

short code) that is configured in the Service Center (SC). This code can be of any size; can be

short (e.g., 333, 555, etc), can be long (e.g., 919845754367675438), can even be a Global title

(e.g., 919844285467). Even if the address of the service is a Global title, routing to the service

remains proprietary and is not interoperable; this is because the Global Title will be configured

locally on the SC and not on the HLR. Unless a user is subscriber of an operator, they cannot

access the service irrespective of the service code.



An operator should have the flexibility to offer a service to its customers at a premium.

At the same token, a content provider should also be able to provide its content to the public. The

Indian Railways services for example, are available to anybody in the world through their Web

site http://www.indianrail.gov.in. Anybody in the world can use this Web site to book ticket or

enquiry the ticket availability or status. However, when it comes to accessing these same services

through SMS-data, it is available only to Indians living in India through some mobile operator in

India. For an example, let us assume, a foreigner is visiting India, with a mobile phone and being

a subscriber of a GSM network of his/her country; this foreigner is traveling in Indian Railways

and being a customer of Indian Railways cannot access the above services using a GSM network

as a roaming customer in India. As a passenger or customer of Indian Railways he cannot use his

mobile phone to check whether a “Wait Listed” ticket has been confirmed. Regulators need to

step in when there is a fight on “Who owns the customer”. For premium content like “Cricket

Score”, it is the operator or the content provider who owns the customer and they can charge a

reasonable amount for the content. In the thesis this is referred as OCC (Operator Centric

Content) (Section 2.6.2). However, in case of Indian Railways, it is the Railways who own the

customer. In the thesis this is referred this type of content as CCC (Consumer Centric Content).

Therefore Railways need to offer the service over SMS to everybody around the world through a

code like 9844637245 (984INDRAIL) for example while they continue to offer the service

through short code like INDRAIL (4637245). Therefore, to use SMS as a transport bearer, the

SMS needs to be routed to a destination chosen by the service provider.

In this chapter, we present our contribution through the introduction of novel USRS

(Ubiquitous SMS Routing Service) technology [AKTTW2004, AKTUS2005] that can route

SMS-data from any mobile phone roaming in any network to any service in the Web. USRS

technology offers ubiquitous routing of SMS-data that is network neutral and scaleable. This

technology will solve the mobile Web challenges discussed above. In this chapter, we look into

the USRS protocol and analyze the traffic capacity through simulation modelling. We also look

into the results obtained from USRS implementation in a live GSM network in India along with

real-world implementation of other technologies.

2.2 Ubiquitous SMS Routing Service (USRS)

In this section, we introduce Ubiquitous SMS Routing Service (USRS) technology and protocol –

that is carrier-grade, PLMN neutral, ubiquitous, and scalable. It has been mentioned earlier that,

carrier-grade SMS services are accessed through short SDSIs number like 333, 555, 7827 etc.

These numbers are network specific and do not carry the same meaning outside of the home



network. In one network SDSI 555 may carry a weather service, in another network 555 may be a

restaurant guide, in another network there may not be any service at all on 555. Therefore, to have

a ubiquitous service – we need to have a SDSI that is global and static. In telecommunications

networks we have a concept of non-geographic numbers. A non-geographic number is a virtual

number – not associated with any specific network. A non-geographic number is specific to a

country and assigned to a subscriber; whereas a geographic numbers (in blocks of 10,000) are

assigned to network operators in hierarchical fashion within a region. We discuss this in detail in

Chapter 3 in the context of number portability. Examples of geographic number is 918025211234

whereas, non-geographic numbers will be 1-800-xxxxxxx, 1-888-yyyyyyy, 1-900-zzzzzzz etc in

USA. In India 1-600-xxxxxx are used for non-geographic toll free numbers.

In telecommunications network, the mapping between a non-geographic number and a

physical link is done through the mechanism of Global Title Translation (GTT). Through GTT, a

dialled number (which is a non-geographic virtual number) is translated to get a circuit number

where the call will be routed. Similarly, the routing of SMS from an MS to any data services is

achieved through masked SDSI. The USRS is an intelligent node within the SS#7 network and is

outside the scope of administrative control of the home SC or the serving network.

2.3 USRS Building Blocks

The USRS has the following major components and functions (Figure 2.1):

• MSC/VLR interfaces: This module is a RCP (Route Control Point) responsible for all

functions related to the SMS routing and management.

• Service Interface: This module works as the client interface to the origin server and

responsible for forwarding the SMS request to the application through proper API.

• SME proxy interface with HTTP server: This module works as the server interface to

the origin server and responsible for accepting the SMS request from the application

through proper API either as the response of a previous request or an notification, alert,

or unsolicited response..

• SC interface: This module handles the SMS-SUBMIT, SMS-DELIVERY functions.

• Configurator: This module handles the management of USRS. This also maintains the

SDSI numbers and their associations with foster network and the applications.



Figure 2.1: USRS Building Blocks

Figure 2.2: USRS MSC/VLR architecture

2.3.1 MSC/VLR Interface

The MSC/VLR module manages the SS#7 MAP (Mobile Application Part) interfaces. The

MSC/VLR server is depicted in Figure 2.2. This module is responsible for sending the location

update messages periodically to various HLRs in respective foster networks (described in Section

2.4) using the services of the underlying SS#7 services. The periodicity of this update is

Ubiquitous SMS routing App Core

System Management Entity

SS7AL Timer

SS7 Stack

External Database

DBAL

CLI

Origin Server

USRS Server GSM

Alert Message

MSC/VLR interface

Service Interface

HTTP Server

SC interface

Internet

Pull Request

Pull Response

USRDB

Configurator



configurable. The default is once every ½ hours. This module is responsible for accessing the

database for the virtual number authentication and details.

2.3.1.1 Ubiquitous SMS Routing Application Core

This module will handle all the core functions related to the SMS message transfer. It will

validate the SMS addresses in the SMS message. If the addresses are not in revoked or black list,

the SMS will be forwarded to the HTTP client It is also responsible for sending periodic

invocation of location update message towards the SS7 stack, etc.

2.3.1.2 SS7 Stack Adaptation Layer (SS7AL)

This module will act as adaptation layer for the ubiquitous routing. This module will convert the

messages from the SS7 stack to the format that is acceptable by the Ubiquitous SMS Routing

Application. This module will need to be customised depending upon the SS#7 stack vendor.

2.3.1.3 Database Adaptation Layer (DBAL)

This module will hide the intricacies of interacting with the actual database server for any

database query. It will have interface with the Ubiquitous SMS Routing Application Core module

and the System Management Entity.

2.3.1.4 System Management Entity

This module will act as the internal management entity for the Ubiquitous SMS Routing Server

modules. This module will control all the system management activities. This module will

interact with the external management entities. The external management entity will be client

specific and may provide its own interface to its user (web based, etc.).

2.3.1.5 Timer

This module will handle the entire timer request by different modules of the Ubiquitous SMS

Routing Server. It will maintain a list of all the timer requests and their context in its internal

database.

2.3.1.6 Command Line Interface (CLI)

This module will provide the bare-bone interface functionality of sending specific management

messages to the System Management Entity of the Ubiquitous SMS Routing Server.



2.3.1.7 External Database

This is database accepting queries form the DBAL (Database Adaptation Layer) and responding

to them. The USRS database contains information specific to each SDSI. This data is generally

updated through the system management entity and database adaptation layer interfaces. Any

change in the SDSI parameters results in an update of this database. This includes following

information:

1. The SMS-data Service Identifier (SDSI) as the key

2. International Mobile Subscriber Identity (IMSI) related to this SDSI

3. The signalling point code and global title of the HLR in the foster network

4. The signalling point code, MSC address, and the VLR number of the USRS

5. Periodic location update message interval (this value depends on detach timeout period

and the detach cost that is explained in Section 2.6)

6. The URL (Universal Resource Locator) of the application in the Internet that will service

the SMS-data related to this SDSI

7. The ISDN address or the global title of the SC where the SMS needs to be redirected in

case of USRS-tunnelling

8. Optional security related information to block SDSI access

9. Accounting related information required to calculate charges for a service

10. Administrative data related to the SDSI (like address, contact details, customer since, etc)

2.3.2 SME Proxy Interface with HTTP Server

This has the http server interface. HTTP server interface is used for applications to send

unsolicited SMS alerts, notifications, and Push messages to MS. If the security criteria do not

match, the SMS is dropped. This is the standard Kannel SMS/WAP gateway [Kannel] integrated

and customized for the USRS need. For this function the sendsms module of Kannel is used. To

send an SMS from an application following http command is used.

http://usrs.domain.name:13013/cgi-

bin/sendsms?username=usrsuser&password=usrs&to=919834212345&text=Hello+

World

All information is stuffed into one HTTP GET request that executes the sendsms command in the

USRS HTTP Server. In the above example, the sendsms interface sends an SMS message “Hello

World” to the MS with MSISDN number 919834212345. To access the sendsms command, the

user needs to enter username and password through the respective parameters.



2.3.3 Service Interface

The service interface is used to access Internet sites or various services/applications through URI

as configured in the system through HTTP APIs interfaces. If the SMS meets the security criteria,

it parses the keyword and forwards the message to the appropriate origin server through http/https

interface. We have integrated the open source Kannel [Kannel] SMS gateway function with the

USRS. The configuration of Kannel has not been changed within the USRS. In Kannel, URLs

(Universal Resource Locator) are configured based on the keyword. For example following are

the configurations for USRS.

# Live Cricket group = sms-service keyword = cri url = "http://apps.oserver.com/SMSApps/cricket.jsp?keyvalue=%a&mobileno=%p&smsc=%i&time=%t" max-messages = 5 # Joke group = sms-service keyword = joke url = "http://apps.oserver.com/SMSApps/joke.asp?keyvalue=%a&mobileno=%p&smsc=%i&time=%t" max-messages = 5 # News group = sms-service keyword = news url = "http://apps.oserver.com/SMSApps/news.jsp?keyvalue=%a&mobileno=%p&smsc=%i&time=%t" max-messages = 3

When the SMS is received by the USRS, it looks at the keyword defined in the Kannel

configuration. Based on the keyword, it selects the appropriate URL. The service interface then

generates a HTTP GET command, embeds the SMS message to into the command and sends it to

the URL. For example, in the above configuration, when user with an MSISDN +919845912345

enters “NEWS SPORTS”, following URL will be activated:

http://apps.oserver.com/SMSApps/news.jsp?keyvalue=news%20sports&mobilen

o=919845912345

The response from the http site apps.oserver.com/SMSApps/news.jsp will then be

delivered to the MS as a response. The parameter max-messages = 3 tells the USRS Kannel



driver that if the response is more than 480 characters long, only first 480 characters (3 text

messages with 160 characters long) should be sent to the user as response.

2.3.4 SC Interface

This module is a miniature service centre. This module is responsible for sending SM MT

messages. This has interface to the SS#7 network. However, this module does not implement

some of the scheduling algorithms like priority, which are common in a carrier grade SC. This

module does an error-free delivery of the SMS to the target MS. If there is any error in delivery

due to some reason, like Power-Off, out of range, paging or authentication error, or network error

etc, it does not schedule it for retry. Instead the message is converted into an SM MO message

and submitted to the conventional SC of the host network. The SC delivers the MT message to

the MS according to its own delivery priorities and scheduling algorithms.

2.3.5 Configuration/Management Interfaces

This module is responsible for configuration and management functions of different function in

the USRS server. This module also is responsible for maintenance of the USRS database, SDSI

numbers, Foster HLRs, and the URI relationship. This module interfaces to the command line

interface (CLI) as described above.

2.3.6 Construction of USRS

USRS was constructed and tested in real-world live GSM network using the building blocks as

described above and using the following products and platforms:

• Septel SS7 E1 card

• Datakinetics Septel SS7 stack

• Intel Pentium PC with 800 MHz and 512 MB RAM

• Linux operating system

• Kannel Open source WAP and SMS Gateway

• C programming language

• MySQL database

2.4 USRS Architecture

The USRS is installed as an intelligent node within the SS#7 network. Any SMS service that

needs to be ubiquitous, network neutral, and accessible from anywhere, needs to have an SDSI



that is a global title. Example of such SDSI are +97394MYINC (+9739469462) or

+919811MYBANK (+919811692265). Figure 2.3 depicts the USRS element within the SMS

schematic.

Figure 2.3: Network architecture for ubiquitous SMS-data through USRS

USRS server is an entity (node) installed in the SS#7 network as an MSC/VLR. It

includes partial functionality of an SC, SME, and HTTP proxy. The USRS has a Signalling Point

Code [ANSIPC] and a Global Title. In the context of USRS, we define different networks. Some

of these networks are relevant in number portability scenario described in detail in Chapter 3.

These networks are:

1. Serving Network: Network currently servicing the MS – network where the MS

is currently located. While roaming, this will be the foreign network.

2. Foster Network: For universal access of the SMS-data service, the SMS-data

service needs to carry an SDSI that is a Global Title. Foster network issues the

SDSI GT from its number range. Unlike in telecommunications network, there is

no standard for non-geographic number for SMS. Therefore, for the purpose of

this work and realization of USRS, the service number is assigned from a number

HLR – Home Location Register MS – Mobile Station MSC -- Mobile Switching Center SC -- Service Center

SMS-GMSC – SMS Gateway MSC SMS-IWMSC – SMS Interworking MSC USRS – Universal/Ubiquitous SMS Routing Service VLR – Visitor Location Register

Host Network with USRS

Home Network

of Sender Foster

Network

SCA

MSA

MSC/VLR MSCV

VLRV

SMS-IWMSCA

Application Server

Serving Network (Visiting network)

Data Network

SMS-GMSCA USRS

SMSCH HLRA

Location Update (VMSC=USRS

Routing Info (VMSC=USRS)

Send Routing Info

HLRB



range allocated from a geographic number. Though in practice, this number is a

virtual masked number, for this implementation a real number is used as a virtual

number.

3. Host Network: The USRS server is an MSC/VLR node in the SS#7 network.

This will have a Signalling Point Code and a Global Title. This GT/Point code

will be part of an existing network. The Signalling Point Code assigned to the

USRS is associated with the Host network. This can also be defined as the

network where the USRS server is installed.

4. Data Network: This is the network which is servicing the data service or the

application.

During roaming, as an MS enters a new PLMN, it is authenticated by the foreign or

visiting (or serving) network. If the authentication is successful, the MS is registered in the

visiting network. Information from the HLRB (HLR of MSB) is copied to the visiting VLRV

(Visitor Location Register of the visiting network serving MSA). The visiting PLMN assigns a

roaming number called MSRN (Mobile Station Roaming Number) {AKTMC2005] to this new

MSB. The MSRN is sent by the MSCV/VLRV to HLRB. Also, the address of the MSCV/VLRV that

is serving the MSB is sent to HLRB. The serving MSCV/VLRV address is stored as the VMSC

(Visited MSC) address field within the HLRB. For incoming voice call, the call is routed to the

roaming MS – using the MSRN. Whereas, for SMS, VMSCV address is used to locate and route

an SMS.

Though the USRS SDSI number is a virtual masked number, the HLRB in the foster

network will be updated with some valid identifiers like IMSI (International Mobile Subscriber

Identity), MSISDN etc corresponding to the SDSI. This MSISDN (SDSI) number will be used by

a user to access the ubiquitous SMS based application service. This SDSI number is a virtual

masked number without any SIM card associated with it. One USRS server can support many

virtual SDSI numbers from various Foster networks. They can even be from different countries.

For example, a bank in Spain can have a Spanish number. Though not necessary, the same bank

in Muscat, may like to publish a Muscat number. If majority of the customers of an enterprise is

from a region, a regional number may help branding. Also, in certain networks domestic SMS is

cheaper. For the purpose of branding and easy to remember, the non-geographic virtual global

title can mask as a geographic number.

These SDSI numbers along with the respective IMSI from different Foster networks will

be stored in the USRS database (USRDB). The respective point-codes and the global titles of the

HLRs from the respective Foster networks will also be stored in the USRS database. Also, the



URI (Universal Resource Identifier) of the application in the origin server is saved in the database

respective to an SMS keyword of a service. Information stored in the USRS is:

1. SDSI numbers of the SMS service (e.g., +447775502MYINC)

2. The IMSI associated with each SDSI

3. The Signalling Point-code and the Global title of the HLR in the Foster network

owning this MSISDN (SDSI)

4. The URI for the service is an http URL pointing to an application in the origin server

in the service network.

For all these masked SDSI numbers, the USRS server periodically sends location update

messages to the HLRs of respective Foster networks through the SS#7 interface – using MAP

(Mobile Application Part) service message (MAP_UPDATE_LOCATION) [GSM-09.02]. In this

location update message the VMSC (Visiting MSC) address will be the address of the USRS

server. The location update messages make the HLR in the Foster network informed that the

IMSI is now roaming in a foreign network. As the VMSC address points to USRS, the Foster

network HLR believes that the IMSI is being services by the USRS functioning as an SSP

(Service Switching Point) that owns the MSC/VLR.

2.5 Ubiquitous SMS Routing

To offer ubiquitous SMS-data service, the challenge is that the SMS-data request needs to be

delivered to the USRS from any SC of any network. The USRS will then forward these SMS-data

request to the application in an origin server. The steps followed for one transaction is depicted in

Figure 2.4 and will be as following:



Figure 2.4: The USRS Routing Procedure

1. SDSI with virtual IMSI and the virtual MSISDN numbers (e.g., 4477755MYINC,

9198371APARK etc) are created in the HLR database of different Foster networks.

2. The USRS database is updated to include all these SDSI virtual numbers and the address

(Global Title) of respective Foster HLR.

3. The USRS server periodically sends location update (MAP_UPDATE_LOCATION)

MAP service message to the respective Foster HLR and updates the VMSC field in the

HLR entry for all these virtual SDSI numbers so that VMSC address for all these SDSIs

are set to the USRS address in the respective records.

4. The Mobile User sends an SM MO requests to a SMS service carrying a SDSI (e.g.,

4477755MYINC) using her own MS. The MS can be from any network roaming in any

other network. The MSC of the serving network will deliver the SM MO to the SMS-

IWMSC. SMS-IWMSC will then submit the SMS to the home SC.

5. The SMS is submitted to the home SC of the sender (this can be any home SC of any

network).

6. The home SC then tries to deliver the message to the virtual number (SDSI).

SC (Home Network)

SMS-GMSC (Home

Network)

HLR (Foster Network)

USRS (Host Network)

1a

2

3

3a

1b

1a – Message transfer 1b – Delivery report 2 – sendRoutingInfoForShortMsg 3 – forwardShortMessage 3a – Delivery report



7. The SC does an HLR Query through its SMS-GMSC (Step 1a and 2 in Figure 2.4). The

query comes to the Foster network HLR (to UK for virtual number 4477755MYINC or to

India for 9198371APARK).

8. The HLR sends the VMSC address (which is the number of USRS) and virtual IMSI as a

response to query message (Step 2 in Figure 2.4).

9. The SC then sends the MT “forward SM” message to the given VMSC address (Step 3 in

Figure 2.4). The VMSC address is the address of the MSC/VLR, which is also the

address of the USRS server. The “forward SM” message is delivered to the USRS server.

10. The USRS now accepts this MT “forward SM” message, parses it and extracts the

relevant fields. The SME function of the USRS forwards the request to the application

through proper API. The delivery report is sent to the SC (Step 3a and 1a in Figure 2.4)

11. The application server processes the message and sends the response back to the USRS

through an API.

12. The USRS sends the response back to the MS as an SM MT message. Due to error

conditions (MS out of reach/power off), if the transfer is unsuccessful, the SMS is

submitted to an SC within the host network for retry and delivery at a later time.

It is interesting to note that the SMS request has been routed to an application server which is not

connected to the SC of the home network through SME.

2.5.1 An Example of SM MO Routing through USRS

Let us go through each step to illustrate the functions of USRS. Assume that an independent

service provider in Mumbai, India called MyInc offers an ITS (Intelligent Transportation Service)

service “Acme Parking” to reserve a parking spot through SMS. The car park service is in

Bangalore with service number +9198448APARK (+919844827275). The service number

919844827275 is taken from the Spice network in Bangalore. Spice network is the serving

foreign network with mobile country code MCC = 404 (India) and mobile network code MNC =

44 (Spice). A person from Delhi travels to Bangalore. This person is a subscriber of Airtel

network in Delhi and registers in the Hutch network in Bangalore while roaming. While roaming

in Bangalore, this person wants to book a parking spot managed by “Acme parking” using his

own mobile phone. In the classical SMS-data model it was not possible for a roaming subscriber

to use a SMS-data service in foreign network.

The origin server of this ITS company (Acme parking) is located in Mumbai in India.

The USRS server is installed in the Escotel network (at Meerut, a place 200 Kilometres from

Delhi) in India. We defined this network as the host network. The ISDN number assigned to this



USRS server is +919837099975. Between the USRS system in Delhi and the Acme Parking’s

origin server in Mumbai a secured data connection is set up.

While roaming in Bangalore, the Delhi (Airtel) subscriber sends an SMS request “PARK

FORUM” from his mobile phone (MSISDN number +919811012345) to +9198448APARK to

book a parking spot. The SMS-IWMSC function in Hutch network in Bangalore looks at the

message and finds that the SC address (ISDN number +919810051914) in the SMS is of Airtel

network in Delhi. The Hutch MSC submits the SMS to the SC in Airtel network through Airtel

SMS-IWMSC in Delhi.

In the Airtel network in Delhi, the home SC (+919810051914) looks at the SMS message

and finds that this message needs to be delivered to a number +9198448APARK in Spice network

in Bangalore. The SC sends the SMS (Figure. 2.2) as transaction 1a (Message transfer) to the

home SMS-GMSC of the target MSISDN (9198448APARK). The home SMS-GMSC sends

transaction 2 (sendRoutingInfoForShortMsg) to the Spice HLR. The Spice HLR of this Bangalore

network is updated earlier through a MAP_UPDATE_LOCATION transaction from the USRS

server to indicate that this number is currently roaming in Escotel (the host network). The Spice

HLR points to MSC/VLR of the Escotel network with ISDN number +919837099975. This

MSC/VLR (+919837099975) in reality is our USRS server. The home SMS-GMSC does the

transaction 3 (forwardShortMessage) to the USRS. The USRS server picks this SMS and

processes it. The USRS server shortcuts the transactions sendInfoForMO-SMS and

Message_transfer respectively. It sends transaction 3a (Delivery report) to the home SMS-GMSC

(Bangalore). The SMS-GMSC sends the Delivery_report as transaction 1b to the Airtel SC in

Delhi. The Airtel SC in Delhi delivers the delivery report to the Airtel subscriber roaming in

Bangalore (Hutch).

Though the service number is from a network in Bangalore, and the user is from Airtel in

Delhi roaming in another network in Bangalore, the SMS has been forwarded to the USRS server

in Meerut near Delhi. The SMS message is parsed in the USRS server like any standard SME and

found that it contains a keyword as PARK. An HTTP request is formed for the corresponding

keyword. The body of the SMS message is sent to the URL as parameter. The MSISDN number

of the sender (+46705583080), timestamp etc. are also sent as parameters for the HTTP request.

In the Acme Parking’s origin server in Mumbai the URL is processed. The authentication is done

on the IP address of the USRS server and the MSISDN number of the sender. The parking system

processes the request, reserves a parking slot in the Forum Mall, and sends back the response as

an MT message with the parking slot number. It may be noted that the SMS is forwarded from

the SC in Airtel network to a server in Mumbai without having a direct connection between the



home SC and the Origin Server. The user pays the parking fee through SMS by sending a

message “PAY” to +9198448APARK. The system had start time and the end time of the parking.

Based on the charges, the parking system calculates the fee and sends a barcode to the mobile

phone. The user shows this SMS to the machine at the exit gate of the parking. Payment can be

done through electronic wallet or the fee can be paid by cash at the exit point of the parking lot.

Using the USRS technology, a roaming user is able to use own mobile phone to use a foreign

SMS-data service while roaming in foreign network.

2.6 Location Update Interval and Associated Cost

In Section 2.4 and 2.5 we mentioned that USRS sends location update message to HLR in the

foster network. It updates the VMSC field in the HLR; also, it keeps the IMSI attached to the

HLR. In the absence of location update – the HLR assumes that there is no contact between the

IMSI and the VLR; therefore, following the detach timeout period the IMSI of an SDSI is

detached. If the IMSI is detached, the “Send_Routing_Info” enquiry from the home SC towards

the HLR in foster network will fail causing service interruption in the USRS. To ensure that

USRS service is available in an uninterrupted fashion, IMSI of an SDSI must remain attached

through periodic location update. To keep IMSI attached, frequent location update will cost in

terms of the SS7 signalling traffic; therefore, it is advisable that location updates in USRS are

optimized. In this section we describe the procedure to select the optimal location update interval.

When the mobile station is within a network, the MS needs to be tracked for mobile

terminated calls and mobile terminated SMS. This requires the MS remain attached to the

network and updating its location information in the VLR and the HLR. Frequent location update

costs in terms of power in the mobile device and the SS7 signalling traffic. Tracking through

paging on the other hand costs in terms of radio and backbone SS7 signalling bandwidth. When

an outgoing mobile originated call is made from the MS, or the MS moves to a new location area

(LA), an implicit location update occurs. If there is no mobile originated call or LA crossover, an

explicit location update is necessary. There are 3 basic techniques that are recommended for

explicit location update [Bar-Noy1995]. These are:

1. Distance-based scheme -- in this scheme, the MS updates the location co-ordinates when

its location is more than k cells away in distance from the location of the last update.

2. Movement-based scheme -- in this scheme the MS provides an update when it crosses

exactly k cell boundaries irrespective of the distance.

3. Time-based scheme – in this scheme the mobile provides a periodic update exactly once

every t time units irrespective of cell location or distance.



Taking paging and location update in consideration, authors in [Bar-Noy1995] proved that time

based scheme is most costly; whereas, distance based scheme being least costly.

i.e., CDistance � CMovement � CTime (1)

In case of USRS, an SDSI behaves as if it is an MS roaming in the host network; though, there is

no physical device that is moving or needs to be tracked. Therefore, in case of USRS, the cost is

governed by time-based location update scheme without any cost for paging.

When an MS is powered off an explicit IMSI detach occurs; if there is no successful

connection between the MS and the network for an operator defined interval, implicit IMSI

detach occurs. IMSI attach is accomplished through mobile originated calls, location area update,

or explicit periodic location update. The time-out value for the periodic location update timer

needs to be within the range of 1 deci-hour to 255 deci-hours with a granularity of 1 deci-hour

[3GPP-23.122]. IMSI detach is equivalent to HLR data for the particular IMSI is not available. In

the case of an entire HLR database failure – all IMSIs in an HLR are logically detached. In such

failure, the HLR informs the associated MSCs to trigger the VLR to perform a location update

towards the HLR in order to restore the HLR database [3GPP-29.018]. To resume the service

following a service black-out, HLR and USRS perform the same function of location update.

Therefore, procedures used to calculate the cost of failure for an entire HLR database can be

extended for a single IMSI failure (in USRS) as well. In other words, to an MSC/VLR (USRS in

this paper) the effect of HLR failure or IMSI detach is same. In [Haas1998], authors have

calculated the location update cost with respect to entire HLR failure. We have extended this

procedure for IMSI detach to calculate USRS detach cost. In case of IMSI detach, the total cost

will be (as derived in [Haas1998]) expressed through (2).

(2). Where CTotal is the total cost related to location update and the cost involved due to business loss

for non-delivery of SMS to the USRS; c1 is the cost related to single non-delivery of SMS; cu is

the cost due to single location update; Tf is the mean time between IMSI detach; Tp is the constant

time interval between two location update messages; pL(n) is the probability that after an IMSI

detach, n SMS are sent before the next IMSI attach. To evaluate optimal cost for location update,

authors in [Fang2000] normalized the total cost in equation (2) by cu, then differentiated the

c1 CTotal =

Tf � n=1

� cu

Tp + npL(n)



normalized cost in equation with respect to Tp and set it to zero to analytically arrive at the

stationary equation,

1 – e–y – ye–y = a (3), where, y = �uTp (4), and, a = �u

2Tf /(c�a) (5). In equations (4) and (5), �u is the combined rate of call originations from the MS and location

area (LA) crossing events by the MS and will be equal to �o + �c, where �o is arrival rate of

mobile originated calls from the MS, and �c is the rate of crossing the LA boundaries by the MS;

and �a is the arrival rate of mobile terminated calls.

Equation (3) can be solved only for values where 0 � a < 1. This means that there lies a

value for y* for which implicit location update is not sufficient; an explicit location update is

necessary [Fang2000]. However, for values of a where 1 � a < �, the implicit location updates

through mobile originated calls and LA are sufficient and the arrival rate can be calculated as,

�u = �(ac�a/Tf). (6).

If an MS is stationary and there is no outgoing call from the MS, implicit IMSI attach

does not happen; in this case a location update from the MS must happen to keep the IMSI

attached to the HLR. For a particular SDSI, the foster network is masked as if the IMSI is

roaming in the host network managed by the USRS. The USRS server is stationary and there is

no physical MS associated with this IMSI to initiate an outgoing call, therefore to the HLR in the

foster network the periodic location update is the only means to have the IMSI attached. In case

of USRS therefore, the location update interval will be 1/�u. Considering cost due to loss of

message to be 1¢ and a location update costs of 1¢, c (= c1/cu) will be 1. If we assume IMSI

detach timeout to be 48 hours, we have Tf = 172800 seconds. Let us assume that 50,000

customers of a bank use mobile payment and make average 1 mobile banking transaction per

week; then we have �a to be 0.08, and �u = �((a * 1 * 0.08)/172800). Making a = 1, we get �u as

1/1470 or an intra-arrival time of 1470 seconds; i.e., 24 minutes and 30 seconds. Therefore, the

location update interval for this SDSI in the foster network will be 24 minutes (4 deci-hour).

For the above bank, let us now take another case where the location update interval is

chosen to be 30 minutes (5 deci-hour); therefore �u evaluates to 1/1800. For this case, a will be,

a = (1/1800)2 * 172800 / (1 * 0.08) = 0.666666. To solve the equation (3) for a = 0.666666, the

value of y* = 2.289. Therefore, the explicit location update interval from equation (4) will be,



Tp = y / �u = 2.289 / (1/1800) = 2.289 * 1800 = 4120 = 68 minutes. This implies that average

location update interval will be 24 * 2 + (24 * 60) / 68 = 69 updates in 24 hours making the

average location update interval to be 21 minutes.

2.7 Experimental (Simulation) Setup

As a part of the research, we have taken each of the technologies viz., CG-SME, OTA-GSMM,

and USRS and did thorough experiments. Experiments include examining the traffic pattern and

performance with respect to traffic simulator. We also realized all the technology models in real

world scenario and measured the capacity of these technologies. We discuss these experiments in

the following sections.

2.7.1 Simulation Modelling Methodology

To simulate the traffic pattern and delay for SMS, we had two options: either to develop a

simulator specifically for this problem or to use a standard, stable, reliable, and tested simulator.

As the basic purpose of this research is to develop a routing protocol for ubiquitous SMS, we did

not attempt to develop a network simulator for SMS. We instead, looked at the available discrete

event simulators. We looked at veracity of the simulator as critical factor, compared to the

efficiency of the simulator. A home-grown simulator can be faster and efficient; however, the

veracity of this simulator can not be guaranteed. We therefore, looked at two most widely used

simulators. These were NS2 [NS2], and OMNeT++ [OMNeT-3.1]. NS2 is a reliable and widely

used network simulator. NS2 has rich set of libraries. However, our investigation made us to

believe that NS2 is more tuned towards TCP/IP networks. OMNeT++ on the other hand does not

assume any specific network. Therefore, we selected OMNeT++ Version 3.1 [OMNeT-3.1].

OMNeT++ is a discrete event network simulator developed by András Varga [Andras2005].

OMNeT++ model consists of hierarchically nested modules. Modules communicate through

message passing. Modules send messages through user defined gates and connections.

OMNeT++ offers a framework with different statistical and queue libraries. Network topology is

defined using the NED language. Traffic flow, protocols are programmed in C++ using the

simulation library. OMNeT++ offers a very rich set of graphical tools to define the network,

plotting of graph. OMNeT++ has been used in many domains. Examples are simulation of

TCP/IP network (IPv4), simulation of IPv6, Ad-hoc networks etc [Imre2001, Imre2002,

Imre2003, Drytkiewicz2003, Idserda2004, Bless2002, Mallanda2005, Csegedi2002, Rózsás2003,

Wu2005].



SMS is memoryless. One SMS is independent of any other SMS in space and time.

Unlike voice calls in a telecommunications network, SMS can withstand delay. SMS is store-and-

forward, if any part of the network between source and destination is temporarily unavailable,

SMS is not lost. The arrival pattern of SMS is therefore considered to be random following

exponential distribution. Hence, we have considered Markov model to evaluate delay

[Gross2002] for both OTA-GSMM and USRS systems. For the purpose of simulation, we have

used following analysis to generate exponential arrival pattern of SMS packets. The cumulative

distribution function [Gross2002] of the exponential arrival is given by,

X = 1 – e-GT (7)

Where, X is cumulative distribution, G is average arrival rate of SMS packets, T is the duration in

time when the packet has arrived. The above Equation (7), we can express in natural logarithm

form as,

GT = -ln(1-X) (8)

X being the cumulative distribution, 1 – X has values between 0 and 1. If the numbers X are

uniformly distributed, so also are the numbers 1 – X, hence, we can simplify the above Equation

(8) as,

T = -ln(X)/G (9)

X is generated using the standard pseudo random function. It is normalized to get a value between

0 and 1. From the above Equation (9), we found out the simulation steps to evaluate the SMS

arrival time with respect to an average traffic.

By above methodology we find out SMS-data-request packets arrival time. Then, we

simulate queuing delay in OTA-GSMM and USRS architecture. The total delay in OTA-GSMM

(DGSMM) and USRS (DUSRS) systems are, respectively,

DGSMM = QGSMM + PGSMM + TGSMM + FGSMM (10)

DUSRS = QUSRS + PUSRS + TUSRS + FUSRS (11)

Where, QGSMM, PGSMM, TGSMM, FGSMM and QUSRS,, PUSRS,TUSRS, FUSRS in equations (10) and (11) are

queuing, processing, transmission, and content fetching delay at OTA-GSMM and USRS

systems, respectively. We evaluated the delay OTA-GSMM and USRS by M/M/1 queuing

model.

Like in Internet, we assumed the traffic in OTA-GSMM and USRS to be asymmetric

where the size of the response message from the application is greater than the request message.

For simulation, we have assumed the following parameters:

1. SMS-data request message size to be 10 octets,

2. SMS-data response message size to be 70 octets,



3. Every SMS message has 24 octets of SMS header [GSM-03.40] added to messages,

4. For transmission of SMS through SS#7 network, the data-rate if 64000 bits/second,

and

5. For transmission of SMS over the air, the data-rate is 315 bits/second (best case).

6. According to www.internettrafficreport.com, average response time in Internet is 250

ms (measured using ping command). Load for HTTP protocol being about 5 times

that of ping, and keeping some time as safety time, we assumed that the average fetch

time from the application server in the Internet is 1.5 seconds. This time includes the

time of network transmission and the processing time by the application in the origin

server. The distribution of service output is considered to be exponential.

2.7.2 Simulation Modelling for CG-SME

Fakesmsc [Fink2004] is a simulation tool for SMSC (SMS Centre or SC) to test Kannel SME.

We used this simulator to test the performance of CG-SME architecture. The usage of fakesmsc is

as follows:

fakesmsc [options] <message1> [message2 ...]

A typical fakesmsc command can be:

fakesmsc -i 0.01 -m 180000 "919844012345 333 text NEWS SPORTS"

This tells fakesmsc to send 180000 messages with an interval of 0.01 seconds. Each message is

from a device with MSISDN number 919844012345, to SDSI number 333 with message ’NEWS

SPORTS’.

Figure 2.5: SMS OTA-GSMM Simulation Model

Over the Air

SC

HLR MS

Modem Read

Content over Internet/ Intranet

Modem Write

Get Content

FIFO Queue

Scope of OMNeT++ Simulation



2.7.3 Simulation Modelling for OTA-GSMM

For the SMS traffic over the air, we used the topology model of OTA-GSMM as shown Figure

2.5. In this model, the user sends an SM MO from the MS. Same is delivered to the SC. The SC

checks the HLR of the target MS (the service number) to obtain the routing path. Once the

routing path is obtained, the SC forwards the SMS to the OTA-GSMM over the air. The OTA-

GSMM is having three functions; viz., “Modem Read”, “Modem Write” and “Get Content”.

“Modem Read” function reads the SMS from the COM1/COM2 serial interface using the

AT+CMGR command [GSM-07.05]. Following the successful read of the message, the message

is passed to the “Get Content” module. The “Get Content” module parses the message.

Depending upon the type of query, the “Get Content” module services the query itself or obtains

the content from external source. This content is then delivered to the “Modem Write” module.

“Modem Write” writes the message on the COM1/COM2 serial interface. This is transmitted by

the GSM modem back to the user’s MS. In our model for simulation, we have simulated only the

OTA-GSMM part. The network leg from user’s MS to SC and SC to user’s MS are not included

in our simulation. Also, we have not added the time required by the SC for HLR query. This is

because, in case of SMS transmission, SC to HLR query is common for any type of architecture.

Figure 2.6: USRS topology for HTTP URL as Service URI

2.7.4 Simulation Modelling for USRS

For the SMS traffic over USRS, we used the topology model as shown in Figure 2.6. In this

model, an SM MO is delivered by the SC to the USRS. The USRS will process the SMS and send

the response back to the MS. Like the model of OTA-GSMM, the scope of the simulation is only

the part from SC to USRS and back to SC. Other portions of the network have not been included

Scope of OMNeT++ Simulation

SC

SMS Read

HLR

Get Content

FIFO Queue

Content over Internet/ Intranet

SMS Write



within the simulation. Like the OTA-GSMM, the USRS for HTTP URI has three major functions.

These are “Read SMS”, “Get Content” and “SMS Write”.

The USRS will read the SMS using the “Read SMS” module. It will parse the SMS and

forward the same to a “Get Content” (HTTP client interface) for fetching the content. The

response from the content server will be sent back to the MS through the SC.

2.8 Results and Discussions

In this section we present the results of various simulations we performed.

2.8.1 Simulation Results on Performance of CG-SME

CG-SME technology scales. As mentioned earlier, for our experiment, we choose Kannel open

source WAP and SMS gateway. Kannel is a carrier grade SME developed by Kannel.org

[Kannel, Fink2004]. Kannel is used widely by many network operators as carrier grade SME.

Kannel offers an interface called “Fakesmsc”. As the words signify, Fakesmsc is a “Fake SMS

Centre”. Fakesmsc is a SMSC or SC simulator. Using fakesmsc, SMS traffic can be generated to

test the scalability of Kannel. An example command to run the SMSC simulator in Kannel is:

fakesmsc -i 0.01 -m 180000 "919844012345 555 text NEWS SPORTS"

This command instructs the fakesmsc to run the simulator to send 180000 SMS message (the -m

flag) at an interval of 0.01 seconds (the -i flag). The message will have originating MSISDN as

919844012345 and the destination MSISDN as 555. The message that will be sent to the SME

from the fakesmsc will be “NEWS SPORTS”. Using SMPP protocol through fakesmsc, in our lab

we could service more than 500 messages/second through Kannel SME. This results into a

performance of an SME of over 30000 messages in a minute. This gives a BHSM (Busy Hour

Short Message) of 1,800,000. However, in a live network, carrier-grade commercially available

SC services 20 to 250 SMS messages/second. This in other word implies that in case of CG-SME

architecture, the performance will depend on the service rate of the SC.

2.8.2 Simulation Results on Performance of OTA-GSMM

The simulation results depicted in Figure 2.7, Figure 2.8 and Figure 2.9 are related to the OTA-

GSMM. Figure 2.7 assumes the architecture to be half-duplex with single thread; whereas, Figure

2.8 assumes it to be full-duplex with multi thread (2 threads). Figure 2.7 records the result from

the half-duplex OTA-GSMM simulation model with M/M/1 where the fetching time for content

is assumed to be random with mean time of service of 1.5 seconds. Figure 2.8 records the results



from the OTA-GSMM simulation model with M/M/1 where OTA-GSMM is considered to be

with full duplex transmission with parallel threads of execution. In case of full duplex, both the

serial ports in the computer are used; one port (either COM1 or COM2) for read/receive and the

other port for write/transmit (COM2 or COM1 respectively). In half duplex or single thread

OTA-GSMM architecture, only one serial interface (COM1 or COM2) is used for both read and

write.

The average delay for an SMS from SC to OTA-GSMM in a half-duplex system under

best conditions is around 7.7 seconds; whereas in case of full-duplex system, the response time

under best conditions is around 7.2 seconds. We are able to maintain this response time with a

mean inter-arrival time of 8 seconds for half-duplex and 3 seconds for full-duplex system. In case

of half-duplex, queue starts build up if the inter-arrival time drops below 8 seconds. For full-

duplex, the same behaviour is observed when the inter-arrival time drops below 3 seconds. We

can also see that the queue build up at a faster rate in half-duplex compared to the same in full-

duplex transmission. Figure 2.9 plots the results in one chart with both half-duplex and full-

duplex.

Figure 2.7: Response Time for SMS OTA-GSMM with half-duplex



Figure 2.8: Response Time for SMS OTA-GSMM with full-duplex

Figure 2.9: Round Trip time for SMS OTA-GSMM with both 1 Thread and 2 Threads

Findings from these simulations are that, using OTA-GSM modem, we cannot get high

throughput. In other words, OTA-GSMM architecture does not scale. OTA-GSMM technology is



used in many applications with sensors. One of the most popular usages of OTA-GSMM

technology is in vehicle tracking. In this application, the location and speed of the vehicle is

captured using GPS (Global Positioning System). These data is then buffered and sent to the

controlling system through OTA-GSMM architecture offline at some fixed interval. In other

services for sensor networks, vehicle safety, or similar services, where data rate (and the volume

of data) is not high, OTA-GSM modem technology is well suited. However, for high volume

carrier grade services, OTA-GSMM technology will not be suitable.

2.8.3 Simulation Results on Performance of USRS

The result of the simulation is presented in Figure 2.10. The average delay is about 1.69 seconds

for a traffic rate of 50/second. Upto a traffic rate of 80 messages/second, the average delay is 2.03

seconds. When the traffic rate crosses 90, the queue starts building up. Figure 2.11 shows the

performance of OTA-GSMM and USRS together in one chary. To fit both in one chart, logarithm

scale is used.

Figure 2.10: Plot of USRS with http content fetch



Figure 2.11: Average delay versus average SMS traffic for OTA-GSMM and USRS systems

2.8.4 Results from Real-World Realization

All the technologies, architectures, and models described above have been implemented, realized,

and commissioned in real-world environment. In this section we present these results from live

experiments.

2.8.4.1 Results from Real-World Realizations of OTA-GSMM We implemented the OTA-GSMM model in real world environment. The architecture of OTA-

GSM modem is depicted in Figure 1.6. In the physical real world environment, we used Nokia

Data suite 3.0 [NokiaDS3.0] with Nokia mobile phone model 5110. Figure 1.7 shows one such

system. In this picture one end of the data cable is connected to a Nokia 5110 mobile phone. The

other end of the data cable is connected to the serial port (rear side of the laptop not visible in the

picture). Device driver for the 5110 mobile phone is loaded in the laptop.

Major challenge with Nokia data suite and similar GSM modem interfaces are that they

are all half-duplex. Though any PC generally comes with two serial ports COM1 and COM2,

Nokia data suite can use any one of them but not both. Therefore, in one computer only one

modem can be installed. The same port needs to be used for both input and output. Also, in case

of Nokia data suite the write is not successful (control remains with the driver) till an

acknowledgement (or an error) is received from the SC. This increases the service time required



for SMS write. With all these constraints, our benchmark results in the real world environment

show that the round-trip response time for 80 octets (10 octets for request + 70 octets for

response) is in the order of 8 seconds. This result also matches with the data rates recorded by

some literatures. According to [Hallikainen2000] the SMS speed is 160 bits/second. According to

Logica literature [Logica1999], the data speed of SMS over the air is 150 bits/sec. With an

effective data speed of 160 bits/second, a message of 80 octets will take 6.8 ((10+70)*8/160)

seconds. If we use one modem for both input and output, the throughput at steady state will be not

more than 8 messages/minute. The delay in real-world situation is higher than what we got

through simulation. One of the reasons is that we did not take the error rate of transmission into

account while modelling the OTA-GSMM.

2.8.4.2 Commissioning of USRS in Live GSM Network As mentioned earlier, the USRS technology was realized in real-world environment. The USRS is

tested and commissioned in a live GSM network in India. It is also being used commercially by

MVNO and mobile network operators. The USRS server scales up and able to offer ubiquitous

SMS routing to many commercial establishments in realtime situation. The USRS server has been

installed in the switch room of a GSM network in Meerut, about 200KM from Delhi. The GSM

host operator is “Escotel”, which is now part of a larger conglomerate called “Idea”. The GT

(ISDN number) for the same is +919837099975. It is connected to a MSC with ISDN number

+919837099998. It was tested for various numbers from different GSM Foster networks. These

Foster networks were “Escotel” in Kerala, “Airtel” in Delhi, and “Escotel” in Uttar Pradesh. This

service is currently being used by live customers of various corporations. The list includes many

financial institutes including banks in India, insurance companies in USA and credit card

companies in Australia.

2.8.4.3 Results from Real-World Realization of USRS We have tested the USRS technology through loop back test for a peak load of 100

messages/second. Our experiment shows us that the USRS technology is able to sustain a peak

load of 100 messages/second quite easily. This is a very good benchmark because, majority of the

carrier grade SC available throughout the world offer a SMS throughput rate between 20 to 100

messages/second.

This is a major achievement. In the current GSM modem technology (existing ubiquitous

SMS-data technology) maximum round trip (MS to GSM modem/application – application to

MS) throughput possible is 6 messages/minute per MSISDN. Whereas, in case of USRS we could

achieve a sustained service rate of 70 messages/second quite easily. This increases the throughput



in USRS to 700 times. USRS takes the ubiquitous SMS throughput from 7 to 4200+

messages/minute. This will result into a BHSM of 252,000.

2.8.5 Comparison of Results

We have examined different models of SMS routing. We present these results in Table 2.1.

Table 2.1: Summary of Results for Network Independent SMS

Technology Throughput/Hour Characteristic/Remark

CG-SME > 100 messages/second

(900,000 messages/hour)

Scalable, Network centric

routing, Limited by SS#7

throughput (64000bits/sec)

OTA-GSMM ~ 8 messages/minute

(480 messages/hour)

Network neutral routing, Does

not scale, Limited by over the

air radio channel throughput

(315 bits/sec)

USRS ~100 messages/second

(360,000 messages/hour)

Scalable, Network neutral

routing, Limited by SS#7

throughput (64000bits/sec)

2.9 Summary

In this chapter we looked at PLMN proprietary CG-SME model of SMS-data routing and network

independent ubiquitous SMS-data routing through GSM modem (OTA-GSMM) technology. We

have seen from simulation results and real-world implementation that CG-SME scales. We have

seen from simulation results and the live environment that using GSM modem, it is not possible

to get a throughput above 8 messages/minute. We have introduced our contribution, the USRS

technology, which is a scalable PLMN independent SMS-data routing protocol. We have

described in detail the USRS protocol and how it works. We have also modelled the network and

simulated its traffic conditions. We find that it is possible to reach a throughput of 90

messages/second without considerable delay. The USRS technology as proposed here have been

constructed, and commissioned in a live GSM network in northern India. The throughput we get

in live GSM environment matches with the simulation result. Also, using the USRS technology,



we are able to offer scalable network independent SMS-data routing for business critical carrier

grade applications in realtime. This type of routing will allow independent service creation in the

verticals like micropayment, vehicular applications, emergency services, or intelligent

transportation systems (ITS) applications. In the next chapter, we extend the idea of providing

ubiquitous routing of SMS-data to a portable number from one service provider to other.



Documents

Chapter 2shodhganga.inflibnet.ac.in/bitstream/10603/6109/10/10_chapter 2.pdfThese numbers are network specific and do not carry the same meaning outside of the home . Chapter 2 Ubiquitous