Understanding NFC Data Exchange Format (NDEF) messages

This article explains the structure of a NDEF message with simple uniform resource identifier (URI) that describes web page address.

Introduction

Most NFC tags are passive elements those store data for reader (for NFC enabled mobile phones) in NDEF (NFC Data Exchange Format) format. When we touch our phones with any NFC forum enabled tags, actually we read the NDEF message by our application. Those happen via NFC application to protocol stack then low level driver and finally the radio frequency (RF) parts to retrieve data from tags.

In this article, we try to explain the structure of NDEF message with simple uniform resource identifier (URI) to describe web page address. We provide an example Qt mobility application that can be used to test it.

NDEF message and NDEF record

The NFC Data Exchange Format (NDEF) specification defines a message encapsulation format to exchange information, e.g. between an NFC Forum Device and another NFC Forum Device or an NFC Forum Tag. NDEF is a lightweight, binary message format that can be used to encapsulate one or more application-defined payloads of arbitrary type and size into a single message.

An NDEF message is composed of one or more NDEF records. There can be multiple records in a NDEF message. Basically NDEF message is array of NDEF records. How many records we can encapsulate in a NDEF message that depends on our application and the tag type. For our analysis purposes we use only one NDEF records. This NDEF record stores http://nokia.com. Following figure shows the general view of NDEF message^[1]^[2].

When we communicate with our NFC reader devices (mobile phones) to read or write data to NFC tag we read basically (for example http: //nokia . com) the following hexa code.

03 0e d1 01 0a 55 03 6e 6f 6b 69 61 2e 63 6f 6d fe

03 - This is one byte that defines the type of record this is. An NDEF record is represented by the hex byte 03, with Qt mobility API we don’t provide this, those are added for us.
0e - This is one byte that tells the reader how many bytes are in the payload.With Qt mobility API we don’t provide this, those are added for us by platform.
d1 - NDEF records are variable length records with a common format illustrated in the figure below.

d1 is binary code (11010001)

In our case:

MB = 1 (message Begin is true means this is first record in the NDEF message)
ME = 1 (Message end, means it is last record in the NDEF message, if it is 0 that tells application that more records are ahead)
CF = 0 (means this is not chunked message, An NDEF message can contain zero or more chunked payloads. Each chunked payload is encoded as an initial record chunk followed by zero or more middle record chunks and finally by a terminating record chunk, in our case we simplify our record as not chunked)
SR = 1 (SR stands for short record, if set, that the payload length field is a single octet.This short record layout is intended for compact encapsulation of small payloads which will fit within PAYLOAD fields of size ranging between 0 to 255 octets.)
IL = 0(IL stands for identification length, if set, that the ID_LENGTH field is present in the header as a single octet. If the IL flag is zero, the ID_LENGTH field is omitted from the record header and the ID field is also omitted from the record)
TNF = 001(The TNF field value indicates the structure of the value of the TYPE field. The value 0x01 (NFC Forum well-known type) indicates that the TYPE field contains a value that follows the RTD type name format defined in the NFC Forum RTD specification)
01 (Type Length) - The TYPE_LENGTH field is an unsigned 8-bit integer that specifies the length in octets of the TYPE field. The TYPE_LENGTH field is always zero for certain values of the TNF field.
0A (Pay load Length) - The PAYLOAD_LENGTH field is an unsigned integer that specifies the length in octets of the PAYLOAD field (the application payload). The size of the PAYLOAD_LENGTH field is determined by the value of the SR flag
55 (type The value of the TYPE field is an identifier describing the type of the payload, The URI record type (“U”) )
03 - 0x03 URI identifier (“http://”)
Pay Load - The rest of the string in UTF-8 (nokia.com)
FE Terminator byte. This is final byte added by platform.