Audio Video Bridging

Cơ bản

Các kết nối thiết bị audio và video (AV) trong lịch sử từng là analog một chiều, đơn-mục-đích và đơn-điểm-đến-đơn-điểm. 
Ngay cả các tiêu chuẩn AV kĩ thuật số cũng thường là đơn-điểm-đến-đơn-điểm và một chiều như S/PDIF cho audio và serial digital interface (SDI, giao diện kĩ thuật số tuần tự) cho video.
Mô hình kết nối này dẫn đến khối lượng cáp lớn đến mức khó hiểu, đặc biệt trong các ứng dụng tiêu dùng cao cấp và chuyên nghiệp.
Những nỗ lực giải quyết các vấn đề này bao gồm các công nghệ mới như IEEE 1394 (còn gọi là FireWire), và các thích ứng của các công nghệ mạng máy tính tiêu chuẩn như Audio over Ethernet hoặc Audio over IP.
Các protocol ô tô, nhà, và nghề nghiệp chuyên biệt không tương thích với nhau.
Để làm các mạng tiêu chuẩn thích ứng có thể sử dụng công nghệ thương phẩm, nhưng việc điều khiển quality of service (chất lượng dịch vụ) chặt chẽ là không dễ.

Yêu cầu

Các yêu cầu bao gồm việc đồng bộ hóa nhiều stream nhằm đảm bảo chúng được render chính xác đúng thời điểm; một ví dụ đơn giản cho điều này là lip synch. Các ứng dụng nghiêm ngặt hơn, ví dụ để giữ cho nhiều speaker (loa) kĩ thuật số đồng bộ chính xác trong một môi trường chuyên nghiệp, thì cần phải đồng bộ hóa trong 1μs.
Delay trong trường hợp xấu nhất (tính cả buffering đích và nguồn), phải thấp và xác định (deterministic). Ví dụ, delay cho phản hồi giao-diện-người-dùng người tiêu dùng là khoảng 50 ms, hoặc 2 ms với các buổi biểu diễn trực tiếp.
Các ứng dụng phải có khả năng dự trữ các tài nguyên mạng, đôi khi được gọi là admission control (điều khiển thu nhận). AVB cũng được xem xét để ứng dụng cho việc điều khiển trong công nghiệp.

Tiêu chuẩn hóa IEEE

Vào tháng 7 năm 2004, IEEE 802.3 khởi lập một nhóm nghiên cứu residential Ethernet cho streaming A/V.
Vào tháng 11 năm 2005, công việc chuyển đến working group IEEE 802.1, đảm nhiệm các tiêu chuẩn cross-network bridging. Cụ thể, nhóm mong muốn có một công nghệ có thể mở rộng từ các ứng dụng tiêu dùng rẻ tiền cho đến các tiêu chuẩn chuyên nghiệp.

IEEE 802.1Qav - shaping traffic cho các stream AV

Nhằm cung cấp các dịch vụ AV chuyên nghiệp, kiến trúc AVB thực thi việc shaping traffic bằng cách dùng các cơ chế ưu tiên và chuyển tiếp 802.1Q hiện có, ngoài ra nó cũng định nghĩa thêm một mối quan hệ đặc biệt giữa các tag ưu tiên và hành vi chuyển tiếp frame tại các endpoint (đầu cuối, điểm cuối) và các bridge (cầu).
Shaping traffic là quá trình làm mượt traffic cho một stream, phân phối các packet của nó đồng đều theo thời gian. Nếu việc shaping traffic không được thực hiện ở các nguồn và các bridge, thì các packet có xu hướng "bunch", nghĩa là kết tụ, thành vụ bùng nổ traffic, gây quá tải cho các buffer (bộ đệm) ở các bridge, switch và các thiết bị hạ tầng khác tiếp theo. "bunching" được mô tả chi tiết hơn ở các phần sau.

Các yêu cầu tagging tại nguồn stream và bridge

Các stream AVB bao gồm các frame 802. Các frame này có tagging ưu tiên và các hạn chế thông thường về định dạng và chiều dài. Tagging 802.1Q mặc định cho phân khúc thị trường cụ thể nên được chọn để tránh xung đột tiềm năng với cách dùng hiện tại của các tag ưu tiên 802.1Q trong phân khúc thị trường đó.

Shaping traffic tại nguồn stream

Các thiết bị endpoint cần phải truyền các frame cho một stream cụ thể một cách rất đều đặn dựa trên lớp traffic AVB và các thông số quality of service (QoS) cụ thể từng được sử dụng khi stream được mạng chấp nhận (xem mục Admission control bên dưới). Các quy định cụ thể đối với việc shaping traffic được mô tả trong specification IEEE 802.1Qav, và là một dạng đơn giản của "leaky bucket" (thùng rò rỉ) credit-based fair queuing (xếp hàng công bằng dựa trên credit) trong đó bandwidth được dự trữ cho một stream sẽ kiểm soát khoảng thời gian giữa các packet tạo nên stream đó.

Shaping traffic tại một bridge AVB

Cơ chế shaping traffic được các nguồn stream sử dụng cũng được các bridge AVB khai thác. Các frame AVB được chuyển tiếp với ưu tiên cao hơn traffic Best Effort (nỗ lực tốt nhất) (có nghĩa là, traffic stream AVB được dự trữ khi đi qua một bridge AVB sẽ được ưu tiên chuyển tiếp hơn so với traffic không được dự trữ) và phải tuân thủ các luật về shaping traffic (có thể chúng cần đợi cho đến khi có đủ credit).
Như đối với các nguồn stream, các luật về shaping traffic được áp dụng cho các bridge cũng yêu cầu các frame phải được phân phối rất đều đặn theo thời gian. Nhưng việc phân phối này chỉ dựa trên một lớp kết hợp hơn là trên mỗi stream. Điều này có nghĩa là tất cả traffic AVB đang được truyền đi từ một port cụ thể sẽ được phân phối đều đặn theo thời gian và sẽ được đo lường bằng cách sử dụng các tham số QoS của lớp đó; đây chính là tổng của các bandwidth của tất cả các reservation (đặt trước) dành cho một lớp AVB cụ thể và cho một port cụ thể, được tạo ra bởi quá trình admission control như được mô tả dưới đây, nhằm đạt được hiệu quả làm mịn (smoothing out) thời điểm phân phát (ngăn chặn các frames bị bó lại) trong suốt quá trình một stream lan truyền qua mạng. Việc bó lại bị hạn chế này sẽ mang lại ích lợi lớn trong việc đặt ra một giới hạn trên tương đối nhỏ về kích thước cho các buffer đầu ra AVB, các buffer này cần phải tồn tại ở tất cả các port đầu ra của một bridge. Việc bó lại bị hạn chế này cũng độc lập với số lượng bước nhảy (hop) trong đường dẫn. Kích thước buffer bị giới hạn này là một thuộc tính quan trọng. Thuộc tính này cho phép độ trễ bị giới hạn, và loại bỏ nghẽn mạng đối với các stream AV đã được chấp nhận trong mạng AVB, ngay cả khi traffic không được chấp nhận bị tắc.

IEEE 802.1Qat - Admission control (kiểm soát thu nhận)

Mặc dù cơ chế trước đây có thể phân phát dữ liệu đáng tin cậy với một latency và jitter thấp, nhưng cơ chế đó chỉ hoạt động nếu các tài nguyên mạng (ví dụ, throughput (lưu lượng) trên một port, không gian buffer trong một bridge) sẵn sàng trên toàn bộ đường dẫn từ talker đến [các] listener. Trong các protocol AVB, thuật ngữ ‘talker’ (người nói) chỉ nguồn stream còn ‘listener’ (người nghe) chỉ đích stream. Trong kiến trúc này, cả talker và listener phải chịu trách nhiệm đảm bảo đường dẫn sẵn sàng và dự trữ các tài nguyên. Quá trình làm việc này được xác định trong 802.1Qat "Stream Reservation Protocol" (SRP, Giao thức Dự trữ Stream). Protocol này đăng kí một stream và dự trữ các tài nguyên cần thiết xuyên suốt toàn bộ đường dẫn chiếm bởi stream:
Các talker bắt đầu gửi một tin nhắn SRP "talker advertise" (quảng cáo talker). Tin nhắn này gồm một Stream ID tạo bởi địa chỉ MAC của nguồn stream cộng với một ID duy nhất dài 16 bit đặc trưng cho talker và địa chỉ MAC của đích stream. Ngoài ra, tin nhắn "talker advertise" còn bao gồm các yêu cầu về QoS (ví dụ, lớp traffic AVB và thông tin về data rate) và latency tích lũy trong trường hợp xấu nhất. Mặc dù địa chỉ và các yêu cầu QoS đều bắt nguồn từ talker, latency trong trường hợp xấu nhất vẫn được tính lại tại mỗi bridge, cho phép listener truyền thông tin này lên các tầng cao hơn nhằm giúp đồng bộ hóa media.
Tất cả các bridge AVB trung gian khi nhận được một tin nhắn "talker advertise" sẽ kiểm tra xem bandwidth trên các port đầu ra của chúng có sẵn sàng hay không. Khi bridge có đủ tài nguyên trên port đầu ra đó, "talker advertise" sẽ được lan truyền đến station tiếp theo.
Khi bridge không có đủ tài nguyên, thay vì lan truyền tin nhắn advertise, bridge sẽ gửi một tin nhắn "talker failed" (talker bị lỗi). Trong tin nhắn này có một mã lỗi và một identification của bridge, cho phép một ứng dụng tầng cao hơn cung cấp việc kiểm tra lỗi và thông báo. Một bridge trung gian nhận được tin nhắn "talker failed" chỉ nên chuyển tiếp tin nhắn đó cho listener.
Khi một listener nhận được tin nhắn "talker advertise", nó cần phải biết tài nguyên sẵn sàng hay không, và nếu tài nguyên có đủ thì nó sẽ xét đến latency trên đường dẫn. Sau đó nó có thể phản hồi lại bằng một tin nhắn "listener ready" (listener đã sẵn sàng), tin nhắn này sẽ được chuyển tiếp ngược lại đến talker. Các bridge trung gian sử dụng tin nhắn "ready" để khóa các tài nguyên mà stream cần và làm cho các entry thích hợp trong cơ sở dữ liệu chuyển tiếp (forwarding database) của chúng cho phép stream được gửi trên port đã nhận được tin nhắn "ready". Khi talker nhận được một tin nhắn "ready", nó có thể bắt đầu gửi stream.
Talker có thể hủy một stream một cách tường minh bằng cách hủy đăng kí tin nhắn "talker advertise", và một listener có thể ngắt kết nối bằng cách hủy đăng kí tin nhắn "listener ready".  Một tin nhắn hủy đăng kí sẽ lan truyền qua mạng giống với tin nhắn đăng kí ban đầu.
Ngoài ra còn có các phương pháp ngầm hiểu dùng để hủy một kết nối và để giải phóng các tài nguyên đã được cấp phát. Ví dụ, listener phải định kì gửi lại các các registration (bản đăng kí) và các tin nhắn "ready", còn các talker phải định kì gửi lại các tin nhắn "advertise". Theo cách đó bất cứ thiết bị nhận nào (bao gồm các bridge trung gian) cũng có thể tự động giải phóng các tài nguyên đã được cấp phát và thông báo cho các tầng cao hơn nếu nó không nhận được các registration và các reservation (dự trữ, đặt chỗ trước) thích hợp vì một lỗi làm gián đoạn hệ thống (system halt), ví dụ, mất điện đột ngột.

Cân nhắc cho mạng LAN-đặc-biệt

Mặc dù ý đồ của nhóm công tác AVB (AVB Task Group) là cung cấp một phương pháp độc-lập-công-nghệ-LAN cho việc yêu cầu và cung cấp các dịch vụ streaming, các đặc điểm và kiến trúc của các công nghệ LAN khác đòi hỏi các cách chuyên biệt để thực thi những dịch vụ đó như được phác thảo trong các phần sau.

IEEE 802.3 / Các liên kết Ethernet

Các thiết bị Ethernet ngày nay chủ yếu hỗ trợ hoạt động full-duplex ở tốc độ 100 Mbit/s hoặc hơn. Vì vậy, bởi vì bandwidth tổng cộng có sẵn trên một liên kết Ethernet như vậy đều đã biết và là hằng số, dự trữ AVB trên các liên kết Ethernet đó được kết hợp với việc shaping traffic thích hợp đảm bảo cả throughput và các tham số latency phân phát được đảm bảo cho các packet của stream được dự trữ. Vì bandwidth và việc định giờ phân phát không thể được đảm bảo giữa hai thiết bị trong Ethernet CSMA/CD được chia sẻ cũ hơn dùng các hub, những công nghệ cũ hơn này không được hỗ trợ bởi AVB. Tiêu chuẩn đồng bộ hóa thời gian Ethernet của AVB, 802.1AS, thúc đẩy và đơn giản hóa IEEE 1588-2008 được khai thác.

IEEE 802.11 / Wireless LAN (LAN không dây)

Đến nay, việc hỗ trợ AVB đã được lập kế hoạch cho 802.11 bị giới hạn ở việc đồng bộ hóa thời gian.  802.1AS cung cấp đồng bộ hóa thời gian chính xác trên các liên kết 802.11, một phần bằng cách viện dẫn các primitive timestamp-reporting đặc trưng MAC được định nghĩa trong IEEE Std 802.11v-2011. Protocol đồng bộ hóa thời gian được định nghĩa bởi 802.1AS được thiết kế để linh hoạt đối với các đặc điểm truyền có thể có trên medium không dây.

Coordinated Shared Network Link (Các liên kết mạng được chia sẻ và phối hợp)

Hiện nay nhiều tiêu chuẩn và specification MAC/PHY đang được sử dụng hoặc đang được phát triển hoạt động trên các dây dẫn hiện có trong gia đình (như các dây điện AC, dây cáp đồng trục). Những dây dẫn này "Shared" (được chia sẻ) về điện giữa nhiều thiết bị (không phải đơn-điểm-đến-đơn-điểm như Ethernet), vì vậy để cung cấp performance có thể đoán trước được, việc truyền thông tin trên dây dẫn được "Coordinated" (được phối hợp) để tránh xung đột va chạm bởi một trong các thiết bị trên mạng. Những công nghệ nối mạng như vậy thường được gọi là Coordinated Shared Network (CSN, các mạng được chia sẻ và được phối hợp). Nếu CSN cung cấp một phương pháp truy cập với latency bị chặn (như hầu hết đều làm), và nếu time stamping đặc trưng liên kết chính xác hoặc phân bố clock sẵn sàng cho các mạng CSN, thì các phần mở rộng có thể được định nghĩa để hưởng lợi từ chúng.

Các protocol tầng cao hơn

Đối với các ứng dụng hưởng lợi từ các đặc tính của AVB, cần có một số phối hợp với các phần của các protocol giao tiếp tầng cao hơn ở giữa chúng.  Ngoài ra, một số protocol vận chuyển đã được thích ứng  để cung cấp thông tin cho các ứng dụng sử dụng AVB.
Một ứng dụng có thể thực thi việc render phân tán được đồng bộ hóa (synchronized distributed rendering) bằng cách sử dụng 802.1AS và các tầng cao hơn. Các sample audio và hoặc các frame video đặc trưng được mang bởi các protocol tầng cao hơn được cung cấp một thời gian trình bày kết hợp (associated presentation time) (với nghĩa clock 802.1AS được chia sẻ) bởi một nguồn media mà nguồn này cũng là một  talker AVB.  Mỗi thiết bị render media, cũng là một listener AVB, render sample audio hoặc frame video được tham chiếu ở thời gian trình bày 802.1AS.

IEEE 1722 và IEEE 1722.1

Các ứng dụng sử dụng IEC 61883 và các định dạng khác có thể sử dụng các procedure (thủ tục) được định nghĩa trong IEEE Std 1722-2011 để sample clock 802.1AS liên quan đến một block dữ liệu A/V và sau đó thêm delay vận chuyển trong trường hợp xấu nhất vào thời gian sample để nhận được thời gian trình bày, thời gian trình bày được nhét vào packet 1722.
IEEE Std 1722.1-2013 là tiêu chuẩn cho phép AVB Discovery, Enumeration, Connection management and Control (AVDECC) của các thiết bị sử dụng IEEE Std 1722-2011.

IEEE 1733

Nếu một ứng dụng sử dụng IETF Real-time Transport Protocol (RTP), nó có thể sử dụng một định dạng payload RTCP mới được định nghĩa trong IEEE 1733 tương quan timestamp RTP với thời gian trình bày 802.1AS. Sau đó các ứng dụng ở các bộ renderer sẽ sử dụng các tương quan đó để phiên dịch timestamp RTP thành time stamp trình bày cho phép [các] renderer bắt đầu chơi vào cùng một thời điểm và tiếp tục chơi ở cùng rate.

HTTP

Các ứng dụng sử dụng HTTP cũng có thể hưởng lợi từ đồng bộ hóa thời gian của AVB bằng cách mang thời gian trình bày. Ví dụ, các stream vận chuyển MPEG2 mà cần đồng bộ hóa clock giữa server và client có thể gộp các time stamp vận chuyển (transport time stamp, TTS) như được định nghĩa bởi ARIB TTS (ARIB STD-B24), trích xuất từ clock 802.1AS clock. Tương tự, một ứng dụng có thể sử dụng đồng bộ hóa clock thông qua các phương pháp được mô tả trong ISO 13818-1 Annex J, phụ lục này bao gồm thảo luận về các scheme phụ hồi clock khác nhau được đề xuất cho MPEG2 Transport Streams over jitter bao gồm các mạng, và hình figure J.2 minh họa cách sử dụng đơn giản clock 802.1AS cho mục đích này.
Nếu nguồn media không phải là một nguồn thời gian thực (ví dụ một file media trên một thiết bị lưu trữ (mass storage device)), các thời điểm trình bày có thể được sinh ra dựa trên media rate danh nghĩa.  Nếu nguồn media là một nguồn thời gian thực (ví dụ một microphone), thời gian trình bày có thể được tạo lập bởi một talker dựa trên sự quan sát của nó về thời gian 802.1AS liên quan đến clock sample của microphone đó.
Các dịch vụ khác ở tầng cao hơn có thể sử dụng AVB theo cách tương tự. Các phương pháp quản lý kết nối hiện có, ví dụ, có thể sử dụng các dịch vụ dự trữ AVB SRP bằng cách mapping (ánh xạ) các identifier của stream nội bộ với các ID của stream SRP. Một khi liên kết đã được thành lập thành việc streaming sẽ có thể bắt đầu. Ví dụ, các ứng dụng sử dụng RTP gửi đi các packet RTCP được định nghĩa bởi IEEE 1733 tương quan SSRC với ID của stream SRP. Hơn nữa, các ứng dụng listener sử dụng 1722 sử dụng ID stream SRP để phân biệt giữa các stream khác nhau.