USB 3.0規範中譯本 第4章 超高速數據流模型

轉自：http://www.cnblogs.com/coryxie/p/3956235.html

本文爲CoryXie原創譯文，轉載及有任何問題請聯繫cory.xie#gmail.com。

本章展示數據和信息如何在超高速上通過的一種高層次的描述。請閱讀協議層一章關於低層次協議的細節。本章提供設備架構概述信息，設備框架一章會對此進一步展開。所有實現者應該閱讀本章瞭解超高速的關鍵概念。

4.1 實現者觀點 【Implementer Viewpoints】

超高速是與USB 2.0非常相似的，它提供了一個USB主機和連接的USB設備之間的通訊服務。該通訊模型保持了USB 2.0分層結構及通訊流的基本組成部分（即，點到點，同樣的傳輸類型，等等）。請參閱Universal Serial Bus Specification, Revision 2.0第5章中USB 2.0通訊流的更多信息。

本章介紹數據和控制信息是如何在超高速主機及其所連接的超高速設備之間通訊（與USB 2.0）的差異。爲了瞭解超高速數據流，下面的概念是有用的：

• 通訊流模型（Communication Flow Models）：第4.2節介紹了通訊如何在主機和設備之間通過超高速總線流動。
• 超高速協議綜述（SuperSpeed Protocol Overview）：第4.3節給出了一個超高速協議的高層次概述，並將它與USB 2.0協議作比較。
• 總體傳輸描述（Generalized Transfer Description）：第4.4節提供了數據傳輸如何在超高速工作的概述，以後各節定義每個傳輸類型的操作限制。
• 設備通知（Device Notifications）：第4.4.9提供了概述了設備通知，一種允許設備異步通知設備上的事件或狀態給其主機的特性。
• 可靠性與高效率：第4.4.10和4.4.11節總結了在超高速中可確保可靠性和提高效率的信息和機制。

4.2 超高速通訊流 【SuperSpeed Communication Flow】

超高速保留了熟悉的概念和機制，以及對端點，管道，和傳輸類型的支持。參照Universal Serial Bus Specification, Revision 2.0的細節。正如USB2.0，最終數據的消費者/生產者是端點。

端點的特性（最大數據包大小，突發長度等）在端點描述符和超高速端點伴侶描述符中報告。正如USB 2.0，端點使用尋址三劍客（設備地址，端點號，方向）來標識。

所有超高速設備必須至少實現默認的控制管道（端點0）。默認控制管道是在Universal Serial Bus Specification,Revision 2.0定義的控制管道。

4.2.1 管道 【Pipes】

超高速管道是在設備上的一個端點和主機上軟件之間的一個關聯。管道代表通過內存緩衝區在主機軟件和設備上的端點之間的搬移數據的能力，並擁有在Universal Serial Bus Specification, Revision 2.0中定義的相同行爲。主要區別是，當一個非超高速同步端點正忙時，它返回一個未準備好【Not Ready】（NRDY）響應，並且當它想再次提供服務時必須發送一個端點就緒【Endpoint Ready】（ERDY）通知。主機會按照在傳輸類型的限制範圍內，在下一個可用的機會上重新調度事務交易（transaction）。

4.3 超高速協議概述 【SuperSpeed Protocol Overview】

正如在USB 3.0架構概述一章所提到的，超高速協議被設計成能夠利用雙重單工（dual-simplex）物理層的優勢。所有的USB 2.0傳輸類型都被超高速協議支持。USB 2.0協議和超高速協議的差異被首先討論，接着對超高速中使用的數據包進行簡要說明。

4.3.1 與USB 2.0的差異 【Differences from USB 2.0】

超高速在框架層級是向後兼容USB 2.0的。然而，USB 2.0和超高速協議還是有一些根本性的差異：

• USB 2.0使用三部分事務交易（令牌，數據和握手），而超高速對這相同的三部分的使用是不相同的。對於輸出（OUTs），令牌被列入數據包；而對於輸入（INs），令牌則被握手所取代。
• USB 2.0不支持突發（bursting）而超高速支持連續突發（continuous bursting）。
• USB 2.0是一個半雙工廣播（broadcast）總線，而超高速是雙重單工（dual-simplex）單播（unicast）總線，這就允許同時進行IN和OUT事務交易。
• USB 2.0使用輪詢模型，而超高速使用異步通知。
• USB 2.0沒有流（Streaming）的能力，而超高速支持對批量端點的流（Streaming）。
• USB 2.0沒有提供機制來允許具有同步（isochronous）傳輸能力的設備來在服務間隔之間進入低功耗USB總線狀態。超高速允許具有同步（isochronous）傳輸能力的設備在服務間隔之間自動進入低功耗鏈路狀態。超高速主機可以傳送PING包到目標同步設備，以便允許時間，在啓動同步傳輸之前，將路徑轉換回到活動功率狀態。
• 如果系統進入更低的系統電源狀態，USB 2.0沒有提供機制來讓設備告知主機設備可以容忍多少延遲。因此，一個主機可能不能進入更低系統電源狀態，因爲可能會影響設備的性能（由於它缺乏一個對設備的電源策略的理解）。USB 3.0提供了一種機制，讓超高速設備使用延遲容忍消息（Latency Tolerance Messaging）告知主機其對延遲的容忍。主機可以使用這些信息來建立一個系統電源策略，將設備的延遲容忍考慮在內。
• USB 2.0以固定的1 ms/125 μs間隔傳輸SOF/uSOF。取決於主機和系統軟件的實現，設備驅動程序可能會在有限的小的調整區間內更改該間隔。USB 3.0增加了設備機制來發送總線間隔調整消息（Bus Interval Adjustment Message），被主機用來調整其125微秒總線間隔，高達+ / -13.333微秒。此外，主機可能會在一個總線間隔邊界附近寬鬆的時序窗口（relaxed timing window）內發送同步時間戳包【Isochronous Timestamp Packet】（ITP）。
• USB 2.0的電源管理，包括鏈路電源管理，總是由主機直接發起。超高速支持鏈路級的電源管理，可由鏈路的任何一端啓動。因此，每一個鏈路可以獨立地在空閒（idle）時進入低功耗狀態，而在需要通訊時退出。
• USB 2.0只在每個事務交易的端到端層級處理事務交易錯誤檢測和恢復以及流量控制。超高速將這些功能在端到端和鏈路層級進行了拆分。

 

4.3.1.1 比較USB 2.0和超高速事務交易 【Comparing USB 2.0 and SuperSpeed Transactions】

超高速雙重單工（dual-simplex）物理層允許信息同時在兩個方向通行。超高速協議允許的發射器在收到握手之前發送多個數據包。對於OUT傳輸，在USB 2.0令牌中提供的信息被整合在數據包頭中，因此不需要一個單獨的令牌。對於IN傳輸，握手被髮送到設備來請求數據。該設備可能會要麼返回數據迴應，要麼返回一個STALL握手，或返回一個未準備好（NRDY）握手來推遲傳輸直到該設備已準備就緒。

USB 2.0廣播數據包到所有已使能的下行端口。每一個設備都需要解碼每個數據包的地址三劍客（設備地址，端點，方向）以確定它是否需要作出迴應。超高速單播數據包，下游方向數據包被在主機和目標設備的直接路徑上發送，而上游方向的數據包在在設備和主機之間的直接路徑上發送。超高速數據包包含路由信息，被集線器使用，以確定數據包需要遍歷（traverse）哪些下行端口來到達設備。有一個例外：同步時間戳包（ITP）是多播到所有活動端口的。

USB 2.0風格的輪訓已被異步通知替換。超高速事務交易由主機發起，通過由主機發送一個請求後，緊接着一個設備響應。如果設備可以滿足該請求，那麼就要麼接受或發送數據。如果端點停止（halted），設備應響應一個STALL握手。如果它由於缺乏緩衝空間或數據，不能滿足請求，它迴應一個未準備好【Not Ready】（NRDY）來告訴它的主機在這個時候無法處理請求。當設備可以滿足請求時，它將會發送一個端點就緒【Endpoint Ready】（ERDY）到主機，屆時主機將重新調度事務交易。

對轉移到對包進行單播和有限的多播，加上異步通知，允許沒有活動地傳遞數據包的鏈路被放置到低功耗狀態。上游和下游端口合作，把鏈路放置到低功耗狀態，並且集線器將向上遊傳導。允許鏈路夥伴控制自己的獨立鏈路功耗狀態，以及集線器傳導在其任意的下游端口上看到的最高鏈路功耗狀態到其上游端口，使得總線迅速進入可允許的最低功耗狀態。

4.3.1.2 介紹超高速包 【Introduction to SuperSpeed Packets】

超高速包以一個16字節的頭開始。有些包只包括一個頭。所有的頭都以數據包類型（Packet Type）信息開始，用來決定如何處理包。頭被一個16位CRC校驗碼（CRC-16）保護，並以2個字節的鏈路控制字結束。 根據不同的類型（Type），大多數包包含路由信息（路由字串，Route String）和設備尋址三劍客（設備地址，端點號和方向）。路由字串是用來引導主機發送的數據包在直接路徑上通過拓撲。由設備的發送的數據包被隱式路由，因爲集線器始終將從任何下游端口看到的包轉發到其上游端口。有四種基本類型的數據包：鏈路管理包（Link Management Packets），事務交易包（Transaction Packets），數據包（Data Packets），以及同步時間戳包（Isochronous Timestamp Packets）：

• 鏈路管理包（LMP）的只穿越的一對直接連接的端口，並且主要用於管理該鏈路。
• 事務交易包（TP）遍歷直接連接主機和設備的路徑上的所有鏈路。它是用來控制數據包流，配置設備和集線器等。請注意事務交易包沒有數據有效載荷。
• 數據包（DP）遍歷直接連接主機和設備的路徑上的所有鏈路。數據包由兩部分組成：類似TP的數據包頭【Data Packet Header】（DPH）；以及數據包有效載荷【Data Packet Payload】（DPP），它由數據塊，加上爲確保數據的完整性的32位CRC（CRC-32）組成。
• 同步時間戳包【Isochronous Timestamp Packet】（ITP）是由主機發送的到所有活動鏈路的多播包。

4.4 總體傳輸描述 【Generalized Transfer Description】

每個發送到一個接收器的非同步（non-isochronous）數據包都由握手確認（被稱爲ACK事務交易包）。然而，由於超高速有獨立的發送和接收通道這樣的事實，在發送發送下一個數據包之前，發射器不必等待每個數據包明確的握手。

超高速保留了所有的基本數據流以及USB 2.0定義的傳輸概念，包括傳輸類型，管道和基礎數據流模型。本節對與USB 2.0的差別進行了討論，從協議層級開始，接着是傳輸類型限制。

USB 2.0規範採用了串行的事務交易模型。這實際上是說在開始下一個事務交易前，主機啓動並完成一個事務交易（令牌總線，數據，握手）。分割的事務交易也遵循同樣的模型，因爲它們由完全的高速事務交易（令牌，數據，握手）組成，這些事務交易用與所有其他事務交易同樣的模型完成。

超高速使用獨立的發送和接收通道，提高了USB 2.0事務交易協議。其結果是，超高速USB交易協議基本上是一種分割事務交易（split transaction）協議，允許多個輸出（OUT）"總線交易"以及最多一個輸入（IN）"總線交易"同時在總線上活動。設備響應事務交易的順序是固定以每個端點爲基礎的（例如，如果一個端點接收到三個數據包（DPs），該端點必須以這些數據包DPs被接收到的順序，爲每個數據包返回一個ACK TP）。設備響應發送到設備上的不同的端點的ACK或數據包DPs的順序，是設備實現相關的，軟件不能期望他們會以任何特定的順序出現/完成。分割事務交易協議可基於信號比特率較好地擴展（跨多個事務交易，到多個功能端點），因爲它不受傳播延遲影響。

USB 2.0協議在繼續到下一個調度的端點的總線事務交易之前，需要完成當前完整的事務交易{令牌總線，數據，握手}。所有的主機事務交易本質上都是在USB 2.0總線上的廣播。與此相反，超高速協議不廣播任何包（除了ITPs），並且包只遍歷到達預定接收者的必要的鏈路。主機通過發送握手或者數據來開始事務交易，設備響應數據或者握手。如果設備沒有數據可用或者不能接受數據，就會迴應一個包說明其不能這麼做。之後，當設備準備好接受或者發送數據時，就會發送一個通知給主機，指示其準備好恢復事務交易。此外，超高速提供將鏈路轉換進入或者退出特定的低功耗狀態的能力。進入更低的功耗狀態要麼是通過軟件控制，或者在被軟件使能後由硬件自動控制。提供了機制，可供主機和設備之間路徑上所有的鏈路從非活動功耗狀態自動轉換進入活動功耗狀態。

設備在端點描述符中報告每個端點的最大包大小。該大小隻表示數據有效載荷長度，並不包括鏈路和協議層的任何開銷。超高速帶寬分配類似於USB 2.0。

4.4.1 數據突發 【Data Bursting】

數據突發（Data Bursting）通過消除了每個包的基礎上的對確認的等待時間增強了有效性。超高速設備上的每個端點顯示在它必須等待一個明確的握手之前，它可以發送/接收（稱爲最大數據突發大小）的數據包數量。 最大數據突發大小是各個端點的能力;主機從與此端點相關的超高速端點伴侶描述符來確定一個端點的最大數據突發大小（參考第9.6.7）。

主機可以動態地以每次交易的基礎上改變突發大小，最大達到配置的最大突發大小。主機可能會使用不同大小的突發的例子包括，但不限於，一個主機上的公平策略以及對於中斷流的重試。當端點是輸出（OUT）時，主機可以很容易地控制突發長度（接收器必須始終能夠管理事務交易突發大小）。當一個輸入（IN）端點，主機可以在每次交易的基礎上通過發送到設備的確認包的一個字段對端點限制突發大小。

4.4.2 輸入傳輸 【IN Transfers】

主機和設備應遵守傳輸類型和端點特性的限制。 主機通過發送一個確認包（IN）到設備發起一次傳輸。這個確認包包含了將包路由到預想的端點的尋址信息。主機告訴設備它可以發送的數據包的數量，以及預計從設備接收到的第一個數據包的序列號。作爲迴應，端點會以適當的序列號發送數據包回主機。確認包還暗含地確認，以前的數據包被成功收到。

請注意，即使主機需要爲每個接收到的數據包發送確認包，設備仍然可以發送被請求數量的數據包，而不必等待任何確認包。

超高速輸入（IN）事務交易協議中如圖4-1所示。一個超高速總線上的輸入（IN）傳輸由一個或多個IN事務交易組成，並在出現下列任何情況之一時完成：

• 所有的傳輸數據成功被接收。
• 端點用比端點的最大數據包大小要小的數據包響應。
• 端點回應一個錯誤。

 

4.4.3 OUT Transfers

主機和設備應遵守傳輸類型和端點特性的限制。 主機通過發送一個突發的數據包到設備發起一次傳輸。每個數據包包含了將包路由到預想的端點的尋址信息。它也包括數據包的序列號。對於非同步事務交易，設備返回一個確認包，包括下一個數據包的序列號，並暗含地確認當前的數據包。

請注意，即使設備需要爲每個接收到的數據包發送確認包，主機仍然可以發送最大突發大小數量的數據包，而不必等待確認包。

超高速輸出（OUT）事務交易協議中如圖4-2所示。一個超高速總線上的輸出（OUT）傳輸一個或多個OUT事務交易組成，並在出現下列任何情況之一時完成：

• 所有的傳輸數據成功被接收。
• 主機發送一個比端點的最大數據包大小要小的數據包。
• 端點回應一個錯誤。

 

4.4.4 電源管理和性能【Power Management and Performance】

對不活動定時器以及設備驅動的鏈路電源管理的使用，提供了非常具有挑戰性的電源管理能力。當主機發送一個位於一個集線器後面，並且其端口所在的鏈路處於非活動狀態時，包不能穿透該鏈路，直到其返回到活動狀態。對於IN事務交易的情形，主機不能開始另外一個IN事務交易，直到當前的一個完成。這一行爲的效果可能對性能具有嚴重的影響。

爲了在電源管理和好的性能之間平衡，使用了推後的概念（對於輸入INs和輸出OUTs兩者）。當主機發起了一個事務交易，遇到處於非活動狀態的鏈路，一個推後的響應被集線器發送，用來告訴主機這條特別路徑現在處於推後管理狀態，並且主機應該繼續調度其他的事務交易。此外，集線器發送一個推後的請求給設備，通知它有一個事務交易被嘗試。這一機制通知了主機由於電源管理增加了延時，並且允許主機緩和了由於鏈路電源管理導致的性能影響。

4.4.5 控制傳輸 【Control Transfers】

控制傳輸的目的和特性與Universal Serial Bus Specification, Revision 2.0的第5.5節中所定義的相同。本規範的協議層一章描述用於完成控制傳輸的數據包，總線事務，以及事務交易序列。本規範設備框架一章定義對設備使用的完整的標準命令代碼。

每個設備必須實現默認控制管道作爲消息管道。這條管道用於設備初始化和管理。這條管道用來訪問設備描述符

並向設備提請求來管理其行爲（在設備側層級）。控制傳輸必須堅持同樣的在Universal Serial Bus Specification, Revision 2.0定義的要求。

超高速系統會作出"最大努力"，以支持控制傳輸在主機和設備之間傳送。如同USB 2.0一樣，功能和客戶端軟件不能爲控制傳輸請求特定的帶寬。

4.4.5.1 控制傳輸包大小 【Control Transfer Packet Size】

控制端點有固定的最大控制傳輸的數據有效載荷爲512字節，最大突發大小爲1。這些極大值適用於所有在控制傳輸的數據階段的數據事務交易。請參閱第8.12.2節的超高速控制傳輸的Setup和Status階段情況的詳細信息。

超高速設備必須報告其設備描述符的bMaxPacketSize字段的值爲09H。解碼控制管道的默認最大數據包大小的規則在第9.6.1節給出。默認控制管道必須最多支持32個序列號值 （即使用 [0-31] 範圍內的序列值）。

對於設備到主機和主機到設備的數據階段的數據傳輸和完成的要求， 總體上USB 2.0和超高速之間沒有更改（參考Universal Serial Bus Specification, Revision 2.0的第5.5.3節）。

4.4.5.2 Control Transfer Bandwidth Requirements

設備無法指示需要的控制管道帶寬。主機平衡所有控制管道以及在這些管道上的未完成的事務交易的總線訪問要求，以在客戶端軟件和在設備上的功能之間提供"最佳努力"傳送。這一策略與USB 2.0的策略是相同的。

超高速要求總線帶寬被保留可供控制傳輸使用的情況如下：

• 一個控制傳輸的事務交易可能會被調度與其他任何已定義的傳輸類型功能端點的事務交易重合。
• 控制傳輸沒有得到比其他盡力優先事務交易更好的優先權。
• 如果有多個端點的控制和批量傳輸未完成，不同的控制傳輸的端點以主機控制器實現相關的公平的訪問策略被選擇服務。
• 當一個控制端點傳送了一個流量控制事件（定義見第8.10.1節），主機會將端點從活動的調度端點中刪除。從設備收到就緒通知後，主機將恢復到該端點的傳輸。

這些要求允許一臺主機和設備之間的控制傳輸定期以"最大努力"在超高速總線上搬移數據。Universal Serial Bus Specification, Revision 2.0的第5.5.4節定義的系統軟件的"酌情行事"的行爲，也同樣適用於超高速控制傳輸。

4.4.5.3 控制傳輸數據序列 【Control Transfer Data Sequences】

超高速保留了Universal Serial Bus Specification, Revision 2.0第5.5.5節定義的控制傳輸的消息格式和總體階段順序。超高速協議定義了一些控制傳輸的Setup和Status階段的變化。然而，Universal Serial Bus Specification, Revision 2.0第5.5.5節定義的所有常規的順序要求和錯誤恢復情形，都可以直接映射到超高速協議中來。

4.4.6 批量傳輸 【Bulk Transfers】

批量傳輸的目標和特性與Universal Serial Bus Specification, Revision 2.0規範5.8節定義的類似。本規範的8.12.1節描述用來完成批量傳輸的詳細的包，總線事務，以及事務序列。批量傳輸類型是以支持想要以極大的時間可變性，傳輸可以使用任意可用的超高速帶寬，進行相當大量數據通訊的設備爲目的的。一個超高速批量功能端點提供如下：

• 以帶寬可用爲基礎訪問超高速總線。
• 可保證的數據傳輸，但是沒有帶寬和延遲的保證。

超高速保留下面的批量管道特性：

• 批量管道通訊流沒有數據內容結構的限制
• 批量管道是一個流管道，並且，因此，對於任意的管道實例，總是有通訊流進出主機。如果應用要求雙向批量通訊流，必須使用兩個批量管道（一個IN一個OUT）。

標準的USB批量管道提供了搬移一序列（stream）數據的能力。超高速增加了流（Streams）的概念，提供了協議層對於多個流（multi-stream）模型的支持。

4.4.6.1 批量傳輸數據包大小 【Bulk Transfer Data Packet Size】

批量傳輸端點應在其端點描述符中設置最大的數據包負載大小爲1024字節。它還指定端點可以接受或者發送到超高速總線的突發大小。對於批量端點允許的突發大小應在1至16範圍。所有超高速批量端點應當支持 [0-31]範圍內的序列值。

主機必須支持任何超高速批量端點。主機應當支持所有批量突發大小。主機確保沒有突發事務交易的任何數據包的數據有效載荷被髮送到大於最大數據包大小的端點【譯註：此句不太明確！】。此外，它不會發送多餘報告的最大突發大小的數據包。

批量功能端點必須始終傳輸數據字段小於或等於1024字節的數據負載。如果批量傳輸有比之更多的數據，在突發事務交易的所有數據的有效載荷必須爲1024字節長度，除了突發的最後一個數據有效載荷，它可能包含剩餘數據。批量傳輸可能跨越多個總線事務交易。當端點進行下列操作之一時，批量傳輸完成時：

• 已經傳輸了如預期數量的數據。
• 傳輸了一個數據負載小於1024字節的數據包。
• 用STALL響應

4.4.6.2 批量傳輸端口要求 【Bulk Transfer Bandwidth Requirements】

與USB2.0一樣，批量概念端點無法直視其需要的批量管道帶寬。批量事務交易在超高速總線上直視以帶寬可用爲基礎。超高速提供了對於客戶軟件和設備概念之間批量數據的"最大努力"的傳送。在超高速總線上搬移控制傳輸比搬移批量事務交易優先級更高。當有多個端點的批量傳輸沒有完成，主機將按照公平訪問策略來給各個端點提供事務交易機會，這是依賴於主機實現的。

所有的等待與系統中的批量傳輸一起競爭使用系統的可用帶寬。一個端點和其客戶軟件不能假設對於批量傳輸的特定服務比率。對於軟件客戶和其端點可用的總線時間可以隨着其他設備的被插入和拔出系統而被改變，或者隨着批量傳輸被請求到其他的功能端點而改變。客戶軟件不能假設批量和控制傳輸之間的順序；也就是說，在某些情形下，批量傳輸可能被再控制傳輸之前被傳送。

主機可以對於批量端點使用1到被報告的最大值的突發大小，來更有效地利用可用帶寬。例如，可能有比可用帶寬更多的批量傳輸，因此一個主機可以使用一個策略，每個事務交易使用更小的數據突發，來爲所有未完成的批量數據流提供公平服務。

當一個批量端點傳送了一個流量控制事件（定義見第8.10.1節），主機會將端點從活動的調度端點中刪除。從設備收到就緒通知後，主機將恢復到該端點的傳輸。

4.4.6.3 批量傳輸數據序列 【Bulk Transfer Data Sequences】

批量事務交易使用在第8.10.2節中定義的標準突發序列達到可靠的數據傳送。批量端點被一個適當的控制傳輸 （SetConfiguration，SetInterface，ClearEndpointFeature）初始化爲最初的發送或接收的序列號和突發大小（參考第8.12.1.2節和第8.12.1.3節）。同樣，主機當它成功完成了上述適當的控制傳輸之後，對批量端點也假定初始的發送或接收序列號以及突發大小。

超高速批量管道的停止（Halt）情形與爲USB 2.0定義的影響批量端點相同的一面。從停止情形恢復也與USB 2.0相同（參考Universal Serial Bus Specification, Revision 2.0第5.8.5節）。批量管道停止情形包括對事務交易的STALL握手響應，或耗盡主機由於在傳輸錯誤時事務交易的重試策略。

4.4.6.4 批量流 【Bulk Streams】

標準的USB批量管道代表在主機和設備間通過主機內存緩衝區和設備的端點間搬移單數據流（FIFO）的數據的能力。超高速流提供對多流（multi-stream）模型的協議級別的支持，並利用"流式"管道通信模式（參考Universal Serial Bus Specification, Revision 2.0第5.3.2節）。 流使用主機和設備間的流協議（Stream Protocol）來管理。每個流都被分配一個流識別碼（Stream ID）（SID）。

流協議（Stream Protocol）定義了一個握手，允許設備或者主機來建立與一個端點相關聯的當前流ID【Current Stream (CStream) ID】。主機使用CStream ID來選擇將被用來在管道上做後續數據傳輸的命令或操作特定的端點緩衝區【Endpoint Buffer(s)】。設備用CStream ID來選擇將被使用到的功能數據緩衝區【Function Data buffer(s)】。

圖4-3的例子代表一個輸入批量管道，這裏建立起了大量的流（Streams）。在主機內存中與每個流（Stream）相關的是一個或者多個端點緩衝區（Endpoint Buffers）來接收流數據（Stream data）。在設備端，也有一個相應的特定於命令或者功能的數據，會被傳輸到主機。

當設備有對特定的流可用的數據時（如圖中的G），它就用發送ERDY加上CStream ID作爲標籤，並且主機會開始發送加有CStream ID標籤的IN ACK TP到設備。設備會通過返回與CStream ID相關的功能數據，並且也是加上CStream ID爲標籤。當主機接收到數據，就用CStream ID來選擇一組端點緩衝區（Endpoint Buffers）用來接收數據。

當功能數據被耗盡，設備終結該流（參考8.12.1.4節）。主機也被允許終結流，如果它用完了端點緩衝區的話。流可以被用來，例如，支持大容量設備命令排隊（mass storage device command queuing）所需要的亂序（out-of-order）數據傳輸。

一個標準的批量端點有單組端點緩衝區（Endpoint Buffers）與之相關聯。流擴展了一個端點可以訪問的主機緩衝區個數，從1直到65533。在主機緩衝區和Stream ID之間有一個1:1的映射。

設備類定義的方法被用來協調主機用來選擇端點緩衝區的流標識（Stream IDs），以及設備用來選擇與特定的流相關聯功能數據。典型地，這是通過帶外機制（out-of-band mechanism）（例如，另一個端點）來完成的，該機制用來在主機和設備之間傳遞有效的流標識（Stream IDs）。

對於當前流（Current Stream）的選擇可以被主機或者設備發起，在任一情況下，流協議（Stream Protocol）都提供了一個可以讓選擇被拒絕的方法。例如，主機可以拒絕一個由設備發起的選擇，如果它沒有可用的端點緩衝區可用。或者設備也可以拒絕由主機發起的流選擇，如果它沒有可用的功能數據。設備類定義什麼時候一個流可以被主機或者設備選擇，以及當一個流被拒絕時將會有的動作（參考第8.12.1.4節）。

製造商和設備類定義的算法組合，決定流如何在設備上被調度。流協議提供了用於啓動，停止以及切換流的方法（參考第8.12.1.4節）。

流協議定義的機制允許設備或者主機來對流進行流量控制。這些機制與標準的批量流量控制部分重疊（overlap）。

主機可以啓動或者停止一個流。例如，主機將會在其用完緩衝空間時停止流。當主機控制器通知設備這一情形時，設備可以切換到另一個流，或者等待並在主機接收到更多緩衝區時繼續該相同的流。

流協議也提供了一個機制，允許主機在調度緩衝區（Endpoint Buffers）被加入到管道時，異步地通知設備。這在由於主機用完調度緩衝區而必須終結流，而設備還有功能數據要傳輸的情形有用；沒有這種機制，設備可能必須週期性地重啓該流（影響功耗管理），或者必須要一個長延時的帶外方法（out-of-band method）。

由於流是基於一個標準的批量管道運行，一個錯誤就會讓管道暫停（halt），停止所有的活動。排除暫停情形是通過控制管道的軟件干預達到的，就像標準的批量管道一樣。

最後，流極大地增加了批量管道的功能性。同時也具有最小化的影響，即在主機和設備端支持該特性的附加硬件要求。

4.4.7 中斷傳輸 【Interrupt Transfers】

中斷傳輸的目標和特性與Universal Serial Bus Specification, Revision 2.0規範5.7節定義的類似。超高速中斷傳輸類型意圖支持需要高可靠性方法以固定的服務間隔來通信小量數據的設備。本規範的協議層一章（Protocol Layer）詳細描述用來完成中斷傳輸的包，總線事務，以及事務序列的細節。一個超高速中斷端點名義上提供如下：

• 可保證的最大服務間隔。
• 可保證的在下一個服務間隔內對於傳輸嘗試的重試。

對一箇中斷達到而言，中斷傳輸在每個服務間隔都會得到嘗試。帶寬被保留，以保證每個服務間隔一次的傳輸嘗試。一旦一個傳輸成功，直到下一個服務間隔之前，不會再進行傳輸嘗試。如果端點響應一個未準備就緒通知（not ready notification），或者一個確認，指示其不能接受更多包，那麼主機不會嘗試另一次傳輸，直到它接收到一個準備就緒通知（ready notification）。主機接着必須在接收到該通知後兩個服務間隔內對該端點提供服務。所請求的服務間隔被在其端點描述符中描述。

超高速保留下面的中斷管道特性：

• 中斷管道通訊流沒有數據內容結構的限制
• 中斷管道是一個流管道，並且，因此， 總是單向的。

4.4.7.1 中斷傳輸包大小 【Interrupt Transfer Packet Size】

中斷傳輸端點要指定其可以在超高速總線上接受或傳輸的最大數據包負載大小。對於支持突發大小大於1的中斷端點，唯一允許的最大的數據包負載大小爲1024字節；對於突發大小等於1的中斷端點，最大的數據包負載大小可以在1到1024之間任意大小。中斷端點的最大突發大小是3。所有超高速中斷端點應當支持 [0-31]範圍內的序列值。

超高速中斷端點只意圖以固定的服務間隔搬移小量數據。超高速協議不要求中斷事務交易具有最大大小。

主機必須支持超高速中斷端點。主機應當支持所有允許的中斷包大小和突發大小。主機確保沒有突發事務交易的任何數據包的數據有效載荷被髮送到大於最大數據包大小的端點【譯註：此句不太明確！】。此外，它不應該發送多於報告的最大突發大小的數據包。

中斷端點必須始終傳輸數據字段小於或等於端點的最大包大小的數據負載。如果中斷傳輸有比最大包大小更多的數據，在突發事務交易的所有數據的有效載荷必須爲最大包大小字節長度，除了突發的最後一個數據有效載荷，它可能包含剩餘數據。中斷傳輸可能跨越多個總線事務交易。當端點進行下列操作之一時，中斷傳輸完成時：

• 已經傳輸了如預期數量的數據。
• 傳輸了一個數據負載小於最大包大小字節的數據包。
• 用STALL響應

4.4.7.2 中斷傳輸帶寬要求 【Interrupt Transfer Bandwidth Requirements】

週期端點在超高速總線上可以分配到80％總可用帶寬。 中斷管道通過其端點端點描述符指定其所需的服務間隔限定。中斷端點可以指定所需的時間爲2^（bInterval - 1）× 125微秒，其中bInterval 的範圍是1到16（包括）。USB系統軟件在配置期間將利用這一信息，以確定一個可以支持的週期。系統提供的週期可以短於設備預期的週期，端到由超高速定義的最短總線週期（125微秒，也稱爲總線間隔）。請注意，總線上的錯誤可阻止中斷交易在總線上成功被傳送，結果超過所需的週期。

超高速中斷端點每個服務間隔可以搬移最多三個最大大小的數據包（3 × 1024個字節）。中斷傳輸通過在每個服務間隔訪問中斷端點來在USB上搬移數據。對於中斷端點，除了訪問端點並請求中斷傳輸之外，主機沒有辦法確定是否端點可以源發/接收數據。當被主機訪問時，如果一箇中斷輸入（IN）端點沒有中斷數據需要傳輸，或中斷輸出（OUT）端點接受緩衝區不足以接收數據時，它用流量控制響應作爲迴應。

端點只在有中斷數據時提供中斷數據，以避免出現軟件客戶端被錯誤地通知傳輸完成。零長度的數據有效載荷是有效的傳輸，並且可能對一些實現有用。主機可以在任何服務間隔內任意時間點訪問端點。中斷端點不應假設固定間距的事務交易嘗試。中斷端點只可以假設它會在服務間隔限定內收到一個事務交易嘗試。錯誤可以阻止服務間隔內數據成功交換，主機無須在同一服務間隔重試事務交易，只需要在下一個服務間隔內重試事務交易。

4.4.7.3 中斷傳輸數據順序 【Interrupt Transfer Data Sequences】

中斷事務交易使用在第8.10.2節中定義的標準突發序列達到可靠的數據傳送。中斷端點被一個適當的控制傳輸 （SetConfiguration，SetInterface，ClearEndpointFeature）初始化爲最初的發送或接收的序列號和突發大小（參考第8.12.1.2節和第8.12.1.3節）。同樣，主機當它成功完成了上述適當的控制傳輸之後，對中斷端點也假定初始的發送或接收序列號以及突發大小。

超高速中斷管道的停止（Halt）情形與爲USB 2.0定義的影響中斷端點相同的一面。從停止情形恢復也與USB 2.0相同（參考Universal Serial Bus Specification, Revision 2.0第5.8.5節）。中斷管道停止情形包括對事務交易的STALL握手響應，或耗盡主機由於在傳輸錯誤時事務交易的重試策略。

4.4.8 等時傳輸 【Isochronous Transfers】

超高速等時傳輸的目標與Universal Serial Bus Specification, Revision 2.0規範5.6節定義的類似。正如USB 2.0，超高速等時傳輸類型的目的是支持流，以執行具有錯誤容忍性，在固定服務間隔範圍內的週期傳輸。超高速不傳輸如USB 2.0的幀開始（start of frames），但是時序信息會被通過等時時間戳包【Isochronous Timestamp Packets (ITPs)】傳輸到設備。本規範的協議層一章（Protocol Layer）詳細描述用來完成等時傳輸的包，總線事務，以及事務序列的細節。同時該部分也會描述時序信息是如何傳遞到設備的。超高速等時傳輸提供如下：

• 對於在超高速總線上的事務交易具有固定延遲的可保證帶寬
• 通過管道的可保證的數據率，只要數據被提供給管道

對於等時端點，等時事務交易在每個服務間隔都會被嘗試。被超高速總線允許的等時端點被保證他們在總線上所請求的帶寬。主機可以在服務間隔的任意時間對特定的設備端點請求數據或者發送數據到設備。端點所請求的服務間隔在端點描述符中描述。超高速等時傳輸類型被設計爲以相同的平均速率生產和消費數據，即源發及接收數據。超高速等時管道是流式管道，並且總是單向的。端點描述符識別是否一個等時管道的通信流是進還是出主機。如果設備要求雙向等時通信流，必須使用兩個等時管道，一個方向一個。

每當有一個等時傳輸需要在不活動的鏈路上傳送時，超高速電源管理可能干擾等時傳輸。結果所造成的時延可能導致數據不能再服務間隔內到達。爲了克服這一問題，超高速定義了PING 以及 PING_RESPONSE機制（參考8.5.7節）。在發起一次等時傳輸之前，主機可以發送一個PING到設備。設備使用PING_RESPONSE包作爲響應，告訴主機在從主機到設備的所有鏈路都是活動的。