Understanding the format of NDEF Messages — Part 1
The NFC Data Exchange Format (NDEF) is a standardized data format that can be used to exchange information between any compatible NFC device and another NFC device or tag. The data format consists of NDEF Messages and NDEF Records.
In this series of articles, I will explain how an NDEF message can be constructed and stored on an NFC tag. Assume a company wants to issue tags to that can be used in public transport systems as a replacement of paper tickets. These tags can be tapped on an NFC enabled Android device which will scan the tag and register entry and exit time of the user. I won’t be going into how the application logic should be constructed but will be dealing with how the required data can be put on the tags.
In this article lets get an overview of how NDEF messages are constructed.
NDEF messages are the basic transport mechanism for NDEF records, with an NDEF message containing one or more NDEF records.
For this use case the tag primarily needs the following records on it:
- A user identifier, say username to identify the user.
- An application identifier, to tell the android system which app will be handling the NFC tag.
NDEF Records contain a specific payload and have the following structure that identifies the contents and size of the record. The basic elements that construct an NDEF record are:
- TNF ie. Type Name Format Field
typewhich is a value corresponding to bits set in TNF field
- ID value
- payload value
More specifically an NDEF record can be composed in the following way.
Bit 7 6 5 4 3 2 1 0
------ ------ ------ ------ ------ ------ ------ ------
[ MB ] [ ME ] [ CF ] [ SR ] [ IL ] [ TNF ]
[ TYPE LENGTH ]
[ PAYLOAD LENGTH ]
[ ID LENGTH ]
[ RECORD TYPE ]
[ ID ]
[ PAYLOAD ]
NDEF record explained
An NDEF record starts with 8 bits header that describes the record.
TNF: The Type Name Format or TNF Field of an NDEF record is a 3-bit value that describes the record type.
IL [ID Length bit]: The IL flag indicates if the ID Length Field is present or not.
SR [Short Record bit]: The SR flag is set to 1 if the payload length field is 1 byte (8 bits/0–255) or less. This allows for more compact records.
CF [Chunk Flag bit]: The CF flag indicates if this is the first record chunk or a middle record chunk. For the 1st record of the message, it is set to 0 and for subsequent records, it is set to 1.
ME [Message End bit]: The ME flag indicates if this is the last record in the message. It is set to 1 for the last record.
MB [Message Begin bit]: The MB flag indicates if this is the first record in the message. It is set to 1 for the first message.
For our application, we need the following NDEF records.
- tnf: TNF_MIME_MEDIA,
- type: application/vnd.com.tickets [in bytes]
- id: null
- payload: byjwdH_6DNsuU4iTSrVaNEe6e52VLhhr4v_iGTRP7jQ= [in bytes]
Android Application Record(AAR)
- tnf: TNF_EXTERNAL_TYPE
- type: android.com:pkg [in bytes]
- id: null
- payload: com.example.tickets [in bytes]
We have seen an overview of the different parts of an NDEF message. In the next part of this article, we will see how these two NDEF records can be written on a tag. We will discuss two kinds of tags ie. Mifare Ultralight C and Mifare Classic.
Make sure you give this post 50 claps and follow me if you enjoyed this post and want to see more!