Enabling NS-2 With SSM Environments

Simulation of NFCIP-1 protocol over Ns-2 Abstract Nowadays, the increasing need to digitally handle information everywhere everytime helps the spread of some new technologies and services. One of these technologies is Near Field Communication (NFC) which is a short range wireless connectivity technology. NFC technology invades the world by many trails in different countries as it gives out many ways of communication and transaction in a very comfortable, user-friendly way. Many electronic services will be accessible to different kinds of users. So there is an essential need for simulation module that can play an important role in the study of the underlying protocols to assist evaluation of different solutions of the system and testing many changes without having to carry them out. The main protocol of the NFC technology is the Near Field Communication Interface and Protocol (NFCIP-1). This paper presents an extension simulation module for the NFCIP-1 over the network simulator (NS-2). Simulation results are compared to measurement results of a real NFC system. Results showed the efficiency of the implemented module. The simulated results differs from measured values by an approximate value of 12%. Keywords: Near Field Communication, NFCIP-1 and NS-2, modeling and simulation, mobile business.

1. INTRODUCTION Jointly developed by Philips and Sony, NFC is a short-range high frequency wireless technology standard operating at 13.56 MHz [1]. Most recent prediction published by ABI Research announced that about 419 million NFC chipset will be shipped by 2012 [2]. NFC is designed for intuitive, simple communication between initiator and target devices. It is a development of an old known technology 1

which is Radio Frequency Identification (RFID). So NFC is based on the same concept of RFID in establishing connections. Both depend on the concept of Proximity [3]. NFC operates in a range of approximately 10 centimeters (around 4 inches). NFC operating modes make it a smarter technology that allows easy, interactive and user-friendly services. NFC devices distinguish between two modes: active mode and passive mode. Devices operating in active mode generate its own Radio Frequency field (RF) to carry the data and need a power supply. On the other side, passive devices don‟t have a power supply and use the existing RF field provided by the initiator [4]. NFC technology follows universally implemented standards proposed by the international organization for standardization (ISO), the international electro-technical commission (IEC), and European Computer Manufactures Association (ECMA). The main approved standards are: The primary one is the NFCIP-1 (ISO 18092, ECMA 340) protocol which is describing the main peer to peer connection characteristics for different device modes. The second is the NFCIP-2 (ECMA 352, ISO 21481). The device following this standard works with three different standardized operating functions which are PCD (Proximity Coupling Device) as specified in ISO/IEC 14443., VCD (Vicinity Coupling Device) as specified in ISO/IEC15693, and NFC communication as specified in ECMA-340. [4] [5]. The paper will propose a simulation for NFCIP-1 protocol in active mode at 424 kbits/s data rate and a 251 byte maximum packet size. Since its inception, NS2 has continuously gained great interest from industry, academia, and government. And become one of the most popular simulators in the field of communication networking. Over the years, it has received a wide attention. Now, it contains modules for aplenty of network components, allowing the creation of many network topologies and analyze different kind of protocols. This paper will propose simulation results based on ns-2 extension module for the NFC device. The paper is organized as follows: Section 2 lists some of the previous trails in evaluating NFC technology. Section 3 shows a brief of the NFCIP-1 transmission protocol operation. Section 4 2

conation overview about the used simulator NS-2, illustration for the NFC mobile node architecture and details of the implementation. Results of the simulation and conclusion will be shown in section 5. Finally, we suggest future research that will be adopted as extension to this work.

2. BACKGROUND With the advent of this technology, research has been made so as to employ it in the market. In [6], comparison has been made between RFID and NFC. There is always a doubt that they are a same. But the comparison shows that NFC provides explicit interaction and more initiative for users. So it is most preferred in applications such as ticketing and mobile payment as shown in [7] and [8]. In [9], Y. Anokwa and T. Pering, demonstrates the architecture of NFC application that allow easy interaction from user. Applications need to define objects within the environment of the user. Also it has a predefined actions that user can apply to any chosen object. Research also goes to test one of the main functionalities of NFC. It can be used in pairing with other higher technologies such as Bluetooth and WiFi. Because of the short set up time as defined in [10], it can be used to exchange required parameters for initiating connection with any other wireless technologies. In [11], S. Gr¨unberger and J. Langer tested IP link that was established over NFC connection. It tries to measure the maximum data rate can be accomplished from this connection at different cases such as using different MTU values by the IP connection. Previous work usually made by commercial NFC device vendors that perhaps not fully commensurate with the standards. So there is a need for simulation of the underlying protocols to enable detailed studies for different scenarios of the system.

3. NFCIP-1 OPERATION A NFCIP-1 connection starts when the application of the initiator wants to send data. All packets used during the connection will be sent in pairs of request and response. At the beginning, the initiator 3

will send Attribute Request (ATR_REQ) packet to the target with defined address that will be generated at the beginning of the connection and fixed during the whole connection. Initiator also has to announce the acceptable send bit rate, receive bit rate, maximum data length. Figure 1 shows the fields of the ATR_REQ frame. Command Code

ID of NFC Device

Send Bit Rate

Received Bit Rate

Maximum Transport Data

Figure 1 – ATR_REQ Frame

Initiator and target has to use the same send and receive rate. Standard doesn‟t specify flow control mechanism in case of bottleneck at any side of the connection. Target will reply by sending Attribute Response (ATR_RES) packet which includes the target address, the send bit rate, receive bit rate and the maximum data length. Moreover, the target has to calculate the time it needs to process data. This value is the timeout timer after which the initiator detects connection timeout. Figure 2 shows the fields of the ATR_RES frame.

Command Code

ID of NFC Device

Send Bit Rate

Receive Bit Rate

Timeout

Maximum Transport Data

Figure 2 - ATR_RES Frame

After this stage, the initiator starts to send its data with the agreed parameters using Data Exchange Protocol Request (DEP_REQ) and receives Data Exchange Protocol Response (DEP_RES) that acknowledge received packets. Figure 3 show the main fields of Data Exchange Protocol frame.

Command Code

Control Information

Payload

Figure 3 - Data Exchange Protocol Frame

4

Control Information defines the frame type that can be user information, ACK or NACK. Information frame contain More Information (MI) bit that show the need for transmitting more data. Using the 2-bit Packet Number Information (PNI) Field, current standard specify only 4 sequenced packets every established connection. If initiator still has more information, it has to begin new connection. Target response any received packet with ACK or NACK using its PNI. Finally, when initiator application finish its data, is send Release Request (RLS_REQ) to free its resources and receive Release Response (RLS_RES) from the target [12]. Initiator

Target ATR_REQ

ATR_RES

DEP_REQ

DEP_RES

RLS_REQ

RLS_RES

Figure 4- NFCIP-1 Connection

4. SIMULATED NFC MODEL ARCHITECTURE The Network Simulator (ns) was started in 1989 by UC Berkeley. It is an open-source discreteevent network simulator. It is popularly used by researcher for its flexible design which permits extension to new protocols. It also supports tracing and analysis of the simulated system behavior. NS currently used version is NS-2 [13]. It was programmed based on two object oriented languages, C++ and OTcl. OTcl code can be considered as the interface to the user of the simulated system. It allow

5

configuration of the system. C++ code is the core of the NS-2 that executes the actual simulation of protocols in the simulated system [14]. NS-2 supports simulation of wireless systems by using the node configuration API. This API enables creating wireless nodes in the simulation and configures each with the required protocol at each layer. Wireless node in NS-2 has physical, mac, LL, routing, and application layer [15]. NFC node is a wireless node but has different architecture. Current NFC devices produced in the market has three main layers for peer to peer connection which are RF physical layer, NFCIP-1 exchange protocol layer and application. So, to represent the described model some changes have been made to the wireless node.

The proposed simulated model passed through three stages illustrated in the following

paragraphs. First, implementation of the main layer of the architecture, known as the NFCIP-1 data exchange layer , has been made. This layer was added as a new protocol by adding a new directory to the NS-2. The new directory contains NFCIP-1.cc, NFCIP1.h and NFCIP1_pkt.h. These files contain the implementation details of the NFCIP-1 protocol as described in the ECMA-340 standard. It contains the definition of all packets types mentioned in figure 4 and send/receive procedures followed to allow initiator node to activate target then send application data and finally release the connection. Second, changes have been made to the physical layer in NS-2 to match the required bit rate of the peer to peer NFC connection. The new simulated rate is 424 kbps as specified in ECMA-340. Transmission time consumed by the defined rate was calculated by txtime() method. The implementation of this method moved from the mac layer which is omitted here to the physical layer of the NFC node. Finally, editing has made to the defined wireless node in NS2 found in ns-tcl/lib/mobilenode.tcl to change its layering. NS2 mobile node figure is shown in [16]. The target_ object of the wireless physical layer defined in NS-2 is used to connect it with the new defined protocol NFCIP-1.

6

Application agents on nodes were allowed to use this model to send data. So the new NFC mobile node model will look as shown in figure 5.

port demux Application

entry_ addr demux

NFCIP-1

target_

uptarget_

NetIF channel_

Radio Propagation Model

uptarget_

CHANNEL

Figure 5- NFC Mobile Node

Files modified in the NS-2 can be listed as: 1. Common/packet.h: This file contains list of all packet types used by any protocol defined and used in NS-2 simulations. PT_NFCIP1 is the new type defined to be used by NFCIP-1 protocol. 2. Tcl/lib/ns-packet.tcl: This file contains the procedures needed to handle any defined packet type in common/packet.h. We add NFCIP1 as a new protocol type to be able to mange sending and receiving of PT_NFCIP1 packets. 3. Tcl/lib/ns-default.tcl: This file is used to specify default values of parameters accessed by the TCL objects defined in any protocol. We set the used data length value by the NFCIP1 protocol here. Used values as will be shown in results are 8, 16, 32, 128, 256 and 512. 4. Tcl/lib/ns-lib.tcl: 7

This file contains definition to protocol agents. We add NFCIP1 a new agent type that can be connected to a mobile node. 5. Tcl/lib/ns-mobilenode.tcl: One of the uses of this file is to add node interface which contain objects of the needed underlying protocols to build the mobile node architecture. The normal mobile node need to access TCL objects for each layer such as $llType_, $macType_, $phyType_, and others. We add add-nfcip-interface as a TCL instance procedures that access only the needed objects of the new node structure as shown in figure 3.

After modifying NS-2 files to represent the new mobile node with its protocols, we build a TCL script to run the simulation and use the new model. Some special requirements are needed to represent a peer to peer NFC connection. First, the topology contains only 2 nodes which represent initiator and target. Second, the topology dimension must represent the operating range of NFC connection. We have used a 0.1m× 0.1m (represented in ns-2 as $topo load_flatgrid 0.1 0.1). Second, the propagation model used in the space must be specified. NS-2 has two types of propagation models. Free space model and Two-ray ground reflection model. We use the free space model (represented in ns-2 as set val(prop)

Propagation/FreeSpace). This model assumes an ideal propagation condition that there is

only one clear line-of-sight path between the transmitter and receiver [16]. So it is used for near range connections.Fi nally, NFC node operates at 13.56 MHz frequency (represented in ns-2 as Phy/WirelessPhy set freq_ 1.36E+07)

5. SIMULATION RESULTS To test the efficiency of the simulated module, a comparison has been derived between the proposed simulation model and a real NFC system [17]. The real system includes two ROKR E2 phones with NFC circuitry touched. The two devices implement the NFC Interface and Protocol (NFCIP-1) in 8

active mode with 424 Kbits/s and 251 byte maximum packet size. NFC peer to peer connection passes through three stages:  First one is initialization. This is a fixed waiting time known as initial RF collision avoidance as described in ECMA-340. In this stage the initiator wait to ensure that there is no data send in the field to avoid collisions.  Second stage is InJumpForDEP as described in [17] which maps for the exchange of ATR_REQ – ATR_RES as described in ECMA-340. In this stage both parties announce to each other the connection attributes. Time of this stage is also equal for any amount of data sent.  Finally, last stage of InDataExchange as described [17] which maps to the exchange of DEP_REQ – DEP_RES as described in ECMA-340. The initiator sends its application data at this stage. The time needed for this stage will differ depending on the length of the sent packet. This time is measured by the simulator Our concern is the final stage which is the data transfer rate of the initiator for the proposed model. The time of this stage was tested by the simulated model at different packet length and results are shown in figure 6.

Transfer Rate of NFC Connection

Time in Seconds

2.5 2 1.5

Real System Simulated System

1 0.5 0 8

16

32

128

256

502

Payload

Figure 6- Initiator Data Transfer Rate 9

From the figure we will notice that the increase in the time at 8, 16, 32 and 128 data length is slightly simple. When sending large packets with 256 and 502 data length, more time is needed because the initiator will send this data in more than one packet. Initiator use chaining mechanism as described in ECMA-340 to divide large data to blocks so it doesn‟t exceed the maximum packet length specified by the standard. Comparison between real system and simulation model shows that values are close to large extent. The percentage accuracy of the simulated transfer time for different packet sizes is shown in table 1, where R represents the real transfer time, S represents the simulated transfer time, D represents the frame data length and A represents the percentage accuracy and defined as :

A

D (Bytes) 8 16 32 128 256 502

S  R  100 R

R( ) 0.3 0.4 0.4 0.8 1.2 2

S( ) 0.30692 0.30707 0.30737 0.76197 1.37978 2.15521

Average Accuracy

A 2.3063 23.2325 23.157 3.803 14.9817 7.7605 12.54%

Table 1- Average Accuracy of the Simulation Model

Also we have calculated the throughput of the simulated system for different packet sizes. Values of throughput are shown in the figure 7.

10

Throughput 0.3

KiloByte/Sec

0.25 0.2 Real Throughput

0.15

Simulated Throughput

0.1 0.05 0 128

256

512

Payload (Bytes)

Figure 7 – Throughput of NFC Connection

The throughput of the system increase in case of small payload but we notice more overhead and less achieved throughput when user application tries to send large data that need more than four frames per connection. After receiving the four sequenced frames, initiator has to restart the connection. This throughput values make NFC suitable for applications that exchange limited amount of data such as identity information and parameters needed for establishing connection with other more fast wireless technologies.

6. FUTURE WORK This paper presents a simulation model for the NFC mobile device. The simulation depends on NS-2 which is one of the powerful tools for network analysis researchers. The proposed model can be extended to include the passive mode of NFC connections. Also NFCIP-1 protocol needs to be supported with other techniques such as flow control mechanisms. So this model is a start point for many research points. It provides a way for researchers to analyze the NFC system on labs before start of using it in different life applications.

11

REFERENCES [1] NFC Forum - http://www.nfc-forum.org/aboutnfc/ - 2008. [2] ABI Research Firm - http://www.abiresearch.com/press - 2008. [3] S. AHSON, M. ILYAS - “RFID Handbook - Applications, Technology, Security, and Privacy” 2008 by Taylor & Francis Group, LLC. [4] Ecma International Organization http://www.ecmainternational.org/publications/standards/ Standard.htm - 2008. [5] International Organization for Standardization -http://www.iso.org/iso/iso_catalogue/catalogue_tc/ catalogue_tc_ browse.htm?commid=45072 – 2008. [6] S. Nava, G. Chavira -” Towards Simple Interaction in the Classroom: An NFC Approach”- IADIS International Conference e-Learning- Amsterdam, the Netherlands - 2008. [7] S. Ghìron, S. Sposato - “NFC Ticketing: a Prototype and Usability test of an NFC-based Virtual Ticketing application” - First International Workshop on Near Field Communication - 2009. [8] J. Ondrus, Y. Pigneur - “An assessment of NFC for Future Payment Systems”- Sixth International Conference on Mobile Business, IEEE Computer Society- 2007. [9] Y. Anokwa, G. Borriello, and R. Want - "A User Interaction Model for NFC Enabled Applications" - The Fourth IEEE Workshop on Context Modeling and Reasoning- 2007. [10] C. Duverne, G. Romen and T. Barba - “Near Field Communication Technology and the Road Ahead” - NFC Forum - 2007 [11] S. Gr¨unberger , J. Langer - “Analysis and test results of tunneling IP over NFCIP-1” - First International Workshop on Near Field Communication - 2009. [12] Standard ECMA-340, Near Field Communication Interface and Protocol (NFCIP-1)http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-340.pdf December 2004. 12

-

2nd

Edition

/

[13] Information Sciences Institute, “The Network Simulator - ns-2”, http://www.isi.edu/nsnam/ns/ 2008. [14] T. Issariyakul, E. Hossain - “Introduction to Network Simulator NS2” - 2009 by Springer Science+Business Media, LLC. [15] M. Greis. “Tutorial for the Network simulator „ns‟ ” - http://www.isi.edu/nsnam/ns/tutorial/ . [16] Ns Manual - http://www.isi.edu/nsnam/ns/doc/ns_doc.pdf [17] Yaw Y. Anokwa, "Beyond Device Pairing: New Interactions on NFC Enabled Mobile Phones", Department of Computer Science and Engineering, University of Washington - 2007.

13