TG 5 Running Ad Hoc Telecom Notes
Hawaii Ad Hoc:
Add notes and definitions from first meeting in Hawaii. [Allen will add these when he and the definitions document finds them.]
Telecom Meetings:
February 6, 2006, 10:03 p.m. EST
Attendees:
Ho-In Jeon
Myung Lee
Michael Sim
Richard Wilson
Sebastian Max
Lothar (sp? – please correct)
Art Austin
James Gilb
James Allen.
Sebastian summarized the agenda.
The major goal of these calls is to determine:
1-can we align multiple ideas to create a proposal that could be confirmed in March or
2-do we have to default to having more than one recommended practice in the proposal per the Shvodian motion.
The first and pivotal technical issue is the access architecture. Can we come together to one proposal at the big blocks and align with idea and the optional elements. If not then we’ll work on parallel chapters on summary.
At the last meeting we did not agree on how to do beaconing. We revisited the application scenarios.
1 – there may be slow adoptions so non mesh networks would be the initial sales, growing to meshed networks as the density and need increases (many in network that can participate in a few mesh), and
2 – meshing is needed with the first products so that it is available and in the first products and is ready as the need increases (many mesh networks of all devices).
The concepts of PNC, PNC Plus (capable of meshing), device (stupid), device-plus (capable of meshing) as discussed in Hawaii were reviewed.
There was a discussion about the super frame and beacon timing constraints for each approach and a few comments on the 15.3b capabilities. For example, MCTAs can have a broadcast mode.
The Market discussion continued.
Sim discussed his proposal.
Max discussed his proposal and the levels of hierarchy. All devices can decide medium access time. Need hierarchy structure but too many levels won’t scale. A two level approach is OK by him.
We discussed the concept that some of the mesh parameters and rules might be PHY speed and range dependant. This is an area we may want to address later on.
The different proposals and the pros and cons of each (efficiency, signaling requirements, robustness….) were discussed.
Since these meetings will be difficult without the ability to draw and explain concepts quickly, Sebastian agreed to try to publish by Friday Feb. 10th, a merged proposal or examples of issues, or discussion of why things can’t be merged, for discussion at the next meeting.
Meetings were scheduled for the next 3 Tuesdays at 10 am EST.
Tuesday, February 14, 2006
10 a.m. EST
Sebastian Max
Guido Hiertz
Dee Denteneer
Michael Sim
James Allen
Myung Lee
Chun-Ting Chou
Terry Martin
2 connections that failed to announce
Regarding the status of the down selection process: Lee will contact Austin about the status.
Regarding these minutes, the email sent last week didn’t make it past the listserver so these updated minutes will be sent to day.
Sim presented “TG5 Teleconference Discussion.ppt”.
Regarding the generic architecture slide, route management and maintenance may be in different locations and planes. User and management services, for example, may be different for meshes. Comments on the slide were requested and feedback is due Friday. In the feedback, try to indicate what functions are in each new block, even if the block is “above” the MAC.
It was suggested that it would be good to write into the standard, which functions were in the hardware (lower) MAC and which were in software. We’ll keep that distinction in mind because it is important to the concept of upgradeable systems and flexibility, but H/W – S/W splits are implementation dependent and not in scope.
Do we need to define the difference between MAC Function and MAC Feature in the definitions document?
On the slide labeled: “Medium Access Time Slot” we discussed whether the slot should be based on a fixed number of uSec., or be granular to one uSec and have the protocol determine how they are lumped together into bigger preset slots for a specific use, like for Meshing. There was discussion about overhead, optimization, and proposed CTA sizes. This turns out to be a question about efficiency and application requirements. Since we don’t have to set slot direction now, we moved on to the more important decisions. When we return to this, we need to decide if overhead or flexibility is more important.
The presenters chose 256 uSec per slot in the current proposal. The presentors tried 1uSec. and are willing to model the different approaches. The current proposers were concerned that reservation info has to be sent several times, which “gets nasty with microseconds as a basis”. They assumed fixed widths, static network (not mobile), in home, all devices mesh (beacon) and it provided good simulation results. Allen can look at his 15.3 development system to see if he can extract real measurements for the dynamic distribution of slot size in normal operation.
It was also suggested that slot widths be allowed to be PHY dependent. Perhaps the right approach is to have the ability to fix packet width but as a result of a flexible basic mechanism.
Slide: Beaconing.
There was discussion around the different approaches and the two beacon slides.
Question: Why does the proposal have more than one beacon per frame when a single 15.3 beacon can support mesh? Answer: Because the first beacon allows for backwards compatibility (legacy devices) and the new mesh beacon allows for optimization and new information & features for meshing. The overhead may not be very different. The proposers were interested in the possibility that even if meshing were not needed in the early roll out of product (due to a low density of devices needed to support mesh), that the protocol could be converted to a Mesh based architecture if that were the dominate requirement in the future.
Question: Isn’t it harder to coordinate and use beacons spread out over the entire super frame (per 15.3) than to concentrate them into one beacon period? Answer: Sim didn’t think so and explained his approach and some capabilities within 15.3. He also explained that the Cap is partly there for communicating command and network command and response to non-beaconing devices.
There was a long discussion about hidden devices and why the proposer thought that all devices had to beacon or risk interfering with the network, a condition under which a mesh could not survive. We’ll pick this discussion up later. The alternative view was also discussed based on existing 15.3 methods.
It was reiterated that beaconing is one mechanism where we need to come together and we need to try to reach a compromise.
The question was asked: “Is it possible to have a protocol that adapts to the situation and if so, do we agree to want it or not.” This will be the main topic of the next meeting.
Discussion continued about the different beacon structures and dual beacon methods, how to track two separate beacon periods, how to avoid hidden PNCs or hidden devices, how to sync CTAs between networks to avoid the resulting problem, and how 15.3 currently deals with the issue.
Michael and Sebastian will try to document their suggestions again, by Friday.
Myung briefly discussed the Denver meeting agenda.
Next meeting is February 21st, same time and call-in data.
The meeting ended at 11:37 a.m. EST