SUPL Support for Mobile Devices

2 downloads 955 Views 2MB Size Report
... A-GPS Simulator to handheld devices with different Operating Systems (OS) and also to a laptop PC where ..... SUPLPoslMess_DecodedAtClient- Notepad=.
SUPL Support for Mobile Devices Jayanthi Narisetty, Arpine Soghoyan, Mohanapriya Sundaramurthy, David Akopian The University of Texas at San Antonio, One UTSA Circle, San Antonio, TX 78249 ABSTRACT Conventional Global Positioning System (GPS) receivers operate well in open-sky environments. But their performance degrades in urban canyons, indoors and underground due to multipath, foliage, dissipation, etc. To overcome such situations, several enhancements have been suggested such as Assisted GPS (A-GPS). Using this approach, orbital parameters including ephemeris and almanac along with reference time and coarse location information are provided to GPS receivers to assist in acquisition of weak signals. To test A-GPS enabled receivers high-end simulators are used, which are not affordable by many academic institutions. This paper presents an economical A-GPS supplement for inexpensive simulators which operates on application layer. Particularly proposed solution is integrated with National Instruments’ (NI) GPS Simulation Toolkit and implemented using NI’s Labview environment. This A-GPS support works for J2ME and Android platforms. The communication between the simulator and the receiver is in accordance with the Secure User Plane Location (SUPL) protocol encapsulated with Radio Resource Location Protocol (RRLP) applies to Global System for Mobile Communications (GSM) and Universal Mobile Telecommunications System (UMTS) cellular networks. 1.

INTRODUCTION

The widespread use of Global Positioning Systems (GPS) and other existing and emerging Global Navigation Satellite Systems (GNSS) has significantly influenced Location Based Services (LBS) in cellular networks. The Enhanced-911 (E-911) regulation mandated by the US Federal Communications Commission (FCC) [1] proliferate the need for accurate LBS. According to E-911, the wireless network operators should provide accurate location information (accuracy of 50 to 150 m) of the mobile caller to the emergency service responders. Conventional GPS receivers incorporated in mobile devices provide excellent LBS (accuracy of 5 to 10m) in open sky environments when the receiver is in direct line of sight with the satellites. But, the GPS receiver’s performance deteriorates in so-called weak signal conditions such as urban canyons, indoors and underground due to tall buildings and foliage. Weak signals are both attenuated by structures and subjected to multipath degradation resulting in essential errors or signal loss. One of the enhancements to overcome above mentioned problem is the Assisted GPS concept where an external reference server having direct-line of sight access to satellites provides assistance to the mobile device exploiting terrestrial links. Assistance includes data such as satellite orbital parameters, reference time and coarse location if available. A-GPS typically reduces Time to First Fix (TTFF) and improves sensitivity, i.e. allows for the acquisition of weaker GPS signals. It also helps to save battery power. The invention of A-GPS technology widely improved LBS in the cellular industry. Consequently, testing of A-GPS methods has become critical prior to their realtime usage in any cellular network. A number of simulators (e.g. Spirent, Aeroflex, Agilent Technologies and ETS Lindgren) for the purpose of testing these receivers are available in the market which are very expensive and are not affordable for many academic institutions and small businesses. This paper extends ideas in [2] which reported the development of an affordable Assisted GPS (A-GPS) Simulator using Secure User Plane Location (SUPL) [3] architecture. SUPL is a user plane standard that relies on Internet Protocol (IP) [4] based data delivery channels to transmit assistance data making use of the existing control plane protocols for LBS positioning. Thus implementation of SUPL architecture remains infrastructure independent unlike the control plane protocols which widely depend on network infrastructure. This paper demonstrates the transmission of aiding data generated by A-GPS Simulator to handheld devices with different Operating Systems (OS) and also to a laptop PC where a GNSS receiver [5] is located. The hybrid GNSS receiver uses this A-GPS support for much faster position calculation.

Multimedia on Mobile Devices 2012; and Multimedia Content Access: Algorithms and Systems VI, edited by Reiner Creutzburg, David Akopian, Cees G. M. Snoek, Nicu Sebe, Lyndon S. Kennedy, Proc. of SPIE-IS&T Electronic Imaging, Vol. 8304, 830409 · © 2012 SPIE-IS&T · CCC code: 0277-786X/12/$18 · doi: 10.1117/12.910162 SPIE-IS&T Vol. 8304 830409-1 Downloaded From: http://proceedings.spiedigitallibrary.org/ on 04/19/2015 Terms of Use: http://spiedl.org/terms

2.

SECURE USER PLANE LOCATION (SUPL) ARCHITECTURE

SUPL is a Location Based IP technology for wireless communication defined by the OMA [3]. SUPL has become extensively popular in recent years because of its capability to use existing protocols and an opportunity to third party providers to support A-GPS. The two basic components of SUPL architecture are SUPL Enabled Terminal (SET) and SUPL Location Platform (SLP) The SET is a mobile device, such as a mobile phone or a Personal Digital Assistant (PDA), configured to support SUPL transactions. Examples of this could be a User Equipment (UE) in UMTS, a Mobile Station (MS) in GSM or IS-95, or a PC over an IP based transport. The SUPL Location Platform (SLP) is a server that handles user authentication, location requests, location-based application downloads, charging and roaming. SLP is composed of SUPL Location Center (SLC) and a SUPL Positioning Center (SPC). The SLC coordinates the operations of SUPL in the network and interacts with the SET over the User Plane bearer. It is also used for the translation of a location identifier (Cell-ID) to a geographic location expressed in latitude and longitude data. The SPC can be described as one which is responsible for all the messages and procedures required for position calculation and for the delivery of assistance data. The SET communicates with the network over the Location User Plane (LUP) interface. There are two communication modes between the SLP and the SET. • •

Proxy mode: The SPC will not have direct communication with the SET. Instead SLC will act as a proxy between the SPC and the SET to co-ordinate the operations of SUPL in the network. Non-Proxy mode: The SET has direct communication with the SPC which provides the assistance data to the SET.

SUPL protocol minimizes the infrastructure support for LBS. The SUPL standards are compatible with C-Plane protocols. SUPL also supports Mobile Location Protocol (MLP) [6] and ULP (User Plane Location Protocol) [7]. MLP is used for Location Based information exchange between elements such an SLP and a Gateway Mobile Location Center (GMLC) [8], or between two SLPs. ULP on the other hand is a TCP/IP protocol where the exchange of LBS data occurs between the SLP and the SET. This requires the data to be in Abstract Syntax Notation (ASN.1) [9] format for transmission. As this paper aims at transmitting assistance data from SLP to SET, we implemented the ULP protocol specification and formatting for the exchange of messages. 3.

LABVIEW-BASED ASSISTED GPS SIMULATOR

TM

The NI GPS Simulation Toolkit [10] receives almanac file in SEM format [11] and the ephemeris file in RINEX 2.0 format [12] and outputs the GPS navigation data based on user defined location and time for the available satellites. The navigation data is written to a text file as navigation bits. The A-GPS Simulator encapsulates these navigation bits into assistance data according to SUPL standard in ASN.1 format. This assistance data is communicated to the SET by a SUPL Server (e.g. SLP) over the TCP/IP network. Figure 1 shows the block diagram of the assistance data flow from the time of generation to the time delivered to the SET. The assistance data consists of the mandatory parameters such as the coarse time, coarse location, ephemeris, and almanac data. This basic assistance data is required for the SET to conform to its minimum A-GPS test requirements. The generated positioning data is according to RRLP and is delivered through the RRLP Payload wrapped in the SUPLPOS message [2], [13]. Five messages are exchanged between the SET and the SLP in the SUPL architecture as shown in Figure 2. Whenever an application running on the SET requests for position, the SUPL agent on the SET sets up a secure IP connection with the SLP and initially sends the start message to the SLP (SUPLSTART).

SPIE-IS&T Vol. 8304 830409-2 Downloaded From: http://proceedings.spiedigitallibrary.org/ on 04/19/2015 Terms of Use: http://spiedl.org/terms

Navigation Binary Data

NI GPS Simulation Toolkit

Windows Laptop PC

Simulator

'CSN

SUPL Server (SLP)

Symbian Mobile F._ OS

ASN.1 Files (Selected Satellites)

A -GPS

SET

TCP/IP

Android Mobile OS

Figure 1: Block diagram of assistance data generation and flow.

The fields in this message are user position technology, preference method and position protocol. The SLP replies to the SET with the SUPLRESPONSE message with session-ID and the positioning method as its fields. The SET then initializes the position session by requesting for the assistance data sending SUPLPOSINIT message to the SLP consisting of supported positioning methods and associated positioning protocol. The assistance data (SUPLPOS message) is delivered to the SET by the SLP wrapped in the form of a RRLP payload. As long as the SET receives the orbital assistance message (SUPLPOS), it proceeds with the calculation of the coarse position based on the estimated assistance data from the SLP. Once the position calculation is complete, the SET informs the SLP to end the IP connection by sending SUPLEND message for releasing resources related to the location session. For more information on the fields in the messages the reader is directed to read the reference documents [2],[7],[13].

SET

SLP Data Connection Setup (IP Network) SUPL START MESSAGE

(SET Capabilities, Cell ID, Session ID)

2

SUPL RESPONSE MESSAGE (Session ID, POS Method)

SUPL POSINIT MESSAGE (SET Capabilities, Session ID, Requested Assistance data, Location ID

4

3

SUPL POS MESSAGE (Coarse Position, Coarse Time, Ephemeris, Almanac Parameters)

SUPL END MESSAGE (session ID)

5

Figure 2: SUPL message flow (SET initiated)

Figure 3 illustrates the complete experimental setup to test mobile devices for A-GPS Simulator support. The developed Labview-Based A-GPS Simulator produces eight SUPLPOS textual files in ASN.1format that include updated orbital parameters (coarse location, time, ephemeris and the almanac data) of the corresponding satellites selected by the NI GPS Simulator based on the user location.

SPIE-IS&T Vol. 8304 830409-3 Downloaded From: http://proceedings.spiedigitallibrary.org/ on 04/19/2015 Terms of Use: http://spiedl.org/terms

These ASN.1 files (assistance data) are sent to the SET through the SUPLPOS message wrapped in accordance to RRLP Protocol. The SUPL messages at both the SET and SLP Server are converted to Java classes using OSS NOKALVATMASN.1 TO JAVA COMPILER [14] and included in the client application and server application resource bundle respectively to be converted into binary representation (encoded) prior to communication over the TCP/IP network. The messages can be encoded using one of the encoding rules specified in ASN.1 standard such as Basic Encoding Rules (BER), Canonical Encoding Rules (CER), Distinguished Encoding Rules (DER), Packed Encoding Rules (PER) (Aligned, Unaligned), or XML Encoding Rules (XER). Our implementation uses Unaligned PER [15] for minimal encoding size using OSS NOKALVATM runtime libraries. The user application encodes the messages and writes GPS Satellites

NI PXI RF Vector

ßiLnal Generator

NI LabVIEW A -GPS

Assistance data

simulator

SERVER

Client to Server

Weak GPS signals

1. 3.

2.4.5.

CLIENT

1----

Server to Client I

t_t_ _7

PER

Encoder

Java ME application

Java application

(Sun Java Wireless

(JDK 1.6 Platform)

: SUPL messages: PER

Encoder &Decoder

Toolkit 2.5 Platform)

&Decoder API for Java ME

API for Java PER Encoding

getinputStream() read()

OSS Nokalva OSS

41

ASN.1 /JAVA

Compiler generated Java classes

PER Decoding

PER Encoding

getlnputStream() read()

2.SUPLRESPONSE

3.SUPLPOSINIT

PER Decoding

getOutputStream( write()

11.SUPLSTART

getOutputStream() write()

OSS Nokalva O5S

ASN.1/JAVA

4.SUPLPOS : 5.SUPLEND

Compiler generated Java classes

L Figure 3: A block diagram of experimental setup for testing A-GPS support

the data on the output stream while decoding the incoming data by reading on the input stream as shown in Figure 4. In our implementation the GPS Simulator is co-located with the A-GPS SUPL server (e.g. SLP).

ASN. i Source Files

OSS Runtime Libraries

OSS ASN.lJavA Compiler

Compiler Generated Java Classes

PER Encoder /Decoder Classes /Methods

User Application

F.nmded /Dec ded Stream Output

Figure 4: Function of OSS ASN.1/JAVA COMPILER

SPIE-IS&T Vol. 8304 830409-4 Downloaded From: http://proceedings.spiedigitallibrary.org/ on 04/19/2015 Terms of Use: http://spiedl.org/terms

4.

WI-FI ASSISTANCE TO SUPL BASED A-GPS SIMULATOR

Another technology which improves accuracy of LBS is the use of Wi-Fi Positioning System (WPS). In [16] Wi-Fi assistance was provided to the SUPL-Based A-GPS Simulator to generate more accurate location information. According to the description, in the SUPL message flow, initially the SET requests for assistance data by providing its ID to the SLP. The SET’s ID can either be its cell-ID, IP address or MAC address. On receiving the SET’s ID, the SLP contacts the GMLC to fetch the SET’s location based on the SET’s ID. If the SET’s ID is a cell-ID, then GMLC looks for the Base Station (BS) to provide the SET’s latitude and longitude. In the implementation described in [2], since the simulator does not have access to the GMLC, the cell-ID can be specified by the user or obtained by using freely available applications on the SET. In the implementation described in [16], if the SET’s ID is an IP address, then GMLC looks up an IP address SQL database to retrieve the latitude and longitude and returns this to the SLP which in turn will return the coarse location to the SET. For the IP address, database provided by Ip2LocationTM [17] is used. In the case of the SET’s ID being the MAC address, the coarse location calculation is performed on the SET itself. The SET uses Skyhook WirelessTM [18] Wi-Fi positioning technology to obtain its location in terms of latitude and longitude based on its MAC address. When the SET requests for assistance data, it sends the obtained coarse location to the SLP instead of its ID. The SLP replies to this request by sending the assistance data generated by the A-GPS Simulator along with the SET’s coarse location information. This information helps the SET to calculate its exact position. The location information based on MAC address is more accurate than the location based on IP address. The block diagram of Wi-Fi Assistance to the A-GPS Simulator is shown in Figure 5.

END messages

I

S. Assistant

data as A:N files

qe.y for location based on IP address

NI LaIbVIEW

GPS Simulator IP add

Figure 5: Block diagram of Wi-Fi assistance to the A-GPS simulator [15]

5.

SOFTWARE IMPLEMENTATION OF A CLIENT/SERVER COMMUNICATION IN JAVA ENVIRONMENT

The information exchange between SLP and SET in SUPL Architecture is realized through client-server communication model in Java environment. The TCP provides a connection-based, reliable, ordered delivery of stream of bytes from a client application running on one computer to a server application on another computer over the internet. A Socket class available through java.net package is the Java representation of a TCP connection. When a Socket object is instantiated, a connection is opened to the specified destination. 5.1 Server Implementation The server application implements the significant feature of the SLP which is to transmit location information to the SET

SPIE-IS&T Vol. 8304 830409-5 Downloaded From: http://proceedings.spiedigitallibrary.org/ on 04/19/2015 Terms of Use: http://spiedl.org/terms

upon request. The assistance data generated by the dedicated Labview A-GPS Simulator is periodically updated and stored on the server PC. In Java environment, the java.net.ServerSocket class is used to listen for client requests on the specific port (port 9999 in our case). 1. try { 2. serverSocket = new ServerSocket(9999); 3. } catch (IOException e) { 4. System.out.println("Failed to listen”); } The server invokes the accept() method of the ServerSocket class, which waits until a client connects to the server on the mentioned port. When a connection is requested and successfully established, the accept() method returns a reference to the new socket on the server through which communication with the client is possible. 1. Socket socket = null; 2. try { 3. socket = serverSocket.accept(); 4. } catch (IOException e) { 5. System.out.println("Accept failed: 9999"); } After establishing the client-server connection, they can now communicate by writing to and reading from the socket using I/O streams. The client's OutputStream is connected to the server's InputStream, and the client's InputStream is connected to the server's OutputStream. 1. os = socket.openOutputStream(); os.write(); 2. is = socket.openInputStream(); is.read(); Since the SUPL architecture in our implementation is SET initiated, the SET initiates the information exchange by streaming the PER encoded SUPLSTART message using write() method on the instance of DataOutputStream class and sends over the TCP socket connection. The Server application reads the client’s message using the read() method on the instance of DataInputStream class. The received SUPLSTART message is given to Unaligned PER decoder which converts data from stream to a string. The decoded message is stored as a file on the server. This procedure is carried out for each file that the server receives from the client. 1. suplstart.ulp.ULP_PDU decodedmsg=null; 2. try{ Coder coder = Suplstart.getPERUnalignedCoder(); 3. ByteArrayInputStream source = new ByteArrayInputStream(SUPLSTART); 4. decodedmsg= (suplstart.ulp.ULP_PDU)coder.decode(source,new suplstart.ulp.ULP_PDU()); 5. } catch (Exception e) { 6. System.out.println("Decode Failed: " + e);} When the server replies to the message exchange initiation with the SUPLRESPONSE message, a similar process takes place at the client side. The Unaligned PER encoding/decoding at both client and server side is made possible by including OSS NOKALVATM API and by importing the following packages into application resource bundle. 1. import com.oss.asn1.*; 2. import com.oss.metadata.*; 3. import com.oss.util.*; 4. import com.oss.validator; In the final step of SUPL message exchange session, the server sends eight SUPLPOS messages corresponding to assistance data of eight satellites generated by the NI Labview A-GPS Simulator. The assistance data of eight satellites are received and stored as files on the client side, which help the client to calculate its position. The server then ends the session by closing all connections after being prompted by the client’s SUPLEND message.

SPIE-IS&T Vol. 8304 830409-6 Downloaded From: http://proceedings.spiedigitallibrary.org/ on 04/19/2015 Terms of Use: http://spiedl.org/terms

1. os.close(); 2. is.close(); 3. serverSocket.close(); 4. socket.close(); 5.2 Client Implementation The SET can be a MS in GSM technology or a UE in UMTS or a PC over an IP-based technology. To provide wide test environment, three client applications have been developed as shown in Figure 6. The first client application is developed using Java Platform, Standard Edition (J2SE) [19] and tested on a Windows Laptop PC. This application has been developed to provide A-GPS support to the GPS/GNSS receiver. The second client application is developed using Java Platform, Micro Edition (Java ME) [20] with Sun Java Wireless Toolkit [21]. The application is deployed on a mobile device with Symbian OS (Nokia E72). The third client application is developed as an Android project and deployed on a smart mobile device with Android OS (HTC model). For mobile client applications, the OSS NOKALVATMASN.1 TO JAVA COMPILER is used to compile the ASN.1 modules to Java classes with the microedition option and included in the application resource bundle while for standard J2SE application the same compiler is used without the microedition option. Also the Java ME applications are built with ossmicro.jar (OSS NOKALVATMAPI for Java ME) while pure Java application is built with oss.jar (OSS NOKALVATMAPI for standard J2SE).

SLP

--

(Server Application)

TCP/IP SET

(Client Application)

Windows Platform Laptop PC

Symbian Platform Nokia E -72

Android Platform HTC Thunderbolt

Figure 6: Client application developed on three different platforms.

5.2.1 Development and Deployment of Java ME client application on a Symbian Platform In Java ME application, the Connector class is the core of Generic Connection framework. Different types of communication can be created by the same static method open() defined in Connector class with different parameters. The connection could be file I/O, serial port communication, datagram connection, stream connection or an http connection depending on the string parameter passed to the method. Such design makes Java ME implementation very flexible in supporting new devices and products. The stream connection is used in our implementation as shown by the following fragment of code to connect the mobile client to the server. 1.StreamConnection socket = null; 2. try { String server="10.3.12.77"; 3. String port = "801"; 4. String name="socket://"+server +":"+port; 5. socket =(StreamConnection)Connector.open (name, Connector.READ_WRITE); 6. } catch (Exception ex) { 7. System.out.println(“Connection failed”+ex); }

SPIE-IS&T Vol. 8304 830409-7 Downloaded From: http://proceedings.spiedigitallibrary.org/ on 04/19/2015 Terms of Use: http://spiedl.org/terms

As the SUPL Architecture in our implementation is SET initiated, the client initially PER encodes SUPLSTART message using the encode() method provided by the Coder class of OSS API as shown in the following fragment of code. This encoded message is written to the OutputStream through write() method and sent over the TCP socket connection to the server. The other message exchange procedure between client/server and encoding/decoding of messages remains similar to that explained in the server implementation. 1.byte[] encoding = null; 2.try {suplstart.ulp.ULP_PDU SUPLSTART =suplstart.ulp.ULP.myULP_PDU; 3.Coder coder = Suplstart.getPERUnalignedCoder(); 4.ByteArrayOutputStream sink = new ByteArrayOutputStream(); 5. coder.encode(SUPLSTART, sink); 6. encoding = sink.toByteArray(); 7.} catch (Exception e) { 8. System.out.println("Encode Failed: " + .e);} The developed Java ME application is deployed onto the Java enabled cell phone from the NetBeans Integrated Development Environment (IDE) [22]. When the user launches the mobile application from the phone memory, exchange of messages takes place and as a final message the mobile device receives eight SUPLPOS messages from the server. Figure 7(a) displays a fragment of received ephemeris data on a Symbian Mobile Device (NOKIA E-72).

NOKIA

ephem[ode0nL2 7:1 ephemURA_7: 0

ephemSVhealth 7: 0

ephemlODf 1: 169 ephemL2P11aq_7 0

ephemTçd_7 -16

ephemToç 7:65085

I

2,19 PM

(a)

(b)

Figure 7: (a) Fragment of ephemeris data received and displayed on Symbian Mobile Device (NOKIA E-72). (b) Fragment of ephemeris data received and displayed on HTC Thunder Bolt Mobile Device (Android 2.2.1).

5.2.2 Development and Deployment of Android client application on HTC Mobile Device Today, we are aware that stable devices like PCs and laptops are being replaced by smartphones and tablets. For successful multitasking capability of such devices, the operating system (OS) plays the most important role. The advent of Android OS certainly allowed the onset of better service and features to the end user. Android smartphones are becoming more and more popular in market. Keeping this in view, we developed an A-GPS client application to provide SUPL-Based A-GPS Simulator support to Android smartphones market. Android applications are written in the Java programming language. The Android SDK [23] tools compile the code into an Android package which is an archive file with an .apk extension. All the code in a single .apk file is considered to be one application. This file is installed as an application on the Android-powered device. In our implementation the

SPIE-IS&T Vol. 8304 830409-8 Downloaded From: http://proceedings.spiedigitallibrary.org/ on 04/19/2015 Terms of Use: http://spiedl.org/terms

Android A-GPS client application is developed in a similar pattern as explained in the previous section, compiled in Eclipse IDE [24] with ADT plug-in for Android [25]. Figure 7(b) shows the real time implementation of A-GPS Simulator support on HTC Thunderbolt Mobile which supports Android 2.2.1. 5.2.3 Labview-Based GPS/GNSS Receiver Testing with A-GPS Support A PC with Intel(R) Core™ i5 CPU M580, 2.67GHz (4CPUs), 3510MB RAM, Windows XP Professional OS is used as a GPS simulator and A-GPS assistance generation platform. NI Labview 2010 version is used as a development environment along with GPS Simulation Toolkit 2.0. Microsoft Visual Studio 2008 Team Suite is used for creating dynamic linked library (dll) to communicate C/C++ programming code with Labview development environment. In [26] an implementation of the GPS/GNSS receiver using MS Visual Studio C++ dll block was done proving that Labview is not adding any overhead on the performance of the same receiver operating on the MS Visual Studio C++ platform. In addition to that receiver, this paper demonstrates the A-GPS support transferred to the Windows laptop PC from the A-GPS support server. The test is conducted using the modified version of the application from the Labview example package called “RFSA Acquire Continuous IQ.vi”. The settings chosen for the RFSA signal acquisition are the following; the IQ sampling rate is 4.092MS/s, the reference power level is -80dBm, the GPS carrier signal frequency is 1.57542GHz, and the number of samples to read per each block of the received signal is 81840.

28.008s

28.00828.007gy,

rff 28.006-

J 28.00528.009 28.003 -, 86.99

86.992

86.994

86.996

86.946

87

Latitude

Figure 8. The actual location of the user with determined set of locations.

Actual Latitude = .Actual Longitude = 86

Without A-GPS support there was a need to collect 36 seconds of signal which is sufficient for decoding a navigation message for position calculation. But with A-GPS support we already have the almanac and ephemeris information decoded thus we can proceed to the position calculation almost immediately. In Figure 8 it is shown the actual location of the user and the detected location according to the A-GPS supported receiver position calculation. For A-GPS support, a client application is developed in Java environment on Windows Platform using J2SE. J2SE provides the java.net.Socket class through which the client PC can communicate with the server PC. While the server listens to the client on a specific port, the client instantiates a Socket object, specifying the server name and port number to connect to. The constructor of the Socket class attempts to connect the client to the specified server and port number. If communication is established, the client now has a Socket object capable of communicating with the server. 1. try { 2. socket = new Socket("10.3.12.77", 9999); 3. } catch (IOException e) { 4. System.out.println("Failed to connect server”); }

The message exchange procedure between client/server and encoding/decoding of messages remains similar to that explained in the previous section. Figure 9 shows a comparison of assistance data (ASN.1 File) transmitted by the server and the received decoded file at the client.

SPIE-IS&T Vol. 8304 830409-9 Downloaded From: http://proceedings.spiedigitallibrary.org/ on 04/19/2015 Terms of Use: http://spiedl.org/terms

- SUPLPoslMess`ransmiited File

Edit

Format

View

erverlotepad

Help

SUPLPoslMess_DecodedAtClientFile

Edit

altuncertainty 86))), navigatiorwodel { navvodelList isatelliteio 1, satstatus { ephemcodeonL2 1, ephemuRA 1. ephemsvhealth 0, ephemlOoc 201.

View

Format

Notepad=

Help

navigatiorntodel { navatodel L i st {

satellitelD 1, satstatus { ephemCOdeont_2 1, ephemuRA 1.

ephemsvhealth 0, ephemioDC 201, ?of l .0 t\

IephemTgd 7, ephemToc 65085, e hemTOw 131070,

enemwN

ep e ephemAF2 -1, ephemAF1 -22, ephemAFO -356033, ephemcrs -3888. ephemDeltaN -10957. ephenMO 277992043, ephemcuc 3366, ephemE -60416402, ephemcus 2436, ephemAPOwerMalf -1577892642. ephemToe 65085, eohemFitFlaa 1.

4Z9,

ephemAF2 -1, ephemAF1 -22, ephemAFO -356033, ephemCrs -3888, ephemDeltaN -10957, ephertm0 277992043, ephemCUC 3366, ephemE -60416402, ephemcus 2436, ephemAPOwerHalf -1577892642, ephemTOe 65085, ephemFitFlag 1,

Figure 9: Transmitted vs. Received SUPLPOS message files.

Time (s) 2.221 2.231 2.232 2.720

2.740

Time

SLP

SET SYN

999i

tr9397i

SYN, AC K

'

'g3

(.49397J'

ACK (..397j i

"1.9m

' PSH, ACK - Len: '9999}

0.715

i'99944

0.919

'PSH, AC K - Len: 4:

3.003

ACK - Len: 114

P,1-1, ACK - Len: 114

'13991

1.573

FIIPSH, ACK - Len: 798

i!99997

1.573

ACK

4.872

FIN, ACK

4.912

ACK

FIN, ACK ¡+A999)

ACK

ACK - Len: 8 ACK 'PSH, ACK - Len: 43

1.382

ACK

:49ì97) :

ACK --- ' PSH, ACK `== - Len:

1.332

3.189

(.4439:,,

i

>:. :

SYN, ACK

:?,.

FIN PSH, ACK - Len: 798

,

;

99991

3.189

6.353

0.691

iftn97

2.952

6.344

=

0.015 0.015

SLP SYN

0.000

!49397J'

SH, ACK - Len: 8

SET

(s)

99,íJ

.

Figure 10: Delay observations. TCP flow graph with network source/destination; (a) Ethernet connection; (b) Wi-Fi connection

The testbed displays communication delays in the network. SUPL messages are encapsulated as sockets in TCP/IP connections, and the socket delays are measured by the network analyzer developed by Wireshark [27], see Figure 10. The testbed also contains reference software GPS receiver for comparative evaluation and A-GPS enhancements. The baseband signal processing is implemented using block correlators for coarse (acquisition) and fine (tracking) synchronization. The block correlators for acquisition efficiently perform a parallel joint search in three dimensions: code phase, Doppler frequency, satellite number, using e.g. FFT. In [28] many frequency search steps are implemented through iterations in frequency domain, a long FFT is computed once, while shorter inverse FFTs are computed for each Doppler frequency and satellite. The tracking block-correlator concept [29] implements several correlators jointly in time domain. Early-Late-Prompt replica sequences are transformed to a set of addresses pointing to a set registers which accumulate partial correlations. The acquisition is performed first when correlators for each satellite provide 2D synchronization pattern with a peak highlighting Doppler frequency and code phase of the acquired signal as shown in Figure 11(a). The tracking algorithm described in [5] works for the sampling rate of 4.092 MHz. For the advanced tracking these samples are further integrated to reduce the sampling rate to 2.046MHz. To avoid real time generation of

SPIE-IS&T Vol. 8304 830409-10 Downloaded From: http://proceedings.spiedigitallibrary.org/ on 04/19/2015 Terms of Use: http://spiedl.org/terms

the carrier wave a fixed 12500 sinusoid array is created for 10000 generating various Doppler 7500modulation compensating 5000v 2590sinusoids through the saved 0sinusoid decimations and ¿ -2590cyclic array reading. The -5000-7590generated sinusoids are -10000 multiplied to the input signal -12500 0 200 400 600 800 L000 to wipe-off the carrier. The Tiere (rns) resulting samples are (a) (b) accumulated into 8 partial correlations (sub-sums). Figure 11. (a) Acquisition result of a single satellite using Labview visualization tools. Figure 11(b) illustrates the (b) Bits of the navigation message for a single satellite navigation message decoded in the tracking stage. The navigation data bits and measurements are passed to position computation module. In this implementation a conventional least squares positioning algorithm is used [30]. 6.

CONCLUSIONS

With the advent of cellular phones and the growing demand for Location Based Service especially the FCC’s Wireless E911 Mandate has boosted up the GPS technology. Nowadays GPS receivers are commonly integrated in phones, cameras and other consumer electronic devices. Assisted-GPS has been suggested as an approach to enhance GPS operation in weak signal environments. This work was motivated by the need to develop inexpensive, infrastructure independent A-GPS testing platform for mobile devices with different operational platforms. A testbed system for AGPS integrating GPS simulator, A-GPS assistance generation, and SUPL channeling has been implemented and validated for A-GPS technology developers. ACKNOWLEDGEMENT This work was partly supported by NSF grant 0942852. The authors would like to thank Chetan Dhumal amd Grant Huang for their help with network analyzer. REFERENCES [1] Wireless E911 location accuracy requirements: FCC mandate for Docket 94-102. http://www.fcc.gov/e911. (Access: Dec 1, 2011). [2] Chayapathy S.N., Kumar A., Kashyap P., Akopian D., Samant A.,“A SUPL-based A-GPS Simulator Support for Indoor Positioning,” Proc. of the 22nd Int. Technical Meeting of The Satellite Division of the Institute of Navigation (ION GNSS), 503-515, (2009). [3] Open Mobile Alliance. Secure User Plane Location Architecture, OMA-AD-SUPL-V1_0-20070615-A at www.openmobilealliance.org [4] Internet Protocol Suite, http://wiki.ask.com/Internet_protocol_suite [5] Soghoyan A., Huang G., Narisetty J., Akopian D., “A Labview-Based Assisted GPS Receiver Development, Simulation and Testing Platform,” ION GNSS Conference, 1982-1997, (2011). [6] Open Mobile Alliance, Mobile Location Protocol, OMA-TS-MLP-V3_3-20100831-C, 2010 at www.openmobilealliance.org [7] Open Mobile Alliance, User Plane Location Protocol, OMA-TS-ULP-V1_0-20070615-A, 2010 at www.openmobilealliance.org. [8] 3GPP TS 44.031 Third Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; Location Services (LCS); Mobile Station (MS) – Serving Mobile Location Centre (SMLC) Radio Resource LCS Protocol (RRLP), 2010. [9] T-REC-X.680 -2008 Abstract Syntax Notation One (ASN.1): Specification of Basic Notation at http://www.itu.int/ITU-T.

SPIE-IS&T Vol. 8304 830409-11 Downloaded From: http://proceedings.spiedigitallibrary.org/ on 04/19/2015 Terms of Use: http://spiedl.org/terms

[10] NI GPS Simulation Toolkit for Labview, http://sine.ni.com/nips/cds/view/p/lang/en/nid/204980 [11]Almanac information (the navigation center of excellence) http://navcen.uscg.gov/gps/alamanacs.htm [12] Ephemeris information (NASA Goddard Space Flight Center) http://cddis.gsfc.nasa.gov/gnss_datasum.html#brdc [13] Kashyap P., Samant A., Sagiraju P., Akopian D., "An A-GPS Support for GPS Simulators for Embedded Mobile Positioning," Proc. of SPIE Multimedia on Mobile Devices, (2009). [14] OSS Nokalva at www.oss.com [15] T-REC-X.691 -2008 ASN.1Encoding Rules: Specification of Packed Encoding Rules (PER) at http://www.itu.int/ITU-T [16] Sundaramurthy M. C., Chayapathy S. N., Kumar A., Akopian D., “Wi-Fi assistance to SUPL-based Assisted-GPS Simulators for indoor positioning,” IEEE CCNC, 918-922, (2011). [17] Ip2location at http://www.ip2location.com/ [18] Skyhook wireless at http://www.skyhookwireless.com/ [19] Java SE at a Glance, at www.oracle.com/technetwork/java/javase [20] Java ME Programming Guide- http://developer.att.com/developer [21] The J2ME Wireless Toolkit 2.1 - http://developers.sun.com/mobility/midp/articles/wtk21 [22] NetBeans Docs & Support at www.netbeans.org. [23]Download the Android SDK at http://developer.android.com/sdk/index.html [24] Java Development User Guide at http://www.eclipse.org/documentation/ [25] ADT Plug-in for Eclipse, at http://developer.android.com/sdk/eclipse-adt [26] Akopian D., Soghoyan A., Chayapathi S., Raju GVS, “A Flexible Labview-based GNSS Receiver Development and Testing Platform,” ION-ITM-2011 Conference, 1270-1280, (2011). [27] Wireshark network analyzer, http://www.wireshark.org [28] Akopian D., "Fast FFT based GPS satellite acquisition methods," Proceedings of IEE, Vol. 152, No. 4, 277-286, (2005). Initial version presented at ION-GPS-2001 Conference, Sep. 11-14, 2001, Salt Lake City, UT. [29] Sagiraju P. K., Kashyap P., Akopian D., “Block correlator for tracking GPS/GNSS Signals,” ION-GNSS Conference, 229-235, (2008). [30] Misra P., Enge P., [Global Positioning System, Signals, Measurements, and Performance], Ganga-Jamuna Press, Lincoln, MA, (2001).

SPIE-IS&T Vol. 8304 830409-12 Downloaded From: http://proceedings.spiedigitallibrary.org/ on 04/19/2015 Terms of Use: http://spiedl.org/terms