原文地址 https://www.cnblogs.com/coryxie/p/3956463.html
本文爲CoryXie原創譯文，轉載及有任何問題請聯繫cory.xie#gmail.com。
本章描述USB 3.0 集線器的體系結構要求。本章還描述主機下行口和集線器下行口之間功能性的不同之處，以及設備上行口和集線器上行口之間的不同之處。本章包括三個主要的子模塊的其中兩個的描述：超高速集線器中繼器/轉發器（SuperSpeed hub repeater/forwarder）以及超高速集線器控制器（SuperSpeed hub controller）。USB 2.0 集線器子模塊在Universal Serial Bus Specification, Revision 2.0中介紹。本章還描述了集線器對於錯誤恢復，復位，掛起/恢復，集線器請求行爲的操作，以及集線器描述符。Universal Serial Bus Specification, Revision 2.0的集線器規範一章提供了實現者必要的信息來設計遵循USB 3.0規範的集線器。
10.1 集線器特性總結[Hub Feature Summary]
集線器提供了USB設備和主機之間的電氣接口。集線器直接負責提供使得USB用戶友好的多種屬性，將其複雜性從用戶處隱藏起來。下面列出的是集線器支持的USB功能性的主要方面：
- 連接性行爲
- 電源管理
- 設備連接和斷開連接檢測
- 總線錯誤檢測和恢復
- 超高速和USB 2.0（高速，全速，以及低速）設備的支持
USB 3.0集線器包含一個USB 2.0集線器，以及一個由超高速集線器中繼器/轉發器（SuperSpeed Hub Repeater/Forwarder）和超高速集線器控制器（SuperSpeed Hub Controller）這兩個主要部件組成的超高速集線器。USB 2.0集線器在USB 2.0規範中描述。後面所有的引用，如無特殊說明，均指超高速集線器的組件。集線器中繼器/轉發器（SuperSpeed Hub Repeater/Forwarder）負責連結性的建立和拆除；也負責異常處理，例如總線錯誤檢測和恢復，以及設備連接和斷開連接檢測。集線器控制器（SuperSpeed Hub Controller）提供主機到集線器的通信的機制。集線器特定的狀態和控制命令允許主機配置集線器，並監視和控制其單獨的下行口。
圖10-2顯示了一個4端口USB 3.0集線器的高層次塊狀圖，以及上行口和下行口的位置。USB 3.0集線器是兩個集線器的邏輯組合：USB 2.0集線器和超高速集線器。每個集線器在獨立的數據總線上獨立操作。典型地，唯一的信號共享邏輯是對的VBUS控制。如果USB 2.0集線器或者超高速集線器需要，就會對一個下行口加電。USB 3.0集線器只要可能，就會盡量連接上行口的兩個接口。所有報漏出來的USB 3.0集線器下行口都應該支持超高速和USB 2.0連結。主機控制器端口可能還有不同的要求。
圖10-2顯示了USB 3.0集線器的包含超高速集線器中繼器/轉發器（SuperSpeed Hub Repeater/Forwarder）和超高速集線器控制器（SuperSpeed Hub Controller）的超高速部分。
USB 3.0集線器的USB 2.0部分應該滿足USB 2.0規範的所有要求，除非有特別的例外說明。
集線器中繼器/轉發器（Hub Repeater/Forwarder）負責管理上行口和下行口之間的連結性，工作在超高速。集線器控制器（Hub Controller）提供狀態和控制，允許主機訪問超高速集線器。
當集線器上行口連接到只操作在高速或者全速的電氣環境時，下行口連接的設備的超高速連結性不可用。
不像USB 3.0外設，USB 3.0集線器要求將上行口連接到USB 3.0和USB 2.0兩條總線上。對於USB 3.0集線器的下行端口，超高速連接可以在系統軟件的控制下被使能或者禁能。如果集線器上行口的超高速連接不被該USB 3.0集線器所連接的端口所支持，集線器就會禁止掉所有下行口的超高速支持。如果USB 3.0集線器上行口沒有連接到USB 2.0或者超高速端口上，那麼集線器就不提供電源到其下行端口，除非其支持USB實現者論壇的電池充電（Battery Charging）規範。參考10.3.1.1節關於何時集線器允許移除下行口的VBUS電源的詳細討論。USB 3.0規範允許自供電和總線供電的集線器。
下面的章節介紹在不同類型的系統中，當主機系統加電之初，對於圖10-3所示的簡單拓撲的典型的連接管理流程。
注意：這些示例概述了系統如預期操作的情形，對於錯誤處理的情形在本章後面描述。
10.1.1 支持超高速的主機具有支持超高速的軟件
當主機被斷電，集線器不提供電源到下行口，除非集線器支持充電應用（參考10.3.1.1節）。
當主機被加電，並且使能了下行口的超高速支持，默認情況下有如下的典型事件序列：
- 集線器檢測到VBUS和超高速支持，並給其下行口加電並使能超高速
- 集線器以超高速和高速設備同時連接
- 設備檢測到VBUS和超高速支持，以超高速設備連接
- 主機系統開始以高速和超高速同時枚舉集線器
- 主機系統開始以超高速枚舉設備
10.1.2 USB 2.0主機
當主機被斷電，集線器不提供電源到下行口，除非集線器支持充電應用（參考10.3.1.1節）。
當主機被加電，並且沒有超高速的硬件支持，有如下的典型事件序列：
- 集線器檢測到VBUS和超高速支持，並以超高速設備連接
- 主機系統以高速開始集線器枚舉
- 集線器被軟件（USB 2.0）控制給下行口加電
- 設備以高速連接
- 主機系統開始以高速枚舉設備
10.1.3 集線器連接性 [Hub Connectivity]
集線器根據是否是在傳導數據包頭/數據包負載交易（traffic），其他的包交易，恢復信號（resume signaling），或者是在空閒（Idle）狀態而展示不同的連接性行爲。
10.1.3.1 包信號連結性 [Packet Signaling Connectivity]
集線器中繼器/轉發器包含一個應該總是在上行方向連接的端口（稱爲面向上行口），以及一個或者多個面向下行的端口。上行連結性定義爲朝向主機，而下行連接性被定義爲朝向設備。超高速集線器控制器包含對包頭和數據的緩衝區。超高速集線器控制器不使用在USB 2.0中爲高速連結性而使用的repeater-only模式。這一改變允許多個下行設備同時發送異步消息而無數據丟失，並且，當有些交易（traffic）被指向鏈路不處於U0狀態的下行口時，會被存儲之後傳送。
圖10-4顯示了集線器上行和下行方向的高層級的信號連結性行爲。後面的章節會對集線器內部緩衝機制和連結性作更多詳細描述。集線器也有空閒（Idle）狀態，在此期間集線器沒有連結性。當處於空閒（Idle）狀態時，所有的集線器端口（上行加下行）都處於U1, U2，或者在U0接收或者發送邏輯空閒信號（logical idles），等待下一個包的開始。
如果下行口是使能的（即，處於可以通過集線器傳導信號的狀態），並且集線器在該端口檢測到了包開始標誌，即掀起就開始存儲包頭。當有效的頭包（header packet）被在一個下行口上接收到時，就會在該集線器的上行口建立起朝上行方向的連接性。集線器會將在下行口上接收到的頭包向上行發送，但不會向其他的下行口發送。這就意味着當設備或者集線器向上行傳送一個包時，只有連接發送設備和主機所在的一條直線上的集線器會看到該包。
除了 Isochronous Timestamp 包以外的所有包在向下行方向上都是unicast；集線器使用一個直接連結性模型（direct connectivity model）來操作。這就意味着當主機或者集線器向下行傳送一個包的時候，只有在主機和接收者設備之間的一個直線上的那些集線器將會見到該包。當一個集線器在它的上行端口上檢測包開始的時候，集線器就開始儲存該包頭。每當一個有效的頭包已經在一個集線器上行端口上被收到的時候，該集線器就使用在該包頭中的路由字串(Route String)（Route String）和在枚舉期間被分配的集線器深度值（hub depth value），來建立僅僅到被指定的端口的連結性。如果該指定的端口沒被使能，它就不向下行傳導包信號。如果頭包被路由到一個沒被使能的下行端口，一個鏈路處於U3的端口, 或一個不存在的下行端口，集線器將默默地丟棄該頭包。在這些情況下，集線器仍然將執行正常的對於該頭包的鏈路層次的確認。
10.1.3.2 路由信息 [Routing Information]
在集線器上行端口上被收到的包，被基於包含在在該包頭的一個20比特字段（路由字串(Route String)）信息而路由。路由字串(Route String)連同一個集線器深度值，被集線器用以爲被指定到下行的包識別目標端口。集線器深度值被軟件使用設置集線器深度（Set Hub Depth）請求來分配。集線器進入被配置狀態之前，會忽略路由字串(Route String)，而假設所有的包是直接路由到該集線器自己。集線器上行端口將被端口號0來代表，而下行端口由1號端口開始，並循序地向上計數。每當一個集線器控制器以包含路由字串(Route String)的包迴應一個路由給該集線器的包，或者源發一個包（除了集線器正在推後的包以外）時，集線器應該將路由字串(Route String)設置爲零。
圖 10-5 以五個層級的四端口USB 3.0集線器的一個示例拓撲舉例說明了路由字串(Route String)的使用。對於每個層的集線器的集線器深度數值在圖中被說明。在拓撲中的每個集線器以及每個設備都包含路由字串(Route String)，會被用來路由包到該集線器/設備。對於每個集線器深度，在該集線器深度決定路由目標的路由字串(Route String)的八位組（octet）以粗體和大小超過該路徑串其餘部分的較大的字型被顯示。主機根端口沒被包含在這20個比特的路由字串(Route String)之中。
10.1.4 恢復連結性 [Resume Connectivity]
集線器對於由上行和下行發起的恢復信號展現出不同的連結性行爲。除非下行端口被掛起（suspended）而且自從它被掛起（suspended）之後已經收到恢復信號[譯註1]，集線器不從上行端口傳導恢復信號到任何它的下行端口。圖 10-6 舉例說明了集線器的上行和下行恢復連結性。
[譯註1：原文此處爲has received，筆者懷疑此處應爲has not received，否則這裏會產生死鎖現象。]
如果集線器上行端口被掛起，而且集線器從一個掛起的下行端口檢測到恢復信號，集線器就會向上行傳導該信號而且不反射該信號到任何下行端口（包括髮起恢復信號的下行端口）。如果一個集線器上行端口沒被掛起，而且集線器從一個掛起的下行端口檢測到恢復信號，集線器就會反射恢復信號到該下行端口。注意，軟件在該集線器的上行端口之上不應該發起到U3的轉換，除非它已經在所有的被使能的下行端口上開始到U3的轉換了。在第 10.8 節將會有恢復連結性詳細的討論。
10.1.5 集線器故障恢復機制 [Hub Fault Recovery Mechanisms]
集線器是在主機和其他設備之間建立連結性的必要的USB組件。任何的連結性故障應該儘可能地被避免，在不太可能避免而最終發生的時候也能被檢測到，這是至關重要的。
集線器也必須能夠檢測到丟失的或者損壞了的被定址到集線器控制器的包，而且將之復原。因爲集線器控制器事實上是另外的一個USB設備，它將遵從和其他的USB設備如第8章所描述的相同規則。
10.1.6集線器頭包緩衝區結構 [Hub Header Packet Buffer Architecture]
圖 10-7 顯示了一個SuperSpeed集線器典型的頭包緩衝區實現的邏輯表示。邏輯地，一個SuperSpeed集線器有單獨的與每個端口的上行及下行通訊相關聯的頭包緩衝區。當一個集線器在它的上行端口上接收到一個頭包的時候，它路由頭包到適當的下行頭包緩衝區準備傳輸（除非頭包是給該集線器的）。當集線器在一個下行端口上接收到一個非 LMP 的頭包的時候，它就將該頭包路由到上行端口的頭包緩衝區準備傳輸。頭包傳輸後，仍然被保持在集線器頭包緩衝區中，直到對於頭包的鏈路層級的確認（LGOOD_n）被收到爲止。這就允許集線器如果必要的話可以重試頭包，確保頭包在鏈路層級正確地被收到。當頭包指向處於低功耗鏈路狀態的下行鏈路的時候，頭包緩衝區也允許讓集線器儲存頭包直到他們能被轉發爲止。集線器儲存頭包並且一旦鏈路變成活躍就遞送它。
10.1.6.1 集線器數據緩衝區結構 [Hub Data Buffer Architecture]
圖 10-8 顯示了在典型的 SuperSpeed集線器中數據緩衝區結構的邏輯表示法。SuperSpeed 集線器在上行以及下行兩方向上爲數據包負載（DPP）提供獨立的緩衝區。USB 3.0 結構允許在上行以及下行兩方向上發生併發的事務。在圖中，有兩個數據包正在下行方向進行。集線器能同時儲存多於一個數據包負載。在罕有的情形下，數據包負載由於緩衝不可用而被丟棄的時候，端到端協議將會藉由重試該事務而恢復。等時（isochronous）協議不包括重試。然而，在實際的物理總線上，丟棄錯誤被期望要比比特錯誤發生的頻率少。
注意：數據包頭以和其他的頭一樣的方式，被使用頭包緩衝區儲存和處理。DPPs 使用分開的數據緩衝區被處理。
10.2 集線器功耗管理 [Hub Power Management]
10.2.1 鏈路狀態Link States
集線器必須要在所有的端口（上行以及下行）上支持U0, U1, U2, 以及U3狀態。
10.2.2 集線器下行端口U1/U2定時器[Hub Downstream Port U1/U2 Timers]
集線器必須在每一個下行端口上要有U1以及U2不活動定時器。Timeout值可以被編程，並且可以被主機軟件設置。Timeout值爲0意味着定時器被禁止。U1/U2的默認timeout值爲0。在PowerOn Reset或者集線器上行口被reset時，所有的下行口U1以及U2的timeout值都被複位到默認值。當街收到SetPortFeature請求進行端口復位時，下行口U1以及U2的timeout值也被複位到默認值。本章展示的下行口狀態機描述U1以及U2的timeout值被使能的時候得特定的操作規則。
- 集線器下行端口應該接受由鏈路參與方（link partner）發起的U1或者U2進入請求（U1 or U2 entry），除非相應的U1/U2 timeout被設置爲0，或者還有導向給該下行端口的事務交易。
- 如果集線器已經在上行口接收到一個有效的包，並且這個包已經被路由到了一個下行口，那麼集線器應該在該下行端口上拒絕鏈路進入U1或者U2的嘗試，直到這個包已經被成功傳輸爲止。如果集線器正在接收一個包但是還沒有判定該包的目的地的時候，集線器也可以在該下行端口上拒絕鏈路進入U1或者U2的嘗試。集線器的實現應該確保不存在競爭條件而導致一個沒被推後的頭包，被放入鏈路處於或正進入U1, U2, 或U3的下行端口的隊列準備傳輸。
- 如果相應的timeout值被設置爲0，集線器下行端口應該拒絕所有的U1以及U2進入請求。
- 集線器U1以及U2不活動定時器不應該被等時時間戳包（Isochronous Timestamp Packet）復位。
10.2.3 下行/上行端口鏈路狀態轉換 [Downstream/Upstream Port Link State Transitions]
集線器應該評估它的下行鏈路功耗狀態，以便當上行端口沒有處於等待狀態的上行通訊（no pending upstream traffic）的時候，它傳導它的所有下行端口中的最高鏈路狀態到它的上行端口。U0 是最高鏈路狀態，接着是 U1, 然後 U2, 然後 U3, 然後 Rx.Detect，然後 SS.Disabled。如果一個上行端口鏈路狀態轉換會導致進入已經被軟件禁止的上行端口鏈路狀態，集線器將轉換該上行端口鏈路進入下一個最高的被使能的U狀態。集線器絕不會自動地嘗試轉換集線器上行端口到U3.
在這一章節中所呈現的下行端口狀態機，提供並滿足了根據下行端口鏈路狀態的變化而改變上行端口鏈路狀態的特定的時序要求。
每當集線器接收到一個包，被路由到不處於U0的下行端口的時候，集線器也應該在適當的下行端口上發起一個鏈路狀態轉換。在這一章節中所呈現的集線器上行端口狀態機，提供並滿足了對於這些轉換的特定的時序要求。如果被使能，端口狀態變化中斷，例如，由於下行端口上的連接事件，將會導致上行鏈路發起到U0的轉換。
10.3 集線器下行面端口[Hub Downstream Facing Ports]
下面章節提供了一個狀態機的功能描述，該狀態機對於下行端口顯示了正確的必要的行爲。
圖 10-9 顯示了下行面端口狀態機。每一個狀態在第 10.4.2 節描述。在下面的圖表中，一些進入狀態的進入條件沒有顯示起始狀態。這些條件有多個起始狀態，並且這些單獨的轉換線沒被顯示，以簡化圖表。對於所進入的狀態的描述會指示從那些狀態轉換而來是可適用的。
注意：對於根集線器，從上行面端口的狀態機來的信號依賴於特定的實現（implementation dependent）。
10.3.1 集線器下行面端口狀態機描述[Hub Downstream Facing Port State Descriptions]
10.3.1.1 DSPORT.Powered-off
DSPORT.Powered-off狀態是邏輯電源關閉狀態。在DSPORT.Powered-off狀態下，集線器可能還是會被要求或者選擇鄉下行端口提供VBUS。對於存在VBUS的詳細要求在本節後續描述。
如果下面任意情形發生，端口應該轉換到該狀態：
- 從任意狀態，當集線器接收到ClearPortFeature(PORT_POWER)請求時。在這種情形下，電源僅在下面條件滿
足時會從端口上移除：不會影響集線器的任意下行口上的低速，全速，或者高速操作，也不會影響除了目標端口之外的其他端口的超高速（SS）操作。
- 從任意狀態，當端口丟掉本地電源或者發生過流情形。
- 從任意狀態，當VBUS從集線器上行口上被移除。
- 從任意狀態，如果集線器上行端口鏈路轉換到SS.Disabled狀態。
- 從任意狀態，如果集線器上行端口鏈路已經連續8次Rx.Detect事件而沒有檢測到遠端接收器終端阻抗（far-end receiver terminations）。
- 從任意狀態，如果集線器上行端口接收到一個SetConfiguration(0)請求。在此情形下，下行端口保持
在DSPORT.Powered-off狀態。不論其他條件如何，直到集線器被複位，或者集線器上行口接收到非0的SetConfiguration請求。非0的SetConfiguration請求之後，遵循正常的狀態機規則。
如果由於一個在其他端口上的過流情形，並且該過流情形可能已經導致提供給本端口的電源下降到規定的極限值以下，那麼端口會進入DSPORT.Powered-off狀態。
如果集線器在本地電源存在的情形下被配置，而此後本地電源丟掉了，如果電源尚可以用來運行集線器控制器的話，集線器應該將所有的端口置於Powered-off狀態。在DSPORT.Powered-off狀態，端口的鏈路處於SS.Disabled狀態。
表 10-1 顯示了集線器下行端口允許的 VBUS 狀態，對應於集線器上行口可能狀態以及下行端口邏輯端口電源狀態。這個表覆蓋了該集線器有足夠的電源提供電源給下行的端口（本地電源存在）的情形。對於沒有實現對每個端口進行電源控制（per port power control）的集線器，所有將被因移除VBUS而影響的下行端口，都應該在集線器移除VBUS之前，進入電源可能被關閉的狀態。
注意：集線器可能一直提供電源到它所有的下行端口，來支持諸如從USB端口充電這樣的應用。
表 10-1.下行端口 VBUS 需求
集線器 上行端口 連接狀態 | 下行端口的 SuperSpeed 端口電源關閉（PORT_POWER ＝ 0) 下行端口的 USB 2.0 端口電源打開 （PORT_POWER ＝ 1) | 下行端口的 SuperSpeed端口電源打開 （PORT_POWER ＝ 1) 下行端口的 USB 2.0端口電源關閉 （PORT_POWER ＝ 0) | 下行端口的USB 2.0 以及 SuperSpeed 端口電源關閉（PORT_POWER ＝ 0) |
SuperSpeed | 打開[注1] | 打開 | 可能關閉 |
USB 2.0 | 打開 | 可能關閉 | 可能關閉 |
SuperSpeed 和USB 2.0 | 打開 | 打開 | 可能關閉 |
沒有VBUS | 可能關閉 | 可能關閉 | 可能關閉 |
[注1]如果集線器上行端口不能在 USB 2.0 總線上連接，下行端口 VBUS 可能在這個狀態中關閉。
10.3.1.2 DSPORT.Disconnected (等待超高速(SS)連接)
這是本地電源有效時（(self-powered）或者變得有效時（bus-powered）的默認狀態。端口在下面的任意情形下轉換進入本狀態：
- 從DSPORT.Powered-off狀態，當集線器收到SetPortFeature(PORT_POWER)請求時。
- 從除了DSPORT.Powered-off狀態的任意狀態，當端口檢測到一個斷開連接事件。
- 從DSPORT.Powered-off狀態，當集線器的上行口的鏈路從Rx.Detect轉換到polling狀態。
- 從DSPORT.Resetting狀態，當端口的鏈路在復位期間從Rx.Detect.Active狀態超時。
- 從DSPORT.Disabled狀態，當端口接收到一個SetPortFeature(PORT_LINK_STATE) Rx.Detext請求。
- 從DSPORT.Resetting狀態，如果端口的鏈路在復位期間從任意Polling substate狀態超時。
- 從DSPORT.Training狀態，如果端口的鏈路從任意Polling substate狀態超時。
- 從DSPORT.Loopback狀態，如果端口鏈路在Loopback.Exit狀態中執行了一次成功的LFPS握手。
在本狀態，端口的鏈路應該處於Rx.Detect狀態。
注意：如果集線器的上行端口的鏈路處於U3，端口的鏈路應該還是要以Rx.Detect狀態正常執行連接檢測。
10.3.1.3 DSPORT.Training
當檢測到SuperSpeed遠端接收器終端阻抗（far-end receiver terminations）時，端口從DSPORT.Disconnected狀態轉換到本狀態。
在本狀態，端口的鏈路應該處於Polling狀態。
10.3.1.4 DSPORT.ERROR
只有當能支持SuperSpeed的設備存在，並且在嘗試操作該鏈路的時候發生了嚴重的錯誤條件的時候，端口才會轉換至本狀態。。
端口在下面的任意情形下轉換進入本狀態：
- 從DSPORT.Enabled狀態，如果端口鏈路要進入恢復（recovery）但是還沒有恢復就超時了。
- 從DSPORT.Resetting狀態，如果U1 或者 U2 exit失敗。
- 從DSPORT.Loopback狀態，如果端口是loopback master，但是Loopback.Exit 的 LFPS握手失敗了。
- 從DSPORT.Enabled狀態，如果Port Configuration如8.4.5所述那樣失敗了。
在本狀態，端口的鏈路應該處於SS.Inactive狀態。
10.3.1.5 DSPORT.Enabled
端口在下面的任意情形下轉換進入本狀態：
- 從DSPORT.Training狀態，當端口鏈路成功進入U0。
- 從DSPORT.Resetting狀態，當復位操作成功完成。
處於DSPORT.Enabled狀態的端口可以在上行和下行兩個方向傳導包。在power on 或者 warm reset之後，當集線器下行端口首次轉換到DSPORT.Enabled狀態，集線器應該傳送一個定義於8.4.5節中的端口配置LMP。
在power on reset之後，當集線器下行端口首次轉換到DSPORT.Enabled狀態，U1以及U2不活動定時器應該被複位到0。
當進入enabled狀態後，鏈路應該處於U0。
如果在下行端口進入DSPORT.Enabled狀態是，集線器的上行端口的鏈路處於U3，並且集線器沒有使能remote wakeup，那麼下行端口應該在tDSPortEnabledToU3時間內，在其鏈路上發起一次到U3的轉換。
第 10.4 節提供了一個狀態機，該狀態機顯示了一個功能性正確的實現，用於下行端口在DSPORT.Enabled狀態下管理不同的鏈路狀態。
10.3.1.6 DSPORT.Resetting
除非端口正處於DSPORT.Powered-off 或者 DSPORT.Disconnected 狀態，否則當接收到SetPortFeature(PORT_RESET) 或者 SetPortFeature(BH_PORT_RESET) 請求後，下行端口應該轉換進入DSPORT.Resetting 狀態。如果下行端口正處於DSPORT.Powered-off 或者 DSPORT.Disconnected 狀態，並且接收到一個SetPortFeature reset請求，該請求就會被忽略。如果端口狀態是DSPORT.Error，並且接收到一個SetPortFeature(PORT_RESET) 或者 SetPortFeature(BH_PORT_RESET) 請求，端口應該在tDSPortResetToLFPS時間內在下行端口鏈路上發送一個warm reset。當接收到一個SetPortFeature(PORT_RESET)請求時，如果端口狀態處於DSPORT.Enabled，而端口鏈路處於除了U3之外的任意狀態，該端口應該在tDSPortResetToHotReset時間內在其鏈路上發起一次hot reset。如果端口接收到一個SetPortFeature(BH_PORT_RESET)請求，端口應該在tDSPortResetToHotReset時間內在其鏈路上發起一個warm reset。
注意：如果端口在其鏈路上發起了一次hot reset，而hot reset的TS1/TS2握手失敗了，就會自動嘗試warm reset。參考Link一章關於這一過程的細節。該端口在這一過程中保持在DSPORT.Resetting狀態，直到warm reset完成。
在warm reset過程中，當下行端口鏈路進入Rx.Detect.Active狀態，集線器應該啓動一個計時器來對處於Rx.Detect.Active狀態計時。如果這個計時器在鏈路處於Rx.Detect.Active狀態超過tTimeForResetError時間，端口應該轉換到DSPORT.Disconnected狀態。
10.3.1.7 DSPORT.Compliance
端口在下面的任意情形下轉換進入本狀態：
- 當鏈路進入Compliance Mode狀態。
10.3.1.8 DSPORT.Loopback
端口在下面的任意情形下轉換進入本狀態：
- 從DSPORT.Training狀態，如果在接收到的TS2有序集（ordered sets）中的loopback bit被設置。
在此狀態，端口的鏈路應該處於Loopback狀態。
10.3.1.9 DSPORT.Disabled
端口在接收到SetPortFeature(PORT_LINK_STATE) SS.Disabled請求後轉換進入本狀態。
在此狀態，端口的鏈路應該處於SS.Disabled狀態。
10.3.2 斷開連接檢測機制 [Disconnect Detect Mechanism]
斷開連接檢測機制在第 7.5 節中被描述。
10.3.3 給端口加標籤 [Labeling]
USB 系統軟件用 ClearPortFeature或SetPortFeature 請求，使用端口編號來引用各個端口。如果一個廠商提供一個標籤來識別各個下行面端口，那麼每個端口連接器應該用與它相應的端口號來標示。被集線器爲特定的端口分配的端口號，應該在 USB 2.0 集線器和 SuperSpeed 集線器控制器之間保持一致。
10.4 集線器下行面端口功耗管理[Hub Downstream Facing Port Power Management]
下面章節提供了一個狀態機的功能描述，該狀態機對於下行面端口顯示了正確的鏈路功耗管理行爲。
圖 10-10 顯示了下行面端口功耗管理狀態機。每一個狀態在第 10.4.2 節描述。在圖 10-10中，一些進入某狀態的進入條件沒有顯示其起始狀態。這些條件有多個起始狀態，並且這些單獨的轉換線沒被顯示，以簡化圖表。對於所進入的狀態的描述會指示從那些狀態轉換而來是可適用的。
10.4.1 下行面端口PM定時器 [Downstream Facing Port PM Timers]
每個下行面端口都維護了邏輯不活動定時器，用於跟蹤何時U1以及U2超時值超時。U1或U2超時值可以隨時被軟件用SetPortFeature(PORT_U1_TIMEOUT) 或 SetPortFeature(PORT_U2_TIMEOUT)命令設置。這些PM定時器每當接收到SetPortFeature(PORT_U1_TIMEOUT) 或 SetPortFeature(PORT_U2_TIMEOUT)請求時被複位到0。每當除了等時時間戳包之外的任意包被端口的鏈路發送或者接收到時，這些定時器都應該被複位。U1定時器應該有+1/- 0 μs的精確度。U2定時器應該有+500/-0 μs的精確度。其他的對於定時器的要求在下行端口的PM狀態機的描述中被定義。
10.4.2 集線器下行面端口狀態機描述 [Hub Downstream Facing Port State Descriptions]
10.4.2.1 Enabled U0 狀態 [Enabled U0 States]
有4個enabled U0狀態，他們只在被配置的 U1 和 U2 超時值方面有不同。針對不同的U1 和 U2 超時值的端口行爲如下：
U1_TIMEOUT = 0, U2_TIMEOUT = 0
- 這是集線器在接收到任何SetPortFeature(PORT_U1/U2_TIMEOUT)之前端口的默認狀態。
- 端口的鏈路應該拒絕鏈路對方發起的所有到U1 或 U2 的轉換請求。
- PM定時器可以被禁止，並且PM定時器值應該被忽略。
- 端口的鏈路不應該嘗試發起到U1 或 U2 的轉換。
U1_TIMEOUT = X > 0, U2_TIMEOUT = 0
- 端口的鏈路應該拒絕鏈路對方發起的所有到U2的轉換請求。
- 當進入並且活躍在本狀態時，PM定時器應該被複位。
- 端口的鏈路應該接受鏈路對方發起的到U1的轉換請求，除非集線器還有一個或者多個包/鏈路命令要在該端口上傳送。
- 如果U1超時值是0xFF，端口應該被禁止發起進入U1，但是應該接受鏈路對方發起的到U1的轉換請求，除非集線器還有一個或者多個包/鏈路命令要在該端口上傳送。
- 如果U1超時值不是0xFF，並且U1定時器達到了X，端口的鏈路應該發起一次到U1的轉換。
U1_TIMEOUT = 0, U2_TIMEOUT = Y > 0
- 端口的鏈路應該拒絕鏈路對方發起的所有到U1的轉換請求。
- 當進入並且活躍在本狀態時，PM定時器應該被複位。
- 端口的鏈路應該接受鏈路對方發起的到U2的轉換請求，除非集線器還有一個或者多個包/鏈路命令要在該端口上傳送。
- 如果U2超時值是0xFF，端口應該被禁止發起進入U2，但是應該接受鏈路對方發起的到U2的轉換請求，除非集線器還有一個或者多個包/鏈路命令要在該端口上傳送。
- 如果U2超時值不是0xFF，並且U2定時器達到了Y，端口的鏈路應該發起一次從U0到U2的直接轉換。在這種情形下，PORT_U2_TIMEOUT代表在U0狀態的不活動時間長度。
U1_TIMEOUT =X > 0, U2_TIMEOUT = Y > 0
- 當進入並且活躍在本狀態時，PM定時器應該被複位。
- 端口的鏈路應該接受鏈路對方發起的到U1或者U2的轉換請求，除非集線器還有一個或者多個包/鏈路命令要在該端口上傳送。
- 如果U1超時值是0xFF，端口應該被禁止發起進入U1，但是應該接受鏈路對方發起的到U1的轉換請求，除非集線器還有一個或者多個包/鏈路命令要在該端口上傳送。
- 如果U1超時值不是0xFF，並且U1定時器達到了X，端口的鏈路應該發起一次到U1的轉換。
- 如果U2超時值是0xFF，端口應該被禁止發起進入U2，但是應該接受鏈路對方發起的到U2的轉換請求，除非集線器還有一個或者多個包/鏈路命令要在該端口上傳送。
在下列任意情形下，端口就會轉換到其中一個Enabled U0狀態（依賴於U1和U2超時值）：
- 從任意狀態，如果集線器接收到了SetPortFeature(PORT_LINK_STATE) U0請求。
- 從U1狀態，如果鏈路對方成功發起了一次到U0的轉換。
- 從U2狀態，如果鏈路對方成功發起了一次到U0的轉換。
- 從U1狀態，如果集線器在接收到一個路由到該端口的包之後，成功發起了一次到U0的轉換。
- 從U2狀態，如果集線器在接收到一個路由到該端口的包之後，成功發起了一次到U0的轉換。
- 從一次想要從U0狀態轉換到U1狀態的嘗試，如果下行端口的鏈路對方拒絕這一轉換請求。
- 從一次想要從U0狀態轉換到U2狀態的嘗試，如果下行端口的鏈路對方拒絕這一轉換請求。
- 從U3狀態，如果集線器的上行端口接收到了wakeup信號，並且正在被轉換的集線器下行端口在U3的時候已經接收到了wakeup信號。
- 從U3狀態，如果集線器下行端口的鏈路對方發起了wake信號，而上行集線器的端口鏈路不處於U3。
注意：參考10.1.4節中下行口鏈路對方發起remote wakeup信號情形的細節。
10.4.2.2 嘗試 U0到U1轉換 [Attempt U0 – U1 Transition]
在本狀態，端口嘗試將其鏈路從U0狀態轉換到U1狀態。
在下列任意情形，端口應該嘗試轉換到U1狀態：
- U1定時器達到了U1超時值。
- 集線器接收到一個SetPortFeature(PORT_LINK_STATE) U1請求。
- 下行端口的鏈路對方發起了一次U0到U1的轉換。
如果轉換嘗試失敗，端口返回到恰當的enabled U0狀態。然而，如果本狀態是由於一個SetPortFeature請求而進入的，端口會繼續在其鏈路上的從U0到U1轉換的嘗試。
注意：SetPortFeature請求典型的只被用來在測試目的下進入U1。
10.4.2.3 Attempt U0 – U2 Transition
在本狀態，端口嘗試將其鏈路從U0狀態轉換到U2狀態。
在下列任意情形，端口應該嘗試轉換到U2狀態：
- U2定時器達到了U2超時值。
- 集線器接收到一個SetPortFeature(PORT_LINK_STATE) U2請求。
- 下行端口的鏈路對方發起了一次U0到U2的轉換。
如果轉換嘗試失敗，端口返回到恰當的enabled U0狀態。然而，如果本狀態是由於一個SetPortFeature請求而進入的，端口會繼續在其鏈路上的從U0到U2轉換的嘗試。
注意：SetPortFeature請求典型的只被用來在測試目的下進入U2。
10.4.2.4 U1狀態的鏈路 [Link in U1]
每當一個下行口進入U1，並且所有的下行口現在都處於U1狀態或者更低的功耗狀態，如果集線器的上行端口對於U1是使能的（enabled for U1），集線器應該在tHubPort2PortExitLat時間內，在其上行端口上發起一次到U1的轉換。
當鏈路進入U1時，U2定時器被複位到0並被啓動。
如果U2超時值不是0xFF，並且U2定時器達到了Y，端口的鏈路應該發起一次從U1到U2的直接轉換。在這種情形下，PORT_U2_TIMEOUT代表在U1狀態的不活動時間長度。
每當一個下行端口或者其鏈路對方發起一次從U1到其中一個Enabled U0狀態的轉換，但是上行端口不處於U0狀態，集線器都應該從這個轉換在下行端口被啓動之後的tHubPort2PortExitLat時間內，在上行端口上發起一次到U0的轉換。如果上行端口已經在U0狀態，當下行端口轉換到U0時，它應該保持在U0狀態。
10.4.2.5 U2狀態的鏈路 [Link in U2]
當下行端口進入 U2 時，適用於下列各項規則:
- 如果所有的下行端口現在處於U2或者更低的功耗狀態，如果上行端口對U2是使能的（enabled for U2），集線器應該在tHubPort2PortExitLat時間內，在上行端口上發起到U2的轉換。如果U2在上行端口上不被使能，但是U1是被使能的，集線器應該在相同的時序要求下發起到U1的一次轉換。
- 如果所有的下行端口現在處於U1或者更低的功耗狀態，如果上行端口對U1是使能的（enabled for U1），集線器應該在tHubPort2PortExitLat時間內，在上行端口上發起到U1的轉換。
每當一個下行端口或它的鏈路對方發起從U2到其中一個Enabled U0狀態的轉換而集線器上行端口不處於U0時:
- 如果集線器的上行端口鏈路處於U2，從這個轉換在下行端口被啓動之後的tHubPort2PortExitLat時間內，集線器應該在上行端口的鏈路上發起一次到U0的轉換。
- 如果集線器的上行端口鏈路處於U1，從這個轉換在下行端口被啓動之後的tHubPort2PortExitLat + U2DevExitLat-U1DevExitLat時間內，集線器應該在上行端口的鏈路上發起一次到U0的轉換。
10.4.2.6 U3狀態的鏈路 [Link in U3]
當下行端口進入U3時，適用於下列各項規則:
- 如果所有的下行端口現在處於U2或者U3, 集線器應該在上行端口上，在tHubPort2PortExitLat時間內，發起到U3以上被使能的最低功耗狀態的一次轉換。
- 如果所有的下行端口現在處於U1或者更低的功耗狀態，如果上行端口對U1是使能的（enabled for U1），集線器應該在tHubPort2PortExitLat時間內，在上行端口上發起到U1的轉換。
參考10.3.1.5節關於從Enabled U0狀態只轉換到U3狀態的詳細描述。
注意：如果集線器的上行端口接收到一個被路由到一個處於U3的下行端口的包, 這個包會被默默地丟棄。在這情況下，集線器將執行正常的鏈路層級頭包的確認。
10.5 Hub Upstream Facing Port
下面章節提供了一個狀態機的功能描述，該狀態機對於集線器上行面端口顯示了正確的行爲。這些章節也適用於設備的上行面端口，除非在不適用處將做出特別的說明。上行口應該只嘗試如後續節中所描述的上行端口狀態機那樣來連接到SuperSpeed以及USB 2.0接口。
圖 10-11 顯示了上行面端口狀態機。每一個狀態在第 10.5.1 節描述。在圖10-11中，一些進入某狀態的進入條件沒有顯示起始狀態。這些條件有多個起始狀態，並且這些單獨的轉換線沒被顯示，以簡化圖表。對於所進入的狀態的描述會指示從那些狀態轉換而來是可適用的。
10.5.1 上行面端口狀態描述 [Upstream Facing Port State Descriptions]
10.5.1.1 USPORT.Powered-off
USPORT.Powered-off 狀態是上行面端口的默認狀態。
下列任意情形發生，端口應該轉換進入本狀態：
- 從任意狀態，當VBUS被移除。
- 從任意狀態，如果遠端接收器中斷阻抗（far-end receiver terminations）沒有被檢測到。
- 從USPORT.Connected狀態，如果Port Configuration過程失敗。
在本狀態，斷口的鏈路應該處於SS.Disabled狀態。
10.5.1.2 USPORT.Powered-on
端口在下面的任意情形下轉換進入本狀態：
- 從USPORT.Powered-off 狀態，當VBUS變得有效。
- 從USPORT.Error 狀態，當鏈路接收到一個warm reset。
- 從USPORT.Connected 狀態，當鏈路接收到任意的reset。
- 從USPORT.Enabled 狀態，當鏈路接收到任意的reset。
- 從USPORT.Training狀態，如果端口的鏈路從Polling substate 狀態超時。
在本狀態，端口的鏈路應該處於Rx.Detect狀態。當在本狀態中，如果集線器的USB 2.0部分進入了suspended狀態，集線器從VBUS抽取的總電流應該滿足suspend電流限制。
10.5.1.3 USPORT.Training
當SuperSpeed遠端接收器中斷阻抗（far-end receiver terminations）被檢測到時，端口從USPORT.Powered-on狀態轉換進入本狀態。
在本狀態，端口的鏈路應該處於Polling狀態。
10.5.1.4 USPORT.Connected
當端口的鏈路從Polling.Idle狀態進入U0狀態時，端口從USPORT.Training狀態轉換進入本狀態。 在本狀態，端口的鏈路應該處於U0 或 Recovery狀態。
當鏈路進入U0狀態，端口開始8.4.5節定義的端口配置過程。
當處於USPORT.Connected狀態時，端口可以發送鏈路管理包或鏈路命令，但是不應該傳送除了響應默認的控制端點請求之外任意其他的包。
10.5.1.5 USPORT.Error
當嘗試操作鏈路，發生嚴重的錯誤情形時，端口轉換進入本狀態。端口在如下任意情形下，轉換進入本狀態：
- 從USPORT.Connected 狀態，如果鏈路進入Recovery但是還沒有恢復就已經超時。
- 從USPORT.Enabled 狀態，如果鏈路進入Recovery但是還沒有恢復就已經超時。
在本狀態，端口的鏈路應該處於SS.Inactive狀態。
端口只有在鏈路上接收到Warm Reset後才退出Error狀態。
10.5.1.6 USPORT.Enabled
當Set Address請求被接收到，並且Set Address的狀態階段的ACK TP響應已經被髮送並被在鏈路層級成功確認時，端口從USPORT.Connected狀態轉換進入本狀態。
在本狀態，端口的鏈路應該處於U0, U1, U2, U3, 或者Recovery狀態。
當在USPORT.Enabled狀態，端口可以發送任意類型的包。
當進入USPORT.Enabled狀態時，鏈路應該處於U0狀態。
10.5.2 集線器連接狀態機 [Hub Connect State Machine]
下面的章節提供了一個狀態機的功能性描述，展示了當連接到SuperSpeed或USB 2.0時正確的集線器行爲。對於集線器而言，SuperSpeed 和 USB 2.0的連接邏輯是完全獨立的。對於USB 2.0上的連接，集線器應該依照USB 2.0規範。圖10-12是SuperSpeed的集線器連接狀態機。10.5.2.1節描述每一個狀態。
10.5.2.1 集線器連接狀態描述 [Hub Connect State Descriptions]
10.5.2.2 HCONNECT.Powered-off
HCONNECT.Powered-off狀態是集線器設備的默認狀態。如果發生了下列情形，集線器設備應該轉換進入本狀態：
- 從任意狀態，當VBUS被移除。
In this state, the hub upstream port's link shall be in the SS.Disabled state.
在本狀態，集線器上行端口應該處於SS.Disabled狀態。
10.5.2.3 HCONNECT.Attempt SS Connect
如果發生了下列任意情形，集線器設備應該轉換進入本狀態：
- 從HCONNECT.Powered-off 狀態，當VBUS 變得有效 (並且如果必要，本地電源有效)。
- 從HCONNECT.Connected on SS狀態，如果Rx.Detect 或者Link Training超時。
在本狀態，集線器上行端口SuperSpeed鏈路應該處於Rx.Detect 或 Polling狀態。
10.5.2.4 HCONNECT.Connected on SS
如果發生了下列情形，集線器設備應該轉換進入本狀態：
- 從PCONNECT.Attempt SS Connect狀態，當鏈路從polling轉換到U0。
在本狀態，集線器上行端口SuperSpeed鏈路處於U0, U1, U2, U3, Inactive, Rx.Detect, Recovery, 或者Polling狀態。
10.6 上行面端口功耗管理 [Upstream Facing Port Power Management]
下面章節提供了一個狀態機的功能描述，該狀態機對於上行面端口顯示了正確的鏈路功耗管理行爲。
圖 10-13 顯示了上行面端口功耗管理狀態機。每一個狀態在第 10.4.2 節描述。在圖 10-13中，一些進入某狀態的進入條件沒有顯示其起始狀態。這些條件有多個起始狀態，並且這些單獨的轉換線沒被顯示，以簡化圖表。對於所進入的狀態的描述會指示從那些狀態轉換而來是可適用的。
如果在任何下行端口有狀態改變，如果上行端口處於U1或U2的話，集線器應該在上行端口的鏈路上發起一次到U0的轉換。
如果在任何下行端口有狀態改變，並且集線器上行口處於U3狀態，集線器的行爲由當前的遠程喚醒掩碼設置（remote wakeup mask settings）來指定。參考10.14.2.10節中更多的細節。
10.6.1 上行面端口PM定時器 [Upstream Facing Port PM Timer]
集線器上行口維護了一個邏輯PM定時器，用來跟蹤何時U2不活動超時值被超過了。沒有定義標準的U1不活動超時值。U2不活動超時值在接收到U2 Inactivity Timeout LMP時被設置。當集線器上行端口鏈路進入U1時，該PM定時器被複位。該PM定時器應該有+500/-0 μs的精確度。其他的對於該定時器的要求在上行口的PM狀態機的描述中被定義。
10.6.2 集線器上行面端口狀態機 【Hub Upstream Facing Port State Descriptions】
10.6.2.1 Enabled U0 狀態【Enabled U0 States】
有4種enabled U0狀態，他們只在U1 以及 U2 Enable設置方面有所不同。下面的規則對於所有的enabled U0狀態全局適用。
- 如果還有包需要在上行端口上傳輸，則上行端口不能發起到U1 或 U2的轉換。
- 如果Force_LinkPM_Accept比特被設置爲1 (參考8.4.2節)，那麼上行端口應該接受到U1 或 U2的轉換。
對於U1 以及 U2 Enable值的不同組合，端口的行爲如下：
U1_ENABLE = 0, U2_ENABLE = 0
- 這是集線器在接收到任意的SetFeature(U1/U2_ENABLE)請求之前的默認狀態。
- PM定時器可以被禁止，並且PM定時器值應該被忽略。
- 端口的鏈路應該接受其鏈路對方的U1進入請求，除非集線器已經有一個或者多個包或者鏈路命令要在該端口上發送，或者該集線器的一個或者多個下行端口的鏈路處於U0或者恢復狀態。
- 端口的鏈路應該接受其鏈路對方的U2進入請求，除非集線器已經有一個或者多個包或者鏈路命令要在該端口上發送，或者該集線器的一個或者多個下行端口的鏈路處於U0，U1或者恢復狀態。
- 端口的鏈路不應該嘗試發起到U1或者U2的轉換。
U1_ENABLE = 1, U2_ENABLE = 0
- 端口的鏈路不應該嘗試發起到U2的轉換。
- 端口的鏈路應該接受其鏈路對方的U2進入請求，除非集線器已經有一個或者多個包或者鏈路命令要在該端口上發送，或者該集線器的一個或者多個下行端口的鏈路處於U0，U1或者恢復狀態。
- 端口的鏈路應該接受其鏈路對方的U1進入請求，除非集線器已經有一個或者多個包或者鏈路命令要在該端口上發送，或者該集線器的一個或者多個下行端口的鏈路處於U0或者恢復狀態。
- PM定時器可以被禁止，並且PM定時器值應該被忽略。
- 如果集線器所有的下行端口都處於U1或者更低功耗的鏈路狀態，端口的鏈路應該發起到U1的轉換。
U1_ENABLE = 0, U2_ENABLE = 1
- 端口的鏈路不應該嘗試發起到U1的轉換。
- 端口的鏈路應該接受其鏈路對方的U1進入請求，除非集線器已經有一個或者多個包或者鏈路命令要在該端口上發送，或者該集線器的一個或者多個下行端口的鏈路處於U0或者恢復狀態。
- 端口的鏈路應該接受其鏈路對方的U2進入請求，除非集線器已經有一個或者多個包或者鏈路命令要在該端口上發送，或者該集線器的一個或者多個下行端口的鏈路處於U0，U1或者恢復狀態。
- PM定時器可以被禁止，並且PM定時器值應該被忽略。
- 如果集線器所有的下行端口都處於U2或者更低功耗的鏈路狀態，端口的鏈路應該發起到U2的轉換。
U1_ENABLE = 1, U2_ENABLE = 1
- 端口的鏈路應該接受其鏈路對方的U1或者U2的進入請求，除非集線器已經有一個或者多個包或者鏈路命令要在該端口上發送。
- 如果該集線器的一個或者多個下行端口的鏈路處於U0或者恢復狀態，U1進入請求不應該被接受。
- 如果該集線器的一個或者多個下行端口的鏈路處於U1或者恢復狀態，U2進入請求不應該被接受。
- 如果集線器所有的下行端口都處於U1或者更低功耗的鏈路狀態，端口的鏈路應該發起到U1的轉換。
- PM定時器可以被禁止，並且PM定時器值應該被忽略。
端口在如下任一情形下，就會轉換進入其中一個Enabled U0狀態（依賴於U1或者U2 Enable值而定）：
- 從U1，如果鏈路對方成功發起了一次到U0的轉換。
- 從U2，如果鏈路對方成功發起了一次到U0的轉換。
- 從U1，如果在一個下行端口上有狀態改變。
- 從U2，如果在一個下行端口上有狀態改變。
- 從U1，如果集線器下行端口的鏈路發起了一次到U0的轉換。
- 從U2，如果集線器下行端口的鏈路發起了一次到U0的轉換。
- 從一次想要從U0轉換到U1的嘗試，如果上行端口鏈路對方拒絕該次轉換嘗試。
- 從一次想要從U0轉換到U2的嘗試，如果上行端口鏈路對方拒絕該次轉換嘗試。
- 從U3，如果集線器上行口接收到了wakeup信號。
- 從U3，如果在一個下行端口上有狀態改變，或者本地電源狀態改變，並且相應於該事件類型的遠程喚醒（remote wakeup）被使能。
10.6.2.2 嘗試U0-U1轉換 【Attempt U0 – U1 Transition】
在本狀態，端口嘗試將其鏈路從U0狀態轉換到U1狀態。
在如下任一情形下，端口應該嘗試轉換到U1狀態：
- 被鏈路對方請求進入U1，並且在該端口上沒有未完成事務交易，並且集線器所有的下行端口都處於U1或者更低的功耗狀態。
- 集線器所有的下行端口都處於U1或者更低的功耗狀態，並且在上行端口上沒有等待傳輸的事務交易，並且U1_ENABLE被設置爲1。
- 被鏈路對方請求進入U1，並且Force_LinkPM_Accept比特被設置。
如果轉換嘗試失敗（接收到一個LXU或者鏈路進入恢復狀態），端口將返回到恰當的enabled U0狀態。
10.6.2.3 嘗試U0-U1轉換 【Attempt U0 – U2 Transition】
在本狀態，端口嘗試將其鏈路從U0狀態轉換到U2狀態。
在如下任一情形下，端口應該嘗試轉換到U2狀態：
- 被鏈路對方請求進入U2，並且在該端口上沒有未完成事務交易，並且集線器所有的下行端口都處於U2或者更低的功耗狀態。
- 集線器所有的下行端口都處於U2或者更低的功耗狀態，並且在上行端口上沒有等待傳輸的事務交易，並且U2_ENABLE被設置爲1。
- 被鏈路對方請求進入U2，並且Force_LinkPM_Accept比特被設置。
如果轉換嘗試失敗（接收到一個LXU或者鏈路進入恢復狀態），端口將返回到恰當的enabled U0狀態。
10.6.2.4 處於U1的鏈路 【Link in U1】
當進入並活動於本狀態時，PM定時器被複位。
端口應該轉換進入U1：
- 當發送一個LAU，接受一個由鏈路對方發起的轉換之後。
- 當在發起一次轉換該鏈路進入U1的嘗試後，從鏈路對方接收到一個LAU之後。
如果U2不活動計時器超時值不是0xFF 或者 0x00，並且PM定時器達到U2不活動計時器超時值，端口鏈路應該發起一次從U1到U2的轉換。
10.6.2.5 處於U2的鏈路 【Link in U2】
鏈路處於U2。
端口應該轉換進入U2：
- 當發送一個LAU，接受一個由鏈路對方發起的轉換之後。
- 當在發起一次轉換該鏈路進入U2的嘗試後，從鏈路對方接收到一個LAU之後。
10.6.2.6處於U3的鏈路 【Link in U3】
鏈路處於U3。
端口應該轉換進入U3：
- 當發送一個LAU，接受一個由鏈路對方發起的轉換之後。
10.7 集線器頭包轉發和數據中繼器【Hub Header Packet Forwarding and Data Repeater】
集線器對頭包使用存儲轉發模型，對數據使用中繼器模型，聯合提供瞭如下的總體功能性：
在下行方向上：
- 驗證頭包
- 建立起到選擇的下行端口的連接
- 轉發頭包到下行端口
- 轉發數據負載到下行端口，如果有的話
- 在包邊界處建立和斷開連接性
在上行方向上：
- 驗證頭包
- 建立起到上行端口的連接
- 轉發頭包到上行端口
- 轉發數據負載到上行端口，如果有的話
- 在包邊界處建立和斷開連接性
10.7.1 集線器彈性緩衝區 【Hub Elasticity Buffer】
沒有對集線器內部的彈性緩衝區進行直接的規定。但是，注意，集線器必須滿足10.7.3小節對於頭包從集線器上行端口轉發到下行端口的最大可變傳導時延的要求。
10.7.2 SKP有序集 【SKP Ordered Sets】
對於所有的傳輸，集線器都需要按照第7章中對於所有的發送器的規則，發送SKP有序集。
10.7.3 包間距 【Interpacket Spacing】
當集線器源發或者轉發包時，數據包頭以及數據包負載應該如7.1.1.2.3小節那樣，被始終連續地發送。
當集線器轉發頭包到下行，並且當該頭包在集線器上行端口被接收到時，下行端口的鏈路處於U0，那麼傳導時延的變數不應該超過tPropagationDelayJitterLimit。
10.7.4 頭包緩衝區結構 【Header Packet Buffer Architecture】
本規範不要求集線器內部的頭包緩衝區的特定結構。滿足本規範的功能性要求的結構實例被顯示在圖10-14和圖10-15中，示例了集線器的功能性行爲。圖10-14顯示了一個集線器，在上行端口上擁有4個頭包Rx緩衝，在每個下行端口上有4個頭包Tx緩衝。圖10-15顯示了每個下行端口上有4個頭包Rx緩衝，並且在上行端口上擁有4個頭包Tx緩衝。在圖10-14和圖10-15中顯示的緩衝區都是獨立的物理緩衝區。
下面列出集線器緩衝區結構的功能性要求，在每種情況下，都假設只有集線器上被指示的端口在接收或者發送頭包：
- 以所有的頭包緩衝區都清空開始的集線器，在其上行端口的頭包流量控制信用值（flow control credits）用完之前，至少應該能夠接收8個定向到同一個不處於U0狀態的下行端口的頭包。
- 在其上行端口上接收到一個應該被路由到一個下行端口的頭包的集線器，應該立刻將該頭包路由到適當者的下行端口頭包緩衝區（如果該緩衝區的空間可用），不管任何其他下行端口頭包緩衝區的狀態如何，也不管上行端口Rx頭包緩衝區狀態如何。舉例來說，一個集線器的下行端口1的Tx頭包緩衝區是滿的，而且集線器上行Rx頭包緩衝區有另外三個頭包要被路由下行端口1。如果該集線器現在接收到一個頭包要被路由到下行端口2, 它必須立刻路由該頭包到該下行端口2的Tx頭包緩衝區。
- 以所有的頭包緩衝區都清空開始的集線器，在上行端口不處於U0狀態時，至少應該能夠接收同一下行端口上的8個頭包，定向用於向上行傳輸。
- 被下行端口傳輸的頭包應該以它們在上行端口上被收到的順序傳輸。
- 從相同的下行端口上來的，被上行端口傳輸的頭包，應該以它們在從該下行端口上被收到的順序傳輸。
第 10.7.6,10.7.8,10.7.10 和 10.7.12節提供詳細的功能性狀態機，描述一個集線器實現中的上行和下行端口的Tx和Rx頭包緩衝區。
10.7.5 上行面端口Tx 【Upstream Facing Port Tx】
本節描述上行面端口Tx狀態機的功能性需求。
10.7.6 上行面端口狀態描述 【Upstream Facing Port Tx State Descriptions】
一個上行端口應該維持一個已傳送符號的計數。
10.7.6.1 Tx IDLE
在Tx IDLE狀態, 上行端口發送器在積極傳送idle符號。端口應該在如下任一情形下轉換進入Tx IDLE狀態：
- 從Tx Data, Tx Data Abort, 或 Tx Header 狀態，在任何必要的SKP有序集被傳送之後。
- 從Tx Link Command 狀態， 在傳送一個鏈路命令並且沒有其他的鏈路命令正等待傳送之後。
- 作爲進入U0時的默認狀態。
發送器應該在必要時如第 7 章所描述那樣傳送LUP。
當傳送的符號計數達到 nSkipSymbolLimit 的時候， 一個SKP有序集應該被傳送，並且已傳送符號計數應該被複位歸零。
10.7.6.2 Tx Header
在 Tx Header 狀態中，上行端口發送器正在積極地傳送一個頭包。
注意：集線器不應該用 DPPABORT 有序集中止（abort）頭包的傳輸。
在如下任一情形下，端口應該轉換到Tx Header狀態：
- 從Tx IDLE狀態，當有一個或者多個頭包被排隊準備傳輸，但是沒有鏈路命令被被排隊準備傳輸時。
在傳送任何頭包的結尾（除了具有數據包負載的數據包頭包以外），當已傳送符號計數超過或等於nSkipSymbolLimit，一個SKP有序集應該被傳輸，而且已傳送符號計數應該被減少nSkipSymbolLimit個。
10.7.6.3 Tx Data
在 Tx Data 狀態中，上行端口發送器正在積極地傳送一個數據包負載。在傳送數據包負載的最後的分幀符號以及必要的SKP有序集之後，端口可以將數據負載包從集線器的儲存緩衝中移除。在任何的境況之下，集線器都不應該重傳DPP包。
當有數據包負載與被傳輸了的數據包頭相關聯時，端口應該從Tx Header狀態轉換到Tx Data狀態。數據包負載量傳輸應該在傳輸數據包頭的最後一個符號之後立刻開始。
在傳送沒被中止（aborted）的數據包負載結束的時候：
- 當已傳送符號計數超過或者等於nSkipSymbolLimit時，一個SKP有序集應該被傳輸，並且已傳送符號計數應該被減少nSkipSymbolLimit個。
- 該序列被重複，直到符號計數少於nSkipSymbolLimit。
10.7.6.4 Tx Data Abort
在Tx Data abort狀態，上行端口發送器藉由傳送DPPABORT有序集以及必要的SKP有序集，中止數據包負載的正常傳輸。然後，端口從集線器儲存中移除數據包負載。
當接收數據包負載的下行端口接收到DPPABORT有序集的時候，或者已經接收到sDataSymbolsBabble個符號而沒有接收到有效的DPPEND有序集或DPPABORT有序集的時候，端口應該從Tx Data狀態轉換到Tx Data Abort狀態。
在傳送DPPABORT有序集結束的時候：
- 當已傳送符號計數超過或者等於nSkipSymbolLimit時，一個SKP有序集應該被傳輸，並且已傳送符號計數應該被減少nSkipSymbolLimit個。
- 該序列被重複，直到符號計數少於nSkipSymbolLimit。
10.7.6.5 Tx Link Command
在Tx Link Command狀態中，上行端口發送器正在積極地傳送一個鏈路命令。如果多個鏈路命令要在Tx Link Command狀態被排隊傳輸，他們應該無間隙地被傳輸，除非SKP有序集被傳輸。
在下列的任一情形下，端口應該轉換到Tx Link Command狀態：
- 從Tx IDLE狀態，當有一個或多個鏈路命令被排隊準備傳輸時候。
- 從Tx Link Command狀態，當有另外的鏈路命令被排隊準備傳輸的時候。
在傳送任何的鏈路命令結束的時候，若已傳送符號計數超過或者等於nSkipSymbolLimit，一個SKP有序集應該被傳輸，並且已傳送符號計數應該被減少nSkipSymbolLimit個。
10.7.7 上行面端口Rx 【Upstream Facing Port Rx】
這一個節描述上行面端口Rx狀態機的功能性需求。
10.7.8 上行面端口Rx狀態描述 【Upstream Facing Port Rx State Descriptions】
10.7.8.1 Rx Default
在Rx Default狀態中，上行端口接收器正在積極地處理已接收到的符號，並尋找DPPSTART有序集， HPSTART有序集，或LCSTART有序集的分幀符號，來開始接收一個包或鏈路命令。
如果DPPStart有序集被收到，但是其不緊隨一個DPH，它就會被忽略，而且端口接收器停留在RX.Default狀態。
在下列任何情形下，一個端口應該轉換到Rx Default狀態：
- 從Rx Data狀態，當DPPEND有序集或者DPPABORT有序集被接收到時。
- 從Rx Header狀態，當一個頭包的最後一個符號被收到時。
- 從Rx Data狀態，當達到sDataSymbolsBabble，都沒有收到一個DPPEND有序集或者DPPABORT有序集。
- 在接收到一個鏈路命令之後。
- 作爲鏈路進入U0之後的默認狀態。
10.7.8.2 Rx Data
在Rx Data狀態中，上行端口接收器正在積極地處理已經接收到的符號，並尋找DPPEND有序集或 DPPABORT有序集。當進入本狀態的時候，接收器應該從零開始對已經接收到的符號進行計數。被計算的第一個符號是DPPSTART有序集後的第一個符號。
當端口接收到有效的DPPSTART有序集的時候，它應該轉換到Rx Data狀態。當在如第 7.2.4.1.6 節所定義的DPP結束之前，端口檢測到一個錯誤的時候，只有在它已經在適當的下行端口上傳輸完已經接收到的 DPP（包括DPPABORT有序集）之後，它纔可能清除它的緩衝區中的數據。當一個錯誤被檢測到的時候，集線器應該在傳送數據包負載錯誤（被跟隨一個DPPABORT有序集）前，在適當的下行端口上傳送有效的已經接收到的符號。注意，即使集線器在下行端口上開始傳送DPP之前，集線器檢測到一個錯誤，這一個要求也適用。
集線器應該有至少1080字節緩衝區用於在上行端口上接收到的數據包。
10.7.8.3 Rx Header
在Rx header狀態中，上行端口接收器正在積極地處理已經接收到的符號,直到最後一個頭包符號被接收到。當進入這狀態的時候,接收器應該從零開始一個對已經接收到符號的計數。被計算的第一個符號是HPSTART有序集後的第一個符號。
當端口接收到有效的HPSTART有序集的時候，它應該轉換到Rx Header狀態。端口應該在頭包的最後一個符號被接收到之後的四個符號時間內，完成驗證CRC-16，鏈路控制字CRC-5，並且檢查路由字串和頭包類型。
實現者可能必須要在接收到符號時就開始CRC計算，在頭包被驗證之前就開始檢查路由字串，來滿足這一要求。
10.7.8.4 處理頭包 【Process Header Packet】
當一個頭包的最後一個符號被接收到的時候,端口應該對該頭包執行所有必要附加處理。任何的此類處理都不應該阻礙端口立刻返回到Rx Default狀態，並繼續處理已經接收到的符號。
在如下任一情形下，端口要對頭包執行附加的處理。附加的處理步驟被描述在每種情形中。
- 當最後一個頭包符號在Rx Header狀態被接收到，並且頭包CRC-16以及鏈路控制字CRC-5被判定有效的時候，適當的LGOOD_n鏈路命令就會被該接收端口排隊準備傳輸。然後，如果上行端口 Rx 頭包緩衝區至少有四空閒的槽位（slots），適當的 LCRD_x 鏈路命令應該被上行端口排隊準備傳輸。否則，一旦用於該頭包的Rx頭包緩衝區槽位可用，這個適當的 LCRD_x 鏈路命令就會被排隊準備傳輸。
注意：一個集線器實現可以在一個Rx頭包緩衝區中選擇提供超過四個儲存槽位。
— 如果頭包被路由到不處於U0的下行端口 (而且頭包不是ITP）：
1. 集線器在對應的下行端口的鏈路上發起U0進入請求。U0進入請求應該在集線器接收到該頭包的路由字串(Route String)後tDownLinkStateChange時間內被髮起。
2. 頭包被標記爲deferred（如果它尚未被標記爲deferred），並對該已被修改的頭包，重新計算正確的鏈路控制字CRC-5。
5. 如果頭包是一個數據包頭（data packet header），對應的數據包負載被丟棄（discarded）。
注意：如果適當的下行端口的隊列已滿，一旦在該適當的下行端口的對列上有一個空間可用，頭包就被排隊上去。當一個下行端口隊列已滿的時候，集線器應該繼續正常處理後續的頭包，如果他們指向一個不同的下行端口的話。
注意：如果適當的下行端口的隊列已滿，一旦在該適當的下行端口的對列上有一個空間可用，頭包就被排隊上去。當一個下行端口隊列已滿的時候，集線器應該繼續正常處理後續的頭包，如果他們指向一個不同的下行端口的話。
注意：所有的後續的頭包都被默默地丟棄，直到對無效的頭包的重試被接收到。
10.7.8.5 Rx Link Command
在Rx Link Command狀態中，上行端口接收器正在積極地處理已經接收到的符號並且尋找鏈路命令的結尾 （鏈路命令字的第二個實例）。
當端口接收到有效的LCSTART有序集的時候，端口就轉換到Rx Link Command狀態。
10.7.8.6 處理鏈路命令 【Process Link Command】
一旦一個鏈路命令的最後一個符號被接收到，端口應該爲該鏈路命令執行所有必要的附加處理。任何的此類處理不應該阻礙端口立刻返回到Rx Default狀態，並且繼續處理已經接收到的符號。
10.7.9 下行面端口Tx 【Downstream Facing Port Tx】
10.7.10 下行面端口狀態描述 【Downstream Facing Port Tx State Descriptions】
10.7.10.1 Tx IDLE
在Tx IDLE狀態, 下行端口發送器在積極傳送idle符號。端口應該在如下任一情形下轉換進入Tx IDLE狀態：
- 從Tx Data, Tx Data Abort, 或 Tx Header 狀態，在最後的必要的SKP有序集被傳送之後。
- 從Tx Link Command 狀態， 在傳送完成一個鏈路命令並且沒有其他的鏈路命令正等待傳送之後。
- 作爲進入U0時的默認狀態。
當已傳送的符號計數達到 nSkipSymbolLimit 的時候， 一個SKP有序集應該被傳送，並且已傳送符號計數應該被複位歸零。
10.7.10.2 Tx Header
在 Tx Header 狀態中，下行端口發送器正在積極地傳送一個頭包。
注意：集線器不應該用 DPPABORT 有序集中止（abort）頭包的傳輸。
10.7.10.3 Tx Data
當有數據包負載與被傳輸了的數據包頭相關聯時，端口應該從Tx Header狀態轉換到Tx Data狀態。數據包負載量傳輸應該在傳輸數據包頭的最後一個符號之後立刻開始。
- 當已傳送符號計數超過或者等於nSkipSymbolLimit時，一個SKP有序集應該被傳輸，並且已傳送符號計數應該被減少nSkipSymbolLimit個。
- 該序列被重複，直到符號計數少於nSkipSymbolLimit。
10.7.10.4 Tx Data Abort
在Tx Data abort狀態，下行端口發送器藉由傳送DPPABORT有序集以及必要的SKP有序集，中止數據包負載的正常傳輸。然後，端口從集線器儲存中移除數據包負載。
- 當已傳送符號計數超過或者等於nSkipSymbolLimit時，一個SKP有序集應該被傳輸，並且已傳送符號計數應該被減少nSkipSymbolLimit個。
- 該序列被重複，直到符號計數少於nSkipSymbolLimit。
10.7.10.5 Tx Link Command
在Tx Link Command狀態中，下行端口發送器正在積極地傳送一個鏈路命令。如果多個鏈路命令要在Tx Link Command狀態被排隊傳輸，他們應該無間隙地被傳輸，除非SKP有序集被傳輸。
在下列的任一情形下，端口應該轉換到Tx Link Command狀態：
在傳送任何的鏈路命令結束的時候，若已傳送符號計數超過或者等於nSkipSymbolLimit，一個SKP有序集應該被傳輸，並且已傳送符號計數應該被減少nSkipSymbolLimit個。
10.7.11 下行面端口Rx 【Downstream Facing Port Rx】
10.7.12 下行面端口Rx狀態描述 【Downstream Facing Port Rx State Descriptions】
10.7.12.1 Rx Default
在Rx Default狀態中，下行端口接收器正在積極地處理已接收到的符號，並尋找DPPSTART有序集， HPSTART有序集，或LCSTART有序集的分幀符號，來開始接收一個包或鏈路命令。
如果DPPStart有序集被收到，但是其不緊隨於一個DPH，它就會被忽略，而且端口接收器停留在RX.Default狀態。
在下列任何情形下，一個端口應該轉換到Rx Default狀態【譯註：原文此處爲Rx IDLE狀態，應爲筆誤，沒有Rx IDLE狀態！】：
- 從Rx Data狀態，當DPPEND有序集或者DPPABORT有序集被接收到時。
- 從Rx Header狀態，當一個頭包的最後一個符號被收到時。
- 從Rx Data狀態，當達到sDataSymbolsBabble，都沒有收到一個DPPEND有序集或者DPPABORT有序集。
- 在接收到一個鏈路命令之後。
- 作爲鏈路進入U0之後的默認狀態。
10.7.12.2 Rx Data
集線器應該有至少1080字節共享的緩衝區用於在所有的下行端口上接收到的數據包。
10.7.12.3 Rx Header
實現者可能必須要在接收到符號時就開始CRC計算，在頭包被驗證之前就開始檢查路由字串，來滿足這一要求。
10.7.12.4 處理頭包 【Process Header】
當一個頭包的最後一個符號被接收到的時候,端口應該對該頭包執行所有必要附加處理。任何的此類處理都不應該阻礙端口立刻返回到Rx Default狀態，並繼續處理已經接收到的符號。
在如下任一情形下，端口要對頭包執行附加的處理。附加的處理步驟被描述在每種情形中。
注意：這些仲裁要求只在多個下行端口以及該集線器控制器之間適用。對於單個來源（下行端口或集線器控制器），包必須以它們被接收到或生成的順序來傳輸。
2. 如果下行端口Rx頭包緩衝區至少有四個空閒的槽位，適當的LCRD_x鏈路命令在下行端口被排隊準備傳輸。否則，該適當的LCRD_x鏈路命令會在用於頭包的Rx頭包緩衝區槽位可用時，被排隊準備傳輸。
注意：所有的後續頭包默默地被丟棄，直到對於該無效的頭包的重試被接收到。
10.7.12.5 Rx Link Command
在Rx Link Command狀態中，下行端口接收器正在積極地處理已經接收到的符號並且尋找鏈路命令的結尾 （鏈路命令字的第二個實例）。
當端口接收到有效的LCSTART有序集的時候，端口就轉換到Rx Link Command狀態。
10.7.12.6 處理鏈路命令 【Process Link Command】
一旦一個鏈路命令的最後一個符號被接收到，端口應該爲該鏈路命令執行所有必要的附加處理。任何的此類處理不應該阻礙端口立刻返回到Rx.Default狀態，並且繼續處理已經接收到的符號。
10.7.13 SuperSpeed 包連結性 【SuperSpeed Packet Connectivity】
SuperSpeed 集線器的包中繼器/轉發器必須對兩方向上的包進行重加時鐘（reclock）。
重加時鐘（Reclocking）意味着，中繼器從接收到的數據流中取出數據，並使用它自己的本地時鐘接着傳送（retransmits）該數據流。
10.8 掛起以及恢復 【Suspend and Resume】
在集線器的上行面端口上，集線器與SuperSpeed設備遵循相同的掛起要求。
當一個集線器下行端口鏈路處於U3狀態中時，如果集線器接收到來自該下行端口的鏈路對方發來的喚醒信號（wakeup signaling），那麼如下的要求適用於該集線器：
- 如果集線器上行端口鏈路不處於U3狀態，集線器應該在tHubDriveRemoteWakeDownstream內，在接收到喚醒信號的下行鏈路上驅動遠程喚醒信號。
- 如果集線器上行端口鏈路處於U3狀態，集線器應該在tHubPropRemoteWakeUpstream內，在其上行端口上驅動遠程喚醒信號。
10.9 集線器上行口復位行爲 【Hub Upstream Port Reset Behavior】
對一個集線器的復位信號只在下行方向有定義，也就是在集線器的上行面端口。集線器必要的復位信號機制在第 6 章被描述。
處於掛狀態的集線器應該將復位型號的開始解釋爲喚醒事件（wakeup event）；到復位信號結束時，集線器應該是醒的（awake），並且已經完成了它的復位序列（reset sequence）。
在Warm Reset的完成之後，整個集線器返回到默認狀態。
在Hot Reset完成之後，集線器除了上行端口的端口配置信息被保持以外，其餘返回爲默認狀態。
10.10 集線器端口電源控制 【Hub Port Power Control】
對於沒有電源開關的集線器，bPwrOn2PwrGood應該被設置爲0。
10.10.1 多個電源分組 【Multiple Gangs】
如果過流情形發生，並且有電源開關，那麼與過流保護電路相關聯的電源開關都應該被關閉。如果多個過流保護設備與單個電源開關相關聯，那麼當任意一個過流保護電路指示有過流情形時，那個開關都將被關閉。
10.11 集線器控制器 【Hub Controller】
10.11.1 端點組織 【Endpoint Organization】
10.11.2 集線器信息結構和操作 【Hub Information Architecture and Operation】
USB系統軟件使用與狀態改變端點相關聯的中斷管道來檢測集線器和端口狀態的改變。
10.11.3 端口改變信息的處理 【Port Change Information Processing】
10.11.4 Hub and Port Status Change Bitmap
集線器和端口狀態改變Bitmap大小是2字節。集線器只報告集線器實際具有的端口數數量的比特位。USB 3.0集線器可能具有不多於nMaxHubPorts個端口。
在任何時間，只要任意的狀態改變比特位變爲非零，就會返回一個ERDY（如果之間發送過一個NRDY），通知主機集線器和端口狀態改變Bitmap已經改變了。圖10-24顯示了構造集線器和端口改變比特的示例。
10.11.5 過流報告和恢復 【Over-current Reporting and Recovery】
- 主機從集線器獲得過流事件的通知。
- 主機抽取出恰當的集線器或端口改變信息（依賴於改變bitmap中的信息）。
- 主機等待過流狀態比特被清成0.
- 主機對所有端口進行上電週期（例如，對每個端口發送一個SetPortFeature(PORT_POWER)請求）。
- 主機重新枚舉所有被影響到的端口。
10.11.6 枚舉處理 【Enumeration Handling】
當設備被從端口上拔出，端口通過狀態改變端點報告狀態改變。接着，就進入下一個設備連接檢測的過程就緒。
10.12 集線器配置 【Hub Configuration】
表10-2. 集線器電源操作模式總結 【Hub Power Operating Mode Summary】
配置描述符 | 集線器設備狀態 （自供電） | 解釋 | |
MaxPower | bmAttributes (自供電) | ||
0 | 0 | N/A | N/A， 這是一個非法的組合 |
0 | 0 | 0 | N/A，設備只能自供電，但是又沒有本地電源，就不能連接到總線上進行通信 |
0 | 1 | 1 | 只能自供電的設備且本地電源良好。集線器狀態也指示本地電源良好。只要深度限制沒有違例，則集線器功能在隨處都正常。 |
>0 | 0 | N/A | 只能總線供電的集線器。除非被當前拓撲允許，下行面端口可能不能被上電。如果bmAttributes.self-powered是零，集線器狀態報告自供電也是無意義的。 |
>0 | 1 | 0 | 這個集線器可以支持自供電和總線供電操作模式。當前其只是作爲總線供電的集線器可用。 |
> | 0 | 1 | 這個集線器正從總線和本地電源取電。當前作爲一個自供電的集線器可用。 |
配置描述符的MaxPower字段用於向系統報告本配置被選擇時，集線器將要從VBUS吸取的最大電源。連接到集線器的外接設備會單獨地向集線器報告他們的電源需求。
注意：軟件應該確保對於在一個總線供電的集線器上的每一個暴露的下行端口至少有150mA可用。
10.13 描述符 【Descriptors】
集線器描述符源於一般的USB設備框架。集線器描述符描述一集線器設備以及在該集線器上的端口。主機經過集線器默認控制管道訪問集線器描述符。
集線器類定義附加的描述符（參考第10.13.2節)。除此之外，廠商特定的（vendor-specific）描述符在USB設備框架中被允許。集線器支持標準的如第 8 章所定義的USB設備命令。
集線器是唯一的允許同時以高速和SuperSpeed工作的設備。本規範只定義當在SuperSpeed模式操作的時候，集線器應該報告的描述符。
注意，在SuperSpeed和非SuperSpeed兩種模式中，SuperSpeed 集線器應該總是支持GetDescriptor (BOS) (參考第9.6.2節)。
10.13.1 標準集線器類描述符 【Standard Descriptors for Hub Class】
集線器類預先定義了標準的USB描述符的某些字段。其他的字段要麼是依賴於實現，要麼不適用於這一類。
A hub has a device descriptor with a bDeviceProtocol field set to 3 and an interface descriptor with
a bInterfaceProtocol field set to 0.
集線器設備描述符的bDeviceProtocol字段爲3， 並且接口描述符的bInterfaceProtocol字段設爲0.
10.13.2 類特定描述符 【Class-specific Descriptors】
10.13.2.1 集線器描述符 【Hub Descriptor】
偏移（Offset） | 字段（Field） | 寬度（Size） | 描述（Description） |
0 | bDescLength | 1 | 本描述符字節數，包括本字節。（12字節） |
1 | bDescriptorType | 1 | 描述符類型, 值: 2AH，表示 SuperSpeed集線器描述符 |
2 | bNbrPorts | 1 | 本集線器支持的下行端口個數。一個集線器最多能夠支持的端口數是15。 |
3 | wHubCharacteristics | 2 | D1...D0: 邏輯電源開關模式【Logical Power Switching Mode】 00: 分組電源開關【Ganged】（所有端口電源一起）。 01: 單獨的端口電源開關 1X: 保留 D2: 識別複合設備 0: 集線器不是複合設備的一部分 1: 集線器是複合設備的一部分 D4...D3: 過流保護模式【Over-current Protection Mode】 00: 全局過流保護【Global Over-current Protection】。集線器把所有端口吸取的電流之和用來報告，不分別個別端口過流狀態。 01: 個別端口過流保護【Individual Port Over-current Protection】。集線器以各個端口爲基礎報告過流。每個端口都有一個過流狀態。 1X: 沒有過流保護【No Over-current Protection】。這一選項只允許總線供電的沒有實現過流保護的集線器。 D15...D5: 保留。 |
5 | bPwrOn2PwrGood | 1 | 從在端口開始上電序列開始，到電源在端口上良好爲止之間的時間（以2ms爲間隔）。USB系統軟件用這個值決定在開始訪問一個已上電的端口之前需要等待多久。這個值被設置爲0，如果電源開關不被這個集線器支持。 |
6 | bHubContrCurrent | 1 | 當集線器運作在USB 2.0和超高速時，集線器控制器的電子元件的最大電流要求，以aCurrentUnit爲單位表示（即50 = 50 * aCurrentUnit毫安）。請注意，如果使用的編碼是爲USB 2.0 USB規範的2.0集線器，那麼在這一字段的編碼是不同的。一個USB 3.0集線器，當它只是在USB 2.0（非超高速）工作時，電流要求應該在USB 2.0集線器描述符報告。 |
7 | bHubHdrDecLat | 1 | 集線器包頭解碼時延（Hub Packet Header Decode Latency）。 最差情形下，上行鏈路處於U0狀態的集線器解碼向下行流向的TP或者DP包，並且在相關的下行端口發起一次向U0的轉換，所需要的時延。時間從上行端口接收到頭包的最後一個符號開始計算，直到集線器在預想的下行口上啓動LFPS爲止。 |
8 | wHubDelay | 2 | 這個字段定義了當集線器用以轉發包的上行和下行鏈路都處於U0狀態，並且沒有鏈路命令正在發送時，由集線器在其接收的向下行流向的頭包上引入的，以納秒記的平均延遲。時間從上行端口接收到包的最後一個符號開始計算，直到下行口發送該包的第一個分幀符號爲止。 |
10 | DeviceRemovable | 2 | 指示是否端口有一個可移除的設備連接。此字段以字節粒度報告。在一個字節中，如果沒有端口存在於一個給定位置，代表該端口的那個位字段應爲0。位值的定義： 0B -設備是可移除的。 1B -設備是不可移除的。 這是一個對應單獨的集線器端口的位圖： Bit 0: 保留供將來使用 Bit 1: Port 1 Bit 2: Port 2 .... Bit n: Port n (實現相關的，最多可到15個端口) |
10.14 請求 【Requests】
10.14.1 標準請求 【Standard Requests】
集線器具有比在9.2.6節中爲標準設備指定的請求處理時間更緊的限制，因爲他們對於連接到USB上的所有設備的"可使用時間"非常關鍵。最壞情形請求處理時間列於如下（他們適用於標準和集線器類請求）：
由於集線器在總線枚舉中扮演瞭如此重要的角色，建議集線器對於所有請求的平均響應時間應少於5ms。
表 10-4. 集線器對於標準設備請求的響應【Hub Responses to Standard Device Requests】
bRequest | 集線器響應 【Hub Response】 |
CLEAR_FEATURE | 標準 |
GET_CONFIGURATION | 標準 |
GET_DESCRIPTOR | 標準 |
GET_INTERFACE | 未定義。集線器被允許只支持一個接口。 |
GET_STATUS | 標準 |
SET_ADDRESS | 標準 |
SET_CONFIGURATION | 標準 |
SET_DESCRIPTOR | 可選 |
SET_FEATURE | 標準 |
SET_INTERFACE | 未定義。集線器被允許只支持一個接口。 |
SET_ISOCH_DELAY | 標準 |
SET_SEL | 標準 |
SYNCH_FRAME | 未定義。集線器不被允許有等時端點。 |
沒有被實現的可選的請求應該在請求的數據或者狀態階段返回一個STALL。
10.14.2 類特定的請求 【Class-specific Requests】
集線器類定義了集線器要響應的請求，列出在表10-5中。表10-6定義了集線器類請求代碼。所有下表中的請求，除了SetHubDescriptor()之外，都是強制必須的。
表 10-7 給出了有效的集線器類的特性選擇子（feature selectors）。參考第10.14.2.4 節和10.14.2.6節關於特性的描述。
10.14.2.1 Clear Hub Feature
如果wValue不是表10-7中列出的特性選擇子，或者如果wIndex或wLength不是如上所指定的那樣，就是一個請求錯誤（Request Error）。
如果一個集線器沒有被配置，那麼對於該請求的集線器響應就未定義。
10.14.2.2 Clear Port Feature
端口號應該是該集線器有效的端口編號，大於0。端口字段位於字段的bits 7..0。
清除一個特性就是將該特性禁止，或者啓動一個與該特性相關的過程。參考表10-7中特性選擇子的定義。如果特性選擇子與一個狀態改變相聯繫，清除這個狀態改變就確認了這個改變。這個請求格式用於清除下列特性：
如果一個集線器沒有被配置，那麼對於該請求的集線器響應就未定義。
10.14.2.3 Get Hub Descriptor
如果wLength大於實際的描述符長度，那麼只返回實際的長度。如果wLength小於實際的描述符長度，那麼只有最先的wLength長度字節的描述符被返回。即使wLength是零，也不被認爲是錯誤。
如果的wValue 或 wIndex值是除了上面指定的值之外的其他值，就是一個請求錯誤（Request Error）。
如果一個集線器沒有被配置，那麼對於該請求的集線器響應就未定義。
10.14.2.4 Get Hub Status
這個請求返回當前集線器狀態以及相對於前一次確認已經改變了的狀態。
數據的第一個字包含wHubStatus字段（參考表10-8）。第二個字包含wHubChange字段（參考表10-9）。
如果的wValue ，wIndex，或wLength值是除了上面指定的值之外的其他值，就是一個請求錯誤（Request Error）。
如果一個集線器沒有被配置，那麼對於該請求的集線器響應就未定義。
比特Bit | 描述Description |
0 | 本地電源來源【Local Power Source】：這是本地電源供給的來源。 這一字段指示是否集線器電源（除了給SIE的部分）當前是由外部電源或者從USB總線供電。本字段允許USB系統軟件判定從集線器可用於下行設備的電源。 0 =本地電源供給良好【 Local power supply good】 1 =本地電源供給丟失（不活動） 【Local power supply lost (inactive)】 |
1 | 過流【Over-current】: 如果集線器支持在集線器基礎上報告過流，這個字段指示所有端口電流的總和超過了指定的最大值，並且所有的端口已經被置於Powered-off狀態。如果集線器以端口爲基礎報告過流或者沒檢測過流的機制，那麼本字段總是0。集線器應該只在物理上不能滿足所有端口的電流吸取時報告過流。關於過流保護的更多信息，參考USB 2.0規範7.2.1.2.1節。 0 = 當前沒有過流情形存在。【No over-current condition currently exists.】 1 = 有一個集線器過流情形存在。【A hub over-current condition exists.】 |
2-15 | 保留 |
沒有已定義的特性選擇子給這些狀態比特，並且他們既不能被USB系統軟件設置，也不能被清除。
比特Bit | 描述Description |
0 | 本地電源狀態改變（C_HUB_LOCAL_POWER）: 這一字段指示在wHubStatus中的集線器的本地電源來源（Local Power Source）字段發生了改變。 本字段在集線器接收到總線復位時初始化爲0. 0 = 沒有發生本地電源狀態改變【No change has occurred to Local Power Status.】 1 = 本地電源狀態已經改變【Local Power Status has changed.】 |
1 | 過流改變 （C_HUB_OVER_CURRENT）： 這一字段指示在wHubStatus中過流（Over-Current）字段發生了改變。 本字段在集線器接收到總線復位時初始化爲0. 0 =過流狀態沒有改變【 No change has occurred to the Over-Current Status.】 1 = 過流狀態已經改變【Over-Current Status has changed.】 |
2-15 | 保留 |