An Innovative Gateway for Indoor Positioning

Enabling the pervasive paradigm requires the incorporation of location information. Retrieving location data has been a ﬁeld of ongoing research for both the outdoor and indoor wireless systems. The results in the cellular scenario are already mature and location architectures have been standardized. Recent research is ongoing for indoor-positioning mechanisms, resulting in implementations that vary. A platform that enables the deployment of location-based services in heterogeneous indoor and WLAN-based communication systems will address di ﬃ culties in cooperating with di ﬀ erent positioning systems. For that purpose, we have designed a novel entity, called Gateway WLAN Location Center (GWLC), which hides the heterogeneous functions of the indoor positioning architectures, incorporating a uniﬁed framework for retrieving location data of users and objects. The GWLC platform has been designed to meet objectives such as modularity, scalability, as well as portability, and to facilitate open interfaces. In this contribution, we elaborate on the design principles and the functionality of GWLC. We also provide performance results, obtained through real experiments.


INTRODUCTION
During the last years, cellular operators, service and content providers have been trying to identify the needs of a fully connected user, facilitating pervasive communications and ubiquitous computing concepts. The most promising direction seems to be the development of context-aware applications. These applications are based on the contextual information of a mobile or nomadic user and they can lead to highly customized personal communications. The location of a user is the most important attribute of the contextual information. Thus it is expected that services provided to the users, which are based on his/her location, will exhibit high market penetration, worldwide. Examples of location-based services (LBS) are (i) emergency services as defined by the E911 and the E112 recommendations in North America and EC countries, respectively [1,2]; (ii) point of interest (POIs), such as finding location and proximity services; (iii) navigation and routing; (iv) geocoding and reverse geocoding.
In order to support such applications, cellular operators and organizations offering wireless access have to use location-tracking mechanisms and deploy specialized platforms, which will execute the logic to provide LBS services. Until now, these platforms were highly customized for peculiar and specific applications, and, as a result, the deployment of LBS has been evolving at a slow pace. In order to accelerate the LBS deployment, the network operators incorporated open interfaces to service providers. The Open Service Access/Parlay (OSA/Parlay) [1] is considered as the most promised open interface. Third parties, such as service and content providers that reside outside the mobile or wireless infrastructure, can take advantage of the OSA/Parlay gateways to access information elements, or even services, from the cellular or the wireless network. For the deployment of LBS services, the 3rd Generation Partnership Project (3GPP) has specified a standard configuration of service entities in the GSM/GPRS and UMTS public land mobile network (PLMN) [3]. The 3GPP initiative has defined the Gateway Mobile Location Center (GMLC) [3] by a PLMN entity that an external location application accesses to retrieve the location information of mobile subscribers. Although the introduction of the OSA interface and the facilitation of specialized gateways are key steps to accelerate the LBS deployment, the current solution for providing location services is bound to peculiarities and specific 2 EURASIP Journal on Applied Signal Processing application's semantics. The PoLoS middleware platform 1 specified and deployed a gateway that caters for the uniformly provisioning and the delivery of LBS services [4]. For providing LBS services over heterogeneous location-tracking systems, the PoLoS platform incorporates a positioning component (POS), generic enough to communicate with different types of network infrastructures [5]. The POS component interoperates with cellular networks (e.g., GSM, UMTS) and wireless LANs (e.g., IEEE 802.11) to retrieve the location information of a user or object. In the case of cellular networks, the entity that provides the location information is the standardized GMLC. On the other hand, for indoor and local areas, there is no such standardised entity. However, during the last years the research for indoor-positioning mechanisms is growing, whilst indoor positioning prototypes and commercial products have been made available. Beyond a limited number of positioning mechanisms that rely on the wireless data infrastructures, the majority of the mechanisms require specific hardware and software to be deployed. To provide a platform that hides the different location-tracking methodologies and architectures of the indoor and local area scenario, we propose a novel platform, the Gateway WLAN Location Center (GWLC). GWLC integrates different positioning methodologies, giving to middleware and locationbrokering entities a uniform interface capable of obtaining location information of users and assets. Additionally, GWLC incorporates service discovery logic, providing means to exploit the LBS and context-aware services that are offered in indoor environments, to configure end devices automatically and to register for LBS usage.
This contribution describes our ongoing research for the design and the development of the GWLC entity and is structured as follows. In Section 2 we discuss the different mechanisms used for positioning in indoor environments. We provide a brief categorization of these location mechanisms, which will reveal the need for a unified framework that provides LBS services. In Section 3 we introduce the characteristics of the GWLC entity, and in Section 4 we define its design objectives. The architecture of the novel GWLC entity and its modular design is presented in Section 5. The publishing and automatic configuration capabilities of the GWLC are illustrated in Section 6. Subsequently, in Section 7, we present performance assessment results. Finally, we summarize the advantages and possible enhancements that might be applied to the GWLC platform.

POSITIONING TECHNOLOGIES IN INDOOR WIRELESS NETWORKS
During the last years, considerable research effort has been carried out for the design and development of indoor location techniques that estimate the position of a static (e.g., a printer that may sparely change position) or moving (e.g., a nomadic user) object. Indoor areas have the disadvantage of absorbing and diffusing the radio waves of cellular systems like the GSM. This introduces difficulties to use positioning mechanisms that apply to cellular networks (i.e., time of arrival, observed time reference, angle of arrival, A-GPS etc.) in order to provide location information inside buildings. Even though, the provided accuracy might not be useful for the applications envisioned in the indoor service provisioning paradigm. Thus, indoor-positioning mechanisms should provide the accuracy required by the context-aware applications that will be deployed in local and indoor areas. Several indoor location-tracking systems have been proposed in the literature, or already exist as prototypes or even commercial products. Hightower and Borriello provide a comprehensive survey of location systems for ubiquitous computing in [6]. Additional resources for location systems can be found in [7].
There are three main techniques that can be used to provide this information: triangulation, scene analysis, and proximity [6]. These techniques can be used either on their own or jointly. The latter case can further enhance the accuracy and precision of the positioning method.
Triangulation is a technique that uses the geometric properties of triangles to compute objects' location. There are two triangulation approaches. (ii) Angulation uses angles measurements for determining the position of an object.
The scene analysis technique uses features of a scene observed by a reference point in order to draw conclusions about the location of the observer or of objects in the scene. It usually requires a database of signal measurements that is used from the positioning system for location estimation.
Finally, proximity determines when an object is "near" a known location. The object's presence is sensed using a physical phenomenon with limited range. Proximity sensing can be done through: (i) physical contact through pressure sensors, touch sensors, and capacitive field detectors; (ii) Monitoring wireless cellular access points for determining when an object is in their range; (iii) observing automatic ID systems, through the proximity of systems like credit card point-of-sales terminals, computer login histories, landline telephone records, and so forth.
The information concerning the location of an object can be either physical or symbolic. Physical location is expressed as a mathematic magnitude like, for example, our building is positioned at 38 0 14 49 N by 23 0 31 94 W, at a 10.5-meter 3 elevation. The symbolic position information encompasses abstract ideas for the position of an object, for example, in the office, in Athens. Another classification of the location information supported by the positioning systems is whether this information is absolute or relative. The absolute information for the object that is tracked is the same and unique for all the observers; it refers to the same grid or a Cartesian system. The relative position information represents the position in reference to the observer, and, thus, it is not unique and not the same for all the observers.
Positioning systems can be divided into two primary categories. The first category includes the systems that use a specialized infrastructure, apart from the one that is used for wireless data communication purposes. This infrastructure is specifically deployed to provide location information. The second category includes the systems that are relying on the wireless communication network to infer the position of an object. The first category includes systems like the following.
(i) Active Badge which a proximity system that uses infrared emissions emitted by small infrared badges, and carried by objects of interest. A centralised server receives the emitted signals and provides the location information [6,8]. (ii) Active Bat system which resembles the Active Badge using an ultrasound time-of-flight lateration technique for higher accuracy [6,8]. (iii) MIT's Cricket system which relies on beacons, which transmit an RF signal and an ultrasound wave, and on receivers attached to the objects. A receiver estimates its position by listening to the emissions of the beacons and finding out the nearest one [9]. (iv) SpotON which is a location technology based on measuring RF signal strength emitted by RF tags on the objects of interest and perceived by RF base stations [10]. (v) Pseudolites which are devices emulating the operation of the GPS satellites constellation, and positioned inside buildings [11]. (vi) Pinpoint 3D-iD which is a commercial system that uses the time-of-flight lateration technique for RF signals emitted and received by proprietary hardware [12]. (vii) MSR Easy Living which uses computer vision to recognize and locate the objects in a 3D environment [8]. (viii) MotionStar magnetic tracker which incorporates electromagnetic sensing techniques to provide position tracking [8]. (ix) Smart Floor which utilizes pressure sensors to capture footfalls in order to track the position of pedestrians [8]. (x) Ultra-wideband technology systems, such as PulsON, a time-of-flight ultra-wideband technology [13], and the wide-band time-of-flight location mechanisms, which are proposed in [14,15].
The second category includes the following systems.
(i) MSR RADAR system which uses both scene analysis and triangulation based on the received signal's attenuation [16]. (ii) Nibble which uses scene analysis to estimate the location of the user that requests location information and which provides to him/her symbolic and absolute positioning information [17,18]. (iii) Ekahau's Positioning Engine which is a commercial product that combines Bayesian networks, stochastic complexity and on-line competitive learning, to provide, through a central location server, its clients with positioning information [19].
The main advantage of systems that belong to the first category is the high accuracy that they support when estimating the position of an object. However, the disadvantage is that they require additional equipment to be carried by the located object, which, in most cases, is small and economic. Moreover, a main drawback is associated with the deployment, operation, and maintenance costs of a second, location-specific infrastructure, which runs in parallel to the wireless communication infrastructure. The GWLC platform integrates systems of the second category, although, as it will be shown in Section 5, any location mechanism can be easily added to the platform.

THE GWLC PLATFORM
To provide a unified framework for the indoor location scenario, it is essential to integrate the different location systems into a generic platform. Such an innovative platform will hide the heterogeneity of the indoor location systems. For these reasons, we have designed a novel gateway, which provides position information of objects transparently to the different indoor-positioning mechanisms. This idea resembles the architecture that has been standardized for cellular systems. The 3GPP specify that the GMLC entity will be responsible for providing location information of subscribers that have been registered to the PLMN network and have agreed to permit their location tracking. GMLC can be accessed through a standardized OSA/Parlay interface, which permits an LBS service (client) that is running outside the PLMN to request the delivery of predefined location-positioning functions. The request-response (RR) function is the simplest; the GMLC entity returns to the requesting LBS client the position of a user. The periodic request (PR) function registers a request to the GMLC entity for periodic forwarding of a user's position. Finally, the event-driven request (ER) registers a request to the GMLC, which responds to indicate that a subscriber has entered to (or departed from) a predefined geographical area. These types of requests are incorporated with specific attributes, such as accuracy, time to respond, and priority.
The existing features of the GMLC entity are used as a basis for the design objectives of the GWLC entity. As in the GMLC case, the designed GWLC entity receives and  manipulates the location requests arrived from LBS clients, such as third-party service providers (i.e., the PoLoS platform). The GWLC entity provides the location information of WLAN or indoor, nomadic, users that have been registered to the WLAN network and have decided to permit their location tracking. GWLC implement an OSA-based interface between the LBS client, as well. In Figure 1 we depict the proposed architecture and the potential entities that cooperate with the GWLC to provide indoor, WLAN-based, location tracking. As an external client paradigm, we illustrate the Po-LoS platform. The PoLoS platform acts as a middleware for location brokerage over various location-tracking systems, such as fixed, wireless, and satellite systems. It receives location requests and returns the results through three interfaces: an HTTP interface for any type of client (i.e., cellular phone, PDA, or a content provider), an SMS interface for cellular phones, and a WAP interface for cellular phones incorporating microbrowser. The PoLoS Kernel component is responsible for orchestrating the operation of the platform. The GIS component imports the required POI, and geolocation or mapping services, according to the semantics of the location request. Such information enriches the corresponding response. When location tracking is requested, the positioning component (POS) is invoked. This component interacts with the various underlying infrastructures to retrieve location information. It incorporates various wrappers to handle the communication between PoLoS and the underlying network or tracking service. In the context of PoLoS, three types of wrappers have been defined. The GIS wrapper retrieves location information from the GPS repository, which is filled with location data from GPS capable clients. The GMLC wrapper is responsible for communicating with the GMLC entity of the cellular network (GSM, GPRS, UMTS). The communication relies on an OSA/Parlay interface. Finally, the GWLC wrapper is used for communicating with the GWLC entity to obtain location data form indoor and WLAN location-tracking systems. A detailed description of the PoLoS platform is provided in [20].

GWLC DESIGN OBJECTIVES
The design of the GWLC platform is based on a modular, object-oriented approach. The development is based on state-of-the-art tools, which are provided by the various Java frameworks, and especially the Java 2 Enterprise Edition (J2EE) [21,22]. The GWLC platform was designed to fulfil: (i) modularity: GWLC adopts a fully modular architecture (see Section 5) where each one of the components illustrates a discrete, well-defined functionality; (ii) extensibility that stems out from the modular design, which allows new location mechanisms to be integrated easily to the platform. Moreover, the platform allows the addition of mission-oriented components in future releases, such as customer records' objects and LDAP dictionaries; (iii) efficiency, in terms of concurrent sessions that can be supported by the platform, by integrating loadbalancing mechanisms and clustering capabilities (e.g., server farm), as provided by the J2EE framework; (iv) independency from the underlying networking systems that are used for providing indoor location, the various positioning techniques, and the capabilities of user's terminal equipment; (v) portability between contexts, illustrating different characteristics and architectures (e.g., Windows, Linux), due to the use of the Java language;  (vii) QoS orientation through the incorporation of qualityof-service (QoS) techniques during the scheduling of the requests according to priority levels and response time requirements, and at the selection of the appropriate location system; (viii) reliability: taking advance of the clustering characteristics of the J2EE framework.
The QoS capabilities and the management interface are to be further elaborated in conjunction to the authentication and security mechanisms, which are based on the Java Authentication and Authorization Service (JAAS) framework [24]. The majority of the aforementioned features results from the capabilities provided by the Java language and the J2EE development framework. Thus, efficiency is supported through the clustering capabilities of the J2EE framework. GWLC is actually a middleware component that provides its functions as Web services. It follows the 3-tier architecture paradigm, to discriminate data manipulation (database), presentation, and processing layers. This feature supports the requirements for availability and efficiency. Furthermore, it was designed to offer services running in any operating system, requiring the minimum reconfiguration effort during context switching. Java allows for portability of the application to various platforms, like Windows or Unix flavoured systems.

GWLC ARCHITECTURE
In this Section, we describe the details of each of the GWLC components. Figure 2 illustrates the architecture of the GWLC platform.

Communication interfaces
Through this interface, the platform receives location requests, associated with a list of requirement attributes, and sends the results to the requesting clients (e.g., the PoLoS platform). We have used open and standardized interfaces, such as the OSA/Parlay's and the LIF's MLP protocol. However, proprietary legacy interfaces can be easily integrated as communication subsystems in the GWLC platform.

Dispatcher
Dispatcher's task is to receive the requests from the communication interfaces and to parse them, in order to determine the semantic and syntactic correctness. It assigns a unique identifier to each incoming request, which is used throughout the GWLC platform. It determines the scheduler's queue that should forward each incoming request, based on the attributes that are associated with it. In the opposite direction, the dispatcher retrieves the location information from the Kernel and forwards this information to the appropriate communication interface module as a location respond. The dispatcher maintains a table that associates pending requests, identifications, and the communication interfaces that these requests originated. Dispatcher is the first module where authentication and access restrictions are taken under consideration when a service request is captured.

Requests schedulers
Each type of request (i.e., RR, ER, PR) is processed by a discrete scheduler, which is responsible to handle priority 6 EURASIP Journal on Applied Signal Processing queues and to schedule the requests based on their QoS constraints. The scheduled requests are forwarded to the Kernel of the platform. The RR scheduler follows the FIFO discipline, but in future versions QoS-based disciplines, such as the weighted round robin (WRR) disciple [25], will be used to cope with priority levels or response delays. The ER and PR schedulers use timers to trigger the scheduling of the events, according to the requested periodicity. The ER scheduler incorporates advanced characteristics to prevent flooding of the underlying WLANs with location requests. In future releases, the ER scheduler will drop periodic location requests that concern a user illustrating low mobility.

Router and capabilities broker
The router and capabilities broker component determines the positioning system that is appropriate to serve a specific location request. GWLC might be deployed in an environment where various types of positioning technologies might coexist (e.g., Nibble and Ekahau might coexist on the same WLAN), offering different levels of service, in terms of accuracy, precision, reliability, time to respond, and first time to fix. To determine the appropriate positioning system, the router and capability broker takes into account the users' terminal equipment, as well. Moreover semantics such as location computation costs, the coverage of the geographical area, and the communication overhead of positioning information are taken under consideration [6]. Furthermore, as indicated in Section 2, some systems support physical coordinates, whilst other might provide symbolic locations. The router and capability broker based on the location requests' semantics identifies the appropriate location system for handling the incoming request and passes this information to the Kernel component.

Users DB
This database stores information related with the users that are registered on the platform. Each user is assigned a unique identifier, whilst the time of the registration is stored, as well. Users are classified as occasional (e.g., visitors) or permanent users (e.g., working stuff). Users DB records are valuable for accounting and charging purposes, including post and pre-paid options. Additionally, these records are useful when the platform informs end-users about the available location services (publish module), since, for example, the navigation service might be critical for a visitor, but not for a resident.

Service publish and configuration module
This module advertises the deployed location services. It manipulates the service discovery and the service configuration for end-users, which is performed transparently and with the minimum human intervention. We further describe the mechanisms used by this module at Section 6.

Authentication and security module
The authentication and the security policies that apply to the GWLC platform are enforced from this module. It utilizes the JAAS security framework, and it provides authentication and security services to other modules of the platform [24].

Security database
This database holds all the required information that enables the authentication and security module to enforce the security policy that governs the GWLC platform. Typical records of this database include access permission rights, authentication tokens or key certificates, and lists of permitted operations and services for each user (permanent or occasional).

Location cache
To minimize location-signalling overheads and to avoid power consumption phenomena on the end-user equipment, we have introduced the location cache. This cache keeps the location information of the recently tracked users and objects. Moreover, several WLAN-based location systems, such as the Nibble, introduce a predefined refresh period, which imposes lower bounds on the response delay requirement. Storing location data in this cache, the GWLC platform avoids delay limitations, introducing different levels of response thresholds, applicable to location request that require fast position resolution with medium location accuracy.

Positioning mechanisms
In a typical indoor environment, multiple positioning systems might be available at the same time. Thus, GWLC provides functionality to import/export a position mechanism as a discrete module. Additionally, GWLC incorporates the logic to decide which one of the candidate position mechanisms fits better for processing a particular request, according to semantics such as accuracy, response time, and communication costs. The WLAN positioning mechanisms are classified as centralized (e.g., Ekahau's Positioning Engine), decentralized (e.g., Nibble), and dual-mode (e.g., MSR Radar). The platform integrates these types of WLAN-based mechanisms. Modules that implement other mechanisms can be integrated to the platform, enhancing its capabilities and providing a generic functionality to different LBS semantics.

Kernel
The Kernel is the centric entity of the GWLC platform. It incorporates all the logic required to orchestrate the other components. Kernel receives requests for service execution from the schedulers. It is the only module that is permitted to re-insert a request in schedulers' queues or to delete a PR or ER request from the corresponding queues, when a message to abandon the periodic or event-driven reports arrives. It activates the appropriate positioning module to serve a particular request, based on information obtained from the router. Finally, upon receiving the location data from the positioning module, it builds a corresponding response and forwards this to the dispatcher, in order to be returned to the corresponding requestor.
To describe the life cycle of a location request within the GWLC platform, assume that a location request appears at the appropriate communication interface (e.g., the OSA interface). The service context and the attributes of the request are retrieved and validated. Then the request is forwarded to the dispatcher. This module assigns a unique ID that will be used for any future reference. The request is, then, pushed into the appropriate scheduler for scheduling. For instance, if the request is an RR, the RR scheduler is invoked. According to the request's priority attributes, the Kernel receives the request and proceeds to service execution. The Kernel consults the router and capabilities broker, which selects the positioning mechanism that will be used to handle the request and retrieve the location information. Once the positioning mechanism returns the positioning information, the Kernel forwards the result to the dispatcher. The dispatcher consults the tables maintaining the requests' IDs, and according to the stored information, it decides the communication interface that the response will be forwarded to.

SERVICE DISCOVERY AND CONFIGURATION
GWLC platform provides supplementary services. Those include publishing and advertising of the LBS services that the platform provides and mechanisms that dynamically configure end-user's equipment for communicating with the GWLC modules. The service publish and configuration module advertises the services that are offered to end-users using a mechanism that is based on the Jini framework provided by the Java language [26]. Thus, end-users will conveniently discover the context-aware application that they can use. Every user that enters the WLAN area receives a notification message that advertises the existence of positioning capabilities within the WLAN domain. The user has the choice to register in GWLC, enabling his/her tracking, or to decline this opportunity. Other candidate systems to carry out the service advertisement process include the Service Location Protocol (SLP) and the Universal Plug and Play (UPnP) protocol [27,28]. An important aspect of the GWLC is the effortless reconfiguration of the end-users' equipment, performed in an automatic and transparent fashion by the service publish and configuration module. Using mechanisms, like the mobile execution environment (MExE), the module retrieves information for the terminal equipment capabilities [28]. Service configuration module forwards the required configuration files of the location system (e.g., Nibble client software), in a form that is compatible to the enddevice, as well as, application files. In this way, any file that is required for location tracking can be pushed to end terminals, enabling positioning mechanisms to be executed in a centralized or a decentralized fashion, without any human intervention.

Experiment setup
The performance assessment of the GWLC was carried out through a number of real experiments. In the first scenario (S1), we have used a nondedicated low-cost system (1.4GHz CPU, 512MB RAM), suitable for an organization with smallto-medium positioning requirements (e.g., limited number of users, such as a parcel delivery service provider that requires fleet management within the university campus). In the second scenario (S2), we have involved a dedicated system (3GHz CPU, 1GB RAM), representing a medium-cost solution for an organization with higher positioning requirements. Finally, a cluster of the aforementioned systems was used to represent a high-cost system (S1 + S2) for an operator that would need to track a high number of users.
Location requests were simulated through a request generator. This generator runs on a dedicated server and sends requests to the GWLC platform, or the two platforms in the case of the clustering configuration, through OSA-based interface. Each request retrieves from the GWLC the location data of one among ten different users that roam on the wireless network of the university campus. The wireless network consists of ten IEEE 802.11a/b access points, and each user's device is equipped with an IEEE 802.11 corresponding NIC. The location fingerprints of the nomadic users are captured through the Nibble location system [18]. Nibble is a standalone indoor location system. It uses a Bayesian network represented in XML format that is built and trained incrementally. Using signal strength measurements as input, obtained from the IEEE 802.11 NIC card, the current location is returned along with the probability of successful guess. During our experiments, we have measured the average response time, that is, the life-cycle of a location request. This period is defined as the time between the arrival of a location request to the communication interfaces and the formation of the corresponding response in the dispatcher module. Additionally, we have measured the percentage of failed requests, that is, the requests that failed to receive any location response.

Results
We assumed heavy-loaded scenarios, where several concurrent positioning requests arrive on GWLC. For the scenario S1, the GWLC is capable to service more than 450 concurrent requests with an average delay of less than 10 seconds, as Figure 3 illustrates. When 50% of these users request location information, the gateway responds with an average delay of less than 3 seconds. The gateway achieves low percentage of failed requests throughout the experiments. For less than 800 concurrent requests and for each of the three scenarios, the gateway served the total amount of concurrent requests, without any losses. Above this level, a small number of requests were lost, as Figure 4 illustrates. This is due to the limitations of the internal database of the J2EE container, which manipulates and assigns discrete identifications for each incoming request. When more than 800 concurrent requests Simultaneous clients S1 S2 S1 + S2 arrive, some fail to receive an assigned ID, and eventually become invalid and lost. This phenomenon increases the average service delay of valid requests, as well. However, even in the worst-case scenario (i.e., the scenario S1), the failed requests were less than 0.05%. For the purpose of the simulations, only the Nibble location engine was used, since this was the only freeware module. The Nibble, as an experimental engine, was designed to provide location accuracy, and it does not cope with the optimization of the location-request processing time. The average response delay is expected to be minimized when the location cache will incorporate location fusion techniques, as well as when commercial location systems will be integrated. In the latter case, the location broker will be more useful, since it will identify the positioning engine that fits better to serve a particular location request. Furthermore, since each location request might require discrete response times and scheduling priorities, the usage of enhanced scheduling disciplines, such as the WRR, will improve the service delay for the high-priority requests.

CONCLUSIONS
The GWLC platform is an innovative middleware entity that provides a unified interface and a generic brokerage service to access positioning services that are offered by wireless location-tracking systems. The GWLC hides the heterogeneity and the peculiarities of various WLAN-based location architectures since it is able to integrate different commercial or prototype positioning systems. In this contribution, we have described the design objectives, the architecture, the functional characteristics, and the services that the GWLC offers to external LBS services, such as location information clients and content providers or aggregators. The GWLC platform is based on state-of-the-art development tools and is developed on a modular fashion that adds portability, flexibility, and efficiency. Using open and standardized interfaces (OSA/Parlay, LIF's MLP), the platform provides an Simultaneous clients S1 S2 S1 + S2 open framework for location data retrieval. Enhanced features of the platform deal with the capability to handle different quality levels associated with the location requests, the enforcement of authentication and security policies, and the brokering efficiency to route requests based on underlying positioning capabilities and on location request's semantics. An advanced feature of the platform is the service publishing and discovery module. Service discovery enable end-users to identify the LBS services offered by the GWLC, whilst reconfigurability options allow the automatic configuration of end-users equipment for accessing and supporting the location services. The results of the experiments illustrate that the performance of the gateway satisfies the qualification criteria. Based on the fact that each commercial WLAN access point can serve, in practice, at most 60 concurrent users, the GWLC platform manages to serve up to 13 WLAN cells, without dropping any of the received location requests.