| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hello all, 802.11 has the following mechanisms: 1.
TXOP error continuation. A STA owning a TXOP that misses a response can recover by transmission after a PIFS, and can transmit to another STA. 2.
RDG. Effectively transfers ownership of the balance of the current TXOP to another STA. But that “balance” is constrained in that other STA can only talk to the original
STA. 3.
HCCA. This is a polled mechanism where the HC grants a sequence of TXOPs to other STAs. The HC remains in control of who owns a TXOP, and the duration of that TXOP. 4.
PSMP. The AP indicates a sequence of downlink and uplink slots to other STAs. There is some flexibility for recovery by the AP, but not by other STAs. The first two mechanisms are limited by the original TXOP boundaries and apply to both STAs and APs. The TXOP limits are determined by the AP by signalling in the beacon. The second two mechanisms are for APs to manage the medium and are not limited to a single TXOP limit. Note that “error recovery” is easy to specify wrongly. There has to be an unambiguous understanding of who can transmit next during a TXOP, otherwise it changes from a region of
contention-free operation into something else. Best Regards, Adrian P STEPHENS Tel: +44 (1793) 404825 (office) ---------------------------------------------- From: Mark Hamilton [mailto:mark.hamilton2152@xxxxxxxxx]
Osama, I’m thinking of RDG, HCCA, PSMP, and probably some more that escape me at the moment. Mark From: Osama AboulMagd [mailto:Osama.AboulMagd@xxxxxxxxxx]
Hi Mark, I am just curious what mechanism in 802.11 allows the continuation of a TXOP by another device. Are you referring to RDG? Or you have something else in mind? Regards; Osama. From: Mark Hamilton [mailto:mark.hamilton2152@xxxxxxxxx]
Thanks, Andrew. You’re right, I needed to review the slides fully. After looking at the context set up by slides 37 and 38, slide 39 seems good the way it is. I do note that Wi-Fi allows continuation TxOPs by another device, without any LBT, by depending on the (NAV) reservation to solve the hidden node problem. So, we could perhaps discuss that if LAA
did use (and respect) a common reservation mechanism, then it could also do such continuations without LBT. But, trying to merge all these combinations of possibilities into the slideware at this point, is just too complex. Just something to think about
during follow-on discussions, perhaps. Thanks for all this hard work! Mark From: Andrew Myles (amyles) [mailto:amyles@xxxxxxxxx]
G’day Mark MH> I think it depends on the context in which we say this. That statement is good. But is it clear that this could include either or both DL and
UL traffic, within the same TxOP? That was my intent, but I will leave it to you to review slide 39 and suggest changes in context MH> To Alireza’s point, I think we also need to say somewhere that UL traffic either must be within a continued TxOP, or it needs to do a category 4 LBT. We (802) believe that it is just as important
for UL traffic to provide the same coexistence mechanism, as it is for DL. Would you like me to add something along those lines to slide 39? Explicit text would be great, because I am going blind on this document Andrew From: Mark Hamilton [mailto:mark.hamilton2152@xxxxxxxxx]
Andrew, I think it depends on the context in which we say this. That statement is good. But is it clear that this could include either or both DL and UL traffic, within the same TxOP? To Alireza’s point, I think we also need to say somewhere that UL traffic either must be within a continued TxOP, or it needs to do a category 4 LBT. We (802) believe that it is just as important
for UL traffic to provide the same coexistence mechanism, as it is for DL. Mark From: Andrew Myles (amyles) [mailto:amyles@xxxxxxxxx]
G'day Mark The current version states, after a discussion with Alireza this morning ·
Proposal: IEEE 802 tentatively proposes that a device may continue a TxOP obtained by another device immediately after a “defer” period equivalent to PIFS o
IEEE 802 expects that this topic would be subject to further joint collaboration, including investigation using simulations, by 3GPP, IEEE 802 and other interested stakeholders Does that work? Andrew -----Original Message----- Alireza, I agree with your intent, and general direction.
I would add, however, that I can see a reasonable case for an UL mechanism which is both scheduled and "protected" in some fashion so as to be part of the same TxOP of a DL, where the DL did the category 4 LBT. This
would analogous to several mechanisms in 802.11 itself, where "responding" STAs can transmit a SIFS after an enabling/triggering reception. The challenge is that if the LAA transmissions can't be back-to-back with no gap (and I suspect back-to-back might
be a challenge for LAA?) then the medium would need to be managed so that the overlapping 802.11 system doesn't see idle medium and get confused that the TxOP is complete. So, can we say that UL should either use (consider) category 4 LBT, or a mechanism which creates a "TxOP continuation" on the medium. (And, of course, our suggested limits on maximum TxOP time would still apply.) Mark -----Original Message----- From: Alireza Babaei [mailto:A.Babaei@xxxxxxxxxxxxx] Sent: Tuesday, August 04, 2015 4:59 PM To: STDS-802-19@xxxxxxxxxxxxxxxxx Subject: Re: [802.19] Request for suggestions to make 19-15-0063 better! Hi Andrew, Thanks again for putting together this presentation. I have a comment regarding the LBT requirements in UL LAA. So far, only LAA DL transmissions is recommended to use LBT category 4 in 3GPP. For UL, LBT is recommended,
without specifying which category. In fact, it has been the intention of 3GPP to use different LBT category for UL from DL. In 3GPP TR 36.889, §9, Conclusion: "Based on the evaluations and findings in Section 8, it is recommended that the channel access framework defined in section 7.2.1.6 be adopted for LAA. The channel access framework includes a category 4 LBT scheme including random backoff and variable contention windows at least for the downlink data transmissions. It is recommended that the key parameters of the
LBT scheme such as contention windows and defer periods should be configurable within limits to enable fair coexistence with other technologies operating in unlicensed spectrum. It is recommended that LAA supports uplink LBT at the UE. In LAA systems, where
the UE¹s uplink transmissions are controlled by the eNB, the uplink channel access scheme can be different from the downlink channel access scheme for an LAA SCell." §7.2.1.6: "It is recommended that a Category 4 LBT mechanism is the baseline at least for LAA DL transmission bursts containing PDSCH. It is recommended that LAA supports uplink LBT at the UE. The UL LBT scheme can be different from the DL LBT scheme (e.g. by using different LBT mechanisms or parameters) for example, since the LAA UL is based on scheduled
access which affects a UE¹s channel contention opportunities. Other considerations motivating a different UL LBT scheme include, but are not limited to, multiplexing of multiple UEs in a single subframe. The candidates for DL and UL LBT that have been considered in the study
item for the case where LAA supports both DL and UL transmissions are listed in Section 8.3.2.2." 3GPP is arguing that LBT category 4 should not be used for UL LAA because it affects LAA eNB UL scheduling. On the other hands, similar arguments in favor of an exponential backoff mechanism holds for both UL and DL
LAA transmissions. I recommend to add a proposal that LBT category 4 be considered for UL LAA as well. Regards, Alireza On 8/2/15, 11:18 PM, "Andrew Myles (amyles)" <amyles@xxxxxxxxx> wrote: >G'day all > >As promised the latest version is at >https://mentor.ieee.org/802.19/dcn/15/19-15-0063-04-0000-proposal-for-i >eee >-802-submission-to-3gpp.pptx > >Comments welcome ... and thanks to all those that have provided
>comments so far. The comments have made the document much better! :) > >It is still a little long but it is structured in a way that means it
>can be presented in a time that represents the time available > >Andrew > >-----Original Message----- >From: Andrew Myles (amyles) >Sent: Monday, 3 August 2015 1:11 PM >To: 'yamadaakira@xxxxxxxxxxxxx';
STDS-802-19@xxxxxxxxxxxxxxxxx >Subject: RE: [802.19] Request for suggestions to make 19-15-0063 better! > >G'day Akira > >Done! Thanks for your input > >I will upload a new version later today (my time) > >Andrew > > >-----Original Message----- >From: Akira Yamada [mailto:yamadaakira@xxxxxxxxxxxxx] >Sent: Friday, 31 July 2015 5:41 PM >To: STDS-802-19@xxxxxxxxxxxxxxxxx; Andrew Myles (amyles) >Subject: Re: [802.19] Request for suggestions to make 19-15-0063 better! > >Dear Andrew-- I appreciate your creating great presentation material
>for the upcoming LAA workshop. > >Regarding my comment in the previous teleconference on TxOP duration in
>slide p34, please refer to the Section 4.3.2 in TR36.889-d00. Burst
>transmission duration (=TxOP) in Japanese regulation is limited <
>4.0ms, to enable co-existance among several systems in 5GHz band. It
>looks "4ms" >is the most severe rule compared with other countries. >That's why 3GPP simulates co-ex using TxOP < 4ms. Then, I would suggst
>change "5ms" to "4ms" in slide P34. Please let me know if there's any
>concern. > >Best Regards >Akira > >Akira Yamada >Research Laboratories, NTT DOCOMO,INC. > > > >On 2015/07/28 14:00, Andrew Myles (amyles) wrote: >> G'day all >> >> The latest version of the proposed 802 submission to the 3GPP
>> workshop is >> >>https://mentor.ieee.org/802.19/dcn/15/19-15-0063-03-0000-proposal-for- >>iee >>e-802-submission-to-3gpp.pptx. >> Thank you to those who provided comments >> >> Roger, I will be attending the 802.19 call but may be a couple of
>> minutes late >> >> Andrew >> >> *From:*Andrew Myles (amyles) >> *Sent:* Tuesday, 21 July 2015 12:22 PM >> *To:* STDS-802-19@xxxxxxxxxxxxxxxxx >> *Subject:* [802.19] Request for suggestions to make 19-15-0063 better! >> >> G'day all >> >> Last week I presented >> https://mentor.ieee.org/802.19/dcn/15/19-15-0063-00-0000-proposal-for >> - ieee-802-submission-to-3gpp.pptx as the basis of a possible
>> submission from IEEE 802 to the 3GPP Workshop at the end of August. >> Many people provided excellent comments and suggested refinements
>> during the meeting. As requested, some people have sent me their
>> comments via e-mail. However, many have not yet done so. Please send
>> me any comments or suggestions so that I can incorporate them into
>> the next version for discussion at the upcoming >> 802.19 WG teleconferences. And on that topic, could someone please >> send out details for the scheduled teleconferences; when, where and how? >> >> Steve, the draft minutes are incorrect. The session at which "/Jingyi
>> Zhou and Mingxi Fan presented a Liaison presentation on LTE-U, in
>> document 802.19/15-57r1/." was held on Tuesday, 14 July and not
>> Wednesday, 15 July. >> >> Andrew >> |