RTLS
1
Real Time Location System using WiFi Tim Denis1 , Maarten Weyn2 , Koen Williame3 , Frederik Schrooyen4 1
[email protected] 2
[email protected] 3
[email protected] 4
[email protected]
May 31, 2006 Abstract— Using WiFi it is possible to determine the exact location of people or assets with accuracy up to 1 meter. We use the Real Time Location System (RTLS) from Ekahau to build our own healthcare application, which monitors and logs the movement of patients, with the possibility to receive alerts in alarm situations.
I. INTRODUCTION RTLS can be implemented in almost all situations where location tracking is needed. Today it is being tested and used in different sectors. One of them is the healthcare sector where they can track patients, staff and assets like medical equipment. In this way, emergency response can be more efficient and faster. RTLS provides also increased patient safety, increased throughput, better staff utilization, reduced need for inventory, improved workflow, reduced errors and improved revenue capture. Other places where RTLS is implemented are supply chain management, distribution centres, tracking of staff and visitors in buildings, etc. Our goal was to create a RTLS application based on an existing technology for a healthcare centre to secure quality of care of the patients. II. RTLS OVERVIEW Real Time Location Systems are fully automated systems that continually monitor the locations of assets and people. The first RTLS systems generally used the unlicensed spectrum (408, 433, 900 MHz, etc) for tag-to-reader air interface. This technology required additional reader hardware infrastructure to communicate. Because of the ratification and subsequent success of IEEE 802.11, a new group of systems emerged. This tag-to-access point air interface can communicate with the 802.11 access points (AP) directly. There are three major technological concepts, which divide RTLS to determine the location of a client: • Nearest Access Point • Time Difference on Arrival (TDoA) • Received Signal Strength Indicator The first, Nearest Access Point is used for environments where detecting the presence of an asset within a set area (or lack thereof) is critical, a single Access Point or Location Receiver can detect tags and WiFi devices. Examples include automated inventory counts, and sorting cars on a lot by the ”zone” in which they are located. The second is called Time Difference on Arrival. This method relies on the time a packet needs to be sent from a transmitting device
towards a receiving device. Using WiFi this means that the client sends out a time stamped signal, which is received by the access points. Knowing the time difference, the distance between the AP and the client can be calculated. In a system with at least three visible access points, it becomes possible to estimate the location of the client. The third technology is called Received Signal Strength Indicator; here the client device measures the signal strength of the access points and sends the values to a server. On the server, the location of the client can be calculated if at least three values can be measured. RSSI performs better in indoor walled environments (e.g. hospitals, warehouses, distribution centres), while TDoA has advantages in unobstructed, outdoor environments (e.g. shipping/trucking yards, airplane-manufacturing hangars). TDoA suffers more from the multipath problem in an indoor environment caused by the reflection of signals on obstacles. This makes it difficult to distinguish the original correct signal from the reflected signals. With TDoA, the access points need to be specially designed to be able to measure the time difference. This makes TDoA a hardware based thus expensive solution where RSSI is a software based, hardware independent solution, where the software of the vendor is the only initial cost. Pairing the proper technology to the correct environment can lead to improved performance and reduced development costs. RSSI can be combined with fingerprinting; this is a technology where several positions are calibrated so the engine can refine its calculations with the triangulation. Another way to divide RTLS using WiFi access points is by checking if the technology really communicates using the WiFi protocol. The tags consume more power when using the IEEE 802.11 protocol than by using an own protocol with smaller power consumption (down to 20mW). The big RTLS vendors at the moment are AeroScout[1], Ekahau[2], PanGo Networks[3] and WhereNet[4]. •
AeroScout delivers an end-to-end product solution for most vertical market needing asset tracking solutions. For outdoor environments, AeroScout Engine 3.0 uses TDoA location determining technology. AeroScout has collaborated with Cisco to tackle the indoor multi path problem. The AeroScout Visibility System utilizes Time Difference of Arrival (TDoA) and Signal Strength (RSSI) algorithms to wirelessly determine
2
RTLS
•
•
•
the precise location of tags and WiFi devices. Another distinction AeroScout has over its 802.11 rivals is its ability to enable perimeter security and gating applications. AeroScout Exciter is a hardware component that allows active RFID tags to trigger events based on proximity. Ekahau offers a RSSI-fingerprinting based - stand-alone RTLS solution for asset and people tracking. The Ekahau Real-Time Location System is a wireless radio frequency solution that continually monitors and reports real-time locations of tracked resources. Unlike competing solutions, which are based on Time Difference on Arrival (TDoA) technology, Bluetooth or active RFID, and therefore require deployment of costly RFantennas or receivers, Ekahau’s patented RF modelling technology leverages standard WiFi access points, so no proprietary infrastructure is needed. By using standard 802.11 access points and WiFi tags, any WiFi network can now work as the backbone and sensor network for a real-time location system. This quickly translates into faster deployment and improved costeffectiveness. Ekahau claims that its technology is the frontrunner in accuracy. They implement software-only systems, which limit their ability to supply gating functionality used in many shipping/receiving or physical perimeter security applications. Built around a proprietary location determining technology, Ekahau Position Engine 3.1 provides a compelling implementation. It achieves as little as 1m accuracy variance compared with Cisco Location Engine, which can exceed 6 meters. The significant difference in accuracy effectively enables accurate item-level tracking versus room or zone-level tracking. PanGo Networks embraces the notion that campus-based location technologies will integrate across the IT infrastructure as a core enterprise application technology. PanGo is uniquely positioned to its competitors by separating the RTLS system and an application platform for back-end integration and application development. The PanOS Platform combines location technology, console management, device management and SDK with robust API’s for backend integration to third-party vendor or enterprise application integration. As an emerging middleware platform, PanOS Platform aims to server up location information to multiple enterprise applications and potentially across many RTLS technologies. WhereNet holds a leading position in the RTLS vendor space in terms of experience, deployments and name recognition. WhereNet offers the Visibility Server Software, which is a complete development tool set for application development and integration. WhereNet has developed WhereLAN which works with a proprietary TDoA protocol. The Locating Access Point can combine 802.11b WiFi compliant communication with their RTLS communication protocol. The WhereTag of WhereNet works on the 2,4GHz frequency using their custom protocol, which makes it possible to create an RTLS environment where the tags only use 2mW. III. MASTER PROJECT
to set up a system, so the practical details can be reviewed. When the details and possibilities are know, a profound study can be made on the system, which can be used in further projects, or can serve as guide for companies who are thinking about implementing an RTLS solution. B. Pilot project To be able to test in a real life environment, we contacted a health care institute. This institute was interested and offered us the opportunity to implement a RTLS system at their premises. This gave us the chance to work in a practical situation, and gather information in a real life environment. To make sure both parties could benefit the pilot project, the institute wanted us to create the system so it could fit in their infrastructure, and have a practical use. For this, several requirements were demanded of the system. C. Real time tracking One of the most important demands of the system is the real time aspect. It is necessary to be able to see the patients on a map. This feature is useful for several purposes, like safety reasons, have an idea how many people are in a certain area, or where a person is at a certain moment. Another possibility of the real time tracking system is to locate a person in need real fast on a map. The time gained here can possibly save lives. When a patient is getting confused, not knowing where he or she is at the moment, walking in the wrong direction, it is possible for the staff to locate this patient on the map, come to aid and bring the patient back to his or her room. D. Emergency system Knowing the exact location of a patient on a map when he is in need is of utmost importance. On the other hand, it has to be possible for the patient to raise an alarm when he or she is in need. This alarm is then passed to the staff, who can come to aid, knowing the exact location of the patient. To enable the patient to raise an alarm, the device he is carrying (tag) has an emergency button on it. When this button is pressed, the tag immediately transmits a signal, which is the alarm event. When the alarm event is raised, it can be displayed on a message board, possibly accompanied by a sound. However, this is not the only emergency that can occur. For instance, when a person leaves a certain area or building, this might be an alert too. On the other hand, when someone stays too long in a certain area or room, this might also be considered a case of emergency. E. History For research goals, it might be interesting to know how much a certain patient moves. Using a logging service, it is possible to fill a database with location data. This data can later be analysed. Using the data accumulated by this log, things like the degree of mobility from a patient can be determined. A person sitting in a wheelchair is likely to have a different degree of mobility than a patient who is able to walk all day. It can also be used to check if a patient moves enough in a certain period as instructed by his doctor. Another application of the logging service can be to review how much time a person or more persons spent in a certain area. This information can be used to improve the accommodation in an often-visited area, instead of areas where only few people are.
A. Goal
F. Other possible applications
The goal of this Master project is to research the area of Real Time Location systems using WiFi. It is important to know which possibilities are available, and how they can be used in a corporate environment. To be able to study these possibilities, it is necessary
Of course, there are a lot more valuable applications for this RTLS system. These applications can be implemented elsewhere, but are of no use for our specific test case. Some examples of these applications are:
RTLS •
•
•
3
Gain access to a building or room, without using keys or any other kind of lock. The doors can be automatically unlocked when a person with the right authorisation approaches the door. Allow certain services based on the location. The services can be internet access, or access to specific websites and so on. Capturing which halls or staircases are used most by the staff, to improve the environment by placing an elevator or taking other measures.
G. Used technology Before we started with our project, we investigated the available solutions in the area of RTLS. We came up with solutions in both technology disciplines that are used most. The third technology, nearest access point is left out because of the low accuracy. The solutions using TDoA had some advantages, but for our goals, the disadvantages were too numerous. One of the disadvantages is the higher cost of the hardware because of the more intelligent access points. In the RTLS scene, it is also commonly known that TDoA is a technology best used outdoor. A major example is the Global Positioning System (GPS). This is entirely based on the Time Difference on Arrival principle. The reason that TDOA is not so accurate indoors, is that it suffers from reflection. This means that the signals (and thus the packets containing the timestamps) may be delayed, which generates a decrease in accuracy. Opposite to this, the RSSI technology does not suffer from this reflection disadvantage. The communication used here is only to transmit the data, and not to measure some distances. It is also more convenient to use RSSI indoor, because the signal strength may decrease seriously passing an obstacle, like a wall or so. This creates an easy to measure difference between the locations, and so an accurate location can be determined. When RSSI is used outdoor, the difference in signal strength may be not sufficient to obtain a satisfactory accuracy. Considering these properties, advantages and disadvantages, we chose the RSSI technology to work with. Searching for the right solution, we found the Finnish Ekahau solution. Ekahau is a young company,
Fig. 1: Ekahau logo[5]
which concentrates on the RSSI technology. Their product is the Ekahau Software Engine, which is able to determine an accurate location up to 1 meter. H. Ekahau Software Solution The choice we made for the Ekahau solution had another big advantage at first sight. The Solution provided a Software Development Kit (SDK) in the Java environment. This provides a way to communicate with the software engine, so you can build your own application using the Ekahau Engine. This has the main advantage that the user application is only limited by the programmer’s imagination or the needs of the end user. Further, the development kit contains a set of three tags, which can be used as clients to track. It is also possible to communicate with your own application with the Ekahau Engine, using telnet. This feature makes it possible to use any programming language to build your own applications. We chose
this approach to be able to implement more features than the SDK provides and to have a better grip on the underlying communication process. The development language of choice was C] combined with Microsoft Visual Studio 2005 IDE[6]. The reasons we did this were the fast development, the ease with which server-related applications can be written, and the short learning process. Ekahau includes in its development kit several tools to test and make the user able to start implementing the solution. First, there is of course the engine, which runs on a (dedicated) server. To control and to ’learn’ the engine the fingerprinted[7] positions, there is the manager. This application, shown in figure 2, allows the user to
Fig. 2: Ekahau manager
load a map of the area into the engine. Then it allows the user to calibrate (fingerprint) using this map. Although this process is as easy as it is time-consuming, the results are quite satisfactory. A person carrying the tag stands on the place, which needs to be calibrated and initiates the calibration process on the engine. This process is very time-consuming, because every spot that needs to be calibrated takes about 10 seconds. It is obvious that with more calibrated spots, the accuracy will increase. The manager also provides means for setting the map scale. This scale is expressed in pixels per meter. The only thing the user has to do is drawing a line on the map, from which he knows the distance in meter. This way, the engine is able to determined distances between points. In the screenshot (figure 2), there is a list of areas visible. These areas are the so-called ’logical areas’. When the engine is tracing people, it produces several types of data. One of these is the logical area in which a person is located. This information is very useful in this pilot project, because it is more important to know in which room or area a patient is, then to know exactly how many meters he or she moved during the day. Other types of output information from the server are coordinates on the map. For each device, (tag or software client) an X and Y coordinate is calculated. The abscess of these coordinates is the upper left corner of the map. These coordinates are used to indicate a device on the map. The engine also provides information about the expected error. An estimation is made how far the engine expects to be wrong. How the engine calculates this information is not provided by Ekahau. Their Software engine is a commercial closed source application, so we do not have insight in the code or the mathematical algorithms that are used. All the information the Engine provides is available via telnet communication with the engine, and thus can be used in
4
RTLS
the custom software application. Using this solution, in a good environment (low interference, low levels of disturbing signals) accuracy from 1 to 3 meters can be obtained. For most applications, this is sufficient. The operational distance of the solution is about 100m in an open space. It is obvious that this range dramatically decreases in a building, but this is not necessarily a disadvantage, as mentioned above. When the used access points are placed in a smart way, the covered area is theoretically unlimited. The only requirement here is that at least three access points cover the operational area, and that one of these AP’s has a network connection to the Engine. This implies that it is possible to use ’Dummy-access points’. These access points do nothing but sending their signal, and do not require a network connection. I. Devices It is obvious that the system can only work when there is some sort of device that is carried by the person or asset that needs to be tracked. Ekahau standard delivers two options. The first option is a software client, which can be installed as a service on a windows platform. This makes it possible to let almost every device, which runs windows and is capable of WLAN networking, participate in the system. However, there are some difficulties with this system. Not every portable computer receives the same signal strengths, because of several reasons, like different construction, different place of the WiFi-antenna, different WLAN hardware, and different drivers. To overcome these difficulties, Ekahau has a list of supported hardware, which is tested for compatibility with their system. Ekahau provides drivers for different WiFi hardware, which can work with the Ekahau Engine. The system is tested and built with Cisco hardware in mind. The driver provides a correction between the specific hardware and the cisco reference hardware. That way, some sort of compliance is accomplished for all custom WiFi hardware. Of course, not all hardware is tested and certified by Ekahau, but the most popular types and brands are. For a complete list of hardware supported by Ekahau, please refer to Ekahau’s website.
Fig. 3: Ekahau tag
The second option that Ekahau provides is the use of WiFi-tags, as shown in figure 3. These tags are small devices, containing everything that is needed to communicate with the WLAN infrastructure, and measuring the signal strengths. One of the tags features is a red emergency button. When this button is pressed, the tag sends immediately its received signal strengths, and a signal indicating an emergency. The engine will then process this emergency signal, and a proper response (depending on the application) will start. One of the other features is a flashing led which indicates the status of the tag. It can indicate an empty battery, out of range or no communication with the server available. Of course, the tag contains a battery, which delivers the power to the tag. The time the battery lasts, depends on the use, and the configuration. The tag supports several modes in which it can run. There is the ’calibration-mode’, which forces the tag to transmit every 2 seconds the RSSI-information it collects. This
means that the tag will not go to suspend or sleep in this mode. Other configuration modes allow the tag to only transmit RSSI-information every ten minutes, or any other custom time interval. Finally, it is also possible to allow the tag only to transmit RSSI-information when it is in motion. This ability is made possible by implementing a motion detector in the tag. The battery of a tag provides power to the tag for approximate 16 hours, when it is intermediate configured. It is obvious that the battery consumption of the tag is directly related to the configuration. In the three examples mentioned above, the first is definitely the most power-consuming one. The second and the third example are less power-consuming, because of the fact that in this configuration, there is less communication with the server. Ekahau can also provide other kinds of tags, like tags with longer operation time (larger battery capacity) or tags in the shape of a wristwatch, so a person can easily wear them. The tags can be configured in several ways, for instance, the tag can be configured to make a sound when the button is pressed or not, settings for the time it takes before the device goes to standby, or the interval between two location data bursts are available. By tweaking these settings in a smart way, the tags can be optimised for each application. When a person or an asset, which moves only twice a day, carries the tag there is no point in having the tag sending location information every 30 seconds. In this case, it would be smarter to have the tag send data only when its motion detector indicates a movement. J. Requirements The Ekahau software is designed to run on a Windows platform. Further, a network infrastructure is needed, so communication can take place between the tags or clients and the software. The Ekahau solution is completely independent of hardware, so the choice of access points is completely free. We have chosen Linksys access points to work with, for their high fidelity, their big range, easy configuration and maintenance features. The configuration software Ekahau provides, -like the Manager and the Finder- are also designed to run on the Windows platform. The host in the network on which the Ekahau engine runs, is a Windows 2003 server. Besides running the solution, the other tasks are: • Run a DHCP server, so every host in the network can obtain an IP-address. • Run a Microsoft SQL Express server, which is a database engine. This database application is used by the log service to store all the gathered data. • Run the Log Service we wrote (see further) which provides the possibility to fill the database with location data, so that we are able to analyse the location data at another time. • Enabling VPN (Virtual Private Network) so control of and communication with the network are possible from external locations. Ekahau provides two software clients, one for a Windows PC and an other for a PocketPC running Windows Mobile 2003. As mentioned above, the tags are delivered with the development kit. The tags are embedded systems, of which we do not know much, except for their behaviour and configuration options. K. The network The way the network is built, is not different from any other TCP/IP network. Nevertheless, there are some extra rules that need to be followed, like the availability of three access points on each spot where tracking should be possible. This requirement is rather a practical matter (where to place the access points) then a network
RTLS
5
matter. The difficulty here is to make sure that the access points do not interfere with each other and while doing so would cancel out each other’s signal. For this, it is important to make sure that the channel space between the overlapping access points is four channels or more[8]. When this requirement is met, the system is operational. To have a more network related view to the system, it is important to consider the build-up of the network, and adapt this to the other applications using the network. The Ekahau solution is able to co-exist along with other applications on the network, like internet access, network sharing, VoIP and other network applications. L. Testing To make sure the solution was implemented properly, we did profound testing after each stage. The first tests were not always satisfying, but the results taught us what the best way is to implement the solution. Several sorts of tests were carried out during the pilot project to guarantee the good working and accurate location determination of the system: • After setting up the network, we ran tests to see if there is a network connection available at each desired spot.
The maximum accuracy obtained with the Ekahau Solution in optimal conditions is about 1 meter. This test is also a very important factor for the cost calculation (see further). IV. CUSTOM SOFTWARE A. Development Environment and Tools We chose to use C] and the .Net framework to develop our software because of Visual Studio, which is a full featured integrated development environment, the possibility to use Microsoft Windows platform dependent features (like windows services) and the high productivity. The toolset for developing besides Visual Studio 2005 Standard consisted of NUnit[9] an automated unit-testing framework, nPerf[10] a class performance comparison tool and nProf[11] a program instance profiling tool. Besides the .Net framework, the nPlot[12] library was used for all graphical needs. This library is an open-source project without commercial restraints. nPlot fulfilled all the diagram needs. B. Implementation In the next block diagram, you can see we chose to build a library (blocks with (1) on the diagram in figure 5) that handles all the trivial communication with the Ekahau platform. This library makes it easy
Fig. 5: Software diagram
Fig. 4: Measured signal strengths •
•
As a second test, often combined with the first test, we checked if there were at least three access points available at each point we wished to track (figure 4). If not, we adjusted the place of the access points until an optimal spreading was reached. This is a trial-and-error process, because it is very hard to predict what the influence of the environment (walls, elevators, windows, ...) is on the signal strength. This process gave us a good indication on the total time needed to implement the solution and make an accurate cost calculation. The information gathered here can be extrapolated to bigger areas or other environments. When the previous tests and adaptations were successful, we started calibrating a few points, distant from each other. When the system interpreted these few spots accurate, we moved on with calibrating, so the system became more and more accurate.
to write any future applications. At the core of the library, a method factory[13] resides. This factory returns an object that corresponds with a received text message from the Ekahau Server. This conversion is achieved by means of a parser[14]. Our first parser implementation was based on regular expressions[15] a well known widely used, very powerful and natively included in the .Net framework, pattern-matching language. However, during operation, we noticed a big performance impact when the connection was lost during a message-receive event. Tests that reproduced this situation showed us that the regular expression needed a lot of time when parsing incomplete messages (See figure 6). Thus, the need for a custom parser arose. As you can see in the following graph where the red dotted line shows the performance of the regular expression parser algorithm compared to our custom parser (the blue solid line), our custom parser outperforms the regular expression parser when parsing unfinished messages. Besides handling unfinished messages, the time to handle n-messages in loop and the time to handle
6
RTLS
Fig. 6: Parsing unfinished messages
Fig. 8: Parsing messages with different lengths
one message of variable length were examined. The results, in the following two graphs (figures 7 and 8), clearly show the increase in performance we gained by using our improved parser, presented by the blue solid line, compared to the regular expression parser, the red dotted line.
types of captured data to individual but normalized tables. For the database engine, Microsoft SQL-Express was chosen for its integration with the .Net framework and support by the development tools. The biggest restriction and future problem with this product is
Fig. 7: Parsing message loop Fig. 9: Database model
C. Requirements During meetings with the different parties, the following requirements were noted: • •
•
•
•
Log all location history. Implement a user-friendly program to query the history and extract specific statistics (e.g.: measure the activity of patients.) Users must be notified when a patient presses a button. The notification should clearly state who and where the patient is. A real time view of patients and staffs current locations must be available in order to find a patient or staff member. Implement a program to easily configure the tags.
The first requirement was achieved by building a Windows Service. This service taps in the library and saves all the data provided by the Ekahau Engine. Four main types of data were tracked: location coordinates (an absolute position), area estimate (an area where the item is located), a device property change (for instance: battery level of the device, a button is pressed, the name of the device changed, ...) and finally, when a device is added or removed to the network, a device activity entry. The database model maps these four different
the 4GB Database limitation[16]. A quick view at the database shows us the following projected table growths and sizes: • AreaEstimate table has a growth size of 44 bytes per row and grows 23.000 rows per day. • DeviceActivity table has a growth size of 36 bytes per row and grows 6 rows per day. • DeviceProperties table has a growth size of 232 bytes per row and grows 5285 rows per day. • Location table has a growth size of 96 bytes per row and grows 47.000 rows per day. This brings us to a total Database growth of 6,56MB per day or 2,4GB per year. At this rate, the database can run for 624 days, which is approximately 1 year and 8 months. Since the log viewer and the real time tracking viewer show the same information, people on a map, one application was chosen that incorporates both functionalities. When using the Log view mode, tracked entries can be viewed for all or individual devices. The application makes it possible to replay the route people made including the positions where ”button pressed events” occurred. Besides this visual representation, an important
RTLS
7
requirement was the ability to generate a measurable value that represents the activity of a certain patient or group of patients. This can be measured in two ways when we take the data provided into account: • A distance calculation based on area estimates. We calculate the distance travelled by logging the sequence of areas that are passed. To make this possible we need to add an arbitrary distance to each area. • A distance calculation based on the location coordinates. The biggest challenge is to filter out small errors. Due to the nature of the location system (using signal strength) positions are determined by calculating statistical algorithms on a collection of different samples. As a result, positions have a small error and are continuously circling around the actual position (with an error of maximum 3 meters). When these values are added, a huge distance can be the result while the person in question is really standing still. To solve this, an average of the last five positions is used to minimize the effect of the errors. For the alert or notification application we chose a system tray windows application. A system tray application is an application that only shows an icon in the area left to the clock in the bar on the bottom on Windows machines that invokes balloon tips or dialogs to warn the user. Our system tray application invokes warnings containing information to identify and locate the person who pressed the button. Besides these programs, a tool was written to automatically configure the Ekahau tags. Tag configurations can easily be created, locally stored, backed up, restored and extended through custom properties with the use of this small application. To make the binding between a person and a tag less error prone the configuration of the tag can be done based on an e-ID. When you put an e-ID in the reader and connect the tag to the computer, our tool will automatically configure the tag with information of the person.
extra access point an additional 690m2 were covered. The achieved coverage per access point is off course highly dependent on the surroundings. Every four access points, a switch was needed. The server is a fixed cost and is estimated at 1500 Euro for the hardware, an extra 450 Euro for the Windows Server 2003 license and 4 hours at 60 Euro per hour installation time. Another factor and biggest drawback of the technology used is the need for calibration also known as fingerprinting. This manual labour intensive task has surprisingly little impact on the total cost of the installation as can be seen on the Graph. When we apply this calculation to the project at the healthcare institute in Merksem (RVT[17]) which has a surface of 1800m2 we find the following calibration cost: 133,33 Euro. Since the Surface at RVT is T-shaped, we need to calculate the equivalent surface to determine the amount and cost of the access points and switches, because during the calculation a rectilinear surface was presumed. For the RVT, the equivalent surface is 3992m2 . This gives us eight access points and two switches. This corresponds with the real situation. The cost in relation to the number of people to track depends completely on the pricing policy of Ekahau, as shown in figure 11. The following information is nothing more than an indication and is added here for completeness. For accurate and up to date pricing, you should contact Ekahau. The small steps visible in the graph are caused by quantity discounts. For instance, the first 99 tags have a cost of 74 Euro per tag. When your quantity exceeds 100 devices, the price per tag is 57 Euro.
V. COST CALCULATION Two factors determine the cost of this solution: • The number of people to track. This will determine the Ekahau software license and the amount of devices that are needed. • The surface where you want to accurately track people. The latter is what we were able to measure in this project. This is shown in figure 10.
Fig. 11: Ekahau prices
VI. CONCLUSION
Fig. 10: Cost calculation
Depending on the surface, a number of access points are needed to achieve coverage with an initial amount of three access points. Per
As general conclusion, we can state that this masterproject has reached its goals. During the pilot project, a lot of knowledge was accumulated in the area of RTLS using WiFi. Furthermore, some experience was gathered on how to setup and maintain the Ekahau Software Solution. This research also confirmed that the RSSI-technology is a good solution to use indoor, and achieves satisfactory results on accuracy. We also proved that it is perfectly possible to design custom applications based on the Ekahau solution. These applications can be written using any programming language. As a last point, the research gave a reliable indication of the costs of such an RTLS system. This is very important information for companies or other organisations to have an indication what kind of investments have to be made. For further information, please refer to www.rtls.be
8
RTLS R EFERENCES
[1] AeroScout, May 2006, company Website. [Online]. Available: http://www.aeroscout.com [2] Ekahau, May 2006, company Website. [Online]. Available: http://www.ekahau.com [3] P. Networks, May 2006, company Website. [Online]. Available: http://www.pangonetworks.com [4] WhereNet, May 2006, company Website. [Online]. Available: http://www.wherenet.com [5] Copyright (c) 2000-2005 Ekahau, Inc. All rights reserved. [6] [Online]. Available: http://msdn.microsoft.com/vstudio/products/ [7] [Online]. Available: http://ekahau.com/?id=4500 [8] B. J. Geier, “Assigning 802.11b access point channels.” [9] [Online]. Available: http://www.nunit.org/ [10] [Online]. Available: http://www.codeproject.com/gen/design/nperf.asp [11] [Online]. Available: http://www.mertner.com/confluence/display/NProf [12] [Online]. Available: http://www.nplot.com/ [13] Microsoft, “Microsoft patterns and practices website,” May 2006. [Online]. Available: http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnbda/html/factopattern.asp [14] Wikipedia, “Parser definition,” May 2006, wikipedia Website. [Online]. Available: http://en.wikipedia.org/wiki/Parser [15] Microsoft, “.net framework regular expressions,” May 2006, mSDN Website. [Online]. Available: http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpguide/html/cpconCOMRegularExpressions.asp [16] S. E. P. Website, May 2006. [Online]. Available: http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx [17] Healthcare centre for elderly people, Merksem (Antwerp), Belgium.
