TECHNICAL FIELD

[0001] This disclosure relates in general to the field of computer systems and, more particularly, to device location tracking.

BACKGROUND

[0002] Location-based services are increasing in popularity and value, particularly as marketers realize the value of catering to users' specific interests, tendencies, and proximity within a particular geographical area. To provide such location-based services, it can be a prerequisite to provide functionality for reliably determining the location of a user (or device carried by a user). Location can also be applied in other applications, such as applications aimed at enhancing traditional agriculture, traffic maintenance, robotics, drone and autonomous vehicle tracking, orchestrations, and traffic management, among other examples. Radio frequency technology has been utilized to determine device locations. Global positioning systems (GPS) is one example of a localization system that can be used to derive location information that can be used in one or more graphical user interfaces and location-based services. GPS systems involve space-based antennas that can provide location information to client receivers potentially anywhere having an unobstructed line of sight to four or more GPS satellites, among other example localization systems.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] FIG. 1 illustrates an embodiment of a system including devices capable of being deployed within a machine-to-machine (M2M) network, each hosting respective device localization logic.

[0004] FIG. 2 is a simplified block diagram illustrating example devices with local location manager computing logic.

[0005] FIG. 3 is a block diagram illustrating an overhead view (or floorplan) of an example environment in which an M2M network can be deployed.

[0006] FIG. 4 is a simplified block diagram illustrating representations of grids in a gird-based localization system. [0007] FIG. 5 illustrates an example of localization of a device based on two dimensional encounters with other devices within a system.

[0008] FIGS. 6A-6B are flowcharts illustrating example techniques for determining location of a device.

[0009] FIGS. 7A-7B are flowcharts illustrating additional example techniques for determining location of a device.

[0010] FIG. 8 is a block diagram of an exemplary processor in accordance with one embodiment; and

[0011] FIG. 9 is a block diagram of an exemplary computing system in accordance with one embodiment.

[0012] Like reference numbers and designations in the various drawings indicate like elements.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

[0013] Together with satellite global positioning systems, indoor location technology is a key contributor to delivering location-based services. Radio-based indoor positioning has been a popular approach, enabling robust indoor positioning in some systems. Global positioning systems (GPS) have also enjoyed wide-adoption in personal computing devices (e.g., smartphones, tablets, and in-vehicle computers), providing precise. Despite these advancements, localization within Internet of Things (loT) systems can remain a challenge, particularly in systems deploying a heterogeneous mix of loT devices. The capabilities of loT devices can vary widely. Some devices may be provisioned with high speed processing capabilities, GPS modules, and sophisticated software stacks, while other devices are, by design, more simply provisioned (e.g., with lower power processors, minimal memory, specialized sensors, simplified communication interfaces, etc.). In this sense, some loT devices can be considered resource-constrained in that their design is focused to include only those features and hardware that allow them to perform their particular function (e.g., as a sensor and/or actuator) and communicate with at least one other device to participate in loT systems. Accordingly, such resource-constrained devices often do not possess higher-end localization capabilities, nor are they equipped with the infrastructure to support such capabilities (e.g., GPS) without weighing down the original design. Additionally, even when devices possess state of the art GPS and other localization systems, these solutions may perform poorly within certain environments (e.g., certain indoor environments, multi-story environments, etc.). Accordingly, localization systems can be provided that utilize principles of collaborative localization, where multiple devices, operating (and, in some cases, moving) together within an environment can provide reliable localization results for devices within an loT system. Further, an improved system can be provided to support localization based on two-dimensional (2D) encounter geometry to further improve upon existing localization systems to implement a solution well-tailored for heterogeneous loT systems.

[0014] FIG. 1 is a block diagram illustrating a simplified representation of a system 100 that includes one or more devices 105a-d, or assets, deployed throughout an environment. Each device 105a-d may include a computer processor to execute varying types of programs or other code, as well as communications modules to allow each device 105a-d to intercommunicate and operate with one or more other devices (e.g., 105a-d) or systems in the environment. Such communications modules can include an antennae and receiver, the antennae capable sending signals, which may serve as beacons within a device localization solution. Each device can further include one or more instances of various types of sensors (e.g., HOa-c), actuators (e.g., 115a-b), storage, power, and computer processing resources, which can be leveraged and utilized (e.g., by other devices or software) within a machine-to- machine, or Internet of Things (loT) system or application.

[0015] Sensors configured for use in various M2M and loT applications, or "application sensors," can be operable to detect, measure, and generate sensor data describing characteristics of the environment in which they reside, are mounted, or are in contact with. For instance, a given application sensor (e.g., llOa-c) may be configured to detect one or more respective characteristics such as movement, weight, physical contact, temperature, wind, noise, light, computer communications, wireless signals, position, humidity, the presence of radiation, liquid, or specific chemical compounds, among several other examples. Indeed, application sensors (e.g., llOa-c) as described herein, anticipate the development of a potentially limitless universe of various sensors, each designed to and capable of detecting, and generating corresponding sensor data for, new and known environmental characteristics. Actuators (e.g., 115a-b) can allow the device to perform some kind of action to affect its environment. For instance, one or more of the devices (e.g., 105b, d) may include one or more respective actuators that accepts an input and perform its respective action in response. Actuators can include controllers to activate additional functionality, such as an actuator to selectively toggle the power or operation of an alarm, camera (or other sensors), heating, ventilation, and air conditioning (HVAC) appliance, household appliance, in-vehicle device, lighting, among other examples.

[0016] As noted above, application sensors llOa-c and actuators 115a-b provided on devices 105a-d can be incorporated in and/or embody an Internet of Things (loT) or machine-to-machine (M2M) systems. loT or M2M systems (sometimes used interchangeably herein) can refer to new or improved ad-hoc systems and networks composed of multiple different devices interoperating and synergizing to deliver one or more results or deliverables. Such ad-hoc systems are emerging as more and more products and equipment evolve to become "smart" in that they are controlled or monitored by computing processors and provided with facilities to communicate, through computer-implemented mechanisms, with other computing devices (and products having network communication capabilities). For instance, loT systems can include networks built from sensors and communication modules integrated in or attached to "things" such as equipment, toys, tools, vehicles, etc. and even living things (e.g., plants, animals, humans, etc.). In some instances, an loT system can develop organically or unexpectedly, with a collection of sensors monitoring a variety of things and related environments and interconnecting with data analytics systems and/or systems controlling one or more other smart devices to enable various use cases and application, including previously unknown use cases. Further, loT systems can be formed from devices that hitherto had no contact with each other, with the system being composed and automatically configured spontaneously or on the fly (e.g., in accordance with an loT application defining or controlling the interactions). Further, loT systems can often be composed of a complex and diverse collection of connected devices (e.g., 105a-d), such as devices sourced or controlled by varied groups of entities and employing varied hardware, operating systems, software applications, and technologies.

[0017] Facilitating the successful interoperability of such diverse systems is, among other example considerations, an important issue when building or defining an loT system. Software applications can be developed to govern how a collection of loT devices can interact to achieve a particular goal or service. In some cases, the loT devices may not have been originally built or intended to participate in such a service or in cooperation with one or more other types of loT devices. Indeed, part of the promise of the Internet of Things is that innovators in many fields will dream up new applications involving diverse groupings of the loT devices as such devices become more commonplace and new "smart" or "connected" devices emerge. However, the act of programming, or coding, such loT applications may be unfamiliar to many of these potential innovators, thereby limiting the ability of these new applications to be developed and come to market, among other examples and issues.

[0018] As shown in the example of FIG. 1, multiple loT devices (e.g., 105a-d) can be provided from which loT systems can be deployed according various loT software applications. A device (e.g., 105a-d) can include such examples as a mobile personal computing device, such as a smart phone or tablet device, a wearable computing device (e.g., a smart watch, smart garment, smart glasses, smart helmet, headset, etc.), purpose-built devices such as and less conventional computer-enhanced products such as home, building, vehicle automation devices (e.g., smart heat-ventilation-air-conditioning (HVAC) controllers and sensors, light detection and controls, energy management tools, etc.), smart appliances (e.g., smart televisions, smart refrigerators, etc.), and other examples. Some devices can be purpose-built to host sensor and/or actuator resources, such as a weather sensor devices that include multiple sensors related to weather monitoring (e.g., temperature, wind, humidity sensors, etc.), traffic sensors and controllers, among many other examples.

[0019] Some loT devices may be designed to be statically located, such as a device mounted within a building, on a lamppost, sign, water tower, secured to a floor (e.g., indoor or outdoor), or other fixed or static structure. Other devices may be mobile, such as a sensor provisioned in the interior or exterior of a vehicle, in-package sensors (e.g., for tracking cargo), wearable devices worn by active human or animal users, an aerial, ground-based, or underwater drone among other examples. Indeed, it may be desired that some sensors move within an environment and applications can be built around use cases involving a moving subject or changing environment using such devices, including use cases involving both moving and static devices, among other examples. The location and changes in location of such devices relative to other devices or the environment in which they operate can be leveraged in some loT applications. Accordingly, localization logic can be disposed on one or more of the devices (e.g., 105-a) in the system and/or a management system (e.g., 150) managing deployment and operation of the system, among other examples.

[0020] Continuing with the example of FIG. 1, software-based loT management platforms (e.g., 150) can be provided to allow developers and end users to build and configure loT applications and systems. An loT application can provide software support to organize and manage the operation of a set of loT device for a particular purpose or use case. In some cases, an loT application can be embodied as an application on an operating system of a user computing device (e.g., 120) or a mobile app for execution on a smart phone, tablet, smart watch, or other mobile device (e.g., 125, 130). For instance, a management system 150 can provision one or more deployed devices in an loT system with application code in order to facilitate the loT system.

[0021] In some cases, the application can make use of a dedicated or general purpose management utility or administrative tool allowing users to configure settings and policies to govern how the set of devices (e.g., 105a-d) are to operate when deployed in an loT system. A management utility can also be used to select which devices are used with the application. In other cases, a dedicated loT management application can be provided which can manage potentially multiple different loT applications or systems. The loT management utility, or system, may be hosted on a single system, such as a single server system (e.g., 150) or a single end-user device (e.g., 130, 135, 140). Alternatively, an loT management system can be distributed across multiple hosting devices (e.g., 130, 135, 140, 150, etc.).

[0022] In some cases, applications can be programmed, or otherwise built or configured, utilizing interfaces of an loT management system. In some cases, the interfaces can adopt asset abstraction to simplify the loT application building process. For instance, users can simply select classes, or taxonomies, of devices and logically assemble a collection of select devices classes to build at least a portion of an loT application (e.g., without having to provide details regarding configuration, device identification, data transfer, etc.). Further, loT application systems built using the loT management system can be sharable, in that a user can send data identifying the built system to another user, allowing the other user to simply port the abstracted system definition to the other user's environment (even when the combination of device models is different from that of the original user's system). [0023] In some cases, loT systems can interface (through a corresponding loT management system or application or one or more of the participating loT devices) with remote services, such as data storage, information services (e.g., media services, weather services), geolocation services, and computational services (e.g., data analytics, search, diagnostics, etc.) hosted in cloud-based and other remote systems (e.g., 125). Such services 125 can also consume data generated from or describing the loT system. For instance, localization data can be generated (e.g., by individual devices (e.g., 105a-d) and/or the management system 150) and provided to a local or remote server (e.g., 125) of a service that utilizes localization. To provide such interaction, one or more devices (e.g., 105a-d) of an loT system can connect to a remote service over one or more networks 120. In some cases, a gateway device (or the management system 150) can be utilized to facilitate a network connection (e.g., an Internet connection) to facilitate interaction with a remotely hosted service 125. In some cases, the remote service can, itself, be considered an asset of an loT application and system. Additionally, data queried from or otherwise received from a remotely-hosted service can be consumed by the governing loT application and/or one or more of the component loT devices to cause one or more results or actions to be performed, among other examples.

[0024] One or more networks (e.g., 120, 122) can facilitate communication between loT devices (e.g., 105a-d), end user devices (e.g., 130, 135, 140), and other systems (e.g., 125, 150) utilized to implement and manage loT applications in an environment. Such networks can include wired and/or wireless local networks, public networks, wide area networks, broadband cellular networks, the Internet, and the like. For instance, in some implementations, one or more gateway devices (e.g., 125) can be utilized to facilitate communication with one or more devices (e.g., 105b-c) within a given loT system. For instance, a gateway can be utilized to extend the geographical reach of an loT system implementation, to provide a mechanism to communicate with devices (e.g., 105b) which possess limited or proprietary communications capabilities, or form sub-groups of devices within an loT system deployment.

[0025] In general, "servers," "clients," "computing devices," "network elements," "hosts," "system-type system entities," "user devices," "sensor devices," and "systems" (e.g., 105a-d, 125, 130, 135, 140, 150, etc.) in example computing environment 100, can include electronic computing devices operable to receive, transmit, process, store, or manage data and information associated with the computing environment 100. As used in this document, the term "computer," "processor," "processor device," or "processing device" is intended to encompass any suitable processing apparatus. For example, elements shown as single devices within the computing environment 100 may be implemented using a plurality of computing devices and processors, such as server pools including multiple server computers. Further, any, all, or some of the computing devices may be adapted to execute any operating system, including Linux, UNIX, Microsoft Windows, Apple OS, Apple iOS, Google Android, Windows Server, etc., as well as virtual machines adapted to virtualize execution of a particular operating system, including customized and proprietary operating systems.

(0026] While FIG. 1 is described as containing or being associated with a plurality of elements, not all elements illustrated within computing environment 100 of FIG. 1 may be utilized in each alternative implementation of the present disclosure. Additionally, one or more of the elements described in connection with the examples of FIG. 1 may be located external to computing environment 100, while in other instances, certain elements may be included within or as a portion of one or more of the other described elements, as well as other elements not described in the illustrated implementation. Further, certain elements illustrated in FIG. 1 may be combined with other components, as well as used for alternative or additional purposes in addition to those purposes described herein.

[0027] Changing conditions are expected in environments in which positioning solutions are deployed. Some conventional (and emerging) tools utilize RF signal trilateration and other techniques to derive location based on radio signal strength. Such "model-based" approaches may triangulate the position of a given device based on a radio propagation model to estimate the device's (e.g., tag's) distance from known location of beacons, or readers, utilized to triangulate the device and known transmission power of the device. Such systems often involve careful calibration of intrinsic and extrinsic parameters of the beacons.

[0028] Indoor localization functionality can be prerequisite to delivering certain location-based services. Multi-modal approaches have been developed for indoor localization leveraging a variety of sensors, typically implemented as stationary beacons, or statically mounted radio frequency (RF) devices emitting signals for pinpointing receiving devices. However, the uneven distribution of beacons can prevent localization solutions from scaling out and performing consistently across an environment. In one implementation, the capability of many loT devices (e.g., smartphones, tablets, laptops, wearable devices, sensors, etc.) to transmit and receive, either alternately or simultaneously, RF signals can allow even resource constrained or mobile loT devices to serve as beacons for use in implementing a localization solution. Indeed, in the case of mobile loT devices (e.g., devices designed to move or otherwise capable of moving within (or even in and out of) the environment can be utilized as mobile beacons. Such loT device-implemented beacons can be utilized collaborative to potentially better pinpoint each other device's location through information sharing in machine-to-machine (M2M) interactions.

[0029] Collaborative localization can be employed in systems where one or more of the deployed devices are resource-constrained. Collaborative localization can be categorized into classes of augmented state filtering/optimization solutions and belief merging systems, among potentially other examples. In augmented state filtering, locations or trajectories are estimated of a set of target devices in a unified theoretical framework (e.g., augmented state Kalman filtering, augmented state simultaneous localization and mapping (SLAM), structure from motion (SfM), etc.). Such solutions provide a theoretic upper bound and often rely on powerful, centralized processing resources (often offline), which aggregate all device observations (or estimations) to derive localization results. Such resource intensive, centralized solutions, however, typically incur outstanding device-to-device communication overhead in real world collaborative localization scenarios, limiting their utility in loT and M2M system networks. Belief merging can take, as inputs, a set of location results, instead of the raw sensor data, determined at a local view by a set of devices, where localization conclusions can be derived in a decentralized manner as communication overhead has been largely reduced. Traditional belief-merging solutions, however, do not incorporate 2D geometry without falling back on resource-intensive augmented state formulations (e.g., to formulate locations over time), which themselves may be inefficient in space and time. In implementations described herein, an improved M2M collaborative localization system can be provided that can infer and incorporate 2D encounter geometry without reliance on augmented state formulation.

[0030] A system implementing collaborative localization using 2D encounter geometry can represent advancements over other systems that attempt to realize belief merging, but without enforcing geometric constraints. In one implementation, an online algorithm can be applied to a grid based localization scheme (and corresponding algorithm) (e.g., Markov localization, conditional random field (CRF) based localization, etc.). An approximate distance measure can be determined using localization logic local to each of a plurality of devices in an loT system, and the relative orientations between any pair of the devices can be inferred through 2D geometry for facilitating integration into any grid-based localization algorithms. Further, M2M localization information sharing (e.g., through M2M communications) can enhance the solution, in some cases, allowing loT devices to share localization determinations with other loT devices. In some cases, through M2M localization information sharing, resource-constrained loT devices can leverage information determined by higher-end localization systems present on other loT devices in the system, or converged location determinations by other loT devices (e.g., from other resource-constrained devices which have a "head start" in determining their location within a session).

[0031] In some implementations, a collaborative localization system employing 2D encounter geometry can include machine executable logic to implement a partially delayed update solution. An approximate relative distance can be determined from beaconing between a pair of devices (e.g., based on detected signal strengths), which can be easily generalized to any RF beaconing technology (e.g., WiFi, ZigBee, ZWave, Bluetooth, Bluetooth Low Energy (BLE), etc.). Some implementations can provide reliable localization results without resorting to additional non-RF functionality, such as active sensors like cameras, microphone array, etc., which maybe unavailable or incompatible with some loT systems, including systems involving localization of resource-constrained devices, among other examples. Partially delayed update can address instances of localization service latency, for instance, where 2D geometry readings are delayed by insufficient M2M observations being obtained. In some use cases, it can be unacceptable to even temporarily lose track of a device, user, etc., for which localization is being determined. Additionally, in some services, localization latency can degrade the quality of the user experience in related loT applications and corresponding localization services.

[0032] At least some of the above example issues and solutions can be addressed, in the systems, devices, and implementations described herein. For instance, turning to FIG. 2, a system is illustrated, which includes multiple loT devices, or assets, (e.g., 105a-c) capable of being used in a variety of different loT applications and supporting collaborative localization within loT systems deployed using the devices (e.g., 105a-c). For instance, each of the assets 105a-c can be provided with respective location manager logic (e.g., 205, 210, 215) implemented in hardware and software local to the corresponding device. In this example, a location service system 220 can also be provided which can consume location data generated by one or more of the device-based location manager or a management system (not pictured in FIG. 2) interfacing with the location managers in connection with a particular loT system deployment.

[0033] Each of the loT assets (e.g., 105a-c) can include one or more processing apparatus (e.g., 222, 224, 226), one or more memory elements (e.g., 228, 230, 232), and hardware and/or software implementing one or more logical components. For instance, each asset pictured in FIG. 2 can include a beacon (e.g., 234, 236, 238) for generating a signal to broadcast to other devices (e.g., 105a-c) and receivers in an environment, from which the distance between the device (e.g., 105a) and one or more other devices (e.g., 105b-c) can be derived. The beacon signal can be generated according to one or more different RF signaling technologies (e.g., WiFi, Bluetooth, ZigBee, BLE, etc.). The beacon signal can carry information identifying the corresponding device (e.g., 105a-c) such that receiving devices can determine and track the distance between the devices. A beacon signal, in some cases, can carry additional information and can be used for more substantive wireless communications according to one or more defined communications protocols. A communication module (e.g., 240, 242, 244) can be provided, in some instances, to manage (wireless and even wired) and process data from communications with one or more other systems.

[0034] Generally, loT assets (e.g., 105a-c) can possess unique hardware and other logic (e.g., 110a, 110b, 115a, 246, 248, 250, etc.) to realize the intended functionality of the device. For instance, devices may be provided with such resources as sensors of varying types (e.g., HOa-b), actuators (e.g., 115a) of varying types, energy modules (e.g., batteries, solar cells, etc.), computing resources (e.g., through a respective processor and/or software logic), security features, data storage, and other resources. Further, additional logic (e.g., 246, 248, 250) can be provided through which the respective device (e.g., 105a-c) processes data generated or received by the device, generates communications, controls sensors and actuators of the device, generates outcomes related to the device's function(s), among other functionality.

[0035] As noted above, at least a subset of the devices deployed in a given loT system can possess locally-hosted location management logic (e.g., 205, 210, 215). While some devices (e.g., 105c) may possess GPS (e.g., 225) and other more sophisticated localization modules, other devices (e.g., 105a-b) may be resource-constrained and not possess such functionality. Nonetheless, the wireless communications capabilities of loT devices can be leveraged to support participation in collaborative localization utilizing 2D encounter geometry. For instance, location managers 205, 210 can include logic to support such collaborative, client-based localization solutions. In one example, a location manager 205, 210 can include a grid manager (e.g., 252, 254), a location estimator (e.g., 256, 258), a step engine (e.g., 260, 262), and 2D encounter engine logic (e.g., 264, 266), among other functionality or combinations of the foregoing. In one example, a grid manager (e.g., 252, 254) can be provided to manage location state for the device in a location grid (e.g., 268, 270), as well as, potentially track the locations determined for other devices encountered in the environment encountered. A location estimator (e.g., 256, 258) can be utilized to derive a starting location, or location probability within the grid (e.g., 268, 270). As the device (e.g., 105a-c), at the beginning of a localization session, may not have encountered any other device (e.g., shortly after power-on), the device (e.g., 105a-c) may begin by attempting to determine its starting location within the environment. Techniques such a RF signal fingerprinting within the environment, or triangulation based on known, fixed RF transmitters in the environment can be used, among other techniques to estimate the starting location of the device. Subsequent encounters with other devices (i.e., beacon signals from other devices) can be used to iteratively improve the location manager's estimate of the device's location within the grid. After a number of encounters and step events (tracked by step engine 260, 262), the location manager can identify a convergence of the device's location within a single one of the cells in the grid, thereby determining the device's location. In other instances, a device can receive location information from another device, which possesses a higher degree of certainty regarding its own position. For instance, device 105c may possess precise location information for its position within the environment using GPS module 225 and can advertise its position to the devices (e.g., 105a-b). Resource-constrained devices (e.g., 105a-b) (or devices without GPS or higher precision localization functionality) can likewise reach definitive judgments regarding their position in the environment (without relying in any way on GPS or other such localization technology) and share their position information with other devices (e.g., in its beacon signal).

[0036] A location manager (e.g., 205, 210, 215) can additionally include a step engine 260 configured to determine movement by the device (e.g., 105a-c) and estimate a change in position (tracked within the gird) based on the movement. As an example, a compass, gyroscope, accelerometer, or other functionality can be provided on the device (e.g., 105a-c) and determine that a person or animal carrying the device has taken a step. The general direction of the step can be determined, based on one or more accelerometer readings and the compass reading, and a distance attributable to the step (e.g., a predetermined average distance) can be assumed, from which the change in position can be calculated. Other implementations may determine movement, differently based on the nature of the device. For instance, a drone device that travels autonomously can drive or fly, and the speed of an engine, rotor, or tires can be measured or detected along with directional aspects of the device's movement to determine a change in position from a previously estimated or determined position and the position of the device following the movement.

[0037] A location manager (e.g., 205, 210, 215) can also include logic (e.g., 264, 266, 268) for estimating its position or movement within an environment using 2D encounter geometry. The beacon (e.g., 234, 236, 238) can include an antennae to receive signals broadcast by other relatively nearby devices and identify the corresponding broadcasting device from the signals. The 2D encounter engine (e.g., 264, 266) can record encounters (e.g., in encounter records 272) with each of the varied devices in accordance with the received signal. Each encounter record 272 can identify the sending device and also identify the strength, amplitude, or RSSI of the signal. After a number of consecutive encounters within a time window, the 2D encounter engine (e.g., 264, 266) can utilize triangulation or other geometric algorithms to calculate a distance between the receiving and sending devices and derive a position, or change in position, from the distance. Encounter determinations using 2D encounter engine (e.g., 264, 266) can be used in combination with steps or other location change determinations by the location manager 205, 210 (e.g., made by step engine 260, 262, etc.). Encounter-based location change determinations can be used to confirm, supplement, or reinforce the step-based location change determinations of the location manager (e.g., 205, 210). Indeed, after a number of step and encounter position change determinations for a device, it can be expected that the probability that the device is within a particular one of the cells of the location grid 268, 270 will converge to a single cell, or state. Once a threshold level of convergence has been reached for the location of a device, the device, in some instances, may advertise its findings to other devices in the M2M network, or loT system, to provide context for their 2D encounter determinations based on beacons from the device, among other uses.

[0038] In some implementations, some devices (e.g., 105c) may be equipped with GPS or other more formal or sophisticated localization functionality (e.g., 225). These devices can also include a location manager (e.g., 215). Such location managers can be configured to utilize the results of localization functionality 225. Such location managers (e.g., 215), in some implementations, may also possess functionality to support and participate in collaborative localization schemes (e.g., with resource-constrained devices 105a-b), including those implemented at least in part using 2D encounter geometry. For instance, device 105c can send beacon signals for use by other devices (e.g., 105a-b) to determine their respective locations relative to device 105c. In some cases, location managers (e.g., 215) using local GPS or other precision localization results can include much of the same functionality as those with more constrained localization functionality, for instance, to serve as an alternate or fallback localization mechanism for the device (e.g., 105c), such as when the GPS 225 malfunctions, is inoperable or unreliable given the physical environment in which the device operates, among other factors.

[0039] Continuing with the example of FIG. 2, a location service system 220 can also be provided in some implementations. The location service system 220 can include one or more processors (e.g., 276), one or more memory elements (e.g., 278), and other hardware and software components to host a service (e.g., 275) that utilizes location information of one or more devices (e.g., in location data 282) in an loT system as an input to the service 275. Such services can include an application that tracks movement of a person, robot, drone, or animal in the environment and utilizes this information to provide a given outcome. A location service examples can include services that pushes recommendations or offers to a user based on their current location, a service that pushes a particular instruction or code to a drone or robot based on its position, a service that provides varying levels of security to a device based on the location in which it is found, a service to provide traffic and traffic route information, among many other potential examples. The location service system 220 can include one or more interfaces (e.g., 280) through which the location service system may communicate with an loT system. In some cases, the location service system 220 may communicate directly with devices (e.g., 105a-c) to obtain their respective location information (determined locally through collaboration with other devices). In other cases, a device or server, such as that of a management system, can aggregate location determination data from multiple deployed loT devices (e.g., 105a-c) and provide the aggregated location data (e.g., 282) for consumption in the location service 275 (e.g., through a corresponding interface (e.g., 280) on behalf of the devices (e.g., 105a-c), among other example implementations.

[0040] Client user devices (e.g., 130), such as laptops, desktops, tablets, phablets, smart phones, etc., can also interface with an loT system utilizing the collaborative localization techniques described herein. In some cases, the client device (e.g., 130) can host one or more applications (e.g., 292) to be run in its operating system (OS) (e.g., 294), which can make use of location information collected from devices (e.g., 105a-c) in an loT system deployment. In still other implementations, a location engine 296 can be provided at client user devices (e.g., 130) to assist in the determination of location of loT devices (e.g., 105a-c) within proximity of the user device 130. For instance, location engine 296 can generate a beacon signal and advertise its position to other loT devices (e.g., 105a-b) to assist location managers (e.g., 205, 210, 215) determine location. Alternatively, client device 130 can be considered a mobile loT asset itself and its location engine 296 can both assist other devices in the environment through encounter events, as well as use these encounters to determine or reinforce determination of its own location, among other examples. In some cases, a client device (e.g., 130) can include one or more processors (e.g., 284), one or more memory elements (e.g., 286), and a communications module (e.g., 288), through which the device can communicate with other devices in a network. In one example, the user device 130 can enable user interface (to be presented on display 290) to allow a user to manage settings, configuration, and other aspects of an loT deployment. Further, display 290 can be used to present graphical user interfaces (GUIs) configured to represent positioning and movement of various loT devices or to serve as a GUI of a location -based service (e.g., 220) or locally-hosted application (e.g., 292) which makes use of the loT localization information (e.g., determined by instances of a location manager (e.g., 205, 210), among other examples. For instance, a map can be presented in such GUI examples and an icon or other graphical element can be configured to move about the map to correspond to determined position and movement of one or more devices (including the client device itself) within an environment utilizing the 2D encountering solution, among other examples.

[0041] Turning to FIG. 3, an above view, or floorplan 300, of an example environment is shown, in which an example loT system can be deployed. In this example, at least two loT devices (e.g., 105a-b) have been deployed, each capable of broadcasting a beacon signal and further including logic to determine, from the other device's beacon, a distance from the other device. Each device can further determine its location in the 2D floorplan based on the distance determined from the other device's beacon. Each of the devices (e.g., 105a-b) may move within the environment. Sometimes only one of the devices may be moving, at other times both devices may be moving simultaneously within the environment 300.

[0042] In some implementations, other communications devices (e.g., 310, 315, 320, 325) may also be present within the environment, such as fixed or otherwise statically located devices equipped with RF transmitters that may emit signals within the environment. In some implementations, example loT devices (e.g., 105a-b) can utilize RF signals from statically located transmitters (e.g., 310, 315, 320, 325) to derive an initial estimate of the device's location within the environment. For example, a location manager of the device may detect the strengths of the fixed signals to determine a distance from the fixed transmitters (e.g., 310, 315, 320, 325) and the device. From this reading, and a knowledge of the location of the transmitters (e.g., 310, 315, 320, 325), the device (e.g., 105a-b) may estimate its initial position within the environment 300. In another example, fingerprinting can be utilized based on the mix of RF signals broadcast by the collection of transmitters (e.g., 310, 315, 320, 325) to estimate the device's initial position within the environment 300, among other localization techniques.

[0043] The initial location estimate for a device (e.g., 105a-b) may determine an array of probabilities that the device is in a respective one of cells of a location grid corresponding to the environment 300. In some instances, the initial estimate may provide a relatively low level of convergence, with multiple different grid cells indicating a relatively high probability that the device is present in the cell. A first movement step of the device can reference the initial estimate and the change in location can be based on a corresponding movement away from the initial location. Further, as the devices 105a-b move about the environment 300, they may encounter the beacon signals of the other device and determine a distance between the devices (e.g., 105a-b) at the encounter based on the beacon signal. These encounters can be used with the detected step (or other movements) to cause the device to narrow the variance of the grid probability array to eventually converge the location estimation to a single grid cell.

[0044] As noted above, locally hosted location manager logic can employ grid-based localization, easy hardware implementation and acceleration for resource-constrained and other loT devices. The location manager can utilize potentially any grid-based localization algorithms. In some implementations, location managers can collaborate with the location managers of other devices to perform grid merging (or element-wise multiplication as every grid cell represents a respective probability). For instance, when two devices (e.g., 105a-b) are in the same geographic area, or environment, at a particular time, the location estimate for each device can be represented locally in grid-based notation. As represented in FIG. 4, each device can host data representing the corresponding location grid (e.g., 405, 410) of the device (e.g., 105a-b, or "Subject A" and "Subject B"). Probability distributions within the grid can be estimated separately by each location manager for each device within the corresponding grid data structure. However, in some implementations, devices encountering each other within the environment can communicate (e.g., using beacon signals) to incorporate encounter constraints within their respective probabilities. In some cases, when a device detects a signal from another device above a threshold RSSI or strength, the device can begin tracking the encounter to attempt to determine the device's position relative to the other device. From this information, both devices can improve the speed at which they arrive at a definitive determination of their own location within the grid.

[0045] In one implementation, location managers can model encounter based on a function Φ describing the relation between the probability distributions in the two grids. The potential function <f>(S*, S , z _e ), can indicate how strong the evidence of the encounter event z _e is for which the subject (or device) A and B are at states S ⁴ and S when encountering in a proximity at an arbitrary distance (where / is the time step of device A relative to the device A's starting time stamp and j is the time step of device B relative to the device B's starting time stamp). The probability distribution can be manifest by the following model:

Vb e S ^B , P'(b) = P(6) * P(a') * </>(a', i?, z _e ) where

a' = argmax φ(α, b, z _e )

Va e S ^A

[0046] For any encounter, the respective location manager can determine two component measures, distance and direction. An encounter event can be detected by the devices that support short-range wireless protocols such as BLE. The value of the received signal strength indicator (RSSI) can be used (e.g., by the device's local location manager logic) to estimate the distance between the encounter subjects, for instance, according to:

RSSI[dbm] = -(10n log _a0 d _rssi - A)

[0047] As many wireless communication antennas in loT systems are omnidirectional (particularly in resource-constrained devices), confirming the direction of the encounter subject can be problematic. Indeed, from a single received beacon signal, the location manager may only be able to detect that the encounter subject is somewhere within the range drssi of the received omnidirectional signal (e.g., as indicated by the RSSI), without knowing from which direction. In some implementations, a location manager can possess logic to determine, from multiple received signals from the subject device (when one or both of the receiving device and transmitting device are moving within the environment), the intersection of the two devices (such as represented in FIG. 5). In some implementations, three or more received signals can allow an intersection point to be identified. For instance, given that the relative distances and angles at the first and last encounters can be detected, all other distances to the intersection point (from each other encounter (before or after the intersection) involving the two subjects) can be determined. The intersection point can represent the encounter point with the least relative distance between two subjects (e.g., when the two devices are assumed to be in the same state (i.e., grid cell) at that time). Upon determining the intersection point, an angle β can be calculated (e.g., by the cosine theorem), where the efo and cfe are estimated by the moving distance of each subject through any self- localization (or step-based) algorithms. Accordingly, a value he can be determined representing the moving direction he rotated by angle β (as represented in FIG. 5).

[0048] As noted above, in order to take advantage of the contribution of encounter information derived from signals detected from other devices within an environment, multiple signals are to be detected within a particular window such that a directionality of the signals can be determined. In one example, at least three encounters are to be detected from a single device within a particular time window in order to derive location information from the encounters. As illustrated in FIG. 6A, steps (or other non-M2M location change information) can be detected while M2M encounter signals of other devices are being detected. A location manager can make use of both non-M2M and M2M location information to update the location, or state, of the device within its grid. In the case of 2D encounter geometry, a delayed update may result, as shown in FIG. 6A, if the location manager waits to update state until a sufficient number of encounters (e.g., 605, 610, 615) are detected from a single device. For instance, the location manager of a particular device may not be able to derive any meaningful state updates from one or two encounters (e.g., 605, 610) and will wait until a third encounter occurs before updating the state. However, as illustrated in FIG. 6A, delaying the update until sufficient context for the encounters is received can lead to a latency to, where consideration of intervening steps (or other non-M2M) movements (e.g., 620, 625, 630, 635, 640) are queued until a preceding encounter is resolved (by collecting subsequent encounters 610, 615). For instance, in the example of FIG. 6A, location updates are delayed until a third encounter 615 is received, upon which time the updates corresponding to previous encounters (e.g., 605, 610) and steps (e.g., 620, 625, 630, 635, 640) can also be applied (at 645 following the observation of encounter 615).

[0049] In one implementation, to improve upon the latency introduced by a delayed update of state due to the consideration of M2M encounter information, an alternative example location manager can apply a partially delayed update to location information detected using the location manager. For instance, a partially delayed update can cause state updates based on non-M2M observations (e.g., steps 620, 625, 630, 635, 640) to be processed in order (temporally) as they are detected (i.e., with no delay to the state update), while M2M observations updates (e.g., encounters 605, 610, 615) are incorporated out of order (temporally). This can allow each device's location manager, within a collaborative localization system, to continuously estimate the location of its device based on non-M2M observation while still opportunistically incorporating M2M information on the fly using 2D geometric constraints. Such an approach can dramatically improve latency (tb<«t _a ) as would be experienced through a full delayed update.

(0050] For instance, as shown in FIG. 6B, while a first step 620 (at time = f) may be succeeded by an encounter 605 (at f+1), followed by another step 625 detection (at t+2), and so forth. The first encounter 605, in accordance with partially delayed update, can be queued for later consideration (at 645) (i.e., resulting no immediate state update), while location information obtained in step 625 results in an immediate grid state update based on the step 625 information (effectively ignoring encounter 605). For instance, steps (e.g., 620, 625, 630, 635) can include non-M2M observations detected locally at the device from internal measurement mechanisms, such as accelerometers, compasses, gyroscopes, etc. and identify an assumed distance and direction associated with each step (e.g., 620, 625, 630, 635, 640). In one example, each step (e.g., 620, 625, 630, 635, 640) can be detected and determined to correlate to a human step. Accordingly, the direction of the step and an assumed distance (e.g., the distance of an average human step (e.g., for a particular user of a particular height)) can be estimated to define the dimensions of a location state change from a previous location (as recorded in grid data) corresponding to the step (e.g., 620, 625, 630, 635, 640). As a result, due to the step, the current location of the device, as defined in the grid, can be updated to account for the dimensions of the step.

[0051] Continuing with the example of FIG. 6B, another encounter 610 (e.g., with a particular device (or more accurately a signal sent from the particular device) can be detected, followed by (in this particular example) two more non-M2 steps (e.g., 620, 625, 630, 635, 640) before a third M2M encounter 615 is received. In this example, the location manager can automatically update the device's location status based on each of the steps 630, 635 as they are detected, adding the second encounter 610 to the queue until the third (e.g., the minimum threshold) encounter 615 is detected (at time t+6). Following the detection of the third encounter 615, a location determination can be made (at 650) based on information gleaned in the third encounter 615 within the context of the information gleaned (and stored in the queue) for each of the first (605) and second (610) encounters. Accordingly, upon detection of the three encounters, another update can be made to the device's location grid status, this time based on the encounter information, thereby supplementing and enriching the contributions of the foregoing step-based state updates (e.g., at 620, 625, 630, 635). With the location state updated at time t+6 (based on encounters 605, 610, 615), a subsequent step (e.g., 640), or encounter, can cause an additional update to be made to the grid status. Indeed, once a minimum number of encounters with a particular device in a particular time window or sequence (e.g., three encounters) have been detected, each additional encounter with the particular device can be used to immediately generate another location grid state update. For instance, were a fourth encounter (not shown) with the other device be received following encounter 615, location of the receiving device could be derived using at least encounters 610 and 615, and so on. Indeed, the queue can store information from all or a minimum threshold number of previous encounters (e.g., two previous encounters) with a particular device within a particular time window, and the queue of previous encounter information can be referenced to determine location updates as subsequent encounters are detected. In one implementation, an encounter record can be created for each unique detected sequence of encounters with a given device and the encounter record can be maintained until the encountered device falls out of range of the detecting device, among other implementations. This can represent another example advantage over full updates where not only encounters, but also steps, are to be queued, while waiting for a minimum number of encounters (such as in the example of FIG. 6A).

[0052] As noted, in order to take into account 2D encounter geometry (with relative distances and orientations), a sufficient number of M2M (encounter) observations are to be first obtained. As step events (or other non-M2M movement detections) are encountered, the probabilities of grid states can be transferred by the step events while waiting for encounter-based localization information to develop (e.g., to detect a minimum number of encounter instances with a particular other device. Accordingly, a model can be modified, where ai _as t is the relative encounter point in 5 ^A of b in S ^B that is estimated by the last encounter event (where ai _as t,is the last time step at which device B encounters device A, S ^A is the (grid) state of device A, S ⁸ is the state of device B, and b is the corresponding location of device B), and:

Vb E S ^B , P'(b) = P(b) * P(a' _last ) * (Ka' _last , b, z _e ) where

a'last = α^πιαχ φία^, ^ζ ΐ,' ¹ ^

Va 6 S ^A

Here, the potential function Φ is related to the direction he and the dista nee drssi' It can be defined as a function that is composed of two feature functions (fe and fa) as shown. Additionally, taking measurement errors into consideration, the direction and the distance can be represented (e.g. by location manager logic) as a log-normal distribution. Therefore, the feature functions can be defined:

where the e(S*, S ) and the floor plan.

[0053] In some implementations, in order to reduce time complexity, states falling outside of the encounter range (or outside the finite space tracked by the device's respective location grid) can be ignored. For instance, we can limit the encounter range within a predefined range distance (e.g., 5 meters) and build a look-up table to restore the valid encounter neighbors of each state in advance. With the range of encounters constrained by the dimensions of the grid, the relative probabilities can be calculated beforehand to reduce the computational overhead at runtime. By doing so, the time complexity can be reduced from 0(n ² ) to O(n) (where n is the number of grids) indicating that the time complexity increases asymptotically linearly with the number of grid cells. Overall, an encounter model can be formulated by:

Vb G S ^B , P'(b) = P(b) * P(a' _last ) * <t>{a' _last , b, z _e ) where

a'iast = argmax ψ(α, 6, ζ^)

Va€ encounter neighbors of b in S ^A

(0054] While some of the systems and solution described and illustrated herein have been described as containing or being associated with a plurality of elements, not all elements explicitly illustrated or described may be utilized in each alternative implementation of the present disclosure. Additionally, one or more of the elements described herein may be located external to a system, while in other instances, certain elements may be included within or as a portion of one or more of the other described elements, as well as other elements not described in the illustrated implementation. Further, certain elements may be combined with other components, as well as used for alternative or additional purposes in addition to those purposes described herein.

[0055] Further, it should be appreciated that the examples presented above are non-limiting examples provided merely for purposes of illustrating certain principles and features and not necessarily limiting or constraining the potential embodiments of the concepts described herein. For instance, a variety of different embodiments can be realized utilizing various combinations of the features and components described herein, including combinations realized through the various implementations of components described herein. Other implementations, features, and details should be appreciated from the contents of this Specification.

[0056] FIG. 7A is a simplified flowchart 700a illustrating an example technique for determining a location locally at a device using a combination of a both non-M2M (e.g., steps) and M2M (e.g., encounter) observations. For instance, steps, or other movements, can be detected 705 at a first device based on one or more movement or directional sensors provisioned (internally or externally) on the first device. A location of the first device within a particular environment can be estimated from the detected movement (and can reflect a relative distance estimated from a prior estimated location of the first device). Location information (such as location grid states or probabilities) can be updated 710 to reflect the location estimation based on the detected movement. Signals from other devices within the environment can be detected 715 and also used to improve the location estimates of the first device. For instance, a sequence of signals from a second device can be detected 715. Detection of a first of the detected sequence of signals can precede detection (at 705) of the movement. While the detected movement can lead to an immediate update (710) of the location information, information and results generated from the first signal in the sequence can be queued, or temporally delayed, until a requisite number of signals are detected in the sequence. Each of the signals in the sequence can be used to determine 720 a respective measurement of the distance between the first and second devices at the time the second device sent the corresponding signal. These determined distances can serve as the basis for a location estimation for the first device. Indeed, a location of the first device can be determined 725 from the distances once a threshold number of signals have been received, and the location information can be updated 730 to reflect the estimate.

[0057] While intervening movements detected from local sensors of the first device may lead to corresponding updates of the location information for the first device, contributions from encounters (evidenced by received sequences of signals) can be delayed until a threshold number of signals are received for any one device. Due to the immediate updating of location information based on locally-detected movements (e.g., 705, 710), there may be no latency experienced (e.g., by a user) in the location estimates generated for the first device, at least as it pertains to location changes predicated on the locally-detected movements. Further, after a set of detected movements (e.g., non-M2M observations) interspersed between M2M encounter observations (e.g., detected signal sequences (715)), the first device may make a location determination 735 indicating that the first device has determined, beyond a threshold probability, that the first device is currently within a particular location (e.g., a particular cell of a location grid). Such location determination (and even location estimates) can be shared (through wireless signaling) with other devices in the environment to improve their own location estimates. Further location determinations (e.g., from 735) can be shared with other systems, such as servers of location-based services or an loT management system to manage a system of moving devices, among other example uses. [0058] Turning to FIG. 7B, a flowchart 700b illustrates an example merging (involving encounter-based localization) and managing encounter records in a localization system employing 2D encounter geometry. In determining whether to create, maintain, or discard an encounter record, an loT device can receive a signal 750. Indeed, the device may receive multiple signals from multiple different devices and create concurrent encounter records for each encounter (and make corresponding determinations regarding its location (in a grid) from the encounters. A device identifier can be determined from each of the received signals. Further, the strength of each received signal can be detected to determine 755 whether the device is within a defined encounter range (e.g., in sufficient physical proximity) of the receiving device. This allows a potentially large portion of the received signals to be filtered-out, leaving only the signals of beaconing devices within closest proximity to the device to be assessed. If a signal is determined to fall outside of the defined range (e.g., a particular RSSI value or physical distance value inferred from RSSI values, etc.), the location manager can determine (at 760) whether an active encounter record exists for the identified transmitting device. If no active encounter record exists, the signal can be ignored. If an encounter does exist however, updates to the location state based on the signal can be delayed 765 (e.g., until sufficient encounter readings have been obtained to allow for an encounter-based localization estimate (e.g., as in FIG. 6B)). If the signal is determined (at 755) to be within the defined encounter range, an active encounter record can be created for the encounter if one has not already been created, and information concerning the corresponding signal from the encountered device can be recorded 770 within the record. If insufficient subsequent encounters are detected, or if the location manager is otherwise unable to determine an intersection point between the encountered device and receiving device, the encounter record can be abandoned. Likewise, encounter records can be dropped if a given device move outside of the encounter range (e.g., for a threshold amount of time or unit intervals). Should this same device back into the encounter range after the abandonment of a previous encounter record, a new active encounter record can be generated. In either instance, an active encounter record can be used to track each of the encounters in a sequence of encounters with a device to allow 2D location information to be generated based on the encounter information, such as discussed herein. [0059] FIGS. 8-9 are block diagrams of exemplary computer architectures that may be used in accordance with embodiments disclosed herein. Other computer architecture designs known in the art for processors and computing systems may also be used. Generally, suitable computer architectures for embodiments disclosed herein can include, but are not limited to, configurations illustrated in FIGS. 8-9.

[0060] FIG. 8 is an example illustration of a processor according to an embodiment. Processor 800 is an example of a type of hardware device that can be used in connection with the implementations above. Processor 800 may be any type of processor, such as a microprocessor, an embedded processor, a digital signal processor (DSP), a network processor, a multi-core processor, a single core processor, or other device to execute code. Although only one processor 800 is illustrated in FIG. 8, a processing element may alternatively include more than one of processor 800 illustrated in FIG. 8. Processor 800 may be a single-threaded core or, for at least one embodiment, the processor 800 may be multithreaded in that it may include more than one hardware thread context (or "logical processor") per core.

[0061] FIG. 8 also illustrates a memory 802 coupled to processor 800 in accordance with an embodiment. Memory 802 may be any of a wide variety of memories (including various layers of memory hierarchy) as are known or otherwise available to those of skill in the art. Such memory elements can include, but are not limited to, random access memory (RAM), read only memory (ROM), logic blocks of a field programmable gate array (FPGA), erasable programmable read only memory (EPROM), and electrically erasable programmable ROM (EEPROM).

[0062] Processor 800 can execute any type of instructions associated with algorithms, processes, or operations detailed herein. Generally, processor 800 can transform an element or an article (e.g., data) from one state or thing to another state or thing.

[0063] Code 804, which may be one or more instructions to be executed by processor 800, may be stored in memory 802, or may be stored in software, hardware, firmware, or any suitable combination thereof, or in any other internal or external component, device, element, or object where appropriate and based on particular needs. In one example, processor 800 can follow a program sequence of instructions indicated by code 804. Each instruction enters a front-end logic 806 and is processed by one or more decoders 808. The decoder may generate, as its output, a micro operation such as a fixed width micro operation in a predefined format, or may generate other instructions, microinstructions, or control signals that reflect the original code instruction. Front-end logic 806 also includes register renaming logic 810 and scheduling logic 812, which generally allocate resources and queue the operation corresponding to the instruction for execution.

[0064] Processor 800 can also include execution logic 814 having a set of execution units 816a, 816b, 816n, etc. Some embodiments may include a number of execution units dedicated to specific functions or sets of functions. Other embodiments may include only one execution unit or one execution unit that can perform a particular function. Execution logic 814 performs the operations specified by code instructions.

[0065] After completion of execution of the operations specified by the code instructions, back-end logic 818 can retire the instructions of code 804. In one embodiment, processor 800 allows out of order execution but requires in order retirement of instructions. Retirement logic 820 may take a variety of known forms (e.g., re-order buffers or the like). In this manner, processor 800 is transformed during execution of code 804, at least in terms of the output generated by the decoder, hardware registers and tables utilized by register renaming logic 810, and any registers (not shown) modified by execution logic 814.

[0066] Although not shown in FIG. 8, a processing element may include other elements on a chip with processor 800. For example, a processing element may include memory control logic along with processor 800. The processing element may include I/O control logic and/or may include I/O control logic integrated with memory control logic. The processing element may also include one or more caches. In some embodiments, non-volatile memory (such as flash memory or fuses) may also be included on the chip with processor 800.

[0067] FIG. 9 illustrates a computing system 900 that is arranged in a point-to-point (PtP) configuration according to an embodiment. In particular, FIG. 9 shows a system where processors, memory, and input/output devices are interconnected by a number of point-to- point interfaces. Generally, one or more of the computing systems described herein may be configured in the same or similar manner as computing system 900.

[0068] Processors 970 and 980 may also each include integrated memory controller logic (MC) 972 and 982 to communicate with memory elements 932 and 934. In alternative embodiments, memory controller logic 972 and 982 may be discrete logic separate from processors 970 and 980. Memory elements 932 and/or 934 may store various data to be used by processors 970 and 980 in achieving operations and functionality outlined herein.

[0069] Processors 970 and 980 may be any type of processor, such as those discussed in connection with other figures. Processors 970 and 980 may exchange data via a point-to-point (PtP) interface 950 using point-to-point interface circuits 978 and 988, respectively. Processors 970 and 980 may each exchange data with a chipset 990 via individual point-to-point interfaces 952 and 954 using point-to-point interface circuits 976, 986, 994, and 998. Chipset 990 may also exchange data with a high-performance graphics circuit 938 via a high-performance graphics interface 939, using an interface circuit 992, which could be a PtP interface circuit. In alternative embodiments, any or all of the PtP links illustrated in FIG. 9 could be implemented as a multi-drop bus rather than a PtP link.

[0070] Chipset 990 may be in communication with a bus 920 via an interface circuit 996. Bus 920 may have one or more devices that communicate over it, such as a bus bridge 918 and I/O devices 916. Via a bus 910, bus bridge 918 may be in communication with other devices such as a user interface 912 (such as a keyboard, mouse, touchscreen, or other input devices), communication devices 926 (such as modems, network interface devices, or other types of communication devices that may communicate through a computer network 960), audio I/O devices 914, and/or a data storage device 928. Data storage device 928 may store code 930, which may be executed by processors 970 and/or 980. In alternative embodiments, any portions of the bus architectures could be implemented with one or more PtP links.

[0071] The computer system depicted in FIG. 9 is a schematic illustration of an embodiment of a computing system that may be utilized to implement various embodiments discussed herein. It will be appreciated that various components of the system depicted in FIG. 9 may be combined in a system-on-a-chip (SoC) architecture or in any other suitable configuration capable of achieving the functionality and features of examples and implementations provided herein.

[0072] Although this disclosure has been described in terms of certain implementations and generally associated methods, alterations and permutations of these implementations and methods will be apparent to those skilled in the art. For example, the actions described herein can be performed in a different order than as described and still achieve the desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve the desired results. In certain implementations, multitasking and parallel processing may be advantageous. Additionally, other user interface layouts and functionality can be supported. Other variations are within the scope of the following claims.

[0073] While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any inventions or of what may be claimed, but rather as descriptions of features specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0074] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0075] The following examples pertain to embodiments in accordance with this Specification. One or more embodiments may provide a method, a system, a machine readable storage medium with executable code to detect, using sensors provisioned on a first device, a movement of the first device, wherein the movement causes the first device to change position within an environment, update location information for the first device based on the position change, detect, at the first device, a plurality of signals from a second device in the environment, determine, for each of the plurality of signals, a distance between the first and second devices when the respective signal was sent by the second device, determine, from the plurality of signals, another change in position of the first device within the environment, and update location information for the first device based on the other change in position. The movement can be detected at the first device at an instance between two of the plurality of signals, and location information for the first device based on the first position change can be updated prior to detection of the later of the two signals in the plurality of signals.

[0076] In one example, the other change is determined in response to detecting that a particular one of the plurality of signals from the second device exceeds a minimum threshold amount.

[0077] In one example, the minimum threshold amount corresponds to a minimum number of distances between the first and second devices, determined from the plurality of signals, required to determine a location of the first device from the distances.

[0078] In one example, data describing signals preceding the particular signal are queued at least until detection of the particular signal.

[0079] In one example, updating the location information comprises updating states within a location grid corresponding to the environment.

[0080] In one example, updating the location information comprises determining, for each of a plurality of cells of the location grid, a probability that the first device is present in the cell based on a respective location estimate by of the first device.

[0081] In one example, the first device generates a location estimate corresponding to each of the first and second changes in position.

[0082] In one example, a particular device identifier is identified in each of the plurality of signals to attribute the plurality of signals to the second device.

[0083] In one example, at least one other signal from a third device in the environment is detected to determine, from the other signal, whether the third device is within a threshold distance of the first device.

[0084] In one example, an encounter record can be generated for the third device to track encounters with the third device based on the third device being within the threshold distance. [0085] In one example, the encounter record for the third device can be discarded based on determining that the distance between the first and third devices has grown beyond the threshold distance.

[0086] In one example, signals can be transmitted within the environment, wherein the transmitted signals are usable by other devices in the environment to identify their respective locations within the environment.

[0087] In one example, at least some of the transmitted signals advertise a determined location of the first device.

[0088] In one example, the determined location is based at least in part on the updates to the location information based on the movement and the plurality of signals from the second device.

[0089] In one example, an initial location of the first device within the environment is estimated.

[0090] In one example, estimating the initial location comprises detecting signals from a plurality of stationary transmitters with known locations in the environment and generating the estimate based at least in part on detected strengths of the signals of the stationary transmitters while the first device is in the initial location.

[0091] In one example, estimating the initial location comprises determining a radio frequency fingerprint and identifying a particular location within the environment associated with the fingerprint.

[0092] One or more embodiments may provide an apparatus (and system including the apparatus), where the apparatus includes at least one processor, computer memory, at least one antenna to receive and transmit radio frequency signals, at least one movement sensor to detect movement of the apparatus, at least one direction sensor to detect orientation of the apparatus, and a location manager. The location manager can be executable by the processor to detect, using the movement and direction sensors, a change in position of the apparatus within an environment, update location information based on the position change, detect, using the antenna, a sequence of signals from a particular device in the environment, determine, for each of the sequence of signals, a distance between the apparatus and the particular corresponding to instances when each respective signal was sent by the particular device, determine, from the plurality of signals, another change in position of the apparatus within the environment, and update the location information based on the other change in position. The movement can be detected at an instance between two of the sequence of signals, and location information corresponding to the first position change can be updated prior to detection of the later of the two signals in the sequence of signals.

[0093] In one example, the memory stores location grid data corresponding to the environment, and updating the location information includes updating state within the location grid data.

[0094] In one example, the memory stores a plurality of encounter records, each of the encounter records corresponds to a respective sequence of signals received at the antenna from a corresponding one of a plurality of other devices in the environment, and each encounter record identifies the respective sequence of signals as detected at the apparatus.

[0095] In one example, the apparatus further includes at least one of a sensor to sense attributes of the environment or an actuator to cause an action within the environment.

[0096] In one example, the apparatus further includes a motor to drive automatic movement of the apparatus within the environment.

[0097] In one example, the apparatus further includes one of a wearable device, a personal computing device, and a drone device.

[0098] In one example, a system may also include a server to host location-based services based on the location information.

[0099] In one example, a system may also include the other device.

[00100] In one example, the device and other device are deployed to interoperate in a machine-to-machine network.

[00101] Thus, particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results.