Audio Video Bridging

AVB
Nhãn hiệu chứng nhận AVnu
Thông tin nhà sản xuất
Nhà sản xuất	IEEE, AVnu
Ngày phát triển	September 2011; 13 năm trước (September 2011)
Khả năng tương thích mạng
Switchable	Có
Routable	Không
Các thông số kĩ thuật audio
Độ trễ tối thiểu	0.25 ms[1]
Tần số lấy mẫu tối đa	192 kHz[2]
Độ sâu bit tối đa	32-bit floating point[2]:clause 8.3

Audio Video Bridging (tiếng Anh, viết tắt: AVB, Ethernet AVB) là tên chung của một bộ tiêu chuẩn kĩ thuật do nhóm tác vụ (task group) Audio Video Bridging trong nhóm làm việc (work group) ủy ban tiêu chuẩn IEEE 802.1 của viện Institute of Electrical and Electronics Engineers (IEEE) phát triển. Task group này đã đổi tên thành Time-Sensitive Networking vào tháng 11 năm 2012 để phản ánh phạm vi mở rộng của dự án.

Hiến chương của tổ chức này là "cung cấp các specification (bộ tài liệu chi tiết kĩ thuật) cho phép các dịch vụ streaming với latency (độ trễ) thấp được đồng bộ hóa thời gian thông qua các mạng IEEE 802".^[3] Các specification này gồm có:

• IEEE 802.1BA:^[4] Audio Video Bridging (AVB) Systems (Các hệ thống Cầu nối Audio Video);
• IEEE 802.1AS: Timing and Synchronization for Time-Sensitive Applications (gPTP) (Định giờ và Đồng bộ hóa cho các ứng dụng nhạy thời gian);
• IEEE 802.1Qat: Stream Reservation Protocol (SRP, Giao thức Dự trữ Stream); và
• IEEE 802.1Qav: Forwarding and Queuing for Time-Sensitive Streams (FQTSS, Chuyển tiếp và Xếp hàng đợi cho các stream nhạy thời gian).

IEEE 802.1Qat và 802.1Qav là các phần bổ sung cho tài liệu IEEE 802.1Q cơ bản, quy định hoạt động của "Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks" (Các cầu nối Điều khiển Truy cập Media và các mạng khu vực cục bộ được bắc cầu ảo), do các thiết bị mạng gọi là các Ethernet switch (bộ chuyển mạch Ethernet) thực thi.

Nhằm bảo đảm khả năng tương tác giữa các thiết bị thực thi các tiêu chuẩn AVB, AVnu Alliance đã phát triển các chứng nhận thiết bị cho ô tô, người tiêu dùng, và các thị trường audio và video chuyên nghiệp.^[5]

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.^[6]

Nối dây của một patch bay của một xe van phát sóng broadcast ở ngoài trời

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ễ.^[6]

Lợi ích^[7]

Một số lợi ích của các hệ thống AVB:

• Đồng bộ hóa được cải tiến
• Latency (độ trễ) thấp
• Có thể tin cậy được
• Các yêu cầu hạ tầng
• Networked Live Sound (âm thanh trực tiếp được nối mạng)

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).^[6] AVB cũng được xem xét để ứng dụng cho việc điều khiển trong công nghiệp.^[8]

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.^[9] 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.^[10]

Tóm lược Audio Video Bridging

Hình 2 - Các kết nối AVB

Mạng "Audio Video Bridging" (AVB) thực thi một tập hợp protocol do Task Group Audio/Video Bridging của IEEE 802.1 phát triển. AVB hoạt động bằng cách dành riêng một phần bandwidth Ethernet hiện có cho traffic AVB. Có bốn điểm khác biệt chủ yếu giữa kiến trúc được đề xuất và các kiến trúc 802 đang tồn tại:

• Đồng bộ hóa chính xác,
• Shaping traffic cho các stream media,
• Các admission control (kiểm soát thu nhận), và
• Identification (nhận biết, xác định) các thiết bị không-tham-gia.

Những điểm này được thực thi bằng cách sử dụng phần mở rộng (khá nhỏ) của các bridge và các MAC tầng 2 tiêu chuẩn. Triết lí "thay đổi tối thiểu" này cho phép các thiết bị hỗ trợ AVB và các thiết bị không-hỗ-trợ-AVB giao tiếp được với nhau bằng cách dùng các frame 802 tiêu chuẩn. Tuy nhiên, như biểu thị ở Hình 2, chỉ các thiết bị hỗ trợ AVB mới có khả năng:

a) dự trữ một phần tài nguyên mạng thông qua việc sử dụng admission control và shaping traffic

b) gửi và nhận các frame dựa trên việc định giờ mới.

Các packet AVB được gửi đi đều đặn trong các slot đã được cấp phát. Vì bandwidth được dự trữ nên sẽ không có xung đột.

IEEE 802.1AS - đồng bộ hóa chính xác

Các thiết bị AVB trao đổi thông tin định giờ cho nhau theo chu kì. Việc trao đổi này cho phép cả hai thiết bị ở hai đầu của một liên kết đồng bộ hóa clock tham chiếu cơ sở thời gian của chúng một cách rất chính xác. Việc đồng bộ hóa chính xác này có hai mục đích:

• Cho phép đồng bộ hóa các stream dữ liệu
• Cung cấp cơ sở thời gian chung cho việc sampling hoặc nhận các stream dữ liệu tại thiết bị nguồn và biểu diễn các stream đó ở thiết bị đích với cùng việc định giờ tương đối.

Protocol được sử dụng trong việc duy trì đồng bộ hóa định giờ được xác định trong IEEE 802.1AS. Đây là một tập con của một tiêu chuẩn IEEE khác (IEEE 1588), bị ràng buộc rất chặt chẽ, và có phần mở rộng hỗ trợ IEEE 802.11 và các mạng "coordinated shared network" (CSN, mạng được chia sẻ và phối hợp) chung (ví dụ CSN bao gồm một số công nghệ không dây, cáp đồng trục và dây dẫn điện). IEEE 1588 được dùng trong các ứng dụng đo đạc, kiểm thử, và điều khiển công nghiệp.

Một domain định giờ mạng 802.1AS sẽ được tạo thành khi tất cả các thiết bị đều tuân theo các yêu cầu của tiêu chuẩn 802.1AS và giao tiếp với nhau bằng cách sử dụng protocol IEEE 802.1AS. Bên trong domain định giờ, có một thiết bị duy nhất được gọi là grandmaster. Thiết bị này cung cấp tín hiệu định giờ master. Còn tất cả các thiết bị khác sẽ đồng bộ hóa clock của chúng với grandmaster như biểu thị ở Hình 3.

Thiết bị giữ vai trò grandmaster có thể được lựa chọn một cách tự động hoặc được phân công đặc biệt (ví dụ, khi mạng được sử dụng trong một môi trường chuyên nghiệp cần "house clock" (audio), hoặc "genlock" (video), hoặc khi hệ thống phân cấp timing cần được xác định vì các lí do khác). Sau khi thiết lập liên kết vật lý, các thiết bị AVB thường trao đổi cho nhau thông tin khả năng (capability information). Nếu các thiết bị ngang hàng trên cùng một liên kết (link) có khả năng đồng bộ hóa mạng, thì chúng sẽ bắt đầu trao đổi các frame đồng bộ hóa clock. Nếu không, thì ranh giới sẽ được xác định cho domain định giờ AVB (như biểu thị ở Hình 2).

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 đó.

Hình 4 – Ví dụ shaping traffic Qav

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.

Hình 5 – Dự trữ thành công (talker advertise)

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.

Hình 6 – Reservation acknowledge (listener ready)

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.^[11] 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.

IEEE 802.1BA - Identification của các thiết bị tham gia

Vì scheme (sơ đồ, phương pháp) tổng thể AVB phụ thuộc vào sự tham gia của tất cả các thiết bị nằm giữa talker và listener, bất cứ yếu tố mạng nào không hỗ trợ AVB (bao gồm cả cái gọi là các "unmanaged bridge" (bridge không được quản lí)) phải được xác định và gắn cờ. Quá trình làm việc này được mô tả trong việc phát triển tiêu chuẩn IEEE 802.1BA "Audio Video Bridging Systems". Tiêu chuẩn này xác định cấu hình mặc định cho các thiết bị AVB trên một mạng.

Đối với Ethernet, phương pháp được định nghĩa bởi 802.1BA để xác định xem thiết bị ngang hàng của nó có khả năng hỗ trợ AVB là một tổ hợp của các khả năng liên kết 802.3 (được xác định trong khi thiết lập liên kết Ethernet) và các phép đo delay (độ trễ) liên kết được thực hiện bởi IEEE 802.1AS. Một port Ethernet có khả năng hỗ trợ sẽ sử dụng AVB nếu:

1. liên kết là full duplex 100 Mbit/s hoặc lớn hơn
2. protocol 802.1AS phát hiện ra chính xác một thiết bị ngang hàng
3. round-trip delay (độ trễ chuyến khứ hồi) đến thiết bị AVB hồi đáp không nhiều hơn delay dây dẫn trong trường hợp xấu nhất (được tính từ việc trao đổi "PDelay" IEEE 802.1AS) Lưu ý: delay dây dẫn trong trường hợp xấu nhất nhỏ hơn delay của một switch không hỗ trợ AVB.
4. một yêu cầu dự trữ SRP hoặc acknowledge đã được nhận ở port

Các kết nối khác ở tầng thứ hai sẽ có các phương pháp đặc trưng riêng của chúng để xác định các thiết bị ngang hàng cùng hợp tác.

Mặc dù một port có thể được kích hoạt cho hoạt động AVB, có khả năng một kết nối AVB end-to-end (đầu cuối đến đầu cuối) hoàn thiện không thể được thiết lập đối với một thiết bị đầu cuối (endpoint device) khác đã được kích hoạt AVB. Ví dụ, ở Hình 2 phía trên, các thiết bị trong domain AVB 1 không thể thiết lập một kết nối AVB đến các thiết bị trong domain AVB 2. Một kết nối AVB mà có thể chỉ được đảm bảo nếu một dự trữ thành công được tạo thành bằng cách sử dụng các tin nhắn SRP, và các tin nhắn SRP "talker advertise" sẽ không được lan truyền bởi một bridge không hỗ trợ AVB.^[6]

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^[12] để 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^[13] 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^[14] 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.

Tiêu chuẩn hóa

Tiêu chuẩn	Tiêu đề	Hiện trạng	Ngày tháng
IEEE 802.1BA-2011	Audio Video Bridging Systems	Đã được phê chuẩn và xuất bản	30 tháng 9 năm 2011
IEEE 802.1Qav	Forwarding and Queuing Enhancements for Time-Sensitive Streams	Đã được phê chuẩn và xuất bản	5 tháng 1 năm 2010
IEEE 802.1Qat	Stream Reservation Protocol (SRP)	Đã được phê chuẩn và xuất bản	30 tháng 9 năm 2010
IEEE 802.1Q-2011	Incorporates IEEE 802.1Qav and IEEE 802.1Qat	Đã được phê chuẩn và xuất bản	31 tháng 8 năm 2011
IEEE 802.1AS-2011	Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks	Đã được phê chuẩn và xuất bản	30 tháng 3 năm 2011
IEEE 1722-2011	Layer 2 Transport Protocol for Time Sensitive Applications in a Bridged Local Area Network	Đã được phê chuẩn và xuất bản	6 tháng 5 năm 2011
IEEE 1733-2011	Layer 3 Transport Protocol for Time Sensitive Applications in Local Area Networks	Đã được phê chuẩn và xuất bản	25 tháng 4 năm 2011
IEEE 1722.1-2013	Device Discovery, Enumeration, Connection Management and Control Protocol for 1722-Based Devices	Đã được phê chuẩn và xuất bản	23 tháng 8 năm 2013

Các nỗ lực tiêu chuẩn hóa vẫn đang tiếp diễn ở IEEE 802.1. Các dự án cải tiến AVB sau đây đang được đề xuất hoặc đang được tiến hành.^[15]

Tiêu chuẩn	Nhóm chức năng	Tiêu đề	Hiện trạng	Ngày cập nhật
IEEE 802.1ASbt	Timing and Synchronization	Enhancements and Performance Improvements [16]	Draft 0.7	1 tháng 11 năm 2014
IEEE 802.1Qbv	Forwarding and Queuing	Enhancements for Scheduled Traffic [17]	Draft 2.1	24 tháng 10 năm 2014
IEEE 802.1Qbu	Forwarding and Queuing	Frame preemption [18]	Draft 1.1	16 tháng 10 năm 2014
IEEE 802.1Qca	Stream Reservation (SRP)	Path Control and Reservation [19]	Draft 1.1	26 tháng 9 năm 2014
IEEE 802.1CB	Stream Reservation (SRP)	Frame Replication and elimination for Reliability [20]	Draft 0.5	3 tháng 11 năm 2014
IEEE 802.1Qcc	Stream Reservation (SRP)	Enhancements and Performance Improvements [21]	Draft 0.2	1 tháng 11 năm 2014

Tham khảo

1. “D-Mitri - AVB”. Meyer Sound Laboratories. Bản gốc lưu trữ ngày 8 tháng 7 năm 2014. Truy cập ngày 24 tháng 4 năm 2014.
2. ^ IEC 61883-6
3. IEEE 802.1 Audio Video Bridging Task Group
4. IEEE 802.1BA - Audio Video Bridging (AVB) Systems
5. “AVnu Alliance”. Official website. Truy cập ngày 27 tháng 9 năm 2011.
6. ^ Michael Johas Teener; và đồng nghiệp. “No-excuses Audio/Video Networking: the Technology Behind AVnu” (PDF). Truy cập ngày 16 tháng 10 năm 2016.
7. Kreifeldt, Rick (ngày 30 tháng 7 năm 2009). “AVB for Professional A/V Use” (PDF). AVnu Alliance White Paper.
8. Jahan Imtiaz; Jürgen Jasperneite; Lixue Han: A performance study of Ethernet Audio Video Bridging (AVB) for Industrial real-time communication in: IEEE Conference on Emerging Technologies & Factory Automation (ETFA 2009), pp.1,8, 22-25 Sept. 2009 doi: 10.1109/ETFA.2009.5347126
9. Richard Brand; và đồng nghiệp (ngày 14 tháng 7 năm 2004). “Residential Ethernet: IEEE 802.3 Call for Interest” (PDF). IEEE 802.3 standards committee. Truy cập ngày 27 tháng 9 năm 2011.
10. “IEEE 802.3 Residential Ethernet Study Group”. Official web site. IEEE 802.3 standards committee. ngày 10 tháng 1 năm 2006. Truy cập ngày 27 tháng 9 năm 2011.
11. “IEEE Std 802.11v-2011”. Bản gốc lưu trữ ngày 15 tháng 7 năm 2018. Truy cập ngày 24 tháng 7 năm 2017.
12. “IEEE Std 1722-2011”. Bản gốc lưu trữ ngày 20 tháng 6 năm 2018. Truy cập ngày 24 tháng 7 năm 2017.
13. “IEEE Std 1722.1-2013”. Bản gốc lưu trữ ngày 20 tháng 9 năm 2017. Truy cập ngày 24 tháng 7 năm 2017.
14. “IEEE 1733”. Bản gốc lưu trữ ngày 12 tháng 9 năm 2017. Truy cập ngày 24 tháng 7 năm 2017.
15. http://ieee802.org/1/files/public/docs2013/tsn-rev2-task-0113-v3.pdf
16. “and Synchronization: Enhancements and Performance Improvements”. Bản gốc lưu trữ ngày 19 tháng 10 năm 2011. Truy cập ngày 24 tháng 7 năm 2017.
17. “for Scheduled Traffic”. Bản gốc lưu trữ ngày 1 tháng 9 năm 2012. Truy cập ngày 24 tháng 7 năm 2017.
18. “preemption”. Bản gốc lưu trữ ngày 1 tháng 9 năm 2012. Truy cập ngày 24 tháng 7 năm 2017.
19. “Control and Reservation”. Bản gốc lưu trữ ngày 26 tháng 3 năm 2013. Truy cập ngày 24 tháng 7 năm 2017.
20. “Replication and elimination for Reliability”. Bản gốc lưu trữ ngày 27 tháng 7 năm 2013. Truy cập ngày 24 tháng 7 năm 2017.
21. “Reservation Protocol (SRP) Enhancements and Performance Improvements”. Bản gốc lưu trữ ngày 17 tháng 6 năm 2013. Truy cập ngày 24 tháng 7 năm 2017.

Liên kết ngoài

• IEEE 802.1 Audio/Video Bridging task group
• IEEE 1722 Layer 2 transport protocol working group for time-sensitive streams
• IEEE 1722.1 working group for Device Discovery, Enumeration, Connection Management and Control Protocol for P1722 based devices
• IEEE 1733 AVB layer 3 transport working group^{[liên kết hỏng]}
• Networking and interoperability in AVB-capable devices, by William Gravelle, UNH-IOL
• AV Bridging and Ethernet AV – AVB overview presentation
• Forum for discussion about AVB