1. 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

2. 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

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
Page 3

4. 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

5. 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

6. 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

7. 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

8. 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.

9. 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

10. 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.

11. 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

12. 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.

13. 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.

14. 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 ?

15. DISCUSSION ?