Tag: current state of technology

SO – “What is all the fuss about TSN (Time Sensitive Networking)?

And now for a “way too broad” question.

This was originally entitled “Time Sensitive Networking” by Praveen here, and phrased as this:

I am aware of current Ethernet Technology and it’s non-deterministic behavior, due to CSMA-/CA/CD. I also see a lot of news around Time Sensitive Networking.

Could anyone briefly explain how TSN could change or enhance timing, synchronization, how is it related to IEEE 1588(PTP) etc ?

Since indeed this is “way too broad”, I’d rephrase it as “what is all the fuss about TSN (Time Sensitive Networking)?”

First, to put that aside:

All Ethernet link these days are full duplex, so collision avoidance such as CSMA-/CA/CD are a thing of the past since about 15 years I would say: Ethernet is not a shared media (like is air for Wi-Fi), and there simply isn’t any collision, so no need to avoid it. Did you get that “non-deterministic because of CSMA-/CA/CD” from a book or teacher? Then those would need a serious update.

(And so no, the collision risk and its avoidance mechanism is not the cause of “current Ethernet Technology and it’s non-deterministic behavior”, especially not with the word “current”.)

And this being done, here is my – way too broad and light – answer introduction pointers to this AVB/TSN topic:


About TSN (Time Sensitive Networking):

TSN is just the new name for an IEEE 802 task sub-group that was first called AVB for “Audio Video Bridging”, as you can see from here (2005 or 2008 to 2012):

http://www.ieee802.org/1/pages/avbridges.html

Note: The Audio/Video Bridging Task Group was renamed the
“Time-Sensitive Networking Task Group” in November, 2012. Please refer
to that page for further information. The rest of this page has been
preserved it existed at that time, without some obsolete meeting
information.

The change was made to reflect its now broader perspective: not only for Pro Audio/Video distribution use, but also to automotive, and latter industrial applications as well. So the work continues here:

http://www.ieee802.org/1/pages/tsn.html

(yes, I know, the look an feel of IEEE web pages really  really sucks, but that is good content though)

As a result, you’ll actually find most information about the fundamentals of TSN by googling “Ethernet AVB” rather than “Ethernet TSN”. The wikipedia page, carefully maintained by people directly involved with the technology, is a good start:

https://en.wikipedia.org/wiki/Audio_Video_Bridging

Also, as with every technology, there is a technical side, that’s the IEEE AVB->TSN group, and there is a marketing side, taking care of branding, use-cases, and (very important) certification programs to label and guarantee the interoperability of products, to have a healthy ecosystem. For AVB/TSN, this marketing side is handled by the AVnu Alliance SIG (Special Interest Group), founded in 2009:

http://avnu.org/

There too, you can find a lot of information in the knowledge base section of the web site (technologies, whitepapers, specifications, FAQs): why was it made (what is the problem to solve), how does it work, what are the use cases in the various fields it targets.

Some final words:

AVB/TSN it is not a single protocol, but rather a set of protocols, put together with possible variants according to the use case. Example: originally designed with auto-configuration/plug and play’ built in (geared towards sound engineers, without the need for network engineers), its automotive profile rather use static configuration (because of reduced boot and configuration time, lesser code/hardware for reduced cost embedded devices, and you’re not going to change a car networking topology nor roles of the nodes everyday anyway).

And that makes a BIG pile of standards: the base IEEE AVB standards put together, the last one published in 2013 IIRC, where already about 1,500 pages, and TSN is now expanding that. Distribution of a common wall-clock to participants, which is a prior need to synchronization, with sub-microsecond range of precision, is a big, complex problem in itself to start with . Be it with a static clock device reference (“PTP master”) in IEEE 1588, and even more with a elected, and then constantly monitored and possibly re-elected GM (“Grand Master) via a BMCA (Best master clock algorithm) as in IEEE 802.1AS.

Also, all this require implementation not only in the end nodes, but also in the switches (bridges), which takes an active part in it at pretty much every level (clocking, but also bandwidth reservation, then admission and traffic shaping). So part of the standards are relevant to nodes, others to the bridges.

So all this is really quite big and complex, and going from 1,500 pages (which I once read from cover to cover) – and it’s now more than that – to “briefly explain how TSN could change or enhance timing, synchronization, how is it related to IEEE 1588 (PTP) etc ?” is a bit challenging… especially the “etc” part… :-)

Hope these few pointers help though.

SO – how about multicast/broadcast Audio/Video streaming over 802.11 aka Wi-Fi?

Ahhhhh… now that’s a really, really good question, originally titled as “Wi-Fi Monitor mode listening to traffic”, from pratiklodha, here.

Actually, it may have been titled as this: “how about multicast/broadcast Audio/Video streaming over 802.11 aka Wi-Fi?”, and so will I.

And now that’s an interesting topic by itself. A real, industry-wide question about the state of technology.

And here was my answer, as 802.11 state of the Art in March of 2016: – warning: as presumption as it may sound, this is a bit more than educated guess:


Are you talking about this Wifibroadcast , here?

If so: well yes, monitor mode is the underlying technology, as can be seen here.

Now, if this is about doing a commercial product, sadly, you cannot expect any kind of interoperability from this.

Streaming audio/video over Wi-Fi is a business, and the the power in charge (Wi-Fi Alliance aka WFA) as some view on it, including certification programs. Have a look at Miracast, using Wi-Fi Direct.

As for multicast / broadcast, it is even more of a business and the realm of proprietary technologies for now (example here – and no, this is not limited to automobile). This is quite complicated, to start with because of the synchronization problem across receivers: you don’t want 2 radio receivers in the same room to play with a 1 seconds delay, this would be cacophony.

EDIT:

Meaning, be it with the Wifibroadcast OSS project or with the proprietary industry about it, since there is not yet an open protocol for this (as “publicly available standard specification”, I don’t even go about implementation, FLOSS or not), you will have to provide a specific application for every receiver to match your broadcaster protocol, and vice versa. And that is the state of the industry today. That is what the company I mentioned above, or this other one more well know, or these are doing. And so, they do not interoperate. This will be your problem: provide a receiver app for Windows, Mac OS, Android and iOS (where you may not even have access to sub-layer 3 API) that will match your radio broadcaster protocol. And Linux too, please.

Though, this is the direction of history because this is what the user wants: stream A/V to/from device/application X from brand A to device/application Y from brand B.

And so people have been working on this, on layer 2, because layer 3 and above have unsolvable challenges with it, at IEEE since 2004 with Ethernet AVB, which is a set of protocols. You can download some of its standards for free, others for a moderate fee depending on how old they are. There is a SIG taking care of certification(http://avnu.org/certified-products/) to guarantee interoperability.

It is for 802.3 (aka wired Ethernet), but there is some work done to bring this to 802.11 Wi-Fi. Because again, that’s what the user wants, the market is here, no question about that. It will take a long time. Even more to get consumer electronic grade devices or applications of the shelves. But they will interoperate out of the box, that’s the goal.

There’s even been work done on moving this to layer 3/IP as well BTW, with some performance sacrifice.

So come back in a few years, and all should be setup. Or, if you have lots of time and money and no urge to deliver, implement a solution based on these standards?

PS:

Link to AVnu (Ethernet AVB SIG) page about use cases for consumer electronics audio streaming, wired or wireless:

http://avnu.org/consumer/

…and its 10 pages white paper at the bottom of the page.