1. Measurement reporting in TGh
May 2002
doc.: IEEE /366r0
Measurement reporting in TGh
Andrew Myles (Cisco Systems)
16 May 2002
Andrew Myles, Cisco Systems
Andrew Myles, Cisco Systems

2. May 2002
doc.: IEEE /366r0
This document explains and discusses the measurement request and reporting structure in the TGh draft
Situation
The TGh draft define a measurement request and reporting structure
Complication
There is some confusion about how it works
Some comments have raised some important issues about the details
Purpose
This document attempts to:
explain the working of the measurement request and reporting structure
Address some of the important issues
Andrew Myles, Cisco Systems
Andrew Myles, Cisco Systems

3. The TGh draft defines an infrastructure for measurement requests and measurement reports
Measurement Request frame
Measurement Report frame
Element …
Element
Element …
Element
Params
Params
Params
Params …
Measurement Report frame
Element …
Element
Params
Params
Andrew Myles, Cisco Systems

4. A Measurement Request frame can contain one or more Measurement Request elements
Action Descriptor field ( )
Category (0)
Action (0)
Action Specific
Dialog Token
Measurement Offset
One or more Measurement Request elements 1 1 1 1 1
variable
Category (0) field indicates Spectrum Management
Action (0) field indicates Measurement Request frame
Action Specific field indicates the time at which the first Measurement Request element should be executed:
0 means execution should start after the offset indicated by the Measurement Offset field
Non-zero values mean execution should start after the specified number of TBTT’s plus the offset indicated by the Measurement Offset field
Note: subsequent Measurement Request elements are processed sequentially and executed in series or in parallel
Dialog Token indicates the unique identity of the request
Measurement Request elements contain the requests
Andrew Myles, Cisco Systems

5. Issue: is the Action Descriptor field necessary?
The Action Descriptor field ( ) should be re-described with each use of an Action frame in
Discussion
It was thought easier to describe the fields in one place that was not TGh specific for easy reuse by other TG’s
Recommendation
No change
Andrew Myles, Cisco Systems

6. Issue: should the Action Specific and Dialog Token fields be defined at the Action Descriptor level?
As currently defined in the Action Descriptor field ( ), the Action Specific and Dialog Token fields are re-definable octets but:
The Dialog Token field can be used for purposes that have nothing to do with being a dialog token
The Action Specific and Dialog Token field descriptions contain examples of use that are TGh specific
Discussion
The current Action Descriptor format was derived from the TGe Action frame proposal with the idea that a familiar format would be more palatable to TGe
Recommendation
Move the Action Specific and Dialog Token field definitions to the Measurement Request frame section in (and the Measurement Report frame in 7.4.2)
Andrew Myles, Cisco Systems

7. Each Measurement Request element contains a request for a measurement in parallel or series with that in any previous element
Measurement Request element ( )
Element ID (38)
Length (variable) 1 1
Measurement Token
Measurement Duration
Measurement ID
Measurement Request 1 2 1
variable
Measurement Token is a non-zero number that is unique among the Measurement Request elements in a Measurement Request frame
Measurement Duration is the length of the measurement
0 means use the length of the previous request element and execute in parallel
Measurement ID identifies the format of the following request field
ID’s are administered by IEEE
Measurement Request contains the details of the request
Andrew Myles, Cisco Systems

8. Issue: should a Measurement Request element contain a single request or multiple requests?
At least comment suggested that the Measurement Request element should be defined to contain multiple measurement requests instead of a single request
Same comment applies to Measurement Report elements
Discussion
The benefit of such a change would be a small saving of octets in a frame containing multiple requests
The cost would be a reasonably significant change in multiple places in the current draft with the risk of introducing additional errors
Recommendation
No change
Andrew Myles, Cisco Systems

9. Issue: should a Measurement Request element contain the Measurement Duration field?
The Measurement Duration field currently indicates:
the duration of a measurement
whether measurements should occur in parallel or series
A better possibility would be to:
Split the functions to avoid overloading the variable
Move the duration function (if required) into the Measurement Request field
Discussion
Splitting the variable will provide extra functionality
whereas measurements in parallel must have the same duration by splitting the variable measurements in parallel could have different durations
measurements would not have to have a duration
Recommendation
Accept (but note that it was my comment)
Andrew Myles, Cisco Systems

10. A Measurement Report frame can contain one or more Measurement Report elements
Action Descriptor field ( )
Category (0)
Action (0)
Action Specific
Dialog Token
One or more Measurement Report elements 1 1 1 1
variable
Category (0) field indicates Spectrum Management
Action (1) field indicates Channel Measurement Report frame
Action Specific field indicates the status of the report frame
O means frame contains report elements in response to request elements
1 means frame contains report elements provided autonomously
2 means frame contains request elements that could not be processed (only allowed for optional request elements)
Dialog Token identifies the request frame that resulted in this report frame
0 if frame contains report elements provided autonomously
Measurement Report elements contain the reports
Andrew Myles, Cisco Systems

11. Issue: should a Measurement Request element contain the Measurement Duration field?
A Measurement Request frame can be answered by multiple Measurement Report frames
If one of the Measurement Report frames is lost (after multiple retries) it may not be possible to interpret the results correctly
Discussion
It is possible to detect missing Measurement Report frames by matching the Measurement Report frame and element dialog tokens with those in the Measurement Report frame and elements
It is also possible to determine that the missing elements make the interpretation of the report ambiguous
Recommendation
Add text that says a STA shall discard any reports that could be ambiguous due to lost Measurement Report frames
Andrew Myles, Cisco Systems

12. Issue: should a mechanism be defined to allow a STA to disable autonomous reports from other STAs?
The current draft does not say how often a autonomous Measurement eport can be sent.
A badly behaved STA could send them continuously with no way for the receiver to stop them
Discussion
A simple solution would be add a mechanism (using a new measurement request/report ID and some text description in 11.6.?) by which an STA (including a AP) could ask another STA (or all STAs) to not send it autonomous reports
The mechanism could be expanded to allow requests like:
Send me anything
Send me radar detections only
Send me nothing
Recommendation
Add appropriate text
Andrew Myles, Cisco Systems

13. A Measurement Report element contains the result of a measurement
Element ID (39)
Length (variable) 1 1
Measurement Token
Measurement Duration
Measurement ID
Measurement Report 1 1 1
variable
Channel Number indicates the channel to which the report element applies
Measurement Token is taken from the corresponding request element
0 means the report element is being sent autonomously
Measurement Duration is the length of the measurement
When first report element in report frame, 0 means use the length of the last report element in the last report with the same Dialog Token and Status
Otherwise, 0 means use the length of the previous report element in this report frame
Measurement ID identifies the format of the following Measurement Request field
ID’s are administered by IEEE
Measurement Report contains the details of the report
Andrew Myles, Cisco Systems

14. Issue: should we timestamp measurements?
For autonomous reports there is no way of knowing when a measurement was undertaken
Discussion
Is it important to know when a measurement took place? In what circumstance that is relevant to radar detection?
It has been suggested that we could add a time stamp to every measurement report based on:
TSF
Some other measure based on TBTT’s
If this feature is required for radio measurement purposes then it could be added later as part of the Measurement ID’s
Recommendation
Add a TSF timestamp – but how many bytes?
Andrew Myles, Cisco Systems