您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
《USB3.0协议规范(英文完整版)》.pdf475页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
文档加载中...广告还剩秒
需要金币：168 &&
《USB3.0协议规范(英文完整版)》.pdf
你可能关注的文档：
··········
··········
Universal Serial Bus 3.0
Specification
Intel Corporation
Microsoft Corporation
NEC Corporation
NXP Semiconductors
Texas Instruments Incorporated Revision 0.9 July 30, 2008
Universal Serial Bus 3.0 Specification, Revision 0.9
Revision History Revision Comments Issue Date 0.7 First consolidated review draft. October 19,
Updates to Chapters 6, 7, 8, 10, and 11. November 9,
Added Chapters 1, 3, and 12 and Appendixes A, B, and C. Updated December 26, 2007 Chapters 4, 5, 6, 7, 8, 10, and 11. 0.85 Moved content into Chapter 2 and Appendix C. Updated all other April 4, 2008 chapters except Appendixes A and B. 0.9RC1 Updated all chapters except Chapter 1 and Appendixes A and B. June 19,
Incorporated all approved SCRs July 30, 2008 INTELLECTUAL PROPERTY DISCLAIMER THIS SPECIFICATION IS PROVIDED TO YOU “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE. THE AUTHORS OF THIS SPECIFICATION DISCLAIM ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PROPRIETARY RIGHTS, RELATING TO USE OR IMPLEMENTATION OF INFORMATION IN THIS SPECIFICATION. THE PROVISION OF THIS SPECIFICATION TO YOU DOES NOT PROVIDE YOU WITH ANY LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS. NOTE: THIS IS A DRAFT SPECIFICATION.
The authors of this draft specification may make changes to it at any time, without notice. Product designers should not rely on the specification, and the authors shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes. Please send comments to usb3feedback@usb.org For industry information, refer to the USB Implementers Forum web All product names are trademarks, registered trademarks, or servicemarks of their respective owners. Copyright ? , HP, Intel Corporation, Microsoft Corporation, NEC Corporation, NXP Semiconductors, and Texas I
正在加载中，请稍后...USB 3.0规范中译本 第10章 集线器，主机下行口以及设备上行口规范 - CoryXie - 博客园
本文为原创译文，转载及有任何问题请联系。本章描述集线器的体系结构要求。本章还描述主机下行口和集线器下行口之间功能性的不同之处，以及设备上行口和集线器上行口之间的不同之处。本章包括三个主要的子模块的其中两个的描述：超高速集线器中继器转发器（）以及超高速集线器控制器（）。集线器子模块在Universal Serial Bus Specification, Revision 2.0中介绍。本章还描述了集线器对于错误恢复，复位，挂起/恢复，集线器请求行为的操作，以及集线器描述符。Universal Serial Bus Specification, Revision 2.0的集线器规范一章提供了实现者必要的信息来设计遵循规范的集线器。10.1 集线器特性总结[Hub Feature Summary]
集线器提供了设备和主机之间的电气接口。集线器直接负责提供使得用户友好的多种属性，将其复杂性从用户处隐藏起来。下面列出的是集线器支持的功能性的主要方面：连接性行为
设备连接和断开连接检测
总线错误检测和恢复
超高速和（高速，全速，以及低速）设备的支持
集线器包含一个集线器，以及一个由超高速集线器中继器转发器（）和超高速集线器控制器（）这两个主要部件组成的超高速集线器。集线器在规范中描述。后面所有的引用，如无特殊说明，均指超高速集线器的组件。集线器中继器转发器（）负责连结性的建立和拆除；也负责异常处理，例如总线错误检测和恢复，以及设备连接和断开连接检测。集线器控制器（）提供主机到集线器的通信的机制。集线器特定的状态和控制命令允许主机配置集线器，并监视和控制其单独的下行口。
图显示了一个端口集线器的高层次块状图，以及上行口和下行口的位置。集线器是两个集线器的逻辑组合：集线器和超高速集线器。每个集线器在独立的数据总线上独立操作。典型地，唯一的信号共享逻辑是对的控制。如果集线器或者超高速集线器需要，就会对一个下行口加电。集线器只要可能，就会尽量连接上行口的两个接口。所有报漏出来的集线器下行口都应该支持超高速和连结。主机控制器端口可能还有不同的要求。
图显示了集线器的包含超高速集线器中继器转发器（）和超高速集线器控制器（）的超高速部分。集线器的部分应该满足规范的所有要求，除非有特别的例外说明。集线器中继器转发器（）负责管理上行口和下行口之间的连结性，工作在超高速。集线器控制器（）提供状态和控制，允许主机访问超高速集线器。
当集线器上行口连接到只操作在高速或者全速的电气环境时，下行口连接的设备的超高速连结性不可用。不像外设，集线器要求将上行口连接到和两条总线上。对于集线器的下行端口，超高速连接可以在系统软件的控制下被使能或者禁能。如果集线器上行口的超高速连接不被该集线器所连接的端口所支持，集线器就会禁止掉所有下行口的超高速支持。如果集线器上行口没有连接到或者超高速端口上，那么集线器就不提供电源到其下行端口，除非其支持实现者论坛的电池充电（）规范。参考节关于何时集线器允许移除下行口的电源的详细讨论。规范允许自供电和总线供电的集线器。下面的章节介绍在不同类型的系统中，当主机系统加电之初，对于图所示的简单拓扑的典型的连接管理流程。注意：这些示例概述了系统如预期操作的情形，对于错误处理的情形在本章后面描述。
10.1.1 支持超高速的主机具有支持超高速的软件
当主机被断电，集线器不提供电源到下行口，除非集线器支持充电应用（参考节）。当主机被加电，并且使能了下行口的超高速支持，默认情况下有如下的典型事件序列：集线器检测到和超高速支持，并给其下行口加电并使能超高速集线器以超高速和高速设备同时连接设备检测到和超高速支持，以超高速设备连接主机系统开始以高速和超高速同时枚举集线器主机系统开始以超高速枚举设备10.1.2 USB 2.0主机
当主机被断电，集线器不提供电源到下行口，除非集线器支持充电应用（参考节）。当主机被加电，并且没有超高速的硬件支持，有如下的典型事件序列：集线器检测到和超高速支持，并以超高速设备连接主机系统以高速开始集线器枚举集线器被软件（）控制给下行口加电设备以高速连接主机系统开始以高速枚举设备10.1.3 集线器连接性 [Hub Connectivity]
集线器根据是否是在传导数据包头数据包负载交易（），其他的包交易，恢复信号（），或者是在空闲（）状态而展示不同的连接性行为。10.1.3.1 包信号连结性 [Packet Signaling Connectivity]
集线器中继器转发器包含一个应该总是在上行方向连接的端口（称为面向上行口），以及一个或者多个面向下行的端口。上行连结性定义为朝向主机，而下行连接性被定义为朝向设备。超高速集线器控制器包含对包头和数据的缓冲区。超高速集线器控制器不使用在中为高速连结性而使用的模式。这一改变允许多个下行设备同时发送异步消息而无数据丢失，并且，当有些交易（）被指向链路不处于状态的下行口时，会被存储之后传送。图显示了集线器上行和下行方向的高层级的信号连结性行为。后面的章节会对集线器内部缓冲机制和连结性作更多详细描述。集线器也有空闲（）状态，在此期间集线器没有连结性。当处于空闲（）状态时，所有的集线器端口（上行加下行）都处于，或者在接收或者发送逻辑空闲信号（），等待下一个包的开始。
如果下行口是使能的（即，处于可以通过集线器传导信号的状态），并且集线器在该端口检测到了包开始标志，即掀起就开始存储包头。当有效的头包（）被在一个下行口上接收到时，就会在该集线器的上行口建立起朝上行方向的连接性。集线器会将在下行口上接收到的头包向上行发送，但不会向其他的下行口发送。这就意味着当设备或者集线器向上行传送一个包时，只有连接发送设备和主机所在的一条直线上的集线器会看到该包。除了 Isochronous Timestamp 包以外的所有包在向下行方向上都是unicast；集线器使用一个直接连结性模型（）来操作。这就意味着当主机或者集线器向下行传送一个包的时候，只有在主机和接收者设备之间的一个直线上的那些集线器将会见到该包。当一个集线器在它的上行端口上检测包开始的时候，集线器就开始储存该包头。每当一个有效的头包已经在一个集线器上行端口上被收到的时候，该集线器就使用在该包头中的路由字串(Route String)（）和在枚举期间被分配的集线器深度值（），来建立仅仅到被指定的端口的连结性。如果该指定的端口没被使能，它就不向下行传导包信号。如果头包被路由到一个没被使能的下行端口，一个链路处于U3的端口, 或一个不存在的下行端口，集线器将默默地丢弃该头包。在这些情况下，集线器仍然将执行正常的对于该头包的链路层次的确认。
10.1.3.2 路由信息 [Routing Information]
在集线器上行端口上被收到的包，被基于包含在在该包头的一个20比特字段（路由字串(Route String)）信息而路由。路由字串(Route String)连同一个集线器深度值，被集线器用以为被指定到下行的包识别目标端口。集线器深度值被软件使用设置集线器深度（）请求来分配。集线器进入被配置状态之前，会忽略路由字串(Route String)，而假设所有的包是直接路由到该集线器自己。集线器上行端口将被端口号0来代表，而下行端口由1号端口开始，并循序地向上计数。每当一个集线器控制器以包含路由字串(Route String)的包回应一个路由给该集线器的包，或者源发一个包（除了集线器正在推后的包以外）时，集线器应该将路由字串(Route String)设置为零。
图 10-5 以五个层级的四端口USB 3.0集线器的一个示例拓扑举例说明了路由字串(Route String)的使用。对于每个层的集线器的集线器深度数值在图中被说明。在拓扑中的每个集线器以及每个设备都包含路由字串(Route String)，会被用来路由包到该集线器/设备。对于每个集线器深度，在该集线器深度决定路由目标的路由字串(Route String)的八位组（）以粗体和大小超过该路径串其余部分的较大的字型被显示。主机根端口没被包含在这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 结构允许在上行以及下行两方向上发生并发的事务。在图中，有两个数据包正在下行方向进行。集线器能同时储存多于一个数据包负载。在罕有的情形下，数据包负载由于缓冲不可用而被丢弃的时候，端到端协议将会藉由重试该事务而恢复。等时（）协议不包括重试。然而，在实际的物理总线上，丢弃错误被期望要比比特错误发生的频率少。
注意：数据包头以和其他的头一样的方式，被使用头包缓冲区储存和处理。DPPs 使用分开的数据缓冲区被处理。
10.2 集线器功耗管理 [Hub Power Management]
10.2.1 链路状态Link States
集线器必须要在所有的端口（上行以及下行）上支持以及状态。10.2.2 集线器下行端口U1/U2定时器[Hub Downstream Port U1/U2 Timers]
集线器必须在每一个下行端口上要有以及不活动定时器。值可以被编程，并且可以被主机软件设置。值为意味着定时器被禁止。的默认值为。在或者集线器上行口被时，所有的下行口以及的值都被复位到默认值。当街收到请求进行端口复位时，下行口以及的值也被复位到默认值。本章展示的下行口状态机描述以及的值被使能的时候得特定的操作规则。集线器下行端口应该接受由链路参与方（）发起的或者进入请求（），除非相应的被设置为，或者还有导向给该下行端口的事务交易。如果集线器已经在上行口接收到一个有效的包，并且这个包已经被路由到了一个下行口，那么集线器应该在该下行端口上拒绝链路进入或者的尝试，直到这个包已经被成功传输为止。如果集线器正在接收一个包但是还没有判定该包的目的地的时候，集线器也可以在该下行端口上拒绝链路进入或者的尝试。集线器的实现应该确保不存在竞争条件而导致一个没被推后的头包，被放入链路处于或正进入或的下行端口的队列准备传输。如果相应的值被设置为，集线器下行端口应该拒绝所有的以及进入请求。集线器以及不活动定时器不应该被等时时间戳包（）复位。
10.2.3 下行/上行端口链路状态转换 [Downstream/Upstream Port Link State Transitions]
集线器应该评估它的下行链路功耗状态，以便当上行端口没有处于等待状态的上行通讯（）的时候，它传导它的所有下行端口中的最高链路状态到它的上行端口。U0 是最高链路状态，接着是 U1, 然后 U2, 然后 U3, 然后 ，然后 SS.Disabled。如果一个上行端口链路状态转换会导致进入已经被软件禁止的上行端口链路状态，集线器将转换该上行端口链路进入下一个最高的被使能的U状态。集线器绝不会自动地尝试转换集线器上行端口到U3.在这一章节中所呈现的下行端口状态机，提供并满足了根据下行端口链路状态的变化而改变上行端口链路状态的特定的时序要求。
每当集线器接收到一个包，被路由到不处于U0的下行端口的时候，集线器也应该在适当的下行端口上发起一个链路状态转换。在这一章节中所呈现的集线器上行端口状态机，提供并满足了对于这些转换的特定的时序要求。如果被使能，端口状态变化中断，例如，由于下行端口上的连接事件，将会导致上行链路发起到U0的转换。
10.3 集线器下行面端口[Hub Downstream Facing Ports]
下面章节提供了一个状态机的功能描述，该状态机对于下行端口显示了正确的必要的行为。图 10-9 显示了下行面端口状态机。每一个状态在第 10.4.2 节描述。在下面的图表中，一些进入状态的进入条件没有显示起始状态。这些条件有多个起始状态，并且这些单独的转换线没被显示，以简化图表。对于所进入的状态的描述会指示从那些状态转换而来是可适用的。
注意：对于根集线器，从上行面端口的状态机来的信号依赖于特定的实现（）。10.3.1 集线器下行面端口状态机描述[Hub Downstream Facing Port State Descriptions]
10.3.1.1 DSPORT.Powered-off
状态是逻辑电源关闭状态。在状态下，集线器可能还是会被要求或者选择乡下行端口提供。对于存在的详细要求在本节后续描述。如果下面任意情形发生，端口应该转换到该状态：从任意状态，当集线器接收到请求时。在这种情形下，电源仅在下面条件满足时会从端口上移除：不会影响集线器的任意下行口上的低速，全速，或者高速操作，也不会影响除了目标端口之外的其他端口的超高速（）操作。从任意状态，当端口丢掉本地电源或者发生过流情形。从任意状态，当从集线器上行口上被移除。从任意状态，如果集线器上行端口链路转换到状态。从任意状态，如果集线器上行端口链路已经连续次事件而没有检测到远端接收器终端阻抗（）。从任意状态，如果集线器上行端口接收到一个请求。在此情形下，下行端口保持在状态。不论其他条件如何，直到集线器被复位，或者集线器上行口接收到非的请求。非的请求之后，遵循正常的状态机规则。如果由于一个在其他端口上的过流情形，并且该过流情形可能已经导致提供给本端口的电源下降到规定的极限值以下，那么端口会进入状态。如果集线器在本地电源存在的情形下被配置，而此后本地电源丢掉了，如果电源尚可以用来运行集线器控制器的话，集线器应该将所有的端口置于状态。在状态，端口的链路处于状态。表 10-1 显示了集线器下行端口允许的 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)连接)
这是本地电源有效时（）或者变得有效时（）的默认状态。端口在下面的任意情形下转换进入本状态：从状态，当集线器收到请求时。从除了状态的任意状态，当端口检测到一个断开连接事件。从状态，当集线器的上行口的链路从转换到状态。从状态，当端口的链路在复位期间从状态超时。从状态，当端口接收到一个请求。从状态，如果端口的链路在复位期间从任意状态超时。从状态，如果端口的链路从任意状态超时。从状态，如果端口链路在状态中执行了一次成功的握手。在本状态，端口的链路应该处于状态。注意：如果集线器的上行端口的链路处于，端口的链路应该还是要以状态正常执行连接检测。10.3.1.3 DSPORT.Training
当检测到远端接收器终端阻抗（）时，端口从状态转换到本状态。在本状态，端口的链路应该处于状态。10.3.1.4 DSPORT.ERROR
只有当能支持SuperSpeed的设备存在，并且在尝试操作该链路的时候发生了严重的错误条件的时候，端口才会转换至本状态。。
端口在下面的任意情形下转换进入本状态：从状态，如果端口链路要进入恢复（）但是还没有恢复就超时了。从状态，如果或者失败。从状态，如果端口是，但是的握手失败了。从状态，如果如所述那样失败了。在本状态，端口的链路应该处于状态。10.3.1.5 DSPORT.Enabled
端口在下面的任意情形下转换进入本状态：从DSPORT.Training状态，当端口链路成功进入。从状态，当复位操作成功完成。处于状态的端口可以在上行和下行两个方向传导包。在或者之后，当集线器下行端口首次转换到状态，集线器应该传送一个定义于节中的端口配置。在之后，当集线器下行端口首次转换到状态，以及不活动定时器应该被复位到。当进入状态后，链路应该处于。如果在下行端口进入状态是，集线器的上行端口的链路处于，并且集线器没有使能，那么下行端口应该在时间内，在其链路上发起一次到的转换。第 10.4 节提供了一个状态机，该状态机显示了一个功能性正确的实现，用于下行端口在状态下管理不同的链路状态。
10.3.1.6 DSPORT.Resetting
除非端口正处于或者状态，否则当接收到或者请求后，下行端口应该转换进入状态。如果下行端口正处于或者状态，并且接收到一个请求，该请求就会被忽略。如果端口状态是，并且接收到一个或者请求，端口应该在时间内在下行端口链路上发送一个。当接收到一个请求时，如果端口状态处于，而端口链路处于除了之外的任意状态，该端口应该在时间内在其链路上发起一次。如果端口接收到一个请求，端口应该在时间内在其链路上发起一个。注意：如果端口在其链路上发起了一次，而的握手失败了，就会自动尝试。参考一章关于这一过程的细节。该端口在这一过程中保持在状态，直到完成。在过程中，当下行端口链路进入状态，集线器应该启动一个计时器来对处于状态计时。如果这个计时器在链路处于状态超过时间，端口应该转换到状态。10.3.1.pliance
端口在下面的任意情形下转换进入本状态：当链路进入状态。
10.3.1.8 DSPORT.Loopback
端口在下面的任意情形下转换进入本状态：从DSPORT.Training状态，如果在接收到的有序集（）中的被设置。在此状态，端口的链路应该处于状态。10.3.1.9 DSPORT.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.4.2 节描述。在图 中，一些进入某状态的进入条件没有显示其起始状态。这些条件有多个起始状态，并且这些单独的转换线没被显示，以简化图表。对于所进入的状态的描述会指示从那些状态转换而来是可适用的。
10.4.1 下行面端口PM定时器 [Downstream Facing Port PM Timers]
每个下行面端口都维护了逻辑不活动定时器，用于跟踪何时以及超时值超时。或超时值可以随时被软件用或命令设置。这些定时器每当接收到或请求时被复位到。每当除了等时时间戳包之外的任意包被端口的链路发送或者接收到时，这些定时器都应该被复位。定时器应该有的精确度。定时器应该有的精确度。其他的对于定时器的要求在下行端口的状态机的描述中被定义。10.4.2 集线器下行面端口状态机描述 [Hub Downstream Facing Port State Descriptions]
10.4.2.1 Enabled U0 状态 [Enabled U0 States]
有个状态，他们只在被配置的和超时值方面有不同。针对不同的和超时值的端口行为如下：这是集线器在接收到任何之前端口的默认状态。端口的链路应该拒绝链路对方发起的所有到或的转换请求。定时器可以被禁止，并且定时器值应该被忽略。端口的链路不应该尝试发起到或的转换。端口的链路应该拒绝链路对方发起的所有到的转换请求。当进入并且活跃在本状态时，定时器应该被复位。端口的链路应该接受链路对方发起的到的转换请求，除非集线器还有一个或者多个包链路命令要在该端口上传送。如果超时值是，端口应该被禁止发起进入，但是应该接受链路对方发起的到的转换请求，除非集线器还有一个或者多个包链路命令要在该端口上传送。如果超时值不是，并且定时器达到了，端口的链路应该发起一次到的转换。端口的链路应该拒绝链路对方发起的所有到的转换请求。当进入并且活跃在本状态时，定时器应该被复位。端口的链路应该接受链路对方发起的到的转换请求，除非集线器还有一个或者多个包链路命令要在该端口上传送。如果超时值是，端口应该被禁止发起进入，但是应该接受链路对方发起的到的转换请求，除非集线器还有一个或者多个包链路命令要在该端口上传送。如果超时值不是，并且定时器达到了，端口的链路应该发起一次从到的直接转换。在这种情形下，代表在状态的不活动时间长度。当进入并且活跃在本状态时，定时器应该被复位。端口的链路应该接受链路对方发起的到或者的转换请求，除非集线器还有一个或者多个包链路命令要在该端口上传送。如果超时值是，端口应该被禁止发起进入，但是应该接受链路对方发起的到的转换请求，除非集线器还有一个或者多个包链路命令要在该端口上传送。如果超时值不是，并且定时器达到了，端口的链路应该发起一次到的转换。如果超时值是，端口应该被禁止发起进入，但是应该接受链路对方发起的到的转换请求，除非集线器还有一个或者多个包链路命令要在该端口上传送。在下列任意情形下，端口就会转换到其中一个状态（依赖于和超时值）：从任意状态，如果集线器接收到了请求。从状态，如果链路对方成功发起了一次到的转换。从状态，如果链路对方成功发起了一次到的转换。从状态，如果集线器在接收到一个路由到该端口的包之后，成功发起了一次到的转换。从状态，如果集线器在接收到一个路由到该端口的包之后，成功发起了一次到的转换。从一次想要从状态转换到状态的尝试，如果下行端口的链路对方拒绝这一转换请求。从一次想要从状态转换到状态的尝试，如果下行端口的链路对方拒绝这一转换请求。从状态，如果集线器的上行端口接收到了信号，并且正在被转换的集线器下行端口在的时候已经接收到了信号。从状态，如果集线器下行端口的链路对方发起了信号，而上行集线器的端口链路不处于。注意：参考节中下行口链路对方发起信号情形的细节。10.4.2.2 尝试 U0到U1转换 [Attempt U0 – U1 Transition]
在本状态，端口尝试将其链路从状态转换到状态。在下列任意情形，端口应该尝试转换到状态：定时器达到了超时值。集线器接收到一个请求。下行端口的链路对方发起了一次到的转换。如果转换尝试失败，端口返回到恰当的状态。然而，如果本状态是由于一个请求而进入的，端口会继续在其链路上的从到转换的尝试。注意：请求典型的只被用来在测试目的下进入。10.4.2.3 Attempt U0 – U2 Transition
在本状态，端口尝试将其链路从状态转换到状态。在下列任意情形，端口应该尝试转换到状态：定时器达到了超时值。集线器接收到一个请求。下行端口的链路对方发起了一次到的转换。如果转换尝试失败，端口返回到恰当的状态。然而，如果本状态是由于一个请求而进入的，端口会继续在其链路上的从到转换的尝试。注意：请求典型的只被用来在测试目的下进入。10.4.2.4 U1状态的链路 [Link in U1]
每当一个下行口进入，并且所有的下行口现在都处于状态或者更低的功耗状态，如果集线器的上行端口对于是使能的（），集线器应该在时间内，在其上行端口上发起一次到的转换。当链路进入时，定时器被复位到并被启动。如果超时值不是，并且定时器达到了，端口的链路应该发起一次从到的直接转换。在这种情形下，代表在状态的不活动时间长度。每当一个下行端口或者其链路对方发起一次从到其中一个状态的转换，但是上行端口不处于状态，集线器都应该从这个转换在下行端口被启动之后的时间内，在上行端口上发起一次到的转换。如果上行端口已经在状态，当下行端口转换到时，它应该保持在状态。10.4.2.5 U2状态的链路 [Link in U2]
当下行端口进入 U2 时，适用于下列各项规则:
如果所有的下行端口现在处于U2或者更低的功耗状态，如果上行端口对U2是使能的（），集线器应该在时间内，在上行端口上发起到U2的转换。如果U2在上行端口上不被使能，但是U1是被使能的，集线器应该在相同的时序要求下发起到U1的一次转换。
如果所有的下行端口现在处于U1或者更低的功耗状态，如果上行端口对U1是使能的（），集线器应该在时间内，在上行端口上发起到U1的转换。
每当一个下行端口或它的链路对方发起从U2到其中一个状态的转换而集线器上行端口不处于U0时:如果集线器的上行端口链路处于U2，从这个转换在下行端口被启动之后的时间内，集线器应该在上行端口的链路上发起一次到的转换。
如果集线器的上行端口链路处于U1，从这个转换在下行端口被启动之后的时间内，集线器应该在上行端口的链路上发起一次到的转换。
10.4.2.6 U3状态的链路 [Link in U3]
当下行端口进入U3时，适用于下列各项规则:
如果所有的下行端口现在处于U2或者U3, 集线器应该在上行端口上，在时间内，发起到U3以上被使能的最低功耗状态的一次转换。
如果所有的下行端口现在处于U1或者更低的功耗状态，如果上行端口对U1是使能的（），集线器应该在时间内，在上行端口上发起到U1的转换。
参考10.3.1.5节关于从状态只转换到U3状态的详细描述。
注意：如果集线器的上行端口接收到一个被路由到一个处于U3的下行端口的包, 这个包会被默默地丢弃。在这情况下，集线器将执行正常的链路层级头包的确认。
10.5 Hub Upstream Facing Port
下面章节提供了一个状态机的功能描述，该状态机对于集线器上行面端口显示了正确的行为。这些章节也适用于设备的上行面端口，除非在不适用处将做出特别的说明。上行口应该只尝试如后续节中所描述的上行端口状态机那样来连接到以及接口。图
显示了上行面端口状态机。每一个状态在第
节描述。在图中，一些进入某状态的进入条件没有显示起始状态。这些条件有多个起始状态，并且这些单独的转换线没被显示，以简化图表。对于所进入的状态的描述会指示从那些状态转换而来是可适用的。
10.5.1 上行面端口状态描述 [Upstream Facing Port State Descriptions]
10.5.1.1 USPORT.Powered-off
状态是上行面端口的默认状态。下列任意情形发生，端口应该转换进入本状态：从任意状态，当被移除。从任意状态，如果远端接收器中断阻抗（）没有被检测到。从状态，如果过程失败。在本状态，断口的链路应该处于状态。10.5.1.2 USPORT.Powered-on
端口在下面的任意情形下转换进入本状态：
从状态，当变得有效。从状态，当链路接收到一个。从状态，当链路接收到任意的。从状态，当链路接收到任意的。从状态，如果端口的链路从状态超时。在本状态，端口的链路应该处于状态。当在本状态中，如果集线器的部分进入了状态，集线器从抽取的总电流应该满足电流限制。10.5.1.3 USPORT.Training
当远端接收器中断阻抗（）被检测到时，端口从状态转换进入本状态。在本状态，端口的链路应该处于状态。10.5.1.4 USPORT.Connected
当端口的链路从状态进入状态时，端口从状态转换进入本状态。在本状态，端口的链路应该处于或状态。当链路进入状态，端口开始节定义的端口配置过程。当处于状态时，端口可以发送链路管理包或链路命令，但是不应该传送除了响应默认的控制端点请求之外任意其他的包。10.5.1.5 USPORT.Error
当尝试操作链路，发生严重的错误情形时，端口转换进入本状态。端口在如下任意情形下，转换进入本状态：从状态，如果链路进入但是还没有恢复就已经超时。从状态，如果链路进入但是还没有恢复就已经超时。在本状态，端口的链路应该处于状态。端口只有在链路上接收到后才退出状态。10.5.1.6 USPORT.Enabled
当请求被接收到，并且的状态阶段的响应已经被发送并被在链路层级成功确认时，端口从状态转换进入本状态。在本状态，端口的链路应该处于或者状态。当在状态，端口可以发送任意类型的包。当进入状态时，链路应该处于状态。10.5.2 集线器连接状态机 [Hub Connect State Machine]
下面的章节提供了一个状态机的功能性描述，展示了当连接到或时正确的集线器行为。对于集线器而言，和的连接逻辑是完全独立的。对于上的连接，集线器应该依照规范。图是的集线器连接状态机。节描述每一个状态。
10.5.2.1 集线器连接状态描述 [Hub Connect State Descriptions]
10.5.2.2 HCONNECT.Powered-off
状态是集线器设备的默认状态。如果发生了下列情形，集线器设备应该转换进入本状态：从任意状态，当被移除。在本状态，集线器上行端口应该处于状态。10.5.2.3 HCONNECT.Attempt SS Connect
如果发生了下列任意情形，集线器设备应该转换进入本状态：从状态，当变得有效并且如果必要，本地电源有效。从状态，如果或者超时。在本状态，集线器上行端口链路应该处于或状态。10.5.2.4 HCONNECT.Connected on SS
如果发生了下列情形，集线器设备应该转换进入本状态：从状态，当链路从转换到。在本状态，集线器上行端口链路处于或者状态。10.6 上行面端口功耗管理 [Upstream Facing Port Power Management]
下面章节提供了一个状态机的功能描述，该状态机对于上行面端口显示了正确的链路功耗管理行为。图
显示了上行面端口功耗管理状态机。每一个状态在第 10.4.2 节描述。在图 中，一些进入某状态的进入条件没有显示其起始状态。这些条件有多个起始状态，并且这些单独的转换线没被显示，以简化图表。对于所进入的状态的描述会指示从那些状态转换而来是可适用的。
如果在任何下行端口有状态改变，如果上行端口处于U1或U2的话，集线器应该在上行端口的链路上发起一次到U0的转换。
如果在任何下行端口有状态改变，并且集线器上行口处于U3状态，集线器的行为由当前的远程唤醒掩码设置（）来指定。参考节中更多的细节。
10.6.1 上行面端口PM定时器 [Upstream Facing Port PM Timer]
集线器上行口维护了一个逻辑PM定时器，用来跟踪何时U2不活动超时值被超过了。没有定义标准的U1不活动超时值。U2不活动超时值在接收到时被设置。当集线器上行端口链路进入U1时，该PM定时器被复位。该PM定时器应该有的精确度。其他的对于该定时器的要求在上行口的状态机的描述中被定义。
10.6.2 集线器上行面端口状态机 【Hub Upstream Facing Port State Descriptions】
10.6.2.1 Enabled U0 状态【Enabled U0 States】
有种状态，他们只在以及设置方面有所不同。下面的规则对于所有的状态全局适用。如果还有包需要在上行端口上传输，则上行端口不能发起到或的转换。如果比特被设置为参考节，那么上行端口应该接受到或的转换。对于以及值的不同组合，端口的行为如下：这是集线器在接收到任意的请求之前的默认状态。定时器可以被禁止，并且定时器值应该被忽略。端口的链路应该接受其链路对方的进入请求，除非集线器已经有一个或者多个包或者链路命令要在该端口上发送，或者该集线器的一个或者多个下行端口的链路处于或者恢复状态。端口的链路应该接受其链路对方的进入请求，除非集线器已经有一个或者多个包或者链路命令要在该端口上发送，或者该集线器的一个或者多个下行端口的链路处于，或者恢复状态。端口的链路不应该尝试发起到或者的转换。端口的链路不应该尝试发起到的转换。端口的链路应该接受其链路对方的进入请求，除非集线器已经有一个或者多个包或者链路命令要在该端口上发送，或者该集线器的一个或者多个下行端口的链路处于，或者恢复状态。端口的链路应该接受其链路对方的进入请求，除非集线器已经有一个或者多个包或者链路命令要在该端口上发送，或者该集线器的一个或者多个下行端口的链路处于或者恢复状态。定时器可以被禁止，并且定时器值应该被忽略。如果集线器所有的下行端口都处于或者更低功耗的链路状态，端口的链路应该发起到的转换。端口的链路不应该尝试发起到的转换。端口的链路应该接受其链路对方的进入请求，除非集线器已经有一个或者多个包或者链路命令要在该端口上发送，或者该集线器的一个或者多个下行端口的链路处于或者恢复状态。端口的链路应该接受其链路对方的进入请求，除非集线器已经有一个或者多个包或者链路命令要在该端口上发送，或者该集线器的一个或者多个下行端口的链路处于，或者恢复状态。定时器可以被禁止，并且定时器值应该被忽略。如果集线器所有的下行端口都处于或者更低功耗的链路状态，端口的链路应该发起到的转换。端口的链路应该接受其链路对方的或者的进入请求，除非集线器已经有一个或者多个包或者链路命令要在该端口上发送。
如果该集线器的一个或者多个下行端口的链路处于或者恢复状态，进入请求不应该被接受。如果该集线器的一个或者多个下行端口的链路处于或者恢复状态，进入请求不应该被接受。如果集线器所有的下行端口都处于或者更低功耗的链路状态，端口的链路应该发起到的转换。定时器可以被禁止，并且定时器值应该被忽略。端口在如下任一情形下，就会转换进入其中一个Enabled U0状态（依赖于U1或者U2 Enable值而定）：
从U1，如果链路对方成功发起了一次到U0的转换。
从U2，如果链路对方成功发起了一次到U0的转换。
从U1，如果在一个下行端口上有状态改变。
从U2，如果在一个下行端口上有状态改变。
从U1，如果集线器下行端口的链路发起了一次到U0的转换。
从U2，如果集线器下行端口的链路发起了一次到U0的转换。
从一次想要从U0转换到U1的尝试，如果上行端口链路对方拒绝该次转换尝试。
从一次想要从U0转换到U2的尝试，如果上行端口链路对方拒绝该次转换尝试。
从U3，如果集线器上行口接收到了wakeup信号。
从U3，如果在一个下行端口上有状态改变，或者本地电源状态改变，并且相应于该事件类型的远程唤醒（）被使能。
10.6.2.2 尝试U0-U1转换 【Attempt U0 – U1 Transition】
在本状态，端口尝试将其链路从状态转换到状态。在如下任一情形下，端口应该尝试转换到状态：被链路对方请求进入U1，并且在该端口上没有未完成事务交易，并且集线器所有的下行端口都处于U1或者更低的功耗状态。
集线器所有的下行端口都处于U1或者更低的功耗状态，并且在上行端口上没有等待传输的事务交易，并且被设置为1。
被链路对方请求进入U1，并且比特被设置。
如果转换尝试失败（接收到一个或者链路进入恢复状态），端口将返回到恰当的状态。
10.6.2.3 尝试U0-U1转换 【Attempt U0 – U2 Transition】
在本状态，端口尝试将其链路从状态转换到状态。在如下任一情形下，端口应该尝试转换到状态：被链路对方请求进入U2，并且在该端口上没有未完成事务交易，并且集线器所有的下行端口都处于U2或者更低的功耗状态。
集线器所有的下行端口都处于U2或者更低的功耗状态，并且在上行端口上没有等待传输的事务交易，并且被设置为1。
被链路对方请求进入U2，并且比特被设置。
如果转换尝试失败（接收到一个或者链路进入恢复状态），端口将返回到恰当的状态。
10.6.2.4 处于U1的链路 【Link in U1】
当进入并活动于本状态时，定时器被复位。端口应该转换进入：当发送一个，接受一个由链路对方发起的转换之后。
当在发起一次转换该链路进入的尝试后，从链路对方接收到一个之后。
如果不活动计时器超时值不是或者，并且定时器达到不活动计时器超时值，端口链路应该发起一次从到的转换。10.6.2.5 处于U2的链路 【Link in U2】
链路处于。端口应该转换进入：当发送一个，接受一个由链路对方发起的转换之后。
当在发起一次转换该链路进入的尝试后，从链路对方接收到一个之后。
10.6.2.6处于U3的链路 【Link in U3】
链路处于。端口应该转换进入：当发送一个，接受一个由链路对方发起的转换之后。
10.7 集线器头包转发和数据中继器【Hub Header Packet Forwarding and Data Repeater】
集线器对头包使用存储转发模型，对数据使用中继器模型，联合提供了如下的总体功能性：在下行方向上：验证头包建立起到选择的下行端口的连接转发头包到下行端口转发数据负载到下行端口，如果有的话在包边界处建立和断开连接性在上行方向上：验证头包建立起到上行端口的连接转发头包到上行端口转发数据负载到上行端口，如果有的话在包边界处建立和断开连接性
10.7.1 集线器弹性缓冲区 【Hub Elasticity Buffer】
没有对集线器内部的弹性缓冲区进行直接的规定。但是，注意，集线器必须满足小节对于头包从集线器上行端口转发到下行端口的最大可变传导时延的要求。10.7.2 SKP有序集 【SKP Ordered Sets】
对于所有的传输，集线器都需要按照第章中对于所有的发送器的规则，发送有序集。10.7.3 包间距 【Interpacket Spacing】
当集线器源发或者转发包时，数据包头以及数据包负载应该如小节那样，被始终连续地发送。当集线器转发头包到下行，并且当该头包在集线器上行端口被接收到时，下行端口的链路处于，那么传导时延的变数不应该超过。10.7.4 头包缓冲区结构 【Header Packet Buffer Architecture】
本规范不要求集线器内部的头包缓冲区的特定结构。满足本规范的功能性要求的结构实例被显示在图和图中，示例了集线器的功能性行为。图显示了一个集线器，在上行端口上拥有个头包缓冲，在每个下行端口上有个头包缓冲。图显示了每个下行端口上有个头包缓冲，并且在上行端口上拥有个头包缓冲。在图和图中显示的缓冲区都是独立的物理缓冲区。下面列出集线器缓冲区结构的功能性要求，在每种情况下，都假设只有集线器上被指示的端口在接收或者发送头包：以所有的头包缓冲区都清空开始的集线器，在其上行端口的头包流量控制信用值（）用完之前，至少应该能够接收个定向到同一个不处于状态的下行端口的头包。在其上行端口上接收到一个应该被路由到一个下行端口的头包的集线器，应该立刻将该头包路由到适当者的下行端口头包缓冲区（如果该缓冲区的空间可用），不管任何其他下行端口头包缓冲区的状态如何，也不管上行端口Rx头包缓冲区状态如何。举例来说，一个集线器的下行端口1的Tx头包缓冲区是满的，而且集线器上行Rx头包缓冲区有另外三个头包要被路由下行端口1。如果该集线器现在接收到一个头包要被路由到下行端口2, 它必须立刻路由该头包到该下行端口2的Tx头包缓冲区。
以所有的头包缓冲区都清空开始的集线器，在上行端口不处于状态时，至少应该能够接收同一下行端口上的个头包，定向用于向上行传输。被下行端口传输的头包应该以它们在上行端口上被收到的顺序传输。
从相同的下行端口上来的，被上行端口传输的头包，应该以它们在从该下行端口上被收到的顺序传输。
第 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
在状态上行端口发送器在积极传送符号。端口应该在如下任一情形下转换进入状态：从或状态，在任何必要的有序集被传送之后。从状态，在传送一个链路命令并且没有其他的链路命令正等待传送之后。作为进入时的默认状态。发送器应该在必要时如第 7 章所描述那样传送LUP。当传送的符号计数达到 nSkipSymbolLimit 的时候， 一个SKP有序集应该被传送，并且已传送符号计数应该被复位归零。
10.7.6.2 Tx Header
在 状态中，上行端口发送器正在积极地传送一个头包。注意：集线器不应该用 DPPABORT 有序集中止（）头包的传输。在如下任一情形下，端口应该转换到状态：从状态，当有一个或者多个头包被排队准备传输，但是没有链路命令被被排队准备传输时。在传送任何头包的结尾（除了具有数据包负载的数据包头包以外），当已传送符号计数超过或等于nSkipSymbolLimit，一个SKP有序集应该被传输，而且已传送符号计数应该被减少nSkipSymbolLimit个。
10.7.6.3 Tx Data
在 状态中，上行端口发送器正在积极地传送一个数据包负载。在传送数据包负载的最后的分帧符号以及必要的SKP有序集之后，端口可以将数据负载包从集线器的储存缓冲中移除。在任何的境况之下，集线器都不应该重传DPP包。
当有数据包负载与被传输了的数据包头相关联时，端口应该从状态转换到状态。数据包负载量传输应该在传输数据包头的最后一个符号之后立刻开始。在传送没被中止（）的数据包负载结束的时候：当已传送符号计数超过或者等于nSkipSymbolLimit时，一个SKP有序集应该被传输，并且已传送符号计数应该被减少nSkipSymbolLimit个。
该序列被重复，直到符号计数少于nSkipSymbolLimit。
10.7.6.4 Tx Data Abort
在状态，上行端口发送器藉由传送DPPABORT有序集以及必要的SKP有序集，中止数据包负载的正常传输。然后，端口从集线器储存中移除数据包负载。当接收数据包负载的下行端口接收到DPPABORT有序集的时候，或者已经接收到sDataSymbolsBabble个符号而没有接收到有效的DPPEND有序集或DPPABORT有序集的时候，端口应该从状态转换到状态。在传送DPPABORT有序集结束的时候：当已传送符号计数超过或者等于nSkipSymbolLimit时，一个SKP有序集应该被传输，并且已传送符号计数应该被减少nSkipSymbolLimit个。
该序列被重复，直到符号计数少于nSkipSymbolLimit。
10.7.6.5 Tx Link Command
在状态中，上行端口发送器正在积极地传送一个链路命令。如果多个链路命令要在状态被排队传输，他们应该无间隙地被传输，除非SKP有序集被传输。在下列的任一情形下，端口应该转换到状态：从状态，当有一个或多个链路命令被排队准备传输时候。从状态，当有另外的链路命令被排队准备传输的时候。在传送任何的链路命令结束的时候，若已传送符号计数超过或者等于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
在状态中，上行端口接收器正在积极地处理已接收到的符号，并寻找DPPSTART有序集， HPSTART有序集，或LCSTART有序集的分帧符号，来开始接收一个包或链路命令。
如果DPPStart有序集被收到，但是其不紧随一个DPH，它就会被忽略，而且端口接收器停留在状态。在下列任何情形下，一个端口应该转换到状态：从状态，当有序集或者有序集被接收到时。
从状态，当一个头包的最后一个符号被收到时。
从状态，当达到，都没有收到一个有序集或者有序集。
在接收到一个链路命令之后。
作为链路进入U0之后的默认状态。
10.7.8.2 Rx Data
在状态中，上行端口接收器正在积极地处理已经接收到的符号，并寻找DPPEND有序集或 DPPABORT有序集。当进入本状态的时候，接收器应该从零开始对已经接收到的符号进行计数。被计算的第一个符号是DPPSTART有序集后的第一个符号。当端口接收到有效的DPPSTART有序集的时候，它应该转换到状态。当在如第 7.2.4.1.6 节所定义的DPP结束之前，端口检测到一个错误的时候，只有在它已经在适当的下行端口上传输完已经接收到的 DPP（包括DPPABORT有序集）之后，它才可能清除它的缓冲区中的数据。当一个错误被检测到的时候，集线器应该在传送数据包负载错误（被跟随一个DPPABORT有序集）前，在适当的下行端口上传送有效的已经接收到的符号。注意，即使集线器在下行端口上开始传送DPP之前，集线器检测到一个错误，这一个要求也适用。集线器应该有至少1080字节缓冲区用于在上行端口上接收到的数据包。
10.7.8.3 Rx Header
在状态中，上行端口接收器正在积极地处理已经接收到的符号,直到最后一个头包符号被接收到。当进入这状态的时候,接收器应该从零开始一个对已经接收到符号的计数。被计算的第一个符号是HPSTART有序集后的第一个符号。当端口接收到有效的HPSTART有序集的时候，它应该转换到状态。端口应该在头包的最后一个符号被接收到之后的四个符号时间内，完成验证CRC-16，链路控制字CRC-5，并且检查路由字串和头包类型。
实现者可能必须要在接收到符号时就开始计算，在头包被验证之前就开始检查路由字串，来满足这一要求。10.7.8.4 处理头包 【Process Header Packet】
当一个头包的最后一个符号被接收到的时候,端口应该对该头包执行所有必要附加处理。任何的此类处理都不应该阻碍端口立刻返回到状态，并继续处理已经接收到的符号。
在如下任一情形下，端口要对头包执行附加的处理。附加的处理步骤被描述在每种情形中。
当最后一个头包符号在状态被接收到，并且头包CRC-16以及链路控制字CRC-5被判定有效的时候，适当的LGOOD_n链路命令就会被该接收端口排队准备传输。然后，如果上行端口 Rx 头包缓冲区至少有四空闲的槽位（），适当的 LCRD_x 链路命令应该被上行端口排队准备传输。否则，一旦用于该头包的Rx头包缓冲区槽位可用，这个适当的 LCRD_x 链路命令就会被排队准备传输。注意：一个集线器实现可以在一个Rx头包缓冲区中选择提供超过四个储存槽位。
—如果头包被路由到不处于U0的下行端口 (而且头包不是ITP）：