doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 1 Requirements and Implementations for Intra-flow/Intra-AC DiffServ Date: Authors:

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 2 Abstract One of the goals of VTS is to enable link layer adaptation on differentiated frames in a video stream according to channel conditions. This requires an intra-flow/intra-AC differentiated service (intra-Flow DiffServ), which is not supported in e QoS amendments. This proposal discusses the requirements on link layer intra-flow DiffServ and presents solutions accordingly.

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 3 Why we need intra-flow/intra-AC DiffServ? Approach Possible Differentiation Fields Solution 1: Modify QoS control field Solution 2: Add a 2-byte new field before Frame body Compatibility to e Management frame modifications for supporting intra- flow DiffServ Outlines

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 4 Why we need intra-flow/intra-AC DiffServ? VTS PAR scope proposed the following MAC enhancement –Graceful degradation of audio video streams when there is insufficient channel capacity, by enabling packet discarding without any requirement for deep packet inspection. –Intra-Access Category prioritization of transport streams by modifying EDCA timing and parameter selection without any requirement for deep packet inspection. –Improved link reliability and low jitter characteristics for multicast/broadcast audio video streams Differentiated frames have different importance in a video transport stream, e.g., –Video content dependent MAC frames, e.g. SVC base layer or enhance layer; I,P,B frames in MPEG-2 or H.264 Region of interest based encoding –Channel coding frames, e.g. FEC and/or ARQ

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 5 Approach Basic idea: define new information fields in MAC frame to realize frame differentiation without requiring deep frame inspection. Information required: –VTS flag For distinguishing the VTS MAC frames against legacy frames –VTS stream identification (VTS-SID) For a pair of source and destination addresses, multiple streams may be served. Need to differentiate one stream from another, so that intra-flow (aka. intra-stream) differentiation can be done for each stream In case of intra-AC (Access Category of EDCA), VTS-SID may not be required –VTS stream intra-flow differentiation fields Used for frame differentiation within one video flow, e.g., –I,P,B frames in MPEG-2 video flow; –video, audio, FEC packets in one video flow Provide the frame dropping criteria when there is insufficient channel capacity

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 6 Possible Differentiation Fields Priority –Corresponding to content dependent frames for intra-flow or intra- AC Dropping precedence –How to drop Frame category –Video/Audio –FEC

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 7 Solution 1: Modify QoS control field Applicable frame (sub) types Bits 0–3 Bit 4Bits 5-6Bit 7Bits 8–15 QoS (+)CF-Poll frames sent by HCTIDEOSPAck PolicyReservedTXOP Limit QoS Data, QoS Null, and QoS Data+CF-Ack frames sent by HC TIDEOSPAck Policy0QAP PS Buffer State TIDEOSPAck Policy1(VTS flag)Intra-flow/Intra-AC information QoS data frames sent by non-AP QSTAs TID0Ack Policy0TXOP Duration Requested TID1Ack Policy0Queue Size TID0Ack Policy1(VTS flag)Intra-flow/Intra-AC information TID1Ack Policy1(VTS flag)Intra-flow/Intra-AC information The TID subfield (4 bits) identifies the TC or TS to which the corresponding MSDU, or fragment thereof, in the Frame Body field belongs. The EOSP subfield (1 bit) is used by the HC to indicate the end of the current service period (SP). The Ack Policy subfield (2 bits) identifies the acknowledgement policy. 00=normal Ack, 10=No Ack, 01= No explicit acknowledgment. 11= Block Ack Bit 7 flag indicates it is a VTS frame with intra-flow/ intra-Access Category (AC) information included. When the flag is set, intra-flow/intra-Access Category field is contained in bits When the flag is not set, other information is contained in bits (Cannot use Bit 7 due to confliction with TGn A- MPDU indicator). However, bits 8-15 is still used for intra-flow/intra-AC info, VTS-flag is set in the TSPEC associated with a TC or TS.

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 8 Intra-flow / Intra-AC diffServ information field Priority subfield (2 bits) indicates the priority of the frame in the access category. Drop precedence subfield (2 bits) indicates how the frame is dropped. B12B13 = 00: no special action, 01: drop if necessary, 10: drop all if necessary, 11: reserved Frame category (1 bit) indicates if the frame is an FEC frame if it is set to 1. (We may want to combine it with Drop precedence to give more choices.) Reserved (3 bits), however, in case of frame is “QoS Data, QoS Null, and QoS Data+CF-Ack frames sent by HC”, B9 (buffer status indicator in QAP PS buffer status field should) set to 0. Avoid confusion for non-VTS devices. Drop Precedence Priority Reserved B8B10 B11B12 B15B13B14 Frame category

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 9 A TSPEC for each flow / AC TID indicates AC (0-7) or flow (8-15). For VTS, a TSPEC management frame must be used to specify parameters of a AC or a flow. B18 = 1 (VTS flag) indicates there are intra-AC / intra-flow diffServ information available in QoS control field bits 8-15 for frames with same SA+TID. In case of TID = 8-15, a VTS frame needs to make sure Access policy = 01 (EDCA) and UP (user priority) = AC (access category), in order to compatible with EDCA. Bits: B0B7B8B9B23 Access policy = 01 B11B13 ReservedUP B18B21B22 TS Info TSPEC element TS Info field Drop Precedence Priority Reserved intra-flow/intra-AC information B8B10 B11B12 B15B13B14 Frame category TID B0-B3 VTS flag

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 10 Solution 2: Add a 2-type new field before Frame body A 2-byte field, VTS control field, is defined and added before the frame body in the data frame. Priority, Dropping criteria, Frame category fields are defined as same as in solution 1. TID = 0-7, intra-AC only, TID = 8-15, intra-flow. The bit 7 in QoS control field (see the following figure) shall be set to 1, based on which the VTS MAC frame can be distinguished by a VTS station. (cannot be used due to conflict with TGn A-MPDU, management frame to be used???) TID Bits: B0B3B4B5B6B7B8B15 VTS Flag =1 B11B12 QoS control field in MAC frame Frame Control Octets:22 Address 1 Duration/ ID Address 2Address 3 Sequence control 6662 Address 4 QoS Control VTS control information 622 Frame Body 2302 FCS 4 VTS control Drop Precedence Intra-Flow Priority Reserved intra-flow/intra-AC information B4 B10 B11B12 B15B13B14 Frame category TID B0-B3

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 11 Compatibility to e Not needed for HCCA –Intra-flow/ intra-AC priority is not required due to per flow QoS is already specified by HCCA. Backward compatibility to EDCA –VTS devices can process EDCA frames produced by legacy devices. –If all EDCA functions are supported, it is fully compatible. Forward compatibility to EDCA –Legacy e device can process VTS frames as normal EDCA frames. –However, a frame generated by VTS device may not contain information of QAP PS buffer status, a possible optional function for EDCA Solution 1 is backward & forward compatible, solution 2 is backward compatible only.

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 12 Management frame modifications for supporting intra-flow DiffServ Following management frames need to be modified –Beacon frame –Association request / Reassociation request –Association response / Reassociation response Following information elements / fields contained in the above frames need to be extended –QoS capability information element –QoS info field

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 13 Use cases

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 14 Traffic generated from aa STA aa STA aa AP aa Mesh Node VTS traffic VTS diffServ Info created at STA VTS diffServ Info used & forwarded VTS diffServ Info may be NOT forwarded at the last hop aa & 802.1avb Bridge LAN VTS diffServ info mapped to 802.1Q

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 15 Traffic mapped at edge bridge of WLAN aa STA Video streaming aa AP VTS traffic Layered video streamed as diff flows VTS diffServ Info used Edge bridge (cross-layer mapping) Layered video & FEC info mapped to aa diffServ info, DPI required Or single flow is streamed but RTP packet is tagged FEC generation FEC per flow, as diff new flow or DPI & tag FEC as well at RTP

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 16 Traffic mapped at edge router of LAN aa STA Video streaming aa AP VTS traffic Layered video streamed as diff flows VTS diffServ Info used aa & 802.1avb Bridge LAN 802.1AVB mapped to aa diffServ info Edge router (Cross-layer Mapping) Multi-layer video flows mapped to AVB or DPI Or single flow is streamed but RTP packet is tagged FEC generation FEC per flow or DPI FEC is tagged

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 17 Observations VTS intra-flow/ intra-AC diffServ info observed and used within WLAN domain without mapping required Cross-domain requires layered video information mapped to VTS diffServ info field If layered video information is not explicitly available, DPI (deep packet inspection) is required at the Edge DPI is never required inside WLAN, complying to VTS PAR

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 18 Mapping at Edge (router / bridge) No specifications in PAR/requirements is made for 802.1AVB to ask for intra-flow / intra-AC diffServ This need is less important in wired network, and may never be implemented in as well as IETF. If VTS considers it is important regardless of corresponding wired network feature, mapping at Edge with DPI (deep packet inspection) is required. The mapping is considered an upper layer function though.

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 19 Straw Poll 1 Do you think solution 1 in document 0529/r1 a favorable solution of graceful degradation and intra- access category prioritization for TGaa (further refinement may be required) ? Yes No

doc.: IEEE /0640r0 Submission Jun Li, Thomson Inc..Slide 20 Straw Poll 2 Do you think solution 2 in document 0529/r1 a favorable solution of graceful degradation and intra- access category prioritization for TGaa (further refinement may be required) ? Yes No