The IMS infrastructure provides a platform for various kinds of services like presence , location, push to talk,etc. There are lots of applications built on top of this platform. But ultimately, it is left to the user's discretion to try out each service and use it. Looking at the number of services and the kind of variations that can be provided on top of the IMS architecture, we cannot expect the user to try each of these services. This aspect has been the main motivation for our project. Instead of asking the user to download each and every service and try them, with the help of our framework, the user has to just register their preferences with the service provider. Then based on the user's profile/preference, relevant services are provided to the user. Thus the user is relieved of selecting the one best service provider from among the various service providers. All the user has to do is to setup his profile/preference. In the world of increasing service providers, the publish subscribe model (where the publishers of a service have registered themselves to a common framework and the subscribers have set their preferences for the services) seems the best way out.
Project Description
The framework aims at establishing a common framework wherein the providers of diverse services like weather service, traffic service, retail outlets register at one common place. The framework can be provided by the connection provider (ATT) itself, the registered users can then avail all of these services from one place as long as he is registered with the ATT for this service.
The current implementations of such applications/services cater directly to users. Each service is provided like a separate application which has to be installed/initiated separately whereas this prototype suggests an alternative approach in providing the services dynamically without the user having to initiate it. The use cases leverage most of the IMS technologies – Location server, Tomcat
Server, Presence Server, SIP Application Server(Sailfin) , Arbitrary Web servers. The use cases can be extended to use the other services like Helix Media server and the PTT Server.
Benefits to service providers and end users.
The publish subscribe model is advantageous to both the service providers as well as the end users.
The model provides a new form of advertising for the service providers. Apart from the conventional modes of advertising in newspapers , television and radio, the retailers are provided with a new mode of advertising in the form of discounts messages sent to the users within the vicinity of the store. The promotional messages are sent only to the users whose profile matches the product with a discount. In order to prevent the user from being spammed, the user is provided with a mechanism to control the number of messages by specifying the degree of match with his/her profile like strong match, average match and weak match, by setting the frequency of promotional messages, and by disabling his feature for a short period of time (basically changing his presence settings). The use case clearly explains when and how the promotional messages are sent to the user.

Case 1: Shopping Assistant - I
1.
The retailers(publishers) publish their promotion offers/ discounts on a regular basis with the service provider.
2.
Users(Subscribers) would have created a create a profile with their preferences for shopping
(like the items they are interested in)
3.
When the user comes in the vicinity of the mall (identified by the location identification module), the users profile is queried against the various publishers in the region.
4.
Depending on the match obtained by the framework, promotional messages with a code is sent to the user.
5.
If the user is interested in buying the product he might visit the store and produce the promotion code to the retailer to get the discount.
6.
If the retailer wants, he can store the promotion code and provide it to the framework provider. The framework provider can use this information to generate the statistics of the actual number of users utilizing the shopping assistant. If the retailer does not want the overhead of maintaining this infrastructure then he can just ignore the promotion code.
Case 2: Shopping assistant – II
1.
This case refers to another instance of the shopping assistant service wherein the service is offered by a third-party and is hosted at a remote location.
2.
In this scenario, the service information for the mall is hosted at the mall's servers and is available through existing web-services (Xml-Rpc services in our case).
3.
In our sample application, we have built this entire service in the Python language.
4.
When a user changes his location, the location framework notifies these external services of the user's changed location through the 'location_handler' remote procedure call.
5.
The remote services then invoke their services and return the results to the Application
Server.
6.
The Application Server then returns the data back to the user.
Case 3: Weather Assistant
1.
The publish information here refers to the real time weather information available from the
Yahoo weather API.
2.
The user merely has to register with the framework for the 'weather assistant' service.
3.
When the user changes the pin-code corresponding to the area he/she is in, the weather service is invoked by the framework and the current weather in the user's location is returned.
4.
The user can be given the additional choice of registering for weather alerts (like temperature going above a certain degree, thunderstorm alerts, etc).
5.
Based on the user's preference, his presence information and the current weather conditions, the user is notified with the appropriate information.

Case 4: Traffic Assistant
1.
The publish information here refers to the real time traffic information available from the
Yahoo traffic API.
2.
The user merely has to register with the framework for the 'traffic assistant' service.
3.
When the user changes his location, the traffic updates are got from the Yahoo service and are returned to the user.
4.
The user can also set his preference on certain aspects of the traffic services like interests in traffic alerts within a K-mile radius around a latitude-longitude co-ordinate.
5.
Based on the user's preferences, his location information and the traffic alerts, the user is notified with the appropriate information.
Case 5: Travel Assistant
1.
The user interested in using the travel assistant registers for this service for the city he wishes to travel.
2.
Whenever the user visits that city, his preferences from shopping, weather, traffic, dining, camping, sight seeing are integrated.
3.
Based on his preferences and the information pertaining to the current location, the user would be notified of relevant places of interest be it for shopping or sight-seeing.
4.
The user can sign out of travel assistance once he leaves the city and returns home.
The user can also select for a combination of the services. In this case, each of the individual services are invoked by the framework and the appropriate results are returned to the user.

The current document describes some of the Call-Flows corresponding to the framework.
1. Publish Presence Information
In our framework, the mobile agent will update the client’s current status to the server. When a client sends a PUBLISH method, he/she will intern be notifying the server of the client’s presence status. Based on this status received, the server will then retain this information and then decide whether or not to send the information to the client. During the entire message exchange phase, the ISC interface forwards the requests to the SIP AS after evaluating the triggers associated with that subscriber.

2.
Registering with the Framework
This corresponds to the initial registration phase where the client registers with the framework. The client will first have to send a register method to the server. The server would then return an “Unauthorized” response back to the client following which the client would have to authenticate itself. Once a successful authentication has been done and the client has authenticated itself, the server returns a 200 OK response back to the client. This notifies the client that the registration process was successful.

3.
Toggling the Client’s Status
In this scenario, we present the message flow diagrams when the client changes his presence information. Based on the presence information set, the server can then forward the service information to the client. In the following figure, the client initially publishes his status information to the server. Following this, the server returns a 200 OK response to notify the client that the change in presence information is successful. The server then checks with the services built on the framework invoking them and sending the results back to the client through the MESSAGE protocol. The client will then notify the server of the receipt by sending a 200 OK response to the server. During the entire message exchange phase, the ISC interface forwards the requests to the SIP AS after evaluating the triggers associated with that subscriber.

4.
Get Service/Event(Weather) Call-flow
The following diagram shows the call-flow when the client sends the change in location of the client. During the entire message exchange phase, the ISC interface forwards the requests to the SIP AS after evaluating the triggers associated with that subscriber. Based on the new location of the client got by the server, the server will then invoke the weather service with the client’s new location and profile information and return the results to the client. The MESSAGE associated with the diagram will contain the location information of the client got from the “WhereAmI” service. The server will then return the 200 OK response to the client notifying that the change in location was successful. The server then notifies the client of the weather information pertaining to the client’s profile based on his/her location. When a client receives the “MESSAGE”, it notifies the server with a 200
OK response notifying the server of the receipt of the Message.

5.
Generic Location Based Service Retriever
The generic service retriever tells us the exchange of messages between the client and the server when there are a number of services hosted on the framework. The utilization of the services is shown in detail in the following diagram. The client uses a HTTP Request to ask for its location information from the “WhereAmI” service. When the location of the client has been returned, the client then forwards a “MESSAGE” with its location. On receipt of the message, the server informs the client with a 200 OK Response. When the new location has been received by the server, the server invokes the services associated with the client’s profile, location and services registered with the framework. This is done returned back to the client in a similar manner as shown in the above figure.

The following diagram gives a general overview of the IMS architecture system used in our prototype.
Illustration 1: IMS Architecture components used in the prototype
We have incorporated the following applications over our location based framework.
Weather
Traffic
Shopping
Location (core)
Presence (core)
The robustness of the framework has been shown through the implementation of the weather, traffic and the sample shopping application. The framework maintains the user profile, the published information of discounts. Then the framework takes the responsibility of matching user profiles with the published information. The framework also has a feature to utilize existing web services in order to supply information to the client. The following sections provide the details.
 Weather service
The weather service has been built using the Yahoo weather service. Yahoo provides a REST based service to access the weather information based on the pin-code of the area. As such, we wrote another XMLRPC based service to get the pin-code corresponding to a lat-long co-ordinate. The weather information is got from Yahoo and is accumulated along with the




 results of other services which the user has registered with at the application server.
Traffic service
The traffic service has also been built using the Yahoo traffic service. Yahoo provides a
REST based service to get the traffic information based on the pin-code of an area. By invoking the REST service, we get the traffic information based on the user’s current location which is then returned back to the client on his phone.
Both the traffic and weather service are REST based services provided by Yahoo. In order to utilize the service and to show the flexibility of the framework, we wrap the traffic and weather services with XMLRPC based service components (which are written in Python).
These python based XMLRPC services are invoked from the application server.
Shopping
The Shopping service has been implemented in two different techniques. One such service has again been implemented using the XMLRPC based architecture (In the user case document, we have described this service as the one provided by Walmart). This is typically useful when a company wants to host its own service. In the other version of the shopping assistant (the Target service), the framework performs the business logic. In this service, we required for Target to supply the appropriate offers corresponding to a Target store location.
This information is stored by the framework in a MySQL database. Following this, any change in the user location involves the framework sending the appropriate information to the client pertaining to the client’s current location.
Location
The Location service has been utilized extensively and is one of the core services used by the framework. The location service forms one of the core components of the IMS architecture. This location service is got by the ‘WhereamI’ service hosted by GT-RNOC.
This service returns the current location of any user connected to the Georgia Tech network.
The service returns the corresponding lat-long co-ordinates of the user within the Georgia
Tech campus. Since this application is a prototype, it is our understanding that the
‘WhereamI’ service covers a reasonable area for a prototype.
Presence Service
The Presence service used by our framework typically maintains the presence information corresponding to the client. We have provided two status messages currently which the client can use. One of them corresponds to the ‘Buzz me !!’ message which refers to the situation wherein the client can receive the alert messages sent by the framework. The
“Don’t Buzz me !!” status message refers to the situation wherein the client does not want to be disturbed by the framework. The database hence also maintains the current status of the client’s preference.

IMS Technologies and Servers used
Handset /Access point: The application was developed for mobile phones using J2ME. We developed the MIDP application using the Netbeans 6.0 IDE which comes preloaded with the mobility feature.
Location Server: We use the GeorgiaTech location service and include it in our IMS system and application.
The GeorgiaTech location service offers an HTTP interface to query a device’s location (GPS coordinates) based on its IP address (only first party). The mobile phone application publishes this information and the
SIP A/S application this in its database.
Apache Web Server: This J2EE server hosts the JSP/HTML web based system and user profile administration web application. In addition to that it can also be used to host user album pictures and media items. We use the WAMP architecture to host all the php scripts on the apache web server. Mysql is used as the backend database system.
CSCF: The CSCF is the central server of the IMS system and handles all SIP messages and triggers on the CSCF advise the server to forward certain messages to our application on the SIP A/S.
Presence/GLM Server: Just like location information, it is our understanding that the presence information is a key component to our framework. One of the key applications of the framework is for advertising purposes and as such, presence information is needed to ensure that the user is not annoyed by the number of alert messages. We do not intend to provide negative publicity to AT&T or to any of the Companies uses our framework hosted by AT&T.
SIP A/S and Database: The SIP A/S (Sailfin/Glassfish) application processes all forwarded SIP messages, parses SDP and XML payload data and sends responses or signalling information to the phones. In addition to that it handles sessions with the registered users.
We use the MySQL database at the SIP A/S and connect to it using the
MySQL JDBC connectors.
Technologies – Software required
The prototype was developed using several open source softwares including components of the LAMP stack.
1.
Apache tomcat server 2.2.8
2.
Mysql 5.0.5
3.
Php 5.0
These three components are packed into a single software - WAMP Server 2.0 which is free for download, so they can be installed separately or from WAMP.
4.
Python 2.5.1
5.
Java ME
6.
Netbeans 6.0
7.
EclipseME 3.3.2

The first four components are required for the framework. So the party (ATT) installing the framework must install these on the server in order to deploy the services. Components 5-7 are used to develop the client code. So these softwares are required only at the site where improvements to the server code is being made.
Note : Python is used to integrate certain external services like weather and traffic and hence it is needed in the server.

The application infact has a mass appeal. People are interested in applications that make their daily life simple, that saves them time, that provide value addition to their activities. We took a survey of one of the use cases – Shopping assistant. The survey raised the following question - “ If your mobile phone had the facility to use your location information(say when you are close to a Mall) and send messages relevant to your preferences(like shopping, weather), would you like to try the service. The service is provided for free by the carrier.” The following screenshot is from the survey website.
Illustration 2: Business Plan - Survey Results
The response to the survey was pretty good. We got nearly 55 people to answer to survey. The results of the survey was very positive. More than 59% of the users were interested in using such a service. Around 22% were unsure of it because of lack of details in the survey (Basically we wanted to keep the survey short). About 20% of them were not interested in using the service.
70
60
50
40
People's preference to use the service
30
20
10
0
Yes No Maybe

The demographic data of the survey showed that people of the age group (22-28) across states like
Georgia, California, New York, Illinois, Wisconsin, Texas, Arizona took part in the survey. We conclude that a majority of this age group who are interested in such services will use it and if they find it useful, they will share their experiences with their friends and get more people to use such a service. The age group that answered the survey comprised of undergrad/graduate students. Given some sort of incentive to these students to spread awareness about the service, we would definitely reach a bigger audience. These aspects are discussed in detail in the business model. The following screenshot is again from the survey website giving the demographic report of the people who answered the different questions.
Illustration 3: Business Plan - Demographic data
Business model
We propose the following business model for a period of 6-12 months.
1.
Lets take the shopping assistant application. We assume that the framework will be hosted by the connection provider (take ATT for example). Thus, ATT will be maintaining the central repository that stores both the users' profile information and the retailers' discount / promotion details. The infrastructure required to setup the framework is close to owning two desktop computers and hence is quite affordable. Apart from that ATT has to spend on the staff (2-3) that supports the continuous functioning of the framework. This cost is negligible compared to the benefits that ATT gets out of it. ATT can choose to outsource the maintenance of the framework while still owing all the profile information and retailers data.
Remaining are the two entities – users and retailers who have to be brought into the system.
2.
The first step is to get the retailers into the system. The retailers are always looking for cheaper and new means of advertising. They might not realize the potential of new forms of advertising like customized advertisements sent to mobile phones. They might be reluctant to try such modes of advertising if the cost involved is high. Thus it makes sense to provide

the facility to the retailers for free for the first few months. Consider the prototype being implemented in Atlanta. The major retailers in the city have to be contacted via email, post informing them about this mode of advertisement. They can be given a promotional period of 3-6 months ( This is because the number of users will be low in the first 1-2 months and the count will pick up as more users will start using the service. This is when the retailers will realize the true potential of this form of advertising. This period gives the retailer some time check if this mode of advertising actually works for him.) Conventional modes of advertising (like newspaper, radio, television) can also be used to get the retailers into the model. Thus the retailers can be got into the system. Once they are in the system, all they have to do is to update their discount information on a daily/weekly basis (whatever is convenient to them) on the website provided. So the involvement of the retailers is kind of bare minimum till now. Once the promotion period is over, the retailers will have to pay on a monthly subscription based on the number of promotional messages they store in the system/ a flat rate fee based on the size of the organization. Also, retailers who join the system after six months of inception of the concept in a city, will be getting a promotional period of 1-2 only.
3.
The next step would be to get users register their profile. This is a huge step towards the success of the venture. In order to get the users into the system, conventional modes of advertising like television, radio and newspaper can be used. Promotions of the service can be sent across with every bill ATT sends on a monthly basis. To attract more users, the first
100 users can be given incentive like waiver of previous month's bill for enabling this service and using it for atleast 2 weeks in active mode. The users can refer their friends and both of them can get a 5$ credit to their current bill (provided they use the service for a minimum of 3 months). It works this way. Using the website provided, the user enters friends' phone numbers. An unique activation code is assigned to each friends phone number and is sent to each one of them along with the invitation to register their profile with the framework. If the person decides to use the service and registers using this invitation code, both the referrer and referral can avail of the credit. This way more users will be attracted to use the service.
4.
According to the statistics obtained from the survey, we believe that majority of the youth are interested in the service and they would use it if it provided for free. So we believe that this service should be provided free of cost to the end user for the shopping assistant application. They can be charged for using other services like traffic and weather services.
Note: Revenue from the shopping assistant application is mainly by the retailers. The retailers will definitely be in the system suppose
5.
How does the discount work?
From the use case, it is evident that the users get the promotional/discount messages when they are in the vicinity of the store and their profile matches the products on sale. Along with the promotional message, the user receives a promotion code that is unique for that offer and user. The user has to produce the promotion code in order to avail the discount.
Thus ATT can keep count of the number of advertisements sent out for various profiles and products. At the retailer's side, on checking the promotional message, the retailer can give the discount to the customer. If the retailers want and have the infrastructure in place, they can keep these promotion codes in their own database to evaluate the actual number of users using the promotion messages. This is optional and left to the discretion of the retailer. If the infrastructure to store the promotion codes is available at the retailer's end. The retailer can share this information with ATT on a regular basis to get the exact statistics of the usage of the advertisements. This will help him decide to increase/decrease his spending on this form

of advertising. Since these statistics help the retailers analyze the usage, it is not possible to evaluate it without their involvement. Even if they do not store the promotion code, ATT can provide the retailers the number of messages that were sent corresponding to every product in the store.
Note: This mode of advertising can be used in two ways, one way is to create awareness of the discount in the prospective buyers who are interested in those products. Secondly, people with this promotional code can be given additional discounts apart from the regular discounts available in the store. This information does not affect ATT directly and hence is under the discretion of the retailer.

1.
This section serves as a step by step guide to use the Publish Subscribe System for the
Shopping Assistant Scenario. If you are a Store Manager and you want to publish promotions/offers using the framework, refer to the section 2. If you are a user willing to receive offer information about the products you are interested in, refer section 3.
2.
Publisher (Store Manager)
Scroll down the “select store” drop down list to select your Organization and click “Enter
Admin Site”. If you do not find your Organization name listed, register for the “Shopping
Assistant” Program.
Verify your Stores’s identification number. If the number displayed is correct, Enter the details of the product and discount that you like to advertise. Also enter the date until when the offer will be valid.

After entering the details, click on the “Submit” button.
You will see your offer displayed in the next page as shown below. If you want to add more offers, click n the “Add More Discounts” link at the bottom of the page. If you have no offers to advertise, click on the “Back to Portal” link.

3. Subscriber (User)
The Shopping Assistant is a free service provided to Users who want to receive information about various offers related to the products of User’s choice. If you have already registered to the service, you can skip this section and proceed to section to set up your profile to list the products that interest you.
Setting Profile
Select the Username from the “Select User” dropdown list and click “Enter User Site”
Verify the Id displayed in the UserId field. If it is correct, please fill the product about which you want to receive offer information and click on the “Submit” button. If you are interested in receiving offer information about all pruducts under a category or subcategory, Just fill those particular fields and leave all the fields below it blank. For Ex. If you want to receive offers about all Men’s Jackets, fill the sub-category as “Jacket“ and leave the “Brand” and “Product Name” blank.

The next page you see reflects your updated profile. If you want to add another product that you are interested in, click “Update Profile”.

User Guide – II
The following document presents a continuation of the previous User Guide document. While the previous document helped set up a profile with the Location framework, the current document focuses on using the services hosted on the SIP application server using our framework.
Our client application has aptly been named LBF Gateway (LBF stands for Location Based
Framework in the entire document henceforth).
The above figure presents an introduction screen when the client opens the application to connect to the SIP application server and utilize the services hosted by our framework on the server. The
“Menu” button at the bottom of the screen provides options to “register” with the framework. The figure below shows the options when the “Menu” button is clicked by the client.

When the user selects the register button, he is prompted with a screen where he can enter his preregistered username. Based on the username entered, the client then issues a SIP register message to the server. The server would receive this message and hence be notified of a new client request to connect to the framework to utilize the services.
Once the registration is successful, the display on the client would immediately change to get the service information appropriate to the services to which the client has registered. As mentioned in the other documents, we currently provide the user with the following services.
Shopping Assistant (generic application used by the framework, the application can be extended to provide similar services like Travel Assistant, etc).
Weather
Traffic
Presence (Core)
Location (Core)
A user can choose any combination of services based on his/her interest. The following figure shows all the services when the user has registered to all the services hosted on the LBF at the application server.

As mentioned previously, the above figure shows the service information based on the client’s current location. In order to allow the user to set his presence information, we provide a feature for the user to select his status by clicking the “Set Presence” button at the bottom of the screen. More information regarding setting the presence information will be presented in the following sections.
In a similar manner, we allow the users to choose the services he/she would like to register to.
Based on the profile information of the user, the framework will then be responsible to invoke only the appropriate services. The following figures show some of the combinations,

The above figure depicts the information got by the client when the user has only registered to the weather service. While the weather service we currently host has detailed information and forecasts, the above figure shows only the basic current weather conditions.

The above figure shows a combination of the weather service and the corresponding shopping offers. The shopping information/offers mentioned in the above display also take into account the client’s current location. (The “Target” store services by the framework on the application server while the “Walmart” store services are hosted at a remote location; more details regarding the service types and the capabilities of the server are mentioned in the other parts of the documentation).
Presence Information:
In order to take into account the presence information, we have provided two buttons at the bottom of the display which the user can use to set his preference. The “Buzz me !!” button allows the user to receive alerts based on his location. The “Don’t buzz me !!” button allows the user to switch the alert feature off. We have provided this feature in the event that the user stays close to the area where he/she might also have an interest in. By setting his status message, the user can ensure that alerts don’t come up. The following figure shows the screens where the user is allowed to set his status.

The current document presents part – II of the User Guide. This document is concerned with details for the clients to use the LFS Gateway application on their mobile devices.
Troubleshooting
In case of any queries, please contact the developers.