[go: up one dir, main page]

WO2013009880A1 - Systèmes intelligent de transport tenant compte de la localisation - Google Patents

Systèmes intelligent de transport tenant compte de la localisation Download PDF

Info

Publication number
WO2013009880A1
WO2013009880A1 PCT/US2012/046265 US2012046265W WO2013009880A1 WO 2013009880 A1 WO2013009880 A1 WO 2013009880A1 US 2012046265 W US2012046265 W US 2012046265W WO 2013009880 A1 WO2013009880 A1 WO 2013009880A1
Authority
WO
WIPO (PCT)
Prior art keywords
nodes
sub
group
node
solutions
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2012/046265
Other languages
English (en)
Inventor
Geoffrey B. Rhoads
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Digimarc Corp
Original Assignee
Digimarc Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Digimarc Corp filed Critical Digimarc Corp
Publication of WO2013009880A1 publication Critical patent/WO2013009880A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/023—Services making use of location information using mutual or relative location information between multiple location based services [LBS] targets or of distance thresholds
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S5/00—Position-fixing by co-ordinating two or more direction or position line determinations; Position-fixing by co-ordinating two or more distance determinations
    • G01S5/02—Position-fixing by co-ordinating two or more direction or position line determinations; Position-fixing by co-ordinating two or more distance determinations using radio waves
    • G01S5/0284—Relative positioning
    • G01S5/0289—Relative positioning of multiple transceivers, e.g. in ad hoc networks
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/07—Controlling traffic signals
    • G08G1/08—Controlling traffic signals according to detected number or speed of vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W64/00—Locating users or terminals or network equipment for network management purposes, e.g. mobility management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Definitions

  • This disclosure is related to object positioning systems.
  • this disclosure is related to location awareness for vehicles and transportation systems.
  • GPS global positioning system
  • DSRC Short-Range Communications
  • VI Vehicle Infrastructure Integration
  • National VII Coalition is a relatively recent technical and community synthesis effort aimed at coalescing many of these powerful macro-development trends in the 21 st century transportation industry.
  • the general notion is that vehicles and the infrastructure need to become coordinated and develop together as an overall system.
  • This disclosure addresses the requirement for better realtime raw data.
  • this disclosure outlines several specific applications that become enabled once a reliable supply of vehicle position data becomes readily available to networks.
  • a location aware intelligent transportation system determines ranges between a plurality of communication devices, including at least one mobile communication device.
  • a method includes receiving, at the mobile communication device, receive messages transmitted from a plurality of other communication devices. Each receive message includes a transmit count stamp corresponding to a remote counter value at the transmission of the receive message from the corresponding other communication device. The mobile communication device generates a receive count stamp for each receive message corresponding to a local counter value at the receipt of the receive message. As the mobile communication device travels along a path relative to the plurality of other communication devices, the method includes dynamically associating and disassociating the mobile communication device with a plurality of sub-groups of the plurality of other communication devices.
  • the associating and disassociating are based at least in part on receiving receive messages from a predetermined number of other communication devices for each sub-group.
  • the method includes generating range estimates between the mobile communication device and the other communication devices in the particular sub-group. The range estimates are based on a combination of the transmit count stamps and the receive count stamps.
  • the disclosure describes various aspects of invention relating to timing and positioning of device nodes in mobile and ad hoc networks.
  • One such aspect is a method of propagating timing through a network that comprises overlapping sub-groups of nodes. For each of the sub-groups, the method gathers count stamps for messages transmitted between nodes in the subgroup over a period of time. From the count stamps gathered for a first sub-group, the method determines differential clock solutions for corresponding clocks in nodes of the first sub-group, where the differential solutions provide a relative timing solution between nodes of the first sub-group. Similarly, differential solutions are determined for nodes in a second sub-group.
  • the method diffuses a differential timing solution between nodes belonging only to the first sub-group and nodes belonging only to the second, through clock solutions for nodes shared between the first and second sub-groups.
  • Another aspect of invention is a method of determining a ranging estimate between nodes in a network.
  • differential solutions are determined for nodes in at least first and second sub-groups.
  • the method determines a range estimate for a range between a first node only in the first subgroup and a second node only in the second sub-group without transmitting a message between the first node and the second node.
  • a method of determining a ranging estimate between nodes in a network determines differential solutions for nodes in at least first and second sub-groups. It determines a range estimate between a first node only in the first sub-group and a second node only in the second sub-group by passing a single packet message between the first node and second node.
  • Another aspect of the invention is a method of positioning of a mobile device.
  • the method tracks associations between the mobile device and nodes in the first and second subgroups. For each of the sub-groups, the method gathers count stamps for messages transmitted between nodes in the sub-group over a period of time. From the count stamps gathered for a first sub-group, the method determines differential clock solutions for corresponding clocks in nodes of the first sub-group. From the count stamps gathered for a second sub-group, the method also determines differential clock solutions for corresponding clocks in nodes of the second sub-group. The method determines range estimates between the mobile device and nodes in the first and second sub-groups from which the position of the mobile device is determined.
  • FIG. 1 is a schematic diagram illustrating vehicles and pedestrians traveling within a simplified urban grid of streets according to one embodiment.
  • FIG. 2 is a schematic diagram illustrating fixed nodes and mobile nodes of a local group corresponding to an intersection of two streets according to one embodiment.
  • FIG. 3 is a schematic diagram illustrating relationships between neighboring local groups according to one embodiment.
  • FIG. 4 is a schematic diagram illustrating an instantaneous view of an example "linq list" for a node manager (called the AlphaDawg ) that manages a dynamic group of nodes according to one embodiment.
  • FIG. 4A is a schematic diagram illustrating a rx-only mobile node, according to one embodiment, that only listens to ZTChatter yet can nevertheless become fully enabled to determine its ongoing position.
  • FIG. 4B is a schematic diagram illustrating a tx-only mobile node according to one embodiment.
  • FIG. 5 is a schematic diagram illustrating an example of a full-duplex embodiment, to describe practical considerations of how a given vehicle participates in an overall scheme.
  • FIG. 6 is a schematic diagram illustrating the concept of "topographic oozing" according to one embodiment.
  • FIG. 7 is a schematic diagram illustrating the concept of Zulutime according to certain embodiments.
  • FIG. 8 is a schematic diagram illustrating that each node manager is free to choose its own definition of local Zulutime for its local group according to one embodiment.
  • FIG. 8A is a schematic diagram illustrating vehicle A sending out a count- stamped message "M" at some instance according to the example embodiment of FIG. 8.
  • FIG. 8B is a schematic diagram illustrating a situation where some random separate node B hears message M sent out by vehicle A according to the example embodiment of FIG. 8.
  • FIG. 8C is a schematic diagram illustrating respective vehicles in motion according to the example embodiment of FIG. 8.
  • FIG. 8D is a schematic diagram illustrating a moment in time a few seconds before message M is sent out by vehicle A, as shown in FIG. 8A.
  • FIG. 8E is a schematic diagram illustrating that all the nodes in the local group are likewise receiving messages all the time according to the example embodiment of FIG. 8.
  • FIG. 8F is a schematic diagram illustrating a large number of messages sent and received by nodes in the local group and organized into linear equations according to the example embodiment of FIG. 8.
  • FIG. 8G is a schematic diagram illustrating the solution vector f according to the example embodiment of FIG. 8.
  • FIG. 8H is a schematic diagram illustrating a culmination of the previous steps according to the example embodiment of FIG. 8.
  • FIG. 81 is a schematic diagram illustrating a summary of the example embodiment of FIG. 8.
  • FIG. 9 is a schematic diagram illustrating use of a GPS receiver to maintain a link to global time standards according to one embodiment.
  • FIG. 9A is a schematic diagram illustrating diffusion of GPS time as a function of cross-group memberships according to the embodiment of FIG. 9.
  • FIG. 9B is a schematic diagram illustrating the receive only mode shown in FIG. 4A according to the embodiment of FIG. 9.
  • FIG. 10 is a schematic diagram illustrating enhancement of traffic flow management according to certain embodiments.
  • FIG. 1 1 is a schematic diagram illustrating an example embodiment within a medium sized shopping store.
  • FIG. 12 is a schematic diagram illustrating effectively the same store layout as that shown in FIG. 1 1 , but with a total of 30 additional WiFi devices strewn throughout the store according to one embodiment.
  • FIG. 13 is a schematic diagram illustrating the shopping store of FIG. 12 with a newly introduced mobile WiFi device somewhere near the entrance of the store according to one embodiment.
  • FIG. 14 is a schematic diagram illustrating a packet transmitted from newly introduced mobile WiFi device shown in FIG. 13 according to one embodiment.
  • FIG. 15 is a schematic diagram illustrating a more typical but more complicated situation, according to certain embodiments, where there are now dozens of mobile devices in the store all transmitting packets.
  • FIG. 16 is a schematic diagram illustrating three instances in time of a single mobile device as it moves among different areas of the store according to one embodiment.
  • FIG. 17 is a schematic diagram illustrating an advanced variant, according to one embodiment, on the baseline description for the examples shown in FIGS. 1 1 , 12, 1 3, 14, 1 5, and 16. Detailed Description of Preferred Embodiments
  • equipping vehicles with wireless communication capabilities is an up and coming technology.
  • the combination of the two in, for example, real-time traffic flow measurement and traveler updating, is becoming broadly available.
  • the disclosure herein prescribes an approach to taking a next step in location awareness for vehicles and the transportation infrastructure, ensuring that any vehicle will know where it is at anytime, anywhere, with a precision and reliability much greater than is possible with GPS, all at a lower cost than GPS.
  • "Opt-in" incentives for a given vehicle to share its position information within a network enable a wide range of applications that benefit the vehicle driver and/or commercial owner, as well as society in general, most notably in reduced fuel consumption and potentially radically reduced operating costs. Anonymous and/or receive-only configurations are also described.
  • this disclosure includes a simple goal of allowing every vehicle to know where it is to sub-meter accuracy, 24/7 (e.g., approximately 24 hours a day, 7 days a week), and to do so with the highest reliability possible and the lowest cost possible.
  • GPS- device implementations within vehicles may co-exist with GPS- device implementations within vehicles. Certain embodiments may be considered as a parallel on-vehicle positioning system, where GPS and INS (Inertial Navigation Systems) have already shown the value of redundancy and cooperation in the raw- data production side of knowing one's location.
  • GPS and INS Inertial Navigation Systems
  • the related disclosures refer to certain aspects as "PhaseNet” technology.
  • the basic idea is that the very act of one communicating device passing a normal message to another device can, after a relatively small number of networked messages being sent to and fro in a network, be used to produce a distance
  • This disclosure's implementation within transportation infrastructures and vehicles is likewise, by design, highly configurable.
  • DSRC efforts in particular are described as an example platform embodiment, not at all to suggest that other communication platforms are not equally capable of supporting the embodiments disclosed herein.
  • the usefulness of describing DSRC as an example embodiment for this disclosure has multiple aspects: there is plenty of public domain materials describing how this system works; there are plenty of articulated visions of what this system can do once a good, reliable positioning system is in place (where GPS is already being used to provide early examples); and there is good reason to believe that DSRC or something very much like it will be a widely deployed technology over the next decade.
  • this disclosure provides details of deploying certain embodiments within the DSRC umbrella framework.
  • DSRC may not simply be a system that enables communication, it enables positioning at the same time. This end result may be an issue of standards creation rather than one of prototyping and building early deployments, but if it can be done and it proves to be the de facto lowest cost approach to do it, one way or another it will be done, be it in a few years or over a decade.
  • reference to a "communications network” may also refer to a "positioning network.”
  • This disclosure may be referred to as a Location Aware Intelligent
  • Transportation System Evolved properly, and the term "location aware" may quickly become apparent from the disclosure herein to the next generation of transportation engineers graduating from the many schools that now have extensive programs in transportation system understanding and development. These two words could then be conveniently dropped off, getting back to the current ITS acronym and a historical footnote that there was an early few-year period where a need existed to be explicit that there were differences between systems that did and did not know where they were.
  • DSRC Short-Range Communications
  • a vehicle includes a device on-board that sends and/or receives signals. This is part of DSRC, where a duplex 5.9 GHz band vehicle-to-vehicle, vehicle-to-infrastructure and infrastructure- to-infrastructure communication system may be used.
  • Step one is to select a specific DSRC communication hardware approach and to determine how to "ping enable" the underlying chosen hardware.
  • the following discussion treats the word “device” generically, not worrying about whether a communications device is on a vehicle or in the non-mobile infrastructure, e.g. a traffic light.
  • Ping enablement involves studying the specifics of how messages are sent and received on the chosen hardware device, and then determining an optimal approach to perform simple count-stamping (described further below) on outgoing and incoming messages.
  • the related disclosures have described ping enablement at length: a ping driver, a component of software that interacts as closely as possible with the lowest level radio frequency (RF) circuitry and whose software execution is generally accomplished either by a low-level dedicated CPU within a
  • RF radio frequency
  • One task of the ping driver is to "count-stamp" either all outgoing and/or transmitted messages, or some specific fraction of outgoing messages.
  • the hardware includes some existing free running counter, which virtually all modern communication devices have, typically “tied” to a CPU's clock or some local oscillator, i.e., harmonically locked to some clock/oscillator as is well understood in the art.
  • the counter counts, at some points hitting a count limit and resetting to zero, but generally incrementing its internal instantaneous discrete value by one, as driven by an oscillatory signal.
  • a task of the ping driver is to fetch a discrete count value from the counter at some pre-specified point in an outgoing message's processing sequence.
  • the count value is fetched at some pre-designed specific point in the processing of an outgoing message.
  • the outgoing message generally has some discrete index value associated with that particular message, e.g., message #4385, which then might be followed roughly 90 milliseconds later by message #4386, and then roughly another 60 milliseconds later by message #4387, etc.
  • a task of ping driver is to fetch a counter value and associate that value with the outgoing message unique identifier.
  • Another task of the ping driver is to either store sequences of these count/ID pairs and report them to a higher level process in batches, or to simply report up count/ID pairs as they occur.
  • Another task of the ping driver is to perform substantially the identical count-stamping task on either or both of: a) received messages from other nodes, whereby the entire message is sensed and properly decoded; or b) messages sent from other nodes that may not necessarily be intended to be fully decoded by the receiver, but which the receiver can nevertheless "partially decode” for the purposes of extracting a received ping count stamp.
  • the basic idea is that all received data is good data, and even if a given vehicle is having a direct data communication exchange with some infrastructure node that is not intended for other vehicles, other vehicles can nevertheless benefit from simply "partially listening in” on at least the ping-aspects of the communications going on.
  • each participating node in a transportation system includes a ping driver as described in the previous section, which may be controlled by a main software program functioning on the device.
  • This main program is described in the related disclosures, and this disclosure discusses its particular implementation in highly dynamic transportation applications.
  • topographic oozing or “topographic dynamics”.
  • topographic dynamics At a philosophical level, it is in the same category as “hand-offs" in the cell industry.
  • a basic requirement is that a mobile client needs to experience smooth and reliable levels of service even as it travels through a thicket of fixed server locations.
  • One embodiment tasks the vehicle-client with continual searching for at least two separate local groups to belong to, and possibly three or even more.
  • local groups will be described further below and in the figures, but suffice it to say in this summary that they represent highly dynamic local webs of connections that coalesce in a temporarily cooperative group, and each node in general is encouraged to belong to several groups at the same time.
  • the core software is designed to not only accommodate this but encourage it.
  • FIG. 1 is a schematic diagram illustrating vehicles and pedestrians traveling within a simplified urban grid of streets according to one embodiment.
  • the essence of the underlying networking topologies and dynamics nicely extrapolate to suburban settings and intertwined-highway settings as well, and hence the following material equally applies to these settings.
  • Flow-Volume and Flow-Vector-Weighting can greatly enhance traffic flow management algorithms which have largely been developed around statistical flow timing and magnetic sensors in the pavement.
  • Anonymous Opt-in' participation by mobile nodes, incentivized by self-interest, ensures a high enough sampling of actual vehicular and pedestrian flow to produce quantifiable reductions in fuel consumption and emissions for all mobile traffic.
  • certain embodiments include two fixed nodes per intersection (see, e.g., FIG. 2).
  • Traffic lights for example, may be used fixed nodes, as several companies are already targeting this equipment for communication system deployment.
  • the choice of two fixed nodes per intersection, over having just one, is only a choice of prudence and redundancy, with the presumption that these devices may become inexpensive as commoditization pressures reign.
  • one fixed node per intersection is sufficient. Any location with a reasonable line-of-sight communication view of the street corridor can be used for the one or more fixed nodes.
  • FIG. 1 also limits the number of graphically depicted moving vehicles to simply keep things uncluttered but illustrative. Although not shown in FIG. 1 , the various nodes (devices corresponding to the vehicles, pedestrians, and fixed nodes) are in sporadic communications with various other nodes, typical of a communication network. Later figures will attempt to graphically show a few examples of this.
  • FIG. 2 is a schematic diagram illustrating fixed nodes 100 (represented by squares) and mobile nodes 105
  • FIG. 2 is an over-simplified but clear depiction of an instant in time where a given local group is in operation, associated with the intersection of Wall Street and Main Street.
  • FIG. 2 highlights the distinction between nodes/devices 100 in a transportation network that are largely fixed and are generally part of the so-called infrastructure (shown as squares), and nodes/devices 105 that are the mobile participants in the transportation system (shown as circles), generally the vehicles.
  • one particular node has been configured to take on the temporary role of node manager, called the "AlphaDawg" 1 15.
  • Any node in the group can play this managing role, and indeed, its tasking may be equally shared amongst the group in certain embodiments. But, for simplicity reasons it is practical to assign to one node certain organizing tasks and the bottom line role of trying to maintain the health and functioning of the local group associated with the
  • the related disclosures go into more details on the tasking involved with instantiating and maintaining a local group.
  • the node 1 15 serving as node manager is in charge of initiating a group session, beginning and maintaining a certain level of communications traffic forming the minimum
  • FIG. 2 depicts a node 120 serving as backup to the node manager.
  • the backup node 120 is ready to take over at a moment's notice, typically within one tenth of a second or sooner, if something goes wrong with the managing node 1 15. Even in such switches, raw ping data is still being collected by all nodes and any such changes in group management will not affect the ability to produce ongoing solutions and associated solution error ellipsoids.
  • FIG. 3 is a schematic diagram illustrating relationships between neighboring local groups (schematically defined by respective ellipses) according to one embodiment.
  • each intersection's Fixed Nodes not only define and manage their own local group, they also participate as non-manager nodes in neighboring local groups.
  • FIG. 3 shows that the neighboring fixed nodes are explicitly included in Wall and Main's local group, even though they themselves are the anchor (manager or "AlphaDawg") nodes for their own respective intersections.
  • the two fixed nodes at Wall and Main are non-managing members in four other local groups, e.g.
  • FIG. 4 is a schematic diagram illustrating an instantaneous view of an example 'linq list' for the node manager according to one embodiment. This diagram depicts a snapshot in time of the active, duplex communications between the local group's current node manager and other members of the local group.
  • the lines depicted show that the managing node currently believes that it has active communications with (or, alternatively, some form of receive (rx)-only, transmit (tx)- only or rx/tx signaling relationship with) fifteen (15) other nodes within the context of its Wall and Main local group, and it believes that all communications are in good working order.
  • FIG. 4 uses the word "duplex" to describe the active linqs. This only represents one embodiment and does not at all need to be the actual case in every embodiment. Indeed, a combination of monoplex and duplex channels can be accommodated, whereby individual nodes can still determine their positions.
  • FIG. 4A is a schematic diagram illustrating a rx-only mobile node 145 (represented by a triangle) according to one embodiment that only listens to ZTChatter yet can nevertheless become fully enabled to determine its ongoing position. Receive-only participation is entirely possible.
  • the triangle icon node 145 is simply listening to all the "public domain" ZT Chatter within the Wall and Main local group, gathering sufficient information to rapidly determine its position. If the rx-only mobile node 145 is just listening to other communications and not itself
  • H matrices can be formed using one-way channels alone, unknowns to the various entities can be created, and position solutions can be formed.
  • 4A represents a sub-class of this disclosure, where if certain municipalities so choose for whatever reasons, they can set up their infrastructure nodes to be broadcast-only nodes, all either actively synchronized to GPS directly or post-facto synchronized to GPS through ongoingly broadcast DZT solutions.
  • Such a solution has less ultimate power and less flexibility than the full duplex version of the disclosure, but it has the virtue that it can be made to work in early pilot projects and to require very little in the way of standardization.
  • Clients in such a system look more and more like GPS receivers, except that they are tuned to whatever frequency and communication protocols are chosen for the municipal beacon system. The number crunching they need to perform in order to derive their positions may require treating their own internal clock as an unknown, just like in GPS receivers.
  • FIG. 4B is a schematic diagram illustrating a tx-only mobile node 155 (represented by a pentagon symbol) according to one embodiment.
  • Transmit-only (TX-only) nodes are also quite supportable. Either just a managing node or the entire group can choose to acknowledge and/or utilize the information inherent in the short ping chirps emanating from the TX-only node. It may or may not become a virtual member of the local group, all depending on the application and how node manager runs the local group.
  • FIG. 4B is a kind of polar opposite situation to that depicted in FIG. 4A. In FIG. 4B, the tx-only mobile node 155 simply chatters away in a pre-defined way (see note 160 in FIG.
  • FIG. 4B uses the word 'chirp' as well, though the idea is that the chirping in question conforms to some pre-defined communication standard, presumably the same or similar standard as is used within the local group's communication protocol.
  • a plurality of nodes such as node 1 55 all chirping away, then that might become a whole lot of asynchronous chirping cacophony with chirps potentially conflicting with each other.
  • chirping circuitry may at the very least have very basic receiving circuitry that can hear other chirps for the purpose of scheduling its own chirps (minimizing contention and overlaps of chirps). All of these options can be accommodated by the primary PhaseNet software running on the local group members (or just the fixed node members, listening for the chirps).
  • such a system may become an opt-in, anonymous, and pro-active replacement to magnetic loops in pavement announcing the coming of going of vehicles.
  • this embodiment denies certain broader capabilities of the full duplex version depicted in FIG. 4 and earlier described, but it too has the advantage that it can simply work, and pilot projects or early deployments can minimize the requirements for inter-operability that otherwise come with the more powerful full duplex version.
  • the so-called chirping device inside the vehicle may be very inexpensive, on the order of a dime or two for a throw-away, postage-sized package.
  • infrastructure nodes are attuned to the chirping, count-stamp the incoming chirp messages, and follow the prescribed methods of calculating position solutions for the variously sensed chirpers. What these fixed infrastructure nodes do with these identifications and positioning of chirpers is wide open, beginning as it might with assistance in controlling traffic light signaling. This is the tip of the iceberg of course, and a reasonable subset of the broader benefits of this disclosure can also accrue to this transmit-only device architecture.
  • each can system can indeed function within their respective limitations.
  • This disclosure will continue to focus on the full suite of capabilities of the duplex model of device communications. It may inevitable that certain applications will for one reason or another gravitate toward non-full-duplex implementations, including rx-only and tx-only implementations. For example, military or intelligence applications may require certain rx-only implementations for classic covert reasons.
  • This disclosure's continued discussion on the full duplex system is only for the purpose of describing the full duplex embodiment and should not be construed as weighted toward expected deployed solution configurations.
  • the combination of duplex/monoplex embodiments mentioned earlier, and fully supported by PhaseNet core software, is expected to be extensively utilized in practice.
  • FIG. 5 is a schematic diagram illustrating an example of a full-duplex embodiment to describe practical considerations of how a given vehicle participates in an overall scheme.
  • FIG. 5 is the graphic representation of the linq list for a chosen vehicle A 162. See note 165 in FIG. 5.
  • vehicle A 1 62 in the local group only has a duplex relationship with a sub-set of members of the Wall and Main local group, represented by the straight lines connecting the vehicle to other nodes. These lines generally represent that two nodes are actively exchanging and mutually count- stamping pings.
  • Vehicle A 162 can communicate pings with all nodes along Main street, including the fixed nodes behind it and the fixed nodes at the intersection beyond Wall street. It also found a way to sneak around the corner and establish an ephemeral ping-exchange with another vehicle on Wall street, a clear example of a multipath signal 180.
  • Note 170 in FIG. 5 asks us to take particular note that in this full embodiment example, vehicles indeed communicate pings with each other, not just the fixed infrastructure node.
  • Note 175 in FIG. 5 brings up the notion familiar to GPS engineers of "geometric diversity" of linqs. In any triangulation situation, it is ideal to be receiving pseudo-range estimations from all directions. But, clearly in the case of an urban street corridor, the resulting geometric diversity is highly constrained at best.
  • a depiction of the ellipse surrounding the vehicle 1 62 graphically indicates a resulting asymmetry of error in position estimation caused by this geometric concentration of pseudo-ranges along the street axis but not along the perpendicular axis.
  • An aspect of this disclosure is that the error geometry, also known as Dilution Of Precision or DOP in the GPS world, is constantly being estimated right alongside the position estimates themselves. For certain applications such as collision avoidance or forensic accident analysis (as but two of many applications), this estimation of error is very useful.
  • FIG. 5 a hypothetical graphic is shown to illustrate how an electromagnetic signal between vehicle A 162 and a vehicle travelling on Wall street might still establish communications even though they are not in a line-of-sight relationship with each other.
  • An entire separate related disclosure is devoted to the topic of multipath, where for this disclosure's purposes, suffice it to say that such linqs are still quite useful to improving the overall quality of position solutions for the group, so long as they are treated appropriately in the solution software routines and not treated as line-of-sight linqs.
  • the related multipath disclosure describes ways to discover the difference between multipath signals and line of sight signals.
  • Vehicle A 162 can participate as a member in three separate local groups if it so chooses. For example, vehicle A might participate in up to three separate local groups defined by the three intersections it is in contact with. The local group on Wall and Main depicted in FIG. 2, but also the local groups defined by the two other intersections along Main Street. As discussed herein, there is no reason in certain embodiments to limit the number of group associations to only three.
  • FIG. 6 is a schematic diagram illustrating the concept of "topographic oozing" according to one embodiment.
  • Topographic Oozing' as opposed to 'Hand- offs' is the operative concept behind how vehicles travel through fixed-location group after group.
  • an alternative way to describe an approach of this disclosure for dynamic re-associations of a moving vehicle might be, e.g., fluid, layered redundant group association dynamics, itself shortened to “topographic dynamics.”
  • this concept is referred to herein by the shorter phrase “topographic oozing.”
  • FIG. 6 graphically clears out all other vehicles (which may still be present) and shows three successive instances in time of vehicle A turning from Main Street onto Wall Street, with the time-sequence shown by arrows (see, also note 190 in FIG. 6). Notes 194, 195, and 196 in FIG. 6 point out that, internally to the core software on the device of vehicle A, it has passed through first belonging to three groups, then belonging to five groups for roughly a two or three second period as the car swings through the actual intersection, then back to belonging to three groups once it finds itself on Wall Street.
  • the managing nodes at all five intersections likewise tracked this swift group re-association, where the intersections down main street (apart from Wall) simply lost contact with Vehicle A at some point (or clearly knew they were going to lose contact by monitoring the motion records), the intersections down Wall street all of the sudden made contact with vehicle A and immediately invited it into their local groups and informed others in its group of the new arrival, while the central local group at Wall and Main just kept its normal exchanges going with vehicle A all along.
  • the data loops in charge of producing raw ping data do not necessarily care about group association and re-association dynamics, they just gather and organize raw pings as they send them and hear them.
  • group association and re-association dynamics they just gather and organize raw pings as they send them and hear them.
  • vehicle's ping driver will be dutifully count-stamping all of its outgoing messages (perhaps ten per second), while also count-stamping all incoming messages (typically many dozens if not hundreds per second), whether they are from other nodes in the groups that it currently belongs to (the three intersections along main Street) or from any other nodes whatsoever.
  • the ping driver does not care, it just count-stamps and logs numbers.
  • the ping driver passes these collections of received count-stamps along with the identification (ID) numbers of the senders over to the core processing software.
  • the ping driver's job is over, relative to its role in topographic oozing or topographic dynamics: count- stamp tx events (transmissions) and count-stamp rx events (receipts), log the events and pass the event information along to other nodes.
  • One example of extreme simplification on the H matrix dynamics challenge is to pre-load template matrices which correspond to discrete combinations of how many vehicles are currently down the four directions of the streets, e.g., from 0 to nine vehicles in each direction, giving then ten to the fourth power number of preloaded H matrices and their inversions.
  • the inverted matrices themselves can be compressed into the few kilobyte range. Thus, only about a few ten's of megabytes of storage are used to accommodate all possible combinations of up to nine vehicles in every direction. For more than nine cars, according to one embodiment, completely separate sub-groups of the local group are formed at that point, keeping the general overall numbers of the groups to one or two dozen each. There are a great many other such engineering options possible to keep the dynamic H matrix problem a very tame one.
  • the info loop and the linq loop are also busy during topographic oozing, the linq loops less so than info loop.
  • the linq loops are told by the info loop which linqs are currently active and are part of one or more group associations.
  • the linq loop then monitors the status of each linq, not caring too much whether it belongs to one local group or another.
  • vehicle A has been told that the managing node ("AlphaDawg") on Main Street a block and one half ahead is part of at least one local group to which the vehicle belongs, and it has been told that its ID is 46352849. In certain embodiments, vehicle A may not receive more information than this regarding the AlphaDawg.
  • the linq loop then scans incoming count-stamp logs from the ping driver, looking for ID 46352849 (and all other active linqs as well), then when it finds this ID, it goes ahead and performs its tasks as described in the related disclosures. For the purposes of topographic oozing, it flags the info loop that this particular linq remains active at to indicate that the one or more groups to which it is associated remain viable.
  • the linq loop When the linq loop scans and retrieves a ping from a non- currently-associated linq, it will nevertheless set up a temporary holding structure for that 'possible linq' and report back to the info loop that there is a linq possibly available that is not a current member of its known groups. (Likewise, an "ignore" list can be sent by the info loop to the linq loop, alerting the linq loop that it may every now and then see a certain ID, but to ignore it and move on).
  • the info loop is the proper place, containing the appropriate set of structures according to certain embodiments, wherein the lists and maintenance of the overlapping group associations is accomplished.
  • Vehicle A in FIG. 6 associates itself with three active groups at an initial time-space point (see note 194), where these associations are maintained with the info loop and info structures.
  • either the Alphadawg itself at Wall and Main may send a message to the vehicle A that it should expect to start hearing from the two new intersections down Wall Street, or, the linq loop simply starts reporting that it is hearing new linq ID'S, which would then kick off normal group association processes once the info loop has been informed of these new linqs and Vehicle A sends out a brief message to the AlphDawgs of these two new groups that it wishes to join the groups.
  • the variations on how the new group association is formed are many, as well as the approaches to take for informing the info loop of Vehicle A that there are new groups to join.
  • AlphaDawg Nodes at the 5 intersections cooperate to determine which local groups that 'Vehicle A' will participate in as it turns from Main Street onto Wall Street, where group-associations can change at Harmonic Block intervals, typically in the tenth-of-a-second range. Harmonic blocks become the group-wide coarse metronome whereby higher level group associations and changing solution conditions are managed.
  • the tenth of a second range is purely rule of thumb, and both slower and faster rates may be needed as a function of application and certainly as a function of expected traffic flow rates.
  • a tenth of a second on a highway setting with 70 MPH cars may in fact be too slow, for example. There is no reason technically to not adapt the harmonic block rate to the particular application.
  • FIG. 7 is a schematic diagram illustrating the concept of Zulutime according to certain embodiments.
  • a common question for implementers of this disclosure as well as users is: what is Zulutime and who is defining it?
  • FIG. 7 graphically illustrates that there may well be a large number of overlapping and hierarchical groups all processing respective data, but where does Zulutime come from?
  • FIG. 8 is a schematic diagram illustrating that each AlphaDawg node is free to choose its own definition of local Zulutime for its local group according to one embodiment.
  • Each and every AlphaDawg is free to choose its own definition of local Zulutime for its local group.
  • the primary job of local Zulutime is to provide a short- term local time-reference against which all participating clocks can track their deviations.
  • the word "time" itself is a notoriously over-loaded and slippery concept. In the context of a local group functioning to help understand the spatial relationships of group members, then there may be no need to explore the metaphysical and mystical associations of the word "time.” Rather, certain embodiments are concerned only with the dynamic and evolving error ellipsoids on the position estimates of group members.
  • AlphaDawg One choice that the AlphaDawg can make is to choose its own counter to represent local Zulutime. For most applications, this turns out to be the most efficient and least complicated from a network programming perspective. Artisans in the global timekeeping community would phrase this as the AlphaDawg's clock becoming the local master clock, but even this statement is an order of magnitude more metaphysical than it needs to be.
  • the AlphaDawg's monotonic counter replete with resets to zero every half hour or so (for typical consumer-grade counters), may work just fine as local Zulutime. No need to put the raw numbers into dates, hours and minutes, according to certain embodiments, just raw streams of monotonic numbers are all that may be needed from a strictly engineering perspective.
  • FIG. 8A is a schematic diagram illustrating vehicle A sending out a count- stamped message "M" at some instance according to the example embodiment of FIG. 8.
  • the internal counter reads 43289283653. This act of sending the message M is enumerated as reference 205 in FIG. 8A.
  • Note 202 in FIG. 8A also indicates that the local group's AlphaDawg has chosen its own counter for the local group's Zulutime definition. At this first step in the example, the number listed above has nothing to do with whatever numbers are streaming away in the AlphaDawg's counter.
  • One of the end goals of this disclosure is to nevertheless produce a useful distance or range estimate between vehicle A and fixed node B based on this single passing of message M. To put this in engineering-terms: What kind of network layer software and what form of network communications protocols need to be built in order for message M to immediately produce a range estimate between A and B?
  • FIG. 8C is a schematic diagram illustrating (with a connected series of circles) respective vehicles in motion 21 5 according to the example embodiment of FIG. 8.
  • these vehicles 21 5 may be travelling about 30 miles per hour or some other speed, with brief instances of their positions depicted (by the connected series of circles).
  • FIG. 8D is a schematic diagram illustrating a moment in time a few seconds before message M is sent out by vehicle A, as shown in FIG. 8A.
  • dozens and dozens of messages have been sent out by every node in the few seconds before message M was sent out from Vehicle A, as depicted in a previous figure.
  • Note 220 in FIG. 8D indicates that over a few seconds time before message M is sent, all nodes in the local group are busy sending out their own messages, where FIG. 8D just displays a sampling of these previous sent messages.
  • the basic point is that all nodes are constantly sending out messages, where for certain example embodiments, at least ten transmitted messages per node is
  • FIG. 8E is a schematic diagram illustrating that all the nodes in the local group are likewise receiving messages all the time according to the example embodiment of FIG. 8.
  • a singular message from any node is usually heard and Ping-driver count-stamped by many other nodes, possibly all other nodes in a local group; hence, the bigger quantity of RX count stamps over TX count stamps, generally speaking.
  • Note 225 in FIG. 8E also points out that, generally speaking, there may be a much larger overall number of received messages than transmitted messages simply due to "sent by one, received by many" principles of networked communications.
  • any given node may not need to be in active packet-based communication with another node for a ping-event to be recorded.
  • some random vehicle may be sending a data packet to some other random fixed node, such as the AlphaDawg at Wall and Main, but all other nodes can be listening to that packet exchange and simply extracting their own ping event local count stamp of the message, while not bothering to decode the sent message. This situation may be very common in practice.
  • FIG. 8F is a schematic diagram illustrating a large number of messages sent and received by nodes in the local group and organized into linear equations according to the example embodiment of FIG. 8.
  • FIG. 8F is an involved graphic that attempts to summarize a fairly complicated situation described in detail in the related disclosures. The general idea attempted to be depicted is that this "large boatload" of messages that have been sent and received by all these nodes in the local group can be organized into a few seconds worth of linear equations with often thousands of equations, i.e., singular data points, and a smaller amount of group unknowns (which will be described in the figures below).
  • 'g' is a raw data vector, which in practice is often the difference between a sending node's count value when it sent a message and a receiving node's count value when it received that message (this may seem counter- intuitive, since they are so unrelated to each other, but their unknown relationship is precisely one of the primary unknowns we are seeking).
  • H is a snapshot linear relationship between nodes: their spatial positions, their count-stamp differences, and a variety of what can be called nuisance variables.
  • 'f is the unknowns in the local group, dominated by count stamp differences and spatial relationships.
  • a single row in the H matrix represents a single data point, most often representing a single node's ping-receipt.
  • the non-zero elements of the H matrix rows are abstractly represented in FIG. 8F, where the artistic license here is aimed at illustrating the completely sporadic nature of communications as opposed to some assumptions being made about data points being collected with imposed regularity.
  • FIG. 8F notes that typical operational H matrix formulations may include hundreds if not thousands of single data point equations.
  • FIG. 8F also notes that most elements in the matrix are zero, i.e., the H matrix is typically sparse.
  • FIG. 8F notes that typically there are a few dozen to sometimes into a few hundred unknowns in a system with say five to fifteen node participants. These numbers are simply practical guidelines for implementation as opposed to representing limitations.
  • harmonic block sub-structure [0115] Also highlighted in FIG. 8F is an array of finer brackets, labeled "harmonic block sub-structure.”
  • harmonic blocks represent the interface between the strict regularity and uniformity that high level software and network processes like to work with on the one side, and the arbitrary sporadicness of nodes coming and going in a local group and their equally sporadic
  • the interface also includes providing a structure to contain and accommodate a wide variety of time-based processes that are different from each other, where for example the time-based characteristics of one node's clock relative to another has quite different properties from an aircraft's positional movement in heavy turbulence. Yet a general processing framework is used to relate the two phenomena, where an example embodiment of this disclosure has chosen to do so with these harmonic blocks.
  • the physical-time length of a typical harmonic block is a function of the particular application, where for intelligent transportation applications a value of one-tenth of one second is not unreasonable. As a vehicle moves through city streets, it and its local groups may be assessing their group relationships generally at this harmonic block rate. In Kalman optimizations, the harmonic block rate may become a guide toward the setting of parametric rates for various underlying unknown parameters being solved for as well.
  • FIG. 8G is a schematic diagram illustrating the solution vector, 'f according to the example embodiment of FIG. 8. This vector may include
  • the spatial unknown solutions are most generically in terms of motion parameters as opposed to absolute positions.
  • One of the main reasons for this is that two and three dimensional absolute position unknowns inherently bring with them non-linear attributes such as the square root of the sum of squares in direct ranging representations of a single data point measurement.
  • there are new tools that can be employed that utilize known constraints of vehicle traffic in order to pseudo- linearize absolute position unknowns. For example, knowing that a vehicle is generally in the middle of the block on Main Street, which might itself be a one way street, then initial linear g Hf formulations might isolate the "x-axis" parameter (the axis coincident with Main street) as the directly solved entity.
  • One point to be made here is that there is vast flexibility in choosing approaches to approximate solutions, initial solutions, post-solution refinements, and the like. All of these solutions broadly fit into the sought-for spatial solution that intelligent transportation systems are seeking.
  • the middle bucket or group in FIG. 8G labeled ⁇ unknowns' are Delta- ZuluTime unknowns, representing the unknown relationship between any node's local counter and the local group's particular definition of Zulutime, whereas previously stated this is often just the AlphaDawg's own counter.
  • DZT's Delta- ZuluTime unknowns
  • the third bucket or group of unknowns in FIG. 8G is labeled "nuisance unknowns," partly in homage to the classic use of the word “nuisance variables” in GPS and other fields. Broadly speaking, this includes all unknown parameters that simply are not either spatial in nature or related to counters and clocks.
  • the related disclosures highlight two typical examples of these unknowns, one being instrument delay properties and the other being environmental effects such as multipath. In both of these cases and others, it is often possible to treat these nuisances as explicit unknowns in the general rolling up of network-node relationships, thereby explicitly attempting to measure them and through their measurement either partially or nearly fully mitigate their negative effects on the qualities of solutions.
  • FIG. 8G thus summarizes their common participation in solution formation.
  • FIG. 8G Another note about FIG. 8G is that the text inside the graphic (Extract Solutions) along with the lines present the notion that later stages of processing, described in some ensuing figures and accompanying text, extract certain specific information from these initial solutions. This process extracts the necessary solution data to help frame message M's inherent ranging relationship between Vehicle A and Fixed Node B.
  • FIG. 8H is a schematic diagram illustrating a culmination of the previous steps according to the example embodiment of FIG. 8.
  • FIG. 8H shows how the relatively short set of network traffic immediately prior to the sending of message M can produce specific estimated variables which can then frame message M as a classic discrete ranging instance.
  • the details of FIG. 8H are ultimately a slight oversimplification in practical terms, because these discrete ranging measurements are rarely explicitly made, and their effective presence is either represented as rows in H matrices or as parametric sequences in Kalman filters. But, FIG. 8H provides valuable insight for the present disclosure.
  • FIG. 8H a single estimate for distance between A and B is shown within the rounded rectangle 244.
  • the units of this raw ranging measurement are in ZT tick distance units, so the note 246 below the rounded rectangle 244 makes the explicit conversion to meters.
  • the components of FIG. 8H include the notional "local Zulutime” (labeled 230 or ⁇ RX) wherein message M was received by node B, and the notional "local Zulutime” (labeled 232 or t T x) that the same message was sent by node A. In one sense, this is a node's best estimate of what the AlphaDawg's counter would be reading precisely when the message was received and sent, respectively. There is no need, in certain embodiments, for any of the underlying clocks to be "steered” (as the art of timekeeping puts it) to local Zulutime, because the calculations or number crunching simply continually produces these correction factors. Note that the use of the letter ⁇ (e.g., t RX and t T x) is ultimately just a unitless counter value, and should not be confused with an actual time.
  • ⁇ e.g., t RX and t T x
  • the two n's sub-scripted by B and A in FIG. 8H respectively are the raw local count-stamp values of the two nodes.
  • the DZT values, labeled 234 and 236, are the values that were
  • DZT stands for delta-Zulutime and represents a given node's best estimate of how far off it is from local group-wide Zulutime at the coarse time that it sent or received message M. It is the set of communications that does the estimating here, not just the node itself, but the node is free to choose exactly how this is calculated and/or filtered. Likewise, other nodes are free to choose how they calculate, filter, or otherwise accept the data of other nodes for what the other nodes' DZT values are. Flexibility in how nodes, especially the AlphaDawg node, calculate these variables, and how they choose to either use or ignore information, is useful to the robustness of the network and of the solutions.
  • the term 'IE' is represented only on the receiving node B, labeled by 238 in FIG. 8H.
  • This term stands for "instrument/environment” and is used here to simplify the graphic and keep the formula tight. It is represented only on the receiving side, even though in practice delays such as transmit delays (the physical time it takes between when a counter latches to some new value and the time that physical electromagnetic wave actually emits from an antenna) are also present. For many applications, most or all of these delays can be lumped into a receive-side correction factor. Fine-tuned applications may wish to break out transmit-side instrument and environmental delay sources, especially if extra information is available to assist in their measurement.
  • Note 240 in FIG. 8H reiterates that one can conceptualize t RX as being roughly the counter value of the AlphaDawg (which has been arbitrarily chosen as local Zulutime) when node B received message M. This in practice may be a fractional value rather than an integer, since the calculation of its components are generally floating point values. The note 240 indicates this through the word
  • message M may be the very first signal exchanged between node A and node B, and yet the overall network can allow that singular message to produce a clear range estimate between node A and B.
  • FIG. 8I is a schematic diagram illustrating a summary of the example embodiment of FIG. 8.
  • FIG. 8I points out variables and provides some quick notations.
  • One note in particular points out that previous messages between A and B help to form better estimates of the DZT values, while the above discussion pointed out that this is not necessary. It is simply helpful to more robust and more precise results.
  • IE is short for Instrument/Environment nuisance variables such as both A and B's instrument errors and delays, multipath effects, atmospheric delays in longer range communications, etc. Companion disclosures explain why all of these nuisances can roll up into a single correction term on the receiving node's Zulutime estimate.
  • DZT delta-Zulutime
  • the word 'coarse' is used quite a bit, alluding to the idea that existing commercial-grade oscillators and discrete counters, along with generally non-trivial nuisance variables, combine to give error bars on individual message-ranging estimates typically one to two orders of magnitude worse than Kalman-filtered final estimates produced after hundreds and thousands of exchanged messages.
  • FIG. 9 is a schematic diagram illustrating use of a GPS receiver to maintain a link to global time standards according to one embodiment.
  • An optional "Good Housekeeping" approach is to create regional fixed-node groups, with at least one node communicating with a high quality GPS receiver to maintain a link to global time standards.
  • FIG. 9 introduces an ancillary but nevertheless practical extension of this disclosure. It is ancillary in the sense that it is un-needed from a pure engineering level, relative to the functionality heretofore described.
  • One option illustrated in FIG. 9 is to put a high quality GPS receiver on some rooftop somewhere and either wireline its signal to one or more nodes in the network, or alternatively, set up a node in the network right at the GPS receiver and have that node become a super-AlphDawg node within a local group that it defines, which may include a few fixed node members at the few intersections around the building where it is placed.
  • the local counter of the node at the GPS receiver may still simply count away in unitless increments, while standard off-the-shelf timing circuitry may relate the count values or otherwise slave the count values to the GPS time being calculated by the GPS receiver. In this way, the GPS-based
  • AlphaDawg's counting then is directly referenced to at least that GPS receiver's version of GPS time.
  • the dark lines drawn along the streets represent, accordingly, the diffusion of GPS time through the network since another figure already showed how intersection fixed nodes become cross-associated, and that this cross-association can be used to relate one AlphaDawg's counting to the next AlphaDawg's counting, all the way out to any periphery from the GPS-based
  • AlphaDawg There may be a price to be paid in a slight degradation of relating "true" GPS time of a given Node to the same time which would be read as if a high precision GPS receiver were placed at every single node, but for the practical purposes of intelligent transport systems where it has already been pointed out that this infusion of GPS is ancillary in the first place, this creep in timing error is negligible.
  • FIG. 9A is a schematic diagram illustrating diffusion of GPS time as a function of cross-group memberships according to the embodiment of FIG. 9.
  • FIG. 9A depicts cross-group diffusion of GPS time or any other chosen standard time, paving way for city-wide specifications on network time and its quantifiable deviations from broader standards.
  • the related disclosures provide more details on precisely how one local Zulutime can relate to another local Zulutime, but the basic notion is rather simple: an AlphaDawg defining one local group is nevertheless a standard non-AlphaDawg in another group, and hence its DZT value relative to the neighboring AlphaDawg is thus ongoingly calculated.
  • any given node "5 hops" away from a high quality GPS receiver can still gain benefit from that receiver's time whilst accumulating the associated errors on cross-group DZT errors.
  • Even the "hops" in question are virtual, and hence a given node can relate to GPS time through any combination of hops, including a weighted combination of all hops.
  • This is represented in FIG. 9A as the thick path- lines between a given indicated node (see note 250) and the GPS receiver.
  • this node counts out a certain value on its counter; it knows that it is X off from its neighbor, which is Y off from its neighbor, which is Z off from its neighbor, which is Q off from the GPS receiver's UTC estimated time.
  • the far node e.g., indicated by the arrow near note 250, can choose to weight several such paths, in order to slightly refine its own estimate of GPS/UTC time.
  • FIG. 9B is a schematic diagram illustrating the receive-only mode shown in FIG. 4A according to the embodiment of FIG. 9.
  • FIG. 9B depicts an example of a region-wide GPS Pseudolite-like broadcasting network:
  • the Rx-only mode for mobile clients is clearly possible in such an arrangement.
  • the earlier Rx-only client is pasted into this figure.
  • a network may be used whereby client nodes need only receive signals, just like GPS receivers do today.
  • Those practiced in the art of GPS systems can recognize this type of network as being similar to what are known as GPS pseudolites, but only if it is also imagined that the signals being sent to the mobile nodes are following the GPS signaling protocols.
  • This choice of configuration tries to bridge the backwards compatibility gap between the full implementation of this embodiment and hardware which already exists in
  • GPS receivers namely, GPS receivers.
  • the fixed nodes in question then could become these GPS-specified transmitters, also containing provisions for broadcasting their fixed known location at street corners, which may result in a city region being bathed in good quality GPS pseudolite signals.
  • An alternative is to not strictly follow either GPS frequency band specifications on the fixed node transmitters but nevertheless follow many of the baseband signaling specifications.
  • Another alternative would be to set up a completely new signaling methodology for the broadcasting nodes.
  • the economics and cost efficiencies of these types of approaches may vary widely, and there should be no inclination to preclude these kinds of sub-configurations from consideration for some given deployment.
  • the mobile node 145 is still listening to ZTChatter, but that chatter is more structured than might be the case, e.g., with 802.1 1 based networks.
  • FIG. 10 is a schematic diagram illustrating enhancement of traffic flow management according to certain embodiments.
  • Flow-Volume and Flow-Vector- Weighting can greatly enhance traffic flow management algorithms which have largely been developed around statistical flow timing and magnetic sensors in the pavement.
  • Anonymous Opt-in' participation by mobile nodes incentivized by self- interest, ensures a high enough sampling of actual vehicular and pedestrian flow to produce quantifiable reductions in fuel consumption and emissions for all mobile traffic.
  • Fuel is effectively wasted by idling cars sitting at traffic lights or worse, stuck in gridlock. But, vastly greater amounts of fuel are wasted by interrupting optimal flows of traffic. Needless changes in velocity, for example an inefficient statistical timer on a stop light turning yellow just as ten cars observing the speed limit are approaching from one direction with absolutely no traffic coming from the
  • the asymptote of potential improvement in MPG overall may be fixed at some optimal constant speed, say 30 mph.
  • FIG. 10 indicates that the techniques prescribed in this disclosure would address this issue, providing a wealth of new and highly reliable traffic data to the traffic control industry.
  • the fixed nodes sitting on top of traffic lights according to one embodiment was no casual choice, where the AlphaDawg and its back up are becoming more and more connected into networks through the many efforts discussed in the introduction. Their processing power is ever increasing and their sharing of information between grid points is rapidly evolving from the network perspective. This disclosure can provide a wealth of new data to these systems.
  • FIG. 10 is deliberately simplified in its traffic depiction, where vehicles become generic and pedestrians are illustrated as well.
  • Cell phones, personal digital assistants (PDAs), Bluetooth devices, or even just cheap chirpers as discussed in relation to FIG. 4B, can easily be carried by pedestrian, bikers, etc.
  • PDAs personal digital assistants
  • Bluetooth devices or even just cheap chirpers as discussed in relation to FIG. 4B, can easily be carried by pedestrian, bikers, etc.
  • both vehicles and non-vehicles alike are included in FIG. 10.
  • Part of the overall management of the Zulutime group by an AlphaDawg can then include tracking short histories of members of the local group.
  • non-vehicle but nevertheless mobile nodes can be included in the definition of local group.
  • These short histories are most simply described by motion vectors attached to known current positions, or they can even include second and third derivatives of motion if ensuing traffic analysis algorithms wish to exploit that higher order motion information.
  • the AlphaDawg or any designee of the AlphaDawg such as a local server serving, e.g., a 1 0-by-10 grid of intersections, is effectively generating the raw data level for a real-time mapping of all the participating nodes in the local group.
  • FIG. 10 shows one very simplified view of what a wider real-time map of mobile objects might look like at some city-grid server (or at an AlphaDawg where neighboring AlphaDawgs have shared their maps of objects not in the other
  • FIG. 10 shows that flow is being actively encouraged along the horizontal access, apart from near the far left where vehicles are stopped, and that vehicles along the vertical axis of FIG. 10 are about to pile up at the horizontal intersection. Accordingly, with all due safety procedures nicely attended to, it may be time to change the light!
  • Flow vectors 258 are therefore highlighted in FIG. 10 to encapsulate the spatial and motion information known about the various participatory nodes in the network.
  • the thick arrows and text labeled 260 and 265 represent outcomes of hypothetical traffic flow algorithms, which this disclosure does not currently describe in depth, but rather simply references the broad prior art of traffic flow modeling and certain instances of detailed traffic flow management based on flow vectors as being the an approach to building and implementing flow-based decisions. This particular disclosure thus indicates the data pipe and mapping related data sources that feed this large array of prior art algorithms.
  • phase "opt in” is part of an embodiment, but certainly not required.
  • a clear case in point of a non-opt-in situation may be for emergency response vehicles where there is already a well established industry for communications between such vehicles and traffic lights.
  • a highly secure link can be established between any node participant and any other, and if one of the nodes is the AlphaDawg and it is configured to control the light switch, then a secure emergency oriented signal can be sent from the vehicle to the traffic light, with the additional benefit that the traffic light will know exactly where the vehicle is and can monitor its safe passage through the intersection, above and beyond the simple task of turning the light green for the vehicle.
  • Note 268 in FIG. 10 depicts but one example of a very large range of possibilities of having local node participants actually pass additional information from the node to the AlphaDawg and/or the traffic management server.
  • Other examples include communicating information such as "I just put my right blinker on,” “I am slowing down to pull over to the curb,” or “I just braked very sharply.”
  • communicating that "I am a police car” provides certain implications to the management server such as "do a quick check on any very recent incident reports in this two block area.”
  • Certain embodiments use and add to the normal communication networks and thereby use those standard communications to supplement flow-vector data.
  • the related disclosures discuss "pung" packets. It is within these pung packets that the certain embodiment may place these informative extra information.
  • the AlphaDawg can also send information to any specific node, a sub-set of nodes, or the entire set of nodes.
  • topographic oozing may be replaced by something more concise and technically descriptive. But, as discussed above, “topographic oozing” is used herein to describe fluid, layered redundant group association dynamics. Likewise, the very word “topographic” also could be either replaced or supplemented with the similar term “topologic,” in that generic network nodes often use this latter term to describe specific configurations of active node linqs, very often ignoring the "geometric" aspects of those linqs. This disclosure will continue to use the topographic term with the understanding that it includes many aspects of network science topologic principles.
  • Example implementation of topographic oozing are provided to provide further details on how topographic oozing principles can be applied on current technology RF devices.
  • 802.1 1 devices are temporarily described for the example implementations, trying in the process to show how DSRC devices can be built to do the same operations.
  • the example switches the baseline usage example from an urban core to the interior of a retail shopping store having similar challenges of mobile devices randomly moving through a large array of fixed nodes.
  • FIG. 1 1 is a schematic diagram illustrating an example embodiment within a medium sized shopping store.
  • the shopping store is about 100,000 square feet, or 500 feet by 200 feet in its two dimensions.
  • the store has two 802.1 1 access points (APs) labeled 300 and 302 in FIG. 1 1 .
  • the APs 300, 302 presumably service, e.g., store personnel as well as customers in any and all of their WiFi service needs. Many stores of this size would typically have more than two APs. But, for but the simplicity of describing how topographic oozing can be implemented, this disclosure will keep it to just two APs.
  • the AP 300 may generally service users (e.g., the user's WiFi or mobile devices 304) near the front of the store, and the AP 302 may service users (e.g., mobile devices 306) wandering toward the back of the store.
  • This example adds a "complication" that these two APs 300, 302 service their associated devices 304, 306 using different WiFi channels.
  • AP 300 uses channel "3"
  • AP 302 uses channel "7". This servicing of different devices by different channels is common in WiFi implementations and it is included in this example to show that topographic oozing can also easily function in this multi-channel setting as well.
  • FIG. 12 is a schematic diagram illustrating effectively the same store layout as that shown in FIG. 1 1 , but with a total of 30 additional WiFi devices, collectively labeled 306 (illustrated by "+” symbols) and 307 (illustrated by “x” symbols) (the two separate numbers explained below), strewn throughout the store.
  • the new 802.1 1 devices 306, 307 are attached to the ceiling and are powered either by Ethernet drops or by 5 volt power lines.
  • the company Gainspan makes a typical low cost device called the GS 101 1 , which may be used in certain embodiments.
  • a property of these devices is that they have two processing units, one largely dedicated to WiFi communications and the other being a general purpose ARM processor capable of performing the steps described below.
  • Each installed GS 101 1 is within range of at least one of the APs 300, 302. (Here again, normally there may be more than two APs, but this implementation example uses just two APs for explication purposes; if "range" becomes an issue for a particular application, then the number of APs may be increased, e.g., to three or four or many more for very large stores.)
  • an information technology (IT) professional has installed the two APs 300, 302 as is typical for APs servicing a given area intended for many client WiFi devices. This example assumes that these two APs have been so installed and they operate according to very normal AP standards and methods.
  • an IT professional or a trained installation technician may mount the 30 GS 101 1 's and ensure that they are properly powered and "booted up". They do not necessarily need to be on the ceiling, though this is useful in certain embodiments.
  • Two additional operations take place on each of the GS 101 1 devices during this physical mounting and powering step. Once powered, the GS 101 1 devices are instructed to act like a normal WiFi client, contacting and communicating with and through one or both APs 300, 302. The other step is that the individual doing the physical installation, or some assistant thereto, logs the actual location of where he/she has installed the given individual device, e.g., relative to a store map.
  • the manner of this logging has many variants, with one method being logging in with a smartphone application indicating the ID number of the GS 101 1 device, its IP address, and its store location, usually indicated in aisle numbers and post numbers. Later on, an additional program transfers the logged locations into physical coordinates relative to the 500 by 200 foot dimensions of the physical store, usually including the height of the GS 101 1 (above the floor) as well.
  • the accuracy goals of the entire system may require that one should log the locations to slightly better than the position accuracy desired for device tracking, where this is currently roughly a meter or so.
  • each GS 101 1 device powers up and communicates with an AP, it can perform a variety of provisioning tasks.
  • One task includes contacting some
  • each GS 101 1 node chooses one of the other of the APs to be its primary association AP and to choose the channel of that AP as the primary channel that it "listens to” for other WiFi traffic, as will be described further below.
  • a function of the GS 101 1 devices is to listen for transmitted WiFi packets from any and all random mobile WiFi devices that establish a WiFi session with the primary AP that it (the GS 101 1 device) is associated with.
  • FIG. 13 is a schematic diagram illustrating the shopping store of FIG. 12 with a newly introduced mobile WiFi device 308 somewhere near the entrance of the store. This device 308 establishes its own "normal" duplex packet communication session with the AP 300, represented by the thick line 309 between the device 308 and the AP 300. In doing this normal operation, most if not all of the other GS 101 1 devices associated with AP 300 also "hear" or receive the packets coming from the mobile device 308.
  • FIG. 13 is a schematic diagram illustrating the shopping store of FIG. 12 with a newly introduced mobile WiFi device 308 somewhere near the entrance of the store. This device 308 establishes its own "normal" duplex packet communication session with the AP 300, represented by the thick line 309 between the device 308 and the AP 300. In doing this normal operation, most
  • FIG. 14 is a schematic diagram illustrating a packet transmitted from newly introduced mobile WiFi device 308 shown in FIG. 13 according to one embodiment.
  • FIG. 14 isolates the situation further, showing the hypothetical transmitted packet from mobile device 308 being received by ten GS 101 1 devices and also the AP 300. Note that there are more than ten GS 101 1 devices associated with AP 300 but not all of them heard the transmitted packet depicted.
  • FIG. 15 is a schematic diagram illustrating a more typical but more complicated situation, according to certain embodiments, where there are now dozens of mobile devices in the store all transmitting packets every now and then. Some mobile devices are smartphones of customers, others might be l-pads® used by store personnel. Depicted in FIG. 15 is the isolated GS 101 1 node labeled 310, where it happens to have received and count stamped a total of 97 packets from 14 different mobile devices over a 2 second period. The mobile devices are 'in session' with the AP 300, but are nevertheless sending out UDP packets that the GS 101 1 can also receive and countstamp. (Not depicted in the figure are the same UDP packets being received by the AP 300). FIG.
  • UDP user datagram protocol
  • the node 31 0 records all of these events as depicted in the associated numeric spreadsheet in FIG. 15 and puts these (or compressed) values directly into a "pung packet" that is transmitted to the IP address given to the node during set-up. If the node is on an Ethernet connection, it will use this channel to ship the pung data. If it is a stand-alone wireless node, it will utilize its association with one of the two APs to gain quick access to the WiFi channel and send the pung data.
  • UDP user datagram protocol
  • the pung packets from the GS 101 1 nodes are thus sending their data to some specified IP address (in this example referred to as a Zulutime Web Service), where data processing of the type explained in other sections of this disclosure track clock drifts between the various GS 101 1 nodes, remove such drifts from the count stamp data, compute multipath-distorted pseudo-range values, and thereafter calculate optimal positions for the mobile devices using multipath mitigation methods describe in the related disclosures.
  • a Zulutime Web Service some specified IP address
  • standard techniques exist to compute positions based on, typically, three or more pseudo-ranges. There may be larger relatively larger error bars on the calculated positions in the case where multipath is ignored.
  • FIG. 16 is a schematic diagram illustrating three instances in time of a single mobile device 312 (shown at different points in time as 312A, 312B, and 312C) as it moves among different areas of the store according to one embodiment.
  • the mobile device 312 is labeled 31 2A at a first location where it is associated with AP 300.
  • the mobile device 312 then moves to an area of the store where it is labeled 312C and where it has re-associated with AP 302; the interim state immediately prior to AP switching is depicted as 31 2B.
  • the position solutions smoothly track not only as different GS 101 1 devices variously receive packets from this mobile device 312, but also how those solutions bridge the gap as the mobile device switches from AP 300 to AP 302.
  • the device 31 2 at point A (312A) has 10 GS 1 01 1 's receiving its packets, moving abruptly down to only 6 at point B (312B), then abruptly going to 8 devices associated with AP 302 by point C (312C).
  • this 'abruptness' is a bit more fluid but still discrete in nature.
  • the mobile device 312 re-associates with AP 302 and the third linq state is indicated by 312C where a total of 8 GS 101 1 devices (devices that are associated with AP 302), receive and count stamp packets from mobile device 312 over the remaining 6 seconds of our original 20 second stretch.
  • the ZWS is continuously monitoring for exactly how many GS101 1 devices are "hearing" any given active mobile node.
  • clock solutions and position solutions can nevertheless be smoothly tracked and determined.
  • the linq state moves from 312A to 312B, several of the listening nodes remain the same and these solution techniques may be used in the transition from 31 2A to 312B.
  • a near-split- second switch now occurs between one set of GS 101 1 devices on one channel (that of AP 300) and another set on another channel (that of AP 302).
  • the ZWS is expecting such abrupt changes to occur in terms of which GS 101 1 devices are listening to which mobile devices.
  • the ID typically MAC address in the WiFi case
  • the continuity factor in stitching the previous positional solutions of 312A and 312B with the newly calculated positional solutions of 312C.
  • FIG. 17 is a schematic diagram illustrating an advanced variant, according to one embodiment, on the baseline description for the examples shown in FIGS. 1 1 , 12, 1 3, 14, 1 5, and 16.
  • FIG. 17 depicts the routine "channel hopping" that GS 101 1 devices can perform, especially those devices lying in the middle zone between AP 300 and AP 302.
  • GS 101 1 devices such as this one can certainly 'channel switch' in a receive-only mode and on a routine bases between the channel of AP 300 and the channel of AP 302.
  • mobile devices are generally fairly 'slow', it doesn't matter too much to the continuity of solutions and only adds accuracy because more GS 101 1 devices are receiving more packets from more mobile devices in range.
  • FIGS. 1 1 , 12, 1 3, 14, 15, 16, and 17 Another advanced variant on the descriptions of FIGS. 1 1 , 12, 1 3, 14, 15, 16, and 17 is where the GS 101 1 devices "go out of their way” to not only count stamp their own outgoing WiFi packets (count stamped tx events), but to send out such packets on a regular basis, e.g., two to three short packets every three to five seconds. In this approach, the GS 101 1 packets are themselves putting out
  • GPS Global System for Mobile Communications
  • the output of the GPS receiver is the triggering mechanism to determine whether one is inside or outside the fence.
  • Such geofencing approaches are applicable to position solutions formed by the descriptions in this disclosure and in the related disclosures. Additional benefits (over GPS) of using this disclosure's approach whereby WiFi or some other communicating channel is being employed, is that the very channel being used can also service geofencing applications, responses, identification, and association functions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Traffic Control Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention porte sur un système intelligent de transport tenant compte de la localisation, qui détermine des plages entre une pluralité de dispositifs de communication, comprenant au moins un dispositif de communication mobile. Un procédé comprend la réception de messages reçus émis d'une pluralité d'autres dispositifs de communication. Chaque message reçu comprend un tampon de compte émis correspondant à une valeur de compteur à distance. Le dispositif de communication mobile génère un tampon de compte reçu pour chaque message reçu. Le procédé comprend l'association et la dissociation de façon dynamique du dispositif de communication mobile avec une pluralité de sous-groupes de la pluralité d'autres dispositifs de communication. L'association et la dissociation sont basées au moins en partie sur la réception de messages reçus à partir d'un nombre prédéterminé d'autres dispositifs de communication pour chaque sous-groupe.
PCT/US2012/046265 2011-07-11 2012-07-11 Systèmes intelligent de transport tenant compte de la localisation Ceased WO2013009880A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/179,807 US8463290B2 (en) 2010-07-09 2011-07-11 Mobile device positioning in dynamic groupings of communication devices
US13/179,807 2011-07-11

Publications (1)

Publication Number Publication Date
WO2013009880A1 true WO2013009880A1 (fr) 2013-01-17

Family

ID=47262065

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2012/046265 Ceased WO2013009880A1 (fr) 2011-07-11 2012-07-11 Systèmes intelligent de transport tenant compte de la localisation

Country Status (2)

Country Link
US (4) US8463290B2 (fr)
WO (1) WO2013009880A1 (fr)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9791545B2 (en) 2006-12-07 2017-10-17 Digimarc Corporation Space-time calibration system and method
US7983185B2 (en) 2009-02-12 2011-07-19 Zulutime, Llc Systems and methods for space-time determinations with reduced network traffic
US8463290B2 (en) 2010-07-09 2013-06-11 Digimarc Corporation Mobile device positioning in dynamic groupings of communication devices
US8725080B2 (en) * 2011-12-29 2014-05-13 Motorola Solutions, Inc. Method and apparatus for transmission in a trunked radio communication system
US9282471B2 (en) 2012-03-21 2016-03-08 Digimarc Corporation Positioning systems for wireless networks
US9401541B2 (en) 2012-04-06 2016-07-26 Digimarc Corporation Methods and systems useful in connection with multipath
US9408178B2 (en) 2013-01-22 2016-08-02 Apple Inc. Detecting mobile access points
US9400321B2 (en) 2013-06-05 2016-07-26 Apple Inc. Utilizing mobile wireless access gateways for location and context purposes
AU2015222926A1 (en) * 2014-02-26 2016-10-13 Clark Emerson Cohen An improved performance and cost Global Navigation Satellite System architecture
US11062368B1 (en) * 2014-03-19 2021-07-13 Google Llc Selecting online content using offline data
WO2016011591A1 (fr) 2014-07-21 2016-01-28 Motorola Solutions, Inc. Procédé et appareil pour appel de sous-groupe à destination de membres de groupe manquant un appel de groupe
US10989531B2 (en) * 2014-08-15 2021-04-27 Commonwealth Scientific And Industrial Research Organisation Method of setting-up a range-based tracking system utilizing a tracking coordinate system
TWI534765B (zh) * 2014-09-26 2016-05-21 富智康（香港）有限公司 交通緩解系統及方法
JP6037468B2 (ja) * 2014-11-14 2016-12-07 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ 移動体が特定領域に接近していることを通知する方法、並びに、その為のサーバ・コンピュータ及びサーバ・コンピュータ・プログラム
US20160148267A1 (en) * 2014-11-20 2016-05-26 Blyncsy, Inc. Systems and methods for traffic monitoring and analysis
US9471060B2 (en) * 2014-12-09 2016-10-18 General Electric Company Vehicular traffic guidance and coordination system and method
US10938585B2 (en) * 2015-03-16 2021-03-02 Qualcomm Incorporated Location and range determination using broadcast messages
US10291419B2 (en) * 2015-03-16 2019-05-14 Qualcomm Incorporated Location and range determination using broadcast messages
US10885336B1 (en) 2018-01-13 2021-01-05 Digimarc Corporation Object identification and device communication through image and audio signals
CN110570672B (zh) * 2019-09-18 2020-12-01 浙江大学 一种基于图神经网络的区域交通信号灯控制方法
CN111081037B (zh) * 2019-12-04 2021-04-09 中移信息技术有限公司 交通信号灯控制方法、装置、设备及存储介质

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5539398A (en) * 1994-01-07 1996-07-23 Minnesota Mining And Manufacturing Company GPS-based traffic control preemption system
US7224984B2 (en) * 2000-08-15 2007-05-29 University Of Maryland, College Park Method, system and computer program product for positioning and synchronizing wireless communications nodes
US7397390B2 (en) * 2004-06-16 2008-07-08 M/A-Com, Inc. Wireless traffic control system
US20090051568A1 (en) * 2007-08-21 2009-02-26 Kevin Michael Corry Method and apparatus for traffic control using radio frequency identification tags
US20090213828A1 (en) * 2006-12-07 2009-08-27 Zulutime, Llc Wireless local area network-based position locating systems and methods
US20090228732A1 (en) * 2005-03-18 2009-09-10 Koninklijke Philips Electronics, N.V. Method for synchronization of network nodes
US20090233621A1 (en) * 2006-12-07 2009-09-17 Zulutime, Llc Systems and methods for locating a mobile device within a cellular system
US7876266B2 (en) * 2006-12-07 2011-01-25 Zulutime, Llc Harmonic block technique for computing space-time solutions for communication system network nodes

Family Cites Families (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4405986A (en) 1981-04-17 1983-09-20 The United States Of America As Represented By The Secretary Of The Army GSP/Doppler sensor velocity derived attitude reference system
FI900645A0 (fi) 1987-08-10 1990-02-09 Duffett Smith Peter James Navigerings- och uppspaoringssystem.
GB9310976D0 (en) 1993-05-27 1993-07-14 Lynxvale Ltd Navigation and tracking system for shielded spaces
US5717406A (en) 1995-06-07 1998-02-10 Sanconix Inc. Enhanced position calculation
US7110880B2 (en) 1997-10-22 2006-09-19 Intelligent Technologies International, Inc. Communication method and arrangement
GB9519087D0 (en) 1995-09-19 1995-11-22 Cursor Positioning Sys Ltd Navigation and tracking system
AUPN733395A0 (en) 1995-12-22 1996-01-25 University Of Technology, Sydney Location and tracking system
US6522890B2 (en) 1995-12-22 2003-02-18 Cambridge Positioning Systems, Ltd. Location and tracking system
GB9722324D0 (en) 1997-10-22 1997-12-17 Cambridge Positioning Sys Ltd Positioning system for digital telephone networks
US7375683B2 (en) 1999-03-05 2008-05-20 Era Systems Corporation Use of geo-stationary satellites to augment wide— area multilateration synchronization
US6674993B1 (en) 1999-04-30 2004-01-06 Microvision, Inc. Method and system for identifying data locations associated with real world observations
GB9912724D0 (en) 1999-06-01 1999-08-04 Cambridge Positioning Sys Ltd Radio positioning system
EP1235076A1 (fr) 2001-02-23 2002-08-28 Cambridge Positioning Systems Limited Perfectionnements aux procédés et dispositifs de positionnement
EP1255122A1 (fr) 2001-05-04 2002-11-06 Cambridge Positioning Systems Limited Unité de mesure pour sytème de radiolocalisation
US6618005B2 (en) 2001-06-29 2003-09-09 Intel Corporation Determining wireless device locations
US6577946B2 (en) * 2001-07-10 2003-06-10 Makor Issues And Rights Ltd. Traffic information gathering via cellular phone networks for intelligent transportation systems
EP1278074A1 (fr) 2001-07-17 2003-01-22 Cambridge Positioning Systems Limited Système de positionement par radio
EP1293800A1 (fr) 2001-09-17 2003-03-19 Alcatel Procédé de détermination de la position d'une station d'un réseau sans fil, station adaptée à la mise en oeuvre de ce procédé
AUPR863401A0 (en) 2001-11-02 2001-11-29 Qx Corporation Pty Ltd A method & device for precision time-lock
US6806830B2 (en) 2001-12-31 2004-10-19 Texas Instruments Incorporated Electronic device precision location via local broadcast signals
US6784827B2 (en) 2001-12-21 2004-08-31 International Business Machines Corporation Determining a time of arrival of a sent signal
EP1365613B1 (fr) 2002-05-22 2006-06-21 Cambridge Positioning Systems Limited Système de localisation et procédé
EP1376150B1 (fr) 2002-06-17 2009-11-11 Cambridge Positioning Systems Limited Système de radiolocalisation avec suppression d'interférence
EP1394562B1 (fr) 2002-08-28 2011-01-19 Cambridge Positioning Systems Limited Perfectionnements aux systèmes de radio-localisation
JP3801123B2 (ja) 2002-09-06 2006-07-26 株式会社日立製作所 無線システムおよびそのサーバーならびにその基地局
WO2005071430A1 (fr) 2004-01-26 2005-08-04 Cambridge Positioning Systems Limited Transfert d'informations temporelles etalonnees dans un terminal mobile
US7302269B1 (en) 2004-03-18 2007-11-27 Cisco Technology, Inc. Radiolocation in a wireless network using time difference of arrival
JP2006023267A (ja) 2004-06-09 2006-01-26 Ntt Docomo Inc マルチパス遅延成分を用いた位置測定装置および位置測定方法
KR20090014387A (ko) 2004-08-05 2009-02-10 메시네트웍스, 인코포레이티드 무선 통신 네트워크 상의 노드들의 범위를 지정하기 위한 효율적 대역폭 시스템 및 방법
EP1717596A1 (fr) 2005-04-28 2006-11-02 Cambridge Positioning Systems Limited Transfert d'information de position à un terminal mobile
EP1897399B1 (fr) 2005-06-27 2011-10-05 Cambridge Positioning Systems Limited Procédé et appareil destinés à déterminer si un terminal mobile se trouve à l extérieur d un lieu donné
US7826837B1 (en) 2005-08-05 2010-11-02 Verizon Services Corp. Systems and methods for tracking signal strength in wireless networks
US7450069B2 (en) 2006-02-27 2008-11-11 Olympus Corporation Technology Of America Ranging system and method
WO2007113086A1 (fr) 2006-04-04 2007-10-11 Cambridge Positioning Systems Limited association d'un temps universel à un signal reçu
US7847734B2 (en) 2006-04-21 2010-12-07 Sensis Corporation System and method for multilaterating a position of a target using mobile remote receiving units
EP1901088A1 (fr) 2006-09-18 2008-03-19 Cambridge Positioning Systems Limited Navigation de terminal mobile intégrée
KR101048444B1 (ko) 2007-09-03 2011-07-11 삼성전자주식회사 무선통신시스템에서 위치 추정 장치 및 방법
US20100135178A1 (en) 2008-11-21 2010-06-03 Qualcomm Incorporated Wireless position determination using adjusted round trip time measurements
US7983185B2 (en) 2009-02-12 2011-07-19 Zulutime, Llc Systems and methods for space-time determinations with reduced network traffic
US8463290B2 (en) 2010-07-09 2013-06-11 Digimarc Corporation Mobile device positioning in dynamic groupings of communication devices
US9282471B2 (en) 2012-03-21 2016-03-08 Digimarc Corporation Positioning systems for wireless networks

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5539398A (en) * 1994-01-07 1996-07-23 Minnesota Mining And Manufacturing Company GPS-based traffic control preemption system
US7224984B2 (en) * 2000-08-15 2007-05-29 University Of Maryland, College Park Method, system and computer program product for positioning and synchronizing wireless communications nodes
US7397390B2 (en) * 2004-06-16 2008-07-08 M/A-Com, Inc. Wireless traffic control system
US20090228732A1 (en) * 2005-03-18 2009-09-10 Koninklijke Philips Electronics, N.V. Method for synchronization of network nodes
US20090213828A1 (en) * 2006-12-07 2009-08-27 Zulutime, Llc Wireless local area network-based position locating systems and methods
US20090233621A1 (en) * 2006-12-07 2009-09-17 Zulutime, Llc Systems and methods for locating a mobile device within a cellular system
US7876266B2 (en) * 2006-12-07 2011-01-25 Zulutime, Llc Harmonic block technique for computing space-time solutions for communication system network nodes
US20090051568A1 (en) * 2007-08-21 2009-02-26 Kevin Michael Corry Method and apparatus for traffic control using radio frequency identification tags

Also Published As

Publication number Publication date
US20170156029A1 (en) 2017-06-01
US9826361B2 (en) 2017-11-21
US20140031059A1 (en) 2014-01-30
US8463290B2 (en) 2013-06-11
US9363783B2 (en) 2016-06-07
US9049563B2 (en) 2015-06-02
US20150341893A1 (en) 2015-11-26
US20120309414A1 (en) 2012-12-06

Similar Documents

Publication Publication Date Title
US9826361B2 (en) Mobile device positioning in dynamic groupings of communication devices
Lyu et al. MoMAC: Mobility-aware and collision-avoidance MAC for safety applications in VANETs
Saini et al. How close are we to realizing a pragmatic VANET solution? A meta-survey
Sengupta et al. Cooperative collision warning systems: Concept definition and experimental implementation
US9736637B2 (en) Position determination of mobile stations in a wireless network
Yan et al. A grid-based on-road localization system in VANET with linear error propagation
Marwein et al. Recent survey on internet of vehicles: Architecture, applications, challenges, and its solutions
Ansari et al. Design of an integration platform for V2X wireless communications and positioning supporting C-ITS safety applications
US9294879B2 (en) Determining path traversed by a mobile communication device
Mitchell et al. Location based services: Locating the money
US20250267599A1 (en) Monitoring, detecting, estimating, and alerting the cv2x-pc5 operation status
Fogue et al. Analysis of the most representative factors affecting Warning Message Dissemination in VANETs under real roadmaps
US9612343B1 (en) Method and mobile station for using a location determining mechanism based on an extent of turning
Ordóñez-Hurtado et al. An assessment on the use of stationary vehicles to support cooperative positioning systems
Cozzetti et al. Tight coupling benefits of GNSS with VANETs
Hasan et al. An experimental validation of accurate and precise GNSS time synchronization in vehicular networks
Ibrahim Data aggregation and dissemination in vehicular ad-hoc networks
Weis et al. GuideWeb: a conceptually infrastructure-free vehicle navigation system
Rylander et al. Using wireless communication to improve road safety and quality of service at road construction work sites (Poster)
Kim Development and evaluation of advanced traveler information system (ATIS) using vehicle-to-vehicle (V2V) communication system
Weis et al. GuideWeb: a new paradigm for navigation support based on v2v communication
Shankar et al. Outdoor Experience with the TrafficView Application
Krishnan et al. Commercial and public use applications
Singh et al. A Prevention Of Vehicle-To-Vehicle Communications With NS2
Iftode et al. Exploring the design and implementation of vehicular networked systems

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12811639

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12811639

Country of ref document: EP

Kind code of ref document: A1