| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear All, Adding Mark Hamilton for additional ARC input (and reattaching the figure) Michael - Please see my comments/reply in line below (note I’ve also left your reply intact for readability purposes, further below). Joseph: Yes, your diagram does depict exactly what I was suggesting as the simplest approach. [JL] good to know we are on the same page. Done that way we do not have to make major additions to the MAC clauses where EDCA is described. There is then no requirement for channel number in MLME-CancelTX.request. [JL] agreed – but this mean that there are two logical MAC/PHY entities that are addressable via different MAC SAPs. The separate and distinct MAC SAP is what makes this architecture work. This does not stop
an implementation from only having one MAC and PHY as long as it is possible to switch when necessary (switching may include saving the MAC state, loading the MAC state of the channel being switched to and switching the PHY to the new channel, while remembering
the old channel so switching back is supported). But, we do need to define a way to trigger the switch. However, we should consider what we want to define as the standardized (abstract) way for the higher-layer entity to provide the channel number and channel width to (each of instance of) the MAC entity – is it through the MIB, a special-purpose
MLME primitive, or parameters of a MAUNITDATA primitive? [JL] the current 802.11 TGmd D3.0 (page:line information provide) provides control of the channel number and width to be provided by the MAC entity via the following (though some changes may need to be
made to these entities to work well for OCB):
Using the MIB requires the least change within the TGbd amendment, but is, from my point of view, a poor approach because there is no means (without our writing new, normative text to create one) to synchronize the effect of a MIB update
with activity at the MAC_SAP. Because, in the NGV use cases are ones where dynamic channel changes are likely, this lack of synchronization argues against using the MIB. Creating an MLME request/response primitive for this purpose is fairly easy, and the
timing of the change in relation to both the EDCA transmit queues and the generation of the response can be specified fully within our amendment, thereby providing the necessary synchronization. Including the channel number and width in the radio environment
request and status vectors is the simplest to specify (which is why I proposed it this way in the first place), but implies that the channel is changeable on a PDU-by-PDU basis, which is not our intent, so there would need to be some way to restrict this,
probably negating the simplicity in the process. One advantage of including the channel information in (at least) the radio environment status vector is that we don’t really have the concept of a receive queue in 802.11, but with dynamic channel changes it
is conceivable that a reception occurs on the “old” channel just before a channel switch but is reported at the MAC_SAP after the channel switch, and the higher layer might want to know which channel the PDU was received from. [JL] This is an interesting problem, but I don’t know if agree this could happen. First I think we do have receive queues in 802.11 as we need to reassemble fragmented MPDUs, hence there must be a queue somewhere
to hold the fragments of the MPDU received in successfully received PPDUs, while waiting for any missing fragments. This queue also must support reordering to reassemble the fragmented MSDU. Also related to this is the concept that on the channel switch
the MAC status is saved for the “old” channel and MAC status of the “new” channel is “restored” which I heard discussed on the call, but don’t fully understand. So, what I thought I heard was that the desired is to have Channel “A” being received on the PHY
and MAC, at some point in time (the channel switch time) the status of the MAC is saved, the MAC status for Channel “B” (which was saved previously or if none is available the starting state) is then loaded in to the MAC and PHY is switched to channel “B”
– starting channel “B” Rx/Tx. Then after some time the STA will switch back to Channel “A”
This could be especially important if there are acknowledged transactions where the acknowledgement needs to be sent on the same channel as the PDU being acknowledged was received from. [JL] I agree the STA should ACK any PPDU received before switching channels, this shouldn’t cause much switching delay because the time to transmit an ACK after PPDU reception is short. However, a switching
time that happens to occur during the reception of a PPDU might be an issue if it is desired to complete the reception prior to switching. My inclination is to allow for switching during PPDU reception, which will cause the reception to fail and therefore
remove any obligation to send and ACK. However, if it is desired to allow the reception to complete and be ACKed before switching this will be much more complex to specify. This decision on to interrupt the reception or not may differ depending on the channel.
e.g. It may be desirable to complete the reception of basic safety messages, before switching to a services channel – but switching from the services channel to the basic safety message channel may want to be done before the reception of the service channel
PPDU is completed. I’m not expert enough to provide an expert opinion on what behavior is the best behavior for an ITS system. Hopefully, some experts will provide insight. Regards, Joseph From: Michael Fischer <michael.fischer@xxxxxxx> Joseph: Yes, your diagram does depict exactly what I was suggesting as the simplest approach. Done that way we do not have to make major additions to the MAC clauses where EDCA is described. There is then no requirement for channel number in
MLME-CancelTX.request. However, we should consider what we want to define as the standardized (abstract) way for the higher-layer entity to provide the channel number and channel width to (each of instance of) the MAC entity – is it through the MIB, a special-purpose
MLME primitive, or parameters of a MAUNITDATA primitive? Using the MIB requires the least change within the TGbd amendment, but is, from my point of view, a poor approach because there is no means (without our writing new, normative text to create one) to
synchronize the effect of a MIB update with activity at the MAC_SAP. Because, in the NGV use cases are ones where dynamic channel changes are likely, this lack of synchronization argues against using the MIB. Creating an MLME request/response primitive for
this purpose is fairly easy, and the timing of the change in relation to both the EDCA transmit queues and the generation of the response can be specified fully within our amendment, thereby providing the necessary synchronization. Including the channel number
and width in the radio environment request and status vectors is the simplest to specify (which is why I proposed it this way in the first place), but implies that the channel is changeable on a PDU-by-PDU basis, which is not our intent, so there would need
to be some way to restrict this, probably negating the simplicity in the process. One advantage of including the channel information in (at least) the radio environment status vector is that we don’t really have the concept of a receive queue in 802.11, but
with dynamic channel changes it is conceivable that a reception occurs on the “old” channel just before a channel switch but is reported at the MAC_SAP after the channel switch, and the higher layer might want to know which channel the PDU was received from.
This could be especially important if there are acknowledged transactions where the acknowledgement needs to be sent on the same channel as the PDU being acknowledged was received from. Which approach to channel selection do you think is best? Is the same approach something which you believe can achieve the necessary consensus when put to a vote? --Michael Fischer P.S. Do we need to provide a way for the higher layer to determine how many NGV MAC & PHY entities are present? From: Joseph Levy <Joseph.Levy@xxxxxxxxxxxxxxxx>
Caution: EXT Email
Hi All, After today’s TGbd teleconference I put together the attached figure (Visio) – to further discuss the proposed 1609/802.11 architecture. As illustrated my view is that we should leave the multi-channel capabilities of 1609 to be 1609 capabilities
and simply provide 1609 with a building block (a MAC/PHY 802.11 entity) that they can use to provide their multi-channel capability.
Please see the attached Visio figure. Michael Fischer – I assume this is in line with what we discussed on todays call, if not please correct or comment. I assume based on today’s call that you will be putting together a contribution to clarify the architecture and provide clarification/corrections
to the draft specification. If you would like my support in this activity please let me know.
Regards, Joseph Levy InterDigital 802.11 TGbd Vice Chair 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 |
Attachment:
1609_4-802_11_ArcR0.vsdx
Description: 1609_4-802_11_ArcR0.vsdx