USB 3.0規范中譯本第8章協議層

本文轉載自查看原文 2014-09-04 16:21 3593 Connectivity

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

協議層管理設備及其主機之間端到端的數據流。這一層建立在鏈路層提供對某些類型的包的保證傳輸（guarantees delivery of certain types of packets）的假設基礎上；本層基於傳輸類型，增加了對其余類型的數據包的端到端傳輸的可靠性（end to end reliability for the rest of the packets）。

本章詳細描述了以下內容：

數據包類型（Types of packets）
數據包格式（Format of the packets）
對由主機和設備發送的數據包的預期反應（Expected responses）
4個超高速事務類型（SuperSpeed transaction types）
支持對流批量傳輸類型（Streams for the bulk transfer type）
主機或設備可能會收到或發送的各種響應和包的時序參數（Timing parameters）

8.1超高速事務【SuperSpeed Transactions】

超高速事務（SuperSpeed transactions）由主機對設備端點請求或發送數據開始，並在端點發送數據或確認收到數據時完成。超高速總線上的數據傳輸（transfer）是主機請求設備應用程序生成的數據，然后該請求被分解成一個或多個突發事務（burst transactions）。當等待完成當前的總線事務時，超高速主機可以啟動一個或多個OUT總線事務到一個或多個端點。

然而，在滿足如下條件之一前，超高速主機不可以發起另一個IN總線事務到任何端點：

• 接收到所有DPs，或者一個NRDY，或者一個STALL TP，或者發送給非等時（non-isochronous）端點的當前ACK TP事務超時；或者

• 接收到所有的已經請求過的DPs，或者接收到一個短包（short packet），或者接收到一個last packet flag被設置的DP，或者發送給等時（isochronous）端點的當前ACK TP事務超時。

對於非等時傳輸（non-isochronous transfers），端點可能通過如下方式對有效的事務（valid transactions）做出響應：

• 返回一個NRDY事務包（Transaction Packet）

• 返回ACK事務包（Transaction Packet）來接受OUT事務 • 返回一個或多個數據包來響應IN事務

• 如果遇到端點內部錯誤，返回一個STALL事務包（Transaction Packet）

NRDY 事務包（TP）響應表示端點沒有准備好接受或者發送數據。結果，在該端點通知主機它已經准備好之前，主機和該端點之間不應該有進一步的活動。這就允許主機和設備之間的鏈路被設置到低功耗狀態（reduced power state），直到端點准備好接受或者發送數據。一旦准備好，端點異步發送一個通知（ERDY TP）給主機，告訴主機它現在已經准備好搬移數據，而主機也通過重新調度先前的請求來做出對該通知的響應。注意等時傳輸不使用ERDY 或者 NRDY TPs，因為它們是由主機周期性地服務的。此外，在等時端點上發送或者接收的數據包不需要確認，也就是說，沒有ACK TPs被發送來確認數據包的接收。

端點只響應由主機作出的請求。主機負責調度總線上的事務，並維護總線上數據搬移的優先級和公平性（priority and fairness）；這是通過對IN和OUT請求進行計時和排序（timing and ordering）達到的。事務不是廣播；包通過一條直接的路徑在主機和設備間穿越（traverse a direct path）。任何沒有被使用的鏈路都可以被設置到低功耗狀態（reduced power states），使得總線可以滿足嚴苛的電源管理要求（amenable to aggressive power management）。

8.2 數據包類型【Packet Types】

超高速USB使用4種基本數據包類型，每個類型又有一個或者多個子類型。這4種類型如下：

• 鏈路管理包【Link Management Packets (LMP)】只在一對鏈路（一對直接連接的端口）之間傳送，主要用於管理這條鏈路。

• 事務包【Transaction Packets (TP)】在所有的直接連接主機和設備的鏈路上傳送。它們被用於數據包流程控制制，配置設備及集線器等等。事務包沒有數據負載。

• 數據包【Data Packets (DP)】在所有的直接連接主機和設備的鏈路上傳送。數據包有兩部分：數據包頭【Data Packet Header (DPH)】以及數據包負載【Data Packet Payload (DPP)】。

• 等時時戳包【Isochronous Timestamp Packets (ITP)】是在主機到一個或多個設備間的所有活動鏈路（active links）上的多播（multicast）。

所有的包都包含一個14字節的頭部，緊接包尾的2字節鏈路控制字（Link Control Word）（總共16字節）。所有的頭都有一個Type字段【已勘誤】，被接收實體（receiving entity）（例如主機，集線器，或者設備）用來判斷如何處理這個包。所有的頭部都包含2字節CRC (CRC-16)。包頭具有在10²⁰個比特中少於1個不可校正或不可檢驗（uncorrectable or undetectable）的錯誤率。

所有的設備（包括集線器）以及主機都消耗掉它們接收到的鏈路管理包（LMPs）。集線器有附加的責任來轉發DPs, ITPs, 以及TPs到接近設備的下行端口（downstream port nearer a device），或者到接近主機的上行端口（upstream port nearer the host）。注意等時時戳包（ITPs）只由主機發送，而由設備接收。所有除鏈路管理包（LMPs）之外的包都會被集線器轉發，除非這個包是路由給該集線器自己的。對路由等時時戳包（ITPs）的附加規則在第8.7節中描述。注意，在TP, ITP, 或者DPH中的鏈路控制字（Link Control Word）可能會被集線器在轉發之前改變。鏈路控制字（Link Control Word）的字段在8.3.1.2節描述。

如果Type字段的值是Transaction Packet 或者Data Packet Header，那么Route String和Device Address字段將依照Type字段而定。Route String字段被集線器用於路由在其上行端口出現的數據包到適當的下行端口。從設備來的數據包總是從集線器的下行端口路由到其上行端口。Device Address字段用來供主機識別一個數據包的源。所有其它的字段將在本章后面得以詳述。

數據包在包頭中包含附加的信息用來描述數據塊（Data Block）。數據塊（Data Block）總是緊跟4字節的CRC-32字段，用以判定數據的正確性。數據塊和CRC-32一起被稱作數據包負載（Data Packet Payload）。

8.3 數據包格式

這一節定義超高速數據包。定義組成包類型和子類型（packet type and subtypes）的各個字段。

在本節中，數據包字節和bit位定義使用未編碼的數據格式來定義。添加到串行數據流中的符號的效果（例如，數據包分幀（frame packets），控制或者修改鏈路（control or modify the link）等），bit編碼，bit加擾, 以及鏈路層分幀（link level framing）等已經被刪除掉，以便更清楚明了。請參閱第6和第7章以獲得更詳細的信息。在討論總線性能（bus performance），有效性（efficiency）以及時序（timing）的時候，前述的底層操作的效果會被討論到，以提供更多的上下文。

8.3.1 所有頭包都有的字段【Fields Common to all Headers】

所有的超高速頭包都是以Type字段開始的，用以判定如何解釋該包。在高層次上這告訴包的接收者如何處理它：要么使用它來管理鏈路，要么用來控制設備和主機之間的數據流。

8.3.1.1 保留值和保留字段的處理【Reserved Values and Reserved Field Handling】

保留字段和保留值不允許以Vendor特定的方式使用。

發送方應該將所有的保留字段都設置為零值，接收方應該忽略所有的保留字段。

發送方不允許將已定義的字段設置成保留值，接收方應該忽略所有的將已定義字段的值設成了保留值的數據包。注意，接收方仍然需要確認這些數據包的接收，按第7.2.4.1節所述返回相關的值。

8.3.1.2 Type字段

Type字段是一個5-bit的字段，用於指定數據包的具體格式。類型是被中間的鏈路用於判定數據包如何被使用或者被轉發。

8.3.1.3 CRC-16

所有的包頭都有16-bit CRC字段。這個字段是對前面的12字節進行CRC計算而得到的。參見第7.2.1.1.2節用於計算這個值的多項式（polynomial）。

8.3.1.4 鏈路控制字（Link Control Word）

對鏈路控制字的使用如7.2.1.1.3節所定義。

Table 8-2. Link Control Word Format

寬度 (bits)	偏移 (DW:bit)	描述
3	3:16	Header Sequence Number. 有效值在 0 到 7之間。
3	3:19	Reserved (R).
3	3:22	Hub Depth. 本字段只在Deferred bit被設置時有效，用於在返回給主機的deferred TP或者deferred DPH中向主機指示該集線器在USB總線上的層級（hierarchical）。這就通知了主機，該數據包原本所期望被從之轉發的端口（the port on which the packet was supposed to be forwarded on）當前正處於低功耗狀態（U1 或者 U2）。該字段唯一有效的值在0到4之間。
1	3:25	Delayed (DL). 這個位應該在Header Packet 被重發（resent）或者Header Packet 的發送被延遲（delayed）的時候被置位。第7章和第10章提供了更多關於何時設置該位的細節。這個位不應該被該包所穿越過的后續集線器（any subsequent hub that this packet traverses）復位。
1	3:26	Deferred (DF). 這個位只可能（may only）被集線器設置。這個位只應該在該數據包需要被從之發送的下行端口（downstream port on which the packet needs to be sent）處於電源管理狀態時設置。這個位不應該被該包所穿越過的后續集線器復位。
5	3:27	CRC-5. 這個字段是對該字前面的11比特進行正確性驗證的CRC值。參閱7.2.1.1.3節關於計算該值的多項式。

8.4 鏈路管理包【Link Management Packet (LMP)】

Type 字段設置成Link Management Packet 的數據包被稱作鏈路管理包 LMPs。這些數據包被用來管理單個鏈路。它們不攜帶地址信息，因此不能被路由。它們可能因執行集線器端口命令而被生成。例如，一個集線器命令可被用來設置U2不活動超時值（U2 inactivity timeout）。此外，他們被用來交換端口能力信息以及完成測試目的。

8.4.1 Subtype字段

LMP Subtype 字段的值進一步標示LMP的內容。

8.4.2 Set Link Function

Set Link Function LMP應該被用來配置可以無須脫離活動狀態（U0）就能被改變的功能性（functionality）。

一旦接收到一個Force_LinkPM_Accept bit有效的（asserted）LMP包，端口應該接受所有的LGO_U1 和 LGO_U2鏈路命令，直到端口接收到Force_LinkPM_Accept無效的（de-asserted）LMP包。

設備必須保持在U1或U2，直到下行端口發起退出到U0。軟件在發起導致生成LGO_U1 或者LGO_U2鏈路命令的SetPortFeature命令之前，需要確保鏈路層級上沒有正在等待的包（no pending packets at the link level）。在常規操作期間，該特性只能在所有將鏈路狀態從U0降低到U1或U2的其他方式都失敗的情況下使用。這個LMP是在集線器接收到一個SetPortFeature (FORCE_LINKPM_ACCEPT)命令時，發送給連接給特定端口上的設備。參考第10.4.2.2節和第10.6.2.1節更多細節。

注意，不恰當地使用Force_LinkPM_Accept功能可能極大地影響鏈路性能，而在某些情況下（僅指在常規操作期間使用時）可能導致設備不能被返回到正常操作。【已勘誤，原來說該功能應該只被用來做兼容性和測試（compliance and testing）目的，現在允許該命令也可以在常規情況下使用！】

這個LMP被集線器在接收到SetPortFeature (FORCE_LINKPM_ACCEPT)命令時，發送給連接到特定端口上的設備。參閱第10.14.2.2節和第10.14.2.10節更多細節。

8.4.3 U2不活動超時（Inactivity Timeout）

U2不活動超時LMP應該被用來定義從U1轉換到U2的超時值。【已勘誤，對於上行端口，沒有U1不活動定時器。】參閱第10.4.2.1節關於這個LMP的更多細節。

表8-5. U2不活動超時功能（Inactivity Timer Functionality）

寬度

(bits)

偏移

(DW:bit)

描述

0:5

Subtype. 這個字段應該被設置為0010b 用於 U2 Inactivity Timeout LMP.

0:9

U2 Inactivity Timeout. 這8比特代表U2 Inactivity Timeout值，該值與被發送給集線器的Set Port Feature (PORT_U2_TIMEOUT)命令中的值相同。參閱第10.14.2.9節更多關於該字段編碼的細節。

8.4.4 制造商設備測試（Vendor Device Test）

使用這個LMP主要是為了制造商特定的測試目的，不應該用於正常的鏈路操作。

Table 8-6. 制造商特定的測試功能

寬度 (bits)	偏移 (DW:bit)	描述
4	0:5	Subtype. 這個字段應該被設置為0011b用於Vendor Device Test LMP.
8	0:9	Vendor-specific device test. 該字段的功能是制造商特定的。
64	1:0	Vendor-defined data. 該字段也是有制造商定義的。

8.4.5 端口能力（Port Capabilities）

端口能力LMP（Port Capability LMP）描述每個端口的鏈路能力，且在成功完成訓練和鏈路初始化之后，鏈路伙伴雙方都要發送。在端口從Polling進入U0之后，端口應該發送在鏈路初始化（參見第7.2.4.1.1節）完成之后的tPortConfiguration時間內發送Port Capability LMP。注意端口可能不總是從Polling直接轉換進入U0，而是在進入U0之前可能通過其他中間狀態（例如，Recovery或Hot Reset）轉換。不論在Polling和進入U0之間經過了什么狀態，設備都應該在進入U0時立即發送一個Port Capability LMP【已勘誤】。

如果一個鏈路伙伴在tPortConfiguration時間內沒有接收到這個LMP，那么：

如果鏈路伙伴有下行能力，它應該按照第10.14.2.6節所描述的那樣發送一個錯誤信號。
如果鏈路伙伴只支持上行能力，那么上行端口應該轉換到SS.Disabled狀態，並且應該嘗試以這個設備支持的其它速度進行連接。

表8-7. 端口能力LMP 格式

寬度 (bits)	偏移 (DW:bit)	描述
4	0:5	Subtype. 這個字段應該被設置為0100b用於Port Capability LMP
7	0:9	Link speed. 這個字段是個掩碼，用於描述這個設備支持的速度。比特位描述 0 這個位應該被設為1來指示該設備支持5Gbps信號 6:1 Reserved.
16	0:16	Reserved
8	1:0	Num HP Buffers. 這個字段指定該設備支持的header packet buffers的個數。所有兼容本規范版本的設備都應該返回值4。所有其它值都是保留的。
8	1:8	Reserved
2	1:16	Direction (D). 該字段用於標示該端口的上行或者下行能力(upstream or downstream capabilities)。所有的端口都至少要設置這些位中的1位。比特位描述 0 如果這位被設為1，那么該端口可以被配置為下行端口 1 如果這位被設為1，那么該端口可以被配置為上行游端口
2	1:18	Reserved
4	1:20	Tiebreaker. 這個字段只在 Direction 的兩個位都被設置為1的情況下才有效。該字段用於兩個同時具備upstream and downstream capability的設備連接在一起時，用來判斷端口類型的。參見表8-8中更詳細的信息。該字段在其它情況下應該都被設置為零。
40	1:24	Reserved.

在交換端口能力LMPs之后，鏈路伙伴應該根據表8-8所指定的那樣來判定由哪一方被配置為下行端口。

表8-8. 端口類型選擇矩陣

端口及其原有屬性		端口2
端口及其原有屬性		只上行	只下行	上下行
端口 1	只上行	未定義	端口2為下行	端口2為下行
	只下行	端口1為下行	未定義	端口1為下行
	上下行	端口1為下行	端口2為下行	Tiebreaker值更高的端口成為下行端口（注1）

注意1: 如果TieBreaker字段相等，那么鏈路伙伴雙方應該用新的不同TieBreaker值來重新交換端口能力LMPs。端口生成TieBreaker字段值的順序應該足夠隨機。【譯注：TieBreaker本身就含有決勝局之意。】

8.4.6 端口配置（Port Configuration）

這一節只描述與端口能力LMP有區別的字段。所有的支持下行端口能力的超高速端口都應該能夠發送這個LMP。如果即將被配置成上行模式的端口沒有在鏈路被初始化之后的tPortConfiguration時間內接收到這個LMP，那么這個上行端口應該切換到SS.Disabled狀態，並且應該嘗試以這個設備支持的其它速度進行連接。

表 8-9. 端口配置LMP格式 (與端口能力LMP有區別之處)

寬度 (bits)	偏移 (DW:bit)	描述
4	0:5	Subtype. 這個字段應該被設置為0101b用於Port Configuration LMP.
7	0:9	Link speed. 該字段描述上行端口應該工作的鏈路速度。鏈路伙伴所發送的端口配置LMP中的這個字段只應該有其中1位能夠被設置。比特位描述 0 如果這個比特被設置，那么這個設備應該工作在5Gbps。 6:1 Reserved.
80	0:16	Reserved.

被配置為下行模式的端口應該發送這個端口配置LMP給上行端口。發送該LMP的端口應該只選擇Link Speed字段的其中1個比特。如果有能力充當下行端口的端口不能與其鏈路伙伴協同工作，那么該有能力充當下行端口的端口應該按照第10.14.2.6節所描述的那樣發送一個錯誤信號。

8.4.7 端口配置響應（Port Configuration Response）

這個LMP是由上行端口作為對端口配置LMP的響應而發出的。他被用作對端口配置LMP的接受或者拒絕的指示。這一節也只描述與端口能力LMP有區別的字段。

所有支持上行端口能力的超高速端口都應該能夠發送這個LMP。

如果下行端口在tPortConfiguration之內沒有收到這個LMP，則它應該該按照第10.14.2.6節所描述的那樣發送一個錯誤信號。

表 8-10. 端口配置響應LMP格式 (與端口能力LMP有區別之處)

寬度 (bits)	偏移 (DW:bit)	描述
4	0:5	Subtype. 這個字段應該被設置為0110b用於Port Configuration Response LMP.
7	0:9	Response Code. 該字段指示被接受的在發送給一個設備的Port Configuration LMP的設置信息。比特位描述 0 如果這個比特被設置，那么這個設備接受Link Speed的設置。. 6:1 Reserved.
80	0:16	Reserved.

如果Response Code 指示Link Speed 被上行端口拒絕, 下行端口應該按照10.14.2.6所描述的那樣發送一個錯誤信號。

8.5 事務包【Transaction Packet (TP)】

事務包 (TPs) 穿越主機和設備之間的直接路徑。事務包被用來控制數據流和管理端到端的連接。 Type字段的值應該設置為Transaction Packet （即00100b）。 Route String字段是被集線器用來路由出現在其上行端口上的包到正確的下行端口。從設備發出的事務包的路由字串被設置為零。當主機發送一個事務包時，Device Address字段包含預定的接收者的地址。當設備發送一個事務包給主機時，它將Device Address字段設置為它自己的設備地址。該字段被主機用來識別事務包的來源。事務包中SubType字段被接收者用來判定事務包的格式和使用方式。

8.5.1 確認事務包【（ACK）Transaction Packet】

這個事務包用於兩個目的：

對於IN端點，由主機發送該事務包，用來從設備請求數據，以及對主機之前接收到的數據包進行確認。
對於OUT端點，由設備發送該事務包，用來對主機之前發送的數據包進行接收確認，以及通知主機在接收到這個包后設備還有多少個數據包緩沖區可用。

表 8-12. 確認事務包 ACK TP 格式

寬度 (bits)	偏移 (DW:bit)	描述
20	0:5	Route String/Reserved. 該字段只被集線器使用。與集線器深度聯合，用來路由包到正確的下行端口。參考第8.9節中的詳情。當被設備端發送時，該字段是被保留的。
7	0:25	Device Address. 該字段指定設備，通過地址，該設備是包的接收者還是源。參考第8.8節。
4	1:0	SubType. 該字段應該被設置為0001b （ACK）用於ACK TP。
2	1:4	Reserved (Rsvd).
1	1:6	Retry Data Packet (rty). 該字段用於告知主機或者設備沒有接收到數據包或者接收到的數據包被損壞，並且請求數據發送方重新發送由指定的序列號開始的一個或者多個數據包。
1	1:7	Direction (D). 該字段定義發送或者接收這個事務包的設備端點的方向。參見第8.8節。值數據流方向 0b 主機到設備 1b 設備到主機
4	1:8	Endpoint Number (Ept Num). 該字段判定發送或者接收這個事務包的設備端點。參考第8.8節。
3	1:12	Reserved (Rsvd).
1	1:15	Host Error (HE). 該字段只在這個ACK TP是被主機發送給設備的情況下才有效。該比特應該被主機在由於主機端的內部問題而無法接收有效數據包的情況下設置。對於非等時傳輸，如果主機設置了這個字段，還必須同時設置 Retry Data Packet 字段。
5	1:16	Number of Packets (NumP). 該字段用於指示接收方可以接受多少個數據包緩沖區。這個值應該小於或等於端點伴侶描述符（Endpoint Companion Descriptor，參考9.6.7節）的Burst Size 字段所指定的端點所能支持的最大突發大小（maximum burst size）。
5	1:21	Sequence Number (Seq Num). 該字段用於識別預期的下一個數據包（next expected data packet）的序列號。
6	1:26	Reserved.
16	2:0	Stream ID/Reserved. 如果這個ACK TP的目標是一個支持流（Streams）的 Bulk端點（即流管道），那么這個字段包含一個在1到65535之間的Stream ID。Stream ID 值0對流管道是保留的，如果接收到該字段為0值則該TP應該被認為是無效的。所有其他管道都應該將該字段作為保留字段對待。對這個字段的使用依賴於設備類。如果該Bulk端點不支持流（Streams），這個字段應該被設置為零。參考第8.12.1.4節關於Stream IDs的更多信息。【已勘誤】
11	2:16	Reserved.
1	2:27	Packets Pending (PP). 該字段只能由主機設置。如果該字段被設置，則主機已經准備好從該端點/流（endpoint/Stream）接收另一個DP，其中端點由Endpoint Number 和 Direction 字段標識，且如果這是一個流端點（Stream endpoint）則Stream由Stream ID字段標識。如果這個字段是清除的（cleared），那么主機還沒有准備好從該端點/流（endpoint/Stream）接收更多的DPs。如果這個設備上沒有端點有數據正等待（packets pending），則設備可據此對其上行鏈路進行深度電源管理，例如進入低功耗U1或者U2狀態。
4	2:28	Reserved.

8.5.2 未就緒事務包【 (NRDY) Transaction Packet】

只能由設備的非等時端點發送這個事務包。OUT端點在設備沒有包緩沖區來接收主機已經發送來的數據包DP的情況下，發送這個TP給主機。IN端點在不能發送數據包DP給主機的情況下，發送這個TP給主機，作為對主機已經發送來的ACK TP的響應。

本節只描述與ACK TP有區別的字段。

表 8-13. NRDY TP 格式(與 ACK TP 有區別部分)

寬度 (bits)	偏移 (DW:bit)	描述
4	1:0	Subtype. 這個字段應該被設置為0010b用於NRDY。
3	1:4	Reserved
20	1:12	Reserved.
5	2:27	Reserved.

8.5.3 端點就緒事務包【 (ERDY) Transaction Packet】

只能由設備的非等時端點發送這個事務包。它被用來通知主機，端點已經准備好發送或者接收數據包。

本節只描述與ACK TP有區別的字段。

表 8-14. ERDY TP 格式 (與 ACK TP 有區別部分)

寬度 (bits)	偏移 (DW:bit)	描述
4	1:0	Subtype. 這個字段應該被設置為0011b用於ERDY。
3	1:4	Reserved
4	1:12	Reserved.
5	1:16	Number of Packets (NumP). 對於OUT 端點, 參考表 8-12 對這個字段的描述. 對於IN 端點，這個字段被端點設置為在主機恢復與該端點之間的事務之后，其能夠發送的包的個數。這個值不應該超過端點伴侶描述符（Endpoint Companion Descriptor，參考9.6.7節）的Burst Size 字段所指定的端點所能支持的最大突發大小（maximum burst size）。注意這個字段報告的值可能只被主機當作參考信息。
11	1:21	Reserved.
5	2:27	Reserved.

8.5.4 狀態事務包【STATUS Transaction Packet】

只能由主機發送這個事務包。它被用來通知設備的控制端點，主機已經發起控制傳輸的狀態階段。這個TP應該只被發送給控制端點。

本節只描述與ACK TP有區別的字段。

表 8-15. STATUS TP 格式(與 ACK TP 有區別部分)

寬度 (bits)	偏移 (DW:bit)	描述
4	1:0	Subtype. 這個字段應該被設置為0100b用於STATUS。
3	0:4	Reserved
52	1:12	Reserved.

8.5.5 STALL Transaction Packet

只能由設備的端點發送這個事務包。它被用來通知主機，端點已經被暫停（halted）或者控制傳輸無效。

本節只描述與ACK TP有區別的字段。

表 8-16. STALL TP 格式 (與 ACK TP 有區別部分)

寬度 (bits)	偏移 (DW:bit)	描述
4	1:0	Subtype. 這個字段應該被設置為0101b用於STALL。
3	0:4	Reserved
52	1:12	Reserved.

8.5.6 設備通知事務包【(DEV_NOTIFICATION) Transaction Packet】

只能由設備發送這個事務包。它被設備用來通知主機，設備或者接口狀態有異步改變，例如，用來識別設備中引起設備執行一次遠程喚醒操作的功能（function）。這個事務包不是從一個特別的端點發送的，在總體上是由設備發送的。

本節只描述與ACK TP有區別的字段。

表 8-17. 設備通知 TP 格式 (與 ACK TP 有區別部分)

寬度

(bits)

偏移

(DW:bit)

描述

1:0

Subtype. 這個字段應該被設置為0110b用於DEV_NOTIFICATION。

1:4

Notification Type. 這個字段標示設備通知的類型。

值通知事務包類型

0000b Reserved

0001b FUNCTION_WAKE

0010b LATENCY_TOLERANCE_MESSAGE

0011b BUS_INTERVAL_ADJUSTMENT_MESSAGE

0100b – 1111b Reserved

8.5.6.1 功能喚醒設備通知【Function Wake Device Notification】

表 8-18. 功能喚醒設備通知【Function Wake Device Notification】

寬度 (bits)	偏移 (DW:bit)	描述
4	1:0	Subtype. 這個字段應該被設置為0110b用於DEV_NOTIFICATION。
4	1:4	Notification Type. FUNCTION_WAKE - 0001b
8	1:8	Interface. 該字段標示引起設備執行遠程喚醒操作的功能中的第一個接口。
48	1:16	Reserved.

8.5.6.2 延遲忍耐消息設備通知【Latency Tolerance Message (LTM) 】

延遲忍耐消息設備通知（Latency Tolerance Message Device Notification）是可選的標准特性（optional normative feature），可以使得平台操作更具功耗有效性（power efficient）。

表 8-19. 延遲忍耐消息設備通知

寬度

(bits)

偏移

(DW:bit)

描述

1:0

Subtype. 這個字段應該被設置為0110b用於DEV_NOTIFICATION。

1:4

Notification Type. LATENCY_TOLERANCE_MESSAGE - 0010b

1:8

BELT. 本字段描述最大努力延遲忍耐(Best Effort Latency Tolerance) 值，代表設備能夠等待服務的以鈉秒計的時間（time in nanoseconds that a device can wait for service），超過該時間則設備將遭遇非預期的操作性副作用（experiencing unintended operational side effects）。

比特位描述

9:0 延遲值（以鈉秒為單位）【LatencyValue (ns)】

11:10 延遲伸張系數【LatencyScale】

延遲伸張系數	描述
00b	Reserved
01b	延遲值要被乘以1024
10b	延遲值要被乘以32,768
11b	延遲值要被乘以1,048,576

1:20

Reserved.

8.5.6.3 總線間隔調整消息設備通知【Bus Interval Adjustment Message Device Notification】

表 8-20. 總線間隔調整消息設備通知

寬度 (bits)	偏移 (DW:bit)	描述
4	1:0	Subtype. 這個字段應該被設置為0110b用於DEV_NOTIFICATION。
4	1:4	Notification Type. BUS_INTERVAL_ADJUSTMENT_MESSAGE - 0011b
8	1:8	Reserved.
16	1:16	Bus Interval Adjustment. 這個字段是在-32768 到 +32767之間的2的補碼（two's complement value），以BusIntervalAdjustmentGranularity為單位表示。

8.5.6.4 功能喚醒通知【Function Wake Notification】

如果遠程喚醒（remote wakeup）被使能，一個功能（function）可以通過發送Function Wake Device Notification，告知主機它想要從設備掛起（device suspend）（在將鏈路轉換進入U0狀態后）或者功能掛起（function suspend）狀態退出。參考第9.2.5節更多細節。

8.5.6.5 延遲忍耐消息【Latency Tolerance Messaging】

延遲忍耐消息（Latency Tolerance Messaging）是一個可選的標准USB電源管理特性（optional normative USB power management feature），利用所報告的BELT (Best Effort Latency Tolerance)值來使能更好的平台操作功耗有效性（power efficient）。

BELT值是主機將設備置於無服務狀態的最大時間（將所有已配置端點的服務需求都計入在內）。特別地，BELT值是主機從接到設備的ERDY開始，到主機傳送對ERDY的響應之間的時間。

設備通過使用BOS描述符中的SUPERSPEED_USB Device Capability描述符中的LTM Capable字段，來指示是否有能力發送LTM事務包（參考9.6.2節）。LTM Enable (參考9.4.10) 特性選擇子使能 (或禁用) LTM capable的設備發送LTM事務包。

8.5.6.5.1 可選的標准LTM和BELT要求【Optional Normative LTM and BELT Requirements】

總體設備要求【General Device Requirements】

• LTM TPs應該只能源自於外圍設備。

• LTM TPs適用於除等時端點之外的所有端點類型。

• 一旦BELT值被設備發送給了主機，所有的設備端點都可以預期在指定的BELT時間內得到服務。

• 設備應該在tMinLTMStateChange時間之內，發送一個BELT字段值為tBELTdefault的LTM TP，來響應LTM Enable狀態的任何改變。

• 設備應該保證足夠經常判定(determined frequently enough)其BELT值，從而在需要更改BELT值之前能夠提供合理的關於設備服務延遲忍耐性的估計。此外，還需要滿足如下條件：

LTM TPs的最大個數受限於tBeltRepeat。
每個LTM TP應該具有不同的BELT值。

• 系統應該對所有設備使用1 ms為默認BELT值 (參見表8-33)。

• BELT的最小值是125 μs (參考表8-33)。

支配BELT值的建立的設備要求【Device Requirements Governing Establishment of BELT Value】

• LTM機制應該使用U1SEL和U2SEL來為設備提供系統延遲（system latency）的信息(見第9.4.12節–Set SEL)。在這個上下文中，系統延遲（system latency）是指，在允許的最深鏈路狀態是U1或U2狀態的情況下，從設備發送ERDY到它從主機接收到事務包（類型特定於方向，direction-specific）之間的時間。這些值由設備用來恰當地調整它們的BELT值，將它們在USB鏈路拓撲中的位置計入在內。

允許其鏈路進入U1，而不允許進入U2的設備，應該將U1系統退出時延【U1 System Exit Latency (U1SEL)】從其總體延遲忍耐時間中減去，並將結果作為LTM TP中的BELT字段值發送。
允許其鏈路進入U1和U2的設備，應該將U2系統退出時延【U2 System Exit Latency (U2SEL)】從其總體延遲忍耐時間中減去，並將結果作為LTM TP中的BELT字段值發送。

8.5.6.6 總線間隔調整消息【Bus Interval Adjustment Message】

【譯注：這段話實在是拗口啊，費解啊！勸君還是看原文吧，即使原文也讓人暈啊！】

該設備通知可由設備發送用來請求增加或者減小總線間隔（bus interval）的長度。這將典型地由設備用於嘗試將主機的總線間隔時鍾（host's bus interval clock）與外部時鍾（external clock）同步。總線間隔調整請求是相對於當前總線間隔的。例如，如果設備請求增加一個BusIntervalAdjustmentGranularity單元，並且之后再請求增加兩個BusIntervalAdjustmentGranularity單元，則主機總共增加三個BusIntervalAdjustmentGranularity單元。

主機應該支持絕對范圍在-37268到37267個BusIntervalAdjustmentGranularity單位之間的調整值。設備每八個總線間隔的調整要求不應該超過一次（A device shall not request adjustments more than once every eight bus intervals）。直到設備等待足夠長時間而在后續的ITPs的時間戳字段上精確觀察到前一次總線間隔調整請求的效果之前，不應該發送另一個總線間隔調整請求。設備的每一次BusIntervalAdjustment請求，不應該超過多於±4096個調整單位。設備可以隨着時間的推移發起多次BusIntervalAdjustment請求，來達到總體上多於4096個調整單位。除非設備在過去的125μs內收到過一個ITP，且該ITP包含的Bus Interval Adjustment Control字段的值等於零或該設備的地址，且該設備正處於Address或Configured狀態，設備不應該請求總線間隔調整。

一次只有一個設備可以控制總線間隔長度。主機控制器根據本節的描述實現一個先來先服務的策略來處理總線間隔調整請求。在主機控制器開始操作時，它應該發送Bus Interval Adjustment Control字段值為0的ITPs。當主機控制器首次接收到一個總線間隔調整控制請求，它應該將后續ITPs的Bus Interval Adjustment Control字段設置為發送該請求的設備的地址。一旦Bus Interval Adjustment Control字段被設置為非零值，主機應該忽略所有其它設備的總線間隔調整請求。如果起控制作用的設備被斷開，主機控制器應該將Bus Interval Adjustment Control字段復位為零。主機控制器可以提供一個方式以供軟件重寫（override）默認的總線間隔調整控制字段的行為，並選擇起控制作用的設備。主機控制器應該在收到總線間隔調整請求之后兩個總線間隔內開始應用總線間隔調整。

最小的總線間隔調整值（1個BusIntervalAdjustmentGranularity）要求主機做出平均每4096個總線間隔8個高速比特時間的調整。允許主機在單個總線間隔內做出這個調整，這樣，用以生成ITP時序和總線間隔范圍的時鍾的周期不需要小於8個高速比特時間。主機應該定期做出總線間隔調整。當主機被要求平均每4096個總線間隔做出一個或多個"8個高速比特時間（eight high speed bit time）"的調整時，應該按照如下定義的限制來均勻地分布該調整：

包含比其他間隔多一個"8個高速比特時間（eight high speed bit time）"的間隔，被稱作"最大調整總線間隔（maximum adjustment bus intervals）"。
在任何總線間隔期間完成的"8個高速比特時間（eight high speed bit time）"調整的個數，超過任何其他總線間隔期間完成的"8高速比特時間（eight high speed bit time）"調整的個數不應該多於1。
兩個連續的"最大調整總線間隔（maximum adjustment bus intervals）"之間的距離（以總線間隔計）不應該多於1個總線間隔。

對於總線間隔調整（bus interval adjustments）的均勻分布和平均調整的要求（even distribution and average adjustment requirements），應該從主機接收到一個總線間隔調整請求的一個總線間隔后（one bus interval after a bus interval adjustment request is received）開始應用，直到主機再次接收到一個后續的有效的總線間隔調整請求（subsequent valid bus interval adjustment request is received）所在的總線間隔。

下面是對一個特定的總線間隔調整請求的有效主機行為的示例。在上電后，主機接收到一個總線間隔調整，要求在總線間隔X-1中減小10個BusIntervalAdjustmentGranularity單位。主機控制器使用一個周期為"8個高速比特時間（eight high speed bit times）"的時鍾來驅動一個計數器，來產生時間戳和總線間隔范圍（produces timestamps and bus

interval boundaries）。主機在下列總線間隔中，添加一個附加的（extra）"8個高速比特時間（eight high speed bit time）"的時鍾tick到其計數器：X+409, X+819, X+1228, X+1638, X+2048,X+2457, X+2867, X+3276, X+3686, X+4096, X+4505,….

8.5.7 PING事務包

這個事務包只能被主機發送。他被主機用來在發起一個等時傳輸之前，將到一個設備的所有鏈路轉換到U0狀態。參考附錄C中關於使用這個TP的細節。本節只描述與ACK TP有區別的字段。

設備應該通過在tPingResponse時間（參考表8-33）內，發送PING_RESPONSE TP給主機，來響應PING TP（參考8.5.8節）。注意設備不應該驗證EP_NUM和Direction字段，而是簡單地將它們拷貝到PING_RESPONSE TP的相關字段中【已勘誤】。

設備應該將其鏈路保持在U0狀態，直到它從主機接收到一個后續包，或者直到tPingResponse時間（參考表8-33）超時。

表 8-21. PING TP 格式 (與 ACK TP 有區別的地方)

寬度 (bits)	偏移 (DW:bit)	描述
4	1:0	Subtype. 這個字段應該被設置為0111b用於PING。
3	1:4	Reserved.
52	1:12	Reserved.

8.5.8 PING_RESPONSE 事務包

這個事務包只能由設備發送，來響應主機發送的PING TP。每接收到一個PING TP都應該發送一個PING_RESPONSE TP。參考附錄C中關於使用這個TP的細節。本節只描述與ACK TP有區別的字段。

表 8-22. PING_RESPONSE TP 格式 (與 ACK TP 有區別的地方)

寬度 (bits)	偏移 (DW:bit)	描述
4	1:0	Subtype. 這個字段應該被設置為1000b用於PING_RESPONSE。
3	1:4	Reserved.
1	1:7	Direction (D). 該字段應該被設置為這個PING_RESPONSE TP正為之發送的PING TP的Direction 字段。
4	1:8	Endpoint Number (Ept Num). 該字段應該被設置為這個PING_RESPONSE TP 正為之發送的PING TP的Ept Num字段。
52	1:12	Reserved.

8.6 數據包【Data Packet (DP)】

這個包可以被主機或者設備發送。主機用這個包發送數據給設備。設備用這個包返回數據給主機，作為對ACK TP的相應。所有的數據包都由數據包頭（Data Packet Header）和數據包負載（Data Packet Payload）組成。本節只描述與ACK TP有區別的字段。

數據包在主機和設備間的直接路徑上穿行。注意發送零長數據塊的數據包是允許的，但還是需要一個CRC-32。

表 8-23. 數據包格式 (與 ACK TP 有區別的地方)

寬度 (bits)	偏移 (DW:bit)	描述
5	1:0	Sequence Number (Seq Num). 該字段用於識別數據包的序列號。注意序列號在31處回繞。
1	1:5	Reserved
1	1:6	End Of Burst (EOB)/Last Packet Flag (LPF). 對於非等時端點，該字段被稱為EOB；而對於等時端點，該字段被稱為LPF 。對於非等時輸入端點，該字段用於標示這是一次突發的最后一個包。當設備准備好繼續傳輸，應該發送一個ERDY TP給主機。注意端點應該重新評估重試的數據包的EOB值。如果設備返回少於上一次接收到的ACK TP中NumP字段指定的包個數，並且最后一個包不是短包，那么突發的最后一個包的EOB字段應該被設置。注意，當設備發送一個短包，盡管它可能會返回比接收到的最后一個ACK TP中的NumP字段要少些的包個數，設備也不必（not required）將這個EOB字段設為1b。只有在設備想要在用這個短包來完成當前傳輸之后進入流程控制狀態時，設備才需要將這個字段設為1b。【已勘誤】對於非等時輸出端點和控制端點，該字段應該被設為零。對於等時端點，該字段用於標示這是當前服務時段（service interval）的最后一個突發的最后一個包。LPF可以由設備和主機設置。當這個數據包的目標和源頭是等時端點時，請參考8.12.6節對該字段的用法。
4	1:8	Endpoint Number (Ept Num). 該字段判定設備中是這個數據包的源頭（source）或者接收者（recipient）的端點。
3	1:12	Reserved
1	1:15	Setup (S). 該字段被主機設置用來標示這個數據包是Setup 數據包。這個字段只能由主機設置。
16	1:16	Data Length. 該字段被用來標示數據包負載中除了數據CRC-32之外的字節數。
1	2:27	Packets Pending (PP). 該字段只能由主機設置。如果該字段被設置，則主機有一個或者多個DPs可用來向該端點/流（endpoint/Stream）傳輸，其中端點由Endpoint Number 和 Direction 字段所標識，且如果這是一個流端點（Stream endpoint）則Stream由Stream ID字段標識。如果這個字段是清除的（cleared），那么這是主機有的可以傳輸給該目標端點/流（endpoint/Stream）的最后一個DP。如果這個設備上沒有端點有數據正等待（packets pending），則設備可據此對其上行鏈路進行深度電源管理，例如設置鏈路進入低功耗U1或者U2狀態。
xx	4:0	Data Block. 這個字段包含數據包負載的數據。這個字段的長度由 Data Length 字段標示。
32	4:0	CRC-32. 數據CRC是對數據包負載的數據塊進行計算得到的。參考7.2.1.2.1的計算這個值的多項式。注意，由於數據塊長度可能不是4的整數倍，因此這個字段也不一定在DWORD邊界對齊。

8.7 等時時戳包【ITP】

ITP的Type字段是01100b (Isochronous Timestamp Packet)。ITPs 被用於從主機傳送時間戳信息到所有的活動設備。ITPs不攜帶尋址或者路由信息，被集線器多播（multicast）到其鏈路處於U0狀態的所有下行端口。設備不應該響應ITP。ITP用來提供主機端的時序信息到設備以達到同步。注意所有的設備或者集線器都可能接收ITP。主機應該當且僅當根端口鏈路已經在U0狀態時在該鏈路上傳送ITP。只有主機應該發起ITP傳送。主機不應該為了要傳送ITP而將根端口鏈路帶進U0狀態。如果根端口鏈路處於U0狀態，主機應該在每個總線間隔的邊界的tTimestampWindow內傳送一個ITP。主機應該在主機的根端口的鏈路從輪詢狀態進入U0狀態tIsochronousTimestampStart時間內開始傳送ITPs。ITP可以在一個突發的包之間傳送。如果一個設備接收到一個鏈路控制字中的延遲標志(DL)被設置的ITP，其時間戳值可能非常不精確，可以被設備忽略。

表 8-24. 等時時戳包格式

寬度 (bits)	偏移 (DW:bit)	描述
27	0:5	Isochronous Timestamp (ITS). 等時時間戳字段被用於標示從傳送ITP的主機角度來看的當前時間值。時間戳字段被分成兩個子字段：比特位描述 13:0 Bus interval counter. 當前1/8毫秒計數器。計數器值當到達0x3FFF時翻轉並繼續增加。 26:14 Delta. 從當前ITP包的開始到前一個總線間隔邊界的時間差值。該值是單位為tIsochTimestampGranularity的數值。使用的值應該指定最接近前一總線間隔邊界的時間差值（delta），而不超前該邊界（comes closest to the previous bus interval boundary without going before the boundary）。注意：如果一個包恰好在總線間隔邊界開始，則delta 被設置為0。
7	1:0	Bus Interval Adjustment Control. 該字段指定控制總線間隔調整機制的設備的地址。在復位，上電，或者如果設備被斷開時，主機應該將該字段設為零。
57	1:7	Reserved.

在ITP的第一個分幀符號（framing symbol）被傳送時測量的ITP的ITS值精確度應該具有主機時鍾（用於ITP生成）值的±1個 tIsochTimestampGranularity單位。

8.8 尋址三劍客【Addressing Triple】

數據包和大多數的事務包通過三個字段的復合來提供對特定數據流的訪問。它們是Device Address, Endpoint Number和Direction字段。

在復位和上電時，設備的地址默認為0，應該被主機在枚舉過程中編程設置為一個在1到127之間的值。設備地址0被保留作為默認地址，不應該被指定為其它用途。

除了必須的端點號設為0的默認控制端點，設備可以支持多達15個IN和15個OUT端點（由Direction字段標示）。

8.9 Route String字段

Route String是下行方向的包中一個20比特的字段，集線器用它來將包路由到指定的下行端口。它由該包將要越過的每一個集線器的下行端口號（每個集線器4比特）拼接而成。集線器用集線器深度（Hub Depth）值乘以4作為偏移量，在 Route String 中定位相應的位來判定下行端口號。集線器深度（Hub Depth）值是在枚舉過程中判定，並賦予給每個集線器的。注意這個字段只在主機發出的包中有效，當設備發送時，這個字段被保留。

在圖8-24中，Hub@Tier1字段的值是直接連接到主機的一個根端口的集線器的下行端口號，而該端口上又掛接了第二個集線器，等等。

8.9.1 Route String Port 字段

這個Route String中的4比特寬的字段代表被尋址的集線器的端口。

8.9.2 Route String Port 字段寬度

Route String Port字段寬度被固定為4，限制了集線器最多能支持的端口個數為15。

8.9.3 Port Number

Route String Port字段的值標示包被導向的特定的集線器下行端口。當尋址集線器控制器【譯注，即集線器本身】時，Route String中該集線器所在的層級對應的Port Number字段應該被設置為0。集線器下行端口從1開始向上順序增加來尋址。

8.10 事務包的使用

事務包（TPs）被用來報告數據事務的狀態，並且可以返回值用以指示數據包的成功接收（reception of data packets），命令被接收或拒絕（command acceptance or rejection），流程控制（flow control），以及暫停情況（halt conditions）。

8.10.1 流程控制情形【Flow Control Conditions】

本節描述當端點返回一個流程控制響應（flow control response）時，主機和設備之間的交互。流程控制是在主機和設備端點之間的端到端級別的交互。只有批量,控制和中斷端點可以發送流程控制響應。

一個IN端點在其返回如下的對ACK TP的響應時，應該被認為在流程控制情形下：

用NRDY TP響應；注意端點應該等待它接收到上次發送的DP的ACK TP之后，才能發送NRDY TP【已勘誤】。
發送一個DP，其DPH中的EOB標志被設為1。

一個OUT端點在其返回如下的對DP的響應時，應該被認為在流程控制情形下：

用NRDY TP響應。
發送一個ACK TP，其NumP字段被設為0。

Packets Pending字段只在被主機設置時有效，且不影響一個端點是否進入流程控制狀態。參考第8.11節關於主機和設備TP響應的進一步細節。

當端點在流程控制情形下，應該發送一個ERDY TP來被轉回活動狀態。進一步，如果端點是IN端點，它應該等到它接收到一個對它發送的上一個DP的ACK TP之后才能發送ERDY TP。當端點不在流程控制狀態下時，除非該端點是支持流模式的批量端點，否則它不應該發送ERDY TP。參考第8.12.1.4.2節和第8.12.1.4.3節關於批量端點可以發送ERDY TP的進一步信息。注意主機可能恢復與一個端點的事務-即使該端點在返回一個流程控制響應后，還沒有返回一個ERDY TP。

8.10.2 突發事務【Burst Transactions】

超高速USB協議允許主機連續發送數據到設備，或者從設備連續接收數據，只要設備可以接收或者發送數據。設備在無需中間確認包（intermediate acknowledgement packet）的情況下可以發送或者接收的包的個數在該端點的端點伴侶描述符（endpoint companion descriptor）中報告（參考第9.6.7節）。報告端點的maximum burst size多於一個包的端點被認為是支持"突發"事務。

在進行突發傳送時，適用於下面的規則：

在接收一個確認包之前，一個突發中可以發送的包個數的最大值，被限制為：端點的最大突發的大小【maximum burst size】（參見表9-20定義的bMaxBurst）和上一個被端點或主機接收到的ACK TP或ERDY的NumP字段值的最小值，減去端點或主機在被上一個ACK TP確認過的包之后已經發送的包的個數。注意，每當端點被初始化時，主機可以重新將能夠發送/接收的最大DPs的個數初始化為端點最大突發的大小【maximum burst size】【已勘誤】。
突發傳送中，每一個獨立的包應該有數據包負載長度為maximum packet size。只有突發的最后一個包可以小於報告的maximum packet size。如果最后一個小一些，那么對於短包的規則適用於在突發末尾的短包（參考8.10.3節）。
突發事務只要ACK TP的NumP字段沒被設為0並且每個包都有最大包大小的數據負載，就可以繼續。
NumP字段可在任何時候被發送ACK TP的主機或者設備增加，只要設備或者主機想要繼續接收數據。唯一的要求是，NumP字段不應該大於設備支持的最大突發個數。但是，對於ISOC IN端點，參考第8.12.6.1節關於如何改變每個突發（each burst）的NumP字段的更多要求。【已勘誤】
如果一個發送ACK TP的設備或者主機減小 NumP字段，那么一次不能超過1個。例如，如果前一次的ACK TP的 NumP字段為5，那么下一個用來確認下一次包被收到的ACK TP的 NumP字段不應該少於4。對此規則的唯一例外如下：
- 如果設備可以接受數據但是不能接受更多數據，那么它應該發送NumP字段為0的ACK TP；
- 主機應該發送一個NumP字段為0的ACK TP來響應設備發送來的EOB字段被設置的數據包DP或者短包（參見第8.10.3節）。但是，如果主機接收到短包並且主機對同一端點還有傳輸要發起，那么主機可能反而要發送一個NumP字段為非0的ACK TP。
- 主機可以發送一個ACK TP，將rty位設置，且將NumP字段設置為小於端點能夠支持的最大突發大小的任何值（包括0值，用於對設備發送DP時DPP錯誤做出響應時）（參見第8.11.2節）【已勘誤】。

8.10.3 短包【Short Packets】

超高速維持了USB2.0支持的短包行為。當主機或者設備接收到一個數據包DP其Data Length字段比端點的最大包長度要小時，它應該認為傳輸已經完成。

對於IN傳輸的情況，設備在發送一個短包之后應該停止發送數據包。主機應該用將NumP字段設為0的ACK TP來響應短包（除非主機對該相同端點有另一個傳輸，在這種情形下主機可以按照第8.10.2節所提到的那樣設置NumP字段【已勘誤】）。主機應該在發起對該端點的另一個傳輸的時候來調度對於該設備端點的事務。

對於OUT傳輸的情況，主機在發送一個短包后可以停止發送數據包。主機應該在對該端點的另一個傳輸被發起之后來調度對於該設備端點的事務。注意這應該是對該端點的新的一次突發的開始。

8.11 TP或者DP的響應

發送和接收設備應該按照表8-25到表8-27所示的細節來返回數據包（DPs）或者事務包（TPs）。不是所有的事務包（TPs）都是被允許的，這依賴於傳輸類型和TP流向。

8.11.1 設備對請求數據的TP的響應【Device Response to TP Requesting Data】

表 8-25. 設備對於請求數據的TP的響應 (Bulk, Control, 和 Interrupt端點)

接收到無效的TP	接收到Deferred 比特被設置的TP	設備的Tx Endpoint Halt 特性被設置	設備准備好傳送數據	采取的動作
Yes	不關心	不關心	不關心	設備應該忽略TP。
No	Yes	Yes	不關心	設備應該發送一個ERDY TP。
No	Yes	No	No	設備不應該響應。它應該在准備好恢復時發送一個ERDY TP。
No	Yes	No	Yes	設備應該發送一個ERDY TP指示他已經准備好接收數據。
No	No	Yes	不關心	發送STALL TP。
No	No	No	No	發送NRDY TP。
No	No	No	Yes	開始傳送數據包（使用主機請求的序列號）。

注意IN端點應該等待它接收到上次發送的DP的ACK TP之后才能發送STALL TP【已勘誤】。

8.11.2 主機對從設備接收到的數據的響應

表8-26顯示了主機對於從設備的bulk, control, 和interrupt端點接受到數據的響應。主機只能返回一個ACK TP。如果DPH的Device Address不正確，或者端點號和方向沒有引用屬於當前配置的端點，或者沒有預期的序列號，或者DPH的Data length大於端點的最大包大小【已勘誤】，該DPH都會被認為是無效的。在表8-26中，DPP Error可能是由於下列的一個或者多個原因引起：

• CRC 不正確(incorrect)

• DPP 中止(aborted)

• DPP 丟失(missing)

• DPH 的Data length與數據負載的實際長度不匹配

表 8-26. 主機對從設備接收到的數據的響應(Bulk, Control, 和 Interrupt端點)

DPH 有無效值	數據包負載錯誤(Payload Error)	主機可以接受數據	主機返回的TP
Yes	不關心	不關心	丟棄數據且不發送任何TP
No	Yes	不關心	丟棄數據並發送一個Retry比特被設置的ACK TP，請求一個或者更多個數據包DPs，Sequence Number 字段設置為被損壞了的數據包的序列號。
No	No	No	丟棄數據並發送一個Retry 比特被設置的ACK TP，請求一個或者更多個數據包DPs，Sequence Number 字段設置為主機此前不能接收的數據包的序列號。這個ACK TP的Host Error比特應該被設置為1來指示主機此前不能接受該數據。
No	No	Yes	接受數據並發送一個Retry比特被設置的ACK TP，請求一個或者更多個數據包DPs，Sequence Number 字段設置為下一個預期的數據包的序列號。這也是一個對於該數據包成功接收的確認的暗示。

8.11.3 設備對從主機接收到的數據的響應

表8-27顯示了設備對於從主機的bulk, control, 和interrupt端點接收到數據的響應。如果DPH的Device Address不正確，或者端點號和方向沒有引用屬於當前配置的端點，或者沒有預期的序列號，該DPH都會被認為是無效的。在表8-27中, DPP Error可能是由於下列的一個或者多個原因引起：

• CRC 不正確(incorrect)

• DPP 中止(aborted)

• DPP 丟失(missing)

• DPH 的Data length與數據負載的實際長度不匹配

注意：除了告訴主機設備具有的可用來接收主機正待發送的數據包緩沖區的個數之外，（主機）接收到一個ACK TP還用來告訴主機，具有前一個序列號的數據包DP已經被該設備成功接收到。設備應該對每一個接收到的數據包DP都發送一個ACK TP。

表 8-27. 設備對OUT 事務的響應 (Bulk, Control, 和 Interrupt 端點)

DPH 有無效值	DPH 有Deferred比特被設置	接受者Halt特性被設置	數據包負載錯誤(Payload Error)	設備可以接受數據	設備返回的TP
Yes	不關心	不關心	不關心	不關心	丟棄數據
No	Yes	Yes	不關心	不關心	設備應該發送一個ERDY TP
No	Yes	No	不關心	No	設備不應該響應。它應該在准備好恢復時發送一個ERDY TP。
No	Yes	No	不關心	Yes	設備應該發送一個ERDY TP
No	Yes	No	不關心	不關心	設備應該發送一個STALL TP
No	No	No	不關心	No	丟棄數據並發送一個NRDY TP
No	No	No	Yes	Yes	丟棄數據並發送一個ACK TP，該ACK TP包含期望的序列號（以此來暗示這個數據包DP沒有被接收到），Retry 比特被設置，以及該設備端點還可以接收的DPs的個數
No	No	No	No	Yes	發送一個ACK TP，指示期望的下一個序列號（以此來暗示這個數據包DP已經成功被接收到）以及該設備端點還可以接收的DPs的個數

8.11.4 設備對於SETUP DP的響應

SETUP DP是特殊數據包DP，Setup字段被設置為1，且指定為尋址任意的控制端點。SETUP是一類特殊的主機到設備的數據傳輸，允許主機發起設備應該執行的命令。一旦接收到SETUP DP，設備應該按照表8-28所顯示的那樣來響應。

注意SETUP DPH如果有如下情況，應該被認為是無效的：

不正確的Device Address
端點號和方向沒有引用屬於當前配置的端點
端點號沒有引用控制端點
非零序列號
數據長度沒有設置為8

在表8-28中, DPP Error可能是由於下列的一個或者多個原因引起：
• CRC 不正確(incorrect)

• DPP 中止(aborted)

• DPP 丟失(missing)

• Setup DPH的Data length與數據負載的實際長度不匹配

表 8-28. 設備對於SETUP 事務的響應(只對Control端點)

DPH 有無效值	DPH有Deferred比特被設置	數據包負載錯誤(Payload Error)	設備返回的TP
Yes	N/A	N/A	丟棄數據包DP
No	Yes	N/A	設備應該發送一個ERDY TP指示它已經准備好接收SETUP DP
No	No	Yes	丟棄SETUP DP，並發送一個Sequence Number字段設置為0，Retry比特被設置，且NumP字段被設置為1的ACK TP
No	No	No	發送一個ACK TP，Sequence Number 字段設置為1（從而指示這個SETUP DP已經成功被接收到），NumP字段中的值指示主機是否設備想要對Data/Status階段做流程控制（flow control）。參考第8.12.2節的詳情。【已勘誤】

8.12 事務包序列【TP Sequences】

組成事務的包依端點類型的不同而有所不同。有4種端點類型：批量（bulk），控制(control)，中斷（interrupt），以及等時（isochronous）。

8.12.1 批量事務【Bulk Transactions】

批量事務類型以具有在主機和設備間通過錯誤檢測和重試來保證數據的無差錯傳輸而著稱。批量事務使用雙相位事務（two-phase transaction），包含事務包（TPs）和數據包（DPs）。在某種流程控制和掛起條件下，數據相位可能被TP所取代。

8.12.1.1 狀態機表示法信息

本節顯示詳細的用於在IN或OUT端點上推進協議（advance the Protocol）所要求的主機和設備狀態機。這些（狀態機）圖不應該被作為要求的實現（required implementation），而是用以指定要求的行為（required behavior）。

圖8-25顯示了狀態機圖的要件（legend）。有三線邊框的圓圈表示到另一層級狀態機的引用。有兩線邊框的圓圈表示初始狀態。單線邊框的圓是簡單的狀態。

鑽石形（接頭）用來連接幾個轉換（transitions）到一個共同點。接頭允許一個單輸入轉換到多個輸出轉換，或多個輸入轉換和一個單輸出轉換。包括一個接頭的路徑上所有轉換的條件都必須為真，該路徑才能被選取。路徑僅僅只是一系列包含一個或多個接頭的轉換。

轉換具有一個標注塊，標注塊中間有一條線，線上方是轉換的條件，線下方是轉換的動作。沒有線的轉換只是一個條件。條件必須為真才能進行該轉換。如果轉換被執行，轉換相關的動作就會被執行。動作和條件所使用的語言是VHDL語言。一個圈包含一個粗體的名字和可選的一個或者多個動作，當進入該狀態時就執行這些動作。

使用實線箭頭的轉換由主機生成。使用虛線箭頭的轉換由設備生成。使用斑點虛線箭頭的轉換要么由主機要么由設備生成。

8.12.1.2 Bulk IN 事務【Bulk IN Transactions】

當主機准備好接收批量數據，它就發送一個ACK TP給設備，指示它期望的從設備接收的包的序列號和包個數。Bulk端點將按照8.11.1所定義的那樣來響應。

主機應該對每一個它接收到的數據包DP發送一個ACK TP。如果主機的前一個ACK TP顯示主機期望設備發送多於一個數據包DP（根據TP的Number of Packets字段的值判斷），設備不必等待主機的ACK TP，就可以發送下一個數據包DP。ACK TP隱性確認主機已經成功地接收到具有前一個序列號的數據包DP，同時也向設備指示主機期望的從設備接收的包的序列號和包個數。如果主機在接收任意數據包DPs的過程中檢測到了錯誤，它應該發送一個ACK TP，序列號設置為接收到的錯誤包中的第一個DP的序列號，並將Retry比特設置上，即便主機請求的這個突發中的后續的包接收沒有錯誤也要如此。設備被要求重新發送Retry比特被設置的ACK TP中所指的序列號對應的數據包DP。

當主機在端點被初始化（通過Set Configuration，Set Interface，或者ClearFeature (ENDPOINT_HALT)命令——參考第9章關於這些命令的詳情）之后開始第一次傳輸時，主機期望第一個數據包DP的序列號被設置為0。該設備端點的第二個數據包DP序列號應該為1；第三個數據包DP序列號為2；以此下去，直到序列號31。在序列號31后的下一個數據包DP使用序列號0。設備上的端點繼續保持增加它傳送的數據包的序列號，直到它接收到一個Retry比特被設置的ACK TP，指示其需要重新傳送早先的一個DP。

如果主機從設備請求多個數據包，而設備在那時沒有那么多個數據包可用，設備應該在最后一個數據包的DPH中將End Of Burst標記設置為1。注意，如果發送到主機的數據包的數據負載長度小於該端點的MaxPacketSize，則沒有必要設置這個包的End Of Burst 標記。

當設備發送了主機期望的所有數據包，或者發送了一個數據包的數據負載長度小於該端點的MaxPacketSize，則一個傳輸完成。當主機想要開始一次新的傳輸時，主機發送一個ACK TP給設備，指示它期望的從設備接收的下一個包的序列號和包個數。例如，如果數據包的數據負載長度小於該端點的MaxPacketSize的包的序列號為2，那么主機就會發送一個ACK TP，其期望的包的序列號為3，來發起下一次傳輸。

8.12.1.3 Bulk OUT事務【Bulk OUT Transactions】

當主機准備好要發送數據時，就發送一個或者多個數據包（DPs）給設備。如果具有有效值的DPH（有效的設備地址，端點號，以及方向和期望的序列號）被設備接收到，就應該按照第8.11.3節所定義的那樣來做出響應。

當主機在端點被初始化（通過Set Configuration，Set Interface，或者ClearFeature (ENDPOINT_HALT)命令——參考第9章關於這些命令的詳情）之后開始第一次傳輸時，主機總是將其與該端點執行的第一個傳輸的第一個數據包的序列號初始化為0。第二個數據包的序列號設置為1；第三個數據包DP序列號設置為2；以此下去，直到序列號31。在序列號31后的下一個數據包DP使用序列號0。主機繼續保持增加它傳送的數據包的序列號，直到它接收到一個Retry比特被設置的ACK TP，指示其需要重新傳送早先的一個包。

當主機發送了所有的數據包到設備時一個傳輸就算完成。但是該傳輸的最后一個數據包的數據負載可能會（也可能不會）等於端點的MaxPacketSize。當主機想要開始一次新的傳輸時，就應該發送另一個數據包，使用下一個序列號，並用設備中的一個端點作為目標。

8.12.1.4 批量流協議【Bulk Streaming Protocol】

流協議（Stream Protocol）遵循（adheres to）標准超高速批量協議的語義，因此在支持流協議的超高速批量管道上的包交換和不支持流協議的超高速批量管道上的包交換不可區分（indistinguishable）。流協議（Stream Protocol）通過操作包頭中的Stream ID字段來嚴格進行管理。

注意：使用設備類定義的方法來協調Stream IDs（主機用於選擇Endpoint Buffers，而設備用於選擇與特定Stream相關聯的Function Data）。典型地，這是通過帶外機制（out-of-band mechanism）實現的（例如，另一個端點），用來在主機和設備之間傳遞"Active Stream IDs"的列表。

注意：Stream狀態機顯示發送一個DP和接收一個ACK TP之間1:1的關系。邏輯上這是真的，但是超高速突發能力（SuperSpeed burst capabilities）允許多達MaxBurst個在主機和設備之間的ACKs，因此可能臨時會有"多對一"的關系存在。Bursts在Stream pipe上的管理和他們在普通Bulk pipe上的管理一樣。參考第8.10.2節關於Burst Transactions的更多信息。【已勘誤】

注意：正如本節所描述的，流協議應用於"管道"的狀態，並且作為一個單一實體來描述。實際上，流協議被管道一端的主機和另一端的設備所獨立地跟蹤。因此在任意時刻，由於主機和設備間的包傳播時延，兩端可能出現暫時的相位不一致。

圖8-28闡釋了流協議狀態機【Stream Protocol State Machine（SPSM）】的基本狀態轉換。本節描述SPSM的總體狀態轉換，因為他們同時適用於IN和OUT端點。關於SPSM對於IN和OUT端點的詳細操作在后面的章節描述。

Disabled – 這是管道在被配置后的初始狀態，也是在其他任意狀態時檢測到錯誤后轉換到的狀態。在端點緩沖區被指派給管道時，主機應該將SPSM轉換到Prime Pipe狀態。如果Disabled狀態是因為錯誤而進入的，那么錯誤條件必須通過軟件干預移除后方可退出該狀態。注意，從設備來的Stall響應應該將任何SPSM狀態都轉換進入Disabled狀態。如果設備不響應（也就是說timeout），則主機應該發送一個Clear Feature Halt來復位該端點，在這種情況下，所有的SPSMs都應該轉換進入Disabled狀態。【已勘誤，澄清設備不會在timeout時做狀態轉換，因為它不知道事務是否已經timeout。】【譯注：這里其實還暗示了在Clear Feature Halt時，主機和設備端都應該做相應動作，轉換進入Disabled狀態。類似於USB2中Clear Feature Halt應該將主機和設備端的Data Toggle都恢復到DATA0。這在軟件上往往是容易出問題的地方，各個實現可能出現不一致。】

【Prime Pipe –總是由主機發起轉換到該狀態，並通知設備，一組端點緩沖區（Endpoint Buffer）已經由軟件加入或者修改。在從該狀態退出后，任何之前被設備認為是Not Ready的Active Stream IDs都應該被認為是已經Ready。

注意：為了減少總線事務，主機控制器將每次進入Idle狀態而轉換到Prime Pipe狀態的次數限制為1。這意味着當在Idle狀態時，只會生成一次到Prime Pipe狀態的轉換，盡管可能多個流（multiple streams）的Endpoint Buffers變得Ready。而由於Prime Pipe狀態並不指定哪個（些）Stream(s)已Ready，所有的Active Stream IDs都被Prime Pipe設置成Ready。設備應該負責通過在返回到Idle狀態后發送恰當的ERDYs，來測試所有的Active Stream IDs（如上面描述的那樣）。注意，設備類定義的限定（constraints）可能被用來限制在任何時間需要進行測試的Active Stream IDs的個數。

Idle – 轉換到這一狀態，指示沒有當前流（Current Stream）（CStream）被選取。在這一狀態，SPSM正等待由主機發起的到Prime Pipe或者到Move Data狀態的轉換；或者由設備發起的到Start Stream狀態的轉換。主機和設備發起轉換的目標，是開始為Stream搬移數據。由主機發起的到Move Data的轉換被稱為Host Initiated Move Data或者HIMD。所有的Active Stream IDs都被HIMD設為Ready。

Start Stream – 該狀態總是由設備當想要在一個選定的Stream上開始數據傳輸時發起。設備可以在每當它有一個Ready Stream ID時，發起一個到該狀態的轉換。如果設備選擇的Stream被主機接受，則管道進入Move Data狀態。如果設備選擇的Stream ID被主機拒絕，管道就返回到Idle狀態，並且被選擇的Stream ID應該被設備臨時認為是Not Ready。注意，設備維護一個Active Stream IDs的列表。一個Active Stream ID可能Ready，也可能Not Ready。設備被主機通過帶外機制（out-of-band mechanism）告知Active Stream IDs（典型地是通過一個單獨的OUT端點）。

Move Data – 在這一狀態，流數據（Stream data）被傳輸。當轉換進入該狀態時，Current Stream被設置。當流傳輸（Stream transfer）完成后，或者如果主機或設備由於臨時耗盡了它們的數據或緩沖空間而決定要終結流傳輸（Stream transfer）時, SPSM 轉換回到Idle狀態。轉換到Idle狀態同時使得管道的Current Stream (CStream) 變得無效。】【已勘誤】

【譯注：流狀態機在原先設計時基於一個假設，即如果在一次突發（burst）中，如果檢測到了錯誤，則要求所有的重試（retries）都要完成，這個突發才能完成，也就是說，如果NumP = 0，則Rty不允許是1。核心規范在USB3_Errata [June 2010]中已經被修改，當NumP = 0時可以允許Rty是1。現在，這就意味着Rty可以跨多個突發（retries can span bursts）。本譯文根據USB3_Errata [June 2010]的描述對流狀態機的相應部分做了更正，以反映這一核心規范的修改。在下面的譯文中，相關勘誤處標記了"勘誤：Rty可以跨多個突發"。】

8.12.1.4.1 Stream IDs

一個16比特Stream ID字段被保留在數據包DP頭以及ACK, NRDY, 和ERDY TP事務包中，用以在主機和設備之間傳遞SIDs。流協議所保留的特定的SID值以及其他一些SID表示法如下：

• NoStream – 這個SID指示沒有Stream ID與相關的總線包相關聯，因此Stream ID字段不應該被當作有效Stream來解釋。NoStream SID的值為FFFFh 。

• Prime – 這個SID被用來定義轉換進或出Prime Pipe狀態。與NoStream一樣，沒有Stream ID與相關的總線包相關聯，因此Stream ID字段不應該被當作有效Stream來解釋。Prime SID 的值是FFFEh。

• Stream n – 此處n是一個在1到65533 (FFFDh)之間的值。這個表示法用來引用一個有效的Stream ID。如果使用這個表示法，則表示包頭中的Stream ID字段為有效。有效的Stream n SID值在1到65533 (FFFDh) 之間，其中數字值等於n。

• Stream 0 – 這個值是被保留的，不被支持流的管道所使用。Stream 0 SID值是0000h。標准的批量管道要求使用它。

• CStream – 代表與管道相關聯的"當前(Current)" Stream ID。CStream由主機和設備共同維護。流協議確保CStream值在主機和設備間一致。有效值是NoStream或者Stream n。

• LCStream – 代表在上一次狀態轉換之前賦予管道的CStream SID值。LCStream值由主機維護。有效值是Prime, NoStream, 或者Stream n。例如，如果管道在Move Data狀態時CStream = Stream n，當管道從Move Data轉換到Idle狀態，LCStream就設為Stream n，並且CStream被設置為NoStream，因此LCStream就記錄了"Last CStream"的值。

Stream n SID的值由主機指定，並且傳遞給設備（典型地是通過帶外（out-of-band），設備類定義的方法實現）。Stream n SID的值應該被設備作為"邏輯值"，也就是說，設備不應該根據其值來推斷其意義，或者對其進行修改。

注意：下面的批量IN和OUT的流協議描述簡化了的狀態機，不明確地解釋超高速端點允許數據包在無需接收到ACK之前就可以發送數據包這一突發（burst）特性的細節。具體實現應該擴展這些狀態機，來管理突發事務（manage bursting）。

【

下面幾節(第8.12.1.4.2節到第8.12.1.4.5節) 將Stream狀態機根據設備端和主機端的Stream管道而分開成4種情形。第8.12.1.4.2節和第8.12.1.4.3節描述設備端狀態機。第8.12.1.4.4節和第8.12.1.4.5節描述主機端狀態機。而對管道的每一端，都有單獨一節來描述相應的IN和OUT操作。

每個Stream狀態機的子章節描述狀態機的相關狀態。子章節以描述狀態的目的和總體特性開始，接着討論狀態的每個退出轉換。描述狀態的退出轉換的段落前有一個唯一的在前一狀態圖中相關退出轉換的"條件（condition）"或"動作（action）"的標簽。

注意：在主機和設備之間路徑上的U1或U2超時值應該被設置為可以防止對Data Transactions的正常響應而轉換到U1或U2。參考第8.13節關於Data Transaction的更多時序信息。

注意：在Stream狀態機一節，狀態名稱是被重載的（overloaded），例如，Idle狀態在所有4個狀態機描述中都有定義。INMvData Host狀態在設備和主機的IN狀態機兩節都有定義，等等。這些狀態是相關的，因為它們可能在Stream管道的兩端都出現，但是每個Stream狀態機小節都描述一個獨立的狀態機，因此與狀態相關的條件和動作在各節都是清楚明顯的（distinct）。

注意：斜體的轉換條件應該被解釋為注釋，而不是要求的條件。例如，圖8-1中的從Idle到Start Stream轉換的文本"Stream n Active and Ready"。

注意：任何的CStream的數據負載都可能是零長（zero-length）。在Stream管道上對零長（zero-length）DPs的使用（而不是用於Prime Pipe或者拒絕Start Stream操作）是由與端點關聯的設備類定義的。

注意：一個IN Data或者Burst Transaction是由一個NumP = 0的ACK TP終結的。這個ACK TP在下面幾節被稱為"終結ACK（Terminating ACK）"。

】

8.12.1.4.2 設備輸入流協議【Device IN Stream Protocol】

本節定義在IN Bulk端點上，使得設備端的流協議（Stream Protocol）從一個狀態轉換到另一個狀態的超高速包交換（SuperSpeed packet exchanges）。

在下文中，假設Device IN Stream狀態轉換發生在設備發送與狀態機相關的消息的第一個符號的第一個比特給主機時，或者當設備首次解碼從主機來的狀態機相關的消息時。對於IN管道，主機端的Endpoint Buffers接收來自設備的Function Data。

【勘誤：上圖中 "Stall or Error" 應該重命名為"Stall or Clear Feature Halt"，去除timeout的情形。】

8.12.1.4.2.1 Disabled

在端口被配置后，管道狀態處於Disabled狀態。

ACK(Prime, NumP>0, PP=0) – 如果接收到Stream ID設置為Prime的ACK TP，則設備應該將管道轉換進入Prime Pipe狀態。這一轉換發生在初始Endpoint Buffers被系統軟件指派給管道之后。

ACK(Deferred) – 如果接收到一個Deferred (DF)標志被設置的ACK TP，則設備應該將管道轉換進入Deferred Prime Pipe狀態。當在等待被指派初始Endpoint Buffers的時候，鏈路轉換進入了U1或U2狀態，會收到這個包。

8.12.1.4.2.2 Prime Pipe

Prime Pipe狀態通知設備，已經有Endpoint Buffers被指派給一個或多個Streams，但是沒有指定是哪些Stream(s)。在這個狀態，設備應該將所有的Active Streams設為Ready。在返回Idle狀態之后，設備應該發送一個ERDY，來從它的Active Streams列表中啟動一個特定的Stream。

NRDY(Prime) – 當進入Prime Pipe狀態時, 設備應該生成一個Stream ID設為Prime的NRDY TP，並轉換到Idle狀態。

8.12.1.4.2.3 Deferred Prime Pipe

Deferred Prime Pipe狀態通知設備，已經有Endpoint Buffers被指派給一個或多個Streams，但是在等待時鏈路已經轉換到U1或U2狀態。在這個狀態，設備應該將所有的Active Streams設為Ready。在返回Idle狀態之后，設備應該發送一個ERDY，來從它的Active Streams列表中啟動一個特定的Stream。

No Condition – 當進入Deferred Prime Pipe狀態時，設備應該立即轉換到Idle狀態。這是圖8-1中唯一的Deferred Prime Pipe狀態的退出轉換。

8.12.1.4.2.4 Idle

在Idle狀態，管道在等待一個Stream選擇（Stream selection）（例如，到Start Stream或Move Data的一個轉換），或者一個從主機來的通知，告知一個Stream Endpoint Buffer已經為該管道而被添加或修改（即，轉換到Prime Pipe）。注意，在初始進入Idle時（從Disabled），只有設備可以發起一個Stream選擇（Stream selection）。

ERDY(Stream n, NumP>0) – 為了發起Stream選擇（Stream selection），設備生成一個ERDY TP，將其Stream ID設為Stream n，且NumP值>0，並轉換到Start Stream狀態，其中的Stream n是設備建議的（proposed）Stream ID。設備可以在它想要開始一次Stream transfer時發起這個轉換，無論管道是否處於流程控制（flow control）情形。設備維護一個可以為之生成ERDYs的Active and Ready Streams的列表。設備用於Stream選擇（Stream selection）的方法超出了本規范的范圍，通常是由與管道相關的設備類所定義。注意ERDY NumP字段反映了設備的Stream n可用的Endpoint Data的數量。
ACK(Prime, NumP>0, PP=0) – 如果從主機接收到了Stream ID等於Prime的ACK TP，則設備應該轉換到Prime Pipe狀態。

ACK(Stream x, NumP>0) – 使用這個轉換，主機向設備建議Stream ID Stream x。如果從主機接收到Stream ID不等於Prime的ACK TP，設備應該轉換到Move Data狀態。主機可以在它想要開始一次Stream transfer時發起這個轉換，而這被稱為Host Initiated Move Data，或者說HIMD。HIMD指示Endpoint Buffer已經為之改變的特定Stream。由於這一轉換，設備應該將Stream x設為Ready。在進入Move Data狀態之后，設備可以用NRDY來拒絕該被建議的（proposed）Stream，或者用一個DP來接受該被建議的（proposed）Stream。當轉換到Move Data狀態的時候，設備將CStream設置成接收到的Stream ID (Stream x)。典型地，Stream x將等於設備上一次生成的ERDY中的Stream ID (Stream n)。如果下面描述的競爭條件（race condition）發生，則Stream x可以不等於Stream n，因為主機在這些條件下會丟棄ERDYs。PP應該等於1。

ACK(Deferred) – 如果接收到Deferred (DF)標志被設置的ACK TP，則設備應該將管道轉換進入Deferred Prime Pipe狀態。當鏈路已經轉換進入U1或U2狀態，且主機已經嘗試了一個HIMD時，會接收到這個包。

8.12.1.4.2.5 Start Stream

在Start Stream狀態，設備正在等待主機接受或拒絕設備建議的Active and Ready Stream的選擇。

ACK(Stream n, NumP>0) – 如果接收到Stream ID等於Stream n的ACK TP，則主機已經接受了設備提出的開始Stream n的建議，而設備應該轉換進入Move Data狀態。當轉換到Move Data狀態的時候，設備將CStream設置成接收到的Stream ID (Stream n)。PP應該等於1。

ACK(NoStream, NumP=0, PP=0) – 如果接收到Stream ID等於NoStream的ACK TP，則主機已經拒絕了設備提出的開始Stream n的建議，而設備應該轉換進入Idle狀態。因為這一轉換，設備應該將Stream n設置到Not Ready。如果沒有Endpoint Buffers可用，則主機應該拒絕從設備來的建議。

ACK(Prime, NumP>0, PP=0) –如果從主機接收到的Stream ID等於Prime的ACK TP，則發生了競爭條件（race condition）。主機已經進入了Prime Pipe狀態，通知設備有一個或者多個Streams的Endpoint Buffers被更新，而同時設備也已試圖發起Stream transfer，而且他們相應的消息都通過鏈路傳遞到了對方。在這個情形期間，設備處於Start Stream狀態，而主機處於Prime Pipe狀態。為了解決這個情況，設備應該轉換到Prime Pipe狀態。

ACK(Stream x, NumP>0) – 如果接收到Stream ID等於Stream x的ACK TP，則發生了競爭條件（race condition）。主機已經進入了Move Data狀態，啟動在Stream x上的傳輸，而同時設備也已試圖發起在Stream n上的一次傳輸，而且他們相應的消息都通過鏈路傳遞到了對方。在這個情形期間，設備處於Start Stream狀態，而主機處於Move Data狀態。為了解決這個情況，設備應該轉換到Move Data狀態。因為這一轉換，設備應該將Stream x設置到Ready。當轉換到Move Data狀態的時候，設備將CStream設置成接收到的Stream ID (Stream x)。PP應該等於1。

ACK(Deferred) – 如果接收到Deferred (DF)標志被設置ACK TP【已勘誤，去掉要求Stream ID是Prime這一條件】，則設備應該將管道轉換進入Deferred Prime Pipe狀態。當在等待主機響應Start Stream請求時，鏈路被轉換進入U1或U2狀態時，會接收到這個包。注意這一轉換只有在tERDYTimeout過期時才會發生。【譯注：處於Start Stream狀態的設備可能會接收到Deferred ACK TP，其中的Stream ID可能是Prime，也可能是LCStream（如果是因為HIMD的話）。在這兩種情況下，設備都應該返回到Idle狀態。】

注意：在Idle和Start Stream狀態中的"PP應該等於1"一句，並不要求設備為相關的轉換去驗證PP，但是，如果設備的確要檢查，如果PP不等於1，則它應該將EP停止（halt）。

8.12.1.4.2.6 Move Data

在Device IN Move Data狀態，CStream在管道的兩端都設為相同值，且管道可以積極搬運數據。在Move Data狀態所執行的總線事務的詳情以及它的退出條件在Device IN Move Data State Machine中定義。

【勘誤：上圖中的INMvData Device Terminate到exit的轉換的標簽ACK(CStream, NumP=0, PP = 0)，應該改為ACK(CStream, NumP=0)。這是為了覆蓋"主機還有更多緩沖空間可用，而設備已終結了這個突發"的情形。】

【勘誤：Rty可以跨多個突發。

去掉從INMvData Host到exit的ACK(Deferred)轉換。

去掉從INMvData Device Terminate到exit的ACK(Deferred)轉換。

添加從INMvData Device Terminate到INMvData Burst End的ACK(CStream, NumP=0, PP=1, Rty)轉換。

因此，上面的狀態機圖可以用下面的狀態機圖替換。為對比起見，先保留原圖，並將修改后的狀態機圖附於下面。

】

Device IN Move Data State Machine (DIMDSM)是從上面描述的Start Stream或Idle狀態進入的。一旦進入DIMDSM，立即就轉換進入INMvData Device狀態。DIMDSM允許設備由於耗盡與Stream相關的Function Data而終結Move Data操作，也允許主機因耗盡與Stream相關的Endpoint Buffer空間而終結Move Data操作。

DIMDSM總是退出到Idle狀態。Retry (Rty=1) 標志在導致DIMDSM退出的包中絕不該設置。Stream管道在包重試期間保持在Move Data狀態。

注意：在Move Data狀態期間所交換的所有包的Stream ID值都應該是CStream。如果在DIMDSM期間檢測到Stream ID值不是CStream，設備應該halt端點。

注意：如果在初始進入Move Data狀態時CStream不是Active的，則設備可以使用設備類定義的NRDY或STALL拒絕該Stream建議。

8.12.1.4.2.7 INMvData Device

這一狀態最初是從Start Stream狀態或Idle狀態進入的。在該狀態，設備准備一個DP發給主機，或者拒絕從主機來的HIMD。

DP(CStream, EOB=0) – 如果設備對CStream的Endpoint Data超過Max Packet Size，則設備應該發送一個EOB = 0的DP給主機，並轉換進入INMvData Host狀態。DPP應該包含CStream的數據。

DP(CStream, EOB=1) – 如果設備對CStream的Endpoint Data少於或等於Max Packet Size，則設備可以（may）發送一個EOB = 1的DP給主機，並轉換進入INMvData Device Terminate狀態。DPP應該包含CStream的數據。【已勘誤】【譯注：並不是必須要求要設置EOB，除非設備想要進行流程控制（flow control）。】

NRDY(CStream) – 設備可以通過發送一個Stream ID設為CStream的NRDY來拒絕進一步的CStream transfers，並轉換進入Idle狀態，退出DIMDSM。設備可以在最初進入到DIMDSM時為拒絕HIMD，也可以在Stream transfer期間由於不可預期的內部情況而想要流程控制（flow control）CStream時, 生成該轉換。

8.12.1.4.2.8 INMvData Host

在該狀態，設備剛剛發送了一個DP給主機，且還有更多給CStream的Function Data。設備在該狀態等待來自主機的對上一DP的確認。

ACK(CStream, NumP>0, PP=1) - 如果設備接收到NumP > 0且PP = 1的ACK TP，則應該轉換進入INMvData Device狀態。這是主機在當前突發（current burst）還未完成，且它還有為CStream DP的更多Endpoint Buffer空間可用時的響應。注意，如果主機檢測到在上一個DP中有錯誤，則Retry (Rty=1)可以被設置。如果Rty被設置，則設備應該在它下次發送一個DP時使用恰當的Sequence Number返回該DP。如果檢測到DP錯誤，主機可以(may)繼續當前突發（current burst），直到所有重試都耗盡，或者收到一個好包。如果在主機不能繼續當前突發（current burst）的情況下，主機將會在該端點類型限制內的下一個可用機會時回到該端點。【已勘誤，原文檔說主機"應該(shall)"繼續當前突發，現在更正為"可以(may)"。這簡化了主機的行為，並且去除了因為要等待其他端點請求多次重試而使得周期性傳輸遭受飢餓(starved)的情形。此外，核心規范並沒有重試次數的限制（一般來說是3次）。】

ACK(CStream, NumP=0, PP=1) – 如果設備接收到NumP = 0且PP = 1的ACK TP，則應該轉換進入INMvData Burst End狀態。這是主機在它還有更多的為另一個CStream DP的Endpoint Buffer空間可用，但它又必須終結從設備來的當前突發（current burst）時的響應。注意在從INMvData Host到INMvData Device的轉換期間，設備應該看到隨着突發趨於完成，NumP也向着0遞減。注意，如果主機檢測到在從設備來的上一個DP中有錯誤，則Retry (Rty=1)可以被設置。

ACK(CStream, NumP=0, PP=0) – 如果設備接收到NumP = 0 且 PP = 0的ACK TP，則應該轉換進入Idle狀態，退出DIMDSM。這是主機在它接受了上一個DP而耗盡其CStream Endpoint Buffer空間時的響應。設備應該因為這個轉換而將其CStream設為Not Ready。在從INMvData Host到INMvData Device轉換期間，設備應該看到隨着Endpoint Buffer被消耗，NumP也向着0遞減。

ACK(Deferred) –如果設備接收到Deferred (DF)標志被設置的ACK TP，則應該轉換進入Idle狀態，退出DIMDSM。當設備在等待主機用一個ACK響應一個DP時鏈路轉換進入U1或U2，會收到這個包。注意這個轉換是可能的（possible），但極不易（highly unlikely）。

注意：在INMvData Host狀態接收到NumP > 0 且 PP = 0的ACK TP是非法的組合，如果檢測到的話，設備應該halt端點。

8.12.1.4.2.9 INMvData Device Terminate

進入這一狀態是因為設備已經發送了CStream的最后一個可用DP，即它已經耗盡了其CStream Function Data。設備在該狀態等待來自主機的對該Move Data transfer上一DP的確認。

ACK(CStream, NumP=0, No Rty) - 如果設備接收到NumP = 0且Rty = 0的ACK TP，則應該轉換進入Idle狀態，退出DIMDSM。這是主機確認從設備來的CStream的上一個DP時的正常主機響應（Terminating ACK）。

ACK(CStream, NumP>0, PP=1, Rty) –如果設備接收到Rty = 1的ACK TP，則應該轉換進入INMvData Device狀態，並重發恰當的包（resend the appropriate DP）。這是主機在檢測到從設備來的DP中有錯誤，而突發尚未完成時的主機響應。

ACK(CStream, NumP=0, PP=1, Rty) –如果設備接收到Rty = 1而NumP = 0的ACK TP，則應該轉換進入INMvData Burst End狀態，並等待主機發起下一個突發（initiate the next burst）。這是主機在檢測到從設備來的DP中有錯誤，但突發已經完成（burst was complete）時的主機響應。主機應該在下一個突發中繼續重試過程(continue the retry process in the next burst)。

8.12.1.4.2.10 INMvData Burst End

進入該狀態是因為主機已經終結了一個Stream管道上的一個突發。在該狀態設備等待一個ACK TP來表示另一個突發的開始。

ACK(CStream, NumP>0, PP=1) – 如果設備接收到NumP > 0且PP = 1的ACK TP，則應該轉換進入INMvData Device狀態。注意，如果Rty標志在進入該狀態時是被設置的，則在退出該狀態時Rty標志也應該被設置。

ACK(Deferred) –如果設備接收到Deferred (DF)標志被設置的ACK TP，則應該轉換進入Idle狀態，退出DIMDSM。這個轉換發生在當設備在等待主機重新開始突發（restart a burst）時鏈路轉換進入U1或U2，而且這個轉換隨着與其他設備的傳輸活動增加時會變得越加可能（becomes more likely）。

8.12.1.4.3 設備輸出流協議【Device OUT Stream Protocol】

本節定義在OUT Bulk端點上，使得設備端流協議（Stream Protocol）從一個狀態轉換到另一個狀態的超高速包交換（SuperSpeed packet exchanges）。

在下文中，假設Device OUT Stream狀態轉換發生在當設備發送與狀態機相關的消息的第一個符號的第一個比特給主機時，或者當設備首次解碼從主機來的狀態機相關的消息時。對與OUT管道，主機端的Endpoint Data發送給設備的Function Buffers。除非特別說明，DP將包含Endpoint Data。

【勘誤：上圖中 "Stall or Error" 應該重命名為"Stall or Clear Feature Halt"，去除timeout的情形。】

【勘誤：上圖中，從Idle狀態到Start Stream End狀態之間，應該添加一條弧線(arc)，標簽為DP(NoStream,PP=0)。在轉換進入U0后，設備會立即發送一個ERDY，導致DOSPSM和HOSPSM從Idle狀態轉換進入Start Stream狀態。在轉換進入Start Stream狀態之后，設備從一個集線器處接收到一個DPH(Deferred)，導致DOSPSM轉換到Idle狀態。在這一刻，DOSPSM和HOSPSM變得不同步（out of sync）。HOSPSM正處於Start Stream狀態，就發送一個DP(NoStream, PP=0)；然而設備正處於Idle，從而不能處理這個包。】

8.12.1.4.3.1 Disabled

在端口被配置后，管道狀態處於Disabled狀態。

DP(Prime, PP=0) – 如果成功接收到Stream ID設置為Prime的DP，則設備應該將管道轉換進入Prime Pipe狀態。DPP應該包含零長（zero-length）數據負載。這一轉換發生在初始Endpoint Buffers被系統軟件指派給管道之后。注意，如果在DP數據中檢測到錯誤（盡管是零長的），設備應該保持在Disabled狀態，並發送ACK(Prime, NumP>0, Rty)包，重試，直到一個DP(Prime)被成功接收到。這種情況沒在上圖說明。

DPH(Deferred) – 如果接收到一個Deferred (DF)標志被設置的DP，則設備應該將管道轉換進入Deferred Prime Pipe狀態。在等待被指派初始Endpoint Data的時候，鏈路轉換進入了U1或U2狀態，會收到這個包。

8.12.1.4.3.2 Prime Pipe

Prime Pipe狀態通知設備，已經有Endpoint Data被指派給一個或多個Streams，但是沒有指定是哪些Stream(s)。在返回Idle狀態之后，設備應該發送一個ERDY，來從它的Active and Ready Streams列表中啟動一個特定的Stream。

NRDY(Prime) – 當進入Prime Pipe狀態時, 設備應該生成一個Stream ID 設為Prime的NRDY TP，並立即轉換到Idle狀態。

8.12.1.4.3.3 Deferred Prime Pipe

Deferred Prime Pipe狀態通知設備，已經有Endpoint Data被指派給一個或多個Streams，但是在等待時鏈路已經轉換到U1或U2狀態。

No Condition – 當進入Deferred Prime Pipe狀態時，設備應該立即轉換到Idle狀態。

8.12.1.4.3.4 Idle

在Idle狀態，管道在等待一個Stream選擇（Stream selection）（例如，到Start Stream或Move Data的一個轉換），或者一個從主機來的通知，Endpoint Data已經為該管道而被添加或修改（即，轉換到Prime Pipe）。注意到在初始進入Idle時,只有設備可以發起一個Stream選擇（Stream selection）。

ERDY(Stream n, NumP>0) – 為了發起Stream選擇（Stream selection），設備生成一個ERDY TP，將其Stream ID設為Stream n，且NumP值>0，並轉換到Start Stream狀態，其中的Stream n是設備建議的（proposed）Stream ID。設備可以在它想要開始一次Stream transfer時發起這個轉換，無論管道是否處於流程控制（flow control）情形。設備維護一個可以為之生成ERDYs的Active and Ready Streams的列表。設備用於Stream選擇（Stream selection）的方法超出了本規范的范圍，通常是由與管道相關的設備類所定義。注意ERDY NumP字段反映了設備為Stream n可用的Endpoint Buffer空間的數量。

DP(Prime, PP=0) – 如果從主機成功接收到了Stream ID等於Prime的DP，則設備應該轉換到Prime Pipe狀態。DPP應該包含零長（zero-length）數據負載。注意，如果在DP數據中檢測到錯誤，設備應該保持在Idle狀態，並發送ACK(Prime, NumP>0, Rty)包，重試，直到一個DP(Prime)被成功接收到。DPP應該包含零長（zero-length）數據負載。

DP(Stream x) – 使用這個轉換，主機向設備建議Stream ID Stream x。如果從主機接收到的Stream ID不等於Prime的DP，設備應該轉換到Move Data狀態。主機可以在它想要開始一次Stream transfer時發起這個轉換，而這被稱為Host Initiated Move Data，或者說HIMD。HIMD指示Endpoint Data已經為之改變的特定Stream。由於這一轉換，設備應該將Stream x設為Ready。在進入Move Data狀態之后，設備可以用NRDY來拒絕該被建議的（proposed）Stream，或者用一個ACK TP來接受該被建議的（proposed）Stream。當轉換到Move Data狀態的時候，設備將CStream設置成接收到的Stream ID (Stream x)。DPP應該包含對該Stream的第一個數據包負載。典型地，Stream x將等於設備上一次生成的ERDY中的Stream ID (Stream n)。如果下面描述的競爭條件（race condition）發生，則Stream x可以不等於Stream n，因為主機在這些條件下會丟棄ERDYs。

ACK(Deferred) – 如果接收到Deferred (DF)標志被設置的DPH，則設備應該將管道轉換進入Deferred Prime Pipe狀態。當鏈路已經轉換進入U1或U2狀態，且主機已經嘗試了Prime Pipe或Move Data（HIMD）轉換時，可能會接收到這個包。

8.12.1.4.3.5 Start Stream

在Start Stream狀態，設備正在等待主機接受或拒絕設備建議的Active and Ready Stream的選擇。

DP(Stream n) – 如果接收到Stream ID等於Stream n的DP，則主機已經接受了設備提出的開始Stream n的建議且提供了Stream n的數據的第一個包，而設備應該轉換進入Move Data狀態。當轉換到Move Data狀態的時候，設備將CStream設置成接收到的Stream ID (Stream n)。DPP應該包含CStream的第一個數據負載。

DP(NoStream, PP=0) – 如果成功接收到Stream ID等於NoStream的DP，則主機已經拒絕了設備提出的開始Stream n的建議，而設備應該轉換進入Start Stream End狀態。DPP應該包含一個零長（zero-length）數據負載。如果沒有給Stream的Endpoint Data，則主機應該拒絕從設備來的建議。因為這一轉換，設備應該將Stream n設置到Not Ready。注意，如果在DP數據中檢測到錯誤，設備應該保持在Start Stream狀態，並發送ACK(Prime, NumP>0, Rty)包，重試，直到一個DP(NoStream)被成功接收到。這個情形沒有在上圖中說明。

DP(Prime, PP=0) –如果從主機接收到的Stream ID不等於Prime的DP，則發生了競爭條件（race condition）。主機已經進入了Prime Pipe狀態，通知設備有一個或者多個Streams的Endpoint Data被發布（posted），而同時設備也已試圖發起Stream transfer，而且他們相應的消息都通過鏈路傳遞到了對方。DPP應該包含一個零長（zero-length）數據負載。在這個情形期間，設備處於Start Stream狀態，而主機處於Prime Pipe狀態。為了解決這個情形，設備應該轉換到Prime Pipe狀態。注意，如果在DP數據中檢測到錯誤，設備應該轉換進入Prime Pipe狀態並在那里進行任何重試。

DP(Stream x) – 如果接收到Stream ID不等於Stream n，Prime 或 NoStream（即，等於Stream x）的DP，則發生了競爭條件（race condition）。主機已經進入了Move Data狀態，啟動在Stream x上的傳輸，而同時設備也已試圖發起在Stream n上的一次傳輸，而且他們相應的消息都通過鏈路傳遞到了對方。在這個情形期間，設備處於Start Stream狀態，而主機處於Move Data狀態。為了解決這個情形，設備應該轉換到Move Data狀態。因為這一轉換，設備應該將Stream x設置到Ready。當轉換到Move Data狀態的時候，設備將CStream設置成接收到的Stream ID (Stream x)。DPP應該包含CStream的第一個數據負載。當在Move Data狀態時，設備可以接受或者拒絕由主機建議的Stream。

DPH(Deferred) – 如果接收到Deferred (DF)標志被設置的DPH，則則設備應該將管道轉換進入Deferred Prime Pipe狀態。當在等待主機響應Start Stream請求，鏈路被轉換進入U1或U2狀態時，會接收到這個包。注意這一轉換只有在tERDYTimeout被超過時才會發生，因此是極不易（highly unlikely）發生的。在這種情形下，設備被期望用ERDY來重試。沒有與deferred DPH相關聯的DPP。

8.12.1.4.3.6 Start Stream End

在Start Stream End狀態，設備已經收到了主機對它建議的Stream選擇（Stream selection）的拒絕，且必須對主機發來的DP做出響應。Bulk協議要求對任何已經發送的DP要有一個ACK 或 NRDY。Streams協議指定發送一個NRDY。

NRDY(NoStream) – 設備應該生成一個Stream ID等於NoStream的NRDY，並轉換到Idle狀態。

8.12.1.4.3.7 Move Data

在Device OUT Move Data狀態，CStream在管道的兩端都設為相同值，且管道可以積極搬運數據。在Move Data狀態所執行的總線事務的詳情以及它的退出條件在Device OUT Move Data State Machine中定義。

Device OUT Move Data State Machine (DOMDSM)是從上面描述的Start Stream或Idle狀態進入的。DOMDSM允許設備由於耗盡與Stream相關的Function Buffer空間而終結Move Data操作，也允許主機因耗盡與Stream相關的Endpoint Data而終結Move Data操作。

PP=0 – 在進入DOMDSM時，如果主機只有Stream的一個包的Endpoint Data可用，則PP應該在設備接收到的第一個DP中等於0，且它將轉換進入OUTMvData Device Terminate狀態。

PP = 1 – 在進入DOMDSM時，如果主機有Stream的多於一個包的Endpoint Data可用，則PP應該在設備接收到的第一個DP中等於1，且它將轉換進入OUTMvData Device狀態。

DOMDSM總是退出到Idle狀態。Retry (Rty=1) 標志在導致DOMDSM退出的包中絕不該設置。Stream管道在包重試期間保持在Move Data狀態。

注意：在Move Data狀態期間所交換的所有包的Stream ID值都應該是CStream。如果在DOMDSM期間檢測到Stream ID值不是CStream，設備應該halt端點。

注意：如果在初始進入Move Data狀態時CStream不是Active的，則設備可以使用設備類定義的NRDY或STALL拒絕該Stream建議。

8.12.1.4.3.8 OUTMvData Device

這一狀態初始是從Start Stream狀態或Idle狀態進入的。在該狀態設備確認主機發送的上一個DP，或者拒絕從主機來的HIMD。

ACK(CStream, NumP>0) – 如果設備對CStream有更多Function Buffer可用，則設備應該發送一個NumP > 0的ACK TP給主機，並轉換進入OUTMvData Host狀態。注意，如果設備在從主機來的上一個DP中檢測到了錯誤，則Retry (Rty)標志可以被設置。主機可以(may)繼續當前突發（current burst），直到所有的重試都耗盡，或者正面確認【positive acknowledgement (Rty=0)】被接收到。如果在主機不能繼續當前突發（current burst）的情況下，主機將會在該端點類型限制內的下一個可用機會時回到該端點。【已勘誤，原文檔說主機"應該(shall)"繼續當前突發，現在更正為"可以(may)"。這簡化了主機的行為，並且去除了因為要等待其他端點請求多次重試而使得周期性傳輸遭受飢餓(starved)的情形。此外，核心規范並沒有重試次數的限制（一般來說是3次）。】這個轉換應該指示此前接收到的CStream的DP的數據負載已經被端點所接受。

ACK(CStream, NumP=0) – 如果設備對CStream沒有Function Buffer可用，則設備應該發送一個NumP = 0的ACK TP給主機，退出DOMDSM，並轉換進入Idle狀態。這一轉換允許設備在其Endpoint Buffer空間被耗盡時從Move Data狀態退出。這個轉換應該指示此前接收到的CStream的DP的數據負載已經被端點所接受。

NRDY(CStream) – 設備可以通過發送一個Stream ID設為CStream的NRDY來拒絕進一步的CStream transfers，並轉換進入Idle狀態，退出DOMDSM。設備可以在初始進入到DOMDSM時為拒絕HIMD，也可以在Stream transfer期間由於不可預期的內部情況而想要流程控制（flow control）CStream時，生成該轉換。這個轉換應該指示此前接收到的DP的數據負載已經被丟棄。

8.12.1.4.3.9 OUTMvData Host

在該狀態，主機剛剛從設備處接收到此前一個DP的ACK TP，且還有更多給CStream的Endpoint Data。主機在該狀態生成一個DP。管道也將在該狀態的主機來的突發（bursts）之間等待（wait in this state between bursts from the host）。

DP(CStream, PP=1) – 如果設備接收到PP = 1的DP，則應該轉換進入OUTMvData Device狀態。DPP應該包含一個CStream數據負載。這是主機在它有為CStream多於Max Packet Size的Endpoint Data可用時的響應。

DP(CStream, PP=0) – 如果設備接收到PP = 0的DP，則應該轉換進入OUTMvData Host Terminate狀態。DPP應該包含一個CStream數據負載。這是主機在它已經耗盡為CStream的Endpoint Data時的響應。DP的長度將是小於或等於Max Packet Size。

DPH(Deferred) – 如果設備接收到Deferred (DF)標志被設置的DPH，則應該轉換進入Idle狀態，退出DOMDSM。當設備在等待從主機來的下一個DP時鏈路轉換進入U1或U2，會收到這個包。沒有跟deferred DPH相關聯的DPP。

8.12.1.4.3.10 OUTMvData Host Terminate

進入這一狀態是因為主機已經發送了CStream的最后一個可用DP，即它已經耗盡了其CStream Endpoint Data。設備在該狀態

對來自主機的該Move Data transfer的上一個DP進行確認。

ACK(CStream, NumP=0) – 如果設備也耗盡了其Function Buffer空間，則它應該生成一個NumP = 0的ACK TP，並轉換進入Idle狀態，退出DOMDSM。

ACK(CStream, NumP>0) – 如果設備沒有耗盡其Function Buffer空間，則它應該生成一個NumP > 0的ACK TP，並轉換進入Idle狀態，退出DOMDSM。由於這一轉換，設備應該CStream將設為Not Ready。

ACK(CStream, NumP>0, Rty) – 如果設備在上一個DP中檢測到錯誤，則它應該生成一個NumP > 0且Rty = 1的ACK TP，從而主機會重試上一個DP。設備應該接着轉換進入OUTMvData Host狀態。

NRDY(CStream) – 設備可以通過發送一個將Stream ID設為CStream的NRDY，且轉換進入Idle狀態，退出DOMDSM，來對上一個CStream transfer進行流程控制（flow control）。設備可以在由於不可預知的內部情況時想要對CStream進行流程控制（flow control）時生成這一轉換。

8.12.1.4.4 主機輸入流協議【Host IN Stream Protocol】

本節定義在IN Bulk端點上，使得主機端流協議（Stream Protocol）從一個狀態轉換到另一個狀態的超高速包交換（SuperSpeed packet exchanges）。

在下文中，假設Host IN Stream狀態轉換發生在當主機發送與狀態機相關的消息的第一個符號的第一個比特給設備時，或者當主機首次解碼從主機來的狀態機相關的消息時。對與IN管道，主機端的Endpoint Buffers接收來自設備的Function Data。

【勘誤：上圖中 "Stall or Error" 應該重命名為"Stall or Clear Feature Halt"，去除timeout的情形。】

8.12.1.4.4.1 Disabled

在端口被配置后，管道狀態處於Disabled狀態，且LCStream被初始化為NoStream。

ACK(Prime, NumP>0, PP=0) – 當初始Endpoint Buffers被系統軟件指派給管道時，主機應該發送Stream ID設置為Prime的ACK TP給設備，並將管道轉換進入Prime Pipe狀態。

8.12.1.4.4.2 Prime Pipe

Prime Pipe狀態通知設備，已經有Endpoint Buffers被指派給一個或多個Streams。

NRDY(Prime) – 如果主機接收到一個Stream ID設為Prime的NRDY TP，則它應該轉換到Idle狀態。這一轉換是Prime Pipe操作的正常終結。

ACK(Deferred) – 如果接收到Deferred (DF)標志被設置的ACK TP，則主機應該將管道轉換進入Idle狀態。當管道在等待指派其初始Endpoint Buffer時，鏈路已經轉換進入U1或U2狀態，會接收到這個包。例如，在Disabled狀態在已經生成ACK(Prime, NumP>0, PP=0)之后，

ERDY() – 如果接收到ERDY，則發生了競爭條件。在此條件期間，設備處於Start Stream狀態，而主機處於Prime Pipe狀態。主機已經進入Prime Pipe狀態來通知設備已經有一個或多個Streams的Endpoint Buffers被更新了，同時設備已經試圖要發起一個Stream transfer，並且它們相應的消息也已經通過鏈路傳遞到對方。為了解決這一情況，主機應該保持在Prime Pipe狀態，並等待設備發NRDY(Prime)。

8.12.1.4.4.3 Idle

在Idle狀態，管道在等待一個Stream選擇（Stream selection）（例如，到Start Stream或Move Data的一個轉換），或者一個從主機來的通知，一個Stream Endpoint Buffer已經為該管道而被添加或修改（即，轉換到Prime Pipe）。注意到在初始進入Idle時（從Disabled），只有設備可以發起一個Stream選擇（Stream selection）。

ERDY(Stream n, NumP>0) – 如果接收到ERDY，主機應該轉換到Start Stream狀態。設備生成一個ERDY來選擇一個特定的Stream (Stream n)，期望主機在該Stream上開始IN事務。設備可以在它想要開始一次Stream transfer時發起這個轉換，無論它是否此前對管道進行了流程控制（flow controlled）。注意ERDY NumP字段反映了設備為Stream n可用的Endpoint Data的數量。ERDY NumP字段的值對主機只有參考意義（informative）,且設備用於Stream選擇（Stream selection）的方法超出了本規范的范圍，通常是由與管道相關的設備類所定義。當轉換進入Start Stream狀態，主機將LCStream設為Stream n。

ACK(Deferred) – 如果接收到Deferred (DF)標志被設置的ACK TP，主機應該保持在Idle狀態。當主機拒絕了從設備來的Start Stream請求時（即，由於一個ACK( NoStream, NumP=0, PP=0)）時，鏈路已經轉換進入U1或U2狀態，會接收到這個包。這一情況只在tERDYTimeout被超過時發生。

Stream x EP Buffer Change – 這一轉換發生在一個或多個主機端的Endpoint Buffers改變時。主機評估（在連接"&"處）軟件呈現給主機控制器的Stream的ID（Stream x），並轉換進入Prime Pipe狀態或Move Data狀態。這是一個優化，允許主機直接將Stream管道轉換進入Move Data狀態，而不是通過Prime Pipe, Start Stream, Move Data序列，並且被稱為Host Initiated Move Data，或者HIMD。用於做出這一決定的算法是特定於主機實現的。

ACK(Prime, NumP>0, PP=0) – 如果選擇了轉換進入Prime Pipe，則主機應該生成一個Stream ID = Prime, NumP > 0, 且 PP = 0的ACK TP，並轉換到Prime Pipe狀態。注意主機設置一個非零的NumP值，從而設備可以用NRDY做出響應。如果NumP = 0，設備可能會認為這是一個Terminating ACK，而不做出響應。典型地，當主機的Endpoint Buffers剛剛被修改過的Stream不是設備上次選擇的Stream時，即Stream x != LCStream時，會選擇Prime Pipe這一轉換。

ACK(Stream x, NumP>0) – 如果選擇了轉換進入Move Data，則主機應該生成一個Stream ID = Stream x, NumP > 0的ACK TP，並轉換到Move Data狀態。當進入Move Data狀態時，主機將CStream設為Stream x。典型地，當主機的Endpoint Buffers剛剛被修改過的Stream是設備上次選擇的Stream時，即Stream x = LCStream時，會選擇Move Data這一轉換。PP應該等於1，因為主機能夠從設備接收另一個DP。這一轉換可選地可以在某些主機中被禁止，且有些設備類可能不會處理這一轉換（例如，Mass Storage UASP）。

8.12.1.4.4.4 Start Stream

在Start Stream狀態，設備已經發送了一個ERDY給主機，建議其發起一個對Stream n的IN transfer,且設備正在等待主機接受或拒絕設備建議的Stream selection。

ACK(Stream n, NumP>0) – 如果主機已經接受了設備提出的開始Stream n的建議，則它應該發送一個Stream ID等於Stream n的ACK TP，並轉換進入Move Data狀態。當轉換到Move Data狀態的時候，主機將CStream設置成Stream n。如果有Endpoint Buffers可用來接收從來Stream的Function Data，則主機應該接受設備的Stream proposal。PP應該等於1，因為主機能夠從設備接收另一個DP。

ACK(NoStream, NumP=0, PP = 0) – 如果主機已經拒絕了設備提出的開始Stream n的建議，則它應該發送一個Stream ID等於NoStream的ACK TP，並轉換進入Idle狀態。如果沒有有Endpoint Buffers可用來接收從來Stream的Function Data，則主機應該拒絕設備的Stream proposal。

8.12.1.4.4.5 Move Data

在Host IN Move Data狀態，CStream在管道的兩端都設為相同值，且管道可以積極搬運數據。在Move Data狀態所執行的總線事務的詳情以及它的退出條件在Host IN Move Data State Machine中定義。

【勘誤：上圖中的INMvData Device Terminate到退出的轉換的動作標簽ACK(CStream, NumP=0, PP = 0)，應該改為ACK(CStream, NumP=0)。這是為了覆蓋到"主機還有更多緩沖空間可用，而設備已終結了這個突發"的情形。】

【勘誤：Rty可以跨多個突發。

去掉從INMvData Burst End到exit的ACK(Deferred)轉換。

添加從INMvData Device Terminate到INMvData Burst End的ACK(CStream, NumP=0, PP=1, Rty)轉換。

因此，上面的狀態機圖可以用下面的狀態機圖替換。為對比起見，先保留原圖，並將修改后的狀態機圖附於下面。

】

Host IN Move Data State Machine (HIMDSM)是從上面描述的Start Stream或Idle狀態進入的。一旦進入HIMDSM，立即就轉換進入INMvData Device狀態。HIMDSM允許設備由於耗盡與Stream相關的Function Data而終結Move Data操作，也允許主機因耗盡與Stream相關的Endpoint Buffer空間而終結Move Data操作。

HIMDSM總是退出到Idle狀態。Retry (Rty=1) 標志在導致HIMDSM退出的包中絕不該設置。Stream管道在包重試期間保持在Move Data狀態。

注意：在Move Data狀態期間所交換的所有包的Stream ID值都應該是CStream，除了INMvData Device子狀態的ERDY轉換。對於已識別的（identified）子狀態，如果在HIMDSM期間檢測到Stream ID值不是CStream，設備應該halt端點。

注意：如果在初始進入Move Data狀態時CStream不是Active的，則設備可以使用設備類定義的NRDY或STALL拒絕該Stream建議。

8.12.1.4.4.6 INMvData Device

這一狀態初始是從Start Stream狀態或Idle狀態進入的。在該狀態主機等待從設備來的DP，或者設備拒絕HIMD。

DP(CStream, EOB=0) – 如果主機接收到一個EOB = 0的DP，它應該將DP的數據拷貝到與Stream相關聯的Endpoint Buffer中，並轉換進入INMvData Host狀態。DPP應該包含CStream的數據負載。這一轉換發生在設備返回IN數據，且還有更多Function Data要發送時。當轉換進入INMvData Host狀態時，主機將LCStream設為CStream的值。如果設備接受HIMD，這一動作使用CStream更新LCStream，也即LCStream記錄設備感興趣的上一個Stream。

DP(CStream, EOB=1) – 如果主機接收到一個EOB = 1的DP，它應該將DP的數據拷貝到與Stream相關聯的Endpoint Buffer中，並轉換進入INMvData Device Terminate狀態。DPP應該包含CStream的數據負載。這一轉換發生在設備返回IN數據，且沒有更多Function Data要發送時。當轉換進入INMvData Device Terminate狀態時，主機將LCStream設為CStream的值。如果設備接受HIMD，這一動作使用CStream更新LCStream，也即LCStream記錄設備感興趣的上一個Stream。

NRDY(CStream) – 如果主機接收到一個NRDY，它應該退出HIMDSM，並轉換進入Idle狀態。主機可以在初始進入到HIMDSM時因為設備拒絕了HIMD，也可以在Stream transfer期間由於不可預期的設備內部情況而想要流程控制（flow control）CStream時, 可以生成該轉換。

ACK(Deferred) – 如果主機接收到一個Deferred (DF)被設置的ACK TP，則它應該退出HIMDSM，並轉換進入Idle狀態。當在主機和設備之間的一段鏈路轉換進入U1或U2狀態時，會接收到這個包。有2中情況可能發生這一轉換：1）主機已經嘗試了一個HIMD，以及2）在突發之間（between bursts）。如果在為Stream獲取緩沖時有一個較長的主機時延（long host delay）, 則情況1很可能（likely）發生。如果在其他設備上有許多端點活動而延遲了突發之間的時間（delaying the time between bursts）, 則情況2可能（may）發生。設備將這個轉換像Prime Pipe一樣對待，將會在當它接收到從集線器轉發給它的Deferred ACK時，發送一個ERDY來重啟（restart）這個Stream。【已勘誤，去掉了一種情況。】

ERDY() – 如果接收到了一個ERDY，則發生了競爭條件。在此情況期間，設備處於Start Stream狀態，而主機處於Move Data狀態。主機由於一個HIMD而進入了Move Data狀態，同時設備已經試圖發起一個Stream transfer，且它們相關的消息也已經通過鏈路傳送到對方。為了解決這一情況，主機應該保持在INMvData Device狀態，等待從設備發來一個DP或者NRDY。

8.12.1.4.4.7 INMvData Host

在該狀態，主機已經接收到一個從設備來的DP，且設備還有更多給CStream的Function Data。主機在將接收到的數據拷貝與該Stream相關聯的Endpoint Buffer空間后，響應一個對上一DP的確認。

ACK(CStream, NumP>0, PP=1) – 如果有更多的給該Stream的Endpoint Buffer空間可用，且主機在繼續到設備的當前突發（current burst），則主機應該生成一個NumP > 0且PP = 1的ACK TP，並轉換進入INMvData Device狀態。如果主機檢測到設備來的上一個DP中有錯誤，則Rty標志應該被設置。主機可以(may)繼續INMvData Host到INMvData Device的循環，直到所有的重試都耗盡，或者從設備收到一個好包。

ACK(CStream, NumP=0, PP=1) – 如果有更多的給該Stream的Endpoint Buffer空間可用，但是主機必須終止到設備的當前突發（current burst），則主機應該生成一個NumP = 0 且 PP = 1的ACK TP，並轉換進入INMvData Burst End狀態。如果主機檢測到從設備來的上一個DP有錯誤，則Rty標志應該被設置。

ACK(CStream, NumP=0, PP=0) – 如果主機在接收到的上一個DP中沒有檢測到錯誤，且已經耗盡了Stream的Endpoint Buffer空間，則這主機應該生成一個NumP = 0 且 PP = 0的ACK TP，並轉換進入Idle狀態，退出HIMDSM。該轉換通知設備主機已經耗盡了Stream的Endpoint Buffer空間。這一轉換通知設備，主機已經耗盡該Stream的Endpoint Buffer空間。

8.12.1.4.4.8 INMvData Burst End

進入該狀態是因為主機已經終結了該Stream管道上的一個突發。當主機准備好開始另一個突發時它就會退出該狀態。如果這個狀態是還在重試時【retrying (Rty =1)】進入的，那么當退出該狀態時主機應該在端點類型的限制內繼續重試過程。

ACK(CStream, NumP>0, PP=1) – 當主機准備好對設備開始在CStream上的另一個突發時，主機應該生成一個NumP > 0 且 PP = 1的ACK TP，並轉換進入INMvData Device狀態。注意，如果在進入該狀態時Rty標志是被設置的，則在退出時也應該被設置。

8.12.1.4.4.9 INMvData Device Terminate

在該狀態，主機已經接收到從設備來的對該Move Data操作的最后一個DP，因為設備已經耗盡了它對CStream的可用Function Data。主機在將接收到的數據拷貝到與該Stream相關聯的Endpoint Buffer空間后，響應一個確認，並退出HIMDSM。如果從設備接收到的DP是壞的，則在端點類型的限制內，重試可以被執行。

ACK(CStream, NumP=0, No Rty) – 如果從設備接收到的DP是好包，則主機生成一個NumP = 0且Rty = 0的ACK TP，並轉換進入Idle狀態，退出HIMDSM。【已勘誤，去掉了PP=0這個參數值】【譯注：這里，覆蓋了"主機還有更多緩沖空間可用，而設備已終結了這個突發"的情形。】

ACK(CStream, NumP>0, PP=1, Rty) – 如果從設備接收到DP是壞包，且當前突發(current burst)尚未完成，則主機應該生成一個NumP > 0, PP = 1 且 Rty = 1的ACK TP，並轉換進入INMvData Device狀態。主機可以(may)繼續INMvData Device Terminate到INMvData Device的循環，直到所有的重試都耗盡，或者收到一個好包。

ACK(CStream, NumP=0, PP=1, Rty) – 如果從設備接收到DP是壞包，且當前突發(current burst)已經完成，則主機應該生成一個NumP = 0, PP = 1 且 Rty = 1的ACK TP，並轉換進入INMvData Burst End狀態。主機應該在下一個突發中繼續重試過程。

8.12.1.4.5 主機輸出流協議【Host OUT Stream Protocol】

本節定義在OUT Bulk端點上，使得主機端流協議（Stream Protocol）從一個狀態轉換到另一個狀態的超高速包交換（SuperSpeed packet exchanges）。

在下文中，假設Host OUT Stream狀態轉換發生在當主機發送與狀態機相關的消息的第一個符號的第一個比特給設備時，或者當主機首次解碼從設備來的狀態機相關的消息時。對與OUT管道，設備端的Function Buffers接收來自主機端的Endpoint Data。

【勘誤：上圖中 "Stall or Error" 應該重命名為"Stall or Clear Feature Halt"，去除timeout的情形。】

8.12.1.4.5.1 Disabled

在端口被配置后，管道狀態處於Disabled狀態，且LCStream被初始化為NoStream。

DP(Prime, PP=0) – 當初始Endpoint Data被系統軟件指派給管道時，主機應該發送Stream ID設置為Prime的零長DP（zero-length DP）給設備，並將管道轉換進入Prime Pipe狀態。DPP應該包含零長數據負載（zero-length data payload）。

8.12.1.4.5.2 Prime Pipe

Prime Pipe狀態通知設備，已經有Endpoint Buffers被指派給一個或多個Streams。注意，這一狀態是當主機從Disabled狀態或者Idle狀態傳送一個DP(Prime)時進入的。如果設備在該DP數據中檢測到錯誤，則設備應該發送ACK(Prime, NumP>0, Rty)包，重試，直到成功接收到DP(Prime)。主機可以(may)重傳DP(Prime)，並保持在Prime Pipe狀態，直到設備成功接收到DP(Prime)並返回一個NRDY(Prime)，或者直到管道的重試被耗盡從而主機停止（halts）該管道。【已勘誤，原文檔說主機"應該(shall)"繼續當前事務，現在更正為"可以(may)"。這簡化了主機的行為，並且去除了因為要等待其他端點請求多次重試而使得周期性傳輸遭受飢餓(starved)的情形。此外，核心規范並沒有重試次數的限制（一般來說是3次）。】這一情況沒在上圖中顯示。

NRDY(Prime) – 如果主機接收到一個Stream ID 設為Prime的NRDY TP，它應該轉換到Idle狀態。這一轉換是Prime Pipe操作的正常終結。

DPH(Deferred) – 如果接收到Deferred (DF)標志被置位的DPH，則主機應該轉換到Idle狀態。當管道在等待其被指派其初始Endpoint Buffer時，如果鏈路轉換進入了U1或U2狀態，會收到該包。例如，在Disabled狀態時，生成DP(Prime, PP=0)之后。沒有DPP與deferred DPH相關聯。

ERDY() – 如果接收到ERDY，則發生了競爭情況。在此情形下，設備處於Start Stream狀態，而主機處於Prime Pipe狀態。主機進入狀態，通知設備一個或多個Streams的Endpoint Buffers已經被更新，同時設備也嘗試發起一個Stream transfer，且他們相關的消息也已經通過鏈路傳遞給對方。為了解決這一情況，主機應該保持在Prime Pipe狀態，並等待從設備發來一個NRDY。

8.12.1.4.5.3 Idle

在Idle狀態，管道在等待一個Stream選擇（Stream selection）（例如，到Start Stream或Move Data的一個轉換），或者一個從主機來的通知，Stream Endpoint Data已經為該管道而被添加或修改（即，轉換到Prime Pipe）。注意到在初始進入Idle時（從Disabled），只有設備可以發起一個Stream選擇（Stream selection）。

ERDY(Stream n, NumP>0) – 如果接收到ERDY，主機應該轉換到Start Stream狀態。設備生成一個ERDY來選擇一個特定的Stream (Stream n)，期望主機在該Stream上開始OUT事務。設備可以在它想要開始一次Stream transfer時發起這個轉換，無論它是否此前對管道進行了流程控制（flow controlled）。注意ERDY NumP字段反映了設備為Stream n可用的Endpoint Buffer空間的數量設備用於Stream選擇（Stream selection）的方法超出了本規范的范圍，通常是由與管道相關的設備類所定義。當轉換進入Start Stream狀態，主機將LCStream設為Stream n。

Stream x EP Buffer Change – 這一轉換發生在主機端的一個或多個Streams的Endpoint Data被提交時（posted）。主機評估（在連接"&"處）軟件呈現給主機控制器的Stream的ID（Stream x），並轉換進入Prime Pipe狀態或Move Data狀態。這是一個優化，允許主機直接將Stream管道轉換進入Move Data狀態，而不是通過Prime Pipe, Start Stream, Move Data序列，並且被稱為Host Initiated Move Data，或者HIMD。用於做出這一決定的算法是特定於主機實現的。

DP(Prime, PP=0) – 如果選擇了轉換進入Prime Pipe，則主機應該生成一個Stream ID = Prime,且 PP = 0的DP，並轉換到Prime Pipe狀態。DPP應該包含零長數據負載（zero-length data payload）。典型地，當主機的Endpoint Data剛剛被修改過的Stream不是設備上次選擇的Stream時，即Stream x != LCStream時，會選擇Prime Pipe這一轉換。

DP(Stream x) – 如果選擇了轉換進入Move Data，則主機應該生成一個Stream ID = Stream x的DP，並轉換到Move Data狀態。當進入Move Data狀態時，主機將CStream設為Stream x。DPP應該包含CStream的第一個數據負載。典型地，當主機的Endpoint Data剛剛被修改過的Stream是設備上次選擇的Stream時，即Stream x = LCStream時，會選擇Move Data這一轉換。如果主機具有超過Max Packet Size的Endpoint Data對該Stream可用，則PP = 1，否則PP = 0。該轉換可以可選地被某些主機禁用，且某些設備類可能不會出來該轉換（例如，Mass Storage UASP）。

8.12.1.4.5.4 Start Stream

在Start Stream狀態，設備已經發送了一個ERDY，建議主機發起一個對Stream n的OUT transfer，且設備正在等待主機接受或拒絕該Stream選擇（Stream selection）。

DP(Stream n) – 如果主機已經接受了設備提出的開始Stream n的建議，則它應該發送一個Stream ID等於Stream n的DP，並轉換進入Move Data狀態。當轉換到Move Data狀態的時候，主機應該將CStream設置成Stream n。DPP應該包含CStream的第一個數據負載。主機應該在對Stream有Endpoint Data可用時接受設備的Stream建議（Stream proposal）。

DP(NoStream, PP=0) – 如果主機已經拒絕了設備提出的開始Stream n的建議，則它應該發送一個Stream ID等於NoStream的DP，並轉換進入Start Stream End狀態。DPP應該包含一個零長（zero-length）數據負載。如果沒有給Stream的Endpoint Data，則主機應該拒絕從設備來的建議。

8.12.1.4.5.5 Start Stream End

在Start Stream End狀態，主機已經拒絕了設備提出的Stream ID的建議，因為對Stream n沒有Endpoint Data可用。注意，這一狀態是當主機從Start Stream狀態發送一個DP(NoStream)時進入的。如果設備在該DP數據中檢測到錯誤，則設備應該發送ACK(NoStream, NumP>0, Rty)包，重試，直到成功接收到DP(NoStream)。主機可以(may)重傳DP(NoStream)，並應該保持在Start Stream End狀態，直到設備成功接收到DP(NoStream)並返回NRDY(NoStream)，或者直到管道的重試被耗盡從而主機停止（halts）該管道。【已勘誤，原文檔說主機"應該(shall)"繼續當前事務，現在更正為"可以(may)"。這簡化了主機的行為，並且去除了因為要等待其他端點請求多次重試而使得周期性傳輸遭受飢餓(starved)的情形。此外，核心規范並沒有重試次數的限制（一般來說是3次）。】這一情況沒在上圖中顯示。

NRDY(NoStream) – 如果接收到一個Stream ID等於NoStream的NRDY，則主機應該轉換到Idle狀態。

DPH(Deferred) – 如果接收到Deferred (DF)標志被置位的DPH，則主機應該轉換到Idle狀態。當等待主機對Start Stream的響應時，如果鏈路轉換進入了U1或U2狀態，會收到該包。注意，這一轉換只有在tERDYTimeout被超過時可能發生。沒有DPP與deferred DPH相關聯。

8.12.1.4.5.6 Move Data

在Host OUT Move Data狀態，CStream在管道的兩端都設為相同值，且管道可以積極搬運數據。在Move Data狀態所執行的總線事務的詳情以及它的退出條件在Host OUT Move Data State Machine中定義。

【勘誤：上圖中，應該在從OUTMvData Host Terminate狀態出來的下列弧線(arc)的標簽上添加LCStream = CStream：標有ACK(CStream,NumP=0)弧線，標有ACK(CStream,NumP>0,No Rty)的弧線，標有ACK(CStream,NumP>0,Rty)的弧線。這是為了在由於一個Host Initiated Move Data通過PP=0的DP而發生時，使得LCStream仍然能夠得到更新。】

Host OUT Move Data State Machine (DOMDSM)是從上面描述的Start Stream或Idle狀態進入的。進入HOMDSM將立即轉換進入OUTMvData Device狀態。HOMDSM允許設備由於耗盡與Stream相關的Endpoint Data而終結Move Data操作，也允許主機因耗盡與Stream相關的Function Buffer而終結Move Data操作。

PP=0 – 在進入HOMDSM時，如果主機只有Stream的一個包的Endpoint Data可用，則PP應該在設備接收到的第一個DP中等於0，且它將轉換進入OUTMvData Device Terminate狀態。

PP = 1 – 在進入HOMDSM時，如果主機有Stream的多於一個包的Endpoint Data可用，則PP應該在設備接收到的第一個DP中等於1，且它將轉換進入OUTMvData Device狀態。

HOMDSM總是退出到Idle狀態。Retry (Rty=1) 標志在導致HOMDSM退出的包中絕不該設置。Stream管道在包重試期間保持在Move Data狀態。

注意：在Move Data狀態期間所交換，除了OUTMvData Device狀態下的ERDY轉換，所有包的Stream ID值都應該是CStream。如果在HOMDSM期間檢測到Stream ID值不是CStream，設備應該halt端點。

8.12.1.4.5.7 OUTMvData Device

這一狀態初始是從Start Stream狀態或Idle狀態進入的。在該狀態主機等待設備發送一個ACK TP，或者從設備來的對HIMD的拒絕。

ACK(CStream, NumP>0) – 如果主機接收到一個NumP > 0的ACK TP，則它應該轉換進入OUTMvData Host狀態。這一轉換在當設備對該Stream有更多可用的Function Buffer空間時發生。如果設備在從主機來的最后一個DP中檢測到錯誤，則Retry (Rty)標志應該被設置。如果需要重試，則主機可以(may)繼續當前突發（current burst）直到所有的重試都耗盡，或者傳送了一個好包。如果在主機不能繼續當前突發（current burst）的情況下，主機將會在該端點類型限制內的下一個可用機會時回到該端點。【已勘誤，原文檔說主機"應該(shall)"繼續當前突發，現在更正為"可以(may)"。這簡化了主機的行為，並且去除了因為要等待其他端點請求多次重試而使得周期性傳輸遭受飢餓(starved)的情形。此外，核心規范並沒有重試次數的限制（一般來說是3次）。】主機應該設置LCStream = CStream。如果設備接受一個HIMD，則這一動作用Stream x的值來更新LCStream，即，LCStream記錄了設備上一次感興趣的Stream。

ACK(CStream, NumP=0) – 如果主機接收到一個NumP = 0的ACK TP，則它應該轉換進入Idle狀態，退出HOMDSM。這一轉換在當設備對該Stream沒有更多可用的Function Buffer空間時發生，即，它葯終結該Move Data操作，因為上一個DP耗盡了其Function Buffer空間。主機應該設置LCStream = CStream。如果設備接受一個HIMD，則這一動作用Stream x的值來更新LCStream，即，LCStream記錄了設備上一次感興趣的Stream。

NRDY(CStream) – 如果主機接收到NRDY，則它應該轉換到Idle狀態，退出HOMDSM。這一轉換可能在當最初進入HOMDSM時就由於設備拒絕該HIMD而發生，或者在一個Stream transfer期間由於不期望的設備內部情況而導致設備想要流程控制（flow control）該CStream時而發生。

DPH(Deferred) – 如果主機接收到Deferred (DF) 標志被設置的DPH，則它應該轉換到Idle狀態，退出HOMDSM。當鏈路已經轉換進入U1或者U2狀態且主機已經嘗試了一個HIMD，或者在OUT管道的突發之間（between bursts），如果在其他設備（other devices）上有許多端點活動且到這個設備（other devices）的路徑上的Ux Timeouts被設置為較短的值時，可能會接收到這個包。當發生該轉換時，主機將在Idle狀態等待從設備發來一個ERDY來重啟該Stream。沒有DPP與deferred DPH相關聯。

ERDY() – 如果接收到ERDY，則發生了競爭情況。在此情形下，設備處於Start Stream狀態，而主機處於Move Data狀態。主機由於HIMD的結果而進入Move Data狀態，同時設備也嘗試發起一個Stream transfer，且他們相關的消息也已經通過鏈路傳遞給對方。為了解決這一情況，主機應該保持在OUTMvData Device狀態，並等待從設備發來一個ACK或者NRDY。

8.12.1.4.5.8 OUTMvData Host

在該狀態，主機已經從設備處接收到一個ACK TP，且設備還有更多給CStream的Function Buffer空間可用。主機在該狀態生成一個DP，包含與該Stream相關聯的Endpoint Data。管道也將在該狀態的主機來的突發（bursts）之間等待（wait in this state between bursts from the host）。注意，DP重試過程可能跨越多個突發（DP retry process may span bursts）。

DP(CStream, PP=1) – 如果具有為該Stream的更多Endpoint Data可用，且主機正在繼續到設備的當前突發（current burst），則主機應該生成一個PP = 1的DP，並轉換到OUTMvData Device狀態。DPP應該包含一個CStream的數據負載。如果在從設備來的上一個ACK中的Rty標志被設置了，則主機應該重發恰當的DP，直到所有的重試都被耗盡，或者一個好DP為設備所確認（接收到好包）。

DP(CStream, PP=0) – 如果發送這個DP耗盡了該Stream的可用Endpoint Data，則主機應該生成一個PP = 0的DP，並轉換到OUTMvData Host Terminate狀態。DPP應該包含一個CStream的數據負載。這個轉換通知設備主機已經耗盡了該Stream的可用Endpoint Data。

8.12.1.4.5.9 OUTMvData Host Terminate

在該狀態，主機已經耗盡了其CStream的可用Endpoint Data，且發送了該Stream的最后一個DP。主機在等待對這個Stream的最后一個DP進行確認。

ACK(CStream, NumP=0) – 如果主機接收到一個NumP = 0 且 Rty = 0的ACK TP，則主機應該轉換進入Idle狀態，退出HOMDSM。這一轉換發生在設備成功接收到上一個DP，且主機和設備同時都耗盡了他們的相應Endpoint Data和Function Buffer空間。

ACK(CStream, NumP>0, No Rty) – 如果主機接收到一個NumP > 0, PP = 0, 且 Rty = 0的ACK TP，則主機應該轉換進入Idle狀態，退出HOMDSM。這一轉換發生在設備已經成功接收到上一個DP，且主機耗盡了其對CStream的Endpoint Data，但是設備仍然還有更多的Function Buffer空間可用時。

ACK(CStream, NumP>0, Rty) –如果主機接收到一個NumP > 0 且 Rty = 1的ACK TP，則主機應該轉換進入OUTMvData Host狀態並重新發送恰當的DP。這一轉換發生在設備接收到的上一個包是壞包，從而需要Retry時。主機應該繼續OUTMvData Host Terminate到OUTMvData Host的循環，直到所有的重試都被耗盡，或者一個好DP為設備所確認（接收到好包）。

NRDY(CStream) – 如果主機接收到一個NRDY，則主機應該轉換進入Idle狀態，退出HOMDSM。這一轉換可能發生在一個Stream transfer期間，由於不期望的設備內部情況而導致設備想要流程控制（flow control）該CStream時而發生。

DPH(Deferred) – 如果主機接收到Deferred (DF) 標志被設置的DPH，則它應該轉換到Idle狀態，退出HOMDSM。如果在最后一個DP被主機發送之前，鏈路已經轉換進入U1或者U2狀態，會接收到這個包。沒有DPP與deferred DPH相關聯。

8.12.1.4.6 批量輸入流協議【Bulk IN Stream Protocol】

【譯注：本節為勘誤之前原始文檔第8.12.1.4.2節譯文。勘誤改動較大，但僅僅是為了闡述得更清晰，實際協議流程與原文一致，且原文被xHCI規范引用，故譯文在勘誤之后保留了原文的譯文且新立章節，供參考。】

本節定義在輸入方向批量端點上，使得流協議從一個狀態轉換到另一個狀態的SuperSpeed包交換。

對於輸入管道，主機端的端點緩沖區（Endpoint Buffers）接收從設備發來的功能數據（Function Data）。

在端點被配置之后，管道進入Disabled狀態。主機應該通過發送Stream ID字段設置為Prime的ACK TP來將管道轉換到Prime Pipe狀態。這一轉換在端點緩沖區被系統軟件指派給管道之后發生。

設備應該通過發送Stream ID 字段設置為Prime的NRDY TP來促使管道從Prime Pipe狀態退出，並轉換到Idle狀態。

注意：如果中間的集線器推后了ACK TP，主機和設備應該就像設備已經發送了一個NRDY TP那樣來工作。也就是說，主機應該在接收到推后的響應（Deferred Response）時轉換到Idle狀態。設備應該在接收到推后的ACK TP（Deferred ACK TP）時轉換到Prime Pipe狀態，並接着馬上轉換到Idle狀態，就像它已經發送了Stream ID字段設置為Prime的NRDY TP。

在Idle狀態,管道在等待流選擇（Stream selection）（例如，轉換到Start Stream 或者 Move Data），或者從主機獲得通知，告知已經對該管道添加了或者修改了一個端點緩沖區（轉換到Prime Pipe）。在Idle狀態,由主機發起的流選擇（Stream selection）被Stream ID設置為Stream n並且NumP值> 0的ACK TP所標識。這個包應該將ISPSM從Idle狀態轉換到Move Data狀態。如果上一個轉換是從Start Stream 或者 Move Data過來，那么主機應該發起從Idle到Move Data的轉換，基於兩個可能的情形：1）如果指定給管道的端點緩沖區（Endpoint Buffer）此前服務於LCStream，並且上一次ISPSM轉換並不是因為NRDY(Stream n) 從Move Data退出；或者 2）如果端點緩沖區被指定給一個新的流（也就是，新制定的SID不等於LCStream）。在Idle狀態, 由設備發起的流選擇（Stream selection）被Stream ID設置為Stream n並且NumP值> 0的ERDY TP所標識。這個包應該將ISPSM從Idle狀態轉換到Start Stream狀態。不論設備是否處於流程控制條件下，當它希望開始一次流傳輸時，設備就應該發起這一轉換。

在Start Stream狀態，管道在等待主機接受或者拒絕由設備提議的流選擇（Stream selection）。主機應該通過發送具有如下設置的ACK TP，來指示對設備發起的流選擇（Stream selection）的認可：Stream ID = Stream n 並且 NumP > 0。這個包應該將ISPSM從Start Stream狀態轉換到Move Data狀態。主機應該通過發送具有如下設置的ACK TP，來指示對設備發起的流選擇（Stream selection）的拒絕：Stream ID = NoStream, NumP = 0, 並且Packet Pending (PP) = 0。這個包應該將ISPSM從Start Stream狀態轉換到Idle狀態。如果沒有端點緩沖區可用時，主機應該拒絕設備選擇的SID。

ISPSM在主機和設備上獨立地執行。在主機發送一個ACK(Prime,PP=0)到設備，並進入Prime Pipe狀態的同時，如果設備發送了一個ERDY給主機，並進入Start Stream狀態的話，就產生了條件競爭（race condition）。為了從這個條件下恢復，如果設備在Start Stream狀態接收到一個ACK(Prime,PP=0)，它應該轉換到Prime Pipe Ack狀態，並且發送一個NRDY(Prime)給主機，來完成主機從Prime Pipe到Idle的轉換，以及設備從Prime Pipe Ack到Idle的轉換。

在Move Data狀態，CStream在主機和設備兩端都被設置，並且管道正在積極地搬運數據到主機。在Move Data狀態中執行的總線事務的詳情以及其退出條件，在下面定義的IN Move Data State Machine中被定義。

如上所述，輸入搬移數據狀態機【IN Move Data State Machine (IMDSM)】從Start Stream 或者 Idle 狀態進入。進入IMDSM后立刻轉換到INMvData Device狀態。IMDSM 生成的所有包的Stream ID字段都應該是Stream n。每當進入INMvData Device狀態，設備執行如下動作來使IMDSM推進：

if (設備功能數據字節數 > 最大包大小)

設備應該生成EOB字段= 0的數據包DP，這樣就促使管道轉移到INMvData Host狀態。

else if (設備功能數據字節數 = 最大包大小)

設備應該生成EOB字段= 1的數據包DP，這樣就促使管道轉移到INMvData Device Terminate狀態。

else (設備功能數據字節數 < 最大包大小)

設備應該生成一個短包數據包DP，這樣就促使管道轉移到INMvData Device Terminate狀態。

可選地，設備可能生成一個Stream ID設置為Stream n的NRDY TP，這樣就終結該流，並將管道退出IMDSM而轉移到Idle狀態。設備可能使用該轉換來拒絕主機發起的數據搬移請求（Host Initiated Move Data）。

注意：如果中間的集線器推后了ACK TP，主機和設備應該就像設備已經發送了一個NRDY TP那樣來工作。也就是說，主機應該在接收到推后的響應（Deferred Response）時轉換到Idle狀態。設備應該在接收到推后的ACK TP（Deferred ACK TP）時退出IMDSM並轉換到Idle狀態，就像它已經發送了Stream ID字段設置為Stream n的NRDY TP。如果設備接受主機發起的Stream ID，它應該發送一個Stream ID字段設置為Stream n的ERDY。如果設備拒絕主機發起的Stream ID，它應該呆在Idle狀態並等待下一個要么從主機要么從設備來的流選擇（Stream selection）。

INMvData Host狀態由於設備有更多數據要發送而進入，因此主機執行如下動作來使IMDSM推進：

if (在本次突發中可以再調度令一個數據包DP)

if (主機有更多的端點緩沖區空間可用)

生成NumP > 0的ACK TP，這樣就促使管道轉換到INMvData Device狀態。

else (主機已經用完端點緩沖區空間)

生成NumP = 0 且 PP = 0的完結ACK TP，這樣就促使管道退出IMDSM並轉換到Idle狀態。

else (收到本次突發的最后一個數據包DP)

終結本次突發。

if (主機有更多的端點緩沖區空間可用)

通知設備本次突發完成(NumP = 0)，且CStream的下一次突發應該由主機調度(PP = 1)。生成NumP = 0 且 PP = 1的ACK TP，並促使管道轉換到INMvData Burst End狀態。

else (主機已經用完端點緩沖區空間)

生成NumP = 0 且 PP = 0的完結ACK TP，這樣就促使管道退出IMDSM並轉換到Idle狀態。

在INMvData Burst End狀態，主機應該生成NumP = 0 且 PP = 1的ACK TP，來發起下一次突發（burst），並並促使管道轉換到INMvData Device狀態。

上述描述IMDSM的偽代碼假設接收到的數據包DP是有效的。如果其無效，應該生成ACK TP，將管道轉換到INMvData Device狀態。ACK TP中的序列號（Sequence Number）不應該改變（推進），但是，retry可能遞減被傳輸的NumP值。如果NumP = 0且主機還有端點緩沖區可用，PP應該被設為1；否則，PP被設為0。

INMvData Device Terminate狀態由於設備沒有更多的功能數據發送，因此主機應該生成NumP = 0 且 PP = 0的終結ACK TP，從而促使管道退出IMDSM並轉換到Idle狀態。如果主機檢測到設備發送的上一個數據包DP的錯誤，它應該用Retry ACK TP (Steam n, NumP>0, Rty)來響應，並且IMDSM應該轉換到INMvData Device狀態。

注意：如果一個數據包DP錯誤在INMvData Host狀態被檢測到，主機應該生成一個NumP > 0 且 Rty = 1的ACK TP，從而促使管道轉換到INMvData Device狀態並重新發送該包。

8.12.1.4.7 批量輸出流協議【Bulk OUT Stream Protocol】

【譯注：本節為勘誤之前原始文檔第8.12.1.4.3節譯文。勘誤改動較大，但僅僅是為了闡述得更清晰，實際協議流程與原文一致，且原文被xHCI規范引用，故譯文在勘誤之后保留了原文的譯文且新立章節，供參考。】

本節定義在輸出方向批量端點上，使得流協議從一個狀態轉換到另一個狀態的SuperSpeed包交換。

對於輸出管道，主機端的端點數據（Endpoint Data）被傳輸到設備發的功能數據緩沖（Function Buffers）。除非另有指出，數據包DP將包括端點數據（Endpoint Data）。

設備應該通過發送Stream ID 字段設置為Prime的NRDY TP來促使管道從Prime Pipe狀態退出，並轉換到Idle狀態。

設備應該通過發送Stream ID字段設置為Prime的NRDY TP來促使管道從Prime Pipe狀態退出，並轉換到Idle狀態。

注意：如果中間的集線器推后了數據包DP，主機和設備應該就像設備發送了一個NRDY TP那樣來工作。也就是說，主機應該在接收到推后的響應（Deferred Response）時轉換到Idle狀態。設備應該在接收到推后的數據包頭（Deferred DPH）時轉換到Prime Pipe狀態，並接着馬上轉換到Idle狀態，就像它已經發送了Stream ID字段設置為Prime的NRDY TP。

在Idle狀態,管道在等待流選擇（Stream selection）（例如，轉換到Start Stream 或者 Move Data），或者從主機獲得通知，告知已經對該管道添加了或者修改了端點數據（Endpoint Data）（轉換到Prime Pipe）。在Idle狀態,由主機發起的流選擇（Stream selection）被Stream ID設置為Stream n的數據包DP所標識。PP的值取決於主機是否有一個（PP = 0）或者多個（PP = 1）數據包要發送。這個包應該將OSPSM從Idle狀態轉換到Move Data狀態。如果上一個轉換是從Start Stream 或者 Move Data過來，那么主機應該發起從Idle到Move Data的轉換，基於兩個可能的情形：1）如果指定給管道的端點緩沖區（Endpoint Buffer）此前服務於LCStream，並且上一次OSPSM轉換並不是因為NRDY(Stream n) 從Move Data退出；或者 2）如果端點緩沖區被指定給一個新的流。在Idle狀態, 由設備發起的流選擇（Stream selection）被Stream ID設置為Stream n並且NumP值> 0的ERDY TP所標識。這個包應該將OSPSM從Idle狀態轉換到Start Stream狀態。不論設備是否處於流程控制條件下，當它希望開始一次流傳輸時，設備就應該發起這一轉換。

在Start Stream狀態，管道在等待主機接受或者拒絕由設備提議的流選擇（Stream selection）。主機應該通過發送具有如下設置的數據包DP，來指示對設備發起的流選擇（Stream selection）的認可：Stream ID = Stream n。PP的值取決於主機是否有一個（PP = 0）或者多個（PP = 1）數據包要發送。這個包應該將OSPSM從Start Stream狀態轉換到Move Data狀態。主機應該通過發送具有如下設置的數據包DP，來指示對設備發起的流選擇（Stream selection）的拒絕：Length = 0, Stream ID = NoStream 且 PP = 0。這個包應該將OSPSM從Start Stream狀態轉換到Start Stream End狀態。如果沒有端點數據緩沖區可用時，主機應該拒絕設備選擇的SID。

OSPSM在主機和設備上獨立地執行。在主機發送一個DP(Prime,PP=0)到設備，並進入Prime Pipe狀態的同時，如果設備發送了一個ERDY給主機，並進入Start Stream狀態的話，就產生了條件競爭（race condition）。為了從這個條件下恢復，如果設備在Start Stream狀態接收到一個DP(Prime,PP=0)，它應該轉換到Prime Pipe Ack狀態，並且發送一個NRDY(Prime)給主機，來完成主機從Prime Pipe到Idle的轉換，以及設備從Prime Pipe Ack到Idle的轉換。

Start Stream End狀態是一個當（流）選擇被拒絕時，從Start Stream狀態退出的中間狀態。設備應該總是通過發送Stream ID = NoStream的NRDY TP，強制轉換到Idle狀態。這一轉換履行了設備必須響應主機發來的數據包的要求。

在Move Data狀態，CStream在主機和設備兩端都被設置，並且管道正在積極地搬運數據到設備。在Move Data狀態中執行的總線事務的詳情以及其退出條件，在下面定義的OUT Move Data State Machine中被定義。

如上所述，輸出搬移數據狀態機【OUT Move Data State Machine (OMDSM)】從Start Stream 或者 Idle 狀態進入。進入IMDSM后立刻轉換到INMvData Device狀態。OMDSM生成的所有包的Stream ID字段都應該是Stream n。

一旦進入OMDSM，就對接收到的數據包DP的PP字段求值。PP = 1將OMDSM轉換到OUTMvData Device狀態。PP = 0將OMDSM轉換到OUTMvData Host Terminate狀態。

每當進入OUTMvData Device狀態，設備執行如下動作來使OMDSM推進：

if (設備功能緩沖區空間 >= 主機端點數據大小【注1】)

設備應該生成NumP字段> 0的數據包ACK TP，這樣就促使管道轉移到OUTMvData Host狀態。

else if (設備功能緩沖區空間 = 主機端點數據大小)

設備應該生成NumP字段= 1的數據包終結ACK TP，這樣就促使管道退出OMDSM,並轉移到Idle狀態。

【注1：主機端點數據大小通過設備類定義機制與設備溝通】

可選地，設備可能生成一個Stream ID設置為Stream n的NRDY TP，這樣就終結該流，並將管道退出OMDSM而轉移到Idle狀態。設備可能使用該轉換來拒絕主機發起的數據搬移請求（Host Initiated Move Data）。

注意：如果中間的集線器推后了數據包DP，主機和設備應該就像設備發送了一個NRDY TP那樣來工作。也就是說，主機應該在接收到推后的響應（Deferred Response）時轉換到Idle狀態。設備應該在接收到推后的數據包DP（Deferred DP）時退出OMDSM並轉換到Idle狀態，就像它已經發送了Stream ID字段設置為Stream n的NRDY TP。如果設備接受主機發起的Stream ID，它應該發送一個Stream ID字段設置為Stream n的ERDY。如果設備拒絕主機發起的Stream ID，它應該呆在Idle狀態並等待下一個要么從主機要么從設備來的流選擇（Stream selection）。

OUTMvData Host狀態由於設備有更多功能緩沖區（Function Buffer）空間可用來接收數據，因此主機執行如下動作來使OMDSM推進：

if (主機端點數據大小 > 最大包大小)

生成PP = 1的數據包DP，這樣就促使管道轉移到OUTMvData Device狀態。

else (主機端點數據大小 <= 最大包大小)

生成PP = 0的數據包DP，這樣就促使管道轉移到OUTMvData Host Terminate狀態。

上述描述OMDSM的偽代碼不依賴於接收到的ACK TP是否指示是重試（retry）。具有Retry的ACK TP應該影響被傳送的數據包DP的序列號（Sequence Number），並促使端點數據（Endpoint Data）被重傳（retransmitted）。

OUTMvData Host Terminate狀態由於主機沒有更多的端點數據（Endpoint Data）發送（PP = 0），因此設備應該生成NumP = 0的終結ACK TP，這樣就促使管道退出OMDSM並轉換到Idle狀態。如果設備檢測到主機發送的上一個數據包DP的錯誤，它應該用Retry ACK TP (Steam n, NumP>0, Rty=1)來響應，並且OMDSM應該轉換到OUTMvData Host狀態。

注意：如果一個數據包DP錯誤在OUTMvData Device狀態被檢測到，設備應該生成一個NumP > 0 且 Rty = 1的ACK TP，從而促使管道轉換到OUTMvData Host狀態並重新發送該包。

8.12.2 控制傳輸【Control Transfers】

控制傳輸至少有兩個事務階段：Setup 和 Status。控制傳輸可能可選地在Setup 和 Status之間有一個Data階段。Data階段的方向由位於Setup包的第一個字節的bmRequestType字段來指示。在Setup階段，SETUP事務被用來傳輸信息到設備的控制端點。SETUP事務在格式上與Bulk OUT事務類似，但是其DPH的Setup字段被設為1，且其Data Length字段被設為8。此外，Setup包總是使用數據序列號0。接收Setup包的設備應該按照8.11.4定義的那樣來響應。不論控制傳輸的階段和方向如何，在主機和設備的任意控制端點之間交換的任何TP或者DP中的Direction字段都應該設為0。【已勘誤】注意，如果設備已經成功接收到了SETUP包，如果端點想要對這個控制傳輸進行流程控制，端點可以返回NumP字段設為0的ACK TP來響應對該端點的SETUP包。設備必須發送一個ERDY來恢復這個控制傳輸，開始其Data或者Status階段。注意，主機可以恢復到任意端點的事務——即便該端點在返回流程控制響應之后還沒有返回一個ERDY TP。【已勘誤，主機不一定要（don't have to）等待一個ERDY才能與被流控的端點交談】。

控制傳輸的Data階段，如果存在的話，包含一個或者多個IN或者OUT事務，並遵循與批量傳輸相同的協議規則，除了控制傳輸的Direction字段應該總是設為0。【已勘誤】Data階段總是以序列號設為0開始。在Data階段的所有事務都必須是相同方向（也就是說，全部輸入或者全部輸出）。在數據階段最多能發送的數據長度以及方向在Setup階段指定。如果數據量超過數據包大小，數據被分成多個以最大包大小傳送的數據包來發送。所有剩下的數據在最后的數據包中作為收尾發送。

注意所有的控制端點只支持burst為1，因此主機一次只能與控制端點發送或者接收1個包。

控制傳輸的Status階段是整個序列中的最后一個事務。狀態階段事務由SubType設為STATUS的事物包TP來指示。作為對Deferred比特被設為0的STATUS TP的響應，設備應該發送一個NRDY, STALL, 或者ACK TP。如果設備發送一個NRDY TP，主機應該在發送另一個STATUS TP給設備之前，應該等待該控制端點發送一個ERDY TP。然而，主機可以恢復到任意端點的事務——即便該端點在返回流程控制響應之后還沒有返回一個ERDY TP。【已勘誤，主機不一定要（don't have to）等待一個ERDY才能與被流控的端點交談】。如果STATUS TP 中的Deferred比特被設置（為1），那么設備應該發送一個ERDY TP來告知已經准備好完成控制傳輸的狀態階段的主機。

圖8-33和8-34顯示事務順序，數據序列號值，以及控制讀和寫序列的數據包類型。

【勘誤：上圖中的所有IN(ACK TP)，都應該改為ACK TP。】

當一次控制傳輸的數據階段或者狀態階段中控制端點發送了一個STALL TP，那么所有后續的對該端點的訪問都應該返回STALL TP，直到收到一個SETUP DP。當端點收到一個后續SETUP DP時，端點應該返回一個ACK TP。對於控制端點，如果對於SETUP 事務返回了ACK TP，那么主機就期望其已經自動從導致STALL的條件中恢復，並且端點可以正常操作。

8.12.2.1 報告狀態結果【Reporting Status Results】

在Status階段，設備向主機報告該次傳輸前面的Setup和Data階段的結果（outcome）。可能返回3種可能結果：

• 命令序列完成成功。
• 命令序列完成失敗。

• 設備還在忙於完成命令。

狀態報告總是device-to-host方向。表8-29總結了各項要求的響應類型。所有的控制傳輸都在作為對STATUS TP事務的響應返回給主機的事務包中返回狀態。

表 8-29. 狀態階段響應【Status Stage Responses】

狀態響應	設備發送的事務包
請求完成	ACK TP
請求有錯	STALL TP
設備忙	NRDY TP

主機應該發送一個STATUS TP到控制端點來啟動Status階段。管道的握手響應指示當前狀態。NRDY TP指示設備正處理該命令並且設備應該在其完成命令時發送ERDY TP。ACK TP指示設備已經完成命令並且已經准備好接受新的命令。STALL TP指示設備出錯，阻礙了設備完成該命令。

設備的控制端點發送的ACK TP的NumP字段應該被設為0。但是這不被當作控制端點的流程控制條件。

如果在Data階段，控制端點被發送了或者被請求返回了多於在Setup階段所指示的數據，就應該返回STALL TP。如果控制端點在Data階段返回了STALL TP，這次從制傳輸就不應該再有Status階段。

8.12.2.2 可變長數據階段【Variable-length Data Stage】

控制管道可以有可變長的數據階段，在此情況下主機請求了比指定的數據結構包含得多的數據。當所有的數據結構都返回給主機后，設備通過返回一個數據負載少於最大包大小的數據包DP來指示數據階段結束。

注意如果返回給主機的數據結構少於主機請求的數量，且恰好是最大包大小的整數倍，那么控制端點應該發送一個零長數據包DP來終結該數據階段。

8.12.2.3 控制管道返回的STALL TPs 【STALL TPs Returned by Control Pipes】

控制管道具有特有的能力，由於控制傳輸的問題可以返回STALL TP。如果設備不能完成命令，在控制傳輸的數據和/或狀態階段返回STALL TP。與功能性STALL不同，協議性STALL並不代表設備出錯。協議性STALL情形保持到接收到下一個SETUP DP，並且設備應該對於該管道的所有的IN或者OUT事務都返回STALL TP，直到接收到SETUP DP。總之，協議性STALL指示請求或者其參數不能被理解，因此提供了一種機制來擴展USB請求。

設備不支持在控制管道上的功能性STALL。

8.12.3 總線間隔以及服務間隔【Bus Interval and Service Interval】

對於所有的周期性（中斷和等時）端點，端點必須被服務的間隔被叫做"服務間隔"。在本規范中，"總線間隔"被用來指代一個125 μs時隙。

8.12.4 中斷事務【Interrupt Transactions】

中斷傳輸類型被用於不經常且具有有限的服務期的數據傳輸。該類型支持有保證的有限時延的可靠數據傳輸。只要數據可用，該類型提供有保證的固定數據率。如果在被傳送的數據中檢測到錯誤，主機並不要求在相同的服務間隔內重傳該事務。但是，如果設備臨時不能發送或者接收數據（也就是說，以NRDY TP響應），主機只應該在從設備接收到一個ERDY TP后恢復對該端點的事務。中斷事務非常類似批量事務——但只限於每個服務間隔內3個數據包。只要設備能接受數據（對於OUT端點）或者返回數據（對於IN端點），主機應該以協同一致的服務間隔，連續執行對端點的事務。主機被要求對在服務間隔內成功接收到的每一個數據包DP發送一個ACK TP，即使這是該服務間隔的最后一個數據包DP。最后一個ACK TP應該確認最后一個數據包DP，且其Number of Packets字段應該被設為0。如果在當前服務間隔內對中斷端點執行事務時發生錯誤，主機沒有被要求必須在當前的服務間隔內重試該事務，但是主機最遲應該在下一個服務間隔內重試該事務。

8.12.4.1 中斷輸入事務【Interrupt IN Transactions】

當主機想要開始一次到端點的Interrupt IN事務時，就發送一個具有所期望的序列號以及期望從端點接收到多少個包的ACK TP到端點。如果設備能夠發送數據來響應主機的ACK TP，就可以在相同服務間隔內發送被請求個數的數據包上來。主機應該對每一個數據包DP響應一個ACK TP，指示對數據的成功接收；或者如果數據包負載（DPP）被損壞，應該發送一個ACK TP來請求重新發送數據包DP。

注意，在端點被初始化后（通過Set Configuration或者Set Interface或者ClearFeature(ENDPOINT_HALT)命令——參考第9章關於這些命令的詳情），當主機開始對特定端點的首次傳輸時，主機期望第一個數據包的序列號被設為0。

中斷端點應該如8.11.1所描述的那樣來響應從主機接收到的事務包s。只要設備返回數據來響應發送ACK TPs的主機，且傳輸還沒完成，主機就應該繼續在每一個服務間隔內向該設備的端點發送ACK TPs。

當任意如下條件之一滿足，主機就應該停止執行到設備端點的事務：

端點以NRDY 或者 STALL TP響應。
本次傳輸的所有數據都已成功接收到。
端點在發送給主機的最后一個數據包中設置了EOB標志。

當端點在接收到主機的ACK TP后，又不能以發送數據來響應，就應該發送一個NRDY（或者在由於是端點或者設備內部錯誤的情況下，發送STALL）TP給主機。主機在之后的服務間隔內就不應該執行更多的到端點的事務。如果在此前的服務間隔內該端點曾以流程控制響應，主機只有在其從端點接收到一個ERDY TP之后，方可恢復到端點的中斷事務。這就通知了主機端點已經准備好再次傳輸數據。一旦主機接收到ERDY TP，就應該在不遲於兩倍於端點描述符的bInterval 字段的時間內發送一個IN請求（通過ACK TP）到端點。中斷端點應該通過返回一個DP（序列號比上一次成功發送的數據多1），或者，假如不能發送數據，就返回一個NRDY 或者一個STALL TP。

如果設備接收到一個推遲的中斷IN TP，且設備需要發送中斷IN數據，設備應該發送一個ERDY TP來響應，並保持鏈路在U0狀態，直到從主機接收到后續的中斷事務，或者到tPingTimeout（參考表8-33）超時。

正如Bulk事務的情形，序列號對於中斷端點每次發送的包是連續增加的。當序列號達到31，就回繞至0。

注意：在圖8-39中，主機在同一個服務間隔內重試接收到的有錯誤的數據包。並不是強制要如此，也可以再下一個服務間隔內重試該事務。

8.12.4.2 終端輸出事務【Interrupt OUT Transactions】

當主機想要開始一次到端點的Interrupt OUT事務時，就以期望的序列號發送第一個DP。如果端點支持大於1的突發大小（burst size），主機就可以在相同服務間隔內發送多個數據包到端點。如果端點能夠接收主機發來的數據，就發送一個ACK TP來確認對數據的成功接收。

注意，在端點被初始化后（通過Set Configuration或者Set Interface或者ClearFeature(ENDPOINT_HALT)命令——參考第9章關於這些命令的詳情），當主機開始對端點的首次傳輸時，主機總是將第一個數據包的序列號設為0。

只要設備返回ACK TPs來響應發送數據包的主機，且傳輸還沒完成，主機就應該繼續在每一個服務間隔內向該設備的端點發送數據。設備應該確認對數據包的成功接收，或者請求主機重傳，如果數據包被損壞的話。

中斷端點應該如8.11.3節所述來響應主機發送的OUT數據。

當端點在接收到主機的數據后，又暫時不能接受數據，就應該發送一個NRDY（或者在由於是端點或者設備內部錯誤的情況下，發送STALL）TP給主機。主機在之后的服務間隔內就不應該執行更多的到端點的事務。如果在此前的服務間隔內該端點曾以流程控制響應，主機只有在其從端點接收到一個ERDY TP之后，方可恢復到端點的中斷事務。這就通知了主機端點已經准備好再次接收數據。一旦主機接收到ERDY TP，就應該在不遲於兩倍於端點描述符的bInterval 字段的時間內發送數據包到端點。

如果設備接收到一個推遲的中斷OUT DPH，且設備需要接收中斷OUT數據，設備應該發送一個ERDY TP來響應，並保持鏈路在U0狀態，直到從主機接收到后續的中斷事務，或者到tPingTimeout（參考表8-33）超時。

正如Bulk事務的情形，序列號對於主機每次發送的包是連續增加的。當序列號達到31，就回繞至0。

注意：在圖8-43中，主機在同一個服務間隔內重試設備接收到的有錯誤的數據包。並不是強制要如此，也可以再下一個服務間隔內重試該事務。

8.12.5 主機時序信息【Host Timing Information】

USB 3.0主機控制器在SuperSpeed USB鏈路上不定期廣播幀開始（SOF）包到所有的設備。主機時序信息只在根端口鏈路處於U0狀態，在總線間隔附近，通過等時時戳包（ITP）被主機發送。集線器轉發等時時戳包到所有的鏈路處於U0狀態的下行口。主機應該給予一個非擴頻時鍾來提供等時時戳包。如果必須要等時時戳包來使設備可操作，設備就有責任在總線間隔附近將鏈路保持在U0狀態。除非必須要等時時戳包來使設備操作，設備絕不應該僅僅為了接收等時時戳包而將鏈路保持於U0狀態。

注意：如果設備的鏈路在總線間隔附近處於U0狀態，設備就會接收到等時時戳包。這就意味着沒有等時端點的設備，或者無需同步的設備可能會丟棄等時時戳包，而不會有負面的副作用。如果設備具有用來判定何時將鏈路置於低功耗狀態的不活動定時器，則在接收到等時時戳包時，設備可以選擇不重置其不活動定時器。

時序信息被放在等時時戳包中，在總線間隔附近發送，並傳遞當前的總線間隔，以及本時戳包的開始到前一次總線間隔之間的時間。等時端點要求125 * 2^n μs的服務間隔，其中n是0到15（包括）之間的整數。

等時時戳包（ITPs）傳遞時序信息，以便所有的等時端點都接收到相同的間隔邊界。在所有時候，主機都應該保持對所有的端點的服務間隔邊界對齊，除非主機鏈路進入了U3狀態。在主機的根端口的鏈路從U3狀態退出后發送的等時時戳包（ITPs）可能與在主機的根端口的鏈路進入U3狀態前的等時時戳包（ITPs）邊界對齊。在主機的根端口的鏈路從U3狀態退出進入U0后，主機應該在tIsochronousTimestampStart時間內開始傳送等時時戳包（ITPs）。圖8-45顯示了一個示例，一個活動的等時IN端點和一個活動的等時OUT端點連接在同一個USB 3.0主機控制器下面。等時IN端點的服務間隔是X，等時OUT端點的服務間隔是2X。注意主機在適當的服務間隔內的任意位置可以隨意調度等時IN（通過ACK TP）或者等時OUT數據。設備將會通過檢測Bus Interval Counter的低比特位（least significant bits）的翻轉（rollover）來檢測服務間隔（service interval）的開始。具體需要監控（monitored）多少比特位的翻轉是由bInterval定義的。例如，如果服務間隔（service interval）等於2個Bus Intervals，則服務間隔（service interval）的開始是由Bus Interval Counter的最低位轉換到'0'定義的。如果服務間隔（service interval）等於4個Bus Intervals，則服務間隔（service interval）的開始由Bus Interval Counter的最低兩位轉換到'0'定義的，以此類推。如果bInterval是1，則設備會在Bus Interval Counter的最低位改變時，檢測到服務間隔（service interval）的開始。【已勘誤】設備不應該假設事務在每一個服務間隔的相同的位置發生。主機應該保證事務不會跨越服務邊界那樣來調度事務。

8.12.6 等時事務【Isochronous Transactions】

IN等時事務被顯示在圖8-46，OUT等時事務被顯示在圖8-47。對於輸入（INs），主機發送一個ACK TP，緊隨其后是端點對輸入請求（INs）傳送數據的數據相位。對於輸出（OUTs），主機在當前服務間隔內有數據發送時，只是簡單地發送數據。等時事務不支持重試能力。

每個服務間隔只有一個數據包的超高速等時事務總是使用序列號0。對於一個服務間隔包含多個數據包的超高速等時事務，序列號對於每一個數據包都增加1。在任意的服務間隔中發送的第一個數據包的序列號總是0。主機應該能在每個服務間隔內發送多達48個數據包（DP）。在每個服務間隔中的第一個DP的序列號應該設為0開始。第二個DP的序列號應該設為1；第三個DP的序列號應該設為2；以此下去，直到序列號31。序列號31的下一個DP使用序列號0。具有等時端點的超高速設備應該能夠發送或者接收由短端點或者端點伴侶描述符指示的數據包個數（序列號為0 – N）。

服務間隔中的最后一個包在發送時應該將lpf字段設為1，並且可以小於或等於MaxPacketSize字節。在服務間隔中的除最后一個包之外的每個包，都應該在發送時將lpf字段設為0，而且應該等於MaxPacketSize字節。【已勘誤】如果主機在服務間隔內沒有數據發送給等時OUT，那么主機在該間隔內不發送任何東西。如果有等時IN端點的設備收到等時IN ACK TP時，沒有數據需要發送，設備應該發送一個零長數據包。圖8-48和圖8-49顯示了對於端點的等時IN和OUT事務的示例，每個服務間隔請求2000字節帶寬（也就是說，每個服務間隔可以發送或接收不多於兩個數據包）。

如果由於錯誤條件導致主機在指定的間隔內不能發送等時數據，主機丟棄數據並通知主機軟件發生了該錯誤。如果由於錯誤條件導致主機在指定的間隔內不能發送等時ACK TP，主機也要通知主機軟件發生了該錯誤。

8.12.6.1 主機執行等時事務的靈活性【Host Flexibility in Performing Isochronous Transactions】

主機被賦予了一定的靈活性來在服務間隔內執行等時服務。主機可以用一個等時突發事務傳輸到（或者從）端點的所有的數據包（DPs），或者可以將傳輸分成更小的突發，以2個，4個，或者8個數據包（DPs）緊跟該服務間隔最后剩余數據包（DPs）構成的等時突發。主機不能以任意其他方式執行等時事務。對於具有乘數值大於1的等時端點，這些規則對與每一個乘數值相關聯的突發事務都單獨適用。設備應該支持由這些規則允許的所有可能的主機突發事務。例如，如果等時IN端點請求一次突發最多11個包，而且主機在該服務間隔內有11個包可以從端點接收，主機就有5種可能的方式來執行事務。

請求1次突發11個包
請求1次突發8個包，接着1次突發3個包
請求2次突發4個包，接着1次突發3個包
請求5次突發2個包，接着1次突發1個包
請求11次突發1個包【已勘誤，添加了這個例子，因為現在ISO傳輸可以支持1次突發一個包（burst of 1）】

將上面的例子進一步，如果等時IN端點請求一次突發最多11個包，且Mult為2（本質上請求3次，每次突發11個包），並且在服務間隔期間主機有緩沖來從設備端點接收33個包，則主機可以使用上面提到的選項的任意組合來從端點傳輸3組，每組11個包的突發。

主機不能在服務間隔內重置序列號。主機應該只在服務間隔的最后一個突發的最后一個包中設置LPF標記。

8.12.6.2 設備對於等時IN事務的響應【Device Response to Isochronous IN Transactions】

表8-30列出了設備對於ACK TP可能的響應。如果Device Address不正確，或者端點號和方向沒有引用當前配置的端點，或者其序列號不正確，或者其中的deferred位被設置了，則一個ACK TP會被認為是無效的。

表8-30. 設備對於等時IN事務的響應

接收到的ACK TP 無效	設備可以發送數據	執行的動作
Yes	不關心	不返回響應
No	No	返回序列號為0的數據包
No	Yes	返回N個數據包，序列號從0到N-1。除了最后一個包之外，每個包都應該是MaxPacketSize字節。最后一個包可以小於或等於MaxPacketSize字節。最后一個包應該將LPF標記設置上。

8.12.6.3 主機處理等時IN事務【Host Processing of Isochronous IN Transactions】

表8-31列出主機從IN事務處理數據。主機從不對接收到的等時IN數據返回響應。在表8-31中，數據包DP錯誤可能是一個或者多個如下的原因：

CRC-32不正確（incorrect）
DPP中止（aborted）
DPP丟失（missing）
DPH的數據長度與實際數據負載長度不匹配
如果主機接收到一個損壞的數據，就丟棄當前服務間隔的剩余數據，並通知主機軟件發生了該錯誤。

表 8-31. 主機響應IN事務

數據包錯誤	主機可以接收數據	主機數據處理
Yes	N/A	丟棄數據
No	No（這對於兼容的主機實現是永遠不應該發生的）	丟棄數據
No-數據包有期望的序列號	Yes	接受數據
No-數據包沒有期望的序列號	Yes	丟棄數據

8.12.6.4 設備對於等時OUT數據包的響應【Device Response to an Isochronous OUT Data Packet】

表8-32列出設備從OUT數據包處理數據。設備從不返回TP來響應。在表8-32中，數據包DP錯誤可能是一個或者多個如下的原因：

CRC-32不正確（incorrect）
DPP中止（aborted）
DPP丟失（missing）
DPH的數據長度與實際數據負載長度不匹配
DPH中的Deferred位被設置

表8-32. 設備對於等時OUT數據包的響應

數據包錯誤	期望的序列號	設備可以接收數據	設備數據處理
Yes	不關心	不關心	丟棄數據
No	Yes	Yes	接受數據
No	Yes	No	數據被丟棄
No	No	No	數據被丟棄。設備可以丟棄當前服務間隔內任意額外的數據
No	No	Yes	數據被丟棄。設備可以丟棄當前服務間隔內任意額外的數據

8.13 時序參數【Timing Parameters】

表8-33列出了在接收到各種各樣的包時，設備需要遵從的最小和（或）最大時間值。該表也列出了設備可以在延遲忍耐消息（Latency Tolerance messages）中設置的默認和最小時間值，以及在從接收到某些事物包（TPs）到其可以發起進入U1或者U2之間的最小時間值。此外，該表還列出了設備在進行突發時必須遵循的數據包（DPs）之間的最長時間。

注意所有的txxxResponse（例如，tNRDYResponse）和tMaxBurstInterval時間值都是設備在沒有別的其它東西發送給上行鏈路時必須滿足的時序要求。

表 8-33. 時序參數

名字（Name）	描述（Description）	最小（Min）	最大（Max）	單位（Units）
tPortConfiguration	從端口進入U0到它完成交換LMPs之間的最大時間。對於tiebreaker的情形（參見表8-7），兩個端口都應該復位它們的定時器並在每個LMP交換時都重啟它們，直到tiebreaker被解決。【已勘誤】		20	μs
tPingTimeout	設備接收到一個ping之后，到其可以發起或者接受U1或者U2請求之間的超時值。該參數的測量要以設備的所有等時端點的所有服務間隔的最大值為依據。【已勘誤】	2		服務間隔
tPingResponse	設備接收到上一個ping的分幀符號（framing symbol）以及ping_response的第一個分幀符號（framing symbol）之間的時間。		400	ns
tBELTDefault	默認的最大努力延遲忍耐（best effort latency tolerance）	1		ms
tBELTmin	在延遲忍耐消息（Latency Tolerance Message）中允許的最小的最大努力延遲忍耐（best effort latency tolerance）	125		μs
tNRDYorSTALLResponse	設備接收到上一個ACK TP 或者 DPP或者STATUS TP的分幀符號（framing symbol）以及NRDY或者STALL響應的第一個分幀符號（framing symbol）之間的時間。【已勘誤】		400	ns
tDPResponse	設備接收到上一個ACK TP的分幀符號（framing symbol）以及DP響應的第一個分幀符號（framing symbol）之間的時間。		400	ns
tACKResponse	設備接收到上一個DPP或者STATUS TP的分幀符號（framing symbol）以及ACK響應的第一個分幀符號（framing symbol）之間的時間。【已勘誤】		400	ns
tHostACKResponse	主機接收到上一個DPP的分幀符號（framing symbol）以及ACK響應的第一個分幀符號（framing symbol）之間的時間。		3	ns
tERDYTimeout	設備發送ERDY到主機之后，到其因沒有得到服務，而可以發起或者接受U1或者U2請求之間的超時值。【已勘誤】	500		ms
tNotification	(從發送上一個功能喚醒通知開始)如果設備還沒有被訪問過，設備應該發送功能喚醒通知（function wake notification）的比率（rate）。	2500		ms
tMaxBurstInterval	設備或者主機在進行突發時數據包（DPs）之間的時間。如果設備不能滿足最大時間要求，那么就應該在其發送的最后一個數據包（DP）中設置EOB標志。		100	ns
tTimestampWindow	如果根端口的鏈路處於U0狀態，主機應該從總線間隔邊界開始到總線間隔邊界之后的tTimestampWindow之間傳送等時時間戳。	0	8	μs
tIsochTimestampGranularity	等時時間戳的粒度	8	8	USB 2.0 High-Speed 比特時間
BusIntervalAdjustmentGranularity	對於設備請求的總線間隔改變的調整單位。		4.0690104 【注1】	ps
tIsochronousTimestampStart	從主機在根端口鏈路從輪詢狀態進入U0狀態,或者從主機的根端口的鏈路從U3狀態退出進入U0，到主機應該開始傳送等時時間戳的時間。		250	μs
tBELTRepeat	設備被允許發送多於兩個延遲忍耐消息事務包（LTM TPs）的時間段	1		ms
tMinLTMStateChange	外圍設備在完成使能或者禁止LTM_Enable 特性請求之后，必須要發送延遲忍耐消息通知（LTM notification）的時間		10	ms
tHostTransactionTimeout	對於控制，批量，和中斷事務，定義為在主機認為該事務已經失敗而halt該端點之前，沒有收到對主機發送出去的上一個DP或ACK TP的響應的時間。對於等時IN事務，定義為沒有收到對主機發送的ACK TP的響應的時間。每當主機接收到ACK TP所請求的每個包時，就初始化並重啟定時器。如果出現超時，則主機在當前服務間隔內就不應該再對該端點執行更多事務。主機不允許halt該端點，而應該在下一個服務間隔內重啟到該端點的事務。不應該執行重試。	32	5032	μs

【注1： (tIsochTimestampGranularity/4096)】

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 USB 3.0規范中譯本第6章物理層 USB 3.0規范中譯本第5章機械結構 USB 3.0規范中譯本第3章 USB 3.0體系結構概覽 USB協議規范學習（一）接口與協議學習筆記-USB協議_USB2.0_USB3.0不同版本（三） USB OTG有關協議 USB HID 協議入門 USB協議詳解 USB通訊協議二十四、USB協議