., how much offset the Talker is using) 7December 18, 2008 IEEE 1722 AVBTP AVBTP Sample Time BenefitsAVBTP Sample Time Benefits • Networks that have a lower latency than 2 mSec can tell the Listeners to play with a 1 mSec offset for better performance • Class B does not always have to be at a worst case 100 mSec which would require vary larger Listener buffers • The Listeners can decide if they have the buffering needed to listen to a given stream knowing how much they need to buffer • Larger applications can be supported – A Concert Hall overflow Hall 8December 18, 2008 IEEE 1722 AVBTP AVBTP Presentation Time SolutionAVBTP Presentation Time Solution • If Talkers use a normalize Sample Time the overflow Concert Hall can play all the data in-sync with the correct offsets given to it by the higher layer application 9December 18, 2008 IEEE 1722 AVBTP AVBTP to/from 1394 Still WorksAVBTP to/from 1394 Still Works • Any Presentation Time that is one native 1394 frames can be ‘normalized’ as they enter the AVBTP network – Some frame modifications are needed anyway • The reverse is true – AVBTP network data to native 1394 can re-apply the 1394 Presentation Time 10December 18, 2008 IEEE 1722 AVBTP Sample Time SummarySample Time Summary • Propose that AVBPT’s Presentation Time be changed to Sample Time which is NOT in the future • If a Class A Talker could assume to use a +2 mSec Presentation Time then Class A Listeners can as well • This math needs to be in Listeners anyway for Tuning so its better to keep all the math in one location • Using Sample Time scales better (Concert Hall overflow case) and makes it clear that some higher layer application needs to set offset parameters • Allows Qav to progress without changes • Allows more time to define Class B’s offset and/or makes Class B adjustable as needed (same for Class A too!)

– Why not use 1394?

– Why not use 1394?

The other use case would be what 1394 or USB requires.

It exists in the form for IEC-61883, but this standard is specifically tied to IEEE 1394 only.

The other use case would be what 1394 or USB requires.

Applic-dependent delay specification Applic-dependent delay specification Packetization Layer (transfer frequency) Adaptation layer Packetization Layer (transfer frequency B) fixed latency Bartky Networks www.bartky.net 1394 channel 1394 bus 1394 24.576MHz Local Clock Service 1394 24.576MHz Local Clock Service (transfer frequency) CIP layer 1394 channel 1394 bus (transfer frequency B) CIP layer 1394 isochronous frame service fixed 125µs cycle, normal max 1 Async packet variation (near fixed latency) April 20, 2007 7AVB transport SG working paper Mixed bridged and P2P AVB Source A/V Bridge A Bridge B Bridge C Bridge D Bridge E Bridge FTalker 1 2 3 4 5 6 1 2 6 Video Audio 74 5 7 Misc time info: •Speed of light = ~ 1 nanosecond / foot •Speed of sound = ~ .9 milliseconds / foot •100 meg min size frame & overhead = 6.72 microseconds •100 meg max size frame & overhead = 123.36 microseconds •Class 5 AVB 7 hop max latency (defined) = 2 milliseconds So for synchronization, listeners have to deal with an AVB class 5 latency range from 6.72 microseconds to 2 milliseconds Network Min ~7µs for 1 hop, Max 2 ms for 7 hops, class 5 AVB stream Varying delays in network Bartky Networks www.bartky.net Listener X Listener Y 1 2 Listener Z 6 74 5 ~.9 ms/ft ~1 ns/ft Varying delays in encoding and decoding Varying delays speaker and people locations April 20, 2007 8AVB transport SG working paper 1394/61883 sync concepts – Source data time stamped at periodic intervals based on local clock – Source adds Fixed Time amount for each time stamped packet, stores new value in packet as “presentation time”. – Packets sent at 8 kHz fixed intervals on local 1394 bus, empty or no packet sent if nothing to send at a given time.

–Data Block Count, 8 bits •Sequence number of 1st Data Block in the packet •Same meaning as in 61883 over 1394 June 27, 2007 IEEE P1722 AVBTP Working Group Contribution 13 Encapsulation Assumptions •Approved by Consensus: –CIP header 2nd quadlet indicator, 2 bits •Fixed at 10 binary –Stream Format, 6 bits •Same values as currently defined for 61883 –Format Dependent Field (FDF), 8 bits if SPH=0, 24 Bartky Networks www.bartky.net –Format Dependent Field (FDF), 8 bits if SPH=0, 24 bits if SPH=1 •Same values as currently defined for 61883 –SYT field (1394 cycle time based presentation time for SPH field equals 0) •Mandatory for use by AVBTP end stations •Same as 1394/61883 June 27, 2007 IEEE P1722 AVBTP Working Group Contribution 14 Encapsulation Assumptions •Approved by Consensus: –CIP header 2nd quadlet • Channel ID (0-63) – 0-30 & 32-63: originating channel ID from 1394 network. – 31: originating source is on AVB network (native AVB) • Source ID (0-63) – 0-62 originating Source ID from IEEE 1394 network Bartky Networks www.bartky.net – 0-62 originating Source ID from IEEE 1394 network – 63 originating source is on AVB network • Reserved (2 bits) – Same as 1394/61883 » Set to 0 on transmit » Ignore on receive. • “sy”field (4 bits) (currently used by 1394 for Digital rights management). – Same as 1394/61883 June 27, 2007 IEEE P1722 AVBTP Working Group Contribution 15 Encapsulation Assumptions •Proposals: –For all class 5 traffic, limit maximum transmission unit size in order to limit total transmission time on and 802.3 100 megabit (including preamble

TA Document IEEE802.17-11Jul2001/0.40:2, July 11, 2000 Use of Lara Provided IEEE Templates Copyright  2001, 1394 Trade Association.

This doesn’t mean the 1394 Wireless Group will sit idly.

4: will DS-UWB products based on 1394 have the 1394 logo so that consumer experience can be “exceedingly easy”?

2004, 1394 Trade Association.

This makes them unsuitable for adoption in a layered networking application. • For IEEE 1394 bus based networks, a working implementation exists today that meets most of the needs for real-time audio and video streams and that is embodied in the IEC 61883 series standards. • Unfortunately for IEEE 802, the IEC 61883 series of standards uses mechanisms, formats, specific low level services and functions provided by IEEE 1394 that are not provided by IEEE 802. • For the reasons stated above, a new standard is needed to provide a common set of protocol encapsulations and mechanisms by starting with IEC 61883 protocol encapsulations and mechanisms, and modifying them to accommodate alternate IEEE LLC and MAC layer protocols.

The use of more common audio video transport over multiple network types will realize operational and equipment cost benefits. • Technologies exist today such as IEEE 1394, Bluetooth and USB, but each have their own unique encapsulation, protocols, timing control, etc. such that building interworking functions is difficult.

This makes them unsuitable for adoption in a layered networking application. • For IEEE 1394 bus based networks, a working implementation exists today that meets most of the needs for real-time audio and video streams and that is embodied in the IEC 61883 series standards. • Unfortunately for IEEE 802, the IEC 61883 series of standards uses mechanisms, formats, specific low level services and functions provided by IEEE 1394 that are not provided by IEEE 802. • For the reasons stated above, a new standard is needed to provide a common set of protocol encapsulations and mechanisms by starting with IEC 61883 protocol encapsulations and mechanisms, and modifying them to accommodate alternate IEEE LLC and MAC layer protocols.

Additionally, there must be standardized approaches for the use of synchronization/presentation time stamps and connection management procedures. • Unfortunately for end stations wishing to provide real time audio and video applications, there are numerous protocol mechanisms and formats often based on specifics of the lower level network protocol specifics. • For IEEE 1394 bus based networks, a working implementation exists today that meets most of the needs for real-time audio and video streams and that is embodied in the IEC 61883 series standards. • Unfortunately for IEEE 802 the IEC 61883 series of standards uses mechanisms, formats, specific low level services and functions provided by IEEE 1394 that are not provided by IEEE 802. • For the reasons stated above, a new standard is needed to provide a more common set of protocol encapsulations and mechanisms by starting with IEC 61883 type of protocol encapsulations and mechanisms, and modifying them to accommodate alternate lower layer protocols besides IEEE 1394.

That is, IEEE Std 1394 would be identified by:     iso (1) iso-identified-organization (3) ieee (111) standards-association-numbered-series-standards (2) std-1394 (1394) The entire tutorial and explanation of the scheme within the IEEE-SA can be found at: http://standards.ieee.org/regauth/Allocation_of_Object_Identifier_values_in_IEEE_standards-09.pdf This would be the appropriate time to make the change to the currently recommended root for IEEE Standards Unfortunately, I will not be able to attend the meeting in Portland to be in on the discussions.

The use of more common audio video transport over multiple network types will realize operational and equipment cost benefits. • Technologies exist today such as IEEE 1394, Bluetooth and USB, but each have their own unique encapsulation, protocols, timing control, etc. such that building interworking functions is difficult.

plus telephone/voice, hi-fi sound, compressed video video s er ia l A D B modem1394 SCSIvideo floppy modem N et w o rk S er ia l K ey b o ar d S o u n d P o w er 1394 family of specifications IEEE 1212-2001 IEEE 1394-1995, 1394a-2000, 1394b-2002 SBP-2,3 1394.1-2004 PC 2001, MacOS platform specs AV/C general AV/C disk IEC 61883 1-6 AV/C tape recorder content protection, “5C, DTCP” HAVi, UPnP RBC IP /1394 O p en H C I H D M D D V D C D D V D 8 D V H S A V /C p an el A V /C au d io A V /C tu n er D P P IIC 1394.3 Key specifications • IEEE 1394-1995, 1394a-2000, 1394b-2002 High Speed Serial Bus – “Memory-bus-like” logical architecture, isochronous support – Serial implementation of 1212 architecture • IEEE 1212-2001 CSR Architecture – Standardized addressing, well-defined control and status registers, configuration declaration, standardized transactions • “Higher layer” protocols – NCITS.325-1998 SBP-2 integrates DMA into I/O process • RBC (for mass storage) and IEEE 1394.3 PPDT (for printers) – IEC 61883 and 1394TA AV/C standards define control and data for A/V devices – RFC 2734 defines Internet Protocol (v4) over 1394 • IPv6 and DHCP also as RFCs – Digital Transport for Content Protection (“5C”/DTCP) – IEEE 1394.1 for bridges, IIC for instrumentation and industrial control, DPP for consumer cameras/printers, etc.

. • For IEEE 1394 bus based networks, a working implementation exists today that meets most of the needs for real-time audio and video streams and that is embodied in the IEC 61883 series standards. • Unfortunately for both IEEE 802 and IETF Internet Protocol technologies, the IEC 61883 series of standards uses in both its mechanisms and formats specific low level services and functions in IEEE 1394 that are different and/or not provided by IEEE 802 or IETF Internet Protocol. • With all of the above, the reason for a new standard is to provide a more common set of protocol encapsulations and mechanisms by starting with 61883 type of protocol encapsulations and mechanisms and modifying them to accommodate alternate lower layer protocols besides IEEE 1394.

Heberling (as Chair of wireless 1394 PAL) announced that the 1394 committee would like to consider review of MLMEs needed to make 1394 easier to implement.

Heberling (as Chair of wireless 1394 PAL) announced that the 1394 committee would like to consider review of MLMEs needed to make 1394 easier to implement.

–Agreed to start work on annex for Interworking function between 1394/61883 and P1722/61883.

IEEE 1722 Audio/Video Bridging Transport Protocol (AVBTP) Draft 1.1 IEEE P1722/D1.1 Layer 2 Transport Protocol for Time Sensitive Applications in Bridged Local Area Networks 2008-08-25 Copyright © 2007-2008 IEEE.

You can find our “final” comment assignment spreadsheet here: https://mentor.ieee.org/802.11/dcn/23/11-23-1394-04-00bf-lb276-comments-and-approved-resolutions.xlsx Let me know if you find any problems.