I am trying to understand the technology behind NFC. I have a basic understanding of the protocol, the physics behind the technology and the immense power it brings to the wide range of applications that could be there.
Now I am trying to understand the the different modes in which an NFC enabled device (may be a smart phone) can operate.
I understand that the device may take up the role of a reader/writer or a card (card emulator). However, what I do not understand is what is the need for having the initiator and the target modes of operation ?
My understanding is :-
In a passive communication mode between 2 NFC enabled devices, one device takes up the active role (thus acting as the reader/writer) and the other device takes up the passive role (and thus acting as the card emulator).
And we know that the active device (in a passive mode of communication between 2 NFC devices) is the one that creates an RF field and constantly polls to find out nearby NFC enabled devices that are ready to act as a card emulator.
So is it not just obvious that the the device acting as an active device (taking up the reader/writer role) is the one that would be the initiator of the communication ? Why is a separate initiator and target ** mode required when it can be inferred easily from the **reader/writer or card role ?
You got it right:
The distinction between target and initiator is only of significance in the peer-to-peer communication mode (aka Android Beam). In this mode one device powers the field and acts like a card reader/writer. This is the initiator. The other device takes over the target role and technically acts like a card emulation.
The difference between target and initiator is significant in the LLCP protocol which implements the peer-to-peer functionality. Reason for that is, that the target cannot send data on it's own. It first has to be asked from the initiator if it wants to send something.
The LLCP protocol (among other things) abstracts this difference and lets the initiator poll the target at regular intervals. If you write communication code on top of this protocol (or anywhere higher in the protocol stack) you don't have to worry about the target/initiator mode at all anymore.
For completes sake here is also a operation mode within peer-to-peer where the two devices are powering the field (called active mode), but this is rarely used because support for it is not that great.
To answer your question:
Why is a separate initiator and target ** mode required when it can be
inferred easily from the **reader/writer or card role
The naming is there to avoid confusion. Take peer-to-peer initiator mode for example: Also it is technically 95% identical to reader/writer mode there are still some minor differences. You don't want your peer-to-peer initiator to connect to a real card but only to peer-to-peer targets for example.
Naming this mode initiator instead of reader/writer avoids confusion.
Related
I'm developing a VoIP application that has to perform well on mobile networks. It is tolerant to packet loss, but here's the bad part: I found out that on mobile networks, on all standards from GSM to LTE, there's that RLC protocol used between the device and the base station. RLC can operate in two modes: acknowledged and unacknowledged. Acknowledged mode, which I observed being used during my experiments, means that if there are any bit errors during packet transmission, it will be retransmitted until there are none, thus holding up the send queue the whole time it gets retransmitted. In the unacknowledged mode, a packet with bit errors is just dropped, and that's what I need.
So... Is there any way I can control the RLC mode used for my application's packets, or is said mode configured by the network? I already tried the "service type" field in the IP header, but it didn't seem to do the trick.
I've put the "android" tag here, but, ideally, I'm interested in a solution that works across all major mobile operating systems.
There is no way to do this from the device for two reasons:
1 - This is a network configured attribute to enforce QoS wanted by operator. All data services will run on RLC AM sharing the same channel. A channel with a dedicated QoS (like higher priority and RLC UM) would run typically for operator's phone service (VoLTE).
2 - Even if device could pick it's preferred mode, that's a low level configuration used by the modem / chipset. This, this is not provided to Android developers (RLC is under PDCP, which is under IP layer).
But still, I don't think your VoIP performance is being affected just because of this property. Latency depends on other factors as well, such as load in the network and radio conditions. The higher the number of users in an LTE network the higher the latency. The worst the cell coverage, the worst the latency.
Give it a try on speedtest.net to check latency. It should be ok until 30ms or so.
Cheers.
I've found that Android devices support three NFC modes: reader/writer, P2P, and card emulation.
Is it possible for my app to check which mode is currently enabled?
No, your app can't really check what mode is currently enabled. The point is that, by default, an Android device will periodically check for all three modes (actually it's a bit more complicated than that: those three modes are themselves split into several parts, each polling for a certain technology). So, while the screen is on, you can expect the Android device to cyclically switch between listening for other readers and polling for different types of tag technologies and peer-to-peer mode devices. This is the case regardless of whether you registered to send a message over peer-to-peer mode, an app is registered for HCE, or your app registered for NFC discovery intents. Even if you disable Android Beam in settings, the device will remain to poll for peer-to-peer mode.
Only if you explicitly disable card emulation and P2P using the reader mode API (available on Android 4.4+), your app can control that only reader/writer mode is active (and it can even control which tag technologies should be polled for).
So your app can know what modes it enabled itself and can do some guessing, e.g.
if the screen is on and reader/writer mode was not explicitly forced using the reader mode API, all three modes are likely to be active.
if the screen is off, only card emulation mode may be active (though this is device dependent and HCE is usually not available).
I have some questions about the communication between a NFC reader and an Android phone.
The first subject is the Android / NFC reader modus:
What is the best way to pass a unique identifier from the NFC reader (ACR122U) to an Android device? ACR122U in peer-to-peer, card emulation, or reader/writer mode? Wich modus are possible? And what is the best mode if you want bi-directional communication?
The second subject is about the listener on the android device:
How can a Android reader trigger an Android application? When you tap your phone on the NFC reader, do you need to have the Android application in the front or do you need to write a NFC listener or something while your application is running on the background?
Many thanks.
What is the best way to pass a unique identifier from the NFC reader (ACR122U) to an Android device?
That depends on what you want to achieve.
Using the ACR122U in reader/writer mode will basically limit you to using Android 4.4 and later (as Android HCE -- for putting the phone into host-based card emulation mode -- is only supported from 4.4 onwards).
Peer-to-peer mode will work but will effectively limit you to sending one data packet (or one message) into a single direction.
Using the ACR122U in card emulation mode will permit you to perform true bidirectional communication (i.e. to send multiple data packets into both direction).
See this answer for a list of further literature.
Which modes are possible?
All three modes are possible but give you different degrees of freedom.
And what is the best mode if you want bi-directional communication?
See above, using the ACR122U in card emulation mode and the phone in reader/writer mode will permit bi-directional communication on all Android versions. The phone has the role of the interrogator (in a command-response protocol) in this case.
If you only want/need to support Android 4.4 and later, you could just as well use the phone in HCE (host-based card emulation) mode and the ACR122U in reader/writer mode.
When you tap your phone on the NFC reader, do you need to have the Android application in the front or do you need to write a NFC listener or something while your application is running on the background?
If you are using Android HCE (phone as emulated card): In this case, the communication is handled by a background service. No user interface is needed on the device. If you want to start a user interface upon scanning the ACR122U with a phone, I suggest that you stick with using the Android in reader/writer or peer-to-peer mode (though you could start a UI through the HCE service too).
If you are using the Android in reader/writer mode: You need an app running in the foreground to communicate with an NFC tag/smartcard/emulated card. However, the
app can be started automatically upon detection of the tag. You would
use an intent filter that matches either the tag's technology or
(better yet) matches an NDEF record that is stored on the tag. See
this for further details.
I have the bluetooth mac-id of the target device. The bluetooth however is in hidden/not visible mode.
Both phones are android. (Non-root).
I did my research and I * know * that I can CONNECT to a device (in most cases) if I know the mac-id, however I want to just scan for proximity and NOT connect i.e. if the target device is in bluetooth range and I know its mac-id, can I * just * know if its in proximity (or in loose terms, scan for it?)
The short answer is no, you cannot discover undiscoverable Bluetooth devices.
Having a device in undiscoverable mode is a security measure implemented by manufacturers to prevent abuses such as device tracking. This make a standard bluetooth adapter (such as yours) completely unable to state whether an invisible/undiscoverable device is close or not.
However, it turns out this kind of security is not optimum and has been broken recently. You can find here Michael Ossmann's work on Ubertooth, a small Bluetooth adapter able to detect undiscoverable devices. You can find here a great presentation of what this is, build this dongle using open source plans and even buy his dongle.
EDIT :
It is possible to know whether a bluetooth device is around, even if he is in an undiscoverable mode, by knowing his full MAC address in the first place.
The technique is to try a PAGE request, sending all the 6 bytes that are composing the seeked Bluetooth host MAC identifier. A PAGE request allows one to connect with a Bluetooth slave when knowing his BT ADDR. Devices that are in undiscoverable mode does not respond to inquiry scan (device discovery intent), but they do respond to page scan which is used by a device wanting to connect to an another previously known device.
You might be able to do what you intend by using Bluesniff, a security proof of concept allowing you to discover hidden devices. It might support page scanning.
Note that this is to be taken as an educational resource, and I do not encourage this kind of practice in a commercial application.
I need to find out how in Android Beam the P2P mode is managed.
I found some general information about P2P:
There is an active P2P mode (not recommended by NFC Forum) and a passive one (recommended by NFC Forum) where the passive device works like a smartcard (card emulation mode).
I also know that an NFC reader device does usually the following steps:
Field on
Check for a card or a P2P passive device
If found then communicate with the device, if not then field off
Field off
Check for external field for around 500ms-1s at least
If external field detected act as a card or P2P passive target. Receive commands and perform the transaction as a target
Wait until no more field detected
Goto 1
Now my question is, in Android Beam what happens when the 2 phones are put together?
I think they both create the field for scanning, and they both recognize them, by showing then the Android Beam interface (the smaller windows with the information for sending)
Then, the user types on the screen, and gets the iniator, while the other one goes to the passive receiver.
They pair by P2P passive and change the information over LLCP
The callback is sent to the iniator and the end.
I don't know if this is correct, does someone have information herefore?
What happens in Android Beam when the 2 smartphones/devices are put together, in which mode are they, and who gets when active/passive and which mode is used (P2P active or passive)?
In LLCP there is no master/slave so both are master and slave what exactly means this?
Thanks for your help!
As far as I remember it is as follows:
The initiator initiates the transmission, i.e., it is the one that begins the communication - comparable with first come first serve - independent of the direction of the data flow.
In a second step, the initiator dictates the kind of transmission mode, i.e., passive or active in peer-to-peer mode, or RFID mode (reader/writer mode). The chosen mode depends what kind of modes the initiator and/or the target supports. The passive mode is used when the initiator has enough power to drive both devices (itself and target). Whereas the active mode can be used if power should be shared among initiator and target device.
When two NFC devices are put together, the device which wants to communicate first, will be the initiator. Therefore, passive devices like tags are always targets. However, there is no peer-to-peer mode between NFC devices and RFID tags.
LLCP is just a top level protocol to transmit data in either way. Therefore, the initiator asks the target to transmit or receive data. The good thing about the NFC peer-to-peer mode is, that the NFC devices can swap its roles after each successful communication.