【正文】 inference, the start of the PID. Packet Field Formats Field formats for the token, data, and handshake packets are described in the following section. Packet bit definitions are displayed in unencoded data format. The effects of NRZI coding and bit stuffing have been removed for the sake of clarity. All packets have distinct Start and EndofPacket delimiters. The Startof Packet (SOP) delimiter is part of the SYNC field. Token Packets Figure 85 shows the field formats for a token packet. A token consists of a PID, 7 specifying either IN, OUT, or SETUP packet type and ADDR and ENDP fields. The PING special token packet also has the same fields as a token packet. For OUT and SETUP transactions, the address and endpoint fields uniquely identify the endpoint that will receive the subsequent Data packet. For IN transactions, these fields uniquely identify which endpoint should transmit a Data packet. For PING transactions, these fields uniquely identify which endpoint will respond with a handshake packet. Only the host can issue token packets. An IN PID defines a Data transaction from a function to the host. OUT and SETUP PIDs define Data transactions from the host to a function. A PING PID defines a handshake transaction from the function to the host. Token packets have a fivebit CRC that covers the address and endpoint fields as shown above. The CRC does not cover the PID, which has its own check field. Token and SOF packets are delimited by an EOP after three bytes of packet field data. If a packet decodes as an otherwise valid token or SOF but does not terminate with an EOP after three bytes, it must be considered invalid and ignored by the receiver. StartofFrame Packets StartofFrame (SOF) packets are issued by the host at a nominal rate of once every ms ms for,a fullspeed bus and 125 μs μs for a highspeed bus. SOF packets consist of a PID indicating packet type followed by an 11bit frame number field as illustrated in Figure 813. The SOF token prises the tokenonly transaction that distributes an SOF marker and acpanying frame number at precisely timed intervals corresponding to the start of 8 each frame. All highspeed and fullspeed functions, including hubs, receive the SOF packet. The SOF token does not cause any receiving function to generate a return packet。 they can ignore the frame number and its CRC. If a function needs to track frame number, it must prehend both the PID and the time stamp. Fullspeed devices that have no particular need for bus timing information may ignore the SOF packet. Handshake Packets Handshake packets are used to report the status of a data transaction and can return values indicating successful reception of data, mand acceptance or rejection, flow control, and halt conditions. Only transaction types that support flow control can return handshakes. Handshakes are always returned in the handshake phase of a transaction and may be returned, instead of data, in the data phase. Handshake packets are delimited by an EOP after one byte of packet field. If a packet decodes as an otherwise valid handshake but does not terminate with an EOP after one byte, it must be considered invalid and ignored by the receiver. There are four types of handshake packets and one special handshake packet: indicates that the data packet was received without bit stuff or CRC errors over the data field and that the data PID was received correctly. ACK may be issued either when sequence bits match and the receiver can accept data or when sequence bits mismatch and the sender and receiver must resynchronize to each other. An ACK handshake is applicable only in transactions in which data has been transmitted and where a handshake is expected. ACK can be returned by the host for IN transactions and by a function for OUT, SETUP, or PING transactions. indicates that a function was unable to accept data from the host (OUT) or that a function has no data to transmit to the host (IN). NAK can only be returned by functions in the data phase of IN transactions or the handshake phase of OUT or PING transactions. The host can never issue NAK. NAK is used for flow control purposes to indicate that a function is temporarily unable to transmit or receive data, but will eventually be able to do so without need of host intervention. is returned by a function in response to an IN token or after the data phase 9 of an OUT or in response to a PING transaction. STALL indicates that a function is unable to transmit or receive data, or that a control pipe request is not supported. The state of a function after returning a STALL (for any endpoint except the default endpoint) is undefined. The host is not permitted to return a STALL under any condition. The STALL handshake is used by a device in one of two distinct occasions. The first case, known as “functional stall,” is when the Halt feature associated with the endpoint is set. A special case of the functional stall is the “manded stall.” Once a function?s endpoint is halted, the function must continue returning STALL until the condition causing the halt has been cleared through host intervention. Protocol stall is unique to control pipes. Protocol stall differs from functional stall in meaning and duration. A protocol STALL is returned during the Data or Status stage of a control transfer, and the STALL condition terminates at the beginning of the next control transfer (Setup). The remainder of this section refers to the general case of a functional stall. 2 Transaction Packet Sequences The packets that prise a transaction varies depending on the endpoint type. There are four endpoint types: bulk, control, interrupt, and isochronous. Batch transaction type were characterized by the error detection and retry way to ensure the host a