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

Re: [802.19] Request for suggestions to make 19-15-0063 better!



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)
Tel: +1 (971) 330 6025 (mobile)

 

----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

 

From: Mark Hamilton [mailto:mark.hamilton2152@xxxxxxxxx]
Sent: 06 August 2015 18:17
To: STDS-802-19@xxxxxxxxxxxxxxxxx
Subject: Re: [802.19] Request for suggestions to make 19-15-0063 better!

 

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]
Sent: Thursday, August 06, 2015 10:53 AM
To: Mark Hamilton <
mark.hamilton2152@xxxxxxxxx>; STDS-802-19@xxxxxxxxxxxxxxxxx
Subject: RE: [802.19] Request for suggestions to make 19-15-0063 better!

 

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]
Sent: August-06-15 12:38 PM
To:
STDS-802-19@xxxxxxxxxxxxxxxxx
Subject: Re: [802.19] Request for suggestions to make 19-15-0063 better!

 

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]
Sent: Wednesday, August 05, 2015 10:48 PM
To: Mark Hamilton <
mark.hamilton2152@xxxxxxxxx>; STDS-802-19@xxxxxxxxxxxxxxxxx
Subject: RE: [802.19] Request for suggestions to make 19-15-0063 better!

 

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]
Sent: Thursday, 6 August 2015 2:34 PM
To: Andrew Myles (amyles);
STDS-802-19@xxxxxxxxxxxxxxxxx
Subject: RE: [802.19] Request for suggestions to make 19-15-0063 better!

 

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]
Sent: Wednesday, August 05, 2015 9:44 PM
To: Mark Hamilton <
mark.hamilton2152@xxxxxxxxx>; STDS-802-19@xxxxxxxxxxxxxxxxx
Subject: RE: [802.19] Request for suggestions to make 19-15-0063 better!

 

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-----
From: Mark Hamilton [
mailto:mark.hamilton2152@xxxxxxxxx]
Sent: Thursday, 6 August 2015 12:24 AM
To:
STDS-802-19@xxxxxxxxxxxxxxxxx
Subject: Re: [802.19] Request for suggestions to make 19-15-0063 better!

 

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.

>TEL:+81-46-840-3759

>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

>>