（邓凡平）深入理解android: NFC部分-----2

8.2.3 NFC P2P运行模式[12]

在前面介绍的R/W模式中，NFC Device只能单向和NFC Tag交互，即只能NFC
Device单方对NFC Tag发起操作，而NFC所基于的无线射频技术实际上可以支持NFC
Device之间互相传递数据。为了满足NFC Device之间双向交互的需求，NFC Forum定义
了P2P（Peer-to-Peer）运行模式。

图8-9展示了IEEE 802参考模型、OSI参考模型及NFC P2P的协议栈参考模型。由此
图可知，NFC P2P协议栈最高层为LLC（Logical Link Control，逻辑链路控制层）。这
一层使用的协议称为LLCP（LLC Protocol）。

在OSI参考模型中，LLC比较偏底层，其更多考虑的是物理地址寻址、链路管理，以及
数据传输方面的事情（参考3.3.1节关于OSI/RM的介绍）。所以，NFC也在LLC层之上添
加了一些对使用者更为方便和友好的协议。图8-10所示为NFC P2P协议栈的全貌。

·SNEP（Simple NDEF Exchange Protocol）紧接LLC层。该协议使得两个NFC
Device之间能直接交换NDEF消息。

·通过Protocol Bindings，NFC可支持其他高层次并且用途更加广泛的协议。根据参
考资料[3]所示的内容，NFC可支持IP和OBEX（Object Exchange，对象交换）协议，但
经过调查发现NFC Forum官网目前只有LLCP-OBEX-Binding协议的草案，而LLCP和IP
协议如何绑定还在研究当中。

·Other Protocols中目前比较常用的是CHP（Connection Handover Protocol）。

目前，Android 4.2中的NFC P2P模块支持SNEP和CHP。本章将重点分析SNEP，而
CHP则请读者学完本章后再自行研究。下面先介绍LLCP，然后再介绍SNEP。

1.LLCP介绍
NFC LLCP比较简单，对应的规范全长也只有40来页。关于LLCP，从以下两个方面来
介绍。

·LLCP的数据封包格式。对学习通信协议来说，掌握数据包格式非常重要。

·NFC LLCP对上层提供无链接（Connectionless）和面向链接（Connectionoriented）
的两种数据传输服务。其中，无链接的数据传输服务和UDP类似，上层的收发
双方无须事先建立逻辑链接关系即可收发数据。面向链接的数据传输服务和TCP类似，收发
双方发送数据前，需要在LLC层先建立逻辑链接关系（即类似TCP协议中的connect和
accept）。同时，LLC层还会处理数据包丢失、重传以及接收确认等方面的事情。目前
SNEP和CHP均使用了LLC提供的面向链接的数据传输服务，故我们将重点介绍它。

（1）LLCP数据包格式
NFC LLC层数据封包格式如图8-11所示

由图8-11可知，LLCP数据包前3字节为LLCP Header。LLCP Header之后就是
Payload，其长度由PTYPE来决定。

DSAP和SSAP分别代表Destination和Source Service Access Point（目标和源服
务接入点）。DSAP和SSAP的作用类似于TCP/UDP中的端口号。注意，使用NFC LLCP
时，DSAP和SSAP可唯一确定通信双方。读者可能有疑问，使用TCP/UDP时，除了指明端
口号外，还需要指明对端设备的IP地址，但NFC LLCP数据包中却没有这样的信息。另
外，和图3-24所示的LLC数据封装格式比起来，NFC LLCP数据包也没有MAC地址这样的
字段。也就是说，LLCP只需要通信双方所使用的端口号即可，而无需MAC或IP地址这样
的信息，这是因为NFC近距离作用的特点使得通信双方从进入有效距离内开始就已彼此确
定，故无需再通过MAC地址指明谁是接收设备，谁是发送设备。而当上层通过LLC发送数
据或者LLC向上层传递接收到的数据时则需要通过类似端口这样的SSAP和DSAP来进一步
确定发送模块和接收模块到底是谁。

PTYPE字段指明LLCP包的类型。NFC LLCP定义了多种不同类型的包，下文将结
合面向链接的数据传输服务来学习相关的LLCP包。

·Sequence字段指明LLCP包的序号，它可分为Send端和Receiver端。由于有一些类
型的LLCP包无需Sequence字段，所以Sequence字段长度有可能为0。例如，无链接的数
据包就不需要Sequence字段，而面向链接的数据包需要该字段来处理数据接收确认或丢失
重传等方面的事情。

由上述介绍可知，DSAP和SSAP类似TCP/UDP的端口号，决定了收发模块到底是谁。
表8-6所示为NFC中SAP取值情况。

以SNEP的使用为例：
·位于NFC Device A的服务端模块在SSAP为0x04的端口上进行监听。
·位于NFC Device B的客户端模块选择一个合适的SSAP，设置DSAP为0x04。然后
该客户端模块发送数据包，LLC负责将数据包打包传递给NFC Device B（假设这两个设备
都在彼此的有效距离内）。
·NFC Device A的LLC层接收到数据包后发现DSAP为0x04，而其上刚好有一个服务
模块工作在0x04端口，故LLC层将把数据包传递给这个在0x04端口上监听的服务模块。

（2）面向链接数据传输服务

假设Device A和Device B打开了NFC功能。当二者进入有效距离后，它们的LLC模块
将进入Link Activation（链路激活）阶段，在此阶段中，A和B的交互过程如图8-12所
示。

·进入Link Activation时，Device A和Device B将分别扮演Initiator和Target角
色，参考资料[13]可用于确定谁来扮演Initiator或Target。

·Initiator发送PAX数据包给Target。PAX全称为Parameter Exchange，它用于在
两个设备间交换彼此的LLC层配置信息（如协议版本等，详情见下文）。

·Target收到Initiator的PAX包后需要相应处理，例如判断协议版本是否匹配等。
Target处理完后，它需要发送自己的LLC层配置信息给Initiator。

·Initiator检查Target的LLC层配置参数，如果一切正常，双方Logical Link成功建
立，随后可进入正常工作阶段。

根据上述内容，双方需要通过PAX交换LLC层的配置信息。PAX属于LLCP数据包的一
种，其格式如图8-13所示。

LLC层的配置信息保存在图8-13中的参数列表中，正常情况下PAX携带的参数信息及
作用如表8-7所示。（注意，并非所有参数都会包含在图8-13的参数列表中。）

当Device A和Device B进入有效距离后，Link Activation将被触发，而Device A
和B分开后，Link Deactivation将被触发。从使用角度来看，Link
Activation/Deactivation可能会频繁被触发。

·WKS用于告知本机设备哪些Well-Known服务端口上有模块在监听。这表明在Link
Activation被触发前，使用者就必须在感兴趣的WKS端口上进行监听。

Link被激活后，Device A和Device B将先建立面向链接的关系，然后再开展数据交
互，这一流程如图8-14所示。

假设Device A扮演Client角色，Device B扮演Server角色。Client先通过CONNECT
包向Server发起链接请求。CONNECT包对应的格式如图8-15所示。

CONNECT包需要携带一些参数信息，常见的参数如表8-8所示。

当服务器端成功处理CONNECT包后，它将回复CC（Connection Complete）包给
客户端。如此，Client和Server就建立了链接关系。CC包内容非常简单，请读者自行研究
参考资料[12]。此后，Client和Server就可通过Information（规范中简称为I）包和
RR（Receive Ready）包来传输数据，其中：

·I包用于承载具体的数据
·RR包用来确认接收方确实收到了数据。

总体而言，LLCP比较简单，不过直接使用LLCP还是稍显复杂。所以，在LLCP基础
上，NFC Forum定义了SNEP协议用于在两个NFC Device之间传输NDEF消息。

2.SNEP介绍

SNEP（Simple NDEF Exchange Protocol）支持在两个NFC Device之间交换
NDEF消息。SNEP是一种基于面向链接的数据传输协议，作为Well-Known Service的一
种，其服务端口号为0x04，服务名为"urn：nfc：sn：snep"。

SNEP属于Request/Response方式，其工作过程如图8-16所示。

SNEP的工作流程非常简单，主要包括两个步骤。
1）SNEP客户端发送SENP Request消息给服务端进行处理。
2）SNEP服务端回复SNEP Response消息给客户端以告知处理结果。

SNEP Request消息和Response消息的格式如图8-17所示。

图8-17中，SNEP Request/Response消息开头都是1字节的Version字段，Version字
段之后分别是Request字段和Response字段。Request字段表示请求类型，Response字段
表示处理结果。

表8-9所示为SNEP当前支持的Request类型。

以SNEP Put请求消息为例，其对应的格式如图8-18所示。

至此，我们对NFC LLCP进行了相关介绍。这部分难度不大，读者需要重点掌握的部分
包括LLCP协议本身，尤其是其数据封包格式、各种参数信息、常见SAP等。在LLCP基础
上，读者可学习SNEP这种比较常用的协议。另外，读者还可在本节基础上自行学习
Connection Handover，它是另外一种基于LLCP面向链接数据传输服务的协议。

8.2.4 NFC CE运行模式[15][16]

NFC CE运行模式使得携带NFC芯片的设备能充当智能卡（例如信用卡）使用。该运行
模式所支持的应用场景极具吸引力，例如用支持该功能的Android智能手机来完成购票、支
付，甚至充当门禁卡，汽车钥匙、公交卡等。

由图8-19可知，SE和NFC芯片（主要是指NFC Controller，简称NFCC）通过
SWP（Single Wire Protocol）或者S2C（SignalIn/SignalOut Connection
Interface，也叫NFC Wired Interface，简称NFC-WI）来交互。一般来说，SE上面运行
了一些特殊的应用程序，NFC负责将数据通过SWP或S2C传递给SE中的应用来处理。

NFCC（NFC controller）通过HCI（host controller interface）协议和NFC Mobile交互，而SE(secure element ) 也可通过 ISO 7816协议 和 NFC Mobile交互。

在CE模式中，NFC Mobile被NFC Reader识别成一个智能卡。NFC Reader通过相关
规范发送数据或控制命令给NFC Mobile中的NFCC。

当NFCC收到数据或控制命令后，将交给相关的应用程序来处理。由于CE相关的应用
场景针对支付、门禁等这类对安全性要求非常高的情况，以Android手机NFC支付为例，一
个完整的支付应用程序包括一个为用户提供操作界面的APK以及一些运行在安全性有绝对保
障的SE中的应用程序。

总之，SE在CE模式中扮演了非常重要的角色，目前SE和NFC的组合有三种方式，如
图8-20所示。这三种组合方式从上到下分别如下。

·SE为一个嵌入式安全芯片，该芯片在手机出厂前就已经安装在其内部，而且无法被
替换。该芯片上运行着一个小系统能够处理支付或安全方面的工作。目前，这种形式的SE
还没有标准规范，可参考的模型有NXP公司的pn65芯片模块示意（如图8-21[17]所示）。

·SE为一个支付型SD卡，这种卡实际上是在SD卡上嵌入了安全模块，相关应用可在这
种卡上运行。该种组合方式所对应的方案也称为NFC-SD方案，这方面的国际标准有ISO
7816。中国的银联曾经主推过NFC-SD卡支付解决方案。

·SE为UICC，也就是常说的手机SIM卡，这种组合方式对应的方案也称为NFC-SIM
方案，目前由运营商主推。前面提到的北京市利用NFC手机充当一卡通所使用的方案就是
NFC-SIM，它需要使用者先到移动运营商那换一个特殊的SIM卡。

图8-21中，NXP公司pn65 NFC芯片自身就包含一个Secure Element，即图中的
SmartMX模块，该模块中运行着一个名为Java Card OS的操作系统。在Java Card OS
上，用户可以安装和运行一些应用程序（称为Applets）。除了SmartMX内置的SE
外，pn65也支持使用外部的SE，即图8-21中的UICC。

提示 从参考资料[18]和[19]来看，目前国际上大多使用NFC-SIM方案，而中国的运
营商和银联也将联合推广它，其对应的商品名叫“闪付”

SE和NFC控制器连接所使用的S2C和SWP协议中，NFC-SIM方案将采用SWP，其对
应的规范是ETSI TS 102613。NFC和UICC使用SWP的连接如图8-22所示。

CLF（NFC Contactless Front-End缩写）和UICC通过三条线相连。Gnd接地，Vcc
提供电源。SWIO为CLF和UICC的数据连接线，数据传输率在212kbps～1.6Mbps之间，
每次传输的数据包小于30字节。

注意，图中UICC的电源由CLF来提供，而非直接由手机电源来提供。这种设计方案使
得手机在电池耗尽的情况下，也可通过外部电磁感应（由NFC Reader或其他NFC设备）来
给CLF和UICC供电，从而确保支付请求不受手机本身的电源影响。

8.2.5 NCI原理[20]

NCI（NFC Controller Interface）是NFC Forum于2012年制定的一个规范，其主要
关注点为DH（Device Host，主机设备）如何控制并与NFCC（NFC Controller）交互。
图8-23所示为NFCC、NCI和DH三者之间的关系。

在图8-23中，NFCC和DH通过物理连线相连，物理连线对应为Transport Layer（传
输层）。目前，NFCC和DH在传输层这一块支持SPI、I2C、UART和USB等。

在图右边的DH中，所有和NFC相关的应用程序都可被视为DH-NFCEE（EE是
Execution Environment的缩写）。图左边有一个NFCEE模块，该模块也可运行着一些和
NFC相关的程序或系统（以图8-21为例，它的SmartMX Secure Element就是此处所说的
EE）。NFCEE模块可直接集成在NFCC中，也可作为单独的芯片模块通过物理连线与
NFCC相连。

NCI负责处理DH和NFCC之间的交互。NCI包含多个模块，详情见下文。图8-24所示
为NCI的模块结构。

·NCI Core模块负责DH和NFCC之间交互的基本功能，包括控制消息（Control
Message）和数据消息（Data Message）的传递、DH初始化、重置和配置NFCC等。

·Transport Mapping用于在NFC Core和传输层之间转换数据格式，例如将NCI
Core使用的控制消息和数据消息转换成对应传输层使用的数据格式。

·NCI Module包含多个功能模块，例如RF Discovery模块用于搜索周围的其他NFC
Device、RF Interface用于和对端的NFC Device交互。

使用NCI的NFC Device中，DH和NCI的工作原理如图8-25所示

·DH通过NCI规范定义的Control Message来控制NFCC。目前规范定义的Control
Message包括Commands（请求命令，包括初始化NFCC、重置NFCC、设置NFCC配置参
数等）、Responses（回复）和Notifications（通知）。这些Message都封装在NCI Control Packages中。其中，Commands只能由DH发送给NFCC。

DH通过RF Interface和对端NFC设备（图中的Remote NFC Endpoint）交互，也
可通过NFCEE Interface和本设备的NFCEE交互。交互数据包括Control Message和
Data Message。

NCI规范一共有140多页，是NFC Forum众多规范中比较复杂的一个。根据笔者的理
解，NCI的一个很重要的作用就是统一Android中NFC HAL层的实现，即通过一套标准的
方法来实现对NFCC的控制以及数据交互。不过，由于NCI规范推出的时间比较晚（该协议
最终版的时间为2012年11月6日），所以占据最大市场份额的NXP公司在其Android平台的
NFC HAL层中还没有使用NCI。
提示8.4节将专门讨论Android平台中NFC HAL层的实现状况。从Android 4.2的代
码来看，NXP公司使用了自己的一套NFC HAL层实现方式，而博通公司的NFC HAL层的
实现参考了NCI规范。但实际上这两家公司NFC HAL层的代码处处透露着它们与特定芯片
的紧密关系，这使不了解芯片细节的读者很难真正看懂NFC HAL层的代码。随着NFC的重
要性和普及程度日益加大，开发者已经在Linux Kernel 3.8[21]中增加了一个名为NFC的子
系统，它使得以后的NFC HAL层只需通过netlink消息就可和位于Kernel空间的NFC驱动
交互。因目前NFC HAL层这些被不同芯片所“绑架”的代码就可从用户空间移除，而那些
和芯片相关的代码就可通过NFC驱动的形式运行在Kernel之内。