SIST EN IEC 63563-6:2026
(Main)Qi Specification version 2.0 - Part 6: Communications protocol (IEC 63563-6:2025)
Qi Specification version 2.0 - Part 6: Communications protocol (IEC 63563-6:2025)
IEC 63563-6:2025 defines the messaging between a Power Transmitter and a Power Receiver. The primary purpose of this messaging is to set up and control the power transfer. As a secondary purpose, it provides a transport mechanism for higher-level applications such as Authentication. The communications protocol comprises both the required order and timing relations of successive messages.
Qi Spezifikation Version 2.0 - Teil 6: Kommunikationsprotokoll (IEC 63563-6:2025)
Spécification Qi version 2.0 - Partie 6: Protocole de communications (IEC 63563-6:2025)
IEC 63563-6:2025 définit la messagerie entre un émetteur de puissance et un récepteur de puissance. L'objectif principal de cette messagerie est de mettre en place et de contrôler le transfert de puissance. En tant qu'objectif secondaire, il fournit un mécanisme de transport pour des applications de niveau supérieur telles que l'authentification. Le protocole de communication comprend à la fois l'ordre requis et les relations temporelles des messages successifs.
Različica specifikacije Qi 2.0 - 6. del: Komunikacijski protokol (IEC 63563-6:2025)
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
oSIST prEN IEC 63563-6:2024
01-julij-2024
Različica specifikacije Qi 2.0 - 6. del: Komunikacijski protokol (Hitri postopek)
Qi Specification version 2.0 - Part 6: Communications protocol (Fast track)
Ta slovenski standard je istoveten z: prEN IEC 63563-6:2024
ICS:
29.240.99 Druga oprema v zvezi z Other equipment related to
omrežji za prenos in power transmission and
distribucijo električne energije distribution networks
33.160.99 Druga avdio, video in Other audio, video and
avdiovizuelna oprema audiovisual equipment
35.200 Vmesniška in povezovalna Interface and interconnection
oprema equipment
oSIST prEN IEC 63563-6:2024 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
oSIST prEN IEC 63563-6:2024
oSIST prEN IEC 63563-6:2024
100/4127/CDV
COMMITTEE DRAFT FOR VOTE (CDV)
PROJECT NUMBER:
IEC 63563-6 ED1
DATE OF CIRCULATION: CLOSING DATE FOR VOTING:
2024-05-03 2024-07-26
SUPERSEDES DOCUMENTS:
IEC TA 15 : WIRELESS POWER TRANSFER
SECRETARIAT: SECRETARY:
Korea, Republic of Mr Ockwoo Nam
OF INTEREST TO THE FOLLOWING COMMITTEES: PROPOSED HORIZONTAL STANDARD:
TC 106,TC 108
Other TC/SCs are requested to indicate their interest, if any,
in this CDV to the secretary.
FUNCTIONS CONCERNED:
EMC ENVIRONMENT QUALITY ASSURANCE SAFETY
SUBMITTED FOR CENELEC PARALLEL VOTING NOT SUBMITTED FOR CENELEC PARALLEL VOTING
This document is still under study and subject to change. It should not be used for reference purposes.
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they
are aware and to provide supporting documentation.
Recipients of this document are invited to submit, with their comments, notification of any relevant “In Some Countries”
clauses to be included should this proposal proceed. Recipients are reminded that the CDV stage is the final stage for
submitting ISC clauses. (SEE AC/22/2007 OR NEW GUIDANCE DOC).
TITLE:
Qi Specification version 2.0 - Part 6: Communications Protocol (Fast track)
PROPOSED STABILITY DATE: 2029
NOTE FROM TC/SC OFFICERS:
This document is only in PDF format. IEC and WPC agreed to use the pdf files as this is an adoption.
electronic file, to make a copy and to print out the content for the sole purpose of preparing National Committee positions.
You may not copy or "mirror" the file or printed version of the document, or any part of it, for any other purpose without
permission in writing from IEC.
oSIST prEN IEC 63563-6:2024
WIRELESS POWER
CONSORTIUM
Qi Specification
Communications Protocol
Version 2.0
April 2023
oSIST prEN IEC 63563-6:2024
COPYRIGHT
© 2023 by the Wireless Power Consortium, Inc. All rights reserved.
The QiSpecification, Communications Protocol is published by the Wireless Power Consortium and
has been prepared by the members of the Wireless Power Consortium. Reproduction in whole or in
part is prohibited without express and prior written permission of the Wireless Power
Consortium.
DISCLAIMER
The information contained herein is believed to be accurate as of the date of publication,
but is provided “as is” and may contain errors. The Wireless Power Consortium makes no
warranty, express or implied, with respect to this document and its contents, including any
warranty of title, ownership, merchantability, or fitness for a particular use or purpose.
Neither the Wireless Power Consortium, nor any member of the Wireless Power
Consortium will be liable for errors in this document or for any damages, including indirect
or consequential, from use of or reliance on the accuracy of this document. For any further
explanation of the contents of this document, or in case of any perceived inconsistency or ambiguity
of interpretation, contact: info@wirelesspowerconsortium.com.
RELEASE HISTORY
Specification Version Release Date Description
v2.0 Final Draft April 2023 Initial release of the v2.0 Qi Specification.
oSIST prEN IEC 63563-6:2024
Table of Contents
1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Structure of the Qi Specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Power Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Protocol phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Power Transfer Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Data packet types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 High-level messages and data transport streams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Backward compatibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Power Receiver and Power Transmitter identification . . . . . . . . . . . . . . . . . . . . 18
4 Ping phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 Ping phase state diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Ping phase timings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5 Configuration phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1 Configuration phase state diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Configuration phase timings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6 Negotiation phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1 Negotiable elements of the Power Transfer Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2 Updating the Power Transfer Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.3 Foreign Object Detection support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.4 Wireless power ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.5 NFC tag protection support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.6 Negotiation phase state diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.7 Negotiation phase timings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7 Power transfer phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.1 Power transfer state diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.2 Data transport stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.3 Power transfer phase timings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
oSIST prEN IEC 63563-6:2024
8 Power Receiver data packets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.1 Auxiliary Data Control—ADC (0x25; simple query) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.2 Auxiliary Data Transport—ADT (multiple header codes; simple query) . . . . . . . . . . . . . . . . . . . . . . . . 97
8.3 Charge Status—CHS (0x05; status update) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
8.4 Configuration—CFG (0x51; simple query) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
8.5 Control Error—CE (0x03; power control) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.6 Data Stream Response—DSR (0x15; data request) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8.7 End Power Transfer—EPT (0x02; power control) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.8 Extended Identification—XID (0x81; status update) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.9 FOD Status—FOD (0x22; simple query) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
8.10 General Request—GRQ (0x07; data request). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
8.11 Identification—ID (0x71; status update) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
8.12 Power Control Hold-off—PCH (0x06; status update) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
8.13 Proprietary—PROP (multiple headers; multiple types) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.14 Received Power—RP8 (0x04; status update). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.15 Received Power—RP (0x31; simple query) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.16 Renegotiate—NEGO (0x09; simple query) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.17 Signal Strength—SIG (0x01; status update). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.18 Specific Request—SRQ (0x20; simple query). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.19 Wireless Power ID—WPID (0x54, 0x55; simple query) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.20 Reserved. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9 Power Transmitter data packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
9.1 Auxiliary Data Control—ADC (0x25). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
9.2 Auxiliary Data Transport—ADT (multiple header codes). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
9.3 Data Not Available—NULL (0x00). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
9.4 Power Transmitter Capabilities—CAP (0x31) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
9.5 Power Transmitter Extended Capabilities—XCAP (0x32) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
9.6 Power Transmitter Identification—ID (0x30). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
9.7 Proprietary—PROP (multiple headers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
9.8 Reserved. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
oSIST prEN IEC 63563-6:2024
1 General
The Wireless Power Consortium (WPC) is a worldwide organization that aims to develop and
promote global standards for wireless power transfer in various application areas. A first
application area comprises flat-surface devices such as mobile phones and chargers in the
Baseline Power Profile (up to 5 W) and Extended Power Profile (above 5 W).
1.1 Structure of the Qi Specification
General documents
Introduction
Glossary, Acronyms, and Symbols
System description documents
Mechanical, Thermal, and User Interface
Power Delivery
Communications Physical Layer
Communications Protocol
Foreign Object Detection
NFC Tag Protection
Authentication Protocol
Reference design documents
Power Transmitter Reference Designs
Power Receiver Design Examples
Compliance testing documents
Power Transmitter Test Tools
Power Receiver Test Tools
Power Transmitter Compliance Tests
Power Receiver Compliance Tests
NOTE: The compliance testing documents are restricted and require signing in to the WPC members’
website. All other specification documents are available for download on both the WPC public website
and the WPC website for members.
oSIST prEN IEC 63563-6:2024
1.2 Scope
The QiSpecification, Communications Protocol (this document) defines the messaging between a
Power Transmitter and a Power Receiver. The primary purpose of this messaging is to set up and
control the power transfer. As a secondary purpose, it provides a transport mechanism for higher-
level applications such as Authentication. The communications protocol comprises both the
required order and timing relations of successive messages.
1.3 Compliance
All provisions in the QiSpecification are mandatory, unless specifically indicated as recommended,
optional, note, example, or informative. Verbal expression of provisions in this Specification follow
the rules provided in ISO/IEC Directives, Part 2.
Table 1: Verbal forms for expressions of provisions
Provision Verbal form
requirement “shall” or “shall not”
recommendation “should” or “should not”
permission “may” or “may not”
capability “can” or “cannot”
1.4 References
For undated references, the most recently published document applies. The most recent WPC
publications can be downloaded from http://www.wirelesspowerconsortium.com. In addition, the
QiSpecification references documents listed below. Documents marked here with an asterisk (*)
are restricted and require signing in to the WPC website for members.
Product Registration Procedure Web page*
Qi Product Registration Manual, Logo Licensee/Manufacturer*
Qi Product Registration Manual, Authorized Test Lab*
Power Receiver Manufacturer Codes,* Wireless Power Consortium
The International System of Units (SI), Bureau International des Poids et Mesures
Verbal forms for expressions of provisions, International Electotechnical Commission
For regulatory information about product safety, emissions, energy efficiency, and use of the
frequency spectrum, visit the regulatory environment page of the WPC members’ website.
oSIST prEN IEC 63563-6:2024
1.5 Conventions
1.5.1 Notation of numbers
Real numbers use the digits 0 to 9, a decimal point, and optionally an exponential part.
Integer numbers in decimal notation use the digits 0 to 9.
Integer numbers in hexadecimal notation use the hexadecimal digits 0 to 9 and A to F, and are
prefixed by "0x" unless explicitly indicated otherwise.
Single bit values use the words ZERO and ONE.
1.5.2 Tolerances
Unless indicated otherwise, all numeric values in the QiSpecification are exactly as specified and do
not have any implied tolerance.
1.5.3 Fields in a data packet
A numeric value stored in a field of a data packet uses a big-endian format. Bits that are more
significant are stored at a lower byte offset than bits that are less significant. Table 2 and Figure 1
provide examples of the interpretation of such fields.
Table 2: Example of fields in a data packet
b b b b b b b b
7 6 5 4 3 2 1 0
(msb)
B
16-bit Numeric Data Field
B
(lsb)
B Other Field (msb)
B 10-bit Numeric Data Field (lsb) Field
Figure 1. Examples of fields in a data packet
16-bit Numeric Data Field
b b b b b b b b b b b b b b b b
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
B B
0 1
10-bit Numeric Data Field
b b b b b b b b b b
9 8 7 6 5 4 3 2 1 0
B B
2 3
oSIST prEN IEC 63563-6:2024
1.5.4 Notation of text strings
Text strings consist of a sequence of printable ASCII characters (i.e. in the range of 0x20 to 0x7E)
enclosed in double quotes ("). Text strings are stored in fields of data structures with the first
character of the string at the lowest byte offset, and are padded with ASCII NUL (0x00) characters
to the end of the field where necessary.
EXAMPLE: The text string “WPC” is stored in a six-byte fields as the sequence of characters 'W', 'P', 'C', NUL,
NUL, and NUL. The text string “M:4D3A” is stored in a six-byte field as the sequence 'M', ':', '4', 'D',
'3', and 'A'.
1.5.5 Short-hand notation for data packets
In many instances, the QiSpecification refers to a data packet using the following shorthand
notation:
/
In this notation, refers to the data packet's mnemonic defined in the QiSpecification,
Communications Protocol, and refers to a particular value in a field of the data packet.
The definitions of the data packets in the QiSpecification, Communications Protocol, list the
meanings of the modifiers.
For example, EPT/cc refers to an End Power Transfer data packet having its End Power Transfer
code field set to 0x01.
oSIST prEN IEC 63563-6:2024
1.6 Power Profiles
A Power Profile determines the level of compatibility between a Power Transmitter and a Power
Receiver. Table 3 defines the available Power Profiles.
BPP PTx: A Baseline Power Profile Power Transmitter.
EPP5 PTx: An Extended Power Profile Power Transmitter having a restricted power transfer
()pot
capability, i.e. P = 5 W.
L
EPP PTx: An Extended Power Profile Power Transmitter.
BPP PRx: A Baseline Power Profile Power Receiver.
EPP PRx: An Extended Power Profile Power Receiver.
Table 3: Capabilities included in a Power Profile
Feature BPP PTx EPP5 PTx EPP PTx BPP PRx EPP PRx
Ax or Bx design Yes Yes No N/A N/A
MP-Ax or MP-Bx design No No Yes N/A N/A
Baseline Protocol Yes Yes Yes Yes Yes
Extended Protocol No Yes Yes No Yes
Authentication N/A Optional Yes N/A Optional
oSIST prEN IEC 63563-6:2024
2 Overview
When a user places a Power Receiver within the Operating Volume of a Power Transmitter, the two
start to communicate with the aim to configure and control the power transfer. The Power Signal
provides the carrier for all communications. The QiSpecification, Communications Physical Layer
defines the low-level formats of data bits, data bytes, and data packets. The QiSpecification,
Communications Protocol (this document) defines the payloads of the data packets and their use in
the power control protocols.
2.1 Protocol phases
The QiSpecification defines two communications protocols.
Baseline Protocol—the original protocol introduced in version 1.0 of the Qi Power Class 0
Specification, which uses Power Receiver to Power Transmitter communications only.
Extended Protocol—added in version 1.2 of the Qi Power Class 0 Specification to support bi-
directional communications and enhanced Foreign Object Detection (FOD) features. Version
1.3 of the QiSpecification adds data transport stream functionality and authentication options.
As shown in Figure 2, the communications protocol comprises several phases. The negotiation
phase is not present in the Baseline Protocol.
Figure 2. Protocol phases
Power
Ping Configuration Negotiation
Transfer
Ping phase. The Power Transmitter tries to establish communications with a Power Receiver.
Before doing so, it typically performs measurements to determine if there are objects such as
bankcards, coins or other metals, which can damage or heat up during the power transfer.
These measurements proceed without waking up the Power Receiver. See the QiSpecification,
Power Delivery, for restrictions on such measurements.
NOTE: The Power Transmitter typically postpones a conclusion whether detected metals are Foreign
Objects or Friendly Metals to the negotiation phase, after obtaining design information from the
Power Receiver. See the QiSpecification, Foreign Object Detection, for details about recommended
methods.
Configuration phase. The Power Receiver sends basic identification and configuration data to
the Power Transmitter. Both sides use this information to create a baseline Power Transfer
Contract. Moreover, the Power Transmitter and Power Receiver decide whether to continue
with the Baseline Protocol or the Extended Protocol.
NOTE: A Power Receiver can only make use of features such as enhanced FOD, data transport streams,
and authentication if it implements the Extended Protocol.
oSIST prEN IEC 63563-6:2024
Negotiation phase. This phase is not present in the Baseline Protocol. The Power Transmitter
and Power Receiver establish an extended Power Transfer Contract containing additional
settings and limits. The Power Receiver also provides design information to the Power
Transmitter, which the latter can use to complete FOD before switching to the power transfer
phase. See the QiSpecification, Foreign Object Detection, for details about this information.
Power transfer phase. This is the phase in which the power transfer to the Power Receiver’s
Load occurs. In the Extended Protocol, the Power Transmitter and Power Receiver perform a
system calibration at the start of this phase. See the QiSpecification, Foreign Object Detection,
for details about calibration. Occasional interruptions of this phase may occur to renegotiate
an element of the Power Transfer Contract. However, the power transfer continues during
such renegotiations.
Table 4 summarizes the main features of the two protocol variants.
Table 4: Comparison of the Baseline Protocol and the Extended Protocol
Feature
Baseline Protocol Extended Protocol
Power Transmitter design Type Ax and type Bx designs All designs
only
Power Receiver to Power Load modulation at a fixed 2 Load modulation at a fixed 2 kHz clock
Transmitter Communications kHz clock
Power Transmitter to Power N/A Frequency shift keying at a frequency
Receiver Communications dependent clock of f /512
op
Operating phases Ping, configuration, and power Ping, configuration, negotiation, and
transfer power transfer
Power level calibration N/A At the start of the power transfer phase
Authentication N/A Using data transport streams in the
power transfer phase
oSIST prEN IEC 63563-6:2024
2.2 Power Transfer Contract
A Power Transfer Contract comprises the settings and limits governing the power transfer. The
Power Receiver sets up an initial Power Transfer Contract as applicable to the Baseline Protocol.
The first part of Table 5 shows the elements of this initial (or baseline) Power Transfer Contract.
The Power Transmitter receives all information to duplicate the baseline Power Transfer Contract
in the configuration phase of the protocol.
Some elements of the Power Transfer Contract are negotiable, enabling the Power Transmitter and
Power Receiver to determine new values for these elements in the negotiation phase of the
protocol (Extended Protocol only). In the Baseline Protocol, all elements of the Power Transfer
Contract keep their values until the power transfer ends.
The Extended Protocol makes use of an extended Power Transfer Contract that contains the
additional elements shown in the second part of Table 5. See the QiSpecification, Power Delivery,
and Section 6, Negotiation phase, for details about the use of these elements.
Table 5: Power Transfer Contract
Element Symbol Unit Negotiable Comment
Elements of a baseline Power Transfer Contract
The reference power level for RP8 and RP data
packets. The CFG data packet provides the initial
()ref
*
Reference Power W
P Yes
r
value. See Section 8.14, Received Power—RP8
(0x04; status update), for an example of its usage.
Received Power
The properties of the time window for measuring
t
ms No
window
window size
the Received Power. The CFG data packet provides
these values. See Figure 62 in Section 7.3, Power
Received Power
t
ms No
offset transfer phase timings.
window offset
The delay between the CE data packet and the
Power Control power level adjustment window. Defaults to 5 ms.
t
ms No
delay
Hold-off See Figure 61 in Section 7.3, Power transfer phase
timings.
Received Power
The resolution of the reported Received Power.
*
reporting N/A N/A
Yes
Defaults to 8 bit (RP8 data packet).
resolution
Additional elements of an extended Power Transfer Contract
Power Transmitter to Power Receiver
FSK polarity,
communications parameters. The CFG data packet
modulation depth,
N/A N/A Yes provides the initial values for the polarity and
and number of
modulation depth. The number of cycles per bit
cycles per bit
defaults to 512.
The highest Guaranteed Load Power level the Power
Potential Load Transmitter can negotiate. No default. See Section
()pot
WNo
P
L
Power 2.2.1, Load Power level negotiation, and the
Qi Specification, Power Delivery, for details.
oSIST prEN IEC 63563-6:2024
Table 5: Power Transfer Contract (Continued)
Element Symbol Unit Negotiable Comment
The negotiated power level. Defaults to 5 W. See
Guaranteed Load
()gtd
WYes Section 2.2.1, Load Power level negotiation, and the
P
L
Power
Qi Specification, Power Delivery, for details.
The delay between an EPT/rep data packet and the
t
Re-ping delay ms Yes
reping
next Digital Ping. Defaults to 12.6 second.
*
In the negotiation phase of the Extended Protocol
oSIST prEN IEC 63563-6:2024
2.2.1 Load Power level negotiation
A Power Receiver can typically operate at multiple target power levels. To determine the most
appropriate one, the Power Receiver negotiates a Guaranteed Load Power level with the Power
Transmitter. Figure 3 shows the steps involved.
Figure 3. Load Power levels
GRQ/cap SRQ/gp Power Transfer Contract
Potential Load Power
Requested Load Power (1)
Negotiable Load Power
Requested Load Power (2) Guaranteed Load Power
The Potential Load Power level is the highest Load power level the Power Transmitter can
negotiate at any time. The Negotiable Load Power level is the highest Load power level the Power
Transmitter is willing to negotiate at a given time. Usually, the Negotiable Load Power level is equal
to the Potential Load Power level. However, in some conditions, the Power Transmitter may set the
Negotiable Load Power level to a lower value. A first example of such a condition is an operating
temperature that can cause the Power Transmitter to overheat when transferring power at the
highest level. A second example is an insufficiently capable power supply driving the Power
Transmitter. The Power Receiver can retrieve the Potential Load Power level and the Negotiable
Load Power level from the Power Transmitter using a GRQ/cap data packet.
The Requested Load Power is the Load power level at which the Power Receiver intends to
operate. It provides this power level to the Power Transmitter using an SRQ/gp data packet. If the
Requested Load Power level is less than or equal to the Negotiable Load Power level, the power level
negotiation is successful, and both the Power Transmitter and Power Receiver store the Requested
Load Power level as a Guaranteed Load Power level in their copies of the Power Transfer Contract.
Section 6, Negotiation phase, Section 8.18.3, SRQ/gp—Guaranteed Load Power: parameter field and
responses, and Section 9.4, Power Transmitter Capabilities—CAP (0x31), provide details and
examples of power level negotiation sequences.
The Load Power level a Power Transmitter can support depends on several factors.
The designs of the Power Transmitter and Power Receiver
The position of the Power Receiver in the Operating Volume
The power supply of the Power Transmitter
The Load of the Power Receiver
The operating temperature
oSIST prEN IEC 63563-6:2024
The Potential Load Power, Negotiable Load Power, and Requested Load Power levels used in the
negotiation process are meaningful only if the Power Receiver has a design that is “similar” to one
the reference designs listed in Table 6. See the QiSpecification, Power Delivery, for details.
NOTE: A Power Receiver may attempt to draw more power than the Guaranteed Load Power level, and a
Power Transmitter may provide more power than the Guaranteed Load Power level or Potential Load
Power level. However, the system operation is undefined in those cases. See the QiSpecification, Power
Delivery, for details.
Table 6: Power Levels
*
Power Level Reference Power Receiver
5 W Power Receiver example 1,
Power Receiver example 2
8 W Power Receiver example 3
12 W Power Receiver example 5
15 W Power Receiver example 4
*
The Qi Specification, Power Receiver Design Examples,
defines the reference Power Receivers listed here.
2.2.2 Examples
Table 7, Table 8, and Table 9 provide examples of Power Transfer Contracts. In the Extended
Protocol, the initial Power Transfer Contract contains the elements of the baseline Power Transfer
Contract plus the elements of the extended Power Transfer Contract.
Table 7: Example of a baseline Power Transfer Contract when leaving the configuration phase
Element Symbol Power Receiver Value Power Transmitter Value
()ref
Reference Power 5 W 5 W
P
r
Received Power window size t
8 ms 8 ms
window
Received Power window offset t
8 ms 8 ms
offset
Power Control Hold-off t
5 ms 5 ms
delay
Received Power reporting resolution N/A 8 bit 8 bit
oSIST prEN IEC 63563-6:2024
Table 8: Example of an extended Power Transfer Contract when entering the negotiation phase
Element Symbol Power Receiver Value Power Transmitter Value
()ref
Reference Power 5 W 5 W
P
r
t
Received Power window size 8 ms 8 ms
window
Received Power window offset t 8 ms 8 ms
offset
t
Power Control Hold-off 5 ms 5 ms
delay
Received Power reporting resolution N/A 8 bit 8 bit
FSK polarity, modulation depth, and
N/A Positive / Category 0/512 Positive / Category 0/512
number of cycles per bit
()pot
Potential Load Power Unknown 15 W
P
L
()gtd
Guaranteed Load Power 5 W 5 W
P
L
t
Re-ping delay 1000 ms 1000 ms
reping
Table 9: Example of an extended Power Transfer Contract when leaving the negotiation phase
Element Symbol Power Receiver Value Power Transmitter Value
()ref
Reference Power 10 W 10 W
P
r
t
Received Power window size 8 ms 8 ms
window
t
Received Power window offset 8 ms 8 ms
offset
t
Power Control Hold-off 5 ms 5 ms
delay
Received Power reporting resolution N/A 16 bit 16 bit
FSK polarity, modulation depth, and
N/A Positive / Category 0/512 Positive / Category 0/512
number of cycles per bit
()pot
*
Potential Load Power 15 W or unknown 15 W
P
L
()gtd
Guaranteed Load Power 8 W 8 W
P
L
t
Re-ping delay 500 ms 500 ms
reping
* If the Power Receiver does not request the CAP data packet in the Extended Protocol, the Potential Load
Power remains unknown in the Power Receiver’s copy of the Power Transfer Contract.
oSIST prEN IEC 63563-6:2024
2.3 Data packet types
Whereas the Power Transmitter starts the communications protocol by applying a Digital Ping (at
the end of the ping phase), the Power Receiver drives the execution of the remaining phases of the
protocol. This means that the Power Receiver initiates all data packet communications, and that the
Power Transmitter waits to send a data packet or Response Pattern until explicitly invited to do so.
NOTE: Although it is the Power Receiver that drives the communications protocol, the Power Transmitter
may adjust the power level or stop the power transfer completely at any time if it considers that
necessary to ensure safe system operation. For additional information, see the QiSpecification, Power
Delivery.
The Power Receiver can send four kinds of data packets:
Status update—the Power Transmitter does not reply to these data packets.
Power control—the Power Transmitter adjusts the power level in response to these data
packets.
Simple query—invites the Power Transmitter to reply with a Response Pattern (ACK, NAK, ND,
ATN).
Data request—invites the Power Transmitter to reply with a full data packet.
NOTE: The Baseline Protocol uses status update and power-control data packets only.
The Power Transmitter should not respond to data packets that suffer from communications
errors. The reason is that data packet corruption could result in the Power Transmitter providing
the wrong type of response, confusing the Power Receiver. The lack of a response is a clear signal to
the Power Receiver that something went wrong and that it should resend the data packet.
oSIST prEN IEC 63563-6:2024
2.4 High-level messages and data transport streams
The purpose of most communications in the protocol is to configure and control the power
transfer. However, the Extended Protocol also supports data transport streams, which can pass
high-level messages (often unrelated to the power transfer) between the Power Transmitter and
Power Receiver. Examples of such messages include the authentication messages that the Power
Transmitter and Power Receiver can use to verify each other's credentials in a tamper-resistant
manner.
NOTE: The goal of authentication is to ensure that the Power Transmitter and/or the Power Receiver have
passed independent tests certifying safe operation.
A Power Receiver to Power Transmitter data transport stream consists of a sequence of simple-
query data packets, with the payloads of these data packets carrying the high-level message data.
The Power Receiver can initiate a data transport stream at any time in the power transfer phase.
Conversely, when a Power Transmitter has a high-level message to send to the Power
Receiver—and has ensured that the latter can process that message—it can draw the Power
Receiver's attention by responding with an ATN Response Pattern to an incoming simple-query
data packet in the power transfer phase. This signals the Power Receiver to transmit a series of
data-request data packets enabling the Power Transmitter to send a data transport stream.
oSIST prEN IEC 63563-6:2024
2.5 Backward compatibility
Table 10 summarizes the key differences between previous versions and version 1.3 of the
QiSpecification, Communications Protocol (this document), other than those associated with the
new data transport stream and authentication functionalities. Power Transmitters and Power
Receivers should examine their counterpart’s version number to handle these differences
appropriately.
NOTE: Prior to version 1.3, the definition of the communications protocol was contained in section 5 of the Qi
Wireless Power Transfer System, Power Class 0 Specification, Parts 1 and 2, Interface Definitions.
Table 10: Backward compatibility
Version Backward compatibility notes
1.0.x Baseline Protocol differences to version 1.3
The value contained in an RP8 data packet represents a rectified power level rather than a
Received Power level.
1.1.x —
1.2.x No Baseline Protocol differences to version 1.3
Extended Protocol differences to version 1.3
A Power Transmitter does not support a defined delay between the removal of the Power
Signal and the next Digital Ping
A Power Transmitter does not support a Power Receiver aborting the negotiation phase and
proceeding to the power transfer phase of the baseline protocol
A Power Transmitter does not support FOD/rf data packets (but it should be resilient to
receiving such data packets)
In the negotiation phase, a Power Transmitter responds with ND to simple-query data
packets having one or more reserved bits set to ONE rather than ignoring those bits
A Power Transmitter does not accept additional SRQ/en data packets after sending an ACK
Response Pattern to the first SRQ/en data packet at the end of the negotiation phase. If a
Power Receiver sends a second SRQ/en data packet, the Power Transmitter interrupts the
power transfer. Note that there is no power transfer interruption when both the Power
Receiver and Power Transmitter are v1.3 compliant.
A Power Receiver does not recognize ATN Response Patterns. Accordingly it will not send
DSR data packets inviting the Power Transmitter to send CAP data packets with the aim to
trigger the Power Receiver into renegotiating.
A Power Transmitter may send CHS, PROP, and/or reserved data packets while
calibrating (that is, before sending its first RP/0 or RP/4 data packet in the power transfer
phase).
1.3.x Extended protocol differences to version 2.0
A Power Transmitter does not support a reduced number of cycles per FSK bit.
oSIST prEN IEC 63563-6:2024
3 Power Receiver and Power Transmitter identification
A Power Receiver identifies itself to a Power Transmitter with the following information.
The version of the QiSpecification with which the Power Receiver complies.
A Power Receiver Manufacturer Code (PRMC) identifying the Power Receiver's manufacturer.
A basic device identifier identifying the Power Receiver among multiple Power Receiver's
present in the Operating Volume.
NOTE: The basic identifier may change from time to time as defined in Section 8.11, Identification—ID
(0x71; status update).
An optional extended device identifier providing additional information.
Optionally a Wireless Power ID (WPID). See Section 6.4, Wireless power ID, for details.
In the Extended Protocol, the Power Receiver can request the Power Transmitter to identify itself to
the Power Receiver with the following information.
The version of the QiSpecification with which the Power Transmitter complies.
A Power Transmitter Manufacturer Code (PTMC) identifying the Power Transmitter's
manufacturer.
A Power Transmitter Certificate. See QiSpecification, Authentication Protocol, for details.
NOTE: In the Baseline Protocol, a Power Receiver cannot retrieve a PTMC from the Power Transmitter.
However, this does not mean that the latter does not have an associated PTMC. The product
registration of the WPC requires the manufacturer of the Power Transmitter to submit a self-
declaration form listing the PTMC.
A Power Transmitter shall not use the PRMC in any way that limits the design freedom of the Power
Receiver. Conversely, a Power Receiver shall not use the PTMC in any way that limits the design
freedom of the Power Transmitter.
The purpose of the PRMC and PTMC is to enable Power Transmitters and Power Receivers of the
same manufacturer recognize Proprietary (PROP) data packets more easily.
As an example, a manufacturer can have multiple Power Receiver Products with substantially
different design properties such as coupling factor, Friendly Metal arrangement, etc. When using
knowledge of the PRMC only, a Power Transmitter can therefore easily make incorrect assumptions
about these properties. By adjusting its operation based on its assumptions, such as adjusting
thresholds etc., interoperability failure is likely to occur.
oSIST prEN IEC 63563-6:2024
4 Ping phase
At the start of the ping phase, the Power Transmitter does not yet know whether a Power Receiver
is present within its Operating Volume. The Power Receiver is not aware of the Power Transmitter
either, because its systems are typically inactive due to the lack of a Power Signal.
Figure 4 illustrates the stages of the ping phase. In the first three stages (dotted arrows), the Power
Receiver is not active. Moreover, the Power Transmitter should ensure that any signals it uses in
these phases do not wake up the Power Receiver. In the fourth stage (dashed arrow), the Power
Transmitter attempts to wake up the Power Receiver. In the last stage (solid arrow), the Power
Receiver starts its communications.
Figure 4. Stages of the ping phase
Power Transmitter Power Receiver
Analog Ping
NFC Tag Protection
Examine Operating Volume
Foreign Object Detection
Digital Ping
Wake Up Power Receiver
SIG or EPT
Indicate Presence
Before initiating a Digital Ping to solicit a response from a Power Receiver, the Power Transmitter
should go through the following stages.
Detect objects. For this purpose, the Power Transmitter can use Analog Pings or a variety of
alternative methods. The QiSpecification, Power Delivery, provides a number of examples.
Optionally apply NFC tag protection as defined in the QiSpecification, NFC Tag Protection.
The QiSpecification, NFC Tag Protection, provides recommendations about how to execute the
above steps.
NOTE: Instead of performing NFC tag detection, a Power Transmitter may limit the Power Signal throughout
the power transfer to levels that do not damage NFC tags. The QiSpecification, NFC Tag Protection,
provides guidelines and methods to determine safe power levels.
Collect information that helps to decide whether Foreign Objects are present in addition to a
Power Receiver. For this purpose, the Power Transmitter can use a variety of methods
commonly known as pre-power FOD methods. The QiSpecification, Foreign Object Detection,
defines these methods.
oSIST prEN IEC 63563-6:2024
After performing the above steps and determining that there potentially is a Power Receiver in its
operating Volume, the Power Transmitter initiates a Digital Ping to solicit a response from the
Power Receiver, which is either a Signal Strength (SIG) data packet or an End Power Transfer (EPT)
data packet. If there is no such response, the Power Transmitter stays in the ping phase and should
repeat the above steps.
NOTE: Power Transmitters employing multiple coils to enable a greater positioning freedom for a Power
Receiver typically initiate a Digital Ping multiple times using different coil. Typically, such Power
Transmitters abort the protocol after receiving the SIG data packet from the Power Receiver until they
have determined the optimum coil to use for the power transfer. The QiSpecification, Power Delivery,
provides examples
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...