1 / 8

TGk Comment Report Beacon Request/Report Issues

TGk Comment Report Beacon Request/Report Issues. Steve Emeott (Motorola). Clauses directly related to beacon request and beacon report: 7.3.2.21.6, 7.3.2.22.6, 11.7.8.1 Comments: 7.3.2.21.6; 37 Technical Comments 7.3.2.22.6; 9 Technical Comments 11.7.8.1; 13 Technical Comments.

kenneth-roach
Télécharger la présentation

TGk Comment Report Beacon Request/Report Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TGk Comment ReportBeacon Request/Report Issues Steve Emeott (Motorola)

  2. Clauses directly related to beacon request and beacon report: 7.3.2.21.6, 7.3.2.22.6, 11.7.8.1 Comments: 7.3.2.21.6; 37 Technical Comments 7.3.2.22.6; 9 Technical Comments 11.7.8.1; 13 Technical Comments Beacon Request/Report

  3. List of comments classified as Beacon that had previously been grouped under Misc. 7.3.2.21.6; 432, 433, 434, 436, 437, 443, 445, 446, 449, 460, 462, 463, 465 (13 of the 37 Technical Comments) 7.3.2.22.6; 564, 565, 567, 569, 570, 571, 572, 1008 (8 of the 9 Technical Comments) 11.7.8.1; 124, 127, 130, 131, 133, 135, 140, 141 (8 of the 13 Technical Comments)

  4. Reporting Condition subfield Objections raised to complexity and number of options provided in Reporting Condition subfield (and described in Table k4), and requested significant simplification on basis of unnecessary complexity and that draft offers no solid basis for available set of Reporting Condition options (432, 461, 462, 478) – group discussion Significant Issues

  5. 432 Table k4: Way too many combinations. If we know how these are going to be used, surely we know which one to choose, don’t have them all! If we don't know which one will be used, then this is not the solution! Sample Comments

  6. 461 A sudden drop in signal quality on the serving channel (which does happen say when a person rounds a corner inside a building) could cause a station to release a glut of measurement reports at a time when the destination of the measurement report may be unreachable. How long should the station hold these reports before they are discarded, and if the signal quality of the serving AP returns to acceptable levels how does the station report a return to normal operation and perhaps prevent an unnecessary handover after conditions improve. With all of the complicated reporting conditions provided in Table k4, the draft goes too far in specifying the behaviors of a handover algorithm without the benefit of specifying a complete algorithm which could be reviewed to ensure proper operation. Sample Comments (cont.)

  7. Clause 7 Conditional Reporting Behavior Objections also raised about the somewhat arbitrary normative averaging procedures defined for conditional reporting (132, 434, 445, 456, 459, 460, 470, 471) – group discussion Significant Issues (cont.)

  8. Clause 11 Normative Behaviors Objections raised about missing and/or unnecessary station behaviors in beacon request/report procedure (124, 132, 133, 134, 136, 141) – submission probably needed to clean things up a bit, once neighbor request issues worked through Other Comment Areas

More Related