markdowned-datasheets/USB_PD_R3.2/07-pd-communications-protocol-message-usage.md

<!-- page 194 -->
# Chapter 7. PD Communications Protocol Message Usage

## 7.1. Reset

Resets are a necessary response to protocol or other error conditions. USB Power Delivery defines four different
types of reset:

- Soft Reset, which resets protocol.
- Data Reset, which resets the USB communications.
- Hard Reset, which resets both the power supplies and protocol.
- Cable Reset which resets the cable.

### 7.1.1. Soft Reset and Protocol Error

A Soft_Reset Message is used to cause a Soft Reset of the communication protocol when it has broken down in
some way. The breakdown in communication or the Protocol Error may take several forms:

- An Unexpected Message is received during an AMS.
- An expected Message fails to arrive.
- A timeout occurs while waiting for a Message or event.

The Soft Reset **Shall Not** have any impact on power supply operation but is used to correct a Protocol Error occurring
during an Atomic Message Sequence (AMS). After a Soft Reset has completed, an Explicit Contract Negotiation
occurs, in order to re-establish PD Communication and to bring State operation for both Port Partners back to either
the PE_SNK_Ready or PE_SRC_Ready states as appropriate (see Section 9.2.5). The Soft Reset **May** be triggered
by either Port Partner in response to the Protocol Error. An Accept Message is sent by the recipient of a Soft Reset
Message to indicate that it has completed the Soft Reset.

The Protocol Error may result in:

- a Hard Reset.
- a Soft Reset.
- or no response.

An Unrecognized Message or Unsupported Message received in a Protocol Engine ready State causes a Not_Supported Message to be generated.

If the error is not corrected by the Soft Reset, Hard Reset Signaling **Shall** be issued (see Section 7.1.3).

A Soft Reset may be sent by either the Source or Sink in response to a Protocol Error irrespective of the value of Rp,
either SinkTxOK or SinkTxNG. If the Soft_Reset Message fails a Hard Reset **Shall** be initiated within tHardReset
of the last CRCReceiveTimer expiring after nRetryCount retries have been completed.

A Soft_Reset Message **Shall** be targeted at a specific entity depending on the type of SOP* Packet used. Soft_Reset
Messages sent using SOP Packets **Shall** Soft Reset the Port Partner only. Soft_Reset Messages sent using SOP'
Packet/ SOP'' Packets **Shall** Soft Reset the corresponding Cable Plug only.

After a VCONN Swap the VCONN Source needs to reset the Cable Plug's Protocol Layer to ensure MessageID
synchronization. If after a VCONN Swap the VCONN Source wants to communicate with a Cable Plug using SOP'

<!-- page 195 -->
Packets, it **Shall** issue a Soft_Reset Message using a SOP' Packet in order to reset the Cable Plug's Protocol Layer.
If the VCONN Source wants to communicate with a Cable Plug using SOP'' Packets, it **Shall** issue a Soft_Reset
Message using a SOP'' Packet in order to reset the Cable Plug's Protocol Layer.

See Section 9.2, "Policy Engine Layer State Diagrams" for more details.

Table 7.1 and Table 7.2 summarize the responses that **Shall** be made to an incoming Message including VDMs.

**Table 7.1. Response to an incoming Message (except VDM)**

| Recipient's Power Role | Recipient's State | Recognized / Supported / Expected | Recognized / Supported / Unexpected | Recognized / Unsupported | Unrecognized |
|---|---|---|---|---|---|
| Source | PE_SRC_Ready | Process Message | Soft_Reset Message[^1] | Not_Supported Message[^2] | Not_Supported Message[^2] (except for VDM)<br>See Section 8.4 for UVDM.<br>See Section 8.5 for SVDM |
| Source | During AMS (power not transitioning[^3]) | Process Message | Soft_Reset Message[^1] | Soft_Reset Message[^1] | Soft_Reset Message[^1] |
| Source | During AMS (power transitioning[^3]) | Process Message | Hard Reset Signaling | Hard Reset Signaling | Hard Reset Signaling |
| Sink | PE_SNK_Ready | Process Message | Soft_Reset Message[^1] | Not_Supported Message[^2] | Not_Supported Message[^2] (except for VDM)<br>See Section 8.4 for UVDM.<br>See Section 8.5 for SVDM |
| Sink | During AMS (not power transitioned) | Process Message | Soft_Reset Message[^1] | Soft_Reset Message[^1] | Soft_Reset Message[^1] |
| Sink | During AMS (power transitioned) | Process Message | Hard Reset Signaling | Hard Reset Signaling | Hard Reset Signaling |

[^1]: The Soft_Reset Message **Shall** be sent using the SOP* of the incoming Message.
[^2]: The Not_Supported Message **Shall** be sent using the SOP* of the incoming Message.
[^3]: "Power transitioning" means the Policy Engine is in PE_SRC_Transition_Supply State or PE_SNK_Transition_Sink State or PE_FRS_SNK_SRC_Start_AMS State.

**Table 7.2. Response to an incoming VDM**

| Recipient's Role | Unstructured VDM: Supported | Unstructured VDM: Unsupported | Unstructured VDM: Unrecognized | Structured VDM: Supported | Structured VDM: Unsupported | Structured VDM: Unrecognized |
|---|---|---|---|---|---|---|
| DFP or UFP | Defined by vendor | Not_Supported Message | Not_Supported Message | See: Table 7.4 | Not_Supported Message | NAK Command |
| Cable Plug | Defined by vendor | Message **Ignored** | Message **Ignored** | See: Table 7.5 | Message **Ignored** | NAK Command |

A failure to see a GoodCRC Message in response to any Message within tReceive (after nRetryCount retries), when
a Port Pair is Connected, is indicative of a communications failure resulting in a Soft Reset (see Section 7.1.1).

A Soft Reset **Shall** impact the USB Power Delivery layers in the following ways:

- PHY Layer: Reset not required since the PHY Layer resets on each Packet transmission/reception.
- Protocol Layer: Reset MessageIDCounter, RetryCounter and State machines.
- Policy Engine: Reset State dependent behavior by performing an Explicit Contract Negotiation.

<!-- page 196 -->
- Power supply: Does not change.

Note: When in SPR Mode the Source sends a Source_Capabilities Message and when in EPR Mode the Source
sends an EPR_Source_Capabilities Message.

A Soft Reset is performed using an AMS (see Section 7.7).

### 7.1.2. Data Reset

The Data_Reset Message **May** be sent by either the DFP or UFP and **Shall** reset the USB data connection and
exit all Alternate Modes with its Port Partner while preserving the power on VBUS. USB4 Mode capable ports **Shall**
support the Data_Reset Message and other ports **May** support the Data_Reset Message.

The Data_Reset Message **Shall Not** change the existing:

- Power Contract
- Data Roles (i.e., which Port is the DFP or UFP)

The receiver of the Data_Reset Message **Shall** respond by sending an Accept Message and then follow the process
outlined in the following steps. Neither the sender nor receiver **Shall** initiate a VCONN Swap until the Data Reset
process is complete, and the Data_Reset_Complete Message has been sent. Following receipt of the Accept Message, or GoodCRC Message following the Accept Message, depending which Port sends the Data_Reset Message:

1. The DFP **Shall**:
   - Disconnect the Port's [USB2] D+/D- signals.
   - If operating in [USB3] remove the Port's Rx Terminations (see [USB3]).
   - If operating in [USB4] drive the Port's SBTX to a logic low (see [USB4]).
2. Both the DFP and UFP **Shall** exit all Alternate Modes if any.
3. Reset the cable:
   - If the VCONN Source Port is also the UFP, then it **Shall** run the UFP VCONN Power Cycle process
     described in Section 4.6.
   - If the VCONN Source Port is also the DFP, then it **Shall** run the DFP VCONN Power Cycle process
     described in Section 4.6.
   - The DFP **Shall** exit the VCONN Power Cycle process as the VCONN Source and be sourcing VCONN.
4. After tDataReset the DFP **Shall**:
   - Reconnect the [USB2] D+/D- signals.
   - If the Port was operating in [USB3] or [USB4] reapply the Port's Rx Terminations (see [USB3]).
5. The Data Reset process is complete; the DFP **Shall** send a Data_Reset_Complete Message and enter the
   USB4 Discovery and Entry Flow (See [USB-C]).

If the Initiator of the Data_Reset Message does not receive a **Valid** response within tSenderResponse it **Shall** enter
the ErrorRecovery State.

### 7.1.3. Hard Reset

Hard Resets are signaled by an ordered set as defined in Table 5.4. Both the sender and recipient **Shall** cause their
power supplies to return to their default states (see Figure 4.14 for details of voltage transitions). In addition, their
respective Protocol Layers **Shall** be reset as for the Soft Reset. This allows the Attached devices to be in a State

<!-- page 197 -->
where they can re-establish USB PD communication. Hard Reset is retried up to nHardResetCount times (see also
Section 7.31.5.4 and Section 7.32.5).

Note: Even though VBUS drops to vSafe0V during a Hard Reset a Sink will not see this as a disconnect since this
is expected behavior.

A Hard Reset **Shall Not** cause any change to either the Rp/Rd resistor being asserted.

If there has been a Data Role Swap the Hard Reset **Shall** cause the Port Data Role to be changed back to DFP for
a Port with the Rp resistor asserted and UFP for a Port with the Rd resistor asserted.

When VCONN is supported (see [USB-C]) the Hard Reset **Shall** cause the Port with the Rp resistor asserted to
supply VCONN and the Port with the Rd resistor asserted to turn off VCONN.

If the Hard Reset is insufficient to clear the error condition, then the Port **Shall** use USB Type-C ErrorRecovery as
defined in [USB-C].

A Sink **Shall** be able to send Hard Reset Signaling regardless of the value of Rp (see Section 5.2.2").

#### 7.1.3.1. Cable Plugs and Hard Reset

Cable Plugs **Shall Not** generate Hard Reset Signaling but **Shall** monitor for Hard Reset Signaling between the
Port Partners and **Shall** reset when this is detected (see Section 9.2.26.2.2). The Cable Plugs **Shall** perform the
equivalent of a power cycle returning to their initial power up State. This allows the Port Partners to be in a State
where they can re-establish USB PD communication.

#### 7.1.3.2. Modal Operation and Hard Reset

A Hard Reset **Shall** cause EPR Mode and all Active Modes to be exited by both Port Partners and any Cable Plugs
(see Section 8.6.4").

### 7.1.4. Cable Reset

Cable Resets are signaled by an ordered set as defined in Table 5.4. Both the sender and recipient of Cable Reset
Signaling **Shall** reset their respective Protocol Layers. The Cable Plugs **Shall** perform the equivalent of a power
cycle returning to their initial power up State. This allows the Port Partners to be in a State where they can reestablish USB PD communication.

Only a DFP **Shall** generate Cable Reset Signaling. The DFP must be supplying VCONN prior to a Cable Reset.
If VCONN has been turned off the DFP **Shall** turn on VCONN prior to generating Cable Reset Signaling. If there
has been a VCONN Swap and the UFP is currently supplying VCONN, the DFP **Shall** perform a VCONN Swap
such that it is supplying VCONN prior to generating Cable Reset Signaling. A DFP **Shall** only generate Cable Reset
Signaling within an Explicit Contract.

A Cable Reset **Shall** cause all Active Modes in the Cable Plugs to be exited (see Section 8.6.4").

## 7.2. Collision Avoidance

To avoid Message collisions due to asynchronous Messaging sent from the Sink, the Source sets Rp to SinkTxOK
to indicate to the Sink that it is OK to initiate an AMS. When the Source wishes to initiate an AMS, it sets Rp to
SinkTxNG. When the Sink detects that Rp is set to SinkTxOK it **May** initiate an AMS. When the Sink detects that
Rp is set to SinkTxNG it **Shall Not** initiate an AMS once tSinkDelay has elapsed after SinkTxNG is asserted, and
**Shall** only send Messages that are part of a Source-initiated AMS.

Note: This restriction applies to SOP* AMSs i.e., for both Port to Port and Port to Cable Plug communications.

Note: A Sink can still send Hard Reset Signaling at any time.
<!-- page 198 -->

## 7.3. Message Discarding

On receiving a received Message on SOP, the Protocol Layer **Shall Discard** any pending SOP* Messages. A received Message on SOP'/SOP'' **Shall Not** cause any pending SOP* Messages to be **Discarded**.

It is assumed that Messages using SOP'/SOP'' constitute a simple Request/response AMS, with the Cable Plug providing the response so there is no reason for a pending SOP* Message to be **Discarded**. There can only be one AMS between the Port Partners, and these also take priority over Cable Plug communications so a Message received on SOP will always cause a Message pending on SOP* to be **Discarded**.

Table 7.3 for details of the Messages that **Shall**/ **Shall Not** be **Discarded**.

**Table 7.3. Message Discarding**

| Message pending transmission | Message received | Message to be Discarded |
| --- | --- | --- |
| SOP | SOP | Outgoing Message |
| SOP | SOP'/SOP'' | Incoming Message |
| SOP' | SOP | Outgoing Message |
| SOP' | SOP' | Incoming Message |
| SOP' | SOP'' | Incoming Message |
| SOP'' | SOP | Outgoing Message |
| SOP'' | SOP' | Incoming Message |
| SOP'' | SOP'' | Incoming Message |

## 7.4. Common Messages

### 7.4.1. Accept

Usage details for the Accept Message are given in each of the different AMS sequences where it is used.

### 7.4.2. Reject

Most usage details for the Reject Message are given in each of the different AMS sequences where it is used.

The sender of a Request, EPR_Request Message, PR_Swap Message, DR_Swap Message, VCONN_Swap, or Enter_USB Message, on receiving a Reject Message response, **Shall Not** send this same Message to the recipient until one of the following has occurred:

- A New Explicit Contract Negotiation as a result of the Source sending a Source_Capabilities Message or EPR_Source_Capabilities Message. This can be triggered by:
    - The Source's Device Policy Manager.
    - A Get_Source_Cap Message sent from the Sink to the Source in SPR Mode.
    - An EPR_Get_Source_Cap Message sent from the Sink to the Source in EPR Mode.
    - A Power Role Swap.
    - A Soft Reset.
    - A Hard Reset.
    - A Disconnect/Re-Connect.
- A Data Role Swap.

<!-- page 199 -->

- A Data Reset.

### 7.4.3. Wait

Usage details for the Wait Message are given in each of the different AMS sequences where it is used.

## 7.5. Applicability Tables

Table 7.4 and Table 7.5 lists the AMS and Message requirements for a Port/Cable Plug.

The "Initiator Applicability" column refers to a Port's requirement to be able to start an AMS, while the "Responder Applicability" column refers to a Port's requirement to respond to an AMS. The "Transmitter" column specifies the transmitter of that specific Message in the sequence. The Initiator of an AMS is the transmitter of the first Message in that sequence. Ports **May** initiate or respond to any AMS not explicitly forbidden.

When multiple messages are allowed in an AMS (e.g. Accept/Reject/Wait), transmitters **May** choose to not implement all of the options. Receivers **Shall** be able to understand any of the Message options.

See Chapter 9 for detailed State diagrams explaining the AMS and messaging options.

**Table 7.4. Port Sequence Applicability**

| AMS | Initiator Applicability | Responder Applicability | General Message Sequence | Transmitter |
| --- | --- | --- | --- | --- |
| Source Capabilities | **Required** for ports that can operate as Source | **Required** | `Source_Capabilities` | Source |
| | | | `Request` | Sink |
| | | | Accept/Reject/Wait | Source |
| | | | `PS_RDY` | Source |
| Request | **Required** for ports that can operate as Sink | **Required** | `Request` | Sink |
| | | | Accept/Reject/Wait | Source |
| | | | `PS_RDY` | Source |
| EPR Source Capabilities | **Required** for ports that can operate as EPR Source | **Required** for EPR Capable ports | `EPR_Source_Capabilities` | Source |
| | | | `EPR_Request` | Sink |
| | | | Accept/Reject/Wait | Source |
| | | | `PS_RDY` | Source |
| EPR Request | **Required** for ports that can operate as EPR Sink | **Required** for EPR Capable ports | `EPR_Request` | Sink |
| | | | Accept/Reject/Wait | Source |
| | | | `PS_RDY` | Source |
| EPR Mode Enter | **Required** for ports that can operate as EPR Sink | **Required** for EPR Capable ports | `EPR_Mode` (Enter) | Sink |
| | | | `EPR_Mode` (Enter Acknowledge) | Source |
| | | | VCONN Swap Sequence | - |
| | | | Cable Plug Discover Identity (SVDM) Sequence | - |
| | | | `EPR_Mode` (Enter Succeeded/Enter Failed) | Source |
| | | | EPR Source Capabilties Sequence | - |
| EPR Keep Alive | **Required** for ports that can operate as EPR Sink | **Required** for EPR Capable ports | `EPR_Keep_Alive` | Sink |
| | | | `EPR_Keep_Alive_Ack` | Source |
| EPR Mode Exit | Recommended for EPR Capable ports | **Required** for EPR Capable ports | `EPR_Mode` (Exit) | Any |
| | | | Source Capabilities Sequence | - |
| Unsupported Sequence | | **Required** | Initiating Message | Any |
| | | | `Not_Supported` | Any |

<!-- page 200 -->

| AMS | Initiator Applicability | Responder Applicability | General Message Sequence | Transmitter |
| --- | --- | --- | --- | --- |
| Soft Reset | **Required** | **Required** | `Soft_Reset` | Any |
| | | | Accept | Responder |
| | | | Source Capabilities/EPR Source Capabilities Sequence | - |
| Data Reset | **Required** for USB4 capable ports | **Required** for USB4 capable ports | `Data_Reset` | Any |
| | | | Accept | Responder |
| | | | `PS_RDY` | UFP VCONN Source |
| | | | `Data_Reset_Complete` | DFP |
| Power Role Swap | **Required** for DRP<br><br>Unsupported by Source only/Sink only | **Required** for DRP | `PR_Swap` | Any |
| | | | Accept/Reject/Wait | Responder |
| | | | `PS_RDY` | Initial Source |
| | | | `PS_RDY` | New Source |
| Fast Role Swap | Recommended for DRP<br><br>Unsupported by Source only/Sink only | Optional for DRP | `FR_Swap` | Sink |
| | | | Accept | Source |
| | | | `PS_RDY` | Initial Source |
| | | | `PS_RDY` | New Source |
| Data Role Swap | **Required** for DRD | **Required** for DRD | `DR_Swap` | Any |
| | | | Accept/Reject/Wait | Responder |
| VCONN_Swap | Recommended | **Required** for ports that can supply VCONN | `VCONN_Swap` | Any |
| | | | Accept/Reject/Wait | Responder |
| | | | `PS_RDY` | New VCONN Source |
| Alert | **Required** for ports that support SPR PPS Mode | Recommended | Alert | Any |
| | | | Optional Get Status Sequence | - |
| | | | Optional Get Battery Status Sequence | - |
| Get Status | Recommended | **Required** for Source ports that support Alert | `Get_Status` | Any |
| | | | Status | Responder |
| Get PPS Status | **Required** for ports that support SPR PPS Mode | **Required** for ports that support SPR PPS Mode | `Get_PPS_Status` | PPS Sink |
| | | | `PPS_Status` | PPS Source |
| Get Source Capabilities | Recommended for ports that can operate as Sink | **Required** for ports that can operate as Source | `Get_Source_Cap` | Any |
| | | | `Source_Capabilities` | Responder |
| | | | If in SPR Mode and AMS was initiated by the Sink: Request Sequence | - |
| Get Sink Capabilities | Recommended for ports that can operate as Source | **Required** for ports that can operate as Sink | `Get_Sink_Cap` | Any |
| | | | `Sink_Capabilities` | Responder |
| EPR Get Source Capabilities | Recommended for ports that can operate as EPR Sink | **Required** for ports that can operate as EPR Source | `EPR_Get_Source_Cap` | Any |
| | | | `EPR_Source_Capabilities`/Reject | Responder |
| | | | If in EPR Mode and AMS was initiated by the Sink: EPR Request Sequence | - |
| EPR Get Sink Capabilities | Recommended for ports that can operate as EPR Source | **Required** for ports that can operate as EPR Sink | `EPR_Get_Sink_Cap` | Any |
| | | | `EPR_Sink_Capabilities`/Reject | Responder |

<!-- page 201 -->

| AMS | Initiator Applicability | Responder Applicability | General Message Sequence | Transmitter |
| --- | --- | --- | --- | --- |
| Get Source Capabilities Extended | Recommended for ports that can operate as Sink | Recommended for ports that can operate as Source | `Get_Source_Cap_Extended` | Any |
| | | | `Source_Capabilities_Extended` | Responder |
| Get Sink Capabilities Extended | Recommended for ports that can operate as Source | **Required** for ports that can operate as Sink | `Get_Sink_Cap_Extended` | Any |
| | | | `Sink_Capabilities_Extended` | Responder |
| Get Battery Capabilities | Recommended | **Required** if product contains batteries | `Get_Battery_Cap` | Any |
| | | | `Battery_Capabilities` | Responder |
| Get Battery Status | Recommended | **Required** if product contains batteries | `Get_Battery_Status` | Any |
| | | | `Battery_Status` | Responder |
| Get Manufacturer Info | Recommended | Recommended | `Get_Manufacturer_Info` | Any |
| | | | `Manufacturer_Info` | Responder |
| Get Country Codes | **Required** if mandated by a country authority | **Required** if mandated by a country authority | `Get_Country_Codes` | Any |
| | | | `Country_Codes` | Responder |
| Get Country Info | **Required** if mandated by a country authority | **Required** if mandated by a country authority | `Get_Country_Info` | Any |
| | | | `Country_Info` | Responder |
| Get Revision | Recommended | **Required** | `Get_Revision` | Any |
| | | | Revision | Responder |
| Get Source Information | Recommended for ports that can operate as Sink | **Required** for ports that can operate as Source (except single Port SPR Chargers with Invariant PDOs) | `Get_Source_Info` | Any |
| | | | `Source_Info` | Responder |
| Security Request | **Required** by ports that support USB security communication as defined in [USBC Auth]. | **Required** by ports that support USB security communication as defined in [USBC Auth]. | `Security_Request` | Any |
| | | | `Security_Response` | Responder |
| Firmware Update Request | **Required** by ports that support USB firmware update communication as defined in [USB DFU]. | **Required** by ports that support USB firmware update communication as defined in [USB DFU]. | `Firmware_Update_Request` | Any |
| | | | `Firmware_Update_Response` | Responder |
| Discover Identity (SVDM) | Recommended for ports that can operate as Source | **Required** for USB4 capable ports, products with more than one DFP, or ports that support Modal Operation | Discover Identity Vendor_Defined INIT | Any |
| | | | Discover Identity Vendor_Defined ACK/NAK/BUSY | Responder |
| Discover SVIDs (SVDM) | **Required** for ports that support Modal Operation | **Required** for ports that support Modal Operation | Discover SVIDs Vendor_Defined INIT | Any |
| | | | Discover SVIDs Vendor_Defined ACK/NAK/BUSY | Responder |
| Discover Modes (SVDM) | **Required** for ports that support Modal Operation | **Required** for ports that support Modal Operation | Discover Modes Vendor_Defined INIT | Any |
| | | | Discover Modes Vendor_Defined ACK/NAK/BUSY | Responder |
| Enter Mode (SVDM) | **Required** for ports that support Modal Operation | **Required** for ports that support Modal Operation | Enter Mode Vendor_Defined INIT | DFP |
| | | | Enter Mode Vendor_Defined ACK/NAK/BUSY | UFP |
| Exit Mode (SVDM) | **Required** for ports that support Modal Operation | **Required** for ports that support Modal Operation | Exit Mode Vendor_Defined INIT | DFP |
| | | | Exit Mode Vendor_Defined ACK/NAK/BUSY | UFP |
| Structured VDM (Other) | Optional | Optional | Vendor_Defined INIT | Any |
| | | | Vendor_Defined ACK/NAK/BUSY | Responder |
<!-- page 202 -->

| AMS | Initiator Applicability | Responder Applicability | General Message Sequence | Transmitter |
| --- | --- | --- | --- | --- |
| Enter USB | **Required** for USB4 capable ports | **Required** for USB4 capable ports | `Enter_USB` | DFP |
| | | | Accept/Reject/Wait | UFP |

Table 7.5 applies to all Cable Plugs and to any Ports that are otherwise required to communicate with the Cable Plug. Only Ports acting as a VCONN Source are allowed to initiate AMSs listed in this table. The Port is always the Initiator of amy AMS to the Cable Plug. For a port that is not currently the VCONN Source to communicate with the Cable Plug, initiate the VCONN Swap AMS to become the VCONN Source.

Cable Plugs **May** respond to any AMS not explicitly forbidden.

**Table 7.5. Cable Plug Sequence Applicability**

| AMS | Port Initiator Applicability | SOP' Responder Applicability | SOP'' Responder Applicability | Message Sequence | Transmitter |
| --- | --- | --- | --- | --- | --- |
| Unsupported Sequence | | **Required** | **Required** | Initiating Message | Port (VCONN Source) |
| | | | | `Not_Supported` | Cable |
| Soft Reset | **Required** | **Required** | **Required** | `Soft_Reset` | Port (VCONN Source) |
| | | | | Accept | Cable |
| Get Status | Optional | **Required** for Active Cables | **Required** for Active Cables | `Get_Status` | Port (VCONN Source) |
| | | | | Status | Cable |
| Get Manufacturer Info | Optional | Recommended | Not Allowed | `Get_Manufacturer_Info` | Port (VCONN Source) |
| | | | | `Manufacturer_Info` | Cable |
| Get Revision | Optional | **Required** for Active Cables | Not Allowed | `Get_Revision` | Port (VCONN Source) |
| | | | | Revision | Cable |
| Security Request | **Required** by ports that support USB security communication as defined in [USBC Auth]. | **Required** by cables that support USB security communication as defined in [USBC Auth]. | Not Allowed | `Security_Request` | Port (VCONN Source) |
| | | | | `Security_Response` | Cable |
| Firmware Update Request | **Required** by ports that support USB firmware update communication as defined in [USB DFU]. | **Required** by cables that support USB firmware update communication as defined in [USB DFU]. | Optional | `Firmware_Update_Request` | Port (VCONN Source) |
| | | | | `Firmware_Update_Response` | Cable |
| Discover Identity (SVDM) | **Required** for ports that can operate as Source and offer >3A.<br>**Required** for ports that support Modal Operation.<br>**Required** for USB4 capable ports.<br>Recommended for all ports. | **Required** | Not Allowed | Discover Identity Vendor_Defined INIT | Port (VCONN Source) |
| | | | | Discover Identity Vendor_Defined ACK/NAK/BUSY | Cable |

<!-- page 203 -->

| AMS | Port Initiator Applicability | SOP' Responder Applicability | SOP'' Responder Applicability | Message Sequence | Transmitter |
| --- | --- | --- | --- | --- | --- |
| Discover SVIDs (SVDM) | **Required** for ports that support Modal Operation. | **Required**, responds NAK if Modal Operation is not supported | Not Allowed | Discover SVIDs Vendor_Defined INIT | Port (VCONN Source) |
| | | | | Discover SVIDs Vendor_Defined ACK/NAK/BUSY | Cable |
| Discover Modes (SVDM) | **Required** for ports that support Modal Operation. | **Required**, responds NAK if Modal Operation is not supported | Not Allowed | Discover Modes Vendor_Defined INIT | Port (VCONN Source) |
| | | | | Discover Modes Vendor_Defined ACK/NAK/BUSY | Cable |
| Enter Mode (SVDM) | **Required** for ports that support Modal Operation. | **Required**, responds NAK if Modal Operation is not supported | Optional | Enter Mode Vendor_Defined INIT | Port (VCONN Source) |
| | | | | Enter Mode Vendor_Defined ACK/NAK/BUSY | Cable |
| Exit Mode (SVDM) | **Required** for ports that support Modal Operation. | **Required**, responds NAK if Modal Operation is not supported | Optional | Exit Mode Vendor_Defined INIT | Port (VCONN Source) |
| | | | | Exit Mode Vendor_Defined ACK/NAK/BUSY | Cable |
| Structured VDM (Other) | Optional | Optional | Optional | Vendor_Defined INIT | Port (VCONN Source) |
| | | | | Vendor_Defined ACK/NAK/BUSY | Cable |
| Enter USB | **Required** for USB4 capable ports. | **Required** for Active Cables that support USB4 | **Required** for Active Cables that support USB4 | `Enter_USB` | Port (VCONN Source) |
| | | | | Accept/Reject/Wait | Cable |

Table 7.6 and Table 7.7 cover messages that may not be a part of an AMS, but still have applicability for given ports/cable plugs.

**Table 7.6. Port Message Applicability**

| Message | Transmit Applicability | Receive Applicability |
| --- | --- | --- |
| `GoodCRC` | **Required** | **Required** |
| Attention (SVDM) | Optional | Optional |
| Vendor_Defined (Unstructured) | Optional | Optional |
| `Vendor_Defined_Extended` | Optional | Optional |
| BIST | **Required** | **Required** |
| `Hard_Reset` | **Required** | **Required** |

<!-- page 204 -->

**Table 7.7. Cable Plug Message Applicability**

| Message | Transmit Applicability | Receive Applicability |
| --- | --- | --- |
| `GoodCRC` | **Required** | **Required** |
| Attention (SVDM) | Not Allowed | Ignore |
| Vendor_Defined (Unstructured) | Optional | Optional |
| `Vendor_Defined_Extended` | Optional | Optional |
| BIST | Not Allowed | **Required** |
| `Hard_Reset` | Not Allowed | **Required** |
| `Cable_Reset` | Not Allowed | **Required** |

## 7.6. AMS Usages

### 7.6.1. Basic Message Exchange

Figure 7.1 illustrates how a Message is sent. Note: The sender might be either a Source or Sink while the receiver might be either a Sink or Source. The basic Message sequence is the same. It starts when the Message Initiator's Policy Engine forms a Message that it passes to the Protocol Layer. The "Protocol to protocol core" sequence fragment defines where:

- the Message Request arrives at the Initiator Protocol Layer on the left side,
- the Request is delivered to the target Policy Engine on the right side, and
- the Message-sent event is delivered to the Initiator Protocol Layer on the left side.

This fragment is used in subsequent diagrams when the Message flow through the protocol and physical layers are identical.

**Figure 7.1. Sequence diagram of messaging core between protocol layers**

![Figure 7.1. Sequence diagram of messaging core between protocol layers](07-pd-communications-protocol-message-usage/figure-7.1.png)

<!-- page 205 -->

### 7.6.2. Possible Points of Failure for Message Delivery

There are various points during the Message flow where failures in communication or other issues can occur. Figure 7.2 below is an annotated Version of Figure 7.1 indicating at which points issues can occur.

**Figure 7.2. Basic Message flow indicating possible errors**

![Figure 7.2. Basic Message flow indicating possible errors](07-pd-communications-protocol-message-usage/figure-7.2.png)

<!-- page 206 -->

**Table 7.8. Potential Issues in the Basic Message Flow**

| Point | Possible Issues |
| --- | --- |
| A | 1. There is an incoming Message on the channel, meaning that the PHY Layer is unable to send. In this case the outgoing Message is removed from the queue and the incoming Message processed.<br>2. Due to some sort of noise on the line it is not possible to transmit. In this case the outgoing Message is **Discarded** by the PHY Layer. Retransmission is via the Protocol Layer's normal mechanism. |
| B | 1. Message does not arrive at the PHY Layer due to noise on the channel.<br>2. Message arrives but has been corrupted and has a bad CRC.<br>There is no Message to pass up to the Protocol Layer on the receiver which means a GoodCRC Message is not sent. This leads to a `CRCReceiveTimer` timeout in the Message Sender. |
| C | Same as Point A, but at the Message Receiver side. |
| D | 1. GoodCRC Message response does not arrive at the Message Sender side due to the noise on the channel.<br>2. GoodCRC Message response arrives but has a bad CRC.<br>A GoodCRC Message is not received by the Message Sender's Protocol Layer. This leads to a CRCReceiveTimertimeout in the Message Sender. |
| E | MessageID of received Message matches stored MessageID so this is a retry. Message is not passed up to the Policy Engine. |
| F | 1. GoodCRC Message is received but does contain the same MessageID as the transmitted Message.<br>2. A Message is received but it is not a GoodCRC Message (similar case to that of an unexpected or unknown Message but this time detected in the Protocol Layer).<br>Both of these issues indicate errors in receiving an expected GoodCRC Message which will lead to a `CRCReceiveTimer` timeout in the Protocol Layer and a subsequent retry (except for communications with Cable Plugs). |
| G | 1. Policy Engine receives a known Message that it was not expecting.<br>2. Policy Engine receives an Unrecognized Message.<br>These cases are errors in the protocol which could lead to the generation of a `Soft_Reset` Message. |

## 7.7. Soft Reset AMS

Message numbers **Shall** be set to zero prior to sending the `Soft_Reset`/Accept Message since the issue might be with the counters. The sender of a `Soft_Reset` Message **Shall** reset its `MessageIDCounter` and `RetryCounter` to 0. The receiver of the Message **Shall** reset its `MessageIDCounter` and `RetryCounter` to 0 before sending the Accept Message response. A Port Partner observing a Protocol Error during an SOP Soft Reset **Shall** initiate a Hard Reset; a DFP observing a Protocol Error during an SOP'/SOP'' Soft Reset **Shall** initiate a Cable Reset (see Section 7.1.3 and Section 7.1.4).

## 7.8. Data Reset AMS

In a Data Reset AMS, the Initiator sends a `Data_Reset` Message. The Responder will respond with an Accept Message. Both Port partners will then follow the process given in Section 7.1.2, "Data Reset". When the Data Reset process is complete, the DFP will complete the AMS by sending a `Data_Reset_Complete` Message to the UFP regardless of the role of the Initiator.

<!-- page 207 -->

## 7.9. Power Negotiation (SPR) AMS

### 7.9.1. Source_Capabililties Message

#### 7.9.1.1. Power Data Objects

Section 6.4.1.1 and Section 6.4.1.3 describe the Power Data Objects (PDOs) used in the construction of a Capabilities Message for both SPR Mode and EPR Mode.

Power Data Objects are also used to expose additional Capabilities that **May** be utilized, such as in the case of a Power Role Swap.

A list of one or more Power Data Objects **Shall** be sent by the Source to convey its Capabilities. The Sink **May** then Request one of these Capabilities by returning a Request Data Object that contains an index to a Power Data Object, to Negotiate a mutually agreeable Explicit Contract.

Where Maximum and Minimum voltage and current values are given in PDOs these **Shall** be taken to be absolute values.

The Source and Sink **Shall Not** Negotiate a power level that would allow the current to exceed the maximum current supported by their receptacles or the Attached plug (see [USB-C]). The Source **Shall** limit its offered Capabilities to the maximum current supported by its receptacle and Attached plug. A Sink **Shall** only make a Request from any of the Capabilities offered by the Source. For further details see Section 8.6.1.2.2.

Sources expose their power Capabilities by sending a `Source_Capabilities` Message. Sinks expose their power requirements by sending a `Sink_Capabilities` Message. Both are composed of several 32-bit Power Data Objects (see Section 7.9.1.1).

The Augmented Power Data Object (APDO) is defined to allow support for more than the four PDO types by extending the Power Data Object field from 2 to 4 bits when the `B31…B30` are `11b`. The generic APDO structure is shown in Table 6.7"

#### 7.9.1.2. USB Suspend Supported

Prior to an Explicit Contract or when the USB Communications Capable bit is set to zero, the USB Suspend Supported flag is undefined and Sinks **Shall** follow the rules for suspend as defined in [USB2], [USB 3.2], [USB4], [USBC] or [USB BC]. After an Explicit Contract has been Negotiated:

- A PDUSB Peripheral **May** draw up to `pSnkSusp` during suspend; a PDUSB Hub **May** draw up to `pHubSusp` during suspend (see Section 4.2.3").

Note: When USB is suspended, the USB Device State is also suspended.

Sinks **May** indicate to the Source that they would prefer to have the USB Suspend Supported flag cleared by setting the No USB Suspend flag in a Request Message (see Section 6.4.2.1.8).

#### 7.9.1.3. Unconstrained Power

To set the Unconstrained Power bit because of an external Source, the external Source of power **Should** be either:

- An AC Supply, e.g., a Charger, directly Connected to the Sink.
- Or, in the case of a PDUSB Hub:
  - A PD Source with its Unconstrained Power bit set.

<!-- page 208 -->

- Multiple PD Sources all with their Unconstrained Power bits set.

#### 7.9.1.4. EPR Mode Capable

When this bit is set, an EPR Source:

- Operating in SPR Mode **Shall** only send an `EPR_Source_Capabilities` Message in response to an `EPR_Get_Source_Cap` Message

#### 7.9.1.5. Source Offering No Capabilities

A Source offering no Capabilities (0mA or 0W) **Shall** offer a single Fixed Supply PDO with Voltage set to 5V and Maximum Current set to 0mA. Examples of products that might do this:

- A Dual-Role Power product that offers no Capabilities as a Source or in the absence of external power.
- A Source that wants the Sink to draw no more than `pSnkSusp`.
- A Sink with Accessory Support that does not support VBUS but is sourcing VCONN to an Accessory (see [USB-C]).

### 7.9.2. Request Message

A Request Message **Shall** be sent by a Sink to Request power during the Request phase of an SPR power Negotiation. The Request Data Object **Shall** be returned by the Sink making a Request for power. It **Shall** be sent in response to the most recent `Source_Capabilities` Message when in SPR Mode.

The Request Message includes the requested power level. For example, if the `Source_Capabilities` Message includes a Fixed Supply PDO that offers 9V @ 1.5A and if the Sink only wants 9V @ 0.5A, it will set the Operating Current field to 50 (i.e., 10mA * 50 = 0.5A).

Note: A Source in AVS Mode, unlike the SPR Source in PPS Mode, does not support Current Limit; the Sink is responsible not to take more current than it requested.

The Accept Message **Shall** be sent by the Source, in SPR Mode, to signal the Sink that the Source is willing to meet the Request Message.

The Reject Message **Shall** be sent to signal the Sink, in SPR Mode, that the Source is unable to meet the Request Message. This **May** be due an Invalid Request or because the Source can no longer provide what it previously Advertised.

A Source operating in EPR Mode that receives a Request Message **Shall** initiate a Hard Reset.

The Sink **May** send a different Request Message to the one which was rejected but **Shall Not** repeat the same Request Message, using the same RDO, unless there has been a New Explicit Contract Negotiation, Data Role Swap, or Data Reset.

#### 7.9.2.1. Capability Mismatch

Capabilities Mismatch occurs when the Source cannot satisfy the Sink's power requirements based on the offered Source Capabilities. In this case the Sink **Shall** make a **Valid** Request from the offered Source Capabilities and **Shall** set the Capability Mismatch bit. When a Capabilities Mismatch condition does not exist, the Sink **Shall Not** set the Capability Mismatch bit.

When a Sink returns a Request Data Object with the Capability Mismatch bit set in response to a Source Capabilities Message, it indicates that it wants more power than the Source is currently offering. This can be due to a lack of a specific offered voltage or insufficient current for the offered voltages.

<!-- page 209 -->

Sources whose Port Reported PDP is less than their Port Present PDP (see Section 6.4.10) **Shall** respond to Requests with the Capability Mismatch bit set by issuing a New Source Capabilities Message within `tCapabilitiesMismatchResponse` of the `PS_RDY` Message that offers either:

1. The set of Source Capabilities to minimally satisfy the Sink's requirements based on what it actually requires for full operation by evaluating the:

   i. `Sink_Capabilities_Extended` Message (for Sinks > PD2) and/or

   ii. `Sink_Capabilities` Message or `EPR_Sink_Capabilities` Message.

2. The set of Source Capabilities the Source can supply at this time based on the Port Present PDP.

To prevent looping, Sources **Should Not** send a New Source Capabilities Message in response to subsequent Request Message with the Capability Mismatch flag set until its Port Present PDP changes.

Once a Guaranteed Capability Source that has responded to a Capability Mismatch, it **Shall Not** subsequently send out another Source Capabilities Message at a lower PDP unless the power required by the Sink (as indicated in its Sink Capabilities Message) has also been reduced. Sources wishing to manage their power **May** periodically check the Sink Capabilities Message to determine whether this has changed.

Note: A Source Capabilities Message refers to a `Source_Capabilities` Message or an `EPR_Source_Capabilities` Message, and a Sink Capabilities Message refers to a `Sink_Capabilities` Message or `EPR_Sink_Capabilities` Message, Request refers to a Request Message or `EPR_Request` Message depending on operating Mode.

#### 7.9.2.2. Wait in Response to Request Message

The Wait Message allows the Source time to recover the power it requires to meet the Request, e.g., through Re-Negotiation with other Sinks or an upstream Source. A Source **Should** only send a Wait Message in response to a Request Message when an Explicit Contract exists between the Port Partners. The Sink is allowed to repeat the Request Message using the `SinkRequestTimer` and **Shall** ensure that at least `tSinkRequest` has elapsed after receiving the Wait Message before sending another Request Message.

### 7.9.3. PS_Rdy

The `PS_RDY` Message **Shall** be sent by the Source (or by both the New Sink and New Source during the Power Role Swap AMS or Fast Role Swap AMS) to indicate its power supply has reached the desired operating condition.

## 7.10. Power Role Swap AMS

The `PR_Swap` Message **May** be sent by either Port Partner to Request an exchange of Power Roles. The recipient of the Message **Shall** respond by sending an Accept Message, a Wait Message or a Reject Message.

- The Accept Message **Shall** be sent by the recipient of the `PR_Swap` Message to signal that it is willing to do a Power Role Swap and has begun the Power Role Swap AMS. If an Accept Message is sent, the Source and Sink **Shall** do a Power Role Swap.
- The Reject Message **Shall** be sent by the recipient of the `PR_Swap` Message to signal that it is unable or unwilling to do a Power Role Swap. If a Reject Message is sent, no action **Shall** be taken.
- For a Wait Message, see section, Section 7.10.1

The `PR_Swap` Message **Shall Not** be sent while in EPR Mode. While in EPR Mode if a Power Role Swap is required, an EPR Mode Exit **Shall** be done first. After a successful Power Role Swap the Port Partners **Shall** reset their respective Protocol Layers (equivalent to a Soft Reset): resetting their `MessageIDCounter`, `RetryCounter` and Protocol Layer State machines before attempting to establish the First Explicit Contract. At this point the New Source **Shall** also reset its `CapsCounter`.
<!-- page 210 -->
The New Source **Shall** have Rp asserted on the CC wire and the New Sink **Shall** have Rd asserted on the CC wire as defined in [USB-C]. When performing a Power Role Swap from Source to Sink, the Port **Shall** change its CC wire resistor from Rp to Rd. When performing a Power Role Swap from Sink to Source, the Port **Shall** change its CC wire resistor from Rd to Rp. The DFP (Host), UFP (Device) Data Roles and VCONN Source **Shall** remain unchanged by the Power Role Swap process.

During the Power Role Swap AMS, for the Initial Source Port, the Port Power Role field **Shall** be set to Sink in the PS_RDY Message indicating that the Initial Source's power supply is turned off.

During the Power Role Swap AMS, for the Initial Sink, the Port Power Role field **Shall** be set to Source for Messages initiated by the Policy Engine after receiving the PS_RDY Message from the Initial Source.

Note: During the Power Role Swap process the Initial Sink does not disconnect even though VBUS drops below vSafe5V.

For more information regarding the Power Role Swap, refer to:

Section 4.3.3, "Power Role Swap Sequence"

Section 7.1.2, "Data Reset".

Section 9.2.20.3, "Policy Engine in Source to Sink Power Role Swap State Diagram"

Section 9.2.20.4, "Policy Engine in Sink to Source Power Role Swap State Diagram"

### 7.10.1. Wait in response to a PR_Swap Message

The Wait Message is used when responding to a PR_Swap Message to indicate that a Power Role Swap might be possible in the future. This can occur in any case where the Device receiving the PR_Swap Message needs to evaluate the Request further e.g., by requesting Sink Capabilities from the originator of the PR_Swap Message. Once it has completed this evaluation one of the Port Partners **Should** initiate the Power Role Swap process again by sending a PR_Swap Message. Once it has completed this evaluation one of the Port Partners **Should** initiate the Power Role Swap process again by sending a PR_Swap Message.

The Wait Message is also used where a Hub is operating in hybrid Mode when a Request cannot be satisfied (see [UCSI]). A Port that receives a Wait Message in response to a PR_Swap Message **Shall** wait tPRSwapWait after receiving the Wait Message before sending another PR_Swap Message.

## 7.11. Fast Role Swap AMS

See Chapter 10 for details regarding Fast Role Swap.

## 7.12. Data Role Swap AMS

### 7.12.1. DR_Swap

The Data Role Swap process can be used by Port Partners whether or not they support USB Communications capability. A DFP that supports USB Communication capability starts as the USB Host on Attachment. A UFP that supports USB Communication capability starts as the USB Device on Attachment.

[USB-C] Dual-Role Data (DRD) Ports **Shall** have the capability to perform a Data Role Swap from the PE_SRC_Ready or PE_SNK_Ready states. DFPs and UFPs **May** have the capability to perform a Data Role Swap from the PE_SRC_Ready or PE_SNK_Ready states. A Data Role Swap **Shall** be regarded in the same way as a cable Detach/Re-Attach in relation to any USB Communication which is ongoing between the Port Partners. If there are any Active Modes between the Port Partners when a DR_Swap Message is a received, then a Hard Reset **Shall** be

<!-- page 211 -->
performed (see Section 8.6.4"). If the Cable Plug has any Active Modes then the DFP **Shall Not** issue a DR_Swap Message and **Shall** cause all Active Modes in the Cable Plug to be exited before accepting a Data Role Swap Request. The Source of VBUS and VCONN Source **Shall** remain unchanged as well as the Rp/Rd resistors on the CC wire during the Data Role Swap process.

The DR_Swap Message **May** be sent by either Port Partner. The recipient of the DR_Swap Message **Shall** respond by sending an Accept Message, a Wait Message or a Reject Message.

- The Accept Message **Shall** be sent by the recipient of the DR_Swap Message to signal that it is willing to do a Data Role Swap and has begun the Data Role Swap AMS. If an Accept Message is sent, the Source and Sink **Shall** exchange Data Roles.
- The Reject Message **Shall** be sent by the recipient of the DR_Swap Message to signal that it is unable or unwilling to do a Data Role Swap. If a Reject Message is sent, no action **Shall** be taken.
- For a Wait Message, see Section 7.12.2.

Before a Data Role Swap, the initial DFP **Shall** have its Port Data Role bit set to DFP, and the initial UFP **Shall** have its Port Data Role bit set to UFP.

### 7.12.2. Wait in response to a DR_Swap Message

The Wait Message is used when responding to a DR_Swap Message to indicate that a Data Role Swap might be possible in the future. This can occur in any case where the Device receiving the DR_Swap Message needs to evaluate the Request further. Once it has completed this evaluation one of the Port Partners **Should** initiate the Data Role Swap process again by sending a DR_Swap Message.

A Port that receives a Wait Message in response to a DR_Swap Message, **Shall** wait tDRSwapWait after receiving the Wait Message before sending another DR_Swap Message.

## 7.13. VCONN Swap AMS

The VCONN_Swap Message **Shall** be supported by any Port that can operate as a VCONN Source.

The VCONN_Swap Message **May** be sent by either Port Partner to Request an exchange of VCONN Source. The recipient of the Message **Shall** respond by sending an Accept Message, Reject Message (see Section 7.4), Wait Message (see Section 7.13.1), or Not_Supported Message.

- The Accept Message **Shall** be sent by the recipient of the VCONN_Swap Message to signal that it is willing to do a VCONN Swap and has begun the VCONN Swap AMS. The new VCONN Source **Shall** send a PS_RDY Message within tVconnSourceOn to indicate that it is now sourcing VCONN. The initial VCONN Source **Shall** cease sourcing VCONN within tVconnSourceOff of receipt of the last bit of the EOP of the PS_RDY Message.
- The Reject Message **Shall** be sent by the recipient of a VCONN_Swap Message, that is not presently the VCONN Source, to indicate that it is unable to do a VCONN Swap, and no action **Shall** be taken. The Port that is presently the VCONN Source **Shall Not** send a Reject Message in response to a VCONN_Swap Message.
- For a Wait Message, see Section 7.13.1.
- If a Not_Supported Message is sent, the requester is informed that VCONN Swap is not supported. The Port that is not presently the VCONN Source **May** turn on VCONN when a Not_Supported Message is received in response to a VCONN_Swap Message.

The DFP (Host), UFP (Device) Data Roles and Source of VBUS **Shall** remain unchanged as well as the Rp/Rd resistors on the CC wire during the VCONN Swap process.

<!-- page 212 -->
VCONN **Shall** be continually sourced during the VCONN Swap process to maintain power to the Cable Plug(s) i.e., make before break.

Before communicating with a Cable Plug a Port **Shall** ensure that it is the VCONN Source and that the Cable Plugs are powered, by performing a VCONN Swap if necessary. Since it cannot be guaranteed that the present VCONN Source is supplying VCONN, the only means to ensure that the Cable Plugs are powered is for a Port wishing to communicate with a Cable Plug to become the VCONN Source. If a Not_Supported Message is returned in response to the VCONN_Swap Message, then the Port is allowed to become the VCONN Source until a Hard Reset or Detach.

A VCONN Source that is also a Source can attempt to send a Discover Identity Command using SOP' to a Cable Plug prior to the establishment of the First Explicit Contract.

Note: Even when it is currently the VCONN Source, the Sink is not permitted to initiate an AMS with a Cable Plug unless Rp is set to SinkTxOK.

### 7.13.1. Wait in response to a VCONN_Swap Message

The Wait Message is used when responding to a VCONN_Swap Message to indicate that a VCONN_Swap might be possible in the future. This can occur in any case where the Device receiving the VCONN_Swap Message needs to evaluate the Request further. Once it has completed this evaluation, one of the Port Partners **Should** initiate the VCONN Swap process again by sending a VCONN_Swap Message.

A Port that receives a Wait Message in response to a VCONN_Swap Message **Shall** wait tVCONNSwapWait after receiving the Wait Message before sending another VCONN_Swap Message.

A Port that is currently the VCONN Source **Shall** respond with an Accept Message (rather than a Wait Message) if the Port Partner's Revision and Version, as reported in the Revision Message, is earlier than R3.2 V1.1. A Port Partner supporting an earlier Revision and Version will not expect a Wait Message and will generate a Soft Reset in response.

## 7.14. Alert AMS Message

The Alert Message is provided to allow Port Partners to inform each other when there is a status change event. Some of the events are critical such as OCP, OVP and OTP, while others are informational such as a change in a Battery's status from charging to either charging or discharging.

The Alert Message **Shall** only be sent when the Source or Sink detects a status change.

### 7.14.1. Alert Types

Multiple event bits **May** be set in one Alert Message. Once the Alert Message has been sent the event bits **Shall** be cleared.

A Get_Status Message **Should** be sent in response to a non-Battery status change in an Alert Message to get the details of the change. A Get_Battery_Status Message **Should** be sent in response to a Battery status change in an Alert Message to get the details of the change.

## 7.15. Get Status AMS

An Alert Message indicates that the Sender's status has changed, and the Receiver **Should** re-read it using a Get_Status Message.

The Active Cable **Shall** respond to the Get_Status Message by returning an SOP'/SOP'' Status Message (see Table 6.52).

<!-- page 213 -->
To make sure that the internal temperature value in the Status Message is up to date, the Cable Plug **Shall** update its internal temperature at least every tACTempUpdate.

## 7.16. Get PPS Status AMS

The Sink sends the Get_PPS_Status Message to Request information about the Source's PPS status. The Source **Shall** respond with a PPS_Status Message. A Source that supports this AMS **Shall** support sending the Alert Message. A Sink that supports this AMS **Shall** support receiving the Alert Message.

## 7.17. Get Source Capabilities (SPR) AMS

The Port **Shall** respond by returning a Source_Capabilities Message.

Sinks with the Dual-Role Power bit set, **Shall** respond to a Get_Source_Cap Message by declaring their Source Capabilities, without limiting them based on the cable's Capabilities.

## 7.18. Get Sink Capabilities (SPR) AMS

The Port **Shall** respond by returning a Sink_Capabilities Message.

## 7.19. Extended Capabilities AMS

### 7.19.1. Get_Source_Cap_Extended

The Port **Shall** respond by returning a Source_Capabilities_Extended Message.

### 7.19.2. Source_Capabilities_Extended

The Source_Capabilities_Extended Message **Should** be sent in response to a Get_Source_Cap_Extended Message.

#### 7.19.2.1. Touch Current Field

The Touch Current field reports whether the Source meets certain leakage current levels and if it has a ground pin.

A Source **Shall** set the Touch Current bit (bit 0) when their leakage current is less than 65μA rms when Source's maximum capability is less than or equal to 30W, or when their leakage current is less than 100 μA rms when its power capability is between 30W and 100W. The total combined leakage current **Shall** be measured in accordance with [IEC 60950-1] when tested at 250VAC rms at 50 Hz.

#### 7.19.2.2. Peak Current Field

The Peak Current1/Peak Current2/Peak Current3 fields **Shall** contain the combinations of Peak Current that the Source supports (see Section 4.1.6).

Peak Current provides a means for Source report its ability to provide current in excess of the Negotiated amount for short periods. The Peak Current descriptor defines up to three combinations of percent overload, duration and duty cycle defined as Peak Current1, Peak Current2, and Peak Current3 that the Source supports. A Source **May** offer no Peak Current capability. A Source **Shall** populate unused Peak Current bit fields with zero.

The Bit Fields within Peak Current1, Peak Current2 and Peak Current3 contain the following subfields:

- Duty Cycle

<!-- page 214 -->
- Duty Cycle **Shall** be the maximum percentage of overload period reported in 5% increments. The values **Should** be 5%, 10% and 50% for PeakCurrent1, PeakCurrent2, and PeakCurrent3, respectively.
- VBUS Droop
  - **Shall** be set to '1' to indicate there is an additional 5% voltage droop on VBUS when the overload conditions occur as defined by vSrcPeak. However, it is recommended that the Source **Should** provide VBUS in the range of vSrcNew when overload conditions occur and set this bit to '0'.

#### 7.19.2.3. Number of Batteries/Battery Slots Field

The number assigned to a given Battery Slot **Shall Not** change between Attach and Detach.

### 7.19.3. Get_Sink_Cap_Extended

The Port **Shall** respond by returning a Sink_Capabilities_Extended Message.

### 7.19.4. Sink_Capabilities_Extended

The Sink_Capabilities_Extended Message **Shall** be sent in response to a Get_Sink_Cap_Extended Message.

#### 7.19.4.1. XID Field

If the vendor does not have an XID, then it **Shall** return zero in this field (see [USB2] and [USB3]).

#### 7.19.4.2. Battery Info

Fixed Batteries **Shall** be numbered consecutively from 0 to 3. The number assigned to a given Fixed Battery **Shall Not** change between Attach and Detach. Battery Slots **Shall** be numbered consecutively from 4 to 7. The number assigned to a given Battery Slot **Shall Not** change between Attach and Detach.

#### 7.19.4.3. Sink Modes

Bits 1-4 **May** be set independently of one another. The combination indicates what sources of power the Sink can utilize. For example, some Sinks are only powered by a Battery (e.g., an automobile Battery) rather than the more common AC Supply and some Sinks are only powered from VBUS or VCONN.

## 7.20. Battery Capabilities AMS

### 7.20.1. Get_Battery_Cap Message

The Port **Shall** respond by returning a Battery_Capabilities Message containing a Battery Capabilities Data Block (BCDB) for the targeted Battery.

## 7.21. Battery Status AMS

### 7.21.1. Get_Battery_Status Message

The Port **Shall** respond by returning a Battery_Status Message containing a Battery Status Data Object (BSDO) for the targeted Battery.

### 7.21.2. Battery Status Message

The Battery_Status Message **Shall** be sent in response to a Get_Battery_Status Message.

<!-- page 215 -->
## 7.22. Manufacturer Information AMS

### 7.22.1. Get_Manufacturer_Info Message

The Port **Shall** respond by returning a Manufacturer_Info Message containing a Manufacturer Info Data Block (MIDB). Support for this feature by the Cable Plug is **Optional**.

### 7.22.2. Manufacturer_Info Message

The Manufacturer_Info Message **Shall** be sent in response to a Get_Manufacturer_Info Message.

## 7.23. Country Codes AMS

### 7.23.1. Get_Country_Codes Message

The Port Partner **Shall** respond by returning a Country_Codes Message.

### 7.23.2. Country Codes Message

The Country_Codes Message **Shall** be sent in response to a Get_Country_Codes Message.

## 7.24. Country Information AMS

### 7.24.1. Country_Info Message

The Country_Info Message **Shall** be sent in response to a Get_Country_Info Message.

## 7.25. Revision Information AMS

### 7.25.1. Get_Revision Message

The Port Partner **Shall** respond by returning a Revision Message.

The Active Cable **Shall** respond by returning a Revision Message.

### 7.25.2. Revision Message

The Revision Message **Shall** be sent in response to the Get_Revision Message sent by the Port Partner.

## 7.26. Source Information AMS

### 7.26.1. Get_Source_Info Message

The Port **Shall** respond by returning the Source_Info Message.

### 7.26.2. Source_Info Message

The Source_Info Message **Shall** be sent in response to a Get_Source_Info Message.

<!-- page 216 -->
#### 7.26.2.1. Port Maximum PDP Field

A Guaranteed Capability Port (as indicated by the Port Type field being set to '1') **Shall** always be capable of supplying this amount of power. A Managed Capability Port (as indicated by the Port Type field being set to '0') **Shall** be able to offer this amount of power at some time.

The Port Maximum PDP **Shall** be the same as the larger of the SPR Source PDP Rating and the EPR Source PDP Rating in the Source_Capabilities_Extended Message.

#### 7.26.2.2. Port Present PDP Field

A Guaranteed Capability Port **Shall** always set its Port Present PDP to be the same as its Port Maximum PDP or the highest possible value when limited.

A Managed Capability Port that is a Shared Capacity Group **Shall** set its Port Present PDP to Shared Port Power Available as defined in [USB-C] or to a lower value when limited.

A Managed Capability Port, that is an Assured Capacity Port, **Shall** set its Port Present PDP to the Port Maximum PDP or the highest value possible when limited.

#### 7.26.2.3. Port Guaranteed PDP Field

Managed Capability Ports may offer less power than the value defined in the Port Guaranteed PDP but **Shall** be able to provide at least this power level once the Sink initiates the process of requesting more power by setting the mismatch bit, and following the process indicated in Section 7.9.2.1. While there is an Explicit Contract for Port Guaranteed PDP, the Source **Shall Not** reduce the advertised power.

The only scenario where the Source **May** not be able to reach Port Guaranteed PDP is if the Cable Capabilities limit the current.

## 7.27. Security AMS

The authentication process between Port Partners or a Port and Cable Plug is fully described in [USBC Auth]. This specification describes two Extended Messages used by the authentication process when applied to PD. In the authentication process described in [USBC Auth] there are three basic exchanges that serve to:

- Get the Port or Cable Plug's certificates.
- Get the Port or Cable Plug's digest.
- Challenge the Port Partner or Cable Plug.

Certificates are used to convey information, attested to by a signer, which attests to the Port Partner's or Cable Plug's authenticity. The Port's or Cable Plug's certificates are needed when a Port encounters a Port Partner or Cable Plug it has not been Attached to before. To minimize calculations after the initial Attachment, a Port can also use a digest consisting of hashes of the certificates rather than the certificates themselves. Once the Port has the certificates and has calculated the hashes, it stores the hashes and uses the digest in future exchanges. After the Port gets the certificates or digest, it challenges its Port Partner or the Cable Plug to detect replay attacks. For further details refer to [USBC Auth].

## 7.28. Firmware Update AMS

The firmware update process between Port Partners or a Port and Cable Plug is fully described in [USB DFU]. This specification describes two Extended Messages used by the firmware update process when applied to PD.

<!-- page 217 -->
## 7.29. Enter USB AMS

The recipient of the Message **Shall** respond by sending an Accept Message, a Wait Message or a Reject Message.

- The Accept Message **Shall** be sent by the recipient of the Enter_USB Message to indicate that it has begun the Enter USB AMS.
- The Reject Message **Shall** be sent by UFP on receiving an Enter_USB Message to indicate it is unable to enter the requested USB Mode.
- For a Wait Message, see Section 7.29.1.

When entering [USB4] operation, the Enter_USB Message **Shall** be sent by a [USB4] PDUSB Hub's DFP(s) or [USB4] PDUSB Host's DFP(s) within tEnterUSB:

- following a PD Connection.
- after a Data Reset to enter [USB4] operation is completed.
- after a Data Role Swap is completed.

The Enter_USB Message **May** be sent by a PDUSB Hub's DFP(s) or PDUSB Host's DFP(s) within tEnterUSB following a PD Connection or after a Data Reset to enter [USB3] or [USB2] operation. The Enter_USB Message **Shall** be used by a PDUSB Hub's DFP(s) to speculatively train the USB links or enter [DPTC] or [TBT3] Alternate Modes prior to the presence of a Host. In this case, the Host Present bit **Shall** be cleared. When the Host is Connected the Enter_USB Message **Shall** be resent with the Host Present bit set. The Enter_USB Message's Enter USB Data Object (EUDO), received from the Root Hub when the USB Host is Connected, **Shall** be propagated down through the Hub tree. See [USB-C] [USB4] Hub Connection Requirements.

### 7.29.1. Wait in Response to an Enter_USB Message

The Wait Message is used, by the UFP, when responding to an Enter_USB Message to indicate that entering the requested USB Mode might be possible in the future. This can occur, for example, in any case where the UFP needs to Negotiate more power to enter the Mode. Once the UFP has completed this the DFP **Should** initiate the Enter USB process again by sending an Enter_USB Message. A DFP that receives a Wait Message in response to an Enter_USB Message **Shall** wait tEnterUSBWait after receiving the Wait Message before sending another Enter_USB Message.

## 7.30. EPR Mode AMS

### 7.30.1. Process to Enter EPR Mode AMS

An EPR Source **Shall** enter EPR Mode upon Request by an EPR Sink Connected with an EPR Cable when able to offer the Source Capabilities as defined in the Power Rules (Table 3.5" and Table 3.6).

For Port Partners to successfully enter EPR Mode, the following conditions must be met:

- The Sink **Shall** Request entry into the EPR Mode.
- The Source **Shall** verify the cable is EPR Capable.
- A Sink **Shall Not** be Connected to the Source through a Charge Through VPD (CT-VPD).
- The Source and Sink **Shall** already be in an SPR Explicit Contract.
- The EPR Capable bit **Shall** be set in the Fixed Supply 5V PDO.
<!-- page 218 -->

- The EPR Capable bit **Shall** have been set in the RDO in the last Request Message received by the Source.

To verify the cable is EPR Capable, the EPR Source **Shall** have already done the following (see Section 7.31.18.3):

- Discover the cable prior to entering its First Explicit Contract
- Alternatively, within tEPRSourceCableDiscovery of entry into the First Explicit Contract
  - If it is the VCONN Source, discover the cable.
  - If not the VCONN Source, do a VCONN Swap then discover the cable and verify the cable is EPR Capable by completing steps 5 and 6 in the entry process in Figure 7.3.

The EPR Mode Entry process is a multi-Message AMS. An illustration of this AMS is shown in Figure 7.3.

<!-- page 219 -->

**Figure 7.3. Illustration of process to enter EPR Mode.**

The EPR Mode Entry process is illustrated for **Informative** purposes.

![Figure 7.3. Illustration of process to enter EPR Mode.](07-pd-communications-protocol-message-usage/figure-7.3.png)

<!-- page 220 -->

The entry process **Shall** follow these steps in order:

1. The Sink **Shall** send the EPR_Mode Message with the Action field set to 1 (Enter) and the Data field set to its Operational PDP. If the EPR Source receives an EPR_Mode Message with the Action field not set to Enter it **Shall** initiate a Soft Reset.
2. The Source **Shall** do the following:
   - a. Verify the EPR Capable bit was set in the most recent RDO. If not set, the Source **Shall** do the following:
     - i. Send an EPR_Mode Message with the Action field set to 4 (Enter Failed) and the Data field set to 3 ("EPR Mode Capable bit not set in the RDO").
     - ii. Abort the EPR Mode Entry process and remain in the existing SPR Explicit Contract.
   - b. Verify the EPR Capable bit was set in the most recent 5V Fixed Supply PDO. If not set, the Source **Shall** do the following:
     - i. Send an EPR_Mode Message with the Action field set to 4 (Enter Failed) and the Data field set to 5 ("EPR Mode Capable bit not set in the Fixed Supply 5V PDO").
     - ii. Abort the EPR Mode Entry process and remain in the existing SPR Explicit Contract.
   - c. Verify the Source is still able to support EPR Mode. If not, the Source **Shall** do the following:
     - i. Send an EPR_Mode Message with the Action field set to 4 (Enter Failed) and Data field set to 4 ("Unable at this time").
     - ii. Abort the EPR Mode Entry process and remain in the existing SPR Explicit Contract. The Sink **May** at some time in the future send another Request to enter EPR Mode.
   - d. Send an EPR_Mode Message with the Action field set to 2 (Enter Acknowledged).
3. If the Sink receives any Message, other than an EPR_Mode Message with the Action Field set to 2, the Sink **Shall** initiate a Soft Reset.
4. When the EPR Source has used the Discover Identity Command to determine and remembers the Cable Capabilities or the EPR Source is Connected with a captive cable:
   - a. If the cable is EPR Capable it **Should** go directly to Step 7, but **May** continue to Step 5.
   - b. If the cable is not EPR Capable it **Shall** do the following:
   - c. Send an EPR_Mode Message with the Action field set to 4 (Enter Failed) and the Data field set to 1 ("Cable not EPR Capable").
   - d. Abort the EPR Mode Entry process and remain in the existing SPR Explicit Contract.
5. If the Source is not the VCONN Source, it **Shall** send a VCONN_Swap Message.
   - a. If the Source fails to become the VCONN Source, it **Shall**:
     - i. Send an EPR_Mode Message with the Action field set to 4 (Enter Failed) and the Data field set to 2 (not VCONN Source).
     - ii. Abort the EPR Mode Entry process and remain in the existing SPR Explicit Contract.
6. The Source **Shall** use the Discover Identity Command to read the cable's e-Marker and verify the following:
   - a. Cable VDO - Maximum VBUS Voltage (Passive Cable)/Maximum VBUS Voltage (Active Cable) field is `11b` (50V)
   - b. Cable VDO - VBUS Current Handling Capability (Passive Cable)/VBUS Current Handling Capability (Active Cable) field is `10b` (5A)

<!-- page 221 -->

   - c. Cable VDO - EPR Capable (Passive Cable)/EPR Capable (Active Cable) field is `1b` (EPR Capable)
   - d. If the cable fails to respond to the Discover Identity Command or is not EPR Capable, the Source **Shall** do the following:
     - i. Send an EPR_Mode Message with the Action field set to 4 (Enter Failed) and the Data field to ("Cable not EPR Capable").
     - ii. Abort the EPR Mode Entry process and remain in the existing SPR Explicit Contract.
7. The Source **Shall** send the EPR_Mode Message with the Action field set to 3 (Enter Succeeded) and **Shall** enter EPR Mode.
8. If the Sink receives an EPR_Mode Message with the Action field set to 3 (Enter Succeeded) it **Shall** enter EPR Mode, otherwise it **Shall** initiate a Soft Reset.

If the EPR Mode Entry process successfully completes within tEnterEPR of the last bit of the GoodCRC Message sent in response to the EPR_Mode Message with the Action field set to 1 (Enter), the Source **Shall** send an EPR_Source_Capabilities Message within tFirstSourceCap.

If the EPR Mode Entry process has not been aborted or does not complete within tEnterEPR of the last bit of the GoodCRC Message sent in response to the EPR_Mode Message with the Action field set to 1 (Enter), the Sink **Shall** initiate a Soft Reset.

### 7.30.2. EPR_Source_Capabilities Message

An EPR Source **Shall** send the EPR_Source_Capabilities Message:

- When entering EPR Mode
- While in EPR Modes when its Capabilities chang
- In response to an EPR_Get_Source_Cap Message
- After a Soft Reset while in EPR Mode

An EPR Sink operating in EPR Mode **Shall** evaluate every EPR_Source_Capabilities Message it receives and **Shall** respond with a EPR_Request Message. If its power consumption exceeds the Source Capabilities, it **Shall** Re-Negotiate so as not to exceed the Source's most recently Advertised Source Capabilities.

While operating in SPR Mode, an EPR Sink receiving an EPR_Source_Capabilities Message in response to an EPR_Get_Source_Cap Messages **Shall Not** respond with an EPR_Request Message.

The PDOs or APDOs in an EPR_Source_Capabilities Message **Shall** only be requested using the EPR_Request Message and only when in EPR Mode.

When Source wants to exit EPR Mode, if not already in power Contract with an SPR PDO or APDO, it **Shall** send an EPR_Source_Capabilities Message with no EPR PDOs or APDOs (i.e. seven SPR PDOs or APDOs including any zero padded ones). See Section 6.5.18.

### 7.30.3. EPR_Request Message

An EPR_Request Message **Shall** be sent by a Sink, operating in EPR Mode, to Request power, typically during the Request phase of a power Negotiation. The EPR_Request Message **Shall** be sent in response to the most recent EPR_Source_Capabilities Message.

The Source **Shall** verify the PDO in the EPR_Request Message exactly matches the PDO in the latest EPR_Source_Capabilities Message pointed to by the Object Position field in the RDO.

<!-- page 222 -->

The Source **Shall** respond to an EPR_Request Message in the same manner as it responds to a Request Message with an Accept Message, a Reject Message, or a Wait Message. The Explicit Contract Negotiation process for EPR is the same as the process for SPR Mode except that the Source_Capabilities Message is replaced by the EPR_Source_Capabilities Message and the Request Message is replaced by the EPR_Request Message.

- The Accept Message **Shall** be sent by the Source, in EPR Mode, to signal the Sink that the Source is willing to meet the EPR_Request Message.
- The Reject Message **Shall** be sent to signal the Sink, in EPR Mode, that the Source is unable to meet the EPR_Request Message. This **May** be due an Invalid Request or because the Source can no longer provide what it previously Advertised. A mismatch between the requested and advertised PDOs is an example of an Invalid Request.
- The Wait Message **May** be sent by the Source, in EPR Mode, to signal the Sink that the Source is currently unable to meet the EPR_Request Message.

The Wait Message **Shall** be sent to signal the Sink, in response to a EPR_Request Message in EPR Mode during Negotiation, to indicate that the Source is currently unable to meet the Request.

### 7.30.4. EPR_Sink_Capabilities Message

The EPR Sink **Shall** only send the EPR_Sink_Capabilities Message in response to an EPR_Get_Sink_Cap Message.

### 7.30.5. Operation in EPR Mode

While operating in EPR Mode, the Source **Shall** only send EPR_Source_Capabilities Messages to Advertise its power Capabilities and the Sink **Shall** only respond with EPR_Request Message Messages to Negotiate Explicit Contracts. The EPR_Request Message **May** be for either an SPR or EPR PDO or APDO.

If the Source sends a Source_Capabilities Message, that is not in response to a Sink Get_Source_Cap Message, the Sink **Shall** initiate a Hard Reset. If the Sink sends a Request Message, the Source **Shall** initiate a Hard Reset.

The Source **Shall** monitor the CC communications path to ensure that there is periodic traffic. The Sink **Shall** send an EPR_Keep_Alive Message when it has not sent any Messages for more than tSinkEPRKeepAlive to ensure there is timely periodic traffic. If there is no traffic for more than tSourceEPRKeepAlive, the Source **Shall** initiate a Hard Reset.

A PR_Swap is not allowed while in EPR Mode. The recipient of a PR_Swap Message **Shall** respond with a Reject Message.

### 7.30.6. EPR_Keep_Alive Message

The Source operating on EPR Mode responds by returning an EPR_Keep_Alive_Ack Message to the Sink.

See Section 7.31.18.1 and Section 7.31.18.2 for more information on the EPR_Keep_Alive Message.

### 7.30.7. Exiting EPR Mode

#### 7.30.7.1. Commanded Exit

While in EPR Mode, either the Source or Sink **May** exit EPR Mode by sending an EPR_Mode Message with the Action field set to 5 (Exit).

The ports **Shall** be in an Explicit Contract with an SPR PDO or APDO prior to the EPR Mode Exit process by either:

- The Source sending an EPR_Source_Capabilities Message with no EPR PDO or APDO s (e.g., only SPR PDOs or APDOs) or

<!-- page 223 -->

- The Sink negotiating a new Explicit Contract with bit 31 in the RDO set to zero (e.g., only SPR PDOs or APDOs)).

The process to exit EPR Mode is a multi-Message AMS and **Shall** follow these steps in order:

1. The Port Partners **Shall** be in an Explicit Contract with an SPR PDO or APDO.
2. Either the Source or Sink **Shall** send an EPR_Mode Message with the Action field set to 5 (Exit) to exit the EPR Mode.
3. The Source **Shall** send a Source_Capabilities Message within tFirstSourceCap of the GoodCRC Message in response to the EPR_Mode Message with the Action field set to 5 (Exit).
4. If the Sink does not receive a Source_Capabilities Message within tTypeCSinkWaitCap of the last bit of the GoodCRC Message in response to the EPR_Mode Message with the Action field set to 5 (Exit), Sink **Shall** initiate a Hard Reset.

#### 7.30.7.2. Implicit Exit

EPR Mode **Shall** be exited as the side-effect of the Fast Role Swap process. This is because at the end of this process VBUS will be at vSafe5V and the Ports will be in an Implicit Contract. The New Source will then send a Source_Capabilities Message (not an EPR_Source_Capabilities Message) to begin the process of negotiating an SPR Explicit Contract. Once an SPR Explicit Contract is entered, the Source and Sink can then enter EPR Mode if needed.

#### 7.30.7.3. Exits due to errors

Other critical errors can occur while in EPR Mode; these errors **Shall** result in Hard Reset being initiated by the Port that detects the error. Some of these errors include:

- An EPR_Mode Message with the Action field set to 5 (Exit) to exit EPR Mode is received by a Port in an Explicit Contract with an EPR PDO or APDO.
- The Sink receives an EPR_Source_Capabilities Message with an EPR PDO or APDO in any of the first seven object positions.
- The PDO or APDO in the EPR_Request Message does not match the PDO or APDO in the latest EPR_Source_Capabilities Message pointed to by the Object Position field in the RDO.
- The Source receives a Request Message.
- The Sink receives a Source_Capabilities Message not in response to a Get_Source_Cap Message.

### 7.30.8. EPR_Get_Source_Cap Message

A Port that can operate as an EPR Source **Shall** respond by returning an EPR_Source_Capabilities Message.

A Port that does not support EPR Mode as a Source **Shall** have the following behavior:

- If the Port supports EPR Mode as a Sink and is a DRP Port, it **Shall** return a Reject Message or Not_Supported Message.
- If the Port does not support EPR Mode as a Sink or is not a DRP Port, it **Shall** return a Not_Supported Message.

An EPR Capable Sink Port that is operating in SPR Mode **Shall** treat the EPR_Source_Capabilities Message as informational only and **Shall Not** respond with an EPR_Request Message.

### 7.30.9. EPR_Get_Sink_Cap Message

A Port that is EPR Capable operating as a Sink **Shall** respond by returning an EPR_Sink_Capabilities Message.

<!-- page 224 -->

A Port that does not support EPR Mode as a Sink **Shall** behave as follows:

- If the Port supports EPR Mode as a Source and is a DRP Port, it **Shall** return a Reject Message or Not_Supported Message.
- If the Port does not support EPR Mode as a Source or is not a DRP Port, it **Shall** return a Not_Supported Message.

## 7.31. Timers

All the following timers are defined in terms of bits on the bus regardless of where they are implemented in terms of the logical architecture. This is to ensure a fixed reference for the starting and stopping of timers. It is left to the implementer to ensure that this timing is observed in a real system.

### 7.31.1. CRCReceiveTimer

The CRCReceiveTimer **Shall** be used by the sender's Protocol Layer to ensure that a Message has not been lost. Failure to receive an acknowledgment of a Message (a GoodCRC Message) whether caused by a bad GoodCRC Message on the receiving end or by a garbled Message within tReceive is detected when the CRCReceiveTimer expires. The sender's Protocol Layer response when a CRCReceiveTimer expires **Shall** be to retry nRetryCount times.

Note: Cable Plugs do not retry Messages and large Extended Messages that are not Chunked are not retried (see Section 7.32.4"). Sending of the Preamble corresponding to the retried Message **Shall** start within tRetry of the CRCReceiveTimer expiring.

The CRCReceiveTimer **Shall** be started when the last bit of the Message EOP has been transmitted by the PHY Layer. The CRCReceiveTimer **Shall** be stopped when the last bit of the EOP corresponding to the GoodCRC Message has been received by the PHY Layer. The Protocol Layer receiving a Message **Shall** respond with a GoodCRC Message within tTransmit in order to ensure that the sender's CRCReceiveTimer does not expire. The tTransmit time **Shall** be measured from when the last bit of the Message EOP has been received by the PHY Layer until the first bit of the Preamble of the GoodCRC Message has been transmitted by the PHY Layer.

### 7.31.2. SenderResponseTimer

The SenderResponseTimer **Shall** be used by the sender's Policy Engine to ensure that a Message requesting a response (e.g., Get_Source_Cap Message) is responded to within a bounded time of tSenderResponse. Failure to receive the expected response is detected when the SenderResponseTimer expires. For Extended Messages received as Chunks, the SenderResponseTimer will also be started and stopped by the Chunked Rx State Machine. See Section 9.2.2 for more details of the SenderResponseTimer operation. The Policy Engine's response when the SenderResponseTimer expires **Shall** be dependent on the Message sent. The SenderResponseTimer **Shall** be started from the time the last bit of the GoodCRC Message EOP, corresponding to the Message requesting a response, has been received by the PHY Layer. The SenderResponseTimer **Shall** be stopped when the last bit of the EOP of the GoodCRC Message, corresponding to the expected response Message, has been transmitted by the PHY Layer. The receiver of a Message requiring a response **Shall** respond within tReceiverResponse in order to ensure that the sender's SenderResponseTimer does not expire. The tReceiverResponse time **Shall** be measured from the time the last bit of the GoodCRC Message EOP, corresponding to the expected Request Message, has been transmitted by the PHY Layer until the first bit of the response Message Preamble has been transmitted by the PHY Layer.

### 7.31.3. Capability Timers

Sources and Sinks use Capability Timers to determine Attachment of a PD Capable Device. By periodically sending or requesting Capabilities, it is possible to determine PD Device Attachment when a response is received.

<!-- page 225 -->

#### 7.31.3.1. SourceCapabilityTimer

Prior to the First Explicit Contract a Source **Shall** use the SourceCapabilityTimer to periodically send out a Source_Capabilities Message every tTypeCSendSourceCap while:

- The Port is Attached.
- The Source is not in an active connection with a PD Sink Port.

Whenever there is a SourceCapabilityTimer timeout the Source **Shall** send a Source_Capabilities Message Message. It **Shall** then re-initialize and restart the SourceCapabilityTimer. The SourceCapabilityTimer **Shall** be stopped when the last bit of the EOP corresponding to the GoodCRC Message has been received by the PHY Layer since a PD connection has been established. At this point, the Source waits for a Request Message or a response timeout.

Note: The Source can also stop sending Source_Capabilities Message after nCapsCount Messages have been sent without a GoodCRC Message response (see Section 7.32.6). See Section 9.2.3 for more details of when Source_Capabilities Messages are transmitted.

#### 7.31.3.2. SinkWaitCap Timer

While in a Default Contract or an Implicit Contract when a Sink observes an absence of Source_Capabilities Messages, after VBUS is present, for a duration of tTypeCSinkWaitCap the Sink **May** issue Hard Reset Signaling in order to restart the sending of Source_Capabilities Messages by the Source (see Section 7.32.6) or continue to operate at USB Type-C current. When a Sink, entering EPR Mode, observes an absence of EPR_Source_Capabilities Messages, after the GoodCRC Message acknowledging the EPR_Mode Message with the Action field set to 3 (Enter Succeeded), for a duration of tTypeCSinkWaitCap the Sink **Shall** issue Hard Reset Signaling in order to exit EPR Mode (see Section 6.4.9).

When a Sink, exiting EPR Mode, observes an absence of Source_Capabilities Messages, after the GoodCRC Message acknowledging the EPR_Mode Message with the Action field set to 5 (Exit), for a duration of tTypeCSinkWaitCap the Sink **Shall** issue Hard Reset Signaling in order to restart the sending of Source_Capabilities Messages by the Source (see Section 7.32.6). See Section 9.2.4 for more details of when the SinkWaitCapTimer is run.

#### 7.31.3.3. tFirstSourceCap

After Port Partners are Attached or after a Hard Reset or after a Power Role Swap or after a Fast Role Swap a Source **Shall** send its first Source_Capabilities Message within tFirstSourceCap of VBUS reaching vSafe5V. After Soft Reset, a Source **Shall** send its first Source Capabilities Message within tFirstSourceCap after the last bit of the GoodCRC Message EOP corresponding to the Accept Message. This ensures that the Sink receives a Source Capabilities Message before the Sink's SinkWaitCapTimer expires.

A Source entering EPR Mode **Shall** send its first EPR_Source_Capabilities Message within tFirstSourceCap of the GoodCRC Message acknowledging the EPR_Mode Message with the Action field set to 3 (Enter Succeeded). A Source exiting EPR Mode **Shall** send its first Source_Capabilities Message within tFirstSourceCap of the GoodCRC Message acknowledging the EPR_Mode Message with the Action field set to 5 (Exit).

### 7.31.4. Wait Timers and Times

#### 7.31.4.1. SinkRequestTimer

The SinkRequestTimer is used to ensure that the time before the next Sink Request Message, after a Wait Message has been received from the Source in response to a Sink Request Message (see Section 7.9.2.2), is a minimum of tSinkRequest. The SinkRequestTimer **Shall** be started when the EOP of a Wait Message has been received and **Shall** be stopped if any other Message is received or during a Hard Reset. The Sink **Shall** wait at least tSinkRequest, after receiving the EOP of a Wait Message sent in response to a Sink Request Message, before sending a new Request Message. Whenever there is a SinkRequestTimer timeout, the Sink **May** send a Request Message. It **Shall** then re-initialize and restart the SinkRequestTimer.
<!-- page 226 -->

#### 7.31.4.2. tPRSwapWait

The time before the next PR_Swap Message, after a Wait Message has been received in response to a PR_Swap Message (see Section 7.10.1) is a minimum of tPRSwapWait min. The Port **Shall** wait at least tPRSwapWait after receiving the EOP of a Wait Message sent in response to a PR_Swap Message, before sending a new PR_Swap Message.

#### 7.31.4.3. tDRSwapWait

The time before the next DR_Swap Message, after a Wait Message has been received in response to a DR_Swap Message (see Section 7.12.2) is a minimum of tDRSwapWait min. The Port **Shall** wait at least tDRSwapWait after receiving the EOP of a Wait Message sent in response to a DR_Swap Message, before sending a new DR_Swap Message.

#### 7.31.4.4. tVconnSwapWait

The time before the next VCONN_Swap Message, after a Wait Message has been received in response to a VCONN_Swap Message (see Section 7.13.1) is a minimum of tVconnSwapWait min. The Port **Shall** wait at least tVconnSwapWait after receiving the EOP of a Wait Message sent in response to a VCONN_Swap Message, before sending a new VCONN_Swap Message.

#### 7.31.4.5. tVconnSwapDelayDFP

The time delay for DFP after losing VCONN Source role due to an incoming VCONN Swap Request from UFP and before sending the next VCONN_Swap Message. The DFP **Shall** wait at least tVconnSwapDelayDFP after sending the EOP of the GoodCRC Message in response to PS_RDY Message received at the end of the previous VCONN Swap AMS.

#### 7.31.4.6. tVconnSwapDelayUFP

The time delay for UFP after losing VCONN Source role due to an incoming VCONN Swap Request from DFP and before sending the next VCONN_Swap Message. The UFP **Shall** wait at least tVconnSwapDelayUFP after sending the EOP of the GoodCRC Message in response to PS_RDY Message received at the end of the previous VCONN Swap AMS.

#### 7.31.4.7. tEnterUSBWait

The time before the next Enter_USB Message, after a Wait Message has been received in response to a Enter_USB Message (see Section 7.29.1) is a minimum of tEnterUSBWait min. The DFP **Shall** wait at least tEnterUSBWait after receiving the EOP of a Wait Message sent in response to an Enter_USB Message, before sending a new Enter_USB Message.

### 7.31.5. Power Supply Timers

See Section 4.5 for diagrams showing the usage of the timers in this section.

#### 7.31.5.1. PSTransition Timer

The PSTransitionTimer is used by the Policy Engine to timeout on a PS_RDY Message. It is started when a Request for New Source Capabilities has been accepted and will timeout after tPSTransition if a PS_RDY Message has not been received. This condition leads to a Hard Reset and a return to USB Default Operation. The PSTransitionTimer relates to the time taken for the Source to transition from one voltage, or current level, to another (see Section 4.1).

The PSTransitionTimer **Shall** be started when the last bit of the GoodCRC Message EOP, corresponding to an Accept Message, has been transmitted by the PHY Layer. The PSTransitionTimer **Shall** be stopped when the last bit of the GoodCRC Message EOP, corresponding to the PS_RDY Message, has been transmitted by the PHY Layer.

<!-- page 227 -->

#### 7.31.5.2. PSSourceOffTimer

Use during Power Role Swap

The PSSourceOffTimer is used by the Policy Engine in Dual-Role Power Device that is currently acting as a Sink to timeout on a PS_RDY Message during a Power Role Swap AMS. This condition leads to USB Type-C Error Recovery. If a PR_Swap Message Request has been sent by the Dual-Role Power Device currently acting as a Source the Sink can respond with an Accept Message. When the last bit of the GoodCRC Message EOP, corresponding to this transmitted Accept Message, is received by the Sink's PHY Layer, then the PSSourceOffTimer **Shall** be started.

If a PR_Swap Message Request has been sent by the Dual-Role Power Device currently acting as a Sink the Source can respond with an Accept Message. When the last bit of the GoodCRC Message EOP, corresponding to this received Accept Message, is transmitted by the Sink's PHY Layer, then the PSSourceOffTimer **Shall** be started. The PSSourceOffTimer **Shall** be stopped when the last bit of the GoodCRC Message EOP, corresponding to the received PS_RDY Message, is transmitted by the PHY Layer. The PSSourceOffTimer relates to the time taken for the remote Dual-Role Power Device to stop supplying power (see Section 4.3.3). The timer **Shall** time out if a PS_RDY Message has not been received from the remote Dual-Role Power Device within tPSSourceOff indicating this has occurred.

Use during Fast Role Swap

The PSSourceOffTimer is used by the Policy Engine in Dual-Role Power Device that is the Initial Sink (currently providing vSafe5V) to timeout on a PS_RDY Message during a Fast Role Swap AMS. This condition leads to USB Type-C Error Recovery. When the FR_Swap Message Request has been sent by the Initial Sink, the Initial Source **Shall** respond with an Accept Message. When the last bit of the GoodCRC Message EOP, corresponding to this Accept Message is received by the Initial Sink's PHY Layer, then the PSSourceOffTimer **Shall** be started. The PSSourceOffTimer **Shall** be stopped when the last bit of the GoodCRC Message EOP, corresponding to the received PS_RDY Message, is transmitted by the PHY Layer. The PSSourceOffTimer relates to the time taken for the Initial Source to stop supplying power and for VBUS to revert to vSafe5V (see Figure 10.3). The timer **Shall** time out if a PS_RDY Message has not been received from the Initial Source within tPSSourceOff indicating this has occurred.

#### 7.31.5.3. PSSourceOnTimer

Use during Power Role Swap

The PSSourceOnTimer is used by the Policy Engine in Dual-Role Power Device that has just stopped sourcing power and is waiting to start sinking power to timeout on a PS_RDY Message during a Power Role Swap. This condition leads to USB Type-C Error Recovery.

The PSSourceOnTimer **Shall** be started when:

- The last bit of the GoodCRC Message EOP, corresponding to the transmitted PS_RDY Message, is received by the PHY Layer.
- The PSSourceOnTimer **Shall** be stopped when:
- The last bit of the GoodCRC Message EOP, corresponding to the received PS_RDY Message, is transmitted by the PHY Layer.

The PSSourceOnTimer relates to the time taken for the remote Dual-Role Power Device to start sourcing power (see Section 4.3.3) and will time out if a PS_RDY Message indicating this has not been received within tPSSourceOn.

Use during Fast Role Swap

The PSSourceOnTimer is used by the Policy Engine in Dual-Role Power Device that has just stopped sourcing power and is waiting to start sinking power to timeout on a PS_RDY Message during a Fast Role Swap. This condition leads to USB Type-C Error Recovery.

<!-- page 228 -->

The PSSourceOnTimer **Shall** be started when:

- The last bit of the GoodCRC Message EOP, corresponding to the transmitted PS_RDY Message, is received by the PHY Layer.
- The PSSourceOnTimer **Shall** be stopped when:
- The last bit of the GoodCRC Message EOP, corresponding to the received PS_RDY Message, is transmitted by the PHY Layer.

The PSSourceOnTimer relates to the time taken for the remote Dual-Role Power Device to start sourcing power (see Section 10.1) and will time out if a PS_RDY Message indicating this has not been received within tPSSourceOn.

#### 7.31.5.4. NoResponseTimer

The NoResponseTimer is used by the Policy Engine in a Source to determine that its Port Partner is not responding after a Hard Reset. When the NoResponseTimer times out, the Policy Engine **Shall** issue up to nHardResetCount additional Hard Resets before determining that the Port Partner is non-responsive to USB Power Delivery messaging. If the Source fails to receive a GoodCRC Message in response to a Source_Capabilities Message within tNoResponse of:

- The last bit of a Hard Reset Signaling being sent by the PHY Layer if the Hard Reset Signaling was initiated by the Sink.
- The last bit of a Hard Reset Signaling being received by the PHY Layer if the Hard Reset Signaling was initiated by the Source.
- Then the Source **Shall** issue additional Hard Resets up to nHardResetCount times (see Section 7.1.3).

For a non-responsive Device, the Policy Engine in a Source May either decide to continue sending Source_Capabilities Messages or to go to non-USB Power Delivery operation and cease sending Source_Capabilities Messages.

### 7.31.6. BIST Timers

#### 7.31.6.1. tBISTCarrierMode

tBISTCarrierMode is used to define the maximum time that a UUT has to enter BIST Carrier Mode when requested by a Tester. A UUT **Shall** enter BIST Carrier Mode within tBISTCarrierMode of the last bit of the GoodCRC Message EOP, corresponding to the received the BIST Message used to initiate the test, being transmitted by the PHY Layer. In BIST Carrier Mode when transmitting a continuous carrier signal transmission **Shall** start as soon as the UUT enters BIST Mode.

#### 7.31.6.2. BISTContModeTimer

The BISTContModeTimer is used by a UUT to ensure that a Continuous BIST Mode (i.e., BIST Carrier Mode) is exited in a timely fashion. A UUT that has been put into a Continuous BIST Mode **Shall** return to normal operation (either PE_SRC_Transition_to_default, PE_SNK_Transition_to_default, or PE_CBL_Ready) within tBISTContMode of starting to transmit a continuous carrier signal.

#### 7.31.6.3. tBISTSharedTestMode

tBISTSharedTestMode is used to define the maximum time that a UUT has to enter BIST Shared Capacity Test Mode when requested by a Tester. A UUT **Shall** enter BIST Shared Capacity Test Mode and send a new Source_Capabilities Message from all Ports within the Shared Capacity Port within tBISTSharedTestMode of the last bit of the GoodCRC Message. Message EOP, corresponding to the received the BIST Message used to initiate the test, being transmitted by the PHY Layer.

<!-- page 229 -->

### 7.31.7. Power Role Swap Timers

#### 7.31.7.1. SwapSourceStartTimer

The SwapSourceStartTimer **Shall** be used by the New Source, after a Power Role Swap or Fast Role Swap, to ensure that it does not send Source_Capabilities Message before the New Sink is ready to receive the Source_Capabilities Message. The New Source **Shall Not** send the Source_Capabilities Message earlie than tSwapSourceStart after the last bit of the EOP of GoodCRC Message sent in response to the PS_RDY Message sent by the New Source indicating that its power supply is ready. The Sink **Shall** be ready to receive a Source_Capabilities Message tSwapSinkReady after having sent the last bit of the EOP of GoodCRC Message sent in response to the PS_RDY Message sent by the New Source indicating that its power supply is ready.

### 7.31.8. Soft Reset Timers

#### 7.31.8.1. tSoftReset

A failure to see a GoodCRC Message in response to any Message within tReceive (after nRetryCount retries), when a Port Pair is Connected, is indicative of a communications failure. This **Shall** cause the Source or Sink to send a Soft_Reset Message, transmission of which **Shall** be completed within tSoftReset of the CRCReceiveTimer expiring.

#### 7.31.8.2. tProtErrSoftReset

If the Protocol Error occurs that causes the Source or Sink to send a Soft_Reset Message, the transmission of the Soft_Reset Message **Shall** be completed within tProtErrSoftReset of the EOP of the GoodCRC Message sent in response to the Message that caused the Protocol Error.

### 7.31.9. Data Reset Timers

#### 7.31.9.1. VCONNDischargeTimer

The VCONNDischargeTimer is used by the Policy Engine in the DFP to ensure the UFP actively discharges VCONN in a timely manner to ensure the cable will restore Ra. Once the UFP has discharged VCONN below vRaReconnect (see [USB-C]) it sends a PS_RDY Message (see also Section 4.6).

If the DFP does not receive a PS_RDY Message from the UFP within tVCONNSourceDischarge of the last bit of the GoodCRC Message acknowledging the Accept Message in response to the Data_Reset Message, the VCONNDischargeTimer will time out and the Policy Engine **Shall** enter the ErrorRecovery State.

#### 7.31.9.2. tDataReset

The DFP **Shall** complete the Data_Reset process (see Section 7.1.2") within tDataReset of the last bit of the GoodCRC Message EOP, corresponding to the Accept Message, being transmitted by the PHY Layer.

#### 7.31.9.3. DataResetFailTimer

The DataResetFailUFPTimer **Shall** be used by the DFP's Policy Engine to ensure the Data Reset process completes within tDataResetFailUFP of the last bit of the GoodCRC Message acknowledging the Accept Message in response to the Data_Reset Message. If the DFP's DataResetFailUFPTimer expires, the DFP **Shall** enter the ErrorRecovery State.

#### 7.31.9.4. DataResetFailUFPTimer

The DataResetFailUFPTimer **Shall** be used by the UFP's Policy Engine to ensure the Data Reset process completes within tDataResetFailUFP of the last bit of the GoodCRC Message acknowledging the Accept Message in response to the Data_Reset Message. If the UFP's DataResetFailUFPTimer expires, the UFP **Shall** enter the ErrorRecovery State.

<!-- page 230 -->

### 7.31.10. Hard Reset Timers

#### 7.31.10.1. HardResetCompleteTimer

The HardResetCompleteTimer is used by the Protocol Layer in the case where it has asked the PHY Layer to send Hard Reset Signaling and the PHY Layer is unable to send the Signaling within a reasonable time due to a non-Idle channel. If the PHY Layer does not indicate that the Hard Reset Signaling has been sent within tHardResetComplete of the Protocol Layer requesting transmission, then the Protocol Layer **Shall** inform the Policy Engine that the Hard Reset Signaling has been sent in order to ensure the power supply is reset in a timely fashion.

#### 7.31.10.2. PSHardResetTimer

The PSHardResetTimer is used by the Policy Engine in a Source to ensure that the Sink has had sufficient time to process Hard Reset Signaling before turning off its power supply to VBUS. When a Hard Reset occurs the Source, stops driving VCONN, removes Rp from the CC pin and starts to transition the VBUS voltage to vSafe0V either:

- tPSHardReset after the last bit of the Hard Reset Signaling has been received from the Sink or
- tPSHardReset after the last bit of the Hard Reset Signaling has been sent by the Source. See Section 4.4.

#### 7.31.10.3. tDRSwapHardReset

If a DR_Swap Message is received during Modal Operation then a Hard Reset **Shall** be initiated by the recipient of the unexpected DR_Swap Message; Hard Reset Signaling **Shall** be generated within tDRSwapHardReset of the EOP of the GoodCRC Message sent in response to the DR_Swap Message.

#### 7.31.10.4. tProtErrHardReset

If a Protocol Error occurs that directly leads to a Hard Reset, the transmission of the Hard Reset Signaling **Shall** be completed within tProtErrHardReset of the EOP of the GoodCRC Message sent in response to the Message that caused the Protocol Error.

#### 7.31.10.5. tSendHardReset

When a timer expiration leads to sending a Hard Reset, the transmission of the last bit of the Hard Reset Message **Shall** be completed within tSendHardReset. tSendHardReset applies to the expiration of:

- SenderResponseTimer,
- SourcePPSCommTimer or
- SourceEPRKeepAliveTimer.

#### 7.31.10.6. tInitiateErrorRecovery

When an event or timer expiration leads to ErrorRecovery, the ErrorRecovery State **Shall** be entered within tInitiateErrorRecovery.

### 7.31.11. Structured VDM Timers

#### 7.31.11.1. VDMResponseTimer

The VDMResponseTimer **Shall** be used by the Initiator's Policy Engine to ensure that a Structured VD Command Request needing a response (e.g. Discover Identity Command Request) is responded to withi a bounded time of tVDMSenderResponse. The VDMResponseTimer **Shall** be applied to all Structure VDM Commands except the Enter Mode and Exit Mode Commands which have their own timer (VDMModeEntryTimer and VDMModeExitTimer respectively). Failure to receive the expected response is detected when the VDMResponseTimer expires.

<!-- page 231 -->

The Policy Engine's response when the VDMResponseTimer expires **Shall** depend on the Message sent (see Section 7.5 and Section 9.2). The VDMResponseTimer **Shall** be started from the time the last bit of the GoodCRC Message EOP corresponding to the VDM Command requesting a response, has been received by the PHY Layer. The VDMResponseTimer **Shall** be stopped when the last bit of the EOP of the GoodCRC Message, corresponding to the expected VDM Command response, has been transmitted by the PHY Layer. The receiver of a Message requiring a response **Shall** respond within tVDMReceiverResponse in order to ensure that the sender's VDMResponseTimer does not expire. The tVDMReceiverResponse time **Shall** be measured from the time the last bit of the Message EOP has been transmitted by the PHY Layer until the first bit of the response Message Preamble has been transmitted by the PHY Layer.

#### 7.31.11.2. VDMModeEntryTimer

The VDMModeEntryTimer **Shall** be used by the Initiator's Policy Engine to ensure that the response to a Structured VDM Enter Mode Command Request (ACK or NAK with ACK indicating that the requested Alternate Mode has been entered) arrives within a bounded time of tVDMWaitModeExit. Failure to receive the expected response is detected when the VDMModeEntryTimer expires. The Policy Engine's response when the VDMModeEntryTimer expires is to inform the Device Policy Manager (see Section 9.2.24.1.1).

The VDMModeEntryTimer **Shall** be started from the time the last bit of the EOP of the GoodCRC Message, corresponding to the VDM Command Request, has been received by the PHY Layer. The VDMModeEntryTimer **Shall** be stopped when the last bit of the EOP of the GoodCRC Message, corresponding to the expected Structured VDM Command response (ACK, NAK or BUSY), has been transmitted by the PHY Layer.

The receiver of a Message requiring a response **Shall** respond within tVDMEnterMode in order to ensure that the sender's VDMModeEntryTimer does not expire. The tVDMEnterMode time **Shall** be measured from the time the last bit of the EOP of the GoodCRC Message, corresponding to VDM Command Request, has been transmitted by the PHY Layer until the first bit of the response Message Preamble has been transmitted by the PHY Layer.

#### 7.31.11.3. VDMModeExitTimer

The VDMModeExitTimer **Shall** be used by the Initiator's Policy Engine to ensure that the ACK response to a Structured VDM Exit Mode Command, indicating that the requested Alternate Mode has been exited, arrives within a bounded time of tVDMWaitModeExit. Failure to receive the expected response is detected when the VDMModeExitTimer expires. The Policy Engine's response when the VDMModeExitTimer expires is to inform the Device Policy Manager (see Section 9.2.24.2.1). The VDMModeExitTimer **Shall** be started from the time the last bit of the GoodCRC Message EOP, corresponding to the VDM Command requesting a response, has been received by the PHY Layer. The VDMModeExitTimer **Shall** be stopped when the last bit of the GoodCRC Message EOP, corresponding to the expected Structured VDM Command response ACK, has been transmitted by the PHY Layer. The receiver of a Message requiring a response **Shall** respond within tVDMExitMode in order to ensure that the sender's VDMModeExitTimer does not expire. The tVDMExitMode time **Shall** be measured from the time the last bit of the Message EOP has been received by the PHY Layer until the first bit of the response Message Preamble has been transmitted by the PHY Layer.

#### 7.31.11.4. tVDMBusy

The Initiator **Shall** wait at least tVDMBusy, after receiving a BUSY Command response, before repeating the Structured VDM Request again.

### 7.31.12. VCONN Timers

#### 7.31.12.1. VconnOnTimer

The VconnOnTimer is used during a VCONN Swap.

The VconnOnTimer **Shall** be started when:

<!-- page 232 -->

- The last bit of GoodCRC Message EOP, corresponding to the Accept Message, is transmitted or received by the PHY Layer.

The VconnOnTimer **Shall** be stopped when:

- The last bit of the GoodCRC Message EOP, corresponding to the PS_RDY Message, is transmitted by the PHY Layer.

Prior to sending the PS_RDY Message, the Port **Shall** have turned VCONN On.

#### 7.31.12.2. tVconnSourceOff

The tVconnSourceOff time applies during a VCONN Swap. The initial VCONN Source **Shall** cease sourcing VCONN within tVconnSourceOff of the last bit of the GoodCRC Message EOP, corresponding to the PS_RDY Message, being transmitted by the PHY Layer.

#### 7.31.12.3. tCableMessage

When Ports on both ends are compliant with Revision 3.x of the specification, the ports **Shall Not** wait tCableMessage before sending an SOP' Packet or SOP'' Packet even when communicating using [PD2] with a Cable Plug. This specification defines Collision Avoidance mechanisms that obviate the need for this time. Cable Plugs **Shall** only wait tCableMessage before sending an SOP' Packet or SOP'' Packet when operating at [PD2]. When operating at Revisions higher than [PD2] Cable Plugs **Shall Not** wait tCableMessage before sending an SOP' Packet or SOP'' Packet.

#### 7.31.12.4. DiscoverIdentityTimer

The DiscoverIdentityTimer is used prior to or during an Explicit Contract when discovering whether a Cable Plug is PD Capable using SOP'. When performing Cable Discovery during an Explicit Contract the Discover Identity Command Request **Shall** be sent every tDiscoverIdentity. No more than nDiscoverIdentityCount Discover Identity Messages without a GoodCRC Message response **Shall** be sent. If no GoodCRC Message response is received after nDiscoverIdentityCount Discover Identity Command requests have been sent by a Port, the Port **Shall Not** send any further SOP'/SOP'' Messages.

### 7.31.13. Collision Avoidance Timers

#### 7.31.13.1. SinkTxTimer

The SinkTxTimer is used by the Protocol Layer in a Source to allow the Sink to complete its transmission before initiating an AMS. The Source **Shall** wait a minimum of tSinkTx after changing Rp from SinkTxOK to SinkTxNG before initiating an AMS by sending a Message. A Sink **Shall** only initiate an AMS when it has determined that Rp is set to SinkTxOK.

#### 7.31.13.2. tSrcHoldsBus

If a transition into the PE_SRC_Ready State will result in an immediate transition out of the PE_SRC_Ready State within tSrcHoldsBus e.g. it is due to a Protocol Error that has not resulted in a Soft Reset, then the notifications of the end of AMS and first Message in an AMS May Not be sent to avoid changing the Rp value unnecessarily.

### 7.31.14. Fast Role Swap Timers

See Section 10.1 for more information on the use of Fast Role Swap timers.

#### 7.31.14.1. tFRSwap5V

The tFRSwap5V time **Shall** be measured from:

<!-- page 233 -->

The later of:

- The last bit of the GoodCRC Message EOP, corresponding to the Accept Message or
- VBUS being within vSafe5V.
- Until the first bit of the response PS_RDY Message Preamble has been transmitted by the PHY Layer.

During a Fast Role Swap, the Initial Source **Shall** start the PS_RDY Message within tFRSwap5V after both:

- The Initial Source has sent the Accept Message, and
- VBUS is at or below vSafe5V.

#### 7.31.14.2. tFRSwapComplete

During a Fast Role Swap, the Initial Sink **Shall** respond with a the PS_RDY Message within tFRSwapComplete after it has received the PS_RDY Message from the Initial Source. The tFRSwapComplete time **Shall** be measured from the time the last bit of the GoodCRC Message EOP, corresponding to the PS_RDY Message, has been transmitted by the PHY Layer until the first bit of the response PS_RDY Message Preamble has been transmitted by the PHY Layer.

#### 7.31.14.3. tFRSwapInit

That last bit of the EOP of the FR_Swap Message **Shall** be transmitted by the New Source no later than tFRSwapInit after the Fast Role Swap Request has been detected (see Section 10.3)

### 7.31.15. Chunking Timers

#### 7.31.15.1. ChunkingNotSupportedTimer

The ChunkingNotSupportedTimer is used by a Source or Sink which does not support multi-Chunk Chunking but has received a Message Chunk.

The ChunkingNotSupportedTimer **Shall** be started when:

The last bit of the GoodCRC Message EOP, corresponding to a Message Chunk of a multi-Chunk Message, is transmitted by the PHY Layer. The Policy Engine **Shall Not** send its Not_Supported Message before the ChunkingNotSupportedTimer expires.

#### 7.31.15.2. ChunkSenderRequestTimer

The ChunkSenderResponseTimer is used during a Chunked Message transmission. The ChunkSenderResponseTimer **Shall** be used by the sender's Chunking State machine to ensure that a Chunk Response is responded to within a bounded time of tChunkSenderResponse. Failure to receive the expected response is detected when the ChunkSenderResponseTimer expires.

The ChunkSenderResponseTimer **Shall** be started when:

The last bit of the GoodCRC Message EOP, corresponding to the Chunk Response Message, is received by the PHY Layer.

The ChunkSenderResponseTimer **Shall** be stopped when:

- The last bit of the EOP of the GoodCRC Message, corresponding to the Chunk Request Message, is transmitted by the PHY Layer.
<!-- page 234 -->

- A Message other than a Chunk Request is received from the Protocol Layer Rx.

The receiver of a Chunk Response requiring a Chunk Request **Shall** respond with a Chunk Request within `tChunkReceiverRequest` in order to ensure that the sender's `ChunkSenderRequestTimer` does not expire.

The `tChunkReceiverRequest` time **Shall** be measured from the time the last bit of the EOP of the GoodCRC Message, corresponding to the Chunk Response Message, has been transmitted by the PHY Layer until the first bit of the response Message Preamble has been transmitted by the PHY Layer.

#### 7.31.15.3. ChunkSenderResponseTimer

The `ChunkSenderResponseTimer` is used during a Chunked Message transmission. The `ChunkSenderResponseTimer` **Shall** be used by the sender's Chunking State machine to ensure that a Chunk Request is responded to within a bounded time of `tChunkSenderResponse`. Failure to receive the expected response is detected when the `ChunkSenderResponseTimer` expires.

The `ChunkSenderResponseTimer` **Shall** be started when:

The last bit of the GoodCRC Message EOP, corresponding to the Chunk Request Message, is received by the PHY Layer.

The `ChunkSenderResponseTimer` **Shall** be stopped when:

The last bit of the GoodCRC Message EOP, corresponding to the Chunk Response Message, is transmitted by the PHY Layer.

A Message other than a Chunk is received from the Protocol Layer. The receiver of a Chunk Request requiring a Chunk Response **Shall** respond with a Chunk Response within `tChunkReceiverResponse` in order to ensure that the sender's `ChunkSenderResponseTimer` does not expire. The `tChunkReceiverResponse` time **Shall** be measured from the time the last bit of the EOP of th GoodCRC Message, corresponding to the Chunk Request Message, has been transmitted by the PHY Layer until the first bit of the response Message Preamble has been transmitted by the PHY Layer.

### 7.31.16. Programmable Power Supply Timers

#### 7.31.16.1. SinkPPSPeriodicTimer

The `SinkPPSPeriodicTimer` **Shall** be used by the Sink's Policy Engine to ensure that communication between the Sink and Source occurs within a bounded time of `tPPSRequest` when in PPS Mode. In the absence of any other traffic, a Request Message requesting a PPS APDO is sent periodically as a keep alive mechanism.

`SinkPPSPeriodicTimer` **Shall** be re-initialized and restarted on transmission, by the PHY Layer, of the last bit of the GoodCRC Message EOP, corresponding to any received Message, that causes the Sink to enter the `PE_SNK_Ready` State. The Sink **Shall** stop the `SinkPPSPeriodicTimer` on transmission, by the PHY Layer, of the last bit of the GoodCRC Message EOP, corresponding to any Message, or the last bit of any Signaling is received, by the PHY Layer, from the Source and by the Sink that causes the Sink to leave the `PE_SNK_Ready` State.

#### 7.31.16.2. SourcePPSCommTimer

The `SourcePPSCommTimer` **Shall** be used by the Source's Policy Engine to ensure that communication between the Sink and Source occurs within a bounded time of `tPPSTimeout` when in PPS Mode. In the absence of any other traffic, a Request Message requesting a PPS APDO is received periodically as a keep alive mechanism.

`SourcePPSCommTimer` **Shall** be re-initialized and restarted when, after receiving any Message that causes the Source to enter the `PE_SRC_Ready` State, the last bit of the corresponding GoodCRC Message EOP is transmitted by the PHY Layer.

<!-- page 235 -->

The Source **Shall** stop the `SourcePPSCommTimer` when:

- After receiving any Message that causes the Source to leave the `PE_SRC_Ready` State, the last bit of the of the corresponding GoodCRC Message EOP is sent by the PHY Layer, or

- The last bit of any Signaling is received by the PHY Layer from the Sink by the Source that causes the Source to leave the `PE_SRC_Ready` State. When the `SourcePPSCommTimer` times out the Source **Shall** issue Hard Reset Signaling.

### 7.31.17. tEnterUSB

The DFP **Shall** send the Enter_USB Message within `tEnterUSB` of either:

- The last bit of the GoodCRC Message acknowledging the Data_Reset_Complete Message in response to the Data_Reset Message or

- A PD Connection, specifically the last bit of the GoodCRC Message acknowledging the Source_Capabilities Message after the initial entry into the `PE_SRC_Send_Capabilities` State or

The last bit of the GoodCRC Message acknowledging the Accept Message in response to the DR_Swap Message Failure by the DFP to meet this timeout parameter can result in the ports not transitioning into [USB4] operation. Any AMS initiated by the UFP prior to receiving the Enter_USB Message will delay reception of the Enter_USB Message and [USB4] operation, therefore a USB4 -capable UFP **Should Not** initiate any AMS until the DFP has been given time to send the Enter_USB Message.

### 7.31.18. EPR Timers

#### 7.31.18.1. SinkEPREnterTimer

The `SinkEPREnterTimer` is used to ensure the EPR Mode Entry process completes within `tEnterEPR`. The Sink **Shall** start the timer when it sees the last bit of the GoodCRC Message in response to the EPR_Mode Message with the Action field set to `1 (Enter)`. The Sink **Shall** stop the timer when the last bit of the corresponding GoodCRC Message EOP, corresponding to the received EPR_Mode Message withthe Action field set to `3 (Enter Succeeded)`, has been transmitted by the PHY Layer. If the timer expires the Sink **Shall** send a Soft_Reset Message.

#### 7.31.18.2. SourceEPRKeepAlive Timer

The `SinkEPRKeepAliveTimer` **Shall** be used by the Sink's Policy Engine to ensure that communication between the Sink and Source occurs within a bounded time of `tSinkEPRKeepAlive`. The Sink **Shall** initialize and run this timer upon entry into the `PE_SNK_Ready` State when in EPR Mode and **Shall** stop it upon exit from the `PE_SNK_Ready` when in EPR Mode.

While operating in EPR Mode, the Sink **Shall** stop the `SinkEPRKeepAliveTimer` timer whenever:

- The last bit of the GoodCRC Message EOP, in response any Message from the Source, is transmitted by the PHY Layer.

- The PHY Layer receives the last bit of the GoodCRC Message EOP in response to any Message sent tothe Source.

If the timer expires the Sink **Shall** send an EPR_Keep_Alive Message.

#### 7.31.18.3. tEPRSourceCableDiscovery

After Port Partners are Attached or after a Hard Reset or after a Power Role Swap or after a Fast Role Swap an EPR Source **Shall** discover the Cable Plug within `tEPRSourceCableDiscovery` of entering the First Explicit Contract.

<!-- page 236 -->

The EPR Source **Shall** send the Discover Identity REQ Command, to the Cable Plug, within `tEPRSourceCableDiscovery` of receiving the GoodCRC Message acknowledging the PS_RDY Message as part of the Explicit Contract Negotiation.

Note: If the EPR Source is not the VCONN Source, `tEPRSourceCableDiscovery`, will also include the time needed for the VCONN Swap.

### 7.31.19. Time Values and Timers

**Table 7.9. Timer Values**

| Parameter Name | Min Value | Nom Value | Max Value | Unit |
|---|---|---|---|---|
| `tACTempUpdate` | | | 500 | ms |
| `tBISTContMode` | 30 | 45 | 60 | ms |
| `tBISTCarrierMode` | | | 300 | ms |
| `tBISTSharedTestMode` | | | 1 | s |
| `tCableMessage` | 750 | | | μs |
| `tCapabilitiesMismatchResponse` | | | 2 | s |
| `tChunkingNotSupported` | 40 | 45 | 50 | ms |
| `tChunkReceiverRequest` | | | 15 | ms |
| `tChunkReceiverResponse` | | | 15 | ms |
| `tChunkSenderRequest` | 24 | 27 | 30 | ms |
| `tChunkSenderResponse` | 24 | 27 | 30 | ms |
| `tDataReset` | 200 | 225 | 250 | ms |
| `tDataResetFail` | 300 | | 400 | ms |
| `tDataResetFailUFP` | 450 | | 550 | ms |
| `tDiscoverIdentity` | 40 | | 50 | ms |
| `tDRSwapHardReset` | | | 15 | ms |
| `tDRSwapWait` | 100 | | | ms |
| `tEnterUSB` | | | 500 | ms |
| `tEnterUSBWait` | 100 | | | ms |
| `tEnterEPR` | 450 | 500 | 550 | ms |
| `tEPRSourceCableDiscovery` | | | 2 | ms |
| `tFirstSourceCap` | | | 250 | ms |
| `tHardReset` | | | 5 | ms |
| `tHardResetComplete` | 4000 | 4500 | 5000 | μs |
| `tSourceEPRKeepAlive` | 750 | 875 | 1000 | ms |
| `tSinkEPRKeepAlive` | 250 | 375 | 500 | ms |
| `tNoResponse` | 4.5 | 5.0 | 5.5 | s |
| `tPPSRequest` | | | | s |
| `tPPSTimeout` | 12.0 | 13.5 | 5.5 | s |
| `tProtErrHardReset` | | | 15 | ms |
| `tSendHardReset` | | | 15 | ms |
| `tProtErrSoftReset` | | | 15 | ms |
| `tPRSwapWait` | 100 | | | ms |
| `tPSHardReset` | 25 | 30 | 35 | ms |
| `tInitiateErrorRecovery` | | | 15 | ms |
| `tPSSourceOff` SPR Mode | 750 | 835 | 920 | ms |
| `tPSSourceOff` EPR Mode | 1120 | 1260 | 1400 | ms |

<!-- page 237 -->

| Parameter Name | Min Value | Nom Value | Max Value | Unit |
|---|---|---|---|---|
| `tPSSourceOn` SPR Mode | 390 | 435 | 480 | ms |
| `tPSTransition` SPR Mode | 450 | 500 | 550 | ms |
| `tPSTransition` EPR Mode | 830 | 925 | 1020 | ms |
| `tReceive` | 900 | 1000 | 1100 | μs |
| `tReceiverResponse` | | | 15 | ms |
| `tRetry` | | | 195 | μs |
| `tSenderResponse` | 27 [1] | | 50 [1] | ms |
| `tSinkRequest` | 100 | | | ms |
| `tSinkTx` | 16 | 18 | 20 | ms |
| `tSoftReset` | | | 15 | ms |
| `tSinkDelay` | | | 5 | ms |
| `tSrcHoldsBus` | | | 50 | ms |
| `tSwapSinkReady` | | | 15 | ms |
| `tSwapSourceStart` | 20 | | | ms |
| `tTransmit` | | | 195 | μs |
| `tTypeCSendSourceCap` | 100 | 150 | 200 | ms |
| `tTypeCSinkWaitCap` | 310 | 465 | 620 | ms |
| `tVconnSourceDischarge` | 160 | 200 | 240 | ms |
| `tVconnSourceOff` | | | 25 | ms |
| `tVconnSourceOn` | | | 50 | ms |
| `tVconnSourceTimeout` | 100 | 150 | 200 | ms |
| `tVconnSwapWait` | 100 | | | ms |
| `tVconnSwapDelayDFP` | 100 | | | ms |
| `tVconnSwapDelayUFP` | 500 | | | ms |
| `tVDMBusy` | 50 | | | ms |
| `tVDMEnterMode` | | | 25 | ms |
| `tVDMExitMode` | | | 25 | ms |
| `tVDMReceiverResponse` | | | 15 | ms |
| `tVDMSenderResponse` | 24 | | 50 [1] | ms |
| `tVDMWaitModeEntry` | 40 | 45 | 50 | ms |
| `tVDMWaitModeExit` | 40 | 45 | 50 | ms |

1. This timing can also be used when USBPD Device is in a PD2 explicit Contract

**Table 7.10. Timer Specifications**

| Timer Name | Parameter | Used By |
|---|---|---|
| `BISTContModeTimer` | `tBISTContMode` | Policy Engine |
| `ChunkingNotSupportedTimer` | `tChunkingNotSupported` | Policy Engine |
| `ChunkSenderRequestTimer` | `tChunkSenderRequest` | Protocol Layer |
| `ChunkSenderResponseTimer` | `tChunkSenderResponse` | Protocol Layer |
| `CRCReceiveTimer` | `tReceive` | Protocol Layer |
| `DataResetFailTimer` | `tDataResetFail` | Policy Engine |
| `DataResetFailUFPTimer` | `tDataResetFailUFP` | Policy Engine |
| `DiscoverIdentityTimer` | `tDiscoverIdentity` | Policy Engine |
| `HardResetCompleteTimer` | `tHardResetComplete` | Protocol Layer |
| `NoResponseTimer` | `tNoResponse` | Policy Engine |

<!-- page 238 -->

| Timer Name | Parameter | Used By |
|---|---|---|
| `PSHardResetTimer` | `tPSHardReset` | Policy Engine |
| `PSSourceOffTimer` | `tPSSourceOff` | Policy Engine |
| `PSSourceOnTimer` | `tPSSourceOn` | Policy Engine |
| `PSTransitionTimer` | `tPSTransition` | Policy Engine |
| `SenderResponseTimer` | `tSenderResponse` | Policy Engine |
| `SinkEPREnterTimer` | `tEnterEPR` | Policy Engine |
| `SinkEPRKeepAliveTimer` | `tSinkEPRKeepAlive` | Policy Engine |
| `SinkPPSPeriodicTimer` | `tPPSRequest` | Policy Engine |
| `SinkRequestTimer` | `tSinkRequest` | Policy Engine |
| `SinkWaitCapTimer` | `tTypeCSinkWaitCap` | Policy Engine |
| `SourceCapabilityTimer` | `tTypeCSendSourceCap` | Policy Engine |
| `SourceEPRKeepAliveTimer` | `tSourceEPRKeepAlive` | Policy Engine |
| `SourcePPSCommTimer` | `tPPSTimeout` | Policy Engine |
| `SinkTxTimer` | `tSinkTx` | Protocol Layer |
| `SwapSourceStartTimer` | `tSwapSourceStart` | Policy Engine |
| `VconnDischargeTimer` | `tVconnSourceDischarge` | Policy Engine |
| `VconnOnTimer` | `tVconnSourceTimeout` | Policy Engine |
| `VDMModeEntryTimer` | `tVDMWaitModeEntry` | Policy Engine |
| `VDMModeExitTimer` | `tVDMWaitModeExit` | Policy Engine |
| `VDMResponseTimer` | `tVDMSenderResponse` | Policy Engine |

## 7.32. Counters

### 7.32.1. MessageID Counter

The `MessageIDCounter` is a rolling counter, ranging from 0 to `nMessageIDCount`, used to detect duplicate Messages. This value is used for the MessageID field in the Message Header of each transmitted Message. Each Port **Shall** maintain a copy of the last MessageID value received from its Port Partner. Devices that support multiple ports, such as Hubs, **Shall** maintain copies of the last MessageID on a per Port basis. A Port which communicates using SOP* Packets **Shall** maintain copies of the last MessageID for each type of SOP* it uses. The transmitter **Shall** use the MessageID in a GoodCRC Message to verify that a particular Message was received correctly. The receiver **Shall** use the MessageID to detect duplicate Messages.

### 7.32.2. Transmitter Usage

The Transmitter **Shall** use the MessageID as follows:

- Upon receiving either Hard Reset Signaling, or a Soft_Reset Message, the transmitter **Shall** set its MessageIDCounter to zero and re-initialize its retry mechanism.

- If a GoodCRC Message with a MessageID matching the MessageIDCounter is not received before the CRCReceiveTimer expires, it **Shall** retry the same Packet up to `nRetryCount` times using the same MessageID.

- If a GoodCRC Message is received with a MessageID matching the current MessageIDCounter before the CRCReceiveTimer expires, the transmitter **Shall** re-initialize its retry mechanism and increment its MessageIDCounter.

- If the Message is aborted by the Policy Engine, the transmitter **Shall** delete the Message from its transmit buffer, re-initialize its retry mechanism and increment its MessageIDCounter.

<!-- page 239 -->

### 7.32.3. Receiver Usage

The Receiver **Shall** use the MessageID as follows:

- When the first good Packet is received after a reset, the receiver **Shall** store a copy of the received MessageID value.

- For subsequent Messages, if MessageID value in a received Message is the same as the stored value, the receiver **Shall** return a GoodCRC Message with that MessageID value and drop the Message (this is a retry of an already received Message).

Note: This **Shall Not** apply to the Soft_Reset Message which always has a MessageID value of zero.

- If MessageID value in the received Message is different than the stored value, the receiver **Shall** return a GoodCRC Message with the new MessageID value, store a copy of the new MessageID value and process the Message.

### 7.32.4. Retry Counter

The `RetryCounter` is used by a Port whenever there is a Message transmission failure (timeout of `CRCReceiveTimer`). If the `nRetryCount` retry fails, then the link **Shall** be reset using the Soft Reset mechanism.

The following rules apply to retries when there is a Message transmission failure (see Section 9.1.2.2):

- Cable Plugs **Shall Not** retry Messages.

- Extended Messages of Data Size > `MaxExtendedMsgLegacyLen` that are not Chunked (Chunked flag set to zero) **Shall Not** be retried.

- Extended Messages of Data Size ≤ `MaxExtendedMsgLegacyLen` (Chunked flag set to zero or one) **Shall** be retried.

- Extended Messages of Data Size > `MaxExtendedMsgLegacyLen` that are Chunked (Chunked flag set to one) individual Chunks **Shall** be retried.

When Messages are not retried, then the RetryCounter is not used. Higher layer protocols are expected to accommodate Message delivery failure or failure to receive a GoodCRC Message.

### 7.32.5. Hard Reset Counter

The `HardResetCounter` is used to retry the Hard Reset whenever there is no response from the remote Device (see Section 7.31.5.4). Once the Hard Reset has been retried `nHardResetCount` times then it **Shall** be assumed that the remote Device is non-responsive.

### 7.32.6. Capabilities Counter

The `CapsCounter` is used to count the number of Source_Capabilities Messages which have been sent by a Source at power up or after a Hard Reset. Implementation of the CapsCounter is **Optional** but **May** be used by any Source which wishes to preserve power by not sending Source_Capabilities Messages after a period of time. When the CapsCounter is implemented and the Source detects that a Sink is Attached then after `nCapsCount` Source_Capabilities Messages have been sent the Source **Shall** decide that the Sink is non- responsive, stop sending Source_Capabilities Messages and disable PD.

A Sink **Shall** use the `SinkWaitCapTimer` to trigger the resending of Source_Capabilities Messages by a USB Power Delivery capable Source which has previously stopped sending Source_Capabilities Messages. Any Sink which is Attached and does not detect a Source_Capabilities Message, **Shall** issue Hard Reset Signaling when the SinkWait-

<!-- page 240 -->

CapTimer times out in order to reset the Source. Resetting the Source **Shall** also reset the CapsCounter and restart the sending of Source_Capabilities Messages.

### 7.32.7. Discover Identity Counter

When sending Discover Identity Messages to a Cable Plug a Port **Shall** maintain a count of Messages sent (`DiscoverIdentityTimer`). No more than `nDiscoverIdentityCount` Discover Identity Messages **Shall** be sent by the Port without receiving a GoodCRC Message Message response. A VCONN Swap **Shall** reset the DiscoverIdentityTimer.

### 7.32.8. VDMBusyCounter

When sending Responder BUSY responses to a Structured Vendor_Defined Message a UFP or Cable Plug **Shall** maintain a count of Messages sent (`VDMBusyCounter`). No more than `nBusyCount` Responder BUSY responses **Shall** be sent. The VDMBusyCounter **Shall** be reset on sending a non-BUSY response.Products wishing to meet [USB-C] requirements for Alternate Mode Entry **Should** use an nBusyCount of 1.

### 7.32.9. Counter Values and Counters

Table 7.12 lists the counters used in this section and Table 7.11 shows the corresponding parameters.

**Table 7.11. Counter Parameters**

| Parameter | Value |
|---|---|
| `nBusyCount` | 5 |
| `nCapsCount` | 50 |
| `nDiscoverIdentityCount` | 20 |
| `nHardResetCount` | 2 |
| `nMessageIDCount` | 7 |
| `nRetryCount` | 2 |

**Table 7.12. Counters**

| Counter | Max |
|---|---|
| `CapsCounter` | `nCapsCount` |
| `DiscoverIdentityCounter` | `nDiscoverIdentityCount` |
| `HardResetCounter` | `nHardResetCount` |
| `MessageIDCounter` | `nMessageIDCount` |
| `RetryCounter` | `nRetryCount` |
| `VDMBusyCounter` | `nBusyCount` |