Disclaimer   Copyright © 2010-2011 Inside Secure   Licensed under the Apache License, Version 2.0 (the "License");you may not use this file except in compliance with the License.You may obtain a copy of the License at       http://www.apache.org/licenses/LICENSE-2.0   Unless required by applicable law or agreed to in writing, softwaredistributed under the License is distributed on an "AS IS" BASIS,WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.See the License for the specific language governing permissions andlimitations under the License.   Content of the NOTICE file:   Open NFC and the Open NFC logo are trademarks or registered trademarks of Inside Secure.   Other brand, product and company names mentioned herein may be trademarks, registered trademarks or trade names of their respective owners.

 

History
Version	Date	Comments
0.1	March 9, 2010	First Draft
0.2	April 4, 2010	Delivery for customer review
1.0	Dec. 24, 2010	Delivery for Open NFC 4.1
1.1	Feb. 6, 2011	Delivery for Open NFC 4.2.2
1.2	May 16, 2011	Delivery for Open NFC 4.3 Beta Renaming the document from FSP_NFC_1003-188 into SIS_NFC_1003-188.
1.3	July 28, 2011	Delivery for Open NFC 4.3
1.4	Aug. 10, 2011	Delivery for Open NFC 4.3.1

 

 

Content

1               NFC Tags. 4

1.1    Overview.. 4

1.1.1       Types of NFC Tags. 4

1.1.2       Implicit Handling of the Flags. 4

1.1.3       NDEF Type Name Format 4

1.1.4       NDEF Type Comparison. 6

1.1.5       NDEF Record Identifier 7

1.1.6       URI Format 7

1.2    NFC Tag Manager 9

1.3    Text Records. 11

1.3.1       The Language Format 11

1.3.2       Language Matching. 11

1.4    URI Records. 12

2               NFC Controller. 15

2.1    The NFC Controller Modes. 15

2.1.1       Boot Sequence. 16

2.1.2       Activity Modes. 16

2.1.3       Maintenance Modes. 17

2.1.4       Error Modes. 18

2.1.5       Function Availability. 18

2.2    RF Locks. 19

3               NFC Properties. 21

 

 

1      NFC Tags

The NFC tag API is used to generate or to parse NFC Tags containing NDEF messages as defined by the NFC Forum (http://www.nfcforum.org).

 

The following items are managed by the API:

·         NFC Tags,

·         NDEF Messages

·         NDEF Records

·         NDEF Message included in record payload.

 

The API provides all the functions required:

·         to build new records or new messages,

·         to parse records and messages,

·         to read NDEF messages from tags, and

·         to write NDEF message into the tags.

1.1    Overview

1.1.1     Types of NFC Tags

Several tag types are defined to store the NDEF messages. The difference between the tags is the capacity of the tag and the capability to lock the tag. The following table describes the tag types:

 

Tag Type	Useful capacity for the NDEF message	Can be locked
Type 1	96 bytes or 512 bytes	yes
Type 2	48 bytes or 148 bytes	yes
Type 3	depends on the tag	yes
Type 4	depends on the tag	no
Type 5	232 bytes or 4048 bytes	yes
Type 6	depends on the tag	yes

1.1.2     Implicit Handling of the Flags

The NDEF API transparently generates and read the message begin flag (MB), the message end flag (ME), the short records identified by the SR flag, and the chunked records identified with the CR flag.

1.1.3     NDEF Type Name Format

The type of record (RTD) is defined by an integer and a string. The integer is the type definition described below. The meaning of the string depends on the value of the type definition. The string should contain only printable ASCII characters.

 

The list of the type definition constants is the following:

 

Type	Description	Type String
EMPTY	Empty Record with no type or payload associated. When used, the TYPE_LENGTH, ID_LENGTH, and PAYLOAD_LENGTH fields are zero and the TYPE, ID, and PAYLOAD fields are thus omitted from the record. This TNF value can be used whenever an empty record is needed; for example, to terminate an NDEF message in cases where there is no payload defined by the user application.	Must be null.
WELL_KNOWN	NFC Forum well-known type. The TYPE field contains a value that follows the RTD type name format defined in the NFC Forum RTD specification.	The well-known RTD type name.
MEDIA	Media-type as defined in RFC 2046. The TYPE field contains a value that follows the media-type BNF construct defined by RFC 2046	The media-type BNF construct defined by RFC 2046
ABSOLUTE_URI	Absolute URI as defined in RFC 3986. The TYPE field contains a value that follows the absolute-URI BNF construct defined by RFC 3986.	The absolute-URI BNF construct defined by RFC 3986 using the printable representation as defined in 1.1.6 URI Format”.
EXTERNAL	NFC Forum external type. The TYPE field contains a value that follows the type name format defined for external type names.	The external name.
UNKNOWN	This value is used to indicate that the type of the payload is unknown. This is similar to the “application/octet-stream” media type defined by MIME (RFC 2046). When used, the TYPE_LENGTH field is zero and thus the TYPE field is omitted from the NDEF record.	Must be null.
UNCHANGED	Unchanged. This value is used in all middle record chunks and the terminating record chunk used in chunked payloads. It is not used in any other record. When used, the TYPE_LENGTH field MUST be zero and thus the TYPE field is omitted from the NDEF record.	Must be null.
ANY_TYPE	Any type. This value is used with the read functions to read every message regardless of their type.	Must be null.

1.1.4     NDEF Type Comparison

The comparison of two record types depends on the type definition.

 

Type	Comparison Rules
EMPTY	Both record type names shall be null.
WELL_KNOWN	Before performing the comparison, the prefix urn:nfc:wkt: is removed from the type names, if present. Then both record type names shall be identical. The comparison is case-sensitive.
MEDIA	Comparison character-by-character in case-insensitive manner up to the first ";".
ABSOLUTE_URI	Before performing the comparison, the following operation are performed: ·         The reserved characters must be percent-encoded using uppercase letters for the hexadecimal digits. ·         The scheme and host parts of the URI must be normalized to lowercase. Then both record type names shall be identical. The comparison is case-sensitive.
EXTERNAL	Before performing the comparison, the prefix urn:nfc:ext: is removed from the type names, if present. Then both record type names shall be identical. The comparison is case-insensitive.
UNKNOWN	Both record type names shall be null.
UNCHANGED	Both record type names shall be null.
ANY_TYPE	Always true

1.1.5     NDEF Record Identifier

Each NDEF record may include an optional identifier. Record identifiers are URI defined in the specification document RFC 3986. When present, the identifier may be used to identify a record within a message.

Identifier Encoding

The URI are encoded in the record following the UTF8 encoding as defined in the next section.

Uniqueness

Each time a record is added to a message, the API implementation checks that the identifier of the record is not already present in a record of the message. An error is returned if the identifier is already in the message. If the record has no identifier, there is no check.

1.1.6     URI Format

The URI format is defined in the specification document RFC 3986. 

 

The NFC software stack uses three encoding of the URI string as defined in RFC 3986: The UTF8 encoding, the printable representation and the ASCII encoding.

 

The following figure describes the different encoding of the URIs:

 

 

 

Figure 1    URI Encoding

UTF8 Encoding

The UTF8 representation is the UTF8 encoding of the URI string without escapement.

Printable Representation

The printable representation is the encoding of the URI string with escapement. The following ASCII characters are left unchanged:

 

':', '/', '?', '#', '[', ']', '@','!', '$', '&', ''', '(', ')',

'*', '+', ',', ';', '=', '-', '.', '_', '~'

['a', 'z'], ['A', 'Z'], ['0', '9']

 

The other characters are encoded as follows:

·         For the characters in the range [0x00, 0xFF], a percent character ‘%’ followed by the two upper-case hexadecimal digits of character value.

·         For the other Unicode characters, the characters ‘%u’ followed by the four upper-case hexadecimal digits of character value.

ASCII Encoding

The ASCII representation is the ASCII encoding of the URI string without escapement. Of course this representation is limited to the URI using characters in the range [0x00, 0xFF] only.

1.2     NFC Tag Manager

Depending on the client application requirements, several functions are provided to access a NFC tag.

First Use-Case:

·         The application wants to use only already formatted NFC tags and non formatted NFC tags.

 

·         The application wants to perform a single NDEF operation on the first valid NFC tag presented.

 

In this case, the simplest way is to use the methods NfcTagManager.registerMessageReader() or NfcTagManager.writeMessageOnAnyTag ().

Second Use-Case:

·         The application wants to use only already formatted NFC tags and non formatted NFC tags.

 

·         The application wants to perform several NDEF operations on the tags.

 

In this case, the client application must register a handler for the NFC tags, using  NfcTagManager.registerTagListener(). Once the tag presented and the connection established, the application uses the methods NfcTagConnection.readMessage() and NfcTagConnection.writeMessage() to read / write NDEF messages from / into the tag.

Third Use-Case:

·         Same as first use case, but the application also wants to use only a specific NFC tag type or a subset of all NFC tags type supported.

 

In this case, the client application must register a handler for the NFC tag types or the corresponding chips, using card listener registry CardListenerRegistry. Once a tag is presented, the application checks if the tag is already formatted (using the connections properties). If the tag is not formatted, the application must use NfcTagConnection.writeMessage() to format the tag. Once the tag is formatted, the application can use methods NfcTagConnection.readMessage()and NfcTagConnection.writeMessage() to read / write NDEF messages from / into the tag.

Formatting Support:

We distinguish several states for a NFC tag:

 

·         Blank: The tag is empty and not formatted: its content has not been modified after the production of the tag.

 

·         Non-NDEF: The tag is not formatted for NDEF usage but is contains data, the content of the tag differs from the default content of the tag after production.

 

·         NDEF Empty: The tag has been formatted in NDEF format, but do not contain any NDEF record or any proprietary data included in the NDEF format.

 

·         NDEF: The tag has been formatted in NDEF format and contains at least one NDEF record or some proprietary data included in the NDEF format.

 

 

Below a table showing for different tags state supported by the write functions:

 

Methods	Tag Status
	Blank	Non-NDEF	NDEF Empty	NDEF
NfcTagConnection.readMessage()	no	no	yes	yes
NfcTagManager.registerMessageReader()	no	no	yes	yes
NfcTagConnection.writeMessage()	yes (1)	yes (2)	yes	yes
NfcTagManager.writeMessageOnAnyTag ()	yes (1)	yes (2)	yes	yes

 

(1)  Blank tag support is available only if ACTION_BIT_FORMAT_BLANK_TAG, ACTION_BIT_FORMAT_NON_NDEF_TAG  or ACTION_BIT_FORMAT_ALL bit is set in the actionFlags parameter.

(2)  Tags that contain non NDEF contents support is available only if ACTION_BIT_FORMAT_NON_NDEF_TAG or ACTION_BIT_FORMAT_ALL bit is set in the actionFlags parameter.

 

The following table explains the change of tag status caused by the formatting flags:

 

Formatting Flags	Initial Tag Status
	Blank	Non-NDEF	NDEF Empty	NDEF
ACTION_BIT_FORMAT_BLANK_TAG	NDEF Empty	no change	no change	no change
ACTION_BIT_FORMAT_NON_NDEF_TAG	NDEF Empty	NDEF Empty(1)	no change	no change
ACTION_BIT_FORMAT_ALL	NDEF Empty	NDEF Empty(1)	no change	NDEF Empty (2)

 

(1)  The data included in the tag are erased

(2)  The proprietary data included in the NDEF format, if any, are erased

 

Using ACTION_BIT_FORMAT_BLANK_TAG option prevents to format tags that may contents valuable non NDEF information, since it allows formatting of tags that were not modified after their production.

Getting Tag Information

The methods of the NFC tag connection NfcTagConnection returns the information on a tag:

·         the free size on the tag,

·         the serial number of the tag, and

·         the lock status.

1.3    Text Records

Text records define the format in which to store a localized text in a NDEF message. Text records are handled with the class TextRecord.

1.3.1     The Language Format

The format of the language in the text record is defined in the RFC 3066 “Tags for the Identification of Languages”, H. Alvestrand, Cisco Systems, January 2001 (http://www.faqs.org/rfcs/rfc3066.html).

 

The language code is typically either two characters or five characters, though in the future, it is likely that it will be possible to have longer codes. The two-character version disregards any dialects, and thus is used most often.  For example, “fi” for Finnish, “jp” for Japanese, “fr” for French. However, in some cases you might want to differentiate between variants of the same language, such as providing US-English and British English versions via “en-US” and “en-UK” respectively.

1.3.2     Language Matching

This language comparison algorithm compares two language codes and returns on of the following value: “exact match” if the two languages match exactly, “partial match” if the two languages match partially and “no match” if the languages do not match.

 

The text comparisons are case insensitive.

 

The language matching algorithm consider only the language codes with two letters with a primary sub tag as defined in ISO 639, or the language codes with five letters, i.e. a primary and a secondary sub tag of two letters as defined in ISO 639 and ISO 3166.

 

If one of the compared language codes is not in this category, the algorithm returns “exact match” if the two language codes are identical. Otherwise, the algorithm returns “no match”.

 

If a language code A is “<A1>” or “<A1>-<A2>” and a language code B is “<B1>” or “<B1>-<B2>”, the following table gives the results of the comparison of A and B:

 

Language A	Language B	Condition	Result
<A1>	<B1>	A1 != B1	No match
		A1 = B1	Exact match
<A1>-<A2>	<B1>	A1 != B1	No match
		A1 = B1	Partial match
<A1>-<A2>	<B1>-<B2>	A1 != B1	No match
		A1 = B1 and A2 != B2	Partial match
		A1 = B1 and A2 = B2	Exact match

 

When the language of a text record is compared with two languages, the algorithm first looks for the best match with the primary language and if no match is found, it looks for the match with the secondary language.

 

The following array defines the constants returned by the comparison functions:

 

Result Value	Description
TEXT_MATCH_1	The primary language matches exactly the language of the record.
TEXT_PARTIAL_MATCH_1	The primary language matches partially the language of the record.
TEXT_MATCH_2	The secondary language matches exactly the language of the record.
TEXT_PARTIAL_MATCH_2	The secondary language matches partially the language of the record.
TEXT_NO_MATCH_FOUND	The languages do not match the language of the record.

1.4     URI Records

URI records define the format to store an URI value in a NDEF message. The URI format defined by the NFC forum includes a format compressed by tokenization of the URI prefix. This compressed format is implemented transparently by the class UriRecord.

 

The URI strings used with UriRecord follow the printable representation of the URI as defined in “URI Format”.

 

An NDEF URI Record consists in:

 

·         An URI identifier code, offering possibility to shorten the URI,

·         A string containing the rest of the URI, or the entire URI, if URI identifier code is 0x00

Encoding an NDEF URI

Before being stored in the NDEF record, the URI value is processed as follows:

 

·         Parse the URI trying to identify a prefix of the “Abbreviation Table” (see Table 3 of the NFC Forum document NFCForum-TS-RTD_URI_1.0)

·         If a prefix is recognized, the prefix is removed, and the URI identifier code is set to the corresponding value found in this table (e.g. the 11 characters “http://www. “ will be replaced by the URI identifier code 0x01)

·         otherwise, the URI identifier code is set to 0x00, and the URI string is kept unmodified.

Examples:

 

1)    Simple URL with no substitution

 

Open NFC does not find any matching prefix in the Abbreviation table, so

·         URI identifier code = 0x00,

·         URI string = “www.open-nfc.org” unmodified.

Offset	Content	Explanation
0	0xD1	SR = 1, TNF = 0x01 (NFC Forum Well Known Type), ME=1, MB=1
1	0x01	Length of the Record Type (1 byte)
2	0x11	Length of the payload (17 bytes)
3	0x55	The Record Name (“U”)
4	0x00	No abbreviation
5	0x77 0x77 0x77 0x2E 0x6F 0x70 0x65 0x6E 0x2D 0x6E 0x66 0x63 0x2E 0x6F 0x72 0x67	The string “www.open-nfc.org“.  (16 bytes)

 

2)    URL with known prefix

 

Open NFC finds a matching prefix in the abbreviation table ( “http://www.” ), so

·         URI identifier code = 0x01,

·         URI string = “open-nfc.org”, compressed.

Offset	Content	Explanation
0	0xD1	SR = 1, TNF = 0x01 (NFC Forum Well Known Type), ME=1, MB=1
1	0x01	Length of the Record Type (1 byte)
2	0x0B	Length of the payload (13 bytes)
3	0x55	The Record Name (“U”)
4	0x01	URI identifier (“http://www.”)
5	0x6F 0x70 0x65 0x6E 0x2D 0x6E 0x66 0x63 0x2E 0x6F 0x72 0x67	The compressed string “open-nfc.org“. (12 bytes)

 

Decoding an NDEF URI

When an NDEF URI Record is read on a tag, Open NFC automatically appends the prefix, corresponding to the URI identifier code, to the URI string, so the caller application has no more process to perform in order to use the URI detected on the tag.

2      NFC Controller

The RF and NFC Controller tests are used to control and to test the functionalities of the following elements:

·         the software stack,

·         the NFC Controller hardware,

·         the NFC Controller firmware,

·         the NFC RF modem, and

·         the NFC RF antenna.

2.1    The NFC Controller Modes

The NFC Controller behavior is defined by a mode of execution. The following table defines the constants representing the NFC Controller modes:

 

Constant	Description	Type of Activity
BOOT_PENDING	A boot procedure is pending.	Boot Sequence
MAINTENANCE	Maintenance mode, the firmware can be used.	Maintenance Modes
NO_FIRMWARE	Maintenance mode, no firmware is present.
FIRMWARE_NOT_SUPPORTED	Maintenance mode, the version of the firmware is not supported by the stack
NOT_RESPONDING	The NFC Controller is not responding.	Error Modes
LOADER_NOT_SUPPORTED	The version of the loader is not supported.
ACTIVE	The NFC Controller is active.	Activity Modes
SWITCH_TO_STANDBY	The NFC Controller is switching from active mode to standby mode
STANDBY	The NFC Controller is in standby mode
SWITCH_TO_ACTIVE	The NFC Controller is switching from standby mode to active mode

 

 

The mode state diagram is illustrated in the following figure:

 

 

Figure 2    The NFC Controller modes

2.1.1     Boot Sequence

When the NFC Controller is powered, the mode is “boot pending”. The boot sequence switches automatically to the mode “active” if the stack can communicate with the NFC Controller firmware. If there is no firmware or if the firmware version is not supported, the boot procedure switches to one of the maintenance modes. If the NFC Controller is not responding or if the stack cannot communicate with the NFC Controller loader, the stack enters in the appropriate error mode. During the boot sequence, the mode is BOOT_PENDING.

2.1.2     Activity Modes

In “active” mode, most of the NFC Controller functions can be executed, except the test functions. The method reset() is used to switch to the maintenance mode. If a critical error occurs with the NFC Controller, the stack enters in one of the error modes.

 

The NFC Controller may switch from the “active” mode into the “standby” mode. The standby mode reduces the power consumption of the NFC Controller. In standby mode, the RF cannot be used for reader mode. The NFC Controller may enter in standby mode for any of these reasons:

·         The method switchToStandbyMode() is called to switch in standby mode. In this case, the NFC Controller switches to standby mode even if there is a reader active. The reader activity will be cut off.

·         There is no reader mode active and there is no communication with the NFC Controller for a given time. Then the NFC Controller switches spontaneously in standby mode.

 

The value of the timeout used to switch to standby mode is given by the NFC Controller property “nfcc.standby_timeout”. If this value is zero, the NFC Controller does not switch spontaneously in standby mode.

 

The NFC Controller leaves the standby mode and returns to the activity mode for any of these reasons:

·         The method switchStandbyMode() is called to switch in active mode.

·         A reader field is detected. This may mean that a remote reader or a peer to peer device is in range.

·         A function of the Client API is called and this function requires a communication with the NFC Controller.

 

Whatever the cause of the wake up of the NFC Controller, the configuration and the behavior of the NFC Controller are identical before and after switching to standby mode. The RF modes (reader, card, P2P), the handles (registry, connection etc…) are still valid. In other words switching to standby mode is completely transparent for an application.

 

The activity modes are the following:

·         ACTIVE,

·         SWITCH_TO_STANDBY,

·         STANDBY, and

·         SWITCH_TO_ACTIVE.

2.1.3     Maintenance Modes

The stack enters in one of the maintenance modes after a reset. The nature of the maintenance mode depends on the presence of a firmware and the capability of communicating with it. In maintenance mode, the test functions and the firmware update functions are accessible.

 

The maintenance modes are the following:

·         MAINTENANCE,

·         NO_FIRMWARE, and

·         FIRMWARE_NOT_SUPPORTED.

2.1.4     Error Modes

The stack enters into an error mode if a critical error is detected during the communication with the NFC Controller. The only functions available in error mode are getMode(), registerExceptionEventHandler() and reset().

 

The error modes are the following:

·         NOT_RESPONDING, and

·         LOADER_NOT_SUPPORTED.

2.1.5     Function Availability

Depending on the current mode, a function may or may not be executed. If a function is called while the stack is not in right mode, the method throws the exception IllegalStateException. The following table describes the functions available in each mode:

 

Methods	BOOT_PENDING	MAINTENANCE	NO FIRMWARE	FIRMWARE NOT SUPPORTED	NOT RESPONDING	LOADER NOT SUPPORTED	ACTIVE	SWITCH TO STANDBY	STANDBY	SWITCH TO ACTIVE
getMode() registerExceptionEventHandler()	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Reset()		Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
firmwareUpdate()	Yes	Yes	Yes	Yes
selfTest() productionTest()		Yes
switchStandbyMode()							Yes	Yes	Yes	Yes
Other Methods							Yes	Yes	Yes	Yes

2.2    RF Locks

The RF lock properties are used by the NFC Controller to lock or unlock the RF functionalities. The RF locks are generally connected to the user configuration screen to enable or disable the contactless interface. There are three different locks, one for the card listener modes, one for the card emulation modes and one for the peer to peer modes.

 

When the card listener lock, the card emulation lock or the peer to peer lock is set, the card listener API, the card emulation API or the peer to peer API respectively does not return any specific error but functions do not detect any remote card, any remote reader or any remote peer to peer device respectively. The effect of a volatile lock is immediate and will shut down any ongoing connection.

 

The locking of the RF functionalities is effective for the NFC Device, for the UICC and for the Secure Element.

 

There are two sets of locks: one is volatile and the other is persistent.

 

Volatile Locks

The NFC Device uses the volatile set of locks to control the access to the RF functionalities. Changing the volatile locks values has an immediate effect on the RF access. The value of the volatile set of locks is not kept between two reboots of the NFC Device or when the NFC Device switches of mode (Battery On, Battery Low or Battery Off).

 

Changing the volatile set of locks allows changing immediately the RF access without changing the RF access in other modes (Battery Low or Battery Off) and without modification of the lock value when the NFC Device is rebooted. The volatile locks are managed with the properties “nfcc.lock.volatile.card_emulation”, and “nfcc.lock.volatile.card_listener”. These values may be used to display an icon on the user interface to notify the user of the availability of the contactless functionalities.

 

Persistent Locks

The persistent set of locks is stored persistently in the NFC Device. The value of the persistent set of lock is kept between two reboots of the NFC Device and when the NFC Device switches of mode (Battery On, Battery Low or Battery Off). The NFC Device does not use the persistent set of locks to control the access to the RF functionalities. At boot time or when the NFC Device switches of mode, the persistent lock values are copied in the volatile locks. Changing the persistent locks values has no immediate effect on the RF access.

 

Changing the persistent set of locks allows changing the RF access the next time the NFC Device is booted or when the NFC Device is used in Battery Low or in Battery Off mode. The persistent locks are managed with the properties “nfcc.lock.persistent.card_emulation”, and “nfcc.lock.persistent.card_listener”.

 

RF Locks and Access Policies

The RF Locks supersede the Access Policies for the NFC Device, the UICC or the Secure Element. Before granting an access to the RF interface, the NFC Controller looks first to the corresponding policy then the corresponding RF lock is checked. The access is granted only if both the policy and the RF locks grant the access.

 

3      NFC Properties

The NFC properties are accessed from the class NfcManager. The property methods may throw a SecurityException if the calling is not allowed to access a given property. The “Access” column gives the access right required to access each property. The following properties are defined:.

 

 

Name	Type	Access	Description
open_nfc.version	string, read-only	nfc	The version of the library. The maximum length of the value is 16 characters.
open_nfc.implementation	string, read-only	nfc	Describes the implementation of the library. The maximum length of the string is 64 characters.
Card Listener
card_listen.iso_14443_A_cid	boolean, read-only	card listen	Indicates if the CID is supported for the protocol ISO 14443 A in card listener mode.
card_listen.iso_14443_A_input_size	integer, read-only	card listen	The maximum size in bytes for the input data buffer of the ISO 14443 A card listener. This value is sent by the NFC Controller in the RATS frame.
card_listen.iso_14443_A_max_rate	integer, read-only	card listen	The data rates supported by the NFC Controller for the ISO 14443 A card listener protocol(**). This value is set to zero if the protocol is not supported. The value is a bit field of 3 bits defining the DR value supported (See chapter 5.2.4 in ISO/IEC 14443-4). The string format of the property is the upper-case hexadecimal representation of this value, i.e. a zero ended string of 8 characters.
card_listen.iso_14443_A_nad	boolean, read-only	card listen	Indicates if the NAD is supported for the protocol ISO 14443 A in card listener mode.
card_listen.iso_14443_B_cid	boolean, read-only	card listen	Indicates if the CID is supported for the protocol ISO 14443 B in card listener mode.
card_listen.iso_14443_B_input_size	integer, read-only	card listen	The maximum size in bytes for the input data buffer of the ISO 14443 B card listener. This value is sent by the NFC Controller in the ATTRIB frame.
card_listen.iso_14443_B_max_rate	integer, read-only	card listen	The data rates supported by the NFC Controller for the ISO 14443 B card listener protocol (**). This value is set to zero if the protocol is not supported. The value is a bit field of 3 bits defining the DR value supported (See chapter 5.2.4 in ISO/IEC 14443-4).The string format of the property is the upper-case hexadecimal representation of this value, i.e. a zero ended string of 8 characters.
card_listen.iso_14443_B_nad	boolean, read-only	card listen	Indicates if the NAD is supported for the protocol ISO 14443 B in card listener mode.
Card Emulation
card_emul.iso_14443_A_max_rate	integer, read-only	card emulation	The data rates supported by the NFC Controller for the ISO 14443 A card emulation protocol(**). The value is a bit field of 3 bits defining the DR value supported (See chapter 5.2.4 in ISO/IEC 14443-4). This value is set to zero if the protocol is not supported. The string format of the property is the upper-case hexadecimal representation of this value, i.e. a zero ended string of 8 characters.
card_emul.iso_14443_B_max_rate	integer, read-only	card emulation	The data rates supported by the NFC Controller for the ISO 14443 B card emulation protocol(**). The value is a bit field of 3 bits defining the DR value supported (See chapter 5.2.4 in ISO/IEC 14443-4). This value is set to zero if the protocol is not supported. The string format of the property is the upper-case hexadecimal representation of this value, i.e. a zero ended string of 8 characters.
card_emul.iso_14443_A_cid	boolean, read-only	card emulation	Indicates if the CID is supported for the protocol ISO 14443 A in card emulation.
card_emul.iso_14443_A_nad	boolean, read-only	card emulation	Indicates if the NAD is supported for the protocol ISO 14443 A in card emulation.
card_emul.iso_14443_A_cid	boolean, read-only	card emulation	Indicates if the CID is supported for the protocol ISO 14443 B in card emulation.
card_emul.iso_14443_A_nad	boolean, read-only	card emulation	Indicates if the NAD is supported for the protocol ISO 14443 B in card emulation.
Peer To Peer
p2p.supported	boolean, read-only	peer to peer	Indicates if the Peer to Peer protocol is supported.
p2p.local_lto	integer, read-write	peer to peer	The Local Link Timeout expressed in ms.
p2p.local_miu	integer, read- write	peer to peer	Local Link Max Information Unit.
p2p.initiator	boolean, read- write	peer to peer	Indicates if the Initiator mode is used for the P2P connection.
p2p.active	boolean, read- write	peer to peer	Indicates if the Active Mode mode is used for the P2P connection.
p2p.typeA_target_protocol	boolean, read- write	peer to peer	Indicates if the Type A protocol is used for the P2P target connection.
NFC Controller
nfcc.nfc_hal_version	string, read-only	hardware	The version number of the NFC HAL specification used with the NFC stack. The string format of the property is the decimal representation of this value.
nfcc.battery_low_supported	boolean, read-only	hardware	Indicates if the "battery low" mode is supported by the NFC Controller.
nfcc.battery_off_supported	boolean, read-only	hardware	Indicates if the "battery off" mode is supported by the NFC Controller.
nfcc.standby_supported	boolean, read-only	hardware	Indicates if the "standby" mode is supported by the NFC Controller.
nfcc.standby_timeout	integer, read-only	hardware	The timeout in ms used to switch in standby mode. If no mode is active and there is no communication with the NFC Controller during this timeout, the NFC Controller switches to standby mode. This feature is disabled if the value is zero.
nfcc.harware_version	string, read-only	hardware	Describes the type and version of the NFC Controller hardware. The maximum length of the string is 32 characters.
nfcc.loader_version	string, read-only	hardware	Describes the version of the NFC Controller firmware loader. The maximum length of the string is 32 characters.
nfcc.firmware_version	string, read-only	hardware	Describes the version of the NFC Controller firmware, including the build number. The maximum length of the string is 32 characters.
nfcc.hardware_serial_number	string, read-only	hardware	Describes the serial number of the NFC Controller hardware This serial number is a 64 bit value. The format of the property is the upper-case hexadecimal representation of this value, i.e. a zero ended string of 16 characters.
nfcc.pulse_period	integer, read-write	hardware	The pulse period used for the detection sequence is configurable. The pulse period value is not persistent. The NFC Controller initializes this parameter to a default value when the NFC Controller is booted. If a specific value shall be used, the NFC Device firmware should set this value each time the device is booted. The pulse period may be one of the configuration parameters given by the user.   If the period value is high, the delay for the card detection may be high. A very low value causes a better responsiveness but increases the power consumption.   The pulse period value in milliseconds. Depending of the NFC controller capabilities, the range of the allowed values may be restricted to a subset of valid values. In this case, the value will be rounded to the nearest value supported by the NFC controller.
nfcc.lock.persistent.card_emulation	boolean, read-write	hardware	The persistent value of the global RF lock for card emulation. See “RF Locks”.
nfcc.lock.persistent.card_listener	boolean, read-write	hardware	The persistent value of the global RF lock for card listener. See “RF Locks”.
nfcc.lock.volatile.card_emulation	boolean, read-write	hardware	The volatile value of the global RF lock for card emulation. See “RF Locks”.
nfcc.lock.volatile.card_listener	boolean, read-write	hardware	The volatile value of the global RF lock for card listener. See “RF Locks”.
nfcc.activity.card_emulation	string, read-only	hardware	The current RF activity for the card emulation: ·         "active" One card protocol is active, a remote reader may be communicating with the card emulation or a Secure Element or the UICC are using the card emulation. ·         "detection" The NFC Controller is performing the detection sequence to detect the presence of a remote reader. ·         "inactive" The card emulation is not used. The security elements or the UICC are not performing a card emulation.
nfcc.activity.card_listener	string, read-only	hardware	The current RF activity for card listener: ·         "active" One reader protocol is active, one card is being read. ·         "detection" The NFC Controller is performing the detection sequence to detect a card. ·         "inactive" No card listener is registered. The Secure Elements or the UICC are not using the reader protocols. No reader protocol is active.
nfcc.activity.p2p	string, read-only	hardware	The current RF activity for peer to peer: ·         "active" The Peer to Peer protocol is active, a remote device is communicating with the local device. ·         "detection" The NFC Controller is performing the detection sequence to detect the presence of a remote Peer to Peer device. ·         "inactive" The Peer to Peer protocol is not used.

 

(**) The value is expressed as the maximum divisor supported in (ISO/IEC 14443-3) and (ISO/IEC 14443-4). Only the same divisor for both directions (reader to card and card to reader) is supported:

-          '00' = maximum divisor is 1

-          '01' = maximum divisor is 2

-          '02' = maximum divisor is 4

-          '03' = maximum divisor is 8