NFC SWP Physical Layer – How it works

As I’m currently building an NFC-SWP reader device I have to tackle quite some challenges simply because there there is no single chip solution out there that you can simply connect to USB and a SIM card. Most NFC Controllers can of course talk SWP, but they will not work as a simple and transparent bridge. Therefore I’ll design my own solution.

To do so, it is crucial to understand how the protocol works on the lowest level.

The SWP physical layer is quite a unique thing. It allows the NFC SIM-card and the NFC controller to exchange data at a rate of 1.7 megabit/second full duplex over just a single wire. And they not only transmit bidirectional data, they transmit a clock signal for synchronization as well.


How do they pulled that off?

First have a look at the S1 signal. This is the signal that transmits the clock and the data from the NFC controller towards the NFC SIM. Each bit gets transmitted using a full cycle, and the pulse-width of the signal defines if a zero or one bit gets transmitted.

Here is a picture of the S1 signal transmitting a stream of zeroes:


Each bit starts with the raising edge. The voltage high duration of each cycle is 25% of the cycle length. This is interpreted as a zero-bit. Likewise, if the voltage high duration is 75% of the cycle length a one-bit gets transmitted. Again a picture of one-bits to illustrate this:


Extracting the clock and data from this signal is easy. Each clock-cycle starts with the raising edge of the signal. For the clock extraction the falling edge can simply be ignored.

Getting data-bits is easy as well. All you have to do to extract the bits from this signal is to take a look at the voltage at the middle of the cycle. In the images I’ve aligned the numbers denoting the bit-value to this place. I use this method when I debug SWP signals taken with a logic-analyzer. In a hardware-design it is probably not feasible because you’ll never know where exactly the middle of the cycle is until the cycle has ended. I don’t know for sure, but I bet they measure the durations of the high and low periods and extract the bit from that.

For completes sake, here is a picture of a signal with some one and zeros:


This is how one side of the communication works. I’ve simplified a bit and left out things like fall- and rise-times, voltage-levels, tolerances and so on. Also it is worth noting that the clock-rate is not fixed. The NFC-controller is allowed to change the clock rate at will as long as you stay within the allowed range.

How does the SIM transmits data?

Now we have seen how the NFC-controller talks to the SIM-card and how the synchronization works. But the SIM card probably wants to transmit data as well. How does this work?

The NFC-SIM can not transmit data by applying a voltage to the SWP link because the link is always driven by the NFC-Controller. However, the NFC-SIM can draw current from the SWP-link without interfering with the NFC-controller.

Take a look at one of the S1 signal images again. In each clock cycle there will always be voltage high period. During these high periods the SIM can load the SWP link and draw some current. During the voltage low periods it can’t because to draw a current a voltage must be present.

This leads to the fact that the signal from the SIM (S2) will always be modulated by the signal S1 generated by the NFC-controller.

To make things a bit more easy to understand here is a picture of signals S1 and S2. The voltage domain is shown in blue while the current domain is shown in red.

First S1 transmitting some one and zero bits while S2 (the SIM) transmitting a stream of zeros:

s2-zeroesNot much going on on the S2 signal. That’s how zero-bits look like.


And now S1 transmitting the same data again while S2 is transmitting a stream of ones:s2-onesOn the S2 signal, one bits become a copy of the S1 bits.


And finally both signals transmitting a bunch of bits:s2-bitsYou probably already guessed it. One bits in S2 become copies of S1, zero bits are just a flat line.

The NFC-controller can read the S2 bit-stream by measuring the current consumption of the SWP link just before it generates the falling edge.


Timing, Timing and Levels:

In the general case communication over SWP must be done at a frequency between 200 kilobit/second up to 1 megabit/s. A SIM card may also announce the capability to go faster (up to 1.69 megabit/s) or slower (down to 100 kilobit/s).

And they mean it! While troubleshooting I’ve tried to run SWP at a slower clock-rate. It didn’t worked at all. There is some wiggle room, but not much.

The S1 (voltage) is in practice a 1.8V digital signal regardless of the SIM-card supply voltage. The levels that define the high and low regions change somewhat with the different supply voltage classes, but if you provide a clean digital 1.8V signal you won’t run into issues.

In practice it seems that NFC SIM-cards are very forgiving about the voltage applied to the SWP-pin as long as you don’t exceed the supply voltage.

Note that these are ballpark figures, within 10% or so of the real thing. You’ll find the exact values in the specification ETSI TS 102 613 (you’ll find it via Google), chapter 7.1.3.

The S2 (current) signaling definition is much simpler. Independent of the class, a logic high is defined by drawing 600µA or more. The SIM should not draw more than 1mA though.

Why did they came up with such a oddball protocol?

To be honest, I don’t know exactly.

A couple of years ago, while I was working on a NFC middle-ware, I had good contacts with a NFC chip manufacturer. While on site, during lunch I asked exactly this question. The answer was more pragmatic than I expected:

During the stone ages of smart-cards the contact interface (aka the gold pads on your SIM that makes contact with the phone) has been defined. The same interface has been re-used by SIM-cards because SIMs *are* just small smart-cards.

Back then writing to smart-cards required a dedicated programming voltage. Nowadays no one needs the programming voltage anymore, so the pin was always unconnected. Since they wanted NFC functionality in their SIM’s they re purposed this pin and use it for SWP now.

If they had two free pins we would probably have something much simpler. Doing stuff in the current domain has a price: It consumes power. Now SIM cards usually end up in mobile phones. Going low power and having having a long standby time is a thing so I’ve heard. Fortunately the SIM is not communicating over SWP most of the time.

There is one thing that I don’t understand at all though: Going current domain and doing three things over a single wire: All fine. But if you read the specification of SWP you’ll find a lot of details where some crazy timing constraints are required. The requirement bit-rates up to 1 megabit per second for example, let alone 1.7 megabit/second in the high-speed case. I can’t come up with any use-case that even remotely needs such a high bandwidth.

This entry was posted in Uncategorized. Bookmark the permalink.

3 Responses to NFC SWP Physical Layer – How it works

  1. Pingback: Snooping on SIM Cards | Life Hacking

  2. GNUtoo says:

    Interesting, did you also look into the higher levels of the protocol?

    Maybe the osmocom project ( would be interested in your work.

    The project description from its page is:
    “The Osmocom project is a family of projects regarding Open source mobile communications. It includes software and tools for a variety of mobile communication standards, including GSM, DECT, TETRA and others”

    They have several project related to SIM cards, including a SIM card
    traffic sniffer ( and a program
    to easily dump the list of the permission the modem gives to the SIM (

    I posted here since I had some trouble posting on hackaday without javascript.


  3. Nils says:

    Hi Denis,

    I’ll definitely try out osmocom and a bunch of other SIM-card utilities as soon as I have PCSC interface working for my board. The ISO7816 interface has lower priority than SWP, but nonetheless I’m currently working on it. Simple T=0 interface transfers already work fine. I ‘just’ have to write a bunch of boring glue code before I can do any experiments with third party packages.

Leave a Reply

Your email address will not be published. Required fields are marked *