Re: [STDS-802-11] Volunteers requested to lead discussions on each issue

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

G’day all

I have had volunteers so far to address many of the items, as documented in the following table. Further volunteers are sought, and it is OK to provide alternative perspectives on items for which there is already a volunteer

I suggest that volunteers attempt to use a common structure for documenting a response for each item as follows, which should assist putting together a response to 3GPP (if that is what we decide to do)

· Situation

o A summary of the issue and the liaison discussions so far

o Let’s keep this section down to, say, half a page if possible

· Problem

o Explanation of why the 3GPP RAN1 response is acceptable or unacceptable

· Next steps

o Is there consensus?

o If note, what are we asking to achieve consensus?

Please notify me as you upload documents relating to each item. It might be useful to have one issue per document so that all the responses do not need to be completed before document upload

Andrew

Issue	IEEE 802 comment	Volunteer?	Issue resolved?
1-1	Requested that 3GPP RAN1 acknowledge transmission of energy to block channel should be avoided	Yes	No
1-2	Suggested transmission of blocking energy could be avoided by defining multiple sub-frame boundaries		?
1-3	Requested 3GPP RAN1 confirm that HARQ operation is not related to comment 1-1		?
2	Requested 3GPP RAN1 impose additional constraints on DRS overheads	No	?
3	Requests 3GPP RAN1 to consider an ED threshold based on a more realistic channel model	Yes	No
4	Requested that 3GPP RAN1 align LAA & 802.11 slots to preserve efficiency	Yes	No
5	Suggested resolution of the multi-channel aggregation issue be postponed until coexistence tests can be run	Yes	Yes
6	Requested confirmation that it is mandatory to end transmissions at the shortest subframe boundary and further enhancements in LAA Rel 14.	Yes	?
7	Requested minimum duration be defined in LAA Rel. 13 and a subframe of one OFDM symbol be defined in LAA Rel. 14	Yes	?
8	Requested alignment of TxOP rules with those in ETSI BRAN EN 301 893	Yes	?
9	Suggested resolution of the channel access contention window issue be postponed until further tests and simulations have been completed	No	?
10	Thanked 3GPP RAN1 for its clarification on CWp adjustment	None required	Yes
11	Noted IEEE 802’s comment on quanta of channel sense has been resolved	None required	Yes
12-1	Noted a remaining issue related to LAA Rel. 13’s backoff mechanism	No	?
12-2	Noted an ambiguity in the LAA access mechanism	No	?

Issue	IEEE 802 comment	3GPP response	Issue resolved?
13	Requested support for PD-based channel access in a future release of LAA specification	Will be addressed in PDED ad hoc	No
14	Suggested future dialog on coexistence issues	None required	Yes

From: Andrew Myles (amyles)
Sent: Sunday, 11 December 2016 12:12 PM
To: STDS-802-19@xxxxxxxxxxxxxxxxx; *** IEEE stds-802-11 List ***
Subject: Volunteers requested to lead discussions on each issue in most recent 3GPP RAN1 response

G’day all

Action: request for volunteers to lead discussions on each issue in most recent 3GPP RAN1 response

In July 2016, IEEE 802 sent 3GPP RAN1 a liaison related to outstanding comments on LAA Rel. 13 from a previous liaison exchange. In late November 2016, 3GPP RAN1 finally responded. The 3GPP RAN1 liaison also included a response to a liaison from IEEE 802 sent in November 2016 related to energy thresholds

In January 2017, IEEE 802.19 WG and IEEE 802.11 PDED ad hoc will consider various aspects of the most recent 3GPP RAN1 response. The discussions in January will go much more efficiently if people are prepared beforehand. The following table summarises the various open issues. I would like to issue a call for IEEE 802 participants to volunteer to lead discussions on each of the open issues, and ultimately to generate text for consideration in January 2017. Please volunteer by sending me an e-mail.

A meta issue arises as to whether IEEE 802 should continue this process of “liaison ping pong”? Back in late 2015, 3GPP RAN leadership committed to not closing the Rel 13 specification until there was consensus from all stakeholders. It was explicitly stated that IEEE 802 was one of those stakeholders. However, 3GPP RAN1 closed the Rel 13 specification before it had even responded to the initial comments from IEEE 802, and has ignored a number of IEEE 802 requests since then. Thoughts are also sought on how to collaborate better with 3GPP RAN1 going forward.

Below is a summary of issues that arose from IEEE 802 liaison in July 2016 (the liaison was developed in IEEE 802.19 WG)

Issue	IEEE 802 comment	3GPP response	Issue resolved?
1-1	Requested that 3GPP RAN1 acknowledge transmission of energy to block channel should be avoided	Ignored the substance of IEEE 802 argument but stated that they may include a statement (not yet agreed) to suggest such transmissions should be “minimised”	No
1-2	Suggested transmission of blocking energy could be avoided by defining multiple sub-frame boundaries	Stated that later versions of LAA may include this functionality	?
1-3	Requested 3GPP RAN1 confirm that HARQ operation is not related to comment 1-1	?	?
2	Requested 3GPP RAN1 impose additional constraints on DRS overheads	Declined to impose constraints but asserted they were not needed in practice	?
3	Requests 3GPP RAN1 to consider an ED threshold based on a more realistic channel model	Declined to make any changes based on assertion that current threshold was determined after consensus among 3GPP and IEEE 802 stakeholders. However, noted that the threshold will be evaluated by RAN4	No
4	Requested that 3GPP RAN1 align LAA & 802.11 slots to preserve efficiency	Rejected all aspects of the IEEE 802 request. Aside: in doing so, they actually made a good case to require detection and transmission of IEEE 802.11 preambles and NAVs	No
5	Suggested resolution of the multi-channel aggregation issue be postponed until coexistence tests can be run	Agreed to wait for IEEE 802 input	Yes
6	Requested confirmation that it is mandatory to end transmissions at the shortest subframe boundary and further enhancements in LAA Rel 14.	Ignored request in relation to accommodating partial sub-frames of one OFDM symbol duration	?
7	Requested minimum duration be defined in LAA Rel. 13 and a subframe of one OFDM symbol be defined in LAA Rel. 14	Ignored request in relation to Rel 13, but noted some related work is occurring in Rel 14	?
8	Requested alignment of TxOP rules with those in ETSI BRAN EN 301 893	Rejected request on the basis there is no need to follow ETSI BRAN rules outside Europe	?
9	Suggested resolution of the channel access contention window issue be postponed until further tests and simulations have been completed	Responded to various elements of IEEE 802 response	?
10	Thanked 3GPP RAN1 for its clarification on CWp adjustment	Confirmed IEEE 802 understanding	Yes
11	Noted IEEE 802’s comment on quanta of channel sense has been resolved	Noted IEEE 802 response	Yes
12-1	Noted a remaining issue related to LAA Rel. 13’s backoff mechanism	Asserted LAA “can” maintain slot alignment by monitoring the channel; also that any non-alignment is mitigated by checking channel for defer period	?
12-2	Noted an ambiguity in the LAA access mechanism	Proposed a clarification that resolves the ambiguity	?

Below is a summary of issues that arose from IEEE 802 liaison in November 2016 (the liaison was developed in IEEE 802 PDED ad hoc)

Issue	IEEE 802 comment	3GPP response	Issue resolved?
13	Requested support for PD-based channel access in a future release of LAA specification	Rejected request on basis that ED is a viable technology neutral solution which can ensure fair coexistence with IEEE 802.11 devices	No
14	Suggested future dialog on coexistence issues	Accepted	Yes

Andrew Myles


Andrew Myles Manager, Enterprise Standards amyles@xxxxxxxxx Phone: +61 2 8446 1010 Mobile: +61 418 656587	Cisco Systems Limited The Forum 201 Pacific Highway St Leonards 2065 AUSTRALIA Cisco.com

If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.

Re: [STDS-802-11] Volunteers requested to lead discussions on each issue in most recent 3GPP RAN1 response