July 2010 doc.: IEEE 802.11-10/0xxxr0 A summary of most recent LS from 3GPP RAN/RAN1 and proposed process for review 13 Jan 2017 Authors: Name Company Phone email Andrew Myles Cisco +61 2 84461010 +61 418 656587 amyles@cisco.com Andrew Myles, Cisco Andrew Myles, Cisco

802.19 WG needs to decide on how to deal with latest and future LS’s from 3GPP RAN1 Executive summary IEEE 802 and 3GPP RAN/RAN1 have been playing “LS ping pong” for more than two years The most recent “shot” (LS) from 3GPP RAN1 contains responses to 14 outstanding issues Some issues are still not resolved, while there is doubt about the resolution of other issues More volunteers are required to spread the load analysing the 3GPP RAN1 responses We also probably need to decide on a revised schedule for any response to 3GPP RAN1 Stepping back … is “LS ping pong” the best way to work with 3GPP RAN1 on LAA and eLAA? Andrew Myles, Cisco

IEEE 802 and 3GPP RAN/RAN1 have been playing “LS ping pong” for more than two years … Jun 2014: Reply LS on Areas of Mutual Interest to 802 LMSC and 3GPP Jul 2014: Areas of Mutual Interest to 802 LMSC and 3GPP Sep 2014: Licensed-Assisted Access using LTE Nov 2014: Coexistence Lessons Learned Mar 2015: Regarding Coexistence of Licensed Assisted Access (LAA) and IEEE 802 Jan 2015: Statement Regarding Coexistence of Licensed Assisted Access (LAA) and IEEE 802 Apr 2015: 802.11 Coexistence Mar 2015: Regarding 1) Clarification of LBT Categories and 2) LAA / 802.11 Coexistence Apr 2015: Clarification of LBT Categories May 2015: Follow-up Liaison Statement Regarding LAA Next page Andrew Myles, Cisco

… IEEE 802 and 3GPP RAN/RAN1 have been playing “LS ping pong” for more than two years … Jun 2015: LS on LAA capabilities and scope Previous page Jun 2015: 3GPP RAN Workshop on Licensed-Assisted Access (LAA) Jun 2015: LS on LAA capabilities and scope Aug 2015: presentation at 29-Aug-15 LAA Workshop Dec 2015: LAA CRs Mar 2016: Comments related to the LAA Specification Jun 2016: Response Liaison Statement to 802 regarding LAA May 2016: Review of 3GPP LAA Specification Rel. 13 Jun 2016: Response Liaison Statement to 802 regarding LAA Next page Andrew Myles, Cisco

… IEEE 802 and 3GPP RAN/RAN1 have been playing “LS ping pong” for more than two years Previous page July 2016: Review of 3GPP LAA Specification Rel. 13 Nov 2015: Response LS to IEEE 802.11 regarding LAA Nov 2016: LS related to ED issue Today Andrew Myles, Cisco

The most recent “shot” (LS) from 3GPP RAN1 contains responses to 14 outstanding issues The following slides contain a summary of the most recent Liaison Statement (Nov 2016) from 3GPP RAN1, which contains responses to LS’s from IEEE 802: July 2016: Review of 3GPP LAA Specification Rel. 13 Nov 2016: LS related to ED issue For each of the 14 outstanding issues (including a number of sub-issues) the following slides: Summarise IEEE 802 comment Summarise 3GPP RAN1 response Evaluate whether the issue has been resolved From the perspective of Andrew Myles Identify any known volunteer to lead a deeper review Andrew Myles, Cisco

Some issues are still not resolved, while there is doubt about the resolution of other issues IEEE 802 comment 3GPP response Issue resolved? Volunteer? 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 Derham 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 Andrew Myles, Cisco

Some issues are still not resolved, while there is doubt about the resolution of other issues IEEE 802 comment 3GPP response Issue resolved? Volunteer? 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 Derham PDED ad hoc 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 Myles 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 Andrew Myles, Cisco

Some issues are still not resolved, while there is doubt about the resolution of other issues IEEE 802 comment 3GPP response Issue resolved? Volunteer? 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 ? Derham 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 Andrew Myles, Cisco

Some issues are still not resolved, while there is doubt about the resolution of other issues IEEE 802 comment 3GPP response Issue resolved? Volunteer? 10 Thanked 3GPP RAN1 for its clarification on CWp adjustment Confirmed IEEE 802 understanding Yes n/a 11 Noted IEEE 802’s comment on quanta of channel sense has been resolved Noted IEEE 802 response 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 Andrew Myles, Cisco

Some issues are still not resolved, while there is doubt about the resolution of other issues IEEE 802 comment 3GPP response Issue resolved? Volunteer? 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 PDED ad hoc 14 Suggested future dialog on coexistence issues Defers to RAN1 ? Andrew Myles, Cisco

More volunteers are required to spread the load analysing the 3GPP RAN1 responses Volunteers have been identified for most of the open issues 8 issues have volunteers 4 are missing volunteers 2 don’t need volunteers However, only two individuals and the PDED ad hoc have volunteered Are there additional volunteers to analyse the responses, and this spread the load? Andrew Myles, Cisco

We also probably need to decide on a revised schedule for any response to 3GPP RAN1 It was originally intended (at least by this author) that a response be sent to 3GPP RAN1 out of the January 2017 meeting in Atlanta Or a decision made not to send a response Unfortunately, not enough analysis was undertaken before the meeting to make this schedule realistic Should we now aim for the March 2017 meeting in Vancouver? This makes approval by the 802 EC easier Is March 2017 too late? Are we already too late? Andrew Myles, Cisco

Stepping back … is “LS ping pong” the best way to work with 3GPP RAN1 on LAA and eLAA? 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 Release 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 effectively ignored  most IEEE 802 requests since then It is also rapidly completing the eLAA Rel 14 specification without any review so far from IEEE 802 How should we collaborate better with 3GPP RAN1 going forward? Or should we give up? Possibly appealing to regulators and “court of pubic opinion”? Have we achieved all we need to achieve? Andrew Myles, Cisco