USB 3.0规范中译本 第10章 集线器，主机下行口以及设备上行口规范
原文地址 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 |
保留 |