Presentation is loading. Please wait.
doc.: IEEE 802.15-<15-09-0758-00-004e>
<month year> doc.: IEEE < e> Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Localisation elements for TG12 ULI] Date Submitted: [19 January 2017] Source: [Billy Verso] Company [Decawave Ltd.] Address [Peter Street, Dublin 8, Ireland] Voice:[ ], [billy.verso (at) decawave.com] Re: [Overview of ranging and localization function] Abstract: [Continue development of the mechanisms for location awareness for TG12 ULI] Purpose:  Notice: This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P
The aim of this presentation:
Progress the definition of the ULI functionality for ranging and localisation: Build upon the ideas presented in Define functional architectures for different localisation methods Consider the features and SAP necessary to support those architectures
doc.: IEEE 802.15-<15-09-0758-00-004e>
<month year> November 18 doc.: IEEE < e> Localisation functional decomposition within the framework Localisation Features Solver Location solving application (local or remote) Send relevant data to Solver application Perform ranging TOF calculation in ranging mode TX and RX timestamps AOA information RSSI Page 3
doc.: IEEE 802.15-<15-09-0758-00-004e>
<month year> November 18 doc.: IEEE < e> Localisation functional decomposition within the framework Localisation Features Solver Location solving application (local or remote) Send relevant data to Solver application Perform ranging TOF calculation in ranging mode TX and RX timestamps AOA information RSSI Re-designating the “Ranging” function as the “Ranging and Location Support (RLS)” function Page 4
Ranging and Location Support (RLS) functionality
Capability: Location & ranging support depends on PHY capability (UWB typically) with support for TX/RX timestamping, AOA, RSSI etc Functionality groupings : Passive RX timestamp (and RSSI, AOA) reporting Passive TX timestamp reporting Active sending of blink frames Active ranging direct or piggy-backed Communicating ranging results
Passive reporting Set appropriate PHY mode
Depending on device capability, MAC will deliver RSSI, AOA, and TX & RX timestamps (ranging counters) for TX and RX frames through MCPS-DATA.confirm and MCPS-DATA.indication primitives. Multiplexed MAC Interface (MMI) Intercept all MCPS-DATA.request to set the “Ranging” parameter Intercept the MCPS-DATA.confirm and .indication primitives For TX frames gather the Destination Address and the TX timestamp For RX frames1 gather the Source Address, and the attributes reported of: RX timestamp, AOA Azimuth, AOA Elevation, and RSSI Report gathered info into RLS via the RLSM-SAP RLS sends this “location enabling” info (LEI) via RLSH-SAP to the solver via local APP-SAP or appropriate network SAP The RTLS solver application combines the LEI from multiple nodes to solve the locations of the mobile nodes. 1 Perhaps use promiscuous mode to pick up frames addressed to other destinations
Active sending of blink frames
Proposal: make the RLS capable of initiating a blink frame transmission Where there is insufficient flow of data frames upon which to base the location service, periodic sending of blink frames from mobile nodes can enable TDOA location. Where infrastructure does not have distributed wired clock for TDOA timebase synchronisation, periodic sending of blinks from selected fixed nodes can be used to implement clock tracking to support time base unification for TDOA RTLS. Application tells RLS to send a blink. Via APP SAP multiplexed into RLSH-SAP RLS issues the instruction to send the blink RLSM-SAP multiplexed into MCPS-SAP invokes MCPS-DATA to initiate the sending of the multipurpose blink frame (broadcast) with “Ranging” set. Multiplexed MAC Interface (MMI) picks up the MCPS-DATA.confirm and delivers the indication to the RLS (optionally with the TX timestamp) through the RLSM-SAP RLS reports Blink TX done to the application, optionally (i.e. in infrastructure) sends the TX timestamp LEI to the configured solver Application may sleep (in a mobile node) or enable RX (infrastructure) until it is time to send the next periodic blink
Active ranging – proposal overview
Proposal: have the RLS actively engage in ranging Where there is insufficient flow of frames upon which to base ranging measurements, initiate appropriate frame exchanges to enable a ranging measurement Ranging is based halving the measured round trip delay (RTD) defined by a message TX and its response RX minus the reply time of the responding node, This gives a low accuracy result. A double-sided version of this is used where high accuracy is needed. Overview Application tells RLS to send message to initiate the ranging Remote MAC or RLS responds accordingly, making one RTD for SS-TWR For DS-TWR initiating RLS sends another message to complete a second RTD RLS at one end communicates its measured timestamps or inter-message delays to the other RLS which now has complete info to calculate the propagation time (TOF) between the devices RLS sends TOF and the device ID’s to the solver (local or over network) The RTLS solver application combines TOFs relating to single mobile node to solve its location.
Ranging mechanism: SS-TWR
For single-sided two-way ranging between two devices, A and B, we need a transmitted message from A and a response from B. For device A to calculate the estimated time of flight, Tprop, device B needs to communicate its reply time, Treply, to device A. This would normally be done in a subsequent frame, in an IE perhaps. Some implementations may be able to predict and set the reply TX time accurately and so be able to pre-compute, Treply, and actually include it in the reply message. The response from B to A could be an ACK or an independantly sent data frame
Ranging mechanism: DS-TWR
Double-sided two-way ranging produces a much more accurate TOF result since it cancels the error caused by clock offset between A and B. It is possible to complete a DS-TWR using three messages as shown. Here, device B receiving the final message of the exchange is able to calculate the Tprop (using the equation above) once it also has the Tround1 and Treply2 values from device A. While the earlier Tround1 value is probably available, Treply2 may need to be sent in a subsequent frame. Again some implementations may be able pre-compute, Treply, and include it in final message.
Active DS-TWR Application tells RLS to initiate DS-TWR with a specified device. Via APP SAP multiplexed into RLSH-SAP RLS initiates the exchange RLSM-SAP multiplexed into MCPS-SAP invokes MCPS-DATA to initiate send a data frame to the destination device with “Ranging” set, and ACK request, and carrying payload IE to tell the destination RLS to be ready for the final message. Multiplexed MAC Interface (MMI) picks up the MCPS-DATA.confirm and delivers the indication to the RLS with the TX timestamp and ACK RX timestamp) through the RLSM-SAP RLS sends final message of exchange. RLSM-SAP multiplexed into MCPS-SAP invokes MCPS-DATA to initiate send a data frame to the destination device with “Ranging” set, and payload IE to communicate the Tround1 value, and if possible the Treply2 value. Where Treply2 could not be carried in the final message the RLS invokes an additional invokes MCPS-DATA.request to send it. Destination RLS calculates the TOF and reports it to the local or remote consumer (RTLS solver) application (with the node IDs) Including any other useful location aiding data (RSSI, AOA) that the RLS has gathered
Piggy-backed TWR Where we want to perform TWR between a pair of devices for which there is already message flows between the devices, then the TWR exchange and TOF measure may be achieved by piggy-backing the measurement on top of the data messages. Mechanism Details to be defined in next revision… Outline is something like: Intercept an MCPS-DATA.request (with ACK request) to set the “Ranging” parameter, and embed IE to say it is a ranging exchange (so the destination RLS knows what to do) Intercept the MCPS-DATA.confirm and .indication primitives to gather timestamps and other attributes AOA, RSSI etc Generate final MCPS-DATA.request (or intercept a second message) to include IE to communicate Tround and/or Treply times as appropriate to the device calculating the TOF.
Communicating ranging results
At the end of an active TWR exchange, one RLS will calculate the TOF This may be used locally or may need to be sent to a solver that combines TOFs (from the mobile device to several fixed devices) to estimate the location of the mobile device. Steps: RLS completes ranging exchange and gathering the respective Tround and Treply times calculates the TOF. RLS sends the TOF data (including the ID’s of the pair of devices participating in the TWR exchnge) via the RLSH-SAP to the solver via local APP-SAP or appropriate network SAP The RTLS solver application combines the TOF data reports from several TWR exchanges solve the location of the mobile node.
Future work Expand this document to more fully define the scenarios
Identify all the different interactions Between RLS function and lower layer applications Between RLS function and lower layer MAC SAP For each interaction define the parameters necessary and the content For lower layer MAC SAP define the RLS IE … drafting ?
© 2023 SlidePlayer.com Inc.
All rights reserved.