Universal Serial Bus

Power Delivery Specification

Revision 2.0, V1.1. 7 May 2015

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 1

Editors

Bob Dunstan Intel Corporation

Richard Petrie DisplayLink

Contributors
Joseph Scanlon Advanced Micro Devices

Howard Chang Allion Labs, Inc.

Greg Stewart Analogix Semiconductor, Inc.

Mehran Badii Analogix Semiconductor, Inc.

Bill Cornelius Apple

Colin Whitby-Strevens Apple

Corey Axelowitz Apple

Corey Lange Apple

James Orr Apple

Jason Chung Apple

Jennifer Tsai Apple

Karl Bowers Apple

Keith Porthouse Apple

Paul Baker Apple

Reese Schreiber Apple

Sasha Tietz Apple

Sree Raman Apple

William Ferry Apple

Zaki Moussaoui Apple

Shawn Meng Bizlink Technology Inc.

Alessandro Ingrassia Canova Tech

Andrea Colognese Canova Tech

Davide Ghedin Canova Tech

Page 2 USB Power Delivery Specification Revision 2.0, Version 1.1

 Matteo Casalin Canova Tech

Nicola Scantamburlo Canova Tech

Anup Nayak Cypress Semiconductor

Rushil Kadakia Cypress Semiconductor

Steven Wong Cypress Semiconductor

Subu Sankaran Cypress Semiconductor

Adolfo Montero Dell Inc.

Bruce Montag Dell Inc.

Gary Verdun Dell Inc.

Merle Wood Dell Inc.

Mohammed Hijazi Dell Inc.

Siddhartha Reddy Dell Inc.

Dan Ellis DisplayLink

Jason Young DisplayLink

Peter Burgers DisplayLink

Richard Petrie DisplayLink PD Chair/Device Policy Lead

Chuck Trefts Ellisys

Emmanuel Durin Ellisys

Mario Pasquali Ellisys

Chien-Cheng Kuo Etron Technology, Inc.

Jack Yang Etron Technology, Inc.

Richard Crisp Etron Technology, Inc.

Shyanjia Chen Etron Technology, Inc.

TsungTa Lu Etron Technology, Inc.

Christian Klein Fairchild Semiconductor

Oscar Freitas Fairchild Semiconductor

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 3

 AJ Yang Foxconn / Hon Hai

Steve Sedio Foxconn / Hon Hai

Terry Little Foxconn / Hon Hai

Dian Kurniawan Fresco Logic Inc.

Adam Rodriguez Google Inc.

Alec Berg Google Inc.

David Schneider Google Inc.

Jim Guerin Google Inc.

Juan Fantin Google Inc.

Ken Wu Google Inc.

Mark Hayter Google Inc.

Todd Broch Google Inc.

Vincent Palatin Google Inc.

Mike Engbretson Granite River Labs

Rajaraman V Granite River Labs

Alan Berkema Hewlett Packard

Lee Atkinson Hewlett Packard

Rahul Lakdawala Hewlett Packard

Robin Castell Hewlett Packard

Roger Benson Hewlett Packard

Ron Schooley Hewlett Packard

Vaibhav Malik Hewlett Packard

Walter Fry Hewlett Packard

Bob Dunstan Intel Corporation PD Chair/Protocol WG Lead

Brad Saunders Intel Corporation

Chee Lim Nge Intel Corporation

Page 4 USB Power Delivery Specification Revision 2.0, Version 1.1

 Christine Krause Intel Corporation

Dan Froelich Intel Corporation

David Harriman Intel Corporation

Guobin Liu Intel Corporation

Harry Skinner Intel Corporation

Henrik Leegaard Intel Corporation

Jervis Lin Intel Corporation

John Howard Intel Corporation

Karthi Vadivelu Intel Corporation

Leo Heiland Intel Corporation

Maarit Harkonen Intel Corporation

Nge Chee Lim Intel Corporation

Paul Durley Intel Corporation

Rahman Ismail Intel Corporation System Policy Lead

Ronald Swartz Intel Corporation

Sarah Sharp Intel Corporation

Scott Brenden Intel Corporation

Sridharan
Intel Corporation
Ranganathan

Steve McGowan Intel Corporation

Tim McKee Intel Corporation PD Chair/Compliance Lead

Toby Opferman Intel Corporation

Kenta Minejima Japan Aviation Electronics Industry Ltd. (JAE)

Mark Saubert Japan Aviation Electronics Industry Ltd. (JAE)

Toshio Shimoyama Japan Aviation Electronics Industry Ltd. (JAE)

Gianluca Mariani Lattice Semiconductor Corp

Thomas Watza Lattice Semiconductor Corp

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 5

 Vesa Lauri Lattice Semiconductor Corp

Daniel H Jacobs LeCroy Corporation

Jake Jacobs LeCroy Corporation

Kimberley McKay LeCroy Corporation

Mike Micheletti LeCroy Corporation

Roy Chestnut LeCroy Corporation

Dave Thompson LSI Corporation

Alan Kinningham Luxshare-ICT

Daniel Chen Luxshare-ICT

Josue Castillo Luxshare-ICT

Chris Yokum MCCI Corporation

Geert Knapen MCCI Corporation

Velmurugan Selvaraj MCCI Corporation

Brian Marley Microchip Technology Inc.

Dave Perchlik Microchip Technology Inc.

Don Perkins Microchip Technology Inc.

John Sisto Microchip Technology Inc.

Josh Averyt Microchip Technology Inc.

Kiet Tran Microchip Technology Inc.

Mark Bohm Microchip Technology Inc.

Matthew Kalibat Microchip Technology Inc.

Mick Davis Microchip Technology Inc.

Rich Wahler Microchip Technology Inc.

Shannon Cash Microchip Technology Inc.

David Voth Microsoft Corporation

Jayson Kastens Microsoft Corporation

Page 6 USB Power Delivery Specification Revision 2.0, Version 1.1

 Kai Inha Microsoft Corporation

Marwan Kadado Microsoft Corporation

Randy Aull Microsoft Corporation

Shiu Ng Microsoft Corporation

Toby Nixon Microsoft Corporation

Vivek Gupta Microsoft Corporation

Yang You Microsoft Corporation

Ben Crowe MQP Electronics Ltd.

Pat Crowe MQP Electronics Ltd.

Sten Carlsen MQP Electronics Ltd.

Frank Borngräber Nokia Corporation

Kai Inha Nokia Corporation

Pekka Leinonen Nokia Corporation

Richard Petrie Nokia Corporation PD Vice-Chair/Device Policy Lead

Sten Carlsen Nokia Corporation Physical Layer WG Lead

Abhijeet Kulkarni NXP Semiconductors

Ahmad Yazdi NXP Semiconductors

Bart Vertenten NXP Semiconductors

Dong Nguyen NXP Semiconductors

Ken Jaramillo NXP Semiconductors

Krishnan TN NXP Semiconductors

Robert de Nie NXP Semiconductors

Rod Whitby NXP Semiconductors

Vijendra Kuroodi NXP Semiconductors

Robert Heaton Obsidian Technology

Bryan McCoy ON Semiconductor

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 7

 Cor Voorwinden ON Semiconductor

Edward Berrios ON Semiconductor Power Supply WG Lead

Tom Duffy ON Semiconductor

Craig Wiley Parade Technologies Inc.

Ricardo Pregiteer Power Integrations

Narendra Mehta Qualcomm, Inc.

Terry Remple Qualcomm, Inc.

Yoram Rimoni Qualcomm, Inc.

Atsushi Mitamura Renesas Electronics Corp.

Dan Aoki Renesas Electronics Corp.

Kiichi Muto Renesas Electronics Corp.

Masami Katagiri Renesas Electronics Corp.

Nobuo Furuya Renesas Electronics Corp.

Patrick Yu Renesas Electronics Corp.

Peter Teng Renesas Electronics Corp.

Philip Leung Renesas Electronics Corp.

Steve Roux Renesas Electronics Corp.

Tetsu Sato Renesas Electronics Corp.

Tatsuya Irisawa Ricoh Company Ltd.

Akihiro Ono Rohm Co. Ltd.

Chris Lin Rohm Co. Ltd.

Hidenori Nishimoto Rohm Co. Ltd.

Manabu Miyata Rohm Co. Ltd.

Ruben Balbuena Rohm Co. Ltd.

Takashi Sato Rohm Co. Ltd.

Vijendra Kuroodi Rohm Co. Ltd.

Page 8 USB Power Delivery Specification Revision 2.0, Version 1.1

 Yusuke Kondo Rohm Co. Ltd.

Matti Kulmala Salcomp Plc

Toni Lehimo Salcomp Plc

Tong Kim Samsung Electronics Co. Ltd.

Alvin Cox Seagate Technology LLC Cab Con WG Lead

John Hein Seagate Technology LLC

Marc Noblitt Seagate Technology LLC

Ronald Rueckert Seagate Technology LLC

Tony Priborsky Seagate Technology LLC

John Sisto SMSC

Ken Gay SMSC

Mark Bohm SMSC

Richard Wahler SMSC

Shannon Cash SMSC

Tim Knowlton SMSC

William Chiechi SMSC

Fabien Friess ST-Ericsson

Giuseppe Platania ST-Ericsson

Jean-Francois Gatto ST-Ericsson

Milan Stamenkovic ST-Ericsson

Nicolas Florenchie ST-Ericsson

Patrizia Milazzo ST-Ericsson

Christophe Lorin ST-Microelectronics

Meriem Mersel ST-Microelectronics

Pascal Legrand ST-Microelectronics

Patrizia Milazzo ST-Microelectronics

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 9

 Joan Marrinan Tektronix

Kimberley McKay Teledyne-LeCroy

Matthew Dunn Teledyne-LeCroy

Tony Minchell Teledyne-LeCroy

Anand Dabak Texas Instruments

Bill Waters Texas Instruments

Deric Waters Texas Instruments Physical Layer WG Lead

Grant Ley Texas Instruments

Ingolf Frank Texas Instruments

Ivo Huber Texas Instruments

Javed Ahmad Texas Instruments

Jean Picard Texas Instruments

Martin Patoka Texas Instruments

Scott Jackson Texas Instruments

Srinath Hosur Texas Instruments

Steven Tom Texas Instruments

Dydron Lin VIA Technologies, Inc.

Fong-Jim Wang VIA Technologies, Inc.

Jay Tseng VIA Technologies, Inc.

Rex Change VIA Technologies, Inc.

Terrance Shih VIA Technologies, Inc.

Charles Neumann Western Digital Technologies, Inc.

Curtis Stevens Western Digital Technologies, Inc.

John Maroney Western Digital Technologies, Inc.

Page 10 USB Power Delivery Specification Revision 2.0, Version 1.1

 Revision History

Revision Version Comments Issue Date

1.0 1.0 Initial release Revision 1.0 5 July, 2012

1.0 1.1 Including errata through 31-October-2012 31 October 2012

1.0 1.2 Including errata through 26-June-2013 26 June, 2013

1.0 1.3 Including errata through 11-March-2014 11 March 2014

2.0 1.0 Initial release Revision 2.0 11 August 2014

2.0 1.1 Including errata through 7-May 2015 7 May 2015

INTELLECTUAL PROPERTY DISCLAIMER

THIS SPECIFICATION IS PROVIDED TO YOU “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY
WARRANTY OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE. THE
AUTHORS OF THIS SPECIFICATION DISCLAIM ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY
PROPRIETARY RIGHTS, RELATING TO USE OR IMPLEMENTATION OF INFORMATION IN THIS SPECIFICATION. THE
PROVISION OF THIS SPECIFICATION TO YOU DOES NOT PROVIDE YOU WITH ANY LICENSE, EXPRESS OR
IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS.

Please send comments via electronic mail to techsup@usb.org

For industry information, refer to the USB Implementers Forum web page at http://www.usb.org

All product names are trademarks, registered trademarks, or service marks of their respective owners.
Copyright © 2010-2015 Hewlett-Packard Company, Intel Corporation, LSI Corporation, Microsoft Corporation,
Renesas, STMicroelectronics, and Texas Instruments
All rights reserved.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 11

Table of Contents

Contributors ................................................................................................................ 2
Revision History ..........................................................................................................11
Table of Contents .......................................................................................................12
List of Tables ...............................................................................................................22
List of Figures..............................................................................................................27
1. Introduction .........................................................................................................35
1.1 Overview ................................................................................................................................................................................... 35
1.2 Purpose ...................................................................................................................................................................................... 36
1.3 Scope ........................................................................................................................................................................................... 36
1.4 Conventions ............................................................................................................................................................................. 36
1.4.1 Precedence .......................................................................................................................................................................... 36
1.4.2 Keywords ............................................................................................................................................................................. 36
1.4.3 Numbering .......................................................................................................................................................................... 37
1.5 Related Documents ............................................................................................................................................................... 38
1.6 Terms and Abbreviations ................................................................................................................................................... 38
1.7 Parameter Values................................................................................................................................................................... 43
2. Overview..............................................................................................................44
2.1 Introduction ............................................................................................................................................................................. 44
2.2 Section Overview ................................................................................................................................................................... 45
2.3 USB Power Delivery Capable Devices ........................................................................................................................... 46
2.4 SOP* Communication with Cable Plugs ........................................................................................................................ 47
2.4.1 SOP’ Communication....................................................................................................................................................... 47
2.4.2 SOP’’ Communication...................................................................................................................................................... 48
2.5 Operational Overview .......................................................................................................................................................... 49
2.5.1 DFP Operation ................................................................................................................................................................... 49
2.5.2 UFP Operation.................................................................................................................................................................... 52
2.5.3 Cable Plug Operation ...................................................................................................................................................... 55
2.6 Architectural Overview ....................................................................................................................................................... 56
2.6.1 Policy ..................................................................................................................................................................................... 58

Page 12 USB Power Delivery Specification Revision 2.0, Version 1.1

 2.6.2 Message Formation and Transmission.................................................................................................................... 59
2.6.3 Power supply ..................................................................................................................................................................... 59
2.6.4 Cable and Connectors ..................................................................................................................................................... 60
3. Type-A and Type-B Cable Assemblies and Connectors ..........................................61
3.1 Significant Features .............................................................................................................................................................. 61
3.1.1 Connectors .......................................................................................................................................................................... 61
3.1.2 Compliant Cable Assemblies ........................................................................................................................................ 63
3.1.3 USB Power Delivery Adapters (USB plug to USB receptacle) ........................................................................ 64
3.1.4 Hardwired Captive PD Cable ....................................................................................................................................... 64
3.1.5 Standard-A Insertion Detect ........................................................................................................................................ 64
3.1.6 Standard-A PD Detect ..................................................................................................................................................... 64
3.1.7 Raw Cables .......................................................................................................................................................................... 65
3.2 Connector Mating Interfaces............................................................................................................................................. 66
3.2.1 Standard-A Insertion Detect Mechanical Dimensions ...................................................................................... 66
3.2.2 USB PD Standard-A PD Detect Mechanical Requirement ................................................................................ 66
3.2.3 USB 2.0 PD Standard-A Connector ............................................................................................................................ 67
3.2.4 USB 3.1 PD Standard-A Connector ............................................................................................................................ 72
3.2.5 USB 2.0 PD Standard-B Connector ............................................................................................................................ 76
3.2.6 USB 3.1 PD Standard-B Connector ............................................................................................................................ 79
3.3 Cable Assemblies ................................................................................................................................................................... 84
3.3.1 Non-marked Cable Assemblies ................................................................................................................................... 84
3.3.2 Marked Cable Assemblies ............................................................................................................................................. 84
3.3.3 PD Cable Assembly Overmold Requirements ....................................................................................................... 84
3.4 PD Cable Assembly Marking ............................................................................................................................................. 86
3.4.1 Marker for PD Standard-A Connectors.................................................................................................................... 86
3.4.2 Electronic Markers for Micro-A Plugs...................................................................................................................... 86
3.4.3 Electronic Markers for PD Standard-B Plugs and Micro-B Plugs ................................................................. 87
3.5 USB PD Icon.............................................................................................................................................................................. 88
3.6 USB Power Delivery Cable Requirements ................................................................................................................... 89
3.6.1 Low Level Contact Resistance (EIA 364-23B) ...................................................................................................... 89
3.6.2 Open Circuit Resistance ................................................................................................................................................. 89
3.6.3 Dielectric Strength (EIA 364-20) ............................................................................................................................... 89
3.6.4 Insulation Resistance (EIA 364-21).......................................................................................................................... 89

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 13

 3.6.5 Contact Current Rating .................................................................................................................................................. 90
3.6.6 Differential Crosstalk between VBUS and the D+/D- Pair (EIA-360-90) ..................................................... 90
3.6.7 PD Cable Assembly Shielding Connectivity ........................................................................................................... 90
3.6.8 PD Cable VBUS Impedance .............................................................................................................................................. 91
3.6.9 PD Cable Insertion Loss ................................................................................................................................................. 91
3.6.10 PD Cable IR Drop Considerations .............................................................................................................................. 91
3.7 Electrical Parameters ........................................................................................................................................................... 93
4. Electrical Requirements........................................................................................94
4.1 Dead Battery Detection / Unpowered Port Detection............................................................................................ 94
4.1.1 Type-A to Type-B Dead Battery Operation ............................................................................................................ 94
4.1.2 Type-C to Type-C Dead Battery Operation ............................................................................................................ 98
4.2 Cable IR Ground Drop (IR Drop) ..................................................................................................................................... 98
4.3 A-Plug Insertion Detect ....................................................................................................................................................... 98
4.4 Cable Type Detection ........................................................................................................................................................... 98
4.4.1 Detecting Cabling Capabilities .................................................................................................................................... 98
4.4.2 Plug Type Determination .............................................................................................................................................. 99
4.4.3 Detecting the PD Capabilities of the Standard-A Connector........................................................................ 100
4.4.4 Plug Type Detection except Standard-A .............................................................................................................. 101
4.5 Low Power Devices using Micro-A Plug .................................................................................................................... 102
4.6 Electrical Parameters ........................................................................................................................................................ 103
5. Physical Layer..................................................................................................... 104
5.1 Physical Layer Overview ................................................................................................................................................. 104
5.2 Physical Layer Functions ................................................................................................................................................. 104
5.3 Symbol Encoding ................................................................................................................................................................ 105
5.4 Ordered Sets ......................................................................................................................................................................... 106
5.5 Transmitted Bit Ordering ................................................................................................................................................ 107
5.6 Packet Format ...................................................................................................................................................................... 108
5.6.1 Packet Framing............................................................................................................................................................... 108
5.6.2 CRC ...................................................................................................................................................................................... 110
5.6.3 Packet Detection Errors.............................................................................................................................................. 112
5.6.4 Hard Reset ........................................................................................................................................................................ 112
5.6.5 Cable Reset ....................................................................................................................................................................... 113
5.7 Collision Avoidance............................................................................................................................................................ 113

Page 14 USB Power Delivery Specification Revision 2.0, Version 1.1

5.8 Physical Layer Signaling Schemes ............................................................................................................................... 114
5.8.1 Common Signaling Scheme Specifications .......................................................................................................... 114
5.8.2 Binary Frequency Shift Keyed (BFSK) Signaling Scheme ............................................................................. 116
5.8.3 Biphase Mark Coding (BMC) Signaling Scheme ................................................................................................ 124
5.8.4 Interoperability with BFSK and BMC .................................................................................................................... 139
5.9 Built in Self-Test (BIST) ................................................................................................................................................... 140
5.9.1 BIST PRBS Pattern ........................................................................................................................................................ 140
5.9.2 BIST Carrier Mode 0 ..................................................................................................................................................... 141
5.9.3 BIST Carrier Mode 1 ..................................................................................................................................................... 141
5.9.4 BIST Carrier Mode 2 ..................................................................................................................................................... 141
5.9.5 BIST Carrier Mode 3 ..................................................................................................................................................... 141
5.9.6 BIST Eye Pattern ............................................................................................................................................................ 141
5.9.7 BIST Test Data ................................................................................................................................................................ 142
5.9.8 BIST Parameters ............................................................................................................................................................ 142
5.9.9 BIST Test Applicability ................................................................................................................................................ 142
6. Protocol Layer .................................................................................................... 143
6.1 Overview ................................................................................................................................................................................ 143
6.2 Messages ................................................................................................................................................................................ 143
6.2.1 Message Construction.................................................................................................................................................. 143
6.3 Control Message .................................................................................................................................................................. 146
6.3.1 GoodCRC Message ......................................................................................................................................................... 146
6.3.2 GotoMin Message........................................................................................................................................................... 146
6.3.3 Accept Message .............................................................................................................................................................. 147
6.3.4 Reject Message ............................................................................................................................................................... 147
6.3.5 Ping Message ................................................................................................................................................................... 147
6.3.6 PS_RDY Message ............................................................................................................................................................ 148
6.3.7 Get_Source_Cap Message ............................................................................................................................................ 148
6.3.8 Get_Sink_Cap Message ................................................................................................................................................. 148
6.3.9 DR_Swap Message ......................................................................................................................................................... 148
6.3.10 PR_Swap Message.......................................................................................................................................................... 149
6.3.11 VCONN_Swap Message ................................................................................................................................................ 149
6.3.12 Wait Message .................................................................................................................................................................. 150
6.3.13 Soft Reset Message........................................................................................................................................................ 151

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 15

6.4 Data Message ........................................................................................................................................................................ 151
6.4.1 Capabilities Message .................................................................................................................................................... 152
6.4.2 Request Message ........................................................................................................................................................... 159
6.4.3 BIST Message .................................................................................................................................................................. 163
6.4.4 Vendor Defined Message ............................................................................................................................................ 167
6.5 Timers ..................................................................................................................................................................................... 184
6.5.1 CRCReceiveTimer .......................................................................................................................................................... 184
6.5.2 SenderResponseTimer ................................................................................................................................................ 184
6.5.3 Activity Timers ............................................................................................................................................................... 184
6.5.4 Capability Timers .......................................................................................................................................................... 185
6.5.5 SinkRequestTimer......................................................................................................................................................... 186
6.5.6 Power Supply Timers .................................................................................................................................................. 186
6.5.7 NoResponseTimer......................................................................................................................................................... 187
6.5.8 BIST Timers ..................................................................................................................................................................... 187
6.5.9 Power Role Swap Timers ........................................................................................................................................... 188
6.5.10 Hard Reset Timers ........................................................................................................................................................ 189
6.5.11 Structured VDM Timers .............................................................................................................................................. 189
6.5.12 VCONN Timers ................................................................................................................................................................ 190
6.5.13 tCableMessage ................................................................................................................................................................ 190
6.5.14 DiscoverIdentityTimer ................................................................................................................................................ 191
6.5.15 Attention Timers............................................................................................................................................................ 191
6.5.16 Time Values and Timers ............................................................................................................................................. 191
6.6 Counters ................................................................................................................................................................................. 194
6.6.1 MessageID Counter ....................................................................................................................................................... 194
6.6.2 Retry Counter.................................................................................................................................................................. 194
6.6.3 Hard Reset Counter ...................................................................................................................................................... 194
6.6.4 Capabilities Counter ..................................................................................................................................................... 194
6.6.5 BIST Error Counter ....................................................................................................................................................... 195
6.6.6 Discover Identity Counter.......................................................................................................................................... 195
6.6.7 VDMBusyCounter .......................................................................................................................................................... 195
6.6.8 nAttentionCount ............................................................................................................................................................ 195
6.6.9 Counter Values and Counters ................................................................................................................................... 195
6.7 Reset......................................................................................................................................................................................... 196
6.7.1 Soft Reset .......................................................................................................................................................................... 196

Page 16 USB Power Delivery Specification Revision 2.0, Version 1.1

 6.7.2 Hard Reset ........................................................................................................................................................................ 196
6.7.3 Cable Reset ....................................................................................................................................................................... 197
6.8 State behavior ...................................................................................................................................................................... 198
6.8.1 Introduction to state diagrams used in Chapter 6 ........................................................................................... 198
6.8.2 State Operation............................................................................................................................................................... 198
6.8.3 BIST Operation ............................................................................................................................................................... 207
6.8.4 List of Protocol Layer States ..................................................................................................................................... 211
6.9 Message Applicability ....................................................................................................................................................... 212
7. Power Supply ..................................................................................................... 215
7.1 Source Requirements ........................................................................................................................................................ 215
7.1.1 Behavioral Aspects ....................................................................................................................................................... 215
7.1.2 Source Bulk Capacitance ............................................................................................................................................ 215
7.1.3 Types of Sources ............................................................................................................................................................ 216
7.1.4 Positive Voltage Transitions ..................................................................................................................................... 216
7.1.5 Negative Voltage Transitions ................................................................................................................................... 217
7.1.6 Response to Hard Resets ............................................................................................................................................ 217
7.1.7 Changing the Output Power Capability ................................................................................................................ 219
7.1.8 Safe Operating Considerations ................................................................................................................................ 219
7.1.9 Output Voltage Tolerance and Range ................................................................................................................... 219
7.1.10 Charging and Discharging the Bulk Capacitance on VBUS .............................................................................. 220
7.1.11 Swap Standby for Sources ......................................................................................................................................... 220
7.1.12 Source Peak Current Operation ............................................................................................................................... 220
7.1.13 BFSK over VBUS Considerations for Sources........................................................................................................ 221
7.2 Sink Requirements ............................................................................................................................................................. 224
7.2.1 Behavioral Aspects ....................................................................................................................................................... 224
7.2.2 Sink Bulk Capacitance.................................................................................................................................................. 224
7.2.3 Sink Standby .................................................................................................................................................................... 225
7.2.4 Suspend Power Consumption .................................................................................................................................. 225
7.2.5 Zero Negotiated Current............................................................................................................................................. 225
7.2.6 Transient Load Behavior ............................................................................................................................................ 225
7.2.7 Swap Standby for Sinks............................................................................................................................................... 225
7.2.8 Sink Peak Current Operation .................................................................................................................................... 225
7.2.9 BFSK over VBUS Considerations for Sinks ............................................................................................................. 225

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 17

 7.2.10 Safe Operating Considerations ................................................................................................................................ 227
7.3 Transitions ............................................................................................................................................................................ 229
7.3.1 Increasing the Current ................................................................................................................................................ 230
7.3.2 Increasing the Voltage ................................................................................................................................................. 232
7.3.3 Increasing the Voltage and Current ....................................................................................................................... 234
7.3.4 Increasing the Voltage and Decreasing the Current ....................................................................................... 236
7.3.5 Decreasing the Voltage and Increasing the Current ....................................................................................... 238
7.3.6 Decreasing the Current ............................................................................................................................................... 240
7.3.7 Decreasing the Voltage................................................................................................................................................ 242
7.3.8 Decreasing the Voltage and the Current .............................................................................................................. 244
7.3.9 Sink Requested Power Role Swap .......................................................................................................................... 246
7.3.10 Source Requested Power Role Swap ..................................................................................................................... 249
7.3.11 GotoMin Current Decrease ........................................................................................................................................ 252
7.3.12 Source Initiated Hard Reset ...................................................................................................................................... 254
7.3.13 Sink Initiated Hard Reset ........................................................................................................................................... 256
7.3.14 Type-A/B Hard Reset after a Power Role Swap ............................................................................................... 258
7.3.15 Type-A to Type-B Dead Battery Operation ......................................................................................................... 266
7.3.19 No change in Current or Voltage ............................................................................................................................. 268
7.4 Electrical Parameters ........................................................................................................................................................ 270
7.4.1 Source Electrical Parameters ................................................................................................................................... 270
7.4.2 Sink Electrical Parameters......................................................................................................................................... 272
7.4.3 Common Electrical Parameters ............................................................................................................................... 274
8. Device Policy ...................................................................................................... 275
8.1 Overview ................................................................................................................................................................................ 275
8.2 Device Policy Manager...................................................................................................................................................... 275
8.2.1 Capabilities....................................................................................................................................................................... 276
8.2.2 System Policy .................................................................................................................................................................. 276
8.2.3 Control of Source/Sink ................................................................................................................................................ 276
8.2.4 Cable Detection .............................................................................................................................................................. 277
8.2.5 Managing Power Requirements .............................................................................................................................. 277
8.2.6 Use of “Externally Powered” bit with Batteries and AC supplies .............................................................. 279
8.2.7 Interface to the Policy Engine .................................................................................................................................. 280
8.3 Policy Engine ........................................................................................................................................................................ 282

Page 18 USB Power Delivery Specification Revision 2.0, Version 1.1

 8.3.1 Introduction..................................................................................................................................................................... 282
8.3.2 Message Sequence Diagrams .................................................................................................................................... 282
8.3.3 State Diagrams................................................................................................................................................................ 380
9. System Policy ..................................................................................................... 457
9.1 Overview ................................................................................................................................................................................ 457
9.1.1 PDUSB Device and Hub Requirements ................................................................................................................. 459
9.1.2 Mapping to USB Device States.................................................................................................................................. 460
9.1.3 PD Software Stack ......................................................................................................................................................... 462
9.1.4 PDUSB Device Enumeration ..................................................................................................................................... 463
9.2 PD Class Specific Descriptors......................................................................................................................................... 464
9.2.1 USB Power Delivery Capability Descriptor ........................................................................................................ 464
9.2.2 Battery Info Capability Descriptor ......................................................................................................................... 466
9.2.3 PD Consumer Port Capability Descriptor ............................................................................................................ 467
9.2.4 PD Provider Port Capability Descriptor ............................................................................................................... 468
9.3 PD Class Specific Requests and Events ...................................................................................................................... 470
9.3.1 Class-specific Requests ............................................................................................................................................... 470
9.3.2 PDUSB Hub Event Reporting .................................................................................................................................... 471
9.4 PDUSB Hub and PDUSB Peripheral Device Requests .......................................................................................... 473
9.4.1 ClearPortPDFeature (PDUSB Hub) ........................................................................................................................ 473
9.4.2 GetBatteryStatus (PDUSB Hub/Peripheral Device) ........................................................................................ 473
9.4.3 GetPortPartnerPDObjects (PDUSB Hub) ............................................................................................................. 475
9.4.4 GetPortPDStatus (PDUSB Hub) ............................................................................................................................... 476
9.4.5 SetPDFeature (PDUSB Hub/Peripheral Device) ............................................................................................... 478
9.4.6 SetPortPDFeature (PDUSB Hub) ............................................................................................................................. 480
9.4.7 SetPortPDOs (PDUSB Hub) ....................................................................................................................................... 481
9.4.8 GetVDM (PDUSB Hub) ................................................................................................................................................. 481
9.4.9 SendVDM (PDUSB Hub) .............................................................................................................................................. 482
A. Power Profiles .................................................................................................... 483
A.1 Profile Definitions............................................................................................................................................................... 483
A.2 Voltage Selection Rationale ............................................................................................................................................ 484
A.3 Relevance of Profiles to Sink Ports .............................................................................................................................. 484
A.4 System Level Examples .................................................................................................................................................... 485
A.4.1 Notebook and HDD Examples .................................................................................................................................. 485

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 19

 A.4.2 Display with Hub Example ........................................................................................................................................ 486
B. CRC calculation................................................................................................... 488
B.1 C code example .................................................................................................................................................................... 488
B.2 Table showing the full calculation over one Message ......................................................................................... 490
C. Power Implementation Considerations .............................................................. 491
C.1 Managing Isolation Impedance (BFSK) ..................................................................................................................... 491
C.1.1 In-band fCarrier Spurious Noise ............................................................................................................................. 491
C.1.2 Spurious Noise Test Setup and Calibration ....................................................................................................... 492
C.2 Connector Detach Transients ........................................................................................................................................ 494
C.3 Closed Loop Stability Effects .......................................................................................................................................... 495
C.3.1 Basic Power Stage Small Signal AC Model........................................................................................................... 495
C.3.2 Feedback Past Isolation Inductor ........................................................................................................................... 497
D. Standard-A Mating Illustrations ...................................................................... 499
E. Physical Layer Informative Material ................................................................... 506
E.1 Squelch Budget .................................................................................................................................................................... 506
F. PD Message Sequence Examples ........................................................................ 508
F.1 External power is supplied downstream .................................................................................................................. 508
F.2 External power is supplied upstream ........................................................................................................................ 512
F.3 Giving back power .............................................................................................................................................................. 519
G. VDM Command Examples .................................................................................. 532
G.1 Discover Identity Example .............................................................................................................................................. 532
G.1.1 Discover Identity Command request .................................................................................................................... 532
G.1.2 Discover Identity Command response – Active Cable.................................................................................... 532
G.1.3 Discover Identity Command response – Hub .................................................................................................... 533
G.2 Discover SVIDs Example .................................................................................................................................................. 535
G.2.1 Discover SVIDs Command request......................................................................................................................... 535
G.2.1 Discover SVIDs Command response...................................................................................................................... 535
G.3 Discover Modes Example ................................................................................................................................................ 537
G.3.1 Discover Modes Command request ....................................................................................................................... 537
G.3.2 Discover Modes Command response .................................................................................................................... 537
G.4 Enter Mode Example ......................................................................................................................................................... 539
G.4.1 Enter Mode Command request ................................................................................................................................ 539

Page 20 USB Power Delivery Specification Revision 2.0, Version 1.1

 G.4.2 Enter Mode Command response ............................................................................................................................. 539
G.4.1 Enter Mode Command request with additional VDO ..................................................................................... 540
G.5 Exit Mode Example ............................................................................................................................................................ 541
G.5.1 Exit Mode Command request ................................................................................................................................... 541
G.5.2 Exit Mode Command response ................................................................................................................................ 541
G.6 Attention Example.............................................................................................................................................................. 543
G.6.1 Attention Command request .................................................................................................................................... 543
G.6.2 Attention Command request with additional VDO.......................................................................................... 543

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 21

List of Tables
Table 1-1 Terms and Abbreviations ...................................................................................................................................................................... 38
Table 3-1 Plugs Accepted By Receptacles ........................................................................................................................................................... 62
Table 3-2 USB 2.0 PD Standard-A Connector Pin Assignments ................................................................................................................ 72
Table 3-3 USB 3.1 PD Standard-A Connector Pin Assignments ................................................................................................................ 76
Table 3-4 USB 2.0 PD Standard-B Connector Pin Assignments................................................................................................................. 79
Table 3-5 USB 3.1 PD Standard-B Connector Pin Assignments................................................................................................................. 83
Table 3-6 USB PD Cable Assembly Overmold Maximum Dimensions .................................................................................................... 84
Table 3-7 Electrical Parameters .............................................................................................................................................................................. 93
Table 4-1 Normal Dead Battery Operation ......................................................................................................................................................... 97
Table 4-2 Plug Type Determination..................................................................................................................................................................... 102
Table 4-3 Electrical Parameters ............................................................................................................................................................................ 103
Table 4-4 Electrical Timers...................................................................................................................................................................................... 103
Table 5-1 4b5b Symbol Encoding Table ............................................................................................................................................................ 105
Table 5-2 Ordered Sets .............................................................................................................................................................................................. 106
Table 5-3 Validation of Ordered Sets .................................................................................................................................................................. 106
Table 5-4 Data Size ...................................................................................................................................................................................................... 107
Table 5-5 SOP ordered set........................................................................................................................................................................................ 108
Table 5-6 SOP’ ordered set ...................................................................................................................................................................................... 109
Table 5-7 SOP’’ ordered set ..................................................................................................................................................................................... 109
Table 5-8 SOP’_Debug ordered set ....................................................................................................................................................................... 110
Table 5-9 SOP’’_Debug ordered set ...................................................................................................................................................................... 110
Table 5-10 CRC-32 Mapping ................................................................................................................................................................................... 111
Table 5-11 Hard Reset ordered set ...................................................................................................................................................................... 112
Table 5-12 Cable Reset ordered set ..................................................................................................................................................................... 113
Table 5-13 Common Normative Signaling Scheme Requirements ........................................................................................................ 114
Table 5-14 Common Normative Signaling Scheme Requirements for Transmitter ...................................................................... 114
Table 5-15 Common Normative Signaling Scheme Requirements for Receiver ............................................................................. 114
Table 5-16 BFSK Common Normative Requirements ................................................................................................................................. 118
Table 5-17 BFSK Transceiver Isolation Impedance Normative Requirements ............................................................................... 118
Table 5-18 BFSK Transmitter Normative Requirements ........................................................................................................................... 118
Table 5-19 BFSK Spectrum Mask Corners ........................................................................................................................................................ 121
Table 5-20 BFSK Receiver Normative Requirements .................................................................................................................................. 122
Table 5-21 BMC Tx Mask Definition, X Values ................................................................................................................................................ 129
Table 5-22 BMC Tx Mask Definition, Y Values ................................................................................................................................................ 129

Page 22 USB Power Delivery Specification Revision 2.0, Version 1.1

Table 5-23 BMC Rx Mask Definition .................................................................................................................................................................... 134
Table 5-24 BMC Common Normative Requirements ................................................................................................................................... 136
Table 5-25 BMC Transmitter Normative Requirements ............................................................................................................................ 136
Table 5-26 BMC Receiver Normative Requirements ................................................................................................................................... 137
Table 5-27 Allowable Bit Errors vs. Number of Test Frames ................................................................................................................... 141
Table 5-28 BIST Parameters ................................................................................................................................................................................... 142
Table 5-29 BIST Mode support .............................................................................................................................................................................. 142
Table 6-1 Message Header ....................................................................................................................................................................................... 144
Table 6-2 Control Message Types ......................................................................................................................................................................... 146
Table 6-3 Data Message Types ............................................................................................................................................................................... 151
Table 6-4 Power Data Object .................................................................................................................................................................................. 153
Table 6-5 Type-A to Type-A Port Behavior ...................................................................................................................................................... 154
Table 6-6 Fixed Supply PDO - Source .................................................................................................................................................................. 155
Table 6-7 Fixed Power Source Peak Current Capability ............................................................................................................................. 156
Table 6-8 Variable Supply (non-battery) PDO - Source .............................................................................................................................. 157
Table 6-9 Battery Supply PDO - Source .............................................................................................................................................................. 157
Table 6-10 Fixed Supply PDO - Sink .................................................................................................................................................................... 158
Table 6-11 Variable Supply (non-battery) PDO - Sink ................................................................................................................................ 159
Table 6-12 Battery Supply PDO - Sink ................................................................................................................................................................ 159
Table 6-13 Fixed and Variable Request Data Object .................................................................................................................................... 160
Table 6-14 Fixed and Variable Request Data Object with GiveBack Support ................................................................................... 160
Table 6-15 Battery Request Data Object............................................................................................................................................................ 160
Table 6-16 Battery Request Data Object with GiveBack Support........................................................................................................... 161
Table 6-17 BIST Data Object ................................................................................................................................................................................... 164
Table 6-18 Unstructured VDM Header ............................................................................................................................................................... 168
Table 6-19 Structured VDM Header .................................................................................................................................................................... 168
Table 6-20 Structured VDM Commands ............................................................................................................................................................ 169
Table 6-21 SVID Values ............................................................................................................................................................................................. 170
Table 6-22 Commands and Responses ............................................................................................................................................................... 171
Table 6-23 ID Header VDO ....................................................................................................................................................................................... 172
Table 6-24 Product Types ........................................................................................................................................................................................ 173
Table 6-25 Cert Stat VDO .......................................................................................................................................................................................... 173
Table 6-26 Product VDO ........................................................................................................................................................................................... 173
Table 6-27 Cable VDO ................................................................................................................................................................................................ 174
Table 6-28 AMA VDO .................................................................................................................................................................................................. 175
Table 6-29 Discover SVIDs Responder VDO .................................................................................................................................................... 176

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 23

Table 6-30 Time Values ............................................................................................................................................................................................. 191
Table 6-31 Timers........................................................................................................................................................................................................ 192
Table 6-32 Counter parameters ............................................................................................................................................................................ 195
Table 6-33 Counters ................................................................................................................................................................................................... 195
Table 6-34 Protocol Layer States .......................................................................................................................................................................... 211
Table 6-35 Applicability of Control Messages ................................................................................................................................................. 212
Table 6-36 Applicability of Type-C Specific Control Messages ................................................................................................................ 213
Table 6-37 Applicability of Data Messages ....................................................................................................................................................... 213
Table 6-38 Applicability of VDM Commands ................................................................................................................................................... 214
Table 7-1 Noise Spectral Mask Corners ............................................................................................................................................................. 223
Table 7-2 Noise Spectral Mask Corners ............................................................................................................................................................. 227
Table 7-3 Sequence Description for Increasing the Current .................................................................................................................... 231
Table 7-4 Sequence Description for Increasing the Voltage ..................................................................................................................... 233
Table 7-5 Sequence Diagram for Increasing the Voltage and Current ................................................................................................. 235
Table 7-6 Sequence Description for Increasing the Voltage and Decreasing the Current .......................................................... 237
Table 7-7 Sequence Description for Decreasing the Voltage and Increasing the Current .......................................................... 239
Table 7-8 Sequence Description for Decreasing the Current ................................................................................................................... 241
Table 7-9 Sequence Description for Decreasing the Voltage .................................................................................................................... 243
Table 7-10 Sequence Description for Decreasing the Voltage and the Current ............................................................................... 245
Table 7-11 Sequence Description for a Sink Requested Power Role Swap........................................................................................ 247
Table 7-12 Sequence Description for a Source Requested Power Role Swap .................................................................................. 250
Table 7-13 Sequence Description for a GotoMin Current Decrease ...................................................................................................... 253
Table 7-14 Sequence Description for a Source Initiated Hard Reset .................................................................................................... 255
Table 7-15 Sequence Description for a Sink Initiated Hard Reset ......................................................................................................... 257
Table 7-16 Sequence Description for Type-B New Source Initiated Hard Reset and Type-A New Sink Receives Hard
Reset Signaling .............................................................................................................................................................................................................. 259
Table 7-17 Sequence Description for Type-B New Source Initiated Hard Reset and Type-A New Sink Does Not Receive
Hard Reset Signaling ................................................................................................................................................................................................... 261
Table 7-18 Sequence Description for Type-A New Sink Initiated Hard Reset and Type-B New Source Receives Hard
Reset Signaling .............................................................................................................................................................................................................. 263
Table 7-19 Sequence Description for Type-A New Sink Initiated Hard Reset and Type-B New Source Does Not Receive
Hard Reset Signaling ................................................................................................................................................................................................... 265
Table 7-20 Sequence Description for Type-A to Type-B Dead Battery Operation ......................................................................... 267
Table 7-21 Sequence Description for no change in Current or Voltage .............................................................................................. 269
Table 7-22 Source Electrical Parameters .......................................................................................................................................................... 270
Table 7-23 Sink Electrical Parameters ............................................................................................................................................................... 272
Table 7-24 Common Source/Sink Electrical Parameters ........................................................................................................................... 274

Page 24 USB Power Delivery Specification Revision 2.0, Version 1.1

Table 8-1 Basic Message Flow ................................................................................................................................................................................ 283
Table 8-2 Potential issues in Basic Message Flow ......................................................................................................................................... 284
Table 8-3 Basic Message Flow with CRC failure ............................................................................................................................................. 285
Table 8-4 Steps for a successful Power Negotiation..................................................................................................................................... 288
Table 8-5 Steps for a GotoMin Negotiation....................................................................................................................................................... 291
Table 8-6 Steps for a Soft Reset ............................................................................................................................................................................. 293
Table 8-7 Steps for Source initiated Hard Reset ............................................................................................................................................ 297
Table 8-8 Steps for Sink initiated Hard Reset ................................................................................................................................................. 300
Table 8-9 Steps for Source initiated Hard Reset – Sink long reset ......................................................................................................... 303
Table 8-10 Steps for a Successful Type-A or Type-B Source Initiated Power Role Swap Sequence ....................................... 307
Table 8-11 Steps for a Successful Type-A or Type-B Sink Initiated Power Role Swap Sequence ............................................ 311
Table 8-12 Steps for Type-A or Type-B Source initiated Hard Reset (Power Role Swapped) .................................................. 315
Table 8-13 Steps for Type-A or Type-B Sink initiated Hard Reset (Power Role Swapped) ....................................................... 318
Table 8-14 Steps for a Successful Type-C Source Initiated Power Role Swap Sequence ............................................................. 322
Table 8-15 Steps for a Successful Type-C Sink Initiated Power Role Swap Sequence .................................................................. 327
Table 8-16 Steps for Type-C Data Role Swap, UFP operating as Sink initiates ................................................................................ 331
Table 8-17 Steps for Type-C Data Role Swap, UFP operating as Source initiates ........................................................................... 334
Table 8-18 Steps for Type-C Data Role Swap, DFP operating as Source initiates ........................................................................... 337
Table 8-19 Steps for Type-C Data Role Swap, DFP operating as Sink initiates ................................................................................ 340
Table 8-20 Steps for Type-C DFP to UFP VCONN Source Swap ................................................................................................................. 343
Table 8-21 Steps for Type-C UFP to DFP VCONN Source Swap ................................................................................................................. 346
Table 8-22 Steps for DFP to UFP Discover Identity ...................................................................................................................................... 348
Table 8-23 Steps for Source Port to Cable Plug Discover Identity ......................................................................................................... 350
Table 8-24 Steps for DFP to Cable Plug Discover Identity ......................................................................................................................... 352
Table 8-25 Steps for DFP to UFP Enter Mode .................................................................................................................................................. 356
Table 8-26 Steps for DFP to UFP Exit Mode ..................................................................................................................................................... 360
Table 8-27 Steps for DFP to Cable Plug Enter Mode .................................................................................................................................... 364
Table 8-28 Steps for DFP to Cable Plug Exit Mode ........................................................................................................................................ 368
Table 8-29 Steps for UFP to DFP Attention ...................................................................................................................................................... 370
Table 8-30 Steps for BIST Receiver Mode test ................................................................................................................................................ 373
Table 8-31 Steps for BIST Transmit Mode test ............................................................................................................................................... 376
Table 8-32 Steps for BIST Eye Pattern Test ..................................................................................................................................................... 379
Table 8-33 Policy Engine States ............................................................................................................................................................................ 451
Table 9-1 USB Power Delivery Type Codes ...................................................................................................................................................... 464
Table 9-2 USB Power Delivery Capability Descriptor ................................................................................................................................. 464
Table 9-3 Battery Info Capability Descriptor .................................................................................................................................................. 466

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 25

Table 9-4 PD Consumer Port Descriptor ........................................................................................................................................................... 468
Table 9-5 PD Provider Port Descriptor .............................................................................................................................................................. 469
Table 9-6 PD Class Requests ................................................................................................................................................................................... 470
Table 9-7 PD Class Request Codes ........................................................................................................................................................................ 470
Table 9-8 PD Class Feature Selectors .................................................................................................................................................................. 471
Table 9-9 Clear Change Mask.................................................................................................................................................................................. 473
Table 9-10 Battery Status Structure .................................................................................................................................................................... 474
Table 9-11 Port PD Status ........................................................................................................................................................................................ 476
Table 9-12 Battery Wake Mask .............................................................................................................................................................................. 478
Table 9-13 Policy Mode Encoding ........................................................................................................................................................................ 479
Table 9-14 Charging Policy Encoding ................................................................................................................................................................. 479
Table F-1 External power is supplied downstream ...................................................................................................................................... 509
Table F-2 External power is supplied downstream ...................................................................................................................................... 512
Table F-3 Giving back power .................................................................................................................................................................................. 519
Table G-1 Discover Identity Command request from Initiator Example ............................................................................................ 532
Table G-2 Discover Identity Command response from Active Cable Responder Example ......................................................... 532
Table G-3 Discover Identity Command response from Hub Responder Example .......................................................................... 533
Table G-4 Discover SVIDs Command request from Initiator Example ................................................................................................. 535
Table G-5 Discover SVIDs Command response from Responder Example ........................................................................................ 535
Table G-6 Discover Modes Command request from Initiator Example ............................................................................................... 537
Table G-7 Discover Modes Command response from Responder Example ....................................................................................... 537
Table G-8 Enter Mode Command request from Initiator Example ........................................................................................................ 539
Table G-9 Enter Mode Command response from Responder Example................................................................................................ 539
Table G-10 Enter Mode Command request from Initiator Example ..................................................................................................... 540
Table G-11 Exit Mode Command request from Initiator Example ......................................................................................................... 541
Table G-12 Exit Mode Command response from Responder Example ................................................................................................ 541
Table G-13 Attention Command request from Initiator Example .......................................................................................................... 543
Table G-14 Attention Command request from Initiator with additional VDO Example .............................................................. 543

Page 26 USB Power Delivery Specification Revision 2.0, Version 1.1

List of Figures
Figure 2-1 Logical Structure of USB Power Delivery Capable Devices .................................................................................................. 46
Figure 2-2 SOP’ Communication between Source and Cable Plug with no Explicit Contract or an Implicit Contract ...... 47
Figure 2-3 SOP’ Communication between DFP and Cable Plug with PD Explicit Contract ........................................................... 47
Figure 2-4 SOP’’ Communication with the attached Cable Plugs .............................................................................................................. 48
Figure 2-5 USB Power Delivery Communications Stack............................................................................................................................... 56
Figure 2-6 USB Power Delivery Communication Over USB ........................................................................................................................ 57
Figure 2-7 High Level Architecture View ............................................................................................................................................................ 58
Figure 3-1 Standard-A Insertion Detect Schematic Representation ....................................................................................................... 64
Figure 3-2 PD Standard-A No Plug Detection Circuit ..................................................................................................................................... 65
Figure 3-3 Non-PD Plug Standard-A Detection Circuit ................................................................................................................................. 65
Figure 3-4 USB Thin Card Standard-A Detection Circuit .............................................................................................................................. 65
Figure 3-5 PD Plug Standard-A Detection Circuit ............................................................................................................................................ 65
Figure 3-6 Insertion Detect Zone Mechanical Dimensions for the Standard-A Receptacle .......................................................... 66
Figure 3-7 PD Detect Plane Location Range for PD Standard-A Receptacles ...................................................................................... 67
Figure 3-8 PD Standard-A Plug Interface Dimensions .................................................................................................................................. 69
Figure 3-9 USB 2.0 PD Standard-A Receptacle Interface Dimensions .................................................................................................... 70
Figure 3-10 Reference Footprint for the USB 2.0 PD Standard-A Top Mount Single Receptacle (Informative) ................ 71
Figure 3-11 USB 3.1 PD Standard-A Plug Interface Dimensions .............................................................................................................. 73
Figure 3-12 Reference USB 3.1 PD Standard-A Receptacle Interface Dimensions (Informative) ............................................. 74
Figure 3-13 Reference Footprint for the USB 3.1 PD Standard-A Top Mount Single Receptacle (Informative) ................. 75
Figure 3-14 USB 2.0 PD Standard-B Plug Interface Dimensions............................................................................................................... 77
Figure 3-15 USB 2.0 PD Standard-B Receptacle Interface Dimensions ................................................................................................. 78
Figure 3-16 Reference Footprint for the USB 2.0 PD Standard-B Receptacle ..................................................................................... 79
Figure 3-17 USB 3.1 PD Standard-B Plug Interface Dimensions............................................................................................................... 80
Figure 3-18 USB 3.1 PD Standard-B Receptacle Interface Dimensions ................................................................................................. 81
Figure 3-19 Reference Footprint for the USB 3.1 PD Standard-B Receptacle ..................................................................................... 82
Figure 3-20 USB PD Cable Assembly Overmold Maximum Dimensions ............................................................................................... 85
Figure 3-21 Schematic of a Micro-A Plug Legacy Termination ................................................................................................................. 86
Figure 3-22 Schematic of a Micro-A Plug Marker Indicating Low Power Capability ....................................................................... 87
Figure 3-23 Schematic of a Micro-A PD Plug ..................................................................................................................................................... 87
Figure 3-24 Schematic of a B Plug Connector Marker Indicating 3A Capability ................................................................................ 88
Figure 3-25 Schematic of a B Plug Connector Marker Indicating 5A Capability ................................................................................ 88
Figure 3-26 Differential Near-End and Far-End Crosstalk Requirement between the D+/D- Pair and VBUS ........................ 90
Figure 3-27 Voltage Drop Measurement ............................................................................................................................................................. 91

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 27

Figure 4-1 Type-A to Type-B Dead Battery / Unpowered Port Detection Flow ................................................................................ 96
Figure 4-2 Plug Type Determination ................................................................................................................................................................... 100
Figure 4-3 Standard-A Plug PD Capabilities Flow ......................................................................................................................................... 101
Figure 4-4 Plug Type Detection Circuit .............................................................................................................................................................. 101
Figure 5-1 Interpretation of ordered sets ......................................................................................................................................................... 106
Figure 5-2 Transmit Order for Various Sizes of Data ................................................................................................................................... 107
Figure 5-3 USB Power Delivery Packet Format .............................................................................................................................................. 108
Figure 5-4 CRC 32 generation ................................................................................................................................................................................ 111
Figure 5-5 Line format of Hard Reset ................................................................................................................................................................. 113
Figure 5-6 Line format of Cable Reset ................................................................................................................................................................ 113
Figure 5-7 Inter-Frame Gap Timings .................................................................................................................................................................. 115
Figure 5-8 Transmitter Block Diagram .............................................................................................................................................................. 116
Figure 5-9 Receiver Block Diagram ..................................................................................................................................................................... 116
Figure 5-10 Channel Diagram (Cable Type Detection not shown) ........................................................................................................ 117
Figure 5-11 Eye diagram of BFSK Modulation ................................................................................................................................................ 120
Figure 5-12 BFSK Transmit Spectral Mask, given in absolute terms relative to the maximum value of vTX..................... 121
Figure 5-13 Line Format of Bit Stream ............................................................................................................................................................... 123
Figure 5-14 BMC Example ........................................................................................................................................................................................ 124
Figure 5-15 BMC Transmitter Block Diagram ................................................................................................................................................. 124
Figure 5-16 BMC Receiver Block Diagram ........................................................................................................................................................ 125
Figure 5-17 BMC Encoded Start of Preamble .................................................................................................................................................. 125
Figure 5-18 Transmitting or Receiving BMC Encoded Frame Terminated by Zero with High-to-Low Last Transition 126
Figure 5-19 Transmitting or Receiving BMC Encoded Frame Terminated by One with High-to-Low Last Transition . 126
Figure 5-20 Transmitting or Receiving BMC Encoded Frame Terminated by Zero with Low to High Last Transition . 126
Figure 5-21 Transmitting or Receiving BMC Encoded Frame Terminated by One with Low to High Last Transition .. 127
Figure 5-22 Waiting for idle after a BMC Encoded Frame Terminated by Zero with High-to-Low Last Transition ....... 127
Figure 5-23 BMC Tx ‘ONE’ Mask ............................................................................................................................................................................ 128
Figure 5-24 BMC Tx ‘ZERO’ Mask ......................................................................................................................................................................... 128
Figure 5-25 BMC Rx ‘ONE’ Mask when Sourcing Power ............................................................................................................................. 131
Figure 5-26 BMC Rx ‘ZERO’ Mask when Sourcing Power .......................................................................................................................... 131
Figure 5-27 BMC Rx ‘ONE’ Mask when Power neutral ................................................................................................................................ 132
Figure 5-28 BMC Rx ‘ZERO’ Mask when Power neutral.............................................................................................................................. 132
Figure 5-29 BMC Rx ‘ONE’ Mask when Sinking Power ............................................................................................................................... 133
Figure 5-30 BMC Rx ‘ZERO’ Mask when Sinking Power ............................................................................................................................. 133
Figure 5-31 Transmitter Load Model for BMC Tx from a Source ........................................................................................................... 134
Figure 5-32 Transmitter Load Model for BMC Tx from a Sink ................................................................................................................ 135

Page 28 USB Power Delivery Specification Revision 2.0, Version 1.1

Figure 5-33 Transmitter diagram illustrating zDriver ................................................................................................................................ 137
Figure 5-34 Example Multi-Drop Configuration showing two DRPs .................................................................................................... 138
Figure 5-35 Example Multi-Drop Configuration showing a DFP and UFP.......................................................................................... 138
Figure 5-36 Example implementation of the BIST generator and checker ........................................................................................ 140
Figure 5-37 Test Frame ............................................................................................................................................................................................. 140
Figure 5-38 Test Data Frame .................................................................................................................................................................................. 142
Figure 6-1 High Level Message Structure ......................................................................................................................................................... 143
Figure 6-2 USB Power Delivery Packet Format including Message Payload .................................................................................... 143
Figure 6-3 Example Capabilities Message with 2 Power Data Objects ................................................................................................ 152
Figure 6-4 BIST Message .......................................................................................................................................................................................... 164
Figure 6-5 Vendor Defined Message.................................................................................................................................................................... 167
Figure 6-6 Discover Identity Command response ......................................................................................................................................... 172
Figure 6-7 Example Discover SVIDs response with 3 SVIDs .................................................................................................................... 176
Figure 6-8 Example Discover SVIDs response with 4 SVIDs .................................................................................................................... 176
Figure 6-9 Example Discover SVIDs response with 12 SVIDs followed by an empty response ............................................... 176
Figure 6-10 Example Discover Modes response for a given SVID with 3 Modes ............................................................................ 177
Figure 6-11 Successful Enter Mode sequence ................................................................................................................................................. 178
Figure 6-12 Unsuccessful Enter Mode sequence due to NAK .................................................................................................................. 178
Figure 6-13 Exit Mode sequence ........................................................................................................................................................................... 179
Figure 6-14 Attention Command request/response sequence ............................................................................................................... 180
Figure 6-15 Command request/response sequence .................................................................................................................................... 180
Figure 6-16 Enter/Exit Mode Process ................................................................................................................................................................ 182
Figure 6-17 Vendor Defined Message interrupted by a Power Delivery Message ......................................................................... 183
Figure 6-18 Outline of States .................................................................................................................................................................................. 198
Figure 6-19 References to states ........................................................................................................................................................................... 198
Figure 6-20 Protocol Layer Message transmission ....................................................................................................................................... 199
Figure 6-21 Protocol layer Message reception ............................................................................................................................................... 202
Figure 6-22 Hard/Cable Reset ............................................................................................................................................................................... 204
Figure 6-23 BIST Transmitter Test ...................................................................................................................................................................... 207
Figure 6-24 BIST Receiver Test ............................................................................................................................................................................. 209
Figure 7-1 Placement of Source Bulk Capacitance ........................................................................................................................................ 215
Figure 7-2 Transition Envelope for Positive Voltage Transitions .......................................................................................................... 216
Figure 7-3 Transition Envelope for Negative Voltage Transitions ........................................................................................................ 217
Figure 7-4 Source VBUS Response to Hard Reset ............................................................................................................................................. 218
Figure 7-5 Source VCONN Response to Hard Reset ........................................................................................................................................ 218
Figure 7-6 Application of vSrcNew and vSrcValid limits after tSrcReady .......................................................................................... 220

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 29

Figure 7-7 Source Peak Current Overload ........................................................................................................................................................ 221
Figure 7-8 Noise Spectral Mask, given in absolute terms relative to the maximum value of vTX ........................................... 222
Figure 7-9 vSafeDB Operating Region ................................................................................................................................................................ 223
Figure 7-10 Placement of Sink Bulk Capacitance .......................................................................................................................................... 224
Figure 7-11 Noise Spectral Mask, given in absolute terms relative to the maximum value of vTX ........................................ 227
Figure 7-12 Transition Diagram for Increasing the Current .................................................................................................................... 230
Figure 7-13 Transition Diagram for Increasing the Voltage ..................................................................................................................... 232
Figure 7-14 Transition Diagram for Increasing the Voltage and Current........................................................................................... 234
Figure 7-15 Transition Diagram for Increasing the Voltage and Decreasing the Current .......................................................... 236
Figure 7-16 Transition Diagram for Decreasing the Voltage and Increasing the Current .......................................................... 238
Figure 7-17 Transition Diagram for Decreasing the Current ................................................................................................................... 240
Figure 7-18 Transition Diagram for Decreasing the Voltage.................................................................................................................... 242
Figure 7-19 Transition Diagram for Decreasing the Voltage and the Current ................................................................................. 244
Figure 7-20 Transition Diagram for a Sink Requested Power Role Swap .......................................................................................... 246
Figure 7-21 Transition Diagram for a Source Requested Power Role Swap ..................................................................................... 249
Figure 7-22 Transition Diagram for a GotoMin Current Decrease ........................................................................................................ 252
Figure 7-23 Transition Diagram for a Source Initiated Hard Reset ...................................................................................................... 254
Figure 7-24 Transition Diagram for a Sink Initiated Hard Reset ............................................................................................................ 256
Figure 7-25 Transition Diagram for Type-B New Source Initiated Hard Reset and Type-A New Sink Receives Hard
Reset Signaling .............................................................................................................................................................................................................. 258
Figure 7-26 Transition Diagram for Type-B New Source Initiated Hard Reset and Type-A New Sink Does Not Receive
Hard Reset Signaling ................................................................................................................................................................................................... 260
Figure 7-27 Transition Diagram for Type-A New Sink Initiated Hard Reset and Type-B New Source Receives Hard
Reset Signaling .............................................................................................................................................................................................................. 262
Figure 7-28 Transition Diagram for Type-A New Sink Initiated Hard Reset and Type-B New Source Does Not Receive
Hard Reset Signaling ................................................................................................................................................................................................... 264
Figure 7-29 Type-A to Type-B Transition Diagram for Dead Battery Operation ............................................................................ 266
Figure 7-30 Transition Diagram for no change in Current or Voltage ................................................................................................. 268
Figure 8-1 Example of daisy chained displays ................................................................................................................................................ 280
Figure 8-2 Basic Message Exchange (Successful) .......................................................................................................................................... 282
Figure 8-3 Basic Message flow indicating possible errors ........................................................................................................................ 283
Figure 8-4 Basic Message Flow with Bad CRC followed by a Retry ....................................................................................................... 285
Figure 8-5 Successful Power Negotiation ......................................................................................................................................................... 287
Figure 8-6 Successful GotoMin operation ......................................................................................................................................................... 291
Figure 8-7 Soft Reset .................................................................................................................................................................................................. 293
Figure 8-8 Source initiated Hard Reset .............................................................................................................................................................. 296
Figure 8-9 Sink Initiated Hard Reset ................................................................................................................................................................... 299

Page 30 USB Power Delivery Specification Revision 2.0, Version 1.1

Figure 8-10 Source initiated reset - Sink long reset ..................................................................................................................................... 302
Figure 8-11 Type-A or Type-B Successful Power Role Swap Sequence Initiated by the Source .............................................. 306
Figure 8-12 Type-A or Type-B Successful Power Role Swap Sequence Initiated by the Sink ................................................... 310
Figure 8-13 Type-A or Type-B Source initiated Hard Reset (Power Role Swapped) .................................................................... 314
Figure 8-14 Type-A or Type-B Sink Initiated Hard Reset (Power Role Swapped) ......................................................................... 317
Figure 8-15 Type-C Successful Power Role Swap Sequence Initiated by the Source .................................................................... 321
Figure 8-16 Type-C Successful Power Role Swap Sequence Initiated by the Type-C Sink ......................................................... 326
Figure 8-17 Type-C Data Role Swap, UFP operating as Sink initiates .................................................................................................. 330
Figure 8-18 Type-C Data Role Swap, UFP operating as Source initiates ............................................................................................. 333
Figure 8-19 Type-C Data Role Swap, DFP operating as Source initiates ............................................................................................. 336
Figure 8-20 Type-C Data Role Swap, DFP operating as Sink initiates .................................................................................................. 339
Figure 8-21 Type-C DFP to UFP VCONN Source Swap ................................................................................................................................... 342
Figure 8-22 Type-C UFP to DFP VCONN Source Swap ................................................................................................................................... 345
Figure 8-23 DFP to UFP Discover Identity ........................................................................................................................................................ 348
Figure 8-24 Source Port to Cable Plug Discover Identity ........................................................................................................................... 350
Figure 8-25 DFP to Cable Plug Discover Identity........................................................................................................................................... 352
Figure 8-26 DFP to UFP Enter Mode ................................................................................................................................................................... 355
Figure 8-27 DFP to UFP Exit Mode ....................................................................................................................................................................... 360
Figure 8-28 DFP to Cable Plug Enter Mode ...................................................................................................................................................... 363
Figure 8-29 DFP to Cable Plug Exit Mode.......................................................................................................................................................... 368
Figure 8-30 UFP to DFP Attention ........................................................................................................................................................................ 370
Figure 8-31 BIST Receiver Mode test .................................................................................................................................................................. 372
Figure 8-32 BIST Transmit Mode test ................................................................................................................................................................. 375
Figure 8-33 BIST Eye Pattern Test ....................................................................................................................................................................... 378
Figure 8-34 Outline of States .................................................................................................................................................................................. 380
Figure 8-35 References to states ........................................................................................................................................................................... 380
Figure 8-36 Example of state reference with conditions ........................................................................................................................... 380
Figure 8-37 Example of state reference with the same entry and exit ................................................................................................ 381
Figure 8-38 Source Port Policy Engine state diagram ................................................................................................................................. 382
Figure 8-39 Sink Port state diagram.................................................................................................................................................................... 388
Figure 8-40 Source Port Soft Reset Diagram ................................................................................................................................................... 393
Figure 8-41 Sink Port Soft Reset Diagram ........................................................................................................................................................ 394
Figure 8-42 Source Port Ping State Diagram ................................................................................................................................................... 395
Figure 8-43 Dual-Role (initially Source Port) Ping State Diagram......................................................................................................... 396
Figure 8-44 Dual-Role (initially Sink Port) Ping State Diagram .............................................................................................................. 397
Figure 8-45 State Diagram for Hard Reset of P/C in Sink Role ................................................................................................................ 397

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 31

Figure 8-46 State Diagram for the Hard Reset of a C/P in Source Role ............................................................................................... 398
Figure 8-47 Consumer/Provider Dead Battery/Power Loss State Diagram ..................................................................................... 400
Figure 8-48 BFSK Provider/Consumer Dead Battery/Power Loss State Diagram......................................................................... 403
Figure 8-49: Type-C DFP to UFP Data Role Swap State Diagram ........................................................................................................... 405
Figure 8-50: Type-C UFP to DFP Data Role Swap State Diagram ........................................................................................................... 408
Figure 8-51: Dual-Role Port in Source to Sink Power Role Swap State Diagram ............................................................................ 411
Figure 8-52: Dual-role Port in Sink to Source Power Role Swap State Diagram ............................................................................. 414
Figure 8-53 Dual-Role (Source) Get Source Capabilities diagram ......................................................................................................... 417
Figure 8-54 Dual-Role (Source) Give Sink Capabilities diagram ............................................................................................................ 417
Figure 8-55 Dual-Role (Sink) Get Sink Capabilities State Diagram ....................................................................................................... 418
Figure 8-56 Dual-Role (Sink) Give Source Capabilities State Diagram ................................................................................................ 418
Figure 8-57 VCONN Swap State Diagram .......................................................................................................................................................... 419
Figure 8-58 UFP Structured VDM Discover Identity State Diagram ..................................................................................................... 421
Figure 8-59 UFP Structured VDM Discover SVIDs State Diagram .......................................................................................................... 422
Figure 8-60 UFP Structured VDM Discover Modes State Diagram ........................................................................................................ 423
Figure 8-61 UFP Structured VDM Enter Mode State Diagram ................................................................................................................. 424
Figure 8-62 UFP Structured VDM Exit Mode State Diagram .................................................................................................................... 425
Figure 8-63 UFP VDM Attention State Diagram ............................................................................................................................................. 426
Figure 8-64 DFP to UFP VDM Discover Identity State Diagram .............................................................................................................. 427
Figure 8-65 DFP VDM Discover Identity State Diagram ............................................................................................................................. 428
Figure 8-66 DFP VDM Discover SVIDs State Diagram ................................................................................................................................. 429
Figure 8-67 DFP VDM Discover Modes State Diagram ................................................................................................................................ 430
Figure 8-68 DFP VDM Mode Entry State Diagram ........................................................................................................................................ 431
Figure 8-69 DFP VDM Mode Exit State Diagram ............................................................................................................................................ 433
Figure 8-70 DFP VDM Attention State Diagram ............................................................................................................................................. 434
Figure 8-71 Cable Ready VDM State Diagram ................................................................................................................................................. 434
Figure 8-72 Cable Plug Structured VDM Discover Identity State Diagram ........................................................................................ 435
Figure 8-73 Cable Plug Structured VDM Discover SVIDs State Diagram ............................................................................................ 436
Figure 8-74 Cable Plug Structured VDM Discover Modes State Diagram ........................................................................................... 437
Figure 8-75 CablePlug Structured VDM Enter Mode State Diagram ..................................................................................................... 438
Figure 8-76 CablePlug Structured VDM Exit Mode State Diagram ........................................................................................................ 439
Figure 8-77 Cable Plug Soft Reset State Diagram .......................................................................................................................................... 440
Figure 8-78 Cable Plug Hard Reset State Diagram ........................................................................................................................................ 441
Figure 8-79 DFP Soft Reset or Cable Reset of a Cable Plug State Diagram ......................................................................................... 442
Figure 8-80 UFP Source Soft Reset of a Cable Plug State Diagram ........................................................................................................ 443
Figure 8-81 Source Startup Structured VDM Discover Identity State Diagram ............................................................................... 444

Page 32 USB Power Delivery Specification Revision 2.0, Version 1.1

Figure 8-82 BIST Receive Mode State Diagram .............................................................................................................................................. 445
Figure 8-83 BIST Transmit Mode State Diagram ........................................................................................................................................... 447
Figure 8-84 BIST Carrier Mode and Eye Pattern State Diagram ............................................................................................................. 448
Figure 9-1 Example PD Topology ......................................................................................................................................................................... 458
Figure 9-2 Mapping of PD Topology to USB ..................................................................................................................................................... 459
Figure 9-3 USB Attached to USB Powered State Transition ..................................................................................................................... 460
Figure 9-4 Any USB State to USB Attached State Transition (When operating as a Consumer) .............................................. 461
Figure 9-5 Any USB State to USB Attached State Transition (When operating as a Provider) ................................................. 461
Figure 9-6 Any USB State to USB Attached State Transition (After a Type-C Data Role Swap) ................................................ 462
Figure 9-7 Software stack on a PD aware OS ................................................................................................................................................... 462
Figure 9-8 Enumeration of a PDUSB Device .................................................................................................................................................... 463
Figure 9-9 Hub Status Change ................................................................................................................................................................................ 472
Figure A-1 Interpretation of UL60950 ............................................................................................................................................................... 484
Figure A-2 Notebook is Capable of Meeting User’s Requirements ........................................................................................................ 485
Figure A-3 Notebook is not Capable of Meeting User’s Requirements ................................................................................................ 486
Figure A-4 Display with Integrated Hub Capable of Meeting User’s Requirements ...................................................................... 487
Figure C-1 Typical System Electrical Model ..................................................................................................................................................... 491
Figure C-2 Typical Synchronous Buck Power Stage with Parasitics ..................................................................................................... 492
Figure C-3 Spurious Noise Measurement Test Setup ................................................................................................................................... 493
Figure C-4 Current Transients when Cable/Load Removed ..................................................................................................................... 494
Figure C-5 Isolation Inductor Energy versus Load ....................................................................................................................................... 495
Figure C-6 Simplified Small Signal AC Model ................................................................................................................................................... 496
Figure C-7 Power Stage Phase And Gain with and without Isolation Inductors .............................................................................. 497
Figure C-8 Simplified Small Signal AC Model (Feedback before and after Inductor zIsolation_P) .......................................... 498
Figure C-9 Simplified Small Signal AC Model (Feedback before and after Inductor zIsolation_P) .......................................... 498
Figure D-1 USB 3.1 Standard-A Plug with USB 2.0 PD or 3.1 PD Standard-A Receptacle ............................................................ 499
Figure D-2 USB 3.1 PD Standard-A Plug with USB 2.0 or 3.1 Standard-A Receptacle ................................................................... 500
Figure D-3 USB 2.0 PD or 3.1 PD Standard-A plug with USB 2.0 PD or 3.1 PD Standard-A receptacle ................................. 501
Figure D-4 USB 2.0 PD or 3.1 PD Standard-A Plug with USB 2.0 Standard-A Receptacle............................................................ 502
Figure D-5 USB 2.0 Standard-A Plug with USB 2.0 or USB3.1 PD Standard-A Receptacle .......................................................... 503
Figure D-6 USB 2.0 Thin Card with USB 2.0 PD or 3.1 PD Standard-A Receptacle ......................................................................... 504
Figure D-7 USB 3.1 Thin Card with USB 2.0 PD or 3.1 PD Standard-A Receptacle ......................................................................... 505
Figure E-1 Squelch Budget ....................................................................................................................................................................................... 506
Figure F-1 External Power supplied downstream ........................................................................................................................................ 508
Figure F-2 External Power supplied upstream ............................................................................................................................................... 512
Figure F-3 Giving Back Power ................................................................................................................................................................................ 519

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 33

Page 34 USB Power Delivery Specification Revision 2.0, Version 1.1
1. Introduction
USB has evolved from a data interface capable of supplying limited power to a primary provider of power with a data
interface. Today many devices charge or get their power from USB ports contained in laptops, cars, aircraft or even
wall sockets. USB has become a ubiquitous power socket for many small devices such as cell phones, MP3 players and
other hand-held devices. Users need USB to fulfill their requirements not only in terms of data but also to provide
power to, or charge, their devices simply, often without the need to load a driver, in order to carry out “traditional”
USB functions.
There are however, still many devices which either require an additional power connection to the wall, or exceed the
USB rated current in order to operate. Increasingly, international regulations require better energy management due
to ecological and practical concerns relating to the availability of power. Regulations limit the amount of power
available from the wall which has led to a pressing need to optimize power usage. The USB Power Delivery
Specification has the potential to minimize waste as it becomes a standard for charging devices that are not satisfied
by [BC 1.2].
Wider usage of wireless solutions is an attempt to remove data cabling but the need for “tethered” charging remains.
In addition, industrial design requirements drive wired connectivity to do much more over the same connector.
USB Power Delivery is designed to enable the maximum functionality of USB by providing more flexible power
delivery along with data over a single cable. Its aim is to operate with and build on the existing USB ecosystem;
increasing power levels from existing USB standards, for example Battery Charging, enabling new higher power use
cases such as USB powered Hard Disk Drives (HDDs) and printers.
With USB Power Delivery the power direction is no longer fixed. This enables the product with the power (Host or
Peripheral) to provide the power. For example, a display with a supply from the wall can power, or charge, a laptop.
Alternatively, USB power bricks or chargers are able to supply power to laptops and other battery powered devices
through their, traditionally power providing, USB ports.
USB Power Delivery enables hubs to become the means to optimize power management across multiple peripherals
by allowing each device to take only the power it requires, and to get more power when required for a given
application. For example battery powered devices can get increased charging current and then give it back
temporarily when the user’s HDD requires to spin up. Optionally the hubs can communicate with the PC to enable
even more intelligent and flexible management of power either automatically or with some level of user intervention.
USB Power Delivery allows Low Power cases such as headsets to negotiate for only the power they require. This
provides a simple solution that enables USB devices to operate at their optimal power levels.
The Power Delivery Specification, in addition to providing mechanisms to negotiate power also can be used as a side-
band channel for standard and vendor defined messaging. Power Delivery enables alternative modes of operation by
providing the mechanisms to discover, enter and exit Alternate Modes. The specification also enables discovery of
cable capabilities such as supported speeds and current levels.

1.1 Overview
This specification defines how USB Devices may negotiate for more current and/or higher or lower voltages over the
USB cable (using VBUS or CC wire as the communications channel) than are defined in the [USB 2.0], [USB 3.1],
[USBType-C 1.0] or [BC 1.2] specifications. It allows Devices with greater power requirements than can be met with
today’s specification to get the power they require to operate from VBUS and negotiate with external power sources
(e.g. wall warts). In addition, it allows a Source and Sink to swap power roles such that a Device could supply power
to the Host. For example, a display could supply power to a notebook to charge its battery.
The USB Power Delivery Specification is guided by the following principles:
1) Works seamlessly with legacy USB Devices
2) Compatible with existing spec-compliant USB cables
3) Minimizes potential damage from non-compliant cables (e.g. ‘Y’ cables etc.)
4) Optimized for low-cost implementations

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 35

This specification defines mechanisms to discover, enter and exit Modes defined either by a standard or by a
particular vendor. These Modes can be supported either by the Port Partner or by a cable connecting the two Port
Partners.
The specification defines mechanisms to discover the capabilities of cables which can communicate using Power
Delivery.
For Type-C Connectors this specification adds a mechanism to swap the data roles such that the upstream facing Port
becomes the downstream facing Port and vice versa. It also enables a swap of the end supplying VCONN to a powered
cable.

1.2 Purpose
The USB Power Delivery specification defines a power delivery system covering all elements of a USB system
including: Hosts, Devices, Hubs, Chargers and cable assemblies. This specification describes the architecture,
protocols, power supply behavior, connectors and cabling necessary for managing power delivery over USB at up to
100W. This specification is intended to be fully compatible and extend the existing USB infrastructure. It is intended
that this specification will allow system OEMs, power supply and peripheral developers adequate flexibility for
product versatility and market differentiation without losing backwards compatibility.
USB Power Delivery is designed to operate independently of the existing USB bus defined mechanisms used to
negotiate power which are:
 [USB 2.0], [USB 3.1] in band requests for high power interfaces.
 [BC1.2] mechanisms for supplying higher power (not mandated by this specification).
 [USBType-C 1.0] mechanisms for supplying higher power
Initial operating conditions remain the USB Default Operation as defined in [USB 2.0], [USB 3.1], [USBType-C 1.0] or
[BC 1.2].
 The DFP sources vSafe5V over VBUS.
 The UFP consumes power from VBUS.

1.3 Scope
This specification is intended as an extension to the existing [USB 2.0], [USB 3.1], [USBType-C 1.0] and [BC 1.2]
specifications. It addresses only the elements required to implement USB Power Delivery. It is targeted at power
supply vendors, manufacturers of [USB 2.0], [USB 3.1], [USBType-C 1.0] and [BC 1.2] Platforms, Devices and cable
assemblies.
Normative information is provided to allow interoperability of components designed to this specification. Informative
information, when provided, may illustrate possible design implementation.

1.4 Conventions
1.4.1 Precedence
If there is a conflict between text, figures, and tables, the precedence shall be tables, figures, and then text.

1.4.2 Keywords
The following keywords differentiate between the levels of requirements and options.

1.4.2.1 Conditional Normative

Conditional Normative is a keyword used to indicate a feature that is mandatory when another related feature has
been implemented. Designers are mandated to implement all such requirements, when the dependent features have
been implemented, to ensure interoperability with other compliant Devices.

Page 36 USB Power Delivery Specification Revision 2.0, Version 1.1

 1.4.2.2 Deprecated
Deprecated is a keyword used to indicate a feature, supported in previous releases of the specification, which is no
longer supported.

1.4.2.3 Discarded
Discarded is a keyword indicating that a Packet when received shall be thrown away by the PHY Layer and not
passed to the Protocol Layer for processing. No GoodCRC Message shall be sent in response to the Packet.

1.4.2.4 Ignored
Ignored is a keyword indicating Messages or Message fields which, when received, shall result in no action by the
receiver, aside from returning a GoodCRC Message to acknowledge Message receipt.

1.4.2.5 May
May is a keyword that indicates a choice with no implied preference.

1.4.2.6 N/A
N/A is a keyword that indicates that a field or value is not applicable and has no defined value and shall not be
checked or used by the recipient.

1.4.2.7 Optional/Optionally/Optional Normative

Optional, Optionally and Optional Normative are equivalent keywords that describe features not mandated by this
specification. However, if an Optional feature is implemented, the feature shall be implemented as defined by this
specification.

1.4.2.8 Reserved
Reserved is a keyword indicating reserved bits, bytes, words, fields, and code values that are set-aside for future
standardization. Their use and interpretation may be specified by future extensions to this specification and shall not
be utilized or adapted by vendor implementation. A Reserved bit, byte, word, or field shall be set to zero by the
sender and shall be Ignored by the receiver. Reserved field values shall not be sent by the sender and shall be Ignored
by the receiver.

1.4.2.9 Shall/Normative
Shall and Normative are equivalent keywords indicating a mandatory requirement. Designers are mandated to
implement all such requirements to ensure interoperability with other compliant Devices.

1.4.2.10 Should
Should is a keyword indicating flexibility of choice with a preferred alternative. Equivalent to the phrase “it is
recommended that”.

1.4.3 Numbering
Numbers that are immediately followed by a lowercase "b" (e.g., 01b) are binary values. Numbers that are
immediately followed by an uppercase "B" are byte values. Numbers that are immediately followed by a lowercase
"h" (e.g., 3Ah) or are preceded by “0x” (e.g. 0xFF00) are hexadecimal values. Numbers not immediately followed by
either a "b", “B”, or "h" are decimal values.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 37

 1.5 Related Documents
 [USB 2.0] – Universal Serial Bus Specification, Revision 2.0, plus ECN and Errata (this includes the entire
document release package including the OTG&EH v2.0 and the Micro connector v1.01 specifications).
http://www.usb.org/developers/docs/usb20_docs/.
 [USB 3.1] – Universal Serial Bus 3.1 Specification, Revision 1 plus ECN and Errata (this includes the entire
document release package including the OTG&EH v3.0 specification). www.usb.org/developers/docs.
 [BC 1.2] – Battery Charging Specification, Revision 1.2 plus Errata (referred to in this document as the Battery
Charging specification). www.usb.org/developers/devclass_docs#approved.
 [USBPDCompliance] – USB Power Delivery Compliance Plan version 1.0
http://www.usb.org/developers/docs/devclass_docs/.
 [USBOTG 2.0] On-The-Go and Embedded Host Supplement to the Universal Serial Bus Revision 2.0 Specification.
 [Maxim37] – Maxim Engineering Journal, Volume 37, page 12 http://pdfserv.maxim-ic.com/en/ej/EJ37.pdf.
 [USBType-C 1.0] – USB Type-C Specification www.usb.org/developers/docs
 [IEC 60958-1] IEC 60958-1 Digital Audio Interface Part:1 General Edition 3.0 2008-09 www.iec.ch

1.6 Terms and Abbreviations

This section defines terms used throughout this document. For additional terms that pertain to the Universal Serial
Bus, see Chapter 2, “Terms and Abbreviations,” in [USB 2.0], [USB 3.1], [USBType-C 1.0] and [BC 1.2].

Table 1-1 Terms and Abbreviations

Term Description
Active Cable A cable with a USB Plug on each end at least one of which is a Cable Plug supporting SOP’,
that also incorporates data bus signal conditioning circuits. The cable supports the
Structured VDM Discover Identity to determine its characteristics in addition to other
Structured VDM Commands (Electronically Marked Cable see [USBType-C 1.0]).
Active Mode A Mode which has been entered and not exited.
Alternate Mode As defined in [USBType-C 1.0]. Equivalent to Mode in the PD Specification.
Alternate Mode Adapter A PDUSB Device which supports Alternate Modes as defined in [USBType-C 1.0]. Note that
(AMA) since an AMA is a PDUSB Device it has a single UFP that is only addresseable by SOP Packets.
Attached USB Power Delivery ports which are mechanically joined with USB cable.
Binary Frequency Shift BFSK uses a pair of discrete frequencies to transmit binary (0s and 1s) information. In the
Keying (BFSK) Power Delivery BFSK system:

 Logic 0 is indicated by a frequency fCarrier - fDeviation.

 Logic 1 is indicated by a frequency fCarrier + fDeviation.
Biphase Mark Coding Modification of Manchester coding where each zero has one transition and a one has two
(BMC) transitions (see [IEC 60958-1]).
BIST Built In Self Test – Power Delivery testing mechanism for the PHY Layer.
BIST Data Object (BDO) Data Object used by BIST Messages.
BIST Mode A BIST receiver or transmitter test mode enabled by a BIST Message.
Cable Plug Term used to describe a PD Capable element in a Multi-Drop system addressed by SOP’/SOP’’
Packets. Logically the Cable Plug is associated with a USB plug at one end of the cable. In a
practical implementation the electronics may reside anywhere in the cable.
Cable Reset This is initiated by Cable Reset Signaling from either the Source or DFP. It restores the Cable
Plugs to their default, power up condition and resets the PD communications engine to its
default state. It does not reset the Port Partners but does restore VCONN to its attachment
state.
Cold Socket A DFP receptacle that does not apply vSafe5V on VBUS until a plug insertion is detected.
Command Request and response pair defined as part of a Structured Vendor Defined Message (see
Section 6.4.4.2)
Configuration Channel (CC) Single wire used by the BMC PHY Layer Signaling Scheme (see [USBType-C 1.0]).

Page 38 USB Power Delivery Specification Revision 2.0, Version 1.1

Term Description
Connected USB Power Delivery ports that have exchanged a Message and a GoodCRC Message response
using the USB Power Delivery protocol so that both Port Partners know they each is PD
Capable.
Consumer The capability of a PD Port (typically a Device’s UFP) to sink power from the power
conductor (e.g. VBUS). This corresponds to a Type-B Port or a Type-C Port with Rd asserted on
its CC Wire.
Consumer/Provider A Consumer with the additional capability to act as a Provider. This corresponds to a Dual-
Role Type-B Port or a Dual-Role Type-C Port with Rd asserted on its CC Wire.
Continuous BIST Mode A BIST Mode where the Port or Cable Plug being tested sends a continuous stream of test
data.
Contract An agreement on both power level and direction reached between a Port Pair. A Contract
may be explicitly negotiated between the Port Pair or may be an Implicit power level defined
by the current state. While operating in Power Delivery mode there will always be either an
Explicit or Implicit Contract in place. The Contract may only be altered in the case of a (re-
)negotiation, Power Role Swap, Data Role Swap, Hard Reset or failure of the Source.
Control Message A Message is defined as a Control Message when the Number of Data Objects field in the
Message Header is set to 0. The Control Message consists only of a Message Header and a
CRC.
Data Message A Data Message consists of a Message Header followed by one or more Data Objects. Data
Messages are easily identifiable because the Number of Data Objects field in the Message
Header is a non-zero value.
Data Object 32 bit object which contains information specific to different types of Data Message. Power,
Request, BIST and Vendor Data Objects are defined.
Data Role Swap Process of exchanging the DFP (Host) and UFP (Device) roles between Port Partners using
the [USBType-C 1.0] connector.
Dead Battery A device has a Dead Battery when the battery in a device is unable to power its functions.
Device When lower cased (device), it refers to any USB product, either USB Device or USB Host.
When in upper case refers to a USB Device (Peripheral or Hub).
Device Policy Manager Module running in a Provider or Consumer that applies Local Policy to each Port in the
Device via the Policy Engine.
Discovery Process Command sequence using Structured Vendor Defined Messages resulting in identification of
the Port Partner, its supported SVIDs and Modes.
Downstream Facing Port Typically a Type-A Port on a Device as defined in [USB 2.0], [USB 3.1] or Type-C Port as
(DFP) defined in [USBType-C 1.0]. The default Host and Source.
DRP (Type-C) DRP as defined in [USBType-C 1.0]. Note that this is not the same as a Power Delivery Dual-
Role Port.
Dual-Role Device A product containing one or more Dual-Role Ports that are capable of operating as either a
Source or a Sink.
Dual-Role Port A Consumer/Provider or Provider/Consumer capable Port that is a Port capable of operating
as either a Source or Sink.
End of Packet (EOP) K-code marker used to delineate the end of a packet.
Enter Mode Process Command sequence using Structured Vendor Defined Messages resulting in the Port Partners
entering a Mode.
Exit Mode Process Command sequence using Structured Vendor Defined Messages resulting in the Port Partners
exiting a Mode.
Explicit Contract An agreement reached between a Port Pair as a result of the Power Delivery negotiation
process. An Explicit Contract is established (or continued) when a Source sends an Accept
Message in response to a Request Message sent by a Sink followed by a PS_RDY Message
indicating that the power supply is ready; this corresponds to the PE_SRC_Ready state for a
Source Policy Engine and the PE_SNK_Ready state for a Sink Policy Engine. The Explicit
Contract may be altered through the re-negotiation process. All Port pairs, except for those
involving low power devices, are required to make an Explicit Contract.
Frame Generic term referring to an atomic communication transmitted by PD such as a Packet, Test
Frame or Signaling.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 39

Term Description
Hard Reset This is initiated by Hard Reset Signaling from either Port Partner. It restores VBUS to USB
Default Operation and resets the PD communications engine to its default state in both Port
Partners as well as in any attached Cable Plugs. For Type-C connectors it restores both Port
Partners to their default Data Roles and returns the VCONN Source to the Source Port.
HDD A Hard Disk Drive.
ID Header VDO The VDO in a Discover Identity Command immediately following the VDM Header. The ID
Header VDO contains information corresponding to the Power Delivery Product.
Implicit Contract An agreement on power levels between a Port Pair which occurs, not as a result of the Power
Delivery negotiation process, but as a result of the current state e.g.during a Power Role
Swap or Dead Battery operation, or on detection of a low power device. Implicit Contracts,
except for those involving low power devices, are temporary since the Port pair is required to
immediately negotiate an Explicit Contract.
Initiator The initial sender of a Command request in the form of a query.
IR Drop The voltage drop across the cable and connectors between the Source and the Sink. It is a
function of the resistance of the ground and power wire in the cable plus the contact
resistance in the connectors times the current flowing over the path.
K-code Special symbols provided by the 4b5b coding scheme. K-codes are used to signal Hard Reset
and Cable reset, and delineate Packet boundaries.
Local Policy Every PD Capable device has its own Policy, called the Local Policy, that is executed by its
Policy Engine to control its power delivery behavior. The Local Policy at any given time may
be the default policy, hard coded or modified by changes in operating parameters or one
provided by the system Host or some combination of these. The Local Policy optionally may
be changed by a System Policy Manager.
Low Power State in which Sources powered by e.g. a single cell Li battery that want to minimize the
power they output over VBUS without the requirement to fully support the PD negotiation
process.
Low Power Device Devices which can be powered e.g. by a single cell Li battery without the requirement to fully
support the PD negotiation process.
Message The packet payload consisting of a Message Header for Control Messages and a Message
Header and data for Data Messages as defined in Section 5.6.1.2.5.
Message Header Every Message starts with a 16-bit Message Header containing basic information about the
Message and the PD Port’s Capabilities.
Messaging Communication in the form of Messages as defined in Chapter 5.9.9.
Modal Operation State where there are one or more Active Modes. Modal Operation ends when there are no
longer any Active Modes.
Mode Operation defined by a Vendor or Standard’s organization, which is associated with a SVID,
whose definition is outside the scope of USB-IF specifications. Entry to and exit from the
Mode uses the Enter Mode and Exit Mode Processes. Modes are equivalent to “Alternate
Modes” as described in [USBType-C 1.0].
Multi-Drop Refers to a Power Delivery system with one or more Cable Plugs where communication is to
the Cable Plugs rather than the Port Partner. Multi-Drop systems share the Power Delivery
communication channel with the Port Partners.
Negotiation This is the PD process whereby:
1. The Source advertises its capabilities.
2. The Sink requests one of the advertised capabilities.
3. The Source acknowledges the request and alters its output to satisfy the request.
The result of the negotiation is a Contract for power delivery/consumption between the Port
Pair.
Packet One entire unit of PD communication including a Preamble, SOP*, payload, CRC and EOP as
defined in Section 5.6.

Page 40 USB Power Delivery Specification Revision 2.0, Version 1.1

Term Description
Passive Cable Cable with a USB Plug on each end at least one of which is a Cable Plug supporting SOP’ that
does not incorporate data bus signal conditioning circuits. Supports the Structured VDM
Discover Identity to determine its characteristics (Electronically Marked Cable see
[USBType-C 1.0]). Note this specification does not discuss Passive Cables which are not
Electronically Marked Cables.
PD USB Power Delivery
PD Capable A Port that supports USB Power Delivery.
PD Connection See Connected.
PDUSB USB Device Port or USB Host Port that is both PD capable and capable of USB
Communication. See also PDUSB Host, PDUSB Device and PDUSB Hub.
PDUSB Device A USB Device with a PD Capable UFP. A PDUSB Device is only addressed by SOP Packets.
PDUSB Host A USB Host which is PD Capable on at least one of its DFPs. A PDUSB Host is only addressed
by SOP Packets.
PDUSB Hub A port expander USB Device with a UFP and one or more DFPs which is PD Capable on at
least one of its Ports. A PDUSB Hub is only addressed by SOP Packets.
PDUSB Peripheral A USB Device with a PD Capable UFP which is not a PDUSB Hub. A PDUSB Peripheral is only
addressed by SOP Packets.
PHY Layer The Physical Layer responsible for sending and receiving Messages across either VBUS or CC
between a Port Pair.
Policy Policy defines the behavior of PD capable parts of the system and defines the capabilities it
advertises, requests made to (re)negotiate power and the responses made to requests
received.
Policy Engine The Policy Engine interprets the Device Policy Manager’s input in order to implement Policy
for a given Port and directs the Protocol Layer to send appropriate Messages.
Port An interface typically exposed through a receptacle, or via a plug on the end of a hard-wired
captive cable. USB Power Delivery defines the interaction between a Port Pair.
Port Pair Two attached PD Capable Ports.
Port Partner A Contract is negotiated between a Port Pair connected by a USB cable. These ports are
known as Port Partners.
Power Conductor The wire delivering power from the Source to Sink. For example USB’s VBUS.
Power Consumer See Consumer
Power Data Object (PDO) Data Object used to expose a Source Port’s power capabilities or a Sink’s power requirements
as part of a Source_Capabilities or Sink_Capabilities Message respectively. Fixed, Variable
and Battery Power Data Objects are defined.
Power Delivery Mode Operation after a Contract has initially been established between a Port pair. This mode
persists during normal Power Delivery operation, including after a Power Role Swap. Power
Delivery mode can only be exited by detaching the ports, applying a Hard Reset or by the
Source removing power (except when power is removed during the Power Role Swap
procedure).
Power Provider See Provider
Power Reserve Power which is kept back by a Source in order to ensure that it can meet total power
requirements of attached Sinks on at least one Port.
Power Role Swap Process of exchanging the Source and Sink roles between Port Partners.
Preamble Start of a transmission which is used to enable the receiver to lock onto the carrier. The
Preamble consists of a 64-bit sequence of alternating 0s and 1s starting with a "0" and ending
with a "1" which is not 4b5b encoded.
Product Type Product categorisation returned as part of the Discover Identity Command.
Product Type VDO VDO identifying a certain Product Type in the ID Header VDO of a Discover Identity
Command.
Protocol Error An unexpected Message during an atomic Message sequence.
Protocol Layer The entity that forms the Messages used to communicate information between Port Partners.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 41

Term Description
Provider A capability of a PD Port (typically a Host, Hub, or Wall Wart DFP) to source power over the
power conductor (e.g. VBUS). This corresponds to a Type-A Port or a Type-C Port with Rp
asserted on its CC Wire.
Provider/Consumer A Provider with the additional capability to act as a Consumer. This corresponds to a Dual-
Role Type-A Port or a Dual-Role Type-C Port with Rp asserted on its CC Wire.
Re-negotiation A process wherein one of the Port Partners wants to alter the negotiated Contract.
Request Data Object (RDO) Data Object used by a Sink Port to negotiate a Contact as a part of a Request Message.
Responder The receiver of a Command request sent by an Initiator that replies with a Command
response.
Safe Operation Sources must have the ability to tolerate vSafe5V applied by both Port Partners.
Signaling A Preamble followed by an ordered set of four K-codes used to indicate a particular line
symbol e.g. Hard Reset as defined in Section 5.4.
Signaling Scheme Physical mechanism used to transmit bits. BMC and BFSK Signaling Schemes are defined in
this specification.
Single-Role Port A Port that is a Port only capable of operating as a Source or Sink, but not both.
Sink The Port consuming power from VBUS; most commonly a Device.
Soft Reset A process that resets the PD communications engine to its default state.
SOP Communication Communication using SOP Packets, also implies that a Message sequence is being followed.
SOP Packet Any Power Delivery Packet which starts with an SOP.
SOP* Communication Communication with a Cable Plug using SOP* Packets, also implies a Message sequence is
being followed.
SOP* Packet A term referring to any Power Delivery Packet starting with either SOP, SOP’ or SOP’’.
SOP’ Communication Communication with a Cable Plug using SOP’ Packets, also implies that a Message sequence is
being followed.
SOP’ Packet Any Power Delivery Packet which starts with an SOP’ used to communicate with a Cable Plug.
SOP’’ Communication Communication with a Cable Plug using SOP’’ Packets, also implies that a Message sequence
is being followed.
SOP’’ Packet Any Power Delivery Packet which starts with an SOP’’ used to communicate with a Cable
Plug when SOP’ Packets are being used to communicate with the other Cable Plug.
Source A role a Port is currently taking to supply power over VBUS; most commonly a Host or Hub
DFP.
Standard ID (SID) 16-bit unsigned value assigned by the USB-IF to a given industry standard.
Standard or Vendor ID Generic term referring to either a VID or a SID. SVID is used in place of the phrase “Standard
(SVID) or Vendor ID”.
Start of Packet (SOP) K-code marker used to delineate the start of a packet. Three start of packet sequences are
defined: SOP, SOP’ and SOP’’, with SOP* used to refer to all three in place of SOP/SOP’/SOP’’.
System Policy Overall system policy generated by the system, broken up into the policies required by each
Port Pair to affect the system policy. It is programmatically fed to the individual devices for
consumption by their Policy Engines.
System Policy Manager Module running on the USB Host. It applies the System Policy through communication with
PD capable Consumers and Providers that are also connected to the Host via USB.
Test Frame Frame consisting of a Preamble, SOP*, followed by test data (See Section 5.9.
Test Pattern Continuous stream of test data in a given sequence (See Section 5.9)
Tester The Tester is assumed to be a piece of test equipment that manages the BIST testing process
of a PD UUT.
Type-A Term used to refer to any A plug or receptacle including Micro-A plugs and Standard-A plugs
and receptacles, including the PD and non-PD versions. Micro-AB receptacles are assumed to
be a combination of Type-A and Type-B.
Type-B Terms used to refer to any B-plug or receptacle including Micro-B plugs and Standard-B
plugs and receptacles, including the PD and non-PD versions. Micro-AB receptacles are
assumed to be a combination of Type-A and Type-B.

Page 42 USB Power Delivery Specification Revision 2.0, Version 1.1

Term Description
Type-C Term used to refer to the Type-C connector plug or receptacle as defined in [USBType-C 1.0].
Unit Interval (UI) The time to transmit a single data bit on the wire.
Unit Under Test (UUT) The PD device that is being tested by the Tester and responds to the initiation of a particular
BIST test sequence.
Upstream Facing Port Typically a B Port on a Device as defined in [USB 2.0], [USB 3.1]or Type-C Port as defined in
(UFP) [USBType-C 1.0]. The default Device and Sink.
USB Attached State Synonymous with the [USB 2.0]] and [USB 3.1] definition of the attached state
USB Default Operation Operation of a Port at attach or after a Hard Reset where the DFP Source applies vSafe0V or
vSafe5V on VBUS and the UFP Sink is operating at vSafe5V as defined in [USB 2.0], [USB 3.1],
[USBType-C 1.0] or [BC 1.2].
USB Device Either a hub or a peripheral device as defined in [USB 2.0] and [USB 3.1].
USB Host The host computer system where the USB host controller is installed as defined in [USB 2.0]
and [USB 3.1].
USB Powered State Synonymous with the [USB 2.0] and [USB 3.1] definition of the powered state.
USB Safe State State of the Type-C connector when there are pins to be re-purposed (see [USBType-C 1.0])
so they are not damaged by and do not cause damage to their Port Partner.
USB-IF PD SID (PD SID) Standard ID allocated to this specification by the USB Implementer’s Forum.
VCONN Powered Accessory An accessory that is powered from VCONN to operate in a Mode (see [USBType-C 1.0]).
VCONN Source The Type-C Port responsible for sourcing VCONN.
VCONN Swap Process of exchanging the VCONN Source between Port Partners.
VDM Header The first Data Object following the Message Header in a Vendor Defined Message. The VDM
Header contains the SVID relating to the VDM being sent and provides information relating to
the Command in the case of a Structured VDM (see Section 6.4.4).
Vendor Data Object (VDO) Data Object used to send Vendor specific information as part of a Vendor_Defined Message.
Vendor Defined Message PD Data Message defined for vendor/standards usage. These are further partitioned into
(VDM) Structured VDM Messages, where Commands are defined in this specification, and
Unstructured VDM Messages which are entirely Vendor Defined (see Section 6.4.4).
Vendor ID (VID) 16-bit unsigned value assigned by the USB-IF to a given Vendor.
VI Same as power (i.e. voltage * current = power)
Wall Wart A power supply or “power brick” that is plugged into an AC outlet. It supplies DC power to
power a device or charge a battery.

1.7 Parameter Values

The parameters in this specification are expressed in terms of absolute values. For details of how each parameter is
measured in compliance please see [USBPDCompliance].

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 43

 2. Overview
This section contains no normative requirements.

2.1 Introduction
In USB Power Delivery, pairs of directly attached ports negotiate voltage, current and/or direction of power flow over
the USB cable, using VBUS or the CC wire as the communications channel. The mechanisms used, operate
independently of other USB methods used to negotiate power. Type-C connectors can support the CC wire as the
communications channel and in addition can support VBUS communication but not concurrently. Type-A and Type-B
connectors can only support VBUS communication.
USB Power Delivery also acts as a side-band channel enabling support for Standard or Vendor defined Modal
Operation. Modes are associated with a Standard or Vendor ID (SVID). Power Delivery Structured VDM Messages can
be used to discover supported SVIDs and Modes and then to enter and exit Modes as required. Multiple Active Modes
can also be in operation at the same time.
Any Contract negotiated using this specification, supersedes any and all previous power contracts established
whether from standard [USB 2.0], [USB 3.1], [USBType-C 1.0] or [BC 1.2] mechanisms. While in Power Delivery Mode
there will be a Contract in place (either Explicit or Implicit) determining the power level available and the direction of
that power. The Port Pair remains in Power Delivery Mode until the Port Pair is detached, there is a Hard Reset or the
Source removes power (except during a Power Role Swap when the initial Source removes power in order to for the
new Source to apply power).
An Explicit Contract is negotiated by the process of the Source sending a set of Capabilities, from which the Sink is
required to request a particular capability and then the Source accepting this request.
An Implicit Contract is the specified level of power allowed in particular states (i.e. during and after a Power Role
Swap, in dead battery operation or when operating with a low power device). Except for the case of low power
devices, Implicit Contracts are temporary; Port Pairs are required to immediately negotiate an Explicit Contract. In
the low power device case the Implicit Contract persists for as long as the Port Pair remains attached and the Source
continues to supply power.
Each Provider has a Local Policy, governing power allocation to its Ports. Sinks also have their own Local Policy
governing how they draw power. A System Policy can be enacted over USB that allows modification to these local
policies and hence management of overall power allocation in the system.
When PD Capable devices are attached to each other, the DFPs and UFPs initially default to standard USB Default
Operation. The DFP supplies vSafe5V and the UFP draws current in accordance with the rules defined by [USB 2.0],
[USB 3.1], [USBType-C 1.0] or [BC 1.2] specifications. After Power Delivery negotiation has taken place power can be
supplied at higher, or lower, voltages and higher currents than defined in these specifications. It is also possible to
perform a Power Role Swap to exchange the power supply roles such that the DFP receives power and the UFP
supplies power. For a Type-C connector it is possible to perform a Data Role Swap such that the DFP becomes the UFP
and vice-versa and to perform a VCONN Swap to change the end supplying VCONN to the cable.
Prior to an Explicit Contract the Source can discover the capabilities of the attached cable assembly. This is important
for [USBType-C 1.0] where 5A cabling is marked as well as other details of the cable assembly such as the supported
speed. Cable discovery occurs on initial attachment of a Port Pair, before an Explicit Contract has been established
where the DFP is the Source. It is also possible to carry out cable discovery after a Power Role Swap prior to
establishing an Explicit Contract, where the UFP is the Source and an Implicit Contract is in place.
Once an Explicit Contract is in place only the DFP is permitted to communicate with the attached cable assembly. This
communication can consist of discovering capabilities but may also include discover of SVIDs, Modes and the
entering/exiting of Modes supported by the cable assembly.

Page 44 USB Power Delivery Specification Revision 2.0, Version 1.1

 2.2 Section Overview
This specification contains the following sections:

Section 1 Introduction, conventions used in the document, list of terms and abbreviations, references and details
of parameter usage.

Section 2 Overview of the document including a description of the operation of PD and the architecture.

Section 3 Mechanical and electrical characteristics of the cables and connectors used by PD.

Section 4 Electrical requirements for Dead Battery operation and cable detection.

Section 5 Details of the PD PHY Layer requirements

Section 6 Protocol Layer requirements including the Messages, timers, counters and state operation.

Section 7 Power supply requirements for both Providers and Consumers.

Section 8 Device Policy Manager requirements.

Policy Engine Message sequence diagrams and state diagrams

Section 9 USBPD Device requirements including mapping of VBUS to USB states.

System Policy Manager requirements including descriptors, events and requests.

Appendix A Details of PD Power Profiles.

Appendix B Example CRC calculations.

Appendix C Considerations for power supply implementations.

Appendix D Mating illustrations for the Standard-A.

Appendix E Information relating to PHY Layer implementations.

Appendix F Scenarios illustrating Device Policy Manager operation.

Appendix G Examples of Structured VDM usage.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 45

 2.3 USB Power Delivery Capable Devices
Some examples of USB Power Delivery capable devices can be seen in Figure 2-1 (a Host, a Device, a Hub, and a
Charger). These are given for reference only and do not limit the possible configurations of products that can be built
using this specification.

Figure 2-1 Logical Structure of USB Power Delivery Capable Devices

USB Host USB Device USB Hub USB Charger

External UFP External UFP External External

power power power power

Power Power Power Power

Storage Storage Storage Storage

DFP DFP DFP

Legend Multiple Power

Multiple Power
inputs/outputs outputs

Optional Optional
Power input Feature
Power input

Each USB Power Delivery capable device is assumed to be made up of at least one Port. Providers are assumed to
have a Source and Consumers a Sink. Each device contains one, or more, of the following components:
 UFPs that:
o Sink power (a Consumer).
o Optionally source power (a Consumer/Provider).
o Optionally communicate via USB.
o Communicate using SOP Packets.
 DFPs that:
o Source power (a Provider).
o Optionally Sink power (a Provider/Consumer).
o Optionally communicate via USB.
o Communicate using SOP Packets
 Optionally Communicate using SOP* Packets.
 A Source that may be:
o An external power source e.g. AC.
o Power Storage (e.g. battery).
o Derived from another Port (e.g. bus-powered Hub).
 A Sink that may be:
o Power Storage (e.g. a battery).
o Used to power internal functions.
o Used to power devices attached to other devices (e.g. a bus-powered Hub).

Page 46 USB Power Delivery Specification Revision 2.0, Version 1.1

 2.4 SOP* Communication with Cable Plugs
2.4.1 SOP’ Communication
SOP’ Communication is recognized by electronics in one Cable Plug (which may be attached to either the UFP or DFP).
SOP Communication between the Port Partners is not recognized by the Cable Plug. Note: that the term Cable Plug in
the SOP’ Communication case is used to represent a logical entity in the cable which is capable of PD Communication
and which may or may not be physically located in the plug. Figure 2-2 outlines the usage of SOP’ Communications
between a Source and a Cable Plug. Figure 2-3 outlines the usage of SOP’ Communication between DFP and a Cable
Plug.
Both SOP Communication and SOP’ Communication take place over a single wire (either VBUS or CC). This means that
the SOP* Communication periods must be coordinated to prevent important communication from being blocked. For
a product which does not recognize SOP’ Packets, this will look like a non-idle channel, leading to missed packets and
retries. Communications between the Port Partners take precedence meaning that communications with the Cable
Plug can be interrupted, but will not lead to error recovery steps such as Hard Reset.
When no Explicit Contract or an Implicit Contract is in place (e.g. after a Power Role Swap) the Source (either the DFP
or UFP) can communicate with the Cable Plug using SOP’ Packets in order to determine its characteristics (see Figure
2-2). During this phase all communication with the Cable Plug is initiated and controlled by the Source which acts to
prevent conflicts between SOP* Packets. The Sink does not communicate with the Cable Plug, even if it is the DFP, and
Discards any SOP’ Packets received.
When an Explicit Contract is in place the DFP (either the Source or the Sink) can communicate with the Cable Plug
using SOP’ Packets (see Figure 2-3). During this phase all communication with the Cable Plug is initiated and
controlled by the DFP which acts to prevent conflicts between SOP* Packets. The UFP does not communicate with the
Cable Plug, even if it is the Source and Discards any SOP’ Packets received.

Figure 2-2 SOP’ Communication between Source and Cable Plug with no Explicit Contract or an Implicit Contract

Cable
Source Port Electronically Marked Cable Sink Port
Plug1

SOP’
signaling

SOP signaling

1
Cable Plug can be physically attached to either the Source or Sink Port.

Figure 2-3 SOP’ Communication between DFP and Cable Plug with PD Explicit Contract

Cable
DFP Electronically Marked Cable UFP
Plug1

SOP’
signaling

SOP signaling

1
Cable Plug can be physically attached to either the DFP or UFP.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 47

 2.4.2 SOP’’ Communication
SOP’ Packets are recognized by electronics in one Cable Plug attached to the DFP and are not recognized by the UFP or
the other Cable Plug. Similarly SOP’’ Packets are recognized by electronics in one Cable Plug attached to the UFP and
are not recognized by the UFP or the other Cable Plug. Communication between the Port Partners uses SOP Packets
which is not recognized by either Cable Plug. Note: that the term Cable Plug in the SOP’/SOP’’ Communication case is
used to represent a logical entity in the cable which is capable of PD Communication and which may or may not be
physically located in the plug but is physically associated with the plug. Figure 2-4 outlines the usage of SOP’’
Communication between a DFP and a Cable Plug.
SOP* Communication takes place over a single wire (either VBUS or CC). This means that the SOP* Communication
periods must be coordinated to prevent important communication being blocked. For a product which does not
recognize SOP’/SOP’’ Packets, this will look like a non-idle channel, leading to missed packets and retries. Cable Plugs
are forbidden from communicating with each other and can only respond to a Command request. Communications
between the Port Partners take precedence meaning that communications with the Cable Plug can be interrupted, but
do not lead to error recovery steps such as Hard Reset.
When no Explicit Contract or an Implicit Contract is in place (e.g. after a Power Role Swap), no SOP’’ communication
takes place.
When an Explicit Contract is in place the DFP (either the Source or the Sink) can communicate with the Cable Plugs
using SOP’/SOP’’ Packets (see Figure 2-3). During this phase all communication with the Cable Plugs is initiated and
Controlled by the DFP which acts to prevent conflicts between SOP* Packets. The UFP does not communicate with the
Cable Plug, even if it is the Source, and Discards any SOP’/SOP’’ Packets received.

Figure 2-4 SOP’’ Communication with the attached Cable Plugs

Cable Cable
DFP Plug Electronically Marked Cable Plug UFP
(SOP’) (SOP’’)

SOP’
signaling

SOP’’
signaling

SOP signaling

Page 48 USB Power Delivery Specification Revision 2.0, Version 1.1

 2.5 Operational Overview
A USB Power Delivery Port supplying power is known as a Source and a Port consuming power is known as a Sink.
There is only one Source Port and one Sink Port in each PD connection between Port Partners. Where USB products
support USB Power Delivery protocols a USB DFP is initially a Source and a USB UFP is initially a Sink, although USB
Power Delivery also enables both the Source/Sink roles and DFP/UFP roles to be swapped; DFP/UFP roles can only be
swapped on the Type-C connector.
The following sections describe the high level operation of ports taking on the roles of DFP, UFP, Source and Sink.
These sections do not describe operation that is not allowed; however if a certain behavior is not described then it is
probably not supported by this specification.
For details of how PD maps to USB states in a PDUSB Device see Section 9.1.2.

2.5.1 DFP Operation

The DFP operates differently depending on attachment status:
 At Attach (no PD Connection or Contract):
o The DFP can detect attachment of an A plug or detect Sink attachment via a C-Plug.
o The DFP typically sets VBUS to vSafe5V.
 Before PD Connection (no PD Connection or PD Contract):
o Prior to sending Source_Capabilities Messages the DFP detects the type of cabling attached and may
alter its advertised capabilities depending on the type of cable detected.
 For an A-plug or B-plug, plug detection will be carried out to determine the current carrying
capabilities of the cable.
 For a C-plug the default capability is 3A, but SOP’ Communication can be used to determine other
capabilities of the cable. The DFP can attempt to communicate with one of the Cable Plugs using
SOP’ Packets. If the Cable Plug responds then communication takes place.
o The DFP periodically advertises its capabilities by sending Source_Capabilities Messages.
 Establishing PD Connection (no PD Connection or Contract):
o Presence of a Port Partner is detected either:
 By receiving a GoodCRC Message in response to a Source_Capabilities Message.
 By receiving Hard Reset Signaling.
 Establishing Explicit Contract (PD Connection but no Explicit Contract or Implicit Contract after a Power Role
Swap):
o A DFP acting as a Source receives a Request Message from the UFP and responds with an Accept
Message, if this is a valid request, followed by a PS_RDY Message when its power supply is ready to
source power at the agreed level. At this point an Explicit Contract has been agreed.
o A DFP acting as a Sink receives a Source_Capabilities Message from the UFP and responds with a
Request Message. If this is a valid request the DFP receives an Accept Message followed by a PS_RDY
Message when its power supply is ready to source power at the agreed level. At this point an Explicit
Contract has been agreed.
o A DFP does not generate SOP’ or SOP’’ Packets, is not required to detect SOP’ or SOP’’ Packets and
Discards them.
 During PD Connection (Explicit Contract):
o The DFP processes and responds (if a response is required) to all Messages received and sends
appropriate Messages whenever its Local Policy requires.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 49

  The DFP can communicate with a Cable Plug using SOP’ or SOP’’ Communication at any time it is
not engaged in any other SOP Communications.
 If SOP Packets are received by the DFP, during SOP’ or SOP’’ Communication, the SOP’ or
SOP’’ Communication is immediately terminated (the Cable Plug times out and does not
retry)
 If the DFP needs to initiate an SOP Communication during an ongoing SOP’ or SOP’’
Communication (e.g. for a Capabilities change) then the SOP’ or SOP’’ Communications
will be interrupted.
 DFP acting as a Source:
 A DFP acting as a Source informs the UFP acting as a Sink whenever its capabilities
change, by sending a Source_Capabilities Message.
 A DFP acting as a Source, after a period of tSourceActivity, sends out Ping Messages if
no other Messages are being sent.
o Ping Messages are optional when the Source Port is operating at vSafe5V
and are not needed at all if a [USBType-C 1.0] connector is being used.
 A DFP using the [USBType-C 1.0] connector and acting as a Source will always have R p
asserted on its CC wire.
 DFP acting as a Sink (Power Role Swapped):
 A DFP acting as a Sink whose power needs have changed indicates this to the Source
with a new Request Message. The Sink Port may request one of the capabilities
previously offered by the Source, even if this is the vSafe5V output offered by [USB 2.0],
[USB 3.1], [USBType-C 1.0] or [BC 1.2], in order to enable future power negotiation.
o A DFP acting as a Sink not requesting any capability with a Request
Message results in an error.
o A DFP acting as a Sink unable to fully operate at the offered capabilities
requests an offered capability but indicates a capability mismatch i.e. that it
would prefer another power level also providing a physical indication of the
failure to the End User (e.g. using an LED).
 If a DFP acting as a Sink does not receive any Messages within tSinkActivity, it will issue
Hard Reset Signaling.
o A DFP acting as a Sink using the [USBType-C 1.0] connector does not run
the SinkActivityTimer and therefore does not time out on Messages since it
uses the detach detection mechanisms on this connector instead.
 A DFP using the [USBType-C 1.0] connector and acting as a Sink will always have R d
asserted on its CC wire.
 A DFP using the [USBType-C 1.0] connector may:
 initiate or receive a request for an exchange of data roles. After a Data Role Swap the
DFP (Host) becomes a UFP (Device). The direction of power and VCONN Source remain
unchanged.
 initiate or receive a request for an exchange of VCONN Source. During a VCONN Swap
VCONN is applied by both ends (make before break). The direction of power and
DFP/UFP roles remain unchanged.
 Detach or Communications Failure
o There are several ways to detect Detach

Page 50 USB Power Delivery Specification Revision 2.0, Version 1.1

  A DFP acting as a Source detects the failure to receive a GoodCRC Message in response to a Ping
Message or other Message within tReceive leads to a Soft Reset, within tSoftReset of the
CRCReceiveTimer expiring followed by a Hard Reset within tHardReset of the
CRCReceiveTimer expiring to begin restoring VBUS to USB Default Operation within ~50ms.
 Receiving no response to further attempts at communication is interpreted by the DFP
as a detach event (see Error handling).
 Ping Messages are optional when the Source Port is operating at vSafe5V and are not
needed at all if a [USBType-C 1.0] connector is being used.
 A DFP acting as a Sink detects the removal of VBUS and interprets this as the end of the PD
Connection.
 This is unless the vSafe0V is due to either a Hard Rest or Power Role Swap.
 A DFP acting as a Source or Sink detects plug removal and restores VBUS to USB Default Operation
within ~800ms (i.e. using Type-A insertion detect or Type-C detach detection via CC).
o Upon detach a DFP acting as either a Source or Sink returns to unattached behavior including returning
its power supply to sourcing the USB default of either vSafe0V or vSafe5V .
 Error handling
o Protocol Errors are handled by a Soft_Reset Message issued by either Port Partner, that resets counters,
timers and states, but does not change the negotiated voltage and current or the Port’s role (e.g. Source or
Sink) and does not cause an exit from Modal Operation.
o Serious errors are handled by Hard Reset Signaling issued by either Port Partner, that resets protocol as
for a Soft Reset but also returns the power supply to USB Default Operation (vSafe0V or vSafe5V output)
in order to protect the Sink. A Consumer/Provider operating as a Source returns to its default operation
as a Sink Port after the Hard Reset. A Hard Reset also causes all Active Modes to be exited such that the
Source is no longer in Modal Operation.
 After a Hard Reset it is expected that the Port Partner will respond within tNoResponse. If this
does not occur then 2 further Hard Resets are carried out before the DFP goes to the
PE_SRC_Disabled state at which point the PD Connection is assumed to have been terminated.
[USBType-C 1.0] Ports can perform additional error recovery steps at this point by entering the
ErrorRecovery state.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 51

 2.5.2 UFP Operation
The UFP operates differently depending on attachment status:
 VBUS Unpowered (no PD Connection or Contract):
o The UFP monitors VBUS for the presence of vSafe5V.
 VBUS Powered (no PD Connection or Contract):
o The UFP detects the presence of vSafe5V on VBUS and waits for a Source_Capabilities Message indicating
the presence of a PD capable Source.
o If the UFP does not receive a Source_Capabilities Message within tSinkWaitCap/tTypeCSinkWaitCap
then it issues Hard Reset Signaling in order to cause the Source Port to send a Source_Capabilities
Message if the Source Port is PD capable.
o The UFP does not generate SOP’ or SOP’’ Packets, is not required to detect SOP’ or SOP’’ Packets and
Discards them.
 Establishing PD Connection (no PD Connection or Contract):
o The UFP receives a Source_Capabilities Message and responds with a GoodCRC Message.
o The UFP does not generate SOP’ or SOP’’ Packets, is not required to detect SOP’ or SOP’’ Packets and
Discards them.
 Establishing Explicit Contract (PD Connection but no Explicit Contract or Implicit Contract after a Power Role
Swap):
o UFP acting as Sink:
 A UFP acting as a Sink receives a Source_Capabilities Message from the DFP and responds with a
Request Message. If this is a valid request the UFP receives an Accept Message followed by a
PS_RDY Message when its power supply is ready to source power at the agreed level. At this
point an Explicit Contract has been agreed.
 The Sink Port may request one of the capabilities offered by the Source, even if this is the
vSafe5V output offered by [USB 2.0], [USB 3.1], [USBType-C 1.0] or [BC 1.2], in order to
enable future power negotiation.
o For Sinks using an A-plug or B-plug the request will be limited by the type
of cabling detected. Plug detection will be carried out to determine the
current carrying capabilities of the cable.
o For Sinks using a C-plug the request is made from any capabilities offered
by the Source.
o A Sink not requesting any capability with a Request Message results in an
error.
 A Sink unable to fully operate at the offered capabilities requests the default capability
but indicates that it would prefer another power level and provide a physical indication
of the failure to the end user (e.g. using an LED).
 A UFP does not generate SOP’ or SOP’’ Packets, is not required to detect SOP’ or SOP’’ Packets and
Discards them.
o UFP acting as Source (Power Role Swapped):
 Prior to sending Source_Capabilities Messages a UFP acting as a Source detects the type of
cabling attached and may alter its advertised capabilities depending on the type of cable
detected.
 For an A-plug or B-plug, plug detection will be carried out to determine the current
carrying capabilities of the cable.

Page 52 USB Power Delivery Specification Revision 2.0, Version 1.1

  For a C-plug the default capability is 3A, but SOP’ Communication can be used to
determine other capabilities of the cable. The UFP can attempt to communicate with one
of the Cable Plugs using SOP’ Packets. If the Cable Plug responds then communication
takes place.
 A UFP acting as a Source receives a Request Message from the DFP and responds with an Accept
Message if this is a valid request followed by a PS_RDY Message when its power supply is ready
to source power at the agreed level. At this point an Explicit Contract has been agreed.
 A UFP does not generate SOP’’ Packets, is not required to detect SOP’’ Packets and Discards them.
 During PD Connection (Explicit Contract – Ready state)
o The UFP processes and responds (if a response is required) to all Messages received and sends
appropriate Messages whenever its Local Policy requires.
o UFP acting as a Sink:
 A UFP acting as a Sink whose power needs have changed indicates this to the Source with a new
Request Message. The Sink Port may request one of the capabilities previously offered by the
Source, even if this is the vSafe5V output offered by [USB 2.0], [USB 3.1], [USBType-C 1.0] or [BC
1.2], in order to enable future power negotiation.
 A UFP acting as a Sink not requesting any capability with a Request Message results in
an error.
 A UFP acting as a Sink unable to fully operate at the offered capabilities requests an
offered capability but indicates a capability mismatch i.e. that it would prefer another
power level also providing a physical indication of the failure to the End User (e.g. using
an LED).
 If the UFP acting as a Sink does not receive any Messages within tSinkActivity, will issue Hard
Reset Signaling.
 A UFP acting as a Sink using the [USBType-C 1.0] connector does not run the
SinkActivityTimer and therefore does not time out on Messages since it uses the detach
detection mechanisms on this connector instead.
 A UFP using the [USBType-C 1.0] connector and acting as a Sink will always have R d asserted on
its CC wire.
 DFP which is a Type-C DRP
o UFP acting as a Source (Power Role Swapped):
 The UFP acting as a Source informs the DFP acting as a Sink whenever its capabilities change, by
sending a Source_Capabilities Message.
 The UFP acting as a Source, after a period of tSourceActivity, sends out Ping Messages if no
other Messages are being sent.
 Ping Messages are optional when the Source Port is operating at vSafe5V and are not
needed at all if a [USBType-C 1.0] connector is being used.
 A UFP using the [USBType-C 1.0] connector and acting as a Source will always have R p asserted
on its CC wire.
o The UFP does not generate SOP’ or SOP’’ Packets, is not required to detect SOP’ or SOP’’ Packets and
Discards them.
o A UFP, using the [USBType-C 1.0] connector, may:
 initiate or receive a request for an exchange of data roles. After a Data Role Swap the UFP
(Device) becomes a DFP (Host). The direction of power and VCONN Source remain unchanged.
 initiate or receive a request for an exchange of VCONN Source. During a VCONN Swap VCONN is
applied by both ends (make before break). The direction of power and DFP/UFP roles remain
unchanged.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 53

 Detach or Communications Failure
o There are several ways to detect Detach
 A UFP acting as a Sink detects the removal of VBUS and interprets this as the end of the PD
Connection.
 This is unless the vSafe0V is due to either a Hard Rest or Power Role Swap.
 A UFP acting as a Source detects the failure to receive a GoodCRC Message in response to a Ping
Message or other Message within tReceive. This leads to a Soft Reset, within tSoftReset of the
CRCReceiveTimer expiring followed by a Hard Reset within tHardReset of the
CRCReceiveTimer expiring to begin restoring VBUS to USB Default Operation within ~50ms.
 Receiving no response to further attempts at communication is interpreted by the UFP
as a detach event (see Error handling).
 Ping Messages are optional when the Source Port is operating at vSafe5V and are not
needed at all if a [USBType-C 1.0] connector is being used.
 A DFP acting as a Source or Sink detects plug removal and restores V BUS to USB Default Operation
within ~800ms (i.e. using Type-A insertion detect or Type-C detach detection via CC).
o Upon detach a UFP acting as either a Sink or Source stops supplying power and returns to its default
behavior as an unattached Sink Port.
 Error handling
o Protocol Errors are handled by a Soft_Reset Message issued by either Port Partner, that resets counters,
timers and states, but does not change the negotiated voltage and current or the Port’s role (e.g. Source or
Sink) and does not cause an exit from Modal Operation.
o Serious errors are handled by issuing Hard Reset Signaling that resets protocol as for a Soft Reset but
also returns the power supply to its USB default current and voltage. A Provider/Consumer operating as
a Sink returns to its USB Default Operation as a Source Port outputting vSafe0V or vSafe5V after the Hard
Reset. A Hard Reset also causes all Active Modes to be exited such that the Sink is no longer in Modal
Operation.
 After a Hard Reset it is expected that the Port Partner will respond within tNoResponse. If this
does not occur then 2 further Hard Resets are carried out before the UFP stays in the
PE_SNK_Wait_for_Capabilities state at which point the PD Connection is assumed to have been
terminated. [USBType-C 1.0] Ports can perform additional error recovery steps at this point.

Page 54 USB Power Delivery Specification Revision 2.0, Version 1.1

 2.5.3 Cable Plug Operation
The DFP operates differently depending on attachment status:
 Before PD Connection (no Contract):
o The DFP operating as a Source can attempt to communicate with one of the Cable Plugs using SOP’
Packets
 If the Cable Plug responds then communication takes place.
 Establishing PD Connection (no Contract):
o The DFP does not generate SOP’ Packets, is not required to detect SOP’ Packets and Discards them.
 Establishing Explicit Contract (PD Connection but no Explicit Contract or Implicit Contract after a Power Role
Swap):
o The DFP or UFP operating as a Source can attempt to communicate with one of the Cable Plugs using SOP’
Packets
 If the Cable Plug responds then communication takes place.
 During PD Connection (Explicit Contract):
o The DFP can communicate with a Cable Plug, using SOP’ Packets or SOP’’ Packets, at any time it is not
engaged in any other SOP Communications.
o If SOP Packets are received by the DFP, during SOP’ or SOP’’ Communication, the SOP’ or SOP’’
Communication is immediately terminated (the Cable Plug times out and does not retry)
o If the DFP needs to initiate an SOP Communication during an ongoing SOP’ or SOP’’ Communication (e.g.
for a Capabilities change) then the SOP’ or SOP’’ Communications will be interrupted.
 Detach or Communications Failure:
o There is no communication timeout scheme between the DFP and Cable Plug since communications may
be interrupted at any time.
 Error handling:
o The Cable Plug can detect Hard Reset Signaling to determine that the DFP and UFP have been reset and
will need to reset itself (equivalent to a power cycle).
 The Cable Plug cannot generate Hard Reset Signaling itself.
o A Cable Plug can detect Cable Reset Signaling to determine that it will need to reset itself (equivalent to a
power cycle).

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 55

 2.6 Architectural Overview
This logical architecture is not intended to be taken as an implementation architecture. An implementation architecture
is, by definition, a part of product definition and is therefore outside of the scope of this specification.
This section outlines the high level logical architecture of USB Power Delivery referenced throughout this
specification. In practice various implementation options are possible based on many different possible types of PD
device. PD devices may have many different configurations e.g. USB or non-USB communication, single versus
multiple ports, dedicated power supplies versus supplies shared on multiple ports, hardware versus software based
implementations etc. The architecture outlined in this section is therefore provided only for reference in order to
indicate the high level logical model used by the PD specification. This architecture is used to identify the key
concepts and also to indicate logical blocks and possible links between them.
The USB Power Delivery architecture in each USB Power Delivery capable Device is made up of a number of major
components.
The communications stack seen in Figure 2-5 consists of:
 A Device Policy Manager (see Section 8.2) that exists in all devices and manages USB Power Delivery resources
within the device across one or more ports based on the Device’s Local Policy.
 A Policy Engine (see Section 8.3) that exists in each USB Power Delivery Port implements the Local Policy for that
Port.
 A Protocol Layer (see Chapter 5.9.9) that enables Messages to be exchanged between a Source Port and a Sink
Port.
 A Physical Layer (see Chapter 5) that handles transmission and reception of bits on the wire and handles data
transmission.

Figure 2-5 USB Power Delivery Communications Stack

Provider Consumer
Device Policy Device Policy
Manager Manager

Policy Engine Policy Engine

Protocol Protocol

Physical Layer Physical Layer

VBUS/CC

Additionally USB Power Delivery devices which can operate as USB devices may communicate over USB (see Figure
2-6). An optional System Policy Manager (see Chapter 9) that resides in the USB Host communicates with the PD
Device over USB, via the root Port and potentially over a tree of USB Hubs. The Device Policy Manager interacts with
the USB interface in each device in order to provide and update PD related information in the USB domain. Note that a
PD device is not required to have a USB device interface.

Page 56 USB Power Delivery Specification Revision 2.0, Version 1.1

 Figure 2-6 USB Power Delivery Communication Over USB

USB Host

System Policy
Manager

USB hub tree

(optional)

PD USB
Device
USB Interface
(optional)

Device Policy
Manager

Policy Engine

Protocol

Physical Layer

VBUS/CC

Figure 2-7 shows the logical blocks between two attached PD ports. In addition to the communication stack described
above there are also:
 For a Provider or Dual-Role Device: one or more Sources providing power to one or more ports.
 For a Consumer or Dual-Role Device: a Sink consuming power.
 A Cable Detection module (see Section4.4) that:
o Detects presence of VBUS for Sink Ports
o Identifies the type of PD cable attached
 USB Power Delivery uses either Type-A and Type-B PD Cabling is defined in Section 3 or standard cabling
defined in [USB 2.0], [USB 3.1], and [USBType-C 1.0].
The Device Policy Manager talks to the communication stack, Source/Sink and the cable detection block in order to
manage the resources in the Provider or Consumer.
Figure 2-7 illustrates a Provider and a Consumer. Dual-Role Devices such as Provider/Consumers or
Consumer/Providers can be constructed by combining the elements of both Provider and Consumer into a single
device. Providers can also contain multiple Source Ports each with their own communications stack and cable
detection.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 57

 Figure 2-7 High Level Architecture View

Provider Consumer

Device Policy Manager Device Policy Manager

Source Port Sink Port

Policy Engine Policy Engine

Protocol Power Power Protocol

Source(s) Sink

Cable Detection Physical Layer Physical Layer Cable Detection

BMC BFSK BFSK BMC

USB Port USB Port

Type-A/B Plug Type-A/B Plug
CC (Type-C only) VBUS VBUS CC (Type-C only) identification
identification

VBUS

CC

2.6.1 Policy
There are two possible levels of Policy:
1) System Policy applied system wide by the System Policy Manager across multiple Providers or Consumers.
2) Local Policy enforced on a Provider or Consumer by the Device Policy Manager.
Policy comprises several logical blocks:
 System Policy Manager (system wide).
 Device Policy Manager (one per Provider or Consumer).
 Policy Engine (one per Source or Sink Port).

2.6.1.1 System Policy Manager

Since the USB Power Delivery protocol is essentially point to point, implementation of a System Policy requires
communication by an additional data communication mechanism i.e. USB. The System Policy Manager monitors and
controls System Policy between various Providers and Consumers connected via USB. The System Policy Manager
resides in the USB Host and communicates via USB with the Device Policy Manager in each connected Device. Devices
without USB data communication capability or are not data connected, will not be able to participate in System Policy.
The System Policy Manager is optional in any given system so USB Power Delivery Providers and Consumers can
operate without it being present. This includes systems where the USB Host does not provide a System Policy
Manager and may also include “headless” systems without any USB Host. In those cases where a Host is not present,
USB Power Delivery is useful for charging purposes, or the powering of devices since useful USB functionality is not
possible. Where there is a USB Host but no System Policy Manager, Providers and Consumers can negotiate power
between themselves, independently of USB power rules, but are more limited in terms of the options available for
managing power.

Page 58 USB Power Delivery Specification Revision 2.0, Version 1.1

 2.6.1.2 Device Policy Manager
The Device Policy Manager provides mechanisms to monitor and control the USB Power Delivery system within a
particular Consumer or Provider. The Device Policy Manager enables Local Policies to be enforced across the system
by communication with the System Policy Manager. Local Policies are enacted on a per Port basis by the Device Policy
Manager’s control of the Source/Sink Ports and by communication with the Policy Engine and Cable Detection for that
Port.

2.6.1.3 Policy Engine

Providers and Consumers are free to implement their own Local Policies on their directly connected Source or Sink
Ports. These will be supported by negotiation and status mechanisms implemented by the Policy Engine for that Port.
The Policy Engine interacts directly with the Device Policy Manager in order to determine the present Local Policy to
be enforced. The Policy Engine will also be informed by the Device Policy Manager whenever there is a change in
Local Policy (e.g. a capabilities change).

2.6.2 Message Formation and Transmission

2.6.2.1 Protocol Layer
The Protocol Layer forms the Messages used to communicate information between a pair of ports. It is responsible
for forming Capabilities Messages, requests and acknowledgements. Additionally it forms Messages used to swap
roles and maintain presence. It receives inputs from the Policy Engine indicating which Messages to send and
indicates the responses back to the Policy Engine.
The basic protocol uses a push model where the Provider pushes it capabilities to the Consumer that in turn responds
with a request based on the offering. However, the Consumer may asynchronously request the Provider’s present
capabilities and may select another voltage/current.

2.6.2.2 PHY Layer

The PHY Layer is responsible for sending and receiving Messages across either the VBUS or CC wire. It consists of a
transceiver that superimposes a Signaling Scheme (BFSK on VBUS or BMC on CC) on the wire. The PHY Layer is
responsible for managing data on the wire. It tries to avoid collisions on the wire, recovering from them when they
occur. It also detects errors in the Messages using a CRC.

2.6.3 Power supply

2.6.3.1 Source
Each Provider will contain one or more Sources that are shared between one or more ports. These Sources are
controlled by the Local Policy. Sources start up in USB Default Operation where the Port applies vSafe0V or vSafe5V
on VBUS and return to this state on detach or after a Hard Reset. If the Source applies vSafe0V as their default, it
detects attach events and transitions its output to vSafe5V upon detecting an attach.

2.6.3.2 Sink
Consumers are assumed to have one Sink connected to a Port. This Sink is controlled by Local Policy. Sinks start up in
USB Default Operation where the Port can operate at vSafe5V with USB default specified current levels and return to
this state on detach or after a Hard Reset.

2.6.3.3 Dual-Role Ports

Dual-Role ports can be either a Provider/Consumer or Consumer/Provider meaning that they have the ability to
operate as either a Source or a Sink. A Provider/Consumer is a Port that can operate as either a Source Port (default)
or a Sink Port. A Consumer/Provider is a Port that can operate either as a Sink Port (default) or a Source Port.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 59

Combination supplies that support Dual-Role ports follow the default rules as well as supporting a return to their own
default role and state on a detach event or Hard Reset.

2.6.3.4 Dead Battery or Lost Power Detection

The USB Power Delivery specification defines mechanisms intended to communicate with and charge a
Provider/Consumer with a Dead Battery. A Provider/Consumer may also use this mechanism to get power when they
are disconnected from their normal power source. All Consumer/Providers support this mechanism.

2.6.4 Cable and Connectors

2.6.4.1 Cable Detection
The Cable Detection block provides mechanisms to detect the type of cable attached. This information is provided to
the Device Policy Manager. It adjusts the Local Policy accordingly and may also communicate cabling issues to the
System Policy Manager for further action.
The USB Power Delivery specification assumes certified USB cables as defined in this specification or in the [USB 2.0],
[USB 3.1], or [USBType-C 1.0] specifications.
For Type-A and Type-B connectors the existence of a large number of non-compliant legacy cables, particularly ‘Y’ and
‘W’ cables are problematic. These kinds of cables, in combination with the higher voltages that PD can deliver, have
the potential to permanently damage the user’s equipment. PD defines mechanisms to detect Type-A and Type-B PD
capable cables.
For Type-C connectors, PD uses the certified USB cables and associated detection mechanisms as defined in
[USBType-C 1.0].

2.6.4.2 Interactions between Non-PD, BC and PD devices

USB Power Delivery only operates when two USB Power Delivery devices are directly connected. When a Device finds
itself a mixed environment, where the other device does not support the USB Power Delivery Specification, the
existing rules on supplying vSafe5V as defined in the [USB 2.0], [USB 3.1], [BC 1.2] or [USBType-C 1.0] specifications
are applied.
There are two primary cases to consider:
 The Host (DFP) is non-PD and as such will not send any advertisements. An attached PD capable Device will not
see any advertisements and operates using the rules defined in the [USB 2.0], [USB 3.1], [BC 1.2] or [USBType-C
1.0] specifications.
 The Device (UFP) is non-PD and as such will not see any advertisements and therefore will not respond. The Host
(DFP) will continue to supply vSafe5V to VBUS as specified in the [USB 2.0], [USB 3.1], [BC 1.2] or [USBType-C 1.0]
specifications.

2.6.4.3 Power Profiles

Power Profiles are used to define voltages and current ranges that may be offered by USB Power Delivery Sources.
Although Profiles are defined for Sources, Sinks may refer to a Profile that will meet their power requirements. See
Appendix A for further details.

Page 60 USB Power Delivery Specification Revision 2.0, Version 1.1

3. Type-A and Type-B Cable Assemblies and Connectors
USB Power Delivery is designed to operate at voltages and currents outside the specified ranges defined in [USB 2.0],
[USB 3.1] and [BC 1.2] specifications. For this reason it is critical to understand the characteristics of the USB Power
Delivery cable assemblies and the connectors used. The following sections define the assumed characteristics of both
non-PD Type-A and Type-B cable assemblies (non-marked cable assemblies) and USB Power Delivery cable
assemblies designed to take advantage of the USB Power Delivery system (marked cable assemblies). Cable
assemblies for use with Type-C connectors are defined in [USBType-C 1.0] and are not covered in this specification.
The considerable presence of non-compliant legacy cable assemblies presents an additional challenge to safely deliver
voltages other than vSafe5V. ‘Y’ cable assemblies, for example, provide topologies and connections that are not
included in the original USB specifications. As a result, there is a requirement to identify cable assemblies used in
support of this specification that deliver more than vSafe5V.
The additional requirements for USB Power Delivery cable assemblies are defined in this section. Unlike typical USB
philosophy, both the Device and the Host are responsible for detecting the insertion of a USB Power Delivery cable
assembly and make requests for power accordingly.

3.1 Significant Features

This section identifies the significant features of the USB Power Delivery connectors and cable assemblies. This
section references other parts of the document where further details can be found.

3.1.1 Connectors
The USB PD specification defines the following connectors:
 PD Standard-A plug and receptacle
 PD Standard-B plug and receptacle
 PD Micro-A plug
 PD Micro-AB receptacle
 PD Micro-B plug and receptacle
USB PD connectors are differentiated from their standard USB counterparts in their current carrying capability as well
as electrical markings or physical features, while remaining mechanically compatible. The USB PD Micro connectors
are mechanically identical to their non-PD counterparts. The USB PD Standard connector mechanical differences are
specified in this chapter.
 PD Micro-A, PD Micro-AB, and PD Micro-B connectors shall be capable of carrying 3A current as specified in
Section 3.6.5.1.
 PD Standard-A and PD Standard-B connectors shall be capable of carrying 5A current as specified in Section
3.6.5.2.
Refer to Section 3.4 for marking details. For details on the usage of the PD icon refer to Section 3.5.
Appendix D illustrates mating conditions of Standard-A connector combinations.
Table 3-1 lists the compatible plugs and receptacles and possible roles which may be supported in each case. Note
that for AB receptacles it is not required that if the Provider/Consumer role is supported with an A-plug inserted, that
the Consumer/Provider role is supported with a B-plug inserted or vice-versa. Standard, non-PD, receptacles used in
USB Power Delivery capable products are limited to a nominal vSafe5V at 1.5A as defined in [BC 1.2].

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 61

 Table 3-1 Plugs Accepted By Receptacles

Receptacle Plugs Accepted Possible Role

USB 2.0 Standard-A USB 2.0 Standard-A, USB 2.0 PD Standard-A, Provider, Provider/Consumer
USB 3.1 Standard-A, or USB 3.1 PD
Standard-A
USB 2.0 PD Standard-A USB 2.0 PD Standard-A, USB 2.0 Standard-A, Provider, Provider/Consumer
USB 3.1 PD Standard-A, or USB 3.1
Standard-A
USB 3.1 Standard-A USB 3.1 Standard-A, USB 3.1 PD Standard-A, Provider, Provider/Consumer
USB 2.0 Standard-A, or USB 2.0 PD
Standard-A
USB 3.1 PD Standard-A USB 3.1 PD Standard-A, USB 3.1 Standard-A, Provider, Provider/Consumer
USB 2.0 PD Standard-A, or USB 2.0
Standard-A
USB 2.0 Standard-B USB 2.0 Standard-B or USB 2.0 PD Consumer, Consumer/Provider
Standard-B
USB 2.0 PD Standard-B USB 2.0 PD Standard-B or USB 2.0 Consumer, Consumer/Provider
Standard-B
USB 3.1 Standard-B USB 3.1 Standard-B, USB 3.1 PD Standard-B, Consumer, Consumer/Provider
USB 2.0 Standard-B, USB 2.0 PD Standard-B
or USB 3.1 Powered-B
USB 3.1 PD Standard-B USB 3.1 PD Standard-B, USB 3.1 Standard-B, Consumer, Consumer/Provider
USB 2.0 PD Standard-B, USB 2.0 Standard-B,
or USB 3.1 Powered-B
USB 3.1 Powered-B USB 3.1 Powered-B, USB 3.1 Standard-B, Consumer, Consumer/Provider
USB 3.1 PD Standard-B, USB 2.0 Standard-B,
or USB 2.0 PD Standard-B
USB 2.0 Micro-B USB 2.0 Micro-B or USB 2.0 PD Micro-B Consumer, Consumer/Provider
USB 2.0 PD Micro-B USB 2.0 PD Micro-B or USB 2.0 Micro-B Consumer, Consumer/Provider
USB 3.1 Micro-B USB 3.1 Micro-B, USB 3.1 PD Micro-B, USB Consumer, Consumer/Provider
2.0 Micro-B, or USB 2.0 PD Micro-B
USB 3.1 PD Micro-B USB 3.1 PD Micro-B, USB 3.1 Micro-B, USB Consumer, Consumer/Provider
2.0 PD Micro-B, or USB 2.0 Micro-B
USB 2.0 Micro-AB USB 2.0 Micro-A, or USB 2.0 PD Micro-A Provider, Provider/Consumer,
USB 2.0 Micro-B, USB 2.0 PD Micro-B Consumer, Consumer/Provider
USB 2.0 PD Micro-AB USB 2.0 PD Micro-A, or USB 2.0 Micro-A Provider, Provider/Consumer
USB 2.0 PD Micro-B, USB 2.0 Micro-B, Consumer, Consumer/Provider
USB 3.1 Micro-AB USB 2.0 Micro-A, or USB 2.0 PD Micro-A, Provider, Provider/Consumer
USB 3.1 Micro-A, USB 3.1 PD Micro-A

USB 2.0 Micro-B, USB 2.0 PD Micro-B, Consumer, Consumer/Provider

USB 3.1 Micro-B, USB 3.1 PD Micro-B

USB 3.1 PD Micro-AB USB 2.0 PD Micro-A, or USB 2.0 Micro-A Provider, Provider/Consumer
USB 3.1 PD Micro-A, USB 3.1 Micro-A
USB 2.0 PD Micro-B, USB 2.0 Micro-B, Consumer, Consumer/Provider
USB 3.1 PD Micro-B, USB 3.1 Micro-B

3.1.1.1 USB 2.0 PD Standard-A Connector

The USB 2.0 PD Standard-A connector is defined as the host connector. It has the same mating interface as the USB 2.0
Standard-A connector, but with mechanical differences to provide a means of detecting insertion and PD support.
Refer to Section 3.2.3 for mechanical details, pin assignments, and descriptions.

Page 62 USB Power Delivery Specification Revision 2.0, Version 1.1

A USB 2.0 PD Standard-A receptacle accepts a USB 2.0 PD Standard-A plug, a USB 2.0 Standard-A plug, a USB 3.1 PD
Standard-A plug, or a USB 3.1 Standard-A plug. Similarly, a USB 2.0 PD Standard-A plug may be mated with a USB 2.0
PD Standard-A receptacle, a USB 2.0 Standard-A receptacle, a USB 3.1 PD Standard-A receptacle, or a USB 3.1
Standard-A receptacle.

3.1.1.2 USB 3.1 PD Standard-A Connector

The USB 3.1 PD Standard-A connector is defined as a host connector. It has the same mating interface as the USB 3.1
Standard-A connector, but with mechanical differences to provide a means of detecting insertion and PD support.
Refer to Section 3.2.4 for mechanical details, pin assignments, and descriptions.
A USB 3.1 PD Standard-A receptacle accepts a USB 3.1 PD Standard-A plug, a USB 3.1 Standard-A plug, a USB 2.0 PD
Standard-A plug, or a USB 2.0 Standard-A plug. Similarly, a USB 3.1 PD Standard-A plug may be mated with a USB 3.1
PD Standard-A receptacle, a USB 3.1 Standard-A receptacle, a USB 2.0 PD Standard-A receptacle, or a USB 2.0
Standard-A receptacle.

3.1.1.3 USB 2.0 PD Standard-B Connector

The USB 2.0 PD Standard-B connector is defined to facilitate deliver of up to 100 Watts. An ID pin supports PD
identification. Refer to Section 3.2.5 for mechanical details, pin assignments, and descriptions.
A USB 2.0 PD Standard-B receptacle accepts either a USB 2.0 PD Standard-B plug or a USB 2.0 Standard-B plug.
Inserting a USB 3.1 PD Standard-B plug, a USB 3.1 Standard-B plug, or a USB 3.1 Powered-B plug into a USB 2.0 PD
Standard-B receptacle is physically disallowed. A USB 2.0 PD Standard-B plug may be mated with a USB 2.0 PD
Standard-B receptacle, a USB 2.0 Standard-B receptacle, a USB 3.1 PD Standard-B receptacle, a USB 2.0 Standard-B
receptacle, or a USB 3.1 Powered-B receptacle.

3.1.1.4 USB 3.1 PD Standard-B Connector

The USB 3.1 PD Standard-B connector is defined to facilitate delivery of up to 100 Watts. An ID pin supports PD
identification. Refer to Section 3.2.6 for mechanical details, pin assignments, and descriptions.
A USB 3.1 PD Standard-B receptacle accepts a USB 3.1 PD Standard-B plug, a USB 3.1 Standard-B plug, a USB 3.1
Powered-B plug, a USB 2.0 PD Standard-B plug, or a USB 2.0 Standard-B plug. Inserting a USB 3.1 PD Standard-B plug
or a USB 3.1 Standard-B plug into a USB 2.0 PD Standard-B receptacle or a USB 2.0 Standard-B receptacle is physically
disallowed. A USB 3.1 PD Standard-B plug may be mated with a USB 3.1 PD Standard-B receptacle, a USB 3.1
Standard-B receptacle, or a USB 3.1 Powered-B receptacle.

3.1.2 Compliant Cable Assemblies

The USB Power Delivery Specification defines the following cable assemblies:
 USB 3.1 PD Standard-A plug to USB 3.1 PD Standard-B plug
 USB 3.1 PD Standard-A plug to USB 3.1 PD Micro-B plug
 USB 3.1 PD Micro-A plug to USB 3.1 PD Micro-B plug
 USB 3.1 PD Micro-A plug to USB 3.1 PD Standard-B plug
 USB 2.0 PD Standard-A plug to USB 2.0 PD Standard-B plug
 USB 2.0 PD Standard-A plug to USB 2.0 PD Micro-B plug
 USB 2.0 PD Micro-A plug to USB 2.0 PD Micro-B plug
 USB 2.0 PD Micro-A plug to USB 2.0 PD Standard-B plug
PD cable assemblies shall have one plug on each end. PD Cable assemblies with multiple connectors on either end are
expressly prohibited due to the danger of back-powering USB ports with high voltages. Any cable combinations not
explicitly defined in the list above shall not be permitted.
Connectors on each end of the PD cable assembly shall be labeled with the appropriate USB PD icon defined in Section
3.5.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 63

 3.1.3 USB Power Delivery Adapters (USB plug to USB receptacle)
This section has been deleted. Adapters from a USB plug to a USB receptacle are not supported by PD because their
use may result in unacceptable VGND_DROP, restricting USB 2.0 signaling capability.

3.1.4 Hardwired Captive PD Cable

A hardwired captive PD cable assembly has a single PD plug at one end and a single hardwired (non-removable)
connection at the other end. A hardwired captive PD cable assembly is PD compliant if it meets the requirements of
this specification at the connector end cable marking or marking detection, negotiation capability, etc. and supports
USB PD. A hardwired captive PD cable assembly may support USB signaling. The initial role of a Port with a
hardwired captive cable assembly may be either a Provider or a Consumer as determined by the type of plug.
The connector on the hardwired captive PD cable assembly shall be labeled with the appropriate USB PD icon defined
in Section 3.5.

3.1.5 Standard-A Insertion Detect

Insertion Detect is a feature added to the Standard-A receptacle to support Cold Socket capability. It may be
implemented in a Standard-A receptacle or a PD Standard-A receptacle. Insertion Detect provides an open circuit
condition on pin 13 when a plug is not detected in the Standard-A receptacle and a connection to the receptacle shield
on pin 13 when a plug is present. Schematic representation is provided in Figure 3-1 to illustrate the electrical
implementation of the detection mechanism if pin 12 is present. Implementation is vendor-specific. The Insertion
Detect feature shall be implemented for Cold Socket Standard-A applications and optional for all other Standard-A
implementations. See Section 3.2.1 for the mechanical requirements, and Sections 3.6.1, 3.6.2 and 4.1.2 for the
electrical description.

Figure 3-1 Standard-A Insertion Detect Schematic Representation

3.1.6 Standard-A PD Detect

The PD Detect contact is a feature added to the PD Standard-A receptacle to detect the presence of a PD Standard-A
plug. Implementation of PD Detect shall include either pin 10, pin 11, or both pin 10 and pin 11 in the PD Standard-A
receptacle. If both pins 10 and 11 are present then both shall be connected to the PD Detect logic. Depending on the
detection mechanism and location, two pins may be required to ensure PD Detect if the plug is skewed within the
receptacle. If two pins are used for PD Detect, then a closed circuit to the shield on either pin is considered PD
detected.
PD Detect shall be an open circuit when PD is not detected (refer to Figure 3-2, Figure 3-3 and Figure 3-4) and shall be
connected to the receptacle shield when a PD Standard-A plug is present (Figure 3-5). PD Detect shall be a closed
circuit to the shield when the PD plug is detected.
The PD Standard-A receptacle shall not connect PD Detect to the receptacle shield when a USB Thin Card is inserted,
as shown in Figure 3-4.

Page 64 USB Power Delivery Specification Revision 2.0, Version 1.1

Schematic representation is provided (Figure 3-5) to illustrate the electrical implementation of the detection
mechanism when the implementation uses the PD Standard-A plug shield as a conductor to complete the detection
circuit. The mechanics of the implementation are vendor-specific.

Figure 3-2 PD Standard-A No Plug Detection Circuit

Figure 3-3 Non-PD Plug Standard-A Detection Circuit

Figure 3-4 USB Thin Card Standard-A Detection Circuit

Figure 3-5 PD Plug Standard-A Detection Circuit

See Appendix D for mechanical details of different connector mating situations. See Section 3.6.1 and 3.6.2 for the
electrical performance requirements.

3.1.7 Raw Cables

Attention should be given for the possibility of signal interference from V BUS, especially at higher operating current
and voltage, in PD cable assemblies that are capable of Hi-Speed or Enhanced SuperSpeed data communication. See
Section 3.6.6 crosstalk requirements.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 65

 3.2 Connector Mating Interfaces
This section defines the connector mating interfaces, including the connector interface drawings, pin assignments and
descriptions. All dimensions are in mm.

3.2.1 Standard-A Insertion Detect Mechanical Dimensions

The Insertion Detect feature is optional if Cold Socket is not implemented. Figure 3-6 shows the mechanical
dimensions for the zone where the Insertion Detect mechanism on the Standard-A and PD Standard-A receptacle shall
activate when any type of Standard-A plug is inserted. This zone applies to any USB 2.0 or USB 3.1 versions of
receptacles. The detection mechanism shall be designed such that the insertion detect electrical requirements are
met, regardless of power being applied. Special consideration should be given to the location of shell features such as
retention springs and cutout areas. The sample implementation shown in Figure 3-6 is for reference only.

Figure 3-6 Insertion Detect Zone Mechanical Dimensions for the Standard-A Receptacle

3.2.2 USB PD Standard-A PD Detect Mechanical Requirement

Figure 3-7 shows the mechanical dimensions for the range where the PD Detect mechanism on the PD Standard-A
receptacle shall indicate PD Detect when a PD Standard-A plug is inserted. The dimensions shall apply to planes
parallel to Datum A and shall apply to both USB 2.0 and USB 3.1 versions of PD Standard-A receptacles.
Implementation is vendor specific. The sample implementation in the Figure 3-7 is for reference only. PD detect
electrical characteristics are defined in Section 3.1.6. The implementation shall also conform to the following
requirements:
 The metal shell of the USB PD Standard-A plug is nominally 1.3 mm longer than the USB Standard-A plug to
provide a means for PD Detect.
 The metal shell of the USB PD Standard-A plug shall be gold plated on the inner and outer surfaces a minimum of
1.6 mm from the leading edge.
 Contact for PD Detect shall occur on either the inner or the outer surface of the plug shell.
 The insertion of a USB ThinCard shall not indicate PD Detect.

Page 66 USB Power Delivery Specification Revision 2.0, Version 1.1

 Figure 3-7 PD Detect Plane Location Range for PD Standard-A Receptacles

3.2.3 USB 2.0 PD Standard-A Connector

3.2.3.1 Interface Definition
Figure 3-8, Figure 3-9, and Figure 3-10 show the USB 2.0 PD Standard-A plug, the USB 2.0 PD Standard-A receptacle
and a reference footprint for the USB 2.0 PD Standard-A receptacle, respectively.
Mechanical requirements governing mating interoperability of the USB 2.0 PD Standard-A receptacle and USB PD
Standard-A plug are included in this specification. For the USB 2.0 PD receptacle, Datum A was moved from the front
edge of the receptacle shell to the front of the tongue to be consistent with [USB 3.1] and to provide proper
dimensioning for PD Detect features. Similarly for the USB 2.0 PD Standard-A plug, Datum A was moved from the
front edge of the plug shell to the back of the tongue.
Figure 3-8 defines the mechanical requirements that govern the mating interoperability that shall be followed for the
USB 2.0 Standard-A plug. See Section 3.2.2 for additional USB PD Standard-A plug requirements.
Figure 3-9 defines the normative mechanical requirements the USB 2.0 PD Standard-A receptacle that govern the
mating interoperability and informative dimensions for solder tail locations, a sample Insertion Detect
implementation, and a sample PD Detect implementation. Dimensions associated with solder tails, the sample
Insertion Detect feature, and the sample PD Detect features are not normative. The solder pin locations are vendor-
specific and included in the drawings for reference only. See Section 3.2.1 and Section 3.2.2 for normative Insertion
Detect and PD Detect mechanical requirements, respectively.
The through-hole footprint in Figure 3-10 is shown as an example. Other footprints are allowed.
General considerations:
 There may be some increase in the USB 2.0 PD Standard-A receptacle connector depth (into a system board) as
compared to the USB 2.0 Standard-A receptacle to accommodate detection of the Standard-A plug’s longer shell.
 Drawings for stacked USB 2.0 PD Standard-A receptacles are not shown in this specification. They are allowed, as
long as they meet all the electrical requirements defined in [USB 2.0] and the mating interoperability mechanical

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 67

 and electrical requirements defined in this specification. When designing stacked USB 2.0 PD Standard-A
receptacles, PD Detect contacts shall be provided in all PD capable receptacles.

Page 68 USB Power Delivery Specification Revision 2.0, Version 1.1

 Figure 3-8 PD Standard-A Plug Interface Dimensions

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 69

 Figure 3-9 USB 2.0 PD Standard-A Receptacle Interface Dimensions

Page 70 USB Power Delivery Specification Revision 2.0, Version 1.1

 Figure 3-10 Reference Footprint for the USB 2.0 PD Standard-A Top Mount Single Receptacle (Informative)

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 71

 3.2.3.2 Pin Assignments and Description
The usage and assignments of the pins that shall be used in the USB 2.0 PD Standard-A connector are defined in Table
3-2.

Table 3-2 USB 2.0 PD Standard-A Connector Pin Assignments

Pin Number1 Signal Name Description Mating Sequence

1 VBUS Power Third
2 D- Differential pair as defined Fourth
3 D+ in [USB 2.0]
4 GND Ground for power return Third
102 PD DETECT 1 Contact in PD receptacle to Last
detect a PD plug
112 PD DETECT 2 Contact in PD receptacle to Last
detect a PD plug
123,13 INSERTION DETECT Receptacle only. Detects Second
insertion of a plug into the
receptacle. Optional except
for Cold Socket
applications.
Shell Shield Connector metal shell First
Note 1: Pin numbers not included in this table do not have contacts present. Pin numbering is
consistent with location across multiple USB connector types.
Note 2: Implementation of PD DETECT shall include:
a) either pin 10 or pin 11.
b) both pin 10 and pin 11.
Note 3: Pin 12, if present, shall be connected to Shield.

The physical location of the pins in the connector is illustrated in Figure 3-9.

3.2.4 USB 3.1 PD Standard-A Connector

3.2.4.1 Interface Definition
Figure 3-11, Figure 3-12, and Figure 3-13 show the USB 3.1 PD Standard-A plug, the USB 3.1 PD Standard-A receptacle
and a reference footprint for the USB 3.1 PD Standard-A receptacle, respectively.
Figure 3-11 defines the mechanical requirements of the USB 3.1 PD Standard-A plug that govern the mating
interoperability that are different than the dimensions in the [USB 2.0]and [USB 3.1] specifications, that shall be
followed, for the USB 3.1 Standard-A plug. See Section 3.2.1 for additional USB PD Standard-A plug requirements.
Figure 3-12 provides an informative example of a USB 3.1 PD Standard-A receptacle including dimensions for solder
tail locations, a sample Insertion Detect implementation, and a sample PD Detect implementation. The dimensions in
Figure 3-12 associated with solder tails, the sample Insertion Detect feature, and the sample PD Detect features are
not normative. The solder pin locations are vendor-specific and included in the drawings for reference only. The USB
3.1 PD Standard-A receptacle mating interface shall comply with the dimensions defined in the [USB 2.0] and [USB
3.1] specifications for the USB 3.1 Standard-A receptacle. See Section 3.2.1 and Section 3.2.2 for normative Insertion
Detect and PD Detect mechanical requirements, respectively.
The through-hole footprint in Figure 3-13 is shown as an example. Other footprints are allowed.
General considerations:
 Drawings for stacked USB 3.1 PD Standard-A receptacles are not shown in this specification. They are allowed, as
long as they meet all the electrical and mechanical requirements defined in [USB 2.0], [USB 3.1], and this
specification. When designing a stacked USB 3.1 PD Standard-A receptacle, PD Detect contacts shall be provided
in all PD capable receptacles.

Page 72 USB Power Delivery Specification Revision 2.0, Version 1.1

 Figure 3-11 USB 3.1 PD Standard-A Plug Interface Dimensions

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 73

 Figure 3-12 Reference USB 3.1 PD Standard-A Receptacle Interface Dimensions (Informative)

Page 74 USB Power Delivery Specification Revision 2.0, Version 1.1

 Figure 3-13 Reference Footprint for the USB 3.1 PD Standard-A Top Mount Single Receptacle (Informative)

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 75

 3.2.4.2 Pin Assignments and Description
The usage and assignments of the pins that shall be used in the USB 3.1 PD Standard-A connector are defined in Table
3-3.

Table 3-3 USB 3.1 PD Standard-A Connector Pin Assignments

Pin Number1 Signal Name2 Description Mating Sequence

1 VBUS Power Third
2 D- Differential pair as defined Fourth
3 D+ in [USB 2.0]
4 GND Ground for power return Third
5 StdA_SSRX- Enhanced SuperSpeed Fifth
6 StdA_SSRX+ receiver differential pair
7 GND_DRAIN Ground for signal return
8 StdA_SSTX- Enhanced SuperSpeed
9 StdA_SSTX+ transmitter differential pair
103 PD DETECT 1 Contact in PD receptacle to Last
detect a PD plug
113 PD DETECT 2 Contact in PD receptacle to Last
detect a PD plug
124, 13 INSERTION DETECT Receptacle only. Detects Second
insertion of a plug into the
receptacle. Optional except
for Cold Socket
applications.
Shell Shield Connector metal shell First
Note 1: Pin numbers not included in this table do not have contacts present. Pin numbering is
consistent with location across multiple USB connector types.
Note 2: Tx and Rx are defined from the host perspective.
Note 3: Implementation of PD DETECT shall include :
a) either pin 10 or pin 11.
b) both pin 10 and pin 11.
Note 4: Pin 12, if present, shall be connected to Shield.

The physical location of the pins in the connector is illustrated in Figure 3-12. Note: pins 1 to 4 are referred to as the
USB 2.0 pins, while pins 5 to 9 are referred to as the Enhanced SuperSpeed pins.

3.2.5 USB 2.0 PD Standard-B Connector

3.2.5.1 Interface Definition
Figure 3-15, Figure 3-14, and Figure 3-16 show the USB 2.0 PD Standard-B plug, the USB 2.0 PD Standard-B
receptacle, and a reference footprint for the USB 2.0 PD Standard-B receptacle, respectively. Solder pin locations on
the USB 2.0 PD Standard-B receptacle are vendor-specific and are included in the drawings for reference only. The
views in the plug and receptacle figures correspond to those shown in the [USB 2.0] base specification and non-
reference dimensions define the ID pin for PD applications. The USB 2.0 PD Standard-B plug and receptacle shall
comply with the mechanical requirements specified in the [USB 2.0] base specification and the ID pin as specified in
Figure 3-15 and Figure 3-14.

Page 76 USB Power Delivery Specification Revision 2.0, Version 1.1

 Figure 3-14 USB 2.0 PD Standard-B Plug Interface Dimensions

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 77

 Figure 3-15 USB 2.0 PD Standard-B Receptacle Interface Dimensions

Page 78 USB Power Delivery Specification Revision 2.0, Version 1.1

 Figure 3-16 Reference Footprint for the USB 2.0 PD Standard-B Receptacle

3.2.5.2 Pin Assignments and Descriptions

The usage and assignments of the pins that shall be used in the USB 2.0 PD Standard-B connector are defined in
Table 3-4.

Table 3-4 USB 2.0 PD Standard-B Connector Pin Assignments

Pin Number1 Signal Name Description Mating Sequence

1 VBUS Power Second
2 D- Differential pair as defined in Third or beyond
3 D+ [USB 2.0]
4 GND Ground for power return Second
112 ID Identification of PD Third or beyond
capability
Shell Shield Connector metal shell First
Note 1: Pin numbers not included in this table do not have contacts present. Pin numbering is
consistent with location across multiple USB connector types.
Note 2: ID pin as defined in core USB specifications and extended by the USB Power Delivery
specifications. See Section 3.4.3. Historically Pin 11 was defined by the USB 3.0 specification as
the Ground Return for DPWR (power supplied by the device) for the Powered-B connector
(deprecated by [USB 3.1]).

The physical locations of the pins in the connector are illustrated in Figure 3-15 and Figure 3-14.

3.2.6 USB 3.1 PD Standard-B Connector

3.2.6.1 Interface Definition
Figure 3-17 , Figure 3-18, and Figure 3-19 show the USB 3.1 PD Standard-B plug, the USB 3.1 PD Standard- B
receptacle, and a reference footprint for the USB 3.1 PD Standard- B receptacle, respectively. Solder pin locations on

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 79

 the USB 3.1 PD Standard-B receptacle are vendor-specific and included in the drawings for reference only. The
views in the plug and receptacle figures correspond to those shown in the [USB 3.1] base specification and non-
reference dimensions define the ID pin for PD applications. The USB 3.1 PD Standard-B plug and receptacle shall
comply with all other mechanical requirements specified in the [USB 3.1] base specification and the ID pin as
specified in Figure 3-17 and Figure 3-18.

Figure 3-17 USB 3.1 PD Standard-B Plug Interface Dimensions

Page 80 USB Power Delivery Specification Revision 2.0, Version 1.1

 Figure 3-18 USB 3.1 PD Standard-B Receptacle Interface Dimensions

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 81

 Figure 3-19 Reference Footprint for the USB 3.1 PD Standard-B Receptacle

Page 82 USB Power Delivery Specification Revision 2.0, Version 1.1

 3.2.6.2 Pin Assignments and Descriptions
The usage and assignments of the pins that shall be used in the USB 3.1 PD Standard-B connector are defined in
Table 3-5.

Table 3-5 USB 3.1 PD Standard-B Connector Pin Assignments

Pin Number1 Signal Name2 Description Mating Sequence

1 VBUS Power Second
2 D- Differential pair as defined in Third or beyond
3 D+ [USB 2.0]
4 GND Ground for power return Second
5 StdB_SSTX- Enhanced SuperSpeed Third or beyond
6 StdB_SSTX+ transmitter differential pair
7 GND_DRAIN Ground for signal return
8 StdB_SSRX- Enhanced SuperSpeed
9 StdB_SSRX+ receiver differential pair
113 ID Identification of PD
capability
Shell Shield Connector metal shell First
Note 1: Pin numbers not included in this table do not have contacts present. Pin numbering is
consistent with location across multiple USB connector types.
Note 2: Tx and Rx are defined from the device perspective.
Note 3: ID pin as defined in core USB specifications and extended by the USB Power Delivery
specifications. See Section 3.4.3. Pin 11 was defined by [USB 3.1] as the Ground Return for
DPWR (power supplied by the device) for the USB 3.1 Powered-B connector.

The physical locations of the pins in the connector are illustrated in Figure 3-16 and Figure 3-17.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 83

 3.3 Cable Assemblies
USB Power Delivery introduces the concept of an electronically marked cable assembly. The particular marking
denotes the cable assembly’s characteristics and is electronically detected. This provides devices on each end of the
cable assembly a means to detect and identify the cable assembly capabilities. The ID pin definition is extended to
electronically mark cable assemblies. An ID pin has been added to the Standard-B Connectors to create PD Standard-
B Connectors as defined in Section 3.2.5 and Section 3.2.6. The B-Device shall detect the cable assembly and make
requests that are consistent with the cable assembly’s capabilities. Similarly, the Standard-A Connector shell has been
modified to create a PD Standard-A Connector to allow detection of cable insertion and to identify if the cable
assembly is PD-capable. The combination of these PD cable assembly markings provide a robust system to safely
deliver high power across the USB cable assembly.
The portion of this specification that allows the negotiation of voltages other than the default vSafe5V and currents in
excess of 1.5A shall apply only to Devices with marked PD cable assemblies.

3.3.1 Non-marked Cable Assemblies

Limitations are placed on the use of legacy cable assemblies (i.e., ones not marked). Legacy cable assemblies include
all cable assemblies with USB 2.0 or USB 3.1 Standard-A Connectors, USB 2.0 or USB 3.1 Standard-B Connectors, USB
3.1 Powered-B Connectors, and USB 2.0 or USB 3.1 Micro-B Connectors. Devices shall only use these non-marked
legacy cable assemblies at vSafe5V and up to 1.5A as described by [USB 2.0], [USB 3.1] and [BC 1.2].

3.3.2 Marked Cable Assemblies

Marking allows Port Partners to detect the insertion of a USB Power Delivery cable assembly and its electrical
characteristics. Port Partners shall not negotiate for currents in excess of the electrical characteristics indicated by
the cable’s marking.

3.3.3 PD Cable Assembly Overmold Requirements

It is strongly recommended that the PD cable assembly overmold dimensions conform to the requirements defined by
[USB 2.0] and [USB 3.1]. Depending on the PD cable assembly current rating and length, the wire gauge to meet the IR
drop defined in 3.6.9 may require a cable diameter that results in a larger overmold at the cable/connector interface.
Table 3-6 and Figure 3-20 define the maximum allowed overmold dimensions for the PD cable assembly. PD cable
assemblies using these larger limits may result in mechanical interferences (e.g., may block use of a connector slot in
stacked connector configurations) therefore, the overmold dimensions should conform to requirements defined by
[USB 2.0] and [USB 3.1] if possible.

Table 3-6 USB PD Cable Assembly Overmold Maximum Dimensions

Dimension Connector Type 3A 5A

Z max PD Standard-A 5.00 10.00
Z max PD Micro 9.00 -
Y max PD Standard-B - 14.00
Z max PD Standard-B - 8.60

Page 84 USB Power Delivery Specification Revision 2.0, Version 1.1

 Figure 3-20 USB PD Cable Assembly Overmold Maximum Dimensions

Standard-A

Micro

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 85

 3.4 PD Cable Assembly Marking
Paragraphs in this section described the markings for the plug connectors at each end of the PD cable assembly.
References to cable assembly in this section apply to cable assemblies which include a PD plug connector. Component
values are found in Table 3-7.

3.4.1 Marker for PD Standard-A Connectors

The PD Standard-A Connector shell is 1.3 mm longer than the shell of the legacy Standard-A Connector. The PD
Standard-A Connector shell shall be detected by the DFP connector using a PD Standard-A receptacle connector and
associated marking detection circuitry to indicate that the cable assembly is a PD cable assembly. Marking detection
circuitry is vendor specific.

3.4.2 Electronic Markers for Micro-A Plugs

In the standard cable assembly with a Micro-A plug, the ID-pin is grounded. The data and shield connections shall be
made per the [USB 2.0] and the [USB 3.1] specifications.

3.4.2.1 Legacy Micro-A Plug

Figure 3-21 Schematic of a Micro-A Plug Legacy Termination

VBUS

ID

< Ra_PLUG_ID

Ground

Figure 3-21 shows the schematic diagram of the Micro-A plug termination in a legacy cable assembly. Note the ID pin
is connected to ground through an impedance of Ra_PLUG_ID (as defined in the Micro-USB Cables and Connectors
specification v1.01 in [USB 2.0]) to indicate that the plug is an A plug. For PD to remain backward compatible, the low

Page 86 USB Power Delivery Specification Revision 2.0, Version 1.1

impedance to ground shall be maintained. However, any value less than rID is assumed to be interpreted by a legacy
Port as a Micro-A plug.
PD uses two new markers to allow the detection of a Low Power cable assembly and PD cable assembly in addition to
the detection of a legacy cable.

3.4.2.2 Low Power Micro-A Plug

Devices with a hardwired captive cable with a Micro-A plug connector supporting a one cell Lithium battery as their
power source or where very low power consumption is important may terminate the Micro-A Plug’s ID pin to ground
with rID and to VBUS with cPlug. This termination may be detected electrically. See 4.4.4 for additional information
regarding Low Power Device characteristics.

Figure 3-22 Schematic of a Micro-A Plug Marker Indicating Low Power Capability

VBUS

cPlug
ID

rID

Ground

3.4.2.3 PD Micro-A Plug

PD cable assemblies with Micro-A plug connectors shall be marked with rID terminating the ID pin to ground. See
Figure 3-23 for a schematic diagram of the connector termination in a PD cable assembly using a Micro-A plug.

Figure 3-23 Schematic of a Micro-A PD Plug

VBUS

ID

rID

Ground

3.4.3 Electronic Markers for PD Standard-B Plugs and Micro-B Plugs

Electronic markers for PD cable assemblies with PD Standard-B plug connectors and Micro-B plug connectors are
specified in this section. A legacy Micro-B connector’s ID pin exhibits a very high resistance to ground. To maintain
backward compatibility, capacitors are used as markers.
Note the 3A and 5A markers are mutually exclusive; hence both markers shall not be present at the same time.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 87

 3.4.3.1 3A Capable PD B Plug
The schematic diagram for a 3A-capable PD cable assembly detailing how a PD Standard-B plug connector or a Micro-
B plug connector shall be marked is shown in Figure 3-24.

Figure 3-24 Schematic of a B Plug Connector Marker Indicating 3A Capability

VBUS

ID

cPlug

Ground

3.4.3.2 5A Capable PD B Plug

The schematic diagram for a 5A-capable PD cable assembly detailing how a PD Standard-B plug connector shall be
marked is shown in Figure 3-25.

Figure 3-25 Schematic of a B Plug Connector Marker Indicating 5A Capability

VBUS

cPlug
ID

Ground

3.5 USB PD Icon

The USB PD cable assemblies shall display the USB icon appropriate for PD. A dimensioned drawing and allowable
usage of the icon are supplied with the license from the USB-IF.

Page 88 USB Power Delivery Specification Revision 2.0, Version 1.1

 3.6 USB Power Delivery Cable Requirements
The methods used to mark the USB PD cable assemblies and USB PD cable adaptors are found in Section 3.4. The USB
PD connector family shall conform to all requirements in Section 3, in addition to the requirements specified in the
[USB 2.0], [USB 3.1] or [BC 1.2] specifications. Test sequences shall conform to EIA-364-1000.001 as specified in the
Environmental Requirements section of [USB 3.1].
Some USB PD cable assemblies may be designed for use as power only (i.e., no USB data communication).
Requirements that relate to the transfer of USB data may not apply to these cables.

3.6.1 Low Level Contact Resistance (EIA 364-23B)

The power contacts of a 3A PD cable assembly shall conform to the following requirements:
 20mΩ (Max) initial for VBUS and GND contacts.
 Maximum change (delta) of +10mΩ after environmental stresses.
 Measure at 20mV (Max) open circuit at 100mA.
The power contacts of a 5A PD cable assembly shall conform to the following requirements:
 20mΩ (Max) initial for VBUS and GND contacts.
 Maximum change (delta) of +10mΩ after environmental stresses.
 Measure at 20mV (Max) open circuit at 100mA.
The following requirements shall apply, independent of power being applied, to the resistance of a PD Standard-A
plug receptacle shell to the PD Standard-A receptacle PD DETECT contact with a PD Standard-A plug in the mated
condition or to the resistance between the INSERTION DETECT contacts when a Standard-A plug is present in the
Standard-A receptacle supporting Insertion Detect. For PD Detect, there are two contact interfaces to the plug shell
included in series in this measurement:
 200mΩ (Max) initial.
 Maximum change (delta) of 300mΩ after environmental stresses.
 Measure at 20mV (Max) open circuit at 100mA.

3.6.2 Open Circuit Resistance

The following requirements shall apply, independent of power being applied, to the resistance of the PD Standard-A
receptacle shell to the PD Standard-A receptacle PD DETECT contact(s) when no PD Standard-A plug is inserted in the
mated condition or a non-PD Standard–A plug is inserted in the mated condition or to the resistance between the
INSERTION DETECT contacts of a Standard-A receptacle supporting Insertion Detect when a Standard-A plug is not
inserted:
 ≥ 10MΩ initial.
 ≥ 10MΩ after environmental stress.

3.6.3 Dielectric Strength (EIA 364-20)

No breakdown shall occur when 100VAC (RMS) is applied between adjacent contacts of unmated and mated
connectors.

3.6.4 Insulation Resistance (EIA 364-21)

There shall be a minimum of 100MΩ insulation resistance between adjacent contacts of unmated and mated
connectors.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 89

 3.6.5 Contact Current Rating
3.6.5.1 3A PD Connector Mated Pair (EIA 364-70, Method 2)
When a current of 3.0 A is applied to the VBUS pin and its corresponding GND pin (i.e., pin 1 and pin 5 of the PD Micro-A
Connector, PD Micro-AB Connector, or PD Micro-B Connector), the delta temperature shall not exceed +30°C at any
point on the connectors under test, when measured at an ambient temperature of 25°C.

3.6.5.2 5A PD Connector Mated Pair (EIA 364-70, Method 2)

When a current of 5.0A is applied to the VBUS pin and its corresponding GND pin (i.e., pin 1 and pin 4 of the PD
Standard-B Connector or PD Standard-A Connector), the delta temperature shall not exceed +30°C at any point on the
connectors under test, when measured at an ambient temperature of 25°C.

3.6.6 Differential Crosstalk between VBUS and the D+/D- Pair (EIA-360-90)
The differential, near-end, and far-end, crosstalk between the D+/D- pair and VBUS shall be managed not to exceed the
limit shown in Figure 3-26.

Figure 3-26 Differential Near-End and Far-End Crosstalk Requirement between the D+/D- Pair and VBUS

-25

-27
X: 100
Y: -30
-29
Differential Crosstalk, dB

-31

-33

-35

-37 X: 15 X: 30
Y: -40 Y: -40
-39

-41

-43

-45
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100

Freq, MHz

3.6.7 PD Cable Assembly Shielding Connectivity

The shield conductor shall be attached to the connector shell at both ends of the cable and shall provide a resistance of
no greater than 1.0Ω from end to end. The shield shall not be connected to ground within the cable.

Page 90 USB Power Delivery Specification Revision 2.0, Version 1.1

 3.6.8 PD Cable VBUS Impedance
The cable impedance shall meet the requirements specified in Table 5-18.

3.6.9 PD Cable Insertion Loss

The insertion loss of the cable shall not exceed aInsertionLoss.

3.6.10 PD Cable IR Drop Considerations

The maximum voltage drop between the Source and Sink ports is defined to:
 Insure signal integrity of the USB 2.0 signal wires.
 Quantify the worst case voltage seen at the input of a Sink.

Figure 3-27 Voltage Drop Measurement

Source Sink

Rcontact Rcable(VBUS) Rcontact

+5V

Source
VVBUS_DROP
Sink

Rcontact Rcable(Gnd) Rcontact

Gnd

VGND_DROP
As shown in Figure 3-27, voltage drop across the cable is measured independently on both the GND and the VBUS
connections. It is inclusive of the cable and connectors at both ends.

3.6.10.1 Voltage Drop on the Ground

A PD cable assembly shall ensure VGND_DROP does not exceed the maximum value listed in Table 3-7 for the signal
ground reference between the Source’s power source connection to the USB receptacle and the Sink’s connection to
its internal power conversion block, if present. VGND_DROP shall be measured at iCable and measured either:
 At the receptacle’s solder pad where it attaches to the printed circuit board
 Or where the captive cable is attached to the printed circuit board in the device.
VGND_DROP shall include the effects of the following:
1) The mated contact resistance of both the A-side and the B-side (if present) connections for GND.
2) The series resistance of the cable’s GND wire.
3) The rated current of the cable (iCable).
VGND_DROP for removable cables equals (2 * Rcontact + Rcable(GND)) * iCable. VGND_DROPfor captive cables equals (1 *
Rcontact + Rcable(GND)) * iCable.
The only variable in the above equations is Rcable(GND). The wire size and its length are the major contributors to
VGND_DROP. The ground wire size shall be selected so that VGND_DROPat a current of iCable does not exceed the maximum
value listed in Table 3-7.

3.6.10.2 Overall IR Drop between a Source and a Sink

A PD cable assembly shall provide a maximum voltage drop of vIRDrop_Cable for VBUS to GND at the Sink end of the
cable. The VBUS to GND voltage drop shall include VVBUS_DROP plus VGND_DROP.
VVBUS_DROP shall be measured at a current of iCable and measured either:
 At the receptacle’s solder pad where it attaches to the printed circuit board

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 91

 Or where the captive cable is attached to the printed circuit board in the device.
VVBUS_DROP shall include the effects of the following
 The mated contact resistance of both the A-side and B-side (if present) connections for VBUS.
 The series resistance of cable’s VBUS wire.
 The rated current of the cable (iCable).
VVBUS_DROP for removable cables equals (2 * Rcontact + Rcable (VBUS)) * iCable. VVBUS_DROP for captive cables equals (1 *
Rcontact + Rcable (VBUS)) * iCable.
The only variable in the above equations is Rcable (VBUS). The wire size and its length are the major contributors to
VVBUS_DROP. The VBUS wire size shall be selected so that VVBUS_DROP at a current of iCable does not exceed the maximum
value listed in Table 3-7.

3.6.10.3 Example Calculation of Overall IR Drop

The goal of this example is to design a compliant PD Cable with a Standard A and a Micro B plug (e.g. iCable = 3A) that
is 1m in length.
The allowable Rcable (GND) to achieve this is found by:
1) R=E/I or E = IR -> Rcable (GND) = the maximum value for VGND_DROP listed in Table 3-7/iCable -> 0.375/3 =
125mΩ.
2) Mated contact resistance is defined as 30mΩ (Max) times 2 mated pair connections or 60mΩ.
3) Rcable (GND) = 125mΩ – 60mΩ = 65mΩ (the budget for the ground wire in the cable).
The allowable Rcable (VBUS) to achieve this can be found by:
1) R=E/I or R = IR -> Rcable (VBUS) = the maximum value for VVBUS_DROP listed in Table 3-7/iCable -> 0.625/3 =
208mΩ.
2) Mated contact resistance is defined as 30mΩ (Max) times 2 mated pair connections or 60mΩ.
3) Rcable (VBUS) = 208mΩ – 60mΩ = 148mΩ (the budget for the VBUS wire in the cable).
In this example, a 22AWG @ 52.94mΩ /m used for Ground and a 26AWG @ 134mΩ /m used for VBUS meets the
vIRDrop_Cable requirements for a 1m cable.

Page 92 USB Power Delivery Specification Revision 2.0, Version 1.1

 3.7 Electrical Parameters
Table 3-7 shows the parameters used in this Section.

Table 3-7 Electrical Parameters

Parameter Minimum Nominal Maximum Units Description

aInsertionLoss 1.5 dB As measured within fRange.

cPlug 5 10 15 nF Across temperature -20oC to +80 oC at

vSafe5V for the minimum and at
vSafe0V for the maximum. Minimum
voltage rating of 50V.
See Figure 3-22, Figure 3-24, and
Figure 3-25.
iCable 5 A If only Standard connectors are used.
3 A If a Micro connector is present at any
point.
rID 900 1000 1100 Ω See Figure 3-22 and Figure 3-23.

vIRDrop_Cable 1 V Sum of VVBUS_DROP and VGND_DROP.

VGND_DROP1 375 mV Note: this value is the same as
VGND_OFFSET as defined in [BC 1.2].
VVBUS_DROP1 625 mV

Note 1: For charging-only cables (e.g. cables without data lines), the maximum value of either VVBUS_DROP or
VGND_DROP may be exceeded; however VVBUS_DROP plus VGND_DROP shall not exceed vIRDrop_Cable.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 93

4. Electrical Requirements
This chapter covers the platform’s electrical requirements for implementing USB Power Delivery.
USB Power Delivery may be implemented alongside the [USB 2.0], [USB 3.1], [BC 1.2] and [USBType-C 1.0]
specifications. In the case where a Device requests power via the Battery Charging Specification and then the USB
Power Delivery Specification, it shall follow the USB Power Delivery Specification until the Port Pair is unattached or
there is a Hard Reset. If the USB Power Delivery connection is lost, the Port shall return to its default state, see Section
6.7.2.

4.1 Dead Battery Detection / Unpowered Port Detection

The Power Delivery specification provides a mechanism for a USB Device to provide power to a USB Host under the
circumstances where the USB Host:
 Has a Dead Battery that requires charging or
 Has lost its power source or
 Does not have a power source or
 Does not want to provide power.
The USB Peripheral primarily acts as a USB Device that may also provide power to the USB Host if the correct
detection is carried out.
The following sections detail mechanisms used for:
 Type-A to Type-B connections:
o The USB Device is a Consumer/Provider acting as a Source
o The USB Host is a Provider/Consumer acting as a Sink.
For mapping of VBUS level to USB states during Dead Battery detection see Figure 9-3.

4.1.1 Type-A to Type-B Dead Battery Operation

4.1.1.1 Overview
A Consumer/Provider shall back power the Provider/Consumer at a reduced current level. This enables the
Provider/Consumer’s PD transmitter on its DFP to send a continuous stream of alternating ‘0s’ and ‘1s’ (referred to in
this section as a Bit Stream) that the Consumer/Provider’s UFP’s PD receiver can readily detect. The use of a current
limited Source (vSafeDB) to back power VBUS is intended to minimize the risk of damage to legacy USB DFPs. At the
start of the process when the Consumer/Provider sees no voltage on VBUS, it probes the bus by back powering VBUS to
see if its Port Partner has a Dead Battery or unpowered Port that it wants powered. If so, the Consumer/Provider
outputs vSafe5V on VBUS and becomes the de facto power Provider.
When the process is complete, both ports will have performed an Implicit Power Role Swap without the use of the
PR_Swap Message (see Section 8.3.2.7.1.2) where the Consumer/Provider is now operating as the Source while the
Provider/Consumer operates as a Sink. With communications and cable capabilities established, the
Provider/Consumer may negotiate for a voltage/current combination to charge its battery or to operate.

4.1.1.2 Consumer/Provider Operational Details

In operation (see Figure 4-1), a Consumer/Provider Port that does not detect vSafe5V on VBUS shall periodically apply
a current limited five volt supply (vSafeDB) to VBUS in an attempt to ascertain the presence of a Provider/Consumer
Port that wants to be powered. In response to vSafeDB on VBUS, a Provider/Consumer Port that wants power shall
transmit the Bit Stream that a Consumer/Provider can detect indicating the presence of a Port that wants to be
powered. When the Consumer/Provider detects a Provider/Consumer Port wanting to be powered, it shall apply
vSafe5V to VBUS. In all other cases, for example when connected to a legacy Port or an unpowered Provider Port, there
will be no response and the Consumer/Provider Port shall not apply full power (vSafe5V) to VBUS. The

Page 94 USB Power Delivery Specification Revision 2.0, Version 1.1

Consumer/Provider shall continue to periodically probe for the presence of a Provider/Consumer Port that wants
power. The limitations on the current and power applied to back power V BUS and its controlled duration shall be
applied in order to prevent damage to legacy ports.
The Consumer/Provider may use other means to detect the presence of a Port Partner before applying the method
described above.

4.1.1.3 Provider/Consumer Operational Details

In operation (see Figure 4-1), the Provider/Consumer with a Dead Battery shall begin (as it must if its battery is truly
dead) by outputting nothing on VBUS. When power is applied to VBUS (i.e. back powered), VBUS is used by the
Provider/Consumer to power its transmitter and to output the Bit Stream within the limited power offered by
vSafeDB.
The Provider/Consumer shall begin outputting the Bit Stream on VBUS within tSendBitStream. This is necessary
because the application of full VBUS power is dependent on the time it takes the Consumer/Provider to detect the
presence of activity on VBUS and to adjust its power supply.
The Provider/Consumer may have additional circuitry that requires more power than is available from V BUS when
powered by vSafeDB. The Provider/Consumer Port can assume that full vSafe5V power is available tWaitForPower
after it started sending the Bit Stream. After tWaitForPower, vSafe5V will be available to the Provider/Consumer to
bring up any remaining logic required to process PD Messages on VBUS. When this logic is ready, the
Provider/Consumer Port shall signal its Port Partner that is ready to operate as Consumer by stopping the Bit Stream.

4.1.1.4 Sequence of operation

Figure 4-1 illustrates the flow for Dead Battery/Unpowered Port detection for both Provider/Consumer ports and
Consumer/Provider ports. To ensure consistent behavior all Consumer/Provider ports shall have the ability to detect
a Provider/Consumer with a Dead Battery or Unpowered Port.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 95

 Figure 4-1 Type-A to Type-B Dead Battery / Unpowered Port Detection Flow
Provider/Consumer Start Consumer/Provider Start

VBUS becomes vSafe0V

DBSourceOffTimer timeout
Ensure Bit Stream off
P/C not powering VBUS Start DBDetectTimer
within tBitStreamOff of
(e.g. Dead Battery)
vSafe0V on VBUS
Apply vSafe0V to VBUS
Start DBSourceOffTimer

Willing to power port? Yes Operate as a Source

VBUS > vSafe0V? Yes Operate as a Sink
No

No No

No Wants to be powered?
DBDetectTimer
expired?
Yes

Yes
No vSafeDB present? Output vSafeDB on VBUS
Start BitStreamDetectTimer

Yes

Output Bit Stream

within tSendBitStream of Yes BitStreamDetectTimer
vSafeDB detection expired?
Start WaitForPowerTimer
No
No
WaitForPowerTimer timeout
Bit Stream
detected?

No Yes
PD System Ready
for Capabilities?
Start
DeviceReadyTimer

Yes

Stop Outputting DeviceReadyTimer

Yes
Bit Stream expired?

No No

No
Bit Stream
Capabilities Message stopped?
Received

Yes

Yes
Operate as a Source

Determine Cable Type

Operate as a Sink

Table 4-1 describes the Message sequence shown in Figure 4-1.

Page 96 USB Power Delivery Specification Revision 2.0, Version 1.1

 Table 4-1 Normal Dead Battery Operation

Step Provider/Consumer Consumer/Provider

1 The Consumer/Provider shall start DBDetectTimer, used
The Provider/Consumer shall not drive VBUS; to determine when next to apply vSafeDB.
allowing it to remain at vSafe0V.
2 Until the DBDetectTimer expires, the Consumer/Provider
While vSafeDB is not present, the shall check whether VBUS is above vSafe0V. If it is, it shall
Provider/Consumer shall: start to operate as a Sink, and leave the Dead Battery
 If willing to act as a Source, go and do this. Operation procedure.
(The first action will be to output vSafe5V).
 If it does not wish to be powered, remain in
this step.
3 When the DBDetectTimer expires, the Consumer/Provider
shall start to output vSafeDB, in order to power the
Provider/Consumer Bit Stream generation circuitry. The
process of preparing this may take up to tTurnOnSafeDB.
The Consumer/Provider shall then start the
BitStreamDetectTimer, which determines how long to wait
for the Bit Stream. The Bit Stream detector shall see at least
128 alternating '0' and '1' bits before deciding that the Bit
Stream is present.
4 If the BitStreamDetectTimer expires before the Bit Stream
is detected, the Consumer/Provider shall perform the
following procedure.
Apply vSafe0V Procedure
The Consumer/Provider shall attempt to discharge the
maximum permitted capacitance (this can theoretically be as
much as cSrcBulk max or cSrcBulkShared max) on VBUS at a
rate which will reduce its voltage to vSafe0V within
tDBDischargeVbus max bearing in mind that VBUS may be
being driven with vSafe5V and not capable of being
discharged. After tDBDischargeVbus max the
Consumer/Provider shall stop attempting to discharge VBUS.
After a time of tDBSourceOff from starting to discharge VBUS,
then the Consumer/Provider shall go back to step 1.
5 If the Provider/Consumer wishes to be powered,
and vSafeDB is present, it shall start to output Bit
Stream within tSendBitStream of vSafeDB being
available, and start the WaitForPowerTimer.
When budgeting for tSendBitStream the
Provider/Consumer shall allow for:
 The time required for vSafeDB to charge
the capacitance presented by itself to a
level at which it can begin operation.
 The time required for enough of its own
circuitry to power up to transmit a Bit
Stream.
 The fact that tTurnOnImpliedSink is
included in this budget
Note that the effect of VBUS capacitance on these
timings is significant. The designer should verify
their own design in this respect.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 97

Step Provider/Consumer Consumer/Provider
6 If the Bit Stream is detected, the Consumer/Provider shall
output vSafe5V to VBUS and start the DeviceReadyTimer.
This timer is used to ensure that the Provider/Consumer is
ready to operate as a Sink within a reasonable time.
7 When the WaitForPowerTimer expires, the If the DeviceReadyTimer expires, the Consumer/Provider
Provider/Consumer assumes that vSafe5V is shall perform the Apply vSafe0V Procedure defined in step 4
present on VBUS. It shall then bring up the full PD above, ending by going to step 1.
system and when ready to receive and process
Source_Capabilities Messages, stop sending the
Bit Stream.
8 When the Source_Capabilities Message is If the Bit Stream is detected to have stopped, the
received, the Provider/Consumer shall determine Consumer/Provider shall go and start operating as a Source.
the connected cable type, and start operation as a The first action will be to send the Source_Capabilities
Sink. Message.
Note: If at any time the Provider/Consumer sees vSafe0V on VBUS, it shall ensure that it is not sending Bit Stream within
tBitStreamOff, and go to step 1.

4.1.2 Type-C to Type-C Dead Battery Operation

Dead Battery charging operation for connections between Type-C connectors is defined in [USBType-C 1.0].

4.2 Cable IR Ground Drop (IR Drop)

Every PD Sink Port capable of USB communications may be susceptible to unreliable USB communication if the
voltage drop across ground falls outside of the acceptable common mode range for the USB Hi-Speed transceivers
data lines (VGND_DROP) due to excessive current draw. Certified USB cabling is specified such that such errors should
not occur (See Section 3.6.10).

4.3 A-Plug Insertion Detect

The USB Power Delivery specification defines an Insertion Detect mechanism for the Standard-A plug. It consists of a
contact that connects with the shield when a Standard-A plug or a PD Standard-A plug is inserted into the receptacle.
The shield is essentially connected to ground through at most rID max.
The Micro-A plug’s ID pin is used for Insertion Detect. It is essentially connected to ground through at most a 1KΩ
resistance. This is the default defined in the Micro-A connector specification for [USB 2.0] and [USB 3.1]. See Section
3.4.2 for more details.
The Insertion Detect feature:
 When a plug is present for Cold Socket applications shall be used to indicate when to apply power to VBUS
 Should be used to indicate to the PD logic to start sending Source_Capabilities Messages when a plug is present.
 Should be used to indicate to the PD logic to put VBUS back to USB Default Operation when the plug is removed.
The Insertion Detect feature for Standard-A receptacles shall be present for Cold Socket but is optional for all other
Standard-A applications.

4.4 Cable Type Detection

4.4.1 Detecting Cabling Capabilities
Non-compliant cables, such as ‘Y’ and ‘W’ cables create the potential to damage hardware were the PD system to allow
more than vSafe5V to be placed on VBUS. To prevent this, all PD A-plug to B-plug assemblies are made in a way that
can be electronically detected. Only A-plug to B-plug assemblies that are marked for PD shall be used for voltages
higher than vSafe5V or current levels higher than 1.5A. Standard Type-C cable assemblies are rated for PD voltages
higher than vSafe5V and current levels of at least 3A.

Page 98 USB Power Delivery Specification Revision 2.0, Version 1.1

Cable type detection is a multi-step process that both the Source and Sink perform. This section provides flow of the
cable type detection based on the electronic markings defined in Section 3.4. The Source shall limit maximum
capabilities it offers so as not to exceed the capabilities of the type of plug detected. Requests made by the Sink shall
not exceed the capabilities of the type of plug.
The cable detection process is usually run when the Source is powered up, after a Power Role Swap or when power is
applied to a Sink. The exact method used to detect these events is up to the manufacturer and shall meet the following
requirements:
 Sources shall run the cable detection process prior to the Source sending Source_Capabilities Messages offering
voltages in excess of vSafe5V or currents in excess of:
o 1.5A for Type-A/Type-B
o 3A for Type-C.
 Sinks with Type-A and Type-B connectors shall run the cable detection process prior to sending any Request
Messages.
 Sinks with Type-C connectors shall select Capabilities from the offered Source Capabilities assuming that the
Source has already determined the Capabilities of the cable.
 Provider/Consumers with dead batteries shall wait until after receipt of the first Source_Capabilities Message
before running the cable detection process and making a request for power.
Sources shall detect the type of attached cable and either limit the Capabilities they offer or operate in a Low Power
mode based on:
 The receptacle type (i.e. Standard, Micro or Type-C) and its known current carrying capability.
 The current carrying capability of the plug determined by:
o The plug type (i.e. Type-C, PD, non-PD or Low Power).
o Cable capabilities determined using Structured VDM Messages (see Section 6.4.4.2) sent using SOP’
Communication (see Section 2.4).
Sinks, except those with Type-C receptacles, shall detect the type of attached cable and limit their requests based on:
 The receptacle type (i.e. Standard, or Micro) and its known current carrying capability.
 The current carrying capability of the plug determined by:
o The plug type (i.e. PD or non-PD).

4.4.2 Plug Type Determination

Figure 4-2 shows the flow for the first portion of the multi-step process that shall be used to determine the kind of
cable. It begins by determining the kind of plug inserted into the receptacle. Specifically the plug type: Standard-A,
Standard-B, Micro-A, Micro-B or Type-C, is determined. Detection of Type-C plugs is defined in [USBType-C 1.0].

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 99

 Figure 4-2 Plug Type Determination

Start

Micro-B Receptacle Type-C

Std-A
Micro-AB
Std B

ID-pin to GND
< rID max
Yes
No

Micro-A plug Standard-B Standard-A

Micro-B plug Type-C Plug
plug Plug

4.4.3 Detecting the PD Capabilities of the Standard-A Connector

The PD version of the Standard-A receptacle has one or two additional contacts that are used to:
 Optional detect if Standard-A plug is inserted in or removed from the receptacle.
 Required detect if the Standard-A plug is PD Capable or not.
The following description assumes that the two switches in the Standard-A receptacle are detected by having pull-up
resistors to a positive voltage and looking at the voltage, so a high voltage indicates no connection in the switch and a
low voltage indicates a connection in the switch. Other detection circuits may be used.

Page 100 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 4-3 Standard-A Plug PD Capabilities Flow

Standard-A
Plug

Put "+" on the

pullups

Insertion
Contact
Closed Open

PD Contact

Closed Open

PD Plug Standard Plug No Plug

Figure 4-3 illustrates how the detection contacts in the A receptacle shall be used. Insertion Detect is an optional
feature (see Section 3.1.5). When not present, the path through the Figure 4-3 follows the Insertion Detect ‘Closed’
arc.

4.4.4 Plug Type Detection except Standard-A

Figure 4-4 Plug Type Detection Circuit

100kΩ
62Ω VBUS
TX
Q1 1kΩ C2
Q2 Q3
ID
RX
(~10K input)
Q4 C1

33Ω
Ground

The example circuit shown in Figure 4-4 is used to detect the electronic markings on the ID pin indicating the type of
Micro connector.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 101
The TX is used to put a carrier signal on the VBUS line and the RX is used to detect whether a signal is present or not
(typically the Squelch is used for this purpose). Q1 - Q4 are used to create a series of circuits where the voltage output
(as measured by the RX) in each step is used to determine the configuration of the plug in accordance with to Table
4-2.
It is important that B-Plug type detection takes place when the line is idle and connected at the remote end. The ideal
measurement opportunity is after sending the GoodCRC Message in response to the Source_Capabilities Message and
before sending the Request Message as the line can be expected to be connected and idle because the sink will be the
next to transmit.
Note: If the far-end is not terminated or not terminated correctly (see Section 5.8.2.5) then the cable-type detection
described below may give erroneous results if signal levels at the cable input are reduced excessively by the
reflections of the cable.
In normal operation Q1 is conducting (turned ON) and Q2, Q3 and Q4 are not conducting (turned OFF).
In order to check the plug type using the circuit in Figure 4-4, a series of steps are performed; the result of each step is
recorded as a "0" or "1". The steps are:
1) Q1, Q3 and Q4 not conducting (turned OFF)
2) Q2 conducting (turned ON)
3) Check Squelch -> open - "1", else "0" -> bit 1
4) Q3 conducting (turned ON)
5) Check Squelch -> open - "1", else "0" -> bit 2
6) Q4 conducting (turned ON)
7) Check Squelch -> open - "1", else "0" -> bit 3
Table 4-2 summarizes the results.

Table 4-2 Plug Type Determination

bit 1 bit 2 bit 3 Micro-A plug Micro-B or PD Approximate Approximate Approximate

Standard-B plug level at RX when level at RX when level at RX when
detecting bit 1 detecting bit 2 detecting bit 3
1 1 1 Low Power PD (5A) ~ 0dB ~ 0dB ~ -9dB
1 1 0 PD Legacy1 ~ 0dB ~ -6dB (PD) ~ -30dB
~ 0dB (Legacy)
1 0 1 Fault Fault
1 0 0 Legacy PD (3A) ~ 0dB ~ -40dB ~ -40dB
0 1 1 Fault Fault
0 1 0 Fault Fault
0 0 1 Fault Fault
0 0 0 Fault Fault
Note 1: A legacy Standard-B plug does not have an ID pin but will be detected as legacy via the ID pin in the receptacle..

4.5 Low Power Devices using Micro-A Plug

The Low Power feature enables Sources to minimize the power they output over VBUS without using the PD
negotiation process. These devices utilize a captive cable ending in a Micro-A plug.
Sources that are able to detect the Low Power plug shall automatically begin an Implicit Contract equivalent to a
Battery PDO (Max Voltage = vLowPower max, Min Voltage = vLowPower min, Max Power=pLowPower nom) and
shall not transmit or respond to PD Messaging or Signaling while the Low Power plug is connected. Low Power
Devices (Sinks) shall be able to operate normally when powered by any voltage in the range vLowPower and shall not
transmit USB PD Messaging or Signaling.
The entry process into Low Power operation is as follows:

Page 102 USB Power Delivery Specification Revision 2.0, Version 1.1
1. The Source detects a Low Power Device is attached (see Table 4-2).
2. The Port Pair then operates on an Implicit Contract:
a. The Source supplies a voltage in the range vLowPower and at least pLowPower nominal
b. The Sink shall be able to operate on a voltage on the range vLowPower and shall draw no more than
pLowPower nominal.
3. The Source may monitor the voltage and when it falls below vLowPower min reapply vSafe5V in an attempt to
continue operating. Alternatively, the Source may not monitor VBUS and when it falls to this level; both it and the
Low Power Device will likely fail for lack of power.
Exit from Low Power operation occurs when the Low Power plug is detached.
Sources that are not able to detect the Low Power plug shall treat the plug as a PD micro-A plug. These sources would
therefore supply vSafe5V constantly to a Low Power Device (Sink).

4.6 Electrical Parameters

Table 4-3 shows the parameters used in this section.

Table 4-3 Electrical Parameters

Parameter Minimum Nominal Maximum Units Section

pLowPower 250 mW 4.5

tBitStreamDetect 100 300 ms 4.1

tBitStreamOff 100 ms 4.1

tDBDetect 10 15 s 4.1
tDBDischargeVbus 90 ms 4.1

tDBSourceOff 200 220 ms 4.1

tDeviceReady 60 90 s 4.1

tSendBitStream 95 ms 4.1
tWaitForPower 20 ms 4.1.1

vLowPower 2.5 vSafe5V max V 4.5

Table 4-4 Electrical Timers

Timer Parameter Used By Section

BitStreamDetectTimer tBitStreamDetect PolicyEngine 4.1, 8.3.3.6.1.5
DBDetectTimer tDBDetect PolicyEngine 4.1, 8.3.3.6.1.5

DBSourceOffTimer tDBSourceOff PolicyEngine 4.1, 8.3.3.6.1.5

DeviceReadyTimer tDeviceReady PolicyEngine 4.1, 8.3.3.6.1.5

WaitForPowerTimer tWaitForPower Policy Engine 4.1.1, 8.3.3.6.1.6

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 103
5. Physical Layer
5.1 Physical Layer Overview
The Physical Layer (PHY Layer) defines the signaling technology for USB Power Delivery. This chapter defines the
electrical requirements and parameters of the PD Physical Layer required for interoperability between USB PD
devices.

5.2 Physical Layer Functions

The USB PD Physical Layer consists of a pair of transmitters and receivers that communicate across a single signal
wire (VBUS or CC). All communication is half duplex. The PHY Layer practices collision avoidance to minimize
communication errors on the channel.
The transmitter performs the following functions:
 Receive packet data from the protocol layer
 Calculate and append a CRC
 Encode the packet data including the CRC (i.e. the payload)
 Transmit the Packet (Preamble, SOP*, payload, CRC and EOP) across the channel using either
o A Binary Frequency Shift Keyed (BFSK) modulated carrier over VBUS or
o Biphase Mark Coding (BMC) over CC
The receiver performs the following functions:
 For BFSK detect the modulated carrier from the channel
 Recover the clock and lock onto the Packet from the Preamble
 Detect the SOP*
 Decode the received data including the CRC
 Detect the EOP and validate the CRC
o If the CRC is valid, deliver the packet data to the protocol layer.
o If the CRC is not valid, flush the received data.

Page 104 USB Power Delivery Specification Revision 2.0, Version 1.1
 5.3 Symbol Encoding
Except for the Preamble, all communications on the line shall be encoded with a line code to ensure a reasonable level
of DC-balance and a suitable number of transitions. This encoding makes receiver design less complicated and allows
for more variations in the receiver design.
4b5b line code shall be used. This encodes 4-bit data to 5-bit symbols for transmission and decodes 5-bit symbols to
4-bit data for consumption by the receiver.
The 4b5b code provides data encoding along with special symbols. Special symbols are used to signal Hard Reset,
and delineate packet boundaries.

Table 5-1 4b5b Symbol Encoding Table

Name 4b 5b Symbol Description

0 0000 11110 hex data 0
1 0001 01001 hex data 1
2 0010 10100 hex data 2
3 0011 10101 hex data 3
4 0100 01010 hex data 4
5 0101 01011 hex data 5
6 0110 01110 hex data 6
7 0111 01111 hex data 7
8 1000 10010 hex data 8
9 1001 10011 hex data 9
A 1010 10110 hex data A
B 1011 10111 hex data B
C 1100 11010 hex data C
D 1101 11011 hex data D
E 1110 11100 hex data E
F 1111 11101 hex data F
Sync-1 K-code 11000 Startsynch #1
Sync-2 K-code 10001 Startsynch #2
RST-1 K-code 00111 Hard Reset #1
RST-2 K-code 11001 Hard Reset #2
EOP K-code 01101 EOP End Of Packet
Reserved Error 00000 Shall not be used
Reserved Error 00001 Shall not be used
Reserved Error 00010 Shall not be used
Reserved Error 00011 Shall not be used
Reserved Error 00100 Shall not be used
Reserved Error 00101 Shall not be used
Sync-3 K-code 00110 Startsynch #3
Reserved Error 01000 Shall not be used
Reserved Error 01100 Shall not be used
Reserved Error 10000 Shall not be used
Reserved Error 11111 Shall not be used

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 105
 5.4 Ordered Sets
Ordered sets shall be interpreted according to Figure 5-1.
An ordered set consists of 4 K-codes sent as shown in Figure 5-1.

Figure 5-1 Interpretation of ordered sets

A list of the ordered sets used by USB Power Delivery can be seen in Table 5-2. SOP* is a generic term used in place of
SOP/SOP’/SOP’’.

Table 5-2 Ordered Sets

Ordered Set Section

SOP 5.6.1.2.1
SOP’ 5.6.1.2.2
SOP’’ 5.6.1.2.3
Hard Reset 5.6.4
Cable Reset 5.6.5
SOP’_Debug 5.6.1.2.4
SOP’’_Debug 5.6.1.2.5

The receiver shall search for all four K-codes and when it finds at least three in the correct place, it may interpret it as
a valid ordered set (see Table 5-3).

Table 5-3 Validation of Ordered Sets

1st code 2nd code 3rd code 4th code

Valid Corrupt K-code K-code K-code
Valid K-code Corrupt K-code K-code
Valid K-code K-code Corrupt K-code
Valid K-code K-code K-code Corrupt
Valid (perfect) K-code K-code K-code K-code
Not Valid (example) K-code Corrupt K-code Corrupt

Page 106 USB Power Delivery Specification Revision 2.0, Version 1.1
 5.5 Transmitted Bit Ordering
This section describes the order of bits on the wire that shall be used when transmitting data of varying sizes. Table
5-4 shows the different data sizes that are possible.
Figure 5-2 shows the transmission order that shall be followed.

Table 5-4 Data Size

Unencoded Encoded
Byte 8-bits 10-bits
Word 16-bits 20- bits
DWord 32-bits 40-bits

Figure 5-2 Transmit Order for Various Sizes of Data

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 107
 5.6 Packet Format
The packet format shall consist of a Preamble, an SOP*, (see Section 5.6.1.2), packet data including the Message
Header, a CRC and an EOP (see Section 5.6.1.5). The packet format is shown in Figure 5-3 and indicates which parts of
the packet shall be 4b/5b encoded. Once 4b/5b encoded, the entire Packet shall be transmitted either using BFSK
over VBUS or BMC over CC. Note that when using BMC the Preamble is BMC encoded.

Figure 5-3 USB Power Delivery Packet Format

Preamble(training for receiver)

SOP* (Start
Of Packet)
Message
Header
Byte 0 Byte 1 ...

... Byte n-1 Byte n CRC

EOP (End Of
Packet)

LEGEND:
Training sequence provided by the Provided by the Physical Provided by the Protocol
Physical layer, not encoded with 4b5b layer, encoded with 4b5b layer, encoded with 4b5b

5.6.1 Packet Framing

The transmission starts with a Preamble that is used to allow the receiver to lock onto the carrier. It is followed by a
SOP* (Start of Packet). The packet is terminated with an EOP (End of Packet) K-code.

5.6.1.1 Preamble
The Preamble is used to achieve lock in the receiver by presenting an alternating series of "0s" and "1s", so the
average frequency is the carrier frequency. Unlike the rest of the packet, the Preamble shall not be 4b/5b encoded.
The Preamble shall consist of a 64-bit sequence of alternating 0s and 1s. The Preamble shall start with a "0" and shall
end with a "1".

5.6.1.2 Start of Packet Sequences

5.6.1.2.1 Start of Packet Sequence (SOP)

SOP is an ordered set. The SOP ordered set is defined as: three Sync-1 K-codes followed by one Sync-2 K-code (see
Table 5-5).

Table 5-5 SOP ordered set

K-code number K-code in code table

1 Sync-1
2 Sync-1
3 Sync-1
4 Sync-2

A Power Delivery Capable Provider, Provider/Consumer, Consumer or Consumer/Provider shall be able to detect and
communicate with packets using SOP. If a valid SOP is not detected (see Table 5-3) then the whole transmission shall
be Discarded.
Sending and receiving of SOP Packets shall be limited to PD Capable DFPs and UFPs only (i.e. PD Capable Ports on
PDUSB Hosts and PDUSB Devices). Cable Plugs shall neither send nor receive SOP Packets. Note that PDUSB Devices,
even if they have the physical form of a cable (e.g. AMAs), are still required to respond to SOP Packets.

Page 108 USB Power Delivery Specification Revision 2.0, Version 1.1
 5.6.1.2.2 Start of Packet Sequence Prime (SOP’)
The SOP’ ordered set is defined as: two Sync-1 K-codes followed by two Sync-3 K-codes (see Table 5-6).

Table 5-6 SOP’ ordered set

K-code number K-code in code table

1 Sync-1
2 Sync-1
3 Sync-3
4 Sync-3

A Cable Plug capable of SOP’ Communications shall only detect and communicate with packets starting with SOP’.
A DFP or Source needing to communicate with a Cable Plug capable of SOP’ Communications, attached between a Port
Pair will be able to communicate using both packets starting with SOP’ to communicate with the Cable Plug and
starting with SOP to communicate with its Port Partner. The DFP or Source shall co-ordinate SOP and SOP’
Communication so as to avoid collisions.
For a Cable Plug supporting SOP’ Communications, if a valid SOP’ is not detected (see Table 5-3) then the whole
transmission shall be Discarded. For the DFP or Source supporting SOP’ Communications if a valid SOP or SOP’ is not
detected (see Table 5-3) then the whole transmission shall be Discarded. When there is an Explicit Contract in place a
UFP shall not send SOP’ Packets and shall Discard all packets starting with SOP’. When there is no Explicit Contract or
an Implicit Contract in place a Sink shall not send SOP’ Packets and shall Discard all packets starting with SOP’.

5.6.1.2.3 Start of Packet Sequence Double Prime (SOP’’)

The SOP’’ ordered set is defined as the following sequence of K-codes: Sync-1, Sync-3, Sync-1, Sync-3 (see Table 5-7).

Table 5-7 SOP’’ ordered set

K-code number K-code in code table

1 Sync-1
2 Sync-3
3 Sync-1
4 Sync-3

A Cable Plug capable of SOP’’ Communication, shall have a SOP’ Communication capability in the other Cable Plug. No
cable shall only support SOP’’ Communication. A Cable Plug to which SOP’’ Communication is assigned shall only
detect and communicate with packets starting with SOP’’ and shall Discard any other packets.
A DFP needing to communicate with such a Cable Plug, attached between a Port Pair will be able to communicate
using packets starting with SOP’ and SOP’’ to communicate with the Cable Plugs and packets starting with SOP to
communicate with its Port Partner. A DFP which supports SOP’’ Communication shall also support SOP’
Communication and shall co-ordinate SOP* Communication so as to avoid collisions.
For the Cable Plug supporting SOP’’ Communication, if a valid SOP’’ is not detected (see Table 5-3) then the whole
transmission shall be Discarded. For the DFP if a valid SOP* is not detected (see Table 5-3) then the whole
transmission shall be Discarded. A UFP shall not send SOP’’ Packets and shall Discard all Packets starting with SOP’’.

5.6.1.2.4 Start of Packet Sequence Prime Debug (SOP’_Debug)

The SOP’_Debug ordered set is defined as the following sequence of K-codes: Sync-1, RST-2, RST-2, Sync-3 (see Table
5-8). The usage of this Ordered Set is presently undefined.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 109
 Table 5-8 SOP’_Debug ordered set

K-code number K-code in code table

1 Sync-1
2 RST-2
3 RST-2
4 Sync-3

5.6.1.2.5 Start of Packet Sequence Double Prime Debug (SOP’’_Debug)

The SOP’’_Debug ordered set is defined as the following sequence of K-codes: Sync-1, RST-2, Sync-3, Sync-2 (see
Table 5-9). The usage of this Ordered Set is presently undefined.

Table 5-9 SOP’’_Debug ordered set

K-code number K-code in code table

1 Sync-1
2 RST-2
3 Sync-3
4 Sync-2

5.6.1.3 Packet Payload

The packet payload is delivered from the protocol layer (Section 6.2) and shall be encoded with the hex data codes
from Table 5-1.

5.6.1.4 CRC
The CRC shall be inserted just after the payload. It is described in Section 5.6.2.

5.6.1.5 End of Packet (EOP)

The end of packet marker shall be a single EOP K-code as defined in Table 5-1. This shall mark the end of the CRC.
After the EOP, the CRC-residual shall be checked. If the CRC is not good, the whole transmission shall be discarded, if
it is good, the packet shall be delivered to the Protocol Layer. Note an EOP may be used to prematurely terminate a
Packet e.g. before sending Hard Reset Signaling.

5.6.2 CRC
The Message Header and data shall be protected by a 32-bit CRC.
CRC-32 protects the data integrity of the data payload. CRC-32 is defined as follows:
 The CRC-32 polynomial shall be = 04C1 1DB7h.
 The CRC-32 Initial value shall be = FFFF FFFFh.
 CRC-32 shall be calculated for all bytes of the payload not inclusive of any packet framing symbols (i.e. excludes
the Preamble, SOP*, EOP).
 CRC-32 calculation shall begin at byte 0 bit 0 and continue to bit 7 of each of the bytes of the packet.
 The remainder of CRC-32 shall be complemented.
 The residual of CRC-32 shall be C704 DD7Bh.
Note: This inversion of the CRC-32 remainder adds an offset of FFFF FFFFh that will create a constant CRC-32
residual of C704 DD7Bh at the receiver side.
Note: The CRC implementation is identical to the one used in [USB 3.1].
Figure 5-4 is an illustration of CRC-32 generation. The output bit ordering shall be as detailed in Table 5-10.

Page 110 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 5-4 CRC 32 generation

Table 5-10 CRC-32 Mapping

CRC-32 Result bit Position in CRC-32 Field

0 31
1 30
2 29
3 28
4 27
5 26
6 25
7 24
8 23
9 22
10 21
11 20
12 19
13 18
14 17
15 16
16 15
17 14
18 13
19 12
20 11
21 10
22 9
23 8
24 7

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 111
 CRC-32 Result bit Position in CRC-32 Field
25 6
26 5
27 4
28 3
29 2
30 1
31 0

The CRC-32 shall be encoded before transmission.

5.6.3 Packet Detection Errors

CRC errors, or errors detected while decoding encoded symbols using the code table, shall be treated the same way;
the Message shall be discarded and a GoodCRC Message shall not be returned.
While the receiver is processing a packet, if at any time VBUS becomes idle the receiver shall stop processing the packet
and discard it (no GoodCRC Message is returned). See Section 5.8.2.6.4 for the definition of BFSK idle and Section
5.8.3.6.1 for the definition of BMC idle.

5.6.4 Hard Reset

Hard Reset Signaling is an ordered set of bytes sent with the purpose to be recognized by the PHY Layer. The Hard
Reset Signaling ordered set is defined as: three RST-1 K-codes followed by one RST-2 K-code (see Table 5-11).

Table 5-11 Hard Reset ordered set

K-code number K-code in code table

1 RST-1
2 RST-1
3 RST-1
4 RST-2

A device shall perform a Hard Reset when it receives Hard Reset Signaling. After receiving the Hard Reset Signaling,
the device shall reset as described in Section 6.7.2. If a valid Hard Reset is not detected (see Table 5-3) then the
whole transmission shall be Discarded.
A Cable Plug shall perform a Hard Reset when it detects Hard Reset Signaling being sent between the Port Partners.
After receiving the Hard Reset Signaling, the device shall reset as described in Section 6.7.2.
The procedure for sending Hard Reset Signaling shall be as follows:
1. If the PHY Layer is currently sending a Message, the Message shall be interrupted by sending an EOP K-code and
the rest of the Message discarded.
2. If VBUS is not idle, wait for it to become idle (see Section 5.8.2.6.4 for the definition of BFSK idle and Section
5.8.3.6.1 for the definition of BMC idle)
3. Wait tInterFrameGap.
4. If VBUS is still idle send the Preamble followed by the 4 K-codes for Hard Reset Signaling.
5. Disable the channel (i.e. stop sending and receiving), reset the PHY Layer and inform the Protocol Layer that the
PHY Layer has been reset.
6. Re-enable the channel when requested by the Protocol Layer.
Figure 5-5 shows the line format of Hard Reset Signaling which is a Preamble followed by the Hard Reset Ordered
Set.

Page 112 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 5-5 Line format of Hard Reset

Preamble(training for receiver) RST-1 RST-1 RST-1 RST-2

LEGEND:
Preamble provided by the Physical layer, Provided by the Physical
not encoded with 4b5b layer, encoded with 4b5b

5.6.5 Cable Reset

Cable Reset Signaling is an ordered set of bytes sent with the purpose to be recognized as an embedded Control
Message to the PHY Layer. The Cable Reset Signaling ordered set is defined as the following sequence of K-codes:
RST-1, Sync-1, RST-1, Sync-3 (see Table 5-12).

Table 5-12 Cable Reset ordered set

K-code number K-code in code table
1 RST-1
2 Sync-1
3 RST-1
4 Sync-3

Cable Reset Signaling shall only be sent by the DFP. The Cable Reset Ordered Set is used to reset the Cable Plugs
without the need to Hard Reset the Port Partners. The state of the Cable Plug after the Cable Reset Signaling shall be
equivalent to power cycling the Cable Plug.
Figure 5-6 shows the line format of Cable Reset Signaling which is a Preamble followed by the Cable Reset Ordered
Set.

Figure 5-6 Line format of Cable Reset

Preamble(training for receiver) RST1 Sync-1 RST-1 Sync-3

LEGEND:
Preamble provided by the Physical layer, Provided by the Physical
not encoded with 4b5b layer, encoded with 4b5b

5.7 Collision Avoidance

The PHY Layer shall monitor the channel for data transmission and only initiate transmissions when VBUS or CC is idle.
If the bus idle condition is present, it shall be considered safe to start a transmission provided the conditions detailed
in Section 5.8.1.4 are met. The bus idle condition shall be checked immediately prior to transmission. If transmission
cannot be initiated then the packet shall be discarded. If the packet is discarded because VBUS or CC is not idle, the PHY
Layer shall signal to the protocol layer that it has discarded the Message as soon as VBUS or CC becomes idle. See
Section 5.8.2.6.4 for the definition of idle VBUS and Section 5.8.3.6.1 for the definition of idle CC.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 113
 5.8 Physical Layer Signaling Schemes
5.8.1 Common Signaling Scheme Specifications
This section defines receiver and transmitter requirements which are common across different signaling schemes.

5.8.1.1 Common Signaling Scheme Parameters

The electrical requirements specified in Table 5-13 shall apply to both the transmitter and receiver.

Table 5-13 Common Normative Signaling Scheme Requirements

Parameter Description Min Nom Max Units Comment

fBitRate Bit rate 270 300 330 Kbps

5.8.1.2 Common Transmitter Signaling Scheme Specifications

Table 5-14 Common Normative Signaling Scheme Requirements for Transmitter

Parameter Description Min Nom Max Units Comment

pBitRate Maximum difference 0.25 %
between the bit-rate during
The reference bit
the part of the packet rate is the average
following the Preamble and bit rate of the last 32
the reference bit-rate. bits of the Preamble.

tInterFrameGap Time from the end of last 25 µs

bit of a Frame until the start
of the first bit of the next
Preamble.
tStartDrive Time before the start of the -1 1 µs
first bit of the Preamble
when the transmitter shall
start driving the line.

5.8.1.2.1 Bit Rate Drift

Limits on the drift in fBitRate are set in order to help low-complexity receiver implementations.
fBitRate is the reciprocal of the average bit duration from the previous 32 bits at a given portion of the packet. The
change in fBitRate during a packet shall be less than pBitRate. The reference bit rate (refBitRate) is the average
fBitRate over the last 32 bits of the Preamble. fBitRate throughout the packet, including the EOP, shall be within
pBitRate of refBitRate. pBitRate is expressed as a percentage:

pBitRate = | fBitRate – refBitRate | / refBitRate x 100%

The transmitter shall have the same pBitRate for all packet types. The BIST Carrier Mode 2and Bit Stream signals are
continuous signals without a payload. When checking pBitRate any set of 1044 bits (20 bit SOP followed by 1024
PRBS bits) within a continuous signal may be considered as the part of the packet following the Preamble and the 32
preceding bits considered to be the last 32 bits of the Preamble used to compute refBitRate .

5.8.1.3 Common Receiver Signaling Scheme Specifications

Table 5-15 Common Normative Signaling Scheme Requirements for Receiver

Parameter Description Min Nom Max Units Comment

nBER Bit error rate, S/N = 25 dB 10-6

Page 114 USB Power Delivery Specification Revision 2.0, Version 1.1
 5.8.1.4 Inter-Frame Gap
Figure 5-7 illustrates the inter-Frame gap timings.

Figure 5-7 Inter-Frame Gap Timings

Bus driven after end Bus driven before

End of Frame of Frame Preamble Preamble

tInterFrameGap

tEndDriveBFSK or tStartDrive
tEndDriveBMC

The transmitter shall drive the bus for no longer than tEndDriveBFSK or tEndDriveBMC (as appropriate) after
transmitting the final bit of the Frame. Detailed requirements for terminating the Frame and ceasing to drive the bus
are given separately for BFSK and BMC.
Before starting to transmit the next Frame’s Preamble the transmitter of the next Frame shall ensure that it waits for
tInterFrameGap after either:
1. Transmitting the previous frame, or
2. Receiving the previous frame, or
3. Observing an idle condition on VBUS or CC (see Section 5.7).
Note: the transmitter is also required to verify a bus idle condition immediately prior to starting transmission of the
next Frame.
The transmitter of the next Frame may vary the start of the Preamble by tStartDrive (see Section 5.8.2.5.2).
See also Section 5.8.3.1 for figures detailing the timings relating to transmitting, receiving and observing idle in
relating to Frames.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 115
 5.8.2 Binary Frequency Shift Keyed (BFSK) Signaling Scheme
The Binary Frequency Shift Keyed (BFSK) Signaling Scheme over VBUS uses a carrier of fCarrier modulated with the
information to avoid the noise from the power supplies. Continuous Phase Binary Frequency Shift Keying (BFSK)
shall be used to encode bits for transmission on the channel. In this specification, BFSK shall be understood to mean
continuous phase BFSK. A signal of amplitude vTX shall be injected onto VBUS using a carrier frequency, fCarrier. The
following logic states shall be used:
 Logic 0 is indicated by a frequency fCarrier - fDeviation.
 Logic 1 is indicated by a frequency fCarrier + fDeviation.
The PHY Layer functions are shown in Figure 5-8, Figure 5-9, and Figure 5-10. The PHY Layer is expected to keep
power consumption low, especially when only the squelch detector is required to be active. In the active mode, where
any of the functions listed above may be executed, the PHY Layer Block power consumption should be minimized. In
the squelch mode, when only the squelch detector is required, the power consumption should be minimized.

Figure 5-8 Transmitter Block Diagram

Figure 5-9 Receiver Block Diagram

Page 116 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 5-10 Channel Diagram (Cable Type Detection not shown)

SOURCE CABLE SINK

TX TX
rTX rTX
RX RX
cAC-Coupling cAC-Coupling

zIsolation zIsolation
VBUS VBUS

Power Data Data

Load
...

...
Supply Lines Lines

GND GND
SHIELD SHIELD

5.8.2.1 Channel Overview

The channel connects two PHYs together via a single-ended serial signal. The PD signal uses USB VBUS as the channel,
and the system is designed to treat the VBUS line in the cable as a transmission line terminated at both ends with
matching impedance. The PHY Layer shall be AC coupled to VBUS or be tolerant of the maximum possible DC voltage
that may be present on VBUS. For example, the PHY Layer may be AC coupled to VBUS through a capacitor at each end.
While transmitting, the Source, or Sink, shall apply an AC signal with amplitude vTX to VBUS as measured between
zIsolation and cAC-Coupling.

5.8.2.2 Transceiver Isolation Impedance

The Source and Sink shall place an isolation impedance between the VBUS wire bulk capacitance and the VBUS pin on the
connector to allow the AC coupled USB Power Delivery transceiver to communicate over VBUS.
The isolation impedance shall have an impedance of zIsolation at any frequency within fRange. See Sections 7.1.13.1
and 7.2.9.1 for additional detail.
Note: Isolation impedance surges may occur and need to be clamped in some manner. There are many variables that
could enter into the nature of the surge that are not controlled by the spec and subject to implementation. The
clamping method is therefore an implementation choice. Implementers are strongly advised to read through
Appendix-C to evaluate the need for this in their implementation.

5.8.2.3 Transceiver AC Coupling Capacitance

The Source and Sink shall be AC coupled to VBUS or be tolerant of the maximum possible DC voltage that may be
present on VBUS. For example, the Source and Sink may be AC coupled to V BUS by placing an AC coupling capacitance
cAC-Coupling between the VBUS pin on the connector and the transceiver as indicated in Figure 5-10. A suggested
value for cAC-Coupling in this case would be between 3nF and 10nF.

5.8.2.4 BFSK Common Specifications

This section defines the common receiver and transmitter requirements.

5.8.2.4.1 BFSK Common Parameters

The electrical requirements specified in Table 5-16 shall apply to both the transmitter and receiver.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 117
 Table 5-16 BFSK Common Normative Requirements

Parameter Description Min Nom Max Units Comment

fCarrier BFSK carrier frequency 22.4 23.2 24.0 MHz

fDeviation BFSK frequency deviation 450 500 600 kHz

Table 5-17 BFSK Transceiver Isolation Impedance Normative Requirements

Parameter Description Min Nom Max Units Comment

zIsolation Impedance Allowed 80 Ω Measured at any frequency
within fRange.
fRange Range of frequencies 20.4 26 MHz A spacing of 2MHz around
used in communication fCarrier is allowed for the signal
including FM tolerance and
deviation.

One example implementation of a transceiver isolation impedance using the parameters listed in Table 5-17 is a 1µH
inductor (see Appendix C).

5.8.2.5 BFSK Transmitter Specifications

Limits on the drift in fCarrier, and fDeviation are set in order to help low-complexity receiver implementations.
The transceiver shall terminate the VBUS line with rTX while it is powered, whether it is transmitting, receiving or
waiting for the squelch to close.

5.8.2.5.1 BFSK Transmitter Requirements

The requirements specified in Table 5-18 shall apply to the transmitter.

Table 5-18 BFSK Transmitter Normative Requirements

Name Description Min Nom Max Units Comment

pCarrierFreq Maximum difference between the 0.2 % The reference carrier
carrier-frequency during the part frequency is the average
of the packet following the carrier frequency of the
Preamble and the reference last 32 bits of the
carrier-frequency. Preamble.
pDevFreq Maximum difference between the 1 % The reference deviation
deviation frequency during the frequency is the average
part of the packet following the deviation frequency
Preamble and the reference during the last 32 bits of
deviation frequency. the Preamble.
rTX The termination resistance and 52 62 72 Ω The impedance at the
the cable impedance for test and point between the TX
calculation. block and the rTX
resistor in Figure 5-10 is
assumed to be 0Ω when
the transceiver is
powered (See also
Figure 4-4).
tEndDriveBFSK Time to cease driving the line 0 4 µs
after the end of the last bit of a
Frame

Page 118 USB Power Delivery Specification Revision 2.0, Version 1.1
Name Description Min Nom Max Units Comment
vTX TX voltage injected on VBUS 100 150 200 mVRMS This is the voltage on
VBUS when terminated by
a nominal rTX through a
cable no longer than
250mm whose
characteristic impedance
matches the termination
impedance.

5.8.2.5.1.1 Carrier Noise

The carrier phase noise should be considered when designing the transmitter system in order to achieve the required
BER (nBER). The carrier phase noise can be measured while the transmitter sends a BIST Carrier Mode 0 or BIST
Carrier Mode 1.

5.8.2.5.1.2 Carrier-Frequency Drift

fCarrier is the carrier frequency over the previous 10 bits at a given point in the packet. The change in fCarrier
during a packet shall be less than pCarrierFreq. The reference carrier frequency (refCarrierFreq) is the average
fCarrier of the last 32 bits of the Preamble. fCarrier during the packet, including the EOP, shall be within
pCarrierFreq of the reference carrier frequency. pCarrierFreq is expressed as a percentage:

pCarrierFreq = | fCarrier – refCarrierFreq| / refCarrierFreq x 100%

The transmitter shall have the same pCarrierFreq for all packet types. The BIST Carrier Mode 3 signal is an example
of a continuous signal without a Preamble. When checking pCarrierFreq any set of 1044 bits within a continuous
signal may be considered as the part of the packet following the Preamble and the 32 preceding bits considered to be
the last 32 bits of the Preamble used to compute refCarrierFreq.

5.8.2.5.1.3 Deviation-Frequency Drift

fDeviation is the frequency deviation during one bit at any point in the packet. The change in fDeviation shall be less
than pDevFreq. The reference deviation frequency (refDevFreq) is the average fDeviation during the last 32 bits of
the Preamble. fDeviation during the packet, including the EOP, shall be within pDevFreq of the reference deviation
frequency. pDevFreq is expressed as a percentage:

pDevFreq = | fDeviation – refDevFreq | / refDevFreq x 100%

The transmitter shall have the same fDeviation for all packet types. The BIST Carrier Mode 0 and BIST Carrier Mode
1 signals are examples of continuous signals without a Preamble. When checking pDevFreq any set of 1044 bits
within a continuous signal may be considered as the part of the packet following the Preamble and the 32 preceding
bits considered to be the last 32 bits of the Preamble for computing refDevFreq.

5.8.2.5.2 Transmitter Characteristics

In order to allow for low cost and simple receivers, there is a requirement for the transmitted waveform to have a
minimum of edge steepness. The transmitted waveform shall fulfill the eye diagram mask in Figure 5-11.
In Figure 5-11 the Y-axis corresponds to the nominal deviation. . A continuous string of '1's will produce a constant
frequency, which is designated 100% in this figure. This frequency must fulfil the relevant requirements regarding
tolerances as described in Table 5-16. Similarly a continuous stream of ‘0’s corresponds to -100% on the Y-axis. This
allows for a pre-filtering of the signal used for modulation if desired but limits the amount of filtering allowed. The
designer can balance the design between filtering at the baseband or the RF level as appropriate as long as all of the
requirements are fulfilled.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 119
When starting to transmit a frame the transmitter shall enable its carrier tStartDrive before the start of the first
preamble bit. It shall stop transmitting a carrier within tEndDriveBFSK of the end of the last transmitted symbol.

Figure 5-11 Eye diagram of BFSK Modulation

In order to manage the noise emitted from the cables, the emitted spectrum, on VBUS at the transmitting device
receptacle, shall comply with the mask in Figure 5-12 when VBUS is terminated by a nominal rTX at the connector
through a cable no longer than 250mm whose characteristic impedance matches the termination impedance. Normal
rules and regulations for noise emissions shall still be applicable.
Side lobes outside the coverage of Figure 5-12 shall be kept below the level as the figure shows.

Page 120 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 5-12 BFSK Transmit Spectral Mask, given in absolute terms relative to the maximum value of vTX

D E
0

-5
dB relative to 200mVrms

A
-10

-15

B C F G
-20

-25

H
-30

-35
1 2
10 10
frequency [MHz]

The corners in Figure 5-12 are specified in Table 5-19.

Table 5-19 BFSK Spectrum Mask Corners

Frequency (MHz) Maximum Allowed Signal Level

(dB) (mVrms)
< 10 (A) -10 63.2
13 (B) to 20.8(C) -20 20
21.45(D) to 24.89 (E) 0 200
25.54(F) to 40 (G) -20 20
>40 (H) -30 6.3

5.8.2.6 BFSK Receiver Specifications

5.8.2.6.1 BFSK Receiver Electrical Parameters

The requirements specified in Table 5-20 shall apply to the receiver (except vSquelchDetecting). There are two
different squelch modes for the receiver. The Squelch Detection mode is used when the receiver is implementing
cable-type detection following the suggested method in Section 4.4. The Squelch Operating mode is used when the
receiver is watching for a packet to arrive. These two squelch modes have different required sensitivities. In the
Squelch Detection mode, the receiver detects signals exceeding vSquelchDetecting. In the Squelch Operating mode
the receiver shall meet the requirement nBER when the signal level exceeds vSquelchOperating.
The input impedance of the receiver (the RX block in Figure 5-10 and Figure 4-4) is zRX. The input impedance as
measured between VBUS and GND is determined by rTX (see Section 5.8.2.5). The high impedance zRX is required for
cable-type detection (see Section 4.4.4).

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 121
The receiver shall meet the nBER performance requirement in Table 5-20 when the voltage received on VBUS is within
the allowable range of vRX. Cables close to a quarter wavelength with characteristic impedance higher or lower than
rTX may attenuate or amplify the signal level, so the allowable range of vRX includes margin above and below the
allowable vTX. The ranges for vRX were selected to cover the variation seen in legacy cables.

Table 5-20 BFSK Receiver Normative Requirements

Name Description Min Nom Max Units Comment

tBitStreamComplete The Bit Stream has stopped if 1 3 ms
the squelch has closed for
tBitStreamComplete.
vRX RX voltage received on VBUS 55 150 300 mVRMS This is the voltage on VBUS
(the link terminated by
rTX).
Legacy cables close to a
quarter wavelength with
characteristic impedance
higher or lower than rTX
may attenuate or amplify
the signal level by up to
6dB.
In practice, the minimum
value will be the actual
vSquelchOperating value.
vSquelchDetecting Squelch detection sensitivity 15 20 25 mVRMS Informative only.
in Squelch Detection Mode
vSquelchOperating Squelch detection sensitivity 35 55 mVRMS This parameter only
In Squelch Operating Mode pertains to the signal
content within the
frequency band of interest
within fRange.
zRX Receiver input impedance 10 kΩ 15% tolerance, measured
from VBUS to GND in the
band from 19 MHz to 27
MHz.
Note:
The input impedance as
measured between VBUS
and GND is determined by
rTX (see Section 5.10).
The high impedance zRX
is required for cable-type
detection (see Section
4.4.4).

5.8.2.6.2 Receiver Filter Specification

The design of the receiver filter represented by the “Filter Bandpass” in

Figure 5-9 Receiver Block Diagram

is implementation specific, but shall take into account the out-of-band power-supply noise (see Sections 7.1.13.2 and
7.2.9.2).

5.8.2.6.3 Crosstalk in the cables

In order to maintain good communications, the cables shall fulfill the crosstalk requirements in Section 3.6.6.

Page 122 USB Power Delivery Specification Revision 2.0, Version 1.1
 5.8.2.6.4 Definition of Idle
For the BFSK Signaling Scheme VBUS shall be declared idle when the signal level is less than vSquelchOperating. The
power supply noise allowed by Figure 7-8 and Figure 7-11 shall not cause the receiver to indicate the channel is busy.

5.8.2.7 Bit Stream

A Bit Stream transmission is defined to allow a Consumer/Provider using BFSK on a Type-B connector to detect a
Provider/Consumer with a Dead Battery on a Type-A connector (see Section 4.1).
The transmitter of the Provider/Consumer that implements Dead Battery Support shall be able to transmit a Bit
Stream consisting of alternating “0s” and “1s” which may be viewed as concatenating multiple Preambles as shown in
Figure 5-13 (note that the last Preamble may not contain 64 bits). The PHY Layer shall continue to transmit the Bit
Stream until the PD System is ready for a Source_Capabilities Message or VBUS becomes vSafe0V (see Figure 4-1).
The Consumer/Provider’s receiver shall declare a Bit Stream is detected after detecting 128 consecutive bits that
match the Preamble pattern of alternating “0s” and “1s”.
After the Bit Stream is detected, the receiver shall indicate that the Bit Stream has stopped when the squelch has
closed (the signal level is below vSquelchOperating) for tBitStreamComplete.

Figure 5-13 Line Format of Bit Stream

Preamble1 Preamble2 ... PreambleN

LEGEND:
Preamble provided by the Physical layer,
not encoded with 4b5b

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 123
 5.8.3 Biphase Mark Coding (BMC) Signaling Scheme
Biphase Mark Coding (BMC) is an alternative physical layer for carrying USB Power Delivery Messages. This encoding
assumes a dedicated DC connection, identified as the CC wire, which is used for sending PD Messages.
Biphase Mark Coding is a version of Manchester coding (see [IEC 60958-1]). In BMC, there is a transition at the start
of every bit time (UI) and there is a second transition in the middle of the UI when a 1 is transmitted. BMC is
effectively DC balanced, (each 1 is DC balanced and two successive zeroes are DC balanced, regardless of the number
of intervening 1’s). It has bounded disparity (limited to 1 bit over an arbitrary packet, so a very low DC level).
Figure 5-14 illustrates Biphase Mark Coding. This example shows the transition from a Preamble to the Sync-1 K-
codes of the SOP Ordered Set at the start of a Message. Note that other K-codes can occur after the Preamble for
Signaling such as Hard Reset and Cable Reset.

Figure 5-14 BMC Example

5.8.3.1 Encoding and signaling

BMC uses DC coupled baseband signaling on CC. Figure 5-15 shows a block diagram for a Transmitter and Figure 5-16
shows a block diagram for the corresponding Receiver.

Figure 5-15 BMC Transmitter Block Diagram

Data 4b5b BMC

Encoder Encoder to CC

CRC

Page 124 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 5-16 BMC Receiver Block Diagram

from CC BMC SOP 5b4b Data

Decoder Detect Decoder

CRC

The USB PD baseband signal shall be driven on the CC wire with a tri-state driver that shall cause a vSwing swing on
CC. The tri-state driver is slew rate limited (see min rise/fall time in Section 5.8.3.5) to limit coupling to D+/D- and to
other signal lines in the Type-C fully featured cables (see [USBType-C 1.0]). This slew rate limiting can be performed
either with driver design or an RC filter on the driver output.
When sending the Preamble, the transmitter shall start by transmitting a low level. The receiver shall tolerate the loss
of the first edge. The transmitter may vary the start of the Preamble by tStartDrive min (see Figure 5-17).

Figure 5-17 BMC Encoded Start of Preamble

The transmitter shall terminate the final bit of the Frame by an edge (the “trailing edge”) to help ensure that the
receiver clocks the final bit. If the trailing edge results in the transmitter driving CC low (i.e. the final half-UI of the
frame is high), then the transmitter:
1. Shall continue to drive CC low for tHoldLowBMC.
2. Then shall continue to drive CC low for tEndDriveBMC measured from the trailing edge of the final bit of the
Frame.
3. Then shall release CC to high impedance.
Figure 5-18 illustrates the end of a BMC encoded Frame with an encoded zero for which the final bit of the Frame is
terminated by a high to low transition. Figure 5-19 illustrates the end of a BMC Encoded frame with an encoded one
for which the final bit of the Frame is terminated by a high to low transition. Both figures also illustrate the
tInterFrameGap timing requirement before the start of the next Frame when the Port has either been transmitting or
receiving the previous Frame (see Section 5.8.1.4).

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 125
 Figure 5-18 Transmitting or Receiving BMC Encoded Frame Terminated by Zero with High-to-Low Last Transition

Figure 5-19 Transmitting or Receiving BMC Encoded Frame Terminated by One with High-to-Low Last Transition

If the trailing edge results in the transmitter driving CC high (i.e. the final half-UI of the frame is low), then the
transmitter:
1. Shall continue to drive CC high for 1 UI.
2. Then shall drive CC low for tHoldLowBMC.
3. Then shall continue to drive CC low for tEndDriveBMC measured from the final edge of the final bit of the Frame.
4. Then shall release CC to high impedance.
Figure 5-20 illustrates the ending of a BMC encoded Frame that ends with an encoded zero for which the final bit of
the Frame is terminated by a low to high transition. Figure 5-21 illustrates the ending of a BMC encoded Frame that
ends with an encoded zero for which the final bit of the Frame is terminated by a low to high transition. Both figures
also illustrate the tInterFrameGap timing requirement before the start of the next Frame when the Port has either
been transmitting or receiving the previous Frame (see Section 5.8.1.4).

Figure 5-20 Transmitting or Receiving BMC Encoded Frame Terminated by Zero with Low to High Last Transition

Page 126 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 5-21 Transmitting or Receiving BMC Encoded Frame Terminated by One with Low to High Last Transition

Figure 5-22 illustrates the end of a BMC encoded Frame with an encoded zero for which the final bit of the Frame is
terminated by a high to low transition. The figure also illustrates the tTransitionWindow followed tInterFrameGap
timing requirement before the start of the next Frame, when the Port did not either transmit or receive the previous
Frame and is waiting for bus idle before transmission of the next Frame (see Section 5.8.1.4).

Figure 5-22 Waiting for idle after a BMC Encoded Frame Terminated by Zero with High-to-Low Last Transition

Note: There is no requirement to maintain a timing phase relationship between back-to-back packets.

5.8.3.2 Transmit and Receive Masks

5.8.3.2.1 Transmit Masks

The transmitted signal shall not violate the masks defined in Figure 5-23, Figure 5-24, Table 5-21 and Table 5-22 at
the output of a load equivalent to the cable model and receiver load model described in Section 5.8.3.3. Note: the
measurement of the transmitter does not need to accommodate a change in signal offset due to the ground offset
when current is flowing in the cable.
The transmitted signal shall have a rise time no faster than tRise. The transmitted signal shall have a fall time no
faster than tFall. The maximum limits on the rise and fall times are enforced by the Tx inner masks.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 127
 Figure 5-23 BMC Tx ‘ONE’ Mask

Figure 5-24 BMC Tx ‘ZERO’ Mask

Page 128 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 5-21 BMC Tx Mask Definition, X Values

Name Description Value Units

X1Tx Left Edge of Mask 0.015 UI
X2Tx see figure 0.07 UI
X3Tx see figure 0.15 UI
X4Tx see figure 0.25 UI
X5Tx see figure 0.35 UI
X6Tx see figure 0.43 UI
X7Tx see figure 0.485 UI
X8Tx see figure 0.515 UI
X9Tx see figure 0.57 UI
X10Tx see figure 0.65 UI
X11Tx see figure 0.75 UI
X12Tx see figure 0.85 UI
X13Tx see figure 0.93 UI
X14Tx Right Edge of Mask 0.985 UI

Table 5-22 BMC Tx Mask Definition, Y Values

Name Description Value Units

Y1Tx Lower bound of Outer mask -0.075 V
Y2Tx Lower bound of inner mask 0.075 V
Y3Tx see figure 0.15 V
Y4Tx see figure 0.325 V
Y5Tx Inner mask vertical midpoint 0.5625 V
Y6Tx see figure 0.8 V
Y7Tx see figure 0.975 V
Y8Tx see figure 1.04 V
Y9Tx Upper Bound of Outer mask 1.2 V

5.8.3.2.2 Receive Masks

A Provider using the BMC Signaling Scheme shall be capable of receiving a signal that complies with the mask when
sourcing power as defined in Figure 5-25, Figure 5-26 and Table 5-23. The Provider Rx mask is bounded by sweeping
a Tx mask compliant signal, with added vNoiseActive between power neutral and Provider offsets.
A Consumer using the BMC Signaling Scheme shall be capable of receiving a signal that complies with the mask when
sinking power as defined in Figure 5-29, Figure 5-30 and Table 5-23. The Consumer Rx mask is bounded by sweeping
a Tx mask compliant signal, with added vNoiseActive between power neutral and Consumer offsets.
Every product using the BMC Signaling Scheme shall be capable of receiving a signal that complies with the mask
when power neutral as defined in Figure 5-27, Figure 5-28 and Table 5-23.
Dual-Role Devices shall meet the receiver requirements for a Provider when providing power during any
transmission using the BMC Signaling Scheme or a Consumer when consuming power during any transmission using
the BMC Signaling Scheme.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 129
Cable Plugs shall meet the receiver requirements for both a Provider and a Consumer during any transmission using
the BMC Signaling Scheme.
The parameters used in the masks are specified to be appropriate to either edge triggered or oversampling receiver
implementations.
The masks are defined for ‘ONE’ and ‘ZERO’ separately as BMC enforces a transition at the midpoint of the unit
interval while a ‘ONE’ is transmitted.
The Rx masks are defined to bound the Rx noise after the Rx bandwidth limiting filter with the time constant tRxFilter
has been applied.
The boundaries of Rx outer mask, Y1Rx and Y5Rx, are specified according to vSwing max and accommodate half of
vNoiseActive from cable noise coupling and the signal offset vIRDropGNDC due to the ground offset when current is
flowing in the cable.
The vertical dimension of the Rx inner mask, Y4Rx - Y2Rx, for power neutral is derived by reducing the vertical
dimension of the Tx inner mask, Y7Tx - Y3Tx, at time location X3Tx by vNoiseActive to account for cable noise
coupling. The received signal is composed of a waveform compliant to the Tx mask plus vNoiseActive.
The vertical dimension of the Rx inner mask for sourcing power is derived by reducing the vertical dimension of the
Tx inner mask by vNoiseActive and vIRDropGNDC to account for both cable noise coupling and signal DC offset. The
received signal is composed of a waveform compliant to the Tx mask plus the maximum value of vNoiseActive plus
vIRDropGNDC where the vIRDropGNDC value transitions between the minimum and the maximum values as allowed
in this spec.
The vertical dimension of the Rx inner mask for sinking power is derived by reducing the vertical dimension of the Tx
inner mask by vNoiseActive max and vIRDropGNDC max for account for both cable noise coupling and signal DC
offset. The received signal is composed of a waveform compliant to the Tx mask plus the maximum value of
vNoiseActive plus vIRDropGNDC where the vIRDropGNDC value transitions between the minimum and the maximum
values as allowed in this spec.
The center line of the Rx inner mask, Y3Rx, is at half of the nominal vSwing for power neutral, and is shifted up by half
of vIRDropGNDC max for sourcing power and is shifted down by half of vIRDropGNDC max for sinking power.
The receiver sensitivity shall be set such that the receiver does not treat noise on an undriven signal path as an
incoming signal. Signal amplitudes below vNoiseIdle max shall be treated as noise when BMC is idle.

Page 130 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 5-25 BMC Rx ‘ONE’ Mask when Sourcing Power

Figure 5-26 BMC Rx ‘ZERO’ Mask when Sourcing Power

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 131
 Figure 5-27 BMC Rx ‘ONE’ Mask when Power neutral

Figure 5-28 BMC Rx ‘ZERO’ Mask when Power neutral

Page 132 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 5-29 BMC Rx ‘ONE’ Mask when Sinking Power

Figure 5-30 BMC Rx ‘ZERO’ Mask when Sinking Power

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 133
 Table 5-23 BMC Rx Mask Definition

Name Description Value Units

X1Rx Left Edge of Mask 0.07 UI

X2Rx Top Edge of Mask 0.15 UI

X3Rx See figure 0.35 UI

X4Rx See figure 0.43 UI

X5Rx See figure 0.57 UI

X6Rx See figure 0.65 UI

X7Rx See figure 0.85 UI

X8Rx See figure 0.93 UI

Y1Rx Lower bound of Outer Mask -0.3325 V

Y2Rx Lower Bound of Inner Mask Y3Rx – 0.205 when V

sourcing power1 or
sinking power1
Y3Rx – 0.33 when power
neutral1
Y3Rx Center line of Inner Mask 0.6875 Sourcing Power1 V
0.5625 Power Neutral1
0.4375 Sinking Power1
Y4Rx Upper bound of Inner mask Y3Rx + 0.205 when V
sourcing power1 or
sinking power1
Y3Rx + 0.33 when power
neutral1
Y5Rx Upper bound of the Outer mask 1.5325 V
Note 1: The position of the center line of the Inner Mask is dependent on whether the receiver is
Sourcing or Sinking power or is Power Neutral (see earlier in this section).

5.8.3.3 Transmitter Load Model

The transmitter load model for the eye mask tests and vSwing shall be equivalent to the circuit outlined in Figure
5-31 for a Source and Figure 5-32 for a Sink. It is formed by the concatenation of a cable load model and a receiver
load model. See [USBType-C 1.0] for details of the Rp and Rd resistors.

Figure 5-31 Transmitter Load Model for BMC Tx from a Source

Transmitter Load
Model Output
Cable Model Receiver
Rp Load Model
rOutput Connector La
cCablePlug

cCablePlug

cShunt ca ca Rd cReceiver
2 2

Page 134 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 5-32 Transmitter Load Model for BMC Tx from a Sink

Transmitter Load
Model Output
Cable Model Receiver
Rp Load Model
rOutput Connector La

cCablePlug

cCablePlug
Rd cShunt ca ca cReceiver
2 2

The transmitter system components rOutput and cShunt are illustrated for informative purposes, and do not form
part of the transmitter load model. See Section 5.8.3.5 for a description of the transmitter system design.
The value of the modeled cable inductance, La, (in nH) shall be calculated from the following formula:
𝐿𝑎 = 𝒕𝑪𝒂𝒃𝒍𝒆𝑫𝒆𝒍𝒂𝒚𝑚𝑎𝑥 ∗ 𝒛𝑪𝒂𝒃𝒍𝒆𝑚𝑖𝑛
tCableDelay is the modeled signal propagation delay through the cable, and zCable is the modeled cable impedance.
The modeled cable inductance is 640 nH for a cable with zCablemin = 32 Ω and tCableDelaymax = 20 nS.
The value of the modeled cable capacitance, Ca, (in pF) shall be calculated from the following formula:
tCableDelay𝑚𝑎𝑥
𝐶𝑎 =
zCable𝑚𝑖𝑛
The modeled cable capacitance is Ca = 625 pF for a cable with zCablemin = 32 Ω and tCableDelaymax = 20 nS.
Therefore, Ca/2 = 312.5 pF.
cCablePlug models the capacitance of the plug at each end of the cable. cReceiver models the capacitance of the
receiver. The maximum values shall be used in each case.
Note: the transmitter load model assumes that there are no other return currents on the ground path.

5.8.3.4 BMC Common specifications

This section defines the common receiver and transmitter requirements.

5.8.3.4.1 BMC Common Parameters

The electrical requirements specified in Table 5-24 shall apply to both the transmitter and receiver.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 135
 Table 5-24 BMC Common Normative Requirements

Name Description Min Nom Max Units Comment

tUnitInterval1 Unit Interval 3.03 3.70 µs 1/fBitRate
Each plug on a cable assembly
Capacitance for a Cable
cCablePlug2 25 pF can have capacitance up to
Plug
this value
Signal propagation delay
tCableDelay 20 ns
through the cable
Cable characteristic
impedance on CC Wire as See [USBType-C 1.0] for Cable
zCable
defined in [USBType-C impedance values.
1.0].
Note 1: tUnitInterval denotes the time to transmit an unencoded data bit, not the shortest high or low times on the wire after
encoding with BMC. A single data bit cell has duration of 1UI, but a data bit cell with value 1 will contain a centrally placed 01 or
10 transition in addition to the transition at the start of the cell.
Note 2: The capacitance of the bulk cable is not included in the cCablePlug definition. It is modeled as transmission line in both
modeling and compliance processes. However cCablePlug does include the BMC transceiver’s capacitance in the Cable Plug(s).

5.8.3.5 BMC Transmitter Specifications

The transmitter shall meet the specifications defined in Table 5-25.

Table 5-25 BMC Transmitter Normative Requirements

Name Description Min Nom Max Units Comment

Time to cease driving the
Min value is limited by
tEndDriveBMC line after the end of the last 23 µs
tHoldLowBMC.
bit of the Frame.
10 % and 90 % amplitude
tFall Fall Time 300 ns points, minimum is under an
unloaded condition.
Time to cease driving the
Max value is limited by
tHoldLowBMC line after the final high-to- 1 µs
tEndDriveBMC.
low transition.
10 % and 90 % amplitude
tRise Rise time 300 ns points, minimum is under an
unloaded condition.
Applies to both no load
condition and under the load
vSwing Voltage Swing 1.05 1.125 1.2 V
condition specified in Section
5.8.3.3.
Source output impedance at
the Nyquist frequency of [USB
Transmitter output
zDriver 33 75 Ω 2.0] low speed (750 kHz)
impedance
while the source is driving the
CC line.

cReceiver is the capacitance that a DFP or UFP shall present on the CC line when the DFP or UFP’s receiver is not
transmitting on the line. The transmitter may have more capacitance than cReceiver while driving the CC line, but
must meet the waveform mask requirements. Once transmission is complete, the transmitter shall disengage
capacitance in excess of cReceiver from the CC wire within tInterFrameGap.
Source output impedance zDriver is determined by the driver resistance and the shunt capacitance of the source and
is hence a frequency dependent term. zDriver impacts the noise ingression in the cable. It is specified such that the
noise at the Receiver is bounded.
zDriver is defined by the following equation:

Page 136 USB Power Delivery Specification Revision 2.0, Version 1.1
 𝑟𝑂𝑢𝑡𝑝𝑢𝑡
𝑧𝐷𝑟𝑖𝑣𝑒𝑟 =
1 + 𝑠 ∗ 𝑟𝑂𝑢𝑡𝑝𝑢𝑡 ∗ 𝑐𝑆ℎ𝑢𝑛𝑡

Figure 5-33 Transmitter diagram illustrating zDriver

rOutput

cShunt zDriver

cShunt shall not cause a violation of cReceiver when not transmitting.

5.8.3.6 BMC Receiver Specifications

The receiver shall meet the specifications defined in Table 5-26.

Table 5-26 BMC Receiver Normative Requirements

Name Description Min Nom Max Units Comment
The DFP or UFP system shall
have capacitance within this
cReceiver CC receiver capacitance 200 600 pF
range when not transmitting
on the line.
Number of transitions to be
Transitions for signal
nTransitionCount 3 detected to declare bus non-
detect
idle.
Time constant of a single pole
Rx bandwidth limiting
tRxFilter 100 ns filter to limit broad-band
filter (digital or analog)
noise ingression1.
Time window for
tTransitionWindow 12 20 µs
detecting non-idle
zBmcRx Receiver Input Impedance 1 MΩ
Peak-to-peak noise from VBUS,
USB 2.0 and SBU lines after
Noise amplitude when
vNoiseActive 165 mV the Rx bandwidth limiting
BMC is active.
filter with the time constant
tRxFilter has been applied.
Peak-to-peak noise from VBUS,
USB 2.0 and SBU lines after
Noise amplitude when
vNoiseIdle 300 mV the Rx bandwidth limiting
BMC is idle.
filter with the time constant
tRxFilter has been applied.
As specified in [USBType-C
vIRDropGNDC Cable Ground IR Drop 250 mV
1.0]
Note 1. Broad-band noise ingression is due to coupling in the cable interconnect.

5.8.3.6.1 Definition of Idle

BMC packet collision is avoided by the detection of signal transitions at the receiver. This is the equivalent of squelch
for FSK modulation. Detection is active when nTransitionCount transitions occur at the receiver within a time
window of tTransitionWindow. After waiting tTransitionWindow without detecting nTransitionCount transitions
the bus shall be declared idle.
Refer to Section 5.8.1.4 for details of when transmissions may start.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 137
 5.8.3.6.2 Multi-Drop
The BMC Signaling Scheme is suitable for use in Multi-Drop configurations containing one or two BMC Multi-Drop
transceivers connected to the CC wire, for example where one or both ends of a cable contains a Multi-Drop
transceiver. In this specification the location of the Multi-Drop transceiver is referred to as the Cable Plug.
Figure 5-34 below illustrates a typical Multi Drop configuration with two DRPs.

Figure 5-34 Example Multi-Drop Configuration showing two DRPs

The Multi-Drop transceiver shall obey all the electrical characteristics specified in this section except for those
relating to capacitance. The maximum capacitance allowed for the Multi-Drop node when not driving the line is
cCablePlug. There are no constraints as to the distance of the Multi-Drop transceiver from the end of the plug. The
Multi-Drop transceiver(s) may be located anywhere along the cable including the plugs. The Multi-Drop transceiver
suffers less from ground offset compared to the transceivers in the host or device and contributes no significant
reflections.
Since sourcing VCONN is not mandated for UFPs, it is possible to have a configuration where there is no switch in the
UFP as outlined in Figure 5-35. In this configuration, the capacitance on the CC line contained within the UFP shall
still be within cReceiver except when transmitting.

Figure 5-35 Example Multi-Drop Configuration showing a DFP and UFP

Page 138 USB Power Delivery Specification Revision 2.0, Version 1.1
 5.8.4 Interoperability with BFSK and BMC
In order to interoperate with systems supporting either BFSK or BMC, without requiring an adapter to convert
between the two Signaling Schemes, manufacturers may choose to support both BMC over the CC wire and BFSK over
VBUS on a Type-C connector. Products with Type-C connectors shall not support BFSK without supporting BMC. Note
that any system utilizing the Type-C connector can see BFSK signaling on VBUS when a suitable Type-A/B to Type-C
adapter is used.
When both BMC and BFSK Signaling Schemes are supported by a [USBType-C 1.0] Port:
 A Source shall first attempt to become Connected with its Port Partner, using BMC; the attempt failing when the Source
enters the PE_SRC_Disabled state for a Source (see Section 8.3.3.2).
 If the Source cannot become Connected using BMC then the Source may attempt to become Connected with its Port
Partner using BFSK over VBUS (re-entering the PE_SRC_Startup state for a Source see Section 8.3.3.2).
 A Sink shall be able to receive, in the PE_SNK_Wait_for_Capabilities state (see Section 8.3.3.3), a
Source_Capabilities Message sent either over the CC wire using BMC or over VBUS using BFSK.
 The Sink, after the SinkWaitCapTimer has timed out in the PE_SNK_Wait_for_Capabilities state (see Section 8.3.3.3),
shall issue Hard Reset Signaling over both BMC and BFSK.
 Once the Port Partners are Connected they shall continue to use the same signaling scheme, either BMC or BFSK, until a
Detach or Hard Reset occurs.
 If either Port Partner issues Hard Reset Signaling it shall issue Hard Reset Signaling over both BMC and BFSK.
A Source or DFP may communicate using BMC with a Cable Plug regardless of the Signaling Scheme currently being
used with its Port Partner.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 139
 5.9 Built in Self-Test (BIST)
5.9.1 BIST PRBS Pattern
The generator polynomial for the PRBS-8 pattern shall be x8 + x6 + x5 + x4 + 1.
Figure 5-36 shows an example implementation of the PRBS-generator and checker.
The preloaded pattern shall be "all ones" i.e. all 8 bits in the shift register shall be set to "1". The pattern shall be
preloaded when the request to enter test mode is given or received.

Figure 5-36 Example implementation of the BIST generator and checker

In BIST Transmit or Receiver Test Frames are constructed as shown in Figure 5-37 with a test pattern as defined in
Section 5.9.1. Note that the Test Frame does not include an EOP. At least nBISTConfidence of these Test Frames shall
be sent/received without error (see Section 5.9.1.1).

Figure 5-37 Test Frame

SOP* (Start
Preamble(training for receiver) PRBS-data 1024 bits
Of Packet)

LEGEND:
Preamble, not encoded Provided by the Physical Provided by the Physical layer, not
with 4b5b layer, encoded with 4b5b encoded with 4b5b – 1024 bits

The PRBS data shall be continued without change in the PRBS generator between Test Frames. If the payloads from
all Test Frames were concatenated the resulting stream shall look like it was generated directly by the BIST generator.
The Test Frame shall have a fixed length and the only other signaling that shall be recognized in the test mode is the
Hard Reset Signaling, which shall be used to exit the test mode.
Since the payload length (nBISTPayload) and the BIST pattern cycle length are relatively prime, every pattern will
eventually appear in every position providing a test of all pattern related weaknesses.

Page 140 USB Power Delivery Specification Revision 2.0, Version 1.1
 5.9.1.1 Test Frame Transmission
The number of bits transferred needed to demonstrate the required nBER (see Table 5-27) at a 99% confidence level
is 4.61x106 (see [Maxim37]). To reach this level of confidence, a minimum of nBISTConfidence Test Frames shall be
transmitted. To end the test sequence, Hard Reset Signaling shall be sent.
If errors are detected more bits shall be sent, see [Maxim37]). The number of Test Frames versus the number of
allowable error is given in Table 5-27.

Table 5-27 Allowable Bit Errors vs. Number of Test Frames

N (number of allowable errors) Minimum number of Test Frames required for Confidence level 99%
0 4502
1 6483
2 8209
3 9810
4 11333
5 12802
6 14230
7 15625
8 16995
10 19673
15 26117
20 32328
30 44337

5.9.1.2 Error Counters

The UUT shall maintain a count of errors detected BISTErrorCounter (see Section 6.6.5). The number of errors shall
be compared to the number of errors expected from the number of sent bits and the allowed error rate. Typical
testing would take place at each supported voltage and in the presence of an acceptable noise level.

5.9.2 BIST Carrier Mode 0

In BIST Carrier Mode 0, the Physical Layer shall send out a continuous string of "0"s. This produces a continuous
frequency that will allow measurement of fCarrier - fDeviation.

5.9.3 BIST Carrier Mode 1

In BIST Carrier Mode 1, the Physical Layer shall send out a continuous string of "1"s. This produces a continuous
frequency that will allow measurement of fCarrier + fDeviation.

5.9.4 BIST Carrier Mode 2

In BIST Carrier Mode 2, the Physical Layer shall send out a continuous string of alternating "1"s and “0”s. This
enables the measurement of power supply noise and frequency drift.

5.9.5 BIST Carrier Mode 3

In BIST Carrier Mode 3, the Physical Layer shall send out a continuous string of sixteen "1"s, followed by sixteen “0”s,
followed by sixteen “1”s, etc. This enables the measurement of fCarrier.

5.9.6 BIST Eye Pattern

In BIST Eye Pattern, the Physical Layer shall send out a continuous string of bits in accordance with Section 5.9.1.
This produces a signal that will allow measurement of the eye pattern and of the spectrum mask.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 141
 5.9.7 BIST Test Data
A BIST Test Data Message is used by the Tester to send various Tester generated test patterns to the UUT in order to
test the UUT’s receiver.
Figure 5-38 shows the Test Data Frame which shall be sent by the Tester to the UUT. The BIST Message, with a BIST
Test Data BIST Data Object consists of a Preamble, followed by SOP*, followed by the Message Header with a data
length of 7 Data Objects, followed a BIST Test Data BIST Data Object, followed by 6 Data Objects containing Test data,
followed by the CRC and then an EOP.

Figure 5-38 Test Data Frame

SOP* (Start Header BIST Test Data
Preamble(training for receiver)
Of Packet) Data Objects = 7 BDO Test Data 192 bits ...

... CRC
EOP (End Of
Packet)

LEGEND:

Preamble, not encoded Provided by the Physical Provided by the Protocol

with 4b5b layer, encoded with 4b5b layer, encoded with 4b5b

5.9.8 BIST Parameters

Table 5-28 BIST Parameters

Parameter Description Min Nom Max Units Comment

nBISTConfidence Number of Test Frames to 4502 Frames
transmit in order to reach 99%
confidence level
nBISTPayload Number of bits in a BIST Test 1024 1024 Bits
Frame payload

5.9.9 BIST Test Applicability

Table 5-29 shows the BIST Modes which shall be supported, depending on the Signaling Scheme (BMC or BFSK)
supported by a device.

Table 5-29 BIST Mode support

Test BFSK BMC Comment

BIST Receiver Mode √
BIST Transmit Mode √
BIST Eye Pattern √
BIST Carrier Mode 0 √
BIST Carrier Mode 1 √
BIST Carrier Mode 2 √ √
BIST Carrier Mode 3 √
BIST Test Data √ √

Page 142 USB Power Delivery Specification Revision 2.0, Version 1.1
6. Protocol Layer
6.1 Overview
This chapter describes the requirements of the USB Power Delivery Specification’s protocol layer including:
 Details of how Messages are constructed and used
 Use of timers and timeout values
 Use of Message and retry counters
 Reset operation
 Error handling
 State behavior
Refer to Section 2.5 for an overview of the theory of operation of USB Power Delivery.

6.2 Messages
This specification defines two types of Messages:
 Control Messages that are short and used to manage the Message flow between Port Partners or to exchange
Messages that require no additional data. Control Messages are 16 bits in length.
 Data Messages that are used to exchange information between a pair of Port Partners. Data Messages range from
48 to 240 bits in length. There are three types of Data Messages:
o Those used to expose capabilities and negotiate power
o Those used for the BIST
o Those that are Vendor Defined

6.2.1 Message Construction

All Messages shall be composed of a Message Header and a variable length (including zero) data portion. A Message
either originates in the Protocol Layer and is passed to the Physical Layer, or it is received by the Physical Layer and is
passed to the Protocol Layer.

Figure 6-1 High Level Message Structure

Message Header 0..7 Data Object(s)

Figure 6-2 illustrates the Message as part of a Packet showing the parts are provided by the Protocol and PHY Layers.

Figure 6-2 USB Power Delivery Packet Format including Message Payload

SOP* (Start EOP (End Of

Preamble Message Header 0..7 Data Object(s) CRC
Of Packet) Packet)

Legend:

PHY Layer Protocol Layer

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 143
 6.2.1.1 Message Header
Every Message shall start with a 16-bit Message Header, as shown in Figure 6-1 and defined in Table 6-1. The
Message Header contains basic information about the Message and the PD Port Capabilities. The Message Header may
be used standalone as a Control Message when the Number of Data Objects field is zero or as the first part of a Data
Message when the Number of Data Objects field is non-zero.

Table 6-1 Message Header

Bit(s) Start of Packet Field Name Notes

15 N/A Reserved Shall be set to 0
14..12 SOP* Number of Data Objects See Section 6.2.1.2
11..9 SOP* MessageID See Section 6.2.1.3
SOP only Port Power Role See Section 6.2.1.4
8
SOP’/SOP’’ Cable Plug See Section 6.2.1.7
7..6 SOP* Specification Revision See Section 6.2.1.5
SOP only Port Data Role See Section 6.2.1.6
5
SOP’/SOP’’ Reserved Shall be set to 0
4 N/A Reserved Shall be set to 0
3..0 SOP* Message Type See Section 6.2.1.8

6.2.1.2 Number of Data Objects

The 3-bit Number of Data Objects field shall indicate the number of 32-bit Data Objects that follow the Message
Header. When this field is zero the Message is a Control Message and when it is non-zero, the Message is a Data
Message.
The Number of Data Objects field shall apply to all SOP* Packet types.

6.2.1.3 MessageID
The 3-bit MessageID field is the value generated by a rolling counter maintained by the originator of the Message.
The MessageIDCounter shall be initialized to zero at power-on as a result of a Soft Reset, or a Hard Reset. The
MessageIDCounter shall be incremented when a Message is successfully received as indicated by receipt of a
GoodCRC Message. Note: during BIST, when sending Test Frames, the MessageID is not incremented by the sender
and is Ignored by the receiver.
The MessageID field shall apply to all SOP* Packet types.

6.2.1.4 Port Power Role

The 1-bit Port Power Role field shall indicate the current power role of the Port:
 0b Sink
 1b Source
Messages, such as Ping, and GotoMin, that are only ever sent by a Source, shall always have the Port Power Role field
set to Source. Similarly Messages such as Request that are only ever sent by a Sink shall always have the Port Power
Role field set to Sink.
During the Power Role Swap Sequence, for the initial Source Port, the Port Power Role field shall be set to Sink in the
PS_RDY Message indicating that the initial Source’s power supply is turned off (see Figure 8-6 and Figure 8-7).
During the Power Role Swap Sequence, for the initial Sink Port, the Port Power Role field shall be set to Source for
Messages initiated by the Policy Engine after receiving the PS_RDY Message from the initial Source (see Figure 8-6 and
Figure 8-7).

Page 144 USB Power Delivery Specification Revision 2.0, Version 1.1
Note that the GoodCRC Message sent by the initial Sink in response to the PS_RDY Message from the initial Source will
have its Port Power Role field set to Sink since this is initiated by the Protocol Layer. Subsequent Messages initiated
by the Policy Engine, such as the PS_RDY Message sent to indicate that VBUS is ready, will have the Port Power Role
field set to Source.
The Port Power Role field of a received Message shall not be verified by the receiver and no error recovery action
shall be taken if it is incorrect.
The Port Power Role field shall only be defined for SOP Packets.

6.2.1.5 Specification Revision

The 2-bit Specification Revision field shall indicate the revision of the Power Delivery Specification supported by the
Device.
 00b –Revision 1.0
 01b –Revision 2.0
 10b - 11b – Reserved, shall not be used
On receipt of a Message Header with a higher revision number than that supported, a Port shall respond using the
highest revision number it supports.
The Specification Revision field shall apply to all SOP* Packet types.

6.2.1.6 Port Data Role

The 1-bit Port Data Role field shall indicate the current data role of the Port:
 0b UFP
 1b DFP
The Port Data Role field shall only be defined for SOP Packets. For all other SOP* Packets the Port Data Role field is
Reserved and shall be set to zero.
Should a Type-C Port receive a Message with the Port Data Role field set to the same Data Role as its current Data
Role, except for the GoodCRC Message, Type-C error recovery actions as defined in [USBType-C 1.0] shall be
performed.
For a Type-C Port the Port Data Role field shall be set to the default value at attachment after a Hard Reset: 0b for a
Port with Rd asserted and 1b for a Port with Rp asserted.

6.2.1.7 Cable Plug

The 1-bit Cable Plug field shall indicate whether this Message originated from a Cable Plug:
 0b Message originated from a DFP or UFP
 1b Message originated from a Cable Plug
The Cable Plug field shall only apply to SOP’ and SOP’’ Packet types.

6.2.1.8 Message Type

The 4-bit Message Type field shall indicate the type of Message being sent. To fully decode the Message Type, the
Number of Data Objects field is first examined to determine whether the Message is a Control Message or a Data
Message. Then the specific Message Type can be found in Table 6-2 (Control Message) or Table 6-3 (Data Message).
The Message Type field shall apply to all SOP* Packet types.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 145
 6.3 Control Message
A Message is defined as a Control Message when the Number of Data Objects field in the Message Header is set to 0.
The Control Message consists only of a Message Header and a CRC. The Protocol Layer originates the Control
Messages (i.e. Accept Message, Reject Message etc.).
The Control Message types are specified in the Message Header’s Message Type field (bits 3...0) and are summarized
in Table 6-2. The Sent by column indicates entities which may send the given Message (Source, Sink or Cable Plug);
entities not listed shall not issue the corresponding Message. The “Valid Start of Packet” column indicates the
Messages which shall only be issued in SOP Packets and the Messages which may be issued in SOP* Packets.

Table 6-2 Control Message Types

Bits 3..0 Message Type Sent by Description Valid Start of

Packet
0000 Reserved N/A All values not explicitly defined are
Reserved and shall not be used.
0001 GoodCRC Source, Sink or Cable Plug See Section 6.3.1. SOP*
0010 GotoMin Source only See Section 6.3.2. SOP only
0011 Accept Source, Sink or Cable Plug See Section 6.3.3. SOP*
0100 Reject Source or Sink See Section 6.3.4. SOP only
0101 Ping Source only See Section 6.3.5. SOP*
0110 PS_RDY Source or Sink See Section 6.3.6. SOP only
0111 Get_Source_Cap Source or Sink See Section 6.3.7. SOP only
1000 Get_Sink_Cap Source or Sink See Section 6.3.8. SOP only
1001 DR_Swap Source or Sink See Section 6.3.9 SOP only
1010 PR_Swap Source or Sink See Section 6.3.10. SOP only
1011 VCONN_Swap Source or Sink See Section 6.3.11 SOP only
1100 Wait Source or Sink See Section 6.3.12 SOP only
1101 Soft_Reset Source or Sink See Section 6.3.13. SOP*
1110- Reserved N/A All values not explicitly defined are
1111 Reserved and shall not be used.

6.3.1 GoodCRC Message

The GoodCRC Message shall be sent by the receiver to acknowledge that the previous Message was correctly received
(i.e. had a good CRC). The GoodCRC Message shall return the Message’s MessageID so the transmitter can determine
that the correct Message is being acknowledged. The first bit of the GoodCRC Message shall be returned within
tTransmit after receipt of the last bit of the previous Message.
BIST does not send the GoodCRC Message during the data stream (see Section 6.4.3).

6.3.2 GotoMin Message

The GotoMin Message applies only to those Sinks that have requested power with the GiveBack capable flag set in the
Sink Request Data Object.
It is a directive to the Sink Port to reduce its operating power level to the amount specified in the Minimum Operating
Current field of its latest Sink Request Data Object.
The GotoMin process is designed to allow the Source to temporarily reallocate power to meet a short term
requirement. For example, a Source may reduce a Sink’s power consumption for 10-20 seconds to allow another Sink
(e.g. an HDD to spin up).

Page 146 USB Power Delivery Specification Revision 2.0, Version 1.1
The Source sends this Message as a means to harvest power in order to meet a request for power that it cannot
otherwise meet. The Device Policy Manager determines which Port or ports will receive the Message.
The Sink shall respond to a GotoMin Message by reducing its power consumption to less than or equal to the pre-
negotiated value (Minimum Operating Current) within tSnkNewPower time.
The Source sends a GotoMin Message as a shortcut in the power negotiation process since the Source and Sink have
already made a Contract with respect to the power to be returned. In essence, the Source does not have to advertise
its Capabilities and the Sink does not have to make a Request based on them. The Source simply sends the GotoMin
Message in place of the Accept Message normally sent during the power negotiation process (see step 19 in Figure
8-5). The power negotiation process then completes from this point in the normal manner with the Source sending a
PS_RDY Message once the power supply transition is complete. The steps of the GotoMin process are fully described
in Figure 8-6.
The Source shall return power to the Sink(s) it has ‘borrowed’ from using the GotoMin mechanism before it can
allocate any ‘new’ power to other devices.

6.3.3 Accept Message

The Accept Message is a valid response in the following cases:
 It shall be sent by the Source to signal the Sink that the Source is willing to meet the Request Message.
 It shall be sent by the recipient of the PR_Swap Message to signal that it is willing to do a Power Role Swap and
has begun the Power Role Swap sequence.
 It shall be sent by the recipient of the DR_Swap Message to signal that it is willing to do a Data Role Swap and has
begun the Data Role Swap sequence.
 It shall be sent by the recipient of the VCONN_Swap Message to signal that it is willing to do a VCONN Swap and has
begun the VCONN Swap sequence.
 It shall be sent by the recipient of the Soft_Reset Message to indicate that it has completed its Soft Reset.
The Accept Message shall be sent within tReceiverResponse of the receipt of the last bit of the Message (see Section
6.5.2).

6.3.4 Reject Message

The Reject Message is a valid response in the following cases:
 It shall be sent to signal the Sink that the Source is unable to meet the Request Message. This may be due an
invalid request or because the Source can no longer provide what it previously advertised.
 It shall be sent by the recipient of a PR_Swap Message to indicate it is unable to do a Power Role Swap.
 It shall be sent by the recipient of a DR_Swap Message to indicate it is unable to do a Data Role Swap.
 It shall be sent by the recipient of a VCONN_Swap Message to indicate it is unable to do a VCONN Swap.
 It shall be sent by a Source without Dual-Role capability in response to a Get_Sink_Cap Message.
 It shall be sent by a Sink without Dual-Role capability in response to a Get_Source_Cap Message.
The Reject Message shall be sent within tReceiverResponse of the receipt of the last bit of Message (see Section
6.5.2).

6.3.5 Ping Message

6.3.5.1 Pings on Type-A and Type-B connectors
The Ping Message is used on Type-A and Type-B connectors to determine the continued presence of the Sink when no
other messaging is taking place (see Figure 8-38 in Section 8.3). The Ping Message is sent periodically, every
tSourceActivity, by the Source to the Sink.
Once a Contract is established Sources shall periodically send the Ping Message every tSourceActivity after the last
Message has been sent/received except when:

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 147
 The system is not operating in USB Power Delivery Mode (i.e. in standard [USB 2.0], [USB 3.1], [USBType-C 1.0]
or [BC 1.2] operation).
 A Provider or Provider/Consumer is operating as a Source at vSafe5V in the PE_SRC_Ready state (i.e. power
negotiation has already taken place see Section 8.3.3.2.6).

6.3.5.2 Pings on Type-C Connectors

Type-C connectors have an alternative mechanism to determine Sink presence so when the Port Partners are both
connected using Type-C connectors the Ping Message is not necessary. A Sink using a Type-C connector shall not
expect to receive Ping Messages but shall not treat Ping Messages as an error if they are received.

6.3.6 PS_RDY Message

The PS_RDY Message shall be sent by the Source (or by both the new Sink and new Source during the Power Role
Swap sequence) to indicate its power supply has reached the desired operating condition. See Section 8.3.2.3 or
Section 8.3.2.7.1.2 for examples of use.

6.3.7 Get_Source_Cap Message

The Get_Source_Cap (Get Source Capabilities) Message may be sent by a Port to request the Source Capabilities and
Dual-Role capability of its Port Partner (e.g. Dual-Role capable). The Port shall respond by returning a
Source_Capabilities Message (see Section 6.4.1.1.1). A Sink Port, without Dual-Role capability, shall return a Reject
Message.

6.3.8 Get_Sink_Cap Message

The Get_Sink_Cap (Get Sink Capabilities) Message may be sent by a Port to request the Sink Capabilities and Dual-Role
capability of its Port Partner (e.g. Dual-Role capable). The Port shall respond by returning a Sink_Capabilities
Message (see Section 6.4.1.1.2). A Source Port, without Dual-Role capability, shall return a Reject Message.

6.3.9 DR_Swap Message

The DR_Swap Message is used to exchange DFP and UFP operation between Port Partners both utilizing Type-C
connectors while maintaining the direction of power flow over VBUS. The DR_Swap process can be used by [USBType-
C 1.0] Port Partners whether or not they support USB Communications capability. A DFP that supports USB
Communication Capability starts as the USB Host on attachment of [USBType-C 1.0] Ports. A UFP that supports USB
Communication Capability starts as the USB Device on attachment of [USBType-C 1.0] Ports.
The DFP is the “bus master” for Vendor Defined Message communications so the DR_Swap Message is used to
exchange the Port Partner responsible for this communication.
[USBType-C 1.0] DRPs shall have the capability to perform a Data Role Swap from the PE_SRC_Ready or
PE_SNK_Ready states. [USBType-C 1.0] DFPs and [USBType-C 1.0] UFPs may have the capability to perform a Data
Role Swap from the PE_SRC_Ready or PE_SNK_Ready states. A Data Role Swap shall be regarded in the same way as a
cable detach/reattach in relation to any USB communication which is ongoing between the Port Partners. If there are
any Active Modes between the Port Partners when a DR_Swap Message is a received then a Hard Reset shall be
performed (see Section 6.4.4.3.4). If the Cable Plug has any Active Modes then the DFP shall not issue a DR_Swap
Message and shall cause all Active Modes in the Cable Plug to be exited before accepting a DR Swap request.
The Source of VBUS and VCONN Source shall remain unchanged as well as the Rp/Rd resistors on the CC wire during the
Data Role Swap process.
The DR_Swap Message may be sent by either Port Partner. The recipient of the DR_Swap Message shall respond by
sending an Accept Message, Reject Message or Wait Message.
 If an Accept Message is sent, the Source and Sink shall exchange operational roles.
 If a Reject Message is sent, the requester is informed that the recipient is unable, or unwilling, to do a Data Role
Swap and no action shall be taken.

Page 148 USB Power Delivery Specification Revision 2.0, Version 1.1
 If a Wait Message is sent, the requester is informed that a Data Role Swap might be possible in the future but that
no immediate action shall be taken.
Before a Data Role Swap the initial DFP shall have its Port Data Role bit set to DFP, and the initial UFP shall have its
Port Data Role bit set to UFP.
After a successful Data Role Swap the DFP/Host shall become the UFP/Device and vice-versa; the new DFP shall have
its Port Data Role bit set to DFP, and the new UFP shall have its Port Data Role bit set to UFP. Where USB
Communication is supported by both Port Partners a USB data connection should be established according to the new
data roles.
If the Data Role Swap, after having been accepted by the Port Partner, is subsequently not successful, in order to
attempt a re-establishment of the connection on the CC Wire, Type-C error recovery actions, such as disconnect, as
defined in [USBType-C 1.0] will be necessary.
See Sections 0, 8.3.3.6.2.1 and 8.3.3.6.2.2 for further details.

6.3.10 PR_Swap Message

The PR_Swap Message may be sent by either Port Partner to request an exchange of power roles. The recipient of the
Message shall respond by sending an Accept Message, Reject Message or Wait Message.
 If an Accept Message is sent, the Source and Sink shall do a Power Role Swap.
 If a Reject Message is sent, the requester is informed that the recipient is unable, or unwilling, to do a Power Role
Swap and no action shall be taken.
 If a Wait Message is sent, the requester is informed that a Power Role Swap might be possible in the future but
that no immediate action shall be taken.
After a successful Power Role Swap the Port Partners shall reset their respective Protocol Layers (equivalent to a Soft
Reset): resetting their MessageIDCounter, RetryCounter and Protocol Layer state machines before attempting to
establish an Explicit Contract. At this point the Source shall also reset its CapsCounter.
Since a UFP Source can attempt to send a Discover Identity Command using SOP’ to a Cable Plug prior to the
establishment of an Explicit Contract, a DFP Sink shall disable the receiving of SOP’ Messages until an Explicit Contract
has been established. This ensures that only the Cable Plug responds with a GoodCRC Message to the Discover Identity
Command.
For Type-C Ports the Source shall have Rp asserted on the CC wire and the Sink shall have Rd asserted on the CC wire.
When performing a Power Role Swap from Source to Sink, a Type-C Port shall change its CC Wire resistor from Rp to
Rd. When performing a Power Role Swap from Sink to Source, a Type-C Port shall change is CC Wire resistor from Rd
to Rp. The DFP (Host), UFP (Device) roles and VCONN Source shall remain unchanged during the Power Role Swap
process.
For more information regarding the Power Role Swap, refer to Sections 7.3.9 and 7.3.10 in the Power Supply chapter,
Sections 8.3.2.7.1, 8.3.2.8.1, 8.3.3.6.3.1 and 8.3.3.6.3.2 in the Device Policy chapter and Section 9.1.2 for VBUS mapping
to USB states.

6.3.11 VCONN_Swap Message

The VCONN_Swap Message shall be supported by any Type-C Port that that utilizes the SSTX and SSRX pins and
supports the PR_Swap Message.
The VCONN_Swap Message may be sent by either Port Partner to request an exchange of VCONN Source. The recipient
of the Message shall respond by sending an Accept Message, Reject Message or Wait Message.
 If an Accept Message is sent, the Port Partners shall perform a VCONN Swap. The new VCONN Source shall send a
PS_RDY Message within tVCONNSourceOn to indicate that it is now sourcing VCONN. The initial VCONN Source
shall cease sourcing VCONN within tVCONNSourceOff of receipt of the last bit of the EOP of the PS_RDY Message.
 If a Reject Message is sent, the requester is informed that the recipient is unable, or unwilling, to do a VCONN Swap
and no action shall be taken.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 149
 If a Wait Message is sent, the requester is informed that a VCONN Swap might be possible in the future but that no
immediate action shall be taken.
The DFP (Host), UFP (Device) roles and Source of VBUS shall remain unchanged as well as the Rp/Rd resistors on the CC
wire during the VCONN Swap process.
Note: VCONN shall be continually sourced during the VCONN Swap process in order to maintain power to the Cable
Plug(s) i.e. make before break.

6.3.12 Wait Message

The Wait Message is a valid response to a Request, a PR_Swap, DR_Swap or VCONN_Swap Message.
 It shall be sent to signal the Sink that the Source is unable to meet the request at this time.
 It shall be sent by the recipient of a PR_Swap Message to indicate it is unable to do a Power Role Swap at this time.
 It shall be sent by the recipient of a DR_Swap Message to indicate it is unable to do a Data Role Swap at this time.
 It shall be sent by the recipient of a VCONN_Swap Message to indicate it is unable to do a VCONN Swap at this time.
The Wait Message shall be sent within tReceiverResponse of the receipt of the last bit of the Message (see Section
6.5.2).

6.3.12.1 Wait in response to a Request Message

The Wait Message is used by the Source when a Sink that has reserved power, requests it. The Wait Message allows
the Source time to recover the power it requires to meet the request through the GotoMin process. A Source shall
only send a Wait Message in response to a Request Message when an Explicit Contract exists between the Port
Partners.
The Sink is allowed to repeat the Request Message using the SinkRequestTimer to ensure that there is tSinkRequest
between requests.

6.3.12.2 Wait in response to a PR_Swap Message

The Wait Message is used when responding to a PR_Swap Message to indicate that a Power Role Swap might be
possible in the future. This can occur in any case where the device receiving the PR_Swap Message needs to evaluate
the request further e.g. by requesting Capabilities from the originator of the PR_Swap Message. Once it has completed
this evaluation one of the Port Partners should initiate the Power Role Swap process again by sending a PR_Swap
Message.
The Wait Message is also used where a Hub is operating in intrusive mode or in hybrid mode when a request cannot
be satisfied (see Section 9.4.5). In this case the Hub shall send a Wait Message in response to a PR_Swap Message
from its Port Partner. Once the System Policy Manager has completed its evaluation of the request the Hub should
initiate the Power Role Swap process again by sending a PR_Swap Message.

6.3.12.3 Wait in response to a DR_Swap Message

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

6.3.12.4 Wait in response to a VCONN_Swap Message

The Wait Message is used when responding to a VCONN_Swap Message to indicate that a VCONN Swap might be
possible in the future. This can occur in any case where the device receiving the VCONN_Swap Message needs to
evaluate the request further. Sender of the VCONN_Swap Message should initiate the VCONN Swap process again at a
future time by resending a VCONN_Swap Message.

Page 150 USB Power Delivery Specification Revision 2.0, Version 1.1
 6.3.13 Soft Reset Message
A Soft_Reset Message may be initiated by either the Source or Sink to its Port Partner requesting a Soft Reset. The
Soft_Reset Message shall cause a Soft Reset of the connected Port Pair (see Section 6.7.1). If the Soft_Reset Message
fails a Hard Reset shall be initiated within tHardReset of the last CRCReceiveTimer expiring after nRetryCount
retries have been completed.
A Soft_Reset Message is used to recover from Protocol Layer errors; putting the Message counters to a known state in
order to regain Message synchronization. The Soft_Reset Message has no effect on the Source or Sink; that is the
previously negotiated direction. Voltage and current remain unchanged. Modal Operation is unaffected by Soft Reset.
However after a Soft Reset has completed, an Explicit Contract negotiation occurs, in order to re-establish PD
Communication and to bring state operation for both Port Partners back to either the PE_SNK_Ready or
PE_SRC_Ready states as appropriate (see Section 8.3.3.4).
A Soft_Reset Message may be sent by either the Source or Sink when there is a Message synchronization error. If the
error is not corrected by the Soft Reset, Hard Reset Signaling shall be issued (see Section 6.7).
A Soft_Reset Message shall be targeted at a specific entity depending on the type of SOP* Packet used. Soft_Reset
Messages sent using SOP Packets shall Soft Reset the Port Partner only. Soft_Reset Messages sent using SOP’/SOP’’
Packets shall Soft Reset the corresponding Cable Plug only.
If, after a Power or Data Role Swap, a different Port starts to communicate with a given Cable Plug, the Cable Plug’s
Protocol Layer needs to be reset in order to ensure MessageID synchronization. If the Source or DFP wants to
communicate with a Cable Plug using SOP’ Packets it shall issue a Soft_Reset Message using a SOP’ Packet in order to
reset the Cable Plug’s Protocol Layer. If the Source or DFP wants to communicate with a Cable Plug using SOP’’
Packets it shall issue a Soft_Reset Message using a SOP’’ Packet in order to reset the Cable Plug’s Protocol Layer.

6.4 Data Message

A Data Message shall consist of a Message Header and be followed by one or more Data Objects. Data Messages are
easily identifiable because the Number of Data Objects field in the Message Header is a non-zero value.
There are several types of Data Objects:
 BIST Data Object (BDO) used for PHY Layer compliance testing
 Power Data Object (PDO) used to expose a Source Port’s power capabilities or a Sink’s power requirements
 Request Data Object (RDO) used by a Sink Port to negotiate a Contract
 Vendor Defined Data Object (VDO) used to convey vendor specific information
The type of Data Object being used in a Data Message is defined by the Message Header’s Message Type field and is
summarized in Table 6-3. The Sent by column indicates entities which may send the given Message (Source, Sink or
Cable Plug); entities not listed shall not issue the corresponding Message. The Valid Start of Packet column indicates
the Messages which shall only be issued in SOP Packets and the Messages which may be issued in SOP* Packets.

Table 6-3 Data Message Types

Bits 3..0 Type Sent by Description Valid Start of

Packet
0000 Reserved All values not explicitly defined are
Reserved and shall not be used.
0001 Source_Capabilities Source or Dual-Role See Section 6.4.1.2 SOP only
0010 Request Sink only See Section 6.4.2 SOP only
0011 BIST Tester, Source or See Section 6.4.3 SOP*
Sink
0100 Sink_Capabilities Sink or Dual-Role See Section 6.4.1.3 SOP only
0101-1110 Reserved All values not explicitly defined are
Reserved and shall not be used.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 151
Bits 3..0 Type Sent by Description Valid Start of
Packet
1111 Vendor_Defined Source, Sink or Cable See Section 6.4.4 SOP*
Plug

6.4.1 Capabilities Message

A Capabilities Message (Source_Capabilities Message or Sink_Capabilities Message) shall have at least one Power
Data Object for vSafe5V. The Capabilities Message shall also contain the sending Port’s information followed by up to
6 additional Power Data Objects. Power Data Objects in a Capabilities Message shall be sent in the following order:
1. The vSafe5V Fixed Supply Object shall always be the first object.
2. The remaining Fixed Supply Objects, if present, shall be sent in voltage order; lowest to highest.
3. The Battery Supply Objects, if present shall be sent in Minimum Voltage order; lowest to highest.
4. The Variable Supply (non-battery) Objects, if present, shall be sent in Minimum Voltage order; lowest to highest.

Figure 6-3 Example Capabilities Message with 2 Power Data Objects

Header
Object1 Object2
No. of Data Objects = 2

In Figure 6-3, the Number of Data Objects field is 2: vSafe5V plus one other voltage.
Power Data Objects (PDO) are identified by the Message Header’s Type field. They are used to form
Source_Capabilities Messages and Sink_Capabilities Messages.
There are three types of Power Data Objects. They contain additional information beyond that encoded in the
Message Header to identify each of the three types of Power Data Objects:
 Fixed Supply is the most commonly used to expose well regulated fixed voltage power supplies.
 Variable power supply is used to expose very poorly regulated power supplies.
 Battery is used to expose batteries than can be directly connected to VBUS.
Power Data Objects are also used to expose additional capabilities that may be utilized; such as in the case of a Power
Role Swap.
A list of one or more Power Data Objects shall be sent by the Source in order to convey its capabilities. The Sink may
then request one of these capabilities by returning a Request Data Object that contains an index to a Power Data
Object, in order to negotiate a mutually agreeable Contract.
Where Maximum and Minimum Voltage and Current values are given in PDOs these shall be taken to be absolute
values.
The Source and Sink shall not negotiate a power level that would allow the current to exceed the maximum current
supported by their receptacles or the attached plug (see Section 3.1.1 and [USBType-C 1.0]). The Source shall limit its
offered capabilities to the maximum current supported by its receptacle and attached plug. A Sink with a Type-A or a
Type-B receptacle shall limit its requested capabilities to the maximum current supported by its receptacle and
attached plug. A Sink with a Type-C receptacle may make a request from any of the capabilities offered by the Source.
For further details see Section 4.4.
Sources expose their power capabilities by sending a Source_Capabilities Message. Sinks expose their power
requirements by sending a Sink_Capabilities Message. Both are composed of a number of 32-bit Power Data Objects
(see Table 6-4).

Page 152 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 6-4 Power Data Object

Bit(s) Description
B31..30 Value Parameter
00b Fixed supply (Vmin = Vmax)
01b Battery
10b Variable Supply (non-battery)
11b Reserved
B29..0 Specific Power Capabilities are described by the PDOs in the following sections.

6.4.1.1 Use of the Capabilities Message

6.4.1.1.1 Use by Sources

Sources send a Source_Capabilities Message (see Section 6.4.1) either as part of advertising Port capabilities, or in
response to a Get_Source_Cap Message.
Following a Hard Reset, a power-on event or plug insertion event, a Source Port shall send a Source_Capabilities
Message after every SourceCapabilityTimer timeout as an advertisement that shall be interpreted by the Sink Port on
attachment. The Source shall continue sending a minimum of nCapsCount Source_Capabilities Messages until a
GoodCRC Message is received.
Additionally, a Source_Capabilities Message shall only be sent in the following cases:
 By the Source Port from the PE_SRC_Ready state upon a change in its ability to supply power
 By a Source Port or Dual-Role Port in response to a Get_Source_Cap Message

6.4.1.1.2 Use by Sinks

Sinks send a Sink_Capabilities Message (see Section 6.4.1.3) in response to a Get_Sink_Cap Message.
A USB Power Delivery capable Sink, upon detecting vSafe5V on VBUS and after a SinkWaitCapTimer timeout without
seeing a Source_Capabilities Message, shall send a Hard Reset. If the attached Source is USB Power Delivery capable,
it responds by sending Source_Capabilities Messages thus allowing power negotiations to begin.

6.4.1.1.3 Use by Dual-Role devices

Dual-Role devices send a Source_Capabilities Message (see Section 6.4.1) as part of advertising Port capabilities
when operating in Source role. Dual-Role devices send a Source_Capabilities Message (see Section 6.4.1) in response
to a Get_Source_Cap Message regardless of their present operating role. Similarly Dual-Role devices send a
Sink_Capabilities Message (see Section 6.4.1.3) in response to a Get_Sink_Cap Message regardless of their present
operating role.

6.4.1.2 Source_Capabilities Message

A Source Port shall report its capabilities in a series of 32-bit Power Data Objects (see Table 6-4) as part of a
Source_Capabilities Message (see Figure 6-3). Power Data Objects are used to convey a Source Port’s capabilities to
provide power including Dual-Role ports presently operating as a Sink.
Each Power Data Object shall describe a specific Source capability such as a battery (e.g. 2.8-4.1V) or a fixed power
supply (e.g. 12V) at a maximum allowable current. The Number of Data Objects field in the Message Header shall
define the number of Power Data Objects that follow the Message Header in a Data Message. All Sources shall
minimally offer one Power Data Object that reports vSafe5V. A Source shall not offer multiple Power Data Objects of
the same type (fixed, variable, battery) and the same voltage but shall instead offer one Power Data Object with the
highest available current for that Source capability and voltage. DRPs that support VCONN Powered Accessories do not
source VBUS (see [USBType-C 1.0]) however when sourcing VCONN they shall advertise vSafe5V with the Maximum
Current set to 0mA in the first Power Data Object.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 153
A Sink shall evaluate every Source_Capabilities Message it receives and shall respond with a Request Message. If its
power consumption exceeds the Source’s capabilities it shall re-negotiate so as not to exceed the Source’s most
recently advertised capabilities.

6.4.1.2.1 Management of the Power Reserve

A Power Reserve may be allocated to a Sink when it makes a request from Source Capabilities which includes a
Maximum Operating Current/Power. The size of the Power Reserve for a particular Sink is calculated as the
difference between its Maximum Operating Current/Power field and its Operating Current/Power field. For a Hub
with multiple ports this same Power Reserve may be shared between several Sinks. The Power Reserve may also be
temporarily used by a Sink which has indicated it can give back power by setting the GiveBack flag.
Where a Power Reserve has been allocated to a Sink the Source shall indicate the Power Reserve as part of every
Source_Capabilities Message it sends. When the same Power Reserve is shared between several Sinks the Source
shall indicate the Power Reserve as part of every Source_Capabilities Message it sends to every Sink. Every time a
Source sends capabilities including the Power Reserve capability and then accepts a request from a Sink including the
Power Reserve indicated by its Maximum operating Current/Power it is confirming that the Power Reserve is part of
the Explicit Contract with the Sink.
When the Reserve is being temporarily used by a giveback capable Sink the Source shall indicate the Power Reserve
as available in every Source_Capabilities Message it sends. However in this situation, when the Power Reserve is
requested by a Sink, the Source shall return a Wait Message while it retrieves this power using a GotoMin Message.
Once the additional power has been retrieved the Source shall send a new Source_Capabilities Message in order to
trigger a new request from the Sink requesting the Power Reserve.
The Power Reserve may be de-allocated by the Source at any time, but the de-allocation shall be indicated to the Sink
or Sinks using the Power Reserve by sending a new Source_Capabilities Message.

6.4.1.2.2 Non-Standard attachment of Type-A Ports

When a Provider/Consumer Port, with a Type-A receptacle, that is operating as a Source receives an unexpected
Source_Capabilities Message (e.g. one not in response to a Get_Source_Cap Message), it shall silently remove vSafe5V
from VBUS within tPSSourceOff of receiving the Source_Capabilities Message EOP. Reception of a Source_Capabilities
Message indicates that the user has attached two Type-A Ports together via non-standard cabling so VBUS is removed
to prevent back-powering.
Table 6-5 shows the behavior of various combinations of Type-A Ports when attached in a non-standard
configuration.

Table 6-5 Type-A to Type-A Port Behavior

Port 1 Port 2 Description

Provider/Consumer Provider/Consumer Either Port 1 or Port 2 will remove VBUS depending on
which sends its Capabilities first.
Provider/Consumer Provider Port 1 will silently remove vSafe5V from VBUS
Provider Provider Safe operation (see Section 7.1.8).
Provider/Consumer Legacy host Safe operation (see Section 7.1.8).
Legacy host Legacy host Outside scope of this specification

6.4.1.2.3 Source Fixed Supply Power Data Object

Table 6-6 describes the Fixed Supply (00b) PDO. See Section 7 for the electrical requirements of the power supply.
Since all USB Providers support vSafe5V, the required vSafe5V Fixed Supply Power Data Object is also used to convey
additional information that is returned in bits 29 through 25. All other Fixed Supply Power Data Objects shall set bits
29...22 to zero.

Page 154 USB Power Delivery Specification Revision 2.0, Version 1.1
For a Source offering no capabilities, the Voltage (B19..10) shall be set to 5V and the Maximum Current shall be set to
0mA. This is used in cases such as a Dual-Role device which offers no capabilities in its default role or when external
power is required in order to offer power.
When a Source wants a Sink, consuming power from VBUS, to go to its lowest power state, the Voltage (B19..10) shall
be set to 5V and the Maximum Current shall be set to 0mA. This is used in cases where the Source wants the Sink to
draw pSnkSusp.

Table 6-6 Fixed Supply PDO - Source

Bit(s) Description
B31..30 Fixed supply
B29 Dual-Role Power
B28 USB Suspend Supported
B27 Externally Powered
B26 USB Communications Capable
B25 Data Role Swap
B24..22 Reserved – shall be set to zero.
B21..20 Peak Current
B19..10 Voltage in 50mV units
B9..0 Maximum Current in 10mA units

6.4.1.2.3.1 Dual-Role Power

The Dual-Role Power bit shall be set when the Port is Dual-Role Power capable i.e. supports the PR_Swap Message.
This is a static capability which shall remain fixed for a given device.

6.4.1.2.3.2 USB Suspend Supported

Prior to a Contract or when the USB Communications Capable bit is set to zero, this flag is undefined and Sinks shall
follow the rules for suspend as defined in [USB 2.0], [USB 3.1], [USBType-C 1.0] or [BC 1.2]. After a Contract has been
negotiated:
 If the USB Suspend Supported flag is set, then the Sink shall follow the [USB 2.0] or [USB 3.1] rules for suspend
and resume. A PDUSB Peripheral may draw up to pSnkSusp during suspend; a PDUSB Hub may draw up to
pHubSusp during suspend (see Section 7.2.4).
 If the USB Suspend Supported flag is cleared, then the Sink shall not apply the [USB 2.0] or [USB 3.1] rules for
suspend and may continue to draw the negotiated power. Note that when USB is suspended, the USB device state is
also suspended.
Sinks may indicate to the Source that they would prefer to have the USB Suspend Supported flag cleared by setting the
No USB Suspend flag in a Request Message (see Section 6.4.2.5).

6.4.1.2.3.3 Externally Powered

The Externally Powered bit shall only be set when an AC “wall” supply is providing 100% of the Source’s power.
This means that either:
 There is an AC supply, e.g. a wall wart, directly connected to the Source.
 Or, in the case of a PDUSB Hub:
o The Hub is receiving 100% of its power from a PD Source with its Externally Powered bit set.
o The Hub is receiving 100% of its power from multiple PD Sources all with their Externally Powered bits
set.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 155
 6.4.1.2.3.4 USB Communications Capable
The USB Communications Capable bit shall only be set for devices capable of communication over the USB data lines
(e.g. D+/- or SS Tx/Rx).

6.4.1.2.3.5 Data Role Swap

The Data Role Swap bit shall be set when the Port is Type-C (see [USBType-C 1.0]) and supports the DR_Swap
Message. This is a static capability which shall remain fixed for a given device.

6.4.1.2.3.6 Peak Current

The USB Power Delivery Fixed Supply is only required to deliver the amount of current requested in the Operating
Current (IOC) field of an RDO. In some usages however, for example computer systems, where there are short bursts
of activity, it may be desirable to overload the power source for short periods.
For example when a computer system tries to maintain average power consumption, the higher the peak current, the
longer the low current (see Section 7.2.8) period needed to maintain such average power. The Peak Current field
allows a power source to advertise this additional capability. This capability is intended for direct Port to Port
connections only and shall not be offered to downstream Sinks via a Hub.
Every Fixed Supply PDO shall contain a Peak Current field. Supplies that want to offer a set of overload capabilities
shall advertise this through the Peak Current field in the corresponding Fixed Supply PDO (see Table 6-7). Supplies
that do not support an overload capability shall set these bits to 00b in the corresponding Fixed Supply PDO.

Table 6-7 Fixed Power Source Peak Current Capability

Bits 21..20 Description

00 Peak current equals IOC (default)
01 Overload Capabilities:
1. Peak current equals 150% IOC for 1ms @ 5% duty cycle (low current equals 97% IOC for
19ms)
2. Peak current equals 125% IOC for 2ms @ 10% duty cycle (low current equals 97% IOC for
18ms)
3. Peak current equals 110% IOC for 10ms @ 50% duty cycle (low current equals 90% IOC for
10ms)
10 Overload Capabilities:
1. Peak current equals 200% IOC for 1ms @ 5% duty cycle (low current equals 95% IOC for
19ms)
2. Peak current equals 150% IOC for 2ms @ 10% duty cycle (low current equals 94% IOC for
18ms)
3. Peak current equals 125% IOC for 10ms @ 50% duty cycle (low current equals 75% IOC for
10ms)
11 Overload Capabilities:
1. Peak current equals 200% IOC for 1ms @ 5% duty cycle (low current equals 95% IOC for
19ms)
2. Peak current equals 175% IOC for 2ms @ 10% duty cycle (low current equals 92% IOC for
18ms)
3. Peak current equals 150% IOC for 10ms @ 50% duty cycle (low current equals 50% IOC for
10ms)

6.4.1.2.4 Variable Supply (non-battery) Power Data Object

Table 6‑9 describes a Variable Supply (non-battery) (10b) PDO for a Source. See Section 7 for the electrical
requirements of the power supply.

Page 156 USB Power Delivery Specification Revision 2.0, Version 1.1
The voltage fields shall define the range that output voltage shall fall within. This does not indicate the voltage that
will actually be supplied, except it shall fall within that range. The absolute voltage, including any voltage variation,
shall not fall below the Minimum Voltage and shall not exceed the Maximum Voltage.

Table 6-8 Variable Supply (non-battery) PDO - Source

Bit(s) Description
B31..30 Variable Supply (non-battery)
B29..20 Maximum Voltage in 50mV units
B19..10 Minimum Voltage in 50mV units
B9..0 Maximum Current in 10mA units

6.4.1.2.5 Battery Supply Power Data Object

Table 6-9 describes a Battery (01b) PDO for a Source. See Section 7 for the electrical requirements of the power
supply.
The voltage fields shall represent the battery’s voltage range. The battery shall be capable of supplying the Power
value over the entire voltage range. The absolute voltage, including any voltage variation, shall not fall below the
Minimum Voltage and shall not exceed the Maximum Voltage. Note, only the Battery PDO uses power instead of
current.
The Sink may monitor the battery voltage.

Table 6-9 Battery Supply PDO - Source

Bit(s) Description
B31..30 Battery
B29..20 Maximum Voltage in 50mV units
B19..10 Minimum Voltage in 50mV units
B9..0 Maximum Allowable Power in 250mW units

6.4.1.3 Sink Capabilities Message

A Sink Port shall report power levels it is able to operate at in a series of 32-bit Power Data Objects (see Table 6-4).
These are returned as part of a Sink_Capabilities Message in response to a Get_Sink_Cap Message (see Figure 6-3).
This is similar to that used for Source Port capabilities with equivalent Power Data Objects for Fixed, Variable and
Battery Supplies as defined in this section. Power Data Objects are used to convey the Sink Port’s operational power
requirements including Dual-Role ports presently operating as a Source.
Each Power Data Object shall describe a specific Sink operational power level, such as a battery (e.g. 2.8-4.1V) or a
fixed power supply (e.g. 12V). The Number of Data Objects field in the Message Header shall define the number of
Power Data Objects that follow the Message Header in a Data Message.
All Sinks shall minimally offer one Power Data Object with a power level at which the Sink can operate. A Sink shall
not offer multiple Power Data Objects of the same type (fixed, variable, battery) and the same voltage but shall instead
offer one Power Data Object with the highest available current for that Sink capability and voltage.
All Sinks shall include one Power Data Object that reports vSafe5V even if they require additional power to operate
fully. In the case where additional power is required for full operation the Higher Capability bit shall be set.

6.4.1.3.1 Sink Fixed Supply Power Data Object

Table 6-10 describes the Sink Fixed Supply (00b) PDO. See Chapter 0 for the electrical requirements of the power
supply. The Sink shall set Voltage to its required voltage and Operational Current to its required operating current.
Required operating current is defined as the amount of current a given device needs to be functional. This value could
be the maximum current the Sink will ever require or could be sufficient to operate the Sink in one of its modes of
operation.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 157
Since all USB Consumers support vSafe5V, the required vSafe5V Fixed Supply Power Data Object is also used to
convey additional information that is returned in bits 29 through 20. All other Fixed Supply Power Data Objects shall
set bits 29...20 to zero.
For a Sink requiring no power from the Source, the Voltage (B19..10) shall be set to 5V and the Operational Current
shall be set to 0mA.

Table 6-10 Fixed Supply PDO - Sink

Bit(s) Description
B31..30 Fixed supply
B29 Dual-Role Power
B28 Higher Capability
B27 Externally Powered
B26 USB Communications Capable
B25 Data Role Swap
B24..20 Reserved – shall be set to zero.
B19..10 Voltage in 50mV units
B9..0 Operational Current in 10mA units

6.4.1.3.1.1 Dual-Role Power

The Dual-Role bit shall be set when the Port is Dual-Role Power capable i.e. supports the PR_Swap Message. This is a
static capability which shall remain fixed for a given device.

6.4.1.3.1.2 Higher Capability

In the case that the Sink needs more than vSafe5V (e.g. 12V) to provide full functionality, then the Higher Capability
bit shall be set.

6.4.1.3.1.3 Externally Powered

The Externally Powered bit shall only be set when an AC “wall” supply is providing 100% of the Sink’s power.
This means that either:
 There is an AC supply, e.g. a wall wart, directly connected to the Sink.
 Or, in the case of a PDUSB Hub:
o The Hub is receiving 100% of its power from a PD Source with its Externally Powered bit set.
o The Hub is receiving 100% of its power from multiple PD Sources all with their Externally Powered bits
set.

6.4.1.3.1.4 USB Communications Capable

The USB Communications Capable bit shall only be set for devices capable of communication over the USB data lines
(e.g. D+/- or SS Tx/Rx).

6.4.1.3.1.5 Data Role Swap

The Data Role Swap bit shall be set when the Port is a Type-C DRP (see [USBType-C 1.0]) and supports the DR_Swap
Message. This is a static capability which shall remain fixed for a given device.

6.4.1.3.2 Variable Supply (non-battery) Power Data Object

Table 6-11 describes a Variable Supply (non-battery) (10b) PDO used by a Sink. See Section 7 for the electrical
requirements of the power supply.
The voltage fields shall be set to the output voltage range that the Sink requires to operate. The Operational Current
field shall be set to the operational current that the Sink requires at the given voltage range. The absolute voltage,

Page 158 USB Power Delivery Specification Revision 2.0, Version 1.1
including any voltage variation, shall not fall below the Minimum Voltage and shall not exceed the Maximum Voltage.
Required operating current is defined as the amount of current a given device needs to be functional. This value could
be the maximum current the Sink will ever require or could be sufficient to operate the Sink in one of its modes of
operation.

Table 6-11 Variable Supply (non-battery) PDO - Sink

Bit(s) Description
B31..30 Variable Supply (non-battery)
B29..20 Maximum Voltage in 50mV units
B19..10 Minimum Voltage in 50mV units
B9..0 Operational Current in 10mA units

6.4.1.3.3 Battery Supply Power Data Object

Table 6-12 describes a Battery (01b) PDO used by a Sink. See Section 7 for the electrical requirements of the power
supply.
The voltage fields shall be set to the output voltage range that the Sink requires to operate. The Operational Power
field shall be set to the operational power that the Sink requires at the given voltage range. The absolute voltage,
including any voltage variation, shall not fall below the Minimum Voltage and shall not exceed the Maximum Voltage.
Note, only the Battery PDO uses power instead of current. Required operating power is defined as the amount of
power a given device needs to be functional. This value could be the maximum power the Sink will ever require or
could be sufficient to operate the Sink in one of its modes of operation.

Table 6-12 Battery Supply PDO - Sink

Bit(s) Description
B31..30 Battery
B29..20 Maximum Voltage in 50mV units
B19..10 Minimum Voltage in 50mV units
B9..0 Operational Power in 250mW units

6.4.2 Request Message

A Request Message shall be sent by a Sink to request power, typically during the request phase of a power
negotiation. The Request Data Object shall be returned by the Sink making a request for power. It shall be sent in
response to the most recent Source_Capabilities Message (see Section 8.3.2.3). A Request Message shall return one
and only one Sink Request Data Object that shall identify the Power Data Object being requested.
The Request Message includes the requested power level. For example, if the Source_Capabilities Message includes a
Fixed Supply PDO that offers 12V @ 1.5A and if the Sink only wants 12V @ 0.5A, it will set the Operating Current field
to 50 (i.e. 10mA * 50 = 0.5A). The Request Message requests the highest current the Sink will ever require in the
Maximum Operating Current Field (in this example it would be 100 (100 * 10mA = 1.0A)).
The request takes one of two forms depending on the kind of power requested. The Fixed Power Data Object and
Variable Power Data Object share a common format (see Table 6-13 and Table 6-14). The Battery Power Data Object
uses a different format (see Table 6-15 and Table 6-16).

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 159
 Table 6-13 Fixed and Variable Request Data Object

Bits Description
B31 Reserved – shall be set to zero
B30..28 Object position (000b is Reserved and shall not be used)
B27 GiveBack flag = 0
B26 Capability Mismatch
B25 USB Communications Capable
B24 No USB Suspend
B23..20 Reserved - shall be set to zero.
B19..10 Operating current in 10mA units
B9..0 Maximum Operating Current 10mA units

Table 6-14 Fixed and Variable Request Data Object with GiveBack Support

Bits Description
B31 Reserved – shall be set to zero
B30..28 Object position (000b is Reserved and shall not be used)
B27 GiveBack flag =1
B26 Capability Mismatch
B25 USB Communications Capable
B24 No USB Suspend
B23..20 Reserved - shall be set to zero.
B19..10 Operating Current in 10mA units
B9..0 Minimum Operating Current 10mA units

Table 6-15 Battery Request Data Object

Bits Description
B31 Reserved – shall be set to zero
B30..28 Object position (000b is Reserved and shall not be used)
B27 GiveBackFlag = 0
B26 Capability Mismatch
B25 USB Communications Capable
B24 No USB Suspend
B23..20 Reserved - shall be set to zero.
B19..10 Operating Power in 250mW units
B9..0 Maximum Operating Power in 250mW units

Page 160 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 6-16 Battery Request Data Object with GiveBack Support

Bits Description
B31 Reserved – shall be set to zero
B30..28 Object position (000b is Reserved and shall not be used)
B27 GiveBackFlag = 1
B26 Capability Mismatch
B25 USB Communications Capable
B24 No USB Suspend
B23..20 Reserved - shall be set to zero.
B19..10 Operating Power in 250mW units
B9..0 Minimum Operating Power in 250mW units

6.4.2.1 Object Position

The value in the Object Position field shall indicate which object in the Source_Capabilities Message the RDO refers.
The value 1 always indicates the 5V Fixed Supply PDO as it is the first object following the Source_Capabilities
Message Header. The number 2 refers to the next PDO and so forth.

6.4.2.2 GiveBack Flag

The GiveBack flag shall be set to indicate that the Sink will respond to a GotoMin Message by reducing its load to the
Minimum Operating Current. It will typically be used by a USB Device while charging its battery because a short
interruption of the charge will have minimal impact on the user and will allow the Source to manage its load better.

6.4.2.3 Capability Mismatch

A Capability Mismatch occurs when the Sink cannot satisfy its power requirements from the capabilities offered by
the Source. In this case the Sink shall make a valid request from the offered capabilities and shall set the Capability
Mismatch bit (see Section 8.2.5.2).
When a Sink returns a Request Data Object in response to advertised capabilities with this bit set, it indicates that the
Sink wants power that the Source cannot provide. This may be due to either a voltage that is not available or the
amount of available current. At this point the Source can use the information in the Request Message combined with
the contents of the Sink_Capabilities Message to ascertain the Voltage and Current required by the Sink for full
operation.
In this context a valid Request Message means the following:
 The Object position field shall contain a reference to an object in the last received Source_Capabilities Message.
 The Operating Current/Power field shall contain a value which is less than or equal to the maximum
current/power offered in the Source_Capabilities Message.
 If the GiveBack flag is set to zero i.e. there is a Maximum Operating Current/Power field:
o If the Capability Mismatch bit is set to one
 The Maximum Operating Current/Power field may contain a value larger than the maximum
current/power offered in the Source_Capabilities Message’s PDO as referenced by the Object
position field. This enables the Sink to indicate that it requires more current/power than is
being offered. If the Sink requires a different voltage this will be indicated by its
Sink_Capabilities Message.
o Else if the Capability Mismatch bit is set to zero
 The Maximum Operating Current/Power field shall contain a value less than or equal to the
maximum current/power offered in the Source_Capabilities Message’s PDO as referenced by the
Object position field.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 161
 Else if the GiveBack flag is set to one i.e. there is a Minimum Operating Current/Power field:
o The Minimum Operating Current/Power field shall contain a value less than the Operating
Current/Power field.

6.4.2.4 USB Communications Capable

The USB Communications Capable flag shall be set to one when the Sink has USB data lines and is capable of
communicating using either [USB 2.0] or [USB 3.1] protocols. The USB Communications Capable flag shall be set to
zero when the Sink does not have USB data lines or is otherwise incapable of communicating using either [USB 2.0] or
[USB 3.1] protocols. This is used by the Source to determine operation in certain cases such as USB suspend. If the
USB Communications Capable flag has been set to zero by a Sink then the Source needs to be aware that USB Suspend
rules cannot be observed by the Sink.

6.4.2.5 No USB Suspend

The No USB Suspend flag may be set by the Sink to indicate to the Source that this device is requesting to continue its
Contract during USB Suspend. Sinks setting this flag typically have functionality that can use power for purposes
other than USB communication e.g. for charging a battery.
The Source uses this flag to evaluate whether it should re-issue the Source_Capabilities Message with the USB
Suspend flag cleared.

6.4.2.6 Operating Current

The Operating Current field in the Request Data Object shall be set to the actual amount of current the Sink needs to
operate at a given time. A new Request Message, with an updated Operating Current value, shall be issued whenever
the Sink’s power needs change e.g. from Maximum Operating Current down to a lower current level. In conjunction
with the Maximum Operating Current field or Minimum Operating Current field, it provides the Source with additional
information that allows it to better manage the distribution of its power. This field shall apply to the Fixed and
Variable RDO.

6.4.2.7 Maximum Operating Current

The Maximum Operating Current field in the Request Message shall be set to the highest current the Sink will ever
require. The difference between the Operating Current and Maximum Operating Current fields (when the GiveBack
Flag is cleared) is used by the Device Policy Manager in the Source to calculate the size of the Power Reserve to be
maintained (see Section 8.2.5.1). The Operating Current value shall be less than or equal to the Maximum Operating
Current value.
When the Capabilities Mismatch bit is set to zero the requested Maximum Operating Current shall be less than or
equal to the current in the offered Source Capabilities since the Source will need to reserve this power for future use.
The Maximum Operating Current field shall continue to be set to the highest current needed in order to maintain the
allocation of the Power Reserve. If Maximum Operating Current is requested when the Power Reserve is being used
by a GotoMin capable device then the resulting Message will be a Wait Message to enable the Source to reclaim the
additional current (see Sections 6.3.12.1 and 8.2.5.1).
When the Capabilities Mismatch bit is set to one the requested Maximum Operating Current may be greater than the
current in the offered Source Capabilities since the Source will need this information to ascertain the Sink’s actual
needs.
See Section 6.4.2.3 for more details of the usage of the Capabilities Mismatch bit.
This field shall apply to the Fixed and Variable RDO.

6.4.2.8 Minimum Operating Current

The Minimum Operating Current field in the Request Message shall be set to the lowest current the Sink requires to
maintain operation. The difference between the Operating Current and Minimum Operating Current fields (when the

Page 162 USB Power Delivery Specification Revision 2.0, Version 1.1
GiveBack Flag is set) is used by the Device Policy Manager to calculate the amount of power which can be reclaimed
using a GotoMin Message. The Operating Current value shall be greater than the Minimum Operating Current value.
This field shall apply to the Fixed and Variable RDO.

6.4.2.9 Operating Power

The Operating Power field in the Request Data Object shall be set to the actual amount of power the Sink wants at this
time. In conjunction with the Maximum Operating Power field, it provides the Source with additional information that
allows it to better manage the distribution of its power.
This field shall apply to the Battery RDO.

6.4.2.10 Maximum Operating Power

The Maximum Operating Power field in the Request Message shall be set to the highest power the Sink will ever
require. This allows a Source with a power supply shared amongst multiple ports to intelligently distribute power.
When the Capabilities Mismatch bit is set to zero the requested Maximum Operating Power shall be less than or equal
to the power in the offered Source Capabilities since the Source will need to reserve this power for future use. The
Maximum Operating Power field shall continue to be set to the highest power needed in order to maintain the
allocation of the Power Reserve. If Maximum Operating Power is requested when the Power Reserve is being used by
a GotoMin capable device then the resulting Message will be a Wait Message to enable the Source to reclaim the
additional power (see Sections 6.3.12.1 and 8.2.5.1).
When the Capabilities Mismatch bit is set to one the requested Maximum Operating Power may be greater than the
current in the offered Source Capabilities since the Source will need this information to ascertain the Sink’s actual
needs
See Section 6.4.2.3 for more details of the usage of the Capabilities Mismatch bit.
This field shall apply to the Battery RDO.

6.4.2.11 Minimum Operating Power

The Minimum Operating Power field in the Request Message shall be set to the lowest current the Sink requires to
maintain operation. When combined with the Operating Power, it gives a Source with a power supply shared amongst
multiple ports information about how much power it can temporarily get back so it can to intelligently distribute
power.
This field shall apply to the Battery RDO.

6.4.3 BIST Message

The BIST Message is sent to request the Port to enter a Physical Layer test mode that performs one of the following
functions:
 Enter the receiver mode which does the following:
o Zero accumulated BISTErrorCounter
o Process a series of BIST Test Frames and compare the received data to the expected data pattern
o Count the number of errors received and add to the BISTErrorCounter
 Enter a transmit mode to send BIST Test Frames to the Tester
 Enter a Continuous BIST Mode to send a continuous stream of test data to the Tester
 Send BIST test to the UUT
 Return the BISTErrorCounter to the Tester
The Message format is as follows:

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 163
 Figure 6-4 BIST Message

Header BIST Request

No. of Data Objects = 1 or 7 Object

All ports shall be able to be a Unit Under Test (UUT) only when operating at vSafe5V. BIST Modes to be supported are
defined in Section 5.9.9. For each supported BIST Mode the following operations shall be implemented based on the
reception of the appropriate BIST Message BIST Data Object (see Table 6-17):
 Process reception of a BIST Receiver Mode BIST Data Object
 Process reception of a BIST Transmit Mode BIST Data Object
 Generate a Returned BIST Counters BIST Data Object response within a BIST Message in response to each
received Test Frame.
 Process reception of a BIST Carrier Mode 0 BIST Data Object that shall result in the generation of the appropriate
carrier signal
 Process reception of a BIST Carrier Mode 1 BIST Data Object that shall result in the generation of the appropriate
carrier signal
 Process reception of a BIST Carrier Mode 2 BIST Data Object that shall result in the generation of the appropriate
carrier signal.
 Process reception of a BIST Carrier Mode 3 BIST Data Object that shall result in the generation of the appropriate
carrier signal.
 Process reception of a BIST Eye Pattern BIST Data Object that shall result in the generation of the appropriate
carrier signal
 Process reception of a BIST Test Data BIST Data Object that shall result in the Message being Ignored.
It is optional for a Port to take on the role of a Tester.
When a Port receives a BIST Message BIST Data Object for a BIST Mode when Power Role swapped or not operating at
vSafe5V, the BIST Message shall be Ignored.
When a Port receives a BIST Message BIST Data Object for a BIST Mode it does not support the BIST Message shall be
Ignored.
When a Port or Cable Plug receives a BIST Message BIST Data Object for a Continuous BIST Mode that it supports, the
Port or Cable Plug enters the requested BIST Mode and shall remain in that BIST Mode for tBISTContMode and then
shall return to normal operation (see Section 6.5.8.4).
It is anticipated that dedicated Testers will exist. Those testers may not be required to implement a local receiver test.
However, a Tester shall always be able to complete the operations required when a BIST Message with BIST Data
Object BIST Transmit Mode is sent by the Tester.
The usage model of the PHY Layer BIST modes generally assumes that some controlling agent will request a test of its
Port Partner. A UUT Port minimally has to process a request to enter test mode and return error counters. A Tester
Port shall have a means to place the UUT Port into receiver test mode and retrieve the error counters from the UUT. A
Port, that is not part of a Tester, is not expected to be the initiator of a receiver test operation, but is not precluded
from doing so.
In Section 0 there is a sequence description of the test sequences used for compliance testing.
The fields in the BIST Data Object are defined in the Table 6-17.

Table 6-17 BIST Data Object

Bit(s) Value Parameter Description Reference

B31..28 0000b BIST Receiver Mode Requests receiver to enter BIST Receiver See Section 6.4.3.1
Mode
0001b BIST Transmit Mode Requests receiver to enter BIST Transmit See Section 6.4.3.2
Mode

Page 164 USB Power Delivery Specification Revision 2.0, Version 1.1
Bit(s) Value Parameter Description Reference
0010b Returned BIST Counters Returned error counters See Section 6.4.3.3
0011b BIST Carrier Mode 0 Requests transmitter to enter BIST Carrier See Section 6.4.3.4
Mode 0
0100b BIST Carrier Mode 1 Requests transmitter to enter BIST Carrier See Section 6.4.3.5
Mode 1
0101b BIST Carrier Mode 2 Request Transmitter to enter BIST Carrier See Section 6.4.3.6
Mode 2
0110b BIST Carrier Mode 3 Request Transmitter to enter BIST Carrier See Section 6.4.3.7
Mode 3
0111b BIST Eye Pattern Requests transmitter to enter BIST Eye See Section 6.4.3.8
Pattern.
1000b BIST Test Data Sends a Test Data Frame. See Section 6.4.3.9
1001b- All values not explicitly defined are
1111b Reserved and shall not be used.
B27..16 Reserved and shall be set to zero.
B15..0 16-bit unsigned integer When Request Type is Returned BIST See Section 6.4.3.3
Counters, this field shall contain the
contents of BISTErrorCounter otherwise it
shall be set to zero.

6.4.3.1 BIST Receiver Mode

This operation shall be used to initiate a UUT remote receiver test by sending a BIST Message containing a BIST
Receiver Mode BIST Data Object.
On receiving the request, the UUT shall zero its BISTErrorCounter and both the Tester and the UUT shall preload
their PRBS generator with the designated pattern (see Section 5.9.1).
The receiver (UUT) shall acknowledge the BIST Message with a GoodCRC Message.
The UUT enters BIST Receiver Mode after the BIST Message has been received (see Section 6.5.8.1). At this time the
UUT shall be able to receive a Test Frame from the Tester and to respond appropriately with a BIST Message with a
BIST Data Object of Returned BIST Counters (see Section 6.5.8.5). After reception of the first Test Frame, further Test
Frames are sent at a rate determined by the Tester.
The test shall be ended by sending Hard Reset Signaling to reset the UUT.

6.4.3.2 BIST Transmit Mode

Loopback mode is not possible so BIST Transmit Mode shall be used to request a UUT transmitter test by sending a
BIST Message containing a BIST Transmit Mode BIST Data Object.
Before initiating the request the Tester shall zero its BISTErrorCounter and preload the PRBS generator with the
designated pattern (see Section 5.9.1). On receiving the request the UUT shall preload the PRBS generator with the
designated pattern (see Section 5.9.1).
The receiver in the UUT shall acknowledge the BIST Message with a GoodCRC Message. The UUT enters BIST
Transmit Mode after the BIST Message has been received (see Section 6.5.8.1). The UUT shall start transmitting the
first Test Frame no later than tBISTMode max of the last bit of the EOP of the BIST Message used to initiate the test is
received by the Physical Layer. Each subsequent Test Frame shall be started:
 Either on reception of a BIST Message, with a Returned BIST Counters BIST Data Object or
 On expiry of the BISTReceiveErrorTimer and
 No later than tBISTResponse after the first bit of the Preamble of the previous Test Frame has been transmitted
by the Physical Layer.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 165
The Tester shall preload its PRBS checker with the designated pattern and start counting errors. After receiving a
suitable number of Test Frames, the Tester shall freeze its error counter. The UUT shall be reset by sending Hard
Reset Signaling instead of a BIST Message.

6.4.3.3 Returned BIST Counters

The BIST Message, with a Returned BIST Counters BIST Data Object, shall contain the error counters obtained during
the receiver test. During BIST, when sending Test Frames, the MessageID of the BIST Message, with a Returned BIST
Counters BIST Data Object shall be Ignored.

6.4.3.4 BIST Carrier Mode 0

Upon receipt of a BIST Message, with a BIST Carrier Mode 0 BIST Data Object, the UUT shall send out a continuous
string of "0"s. This produces a continuous frequency that will allow measurement of fCarrier - fDeviation.
The UUT shall exit the Continuous BIST Mode within tBISTContMode of this Continuous BIST Mode being enabled
(see Section 6.5.8.4).

6.4.3.5 BIST Carrier Mode 1

Upon receipt of a BIST Message, with a BIST Carrier Mode 1 BIST Data Object, the UUT shall send out a continuous
string of "1"s. This produces a continuous frequency that will allow measurement of fCarrier + fDeviation.
The UUT shall exit the Continuous BIST Mode within tBISTContMode of this Continuous BIST Mode being enabled
(see Section 6.5.8.4).

6.4.3.6 BIST Carrier Mode 2

Upon receipt of a BIST Message, with a BIST Carrier Mode 2 BIST Data Object, the UUT shall send out a continuous
string of alternating "1"s and “0”s. Note: that in the case that the BMC Signaling Scheme is used the “1”s and “0”s will
in addition be BMC encoded.
The UUT shall exit the Continuous BIST Mode within tBISTContMode of this Continuous BIST Mode being enabled
(see Section 6.5.8.4).

6.4.3.7 BIST Carrier Mode 3

Upon receipt of a BIST Message, with a BIST Carrier Mode 3 BIST Data Object, the UUT shall send out a continuous
string of sixteen "1"s, followed by sixteen “0”s.
The UUT shall exit the Continuous BIST Mode within tBISTContMode of this Continuous BIST Mode being enabled
(see Section 6.5.8.4).

6.4.3.8 BIST Eye Pattern

Upon receipt of a BIST Message, with a BIST Eye Pattern BIST Data Object, the UUT shall send out a continuous string
of bits in accordance with section 5.9.1. This produces a signal that will allow measurement of the eye pattern and of
the spectrum mask.
The UUT shall exit the Continuous BIST Mode within tBISTContMode of this Continuous BIST Mode being enabled
(see Section 6.5.8.4).

6.4.3.9 BIST Test Data

Upon receipt of a BIST Message, with a BIST Test Data BIST Data Object, the UUT shall return a GoodCRC Message
and shall enter a test mode in which it sends no further Messages except for GoodCRC Messages in response to
received Messages. See Section 5.9.7 for the definition of the Test Data Frame.
The test shall be ended by sending Hard Reset Signaling to reset the UUT.

Page 166 USB Power Delivery Specification Revision 2.0, Version 1.1
 6.4.4 Vendor Defined Message
The Vendor_Defined Message (VDM) is provided to allow vendors to exchange information outside of that defined by
this specification.
A Vendor_Defined Message shall consist of at least one Vendor Data Object, the VDM Header, and may contain up to a
maximum of six additional VDM Objects (VDO).
To ensure vendor uniqueness of Vendor_Defined Messages, all Vendor_Defined Messages shall contain a valid USB
Standard or Vendor ID (SVID) allocated by USB-IF in the VDM Header.
Two types of Vendor_Defined Messages are defined: Structured VDMs and Unstructured VDMs. A Structured VDM
defines an extensible structure designed to support Modal Operation. An Unstructured VDM does not define any
structure and Messages may be created in any manner that the vendor chooses.
Vendor_Defined Messages shall not be used for direct power negotiation. They may however be used to alter Local
Policy, affecting what is offered or consumed via the normal PD Messages. For example a Vendor_Defined Message
could be used to enable the Source to offer additional power via a Source_Capabilities Message.
The Message format shall be as shown in Figure 6-5.

Figure 6-5 Vendor Defined Message

Header
VDM Header 0-6 VDOs
No. of Data Objects = 1-7

The VDM Header shall be the first 4-byte object in a Vendor Defined Message. The VDM Header provides command
space to allow vendors to customize Messages for their own purposes. Additionally vendors may make use of the
Commands in a Structured VDM.
The fields in the VDM Header for an Unstructured VDM, when the VDM Type Bit is set to zero, shall be as defined in
Table 6-18. The fields in the VDM Header for a Structured VDM, when the VDM Type Bit is set to one shall be as
defined in Table 6-19.
Both Unstructured and Structured VDMs shall only be sent and received after an Explicit Contract has been
established. The only exception to this is the Discover Identity Command which may be sent by Source when no
Contract or an Implicit Contract (in place after a Power Role Swap) is in place in order to discover Cable capabilities
(see Section 8.3.3.10.11). A VDM Message sequence shall not interrupt any other PD Message Sequence. A VDM
Message sequence shall be interruptible by any other PD Message Sequence.

6.4.4.1 Unstructured VDM

The Unstructured VDM does not define the contents of bits B14..0 in the VDM Header. Their definition and use are the
sole responsibility of the vendor indicated by the VID. The Port Partners and Cable Plugs shall exit any states entered
using an Unstructured VDM when a Hard Reset appears on PD.
The following rules apply to the use of Unstructured VDM Messages:
 Unstructured VDMs shall only be used when an Explicit Contract is in place.
 Prior to establishing an Explicit Contract Unstructured VDMs shall not be sent and shall be Ignored if received.
 A Port receiving an Unstructured VDM for a VID that it does not recognize shall Ignore the Message.
 Only the DFP shall be an Initiator of Unstructured VDMs.
 Only the UFP or a Cable Plug shall be a Responder to Unstructured VDM.
 Unstructured VDMs shall not be initiated or responded to under any other circumstances.
 A DFP or UFP which does not support Unstructured VDMs shall Ignore any Unstructured VDMs received.
 A “command” sequence shall be interruptible e.g. due to the need for a Message sequence using SOP Packets.
 Unstructured VDMs shall only be used during Modal Operation in the context of an Active Mode.
 Unstructured VDMs may be used with SOP* Packets.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 167
Table 6-18 illustrates the VDM Header bits.

Table 6-18 Unstructured VDM Header

Bit(s) Description Reference

B31..16 Vendor ID (VID) Unique 16-bit unsigned integer. Assigned by the
USB-IF to the Vendor.
B15 VDM Type 0 = Unstructured VDM
B14..0 Available for Vendor Use Content of this field is defined by the vendor.

6.4.4.1.1 USB Vendor ID

The Vendor ID field shall contain the 16-bit Vendor ID value assigned to the vendor by the USB-IF (VID). No other
value shall be present in this field.

6.4.4.1.2 VDM Type

The VDM Type field shall be set to zero indicating that this is an Unstructured VDM.

6.4.4.2 Structured VDM

Setting the VDM Type field to 1 (Structured VDM) defines the use of bits B14..0 in the Structured VDM Header. The
fields in the Structured VDM Header are defined in Table 6-19.
The following rules apply to the use of Structured VDM Messages:
 Structured VDMs shall only be used when an Explicit Contract is in place with the following exception:
 Prior to establishing an Explicit Contract a Source may issue Discover Identity Messages, to a Cable Plug using
SOP’ Packets, as an Initiator (see Section 8.3.3.10.11).
 Only the DFP shall be an Initiator of Structured VDMs except for the Attention Command that shall only be
initiated by the UFP.
 Only the UFP or a Cable Plug shall be a Responder to Structured VDMs.
 Structured VDMs shall not be initiated or responded to under any other circumstances.
 A DFP or UFP which does not support Structured VDMs shall Ignore any Structured VDMs received.
 A DFP, UFP or Cable Plug which supports Structured VDMs and receiving an Structured VDM for a SVID that it
does not recognize shall reply with a NAK Command.
 A Command sequence shall be interruptible e.g. due to the need for a Message sequence using SOP Packets.

Table 6-19 Structured VDM Header

Bit(s) Field Description
B31..16 Standard or Vendor ID (SVID) Unique 16 bit unsigned integer, assigned by the
USB-IF
B15 VDM Type 1 = Structured VDM
B14..13 Structured VDM Version Version Number of the Stuctured VDM (not this
specification Version):
 Version 1.0 = 0
 Values 1-3 are Reserved and shall not be used
B12..11 Reserved For Commands 0..15 shall be set to 0 and shall be
Ignored
SVID Specific Commands (16..31) defined by the
SVID.

Page 168 USB Power Delivery Specification Revision 2.0, Version 1.1
Bit(s) Field Description
B10..8 Object Position For the Enter Mode, Exit Mode and Attention
Commands:
 000b = Reserved and shall not be used.
 001b..110b = Index into the list of VDOs to
identify the desired Mode VDO
 111b = Exit all Active Modes (equivalent of a
power on reset). Shall only be used with the
Exit Mode Command.
Commands 0..3, 7..15:
 000b
 001b..111b = Reserved and shall not be
used.
SVID Specific Commands (16..31) defined by the
SVID.
B7..6 Command Type 00b = Initiator
01b = Responder ACK
10b = Responder NAK
11b = Responder BUSY
B5 Reserved Shall be set to 0 and shall be Ignored
B4..0 Command 1 0 = Reserved, shall not be used
1 = Discover Identity
2 = Discover SVIDs
3 = Discover Modes
4 = Enter Mode
5 = Exit Mode
6 = Attention
7-15 = Reserved, shall not be used
16..31 = SVID Specific Commands
Note 1: In the case where a SID is used the modes are defined by a standard. When a VID is used the modes are defined by the
Vendor.

Table 6-20 shows the Commands, which SVID to use with each Command and the only SOP* values which shall be
used.

Table 6-20 Structured VDM Commands

Command VDM Header SVID Field SOP* used

Discover Identity Shall only use the PD SID. Shall only use SOP/SOP’.
Discover SVIDs Shall only use the PD SID. Shall only use SOP/SOP’.
Discover Modes Valid with any SVID. Shall only use SOP/SOP’.
Enter Mode Valid with any SVID. Valid with SOP*.
Exit Mode Valid with any SVID. Valid with SOP*.
Attention Valid with any SVID. Valid with SOP.
SVID Specific Valid with any SVID. Valid with SOP* (defined by
Commands SVID).

6.4.4.2.1 SVID
The SVID field shall contain either a 16-bit USB Standard ID value (SID) or the 16-bit assigned to the vendor by the
USB-IF (VID). No other value shall be present in this field.
Table 6-21 lists specific SVID values referenced by this specification.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 169
 Table 6-21 SVID Values

Parameter Value Description

PD SID 0xFF00 Standard ID allocated to this specification.

6.4.4.2.2 VDM Type

The VDM Type field shall be set to one indicating that this is a Structured VDM.

6.4.4.2.3 Structured VDM Version

The Structured VDM Version field indicates the level of functionality supported in the Structured VDM part of the
specification. This is not the same version as the version of this specification. At this time, there is only one version
(1.0) defined. This field shall be set to zero to indicate Version 1.0.
On receipt of a VDM Header with a higher Version number than that supported, a Port shall respond using the highest
Version number it supports.

6.4.4.2.4 Object Position

The Object Position field shall be used by the Enter Mode and Exit Mode Commands. The Discover Modes Command
returns a list of zero to six VDOs, each of which describes a Mode. The value in Object Position field is an index into
that list that indicates which VDO (e.g. Mode) in the list the Enter Mode and Exit Mode Command refers to. The Object
Position shall start with one for the first Mode in the list. If the SVID is a VID, the content of the VDO for the Mode shall
be defined by the vendor. If the SVID is a SID, the content shall be defined by the Standard. The VDO’s content may be
as simple as a numeric value or as complex as bit mapped description of capabilities of the Mode. In all cases, the
Responder is responsible for deciphering the contents to know whether or not it supports the Mode at the Object
Position.
This field shall be set to zero when not required by the Command.

6.4.4.2.5 Command Type

This Command Type field shall be used to indicate the type of Command request/response being sent.
An Initiator shall set the field to “Initiator” to indicate that this is a Command request from an Initiator.
“Responder ACK” is the normal return and shall be sent to indicate that the Command request was received and
handled normally.
“Responder NAK” shall be returned when the Command request has an invalid parameter (e.g. invalid SVID or Mode)
or cannot not be acted upon at this time (e.g. a Mode which has a dependency on another Mode). The handling of
“Responder NAK” is left up to the Initiator.
“Responder BUSY” shall be sent in the response to a VDM when the Responder is unable to respond to the Command
request immediately, but the Command request may be retried. The DFP shall wait tVDMBusy after a “Responder
BUSY” response is received before retrying the Command request.

6.4.4.2.6 Command
This field is used to identify devices and manage their operational Modes. The commands defined in this specification
shall be used to manage Modes on the USB Type-C connector. There is a further range of Command values left for the
vendor to use to manage additional extensions.
A Structured VDM Command is deemed to be completed (and if applicable, the transition to the requested
functionality is made) when the GoodCRC Message has been successfully sent by the Initiator in reply to the
Responder’s response.
If the Structured VDM Command request is not recognized it shall be NAKed.

Page 170 USB Power Delivery Specification Revision 2.0, Version 1.1
 6.4.4.3 Use of Commands
The VDM Header for a Structured VDM Message defines Commands used to retrieve a list of SVIDs the device
supports, to discover the Modes associated with each SVID, and to enter/exit the Modes. The Commands include:
 Discover Identity
 Discover SVIDs
 Discover Modes
 Enter Mode
 Exit Mode
 Attention
Additional Command space is also reserved for Standard and Vendor use and for future extensions.
The Command sequences use the terms Initiator and Responder to identify messaging roles the ports are taking on
relative to each other. This role is independent of the Port’s power capability (Provider, Consumer etc.) or its present
power role (Source or Sink). The Initiator is the Port sending the initial Command request and the Responder is the
Port replying with the Command response. See Section 6.4.4.3.6.
All Ports that support Modes shall support the Discover Identity, Discover SVIDs, the Discover Modes, the Enter Mode and
Exit Mode Commands.
Table 6-22 details the responses a Responder may issue to each Command request. Responses not listed for a given
Command shall not be sent by a Responder. A NAK response should be taken as an indication not to retry that
particular Command.

Table 6-22 Commands and Responses

Command Allowed Response Reference

Discover Identity ACK, NAK, BUSY 6.4.4.3.1

Discover SVIDs ACK, NAK, BUSY 6.4.4.3.1.10

Discover Modes ACK, NAK, BUSY 6.4.4.3.3

Enter Mode ACK, NAK 6.4.4.3.4

Exit Mode ACK, NAK 6.4.4.3.5

Attention None 6.4.4.3.6

Examples of Command usage can be found in Appendix G.

6.4.4.3.1 Discover Identity

The Discover Identity Command is provided to enable an Initiator (DFP) to identify its Port Partner and for an Initiator
(Source or DFP) to identify the attached Cable Plug (Responder). The Discovery Identity Command is also used by a
DFP or UFP Sink to determine whether a Cable Plug is PD-Capable by looking for a GoodCRC Message Response.
The Discover Identity Command shall be used to determine whether a given Cable Plug is PD Capable (see Sections
8.3.3.9.2 and 8.3.3.10.11). In this case a Discover Identity Command request sent to SOP' shall not cause a Soft Reset if
a GoodCRC Message response is not returned since this can indicate a non-PD Capable cable. Note that a Cable Plug
will not be ready for PD Communication until tVCONNStable after VCONN has been applied (see [USBType-C 1.0]).
During Cable Plug discovery, when there is an Explicit Contract, Discover Identity Commands are sent at a rate defined
by the DiscoverIdentityTimer (see Section 6.5.14) up to a maximum of nDiscoverIdentityCount times (see Section
6.6.6).
A PD-Capable Cable Plug shall return a Discover Identity Command ACK in response to a Discover Identity Command
request sent to SOP’. A PD-Capable UFP that supports Modal Operation shall return a Discover Identity Command ACK
in response to a Discover Identity Command request sent to SOP.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 171
The SVID in the Discover Identity Command shall be set to the PD SID (see Table 6-21) by both the Initiator and the
Responder for this Command.
The Discover Identity Command sent back by the Responder contains an ID Header VDO, a Cert Stat VDO, a Product
VDO and some Product Type VDOs which depend on the Product Type (see Figure 6-6). This specification defines the
following Product Type VDOs:
 Cable VDO (see Section 6.4.4.3.1.9).
 Alternate Mode Adapter VDO (see Section 6.4.4.3.1.10)
No VDOs other than those defined in this specification shall be sent as part of the Discover Identity Command response.
Where there is no Product Type VDO defined for a specific Product Type, no VDOs shall be sent as part of the Discover
Identity Command response. Any additional VDOs received by the responder shall be Ignored.

Figure 6-6 Discover Identity Command response

Header
VDM Header ID Header VDO Cert Stat VDO Product VDO 0..32 Product Type VDO(s)
No. of Data Objects = 4-71
1
Only Data objects defined in this specification can be sent as part of the Discover Identity Command.
2
The following sections define the number and content of the VDOs for each Product Type.

6.4.4.3.1.1 ID Header VDO

The ID Header VDO contains information corresponding to the Power Delivery Product. The fields in the ID Header
VDO shall be as defined in Table 6-23.

Table 6-23 ID Header VDO

Bit(s) Description Reference

B31 Data Capable as USB Host:
 Shall be set to one if the product is capable of
enumerating USB Devices.
 Shall be set to zero otherwise
B30 Data Capable as a USB Device:
 Shall be set to one if the product is capable of
enumerating as a USB Device.
 Shall be set to zero otherwise
B29..27 Product Type:
 000b – Undefined
 001b – Hub
 010b – Peripheral
 011b – Passive Cable
 100b – Active Cable
 101b – Alternate Mode Adapter (AMA)
 110b..111b – Reserved, shall not be used.
B26 Modal Operation Supported:
 Shall be set to one if the product supports
Modal Operation.
 Shall be set to zero otherwise
B25..16 Reserved. Shall be set to zero.
B15..0 16-bit unsigned integer. USB Vendor ID [USB 2.0]/[USB 3.1]

6.4.4.3.1.2 Data Capable as a USB Host

The Data Capable as a USB Host field is used to indicate whether or not the Port has a USB Host Capability.

Page 172 USB Power Delivery Specification Revision 2.0, Version 1.1
 6.4.4.3.1.3 Data Capable as a USB Device
The Data Capable as a USB Device field is used to indicate whether or not the Port has a USB Device Capability.

6.4.4.3.1.4 Product Type

The Product Type field indicates the type of Product, whether a VDO will be returned and if so the type of VDO to be
returned. Table 6-24 defines the Product Type VDOs which shall be returned.

Table 6-24 Product Types

Product Type Description Product Type VDO Reference

Undefined Shall be used where no other Product Type None
value is appropriate.
Hub Shall be used when the Product is a USB Hub. None 6.4.4.3.1.8
Peripheral Shall be used when the Product is a USB Device None
other than a USB Hub.
Active Cable Shall be used when the Product is a cable that Cable VDO
6.4.4.3.1.9
incorporates signal conditioning circuits.
Passive Cable Shall be used when the Product is a cable that Cable VDO
does not incorporate signal conditioning 6.4.4.3.1.9
circuits.
Alternate Mode Shall be used when the Product is a USB Device AMA VDO
6.4.4.3.1.10
Adapter that supports one or more Alternate Modes.

6.4.4.3.1.5 Modal Operation Supported

The Modal Operation Supported bit is used to indicate whether or the not the Product supports Modes.

6.4.4.3.1.6 Vendor ID
Manufacturers shall set the Vendor ID field to the value of the Vendor ID assigned to them by USB-IF. For USB Devices
or Hubs which support USB communications the Vendor ID field shall be identical to the Vendor ID field defined in the
product’s USB Device Descriptor (see [USB 2.0] and [USB 3.1]).

6.4.4.3.1.7 Cert Stat VDO

The Cert Stat VDO shall contain the Test ID (TID) assigned by USB-IF to the product during certification. The fields in
the Cert Stat VDO shall be as defined in Table 6-25.

Table 6-25 Cert Stat VDO

Bit(s) Description Reference

B31..20 Reserved, shall be set to zero.
B19..0 20-bit unsigned integer, TID Assigned by USB-IF

6.4.4.3.1.8 Product VDO

The Product VDO contains identity information relating to the product. The fields in the Product VDO shall be as
defined in Table 6-26.

Table 6-26 Product VDO

Bit(s) Description Reference

B31..16 16-bit unsigned integer. USB Product ID [USB 2.0]/[USB 3.1]
B15..0 16-bit unsigned integer. bcdDevice [USB 2.0]/[USB 3.1]

Manufacturers should set the USB Product ID field to a unique value identifying the product and should set the
bcdDevice field to a version number relevant to the release version of the product. For USB Devices or Hubs which

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 173
support USB communications the Product ID and bcdDevice fields shall be identical to the Product ID and bcdDevice
fields defined in the product’s USB Device Descriptor (see [USB 2.0] and [USB 3.1]).

6.4.4.3.1.9 Cable VDO

The Cable VDO defined in this section shall be sent when the Product Type is given as Passive or Active Cable. Table
6-27 defines the Cable VDO which shall be sent.

Table 6-27 Cable VDO

Bit(s) Field Description

B31..28 HW Version 0000b..1111b assigned by the VID owner
B27..24 Firmware Version 0000b..1111b assigned by the VID owner
B23..20 Reserved Shall be set to zero.
B19..18 Type-C plug to Type- 00b = Type-A
A/B/C/Captive 01b = Type-B
10b = Type-C
11b = Captive
B17 Type-C plug to 0 = Plug
Plug/Receptacle 1 = Receptacle (not valid when B19..18 set to Type-C or Captive)
B16..13 Cable Latency 0000b – Reserved, shall not be used
0001b – <10ns (~1m)
0010b – 10ns to 20ns (~2m)
0011b – 20ns to 30ns (~3m)
0100b – 30ns to 40ns (~4m)
0101b – 40ns to 50ns (~5m)
0110b – 50ns to 60ns (~6m)
0111b – 60ns to 70ns (~7m)
1000b –1000ns (~100m)
1001b –2000ns (~200m)
1010b – 3000ns (~300m)
1011b ….1111b Reserved, shall not be used
Includes latency of electronics in Active Cable
B12..11 Cable Termination Type 00b = Both ends Passive, VCONN not required
01b = Both ends Passive, VCONN required
10b = One end Active, one end passive, VCONN required
11b = Both ends Active, VCONN required
B10 SSTX1 Directionality Support 0 = Fixed
1 = Configurable
B9 SSTX2 Directionality Support 0 = Fixed
1 = Configurable
B8 SSRX1 Directionality Support 0 = Fixed
1 = Configurable
B7 SSRX2 Directionality Support 0 = Fixed
1 = Configurable
B6..5 VBUS Current Handling 00b = VBUS not through cable
Capability 01b = 3A
10b = 5A
11b = Reserved, shall not be used.
B4 VBUS through cable 0 = No
1 = Yes
B3 SOP” controller present? 1 = SOP” controller present
0 = No SOP” controller present

Page 174 USB Power Delivery Specification Revision 2.0, Version 1.1
Bit(s) Field Description
B2..0 USB Superspeed Signaling 000b = USB 2.0 only
Support 001b = [USB 3.1] Gen1
010b = [USB 3.1] Gen1 and Gen2
011b.. 111b = Reserved, shall not be used

6.4.4.3.1.10 Alternate Mode Adapter VDO

The Alternate Mode Adapter (AMA) VDO defined in this section shall be sent when the Product Type is given as
Alternate Mode Adapter. Table 6-28 defines the AMA VDO which shall be sent.

Table 6-28 AMA VDO

Bit(s) Field Description

B31..28 HW Version 0000b..1111b assigned by the VID owner
B27..24 Firmware Version 0000b..1111b assigned by the VID owner
B23..12 Reserved. Shall be set to zero.
B11 SSTX1 Directionality Support 0 = Fixed
1 = Configurable
B10 SSTX2 Directionality Support 0 = Fixed
1 = Configurable
B9 SSRX1 Directionality Support 0 = Fixed
1 = Configurable
B8 SSRX2 Directionality Support 0 = Fixed
1 = Configurable
B7..5 VCONN power VCONN power needed by adapter for full functionality
000b = 1W
001b = 1.5W
010b = 2W
011b = 3W
100b = 4W
101b = 5W
110b = 6W
111b = Reserved, shall not be used
B4 VCONN required 0 = No
1 = Yes
B3 VBUS required 0 = No
1 = Yes
B2..0 USB Superspeed Signaling 000b = USB 2.0 only
Support 001b = [USB3.1] Gen1 and USB 2.0
010b = [USB3.1] Gen1, Gen2 and USB 2.0
011b = USB 2.0 billboard only
100b.. 111b = Reserved, shall not be used

6.4.4.3.2 Discover SVIDs

The Discover SVIDs Command is used by an Initiator (DFP) to determine the SVIDs for which a Responder (UFP or
Cable Plug) has Modes. The Discover SVIDs Command is used in conjunction with the Discover Modes Command in the
Discovery Process to determine which Modes a device supports. The list of SVIDs is always terminated with one or
two 0x0000 SVIDs.
The SVID in the Discover SVIDs Command shall be set to the PD SID (see Table 6-21) by both the Initiator and the
Responder for this Command. The SVIDs are returned 2 per VDO (see Table 6-29). If there are an odd number of
supported SVIDs, the Discover SVIDs Command is returned ending with a SVID value of 0x0000 in the last part of the
last VDO. If there are an even number of supported SVIDs, the Discover SVIDs Command is returned ending with an

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 175
additional VDO containing two SVIDs with values of 0x0000. A Responder shall only return SVIDs for which a Discover
Modes Command request for that SVID will return at least one Mode. A Responder that does not support any SVIDs
shall return a NAK.
If the Responder supports 12 or more SVIDs then the Discover SVIDs Command shall be executed multiple times until a
Discover SVIDs VDO is returned ending either with a SVID value of 0x0000 in the last part of the last VDO or with a
VDO containing two SVIDs with values of 0x0000. Each Discover SVID ACK Message, other than the one containing
the terminating 0x0000 SVID, shall convey 12 SVIDs. The Responder shall restart the list of SVIDs each time a Discover
Identity Command request is received from the Initiator.
Note: that since a Cable Plug does not retry Messages if the GoodCRC Message from the DFP becomes corrupted the
Cable Plug will consider the Discover SVIDs Command ACK unsent and will send the same list of SVIDs again.
Figure 6-7 shows an example response to the Discover SVIDs Command request with two VDOs containing three SVIDs.
Figure 6-8 shows an example response with two VDOs containing four SVIDs followed by an empty VDO to terminate
the response. Figure 6-9 shows an example response with six VDOs containing twelve SVIDs followed by an
additional request that returns an empty VDO indicating there are no more SVIDs to return.

Table 6-29 Discover SVIDs Responder VDO

Bit(s) Field Description

B31..16 SVID n 16 bit unsigned integer, assigned by the USB-IF or
0x0000 if this is the last VDO and the Responder supports an even
number of SVIDs.
B15..0 SVID n+1 16 bit unsigned integer, assigned by the USB-IF or
0x0000 if this is the last VDO and the Responder supports an odd or
even number of SVIDs.

Figure 6-7 Example Discover SVIDs response with 3 SVIDs

VDO 1 VDO 2
Header
VDM Header
No. of Data Objects = 3 SVID 0 SVID 1 SVID 2 0x0000
(B31..16) (B15..0) (B31..16) (B15..0)

Figure 6-8 Example Discover SVIDs response with 4 SVIDs

VDO 1 VDO 2 VDO 3

Header
VDM Header
No. of Data Objects = 4 SVID 0 SVID 1 SVID 2 SVID 3 0x0000 0x0000
(B31..16) (B15..0) (B31..16) (B15..0) (B31..16) (B15..0)

Figure 6-9 Example Discover SVIDs response with 12 SVIDs followed by an empty response

VDO 1 VDO 2 VDO 3 VDO 4 VDO 5 VDO 6

Header
VDM Header
No. of Data Objects = 7 SVID 0 SVID 1 SVID 2 SVID 3 SVID 4 SVID 5 SVID 6 SVID 7 SVID 8 SVID 9 SVID 10 SVID 11
(B31..16) (B15..0) (B31..16) (B15..0) (B31..16) (B15..0) (B31..16) (B15..0) (B31..16) (B15..0) (B31..16) (B15..0)

VDO 1
Header
VDM Header
No. of Data Objects = 2 0x0000 0x0000
(B31..16) (B15..0)

Page 176 USB Power Delivery Specification Revision 2.0, Version 1.1
 6.4.4.3.3 Discover Modes
The Discover Modes Command is used by an Initiator (DFP) to determine the Modes a Responder (UFP or Cable Plug)
supports for a given ID. The Responder to the Discover Modes Command request shall return a Message Header with
the Number of Data Objects field set to a value of 1 to 7 (the actual value is the number of Mode objects plus one). If
the ID is a VID, the structure and content of the VDO is left to the Vendor. If the ID is a SID, the structure and content
of the VDO is defined by the relevant Standard. A Responder that does not support any Modes shall return a NAK.
Figure 6-10 shows an example of a Discover Modes Command response from a Responder which supports three Modes
for a given SVID.

Figure 6-10 Example Discover Modes response for a given SVID with 3 Modes

Header
VDM Header Mode 1 Mode 2 Mode 3
No. of Data Objects = 4

6.4.4.3.4 Enter Mode Command

The Enter Mode Command is used by an Initiator (DFP) to command a Responder (UFP or Cable Plug) to enter a
specified Mode of operation. Only a DFP is allowed to initiate the Enter Mode Process which it starts after it has
successfully completed the Discovery Process.
The value in the Object Position field in the VDM Header shall indicate to which Mode in the Discover Modes Command
the VDO refers (see Figure 6-10). The value 1 always indicates the first Mode as it is the first object following the VDM
Header. The value 2 refers to the next Mode and so forth.
The Number of Data Objects field in the Message Header in the Command request shall be set to either 1 or 2. The
Enter Mode Command request shall not contain more than 1 VDO. When a VDO is included in an Enter Mode Command
request the contents of the 32 bit VDO is defined by the Mode.
The Number of Data Objects field in the Command response shall be set to 1 since an Enter Mode Command response
(ACK, NAK, BUSY) shall not contain any VDOs.
Before entering a Mode, by sending the Enter Mode Command request, that requires the reconfiguring of any pins on
entry to that Mode, the Initiator shall ensure that those pins being reconfigured are placed into the USB Safe State.
Before entering a Mode that requires the reconfiguring of any pins, the Responder shall ensure that those pins being
reconfigured are placed into either USB operation or the USB Safe State.
A device may support multiple Modes with one or more active at any point in time. Any interactions between them
are the responsibility of the Standard or Vendor. Where there are multiple Active Modes at the same time Modal
Operation shall start on entry to the first Mode.
On receiving an Enter Mode Command request the Responder shall respond with either an ACK or a NAK response.
The Responder is not allowed to return a BUSY response. The value in the Object Position field of the Enter Mode
Command response shall contain the same value as the received Enter Mode Command request.
If the Responder responds to the Enter Mode Command request with an ACK, the Responder shall enter the Mode
before sending the ACK. The Initiator shall enter the Mode on reception of the ACK. Receipt of the GoodCRC Message
corresponding to the ACK confirms to the Responder that the Initiator is in an Active Mode and is ready to operate.
If the Responder responds to the Enter Mode Command request with a NAK, the Mode is not entered. If not presently
in Modal Operation the Initiator shall return to USB operation. If not presently in Modal Operation the Responder
shall remain in either USB operation or the USB Safe State.
If the Initiator fails to receive a response within tVDMWaitModeEntry it shall not enter the Mode but return to USB
operation.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 177
Figure 6-11 shows the sequence of events during the transition between USB operation and entering a Mode. It
illustrates when the Responder’s Mode changes and when the Initiator’s Mode changes. Figure 6-12 illustrates that
when the Responder returns a NAK the transition to a Mode do not take place and the Responder and Initiator remain
in their default USB roles.

Figure 6-11 Successful Enter Mode sequence

DFP (Initiator) UFP (Responder)

USB
USB or USB Safe State
Enter Mod
e

GoodCRC
USB Safe State

ACK
New
Mode
New GoodCRC
Mode

Figure 6-12 Unsuccessful Enter Mode sequence due to NAK

DFP (Initiator) UFP (Responder)

USB
USB or USB Safe State
Enter Mod
e

GoodCRC
USB Safe State

NAK

GoodCRC
USB

Once the Mode is entered, the device shall remain in that Active Mode until the Exit Mode Command is successful (see
Section 6.4.4.3.5).
The following events shall also cause the Port Partners and Cable Plug(s) to exit all Active Modes:
 A PD Hard Reset
 The Port Partners or Cable Plug(s) are disconnected
 A Cable Reset (only exits the Cable Plug’s Active Modes)

Page 178 USB Power Delivery Specification Revision 2.0, Version 1.1
The Initiator shall return to USB Operation within tVDMExitMode of a disconnect or of Hard Reset Signaling being
detected.
The Responder shall return to either USB operation or USB Safe State within tVDMExitMode of a disconnect or of
Hard Reset Signaling being detected.
A DR_Swap Message shall not be sent during Modal Operation between the Port Partners (see Section 6.3.9).

6.4.4.3.5 Exit Mode Command

The Exit Mode Command is used by an Initiator (DFP) to command a Responder (UFP or Cable Plug) to exit its Active
Mode and return to normal USB operation. Only the DFP is allowed to initiate the Exit Mode Process.
The value in the Object Position field shall indicate to which Mode in the Discover Modes Command the VDO refers (see
Figure 6-10) and shall have been used previously in an Enter Mode Command request for an Active Mode. The value 1
always indicates the first Mode as it is the first object following the VDM Header. The value 2 refers to the next Mode
and so forth. A value of 111b in the Object Position field shall indicate that all Active Modes shall be exited.
The Number of Data Objects field in both the Command request and Command response shall be set to 1 since an Exit
Mode Command shall not contain any VDOs.
The Responder shall exit its Active Mode before sending the response Message. The Initiator shall exit its Active Mode
before sending GoodCRC Message in response to the ACK. Receipt of the GoodCRC Message confirms to the
Responder that the Initiator has exited the Mode. The Responder shall not return a BUSY acknowledgement and shall
only return a NAK acknowledgement to a request not containing an Active Mode (i.e. invalid object position). An
Initiator which fails to receive an ACK within tVDMWaitModeExit or receives a NAK or BUSY response shall exit its
Active Mode.
Figure 6-13 shows the sequence of events during the transition between exiting an Active Mode and USB operation. It
illustrates when the Responder’s Mode changes and when the Initiator’s Mode changes.

Figure 6-13 Exit Mode sequence

DFP (Initiator) UFP (Responder)

Mode

Mode
Exit Mode

GoodCRC
USB Safe State

ACK
USB or USB Safe
State
GoodCRC
USB

6.4.4.3.6 Attention
The Attention Command may be used by the Initiator (UFP) to notify the Responder (DFP) that it requires service.
The value in the Object Position field shall indicate to which Mode in the Discover Modes Command the VDO refers (see
Figure 6-10) and shall have been used previously in an Enter Mode Command request for an Active Mode. The value 1
always indicates the first Mode as it is the first object following the VDM Header. The value 2 refers to the next Mode
and so forth. A value of 000b or 111b in the Object Position field shall not be used by the Attention Command.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 179
The Number of Data Objects field in the Message Header shall be set to 1 or 2. The Attention Command shall not
contain more than 1 VDO. When a VDO is included in an Attention Command the contents of the 32 bit VDO is defined
by the Mode. No more than nAttentionCount Commands shall be sent during any given tAttentionAverage (max)
period. The spacing between successive Attention Commands shall be at least tAttentionSpacing except that a single
burst of no more than 2 Attention Commands with a spacing of at least tAttentionBurstSpacing may be sent during
any given tAttentionAverage (max) period.

Figure 6-14 Attention Command request/response sequence

DFP UFP
(Responder) (Initiator)
)
(Attention
Command

GoodCRC

Command Complete

6.4.4.4 Command Processes

The Message flow of Commands during a Process is a query followed by a response. Every Command request sent has
to be responded to with a GoodCRC Message. The GoodCRC Message only indicates the Command request was
received correctly; it does not mean that the Responder understood or even supports a particular SVID. Figure 6-15
shows the request/response sequence including the GoodCRC Messages.

Figure 6-15 Command request/response sequence

Initiator Responder
Command
(request)

GoodCRC

(response)
Command

GoodCRC

Command Complete

In order for the Initiator to know that the Command request was actually consumed, it needs an acknowledgement
from the Responder. There are three responses that indicate the Responder received and processed the Command
request:
 ACK
 NAK
 BUSY
The Responder shall complete:
 Enter Mode requests within tVDMEnterMode
Page 180 USB Power Delivery Specification Revision 2.0, Version 1.1
 Exit Mode requests within tVDMExitMode
 Other requests within tVDMReceiverResponse,
An Initiator not receiving a response within the following times shall timeout and return to either the PE_SRC_Ready
or PE_SNK_Ready state (as appropriate):
 Enter Mode requests within tVDMWaitModeEntry
 Exit Mode requests within tVDMWaitModeExit
 Other requests within tVDMSenderResponse,
The Responder shall respond with:
 ACK if it recognizes the SVID and can process it at this time
 NAK
o if it recognizes the SVID but cannot process the Command request
o or if it does not recognize the SVID
o or if it does not support the Command
o or if a VDO has been supplied which is invalid
 BUSY if it recognizes the SVID and the Command but cannot process the Command request at this time

6.4.4.4.1 Discovery Process

The Initiator (DFP) always begins the Discovery Process. The Discovery Process has two phases. In the first phase,
the Discover SVIDs Command request is sent by the Initiator to get the list of SVIDs the Responder supports. In the
second phase, the Initiator sends a Discover Modes Command request for each SVID supported by both the Initiator
and Responder.
The result of the Discovery Process is that both the Initiator (DFP) and Responder (UFP or Cable Plug) identify the
Modes they mutually support. It is then up to the Initiator to select the Mode it wants to use and use the Enter Mode
Command using the SVID and Object Position appropriate for that Mode.

6.4.4.4.2 Enter Vendor Mode / Exit Vendor Mode Processes

The Initiator (DFP), upon finding a Mode it supports, uses the Enter Mode Command to enable the Mode.
The Responder (UFP or Cable Plug) and Initiator continue using the Active Mode until the Active Mode is exited. In a
managed termination, using the Exit Mode Command, the Active Mode shall be exited in a controlled manner as
described in Section 6.4.4.3.5. In an unmanaged termination, triggered by a Power Delivery Hard Reset (i.e. Hard
Reset Signaling sent by either Port Partner) or by cable detach (device unplugged), the Active Mode shall still be
exited but there may not be a transition through the USB Safe State. In both the managed and unmanaged
terminations the Initiator and Responder return to USB operation as defined in [USBType-C 1.0] following an exit
from a Mode.
The overall Message flow is illustrated in Figure 6-16.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 181
 Figure 6-16 Enter/Exit Mode Process

Initiator (DFP) Responder (UFP or Cable Plug)

Establish PD Contract

Discover SVID
s

s
List of SVID
For every DFP supported SVID
Discover Mod
es (SVID)

r SV ID
Modes fo

Stay in USB mode N Modes Supported?

Enter Mode

ode)
ched to M
nder swit
ACK (Respo

Initiator and Responder operate using Mode

Exit Mode or PD Hard Reset or cable

unplugged or power removed?

Return to USB mode

6.4.4.5 VDM Message Timing and Normal PD Messages

Any Command Process or other VDM sequence may be interrupted by any other USB PD Message. The Vendor or
Standards defined state operation shall comprehend this and continue to operate as expected when processing any
other USB PD Messages.
The timing and interspersing of VDMs between regular PD Messages shall be done without perturbing the PD Message
sequences. This requirement shall apply to both Unstructured VDMs and Structured VDMs. Structured and
Unstructured VDM sequences shall not be atomic although they may require a strict albeit interrupted ordering.
The use of Structured VDMs by an Initiator shall not interfere with the normal PD Message timing requirements nor
shall either the Initiator or Responder interrupt a PD Message sequence (e.g. Power Negotiation, Power Role Swap,
Data Role Swap etc.). The use of Unstructured VDMs shall not interfere with normal PD Message timing.

Page 182 USB Power Delivery Specification Revision 2.0, Version 1.1
VDM sequences shall be interruptible after the return of a GoodCRC Message has been completed. In the case where
there is an error in transmission of the Vendor_Defined Message, as for any other PD Message, the Vendor_Defined
Message will not be retried, but instead the incoming Message will be processed by the Policy Engine. This means that
the Vendor_Defined Message will need to be re-sent after the USB PD Message sequence has completed.
The overall Message flow is illustrated in Figure 6-17.

Figure 6-17 Vendor Defined Message interrupted by a Power Delivery Message

Initiator Responder

VDM (que
ry)

GoodCRC

A command may be interrupted by a PD

message here

nse)
VDM (respo

GoodCRC

Command Complete

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 183
 6.5 Timers
All the following timers are defined in terms of bits on the bus regardless of where they are implemented in terms of
the logical architecture. This is to ensure a fixed reference for the starting and stopping of timers. It is left to the
implementer to ensure that this timing is observed in a real system.

6.5.1 CRCReceiveTimer
The CRCReceiveTimer shall be used by the sender’s Protocol Layer to ensure that a Message has not been lost.
Failure to receive an acknowledgement of a Message (a GoodCRC Message) whether caused by a bad CRC on the
receiving end or by a garbled Message within tReceive is detected when the CRCReceiveTimer expires.
The sender’s Protocol Layer response when a CRCReceiveTimer expires shall be to retry nRetryCount times. Note:
that Cable Plugs do not retry Messages (see Section 6.6.2). Sending of the Preamble corresponding to the retried
Message shall start within tRetry of the CRCReceiveTimer expiring.
The CRCReceiveTimer shall be started when the last bit of the Message EOP has been transmitted by the Physical
Layer. The CRCReceiveTimer shall be stopped when the last bit of the EOP corresponding to the GoodCRC Message
has been received by the Physical Layer.
The Protocol Layer receiving a Message shall respond with a GoodCRC Message within tTransmit in order to ensure
that the sender’s CRCReceiveTimer does not expire. The tTransmit shall be measured from when the last bit of the
Message EOP has been received by the Physical Layer until the first bit of the Preamble of the GoodCRC Message has
been transmitted by the Physical Layer.

6.5.2 SenderResponseTimer
The SenderResponseTimer shall be used by the sender’s Policy Engine to ensure that a Message requesting a
response (e.g. Get_Source_Cap Message) is responded to within a bounded time of tSenderResponse. Failure to
receive the expected response is detected when the SenderResponseTimer expires.
The Policy Engine’s response when the SenderResponseTimer expires shall be dependent on the Message sent (see
Section 8.3).
The SenderResponseTimer shall be started from the time the last bit of the GoodCRC Message EOP (i.e. the GoodCRC
Message corresponding to the Message requesting a response) has been received by the Physical Layer. The
SenderResponseTimer shall be stopped when the last bit of the expected response Message EOP has been received by
the Physical Layer.
The receiver of a Message requiring a response shall respond within tReceiverResponse in order to ensure that the
sender’s SenderResponseTimer does not expire.
The tReceiverResponse time shall be measured from the time the last bit of the Message EOP has been received by
the Physical Layer until the first bit of the response Message Preamble has been transmitted by the Physical Layer.

6.5.3 Activity Timers

The Protocol Layer uses activity timers to ensure that there is adequate activity to allow the Source to know that a
Sink is still present. The activity timer’s value and use are specific to the role the device is playing – either Source or
Sink. The values are selected to allow one missed response to a Ping Message without the Source returning its output
to the default state. Activity Timers are not used in conjunction with the [USBType-C 1.0] connector (see Section
6.3.5.2)

6.5.3.1 SourceActivityTimer
A PD Source that is not using a Type-C connector is required to maintain a minimal level of bus traffic in order to
detect Sink detach. It does so by periodically sending a Ping Message during a connection to a PD Sink, whenever
there is no other Message traffic.

Page 184 USB Power Delivery Specification Revision 2.0, Version 1.1
In order to maintain bus activity the Source shall start its SourceActivityTimer as described in Section 8.3.3.2.
Whenever the timer expires, after tSourceActivity, the Source shall send a Ping Message. It shall then initialize and
restart the SourceActivityTimer ready for the next Ping Message. This ensures that Message activity is maintained in
cases where the time between normal Messages would exceed the Sink’s activity timeout. For example power supply
transitions may take longer than the activity timeout meaning that a Ping is sent prior to the PS_RDY Message.
The SourceActivityTimer shall be reset and restarted on entry to the PE_SRC_Ready state (see Section 8.3.3.2). This
occurs when:
 The last bit of the GoodCRC Message EOP has been received by the Physical Layer (i.e. a Message has been
successfully sent prior to entering the PE_SRC_Ready state).
 The last bit of any Message EOP has been received by the Physical Layer.
 The SenderResponseTimer times out.
A failure to see a GoodCRC Message in response to a Ping Message within tReceive (after nRetryCount retries) is
indicative of a communications failure. This shall cause the Source to send a Soft_Reset Message, transmission of
which shall be completed within tSoftReset of the CRCReceiveTimer expiring (see Section 6.7.1).
See Section 8.3.3.6 for more details of when Ping Messages are transmitted.

6.5.3.2 SinkActivityTimer
The Sink shall support the SinkActivityTimer. Sinks shall observe an absence of a Ping, or other Messages within
tSinkActivity, as an indication of communications failure and as such shall issue Hard Reset Signaling in order to
return to USB Default Operation. Initialization and restarting of the SinkActivityTimer is described in Section
8.3.3.3.7. Any additional action taken is Device implementation specific. Sinks shall also use the absence of VBUS to
return to USB Default Operation unless this is part of an ongoing Power Role Swap sequence.
The SinkActivityTimer shall be re-initialized and re-started when the last bit of a Ping, or any other Message EOP, has
been received by the Physical Layer.
Note: to avoid triggering unnecessary Hard Resets the SinkActivityTimer shall not be run when the Sink is:
 Using a [USBType-C 1.0] connector or
 Using a Type-A operating in its default Source role or using a Type-B connector operating in its default Sink role,
at vSafe5V, in the PE_SNK_Ready state. This is because Ping Messages are optional in these cases, (see Section
6.3.5).
See Section 8.3.3.3 for more details of when the SinkActivityTimer is run.

6.5.4 Capability Timers

Sources and Sinks use Capability Timers to determine attachment of a PD Capable device. By periodically sending or
requesting capabilities it is possible to determine PD device attachment when a response is received.

6.5.4.1 SourceCapabilityTimer
Prior to a successful negotiation a Source shall use the SourceCapabilityTimer to periodically send out a
Source_Capabilities Message every tTypeCSendSourceCap for the Type-C connector and tSendSourceCap for all
other connectors while:
 An A-plug is attached
 The Source is not in an active connection with a PD Sink Port
Whenever there is a SourceCapabilityTimer timeout the Source shall send a Source_Capabilities Message. It shall
then re-initialize and restart the SourceCapabilityTimer. The SourceCapabilityTimer shall be stopped when the last
bit of the EOP corresponding to the GoodCRC Message has been received by the Physical Layer since a PD connection
has been established. At this point the Source waits for a Request Message or a response timeout.
See Section 8.3.3.2 more details of when Source_Capabilities Messages are transmitted.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 185
 6.5.4.2 SinkWaitCapTimer
The Sink shall support the SinkWaitCapTimer. When a Sink observes an absence of Source_Capabilities Messages,
after VBUS is present, for a duration of tTypeCSinkWaitCap for the Type-C connector and tSinkWaitCap for all other
connectors the Sink shall issue Hard Reset Signaling in order to restart the sending of Source_Capabilities Messages
by the Source (see Section 6.6.4).
See Section 8.3.3.3 for more details of when the SinkWaitCapTimer are run.

6.5.4.3 tFirstSourceCap
After Port Partners are attached or after a Hard Reset or after a Power Role Swap a Source shall send its first
Source_Capabilities Message within tFirstSourceCap of VBUS reaching vSafe5V. This ensures that the Sink receives a
Source_Capabilities Message before the Sink’s SinkWaitCapTimer expires.

6.5.5 SinkRequestTimer
The SinkRequestTimer is used to ensure that the time between Sink Request Messages, after a Wait Message has
been received from the Source, is a minimum of tSinkRequest (see Section 6.3.12).
The SinkRequestTimer shall be started when a Wait Message has been received and shall be stopped if any other
Message is received or during a Hard Reset.
The Sink shall wait at least tSinkRequest, after receiving a Wait Message, before issuing a new Request Message.
Whenever there is a SinkRequestTimer timeout the Sink may send a Request Message. It shall then re-initialize and
restart the SinkRequestTimer.

6.5.6 Power Supply Timers

6.5.6.1 PSTransitionTimer
The PSTransitionTimer is used by the Policy Engine to timeout on a PS_RDY Message. It is started when a request for
a new Capability has been accepted and will timeout after tPSTransition if a PS_RDY Message has not been received.
This condition leads to a Hard Reset and a return to USB Default Operation. The PSTransitionTimer relates to the
time taken for the Source to transition from one voltage, or current level, to another (see Section 7.1).
The PSTransitionTimer shall be started when the last bit of an Accept or GotoMin Message EOP has been received by
the Physical Layer. The PSTransitionTimer shall be stopped when the last bit of the PS_RDY Message EOP has been
received by the Physical Layer.

6.5.6.2 PSSourceOffTimer
The PSSourceOffTimer is used by the Policy Engine in Dual-Role Device that is currently acting as a Sink to timeout
on a PS_RDY Message during a Power Role Swap sequence. This condition leads to a Hard Reset and return to USB
Default Operation.
If a PR_Swap Message request has been sent by the Dual-Role Device currently acting as a Source the Sink can
respond with an Accept Message. When the last bit of the EOP of the GoodCRC Message corresponding to this Accept
Message is received by the Sink, then the PSSourceOffTimer shall be started.
If a PR_Swap Message request has been sent by the Dual-Role Device currently acting as a Sink the Source can
respond with an Accept Message. When the last bit of the EOP of this Accept Message is received by the Sink then the
PSSourceOffTimer shall be started.
The PSSourceOffTimer shall be stopped when:
 The last bit of the EOP of the PS_RDY Message is received.
The PSSourceOffTimer relates to the time taken for the remote Dual-Role Device to stop supplying power (see also
Sections 7.3.9 and 7.3.10). The timer shall time out if a PS_RDY Message has not been received from the remote Dual-
Role Device within tPSSourceOff indicating this has occurred.
Page 186 USB Power Delivery Specification Revision 2.0, Version 1.1
 6.5.6.3 PSSourceOnTimer
The PSSourceOnTimer is used by the Policy Engine in Dual-Role Device that has just stopped sourcing power and is
waiting to start sinking power to timeout on a PS_RDY Message during a Power Role Swap. This condition leads to a
Hard Reset and return to USB Default Operation.
The PSSourceOnTimer shall be started when:
 The last bit of the EOP of the GoodCRC Message corresponding to the transmitted PS_RDY Message is received by
the Physical Layer
The PSSourceOnTimer shall be stopped when:
 The last bit of the EOP of the PS_RDY Message is received by the Physical Layer
The PSSourceOnTimer relates to the time taken for the remote Dual-Role Device to start sourcing power (see also
Sections 7.3.9 and 7.3.10) and will time out if a PS_RDY Message indicating this has not been received within
tPSSourceOn.

6.5.7 NoResponseTimer
The NoResponseTimer is used by the Policy Engine in a Source or Sink to determine that its Port Partner is not
responding after a Hard Reset. When the NoResponseTimer times out, the Policy Engine shall issue up to
nHardResetCount additional Hard Resets before determining that the Port Partner is non-responsive to USB Power
Delivery messaging.
If the Sink fails to receive a Source_Capabilities Message received within tNoResponse of:
 The last bit of a Hard Reset Signaling being sent by the PHY Layer if the Hard Reset Signaling was initiated by the
Sink
 The last bit of a Hard Reset Signaling being received by the PHY Layer if the Hard Reset Signaling was initiated by
the Source
Then the Sink shall issue additional Hard Resets up to nHardResetCount times (see Section 6.7.2).
If the Source fails to receive a GoodCRC Message in response to a Source_Capabilities Message within tNoResponse
of:
 The last bit of a Hard Reset Signaling being sent by the PHY Layer if the Hard Reset Signaling was initiated by the
Sink
 The last bit of a Hard Reset Signaling being received by the PHY Layer if the Hard Reset Signaling was initiated by
the Source
Then the Source shall issue additional Hard Resets up to nHardResetCount times (see Section 6.7.2).
For a non-responsive device, the Policy Engine in a Source may either decide to continue sending Source_Capabilities
Messages or to go to non-USB Power Delivery operation and cease sending Source_Capabilities Messages.

6.5.8 BIST Timers

6.5.8.1 tBISTMode
tBISTMode is used to define the maximum time that a UUT has to enter a BIST mode when requested by a Tester.
A UUT shall enter the appropriate BIST mode within tBISTMode of the last bit of the EOP of the BIST Message used to
initiate the test is received by the Physical Layer. When in BIST Receiver Mode the UUT is ready to receive a Test
Frame from the Tester and to respond appropriately with the BISTErrorCounter (see Sections 6.5.8.5 and 6.4.3.1).
When in BIST Transmit mode the UUT starts transmitting Test Frames (see Section 6.4.3.2). For modes transmitting a
continuous carrier signal (i.e. carrier modes and eye pattern) transmission shall start as soon as the UUT enters BIST
mode.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 187
 6.5.8.2 tBISTResponse
tBISTResponse defines the maximum time which a UUT has to respond with a Test Frame when operating in BIST
Transmit Mode (see Section 6.4.3.2).

6.5.8.3 BISTStartTimer
The BISTStartTimer is used by the Tester to ensure that there is a delay of more than tBISTMode before sending the
first Test Frame after requesting BIST Receiver Mode. The BISTStartTimer is initialized and run once the BIST
Message containing the BIST Data Object has been sent i.e. a GoodCRC Message has been received. The first Test
Frame is not sent until after the BISTStartTimer has expired.

6.5.8.4 BISTContModeTimer
The BISTContModeTimer is used by a UUT to ensure that a Continuous BIST Mode is exited in a timely fashion. A
UUT that has been put into a Continuous BIST Mode shall return to normal operation (either
PE_SRC_Transition_to_default, PE_SNK_Transition_to_default, or PE_CBL_Ready) within tBISTContMode of the last
bit of the bit of the EOP of GoodCRC Message sent in response to the BIST Message used to enable the Continuous
BIST Mode.

6.5.8.5 BISTReceiveErrorTimer
The BISTReceiveErrorTimer shall be used by the sender’s Protocol Layer during BIST operation to detect when a
Test Frame has been lost and to trigger the transmission of the next Test Frame. Failure to receive an
acknowledgement of a Test Frame (BIST Message with a BIST Data Object of Returned BIST Counters) whether
caused by a bad CRC on the receiving end or by a garbled Message within tBISTReceive is detected when the
BISTReceiveErrorTimer expires.
The sender’s Protocol Layer response when a BISTReceiveErrorTimer expires shall be to continue operation.
The BISTReceiveErrorTimer shall be started when the nBISTPayload bit past the last bit of the SOP* has been
transmitted by the Physical Layer. The BISTReceiveErrorTimer shall be stopped when the last bit of the EOP
corresponding to the BIST Message with a BIST Data Object of Returned BIST Counters has been received by the
Physical Layer.
The Protocol Layer receiving a Test Frame shall respond with a BIST Message with a BIST Data Object of Returned
BIST Counters within tTransmit in order to ensure that the sender’s BISTReceiveErrorTimer does not expire. The
tTransmit shall be measured from when the last bit of the Test Frame has been received by the Physical Layer until
the first bit of the Preamble of the BIST Message has been transmitted by the Physical Layer.

6.5.9 Power Role Swap Timers

6.5.9.1 SwapRecoveryTimer
The SwapRecoveryTimer is used by a Provider/Consumer acting in Sink role during a Hard Reset. The
Provider/Consumer shall wait tSwapRecover after either sending or receiving Hard Reset Signaling before turning
on its Power Source.

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

Page 188 USB Power Delivery Specification Revision 2.0, Version 1.1
 6.5.10 Hard Reset Timers
6.5.10.1 HardResetCompleteTimer
The HardResetCompleteTimer is used by the Protocol Layer in the case where it has asked the PHY Layer to send
Hard Reset Signaling and the PHY Layer is unable to send the Signaling within a reasonable time due to a non-idle
channel. If the PHY Layer does not indicate that the Hard Reset Signaling has been sent within tHardResetComplete
of the Protocol Layer requesting transmission, then the Protocol Layer shall inform the Policy Engine that the Hard
Reset Signaling has been sent in order to ensure the power supply is reset in a timely fashion.

6.5.10.2 PSHardResetTimer
The PSHardResetTimer is used by the Policy Engine in a Source to ensure that the Sink has had sufficient time to
process Hard Reset Signaling before turning off its power supply to V BUS. The Source shall wait tPSHardReset after
sending Hard Reset Signaling before starting to transition the VBUS voltage to vSafe0V.

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

6.5.11 Structured VDM Timers

6.5.11.1 VDMResponseTimer
The VDMResponseTimer shall be used by the Initiator’s Policy Engine to ensure that a Structured VDM Command
request needing a response (e.g. Discover Identity Command request) is responded to within a bounded time of
tVDMSenderResponse. The VDMResponseTimer shall be applied to all Structured VDM Commands except the Enter
Mode and Exit Mode Commands which have their own timers (VDMModeEntryTimer and VDMModeExitTimer
respectively). Failure to receive the expected response is detected when the VDMResponseTimer expires.
The Policy Engine’s response when the VDMResponseTimer expires shall be dependent on the Message sent (see
Section 8.3).
The VDMResponseTimer shall be started from the time the last bit of the GoodCRC Message EOP (i.e. the GoodCRC
Message corresponding to the VDM Command requesting a response) has been received by the Physical Layer. The
VDMResponseTimer shall be stopped when the last bit of the expected VDM Command response EOP has been
received by the Physical Layer.
The receiver of a Message requiring a response shall respond within tVDMReceiverResponse in order to ensure that
the sender’s VDMResponseTimer does not expire.
The tVDMReceiverResponse time shall be measured from the time the last bit of the Message EOP has been received
by the Physical Layer until the first bit of the response Message Preamble has been transmitted by the Physical Layer.

6.5.11.2 VDMModeEntryTimer
The VDMModeEntryTimer shall be used by the Initiator’s Policy Engine to ensure that the response to a Structured
VDM Enter Mode Command request (ACK or NAK with ACK indicating that the requested Mode has been entered)
arrives within a bounded time of tVDMWaitModeEntry. Failure to receive the expected response is detected when
the VDMModeEntryTimer expires.
The Policy Engine’s response when the VDMModeEntryTimer expires is to inform the Device Policy Manager (see
Section 8.3.3.9.5).
The VDMModeEntryTimer shall be started from the time the last bit of the GoodCRC Message EOP (i.e. the GoodCRC
Message corresponding to the VDM Command request) has been received by the Physical Layer. The

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 189
VDMModeEntryTimer shall be stopped when the last bit of the expected Structured VDM Command response (ACK,
NAK or BUSY) EOP has been received by the Physical Layer.
The receiver of a Message requiring a response shall respond within tVDMEnterMode in order to ensure that the
sender’s VDMModeEntryTimer does not expire.
The tVDMEnterMode time shall be measured from the time the last bit of the Message EOP has been received by the
Physical Layer until the first bit of the response Message Preamble has been transmitted by the Physical Layer.

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

6.5.11.4 tVDMBusy
The Initiator shall wait at least tVDMBusy, after receiving a BUSY Command response, before repeating the Structured
VDM request again.

6.5.12 VCONN Timers

6.5.12.1 VCONNOnTimer
The VCONNOnTimer is used by the DFP or UFP during a VCONN Swap.
The VCONNOnTimer shall be started when:
 The last bit of the EOP of the Accept Message is received by the DFP.
 The last bit of the EOP of GoodCRC Message corresponding to the Accept Message is received by the UFP.
The VCONNOnTimer shall be stopped when:
 The last bit of the EOP of the PS_RDY Message is received by the DFP or UFP.
The DFP or UFP, prior to sending the PS_RDY Message, shall have turned VCONN On.

6.5.12.2 tVCONNSourceOff
The tVCONNSourceOff time applies during a Vconn Swap. The initial VCONN Source shall cease sourcing VCONN within
tVCONNSourceOff of receipt of the last bit of the EOP of the PS_RDY Message.

6.5.13 tCableMessage
The sender of an SOP’ or SOP’’ packet (either a DFP or Cable Plug), that is not a GoodCRC Message, shall wait
tCableMessage after the last bit of the EOP of the GoodCRC transmitted in response to the previous SOP’ or SOP’’
Packet before sending another SOP’ or SOP’’ Packet. This ensures that there is sufficient idle time between packets for

Page 190 USB Power Delivery Specification Revision 2.0, Version 1.1
a UFP to generate an asynchronous Message. Retransmission shall occur as described in Section 6.5.1 with
tCableMessage applying to the last transmitted SOP’ or SOP’’ Packet.

6.5.14 DiscoverIdentityTimer
The DiscoverIdentityTimer is used by a DFP during an Explicit Contract when discovering whether a Cable Plug is PD
Capable using SOP’. When performing cable discovery during an Explicit Contract the Discover Identity Command
request shall be sent every tDiscoverIdentity. No more than nDiscoverIdentityCount Discover Identity Messages
without a GoodCRC Message response shall be sent. If no GoodCRC Message response is received after
nDiscoverIdentityCount Discover Identity Command requests have been sent the DFP shall not send any further
SOP’/SOP’’ Messages.

6.5.15 Attention Timers

Structured VDM Attention Commands are limited to a rate of no more than nAttentionCount Attention Commands
during any given tAttentionAverage period. In addition Structured VDM Attention Commands have to be spaced at
least tAttentionSpacing (min) apart except for a single burst of no more than 2 Attention Commands during any given
tAttentionAverage period that have to be spaced at least tAttentionBurstSpacing apart.
See Section 6.4.4.3.6 for more details.

6.5.16 Time Values and Timers

Table 6-30 summarizes the values for the timers listed in this section. For each Timer Value, a given implementation
shall pick a fixed value within the range specified. Table 6-31 lists the timers.

Table 6-30 Time Values

Parameter Value (min) Value (max) Units Section

tAttentionAverage 10 s 6.5.15

tAttentionBurstSpacing 100 ms 6.5.15

tAttentionSpacing 250 ms 6.5.15

tBISTMode 300 ms 6.5.8.1

tBISTContMode 30 60 ms 6.5.8.4

tBISTReceive 1.0 1.2 ms 6.5.8.5

tBISTResponse 15 ms 6.5.8.2
tCableMessage 750 µs 6.5.13

tDiscoverIdentity 40 50 ms 6.5.13

tDRSwapHardReset 15 ms 6.5.10.3

tFirstSourceCap 250 ms
tHardReset 5 ms 6.3.13

tHardResetComplete 4 5 ms 6.5.10

tNoResponse 4.5 5.5 s 6.5.7

tPSHardReset 25 35 ms 6.5.10.2
tPSSourceOff 750 920 ms 6.5.6.2

tPSSourceOn 390 480 ms 6.5.6.3

tPSTransition 450 550 ms 6.5.6.1

tReceive 0.9 1.1 ms 6.5.1

tReceiverResponse 15 ms 6.5.2

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 191
 Parameter Value (min) Value (max) Units Section
tRetry 75 µs 6.5.1

tSenderResponse 24 30 ms 6.5.2
tSendSourceCap 1 2 s 6.5.4.1

tSinkActivity 120 150 ms 6.5.3.2

tSinkRequest 100 ms 6.5.5

tSinkWaitCap 2.1 2.5 s 6.5.4.2

tSoftReset 15 ms 6.5.3.1, 6.7.1

tSourceActivity 40 50 ms 6.5.3.1

tSwapSinkReady 15 ms 6.5.9.2

tSwapSourceStart 20 ms 6.5.9.2

tTransmit 195 µs 6.5.1

tTypeCSendSourceCap 100 200 ms 6.5.4.1

tTypeCSinkWaitCap 310 620 ms 6.5.4.2

tVCONNSourceOff 25 ms 6.5.12

tVCONNSourceOn 100 ms 6.5.12

tVDMBusy 50 ms 6.5.11.4

tVDMEnterMode 25 ms 6.5.11.2

tVDMExitMode 25 ms 6.5.11.3

tVDMReceiverResponse 15 ms 6.5.11.1
tVDMSenderResponse 24 30 ms 6.5.11.1

tVDMWaitModeEntry 40 50 ms 6.5.11.2

tVDMWaitModeExit 40 50 ms 6.5.11.3

Table 6-31 Timers

Timer Parameter Used By Section

BISTContModeTimer tBISTContMode Policy Engine 6.5.8.4

BISTReceiveErrorTimer tBISTReceive Protocol 6.5.8.5

BISTStartTimer Defined by Tester Policy Engine 6.5.8.3

CRCReceiveTimer tReceive Protocol 6.5.1

DiscoverIdentityTimer tDiscoverIdentity Policy Engine

HardResetCompleteTimer tHardResetComplete Protocol 6.5.10

NoResponseTimer tNoResponse Policy Engine 6.5.7

PSHardResetTimer tPSHardReset Policy Engine 6.5.10.2

PSSourceOffTimer tPSSourceOff Policy Engine 6.5.6.2

PSSourceOnTimer tPSSourceOn Policy Engine 6.5.6.3

PSTransitionTimer tPSTransition Policy Engine 6.5.6.1

SenderResponseTimer tSenderResponse Policy Engine 6.5.2

SinkActivityTimer tSinkActivity Policy Engine 6.5.3.2

SinkRequestTimer tSinkRequest Policy Engine 6.5.5

Page 192 USB Power Delivery Specification Revision 2.0, Version 1.1
 Timer Parameter Used By Section
SinkWaitCapTimer tSinkWaitCap, Policy Engine 6.5.4.2
tTypeCSinkWaitCap
SourceActivityTimer tSourceActivity Policy Engine 6.5.3.1
SourceCapabilityTimer tSendSourceCap, Policy Engine 6.5.4.1
tTypeCSendSourceCap
SwapRecoveryTimer tSwapRecover Policy Engine 6.5.9

SwapSourceStartTimer tSwapSourceStart Policy Engine 6.5.9.2

VCONNOnTimer tVCONNSourceOn Policy Engine 6.5.12.1

VDMModeEntryTimer tVDMWaitModeEntry Policy Engine 6.5.11.2

VDMModeExitTimer tVDMWaitModeExit Policy Engine 6.5.11.3

VDMResponseTimer tVDMSenderResponse Policy Engine 6.5.11.1

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 193
 6.6 Counters
6.6.1 MessageID Counter
The MessageIDCounter is a rolling counter, ranging from 0 to nMessageIDCount, used to detect duplicate Messages.
This value is used for the MessageID field in the Message Header of each transmitted Message.
Each Port shall maintain a copy of the last MessageID value received from its Port Partner. Devices that support
multiple ports, such as Hubs, shall maintain copies of the last MessageID on a per Port basis. A DFP or Source which
communicates using SOP* Packets shall maintain copies of the last MessageID for each type of SOP* it uses.
The transmitter shall use the MessageID in a GoodCRC Message to verify that a particular Message was received
correctly. The receiver shall use the MessageID to detect duplicate Messages.

6.6.1.1 Transmitter Usage

The Transmitter shall use the MessageID as follows:
 Upon receiving either Hard Reset Signaling, or a Soft_Reset Message, the transmitter shall set its
MessageIDCounter to zero and re-initialize its retry mechanism.
 If a GoodCRC Message with a MessageID matching the MessageIDCounter is not received before the
CRCReceiveTimer expires, it shall retry the same packet up to nRetryCount times using the same MessageID.
 If a GoodCRC Message is received with a MessageID matching the current MessageIDCounter before the
CRCReceiveTimer expires, the transmitter shall re-initialize its retry mechanism and increment its
MessageIDCounter.
 If the Message is aborted by the Policy Engine, the transmitter shall delete the Message from it’s transmit buffer,
re-initialize its retry mechanism and increment its MessageIDCounter.

6.6.1.2 Receiver Usage

The Receiver shall use the MessageID as follows:
 When the first good packet is received after a reset, the receiver shall store a copy of the received MessageID
value.
 For subsequent Messages, if MessageID value in a received Message is the same as the stored value, the receiver
shall return a GoodCRC Message with that MessageID value and drop the Message (this is a retry of an already
received Message). Note: this shall not apply to the Soft_Reset Message which always has a MessageID value of
zero.
 If MessageID value in the received Message is different than the stored value, the receiver shall return a GoodCRC
Message with the new MessageID value, store a copy of the new MessageID value and process the Message.

6.6.2 Retry Counter

The RetryCounter is used by a DFP or UFP whenever there is a Message transmission failure (timeout of
CRCReceiveTimer). If the nRetryCount retry fails, then the link shall be reset using the Soft Reset mechanism. Cable
Plugs shall not retry Messages.

6.6.3 Hard Reset Counter

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

6.6.4 Capabilities Counter

The CapsCounter is used to count the number of Source_Capabilities Messages which have been sent by a Source at
power up or after a Hard Reset. Implementation of the CapsCounter is optional but may be used by any Source which
wishes to preserve power by not sending Source_Capabilities Messages after a period of time.

Page 194 USB Power Delivery Specification Revision 2.0, Version 1.1
When the CapsCounter is implemented and the Source detects that a Sink is attached then after nCapsCount
Source_Capabilities Messages have been sent the Source shall decide that the Sink is non-responsive, stop sending
Source_Capabilities Messages and disable PD.
A Sink shall use the SinkWaitCapTimer to trigger the resending of Source_Capabilities Messages by a USB Power
Delivery capable Source which has previously stopped sending Source_Capabilities Messages. Any Sink which is
attached and does not detect a Source_Capabilities Message, shall issue Hard Reset Signaling when the
SinkWaitCapTimer times out in order to reset the Source. Resetting the Source shall also reset the CapsCounter and
restart the sending of Source_Capabilities Messages.

6.6.5 BIST Error Counter

The Tester and UUT shall maintain a count of errors detected BISTErrorCounter (see Sections 6.4.3.1 and 6.4.3.2).
The BISTErrorCounter shall contain the number of bits in error during a BIST Transmit or Receive test.
The BISTErrorCounter shall be a 16-bit counter that shall be set to zero upon the BIST test start. The
BISTErrorCounter shall freeze at a value of FFFFh.

6.6.6 Discover Identity Counter

When sending Discover Identity Messages to a Cable Plug the DFP shall maintain a count of Messages sent
(DiscoverIdentityCounter). No more than nDiscoverIdentityCount Discover Identity Messages shall be sent by the
DFP receiving a GoodCRC Message response. A Data Role Swap shall reset the DiscoverIdentityCounter to zero.

6.6.7 VDMBusyCounter
When sending Responder Busy responses to a Structured Vendor_Defined Message a UFP or Cable Plug shall maintain
a count of Messages sent (VDMBusyCounter). No more than nBusyCount Responder Busy responses shall be sent.
The VDMBusyCounter shall be reset on sending a non-Busy response. Products wishing to meet [USBType-C 1.0]
requirements for Mode entry should use an nBusyCount of 1.

6.6.8 nAttentionCount
Structured VDM Attention Commands are limited to a rate of no more than nAttentionCount Attention Commands
during any given tAttentionAverage period (see Section 6.4.4.3.6).

6.6.9 Counter Values and Counters

Table 6-33 lists the counters used in this section and Table 6-32 shows the corresponding parameters.

Table 6-32 Counter parameters

Parameter Value Section

nAttentionCount 10 6.6.8

nBusyCount 5 6.6.7

nCapsCount 50 6.6.4

nDiscoverIdentityCount 20 6.6.6
nHardResetCount 2 6.6.3

nMessageIDCount 7 6.6.1

nRetryCount 3 6.6.2

Table 6-33 Counters

Counter Max Section

BISTErrorCounter FFFFh 6.6.5

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 195
 Counter Max Section
CapsCounter nCapsCount 6.6.4

DiscoverIdentityCounter nDiscoverIdentityCount 6.6.6

HardResetCounter nHardResetCount 6.6.3

MessageIDCounter nMessageIDCount 6.6.1

RetryCounter nRetryCount 6.6.2

VDMBusyCounter nBusyCount 6.6.7

6.7 Reset
Resets are a necessary response to protocol or other error conditions. USB Power Delivery defines two different types
of reset; a Soft Reset, that resets protocol, and a Hard Reset which resets both the power supplies and protocol.

6.7.1 Soft Reset

A Soft_Reset Message is used to cause a Soft Reset of protocol communication when this has broken down in some
way. It shall not have any impact on power supply operation, but shall be used whenever there is a Protocol Error.
The Soft Reset may be triggered by either Port Partner in response to an error.
Protocol Errors that shall lead to a Soft Reset are unexpected Messages during one of the atomic Message sequences
defined in Section 8.3.2. In this case the Policy Engine state machines need to be resychronized. An unrecognized
Message, received in the PE_SNK_Ready or PE_SRC_Ready states, shall not cause a Soft_Reset Message to be generated
but shall be Ignored.
A failure to see a GoodCRC Message in response to any Message within tReceive (after nRetryCount retries), when a
Port Pair is Connected, is indicative of a communications failure. This shall cause the Source to send a Soft_Reset
Message, transmission of which shall be completed within tSoftReset of the CRCReceiveTimer expiring.
A Soft Reset shall impact the USB Power Delivery layers in the following ways:
 Physical Layer: Reset not required since the Physical Layer resets on each packet transmission/reception
 Protocol Layer: Reset MessageIDCounter, RetryCounter and state machines
 Policy Engine: Reset state dependent behavior by performing an Explicit Contract negotiation
 Power supply: Shall not change
A Soft Reset is performed using a sequence of protocol Messages (see Table 8-6). Message numbers shall be set to
zero prior to sending the Soft_Reset/Accept Message since the issue may be with the counters. The sender of a
Soft_Reset Message shall reset its MessageIDCounter and RetryCounter, the receiver of the Message shall reset its
MessageIDCounter and RetryCounter before sending the Accept Message response. Any failure in the Soft Reset
process will trigger a Hard Reset when SOP Packets are being used or Cable Reset for any other SOP* Packets; for
example a GoodCRC Message is not received during the Soft Reset process (see Sections 6.7.2 and ).

6.7.2 Hard Reset

6.7.2.1 Hard Reset Common Requirements
Hard Resets are signaled by an ordered set as defined in Section 5.6.4. Both the sender and recipient shall cause their
power supplies to return to their default states (see Sections 7.3.12 to 7.3.14.4 for details of voltage transitions). In
addition their respective Protocol Layers shall be reset as for the Soft Reset. This allows the attached devices to be in
a state where they can re-establish USB PD communication. Hard Reset is retried up to nHardResetCount times (see
also Sections 6.5.7 and 6.6.3). Note: that even though VBUS drops to vSafe0V during a Hard Reset a Sink will not see
this as a disconnect since this is expected behavior.

Page 196 USB Power Delivery Specification Revision 2.0, Version 1.1
 6.7.2.2 Type-A/B and Hard Reset
When there has been a Type-A/B Power Role Swap, a Hard Reset shall cause the Port Partners to return to their
default Source/Sink roles. A Type-A Port shall return to Source operation. A Type-B Port shall return to Sink
operation.

6.7.2.3 Type-C and Hard Reset

A Hard Reset shall not cause any change to either the Rp/Rd resistor being asserted.
If there has been a Data Role Swap the Hard Reset shall cause the Port Data Role to be changed back to DFP for a Port
with the Rp resistor asserted and UFP for a Port with the Rd resistor asserted.
When VCONN is supported (see [USBType-C 1.0]) the Hard Reset shall cause the Port with the Rp resistor asserted to
supply VCONN and the Port with the Rd resistor asserted to turn off VCONN.
In effect the Hard Reset will revert the Ports to their default state based on their CC line resistors. Removing and
reapplying VCONN from the Cable Plugs also ensures that they re-establish their configuration as either SOP’ or SOP’’
based on the location of VCONN (see [USBType-C 1.0]).
If the Hard Reset is insufficient to clear the error condition then the Port should use error recovery mechanisms as
defined in [USBType-C 1.0].

6.7.2.4 Cable Plugs and Hard Reset

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

6.7.2.5 Modal Operation and Hard Reset

A Hard Reset shall cause all Active Modes to be exited by both Port Partners and any Cable Plugs (see Section
6.4.4.3.4).

6.7.3 Cable Reset

Cable Resets are signaled by an ordered set as defined in Section 5.6.5. Both the sender and recipient of Cable Reset
Signaling shall reset their respective Protocol Layers. The Cable Plugs shall perform the equivalent of a power cycle
returning to their initial power up state. This allows the attached products to be in a state where they can re-establish
USB PD communication.
The DFP has to be supplying VCONN prior to a Cable Reset to ensure that the Cable Plugs correctly configure SOP’ and
SOP’’ after the Cable Reset is complete. If VCONN has been turned off the DFP shall turn on VCONN prior to generating
Cable Reset Signaling. If there has been a VCONN Swap and the UFP is currently supplying VCONN, the DFP shall
perform a VCONN Swap such that it is supplying VCONN prior to generating Cable Reset Signaling.
Only a DFP shall generate Cable Reset Signaling. A DFP shall only generate Cable Reset Signaling within an Explicit
Contract.
A Cable Reset shall cause all Active Modes in the Cable Plugs to be exited (see Section 6.4.4.3.4).

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 197
 6.8 State behavior
6.8.1 Introduction to state diagrams used in Chapter 6
The state diagrams defined in Section 6.8 are normative and shall define the operation of the Power Delivery protocol
layer. Note that these state diagrams are not intended to replace a well written and robust design.
Figure 6-18 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 6-18 Outline of States

<Name of State>
Actions on entry:
“List of actions to carry out on entering the
state”
Actions on exit:
“List of actions to carry out on exiting the
state”

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 6-19 indicates how such
references are made. The reference is indicated with a hatched box. The box contains the name of the referenced
state.

Figure 6-19 References to states

<Name of reference state>

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.
Timeouts of the timers are listed as conditions on state transitions.
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.)

6.8.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 BIST State Machine instances, with their own counter and timer 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).

Page 198 USB Power Delivery Specification Revision 2.0, Version 1.1
 6.8.2.1 Protocol Layer Message Transmission
Figure 6-20 shows the state behavior for the Protocol Layer when transmitting a Message.

Figure 6-20 Protocol Layer Message transmission

Start Soft Reset Message from PHY Layer |

Exit from Hard Reset

PRL_Tx_Discard_Message
PRL_Tx_PHY_Layer_Reset Actions on entry: Protocol Layer
If any message is currently awaiting message reception
Actions on entry: Discarding transmission discard and increment in PRL_Rx_Store_MessageID state
Reset PHY Layer complete MessageID Counter

PRL_Tx_Layer_Reset_for
_Transmit
Actions on entry:
PHY Layer reset Reset MessageIDCounter.
complete Protocol Layer message reception
transitions to
PRL_Rx_Wait_for_PHY_Message
state.
Soft Reset Message request received Layer Reset Complete
from Policy Engine
PRL_Tx_Wait_for_ PRL_Tx_Construct_Message
Message_Request
Actions on entry:
Actions on entry: Message request received Construct message
Reset RetryCounter Pass message to PHY Layer
from Policy Engine (except Soft Reset)

(RetryCounter ≤ nRetryCount) &

not Cable Plug
Message sent to
Policy Engine informed PHY Layer
of Transmission Error

PRL_Tx_Transmission_Error PRL_Tx_Check_RetryCounter PRL_Tx_Wait_for_PHY_response

Policy Engine (RetryCounter CRCReceiveTimer
Actions on entry: Actions on entry: Actions on entry:
informed > nRetryCount) | Timeout |
Increment MessageIDCounter If DFP or UFP increment and check Initialize and run CRCReceiveTimer1
message sent Cable Plug RetryCounter Message discarded bus Idle2
Inform Policy Engine of
Transmission Error

GoodCRC response
MessageID mismatch received from PHY Layer

PRL_Tx_Message_Sent PRL_Tx_Match_MessageID
Actions on entry: MessageID match Actions on entry:
Increment MessageIDCounter Match MessageIDCounter and
Inform Policy Engine message response MessageID
sent

1The 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 6.5.1).
2This indication is sent by the PHY Layer when a message has been discarded due to VBUS or CC being busy, and
after VBUS or CC becomes idle again (see Section 5.7). The CRCReceiveTimer is not running in this case since no
message has been sent.

6.8.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:

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 199
 When the PHY Layer reset is complete.

6.8.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.

6.8.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 6.8.2.2.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.

6.8.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:
 The Message has been sent to the PHY Layer.

6.8.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 6.5.1).
The Protocol Layer shall transition to the PRL_Tx_Match_MessageID state when:
 A GoodCRC Message response is receive 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.7).

6.8.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.

Page 200 USB Power Delivery Specification Revision 2.0, Version 1.1
 6.8.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.

6.8.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 that
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.
The Protocol Layer shall transition to the PRL_Tx_Transmission_Error state when:
 RetryCounter > nRetryCount or
 This is a Cable Plug, which does not retry.

6.8.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.

6.8.2.1.10 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.
On entry to the PRL_Tx_Discard_Message state, if there is a Message queued awaiting transmission, the Protocol
Layer shall discard the Message 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.

6.8.2.2 Protocol Layer Message Reception

Figure 6-21 shows the state behavior for the Protocol Layer when receiving a Message.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 201
 Figure 6-21 Protocol layer Message reception

PRL_Rx_Layer_Reset_
for_Receive
Actions on entry:
Reset MessageIDCounter and clear
stored MessageID value
Soft Reset request from Policy Engine | Protocol Layer message
transmission transitions to
Exit from Hard Reset PRL_Tx_PHY_Layer_Reset state.

Start
Soft Reset Message received Soft Reset complete
from PHY

Message received
PRL_Rx_Wait_for_PHY_ from PHY (except Soft Reset) PRL_Rx_Send_GoodCRC
message
Actions on entry:
Actions on entry:
Message discarded bus Idle1 Send GoodCRC message to PHY

MessageID = stored
Message passed to MessageID (GoodCRC sent | Message discarded bus Idle1)
Policy Engine

PRL_Rx_Store_MessageID
PRL_Rx_Check_MessageID
Actions on entry:
Actions on entry:
Protocol Layer message transmission MessageID <> stored If there is a stored value compare
transitions to PRL_Tx_Discard_Message MessageID | MessageID with stored value.
state2. no stored value
Store new MessageID
Pass message to Policy Engine

1This indication is sent by the PHY when a message has been discarded due to V BUS or CC being busy, and
after VBUS or CC becomes idle again (see Section 5.7). Two alternate allowable transitions are shown.
2In 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.

6.8.2.2.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.
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.

Page 202 USB Power Delivery Specification Revision 2.0, Version 1.1
 6.8.2.2.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 6.8.2.1.1).
The Protocol Layer shall transition to the PRL_Rx_Send_GoodCRC State when:
 The Soft Reset actions in this state have been completed.

6.8.2.2.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 VBUS or CC being busy but VBUS or CC is now
idle (see Section 5.7), the Protocol Layer shall either:
 Transition to the PRL_Rx_Check_MessageID state or
 Transition to the PRL_Rx_Wait_for_PHY_Message state

6.8.2.2.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

6.8.2.2.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 (except when a Ping Message has been received in which case the
PRL_Tx_Discard_Message state should not be entered), replace the stored value of MessageID with the value of
MessageID in the received Message and pass the Message up to the Policy Engine.
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.

6.8.2.3 Hard Reset operation

Figure 6-22 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 Physical Layer (see also Sections 6.7.2
and 6.7.3).

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 203
 Figure 6-22 Hard/Cable Reset

Hard Reset request received from Policy Engine2 |

Cable Reset request received from Policy Engine4 |
Hard Reset signalling received By PHY Layer |
Cable Reset signalling received By PHY Layer3

PRL_HR_Reset_Layer
Actions on entry:
Reset MessageIDCounter.
Protocol Layer message transmission
transitions to
PRL_Tx_Wait_For_Message_Request state.
Protocol Layer message reception transitions
to PRL_Rx_Wait_for_PHY_Message state.

Protocol Layer reset complete & Protocol Layer reset complete &
(Hard Reset was Initiated by Policy Engine | (Hard Reset was initiated by Port Partner |
Cable Reset was Initiated by Policy Engine) Cable Reset received by Cable Plug)

PRL_HR_Request_Hard_Reset PRL_HR_Indicate_Hard_Reset
Actions on entry: Actions on entry:
Request PHY to perform a Hard Reset Inform the Policy Engine of the Hard
or Cable Reset Reset or Cable Reset

PHY Hard Reset request sent |

PHY Cable Reset request sent

PRL_HR_Wait_For_PHY_
Hard_Reset_Complete
Actions on entry:
Start HardResetCompleteTimer
Wait for Hard Reset or Cable Reset complete
indication from PHY

Policy Engine informed

Hard Reset complete from PHY |
Cable Reset complete from PHY |
HardResetCompleteTimer timeout1

PRL_HR_PHY_Hard_Reset_Requested
Actions on entry:
Inform Policy Engine Hard Reset or Cable
Reset request has been sent

Policy Engine informed

PRL_HR_Wait_For_PE_Hard_Reset_Complete
Actions on entry:
Wait for Hard Reset or Cable Reset complete indication
from Policy Engine.

Hard Reset complete from Policy Engine |

Cable Reset complete from Policy Engine

PRL_HR_PE_Hard_Reset_Complete
Actions on entry:
Inform Physical Layer Hard Reset or
Cable Reset is complete

Physical Layer informed

Exit from Hard Reset

1 If the HardResetTimer 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 CablePlugs 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 signalling is only recognised by a Cable Plug.
4 Cable Reset signaling cannot be generated by Cable Plugs

Page 204 USB Power Delivery Specification Revision 2.0, Version 1.1
 6.8.2.3.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 Physical 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 Physical Layer or
 A Cable Reset Request is received from the Policy Engine or
 Cable Reset Signaling is received from the Physical 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
o The Hard Reset request has originated from the Policy Engine or
o 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
o The Hard Reset request has been passed up from the Physical Layer or
o A Cable Reset request has been passed up from the Physical Layer (Cable Plug only).

6.8.2.3.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.

6.8.2.3.3 PRL_HR_Request_Hard_Reset state

On entry to the PRL_HR_Request_Hard_Reset state the Protocol Layer shall request the Physical Layer to send either
Hard Reset Signaling or Cable Reset signaling .
The Protocol Layer shall transition to the PRL_HR_Wait_for_PHY_Hard_Reset_Complete state when:
 The Physical Layer Hard Reset Signaling request has been sent or
 The Physical Layer Cable Reset Signaling request has been sent.

6.8.2.3.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_PE_Hard_Reset_Complete state when:
 A Hard Reset complete indication is received from the PHY Layer or

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 205
 A Cable Reset complete indication is received from the PHY Layer or
 The HardResetCompleteTimer times out.

6.8.2.3.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.

6.8.2.3.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.

6.8.2.3.7 PRL_HR_PE_Hard_Reset_Complete
On entry to the PRL_HR_PE_Hard_Reset_Complete state the Protocol Layer shall inform the Physical 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 Physical 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 Physical Layer has been informed that the Cable Reset is complete.

Page 206 USB Power Delivery Specification Revision 2.0, Version 1.1
 6.8.3 BIST Operation
6.8.3.1 BIST Transmitter Test
Figure 6-23 shows the state behavior for the Protocol Layer when in BIST Transmitter Test mode and transmitting
BIST Transmitter Test Frames. The Protocol Layer changes from normal operation for Protocol Message Layer
Transmission (see Section 6.8.2.1) to BIST Transmitter Test Mode when directed by the Policy Engine.

Figure 6-23 BIST Transmitter Test

PRL_Tx_Wait_For_
Message_Request

BIST Tx Test Mode Request

received from Policy Engine

PRL_BIST_Tx_Init_PRBS
Actions on entry:
Request Physical Layer to Reset
BISTErrorCounter and preload PRBS

PRBS initialized

PRL_BIST_Tx_Wait_Test
_Frame_Request
Actions on entry:
Wait for Tx Test Frame request from
Policy Engine

Tx Test Frame request

received from Policy Engine

PRL_BIST_Tx_Test_Frame
Actions on entry:
Request PHY to Construct Tx Test
Frame Error Counter response
received from PHY |
BISTReceiveErrorTimer
timeout
Tx Test Frame request
sent to PHY

PRL_BIST_Tx_PHY_Response
Actions on entry:
Wait for PHY response
Initialize and run
BISTReceiveErrorTimer

Actions on exit:
Inform Policy Engine of Error Count or
timeout

6.8.3.1.1 PRL_BIST_Tx_Init_PRBS state

The Protocol Layer shall enter the PRL_BIST_Tx_Init_PRBS state from the PRL_Tx_Wait_for_Message_Request state
(see Section 6.8.2.1.1) when:
 The Policy Engine requests the Protocol Layer to enter BIST Transmitter Test Mode.
On entry to the PRL_BIST_Tx_Init_PRBS state the Protocol Layer shall request the Physical Layer to reset the
BISTErrorCounter and preload the PRBS (see Section 5.9.1).
The Protocol Layer shall transition to the PRL_BIST_Tx_Wait_Test_Frame_Request state when:
 The PRBS generator has been preloaded.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 207
 6.8.3.1.2 PRL_BIST_Tx_Wait_Test_Frame_Request state
On entry to the PRL_BIST_Tx_Wait_Test_Frame_Request state the Protocol Layer shall wait for a Test Frame from the
Policy Engine.
The Protocol Layer shall transition to the PRL_BIST_Tx_Test_Frame state when:
 When a request to transmit a Test Frame is received from the Policy Engine.

6.8.3.1.3 PRL_BIST_Tx_Test_Frame state

On entry to the PRL_BIST_Tx_Test_Frame state the Protocol Layer shall request the Physical Layer to construct the
Test Frame.
The Protocol Layer shall transition to the PRL_BIST_Tx_PHY_Response state when:
 The Test Frame request has been sent to the Physical Layer.

6.8.3.1.4 PRL_BIST_Tx_PHY_Response state

In the PRL_BIST_Tx_PHY_Response state the Protocol Layer shall wait for the Physical Layer to provide a response to
the Test Frame.
On entry to the PRL_BIST_Tx_PHY_Response state the Protocol Layer shall initialize and run the
BISTReceiveErrorTimer.
On exit from the PRL_BIST_Tx_PHY_Response state the Protocol Layer shall inform the Policy Engine either of the
received Error Counter value or of a BISTReceiveErrorTimer timeout.
The Protocol Layer shall transition to the PRL_BIST_Tx_Wait_Test_Frame_Request state (see Section 6.8.3.1.2) when:
 An error counter response is received from the Physical Layer.
 Or the BISTReceiveErrorTimer times out.

6.8.3.2 BIST Receiver Test

Figure 6-24 shows the state behavior for the Protocol Layer when in BIST Receiver Test mode and receiving BIST
Receiver Test Frames. The Protocol Layer changes from normal operation for Protocol Layer Message Reception (see
Section 6.8.2.2) to BIST Receiver Test Mode when directed by the Policy Engine. Exit from this mode of operation is
via Hard Reset (see Section 6.8.2.3).

Page 208 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 6-24 BIST Receiver Test

PRL_Rx_Wait_for_PHY_Message

BIST Rx Test Mode Request

received from Policy Engine

PRL_BIST_Rx_Reset_Counter
Actions on entry:
Request Physical Layer to Reset
BISTErrorCounter and preload PRBS

BISTErrorCounter
reset

PRL_BIST_Rx_Test_Frame

Actions on entry:
Wait for test Frame from PHY
(Receiver Test)

BISTErrorCounter
received from PHY

PRL_BIST_Rx_Error_Count
Actions on entry:
Construct and send BIST error Policy Engine informed
count message to PHY

Error Count sent

PRL_BIST_Rx_Inform_Policy
Actions on entry:
Inform Policy Engine Error Count
has been sent

6.8.3.2.1 PRL_BIST_Rx_Reset_Counter state

The Protocol Layer shall enter the PRL_BIST_Rx_Reset_Counter state from the PRL_Rx_Wait_for_PHY_Message states
when:
 A BIST Receiver Test Mode request is received from the Policy Engine.
On entry to the PRL_BIST_Rx_Reset_Counter state the Protocol Layer shall request the Physical Layer to reset the
BISTErrorCounter and preload the PRBS (see Section 5.9.1).
The Protocol Layer shall transition to the PRL_BIST_Rx_Test_Frame state when:
 The BISTErrorCounter has been reset by the Physical Layer.

6.8.3.2.2 PRL_BIST_Rx_Test_Frame state

In the PRL_BIST_Rx_Test_Frame State the Protocol Layer shall wait for the Physical Layer to receive the next Test
Frame.
The Protocol Layer shall transition to the PRL_BIST_Rx_Error_Count state when:
 The current value of the BISTErrorCounter is received from the PHY Layer.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 209
 6.8.3.2.3 PRL_BIST_Rx_Error_Count state
On entry to the PRL_BIST_Rx_Error_Count state the Protocol Layer shall construct a BIST Message with a BIST Data
Object of Returned BIST Counters using the BISTErrorCounter value returned by the Physical Layer. This BIST
Message shall be passed to the Physical Layer for transmission.
The Protocol Layer shall transition to the PRL_BIST_Rx_Inform_Policy state when:
 The BIST Message has been sent.

6.8.3.2.4 PRL_BIST_Rx_BIST_Inform_Policy state

On entry to the PRL_BIST_Rx_Inform_Policy state the Protocol Layer shall inform the Policy Engine that the BIST
Message containing the BISTErrorCounter has been sent.
The Protocol Layer shall transition to the PRL_BIST_Rx_Test_Frame state when:
 The Policy Engine has been informed that the BIST Message containing the BISTErrorCounter has been sent.

Page 210 USB Power Delivery Specification Revision 2.0, Version 1.1
 6.8.4 List of Protocol Layer States
Table 6-34 lists the states used by the various state machines.

Table 6-34 Protocol Layer States

State name Section

Protocol Layer Message Transmission
PRL_Tx_PHY_Layer_Reset 6.8.2.1.1

PRL_Tx_Wait_for_Message_Request 6.8.2.1.2
PRL_Tx_Layer_Reset_for_Transmit 6.8.2.1.3

PRL_Tx_Construct_Message 6.8.2.1.4

PRL_Tx_Wait_for_PHY_Response 6.8.2.1.5

PRL_Tx_Match_MessageID 6.8.2.1.6
PRL_Tx_Message_Sent 6.8.2.1.7

PRL_Tx_Check_RetryCounter 6.8.2.1.8

PRL_Tx_Transmission_Error 6.8.2.1.9

PRL_Tx_Discard_Message 6.8.2.1.10
Protocol Layer Message Reception
PRL_Rx_Wait_for_PHY_Message 6.8.2.2.1

PRL_Rx_Layer_Reset_for_Receive 6.8.2.2.2

PRL_Rx_Send_GoodCRC 6.8.2.2.3
PRL_Rx_Check_MessageID 6.8.2.2.4

PRL_Rx_Store_MessageID 6.8.2.2.5
Hard Reset Operation
PRL_HR_Reset_Layer 6.8.2.3.1
PRL_HR_Indicate_Hard_Reset 6.8.2.3.2

PRL_HR_Request_Hard_Reset 6.8.2.3.3

PRL_HR_Wait_for_PHY_Hard_Reset_Complete 6.8.2.3.4

PRL_HR_PHY_Hard_Reset_Requested 6.8.2.3.5

PRL_HR_Wait_for_PE_Hard_Reset_Complete 6.8.2.3.6
PRL_HR_PE_Hard_Reset_Complete 6.8.2.3.7
BIST Transmitter Test
PRL_BIST_Tx_Init_PRBS 6.8.3.1.1

PRL_BIST_Tx_Wait_Test_Frame_Request 6.8.3.1.2
PRL_BIST_Tx_Test_Frame 6.8.3.1.3

PRL_BIST_Tx_PHY_Response 6.8.3.1.4
BIST Receiver Test
PRL_BIST_Rx_Reset_Counter 6.8.3.2.1
PRL_BIST_Rx_Test_Frame 6.8.3.2.2

PRL_BIST_Rx_Error_Count 6.8.3.2.3

PRL_BIST_Rx_Inform_Policy 6.8.3.2.4

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 211
 6.9 Message Applicability
The following tables outline the Messages supported by a given port, depending on its capability.
When a Message is supported the feature and Message sequence implied by the Message shall also be supported. For
example Sinks using power for charging that support the GotoMin Message shall be able to reduce their current draw
when requested via a GotoMin Message.
The following abbreviations are used:
 M – Mandatory; shall be supported by this Port/Cable Plug
 CM – Conditionally Mandatory; shall be supported by a given Port/Cable Plug based on features
 R – Recommended; should be supported by this Port/Cable Plug
 O – Optional; may be supported by this Port/Cable Plug
 NS – Not Supported; shall not by transmitted by this Port/Cable Plug and shall be Ignored by this Port/Cable Plug
when received.
 RJ – Reject; this Port/Cable Plug shall return a Reject Message when received
 NK – NAK; this Port/Cable Plug shall return Responder NAK to this Command when received
For the case of Conditional Mandatory a note has been added to indicate the condition. “CM/” notation is used to
indicate the level of support when the condition is not present.
“R/” and “O/” notation is used to indicate the response when the Recommended or Optional Message is not supported.
Note: that where NS/RJ/NK is indicated for Received Messages this shall apply to the PE_CBL_Ready, PE_SNK_Ready
or PE_SRC_Ready states only since unexpected Messages received during a Message sequence are Protocol Errors (see
Section 6.7.1).
This section covers Control and Data Message support for Sources, Sink and Cable Plugs. It also covers VDM
Command support for DFPs, UFPs and Cable Plugs.
Table 6-35 details Control Messages (except for those specific to the Type-C connector) that shall/should/shall not be
transmitted and received by a Source, Sink or Cable Plug. Requirements for Dual-Role Power Ports shall override any
requirements for Source-only or Sink-Only Ports.

Table 6-35 Applicability of Control Messages

Message Type Source Sink Dual-Role Cable Plug

Power
Transmitted Message
GoodCRC M M M
GotoMin CM1/O NS NS

Accept M M M

Reject M M NS

Ping CM2/O NS NS
PS_RDY M NS M NS

Get_Source_Cap O M M NS

Get_Sink_Cap M O M NS

PR_Swap NS NS M NS
Wait CM3/O NS O NS

Soft_Reset M M NS
Received Message
GoodCRC M M M

Page 212 USB Power Delivery Specification Revision 2.0, Version 1.1
 Message Type Source Sink Dual-Role Cable Plug
Power
GotoMin NS R4 NS

Accept M M NS
Reject M M NS

Ping NS NS NS

PS_RDY NS M M NS

Get_Source_Cap M RJ M NS
Get_Sink_Cap RJ M M NS

PR_Swap RJ RJ M NS

Wait NS M M NS

Soft_Reset M M M
Note 1: Shall be supported by a Hub with multiple Downstream Ports. Should be
supported by a Host with multiple Downstream Ports.
Note 2: Shall be supported by BFSK systems.
Note 3: Shall be supported when transmission of GotoMin Messages is supported.
Note 4: Should be supported by Sinks which use PD power for charging.

Table 6-36 details Control Messages specific to the Type-C connector that shall/should/shall not be transmitted and
received by a DFP, UFP or Cable Plug. Requirements for Dual-Role Data Ports shall override any requirements for
DFP-only or UFP-Only Ports.

Table 6-36 Applicability of Type-C Specific Control Messages

Message Type DFP UFP Dual-Role Cable Plug

Sent Data
Transmitted Message
DR_Swap NS NS M NS

Wait O

VCONN_Swap R R NS
Received Message
DR_Swap RJ RJ M NS

Wait M

VCONN_Swap CM1/RJ CM1/RJ NS

Note 1: Shall be supported by any Type-C Port that that utilizes the SSTX and
SSRX pins and supports the PR_Swap Message.

Table 6-37 details Data Messages (except for VDM Commands) that shall/should/shall not be transmitted and
received by a Source, Sink or Cable Plug. Requirements for Dual-Role Power Ports shall override any requirements for
Source-only or Sink-Only Ports.

Table 6-37 Applicability of Data Messages

Message Type Source Sink Dual-Role Cable Plug

Power
Transmitted Message
Source_Capabilities M NS M NS
Request NS M NS

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 213
 Message Type Source Sink Dual-Role Cable Plug
Power
BIST M2 M2 NS

Sink_Capabilities NS M M NS
Received Message
Source_Capabilities NS1 M M NS

Request M NS NS

BIST M2 M2 M2
Sink_Capabilities M NS M NS
Note 1: See Section 6.4.1.2.2.
Note 2: For details of which BIST Modes and Messages shall be supported see Sections 5.9.9 and
6.4.3.

Table 6-38 details VDM Commands that shall/should/shall not be transmitted and received by a DFP, UFP or Cable
Plug. Requirements for Modal Operation shall override any requirements for DFP or UFP Ports or Cable Plugs without
Modal Operation.

Table 6-38 Applicability of VDM Commands

Command Type DFP UFP Cable Plug Modal

Operation
Supported
Transmitted Command
Discover Identity R R2 NS CM1

Discover SVIDs NS NS NS CM1

Discover Modes NS NS NS CM1

Enter Mode NS NS NS CM1

Exit Mode NS NS NS CM1

Attention NS O NS
Received Command
Discover Identity NS R/NK M CM3

Discover SVIDs NS NK NK CM3

Discover Modes NS NK NK CM3

Enter Mode NS NK NK CM3

Exit Mode NS NK NK CM3

Attention O/NS NK NS
Note 1: Shall only be supported by a DFP.
Note 2: May be transmitted by a UFP/Source during discovery (see Sections 6.4.4.3.1 and
8.3.3.10.11).
Note 3: Shall only be supported by a UFP or Cable Plug.

Page 214 USB Power Delivery Specification Revision 2.0, Version 1.1
7. Power Supply
7.1 Source Requirements
7.1.1 Behavioral Aspects
The Source in a Provider or Provider/Consumer exhibits the following behaviors.
 Shall be backward compatible with legacy VBUS ports.
 Shall supply the default [USB 2.0], [USB 3.1], [USBType-C 1.0] or [BC 1.2] voltage and current to VBUS when the
USB cable is attached (USB Default Operation).
 Shall supply the default [USB 2.0], [USB 3.1], [USBType-C 1.0] or [BC 1.2] voltage and current to VBUS when a
Contract does not exist (USB Default Operation).
 Shall return vSafe0V for some time then return to vSafe5V when Hard Reset Signaling is received.
 Shall control VBUS voltage transitions as bound by undershoot, overshoot and transition time requirements.
The Source in a Consumer/Provider exhibits the following behaviors.
 Shall support Dead Battery operation as defined in Section 4.1.1 for Type-A to Type-B connections and as defined
in [USBType-C 1.0] for Type-C to Type-C connections.
 Shall return to Sink operation when Hard Reset Signaling is received.
 Shall control VBUS voltage transitions as bound by undershoot, overshoot and transition time requirements.

7.1.2 Source Bulk Capacitance

The Source shall have a bulk capacitance located between the output of the power supply and the transceiver isolation
impedance as shown in Figure 7-1. The Source bulk capacitance shall not be placed between the transceiver isolation
impedance and the USB receptacle. The bulk capacitance consists of C1 and C2 as shown in Figure 7-1. The Ohmic
Interconnect may consist of PCB traces for power distribution or power switching devices. The capacitance may be a
single capacitor, a capacitor bank or distributed capacitance. If the power supply is shared across multiple ports, bulk
capacitance is defined as cSrcBulkShared. If the power supply is dedicated to a single Port, the minimum bulk
capacitance is defined as cSrcBulk.
The Source bulk capacitance is allowed to change for a newly negotiated power level. The capacitance change shall
occur before the Source is ready to operate at the new power level. During a Power Role Swap, the Default Source
shall transition to Swap Standby before operating as the new Sink. Any change in bulk capacitance required to
complete the Power Role Swap shall occur during Swap Standby.

Figure 7-1 Placement of Source Bulk Capacitance

SOURCE CABLE

TX
rTX
RX

zIsolation* VBUS
Power Ohmic VBUS
Supply Interconnect
Data Data
...

...

C1
C2 Lines Lines

GND GND
SHIELD SHIELD
Source Bulk Capacitance

* zIsolation is only required where BFSK over VBUS signaling is implemented otherwise this can be omitted

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 215
 7.1.3 Types of Sources
Consistent with the Power Data Objects discussed in Section 6.4.1, the three possible power supply types that are
available as Sources in a USB Power Delivery System are:
 Fixed Supply is used to expose well regulated fixed voltage power supplies. Sources shall support at least one
fixed power source capable of supplying vSafe5V. The output voltage of a Fixed Supply shall be specified in terms
of an absolute tolerance, vSrcNew, relative to the nominal value. Refer to Table 7-22 for the output voltage
tolerance specification.
 Variable power supply (non-battery) is used to expose very poorly regulated Sources. The output voltage of a
Variable power supply (non-battery) shall be specified as vSrcNew, in terms of an absolute maximum output
voltage and an absolute minimum output voltage.
 Battery Supply is used to expose batteries than can be connected directly as a Source to VBUS. The output voltage
of a Battery Supply shall be specified as vSrcNew, in terms of an absolute maximum output voltage and an
absolute minimum output voltage.

7.1.4 Positive Voltage Transitions

The Source shall transition VBUS from the starting voltage to the higher new voltage in a controlled manner. The
negotiated new voltage (e.g., 12V or 20V) defines the typical value for vSrcNew. If the newly negotiated voltage is 5V,
then vSafe5V limits shall apply. During the positive transition the Source shall be able to supply the Sink standby
power and the transient current to charge the total bulk capacitance on VBUS. The slew rate of the positive transition
shall not exceed vSrcSlewPos. The Source output voltage during a positive transition shall settle within the Source
output tolerance range vSrcNew. The Source shall be able to supply the negotiated power level at the new voltage by
tSrcReady. The positive voltage transition shall remain monotonic while the transitioning voltage is below vSrcValid
min and shall remain within the vSrcValid range upon crossing vSrcValid min as shown in Figure 7-2. See Section
7.1.9 for requirements relating to transients. The starting time, t0, in Figure 7-2 starts tSrcTransition after the last bit
of the EOP of the GoodCRC Message has been received by the Source.

Figure 7-2 Transition Envelope for Positive Voltage Transitions

Upper bound of valid Source range

vSrcValid(max)

vSrcNew(max)

vSrcNew(typ)

vSrcNew(min)

vSrcValid(min)
Lower bound of valid Source range

≈
vSrcSlewPos

Starting voltage

≈
t0 tSrcSettle tSrcReady

When a positive voltage transition is started, the VBUS voltage may decrease at the onset of the transition. When the
starting voltage on VBUS for the transition is vSafe5V, the VBUS voltage shall not droop below vSafe5V min. When the
starting voltage on VBUS is any voltage other than vSafe5V, the VBUS voltage shall not droop below vSrcValid min.

Page 216 USB Power Delivery Specification Revision 2.0, Version 1.1
During normal operation, not including VBUS transitions or discharge, VBUS shall not go beyond the limits of vSrcValid
(or vSafe5V if VBUS is 5V). This limitation shall apply to static and transient VBUS behavior across all single port and
multi-port power configurations.

7.1.5 Negative Voltage Transitions

Negative voltage transitions are defined as shown in Figure 7-3 and are specified in a similar manner to positive
voltage transitions. Figure 7-3 does not apply to vSafe0V transitions. If the newly negotiated voltage is 5V, then
vSafe5V limits shall apply. The slew rate of the negative transition shall not exceed vSrcSlewNeg. The negative
voltage transition shall remain monotonic while the transitioning voltage is above vSrcValid max and shall remain
within the vSrcValid range upon crossing vSrcValid max as shown in Figure 7-3. See Section 7.1.9 for requirements
relating to transients. The starting time, t0, in Figure 7-3 starts tSrcTransition after the last bit of the EOP of the
GoodCRC Message has been received by the Source.

Figure 7-3 Transition Envelope for Negative Voltage Transitions

Starting voltage

vSrcSlewNeg

Upper bound of valid Source range

vSrcValid(max)

vSrcNew(max)

vSrcNew(typ)

vSrcNew(min)

vSrcValid(min)
Lower bound of valid Source range
≈
t0 tSrcSettle tSrcReady

7.1.6 Response to Hard Resets

Hard Reset Signaling indicates a communication failure has occurred and the Source shall drive VBUS to vSafe0V as
shown in Figure 7-4. The USB connection may reset during a Hard Reset since the VBUS voltage will be less than
vSafe5V for an extended period of time. After establishing the safe voltage condition on V BUS, the power supply shall
wait tSrcRecover before powering VBUS to vSafe5V. A Source using a Type-C connector shall conform to the VCONN
timing as specified in [USBType-C 1.0].
Device operation during and after a Hard Reset is defined as follows:
 Self-powered devices should not disconnect from USB during a Hard Reset (see Section 9.1.2).
 Self-powered devices operating at more than vSafe5V may not maintain full functionality after a Hard Reset.
 Bus powered devices will disconnect from USB during a Hard Reset due to the loss of their power source.
When a Hard Reset occurs the Source shall start to transition the VBUS voltage to vSafe0V and the VCONN voltage to
vVConnDischarge (see [USBType-C 1.0]) either:

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 217
  tPSHardReset after the last bit of the Hard Reset Signaling has been received from the Sink or
 tPSHardReset after the last bit of the Hard Reset Signaling has been sent by the Source
The Source shall meet both tSafe5V and tSafe0V relative to the start of the voltage transition as shown in Figure 7-4.

Figure 7-4 Source VBUS Response to Hard Reset

Old voltage

≈
vSafe5V(max)

vSafe0V(max)

0V
t0
vSrcNeg(max)
tSafe5V

tSrcRecover
tSafe0V tSrcTurnOn

The Source shall meet tVConnDischarge relative to the start of the voltage transition as shown in Figure 7-5. The
source shall meet tVconnOn relative to VBUS reaching vSafe5V. Note: tVConnDischarge, vVConnDischarge and
tVconnOn are defined in [USBType-C 1.0].

Figure 7-5 Source VCONN Response to Hard Reset

VConn

vVConnDischarge

0V
t0 tVConnOn

tVConnDischarge tSrcTurnOn

Page 218 USB Power Delivery Specification Revision 2.0, Version 1.1
 7.1.7 Changing the Output Power Capability
Some USB Power Delivery negotiations will require the Source to adjust its output power capability without changing
the output voltage. In this case the Source shall be able to supply a higher or lower load current within tSrcReady.

7.1.8 Safe Operating Considerations

The Source shall provide short circuit current limiting to protect its Port from prolonged exposure to excessive
current draw. For the purposes of this standard, excessive current draw is defined as any current that significantly
exceeds the output capability of the power supply or the contact rating of the receptacle. The maximum steady state
operating current of the Source shall be the lesser of these two values. For example, the Source Port powered by a 6A
power supply connected to two 3A receptacles will provide a maximum continuous operating current of 3A on each
receptacle. The short circuit protection mechanism shall be designed to avoid tripping at the maximum continuous
operating current of the Source Port and shall not interfere with negotiated current levels. The protected Port shall
recover automatically, by performing a Hard Reset, when the fault is removed and resume operation at vSafe5V
within tShortCctRecover of the fault removal. Mechanical or user intervention shall not be required to reset the short
circuit protection mechanism unless the Provider is purely a power source, which does not support USB
communication, when mechanical intervention may be used.
Safe operation mandates that Power Delivery Sources shall be tolerant of vSafe5V being present on VBUS when
simultaneously applying power to VBUS. This shall not interfere with normal PD communication.
A USB detach can be detected mechanically (e.g. Standard-A receptacle with insertion detect) or electrically (e.g. CC
detection on the Type-C or via the ID pin on the Micro-A plug or using Attach Detection Protocol from [USBOTG 2.0]).
When the Source is capable of detecting a detach either mechanically or electrically, the Source shall transition to
vSafe0V by tSafe0V relative to when the detach event occurred (i.e. physical removal of the plug). During the
transition to vSafe0V the VBUS voltage shall be below vSafe5V max by tSafe5V relative to when the detach event
occurred (i.e. physical removal of the plug) and shall not exceed vSafe5V max after this time.

7.1.9 Output Voltage Tolerance and Range

The vSrcNew and vSrcValid limits apply to VBUS Source output voltage after the voltage transition is complete (i.e.
after tSrcReady) as follows. During static load conditions the Source output voltage shall remain within the vSrcNew
range. The range defined by vSrcNew accounts for DC regulation accuracy, line load regulation and output ripple. In
response to a transient load event (as described below) the Source output voltage shall not go beyond the range
specified by vSrcValid. The amount of time the Source output voltage can be in the band between vSrcNew and
vSrcValid shall not exceed tSrcTransient. Refer to Table 7-22 for the output voltage tolerance specifications. Figure
7-6 illustrates the application of these limits.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 219
 Figure 7-6 Application of vSrcNew and vSrcValid limits after tSrcReady

vSrcValid(max)
tSrcTransient windows
vSrcNew(max)

vSrcNew(typ)

vSrcNew(min)
tSrcTransient window
vSrcValid(min)

≈
Sink Load I2

iLoadReleaseRate
iLoadStepRate

≈
≈
Sink Load I1

tSrcReady

The Source output voltage shall be measured at the connector receptacle. The stability of the Source shall be tested in
25% load step increments from minimum load to maximum load and also from maximum load to minimum load. The
transient behavior of the load current is defined in Section 7.2.6. The time between each step shall be sufficient to
allow for the output voltage to settle between load steps. In some systems it may be necessary to design the Source to
compensate for the voltage drop between the output stage of the power supply electronics and the receptacle contact.
The determination of when compensation may be necessary is left to the discretion of the implementation.

7.1.10 Charging and Discharging the Bulk Capacitance on VBUS

The Source shall charge and discharge the bulk capacitance on VBUS whenever the Source voltage is negotiated to a
different value. The charging or discharging occurs during the voltage transition and shall not interfere with the
Source’s ability to meet tSrcReady.

7.1.11 Swap Standby for Sources

Sources and Sinks of a Dual-Role Port shall support Swap Standby. Swap Standby occurs for the Source after the
Source power supply has discharged the bulk capacitance on VBUS to vSafe0V as part of the Power Role Swap
transition.
While in Swap Standby:
 The Source shall not drive VBUS that is therefore expected to remain at vSafe0V.
 Any discharge circuitry that was used to achieve vSafe0V shall be removed from VBUS.
 The Dual-Role Port shall be configured as a Sink
 The USB connection shall not reset even though vSafe5V is no longer present on VBUS (see Section 9.1.2).
The PS_RDY Message associated with the Source being in Swap Standby shall be sent after the VBUS drive is removed.
The time for the Source to transition to Swap Standby shall not exceed tSrcSwapStdby. Upon entering Swap Standby
the Source has relinquished its role as Source and is ready to become the new Sink. The transition time from Swap
Standby to being the new Sink shall be no more than tNewSnk. The new Sink may start using power after the new
Source sends the PS_RDY Message.

7.1.12 Source Peak Current Operation

A Source that has the Fixed Supply PDO Peak Current bits set to 01b, 10b and 11b shall be designed to support one of
the overload capabilities defined in Table 6-7. The overload conditions are bound in magnitude, duration and duty
cycle as listed in Table 6-7. Sources are not required to support continuous overload operation. When overload
conditions occur, the Source is allowed the range of vSrcPeak (instead of vSrcNew) relative to the nominal value (see

Page 220 USB Power Delivery Specification Revision 2.0, Version 1.1
Figure 7-7). When the overload capability is exceeded, the Source is expected take whatever action is necessary to
prevent electrical or thermal damage to the Source. The Source may send a new Source_Capabilities Message with
the Fixed Supply PDO Peak Current bits set to 00b to prohibit overload operation even if an overload capability was
previously negotiated with the Sink.

Figure 7-7 Source Peak Current Overload

Operating range for supply that DOES
Source Port Voltage NOT support overload capability

Additional operating range for

vSrcNew(max)/
Fixed Supply that supports
vSrcPeak(max)
overload capability
Nominal Voltage

vSrcNew(min)

vSrcPeak(min)

Sink Port Current

IOC level % level with respect to IOC
as requested in the Operating as advertised in the Peak Current
Current field of an RDO field of Fixed Supply PDO

7.1.13 BFSK over VBUS Considerations for Sources

The following sections list Source power supply considerations when applying BFSK signaling to VBUS.

7.1.13.1 Transceiver Isolation Impedance

For BFSK signaling over VBUS an isolation impedance as specified in Section 5.8.2.2 is used to isolate the transceiver
from the capacitive loading of the Source. The DC component of the isolation impedance introduces additional voltage
loss between the Source power path and the connector. The Source output impedance, the total VBUS bulk capacitance,
the transceiver isolation impedance(s), the USB cable and the Sink network creates a complex output isolation
impedance that should be taken into consideration when designing the Source. Refer to Appendix C.1 for more
information on this topic.

7.1.13.2 Noise Injected on VBUS

The Source shall not interfere with the USB Power Delivery BFSK waveform that is transmitted on VBUS. Power stage
switching harmonics or poor layout and component selection may result in a significant amount of in-band noise
injected on VBUS. The characteristics of the noise will be implementation specific and in some cases an additional filter
may be required to meet the in-band signal-to-noise ratio requirement of snrSrc. Refer to Section 5.8.2 for the
reference impedance, carrier signal amplitude and transmission bandwidth of the USB Power Delivery BFSK
waveform. Refer to Appendix C for more information on this topic.
Out-of-band noise (including spurs) can also affect the reception of the BFSK signal; therefore the Source shall limit its
out-of-band noise below the spectrum shown in Figure 7-8 and the levels indicated in Table 7-1. Figure 7-8 shows the
level of allowed noise relative to the level of the allowed in-band noise [for a Source: dbV (minimum value of vTX) –
snrSrc]. The limits shown in Figure 7-8 and

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 221
Table 7-1 does not include any other regulations (such as FCC regulations) that govern signal emissions.
The VBUS-to-GND noise measurement shall be made at the connector. The noise measurement can be made using a
breakout board or equivalent method that does not introduce additional loading of the AC impedance of the VBUS wire.
Such measurement access methods will require calibration to ensure accurate measurement results.

Figure 7-8 Noise Spectral Mask, given in absolute terms relative to the maximum value of vTX

-5

A
-10

-15
dB relative to 200mVrms

-20

-25

D
-30

-35
B C

-40
1 2
10 10
frequency [MHz]

Page 222 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-1 Noise Spectral Mask Corners

Frequency (MHz) Maximum Allowed Signal Level

(dB) (mVpp)
<10 (A) -10 178.7
19.7(B) to 26.7 (C) -37 7.92
>32 (D) -30 17.8

7.1.13.3 Dead Battery Operation

Dead Battery operation shall be supported by all Consumer/Providers. A Consumer/Provider shall apply vSafeDB to
its Port when it detects its Port voltage to be vSafe0V (see Section 4.1). The Operation Region of vSafeDB source shall
be as shown in Figure 7-9. For example if the Provider/Consumer attempts to draw 30mA the voltage will remain
above 2.4V; if the Provider/Consumer attempts to draw more than 90mA the voltage will drop to vSafe0V. The
Consumer/Provider shall fully support the vSafeDB Operating Region as shown in Figure 7-9 on reaching 2V. The
output voltage shall reach 2V and comply with the vSafeDB Operating Region within tTurnOnSafeDB of when it first
applies voltage to VBUS. The Source bulk capacitance shall be limited to cSrcBulkDB for the Consumer/Provider when
applying vSafeDB. The Consumer/Provider shall be limited to cSnkBulk when not applying vSafeDB.
A detailed description of the Consumer/Provider’s behavior during Dead Battery operation is provided in Section
8.3.3.6.1.5.

Figure 7-9 vSafeDB Operating Region

5.5V
C/P area of operation during Dead Battery mode.

C/P min current supplied @ 4V = 10 mA

4V

3V
P/C area of operation during
Dead Battery mode.
C/P min current supplied @ 2V = 35 mA

2V
P/C may draw up to 1 mA while C/P output voltage is < 2V for UVLO
startup. This is in addition to the bulk capacitance charging current.

1V

Dead Battery mode shall not operate in this area

0V
0 mA 30 mA 60 mA 90 mA

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 223
 7.2 Sink Requirements
7.2.1 Behavioral Aspects
The Sink in a Consumer or Consumer/Provider exhibits the following behaviors.
 Shall be backward compatible with legacy VBUS ports.
 Shall draw the default [USB 2.0], [USB 3.1], [USBType-C 1.0] or [BC 1.2] VBUS current when the USB cable is
attached (USB Default Operation).
 Shall draw the default [USB 2.0], [USB 3.1], [USBType-C 1.0] or [BC 1.2] VBUS current when a Contract does not
exist (USB Default Operation).
 Shall return to the default [USB 2.0], [USB 3.1], [USBType-C 1.0] or [BC 1.2] VBUS when responding to a Hard Reset
(USB Default Operation).
 Shall control VBUS in-rush current when increasing current consumption.
The Sink in a Provider/Consumer exhibits the following behaviors.
 May support Dead Battery operation as defined in Section 4.1.1 for Type-A to Type-B connections and as defined
in [USBType-C 1.0] for Type-C to Type-C connections.
 Shall return to Source operation when responding to a Hard Reset.
 Shall control VBUS in-rush current when increasing and decreasing current consumption.

7.2.2 Sink Bulk Capacitance

The Sink shall have a bulk capacitance, cSnkBulk, located between the input of the power supply and the transceiver
isolation impedance as shown in Figure 7-10. The Sink bulk capacitance shall not be placed between the transceiver
isolation impedance and the USB receptacle. The bulk capacitance consists of C3 and C4 as shown in Figure 7-10. The
Ohmic Interconnect may consist of PCB traces for power distribution or power switching devices. The capacitance
may be a single capacitor, a capacitor bank or distributed capacitance. An upper bound of cSnkBulkPd shall not be
exceeded so that the transient charging, or discharging, of the total bulk capacitance on VBUS can be accounted for
during voltage transitions.
The Sink bulk capacitance that is within the cSnkBulk max or cSnkBulkPd max limits is allowed to change to support
a newly negotiated power level. The capacitance can be changed when the Sink enters Sink Standby or during a
voltage transition or when the Sink begins to operate at the new power level. Regardless of when the change occurs,
the capacitance change shall occur in such a manner that does not introduce a V BUS transient current greater than
iCapChange. During a Power Role Swap the Default Sink shall transition to Swap Standby before operating as the
new Source. Any change in bulk capacitance required to complete the Power Role Swap shall occur during Swap
Standby.

Figure 7-10 Placement of Sink Bulk Capacitance

CABLE SINK

TX
rTX
RX

VBUS zIsolation*
VBUS Ohmic
Load
Interconnect
Data Data
...

...

Lines Lines C3 C4

GND GND
SHIELD SHIELD
Sink Bulk Capacitance

* zIsolation is only required where BFSK over VBUS signaling is implemented otherwise this can be omitted

Page 224 USB Power Delivery Specification Revision 2.0, Version 1.1
 7.2.3 Sink Standby
The Sink shall transition to Sink Standby before a positive or negative voltage transition of V BUS. During Sink Standby
the Sink shall reduce its average power draw to pSnkStdby and its peak power draw shall not exceed
pSnkStdbyLimit. This allows the Source to manage the voltage transition as well as supply sufficient operating
current to the Sink to maintain PD operation during the transition. The Sink shall complete this transition to Sink
Standby within tSnkStdby after evaluating the Accept Message from the Source. The transition when returning to
Sink operation from Sink Standby shall be completed within tSnkNewPower. The pSnkStdby requirement shall only
apply if the Sink power draw is higher than this level.

7.2.4 Suspend Power Consumption

When Source has set its USB Suspend Supported flag (see Section 6.4.1.2.3.2), a Sink shall go to the lowest power state
during USB suspend. The lowest power state shall be pSnkSusp or lower for a PDUSB Peripheral and pHubSusp or
lower for a PDUSB Hub. There is no requirement for the Source voltage to be changed during USB suspend.

7.2.5 Zero Negotiated Current

When a Sink Requests zero current as part of a power negotiation with a Source, the Sink shall go to the lowest power
state, pSnkSusp or lower, where it can still communicate using PD signaling.

7.2.6 Transient Load Behavior

When a Sink’s operating current changes due to a load step, load release or any other change in load level, the positive
or negative overshoot of the new load current shall not exceed the range defined by iOvershoot. For the purposes of
measuring iOvershoot the new load current value is defined as the average steady state value of the load current after
the load step has settled. The rate of change of any shift in Sink load current during normal operation shall not exceed
iLoadStepRate (for load steps) and iLoadReleaseRate (for load releases) as measured at the Sink receptacle.

7.2.7 Swap Standby for Sinks

The Sink capability in a Dual-Role Port shall support Swap Standby. Swap Standby occurs for the Sink after evaluating
the Accept Message from the Source during a Power Role Swap negotiation. While in Swap Standby the Sink’s current
draw shall not exceed iSnkSwapStdby from VBUS and the Dual-Role Port shall be configured as a Source after VBUS has
been discharged to vSafe0V by the existing Initial Source. The Sink’s USB connection should not be reset even though
vSafe5V is not present on the VBUS conductor (see Section 9.1.2). The time for the Sink to transition to SwapStandby
shall be no more than tSnkSwapStdby. When in Swap Standby the Sink has relinquished its role as Sink and will
prepare to become the new Source. The transition time from Swap Standby to new Source shall be no more than
tNewSrc.

7.2.8 Sink Peak Current Operation

Sinks shall only make use of a Source overload capability when the corresponding Fixed Supply PDO Peak Current bits
are set to 01b, 10b and 11b (see Section 6.4.1.2.3.6). Sinks shall manage thermal aspects of the overload event by not
exceeding the average negotiated output of a Fixed Supply that supports Peak Current operation.
Sinks that depend on the Peak Current capability for enhanced system performance shall also function correctly when
attached to a Source that does not offer the Peak Current capability or when the Peak Current capability has been
inhibited by the Source.

7.2.9 BFSK over VBUS Considerations for Sinks

The following sections list Sink considerations when applying BFSK signaling to VBUS.

7.2.9.1 Transceiver Isolation Impedance

For BFSK signaling over VBUS an isolation impedance as specified in Section 5.8.2.2 is used to isolate the transceiver
from the capacitive loading of the Sink. The DC component of the isolation impedance introduces additional voltage
USB Power Delivery Specification Revision 2.0, Version 1.1 Page 225
loss between the connector and the Sink power path. The Sink input impedance, the total VBUS bulk capacitance, the
transceiver isolation impedance(s), the USB cable and the Source creates a complex input isolation impedance that
should be taken into consideration when designing the Sink. Refer to Appendix C.1 for more information on this topic.

7.2.9.2 Noise Reflected on VBUS

The Sink shall not interfere with the USB Power Delivery BFSK waveform that is transmitted on VBUS. Power stage
switching harmonics or poor layout and component selection may result in a significant amount of in-band noise
reflected on VBUS. The characteristics of the noise will be implementation specific and in some cases an additional
filter may be required to meet the in-band signal-to-noise ratio requirement of snrSnk. Refer to Section 5.8.2 for the
reference impedance, carrier signal amplitude and transmission bandwidth of the USB Power Delivery BFSK
waveform. Refer to Appendix C.1.1 for more information on this topic.
Out-of-band noise (including spurs) can also affect the reception of the BFSK signal; therefore the Sink shall limit its
out-of-band noise below the spectrum shown in Figure 7-11 and as detailed in Table 7-2. Figure 7-11 also shows the
noise level that shall be allowed relative to the level of the allowed in-band noise [for a Sink: dbV (minimum value of
vTX) – snrSnk]. The limits shown in Figure 7-11 and Table 7-2 do not include any other regulations (such as FCC
regulations) that govern signal emissions.
The VBUS-to-GND noise measurement shall be made at the connector.

Page 226 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 7-11 Noise Spectral Mask, given in absolute terms relative to the maximum value of vTX

-5

A
-10

-15
dB relative to 200mVrms

-20

-25

D
-30

-35
B C

-40
1 2
10 10
frequency [MHz]

Table 7-2 Noise Spectral Mask Corners

Frequency (MHz) Maximum Allowed Signal Level

(dB) (mVpp)
<10 (A) -10 178.7
19.7(B) to 26.7 (C) -37 7.92
>32 (D) -30 17.8

7.2.9.3 Dead Battery Operation

Dead Battery operation is only supported by Provider/Consumers that want to perform an Implicit (i.e. non-
negotiated) Power Role Swap when attached to a Consumer/Provider. When a Provider/Consumer Port is not able to
Source power (or has chosen to not source power) and would like to be powered by a Consumer/Provider, the
Provider/Consumer shall discharge its Port voltage to vSafe0V, present cSnkBulk and be ready to power up the
transceiver if vSafeDB is applied to its Port. When operating from vSafeDB, the Provider/Consumer, acting as a Sink,
shall be able to operate from any Source that complies with the Operating Region of Figure 7-9. The
Provider/Consumer may regain the ability to Source power (or decide to do so) at any time and shall not apply power
to its Port when vSafeDB is present. The Provider/Consumer shall not commence Dead Battery operation or draw
more than 1 mA until the voltage on VBUS is above 2V. The Sink bulk capacitance shall be limited to cSnkBulkDB for
the Provider/Consumer acting as the Sink during Dead Battery operation. A detailed description of the
Provider/Consumer’s behavior during Dead Battery operation is provided in Sections 4.1 and 7.1.13.3.

7.2.10 Safe Operating Considerations

When a Source is detached from a Sink, the Sink shall continue to draw power from its input bulk capacitance until
VBUS is discharged to vSafe5V or lower by no longer than tSafe5V from the detach event. This safe Sink requirement

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 227
shall apply to all Sinks operating with a negotiated VBUS level greater than vSafe5V and shall apply during all low
power and high power operating modes of the Sink.
If the detach is detected during a Sink low power state, such as USB Suspend, the Sink can then draw as much power
as needed from its bulk capacitance since a Source is no longer attached. In order to achieve a successful detach
detect based on VBUS voltage level droop, the Sink power consumption must be high enough so that VBUS will decay
below vSrcValid(min) well within tSafe5V after the Source bulk capacitance is removed due to the detach. Once
adequate VBUS droop has been achieved, a discharge circuit can be enabled to meet the safe Sink requirement.
To illustrate the point, the following set of Sink conditions will not meet the safe Sink requirement without additional
discharge circuitry:
 Negotiated VBUS = 20V
 Maximum allowable supplied VBUS voltage = 21.5V
 Maximum bulk capacitance = 30µF
 Power consumption at detach = 12.5mW
When the detach occurs (hence removal of the Source bulk capacitance) the 12.5mW power consumption will draw
down the VBUS voltage from the worst-case maximum level of 21.5V to 17V in approximately 205 ms. At this point,
with VBUS well below vSrcValid (min) an approximate 100 mW discharge circuit can be enabled to increase the rate of
Sink bulk capacitance discharge and meet the safe Sink requirement. The power level of the discharge circuit is
dependent on how much time is left to discharge the remaining voltage on the Sink bulk capacitance. If a Sink has the
ability to detect the detach in a different manner and in much less time than tSafe5V, then this different manner of
detection can be used to enable a discharge circuit, allowing even lower power dissipation during low power modes
such as USB Suspend.
In most applications, the safe Sink requirement will limit the maximum Sink bulk capacitance well below the
cSnkBulkPd limit. A detach occurring during Sink high power operating modes must quickly discharge the Sink bulk
capacitance to vSafe5V or lower as long as the Sink continues to draw adequate power until VBUS has decayed to
vSafe5V or lower.

Page 228 USB Power Delivery Specification Revision 2.0, Version 1.1
 7.3 Transitions
The following sections illustrate the power supply’s response to various types of negotiations. The negotiation cases
take into consideration for the examples are as follows:
 Higher Power Transitions
o Increase the current
o Increase the voltage
o Increase the voltage and the current
 Relatively Constant Power Transitions
o Increase the voltage and decrease the current
o Decrease the voltage and increase the current
 Lower Power Transitions
o Decrease the current
o Decrease the voltage
o Decrease the voltage and the current
 Power Role Swap Transitions
o Source requests a Power Role Swap
o Sink requests a Power Role Swap
 Go To Minimum Current Transition
 Response to Hard Reset Signaling
o Source issues Hard Reset Signaling
o Sink issues Hard Reset Signaling
o New Source issues Hard Reset Signaling and New Sink Receives Hard Reset Signaling.
o New Source issues Hard Reset Signaling and New Sink Does Not Receive Hard Reset Signaling.
o New Sink issues Hard Reset Signaling and New Source Receives Hard Reset Signaling.
o New Sink issues Hard Reset Signaling and New Source Does Not Receive Hard Reset Signaling.
 Dead Battery Operation.
 No change in Current or Voltage.
The transition from [USB 2.0], [USB 3.1], [USBType-C 1.0] or [BC 1.2] operation into Power Delivery Mode can also
lead to a Power Transition since this is the initial Contract negotiation. The following types of Power Transitions shall
also be applied when moving from [USB 2.0], [USB 3.1], [USBType-C 1.0] or [BC 1.2] operation into Power Delivery
Mode:
 High Power
 Relatively Constant Power
 Lower Power Transitions
 No change in Current or Voltage.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 229
 7.3.1 Increasing the Current
The interaction of the System Policy, Device Policy, and power supply that shall be followed when increasing the
current is shown in Figure 7-12. The sequence that shall be followed is described in Table 7-3. The timing
parameters that shall be followed are listed in Table 7-22 and Table 7-23. Note in this figure, the Sink has previously
sent a Request Message to the Source.

Figure 7-12 Transition Diagram for Increasing the Current

1 4
tSrcTransition
Source Port Send Send
Policy Engine Accept PS_RDY
Port to Port
2 5
Evaluate
PSTransitionTimer (running)
Evaluate
Messaging
Sink Port
Policy Engine Accept PS_RDY

3
Source Port Source
Device Policy Mgr ñI
Source Port
Source Port Interaction
Source VOLD t1 Source VOLD
Power Supply

6 7
Sink
Sink Port ... ñI
Device Policy Mgr
Sink Port
Sink Port Interaction
Sink ≤ IOLD t2 Sink ≤ INEW
Power Supply

Source Port
VBUS doesn’t change
Voltage
Source
VBUS Voltage

Sink Port
≤ INEW
Current
≤ IOLD Sink
≈

VBUS Current

Page 230 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-3 Sequence Description for Increasing the Current

Step Source Port Sink Port

1 Policy Engine sends the Accept Message to the
Sink.
Policy Engine receives the Accept Message and starts
the PSTransitionTimer.
2 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. The Policy Engine waits Policy Engine then evaluates the Accept Message.
tSrcTransition before telling the Device Policy
Manager to instruct the power supply to modify
its output power.
3 After tSrcTransition, the Policy Engine tells the
Device Policy Manager to instruct the power
supply to change its output power capability. The
power supply shall be ready to operate at the new
power level within tSrcReady (t1). The power
supply informs the Device Policy Manager that it
is ready to operate at the new power level. The
power supply status is passed to the Policy
Engine.
4 The Policy Engine sends the PS_RDY Message to The Policy Engine receives the PS_RDY Message from the
the Sink. Source.
5 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. Policy Engine then evaluates the PS_RDY Message from the
Source and tells the Device Policy Manager it is okay to
operate at the new power level.
6 The Sink may begin operating at the new power level any
time after evaluation of the PS_RDY Message. This time
duration is indeterminate.
7 The Sink shall not violate the transient load behavior
defined in Section 7.2.6 while transitioning to and
operating at the new power level. The time duration (t2)
depends on the magnitude of the load change.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 231
 7.3.2 Increasing the Voltage
The interaction of the System Policy, Device Policy, and power supply that shall be followed when increasing the
voltage is shown in Figure 7-13. The sequence that shall be followed is described in Table 7-4. The timing parameters
that shall be followed are listed in Table 7-22, Table 7-23 and Table 7-24. Note in this figure, the Sink has previously
sent a Request Message to the Source.

Figure 7-13 Transition Diagram for Increasing the Voltage

1 5
tSrcTransition
Source Port Send Send
Policy Engine Accept PS_RDY
Port to Port
2 6
Evaluate
PSTransitionTimer (running)
Evaluate
Messaging
Sink Port
Policy Engine Accept PS_RDY

4
Source Port Source
Device Policy Mgr ñV
Source Port
Source Port Interaction
Source VOLD t2 Source VNEW
Power Supply

3 7 8
Sink to Sink Sink Standby
Sink Port
Standby ... to Sink
Device Policy Mgr
Sink Port
Sink Port Interaction
Sink ≤ IOLD t1 Sink pSnkStdby t3 Sink ≤ IOLD
Power Supply

Source Port
VNEW
Voltage
Source
VOLD VBUS Voltage

Sink Port I2
≤ IOLD ≤ IOLD
Current
I1 Sink
VBUS Current
≈

I1

I1 ≤ (pSnkStdby/VBUS) I2 ≤ (pSnkStdby/VBUS) + cSnkBulkPd(DVBUS/Dt)

Page 232 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-4 Sequence Description for Increasing the Voltage

Step Source Port Sink Port

1 Policy Engine sends the Accept Message to the Policy Engine receives the Accept Message and starts the
Sink. PSTransitionTimer.
2 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. The Policy Engine waits Policy Engine. Policy Engine then evaluates the Accept
tSrcTransition before telling the Device Policy Message.
Manager to instruct the power supply to modify
its output power.
3 Policy Engine tells the Device Policy Manager to instruct
the power supply to reduce power consumption to
pSnkStdby within tSnkStdby (t1); t1 shall complete before
tSrcTransition. The Sink shall not violate transient load
behavior defined in Section 7.2.6 while transitioning to
and operating at the new power level.
4 After tSrcTransition, the Policy Engine tells the
Device Policy Manager to instruct the power
supply to change its output voltage to operate at
the new power level. The power supply shall be
ready to operate at the new power level within
tSrcReady (t2). The power supply informs the
Device Policy Manager that it is ready to operate
at the new power level. The power supply status
is passed to the Policy Engine.
5 The Policy Engine sends the PS_RDY Message to The Policy Engine receives the PS_RDY Message from the
the Sink. Source.
6 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. Policy Engine then evaluates the PS_RDY Message from the
Source and tells the Device Policy Manager it is okay to
operate at the new power level.
7 The Sink may begin operating at the new power level any
time after evaluation of the PS_RDY Message. This time
duration is indeterminate.
8 The Sink shall not violate the transient load behavior
defined in Section 7.2.6 while transitioning to and
operating at the new power level. The time duration (t3)
depends on the magnitude of the load change.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 233
 7.3.3 Increasing the Voltage and Current
The interaction of the System Policy, Device Policy, and power supply that shall be followed when increasing the
voltage and current is shown in Figure 7-14. The sequence that shall be followed is described in Table 7-5. The
timing parameters that shall be followed are listed in Table 7-22, Table 7-23 and Table 7-24. Note in this figure, the
Sink has previously sent a Request Message to the Source.

Figure 7-14 Transition Diagram for Increasing the Voltage and Current

1 5
tSrcTransition
Source Port Send Send
Policy Engine Accept PS_RDY
Port to Port
2 6 Messaging
PSTransitionTimer (running)
Sink Port Evaluate Evaluate
Policy Engine Accept PS_RDY

4
Source Port Source
Device Policy Mgr ñVñI
Source Port
Source Port
Interaction
Source VOLD t2 Source VNEW
Power Supply

3 7 8
Sink to Sink Sink Standby
Sink Port
Standby ... to Sink
Device Policy Mgr
Sink Port
Sink Port
Interaction
Sink ≤ IOLD t1 Sink pSnkStdby t3 Sink ≤ INEW
Power Supply

Source Port
VNEW
Voltage Source
VOLD
VBUS Voltage

Sink Port I2
≤ INEW
Current Sink
≤ IOLD
I1 VBUS Current
≈

I1

I1 ≤ (pSnkStdby/VBUS) I2 ≤ (pSnkStdby/VBUS) + cSnkBulkPd(DVBUS/Dt)

Page 234 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-5 Sequence Diagram for Increasing the Voltage and Current

Step Source Port Sink Port

1 Policy Engine sends the Accept Message to the Policy Engine receives the Accept Message and starts the
Sink. PSTransitionTimer.
2 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. The Policy Engine waits Policy Engine then evaluates the Accept Message.
tSrcTransition before telling the Device Policy
Manager to instruct the power supply to modify
its output power.
3 Policy Engine tells the Device Policy Manager to instruct
the power supply to reduce power consumption to
pSnkStdby within tSnkStdby (t1) ; t1 shall complete
before tSrcTransition. The Sink shall not violate transient
load behavior defined in Section 7.2.6 while transitioning
to and operating at the new power level.
4 After tSrcTransition, the Policy Engine tells the
Device Policy Manager to instruct the power
supply to change its output voltage to operate at
the new power level. The power supply shall be
ready to operate at the new power level within
tSrcReady (t2). The power supply informs the
Device Policy Manager that it is ready to operate
at the new power level. The power supply status
is passed to the Policy Engine.
5 The Policy Engine sends the PS_RDY Message to
the Sink.
The Policy Engine receives the PS_RDY Message from
the Source.
6 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. Policy Engine then evaluates the PS_RDY Message from the
Source and tells the Device Policy Manager it is okay to
operate at the new power level.
7 The Sink may begin operating at the new power level any
time after evaluation of the PS_RDY Message. This time
duration is indeterminate.
8 The Sink shall not violate the transient load behavior
defined in Section 7.2.6 while transitioning to and
operating at the new power level. The time duration (t3)
depends on the magnitude of the load change.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 235
 7.3.4 Increasing the Voltage and Decreasing the Current
The interaction of the System Policy, Device Policy, and power supply that shall be followed when increasing the
voltage and decreasing the current is shown in Figure 7-15. The sequence that shall be followed is described in Table
7-6. The timing parameters that shall be followed are listed in Table 7-22, Table 7-23 and Table 7-24. Note in this
figure, the Sink has previously sent a Request Message to the Source.

Figure 7-15 Transition Diagram for Increasing the Voltage and Decreasing the Current

1 5
tSrcTransition
Source Port Send Send
Policy Engine Accept PS_RDY
Port to Port
2 6
Evaluate
PSTransitionTimer (running)
Evaluate
Messaging
Sink Port
Policy Engine Accept PS_RDY

4
Source Port Source
Device Policy Mgr ñ V òI
Source Port
Source Port
Interaction
Source VOLD t2 Source VNEW
Power Supply

3 7 8
Sink to Sink Sink Standby
Sink Port
Standby ... to Sink
Device Policy Mgr
Sink Port
Sink Port
Interaction
Sink ≤ IOLD t1 Sink pSnkStdby t3 Sink ≤ INEW
Power Supply

Source Port
VNEW
Voltage
Source
VOLD VBUS Voltage

Sink Port I2
≤ IOLD
Current
I1 ≤ INEW Sink
VBUS Current
≈

I1

I1 ≤ (pSnkStdby/VBUS) I2 ≤ (pSnkStdby/VBUS) + cSnkBulkPd(DVBUS/Dt)

Page 236 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-6 Sequence Description for Increasing the Voltage and Decreasing the Current

Step Source Port Sink Port

1 Policy Engine sends the Accept Message to the Policy Engine evaluates the Accept Message and starts the
Sink. PSTransitionTimer.
2 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. The Policy Engine waits Policy Engine then evaluates the Accept Message.
tSrcTransition before telling the Device Policy
Manager to instruct the power supply to modify
its output power.
3 Policy Engine tells the Device Policy Manager to instruct
the power supply to reduce power consumption to
pSnkStdby within tSnkStdby (t1) ; t1 shall complete
before tSrcTransition. The Sink shall not violate transient
load behavior defined in Section 7.2.6 while transitioning
to and operating at the new power level.
4 After tSrcTransition, the Policy Engine tells the
Device Policy Manager to instruct the power
supply to change its output voltage to operate at
the new power level. The power supply shall be
ready to operate at the new power level within
tSrcReady (t2). The power supply informs the
Device Policy Manager that it is ready to operate
at the new power level. The power supply status
is passed to the Policy Engine.
5 The Policy Engine sends the PS_RDY Message to The Policy Engine receives the PS_RDY Message from the
the Sink. Source.
6 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. Policy Engine then evaluates the PS_RDY Message from the
Source and tells the Device Policy Manager it is okay to
operate at the new power level.
7 The Sink may begin operating at the new power level any
time after evaluation of the PS_RDY Message. This time
duration is indeterminate.
8 The Sink shall not violate the transient load behavior
defined in Section 7.2.6 while transitioning to and
operating at the new power level. The time duration (t3)
depends on the magnitude of the load change.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 237
 7.3.5 Decreasing the Voltage and Increasing the Current
The interaction of the System Policy, Device Policy, and power supply that shall be followed when decreasing the
voltage and increasing the current is shown in Figure 7-16. The sequence that shall be followed is described in Table
7-7. The timing parameters that shall be followed are listed in Table 7-22, Table 7-23 and Table 7-24. Note in this
figure, the Sink has previously sent a Request Message to the Source.

Figure 7-16 Transition Diagram for Decreasing the Voltage and Increasing the Current

1 5
tSrcTransition
Source Port Send Send
Policy Engine Accept PS_RDY

2 6
Port to Port
PSTransitionTimer (running) Messaging
Sink Port Evaluate Evaluate
Policy Engine Accept PS_RDY

4
Source Port Source
Device Policy Mgr òVñI
Source Port
Source Port
Source VOLD t2 Source VNEW
Interaction
Power Supply

3 7 8
Sink to Sink Sink Standby
Sink Port
Standby ... to Sink
Device Policy Mgr
Sink Port
Sink Port
Sink ≤ IOLD t1 Sink pSnkStdby t3 Sink ≤ INEW
Interaction
Power Supply

Source Port
VOLD
Voltage
Source
VNEW VBUS Voltage

Sink Port ≤ INEW

Current ≤ IOLD
Sink
≈

I1
I1
VBUS Current
I2
I1 ≤ (pSnkStdby/VBUS) I2 ≤ (pSnkStdby/VBUS) + cSnkBulkPd(DVBUS/Dt)

Page 238 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-7 Sequence Description for Decreasing the Voltage and Increasing the Current

Step Source Port Sink Port

1 Policy Engine sends the Accept Message to the Policy Engine receives the Accept Message and starts the
Sink. PSTransitionTimer.
2 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. The Policy Engine waits Policy Engine then evaluates the Accept Message.
tSrcTransition before telling the Device Policy
Manager to instruct the power supply to modify
its output power.
3 Policy Engine tells the Device Policy Manager to instruct
the power supply to reduce power consumption to
pSnkStdby within tSnkStdby (t1) ; t1 shall complete
before tSrcTransition. The Sink shall not violate transient
load behavior defined in Section 7.2.6 while transitioning
to and operating at the new power level.
4 After tSrcTransition, the Policy Engine tells the
Device Policy Manager to instruct the power
supply to change its output voltage to operate at
the new power level. The power supply shall be
ready to operate at the new power level within
tSrcReady (t2). The power supply informs the
Device Policy Manager that it is ready to operate
at the new power level. The power supply status
is passed to the Policy Engine.
5 The Policy Engine sends the PS_RDY Message to The Policy Engine receives the PS_RDY Message from the
the Sink. Source.
6 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. Policy Engine then evaluates the PS_RDY Message from the
Source and tells the Device Policy Manager it is okay to
operate at the new power level.
7 The Sink may begin operating at the new power level any
time after evaluation of the PS_RDY Message. This time
duration is indeterminate.
8 The Sink shall not violate the transient load behavior
defined in Section 7.2.6 while transitioning to and
operating at the new power level. The time duration (t3)
depends on the magnitude of the load change.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 239
 7.3.6 Decreasing the Current
The interaction of the System Policy, Device Policy, and power supply that shall be followed when decreasing the
current is shown in Figure 7-17. The sequence that shall be followed is described in Table 7-8. The timing
parameters that shall be followed are listed in Table 7-22, Table 7-23 and Table 7-24. Note in this figure, the Sink has
previously sent a Request Message to the Source.

Figure 7-17 Transition Diagram for Decreasing the Current

1 5
tSrcTransition
Source Port Send Send
Policy Engine Accept PS_RDY

2 6
Port to Port
PSTransitionTimer (running) Messaging
Sink Port Evaluate Evaluate
Policy Engine Accept PS_RDY

4
Source Port Source
Device Policy Mgr òI
Source Port
Source Port
Source VOLD t2 Source VOLD
Interaction
Power Supply

3
Sink Port Sink
Device Policy Mgr òI
Sink Port
Sink Port
Sink ≤ IOLD t1 Sink ≤ INEW
Interaction
Power Supply

Source Port
VBUS does not change
Voltage
Source
VBUS Voltage

Sink Port
≤ IOLD
Current
Sink
≤ INEW VBUS Current

Page 240 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-8 Sequence Description for Decreasing the Current

Step Source Port Sink Port

1 Policy Engine sends the Accept Message to the Policy Engine receives the Accept Message starts
Sink. PSTransitionTimer.
2 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. The Policy Engine waits Policy Engine then evaluates the Accept Message. Policy
tSrcTransition before telling the Device Policy Engine tells the Device Policy Manager to instruct the
Manager to instruct the power supply to modify power supply to reduce power consumption.
its output power.
3 The Sink shall not violate the transient load behavior
defined in Section 7.2.6 while transitioning to and
operating at the new power level. The Sink shall be able to
operate with lower currentwithin tSnkNewPower (t1) ; t1
shall complete before tSrcTransition.
4 After tSrcTransition, the Policy Engine tells the
Device Policy Manager to instruct the power
supply to change its output power capability. The
power supply shall be ready to operate at the new
power level within tSrcReady (t2). The power
supply informs the Device Policy Manager that it
is ready to operate at the new power level. The
power supply status is passed to the Policy
Engine.
5 The Policy Engine sends the PS_RDY Message to The Policy Engine receives the PS_RDY Message from the
the Sink. Source.
6 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. Policy Engine evaluates the PS_RDY Message from the
Source. The Sink is already operating at the new power
level so no further action is required.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 241
 7.3.7 Decreasing the Voltage
The interaction of the System Policy, Device Policy, and power supply that shall be followed when decreasing the
voltage is shown in Figure 7-18. The sequence that shall be followed is described in Table 7-9. The timing parameters
that shall be followed are listed in Table 7-22, Table 7-23 and Table 7-24. Note in this figure, the Sink has previously
sent a Request Message to the Source.

Figure 7-18 Transition Diagram for Decreasing the Voltage

1 5
tSrcTransition
Source Port Send Send
Policy Engine Accept PS_RDY
Port to Port
2 6
Evaluate
PSTransitionTimer (running)
Evaluate
Messaging
Sink Port
Policy Engine Accept PS_RDY

4
Source Port Source
Device Policy Mgr òV
Source Port
Source Port Interaction
Source VOLD t2 Source VNEW
Power Supply

3 7 8
Sink to Sink Sink Standby
Sink Port
Standby ... to Sink
Device Policy Mgr
Sink Port
Sink Port Interaction
Sink ≤ IOLD t1 Sink pSnkStdby t3 Sink ≤ IOLD
Power Supply

Source Port
VOLD
Voltage
Source
VNEW VBUS Voltage

Sink Port
≤ IOLD ≤ IOLD
Current
Sink
≈

I1
I1 VBUS Current
I2

I1 ≤ (pSnkStdby/VBUS) I2 ≤ (pSnkStdby/VBUS) + cSnkBulkPd(DVBUS/Dt)

Page 242 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-9 Sequence Description for Decreasing the Voltage

Step Source Port Sink Port

1 Policy Engine sends the Accept Message to the Policy Engine receives the Accept Message and starts the
Sink. PSTransitionTimer.
2 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. The Policy Engine waits Policy Engine then evaluates the Accept Message.
tSrcTransition before telling the Device Policy
Manager to instruct the power supply to modify
its output power.
3 Policy Engine tells the Device Policy Manager to instruct
the power supply to reduce power consumption to
pSnkStdby within tSnkStdby (t1) ; t1 shall complete
before tSrcTransition. The Sink shall not violate transient
load behavior defined in Section 7.2.6 while transitioning
to and operating at the new power level.
4 After tSrcTransition, the Policy Engine tells the
Device Policy Manager to instruct the power
supply to change its output voltage to operate at
the new power level. The power supply shall be
ready to operate at the new power level within
tSrcReady (t2). The power supply informs the
Device Policy Manager that it is ready to operate
at the new power level. The power supply status
is passed to the Policy Engine.
5 The Policy Engine sends the PS_RDY Message to The Policy Engine receives the PS_RDY Message from the
the Sink. Source.
6 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. Policy Engine then evaluates the PS_RDY Message from the
Source and tells the Device Policy Manager it is okay to
operate at the new power level.
7 The Sink may begin operating at the new power level any
time after evaluation of the PS_RDY Message. This time
duration is indeterminate.
8 The Sink shall not violate the transient load behavior
defined in Section 7.2.6 while transitioning to and
operating at the new power level. The time duration (t3)
depends on the magnitude of the load change.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 243
 7.3.8 Decreasing the Voltage and the Current
The interaction of the System Policy, Device Policy, and power supply that shall be followed when decreasing the
voltage and current is shown in Figure 7-19. The sequence that shall be followed is described in Table 7-10. The
timing parameters that shall be followed are listed in Table 7-22, Table 7-23 and Table 7-24. Note in this figure, the
Sink has previously sent a Request Message to the Source.

Figure 7-19 Transition Diagram for Decreasing the Voltage and the Current

1 5
tSrcTransition
Source Port Send Send
Policy Engine Accept PS_RDY

2 6
Port to Port
PSTransitionTimer (running) Messaging
Sink Port Evaluate Evaluate
Policy Engine Accept PS_RDY

4
Source Port Source
Device Policy Mgr òVòI
Source Port
Source Port
Source VOLD t2 Source VNEW
Interaction
Power Supply

3 7
Sink to Sink Sink Standby
Sink Port
Standby ... to Sink
Device Policy Mgr
Sink Port
Sink Port
Sink ≤ IOLD t1 Sink pSnkStdby t3 Sink ≤ INEW
Interaction
Power Supply

Source Port
VOLD
Voltage
Source
VNEW VBUS Voltage

Sink Port
≤ IOLD
Current ≤ INEW
Sink
≈

I1
I1 VBUS Current
I2

I1 ≤ (pSnkStdby/VBUS) I2 ≤ (pSnkStdby/VBUS) + cSnkBulkPd(DVBUS/Dt)

Page 244 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-10 Sequence Description for Decreasing the Voltage and the Current

Step Source Port Sink Port

1 Policy Engine sends the Accept Message to the Policy Engine receives the Accept Message and starts the
Sink. PSTransitionTimer.
2 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. The Policy Engine waits Policy Engine then evaluates the Accept Message.
tSrcTransition before telling the Device Policy
Manager to instruct the power supply to modify
its output power.
3 Policy Engine tells the Device Policy Manager to instruct
the power supply to reduce power consumption to
pSnkStdby within tSnkStdby (t1) ; t1 shall complete
before tSrcTransition. The Sink shall not violate transient
load behavior defined in Section 7.2.6 while transitioning
to and operating at the new power level.
4 After tSrcTransition, the Policy Engine tells the
Device Policy Manager to instruct the power
supply to change its output voltage to operate at
the new power level. The power supply shall be
ready to operate at the new power level within
tSrcReady (t2). The power supply informs the
Device Policy Manager that it is ready to operate
at the new power level. The power supply status
is passed to the Policy Engine.
5 The Policy Engine sends the PS_RDY Message to The Policy Engine receives the PS_RDY Message from the
the Sink. Source.
6 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. Policy Engine then evaluates the PS_RDY Message from the
Source and tells the Device Policy Manager it is okay to
operate at the new power level.
7 The Sink may begin operating at the new power level any
time after evaluation of the PS_RDY Message. This time
duration is indeterminate.
8 The Sink shall not violate the transient load behavior
defined in Section 7.2.6 while transitioning to and
operating at the new power level. The time duration (t3)
depends on the magnitude of the load change.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 245
 7.3.9 Sink Requested Power Role Swap
The interaction of the System Policy, Device Policy, and power supply that shall be followed during a Sink requested
Power Role Swap is shown in Figure 7-20. The sequence that shall be followed is described in Table 7-11. The timing
parameters that shall be followed are listed in Table 7-23. Note in this figure, the Sink has previously sent a PR_Swap
Message to the Source.

Figure 7-20 Transition Diagram for a Sink Requested Power Role Swap

1 5 9
tSrcTransition PSSourceOnTimer (running)
Initial Source Port Send Send Evaluate
Policy Engine Accept PS_RDY PS_RDY
Port to Port
2 6 8
Evaluate
PSSourceOffTimer (running)
Evaluate Send Messaging
Initial Sink Port
Policy Engine Accept PS_RDY PS_RDY

Initial Source 4 10 New Sink

Initial Source Port Source to Swap Standby
Device Policy Mgr Swap Standby to Sink
Source Port
Source à Sink Interaction
Source VOLD t2 Swap Standby t4 Sink default current
Power Supply

Initial Sink 3 7 New Source

Initial Sink Port Sink to Swap Swap Standby
Device Policy Mgr Standby to Source
Sink Port
Sink à Source Interaction
Sink ≤ IOLD t1 Swap Standby t3 Source vSafe5V
Power Supply

Source Port
VOLD
Voltage vSafe5V
Source
Initial Source New Source
VBUS Voltage

not driven

Sink Port
IOLD
Current pSnkSusp
Sink
Initial Sink I2 New Sink
VBUS Current
I1 I1
not driven
I1 ≤ iSnkSwapStdby I2 I2 ≤ iSnkSwapStdby + cSnkBulkPd(DVBUS/Dt)

Page 246 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-11 Sequence Description for a Sink Requested Power Role Swap

Step Initial Source Port à New Sink Port Initial Sink Port à New Source Port
1 Policy Engine sends the Accept Message to the Policy Engine receives the Accept and starts the
Initial Sink. PSSourceOffTimer.
2 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Initial
from the Initial Sink. The Policy Engine waits Source. Policy Engine then evaluates the Accept Message.
tSrcTransition before telling the Device Policy
Manager to instruct the power supply to
transition to Swap Standby.
3 Policy Engine tells the Device Policy Manager to instruct
the power supply to transition to Swap Standby within
tSnkStdby (t1) ; t1 shall complete before tSrcTransition.
When in Sink Standby the Initial Sink shall not draw more
than iSnkSwapStdby (I1). The Sink shall not violate
transient load behavior defined in Section 7.2.6 while
transitioning to and operating at the new power level.
4 After tSrcTransition, the Policy Engine tells the
Device Policy Manager to instruct the power
supply to transition to Swap Standby (see Section
7.1.11). The power supply shall complete the
transition to Swap Standby within
tSrcSwapStdby (t2). The power supply informs
the Device Policy Manager that it is ready to
operate as the new Sink. The power supply status
is passed to the Policy Engine.
5 The power supply is ready and the Policy Engine
sends the PS_RDY Message to the device that will
become the new Source.
6 Protocol Layer receives the GoodCRC Message Policy Engine stops the PSSourceOffTimer.
from the device that will become the new Source. The Protocol Layer sends the GoodCRC Message to the
Policy Engine starts the PSSourceOnTimer. Upon new Sink.
sending the PS_RDY Message and receiving the Policy Engine tells the Device Policy to instruct the power
GoodCRC Message the Initial Source is ready to be supply to operate as the new Source.
the new Sink.
7 The power supply as the new Source transitions from
Swap Standby to sourcing default vSafe5V within tNewSrc
(t3). The power supply informs the Device Policy Manager
that it is operating as the new Source.
8 Policy Engine receives the PS_RDY Message from Device Policy Manager informs the Policy Engine the
the Source. power supply is ready and the Policy Engine sends the
PS_RDY Message to the new Sink.
9 Policy Engine stops the PSSourceOnTimer. Protocol Layer receives the GoodCRC Message from the
Protocol Layer sends the GoodCRC Message to the new Sink.
new Source.
Policy Engine evaluates the PS_RDY Message from
the new Source and tells the Device Policy
Manager to instruct the power supply to draw
current as the new Sink.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 247
Step Initial Source Port à New Sink Port Initial Sink Port à New Source Port
10 The power supply as the new Sink transitions
from Swap Standby to drawing pSnkSusp within
tNewSnk (t4). The power supply informs the
Device Policy Manager that it is operating as the
new Sink. At this point subsequent negotiations
between the new Source and the new Sink may
proceed as normal. The Sink shall not violate the
transient load behavior defined in Section 7.2.6
while transitioning to and operating at the new
power level. The time duration (t4) depends on
the magnitude of the load change.

Page 248 USB Power Delivery Specification Revision 2.0, Version 1.1
 7.3.10 Source Requested Power Role Swap
The interaction of the System Policy, Device Policy, and power supply that shall be followed during a Source requested
Power Role Swap is shown in Figure 7-21. The sequence that shall be followed is described in Table 7-12. The timing
parameters that shall be followed are listed in Table 7-22. Note in this figure, the Sink has previously sent a PR_Swap
Message to the Source.

Figure 7-21 Transition Diagram for a Source Requested Power Role Swap

2 4 8
PSSourceOnTimer (running)
Initial Source Port Evaluate Send Evaluate
Policy Engine Accept PS_RDY PS_RDY
tSrcTransition Port to Port
1 5 7
Send
PSSourceOffTimer (running)
Evaluate Send
Messaging
Initial Sink Port
Policy Engine Accept PS_RDY PS_RDY

Initial Source 3 9 New Sink

Initial Source Port Source to Swap Standby
Device Policy Mgr Swap Standby to Sink
Source Port
Source à Sink Interaction
Source VOLD t2 Swap Standby t4 Sink default current
Power Supply

Initial Sink 2a 6 New Source

Initial Sink Port Sink to Swap Swap Standby
Device Policy Mgr Standby to Source
Sink Port
Sink à Source Interaction
Sink ≤ IOLD t1 Swap Standby t3 Source vSafe5V
Power Supply

Source Port
VOLD
Voltage vSafe5V
Source
VBUS Voltage
Initial Source New Source

not driven

Sink Port
IOLD
Current pSnkSusp
Sink
I2
I1 VBUS Current
Initial Sink I1 New Sink
not driven
I1 ≤ iSnkSwapStdby I2 I2 ≤ iSnkSwapStdby + cSnkBulkPd(DVBUS/Dt)

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 249
 Table 7-12 Sequence Description for a Source Requested Power Role Swap

Step Initial Source Portà New Sink Port Initial Sink Port à New Source Port
1 Policy Engine receives the Accept Message. Policy Engine sends the Accept Message to the Initial
Source.
2 Protocol Layer sends the GoodCRC Message to the Protocol Layer receives the GoodCRC Message from the
Initial Sink. Policy Engine evaluates the Accept Initial Source. Policy Engine starts the PSSourceOffTimer.
Message, and then waits tSrcTransition before
telling the Device Policy Manager to instruct the
power supply to transition to Swap Standby.
2a The Policy Engine tells the Device Policy Manager to
instruct the power supply to transition to Swap Standby.
The power supply shall complete the transition to Swap
Standby within tSnkStdby (t1) ; t1 shall complete before
tSrcTransition. The Sink shall not violate the transient
load behavior defined in Section 7.2.6 while transitioning
to and operating at the new power level. Policy Engine
starts PSSourceOffTimer. When in Sink Standby the
Initial Sink shall not draw more than iSnkSwapStdby (I1).
3 After tSrcTransition, the Policy Engine tells the
Device Policy Manager to instruct the power
supply to transition to Swap Standby (see Section
7.1.11). The power supply shall complete the
transition to Swap Standby within
tSrcSwapStdby (t2). The power supply informs
the Device Policy Manager that it is ready to
operate as the new Sink. The power supply status
is passed to the Policy Engine.
4 The Policy Engine sends the PS_RDY Message to Policy Engine receives the PS_RDY Message and stops the
the soon to be new Source. PSSourceOffTimer.
5 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the new
from the soon to be new Source. Policy Engine Sink. Upon evaluating the PS_RDY Message the Initial Sink
starts the PSSourceOnTimer. At this point the is ready to operate as the new Source. Policy Engine tells
Initial Source is ready to be the new Sink. the Device Policy to instruct the power supply to operate
as the new Source.
6 The power supply as the new Source transitions from
Swap Standby to sourcing default vSafe5V within tNewSrc
(t3). The power supply informs the Device Policy Manager
that it is operating as the new Source.
7 Policy Engine receives the PS_RDY Message and Device Policy Manager informs the Policy Engine the
stops the PSSourceOnTimer. power supply is ready and the Policy Engine sends the
PS_RDY Message to the new Sink.
8 Protocol Layer sends the GoodCRC Message to the Protocol Layer receives the GoodCRC Message from the
new Source. new Sink.
Policy Engine evaluates the PS_RDY Message from
the new Source and tells the Device Policy
Manager to instruct the power supply to draw
current as the new Sink.

Page 250 USB Power Delivery Specification Revision 2.0, Version 1.1
Step Initial Source Portà New Sink Port Initial Sink Port à New Source Port
9 The power supply as the new Sink transitions
from Swap Standby to drawing pSnkSusp within
tNewSnk (t4). The power supply informs the
Device Policy Manager that it is operating as the
new Sink. At this point subsequent negotiations
between the new Source and the new Sink may
proceed as normal. The new Sink shall not violate
the transient load behavior defined in Section
7.2.6 while transitioning to and operating at the
new power level. The time duration (t4) depends
on the magnitude of the load change.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 251
 7.3.11 GotoMin Current Decrease
The interaction of the System Policy, Device Policy, and power supply that shall be followed during a GotoMin current
decrease is shown in Figure 7-22. The sequence that shall be followed is described in Table 7-13. The timing
parameters that shall be followed are listed in Table 7-22 and Table 7-13.

Figure 7-22 Transition Diagram for a GotoMin Current Decrease

1 5
tSrcTransition
Source Port Send Send
Policy Engine Go To Min PS_RDY
Port to Port
2 6
Evaluate
PSTransitionTimer (running)
Evaluate
Messaging
Sink Port
Policy Engine Go To Min PS_RDY

4
Source Port Source
Device Policy Mgr òI
Source Port
Source Port Interaction
Source VOLD t2 Source VOLD
Power Supply

3
Sink Port Sink
Device Policy Mgr òI
Sink Port
Sink Port Interaction
Sink ≤ IOLD t1 Sink previously negotiated go to min current
Power Supply

Source Port
VBUS doesn’t change
Voltage
Source
VBUS Voltage

Sink Port
≤ IOLD
Current
Sink
go to min current VBUS Current

Page 252 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-13 Sequence Description for a GotoMin Current Decrease

Step Source Port Sink Port

1 Policy Engine sends the GotoMin Message to the Policy Engine receives the GotoMin Message and starts the
Sink. PSTransitionTimer.
2 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. The Policy Engine waits Policy Engine then evaluates the GotoMin Message.
tSrcTransition before telling the Device Policy
Manager to instruct the power supply to modify
its output power.
3 Policy Engine tells the Device Policy Manager to instruct
the power supply to reduce power consumption, within
tSnkNewPower (t1), to the pre-negotiated go to reduced
power level ) ; t1 shall complete before tSrcTransition.
The Sink shall not violate the transient load behavior
defined in Section 7.2.6 while transitioning to and
operating at the new power level.
4 After tSrcTransition, the Policy Engine tells the
Device Policy Manager to instruct the power
supply to change its output power capability. The
power supply shall be ready to operate at the new
power level within tSrcReady (t2). The power
supply informs the Device Policy Manager that it
is ready to operate at the new power level. The
power supply status is passed to the Policy
Engine.
5 The Policy Engine sends the PS_RDY Message to The Policy Engine receives the PS_RDY Message.
the Sink.
6 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. Policy Engine evaluates the PS_RDY Message from the
Source and no further action is required.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 253
 7.3.12 Source Initiated Hard Reset
The interaction of the System Policy, Device Policy, and power supply that shall be followed during a Source Initiated
Hard Reset is shown in Figure 7-23. The sequence that shall be followed is described in Table 7-14. The timing
parameters that shall be applied are listed in Table 7-22 and Table 7-23.

Figure 7-23 Transition Diagram for a Source Initiated Hard Reset

1
Send tPSHardReset
Source Port
Policy Engine Hard Reset
Port to Port
2
Process
Messaging
Sink Port
Policy Engine Hard Reset

4 5
Source Port Source Source
Device Policy Mgr Hard Reset Recover
Source Port
Source Port Interaction
Source VOLD t2 Source vSafe0V t4 Source vSafe5V
Power Supply

Sink Port Sink

Device Policy Mgr Prepare
Sink Port
Sink Port Interaction
Sink ≤ IOLD t1 Ready to recover and power up
Power Supply

Source Port tSrcRecover

VOLD vSafe5V
Voltage
Source
≈ VBUS Voltage
vSafe0V

Sink Port
≤ IOLD Default current draw
Current
Sink
≈ VBUS Current
iSafe0mA

Page 254 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-14 Sequence Description for a Source Initiated Hard Reset

Step Source Port Sink Port

1 Policy Engine sends Hard Reset Signaling to the Sink receives Hard Reset Signaling.
Sink.
2 Policy Engine is informed of the Hard Reset. Policy Engine
tells the Device Policy Manager to instruct the power
supply to prepare for a Hard Reset.
3 The Sink prepares for the Hard Reset within
tSnkHardResetPrepare (t1) ) and passes an indication to
the Device Policy Manger The Sink shall not draw more
than iSafe0mA when VBUS is driven to vSafe0V.
4 Policy Engine waits tPSHardReset after sending
Hard Reset Signaling and then tells the Device
Policy Manager to instruct the power supply to
perform a Hard Reset. The transition to vSafe0V
shall occur within tSafe0V (t2).
5 After tSrcRecover the Source applies power to The Sink shall not violate the transient load behavior
VBUS in an attempt to re-establish commnication defined in Section 7.2.6 while transitioning to and
with the Sink and resume USB Default Operation. operating at the new power level.
The transition to vSafe5V shall occur within
tSrcTurnOn (t4).

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 255
 7.3.13 Sink Initiated Hard Reset
The interaction of the System Policy, Device Policy, and power supply that shall be followed during a Sink Initiated
Hard Reset is shown in Figure 7-24. The sequence that shall be followed is described in Table 7-15. The timing
parameters that shall be followed are listed in Table 7-22 and Table 7-23.

Figure 7-24 Transition Diagram for a Sink Initiated Hard Reset

4
Source Port Evaluate
Policy Engine Hard Reset
Port to Port
1
Send tPSHardReset Messaging
Sink Port
Policy Engine Hard Reset

2 5 6
Process Source Source
Source Port Hard Reset
Device Policy Mgr Hard Reset Recover
Source Port
Source Port Interaction
Source VOLD t2 Source vSafe0V t4 Source vSafe5V
Power Supply

3
Sink Port Sink
Device Policy Mgr Prepare
Sink Port
Sink Port Interaction
Sink ≤ IOLD t1 Ready to recover and power up
Power Supply

Source Port tSrcRecover

VOLD vSafe5V
Voltage
Source
≈ VBUS Voltage
vSafe0V

Sink Port Defalt current

≤ IOLD
Current draw
Sink
≈ VBUS Current
iSafe0mA

Page 256 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-15 Sequence Description for a Sink Initiated Hard Reset

Step Source Port Sink Port

1 Policy Engine sends Hard Reset Signaling to the Source.
2 Policy Engine tells the Device Policy Manager to instruct
the power supply to prepare for a Hard Reset.
3 The Sink prepares for the Hard Reset within
tSnkHardResetPrepare (t1) and passes an indication to
the Device Policy Manger The Sink shall not draw more
than iSafe0mA when VBUS is driven to vSafe0V.
4 Policy Engine is informed of the Hard Reset.
5 Policy Engine waits tPSHardReset after receiving
Hard Reset Signaling and then tells the Device
Policy Manager to instruct the power supply to
perform a Hard Reset. The transition to vSafe0V
shall occur within tSafe0V (t2).
6 After tSrcRecover the Source applies power to The Sink shall not violate the transient load behavior
VBUS in an attempt to re-establish commnication defined in Section 7.2.6 while transitioning to and
with the Sink and resume USB Default Operation. operating at the new power level.
The transition to vSafe5V shall occur within
tSrcTurnOn (t4).

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 257
 7.3.14 Type-A/B Hard Reset after a Power Role Swap
The following sections indicate the transitions made when a Hard Reset occurs between Type-A Port acting as Sink
and a Type-B Port acting as Source.

7.3.14.1 Type-B New Source Initiates Hard Reset and Type-A New Sink Receives Hard Reset
Signaling
The interaction of the System Policy, Device Policy, and power supply that shall be followed during a Hard Reset
initiated by the Type-B new Source when the Type-A new Sink receives Hard Reset Signaling is shown in Figure 7-25.
The sequence that shall be followed is described in Table 7-16. The timing parameters that shall be followed are
listed in Table 7-22 and Table 7-23.
The default roles for Provider/Consumers and Consumer/Providers after a Hard Reset are as defined in Section 6.7.2.

Figure 7-25 Transition Diagram for Type-B New Source Initiated Hard Reset and Type-A New Sink Receives Hard Reset
Signaling

2b
tSwapRecover
New Sink Port Evaluate
Policy Engine Hard Reset
Port to Port
1
Send
Messaging
New Source Port
Policy Engine Hard Reset

New Sink 3 Initial Source

New Sink Port Initial Source
Device Policy Mgr Turn On
Source Port
New Sink à Source Interaction
New Sink t2 Revert to Source
Power Supply

New Source 2a Initial Sink

New Source Port New Source
Device Policy Mgr Turn Off
Sink Port
New Source à Sink Interaction
New Source t1 Revert to Sink and ready to power up
Power Supply

Source Port
VOLD vSafe5V
Voltage
≈ Source
VBUS Voltage
New Source vSafe0V
Initial Source

Sink Port
≤ IOLD default draw
Current
≈ Sink
VBUS Current
New Sink iSafe0mA
Initial Sink

Page 258 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-16 Sequence Description for Type-B New Source Initiated Hard Reset and Type-A New Sink Receives Hard Reset
Signaling

Step New Source Port New Sink Port

1 Policy Engine sends Hard Reset Signaling to the
new Sink and tells the Device Policy Manager to
turn off the new Source.
2a The Device Policy Manager instructs the power
supply to turn off the Source and revert to Sink
operation by tSafe0V (t1).
2b Policy Engine receives and evaluates a Hard Reset
notification, waits tSwapRecover and then tells the Device
Policy Manager to turn on the new Source.
3 Sink is drawing no more than default current as Source applies vSafe5V when VBUS is within vSafe0V. The
defined in [USB 2.0], [USB 3.1], [USBType-C 1.0] transition to vSafe5V shall be completed with tSrcTurnOn
or [BC 1.2]. (t2). The Sink shall not violate the transient load behavior
defined in Section 7.2.6 while transitioning to and
operating at the new power level.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 259
 7.3.14.2 Type-B New Source Initiates Hard Reset and Type-A New Sink Does Not Receive Hard
Reset Signaling
The interaction of the System Policy, Device Policy, and power supply that shall be followed during a Hard Reset
initiated by the Type-B new Source when the Type-A new Sink does not receive the Hard Reset Signaling is shown in
Figure 7-26. The sequence that shall be followed is described in Table 7-17. The timing parameters that shall be
followed are listed in Table 7-22 and Table 7-23.
The default roles for Provider/Consumers and Consumer/Providers after a Hard Reset are as defined in Section 6.7.2.

Figure 7-26 Transition Diagram for Type-B New Source Initiated Hard Reset and Type-A New Sink Does Not Receive Hard
Reset Signaling

2b
tSwapRecover
New Sink Port Send
≈

Policy Engine Hard Reset

Port to Port
1
Send Messaging
New Source Port
Policy Engine Hard Reset

New Sink 3 Initial Source

New Sink Port Initial Source
Device Policy Mgr Turn On
Source Port
New Sink à Source Interaction
New Sink t2 Revert to Source
Power Supply

New Source 2a Initial Sink

New Source Port New Source
Device Policy Mgr Turn Off
Sink Port
New Source à Sink Interaction
New Source t1 Revert to Sink and ready to power up
Power Supply

Source Port
VOLD vSafe5V
Voltage
≈ Source
New Source Initial Source
VBUS Voltage
vSafe0V

Sink Port
≤ IOLD default current
Current
≈ Sink
New Sink Initial Sink
VBUS Current
iSafe0mA

Page 260 USB Power Delivery Specification Revision 2.0, Version 1.1
Table 7-17 Sequence Description for Type-B New Source Initiated Hard Reset and Type-A New Sink Does Not Receive Hard
Reset Signaling

Step New Source Port New Sink Port

1 Policy Engine attempts to send the Hard Reset
Signaling to the new Sink and tells the Device
Policy Manager to turn off the new Source.
2a The new Sink has not received a Message from the new
Source and decides to initiate a Hard Reset , waits
tSwapRecover, then tells the Device Policy Manager to
turn on the new Source.
2b The Device Policy Manager instructs the power supply to
turn off the Source and revert to Sink operation by tSafe0V
(t1).
3 Source shall not re-apply vSafe5V until VBUS is Sink is drawing no more than default current as defined in
within vSafe0V. The transition to vSafe5V shall [USB 2.0], [USB 3.1], [USBType-C 1.0] or [BC 1.2]. The
be completed within tSrcTurnOn(t2). Sink shall not violate the transient load behavior defined in
Section 7.2.6 while transitioning to and operating at the
new power level.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 261
 7.3.14.3 Type-A New Sink Initiates Hard Reset and Type-B New Source Receives Hard Reset
Signaling
The interaction of the System Policy, Device Policy, and power supply that shall be followed during a Hard Reset
initiated by the Type-A new Sink when the Type-B new Source receives the Hard Reset Signaling is shown in Figure
7-27. The sequence that shall be followed is described in Table 7-18. The timing parameters that shall be followed
are listed in Table 7-22 and Table 7-23.
The default roles for Provider/Consumers and Consumer/Providers after a Hard Reset are as defined in Section 6.7.2.

Figure 7-27 Transition Diagram for Type-A New Sink Initiated Hard Reset and Type-B New Source Receives Hard Reset
Signaling

1
tSwapRecover
New Sink Port Send
Policy Engine Hard Reset
Port to Port
2
Evaluate Messaging
New Source Port
Policy Engine Hard Reset

New Sink 4 Initial Source

New Sink Port Initial Source
Device Policy Mgr Turn On
Source Port
New Sink à Source Interaction
New Sink t2 Revert to Source
Power Supply

New Source 3 Initial Sink

New Source Port New Source
Device Policy Mgr Turn Off
Sink Port
New Source à Sink Interaction
New Source t1 Revert to Sink and ready to power up
Power Supply

Source Port
VOLD vSafe5V
Voltage
≈ Source
New Source Initial Source
VBUS Voltage
vSafe0V

Sink Port
≤ IOLD default current
Current
≈ Sink
New Sink Initial Sink
VBUS Current
iSafe0mA

Page 262 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-18 Sequence Description for Type-A New Sink Initiated Hard Reset and Type-B New Source Receives Hard Reset
Signaling

Step New Source Port New Sink Port

1 Policy Engine sends the Hard Reset Signaling to the new
Source and waits tSwapRecover before telling the Device
Policy Manger to revert to Source operation.
2 Policy Engine evaluates the Hard Reset
notification and tells the Device Policy Manager to
turn off the new Source.
3 The Device Policy Manager instructs the power
supply to turn off the Source and revert to Sink
operation by tSafe0V (t1).
4 The Sink shall not violate the transient load Source applies vSafe5V when VBUS is within vSafe0V. The
behavior defined in Section 7.2.6 while transition to vSafe5V shall be completed with
transitioning to and operating at the new power tSrcTurnOn (t2).
level.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 263
 7.3.14.4 Type-A New Sink Initiates Hard Reset and Type-B New Source Does Not Receive Hard
Reset Signaling
The interaction of the System Policy, Device Policy, and power supply that shall be followed during a Hard Reset
initiated by the Type-A new Sink when the Type-B new Source does not receive the Hard Reset Signaling is shown in
Figure 7-28. The sequence that shall be followed is described in Table 7-19. The timing parameters that shall be
followed are listed in Table 7-22 and Table 7-23.
The default roles for Provider/Consumers and Consumer/Providers after a Hard Reset are as defined in Section 6.7.2.

Figure 7-28 Transition Diagram for Type-A New Sink Initiated Hard Reset and Type-B New Source Does Not Receive Hard
Reset Signaling

1
tSwapRecover
New Sink Port Send
Policy Engine Hard Reset
Port to Port
2
Send Messaging
New Source Port
≈

Policy Engine Hard Reset

New Sink 4 Initial Source

New Sink Port Initial Source
Device Policy Mgr Turn On
Source Port
New Sink à Source Interaction
New Sink t2 Revert to Source
Power Supply

New Source 3 Initial Sink

New Source Port New Source
Device Policy Mgr Turn Off
Sink Port
New Source à Sink Interaction
New Source t1 Revert to Sink and ready to power up
Power Supply

Source Port
VOLD vSafe5V
Voltage
≈ Source
New Source Initial Source
VBUS Voltage
vSafe0V

Sink Port
≤ IOLD default current
Current
≈ Sink
New Sink Initial Sink
VBUS Current
iSafe0mA

Page 264 USB Power Delivery Specification Revision 2.0, Version 1.1
Table 7-19 Sequence Description for Type-A New Sink Initiated Hard Reset and Type-B New Source Does Not Receive Hard
Reset Signaling

Step New Source Port New Sink Port

1 Policy Engine attempts to send the Hard Reset Signaling to
the new Source and waits tSwapRecover before telling the
Device Policy Manger to revert to Source operation.
2 The new Source has not received a Message from
the new Sink and decides to initiate a Hard Reset
and tells the Device Policy Manager to revert to
Source operation.
3 The Device Policy Manager instructs the Power supply to
turn off the Source and revert to Sink operation by tSafe0V
(t1).
4 The Sink shall not violate the transient load behavior
Source shall not re-apply vSafe5V until VBUS is defined in Section 7.2.6 while transitioning to and
within vSafe0V. The transition to vSafe5V shall operating at the new power level.
be completed within tSrcTurnOn(t2).

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 265
 7.3.15 Type-A to Type-B Dead Battery Operation
The interaction of the System Policy, Device Policy, and power supply that shall be followed during Type-A to Type-B
Dead Battery operation is shown in Figure 7-29. The sequence that shall be followed is described in Table 7-20. The
timing parameters that shall be followed are listed in Table 4-4, Table 7-22 and Table 7-23. The Initial Source Port is
not applying power to VBUS at the beginning of this sequence.

Figure 7-29 Type-A to Type-B Transition Diagram for Dead Battery Operation

tWaitForPower & 7 10
4
Ready for Capabilities
Sending Stopped Evaluate
Initial Source Port ... Bit Stream Bit Stream Capabilities
Policy Engine

2 BitStreamDetectTimer 5 DeviceReadyTimer 8 9
Port to Port
(running) (running) Messaging
Initial Sink Port Waiting for Detected Detected Send
Policy Engine Bit Stream Stream Start Stream End Capabilities

3
Initial Source Port Power Up as
Device Policy Mgr Sink

6a
Source Port
Source à Sink
Not Sourcing, ready to power up as Sink t2 Implied Sink New Sink
Interaction
Power Supply

1 6
Initial Sink Port Source Source
Device Policy Mgr vSafeDB vSafe5V
Sink Port
Sink à Source
Nothing attached t1 Implied Source t3 New Source
Interaction
Power Supply

Source Port
vSafe5V
Voltage
Source
≈

vSafeDB
VBUS Voltage
≈

vSafe0V

Sink Port
1 unit load
Current
Sink
VBUS Current
≈

Not attached Attached

Page 266 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-20 Sequence Description for Type-A to Type-B Dead Battery Operation

Step Initial Source Port Initial Sink Port

1 The Initial Sink detects VBUS is within vSafe0V and
performs an implied Power Role Swap to apply vSafeDB to
VBUS. The turn on time for vSafeDB is tTurnOnSafeDB
(t1).
2 The implied Source begins to wait for the Bit Stream after
having applied vSafeDB to VBUS. If an attach does not occur
before BitStreamDetectTimer times out, then the implied
Source removes vSafeDB and discharges VBUS to vSafe0V.
The Dead Battery start up routine for the Source will loop
this behavior until an attach occurs (see Section 4.1.1).
The loop is not illustrated in this diagram.
3 At some point in time an unpowered Source
waiting to power up as the implied Sink is
attached to an implied Source. The turn on time
of the implied Sink is tTurnOnImpliedSink (t2).
The Sink shall not violate the transient load
behavior defined in Section 7.2.6 while
transitioning to and operating at the new power
level.
4 If the implied Sink is unpowered it sends the Bit
Stream after having been powered up for some
time, by vSafeDB from the implied Source.
5 When the Bit Stream is detected the DeviceReadyTimer is
started and this diagram assumes the Bit Stream will end
before the DeviceReadyTimer has timed out.
6 The implied Source will apply vSafe5V to VBUS after the
start of the Bit Stream has been detected. The transition
time to change from vSafeDB to vSafe5V is
tSafeDBtoSafe5V (t3).
6a The implied Sink will transition to new Sink
operation as the VBUS voltage changes from
vSafeDB to vSafe5V and may draw up to 1 unit
load(as specified in [USB 2.0] or [USB 3.1]) once
vSafe5V is reached. The Sink shall not violate the
transient load behavior defined in Section 7.2.6
while transitioning to and operating at the new
power level.
7 The new Sink stops sending the Bit Stream when
the Policy Engine is ready to accept a
Source_Capabilities Message.
8 The new Source detects the end of the Bit Stream.
9 The Policy Engine of the new Source sends a
Source_Capabilities Message to the new Sink.
10 The Policy Engine of the new Sink evaluates the
Source_Capabilities Message from the new
Source and responds as normal for PD
negotiation.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 267
 7.3.19 No change in Current or Voltage
The interaction of the System Policy, Device Policy, and power supply that shall be followed when the Sink requests
the same Voltage and Current as it is currently operating at is shown in Figure 7-30. The sequence that shall be
followed is described in Table 7-21. The timing parameters that shall be followed are listed in Table 7-22 and Table
7-23.

Figure 7-30 Transition Diagram for no change in Current or Voltage

1 3
tSrcTransition
Source Port Send Send
Policy Engine Accept PS_RDY
Port to Port
2 4
Evaluate
PSTransitionTimer (running)
Evaluate
Messaging
Sink Port
Policy Engine Accept PS_RDY

Source Port
Device Policy Mgr
Source Port
Source Port Interaction
Source VOLD
Power Supply

Sink Port
Device Policy Mgr
Sink Port
Sink Port Interaction
Sink ≤ IOLD
Power Supply

Source Port
VBUS doesn’t change
Voltage
Source
VBUS Voltage

Sink Port
Current
Current doesn’t change Sink
VBUS Current

Page 268 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 7-21 Sequence Description for no change in Current or Voltage

Step Source Port Sink Port

1 Policy Engine sends the Accept Message to the
Sink.
Policy Engine receives the Accept Message and starts
the PSTransitionTimer.
2 Protocol Layer receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. Policy Engine then evaluates the Accept Message.
3 The Policy Engine waits tSrcTransition then Policy Engine receives the PS_RDY Message.
sends the PS_RDY Message to the Sink.
4 Policy Engine receives the GoodCRC Message Protocol Layer sends the GoodCRC Message to the Source.
from the Sink. Policy Engine evaluates the PS_RDY Message.
Note: the decision that no power transition is
required could be made either by the Device
Policy Manager or the power supply depending
on implementation.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 269
 7.4 Electrical Parameters
7.4.1 Source Electrical Parameters
The Source Electrical Parameters that shall be followed are specified in Table 7-22 and Table 4-4.

Table 7-22 Source Electrical Parameters

Parameter Description MIN TYP MAX UNITS Reference

cSrcBulk1 Source bulk capacitance 10 µF Section 7.1.2

when a Port is powered from
a dedicated supply.
cSrcBulkShared1 Source bulk capacitance when 120 µF Section 7.1.2
a Port is powered from a
shared supply.
cSrcBulkDB Source bulk capacitance on 0 10 µF Section
VBUS when applying vSafeDB. 7.1.13.3
snrSrc Source’s output Signal-to- 31 dB Section
noise ratio. 7.1.13.2
tNewSnk Time allowed for an initial 15 ms Figure 7-20,
Source in Swap Standby to Figure 7-21
transition new Sink
operation.
vSrcNew2 Fixed Supply output tolerance -5 +5 % Figure 7-2
measured at the Source Figure 7-3
receptacle.
Variable supply As defined by the negotiated min, max levels
Battery Supply As defined by the negotiated min, max levels
vSrcPeak The range that a Fixed Supply -15 +5 % Table 6-7
in Peak Current operation is Figure 7-7
allowed when overload
conditions occur.
vSrcValid The range in addition to -0.5 0.5 V Figure 7-2
vSrcNew which a newly Figure 7-3
negotiated voltage is
considered valid during and
after a transition. These limits
do not apply to VBUS =
vSafe5V.
tSafeDBtoSafe5V Transition time from vSafeDB 15 ms
to vSafe5V. Table 7-20
tShortCctRecover Source recovery time from 120 s Section 7.1.8
short circuit on fault removal.
tSrcReady Time from positive/negative 285 ms Figure 7-2,
transition start (t0) to when Figure 7-3
VBUS is within the range
defined by vSrcNew.
tSrcRecover Time allotted for the Source 0.66 1 s Section 7.1.6
to recover.
tSrcSettle Settling time from 275 ms Figure 7-2
positive/negative transition
start (t0) to when
transitioning voltage is within
the specified tolerance of the
final voltage.

Page 270 USB Power Delivery Specification Revision 2.0, Version 1.1
Parameter Description MIN TYP MAX UNITS Reference

tSrcSwapStdby The maximum time for the 650 ms Table 7-11

Source to transition to Swap Table 7-12
Standby.
tSrcTransient The maximum time for the 5 ms Section 7.1.9
Source output voltage to be
between vSrcNew and
vSrcValid in response to a
load transient.
tSrcTransition The time the Source waits 25 35 ms
before transitioning the
power supply to ensure that
the Sink has sufficient time to
prepare.
tSrcTurnOn Transition time from vSafe0V 275 ms Table 7-14
to vSafe5V. Table 7-15
Table 7-16
Table 7-17
Table 7-18
Table 7-19
tTurnOnSafeDB Time to turn on vSafeDB 15 ms
source. Table 7-20
vSrcSlewNeg Maximum slew rate allowed -30 mV/µs Section 7.1.5
for negative voltage Figure 7-3
transitions. Limits current
based on a 3 A connector
rating and maximum Sink
bulk capacitance of 100 µF.
vSrcSlewPos Maximum slew rate allowed 30 mV/µs Section 7.1.4
for positive voltage Figure 7-2
transitions. Limits current
based on a 3 A connector
rating and maximum Sink
bulk capacitance of 100 µF.
vSrcNeg Most negative voltage -0.3 V Figure 7-4
allowed during transition.
Note 1: The Source shall charge and discharge the total bulk capacitance to meet the transition time requirments.
Note 2: When operating at vSafe5V voltage tolerance is as specified in [USB 2.0] or [USB 3.1].

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 271
 7.4.2 Sink Electrical Parameters
The Sink Electrical Parameters that shall be followed are specified in Table 7-23 and Table 4-4.

Table 7-23 Sink Electrical Parameters

Parameter Description MIN TYP MAX UNITS Reference

cSnkBulk1 Sink bulk capacitance on VBUS 1 10 µF
at attach.
Section 7.2.2

cSnkBulkDB1 Bulk capacitance on VBUS 1 10 µF

when acting as a Sink during
Section 7.2.9.3
Dead Battery.
cSnkBulkPd Bulk capacitance on VBUS a 1 100 µF
Sink is allowed after a
Section 7.2.2
successful negotiation.
iCapChange Transient current allowed to 10 mA
flow when the Sink changes
Section 7.2.2
its bulk capacitance.
iLoadStepRate Load step di/dt. Refer to 150 mA/µs
[USBType-C 1.0] Section
Section 7.2.6
3.7.3.3.2 for cable details.
iLoadReleaseRate Load release di/dt. Refer to -150 mA/µs
[USBType-C 1.0] Section
Section 7.2.6
3.7.3.3.2 for cable details.
iOvershoot Positive or negative -230 230 mA
overshoot when a load
Section 7.2.6
change occurs; relative to the
settled value after the load
change. Refer to USB
[USBType-C 1.0] Section
3.7.3.3.2 for cable details.
iSafe0mA Maximum current a Sink is 1.0 mA
allowed to draw when VBUS is
Figure 7-23
driven to vSafe0V. Figure 7-24

iSnkSwapStdby Maximum current a Sink can 2.5 mA

draw during Swap Standby.
Section 7.2.7
Ideally this current is very
near to 0 mA largely
influenced by Port leakage
current.
pHubSusp Suspend power consumption 125 mW
for a hub. 25mW + 25mW
Section 7.2.4
per downstream Port for up
to 4 ports.
pSnkStdby Average power consumption 150 mW
over a 10ms interval while in
Section 7.2.3
Sink Standby.
pSnkStdbyLimit Absolute maximum standby 500 mW
power consumption while in
Section 7.2.3
Sink Standby.
pSnkSusp Suspend power consumption 25 mW
for a peripheral device.
Section 7.2.4

snrSnk Signal-to-noise ratio of Sink’s 31 dB

noise reflected on VBUS.
Section 7.2.9.2

Page 272 USB Power Delivery Specification Revision 2.0, Version 1.1
Parameter Description MIN TYP MAX UNITS Reference
tNewSnkRevertToSrc Hard Reset during Power 90 ms
Role Swap timing parameter.
Figure 7-25,
Figure 7-26,
Figure 7-27,
Figure 7-28

tNewSrc Maximum time allowed for 275 ms

an initial Sink in Swap
Section 7.2.7
Standby to transition to new Table 7-11
Source operation.
Table 7-12

tSnkHardResetPrepare Time alloted for the Sink 15 ms

power electronics to prepare
Table 7-15
for a Hard Reset.
tSnkNewPower Maximum transition time 15 ms
between power levels.
Section 7.2.3

tSnkRecover Time for the Sink to resume 150 ms

USB Default Operation. Table 7-14

tSnkStdby Time to transition to Sink 15 ms

Standby from Sink.
Section 7.2.3

tSnkSwapStdby Maximum time for the Sink 15 ms

to transition to
Section 7.2.7
SwapStandby.
tSwapRecover Provides settling time after a 0.5 1 s
hard reset before powering Table 7-18
back up.
Table 7-19

tTurnOnImpliedSink Turn on time of implied Sink 15 ms

during Dead Battery
operation. Table 7-20

Note 1: If more bypass capacitance than cSnkBulk max or cSnkBulkPd max is required in the device, then the device
must incorporate some form of VBUS surge current limiting as described in [USB 3.1] Section 11.4.4.1.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 273
 7.4.3 Common Electrical Parameters
Electrical Parameters that are common to both the Source and the Sink that shall be followed are specified in Table
7-24.

Table 7-24 Common Source/Sink Electrical Parameters

Parameter Description MIN TYP MAX UNITS Reference

tSafe0V Time to reach vSafe0V 650 ms Section 7.1.6

max.
Figure 7-4
Table 7-14
Table 7-15
Table 7-16
Table 7-17
Table 7-18
Table 7-19

tSafe5V Time to reach vSafe5V 275 ms Section 7.1.5

max.
Figure 7-4

vSafe0V Safe operating voltage at 0 0.8 V

“zero volts”.
Section 7.1.6

vSafe5V Safe operating voltage at [USB [USB V

5V. See [USB 2.0] and [USB 2.0]/ 2.0]/ Section 7.1.6
3.1] for allowable VBUS [USB [USB
voltage range. 3.1] 3.1]
vSafeDB Safe operating voltage for [USB Refer to [USB V
Dual-Role ports operating 2.0]/ Operating 2.0]/
Section
as DB Source. See [USB [USB Region in
[USB 7.1.13.3
Figure
2.0] and [USB 3.1] for 3.1] 3.1] Section 7.2.9.3
7-9
allowable VBUS voltage
range. Table 7-20

Page 274 USB Power Delivery Specification Revision 2.0, Version 1.1
8. Device Policy
8.1 Overview
This section describes the Device Policy and Policy Engine that implements it. For an overview of the architecture and
how the Device Policy Manager fits into this architecture, please see Section 2.6.

8.2 Device Policy Manager

The Device Policy Manager is responsible for managing the power used by one or more USB Power Delivery ports. In
order to have sufficient knowledge to complete this task it needs relevant information about the device it resides in.
Firstly it has a priori knowledge of the device including the capabilities of the power supply and the receptacles on
each Port since these will for example have specific current ratings. It also has to know information from the cable
detection module regarding cable insertion, type and rating of cable etc. It also has to have information from the
power supply about changes in its capabilities as well as being able to request power supply changes. With all of this
information the Device Policy Manager is able to provide up to date information regarding the capabilities available to
a specific Port and to manage the power resources within the device.
When working out the capabilities for a given Source Port the Device Policy Manager will take into account firstly the
current rating of the Port’s receptacle and whether the inserted cable is PD or non-PD rated and if so what is the
capability of the plug. This will set an upper bound for the capabilities which may be offered. After this the Device
Policy Manager will consider the available power supply resources since this will bound which voltages and currents
may be offered. Finally, the Device Policy Manager will consider what power is currently allocated to other ports,
which power is in the Power Reserve and any other amendments to Policy from the System Policy Manager. The
Device Policy Manager will offer a set of capabilities within the bounds detailed above.
When selecting a capability for a given Sink Port the Device Policy Manager will first look at the capabilities offered by
the Source. The Device Policy Manager will take into account the current rating of the Port’s receptacle and for Type-
A/Type-B plugs whether the inserted cable is PD or non-PD rated and if so what is the capability of the plug. This will
set an upper bound for the capabilities which may be requested. The Device Policy Manager will also consider which
capabilities are required by the Sink in order to operate. If an appropriate match for Voltage and Current can be found
within the limits of the receptacle and cable then this will be requested from the Source. If an appropriate match
cannot be found then a request for an offered voltage and current will be made, along with an indication of a capability
mismatch.
For Dual-Role Ports the Device Policy Manager manages the functionality of both a Source and a Sink. In addition it is
able to manage the Power Role Swap process between the two. In terms of power management this could mean that a
Port which is initially consuming power as a Sink is able to become a power resource as a Source. Conversely,
attached Sources may request that power be provided to them.
The functionality within the Device Policy Manager (and to a certain extent the Policy Engine) is scalable depending
on the complexity of the device, including the number of different power supply capabilities and the number of
different features supported for example System Policy Manager interface or Capability Mismatch, and the number of
ports being managed. Within these parameters it is possible to implement devices from very simple power supplies
to more complex power supplies or devices such as USB hubs or Hard Drives. Within multiport devices it is also
permitted to have a combination of USB Power Delivery and non-USB Power Delivery ports which should all be
managed by the Device Policy Manager.
As noted in Section 2.6 the logical architecture used in the PD specification will vary depending on the
implementation. This means that different implementations of the Device Policy Manager may be relative small or
large depending on the complexity of the device, as indicated above. It is also possible to allocate different
responsibilities between the Policy Engine and the Device Policy Manager, which will lead to different types of
architectures and interfaces.
The Device Policy Manager is responsible for the following:
 Maintaining the Local Policy for the device
USB Power Delivery Specification Revision 2.0, Version 1.1 Page 275
 For a Source, monitoring the present capabilities and triggering notifications of the change.
 For a Sink, evaluating and responding to capabilities related requests from the Policy Engine for a given Port.
 Control of the Source/Sink in the device.
 Control of the cable detection module for each Port.
 Interface to the Policy Engine for a given Port.
The Device Policy Manager is responsible for the following optional features when implemented:
 Communications with the System Policy over USB.
 For Sources with multiple ports monitoring and balancing power requirements across these ports.
 Monitoring of batteries and AC power supplies.

8.2.1 Capabilities
The Device Policy Manager in a Provider shall know the power supplies available in the device and their capabilities.
In addition it shall be aware of any other PD Sources of power such as batteries and AC inputs. The available power
sources and existing demands on the device shall be taken into account when presenting capabilities to a Sink.
The Device Policy Manager in a Consumer shall know the requirements of the Sink and use this to evaluate the
capabilities offered by a Source. It shall be aware of its own power sources e.g. Batteries or AC supplies where these
have a bearing on its operation as a Sink.
The Device Policy Manager in a Provider/Consumer or Consumer/Provider shall combine the above capabilities and
shall also be able to present the dual-role nature of the device to an attached PD Capable device.

8.2.2 System Policy

A given PD Capable device may have no USB capability, or PD may have been added to a USB device in such a way that
PD is not integrated with USB. In these two cases there shall be no requirement for the Device Policy Manager to
interact with the USB interface of the device. The following requirements shall only apply to PD devices that expose
PD functionality over USB.
The Device Policy Manager shall communicate over USB with the System Policy Manager according to the
requirements detailed in Chapter 9. Whenever requested the Device Policy Manager shall implement a Local Policy
according to that requested by the System Policy Manager. For example the System Policy Manager may request that
a battery powered Device temporarily stops charging so that there is sufficient power for a HDD to spin up.
The System Policy Manager may operate in an “Intrusive” POLICY_MODE where supported by a PD Capable device.
This means that each and every request, which can be handled by the System Policy Manager, received by the Device
Policy Manager is passed up to the USB Host for a response. In practice this means that there is a Device Policy
Manager running on the USB Host and communicating via the USB bus to the PD Module. This enables software based
implementations of the Device Policy Manager but has serious implications in terms of response times which have to
be taken into consideration.
Note: that due to timing constraints, a PD Capable device shall be able to respond autonomously to all time-critical PD
related requests.

8.2.3 Control of Source/Sink

The Device Policy Manager for a Provider shall manage the power supply for each PD Source Port and shall know at
any given time what the negotiated power is. It shall request transitions of the supply and inform the Policy Engine
whenever a transition completes.
The Device Policy Manager for a Consumer shall manage the Sink for each PD Sink Port and shall know at any given
time what the negotiated power is.
The Device Policy Manager for a Provider/Consumer or Consumer/Provider shall manage the transition between
Source/Sink roles for each PD Dual-Role Port and shall know at any given time what operational role the Port is in.

Page 276 USB Power Delivery Specification Revision 2.0, Version 1.1
The Device Policy Manager for a Consumer/Provider shall be able to detect and handle cases where back-powering is
required due to a Dead Battery on the Provider/Consumer side. It shall determine the absence of VBUS and the
Provider/Consumer’s ability to be back-powered from the Cable Detection module. It shall then initiate Provider role
and instruct the power supply to start providing default output power. Refer to Section 4.1.
The Device Policy Manager for a Provider/Consumer may be able to detect and handle cases where back-powering is
possible due to a Dead Battery. Where supported it shall determine the presence of VBUS from the Cable Detection
module. It shall then initiate Consumer role and instruct the power supply to start sinking default input power.

8.2.4 Cable Detection

8.2.4.1 Device Policy Manager in a Provider
The Device Policy Manager in the Provider shall control the Cable Detection module and shall be able to use the Cable
Detection module to determine the attachment of a cable and for Type-A/Type-B whether it is a USB Power Delivery
or non-USB Power Delivery cable.
This information and the type of receptacle on the local device shall be used to determine the capabilities of the Port
and attached cabling. Note: that it may be necessary for the Device Policy Manager to also initiate additional
discovery via Structured VDM Messages in order to determine the full capabilities of the cabling (see Section 6.4.4.2).

8.2.4.2 Device Policy Manager in a Consumer

The Device Policy Manager in a Consumer controls the Cable Detection module and shall be able to use the Cable
Detection module to determine the attachment of a USB Power Delivery or non-USB Power Delivery cable.
The type of cabling and receptacle together determine the current carrying ability of the Port and attached cabling.

8.2.4.3 Device Policy Manager in a Consumer/Provider

The Device Policy Manager in a Consumer/Provider inherits characteristics of Consumers and Providers and shall
control the Cable Detection module in order to support the Dead Battery back-powering case to determine the
following for a given Port:
 Attachment of a USB Power Delivery Provider/Consumer which supports Dead Battery back-powering
 Presence of VBUS.

8.2.4.4 Device Policy Manager in a Provider/Consumer

The Device Policy Manager in a Provider/Consumer inherits characteristics of Consumers and Providers and may
control the Cable Detection module in order to support the Dead Battery back-powering case to determine the
following for a given Port:
 Presence of VBUS.

8.2.5 Managing Power Requirements

The Device Policy Manager in a Provider shall be aware of the power requirements of all devices connected to its
Source Ports. This includes being aware of any reserve power that may be required by devices in the future and
ensuring that power is shared optimally amongst attached PD Capable devices. This is a key function of the Device
Policy Manager, whose implementation is critical to ensuring that all PD Capable devices get the power they require in
a timely fashion in order to facilitate smooth operation. This is balanced by the fact that the Device Policy Manager is
responsible for managing the sources of power that are, by definition, finite.
The Consumer’s Device Policy Manager shall ensure that it takes no more power than is required to perform its
functions and gives back unneeded power whenever possible (in such cases the Provider shall maintain a Power
Reserve to ensure future operation is possible).

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 277
 8.2.5.1 Managing the Power Reserve
There may be some products where a Device has certain functionality at one power level and a greater functionality at
another, for example a Printer/Scanner that operates only as a printer with one power level and as a scanner if it can
get more power. Visibility of the linkage between power and functionality will only be apparent at the USB Host;
however the Device Policy Manager provides the mechanisms to manage the power requirements of such Devices.
Devices with the GiveBack flag cleared report Operating Current and Maximum Operating Current (see Section 6.4.2).
For many Devices the Operating Current and the Maximum Operating Current will be the same. Devices with highly
variable loads, such as Hard Disk Drives, may use Maximum Operating Current.
Devices with the GiveBack flag set report Operating Current and Minimum Operating Current (see Section 6.4.2). For
many Devices the Operating Current and the Minimum Operating Current will be the same. Devices that charge their
own batteries may use the Minimum Operating Current and GiveBack flag.
For example in the first case, a mobile device may require 500mA to operate, but would like an additional 1000mA to
charge its battery. The mobile device would set the GiveBack flag (see Section 6.4.2.2) and request 500mA in the
Minimum Operating Current field and 1500mA in the Operating Current field (provided that 1500mA was offered by
the Source) indicating to the Provider that it could temporarily recover the 1000mA to meet a transitory request.
In the second case, a Hard Disk Drive (HDD) may require 2A to spin-up, but only 1A to operate. At startup the HDD
would request Maximum Operating Current of 2A and an Operating Current of 2A. After the drive is spun-up and
ready to operate it would make another request of 1A for its Operating Current and 2A for its Maximum Operating
Current. Over time, its inactivity timers may expire and the HDD will go to a lower power state. When the HDD is next
accessed, it has to spin-up again. So it will request an Operating Current of 2A and a Maximum Operating Current of
2A. The Provider may have the extra power available immediately and can immediately honor the request. If the
power is not available, the Provider may have to harvest power, for example use the GotoMin Message to get back
some power before honoring the HDD’s request. In such a case, the HDD would be told to wait using a Wait Message.
The HDD continues to Request additional power until the request is finally granted.
It shall be the Device Policy Manager’s responsibility to allocate power and maintain a Power Reserve so as not to
over-subscribe its available power resource. A Device with multiple ports such as a Hub shall always be able to meet
the incremental demands of the Port requiring the highest incremental power from its Power Reserve.
The GotoMin Message is designed to allow the Provider to reclaim power from one Port to support a Consumer on
another Port that temporarily requires additional power to perform some short term operation. In the example
above, the mobile device that is being charged reduces its charge rate to allow a Device Policy Manager to meet a
request from an HDD for start-up current required to spin-up its platters. Any power which is available to be
reclaimed using a GotoMin Message may be counted as part of the Power Reserve.
A Consumer requesting power shall take into account its operational requirements when advertising its ability to
temporarily return power. For example, a mobile device with a Dead Battery that is being used to make a call should
make a request that retains sufficient power to continue the call. When the Consumer’s requirements change, it shall
re-negotiate its power to reflect the changed requirements.

8.2.5.2 Power Capability Mismatch

A capability mismatch occurs when a Consumer cannot obtain required power from a Provider (or the Source is not
PD Capable) and the Consumer requires such capabilities to operate. Different actions are taken by the Device Policy
Manager and the System Policy Manager in this case.

8.2.5.2.1 Local device handling of mismatch

The Consumer’s Device Policy Manager shall cause a Message to be displayed to the end user that a power capability
mismatch has occurred. Examples of such feedback can include:
 For a simple Device an LED may be used to indicate the failure. For example, during connection the LED could be
solid amber. If the connection is successful the LED could change to green. If the connection fails it could be red
or alternately blink amber.

Page 278 USB Power Delivery Specification Revision 2.0, Version 1.1
 A more sophisticated Device with a user interface, e.g., a mobile device or monitor, should provide notification
through the user interface on the Device.
The Provider’s Device Policy Manager may cause a Message to be displayed to the user of the power capability
mismatch.

8.2.5.2.2 Device Policy Manager Communication with System Policy

In a USB Power Delivery aware system with an active System Policy manager (see Section 8.2.2), the Device Policy
Manager shall notify the System Policy Manager of the mismatch. This information shall be passed back to the System
Policy Manager using the mechanisms described in Chapter 8.3.3. The System Policy Manager should ensure that the
user is informed of the condition. When another Port in the system could satisfy the Consumer’s power requirements
the user should be directed to move the Device to the alternate Port.
In order to identify a more suitable Source Port for the Consumer the System Policy Manager shall communicate with
the Device Policy Manager in order to determine the Consumer’s requirements. The Device Policy Manager shall use a
Get_Sink_Cap Message (see Section 6.3.8) to discover which power levels can be utilized by the Consumer.

8.2.6 Use of “Externally Powered” bit with Batteries and AC supplies

The Device Policy Manager in a Provider or Consumer may monitor the status of any variable sources of power that
could have an impact on its capabilities as a Source such as Batteries and AC supplies and reflect this in the “Externally
Powered” bit (see Section 6.4.1.3.1.3) provided as part of the Source or Sink Capabilities Message (see Section 6.4.1).
When monitored, and a USB interface is supported, the External Power status (see Section 9.4.4) and the battery state
(see Section 9.4.2) shall also be reported to the System Policy Manager using the USB interface.

8.2.6.1 AC Supplies
The Externally Powered bit provided by Sources and Sinks (see Sections 6.4.1.2.3.3 and 6.4.1.3.1.3) refers to the
presence of an external AC power supply (i.e. from a wall wart) that is providing 100% of the power to a given device.
This means that the device is solely getting its power from this power supply and is not aggregating power from other,
non-external, power sources. Logically this power can either be from an AC supply directly connected to the device or
from an AC supply connected to an attached device, which is also getting 100% of its power from this power supply.
The Externally Powered bit is in this way communicated through a PD system indicating that the origin of the power
is from a single or multiple AC supplies:
 If the “Externally Powered” bit is set then that power is originally sourced from an AC supply.
 Devices capable of consuming on multiple ports can only claim that they are “Externally Powered” for the power
advertised as a provider Port if 100% of the consumed power is from external supplies, (e.g. multiple AC
supplies).
 This concept applies as the power is routed through multiple provider and Consumer tiers, so, as an example.
Power provided out of a monitor that is connected to a monitor that gets power from an AC supply, will claim it is
“Externally Powered” even though it is not directly connected to the AC supply.
An example use case is a Tablet computer that is used with two USB A/V displays that are daisy chained (see Figure
8-1). The tablet and 1st display are not externally powered, (meaning, they have no source of power outside of USB
PD). The 2nd display has an external supply attached which may either be a USB PD based supply or some other form
of external supply. When the displays are connected as shown, the power adapter attached to the 2nd display is able
to power both the 1st display and the tablet. In this case the 2nd display will indicate the presence of the wall wart, to
the 1st display, by setting its “Externally Powered” bit. The 1st display will then in turn indicate the presence of an
external supply to the tablet by setting its “Externally Powered” bit. Power is transmitted through the system to all
devices, provided that there is sufficient power available from the external supply.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 279
 Figure 8-1 Example of daisy chained displays
Tablet

Display 1

Display 2

AC

8.2.6.2 Battery Supplies

When monitored, and a USB interface is supported, the battery state shall be reported to the System Policy Manager
using the USB interface.
A simplified algorithm is detailed below to ensure that battery powered devices will get charge from non-battery
powered devices when possible, and also to ensure that devices do not constantly Power Role Swap back and forth.
When two devices are connected that are not Externally Powered, they should define their own policies so as to
prevent constant Power Role Swapping.
This algorithm uses the “Externally Powered” bit (see Sections 6.4.1.2.3.3 and 6.4.1.3.1.3), thus the decisions are based
on the availability of an external supply, not the full capabilities of a system or device or product.
Rules:
1. Provider/Consumers using external sources (“Externally powered” bit set) shall always deny Power Role Swap
requests from Consumer/Providers not using external sources (“Externally Powered” bit cleared).
2. Provider/Consumers not using external sources (“Externally Powered” bit cleared) shall always accept a Power
Role Swap request from a Consumer/Provider using external power sources (“Externally Powered” bit set) unless
the requester is not able to provide the requirements of the present Provider/Consumer.

8.2.7 Interface to the Policy Engine

The Device Policy Manager shall maintain an interface to the Policy Engine for each Port in the device.

8.2.7.1 Device Policy Manager in a Provider

The Device Policy Manager in a Provider shall also provide the following functions to the Policy Engine:
 Inform the Policy Engine of changes in cable/ device attachment status for a given cable.
 Inform the Policy Engine whenever the Source capabilities available for a Port change.
 Evaluate requests from an attached Consumer and provide responses to the Policy Engine.
 Respond to requests for power supply transitions from the Policy Engine.

Page 280 USB Power Delivery Specification Revision 2.0, Version 1.1
 Indication to Policy Engine when power supply transitions are complete.
 Maintain a Power Reserve for devices operating on a Port at less than maximum power.

8.2.7.2 Device Policy Manager in a Consumer

The Device Policy Manager in a Consumer shall also provide the following functions to the Policy Engine:
 Inform the Policy Engine of changes in cable/device attachment status.
 Inform the Policy Engine whenever the power requirements for a Port change.
 Evaluate Source capabilities and provide suitable responses:
o Request from offered capabilities
o Indicate whether additional power is required
 Respond to requests for Sink transitions from the Policy Engine.

8.2.7.3 Device Policy Manager in a Provider/Consumer

The Device Policy Manager in a Provider/Consumer shall provide the following functions to the Policy Engine:
 Provider Device Policy Manager
 Consumer Device Policy Manager
 Interface for the Policy Engine to request power supply transitions from Source to Sink and vice versa.
 Indications to Policy Engine during Power Role Swap transitions.

8.2.7.4 Device Policy Manager in a Provider/Consumer Dead Battery handling

The Device Policy Manager in a Provider/Consumer with a battery should also provide:
 Detection and handling of back powering in the case of a Type-A to Type-B Dead Battery (see Section 4.1.1).
In this scenario a Provider/Consumer shall:
 Detect that VBUS is present and that its battery is dead
 Switch to Consumer role without using a PR_Swap Message
 Use VBUS to power the USB Power Delivery communications

8.2.7.5 Device Policy Manager in a Consumer/Provider

The Device Policy Manager in a Consumer/Provider shall provide the following functions to the Policy Engine:
 Consumer Device Policy Manager
 Provider Device Policy Manager
 Interface for the Policy Engine to request power supply transitions from Sink to Source and vice versa.
 Indications to Policy Engine during Power Role Swap transitions.

8.2.7.6 Device Policy Manager in a Consumer/Provider Dead Battery handling

The Device Policy Manager in a Consumer/Provider shall also provide:
 Detection and handling of back powering in the case of a Dead Battery (see Section 4.1).
In this scenario a Consumer/Provider shall:
 Detect that a Provider/Consumer with a Dead Battery capable of being back powered is attached
 Check that VBUS is not present.
 Temporarily output vSafeDB on VBUS to provide power to the Provider/Consumer so that it can send a Bit Stream.
 Detect Bit Stream sent by Provider/Consumer.
 Switch to the Provider role without using a PR_Swap Message and output vSafe5V on VBUS that will power the
Provider/Consumer’s PD communications.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 281
 8.3 Policy Engine
8.3.1 Introduction
There is one Policy Engine instance per Port that interacts with the Device Policy Manager in order to implement the
present Local Policy for that particular Port. This section includes:
 Message sequences for various operations
 A state diagram of the Policy Engine for a Source Port
 A state diagram of the Policy Engine for a Sink Port
 A state diagram of the Policy Engine for Dual-Role Ports
 State diagrams for handling Soft Reset
 State diagrams for handling Ping Messages
 State diagrams for the Provider/Consumer and Consumer/Provider dead-battery/back-powering case
 State diagrams for Hard Reset
 State diagrams for BIST

8.3.2 Message Sequence Diagrams

The Device Policy Engine drives the Message sequences and responses based on both the expected Message
sequences and the present Local Policy. This section contains sequence diagrams that highlight some of the more
interesting transactions. It is by no means a complete summary of all possible combinations, but is illustrative in
nature.

8.3.2.1 Basic Message Exchange

Figure 8-2 Basic Message Exchange (Successful) below illustrates how a Message is sent. Note that the sender may be
either a Source or Sink while the receiver may be either a Sink or Source. The basic Message sequence is the same. It
starts when the Message Sender’s Protocol Layer at the behest of its Policy Engine forms a Message that it passes to
the Physical Layer.

Figure 8-2 Basic Message Exchange (Successful)

Message Sender Message Receiver

: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

1: Send message
2: Message
3: Message + CRC
4: Message
Start CRCReceiveTimer
Check MessageID against
local copy
Store copy of MessageID

5: Message received
6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC Consume message

Check and increment MessageIDCounter

Stop CRCReceiveTimer

9: Message sent

Page 282 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 8-1 Basic Message Flow

Step Message Sender Message Receiver

1 Policy Engine directs Protocol Layer to send a
Message.
2 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
3 Physical Layer appends a CRC and sends the Message. Physical Layer receives the Message and checks the CRC to
verify the Message.
4 Physical Layer removes the CRC and forwards the Message to
the Protocol Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value and
then stores a copy of the new value.
Protocol Layer forwards the received Message information to
the Policy Engine that consumes it.
6 Protocol Layer generates a GoodCRC Message and passes it to
the Physical Layer.
7 Physical Layer receives the Message and checks the Physical Layer appends CRC and sends the GoodCRC
CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
Protocol Layer checks and increments the
MessageIDCounter and stops CRCReceiveTimer.
9 Protocol Layer informs the Policy Engine that the
Message was successfully sent.

8.3.2.2 Errors in Basic Message flow

There are various points during the Message flow where failures in communication or other issues can occur. Figure
8-3 is an annotated version of Figure 8-2 indicating at which points issues may occur.

Figure 8-3 Basic Message flow indicating possible errors

 Message currently being received  Message does not arrive  Message is a retry
 Channel unavailable  Message has bad CRC

Message Sender Message Receiver

: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

1: Send message
2: Message
A 3: Message + CRC B C
4: Message
Start CRCReceiveTimer
Check MessageID against
local copy
Store copy of MessageID
D
5: Message received
E 6: GoodCRC
F 7: GoodCRC + CRC
G 8: GoodCRC Consume message

Check and increment MessageIDCounter

Stop CRCReceiveTimer  Message currently being received
 Channel unavailable
9: Message sent
 GoodCRC does not arrive  Message is unexpected
 GoodCRC has a bad CRC  Message is unknown
 GoodCRC has the wrong MessageID
 Response is not GoodCRC

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 283
 Table 8-2 Potential issues in Basic Message Flow

Point Possible issues

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

Figure 8-4 illustrates one of these cases; the basic Message flow with a retry due to a bad CRC at the Message Receiver.
It starts when the Message Sender’s Protocol Layer at the behest of its Policy Engine forms a Message that it passes to
the Physical Layer. The Protocol Layer is responsible for retries on a “’n’ strikes and you are out” basis
(nRetryCount).

Page 284 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 8-4 Basic Message Flow with Bad CRC followed by a Retry
Message Sender Message Receiver

: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

1: Send message
2: Message
3: Message + CRC

Start CRCReceiveTimer Message is not received or CRC

is bad so message is not passed
to the protocol layer

CRCReceiveTimer expires
Retry and increment RetryCounter

4: Message
5: Message + CRC
6: Message
Start CRCReceiveTimer
Check MessageID against
local copy
Store copy of MessageID

7: Message received
8: GoodCRC
9: GoodCRC + CRC
10: GoodCRC Consume message

Check and increment MessageIDCounter

Reset RetryCounter
Stop CRCReceiveTimer

11: Message sent

Table 8-3 Basic Message Flow with CRC failure

Step Message Sender Message Receiver

1 Policy Engine directs Protocol Layer to send a
Message.
2 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
3 Physical Layer appends a CRC and sends the Message. Physical Layer receives no Message or a Message with an
incorrect CRC. Nothing is passed to Protocol Layer.
4 Since no response is received, the CRCReceiveTimer
will expire and trigger the first retry by the Protocol
Layer. The RetryCounter is incremented. Protocol
Layer passes the Message to the Physical Layer. Starts
CRCReceiveTimer.
5 Physical Layer appends a CRC and sends the Message. Physical Layer receives the Message and checks the CRC to
verify the Message.
6 Physical Layer removes the CRC and forwards the Message to
the Protocol Layer.
7 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value and
then stores a copy of the new value.
Protocol Layer forwards the received Message information to
the Policy Engine that consumes it.
8 Protocol Layer generates a GoodCRC Message and passes it to
the Physical Layer.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 285
 Step Message Sender Message Receiver
9 Physical Layer receives the Message and checks the Physical Layer appends CRC and sends the GoodCRC
CRC to verify the Message. Message.
10 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
11 Protocol Layer verifies the MessageID, stops
CRCReceiveTimer and resets the RetryCounter.
Protocol Layer informs the Policy Engine that the
Message was successfully sent.

8.3.2.3 Power Negotiation

Figure 8-5 illustrates an example of a successful Message flow during Power Negotiation. The negotiation goes
through 5 distinct phases:
 The Source sends out its power capabilities in a Source_Capabilities Message.
 The Sink evaluates these capabilities and in the request phase selects one power level by sending a Request
Message.
 The Source evaluates the request and accepts the request with an Accept Message.
 The Source transitions to the new power level and then informs the Sink by sending a PS_RDY Message.
 The Sink starts using the new power level.

Page 286 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 8-5 Successful Power Negotiation

Source Sink

: Source Policy Engine : Protocol : PHY : PHY : Protocol : Sink Policy Engine

Cable Capabilities detected

Plug type detected

1: Send Capabilities
2: Capabilities
3: Capabilities + CRC
Start CRCReceiveTimer 4: Capabilities

Check MessageID against local copy

Store copy of MessageID

5: Capabilities received
6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC

Check and increment MessageIDCounter

Stop CRCReceiveTimer

9: Capabilities sent
Evaluate Capabilities
Start SenderResponseTimer Detect plug type

10: Send Request

11: Request
12: Request + CRC
13: Request Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Request received

15: GoodCRC
Stop SenderResponseTimer 16: GoodCRC + CRC
17: GoodCRC
Check and increment MessageIDCounter
Stop CRCReceiveTimer

18: Request sent

Evaluate Request Start SenderResponseTimer

19: Send Accept

20: Accept
21: Accept + CRC
Start CRCReceiveTimer 22: Accept
Check MessageID against local copy
Store copy of MessageID

23: Accept received

24: GoodCRC
25: GoodCRC + CRC Stop SenderResponseTimer
26: GoodCRC Start PSTransitionTimer
Reduce current
Check and increment MessageIDCounter
Stop CRCReceiveTimer

27: Accept sent

Power supply adjusted to negotiated output

Send Ping if required to maintain activity Prepare for new power

28: Send PS_RDY

29: PS_RDY
30: PS_RDY + CRC
Start CRCReceiveTimer 31: PS_RDY

Check MessageID against local copy

Store copy of MessageID

32: PS_RDY received

33: GoodCRC
34: GoodCRC + CRC
35: GoodCRC Stop PSTransitionTimer
Start SinkActivityTimer
Check and increment MessageIDCounter (if ping required)
Stop CRCReceiveTimer

36: PS_RDY sent

Start SourceActivityTimer
(if ping required)

New Power level

Table 8-4 below provides a detailed explanation of what happens at each labeled step in Figure 8-5 above.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 287
 Table 8-4 Steps for a successful Power Negotiation

Step Source Sink

1 The Cable Capabilities or Plug Type are detected if
these are not already known (see Section 4.4). Policy
Engine directs the Protocol Layer to send a
Source_Capabilities Message that represents the
power supply’s present capabilities.
2 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
3 Physical Layer appends CRC and sends the Physical Layer receives the Source_Capabilities
Source_Capabilities Message. Message and checks the CRC to verify the Message.
4 Physical Layer removes the CRC and forwards the
Source_Capabilities Message to the Protocol Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received
Source_Capabilities Message information to the
Policy Engine that consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Source_Capabilities Message was successfully sent.
Policy Engine starts SenderResponseTimer.
10 Policy Engine evaluates the Source_Capabilities
Message sent by the Source, detects the plug type if
this is necessary (see Section 4.4) and selects which
power it would like. It tells the Protocol Layer to form
the data (e.g. Power Data Object) that represents its
Request into a Message.
11 Protocol Layer creates the Request Message and
passes to Physical Layer. Starts CRCReceiveTimer.
12 Physical Layer receives the Request Message and Physical Layer appends a CRC and sends the Request
compares the CRC it calculated with the one sent to Message.
verify the Message.
13 Physical Layer removes the CRC and forwards the
Request Message to the Protocol Layer.
14 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer passes the Request information
to the Policy Engine. Policy Engine stops
SenderResponseTimer.
15 The Protocol Layer generates a GoodCRC Message
and passes it to its Physical Layer.
16 Physical Layer appends CRC and sends the Message. Physical Layer receives the Message and compares
the CRC it calculated with the one sent to verify the
Message.

Page 288 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Source Sink
17 Physical Layer forwards the GoodCRC Message to the
Protocol Layer.
18 The protocol Layer verifies and increments the
MessageIDCounter. It informs the Policy Engine that
the Request Message was successfully sent. The
Protocol Layer stops the CRCReceiveTimer.
The Policy Engine starts SenderResponseTimer.
19 Policy Engine evaluates the Request Message sent by
the Sink and decides if it can meet the request. It
tells the Protocol Layer to form an Accept Message.
20 The Protocol Layer forms the Accept Message that is
passed to the Physical Layer and starts the
CRCReceiveTimer.
21 Physical Layer appends CRC and sends the Accept Physical Layer receives the Message and compares
Message. the CRC it calculated with the one sent to verify the
Message.
22 Physical Layer forwards the Accept Message to the
Protocol Layer.
23 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
Protocol Layer informs the Policy Engine that an
Accept Message has been received. The Policy Engine
stops SenderResponseTimer, starts the
PSTransitionTimer and reduces its current draw.
The Device Policy Manager prepares the Power
supply for transition to the new power level.
24 The Protocol Layer generates a GoodCRC Message
and passes it to its Physical Layer.
25 Physical Layer receives the Message and compares Physical Layer appends CRC and sends the Message.
the CRC it calculated with the one sent to verify the
Message.
26 Physical Layer forwards the GoodCRC Message to the
Protocol Layer. The Protocol Layer verifies and
increments the MessageIDCounter and stops the
CRCReceiveTimer.
27 The Protocol Layer informs the Policy Engine that an
Accept Message was successfully sent.
power supply Adjusts its Output to the Negotiated Value
28 The Device Policy Manager informs the Policy Engine
that the power supply has settled at the new
operating condition and tells the Protocol Layer to
send a PS_RDY Message. If the time taken to settle
exceeds tSourceActivity then a Ping Message will be
sent.
29 The Protocol Layer forms the PS_RDY Message and
starts the CRCReceiveTimer.
30 Physical Layer appends CRC and sends the PS_RDY Physical Layer receives the PS_RDY Message and
Message. compares the CRC it calculated with the one sent to
verify the Message.
31 Physical Layer forwards the PS_RDY Message to the
Protocol Layer.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 289
 Step Source Sink
32 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
Protocol Layer informs the Policy Engine that a
RS_RDY has been received. The Policy Engine stops
the PSTransitionTimer and starts the
SinkActivityTimer to monitor for Ping Message
timeout if required (see Section 6.3.5).
33 The Protocol Layer generates a GoodCRC Message
and passes it to its Physical Layer.
34 Physical Layer receives the Message and compares Physical Layer appends CRC and sends the Message.
the CRC it calculated with the one sent to verify the
Message.
35 Physical Layer forwards the GoodCRC Message to the
Protocol Layer. The Protocol Layer verifies and
increments the MessageIDCounter. Stops the
CRCReceiveTimer.
36 The Protocol Layer informs the Policy Engine that
the PS_RDY Message was successfully sent. The
Policy Engine starts the SourceActivityTimer in
order to start pinging if required (see Section 6.3.5).

Page 290 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.2.4 Reclaiming Power with GotoMin Message
This is an example of a GotoMin operation. Figure 8-6 shows the Messages as they flow across the bus and within the
devices to accomplish the GotoMin.

Figure 8-6 Successful GotoMin operation

Source Sink

: Source Policy Engine : Protocol : PHY : PHY : Protocol : Sink Policy Engine

1: Send GotoMin
2: GotoMin
3: GotoMin + CRC
Start CRCReceiveTimer 4: GotoMin
Check MessageID against local copy
Store copy of MessageID

5: GotoMin received
6: GoodCRC
7: GoodCRC + CRC Start PSTransitionTimer
8: GoodCRC Reduce current
Check and increment MessageIDCounter
Stop CRCReceiveTimer

9: GotoMin sent

Power supply adjusted to pre-negotiated output current

Send Ping if required to maintain activity

10: Send PS_RDY

11: PS_RDY
12: PS_RDY + CRC
Start CRCReceiveTimer 13: PS_RDY

Check MessageID against local copy

Store copy of MessageID

14: PS_RDY received

15: GoodCRC
16: GoodCRC + CRC Stop PSTransitionTimer
17: GoodCRC Start SinkActivityTimer (optional)
Check and increment MessageIDCounter
Stop CRCReceiveTimer

18: PS_RDY sent

Start SourceActivityTimer
(ping)

New Power level

The table below provides a detailed explanation of what happens at each labeled step in Figure 8-6 above.

Table 8-5 Steps for a GotoMin Negotiation

Step Source Sink

1 Policy Engine tells the Protocol Layer to form a
GotoMin Message.
2 The Protocol Layer forms the GotoMin Message that
is passed to the Physical Layer and starts the
CRCReceiveTimer.
3 Physical Layer appends CRC and sends the GotoMin Physical Layer receives the Message and compares
Message. the CRC it calculated with the one sent to verify the
Message.
4 Physical Layer forwards the GotoMin Message to the
Protocol Layer.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 291
 Step Source Sink
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
Protocol Layer informs the Policy Engine that a
GotoMin Message has been received. The Policy
starts the PSTransitionTimer and reduces its current
draw.
The Policy Engine prepares the Power supply for
transition to the new power level.
6 The Protocol Layer generates a GoodCRC Message
and passes it to its Physical Layer.
7 Physical Layer receives the Message and compares Physical Layer appends CRC and sends the Message.
the CRC it calculated with the one sent to verify the
Message.
8 Physical Layer forwards the GoodCRC Message to the
Protocol Layer. The Protocol Layer verifies and
increments the MessageIDCounter and stops the
CRCReceiveTimer.
9 The Protocol Layer informs the Policy Engine that a
GotoMin Message was successfully sent.
power supply Adjusts its Output to the Negotiated Value
10 Policy Engine sees the power supply has settled at
the new operating condition and tells the Protocol
Layer to send a PS_RDY Message. If the time taken to
settle exceeds tSourceActivity then a Ping Message
will be sent (if required see Section 6.3.5).
11 The Protocol Layer forms the PS_RDY Message and
starts the CRCReceiveTimer.
12 Physical Layer appends CRC and sends the PS_RDY Physical Layer receives the Message and compares
Message. the CRC it calculated with the one sent to verify the
Message.
13 Physical Layer forwards the PS_RDY Message to the
Protocol Layer.
14 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
Protocol Layer informs the Policy Engine that a
PS_RDY Message has been received. The Policy
Engine stops the PSTransitionTimer and optionally
starts the SinkActivityTimer to monitor for Ping
Message timeout (if required see Section 6.3.5).
15 The Protocol Layer generates a GoodCRC Message
and passes it to its Physical Layer.
16 Physical Layer receives the Message and compares Physical Layer appends CRC and sends the Message.
the CRC it calculated with the one sent to verify the
Message.
17 Physical Layer forwards the GoodCRC Message to the
Protocol Layer. The Protocol Layer verifies and
increments the MessageIDCounter and stops the
CRCReceiveTimer.
18 The Protocol Layer informs the Policy Engine that
the PS_RDY Message was successfully sent. The
Policy Engine starts the SourceActivityTimer in
order to start pinging (if required see Section 6.3.5).

Page 292 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.2.5 Soft Reset
This is an example of a Soft Reset operation. Figure 8-7 shows the Messages as they flow across the bus and within
the devices to accomplish the Soft Reset.

Figure 8-7 Soft Reset

Reset Initiator Reset Responder

: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

1: Send Soft Reset

Reset MessageIDCounter and

RetryCounter

2: Soft Reset
3: Soft Reset + CRC
Start CRCReceiveTimer 4: Soft Reset

Reset MessageIDCounter and

RetryCounter

5: Soft Reset received

6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC

Check and increment MessageIDCounter

Stop CRCReceiveTimer

9: Soft Reset sent

Start SenderResponseTimer

10: Send Accept

11: Accept
12: Accept + CRC
Start CRCReceiveTimer
13: Accept

Store copy of MessageID

14: Accept received

15: GoodCRC 16: GoodCRC + CRC
17: GoodCRC
Stop SenderResponseTimer
Check and increment MessageIDCounter
Stop CRCReceiveTimer

18: Accept sent

Reset Complete, Explicit Contract negotiation

Table 8-6 below provides a detailed explanation of what happens at each labeled step in Figure 8-7 above.

Table 8-6 Steps for a Soft Reset

Step Reset Initiator Reset Responder

1 The Policy Engine directs the Protocol Layer to
generate a Soft_Reset Message to request a Soft
Reset.
2 Protocol Layer resets MessageIDCounter and
RetryCounter. Protocol Layer creates the Message
and passes to Physical Layer. Starts
CRCReceiveTimer.
3 Physical Layer appends CRC and sends the Physical Layer receives the Soft_Reset Message and
Soft_Reset Message. compares the CRC it calculated with the one sent to
verify the Message.
4 Physical Layer removes the CRC and forwards the
Soft_Reset Message to the Protocol Layer.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 293
 Step Reset Initiator Reset Responder
5 Protocol Layer does not check the MessageID in the
incoming Message and resets MessageIDCounter and
RetryCounter.
The Protocol Layer forwards the received Soft_Reset
Message information to the Policy Engine that
consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC and checks the Physical Layer appends CRC and sends the GoodCRC
CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Soft_Reset Message was successfully sent. Policy
Engine starts SenderResponseTimer.
10 Policy Engine tells the Protocol Layer to form an
Accept Message.
11 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
12 Physical Layer receives the Message and compares Physical Layer appends a CRC and sends the Message.
the CRC it calculated with the one sent to verify the
Message.
13 Protocol Layer stores the MessageID of the incoming
Message.
14 The Protocol Layer forwards the received Accept
Message information to the Policy Engine that
consumes it.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
18 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Accept Message was successfully sent.
The reset is complete and protocol communication can restart. Port Partners perform an Explicit Contract
negotiation to re-synchronise their state machines.

Page 294 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.2.6 Hard Reset
The following sections describe the steps required for a USB Power Delivery Hard Reset. The Hard Reset returns the
operation of the USB Power Delivery to default role and operating voltage/current. During the Hard Reset USB Power
Delivery PHY Layer communications shall be disabled preventing communication between the Port partners.
Note: Hard Reset, in this case, is applied to the USB Power Delivery capability of an individual Port on which the Hard
Reset is requested. A side effect of the Hard Reset is that it might reset other functions on the Port such as USB.

8.3.2.6.1 Source Initiated Hard Reset

This is an example of a Hard Reset operation when initiated by a Source. Figure 8-8 shows the Messages as they flow
across the bus and within the devices to accomplish the Hard Reset.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 295
 Figure 8-8 Source initiated Hard Reset

Source Sink

: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

1: Send Hard Reset

Start NoResponseTimer
Wait tPSHardReset Reset MessageIDCounter and
Reset Power Supply RetryCounter
Reset Port Data Role to DFP
Turn off VCONN
2: Send Hard Reset
3: Hard Reset
4: Hard Reset received
Channel disabled
Channel disabled
Reset MessageIDCounter and
RetryCounter

5: Hard Reset received

Start NoResponseTimer
Reset Power Sink
Reset Port Data Role to UFP
Turn off VCONN

Power Sink Reset

6: Power Sink Reset

7: Hard Reset Complete

Channel enabled

Power Supply Reset

Turn on VCONN

8: Power Supply Reset

9: Hard Reset Complete

Channel enabled

Hard Reset Complete

10: Send Capabilities

11: Capabilities
12: Capabilities + CRC
Start CRCReceiveTimer 13: Capabilities

Store copy of MessageID

14: Capabilities received

15: GoodCRC
16: GoodCRC + CRC Stop NoResponseTimer
17: GoodCRC Evaluate Capabilities

Check and increment MessageIDCounter

Stop CRCReceiveTimer

18: Capabilities sent

Stop NoResponseTimer
Start SenderResponseTimer

Page 296 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 8-7 Steps for Source initiated Hard Reset

Step Source Sink

1 The Policy Engine directs the Protocol Layer to
generate Hard Reset Signaling.
The Policy Engine starts the NoResponseTimer and
requests the Device Policy Manager to reset the
power supply to USB Default Operation. If this is a
Type-C connector the Policy Engine requests the
Device Policy Manager to reset the Port Data Role to
DFP and to turn off VCONN if this is on.
2 Protocol Layer resets MessageIDCounter and
RetryCounter.
Protocol Layer requests the Physical Layer send
Hard Reset Signaling.
3 Physical Layer sends Hard Reset Signaling and then Physical Layer receives the Hard Reset Signaling and
disables the PHY Layer communications channel for disables the PHY Layer communications channel for
transmission and reception. transmission and reception.
4 Physical Layer informs the Protocol Layer of the Hard
Reset.
Protocol Layer resets MessageIDCounter and
RetryCounter.
5 The Protocol Layer informs the Policy Engine of the
Hard Reset.
The Policy Engine starts the NoResponseTimer and
requests the Device Policy Manager to reset the
Power Sink to default operation. If this is a Type-C
connector the Policy Engine requests the Device
Policy Manager to reset the Port Data Role to UFP and
to turn off VCONN if this is on.
6 The Power Sink returns to default operation.
The Policy Engine informs the Protocol Layer that the
Power Sink has been reset.
7 The Protocol Layer informs the PHY Layer that the
Hard Reset is complete.
The PHY Layer enables the PHY Layer
communications channel for transmission and
reception.
8 The power supply is reset to default operation.
If this is a Type-C connector VCONN is turned on.
The Policy Engine informs the Protocol Layer that
the power supply has been reset.
9 The Protocol Layer informs the PHY Layer that the
Hard Reset is complete. The PHY Layer enables the
PHY Layer communications channel for transmission
and reception.
The reset is complete and protocol communication can restart.
10 Policy Engine directs the Protocol Layer to send a
Source_Capabilities Message that represents the
power supply’s present capabilities.
11 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
12 Physical Layer appends CRC and sends the Physical Layer receives the Source_Capabilities
Source_Capabilities Message. Message and checks the CRC to verify the Message.
13 Physical Layer removes the CRC and forwards the
Source_Capabilities Message to the Protocol Layer.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 297
 Step Source Sink
14 Protocol Layer stores the MessageID of the incoming
Message.
The Protocol Layer forwards the received
Source_Capabilities Message information to the
Policy Engine that consumes it. The Policy Engine
stops the NoResponseTimer.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
18 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Source_Capabilities Message was successfully sent.
Policy Engine stops the NoResponseTimer and starts
the SenderResponseTimer.
USB Power Delivery communication is re-established.

Page 298 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.2.6.2 Sink Initiated Hard Reset
This is an example of a Hard Reset operation when initiated by a Sink. Figure 8-9 shows the Messages as they flow
across the bus and within the devices to accomplish the Hard Reset.

Figure 8-9 Sink Initiated Hard Reset

Source Sink

: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

1: Send Hard Reset

Reset MessageIDCounter, Start NoResponseTimer

stored copy of MessageID and Reset Power Sink
RetryCounter Reset Port Data Role to UFP
Turn off VCONN
2: Send Hard Reset

3: Hard Reset
4: Hard Reset received

Channel disabled
Reset MessageIDCounter, stored Channel disabled
copy of MessageID and
RetryCounter Power Sink Reset

5: Hard Reset received

6: Power Sink Reset
7: Hard Reset Complete
Start NoResponseTimer
Reset Power Supply
Channel enabled
Reset Port Data Role to DFP
Turn off VCONN

Power Supply Reset

Turn on VCONN

8: Power Supply Reset

9: Hard Reset Complete

Channel enabled

Hard Reset Complete

10: Send Capabilities

11: Capabilities
12: Capabilities + CRC
Start CRCReceiveTimer 13: Capabilities

Store copy of MessageID

14: Capabilities received

15: GoodCRC
16: GoodCRC + CRC Stop NoResponseTimer
17: GoodCRC Evaluate Capabilities

Check and increment MessageIDCounter

Stop CRCReceiveTimer

18: Capabilities sent

Stop NoResponseTimer
Start SenderResponseTimer

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 299
 Table 8-8 Steps for Sink initiated Hard Reset

Step Source Sink

1 The Policy Engine directs the Protocol Layer to
generate Hard Reset Signaling.
The Policy Engine starts the NoResponseTimer and
requests the Device Policy Manager to reset the
power supply to USB Default Operation. If this is a
Type-C connector the Policy Engine requests the
Device Policy Manager to reset the Port Data Role to
UFP and to turn off VCONN if this is on.
2 Protocol Layer resets MessageIDCounter, stored
copy of MessageID and RetryCounter.
Protocol Layer requests the Physical Layer send Hard
Reset Signaling.
3 Physical Layer receives the Hard Reset Signaling and Physical Layer sends the Hard Reset Signaling and
disables the PHY Layer communications channel for then disables the PHY Layer communications channel
transmission and reception. for transmission and reception.
4 Physical Layer informs the Protocol Layer of the
Hard Reset.
Protocol Layer resets MessageIDCounter, stored
copy of MessageID and RetryCounter.
5 The Protocol Layer Informs the Policy Engine of the
Hard Reset.
The Policy Engine starts the NoResponseTimer and
requests the Device Policy Manager to reset the
Power Sink to default operation. If this is a Type-C
connector the Policy Engine requests the Device
Policy Manager to reset the Port Data Role to DFP
and to turn off VCONN if this is on.
6 The Power Sink returns to USB Default Operation.
The Policy Engine informs the Protocol Layer that the
Power Sink has been reset.
7 The Protocol Layer informs the PHY Layer that the
Hard Reset is complete.
The PHY Layer enables the PHY Layer
communications channel for transmission and
reception.
8 The power supply is reset to USB Default Operation.
If this is a Type-C connector VCONN is turned on.
The Policy Engine informs the Protocol Layer that
the power supply has been reset.
9 The Protocol Layer informs the PHY Layer that the
Hard Reset is complete. The PHY Layer enables the
PHY Layer communications channel for transmission
and reception.
The reset is complete and protocol communication can restart.
10 Policy Engine directs the Protocol Layer to send a
Source_Capabilities Message that represents the
power supply’s present capabilities.
11 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
12 Physical Layer appends CRC and sends the Physical Layer receives the Source_Capabilities
Source_Capabilities Message. Message and checks the CRC to verify the Message.
13 Physical Layer removes the CRC and forwards the
Source_Capabilities Message to the Protocol Layer.

Page 300 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Source Sink
14 Protocol Layer stores the MessageID of the incoming
Message.
The Protocol Layer forwards the received
Source_Capabilities Message information to the
Policy Engine that consumes it. The Policy Engine
stops the NoResponseTimer.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
18 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Source_Capabilities Message was successfully sent.
Policy Engine stops the NoResponseTimer and starts
the SenderResponseTimer.
USB Power Delivery communication is re-established.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 301
 8.3.2.6.3 Source Initiated Hard Reset – Sink Long Reset
This is an example of a Hard Reset operation when initiated by a Source. In this example the Sink is slow responding
to the reset causing the Source to send multiple Source_Capabilities Messages before it receives a GoodCRC Message
response. Figure 8-10 shows the Messages as they flow across the bus and within the devices to accomplish the Hard
Reset.

Figure 8-10 Source initiated reset - Sink long reset

Source Sink

: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

1: Send Hard Reset

2: Send Hard Reset
Start NoResponseTimer 3: Hard Reset
Wait tPSHardReset 4: Hard Reset received
Reset Power Supply 5: Hard Reset received
Reset Port Data Role to DFP Channel disabled
Turn off VCONN Channel disabled
Start NoResponseTimer
Reset Power Sink
Reset Port Data Role to UFP
Turn off VCONN

Power Supply Reset

Turn on VCONN

6: Power Supply Reset

Reset MessageIDCounter, stored

copy of MessageID and
RetryCounter

7: Hard Reset Complete

Channel enabled
8: Send Capabilities
9: Capabilities
10: Capabilities + CRC
Run SourceCapabilityTimer Power Sink Reset
Send Capabilities messages
until GoodCRC response is
11: Power Sink Reset
received.
Reset MessageIDCounter, stored
copy of MessageID and
RetryCounter

12: Hard Reset Complete

Channel enabled

Hard Reset Complete

13: Send Capabilities

14: Capabilities
15: Capabilities + CRC
Start CRCReceiveTimer 16: Capabilities

Store copy of MessageID

17: Capabilities received

18: GoodCRC
19: GoodCRC + CRC Stop NoResponseTimer
20: GoodCRC Evaluate Capabilities

Check and increment MessageIDCounter

Stop CRCReceiveTimer

21: Capabilities sent

Stop SourceCapabilitiesTimer
Stop NoResponseTimer
Start SenderResponseTimer

Page 302 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 8-9 Steps for Source initiated Hard Reset – Sink long reset

Step Source Sink

1 The Policy Engine directs the Protocol Layer to
generate Hard Reset Signaling.
The Policy Engine starts the NoResponseTimer and
requests the Device Policy Manager to reset the
power supply to USB Default Operation. If this is a
Type-C connector the Policy Engine requests the
Device Policy Manager to reset the Port Data Role to
DFP and to turn off VCONN if this is on.
2 Protocol Layer resets MessageIDCounter, stored
copy of MessageID and RetryCounter.
Protocol Layer requests the Physical Layer send
Hard Reset Signaling.
3 Physical Layer sends the Hard Reset Signaling and Physical Layer receives the Hard Reset Signaling and
then disables the PHY Layer communications disables the PHY Layer communications channel for
channel for transmission and reception. transmission and reception.
4 Physical Layer informs the Protocol Layer of the Hard
Reset.
Protocol Layer resets MessageIDCounter, stored
copy of MessageID and RetryCounter.
5 The Protocol Layer Informs the Policy Engine of the
Hard Reset.
The Policy Engine starts the NoResponseTimer and
requests the Device Policy Manager to reset the
Power Sink to default operation. If this is a Type-C
connector the Policy Engine requests the Device
Policy Manager to reset the Port Data Role to UFP and
to turn off VCONN if this is on.
6 The power supply is reset to USB Default Operation.
If this is a Type-C connector VCONN is turned on.
The Policy Engine informs the Protocol Layer that
the power supply has been reset.
7 The Protocol Layer informs the PHY Layer that the
Hard Reset is complete.
The PHY Layer enables the PHY Layer
communications channel for transmission and
reception.
The reset is complete and protocol communication can restart.
8 Policy Engine directs the Protocol Layer to send a
Source_Capabilities Message that represents the
power supply’s present capabilities. Policy Engine
starts the SourceCapabilityTimer. The
SourceCapabilityTimer times out one or more times
until a GoodCRC Message response is received.
9 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
10 Physical Layer appends CRC and sends the Note: Source_Capabilities Message not received since
Source_Capabilities Message. channel is disabled.
11 The Power Sink returns to USB Default Operation.
The Policy Engine informs the Protocol Layer that the
Power Sink has been reset.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 303
 Step Source Sink
12 The Protocol Layer informs the PHY Layer that the
Hard Reset is complete.
The PHY Layer enables the PHY Layer
communications channel for transmission and
reception.
The reset is complete and protocol communication can restart.
13 Policy Engine directs the Protocol Layer to send a
Source_Capabilities Message that represents the
power supply’s present capabilities. Starts the
SourceCapabilityTimer.
14 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
15 Physical Layer appends CRC and sends the Physical Layer receives the Source_Capabilities
Source_Capabilities Message. Message and checks the CRC to verify the Message.
16 Physical Layer removes the CRC and forwards the
Source_Capabilities Message to the Protocol Layer.
17 Protocol Layer stores the MessageID of the incoming
Message.
The Protocol Layer forwards the received
Source_Capabilities Message information to the
Policy Engine that consumes it. The Policy Engine
stops the NoResponseTimer.
18 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
19 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
20 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
21 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Source_Capabilities Message was successfully sent.
Policy Engine stops the SourceCapabilityTimer,
stops the NoResponseTimer and starts the
SenderResponseTimer.
USB Power Delivery communication is re-established.

Page 304 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.2.7 Type-A/B specific Message Sequence Diagrams

8.3.2.7.1 Type-A/B Power Role Swap

8.3.2.7.1.1 Type-A/B Source Initiated Power Role Swap without subsequent Power Negotiation
This is an example of a successful Power Role Swap operation initiated by a Type-A or Type-B Dual-Role Port which
initially, at the start of this Message sequence, is acting as a Source. It does not include any subsequent Power
Negotiation which is required in order to establish an Explicit Contract (see previous section for the details of a Power
Negotiation).
There are four distinct phases to the Power Role Swap negotiation:
1. A PR_Swap Message is sent.
2. An Accept Message in response to the PR_Swap Message.
3. The original Source sets its power output to vSafe0V and sends a PS_RDY Message when it gets there.
4. The new Source then sets its power output to vSafe5V and sends a PS_RDY Message when it is ready to supply
power.
Figure 8-11 shows the Messages as they flow across the bus and within the devices to accomplish the Power Role
Swap sequence.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 305
 Figure 8-11 Type-A or Type-B Successful Power Role Swap Sequence Initiated by the Source

Dual-Role Port (Initially Source Port) Dual-Role Port (initially Sink Port)
: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

Port Power Role = Source Port Power Role = Sink

1: Send PR_Swap
2:PR_Swap
3: PR_Swap + CRC
Start CRCReceiveTimer 4: PR_Swap

Check MessageID against local copy

Store copy of MessageID

5: PR_Swap received
6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC
Check and increment MessageIDCounter
Stop CRCReceiveTimer

9:PR_Swap sent
Evaluate PR_Swap
Start SenderResponseTimer request

10: Send Accept

11: Accept
12: Accept + CRC
13: Accept Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Accept received

15: GoodCRC
16: GoodCRC + CRC
17: GoodCRC
Stop SenderResponseTimer
Tell Power Supply to stop sourcing power Check and increment MessageIDCounter
Send Ping if required to maintain activity Stop CRCReceiveTimer

18: Accept sent

Start PSSourceOffTimer
Power Supply stops Tell Power Sink to stop
sourcing power sinking current

19: Send PS_RDY

Port Power Role -> Sink

20: PS_RDY
21: PS_RDY + CRC
Start CRCReceiveTimer 22: PS_RDY

Check MessageID against local copy

Store copy of MessageID

23: PS_RDY received

24: GoodCRC
25: GoodCRC + CRC
26: GoodCRC Port Power Role -> Source

Check and increment MessageIDCounter

Stop PSSourceOffTimer
Stop CRCReceiveTimer
Set Power Supply to 5V output
27: PS_RDY sent Send Ping if required to maintain activity

Start PSSourceOnTimer

Power Supply reaches 5V

output

28: Send PS_RDY

29: PS_RDY
30: PS_RDY + CRC
31: PS_RDY
Start CRCReceiveTimer
Check MessageID against local copy
Store copy of MessageID

32: PS_RDY received

33: GoodCRC
34: GoodCRC + CRC
Stop PSSourceOnTimer 35: GoodCRC
Tell Power Sink to start
sinking power Check and increment MessageIDCounter
Reset Protocol Layer Stop CRCReceiveTimer

36: PS_RDY sent

Reset CapsCounter
Reset Protocol Layer
Start SwapSourceStartTimer

New Power Roles

Table 8-10 below provides a detailed explanation of what happens at each labeled step in Figure 8-11 above.

Page 306 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 8-10 Steps for a Successful Type-A or Type-B Source Initiated Power Role Swap Sequence

Step Dual-RolePort (initially Source Port) Dual-Role Port (initially Sink Port)
1 Port Power Role starts as Source. Policy Engine Port Power Role starts as Sink.
directs the Protocol Layer to send a PR_Swap
Message.
2 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
3 Physical Layer appends CRC and sends the PR_Swap Physical Layer receives the PR_Swap Message and
Message. checks the CRC to verify the Message.
4 Physical Layer removes the CRC and forwards the
PR_Swap Message to the Protocol Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received PR_Swap
Message information to the Policy Engine that
consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
PR_Swap Message was successfully sent. Policy
Engine starts SenderResponseTimer.
10 Policy Engine evaluates the PR_Swap Message sent by
the Source and decides that it is able and willing to do
the Power Role Swap. It tells the Protocol Layer to
form an Accept Message.
11 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
12 Physical Layer receives the Message and compares Physical Layer appends a CRC and sends the Accept
the CRC it calculated with the one sent to verify the Message.
Accept Message.
13 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received PR_Swap
Message information to the Policy Engine that
consumes it.
14 The Policy Engine requests its power supply to stop
supplying power and stops the
SenderResponseTimer.
If the time taken to stop supplying power exceeds
tSourceActivity then a Ping Message will be sent(if
required see Section 6.3.5).
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 307
 Step Dual-RolePort (initially Source Port) Dual-Role Port (initially Sink Port)
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
18 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Accept Message was successfully sent. The Policy
Engine starts the PSSourceOffTimer and tells the
power supply to stop sinking current.
19 The Policy Engine determines its power supply is no
longer supplying VBUS, it directs the Protocol Layer to
generate a PS_RDY Message, with the Port Power
Role bit in the Message Header set to “Sink”, to tell its
Port Partner that it can begin to Source VBUS.
20 Protocol Layer sets the Port Power Role bit in the
Message Header set to “Sink”, creates the Message
and passes to Physical Layer. Starts
CRCReceiveTimer.
21 Physical Layer appends CRC and sends the PS_RDY Physical Layer receives the PS_RDY Message and
Message. checks the CRC to verify the Message.
22 Physical Layer removes the CRC and forwards the
PS_RDY Message to the Protocol Layer.
23 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received PS_RDY
Message information to the Policy Engine that
consumes it. The Policy Engine stops the
PSSourceOffTimer and starts switching the power
supply to vSafe5V Source operation.
If the time taken to start supplying power exceeds
tSourceActivity then a Ping Message will be sent (if
required see Section 6.3.5).
24 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
25 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
26 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
27 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
PS_RDY Message was successfully sent. Policy
Engine starts PSSourceOnTimer.
28 Policy Engine, when its power supply is ready to
supply power, tells the Protocol Layer to form a
PS_RDY Message. The Port Power Role bit used in
this and subsequent Message Headers is now set to
“Source”.
29 Protocol Layer creates the PS_RDY Message and
passes to Physical Layer. Starts CRCReceiveTimer.
30 Physical Layer receives the PS_RDY Message and Physical Layer appends a CRC and sends the PS_RDY
compares the CRC it calculated with the one sent to Message.
verify the Message.
31 Physical Layer removes the CRC and forwards the
PS_RDY Message to the Protocol Layer.

Page 308 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Dual-RolePort (initially Source Port) Dual-Role Port (initially Sink Port)
32 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received PS_RDY
Message information to the Policy Engine that
consumes it.
33 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
34 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message.. The Policy Engine stops the compares the CRC it calculated with the one sent to
PSSourceOnTimer, informs the power supply it can verify the Message.
now Sink power and resets the Protocol Layer.
35 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
36 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
PS_RDY Message was successfully sent. The Policy
Engine resets the CapsCounter, resets the Protocol
Layer and starts the SwapSourceStartTimer which
must timeout before sending any Source_Capabilities
Messages.
The Power Role Swap is complete, the roles have been reversed and the Port Partners are free to negotiate for
more power.

8.3.2.7.1.2 Type-A/B Sink Initiated Power Role Swap without subsequent Power Negotiation
This is an example of a successful Power Role Swap operation initiated by a Type-A or Type-B Dual-Role Port which
initially, at the start of this Message sequence, is acting as a Sink. It does not include any subsequent Power
Negotiation which is required in order to establish an Explicit Contract (see Section 8.3.2.3).
There are four distinct phases to the Power Role Swap negotiation:
1) A PR_Swap Message is sent.
2) An Accept Message in response to the PR_Swap Message.
3) The original Source sets its power output to vSafe0V and sends a PS_RDY Message when it gets there.
4) The new Source then sets its power output to vSafe5V and sends a PS_RDY Message when it is ready to
supply power.
Figure 8-12 shows the Messages as they flow across the bus and within the devices to accomplish the Power Role
Swap.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 309
 Figure 8-12 Type-A or Type-B Successful Power Role Swap Sequence Initiated by the Sink

Dual-Role Port (Initially Sink Port) Dual-Role Port (Initially Source Port)
: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

Port Power Role = Sink Port Power Role = Source

1: Send PR_Swap
2:PR_Swap
3: PR_Swap + CRC
Start CRCReceiveTimer 4: PR_Swap

Check MessageID against local copy

Store copy of MessageID

5: PR_Swap received
6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC
Check and increment MessageIDCounter
Stop CRCReceiveTimer

9:PR_Swap sent
Evaluate PR_Swap
Start SenderResponseTimer
request

10: Send Accept

11: Accept
12: Accept + CRC
13: Accept Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Accept received

15: GoodCRC
16: GoodCRC + CRC
Stop SenderResponseTimer 17: GoodCRC
Start PSSourceOffTimer
Check and increment MessageIDCounter
Tell Power Sink to stop
Stop CRCReceiveTimer
sinking current
18: Accept sent

Tell Power Supply to stop sourcing power

Send Ping if required to maintain activity

Power Supply stops

sourcing power

19: Send PS_RDY

Port Power Role -> Sink

20: PS_RDY
21: PS_RDY + CRC
22: PS_RDY
Start CRCReceiveTimer
Check MessageID against local copy
Store copy of MessageID

23: PS_RDY received

24: GoodCRC
25: GoodCRC + CRC
Port Power Role -> Source 26: GoodCRC
Check and increment MessageIDCounter
Stop CRCReceiveTimer
Stop PSSourceOffTimer
Set Power Supply to 5V output 27: PS_RDY sent
Send Ping if required to maintain activity
Start PSSourceOnTimer

Power Supply reaches 5V

output

28: Send PS_RDY

29: PS_RDY
30: PS_RDY + CRC
Start CRCReceiveTimer 31: PS_RDY

Check MessageID against local copy

Store copy of MessageID

32: PS_RDY received

33: GoodCRC
34: GoodCRC + CRC
35: GoodCRC Stop PSSourceOnTimer
Check and increment MessageIDCounter Tell Power Supply to start
Stop CRCReceiveTimer sinking power
Reset Protocol Layer
36: PS_RDY sent

Reset CapsCounter
Reset Protocol Layer
Start SwapSourceStartTimer

New Power Roles

Page 310 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 8-11 Steps for a Successful Type-A or Type-B Sink Initiated Power Role Swap Sequence

Step Dual-Role Port (initially Sink Port) Dual-Role Port (initially Source Port)
1 Port Power Role starts as Sink. Policy Engine directs Port Power Role starts as Source.
the Protocol Layer to send a PR_Swap Message.
2 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
3 Physical Layer appends CRC and sends the PR_Swap Physical Layer receives the PR_Swap Message and
Message. checks the CRC to verify the Message.
4 Physical Layer removes the CRC and forwards the
PR_Swap Message to the Protocol Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received PR_Swap
Message information to the Policy Engine that
consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
PR_Swap Message was successfully sent. Policy
Engine starts SenderResponseTimer.
10 Policy Engine evaluates the PR_Swap Message sent by
the Sink and decides that it is able and willing to do
the Power Role Swap. It tells the Protocol Layer to
form an Accept Message.
11 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
12 Physical Layer receives the Message and compares Physical Layer appends a CRC and sends the Accept
the CRC it calculated with the one sent to verify the Message.
Accept Message.
13 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received PR_Swap
Message information to the Policy Engine that
consumes it.
14 The Policy Engine stops the SenderResponseTimer,
starts the PSSourceOffTimer and tells the power
supply to stop sinking current.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 311
 Step Dual-Role Port (initially Sink Port) Dual-Role Port (initially Source Port)
18 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Accept Message was successfully sent. The Policy
Engine tells the power supply to stop supplying
power.
If the time taken to stop supplying power exceeds
tSourceActivity then a Ping Message will be sent (if
required see Section 6.3.5).
19 The Policy Engine determines its power supply is no
longer supplying VBUS, it directs the Protocol Layer to
generate a PS_RDY Message, with the Port Power
Role bit in the Message Header set to “Sink”, to tell its
Port Partner that it can begin to source VBUS.
20 Protocol Layer sets the Port Power Role bit in the
Message Header set to “Sink”, creates the Message
and passes to Physical Layer. Starts
CRCReceiveTimer.
21 Physical Layer receives the PS_RDY Message and Physical Layer appends CRC and sends the PS_RDY
checks the CRC to verify the Message. Message.
22 Physical Layer removes the CRC and forwards the
PS_RDY Message to the Protocol Layer.
23 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received PS_RDY
Message information to the Policy Engine that
consumes it. The Policy Engine stops the
PSSourceOffTimer and starts switching the power
supply to vSafe5V Source operation.
If the time taken to start supplying power exceeds
tSourceActivity then a Ping Message will be sent (if
required see Section 6.3.5).
24 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
25 Physical Layer appends CRC and sends the GoodCRC Physical Layer receives the GoodCRC Message and
Message. checks the CRC to verify the Message.
26 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
27 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
PS_RDY Message was successfully sent. Policy Engine
starts PSSourceOnTimer.
28 Policy Engine, when its power supply is ready to
supply power, tells the Protocol Layer to form a
PS_RDY Message. The Port Power Role bit used in
this and subsequent Message Headers is now set to
“Source”.
29 Protocol Layer creates the PS_RDY Message and
passes to Physical Layer. Starts CRCReceiveTimer.
30 Physical Layer appends a CRC and sends the PS_RDY Physical Layer receives the PS_RDY Message and
Message. compares the CRC it calculated with the one sent to
verify the Message.

Page 312 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Dual-Role Port (initially Sink Port) Dual-Role Port (initially Source Port)
31 Physical Layer removes the CRC and forwards the
PS_RDY Message to the Protocol Layer.
32 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received PS_RDY
Message information to the Policy Engine that
consumes it. The Policy Engine stops the
PSSourceOnTimer, informs the power supply that it
can start consuming power and optionally starts the
SinkActivityTimer to check for Ping Messages.
33 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
34 Physical Layer receives GoodCRC Message and Physical Layer appends a CRC and sends the GoodCRC
compares the CRC it calculated with the one sent to Message. The Policy Engine stops the
verify the Message. PSSourceOnTimer, informs the power supply it can
now Sink power and resets the Protocol Layer.
35 Physical Layer removes the CRC and forwards the
GoodCRC to the Protocol Layer.
36 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
PS_RDY Message was successfully sent. The Policy
Engine resets the CapsCounter, resets the Protocol
Layer and starts the SwapSourceStartTimer which
must timeout before sending any
Source_Capabilities Messages.
The Power Role Swap is complete, the roles have been reversed and the Port Partners are free to negotiate for
more power.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 313
 8.3.2.7.1.3 Type-A/B Source Initiated Hard Reset (Power Role Swapped)
This is an example of a Hard Reset operation when initiated by a Type-A or Type-B Dual-Role device which is
currently Power Role Swapped and initially acting as a Source at the start of this Message sequence. In this example
both Dual-Role devices return to their original roles after the Hard Reset. Figure 8-13 shows the Messages as they
flow across the bus and within the devices to accomplish the Hard Reset.

Figure 8-13 Type-A or Type-B Source initiated Hard Reset (Power Role Swapped)
Provider/Consumer (initially Sink Port) Consumer/Provider (Initially Source Port)

: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

Port Power Role = Sink Port Power Role = Source

1: Send Hard Reset

Start NoResponseTimer
2: Send Hard Reset Tell Power Supply to stop sourcing power
3: Hard Reset
Reset MessageIDCounter, stored
Channel disabled copy of MessageID and
RetryCounter
4: Hard Reset received

Reset MessageIDCounter, stored Channel disabled Port Power Role -> Sink
copy of MessageID and
RetryCounter

Port Power Role -> Source

5: Hard Reset received

Start NoResponseTimer
Tell Power Sink to stop
sinking current

Power Sink stops sinking

current
Power Supply stops sourcing power.
Reverts to Sink Operation
No voltage detected on VBUS
Set Power Supply to 5V output
6: Power Sink Reset

7: Hard Reset Complete

Power Supply reaches 5V
output Channel enabled
5V detected on VBUS
8: Power Supply Reset Tell Power Supply to start sinking power
9: Hard Reset Complete

Channel enabled

Hard Reset Complete

10: Send Capabilities

11: Capabilities
12: Capabilities + CRC
Start CRCReceiveTimer 13: Capabilities

Store copy of MessageID

14: Capabilities received

15: GoodCRC
16: GoodCRC + CRC
17: GoodCRC Stop NoResponseTimer
Evaluate Capabilities
Check and increment MessageIDCounter
Stop CRCReceiveTimer

18: Capabilities sent

Stop NoResponseTimer
Start SenderResponseTimer

Page 314 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 8-12 Steps for Type-A or Type-B Source initiated Hard Reset (Power Role Swapped)

Step Provider/Consumer (InitiallySink Port) Consumer/Provider (InitiallySource Port)

1 Port Power Role starts as Sink. Port Power Role starts as Source. The Policy Engine
directs the Protocol Layer to generate Hard Reset
Signaling.
The Policy Engine starts the NoResponseTimer and
directs the power supply to stop sourcing power.
2 Protocol Layer resets MessageIDCounter, stored
copy of MessageID and RetryCounter.
Port Power Role reverts to Sink.
Protocol Layer requests the Physical Layer send Hard
Reset Signaling.
3 Physical Layer receives the Hard Reset Signaling and Physical Layer sends the Hard Reset Signaling and
disables the PHY Layer communications channel for then disables the PHY Layer communications channel
transmission and reception. for transmission and reception.
4 Physical Layer informs the Protocol Layer of the
Hard Reset.
Protocol Layer resets MessageIDCounter, stored
copy of MessageID and RetryCounter. Port Power
Role reverts to Source.
5 The Protocol Layer Informs the Policy Engine of the
Hard Reset.
The Policy Engine starts the NoResponseTimer and
directs the Sink to stop sinking power.
6 The power supply stops sourcing power on VBUS and
reverts to Sink operation.
The Policy Engine informs the Protocol Layer that the
Sink has been reset.
7 The Protocol Layer informs the PHY Layer that the
Hard Reset is complete.
The PHY Layer enables the PHY Layer
communications channel for transmission and
reception.
When vSafe5V is detected on VBUS the Policy Engine
directs the Sink to start Sinking power.
8 The Sink stops sinking power.
When there is no voltage detected on VBUS the Policy
Engine requests the Source to go to vSafe5V output.
When the Source reaches vSafe5V the Policy Engine
informs the Protocol Layer that the power supply has
been reset.
9 The Protocol Layer informs the PHY Layer that the
Hard Reset is complete.
The PHY Layer enables the PHY Layer
communications channel for transmission and
reception.
The reset is complete and protocol communication can restart.
10 Policy Engine directs the Protocol Layer to send a
Source_Capabilities Message that represents the
power supply’s present capabilities.
11 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
12 Physical Layer appends CRC and sends the Physical Layer receives the Source_Capabilities
Source_Capabilities Message. Message and checks the CRC to verify the Message.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 315
 Step Provider/Consumer (InitiallySink Port) Consumer/Provider (InitiallySource Port)
13 Physical Layer removes the CRC and forwards the
Source_Capabilities Message to the Protocol Layer.
14 Protocol Layer stores the MessageID of the incoming
Message.
The Protocol Layer forwards the received
Source_Capabilities Message information to the
Policy Engine that consumes it.
The Policy Engine stops the NoResponseTimer.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
18 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Source_Capabilities Message was successfully sent.
Policy Engine stops the NoResponseTimer and starts
the SenderResponseTimer.
USB Power Delivery communication is re-established.

Page 316 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.2.7.1.4 Type-A/B Sink Initiated Hard Reset (Power Role Swapped)
This is an example of a Hard Reset operation when initiated by a Type-A or Type-B Dual-Role device which is
currently Power Role Swapped and initially acting as a Sink at the start of this Message sequence. In this example
both Dual-Role devices return to their original roles after the Hard Reset. Figure 8-14 shows the Messages as they
flow across the bus and within the devices to accomplish the Hard Reset.

Figure 8-14 Type-A or Type-B Sink Initiated Hard Reset (Power Role Swapped)

Provider/Consumer (initially Sink Port) Consumer/Provider (Initially Source Port)

: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

Port Power Role = Sink Port Power Role = Source

1: Send Hard Reset

Start NoResponseTimer Reset MessageIDCounter, stored

Tell Power Sink to stop copy of MessageID and
sinking current RetryCounter

Port Power Role -> Source

2: Send Hard Reset

3: Hard Reset
4: Hard Reset received
Channel disabled
Reset MessageIDCounter, stored
Channel disabled
copy of MessageID and
RetryCounter

Port Power Role -> Sink

Power Sink stops sinking
current 5: Hard Reset received

Start NoResponseTimer
Tell Power Supply to stop sourcing power

Power Supply stops sourcing power

Reverts to Sink operation

No voltage detected on VBUS

Set Power Supply to 5V output 6: Power Sink Reset

7: Hard Reset Complete

Power Supply reaches 5V Channel enabled

output
5V detected on VBUS
8: Power Supply Reset Tell Power Supply to start sinking power
9: Hard Reset Complete

Channel enabled

Hard Reset Complete

10: Send Capabilities

11: Capabilities
12: Capabilities + CRC
Start CRCReceiveTimer 13: Capabilities

Store copy of MessageID

14: Capabilities received

15: GoodCRC
16: GoodCRC + CRC
17: GoodCRC Stop NoResponseTimer
Evaluate Capabilities
Check and increment MessageIDCounter
Stop CRCReceiveTimer

18: Capabilities sent

Stop NoResponseTimer
Start SenderResponseTimer

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 317
 Table 8-13 Steps for Type-A or Type-B Sink initiated Hard Reset (Power Role Swapped)

Step Provider/Consumer (InitiallySink Port) Consumer/Provider (InitiallySource Port)

1 Port Power Role starts as Sink. Port Power Role starts as Source.
The Policy Engine directs the Protocol Layer to
generate Hard Reset Signaling.
The Policy Engine starts the NoResponseTimer and
directs the Sink to stop sinking power.
2 Protocol Layer resets MessageIDCounter, stored
copy of MessageID and RetryCounter.
Port Power Role reverts to Source.
Protocol Layer requests the Physical Layer send
Hard Reset Signaling.
3 Physical Layer sends the Hard Reset Signaling and Physical Layer receives the Hard Reset Signaling and
then disables the PHY Layer communications disables the PHY Layer communications channel for
channel for transmission and reception. transmission and reception.
4 Physical Layer informs the Protocol Layer of the Hard
Reset.
Protocol Layer resets MessageIDCounter, stored
copy of MessageID and RetryCounter.
Port Power Role reverts to Sink.
5 The Protocol Layer Informs the Policy Engine of the
Hard Reset.
The Policy Engine starts the NoResponseTimer and
directs the Source to stop sourcing power.
6 The power supply stops sourcing power on VBUS and
reverts to Sink operation.
The Policy Engine informs the Protocol Layer that the
Sink has been reset.
7 The Protocol Layer informs the PHY Layer that the
Hard Reset is complete.
The PHY Layer enables the PHY Layer
communications channel for transmission and
reception.
8 The Sink stops sinking power. When vSafe5V is detected on VBUS the Policy Engine
When there is no voltage detected on VBUS the Policy directs the Sink to start Sinking power.
Engine requests the Source to go to vSafe5V output.
When the Source reaches vSafe5V the Policy Engine
informs the Protocol Layer that the power supply has
been reset.
9 The Protocol Layer informs the PHY Layer that the
Hard Reset is complete.
The PHY Layer enables the PHY Layer
communications channel for transmission and
reception.
The reset is complete and protocol communication can restart.
10 Policy Engine directs the Protocol Layer to send a
Source_Capabilities Message that represents the
power supply’s present capabilities.
11 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
12 Physical Layer appends CRC and sends the Physical Layer receives the Source_Capabilities
Source_Capabilities Message. Message and checks the CRC to verify the Message.
13 Physical Layer removes the CRC and forwards the
Source_Capabilities Message to the Protocol Layer.

Page 318 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Provider/Consumer (InitiallySink Port) Consumer/Provider (InitiallySource Port)
14 Protocol Layer stores the MessageID of the incoming
Message. The Protocol Layer forwards the received
Source_Capabilities Message information to the
Policy Engine that consumes it.
The Policy Engine stops the NoResponseTimer.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
18 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Source_Capabilities Message was successfully sent.
Policy Engine stops the NoResponseTimer and starts
the SenderResponseTimer.
USB Power Delivery communication is re-established.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 319
 8.3.2.8 Type-C specific Message Sequence Diagrams

8.3.2.8.1 Type-C Power Role Swap

8.3.2.8.1.1 Type-C Source Initiated Power Role Swap without subsequent Power Negotiation
This is an example of a successful Power Role Swap operation initiated by a [USBType-C 1.0] Port which initially, at
the start of this Message sequence, is acting as a Source and therefore has Rp pulled up on its CC wire. It does not
include any subsequent Power Negotiation which is required in order to establish an Explicit Contract (see previous
section for the details of a Power Negotiation).
There are four distinct phases to the Power Role Swap negotiation:
1. A PR_Swap Message is sent.
2. An Accept Message in response to the PR_Swap Message.
3. The original Source sets its power output to vSafe0V, then asserts Rd and sends a PS_RDY Message when this
process is complete.
4. The new Source asserts Rp, then sets its power output to vSafe5V and sends a PS_RDY Message when it is ready to
supply power.
Figure 8-15 shows the Messages as they flow across the bus and within the devices to accomplish the Power Role
Swap sequence.

Page 320 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 8-15 Type-C Successful Power Role Swap Sequence Initiated by the Source

Type-C Port (Initially Source Port) Type-C Port (initially Sink Port)
: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

Port Power Role = Source Port Power Role = Sink

CC = Rp CC = Rd
1: Send PR_Swap
2:PR_Swap
3: PR_Swap + CRC
Start CRCReceiveTimer 4: PR_Swap

Check MessageID against local copy

Store copy of MessageID

5: PR_Swap received
6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC
Check and increment MessageIDCounter
Stop CRCReceiveTimer

9:PR_Swap sent
Evaluate PR_Swap
Start SenderResponseTimer request

10: Send Accept

11: Accept
12: Accept + CRC
13: Accept Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Accept received

15: GoodCRC
16: GoodCRC + CRC
17: GoodCRC
Stop SenderResponseTimer
Tell Power Supply to stop sourcing power Check and increment MessageIDCounter
Stop CRCReceiveTimer

18: Accept sent

Start PSSourceOffTimer
Power Supply stops sourcing power
Tell Power Sink to stop
CC -> Rd
sinking current

19: Send PS_RDY

Port Power Role -> Sink

20: PS_RDY
21: PS_RDY + CRC
Start CRCReceiveTimer 22: PS_RDY

Check MessageID against local copy

Store copy of MessageID

23: PS_RDY received

24: GoodCRC
25: GoodCRC + CRC
26: GoodCRC Port Power Role -> Source

Check and increment MessageIDCounter

Stop CRCReceiveTimer Stop PSSourceOffTimer
CC -> Rp
27: PS_RDY sent
Set Power Supply to 5V output
Start PSSourceOnTimer

Power Supply reaches 5V

output

28: Send PS_RDY

29: PS_RDY
30: PS_RDY + CRC
31: PS_RDY
Start CRCReceiveTimer
Check MessageID against local copy
Store copy of MessageID

32: PS_RDY received

33: GoodCRC
34: GoodCRC + CRC
Stop PSSourceOnTimer 35: GoodCRC
Tell Power Sink to start
sinking power Check and increment MessageIDCounter
Reset Protocol Layer Stop CRCReceiveTimer

36: PS_RDY sent

Reset CapsCounter
Reset Protocol Layer
Start SwapSourceStartTimer

New Power Roles

Table 8-10 below provides a detailed explanation of what happens at each labeled step in Figure 8-15 above.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 321
 Table 8-14 Steps for a Successful Type-C Source Initiated Power Role Swap Sequence

Step Type-C Port (initially Source Port) Type-C Port (initially Sink Port)
1 The [USBType-C 1.0] Port has Port Power Role set to The [USBType-C 1.0] Port has Port Power Role set to
Source and the Rp pull up on its CC wire. Sink with the Rd pull down on its CC wire.
Policy Engine directs the Protocol Layer to send a
PR_Swap Message.
2 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
3 Physical Layer appends CRC and sends the PR_Swap Physical Layer receives the PR_Swap Message and
Message. checks the CRC to verify the Message.
4 Physical Layer removes the CRC and forwards the
PR_Swap Message to the Protocol Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received PR_Swap
Message information to the Policy Engine that
consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
PR_Swap Message was successfully sent. Policy
Engine starts SenderResponseTimer.
10 Policy Engine evaluates the PR_Swap Message sent by
the Source and decides that it is able and willing to do
the Power Role Swap. It tells the Protocol Layer to
form an Accept Message.
11 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
12 Physical Layer receives the Message and compares Physical Layer appends a CRC and sends the Accept
the CRC it calculated with the one sent to verify the Message.
Accept Message.
13 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received PR_Swap
Message information to the Policy Engine that
consumes it.
14 The Policy Engine requests its power supply to stop
supplying power and stops the
SenderResponseTimer.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.

Page 322 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Type-C Port (initially Source Port) Type-C Port (initially Sink Port)
18 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Accept Message was successfully sent. The Policy
Engine starts the PSSourceOffTimer and tells the
power supply to stop sinking current.
19 The Policy Engine determines its power supply is no
longer supplying VBUS. The Policy Engine requests
the Device Policy Manager to assert the Rd pull down
on the CC wire. The Policy Engine then directs the
Protocol Layer to generate a PS_RDY Message, with
the Port Power Role bit in the Message Header set to
“Sink”, to tell its Port Partner that it can begin to
Source VBUS.
20 Protocol Layer sets the Port Power Role bit in the
Message Header set to “Sink”, creates the Message
and passes to Physical Layer. Starts
CRCReceiveTimer.
21 Physical Layer appends CRC and sends the PS_RDY Physical Layer receives the PS_RDY Message and
Message. checks the CRC to verify the Message.
22 Physical Layer removes the CRC and forwards the
PS_RDY Message to the Protocol Layer.
23 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received PS_RDY
Message information to the Policy Engine that
consumes it. The Policy Engine stops the
PSSourceOffTimer, directs the Device Policy Manager
to apply the Rp pull up and then starts switching the
power supply to vSafe5V Source operation.
24 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
25 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
26 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
27 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
PS_RDY Message was successfully sent. Policy
Engine starts PSSourceOnTimer.
28 Policy Engine, when its power supply is ready to
supply power, tells the Protocol Layer to form a
PS_RDY Message. The Port Power Role bit used in
this and subsequent Message Headers is now set to
“Source”.
29 Protocol Layer creates the PS_RDY Message and
passes to Physical Layer. Starts CRCReceiveTimer.
30 Physical Layer receives the PS_RDY Message and Physical Layer appends a CRC and sends the PS_RDY
compares the CRC it calculated with the one sent to Message.
verify the Message.
31 Physical Layer removes the CRC and forwards the
PS_RDY Message to the Protocol Layer.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 323
 Step Type-C Port (initially Source Port) Type-C Port (initially Sink Port)
32 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received PS_RDY
Message information to the Policy Engine that
consumes it.
33 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
34 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message.. The Policy Engine stops the compares the CRC it calculated with the one sent to
PSSourceOnTimer, informs the power supply it can verify the Message.
now Sink power and resets the Protocol Layer.
35 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
36 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
PS_RDY Message was successfully sent. The Policy
Engine resets the CapsCounter, resets the Protocol
Layer and starts the SwapSourceStartTimer which
must timeout before sending any Source_Capabilities
Messages.
The Power Role Swap is complete, the roles have been reversed and the Port Partners are free to negotiate for
more power.

Page 324 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.2.8.1.2 Type-C Sink Initiated Power Role Swap without subsequent Power Negotiation
This is an example of a successful Power Role Swap operation initiated by a [USBType-C 1.0] Port which initially, at
the start of this Message sequence, is acting as a Sink and therefore has Rd pulled down its CC wire. It does not include
any subsequent Power Negotiation which is required in order to establish an Explicit Contract (see Section 8.3.2.3).
There are four distinct phases to the Power Role Swap negotiation:
5) A PR_Swap Message is sent.
6) An Accept Message in response to the PR_Swap Message.
7) The original Source sets its power output to vSafe0V, then asserts Rd and sends a PS_RDY Message when this
process is complete.
8) The new Source asserts Rp, then sets its power output to vSafe5V and sends a PS_RDY Message when it is
ready to supply power.
Figure 8-16 shows the Messages as they flow across the bus and within the devices to accomplish the Power Role
Swap.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 325
 Figure 8-16 Type-C Successful Power Role Swap Sequence Initiated by the Type-C Sink

Type-C Port (Initially Sink Port) Type-C Port (Initially Source Port)
: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

Port Power Role = Sink Port Power Role = Source

CC = Rd CC = Rp

1: Send PR_Swap
2:PR_Swap
3: PR_Swap + CRC
Start CRCReceiveTimer 4: PR_Swap

Check MessageID against local copy

Store copy of MessageID

5: PR_Swap received
6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC
Check and increment MessageIDCounter
Stop CRCReceiveTimer

9:PR_Swap sent
Evaluate PR_Swap
Start SenderResponseTimer request

10: Send Accept

11: Accept
12: Accept + CRC
13: Accept Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Accept received

15: GoodCRC
16: GoodCRC + CRC
Stop SenderResponseTimer 17: GoodCRC
Start PSSourceOffTimer
Check and increment MessageIDCounter
Tell Power Sink to stop
Stop CRCReceiveTimer
sinking current
18: Accept sent

Tell Power Supply to stop sourcing power

Power Supply stops sourcing power

CC -> Rd

19: Send PS_RDY

Port Power Role -> Sink

20: PS_RDY
21: PS_RDY + CRC
22: PS_RDY
Start CRCReceiveTimer
Check MessageID against local copy
Store copy of MessageID

23: PS_RDY received

24: GoodCRC
25: GoodCRC + CRC
Port Power Role -> Source 26: GoodCRC
Check and increment MessageIDCounter
Stop CRCReceiveTimer
Stop PSSourceOffTimer
CC -> Rp 27: PS_RDY sent
Set Power Supply to 5V output
Start PSSourceOnTimer

Power Supply reaches 5V

output

28: Send PS_RDY

29: PS_RDY
30: PS_RDY + CRC
Start CRCReceiveTimer 31: PS_RDY

Check MessageID against local copy

Store copy of MessageID

32: PS_RDY received

33: GoodCRC
34: GoodCRC + CRC
35: GoodCRC Stop PSSourceOnTimer
Check and increment MessageIDCounter Tell Power Supply to start
Stop CRCReceiveTimer sinking power
Reset Protocol Layer
36: PS_RDY sent

Reset CapsCounter
Reset Protocol Layer
Start SwapSourceStartTimer

New Power Roles

Page 326 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 8-15 Steps for a Successful Type-C Sink Initiated Power Role Swap Sequence

Step Type-C Port (initially Sink Port) Type-C Port (initially Source Port)
1 The [USBType-C 1.0] Port has Port Power Role set to The [USBType-C 1.0] Port has Port Power Role set to
Sink with the Rd pull down on its CC wire. Source and the Rp pull up on its CC wire.
Policy Engine directs the Protocol Layer to send a
PR_Swap Message.
2 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
3 Physical Layer appends CRC and sends the PR_Swap Physical Layer receives the PR_Swap Message and
Message. checks the CRC to verify the Message.
4 Physical Layer removes the CRC and forwards the
PR_Swap Message to the Protocol Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received PR_Swap
Message information to the Policy Engine that
consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
PR_Swap Message was successfully sent. Policy
Engine starts SenderResponseTimer.
10 Policy Engine evaluates the PR_Swap Message sent by
the Sink and decides that it is able and willing to do
the Power Role Swap. It tells the Protocol Layer to
form an Accept Message.
11 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
12 Physical Layer receives the Message and compares Physical Layer appends a CRC and sends the Accept
the CRC it calculated with the one sent to verify the Message.
Accept Message.
13 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received PR_Swap
Message information to the Policy Engine that
consumes it.
14 The Policy Engine stops the SenderResponseTimer,
starts the PSSourceOffTimer and tells the power
supply to stop sinking current.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 327
 Step Type-C Port (initially Sink Port) Type-C Port (initially Source Port)
18 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Accept Message was successfully sent. The Policy
Engine tells the power supply to stop supplying
power.
19 The Policy Engine determines its power supply is no
longer supplying VBUS. The Policy Engine requests the
Device Policy Manager to assert the Rd pull down on
the CC wire. The Policy Engine then directs the
Protocol Layer to generate a PS_RDY Message, with
the Port Power Role bit in the Message Header set to
“Sink”, to tell its Port Partner that it can begin to
Source VBUS.
20 Protocol Layer sets the Port Power Role bit in the
Message Header set to “Sink”, creates the Message
and passes to Physical Layer. Starts
CRCReceiveTimer.
21 Physical Layer receives the PS_RDY Message and Physical Layer appends CRC and sends the PS_RDY
checks the CRC to verify the Message. Message.
22 Physical Layer removes the CRC and forwards the
PS_RDY Message to the Protocol Layer.
23 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received PS_RDY
Message information to the Policy Engine that
consumes it. The Policy Engine stops the
PSSourceOffTimer, directs the Device Policy
Manager to apply the Rp pull up and then starts
switching the power supply to vSafe5V Source
operation.
24 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
25 Physical Layer appends CRC and sends the GoodCRC Physical Layer receives the GoodCRC Message and
Message. checks the CRC to verify the Message.
26 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
27 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
PS_RDY Message was successfully sent. Policy Engine
starts PSSourceOnTimer.
28 Policy Engine, when its power supply is ready to
supply power, tells the Protocol Layer to form a
PS_RDY Message. The Port Power Role bit used in
this and subsequent Message Headers is now set to
“Source”.
29 Protocol Layer creates the PS_RDY Message and
passes to Physical Layer. Starts CRCReceiveTimer.
30 Physical Layer appends a CRC and sends the PS_RDY Physical Layer receives the PS_RDY Message and
Message. compares the CRC it calculated with the one sent to
verify the Message.
31 Physical Layer removes the CRC and forwards the
PS_RDY Message to the Protocol Layer.

Page 328 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Type-C Port (initially Sink Port) Type-C Port (initially Source Port)
32 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received PS_RDY
Message information to the Policy Engine that
consumes it. The Policy Engine stops the
PSSourceOnTimer, informs the power supply that it
can start consuming power.
33 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
34 Physical Layer receives GoodCRC Message and Physical Layer appends a CRC and sends the GoodCRC
compares the CRC it calculated with the one sent to Message. The Policy Engine stops the
verify the Message. PSSourceOnTimer, informs the power supply it can
now Sink power and resets the Protocol Layer.
35 Physical Layer removes the CRC and forwards the
GoodCRC to the Protocol Layer.
36 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
PS_RDY Message was successfully sent. The Policy
Engine resets the CapsCounter, resets the Protocol
Layer and starts the SwapSourceStartTimer which
must timeout before sending any
Source_Capabilities Messages.
The Power Role Swap is complete, the roles have been reversed and the Port Partners are free to negotiate for
more power.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 329
 8.3.2.8.2 Type-C Data Role Swap

8.3.2.8.2.1 Type-C Data Role Swap, Initiated by UFP Operating as Sink

This is an example of Message sequence between a Port Pair both utilizing the Type-C connector.
Figure 8-17 shows an example sequence between a [USBType-C 1.0] DRP, which is initially a UFP (Device) and a Sink
(Rd asserted), and a [USBType-C 1.0] DRP which is initially a DFP (Host) and a Source (Rp asserted). A Data Role Swap
is initiated by the UFP. During the process the Port Partners maintain their operation as either a Source or a Sink
(power and Rp/Rd remain constant) but exchange data roles between DFP (Host) and UFP (Device).

Figure 8-17 Type-C Data Role Swap, UFP operating as Sink initiates

Type-C DRP (Initially UFP Sink Port) Type-C DRP (initially DFP Source Port)
: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

CC = Rd (Sink) CC = Rp (Source)
Port Data Role = UFP (Device) Port Data Role = DFP (Host)

1: Send Dr_Swap
2:Dr_Swap
3: Dr_Swap + CRC
Start CRCReceiveTimer 4: Dr_Swap

Check MessageID against local copy

Store copy of MessageID

5: Dr_Swap received
6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC Evaluate Dr_Swap request
CC = Rp (Source)
Check and increment MessageIDCounter Port Data Role = DFP (Host)
Stop CRCReceiveTimer

9:Dr_Swap sent

Start SenderResponseTimer
CC = Rd (Sink) 10: Send Accept
Port Data Role = UFP (Device) 11: Accept
12: Accept + CRC
13: Accept Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Accept received

15: GoodCRC
16: GoodCRC + CRC
Stop SenderResponseTimer
17: GoodCRC

Check and increment MessageIDCounter

Stop CRCReceiveTimer

18: Accept sent

CC = Rd (Sink) CC = Rp (Source)
Port Data Role -> DFP (Host) Port Data Role -> UFP (Device)

New Host/Device Roles

Table 8-10 below provides a detailed explanation of what happens at each labeled step in Figure 8-17 above.

Page 330 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 8-16 Steps for Type-C Data Role Swap, UFP operating as Sink initiates

Step Type-C DRP (initially UFP Sink Port) Type-C DRP (initially DFP Source Port)
1 Port starts as a UFP (Device) operating as a Sink with Port starts as a DFP (Host) operating as Source with Rp
Rd asserted and Port Data Role set to UFP. The asserted and Port Data Role set to DFP.
Policy Engine directs the Protocol Layer to send a
DR_Swap Message.
2 Protocol Layer creates the DR_Swap Message and
passes to Physical Layer. Starts CRCReceiveTimer.
3 Physical Layer appends CRC and sends the DR_Swap Physical Layer receives the DR_Swap Message and
Message. checks the CRC to verify the Message.
4 Physical Layer removes the CRC and forwards the
DR_Swap Message to the Protocol Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received DR_Swap
Message information to the Policy Engine that consumes
it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
DR_Swap Message was successfully sent. Policy
Engine starts SenderResponseTimer.
10 Policy Engine evaluates the DR_Swap Message and
decides that it is able and willing to do the Data Role
Swap. It tells the Protocol Layer to form an Accept
Message.
11 Protocol Layer creates the Accept Message and passes to
Physical Layer. Starts CRCReceiveTimer.
12 Physical Layer receives the Accept Message and Physical Layer appends a CRC and sends the Accept
checks the CRC to verify the Message. Message.
13 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received Accept
Message information to the Policy Engine that
consumes it.
14 The Policy Engine stops the SenderResponseTimer.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 331
 Step Type-C DRP (initially UFP Sink Port) Type-C DRP (initially DFP Source Port)
18 The Policy Engine requests that Data Role is changed Protocol Layer verifies and increments the
from UFP (Device) to DFP (Host). MessageIDCounter and stops CRCReceiveTimer.
The Power Delivery role is now a DFP (Host), with Protocol Layer informs the Policy Engine that the Accept
Port Data Role set to DFP, still operating as a Sink Message was successfully sent.
(Rd asserted). The Policy Engine requests that the Data Role is changed
to UFP (Device), with Port Data Role set to UFP and
continues supplying power as a Source (Rp asserted).
The Data Role Swap is complete, the data roles have been reversed while maintaining the direction of power
flow.

Page 332 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.2.8.2.2 Type-C Data Role Swap, Initiated by UFP Operating as Source
This is an example of Message sequence between a Port Pair both utilizing the Type-C connector.
Figure 8-18 shows an example sequence between a [USBType-C 1.0] DRP, which is initially a UFP (Device) and a
Source (Rp asserted), and a [USBType-C 1.0] DRP which is initially a DFP (Host) and a Sink (Rd asserted). A Data Role
Swap is initiated by the UFP. During the process the Port Partners maintain their operation as either a Source or a
Sink (power and Rp/Rd remain constant) but exchange data roles between DFP (Host) and UFP (Device).

Figure 8-18 Type-C Data Role Swap, UFP operating as Source initiates

Type-C DRP (Initially UFP Source Port) Type-C DRP (initially DFP Sink Port)
: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

CC = Rp (Source) CC = Rd (Sink)
Port Data Role = UFP (Device) Port Data Role = DFP (Host)

1: Send Dr_Swap
2:Dr_Swap
3: Dr_Swap + CRC
Start CRCReceiveTimer 4: Dr_Swap

Check MessageID against local copy

Store copy of MessageID

5: Dr_Swap received
6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC
Check and increment MessageIDCounter
Evaluate Dr_Swap request
Stop CRCReceiveTimer
CC = Rd (Sink)
9:Dr_Swap sent Port Data Role = DFP (Host)

Start SenderResponseTimer
CC = Rp (Source) 10: Send Accept
Port Data Role = UFP (Device) 11: Accept
12: Accept + CRC
13: Accept Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Accept received

15: GoodCRC
16: GoodCRC + CRC
Stop SenderResponseTimer 17: GoodCRC
Check and increment MessageIDCounter
Stop CRCReceiveTimer

18: Accept sent

CC = Rp (Source) CC = Rd (Sink)
Port Data Role -> DFP (Host) Port Data Role -> UFP (Device)

New Host/Device Roles

Table 8-17 below provides a detailed explanation of what happens at each labeled step in Figure 8-18 above.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 333
 Table 8-17 Steps for Type-C Data Role Swap, UFP operating as Source initiates

Step Type-C DRP (initially UFP Source Port) Type-C DRP (initially DFP Sink Port)
1 Port starts as a UFP (Device) operating as Source with Port starts as a DFP (Host) operating as a Sink with R d
Rp asserted and Port Data Role set to UFP. The Policy asserted and Port Data Role set to DFP.
Engine directs the Protocol Layer to send a DR_Swap
Message.
2 Protocol Layer creates the DR_Swap Message and
passes to Physical Layer. Starts CRCReceiveTimer.
3 Physical Layer appends CRC and sends the DR_Swap Physical Layer receives the DR_Swap Message and
Message. checks the CRC to verify the Message.
4 Physical Layer removes the CRC and forwards the
DR_Swap Message to the Protocol Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received DR_Swap
Message information to the Policy Engine that
consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
DR_Swap Message was successfully sent. Policy Engine
starts SenderResponseTimer.
10 Policy Engine evaluates the DR_Swap Message and
decides that it is able and willing to do the Data Role
Swap. It tells the Protocol Layer to form an Accept
Message.
11 Protocol Layer creates the Accept Message and passes
to Physical Layer. Starts CRCReceiveTimer.
12 Physical Layer receives the Accept Message and checks Physical Layer appends a CRC and sends the Accept
the CRC to verify the Message. Message.
13 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received Accept
Message information to the Policy Engine that
consumes it.
14 The Policy Engine stops the SenderResponseTimer.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer appends a CRC and sends the GoodCRC Physical Layer receives GoodCRC Message and
Message. compares the CRC it calculated with the one sent to
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.

Page 334 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Type-C DRP (initially UFP Source Port) Type-C DRP (initially DFP Sink Port)
18 The Policy Engine requests that Data Role is changed Protocol Layer verifies and increments the
from UFP (Device) to DFP (Host). MessageIDCounter and stops CRCReceiveTimer.
The Power Delivery role is now a DFP (Host), and Port Protocol Layer informs the Policy Engine that the
Data Role set to DFP, and continues supplying power as Accept Message was successfully sent. The Policy
a Source (Rp asserted). Engine requests that the Data Role is changed to UFP
(Device), with Port Data Role set to UFP and still
operating as a Sink (Rp asserted).
The Data Role Swap is complete, the data roles have been reversed while maintaining the direction of power flow.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 335
 8.3.2.8.2.3 Type-C Data Role Swap, Initiated by DFP Operating as Source
This is an example of Message sequence between a Port Pair both utilizing the Type-C connector.
Figure 8-19 shows an example sequence between a [USBType-C 1.0] DRP, which is initially a UFP (Device) and a Sink
(Rd asserted), and a [USBType-C 1.0] DRP which is initially a DFP and a Source (Rp asserted). A Data Role Swap is
initiated by the DFP. During the process the Port Partners maintain their operation as either a Source or a Sink
(power and Rp/Rd remain constant) but exchange data roles between DFP (Host) and UFP (Device).

Figure 8-19 Type-C Data Role Swap, DFP operating as Source initiates

Type-C DRP (Initially UFP Sink Port) Type-C DRP (initially DFP Source Port)
: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

CC = Rd (Sink) CC = Rp (Source)
Port Data Role = UFP (Device) Port Data Role = DFP (Host)

1: Send Dr_Swap
2: Dr_Swap
3: Dr_Swap + CRC
4: Dr_Swap Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

5: Dr_Swap received 6: GoodCRC

7: GoodCRC + CRC
8: GoodCRC
Evaluate Dr_Swap request
CC = Rd (Sink) Check and increment MessageIDCounter
Port Data Role =UFP (Device) Stop CRCReceiveTimer

9: Dr_Swap sent

Start SenderResponseTimer
10: Send Accept CC = Rp (Source)
11:Accept Port Data Role = DFP (Host)
12: Accept + CRC
Start CRCReceiveTimer 13: Accept

Check MessageID against local copy

Store copy of MessageID

14: Accept received

15: GoodCRC
16: GoodCRC + CRC
17: GoodCRC Stop SenderResponseTimer
Check and increment MessageIDCounter
Stop CRCReceiveTimer

18:Accept sent

CC = Rd (Sink) CC = Rp (Source)
Port Data Role -> DFP (Host) Port Data Role -> UFP (Device)

New Host/Device Roles

Table 8-18 below provides a detailed explanation of what happens at each labeled step in Figure 8-19 above.

Page 336 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 8-18 Steps for Type-C Data Role Swap, DFP operating as Source initiates

Step Type-C DRP (initially UFP Sink Port) Type-C DRP (initially DFP Source Port)
1 Port starts as a UFP (Device) operating as a Sink with Port starts as a DFP (Host) operating as Source with
Rd asserted and Port Data Role set to UFP. Rp asserted and Port Data Role set to DFP. The Policy
Engine directs the Protocol Layer to send a DR_Swap
Message.
2 Protocol Layer creates the DR_Swap Message and
passes to Physical Layer. Starts CRCReceiveTimer.
3 Physical Layer receives the DR_Swap Message and Physical Layer appends CRC and sends the DR_Swap
checks the CRC to verify the Message. Message.
4 Physical Layer removes the CRC and forwards the
DR_Swap Message to the Protocol Layer.
5 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received DR_Swap
Message information to the Policy Engine that
consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer appends CRC and sends the GoodCRC Physical Layer receives the GoodCRC Message and
Message. checks the CRC to verify the Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
DR_Swap Message was successfully sent. Policy
Engine starts SenderResponseTimer.
10 Policy Engine evaluates the DR_Swap Message and
decides that it is able and willing to do the Data Role
Swap. It tells the Protocol Layer to form an Accept
Message.
11 Protocol Layer creates the Accept Message and
passes to Physical Layer. Starts CRCReceiveTimer.
12 Physical Layer appends a CRC and sends the Accept Physical Layer receives the Accept Message and
Message. checks the CRC to verify the Message.
13 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received Accept
Message information to the Policy Engine that
consumes it.
14 The Policy Engine stops the SenderResponseTimer.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer receives GoodCRC Message and Physical Layer appends a CRC and sends the GoodCRC
compares the CRC it calculated with the one sent to Message.
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 337
 Step Type-C DRP (initially UFP Sink Port) Type-C DRP (initially DFP Source Port)
18 Protocol Layer verifies and increments the The Policy Engine requests that Data Role is changed
MessageIDCounter and stops CRCReceiveTimer. from DFP (Host) to UFP (Device).
Protocol Layer informs the Policy Engine that the The Power Delivery role is now a UFP (Device), with
Accept Message was successfully sent. . The Policy Port Data Role set to UFP, and continues supplying
Engine requests that the Data Role is changed to DFP power as a Source (Rp asserted).
(Host), with Port Data Role set to DFP, still
operating as a Sink (Rd asserted).
The Data Role Swap is complete, the data roles have been reversed while maintaining the direction of power
flow.

Page 338 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.2.8.2.4 Type-C Data Role Swap, Initiated by DFP Operating as Sink
This is an example of Message sequence between a Port Pair both utilizing the Type-C connector.
Figure 8-20 shows an example sequence between a [USBType-C 1.0] DRP, which is initially a UFP (Device) and a
Source (Rp asserted), and a [USBType-C 1.0] DRP which is initially a DFP (Host) and a Sink (Rd asserted). A Data Role
Swap is initiated by the DFP. During the process the Port Partners maintain their operation as either a Source or a
Sink (power and Rp/Rd remain constant) but exchange data roles between DFP (Host) and UFP (Device).

Figure 8-20 Type-C Data Role Swap, DFP operating as Sink initiates

Type-C DRP (Initially UFP Source Port) Type-C DRP (initially DFP Sink Port)
: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

CC = Rp (Source) CC = Rd (Sink)
Port Data Role = UFP (Device) Port Data Role = DFP (Host)

1: Send Dr_Swap
2: Dr_Swap
3: Dr_Swap + CRC
4: Dr_Swap Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

5: Dr_Swap received 6: GoodCRC

7: GoodCRC + CRC
8: GoodCRC
Evaluate Dr_Swap request
CC = Rp (Source) Check and increment MessageIDCounter
Port Data Role = UFP (Device) Stop CRCReceiveTimer

9: Dr_Swap sent

Start SenderResponseTimer
10: Send Accept CC = Rd (Sink)
11:Accept Port Data Role = DFP (Host)
12: Accept + CRC
Start CRCReceiveTimer 13: Accept

Check MessageID against local copy

Store copy of MessageID

14: Accept received

15: GoodCRC
16: GoodCRC + CRC
17: GoodCRC Stop SenderResponseTimer
Check and increment MessageIDCounter
Stop CRCReceiveTimer

18:Accept sent

CC = Rp (Source) CC = Rd (Sink)
Port Data Role -> DFP (Host) Port Data Role -> UFP (Device)

New Host/Device Roles

Table 8-19 below provides a detailed explanation of what happens at each labeled step in Figure 8-20 above.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 339
 Table 8-19 Steps for Type-C Data Role Swap, DFP operating as Sink initiates

Step Type-C DRP (initially UFP Source Port) Type-C DRP (initially DFP Sink Port)
1 Port starts as a UFP (Device) operating as Source with Port starts as a DFP (Host) operating as a Sink with R d
Rp asserted and Port Data Role set to UFP. asserted and Port Data Role set to DFP. The Policy
Engine directs the Protocol Layer to send a DR_Swap
Message.
2 Protocol Layer creates the DR_Swap Message and
passes to Physical Layer. Starts CRCReceiveTimer.
3 Physical Layer receives the DR_Swap Message and Physical Layer appends CRC and sends the DR_Swap
checks the CRC to verify the Message. Message.
4 Physical Layer removes the CRC and forwards the
DR_Swap Message to the Protocol Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received DR_Swap
Message information to the Policy Engine that
consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer appends CRC and sends the GoodCRC Physical Layer receives the GoodCRC Message and
Message. checks the CRC to verify the Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
DR_Swap Message was successfully sent. Policy
Engine starts SenderResponseTimer.
10 Policy Engine evaluates the DR_Swap Message and
decides that it is able and willing to do the Data Role
Swap. It tells the Protocol Layer to form an Accept
Message.
11 Protocol Layer creates the Accept Message and passes
to Physical Layer. Starts CRCReceiveTimer.
12 Physical Layer appends a CRC and sends the Accept Physical Layer receives the Accept Message and
Message. checks the CRC to verify the Message.
13 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received Accept
Message information to the Policy Engine that
consumes it.
14 The Policy Engine stops the SenderResponseTimer.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer receives GoodCRC Message and Physical Layer appends a CRC and sends the GoodCRC
compares the CRC it calculated with the one sent to Message.
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.

Page 340 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Type-C DRP (initially UFP Source Port) Type-C DRP (initially DFP Sink Port)
18 Protocol Layer verifies and increments the The Policy Engine requests that Data Role is changed
MessageIDCounter and stops CRCReceiveTimer. from DFP (Host) to UFP (Device).
Protocol Layer informs the Policy Engine that the The Power Delivery role is now a UFP (Device), with
Accept Message was successfully sent. The Policy Port Data Role set to UFP, still operating as a Sink (Rd
Engine requests that the Data Role is changed to DFP asserted).
(Host), with Port Data Role set to DFP, and continues
supplying power as a Source (Rp asserted).
The Data Role Swap is complete, the data roles have been reversed while maintaining the direction of power flow.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 341
 8.3.2.8.3 Type-C VCONN

8.3.2.8.3.1 Type-C DFP to UFP VCONN Source Swap

This is an example of Message sequence between a Port Pair both utilizing the Type-C connector.
Figure 8-21 shows an example sequence between a Type-C DFP and UFP, where the DFP is initially supplying VCONN
and then tells the UFP to supply VCONN. During the process the Port Partners, keep their role as DFP or UFP, maintain
their operation as either a Source or a Sink (power remains constant) but exchange the VCONN Source from the DFP to
the UFP.

Figure 8-21 Type-C DFP to UFP VCONN Source Swap

DFP (Initially VCONN Source Port) UFP (initially VCONN off)

: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

VCONN Source VCONN off

1: Send VCONN_Swap
2:VCONN_Swap
3: VCONN_Swap + CRC
Start CRCReceiveTimer 4: VCONN_Swap

Check MessageID against local copy

Store copy of MessageID

5: VCONN_Swap received
6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC
Check and increment MessageIDCounter
Stop CRCReceiveTimer

9:VCONN_Swap sent Evaluate VCONN_Swap

Start SenderResponseTimer request

10: Send Accept

11: Accept
12: Accept + CRC
13: Accept Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Accept received

15: GoodCRC
16: GoodCRC + CRC
Stop SenderResponseTimer 17: GoodCRC
Start VCONNOnTimer Check and increment MessageIDCounter
Stop CRCReceiveTimer

18: Accept sent

Tell power supply to

start supplying VCONN

Vconn is on

19: Send PS_RDY

20: PS_RDY
21: PS_RDY + CRC
22: PS_RDY
Start CRCReceiveTimer
Check MessageID against local copy
Store copy of MessageID

23: PS_RDY received

24: GoodCRC
25: GoodCRC + CRC
Stop VCONNOnTimer 26: GoodCRC
Tell power supply to turn off VCONN
Check and increment MessageIDCounter
Stop CRCReceiveTimer

27: PS_RDY sent

VCONN is off

UFP is supplying VCONN

Table 8-20 below provides a detailed explanation of what happens at each labeled step in Figure 8-21 above.
Page 342 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 8-20 Steps for Type-C DFP to UFP VCONN Source Swap

Step DFP (initially VCONN Source) UFP (Initially VCONN off)

1 The DFP starts as the VCONN Source. The Policy The UFP starts with VCONN off.
Engine directs the Protocol Layer to send a
VCONN_Swap Message.
2 Protocol Layer creates the VCONN_Swap Message
and passes to Physical Layer. Starts
CRCReceiveTimer.
3 Physical Layer appends CRC and sends the Physical Layer receives the VCONN_Swap Message
VCONN_Swap Message. and checks the CRC to verify the Message.
4 Physical Layer removes the CRC and forwards the
VCONN_Swap Message to the Protocol Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received
VCONN_Swap Message information to the Policy
Engine that consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
VCONN_Swap Message was successfully sent.
Policy Engine starts SenderResponseTimer.
10 Policy Engine evaluates the VCONN_Swap Message
sent by the DFP and decides that it is able and willing
to do the VCONN Swap. It tells the Protocol Layer to
form an Accept Message.
11 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
12 Physical Layer receives the Accept Message and Physical Layer appends a CRC and sends the Accept
compares the CRC it calculated with the one sent to Message.
verify the Message.
13 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received Accept
Message information to the Policy Engine that
consumes it.
14 The Policy Engine stops the SenderResponseTimer
and starts the VCONNOnTimer.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 343
 Step DFP (initially VCONN Source) UFP (Initially VCONN off)
18 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Accept Message was successfully sent. The Policy
Engine asks the Device Policy Manager to turn on
VCONN.
19 The Device Policy Manager informs the Policy Engine
that its power supply is supplying VCONN. The Policy
Engine directs the Protocol Layer to generate a
PS_RDY Message to tell the DFP it can turn off VCONN.
20 Protocol Layer creates the PS_RDY Message and
passes to Physical Layer. Starts CRCReceiveTimer.
21 Physical Layer receives the PS_RDY Message and Physical Layer appends a CRC and sends the PS_RDY
compares the CRC it calculated with the one sent to Message.
verify the Message.
22 Physical Layer removes the CRC and forwards the
PS_RDY Message to the Protocol Layer.
23 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received PS_RDY
Message information to the Policy Engine that
consumes it.
24 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
25 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message.. The Policy Engine stops the compares the CRC it calculated with the one sent to
VCONNOnTimer, and tells the power supply to stop verify the Message.
sourcing VCONN.
26 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
27 VCONN is off. Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
PS_RDY Message was successfully sent.
The UFP is now the VCONN Source and the DFP has VCONN turned off.

Page 344 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.2.8.3.2 Type-C UFP to DFP VCONN Source Swap
This is an example of Message sequence between a Port Pair both utilizing the Type-C connector.
Figure 8-22 shows an example sequence between a Type-C DFP and UFP, where the UFP is initially supplying VCONN
and then the DFP tells the UFP that it will become the VCONN Source. During the process the Port Partners, keep their
role as DFP or UFP, maintain their operation as either a Source or a Sink (power remains constant) but exchange the
VCONN Source from the UFP to the DFP.

Figure 8-22 Type-C UFP to DFP VCONN Source Swap

DFP (Initially VCONN off) UFP (initially VCONN Source Port)

: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

VCONN Off VCONN Source

1: Send VCONN_Swap
2:VCONN_Swap
3: VCONN_Swap + CRC
Start CRCReceiveTimer 4: VCONN_Swap

Check MessageID against local copy

Store copy of MessageID

5: VCONN_Swap received
6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC
Check and increment MessageIDCounter
Stop CRCReceiveTimer

9:VCONN_Swap sent Evaluate VCONN_Swap

Start SenderResponseTimer request

10: Send Accept

11: Accept
12: Accept + CRC
13: Accept Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Accept received

15: GoodCRC
16: GoodCRC + CRC
Stop SenderResponseTimer 17: GoodCRC
Tell power supply to start Check and increment MessageIDCounter
supplying VCONN Stop CRCReceiveTimer

18: Accept sent

Start VCONNOnTimer

Vconn is on

19: Send PS_RDY

20: PS_RDY
21: PS_RDY + CRC
Start CRCReceiveTimer 22: PS_RDY

Check MessageID against local copy

Store copy of MessageID

23: PS_RDY received

24: GoodCRC
25: GoodCRC + CRC
26: GoodCRC Stop VCONNOnTimer
Tell power supply to turn off VCONN
Check and increment MessageIDCounter
Stop CRCReceiveTimer

27: PS_RDY sent

VCONN is off

DFP is supplying VCONN

Table 8-21 below provides a detailed explanation of what happens at each labeled step in Figure 8-22 above.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 345
 Table 8-21 Steps for Type-C UFP to DFP VCONN Source Swap

Step DFP UFP

1 The DFP starts with VCONN off. The Policy Engine The UFP starts as the VCONN Source.
directs the Protocol Layer to send a VCONN_Swap
Message.
2 Protocol Layer creates the VCONN_Swap Message
and passes to Physical Layer. Starts
CRCReceiveTimer.
3 Physical Layer appends CRC and sends the Physical Layer receives the VCONN_Swap Message
VCONN_Swap Message. and checks the CRC to verify the Message.
4 Physical Layer removes the CRC and forwards the
VCONN_Swap Message to the Protocol Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received
VCONN_Swap Message information to the Policy
Engine that consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
VCONN_Swap Message was successfully sent.
Policy Engine starts SenderResponseTimer.
10 Policy Engine evaluates the VCONN_Swap Message
sent by the DFP and decides that it is able and willing
to do the VCONN Swap. It tells the Protocol Layer to
form an Accept Message.
11 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
12 Physical Layer receives the Accept Message and Physical Layer appends a CRC and sends the Accept
compares the CRC it calculated with the one sent to Message.
verify the Message.
13 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received Accept
Message information to the Policy Engine that
consumes it.
14 The Policy Engine stops the SenderResponseTimer.
The Policy Engine tells the Device Policy Manger to
turn on VCONN.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.

Page 346 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step DFP UFP
18 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Accept Message was successfully sent.
The Policy Engine starts the VCONNOnTimer.
19 The Device Policy Manager tells the Policy Engine
that its power supply is supplying VCONN. The Policy
Engine directs the Protocol Layer to generate a
PS_RDY Message to tell the UFP it can turn off VCONN.
20 Protocol Layer creates the PS_RDY Message and
passes to Physical Layer. Starts CRCReceiveTimer.
21 Physical Layer appends a CRC and sends the PS_RDY Physical Layer receives the PS_RDY Message and
Message. compares the CRC it calculated with the one sent to
verify the Message.
22 Physical Layer removes the CRC and forwards the
PS_RDY Message to the Protocol Layer.
23 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received PS_RDY
Message information to the Policy Engine that
consumes it.
24 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
25 Physical Layer receives GoodCRC Message and Physical Layer appends a CRC and sends the GoodCRC
compares the CRC it calculated with the one sent to Message.. The Policy Engine stops the
verify the Message. VCONNOnTimer, and tells the power supply to stop
sourcing VCONN.
26 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
27 Protocol Layer verifies and increments the VCONN is off.
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
PS_RDY Message was successfully sent.
The DFP is now the VCONN Source and the UFP has VCONN turned off.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 347
 8.3.2.9 Structured VDM

8.3.2.9.1 DFP to UFP Discover Identity

This is an example of Message sequence between a Port Pair both utilizing the Type-C connector.
Figure 8-23 shows an example sequence between a Type-C DFP and UFP, where both Port Partners are in an Explicit
Contract and the DFP attempts to discover identity information from the UFP.

Figure 8-23 DFP to UFP Discover Identity

DFP UFP

: DFP Policy Engine : Protocol : PHY : PHY : Protocol : UFP Policy Engine

Explicit PD Contract Explicit PD Contract

1: Send Discover Identity

2: Discover Identity
3: Discover Identity + CRC
Start CRCReceiveTimer 4: Discover Identity
Check MessageID against local copy
Store copy of MessageID

5: Discover Identity received

6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC

Check and increment MessageIDCounter

Stop CRCReceiveTimer

9: Discover Identity sent

Start VDMResponseTimer Request Identity information from

Device Policy Manager

10: Send Discover Identity ACK

11: Discover Identity ACK
12: Discover Identity ACK + CRC
13: Discover Identity ACK Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Discover Identity ACK received

15: GoodCRC
16: GoodCRC + CRC
17: GoodCRC
Stop VDMResponseTimer Check and increment MessageIDCounter
DPM evaluates UFP Identity Stop CRCReceiveTimer
information
18: Discover Identity ACK sent

Table 8-22 below provides a detailed explanation of what happens at each labeled step in Figure 8-23 above.

Table 8-22 Steps for DFP to UFP Discover Identity

Step DFP UFP

1 The DFP has an Explicit Contract. The Policy Engine The UFP has an Explicit Contract.
directs the Protocol Layer to send a Discover
Identity Command request.
2 Protocol Layer creates the Discover Identity
Command request and passes to Physical Layer.
Starts CRCReceiveTimer.

Page 348 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step DFP UFP
3 Physical Layer appends CRC and sends the Discover Physical Layer receives the Discover Identity
Identity Command request. Command request and checks the CRC to verify the
Message.
4 Physical Layer removes the CRC and forwards the
Discover Identity Command request to the Protocol
Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received Discover
Identity Command request information to the Policy
Engine that consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Discover Identity Command request was
successfully sent.
Policy Engine starts the VDMResponseTimer.
10 Policy Engine requests the identity information from
the Device Policy Manager. The Policy Engine tells
the Protocol Layer to form a Discover Identity
Command ACK response.
11 Protocol Layer creates the Discover Identity
Command ACK response and passes to Physical Layer.
Starts CRCReceiveTimer.
12 Physical Layer receives the Discover Identity Physical Layer appends a CRC and sends the Discover
Command ACK response and compares the CRC it Identity Command ACK response.
calculated with the one sent to verify the Message.
13 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received Discover
Identity Command ACK response information to the
Policy Engine that consumes it.
14 The Policy Engine stops the VDMResponseTimer and
passed the Indentity information to the Device Policy
Manager for evaluation.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
18 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Discover Identity Command ACK response was
successfully sent.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 349
 8.3.2.9.2 Source Port to Cable Plug Discover Identity
This is an example of Message sequence between a Source and a Cable Plug both utilizing the Type-C connector.
Figure 8-24 shows an example sequence between a Type-C Source and a Cable Plug, where the Source attempts to
discover identity information from the Cable Plug prior to establishing an Explicit Contract with its Port Partner.

Figure 8-24 Source Port to Cable Plug Discover Identity

Source Port Cable Plug

: Source Policy Engine : Protocol : PHY : PHY : Protocol : Cable Plug Policy Engine

No or Implicit Contract

1: Send Discover Identity

2: Discover Identity
3: Discover Identity + CRC
Start CRCReceiveTimer 4: Discover Identity
Check MessageID against local copy
Store copy of MessageID

5: Discover Identity received

6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC

Check and increment MessageIDCounter

Stop CRCReceiveTimer

9: Discover Identity sent

Evaluate Discover Identity request
Start VDMResponseTimer Enter USB Operation
Wait tCableMessage before transmission

10: Send Discover Identity ACK

11: Discover Identity ACK
12: Discover Identity ACK + CRC
13: Discover Identity ACK Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Discover Identity ACK received

15: GoodCRC
16: GoodCRC + CRC
17: GoodCRC
Stop VDMResponseTimer Check and increment MessageIDCounter
Use Cable information to specify Stop CRCReceiveTimer
Capabilities
18: Discover Identity ACK sent

Table 8-23 below provides a detailed explanation of what happens at each labeled step in Figure 8-24 above.

Table 8-23 Steps for Source Port to Cable Plug Discover Identity

Step Source Port Cable Plug

1 The Source has no Contract or an Implicit Contract
with its Port Partner. The Policy Engine directs the
Protocol Layer to send a Discover Identity Command
request.
2 Protocol Layer creates the Discover Identity
Command request and passes to Physical Layer.
Starts CRCReceiveTimer.
3 Physical Layer appends CRC and sends the Discover Physical Layer receives the Discover Identity
Identity Command request. Command request and checks the CRC to verify the
Message.

Page 350 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Source Port Cable Plug
4 Physical Layer removes the CRC and forwards the
Discover Identity Command request to the Protocol
Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received Discover
Identity Command request information to the Policy
Engine that consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Discover Identity Command request was
successfully sent.
Policy Engine starts the VDMResponseTimer.
10 Policy Engine requests the identity information from
the Device Policy Manager. . tCableMessage after the
GoodCRC Message was sent the Policy Engine tells
the Protocol Layer to form a Discover Identity
Command ACK response.
11 Protocol Layer creates the Discover Identity
Command ACK response and passes to Physical Layer.
Starts CRCReceiveTimer.
12 Physical Layer receives the Discover Identity Physical Layer appends a CRC and sends the Discover
Command ACK response and compares the CRC it Identity Command ACK response.
calculated with the one sent to verify the Message.
13 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received Discover
Identity Command ACK response information to the
Policy Engine that consumes it.
14 The Policy Engine stops the VDMResponseTimer and
passes the identity information to the Device Policy
Manager for evaluation.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
18 The Source uses the Cable Plug information as input Protocol Layer verifies and increments the
to its offered capabilities. MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Accept Message was successfully sent.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 351
 8.3.2.9.3 DFP to Cable Plug Discover Identity
This is an example of Message sequence between a DFP and a Cable Plug both utilizing the Type-C connector.
Figure 8-25 shows an example sequence between a Type-C DFP and a Cable Plug, where the DFP attempts to discover
identity information from the Cable Plug.

Figure 8-25 DFP to Cable Plug Discover Identity

DFP Cable Plug

: DFP Policy Engine : Protocol : PHY : PHY : Protocol : Cable Plug Policy Engine

Explicit PD Contract

1: Send Discover Identity

2: Discover Identity
3: Discover Identity + CRC
Start CRCReceiveTimer 4: Discover Identity
Check MessageID against local copy
Store copy of MessageID

5: Discover Identity received

6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC

Check and increment MessageIDCounter

Stop CRCReceiveTimer

9: Discover Identity sent

Evaluate Discover Identity request
Start VDMResponseTimer Enter USB Operation
Wait tCableMessage before transmission

10: Send Discover Identity ACK

11: Discover Identity ACK
12: Discover Identity ACK + CRC
13: Discover Identity ACK Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Discover Identity ACK received

15: GoodCRC
16: GoodCRC + CRC
17: GoodCRC
Stop VDMResponseTimer Check and increment MessageIDCounter
Use Cable information to specify Stop CRCReceiveTimer
Capabilities
18: Discover Identity ACK sent

Table 8-24 below provides a detailed explanation of what happens at each labeled step in Figure 8-25 above.

Table 8-24 Steps for DFP to Cable Plug Discover Identity

Step DFP Cable Plug

1 The DFP has an Explicit Contract with its Port
Partner. The Policy Engine directs the Protocol Layer
to send a Discover Identity Command request.
2 Protocol Layer creates the Discover Identity
Command request and passes to Physical Layer.
Starts CRCReceiveTimer.
3 Physical Layer appends CRC and sends the Discover Physical Layer receives the Discover Identity
Identity Command request. Command request and checks the CRC to verify the
Message.

Page 352 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step DFP Cable Plug
4 Physical Layer removes the CRC and forwards the
Discover Identity Command request to the Protocol
Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received Discover
Identity Command request information to the Policy
Engine that consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Discover Identity Command request was
successfully sent.
Policy Engine starts the VDMResponseTimer.
10 Policy Engine requests the identity information from
the Device Policy Manager. tCableMessage after the
GoodCRC Message was sent the Policy Engine tells
the Protocol Layer to form a Discover Identity
Command ACK response.
11 Protocol Layer creates the Discover Identity
Command ACK response and passes to Physical Layer.
Starts CRCReceiveTimer.
12 Physical Layer receives the Discover Identity Physical Layer appends a CRC and sends the Discover
Command ACK response and compares the CRC it Identity Command ACK response.
calculated with the one sent to verify the Message.
13 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received Discover
Identity Command ACK response information to the
Policy Engine that consumes it.
14 The Policy Engine stops the Discover Identity
Command ACK response and passes the identity
information to the Device Policy Manager for
evaluation.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
18 The DFP when acting as a Source uses the Cable Plug Protocol Layer verifies and increments the
information as input to its offered capabilities. MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Accept Message was successfully sent.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 353
 8.3.2.9.4 DFP to UFP Enter Mode
This is an example of Message sequence between a DFP and a UFP both utilizing the Type-C connector.
Figure 8-26 shows an example sequence between a Type-C DFP and a UFP, where the DFP attempts to discover
supported SVIDs, then Modes before selecting and entering a Mode.

Page 354 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 8-26 DFP to UFP Enter Mode
DFP UFP

: DFP Policy Engine : Protocol : PHY : PHY : Protocol : UFP Policy Engine

USB Operation USB Operation

1: Send Discover SVIDs

2: Discover SVIDs
3: Discover SVIDs + CRC
Start CRCReceiveTimer 4: Discover SVIDs

Check MessageID against local copy

Store copy of MessageID

5: Discover SVIDs received

6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC

Check and increment MessageIDCounter

Stop CRCReceiveTimer
Evaluate Discover SVIDs request
9: Discover SVIDs sent

Start VDMResponseTimer

10: Send Discover SVIDs ACK

11: Discover SVIDs ACK
12: Discover SVIDs ACK + CRC
13: Discover SVIDs ACK Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Discover SVIDs ACK received

15: GoodCRC
Stop VDMResponseTimer 16: GoodCRC + CRC
17: GoodCRC
Check and increment MessageIDCounter
Stop CRCReceiveTimer

18: Discover SVIDs ACK sent

Evaluate Discover SVIDs ACK

19: Send Discover Modes

20: Discover Modes
21: Discover Modes + CRC
Start CRCReceiveTimer 22: Discover Modes
Check MessageID against local copy
Store copy of MessageID

23: Discover Modes received

24: GoodCRC
25: GoodCRC + CRC
26: GoodCRC

Check and increment MessageIDCounter

Evaluate Discover Modes request
Stop CRCReceiveTimer

27: Discover Modes sent

Start VDMResponseTimer

28: Send Discover Modes ACK

29: Discover Modes ACK
30: Discover Modes ACK + CRC
31: Discover Modes ACK Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

32: Discover Modes ACK received

33: GoodCRC
Stop VDMResponseTimer 34: GoodCRC + CRC
35: GoodCRC
Check and increment MessageIDCounter
Stop CRCReceiveTimer

36: Discover Modes ACK sent

Evaluate Discover Modes ACK
Enter USB Safe State

37: Send Enter Mode

38: Enter Mode
39: Enter Mode + CRC
Start CRCReceiveTimer 40: Enter Mode
Check MessageID against local copy
Store copy of MessageID

41: Enter Mode received

42: GoodCRC
43: GoodCRC + CRC
44: GoodCRC

Check and increment MessageIDCounter

Stop CRCReceiveTimer

45: Enter Mode sent

Start VDMModeEntryTimer Evaluate Enter Mode request

Enter New Mode

46: Send Enter Mode ACK

47: Enter Mode ACK
48: Enter Mode ACK + CRC
49: Enter Mode ACK Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

50: Enter Mode ACK received

51: GoodCRC
52: GoodCRC + CRC
53: GoodCRC
Stop VDMModeEntryTimer
Enter New Mode Check and increment MessageIDCounter
Stop CRCReceiveTimer

54: Enter Mode ACK sent

New Mode Entered

Table 8-25 below provides a detailed explanation of what happens at each labeled step in Figure 8-26 above.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 355
 Table 8-25 Steps for DFP to UFP Enter Mode

Step DFP UFP

1 The DFP has an Explicit Contract. The Device Policy The UFP has an Explicit Contract.
Manager requests the Policy Engine to discover SVID
information.
The Policy Engine directs the Protocol Layer to send
a Discover SVIDs Command request.
2 Protocol Layer creates the Discover SVIDs Command
request and passes to Physical Layer. Starts
CRCReceiveTimer.
3 Physical Layer appends CRC and sends the Discover Physical Layer receives the Discover SVIDs Command
SVIDs Command request. request and checks the CRC to verify the Message.
4 Physical Layer removes the CRC and forwards the
Discover SVIDs Command request to the Protocol
Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received Discover
SVIDs Command request information to the Policy
Engine that consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Discover SVIDs Command request was successfully
sent.
Policy Engine starts the VDMResponseTimer.
10 Policy Engine requests the SVID information from the
Device Policy Manager. The Policy Engine tells the
Protocol Layer to form a Discover SVIDs Command
ACK response.
11 Protocol Layer creates the Discover SVIDs Command
ACK response and passes to Physical Layer. Starts
CRCReceiveTimer.
12 Physical Layer receives the Discover SVIDs Physical Layer appends a CRC and sends the Discover
Command ACK response and compares the CRC it SVIDs Command ACK response.
calculated with the one sent to verify the Message.
13 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received Discover
SVIDs Command ACK response information to the
Policy Engine that consumes it.
14 The Policy Engine stops the VDMResponseTimer and
passes the SVIDs information to the Device Policy
Manager for evaluation.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.

Page 356 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step DFP UFP
16 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
18 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Discover SVIDs Command ACK response was
successfully sent.
19 The Device Policy Manager requests the Policy
Engine to discover Mode information for a given
SVID.
The Policy Engine directs the Protocol Layer to send
a Discover Modes Command request.
20 Protocol Layer creates the Discover Modes
Command request and passes to Physical Layer.
Starts CRCReceiveTimer.
21 Physical Layer appends CRC and sends the Discover Physical Layer receives the Discover Modes
Modes Command request. Command request and checks the CRC to verify the
Message.
22 Physical Layer removes the CRC and forwards the
Discover Modes Command request to the Protocol
Layer.
23 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received Discover
Modes Command request information to the Policy
Engine that consumes it.
24 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
25 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
26 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
27 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Discover Modes Command request was successfully
sent.
Policy Engine starts the VDMResponseTimer.
28 Policy Engine requests the Mode information from
the Device Policy Manager. The Policy Engine tells
the Protocol Layer to form a Discover Modes
Command ACK response.
29 Protocol Layer creates the Discover Modes Command
ACK response and passes to Physical Layer. Starts
CRCReceiveTimer.
30 Physical Layer receives the Discover Modes Physical Layer appends a CRC and sends the Discover
Command ACK response and compares the CRC it Modes Command ACK response.
calculated with the one sent to verify the Message.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 357
 Step DFP UFP
31 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received Discover
Modes Command ACK response information to the
Policy Engine that consumes it.
32 The Policy Engine stops the VDMResponseTimer and
passes the Modes information to the Device Policy
Manager for evaluation.
33 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
34 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
35 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
36 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Discover Modes Command ACK response was
successfully sent.
37 The DFP goes to USB Safe State. The Device Policy
Manager requests the Policy Engine to enter a Mode.
The Policy Engine directs the Protocol Layer to send
an Enter Mode Command request.
38 Protocol Layer creates the Enter Mode Command
request and passes to Physical Layer. Starts
CRCReceiveTimer.
39 Physical Layer appends CRC and sends the Enter Physical Layer receives the Enter Mode Command
Mode Command request. request and checks the CRC to verify the Message.
40 Physical Layer removes the CRC and forwards the
Enter Mode Command request to the Protocol Layer.
41 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received Enter Mode
Command request information to the Policy Engine
that consumes it.
42 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
43 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
44 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
45 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Enter Mode Command request was successfully sent.
Policy Engine starts the VDMModeEntryTimer.
46 Policy Engine requests the Device Policy Manager to
enter the new Mode. The Policy Engine tells the
Protocol Layer to form an Enter Mode Command ACK
response.

Page 358 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step DFP UFP
47 Protocol Layer creates the Enter Mode Command
ACK response and passes to Physical Layer. Starts
CRCReceiveTimer.
48 Physical Layer receives the Enter Mode Command Physical Layer appends a CRC and sends the Enter
ACK response and compares the CRC it calculated Mode Command ACK response.
with the one sent to verify the Message.
49 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received Enter
Mode Command ACK response information to the
Policy Engine that consumes it.
50 The Policy Engine stops the VDMModeEntryTimer
and requests the Device Policy Manager to enter the
new Mode.
51 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
52 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
53 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
54 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Enter Mode Command ACK response was successfully
sent.
DFP and UFP are operating in the new Mode

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 359
 8.3.2.9.5 DFP to UFP Exit Mode
This is an example of Message sequence between a DFP and a UFP both utilizing the Type-C connector.
Figure 8-27 shows an example sequence between a Type-C DFP and a UFP, where the DFP commands the UFP to exit
the only Active Mode.

Figure 8-27 DFP to UFP Exit Mode

DFP UFP

: DFP Policy Engine : Protocol : PHY : PHY : Protocol : UFP Policy Engine

In Mode In Mode
Enter USB Safe State

1: Send Exit Mode

2: Exit Mode
3: Exit Mode + CRC
Start CRCReceiveTimer 4: Exit Mode
Check MessageID against local copy
Store copy of MessageID

5: Exit Mode received

6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC

Check and increment MessageIDCounter

Stop CRCReceiveTimer

9: Exit Mode sent

Start VDMModeExitTimer Evaluate Exit Mode request

Enter USB Operation

10: Send Exit Mode ACK

11: Exit Mode ACK
12: Exit Mode ACK + CRC
13: Exit Mode ACK Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Exit Mode ACK received

15: GoodCRC
16: GoodCRC + CRC
17: GoodCRC
Stop VDMModeExitTimer
Enter USB Operation Check and increment MessageIDCounter
Stop CRCReceiveTimer

18: Exit Mode ACK sent

USB operation

Table 8-26 below provides a detailed explanation of what happens at each labeled step in Figure 8-27 above.

Table 8-26 Steps for DFP to UFP Exit Mode

Step DFP UFP

1 The DFP is in a Mode and then enters USB Safe State. The UFP is in a Mode.
The Policy Engine directs the Protocol Layer to send
a Exit Mode Command request.
2 Protocol Layer creates the Exit Mode Command
request and passes to Physical Layer. Starts
CRCReceiveTimer.
3 Physical Layer appends CRC and sends the Exit Mode Physical Layer receives the Exit Mode Command
Command request. request and checks the CRC to verify the Message.

Page 360 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step DFP UFP
4 Physical Layer removes the CRC and forwards the
Exit Mode Command request to the Protocol Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received Exit Mode
Command request information to the Policy Engine
that consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Exit Mode Command request was successfully sent.
Policy Engine starts the VDMModeExitTimer.
10 Policy Engine requests the Device Policy Manager to
enter USB operation. The Policy Engine tells the
Protocol Layer to form an Exit Mode Command ACK
response.
11 Protocol Layer creates the Exit Mode Command ACK
response and passes to Physical Layer. Starts
CRCReceiveTimer.
12 Physical Layer receives the Exit Mode Command ACK Physical Layer appends a CRC and sends the Exit
response and compares the CRC it calculated with Mode Command ACK response.
the one sent to verify the Message.
13 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received Exit Mode
Command ACK response information to the Policy
Engine that consumes it.
14 The Policy Engine stops the VDMModeExitTimer and
requests the Device Policy Manager to enter USB
Operation.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
18 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the Exit
Mode Command ACK response was successfully sent.
Both DFP and UFP are in USB Operation

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 361
 8.3.2.9.6 DFP to Cable Plug Enter Mode
This is an example of Message sequence between a DFP and a Cable Plug both utilizing the Type-C connector.
Figure 8-28 shows an example sequence between a Type-C DFP and a Cable Plug, where the DFP attempts to discover
supported SVIDs, then Modes before selecting and entering a Mode.

Page 362 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 8-28 DFP to Cable Plug Enter Mode
DFP Cable Plug

: DFP Policy Engine : Protocol : PHY : PHY : Protocol : Cable Plug Policy Engine

USB Mode USB Mode

1: Send Discover SVIDs

2: Discover SVIDs
3: Discover SVIDs + CRC
Start CRCReceiveTimer 4: Discover SVIDs

Check MessageID against local copy

Store copy of MessageID

5: Discover SVIDs received

6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC

Check and increment MessageIDCounter

Stop CRCReceiveTimer Evaluate Discover SVIDs request
Wait tCableMessage before transmission
9: Discover SVIDs sent

Start VDMResponseTimer

10: Send Discover SVIDs ACK

11: Discover SVIDs ACK
12: Discover SVIDs ACK + CRC
13: Discover SVIDs ACK Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Discover SVIDs ACK received

15: GoodCRC
Stop VDMResponseTimer 16: GoodCRC + CRC
17: GoodCRC
Check and increment MessageIDCounter
Stop CRCReceiveTimer
Evaluate Discover SVIDs ACK
Wait tCableMessage before 18: Discover SVIDs ACK sent
transmission

19: Send Discover Modes

20: Discover Modes
21: Discover Modes + CRC
Start CRCReceiveTimer 22: Discover Modes
Check MessageID against local copy
Store copy of MessageID

23: Discover Modes received

24: GoodCRC
25: GoodCRC + CRC
26: GoodCRC

Check and increment MessageIDCounter Evaluate Discover Modes request

Stop CRCReceiveTimer Wait tCableMessage before transmission

27: Discover Modes sent

Start VDMResponseTimer

10: Send Discover Modes ACK

11: Discover Modes ACK
12: Discover Modes ACK + CRC
13: Discover Modes ACK Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Discover Modes ACK received

15: GoodCRC
Stop VDMResponseTimer 16: GoodCRC + CRC
17: GoodCRC
Check and increment MessageIDCounter
Stop CRCReceiveTimer
Evaluate Discover Modes ACK
Enter USB Safe Mode 18: Discover Modes ACK sent
Wait tCableMessage before
transmission

19: Send Enter Mode

20: Enter Mode
21: Enter Mode + CRC
Start CRCReceiveTimer 22: Enter Mode
Check MessageID against local copy
Store copy of MessageID

23: Enter Mode received

24: GoodCRC
25: GoodCRC + CRC
26: GoodCRC

Check and increment MessageIDCounter

Stop CRCReceiveTimer

27: Enter Mode sent

Evaluate Enter Mode request
Start VDMModeEntryTimer Enter New Mode
Wait tCableMessage before transmission

10: Send Enter Mode ACK

11: Enter Mode ACK
12: Enter Mode ACK + CRC
13: Enter Mode ACK Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Enter Mode ACK received

15: GoodCRC
16: GoodCRC + CRC
17: GoodCRC
Stop VDMModeEntryTimer
Enter New Mode Check and increment MessageIDCounter
Stop CRCReceiveTimer

18: Enter Mode ACK sent

New Mode Entered

Table 8-27 below provides a detailed explanation of what happens at each labeled step in Figure 8-28 above.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 363
 Table 8-27 Steps for DFP to Cable Plug Enter Mode

Step DFP Cable Plug

1 The DFP has an Explicit Contract. The Device Policy The UFP has an Explicit Contract.
Manager requests the Policy Engine to discover SVID
information.
The Policy Engine directs the Protocol Layer to send
a Discover SVIDs Command request.
2 Protocol Layer creates the Discover SVIDs Command
request and passes to Physical Layer. Starts
CRCReceiveTimer.
3 Physical Layer appends CRC and sends the Discover Physical Layer receives the Discover SVIDs Command
SVIDs Command request. request and checks the CRC to verify the Message.
4 Physical Layer removes the CRC and forwards the
Discover SVIDs Command request to the Protocol
Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received Discover
SVIDs Command request information to the Policy
Engine that consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Discover SVIDs Command request was successfully
sent.
Policy Engine starts the VDMResponseTimer.
10 Policy Engine requests the SVID information from the
Device Policy Manager. tCableMessage after the
GoodCRC Message was sent the Policy Engine tells
the Protocol Layer to form a Discover SVIDs
Command ACK response.
11 Protocol Layer creates the Discover SVIDs Command
ACK response and passes to Physical Layer. Starts
CRCReceiveTimer.
12 Physical Layer receives the Discover SVIDs Physical Layer appends a CRC and sends the Discover
Command ACK response and compares the CRC it SVIDs Command ACK response.
calculated with the one sent to verify the Message.
13 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received Discover
SVIDs Command ACK response information to the
Policy Engine that consumes it.
14 The Policy Engine stops the VDMResponseTimer and
passes the SVIDs information to the Device Policy
Manager for evaluation.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.

Page 364 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step DFP Cable Plug
16 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
18 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Discover SVIDs Command ACK response was
successfully sent.
19 The Device Policy Manager requests the Policy
Engine to discover Mode information for a given
SVID.
tCableMessage after the GoodCRC Message was sent
the Policy Engine directs the Protocol Layer to send a
Discover Modes Command request.
20 Protocol Layer creates the Discover Modes
Command request and passes to Physical Layer.
Starts CRCReceiveTimer.
21 Physical Layer appends CRC and sends the Discover Physical Layer receives the Discover Modes
Modes Command request. Command request and checks the CRC to verify the
Message.
22 Physical Layer removes the CRC and forwards the
Discover Modes Command request to the Protocol
Layer.
23 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received Discover
Modes Command request information to the Policy
Engine that consumes it.
24 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
25 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
26 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
27 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Discover Modes Command request was successfully
sent.
Policy Engine starts the VDMResponseTimer.
28 Policy Engine requests the Mode information from
the Device Policy Manager. tCableMessage after the
GoodCRC Message was sent the Policy Engine tells
the Protocol Layer to form a Discover Modes
Command ACK response.
29 Protocol Layer creates the Discover Modes Command
ACK response and passes to Physical Layer. Starts
CRCReceiveTimer.
30 Physical Layer receives the Discover Modes Physical Layer appends a CRC and sends the Discover
Command ACK response and compares the CRC it Modes Command ACK response.
calculated with the one sent to verify the Message.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 365
 Step DFP Cable Plug
31 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received Discover
Modes Command ACK response information to the
Policy Engine that consumes it.
32 The Policy Engine stops the VDMResponseTimer and
passes the Modes information to the Device Policy
Manager for evaluation.
33 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
34 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
35 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
36 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Discover Modes Command ACK response was
successfully sent.
37 The DFP goes to USB Safe State. The Device Policy
Manager requests the Policy Engine to enter a Mode.
tCableMessage after the GoodCRC Message was sent
the Policy Engine directs the Protocol Layer to send
an Enter Mode Command request.
38 Protocol Layer creates the Enter Mode Command
request and passes to Physical Layer. Starts
CRCReceiveTimer.
39 Physical Layer appends CRC and sends the Enter Physical Layer receives the Enter Mode Command
Mode Command request. request and checks the CRC to verify the Message.
40 Physical Layer removes the CRC and forwards the
Enter Mode Command request to the Protocol Layer.
41 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received Enter Mode
Command request information to the Policy Engine
that consumes it.
42 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
43 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
44 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
45 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Enter Mode Command request was successfully sent.
Policy Engine starts the VDMModeEntryTimer.
46 Policy Engine requests the Device Policy Manager to
enter the new Mode. tCableMessage after the
GoodCRC Message was sent the Policy Engine tells
the Protocol Layer to form an Enter Mode Command
ACK response.

Page 366 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step DFP Cable Plug
47 Protocol Layer creates the Enter Mode Command
ACK response and passes to Physical Layer. Starts
CRCReceiveTimer.
48 Physical Layer receives the Enter Mode Command Physical Layer appends a CRC and sends the Enter
ACK response and compares the CRC it calculated Mode Command ACK response.
with the one sent to verify the Message.
49 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received Enter
Mode Command ACK response information to the
Policy Engine that consumes it.
50 The Policy Engine stops the VDMModeEntryTimer
and requests the Device Policy Manager to enter the
new Mode.
51 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
52 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
53 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
54 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Enter Mode Command ACK response was successfully
sent.
DFP and UFP are operating in the new Mode

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 367
 8.3.2.9.7 DFP to Cable Plug Exit Mode
This is an example of Message sequence between a DFP and a Cable Plug both utilizing the Type-C connector.
Figure 8-29 shows an example sequence between a Type-C DFP and a Cable Plug, where the DFP commands the Cable
Plug to exit an Active Mode.

Figure 8-29 DFP to Cable Plug Exit Mode

DFP Cable Plug

: DFP Policy Engine : Protocol : PHY : PHY : Protocol : Cable Plug Policy Engine

In Mode In Mode
Enter USB Safe State

1: Send Exit Mode

2: Exit Mode
3: Exit Mode + CRC
Start CRCReceiveTimer 4: Exit Mode
Check MessageID against local copy
Store copy of MessageID

5: Exit Mode received

6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC

Check and increment MessageIDCounter

Stop CRCReceiveTimer

9: Exit Mode sent

Evaluate Exit Mode request
Start VDMModeExitTimer Enter USB Operation
Wait tCableMessage before transmission

10: Send Exit Mode ACK

11: Exit Mode ACK
12: Exit Mode ACK + CRC
13: Exit Mode ACK Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

14: Exit Mode ACK received

15: GoodCRC
16: GoodCRC + CRC
17: GoodCRC
Stop VDMModeExitTimer
Enter USB Operation Check and increment MessageIDCounter
Stop CRCReceiveTimer

18: Exit Mode ACK sent

USB operation

Table 8-28 below provides a detailed explanation of what happens at each labeled step in Figure 8-29 above.

Table 8-28 Steps for DFP to Cable Plug Exit Mode

Step DFP Cable Plug

1 The DFP is in a Mode and then enters USB Safe State. The Cable Plug is in a Mode.
The Policy Engine directs the Protocol Layer to send
a Exit Mode Command request.
2 Protocol Layer creates the Exit Mode Command
request and passes to Physical Layer. Starts
CRCReceiveTimer.
3 Physical Layer appends CRC and sends the Exit Mode Physical Layer receives the Exit Mode Command
Command request. request and checks the CRC to verify the Message.
4 Physical Layer removes the CRC and forwards the
Exit Mode Command request to the Protocol Layer.

Page 368 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step DFP Cable Plug
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received Exit Mode
Command request information to the Policy Engine
that consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC Message and Physical Layer appends CRC and sends the GoodCRC
checks the CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Exit Mode Command request was successfully sent.
Policy Engine starts the VDMModeExitTimer.
10 Policy Engine requests the Device Policy Manager to
enter USB operation. tCableMessage after the
GoodCRC Message was sent the Policy Engine tells
the Protocol Layer to form an Exit Mode Command
ACK response.
11 Protocol Layer creates the Exit Mode Command ACK
response and passes to Physical Layer. Starts
CRCReceiveTimer.
12 Physical Layer receives the Exit Mode Command ACK Physical Layer appends a CRC and sends the Exit
response and compares the CRC it calculated with Mode Command ACK response.
the one sent to verify the Message.
13 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received Exit Mode
Command ACK response information to the Policy
Engine that consumes it.
14 The Policy Engine stops the VDMModeExitTimer and
requests the Device Policy Manager to enter USB
Operation.
15 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
16 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
17 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
18 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the Exit
Mode Command ACK response was successfully sent.
Both DFP and Cable Plug are in USB Operation

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 369
 8.3.2.9.8 UFP to DFP Attention
This is an example of Message sequence between a DFP and a UFP both utilizing the Type-C connector.
Figure 8-30 shows an example sequence between a Type-C DFP and a UFP, where the UFP requests attention from the
DFP.

Figure 8-30 UFP to DFP Attention

DFP UFP

: DFP Policy Engine : Protocol : PHY : PHY : Protocol : UFP Policy Engine

1: Send Attention
2: Attention
3: Attention + CRC
4: Attention Start CRCReceiveTimer

Check MessageID against local copy

Store copy of MessageID

5: Attention received
6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC
Check and increment MessageIDCounter
Stop CRCReceiveTimer

9: Attention sent

Table 8-29 below provides a detailed explanation of what happens at each labeled step in Figure 8-30 above.

Table 8-29 Steps for UFP to DFP Attention

Step DFP UFP

1 The Device Policy Manager requests attention. The
Policy Engine tells the Protocol Layer to form an
Attention Command request.
2 Protocol Layer creates the Attention Command
request and passes to Physical Layer. Starts
CRCReceiveTimer.
3 Physical Layer receives the Attention Command Physical Layer appends a CRC and sends the
request and compares the CRC it calculated with the Attention Command request.
one sent to verify the Message.
4 Protocol Layer checks the MessageID in the
incoming Message is different from the previously
stored value and then stores a copy of the new value.
The Protocol Layer forwards the received Attention
Command request information to the Policy Engine
that consumes it.
5 The Policy Engine informs the Device Policy Manager
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer appends a CRC and sends the Physical Layer receives GoodCRC Message and
GoodCRC Message. compares the CRC it calculated with the one sent to
verify the Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.

Page 370 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step DFP UFP
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
Attention Command request was successfully sent.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 371
 8.3.2.10 Built in Self-Test (BIST)

8.3.2.10.1 BIST Receiver Mode

This is an example of a BIST Receiver Mode test between a Tester and a Unit Under Test (UUT).
Figure 8-31 shows the Messages as they flow across the bus and within the devices. This test verifies that the UUT can
receive data with a performance according this specification.

Figure 8-31 BIST Receiver Mode test

Tester UUT

: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

1: Send BIST(Receiver Mode)

2: BIST(Receiver Mode)
3: BIST(Receiver Mode) + CRC
Start CRCReceiveTimer 4: BIST(Receiver Mode)

Check MessageID against

local copy
Store copy of MessageID

5: BIST(Receiver Mode) received

6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC

10: Go to BIST receiver mode

Check and increment MessageIDCounter
Stop CRCReceiveTimer Go to BIST Receiver Mode

9: BIST(Receiver Mode) sent 11: Go to BIST receiver mode

Start BISTStartTimer Go to BIST Receiver Mode

Reset BISTErrorCounter
Preload PRBS generator
BISTStartTimer expires
Enter BIST Receiver Mode

12: Send Test Pattern

Start BISTReceiveErrorTimer

13: Send Test Pattern

14: Test Pattern

Calculate Bit Error Count per frame

Add to BISTErrorCounter

15: BISTErrorCounter
16: Test Pattern received

17: BIST(CountersReturned)
18: BIST(CountersReturned) + CRC
19: BIST(CountersReturned)

Check and increment MessageIDCounter

Stop BISTReceiveErrorTimer

20: Test Pattern sent

Test Pattern repeated for duration of test

Initiate Hard Reset

Page 372 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 8-30 Steps for BIST Receiver Mode test

Step Tester UUT

1 The Policy Engine directs the Protocol Layer to
generate a BIST Message with BIST Data Object of
BIST Receiver Mode to put the UUT into BIST
receiver mode.
2 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
3 Physical Layer appends CRC and sends the BIST Physical Layer receives the BIST Message and checks
Message. the CRC to verify the Message.
4 Physical Layer removes the CRC and forwards the
BIST Message to the Protocol Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received BIST
Message information to the Policy Engine that
consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC and checks the Physical Layer appends CRC and sends the GoodCRC
CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
BIST Message was successfully sent. The Policy
Engine initializes and runs the BISTStartTimer.
10 Policy Engine tells Protocol Layer to go into Receiver
Test Mode. The Protocol Layer goes to BIST receiver
mode.
11 Protocol Layer tells Physical Layer to go into BIST
Receiver Mode. The Physical Layer goes to BIST
Receiver Mode, resets the BISTErrorCounter and
preloads the PRBS generator.
UUT enters BIST Receiver Mode
12 After the BISTStartTimer has expired the Policy
Engine directs the Protocol Layer to generate a
packet containing the next Test Frame.
13 Protocol Layer creates the Message and passes to
Physical Layer. Starts BISTReceiveErrorTimer.
14 Physical Layer does not append a CRC and sends the Physical Layer receives the Test Frame. The Physical
Test Frame. Layer calculates the Bit Error Count for the Test
Frame and adds this to the BISTErrorCounter.
15 Physical Layer forwards the BISTErrorCounter value
to the Protocol Layer.
16 The Protocol Layer informs the Policy Engine that a
Test Frame has been received.
17 Protocol Layer generates a BIST Message with BIST
Data Object of Returned BIST Counters and passes it
Physical Layer.
18 Physical Layer receives BIST Message and checks the Physical Layer appends CRC and sends the BIST
CRC to verify the Message. Message.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 373
 Step Tester UUT
19 Physical Layer removes the CRC and forwards the
BIST Message to the Protocol Layer.
20 Protocol Layer verifies and increments the
MessageIDCounter and stops
BISTReceiveErrorTimer. Protocol Layer informs the
Policy Engine that the Test Frame was successfully
sent.
Steps 12 to 20 are repeated until Hard Reset Signaling is generated at which point the UUT returns to normal
operation.

Page 374 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.2.10.2 BIST Transmit mode
This is an example of a BIST Transmit Mode test between a Tester and a UUT. Figure 8-32 shows the Messages as they
flow across the bus and within the devices. This test verifies that the UUT transmitter can transmit with sufficient
quality (see Section 6.4.3.2).

Figure 8-32 BIST Transmit Mode test

Tester UUT

: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

1: Send BIST(Transmit Mode)

2: BIST(Transmit Mode)
3: BIST(Transmit Mode) + CRC
Start CRCReceiveTimer 4: BIST(Transmit Mode)

Check MessageID against

local copy
Store copy of MessageID

5: PhyBIST(Transmit Mode) received

6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC

Check and increment MessageIDCounter 10: Go to BIST Transmit mode

Stop CRCReceiveTimer
Go to BIST Transmit Mode
9: BIST(Transmit Mode) sent
Reset BISTErrorCounter

11: Go to BIST Transmit mode

Enter BIST Transmit Mode

12: Send Test Pattern

Start BISTReceiveErrorTimer
13: Test Pattern

14: Test Pattern

15: Test Pattern

Calculate BER
Add to BER count

16: Test Pattern received

17: BER count
18: BER Count + CRC
19: BER Count

Check and increment MessageIDCounter

Stop BISTReceiveErrorTimer

20: Test Pattern sent

Test Pattern repeated for duration of test

Initiate Hard Reset

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 375
 Table 8-31 Steps for BIST Transmit Mode test

Step Tester UUT

1 The Policy Engine directs the Protocol Layer to
generate a BIST Message, with BIST Data Object of
BIST Transmit Mode, to put the UUT into BIST
Transmit Mode.
2 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
3 Physical Layer appends CRC and sends the BIST Physical Layer receives the BIST Message and checks
Message. the CRC to verify the Message.
4 Physical Layer removes the CRC and forwards the
BIST Message to the Protocol Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received BIST
Message information to the Policy Engine that
consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC and checks the Physical Layer appends CRC and sends the GoodCRC
CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
BIST Message was successfully sent.
10 Policy Engine tells Protocol Layer to go into BIST
Transmit Mode. The Policy Engine goes to BIST
Transmit mode and resets the BISTErrorCounter.
11 Protocol Layer tells Physical Layer to go into BIST
Transmit Mode.
UUT enters BIST Transmit Mode
12 The Policy Engine directs the Protocol Layer to
generate a packet containing the next Test Frame.
13 Protocol Layer creates the Test Frame and passes to
Physical Layer. Starts BISTReceiveErrorTimer.
14 Physical Layer receives the Test Frame. Physical Layer does not append a CRC and sends the
Test Frame.
15 Physical Layer forwards the Test Frame to the
Protocol Layer.
16 The Protocol Layer forwards the received Test Frame
information to the Policy Engine that consumes it.
17 Protocol Layer generates a BIST Message with a BIST
Data Object of Returned BIST Counters and passes it
Physical Layer.
18 Physical Layer appends CRC and sends the BIST Physical Layer receives the BIST Message and checks
Message. the CRC to verify the BIST Message.
19 Physical Layer removes the CRC and forwards the
BIST Message to the Protocol Layer.

Page 376 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Tester UUT
20 Protocol Layer verifies and increments the
MessageIDCounter and stops
BISTReceiveErrorTimer. Protocol Layer informs the
Policy Engine that the Test Frame was successfully
sent.
Steps 12 to 20 are repeated until Hard Reset Signaling is generated at which point the UUT returns to normal
operation.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 377
 8.3.2.10.3 BIST Test Patterns
In addition to the BIST transmit and receive Test Frames there are various Test Patterns which the UUT can be made
to send continuously in order to perform measurements on the transmission spectrum, eye pattern etc. (see Section
5.9.1). The following is an example of a BIST Eye Pattern test between a Tester and a UUT but the sequence applies
equally to other continuous Test Patterns. When the UUT is connected to the Tester the sequence below is executed.
Figure 8-33 shows the Messages as they flow across the bus and within the devices. This test verifies the eye pattern
and the spectrum of the transmitted signal.
1) Connection is established and stable.
2) Tester sends a BIST Message with a BIST Eye Pattern BIST Data Object.
3) UUT answers with a GoodCRC Message.
4) UUT starts sending the Test Pattern.
5) Operator does the measurements.
6) Operator restarts the UUT. Note: that the method of operator restart for the UUT is outside the scope of this
specification. This is assumed to be some mechanism whereby the operator restores the UUT to normal PD
operation.
Refer to Sections 6.4.3.4 through 0.

Figure 8-33 BIST Eye Pattern Test

Tester UUT

: Policy Engine : Protocol : PHY : PHY : Protocol : Policy Engine

1: Send BIST(Eye Pattern)

2: BIST(Eye Pattern)
3: BIST(Eye Pattern) + CRC
Start CRCReceiveTimer 4: BIST(Eye Pattern)

Check MessageID against

local copy
Store copy of MessageID

5: BIST(Eye Pattern) received

Go to BIST Transmit Mode

Reset BISTErrorCounter

6: GoodCRC
7: GoodCRC + CRC
8: GoodCRC

Check and increment MessageIDCounter

Stop CRCReceiveTimer
10: Go to BIST Eye Pattern mode
11: Go to BIST Eye Pattern mode
9: BIST(Eye Pattern) sent

Enter BIST Eye Pattern mode

12: Send Test Pattern

13: Send Test Pattern
14: Test Pattern

Operator Reset – End of Test

Page 378 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 8-32 Steps for BIST Eye Pattern Test

Step Tester UUT

1 The Policy Engine directs the Protocol Layer to
generate a BIST Message, with a BIST Data Object of
BIST Eye Pattern, to put the UUT into BIST Eye
Pattern Test.
2 Protocol Layer creates the Message and passes to
Physical Layer. Starts CRCReceiveTimer.
3 Physical Layer appends CRC and sends the BIST Physical Layer receives the BIST Message and checks
Message. the CRC to verify the Message.
4 Physical Layer removes the CRC and forwards the
BIST Message to the Protocol Layer.
5 Protocol Layer checks the MessageID in the incoming
Message is different from the previously stored value
and then stores a copy of the new value.
The Protocol Layer forwards the received BIST
Message information to the Policy Engine that
consumes it.
6 Protocol Layer generates a GoodCRC Message and
passes it Physical Layer.
7 Physical Layer receives the GoodCRC and checks the Physical Layer appends CRC and sends the GoodCRC
CRC to verify the Message. Message.
8 Physical Layer removes the CRC and forwards the
GoodCRC Message to the Protocol Layer.
9 Protocol Layer verifies and increments the
MessageIDCounter and stops CRCReceiveTimer.
Protocol Layer informs the Policy Engine that the
BIST Message was successfully sent.
10 Policy Engine tells Protocol Layer to go into BIST Eye
Pattern Test Mode. The Policy Engine goes to BIST
Eye Pattern Test Mode.
11 Protocol Layer tells Physical Layer to go into BIST Eye
Pattern Test Mode.
UUT enters BIST Eye Pattern Test Mode
12 The Policy Engine directs the Protocol Layer to start
generation of the Test Pattern.
13 Protocol Layer directs the PHY Layer to generate the
Test Pattern.
14 Physical Layer receives the Test Pattern stream. Physical Layer generates a continuous Test Pattern
stream.
Operator reset of UUT terminates the test

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 379
 8.3.3 State Diagrams
8.3.3.1 Introduction to state diagrams used in Chapter 8
The state diagrams defined in Section 8.3.3 are normative and shall define the operation of the Power Delivery Policy
Engine. Note that these state diagrams are not intended to replace a well written and robust design.

Figure 8-34 Outline of States

<Name of State>
Actions on entry:
“List of actions to carry out on entering the
state”

Actions on exit:
“List of actions to carry out on exiting the
state”
Power (VI) = “Present power level”
PD = “attachment status”

Figure 8-34 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”, “unattached”, 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 8-35 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 pre-conditions (see example in Figure 8-36). It is also possible that the entry and return states are the
same. Figure 8-37 indicates a state reference where each referenced state corresponds to either the entry state or the
exit state.

Figure 8-35 References to states

<Name of reference state>

(<DFP | UFP>)

Figure 8-36 Example of state reference with conditions

Hard Reset:

 Consumer or
Consumer/Provider ->
PE_SNK_....
 Provider/Consumer in
Source role ->
PE_SRC_...

Page 380 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 8-37 Example of state reference with the same entry and exit

<Name of reference state 1> or

<Name of reference state 2>
(<DFP | UFP>)

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.
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 Cable Detection.
Note: The following state diagrams are not intended to cover all possible corner cases that may be encountered. For
example where an outgoing Message is discarded, due to an incoming Message by the Protocol Layer (see Section
6.8.2.2) it will be necessary for the higher layers of the system to handle a retry of the Message sequence that was
being initiated, after first handling the incoming Message.

8.3.3.2 Policy Engine Source Port State Diagram

Figure 8-38 below shows the state diagram for the Policy Engine in a Source Port. The following sections describe
operation in each of the states.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 381
 Figure 8-38 Source Port Policy Engine state diagram

Hard reset signalling received

Start
PE_SRC_Hard_Reset_Received PE_SRC_Transition_to_default
Actions on entry:
Actions on entry:
Request Device Policy Manager to request power Power source at default PE_SRC_Startup
Start PSHardResetTimer
supply Hard Resets to vSafe5V via vSafe0V
Actions on entry:
Power = DefauIt (5V) or Reset local HW
Reset CapsCounter
Implicit/Explicit Contract If Type-C request Device Policy Manager to set
Reset Protocol Layer
PD = Connected/not Connected Port Data Role to DFP and turn off VCONN
Start SwapSourceStartTimer (only after Swap)
Actions on exit:
PSHardResetTimer Power = DefauIt (5V) or Implicit Contract
Request Device Policy Manager to turn on VCONN
timeout PD = Connected/not Connected
Initialize and start NoResponseTimer
Inform Protocol Layer Hard Reset complete Protocol LayerReset6 |
(SourceCapabilityTimer timeout & CapsCounter > nCapsCount2) |
SwapSourceStartTimer timeout
Power = rising/falling to default (5V) ((not Type-C | (Type-C & not previously PD Connected8) ) &
PD = not Connected PE_SRC_Discovery NoResponseTimer timeout &
HardResetCounter > nHardResetCount1)
Actions on entry:
PSHardResetTimer Initialize and run SourceCapabilityTimer
timeout
Power = Default (5V) or Implicit Contract
PD = not Connected
PE_SRC_Hard_Reset
(Capabilities message sending failure PE_SRC_Disabled
Actions on entry: (SourceCapabilityTimer timeout &
Generate Hard Reset signalling CapsCounter ≤ nCapsCount2) (without GoodCRC) &not presently PD Connected7) | Actions on entry:
Start PSHardResetTimer not Type-C & Disable Power Delivery
Increment HardResetCounter (NoResponseTimer timeout &
HardResetCounter > nHardResetCount1)
Power = DefauIt (5V) or Power = DefauIt (5V)
PE_SRC_Wait_New_Capabilities Implicit/Explicit Contract PD =not Connected
PD = Connected/not Connected PE_SRC_Send_Capabilities
Actions on entry:
Wait for new Source Capabilites Actions on entry:
Request present source capabilities from Device Policy Manager (not Type-C | (Type-C & not previously PD Connected8) ) &
Power = DefauIt (5V) Send PD Capabilities message NoResponseTimer timeout &
PD =Connected Increment CapsCounter (optional)2 HardResetCounter > nHardResetCount1
SenderResponseTimer timeout
If GoodCRC received:
 stop NoResponseTimer
 reset HardResetCounter and CapsCounter
Source capability  initialize and run SenderResponseTimer
change
(from Device Power = DefauIt (5V) or Implicit/Explicit Contract Type-C &
Policy Manager) PD = Connected/not Connected previously PD Connected8 &
NoResponseTimer timeout &
Request message received HardResetCount
> nHardResetCount
PE_SRC_Negotiate_Capability
Explicit Contract & Actions on entry:
Reject message sent & Get Device Policy Manager evaluation of sink request:
Contract Invalid5 Request can’t be met |  Can be met
Request met later  Can’t be met ErrorRecovery
from Power Reserve  Could be met later from Power Reserve
PE_SRC_Capability_Response If the sink still requires more power (“Capability Mismatch”) this
Actions on entry: information will be passed to Device Policy Manager4
Send Reject message if request can’t
be met Power = DefauIt (5V) or Implicit/Explicit Contract
no Explicit Contract & Send Wait message if request could PD = Connected
(Reject message sent | be met later from the Power
Wait message sent) Reserve and present Contract is still Request can be met
Request message
valid received

Power = DefauIt (5V) or Implicit/ PE_SRC_Transition_Supply

Explicit Contract Actions on entry:
PD = Connected Initialize and run SourceActivityTimer (see Section 8.3.3.5)3
If GotoMin send GotoMin message
Explicit Contract Else send Accept message (within tSenderResponse)
(Reject message sent & Wait tSrcTransition and request Device Policy Manager to
Contract still valid) | transition Power Supply
Wait message sent Actions on exit:
Send PS_RDY message
Power = transition
PD = Connected

Power supply ready

GotoMin request from
Device Policy Manager Get_Source_Cap message PE_SRC_Give_Source_Cap
PE_SRC_Ready received
Actions on entry:
Actions on entry: Request source capabilities from
Initialize and run Device Policy Manager
SourceActivityTimer3 Capabilities message Send Capabilities message
(see Section 8.3.3.5) sent Power = Explicit Contract
Initialize and run
PD = Connected
DiscoverIdentityTimer9
get sink capabilities request
Source capability
change
from Device Policy Manager PE_SRC_Get_Sink_Cap
(from Device Actions on entry:
Policy Manager) Send Get_Sink_Cap message
Sink capabilities Initialize and run
message received | SenderResponseTimer
SenderResponseTimer
Actions on exit:
1
For a non-Type-C Port If the NoResponseTimer times Out and the HardResetCounter > nHardResetCount the Policy Engine can either timeout
Pass sink capabilities/outcome to
continue sending capabilities or go to the PE_SRC_Disabled state. Power = Explicit Contract Device Policy Manager
2
Implementation of the CapsCounter is optional. In the case where this is not implemented the Source shall continue to send Capabilities PD = Connected Power = Explicit Contract
messages each time the SourceCapabilityTimer times out.
3 PD = Connected
When operating at vSafe5V and not swapped, or when two systems both using the Type-C connector are communicating, Ping messages are
optional so the SourceActivityTimer is not required to run in these circumstances.
4
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.
5
“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.
6
After a Power Swap the new Source is required to wait an additional tSwapSourceStart before sending Source Capabilities. This delay is not
required when first starting up a system.
7
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 disconnect (Type-C, Type-A with insert detect, Micro-AB).
8
Port Partners are no longer PD Connected after a Hard Reset but for Type-C connections consideration needs to be given as to whether there
has been a PD Connection while the Ports have been attached to prevent unnecessary Type-C disconnects.
9
The DiscoverIdentityTimer is run when this is a DFP and a PD Connection with a Cable Plug needs to be established i.e. no GoodCRC has yet
been received in response to a DiscoverIdentity message.

Page 382 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.2.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 that resetting the
Protocol Layer will also reset the MessageIDCounter and stored MessageID (see Section 6.8.2.3).
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: Providers or Provider/Consumers with an insertion detection mechanism (Type-C, Standard-A insertion detect
or Micro-A ID pin or Attach Detection Protocol see [USBOTG 2.0]) and without a plug attached shall remain in the
PE_SRC_Startup state, without sending any Source_Capabilities Messages until a plug is attached.

8.3.3.2.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.
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 is not a Type-C Port
 Or the Port is a Type-C Port and the Port Partners have not been PD Connected (the Type-C 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 unattached until such time as a detach/reattach is detected.
The Policy Engine shall go to the ErrorRecovery state when:
 The Port is a Type-C Port
 And the Port Partners have previously been PD Connected (the Type-C 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

8.3.3.2.3 PE_SRC_Send_Capabilities state

Note: this state may 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 Source_Capabilities
Message containing these capabilities and increment the CapsCounter (if implemented).
If a GoodCRC Message is received then the Policy Engine shall:
 Stop the NoResponseTimer .

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 383
  Reset the HardResetCounter and CapsCounter to zero. Note that 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.
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.
When:
 The Port is not a Type-C Port
 Or the Port is a Type-C Port and the Port Partners have not been PD Connected (the Type-C 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 unattached until such time as a detach/reattach is detected.
The Policy Engine shall go to the ErrorRecovery state when:
 The Port is a Type-C Port
 And the Port Partners have previously been PD Connected (the Type-C 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.

8.3.3.2.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.

Page 384 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.2.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 initialize and run the SourceActivityTimer
(see Section 8.3.3.6 for details of Ping messaging for Source Ports), request the Protocol Layer to either send a
GotoMin Message (if this was requested by the Device Policy Manager) or otherwise an Accept Message, wait for
tSrcTransition, and inform the Device Policy Manager that it shall transition the power supply to the Requested
power level. Note: that 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.

8.3.3.2.6 PE_SRC_Ready state

In the PE_SRC_Ready state the PD Source shall operating at a stable power with no ongoing negotiation. It shall
respond to requests from the Sink, events from the Device Policy Manager and shall send out Ping Messages to
maintain the PD link if required (see Section 6.3.5).
On entry to the PE_SRC_Ready state the Policy Engine shall initialize and run the SourceActivityTimer (see Section
8.3.3.6 for details of Ping messaging for Source Ports). If this is a DFP which needs to establish communication with a
Cable Plug, the DFP shall initialize and run the DiscoverIdentityTimer (no GoodCRC Message response yet received
to Discover Identity Message).
The Policy Engine shall transition to the PE_SRC_Send_Capabilities state when:
 The Device Policy Manager indicates that Source Capabilities have changed.
The Policy Engine shall transition to the PE_SRC_Transition_Supply state when:
 A GotoMin request is received from the Device Policy Manager for the attached Device to go to minimum power.
The Policy Engine shall transition to the PE_SRC_Give_Source_Cap state when:
 A Get_Source_Cap Message is received from the Sink.
The Policy Engine shall transition to the PE_SRC_Get_Sink_Cap state when:
 The Device Policy Manager asks for the Sink’s capabilities.

8.3.3.2.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.

8.3.3.2.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 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_Capability_Response 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 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 Contract is invalid.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 385
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 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 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.
Note: The Policy Engine of a Consumer/Provider, acting as the Source, transitions to the PE_SNK_Hard_Reset state as
described in the Section 8.3.3.6.1.4.

8.3.3.2.9 PE_SRC_Hard_Reset state

The Policy Engine shall transition from any state to the PE_SRC_Hard_Reset state when
 The NoResponseTimer times out and the HardResetCounter ≤ nHardResetCount or
 The Device Policy Manager requests a Hard Reset.
On entry to the PE_SRC_Hard_Reset state the Policy Engine shall request the generation of Hard Reset Signaling by
the PHY Layer, initialize and run the PSHardResetTimer and increment the HardResetCounter. Note that 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.

8.3.3.2.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.
The Policy Engine shall transition to the PE_SRC_Transition_to_default state when:
 The PSHardResetTimer times out.

8.3.3.2.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 7.1.6)
 request a reset of the local hardware
 for a Type-C connector shall 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:
 for a Type-C connector shall request the Device Policy Manager to turn on V CONN
 initialize and run the NoResponseTimer. Note that the NoResponseTimer shall continue to run in every state
until it is stopped or times out.
 inform the Protocol Layer that the Hard Reset is complete.

Page 386 USB Power Delivery Specification Revision 2.0, Version 1.1
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.

8.3.3.2.12 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 transition to the PE_SRC_Ready state when:
 The Source_Capabilities Message has been successfully sent.

8.3.3.2.13 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’s 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).
The Policy Engine shall transition to the PE_SRC_Ready state when:
 A Sink_Capabilities Message is received.
 Or SenderResponseTimer times out.

8.3.3.2.14 PE_SRC_Wait_New_Capabilities
In this state the Policy Engine has been unable to negotiate an Explicit Contract and is waiting either 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.

8.3.3.3 Policy Engine Sink Port State Diagram

Figure 8-39 below shows the state diagram for the Policy Engine in a Sink Port. The following sections describe
operation in each of the states.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 387
 Figure 8-39 Sink Port state diagram

Hard reset signalling received

Start
PE_SNK_Transition_to_default Protocol Layer
Actions on entry: PE_SNK_Startup Reset &
Request Device Policy Manager to request power Power Sink Type-B C/P Port
sink transition to default at default
Actions on entry: PE_DB_CP_Check_for_VBUS2
Reset local HW Reset Protocol Layer
If Type-C set Port Data Role to UFP and turn off
VCONN Power = DefauIt (0V or 5V) or
Implicit Contract
Actions on exit: PD = Connected/not Connected
Initialize and run NoResponseTimer
Inform Protocol Layer Hard Reset complete Protocol Layer Reset &
((SinkWaitCapTimer timeout |
SinkActivityTimer timeout | NOT Type-B C/P Port Type-C &
Power = rising/falling to default (5V)
PSTransitionTimer timeout | PD = not Connected previously PD Connected7 &
NoResponseTimer timeout) & PE_SNK_Discovery NoResponseTimer timeout &
(HardResetCounter ≤ nHardResetCount)) | Hard Reset complete
HardResetCount
Hard Reset request from not Type-C & Actions on entry: > nHardResetCount
Device Policy Manager NoResponseTimer timeout & Wait for VBUS
PE_SNK_Hard_Reset HardResetCounter
≤ nHardResetCount
Actions on entry: Power = Default (0V or 5V) or
Generate Hard Reset signalling. Implicit Contract
Increment HardResetCounter. PD = Connected/not Connected

Power = DefauIt (5V) or

VBUS present6
Implicit/Explicit Contract
PD = Connected/not Connected Type-C &
previously PD Connected7 &
PE_SNK_Wait_for_Capabilities NoResponseTimer timeout &
HardResetCount
Actions on entry: > nHardResetCount
Initialize and run SinkWaitCapTimer
ErrorRecovery
Power = Default (0V or 5V) or
Implicit Contract
PD = Connected/not Connected

Source capabilities message received1

PE_SNK_Evaluate_Capability
Actions on entry:
Stop NoResponseTimer and reset HardResetCounter to zero.
Ask Device Policy Manager to evaluate option based on supplied
capabilities (from supplied capabilities, reserve or “Capability
Mismatch”).

Power = DefauIt (5V) or Implicit Contract

SenderResponseTimer
PD = Connected
Timeout
Device Policy Manager Response received no Explicit Contract &
(Reject message received |
PE_SNK_Select_Capability Wait message received)

Actions on entry:
Send Request based on Device Policy Manager response either:
 Request from present capabilities
 Indicate if other capabilities would be required (“Capability
Mismatch”)
Initialize and run SenderResponseTimer

Power = DefauIt (5V) or Implicit Contract Explicit Contract &

PD = Connected (Reject message received |
Wait message received)
Source capabilities
Accept message
message received1
received

PE_SNK_Transition_Sink
New power required | Actions on entry:
SinkRequestTimer Initialize and run PSTransitionTimer
timeout Actions on exit:
Request Device Policy Manager transitions sink
power supply to new power (if required)
Power = transition
PD = Connected

GotoMin message PS_RDY message

received received

PE_SNK_Ready
Actions on entry:
Initialize and run SinkActivityTimer3
Initialize and run SinkRequestTimer4 (on receiving Wait)
Initialize and run DiscoverIdentityTimer8

Power = Explicit Contract

PD = Connected

Get_Sink_Cap message
Sink capabilities Update remote capabilities
received Get_Source_Cap
message sent request from
Message sent Device Policy Manager
PE_SNK_Give_Sink_Cap
Actions on entry: PE_SNK_Get_Source_Cap
Get present sink capabilities from Device Policy Manager
Send Capabilities message (based on Device Policy Actions on entry:
Manager response) Send Get_Source_Cap message

Power = Explicit Contract Power = Explicit Contract

PD = Connected PD = Connected

1
Source capabilities messages received in states other than PE_SNK_Wait_For_Capabilities and PE_SNK_READY constitute a Protocol Error.
2
The NoResponseTimer will be stopped upon entry to the PE_DB_CP_Check_for_VBUS state.
3
The SinkActivityTimer shall not be run when operating at vSafe5V or when two systems using the Type-C connector are communicating, since Ping messages are optional.
4
The SinkRequestTimer should not be stopped if a Ping message is received in the PE_SNK_Ready state since it represents the maximum time between requests after a Wait which is
not reset by a Ping message.
5
For Type-C connectors error recovery steps can be taken at this point which are defined in the USB Type-C specification and are outside the scope of this specification.
6
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.
7
PD Connected is defined as a situation when the Port Partners have exchanged a Message and GoodCRC response. The Port Partners remain PD Connected after a Swap or the
connector is able to identify a disconnect (Type-C, Type-A with insert detect, Micro-AB).
8
The DiscoverIdentityTimer is run when this is a DFP and a PD Connection with a Cable Plug needs to be established i.e. no GoodCRC has yet been received in response to a
DiscoverIdentity message.

Page 388 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.3.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 that resetting the Protocol Layer will also reset the
MessageIDCounter and stored MessageID (see Section 6.8.2.3).
Once the reset process completes, the Policy Engine shall transition to the PE_SNK_Discovery state for a Consumer
only and to the PE_DB_CP_Check_for_VBUS state for a Type-B Consumer/Provider.

8.3.3.3.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.
The Policy Engine shall transition to the ErrorRecovery state when:
 The Port is a Type-C connector and
 The Port Partners have previously been PD Connected (the Type-C Port remains attached to a Port it has had a PD
Connection with during this attachment) and
 There has been a NoResponseTimer timeout and
 The HardResetCounter > nHardResetCount.
ThePolicy Engine shall transition to the PE_SNK_Hard_Reset state when:
 The Port is not a Type-C connector and
 There has been a NoResponseTimer timeout and
 The HardResetCounter ≤ nHardResetCount.

8.3.3.3.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:
 A Source_Capabilities Message is received.
The Policy Engine shall transition to the ErrorRecovery state when:
 The Port is a Type-C connector and
 The Port Partners have previously been PD Connected (the Type-C Port remains attached to a Port it has had a PD
Connection with during this attachment) and
 There has been a NoResponseTimer timeout and
 The HardResetCounter > nHardResetCount.
When the SinkWaitCapTimer times out, the Policy Engine will perform a Hard Reset.

8.3.3.3.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 which new power level is required:
 A selection from the present offered capabilities is to be made.
 Capability mismatch; offered power does not meet the device’s requirements.
The Policy Engine shall transition to the PE_SNK_Select_Capability state when:
USB Power Delivery Specification Revision 2.0, Version 1.1 Page 389
 A response is received from the Device Policy Manager.

8.3.3.3.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).
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 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_Hard_Reset state when:
 A SenderResponseTimer timeout occurs.
Note: The Policy Engine of the Provider/Consumer, acting as the Sink, transitions to the PE_SRC_Hard_Reset state as
described in the Section 8.3.3.6.1.3.

8.3.3.3.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 8.3.3.3.8 and shall then request the Device Policy Manager to transition
the Sink’s power supply to the new power level. Note that 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:
 A PS_RDY Message is received from the Source.

8.3.3.3.7 PE_SNK_Ready state

In the PE_SNK_Ready state the PD Sink shall be operating at a stable power level with no ongoing negotiation. It shall
respond to requests from the Source, events from the Device Policy Manager and may monitor for Ping Messages to
maintain the PD link.
On entry to the PE_SNK_Ready state as the result of a wait the Policy Engine should do the following:
 Initialize and run the SinkRequestTimer.
On entry to the PE_SNK_Ready state the Policy Engine shall do the following:
 Initialize and run the SinkActivityTimer (see Section 6.5.3.2 for exceptions).

Page 390 USB Power Delivery Specification Revision 2.0, Version 1.1
If this is a DFP which needs to establish communication with a Cable Plug, the DFP shall:
 Initialize and run the DiscoverIdentityTimer (no GoodCRC Message response yet received to Discover Identity
Message).
The Policy Engine shall transition to the PE_SNK_Evaluate_Capability state when:
 A Source_Capabilities Message is received.
The Policy Engine shall transition to the PE_SNK_Select_Capability state when:
 A new power level is requested by the Device Policy Manager.
 A SinkRequestTimer timeout occurs.
The Policy Engine shall transition to the PE_SNK_Transition_Sink state when:
 A GotoMin Message is received.
The Policy Engine shall transition to the PE_SNK_Hard_Reset state when:
 A SinkActivityTimer timeout occurs.
The Policy Engine shall transition back to the PE_SNK_Ready state when:
 A Ping Message is received. Note this should not cause the SinkRequestTimer to be reinitialized.
The Policy Engine shall transition to the PE_SNK_Give_Sink_Cap state when:
 A Get_Sink_Cap Message is received from the Protocol Layer.
The Policy Engine shall transition to the PE_SNK_Get_Source_Cap state when:
 The Device Policy Manager requests an update of the remote Source’s capabilities.

8.3.3.3.8 PE_SNK_Hard_Reset state

The Policy Engine shall transition to the PE_SNK_Hard_Reset state from any state when:
 ((SinkWaitCapTimer timeout |
 SinkActivityTimer timeout |
 PSTransitionTimer timeout |
 NoResponseTimer timeout) &
 (HardResetCounter ≤ nHardResetCount)) |
 Hard Reset request from Device Policy Manager
Note: if the NoResponseTimer times out and the HardResetCounter is greater than nHardResetCount the Sink shall
assume that the Source is non-responsive.
Note: The nHardResetCount 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.

8.3.3.3.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.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 391
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
 for a Type-C connector shall request that the Port Data Role is set to UFP.
On exit from the PE_SNK_Transition_to_default state the Policy Engine shall initialize and run the NoResponseTimer
and inform the Protocol Layer that the Hard Reset is complete. Note that the NoResponseTimer shall continue to run
in every state until it is stopped or times out.
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.

8.3.3.3.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 transition to the PE_SNK_Ready state when:
 The Sink_Capabilities Message has been successfully sent.

8.3.3.3.11 PE_SNK_Get_Source_Cap state

In the PE_SNK_Get_Source_Cap state the Policy Engine, due to a request from the Device Policy Manager, shall request
the capabilities from the attached Source.
On entry to the PE_SNK_Get_Source_Cap state the Policy Engine shall request the Protocol Layer to send a
Get_Source_Cap Message in order to retrieve the Source’s capabilities.
The Policy Engine shall transition to the PE_SNK_Ready state when:
 The Get_Source_Cap Message is sent.

8.3.3.4 Soft Reset State Diagrams

8.3.3.4.1 Source Port Soft Reset State Diagram

Figure 8-40 below shows the state diagram for the Policy Engine in a Source Port when performing a Soft Reset of its
Port Partner. The following sections describe operation in each of the states.

Page 392 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 8-40 Source Port Soft Reset Diagram

Accept message
received
PE_SRC_Send_Capabilities

Accept message
sent

Hard Reset:
SenderResponseTimer
Transmission Timeout | PE_SRC_Send_Soft_Reset
PE_SRC_Soft_Reset  Provider or Provider/ Transmission
Error indication
from Protocol Layer Consumer2 -> Error indication Actions on entry:
Actions on entry: from Protocol Layer
PE_SRC_Hard_Reset Reset Protocol Layer
Reset Protocol Layer
Send Soft Reset message
Send Accept message  Consumer/Provider in
Initialize and run SenderResponseTimer
Source role ->
Power = DefauIt/Implicit or PE_SNK_Hard_Reset Power = DefauIt/Implicit or Explicit Contract
Explicit Contract PD = Connected
PD = Connected

Message not sent after retries (no GoodCRC received)1 |

Soft Reset message Protocol error detected on Source Port
received
1
Excludes Soft Reset itself.
2
Type-C Ports acting as Source will have Rp asserted and are either Providers or Provider/Consumers. Therefore they will not go to the
PE_SNK_Hard_Reset state.

8.3.3.4.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 is detected by the Protocol
Layer (see Section 6.7.1) or when a Message has not been sent after retries to the Sink. 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
(without GoodCRC) and the source is not presently attached (as indicated in Figure 8-38). In this case, the
PE_SRC_Discovery state is entered (see Section 8.3.3.2.3).
 During a Power Role Swap when the power supply is in transition (see Sections 8.3.3.6.3.1 and 8.3.3.6.3.2). In this
case a hard reset will be triggered directly.
 During a Data Role Swap when the DFP/UFP roles are changing. In this case Type-C error recovery will be
triggered directly.
On entry to the PE_SRC_Send_Soft_Reset state the Policy Engine shall request the Protocol Layer to perform a Soft
Reset, then shall send a Soft_Reset Message to the Sink, 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.
The Policy Engine shall transition to the PE_SRC_Hard_Reset or PE_SNK_Hard_Reset state depending on its default
role as either a Source or Sink Port (see Section 6.7.2) when:
 A SenderResponseTimer timeout occurs.
 Or the Protocol Layer indicates that a transmission error has occurred.
The decision as to whether to go to PE_SRC_Hard_Reset or PE_SNK_Hard_Reset shall depend on the type of device:
 The Source Port in a Provider or Provider/Consumer shall go to PE_SRC_Hard_Reset.
 The Source Port in a Type-B Consumer/Provider shall go to PE_SNK_Hard_Reset i.e. revert to USB Default
Operation as Sink Port.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 393
 8.3.3.4.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 from the Protocol
Layer.
On entry to the PE_SRC_Soft_Reset state the Policy Engine shall reset the Protocol Layer and shall then request the
Protocol Layer to send an Accept Message.
The Policy Engine shall transition to the PE_SRC_Send_Capabilities state (see Section 8.3.3.2.3) when:
 The Accept Message has been sent.
The Policy Engine shall transition to the PE_SRC_Hard_Reset or PE_SNK_Hard_Reset state depending on its default
role as either a Source or Sink Port (see Section 6.7.2) when:
 The Protocol Layer indicates that a transmission error has occurred.
The decision as to whether to go to PE_SRC_Hard_Reset or PE_SNK_Hard_Reset shall depend on the type of device:
 The Source Port in a Provider or Provider/Consumer shall go to PE_SRC_Hard_Reset.
 The Source Port in a Consumer/Provider shall go to PE_SNK_Hard_Reset i.e. revert to USB Default Operation as
Sink Port.

8.3.3.4.2 Sink Port Soft Reset State Diagram

Figure 8-41 below shows the state diagram for the Policy Engine in a Sink Port when performing a Soft Reset of its
Port Partner. The following sections describe operation in each of the states.

Figure 8-41 Sink Port Soft Reset Diagram

Accept message
PE_SNK_Wait_for_Capabilities received

Accept message
sent
Hard Reset: SenderResponseTimer
PE_SNK_Soft_Reset Timeout |
Transmission error
Transmission error
PE_SNK_Send_Soft_Reset
indication from  Consumer or
Actions on entry: Indication from Actions on entry:
Reset Protocol Layer
Protocol Layer Consumer/Provider2 -> Protocol Layer Reset Protocol Layer
Send Accept message PE_SNK_Hard_Reset Send Soft Reset message
Power = Default/Implicit or
 Provider/Consumer in Initialize and run SenderResponseTimer
Explicit Contract Sink role ->
Power = DefauIt/Implicit or Explicit
PD = Connected PE_SRC_Hard_Reset
Contract
PD = Connected

Soft Reset message

Message not sent after retries
received
(no GoodCRC received)1 |
Protocol error detected on Sink Port
1
Excludes Soft Reset itself.
2
Type-C Ports acting as Sinks will have Rd asserted and are either Consumers or Consumer/Providers. Therefore they will not go to the
PE_SRC_Hard_Reset state.

8.3.3.4.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 is detected by the Protocol
Layer (see Section 6.7.1) or when a Message has not been sent after retries to the Source. The main exceptions to this
rule are when:

Page 394 USB Power Delivery Specification Revision 2.0, Version 1.1
 During a Power Role Swap when the power supply is in transition (see Sections 8.3.3.6.3.1 and 8.3.3.6.3.2). In this
case a hard reset will be triggered directly.
 During a Data Role Swap when the DFP/UFP roles are changing. In this case Type-C error recovery will be
triggered directly.
On entry to the PE_SNK_Send_Soft_Reset state the Policy Engine shall request the Protocol Layer to perform a Soft
Reset, then shall send a Soft_Reset Message 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.
The Policy Engine shall transition to the PE_SRC_Hard_Reset or PE_SNK_Hard_Reset state when:
 A SenderResponseTimer timeout occurs.
 Or the Protocol Layer indicates that a transmission error has occurred.
The decision as to whether to go to PE_SRC_Hard_Reset or PE_SNK_Hard_Reset shall depend on the type of device:
 The Sink Port in a Provider/Consumer shall go to PE_SRC_Hard_Reset.
 The Sink Port in a Consumer or Consumer/Provider shall go to PE_SNK_Hard_Reset i.e. revert to USB Default
Operation as Sink Port.

8.3.3.4.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 from the Protocol
Layer.
On entry to the PE_SNK_Soft_Reset state the Policy Engine shall reset the Protocol Layer and shall then request the
Protocol Layer to send an Accept Message.
The Policy Engine shall transition to the PE_SNK_Wait_for_Capabilities state when:
 The Accept Message has been sent.
The Policy Engine shall transition to the PE_SRC_Hard_Reset or PE_SNK_Hard_Reset state depending on its default
role as either a Source or Sink Port (see Section 6.7.2) when:
 The Protocol Layer indicates that a transmission error has occurred.
The decision as to whether to go to PE_SRC_Hard_Reset or PE_SNK_Hard_Reset shall depend on the type of device:
 The Sink Port in a Type-A Provider/Consumer shall go to PE_SRC_Hard_Reset.
 The Sink Port in a Consumer or Consumer/Provider shall go to PE_SNK_Hard_Reset i.e. revert to USB Default
Operation as Sink Port.

8.3.3.5 Source Port Ping State Diagram

Figure 8-42 shows the state diagram for a Ping Message from a Source Port. Note: Pings are optional under certain
operating conditions (see Section 6.3.5).

Figure 8-42 Source Port Ping State Diagram

SourceActivityTimer
PE_SRC_Ping timeout

Actions on entry:
PE_SRC_Transition_Supply
Send Ping message Or
Ping message sent PE_SRC_Ready
Power = Transition/Explicit
Contract
PD = connected

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 395
 8.3.3.5.1 PE_SRC_Ping state
On entry to the PE_SRC_Ping state (from the PE_SRC_Transition_Supply or PE_SRC_Ready states) the Policy Engine
shall request the Protocol Layer to send a Ping Message.
The Policy Engine shall transition back to the previous state (PE_SRC_Transition_Supply or PE_SRC_Ready) state (see
Figure 8-38) when:
 The Ping Message has been successfully sent.
On re-entry to the PE_SRC_Transition_Supply or PE_SRC_Ready states the Policy Engine shall not perform any of the
“Actions on Entry” except for initializing and running the SourceActivityTimer.

8.3.3.6 Dual-Role Port State Diagrams

Dual-Role Ports that combine Source and Sink capabilities 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.

8.3.3.6.1 Type-A/B Dual-Role State Diagrams

The State Diagrams in this section shall apply to all Type-A/B Dual-Role Ports.

8.3.3.6.1.1 Type-A/B Dual-Role (initially Source Port) Ping State Diagram

Figure 8-43 shows the state diagram for a Dual-Role Port which is initially a Source Port. Note: Pings are optional
under certain operating conditions (see Section 6.3.5 ).

Figure 8-43 Dual-Role (initially Source Port) Ping State Diagram

SourceActivityTimer
PE_PRS_SRC_SNK_Ping timeout
Ping message not sent after retries
(no GoodCRC received) Actions on entry: PE_PRS_SRC_SNK_
PE_SRC_Hard_Reset Send Ping message Ping message sent Transition_to_off
Power = Transition
PD = connected

8.3.3.6.1.1.1 PE_PRS_SRC_SNK_Ping state

The Policy Engine shall transition to the PE_PRS_SRC_SNK_Ping state, from the PE_PRS_SRC_SNK_Transition_to_off
state, due to a SourceActivityTimer timeout.
On entry to the PE_PRS_SRC_SNK_Ping state the Policy Engine shall request the Protocol Layer to send a Ping
Message.
The Policy Engine shall transition back to the PE_PRS_SRC_SNK_Transition_to_off state (see Figure 8-51) when:
 The Ping Message has been successfully sent.
The Policy Engine shall transition to the PE_SRC_Hard_Reset when:
 The Ping Message has not been sent after retries (a GoodCRC Message has not been received). A soft reset
shall not be initiated in this case.

8.3.3.6.1.2 Type-A/B Dual-Role (initially Sink Port) Ping State Diagram

Figure 8-44 shows the state diagram for a Dual-Role Port which is initially a Sink Port. Note: Pings are optional under
certain operating conditions (see Section 6.3.5).

Page 396 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 8-44 Dual-Role (initially Sink Port) Ping State Diagram

SourceActivityTimer
PE_PRS_SNK_SRC_Ping timeout
Ping message not sent after retries
(no GoodCRC received) Actions on entry: PE_PRS_SNK_SRC_
PE_SNK_Hard_Reset Ping message sent Source_on
Send Ping message

Power = Transition
PD = connected

8.3.3.6.1.2.1 PE_PRS_SNK_SRC_Ping state

The Policy Engine shall transition to the PE_PRS_SNK_SRC_Ping state, from the PE_PRS_SNK_SRC_Source_on state, due
to a SourceActivityTimer timeout.
On entry to the PE_PRS_SNK_SRC_Ping state from the PE_PRS_SNK_SRC_Source_on state the Policy Engine shall
request the Protocol Layer to send a Ping Message.
The Policy Engine shall transition back to the PE_PRS_SNK_SRC_Source_on state (see Figure 8-52) when:
 The Ping Message has been successfully sent.
The Policy Engine shall transition to the PE_SNK_Hard_Reset state when:
 The Ping Message has not been sent after retries (a GoodCRC Message has not been received). A soft reset
shall not be initiated in this case.

8.3.3.6.1.3 Type-A/B Hard Reset of Policy Engine in a Provider/Consumer in Sink Role

Figure 8-45 shows the state diagram in the case where a Provider/Consumer with a Port operating in Sink Role is
required to perform a Hard Reset.

Figure 8-45 State Diagram for Hard Reset of P/C in Sink Role

Hard reset signalling received

PE_PC_SNK_Swap_Recovery
Actions on entry: SwapRecoveryTimer
Initialize and run SwapRecoveryTimer timeout
PE_SRC_Transition_to_default
Power = DefauIt (5V) or
((SinkWaitCapTimer timeout | Implicit/Explicit Contract
SinkActivityTimer timeout | PD = Connected/not Connected
PSTransitionTimer timeout |
NoResponseTimer timeout) &
(HardResetCounter ≤ nHardResetCount)) | Hard Reset complete
Hard Reset request from
Device Policy Manager
PE_PC_SNK_Hard_Reset
Actions on entry:
Generate Hard Reset signalling.
Increment HardResetCounter.
Power = DefauIt (5V) or
Implicit/Explicit Contract
PD = Connected/not Connected

8.3.3.6.1.3.1 PE_PC_SNK_Hard_Reset state

The Policy Engine shall transition to the PE_PC_SNK_Hard_Reset state for a Provider/Consumer Port in Sink Role from
any state when:
 ((SinkWaitCapTimer timeout |
 SinkActivityTimer timeout |

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 397
 PSTransitionTimer timeout |
 NoResponseTimer timeout) &
 (HardResetCounter ≤ nHardResetCount)) |
 Hard Reset request from Device Policy Manager
The Policy Engine shall transition to the PE_PC_SNK_Swap_Recovery state when:
 The Hard Reset is complete.
8.3.3.6.1.3.2 PE_PC_SNK_Swap_Recovery state
The Policy Engine shall transition to the PE_PC_SNK_Swap_Recovery state from any state when:
 Hard Reset Signaling is received.
On entry to the PE_PC_SNK_Swap_Recovery state the Policy Engine shall initialize and run the SwapRecoveryTimer.
The Policy Engine shall transition to the PE_SRC_Transition_to_default state for a Source Port when:
 The SwapRecoveryTimer times out.

8.3.3.6.1.4 Type-A/B Hard Reset of Policy Engine in a Consumer/Provider in Source Role

Figure 8-46 shows the state diagram in the case where a Consumer/Provider with a Port operating in Source Role is
required to perform a Hard Reset.

Figure 8-46 State Diagram for the Hard Reset of a C/P in Source Role

Hard reset signalling received

PE_CP_SRC_Transition_to_off

Actions on entry: Source turned off

Tell Device Policy Manager to turn off PE_SNK_Transition_to_default
Power Supply

Power = Transition to stop sourcing

PD = Connected/not Connected

(NoResponseTimer timeout &

HardResetCounter ≤ nHardResetCount) |
Hard reset complete
Hard Reset request from
Device Policy Manager

PE_CP_SRC_Hard_Reset
Actions on entry:
Generate Hard Reset signalling
Increment HardResetCounter

Power = DefauIt (5V) or

Implicit/Explicit Contract
PD = Connected/not Connected

8.3.3.6.1.4.1 PE_CP_SRC_Hard_Reset state

The Protocol Engine shall transition from any state to the PE_CP_SRC_Hard_Reset state for a Consumer/Provider in
Source Role when
 The NoResponseTimer times out and the HardResetCounter ≤ nHardResetCount or
 The Device Policy Manager requests a Hard Reset.
The Policy Engine shall transition to the PE_CP_SRC_Transition_to_off state when:
 The Hard Reset is complete.

Page 398 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.6.1.4.2 PE_CP_SRC_Transition_to_off state
The Policy Engine shall transition from any state to the PE_CP_SRC_Transition_to_off state for a Consumer/Provider
in Source Role when:
 Hard Reset Signaling is detected.
On entry to the PE_CP_SRC_Transition_to_off state the Policy Engine shall tell the Device Policy Manager to turn off
the power supply.
The Policy Engine shall transition to the PE_SNK_Transition_to_default when:
 The power supply has been turned off.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 399
 8.3.3.6.1.5 Type-A/B Consumer/Provider Dead Battery/Power Loss State Diagram
Figure 8-47 shows the additional state diagram required for a Consumer/Provider to handle Dead Battery detection.
After the Consumer/Provider Policy Engine has transitioned to the PE_SRC_Send_Capabilities state, its subsequent
state operation shall conform to that of a Consumer/Provider which has completed a Power Role Swap (see Section
8.3.3.6.3.2). The Consumer/Provider has effectively undergone a Power Role Swap without the requirement of
protocol negotiation. The Consumer/Provider will not respond to received Source_Capabilities Messages until it
transitions to the PE_SNK_Wait_for_Capabilities state.

Figure 8-47 Consumer/Provider Dead Battery/Power Loss State Diagram

PE_SNK_Startup

Protocol Layer Reset

PE_DB_CP_Check_
for_VBUS
DBSourceOffTimer timeout Actions on entry: VBUS > vSafe0V
Initialize and run DBDetectTimer PE_SNK_Wait_for_Capabilities
Stop NoResponseTimer
Power = Default
PD = unknown

DBDetectTimer timeout &

VBUS within vSafe0V

PE_DB_CP_PS_ PE_DB_CP_Power_
Discharge VBUS_DB
Actions on entry: Actions on entry:
Initialize and run Tell Device Policy Manager
DBSourceOffTimer apply vSafeDB to VBUS
Power=unknown Power=transition
PD = unknown PD = unknown

vSafe0V applied to VBUS vSafeDB on VBUS

PE_DB_CP_Unpower_ PE_DB_CP_Wait_for_
VBUS Bit StreamDetectTimer Bit_Stream
Timeout Actions on entry:
Actions on entry:
Initialize and run
Tell Device Policy Manager
BitStreamDetectTimer
apply vSafe0V to VBUS
Power=vSafeDB
Power=vSafeDB or vSafe5V PD = unknown
PD = unknown
Bit Stream detected
by PHY

PE_DB_CP_Power_
VBUS_5V
Actions on entry:
Tell Device Policy Manager to apply
vSafe5V to VBUS

Power=vSafeDB or vSafe5V
PD = not Connected

vSafe5V on VBUS

PE_DB_CP_Wait_
DeviceReadyTimer Bit_Stream_Stop
Timeout
Actions on entry:
Initialize and run DeviceReadyTimer
Power=vSafe5V
PD = not Connected

Bit Stream stopped

Indication from PHY

PE_SRC_Send_Capabilities

Page 400 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.6.1.5.1 PE_DB_CP_Check_for_VBUS state
The Policy Engine for a Consumer/Provider shall initially start in the PE_SNK_Startup state. Once the Protocol Layer
has been reset it shall transition to the PE_DB_CP_Check_for_VBUS state.
On entry to the PE_DB_CP_Check_for_VBUS state the Policy Engine shall initialize and run the DBDetectTimer and
stop the NoResponseTimer.
The Policy Engine shall transition to the PE_SNK_Wait_for_Capabilities state when:
 VBUS is greater than vSafe0V.
The Policy Engine shall transition to the PE_DB_CP_Power_VBUS_DB state when:
 The DBDetectTimer has timed out and
 VBUS is within vSafe0V.
8.3.3.6.1.5.2 PE_DB_CP_Power_VBUS_DB state
On entry to the PE_DB_CP_Power_VBUS_DB state the Policy Engine shall tell the Device Policy Manager to apply
vSafeDB to VBUS.
The Policy Engine shall transition to the PE_DB_CP_Wait_For_Bit_Stream state when:
 vSafeDB is on VBUS.
8.3.3.6.1.5.3 PE_DB_CP_Wait_For_Bit_Stream state
On entry to the PE_DB_CP_Wait_For_Bit_Stream state the Policy Engine shall initialize and run the
BitStreamDetectTimer.
The Policy Engine shall transition to the PE_DB_CP_Power_VBUS_5V state when:
 The PHY Layer indicates that Bit Stream signaling has been received.
The Policy Engine shall transition to the PE_DB_CP_Unpower_VBUS state when:
 The BitStreamDetectTimer times out.
8.3.3.6.1.5.4 PE_DB_CP_Power_VBUS_5V state
On entry to the PE_DB_CP_Power_VBUS_5V state the Policy Engine shall request the Device Policy Manager to apply
vSafe5V to VBUS.
The Policy Engine shall transition to the PE_DB_CP_Wait_Bit_Stream_Stop state when:
 vSafe5V is present on VBUS.
8.3.3.6.1.5.5 PE_DB_CP_Wait_Bit_Stream_Stop state
On entry to the PE_DB_CP_Wait_Bit_Stream_Stop state the Policy Engine shall initialize and run the
DeviceReadyTimer.
The Policy Engine shall transition to the PE_SRC_Send_Capabilities state when:
 An indication is received from the PHY Layer that the Bit Stream has stopped.
The Policy Engine shall transition to the PE_DB_CP_Unpower_VBUS state when:
 The DeviceReadyTimer times out.
8.3.3.6.1.5.6 PE_DB_CP_Unpower_VBUS state
On entry to the PE_DB_CP_Unpower_VBUS state the Policy Engine shall tell the Device Policy Manager to apply
vSafe0V to VBUS.
The Policy Engine shall transition to the PE_DB_CP_PS_Discharge state when:

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 401
 vSafe0V has been applied to VBUS.
Note: the intention of applying vSafe0V is that the Consumer/Provider will utilize the same mechanism to unpower
VBUS as it uses to remove VBUS power during a Power Role Swap.
8.3.3.6.1.5.7 PE_DB_CP_PS_Discharge state
On entry to the PE_DB_CP_PS_Discharge state the Policy Engine shall initialize and run the DBSourceOffTimer.
The Policy Engine shall transition to the PE_DB_CP_Check_for_VBUS state when:
 The DBSourceOffTimer times out.
Note: the DBSourceOffTimer is used to ensure that the Consumer/Provider is not powering VBUS when it proceeds to
check the voltage on VBUS. This assumes that the discharge of VBUS follows the same process as when removing power
during a Power Role Swap.

Page 402 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.6.1.6 Type-A/B Provider/Consumer Dead Battery/Power Loss State Diagram
Figure 8-48 shows the additional state diagram required for a BFSK Provider/Consumer to handle Dead Battery
detection. The Provider/Consumer is assumed to startup in a state where it is either powered off or is unable to
power its Port (e.g. due to a Dead Battery). If the Provider/Consumer is powered on and has sufficient power to
power it’s Port it should start up as a Source Port.

Figure 8-48 BFSK Provider/Consumer Dead Battery/Power Loss State Diagram

Start
vSafe0V present on VBUS &
P/C powered off or unable to operate

PE_DB_PC_Unpowered
Actions on entry:
Waiting for vSafeDB in order to
operate dead battery detection
Ensure Bit Stream is off within
tBit StreamOff

Power=vSafe0V
PD = attached/unattached

vSafeDB present on VBUS |

P/C Ready to Power VBUS

PE_DB_PC_Check_
Power Willing to
Doesn’t want Actions on entry: power port
to be powered Decide if able/willing to power PE_SRC_Transition_to_Default
port

Power=vSafeDB
PD = attached

Wants to be
powered

PE_DB_PC_Send_Bit_Stream
Actions on entry:
Request PHY to start sending Bit
Stream (within tSendBit Stream of VBUS
detection).

Power = vSafeDB
PD = attached

Bit Stream being sent

PE_DB_PC_Wait_to_Detect
Actions on entry:
Initialize and run WaitForPowerTimer

Power = vSafeDB or vSafe5V

PD = attached

WaitForPowerTimer timeout

PE_DB_PC_Wait_to_start
Actions on entry:
Wait for Policy Engine to be ready to
negotiate Capabilities
Actions on exit:
Request PHY to stop Bit Stream
Power=vSafe5V
PD = attached

Policy Engine ready for Capabilities

PE_SNK_Wait_for_Capabilities

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 403
 8.3.3.6.1.6.1 PE_DB_PC_Unpowered state
The PE_DB_PC_Unpowered state is the startup state for a Provider/Consumer at power up when either there is no
power to the Provider/Consumer (in this case there may be no physical “state” as such) or when the
Provider/Consumer has some sort of power supply but is inactive.
The PE_DB_PC_Unpowered state shall be entered from any state when:
 VBUS is within vSafe0V and
 The Provider/Consumer is powered off or has insufficient power to operate.
On entry to the PE_DB_PC_Unpowered state the Policy Engine shall wait for vSafeDB to appear on VBUS in order to
start the Dead Battery detection process. If a Bit Stream is currently being transmitted then this shall be stopped
within tBitStreamOff of vSafe0V appearing on VBUS.
The Policy Engine shall transition to the PE_DB_PC_Check_Power state when:
 vSafeDB is present on VBUS,.or
 The Provider/Consumer is ready to power VBUS
8.3.3.6.1.6.2 PE_DB_PC_Check_Power state
On entry to the PE_DB_PC_Check_Power state the Policy Engine shall decide whether it is able and willing to supply
power to the Port.
The Policy Engine shall transition to the PE_SRC_Transition_to_default state when:
 It is willing to power VBUS.
The Policy Engine shall transition to the PE_DB_PC_Send_Bit_Stream state when:
 It wants to be powered by the Consumer/Provider.
The Policy Engine shall stay in the PE_DB_PC_Check_Power state when:
 The Provider/Consumer does not want to either power the Port or be powered.
8.3.3.6.1.6.3 PE_DB_PC_Send_Bit_Stream state
On entry to the PE_DB_PC_Send_Bit_Stream state the Policy Engine shall request the PHY Layer to start sending the
Bit Stream (see Section 4.1.1).
The Policy Engine shall transition to the PE_DB_PC_Wait_to_Detect state when:
 The Bit Stream is being sent.
8.3.3.6.1.6.4 PE_DB_PC_Wait_to_Detect state
On entry to the PE_DB_PC_Wait_to_Detect state the Policy Engine shall initialize and run the WaitForPowerTimer to
allow the Consumer/Provider time to detect the Bit Stream and apply power to V BUS.
The Policy Engine shall transition to the PE_DB_PC_Wait_to_Start state when:
 The DeadBatteryTimer times out.
8.3.3.6.1.6.5 PE_DB_PC_Wait_to_Start state
On entry to the PE_DB_PC_Wait_to_Start state the Policy Engine shall wait until it is ready to negotiate Capabilities.
On exit from the PE_DB_PC_Wait_to_Start state the Policy Engine shall request the PHY Layer to stop sending the Bit
Stream.
The Policy Engine shall transition to the PE_SNK_Wait_for_Capabilities state when:
 The Policy Engine is ready to negotiate Capabilities.

Page 404 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.6.2 Type-C DR_Swap State Diagrams
The State Diagrams in this section shall apply to all Dual-Role Ports that are [USBType-C 1.0] DRPs.

8.3.3.6.2.1 Type-C Policy Engine in DFP to UFP Data Role Swap State Diagram
Figure 8-49 shows the additional state diagram required to perform a Data Role Swap from Type-C DFP to UFP
operation and the changes that shall be followed for error and Hard Reset handling.

Figure 8-49: Type-C DFP to UFP Data Role Swap State Diagram

DR_Swap message received &

in Modal Operation
PE_SRC_Hard_Reset or
PE_SNK_Hard_Reset PE_SRC_Ready or
PE_SNK_Ready
(DFP)

Data Role Swap required

(indication from Reject message received |
Message sent Device Policy Manager)Wait message received |
DR_Swap message received & SenderResponseTimer
not in Modal Operation timeout

PE_DRS_DFP_UFP_ PE_DRS_DFP_UFP_
Reject_DR_Swap Data Role Swap not ok | PE_DRS_DFP_UFP_
Further evaluation
Evaluate_DR_Swap Send_DR_Swap
Actions on entry: required Actions on entry:
Send Reject or Wait message Get evaluation of Data Role Swap Actions on entry:
as appropriate request from Device Policy Manager Send Swap DR message
Initialize and run
Power = Explicit Contract SenderResponseTimer
Power = Explicit Contract
PD = Connected
PD = Connected
Power = Explicit Contract
PD = Connected
Data Role Swap ok
Accept received
PE_DRS_DFP_UFP_
Accept_DR_Swap
Actions on entry:
Send Accept message

Power = Explicit Contract

PD = Connected

Accept message
sent

PE_DRS_DFP_UFP_
Change_to_UFP
Actions on entry:
Request Device Policy Manager to
change port to UFP
Power = Explicit Contract
PD = Connected

Port changed to UFP

PE_SRC_Ready or
PE_SNK_Ready
(UFP)

8.3.3.6.2.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_DR_Swap state when:
 A DR_Swap Message is received and
 There are no Active Modes (not in Modal Operation).

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 405
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_DR_Swap state when:

 The Device Policy Manager indicates that a Data Role Swap is required.
8.3.3.6.2.1.2 PE_DRS_DFP_UFP_Evaluate_DR_Swap state
On entry to the PE_DRS_DFP_UFP_Evaluate_DR_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_DR_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_DR_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.
8.3.3.6.2.1.3 PE_DRS_DFP_UFP_Accept_DR_Swap state
On entry to the PE_DRS_DFP_UFP_Accept_DR_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.
8.3.3.6.2.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 Type-C Port has been changed to a UFP.
8.3.3.6.2.1.5 PE_DRS_DFP_UFP_Send_DR_Swap state
On entry to the PE_DRS_DFP_UFP_Send_DR_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_DFP_UFP_Send_DR_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.
8.3.3.6.2.1.6 PE_DRS_DFP_UFP_Reject_DR_Swap state
On entry to the PE_DRS_DFP_UFP_Reject_DR_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.

Page 406 USB Power Delivery Specification Revision 2.0, Version 1.1
 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 6.3.12.3).
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.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 407
 8.3.3.6.2.2 Type-C Policy Engine in UFP to DFP Data Role Swap State Diagram
Figure 8-50 shows the additional state diagram required to perform a Data Role Swap from Type-C DRP UFP to DFP
operation and the changes that shall be followed for error and Hard Reset handling.

Figure 8-50: Type-C UFP to DFP Data Role Swap State Diagram

DR_Swap message received &

PE_SRC_Hard_Reset or in Modal Operation
PE_SNK_Hard_Reset

PE_SRC_Ready or
PE_SNK_Ready
(UFP)
Reject message received |
Wait message received |
SenderResponseTimer
timeout
DR_Swap message received & Data Role Swap required
not in Modal Operation (indication from
Message sent Device Policy Manager)

PE_DRS_UFP_DFP_ PE_DRS_UFP_DFP_ PE_DRS_UFP_DFP_

Reject_DR_Swap Evaluate_DR_Swap Send_DR_Swap
Data Role Swap not ok |
Further evaluation Actions on entry:
Actions on entry: Actions on entry:
required Get evaluation of Data Role Swap
Send Reject or Wait message Send Swap DR message
request from Device Policy Manager
as appropriate Initialize and run
SenderResponseTimer
Power = Explicit Contract
Power = Explicit Contract
PD = Connected Power = Explicit Contract
PD = Connected
PD = Connected
Data Role Swap ok

PE_DRS_UFP_DFP_ Accept received

Accept_DR_Swap
Actions on entry:
Send Accept message

Power = Explicit Contract

PD = Connected

Accept message
sent

PE_DRS_UFP_DFP_
Change_to_DFP
Actions on entry:
Request Device Policy Manager to
change port to DFP

Power = Explicit Contract

PD = Connected

Port changed to DFP

PE_SRC_Ready or
PE_SNK_Ready
(DFP)

8.3.3.6.2.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_DR_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:

Page 408 USB Power Delivery Specification Revision 2.0, Version 1.1
 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_DR_Swap state when:
 The Device Policy Manager indicates that a Data Role Swap is required.
8.3.3.6.2.2.2 PE_DRS_UFP_DFP_Evaluate_DR_Swap state
On entry to the PE_DRS_UFP_DFP_Evaluate_DR_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_DR_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_DR_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.
8.3.3.6.2.2.3 PE_DRS_UFP_DFP_Accept_DR_Swap state
On entry to the PE_DRS_UFP_DFP_Accept_DR_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.
8.3.3.6.2.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 Type-C Port has been changed to a DFP.
8.3.3.6.2.2.5 PE_DRS_UFP_DFP_Send_DR_Swap state
On entry to the PE_DRS_UFP_DFP_Send_DR_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_DR_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.
 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.
8.3.3.6.2.2.6 PE_DRS_UFP_DFP_Reject_DR_Swap state
On entry to the PE_DRS_UFP_DFP_Reject_DR_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 6.3.12.3).

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 409
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.

8.3.3.6.3 Common Dual-Role Port State Diagrams

The State Diagrams in this section shall apply to all Dual-Role Ports: both Type-A/B and [USBType-C 1.0] DRP.

Page 410 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.6.3.1 Policy Engine in Source to Sink Power Role Swap State Diagram
Dual-Role Ports that combine Source and Sink capabilities 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 8-51 shows the additional state diagram required to perform a Power Role Swap from Source to Sink roles and
the changes that shall be followed for error and Hard Reset handling.

Figure 8-51: Dual-Role Port in Source to Sink Power Role Swap State Diagram

Message sent
PE_SRC_Ready
Reject message received |
Wait message received |
PR_Swap message received Power Role Swap required SenderResponseTimer
(indication from timeout
Device Policy Manager)
PE_PRS_SRC_SNK_ PE_PRS_SRC_SNK_
Reject_PR_Swap Power Role Swap not ok | Evaluate_Swap
Further evaluation
Actions on entry: required Actions on entry: PE_PRS_SRC_SNK_
Send Reject or Wait message Get evaluation of swap request from Send_Swap
as appropriate Device Policy Manager
Actions on entry:
Power = Explicit Contract Power = Explicit Contract Send PR_Swap message
PD = Connected PD = Connected Initialize and run
SenderResponseTimer
Power Role Swap ok
Power = Explicit Contract
Accept received
PD = Connected
PE_PRS_SRC_SNK_
Accept_Swap
Actions on entry:
Send Accept message
Power = Explicit Contract
PD = Connected

Accept message
sent

PE_PRS_SRC_SNK_
Transition_to_off PE_PRS_SRC_SNK_
Source turned off &
Assert_Rd
Actions on entry:
Wait tSrcTransition and tell Device Policy Type-C DRP Actions on entry:
ErrorRecovery Manager to turn off power supply Request DPM to assert Rd
Start SourceActivityTimer (see Section
8.3.3.6.1.1)1 Power = Source off
PD = Connected
Power = Transition to stop sourcing
PD = Connected

Source turned off &

(PSSourceOnTimer Timeout | not Type-C DRP
PS_RDY message not sent after retries
(no GoodCRC received)) & Rd asserted
Type-C DRP
PE_PRS_SRC_SNK_
Wait_Source_on
Actions on entry:
(PSSourceOnTimer Timeout | Send PS_RDY message
PS_RDY message not sent after retries Initialize and run PSSourceOnTimer
(no GoodCRC received)) &
not Type-C DRP Power = Source off
PD = Connected
Hard Reset:
PS_RDY message
received
 Consumer/Provider ->
PE_SNK_Hard_Reset
 Provider/Consumer ->
PE_SRC_Hard_Reset PE_SNK_Startup

1
When operating at vSafe5V and not swapped, or when two systems both using the Type-C connector are communicating, Ping messages are optional so the SourceActivityTimer is not required to run
in these circumstances.

8.3.3.6.3.1.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_PR_Swap state when:

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 411
 A PR_Swap Message is received.
The Policy Engine shall transition to the PE_PRS_SRC_SNK_Send_PR_Swap state when:
 The Device Policy Manager indicates that a Power Role Swap is required.
8.3.3.6.3.1.2 PE_PRS_SRC_SNK_Evaluate_Swap state
On entry to the PE_PRS_SRC_SNK_Evaluate_PR_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_PR_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_PR_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.
8.3.3.6.3.1.3 PE_PRS_SRC_SNK_Accept_Swap state
On entry to the PE_PRS_SRC_SNK_Accept_PR_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.
8.3.3.6.3.1.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 wait tSrcTransition and then request
the Device Policy Manager to turn off the Source and shall initialize and run the SourceActivityTimer (see Section
8.3.3.6.1.1.1 for use of Ping messaging for Dual-Role Ports which are initially Source Ports).
The Policy Engine shall transition to the PE_PRS_SRC_SNK_Wait_Source_on state when:
 The Device Policy Manager indicates that the Source has been turned off and
 The Port is not a [USBType-C 1.0] DRP
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 and
 The Port is a [USBType-C 1.0] DRP
8.3.3.6.3.1.5 PE_PRS_SRC_SNK_Assert_Rd
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.
8.3.3.6.3.1.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.
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 PE_SRC_Hard_Reset or PE_SNK_Hard_Reset state depending on its default
role as either a Source or Sink Port (see Section 6.7.2) when:
Page 412 USB Power Delivery Specification Revision 2.0, Version 1.1
 The Port is not a [USBType-C 1.0] DRP and
 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.
The decision as to whether to go to PE_SRC_Hard_Reset or PE_SNK_Hard_Reset shall depend on the type of device:
 The Source Port in a Provider or Provider/Consumer shall go to PE_SRC_Hard_Reset.
 The Source Port in a Consumer/Provider shall go to PE_SNK_Hard_Reset i.e. revert to USB Default Operation as
Sink Port.
The Policy Engine shall transition to the ErrorRecovery state when:
 The Port is a [USBType-C 1.0] DRP and
 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.
8.3.3.6.3.1.7 PE_PRS_SRC_SNK_Send_Swap state
On entry to the PE_PRS_SRC_SNK_Send_PR_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_PR_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.
8.3.3.6.3.1.8 PE_PRS_SRC_SNK_Reject_Swap state
On entry to the PE_PRS_SRC_SNK_Reject_PR_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 6.3.12.2).
The Policy Engine shall transition to the PE_SRC_Ready when:
 The Reject or Wait Message has been sent.

8.3.3.6.3.2 Policy Engine in Sink to Source Power Role Swap State Diagram
Dual-Role Ports that combine Sink and Source capabilities 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 8-52 shows the additional state diagram required to perform a Power Role Swap from Sink to Source roles and
the changes that shall be followed for error and Hard Reset handling.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 413
 Figure 8-52: Dual-role Port in Sink to Source Power Role Swap State Diagram

Message sent
PE_SNK_Ready
Reject message received |
Power Role Swap required Wait message received |
PR_Swap message received SenderResponseTimer
(indication from
Device Policy Manager) timeout

PE_PRS_SNK_SRC_ PE_PRS_SNK_SRC_
Reject_Swap Power Role Swap not ok |
Evaluate_Swap
Further evaluation PE_PRS_SNK_SRC_
Actions on entry: required Actions on entry: Send_Swap
Send Reject or Wait message Get evaluation of swap request from
as appropriate Device Policy Manager Actions on entry:
Send PR_Swap message
Power = Explicit Contract Power = Explicit Contract Initialize and run
PD = Connected PD = Connected SenderResponseTimer

Power Role Swap ok Power = Explicit Contract

PD = Connected

PE_PRS_SNK_SRC_
Accept_Swap
Actions on entry:
Send Accept message Accept message
received
Power = Explicit Contract
PD = Connected

Accept message sent

PSSourceOffTimer timeout &

Type-C DRP PE_PRS_SNK_SRC_
Transition_to_off
Actions on entry:
PSSourceOffTimer timeout &
Initialize and run PSSourceOffTimer PE_PRS_SNK_SRC_
not Type-C DRP
Tell Device Policy Manager to turn off
Power Sink. Assert_Rp
PS_RDY message received &
Power = Transition to stop sinking Type-C DRP Actions on entry:
PD = Connected Request DPM to assert Rp
Hard Reset: Power = Source off
 Consumer/Provider -> PD = Connected
PS_RDY message received &
PE_SNK_Hard_Reset not Type-C DRP
ErrorRecovery  Provider/Consumer ->
PE_SRC_Hard_Reset

PE_PRS_SNK_SRC_
Rp asserted
Source_on
PS_RDY message not sent after retries Actions on entry:
(no GoodCRC received) & Tell Device Policy Manager to turn on
not Type-C DRP Source
Initialize and run SourceActivityTimer (see
Section 8.3.3.6.1.2)1

PS_RDY message not sent after retries Actions on exit:

(no GoodCRC received) & If exit is not due to a Ping message send
Type-C DRP PS_RDY message

Power = Transition to source on

PD = Connected

Source is on

PE_SRC_Startup

1
When operating at vSafe5V and not swapped, or when two systems both using the Type-C connector are communicating, Ping messages are optional so the SourceActivityTimer is not required to run
in these circumstances.

8.3.3.6.3.2.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_PR_Swap state when:
 A PR_Swap Message is received.
The Policy Engine shall transition to the PE_PRS_SNK_SRC_Send_PR_Swap state when:
 The Device Policy Manager indicates that a Power Role Swap is required.
8.3.3.6.3.2.2 PE_PRS_SNK_SRC_Evaluate_Swap state
On entry to the PE_PRS_SNK_SRC_Send_PR_Swap state the Policy Engine shall ask the Device Policy Manager whether
a Power Role Swap can be made.

Page 414 USB Power Delivery Specification Revision 2.0, Version 1.1
The Policy Engine shall transition to the PE_PRS_SNK_SRC_Accept_PR_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_PR_Swap state when:
 The Device Policy Manager indicates that a Power Role Swap is not ok.
8.3.3.6.3.2.3 PE_PRS_SNK_SRC_Accept_Swap state
On entry to the PE_PRS_SNK_SRC_Accept_PR_Swap state the Policy Engine shall request the Protocol Layer to send an
Accept Message.
The Policy Engine shall transition to the PE_PRS_SNK_SRC_Transition_to_off state when:
 The Accept Message has been sent.
8.3.3.6.3.2.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 PE_SRC_Hard_Reset or PE_SNK_Hard_Reset state depending on its default
role as either a Source or Sink Port (see Section 6.7.2) when:
 The PSSourceOffTimer times out and
 The Port is not a [USBType-C 1.0] DRP.
The decision as to whether to go to PE_SRC_Hard_Reset or PE_SNK_Hard_Reset shall depend on the type of device:
 The Source Port in a Provider or Provider/Consumer shall go to PE_SRC_Hard_Reset.
 The Source Port in a Consumer/Provider shall go to PE_SNK_Hard_Reset i.e. revert to USB Default Operation as
Sink Port.
The Policy Engine shall transition to the ErrorRecovery state when:
 The PSSourceOffTimer times out and
 The Port is a [USBType-C 1.0] DRP.

The Policy Engine shall transition to the PE_PRS_SNK_SRC_Source_on state when:

 A PS_RDY Message is received and
 This is not a [USBType-C 1.0] DRP
The Policy Engine shall transition to the PE_PRS_SNK_SRC_Assert_Rp state when:
 A PS_RDY Message is received and
 The Port is a [USBType-C 1.0] DRP
8.3.3.6.3.2.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.
8.3.3.6.3.2.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 and shall initialize and run the SourceActivityTimer (see Section 8.3.3.6.1.2.1 for details of Ping
messaging for Dual-Role ports which are initially Sink Ports).
On exit from the PE_PRS_SNK_SRC_Source_on state (except if the exit is due to a SourceActivityTimer timeout) the
Policy Engine shall send a PS_RDY Message.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 415
The Policy Engine shall transition to the PE_SRC_Startup state when:
 The Source Port has been turned on.
The Policy Engine shall transition to the PE_SRC_Hard_Reset or PE_SNK_Hard_Reset state depending on its default
role as either a Source or Sink Port (see Section 6.7.2) when:
 The Port is not a [USBType-C 1.0] DRP and
 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.
The decision as to whether to go to PE_SRC_Hard_Reset or PE_SNK_Hard_Reset shall depend on the type of device:
 The Source Port in a Provider or Provider/Consumer shall go to PE_SRC_Hard_Reset.
 The Source Port in a Consumer/Provider shall go to PE_SNK_Hard_Reset i.e. revert to USB Default Operation as
Sink Port.
The Policy Engine shall transition to the ErrorRecovery state when:
 The Port is a [USBType-C 1.0] DRP and
 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.
8.3.3.6.3.2.7 PE_PRS_SNK_SRC_Send_Swap state
On entry to the PE_PRS_SNK_SRC_Send_PR_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.
8.3.3.6.3.2.8 PE_PRS_SNK_SRC_Reject_Swap state
On entry to the PE_PRS_SNK_SRC_Reject_PR_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 6.3.12.2).
The Policy Engine shall transition to the PE_SNK_Ready state when:
 The Reject or Wait Message has been sent.

8.3.3.6.3.3 Dual-Role (Source Port) Get Source Capabilities State Diagram

Figure 8-53 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.3.

Page 416 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 8-53 Dual-Role (Source) Get Source Capabilities diagram

get source capabilities request PE_DR_SRC_Get_Source_Cap

from Device Policy Manager
PE_SRC_Ready Actions on entry:
Send Get_Source_Cap message
Source capabilities Initialize and run SenderResponseTimer
message received |
Actions on exit:
SenderResponseTimer
Pass source capabilities/outcome to
Timeout |
Device Policy Manager
Reject message received
Power = Explicit Contract
PD = Connected

8.3.3.6.3.3.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 send a Get_Source_Cap Message and
initialize and run 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 8-38) when:
 A Source_Capabilities Message is received
 Or SenderResponseTimer times out
 Or a Reject Message is received

8.3.3.6.3.4 Dual-Role (Source Port) Give Sink Capabilities State Diagram

Figure 8-54 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.4.1.1.3.

Figure 8-54 Dual-Role (Source) Give Sink Capabilities diagram

Get_Sink_Cap message
received PE_DR_SRC_Give_Sink_Cap
PE_SRC_Ready
Actions on entry:
Get present sink capabilities from Device Policy Manager
Sink Capabilities Send Capabilities message (based on Device Policy
message sent Manager response)
Power = Explicit Contract
PD = Connected

8.3.3.6.3.4.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 is received.
On entry to the PE_DR_SRC_Give_Sink_Cap state the Policy Engine shall request the present capabilities from the
Device Policy Manager and then send a Sink_Capabilities Message based on these capabilities.
The Policy Engine shall transition back to the PE_SRC_Ready state (see Figure 8-38) when:
 The Sink_Capabilities Message has been successfully sent.

8.3.3.6.3.5 Dual-Role (Sink Port) Get Sink Capabilities State Diagram

Figure 8-55 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.1.3.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 417
 Figure 8-55 Dual-Role (Sink) Get Sink Capabilities State Diagram

get sink capabilities request PE_DR_SNK_Get_Sink_Cap

from Device Policy Manager
PE_SNK_Ready Actions on entry:
Send Get_Sink_Cap message
Initialize and run
Sink capabilities SenderResponseTimer
message received |
Actions on exit:
SenderResponseTimer
Pass sink capabilities/outcome to
Timeout |
Device Policy Manager
Reject message received
Power = Explicit Contract
PD = Connected

8.3.3.6.3.5.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 send a Get_Sink_Cap Message and initialize and
run the SenderResponseTimer.
On exit from the PE_DR_SNK_Get_Sink_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_SNK_Ready state (see Figure 8-39 and Figure 8-44) when:
 A Source_Capabilities Message is received
 Or SenderResponseTimer times out
 Or a Reject Message is received

8.3.3.6.3.6 Dual-Role (Sink Port) Give Source Capabilities State Diagram

Figure 8-56 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.4.1.1.3.

Figure 8-56 Dual-Role (Sink) Give Source Capabilities State Diagram

Get_Source_Cap message
received
PE_SNK_Ready PE_DR_SNK_Give_Source_Cap
Actions on entry:
Request source capabilities from
Source Capabilities Device Policy Manager
message sent Send Capabilities message
Power = Explicit Contract
PD = Connected

8.3.3.6.3.6.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 present capabilities from the
Device Policy Manager and then send a Source_Capabilities Message based on these capabilities.
The Policy Engine shall transition back to the PE_SNK_Ready state (see Figure 8-39 and Figure 8-44) when:
 The Source_Capabilities Message has been successfully sent.

8.3.3.7 Type-C VCONN Swap State Diagram

The State Diagram in this section shall apply to [USBType-C 1.0] Ports that supply VCONN. Figure 8-57 shows the state
operation for a Type-C Port on sending or receiving a VCONN Swap request.

Page 418 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 8-57 VCONN Swap State Diagram

VCONN Swap required

(indication from
Device Policy Manager)

PE_SRC_Ready or
PE_SNK_Ready

Reject message received |

Wait message received |
Message sent SenderResponseTimer
VCONN_Swap message received timeout

PE_VCS_Send_Swap
PE_VCS_Reject_VCONN_Swap PE_VCS_Evaluate_Swap Actions on entry:
VCONN Swap not ok |
Further evaluation Actions on entry: Send VCONN_Swap message
Actions on entry: required Initialize and run
Get evaluation of VCONN swap
Send Reject or Wait message as SenderResponseTimer
request from Device Policy Manager
appropriate
Power = Explicit Contract
Power = Explicit Contract Power = Explicit Contract PD = Connected
PD = Connected PD = Connected
Accept received &
VCONN Swap ok Presently VCONN Source1
Accept received &
Not presently VCONN Source1
PE_VCS_Accept_Swap
Actions on entry:
Send Accept message
Power = Explicit Contract
PD = Connected
Accept message sent &
Not presently VCONN Source1
Accept message sent &
Presently VCONN Source1

PE_VCS_Wait_for_VCONN PE_VCS_Turn_On_VCONN
VCONNOnTimer Timeout Actions on entry: Actions on entry:
Start VCONNOnTimer Tell Device Policy Manager to turn on
VCONN
Power = Explicit Contract
PD = Connected Power = Explicit Contract
PD = Connected

PS_RDY message
received VCONN turned on

PE_VCS_Turn_Off_VCONN
PE_VCS_Send_PS_Rdy
Actions on entry:
Tell Device Policy Manager to turn off Actions on entry:
VCONN Send PS_RDY message

Power = Explicit Contract Power = Explicit Contract

PD = Connected PD = Connected

UFP VCONN is off

Hard Reset: PS_RDY message
sent

 Consumer/Provider ->
PE_SNK_Hard_Reset
PE_SRC_Ready or
 Provider/Consumer ->
PE_SNK_Ready
PE_SRC_Hard_Reset

1. A Port is presently the VCONN Source if it has the responsibility for supplying VCONN even if VCONN has been turned off.

8.3.3.7.1.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 V CONN Swap.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 419
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
 DFP current has VCONN turned on.
The Policy Engine shall transition to the PE_VCS_Turn_On_VCONN state when:
 An Accept Message is received and
 DFP current has VCONN turned off.
The Policy Engine shall transition back to either the PE_SRC_Ready or PE_SNK_Ready state for a DFP when:
 A Reject Message is received or
 A Wait Message is received or
 The SenderResponseTimer times out.

8.3.3.7.1.2 PE_VCS_Evaluate_Swap
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 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.

8.3.3.7.1.3 PE_VCS_ Accept_Swap

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 UFP’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 UFP’s VCONN is off.

8.3.3.7.1.4 PE_VCS_Reject_Swap
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. Note: in this case it is expected that
the DFP will send a VCONN_Swap Message at a later time.
The Policy Engine shall transition back to either the PE_SRC_Ready or PE_SNK_Ready state when:
 The Reject or Wait Message has been sent.

Page 420 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.7.1.5 PE_VCS_UFP_Wait_for_ VCONN
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.

8.3.3.7.1.6 PE_VCS_ Turn_Off_VCONN

On entry to the PE_VCS_Turn_Off_VCONN state the Policy Engine shall tell the Device Policy Manager to turn off V CONN.
The Policy Engine shall transition back to either the PE_SRC_Ready or PE_SNK_Ready state for a UFP when:
 The UFP’s VCONN is off.

8.3.3.7.1.7 PE_VCS_ Turn_On_VCONN

On entry to the PE_VCS_Turn_On_VCONN state the Policy Engine shall tell the Device Policy Manager to turn on V CONN.
The Policy Engine shall transition to the PE_VCS_Send_Ps_Rdy state when:
 The UFP’s VCONN is on.

8.3.3.7.1.8 PE_VCS_ Send_PS_Rdy

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 or PE_SNK_Ready state for a UFP when:
 The PS_RDY Message has been sent.

8.3.3.8 UFP Structured VDM State Diagrams

The State Diagrams in this section shall apply to all UFPs that support structured VDMs.

8.3.3.8.1 UFP Structured VDM Discover Identity State Diagram

Figure 8-58 shows the state diagram for a UFP in response to a Discover Identity Command.

Figure 8-58 UFP Structured VDM Discover Identity State Diagram

PE_UFP_VDM__Get_Identity_ PE_UFP_VDM__Get_Identity PE_UFP_VDM__Send_Identity

Actions on entry: NAK DPM says Actions on entry: Identity information Actions on entry:
Send Discover Identity NAK/BUSY Command NAK/BUSY Request Identity information from DPM from DPM Send Discover Identity ACK
response as requested
Power = Explicit Contract Power = Explicit Contract
Power = Explicit Contract PD = Connected PD = Connected
PD = Connected

Discover Identity ACK

Discover Identity NAK/BUSY Discover Identity
sent
sent request

PE_SRC_Ready or PE_SNK_Ready
(UFP)

8.3.3.8.1.1 PE_UFP_VDM_Get_Identity state

The Policy Engine transitions to the PE_UFP_VDM_Get_Identity state from either the PE_SRC_Ready or PE_SNK_Ready
state for a UFP when:

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 421
 A Structured VDM Discover Identity Command request is received from the DFP.
On entry to the PE_UFP_VDM_Get_Identity state the UFP shall request identity information from the Device Policy
Manager.
The Policy Engine shall transition to the PE_UFP_VDM_Send_Identity state when:
 Identity information is received from the Device Policy Manager.
The Policy Engine shall transition to the PE_UFP_VDM_Get_Identity_NAK state when:
 The Device Policy Manager indicates that the response to the Discover Identity request is NAK or BUSY.

8.3.3.8.1.2 PE_ UFP_VDM _Send_Identity state

On entry to the PE_UFP_VDM_Send_Identity state the UFP shall send the Structured VDM Discover Identity 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 Discover Identity ACK Command response has been sent.

8.3.3.8.1.3 PE_ UFP_VDM _Get_Identity_NAK

On entry to the PE_UFP_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 or PE_SNK_Ready state for a UFP when:
 The Structured VDM Discover Identity NAK or BUSY Command response has been sent.

8.3.3.8.2 UFP Structured VDM Discover SVIDs State Diagram

Figure 8-59 shows the state diagram for a UFP in response to a Discover SVIDs Command.

Figure 8-59 UFP Structured VDM Discover SVIDs State Diagram

PE_UFP_VDM__Get_SVIDs_NAK PE_UFP_VDM__Get_SVIDs PE_UFP_VDM__Send_SVIDs

Actions on entry: DPM says Actions on entry: SVIDs information Actions on entry:
Send Discover SVIDs NAK/BUSY Command NAK/BUSY Request SVIDs information from DPM from DPM Send Discover SVIDs ACK
response as requested
Power = Explicit Contract Power = Explicit Contract
Power = Explicit Contract PD = Connected PD = Connected
PD = Connected

Discover SVIDs ACK

Discover SVIDs NAK/BUSY Discover SVIDs
sent
sent request

PE_SRC_Ready or PE_SNK_Ready
(UFP)

8.3.3.8.2.1 PE_UFP_VDM_Get_SVIDs state

The Policy Engine transitions to the PE_UFP_VDM_Get_SVIDs state from either the PE_SRC_Ready or PE_SNK_Ready
state for a UFP when:
 A Structured VDM Discover SVIDs Command request is received from the DFP.
On entry to the PE_UFP_VDM_Get_SVIDs state the UFP shall request SVIDs information from the Device Policy
Manager.
The Policy Engine shall transition to the PE_UFP_VDM_Send_SVIDs state when:
 SVIDs information is received from the Device Policy Manager.

Page 422 USB Power Delivery Specification Revision 2.0, Version 1.1
The Policy Engine shall transition to the PE_UFP_VDM_Get_SVIDs_NAK state when:
 The Device Policy Manager indicates that the response to the Discover Identity request is NAK or BUSY.

8.3.3.8.2.2 PE_UFP_VDM_Send_SVIDs state

On entry to the PE_UFP_VDM_Send_SVIDs state the UFP shall send the Structured VDM Discover SVIDs 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 Discover SVIDs ACK Command response has been sent.

8.3.3.8.2.3 PE_UFP_VDM_Get_SVIDs_NAK
On entry to the PE_UFP_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 or PE_SNK_Ready state for a UFP when:
 The Structured VDM Discover SVIDs NAK or BUSY Command response has been sent.

8.3.3.8.3 UFP Structured VDM Discover Modes State Diagram

Figure 8-60 shows the state diagram for a UFP in response to a Discover Modes Command.

Figure 8-60 UFP Structured VDM Discover Modes State Diagram

PE_UFP_VDM__Get_Modes_ PE_UFP_VDM__Get_Modes PE_UFP_VDM__Send_Mode

Actions on entry: NAK DPM says Actions on entry: Modes information
s
Actions on entry:
Send Discover Modes NAK/BUSY Command NAK/BUSY Request Modes information from DPM from DPM Send Discover Modes ACK
response as requested
Power = Explicit Contract Power = Explicit Contract
Power = Explicit Contract PD = Connected PD = Connected
PD = Connected

Discover Modes ACK

Discover Modes NAK/BUSY Discover Modes
sent
sent request

PE_SRC_Ready or PE_SNK_Ready
(UFP)

8.3.3.8.3.1 PE_UFP_VDM_Get_Modes state

The Policy Engine transitions to the PE_UFP_VDM_Get_Modes state from either the PE_SRC_Ready or PE_SNK_Ready
state for a UFP when:
 A Structured VDM Discover Modes Command request is received from the DFP.
On entry to the PE_UFP_VDM_Get_Modes state the UFP shall request Modes information from the Device Policy
Manager.
The Policy Engine shall transition to the PE_UFP_VDM_Send_Modes state when:
 Modes information is received from the Device Policy Manager.
The Policy Engine shall transition to the PE_UFP_VDM_Get_Modes_NAK state when:
 The Device Policy Manager indicates that the response to the Discover Identity request is NAK or BUSY.

8.3.3.8.3.2 PE_UFP_VDM_Send_Modes state

On entry to the PE_UFP_VDM_Send_Modes state the UFP shall send the Structured VDM Discover Modes ACK Command
response.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 423
The Policy Engine shall transition to either the PE_SRC_Ready or PE_SNK_Ready state for a UFP when:
 The Structured VDM Discover Modes ACK Command response has been sent.

8.3.3.8.3.3 PE_UFP_VDM_Get_Modes_NAK
On entry to the PE_CBL_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.
The Policy Engine shall transition to either the PE_SRC_Ready or PE_SNK_Ready state for a UFP when:
 The Structured VDM Discover Modes NAK or BUSY Command response has been sent.

8.3.3.8.4 UFP Structured VDM Enter Mode State Diagram

Figure 8-61 shows the state diagram for a UFP in response to an Enter Mode Command.

Figure 8-61 UFP Structured VDM Enter Mode State Diagram

PE_SRC_Ready or PE_SNK_Ready (UFP)

Actions on entry:

Power = Explicit Contract

PD = Connected

Enter Modes
request1

Enter Mode NAK sent PE_UFP_VDM__Evaluate_Mode_Entry

DPM says Actions on entry:
NAK Request DPM to evaluate request to enter a Mode

Cable = Awake
PD = Connected
Enter Mode ACK
sent
DPM says
Mode entered

PE_UFP_VDM__Mode_Entry PE_UFP_VDM__Mode_Entry_ACK
Actions on entry: _NAK
Actions on entry:
Send Enter Mode NAK Command response as
Send Enter Mode ACK Command
requested
Cable = Awake
Cable = Awake
PD = Connected
PD = Connected

1
The UFP is required to be in USB operation or USB Safe State at this point.

8.3.3.8.4.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 424 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.8.4.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.

8.3.3.8.4.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.

8.3.3.8.5 UFP Structured VDM Exit Mode State Diagram

Figure 8-62 shows the state diagram for a UFP in response to an Exit Mode Command.

Figure 8-62 UFP Structured VDM Exit Mode State Diagram

PE_SRC_Ready or PE_SNK_Ready (UFP)

Actions on entry:

Power = Explicit Contract

PD = Connected

Exit Mode request

received

PE_UFP_VDM__Mode_Exit
Actions on entry:
Request DPM to evaluate request to exit the
requested Mode Exit Mode
NAK sent
Power = Explicit Contract DPM says NAK
PD = Connected
Exit Mode ACK
sent1

Mode exited

PE_UFP_VDM__Mode_Exit_ PE_UFP_VDM__Mode_Exit_
Actions on entry: ACK Actions on entry: NAK
Send Exit Mode ACK Command Send Exit Mode NAK Command

Power = Explicit Contract Power = Explicit Contract

PD = Connected PD = Connected

1
The UFP is required to be in USB operation or USB Safe State at
this point.

8.3.3.8.5.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 Manger indicates that the Mode has been exited.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 425
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.

8.3.3.8.5.2 PE_CBL_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.

8.3.3.8.5.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.

8.3.3.8.6 UFP Structured VDM Attention State Diagram

Figure 8-70 shows the state diagram for a UFP when sending an Attention Command request.

Figure 8-63 UFP VDM Attention State Diagram

PE_SRC_Ready or PE_SNK_Ready
(UFP)

Attention request Attention Command

from DPM request sent

PE_UFP_VDM_Attention_Request

Actions on entry:
Send Attention Command request

Power = Explicit Contract

PD = Connected

8.3.3.8.6.1 PE_UFP_VDM_Attention_Request
The Policy Engine transitions to the PE_UFP_VDM_Attention_Request state from either the PE_SRC_Ready or
PE_SNK_Ready state for a UFP when:
 When the Device Policy Manager requests attention from the DFP.
On entry to the PE_UFP_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 for a UFP when:
 The Attention Command request has been sent.

Page 426 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.9 DFP Structured VDM State Diagrams

8.3.3.9.1 DFP to UFP Structured VDM Discover Identity State Diagram

Figure 8-64 shows the state diagram for a DFP when discovering the identity of a UFP.

Figure 8-64 DFP to UFP VDM Discover Identity State Diagram

PE_DFP_UFP_VDM_Identity_ACKed PE_DFP_UFP_VDM_Identity_NAKed
Actions on entry: Actions on entry:
Inform DPM of identity Inform DPM of result
Power = Explicit Contract Power = Explicit Contract
PD = Connected PD = Connected

DPM informed
Discover Identity ACK
received Discover Identity NAK/BUSY |
VDMResponseTimer Timeout

PE_DFP_UFP_VDM_Identity_Request
Actions on entry:
Send Discover Identity request DPM informed
Start VDMResponseTimer

Power = Explicit Contract

PD = Connected

DPM requests
identity discovery

PE_SRC_Ready or PE_SNK_Ready
(DFP)

8.3.3.9.1.1 PE_DFP_VDM_Identity_Request state

The Policy Engine transitions to the PE_DFP_UFP_VDM_Identity_Request state from either the PE_SRC_Ready or
PE_SNK_Ready state for a DFP when:
 The Device Policy Manager requests the discovery of the identity of the Port Partner or a Cable Plug.
On entry to the PE_DFP_UFP_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_DFP_UFP_VDM_Identity_ACKed state when:
 A Structured VDM Discover Identity ACK Command response is received.
The Policy Engine shall transition to the PE_DFP_UFP_VDM_Identity_NAKed state when:
 A Structured VDM Discover Identity NAK or BUSY Command response is received or
 The VDMResponseTimer times out

8.3.3.9.1.2 PE_DFP_VDM_Identity_ACKed state

On entry to the PE_DFP_UFP_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 or PE_SNK_Ready state for a DFP when:
 The Device Policy Manager has been informed.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 427
 8.3.3.9.1.3 PE_DFP_VDM_Identity_NAKed state
On entry to the PE_DFP_UFP_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 or PE_SNK_Ready state for a DFP when:
 The Device Policy Manager has been informed.

8.3.3.9.2 DFP to Cable Plug Structured VDM Discover Identity State Diagram
Figure 8-64 shows the state diagram for a DFP when discovering the identity of a Cable Plug.

Figure 8-65 DFP VDM Discover Identity State Diagram

PE_DFP_CBL_VDM_Identity_ACKed PE_DFP_CBL_VDM_Identity_NAKed
Actions on entry: Actions on entry:
Inform DPM of identity Inform DPM of result
Power = Explicit Contract Power = Explicit Contract
Cable Plug = PD Connected Cable Plug = PD Connected

DPM informed Discover Identity ACK Discover Identity NAK/BUSY |

received VDMResponseTimer Timeout |
Discover Identity request sending
failure (without GoodCRC)
PE_DFP_CBL_VDM_Identity_Request
Actions on entry:
Send Discover Identity request
Increment DiscoverIdentityCounter DPM informed
Start VDMResponseTimer

Power = Explicit Contract

Cable Plug = PD Connected

DiscoverIdentityTimer timeout &

DiscoverIdentityCounter < nDiscoverIdentityCount

PE_SRC_Ready or PE_SNK_Ready
(DFP)

8.3.3.9.2.1 PE_DFP_VDM_Identity_Request state

The Policy Engine transitions to the PE_DFP_CBL_VDM_Identity_Request state from either the PE_SRC_Ready or
PE_SNK_Ready state for a DFP when:
 The DiscoverIdentityTimer times out and
 The DiscoverIdentityCounter is less than nDiscoverIdentityCount.
On entry to the PE_DFP_CBL_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_DFP_CBL_VDM_Identity_ACKed state when:
 A Structured VDM Discover Identity ACK Command response is received.
The Policy Engine shall transition to the PE_DFP_CBL_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).

Page 428 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.9.2.2 PE_DFP_VDM_Identity_ACKed state
On entry to the PE_DFP_CBL_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 or PE_SNK_Ready state for a DFP when:
 The Device Policy Manager has been informed.

8.3.3.9.2.3 PE_DFP_VDM_Identity_NAKed state

On entry to the PE_DFP_CBL_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 or PE_SNK_Ready state for a DFP when:
 The Device Policy Manager has been informed.

8.3.3.9.3 DFP Structured VDM Discover SVIDs State Diagram

Figure 8-66 shows the state diagram for a DFP when discovering SVIDs.

Figure 8-66 DFP VDM Discover SVIDs State Diagram

PE_DFP_VDM_SVIDs_ACKed PE_DFP_VDM_SVIDs_NAKed
Actions on entry: Actions on entry:
Inform DPM of SVIDs Inform DPM of result
Power = Explicit Contract Power = Explicit Contract
PD = Connected PD = Connected

DPM informed
Discover SVIDs ACK Discover SVIDs NAK/BUSY |
received VDMResponseTimer Timeout

PE_DFP_VDM_SVIDs_Request
Actions on entry:
Send Discover SVIDs request DPM informed
Start VDMResponseTimer

Power = Explicit Contract

PD = Connected

DPM requests
SVIDs discovery

PE_SRC_Ready or PE_SNK_Ready
(DFP)

8.3.3.9.3.1 PE_DFP_VDM_SVIDs_Request state

The Policy Engine transitions to the PE_DFP_VDM_SVIDs_Request state from either the PE_SRC_Ready or
PE_SNK_Ready state for a DFP when:
 The Device Policy Manager requests the discovery of the SVIDs of the Port Partner or a Cable Plug.
On entry to the PE_DFP_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_DFP_VDM_SVIDs_ACKed state when:
 A Structured VDM Discover SVIDs ACK Command response is received.
The Policy Engine shall transition to the PE_DFP_VDM_SVIDs_NAKed state when:
USB Power Delivery Specification Revision 2.0, Version 1.1 Page 429
 A Structured VDM Discover SVIDs NAK or BUSY Command response is received or
 The VDMResponseTimer times out.

8.3.3.9.3.2 PE_DFP_VDM_SVIDs_ACKed state

On entry to the PE_DFP_VDM_SVIDs_ACKed state the Policy Engine shall inform the Device Policy Manager of the
SVIDs 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.

8.3.3.9.3.3 PE_DFP_VDM_SVIDs_NAKed state

On entry to the PE_DFP_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 for a DFP when:
 The Device Policy Manager has been informed.

8.3.3.9.4 DFP Structured VDM Discover Modes State Diagram

Figure 8-67 shows the state diagram for a DFP when discovering Modes.

Figure 8-67 DFP VDM Discover Modes State Diagram

PE_DFP_VDM_Modes_ACKed PE_DFP_VDM_Modes_NAKed
Actions on entry: Actions on entry:
Inform DPM of Modes Inform DPM of result
Power = Explicit Contract Power = Explicit Contract
PD = Connected PD = Connected

DPM informed
Discover Modes ACK Discover Modes NAK/BUSY |
received VDMResponseTimer Timeout

PE_DFP_VDM_Modes_Request
Actions on entry:
Send Discover Modes request DPM informed
Start VDMResponseTimer

Power = Explicit Contract

PD = Connected

DPM requests
Modes discovery

PE_SRC_Ready or PE_SNK_Ready
(DFP)

8.3.3.9.4.1 PE_DFP_VDM_Modes_Request state

The Policy Engine transitions to the PE_DFP_VDM_Modes_Request state from either the PE_SRC_Ready or
PE_SNK_Ready state for a DFP when:
 The Device Policy Manager requests the discovery of the Modes of the Port Partner or a Cable Plug.
On entry to the PE_DFP_VDM_Modes_Request state the Policy Engine shall send a Structured VDM Discover Modes
Command request and shall start the VDMResponseTimer.

Page 430 USB Power Delivery Specification Revision 2.0, Version 1.1
The Policy Engine shall transition to the PE_DFP_VDM_Modes_ACKed state when:
 A Structured VDM Discover Modes ACK Command response is received.
The Policy Engine shall transition to the PE_DFP_VDM_Modes_NAKed state when:
 A Structured VDM Discover Modes NAK or BUSY Command response is received or
 The VDMResponseTimer times out.

8.3.3.9.4.2 PE_DFP_VDM_Modes_ACKed state

On entry to the PE_DFP_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.

8.3.3.9.4.3 PE_DFP_VDM_Modes_NAKed state

On entry to the PE_DFP_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.

8.3.3.9.5 DFP Structured VDM Mode Entry State Diagram

Figure 8-68 shows the state operation for a DFP when entering a Mode.

Figure 8-68 DFP VDM Mode Entry State Diagram

PE_DFP_VDM_Mode_Entry_ACKed PE_DFP_VDM_Mode_Entry_NAKed

Actions on entry: Actions on entry:

Request DPM to enter the mode Inform DPM of NAK/BUSY or timeout

Power = Explicit Contract Power = Explicit Contract

PD = Connected PD = Connected

Mode Entry ACK

received
Mode Entry NAK/BUSY
Received |
Mode entered VDMModeEntryTimer timeout
PE_DFP_VDM_Mode_Entry_Request
Actions on entry:
Send Mode Entry request DPM informed2
Start VDMModeEntryTimer

Power = Explicit Contract

PD = Connected

DPM requests
Mode entry1

PE_SRC_Ready or PE_SNK_Ready
(DFP)

1
The Device Policy Manager is required to have place the system into USB Safe State before issuing this request when
entering Modal operation.
2
The Device Policy Manager is required to return the system to USB operation if not in Modal operation at this point.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 431
 8.3.3.9.5.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:
 A Structured VDM Enter Mode NAK or BUSY Command response is received or
 The VDMModeEntryTimer times out.

8.3.3.9.5.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.

8.3.3.9.5.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 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.

8.3.3.9.6 DFP Structured VDM Mode Exit State Diagram

Figure 8-69 shows the state diagram for a DFP when exiting a Mode.

Page 432 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 8-69 DFP VDM Mode Exit State Diagram

PE_SRC_Ready or PE_SNK_Ready
(DFP)

DPM indicates
Mode exit

DPM informed1
PE_DFP_VDM_Mode_Exit_Request

Actions on entry:
Send Exit Mode request
Start VDMModeExitTimer
Exit Mode BUSY Received | Power = Explicit Contract
VDMModeExitTimer Timeout PD = Connected

Exit Mode ACK/NAK

received

PE_DFP_VDM_Exit_Mode_ACKed
PE_SRC_Hard_Reset or Actions on entry:
PE_PC_SNK_Hard_Reset Inform DPM of ACK or NAK
(DFP)
Power = Explicit Contract
PD = Connected

1
The Device Policy Manager is required to return the system to USB operation at this point when exiting Modal
Operation.

8.3.3.9.6.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_Exit_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_PC_SNK_Hard_Reset state for a DFP when:
 A Structured VDM Exit Mode BUSY Command response is received or
 The VDMModeExitTimer times out.

8.3.3.9.6.2 PE_DFP_VDM_DFP_Mode_Exit_ACKed state

On Exit to the PE_DFP_VDM_Mode_Exit_ACKed state the Policy Engine shall request the Device Policy Manager to exit
the Mode.
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.

8.3.3.9.7 DFP Structured VDM Attention State Diagram

Figure 8-70 shows the state diagram for a DFP when receiving an Attention Command request.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 433
 Figure 8-70 DFP VDM Attention State Diagram

PE_SRC_Ready or PE_SNK_Ready
(DFP)

Attention Command
request received DPM informed

PE_DFP_VDM_Attention_Request

Actions on entry:
Inform Device Policy Manager of Attention Command request

Power = Explicit Contract

PD = Connected

8.3.3.9.7.1 PE_DFP_VDM_Attention_Request
The Policy Engine transitions to the PE_DFP_VDM_Attention_Request state from either the PE_SRC_Ready or
PE_SNK_Ready state for a DFP when:
 An Attention Command request is received.
On entry to the PE_DFP_VDM_Attention_Request state the Policy Engine shall inform the Device Policy Manager of the
attention request.
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.

8.3.3.10 Cable Plug Related State Diagrams

The State Diagrams in this section shall apply to all Cable Plugs that support Structured VDMs.

8.3.3.10.1 Cable Plug Cable Ready State Diagram

Figure 8-71 shows the Cable Ready state diagram for a Cable Plug.

Figure 8-71 Cable Ready VDM State Diagram

Power up |
Hard Reset Complete |
Cable Reset Complete

PE_CBL__Ready
Actions on entry:

Cable = Awake/Asleep
PD = Not Connected/Connected

8.3.3.10.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 434 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.10.2 Cable Plug Structured VDM Discover Identity State Diagram
Figure 8-72 shows the state diagram for a Cable Plug in response to a Discover Identity Command.

Figure 8-72 Cable Plug Structured VDM Discover Identity State Diagram

PE_CBL__Get_Identity_NAK PE_CBL__Get_Identity PE_CBL__Send_Identity

Actions on entry: DPM says Actions on entry: Identity information Actions on entry:
Send Discover Identity NAK/BUSY Command NAK/BUSY Request Identity information from DPM from DPM Send Discover Identity ACK
response as requested
Cable = Awake Cable = Awake
Cable = Awake PD = Connected PD = Connected
PD = Connected

Discover Identity ACK

Discover Identity NAK/BUSY Discover Identity
sent
sent request

PE_CBL__Ready

8.3.3.10.2.1 PE_CBL_Get_Identity state

The Policy Engine transitions to the PE_CBL_Get_Identity state from the PE_CBL_Ready state when:
 A Structured VDM Discover Identity Command request is received from the DFP.
On entry to the PE_CBL_Get_Identity state the Cable shall request identity information from the Device Policy
Manager.
The Policy Engine shall transition to the PE_CBL_Send_Identity state when:
 Identity information is received from the Device Policy Manager.
The Policy Engine shall transition to the PE_CBL_Get_Identity_NAK state when:
 The Device Policy Manager indicates that the response to the Discover Identity request is NAK or BUSY.

8.3.3.10.2.2 PE_CBL_Send_Identity state

On entry to the PE_CBL_Send_Identity state the Cable shall send the Structured VDM Discover Identity ACK Command
response.
The Policy Engine shall transition to the PE_CBL_Ready state when:
 The Structured VDM Discover Identity ACK Command response has been sent.

8.3.3.10.2.3 PE_CBL_Get_Identity_NAK
On entry to the PE_CBL_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 the PE_CBL_Ready state when:
 The Structured VDM Discover Identity NAK or BUSY Command response has been sent.

8.3.3.10.3 Cable Plug Structured VDM Discover SVIDs State Diagram

Figure 8-73 shows the state diagram for a Cable Plug in response to a Discover SVIDs Command.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 435
 Figure 8-73 Cable Plug Structured VDM Discover SVIDs State Diagram

PE_CBL__Get_SVIDs_NAK PE_CBL__Get_SVIDs PE_CBL__Send_SVIDs

Actions on entry: DPM says Actions on entry: SVIDs information Actions on entry:
Send Discover SVIDs NAK/BUSY Command NAK/BUSY Request SVIDs information from DPM from DPM Send Discover SVIDs ACK
response as requested
Cable = Awake Cable = Awake
Cable = Awake PD = Connected PD = Connected
PD = Connected

Discover SVIDs ACK

Discover SVIDs NAK/BUSY Discover SVIDs
sent
sent request

PE_CBL__Ready

8.3.3.10.3.1 PE_CBL_Get_SVIDs state

The Policy Engine transitions to the PE_CBL_Get_SVIDs state from the PE_CBL_Ready state when:
 A Structured VDM Discover SVIDs Command request is received from the DFP.
On entry to the PE_CBL_Get_SVIDs state the Cable shall request SVIDs information from the Device Policy Manager.
The Policy Engine shall transition to the PE_CBL_Send_SVIDs state when:
 SVIDs information is received from the Device Policy Manager.
The Policy Engine shall transition to the PE_CBL_Get_SVIDs_NAK state when:
 The Device Policy Manager indicates that the response to the Discover Identity request is NAK or BUSY.

8.3.3.10.3.2 PE_CBL_Send_SVIDs state

On entry to the PE_CBL_Send_SVIDs state the Cable shall send the Structured VDM Discover SVIDs ACK Command
response.
The Policy Engine shall transition to the PE_CBL_Ready state when:
 The Structured VDM Discover SVIDs ACK Command response has been sent.

8.3.3.10.3.3 PE_CBL_Get_SVIDs_NAK
On entry to the PE_CBL_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 the PE_CBL_Ready state when:
 The Structured VDM Discover SVIDs NAK or BUSY Command response has been sent.

8.3.3.10.4 Cable Plug Structured VDM Discover Modes State Diagram

Figure 8-74 shows the state diagram for a Cable Plug in response to a Discover Modes Command.

Page 436 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 8-74 Cable Plug Structured VDM Discover Modes State Diagram

PE_CBL__Get_Modes_NAK PE_CBL__Get_Modes PE_CBL__Send_Modes

Actions on entry: DPM says Actions on entry: Modes information Actions on entry:
Send Discover Modes NAK/BUSY Command NAK/BUSY Request Modes information from DPM from DPM Send Discover Modes ACK
response as requested
Cable = Awake Cable = Awake
Cable = Awake PD = Connected PD = Connected
PD = Connected

Discover Modes ACK

Discover Modes NAK/BUSY Discover Modes
sent
sent request

PE_CBL__Ready

8.3.3.10.4.1 PE_CBL_Get_Modes state

The Policy Engine transitions to the PE_CBL_Get_Modes state from the PE_CBL_Ready state when:
 A Structured VDM Discover Modes Command request is received from the DFP.
On entry to the PE_CBL_Get_Modes state the Cable shall request Modes information from the Device Policy Manager.
The Policy Engine shall transition to the PE_CBL_Send_Modes state when:
 Modes information is received from the Device Policy Manager.
The Policy Engine shall transition to the PE_CBL_Get_Modes_NAK state when:
 The Device Policy Manager indicates that the response to the Discover Identity request is NAK or BUSY.

8.3.3.10.4.2 PE_CBL_Send_Modes state

On entry to the PE_CBL_Send_Modes state the Cable shall send the Structured VDM Discover Modes ACK Command
response.
The Policy Engine shall transition to the PE_CBL_Ready state when:
 The Structured VDM Discover Modes ACK Command response has been sent.

8.3.3.10.4.3 PE_CBL_Get_Modes_NAK
On entry to the PE_CBL_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.
The Policy Engine shall transition to the PE_CBL_Ready state when:
 The Structured VDM Discover Modes NAK or BUSY Command response has been sent.

8.3.3.10.5 Cable Plug Structured VDM Enter Mode State Diagram

Figure 8-75 shows the state diagram for a Cable Plug in response to an Enter Mode Command.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 437
 Figure 8-75 CablePlug Structured VDM Enter Mode State Diagram

PE_CBL__Ready
Actions on entry:

Cable = Awake/Asleep
PD = Not Connected/Connected

Enter Modes
request1

Enter Mode NAK sent PE_CBL__Evaluate_Mode_Entry

DPM says Actions on entry:
NAK Request DPM to evaluate request to enter a
Mode
Cable = Awake
PD = Connected
Enter Mode ACK
sent
DPM says
Mode entered

PE_CBL__Mode_Entry_NAK PE_CBL__Mode_Entry_ACK
Actions on entry:
Actions on entry:
Send Enter Mode NAK Command response as
Send Enter Mode ACK Command
requested
Cable = Awake
Cable = Awake
PD = Connected
PD = Connected

1
The Cable is required to be in USB operation or USB Safe State at this point.

8.3.3.10.5.1 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.

8.3.3.10.5.2 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.
The Policy Engine shall transition to the PE_CBL_Ready state when:
 The Structured VDM Enter Mode ACK Command response has been sent.

8.3.3.10.5.3 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.

Page 438 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.10.6 Cable Plug Structured VDM Exit Mode State Diagram
Figure 8-76 shows the state diagram for a Cable Plug in response to an Exit Mode Command.

Figure 8-76 CablePlug Structured VDM Exit Mode State Diagram

PE_CBL__Ready
Actions on entry:

Cable = Awake/Asleep
PD = Not Connected/Connected

Exit Mode request

received

PE_CBL__Mode_Exit
Actions on entry:
Request DPM to evaluate request to exit the
requested Mode Exit Mode
NAK sent
Cable = Awake DPM says NAK
PD = Connected
Exit Mode ACK
sent1

Mode exited

PE_CBL__Mode_Exit_ACK PE_CBL__Mode_Exit_NAK
Actions on entry: Actions on entry:
Send Exit Mode ACK Command Send Exit Mode NAK Command

Cable = Awake Cable = Awake

PD = Connected PD = Connected

1
The Cable is required to be in USB operation or USB Safe State at
this point.

8.3.3.10.6.1 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 Manger 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.

8.3.3.10.6.2 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.

8.3.3.10.6.3 PE_UFP_VDM_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.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 439
The Policy Engine shall transition to the PE_CBL_Ready state when:
 The Structured VDM Exit Mode NAK Command response has been sent.

8.3.3.10.7 Cable Plug Soft Reset State Diagram

Figure 8-77 shows the Cable Plug state diagram on reception of a Soft_Reset Message.

Figure 8-77 Cable Plug Soft Reset State Diagram

PE_CBL_Ready

Accept message
sent

PE_CBL_Soft_Reset Transmission
Error indication
Actions on entry: from Protocol Layer
Reset Protocol Layer PE_CBL_Hard_Reset
Send Accept message
Cable = Awake
PD = Connected

Soft Reset message

received

8.3.3.10.7.1 PE_CBL_Soft_Reset state

The PE_CBL_Soft_Reset state shall be entered from any state when a 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.
The Policy Engine shall transition to the PE_CBL_Hard_Reset state when:
 The Protocol Layer indicates that a transmission error has occurred.

8.3.3.10.8 Cable Plug Hard Reset State Diagram

Figure 8-78 shows the Cable Plug state diagram for a Hard Reset or Cable Reset.

Page 440 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 8-78 Cable Plug Hard Reset State Diagram

Hard Reset signalling

Received |
Cable Reset Command

PE_CBL_Hard_Reset

Actions on entry:
Reset Cable Plug

Cable = Awake/Asleep
PD = Not Connected

Cable reset complete

PE_CBL_Ready

8.3.3.10.8.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.

8.3.3.10.9 DFP Soft Reset or Cable Reset of a Cable Plug State Diagram
Figure 8-82 below shows the state diagram for the Policy Engine in a DFP when performing a Soft Reset or Cable
Reset of a Cable Plug. The following sections describe operation in each of the states.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 441
 Figure 8-79 DFP Soft Reset or Cable Reset of a Cable Plug State Diagram

Accept message
PE_SRC_Ready or PE_SNK_Ready received
(DFP)

Cable Reset sent

SenderResponseTimer
Timeout | PE_DFP_CBL_Send_Soft_Reset
PE_DFP_CBL_Send_Cable_Reset Transmission
Error indication Actions on entry:
Actions on entry: from Protocol Layer Reset Protocol Layer
Turn on VCONN
Send Soft Reset message
Send Cable Reset message
Initialize and run SenderResponseTimer
Power = DefauIt/Implicit or Explicit Contract
PD = Connected Power = DefauIt/Implicit or Explicit Contract
PD = Connected

Cable Reset Request

Message not sent after retries (no GoodCRC received)1 |
from Device Policy Manager
Protocol error detected

1
Excludes Soft Reset itself.

8.3.3.10.9.1 PE_DFP_CBL_Send_Soft_Reset state

The PE_DFP_CBL_Send_Soft_Reset state shall be entered from any state when a Protocol Error is detected by the
Protocol Layer (see Section 6.7.1) when a Message has not been sent after retries while communicating with a Cable
Plug or whenever the Device Policy Manager directs a Soft Reset.
On entry to the PE_DFP_CBL_Send_Soft_Reset state the Policy Engine shall request the Protocol Layer to perform a
Soft Reset, then shall send a Soft_Reset Message 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 DFP’s Power
Role, when:mis
 An Accept Message has been received.
The Policy Engine shall transition to the PE_DFP_CBL_Send_Cable_Reset state when:
 A SenderResponseTimer timeout occurs
 Or the Protocol Layer indicates that a transmission error has occurred.

8.3.3.10.9.2 PE_DFP_CBL_Send_Cable_Reset state

The PE_DFP_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_CBL_Send_Cable_Reset state the 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 DFP’s Power
Role, when:
 Cable Reset Signaling has been sent.

Page 442 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.10.10 UFP Source Soft Reset of a Cable Plug State Diagram
Figure 8-82 below shows the state diagram for the Policy Engine in a UFP Source, prior to an Explicit Contract, when
performing a Soft Reset of a Cable Plug. The following sections describe operation in each of the states.

Figure 8-80 UFP Source Soft Reset of a Cable Plug State Diagram

PE_SRC_Ready (UFP)

Accept message Received |

SenderResponseTimer Timeout |
Transmission Error indication
from Protocol Layer

PE_UFP_CBL_Send_Soft_Reset
Actions on entry:
Reset Protocol Layer
Send Soft Reset message
Initialize and run SenderResponseTimer

Power = DefauIt/Implicit or Explicit Contract

PD = Connected

Message not sent after retries (no GoodCRC received)1 |

Protocol error detected

1
Excludes Soft Reset itself.

8.3.3.10.10.1 PE_UFP_CBL_Send_Soft_Reset state

The PE_UFP_CBL_Send_Soft_Reset state shall be entered from any state when a Protocol Error is detected by the
Protocol Layer, when a Message has not been sent after retries while communicating with a Cable Plug or whenever
the Device Policy Manager directs a Soft Reset.
Note that there are corner cases that are not shown in the defined state diagrams that could be handled without
generating a Protocol Error.
On entry to the PE_UFP_CBL_Send_Soft_Reset state the Policy Engine shall request the Protocol Layer to perform a
Soft Reset, then shall send a Soft_Reset Message to the Cable Plug, and initialize and run the SenderResponseTimer.
The Policy Engine shall transition to the PE_SRC_Ready state when:
 An Accept Message has been received
 Or a SenderResponseTimer timeout occurs
 Or the Protocol Layer indicates that a transmission error has occurred

8.3.3.10.11 Source Startup Structured VDM Discover Identity of a Cable Plug State Diagram
Figure 8-81 shows the state diagram for Source discovery of identity information from a Cable Plug during the startup
sequence.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 443
 Figure 8-81 Source Startup Structured VDM Discover Identity State Diagram

PE_SRC_Startup

DPM requests identity discovery &

Protocol Layer Reset Complete

PE_SRC_VDM_Identity_Request
Actions on entry:
Send Discover Identity request
Increment the DiscoverIdentityCounter
Start VDMResponseTimer

Power = No or Implicit Contract Discover Identity NAK/BUSY |

DPM requests identity discovery & Cable Plug = Not PD Connected VDMResponseTimer Timeout |
DiscoverIdentityCounter < nDiscoverIdentityCount2 Discover Identity request sending
failure (without GoodCRC)
Discover Identity ACK
received

PE_SRC_VDM_Identity_ACKed PE_SRC_VDM_Identity_NAKed
Actions on entry: Actions on entry:
Inform DPM of identity Inform DPM of result
Power = No or Implicit Contract Power =No or Implicit Contract
Cable Plug = PD Connected Cable Plug = PD Connected

DPM informed
DPM informed

PE_SRC_Discovery PE_SRC_Send_Capabilities or
PE_SRC_Discovery1

1 If the Discover Identity message is being sent at startup then the Policy Engine will subsequently transition to the PE_SRC_Capabilities state as
normal. Otherwise the Policy Engine will transition to the PE_SRC_Discovery state.
2 The SourceCapabilitiesTimer 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 are sent out at a regular rate.

8.3.3.10.11.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.
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 8-81 and shall not be initialized on re-entry to PE_SRC_Discovery.
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
 The DiscoverIdentityCounter < nDiscoverIdentityCount.
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:

Page 444 USB Power Delivery Specification Revision 2.0, Version 1.1
 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).

8.3.3.10.11.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.

8.3.3.10.11.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.

8.3.3.11 BIST State diagrams

8.3.3.11.1 BIST Receive Mode State Diagram

Figure 8-82 shows the state diagram required by a UUT, which can be either a Source , Sink or Cable Plug, when
operating in BIST Receive Mode. Transitions to PE_BIST_Receive_Mode state shall be from either the PE_SRC_Ready,
PE_SNK_Ready or PE_CBL_Ready state. See Section 5.9.9 for which tests are applicable to BFSK and BMC.

Figure 8-82 BIST Receive Mode State Diagram

PE_SRC_Ready or
PE_SNK_Ready or
PE_CBL_Ready

BIST message received

with Data Object BIST Receiver Mode &
VBUS = vSafe5V

PE_BIST_Frame_Received PE_BIST_Receive_Mode
Actions on entry: Test Frame received Actions on entry:
Consume Frame Tell Protocol Layer to go to BIST
Receive Mode
VBUS = vSafe5V VBUS = vSafe5V
PD = Connected PD = Connected

Hard Reset
Test Frame
received

Hard Reset signaling received PE_SRC_Transition_to_default or

PE_SNK_Transition_to_default or
PE_CBL_Ready

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 445
 8.3.3.11.1.1 PE_BIST_Receive_Mode state
The Source, Sink or Cable Plug shall enter the PE_BIST_Receive_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 Receiver Mode BIST Data Object and VBUS is at vSafe5V.
On entry to the PE_BIST_Receive_Mode state the Policy Engine shall tell the Protocol Layer to go to BIST Receive
Mode.
The Policy Engine shall transition to the PE_BIST_Frame_Received state when:
 A Test Frame is received.
The Policy Engine shall transition to either the PE_SRC_Transition_to_default state, PE_SNK_Transition_to_default
state or or PE_CBL_Ready state (as appropriate) when:
 Hard Reset Signaling is received.

8.3.3.11.1.2 PE_BIST_Frame_Received state

On entry to the PE_BIST_Frame_Received state the Policy Engine shall consume a BIST Transmit Test Frame if one
has been received.
The Policy Engine shall transition back to the PE_BIST_Frame_Received state when:
 The BIST Receive Test Frame has been received.
The Policy Engine shall transition to either the PE_SRC_Transition_to_default state, PE_SNK_Transition_to_default
state or or PE_CBL_Ready state (as appropriate) when:
 Hard Reset Signaling is received.

Page 446 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.11.2 BIST Transmit Mode State Diagram
Figure 8-83 shows the state diagram required by a UUT that can be either a Source , Sink or Cable Plug, when
operating in BIST Transmit Mode. Transitions to PE_BIST_Transmit_Mode state shall be from either the
PE_SRC_Ready, PE_SNK_Ready or PE_CBL_Ready state. See Section 5.9.9 for which tests are applicable to BFSK and
BMC.

Figure 8-83 BIST Transmit Mode State Diagram

PE_SRC_Ready or
PE_SNK_Ready or
PE_CBL_Ready

BIST message received

with Data Object BIST Transmit Mode &
VBUS = vSafe5V

PE_BIST_Send_Frame PE_BIST_Transmit_Mode
Protocol Layer in
Actions on entry: BIST Transmit Mode Actions on entry:
Tell Protocol Layer to send the BIST Tell Protocol Layer to go to BIST
Transmit Mode Test Frame Transmit Mode
VBUS = vSafe5V VBUS = vSafe5V
PD = Connected PD = Connected

Hard Reset

Test Frame sent

(Error count received) Hard Reset signaling received PE_SRC_Transition_to_default or
PE_SNK_Transition_to_default or
PE_CBL_Ready

8.3.3.11.2.1 PE_BIST_Transmit_Mode state

The Source, Sink or Cable Plug shall enter the PE_BIST_Transmit_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 Transmit Mode BIST Data Object and VBUS is at vSafe5V.
On entry to the PE_BIST_Transmit_Mode state the Policy Engine shall tell the Protocol Layer to go to BIST Transmit
Mode.
The Policy Engine shall transition to the PE_BIST_Send_Frame state when:
 The Protocol Layer is in BIST Transmit Mode.
The Policy Engine shall transition to either the PE_SRC_Transition_to_default state, PE_SNK_Transition_to_default
state or or PE_CBL_Ready state (as appropriate) when:
 Hard Reset Signaling is received.

8.3.3.11.2.2 PE_BIST_Send_Frame state

On entry to the PE_BIST_Send_Frame state the Policy Engine shall tell the Protocol Layer to send the next BIST
Transmit Test Frame in the PRBS sequence.
The Policy Engine shall transition back to the PE_BIST_Send_Frame state when:
 The BIST Transmit Test Frame has been sent (a BIST Message with a BISTErrorCounter BIST Data Object has
been received).
The Policy Engine shall transition to either the PE_SRC_Transition_to_default state, PE_SNK_Transition_to_default
state or or PE_CBL_Ready state (as appropriate) when:
USB Power Delivery Specification Revision 2.0, Version 1.1 Page 447
 Hard Reset Signaling is received.

8.3.3.11.3 BIST Carrier Mode and Eye Pattern State Diagram

Figure 8-84 shows the state diagram required by a UUT, which can be either a Source , Sink or Cable Plug, when
operating in BIST Eye Pattern, BIST Carrier Mode 0, BIST Carrier Mode 1, BIST Carrier Mode 2 or BIST Carrier
Mode 3. Transitions to any of the Test Mode states shall be from either the PE_SRC_Ready, PE_SNK_Ready or
PE_CBL_Ready states. See Section 5.9.9 for which tests are applicable to BFSK and BMC.

Figure 8-84 BIST Carrier Mode and Eye Pattern State Diagram

PE_SRC_Ready or
PE_SNK_Ready or
PE_CBL_Ready

BIST message received

with Data Object BIST Eye Pattern & BIST message received BIST message received
VBUS = vSafe5V BIST message received
BIST message received with Data Object BIST Carrier Mode 2 & with Data Object BIST Carrier Mode 3 &
with Data Object BIST Carrier Mode 0 &
with Data Object BIST Carrier Mode 1 & VBUS = vSafe5V VBUS = vSafe5V
VBUS = vSafe5V
VBUS = vSafe5V

PE_BIST_Eye_Pattern_Mode PE_BIST_Carrier_Mode_0 PE_BIST_Carrier_Mode_1 PE_BIST_Carrier_Mode_2 PE_BIST_Carrier_Mode_3

Actions on entry: Actions on entry: Actions on entry: Actions on entry: Actions on entry:
Tell Protocol Layer to go to BIST Eye Tell Protocol Layer to go to BIST Tell Protocol Layer to go to BIST Tell Protocol Layer to go to BIST Tell Protocol Layer to go to BIST
Pattern Mode Carrier Mode 0 Carrier Mode 1 Carrier Mode 2 Carrier Mode 3
Initialize and run BISTContModeTimer Initialize and run BISTContModeTimer Initialize and run BISTContModeTimer Initialize and run BISTContModeTimer Initialize and run BISTContModeTimer

VBUS = vSafe5V VBUS = vSafe5V VBUS = vSafe5V VBUS = vSafe5V VBUS = vSafe5V
PD = Connected PD = Connected PD = Connected PD = Connected PD = Connected

BISTContModeTimer
BISTContModeTimer
BISTContModeTimer BISTContModeTimer timeout BISTContModeTimer
timeout
timeout timeout timeout

PE_SRC_Transition_to_default or
PE_SNK_Transition_to_default or
PE_CBL_Ready

8.3.3.11.3.1 BIST Eye Pattern

The Source, Sink or Cable Plug shall enter the PE_BIST_Eye_Pattern_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 Eye Pattern BIST Data Object and
 VBUS is at vSafe5V.
On entry to the PE_BIST_Eye_Pattern_Mode state the Policy Engine shall tell the Protocol Layer to go to BIST Eye
Pattern Test Mode and shall initialize and run the BISTContModeTimer.
The Policy Engine shall transition to either the PE_SRC_Transition_to_default state, PE_SNK_Transition_to_default
state or or PE_CBL_Ready state (as appropriate) when:
 The BISTContModeTimer times out.

8.3.3.11.3.2 BIST Carrier Mode 0

The Source, Sink or Cable Plug shall enter the PE_BIST_Carrier_Mode_0 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 0 BIST Data Object and
 VBUS is at vSafe5V.

Page 448 USB Power Delivery Specification Revision 2.0, Version 1.1
On entry to the PE_BIST_Carrier_Mode_0 state the Policy Engine shall tell the Protocol Layer to go to BIST Carrier
Mode 0 and shall initialize and run the BISTContModeTimer.
The Policy Engine shall transition to either the PE_SRC_Transition_to_default state, PE_SNK_Transition_to_default
state or or PE_CBL_Ready state (as appropriate) when:
 The BISTContModeTimer times out.

8.3.3.11.3.3 BIST Carrier Mode 1

The Source, Sink or Cable Plug shall enter the PE_BIST_Carrier_Mode_1 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 1 BIST Data Object and
 VBUS is at vSafe5V.
On entry to the PE_BIST_Carrier_Mode_1 state the Policy Engine shall tell the Protocol Layer to go to BIST Carrier
Mode 1 and shall initialize and run the BISTContModeTimer.
The Policy Engine shall transition to either the PE_SRC_Transition_to_default state, PE_SNK_Transition_to_default
state or or PE_CBL_Ready state (as appropriate) when:
 The BISTContModeTimer times out.

8.3.3.11.3.4 BIST Carrier Mode 2

The Source, Sink or Cable Plug shall enter the PE_BIST_Carrier_Mode_2 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 2 BIST Data Object and
 VBUS is at vSafe5V.
On entry to the PE_BIST_Carrier_Mode_2 state the Policy Engine shall tell the Protocol Layer to go to BIST Carrier
Mode 2 and shall initialize and run the BISTContModeTimer.
The Policy Engine shall transition to either the PE_SRC_Transition_to_default state, PE_SNK_Transition_to_default
state or or PE_CBL_Ready state (as appropriate) when:
 The BISTContModeTimer times out.

8.3.3.11.3.5 BIST Carrier Mode 3

The Source, Sink or Cable Plug shall enter the PE_BIST_Carrier_Mode_3 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 3 BIST Data Object and
 VBUS is at vSafe5V.
On entry to the PE_BIST_Carrier_Mode_3 state the Policy Engine shall tell the Protocol Layer to go to BIST Carrier
Mode 3 and shall initialize and run the BISTContModeTimer.
The Policy Engine shall transition to either the PE_SRC_Transition_to_default state, PE_SNK_Transition_to_default
state or or PE_CBL_Ready state (as appropriate) when:
 The BISTContModeTimer times out.

8.3.3.12 Type-C Referenced States

This section contains states cross-referenced from the [USBType-C 1.0] specification.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 449
 8.3.3.12.1 ErrorRecovery state
The ErrorRecovery state is used to electronically disconnect Port Partners using the Type-C connector. The
ErrorRecovery state shall be entered when there are errors on Type-C Ports which cannot be recovered by Hard
Reset. The ErrorRecovery state shall map to Type-C ErrorRecovery state operation as defined in the [USBType-C 1.0]
specification, including any other state transitions mandated in cases where Type-C ErrorRecovery is not supported.
On entry to the ErrorRecovery state the 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.

Page 450 USB Power Delivery Specification Revision 2.0, Version 1.1
 8.3.3.13 Policy Engine States
Table 8-33 lists the states used by the various state machines.

Table 8-33 Policy Engine States

State name Section

Source Port
PE_SRC_Startup 8.3.3.2.1
PE_SRC_Discovery 8.3.3.2.2

PE_SRC_Send_Capabilities 8.3.3.2.3

PE_SRC_Negotiate_Capability 8.3.3.2.4

PE_SRC_Transition_Supply 8.3.3.2.5
PE_SRC_Ready 8.3.3.2.6

PE_SRC_Disabled 8.3.3.2.7

PE_SRC_Capability_Response 8.3.3.2.8

PE_SRC_Hard_Reset 8.3.3.2.9
PE_SRC_Hard_Reset_Received 8.3.3.2.10

PE_SRC_Transition_to_default 8.3.3.2.11

PE_SRC_Give_Source_Cap 8.3.3.2.12

PE_SRC_Get_Sink_Cap 8.3.3.2.13

PE_SRC_Wait_New_Capabilities 8.3.3.2.14
Sink Port
PE_SNK_Startup 8.3.3.3.1

PE_SNK_Discovery 8.3.3.3.2

PE_SNK_Wait_for_Capabilities 8.3.3.3.3
PE_SNK_Evaluate_Capability 8.3.3.3.4

PE_SNK_Select_Capability 8.3.3.3.5

PE_SNK_Transition_Sink 8.3.3.3.6

PE_SNK_Ready 8.3.3.3.7
PE_SNK_Hard_Reset 8.3.3.3.8

PE_SNK_Transition_to_default 8.3.3.3.9

PE_SNK_Give_Sink_Cap 8.3.3.3.10

PE_SNK_Get_Source_Cap 8.3.3.3.11
Source Port Soft Reset
PE_SRC_Send_Soft_Reset 8.3.3.4.1.1

PE_SRC_Soft_Reset 8.3.3.4.1.2
Sink Port Soft Reset
PE_SNK_Send_Soft_Reset 8.3.3.4.2.1

PE_SNK_Soft_Reset 8.3.3.4.2.2
Source Port Ping
PE_SRC_Ping 8.3.3.5.1

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 451
 State name Section
Type-A/B Dual-Role (initially Source Port) Ping
PE_PRS_SRC_SNK_Ping 8.3.3.6.1.1.1
Type-A/B Dual-Role (initially Sink Port) Ping
PE_PRS_SNK_SRC_Ping 8.3.3.6.1.2.1
Type-A/B Hard Reset of P/C in Sink Role
PE_PC_SNK_Hard_Reset 8.3.3.6.1.3.1
PE_PC_SNK_Swap_Recovery 8.3.3.6.1.3.2
Type-A/B Hard Reset of C/P in Source Role
PE_CP_SRC_Hard_Reset 8.3.3.6.1.4.1

PE_CP_SRC_Transition_to_off 8.3.3.6.1.4.2
Type-A/B C/P Dead Battery/Power Loss
PE_DB_CP_Check_for_VBUS 8.3.3.6.1.5.1

PE_DB_CP_Power_VBUS_DB 8.3.3.6.1.5.2
PE_DB_CP_Wait_For_Bit_Stream 8.3.3.6.1.5.3

PE_DB_CP_Power_VBUS_5V 8.3.3.6.1.5.4
PE_DB_CP_Wait_Bit_Stream_Stop 8.3.3.6.1.5.5

PE_DB_CP_Unpower_VBUS 8.3.3.6.1.5.6

PE_DB_CP_PS_Discharge 8.3.3.6.1.5.7
Type-A/B P/C Dead Battery/Power Loss
PE_DB_PC_Unpowered 8.3.3.6.1.6.1

PE_DB_PC_Check_Power 8.3.3.6.1.6.2

PE_DB_PC_Send_Bit_Stream 8.3.3.6.1.6.3

PE_DB_PC_Wait_to_Detect 8.3.3.6.1.6.4
PE_DB_PC_Wait_to_Start 8.3.3.6.1.6.5
Type-C DFP to UFP Data Role Swap
PE_DRS_DFP_UFP_Evaluate_DR_Swap 8.3.3.6.2.1.2

PE_DRS_DFP_UFP_Accept_DR_Swap 8.3.3.6.2.1.3
PE_DRS_DFP_UFP_Change_to_UFP 8.3.3.6.2.1.4

PE_DRS_DFP_UFP_Send_DR_Swap 8.3.3.6.2.1.5

PE_DRS_DFP_UFP_Reject_DR_Swap 8.3.3.6.2.1.6
Type-C UFP to DFP Data Role Swap
PE_DRS_UFP_DFP_Evaluate_DR_Swap 8.3.3.6.2.2.2
PE_DRS_UFP_DFP_Accept_DR_Swap 8.3.3.6.2.2.3

PE_DRS_UFP_DFP_Change_to_DFP 8.3.3.6.2.2.4

PE_DRS_UFP_DFP_Send_DR_Swap 8.3.3.6.2.2.5

PE_DRS_UFP_DFP_Reject_DR_Swap 8.3.3.6.2.2.6
Source to Sink Power Role Swap
PE_PRS_SRC_SNK_Evaluate_PR_Swap 8.3.3.6.3.1.2

PE_PRS_SRC_SNK_Accept_PR_Swap 8.3.3.6.3.1.3
PE_PRS_SRC_SNK_Transition_to_off 8.3.3.6.3.1.4

Page 452 USB Power Delivery Specification Revision 2.0, Version 1.1
 State name Section
PE_PRS_SRC_SNK_Assert_Rd 8.3.3.6.3.1.5

PE_PRS_SRC_SNK_Wait_Source_on 8.3.3.6.3.1.6
PE_PRS_SRC_SNK_Send_PR_Swap 8.3.3.6.3.1.7

PE_PRS_SRC_SNK_Reject_PR_Swap 8.3.3.6.3.1.8
Sink to Source Power Role Swap
PE_PRS_SNK_SRC_Evaluate_PR_Swap 8.3.3.6.3.2.2
PE_PRS_SNK_SRC_Accept_PR_Swap 8.3.3.6.3.2.3

PE_PRS_SNK_SRC_Transition_to_off 8.3.3.6.3.2.4

PE_PRS_SNK_SRC_Assert_Rp
PE_PRS_SNK_SRC_Source_on 8.3.3.6.3.2.5

PE_PRS_SNK_SRC_Send_PR_Swap 8.3.3.6.3.2.7
PE_PRS_SNK_SRC_Reject_PR_Swap 8.3.3.6.3.2.8
Dual-Role Source Port Get Source Capabilities
PE_DR_SRC_Get_Source_Cap 8.3.3.6.3.3.1
Dual-Role Source Port Give Sink Capabilities
PE_DR_SRC_Give_Sink_Cap 8.3.3.6.3.4.1
Dual-Role Sink Port Get Sink Capabilities
PE_DR_SNK_Get_Sink_Cap 8.3.3.6.3.5.1
Dual-Role Sink Port Give Source Capabilities
PE_DR_SNK_Give_Source_Cap 8.3.3.6.3.6.1
Type-C VCONN Swap
PE_VCS_Send_Swap 8.3.3.7.1.1

PE_VCS_Evaluate_Swap 8.3.3.7.1.2
PE_VCS_Accept_Swap 8.3.3.7.1.3

PE_VCS_Reject_Swap 8.3.3.7.1.4

PE_VCS_Wait_For_VCONN 8.3.3.7.1.5

PE_VCS_Turn_Off_VCONN 8.3.3.7.1.6
PE_VCS_Turn_On_VCONN 8.3.3.7.1.7

PE_VCS_Send_Ps_Rdy 8.3.3.7.1.8
UFP Structured VDM
UFP Structured VDM Discovery Identity
PE_UFP_VDM_Get_Identity 8.3.3.8.1.1
PE_UFP_VDM_Send_Identity 8.3.3.8.1.2

PE_UFP_VDM_Get_Identity_NAK 8.3.3.8.1.3
UFP Structured VDM Discovery SVIDs
PE_UFP_VDM_Get_SVIDs 8.3.3.8.2.1
PE_UFP_VDM_Send_SVIDs 8.3.3.8.2.2

PE_UFP_VDM_Get_SVIDs_NAK 8.3.3.8.2.3
UFP Structured VDM Discovery Modes
PE_UFP_VDM_Get_Modes 8.3.3.8.3.1

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 453
 State name Section
PE_UFP_VDM_Send_Modes 8.3.3.8.3.2

PE_UFP_VDM_Get_Modes_NAK 8.3.3.8.3.3
UFP Structured VDM Enter Mode
PE_UFP_VDM_Evaluate_Mode_Entry 8.3.3.8.4.1

PE_UFP_VDM_Mode_Entry_ACK 8.3.3.8.4.2

PE_UFP_VDM_Mode_Entry_NAK 8.3.3.8.4.3
UFP Structured VDM Exit Mode
PE_UFP_VDM_Mode_Exit 8.3.3.8.5.1

PE_UFP_VDM_Mode_Exit_ACK 8.3.3.8.5.2

PE_UFP_VDM_Mode_Exit_NAK 8.3.3.8.5.3
UFP Structured VDM Attention
PE_UFP_VDM_Attention_Request 8.3.3.8.6.1
DFP Structured VDM
DFP to UFP Structured VDM Discover Identity
PE_DFP_UFP_VDM_Identity_Request 8.3.3.9.1.1
PE_DFP_UFP_VDM_Identity_ACKed 8.3.3.9.1.2

PE_DFP_UFP_VDM_Identity_NAKed 8.3.3.9.1.3
DFP to Cable Plug Structured VDM Discover Identity
PE_DFP_CBL_VDM_Identity_Request 8.3.3.9.2.1
PE_DFP_CBL_VDM_Identity_ACKed 8.3.3.9.2.2

PE_DFP_CBL_VDM_Identity_NAKed 8.3.3.9.2.3
DFP Structured VDM Discover SVIDs
PE_DFP_VDM_SVIDs_Request 8.3.3.9.3.1
PE_DFP_VDM_SVIDs_ACKed 8.3.3.9.3.2

PE_DFP_VDM_SVIDs_NAKed 8.3.3.9.3.3
DFP Structured VDM Discover Modes
PE_DFP_VDM_Modes_Request 8.3.3.9.4.1
PE_DFP_VDM_Modes_ACKed 8.3.3.9.4.2

PE_DFP_VDM_Modes_NAKed 8.3.3.9.4.3
DFP Structured VDM Mode Entry
PE_DFP_VDM_Mode_Entry_Request 8.3.3.9.5.1

PE_DFP_VDM_Mode_Entry_ACKed 8.3.3.9.5.2
PE_DFP_VDM_Mode_Entry_NAKed 8.3.3.9.5.3
DFP Structured VDM Mode Exit
PE_DFP_VDM_Mode_Exit_Request 8.3.3.9.6.1

PE_DFP_VDM_Mode_Exit_ACKed 8.3.3.9.6.2
DFP Structured VDM Attention
PE_DFP_VDM_Attention_Request 8.3.3.9.7.1
Cable Plug Related
Cable Ready
PE_CBL_Ready 8.3.3.10.1.1

Page 454 USB Power Delivery Specification Revision 2.0, Version 1.1
 State name Section
Discover Identity
PE_CBL_Get_Identity 8.3.3.10.2.1
PE_CBL_Send_Identity 8.3.3.10.2.2

PE_CBL_Get_Identity_NAK 8.3.3.10.2.3
Discover SVIDs
PE_CBL_Get_SVIDs 8.3.3.10.3.1
PE_CBL_Send_SVIDs 8.3.3.10.3.2

PE_CBL_Get_SVIDs_NAK 8.3.3.10.3.3
Discover Modes
PE_CBL_Get_Modes 8.3.3.10.4.1

PE_CBL_Send_Modes 8.3.3.10.4.2
PE_CBL_Get_Modes_NAK 8.3.3.10.4.3
Mode Entry
PE_CBL_Evaluate_Mode_Entry 8.3.3.10.5.1

PE_CBL_Mode_Entry_ACK 8.3.3.10.5.2
PE_CBL_Mode_Entry_NAK 8.3.3.10.5.3
Mode Exit
PE_CBL_Mode_Exit 8.3.3.10.6.1

PE_CBL_Mode_Exit_ACK 8.3.3.10.6.2
PE_CBL_Mode_Exit_NAK
Cable Soft Reset
PE_CBL_Soft_Reset 8.3.3.10.7.1
Cable Hard Reset
PE_CBL_Hard_Reset 8.3.3.10.8.1
DFP Soft Reset or Cable Reset
PE_DFP_CBL_Send_Soft_Reset 8.3.3.10.9.1

PE_DFP_CBL_Send_Cable_Reset 8.3.3.10.9.2
UFP Source Soft Reset
PE_UFP_CBL_Send_Soft_Reset 8.3.3.10.10
Source Startup Structured VDM Discover Identity
PE_SRC_VDM_Identity_Request 8.3.3.10.11.1

PE_SRC_VDM_Identity_ACKed 8.3.3.10.11.2
PE_SRC_VDM_Identity_NAKed 8.3.3.10.11.3
BIST Receive Mode
PE_BIST_Receive_Mode 8.3.3.11.1.1

PE_BIST_Frame_Received 8.3.3.11.1.2
BIST Transmit Mode
PE_BIST_Transmit_Mode 8.3.3.11.2.1

PE_BIST_Send_Frame 8.3.3.11.2.2
BIST Carrier Mode and Eye Pattern
PE_BIST_Eye_Pattern_Mode 8.3.3.11.3.1

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 455
 State name Section
PE_BIST_Carrier_Mode_0 8.3.3.11.3.2

PE_BIST_Carrier_Mode_1 8.3.3.11.3.3
PE_BIST_Carrier_Mode_2 8.3.3.11.3.4

PE_BIST_Carrier_Mode_3 8.3.3.11.3.5
Type-C referenced states
ErrorRecovery 8.3.3.12.1

Page 456 USB Power Delivery Specification Revision 2.0, Version 1.1
9. System Policy
9.1 Overview
This chapter describes the requirements of the USB Power Delivery Specification’s System Policy and Status
mechanisms for devices with data connections (e.g. D+/D- and or SSTx+/- and SSRx+/-). The Policies themselves are
not described here; these are left to the implementers of the relevant products and systems to define. The aim of
these mechanisms is to support a System USB Power Delivery Policy Manager (SPM) which:
 Provides feedback of system power status to the end user as and when appropriate
 Provides co-ordination of system power resources based on a system wide policy when enabled
 Exposes relevant policy settings to the end user
 Allows a device to report its capabilities in relation to the power it draws
All PD Capable USB (PDUSB) Devices shall report themselves as self-powered devices (over USB) when plugged into a
PD capable Port even if they are entirely powered from VBUS. However, there are some differences between PD and
[USB 2.0] / [USB 3.1]; for example, the presence of VBUS alone does not mean that the device (Consumer) moves from
the USB Attached state to the USB Powered state. Similarly the removal of VBUS alone does not move the device
(Consumer) from any of the USB states to the Attached state. See Section 9.1.2 for details.
PDUSB Devices shall follow the PD requirements when it comes to suspend (see Section 6.4.1.2.3.2), configured, and
operational power. The PD requirements when the device is configured or operational are defined in this section (see
Table 9-4). Note that the power requirements reported in the PD Consumer Port descriptor of the device shall
override the power draw reported in the bMaxPower field in the configuration descriptor. A PDUSB Device shall
report zero in the bMaxPower field after successfully negotiating a mutually agreeable Contract and shall disconnect
and re-enumerate when it switches operation back to operating in standard [USB 2.0], [USB 3.1], [USBType-C 1.0] or
[BC 1.2]. When operating in [USB 2.0], [USB 3.1], [USBType-C 1.0] or [BC 1.2] mode it shall report its power draw via
the bMaxPower field.
As shown in Figure 9-1, each Provider and Consumer will have their own Local Policies which operate between
directly connected ports. An example of a typical PD system is shown in Figure 9-1. This example consists of a
Provider, Consumer/Providers and Consumers connected together in a tree topology. Between directly connected
devices there is both a flow of Power and also Communication consisting of both Status and Control information.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 457
 Figure 9-1 Example PD Topology

AC/Battery

Power

Provider
Communication

P/C Provider/Consumer

Consumer/
Provider
P/C P/C P/C

Consumer/ AC/Battery
Consumer Consumer
Provider

Figure 9-2 shows how this same topology can be mapped to USB. In a USB based system, policy is managed by the
host and communication of system level policy information is via standard USB data line communication. This is a
separate mechanism to the USB Power Delivery VBUS protocol which is used to manage Local Policy. When USB data
line communication is used, status information and control requests are passed directly between the System Policy
Manager (SPM) on the host and the Provider or Consumer.
Status information comes from a Provider or Consumer to the SPM so it can better manage the resources on the host
and provide feedback to the end user. Control information comes from the SPM to the Provider or Consumer allowing
the SPM to manage resources at a system level and expose relevant settings to the end user.
Real systems will be a mixture of devices which in terms of power management support may have implemented PD,
[USB 2.0], [USB 3.1], [USBType-C 1.0] or [BC 1.2] or they may even just be non-compliant Power Sucking Devices.
The level of communication of system status to the SPM will therefore not necessarily be comprehensive. The aim of
the System Policies and Status mechanisms is to provide a mechanism whereby each connected entity in the system
provides as much information as possible on the status of itself and, in the case of hubs, its downstream ports. This
will enable the PM to build up as comprehensive a picture of the system as possible.

Page 458 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 9-2 Mapping of PD Topology to USB

AC/Battery

Power

Root Hub
Communication

Hub

AC/Battery
Device Device Device

Information which will be communicated to the SPM is as follows:

 Versions of Type-C Current, PD and BC supported
 Capabilities of each Provider/Consumer including a per Port summary for Providers
 Current operational state of each Port e.g. Standard, Type-C Current, BC, PD and negotiated power level
 Status of AC or Battery Power for each PDUSB Device in the system
The SPM can negotiate with Providers or Consumers in the system in order to request a different Local Policy, or to
request the amount of power to be delivered by the Provider to the Consumer. Any change in Local Policy could
trigger a renegotiation of the Contract, using USB Power Delivery protocols, between a directly connected Provider
and Consumer. A change in how much power is to be delivered will, for example, cause a renegotiation.

9.1.1 PDUSB Device and Hub Requirements

All PDUSB Devices shall return all relevant descriptors mentioned in this chapter. PDUSB Hubs shall also support a
PD notification capability as defined in this chapter. In addition, a PDUSB Hubs shall support the capability to return
the PD specific capabilities of a device that is attached to any of its downstream ports. PDUSB Hubs shall support
Local Policy Mode and shall report the appropriate status information in response to any status requests from the
System Policy Manager when operating in Local Policy Mode. In addition PDUSB Hubs may support Hybrid and/or
Intrusive Policy Modes (see Section 9.4.5). Note that in a USB Hub, the notifications are sent over the USB Hub
notification endpoint.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 459
 9.1.2 Mapping to USB Device States
As mentioned in Section 9.1 a PDUSB Device reports itself as a self-powered device. However, the device shall
determine whether or not it is in the USB Attached or USB Powered states as described in Figure 9-3, Figure 9-4 and
Figure 9-5. All other USB states of the PDUSB Device shall be as described in Chapter 9 of [USB 2.0] and [USB 3.1].
Figure 9-3 shows how a PDUSB Device determines when to transition from the USB Attached to the USB Powered
state. Figure 9-3 also shows Dead Battery operation for a Type-A to Type-B connection (see Section 4.1.1). Type-C
Dead Battery operation does not require special handling since the default state at attach or after a Hard Reset is that
the USB Device is a Sink.

Figure 9-3 USB Attached to USB Powered State Transition

Negotiate
enough
No Power? Yes
Hard
Reset
No

USB VBUS Yes Can Yes USB

Attached Present enumerate? Powered

Device
in Sink
Mode
No
Device in
Source
Mode (5V)
Attached
Yes Type-A P/C Yes
Type-B C/P?
wants to be
charged?
C/P Consumer/Provider

No No
P/C Provider/Consumer

Figure 9-4 shows how a PDUSB Device determines when to transition from the USB Powered state to the USB
Attached state when the device is a Consumer. A PDUSB Device determines that it is performing a Power Role Swap
as described in Sections 8.3.2.7.1.1 and 8.3.2.7.1.2. See Section 7.1.6 for additional information on device behavior
during Hard Resets.

Page 460 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure 9-4 Any USB State to USB Attached State Transition (When operating as a Consumer)

Hard Reset Hard Reset

and and
Can Operate Can’t Operate

Swapping
Any USB VBUS No Power
No USB
State Present Attached
Roles?

Yes Yes
Hard Reset
and
Bus Powered
Figure 9-5 shows how a PDUSB Device determines when to transition from the USB Powered state to the USB
Attached state when the device is a Provider.

Figure 9-5 Any USB State to USB Attached State Transition (When operating as a Provider)

Local Power Source Lost

Hard
Reset
Any USB Lack of PD Yes USB
State comms? Attached

No

Figure 9-6 shows how a PDUSB Device using the Type-C connector determines when to transition from the USB
Powered state to the USB Attached state after a Data Role Swap has been performed i.e. it has just changed from
operation as a PDUSB Host to operation as a PDUSB Device. The Data Role Swap is described in Section 0. A Hard
Reset will also return a Sink acting as a PDUSB Host to PDUSB Device operation as described in Section 0. See Section
7.1.6 for additional information on device behavior during Hard Resets.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 461
 Figure 9-6 Any USB State to USB Attached State Transition (After a Type-C Data Role Swap)

Hard Reset
No Changes Data
Role

Swapping
Any USB VBUS Yes Data
Yes USB
State Present Attached
Roles?

9.1.3 PD Software Stack

Figure 9-7 gives an example of the software stack on a PD aware OS. In this stack we are using the example of a
system with an xHCI based controller. The USB Power Delivery hardware may or may not be a part of the xHC. The
software that controls the USB Power Delivery hardware is called the System Policy Manager (SPM) in this
specification.
It is expected that the SPM will expose an interface that can be used by an updated hub driver and updated client
drivers that wish to interact with PDUSB Hubs and PDUSB Peripherals respectively.

Figure 9-7 Software stack on a PD aware OS

Page 462 USB Power Delivery Specification Revision 2.0, Version 1.1
 9.1.4 PDUSB Device Enumeration
As described earlier, a PDUSB Device acts as a self-powered device with some caveats with respect to how it
transitions from the USB Attached state to USB Powered state. Figure 9-8 gives a high level overview of the
enumeration steps involved due to this change. A PDUSB Device will first (Step1) interact with the Power Delivery
hardware and the Local Policy manager to determine whether or not it can get sufficient power to
enumerate/operate. Note: PD is likely to have established a Contract prior to enumeration. The SPM will be notified
(Step 2) of the result of this negotiation between the Power Delivery hardware and the PDUSB Device. It may request
changes to the Local Policy manager if it deems it necessary. After successfully negotiating a mutually agreeable
Contract the device will signal a connect to the xHC. The standard USB enumeration process (Steps 3, 4 and 5) is then
followed to load the appropriate driver for the function(s) that the PDUSB Device exposes.
It is the responsibility of the SPM to ensure that the total amount of power supplied to a PDUSB Device is sufficient to
run as many of the functions exposed by the device as software needs to operate at the same time.
Note that the interfaces between the SPM and USB Power Delivery blocks in Figure 9-7 are outside scope of this
specification.

Figure 9-8 Enumeration of a PDUSB Device

If a PDUSB Device cannot perform its intended function with the amount of power that it can get from the Port it is
connected to then the host system should display a Message (on a PD aware OS) about the failure to provide sufficient
power to the device. In addition the device shall follow the requirements listed in Section 8.2.5.2.1.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 463
 9.2 PD Class Specific Descriptors
A PDUSB Device shall return all relevant descriptors mentioned in this section.
The device shall return its capability descriptors as part of the device’s Binary Object Store (BOS) descriptor set. Table
9-1 lists the type of PD device capabilities.

Table 9-1 USB Power Delivery Type Codes

Capability Code Value Description

POWER_DELIVERY_CAPABILITY 06H Defines the various PD Capabilities of this device

BATTERY_INFO_CAPABILITY 07H Provides information on each battery supported by the device

PD_CONSUMER_PORT_CAPABILITY 08H The Consumer characteristics of a Port on the device

PD_PROVIDER_PORT_CAPABILITY 09H The provider characteristics of a Port on the device

9.2.1 USB Power Delivery Capability Descriptor

Table 9-2 USB Power Delivery Capability Descriptor

Offset Field Size Value Description

0 bLength 1 Number Size of descriptor

1 bDescriptorType 1 Constant DEVICE CAPABILITY Descriptor type

2 bDevCapabilityType 1 Constant Capability type: POWER_DELIVERY_CAPABILITY

3 bReserved 1 Reserved Shall be set to zero.

4 bmAttributes 4 Bitmap Bitmap encoding of supported device level features. A value

of one in a bit location indicates a feature is supported; a
value of zero indicates it is not supported. Encodings are:

Bit Description

0 Reserved. Shall be set to zero.

1 Battery Charging. This bit shall be set

to one to indicate this device supports
the Battery Charging Specification as
per the value reported in the
bcdBCVersion field.

2 USB Power Delivery. This bit shall be

set to one to indicate this device
supports the USB Power Delivery
Specification as per the value reported
in the bcdPDVersion field.

3 Provider. This bit shall be set to one to

indicate this device is capable of
providing power. This field is only valid
if Bit 2 is set to one.

4 Consumer. This bit shall be set to one

Page 464 USB Power Delivery Specification Revision 2.0, Version 1.1
 Offset Field Size Value Description
to indicate that this device is a
consumer of power. This field is only
valid if Bit 2 is set to one.

5 This bit shall be set to 1 to indicate that

this device supports the feature
CHARGING_POLICY. Note that
supporting the CHARGING_POLICY
feature does not require a BC or PD
mechanism to be implemented.

6 USB Type-C Current. This bit shall be

set to one to indicate this device
supports power capabilities defined in
the USB Type-C Specification as per
the value reported in the
bcdUSBTypeCVersion field

7 Reserved. Shall be set to zero.

15:8 bmPowerSource. At least one of the

following bits 8, 9 and 14 shall be set to
indicate which power sources are
supported.
Bit Description

8 AC Supply

9 Battery

10 Other

13:11 NumBatteries. This field

shall only be valid when the
Battery field is set to one
and shall be used to report
the number of batteries in
the device.

14 Uses VBUS

15 Reserved and shall be set to

zero.

31:16 Reserved and shall be set to zero.

8 bmProviderPorts 2 Bitmap The bit corresponding to the Port shall be set to one to
indicate that this device is capable of providing power on that
Port. (Either BC 1.2, USB Type-C Current or PD)

Bit zero refers to the UFP of the device. Bits one through
fifteen are only valid for hubs and refers to the downstream
ports of the hub.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 465
 Offset Field Size Value Description

10 bmConsumerPorts 2 Bitmap The bit corresponding to the Port shall be set to one to
indicate that this device is capable of consuming power on
that Port. (Either BC 1.2, USB Type-C Current or PD).

Bit zero refers to the UFP of the device. Bits one through
fifteen are only valid for hubs and refers to the downstream
ports of the hub.

12 bcdBCVersion 2 BCD Battery Charging Specification Release Number in Binary-

Coded Decimal (e.g., V1.20 is 120H). This field shall only be
valid if the device indicates that it supports BC in the
bmAttributes field.

14 bcdPDVersion 2 BCD USB Power Delivery Specification Release Number in Binary-

Coded Decimal. This field shall only be valid if the device
indicates that it supports PD in the bmAttributes field.

16 bcdUSBTypeCVersion 2 BCD USB Type-C Specification Release Number in Binary-Coded

Decimal. This field shall only be valid if the device indicates
that it supports USB Type-C in the bmAttributes field.

9.2.2 Battery Info Capability Descriptor

A PDUSB Device shall support this capability descriptor if it reported that one of its power sources was a Battery in
the bmPowerSource field in its Power Deliver Capability Descriptor. It shall return one Battery Info Descriptor per
battery it supports.

Table 9-3 Battery Info Capability Descriptor

Offset Field Size Value Description

0 bLength 1 Number Size of descriptor

1 bDescriptorType 1 Constant DEVICE CAPABILITY Descriptor type

2 bDevCapabilityType 1 Constant Capability type: BATTERY_INFO_CAPABILITY

3 iBattery 1 Index Index of string descriptor shall contain the user friendly name
for this battery.

4 iSerial 1 Index Index of string descriptor shall contain the Serial Number
String for this battery.

5 iManufacturer 1 Index Index of string descriptor shall contain the name of the
Manufacturer for this battery.

6 bBatteryId 1 Number Value shall be used to uniquely identify this battery in status
Messages.

7 bReserved 1 Number Reserved and shall be set to zero.

8 dwChargedThreshold 4 mWh Shall contain the Battery Charge value above which this
battery is considered to be fully charged but not necessarily
“topped off.”

12 dwWeakThreshold 4 mWh Shall contain the minimum charge level of this battery such
that above this threshold, a device can be assured of being
able to power up successfully (see Battery Charging 1.2).

Page 466 USB Power Delivery Specification Revision 2.0, Version 1.1
 Offset Field Size Value Description

16 dwBatteryDesignCapacity 4 mWh Shall contain the design capacity of the battery.

20 dwBatteryLastFullcharge 4 mWh Shall contain the maximum capacity of the battery when fully
Capacity charged.

9.2.3 PD Consumer Port Capability Descriptor

A PDUSB Device shall support this capability descriptor if it reported that one, or more, of its ports are a Consumer
Port, as described in the bmConsumerPorts field in its Power Deliver Capability Descriptor. It shall return one PD
Consumer Port Capability descriptor per Port that is a Consumer. The order of the descriptors shall be Port order
number (low to high).
A PDUSB Peripheral shall have at most one Consumer or Consumer/Provider Port. A PDUSB Hub may have a
maximum of sixteen Consumer capable ports (Consumer, Consumer/Provider or Provider/Consumer).

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 467
 Table 9-4 PD Consumer Port Descriptor

Offset Field Size Value Description

0 bLength 1 Number Size of descriptor

1 bDescriptorType 1 Constant DEVICE CAPABILITY Descriptor type

2 bDevCapabilityType 1 Constant Capability type: PD_CONSUMER_PORT_CAPABILITY

3 bReserved 1 Number Reserved and shall be set to zero.

4 bmCapabilities 2 Bitmap Capability: This field shall indicate the specification the
Consumer Port will operate under.
Bit Description

0 Battery Charging (BC)

1 USB Power Delivery (PD)

2 USB Type-C Current

15:3 Reserved and shall be set to zero.

6 wMinVoltage 2 Number Shall contain the minimum voltage in 50mV units that this
Consumer is capable of operating at.

8 wMaxVoltage 2 Number Shall contain the maximum voltage in 50mV units that this
Consumer is capable of operating at.

10 wReserved 2 Number Reserved and shall be set to zero.

12 dwMaxOperatingPower 4 Number Shall contain the maximum power in 10mW units this
Consumer can draw when it is in a steady state operating
mode.

16 dwMaxPeakPower 4 Number Shall contain the maximum power in 10mW units this
Consumer can draw for a short duration of time
(dwMaxPeakPowerTime) before it falls back into a steady
state.

20 dwMaxPeakPowerTime 4 Number Shall contain the time in 100ms units that this Consumer can
draw peak current.

A device shall set this field to 0xFFFF if this value is unknown.

9.2.4 PD Provider Port Capability Descriptor

A PDUSB Device shall support this capability descriptor if it reported that one or more of its ports is a Provider Port,
as described in the bmProviderPorts field in its Power Deliver Capability Descriptor. It shall return one PD Provider
Port Capability descriptor per Port that is a Provider. The order of the descriptors will be Port order number (low to
high).
A PDUSB Peripheral shall have at most one Provider Port. A PDUSB Hub can have a maximum of sixteen Provider
ports.

Page 468 USB Power Delivery Specification Revision 2.0, Version 1.1
 Table 9-5 PD Provider Port Descriptor

Offset Field Size Value Description

0 bLength 1 Number Size of descriptor

1 bDescriptorType 1 Constant DEVICE CAPABILITY Descriptor type

2 bDevCapabilityType 1 Constant Capability type: PD_PROVIDER_PORT_CAPABILITY

3 bReserved 1 Number Reserved and shall be set to zero.

4 bmCapabilities 2 Bitmap This field shall indicate the specification the Provider Port
will operation under.
Bit Description

0 Battery Charging (BC)

1 USB Power Delivery (PD)

2 USB Type-C Current

15:3 Reserved. Shall be set to zero.

6 bNumOfPDObjects 1 Number Shall indicate the number of Power Data Objects.

7 bReserved 1 Number Reserved and shall be set to zero.

8 wPowerDataObject1 4 Bitmap Shall contain the first Power Data Object supported by this
Provider Port. See Section 6.4.1 for details of the Power Data
Objects.

… … … … …

N+4 wPowerDataObjectN 4 Bitmap Shall contain the 2nd and subsequent Power Data Objects
supported by this Provider Port. See Section 6.4.1 for details
of the Power Data Objects.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 469
 9.3 PD Class Specific Requests and Events
A PDUSB Hub that is compliant to this specification shall support the PD specific requests and events detailed in this
section irrespective of whether the PDUSB Hub is a Power Provider, a Power Consumer, or both.
A PDUSB Device that is compliant to this specification shall support the battery related requests if it has a battery.
The events shall be sent to the system software in response to changes on the PDUSB Hub ports that are not a direct
result of a request from system software. These notifications shall be sent over the Interrupt endpoint of a PDUSB
Hub.
Note that a PDUSB Hub shall only send these notifications, or respond to PD requests (except for GetBatteryStatus); if
it has been made aware that the SPM is active on the host as detailed in Section 9.4.4.

9.3.1 Class-specific Requests

The PD class defines requests to which PDUSB Devices shall respond as outlined in Table 9-6. All valid requests in
Table 9-6 shall be implemented by PDUSB Devices.

Table 9-6 PD Class Requests

Request bmRequestType bRequest wValue wIndex wLength Data

ClearPortPDFeature1 00100011B CLEAR_FEATURE Feature Selector Port Two Clear Change

Mask
Number

GetBatteryStatus2 10000000B GET_BATTERY_STATUS Zero Battery ID Eight Battery Status

GetPartnerPDO1 10100011B GET_PARTNER_PDO Zero or One Port Number Variable Power Data
Objects

GetPortPDStatus1 10100011B GET_STATUS One Port Number Eight PD Status

SetPDFeature2 00000000B SET_FEATURE Feature Selector Feature Zero None

Specific

SetPortPDFeature1 00100011B SET_FEATURE Feature Selector Port Number Zero None

SetPortPDOs1 00100011B SET_PDO Zero Port Number Variable Provider Power

Data Objects

GetVDM1 10100011B GET_VDM Zero Port Number Variable VDM

SendVDM1 00100011B SEND_VDM SOP/SOP’/SOP” Port Number Variable VDM

1 Requests valid for PDUSB Hubs only.

2 Requests valid for PDUSB Hubs and PDUSB Peripherals.
Table 9-7 gives the bRequest values for commands that are not listed in the hub/device framework chapters of [USB
2.0], [USB 3.1].

Table 9-7 PD Class Request Codes

bRequest Value
GET_PARTNER_PDO 20

GET_BATTERY_STATUS 21

SET_PDO 22

Page 470 USB Power Delivery Specification Revision 2.0, Version 1.1
 bRequest Value
GET_VDM 23

SEND_VDM 24

Table 9-8 gives the valid feature selectors for the PD class. Refer to Sections 9.4.1, 9.4.5 and 9.4.6 for a description of
the features.

Table 9-8 PD Class Feature Selectors

Feature Selector Recipient Value

BATTERY_WAKE_MASK Device 40

OS_IS_PD_AWARE Device 41

POLICY_MODE Device 42

PR_SWAP Port 43

GOTO_MIN Port 44

RETURN_POWER Port 45

ACCEPT_PD_REQUEST Port 46

REJECT_PD_REQUEST Port 47

PORT_PD_RESET Port 48

C_PORT_PD_CHANGE Port 49

CABLE_PD_RESET Port 50

CHARGING_POLICY Device 54

9.3.2 PDUSB Hub Event Reporting

PDUSB Hubs shall report events back to the system via the “Port N change detected” bit in the PDUSB Hub Status
Change bitmap returned via the PDUSB Hub notification endpoint. ‘N’ refers to the Port number of the Port on which
a PD change has occurred.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 471
 Figure 9-9 Hub Status Change

In order to indicate that a PD change occurred, a PDUSB Hub compliant to the PD class shall set Bit 15
C_PORT_PD_CHANGE in the Port Change field when queried using the standard Get Port Status request.
A PDUSB Hub shall send these notifications for all downstream ports irrespective of whether it is a Consumer or
Provider on that Port. For example, if a PDUSB Peripheral is a Provider on one of the downstream ports and it starts a
negotiation to change the amount of power it will deliver – the PDUSB Hub sends a Port Change notification to the
SPM. However, if the PDUSB Hub loses all power (e.g. the power Provider is unplugged) then it is sufficient if the
PDUSB Hub disconnects from the downstream Port it is attached to without sending any notifications.

Page 472 USB Power Delivery Specification Revision 2.0, Version 1.1
 9.4 PDUSB Hub and PDUSB Peripheral Device Requests
9.4.1 ClearPortPDFeature (PDUSB Hub)
This request resets a value reported in the PDUSB Hub status. This request is only valid for hubs.
bmRequestType bRequest WValue wIndex wLength Data

00100011B CLEAR_FEATURE Feature Selector Port Number Two Clear Change Mask

The Port number shall be a valid Port number for that PDUSB Hub, greater than zero. The Port field is located in bits
7..0 of the wIndex field.
Refer to Table 9-8 for the feature selector definitions that shall apply to the Port as a recipient. If the feature selector
is associated with a status change, the Clear Change Mask shall define the status changes that are being acknowledged
by the SPM. Only when all the status changes in PD Status Change field (see Table 9-11) are acknowledged shall the
hub clear the C_PORT_PD_CHANGE bit in the Port’s Port Change field. The Clear Change Mask is defined in Table 9-9.

Table 9-9 Clear Change Mask

Bit Change Acknowledged when bit is set

0 Reserved

1 External supply.

2 Port operation mode

3 Supported Provider Capabilities

4 Negotiated power level

5 New power direction

6 PD Reset Complete

7 Insertion Detect

8 PD Capable Cable

9 Request Rejected

10 Reserved

11 Hybrid Mode Request

12 Power Role Swap Completed

13 VDM Received

14 Reserved

15 Error

It shall be a Request Error if wValue is not a feature selector listed in Table 9-8, or if wIndex specifies a Port that does
not exist, or if wLength is not as specified above.
If the PDUSB Hub is not configured, the PDUSB Hub's response to this request is undefined.

9.4.2 GetBatteryStatus (PDUSB Hub/Peripheral Device)

This request returns the current status of the battery in a PDUSB Hub/Peripheral.
USB Power Delivery Specification Revision 2.0, Version 1.1 Page 473
 bmRequestType bRequest wValue wIndex wLength Data

10000000B GET_BATTERY_STATUS Zero Battery ID Eight Battery Status

The PDUSB Hub/Peripheral shall return the Battery Status of the Battery identified by the value of wIndex field.
Every PDUSB Device that has a battery shall return its Battery Status when queried with this request. For Providers or
Consumers with multiple batteries, the status of each battery shall be reported per battery.

Table 9-10 Battery Status Structure

Offset Field Size Value Description

0 bBatteryAttributes 1 Number Shall indicate whether a battery is installed and whether this
is charging or discharging.
Value Description

0 There is no battery

1 The battery is charging

2 The battery is discharging

3 The battery is neither discharging nor

charging

255-4 Reserved and shall not be used

1 bBatterySOC 1 Number Shall indicate the Battery State of Charge given as percentage
value from Battery Remaining Capacity.

2 bBatteryStatus 1 Number If a battery is present shall indicate the present status of the
battery.
Value Meaning

0 No error

1 Battery required and not present

2 Battery non-chargeable/wrong chemistry

3 Over-temp shutdown

4 Over-voltage shutdown

5 Over-current shutdown

6 Fatigued battery

7 Unspecified error

255-8 Reserved and shall not be used

Page 474 USB Power Delivery Specification Revision 2.0, Version 1.1
Offset Field Size Value Description

3 bRemoteWakeCapStatus 1 Bitmap If the device supports remote wake, then the device shall
support Battery Remote wake events. The default value for
the Remote wake events shall be turned off (set to zero) and
can be enable/disabled by the host as required. If set to one
the device shall generate a wake event when a change of
status occurs. See Section 9.4.5 for more details.
Bit Description

0 Battery present event

1 Charging flow

2 Battery error

7:3 Reserved and shall be set to zero

4 wRemainingOperatingTime 2 Number Shall contain the operating time (in minutes) until the Weak
Battery threshold is reached, based on Present Battery
Strength and the device’s present operational power needs.
Note: this value shall exclude any additional power received
from charging.

A battery that is not capable of returning this information

shall return a value of 0xFFFF.

6 wRemainingChargeTime 2 Number Shall contain the remaining time (in minutes) until the
Charged Battery threshold is reached based on Present
Battery Strength, charging power and the device’s present
operational power needs. Value shall only be valid if the
Charging Flow is “Charging”.

A battery that is not capable of returning this information

shall return a value of 0xFFFF.

If wValue or wLength are not as specified above, then the behavior of the PDUSB Device is not specified.
If wIndex refers to a Battery that does not exist, then the PDUSB Device shall respond with a Request Error.
If the PDUSB Device is not configured, the PDUSB Hub's response to this request is undefined.

9.4.3 GetPortPartnerPDObjects (PDUSB Hub)

This request returns the Provider/Consumer PD Objects of the PDUSB Device attached to the downstream Port on a
PDUSB Hub.
bmRequestType bRequest wValue wIndex wLength Data

Power Data
10100011B GET_PARTNER_PDO Zero or one Port Number Variable
Objects

The wIndex field shall indicate the Port number to which a PDUSB Device is attached. The Port number shall be a valid
Port number for that PDUSB Hub, greater than zero.
When this request is received by the PDUSB Hub it shall return the Consumer PDOs (if wValue is set to zero) or
Provider PDOs (if wValue is set to one) for the PDUSB Device connected on the downstream Port indicated by the
wIndex field. The PDUSB Hub shall use PD mechanisms (see Section 6.3.8) to retrieve the Power Data Objects from the
PDUSB Device.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 475
The wLength field shall specify the number of bytes to return. The maximum length of this field is a function of the
maximum number of PDOs a PDUSB Device can return as defined in Section 6.2.1.2. If the device on the Partner Port
does not support PD, then the PDUSB Hub shall respond with a Request Error.
If the PDUSB Hub is not configured, the PDUSB Hub's response to this request is undefined.

9.4.4 GetPortPDStatus (PDUSB Hub)

This request returns the PD Status of the specified Port on a PDUSB Hub.
bmRequestType bRequest wValue wIndex wLength Data

10100011B GET_ STATUS One Port Number Eight PD Status

The wIndex field shall indicate the PD capable Port that is being queried. The Port number shall be a valid Port
number for that PDUSB Hub, greater than zero.
If wValue or wLength are not as specified above, then the behavior of the PDUSB Hub is not specified.
If a Port is specified that does not exist, then the PDUSB Hub shall respond with a Request Error. The PD status
changes on the Port are indicated in the PD Status Change field. The SPM can acknowledge the Port Change
notifications via the Clear Port PD Feature (See Section9.4.1).
If the PDUSB Hub is not configured, the PDUSB Hub's response to this request is undefined.
A GetPDStatus () request to a PDUSB Hub shall return the information as shown in Table 9-11.

Table 9-11 Port PD Status

Bit Description

0:15 PD Status Change: A one in the bit position shall indicate the types of status changes that have occurred on the Port.
Bit Change Indicated

0 Reserved and shall not be used.

1 External supply. When set, the Supply field shall indicate the current status of the supply.

2 Port operation mode. When set the Port Operation Mode field shall indicated the current
operational mode of the Port.

3 Supported Provider Capabilities. When set, the SPM shall get the updated Power Data
Objects from by retrieving the BOS Descriptor from the PDUSB Hub.

4 Negotiated power level. When set, the Request Data Object field shall indicate the newly
negotiated power level if the PDUSB Hub was operating in Non-Intrusive mode. If the
PDUSB Hub is working in intrusive mode then, when set, the Request Data Object field
shall indicate the power level that the Port partner wants to operate at.

5 New power direction. When set, this field shall indicate that the power direction has
changed if the PDUSB Hub was operating in Non-Intrusive mode. If the PDUSB Hub is
working in intrusive mode then, when set, this field shall indicate the Port partner wants to
perform a Power Role Swap.

6 PD Reset Complete. When set, this field shall indicate that a PD Hard Reset or a Cable Reset
has completed. When this bit is set, then the other bits in the PD Status Change field shall
report their change status as if the PDUSB Hub was working in Non-Intrusive mode.

7 Insertion Detect. When set, the Insertion Detect field shall indicate the current status of
whether a cable is plugged into this Port.

8 PD Capable Cable. When set, the PD Capable Cable field shall indicate the current status of

Page 476 USB Power Delivery Specification Revision 2.0, Version 1.1
Bit Description
whether a PD Capable Cable is plugged into this Port.

9 Request Rejected. This bit shall be only valid if the PDUSB Hub is operating in Non-
Intrusive mode. When set, this field shall indicate one of two conditions:

 the PDUSB Hub received a request to change the power level (Negotiated power level (Bit
4) bit in this field shall be set) that was rejected or
 the PDUSB Hub received a request to perform a Power Role Swap (New power direction
bit (Bit 5) in this field shall be set) that was rejected.

10 Reserved and shall be set to zero.

11 Hybrid Mode Request. This bit shall only be set by the PDUSB Hub when it is operating in
Hybrid mode. If this bit is set, then bits 4 and 5 (Negotiated power level and New power
direction) shall be interpreted as if the hub was operating in Intrusive mode.

12 Power Role Swap Completed. This shall be set when the hub completes a Power Role Swap
requested by the SPM. The SPM can determine if the Swap request was successful or
unsuccessful based on the PD Direction bit.

13 VDM Received. When set, the SPM shall use the Get VDMs command (see section 9.4.8) to
get further details on this notification.

14 Reserved and shall be set to zero.

15 Error. When set, this field shall indicate that an unknown error has occurred on the Port.

16 Supply: This field shall indicate the type of supply that is attached to this Port. This field shall map directly to the
“Externally Powered” bit provided as part of the Source or Sink Capabilities Message (see Section 6.4.1).
Value Meaning

0 No Supply

1 Supply Present

17:19 Port Operation Mode: The field shall indicate the current mode of operation of the Port.
Value Meaning

0 No Consumer

1 Legacy

2 BC

3 PD

4 Type-C Current

5-7 Reserved

20 Insertion Detect: The field shall indicate the current status of whether a cable is plugged into this Port.
Value Meaning

0 No cable detected

1 Cable detected

21 PD Capable Cable: The field shall indicate the current status of whether a PD Capable cable is plugged into this Port.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 477
Bit Description
Value Meaning

0 PD Capable Cable not detected

1 PD Capable Cable detected

22 PD Direction. The field shall indicate whether the Port is operating as a Consumer or provider.
Value Meaning

0 Port is operating as a Consumer

1 Port is operating as a provider

23:31 Reserved. Shall be set to zero.

32:63 Request Data Object: This field shall return the currently negotiated power level if the hub was operating in Non-
Intrusive mode. If the PDUSB Hub is working in intrusive mode then this field shall indicate the power level that the Port
partner wants to operate at. See Table 6-13 for additional information on the contents of this data structure.

9.4.5 SetPDFeature (PDUSB Hub/Peripheral Device)

This request sets the value requested in the PDUSB Hub/Peripheral.
bmRequestType bRequest wValue wIndex wLength Data

00000000B SET_ FEATURE Feature Feature Specific Zero None

Selector

Setting a feature enables that feature or starts a process associated with that feature; see Table 9-8 for the feature
selector definitions. Features that may be set with this request are:
 BATTERY_WAKE_MASK
 OS_IS_PD_AWARE (Only valid for PDUSB Hubs)
 POLICY_MODE (Only valid for PDUSB Hubs)
 CHARGING_POLICY

9.4.5.1 BATTERY_WAKE_MASK Feature Selector

When the feature selector is set to BATTERY_WAKE_MASK, then the wIndex field is structured as shown in the
following table.

Table 9-12 Battery Wake Mask

Bit Description

0 Battery Present: When this bit is set then the

PDUSB Device shall generate a wake event if it
detects that a battery has been attached.

1 Charging Flow: When this bit is set then the

PDUSB Device shall generate a wake event if it
detects that a battery switched from charging to
discharging or vice versa.

2 Battery Error: When this bit is set then the

PDUSB Device shall generate a wake event if
the battery has detected an error condition.

15:3 Reserved and shall not be used.

Page 478 USB Power Delivery Specification Revision 2.0, Version 1.1
The SPM may Enable or Disable the wake events associated with one or more of the above events by using this
feature.
If the PDUSB Hub is not configured, the PDUSB Hub's response to this request is undefined.

9.4.5.2 OS_IS_PD_AWARE Feature Selector

When the feature selector is set to OS_IS_PD_AWARE, then if the wIndex field is set to one it informs the PDUSB Hub
that the SPM is active on the host. If the wIndex field is set to zero then it informs the PDUSB Hub that the SPM is not
active on the host. The default state for this feature shall be zero. The PDUSB Hub shall respond to all PD requests
(except GetBatteryStatus) or send any PD notifications only after the OS_IS_PD_AWARE feature is set.
This is a valid command for the PDUSB Hub/Peripheral Device in the Address or Configured USB states.

9.4.5.3 POLICY_MODE Feature Selector

When the feature selector is set to POLICY_MODE, the wIndex field shall be set to one of the values in Table 9-13.

Table 9-13 Policy Mode Encoding

Value Description

00H Local: Status Reporting only (Default)

01H Intrusive: All requests are sent to the SPM

02H Hybrid: Send only requests that cannot be

accommodated to the SPM

03H-FFFFH Reserved and shall not be used

If the Policy Mode is set to Intrusive, then the PDUSB Hub shall be set to operate in Intrusive mode. If the Policy Mode
is set to Local or Hybrid, the hub shall be set to operate in Non-Intrusive mode.
When the Policy Mode is set to Intrusive then the PDUSB Hub shall pass any requests that need policy decisions to be
made to the SPM and use PD mechanisms to delay the completion of PD Requests (e.g. using the Wait Message) over
PD. When the Policy Mode is set to Hybrid then only requests which cannot be accommodated by the PDUSB Hub
shall be sent to the SPM.
Some requests are only valid when the PDUSB Hub is operating in Intrusive mode. The requests that are valid in
Intrusive mode are indicated as such in the description for those requests. In addition notifications that operate
differently in Intrusive mode are also called out in the description of those notifications.
It shall be a Request Error if wValue is not a feature selector listed in Table 9-8 or if wIndex is not set to a value as
specified above.
If the PDUSB Hub is not configured, the PDUSB Hub's response to this request is undefined.

9.4.5.4 CHARGING_POLICY Feature Selector

When the feature selector is set to CHARGING_POLICY, the wIndex field shall be set to one of the values defined in
Table 9-14. If the device is using USB Type-C Current above the default value or is using PD then this feature setting
has no effect and the rules for power levels specified in the [USBType-C 1.0] or USB PD specifications shall apply.

Table 9-14 Charging Policy Encoding

Value Description

00H The device shall follow the default current limits as defined in the USB 2.0 or USB 3.1 specification, or as
negotiated through other USB mechanisms such as BC.
This is the default value.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 479
 Value Description

01H The Device may draw additional power during the unconfigured and suspend states for the purposes of
charging.

For charging the device itself, the device shall limit its current draw to the higher of these two values:
 ICCHPF as defined in the USB 2.0 or USB 3.1 specification, regardless of its USB state.
 Current limit as negotiated through other USB mechanisms such as BC.

02H The Device may draw additional power during the unconfigured and suspend states for the purposes of
charging.

For charging the device itself, the device shall limit its current draw to the higher of these two values:
 ICCLPF as defined in the USB 2.0 or USB 3.1 specification, regardless of its USB state.
 Current limit as negotiated through other USB mechanisms such as BC.

03H The device shall not consume any current for charging the device itself regardless of its USB state.

04H-FFFFH Reserved and shall not be used

This is a valid command for the PDUSB Hub/Peripheral in the Address or Configured USB states. Further, it is only
valid if the device reports a USB PD capability descriptor in its BOS descriptor and Bit 6 of the bmAttributes in that
descriptor is set to 1. The device will go back to the wIndex default value of 0 whenever it is reset.

9.4.6 SetPortPDFeature (PDUSB Hub)

This request sets the feature for a Port in a PDUSB Hub. This request shall only be valid when the PDUSB Hub is
operating in Intrusive mode. If the PDUSB Hub is not operating in Intrusive mode, the PDUSB Hub's response to this
request is undefined. If the PDUSB Hub cannot satisfy a request then it shall respond with a Request Error to the SPM.
bmRequestType bRequest wValue wIndex wLength Data

00100011B SET_ FEATURE Feature Port Number Zero None

Selector

The wIndex field shall indicate the PD capable Port that is being queried. The Port number shall be a valid Port
number for that hub, greater than zero.
Setting a feature enables that feature or starts a process associated with that feature; see Table 9-8 for the feature
selector definitions. Features that may be set with this request are:
 PR_SWAP
 GOTO_MIN
 RETURN_POWER
 ACCEPT_PD_REQUEST
 REJECT_PD_REQUEST
 PORT_PD_RESET
 CABLE_PD_RESET
When operating in intrusive mode the PDUSB Hub shall respond with a Wait Message when it receives any Request
Message.
When the feature selector is set to PR_SWAP then the PDUSB Hub shall initiate a Power Role Swap with the Port
partner on the specified Port. See Section 7.3.9 and Section 7.3.10 for details on the PR_Swap Message.
When the feature selector is set to GOTO_MIN and the downstream Port is operating as a Provider, then the PDUSB
Hub shall send the GotoMin Message to the Port partner on the specified Port. See Section 6.3.2 for details on the
GotoMin Message.

Page 480 USB Power Delivery Specification Revision 2.0, Version 1.1
When the feature selector is set to RETURN_POWER and the downstream Port is operating as a Provider, then the
PDUSB Hub shall return the power that it borrowed from the PD Device on that Port.
When the feature selector is set to ACCEPT_PD_REQUEST then the PDUSB Hub shall accept the request that was
previously made by the Port partner on this downstream Port.
When the feature selector is set to REJECT_PD_REQUEST then the PDUSB Hub shall reject the request that was
previously made by the Port partner on this downstream Port.
When the feature selector is set to PORT_PD_RESET, the Port shall be sent a Hard Reset. Once the Hard Reset is
complete, as described in Section 0, the hub shall set the C_PORT_PD_CHANGE bit in the Port change field.
When the feature selector is set to CABLE_PD_RESET, the hub shall send a Cable Reset to the cable attached on that
Port. Once the Cable Reset is complete, as described in Section 6.7.3, the hub shall set the C_PORT_PD_CHANGE bit in
the Port change field.
It shall be a Request Error if wValue is not a feature selector listed in Table 9-8, or if wIndex specifies a Port that does
not exist or if the Port is operating as a Consumer, or if wLength is not as specified above.
If the PDUSB Hub is not configured, the PDUSB Hub's response to this request is undefined.

9.4.7 SetPortPDOs (PDUSB Hub)

This request sets the PDOs that a Port in a PDUSB Hub shall send to its Port Partner if the Port on the PDUSB Hub is
operating as a Provider. Setting the PDO shall cause the Provider to send an updated Source_Capabilities Message.
The PDOs sent shall constitute a subset of the capabilities supported by the PDUSB Hub as defined in the PD Provider
Port Capability Descriptor (see Section 9.2.4). When any PDO set exceeds the capabilities of the PDUSB Hub this
request shall be rejected.
bmRequestType bRequest wValue wIndex wLength Data

00100011B SET_PDO Zero Port Number Variable Provider Power Data Objects

The wIndex field shall indicate the PD capable Port that is being queried. The Port number shall be a valid Port
number for that hub, greater than zero.
The wLength field shall be a multiple of 4 and shall include all the PDOs (see Section 6.4.1) that the Port may send to
its Port partner when sending its PD capabilities. The Port shall send the PDOs in the order that they are included in
this request. It is the responsibility of the PDUSB Hub to verify that the contents of the PDOs sent by the SPM are valid
for this Port. A PDUSB Hub shall respond with a Request Error if the PDOs sent by the SPM are not valid for the Port
specified.
It shall be a Request Error if wValue is not set to zero or if wIndex specifies a Port that does not exist, or if wLength is
not as specified above.
If the Port on the PDUSB Hub is not operating as a Provider, the PDUSB Hub's response to this request is undefined.
If the PDUSB Hub is not configured, the PDUSB Hub's response to this request is undefined.

9.4.8 GetVDM (PDUSB Hub)

This request instructs the PDUSB Hub to return the VDMs that it received from a cable or device attached to a Port in a
PDUSB Hub. The response to each request shall contain only one VDM. VDMs shall be returned in the order they were
received by the Port. If there are no VDMs to return for the Port the PDUSB Hub shall return a zero length packet.
bmRequestType bRequest wValue wIndex wLength Data

10100011B GET_VDM Zero Port Number Variable VDM

The wIndex field shall indicate the PD capable Port that is being queried. The Port number shall be a valid Port
number for that PDUSB Hub, greater than zero.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 481
The wLength field shall be a multiple of 4 and shall include all the VDOs that the PDUSB Hub received on that Port (see
Section 6.4.4).
It shall be a Request Error if wIndex specifies a Port that does not exist, or if wValue or wLength is not as specified
above.
If the PDUSB Hub is not configured, the PDUSB Hub's response to this request is undefined.

9.4.9 SendVDM (PDUSB Hub)

This request instructs the PDUSB Hub to send a VDM to the one of three possible recipients (SOP, SOP’ or SOP’’)
attached to a Port in a PDUSB Hub.
bmRequestType bRequest wValue wIndex wLength Data

00100011B SEND_VDM SOP/SOP’/SOP” Port Number Variable VDM

The wIndex field shall indicate the PD capable Port that is being queried. The Port number shall be a valid Port
number for that PDUSB Hub, greater than zero.
The wValue field indicates the recipient. If the value is 0 it shall be sent to its Port partner. If the value is 1 it shall be
sent to SOP’. If the value is 2 it shall be sent to SOP”. No other values in wValue are allowed.
The wLength field shall be a multiple of 4 and shall include one VDM (see Section 6.4.4) that the Port shall send to the
recipient indicated by wValue.
It shall be a Request Error if wIndex specifies a Port that does not exist, or if wValue or wLength is not as specified
above.
If the PDUSB Hub is not configured, the PDUSB Hub's response to this request is undefined.

Page 482 USB Power Delivery Specification Revision 2.0, Version 1.1
 A. Power Profiles
Power Profiles are optional normative. They define a standardized set of voltages at several current ranges that are
offered by USB Power Delivery Sources. The profiles are defined for Sources only.
The Power Profiles are optional but are intended to provide a finite set of power levels to:
 Limit the number of voltages and current combinations a Source has to supply
 Provide a well-defined set of voltage and current combinations from which a Sink can choose
 Provide a selection of power ranging from 10W to 100W in approximately 2x steps
 Limit the number of valid combinations

A.1 Profile Definitions

There are the following profiles based on Fixed Supply Objects:
 Profile 0 reserved
 Profile 1 capable of supplying at least 5V @ 2.0A
 Profile 2 ports are capable of supplying at least 5V@ 2.0A, 12V @ 1.5A.
 Profile 3 ports are capable of supplying at least 5V @ 2.0A, 12V @ 3A.
 Profile 4 ports are capable of supplying at least 5V @ 2.0A, 12V and 20V at 3A respectively.
 Profile 5 ports are capable of supplying at least 5V @ 2.0A, 12V and 20V at 5A respectively.
Power Profiles are defined to overlap such that a Device that requires a Profile 2 Source will operate equally well
when connected to a Profile 2 or any higher Profile Source.
Sources may have additional capabilities. For example a Source might advertise 5V @ 3.0A, 12V and 15V at 1.5A
respectively. It is a Profile 2 Source because it meets the Profile 2 requirements to supply 5V @ 2.0A and 12V @ 1.5A.
The fact that it can also supply 5V @ 3.0A and 15V will have no effect on a Device that wants a Profile 2 source.
Profile 5 Sources that are capable of 100W operation are subject to various worldwide safety standards. In order to
meet the most common safety standards, the continuous output power cannot exceed 100W and the continuous
output current cannot exceed 5A. The industry is well versed in meeting the safety requirements for such power
sources (e.g. Wall Warts). Refer to Figure A-1 for an interpretation of the safety requirements imposed by
IEC/UL60950 Table 2B.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 483
 Figure A-1 Interpretation of UL60950

8A Safety Limit
Output Current (A)

100VA Safety Limit

30V Safety Limit

Output Voltage (V)

A.2 Voltage Selection Rationale

Voltages used by the profiles were not picked randomly; this section describes the rationale behind the choices.
5V is the USB default that must be supported to provide interoperability with existing Devices. However, higher
voltages are needed to provide more power through USB connectors because of their current carrying capability.
12V was selected because it is very common in PCs and many other systems. The current limitation of the Micro USB
Connector family is 3A for the enhanced PD version. The use of 12V with 3A provides sufficient power to charge
tablets in the 20-30W range that use the Micro USB Connector.
20V was selected because larger systems, such as notebooks, often have 4 lithium cells in series and require charging
voltages in the 18-20V range. A sampling of systems showed that chargers for these systems were typically 19.5-20V.
Typical systems had chargers that supplied between 60W and 100W with the exception of a few very high-end
performance systems that were well over 100W. The 5A current limit of the PD enhanced Standard-A and Standard-B
connectors, with 20V allows up to 100W to be delivered to charge this class of Devices.

A.3 Relevance of Profiles to Sink Ports

Sinks do not have Power Profiles per se. A Sink Port only need to be compatible with the voltage and current offered
in one or more Power Profiles. This can lead to some interesting cases where Dual-Role ports are involved (see
Appendix 0 for examples). A dual- role Port may offer one Profile when operating as a Source and request power from
another Profile when operating as a Sink. For example, a tablet might offer Profile 1 (5V @ 2.0A) when operating as a
Source, but request power (12V @ 3A) supplied by a Profile 3 Source when operating as a Sink. Another example is a

Page 484 USB Power Delivery Specification Revision 2.0, Version 1.1
notebook computer with a Profile 2 Source Port it also uses as a Sink for charging which requires it be supplied with
20V @ 5A from a Profile 5 Source.

A.4 System Level Examples

The following examples are provided to help illustrate some typical system use cases. Examples using a notebook and
HDDs have been selected but the principles apply equally to other types of USB Power Delivery devices (e.g. printers,
scanners, tablets, phones, mp3 players etc.).

A.4.1 Notebook and HDD Examples

In the following two examples, the user has varying experiences attaching his hard disk-drive to a PD Port on his
notebook computer.

Figure A-2 Notebook is Capable of Meeting User’s Requirements

The notebook shown in Figure A-2 is able to supply up to PD profile 2. The larger HDD is able to successfully operate
without a separate power adapter since it gets adequate power from the PD Port. In the case of the HDD with
separate power adapter plugged in, the HDD should not draw power from the notebook’s Port.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 485
 Figure A-3 Notebook is not Capable of Meeting User’s Requirements

Note that in the case shown in Figure A-3, the experience for the user is not unlike their experience today. USB HDDs
that attempt to rely only on USB bus power only will often fail because not all notebooks on the market are capable of
supplying adequate current.

A.4.2 Display with Hub Example

The following example is for a display dock where the integrated hub also provides power and at least one of the hub
ports is of high enough power capacity to power the host platform.

Page 486 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure A-4 Display with Integrated Hub Capable of Meeting User’s Requirements

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 487
 B. CRC calculation
B.1 C code example
//
// USB PD CRC Demo Code.
//
#include <stdio.h>

int crc;

//-----------------------------------------------------------------------------

void crcBits(int x, int len) {

const int poly = 0x04C11DB6; //spec 04C1 1DB7h

int newbit,newword,rl_crc;

for(int i=0;i<len;i++) {

newbit = ((crc>>31) ^ ((x>>i)&1)) & 1;

if(newbit) newword=poly; else newword=0;
rl_crc = (crc<<1) | newbit;
crc = rl_crc ^ newword;
printf("%2d newbit=%d, x>>i=0x%x, crc=0x%x\n",i,newbit,(x>>i),crc);
}
}

int crcWrap(int c){

int ret = 0;
int j, bit;

c = ~c;
printf("~crc=0x%x\n",c);

for(int i=0;i<32;i++) {
j = 31-i;

bit = (c>>i) & 1;

ret |= bit<<j;

Page 488 USB Power Delivery Specification Revision 2.0, Version 1.1
 }
return ret;

//-----------------------------------------------------------------------------

int main(){

int txCrc=0,rxCrc=0,residue=0,data;

printf("using packet data 0x%x\n", data=0x0101);

crc = 0xffffffff;
crcBits(data,16);
txCrc = crcWrap(crc);

printf("crc=0x%x, txCrc=0x%x\n",crc,txCrc);

printf("received packet after decode= 0x%x, 0x%x\n",data,txCrc);

crc = 0xffffffff;
crcBits(data,16);
rxCrc = crcWrap(crc);

printf("Crc of the received packet data is (of course) =0x%x\n",rxCrc);

printf("continue by running the transmit crc through the crc\n");

crcBits(rxCrc,32);

printf("Now the crc residue is 0x%x\n",crc);

printf("should be 0xc704dd7b\n");

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 489
 B.2 Table showing the full calculation over one Message
CRC register CRC register CRC register CRC register
Function Nibble Symbol Bits bit nr. Function Nibble Symbol Bits bit nr.
transmitter receiver transmitter receiver
0 FFFFFFFF FFFFFFFF 1 1 FFFFFFFF FFFFFFFF 85
1 FFFFFFFF FFFFFFFF 2 0 FFFFFFFE FFFFFFFF 86
#1
0 FFFFFFFF FFFFFFFF 3 #09 0 FB3EE24B FFFFFFFF 87
1 FFFFFFFF FFFFFFFF 4 1 F2BCD921 FFFFFFFF 88
0 FFFFFFFF FFFFFFFF 5 0 E1B8AFF5 FFFFFFFF 89
1 FFFFFFFF FFFFFFFF 6 0 E1B8AFF5 FFFFFFFF 90
0 FFFFFFFF FFFFFFFF 7 1 C7B0425D FFFFFFFE 91
#0
1 FFFFFFFF FFFFFFFF 8 #1E 1 8BA1990D FB3EE24B 92
0 FFFFFFFF FFFFFFFF 9 1 13822FAD F2BCD921 93
GoodCRC
1 FFFFFFFF FFFFFFFF 10 1 27045F5A E1B8AFF5 94
Header
0 FFFFFFFF FFFFFFFF 11 1 27045F5A E1B8AFF5 95
#0101
1 FFFFFFFF FFFFFFFF 12 0 4AC9A303 C7B0425D 96
#1
0 FFFFFFFF FFFFFFFF 13 #09 0 95934606 8BA1990D 97
1 FFFFFFFF FFFFFFFF 14 1 2FE791BB 13822FAD 98
0 FFFFFFFF FFFFFFFF 15 0 5FCF2376 27045F5A 99
1 FFFFFFFF FFFFFFFF 16 0 5FCF2376 27045F5A 100
0 FFFFFFFF FFFFFFFF 17 1 BF9E46EC 4AC9A303 101
#0
1 FFFFFFFF FFFFFFFF 18 #1E 1 7BFD906F 95934606 102
0 FFFFFFFF FFFFFFFF 19 1 F7FB20DE 2FE791BB 103
1 FFFFFFFF FFFFFFFF 20 1 EB375C0B 5FCF2376 104
0 FFFFFFFF FFFFFFFF 21 0 EB375C0B 5FCF2376 105
1 FFFFFFFF FFFFFFFF 22 1 EB375C0B BF9E46EC 106
#8
0 FFFFFFFF FFFFFFFF 23 #12 0 EB375C0B 7BFD906F 107
1 FFFFFFFF FFFFFFFF 24 0 EB375C0B F7FB20DE 108
0 FFFFFFFF FFFFFFFF 25 1 EB375C0B EB375C0B 109
1 FFFFFFFF FFFFFFFF 26 0 EB375C0B EB375C0B 110
0 FFFFFFFF FFFFFFFF 27 0 EB375C0B D2AFA5A1 111
#2
1 FFFFFFFF FFFFFFFF 28 #14 1 EB375C0B A19E56F5 112
P 0 FFFFFFFF FFFFFFFF 29 0 EB375C0B 47FDB05D 113
r 1 FFFFFFFF FFFFFFFF 30 1 EB375C0B 8B3A7D0D 114
e 0 FFFFFFFF FFFFFFFF 31 1 EB375C0B 8B3A7D0D 115
a 1 FFFFFFFF FFFFFFFF 32 0 EB375C0B 12B5E7AD 116
#3
m 0 FFFFFFFF FFFFFFFF 33 #15 1 EB375C0B 21AAD2ED 117
b 1 FFFFFFFF FFFFFFFF 34 0 EB375C0B 4355A5DA 118
l 0 FFFFFFFF FFFFFFFF 35 1 EB375C0B 86AB4BB4 119
e 1 FFFFFFFF FFFFFFFF 36 1 EB375C0B 86AB4BB4 120
0 FFFFFFFF FFFFFFFF 37 0 EB375C0B 0D569768 121
CRC-32 = #1
1 FFFFFFFF FFFFFFFF 38 #09 0 EB375C0B 1E6C3367 122
swapped
0 FFFFFFFF FFFFFFFF 39 1 EB375C0B 3CD866CE 123
and
1 FFFFFFFF FFFFFFFF 40 0 EB375C0B 79B0CD9C 124
inverted
0 FFFFFFFF FFFFFFFF 41 1 EB375C0B 79B0CD9C 125
EB375C0B
1 FFFFFFFF FFFFFFFF 42 1 EB375C0B F7A0868F 126
= #5
0 FFFFFFFF FFFFFFFF 43 #0B 0 EB375C0B EB8010A9 127
2FC51328
1 FFFFFFFF FFFFFFFF 44 1 EB375C0B D3C13CE5 128
0 FFFFFFFF FFFFFFFF 45 0 EB375C0B A343647D 129
1 FFFFFFFF FFFFFFFF 46 0 EB375C0B A343647D 130
0 FFFFFFFF FFFFFFFF 47 1 EB375C0B 4686C8FA 131
#C
1 FFFFFFFF FFFFFFFF 48 #1A 0 EB375C0B 8D0D91F4 132
0 FFFFFFFF FFFFFFFF 49 1 EB375C0B 1A1B23E8 133
1 FFFFFFFF FFFFFFFF 50 1 EB375C0B 343647D0 134
0 FFFFFFFF FFFFFFFF 51 1 EB375C0B 343647D0 135
1 FFFFFFFF FFFFFFFF 52 0 EB375C0B 686C8FA0 136
#F
0 FFFFFFFF FFFFFFFF 53 #1D 1 EB375C0B D0D91F40 137
1 FFFFFFFF FFFFFFFF 54 1 EB375C0B A1B23E80 138
0 FFFFFFFF FFFFFFFF 55 1 EB375C0B 43647D00 139
1 FFFFFFFF FFFFFFFF 56 0 EB375C0B 43647D00 140
0 FFFFFFFF FFFFFFFF 57 0 EB375C0B 8209E7B7 141
#2
1 FFFFFFFF FFFFFFFF 58 #14 1 EB375C0B 0413CF6E 142
0 FFFFFFFF FFFFFFFF 59 0 EB375C0B 0CE6836B 143
1 FFFFFFFF FFFFFFFF 60 1 EB375C0B 1D0C1B61 144
0 FFFFFFFF FFFFFFFF 61 1 EB375C0B 1D0C1B61 145
1 FFFFFFFF FFFFFFFF 62 0 EB375C0B 3A1836C2 146
0 FFFFFFFF FFFFFFFF 63 EOP #0D 1 EB375C0B 70F17033 147
1 FFFFFFFF FFFFFFFF 64 1 EB375C0B E1E2E066 148
0 FFFFFFFF FFFFFFFF 65 0 EB375C0B C704DD7B 149
0 FFFFFFFF FFFFFFFF 66
Sync1
0 FFFFFFFF FFFFFFFF 67
(#18) Note: CRC transmitter is calculated over data bytes
1 FFFFFFFF FFFFFFFF 68
only, in casu marked nibbles, and calculation results
1 FFFFFFFF FFFFFFFF 69
are available one (bit-) clock later
0 FFFFFFFF FFFFFFFF 70
0 FFFFFFFF FFFFFFFF 71
Sync1
0 FFFFFFFF FFFFFFFF 72
(#18) Note: CRC receiver is calculated over data bytes and
1 FFFFFFFF FFFFFFFF 73
S received CRC bytes, in casu marked nibbles, and
1 FFFFFFFF FFFFFFFF 74
O calculation results are available five (bit-) clocks later
0 FFFFFFFF FFFFFFFF 75
P
0 FFFFFFFF FFFFFFFF 76
Sync1
0 FFFFFFFF FFFFFFFF 77 Fixed residual
(#18)
1 FFFFFFFF FFFFFFFF 78
1 FFFFFFFF FFFFFFFF 79
1 FFFFFFFF FFFFFFFF 80
0 FFFFFFFF FFFFFFFF 81
Sync2
0 FFFFFFFF FFFFFFFF 82
(#11)
0 FFFFFFFF FFFFFFFF 83
1 FFFFFFFF FFFFFFFF 84

Page 490 USB Power Delivery Specification Revision 2.0, Version 1.1
 C. Power Implementation Considerations
This section has been added as an informative guide for implementers of the PD specification. Expansion of USB
Power Delivery to higher voltage and power levels with its AC coupled communication over V BUS requires new design
considerations to the power delivery system. Many of these may not have been as important in legacy USB systems,
but should be considered when implementing the PD specification. Component labels within this Appendix are
specific to the Appendix unless otherwise stated.

C.1 Managing Isolation Impedance (BFSK)

The isolation impedance outlined in the PD Specification Section 5.8.2.2 is used to block specific frequency bands and
pass others in order to provide a communication path on the VBUS conductor. This impedance will likely be inductive
in nature (for example a 1µH inductor see Table 5-17). The following section describes potential problems that may
arise due to this impedance. Measurement techniques to validate conducted noise will be discussed.

Figure C-1 Typical System Electrical Model

Vsrc PROVIDER CONSUMER

VBUS_P VBUS_C Vload

zIsolation_P zIsolation_C

Power USB CABLE Cfilt_C

Cfilt_P cAC-Coupling_P cAC-Coupling_C
Converter
Power
or
Converter
Power
Mux
Vxcvr_P Vxcvr_C

Load
Transceiver Transceiver

rTX rTX

C.1.1 In-band fCarrier Spurious Noise

The output stage of a switch mode power converter can typically produce high frequency noise. This noise is
differentiated from fundamental switching ripple. The noise tends to be a high frequency damped sinusoid occurring
regularly at the converter power switch transitions. It is likely that some implementations will produce noise that
coincides with the fCarrier frequency band of the transceivers.
Figure C-2 shows parasitic elements within a basic synchronous buck power stage that can generate high frequency
conducted noise which may interfere with the PD Transceiver. A basic synchronous buck stage is shown that is
comprised of two power MOSFETs, HS_FET and LS_FET, an inductor, L_out, and output filter capacitor, C_filt. Also
shown are the parasitic elements that create damped sinusoid noise that may be in contention with fCarrier.
L_HSSRC, L_LSDRV, and CDS_LSFET are typically responsible for creating resonant noise on the VSW node. Other
topologies may have different parasitic elements to consider. This waveform can couple to the output through C_ind
and or circuit board parasitics and impose a voltage across R_Cfilr_ESR. This section is meant to help implementers
identify and resolve noise problems in the design process before submitting PD designs to compliance testing.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 491
 C.1.2 Spurious Noise Test Setup and Calibration
Figure C-2 Typical Synchronous Buck Power Stage with Parasitics

Vsource

HS_FET
Vsw
C_ind

L_HSSRC

Vsw L_out

L_LSDR
C_filt

LS_FET R_Cfilt_ESR

CDS_LSFET

Measurement of in-band spurious noise from the power converter involves setting up measurement equipment with
the correct scales and impedances. The process involves calibrating a known carrier signal in a test setup containing
the correct source and load impedances with the power converter connected, but not operational. Once the test setup
is calibrated, the operational noise can be evaluated. In order to simplify this test and to match industry standard
communication test equipment, 50 Ohm terminations and dBm scaled measurements will be used.
Measurement of in-band spurious noise will require the use of:
 An RF signal generator capable of providing a vTX nominal (150mVrms), fCarrier nominal (23MHz) carrier sine
wave into a 50 ohm load.
 An oscilloscope with at least 200MHz Bandwidth.
 A spectrum analyzer with better than -80dBm measurement capability and 2MHz/div scale capability at 23MHz
center frequency setting.
 A low noise environment with less than -60dBm of RF noise at 13 to 33MHz.
Figure C-3 shows the test setup which includes both the Provider and Consumer to be connected using PD USB cables.
During calibration the power converter and load impedances should be in place with the power converter turned off.

Page 492 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure C-3 Spurious Noise Measurement Test Setup
Noise Free
Source PROVIDER CONSUMER

Power
Converter VBUS_P VBUS_C Vload
or
Power
Mux zIisolation_P zIsolation_C

USB CABLE
Cfilt_P cAC-Coupling_P cAC-Coupling_C Cfilt_C

Noise
Free
Load

Spectrum 23 MHz
Analyzer Signal 50
50 Generator

1) Using appropriately matched RF cabling configure the test setup as shown in Figure C-3 set the termination
for both the signal generator and the spectrum analyzer to 50 ohms.
2) Set the signal generator to ((vTX minimum x 1.414) x 2) Peak to Peak (~282mV) at fCarrier nominal
(23MHz). Confirm the level using an oscilloscope.
3) Set the spectrum analyzer to fCarrier nominal (23MHz) Center Frequency, fCarrier nominal ± 10MHz span
and set the Resolution Bandwidth (RBW) to 10 KHz.
4) Confirm that the measured level on the Spectrum Analyzer is approximately - 7 to -13 dBm (dBMilliwatts on
50 Ohms). Record the Baseline level (dBM Baseline).
5) Confirm that no spurious noise levels are present above -60dBm. If the noise floor is higher, it may be
necessary to test in an environment with EMI shielding from radio noise sources.
6) Turn on the power converter and turn off the fCarrier nominal signal from the signal generator.
7) Confirm that the noise floor has not increased beyond (dBm_Baseline – snrSrc). Reference Figure 7-8 for in-
band noise. The (dBm_Baseline – snrSrc) represents the 0dB level in Figure 7-8. Confirm that all measured
noise falls below the curve.
The same measurement can be made from the perspective of the Sink using a quiet source. In this case the frequency
generator is placed on the Provider side and the signal generator is placed on the Consumer side. The levels would be
compared to Figure 7-11 in this case.
* Noise levels should be validated across expected line and load conditions including expected combinations of USB
Cable types and lengths.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 493
 C.2 Connector Detach Transients
The presence of inductive elements zIsolation_P and zIsolation_C will cause transient voltages to be presented to the
transceiver inputs. This section describes this behavior and some protection methods that can be considered.

Figure C-4 Current Transients when Cable/Load Removed

Vsrc PROVIDER
CONSUMER

VBUS_P VBUS_C Vload

zIsolation_P zIsolation_C
USB
Cable
Detach
Power
Cfilt_P cAC-Coupling_P cAC-Coupling_C Cfilt_C
Converter
Power
or
Converter
Power
Mux

Iclamp_P Iclamp_C Load

Transceiver Transceiver

Transient protection for the transceiver

against detach and power supply fault
protection

As shown in Figure C-4, equal current is flowing in both isolation elements (zIsolation_P and zIsolation_C) within the
Provider and Consumer just prior to detach. Inductive elements resist changes in current and will force voltage
transients on VBUS_P and VBUs_C terminals just following detach. These high dv/dt rate voltages will AC couple through
the coupling capacitors cAC-Coupling_P and cAC-Coupling_C. A positive going voltage transient will be presented on
the Provider side and a negative going voltage transient will be presented on the Consumer side. Clamping elements
should be included or the transceiver should be capable of absorbing the energy of the attach and detach events to
prevent damage to the transceiver.

Page 494 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure C-5 Isolation Inductor Energy versus Load

Figure C-5 shows the total energy that could be delivered during a detach event with the example 1µH inductor
where:
𝐿𝐼 2
𝐸𝑛𝑒𝑟𝑔𝑦 =
2
An external or integrated clamp should be implemented to absorb this energy and limit the applied voltage at the
transceiver input.

C.3 Closed Loop Stability Effects

Addition of the isolation inductor as well as cable inductance will affect the small signal power stage response of a
switch mode power converter PD implementation.

C.3.1 Basic Power Stage Small Signal AC Model

Figure C-6 shows a simplified diagram of the small signal power stage AC response including the parasitic elements
that should be considered. Power stage response refers to the voltage regulation system around which a feedback
loop will be applied. This model does not include modulator gain or dc gain in the power stage as it is only meant to
display exemplary parasitic poles and zeroes in the typical system.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 495
 Figure C-6 Simplified Small Signal AC Model

IN OUT

=OUT/IN

10u 30m 1u 10m 100m 200n 10m 1u

Lout DCRout Lisolation_P DCRlisolation_P DCR_Cable Lcable DCRlisolation_C Lisolation_C

C_Filt_P C_Filt_C
100u 100u

AC 1 0
V1 50m 5m 50
ESR_Filt_P ESR_Filt_C RLOAD

1n 500p
ESL_Filt_P ESL_Filt_C

The dominant pole of the power converter is set by Lout and C_Filt_P assuming the value of Lout is larger than
(zIsolation_P + Lcable + zIsolation_C). Parasitic ESR (Equivalent Series Resistance) and ESL (Equivalent Series
Inductance) form high frequency zeroes in the power stage response gain and phase. Phase distortion is introduced
into the power stage response from (zIsolation_P + Lcable + zIsolation_C) interacting with C_Filt_C. Secondary high
frequency poles and zeroes can degrade phase margin in the feedback loop of the power converter. These effects
need to be modeled and accounted for when designing the feedback loop for stability and transient performance.
Figure C-7 shows the resulting phase and gain impacts of the parasitics using the model in Figure C-6.
These traces compare the power stage phase and gain with and without isolation inductance. In this case, a phase
boost is introduced which is not necessarily bad for compensation; however it is important for the designer to be
aware of these effects to maintain predictable stability and transient response.

Page 496 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure C-7 Power Stage Phase And Gain with and without Isolation Inductors
Y2 Y1

10

0 -20
Gain(w
Gain (with isolation
ith coupling inductor)
inductance)

-10 -40
Gain (w
Gain (without isolation
ithout coupling inductor)
inductance)

-20 -60
Phase / degrees
Gain / dB

-30
-80

-40
-100 Phase
Phase (w ith coupling
(with isolationinductance)
inductor)

-50
-120

-60
-140

-70
Phase
Phase (without isolationinductance)
(w ithout coupling inductor)
-160

100 200 500 1k 2k 5k 10k 20k 50k 100k 200k 500k 1M

Frequency / Hertz

It is important to note that worst case conditions tend to occur at:

 Light load (high Q Condition)
 Load capacitance highly tuned to series isolation inductance (high Q Condition)
 Main power converter LC pole (Lout, C_Filt_P) is selected too close to the parasitic LC ((zIsolation_P+
zIsolation_C), C_Filt_C)
It is also important to note that selection of a C_Filt_C capacitor network that has parasitic ESR large enough to de-
tune the dominant pole will help reduce the negative phase effects.

C.3.2 Feedback Past Isolation Inductor

It may be desirable to compensate the voltage loop past the Provider isolation inductor (zIsolation_P in order to
eliminate the IR voltage drop due to the DC Resistance of the inductor. This further complicates the power stage
response curve by placing the inductors reactance in series with the feedback path. Figure C-7 shows the same simple
model with feedback measured past the isolation inductor.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 497
 Figure C-8 Simplified Small Signal AC Model (Feedback before and after Inductor zIsolation_P)

IN OUT

=OUT/IN

10u 30m 1u 10m 100m 200n 10m 1u

Lout DCRout Lcoupl_P DCRcoupl_P DCR_Cable Lcable DCRcoupl_C Lcoupl_C

C_Filt_P C_Filt_C
100u 100u

AC 1 0
V1 5m 5m 50
ESR_Filt_P ESR_Filt_C RLOAD

1n 500p
ESL_Filt_P ESL_Filt_C

Figure C-8 compares power stage response with compensation taken before and after the zIsolation_P Provider
isolation inductor. As can be seen in in Figure C-9, the phase and gain impacts are larger. A pole is created by the
zIsolation_P inductor that forces a phase reduction beyond 180 degrees which will have to be accounted for in the
compensation network.

Figure C-9 Simplified Small Signal AC Model (Feedback before and after Inductor zIsolation_P)
Y2 Y1

10

Gain
Gain(with
(w ithFB
FBbefore
past
0 -20
isolation
coupling inductor)
inductance)

-10 -40
Gain (with FB past
Phase (w ith FB past
isolation inductor)
coupling inductance)
-20 -60
Phase / degrees

-30 -80
Gain / dB

Phase
Phase (w ith
(with FBFB before
before
coupling
isolation inductance)
inductor)
-40 -100

-50 -120

-60 -140

-70
-160
Phase
Phase (w ith
(with FB FB
pastpast
couplinginductor)
isolation inductance)
-80
-180
100 200 500 1k 2k 5k 10k 20k 50k 100k 200k 500k 1M

Frequency / Hertz

Page 498 USB Power Delivery Specification Revision 2.0, Version 1.1
 D. Standard-A Mating Illustrations
The following illustrations show the mating configurations between PD and non-PD Standard-A connectors. All
dimensions are in mm.

Figure D-1 USB 3.1 Standard-A Plug with USB 2.0 PD or 3.1 PD Standard-A Receptacle

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 499
 Figure D-2 USB 3.1 PD Standard-A Plug with USB 2.0 or 3.1 Standard-A Receptacle

Page 500 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure D-3 USB 2.0 PD or 3.1 PD Standard-A plug with USB 2.0 PD or 3.1 PD Standard-A receptacle

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 501
 Figure D-4 USB 2.0 PD or 3.1 PD Standard-A Plug with USB 2.0 Standard-A Receptacle

Page 502 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure D-5 USB 2.0 Standard-A Plug with USB 2.0 or USB3.1 PD Standard-A Receptacle

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 503
 Figure D-6 USB 2.0 Thin Card with USB 2.0 PD or 3.1 PD Standard-A Receptacle

Page 504 USB Power Delivery Specification Revision 2.0, Version 1.1
 Figure D-7 USB 3.1 Thin Card with USB 2.0 PD or 3.1 PD Standard-A Receptacle

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 505
 E. Physical Layer Informative Material
This section contains informative material about the Physical Layer.

E.1 Squelch Budget

Figure E-1 Squelch Budget

Page 506 USB Power Delivery Specification Revision 2.0, Version 1.1
Figure E-1 shows the signal levels in mV (rms) needed to illustrate the squelch budget for normal operation
(vSquelchOperating) and cable-type detection operation (vSquelchDetecting). The transmission level of the signal is
between 100mV and 200mV, or at least 26.5dB above a 3mV noise floor. During normal operation the nominal SNR is
25dB, packets with a signal level below 55mV may be discarded, and packets with a signal level below 35mV are
discarded. This allows for at least 5.2dB of attenuation in the channel and at most 15dB. During plug-type detection
the nominal SNR is 16.5dB, a signal level below 25mV may be discarded, and a signal level below 15mV must be
discarded. This allows for at least 12dB of attenuation in the channel and at most 22.5dB.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 507
 F. PD Message Sequence Examples
The following examples are intended to show how the Device Policy Manager may operate and the sequence of Power
Delivery messaging which will result. The aim of this section is to inform implementer’s how some of the mechanisms
detailed in this specification may be applied; it does not contain any normative requirements.
In these illustrations all A-Ports are assumed to implement the optional cold-socket functionality. VBUS is only applied
when an A-plug is inserted. In all cases Providers indicate all of the power they have available in their Capabilities and
Consumers only take the power they need and give back what they cannot use. In the case of Hubs this means only
taking sufficient power for the ports with A-plugs inserted.
All ports are assumed to be Enhanced SuperSpeed capable, with a default operating voltage of 5V and a unit load of
150mA. This 0.75W is assumed to be enough power to enable an externally powered device to maintain
communication over USB and is enough to allow such a device to enumerate but not operate until more power is
negotiated.
Although the Hubs in these illustrations support Power Delivery on both their UFPs and DFPs this is only one possible
Hub implementation.
HDDs are assumed to spin up immediately after they are attached. This follows the typical operation of current
systems.
Ideal power transmission is assumed so that there are no power losses through a device; in practice these would need
to be taken into account when requesting power.

F.1 External power is supplied downstream

Figure F-1 External Power supplied downstream

Laptop

AC

Display 1

Display 2

Configuration:
1. Laptop with an AC supply. AC supply provides sufficient power to charge the laptop and, in addition, to provide up
to 60W downstream via its Profile 4 Enhanced SuperSpeed Port.

Page 508 USB Power Delivery Specification Revision 2.0, Version 1.1
 2. Display 1 and Display 2 each require 30W to operate. Display 1 contains a Hub allowing Display 2 to be connected
to Display 1. In USB suspend each Display will power down but can maintain USB connection using the PD power
provided.

Table F-1 External power is supplied downstream

Step Laptop Display 1 Display 2 Device Policy PD Power

Manager (W)

Display 1

1 Connected to wall Unattached Unattached 0

supply

2 Display 1 attached, Attached, drawing Unattached 0.75

VBUS powered. 5V@150mA.

3 Set of Source Source Capabilities Unattached Laptop determines 0.75

Capabilities sent received its Source
including: 5V@2A Capabilities based
(10W), 12V@3A on its needs and
(36W) and 20V@3A the presence of a
(60W). wall supply.
The externally
powered and USB
suspend bits are set.

4 Request received Requests 20V@1.5A Unattached Display 1 knows it 0.75

(30W) from laptop needs 20v@1.5A
(30W) for its own
operation,
evaluates the
supplied
capabilities and
determines that
this is available.

5 Sends Accept Accept received Unattached Waiting for PS_RDY 0.75

before drawing
additional power.

6 Sends PS_RDY PS_RDY received. Unattached Laptop evaluates 30

Starts drawing the request, finds
20V@1.5A. Display 1 that it can meet
turns on and starts this and so sends
operating. an accept.

Display 2

7 Powering Display 1 Detects attach Attached, no VBUS 30

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 509
Step Laptop Display 1 Display 2 Device Policy PD Power
Manager (W)

8 Request received Display 1 requests Attached, no VBUS Display 1 detects 30

20V@1.73A (34.6W) attach and
from Laptop. requests additional
4.5W of power for
USB 3.1 Port.

9 Sends Accept Accept received. Attached, no VBUS 34.6

10 Sends PS_RDY PS_RDY received Attached, no VBUS

11 Powers VBUS Attached, drawing 34.6

5V@150mA.

12 Sends out Source Source Capabilities Display 1 has 4.5W 34.6

Capabilities including: received to allocate to
5V@0.9A to Display 2. Display 1. This is
The externally offered as a
powered and USB standard USB 3.1
suspend bits are set. Port.

13 Request received Display 2 requests Display 2 decides it 34.6

5V@0.15A but can manage to run
indicates a its USB/PD function
Capability with 1 unit load but
Mismatch. Display 2 needs more power
remains off. to function as a
display.

14 Sends Accept Accept received 34.6

15 Sends PS_RDY PS_RDY received Display 2 indicates 34.6

a capability
mismatch to the
user.

16 Get Sink Capabilities Get Sink Capabilities Display 1 needs to 34.6

sent received assess the
capability
mismatch by first
determining what
Display 2 actually
needs.

17 Sink Capabilities Display 2 returns 34.6

received Sink Capabilities
indicating operation
at 20V@1.5A.

Page 510 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Laptop Display 1 Display 2 Device Policy PD Power
Manager (W)

18 Request received Display 1 requests Display1 now 34.6

20V@3A (60W) from knows what
Laptop. Display 2 needs
and requests the
additional power
from the laptop.

19 Sends Accept Accept received. 34.6

20 Sends PS_RDY PS_RDY received An additional 30W 60

is now available to
Display 1 to offer
to Display 2.

21 Sends out Source Source Capabilities Now that Display 1 60

Capabilities including: received can power Display
5V@0.9A and 2 correctly this
20V@1.5A to Display power is offered by
2. The externally Display 1 via a new
powered and USB capabilities
suspend bits are set. Message.

22 Request received Display 2 requests 60

20V@1.5A.

23 Sends Accept Accept received Display 1 60

determines that
the request by
Display 2 is within
the offered
capabilities so the
request is
accepted.

24 Sends PS_RDY. PS_RDY received. Display 2 now has 60

Drawing 20V@3A from Starts drawing the power it needs
laptop. 20V@1.5A, turns on and can start
and starts working.
operating.

USB Suspend

25 Laptop OS goes into Display 1 turns off but Display 2 turns off No changes in 60
suspend (S3), VBUS draws 50mW, 25mW but draws 25mW to Contract. This is a
remains on but USB to maintain PDUSB maintain USB/PD power reduction
bus is also suspended. Hub functions. The functions. purely based on
additional 25mW is the USB state.
used to supply the
Port used by Display 2.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 511
 Step Laptop Display 1 Display 2 Device Policy PD Power
Manager (W)

26 Laptop OS wakes up. Display 1 turns on and Display 2 turns on No changes in PD 60

USB is woken up. returns to drawing and returns to Contract. This
20V@3A. drawing 20V@1.5A. purely relates to
USB bus state.

F.2 External power is supplied upstream

Figure F-2 External Power supplied upstream
Tablet

Display 1

Display 2

AC

Configuration:
1. Tablet with no AC supply. Tablet is a USB host and can use 12V@0.2A (1W) during normal operation and up to
12V@1A (12W) in order to charge.
2. Display 1 and Display 2 each require 30W to operate. Display 1 contains a Hub allowing Display 2 to be connected
to Display 1. In USB suspend each Display will power down but can maintain USB connection using the PD power
provided.
3. Display 2 has an AC supply connected. AC supply provides sufficient power to power Display 2 and, in addition, to
provide up to 60W upstream via a Profile 4 Port.

Table F-2 External power is supplied downstream

Step Tablet Display 1 Display 2 Device Policy PD Power

Manager (W)

Display 1 - Dead Battery

1 Unattached Unattached Connected to the 0

wall supply and
outputs vSafeDB
every 10-15s on its
UFP

Page 512 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Tablet Display 1 Display 2 Device Policy PD Power
Manager (W)

2 Attached to Display 2 Display 1 attached 0

3 Dead battery Dead battery 0

negotiation negotiation

4 Attached to Display 2, Providing 1 unit 0.75

drawing 5V@150mA load to Display 1.
(0.75W)

5 Source Capabilities Display2 sends out Based on the 0.75

received a set of capabilities capabilities of the
including: 5V@2A wall supply and its
(10W), 12V@3A own needs Display
(36W) and 20V@3A 2 calculates what it
(60W). The can offer upstream.
externally powered
and USB suspend
bits are set.

6 Display 1 requests Request received Display 1 knows it 0.75

20V@1.5A (30W) from needs 30W to
Display 2. operate so it
requests this
amount.

7 Accept received Sends Accept Display 2 accepts 0.75

the offer since it is
within its
capabilities.

8 PS_RDY received. Sends PS_RDY Display 2 indicates 30

Display 1 starts drawing its power supply is
power and turns on. ready to offer the
power.

Tablet – Power Role Swap

9 Tablet is attached to Attached, VBUS 30

Display 1. powered.

10 Tablet sends out a set Capabilities received 30

of capabilities
including: 5V@0.5A
(2.5W). The
externally powered bit
cleared and USB
suspend bit set.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 513
Step Tablet Display 1 Display 2 Device Policy PD Power
Manager (W)

11 Request received Display 1 requests Display 1 has 30

5V@0A from the external power
Tablet. The externally providing
powered and Dual-Role everything it needs
Power bits are set. so it does not
request any more.

12 Sends Accept Accept received. No power has been 30

requested from the
Tablet so the tablet
has no reason to
Reject this.

13 Sends PS_RDY PS_RDY received. Table completes 30

the Explicit
Contract by sending
PS_RDY.

14 Get Sink Capabilities Sends Get Sink Display 1 has access 30

received. Capabilities to an external
supply so it needs
to check whether
the Tablet
upstream, which
has no external
supply, could use
some power.
Display 1 also
knows that there is
excess capacity,
based on the last
capabilities it
received, which it is
not currently using
from Display 2.

15 The Tablet returns Sink Capabilities 30

Sink Capabilities received
indicating that it is a
Dual-Role and that it
can use 12V@0.2A
(2.4W) as a Sink.

16 Display 1 requests Request received 30

20V@1.62A (32.4W)
from Display 2.

17 Accept received Sends Accept Request is within 30

the available power
so Display 2 sends
an accept.

Page 514 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Tablet Display 1 Display 2 Device Policy PD Power
Manager (W)

18 PS_RDY received Sends PS_RDY Display 2 indicates 32.4

that the power
supply is ready to
supply the power.

19 PR_Swap received Requests PR_Swap Display 1 now 32.4

from Tablet. offers to provide
power to the Tablet
by initiating a
Power Role Swap.

20 Accept sent. Tablet Accept received. Tablet is happy to 32.4

turns off its VBUS accept a Power
supply. Role Swap from any
device offering it
power.

21 Send PS_RDY PS_RDY received. Tablet indicates 32.4

Display 1 turns on its that its supply has
VBUS supply been turned off.

22 PS_RDY received. PS_RDY sent. Display 1 indicates 32.4

that its power
supply is ready so
the Tablet starts
drawing power.

23 Source Capabilities Display 1 sends out a 32.4

received set of capabilities to the
Tablet including:
5V@0.48A (2.4W),
12V@0.2A (2.4W) and
20V@0.12 (2.4W). The
externally powered and
USB suspend bits are
set.

24 The Tablet requests Request received. Tablet can now 32.4

12V@0.2A. request the power
it needs.

25 Accept received Accept sent Power is within the 32.4

capabilities of
Display 1 so it
accepts the
request.

26 PS_RDY received. The PS_RDY sent Display 1 indicates 32.4

Tablet starts drawing that its power
12V@0.2A. supply is ready so
the tablet starts
drawing the power.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 515
Step Tablet Display 1 Display 2 Device Policy PD Power
Manager (W)

Tablet – Charge

27 Tablet requests Request received. Tablet needs to 32.4

12V@0.2A (2.4W) charge but the
from Display 1. The power offered is
Tablet needs to not sufficient.
charge and so sets the Since Display 1
Capability Mismatch claims to have an
bit and the No USB external supply the
Suspend bit. Tablet will try to get
more power using
the Capability
Mismatch Flag.

28 Accept received Accept sent A valid request has 32.4

been made so
Display 1 accepts
the request.

29 PS_RDY received PS_RDY received Tablet indicates a 32.4

capability mismatch
to the user.

30 Get Sink Capabilities Get Sink Capabilities Due to the 32.4

received. sent Capability
Mismatch Flag
Display 1 requests
Sink Capabilities
from the Tablet.

31 The Tablet returns Sink Capabilities 32.4

Sink capabilities received
containing: 12V@1A
(12W). The externally
powered bit is
cleared.

Page 516 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Tablet Display 1 Display 2 Device Policy PD Power
Manager (W)

32 Display 1 requests Request received Since the Tablet 32.4

20V@2.1A (42W) from requires an
Display 2. The No additional 12W of
Suspend Bit is set to power, and Display
reflect the request from 1 knows that this is
the Tablet. available from
Display 2 based on
the last Capabilities
received so it
requests it. In
addition the
Request from the
Tablet indicated
that it wanted No
Suspend so this is
reflected upwards.

33 Accept received Sends Accept Display 2 has 42W 42

available and so
accepts the
request.

34 PS_RDY received Sends PS_RDY Display 2 completes 42

the Explicit
Contract but at this
point has not
accepted that
power can be
drawn during
suspend.

35 Source Capabilities Display2 sends out Based on the 42

received a new set of capabilities of the
capabilities wall supply and its
including: 5V@2A own needs Display
(10W), 12V@3A 2 calculates what it
(36W) and 20V@3A can offer upstream.
(60W). The It decides that it
externally powered can continue to
and USB suspend supply the power
bits is now set to even during USB
zero. suspend and so
resets the USB
suspend bit.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 517
Step Tablet Display 1 Display 2 Device Policy PD Power
Manager (W)

36 Display 1 requests Request received Display 1 repeats its 42

20V@2.1A (42W) from request since a new
Display 2. The No set of Capabilities
Suspend Bit is set to have been sent out.
reflect the request from
the Tablet.

37 Accept received Sends Accept Display 2 has 42W 42

available, even
during suspend,
and so accepts the
request.

38 PS_RDY received Sends PS_RDY Display 2 completes 42

the Explicit
Contract.

39 Capabilities received Display 1 sends out a Display 1 now has 42

set of capabilities to the the additional
Tablet including: power available
5V@0.5A (2.5W), and so offers this to
12V@1A (12W) and the Tablet.
20V@0.6A (12W). The
externally powered bit
is set and USB suspend
bit is cleared.

40 Tablet requests Request received. Tablet is being 42

12V@1A (12W) from offered the power
Display 1. it needs to charge
and so the Tablet
requests this from
Display 1.

41 Accept received Sends Accept Request is within 42

the available
Display 1's available
power and so it
accepts the
request.

42 PS_RDY received. Sends PS_RDY Display 1 indicates 42

Tablet starts drawing its supply is ready
12V@1A from Display to supply power.
1 and starts to charge.

Page 518 USB Power Delivery Specification Revision 2.0, Version 1.1
 F.3 Giving back power
Figure F-3 Giving Back Power

Laptop

AC

Hub

Hard Hard
Disk Disk Phone
Drive 1 Drive 2

Configuration:
1. Laptop with an AC supply. AC supply provides sufficient power to charge the laptop and, in addition, to provide up
to 60W downstream via a Profile 4 Port.
2. A Hub with 4 downstream ports which initially provides 1 unit load (150mA) per Port plus 1 unit load for its
internal functions.
3. Two Hard Disk Drives both of which require 20V@0.5A (10W) to spin up and 20V@0.25A (5W) while being
accessed.
4. A phone which uses 5V@2A (10W) to charge and can give back all of this power when requested.

Table F-3 Giving back power

Step Laptop Hub Peripherals Device Policy Hub Power

Manager (W)

Connect Hub

1 Connected to wall Unattached Unattached Default

supply

2 Hub is attached Attached, VBUS Default

powered

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 519
 Step Laptop Hub Peripherals Device Policy Hub Power
Manager (W)

3 Laptop sends out a Source Capabilities Laptop sends out Default

set of capabilities received details of all
including: 5V@2A available power via
(10W), 12V@3A external supply
(36W), 20V@3A
(60W). The
externally powered
and USB suspend
bits are set.

4 The Hub requests Request received Hub needs 1 unit Default

5V@0.15A. This is load for its own
the power for the operation and so
Hubs internal requests this
operation. amount.

5 Send Accept Accept received Laptop evaluates 0.75

request and it is
within its available
power.

6 Send PS_RDY PS_RDY received. Laptop indicates 0.75

Starts to draw that its power
5V@0.15A supply is ready.

Connect Hard Disk Drive 1

7 Attached detected. Hard Disk Drive 1 is 0.75

attached to one of
the downstream
ports of the Hub.

8 Request received The Hub requests Hub needs 0.75W 0.75

5V@0.3A (1.5W) for its own
from the Laptop. operation plus
0.75W for USB
communication on
one Port.

9 Accept sent Accept received Request is within 1.5

available power so
the laptop accepts.

10 PS_RDY sent PS_RDY received Laptop indicates 1.5

that its power
supply is ready

Page 520 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Laptop Hub Peripherals Device Policy Hub Power
Manager (W)

11 Hub turns on VBUS Source Capabilities 1.5

and sends out a set received
of capabilities to
Hard Disk Drive 1
including:
5V@0.15A. The
externally powered
and USB suspend
bits are set.

12 Request received Hard Disk Drive 1 Hard Disk Drive 1 1.5

requests only needs one
5V@0.15A from unit load when not
the Hub. operating so
requests this.

13 Accept sent Accept received Request is within 1.5

available power so
the Hub accepts.

14 PS_RDY sent PS_RDY received. Laptop indicates its 1.5

The Hard Disk Drive power supply is
starts drawing 1 ready and the Hard
unit load Disk Drive starts
5V@0.15A. drawing power.

Hard Disk Drive 1 spin up

15 Request received Hard Disk Drive 1 Hard Disk Drive 1 1.5

requests needs 20V@0.5A
5V@0.15A from to spin up but this
the Hub but sets is not available so
the Capability it re-requests the
Mismatch bit. available power
flagging a
capability
mismatch.

16 Accept sent Accept received Request is within 1.5

available power so
the Hub accepts.

17 PS_RDY sent PS_RDY received Hard Disk Drive 1 1.5

indicates a
capability
mismatch to the
user.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 521
 Step Laptop Hub Peripherals Device Policy Hub Power
Manager (W)

18 The Hub requests Get Sink Due to the 1.5

the Sink Capabilities Capabilities Capability
from Hard Disk Drive received Mismatch the Hub
1. needs to
determine what
Hard Disk Drive 1
actually needs

19 Sink Capabilities Hard Disk Drive 1 1.5

received returns capabilities
indicating that it
requires
20V@0.5A.

20 Request received The Hub requests The Hub evaluates 1.5

20V@0.54A (10.8W) that it now needs
from the Laptop. 0.75W for the Hub
and 10W for Hard
Disk Drive 1.

21 Accept sent Accept received Power request 10.8

from the Hub is
within the Laptop's
capabilities so the
Laptop accepts the
request.

22 PS_RDY sent PS_RDY received Laptop completes 10.8

the Explicit
Contract.

23 Hub sends out a set Source Capabilities Hub now offers 10.8
of capabilities to received Hard Disk Drive 1
Hard Disk Drive 1 what it needs.
including: 5V@0.5A
and 20V@0.5A. The
externally powered
and USB suspend
bits are set.

24 Request received Hard Disk Drive 1 Hard Disk Drive 1 is 10.8

requests operating at its
20V@0.5A maximum current
operating current to spin up so sets
and indicates operating current =
20V@0.5A maximum current.
maximum current.

25 Accept sent Accept received Request is within 10.8

the Hubs
capabilities so it
accepts.

Page 522 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Laptop Hub Peripherals Device Policy Hub Power
Manager (W)

26 PS_RDY sent PS_RDY received. Hub indicates its 10.8

Hard Disk Drive 1 power supply is
starts to draw ready so Hard Disk
20V@0.5A and Drive 1 starts to
spins up. draw power.

27 Request received Once spun up Hard Hard Disk Drive 1 is 10.8

Disk Drive 1 operating at a
requests lower current so
20V@0.25A sets operating
operating current current <
and 20V@0.5A maximum current.
maximum current.

28 Accept sent Accept received The Hub will 10.8

maintain a Power
Reserve of
20V@0.25A (5W)
for Hard Disk Drive
1 in addition to the
20V@0.25A (5W) it
is currently using.

29 PS_RDY sent PS_RDY received Hub completes the 10.8

Explicit Contract.

Hard Disk Drive 2 spin up

30 Attach detected Hard Disk Drive 2 is 10.8

attached to one of
the downstream
ports of the Hub.

31 Request received The Hub requests The Hub needs 10.8

20V@0.58A (11.6W) 0.75W for itself,
from the Laptop. 0.75W for USB
communication on
one Port, 5W for
Hard Disk Drive 1
operation and 5W
for the Power
Reserve.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 523
 Step Laptop Hub Peripherals Device Policy Hub Power
Manager (W)

32 Accept sent Accept received Power request 10.8

from the Hub is
within the Laptop's
capabilities so it
accepts the
request.

33 PS_RDY sent PS_RDY received Laptop indicates its 11.6

power supply is
ready.

34 Hub sends out a set Source Capabilities Hub offers Hard 11.6
of capabilities to received by Hard Disk Drive 2
Hard Disk Drive 2 Disk Drive 2 enough power to
including: enumerate.
5V@0.15A. The
externally powered
and USB suspend
bits are set.

35 Request received Hard Disk Drive 2 11.6

requests
5V@0.15A from
the Hub.

36 Accept sent to Hard Accept received by Request is within 11.6

Disk Drive 2 Hard Disk Drive 2 available
capabilities so the
Hub accepts

37 PS_RDY sent to Hard PS_RDY received. Hard Disk Drive 2 11.6

Disk Drive 2. Hard Disk Drive 2 takes the power
starts drawing that it needs
5V@0.15A.

Phone charge

38 Attach detected The phone is 11.6

attached to one of
the downstream
ports of the Hub.

Page 524 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Laptop Hub Peripherals Device Policy Hub Power
Manager (W)

39 Request received The Hub Requests The Hub needs 11.6

20V@0.62A (12.4W) 0.75W for itself,
from the Laptop. 1.5W for USB
communications
on two ports (Hard
Disk Drive 1 and
the Phone), 5W for
Hard Disk Drive 1
operation and 5W
for the Power
Reserve.

40 Accept sent Accept received Request is within 12.4

available
capabilities so the
Laptop accepts

41 PS_RDY sent PS_RDY received Laptop indicates 12.4

that its power
supply is ready.

42 The Hub powers VBUS Source Capabilities The Hub offers the 12.4
and sends out a set received by the Phone 1 unit load
of capabilities to the Phone to enumerate.
Phone including:
5V@0.15A. The
externally powered
and USB suspend
bits are set.

43 Request received The Phone The Phone would 12.4

from the Phone requests like to charge and
5V@0.15A from so indicates this
the Hub but sets fact through the
the Capability Capability
Mismatch bit. Mismatch bit.

44 Accept sent Accept received Request is within 12.4

available
capabilities so the
Hub accepts

45 PS_RDY sent PS_RDY received Hub indicates that 12.4

its power supply is
ready

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 525
 Step Laptop Hub Peripherals Device Policy Hub Power
Manager (W)

46 The Hub requests Get Sink Due to the 12.4

the Sink Capabilities Capabilities Capability
from the phone. received by the Mismatch the Hub
Phone needs to
determine what
the Phone actually
needs

47 Sink Capabilities The Phone returns Phone returns the 12.4

received from the capabilities Capabilities it
Phone indicating that it needs to charge
requires 5V@2A.

48 Request received The Hub Requests The Hub needs 12.4

20V@1.12A (22.4W) 0.75W for itself,
from the Laptop. 0.75W for Hard
Disk Drive 2, 10W
for the phone, 5W
for Hard Disk Drive
1 operation and
5W for the Power
Reserve.

49 Accept sent Accept received Request is within 12.4

available
capabilities so the
Laptop accepts

50 PS_RDY sent PS_RDY received Laptop indicates 22.4

that its power
supply is ready.

51 The Hub sends out a Source Capabilities The Hub now has 22.4
set of capabilities to received by the the power that the
the Phone including: Phone Phone needs and
5V@2A. The so sends out a new
externally powered set of Capabilities.
and USB suspend
bits are set.

52 Request received The Phone The Phone 22.4

from the Phone requests 5V@2A requests the power
from the Hub and it needs to charge.
sets the No USB It asks for the USB
Suspend bit since it Suspend
needs to charge requirement to be
constantly. It sets removed.
the GiveBack flag
and sets the
Minimum
Operating Current
to 5V@0A.

Page 526 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Laptop Hub Peripherals Device Policy Hub Power
Manager (W)

53 Accept sent to the Accept received by 22.4

Phone the Phone

54 PS_RDY sent to the PS_RDY received by 22.4

phone. the phone. Phone
starts to charge
5V@2A but has to
follow USB
Suspend rules

55 Request received The Hub Requests The Hub needs 22.4

20V@0.83A (16.6W) 0.75W for itself,
from the Laptop but 0.75W for Hard
sets the No USB Disk Drive 2, 10W
Suspend bit. for the phone
(includes the
Power Reserve of
5W), and 5W for
Hard Disk Drive 1
operation. It
requests for USB
Suspend rule to be
removed.

56 Accept sent Accept received Request is within 22.4

available
capabilities so the
Laptop accepts.
Note that the
request for No
Suspend has not
been acted on by
the Laptop. USB
Suspend rules
apply until the
Laptop sends out
new Source
Capabilities with
the USB Suspend
bit cleared.

57 PS_RDY sent PS_RDY received Laptop indicates 16.6

that its power
supply is ready.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 527
 Step Laptop Hub Peripherals Device Policy Hub Power
Manager (W)

Hard Disk Drive 2 spin up

58 Request received Hard Disk Drive 2 Hard Disk Drive 2 16.6

from Hard Disk Drive requests needs more power
2 5V@0.15A from to spin up and so
the Hub but sets indicates a
the Capability Capability
Mismatch bit. Mismatch

59 Accept sent Accept received The request is 16.6

within its
capabilities so the
Hub accepts.

60 PS_RDY sent PS_RDY received The Hub indicates 16.6

that its power
supply is ready.

61 The Hub requests Get Sink Due to the 16.6

the Sink Capabilities Capabilities Capability
from Hard Disk Drive received by Hard Mismatch the Hub
2. Disk Drive 2 has to determine
what Hard Disk
Drive 2 needs

62 Sink Capabilities Hard Disk Drive 2 16.6

received returns capabilities
indicating that it
requires 20V@0.5A
maximum current.

63 The Hub instructs Goto Min received Hub assess that 16.6
the Phone to Goto by the Phone there is additional
Minimum operation. power available
from the Phone
and so tells it to
Goto Min. In this
case it is
reallocating the
Phone’s Charging
power as the
Power Reserve for
the Hard Disk
Drives.

64 The Phone drops to 16.6

zero current draw.

65 PD_RDY sent PS_RDY received. Hub indicates that 16.6

its power supply
has changed to the
new level.

Page 528 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Laptop Hub Peripherals Device Policy Hub Power
Manager (W)

66 Request received The Hub Requests The Hub has an 16.6

20V@1.04A (20.8W) additional 10W
from the Laptop from the Phone
but needs 5W
more to maintain
its Power Reserve.
The Hub needs
0.75W for itself,
10W for Hard Disk
Drive 2, 5W for the
Power Reserve, 5W
for Hard Disk Drive
1 operation.

67 Accept sent Accept received Request is within 16.6

available
capabilities so the
Laptop accepts.

68 PS_RDY sent PS_RDY received Laptop indicates 20.8

that its power
supply is ready.

69 Hub sends out a set Source Capabilities The Hub now has 20.8
of capabilities to received by Hard the power that
Hard Disk Drive 2 Disk Drive 2 Hard Disk Drive 2
including: 5V@0.5A needs so it sends
and 20V@0.5A. The out new
externally powered Capabilities.
and USB suspend
bits are set.

70 Request received Hard Disk Drive 2 Hard Disk Drive 2 20.8

from Hard Disk Drive requests requests what it
2 20V@0.5A needs to spin up.
operating current
and 20V@0.5A.

71 Accept sent to Hard Accept received by The Hub assesses 20.8

Disk Drive 2 Hard Disk Drive 2 that the request is
within its
Capabilities so it
accepts.

72 PS_RDY sent. PS_RDY sent. Hard 20.8

Disk Drive 2 starts
to draw 20V@0.5A
and spins up.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 529
 Step Laptop Hub Peripherals Device Policy Hub Power
Manager (W)

73 Request received Once spun up Hard Hard Disk Drive 2 20.8

from Hard Disk Drive Disk Drive 2 no longer needs
2 requests the additional
20V@0.25A power so it gives
operating current back what it does
and 20V@0.5A not need.
maximum current.

74 Accept sent to Hard Accept received by The Hub assesses 20.8

Disk Drive 2 Hard Disk Drive 2 that the request is
within its
Capabilities so it
accepts.

75 PS_RDY sent to Hard PS_RDY received by The Hub indicates 20.8

Disk Drive 2. Hard Disk Drive 2. that its power
supply is ready.

76 The Hub sends out a Source Capabilities The Hub now has 20.8
set of capabilities to received by the the power
the Phone including: Phone available to charge
5V@2A. The the phone so it
externally powered sends out new
bit is set and the USB Capabilities
suspend bit is set.

77 Request received The Phone The Phone 20.8

from the Phone requests 5V@2A requests the power
operating current it needs to charge.
from the Hub and It asks for the USB
sets the No USB Suspend
Suspend bit since it requirement to be
needs to charge removed.
constantly. It sets
the GiveBack flag
and sets the
Minimum
Operating Current
to 5V@0A.

78 Accept sent to the Accept received by The Hub assesses 20.8

Phone the Phone that the request is
within its
Capabilities so it
accepts but
maintains USB
Suspend rules.

Page 530 USB Power Delivery Specification Revision 2.0, Version 1.1
 Step Laptop Hub Peripherals Device Policy Hub Power
Manager (W)

79 PS_RDY sent to the PS_RDY received by The Hub has 20.8

Phone. the Phone. The allocated 0.75W
phone starts to for itself, 5W for
draw 5V@2A but Hard Disk Drive 2,
has to follow USB 10W for the Phone
Suspend. (including 5W for
the Power
Reserve), and 5W
for Hard Disk Drive
1 operation.

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 531
 G. VDM Command Examples
G.1 Discover Identity Example
G.1.1 Discover Identity Command request
Table G-1 below shows the contents of the key fields in the Message Header and VDM header for an Initiator sending a
Discover Identity Command request.

Table G-1 Discover Identity Command request from Initiator Example

Bit(s) Field Value

Message Header
15 Reserved 0
14..12 Number of Data Objects 1 (VDM Header)
11..9 MessageID 0..7
8 Port Power Role 0 or 1
7..6 Specification Revision 01b
5..4 Reserved 0
3..0 Message Type 1111b (Vendor Defined Message)
VDM Header
B31..16 Standard or Vendor ID (SVID) 0xFF00 (PD SID)
B15 VDM Type 1 (Structured VDM)
B14..13 Structured VDM Version 00b (Version 1.0)
B12..11 Reserved 00b
B10..8 Object Position 000b
B7..6 Command Type 00b (Initiator)
B5 Reserved 0
B4..0 Command1 1 (Discover Identity)

G.1.2 Discover Identity Command response – Active Cable

Table G-2 shows the contents of the key fields in the Message Header and VDM header for a Responder returning
VDOs in response to a Discover SVIDs Command request. In this illustration, the responder is an active Gen2 cable
which supports Modal Operation.

Table G-2 Discover Identity Command response from Active Cable Responder Example

Bit(s) Field Value

Message Header
15 Reserved 0
14..12 Number of Data Objects 4 (VDM Header + ID Header VDO + Cer Stat VDO +
Cable VDO)
11..9 MessageID 0..7
8 Cable Plug 1
7..6 Specification Revision 01b
5..4 Reserved 0
3..0 Message Type 1111b (Vendor Defined Message)

Page 532 USB Power Delivery Specification Revision 2.0, Version 1.1
Bit(s) Field Value
VDM Header
B31..16 Standard or Vendor ID (SVID) 0xFF00 (PD SID)
B15 VDM Type 1 (Structured VDM)
B14..13 Structured VDM Version 00b (Version 1.0)
B12..11 Reserved 00b
B10..8 Object Position 000b
B7..6 Command Type 01b (Responder ACK)
B5 Reserved 0
B4..0 Command 2 (Discover Identity)
ID Header VDO
B31 Data Capable as USB Host 0 (not data capable as a Host)
B30 Data Capable as a USB Device 0 (not data capable as a Device)
B29..27 Product Type 100b (Active Cable)
B26 Modal Operation Supported 1 (supports Modes)
B25..16 Reserved. Shall be set to zero. 0
B15..0 16-bit unsigned integer. USB Vendor ID USB-IF assigned VID for this cable vendor
Cert Stat VDO
B31..20 Reserved, shall be set to zero. 0
B19..0 20-bit unsigned integer USB-IF assigned TID for this cable
Product VDO
B31..16 16-bit unsigned integer. USB Product ID Product ID assigned by the cable vendor
B15..0 16-bit unsigned integer. bcdDevice Device version assigned by the cable vendor
Cable VDO (returned for Product Type “Active Cable”)
B31..28 HW Version Cable HW version number (vendor defined)
B27..24 Firmware Version Cable FW version number (vendor defined)
B23..20 Reserved 0
B19..18 Type-C to Type-A/B/C 10b (Type-C)
B17 Type-C to Plug/Receptacle 0 (Plug)
B16..13 Cable Latency 0001b ( <10ns (~1m))
B12..11 Cable Termination Type 11b (Both ends Active, VCONN required)
B10 SSTX1 Directionality Support 0 (Fixed)
B9 SSTX2 Directionality Support 0 (Fixed)
B8 SSRX1 Directionality Support 0 (Fixed)
B7 SSRX2 Directionality Support 0 (Fixed)
B6..5 VBUS Current Handling Capability 01b (3A)
B4 VBUS through cable 1 (Yes)
B3 SOP” controller present? 1 (SOP” controller present)
B2..0 USB Superspeed Signaling Support 010b ([USB 3.1] Gen1 and Gen2)

G.1.3 Discover Identity Command response – Hub

Table G-2 shows the contents of the key fields in the Message Header and VDM header for a Responder returning
VDOs in response to a Discover SVIDs Command request. In this illustration, the responder is a Hub

Table G-3 Discover Identity Command response from Hub Responder Example

Bit(s) Field Value

Message Header
15 Reserved 0

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 533
Bit(s) Field Value
14..12 Number of Data Objects 4 (VDM Header + ID Header VDO + Cer Stat VDO +
Product VDO)
11..9 MessageID 0..7
8 Port Power Role 0 or 1
7..6 Specification Revision 01b
5..4 Reserved 0
3..0 Message Type 1111b (Vendor Defined Message)
VDM Header
B31..16 Standard or Vendor ID (SVID) 0xFF00 (PD SID)
B15 VDM Type 1 (Structured VDM)
B14..13 Structured VDM Version 00b (Version 1.0)
B12..11 Reserved 00b
B10..8 Object Position 000b
B7..6 Command Type 01b (Responder ACK)
B5 Reserved 0
B4..0 Command 2 (Discover Identity)
ID Header VDO
B31 Data Capable as USB Host 0 (not data capable as a Host)
B30 Data Capable as a USB Device 1 (data capable as a Device)
B29..27 Product Type 001b (Hub)
B26 Modal Operation Supported 0 (doesn’t support Modes)
B25..16 Reserved. Shall be set to zero. 0
B15..0 16-bit unsigned integer. USB Vendor ID USB-IF assigned VID for this hub vendor
Cert Stat VDO
B31..20 Reserved, shall be set to zero. 0
B19..0 20-bit unsigned integer USB-IF assigned TID for this hub
Product VDO
B31..16 16-bit unsigned integer. USB Product ID Product ID assigned by the hub vendor
B15..0 16-bit unsigned integer. bcdDevice Device version assigned by the hub vendor

Page 534 USB Power Delivery Specification Revision 2.0, Version 1.1
 G.2 Discover SVIDs Example
G.2.1 Discover SVIDs Command request
Table G-4 below shows the contents of the key fields in the Message Header and VDM header for an Initiator sending a
Discover SVIDs Command request.

Table G-4 Discover SVIDs Command request from Initiator Example

Bit(s) Field Value

Message Header
15 Reserved 0
14..12 Number of Data Objects 1 (VDM Header)
11..9 MessageID 0..7
8 Port Power Role 0 or 1
7..6 Specification Revision 01b
5..4 Reserved 0
3..0 Message Type 1111b (Vendor Defined Message)
VDM Header
B31..16 Standard or Vendor ID (SVID) 0xFF00 (PD SID)
B15 VDM Type 1 (Structured VDM)
B14..13 Structured VDM Version 00b (Version 1.0)
B12..11 Reserved 00b
B10..8 Object Position 000b
B7..6 Command Type 00b (Initiator)
B5 Reserved 0
B4..0 Command1 2 (Discover SVIDs)

G.2.1 Discover SVIDs Command response

Table G-5 shows the contents of the key fields in the Message Header and VDM Header for a Responder returning
VDOs in response to a Discover SVIDs Command request. In this illustration, the value 3 in the Message Header
indicates that one VDO containing the supported SVIDs would be returned followed by a terminating VDO. Note that
the last VDO returned (the terminator of the transmission) contains zero value SVIDs. If a SVID value is zero, it is not
used.

Table G-5 Discover SVIDs Command response from Responder Example

Bit(s) Field Value

Message Header
15 Reserved 0
14..12 Number of Data Objects 3 (VDM Header + 2*VDO)
11..9 MessageID 0..7
8 Port Power Role 0 or 1
7..6 Specification Revision 01b
5..4 Reserved 0
3..0 Message Type 1111b (Vendor Defined Message)
VDM Header
B31..16 Standard or Vendor ID (SVID) 0xFF00 (PD SID)
B15 VDM Type 1 (Structured VDM)

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 535
Bit(s) Field Value
B14..13 Structured VDM Version 00b (Version 1.0)
B12..11 Reserved 00b (Reserved)
B10..8 Object Position 000b
B7..6 Command Type 01b (Responder ACK)
B5 Reserved 0
B4..0 Command 2 (Discover SVIDs)
VDO 1
B31..16 SVID 0 SVID value
B15..0 SVID 1 SVID value
VDO 2
B31..16 SVID 2 0x0000
B15..0 SVID 3 0x0000

Page 536 USB Power Delivery Specification Revision 2.0, Version 1.1
 G.3 Discover Modes Example
G.3.1 Discover Modes Command request
Table G-6 shows the contents of the key fields in the Message Header and VDM header for an Initiator sending a
Discover Modes Command request. The Initiator of the Discover Modes Command sequence sends a Message Header
with the Number of Data Objects field set to 1 followed by a VDM Header with the Command Type (B7..6) set to zero
indicating the Command is from an Initiator and the Command (B4..0) is set to 3 indicating Mode discovery.

Table G-6 Discover Modes Command request from Initiator Example

Bit(s) Field Value

Message Header
15 Reserved 0
14..12 Number of Data Objects 1 (VDM Header)
11..9 MessageID 0..7
8 Port Power Role 0 or 1
7..6 Specification Revision 01b
5..4 Reserved 0
3..0 Message Type 1111b (Vendor Defined Message)
VDM Header
B31..16 Standard or Vendor ID (SVID) SVID for which Modes are being requested
B15 VDM Type 1 (Structured VDM)
B14..13 Structured VDM Version 00b (Version 1.0)
B12..11 Reserved 00b
B10..8 Object Position 000b
B7..6 Command Type 00b (Initiator)
B5 Reserved 0
B4..0 Command1 3 (Discover Modes)

G.3.2 Discover Modes Command response

The Responder to the Discover Modes Command request returns a Message Header with the Number of Data Objects
field set to a value of 1 to 7 (the actual value is the number of Mode objects plus one) followed by a VDM Header with
the Message Source (B5) set to 1 indicating the Command is from a Responder and the Command (B4..0) set to 2
indicating the following objects describe the Modes the device supports. If the ID is a VID, the structure and content of
the VDO is left to the vendor. If the ID is a SID, the structure and content of the VDO is defined by the Standard.
Table G-7 shows the contents of the key fields in the Message Header and VDM Header for a Responder returning
VDOs in response to a Discover Modes Command request. In this illustration, the value 2 in the Message Header
indicates that the device is returning one VDO describing the Mode it supports. It is possible for a Responder to report
up to six different Modes.

Table G-7 Discover Modes Command response from Responder Example

Bit(s) Field Value

Message Header
15 Reserved 0
14..12 Number of Data Objects 2 (VDM Header + 1 Mode VDO)
11..9 MessageID 0..7
8 Port Power Role 0 or 1

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 537
Bit(s) Field Value
7..6 Specification Revision 01b
5..4 Reserved 0
3..0 Message Type 1111b (Vendor Defined Message)
VDM Header
B31..16 Standard or Vendor ID (SVID) SVID for which Modes were requested
B15 VDM Type 1 (Structured VDM)
B14..13 Structured VDM Version 00b (Version 1.0)
B12..11 Reserved 00b
B10..8 Object Position 000b
B7..6 Command Type 01b (Responder ACK)
B5 Reserved 0
B4..0 Command 3 (Discover Modes)
Mode VDO
B31..0 Mode 1 Standard or Vendor defined Mode value

Page 538 USB Power Delivery Specification Revision 2.0, Version 1.1
 G.4 Enter Mode Example
G.4.1 Enter Mode Command request
The Initiator of the Enter Mode Command request sends a Message Header with the Number of Data Objects field set
to 1 followed by a VDM Header with the Message Source (B5) set to zero indicating the Command is from an Initiator
and the Command (B4..0) set to 4 to request the Responder to enter its mode of operation and sets the Object Position
field to the desired functional VDO based on its offset as received during Discovery.
Table G-8 shows the contents of the key fields in the Message Header and VDM Header for an Initiator sending an
Enter Mode Command request.

Table G-8 Enter Mode Command request from Initiator Example

Bit(s) Field Value

Message Header
15 Reserved 0
14..12 Number of Data Objects 1 (VDM Header)
11..9 MessageID 0..7
8 Port Power Role 0 or 1
7..6 Specification Revision 01b
5..4 Reserved 0
3..0 Message Type 1111b (Vendor Defined Message)
VDM Header
B31..16 Standard or Vendor ID (SVID) SVID for the Mode being entered
B15 VDM Type 1 (Structured VDM)
B14..13 Structured VDM Version 00b (Version 1.0)
B12..11 Reserved 00b
B10..8 Object Position 001b (a one in this field indicates a request to enter
the first Mode in list returned by Discover Modes)
B7..6 Command Type 00b (Initiator)
B5 Reserved 0
B4..0 Command 4 (Enter Mode)

G.4.2 Enter Mode Command response

The Responder that is the target of the Enter Mode Command request shall send a Message Header with the Number of
Data Objects field set to a value of 1 followed by a VDM Header with the Command Source (B5) set to 1 indicating the
response is from a Responder and the Command (B4..0) set to 4 indicating the Responder has entered the Mode and is
ready to operate.
Table G-9 shows the contents of the key fields in the Message Header and VDM Header for a Responder sending an
Enter Mode Command response with an ACK.

Table G-9 Enter Mode Command response from Responder Example

Bit(s) Field Value

Message Header
15 Reserved 0
14..12 Number of Data Objects 1 (VDM Header)
11..9 MessageID 0..7
8 Port Power Role 0 or 1

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 539
Bit(s) Field Value
7..6 Specification Revision 01b
5..4 Reserved 0
3..0 Message Type 1111b (Vendor Defined Message)
VDM Header
B31..16 Standard or Vendor ID (SVID) SVID for the Mode entered
B15 VDM Type 1 (Structured VDM)
B14..13 Structured VDM Version 00b (Version 1.0)
B12..11 Reserved 00b
B10..8 Object Position 001b (offset of the Mode entered)
B7..6 Command Type 01b (Responder ACK)
B5 Reserved 0
B4..0 Command 4 (Enter Mode)

G.4.1 Enter Mode Command request with additional VDO

The Initiator of the Enter Mode Command request sends a Message Header with the Number of Data Objects field set
to 2 indicating an additional VDO followed by a VDM Header with the Message Source (B5) set to zero indicating the
Command is from an Initiator and the Command (B4..0) set to 4 to request the Responder to enter its mode of
operation and sets the Object Position field to the desired functional VDO based on its offset as received during
Discovery.
Table G-8 shows the contents of the key fields in the Message Header and VDM Header for an Initiator sending an
Enter Mode Command request with an additional VDO.

Table G-10 Enter Mode Command request from Initiator Example

Bit(s) Field Value

Message Header
15 Reserved 0
14..12 Number of Data Objects 1 (VDM Header)
11..9 MessageID 0..7
8 Port Power Role 0 or 1
7..6 Specification Revision 01b
5..4 Reserved 0
3..0 Message Type 1111b (Vendor Defined Message)
VDM Header
B31..16 Standard or Vendor ID (SVID) SVID for the Mode being entered
B15 VDM Type 1 (Structured VDM)
B14..13 Structured VDM Version 00b (Version 1.0)
B12..11 Reserved 00b
B10..8 Object Position 001b (a one in this field indicates a request to enter
the first Mode in list returned by Discover Modes)
B7..6 Command Type 00b (Initiator)
B5 Reserved 0
B4..0 Command 4 (Enter Mode)
Including optional Mode specific VDO
B31..0 Mode specific

Page 540 USB Power Delivery Specification Revision 2.0, Version 1.1
 G.5 Exit Mode Example
G.5.1 Exit Mode Command request
The Initiator of the Exit Mode Command request sends a Message Header with the Number of Data Objects field set to
1 followed by a VDM Header with the Message Source (B5) set to zero indicating the Command is from an Initiator
and the Command (B4..0) set to 5 to request the Responder to exit its Mode of operation.
Table G-11 shows the contents of the key fields in the Message Header and VDM header for an Initiator sending an Exit
Mode Command request.

Table G-11 Exit Mode Command request from Initiator Example

Bit(s) Field Value

Message Header
15 Reserved 0
14..12 Number of Data Objects 1 (VDM Header)
11..9 MessageID 0..7
8 Port Power Role 0 or 1
7..6 Specification Revision 01b
5..4 Reserved 0
3..0 Message Type 1111b (Vendor Defined Message)
VDM Header
B31..16 Standard or Vendor ID (SVID) SVID for the Mode being exited
B15 VDM Type 1 (Structured VDM)
B14..13 Structured VDM Version 00b (Version 1.0)
B12..11 Reserved 00b
B10..8 Object Position 001b (identifies the previously entered Mode by its
Object Potision that is to be exited)
B7..6 Command Type 00b (Initiator)
B5 Reserved 0
B4..0 Command 5 (Exit Mode)

G.5.2 Exit Mode Command response

The Responder that receives the Exit Mode Command request sends a Message Header with the Number of Data
Objects field set to a value of 1 followed by a VDM Header with the Message Source (B5) set to 1 indicating the
Command is from a Responder and the Command (B4..0) set to 5 indicating the Responder has exited the Mode and
has returned to normal USB operation.
Table G-12 shows the contents of the key fields in the Message Header and VDM header for a Responder sending an
Exit Mode Command ACK response.

Table G-12 Exit Mode Command response from Responder Example

Bit(s) Field Value

Message Header
15 Reserved 0
14..12 Number of Data Objects 1 (VDM Header)
11..9 MessageID 0..7
8 Port Power Role 0 or 1
7..6 Specification Revision 01b

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 541
Bit(s) Field Value
5..4 Reserved 0
3..0 Message Type 1111b (Vendor Defined Message)
VDM Header
B31..16 Standard or Vendor ID (SVID) SVID for the Mode exited
B15 VDM Type 1 (Structured VDM)
B14..13 Structured VDM Version 00b (Version 1.0)
B12..11 Reserved 00b
B10..8 Object Position 001b (offset of the Mode to be exited)
B7..6 Command Type 01b (Responder ACK)
B5 Reserved 0
B4..0 Command 5 (Exit Mode)

Page 542 USB Power Delivery Specification Revision 2.0, Version 1.1
 G.6 Attention Example
G.6.1 Attention Command request
The Initiator of the Attention Command request sends a Message Header with the Number of Data Objects field set to
1 followed by a VDM Header with the Message Source (B5) set to zero indicating the Command is from an Initiator
and the Command (B4..0) set to 6 to request attention from the Responder.
Table G-11 shows the contents of the key fields in the Message Header and VDM header for an Initiator sending an
Attention Command request.

Table G-13 Attention Command request from Initiator Example

Bit(s) Field Value

Message Header
15 Reserved 0
14..12 Number of Data Objects 1 (VDM Header)
11..9 MessageID 0..7
8 Port Power Role 0 or 1
7..6 Specification Revision 01b
5..4 Reserved 0
3..0 Message Type 1111b (Vendor Defined Message)
VDM Header
B31..16 Standard or Vendor ID (SVID) SVID for which attention is being requested
B15 VDM Type 1 (Structured VDM)
B14..13 Structured VDM Version 00b (Version 1.0)
B12..11 Reserved 00b
B10..8 Object Position 001b (offset of the Mode requesting attention)
B7..6 Command Type 000b (Initiator)
B5 Reserved 0
B4..0 Command 6 (Attention)

G.6.2 Attention Command request with additional VDO

The Initiator of the Attention Command request sends a Message Header with the Number of Data Objects field set to
2 indicating an additional VDO followed by a VDM Header with the Message Source (B5) set to zero indicating the
Command is from an Initiator and the Command (B4..0) set to 6 to request attention from the Responder.
Table G-11 shows the contents of the key fields in the Message Header and VDM header for an Initiator sending an
Attention Command request with an additional VDO.

Table G-14 Attention Command request from Initiator with additional VDO Example

Bit(s) Field Value

Message Header
15 Reserved 0
14..12 Number of Data Objects 2 (VDM Header + VDO)
11..9 MessageID 0..7
8 Port Power Role 0 or 1
7..6 Specification Revision 01b
5..4 Reserved 0

USB Power Delivery Specification Revision 2.0, Version 1.1 Page 543
Bit(s) Field Value
3..0 Message Type 1111b (Vendor Defined Message)
VDM Header
B31..16 Standard or Vendor ID (SVID) SVID for which attention is being requested
B15 VDM Type 1 (Structured VDM)
B14..13 Structured VDM Version 00b (Version 1.0)
B12..11 Reserved 00b
B10..8 Object Position 001b (offset of the Mode requesting attention)
B7..6 Command Type 000b (Initiator)
B5 Reserved 0
B4..0 Command 6 (Attention)
Including optional Mode specific VDO
B31..0 Mode specific

Page 544 USB Power Delivery Specification Revision 2.0, Version 1.1