Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBD] Discussion on primitive to indicate primary channel



Hi Hanseul,

Thanks for initiating this email exchange.

I want to start my comment by clarifying that there are two distinct needs we are discussing at this time:
1) The need for a channel indication as part of the MA-UNITDATA.request primitive. This is what I discussed in 11-20-1421/r1 on Sept. 8.  IEEE 1609 needs this in the data primitive because the enqueuing request might be for either the channel that the device is actively using or for another channel for which the device is maintaining a currently inactive set of queues.  The application might generate a packet for an application that the device is not currently executing, but which it will resume executing, and it may wish to enqueue the packet as an MSDU when it is generated.  For this, we need a channel identifier in the Radio Environment Request Vector
2) The need for flexible designation of one 10 MHz sub-channel of a 20 MHz channel as the primary sub-channel.  If we include the primary channel indication in the Radio Environment Request Vector, as proposed in the comment resolution, the device will have the flexibility to change the primary channel within the 20 MHz channel on a packet-by-packet basis.  If we instead include a primary channel indication in a management primitive, I assume there will be less flexibility to designate which 10 MHz sub-channel is primary.  Note that we would still need a channel identifier in the Radio Environment Request Vector for the reasons noted in (1), but that channel identifier might be simpler without including information about the primary channel.  So, my understanding is that whether we designate the primary channel in the data primitive or in the management primitive might impact how much flexibility we have.  For that reason, my preference would be to keep the primary channel indicator in the Radio Environment Request Vector of the data primitive.  I am interested to hear if there are different views.  Note that IEEE 1609 has not specifically discussed this question of the flexible designation of the primary sub-channel. I believe the current comment resolution proposal will meet IEEE 1609's needs. If instead we decide to use the management primitive for the primary channel designation, I can go back to IEEE 1609 to see if they have an opinion.

Thanks,
John


On Wed, Sep 9, 2020 at 8:55 PM Hanseul Hong <hanseul.hong@xxxxxxxxxxxxxx> wrote:

Hello All,

 

First of all, thanks to John and other TGbd members for preparing the IEEE 1609 view on the related primitives and following discussion.

 

I'm preparing for the comment resolution on 20 MHz channel access, and I have one comment to define the primitive to indicate the OCB primary channel. The comment requests to define the TBD in the following sentence:

-The OCB primary channel which is designated by the upper layer in <TBD> primitives

 

In TGbd, we have agreed on the concept of the primary channel and the secondary channel. In addition, we had a passed motion that the primary channel is decided by the upper layer.

 

I'm trying to find the best place to indicate the primary channel from the upper layer, and I think the best place to put the indication is the radio environment request vector, since it contains parameters such as PPDU format, data rate, number of repetition, etc that higher layer entities utilize to control the NGV transmission. I think putting OCB primary channel indication in the radio environment request vector aligns with the 1609's view.  

 

However, I have a comment that the primary channel should be defined in generic management primitives rather than the data primitives, as the data frames will be transmitted successively.

 

I want to get a consensus to define the primitives that indicate the primary channel. Please let me know your thoughts on this.

 

Thank you


Best Regards,

Hanseul Hong


To unsubscribe from the STDS-802-11-TGBD list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBD&A=1



--
John Kenney
Director and Sr. Principal Researcher
Toyota InfoTech Labs
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644

To unsubscribe from the STDS-802-11-TGBD list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBD&A=1