Hostname: page-component-745bb68f8f-lrblm Total loading time: 0 Render date: 2025-02-07T05:20:27.782Z Has data issue: false hasContentIssue false

Location-Based Services: A Road Towards Situation Awareness

Published online by Cambridge University Press:  02 October 2008

Renato Filjar*
Affiliation:
Ericsson Nikola Tesla, Zagreb
Gordan Jezic
Affiliation:
University of Zagreb
Maja Matijasevic
Affiliation:
University of Zagreb
Rights & Permissions [Opens in a new window]

Abstract

With the widespread use of mobile devices and increased demand for mobile services, Location-Based Services (LBS) represent a promising addition to service offerings of network operators as well as third-party service providers. Based on long-term research in LBS, our group has proposed a generic Enhanced LBS Reference Model (ELRM), which describes the concept, the architecture and the functionalities of the LBS. In addition, an evolutionary information process has been identified within the LBS, that represents knowledge maturity from position awareness to situation awareness. Both the ELRM and the information evolution process in LBS are presented in this article and illustrated by a case study within the framework of the 3GPP-standardised IP Multimedia Subsystem (IMS). This case-study emphasises the opportunities for navigation- and LBS-related solutions development provided by modern telecommunication technologies.

Type
Research Article
Copyright
Copyright © The Royal Institute of Navigation 2008

1. INTRODUCTION

The modern definition of location-based services (LBS) presents them as a group of emerging telecommunication services that successfully and purposefully merge ubiquitous position determination, mobile data communications and position-related content, with a defined level of quality of service (QoS). A considerable development has been made in recent years with the aim to define the general LBS reference model that would be able to present all entities required for implementation of a location-based service, and their interrelations. Our group has developed the unique LBS reference model which successfully presents the process of obtaining the best positioning estimate and communicates it with the LBS applications (Filjar et al, Reference Filjar, Dešić and Tržec2004). However, in search of a more general reference model of LBS as an information and telecommunication service, a considerable enhancement of this model was to be developed. As a result, the Enhanced LBS Reference Model (ELRM) has been identified (Filjar, Bušić, Reference Gourraud2007). Further evaluation of the ELRM has led to identification of an evolutionary process through which the “raw” position estimate matures to location. This evolution paves the road towards practical implementation of situation awareness.

This paper addresses improved ELRM concept, architecture, and functionalities, and describes location information evolutionary process. Practical implementation that can provide situation awareness is discussed in the case study utilising the Internet Protocol (IP) Multimedia Subsystem (IMS), a key element of the next-generation converged telecommunication network architecture.

2. TERMINOLOGY

Before dissemination of the proposed ELRM, the authors have found it of utmost importance to distinguish the meanings of two terms frequently interchangeably used in association with the LBS: position and location. In view of later discussion, a definition of both terms will be given here.

As used in this article, a position is assumed to be a quantitative representation of the place of the physical object in a given spatial co-ordinate system. One of the most common means of expressing position, at least in terms of navigation, is through latitude, longitude and height above the sea level, with, for instance, the WGS84 system chosen as a reference. A location is to be assumed a position enriched with additional information elements referring to the relationships between the physical object, e.g. a building, (represented with its position) and the other objects in its surrounding area. In practical deployment and as an example, location of a physical object can be expressed by an address or the name of the building and with relation to other navigation- and orientation-relevant objects in the neighbourhood (for instance, building A, entrance B, to the north from the car park C). Evidently, the position of the physical object is embedded in location, and can be extracted from it by applying the appropriate procedures.

In view of the above-mentioned definitions, the process of position and location determination can be defined, as follows. Position determination simply means the process of determination of the co-ordinates of the physical place in a given reference system, where a certain physical object resides at the moment. For example, systems like Global Positioning System (GPS), Galileo, Glonass, Global Navigation Satellite System (GNSS), (Filjar, Reference Filjar2003), VHF Omni-directional Radio-range (VOR), Instrument Landing System (ILS) represent various positioning systems. On the other hand, location determination means the process of enhancement or enrichment of the position with the information about the object itself as well as the spatial relationship with the other objects residing in the neighbourhood. Every location-based service comprises the evolution from position to location, as it will be presented in the rest of this article.

So far, the LBS have been considered a mechanism for provision of location awareness, which can be defined as the ability to identify the static environment around the position given and spatial relations between nearby physical objects (buildings, roads, rivers, coastline etc.). Here a much broader concept is advocated which calls for the provision of situation awareness. The term refers not only to the ability to identify the static spatial relationship with surrounding physical objects, but also to provide near-real time information about events, temporal status of nearby objects and their expected or announced actions – all of that in order to allow decision making for a user's goals and objectives, both at present and in the near future. Observed in this context, situation awareness is a feat related to the user of a certain location-based service, rather than an issue related to a telecommunication network providing the location-based service in question. (Endsley, 2000) has defined situation awareness as:

“… the perception of elements in the environment within the volume of time and space, the comprehension of their meaning, and the projection of their status in the near future.”

Although the term situation awareness usually refers to military-related actions, its meaning is much broader, as seen from the definition above. This justifies the utilisation of the term in description of location-based services.

3. LOCATION LANDSCAPE CONCEPT

As the information services managing location-related content, LBS can be considered a part of the geoscope concept (Erle et al, Reference Erle, Gibson and Walsh2005). So far, the living environment of every human has been considered in terms of the physical landscape. Following this line of development, LBS were concentrated on the nearest-physical-object types of solutions, greatly limiting the actual space of opportunities. The geoscope concept extends the LBS focus to the concept of the nearest location-related information. With this extension, the information space around the service initiators becomes multi-dimensional. Instead of focusing on the nearest physical objects, LBS starts to consider a wide number of layers in information space. A possible set of examples of these layers is presented in Figure 1.

Figure 1. Various location landscape thematic layers.

The groups of location landscape layers contain location-related data in various forms. Thus, the location landscape can consist of database information, multimedia streaming content, and even location-related IT services. Census data, information about community events and activities, historical and cultural details, environmental and actuarial details, data from the national office of statistics and advertisements can be held in distributed databases and accessed using the appropriate searching algorithms. Multimedia content (photos, audio and video) can be geo-tagged, and thus made available for the content search using the appropriate tools and methods. Banks and insurance companies, as well as telecommunication operators and tourist agencies can offer location-related services designed according the needs and offers of the local environment. Not to be neglected, location-related games and entertainment can be arranged in order to suit local tradition, physical landscape, or combined with some other groups of location landscape layers in order to provide the added value service. Finally, whilst it may not be welcome from the recipient, it would be possible to send location-related spam and advertisements in order to target visitors at certain premises.

4. LOCATION LANDSCAPE AND LBS

Extension to the nearest location-related information-type of service creates a multi-layered information space (called the location landscape, Erle et al, Reference Erle, Gibson and Walsh2005) that is to be explored according to the requirements of a particular LBS service. In that space, layers present the subsets of the location landscape that are to be deployed according to requirements of the LBS service. Location landscape consists of location-related content. The modern approach in classification of location-related content sees it in a 4-dimensional information space, with three dimensions related to spatial coordinates of position and the fourth related to time (age of data). The content may be considered as either static or dynamic (Tookey, Reference Tookey2007). Static location-related content is related to position only, and invariable to time (at least for a reasonable amount of time). On the other hand, dynamic location-related content is characterised by both spatial and time variability. Typical examples of static and dynamic content are the spatial distribution of buildings in a village and weather conditions in the observed area, respectively. Even a small community can provide a rich location landscape, as shown in Figure 2.

Figure 2. An example of location landscape created around the small community of Baška, Krk Island, Croatia.

The formation of location landscape is essential for deployment of the geoscope concept. It is not, however, essential to form a centralised entity (a database, for instance) containing the whole location landscape information (Waller et al, Reference Waller, Lewis, Jones and Craddock2007). Rather, it is much more feasible to maintain an index of addresses where the most accurate and relevant location landscape layers are stored (list of related Internet sites, for example). The introduction of the geoscope concept brings an inevitable impact on the telecommunication network that supports the LBS. Apparently positive, this impact calls for a better integration of different telecommunication networks that a mobile user can use. Furthermore, the location landscape-based location services interweave a number of information systems that store location landscape layers (Waller et al, Reference Waller, Lewis, Jones and Craddock2007, Pottebaum and Torchia, Reference Pottebaum and Torchia2006).

As an example of a targeted advanced LBS service, an investor could ask for all relevant information that can be applied in order to present a clear picture of where and when to invest money in property acquisition for a selected local geographical area. This could ask for a several location landscape layers to be deployed on the basic physical layers, for instance:

  • —spatial distribution of current prices for properties

    spatial distribution of household income

    spatial distribution of communal infrastructure (water supply, electricity lines, gas pipelines etc.).

On the other hand, an exemplary LBS service for local residents and tourists might collect the following location landscape layers in order to provide an information service:

  • —local road traffic conditions

  • —list of local community events

  • —tourist information (accommodation, restaurants, attractions).

5. ENHANCED LBS REFERENCE MODEL

An initial LBS reference model, introduced by our team earlier (Filjar et al, Reference Filjar, Dešić and Tržec2004), defined the process of managing position-related information. Focused on the generic positioning process based on two lower layers (Basic and Advanced Positioning), the LBS reference model left location context management to the upper layer (Application Layer). Considering the LBS as a synergy between ubiquitous positioning, mobile communications and location landscape (location-related content), the information traffic and location-related content management have been inevitably brought into the focus of the Enhanced LBS Reference Model (ELRM) (Filjar, Bušić, Reference Filjar and Busic2007). After the identification of an evolutionary information process within the LBS, the ELRM is improved in order to cover the whole situation awareness concept. The ELRM is briefly presented in this section.

5.1. ELRM description

The ELRM is established as a four-layer model as presented in Figure 3:

  • —Basic Positioning Layer (BPL)

  • —Advanced Positioning Layer (APL)

  • —Location Landscape Aggregation Layer (LLAL)

  • —Application Layer (AL)

Figure 3. Enhanced LBS Reference Model (ELRM).

The Basic Positioning Layer (BPL) consists of basic positioning methods. The BPL presents the raw positioning measurements related to the current user position, based on standard (non-enhanced) positioning methods (satellite positioning, network positioning, radio positioning techniques etc.). For instance, a non-augmented GPS receiver that provides either pseudorange measurements or initial position estimate should be considered a constituent of the BPL.

The Advanced Positioning Layer (APL) consists of various methods for positioning assistance and augmentation to basic positioning. The APL yields the best available position estimate (BAPE) of the rover (mobile user), based on the raw positioning measurements, the positioning enhancements (positioning assistance, positioning augmentation etc.) and the appropriate positioning sensor fusion algorithm (Kalman filter, particle filter, neural network etc.). In this context, the BAPE should be considered the most likely place where a mobile subject (rover) should be found at the moment of location-based service initiation.

The Location Landscape Aggregation Layer (LLAL) creates a location landscape around the obtained BAPE, using the available location-related information from trusted and reliable sources, thus applying the previously mentioned geoscope concept. The location-related data may be obtained from, for instance, trusted and reliable Internet resources, such as GIS and statistical data offered by governmental agencies. Additionally, both internal and external sources are used for collecting information related to the dimension of time for every object, event, or action, when available. Location landscape is established in such a way that the sources of location-related information in both spatial- and time-dimensions are identified and the location-related content is made ready for use by the next ELRM layer.

The Application Layer (AL) selects the subset of location landscape content created at the previous layer and necessary for provision of requested location-based service, shapes it according to the specific user and service profiles requirements, and provides a framework for information exchange (information presentation, communication) with the service user. The AL applies the information filters as the entities capable of selecting the location information required for particular location-based service provision from a previously established location landscape around the BAPE. As a result, the LBS application will provide content and service with selected LBS information extracted from the location landscape created around the estimated position of the mobile user.

5.2. Information evolution in ELRM

An information evolution taking place within the Enhanced LBS Reference Model can be identified, as presented in Figure 4. Starting with the initial position estimate as the substance of every LBS, the process first enriches the initial position estimate with the augmentation, assistance and sensor fusion in order for the best available position estimate to be obtained. Then, the best available position estimate initiates the location landscape formation, as the necessary prerequisite for evolution from position to location, as defined in Section 2. In regard to the evolutionary path from initial position estimate to location, the latter should be considered a subset of the location landscape, which is determined by the user's (rover's) best available position estimate. In the final stage of LBS information evolution, location is enriched by dynamic location-related content, allowing for making decisions in regard of both present location and expected short-term activities of surrounding objects, thus forming a situation.

Figure 4. Information evolution in ELRM.

6. IMPACT OF THE ELRM ON LBS DEVELOPMENT

The ELRM and the LBS information evolution model together form the generic functional description of any location-based telecommunication service, as presented in Figure 5.

Figure 5. General functional description of a location based service.

Components of the Basic and the Advanced Positioning Layers allow for performance of the advanced, best available position estimation. This is usually conducted within the access and core telecommunication networks. On the other side, location-related content management is a task usually performed by an application server. It creates a location landscape around the estimated position of mobile user, based on static and dynamic location-related content available for a place in question. Both static and dynamic location-related contents are provided by trusted and reliable sources, usually outside the telecommunication network in support of the invoked LBS service. Information filtering, needed for extraction of the sub-set of the location landscape related to the invoked LBS service is conducted based on the preferences of both the user and the LBS in question (expressed as user and service profiles, respectively). A selected sub-set of location landscape is then provided in the form of suitably converted content or service related to the position of the mobile user.

7. CASE STUDY

In this section, we present a possible implementation of the proposed model within the framework of the IP Multimedia Subsystem (IMS), the standardized next generation network architecture specified by the 3rd Generation Partnership Project (3GPP) and adopted by other standards organisations, such as Open Mobile Alliance (OMA), European Telecommunications Standards Institute TIPHON (Telecommunications and Internet Protocol Harmonisation over Networks) and SPAN (Services and Protocols for Advanced Networks) (ETSI TISPAN) and 3rd Generation Partnership Project (3GPP2) (Camarillo, Reference Camarillo and Garcia-Martin2004). The IMS architecture is usually depicted as having three layers, as shown in Figure 6: the Service Layer, the Control Layer, and the Connectivity Layer. The IMS uses the Session Initiation Protocol (SIP), initially developed by the Internet Engineering Task Force (IETF), as the main signalling protocol.

Figure 6. Simplified view of the IMS architecture.

The Service Layer comprises application and content servers which host and execute user services. The IMS allows for generic and common capabilities, implemented as services in SIP Application Servers (AS), to be reused as building blocks across multiple applications and services. A capability that may be utilised to provide a service to the end user, by itself or in conjunction with others, is called the service enabler. Some standardized enablers in IMS include presence, group list management, instant messaging, and call control. The Control Layer comprises databases and network control servers for managing call or session set-up, modification, and release. The key IMS entity in the Control Layer is the Call Session Control Function (CSCF). The CSCF is a SIP server responsible for session control and processing of signalling traffic. It controls a single session between itself and the User Equipment (UE). The CSCF plays three distinct “roles”: the Proxy Call Session Control Function (P-CSCF), Serving Call Session Control Function (S-CSCF), and the Interrogating Call Session Control Function (I-CSCF). For the purpose of this discussion, we limit our scope to the S-CSCF, which is responsible for session establishment, modification, and release. It is the function that registers the users and controls the process of services provisioning, although services themselves may reside on separate application servers. It performs routing of SIP requests, number/name translation, provides charging information to support systems, and maintains session timers. It also interrogates the main database containing user related information, the Home Subscriber Server (HSS), to retrieve authorisation, service triggering information, and user profile. The interfaces between the CSCFs and the HSS, as well as those between ASs and HSS are based on Diameter, the IETF's Authentication, Authorization and Accounting (AAA) framework for IP-based networks. The Connectivity Layer comprises routers and switches for the IP Core and access networks. Various access networks are envisioned, for example, 3GPP's General Packet Radio Service (GPRS) and Universal Mobile Telecommunications System (UMTS) Radio Access Network (RAN), 3GPP2's Code Division Multiple Access 2000 (CDMA 2000) RAN, Wireless Local Area Networks (LANs), and various fixed Digital Subscriber Line (DSL) options. The User Equipment (UE), represents networked devices, such as personal computers (PCs), mobile phones, fixed phones etc., which connect to the network at this layer, thus allowing the IMS user to register and access various services offered by, or via, the IMS.

7.1. How the services are composed

Some benefits commonly associated with the adoption of an IMS-based infrastructure include flexible introduction of new services and service integration. Focusing on location-based services, we adopt the point of view that IMS should not only host services but also mediate and add value to 3rd party services (Gourraud, Reference Gourraud2007). To achieve that, a service delivery environment is needed which allows the reuse of common enablers and resources. The important feature of IMS services is that they may be used as building blocks to build more complex services. The functional elements of IMS involved in service delivery are illustrated in Figure 7.

Figure 7. Composition of services in IMS.

The S-CSCF is used for session control and orchestration, while the service logic is implemented within the ASs. Upon registration, the service profile linked to the user is downloaded from HSS to S-CSCF. Service profile includes service-triggering information in the form of prioritised Initial Filter Criteria (iFC). Each iFC contains information on a particular service which needs to be invoked when the particular triggering conditions (Service Point Triggers) are met. When a user issues a SIP request, the S-CSCF will route the request to the appropriate AS based on triggering information in service profile and invoke (zero or more) services, in sequence based on their priority order.

7.2. Adding a Location Enabler

Information about the user's position is a critical piece of information needed for any LBS. With the provisioning of that information considered as a generic and reusable network-provided enabling technology, in our previous work (Mosmondor, Reference Mosmondor, Skorin-Kapov, Filjar and Matijasevic2006) we presented the idea and prototype implementation of a service enabler called IMS Location Server (ILS). ILS is located in the IMS Service Layer. From the point of view of service logic in the IMS, the ILS acts as proxy towards various positioning systems, such as satellite and terrestrial radio positioning systems, as well as systems which utilize mobile communication network signals for position determination. It is important to note that, by providing a uniform (SIP) interface for retrieving the user position information, the ILS provides the means of making this information available to other IMS application servers, thus acting as a “location enabler”. With reference to the ELRM, the ILS comprises the functionality of the APL and the BPL. Its role in the process of LBS provisioning is to provide the BAPE of the user requesting the service to other IMS entities.

7.3. Other IMS Application Servers for LBS delivery

System architecture for LBS delivery in IMS is shown in Figure 8. The following components are involved:

  • —standard Presence Enabler

  • —Presence+Location Enabler

  • —Location Context Enabler

  • —Map Server

  • —LBS Application Server

  • —location-related content providers (3rd party content providers).

Figure 8. System architecture.

The Presence Enabler implements the presence service. In general, the presence service allows a user to be informed about the attainability, availability, and willingness to communicate for a given user on the network (e.g., “available”, “unavailable”, “offline”). When used as an enabler, presence can be invoked by an application that requires information on the status of a user.

The Presence+Location (PresLoc) Enabler is based on the standard Presence Enabler, enhanced with location information. The PresLoc Enabler uses the ILS for retrieving the user position data and sends this information to a subscribed IMS entity together with the requested presence status.

The Location Context Enabler (LCE) is an enabler which allows the user to define a list of personal landmarks. The LCE stores the list of landmarks and makes them available to the user when subscribing to a particular service. The user may also add new entries to the list, as well as modify and remove the existing locations. The location can be visualized on a map retrieved from the Map Server (via Hypertext Transfer Protocol, HTTP). The LCE may also store semantic interpretation of selected locations (e.g., main train station) in a generic presentation format, from which it could be reused for building more complex location-aware services.

The LBS AS has a SIP interface to the IMS Core and an (any standard) data interface towards external content providers. (For practical purposes, HTTP, or File Transfer Protocol, FTP, could be used.) Examples of location-related content providers include various contributors to the location landscape, as shown in Figure 2. The LBS AS performs matching, filtering, and adaptation of location-related content based on user preferences and terminal capabilities. For scalability reasons, the service provided by the LBS AS is based on the loosely coupled messaging model called publish/subscribe, shown in Figure 9. The “publish/subscribe” is an asynchronous messaging paradigm, in which the messages “published” by senders (“publishers”) are delivered only to those receivers (“subscribers”) who explicitly express their interest in a particular topic (subject) or content by subscribing to it. It is important to note that this model is multipoint-to-multipoint and anonymous – the publishers do not need to specify, or even know who the receivers are, and vice versa. Extensions to the basic model have been proposed to accommodate mobility (Podnar, Reference Podnar and Lovrek2004). Publish/subscribe systems may be classified as either topic-based (See Figure 10) or content-based (See Figure 11), depending on the subscriber's ability to tailor the subscription to his or her interests. The topic-based subscription corresponds to a named logical channel, where channel names are fixed and assigned beforehand. Like in a common radio channel, a user subscribed to one or more topics receives all information published on any matching topic channel. The content-based subscription system, on the other hand, allows the subscriber to filter out the content of interest based on multiple filtering criteria and rules.

Figure 9. Publish-subscribe service.

Figure 10. Topic-based subscription.

Figure 11. Content-based subscription.

The LBS AS includes two components:

  • —Publish/Subscribe Component (PSC), and,

  • —Content Delivery Component (CDC).

The PSC receives and processes the user request for a content (e.g., service subscription, service request), while the CDC is responsible for adapting the content and delivering the result to the user. With reference to the ELRM, the LBS AS is located in the AL and the PSC and CDC correspond to Information filter and Information exchange functionality, respectively. The PSC is implemented using the publish/subscribe mechanism extended to support location-based subscriptions and publications of location-related content (Devlic and Jezic, Reference Devlic and Jezic2005). In the context of LBS, the “publishers” are information providers, who publish the content related to a specific geographical position (thus creating the location landscape), and the “subscribers” are registered IMS users, who declare interest in receiving the information referring to a given location. The goal of the PSC is to match publications with subscriptions according to the topic (or content), and the associated location.

Due to the heterogeneity of mobile terminals, it may also be necesary to adapt the form of the content to the requirements of the mobile terminal in use. The CDC performs content adaptation and alters the service behaviour according to the preferences explicitly expressed by the user and the capabilities of the terminal (e.g., amount of memory, processing capabilities, screen resolution, software characteristics, communication status). Some standardised formats for resources, terminal capabilities, and user preferences description include the Resource Description Framework (RDF) specified by the World Wide Web Consortium (W3C), User Agent Profile (UAProf), presence attributes specified by the Open Mobile Alliance (OMA), and PIDF-LO, specified by the IETF GEOPRIV working group for encoding location information and privacy policies. The adaptation and matching could also be performed so as to take into account not just the end-points, like the end-user and the application server, but the current situation in the telecommunication network as well. A possible way to achieve this could be by introducing a network Quality of Service (QoS) matching and optimization function, or a “QoS enabler” as has been envisioned in our previous work (Skorin-Kapov et al., Reference Skorin-Kapov, Mosmondor, Dobrijevic and Matijasevic2007).

7.4. LBS delivery

The delivery method is based on user profile, in which a user defines his/her location-based and non-location based subscription preferences. The preferences include, for example, device capabilities, preferred delivery method (SMS/MMS/e-mail), and list of topics of interest. Two types of LBS subscriptions are considered, one based on “current location” at any given moment, and the other, linked to a fixed “landmark” specified by the user. (It may be noted that the non-location based subscriptions are also possible, but are not considered of interest for the purpose of this discussion).

We first describe the LBS delivery process in case of a current-location based subscription. The user sends a SIP subscription request, which is routed by the S-CSCF (based on the IMS user profile retrieved from the HSS) to the PSC. The PSC sends the request to the ILS to locate the user and, once it receives the BAPE of the user, it creates a current-location-based subscription. As publishers publish the content over various topic “channels”, the PSC receives notifications based on its ongoing subscriptions. If the location/related information matches the current position to which the subscription is linked, the PSC will instruct the CDC to adapt the content to the subscriber's terminal's capabilities and deliver it via a preferred delivery method (SMS, MMS or e-mail). To take into account the user movements, the PSC can periodically query the ILS about the location, or, the ILS can periodically send location-push to the PSC, containing the new BAPE of the user. Due to scalability reasons, however, the frequency of such position updates must remain relatively low, say, refreshed no more than once every few minues.

In the case of a landmark-based subscription, it is assumed that the subscriber has a previously defined list of landmarks and that they are stored in the user profile and downloaded to Context Enabler during IMS registration. The PSC compares the location of the landmark specified in the subscription to that of the published location-related content. If the locations match, the CDC delivers the (adapted) content to the subscriber.

8. EXAMPLE

John, an IMS user, follows a routine on a typical working day: he leaves home to go to work in the morning, then in late afternoon on the way home he stops to eat or shop for groceries. During the day he either walks, or takes the tram, or drives the car to reach the target destination. John also owns a nice cottage in a fishing village at the coast, where, weather permitting, he likes to spend weekends. The location based service portal has a graphical user interface which displays an interactive city map, with some pre-defined areas (city's boroughs) and local landmarks. The location-related content offered includes various tourist information (pubs, restaurants, hotels), current weather, and current traffic conditions, provided by the national tourist association, the weather service, and the traffic information centre, respectively. In addition to predefined landmarks, John's personal landmarks include “Home”, “Work”, “Recreation”, and “Cottage”. Each landmark is assigned a position in the form of geographic coordinates and the landmarks can further be used for specifying landmark-based subscriptions (See Figure 12). John's user data, service data, IMS terminal capabilities, and various user preferences and service subscriptions are stored in the HSS, in his user profile. His preferred delivery method for all LBS is MMS (containing the map with info-elements overlay).

Figure 12. Landmark declaration.

8.1. Scenario 1

John is driving to the office in the morning. Remembering that there is road construction work going on at one section along his usual route, he wants to know the traffic conditions, preferably before he reaches that point. By using his mobile phone, he subscribes to traffic status in the part of town of interest, by selecting one or more districts from a list. He also selects MMS as a preferred delivery method. The PSC is subscribed to the current traffic information provider and once the content is published, the PSC initiates the delivery of a traffic report to all subscribers with a matching subscription. In the course of delivery, the CDC receives the content and checks John's preferred delivery method from his profile, finds out it is MMS, and sends the traffic info as an MMS to John's mobile phone. The MMS content shows congested streets around the road construction site (Figure 13 (Left)), and John decides to take an alternative route to the office. (Note that the Figure 13 illustrations are not actual screenshots, they are simply constructed to indicate what the user interface might look like).

Figure 13. Information delivered. (Left) Scenario 1. Traffic congestion; (Centre) Scenario 2. Nearby Pubs; (Right) Scenario 3. Weather at cottage.

8.2. Scenario 2

John finishes his work for the day and decides to walk to one of his favourite nearby pubs, only to find it closed due to a private party. He decides to look for another pub “close to” his current location. He subscribes to the location-related content under the topic “pubs” within the tourist info section, by using a current-location-based subscription type. For this type of subscription, according to his preferences, “current location” means “within an approximately 500-metre radius from current position.” The PSC retrieves John's location from the ILS. It also retreives a list of pubs from the local tourist association, filters it based on distance from John's current location and initiates the delivery of the result via CDC. The CDC receives the content from PSC, reads John's preferences stored in his user profile and sends the map with pubs marked via MMS to John (Figure 13 (Centre)).

8.3. Scenario 3

The weekend is approaching and John considers spending it in his cottage at the coast. The critical issue, though, is the weather, since the heating system in the cottage is rather basic. John accesses the LBS weather service and subscribes to the location-related content (weather forecast) with a landmark-based subscription. John selects “Cottage” as a landmark at which he wishes to receive weather information, and submits his subscription to the PSC. Once the weather information is refreshed, the PSC compares the location with the specified landmark's position, and sends the weather report to the CDC to deliver it to John (Figure 13 (Right)).

9. CONCLUSION

Location-based services are very complex, involving various inputs and a special information evolution process. Only a generic and detailed description of location-related evolution process offers the identification of proper LBS functionalities and the architecture in support of LBS provisioning. This article provides the most generic description of location-related information evolution within the LBS, allowing for further research in identification of LBS functionalities and architecture components identification. Additionally, this article presents a case-study which utilises the IMS as one of the latest telecommunication technologies, with the aim of attracting the interest for utilisation of telecommunication networks in navigation-related solutions. Presented ELRM and findings related to LBS information evolution will be explored in further research in design and development of navigation systems and solutions that utilise telecommunication networks.

ACKNOWLEDGMENT

The authors acknowledge the support of research projects “New Architectures and Protocols in Converged Telecommunication Networks” (071-362027-2329) and “Content Delivery and Mobility of Users and Services in New Generation Networks” (036-0362027-1639) funded by the Ministry of Science, Education and Sports of the Republic of Croatia, and projects A-STORM and FAME of Ericsson Nikola Tesla, Croatia.

References

REFERENCES

Beatty, C. (2002). Location-Based Services: Navigation for the Masses, At Last! The Journal of Navigation, 55: 241248.CrossRefGoogle Scholar
Camarillo, G., and Garcia-Martin, M. (2004). The 3G IP Multimedia Subsystem: Merging the Internet and the Cellular Worlds. John Wiley & Sons.CrossRefGoogle Scholar
Devlic, A., Jezic, G. (2005). Location-Dependent Information Services using User Profile Matching”. Proc. of ConTEL 2005 Conference, pp 327335. Zagreb, Croatia.Google Scholar
Erle, S., Gibson, R., Walsh, J.. (2005). Mapping Hacks: Tips & Tools for Electronic Cartography. O'Reilly, Sebastopol, CA.Google Scholar
Filjar, R., Busic, L.. (2007). Enhanced LBS Reference Model. Proc. of NAV07 Conference (on CD), 8 pages. Westminster, London, UK.Google Scholar
Filjar, R, Dešić, S., Tržec, K.. (2004). LBS Reference Model. Proc. of NAV04 Conference (on CD), 8 pages. Westminster, London, UK.Google Scholar
Filjar, R. (2003). Satellite Positioning as the Foundation of LBS Development. Revista del Instituto de Navegación de España, 19: 420.Google Scholar
Gourraud, C. (2007). Using IMS as a Service Framework. IEEE Vehicular Technology Mag, 2(1): 411.CrossRefGoogle Scholar
Mosmondor, M., Skorin-Kapov, L., Filjar, R., Matijasevic, M.. (2006). Conveying and Handling Location Information in the IP Multimedia Subsystem. Journal of Communications Software and Systems, 2: 313322.CrossRefGoogle Scholar
Podnar, I., Lovrek, I. (2004). Supporting Mobility with Persistent Notifications in Publish/Subscribe Systems. Proc. of the 26th International Conference on Software Engineering, 3 rdInt. Workshop on Distributed Event-Based Systems, pp 8085. Edinburgh, Scotland, UK.CrossRefGoogle Scholar
Pottebaum, T., Torchia, M.. (2006). Moving from Enterprise Location Data to Location Intelligence. Directions Magazine , (available at: http://tinyurl.com/3xy4ml, accessed on 23 January, 2008).Google Scholar
Skorin-Kapov, S., Mosmondor, M., Dobrijevic, O. and Matijasevic, M. (2007), Application-Level QoS Negotiation and Signaling for Advanced Multimedia Services in the IMS. IEEE Communications Magazine, 45(7): 108116.CrossRefGoogle Scholar
Tookey, B. R. (2007). What Are the Drivers We See that Makes Us Believe Location Intelligence is Ripe for Exploitation in Our Business. Proc. of NAV07 Conference (on CD), 8 pages. Westminster, London, UK.Google Scholar
Waller, A, Lewis, J., Jones, G.Craddock, R.. (2007). Secure Situation Awareness using Web Based Mashups. Proc. of NAV07 Conference (on CD), 8 pages. Westminster, London, UK.Google Scholar
Figure 0

Figure 1. Various location landscape thematic layers.

Figure 1

Figure 2. An example of location landscape created around the small community of Baška, Krk Island, Croatia.

Figure 2

Figure 3. Enhanced LBS Reference Model (ELRM).

Figure 3

Figure 4. Information evolution in ELRM.

Figure 4

Figure 5. General functional description of a location based service.

Figure 5

Figure 6. Simplified view of the IMS architecture.

Figure 6

Figure 7. Composition of services in IMS.

Figure 7

Figure 8. System architecture.

Figure 8

Figure 9. Publish-subscribe service.

Figure 9

Figure 10. Topic-based subscription.

Figure 10

Figure 11. Content-based subscription.

Figure 11

Figure 12. Landmark declaration.

Figure 12

Figure 13. Information delivered. (Left) Scenario 1. Traffic congestion; (Centre) Scenario 2. Nearby Pubs; (Right) Scenario 3. Weather at cottage.