本文為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。
3. 如果頭包在第2步驟被標記為deferred, 一個包括集線器深度（hub depth）以及正確的CRC-5的推后頭包（deferred header packet）被排隊進入上行端口的Tx頭包緩沖區。
4. 該已被修改的頭包在對應的下行端口上被排隊准備傳輸。
5. 如果頭包是一個數據包頭（data packet header），對應的數據包負載被丟棄（discarded）。
- 如果頭包是被路由到處於U0的下行端口，或者頭包一個是ITP（在該情況下，下面的處理被獨立於處於U0狀態的每一個端口而完成)：
1. 如果下行端口的Tx頭包緩沖區隊列不是空的（在對列中至少還有一個頭包沒有完全地被傳輸），或者沒有鏈路信用值（link credit）可用來在下行端口上傳輸，頭包被標記為delayed，並且對於被修改的頭包，正確的鏈路控制字CRC-5被重新計算。
2. 頭包地在適當的下行端口上被排隊准備傳輸。
注意：如果適當的下行端口的隊列已滿，一旦在該適當的下行端口的對列上有一個空間可用，頭包就被排隊上去。當一個下行端口隊列已滿的時候，集線器應該繼續正常處理后續的頭包，如果他們指向一個不同的下行端口的話。
— 如果頭包是 ITP：
1. 頭包在每個鏈路處於U0的下行端口上被排隊准備傳輸。
2. 如果下行端口的Tx頭包緩沖區隊列不是空的（在對列中至少還有一個頭包沒有完全地被傳輸），或者沒有鏈路信用值（link credit）可用來在下行端口上傳輸，頭包被標記為delayed，並且對於被修改的頭包，正確的鏈路控制字CRC-5被重新計算。
注意：如果適當的下行端口的隊列已滿，一旦在該適當的下行端口的對列上有一個空間可用，頭包就被排隊上去。當一個下行端口隊列已滿的時候，集線器應該繼續正常處理后續的頭包，如果他們指向一個不同的下行端口的話。
— 如果頭包不是被路由到一個下行端口：
1. 頭包被處理。
2. 頭包從Rx頭包緩沖區被移除。
3. 如果需要，對頭包的一個響應被排隊准備傳輸。
— 如果頭包是被路由到一個被禁止的或不存在的下行端口：
1. 頭包從Rx頭包緩沖區被移除。
2. 頭包默默地被丟棄。
- 當最后一個頭包符號在Rx header packet狀態被接收到，並且要么該頭包CRC-16或鏈路控制字CRC-5 被判定為無效的時候。
— 頭包從Rx頭包緩沖區被移除。
— LBAD 鏈路命令在上行端口被排隊准備傳輸。
注意：所有的后續的頭包都被默默地丟棄，直到對無效的頭包的重試被接收到。
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】
這一節描述下行面端口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）頭包的傳輸。
在如下任一情形下，端口應該轉換到Tx Header狀態：
- 從Tx IDLE狀態，當有一個或者多個頭包被排隊准備傳輸，但是沒有鏈路命令被排隊准備傳輸時。
在傳送任何頭包的結尾（除了具有數據包負載的數據包頭包以外），當已傳送符號計數超過或等於nSkipSymbolLimit，一個SKP有序集應該被傳輸，而且已傳送符號計數應該被減少nSkipSymbolLimit個。
10.7.10.3 Tx Data
在 Tx Data 狀態中，下行端口發送器正在積極地傳送一個數據包負載。在傳送數據包負載的最后的分幀符號以及必要的SKP有序集之后，端口可以將數據負載包從集線器的儲存緩沖中移除。在任何的境況之下，集線器都不應該重傳數據包負載包。
當有數據包負載與被傳輸了的數據包頭相關聯時，端口應該從Tx Header狀態轉換到Tx Data狀態。數據包負載量傳輸應該在傳輸數據包頭的最后一個符號之后立刻開始。
在傳送沒被中止（aborted）的數據包負載結束的時候：
- 當已傳送符號計數超過或者等於nSkipSymbolLimit時，一個SKP有序集應該被傳輸，並且已傳送符號計數應該被減少nSkipSymbolLimit個。
- 該序列被重復，直到符號計數少於nSkipSymbolLimit。
10.7.10.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.10.5 Tx Link Command
在Tx Link Command狀態中，下行端口發送器正在積極地傳送一個鏈路命令。如果多個鏈路命令要在Tx Link Command狀態被排隊傳輸，他們應該無間隙地被傳輸，除非SKP有序集被傳輸。
在下列的任一情形下，端口應該轉換到Tx Link Command狀態：
- 從Tx IDLE狀態，當有一個或多個鏈路命令被排隊准備傳輸時候。
- 從Tx Link Command狀態，當有另外的鏈路命令被排隊准備傳輸的時候。
在傳送任何的鏈路命令結束的時候，若已傳送符號計數超過或者等於nSkipSymbolLimit，一個SKP有序集應該被傳輸，並且已傳送符號計數應該被減少nSkipSymbolLimit個。
10.7.11 下行面端口Rx 【Downstream Facing Port Rx】
這一節描述下行面端口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
在Rx Data狀態中，下行端口接收器正在積極地處理已經接收到的符號，並尋找DPPEND有序集或 DPPABORT有序集。當進入本狀態的時候，接收器應該從零開始對已經接收到的符號進行計數。被計算的第一個符號是DPPSTART有序集后的第一個符號。
當端口接收到有效的DPPSTART有序集的時候，它應該轉換到Rx Data狀態。當在如第 7.2.4.1.6 節所定義的DPP結束之前，端口檢測到一個錯誤的時候，只有在它已經在適當的下行端口上傳輸完已經接收到的 DPP（包括DPPABORT有序集）之后，它才可能清除它的緩沖區中的數據。當一個錯誤被檢測到的時候，集線器應該在傳送數據包負載錯誤（被跟隨一個DPPABORT有序集）前，在適當的下行端口上傳送有效的已經接收到的符號。注意，即使集線器在下行端口上開始傳送DPP之前，集線器檢測到一個錯誤，這一個要求也適用。
集線器應該有至少1080字節共享的緩沖區用於在所有的下行端口上接收到的數據包。
10.7.12.3 Rx Header
在Rx header狀態中，下行端口接收器正在積極地處理已經接收到的符號,直到最后一個頭包符號被接收到。當進入這狀態的時候,接收器應該從零開始一個對已經接收到符號的計數。被計算的第一個符號是HPSTART有序集后的第一個符號。
當端口接收到有效的HPSTART有序集的時候，它應該轉換到Rx Header狀態。端口應該在頭包的最后一個符號被接收到之后的四個符號時間內，完成驗證CRC-16，鏈路控制字CRC-5，並且檢查路由字串和頭包類型。
實現者可能必須要在接收到符號時就開始CRC計算，在頭包被驗證之前就開始檢查路由字串，來滿足這一要求。
10.7.12.4 處理頭包 【Process Header】
當一個頭包的最后一個符號被接收到的時候,端口應該對該頭包執行所有必要附加處理。任何的此類處理都不應該阻礙端口立刻返回到Rx Default狀態，並繼續處理已經接收到的符號。
在如下任一情形下，端口要對頭包執行附加的處理。附加的處理步驟被描述在每種情形中。
- 當最后一個頭包符號在Rx Header狀態被接收到，並且頭包CRC-16以及鏈路控制字CRC-5被判定有效的時候，適當的LGOOD_n鏈路命令就會被該接收端口排隊准備傳輸，並且：
- 頭包在上行端口上被排隊准備傳輸。
如果上行端口的隊列已滿后，一旦在上行端口的對列上有一個空間可用，頭包就被排隊上去。當一個上行端口隊列已滿的時候，集線器應該繼續正常處理后續的頭包。如果一些頭包在多個下行端口上被接收到，或當空間在上行端口的頭包隊列中變得可用而使得一些頭包被排隊由集線器控制器准備發送的時候，如果有一個（非數據包頭）正在一個下行端口隊列的前面或集線器控制器內等候的話，集線器將優先選擇非數據包頭，而不是數據包頭包。除此之外，集線器使用的仲裁算法沒被指定。
注意：這些仲裁要求只在多個下行端口以及該集線器控制器之間適用。對於單個來源（下行端口或集線器控制器），包必須以它們被接收到或生成的順序來傳輸。
2. 如果下行端口Rx頭包緩沖區至少有四個空閑的槽位，適當的LCRD_x鏈路命令在下行端口被排隊准備傳輸。否則，該適當的LCRD_x鏈路命令會在用於頭包的Rx頭包緩沖區槽位可用時，被排隊准備傳輸。
- 當最后一個頭包符號在Rx header狀態被接收到，並且要么頭的CRC-16或鏈路控制字CRC-5被判定為無效的時候：
— 頭包從 Rx 頭緩沖區被移除。
— LBAD 鏈路命令被下行端口排隊准備傳輸。
注意：所有的后續頭包默默地被丟棄，直到對於該無效的頭包的重試被接收到。
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】
從作為一個USB設備，以及傳導掛起以及恢復信號兩方面來講，集線器都必須支持掛起和恢復。全局掛起/恢復是指整個總線被掛起或恢復，而不影響任何的集線器下行面端口狀態；選擇性掛起/恢復是指一個集線器的一個下行面端口被掛起或者恢復而不影響集線器狀態。SuperSpeed 集線器只支持選擇性掛起和恢復。它們不支持全局的掛起和恢復。選擇性掛起/恢復是通過到一個集線器的請求來實現。設備發起的恢復叫做遠程喚醒（remote-wakeup）。
在集線器的上行面端口上，集線器與SuperSpeed設備遵循相同的掛起要求。
當一個集線器下行端口鏈路處於U3狀態中時，如果集線器接收到來自該下行端口的鏈路對方發來的喚醒信號（wakeup signaling），那么如下的要求適用於該集線器：
- 如果集線器上行端口鏈路不處於U3狀態，集線器應該在tHubDriveRemoteWakeDownstream內，在接收到喚醒信號的下行鏈路上驅動遠程喚醒信號。
- 如果集線器上行端口鏈路處於U3狀態，集線器應該在tHubPropRemoteWakeUpstream內，在其上行端口上驅動遠程喚醒信號。
當集線器上行端口鏈路處於U3狀態，並且從集線器的上行端口鏈路的鏈路對方接收到喚醒信號，集線器應該自動驅動遠程喚醒信號到所有的處於U3並且從進入U3之后【還沒有】【譯注，原文此處為"已經"，疑為錯誤】接收到遠程喚醒信號的下行端口。當集線器接收到一個對於具有處於U3狀態的鏈路的下行端口的SetPortFeature(PORT_LINK_STATE) U0時，集線器應該在tHubDriveRemoteWakeDownstream內在鏈路上驅動遠程喚醒信號。
10.9 集線器上行口復位行為 【Hub Upstream Port Reset Behavior】
對一個集線器的復位信號只在下行方向有定義，也就是在集線器的上行面端口。集線器必要的復位信號機制在第 6 章被描述。
處於掛狀態的集線器應該將復位型號的開始解釋為喚醒事件（wakeup event）；到復位信號結束時，集線器應該是醒的（awake），並且已經完成了它的復位序列（reset sequence）。
在Warm Reset的完成之后，整個集線器返回到默認狀態。
在Hot Reset完成之后，集線器除了上行端口的端口配置信息被保持以外，其余返回為默認狀態。
10.10 集線器端口電源控制 【Hub Port Power Control】
自供電的集線器可能有到下行面端口的控制電源遞送的電源開關，但是它並不是必需的。具有電源開關的集線器可以把所有的端口作為一個組/集體，或者各個端口單獨對待，或者組成多個集體（每個集體有一個或多個端口），來開關電源供應。集線器通過在 wHubCharacteristics 中設置邏輯電源開關模式（Logical Power Switching Mode）字段，來指示其是否支持電源開關。如果一個集線器支持每一端口的電源開關，那么到一個端口的電源如表 10-1 所指定的那樣被打開或關閉。如果一個集線器支持分組的電源開關，那么在該組之上任何端口需要電源的時候，該組中的所有端口電源被打開。對一個組的電源不會被關掉，除非在一個組的所有的端口處於表 10-1 指定的那樣允許電源被移除的狀態。如果當該請求被執行並且PORT_POWER特性會被打開時，C_HUB_LOCAL_POWER 和本地電源狀態（Local Power Status）（在wHubStatus中）兩者都被設定為1，那么到端口的電源不會被SetPortFeature（PORT_POWER）請求打開【譯注：此句比較拗口！】。支持充電應用的集線器可能在其他時候仍然保持電源打開。參考第 10.3.1.1節中支持充電應用的集線器允許的行為的更多細節。
盡管自供電的集線器不被強制要求實現電源開關，集線器還是應該要支持對所有的端口的Powered-off狀態。此外，集線器應該實現PortPwrCtrlMask（所有比特都被設為1），即使集線器沒有可以被USB系統軟件控制的電源開關。
對於沒有電源開關的集線器，bPwrOn2PwrGood應該被設置為0。
10.10.1 多個電源分組 【Multiple Gangs】
集線器可以實現任意數量的電源和/或過流分組（gangs）。實現了多於一個過流和/或電源開關分組的集線器應該將邏輯電源開關模式（Logical Power Switching Mode）以及過流報告模式（Over-current Reporting Mode）字段都置位，用以表明電源開關和過流報告是基於每個端口的（這些字段在wHubCharacteristics中）。同時，在PortPwrCtrlMask中的所有比特都應該被設為1。
當過流情形發生在過流保護設備上時，過流被報告給所有被該設備保護的端口。當過流信號被報告時，該組中的所有打開都被置於DSPORT.Powered-off狀態，並且所有端口的C_PORT_OVER_CURRENT字段都被設置為1。當打開狀態被從該組的任意打開上讀取時，只要過流情形依然處在，則PORT_OVER_CURRENT字段就會被設置。該C_PORT_OVER_CURRENT字段應該在每個端口單獨地被清除。當多個端口共享一個電源開關時，設置該組中任意一個端口的PORT_POWER都會導致該組中所有端口的電源被打開。但是，這不會導致該分組其他的端口離開DSPORT.Powered-off狀態。當一個分組中的所有端口都處於DSPORT.Powered-off狀態，或者集線器沒有被配置時，這些端口的電源是被關閉的。如果一個集線器將電源開關和過流保護都實現了，沒有必要讓過流報告分組和電源開關分組相同。
如果過流情形發生，並且有電源開關，那么與過流保護電路相關聯的電源開關都應該被關閉。如果多個過流保護設備與單個電源開關相關聯，那么當任意一個過流保護電路指示有過流情形時，那個開關都將被關閉。
10.11 集線器控制器 【Hub Controller】
集線器控制器邏輯組織如圖10-20所示。
10.11.1 端點組織 【Endpoint Organization】
集線器類定義了一個除了默認的控制管道之外的附加端點，對於所有的集線器都是必需的：狀態改變端點（Status Change endpoint）。這個端點的最大突發大小（maximum burst size）被設置為1。主機系統通過狀態改變端點接收到端口和集線器的狀態改變通知。狀態改變端點是中斷端點。如果沒有集線器或者端口狀態改變比特被置位，那么當狀態改變端點接收到一個IN請求時（通過ACK TP），集線器返回一個NRDY。當有一個狀態改變比特被置位，集線器會發送一個ERDY TP給主機。主機之后接着會向狀態改變端點請求數據，該數據會指示具有改變比特的實體（集線器或者端口）。USB系統軟件可以使用這個數據來判定需要訪問那個狀態寄存器，來獲得該狀態改變中斷的精確原因。
10.11.2 集線器信息結構和操作 【Hub Information Architecture and Operation】
圖 10-21 顯示了狀態，狀態變化，以及控制信息如何與設備狀態之間的關聯。集線器描述符以及集線器/端口狀態和控制可以通過默認的控制管道進行訪問。集線器描述符可以隨時被讀取。當集線器在一個端口上檢測到一個變化，或當集線器改變它自己的狀態的時候，狀態改變端點以第 10.11.4 節指定的格式傳遞數據到主機。
硬件或者軟件事件，可以導致集線器或者端口狀態改變比特被設置。一旦被置位，這些比特一直保持置位狀態，直到直接被USB系統軟件通過ClearPortFeature()請求或者集線器復位清除。當一個改變比特被設置，當狀態改變端點被讀取時，集線器會持續報告狀態改變，直到所有的狀態改變比特都被USB系統軟件清除。
USB系統軟件使用與狀態改變端點相關聯的中斷管道來檢測集線器和端口狀態的改變。
10.11.3 端口改變信息的處理 【Port Change Information Processing】
集線器通過基於每個端口的端口命令來報告端口的狀態。USB系統軟件通過清除與集線器報告的狀態改變相應的改變狀態來確認端口改變。該確認清除了該端口的改變狀態，因此之后的到狀態改變端點的數據傳輸就不會寶蓋前面的事件。這就允許可以重復對將來的改變處理（參見如10-22）。
10.11.4 Hub and Port Status Change Bitmap
圖10-23中顯示的集線器和端口狀態Bitmap，指示是否集線器或者端口經歷了一次狀態改變。這個bitmap也指示了哪些端口已經有了一個狀態改變。集線器在狀態改變端點上返回這個值。集線器以字節增加的方式報告此值。例如，如果一個集線器有6個端口，它就報告1個字節的長度量，並且對於無效的端口號字段位置會報告為0。USB系統軟件對於集線器上的端口數量是知道的（這是在集線器描述符中報告了的），並且對集線器和端口狀態改變Bitmap相應地解碼。集線器在集線器和端口狀態改變Bitmap的bit 0上報告集線器本身狀態的任何改變。
集線器和端口狀態改變Bitmap大小是2字節。集線器只報告集線器實際具有的端口數數量的比特位。USB 3.0集線器可能具有不多於nMaxHubPorts個端口。
在任何時間，只要任意的狀態改變比特位變為非零，就會返回一個ERDY（如果之間發送過一個NRDY），通知主機集線器和端口狀態改變Bitmap已經改變了。圖10-24顯示了構造集線器和端口改變比特的示例。
10.11.5 過流報告和恢復 【Over-current Reporting and Recovery】
USB設備應該被設計成滿足可適用的安全標准。通常，這將會意指自供電集線器在它的下行面端口上實現限流。如果一個過流情形發生，它就導致一個或多個端口中的狀態和狀態改變。這個變化被報告給USB系統軟件以便它能采取糾正性的行動。
集線器可能被設計成把過流當做端口或集線器事件來報告。集線器描述符字段wHubCharacteristics被用來指示該特定集線器的報告能力（參考第 10.13.2.1 節)。在集線器或端口狀態字段的過流狀態，指示當狀態被返回的時候過流檢測的當前狀態。在集線器或端口改變字段的過流狀態改變比特，指示是否過流狀態已經改變。
當集線器遇到一次過流情形，它應該將被影響到的所有端口置於DSPORT.Powered-off狀態。如果集線器有每個端口的電源開關以及每個端口的電流限制，一個端口上的過流情形可能也會導致在其他端口上的電源下降到指定的最小值之下。在這中情形下，被影響到的端口被置於DSPORT.Powered-off狀態，並且該端口的C_PORT_OVER_CURRENT被設置，但是PORT_OVER_CURRENT不被設置。如果集線器有基於集線器的過流檢測，那么集線器上的過流情形會導致所有的端口都進入DSPORT.Powered-off狀態。但是，在這種情形下，被影響到的端口的C_PORT_OVER_CURRENT 和 PORT_OVER_CURRENT兩者都不會被設置。
主機對於過流事件的恢復動作包括下面這些：
- 主機從集線器獲得過流事件的通知。
- 主機抽取出恰當的集線器或端口改變信息（依賴於改變bitmap中的信息）。
- 主機等待過流狀態比特被清成0.
- 主機對所有端口進行上電周期（例如，對每個端口發送一個SetPortFeature(PORT_POWER)請求）。
- 主機重新枚舉所有被影響到的端口。
10.11.6 枚舉處理 【Enumeration Handling】
集線器設備類命令被用於管理其下行面端口狀態。當有設備連接上時，設備連接事件被檢測到，並被在狀態改變端點上報告。主機將接受狀態改變報告，並且可能在端口上發一個SetPortFeature(PORT_RESET)請求。主機調用的Get_Status(PORT)請求會返回一個PORT_SUPER_SPEED的指示說明下行面端口是在SuperSpeed上操作。
當設備被從端口上拔出，端口通過狀態改變端點報告狀態改變。接着，就進入下一個設備連接檢測的過程就緒。
10.12 集線器配置 【Hub Configuration】
集線器是通過標准的USB設備配置命令來配置的。沒有被配置的集線器在電源需求和尋址方面和其他的沒有被配置設備的行為相似。集線器被要求基於幾個因素來給下行端口上電，包括是否該集線器支持電源開關和充電應用。參考10.3.1.1節關於何時集線器何時需要給下行端口供電的細節。配置集線器使能了其狀態改變端點。配置過程的一部分是設置集線器深度（hub depth），用於計算一個對路由字串（Route String）（參考8.9節）的索引（參考10.14.2.8節）。集線器深度是用於得到到路由字串的偏移量（在TP或DP中），集線器用其來路由在其上有端口上接收到的包。USB系統軟件可以接着發送命令到集線器，來在適當的時候對電源進行開或關。
USB系統軟件檢查集線器描述符信息來判定集線器的特性。通過檢查集線器的特性，USB系統軟件可以通過不給可能會造成USB電源拓撲違例的集線器端口供電，來確保非法的電源拓撲不被允許。設備狀態和配置信息可以被用來判定是否集線器可以被用於一個給定的拓撲。表10-2總結了用於如何判定集線器當前的電源需求的信息。
表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 |
這個集線器正從總線和本地電源取電。當前作為一個自供電的集線器可用。 |
自供電的集線器有一個本地電源供給，但是可能可選地從其上行連接吸取一個單位的（電流）負載。這就允許當本地電源不可用時，接口還可以繼續工作（參考7.2.1.2節）。當本地電源被移除后（由於集線器范圍的過流情形或者本地電源供給關閉），這種類型的集線器保持在Configured狀態，但是將所有的端口（不論可移除與否）都轉換到Powered-off狀態。當本地電源處於關閉時，所有狀態和改變信息都讀成0，並且所有的SetPortFeature()請求都被忽略（請求被當做空操作對待）。集線器會使用狀態改變端點來通知USB系統軟件集線器事件（參考10.11.4節集線器狀態的細節）。
配置描述符的MaxPower字段用於向系統報告本配置被選擇時，集線器將要從VBUS吸取的最大電源。連接到集線器的外接設備會單獨地向集線器報告他們的電源需求。
復合設備（compound device）可以從VBUS給集線器電氣和永久連接的設備兩者供電。整體負載可能在集線器配置描述符中報告，每個永久鏈接的設備都報告成自供電，在它們相應的配置描述符里MaxPower為0。
總線供電的集線器應該能夠提供沒有被當前選擇的配置的集線器電氣或永久鏈接的設備使用的所有電源給暴露的下行端口。集線器應該能夠提供任意分割的電源給暴露的下行端口（例如，如果集線器能夠體統600mA給兩個暴露的下行端口，那么它必須能夠提供450mA給一個端口，150mA給另一個端口，或者300mA給每一個端口，等等）。
注意：軟件應該確保對於在一個總線供電的集線器上的每一個暴露的下行端口至少有150mA可用。
10.13 描述符 【Descriptors】
集線器描述符源於一般的USB設備框架。集線器描述符描述一集線器設備以及在該集線器上的端口。主機經過集線器默認控制管道訪問集線器描述符。
USB 規范（參考第8章) 定義了如下的描述符：
- 設備（Device）層描述符
- 配置（Configuration）描述符
- 接口（Interface）描述符
- 端點（Endpoint）描述符
- 字符串（String）描述符（可選）
集線器類定義附加的描述符（參考第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.
SuperSpeed模式下的集線器描述符
10.13.2 類特定描述符 【Class-specific Descriptors】
10.13.2.1 集線器描述符 【Hub Descriptor】
表10-3列出了集線器描述符包含的各個字段。
10.14 請求 【Requests】
10.14.1 標准請求 【Standard Requests】
集線器具有比在9.2.6節中為標准設備指定的請求處理時間更緊的限制，因為他們對於連接到USB上的所有設備的"可使用時間"非常關鍵。最壞情形請求處理時間列於如下（他們適用於標准和集線器類請求）：
- 沒有數據階段的請求的完成時間：50ms
- 標准的有數據階段的請求的完成時間：
- 從setup到第一個數據階段的時間：50ms
- 每個后續的數據階段之間：50ms
- 最后的數據階段和狀態階段之間的時間：50ms
由於集線器在總線枚舉中扮演了如此重要的角色，建議集線器對於所有請求的平均響應時間應少於5ms。
表10-4列出了各種不同的標准設備請求。
表 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
本請求將在集線器狀態中報告的一個值復位。
清除一個特性就是將該特性禁止。參考表10-7中可用集線器作為接收者的特性選擇子的定義。如果特性選擇子與一個狀態改變相聯系，清除這個狀態改變就確認了這個改變。這個請求格式被用於清除C_HUB_LOCAL_POWER 或 C_HUB_OVER_CURRENT特性。
如果wValue不是表10-7中列出的特性選擇子，或者如果wIndex或wLength不是如上所指定的那樣，就是一個請求錯誤（Request Error）。
如果一個集線器沒有被配置，那么對於該請求的集線器響應就未定義。
10.14.2.2 Clear Port Feature
本請求將在端口狀態中報告的一個值復位。
端口號應該是該集線器有效的端口編號，大於0。端口字段位於字段的bits 7..0。
清除一個特性就是將該特性禁止，或者啟動一個與該特性相關的過程。參考表10-7中特性選擇子的定義。如果特性選擇子與一個狀態改變相聯系，清除這個狀態改變就確認了這個改變。這個請求格式用於清除下列特性：
• PORT_POWER
• C_PORT_CONNECTION
• C_PORT_RESET
• C_PORT_OVER_CURRENT
• C_PORT_LINK_STATE
• C_PORT_CONFIG_ERROR
• C_BH_PORT_RESET
清除PORT_POWER特性導致端口被置於DSPORT.Powered-off狀態，並且可能，由於集線器電源開關限制的原因，導致電源被從端口上移除。當處於DSPORT.Powered-off狀態，唯一有效的以該端口為接收者的請求是Get Port Status（參考10.14.2.6節），以及Set Port Feature (PORT_POWER) （參考節10.14.2.10）。
清除FORCE_LINKPM_ACCEPT特性導致端口無效Set Link Function LMPs 中的Force_LinkPM_Accept 比特。如果Force_LinkPM_Accept比特在該端口不是有效的話，集線器應該將這個請求當做功能無操作。
如果wValue不是一個在表10-7中列出的特性選擇子，或者wIndex指定了一個不存在的端口，或者wLength不是如上所指定的值，那么這就是一個請求錯誤（Request Error）。這個請求如果嘗試要清除一個已經清除過了的特性，並不是一個錯誤（集線器應該把它當做一個功能無操作）。
如果一個集線器沒有被配置，那么對於該請求的集線器響應就未定義。
10.14.2.3 Get Hub Descriptor
這一請求返回集線器描述符。
對集線器描述符的GetDescriptor()請求遵循與標准GetDescriptor()請求相同的使用模型（參見第9章）。標准的集線器描述符使用10.13.2.1節中定義的值來代表。所有的集線器都要求要實現一個集線器描述符，具有描述符索引為0。
如果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）。
如果一個集線器沒有被配置，那么對於該請求的集線器響應就未定義。
表 10-8. 集線器狀態字段, wHubStatus
比特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系統軟件設置，也不能被清除。
表 10-9. 集線器改變字段, wHubChange
比特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 |
保留 |
集線器可以允許使用SetHubFeature()請求設置這些改變比特，用以支持自我診斷（diagnostics）。如果集線器不支持設置這些比特，它聽應該要么將SetHubFeature()請求當做請求錯誤（Request Error）對待，要么作為功能無操作。一旦被設置，這些比特可以被ClearHubFeature()請求清除。一個請求設置一個已經被設置的特性，或者清除已經被清除的特性的請求是沒有效果的，集線器應該當做功能無操作對待。
10.14.2.5 Get Port Error Count
這個請求返回由wIndex指示的集線器端口檢測到的鏈路錯誤數。每當設備經歷一次復位（參見7.3節）或者上電時這個值都會被復位到0。
端口號應該是該集線器有效的端口編號，大於0。
如果的wValue ，或wLength值是除了上面指定的值之外的其他值，或者指定了不存在的一個端口，這就是一個請求錯誤（Request Error）。
如果一個集線器沒有被配置，那么對於該請求的集線器響應就未定義。
10.14.2.6 Get Port Status
該請求返回當前端口狀態及端口的狀態變化位的當前值。
端口號應該是該集線器有效的端口編號，大於0。
數據的第一個字包含wPortStatus字段（參考表10-10）。第二個字包含wPortChange字段（參考表10-11）。
在適用的地方，在wPortStatus和wPortChange字段中的比特位是一對一對應的。
如果的wValue ，或wLength值是除了上面指定的值之外的其他值，或者指定了不存在的一個端口，這就是一個請求錯誤（Request Error）。
如果一個集線器沒有被配置，那么對於該請求的集線器響應就未定義。
10.14.2.6.1 端口狀態位 【Port Status Bits】
表 10-10. 端口狀態字段, wPortStatus
比特Bit |
描述Description |
0 |
Current Connect Status (PORT_CONNECTION)：該字段指示是否有設備連接到這個端口。 Value Meaning 0 No device is present 1 A device is present on this port |
1 |
Port Enabled/Disabled：該字段指示端口是否被使能。端口可以由於一個錯誤情形（斷開事件或者其它錯誤情形）或者USB系統軟件被禁能。 Value Meaning 0 Port is disabled 1 Port is enabled |
2 |
保留 |
3 |
Over-current (PORT_OVER_CURRENT)：如果集線器一端口為基礎報告過流情形，這個字段指示在端口上抽取的電流超過了指定的最大值。 Value Meaning 0 No over-current condition exists on this port 1 An over-current condition exists on this port |
4 |
Reset (PORT_RESET)：當主機想要復位連接着的設備時，本字段被置位。它一直保持置位直到復位信號被集線器關閉。 Value Meaning 0 Reset signaling not asserted 1 Reset signaling asserted |
5-8 |
Port Link State (PORT_LINK_STATE)：該字段反映連接到該端口的鏈路的狀態。在到新狀態的轉換完成之前不會反映該狀態。 Value Meaning 0x00 Link is in the U0 State 0x01 Link is in the U1 State 0x02 Link is in the U2 State 0x03 Link is in the U3 State 0x04 Link is in the SS.Disabled State 0x05 Link is in the Rx.Detect State 0x06 Link is in the SS.Inactive State 0x07 Link is in the Polling State 0x08 Link is in the Recovery State 0x09 Link is in the Hot Reset State 0xA Link is in the Compliance Mode State 0xB Link is in the Loopback State 0xC-0xF Reserved |
9 |
Port Power (PORT_POWER): 此字段反映了端口的邏輯，電源控制狀態。由於集線器可以實現不同的端口電源開關方法，這一地段可能會也可能不會表示有電源應用到端口。設備描述報告集線器實現的電源開關類型。 Value Meaning 0 This port is in the Powered-off state 1 This port is not in the Powered-off state |
10-12 |
連接到此端口的協商好的速度(PORT_SPEED)：本字段只有在設備連接上后有效。 Value Meaning 0 5 Gbps 1 Reserved 2 Reserved 3 Reserved 4 Reserved 5 Reserved 6 Reserved 7 Reserved |
13-15 |
保留 |
PORT_CONNECTION
在端口處於DSPORT.Enabled或DSPORT.Resetting或DSPORT.Error狀態時，該位設置為1，否則設置為零。
SetPortFeature（PORT_CONNECTION）和 ClearPortFeature（PORT_CONNECTION）請求不得由USB系統軟件使用，並應被集線器當做沒有操作的請求對待。
PORT_ENABLE
下行端口處在DSPORT.Enabled狀態時，該位設置為1，否則設置為零。
請注意的USB 2.0 ClearPortFeature（PORT_ENABLE）請求不被超高速集線器支持，不能由USB系統軟件使用來禁用端口。
PORT_OVER_CURRENT
過流條件存在端口時，該位設置為1，否則設置為零。 如果在這個端口上的電壓是受另一個端口過流情況影響，該位被設置為 1，並且保持設置為1，直到上產生影響的端口上的過流條件被刪除。當產生影響的端口上的過流條件被刪除，該位被設置為零。
過電流保護，在自供電集線器上是要求的（對於總線供電的集線器，這是可選的），如10.10節的概述所言。
SetPortFeature（PORT_OVER_CURRENT）和 ClearPortFeature（PORT_OVER_CURRENT）請求不得由USB系統軟件使用，可由集線器作為無操作請求處理。
PORT_RESET
當端口處於DSPORT.Resetting狀態時，該位設置為1。在所有其他下行端口狀態，此位被設置為零。
如果在第10.3.1.6的條件得到滿足，一個SetPortFeature（PORT_RESET或BH_PORT_RESET）請求將啟動 DSPORT.Resetting狀態。
ClearPortFeature（PORT_RESET）請求，不得由USB系統軟件使用，可被集線器作為無操作請求處理。
PORT_LINK_STATE
這字段反映了該鏈路的當前狀態。
SetPortFeature（PORT_LINK_STATE）請求可以由USB系統軟件在任何時候發送，但只具有在第10.14.2.10指明的效果。
ClearPortFeature（PORT_LINK_STATE）請求，不得由USB系統軟件使用，可被集線器作為無操作請求處理。
PORT_POWER
這比特反映了當前邏輯端口的電源狀態。此位在所有端口上都被實現，不論是否實際端口電源開關設備存在與否。
當該位是零，該端口是在DSPORT.Powered-off狀態。同樣，任何情形導致此端口進入DSPORT.Powered-off狀態，都會導致此位被設置為零。
SetPortFeature（PORT_POWER）會將該位設置為1，除非C_HUB_LOCAL_POWER 和本地電源狀態（在wHubStatus中）都兩者都設置為1，在這種情況下請求被作為功能無操作處理。
PORT_SPEED
本字段的值只在PORT_ENABLE位設置為1時有效。值為零的這個字段表明，連接到該端口的超高速設備是在5Gbps運行。本字段的所有其他值都保留。
此字段只能由USB系統軟件讀取。
10.14.2.6.2 端口狀態改變比特位 【Port Status Change Bits】
端口狀態改變位用來指示不是請求的直接結果導致的端口狀態的改變。端口狀態的變化位可以被ClearPortFeature（）請求或集線器復位來清除。 集線器可允許因為診斷目的，用SetPortFeature（）請求來改變位狀態設置。如果不支持集線器的狀態改變位設置，它可能要么把請求作為一個請求錯誤（Request Error），或作為一個功能無操作。表10-11描述了wPortChange字段的各位。
表10-11. 端口改變字段, wPortChange
比特Bit |
描述Description |
0 |
Connect Status Change (C_PORT_CONNECTION)：表明端口的當前連接狀態發生了變化。該集線器設備按照第10.3.1節中描述的那樣來設置這一字段。 值 意義 0 No change has occurred to Current Connect status 1 Current Connect status has changed |
1-2 |
保留 |
3 |
Over-Current Indicator Change (C_PORT_OVER_CURRENT)：此字段僅適用於基於每個端口報告過流條件的集線器（如在集線器描述符中報告的那樣）。 值 意義 0 No change has occurred to Over-Current Indicator 1 Over-Current Indicator has changed 如果集線器不是在每個端口報告過電流，那么這個字段始終為零。 |
4 |
Reset Change (C_PORT_RESET)：此字段在任何類型復位此端口的復位處理完成時設置。 值 意義 0 No change 1 Reset complete |
5 |
BH Reset Change (C_BH_PORT_RESET)：此字段在這個端口上熱復位處理完成時被設置。 值 意義 0 No change 1 Reset complete |
6 |
Port Link State Change (C_PORT_LINK_STATE)：此字段端口狀態發生了如下所述變化時被設置。 值 意義 0 No change 1 Link Status has changed |
7 |
Port Config Error (C_PORT_CONFIG_ERROR)：此字段在端口不能配置其鏈路伙伴時設置。 值 意義 0 Port Link Configuration was successful 1 Port Link Configuration was unsuccessful 5 Reserved 6 Reserved 7 Reserved |
8-15 |
保留 |
C_PORT_CONNECTION
該位設置為1時，PORT_CONNECTION位發生了變化，因為下行的端口成功完成訓練，並過渡到DSPORT.Enabled狀態。該位應該通過ClearPortFeature（C_PORT_CONNECTION）請求被設置到零。
C_PORT_OVER_CURRENT
PORT_OVER_CURRENT位從0改變到1，或從1改變到0時，該位設置為1。如果其他端口上過流，導致端口被放置在DSPORT.Powered-off狀態，此位也被設置。
該位應該通過ClearPortFeature（C_PORT_OVER_CURRENT）請求，或在邏輯端口電源關閉並且端口處於DSPORT.Powered-off狀態時，被設置到零。
C_PORT_RESET
由於任何類型的復位，端口從DSPORT.Resetting狀態過度到DSPORT.Enabled狀態，該位設置為1。
該位應該通過ClearPortFeature(C_PORT_RESET)請求，或在邏輯端口電源關閉時，被設置到零。
C_PORT_BH_RESET
該位只會在端口由於熱復位（Warm Reset），端口從DSPORT.Resetting狀態過度到DSPORT.Enabled狀態時被設置。
該位應該通過ClearPortFeature(C_PORT_BH_RESET)請求，或在邏輯端口電源關閉時，被設置到零。
C_PORT_LINK_STATE
當端口的鏈路由於SetPortFeature(Port_Link_State)請求的結果，完成了一個從U3狀態到U0狀態的過度，或者完成了從任意U狀態到SS.Inactive狀態的過度時，該位被設置。該位不會應為在一個下行面端口上接收到一個遠程喚醒信號而被設置。
該位將被通過ClearPortFeature(C_PORT_LINK_STATE)請求，或在邏輯端口電源關閉時，被設置到零。
C_PORT_CONFIG_ERROR
如果連接到該端口的鏈路不能被成功配置，例如，如果只有下行能力的端口被互相連接時，或者如果鏈路配置不能被完成時，該位被設置為1。
該位將被通過ClearPortFeature(C_PORT_CONFIG_ERROR)請求，或在邏輯端口電源關閉時，被設置到零。
10.14.2.7 Set Hub Descriptor
這一要求將覆蓋集線器描述符。
該對於集線器累描述符的SetDescriptor請求依照與標准的SetDescriptor請求相同的使用模型（參考設備框架一章）。標准的集線器描述符由10.13.2.1節定義的bDescriptorType來表示。所有的集線器都被要求實現一個描述符索引為0的集線器描述符。
該請求是可選的。該請求謝數據到類特定的描述符。主機提供數據，在控制事務的數據傳輸相位被傳輸到集線器。該請求一次寫整個集線器描述符。
集線器應該緩沖所有的在這個請求中接收到的字節，確保整個描述符從主機被成功傳輸。一旦成功完成總線傳輸，集線器就更新指定的描述符的內容。
如果wIndex不是0，或者wLength不匹配主機發送的數據，那么就是Request Error。不支持該請求的集線器用STALL在數據階段來響應該請求。
如果集線器沒有被配置，集線器對這一請求的響應是不確定的。
10.14.2.7 Set Hub Descriptor
This request overwrites the hub descriptor.
The SetDescriptor request for the hub class descriptor follows the same usage model as that of the
standard SetDescriptor request (refer to the framework chapter). The standard hub descriptor is
denoted by using the value bDescriptorType defined in Section 10.13.2.1. All hubs are required to
implement one hub descriptor with descriptor index zero.
This request is optional. This request writes data to a class-specific descriptor. The host provides
the data that is to be transferred to the hub during the data transfer phase of the control transaction.
This request writes the entire hub descriptor at once.
Hubs shall buffer all the bytes received from this request to ensure that the entire descriptor has
been successfully transmitted from the host. Upon successful completion of the bus transfer, the
hub updates the contents of the specified descriptor.
It is a Request Error if wIndex is not zero or if wLength does not match the amount of data sent by
the host. Hubs that do not support this request respond with a STALL during the Data stage of the
request.
If the hub is not configured, the hub's response to this request is undefined.
10.14.2.8 Set Hub Feature
這一請求設置一個在集線器的狀態中報告的值。
設置一個特性就是使能了那個特性。參考表10-7中的適用於以集線器為接收者的特性選擇子的定義。使用這個請求，狀態改變可能不會被確認。
如果wValue不是在表10-7中列出的特性選擇子，或者wIndex或wLength不是如上所指定的值，那么就是Request Error。不支持該請求的集線器用STALL在數據階段來響應該請求。
如果集線器沒有被配置，集線器對這一請求的響應是不確定的。
10.14.2.9 Set Hub Depth
該請求設置一個值，集線器用來判定集線器對Route String Index的索引。
wValue具有Hub Depth的值。Hub Depth左移2，就是對Route String的偏移，用以識別集線器的Route String Port字段的lsb.
如果wValue大於4，或者wIndex或wLength不是如上所指定的值，那么就是Request Error。
如果集線器沒有被配置，集線器對這一請求的響應是不確定的。
10.14.2.10 Set Port Feature 
這一請求設置一個在集線器的狀態中報告的值。
端口號應該是一個對於該集線器的有效端口號，大於0。端口號在wIndex字段的least significant byte (bits 7..0)。wIndex的most significant byte是0，除非當特性選擇子是PORT_U1_TIMEOUT 或 PORT_U2_TIMEOUT 或
PORT_LINK_STATE 或 PORT_REMOTE_WAKE_MASK。
設置一個特性使能該特性，或者啟動一個與該特性相關聯的過程；參考表10-7中的適用於以端口為接收者的特性選擇子的定義。使用這個請求，狀態改變可能不會被確認。可以被這個請求設置的特性如下：
• PORT_RESET
• BH_PORT_RESET
• PORT_POWER
• PORT_U1_TIMEOUT
• PORT_U2_TIMEOUT
• PORT_LINK_STATE
• PORT_REMOTE_WAKE_MASK
當特性選擇子是PORT_U1_TIMEOUT，wIndex字段的most significant byte (bits 15..8)指定U1不活動計時器的Timeout值。參考10.4.2.1節關於U1不活動計時器如何被使用的細節。
以下是允許的值：
表 10-12. U1 Timeout 值編碼
當特性選擇子是PORT_U2_TIMEOUT，wIndex字段的most significant byte (bits 15..8)指定U2不活動計時器的Timeout值。當接收到一個Set Port Feature請求並且具有PORT_U2_TIMEOUT特性選擇子時，端口的鏈路應該使用指定的超時值發送一個LMP到其鏈路伙伴方。參考10.4.2.1節關於U2不活動計時器如何被使用的細節。
表 10-13. U2 Timeout 值編碼
注：軟件不得使能連接到集線器的下行端口的U2超時值。 不一致的鏈接狀態可能會導致超時，如果使能的話。
當特性選擇子是PORT_LINK_STATE，wIndex字段的most significant byte (bits 15..8)指定主機軟件想要將那個連接到該端口的鏈路放置到的U狀態。除了在下面注明的之外，這個請求只有當PORT_ENABLE位被設置，並且PORT_LINK_STATE沒有被設置為SS.Disabled, Rx.Detect或者SS.Inactive時有效。
- 如果該值為0，那么集線器應將鏈路狀態任何U狀態過渡到U0狀態。
- 如果該值為1，則主機軟件要想將鏈路過渡到U1狀態。該集線器應該試圖將鏈路從U0過渡到U1。當接收到具有值為1的請求時，如果鏈路處於除了U0之外的任意狀態，那么行為是不確定的。
- 如果該值為2，則主機軟件要想將鏈路過渡到U2狀態。該集線器應該試圖將鏈路從U0過渡到U2。當接收到具有值為2的請求時，如果鏈路處於除了U0之外的任意狀態，那么行為是不確定的。
- 如果該值為3，則主機軟件要想選擇性地掛起連接到這個端口上的設備。集線器應通過允許的鏈路狀態過渡方式，將鏈路從任意其他的U狀態過度到U3。如果端口不是已經處於U0狀態，那么它就應該將端口過渡到U0狀態，然后發起到U3的過渡。當這個狀態處於活躍時，集線器不傳導向下行的事務到這個端口，但是集線器還是會響應從該端口來的恢復信號。
- 如果該值為4(SS.Disabled)，集線器應該將鏈路轉換到SS.Disabled。該請求在此值為4時隨時都是有效的。當這個請求被接收到之后，下行端口應該過渡到DSPORT.Disabled狀態。
- 如果該值為5(Rx.Detect)，集線器應該將鏈路轉換到Rx.Detect。這個請求只有在下行端口處於DSPORT.Disabled狀態時菜有效。當具有這個值的請求被接收到時，如果鏈路處於其他狀態，則行為是不確定的。當這個請求被接收到之后，下行端口應該轉換到DSPORT.Disconnected狀態。
- 如果集線器在wIndex字段的高字節看到任何其他值，集線器應該用Request Error來響應。
當特性選擇子是PORT_REMOTE_WAKE_MASK，wIndex字段的most significant byte (bits 15..8)指定可以導致集線器在其上行端口上發起遠程喚醒事件的條件。遠程喚醒掩碼的編碼在下面給出：
表10-14. 下行端口遠程喚醒掩碼
比特Bit |
描述Description |
0 |
Conn_RWEnable 值 意義 0 集線器被禁止因一個在這個端口上的連接事件而發送遠程喚醒；在掛起過程中的連接事件還是必須要在恢復過程完成后（由於一些其他事件）被作為一個C_PORT_CONNECTION端口狀態改變而被檢測到並被報告。 1 集線器被使能因一個在這個端口上的連接事件而發送遠程喚醒。 |
1 |
Disconn_RWEnable 值 意義 0 集線器被禁止因一個在這個端口上的端口連接事件而發送遠程喚醒；在掛起過程中的連接事件還是必須要在恢復過程完成后（由於一些其他事件）被作為一個C_PORT_CONNECTION而被檢測到並被報告。 1 集線器被使能因一個在這個端口上的斷開連接事件而發送遠程喚醒。 |
2 |
OC_RWEnable 值 意義 0 集線器被禁止因一個在這個端口上的端口過流事件而發送遠程喚醒；在掛起過程中的連接事件還是必須要在恢復過程完成后（由於一些其他事件）被作為一個C_PORT_OVER_CURRENT而被檢測到並被報告。注意不支持基於每個端口而檢測和報告過流的集線器將對一個過流事件發送遠程喚醒，除非所有的端口的OC-RWEnable都被設為0. 1 集線器被使能因一個在這個端口上的過流事件而發送遠程喚醒。 |
3-7 |
這些位被保留並且必須設為0。 |
注意在上電或者在集線器被復位后，遠程喚醒掩碼被設為0（也就是，這些掩碼是被使能的）。
集線器一個滿足下面的要求：
- 如果端口處於Powered-off狀態，集線器應該將SetPortFeature(PORT_RESET)請求作為功能空操作對待。
- 如果端口處於Enabled狀態，集線器應該將SetPortFeature(PORT_LINK_STATE) U3請求作為功能空操作對待。
- 如果端口處於Powered-off狀態，集線器應該將SetPortFeature(PORT_POWER)請求作為功能空操作對待。
- 如果端口處於Enabled狀態，集線器應該將SetPortFeature(FORCE_LINKPM_ACCEPT)請求作為功能空操作對待。
當特性選擇子是BH_PORT_RESET，集線器應該在這個命令識別的端口上發起一個warm reset（參考7.3節）。在這個復位之后，端口的狀態應該與SetPortFeature(PORT_RESET)之后的狀態一樣。在完成一個BH_PORT_RESET時，集線器應該將該端口的PortStatus的C_BH_PORT_RESET字段設置為1.
如果wValue不是一個在表10-7中列出的特性選擇子，或者如果wIndex指定的端口不存在，或wLength不是如上所指定的值，那么就是Request Error。
如果集線器沒有被配置，集線器對這一請求的響應是不確定的。
10.15 主機根（下行）端口 【Host Root (Downstream) Ports】
在USB 3.0主機根端口和USB 3.0集線器下行端口具有類似的功能要求。本節概述哪些要求也適用於主機的根端口，並確定任何額外的或不同的要求。
主機根端口應遵循10.2節中的下行面集線器端口所需遵循的除10.2.3節之外的要求。
主機根端口應遵循10.3節中的下行面集線器端口所需遵循的要求，除了以下例外以及附加要求：
- 基於集線器上行口的轉換和/或過渡條件都不適用於根端口。
- 主機應該在主機接口內具有控制機制，對於響應SetPortFeature或ClearPortFeature請求，可以允許軟件達到與集線器下行端口的行為等同的行為。
- 主機應該實現端口狀態位，與第10.3節的集線器下行狀態描述一致。
- 主機被要求提供一個機制來將每個USB 2.0端口與任何的共享相同物理連接器的SuperSpeed端口進行關聯。注意這類似於10.3.3節對USB 3.0集線器的要求。
主機根端口應該遵循10.4節對下行面集線器端口的要求，具有在本節已經注意到的相同的通用例外。
主機應通過主機接口實現等同於本章定義的所有端口狀態位定義。
主機應具有機制以對其根端口實現正如在這一章提供的文檔所注釋的SetPortFeature，ClearPortFeature，以及GetPortStatus請求那樣等同的控制，。
10.16 外圍設備上行端口【Peripheral Device Upstream Ports】
周邊設備的上行端口有與USB 3.0集線器上行端口類似的功能需求。這一節概述哪些需求也適用於外圍設備的上行端口，並確定任何另外的或不同的需求。
10.16.1外圍設備上行端口 【Peripheral Device Upstream Ports】
一個周邊設備應該遵循第10.5節上行面集線器端口的需求，包括下列的例外和附加需求：
- 當端口處於USPORT.Connected狀態時，一個周邊設備不應該嘗試在USB 2.0接口上連接。
- 除非端口已經進入USPORT.Powered-off狀態，或者VBUS仍然如圖10-11一樣存在，否則一個周邊設備不應該嘗試在USB 2.0接口上連接。
- 如果一個設備被連接在USB 2.0接口上，而且它接收到一個USB 2.0總線復位，那么設備應該在tCheckSuperSpeedOnReset時間內進入USPORT.Powered-On狀態。
- 在一個 USB 2.0 復位之后，如果 SuperSpeed 端口進入USPORT.Training狀態，那么設備應該在tUSB2SwitchDisconnect時間內與USB 2.0接口斷開。
一個設備應該遵循在第 10.6 節中描述的上行面集線器端口的需求，包括下列的例外和附加需求：
- 沒有一種下行端口相關的情況適用。
- 當另外允許基於廠商特定的算法時，一個周邊設備開始到U1或U2的轉換。
10.16.2 外圍設備連接狀態機 【Peripheral Device Connect State Machine】
下列的章節提供狀態機的功能描述，展現了何時在 SuperSpeed 或 USB 2.0 上進行連接的正確的外圍設備行為。圖 10-25 是一外圍設備的示例狀態機。
10.16.2.1 PCONNECT.Powered-off
PCONNECT.Powered-off 狀態時默認的外圍設備狀態。如果任意下面的情形發生了，外圍設備應該轉換進入該狀態：
- 從任意狀態，當VBUS被去除時。
在本狀態，端口的鏈路應該處於SS.Disabled狀態，並且USB 2.0上拉沒有被應用。
10.16.2.2 PCONNECT.Attempt SS Connect
如果任意下面的情形發生了，端口應該轉換進入該狀態
- 從狀態，當VBUS變得有效（並且，如果需要的話，本地電源有效）。
在本狀態，SuperSpeed鏈路處於Rx.Detect或者Polling狀態，並且USB 2.0上拉沒有被應用。
10.16.2.3 PCONNECT.Connected on SS
如果任意下面的情形發生了，端口應該轉換進入該狀態
- 從PCONNECT.Attempt SS Connect，當鏈路從polling 轉換到U0。
- 從PCONNECT.Connected 在USB 2.0 狀態，當SS 鏈路從polling轉換到U0。
在本狀態，SuperSpeed鏈路處於U0, U1, U2, U3, Inactive, Rx.Detect, Recovery, 或者Polling狀態，並且USB 2.0上拉沒有被應用。
10.16.2.4 PCONNECT.Connected on USB 2.0
如果任意下面的情形發生了，端口應該轉換進入該狀態
- 從PCONNECT.Attempt SS Connect, PCONNECT.Connected on SS, 或者PCONNECT.Connected on USB 2.0 嘗試 SS 等狀態，如果 Rx.Detect or Polling 子狀態超時。
在本狀態，SuperSpeed鏈路處於SS.Disabled狀態，並且USB 2.0上拉被應用。
10.16.2.5 PCONNECT.Connected on USB 2.0 and Attempting SS Connection
如果任意下面的情形發生了，端口應該轉換進入該狀態
- 從PCONNECT.Connected on USB 2.0 狀態，當USB 2.0 復位被接收到時。
在本狀態，SuperSpeed鏈路處於Rx.Detect或者Polling狀態，並且USB 2.0上拉被應用。
當處於本狀態時，設備應該移除USB 2.0上拉，如果SuperSpeed鏈路從polling轉換到U0。
10.17 集線器章參數【Hub Chapter Parameters】
表 10-15 包含了一個在集線器一章的完整參數列表。
表 10-15. 集線器參數 【Hub Parameters】
參數名稱 |
描述 |
最小 |
最大 |
單位 |
tDownLinkStateChange |
從接收到一個導向到一個處於低功耗鏈路狀態的下行端口的頭包的路由字串開始，到在該下行鏈路上發起一個返回到U0的時間。 |
0 |
100 |
Ns |
sDataSymbolsBabble |
在一個數據包負載中的DPPSTART有續集之后，沒有任何數據包負載（Data Packet Payload）結束幀有續集，或者會導致設備檢測到該包是無效的DPPABORT有續集，在此期間經歷的的符號個數。 |
1030 |
N/A |
symbols |
tHubPropRemoteWakeUpstream |
從在集線器下行端口上開始遠程喚醒信號，到集線器必須在其上行端口上傳導該遠程喚醒信號（如果該上行端口鏈路處於U3），之間的時間。 |
0 |
1 |
ms |
tHubDriveRemoteWakeDownstream |
從在一個鏈路處於U3的端口上接收到一個SetPortFeature(PORT_LINK_STATE) U0的請求，到在該鏈路上驅動遠程喚醒信號，之間的時間。 |
0 |
1000 |
ns |
tHubPort2PortExitLat |
從下行端口的鏈路發起一個U狀態改變，到集線器必須在上行端口的鏈路上發起一個U狀態改變，之間的時間（當必要時）。 |
0 |
1 |
μs |
aCurrentUnit |
在集線器描述符中報告集線器控制器電路抽取電流的單位。 |
4 |
mA |
|
nMaxHubPorts |
USB 3.0集線器上最大的端口個數。 |
15 |
Ports |
|
tTimeForResetError |
在熱復位（warm reset）期間，如果下行端口鏈路保持在RxDetect.active狀態達這么長的時間，那么該復位被認為是已經失敗了。 |
100 |
200 |
ms |
tCheckSuperSpeedOnReset |
從一個設備（不是集線器）檢測到USB 2.0總線復位，到該設備端口必須進入USPORT.Powered-On狀態的時間 |
0 |
1 |
ms |
tUSB2SwitchDisconnect |
從一個設備（不是集線器）進入USPORT.Training狀態，到該設備必須斷開USB 2.0接口的時間（如果設備被連接在USB 2.0上）。 |
0 |
1 |
ms |
tPropagationDelayJitterLimit |
當一個被路由到鏈路處於U0的下行端口上的頭包最后的符號被再集線器的上行端口上接收到，和當該頭包的第一個符號被在集線器的下行端口上傳送，之間所需最小時間的變化。 對於所有傳送ITP的下行端口，ITP傳導應該滿足tPropagationDelayJitterLimit。 |
-0 |
+8 |
ns |
nSkipSymbolLimit |
在已傳送的SKP有續集之間的平均符號個數。 |
354 |
354 |
Symbols |