In the first part of this book, we motivated the need for accurate and cost-effective positioning systems that can enable the delivery of location-based services (LBS). Moreover, we suggested positioning based on wireless local area networks as a cost-effective and reliable solution for supporting such services in indoor environments. The second part of this book provides an in-depth treatment of the technical fundamentals of these systems. This chapter will begin by providing an overview of wireless local area networks (Section 5.1) and the radio features that can be used for positioning in these networks (Section 5.2). After motivating the use of received signal strength as the feature of choice for positioning, we proceed to describe the details of the experimental data set used for illustrating various concepts in this book (5.3). This is followed by a discussion of the spatial and temporal properties of received signal strength (Section 5.4), challenges in using this radio feature (Section 5.6), and techniques for modeling the relationship between received signal strength and position (Section 5.5).

Wireless local area networks

Wireless local area networks (WLANs) are radio-based communication network infrastructures based on the IEEE 802.11 family of standards. These networks operate in the unlicensed frequency bands [27], primarily employing the 2.4 GHz ISM band. As shown in Figure 5.1, WLANs use an architecture that relies on a set of base-stations for facilitating communication among the devices within the network, and between the network and the outside world (for example, the Internet).

The objective of a positioning system is to determine the position of a mobile device. This position, however, is not directly observable and must be determined based on some observable measurement. In the case of RSS-based positioning, this observable measurement is the received signal strength (RSS) at the mobile device. If the relationship between the RSS values and the position of mobile devices were known, the positioning problem would be trivial. However, as discussed in Chapter 5, this relationship is not deterministic in practice, but depends on the stochastic characteristics of the propagation environment. Consequently, the unknown position can only be estimated using RSS measurements. The focus of this chapter is the various estimation methods used to accomplish this task. In particular, this chapter focuses on memoryless estimators, which rely on an RSS measurement at a given time to compute the position estimate at that time. In other words, memoryless estimators do not consider the past history of user positions or RSS measurements during estimation.

We begin this chapter by developing a mathematical formulation of the memoryless positioning problem (Section 6.1) and show that this problem reduces to a density estimation problem. We next review two methods for density estimation based on the implicit training information provided in the radio map (Section 6.2). Using these density estimation techniques, we proceed to develop several position estimators (Sections 6.3 and 6.4). Finally, we conclude the chapter with the presentation of some experimental results (Section 6.5).

Positioning systems employ information from a large number of access points and anchor points distributed over large areas to locate a mobile device. In order to form a position estimate, the system must combine or fuse the information provided by these sources to make inferences regarding the location of a mobile device. Fusion of data from multiple sources is not a trivial task as redundancy and conflict among the information can significantly affect the accuracy and reliability of the final estimate. In the context of positioning, data fusion is especially challenging as the unreliable and time-varying nature of the radio-propagation channel means that erroneous and out-of-date information may be received from access and anchor points. In this Chapter, we focus on one data fusion challenge, namely sensor selection. In our context, sensor selection refers to selecting a subset of the available access and anchor points for positioning.

The rest of this chapter is organized as follows. We begin by motivating sensor selection for WLAN-based positioning (Section 8.1). We then proceed to discuss several methods for access point and anchor point selection (Sections 8.2 and 8.3). We conclude this chapter by illustrating the benefits of sensor selection using experimental data (Section 8.4).

Motivation

In WLAN-positioning, information from multiple anchor points and access points is fused to form a position estimate. Careful selection of the sensors that contribute to positioning can benefit RSS-based positioning in two ways.

Since the first WLAN-positioning system was introduced in 2000 [4], rapid advances in signal processing methods have been made in this area. A decade later, fundamental positioning techniques have matured significantly, allowing these systems to offer highly accurate positioning estimates with accuracies on the order of several meters in both indoor and outdoor environments.

The previous chapters have reviewed the fundamental techniques used in WLAN positioning. In this chapter, we look ahead to opportunities and challenges remaining to be addressed in this area.

Highlights

The focus of this book has been WLAN-based positioning. Chapters 1 to 4 discussed the history, applications, and various positioning systems to motivate these systems. In particular, the development of these systems is motivated by the need for accurate, reliable, and cost-efficient positioning solutions to enable the delivery of location-based services (LBS).

The second part of the book was dedicated to fundamental signal processing concepts in these systems. In Chapter 5, we saw that the unpredictability of radio signal features poses a significant challenge to the development of accurate and reliable WLAN systems. In Chapter 6, we discussed a number of non-parametric techniques that can be used to model these radio signals using training samples collected at a set of anchor points with known locations. In addition to their effectiveness as modeling tools, these nonparametric techniques also allowed the estimation of a measure of uncertainty associated with position estimates.

In the previous chapters, we discussed the history and application of modern positioning systems that enable the delivery of location-based services (LBS). In this chapter, we shift our attention to the fundamental positioning principles used in these systems. We begin this chapter by presenting the location stack, a model of location-aware systems, and identify the focus of this book (Section 3.1). We then proceed to discuss the most commonly used techniques for computing the position of mobile receivers. Similar to the techniques used in celestial navigation, modern positioning systems often employ a set of references with known locations for position computation. In this chapter, we discuss different positioning methods, differentiated by the type of references and signal measurements used (Sections 3.2 to 3.4). In addition to these techniques, which generally employ wireless signals, we will also briefly review dead reckoning (Section 3.6) and computer-based positioning (Section 3.7) methods. These two techniques employ modalities complementary to wireless measurements and as such provide a promising direction of development for hybrid positioning systems that employ multiple measurements to improve the accuracy and reliability of positioning. Finally, we conclude the chapter by discussing the advantages and disadvantages of each positioning method (Section 3.8).

The location stack

To position this book within the wealth of information available on positioning systems used in LBS, we review a model of location-aware systems proposed by Hightower et al. [35].

For thousands of years, the ability to explore the world has significantly impacted human civilization. Human explorations have enabled the interaction of cultures for the purposes of geographic expansion (for example, through war and colonization) and economic development through trade. These interactions have also played a pivotal role in an exchange of knowledge that has supported the advancement of science, the development of religion, and the flourishing of the arts throughout the world.

World exploration is largely enabled by the ability to control the movement of a vessel from one position to another. This process, known as navigation, requires the knowledge of the locations of the source and destination points. The process of determining the location of points in space is known as positioning. In this book, we use the terms location and position interchangeably to refer to the point in physical space occupied by a person or object.

Throughout history, various positioning methods have been developed including methods using the relation of a point to various reference points such as celestial bodies and the Earth's magnetic pole. More recently, the advent of wireless communications has led to the development of a number of additional positioning systems that enable not only navigation, but also the delivery of additional value-added services. The focus of this book is one such positioning method that employs wireless local area signals to determine the location of wireless devices.

Traditionally, the application scope of positioning systems was limited to target tracking and navigation in civilian and military applications. This has changed in past decades with the advent of mobile computing. In particular, the maturation of wireless communication and advances in microelectronics have given birth to mobile computing devices, such as laptops and smart phones, which are equipped with sensing and computing capabilities. The mobility of these computing devices in wireless networks means that users' communication, resource, and information needs now change with their physical location. More specifically, location information is now part of the context in which users access and consume wireless services. This, together with the availability of positioning information (for example, through the Global Positioning System), both necessitated and enabled the development of services that cater to the changing needs of mobile users [34]. This need has sparked a new generation of applications for positioning known as location-based services (LBS) or location-aware systems. Formally, LBS have been defined in many ways [24, 50, 80]. In this book, the term LBS is used to indicate services that use the position of a user to add value to a service [50].

In this chapter, we will discuss the economical and ethical implications of LBS. We begin with an assessment of the market potential for these services (Section 2.1). This is followed by a discussion of application areas where LBS services can be employed (Section 2.2). Finally, we discuss the ethical implications of LBS (Section 2.3).

This chapter first revisits the cases described in Chapter 5 but utilizing high-level wrapper APIs instead. Then, another case is demonstrated to illustrate how to create connectionoriented communications. To follow this chapter, it is assumed that a reader understands the content covered in Chapter 5 and Chapter 6.

Revisit of previous case

In this section, Case 6 in Chapter 5 is revisited but this time with wrapper APIs.

Open “pk_switch” process model in Process Editor. Save it as “pk_switch_v2”. Now, you can edit “pk_switch_v2” and replace relevant code with wrapper APIs. In SV block, replace the declarations of state variables, as shown in Figure 7.1.

In TV block, replace the declarations of temporary variables, as shown in Figure 7.2.

In HB block, include header files: “routing.h” and “geo_topo.h”, as shown in Figure 7.3. These two files include relevant wrapper APIs for performing routing and topology related operations.

In “init” state, replace previous code for building the graph and routing table with the new code that utilizes wrapper APIs, as shown in Figures 7.4 and 7.5.

From Figures 7.4 and 7.5, it is seen that after applying the wrapper APIs, the processing of vertices and edges in the routing graph is performed by dealing with W_Vertex_Info andW_Edge_Info objects. The steps for implementing routing algorithm can be represented by the corresponding wrapper APIs in the following way:

• Initialize graph – w_init_graph().

• Set vertices of the graph – w_set_graph_vertices().

• […]

This chapter shows the steps for installing and configuring the OPNET Modeler and its related environment variables. Having followed this chapter, one should be able to run the OPNET Modeler correctly. If OPNET Modeler and relevant software have already been installed and environment variables have been configured on the target machine, this chapter can be skipped. If you have problems compiling OPNET models, especially, compiling standard OPNET models which should have no compilation and linking errors, please check this chapter to make sure your software is properly installed and environment variables are correctly configured, since many OPNET model compilation and linking errors come from incorrect configuration of the C/C++ compiler's environment variables.

This chapter first describes the system requirements for using OPNET Modeler, including both hardware and software requirements. Then it shows the steps for installing and configuring OPNET Modeler on both Windows and Linux operating systems respectively.

System requirements for using OPNET Modeler

This section lists the requirements for using OPNET Modeler 14.5 and later versions, and also highlights the relevant key points. For other versions of OPNET Modeler, please check the system requirements datasheet and installation manual shipped with corresponding products, or visit the OPNET website for more information (www.opnet.com). Tables 2.1–2.3 list the system support and hardware and software requirements for using OPNET Modeler.

Installation on Windows

On Windows, you need to install OPNET Modeler and Microsoft Visual Studio or Microsoft Visual C++ for OPNET Modeler to compile C/C++ based simulation models.

This chapter covers OPNET API (application programming interface) packages and provides an in-depth discussion on a number of commonly used APIs. Practical examples are provided to explain the studied OPNET APIs. If the reader is familiar with OPNET APIs and programming OPNET models, this chapter can be skipped.

Introduction to OPNET programming

The programming language for writing OPNET Models is called Proto-C. There are not many syntax differences between programming in C and Proto-C, since Proto-C preserves generality by incorporating all the capabilities of the C/C++ programming language, i.e., you can program OPNET models in the same way as you program C/C++ applications. The major difference is the methodology adopted by Proto-C to program models. Unlike programming standalone C/C++ applications, Proto-C is designed to handle OPNET predefined data types via an existing simulation engine, which can be regarded as a half-done application in a standalone C/C++ application. This simulation engine needs to incorporate the Proto-C model code to generate a final runnable and debuggable standalone simulation application. The simulation engine can be regarded as pre-written skeleton or framework which is the kernel in every simulation application. Your OPNET model code is the custom part of the simulation application. Your OPNET model code is inserted into the designated positions of the simulation engine framework to generate the final complete source files. These files will be compiled and linked into a normal C/C++ application.

This chapter briefly describes the differences between Proto-C, C, and C++ languages and shows how to configure OPNET to program models in C++. A case study is also provided to help the reader grasp the important points on programming OPNET models in C++. If you are intending to program only in C style, this chapter can be ignored. If you are familiar with C++ and are interested in programming models in object-oriented C++ style, you may read this chapter. The chapter requires basic knowledge of generic C++ programming.

Proto-C, C, and C++: language and library differences

OPNET provides a programming language called Proto-C to allow users to model various systems. Proto-C preserves generality by incorporating all the capabilities of the C/C++ programming language, i.e., a user can program in Proto-C in a similar way to in C/C++, and in Proto-C you can use the libraries that are accessible to C/C++ as well. On the other hand, Proto-C provides a set of its own APIs to model communication networks. Proto-C supports modeling with the state transition diagram (STD) method, which makes it possible to accurately describe most systems. Figure 12.1 shows that Proto-C allows you to use both C/C++ and Proto-C libraries and write models in both C and C++ styles.

OPNET Modeler provides an authoring tool to allow authors to protect their models against unauthorized use. This chapter demonstrates how to use this authoring tool to protect and license user OPNET models. In order to follow this chapter, a reader should understand the basic concepts of OPNET models.

Introduction

In practice, you often need to publish models to allow other people to use them. However, sometimes you want them only to use these models but not to view the implementation details of these models, and/or to use these models for a limited time, like a demo version with limited access ability. To handle these issues, OPNET Modeler provides an authoring tool that allows you to encrypt your models to provide three levels of access: Use, Inspect, and Full. For “Use” access, users can only use the model in a simulation, but cannot inspect this model's structure or code via either the GUI editor or programming interface. For “Inspect” access, users can use this model in a simulation and inspect the model with certain programming interface procedures, but cannot view the structure of the model via the GUI editor. For “Full” access, users have full access to the model, i.e. they can use it, view it, and modify it in either the GUI editor or programming interface. By default, a model is not protected by the authoring tool, which therefore has “Full” access.

This chapter explains the concepts and techniques of building wireless networks based on standard OPNET models. It is essential to understand the concepts described in Chapter 8 when reading this chapter, and a basic knowledge of wireless technology is required.

Basics of wireless modeling

The processes for modeling wireless networks are similar to those for modeling wired networks in OPNET Modeler. However, there are some differences. For wireless networks, nodes are connected via invisible radio links instead of cable links. Unlike fixed cable links, a radio link can be influenced by interference, antenna pattern, and movement of mobile nodes. Therefore, it requires simulation to dynamically compute radio link connectivity, propagation delay, and power levels.

In Node Editor, there are three modules used for modeling wireless nodes: Radio transmitter, Radio receiver and Antenna, as shown in Figure 9.1.

In Figure 9.1, the module marked no. 1 is the radio receiver module, the module marked no. 2 is the radio transmitter module, and the module marked no. 3 is the antenna module. Radio transceiver modules allow packets to be sent or received via radio links. The antenna module can be used to exchange packets with other nodes when antenna directionality or gain needs to be modeled. Antenna module is associated with Radio transmitter and Receiver modules by means of packet streams as shown in Figure 9.1. Antenna location in three-dimensional space can be determined by Antenna module's “latitude”, “longitude”, and “altitude” attributes.