Implementation of Real Time Tracking using Unstructured Supplementary Service Data

Transcription

1 Implementation of Real Time Tracking using Unstructured Supplementary Service Data Aniket Dabas, and Chetna Dabas Abstract Real time tracking is required in many aspects of life like tracking vehicle fleet for optimized use of resources, tracing a stolen object and so on. Unstructured Supplementary Services Data (USSD) is a GSM service that allows high-speed interactive communication between the subscribers and applications across a GSM Network. The primary benefits of USSD are that it is cheaper then existing methods and allows for very fast communication between the user and an application giving the system real-time characteristics. This paper proposes a unique real-time tracking method with its architecture using USSD and GPS system on mobile station which even works in VPLMN and is faster than existing methods. The proposed method has been implemented using GPS, GSM and AJAX technologies. Keywords USSD, Real-time tracking, Implementation, Architecture. I. INTRODUCTION NSTRUCTURED Supplementary Service Data (USSD) U is a technology unique to GSM. It is a capability built into the GSM standard for support of transmitting information over the signaling channels of the GSM network. USSD provides session-based communication, enabling a variety of applications. USSD is widely preferred over other existing technologies due to its key attributes described next. Firstly, USSD is instead session oriented, unlike SMS, which is a store-and-forward, transaction-oriented technology. Secondly, turnaround response times for interactive applications are shorter for USSD than SMS because of the session-based feature of USSD, and because it is NOT a store and forward service. Thirdly, users do not need to access any particular phone menu to access services with USSD- they can enter the Unstructured Supplementary Services Data (USSD) command direct from the initial mobile phone screen. Fourthly, USSD commands are routed back to the home mobile network s Home Location Register (HLR), allowing for the virtual home environment concept the ability for services (based on USSD in this case) to work just as well and in exactly the same way when users are roaming. Fifthly, Unstructured Supplementary Services Data (USSD) works on all existing GSM mobile phones. And lastly, both SIM Application Toolkit and the Wireless Application Protocol support USSD. This paper aims to exploit these USSD features to propose a unique real-time tracking method, which even works in roaming and is faster then SMS and GPRS. The network resources and hardware requirement of USSD is very low. II. METHODS AND MATERIALS The proposed method is a unique real-time tracking method, which is faster than SMS and GPRS and even works in roaming environment. The network resources and hardware requirement of USSD is very low and hence helps in the encouraged use of the proposed method. The system specifications and proposed architecture of the proposed method have been described ahead. A. System Specifications Interface definitions There are various interfaces involved in order to achieve real time tracking in the architecture involved (some of which have been designed specially for the purpose). Three of the most relevant ones are described below: i. Application to application interface design For a proper communication to take place there has to be an agreement between the transmitting node and the end node involved (in this case mobile station and a website) in a welldefined format. In our case, total length of the USSD data = 20. The first 10 digits represent X axis and latter 10 represent Y axis. Each 10 is explained in Fig. 1. Fig. 1 Format of 10 bits of USSD data For example, if the X coordinate = and Y coordinate = the full USSD string formed will be *SAC* # It is illustrated in Figure 2. MS can send this string with the help of AT commands/modem commands (Below you can see an example of account interrogation through an AT command). 241

2 Fig. 2 Snapshot of USSD String generation When data part of the USSD string reaches application on web server, it is decoded in accordance to the format described. ii. USSD communication between network and Intelligent Network This string is routed to SCP/IN by HLR. The message flow between different entities in this case is provided below. Fig. 3 USSD sequence of events between network and IN The Intelligent Network sends the acknowledgement of data reception in end message if the data is saved, in all other cases not ok message is sent. In case a Not OK message is received or time-out occurs the application tries to resend data at some other time. The snapshot below shows the flow of messages for the example taken above. Fig. 4 Emulator result of IN-Network communication iii. IN-Web server interface In the proposed method, following interface is designed in order to make message exchange between IN and web server: XML request form IN <?xml version="1.0"?> <!DOCTYPE cp_request SYSTEM "cp_req_websvr.dtd"> <in_comm_out> //type of request <user></user> //From where or source identification <password></password> //Authentication <user_id></user_id> //user identification <transaction_id></transaction_id> //session information <data sno="" timestemp="">coordinates</data> //data part with serial number and time stemp <application></application> //for internal identification within IN <mode></mode> //mode of operation real time or one shot </in_comm_out> //end of request XML request form Web server <in_comm_in> <user></user> <password></password> <user_id></user_id> <transaction_id></transaction_id> <application></application> <mode></mode> </in_comm_in> The fields in the XML document have the following details associated with them: user & password: Used to identify and authenticate the source of the party sending the XML request i.e. both IN and Web server use this field use this field to authenticate to each other. For the 242

3 purpose it is necessary the both the Web server account and the SIM card account should be present on IN. user_id: This field identifies the end user (being tracked) whose information being communicated. transaction_id: This field is used to distinguish between different call contexts of a given user (as for single user may be running many different types of operations at once. For example a user may be recharging his account through website and making a voice call and the location information may be updating at the same time in this case transaction_id is used to distinguish between different call contexts on IN). Transaction id is calculated using an encryption algorithm that uses system time, user id, password, call context on IN and a public private key system. If the data is being sent in real-time authentication (user and password) and user_id are only required in first request. In rest of the transactions only transaction_id is required since this is a unique number generated by IN and is only valid until the time the call context is present on IN (this context is cleared at the end of each call). <data sno="" timestemp="">coordinates</data> This tag contains the actual data: serial number sno and timestamp (this field is a UNIX time stamp which is the number of seconds since 1970), which contains time at which the coordinates are also transmitted with coordinates. The number of such tags is variable and depends on the amount of data that has to be transmitted in one go. This greatly reduces the number of messages required during first communication between IN and web server where large amount of data is involved. application: Since there are many applications running on IN which utilize this XML request interface, this tag helps identify the type of request and the application that will process it on IN. mode: This tag indicates if the data is required in real-time or only when requested. Fig. 5 The Proposed System Architecture This architecture need software development on MS, IN and web server software. The application on the MS reads the GPS data and transmits this data in form of a USSD string. This data is routed to IN through HLR. On IN the transmitted data is saved and confirmation of successful operation is sent back to the mobile application. Instead of being saved this data can also be sent to web server as XML but this will increases load on IN-web server interface, hence this is done only when the end user is online and data is required in real time to be displayed to him. The data sent by MS is in no way manipulated by IN, so a defined standard needs to be in place for this data. When end user requests web server for the required data through a web browser, a XML request is sent by the server to IN, in reply server gets all the data since its last request and a flag is sent on IN which tells it that user is now on line and that data is required in real time now (from now onwards IN does not save any data in data base but it sends it directly to the web server). For each XML post by IN containing data the web server sends an acknowledgement back to it. B. The Proposed Architecture In the proposed architecture the service of real time tracking is provided be a website which also provides software for the MS. This website is responsible for presenting the real time location related data to the end user in presentable format. Several websites like these can be client of a given IN that performs all the data collection and charging related operations. SIM cards in all the tracked entities hold an account on IN like any other cell phone user. 243

4 After location related data is communicated to web server it combines this information with maps from a maps server (or it may have maps available locally) and provides visual display to user. A live feed of information is sent to web browser where AJAX provides an interactive way to handle and display this data. Fig. 6 Successful case Call Flow If the acknowledgement is not received by IN within a specified period of time, a timeout occurs on IN and the XML post is sent again. If after 3 consecutive failures no reply is received, the connection is assumed to be broken and the flag that indicates online presence of end user is unset. Fig. 8 Implementation To control the application on the mobile station the service provider site sends commands to it. IN sends these commands are as SMS to the mobile station, where application reads and executes it. In above architecture interface for authentication and connection establishment is similar to bank refill. Since Data relating to each website is kept on SDP, real-time charging can be gone either on customer account or on website account (in case if the website is providing end to end service to the end user). INDRs will be generated for statistical and record purpose. III. RESULTS The paper proposes a unique architecture and its implementation using USSD, which ensures real-time behavior for location update while being cheaper and faster than the existing methods. Fig. 7 Time out Call Flow Other condition in which flag is unset when web server asks IN to change the mode of operation to offline. Every day in low traffic hours all the data collected during the day is transferred to web server via FTP to clear IN database and to keep data on web server up to date at least to a certain level. IV. DISCUSSION With the existing methods being used in the telecom industry, in order to display the location of the tracked entity, the GPRS service is used to communicate the location related data to the web server. Here HTTP interface is used to update the location of the tracked entity using GET or POST methods. In this case, if the roaming facility of the user is not activated then, he will not be able to access the GPRS service and hence the location related information of the tracked entity will not be updated on the web server. As a result, the entity would no longer remains traceable while in roaming. Another very important factor is cost. While on roaming and many times even within a country rates for GPRS service is higher out side local area. Also a lot of network resources are required for GPRS as compared to USSD (since USSD communication takes place on control channel). The proposed system takes care of the fact that even if the 244

5 roaming facility of the user is not activated, the location of the tracked entity can still be updated and hence displayed. This becomes possible because the proposed system makes use of USSD service and USSD requests are always routed back to the home HLR. As a consequence, the location related information still reaches IN and hence the web server to be displayed to the end user. Also in many countries use of control channel is free, cost of this system is dramatically cut. This is especially true if MAP gateway is used (if some organization wants to use it instead of IN in case of high usage). REFERENCES [1] Ard Oerlemans, Joachim T. Rijsdam, Michael S.Lew, Real Time object tracking with relevance feedback,civr 07 Proceeding of the 6th ACM International conference on Image and Video retrieval, July [2] N. T. Siebel, and S. Maybank, "Real-time tracking of pedestrians and vehicles", Performance Evaluation of Tracking and Surveillance PETS 2001 (with CVPR 2001), Kauai, Hawaii, Dec 9th, CD-ROM proceedings. [3] Ismail Haritaoglu, Davis Harwood, Larry S. David, Real-Time Surveillance of People and Their Activities, IEEE Transactions on Pattern Analysis and Machine Intelligence, v.22 n.8, p , August