Technical Comparision Beetween versions of USB family in transfer modes

TECHNICAL COMPARISION
	USB 2.0	USB 3.0	USB 3.1
	Control transfer	Control transfer	Control transfer
Control Transfer	Control transfers allow access to different parts of a device. Control transfers are intended to support configuration/command/status type communication flows between client software and its function. A control transfer is composed of a Setup bus transaction moving request information from host to function, zero or more Data transactions sending data in the direction indicated by the Setup transaction, and a Status transaction returning status information from function to host. The Status transaction returns “success” when the endpoint has successfully completed processing the requested operation.	The purpose and characteristics of Control Transfers are identical to those defined in the Universal Serial Bus Specification, Revision 2.0.	The purpose and characteristics of Control Transfers are identical to those defined in the Universal Serial Bus Specification, Revision 2.0.
Setup Stage	SETUP transactions are similar in format to an OUT but use a SETUP rather than an OUT PID.A SETUP always uses a DATA0 PID for the data field of the SETUP transaction. The function receiving a SETUP must accept the SETUP data and respond with ACK; if the data is corrupted, discard the data and return no handshake.	During the Setup stage, a SETUP transaction is used to transmit information to a control endpoint of the device. SETUP transactions are similar in format to a Bulk OUT transaction but have the Setup field set to one in the DPH along with the Data Length field set to eight. In addition, the Setup packet always uses a Data sequence number of zero. A device receiving a Setup packet shall respond as defined in Section 8.11.4(USB 3.0). The Direction field shall be set to zero in TPs or DPs exchanged between the host and any control endpoint on the device regardless of the stage or direction of the control transfer. Note that if the endpoint successfully received the SETUP packet, it may return an ACK TP with the NumP field set to zero if it wants to flow control the control transfer. A device shall send an ERDY when it is ready to resume the control transfer (either the Data or Status stage). Note that an endpoint may return an ACK TP with the NumP field set to zero in response to a SETUP packet if it wants to flow control the control transfer. A device must send an ERDY to start the Data or Status stage. Note that the host may resume transactions to any endpoint – even if the endpoint had not returned an ERDY TP after returning a flow control response.	No change
Data Stage	The Data stage, if present, of a control transfer consists of one or more IN or OUT transactions and follows the same protocol rules as bulk transfers. All the transactions in the Data stage must be in the same direction (i.e., all INs or all OUTs). The amount of data to be sent during the data stage and its direction are specified during the Setup stage. If the amount of data exceeds the prenegotiated data packet size, the data is sent in multiple transactions (INs or OUTs) that carry the maximum packet size. Any remaining data is sent as a residual in the last transaction.	The Data stage, if present, of a control transfer consists of one or more IN or OUT transactions and follows the same protocol rules as bulk transfers except that the Direction field shall always be set to zero. The Data stage always starts with the sequence number set to zero. All the transactions in the Data stage shall be in the same direction (i.e., all INs or all OUTs). The maximum amount of data to be sent during the data stage and its direction are specified during the Setup stage. If the amount of data exceeds the data packet size, the data is sent in multiple data packets that carry the maximum packet size. Any remaining data is sent as a residual in the last data packet. Note that all control endpoints only support a burst of one and hence the host can only send or receive one packet at a time to or from a control endpoint.	No change
Status Stage	The Status stage of a control transfer is the last transaction in the sequence. The status stage transactions follow the same protocol sequence as bulk transactions. Status stage for devices operating at high-speed also includes the PING protocol. A Status stage is delineated by a change in direction of data flow from the previous stage and always uses a DATA1 PID. If, for example, the Data stage consists of OUTs, the status is a single IN transaction. If the control sequence has no Data stage, then it consists of a Setup stage followed by a Status stage consisting of an IN transaction.	The Status stage of a control transfer is the last transaction in the sequence. The status stage transaction is identified by a TP with the SubType set to STATUS. In response to a STATUS TP with zero in the Deferred bit, a device shall send an NRDY, STALL, or ACK TP. If a device sends an NRDY TP, the host shall wait for it to send an ERDY TP for that control endpoint before sending another STATUS TP to the device. However the host may resume transactions to any endpoint – even if the endpoint had not returned an ERDY TP after returning a flow control response. If the Deferred bit is set in the STATUS TP, then the device shall send an ERDY TP to indicate to the host that is ready to complete the status stage of the control transfer.	No change
ACK	Function completes	Request completes:ACK TP	ACK TP
NAK/NRDY	Function is busy:NAK	Device is busy :NRDY TP	NRDY TP
STALL	Function has Error	Request has an error : STALL TP	STALL TP
Control Transfer packet size constraints	* An endpoint for control transfers specifies the maximum data payload size that the endpoint can accept from or transmit to the bus. The allowable maximum control transfer data payload sizes for full-speed devices is 8, 16, 32, or 64 bytes; for high-speed devices, it is 64 bytes and for low-speed devices, it is 8 bytes. This maximum applies to the data payloads of the Data packets following a Setup; i.e., the size specified is for the data field of the packet as defined in Chapter 8(USB spec 2.0), not including other information that is required by the protocol. A Setup packet is always eight bytes. A control pipe (including the Default Control Pipe) always uses its wMaxPacketSize value for data payloads. * All Host Controllers are required to have support for 8-, 16-, 32-, and 64-byte maximum data payload sizes for full-speed control endpoints, only 8-byte maximum data payload sizes for low-speed control endpoints, and only 64-byte maximum data payload size for high-speed control endpoints. No Host Controller is required to support larger or smaller maximum data payload sizes.	Control endpoints have a fixed maximum control transfer data payload size of 512 bytes and have a maximum burst size of one. These maximums apply to all data transactions during the data stage of the control transfer.	No change
Control Transfer Direction	Control transfers are supported via bi-directional communication flow over message pipes. As a consequence, when a control pipe is configured, it uses both the input and output endpoint with the specified endpoint number.	The direction of the Data stage is indicated by the bmRequestType field which is present in the first byte of the data payload of the Setup packet.	No change
Variable length data stage	A control pipe may have a variable-length data phase in which the host requests more data than is contained in the specified data structure. When all of the data structure is returned to the host, the function should indicate that the Data stage is ended by returning a packet that is shorter than the MaxPacketSize for the pipe. If the data structure is an exact multiple of wMaxPacketSize for the pipe, the function will return a zero-length packet to indicate the end of the Data stage.	A control pipe may have a variable-length data phase in which the host requests more data than is contained in the specified data structure. When all of the data structure is returned to the host, a device indicates that the Data stage is ended by returning a DP that has a payload less than the maximum packet size for that endpoint. Note that if the amount of data in the data structure that is returned to the host is less than the amount requested by the host and is an exact multiple of maximum packet size then a control endpoint shall send a zero length DP to terminate the data stage.	No change
control Transfer Bus Access constraints	* If the control transfers that are attempted (in an implementation-dependent fashion) consume less than 10% of the frame time for full-/low-speed endpoints or less than 20% of a microframe for high-speed endpoints, the remaining time can be used to support bulk transfers. * A control transfer that has been attempted and needs to be retried can be retried in the current or a future (micro)frame; i.e., it is not required to be retried in the same (micro)frame. * If there are more control transfers than reserved time, but there is additional (micro)frame time that is not being used for isochronous or interrupt transfers, a Host Controller may move additional control transfers as they are available. * If there are too many pending control transfers for the available (micro)frame time, control transfers are selected to be moved over the bus as appropriate. *If there are control transfers pending for multiple endpoints, control transfers for the different endpoints are selected according to a fair access policy that is Host Controller implementation-dependent. * A transaction of a control transfer that is frequently being retried should not be expected to consume an unfair share of the bus time.	*The transactions of a control transfer may be scheduled coincident with transactions for other function endpoints of any defined transfer type. * Retries of control transfers are not given priority over other best effort transactions. *If there are control and bulk transfers pending for multiple endpoints, control transfers for different endpoints are selected for service according to a fair access policy that is host controller implementation-dependent. *SuperSpeed Data Flow Model When a control endpoint delivers a flow control event the host will remove the endpoint from the actively scheduled endpoints. The host will resume the transfer to the endpoint upon receipt of a ready notification from the device.	No change
Control Transfer Data Sequence	The USB provides robust error detection and recovery/retransmission for errors that occur during control transfers. Transmitters and receivers can remain synchronized with regard to where they are in a control transfer and recover with minimum effort. Retransmission of Data and Status packets can be detected by a receiver via data retry indicators in the packet. A transmitter can reliably determine that its corresponding receiver has successfully accepted a transmitted packet by information returned in a handshake to the packet. The protocol allows for distinguishing a retransmitted packet from its original packet except for a control Setup packet. Setup packets may be retransmitted due to a transmission error; however, Setup packets cannot indicate that a packet is an original or a retried transmission.	No change	No change
	Interrupt Transaction	Interrupt Transaction	Interrupt Transaction
Interrupt Transaction	* Guaranteed maximum service period for the pipe * Retry of transfer attempts at the next period, in the case of occasional delivery failure due to error on the bus	* Guaranteed maximum service interval * Guaranteed retry of transfer attempts in the next service interval	No change
Interrupt Transaction data format	The USB imposes no data content structure on communication flows for interrupt pipes.	The USB imposes no data content structure on communication flows for interrupt pipes.	No change
Interrupt Transaction direction	An interrupt pipe is a stream pipe and is therefore always uni-directional. An endpoint description identifies whether a given interrupt pipe’s communication flow is into or out of the host.	An interrupt pipe is a stream pipe and, therefore, is always unidirectional	No change
interrupt Transaction packet size constraints	An endpoint for an interrupt pipe specifies the maximum size data payload that it will transmit or receive. The maximum allowable interrupt data payload size is 64 bytes or less for full-speed. High-speed endpoints are allowed maximum data payload sizes up to 1024 bytes. A high speed, high bandwidth endpoint specifies whether it requires two or three transactions per microframe. Low-speed devices are limited to eight bytes or less maximum data payload size. This maximum applies to the data payloads of the data packets; i.e., the size specified is for the data field of the packet as defined in Chapter 8, not including other protocol-required information. The USB does not require that data packets be exactly the maximum size; i.e., if a data packet is less than the maximum, it does not need to be padded to the maximum size. All Host Controllers are required to support maximum data payload sizes from 0 to 64 bytes for full-speed interrupt endpoints, from 0 to 8 bytes for low-speed interrupt endpoints, and from 0 to 1024 bytes for high- speed interrupt endpoints. See Section 5.9(usb 2.0) for more information about the details of multiple transactions per microframe for high bandwidth high-speed endpoints. No Host Controller is required to support larger maximum data payload sizes.	An endpoint for interrupt transfers specifies the maximum data packet payload size that it can accept from or transmit on the SuperSpeed bus. The only allowable maximum data payload size for interrupt endpoints is 1024 bytes for interrupt endpoints that support a burst size greater than one and can be any size from 1 to 1024 for an interrupt endpoint with a burst size equal to one. The maximum allowable burst size for interrupt endpoints is three. All SuperSpeed interrupt endpoints shall support sequence values in the range [0-31].	No change
Interrupt Transaction Bus Access constraints	Interrupt transfers can be used by low-speed, full-speed, and high-speed devices. High-speed endpoints can be allocated at most 80% of a microframe for periodic transfers. The USB requires that no more than 90% of any frame be allocated for periodic (isochronous and interrupt) full-/low-speed transfers. The bus frequency and (micro)frame timing limit the maximum number of successful interrupt transactions within a (micro)frame for any USB system to less than 108 full-speed one-byte data payloads, or less than 10 low-speed one-byte data payloads, or to less than 134 high-speed one-byte data payloads. A Host Controller, for various implementation reasons, may not be able to provide the above maximum number of interrupt transactions per (micro)frame.	Periodic endpoints may be allocated up to 90% of the total available bandwidth on SuperSpeed. An endpoint for an interrupt pipe specifies its desired service interval bound via its endpoint descriptor. An interrupt endpoint can specify a desired period 2 (bInterval-1) x 125 μs, where bInterval is in the range 1 up to (and including) 16. The USB System Software will use this information during configuration to determine a period that can be sustained. The period provided by the system may be shorter than that desired by the device up to the shortest period defined by the SuperSpeed (125 μs which is also referred to as a bus interval). Note that errors on the bus can prevent an interrupt transaction from being successfully delivered over the bus and consequently exceed the desired period.	No change
Interrupt Transaction data sequence	Interrupt transactions may use either alternating data toggle bits, such that the bits are toggled only upon successful transfer completion or a continuously toggling of data toggle bits. The host in any case must assume that the device is obeying full handshake/retry rules as defined in Chapter 8(usb 2.0). A device may choose to always toggle DATA0/DATA1 PIDs so that it can ignore handshakes from the host. However, in this case, the client software can miss some data packets when an error occurs, because the Host Controller interprets the next packet as a retry of a missed packet.	No change	No change
ACK	Host handshake	Host handshake	No change
NAK/NRDY	function handshake:NAK	Host handshake	No change
STALL	function handshake	Device Error	No change
	Isochronous Transaction	Isochronous Transaction	Isochronous Transaction
Isochronous Transaction	* Guaranteed access to USB bandwidth with bounded latency * Guaranteed constant data rate through the pipe as long as data is provided to the pipe * In the case of a delivery failure due to error, no retrying of the attempt to deliver the data	* Guaranteed bandwidth for transaction attempts on the SuperSpeed bus with bounded latency * Guaranteed data rate through the pipe as long as data is provided to the pipe * No retry	No change
Isochronous Transaction data format	The USB imposes no data content structure on communication flows for isochronous pipes.	The USB imposes no data content structure on communication flows for isochronous pipes.	No change
Isochronous Transaction direction	An isochronous pipe is a stream pipe and is, therefore, always uni-directional. An endpoint description identifies whether a given isochronous pipe’s communication flow is into or out of the host. If a device requires bi-directional isochronous communication flow, two isochronous pipes must be used, one in eachdirection.	No change	No change
Isochronous Transaction packet size constraints	The USB limits the maximum data payload size to 1,023 bytes for each full-speed isochronous endpoint. High-speed endpoints are allowed up to 1024-byte data payloads. A high speed, high bandwidth endpoint specifies whether it requires two or three transactions per microframe	An endpoint for isochronous transfers specifies the maximum data packet payload size that the endpoint can accept from or transmit on SuperSpeed. The only allowable maximum data payload size for isochronous endpoints is 1024 bytes for isochronous endpoints that support a burst size greater than one and can be any size from 0 to 1024 for an isochronous endpoint with a burst size equal to one. The maximum allowable burst size for isochronous endpoints is 16. However an isochronous endpoint can request up to three burst transactions in the same service interval.	No change
Isochronous Transaction Bus Access constraints	The USB requires that no more than 90% of any frame be allocated for periodic (isochronous and interrupt) transfers for full-speed endpoints. High-speed endpoints can allocate at most 80% of a microframe for periodic transfers. The bus frequency and (micro)frame timing limit the maximum number of successful isochronous transactions within a (micro)frame for any USB system to less than 151 full-speed one-byte data payloads and less than 193 high-speed one-byte data payloads. A Host Controller, for various implementation reasons, may not be able to provide the theoretical maximum number of isochronous transactions per (micro)frame.	Periodic endpoints can be allocated up to 90% of the total available bandwidth on SuperSpeed. An endpoint for an isochronous pipe specifies its desired service interval bound via its endpoint descriptor. An isochronous endpoint can specify a desired period 2 (bInterval-1) x 125 μs, where bInterval is in the range 1 to 16. The system software will use this information during configuration to determine whether the endpoint can be added to the host schedule. Note that errors on the bus can prevent an isochronous transaction from being successfully delivered over the bus.	No change
Isochronous Transaction data sequence	Isochronous transfers do not support data retransmission in response to errors on the bus. A receiver can determine that a transmission error occurred. The low-level USB protocol does not allow handshakes to be returned to the transmitter of an isochronous pipe. Normally, handshakes would be returned to tell the transmitter whether a packet was successfully received or not. An endpoint for isochronous transfers never halts because there is no handshake to report a halt condition. Errors are reported as status associated with the IRP for an isochronous transfer, but the isochronous pipe is not halted in an error case. If an error is detected, the host continues to process the data associated with the next (micro)frame of the transfer. Only limited error detection is possible because the protocol for isochronous transactions does not allow per-transaction handshakes.	Isochronous endpoints always transmit data packets starting with sequence number zero in each service interval. Each successive data packet transmitted in the same service interval is sent with the next higher sequence number. The sequence number shall roll over from thirty one to zero when transmitting the thirty second packet. Isochronous endpoints do not support retries and cannot respond with flow control responses.The first data packet sent in any service interval always uses sequence number zero. The host shall be able to accept and send up to 48 data packets (DP) per service interval. The first DP in each service interval shall start with the sequence number set to 0.	Isochronous endpoints always transmit data packets starting with sequence number zero in each service interval. Each successive data packet transmitted in the same service interval is sent with the next higher sequence number. The sequence number shall roll over from thirty one to zero when transmitting the thirty second packet. Isochronous endpoints do not support retries and cannot respond with flow control responses. * The host shall be able to accept and send up to 48 DPs per service interval for devices operating at Gen 1 speed and up to 96 DPs for devices operating at Gen 2 speed.
	Bulk Transaction	Bulk Transaction	Bulk Transaction
Bulk Transaction	* Access to the USB on a bandwidth-available basis * Retry of transfers, in the case of occasional delivery failure due to errors on the bus * Guaranteed delivery of data but no guarantee of bandwidth or latency	* Access to the SuperSpeed bus on a bandwidth available basis * Guaranteed delivery of data, but no guarantee of bandwidth or latency SuperSpeed retains the following characteristics of bulk pipes: * No data content structure is imposed on the communication flow for bulk pipes. * A bulk pipe is a stream pipe and, therefore, always has communication flow either into or out of the host for any pipe instance. If an application requires a bi-directional bulk communication flow, two bulk pipes must be used (one IN and one OUT).	* Access to the Enhanced SuperSpeed bus on a bandwidth available basis * Guaranteed delivery of data, but no guarantee of bandwidth or latency The Enhanced SuperSpeed bus retains the following characteristics of bulk pipes: * No data content structure is imposed on the communication flow for bulk pipes. * A bulk pipe is a stream pipe and, therefore, always has communication flow either into or out of the host for any pipe instance. If an application requires a bi-directional bulk communication flow, two bulk pipes must be used (one IN and one OUT).
Bulk Transaction data format	The USB imposes no data content structure on communication flows for bulk pipes.	No change	No change
Bulk Transaction direction	A bulk pipe is a stream pipe and, therefore, always has communication flowing either into or out of the host for a given pipe. If a device requires bi-directional bulk communication flow, two bulk pipes must be used, one in each direction.	No change	No change
Bulk Transaction packet size constraints	An endpoint for bulk transfers specifies the maximum data payload size that the endpoint can accept from or transmit to the bus. The USB defines the allowable maximum bulk data payload sizes to be only 8, 16, 32, or 64 bytes for full-speed endpoints and 512 bytes for high-speed endpoints. A low-speed device must not have bulk endpoints. This maximum applies to the data payloads of the data packets; i.e., the size specified is for the data field of the packet as defined in Chapter 8(usb 2.0), not including other protocol-required information.	An endpoint for bulk transfers shall set the maximum data packet payload size in its endpoint descriptor to 1024 bytes. It also specifies the burst size that the endpoint can accept from or transmit on the SuperSpeed bus. The allowable burst size for a bulk endpoint shall be in the range of 1 to 16. All SuperSpeed bulk endpoints shall support sequence values in the range [0-31].	No change
Bulk Transaction Bus Access constraints	Only full-speed and high-speed devices can use bulk transfers. The bus frequency and (micro)frame timing limit the maximum number of successful bulk transactions within a (micro)frame for any USB system to less than 72 full-speed eight-byte data payloads or less than 14 high-speed 512-byte data payloads.
Bulk Transaction data sequence	Bulk transactions use data toggle bits that are toggled only upon successful transaction completion to preserve synchronization between transmitter and receiver when transactions are retried due to errors. Bulk transactions are initialized to DATA0 when the endpoint is configured by an appropriate control transfer. The host will also start the first bulk transaction with DATA0. If a halt condition is detected on a bulk pipe due to transmission errors or a STALL handshake being returned from the endpoint, all pending IRPs are retired. Removal of the halt condition is achieved via software intervention through a separate control pipe. This recovery will reset the data toggle bit to DATA0 for the endpoint on both the host and the device. Bulk transactions are retried due to errors detected on the bus that affect a given transaction.	No change	No change
ACK	ACK indicates that the data packet was received without errors and informs the host that it may send the next packet in the sequence.	ACK TP : Host handshake	ACK TP : Host Handshake
NAK/NRDY	NAK indicates that the data was received without error but that the host should resend the data because the function was in a temporary condition preventing it from accepting the data (e.g., buffer full).	No	No
STALL	If the endpoint was halted, STALL is returned to indicate that the host should not retry the transmission because there is an error condition on the function.	No	No

HOW TO BOOK YUREKA ON AMAZON IN ONLINE MODE

Helloooooooo

Now a days getting a Yu Yureka in shopes is very difficult and it is available in online only. But few people are doing a bussines on it.....

Those who are already know about how to book  yu yureka please ignore it this post is for those who don't know regarding booking in online.

Fresh registration open now. To register yureka sale log into the https://amazon.in/gp/join-and-earn?encoding=UTF8&ref=mrp_refl_cp_clbd_ind_snp_lnd&refcust=Z5QMMK4QL64MRV7RP5C2KGLUE4

and subscribe for the yu yureka mobile


How To Buy A Yureka ?

Step1:::
Log into your Amazon.in account a few minutes prior to the sale every Thursday at 2:00 P.M.

Step2:::
Open Amazon.in/YU in your Browser.

Step3:::
Add Yureka to your cart when the sale starts and checkout the product within 15 minutes.

Step4:::
In case of sell out, you might be asked to join the waitlist.

Step5:::
If the original buyer fails to complete the order within 15 mins, the phone will become available to the customer in waitlist.

Step6:::
If waitlisted, an alert will be pop-up notifying a when yureka is available.

Step7:::
You will have 3 minutes to add to cart and 15 minutes to checkout

Thank you