May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 1

doc.: IEEE 802.11-07/0398r2

Submission

Dedicated Protection

Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair stuart@ok-brit.com as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.

Date: 2007-05-16

Name Company Address Phone email Jari Jokela Nokia Visiokatu 3,

Tampere, Finland +358504860445

Jari.jokela@nokia.com

Yossi Tsfati Texas Instruments

26 Zarchin St, Raanana, Israel

+972-97476927

Yossit@ti.com

Artur Zaks Texas Instruments

26 Zarchin St, Raanana, Israel

+972- 9 7476853

Arturz@ti.com

Authors:

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 2

doc.: IEEE 802.11-07/0398r2

Submission

Scope

• Coexistence use cases

• Coexistence challenges using existing 802.11 mechanisms

• Proposal to improve coexistence

• Address concerns raised in TGv at March 2007 meeting

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 3

doc.: IEEE 802.11-07/0398r2

Submission

Mobile Radio technology Spectrum

1 2 3 4 5 6

802.11bg & BT

UWB-Band1

802.11a

GHZ

WiMax

DTV

GPS

Cellular

• Some of the bands are overlapping (BT & WLAN)

• Some bands are extremely close making analog filtering almost impractical (BT/ WLAN & Wimax)

• Lo harmonics overlap with other technologies

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 4

doc.: IEEE 802.11-07/0398r2

Submission

Coexistence in Handset

• Handset can combine multiple access technologies that operate simultaneously:– Have a call coming though WiFi to BT Headset

– Access Internet through WiMAX/WiFi with cellular call terminating on BT Headset

– Play music to the BT Stereo headset from another Handset connected in WiFi adHoc, while accessing Internet through WiMAX

– And other examples can be listed easily

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 5

doc.: IEEE 802.11-07/0398r2

Submission

Wireless Connectivity technologies access principles

Example• 802.11

– Access: CSMA ( infrastructure, AdHoc connection), Scheduled (HCCA, PSMP)

– Handset role: Master (adhoc, EDCA), Slave (HCCA, PSMP)

• 802.16– Access: scheduled TDMA– Handset role: slave

• Bluetooth– Access: scheduled TDMA– Handset role: master, slave

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 6

doc.: IEEE 802.11-07/0398r2

Submission

Antenna configurations• Separate antenna per connectivity technology

– BT –single antenna– WLAN – one or two (MIMO) antennas– WiMAX – two antennas– Pro: simpler solution– Con: footprint on handset, cost

• Shared antennas– BT-WLAN - single antenna– WLAN/WiMAX - two antennas– Pro: footprint, cost– Con: system solution is needed to schedule antenna to be used by specific

access • In practice, in Handset due to cost and physical limitations,

shared antenna approach is more popular that using separate antennas

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 7

doc.: IEEE 802.11-07/0398r2

Submission

Coexistence solution using separate antennas

• Filter out intrusive signals: decouple BT and WLAN; WiMAX and WLAN– Pro: simple system solution– Con: not always possible due to design constraints: filtering 20+

dB• Enable BT Automatic Frequency Hopping (AFH) to

decouple from WLAN– Pro: simple system solution, simultaneous reception of BT and

WLAN is possible– Con: Simultaneous Reception and Transmission of the two

technologies may not be possible due to limited antenna isolation• When WLAN transmit with high power (18dBm) and typ antenna

isolation of 10dB, the BT receiver is compressed and looses sensitivity by about 40dB which makes it impractical to maintain a BT link

• When BT transmit with high power (4dBm at handset) and typ antenna isolation of 10dB, the WLAN receiver is compressed and looses sensitivity by about 40dB

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 8

doc.: IEEE 802.11-07/0398r2

Submission

Challenges using shared antennas• Generally in master/slave configurations the slave has

minimal opportunities to schedule its own receptions/transmission as it likes

• In CSMA operation, the STA can schedule its own transmission, but no guarantee that AP will deliver downlink traffic in time when antenna is connected to WLAN radio

• Since downlink traffic is not synchronized to antenna availability at WLAN packet loss is experienced– Unnecessary retransmissions and reduction of whole BSS

capacity– Rate fallback at AP causing disconnection

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 9

doc.: IEEE 802.11-07/0398r2

Submission

Rate Fallback causing the “Avalanche” Effect

• All APs use rate adaptation techniques to determine the optimal rate for transmission• All APs are using high PER as the main criteria for rate fall back

– PER of over 30% (or even lower) usually causes rate reduction• Since the AP response time to U-APSD trigger frames is non deterministic and spreads over

period of times that are of the order of the BT inactivity period (2.5msec) – There is a chance of AP responded packets to be overlapping with the BT Voice Tx/Rx

– In a co-located radios operation this would cause packet loss and retransmission• The probability of losing a packet increases as the rate of transmission decreases (as depicted

below for VoIP packet length of 244 Bytes (G711 and additional headers)

Network Type 802.11b 802.11g only 802.11g mixed

Rate 1 2 5.5 11 6 12 24 6 12 24

Exchange Length (usec) 2458 1416 794.9 617.5 404 248 168 660 496 416

Fail Rate 98.3 56.6 31.8 24.7 16.2 9.9 6.7 26.4 19.8 16.6

• Once the AP starts reducing the rate it would continue to do so until reaching 1Mbps since the probability of packet loss is increasing as the rate is reduced

• An AP reaching 1Mbps transmission rate may eventually disconnect the STA since it would not be able to transfer hardly any packet to it

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 10

doc.: IEEE 802.11-07/0398r2

Submission

Solutions using existing mechanisms and their limitations

• Synchronizing downlink traffic using channel protection with CTS-to-self control frame

• Re-association to bring the rates up and overcome rate-fallback

• What are the limitations of the existing mechanisms?– Diminished channel capacity

– Service Disruption to other network users due to traffic patterns

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 11

doc.: IEEE 802.11-07/0398r2

Submission

CTS-to-self frame for channel protection

CTS-TO-SELF

ACK

PS-POLL

T1 (3.75mSec for HV3)

T3

T2BT Inactivity period (2.5mSec for HV3)

T4

STA

BT_HP

AP

T5 (NAV)Covers for predicted BT’s Tx/Rx activity AP which comes sooner than AP response time

MSDU

ACK

T6 (AP DL Response Time)

• Using PS-Poll PowerSave Mode • CTS-to-self is used as Channel Protection • NAV contained in the message is suitable to cover for the BT activity which comes sooner than the AP response time• During the NAV duration the entire BSS transport is blocked• The frequency of the CTS-to-self used for channel protection depends on the BT traffic load and effects the BSS throughput

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 12

doc.: IEEE 802.11-07/0398r2

Submission

Using ‘802.11.b' 11Mbps only, 1500 Byte packets, Assuming BT-HP to CTS-to-self =1000uSec

Expected performances for the extremely severe scenario:• 1 or 2 stations having HV3 with CTS-to-self protection • 1 or 2 stations having high downlink throughput• No other stations in the BSS (max theoretical abuse)• Assumes that the WLAN STA has a fairness rule to limit airtime This fairness rule is expressed as the number of BT HP slots that the WLAN needs to wait from the end of the WLAN transaction to the next data pulling (e.g.: next PS-POLL)

Analysis of BSS Throughput UsingCTS-to-self frames

# STA in BSS with Time Scheduling Coexistence Scheme 1 2

WLAN Fairness Factor: Number of BT slots that WLAN waits before pulling MSDU - [expressed in BT

slots] 0 6 12 18 0 6 12 18Used WLAN BW [%] 67 33 22 17 69 42 30 24

Max downlink throughput [Mbps] 3.2 1.6 1.07 0.8 2.16 1.25 0.9 0.7

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 13

doc.: IEEE 802.11-07/0398r2

Submission

Proposal for possible solutions to improve coexistence/ shared antenna operation

• Dedicated protection– Data/Null-data or Management/Control frame discussion– Immediate protection, delayed protection

• Schedule adaptation based on STA synchronization requests– When operating in S-APSD, PSMP modes

• Downlink rate limiting– Management to request AP to limit the rates (so rate fallback will stop at higher rate)

• Co-located interference reporting– Can be used scheduling&rate adaptation purposes

This proposal outlines “dedicated protection” mechanism

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 14

doc.: IEEE 802.11-07/0398r2

Submission

Dedicated Protection:Non-AP STA and AP operation

• When non-AP STA realizes that it needs to protect other radio operation it sends dedicated protection information to the AP

• When the AP receives the dedicated protection information from the non-AP STA it shall not send any unicast frames to the non-AP STA during the protection period.

• Other non-AP STAs can ignore the dedicated protection field.

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 15

doc.: IEEE 802.11-07/0398r2

Submission

Dedicated Protection –Extended protection frame

• Using Data Frame with extended field to the MAC Header as “Piggyback”– New field added to the MAC Header (HT MAC Header assumed)– NULL data frame is sent in case of there is no data required to be sent

Frame Control

Duration/ID Address 1 Address 2 Address 3Sequence

ControlAddress 4

QoS Control

HT ControlDedicated Protection

Octets: 2 2 6 6 6 2 6 2 4 4

• Dedicated protection field is a 4 octets including two sub fields (each with size of 2 octets):– Start Time – the two least significant bytes of TSF timer to

indicate start time– Protection Duration – the duration (in uSec) after the above start

time

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 16

doc.: IEEE 802.11-07/0398r2

Submission

Dedicated Protection use case: defer AP downlink transmission to STA1 when STA1 has High

Priority BT traffic

ACK

3.75 mS Bluetooth HV3 Period

BT Inactivity period (2.5mSec for HV3)

STA2

BT_HP

APMSDU to STA1

ACK

MSDU to AP +

Dedicated Prot Req from t1 for P1

STA1ACK

AP defers transmission to STA1 but can transmit to STA2

MSDU to STA2

t1

P1

Time

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 17

doc.: IEEE 802.11-07/0398r2

Submission

Explicit Dedicated protection Definition using Existing Header Fields (Queue Size = 255)

• Reuse of Queue Size field = 255 ( Unspecified Queue size).• Spec definition, from 7.1.3.5.5 Queue Size subfield:

“A queue size value of 255 is used to indicate an unspecified or unknown size.”• Propose to change the definition of the QOS Control field in QOS Data/QOS Null frames

sent by STA with Bit4=1: indicate request for dedicated downlink protection by setting QueueSize to value 255

• Dedicated DL Protection field will follow QOSControl or HT Control• The new field is not encrypted and muted for MIC AAD construction

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 18

doc.: IEEE 802.11-07/0398r2

Submission

Definition – Option AnalysisOption1:Define Explicitly Using Existing Header Fields (QOSControl)

Option2: Implicit association

Option3: new Ethertype Option4: New data type

Ease of definition/ Impact on spec

Easy: change meaning of the “unspecified queue size” to “dedicated DL protection”.

Impact: Small, easier to get agreement as HCCA is not implemented widely, the value of 255 is off the bounds.

Medium: need to define procedures on AP & STA.

Impact: hard to get agreement, as there is no precedent in 802.11 to handle the header extension in such way

Medium: need to define procedures on AP & STA.

Impact: hard to get agreement, though there are examples in 802.11 ( EAPOL, EAPOL-over-DS)

Complex: define new datatypes and frame exchange sequences

Impact: very hard to get agreement, as TGv perception is no change to HW, defining new datatype and frame exchange sequences means HW change.

Ease of implementation Easy, SW implementation in low-level MAC at AP.

Easy, SW implementation in low-level MAC.

Easy, SW implementation in low-level MAC.

Medium, HW implementation to handle frame exchange sequence.

Effectiveness Fast AP Response time ~100uS can be achieved

Fast AP Response time ~100uS can be achieved

AP Response time ~1mS can be achieved due to need to decrypt SNAP header

AP Response time of sub-100uS is possible

Preference for definition (1-4), High to Low

1 3 2 4

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 19

doc.: IEEE 802.11-07/0398r2

Submission

Support of Dedicated Protection in IBSS• STA with Dedicated Protection capability joining IBSS sends

Broadcast Action Frame with Wireless Network Management Capabilities– All STAs that receive this frame can use Dedicated Protection mechanism

with this STA– Broadcast Action frame with Wireless Network Management Capabilities is

sent periodically, with period of defined in MIB (dot11DedicatedProtectionAdvertizePeriod. )

• IBSS STAs maintain the list of the STAs supporting Dedicated Protection, after receiving the Action frame.

• STAs may use Dedicated Protection with the STAs that are in the list

• After some time the entry is deleted from the list, if Broadcast Action frame is not received from it  

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 20

doc.: IEEE 802.11-07/0398r2

Submission

Support of Dedicated Protection in Mesh-Network

• MP with Dedicated Protection capability joins MESH, it sends Broadcast Action Frame with Wireless Network Management Capabilities– All MPs that receive this frame can use Dedicated Protection

mechanism with this STA– Broadcast Action frame with Wireless Network Management

Capabilities is set periodically, with period defined in MIB

• MESH MPs maintain the list of the MPs supporting Dedicated Protection, after receiving the Action frame

• MPs may use Dedicated Protection with the MPs that are in the list.

• After some time the entry is deleted from the list, if Broadcast Action frame is not received from it

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 21

doc.: IEEE 802.11-07/0398r2

Submission

Broadcast Action Frame used in IBSS/MESH to advertise Dedicated Protection capability

• Define new Action: Capability Advertisement

– Category = Wireless Network Management

– Action = Capability Advertisement (15)

– Action body: Wireless Network Management Capability IE

• Changed Reserved Bit (#7) in the Wireless Network Management Capabilities IE to indicate Dedicated Protection Capability – Set the capability to ‘1’ if Dedicated Protection is supported and

Enabled

– Set the capability to ‘0’ otherwise

Category ActionWireless Network Management

Capabilities IE

1 1

Dialog Token

n

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 22

doc.: IEEE 802.11-07/0398r2

Submission

Addressing specific concerns raised in March meeting

• How to handle DL broadcast/multicast transmissions, i.e. should the protection concern only unicast frames or should BC/MC frames also considered? – Problem: when using Protection, Broadcast traffic can be missed– Recommendation:

• Dedicated Protection is not used for BC/MC traffic, i.e. the AP can send BC/MC frames despite of the Dedicated Protection requests

• Work in PS mode when Protection is needed – to concentrate BC traffic at a single time location and thus limit occasion of traffic loss

• Relay on application level protocols to retransmit BC messages (e.g.: missed ARP messages)

• Throttle antenna switch to allow occasional BC traffic delivery over WLAN, while affecting service shortly on BT

• Do not use Multicast downlink streaming if terminals with coexistence are present in the BSS

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 23

doc.: IEEE 802.11-07/0398r2

Submission

Addressing specific concerns raised in March meeting (cont)

• How the terminal can control when it is sending the protection frame (channel access times can be different when the load is different)?– Having start time&duration in the Dedicated Protection field

makes it easier to control dedicated protection periods => it is not crucial when the Dedicated Protection time is exactly sent given that it is before the targeted protection period

– Use protected frame when other solutions are not possible: AP has slow delivery time, cannot request DL schedule change

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 24

doc.: IEEE 802.11-07/0398r2

Submission

Addressing specific concerns raised in March meeting (cont)

• Should we use control or management frame for extended protection?– Data frame is preferable

• “Piggyback” protection indication to limit overhead• Simpler solution: limited to a lower layers of the implementation• Easy to deploy• Con: need to find a spare bit in the header to distinguish the additional

protection field– Management frame

• Easy to add to the protocol – another Action frame• Use for rate limiting, to set schedule• May effect BSS capacity since additional messages are sent• More complex to deploy

– New Control frame – not preferable solution• Backward compatibility• Requires HW implementation

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 25

doc.: IEEE 802.11-07/0398r2

Submission

Addressing specific concerns raised in March meeting (cont)

• Is this having impact to basic fairness (i.e. QoS)?– When protection is used, single STA is affected – no influence on

other STAs• So actually this can be seen as a positive enhancement from both the

requesting STA and all the other STAs point of view

– Only Downlink is affected

– Implementation in STA has to find balance to meet QOS needed by applications: limit latency, jitter

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 26

doc.: IEEE 802.11-07/0398r2

Submission

Backup Slides

The Original Presentation from March on Dedicated Protection

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 27

doc.: IEEE 802.11-07/0398r2

Submission

Abstract

This presentation introduces a mechanism that enables coordination of DL transmissions in case of multiradio terminals are present in the BSS

Proposed mechanism is related to req. #2071

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 28

doc.: IEEE 802.11-07/0398r2

Submission

Introduction

• Multiradio challenges in terminals were already discussed in 06/0647r7– Key issue is to control WLAN DL transmissions– Normative text in 06/0645r3 (adopted and included in current TGv draft)

contains mechanism where the terminal can report it is realizing performance degradation caused by other co-located system

• The performance of the adopted scheme is dependent on the AP implementation– How good and robust AP’s rate adaptation algorithm and/or scheduling

algorithms are– In best case provides very good performance but assumes some increased

complexity in the AP side

• In this presentation simpler, complementary, scheme is presented

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 29

doc.: IEEE 802.11-07/0398r2

Submission

Multiradio problem in more details

• Simultaneous WLAN and BT (e.g. WLAN VoIP with BT headset) usage is causing problems.

– WLAN and BT TX/RX slots will overlap periodically– Up to 13% packet loss in BT and up to 30% packet loss in WLAN!

• 802.15.2 is not solving the problem– Can control STA side but cannot control AP side, i.e., cannot control WLAN DL transmissions =>

collisions occurs.– If WLAN AP rate adaptation algorithm just decides to go to more robust mode the collisions are just

increasing and whole BSS capacity is decreasing.• Key issue is how to control WLAN DL transmissions so that the collisions does not occur

20ms =32 BT slots

Tx Rx Tx Rx Tx Rx Tx Rx Tx Rx Tx RxBT

WLANRx/Tx Rx/TxTx/Rx

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 30

doc.: IEEE 802.11-07/0398r2

Submission

Proposed scheme – Dedicated protection

• Mechanism to enable a non-AP STA to indicate when it is not able to receive any WLAN transmissions without having any substantial impact to the other non-AP STAs => dedicated protection information.

• Dedicated protection information – Used by the non-AP STA to protect certain amount of time

• During this time the AP shall not send anything to the STA• During this period the AP and the other non-AP STAs can freely transmit

frames (of course subject to the normal channel access procedures)• Typically protected time is short, from hundreds of microseconds to ~

millisecond

• Dedicated protection information is carried– In data frames MAC Header– In new control frame – Dedicated Protection Request

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 31

doc.: IEEE 802.11-07/0398r2

Submission

Non-AP STA and AP operation

• When non-AP STA realizes that it needs to protect other radio operation it sends dedicated protection information to the AP

• When the AP receives the dedicated protection information from the non-AP STA it shall not send any frames (including bc/mc frames) to the non-AP STA during the protection period.

• Other non-AP STAs can ignore the dedicated protection field.

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 32

doc.: IEEE 802.11-07/0398r2

Submission

Extended protection frame types

• Data frame– New field added to the MAC Header (HT MAC Header assumed)

Frame Control

Duration/ID Address 1 Address 2 Address 3Sequence

ControlAddress 4

QoS Control

HT ControlDedicated Protection

Octets: 2 2 6 6 6 2 6 2 4 2

• New control frame – Dedicated Protection Request

Frame Control

Duration/ID RA TADedicated Protection

Octets: 2 2 6 6 2 4

FCS

• Dedicated protection field indicates the requested protection time in microseconds. Dedicated protection time is indicated as on top of normal NAV protection.

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 33

doc.: IEEE 802.11-07/0398r2

Submission

Protect by Dedicated protection element

Examples

Dedicated protection with data frame– Non-AP STA is having UL data

Non-AP STA APData frame with dedicated protection element

ACKProtect by NAV

Dedicated protection with Dedicated Protection Request– Non-AP STA is not having UL data

Non-AP STA APDedicated Protection Request

ACKProtect by NAV

Protect by Dedicated protection element

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 34

doc.: IEEE 802.11-07/0398r2

Submission

Other solutions

• Use power save modes– Not really attractive solution as PS switching is done very often

– Terminal may want to use this mechanism while continuosly in PS mode

• Use CTS-to-self to protect other radio activity– Works but not scalable to enterprise/operator deployments where

the number of associated STAs and load are high

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 35

doc.: IEEE 802.11-07/0398r2

Submission

Conclusions

• Dedicated protection mechanism provides simple means to control co-located interference

• Target is not to replace co-located interference mechanism but have simple complementary mechanism– Can be used if performance issues with co-located interference

reporting scheme

– Can be used if the AP has disabled co-located interference scheme

• No impact to other STAs operation => scalable to enterprise and operator networks

May 2007

Jari Jokela, Yossi Tsfati, Artu Zaks

Slide 36

doc.: IEEE 802.11-07/0398r2

Submission

Straw poll

Is Task Group V supportive of 11-07/0398r1 and interested in having author draft normative text for inclusion into TGv draft?