max/markdowned-datasheets
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
markdowned-datasheets/USB_PD_R3.2/09-state-machine-diagrams.md

4468 lines
219 KiB
Markdown
Raw Permalink Normal View History

add USB_PD_R3.2
2026-08-23 15:14:35 +02:00
<!-- page 254 -->
# Chapter 9. State Machine Diagrams
## 9.1. Protocol Layer State Diagrams
### 9.1.1. Introduction to Protocol Layer State Diagrams
These State diagrams define the operation of the Power Delivery Protocol Layer.
Note: These State diagrams are not intended to replace a well written and robust design.
Figure 9.1 shows an outline of the states defined in the following sections. At the top there is the name of the State. This is followed by "Actions on entry" a list of actions carried out on entering the State and in some states "Actions on exit" a list of actions carried out on exiting the State.
**Figure 9.1. Outline of States**
![Outline of States](09-state-machine-diagrams/figure-9.1.png)
Transitions from one State to another are indicated by arrows with the conditions listed on the arrow. Where there are multiple conditions, these are Connected using either a logical OR "|" or a logical AND "&". The inverse of a condition is shown with a "NOT" in front of the condition.
In some cases, there are transitions which can occur from any State to a particular State. These are indicated by an arrow which is unconnected to a State at one end, but with the other end (the point) Connected to the final State.
In some State diagrams it is necessary to enter or exit from states in other diagrams. Figure 9.2 indicates how such references are made. The reference is indicated with a hatched box. The box contains the name of the referenced State.
**Figure 9.2. References to States**
![References to States](09-state-machine-diagrams/figure-9.2.png)
Timers are included in many of the states. Timers are initialized (set to their starting condition) and run (timer is counting) in the State it is referenced. As soon as the State is exited then the timer is no longer active. Timeouts of the timers are listed as conditions on State transitions.
<!-- page 255 -->
Conditions listed on State transitions will come from one of three sources:
- Messages received from the PHY Layer.
- Events triggered within the Protocol Layer e.g., timer timeouts
- Message and related indications passed up to the Policy Engine from the Protocol Layer (Message sent; Message received etc.)
### 9.1.2. State Operation
The following section details Protocol Layer State Operation when sending and receiving SOP* Packets.
For each SOP' Communication being sent and received there **Shall** be separate Protocol Layer Transmission and Protocol Layer Reception and Hard Reset State Machine instances, with their own counter and timer instances. When Chunking is supported there **Shall** be separate Chunked Tx, Chunked Tx, and Chunked Message Router State Machine instances.
Soft Reset **Shall** only apply to the State Machine instances it is targeted at based on the type of SOP* Packet used to send the Soft_Reset Message. The Hard Reset State Machine (including Cable Reset) **Shall** apply simultaneously to all Protocol Layer State Machine instances active in the DFP, UFP and Cable Plug (if present).
#### 9.1.2.1. Protocol Layer Chunking
##### 9.1.2.1.1. Architecture of Device Including Chunking Layer
The Chunking component resides in the Protocol Layer between the Policy Engine and Protocol Tx/Rx. Figure 9.3 illustrates the relationship between components.
The Chunking Layer comprises three related State machines:
- Chunked Rx.
- Chunked Tx.
- Chunked Message Router.
Note: The consequence of this architecture is that the Policy Engine deals entirely in Unchunked Messages. It will not receive (and might not respond to) a Message until all the related chunks have been collated.
If a PD Device or Cable Plug has no requirement to handle any Message requiring more than one Chunk of any Extended Message, it **May** omit the Chunking Layer. In this case it **Shall** implement the ChunkingNotSupportedTimer to ensure compatible operation with partners which support Chunking (see Section 7.31.15.1 and Section 9.2.7 ).
<!-- page 256 -->
**Figure 9.3. Chunking architecture Showing Message and Control Flow**
![Chunking architecture Showing Message and Control Flow](09-state-machine-diagrams/figure-9.3.png)
###### 9.1.2.1.1.1. Abort Mechanism
Long Chunked Messages bring with them the potential problem that they could prevent urgent Messages from being transmitted in a timely manner. An **Optional** Abort mechanism is provided to remedy this problem.
The Abort Flag referred to in the diagrams below **May** be set and examined by the Policy Engine. The specific means are left to the implementer.
###### 9.1.2.1.1.2. Aborting Sending a Long-Chunked Message
A long-Chunked Message being sent **May** be aborted by setting the Abort Flag. The Message **Shall** be considered aborted when the Abort Flag is again cleared by the Chunked Tx State machine.
###### 9.1.2.1.1.3. Aborting Receiving a Long-Chunked Message
If the Abort mechanism has been implemented, any Message sent while a Chunked Message receive is in progress will result in an error report being received by the Policy Engine, to indicate that the Message Request has been **Discarded**. If the Message was urgent the Policy Engine might set the Abort Flag, which will result in the incoming Chunked Message being aborted. The Abort Flag being cleared by the Chunked Rx State machine indicates that the urgent Message can now be sent.
<!-- page 257 -->
##### 9.1.2.1.2. Chunked Rx State Diagram
Figure 9.4 shows the State behavior for the Chunked Rx State Machine. This recognizes whether Chunked received Messages are involved and deals with requesting chunks when they are. It also performs validity checks on all Messages related to Chunking.
**Figure 9.4. Chunked Rx State Diagram**
![Chunked Rx State Diagram](09-state-machine-diagrams/figure-9.4.png)
1. Chunking is an internal State that is set to 1 if the 'Unchunked Extended Messages Supported' bit in either Source Capabilities or Request is 0. It defaults to 1 and is set after the first exchange of Source Capabilities and Request. It is also set to 1 for SOP' or SOP'' communication.
2. Additional bytes received over specified Data Size will be because of padding in the last Chunk.
3. This State is responsible for starting two timers of similar length. The implementor **Should** mitigate against more than one of these timers resulting in recovery action.
###### 9.1.2.1.2.1. RCH_Wait_For_Message_From_Protocol_Layer State
The Chunked Rx State Machine **Shall** enter the RCH_Wait_For_Message_From_Protocol_Layer State:
- At startup.
- As a result of a Soft Reset occurring.
- On exit from a Hard Reset.
On entry to the RCH_Wait_For_Message_From_Protocol_Layer State the Chunked Rx State machine clears the Extended Rx Buffer and clears the Abort Flag.
In the RCH_Wait_For_Message_From_Protocol_Layer State the Chunked Rx State machine waits until the Chunked Message Router passes up a received Message.
The Chunked Rx State Machine **Shall** transition to the RCH_Pass_Up_Message State when:
<!-- page 258 -->
- A non-Extended Message is passed up from the Chunked Message Router.
- An Extended Message is passed up from the Chunked Message Router, and the Policy Engine has determined that we are not doing Chunking, and the Message has its Chunked bit set to 0b.
The Chunked Rx State Machine **Shall** transition to the RCH_Processing_Extended_Message State when:
- An Extended Message is passed up from the Chunked Message Router, and the Policy Engine has determined that we are doing Chunking, and the Message has its Chunked bit set to 1b.
###### 9.1.2.1.2.2. RCH_Pass_Up_Message State
On entry to the RCH_Pass_Up_Message State the Chunked Rx State machine **Shall** pass the received Message to the Policy Engine.
The Chunked Rx State Machine **Shall** transition to the RCH_Wait_For_Message_From_Protocol_Layer State when:
- The Message has been passed.
###### 9.1.2.1.2.3. RCH_Processing_Extended_Message State
On entry to the RCH_Processing_Extended_Message State the Chunked Rx State machine **Shall**:
- If this is the first Chunk:
- Set Chunk_Number_Expected = 0.
- Set Num bytes received = 0.
- If Chunk contains the expected Chunk Number:
- Append its data to the Extended_Message_Buffer.
- Increment Chunk_Number_Expected.
- Adjust Num bytes received.
The Chunked Rx State Machine **Shall** transition to the RCH_Pass_Up_Message State when:
- The Message is complete (i.e., Num bytes received ≥ specified Data Size.
Note: The inequality allows for padding bytes in the last Chunk, which are not actually part of the Extended Message).
The Chunked Rx State Machine **Shall** transition to the RCH_Requesting_Chunk State when:
- The Message is not yet complete.
The Chunked Rx State Machine **Shall** transition to the RCH_Report_Error State when:
- An unexpected Chunk Number is received.
The Chunked Rx State Machine **Shall** transition to the RCH_Wait_For_Message_From_Protocol_Layer State when:
- The Abort Flag is set.
###### 9.1.2.1.2.4. RCH_Requesting_Chunk State
On entry to the RCH_Requesting_Chunk State the Chunked Rx State machine **Shall**:
<!-- page 259 -->
- Send notification SRT_Stop to SenderResponseTimer State machine (see Section 9.2.2 ).
- Send Chunk Request to Protocol Layer with Chunk Number = Chunk_Number_Expected. The Chunked Rx State Machine **Shall** transition to the RCH_Waiting_Chunk State when:
- Message Transmitted is received from the Protocol Layer.
The Chunked Rx State Machine **Shall** transition to the RCH_Report_Error State when:
- Transmission Error is received from the Protocol Layer, or
- A Message is received from the Protocol Layer.
###### 9.1.2.1.2.5. RCH_Waiting_Chunk State
On entry to the RCH_Waiting_Chunk State the Chunked Rx State machine **Shall**:
- Start the ChunkSenderResponseTimer.
- Send notification SRT_Start to SenderResponseTimer State machine (see Section 9.2.2).
The Chunked Rx State Machine **Shall** transition to the RCH_Processing_Extended_Message State when:
- A Chunk is received from the Protocol Layer.
The Chunked Rx State Machine **Shall** transition to the RCH_Report_Error State when:
- A Message, other than a Chunk, is received from the Protocol Layer, or
- The ChunkSenderResponseTimer expires.
###### 9.1.2.1.2.6. RCH_Report_Error State
The Chunked Rx State Machine **Shall** enter the RCH_Report_Error State:
- When any Message is received and the Chunked Rx State Machine is not in one of the states RCH_Waiting_Chunk or RCH_Wait_For_Message_From_Protocol_Layer.
On entry to the RCH_Report_Error State the Chunked Rx State machine **Shall**:
- Report the error to the Policy Engine.
- If the State was entered because a Message was received, this Message **Shall** be passed to the Policy Engine.
The Chunked Rx State Machine **Shall** transition to the RCH_Wait_For_Message_From_Protocol_Layer State when:
- The error has been reported.
- Any Message received was passed to the Policy Engine.
##### 9.1.2.1.3. Chunked Tx State Diagram
- Figure 9.5 shows the State behavior for the Chunked Tx State Machine. This recognizes whether Chunked transmitted Messages are involved and deals with sending chunks and waiting for Chunk requests when they are. It also performs validity checks on all related Messages related to Chunking.
<!-- page 260 -->
**Figure 9.5. Chunked Tx State Diagram**
![Chunked Tx State Diagram](09-state-machine-diagrams/figure-9.5.png)
###### 9.1.2.1.3.1. TCH_Wait_For_Message_Request_From_Policy_Engine State
The Chunked Tx State Machine **Shall** enter the TCH_Wait_For_Message_Request_From_Policy_Engine State:
- At startup.
- As a result of a Soft Reset occurring.
- On exit from a Hard Reset.
On entry to the TCH_Wait_For_Message_Request_From_Policy_Engine State the Chunked Tx State machine clears the Abort Flag.
In the TCH_Wait_For_Message_Request_From_Policy_Engine State the Chunked Tx State Machine waits until the Policy Engine sends it a Message Request.
The Chunked Tx State Machine **Shall** transition to the TCH_Pass_Down_Message State when:
- A non-Extended Message Request is received from the Policy Engine, or
- A Message Request is received from the Policy Engine and the link is not Chunking.
The Chunked Tx State Machine **Shall** transition to the TCH_Prepare_To_Send_Chunked_Message State when:
<!-- page 261 -->
- An Extended Message Request is received from the Policy Engine, and the link is Chunking.
The Chunked Tx State Machine **Shall Discard** the Message Request and remain in the TCH_Wait_For_Message_Request_From_Policy_Engine State when:
- The Chunked Rx State is any other than RCH_Wait_For_Message_From_Protocol_Layer, and the Abort Flag has not been implemented.
The Chunked Tx State Machine **Shall Discard** the Message Request and enter the TCH_Report_Error State when:
- The Chunked Rx State is any other than RCH_Wait_For_Message_From_Protocol_Layer and the Abort Flag has been implemented.
###### 9.1.2.1.3.2. TCH_Pass_Down_Message State
On entry to the TCH_Pass_Down_Message State the Chunked Tx State Machine **Shall** pass the Message to the Protocol Layer.
The Chunked Tx State Machine **Shall** transition to the TCH_Wait_For_Transmision_Complete State when:
- The Message has been passed to the Protocol Layer.
###### 9.1.2.1.3.3. TCH_Wait_For_Transmision_Complete State
The Chunked Tx State Machine **Shall** transition to the TCH_Message_Sent State when:
- Message Transmitted has been received from the Protocol Layer.
The Chunked Tx State Machine **Shall** transition to the TCH_Report_Error State when:
- Transmission Error has been received from the Protocol Layer.
###### 9.1.2.1.3.4. TCH_Message_Sent State
On entry to the TCH_Message_Sent State the Chunked Tx State Machine **Shall**:
- Inform the Policy Engine that the Message has been sent.
The Chunked Tx State Machine **Shall** transition to the TCH_Wait_For_Message_Request_From_Policy_Engine State when:
- The Policy Engine has been informed.
###### 9.1.2.1.3.5. TCH_Prepare_To_Send_Chunked_Message State
On entry to the TCH_Prepare_To_Send_Chunked_Message State the Chunked Tx State Machine **Shall**:
- Set 'Chunk Number To Send' to zero.
The Chunked Tx State Machine **Shall** transition to the TCH_Construct_Chunked_Message State when:
- 'Chunk Number To Send' has been set to zero.
###### 9.1.2.1.3.6. TCH_Construct_Chunked_Message State
On entry to the TCH_Construct_Chunked_Message State the Chunked Tx State Machine **Shall**:
- Construct a Message Chunk and pass it to the Protocol Layer.
The Chunked Tx State Machine **Shall** transition to the TCH_Sending_Chunked_Message State when:
- The Message Chunk has been passed to the Protocol Layer.
<!-- page 262 -->
The Chunked Tx State Machine **Shall** transition to the TCH_Wait_For_Message_Request_From_Policy_Engine State when:
- The Abort Flag is set.
###### 9.1.2.1.3.7. TCH_Sending_Chunked_Message State
The Chunked Tx State Machine **Shall** transition to the TCH_Wait_Chunk_Request State when:
- Message Transmitted is received from Protocol Layer and this was the last Chunk.
The Chunked Tx State Machine **Shall** transition to the TCH_Message_Sent State when:
- Message Transmitted is received from Protocol Layer and this was the last Chunk.
The Chunked Tx State Machine **Shall** transition to the TCH_Report_Error State when:
- Transmission Error has been received from the Protocol Layer.
###### 9.1.2.1.3.8. TCH_Wait_Chunk_Request State
On entry to the TCH_Wait_Chunk_Request State the Chunked Tx State Machine **Shall**:
- Increment Chunk Number to Send.
- Start ChunkSenderRequestTimer.
The Chunked Tx State Machine **Shall** transition to the TCH_Report_Error State when:
- A Chunk Request has been received and the Chunk Number does not equal Chunk Number to Send or
- ChunkSenderRequestTimer has expired and Chunk Number is greater than zero.
The Chunked Tx State Machine **Shall** transition to the TCH_Message_Sent State when:
- ChunkSenderRequestTimer has expired and Chunk Number equals zero.
Note: This is the mechanism which allows the remote Port Partner or Cable Plug to omit the Chunking Layer. The Policy Engine will receive a Message Sent signal if the remote Port Partner or Cable Plug is present (GoodCRC Message received) but does not send a Chunk Request. After this the remote Port Partner will send a Not_Supported Message, or the Cable Plug will **Ignore** the Chunked Message.
The Chunked Tx State Machine **Shall** transition to the TCH_Message_Received State when:
- Any other Message than Chunk Request is received.
###### 9.1.2.1.3.9. TCH_Message_Received State
The Chunked Tx State Machine **Shall** enter the TCH_Message_Received State:
- When any Message is received, and the Chunked Tx State Machine is not in the TCH_Wait_Chunk_Request State.
On entry to the TCH_Message_Received State the Chunked Tx State Machine **Shall**:
- Clear the Extended Message Buffers.
- Pass the received Message to Chunked Rx Engine.
The Chunked Tx State Machine **Shall** transition to the TCH_Wait_For_Message_Request_From_Policy_Engine State when:
- The received Message has been passed to the Chunked Rx Engine.
<!-- page 263 -->
###### 9.1.2.1.3.10. TCH_Report_Error State
On entry to the TCH_Report_Error State the Chunked Tx State Machine **Shall**:
- Report the error to the Policy Engine.
The Chunked Tx State Machine **Shall** transition to the TCH_Wait_For_Message_Request_From_Policy_Engine State when:
- The error has been reported.
##### 9.1.2.1.4. Chunked Message Router State Diagram
Figure 9.6 shows the State behavior for the Chunked Message Router. This determines to which State machine an incoming Message is routed to (Chunked Rx, Chunked Tx or direct to Policy Engine).
**Figure 9.6. Chunked Message Router State Diagram**
![Figure 9.6. Chunked Message Router State Diagram](09-state-machine-diagrams/figure-9.6.png)
1. Doing Tx Chunks means that Chunked Tx State Machine is not in the TCH_Wait_For_Message_Request_From_Policy_Engine State.
2. Messages are taken to include notification about transmission success or otherwise of Messages.
###### 9.1.2.1.4.1. RTR_Wait_for_Message_From_Protocol_Layer State
In the RTR_Wait_for_Message_From_Protocol_Layer State the Chunked Message Router waits until the Protocol Layer sends it a received Message.
The Chunked Message Router **Shall** transition to the RTR_Rx_Chunks State when:
<!-- page 264 -->
- A Message is received from the Protocol Layer, and the combined Chunking is not doing Tx Chunks. The Chunked Message Router **Shall** transition to the RTR_Tx_Chunks State when:
- A Message is received from the Protocol Layer, and the combined Chunking is doing Tx Chunks.
###### 9.1.2.1.4.2. RTR_Rx_Chunks State
On entry to the RTR_Rx_Chunks State the Chunked Message Router **Shall**:
- Send the Message to the Chunked Rx State Machine.
- Transition to the RTR_Wait_for_Message_From_Protocol_Layer State.
###### 9.1.2.1.4.3. RTR_Tx_Chunks State
On entry to the RTR_Tx_Chunks State the Chunked Message Router **Shall**:
- Send the Message to the Chunked Tx State Machine.
- Transition to the RTR_Wait_for_Message_From_Protocol_Layer State.
#### 9.1.2.2. Protocol Layer Message Transmission
##### 9.1.2.2.1. Common Protocol Layer Message Transmission State Diagram
Figure 9.7 shows the State behavior, common between the Source and the Sink, for the Protocol Layer when transmitting a Message.
**Figure 9.7. Common Protocol Layer Message Transmission State Diagram**
![Figure 9.7. Common Protocol Layer Message Transmission State Diagram](09-state-machine-diagrams/figure-9.7.png)
1. The CRCReceiveTimer is only started after the PHY has sent the Message. If the Message is not sent due to a busy channel, then the CRCReceiveTimer will not be started (see Section 7.31.1).
<!-- page 265 -->
2. This indication is sent by the PHY Layer when a Message has been **Discarded** due to CC being busy, and after CC becomes Idle again (see Section 5.2.2). The CRCReceiveTimer is not running in this case since no Message has been sent.
3. A "small" Extended Message is either an Extended Message with Data Size ≤ MaxExtendedMsgLegacyLen bytes or an Extended Message with Data Size > MaxExtendedMsgLegacyLen bytes that has been Chunked. A "large" Extended Message is an Extended Message with Data Size > MaxExtendedMsgLegacyLen bytes that has not been Chunked.
4. See Section 7.3 for details of when Messages are **Discarded**.
###### 9.1.2.2.1.1. PRL_Tx_PHY_Layer_Reset State
The Protocol Layer **Shall** enter the PRL_Tx_PHY_Layer_Reset State:
- At startup.
- As a result of a Soft Reset Request being received by the PHY Layer.
- On exit from a Hard Reset.
On entry to the PRL_Tx_PHY_Layer_Reset State the Protocol Layer **Shall** reset the PHY Layer (clear any outstanding messages and enable communications).
The Protocol Layer **Shall** transition to the PRL_Tx_Wait_for_Message_Request State when:
- When the PHY Layer reset is complete.
###### 9.1.2.2.1.2. PRL_Tx_Wait_for_Message_Request State
In the PRL_Tx_Wait_for_Message_Request State the Protocol Layer waits until the Policy Engine directs it to send a Message.
- On entry to the PRL_Tx_Wait_for_Message_Request State the Protocol Layer **Shall** reset the RetryCounter.
The Protocol Layer **Shall** transition to the PRL_Tx_Construct_Message State when:
- A Message Request is received from the Policy Engine which is not a Soft_Reset Message. The Protocol Layer **Shall** transition to the PRL_Tx_Layer_Reset_for_Transmit State when:
- A Message Request is received from the Policy Engine which is a Soft_Reset Message.
###### 9.1.2.2.1.3. PRL_Tx_Layer_Reset_for_Transmit State
On entry to the PRL_Tx_Layer_Reset_for_Transmit State the Protocol Layer **Shall** reset the MessageIDCounter. The Protocol Layer **Shall** transition Protocol Layer Message reception to the PRL_Rx_Wait_for_PHY_Message State (see Section 9.1.2.3.1 ) in order to reset the stored MessageID.
The Protocol Layer **Shall** transition to the PRL_Tx_Construct_Message State when:
- The layer reset actions in this State have been completed.
###### 9.1.2.2.1.4. PRL_Tx_Construct_Message State
On entry to the PRL_Tx_Construct_Message State the Protocol Layer **Shall** construct the Message requested by the Policy Engine, or resend a previously constructed Message, and then pass this Message to the PHY Layer. The Protocol Layer **Shall** transition to the PRL_Tx_Wait_for_PHY_Response State when:
<!-- page 266 -->
- The Message has been sent to the PHY Layer.
###### 9.1.2.2.1.5. PRL_Tx_Wait_for_PHY_Response State
On entry to the PRL_Tx_Wait_for_PHY_Response State, once the Message has been sent, the Protocol Layer **Shall** initialize and run the CRCReceiveTimer (see Section 7.31.1). The Protocol Layer **Shall** transition to the PRL_Tx_Match_MessageID State when:
- A GoodCRC Message response is received from the PHY Layer.
The Protocol Layer **Shall** transition to the PRL_Tx_Check_RetryCounter State when:
- The CRCReceiveTimer times out.
- Or the PHY Layer indicates that a Message has been **Discarded** due to the channel being busy but the channel is now Idle (see Section 5.2.2).
###### 9.1.2.2.1.6. PRL_Tx_Match_MessageID State
On entry to the PRL_Tx_Match_MessageID State the Protocol Layer **Shall** compare the MessageIDCounter and the MessageID of the received GoodCRC Message.
The Protocol Layer **Shall** transition to the PRL_Tx_Message_Sent State when:
- The MessageIDCounter and the MessageID of the received GoodCRC Message match. The Protocol Layer **Shall** transition to the PRL_Tx_Check_RetryCounter State when:
- The MessageIDCounter and the MessageID of the received GoodCRC Message do not match.
###### 9.1.2.2.1.7. PRL_Tx_Message_Sent State
On entry to the PRL_Tx_Message_Sent State the Protocol Layer **Shall** increment the MessageIDCounter and inform the Policy Engine that the Message has been sent.
The Protocol Layer **Shall** transition to the PRL_Tx_Wait_for_Message_Request State when:
- The Policy Engine has been informed that the Message has been sent.
###### 9.1.2.2.1.8. PRL_Tx_Check_RetryCounter State
On entry to the PRL_Tx_Check_RetryCounter State the Protocol Layer in a DFP or UFP **Shall** increment the value of the RetryCounter and then check it in order to determine whether it is necessary to retry sending the Message.
Note: Cable Plugs do not retry Messages and so do not use the RetryCounter.
The Protocol Layer **Shall** transition to the PRL_Tx_Construct_Message State in order to retry Message sending when:
- RetryCounter ≤ nRetryCount and
- This is not a Cable Plug and
- This is an Extended Message with Data Size ≤ MaxExtendedMsgLegacyLen or
- This is an Extended Message that has been Chunked.
The Protocol Layer **Shall** transition to the PRL_Tx_Transmission_Error State when:
<!-- page 267 -->
- RetryCounter > nRetryCount or
- This is a Cable Plug, which does not retry.
- This is an Extended Message with Data Size > MaxExtendedMsgLegacyLen that has not been Chunked.
###### 9.1.2.2.1.9. PRL_Tx_Transmission_Error State
On entry to the PRL_Tx_Transmission_Error State the Protocol Layer **Shall** increment the MessageIDCounter and inform the Policy Engine of the transmission error.
The Protocol Layer **Shall** transition to the PRL_Tx_Wait_for_Message_Request State when:
- The Policy Engine has been informed of the transmission error.
**PRL_Tx_Discard_Message State**
Protocol Layer Message transmission **Shall** enter the PRL_Tx_Discard_Message State whenever:
- Protocol Layer Message reception receives an incoming Message or
- The Fast Role Swap Request is being transmitted (see Section 10.3 )
- The Fast Role Swap Request is detected (see Section 10.3).
On entry to the PRL_Tx_Discard_Message State, if there is a Message queued awaiting transmission, the Protocol Layer **Shall Discard** the Message according to the rules in Section 5.2.2 and increment the MessageIDCounter.
The Protocol Layer **Shall** transition to the PRL_Tx_PHY_Layer_Reset State when:
- Discarding is complete i.e., the Message queue is empty.
##### 9.1.2.2.2. Source Protocol Layer Message Transmission State Diagram
Figure 9.8 shows the State behavior for the Protocol Layer in a Source when transmitting a Message.
<!-- page 268 -->
**Figure 9.8. Source Protocol Layer Message Transmission State Diagram**
![Figure 9.8. Source Protocol Layer Message Transmission State Diagram](09-state-machine-diagrams/figure-9.8.png)
###### 9.1.2.2.2.1. PRL_Tx_Src_Sink_Tx State
In the PRL_Tx_Src_Sink_Tx State the Source sets Rp to SinkTxOK allowing the Sink to start an Atomic Message Sequence (AMS). The Protocol Layer in a Source **Shall** transition from the PRL_Tx_Wait_for_Message_Request State to the PRL_Tx_Src_Sink_Tx State when:
- A notification is received from the Policy Engine that the end of an AMS has been reached.
<!-- page 269 -->
On entry to the PRL_Tx_Src_Sink_Tx State the Protocol Layer **Shall** Request the PHY Layer to Rp to SinkTxOK. The Protocol Layer **Shall** transition to the PRL_Tx_Wait_for_Message_Request State when:
- Rp has been set.
###### 9.1.2.2.2.2. PRL_Tx_Src_Source_Tx State
In the PRL_Tx_Src_Source_Tx State the Source sets Rp to SinkTxNG allowing the Source to start an Atomic Message Sequence (AMS). The Protocol Layer in a Source **Shall** transition from the PRL_Tx_Wait_for_Message_Request State to the PRL_Tx_Src_Source_Tx State when:
- A notification is received from the Policy Engine that an AMS will be starting.
On entry to the PRL_Tx_Src_Source_Tx State the Protocol Layer **Shall** set Rp to SinkTxNG. The Protocol Layer **Shall** transition to the PRL_Tx_Src_Pending State when:
- A Message Request is received from the Policy Engine.
###### 9.1.2.2.2.3. PRL_Tx_Src_Pending State
In the PRL_Tx_Src_Pending State the Protocol Layer has a Message buffered ready for transmission. On entry to the PRL_Tx_Src_Pending State the SinkTxTimer **Shall** be initialized and run.
The Protocol Layer **Shall** transition to the PRL_Tx_Construct_Message State when:
- The pending Message Request from the Policy Engine is not a Soft_Reset Message and
- The SinkTxTimer times out.
The Protocol Layer **Shall** transition to the PRL_Tx_Layer_Reset_for_Transmit State when:
- The pending Message Request from the Policy Engine is a Soft_Reset Message and
- The SinkTxTimer times out.
##### 9.1.2.2.3. Sink Protocol Layer Message Transmission State Diagram
Figure 9.9 shows the State behavior for the Protocol Layer in a Sink when transmitting a Message.
<!-- page 270 -->
**Figure 9.9. Sink Protocol Layer Message Transmission State Diagram**
![Figure 9.9. Sink Protocol Layer Message Transmission State Diagram](09-state-machine-diagrams/figure-9.9.png)
###### 9.1.2.2.3.1. PRL_Tx_Snk_Start_of_AMS State
In the PRL_Tx_Snk_Start_of_AMS State the Protocol Layer waits for the first Message in a Sink initiated
AMS. The Protocol Layer in a Sink **Shall** transition from the PRL_Tx_Wait_for_Message_Request State to the
PRL_Tx_Snk_Start_of_AMS State when:
- A notification is received from the Policy Engine that the next Message the Sink will send is the start of an
AMS.
The Protocol Layer **Shall** transition to the PRL_Tx_Snk_Pending State when:
- A Message Request is received from the Policy Engine.
###### 9.1.2.2.3.2. PRL_Tx_Snk_Pending State
In the PRL_Tx_Snk_Pending State the Protocol Layer has the first Message in a Sink initiated AMS ready to send
and is waiting for Rp to transition to SinkTxOK before sending the Message.
The Protocol Layer **Shall** transition to the PRL_Tx_Construct_Message State when:
<!-- page 271 -->
- A Message is Pending that is not a Soft_Reset Message and
- Rp is set to SinkTxOK.
The Protocol Layer **Shall** transition to the PRL_Tx_Layer_Reset_for_Transmit State when:
- A Soft_Reset Message is pending.
#### 9.1.2.3. Protocol Layer Message Reception
Figure 9.10 shows the State behavior for the Protocol Layer when receiving a Message.
**Figure 9.10. Protocol Layer Message reception**
![Figure 9.10. Protocol Layer Message reception](09-state-machine-diagrams/figure-9.10.png)
1. This indication is sent by the PHY when a Message has been **Discarded** due to CC being busy, and after
CC becomes Idle again (see Section 5.2.2). Two alternate allowable transitions are shown.
2. In the case of a Ping Message being received, in order to maintain robust communications in the presence
of collisions, the outgoing Message **Should Not** be **Discarded**.
3. See Section 7.3 for details of when Messages are discarded.
##### 9.1.2.3.1. PRL_Rx_Wait_for_PHY_Message State
The Protocol Layer **Shall** enter the PRL_Rx_Wait_for_PHY_Message State:
- At startup.
- As a result of a Soft Reset Request from the Policy Engine.
- On exit from a Hard Reset.
<!-- page 272 -->
In the PRL_Rx_Wait_for_PHY_Message State the Protocol Layer waits until the PHY Layer passes up a received
Message.
The Protocol Layer **Shall** transition to the PRL_Rx_Send_GoodCRC State when:
- A Message is passed up from the PHY Layer.
The Protocol Layer **Shall** transition to the PRL_Rx_Layer_Reset_for_Receive State when:
- A Soft_Reset Message is received from the PHY Layer.
##### 9.1.2.3.2. PRL_Rx_Layer_Reset_for_Receive State
On entry to the PRL_Rx_Layer_Reset_for_Receive State the Protocol Layer **Shall** reset the MessageIDCounter
and clear the stored MessageID. The Protocol Layer **Shall** transition Protocol Layer Message transmission to the
PRL_Tx_Wait_for_Message_Request State (see Section 9.1.2.2.1.2 ).
The Protocol Layer **Shall** transition to the PRL_Rx_Send_GoodCRC State when:
- The Soft Reset actions in this State have been completed.
##### 9.1.2.3.3. PRL_Rx_Send_GoodCRC State
On entry to the PRL_Rx_Send_GoodCRC State the Protocol Layer **Shall** construct a GoodCRC Message and
Request the PHY Layer to transmit it. The Protocol Layer **Shall** transition to the PRL_Rx_Check_MessageID State
when:
- The GoodCRC Message has been passed to the PHY Layer.
When the PHY Layer indicates that a Message has been **Discarded** due to CC being busy but CC is now Idle (see
Section 5.2.2), the Protocol Layer **Shall** either:
- Transition to the PRL_Rx_Check_MessageID State or
- Transition to the PRL_Rx_Wait_for_PHY_Message State.
##### 9.1.2.3.4. PRL_Rx_Check_MessageID State
On entry to the PRL_Rx_Check_MessageID State the Protocol Layer **Shall** compare the MessageID of the received
Message with its stored value if a value has previously been stored.
The Protocol Layer **Shall** transition to the PRL_Rx_Wait_for_PHY_Message State when:
- The MessageID of the received Message equals the stored MessageID value since this is a Message retry
which **Shall** be **Discarded**.
The Protocol Layer **Shall** transition to the PRL_Rx_Store_MessageID State when:
- The MessageID of the received Message does not equal the stored MessageID value since this is a new
Message or
- This is the first received Message and no MessageID value is currently stored.
##### 9.1.2.3.5. PRL_Rx_Store_MessageID State
On entry to the PRL_Rx_Store_MessageID State the Protocol Layer **Shall** transition Protocol Layer Message transmission to the PRL_Tx_Discard_Message State, replace the stored value of MessageID with the value of MessageID
in the received Message and pass the Message up to the Policy Engine.
<!-- page 273 -->
The Protocol Layer **Shall** transition to the PRL_Rx_Wait_for_PHY_Message State when:
- The Message has been passed up to the Policy Engine.
#### 9.1.2.4. Hard Reset operation
Figure 9.11 shows the State behavior for the Protocol Layer when receiving a Hard Reset or Cable Reset Request
from the Policy Engine or Hard Reset Signaling or Cable Reset Signaling from the PHY Layer (see also Section 7.1.3
and Section 7.1.4).
<!-- page 274 -->
**Figure 9.11. Hard/Cable Reset**
![Figure 9.11. Hard/Cable Reset](09-state-machine-diagrams/figure-9.11.png)
<!-- page 275 -->
1. If the HardResetCompleteTimer timeout occurs this means that the PHY is still waiting to send the Hard
Reset due to a non-Idle channel. This condition will be cleared once the PE Hard Reset is completed.
2. Cable Plugs do not generate Hard Reset Signaling but are required to monitor for Hard Reset Signaling
between the Port Partners and respond by resetting.
3. Cable Reset Signaling is only recognized by a Cable Plug.
4. Cable Reset Signaling cannot be generated by Cable Plugs.
##### 9.1.2.4.1. PRL_HR_Reset_Layer State
The PRL_HR_Reset_Layer State defines the Mode of operation of both the Protocol Layer transmission and reception State machines during a Hard Reset or Cable Reset. During Hard Reset no USB Power Delivery Protocol
Messages are sent or received; only Hard Reset Signaling is present after which the communication channel is
assumed to have been disabled by the PHY Layer until completion of the Hard Reset. During Cable Reset no USB
Power Delivery Protocol Messages are sent to or received by the Cable Plug but other USB Power Delivery communication **May** continue.
The Protocol Layer **Shall** enter the PRL_HR_Reset_Layer State from any other State when:
- A Hard Reset Request is received from the Policy Engine or
- Hard Reset Signaling is received from the PHY Layer or
- A Cable Reset Request is received from the Policy Engine or
- Cable Reset Signaling is received from the PHY Layer.
On entry to the PRL_HR_Reset_Layer State the Protocol Layer **Shall** reset the MessageIDCounter. It **Shall** also
reset the states of the Protocol Layer transmission and reception State machines to their starting points. The Protocol
Layer transmission State machine **Shall** transition to the PRL_Tx_Wait_for_Message_Request State. The Protocol
Layer reception State machine **Shall** transition to the PRL_Rx_Wait_for_PHY_Message State.
The Protocol Layer **Shall** transition to the PRL_HR_Request_Hard_Reset State when:
- The Protocol Layer's reset is complete and
- The Hard Reset Request has originated from the Policy Engine or
- The Cable Reset Request has originated from the Policy Engine.
The Protocol Layer **Shall** transition to the PRL_HR_Indicate_Hard_Reset State when:
- The Protocol Layer's reset is complete and
- The Hard Reset Request has been passed up from the PHY Layer or
- A Cable Reset Request has been passed up from the PHY Layer (Cable Plug only).
##### 9.1.2.4.2. PRL_HR_Indicate_Hard_Reset State
On entry to the PRL_HR_Indicate_Hard_Reset State the Protocol Layer **Shall** indicate to the Policy Engine that
either Hard Reset Signaling or Cable Reset Signaling has been received.
The Protocol Layer **Shall** transition to the PRL_HR_Wait_for_PE_Hard_Reset_Complete State when:
- The indication to the Policy Engine has been sent.
##### 9.1.2.4.3. PRL_HR_Request_Hard_Reset State
On entry to the PRL_HR_Request_Hard_Reset State the Protocol Layer **Shall** Request the PHY Layer to send
either Hard Reset Signaling or Cable Reset Signaling.
<!-- page 276 -->
The Protocol Layer **Shall** transition to the PRL_HR_Wait_for_PHY_Hard_Reset_Complete State when:
- The PHY Layer Hard Reset Signaling Request has been sent or
- The PHY Layer Cable Reset Signaling Request has been sent.
##### 9.1.2.4.4. PRL_HR_Wait_for_PHY_Hard_Reset_Complete State
In the PRL_HR_Wait_for_PHY_Hard_Reset_Complete State the Protocol Layer **Shall** start the HardResetCompleteTimer and wait for the PHY Layer to indicate that the Hard Reset or Cable Reset has been completed.
The Protocol Layer **Shall** transition to the PRL_HR_PHY_Hard_Reset_Requested State when:
- A Hard Reset complete indication is received from the PHY Layer or
- A Cable Reset complete indication is received from the PHY Layer or
- The HardResetCompleteTimer times out.
##### 9.1.2.4.5. PRL_HR_PHY_Hard_Reset_Requested State
On entry to the PRL_HR_PHY_Hard_Reset_Requested State the Protocol Layer **Shall** inform the Policy Engine
that the PHY Layer has been requested to perform a Hard Reset or Cable Reset.
The Protocol Layer **Shall** transition to the PRL_HR_Wait_for_PE_Hard_Reset_Complete State when:
- The Indication to the Policy Engine has been sent.
##### 9.1.2.4.6. PRL_HR_Wait_for_PE_Hard_Reset_Complete State
In the PRL_HR_Wait_for_PE_Hard_Reset_Complete State the Protocol Layer **Shall** wait for the Policy Engine to
indicate that the Hard Reset or Cable Reset has been completed.
The Protocol Layer **Shall** transition to the PRL_HR_PE_Hard_Reset_Complete State when:
- A Hard Reset complete indication is received from the Policy Engine or
- A Cable Reset complete indication is received from the Policy Engine.
##### 9.1.2.4.7. PRL_HR_PE_Hard_Reset_Complete
On entry to the PRL_HR_PE_Hard_Reset_Complete State the Protocol Layer **Shall** inform the PHY Layer that the
Hard Reset or Cable Reset is complete.
The Protocol Layer **Shall** exit from the Hard Reset and return to normal operation when:
- The PHY Layer has been informed that the Hard Reset is complete so that it will re-enable the communications channel. If Hard Reset Signaling is still pending due to a non-Idle channel this **Shall** be cleared and
not sent or the PHY Layer has been informed that the Cable Reset is complete.
## 9.2. Policy Engine Layer State Diagrams
### 9.2.1. Introduction to State diagrams
The State diagrams in this section define the operation of the Power Delivery Policy Engine.
Note: These State diagrams are not intended to replace a well written and robust design.
<!-- page 277 -->
**Figure 9.12. Outline of States**
![Figure 9.12. Outline of States](09-state-machine-diagrams/figure-9.12.png)
Figure 9.12 shows an outline of the states defined in the following sections. At the top there is the name of the State.
This is followed by "Actions on entry" a list of actions carried out on entering the State. If there are also "Actions
on exit" a list of actions carried out on exiting the State, then these are listed as well; otherwise, this box is omitted
from the State. At the bottom the status of PD is listed:
- "Power" which indicates the present output power for a Source Port or input power for a Sink Port.
- "PD" which indicates the present Attachment status either "Attached", "Detached", or "unknown".
Transitions from one State to another are indicated by arrows with the conditions listed on the arrow. Where there
are multiple conditions, these are Connected using either a logical OR "|" or a logical AND "&".
In some cases, there are transitions which can occur from any State to a particular State. These are indicated by an
arrow which is unconnected to a State at one end, but with the other end (the point) Connected to the final State.
In some State diagrams it is necessary to enter or exit from states in other diagrams (e.g., Source Port or Sink Port
State diagrams). Figure 9.13 indicates how such references are made. The reference is indicated with a hatched
box. The box contains the name of the State and whether the State is a DFP or UFP. It has also been necessary
to indicate conditional entry to either Source Port or Sink Port State diagrams. This is achieved by the use of a
bulleted list indicating the preconditions (see example in Figure 9.14 ). It is also possible that the entry and return
states are the same. Figure 9.15 indicates a State reference where each referenced State corresponds to either
the entry State or the exit State.
**Figure 9.13. References to states**
![Figure 9.13. References to states](09-state-machine-diagrams/figure-9.13.png)
<!-- page 278 -->
**Figure 9.14. Example of State reference with conditions**
![Figure 9.14. Example of State reference with conditions](09-state-machine-diagrams/figure-9.14.png)
**Figure 9.15. Example of State reference with the same entry and exit**
![Figure 9.15. Example of State reference with the same entry and exit](09-state-machine-diagrams/figure-9.15.png)
Timers are included in many of the states. Timers are initialized (set to their starting condition) and run (timer is counting) in the particular State it is referenced. As soon as the State is exited then the timer is no longer active. Where the timers continue to run outside of the State (such as the `NoResponseTimer`), this is called out in the text. Timeouts of the timers are listed as conditions on State transitions.
The `SenderResponseTimer` is a special case, as it **May** be stopped and started from outside the states in which it is used. To allow this to be done without over-complicating the State diagrams, the `SenderResponseTimer` is described with its own State diagram ( Figure 9.16 ). The control of this Timer is shared between the Policy Engine and the Chunking Layer.
Conditions listed on State transitions will come from one of three sources and, when there is a conflict, **Should** be serviced in the following order:
1. Message and related indications passed up to the Policy Engine from the Protocol Layer (Message sent; Message received etc.).
2. Events triggered within the Policy Engine e.g., timer timeouts.
3. Information and requests coming from the Device Policy Manager relating either to Local Policy, or to other modules which the Device Policy Manager controls such as power supply and USB Type-C Port Control.
Note: The following State diagrams are not intended to cover all possible corner cases that could be encountered. For example, where an outgoing Message is **Discarded**, due to an incoming Message by the Protocol Layer it will be necessary for the higher layers of the system to handle a retry of the AMS that was being initiated, after first handling the incoming Message.
### 9.2.2. SenderResponseTimer State Diagram
This figure shows the State diagram for the Policy Engine in a Source Port or a Sink Port. The following sections describe operation in each of the states.
<!-- page 279 -->
**Figure 9.16. SenderResponseTimer Policy Engine State Diagram**
![Figure 9.16. SenderResponseTimer Policy Engine State Diagram](09-state-machine-diagrams/figure-9.16.png)
1. The `SR_Timer` is regarded as the mechanism within the `SenderResponseTimer` State diagram that implements the `SenderResponseTimer`.
#### 9.2.2.1. SRT_Stopped State
The `SRT_Stopped` State **Shall** be the starting State for the `SenderResponseTimer` either on power up or after a Hard Reset. On entry to this State the Policy Engine **Shall** stop incrementing the `SR_Timer`. The Policy Engine **Shall** transition to the `SRT_Running` State:
- When the `SenderResponseTimer` is started from within a Policy Engine State, or
- When a `Start_SRT` is requested from the Chunking Layer.
#### 9.2.2.2. SRT_Running State
On entry to the `SRT_Running` State the `SenderResponseTimer` State machine **Shall**:
- Set the `SR_Timer` to zero
- Start running `SR_Timer`.
<!-- page 280 -->
The `SenderResponseTimer` State machine **Shall** transition to the `SRT_Expired` State:
- When the `SR_Timer` reaches its maximum count
The `SenderResponseTimer` State machine **Shall** transition to the `SRT_Stopped` State:
- When the `SenderResponseTimer` is stopped by exiting a Policy Engine State, or
- When a `Stop_SRT` is requested from the Chunking Layer
#### 9.2.2.3. SRT_Expired State
On entry to the `SRT_Running` State the `SenderResponseTimer` State machine **Shall** Inform Policy Engine of `SenderResponseTimer` timeout.
The Policy Engine **Shall** then transition to the `SRT_Stopped` State:
- When the Policy Engine has been informed.
### 9.2.3. Policy Engine Source Port State Diagram
This figure shows the State diagram for the Policy Engine in a Source Port. The following sections describe operation in each of the states.
<!-- page 281 -->
**Figure 9.17. Source Port State Diagram**
![Figure 9.17. Source Port State Diagram](09-state-machine-diagrams/figure-9.17.png)
1. Implementation of the `CapsCounter` is **Optional**. In the case where this is not implemented the Source **Shall** continue to send Source_Capabilities Messages each time the `SourceCapabilityTimer` times out.
2. Since the Sink is required to make a **Valid** Request from the offered Capabilities the expected transition is via "Request can be met" unless the Source Capabilities have changed since the last offer.
<!-- page 282 -->
3. "Contract **Invalid**" means that the previously Negotiated voltage and Current values are no longer included in the Source's new Capabilities. If the Sink fails to make a **Valid** Request in this case, then Power Delivery operation is no longer possible and Power Delivery Mode is exited with a Hard Reset.
4. After a Power Swap the New Source is required to wait an additional `tSwapSourceStart` before sending a Source_Capabilities Message. This delay is not required when first starting up a system.
5. PD Connected is defined as a situation when the Port Partners are actively communicating. The Port Partners remain PD Connected after a Swap until there is a transition to Disabled or the connector is able to identify a Detach
6. Port Partners are no longer PD Connected after a Hard Reset, but consideration needs to be given as to whether there has been a PD Connection while the Ports have been Attached to prevent unnecessary USB Type-C Error Recovery.
7. The `DiscoverIdentityTimer` is run when this is a VCONN Source and a PD Connection with a Cable Plug needs to be established i.e. no GoodCRC Message has yet been received in response to a Discover Identity Command.
8. See Section 5.2.2, Section 7.31.13, and Section 7.2.
9. In the `PE_SRC_Wait_New_Capabilities` State the Device Policy Manager **Should** either decide to send no further Source Capabilities or **Should** send a different set of Source Capabilities. Continuing to send the same set of Source Capabilities could result in a live lock situation.
10. The `SourcePPSCommTimer` is only initialized and run when the present Explicit Contract is for a PPS APDO. Sources that do not support PPS, do not need to implement the `SourcePPSCommTimer`.
11. The `SourceEPRKeepAliveTimer` is only initialized and run when the Source is in EPR Mode; Sources that do not support EPR Mode do not need to implement the `SourceEPRKeepAliveTimer`.
12. Either SPR or EPR Sink Capabilities **May** be requested, regardless of whether or not the Source is currently operating in SPR or EPR Mode.
#### 9.2.3.1. PE_SRC_Startup State
`PE_SRC_Startup` **Shall** be the starting State for a Source Policy Engine either on power up or after a Hard Reset. On entry to this State the Policy Engine **Shall** reset the `CapsCounter` and reset the Protocol Layer.
Note: Resetting the Protocol Layer will also reset the `MessageIDCounter` and stored `MessageID`.
The Policy Engine **Shall** transition to the `PE_SRC_Send_Capabilities` State:
- When the Protocol Layer reset has completed if the `PE_SRC_Startup` State was entered due to the system first starting up.
- When the `SwapSourceStartTimer` times out if the `PE_SRC_Startup` State was entered as the result of a Power Role Swap.
Note: Sources **Shall** remain in the `PE_SRC_Startup` State, without sending any Source_Capabilities Messages until a plug is Attached.
#### 9.2.3.2. PE_SRC_Discovery State
On entry to the `PE_SRC_Discovery` State the Policy Engine **Shall** initialize and run the `SourceCapabilityTimer` in order to trigger sending a Source_Capabilities Message.
<!-- page 283 -->
The Policy Engine **Shall** transition to the `PE_SRC_Send_Capabilities` State when:
- The `SourceCapabilityTimer` times out and `CapsCounter` ≤ `nCapsCount`. The Policy Engine **May** Optionally go to the `PE_SRC_Disabled` State when:
- The Port Partners are not presently PD Connected
- And the `SourceCapabilityTimer` times out
- And `CapsCounter` > `nCapsCount`.
The Policy Engine **Shall** go to the `PE_SRC_Disabled` State when:
- The Port Partners have not been PD Connected (the Source Port remains Attached to a Port it has not had a PD Connection with during this Attachment)
- And the `NoResponseTimer` times out
- And the `HardResetCounter` > `nHardResetCount`.
Note: In the `PE_SRC_Disabled` State the Attached Device is assumed to be unresponsive. The Policy Engine operates as if the Device is Detached until such time as a Detach/Re-Attach is detected.
#### 9.2.3.3. PE_SRC_Send_Capabilities State
Note: This State can be entered from the `PE_SRC_Soft_Reset` State.
On entry to the `PE_SRC_Send_Capabilities` State the Policy Engine **Shall** Request the present Port Capabilities from the Device Policy Manager. The Policy Engine **Shall** then Request the Protocol Layer to send a Capabilities Message containing these Capabilities. The Policy Engine **Shall** Request:
- A Source_Capabilities Message if the Source is in SPR Mode or
- An EPR_Source_Capabilities Message if the Source is in EPR Mode. The Policy Engine **Shall** then increment the `CapsCounter` (if implemented). If a GoodCRC Message is received, then the Policy Engine **Shall**:
- Stop the `NoResponseTimer`.
- Reset the `HardResetCounter` and `CapsCounter` to zero.
Note: The `HardResetCounter` **Shall** only be set to zero in this State and at power up; its value **Shall** be maintained during a Hard Reset.
- Initialize and run the `SenderResponseTimer`.
Once a Source_Capabilities Message has been received and acknowledged by a GoodCRC Message, the Sink is required to then send a Request Message within `tSenderResponse`.
The Policy Engine **Shall** transition to the `PE_SRC_Negotiate_Capability` State when:
- A Request Message is received from the Sink and the Source is operating in SPR Mode or
An EPR_Request Message is received from the Sink and the Source is operating in EPR Mode. The Policy Engine **Shall** transition to the `PE_SRC_Discovery` State when:
- The Protocol Layer indicates that the Message has not been sent and we are presently not Connected. This is part of the Capabilities sending process whereby successful Message sending indicates connection to a PD Sink Port.
The Policy Engine **Shall** transition to the `PE_SRC_Hard_Reset` State when:
- The `SenderResponseTimer` times out. In this case a transition back to USB Default Operation is required.
<!-- page 284 -->
When the Port Partners have not been PD Connected (the Source Port remains Attached to a Port it has not had a PD Connection with during this Attachment), and the `NoResponseTimer` times out, and the `HardResetCounter` > `nHardResetCount`, the Policy Engine **Shall** do one of the following:
- Transition to the `PE_SRC_Discovery` State.
- Transition to the `PE_SRC_Disabled` State.
Note: That in either case the Attached Device is assumed to be unresponsive. The Policy Engine **Should** operate as if the Device is Detached until such time as a Detach/Re-Attach is detected.
The Policy Engine **Shall** go to the `ErrorRecovery` State when:
- The Port Partners have previously been PD Connected (the Source Port remains Attached to a Port it has had a PD Connection with during this Attachment)
- And, the `NoResponseTimer` times out.
- And, the `HardResetCounter` > `nHardResetCount`.
#### 9.2.3.4. PE_SRC_Negotiate_Capability State
On entry to the `PE_SRC_Negotiate_Capability` State the Policy Engine **Shall** ask the Device Policy Manager to evaluate the Request from the Attached Sink. The response from the Device Policy Manager **Shall** be one of the following:
- The Request can be met.
- The Request cannot be met
- The Request could be met later from the Power Reserve.
The Policy Engine **Shall** transition to the `PE_SRC_Transition_Supply` State when:
- The Request can be met.
The Policy Engine **Shall** transition to the `PE_SRC_Capability_Response` State when:
- The Request cannot be met.
- Or the Request can be met later from the Power Reserve.
#### 9.2.3.5. PE_SRC_Transition_Supply State
The Policy Engine **Shall** be in the `PE_SRC_Transition_Supply` State while the power supply is transitioning from one power to another. On entry to the `PE_SRC_Transition_Supply` State, the Policy Engine **Shall** Request the Protocol Layer to send an Accept Message and inform the Device Policy Manager that it **Shall** transition the power supply to the Requested power level.
Note: If the power supply is currently operating at the requested power no change will be necessary.
On exit from the `PE_SRC_Transition_Supply` State the Policy Engine **Shall** Request the Protocol Layer to send a PS_RDY Message.
The Policy Engine **Shall** transition to the `PE_SRC_Ready` State when:
The Device Policy Manager informs the Policy Engine that the power supply is ready. The Policy Engine **Shall** transition to the `PE_SRC_Hard_Reset` State when:
<!-- page 285 -->
- A Protocol Error occurs.
#### 9.2.3.6. PE_SRC_Ready State
In the `PE_SRC_Ready` State the PD Source **Shall** be operating at a stable power with no ongoing Negotiation. It **Shall** respond to requests from the Sink, events from the Device Policy Manager. On entry to the `PE_SRC_Ready` State the Source Shallnotify the Protocol Layer of the end of the Atomic Message Sequence (AMS). If the transition into `PE_SRC_Ready` is the result of Protocol Error that has not caused a Soft Reset (see Section 9.2.5.1 ) then the notification to the Protocol Layer of the end of the AMS **Shall Not** be sent since there is a Message to be processed.
On entry to the `PE_SRC_Ready` State if this is a VCONN Source which needs to establish communication with a Cable Plug, the Policy Engine **Shall**:
- Initialize and run the `DiscoverIdentityTimer` (no GoodCRC Message response yet received to Discover Identity Message).
On entry to the `PE_SRC_Ready` State if the current Explicit Contract is for a PPS APDO, then the Policy Engine
**Shall** do the following:
- Initialize and run the `SourcePPSCommTimer`.
On entry to the `PE_SRC_Ready` State if the current Explicit Contract is for EPR Mode, then the Policy Engine **Shall** do the following:
- Initialize and run the `SourceEPRKeepAliveTimer`.
On exit from the `PE_SRC_Ready`, if the Source is initiating an AMS, then the Policy Engine **Shall** notify the Protocol Layer that the first Message in an AMS will follow.
The Policy Engine **Shall** transition to the `PE_SRC_Send_Capabilities` State when:
- The Device Policy Manager indicates that Source Capabilities have changed or
- A Get_Source_Cap Message is received, and the Source is in SPR Mode or
An EPR_Get_Source_Cap Message is received, and the Source is in EPR Mode. The Policy Engine **Shall** transition to the `PE_SRC_Negotiate_Capability` State when:
- A Request Message is received, and the Source is in SPR Mode or
An EPR_Request Message is received, and the Source is in EPR Mode. The Policy Engine **Shall** transition to the `PE_SRC_Get_Sink_Cap` State when:
- The Device Policy Manager asks for the Sink Capabilities.
The Policy Engine **Shall** transition to the `PE_SRC_Hard_Reset` State when:
- The Source is operating as a PPS and the `SourcePPSCommTimer` Timer times-out or
The Source is in EPR Mode and the `SourceEPRKeepAliveTimer` Timer times-out. The Policy Engine **Shall** transition to the `PE_SRC_EPR_Keep_Alive` State when:
- An EPR_Keep_Alive Message is received.
The Policy Engine **Shall** transition to the `PE_SRC_Give_Source_Cap` State when:
<!-- page 286 -->
- In EPR Mode and a Get_Source_Cap Message is received or
- In SPR Mode and an EPR_Get_Source_Cap Message is received.
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.
#### 9.2.3.7. PE_SRC_Disabled State
In the PE_SRC_Disabled State the PD Source supplies default power and is unresponsive to USB Power Delivery messaging, but not to Hard Reset Signaling.
#### 9.2.3.8. PE_SRC_Capability_Response State
The Policy Engine **Shall** enter the PE_SRC_Capability_Response State if there is a Request received from the Sink that cannot be met based on the present Capabilities. When the present Explicit Contract is not within the present Capabilities it is regarded as **Invalid** and a Hard Reset will be triggered.
On entry to the PE_SRC_Hard_Reset State the Policy Engine **Shall** Request the Protocol Layer to send one of the following:
- Reject Message - if the Request cannot be met or the present Explicit Contract is **Invalid**.
- Wait Message - if the Request could be met later from the Power Reserve. A Wait Message **Shall Not** be sent if the present Explicit Contract is **Invalid**.
The Policy Engine **Shall** transition to the PE_SRC_Ready State when:
- There is an Explicit Contract and
- A Reject Message has been sent and the present Explicit Contract is still **Valid** or
- A Wait Message has been sent.
The Policy Engine **Shall** transition to the PE_SRC_Hard_Reset State when:
- There is an Explicit Contract and
- The Reject Message has been sent and the present Explicit Contract is **Invalid** (i.e., the Sink had to Request a new value so instead we will return to USB Default Operation).
The Policy Engine **Shall** transition to the PE_SRC_Wait_New_Capabilities State when:
- There is no Explicit Contract and
- A Reject Message has been sent or
- A Wait Message has been sent.
#### 9.2.3.9. PE_SRC_Hard_Reset State
The Policy Engine **Shall** transition to the PE_SRC_Hard_Reset State from any State when:
- Hard Reset Request from Device Policy Manager or
- In EPR Mode and a Request Message is received or
<!-- page 287 -->
- PR Capable and in SPR Mode and an EPR_Request Message is received.
On entry to the PE_SRC_Hard_Reset State the Policy Engine **Shall**:
- Request the generation of Hard Reset Signaling by the PHY Layer which might take up to tHardResetComplete.
- initialize and run the NoResponseTimer.
Note: The NoResponseTimer **Shall** continue to run in every State until it is stopped or times out.
The Policy Engine **Shall** transition to the PE_SRC_Transition_to_default State when:
- The PSHardResetTimer times out.
#### 9.2.3.10. PE_SRC_Hard_Reset_Received State
The Policy Engine **Shall** transition from any State to the PE_SRC_Hard_Reset_Received State when:
- Hard Reset Signaling is detected.
On entry to the PE_SRC_Hard_Reset_Received State the Policy Engine **Shall**:
- initialize and run the PSHardResetTimer
- initialize and run the NoResponseTimer.
Note: The NoResponseTimer **Shall** continue to run in every State until it is stopped or times out. The Policy Engine **Shall** transition to the PE_SRC_Transition_to_default State when:
- The PSHardResetTimer times out.
#### 9.2.3.11. PE_SRC_Transition_to_default State
On entry to the PE_SRC_Transition_to_default State the Policy Engine **Shall**:
- Indicate to the Device Policy Manager that the power supply **Shall** Hard Reset (see Section 4.4).
- Request a reset of the local hardware Request the Device Policy Manager to set the Port Data Role to DFP and turn off VCONN. On exit from the PE_SRC_Transition_to_default State the Policy Engine **Shall**:
- Request the Device Policy Manager to turn on VCONN inform the Protocol Layer that the Hard Reset is complete. The Policy Engine **Shall** transition to the PE_SRC_Startup State when:
- The Device Policy Manager indicates that the power supply has reached the default level.
#### 9.2.3.12. PE_SRC_Get_Sink_Cap State
In this State the Policy Engine, due to a Request from the Device Policy Manager, **Shall** Request the Capabilities from the Attached Sink. On entry to the PE_SRC_Get_Sink_Cap State the Policy Engine **Shall** Request the Protocol Layer to send a Get_Sink_Cap Message in order to retrieve the Sink Capabilities. The Policy Engine **Shall** send:
- A Get_Sink_Cap Message when the Device Policy Manager requests SPR Capabilities or
An EPR_Get_Sink_Cap Message when the Device Policy Manager requests EPR Capabilities. The Policy Engine **Shall** then start the SenderResponseTimer. On exit from the PE_SRC_Get_Sink_Cap State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (Capabilities or response timeout).
<!-- page 288 -->
The Policy Engine **Shall** transition to the PE_SRC_Ready State when:
- SPR Sink Capabilities were requested and a Sink_Capabilities Message is received or
- EPR Sink Capabilities were requested and an EPR_Sink_Capabilities Message is received or
- The SenderResponseTimer times out.
#### 9.2.3.13. PE_SRC_Wait_New_Capabilities State
In this State the Policy Engine has been unable to Negotiate an Explicit Contract and is waiting for new Capabilities from the Device Policy Manager.
The Policy Engine **Shall** transition to the PE_SRC_Send_Capabilities State when:
- The Device Policy Manager indicates that Source Capabilities have changed.
#### 9.2.3.14. PE_SRC_EPR_Keep_Alive State
On entry to the PE_SRC_EPR_Keep_Alive State the Policy Engine **Shall** send a EPR_Keep_Alive_Ack Message. The Policy Engine **Shall** transition to the PE_SRC_Ready State when:
- The EPR_Keep_Alive_Ack Message has been sent.
#### 9.2.3.15. PE_SRC_Give_Source_Cap State
On entry to the PE_SRC_Give_Source_Cap State the Policy Engine **Shall** Request the Device Policy Manager for the current system Capabilities.
The Policy Engine **Shall** then Request the Protocol Layer to send a Source Capabilities Message containing these Capabilities.
The Policy Engine **Shall** send:
- A Source_Capabilities Message when a Get_Source_Cap Message is received or
An EPR_Source_Capabilities Message when a EPR_Get_Source_Cap Message is received. The Policy Engine **Shall** transition to the PE_SNK_Ready State when:
- The Source Capabilities Message has been successfully sent.
### 9.2.4. Policy Engine Sink Port State Diagram
This figure shows the State diagram for the Policy Engine in a Sink Port. The following sections describe operation in each of the states.
<!-- page 289 -->
**Figure 9.18. Sink Port State Diagram**
![Figure 9.18. Sink Port State Diagram](09-state-machine-diagrams/figure-9.18.png)
1. Source Capabilities Messages received in States other than PE_SNK_Wait_for_Capabilities, PE_SNK_Ready or PE_SNK_Get_Source_Cap constitute a Protocol Error.
2. The SinkRequestTimer **Should Not** be stopped if a Ping (**Deprecated**) Message is received in the PE_SNK_Ready State since it represents the maximum time between requests after a Wait Message which is not reset by a Ping (**Deprecated**) Message.
<!-- page 290 -->
3. During a Hard Reset the Source voltage will transition to `vSafe0V` and then transition to `vSafe5V`. Sinks need to ensure that VBUS present is not indicated until after the Source has completed the Hard Reset process by detecting both of these transitions.
4. The DiscoverIdentityTimer is run when this is a VCONN Source and a PD Connection with a Cable Plug needs to be established i.e., no GoodCRC Message has yet been received in response to a Discover Identity Command.
5. The SinkPPSPeriodicTimer is only initialized and run when the present Explicit Contract is for a PPS APDO. Sinks that do not support PPS do not need to implement the SinkPPSPeriodicTimer.
6. A Sink that is a VPD **May** use VCONN as a proxy for VBUS.
7. To be sent once, and only required if Fast Role Swap is supported by the Sink.
#### 9.2.4.1. PE_SNK_Startup State
PE_SNK_Startup **Shall** be the starting State for a Sink Policy Engine either on power up or after a Hard Reset. On entry to this State the Policy Engine **Shall** reset the Protocol Layer.
Note: Resetting the Protocol Layer will also reset the MessageIDCounter and stored MessageID (see Section 9.1.2.3). Once the reset process completes, the Policy Engine **Shall** transition to the PE_SNK_Discovery State.
#### 9.2.4.2. PE_SNK_Discovery State
In the PE_SNK_Discovery State the Sink Policy Engine waits for VBUS to be present. The Policy Engine **Shall** transition to the PE_SNK_Wait_for_Capabilities State when:
- The Device Policy Manager indicates that VBUS has been detected.
#### 9.2.4.3. PE_SNK_Wait_for_Capabilities State
On entry to the PE_SNK_Wait_for_Capabilities State the Policy Engine **Shall** initialize and start the SinkWaitCapTimer.
The Policy Engine **Shall** transition to the PE_SNK_Evaluate_Capability State when:
- The Sink is in SPR Mode and a Source_Capabilities Message is received or
- The Sink is in EPR Mode and an EPR_Source_Capabilities Message is received.
#### 9.2.4.4. PE_SNK_Evaluate_Capability State
The PE_SNK_Evaluate_Capability State is first entered when the Sink receives its first Source_Capabilities Message from the Source. At this point the Sink knows that it is Attached to and communicating with a PD Capable Source.
On entry to the PE_SNK_Evaluate_Capability State the Policy Engine **Shall** Request the Device Policy Manager to evaluate the supplied Source Capabilities based on Local Policy. The Device Policy Manager **Shall** indicate to the Policy Engine the new power level required, selected from the present offered Capabilities. The Device Policy Manager **Shall** also indicate to the Policy Engine a Capabilities Mismatch if the offered power does not meet the Device's requirements.
The Policy Engine **Shall** transition to the PE_SNK_Select_Capability State when:
- A response is received from the Device Policy Manager.
<!-- page 291 -->
#### 9.2.4.5. PE_SNK_Select_Capability State
On entry to the PE_SNK_Select_Capability State the Policy Engine **Shall** Request the Protocol Layer to send a response Message, based on the evaluation from the Device Policy Manager. The Message **Shall** be one of the following:
- A Request from the offered Source Capabilities.
- A Request from the offered Source Capabilities with an indication that another power level would be preferred (Capability Mismatch bit set).
When in SPR Mode a Request Message **Shall** be sent.
When in EPR Mode an EPR_Request Message **Shall** be sent.
The Policy Engine **Shall** initialize and run the SenderResponseTimer.
The Policy Engine **Shall** transition to the PE_SNK_Transition_Sink State when:
- An Accept Message is received from the Source.
The Policy Engine **Shall** transition to the PE_SNK_Wait_for_Capabilities State when:
- There is no Explicit Contract in place and
- A Reject Message is received from the Source or
- A Wait Message is received from the Source.
The Policy Engine **Shall** transition to the PE_SNK_Ready State when:
- There is an SPR Explicit Contract in SPR Mode or an EPR Explicit Contract in EPR Mode and a Reject Message is received from the Source or
- There is an Explicit Contract in place and a Wait Message is received from the Source.
The Policy Engine **Shall** transition to the PE_SNK_Hard_Reset State when:
- A SenderResponseTimer timeout occurs or
- An EPR Explicit Contract has not been established in EPR Mode and a Reject Message is received from the Source.
#### 9.2.4.6. PE_SNK_Transition_Sink State
On entry to the PE_SNK_Transition_Sink State the Policy Engine **Shall** initialize and run the PSTransitionTimer (timeout will lead to a Hard Reset see Section 9.2.4.8 and **Shall** then Request the Device Policy Manager to transition the Sink's power supply to the new power level.
Note: If there is no power level change the Device Policy Manager **Should Not** affect any change to the power supply.
On exit from the PE_SNK_Transition_Sink State the Policy Engine **Shall** Request the Device Policy Manager to transition the Sink's power supply to the new power level.
The Policy Engine **Shall** transition to the PE_SNK_Ready State when:
<!-- page 292 -->
- A PS_RDY Message is received from the Source.
The Policy Engine **Shall** transition to the PE_SNK_Hard_Reset State when:
- A Protocol Error occurs.
#### 9.2.4.7. PE_SNK_Ready State
- The Device Policy Manager requests an update of the remote Source Capabilities. The Policy Engine **Shall** transition to the PE_SNK_EPR_Keep_Alive State when:
- The SinkEPRKeepAliveTimer timeouts out.
#### 9.2.4.8. PE_SNK_Hard_Reset State
The Policy Engine **Shall** transition to the PE_SNK_Hard_Reset State from any State when:
- (PSTransitionTimer times out) and
- (HardResetCounter ≤ nHardResetCount))
- Hard Reset Request from Device Policy Manager or
- In EPR Mode and
• An EPR_Source_Capabilities Message is received with an EPR PDO or APDO in object positions 1…7 or
• A Source_Capabilities Message is received that has not been requested using a Get_Source_Cap Message.
- The Policy Engine **May** transition to the PE_SNK_Hard_Reset State from any State when:
- SinkWaitCapTimer times out.
Note: If the SinkWaitCapTimer times out and the HardResetCounter is greater than nHardResetCount the Sink **Shall** assume that the Source is non-responsive.
Note: The HardResetCounter is reset on a power cycle or Detach.
On entry to the PE_SNK_Hard_Reset State the Policy Engine **Shall** Request the generation of Hard Reset Signaling by the PHY Layer and increment the HardResetCounter.
The Policy Engine **Shall** transition to the PE_SNK_Transition_to_default State when:
- The Hard Reset is complete.
#### 9.2.4.9. PE_SNK_Transition_to_default State
The Policy Engine **Shall** transition from any State to PE_SNK_Transition_to_default State when:
- Hard Reset Signaling is detected.
When Hard Reset Signaling is received or transmitted then the Policy Engine **Shall** transition from any State to PE_SNK_Transition_to_default. This State can also be entered from the PE_SNK_Hard_Reset State. On entry to the PE_SNK_Transition_to_default State the Policy Engine **Shall**:
- Indicate to the Device Policy Manager that the Sink **Shall** transition to default
- Request a reset of the local hardware
<!-- page 293 -->
- Request the Device Policy Manager that the Port Data Role is set to UFP.
The Policy Engine **Shall** transition to the PE_SNK_Startup State when:
- The Device Policy Manager indicates that the Sink has reached the default level.
#### 9.2.4.10. PE_SNK_Give_Sink_Cap State
On entry to the PE_SNK_Give_Sink_Cap State the Policy Engine **Shall** Request the Device Policy Manager for the current system Capabilities. The Policy Engine **Shall** then Request the Protocol Layer to send a Sink_Capabilities Message containing these Capabilities. The Policy Engine **Shall** send:
- A Sink_Capabilities Message when a Get_Sink_Cap Message is received or
- An EPR_Sink_Capabilities Message when a EPR_Get_Sink_Cap Message is received. The Policy Engine **Shall** transition to the PE_SNK_Ready State when:
- The Sink_Capabilities Message has been successfully sent.
#### 9.2.4.11. PE_SNK_EPR_Keep_Alive
- On entry to the PE_SNK_EPR_Keep_Alive State the Policy Engine **Shall** send an EPR_Keep_Alive Message and initialize and run the SenderResponseTimer.
The Policy Engine **Shall** transition to the PE_SNK_Ready State when:
- A EPR_Keep_Alive_Ack Message is received.
The Policy Engine **Shall** transition to the PE_SNK_Hard_Reset State when:
- The SenderResponseTimer times out.
#### 9.2.4.12. PE_SNK_Get_Source_Cap State
- On entry to the PE_SNK_Get_Source_Cap State the Policy Engine **Shall** Request the Protocol Layer to send a get Source Capabilities Message in order to retrieve the Source Capabilities. The Policy Engine **Shall** send:
- A Get_Source_Cap Message when the Device Policy Manager requests SPR Capabilities or
- An EPR_Get_Source_Cap Message when the Device Policy Manager requests EPR Capabilities. The Policy Engine **Shall** then start the SenderResponseTimer.
On exit from the PE_SNK_Get_Source_Cap State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (Capabilities or response timeout).
The Policy Engine **Shall** transition to the PE_SNK_Ready State when:
- In EPR Mode and SPR Source Capabilities were requested and a Source_Capabilities Message is received or
- In SPR Mode and EPR Source Capabilities were requested and an EPR_Source_Capabilities Message is received or
- The SenderResponseTimer times out.
The Policy Engine **Shall** transition to the PE_SNK_Evaluate_Capability State when:
- In SPR Mode and SPR Source Capabilities were requested and a Source_Capabilities Message is received or
<!-- page 294 -->
- In EPR Mode and EPR Source Capabilities were requested and an EPR_Source_Capabilities Message is received.
### 9.2.5. SOP Soft Reset and Protocol Error State Diagrams
#### 9.2.5.1. SOP Source Port Soft Reset and Protocol Error State Diagram
This figure shows the State diagram for the Policy Engine in a Source Port when performing a Soft Reset of its Port Partner i.e., using SOP. The following sections describe operation in each of the states.
**Figure 9.19. SOP Source Port Soft Reset and Protocol Error State Diagram**
![SOP Source Port Soft Reset and Protocol Error State Diagram](09-state-machine-diagrams/figure-9.19.png)
1. Excludes the Soft_Reset Message itself.
2. An Unrecognized or Unsupported Message received on SOP will result in a Not_Supported Message response being generated on SOP (see Section 9.2.7.1).
3. See Section 7.30.1 for the conditions when a Soft_Reset Message **Shall** be sent by the Source during the EPR Mode Entry process.
##### 9.2.5.1.1. PE_SRC_Send_Soft_Reset State
The PE_SRC_Send_Soft_Reset State **Shall** be entered from any State when:
- A Protocol Error on SOP is detected by the Protocol Layer during an AMS (see Section 7.1.1) or
- A Message has not been sent after retries to the Sink or
- When not in an Explicit Contract and Protocol Errors occurred on SOP during any AMS where the first Message in the AMS has not yet been sent i.e., an Unexpected Message is received instead of the expected GoodCRC Message response or
- When in SPR Mode and the EPR Mode Entry process fails. The main exceptions to this rule are when:
• The Source is in the PE_SRC_Send_Capabilities State, there is a Source_Capabilities Message sending failure on SOP (without a GoodCRC Message) and the Source is not presently Attached (as indicated in Figure 9.17 ). In this case, the PE_SRC_Discovery State is entered (see Section 9.2.3.2 ).
<!-- page 295 -->
- When the voltage is in transition due to a new Explicit Contract being Negotiated (see Section 9.2.3 ). In this case Hard Reset Signaling will be generated.
- During a Power Role Swap when the power supply is in transition (see Section 9.2.20.3 and Section 9.2.20.4 ). In this case USB Type-C Error Recovery will be triggered directly.
- During a Data Role Swap when there is a mismatch in the Port Data Role field (see Table 6.9 ). In this case USB Type-C Error Recovery will be triggered directly.
Protocol Errors occurring in the following situations **Shall Not** lead to a Soft Reset, but **Shall** result in a transition to the PE_SRC_Ready State where the Message received will be handled as if it had been received in the PE_SRC_Ready State:
- When in an Explicit Contract and Protocol Errors occurred on SOP during any AMS where the first Message in the AMS has not yet been sent i.e., an Unexpected Message is received instead of the expected GoodCRC Message response.
On entry to the PE_SRC_Send_Soft_Reset State the Policy Engine **Shall** Request the SOP Protocol Layer to perform a Soft Reset, then **Shall** send a Soft_Reset Message to the Sink on SOP, and initialize and run the SenderResponseTimer.
The Policy Engine **Shall** transition to the PE_SRC_Send_Capabilities State when:
- An Accept Message has been received on SOP.
The Policy Engine **Shall** transition to the PE_SRC_Hard_Reset State when:
- A SenderResponseTimer timeout occurs.
- Or the Protocol Layer indicates that a transmission error has occurred.
##### 9.2.5.1.2. PE_SRC_Soft_Reset State
- The PE_SRC_Soft_Reset State **Shall** be entered from any State when a Soft_Reset Message is received on SOP from the Protocol Layer.
On entry to the PE_SRC_Soft_Reset State the Policy Engine **Shall** reset the SOP Protocol Layer and **Shall** then Request the Protocol Layer to send an Accept Message on SOP.
The Policy Engine **Shall** transition to the PE_SRC_Send_Capabilities State (see Section 9.2.3.3 ) when:
- The Accept Message has been sent on SOP.
The Policy Engine **Shall** transition to the PE_SRC_Hard_Reset State when:
- The Protocol Layer indicates that a transmission error has occurred.
#### 9.2.5.2. SOP Sink Port Soft Reset and Protocol Error State Diagram
This figure shows the State diagram for the Policy Engine in a Sink Port when performing a Soft Reset of its Port Partner i.e., using SOP. The following sections describe operation in each of the states.
<!-- page 296 -->
**Figure 9.20. Sink Port Soft Reset and Protocol Error Diagram**
![Sink Port Soft Reset and Protocol Error Diagram](09-state-machine-diagrams/figure-9.20.png)
1. Excludes the Soft_Reset Message itself.
2. An Unrecognized or Unsupported Message received on SOP will result in a Not_Supported Message response being generated on SOP (see Section 9.2.7.2).
3. See Section 7.30.1 for the conditions when a Soft_Reset Message **Shall** be sent by the Source during the EPR Mode Entry process.
##### 9.2.5.2.1. PE_SNK_Send_Soft_Reset State
The PE_SNK_Send_Soft_Reset State **Shall** be entered from any State when:
- A Protocol Error on SOP is detected by the Protocol Layer during an AMS (see Section 7.1.1) or
- A Message has not been sent after retries to the Sink or
- When not in an Explicit Contract and Protocol Errors occurred on SOP during any AMS where the first Message in the AMS has not yet been sent i.e., an Unexpected Message is received instead of the expected GoodCRC Message response.
- When in SPR Mode and the EPR Mode Entry process fails. The main exceptions to this rule are when:
• When the voltage is in transition due to a new Explicit Contract being Negotiated (see Section 9.2.4 ). In this case a Hard Reset will be generated.
• During a Power Role Swap when the power supply is in transition (see Section 9.2.20.3 and Section 9.2.20.4 ). In this case a Hard Reset will be triggered directly.
• During a Data Role Swap when the DFP/UFP Data Roles are changing. In this case USB Type-C Error Recovery will be triggered directly.
Note: Protocol Errors occurring in the following situations **Shall Not** lead to a Soft Reset, but **Shall** result in a transition to the PE_SNK_Ready State where the Message received will be handled as if it had been received in the PE_SNK_Ready State:
- When in an Explicit Contract and Protocol Errors occurred on SOP during any AMS where the first Message in the AMS has not yet been sent i.e., an Unexpected Message is received instead of the expected GoodCRC Message response.
<!-- page 297 -->
On entry to the PE_SNK_Send_Soft_Reset State the Policy Engine **Shall** Request the SOP Protocol Layer to perform a Soft Reset, then **Shall** send a Soft_Reset Message on SOP to the Source, and initialize and run the SenderResponseTimer.
The Policy Engine **Shall** transition to the PE_SNK_Wait_for_Capabilities State when:
- An Accept Message has been received on SOP.
The Policy Engine **Shall** transition to the PE_SNK_Hard_Reset State when:
- A SenderResponseTimer timeout occurs.
- Or the Protocol Layer indicates that a transmission error has occurred.
##### 9.2.5.2.2. PE_SNK_Soft_Reset State
- The PE_SNK_Soft_Reset State **Shall** be entered from any State when a Soft_Reset Message is received on SOP from the Protocol Layer.
On entry to the PE_SNK_Soft_Reset State the Policy Engine **Shall** reset the SOP Protocol Layer and **Shall** then Request the Protocol Layer to send an Accept Message on SOP. The Policy Engine **Shall** transition to the PE_SNK_Wait_for_Capabilities State when:
- The Accept Message has been sent on SOP.
The Policy Engine **Shall** transition to the PE_SNK_Hard_Reset State when:
- The Protocol Layer indicates that a transmission error has occurred.
### 9.2.6. Data Reset State Diagrams
#### 9.2.6.1. DFP Data_Reset Message State Diagrams
Figure 9.21 shows the State diagram for a Data_Reset Message sent or received by a DFP.
<!-- page 298 -->
**Figure 9.21. DFP Data_Reset Message State Diagram**
![DFP Data_Reset Message State Diagram](09-state-machine-diagrams/figure-9.21.png)
1. Note: The DataResetFailTimer **Shall** continue to run in every State until it is stopped or times out.
##### 9.2.6.1.1. PE_DDR_Send_Data_Reset State
The PE_DDR_Send_Data_Reset State **Shall** be entered from the PE_SRC_Ready or PE_SNK_Ready State when requested by the Device Policy Manager.
On entry to the PE_DDR_Send_Data_Reset State the Policy Engine **Shall** Request the Protocol Layer to send a Data_Reset Message and then initialize and start the SenderResponseTimer.
On exit from the PE_DDR_Send_Data_Reset State the Policy Engine **Shall** initialize and start the DataResetFailTimer.
The Policy Engine **Shall** transition to the PE_DDR_Perform_Data_Reset State when:
- An Accept Message has been received and
- The DFP is presently the VCONN Source.
The Policy Engine **Shall** transition to the PE_DDR_Wait_For_VCONN_Off State when:
<!-- page 299 -->
- An Accept Message has been received and
- The DFP is not presently the VCONN Source.
The Policy Engine **Shall** transition to ErrorRecovery when:
- A SenderResponseTimer timeout occurs or
- A Protocol Error occurs.
##### 9.2.6.1.2. PE_DDR_Data_Reset_Received State
The PE_DDR_Data_Reset_Received State **Shall** be entered from the PE_SRC_Ready or PE_SNK_Ready State when a Data_Reset Message is received.
On entry to the PE_DDR_Data_Reset_Received State the Policy Engine **Shall** inform the Device Policy Manager and then **Shall** send an Accept Message. On exit from the PE_DDR_Data_Reset_Received State, the Policy Engine **Shall** initialize and start the DataResetFailTimer.
The Policy Engine **Shall** transition to the PE_DDR_Perform_Data_Reset State when:
- An Accept Message has been sent and
- The DFP is presently the VCONN Source.
The Policy Engine **Shall** transition to the PE_DDR_Wait_For_VCONN_Off State when:
- An Accept Message has been sent and
- The DFP is not presently the VCONN Source.
The Policy Engine **Shall** transition to ErrorRecovery when:
- A Protocol Error occurs.
##### 9.2.6.1.3. PE_DDR_Wait_For_VCONN_Off State
On entry to the PE_DDR_Wait_For_VCONN_Off State the Policy Engine **Shall** initialize and start the VCONNDischargeTimer.
The Policy Engine **Shall** transition to the PE_DDR_Perform_Data_Reset State when:
- A PS_RDY Message is received.
The Policy Engine **Shall** transition to ErrorRecovery when:
- The VCONNDischargeTimer has timed out or
- A Protocol Error occurs.
##### 9.2.6.1.4. PE_DDR_Perform_Data_Reset State
On entry to the PE_DDR_Perform_Data_Reset State the Policy Engine **Shall** Request the Device Policy Manager to complete the Data Reset process as defined in Section 7.1.2. On exit from the PE_DDR_Perform_Data_Reset State the Policy Engine **Shall** stop the DataResetFailTimer and send a Data_Reset_Complete Message.
The Policy Engine **Shall** transition back to either the PE_SRC_Ready or PE_SNK_Ready State depending on the DFP's Power Role when:
- The DPM indicates that Data Reset process is complete (see Section 7.1.2). The Policy Engine **Shall** transition to ErrorRecovery when:
<!-- page 300 -->
- The DataResetFailTimer times out
- A Protocol Error occurs.
#### 9.2.6.2. UFP Data_Reset Message State Diagrams
Figure 9.22 shows the State diagram for a Data_Reset Message sent or received by a UFP.
**Figure 9.22. UFP Data_Reset Message State Diagram**
![UFP Data_Reset Message State Diagram](09-state-machine-diagrams/figure-9.22.png)
1. VCONN **Shall** be fully discharged see Section 4.6.
2. Note: The DataResetFailUFPTimer **Shall** continue to run in every State until it is stopped or times out.
##### 9.2.6.2.1. PE_UDR_Send_Data_Reset State
The PE_UDR_Send_Data_Reset State **Shall** be entered from the PE_SRC_Ready or PE_SNK_Ready State when requested by the Device Policy Manager.
On entry to the PE_UDR_Send_Data_Reset State the Policy Engine **Shall** Request the Protocol Layer to send a Data_Reset Message and then initialize and run the SenderResponseTimer. On exit from the PE_UDR_Send_Data_Reset State the Policy Engine **Shall** initialize and run the DataResetFailUFPTimer.
<!-- page 301 -->
The Policy Engine **Shall** transition to the PE_UDR_Turn_Off_VCONN State when:
- An Accept Message has been received and
- The UFP is presently the VCONN Source.
The Policy Engine **Shall** transition to the PE_UDR_Wait_For_Data_Reset_Complete State when:
- An Accept Message has been received and
- The UFP is not presently the VCONN Source.
The Policy Engine **Shall** transition to ErrorRecovery when:
- The SenderResponseTimer has timed out or
- A Protocol Error occurs.
##### 9.2.6.2.2. PE_UDR_Data_Reset_Received State
The PE_UDR_Data_Reset_Received State **Shall** be entered from either the PE_SRC_Ready or PE_SNK_Ready State when a Data_Reset Message is received.
On entry to the PE_UDR_Data_Reset_Received State the Policy Engine **Shall** inform the Device Policy Manager and then **Shall** send an Accept Message. On exit from the PE_UDR_Data_Reset_Received State the Policy Engine **Shall** initialize and run the DataResetFailUFPTimer.
The Policy Engine **Shall** transition to the PE_UDR_Turn_Off_VCONN State when:
- An Accept Message has been sent and
- The UFP is presently the VCONN Source.
The Policy Engine **Shall** transition to the PE_UDR_Wait_For_Data_Reset_Complete State when:
- An Accept Message has been sent and
- The UFP is not presently the VCONN Source.
The Policy Engine **Shall** transition to ErrorRecovery when:
- A Protocol Error occurs.
##### 9.2.6.2.3. PE_UDR_Turn_Off_VCONN State
On entry to the PE_UDR_Turn_Off_VCONN State the Policy Engine **Shall** Request the Device Policy Manager to turn off VCONN.
The Policy Engine **Shall** transition to the PE_UDR_Send_Ps_Rdy State when:
- The DPM indicates that VCONN has been turned off (VCONN below vRaReconnect see [USB-C]). The Policy Engine **Shall** transition to ErrorRecovery when:
• A Protocol Error occurs.
##### 9.2.6.2.4. PE_UDR_Send_Ps_Rdy State
- On entry to the PE_UDR_Send_Ps_Rdy State the Policy Engine **Shall** send a PS_RDY Message. The Policy Engine **Shall** transition to the PE_UDR_Wait_For_Data_Reset_Complete State when:
<!-- page 302 -->
* The PS_RDY Message has been sent.
The Policy Engine **Shall** transition to ErrorRecovery when:
* A Protocol Error occurs.
##### 9.2.6.2.5. PE_UDR_Wait_For_Data_Reset_Complete State
* On entry to the PE_UDR_Wait_For_Data_Reset_Complete State the Policy Engine **Shall** wait for the Data_Reset_Complete Message.
On exit from the PE_UDR_Wait_For_Data_Reset_Complete State the Policy Engine **Shall** stop the DataResetFailUFPTimer.
The Policy Engine **Shall** transition back to either the PE_SRC_Ready or PE_SNK_Ready State depending on the UFP's Power Role when:
* The Data_Reset_Complete Message is received. The Policy Engine **Shall** transition to ErrorRecovery when:
* The DataResetFailUFPTimer times out or
* A Protocol Error occurs.
### 9.2.7. Not Supported Message State Diagrams
#### 9.2.7.1. Source Port Not Supported Message State Diagram
Figure 9.23 shows the State diagram for a Not_Supported Message sent or received by a Source Port.
**Figure 9.23. Source Port Not Supported Message State Diagram**
![Figure 9.23. Source Port Not Supported Message State Diagram](09-state-machine-diagrams/figure-9.23.png)
1. Transition as a result of an Unsupported Message being received in the PE_SRC_Ready State directly (see also Section 9.2.5.1).
2. Transition can only occur where a manufacturer has opted not to implement a Chunking State machine (see Section 9.1.2.1) and is communicating with a system which is attempting to send it Chunks.
##### 9.2.7.1.1. PE_SRC_Send_Not_Supported State
The PE_SRC_Send_Not_Supported State **Shall** be entered from the PE_SRC_Ready State either as the result of a Protocol Error received during an interruptible AMS or as a result of an Unsupported Message being received in
<!-- page 303 -->
the PE_SRC_Ready State directly except for the first Chunk in a multi-Chunk Message (see also Section 9.1.2.1 and Section 9.2.5.1 ).
On entry to the PE_SRC_Send_Not_Supported State (from the PE_SRC_Ready State) the Policy Engine **Shall** Request the Protocol Layer to send a Not_Supported Message.
The Policy Engine **Shall** transition back to the previous State (PE_SRC_Ready see Figure 9.17 ) when:
* The Not_Supported Message has been successfully sent.
##### 9.2.7.1.2. PE_SRC_Not_Supported_Received State
The PE_SRC_Not_Supported_Received State **Shall** be entered from the PE_SRC_Ready State when a Not_Supported Message is received.
On entry to the PE_SRC_Not_Supported_Received State the Policy Engine **Shall** inform the Device Policy Manager.
The Policy Engine **Shall** transition back to the previous State (PE_SRC_Ready see Figure 9.17 ) when:
* The Device Policy Manager has been informed.
##### 9.2.7.1.3. PE_SRC_Chunk_Received State
The PE_SRC_Chunk_Received State **Shall** be entered from the PE_SRC_Ready State as a result of an Unsupported Message being received in the PE_SRC_Ready State directly where the Message is a Chunk in a multi-Chunk Message (see also Section 9.1.2.1 and Section 9.2.5.1 ).
On entry to the PE_SRC_Chunk_Received State (from the PE_SRC_Ready State) the Policy Engine **Shall** initialize and run the ChunkingNotSupportedTimer.
The Policy Engine **Shall** transition to PE_SRC_Send_Not_Supported when:
* The ChunkingNotSupportedTimer has timed out.
#### 9.2.7.2. Sink Port Not Supported Message State Diagram
Figure 9.24 shows the State diagram for a Not_Supported Message sent or received by a Sink Port.
**Figure 9.24. Sink Port Not Supported Message State Diagram**
![Figure 9.24. Sink Port Not Supported Message State Diagram](09-state-machine-diagrams/figure-9.24.png)
1. Transition as a result of an Unsupported Message being received in the PE_SNK_Ready State directly (see also Section 9.2.5.2).
<!-- page 304 -->
2. Transition can only occur where a manufacturer has opted not to implement a Chunking State machine (see Section 9.1.2.1) and is communicating with a system which is attempting to send it Chunks.
##### 9.2.7.2.1. PE_SNK_Send_Not_Supported State
The PE_SNK_Send_Not_Supported State **Shall** be entered from the PE_SNK_Ready State either as the result of a Protocol Error received during an interruptible AMS or as a result of an Unsupported Message being received in the PE_SNK_Ready State directly except for the first Chunk in a multi-Chunk Message (see also Section 9.1.2.1 and Section 9.2.5.1 ).
On entry to the PE_SNK_Send_Not_Supported State (from the PE_SNK_Ready State) the Policy Engine **Shall** Request the Protocol Layer to send a Not_Supported Message.
The Policy Engine **Shall** transition back to the previous State (PE_SNK_Ready see Figure 9.18 ) when:
* The Not_Supported Message has been successfully sent.
##### 9.2.7.2.2. PE_SNK_Not_Supported_Received State
The PE_SNK_Not_Supported_Received State **Shall** be entered from the PE_SNK_Ready State when a Not_Supported Message is received.
On entry to the PE_SNK_Not_Supported_Received State the Policy Engine **Shall** inform the Device Policy Manager.
The Policy Engine **Shall** transition back to the previous State (PE_SNK_Ready see Figure 9.18 ) when:
* The Device Policy Manager has been informed.
##### 9.2.7.2.3. PE_SNK_Chunk_Received State
The PE_SNK_Chunk_Received State **Shall** be entered from the PE_SNK_Ready State as a result of an Unsupported Message being received in the PE_SNK_Ready State directly where the Message is a Chunk in a multi-Chunk Message (see also Section 9.1.2.1 and Section 9.2.5.1 ).
On entry to the PE_SNK_Chunk_Received State (from the PE_SNK_Ready State) the Policy Engine **Shall** initialize and run the ChunkingNotSupportedTimer.
The Policy Engine **Shall** transition to PE_SNK_Send_Not_Supported when:
* The ChunkingNotSupportedTimer has timed out.
### 9.2.8. Alert State Diagrams
#### 9.2.8.1. Source Port Source Alert State Diagram
Figure 9.25 shows the State diagram for an Alert Message sent by a Source Port.
<!-- page 305 -->
**Figure 9.25. Source Port Source Alert State Diagram**
![Figure 9.25. Source Port Source Alert State Diagram](09-state-machine-diagrams/figure-9.25.png)
##### 9.2.8.1.1. PE_SRC_Send_Source_Alert State
The PE_SRC_Send_Source_Alert State **Shall** be entered from the PE_SRC_Ready State when the Device Policy Manager indicates that there is a Source alert condition to be reported.
On entry to the PE_SRC_Send_Source_Alert State the Policy Engine **Shall** Request the Protocol Layer to send an Alert Message.
The Policy Engine **Shall** transition to the PE_SRC_Wait_for_Get_Status State when:
* The Alert Message has been successfully sent.
##### 9.2.8.1.2. PE_SRC_Wait_for_Get_Status State
On entry to the PE_SRC_Wait_for_Get_Status State the Policy Engine **Shall** initialize and run the SenderResponseTimer.
The Policy Engine **Shall** transition back to the PE_Give_Status State (see Figure 9.36 ) when:
* A Get_Status Message is received.
The Policy Engine **Shall** transition back to PE_SRC_Ready (see Figure 9.17 ) when:
* The SenderResponseTimer times out.
<!-- page 306 -->
#### 9.2.8.2. Sink Port Source Alert State Diagram
Figure 9.26 shows the State diagram for an Alert Message received by a Sink Port.
**Figure 9.26. Sink Port Source Alert State Diagram**
![Figure 9.26. Sink Port Source Alert State Diagram](09-state-machine-diagrams/figure-9.26.png)
##### 9.2.8.2.1. PE_SNK_Source_Alert_Received State
The PE_SNK_Source_Alert_Received State **Shall** be entered from the PE_SNK_Ready State when an Alert Message is received.
On entry to the PE_SNK_Source_Alert_Received State the Policy Engine **Shall** inform the Device Policy Manager of the details of the Source alert.
The Policy Engine **Shall** transition to the PE_Get_Status State (see Figure 9.35 ) when:
* The DPM requests status.
The Policy Engine **Shall** transition back to the PE_SNK_Ready State (see Figure 9.18 ) when:
* The DPM does not Request status.
#### 9.2.8.3. Sink Port Sink Alert State Diagram
Figure 9.27 shows the State diagram for an Alert Message sent by a Sink Port.
<!-- page 307 -->
**Figure 9.27. Sink Port Sink Alert State Diagram**
![Figure 9.27. Sink Port Sink Alert State Diagram](09-state-machine-diagrams/figure-9.27.png)
##### 9.2.8.3.1. PE_SNK_Send_Sink_Alert State
The PE_SNK_Send_Sink_Alert State **Shall** be entered from the PE_SNK_Ready State when the Device Policy Manager indicates that there is a Source alert condition to be reported.
On entry to the PE_SNK_Send_Sink_Alert State the Policy Engine **Shall** Request the Protocol Layer to send an Alert Message.
The Policy Engine **Shall** transition to the PE_SNK_Wait_for_Get_Status State when:
* The Alert Message has been successfully sent.
##### 9.2.8.3.2. PE_SNK_Wait_for_Get_Status State
On entry to the PE_SNK_Wait_for_Get_Status State the Policy Engine **Shall** initialize and run the SenderResponseTimer.
The Policy Engine **Shall** transition back to the PE_Give_Status State (see Figure 9.36 ) when:
* A Get_Status Message is received.
The Policy Engine **Shall** transition back to the PE_SNK_Ready (see Figure 9.18 ) when:
* The SenderResponseTimer times out.
<!-- page 308 -->
#### 9.2.8.4. Source Port Sink Alert State Diagram
Figure 9.28 shows the State diagram for an Alert Message received by a Source Port.
**Figure 9.28. Source Port Sink Alert State Diagram**
![Figure 9.28. Source Port Sink Alert State Diagram](09-state-machine-diagrams/figure-9.28.png)
##### 9.2.8.4.1. PE_SRC_Sink_Alert_Received State
The PE_SRC_Sink_Alert_Received State **Shall** be entered from the PE_SRC_Ready State when an Alert Message is received.
On entry to the PE_SRC_Sink_Alert_Received State the Policy Engine **Shall** inform the Device Policy Manager of the details of the Source alert.
The Policy Engine **Shall** transition to the PE_Get_Status State (see Figure 9.35 ) when:
* The DPM requests status.
The Policy Engine **Shall** transition back to the PE_SRC_Ready (see Figure 9.17 ) when:
* The DPM does not Request status.
### 9.2.9. Source/Sink Capabilities Extended State Diagrams
#### 9.2.9.1. Sink Port Get Source Capabilities Extended State Diagram
Figure 9.29 shows the State diagram for a Sink on receiving a Request from the Device Policy Manager to get the Port Partner's extended Source Capabilities. See also Section 7.19.2.
<!-- page 309 -->
**Figure 9.29. Sink Port Get Source Capabilities Extended State Diagram**
![Figure 9.29. Sink Port Get Source Capabilities Extended State Diagram](09-state-machine-diagrams/figure-9.29.png)
##### 9.2.9.1.1. PE_SNK_Get_Source_Cap_Ext State
The Policy Engine **Shall** transition to the PE_SNK_Get_Source_Cap_Ext State, from the PE_SNK_Ready State, due to a Request to get the remote extended Source Capabilities from the Device Policy Manager.
On entry to the PE_SNK_Get_Source_Cap_Ext State the Policy Engine **Shall** send a Get_Source_Cap_Extended Message and initialize and run the SenderResponseTimer.
On exit from the PE_SNK_Get_Source_Cap_Ext State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (Capabilities or response timeout).
The Policy Engine **Shall** transition back to the PE_SNK_Ready State (see Figure 9.18 ) when:
* A Source_Capabilities_Extended Message is received
* Or SenderResponseTimer times out.
#### 9.2.9.2. Source Give Source Capabilities Extended State Diagram
Figure 9.30 shows the State diagram for a Source on receiving a Get_Source_Cap_Extended Message. See also Section 7.19.2.
**Figure 9.30. Source Give Source Capabilities Extended State Diagram**
![Figure 9.30. Source Give Source Capabilities Extended State Diagram](09-state-machine-diagrams/figure-9.30.png)
##### 9.2.9.2.1. PE_SRC_Give_Source_Cap_Ext State
The Policy Engine **Shall** transition to the PE_SRC_Give_Source_Cap_Ext State, from the PE_SRC_Ready State, when a Get_Source_Cap_Extended Message is received.
On entry to the PE_SRC_Give_Source_Cap_Ext State the Policy Engine **Shall** Request the present extended Source Capabilities from the Device Policy Manager and then send a Source_Capabilities_Extended Message based on these Capabilities.
<!-- page 310 -->
The Policy Engine **Shall** transition back to the PE_SRC_Ready State (see Figure 9.17 ) when:
* The Source_Capabilities_Extended Message has been successfully sent.
#### 9.2.9.3. Source Port Get Sink Capabilities Extended State Diagram
Figure 9.31 shows the State diagram for a Source on receiving a Request from the Device Policy Manager to get the Port Partner's extended Sink Capabilities. See also Section 6.5.16.
**Figure 9.31. Source Port Get Sink Capabilities Extended State Diagram**
![Figure 9.31. Source Port Get Sink Capabilities Extended State Diagram](09-state-machine-diagrams/figure-9.31.png)
##### 9.2.9.3.1. PE_SRC_Get_Sink_Cap_Ext State
The Policy Engine **Shall** transition to the PE_SRC_Get_Sink_Cap_Ext State, from the PE_SRC_Ready State, due to a Request to get the remote extended Source Capabilities from the Device Policy Manager.
On entry to the PE_SRC_Get_Sink_Cap_Ext State the Policy Engine **Shall** send a Get_Sink_Cap_Extended Message and initialize and run the SenderResponseTimer.
On exit from the PE_SRC_Get_Sink_Cap_Ext State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (Capabilities or response timeout).
The Policy Engine **Shall** transition back to the PE_SRC_Ready State (see Figure 9.17 ) when:
* A Sink_Capabilities_Extended Message is received
* Or SenderResponseTimer times out.
#### 9.2.9.4. Sink Give Sink Capabilities Extended State Diagram
Figure 9.32 shows the State diagram for a Source on receiving a Get_Sink_Cap_Extended Message. See also Section 6.5.16.
**Figure 9.32. Sink Give Sink Capabilities Extended State Diagram**
![Figure 9.32. Sink Give Sink Capabilities Extended State Diagram](09-state-machine-diagrams/figure-9.32.png)
<!-- page 311 -->
##### 9.2.9.4.1. PE_SNK_Give_Sink_Cap_Ext State
The Policy Engine **Shall** transition to the PE_SNK_Give_Sink_Cap_Ext State, from the PE_SNK_Ready State, when a Get_Sink_Cap_Extended Message is received.
On entry to the PE_SNK_Give_Sink_Cap_Ext State the Policy Engine **Shall** Request the present extended Source Capabilities from the Device Policy Manager and then send a Sink_Capabilities_Extended Message based on these Capabilities.
The Policy Engine **Shall** transition back to the PE_SNK_Ready State (see Figure 9.18 ) when:
* The Sink_Capabilities_Extended Message has been successfully sent.
### 9.2.10. Source Information State Diagrams
#### 9.2.10.1. Sink Port Get Source Information State Diagram
Figure 9.33 shows the State diagram for a Sink on receiving a Request from the Device Policy Manager to get the Port Partner's Source information. See also Section 6.3.23 and Section 6.4.10.
**Figure 9.33. Sink Port Get Source Information State Diagram**
![Figure 9.33. Sink Port Get Source Information State Diagram](09-state-machine-diagrams/figure-9.33.png)
##### 9.2.10.1.1. PE_SNK_Get_Source_Info State
The Policy Engine **Shall** transition to the PE_SNK_Get_Source_Info State, from the PE_SNK_Ready State, due to a Request to get the remote Source information from the Device Policy Manager.
On entry to the PE_SNK_Get_Source_Info State the Policy Engine **Shall** send a Get_Source_Info Message and initialize and run the SenderResponseTimer.
On exit from the PE_SNK_Get_Source_Info State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (information or response timeout).
The Policy Engine **Shall** transition back to the PE_SNK_Ready State (see Figure 9.18 ) when:
* A Source_Info Message is received
* Or SenderResponseTimer times out.
#### 9.2.10.2. Source Give Source Information State Diagram
Figure 9.34 shows the State diagram for a Source on receiving a Get_Source_Info Message. See also Section 6.3.23 and Section 6.4.10.
<!-- page 312 -->
**Figure 9.34. Source Give Source Information State Diagram**
![Figure 9.34. Source Give Source Information State Diagram](09-state-machine-diagrams/figure-9.34.png)
##### 9.2.10.2.1. PE_SRC_Give_Source_Info State
The Policy Engine **Shall** transition to the PE_SRC_Give_Source_Info State, from the PE_SRC_Ready State, when a Get_Source_Info Message is received.
On entry to the PE_SRC_Give_Source_Info State the Policy Engine **Shall** Request the present Source information from the Device Policy Manager and then send a Source_Info Message based on this information.
The Policy Engine **Shall** transition back to the PE_SRC_Ready State (see Figure 9.17 ) when:
* The Source_Info Message has been successfully sent.
### 9.2.11. Status State Diagrams
#### 9.2.11.1. Get Status State Diagram
Figure 9.35 shows the State diagram for a Port on receiving a Request from the Device Policy Manager to get the Port Partner or Cable Plug's Status. See also Section 6.5.3.
**Figure 9.35. Get Status State Diagram**
![Figure 9.35. Get Status State Diagram](09-state-machine-diagrams/figure-9.35.png)
##### 9.2.11.1.1. PE_Get_Status State
The Policy Engine **Shall** transition to the PE_Get_Status State, from the PE_SRC_Ready or PE_SNK_Ready States, due to a Request to get the Port Partner or Cable Plug's status from the Device Policy Manager.
On entry to the PE_Get_Status State the Policy Engine **Shall** send a Get_Status Message and initialize and run the SenderResponseTimer.
<!-- page 313 -->
On exit from the PE_Get_Status State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (status or response timeout).
The Policy Engine **Shall** transition back to the PE_SRC_Ready or PE_SNK_Ready States as appropriate (see Figure 9.17 or Figure 9.18 ) when:
* A Status Message is received
* Or SenderResponseTimer times out.
#### 9.2.11.2. Give Status State Diagram
Figure 9.36 shows the State diagram for a Source on receiving a Get_Status Message. See also Section 6.5.3.
**Figure 9.36. Give Status State Diagram**
![Figure 9.36. Give Status State Diagram](09-state-machine-diagrams/figure-9.36.png)
##### 9.2.11.2.1. PE_Give_Status State
The Policy Engine **Shall** transition to the PE_Give_Status State, from the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready States, when a Get_Status Message is received.
On entry to the PE_Give_Status State the Policy Engine **Shall** Request the present Source status from the Device Policy Manager and then send a Status Message based on these Capabilities.
The Policy Engine **Shall** transition back to the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready States as appropriate (see Figure 9.17 , Figure 9.18 and Figure 9.88 ) when:
* The Status Message has been successfully sent.
#### 9.2.11.3. Sink Port Get Source PPS Status State Diagram
Figure 9.37 shows the State diagram for a Sink on receiving a Request from the Device Policy Manager to get the Port Partner's Source status when operating as a PPS. See also Section 6.3.20.
<!-- page 314 -->
**Figure 9.37. Sink Port Get Source PPS Status State Diagram**
![Figure 9.37. Sink Port Get Source PPS Status State Diagram](09-state-machine-diagrams/figure-9.37.png)
##### 9.2.11.3.1. PE_SNK_Get_PPS_Status State
The Policy Engine **Shall** transition to the PE_SNK_Get_PPS_Status State, from the PE_SNK_Ready State, due to a Request to get the remote Source PPS status from the Device Policy Manager.
On entry to the PE_SNK_Get_PPS_Status State the Policy Engine **Shall** send a Get_PPS_Status Message and initialize and run the SenderResponseTimer.
On exit from the PE_SNK_Get_PPS_Status State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (status or response timeout).
The Policy Engine **Shall** transition back to the PE_SNK_Ready State (see Figure 9.18 ) when:
* A PPS_Status Message is received
* Or SenderResponseTimer times out.
#### 9.2.11.4. Source Give Source PPS Status State Diagram
Figure 9.38 shows the State diagram for a Source on receiving a Get_PPS_Status Message. See also Section 6.3.20.
**Figure 9.38. Source Give Source PPS Status State Diagram**
![Figure 9.38. Source Give Source PPS Status State Diagram](09-state-machine-diagrams/figure-9.38.png)
##### 9.2.11.4.1. PE_SRC_Give_PPS_Status State
The Policy Engine **Shall** transition to the PE_SRC_Give_PPS_Status State, from the PE_SRC_Ready State, when a Get_PPS_Status Message is received.
<!-- page 315 -->
On entry to the PE_SRC_Give_PPS_Status State the Policy Engine **Shall** Request the present Source PPS status from the Device Policy Manager and then send a PPS_Status Message based on these Capabilities.
The Policy Engine **Shall** transition back to the PE_SRC_Ready State (see Figure 9.17 ) when:
* The PPS_Status Message has been successfully sent.
### 9.2.12. Battery Capabilities State Diagrams
#### 9.2.12.1. Get Battery Capabilities State Diagram
Figure 9.39 shows the State diagram for a Source or Sink on receiving a Request from the Device Policy Manager to get the Port Partner's Battery Capabilities for a specified Battery. See also Section 6.5.6.
**Figure 9.39. Get Battery Capabilities State Diagram**
![Figure 9.39. Get Battery Capabilities State Diagram](09-state-machine-diagrams/figure-9.39.png)
##### 9.2.12.1.1. PE_Get_Battery_Cap State
The Policy Engine **Shall** transition to the PE_Get_Battery_Cap State, from either the PE_SRC_Ready or PE_SNK_Ready State, due to a Request to get the remote Battery Capabilities, for a specified Battery, from the Device Policy Manager.
On entry to the PE_Get_Battery_Cap State the Policy Engine **Shall** send a Get_Battery_Cap Message and initialize and run the SenderResponseTimer.
On exit from the PE_Get_Battery_Cap State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (Capabilities or response timeout).
The Policy Engine **Shall** transition back to either the PE_SRC_Ready or PE_SNK_Ready State as appropriate (see Figure 9.17 and Figure 9.18 ) when:
* A Battery_Capabilities Message is received
* Or SenderResponseTimer times out.
#### 9.2.12.2. Give Battery Capabilities State Diagram
Figure 9.40 shows the State diagram for a Source or Sink on receiving a Get_Battery_Cap Message. See also Section 6.5.6.
<!-- page 316 -->
**Figure 9.40. Give Battery Capabilities State Diagram**
![Figure 9.40. Give Battery Capabilities State Diagram](09-state-machine-diagrams/figure-9.40.png)
##### 9.2.12.2.1. PE_Give_Battery_Cap State
The Policy Engine **Shall** transition to the PE_Give_Battery_Cap State, from either the PE_SRC_Ready or PE_SNK_Ready State, when a Get_Battery_Cap Message is received.
On entry to the PE_Give_Battery_Cap State the Policy Engine **Shall** Request the present Battery Capabilities, for the requested Battery, from the Device Policy Manager and then send a Battery_Capabilities Message based on these Capabilities.
The Policy Engine **Shall** transition back to either the PE_SRC_Ready or PE_SNK_Ready State as appropriate (see Figure 9.17 and Figure 9.18 ) when:
* The Battery_Capabilities Message has been successfully sent.
### 9.2.13. Battery Status State Diagrams
#### 9.2.13.1. Get Battery Status State Diagram
Figure 9.41 shows the State diagram for a Source or Sink on receiving a Request from the Device Policy Manager to get the Port Partner's Battery status for a specified Battery. See also Section 6.5.5.
**Figure 9.41. Get Battery Status State Diagram**
![Figure 9.41. Get Battery Status State Diagram](09-state-machine-diagrams/figure-9.41.png)
<!-- page 317 -->
##### 9.2.13.1.1. PE_Get_Battery_Status State
The Policy Engine **Shall** transition to the PE_Get_Battery_Status State, from either the PE_SRC_Ready or PE_SNK_Ready State, due to a Request to get the remote Battery status, for a specified Battery, from the Device Policy Manager.
On entry to the PE_Get_Battery_Status State the Policy Engine **Shall** send a Get_Battery_Status Message and initialize and run the SenderResponseTimer.
On exit from the PE_Get_Battery_Status State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (status or response timeout).
The Policy Engine **Shall** transition back to either the PE_SRC_Ready or PE_SNK_Ready State as appropriate (see Figure 9.17 and Figure 9.18 ) when:
* A Battery_Status Message is received
* Or SenderResponseTimer times out.
#### 9.2.13.2. Give Battery Status State Diagram
Figure 9.42 shows the State diagram for a Source or Sink on receiving a Get_Battery_Status Message. See also Section 6.5.5.
**Figure 9.42. Give Battery Status State Diagram**
![Figure 9.42. Give Battery Status State Diagram](09-state-machine-diagrams/figure-9.42.png)
##### 9.2.13.2.1. PE_Give_Battery_Status State
The Policy Engine **Shall** transition to the PE_Give_Battery_Status State, from either the PE_SRC_Ready or PE_SNK_Ready State, when a Get_Battery_Status Message is received.
On entry to the PE_Give_Battery_Status State the Policy Engine **Shall** Request the present Battery status, for the requested Battery, from the Device Policy Manager and then send a Battery_Status Message based on this status.
The Policy Engine **Shall** transition back to either the PE_SRC_Ready or PE_SNK_Ready State as appropriate (see Figure 9.17 and Figure 9.18 ) when:
* The Battery_Status Message has been successfully sent.
### 9.2.14. Manufacturer Information State Diagrams
#### 9.2.14.1. Get Manufacturer Information State Diagram
Figure 9.43 shows the State diagram for a Source or Sink on receiving a Request from the Device Policy Manager to get the Port Partner or Cable Plug's Manufacturer Information. See also Section 6.5.7.
<!-- page 318 -->
**Figure 9.43. Get Manufacturer Information State Diagram**
![Figure 9.43. Get Manufacturer Information State Diagram](09-state-machine-diagrams/figure-9.43.png)
##### 9.2.14.1.1. PE_Get_Manufacturer_Info State
The Policy Engine **Shall** transition to the PE_Get_Manufacturer_Info State, from either the PE_SRC_Ready or PE_SNK_Ready State, due to a Request to get the remote Manufacturer Information from the Device Policy Manager.
On entry to the PE_Get_Manufacturer_Info State the Policy Engine **Shall** send a Get_Manufacturer_Info Message and initialize and run the SenderResponseTimer.
On exit from the PE_Get_Manufacturer_Info State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (information or response timeout). The Policy Engine **Shall** transition back to either the PE_SRC_Ready or PE_SNK_Ready State as appropriate (see Figure 9.17 and Figure 9.18 ) when:
- A Manufacturer_Info Message is received
- Or SenderResponseTimer times out.
#### 9.2.14.2. Give Manufacturer Information State Diagram
Figure 9.44 shows the State diagram for a Source, Sink or Cable Plug on receiving a Get_Manufacturer_Info Message. See also Section 6.5.7.
**Figure 9.44. Give Manufacturer Information State Diagram**
![Figure 9.44. Give Manufacturer Information State Diagram](09-state-machine-diagrams/figure-9.44.png)
##### 9.2.14.2.1. PE_Give_Manufacturer_Info State
The Policy Engine **Shall** transition to the PE_Give_Manufacturer_Info State, from either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State, when a Get_Manufacturer_Info Message is received.
<!-- page 319 -->
On entry to the PE_Give_Manufacturer_Info State the Policy Engine **Shall** Request the manufacturer information from the Device Policy Manager and then send a Manufacturer_Info Message based on this status.
The Policy Engine **Shall** transition back to either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State as appropriate (see Figure 9.17 , Figure 9.18 and Figure 9.88 ) when:
- The Manufacturer_Info Message has been successfully sent.
### 9.2.15. Country Codes and Information State Diagrams
#### 9.2.15.1. Get Country Codes State Diagram
Figure 9.45 shows the State diagram for a Source or Sink on receiving a Request from the Device Policy Manager to get the Port Partner or Cable Plug's Country Codes. See also Section 6.3.21.
**Figure 9.45. Get Country Codes State Diagram**
![Figure 9.45. Get Country Codes State Diagram](09-state-machine-diagrams/figure-9.45.png)
##### 9.2.15.1.1. PE_Get_Country_Codes State
The Policy Engine **Shall** transition to the PE_Get_Country_Codes State, from either the PE_SRC_Ready or PE_SNK_Ready State, due to a Request to get the remote Country Codes from the Device Policy Manager.
On entry to the PE_Get_Country_Codes State the Policy Engine **Shall** send a Get_Country_Codes Message and initialize and run the SenderResponseTimer.
On exit from the PE_Get_Country_Codes State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (Country Codes or response timeout).
The Policy Engine **Shall** transition back to either the PE_SRC_Ready or PE_SNK_Ready State as appropriate (see Figure 9.17 and Figure 9.18 ) when:
- A Country_Codes Message is received
- Or SenderResponseTimer times out.
#### 9.2.15.2. Give Country Codes State Diagram
Figure 9.46 shows the State diagram for a Source or Sink on receiving a Get_Country_Codes Message. See also Section 6.3.21.
<!-- page 320 -->
**Figure 9.46. Give Country Codes State Diagram**
![Figure 9.46. Give Country Codes State Diagram](09-state-machine-diagrams/figure-9.46.png)
##### 9.2.15.2.1. PE_Give_Country_Codes State
The Policy Engine **Shall** transition to the PE_Give_Country_Codes State, from either the PE_SRC_Ready or PE_SNK_Ready State, when a Get_Country_Codes Message is received.
On entry to the PE_Give_Country_Codes State the Policy Engine **Shall** Request the country codes from the Device Policy Manager and then send a Country_Codes Message containing these codes.
The Policy Engine **Shall** transition back to either the PE_SRC_Ready or PE_SNK_Ready State as appropriate (see Figure 9.17 and Figure 9.18 ) when:
- The Country_Codes Message has been successfully sent.
#### 9.2.15.3. Get Country Information State Diagram
Figure 9.47 shows the State diagram for a Source or Sink on receiving a Request from the Device Policy Manager to get the Port Partner or Cable Plug's Country Information. See also Section 6.4.6.
**Figure 9.47. Get Country Information State Diagram**
![Figure 9.47. Get Country Information State Diagram](09-state-machine-diagrams/figure-9.47.png)
##### 9.2.15.3.1. PE_Get_Country_Info State
The Policy Engine **Shall** transition to the PE_Get_Country_Info State, from either the PE_SRC_Ready or PE_SNK_Ready State, due to a Request to get the remote Manufacturer Information from the Device Policy Manager.
On entry to the PE_Get_Country_Info State the Policy Engine **Shall** send a Get_Manufacturer_Info Message and initialize and run the SenderResponseTimer.
<!-- page 321 -->
On exit from the PE_Get_Country_Info State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (country information or response timeout).
The Policy Engine **Shall** transition back to either the PE_SRC_Ready or PE_SNK_Ready State as appropriate (see Figure 9.17 and Figure 9.18 ) when:
- A Country_Info Message is received
- Or SenderResponseTimer times out.
#### 9.2.15.4. Give Country Information State Diagram
Figure 9.48 shows the State diagram for a Source or Sink on receiving a Get_Country_Info Message. See also Section 6.4.6.
**Figure 9.48. Give Country Information State Diagram**
![Figure 9.48. Give Country Information State Diagram](09-state-machine-diagrams/figure-9.48.png)
##### 9.2.15.4.1. PE_Give_Country_Info State
The Policy Engine **Shall** transition to the PE_Give_Country_Info State, from either the PE_SRC_Ready or PE_SNK_Ready State, when a Get_Country_Info Message is received.
On entry to the PE_Give_Country_Info State the Policy Engine **Shall** Request the country information from the Device Policy Manager and then send a Country_Info Message containing this country information.
The Policy Engine **Shall** transition back to either the PE_SRC_Ready or PE_SNK_Ready State as appropriate (see Figure 9.17 and Figure 9.18 ) when:
- The Country_Info Message has been successfully sent.
### 9.2.16. Revision State Diagrams
#### 9.2.16.1. Get Revision State Diagram
Figure 9.49 shows the State diagram for a Source or Sink on receiving a Request from the Device Policy Manager to get the Port Partner or Cable Plug's Revision Information. See also Section 6.3.24 and Section 6.4.11.
<!-- page 322 -->
**Figure 9.49. Get Revision State Diagram**
![Figure 9.49. Get Revision State Diagram](09-state-machine-diagrams/figure-9.49.png)
##### 9.2.16.1.1. PE_Get_Revision State
The Policy Engine **Shall** transition to the PE_Get_Revision State, from either the PE_SRC_Ready or PE_SNK_Ready State, due to a Request to get the remote Revision Information from the Device Policy Manager.
On entry to the PE_Get_Revision State the Policy Engine **Shall** send a Get_Revision Message and initialize and run the SenderResponseTimer.
On exit from the PE_Get_Revision State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (Revision information or response timeout).
The Policy Engine **Shall** transition back to either the PE_SRC_Ready or PE_SNK_Ready State as appropriate (see Figure 9.17 and Figure 9.18 ) when:
- A Revision Message is received
- Or SenderResponseTimer times out.
#### 9.2.16.2. Give Revision State Diagram
Figure 9.50 shows the State diagram for a Source, Sink or Cable Plug on receiving a Get_Revision Message. See also Section 6.3.24 and Section 6.4.11.
**Figure 9.50. Give Revision State Diagram**
![Figure 9.50. Give Revision State Diagram](09-state-machine-diagrams/figure-9.50.png)
<!-- page 323 -->
##### 9.2.16.2.1. PE_Give_Revision State
The Policy Engine **Shall** transition to the PE_Give_Revision State, from either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State, when a Get_Revision Message is received.
On entry to the PE_Give_Revision State the Policy Engine **Shall** Request the Revision information from the Device Policy Manager and then send a Revision Message based on this information.
The Policy Engine **Shall** transition back to either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State as appropriate (see Figure 9.17 , Figure 9.18 and Figure 9.88 ) when:
- The Revision Message has been successfully sent.
### 9.2.17. Enter_USB Message State Diagrams
#### 9.2.17.1. DFP Enter_USB Message State Diagrams
Figure 9.51 shows the State diagram for an Enter_USB Message sent by a DFP.
**Figure 9.51. DFP Enter_USB Message State Diagram**
![Figure 9.51. DFP Enter_USB Message State Diagram](09-state-machine-diagrams/figure-9.51.png)
##### 9.2.17.1.1. PE_DEU_Send_Enter_USB State
The PE_DEU_Send_Enter_USB State **Shall** be entered from the PE_SRC_Ready or PE_SNK_Ready State when requested by the Device Policy Manager and the Port is operating as a DFP. On entry to the PE_DEU_Send_Enter_USB State the Policy Engine **Shall** Request the Protocol Layer to send an Enter_USB Message and then initialize and run the SenderResponseTimer.
On exit from the PE_DEU_Send_Enter_USB State the Policy Engine **Shall** inform the Device Policy Manager of the outcome: Accept Message received, Reject Message received, SenderResponseTimer timeout.
The Policy Engine **Shall** transition back to the PE_SRC_Ready or PE_SNK_Ready State depending on the Ports Power Role when:
- An Accept Message has been received or
- A Wait Message has been received or
- A Reject Message has been received
- There is a SenderResponseTimer timeout.
#### 9.2.17.2. UFP or Cable Plug Enter_USB Message State Diagrams
Figure 9.52 shows the State diagram for an Enter_USB Message received by a UFP or Cable Plug.
<!-- page 324 -->
**Figure 9.52. UFP Enter_USB Message State Diagram**
![Figure 9.52. UFP Enter_USB Message State Diagram](09-state-machine-diagrams/figure-9.52.png)
##### 9.2.17.2.1. PE_UEU_Enter_USB_Received State
The PE_UEU_Enter_USB_Received State **Shall** be entered from the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State as appropriate (see Figure 9.17, Figure 9.18 and Figure 9.88 ) when an Enter_USB Message is received and the Port is operating as a UFP or is a Cable Plug.
On entry to the PE_UEU_Enter_USB_Received State the Policy Engine **Shall** inform the Device Policy Manager. The Device Policy Manager responds with an indication of whether the Enter_USB Message is to be accepted or rejected. The Policy Engine **Shall** send either an Accept Message, a Wait Message or a Reject Message as appropriate.
The Policy Engine **Shall** transition back to the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State as appropriate when:
- Either an Accept Message, a Wait Message or a Reject Message has been sent.
### 9.2.18. Security State Diagrams
#### 9.2.18.1. Send Security Request State Diagram
Figure 9.53 shows the State diagram for a Source or Sink on receiving a Request from the Device Policy Manager to send a security Request.
**Figure 9.53. Send security Request State Diagram**
![Figure 9.53. Send security Request State Diagram](09-state-machine-diagrams/figure-9.53.png)
##### 9.2.18.1.1. PE_Send_Security_Request State
The Policy Engine **Shall** transition to the PE_Send_Security_Request State, from either the PE_SRC_Ready or PE_SNK_Ready State, due to a Request to send a security Request from the Device Policy Manager.
On entry to the PE_Send_Security_Request State the Policy Engine **Shall** send a Security_Request Message.
<!-- page 325 -->
The Policy Engine **Shall** transition back to either the PE_SRC_Ready or PE_SNK_Ready State as appropriate (see Figure 9.17 and Figure 9.18 ) when:
- The Security_Request Message has been sent.
#### 9.2.18.2. Send Security Response State Diagram
Figure 9.54 shows the State diagram for a Source, Sink or Cable Plug on receiving a Security_Request Message. See also Section 6.5.9.
**Figure 9.54. Send security response State Diagram**
![Figure 9.54. Send security response State Diagram](09-state-machine-diagrams/figure-9.54.png)
##### 9.2.18.2.1. PE_Send_Security_Response State
The Policy Engine **Shall** transition to the PE_Send_Security_Response State, from either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State, when a Security_Request Message is received.
On entry to the PE_Send_Security_Response State the Policy Engine **Shall** Request the appropriate response from the Device Policy Manager and then send a Security_Response Message based on this status.
The Policy Engine **Shall** transition back to either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State as appropriate (see Figure 9.17 , Figure 9.18 and Figure 9.88 ) when:
- The Security_Response Message has been successfully sent.
#### 9.2.18.3. Security Response Received State Diagram
Figure 9.55 shows the State diagram for a Source or Sink on receiving a Security_Response Message. See also Section 6.5.10.
**Figure 9.55. Security response received State Diagram**
![Figure 9.55. Security response received State Diagram](09-state-machine-diagrams/figure-9.55.png)
<!-- page 326 -->
##### 9.2.18.3.1. PE_Security_Response_Received State
The Policy Engine **Shall** transition to the PE_Security_Response_Received State, from either the PE_SRC_Ready or PE_SNK_Ready when a Security_Response Message is received.
On entry to the PE_Security_Response_Received State the Policy Engine **Shall** inform the Device Policy Manager of the details of the security response.
The Policy Engine **Shall** transition back to either the PE_SRC_Ready or PE_SNK_Ready State as appropriate (see Figure 9.17 , Figure 9.18 and Figure 9.88 ) when:
- The Device Policy Manager has been informed.
### 9.2.19. Firmware Update State Diagrams
#### 9.2.19.1. Send Firmware Update Request State Diagram
Figure 9.56 shows the State diagram for a Source or Sink on receiving a Request from the Device Policy Manager to send a firmware update Request.
**Figure 9.56. Send firmware update Request State Diagram**
![Figure 9.56. Send firmware update Request State Diagram](09-state-machine-diagrams/figure-9.56.png)
##### 9.2.19.1.1. PE_Send_Firmware_Update_Request State
The Policy Engine **Shall** transition to the PE_Send_Firmware_Update_Request State, from either the PE_SRC_Ready or PE_SNK_Ready State, due to a Request to send a firmware update Request from the Device Policy Manager.
On entry to the PE_Send_Firmware_Update_Request State the Policy Engine **Shall** send a Firmware_Update_Request Message.
The Policy Engine **Shall** transition back to either the PE_SRC_Ready or PE_SNK_Ready State as appropriate (see Figure 9.17 and Figure 9.18 ) when:
- The Firmware_Update_Request Message has been sent.
#### 9.2.19.2. Send Firmware Update Response State Diagram
Figure 9.57 shows the State diagram for a Source, Sink or Cable Plug on receiving a Firmware_Update_Request Message. See also Section 6.5.11.
<!-- page 327 -->
**Figure 9.57. Send firmware update response State Diagram**
![Figure 9.57. Send firmware update response State Diagram](09-state-machine-diagrams/figure-9.57.png)
##### 9.2.19.2.1. PE_Send_Firmware_Update_Response State
The Policy Engine **Shall** transition to the PE_Send_Firmware_Update_Response State, from either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State, when a Firmware_Update_Request Message is received.
On entry to the PE_Send_Firmware_Update_Response State the Policy Engine **Shall** Request the appropriate response from the Device Policy Manager and then send a Firmware_Update_Response Message based on this status.
The Policy Engine **Shall** transition back to either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State as appropriate (see Figure 9.17 , Figure 9.18 and Figure 9.88 ) when:
- The Firmware_Update_Response Message has been successfully sent.
#### 9.2.19.3. Firmware Update Response Received State Diagram
Figure 9.58 shows the State diagram for a Source or Sink on receiving a Firmware_Update_Response Message. See also Section 6.5.12.
**Figure 9.58. Firmware update response received State Diagram**
![Figure 9.58. Firmware update response received State Diagram](09-state-machine-diagrams/figure-9.58.png)
##### 9.2.19.3.1. PE_Firmware_Update_Response_Received State
The Policy Engine **Shall** transition to the PE_Firmware_Update_Response_Received State, from either the PE_SRC_Ready or PE_SNK_Ready when a Firmware_Update_Response Message is received.
On entry to the PE_Firmware_Update_Response_Received State the Policy Engine **Shall** inform the Device Policy Manager of the details of the firmware update response.
The Policy Engine **Shall** transition back to either the PE_SRC_Ready or PE_SNK_Ready State as appropriate (see Figure 9.17 , Figure 9.18 and Figure 9.88 ) when:
<!-- page 328 -->
- The Device Policy Manager has been informed.
### 9.2.20. Dual-Role Port State Diagrams
Dual-Role Ports that combine Source and Sink functionality **Shall** comprise Source and Sink Policy Engine State machines. In addition they **Shall** have the capability to perform a Power Role Swap from the PE_SRC_Ready or PE_SNK_Ready states and **Shall** return to USB Default Operation on a Hard Reset.
The State Diagrams in this section **Shall** apply to every [USB-C] DRP.
#### 9.2.20.1. DFP to UFP Data Role Swap State Diagram
Figure 9.59 shows the additional State diagram required to perform a Data Role Swap from DFP to UFP operation and the changes that **Shall** be followed for error and Hard Reset handling.
**Figure 9.59. DFP to UFP Data Role Swap State Diagram**
![Figure 9.59. DFP to UFP Data Role Swap State Diagram](09-state-machine-diagrams/figure-9.59.png)
<!-- page 329 -->
##### 9.2.20.1.1. PE_SRC_Ready or PE_SNK_Ready State
The Data Role Swap process **Shall** start only from either the PE_SRC_Ready or PE_SNK_Ready State where power is stable.
The Policy Engine **Shall** transition to the PE_DRS_DFP_UFP_Evaluate_Swap State when:
- A DR_Swap Message is received and
- There are no Active Modes (not in Modal Operation).
The Policy Engine **Shall** transition to either the PE_SRC_Hard_Reset or PE_SNK_Hard_Reset states when:
- A DR_Swap Message is received and
- There are one or more Active Modes (Modal Operation).
The Policy Engine **Shall** transition to the PE_DRS_DFP_UFP_Send_Swap State when:
- The Device Policy Manager indicates that a Data Role Swap is required.
##### 9.2.20.1.2. PE_DRS_DFP_UFP_Evaluate_Swap State
On entry to the PE_DRS_DFP_UFP_Evaluate_Swap State the Policy Engine **Shall** ask the Device Policy Manager whether a Data Role Swap can be made.
The Policy Engine **Shall** transition to the PE_DRS_DFP_UFP_Accept_Swap State when:
- The Device Policy Manager indicates that a Data Role Swap is OK.
The Policy Engine **Shall** transition to the PE_DRS_DFP_UFP_Reject_Swap State when:
- The Device Policy Manager indicates that a Data Role Swap is not OK.
- Or further evaluation of the Data Role Swap Request is needed.
##### 9.2.20.1.3. PE_DRS_DFP_UFP_Accept_Swap State
On entry to the PE_DRS_DFP_UFP_Accept_Swap State the Policy Engine **Shall** Request the Protocol Layer to send an Accept Message.
The Policy Engine **Shall** transition to the PE_DRS_DFP_UFP_Change_to_UFP State when:
- The Accept Message has been sent.
##### 9.2.20.1.4. PE_DRS_DFP_UFP_Change_to_UFP State
On entry to the PE_DRS_DFP_UFP_Change_to_UFP State the Policy Engine **Shall** Request the Device Policy Manager to change the Port from a DFP to a UFP.
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State when:
- The Device Policy Manager indicates that the Port has been changed to a UFP.
##### 9.2.20.1.5. PE_DRS_DFP_UFP_Send_Swap State
On entry to the PE_DRS_DFP_UFP_Send_Swap State the Policy Engine **Shall** Request the Protocol Layer to send a DR_Swap Message and **Shall** start the SenderResponseTimer.
<!-- page 330 -->
On exit from the PE_DRS_DFP_UFP_Send_Swap State the Policy Engine **Shall** stop the SenderResponseTimer.
The Policy Engine **Shall** continue as a DFP and **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State when:
- A Reject Message is received.
- Or a Wait Message is received.
- Or the SenderResponseTimer times out.
The Policy Engine **Shall** transition to the PE_DRS_DFP_UFP_Change_to_UFP State when:
- An Accept Message is received.
##### 9.2.20.1.6. PE_DRS_DFP_UFP_Reject_Swap State
On entry to the PE_DRS_DFP_UFP_Reject_Swap State the Policy Engine **Shall** Request the Protocol Layer to send:
- A Reject Message if the Device is unable to perform a Data Role Swap at this time.
- A Wait Message if further evaluation of the Data Role Swap Request is required.
Note: In this case it is expected that one of the Port Partners will send a DR_Swap Message at a later time (see Section 7.12.2).
The Policy Engine **Shall** continue as a DFP and **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State when:
- The Reject or Wait Message has been sent.
#### 9.2.20.2. UFP to DFP Data Role Swap State Diagram
Figure 9.60 shows the additional State diagram required to perform a Data Role Swap from DRP UFP to DFP operation and the changes that **Shall** be followed for error and Hard Reset handling.
<!-- page 331 -->
**Figure 9.60. UFP to DFP Data Role Swap State Diagram**
![Figure 9.60. UFP to DFP Data Role Swap State Diagram](09-state-machine-diagrams/figure-9.60.png)
##### 9.2.20.2.1. PE_SRC_Ready or PE_SNK_Ready State
The Data Role Swap process **Shall** start only from the either the PE_SRC_Ready or PE_SNK_Ready State where power is stable.
The Policy Engine **Shall** transition to the PE_DRS_UFP_DFP_Evaluate_Swap State when:
- A DR_Swap Message is received and
- There are no Active Modes (not in Modal Operation).
<!-- page 332 -->
The Policy Engine **Shall** transition to either the PE_SRC_Hard_Reset or PE_SNK_Hard_Reset states when:
- A DR_Swap Message is received and
- There are one or more Active Modes (Modal Operation).
The Policy Engine **Shall** transition to the PE_DRS_UFP_DFP_Send_Swap State when:
- The Device Policy Manager indicates that a Data Role Swap is required.
##### 9.2.20.2.2. PE_DRS_UFP_DFP_Evaluate_Swap State
On entry to the PE_DRS_UFP_DFP_Evaluate_Swap State the Policy Engine **Shall** ask the Device Policy Manager whether a Data Role Swap can be made.
The Policy Engine **Shall** transition to the PE_DRS_UFP_DFP_Accept_Swap State when:
- The Device Policy Manager indicates that a Data Role Swap is OK.
The Policy Engine **Shall** transition to the PE_DRS_UFP_DFP_Reject_Swap State when:
- The Device Policy Manager indicates that a Data Role Swap is not OK.
- Or further evaluation of the Data Role Swap Request is needed.
##### 9.2.20.2.3. PE_DRS_UFP_DFP_Accept_Swap State
On entry to the PE_DRS_UFP_DFP_Accept_Swap State the Policy Engine **Shall** Request the Protocol Layer to send an Accept Message.
The Policy Engine **Shall** transition to the PE_DRS_UFP_DFP_Change_to_DFP State when:
- The Accept Message has been sent.
##### 9.2.20.2.4. PE_DRS_UFP_DFP_Change_to_DFP State
On entry to the PE_DRS_UFP_DFP_Change_to_DFP State the Policy Engine **Shall** Request the Device Policy Manager to change the Port from a UFP to a DFP.
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State when:
- The Device Policy Manager indicates that the Port has been changed to a DFP.
##### 9.2.20.2.5. PE_DRS_UFP_DFP_Send_Swap State
On entry to the PE_DRS_UFP_DFP_Send_Swap State the Policy Engine **Shall** Request the Protocol Layer to send a DR_Swap Message and **Shall** start the SenderResponseTimer.
On exit from the PE_DRS_UFP_DFP_Send_Swap State the Policy Engine **Shall** stop the SenderResponseTimer.
The Policy Engine **Shall** continue as a UFP and **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State when:
- A Reject Message is received.
- Or a Wait Message is received.
<!-- page 333 -->
- Or the SenderResponseTimer times out.
The Policy Engine **Shall** transition to the PE_DRS_UFP_DFP_Change_to_DFP State when:
- An Accept Message is received.
##### 9.2.20.2.6. PE_DRS_UFP_DFP_Reject_Swap State
On entry to the PE_DRS_UFP_DFP_Reject_Swap State the Policy Engine **Shall** Request the Protocol Layer to send:
- A Reject Message if the Device is unable to perform a Data Role Swap at this time.
- A Wait Message if further evaluation of the Data Role Swap Request is required.
Note: In this case it is expected that one of the Port Partners will send a DR_Swap Message at a later time (see Section 7.12.2).
The Policy Engine **Shall** continue as a UFP and **Shall** transition to the either the PE_SRC_Ready or PE_SNK_Ready State when:
- The Reject or Wait Message has been sent.
#### 9.2.20.3. Policy Engine in Source to Sink Power Role Swap State Diagram
Dual-Role Ports that combine Source and Sink functionality **Shall** comprise Source and Sink Policy Engine State machines. In addition, they **Shall** have the capability to do a Power Role Swap from the PE_SRC_Ready State and **Shall** return to USB Default Operation on a Hard Reset.
Figure 9.61 shows the additional State diagram required to perform a Power Role Swap from Source to Sink Power Roles and the changes that **Shall** be followed for error handling.
<!-- page 334 -->
**Figure 9.61. Dual-Role Port in Source to Sink Power Role Swap State Diagram**
![Figure 9.61. Dual-Role Port in Source to Sink Power Role Swap State Diagram](09-state-machine-diagrams/figure-9.61.png)
<!-- page 335 -->
##### 9.2.20.3.1. PE_SRC_Ready State
The Power Role Swap process **Shall** start only from the PE_SRC_Ready State where power is stable. The Policy Engine **Shall** transition to the PE_PRS_SRC_SNK_Evaluate_Swap State when:
- A PR_Swap Message is received.
The Policy Engine **Shall** transition to the PE_PRS_SRC_SNK_Send_Swap State when:
- The Device Policy Manager indicates that a Power Role Swap is required.
##### 9.2.20.3.2. PE_PRS_SRC_SNK_Evaluate_Swap State
On entry to the PE_PRS_SRC_SNK_Evaluate_Swap State the Policy Engine **Shall** ask the Device Policy Manager whether a Power Role Swap can be made.
The Policy Engine **Shall** transition to the PE_PRS_SRC_SNK_Accept_Swap State when:
- The Device Policy Manager indicates that a Power Role Swap is OK.
The Policy Engine **Shall** transition to the PE_PRS_SRC_SNK_Reject_Swap State when:
- The Device Policy Manager indicates that a Power Role Swap is not OK.
- Or further evaluation of the Power Role Swap Request is needed.
##### 9.2.20.3.3. PE_PRS_SRC_SNK_Accept_Swap State
On entry to the PE_PRS_SRC_SNK_Accept_Swap State the Policy Engine **Shall** Request the Protocol Layer to send an Accept Message.
The Policy Engine **Shall** transition to the PE_PRS_SRC_SNK_Transition_to_off State when:
- The Accept Message has been sent.
##### 9.2.20.3.4. PE_PRS_SRC_SNK_Transition_to_off State
On entry to the PE_PRS_SRC_SNK_Transition_to_off State the Policy Engine **Shall** Request the Device Policy Manager to turn off the Source.
The Policy Engine **Shall** transition to the PE_PRS_SRC_SNK_Assert_Rd State when:
- The Device Policy Manager indicates that the Source has been turned off.
##### 9.2.20.3.5. PE_PRS_SRC_SNK_Assert_Rd State
On entry to the PE_PRS_SRC_SNK_Assert_Rd State the Policy Engine **Shall** Request the Device Policy Manager to change the resistor asserted on the CC wire from Rp to Rd.
The Policy Engine **Shall** transition to the PE_PRS_SRC_SNK_Wait_Source_on State when:
- The Device Policy Manager indicates that Rd is asserted.
##### 9.2.20.3.6. PE_PRS_SRC_SNK_Wait_Source_on State
On entry to the PE_PRS_SRC_SNK_Wait_Source_on State the Policy Engine **Shall** Request the Protocol Layer to send a PS_RDY Message and **Shall** start the PSSourceOnTimer.
<!-- page 336 -->
On exit from the Source off State the Policy Engine **Shall** stop the PSSourceOnTimer. The Policy Engine **Shall** transition to the PE_SNK_Startup when:
- A PS_RDY Message is received indicating that the remote Source is now supplying power. The Policy Engine **Shall** transition to the ErrorRecovery State when:
- The PSSourceOnTimer times out or
- The PS_RDY Message is not sent after retries (a GoodCRC Message has not been received).
Note: A Soft Reset **Shall Not** be initiated in this case.
##### 9.2.20.3.7. PE_PRS_SRC_SNK_Send_Swap State
- On entry to the PE_PRS_SRC_SNK_Send_Swap State the Policy Engine **Shall** Request the Protocol Layer to send a PR_Swap Message and **Shall** start the SenderResponseTimer.
On exit from the PE_PRS_SRC_SNK_Send_Swap State the Policy Engine **Shall** stop the SenderResponseTimer. The Policy Engine **Shall** transition to the PE_SRC_Ready State when:
- A Reject Message is received.
- Or a Wait Message is received.
- Or the SenderResponseTimer times out.
The Policy Engine **Shall** transition to the PE_PRS_SRC_SNK_Transition_to_off State when:
- An Accept Message is received.
##### 9.2.20.3.8. PE_PRS_SRC_SNK_Reject_Swap State
- On entry to the PE_PRS_SRC_SNK_Reject_Swap State the Policy Engine **Shall** Request the Protocol Layer to send:
- A Reject Message if the Device is unable to perform a Power Role Swap at this time.
- A Wait Message if further evaluation of the Power Role Swap Request is required.
Note: In this case it is expected that one of the Port Partners will send a PR_Swap Message at a later time (see Section 7.10.1).
The Policy Engine **Shall** transition to the PE_SRC_Ready when:
- The Reject or Wait Message has been sent.
#### 9.2.20.4. Policy Engine in Sink to Source Power Role Swap State Diagram
Dual-Role Ports that combine Sink and Source functionality **Shall** comprise Sink and Source Policy Engine State machines. In addition, they **Shall** have the capability to do a Power Role Swap from the PE_SNK_Ready State and **Shall** return to USB Default Operation on a Hard Reset.
Figure 9.62 shows the additional State diagram required to perform a Power Role Swap from Sink to Source Power Roles and the changes that **Shall** be followed for error handling.
<!-- page 337 -->
**Figure 9.62. Dual-role Port in Sink to Source Power Role Swap State Diagram**
![Figure 9.62. Dual-role Port in Sink to Source Power Role Swap State Diagram](09-state-machine-diagrams/figure-9.62.png)
<!-- page 338 -->
##### 9.2.20.4.1. PE_SNK_Ready State
The Power Role Swap process **Shall** start only from the PE_SNK_Ready State where power is stable. The Policy Engine **Shall** transition to the PE_PRS_SNK_SRC_Evaluate_Swap State when:
- A PR_Swap Message is received.
The Policy Engine **Shall** transition to the PE_PRS_SNK_SRC_Send_Swap State when:
- The Device Policy Manager indicates that a Power Role Swap is required.
##### 9.2.20.4.2. PE_PRS_SNK_SRC_Evaluate_Swap State
On entry to the PE_PRS_SNK_SRC_Send_Swap State the Policy Engine **Shall** ask the Device Policy Manager whether a Power Role Swap can be made.
The Policy Engine **Shall** transition to the PE_PRS_SNK_SRC_Accept_Swap State when:
- The Device Policy Manager indicates that a Power Role Swap is OK.
The Policy Engine **Shall** transition to the PE_PRS_SNK_SRC_Reject_Swap State when:
- The Device Policy Manager indicates that a Power Role Swap is not OK.
##### 9.2.20.4.3. PE_PRS_SNK_SRC_Accept_Swap State
On entry to the PE_PRS_SNK_SRC_Accept_Swap State the Policy Engine **Shall** Request the Protocol Layer to send an
Accept Message and **Shall** disable the Fast Role Swap receiver if this is enabled.
The Policy Engine **Shall** transition to the PE_PRS_SNK_SRC_Transition_to_off State when:
- The Accept Message has been sent.
##### 9.2.20.4.4. PE_PRS_SNK_SRC_Transition_to_off State
On entry to the PE_PRS_SNK_SRC_Transition_to_off State the Policy Engine **Shall** initialize and run the PSSourceOffTimer and then Request the Device Policy Manager to turn off the Sink. The Policy Engine **Shall** transition to the ErrorRecovery State when:
- The PSSourceOffTimer times out.
The Policy Engine **Shall** transition to the PE_PRS_SNK_SRC_Assert_Rp State when:
- A PS_RDY Message is received.
##### 9.2.20.4.5. PE_PRS_SNK_SRC_Assert_Rp State
On entry to the PE_PRS_SNK_SRC_Assert_Rp State the Policy Engine **Shall** Request the Device Policy Manager to change the resistor asserted on the CC wire from Rd to Rp.
The Policy Engine **Shall** transition to the PE_PRS_SNK_SRC_Source_on State when:
- The Device Policy Manager indicates that Rd is asserted.
<!-- page 339 -->
##### 9.2.20.4.6. PE_PRS_SNK_SRC_Source_on State
On entry to the PE_PRS_SNK_SRC_Source_on State the Policy Engine **Shall** Request the Device Policy Manager to turn on the Source.
On exit from the PE_PRS_SNK_SRC_Source_on State the Policy Engine **Shall** send a PS_RDY Message. The Policy Engine **Shall** transition to the PE_SRC_Startup State when:
- The Source Port VBUS is at vSafe5V.
The Policy Engine **Shall** transition to the ErrorRecovery State when:
- The PS_RDY Message is not sent after retries (a GoodCRC Message has not been received). A Soft Reset
**Shall Not** be initiated in this case.
##### 9.2.20.4.7. PE_PRS_SNK_SRC_Send_Swap State
On entry to the PE_PRS_SNK_SRC_Send_Swap State the Policy Engine **Shall** Request the Protocol Layer to send a PR_Swap Message and **Shall** initialize and run the SenderResponseTimer. The Policy Engine **Shall** transition to the PE_SNK_Ready State when:
- A Reject Message is received.
- Or a Wait Message is received.
- Or the SenderResponseTimer times out.
The Policy Engine **Shall** transition to the PE_PRS_SNK_SRC_Transition_to_off State when:
- An Accept Message is received.
##### 9.2.20.4.8. PE_PRS_SNK_SRC_Reject_Swap State
On entry to the PE_PRS_SNK_SRC_Reject_Swap State the Policy Engine **Shall** Request the Protocol Layer to send:
- A Reject Message if the Device is unable to perform a Power Role Swap at this time.
- A Wait Message if further evaluation of the Power Role Swap Request is required.
Note: In this case it is expected that one of the Port Partners will send a PR_Swap Message at a later time (see Section 7.10.1). The Policy Engine **Shall** transition to the PE_SNK_Ready State when:
- The Reject or Wait Message has been sent.
#### 9.2.20.5. Policy Engine in Source to Sink Fast Role Swap State Diagram
Dual-Role Ports that combine Source and Sink functionality **Shall** comprise Source and Sink Policy Engine State machines. In addition, they **Shall** have the capability to do a Power Role Swap from the PE_SRC_Ready State and **Shall** return to USB Default Operation on a Hard Reset.
Figure 9.63 shows the additional State diagram required to perform a Power Role Swap from Source to Sink Power Roles and the changes that **Shall** be followed for error handling.
<!-- page 340 -->
**Figure 9.63. Dual-Role Port in Source to Sink Power Role Swap State Diagram**
![Figure 9.63. Dual-Role Port in Source to Sink Power Role Swap State Diagram](09-state-machine-diagrams/figure-9.63.png)
##### 9.2.20.5.1. PE_SRC_Ready State
The Fast Role Swap process **Shall** start only from the PE_SRC_Ready State where power is stable. The Policy Engine **Shall** transition to the PE_FRS_SRC_SNK_Evaluate_Swap State when:
<!-- page 341 -->
- An FR_Swap Message is received.
##### 9.2.20.5.2. PE_FRS_SRC_SNK_Evaluate_Swap State
On entry to the PE_FRS_SRC_SNK_Evaluate_Swap State the Policy Engine **Shall** ask the Device Policy Manager whether Fast Role Swap has been signaled on the CC wire.
The Policy Engine **Shall** transition to the PE_FRS_SRC_SNK_Accept_Swap State when:
- The Device Policy Manager indicates that a Fast Role Swap has been signaled. The Policy Engine **Shall** transition to the PE_SRC_Hard_Reset State when:
- The Device Policy Manager indicates that a Fast Role Swap is not being signaled.
##### 9.2.20.5.3. PE_FRS_SRC_SNK_Accept_Swap State
On entry to the PE_FRS_SRC_SNK_Accept_Swap State the Policy Engine **Shall** Request the Protocol Layer to send an Accept Message.
The Policy Engine **Shall** transition to the PE_FRS_SRC_SNK_Transition_to_off State when:
- The Accept Message has been sent.
The Policy Engine **Shall** transition to the PE_SRC_Hard_Reset State when:
- The Accept Message is not sent after retries (a GoodCRC Message has not been received).
Note: A Soft Reset **Shall Not** be initiated in this case.
##### 9.2.20.5.4. PE_FRS_SRC_SNK_Transition_to_off State
On entry to the PE_FRS_SRC_SNK_Transition_to_off State the Policy Engine **Shall** wait until VBUS has discharged to vSafe5V.
The Policy Engine **Shall** transition to the PE_FRS_SRC_SNK_Assert_Rd State when:
- The Device Policy Manager indicates that VBUS has discharged to vSafe5V.
##### 9.2.20.5.5. PE_FRS_SRC_SNK_Assert_Rd State
On entry to the PE_FRS_SRC_SNK_Assert_Rd State the Policy Engine **Shall** Request the Device Policy Manager to change the resistor asserted on the CC wire from Rp to Rd.
The Policy Engine **Shall** transition to the PE_FRS_SRC_SNK_Wait_Source_on State when:
- The Device Policy Manager indicates that Rd is asserted.
##### 9.2.20.5.6. PE_FRS_SRC_SNK_Wait_Source_on State
- A PS_RDY Message is received indicating that the New Source is now applying Rp. The Policy Engine **Shall** transition to the ErrorRecovery State when:
- The PSSourceOnTimer times out or
- The PS_RDY Message is not sent after retries (a GoodCRC Message has not been received).
</content>
<!-- page 342 -->
Note: A Soft Reset **Shall Not** be initiated in this case.
#### 9.2.20.6. Policy Engine in Sink to Source Fast Role Swap State Diagram
Dual-Role Ports that combine Sink and Source functionality **Shall** comprise Sink and Source Policy Engine State machines. In addition, they **Should** have the capability to do a Fast Role Swap from the PE_SNK_Ready State and **Shall** return to USB Default Operation on a Hard Reset.
Figure 9.64 shows the additional State diagram required to perform a Fast Role Swap from Sink to Source Power Roles and the changes that **Shall** be followed for error handling.
<!-- page 343 -->
**Figure 9.64. Dual-role Port in Sink to Source Fast Role Swap State Diagram**
![Figure 9.64. Dual-role Port in Sink to Source Fast Role Swap State Diagram](09-state-machine-diagrams/figure-9.64.png)
<!-- page 344 -->
##### 9.2.20.6.1. PE_FRS_SNK_SRC_Start_AMS State
The Policy Engine **Shall** transition to the PE_FRS_SNK_SRC_Start_AMS State from any other State provided there is an Explicit Contract in place when:
- The Sink Capabilities received from the Initial Source by the Policy Engine has at least one of the Fast Role Swap bits set.
- The system has sufficient reserve power to provide the requested current to the Initial Source, as requested in the Fast Role Swap bits in the Sink Capabilities, and is willing to dedicate it to the Port
- The Device Policy Manager indicates that a Fast Role Swap signal has been detected on the CC wire.
On entry to the PE_FRS_SNK_SRC_Start_AMS State the Policy Engine **Shall** notify the Protocol Layer that the first Message in an AMS will follow.
The Policy Engine **Shall** transition to the PE_FRS_SNK_SRC_Send_Swap State when:
- The Protocol Layer has been notified.
##### 9.2.20.6.2. PE_FRS_SNK_SRC_Send_Swap State
On entry to the PE_FRS_SNK_SRC_Send_Swap State the Policy Engine **Shall** Request the Protocol Layer to send an FR_Swap Message and **Shall** initialize and run the SenderResponseTimer.
The Policy Engine **Shall** transition to the PE_FRS_SNK_SRC_Transition_to_off State when:
- An Accept Message is received.
The Policy Engine **Shall** transition to the ErrorRecovery State when:
- The SenderResponseTimer times out or
- The FR_Swap Message is not sent after retries (a GoodCRC Message has not been received). A Soft Reset **Shall Not** be initiated in this case.
##### 9.2.20.6.3. PE_FRS_SNK_SRC_Transition_to_off State
On entry to the PE_FRS_SNK_SRC_Transition_to_off State the Policy Engine **Shall** initialize and run the PSSourceOffTimer and then Request the Device Policy Manager to turn off the Sink. The Policy Engine **Shall** transition to the ErrorRecovery State when:
- The PSSourceOffTimer times out.
The Policy Engine **Shall** transition to the PE_FRS_SNK_SRC_VBUS_Applied State when:
- A PS_RDY Message is received.
##### 9.2.20.6.4. PE_FRS_SNK_SRC_VBUS_Applied State
On entry to the PE_FRS_SNK_SRC_VBUS_Applied State the Policy Engine waits for a notification from the Device Policy Manager that the local power Source has applied vSafe5V to VBUS (see Section 10.3).
Note: This could have already been applied prior to entering this State or could be applied while waiting in this State.
The Policy Engine **Shall** transition to the PE_FRS_SNK_SRC_Assert_Rp State when:
<!-- page 345 -->
- The Device Policy Manager indicates that vSafe5V is being applied.
##### 9.2.20.6.5. PE_FRS_SNK_SRC_Assert_Rp State
On entry to the PE_FRS_SNK_SRC_Assert_Rp State the Policy Engine **Shall** Request the Device Policy Manager to change the resistor asserted on the CC wire from Rd to Rp .
The Policy Engine **Shall** transition to the PE_FRS_SNK_SRC_Source_on State when:
- The Device Policy Manager indicates that Rp is asserted.
##### 9.2.20.6.6. PE_FRS_SNK_SRC_Source_on State
On entry to the PE_FRS_SNK_SRC_Source_on State the Policy Engine **Shall** Request the Device Policy Manager to turn on the Source.
On exit from the PE_FRS_SNK_SRC_Source_on State the Policy Engine **Shall** send a PS_RDY Message. The Policy Engine **Shall** transition to the PE_SRC_Startup State when:
- The PS_RDY Message has been sent.
The Policy Engine **Shall** transition to the ErrorRecovery State when:
- The PS_RDY Message is not sent after retries (a GoodCRC Message has not been received). A Soft Reset **Shall Not** be initiated in this case.
#### 9.2.20.7. Dual-Role (Source Port) Get Source Capabilities State Diagram
Figure 9.65 shows the State diagram for a Dual-Role Device, presently operating as a Source, on receiving a Request from the Device Policy Manager to get the Port Partner's Source Capabilities. See also Section 6.4.1.1.
**Figure 9.65. Dual-Role (Source) Get Source Capabilities diagram**
![Figure 9.65. Dual-Role (Source) Get Source Capabilities diagram](09-state-machine-diagrams/figure-9.65.png)
1. Either SPR or EPR Source Capabilities **May** be requested, regardless of whether or not the Source is currently operating in SPR or EPR Mode..
##### 9.2.20.7.1. PE_DR_SRC_Get_Source_Cap State
The Policy Engine **Shall** transition to the PE_DR_SRC_Get_Source_Cap State, from the PE_SRC_Ready State, due to a Request to get the remote Source Capabilities from the Device Policy Manager.
- On entry to the PE_DR_SRC_Get_Source_Cap State the Policy Engine **Shall** Request the Protocol Layer to send a get Source Capabilities Message in order to retrieve the Source Capabilities. The Policy Engine **Shall** send:
<!-- page 346 -->
- A Get_Source_Cap Message when the Device Policy Manager requests SPR Capabilities or
- An EPR_Get_Source_Cap Message when the Device Policy Manager requests EPR Capabilities. The Policy Engine **Shall** then start the SenderResponseTimer.
On exit from the PE_DR_SRC_Get_Source_Cap State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (Capabilities or response timeout).
The Policy Engine **Shall** transition back to the PE_SRC_Ready State (see Figure 9.17 ) when:
- In SPR Mode and SPR Source Capabilities were requested and a Source_Capabilities Message is received or
- In EPR Mode and EPR Source Capabilities were requested and an EPR_Source_Capabilities Message is received or
- The SenderResponseTimer times out.
#### 9.2.20.8. Dual-Role (Source Port) Give Sink Capabilities State Diagram
Figure 9.66 shows the State diagram for a Dual-Role Device, presently operating as a Source, on receiving a Get_Sink_Cap Message. See also Section 6.3.8.
**Figure 9.66. Dual-Role (Source) Give Sink Capabilities diagram**
![Figure 9.66. Dual-Role (Source) Give Sink Capabilities diagram](09-state-machine-diagrams/figure-9.66.png)
##### 9.2.20.8.1. PE_DR_SRC_Give_Sink_Cap State
The Policy Engine **Shall** transition to the PE_DR_SRC_Give_Sink_Cap State, from the PE_SRC_Ready State, when a Get_Sink_Cap Message or EPR_Get_Sink_Cap Message is received.
- On entry to the PE_DR_SRC_Give_Sink_Cap State the Policy Engine **Shall** Request the Device Policy Manager for the current system Capabilities. The Policy Engine **Shall** then Request the Protocol Layer to send a Sink_Capabilities Message containing these Capabilities. The Policy Engine **Shall** send:
- A Sink_Capabilities Message when a Get_Sink_Cap Message is received or
- An EPR_Sink_Capabilities Message when a EPR_Get_Sink_Cap Message is received.
The Policy Engine **Shall** transition back to the PE_SRC_Ready State (see Figure 9.17 ) when:
- The Sink_Capabilities Message has been successfully sent.
#### 9.2.20.9. Dual-Role (Sink Port) Get Sink Capabilities State Diagram
Figure 9.67 shows the State diagram for a Dual-Role Device, presently operating as a Sink, on receiving a Request from the Device Policy Manager to get the Port Partner's Sink Capabilities. See also Section 6.4.1.2.
<!-- page 347 -->
**Figure 9.67. Dual-Role (Sink) Get Sink Capabilities State Diagram**
![Figure 9.67. Dual-Role (Sink) Get Sink Capabilities State Diagram](09-state-machine-diagrams/figure-9.67.png)
1. Either SPR or EPR Sink Capabilities **May** be requested, regardless of whether or not the Sink is currently operating in SPR or EPR Mode..
##### 9.2.20.9.1. PE_DR_SNK_Get_Sink_Cap State
The Policy Engine **Shall** transition to the PE_DR_SNK_Get_Sink_Cap State, from the PE_SNK_Ready State, due to a Request to get the remote Source Capabilities from the Device Policy Manager.
- On entry to the PE_DR_SNK_Get_Sink_Cap State the Policy Engine **Shall** Request the Protocol Layer to send a Get_Sink_Cap Message in order to retrieve the Sink Capabilities. The Policy Engine **Shall** send:
- A Get_Sink_Cap Message when the Device Policy Manager requests SPR Capabilities or
- An EPR_Get_Sink_Cap Message when the Device Policy Manager requests EPR Capabilities. The Policy Engine **Shall** then start the SenderResponseTimer.
On exit from the PE_SRC_Get_Sink_Cap State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (Capabilities or response timeout). If Fast Role Swap is supported, Request Device Policy Manager prepare or disable 5V Source and configure the Fast Role Swap receiver based on the Fast Role Swap required USB Type- C Current bits in the received Sink Capabilities.
The Policy Engine **Shall** transition to the PE_SNK_Ready State (see Figure 9.18 ) when:
- SPR Sink Capabilities were requested and a Sink_Capabilities Message is received or
- EPR Sink Capabilities were requested and an EPR_Sink_Capabilities Message is received or
- The SenderResponseTimer times out.
#### 9.2.20.10. Dual-Role (Sink Port) Give Source Capabilities State Diagram
Figure 9.68 shows the State diagram for a Dual-Role Device, presently operating as a Sink, on receiving a Get_Source_Cap Message. See also Section 6.3.7.
<!-- page 348 -->
**Figure 9.68. Dual-Role (Sink) Give Source Capabilities State Diagram**
![Figure 9.68. Dual-Role (Sink) Give Source Capabilities State Diagram](09-state-machine-diagrams/figure-9.68.png)
##### 9.2.20.10.1. PE_DR_SNK_Give_Source_Cap State
The Policy Engine **Shall** transition to the PE_DR_SNK_Give_Source_Cap State, from the PE_SNK_Ready State, when a Get_Source_Cap Message is received.
- On entry to the PE_DR_SNK_Give_Source_Cap State the Policy Engine **Shall** Request the Device Policy Manager for the current system Capabilities. The Policy Engine **Shall** then Request the Protocol Layer to send a Source Capabilities Message containing these Capabilities.
- The Policy Engine **Shall** send:
- A Source_Capabilities Message when a Get_Source_Cap Message is received or
- An EPR_Source_Capabilities Message when a EPR_Get_Source_Cap Message is received.
The Policy Engine **Shall** transition to the PE_SNK_Ready State (see Figure 9.18 ) when:
- The Source Capabilities Message has been successfully sent.
#### 9.2.20.11. Dual-Role (Source Port) Get Source Capabilities Extended State Diagram
Figure 9.69 shows the State diagram for Dual-Role Device, presently operating as a Source, on receiving a Request from the Device Policy Manager to get the Port Partner's extended Source Capabilities. See also Section 6.5.2.
**Figure 9.69. Dual-Role (Source) Get Source Capabilities Extended State Diagram**
![Figure 9.69. Dual-Role (Source) Get Source Capabilities Extended State Diagram](09-state-machine-diagrams/figure-9.69.png)
##### 9.2.20.11.1. PE_DR_SRC_Get_Source_Cap_Ext State
The Policy Engine **Shall** transition to the PE_DR_SRC_Get_Source_Cap_Ext State, from the PE_SRC_Ready State, due to a Request to get the remote extended Source Capabilities from the Device Policy Manager.
<!-- page 349 -->
On entry to the PE_DR_SRC_Get_Source_Cap_Ext State the Policy Engine **Shall** send a Get_Source_Cap_Extended Message and initialize and run the SenderResponseTimer.
On exit from the PE_DR_SRC_Get_Source_Cap_Ext State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (Capabilities or response timeout).
The Policy Engine **Shall** transition back to the PE_SRC_Ready State (see Figure 9.17 ) when:
- A Source_Capabilities_Extended Message is received
- Or SenderResponseTimer times out.
#### 9.2.20.12. Dual-Role (Sink Port) Give Source Capabilities Extended State Diagram
Figure 9.68 shows the State diagram for a Dual-Role Device, presently operating as a Sink, on receiving a Get_Source_Cap_Extended Message. See also Section 7.19.2.
**Figure 9.70. Dual-Role (Sink) Give Source Capabilities Extended diagram**
![Figure 9.70. Dual-Role (Sink) Give Source Capabilities Extended diagram](09-state-machine-diagrams/figure-9.70.png)
##### 9.2.20.12.1. PE_DR_SNK_Give_Source_Cap_Ext State
The Policy Engine **Shall** transition to the PE_DR_SNK_Give_Source_Cap_Ext State, from the PE_SNK_Ready State, when a Get_Source_Cap_Extended Message is received.
On entry to the PE_DR_SNK_Give_Source_Cap_Ext State the Policy Engine **Shall** Request the present extended Source Capabilities from the Device Policy Manager and then send a Source_Capabilities_Extended Message based on these Capabilities.
The Policy Engine **Shall** transition back to the PE_SNK_Ready State (see Figure 9.18 ) when:
- The Source_Capabilities_Extended Message has been successfully sent.
#### 9.2.20.13. Dual-Role (Sink Port) Get Sink Capabilities Extended State Diagram
Figure 9.67 shows the State diagram for a Dual-Role Device, presently operating as a Sink, on receiving a Request from the Device Policy Manager to get the Port Partner's extended Sink Capabilities. See also Section 6.5.16.
<!-- page 350 -->
**Figure 9.71. Dual-Role (Sink) Get Sink Capabilities Extended State Diagram**
![Figure 9.71. Dual-Role (Sink) Get Sink Capabilities Extended State Diagram](09-state-machine-diagrams/figure-9.71.png)
##### 9.2.20.13.1. PE_DR_SNK_Get_Sink_Cap_Ext State
The Policy Engine **Shall** transition to the PE_DR_SNK_Get_Sink_Cap_Ext State, from the PE_SNK_Ready State, due to a Request to get the remote extended Source Capabilities from the Device Policy Manager.
On entry to the PE_DR_SNK_Get_Sink_Cap_Ext State the Policy Engine **Shall** send a Get_Sink_Cap_Extended Message and initialize and run the SenderResponseTimer.
On exit from the PE_DR_SNK_Get_Sink_Cap_Ext State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (Capabilities or response timeout).
The Policy Engine **Shall** transition back to the PE_SNK_Ready State (see Figure 9.18 ) when:
- A Sink_Capabilities_Extended Message is received.
- Or SenderResponseTimer times out.
#### 9.2.20.14. Dual-Role (Source Port) Give Sink Capabilities Extended State Diagram
Figure 9.72 shows the State diagram for a Dual-Role Device, presently operating as a Sink, on receiving a Get_Sink_Cap_Extended Message. See also Section 6.5.16.
**Figure 9.72. Dual-Role (Source) Give Sink Capabilities Extended diagram**
![Figure 9.72. Dual-Role (Source) Give Sink Capabilities Extended diagram](09-state-machine-diagrams/figure-9.72.png)
##### 9.2.20.14.1. PE_DR_SRC_Give_Sink_Cap_Ext State
The Policy Engine **Shall** transition to the PE_DR_SRC_Give_Sink_Cap_Ext State, from the PE_SRC_Ready State, when a Get_Sink_Cap_Extended Message is received.
<!-- page 351 -->
On entry to the PE_DR_SRC_Give_Sink_Cap_Ext State the Policy Engine **Shall** Request the present extended Sink Capabilities from the Device Policy Manager and then send a Sink_Capabilities_Extended Message based on these Capabilities.
The Policy Engine **Shall** transition back to the PE_SRC_Ready State (see Figure 9.17 )when:
- The Sink_Capabilities_Extended Message has been successfully sent.
#### 9.2.20.15. Dual-Role (Source Port) Get Source Information State Diagram
Figure 9.73 shows the State diagram for a Dual-Role Device, presently operating as a Source, on receiving a Request from the Device Policy Manager to get the Port Partner's Source information. See also Section 6.3.23 and Section 6.4.10.
**Figure 9.73. Dual-Role (Source) Get Source Information State Diagram**
![Figure 9.73. Dual-Role (Source) Get Source Information State Diagram](09-state-machine-diagrams/figure-9.73.png)
##### 9.2.20.15.1. PE_DR_SRC_Get_Source_Info State
The Policy Engine **Shall** transition to the PE_DR_SRC_Get_Source_Info State, from the PE_SRC_Ready State, due to a Request to get the remote Source information from the Device Policy Manager.
On entry to the PE_DR_SRC_Get_Source_Info State the Policy Engine **Shall** send a Get_Source_Info Message and initialize and run the SenderResponseTimer.
On exit from the PE_DR_SRC_Get_Source_Info State the Policy Engine **Shall** inform the Device Policy Manager of the outcome (information or response timeout).
The Policy Engine **Shall** transition back to the PE_SRC_Ready State (see Figure 9.17 ) when:
- A Source_Info Message is received.
- Or SenderResponseTimer times out.
#### 9.2.20.16. Dual-Role (Sink Port) Give Source Information State Diagram
Figure 9.68 shows the State diagram for a Dual-Role Device, presently operating as a Sink, on receiving a Get_Source_Info Message. See also Section 6.3.23 and Section 6.4.10.
<!-- page 352 -->
**Figure 9.74. Dual-Role (Source) Give Source Information diagram**
![Figure 9.74. Dual-Role (Source) Give Source Information diagram](09-state-machine-diagrams/figure-9.74.png)
##### 9.2.20.16.1. PE_DR_SNK_Give_Source_Info State
The Policy Engine **Shall** transition to the PE_DR_SNK_Give_Source_Info State, from the PE_SNK_Ready State, when a Get_Source_Info Message is received.
On entry to the PE_DR_SNK_Give_Source_Info State the Policy Engine **Shall** Request the present Source information from the Device Policy Manager and then send a Source_Info Message based on this information.
The Policy Engine **Shall** transition back to the PE_SNK_Ready State (see Figure 9.18 ) when:
- The Source_Info Message has been successfully sent.
### 9.2.21. VCONN Swap State Diagram
The State Diagram in this section **Shall** apply to Ports that supply VCONN. Figure 9.75 shows the State operation for a Port on sending or receiving a VCONN Swap Request.
<!-- page 353 -->
**Figure 9.75. VCONN Swap State Diagram**
![Figure 9.75. VCONN Swap State Diagram](09-state-machine-diagrams/figure-9.75.png)
1. A Port is presently the VCONN Source if it has the responsibility for supplying VCONN even if VCONN has been turned off.
2. The PE_VCS_Force_VCONN State is Optional.
#### 9.2.21.1. PE_VCS_Send_Swap State
The PE_VCS_Send_Swap State is entered from either the PE_SRC_Ready or PE_SNK_Ready State when the Policy Engine receives a Request from the Device Policy Manager to perform a VCONN Swap.
On entry to the PE_VCS_Send_Swap State the Policy Engine **Shall** send a VCONN_Swap Message and start the SenderResponseTimer.
The Policy Engine **Shall** transition to the PE_VCS_Wait_For_VCONN State when:
- An Accept Message is received and
- The Port is presently the VCONN Source.
<!-- page 354 -->
The Policy Engine **Shall** transition to the PE_VCS_Turn_On_VCONN State when:
- An Accept Message is received and
- The Port is not presently the VCONN Source.
The Policy Engine **Shall** transition back to either the PE_SRC_Ready, PE_SNK_Ready or PE_SRC_EPR_Mode_Discover_Cable State when:
- A Reject Message is received or
- A Wait Message is received or
- The SenderResponseTimer times out.
The Policy Engine May transition to the PE_VCS_Force_VCONN State when:
- A Not_Supported Message is received and
- The Port is not presently the VCONN Source.
#### 9.2.21.2. PE_VCS_Evaluate_Swap State
The PE_VCS_Evaluate_Swap State is entered from either the PE_SRC_Ready or PE_SNK_Ready State when the Policy Engine receives a VCONN_Swap Message.
On entry to the PE_VCS_Evaluate_Swap State the Policy Engine **Shall** Request the Device Policy Manager for an evaluation of the VCONN Swap Request.
The Policy Engine **Shall** transition to the PE_VCS_Accept_Swap State when:
- The Device Policy Manager indicates that a VCONN Swap is OK.
The Policy Engine **Shall** transition to the PE_VCS_Reject_Swap State when:
- The Port is not presently the VCONN Source and the Device Policy Manager indicates that a VCONN Swap is not OK or
- The Device Policy Manager indicates that a VCONN Swap cannot be done at this time.
#### 9.2.21.3. PE_VCS_Accept_Swap State
On entry to the PE_VCS_Accept_Swap State the Policy Engine **Shall** send an Accept Message. The Policy Engine **Shall** transition to the PE_VCS_Wait_For_VCONN State when:
- The Accept Message has been sent and
- The Port's VCONN is on.
The Policy Engine **Shall** transition to the PE_VCS_Turn_On_VCONN State when:
- The Accept Message has been sent and
- The Port's VCONN is off.
#### 9.2.21.4. PE_VCS_Reject_Swap State
On entry to the PE_VCS_Reject_Swap State the Policy Engine **Shall** Request the Protocol Layer to send:
- A Reject Message if the Device is unable to perform a VCONN Swap at this time.
- A Wait Message if further evaluation of the VCONN Swap Request is required.
<!-- page 355 -->
Note: In this case it is expected that the Port will send a VCONN_Swap Message at a later time. The Policy Engine **Shall** transition back to either the PE_SRC_Ready, PE_SNK_Ready or PE_SRC_EPR_Mode_Discover_Cable State when:
- The Reject or Wait Message has been sent.
#### 9.2.21.5. PE_VCS_Wait_for_VCONN State
On entry to the PE_VCS_Wait_For_VCONN State the Policy Engine **Shall** start the VconnOnTimer. The Policy Engine **Shall** transition to the PE_VCS_Turn_Off_VCONN State when:
- A PS_RDY Message is received.
The Policy Engine **Shall** transition to either the PE_SRC_Hard_Reset or PE_SNK_Hard_Reset State when:
- The VconnOnTimer times out.
#### 9.2.21.6. PE_VCS_Turn_Off_VCONN State
On entry to the PE_VCS_Turn_Off_VCONN State the Policy Engine **Shall** tell the Device Policy Manager to turn off VCONN.
The Policy Engine **Shall** transition back to either the PE_SRC_Ready, PE_SNK_Ready or PE_SRC_EPR_Mode_Discover_Cable State when:
- The Device Policy Manager has been informed.
#### 9.2.21.7. PE_VCS_Turn_On_VCONN State
On entry to the PE_VCS_Turn_On_VCONN State the Policy Engine **Shall** tell the Device Policy Manager to turn on VCONN.
The Policy Engine **Shall** transition to the PE_VCS_Send_Ps_Rdy State when:
- The Port's VCONN is on.
#### 9.2.21.8. PE_VCS_Send_PS_Rdy State
On entry to the PE_VCS_Send_Ps_Rdy State the Policy Engine **Shall** send a PS_RDY Message. The Policy Engine **Shall** transition back to either the PE_SRC_Ready, PE_SNK_Ready or PE_SRC_EPR_Mode_Discover_Cable State when:
- The PS_RDY Message has been sent.
#### 9.2.21.9. PE_VCS_Force_VCONN State
On entry to the PE_VCS_Force_VCONN State the Policy Engine **Shall** tell the Device Policy Manager to turn on VCONN. The Policy Engine **Shall** transition back to either the PE_SRC_Ready, PE_SNK_Ready or PE_SRC_EPR_Mode_Discover_Cable State when:
- The Port's VCONN is on.
### 9.2.22. Initiator Structured VDM State Diagrams
The State Diagrams in this section **Shall** apply to all Initiators.
#### 9.2.22.1. Initiator Structured VDM Discover Identity State Diagram
Figure 9.76 shows the State diagram for an Initiator when discovering the identity of its Port Partner or Cable Plug.
<!-- page 356 -->
**Figure 9.76. Initiator to Port VDM Discover Identity State Diagram**
![Figure 9.76. Initiator to Port VDM Discover Identity State Diagram](09-state-machine-diagrams/figure-9.76.png)
1. The DPM in an EPR Source **Shall** Request the discovery of the identity of the Cable Plug at startup.
##### 9.2.22.1.1. PE_INIT_Port_VDM_Identity_Request State
The Policy Engine transitions to the PE_INIT_Port_VDM_Identity_Request State from either the PE_SRC_Ready or PE_SNK_Ready State when:
- The Device Policy Manager requests the discovery of the identity of the Port Partner or Cable Plug or
- The DiscoverIdentityTimer times out.
<!-- page 357 -->
The Policy Engine transitions to the PE_INIT_Port_VDM_Identity_Request State from the PE_SRC_EPR_Mode_Discover_Cable State when:
- The Cable Plug Discovery Process has been initiated.
On entry to the PE_INIT_Port_VDM_Identity_Request State the Policy Engine **Shall** send a Structured VDM Discover Identity Command Request and **Shall** start the VDMResponseTimer.
The Policy Engine **Shall** transition to the PE_INIT_Port_VDM_Identity_ACKed State when:
- A Structured VDM Discover Identity ACK Command response is received.
The Policy Engine **Shall** transition to the PE_INIT_Port_VDM_Identity_NAKed State when:
- A Structured VDM Discover Identity NAK or BUSY Command response is received or
- The VDMResponseTimer times out.
##### 9.2.22.1.2. PE_INIT_Port_VDM_Identity_ACKed State
On entry to the PE_INIT_Port_VDM_Identity_ACKed State the Policy Engine **Shall** inform the Device Policy Manager of the Identity information.
The Policy Engine **Shall** transition to either the PE_SRC_Ready, PE_SNK_Ready or PE_SRC_EPR_Mode_Evaluate_Cable_EPR State when:
- The Device Policy Manager has been informed.
##### 9.2.22.1.3. PE_INIT_Port_VDM_Identity_NAKed State
On entry to the PE_INIT_Port_VDM_Identity_NAKed State the Policy Engine **Shall** inform the Device Policy Manager of the result (NAK, BUSY or timeout).
The Policy Engine **Shall** transition to either the PE_SRC_Ready, PE_SNK_Ready or PE_SRC_EPR_Mode_Evaluate_Cable_EPR State when:
- The Device Policy Manager has been informed.
#### 9.2.22.2. Initiator Structured VDM Discover SVIDs State Diagram
Figure 9.77 shows the State diagram for an Initiator when discovering SVIDs of its Port Partner or Cable Plug.
<!-- page 358 -->
**Figure 9.77. Initiator VDM Discover SVIDs State Diagram**
![Figure 9.77. Initiator VDM Discover SVIDs State Diagram](09-state-machine-diagrams/figure-9.77.png)
##### 9.2.22.2.1. PE_INIT_VDM_SVIDs_Request State
The Policy Engine transitions to the PE_INIT_VDM_SVIDs_Request State from either the PE_SRC_Ready or PE_SNK_Ready State when:
- The Device Policy Manager requests the discovery of the SVIDs of the Port Partner or a Cable Plug.
On entry to the PE_INIT_VDM_SVIDs_Request State the Policy Engine **Shall** send a Structured VDM Discover SVIDs Command Request and **Shall** start the VDMResponseTimer.
The Policy Engine **Shall** transition to the PE_INIT_VDM_SVIDs_ACKed State when:
- A Structured VDM Discover SVIDs ACK Command response is received. The Policy Engine **Shall** transition to the PE_INIT_VDM_SVIDs_NAKed State when:
- A Structured VDM Discover SVIDs NAK or BUSY Command response is received or
- The VDMResponseTimer times out.
##### 9.2.22.2.2. PE_INIT_VDM_SVIDs_ACKed State
On entry to the PE_INIT_VDM_SVIDs_ACKed State the Policy Engine **Shall** inform the Device Policy Manager of the SVIDs information.
<!-- page 359 -->
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State when:
- The Device Policy Manager has been informed.
##### 9.2.22.2.3. PE_INIT_VDM_SVIDs_NAKed State
On entry to the PE_INIT_VDM_SVIDs_NAKed State the Policy Engine **Shall** inform the Device Policy Manager of the result (NAK, BUSY or timeout).
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State when:
- The Device Policy Manager has been informed.
#### 9.2.22.3. Initiator Structured VDM Discover Modes State Diagram
Figure 9.78 shows the State diagram for an Initiator when discovering Modes of its Port Partner or Cable Plug.
**Figure 9.78. Initiator VDM Discover Modes State Diagram**
![Figure 9.78. Initiator VDM Discover Modes State Diagram](09-state-machine-diagrams/figure-9.78.png)
#### 9.2.22.4. Initiator Structured VDM Attention State Diagram
Figure 9.79 shows the State diagram for an Initiator when sending an Attention Command Request.
<!-- page 360 -->
**Figure 9.79. Initiator VDM Attention State Diagram**
![Figure 9.79. Initiator VDM Attention State Diagram](09-state-machine-diagrams/figure-9.79.png)
##### 9.2.22.4.1. PE_INIT_VDM_Modes_Request State
The Policy Engine transitions to the PE_INIT_VDM_Modes_Request State from either the PE_SRC_Ready or PE_SNK_Ready State when:
- The Device Policy Manager requests the discovery of the Modes of the Port Partner or a Cable Plug.
On entry to the PE_INIT_VDM_Modes_Request State the Policy Engine **Shall** send a Structured VDM Discover Modes Command Request and **Shall** start the VDMResponseTimer.
The Policy Engine **Shall** transition to the PE_INIT_VDM_Modes_ACKed State when:
- A Structured VDM Discover Modes ACK Command response is received. The Policy Engine **Shall** transition to the PE_INIT_VDM_Modes_NAKed State when:
- A Structured VDM Discover Modes NAK or BUSY Command response is received or
- The VDMResponseTimer times out.
##### 9.2.22.4.2. PE_INIT_VDM_Modes_ACKed State
On entry to the PE_INIT_VDM_Modes_ACKed State the Policy Engine **Shall** inform the Device Policy Manager of the Modes information.
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State for a DFP when:
- The Device Policy Manager has been informed.
##### 9.2.22.4.3. PE_INIT_VDM_Modes_NAKed State
On entry to the PE_INIT_VDM_Modes_NAKed State the Policy Engine **Shall** inform the Device Policy Manager of the result (NAK, BUSY or timeout).
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State for a DFP when:
- The Device Policy Manager has been informed.
<!-- page 361 -->
##### 9.2.22.4.4. PE_INIT_VDM_Attention_Request State
The Policy Engine transitions to the PE_INIT_VDM_Attention_Request State from either the PE_SRC_Ready or PE_SNK_Ready State when:
- When the Device Policy Manager requests attention from its Port Partner.
On entry to the PE_INIT_VDM_Attention_Request State the Policy Engine **Shall** send an Attention Command Request.
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State when:
- The Attention Command Request has been sent.
### 9.2.23. Responder Structured VDM State Diagrams
#### 9.2.23.1. Responder Structured VDM Discover Identity State Diagram
Figure 9.80 shows the State diagram for a Responder receiving a Discover Identity Command Request.
**Figure 9.80. Responder Structured VDM Discover Identity State Diagram**
![Figure 9.80. Responder Structured VDM Discover Identity State Diagram](09-state-machine-diagrams/figure-9.80.png)
The Policy Engine transitions to the PE_RESP_VDM_Get_Identity State from either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State when:
- A Structured VDM Discover Identity Command Request is received.
On entry to the PE_RESP_VDM_Get_Identity State the Responder **Shall** Request identity information from the Device Policy Manager.
The Policy Engine **Shall** transition to the PE_RESP_VDM_Send_Identity State when:
- Identity information is received from the Device Policy Manager.
The Policy Engine **Shall** transition to the PE_RESP_VDM_Get_Identity_NAK State when:
- The Device Policy Manager indicates that the response to the Discover Identity Command Request isNAK or BUSY.
##### 9.2.23.1.1. PE_RESP_VDM_Send_Identity State
On entry to the PE_RESP_VDM_Send_Identity State the Responder **Shall** send the Structured VDM Discover Identity ACK Command response.
<!-- page 362 -->
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State for a UFP when:
- The Structured VDM Discover Identity ACK Command response has been sent.
##### 9.2.23.1.2. PE_RESP_VDM_Get_Identity_NAK State
On entry to the PE_RESP_VDM_Get_Identity_NAK State the Policy Engine **Shall** send a Structured VDM Discover Identity NAK or BUSY Command response as indicated by the Device Policy Manager.
The Policy Engine **Shall** transition to either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State when:
- The Structured VDM Discover Identity NAK or BUSY Command response has been sent.
#### 9.2.23.2. Responder Structured VDM Discover SVIDs State Diagram
Figure 9.81 shows the State diagram for a Responder when receiving a Discover SVIDs Command.
**Figure 9.81. Responder Structured VDM Discover SVIDs State Diagram**
![Figure 9.81. Responder Structured VDM Discover SVIDs State Diagram](09-state-machine-diagrams/figure-9.81.png)
The Policy Engine transitions to the PE_RESP_VDM_Get_SVIDs State from either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State when:
- A Structured VDM Discover SVIDs Command Request is received.
On entry to the PE_RESP_VDM_Get_SVIDs State the Responder **Shall** Request SVIDs information from the Device Policy Manager.
The Policy Engine **Shall** transition to the PE_RESP_VDM_Send_SVIDs State when:
- SVIDs information is received from the Device Policy Manager.
The Policy Engine **Shall** transition to the PE_RESP_VDM_Get_SVIDs_NAK State when:
- The Device Policy Manager indicates that the response to the Discover SVIDs Command Request is NAK or BUSY.
##### 9.2.23.2.1. PE_UFP_VDM_Send_SVIDs State
On entry to the PE_RESP_VDM_Send_SVIDs State the Responder **Shall** send the Structured VDM Discover SVIDs ACK Command response.
The Policy Engine **Shall** transition to either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State when:
- The Structured VDM Discover SVIDs ACK Command response has been sent.
<!-- page 363 -->
##### 9.2.23.2.2. PE_UFP_VDM_Get_SVIDs_NAK State
On entry to the PE_RESP_VDM_Get_SVIDs_NAK State the Policy Engine **Shall** send a Structured VDM Discover SVIDs NAK or BUSY Command response as indicated by the Device Policy Manager.
The Policy Engine **Shall** transition to either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State when:
- The Structured VDM Discover SVIDs NAK or BUSY Command response has been sent.
#### 9.2.23.3. Responder Structured VDM Discover Modes State Diagram
Figure 9.82 shows the State diagram for a Responder on receiving a Discover Modes Command.
**Figure 9.82. Responder Structured VDM Discover Modes State Diagram**
![Figure 9.82. Responder Structured VDM Discover Modes State Diagram](09-state-machine-diagrams/figure-9.82.png)
The Policy Engine transitions to the PE_RESP_VDM_Get_Modes State from either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State when:
- A Structured VDM Discover Modes Command Request is received.
On entry to the PE_RESP_VDM_Get_Modes State the Responder **Shall** Request Modes information from the Device Policy Manager.
The Policy Engine **Shall** transition to the PE_RESP_VDM_Send_Modes State when:
- Modes information is received from the Device Policy Manager.
The Policy Engine **Shall** transition to the PE_RESP_VDM_Get_Modes_NAK State when:
- The Device Policy Manager indicates that the response to the Discover Modes Command Request is NAK or BUSY.
##### 9.2.23.3.1. PE_RESP_VDM_Send_Modes State
On entry to the PE_RESP_VDM_Send_Modes State the Responder **Shall** send the Structured VDM Discover Modes ACK Command response.
The Policy Engine **Shall** transition to either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State when:
- The Structured VDM Discover Modes ACK Command response has been sent.
##### 9.2.23.3.2. PE_RESP_VDM_Get_Modes_NAK State
On entry to the PE_RESP_VDM_Get_Modes_NAK State the Policy Engine **Shall** send a Structured VDM Discover Modes NAK or BUSY Command response as indicated by the Device Policy Manager.
<!-- page 364 -->
The Policy Engine **Shall** transition to either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready State when:
- The Structured VDM Discover Modes NAK or BUSY Command response has been sent.
#### 9.2.23.4. Receiving a Structured VDM Attention State Diagram
Figure 9.83 shows the State diagram for a Responder when receiving an Attention Command Request.
**Figure 9.83. Receiving a Structured VDM Attention State Diagram**
![Figure 9.83. Receiving a Structured VDM Attention State Diagram](09-state-machine-diagrams/figure-9.83.png)
##### 9.2.23.4.1. PE_RCV_VDM_Attention_Request State
The Policy Engine transitions to the PE_RCV_VDM_Attention_Request State from either the PE_SRC_Ready or PE_SNK_Ready State when:
- An Attention Command Request is received.
On entry to the PE_RCV_VDM_Attention_Request State the Policy Engine **Shall** inform the Device Policy Manager of the Attention Command Request.
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State when:
- The Device Policy Manager has been informed.
### 9.2.24. DFP Structured VDM State Diagrams
The State Diagrams in this section **Shall** apply to all DFPs that support Structured VDMs.
#### 9.2.24.1. DFP Structured VDM Mode Entry State Diagram
Figure 9.84 shows the State operation for a DFP when entering a Mode.
<!-- page 365 -->
**Figure 9.84. DFP VDM Mode Entry State Diagram**
![Figure 9.84. DFP VDM Mode Entry State Diagram](09-state-machine-diagrams/figure-9.84.png)
1. The Device Policy Manager **Shall** have placed the system into USB Safe State before issuing this Request when entering Modal Operation.
2. The Device Policy Manager **Shall** have returned the system to USB operation if not in Modal Operation at this point.
3. Protocol Errors are handled by informing the DPM, returning to USB Safe State and then processing the Message once the PE_SRC_Ready or PE_SNK_Ready State has been entered.
##### 9.2.24.1.1. PE_DFP_VDM_Mode_Entry_Request State
The Policy Engine transitions to the PE_DFP_VDM_Mode_Entry_Request State from either the PE_SRC_Ready or PE_SNK_Ready State for a DFP when:
- The Device Policy Manager requests that the Port Partner or a Cable Plug enter a Mode.
On entry to the PE_DFP_VDM_Mode_Entry_Request State the Policy Engine **Shall** send a Structured VDM Enter Mode Command Request and **Shall** start the VDMModeEntryTimer.
The Policy Engine **Shall** transition to the PE_DFP_VDM_Mode_Entry_ACKed State when:
- A Structured VDM Enter Mode ACK Command response is received.
The Policy Engine **Shall** transition to the PE_DFP_VDM_Mode_Entry_NAKed State when:
<!-- page 366 -->
- A Structured VDM Enter Mode NAK or BUSY Command response is received or
- The VDMModeEntryTimer times out.
##### 9.2.24.1.2. PE_DFP_VDM_Mode_Entry_ACKed State
On entry to the PE_DFP_VDM_Mode_Entry_ACKed State the Policy Engine **Shall** Request the Device Policy Manager to enter the Mode.
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State for a DFP when:
- The Mode has been entered.
##### 9.2.24.1.3. PE_DFP_VDM_Mode_Entry_NAKed State
On entry to the PE_DFP_VDM_Mode_Entry_NAKed State the Policy Engine **Shall** inform the Device Policy Manager of the reason for failure (NAK, BUSY, timeout or Protocol Error).
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State for a DFP when:
- The Device Policy Manager has been informed.
#### 9.2.24.2. DFP Structured VDM Mode Exit State Diagram
Figure 9.85 shows the State operation for a DFP when exiting a Mode.
**Figure 9.85. DFP VDM Mode Exit State Diagram**
![DFP VDM Mode Exit State Diagram](09-state-machine-diagrams/figure-9.85.png)
<!-- page 367 -->
1. The Device Policy Manager is required to return the system to USB operation at this point when exiting Modal Operation.
##### 9.2.24.2.1. PE_DFP_VDM_Mode_Exit_Request State
The Policy Engine transitions to the PE_DFP_VDM_Mode_Exit_Request State from either the PE_SRC_Ready or PE_SNK_Ready State for a DFP when:
- The Device Policy Manager requests that the Port Partner or a Cable Plug exit a Mode.
On entry to the PE_DFP_VDM_Mode_Exit_Request State the Policy Engine **Shall** send a Structured VDM Exit Mode Command Request and **Shall** start the VDMModeExitTimer.
The Policy Engine **Shall** transition to the PE_DFP_VDM_Mode_Entry_ACKed State when:
- A Structured VDM Exit Mode ACK or NAK Command response is received.
The Policy Engine **Shall** transition to either the PE_SRC_Hard_Reset or PE_SNK_Hard_Reset State depending on the present Power Role when:
- A Structured VDM Exit Mode BUSY Command response is received or
- The VDMModeExitTimer times out.
##### 9.2.24.2.2. PE_DFP_VDM_DFP_Mode_Exit_ACKed State
On Exit to the PE_DFP_VDM_Mode_Entry_ACKed State the Policy Engine **Shall** inform the Device Policy Manager Of the result: ACK or NAK.
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State for a DFP when:
- The Device Policy Manager has been informed.
### 9.2.25. UFP Structured VDM State Diagrams
The State Diagrams in this section **Shall** apply to all UFPs that support Structured VDMs.
#### 9.2.25.1. UFP Structured VDM Enter Mode State Diagram
Figure 9.86 shows the State diagram for a UFP in response to an Enter Mode Command.
<!-- page 368 -->
**Figure 9.86. UFP Structured VDM Enter Mode State Diagram**
![UFP Structured VDM Enter Mode State Diagram](09-state-machine-diagrams/figure-9.86.png)
1. The UFP is required to be in USB operation or USB Safe State at this point.
##### 9.2.25.1.1. PE_UFP_VDM_Evaluate_Mode_Entry State
The Policy Engine transitions to the PE_UFP_VDM_Evaluate_Mode_Entry State from either the PE_SRC_Ready or PE_SNK_Ready State for a UFP when:
- A Structured VDM Enter Mode Command Request is received from the DFP.
On Entry to the PE_UFP_VDM_Evaluate_Mode_Entry State the Policy Engine **Shall** Request the Device Policy Manager to evaluate the Enter Mode Command Request and enter the Mode indicated in the Command Request if the Request is acceptable.
The Policy Engine **Shall** transition to the PE_UFP_VDM_Mode_Entry_ACK State when:
- The Device Policy Manager indicates that the Mode has been entered.
The Policy Engine **Shall** transition to the PE_UFP_VDM_Mode_Entry_NAK State when:
- The Device Policy Manager indicates that the response to the Mode Request is NAK.
<!-- page 369 -->
##### 9.2.25.1.2. PE_UFP_VDM_Mode_Entry_ACK State
On entry to the PE_UFP_VDM_Mode_Entry_ACK State the Policy Engine **Shall** send a Structured VDM Enter Mode ACK Command response.
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State for a UFP when:
- The Structured VDM Enter Mode ACK Command response has been sent.
##### 9.2.25.1.3. PE_UFP_VDM_Mode_Entry_NAK State
On entry to the PE_UFP_VDM_Mode_Entry_NAK State the Policy Engine **Shall** send a Structured VDM Enter Mode NAK Command response as indicated by the Device Policy Manager.
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State for a UFP when:
- The Structured VDM Enter Mode NAK Command response has been sent.
#### 9.2.25.2. UFP Structured VDM Exit Mode State Diagram
Figure 9.87 shows the State diagram for a UFP in response to an Exit Mode Command.
<!-- page 370 -->
**Figure 9.87. UFP Structured VDM Exit Mode State Diagram**
![UFP Structured VDM Exit Mode State Diagram](09-state-machine-diagrams/figure-9.87.png)
1. The UFP is required to be in USB operation or USB Safe State at this point.
##### 9.2.25.2.1. PE_UFP_VDM_Mode_Exit State
The Policy Engine transitions to the PE_UFP_VDM_Mode_Exit State from either the PE_SRC_Ready or PE_SNK_Ready State for a UFP when:
- A Structured VDM Exit Mode Command Request is received from the DFP.
On entry to the PE_UFP_VDM_Mode_Exit State the Policy Engine **Shall** Request the Device Policy Manager to exit the Mode indicated in the Command.
The Policy Engine **Shall** transition to the PE_UFP_VDM_Mode_Exit_ACK State when:
- The Device Policy Manager indicates that the Mode has been exited.
The Policy Engine **Shall** transition to the PE_UFP_VDM_Mode_Exit_NAK State when:
- The Device Policy Manager indicates that the Command response to the Exit Mode Command Request is NAK.
<!-- page 371 -->
##### 9.2.25.2.2. PE_UFP_VDM_Mode_Exit_ACK State
On entry to the PE_UFP_VDM_Mode_Exit_ACK State the Policy Engine **Shall** send a Structured VDM Exit Mode ACK Command response.
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State for a UFP when:
- The Structured VDM Exit Mode ACK Command response has been sent.
##### 9.2.25.2.3. PE_UFP_VDM_Mode_Exit_NAK State
On entry to the PE_UFP_VDM_Mode_Exit_NAK State the Policy Engine **Shall** send a Structured VDM Exit Mode NAK Command response as indicated by the Device Policy Manager.
The Policy Engine **Shall** transition to either the either the PE_SRC_Ready or PE_SNK_Ready State for a UFP when:
- The Structured VDM Exit Mode NAK Command response has been sent.
### 9.2.26. Cable Plug Specific State Diagrams
The State Diagrams in this section **Shall** apply to all Cable Plugs that support Structured VDMs.
#### 9.2.26.1. Cable Plug Cable Ready State Diagram
Figure 9.88 shows the Cable Ready State diagram for a Cable Plug.
**Figure 9.88. Cable Ready State Diagram**
![Cable Ready State Diagram](09-state-machine-diagrams/figure-9.88.png)
##### 9.2.26.1.1. PE_CBL_Ready State
The PE_CBL_Ready State shown in the following sections is the normal operational State for a Cable Plug and where it starts after power up or a Hard/Cable Reset.
<!-- page 372 -->
#### 9.2.26.2. Soft/Hard/Cable Reset
##### 9.2.26.2.1. Cable Plug Soft Reset State Diagram
Figure 9.89 shows the Cable Plug State diagram for a Soft Reset.
**Figure 9.89. Cable Plug Soft Reset State Diagram**
![Cable Plug Soft Reset State Diagram](09-state-machine-diagrams/figure-9.89.png)
###### 9.2.26.2.1.1. PE_CBL_Soft_Reset State
The PE_CBL_Soft_Reset State **Shall** be entered from any State when a Soft_Reset Message is received from the Protocol Layer.
On entry to the PE_CBL_Soft_Reset State the Policy Engine **Shall** reset the Protocol Layer in the Cable Plug and **Shall** then Request the Protocol Layer to send an Accept Message.
The Policy Engine **Shall** transition to the PE_CBL_Ready State when:
- The Accept Message has been sent or
- The Protocol Layer indicates that a transmission error has occurred.
##### 9.2.26.2.2. Cable Plug Hard Reset State Diagram
Figure 9.90 shows the Cable Plug State diagram for a Hard Reset.
<!-- page 373 -->
**Figure 9.90. Cable Plug Hard Reset State Diagram**
![Cable Plug Hard Reset State Diagram](09-state-machine-diagrams/figure-9.90.png)
###### 9.2.26.2.2.1. PE_CBL_Hard_Reset State
The PE_CBL_Hard_Reset State **Shall** be entered from any State when either Hard Reset Signaling or Cable Reset Signaling is detected.
On entry to the PE_CBL_Hard_Reset State the Policy Engine **Shall** reset the Cable Plug (equivalent to a power cycle). The Policy Engine **Shall** transition to the PE_CBL_Ready State when:
- The Cable Plug reset is complete.
##### 9.2.26.2.3. DFP/VCONN Source SOP'/SOP" Soft Reset or Cable Reset of a Cable Plug or VPD State Diagram
This figure shows the State diagram for the Policy Engine in a VCONN Source when performing a Soft Reset or Cable Reset of a Cable Plug or VPD on SOP'/SOP". The following sections describe operation in each of the states.
<!-- page 374 -->
**Figure 9.91. DFP/VCONN Source Soft Reset or Cable Reset of a Cable Plug or VPD State Diagram**
![Figure 9.91. DFP/VCONN Source Soft Reset or Cable Reset of a Cable Plug or VPD State Diagram](09-state-machine-diagrams/figure-9.91.png)
1. Excludes the Soft_Reset Message itself.
2. Sink only communicates with the Cable Plug when in an Explicit Contract. If the Discover Identity Command is being sent at startup, then the Policy Engine will subsequently transition to the PE_SRC_Send_Capabilities State as normal. Otherwise, the Policy Engine will transition to the PE_SRC_Discovery State.
###### 9.2.26.2.3.1. PE_DFP_VCS_CBL_Send_Soft_Reset State
The PE_DFP_VCS_CBL_Send_Soft_Reset State **Shall** be entered from any State when a Protocol Error is detected on SOP'/SOP'' by the Protocol Layer (see Section 7.1.1) or when a Message has not been sent after retries on SOP'/SOP'' while communicating with a Cable Plug/VPD and when there was previous communication with the Cable Plug that did not result in a Transmission Error or whenever the Device Policy Manager directs a Soft Reset on SOP'/SOP''.
On entry to the PE_DFP_VCS_CBL_Send_Soft_Reset State the DFP Policy Engine **Shall** Request the SOP'/SOP'' Protocol Layer to perform a Soft Reset, then **Shall** send a Soft_Reset Message on SOP'/SOP'' to the Cable Plug/VPD, and initialize and run the SenderResponseTimer.
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State, depending on the DFP VCONN Source's Power Role, when:
- There is no Explicit Contract in place and
- An Accept Message has been received on SOP'/SOP''.
The Policy Engine **Shall** transition to either the PE_SRC_Send_Capabilities State or PE_SRC_Discovery State, depending on the DFP's VCONN Source's Power Role, when:
- There is an Explicit Contract in place and
- An Accept Message has been received on SOP'/SOP''.
The Policy Engine **Shall** transition to the PE_DFP_VCS_CBL_Send_Cable_Reset State when:
<!-- page 375 -->
- A SenderResponseTimer timeout occurs
- Or the Protocol Layer indicates that a transmission error has occurred
- Or when a Protocol Error is detected on SOP'/SOP'' by the Protocol Layer.
###### 9.2.26.2.3.2. PE_DFP_VCS_CBL_Send_Cable_Reset State
The PE_DFP_VCS_CBL_Send_Cable_Reset State **Shall** be entered from any State when the Device Policy Manager requests a Cable Reset.
On entry to the PE_DFP_VCS_CBL_Send_Cable_Reset State the DFP Policy Engine **Shall** Request the Protocol Layer to send Cable Reset Signaling.
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State, depending on the VCONN Source's Power Role, when:
- Cable Reset Signaling has been sent.
##### 9.2.26.2.4. UFP/VCONN Source SOP'/SOP'' Soft Reset of a Cable Plug or VPD State Diagram
This figure shows the State diagram for the UFP Policy Engine in a VCONN Source when performing a Soft Reset of a Cable Plug or VPD on SOP'/SOP''. The following sections describe operation in each of the states.
**Figure 9.92. UFP/VCONN Source Soft Reset of a Cable Plug or VPD State Diagram**
![Figure 9.92. UFP/VCONN Source Soft Reset of a Cable Plug or VPD State Diagram](09-state-machine-diagrams/figure-9.92.png)
1. Excludes the Soft_Reset Message itself.
###### 9.2.26.2.4.1. PE_UFP_VCS_CBL_Send_Soft_Reset State
The PE_UFP_VCS_CBL_Send_Soft_Reset State **Shall** be entered from any State when a Protocol Error is detected on SOP'/SOP'' by the Protocol Layer (see Section 7.1.1) or when a Message has not been sent after retries on
<!-- page 376 -->
SOP'/SOP'' while communicating with a Cable Plug/VPD and when there was previous communication with the Cable Plug that did not result in a Transmission Error or whenever the Device Policy Manager directs a Soft Reset on SOP'/SOP''.
On entry to the PE_UFP_VCS_CBL_Send_Soft_Reset State the Policy Engine **Shall** Request the SOP'/SOP'' Protocol Layer to perform a Soft Reset, then **Shall** send a Soft_Reset Message on SOP'/SOP'' to the Cable Plug, and initialize and run the SenderResponseTimer.
The Policy Engine **Shall** transition to either the PE_SRC_Ready or PE_SNK_Ready State, depending on the UFP VCONN Source's Power Role, when:
- An Accept Message has been received on SOP'/SOP''.
The Policy Engine **Shall** transition to either the PE_SRC_Hard_Reset or PE_SNK_Hard_Reset State, depending on the UFP VCONN Source's Power Role, when:
- A SenderResponseTimer timeout occurs
- Or the Protocol Layer indicates that a transmission error has occurred
- Or when a Protocol Error is detected on SOP'/SOP'' by the Protocol Layer.
##### 9.2.26.2.5. Source Startup Structured VDM Discover Identity of a Cable Plug State Diagram
Figure 9.93 shows the State diagram for Source discovery of identity information from a Cable Plug during the startup sequence.
<!-- page 377 -->
**Figure 9.93. Source Startup Structured VDM Discover Identity State Diagram**
![Figure 9.93. Source Startup Structured VDM Discover Identity State Diagram](09-state-machine-diagrams/figure-9.93.png)
1. If the Discover Identity Command is being sent at startup, then the Policy Engine will subsequently transition to the PE_SRC_Send_Capabilities State as normal. Otherwise, the Policy Engine will transition to the PE_SRC_Discovery State.
2. The SourceCapabilityTimer continues to run during the states defined in this diagram even though there has been an exit from the PE_SRC_Discovery State. This ensures that Source_Capabilities Messages are sent out at a regular rate.
3. The DPM in an EPR Source **Shall** Request the discovery of the identity of the Cable Plug at startup.
###### 9.2.26.2.5.1. PE_SRC_VDM_Identity_Request State
The Policy Engine **Shall** transition to the PE_SRC_VDM_Identity_Request State from the PE_SRC_Startup State when:
- The Device Policy Manager requests the discovery of the identity of the Cable Plug.
The Policy Engine **Shall** transition to the PE_SRC_VDM_Identity_Request State from the PE_SRC_Discovery State when:
- The Device Policy Manager requests the discovery of the identity of the Cable Plug and
<!-- page 378 -->
- The DiscoverIdentityCounter < nDiscoverIdentityCount.
Even though there has been a transition out of the PE_SRC_Discovery State the SourceCapabilityTimer **Shall** continue to run during the states shown in Figure 9.93 and **Shall Not** be initialized on re-entry to PE_SRC_Discovery.
Note: An EPR Source is required to discover the identity of the Cable Plug prior to entering the First Explicit Contract (see Section 7.30.1)
On entry to the PE_SRC_VDM_Identity_Request State the Policy Engine **Shall** send a Structured VDM Discover Identity Command Request, **Shall** increment the DiscoverIdentityCounter and **Shall** start the VDMResponseTimer.
The Policy Engine **Shall** transition to the PE_SRC_VDM_Identity_ACKed State when:
- A Structured VDM Discover Identity ACK Command response is received. The Policy Engine **Shall** transition to the PE_SRC_VDM_Identity_NAKed State when:
- A Structured VDM Discover Identity NAK or BUSY Command response is received or
- The VDMResponseTimer times out or
- The Structured VDM Discover Identity Command Request Message sending fails (no GoodCRC Message
received after retries).
###### 9.2.26.2.5.2. PE_SRC_VDM_Identity_ACKed State
On entry to the PE_SRC_VDM_Identity_ACKed State the Policy Engine **Shall** inform the Device Policy Manager of the Identity information.
The Policy Engine **Shall** transition back to either the PE_SRC_Send_Capabilities or PE_SRC_Discovery State when:
- The Device Policy Manager has been informed.
###### 9.2.26.2.5.3. PE_SRC_VDM_Identity_NAKed State
On entry to the PE_SRC_VDM_Identity_NAKed State the Policy Engine **Shall** inform the Device Policy Manager of the result (NAK, BUSY or timeout).
The Policy Engine **Shall** transition back to either the PE_SRC_Send_Capabilities or PE_SRC_Discovery State when:
- The Device Policy Manager has been informed.
##### 9.2.26.2.6. Cable Plug Mode Entry/Exit
###### 9.2.26.2.6.1. Cable Plug Structured VDM Enter Mode State Diagram
Figure 9.94 shows the State diagram for a Cable Plug in response to an Enter Mode Command.
<!-- page 379 -->
**Figure 9.94. Cable Plug Structured VDM Enter Mode State Diagram**
![Figure 9.94. Cable Plug Structured VDM Enter Mode State Diagram](09-state-machine-diagrams/figure-9.94.png)
1. The Cable Plug is required to be in USB operation or USB Safe State at this point.
**PE_CBL_Evaluate_Mode_Entry State**
The Policy Engine transitions to the PE_CBL_Evaluate_Mode_Entry State from the PE_CBL_Ready State when:
- A Structured VDM Enter Mode Command Request is received from the DFP.
On Entry to the PE_CBL_Evaluate_Mode_Entry State the Policy Engine **Shall** Request the Device Policy Manager to evaluate the Enter Mode Command Request and enter the Mode indicated in the Command Request if the Request is acceptable.
The Policy Engine **Shall** transition to the PE_CBL_Mode_Entry_ACK State when:
- The Device Policy Manager indicates that the Mode has been entered. The Policy Engine **Shall** transition to the PE_CBL_Mode_Entry_NAK State when:
- The Device Policy Manager indicates that the response to the Mode Request is NAK.
**PE_CBL_Mode_Entry_ACK State**
On entry to the PE_CBL_Mode_Entry_ACK State the Policy Engine **Shall** send a Structured VDM Enter Mode ACK Command response.
<!-- page 380 -->
The Policy Engine **Shall** transition to the PE_CBL_Ready State when:
- The Structured VDM Enter Mode ACK Command response has been sent.
**PE_CBL_Mode_Entry_NAK State**
On entry to the PE_CBL_Mode_Entry_NAK State the Policy Engine **Shall** send a Structured VDM Enter Mode NAK Command response as indicated by the Device Policy Manager.
The Policy Engine **Shall** transition to the PE_CBL_Ready State when:
- The Structured VDM Enter Mode NAK Command response has been sent.
###### 9.2.26.2.6.2. Cable Plug Structured VDM Exit Mode State Diagram
- Figure 9.95 shows the State diagram for a Cable Plug in response to an Exit Mode Command.
**Figure 9.95. Cable Plug Structured VDM Exit Mode State Diagram**
![Figure 9.95. Cable Plug Structured VDM Exit Mode State Diagram](09-state-machine-diagrams/figure-9.95.png)
1. The Cable Plug is required to be in USB operation or USB Safe State at this point.
<!-- page 381 -->
**PE_CBL_Mode_Exit State**
The Policy Engine transitions to the PE_CBL_Mode_Exit State from the PE_CBL_Ready State when:
- A Structured VDM Exit Mode Command Request is received from the DFP.
On entry to the PE_CBL_Mode_Exit State the Policy Engine **Shall** Request the Device Policy Manager to exit the Mode indicated in the Command.
The Policy Engine **Shall** transition to the PE_CBL_Mode_Exit_ACK State when:
- The Device Policy Manager indicates that the Mode has been exited. The Policy Engine **Shall** transition to the PE_CBL_Mode_Exit_NAK State when:
- The Device Policy Manager indicates that the Command response to the Exit Mode Command Request is NAK.
**PE_CBL_Mode_Exit_ACK State**
On entry to the PE_CBL_Mode_Exit_ACK State the Policy Engine **Shall** send a Structured VDM Exit Mode ACK Command response.
The Policy Engine **Shall** transition to the PE_CBL_Ready State when:
- The Structured VDM Exit Mode ACK Command response has been sent.
**PE_CBL_Mode_Exit_NAK State**
On entry to the PE_CBL_Mode_Exit_NAK State the Policy Engine **Shall** send a Structured VDM Exit Mode NAK Command response as indicated by the Device Policy Manager.
The Policy Engine **Shall** transition to the PE_CBL_Ready State when:
- The Structured VDM Exit Mode NAK Command response has been sent.
#### 9.2.26.3. EPR Mode State Diagrams
##### 9.2.26.3.1. Source EPR Mode Entry State Diagram
Figure 9.96 shows the State diagram for an EPR Source in response to an EPR_Mode Message.
<!-- page 382 -->
**Figure 9.96. Source EPR Mode Entry State Diagram**
![Figure 9.96. Source EPR Mode Entry State Diagram](09-state-machine-diagrams/figure-9.96.png)
###### 9.2.26.3.1.1. PE_SRC_Evaluate_EPR_Mode_Entry State
The Policy Engine transitions to the `PE_SRC_Evaluate_EPR_Mode_Entry` State from the `PE_SRC_Ready` State when:
- An `EPR_Mode` (Enter) Message is received from the Sink.
On Entry to the `PE_SRC_Evaluate_EPR_Mode_Entry` State the Policy Engine **Shall** Request the Device Policy Manager to evaluate the `EPR_Mode` (Enter) Message.
The Policy Engine **Shall** transition to the `PE_SRC_EPR_Mode_Entry_Ack` State when:
- The Device Policy Manager indicates that EPR Mode can be entered.
The Policy Engine **Shall** transition to the `PE_SRC_EPR_Mode_Entry_Failed` State when:
- The Device Policy Manager indicates that the EPR Mode is not to be entered.
<!-- page 383 -->
###### 9.2.26.3.1.2. PE_SRC_EPR_Mode_Entry_Ack State
On entry to the `PE_SRC_EPR_Mode_Entry_Ack` State the Policy Engine **Shall** send a `EPR_Mode` (Enter Acknowledged) Message.
The Policy Engine **Shall** transition to the `PE_SRC_EPR_Mode_Evaluate_Cable_EPR` State when:
- The `EPR_Mode` (Enter Acknowledged) Message has been sent and
- The Source is not the VCONN Source and
- The cable is a captive cable or a known EPR Cable.
The Policy Engine **Shall** transition to the `PE_VCS_Send_Swap` State when:
- The `EPR_Mode` (Enter Acknowledged) Message has been sent and
- The Source is not the VCONN Source and
- The cable is unknown.
The Policy Engine **Shall** transition to the `PE_SRC_EPR_Mode_Discover_Cable` State when:
- The `EPR_Mode` (Enter Acknowledged) Message has been sent and
- The Source is the VCONN Source and
- The cable is unknown.
###### 9.2.26.3.1.3. PE_SRC_EPR_Mode_Discover_Cable State
The Policy Engine transitions to the `PE_SRC_EPR_Mode_Discover_Cable` State from the `PE_VCS_Force_VCONN` State or `PE_VCS_Send_Ps_Rdy` State when:
- A Source initiated `VCONN Swap` process has completed.
The Policy Engine **Shall** transition to the `PE_INIT_Port_VDM_Identity_Request` State in order to perform Cable Plug discovery when:
- The Source is the VCONN Source.
The Policy Engine **Shall** transition to the `PE_SRC_EPR_Mode_Entry_Failed` State when:
- The `VCONN Swap` process failed (the Source is not the VCONN Source).
###### 9.2.26.3.1.4. PE_SRC_EPR_Mode_Evaluate_Cable_EPR State
In the `PE_SRC_EPR_Mode_Evaluate_Cable_EPR` State the Policy Engine requests the DPM to evaluate the Cable Discovery results.
The Policy Engine **Shall** transition to the `PE_SRC_EPR_Mode_Entry_Succeeded` State when:
- The Cable Plug is capable of EPR Mode.
The Policy Engine **Shall** transition to the `PE_SRC_EPR_Mode_Entry_Failed` State when:
- The Cable Plug is not capable of EPR Mode.
###### 9.2.26.3.1.5. PE_SRC_EPR_Mode_Entry_Succeeded State
On entry to the `PE_SRC_EPR_Mode_Entry_Succeeded` State the Policy Engine **Shall** send a `EPR_Mode` (Enter Succeeded) Message and enter EPR Mode.
<!-- page 384 -->
The Policy Engine **Shall** transition to the `PE_SRC_Send_Capabilities` State when:
- EPR Mode has been entered.
###### 9.2.26.3.1.6. PE_SRC_EPR_Mode_Entry_Failed State
On entry to the `PE_SRC_EPR_Mode_Entry_Failed` State the Policy Engine **Shall** send a `EPR_Mode` (Enter Failed) Message.
The Policy Engine **Shall** transition to the `PE_SRC_Ready` State when:
- The `EPR_Mode` (Enter Failed) Message has been sent.
##### 9.2.26.3.2. Sink EPR Mode Entry State Diagram
Figure 9.97 shows the State diagram for an EPR Sink initiating the EPR Mode Entry process.
**Figure 9.97. Sink EPR Mode Entry State Diagram**
![Figure 9.97. Sink EPR Mode Entry State Diagram](09-state-machine-diagrams/figure-9.97.png)
<!-- page 385 -->
###### 9.2.26.3.2.1. PE_SNK_Send_EPR_Mode_Entry State
The Policy Engine transitions to the `PE_SNK_Send_EPR_Mode_Entry` State from the `PE_SNK_Ready` State when:
- The DPM requests entry into EPR Mode.
On Entry to the `PE_SNK_Send_EPR_Mode_Entry` State the Policy Engine **Shall** send an `EPR_Mode` (Enter) Message and starts the SenderResponseTimer and the SinkEPREnterTimer.
Note: The SinkEPREnterTimer **Shall** continue to run in every State until it is stopped or times out. The Policy Engine **Shall** transition to the `PE_SNK_EPR_Mode_Wait_For_Response` State when:
- An `EPR_Mode` (Enter Acknowledge) Message is received.
The Policy Engine **Shall** transition to the `PE_SNK_Send_Soft_Reset` State when:
- An `EPR_Mode` Message is received which is not Enter Succeeded or
- The SenderResponseTimer times out or
- The SinkEPREnterTimer times out.
###### 9.2.26.3.2.2. PE_SNK_EPR_Mode_Wait_For_Response State
In the State the Policy Engine waits for a confirmation that the EPR Mode entry Request has succeeded. On exit from the `PE_SNK_EPR_Mode_Wait_For_Response` State the Policy Engine **Shall** stop the SinkEPREnterTimer and enter EPR Mode.
The Policy Engine **Shall** transition to the `PE_SNK_Send_Soft_Reset` State when:
- An `EPR_Mode` Message is received which is not Enter Succeeded or
- The SinkEPREnterTimer times out.
The Policy Engine **Shall** transition to the `PE_VCS_Evaluate_Swap` State when:
- A `VCONN_Swap` Message is received.
The Policy Engine **Shall** transition back from the `PE_VCS_Turn_Off_VCONN` State to the `PE_SNK_EPR_Mode_Wait_For_Response` State when:
- The `VCONN Swap` process has completed.
The Policy Engine **Shall** transition to the `PE_SNK_Wait_for_Capabilities` State when:
- An `EPR_Mode` (Enter Succeeded) Message has been received.
##### 9.2.26.3.3. Source EPR Mode Exit State Diagram
Figure 9.98 shows the State diagram for an EPR Source initiating the EPR Mode Exit process.
<!-- page 386 -->
**Figure 9.98. Source EPR Mode Exit State Diagram**
![Figure 9.98. Source EPR Mode Exit State Diagram](09-state-machine-diagrams/figure-9.98.png)
###### 9.2.26.3.3.1. PE_SRC_Send_EPR_Mode_Exit State
The Policy Engine transitions to the `PE_SRC_Send_EPR_Mode_Exit` State from the `PE_SRC_Ready` State when:
- The DPM requests exit from EPR Mode.
On Entry to the `PE_SRC_Send_EPR_Mode_Exit` State the Policy Engine **Shall** send an `EPR_Mode` (Exit) Message. On Exit from the `PE_SRC_Send_EPR_Mode_Exit` State the Policy Engine **Shall** exit EPR Mode.
The Policy Engine **Shall** transition to the `PE_SRC_Send_Capabilities` State when:
- The `EPR_Mode` (Exit) Message has been sent.
###### 9.2.26.3.3.2. PE_SRC_EPR_Mode_Exit_Received State
The Policy Engine transitions to the `PE_SRC_EPR_Mode_Exit_Received` State from the `PE_SRC_Ready` State when:
- An `EPR_Mode` (Exit) Message is received.
On Entry to the `PE_SRC_EPR_Mode_Exit_Received` State the Policy Engine **Shall** exit EPR Mode. The Policy Engine **Shall** transition to the `PE_SRC_Send_Capabilities` State when:
- In an Explicit Contract with an SPR PDO or APDO and
- EPR Mode has been exited.
The Policy Engine **Shall** transition to the `PE_SRC_Hard_Reset` State when:
- Not in an Explicit Contract with an SPR PDO or APDO.
<!-- page 387 -->
##### 9.2.26.3.4. Sink EPR Mode Exit State Diagram
Figure 9.99 shows the State diagram for an EPR Sink initiating the EPR Mode Exit process.
**Figure 9.99. Sink EPR Mode Exit State Diagram**
![Figure 9.99. Sink EPR Mode Exit State Diagram](09-state-machine-diagrams/figure-9.99.png)
###### 9.2.26.3.4.1. PE_SNK_Send_EPR_Mode_Exit State
The Policy Engine transitions to the `PE_SNK_Send_EPR_Mode_Exit` State from the `PE_SNK_Ready` State when:
- The DPM requests exit from EPR Mode.
On Entry to the `PE_SNK_Send_EPR_Mode_Exit` State the Policy Engine **Shall** send an `EPR_Mode` (Exit) Message. On Exit from the `PE_SNK_Send_EPR_Mode_Exit` State the Policy Engine **Shall** exit EPR Mode.
The Policy Engine **Shall** transition to the `PE_SNK_Wait_for_Capabilities` State when:
- The `EPR_Mode` (Exit) Message has been sent.
###### 9.2.26.3.4.2. PE_SNK_EPR_Mode_Exit_Received State
The Policy Engine transitions to the `PE_SNK_EPR_Mode_Exit_Received` State from the `PE_SNK_Ready` State when:
- An `EPR_Mode` (Exit) Message is received.
On Entry to the `PE_SNK_EPR_Mode_Exit_Received` State the Policy Engine **Shall** exit EPR Mode. The Policy Engine **Shall** transition to the `PE_SNK_Wait_for_Capabilities` State when:
- In an Explicit Contract with an SPR PDO or APDO and
<!-- page 388 -->
- EPR Mode has been exited.
The Policy Engine **Shall** transition to the `PE_SNK_Hard_Reset` State when:
- Not in an Explicit Contract with an SPR PDO or APDO.
#### 9.2.26.4. BIST State diagrams
##### 9.2.26.4.1. BIST Carrier Mode State Diagram
Figure 9.100 shows the State diagram required by a UUT, which can be either a Source, Sink or Cable Plug, when operating in BIST Carrier Mode. Transitions **Shall** be from either the `PE_SRC_Ready`, `PE_SNK_Ready` or `PE_CBL_Ready` states.
**Figure 9.100. BIST Carrier Mode State Diagram**
![Figure 9.100. BIST Carrier Mode State Diagram](09-state-machine-diagrams/figure-9.100.png)
###### 9.2.26.4.1.1. PE_BIST_Carrier_Mode State
The Source, Sink or Cable Plug **Shall** enter the `PE_BIST_Carrier_Mode` State from either the `PE_SRC_Ready`, `PE_SNK_Ready` or `PE_CBL_Ready` State when:
- A `BIST Message` is received with a BIST Carrier Mode BIST Data Object and
- VBUS is at `vSafe5V`.
On entry to the `PE_BIST_Carrier_Mode` State the Policy Engine **Shall** tell the Protocol Layer to go to BIST Carrier Mode (see Section 5.4.1) and **Shall** initialize and run the BISTContModeTimer.
<!-- page 389 -->
The Policy Engine **Shall** transition to either the `PE_SRC_Transition_to_default` State, `PE_SNK_Transition_to_default` State or `PE_CBL_Ready` State (as appropriate) when:
- The BISTContModeTimer times out.
##### 9.2.26.4.2. BIST Test Data Mode State Diagram
Figure 9.101 shows the State diagram required by a UUT, which can be either a Source, Sink, or Cable Plug, when operating in BIST Test Data Mode. Transitions **Shall** be from either the `PE_SRC_Ready`, `PE_SNK_Ready` or `PE_CBL_Ready` states.
**Figure 9.101. BIST Test Data Mode State Diagram**
![Figure 9.101. BIST Test Data Mode State Diagram](09-state-machine-diagrams/figure-9.101.png)
###### 9.2.26.4.2.1. PE_BIST_Test_Mode State
The Source, Sink or Cable Plug **Shall** enter the `PE_BIST_Test_Mode` State from either the `PE_SRC_Ready`, `PE_SNK_Ready` or `PE_CBL_Ready` State when:
- A `BIST Message` is received with a BIST Test Data BIST Data Object and
- VBUS is at `vSafe5V`.
On entry to the `PE_BIST_Test_Mode` State the Policy Engine **Shall** tell the Protocol Layer to go into BIST Test Data Mode where it sends no further Messages except for `GoodCRC Messages` in response to received Messages (see Section 6.4.3).
<!-- page 390 -->
The Policy Engine **Shall** transition to either the PE_SRC_Transition_to_default State, PE_SNK_Transition_to_default State or PE_CBL_Ready State (as appropriate) when:
- A Hard Reset occurs.
##### 9.2.26.4.3. BIST Shared Capacity Test Mode State Diagram
Figure 9.102 shows the State diagram required by a UUT, which can be either a Source, Sink, or Cable Plug, when operating in BIST Shared Capacity Test Mode. Transitions **Shall** be from either the PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready states.
**Figure 9.102. BIST Shared Capacity Test Mode State Diagram**
![Figure 9.102. BIST Shared Capacity Test Mode State Diagram](09-state-machine-diagrams/figure-9.102.png)
1. The UUT **Shall** exit BIST Shared Capacity Test Mode when It is powered off. The UUT **Shall** remain in BIST Shared Capacity Test Mode for any PD event (except when a BIST Shared Test Mode Exit BIST Data Object, is received); specifically the UUT **Shall** remain in BIST Shared Capacity Test Mode when any of the following PD events occurs: Hard Reset, Cable Reset, Soft Reset, Data Role Swap, Power Role Swap, Fast Role Swap, VCONN Swap. The UUT May leave test Mode if the Tester makes a Request that exceeds the Capabilities of the UUT.
###### 9.2.26.4.3.1. PE_BIST_Shared_Capacity_Test_Mode State
The Source, Sink or Cable Plug **Shall** enter the PE_BIST_Shared_Capacity_Test_Mode state when:
- A BIST Message is received with a BIST Shared Test Mode Entry BIST Data Object and
<!-- page 391 -->
- VBUS is at vSafe5V.
On entry to the PE_BIST_Shared_Capacity_Test_Mode State the Policy Engine **Shall** tell the Protocol Layer to go to BIST Shared Capacity Test Mode (see Section 6.4.3).
The Policy Engine **Shall** transition to either the PE_SRC_Transition_to_default State, PE_SNK_Transition_to_default State or PE_CBL_Ready State (as appropriate) when:
- A BIST Message is received with a BIST Shared Test Mode Exit BIST Data Object.
#### 9.2.26.5. USB Type-C Referenced States
This section contains states cross-referenced from the [USB-C] specification.
##### 9.2.26.5.1. ErrorRecovery State
The ErrorRecovery State is used to electronically disconnect Port Partners using the USB Type-C connector. The ErrorRecovery State **Shall** be entered when there are errors on USB Type-C Ports which cannot be recovered by Hard Reset. The ErrorRecovery State **Shall** map to USB Type-C ErrorRecovery State operation as defined in the [USB-C] specification. Bus powered Sinks **Shall Not** be required to meet this requirement as removal of their power will serve the same purpose.
On entry to the ErrorRecovery State the Explicit Contract and PD Connection **Shall** be ended.
On exit from the ErrorRecovery State a new Explicit Contract Should be established once the Port Partners have re-Connected over the CC wire.
Reference in a new issue Copy permalink