EN IEC 63563-6:2025

SLOVENSKI STANDARD
01-marec-2026
Različica specifikacije Qi 2.0 - 6. del: Komunikacijski protokol (IEC 63563-6:2025)
Qi Specification version 2.0 - Part 6: Communications protocol (IEC 63563-6:2025)
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)
Ta slovenski standard je istoveten z: EN IEC 63563-6:2025
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
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN IEC 63563-6

NORME EUROPÉENNE
EUROPÄISCHE NORM March 2025
ICS 29.240.99; 35.240.99
English Version
Qi Specification version 2.0 - Part 6: Communications Protocol
(IEC 63563-6:2025)
Spécification Qi version 2.0 - Partie 6: Protocole de Qi Spezifikation Version 2.0 - Teil 6:
communications Kommunikationsprotokoll
(IEC 63563-6:2025) (IEC 63563-6:2025)
This European Standard was approved by CENELEC on 2025-03-21. CENELEC members are bound to comply with the CEN/CENELEC
Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the
same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Türkiye and the United Kingdom.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2025 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN IEC 63563-6:2025 E

European foreword
The text of document 100/4251/FDIS, future edition 1 of IEC 63563-6, prepared by TC 100/Technical
Area 15 "Wireless Power Transfer" was submitted to the IEC-CENELEC parallel vote and approved by
CENELEC as EN IEC 63563-6:2025.
The following dates are fixed:
• latest date by which the document has to be implemented at national (dop) 2026-03-31
level by publication of an identical national standard or by endorsement
• latest date by which the national standards conflicting with the (dow) 2028-03-31
document have to be withdrawn
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC shall not be held responsible for identifying any or all such patent rights.
Any feedback and questions on this document should be directed to the users’ national committee. A
complete listing of these bodies can be found on the CENELEC website.
Endorsement notice
The text of the International Standard IEC 63563-6:2025 was approved by CENELEC as a European
Standard without any modification.

IEC 63563-6 ®
Edition 1.0 2025-02
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
Qi Specification version 2.0 –

Part 6: Communications Protocol

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
INTERNATIONALE
ICS 29.240.99, 35.240.99 ISBN 978-2-8327-0189-8

- 2 - IEC 63563-6:2025 © IEC 2025
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
QI SPECIFICATION VERSION 2.0 –
Part 6: Communications Protocol
FOREWORD
 The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprisingall
national electrotechnical committees (IEC National Committees). The object of IEC is to promote internationalco-
operation on all questions concerning standardization in the electrical and electronic fields. To this end andin addition
to other activities, IEC publishes International Standards, Technical Specifications, TechnicalReports, Publicly
Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Theirpreparation is entrusted to
technical committees; any IEC National Committee interested in the subject dealt withmay participate in this
preparatory work. International, governmental and non-governmental organizationsliaising with the IEC also
participate in this preparation. IEC collaborates closely with the InternationalOrganization for Standardization
(ISO) in accordance with conditions determined by agreement between the twoorganizations.
 The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
 IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
 In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence betweenany IEC
Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
 IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
 All users should ensure that they have the latest edition of this publication.
 No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage orother
damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) andexpenses
arising out of the publication, use of, or reliance upon, this IEC Publication or any other IECPublications.
 Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
 IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights inrespect
thereof. As of the date of publication of this document, IEChad not received notice of (a) patent(s),which may be
required to implement this document. However, implementers are cautioned that this may notrepresent the latest
information, which may be obtained from the patent database available athttps://patents.iec.ch. IEC shall
not be held responsible for identifying any or all such patent rights.
IEC 635-6 has been prepared by technical area 15: Wireless Power Transfer, of IEC
technical committee 100: Audio, video and multimedia systems and equipment. It is an
International Standard.
It is based on Qi Specification version 2.0, Communications Protocol and was submitted as a
Fast-Track document.
The text of this International Standard is based on the following documents:
Draft Report on voting
//FDIS //RVD
IEC 63563-6:2025 © IEC 2025 - 3 -
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this International Standard is English.
The structure and editorial rules used in this publication reflect the practice of the organization
which submitted it.
This document was developed in accordance with ISO/IEC Directives, Part 1 and ISO/IEC
Directives, IEC Supplement available at www.iec.ch/members_experts/refdocs. The main
document types developed by IEC are described in greater detail at www.iec.ch/publications.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
x reconfirmed,
x withdrawn, or
x revised.
- 4 - IEC 63563-6:2025 © IEC 2025
WIRELESS POWER
CONSORTIUM
Qi Specification
Communications Protocol
Version 2.0
April 2023
IEC 63563-6:2025 © IEC 2025 - 5 -
DISCLAIMER
Theinformationcontainedhereinisbelievedtobeaccurateasofthedateofpublication,
butisprovided“asis”andmaycontainerrors.TheWirelessPowerConsortiummakesno
warranty,expressorimplied,withrespecttothisdocumentanditscontents,includingany
warrantyoftitle,ownership,merchantability,orfitnessforaparticularuseorpurpose.
NeithertheWirelessPowerConsortium,noranymemberoftheWirelessPower
Consortiumwillbeliableforerrorsinthisdocumentorforanydamages,includingindirect
orconsequential,fromuseoforrelianceontheaccuracyofthisdocument.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.

- 6 - IEC 63563-6:2025 © IEC 2025
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

IEC 63563-6:2025 © IEC 2025 - 7 -
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

- 8 - IEC 63563-6:2025 © IEC 2025
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
IEC 63563-6:2025 © IEC 2025 - 9 -
1.2 Scope
The QiSpecification,CommunicationsProtocol (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.

- 10 - IEC 63563-6:2025 © IEC 2025
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
IEC 63563-6:2025 © IEC 2025 - 11 -
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,
CommunicationsProtocol, and refers to a particular value in a field of the data packet.
The definitions of the data packets in the QiSpecification,CommunicationsProtocol, 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.
- 12 - IEC 63563-6:2025 © IEC 2025
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.
ƒ BPPPTx: A Baseline Power Profile Power Transmitter.
ƒ EPP5PTx: An Extended Power Profile Power Transmitter having a restricted power transfer
()pot
capability, i.e. P = 5 W.
L
ƒ EPPPTx: An Extended Power Profile Power Transmitter.
ƒ BPPPRx: A Baseline Power Profile Power Receiver.
ƒ EPPPRx: 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

IEC 63563-6:2025 © IEC 2025 - 13 -
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,CommunicationsPhysicalLayer
defines the low-level formats of data bits, data bytes, and data packets. The QiSpecification,
CommunicationsProtocol(this document) defines the payloads of the data packets and their use in
the power control protocols.
2.1 Protocol phases
The QiSpecificationdefines two communications protocols.
ƒ BaselineProtocol—the original protocol introduced in version 1.0 of the Qi Power Class 0
Specification, which uses Power Receiver to Power Transmitter communications only.
ƒ ExtendedProtocol—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 QiSpecificationadds 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
ƒ Pingphase. 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,
PowerDelivery,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,ForeignObjectDetection,for details about recommended
methods.
ƒ Configurationphase. 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.

- 14 - IEC 63563-6:2025 © IEC 2025
ƒ Negotiationphase. 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,ForeignObjectDetection,for details about this information.
ƒ Powertransferphase. 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,ForeignObjectDetection,
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
IEC 63563-6:2025 © IEC 2025 - 15 -
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,PowerDelivery,
and Section6,Negotiationphase,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.

- 16 - IEC 63563-6:2025 © IEC 2025
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

IEC 63563-6:2025 © IEC 2025 - 17 -
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.
Section6,Negotiationphase, Section8.18.3,SRQ/gp—GuaranteedLoadPower:parameterfieldand
responses, and Section9.4,PowerTransmitterCapabilities—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
- 18 - IEC 63563-6:2025 © IEC 2025
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,PowerDelivery,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
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

IEC 63563-6:2025 © IEC 2025 - 19 -
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
Re-ping delay t 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
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 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.

- 20 - IEC 63563-6:2025 © IEC 2025
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:
ƒ Statusupdate—the Power Transmitter does not reply to these data packets.
ƒ Powercontrol—the Power Transmitter adjusts the power level in response to these data
packets.
ƒ Simplequery—invites the Power Transmitter to reply with a Response Pattern (ACK, NAK, ND,
ATN).
ƒ Datarequest—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.

IEC 63563-6:2025 © IEC 2025 - 21 -
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.

- 22 - IEC 63563-6:2025 © IEC 2025
2.5 Backward compatibility
Table 10 summarizes the key differences between previous versions and version 1.3 of the
QiSpecification,CommunicationsProtocol(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
WirelessPowerTransferSystem,PowerClass0Specification,Parts1and2,InterfaceDefinitions.
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 on
...