Thông tin tài liệu
receiving parties, or you can send along an audio file to provide ‘bird call’ for an image of the rare species you have sighted). The image can be formatted appropriately to account for such things as: current channel environment, end user capabilities, cost of service, etc. This can also be used as part of a Caller ID scheme by providing a User selected image to accompany the call. Push to Video: Send a Video Session to Members of the PTX Call This service allows the user to send not only an image, but a true video stream to other select users. This service would support video sessions of varying levels of quality from stop frame, to streaming, to live action. There can be multiple media streams (e.g., voice commentary) to accompany this video media to add value to the video session. Push to Game: Real-time Sharing of Information in a Group Gaming Environment The instantaneous nature of the ‘push-to’ service along with the ability to provide source arbitration across a group of participants can be used in interactive gaming services. Additionally this could be used as an introduction to a gaming environment in which the end user could simultaneously play the game and converse (via voice, text messaging, etc.) with other people to get help in operating the game. Push to Meet: Manage Online Meetings Using Presence Information By using the presence information to determine who/when select users can meet to communicate via a PTX session, a more efficient online meeting environment can be created. This can also be mated with location information for each of the potential call members; potentially a distance attribute could be included in the selection criteria to determine suitable members for the call (e.g., members who are currently within 2 miles of location x). This could be used to schedule communications or gain necessary information more efficiently and on a timely basis from select subject matter experts. Based upon the current attributes of pertinent users, calls can be dynamically scheduled and call membership can be dynamically adjusted as other pertinent users become available for the session. Each of the members of the PTX session could provide and receive session communication based upon particular characteristics of the user’s PT X end device and the particulars of the PTX communication itself. Push to Share: Virtual Reality Shared Environment This leverages virtual reality multimedia offerings to provide the environment of a user to other select users to allow for more efficient/realistic sharing of information or an experience. In this mode the end user would literally be able to experience a version of the sensed environment of the sender and could share/interact in the current experience. The perspective of the PTT service evolving beyond simply ‘talk’ to encompass any type of media and service represents a range of bright opportunities for the Push-to-‘Anything’ future. 394 Push-to-Talk: A First Step to a Unified Instant Communication Future 14 Location Based Services Ioannis Priggouris, Stathes Hadjiefthymiades and Giannis Marias 14.1 Introduction Location Based Services (LBS) can be considered as the most rapidly expanding field in the mobile communications market. Their first appearance, in a much more primitive form than that known today, is traced back in the middle of 1990s, propelled by the advent of the GPS positioning system. However, only a few years later the proliferation of the mobile/wireless Internet, the constantly increasing use of handheld, mobile devices and position tracking technologies and the emergence of mobile computing prepared the grounds for the introduction of this new type of services, with an impressively large number of applications for the general public. According to recent research results, the LBS market will generate over US$5 billion for European operators alone, by the end of 2005 [1]. Such estimates justify the increased interest of all the key players in the LBS chain (e.g., telecom operators, content providers, service providers, etc.), in the development of advanced solutions that can boost the market. So what exactly is a Location Based Service? In the popular context, Location Based Services have come to mean solutions that leverage location information to deliver consumer applications on a mobile device. Application opportunities can be grouped into the following categories: navigation and real-time traffic monitoring; location-based information retrieval; emergency assistance; concierge and travel services; location-based marketing and advertising; location-based billing. These categories target to the wider portion of the LBS market and will be accessible to millions of users by large players in the telecommunication, automotive, and media industries. Apart from these services, however, an additional set of applications, focused on specialized target groups (e.g., the corporate sector, the health sector) will be developed. These include: dispatch and delivery route optimization; monitoring person location, which includes data for health care, emergency calls and prisoner tagging; Emerging Wireless Multimedia: Services and Technologies Edited by A. Salkintzis and N. Passas # 2005 John Wiley & Sons, Ltd third party tracking services for Enterprise Resource Planning (ERP) and the corporate and consumer markets (e.g., fleet management, asset or individual tracking); security and theft control; people finding. Apparently, Location Based Services cover the whole range of user needs from emergencies (such as the FCC E911 mandate for mobile emergency calls) to amusement (e.g. friend finder, POIs), as well as a large range of business needs (e.g. fleet management). For the development and provision of LBS services, a synergy of different, yet complementary, technologies and architectures is required. An overview of these technologies, along with other critical technical issues, is given in the sections below, in an attempt to define the requirements and the architectural aspects of an LBS system; that is a system focused on the delivery of location based services. 14.2 Requirements Before stating the requirements for delivering Location Based Services to end users, we will establish a common nomenclature and identify the essential components that make up such a process. There are two main entities involved in the LBS provisioning model: (1) The ‘LBS server’, which is responsible for providing the location sensitive information to the ‘LBS client’. Providing such answers may also require invocation or queries to other network entities. (2) The ‘LBS client’, who asks the ‘LBS server’ for location sensitive information and is the recipient of the response produced by the corresponding service; an LBS client may range from a notepad computer to a mobile phone or any other handheld mobile device. Hereinafter, we will refer to the combination of these two entities as the ‘LBS system’. It is evident that the LBS provision model greatly resembles the standard client-server model (Figure 14.1). There is always an entity that asks for the information and another who should provide it. Although, this is true from a logical perspective, sometimes it is not very easy to physically separate the server and the client entities, as they may both reside in the same physical device. This was the usual case until a few years ago, when the concept of an LBS system would normally bring to mind an electronic device, equipped with a GPS receiver and a display, where the user could see his current position, possibly on a map. However such proprietary LBS solutions were characterized by certain drawbacks. First the consumer found them expensive; the cost of the electronic device was AP1 AP2 AP3 LBS Applications LBS Server request response LBS Clients Figure 14.1 LBS client-server architecture. 396 Location Based Services usually high. Moreover, the device was capable of providing only a certain range of LBS services and no enrichment was possible due to the lack of open interfaces. Currently, such solutions, although not completely abandoned, are targeted to a specific class of users, and have been replaced in solutions that apply to the classical Client-Server model, where the entities involved are physically apart. A key factor in this development was the growth in the capabilities of mobile and handheld devices, as well as the growing maturity of the wireless infrastructure in terms of positioning technology. Moreover, the new model completely separates the service logic from the client side, thus allowing new services to be developed and be accessed using the same terminal equipment. Having made this brief analysis, we can now proceed to some of the basic requirements that an LBS system should meet. Prime requirements include the following. Cost-effectiveness. Service delivery should not require the end-user to buy costly equipment. Openness. Service provisioning should support a variety of access protocols so that the service is available through different networks and different client equipment. Reusability. The LBS system should be capable of hosting a number of different services, with different requirements and functionality. The introduction of new services should not require changes to either the LBS Server or the Client and potential changes to the Server should maintain downward compatibility (i.e, should not affect the execution of existing services). Security and privacy. Security in the interfaces with external entities is essential so that secure communication and privacy is achieved. This is a fundamental requirement as the end user would not normally be willing to have his personal information (e.g., location) revealed to a third party. Scalability. The system should be able to host a large number of services, each capable of serving numerous concurrent requests. Extensibility. The system should be extensible and capable of accommodating new technologies. In order to achieve this, there must be independence from underlying technologies. Therefore the system should not be bound to any specific positioning or GIS technology. This will allow it to easily adopt newly evolved technologies from both sectors, thus increasing its life expectancy. Additional requirements, which are optional, but may greatly enhance the potential of the LBS system include the following. Support for many operation paradigms. This means that apart from the classic request/response functionality, the platform should support services using the push model as well as event scheduling, which can be based on time or location events (such as notifying a user using SMS when he enters a shop about the day’s offers). Roaming across different infrastructures. Both indoors and outdoors environments should be supported. Support for flexible service creation processes. Support for service deployment and operation, which should be provided through automatic procedures. Portability. Independence of operating systems and hardware platforms is a characteristic of prime importance as it guarantees integration with every infrastructure. Having established the mandatory and desirable requirements as listed above, in the following section, we will proceed with the definition of its architecture and a comprehensive analysis of the heterogeneous technologies that such a system can merge. 14.3 LBS System As already mentioned, an LBS system is composed of two elements; the LBS Server and the LBS Client. In this chapter we focus mainly on the Server side, while a brief discussion on LBS clients, their capabilities, and special configurations that may be needed is provided at the end of the chapter. LBS System 397 A generic LBS provisioning model is shown in Figure 14.2. In the figure the main entities involved in the LBS provisioning scheme are depicted. Hence, apart from the core LBS System, as was defined earlier the model contains also three additional types of systems: the Positioning System; the Spatial Data (GIS) System; Supplementary Systems. The first two systems are essential to the LBS provisioning chain, as the information they provide to the LBS Server is mandatory for executing the LBS application. The ‘Supplementary Systems’ category includes auxiliary or optional entities (e.g., billing systems), which although not needed for the basic LBS provisioning process, can greatly enhance it and allow the implementation of advanced concepts such as service personalization, QoS differentiation and different provisioning policies. Further details of all these systems are given below. An important issue is that although each system in the generic model is depicted as topologically distinct, this is not mandatory. The model in Figure 14.2 shows the logical separation between the different components of an LBS System. The LBS Server, for example, may integrate the GIS system as well as the Positioning system in the same physical node. 14.3.1 LBS Server The LBS server is the actual middleware that is used for the provisioning of LBS services. Running location-based applications requires the integration of many different technologies from both the Information Technology and Telecommunications (ITC) sector. Given that ITC technology is rapidly LBS Clients IDC Digital geographical data Positioning System LBS Applications Spatial Data (GIS) System LBS Server Other Systems Figure 14.2 Generic LBS provisioning model. 398 Location Based Services evolving, designing an extensible and open LBS middleware infrastructure is essential, in order to interact with heterogeneous systems that facilitate inter-operation with these evolving technologies. Moreover, according to the generic LBS model (Figure 14.2) these systems may belong to different vendors, each having its own communication protocols and APIs. Despite the fact that standardization institutes and fora (e.g., ETSI, 3GPP, OMA, OGC, etc.), together with key business players in the communications and GIS sector, have specified standard protocols and APIs for implementing such interaction, there is a large portion of the market that still uses proprietary interfaces. In order to cope with such peculiarities a generic LBS server should provide a framework that is capable of adapting to all them, with the minimum possible changes. Application server architectures provide such extensible frameworks. An application server all ows one to develop and shelter the business logic that is neede d for executing an LBS service and at the same time saves the need to re-engineer your system if a component in the architecture needs to be changed. There are many reasons to approach a location server infrastructure as a series of logically discrete components integrated through business logic stored in an application server [3]. It allows you to create infrastructure services based on industry standards for the various specialized components required. Your positioning interface might be based on the specification recommendations provided by the Open Mobile Alliance (OMA) and your spatial data server interface might be based on the Geography Markup Language (GML) proposed by the Open GIS consortium (OGC). However, the major advantage of this logical separation is that any one piece of your infrastructure is insulated from problems in another component. It allows you to substitute components that do not deliver acceptable results without affecting the rest of the system, and it also allows you to enhance components’ functionality easily. Hence, interfacing with any proprietary system is possible through replacing standard infrastructure services with new ones that will comply with the peculiarities of the desired protocol. Apart from making the LBS server extensible, the use of an application server as a basis for the LBS server provides automatic fulfillment of two other basic requirements for service provisioning systems that are reusability and scalability. The basic functional components of the generic LBS server are shown in Figure 14.3. Four main functional areas have been identified, namely: (1) the LBS Application layer; (2) the Infrastructures Services layer; (3) the Presentation layer; (4) the Management layer. We will further elaborate on the functionality of each layer in the following subsections. 14.3.1.1 LBS Application Layer We will start our analysis with the LBS Application layer, which is the hosting system for all LBS applications running on the server. Each layer contains the business logic of a corresponding LBS service. Upon being called, by the LBS client, each LBS application collects the requested information and returns it to the end-user. In order to achieve the required functionality, it has to perform a number of actions: parse the incoming request, consult a number of services from the Infrastructure Se rvices layer, create a response and post it to back to the c lient. We will further examine the overall process flow that takes place inside the LBS Server after we review in detail the internal architecture of the LBS system. This layer also features an API, which allows communication with external service creation systems. This interface permits service deployment from such entities and could allow automatic service deployment tools to be built and integrated with the LBS server. In the same perspective, advanced service creation platforms can be connected through the same interface. LBS System 399 14.3.1.2 Infrastructure Services Layer The most important part of the LBS server is the Infrastructure Services layer. This layer contains the business logic, which is usually used by the LBS applications and which facilitates the interaction with external systems. In the absence of this layer, each location service would need to incorporate the corresponding logic in itself. Such an approach is far from optimal for a number of reasons, which will become obvious from the following example. Assume that the LBS server is connected to a positioning system using a well-established protocol such as the Open Service Access (OSA) protocol [12]. The OSA specification defines an asynchronous communication protocol, where both the client and the server side need to implement predefined interfaces. Whenever, the client side, which in this case is the LBS server , needs to retrie ve the position of a device, it initiates an interaction with the OSA compliant positioning sy stem. A couple of messages are exchanged between the two entities, before the result of the initial query, is returned to the client (Figure 14.4). In the presence of the Infrastructure Services layer, a positioning service takes care of all the aforementioned interaction. The service hides all the complexity of the OSA communication protocol, its particularities, asynchronous nature and specific parameter types. The LBS application only needs to perform a single call towards the positioning service and wait for the answer. This approach not only removes the programming burden from the developer of the LBS application, but also promotes the re-usability principle, which is considered a prime requirement for the LBS system engineering. Now, let us review the case where no infrastructure services are present. Given that no position- ing service exists, communication with the positioning system is handled internally by the LBS application. LBS application developers have to incorporate identical business logic in their applications Presentation Layer LBS clients Positioning service Dispatcher service GIS service Billing service Authentication service Accounting service LBS Applicat ion LBS Applicat ion LBS Applicat ion LBS Application LBS Application Layer Scheduling service Management Layer Positioning System Spatial Data (GIS )System Billing System User Database/ LDAP Accounting System Infrastructure Services Laye r Service Creation System Service registry Figure 14.3 LBS Server generic internal architecture. 400 Location Based Services every time they want to acquire location information. However, most important of all: if for some reason the interface with the positioning system has to be changed, the same should apply to all installed LBS applications. All of them will need to be rewritten to conform to the new communication protocol. Note that in the first case, the same change would impact only the infrastructure positioning service, which would have to be rewritten according to the new protocol. This paradigm showed that the Infrastructure Services layer is the actual middleware, which is placed between the LBS applications and the various external systems and provides, to the former, a means to retrieve information efficiently from the latter. It strongly resembles what the JDBC middleware does for Java applications, in terms of interfacing with an RDBMS. Basic infrastructure services, pertaining to an LBS system, include: the Positioning service, which implements communication with positioning systems (a detailed analysis on available positioning systems will follow later in the chapter); the GIS service, which creates a communication link with the spatial data system (e.g. the GIS server), in order to perform spatial requests and acquire the needed data. Additional infrastructure services that are not required for providing the core LBS functionality include the following. The Authentication service, used for interfacing with repositories containing user-specific info. The LBS application developer may utilize this service for restricting access to certain users either to the LBS system, or to specific applications in it. Moreover, the information acquired during the authentication process may be used for customizing the LBS application according to the user’s preferences (i.e., personalisation). The Billing/pricing service. This service facilitates communication with billing/pricing gateways. It provides the application developer with the means to create billing accounts, checking pre-paid accounts in order to determine whether the user can use the service and it allows the implementation of advanced billing and pricing schemes from the side of the service operator. The Accounting service. This provides a convenient way to interface with external entities (e.g., databases) and store accounting information, pertaining to the usage of the LBS server. This information may be used for a variety of purposes, such as monitoring performance, tracking access to the server, tracking errors, etc. Positioning Service Positioning system locationReportReq() locationReportRes() Figure 14.4 OSA-specific position retrieval sequence diagram. LBS System 401 Finally, there are some infrastructure services that are not meant to interact with external systems, but whose presence is essential for delivering the LBS application. We have identified two such services. (1) The Dispatcher service. The task of this service is to intercept incoming requests from client applications and dispatch them to the corresponding requested service. It acts as the central entry- point for all incoming requests and provides a hidden discovery-like service for them independent of the used communication protocol. If, for example, a communication between the LBS client and the server uses the HTTP protocol, the Dispatcher service may be a simple servlet application which will perform a lookup in an internal service repository for determining the availability of the requested LBS application, and invoking it. If another protocol is used, then the servlet is replaced by another application, featuring the same interface and identical behavior and everything is as it should be. More than one client-server communication protocols (HTTP, WAP, RMI, TCP/IP, CORBA, SMS, etc.) could be supported simultaneously, by using multiple dispatcher services, one for each supported protocol. (2) The Scheduler service. A scheduler service is essential both for supporting the delivery of appli- cations to the end-user as well as for scheduling internal tasks that may be required by the LBS server. An example of the former includes the triggering of the execution of certain LBS applications, in certain time intervals. For instance, a user may register for receiving weather forecast SMSs, once per day, or a father may register for being informed on the location of his underage son every 2 hours. Several paradigms of such time-scheduled service provision can be devised. Regarding the LBS server itself and its internal operation, a scheduling service could be used for implementing opera- tions like clearing cached data, restructuring internal repositories after a certain amount of time, freeing memory and many others which are typical for such enterprise systems. An archetypal sequence diagram, depicting the internal flow of data inside the LBS system from the time a request is posted by the client until the corresponding response is received, is presented in Figure 14.5. LBS Client LBS Server: Dispatcher LBS Server: LBS Application X LBS Server: Positioning Service LBS server: GIS Service LBS server: Authentication Service request(Application X) invoke() authenticate() requestPositionData() requestSpatialData() Application results LBS response Figure 14.5 Typical processing of an LBS request. 402 Location Based Services 14.3.1.3 Presentation Layer Presenting the answer produced by an LBS application to the end-user is a fundamental part of the LBS provisioning system. As we have stated in previous paragraphs, the LBS server can potentially support a variety of protocols for communicating with the client devices. In a typical two-tier architecture the presentation logic would normally be embedded with the business logic. For an LBS server, this means that each service has to check the protocol of the request and format the response accordingly. It is sensible to assume that such an approach is not optimal as there are too many communication protocols available today, each with it own peculiarities and characteristics. Handling all of them inside the service logic would not only be overwhelming for the service creator, but it would also require the whole service to be rewritten in order to support additional protocols. For the three-tier architecture model, which is followed by all modern software systems, the proposed generic LBS architecture features a presentation layer, whose purpose is to provide the necessary modules and tools that will format the results, produced by the underlying layers, in an attractive and comprehensive way by the end terminal. Inserting this layer between the LBS server and the client we automatically gain a significant advantage, as now the service can adopt a single format for its answer, which will then be transformed in the presentation layer to that understood by the client. The XML specification is the most appropriate format for the initial response produced by the LBS application, due to its simplicity and the plethora of tools and technologies that are available today (e.g., XSLT, DOM, SAX) for its processing and transformation. XML allows the development of a single interface to the LBS server that uses different style sheets (e.g., XSLT) to customize output for the format the client is expecting (Figure 14.6). HTML, HDML, cHTML, WML and VXML are all based on the XML specification. If the presentation layer is based on XML, supporting a new client (or protocol) requires nothing more than creating a new style sheet. It does not require a new interface to be engineered. 14.3.1.4 Management Layer A flexible management interface is required in order to administer the LBS server effectively. The manage- ment interface should have methods that will, at least, allow the following operations to be performed. Starting an LBS application. Each LBS application upon being deployed on the Server should not be eligible for access by the end users. Enablement of the application should be done explicitly through the LBS Server’s management console. LBS Clients LBS Application Dispatcher Service XML-HTTP Transformer HTTP XML XML XML-WAP Transformer XML-SMS Transformer Presentation Layer XML-Other Transformer Figure 14.6 Use of XML transformers for presenting results to end users. LBS System 403 [...]... and the lack of ready LBS provisioning solutions, have developed software tools and middleware platforms for handling both the creation and delivery of such services Most of these platforms offer a robust environment that, to some extent, can be used for developing LBS services The vast majority of LBS platforms are built using Java enterprise technologies, and most of them comply with industry standards... location based services provisioning, in Proc 3rd International Workshop on Web and Wireless Geographical Information Systems (W2GIS 2003), Rome, December 2003 [44] A Ioannidis, M Spanoudakis, P Sianas, I Priggouris, S Hadjiefthymiades and L Merakos Using XML and related standards to support location based services, in Proc SAC’2004, 19th ACM Symposium on Applied Computing, Web Technologies and Applications... services and content Core services include: location utilities services; directory service; presentation services; gateway services, and route determination services The OpenLS standard [32] aims at the development of interface specifications that facilitate the use of location and other forms of spatial information in the wireless Internet The exact objective of the OpenLS initiative is the... (COPS-PR), 254 COPS, 112 Emerging Wireless Multimedia: Services and Technologies Edited by A Salkintzis and N Passas # 2005 John Wiley & Sons, Ltd Index 428 Core Network (CN), 239, 241, 245, 249, 252 Cricket, 411 Data Plane IETF protocols for, 87 ITU-T protocols for, 85–86 Deck, 276 decoder, 51 de-jitter buffer, 51 delay jitter, 58 delay-constrained retransmission, 60 Dialog SIP, 108 DIAMETER, 112 Differential... given location and find the shortest path to the destination In the OGC location services reference model, the SDB (Location Content database according to OGC [32]) server acts as a back-end server to the GeoMobility server The GeoMobility server comprises abstract data types (ADTs) and core services through which a service provider can provide location application services and content Core services include:... advanced platforms available today cater for all standard interfaces used by mobile phones (SMS, Multimedia Messaging Service (MMS), WAP) as well as HyperText Markup Language (HTML) for 2.5G and 3G HTML-enabled mobile phones and PDAs In terms of positioning technologies, those supported are mostly those interfacing with GMLC-enabled 2G and 3G networks LocatioNet and Cellpoint’s MLS/MLB platforms cover all... House, 2002 424 Location Based Services [7] B W Parkinson and P K Enge, Differential GPS, Global Positioning System: Theory and Applications, Vol II, ed B W Parkinson and J J Spilker Jr., American Institute of Aeronautics and Astronautics, Inc., Washington DC, pp 3–50, 1996 [8] J Benedicto, S E Dinwiddy, G Gatti, R Lucas and M Lugert, GALILEO: Satellite System Design and Technology Developments, European... Mulligan, J Morris and J Peterson, Threat Analysis of the Geopriv Protocol, RFC 3694, IETF February 2004 [36] Shashi Shekhar, Ranga Raju Vatsavai, Xiaobin Ma and Jin Soung Yoo, Navigation systems: a spatial database perspective, in Location-Based Services, eds J.Schiller and A.Voisard, Morgan Kaufmann, Elsevier, 2004 [37] Oracle spatial user’s guide and reference, 10g Release 1 (10. 1), Oracle Co.,... Location Services (LCS); (Functional description) - Stage 2 (Release 1999) [42] A Ioannidis, I Priggouris, I Marias, S Hadjiefthymiades, C Faist-Kassapoglou, J Hernandez and L Merakos, PoLoS: integrated platform for location-based services, Proc IST Mobile and Wireless Communications Summit, Portugal, June 2003 [43] M Spanoudakis, A Batistakis, I Priggouris, A Ioannidis, S Hadjiefthymiades, and L Merakos... and efficient management of data related to a space in the physical world An SDB provides conceptual, logical and physical data modeling facilities to build and manage spatial databases Spatial information contained in the SDB is in the form of digital road maps and can be modeled and managed as discussed below Digital road maps Location based services rely on digital road maps, postal addresses and . dispatch and delivery route optimization; monitoring person location, which includes data for health care, emergency calls and prisoner tagging; Emerging Wireless Multimedia: Services and Technologies. abstract data types (ADTs) and core services through which a service provider can provide location application services and content. Core services include: location utilities services; directory. presentation services; gateway services, and route determination services. The OpenLS standard [32] aims at the development of interface specifications that facilitate the use of location and other
Ngày đăng: 14/08/2014, 12:20
Xem thêm: emerging wireless multimedia services and technologies phần 10 pps
