SNEP Default Server

The SNEP specification defines both a protocol and a Default SNEP Server that can be connected to on services access point address 4 or with the service name urn:nfc:sn:snep. The Default SNEP Server is a mandatory service on NFC Forum compliant devices.

The Default SNEP Server provides a simple inbox into which remote clients can drop NDEF messages. What then happens with these messages is not defined but the most natural processing in application hosting devices such as smartphones is to see if there is an application installed that can handle the message type that was received.

Interoperability Test Requirement

The interoperability test scenarios require that a Default SNEP Server implementation either dispatches or makes visible the NDEF message received such that the success of receiving can be clearly identified.

Because the Default SNEP Server is a mandatory component on every NFC Forum Device, the maximum NDEF message size that is guaranteed to be transmittable is only 1024 octets. However, as application hosting devices have quite substantially more memory and processing power, larger transmission sizes are desirable and achievable.

Interoperability Test Requirement

The interoperability test scenarios require that a Default SNEP Server implementation supports NDEF message sizes of at least 20480 byte (20 KByte).

Connect to the Default Server

The Default SNEP Server is a well-known service with the service access point address 4 and service name urn:nfc:sn:snep. The NFC Forum Device Requirements mandate that an NFC Forum Device always has that service available. A SNEP client can choose to either connect directly to the destination address 4 or use the well-known service name.

The SNEP protocol uses the LLCP connection-oriented transport type facility, thus a client first has to establish a data link connection with the server. As part of the connect procedure, the server will indicate its data link connection receive window and maximum information unit size. To achieve data throughput that allows 20 KB to be transferred within a time that is convient for the user to hold devices in proximity, the the maximum information unit size should be the largest possible multiple of 248 octets (to match the NFC-DEP capacity for a single information packet) and the receive window should be 2 or more to allow the sender to continue while the earlier LLCP Information (I) PDU is still to be acknowledged.

Interoperability Test Requirement

The interoperability test scenarios require that a Default SNEP Server implementation supports a data link connection receive window of 2 or more and a maximum information unit size of 1984 octets.

  1. As a choice of the Device In Testmode send either a CONNECT PDU to service access point address 4 or a CONNECT PDU with the service name urn:nfc:sn:snep to service access point 1.
  2. Verify that the Device Under Test replies with a Connection Complete (CC) PDU.
  3. Verify that the CC PDU contains a Receive Window (RW) parameter with a value of 2 or more.
  4. Verify that the CC PDU contains a Maximum Information Unit Extension (MIUX) parameter with a value that results in an MUI of 1984 octets.
  5. Disconnect from the Default Server

Disconnect from the Default Server

Once a client has established a connection with the server and potentially transmitted an NDEF message it should disconnect in order to allow the server free its resources.

  1. Connect to the Default Server
  2. Send a Disconnect (DISC) PDU on the data link connection with the Default SNEP Server.
  3. Verify that the Device Under Test confirms termination of the data link connection with a Disconnected Mode (DM) PDU and reason code 0.

Sequential Connects

Although most current usage scenarios involve just the transfer of a single NDEF message, a Default SNEP Server should be prepared to receive another connection request once a client terminated a previous data link connection.

  1. Connect to the Default Server
  2. Disconnect from the Default Server
  3. Connect to the Default Server
  4. Disconnect from the Default Server

Unfragmented Message

A SNEP client uses the PUT command to place an NDEF message into the Default SNEP Server inbox. If the NDEF message plus the SNEP protocol header fit into a single I PDU, the server can immediately reply with the Success response.

  1. Connect to the Default Server
  2. Send a PUT request with a single record text message that contains the string “NFC Interoperability Test Scenarios” in English language encoding.
  3. Verify that the server replies with a Success response and that the text is shown on the Device Under Test.
  4. Disconnect from the Default Server

Fragmented Message

If the NDEF message plus the SNEP protocol header does not into a single I PDU, the client must send the message as a sequence of fragments. The server must wait until the last fragment is received before sending the Success response. To avoid that the client transmits more data than the server can handle, the first fragment contains, as part of the SNEP request header, the total NDEF message size and the server must reply to the first fragment with a Continue or Reject response message depending on whether it can receive that amount of data. If the client receives a Continue response it sends the remaining fragments without further confirmations.

As stated before, the interoperability test scenarios require that a Device Under Test implements the Default SNEP Server to accept an NDEF message of up to 20480 octets total size.

  1. Connect to the Default Server
  2. Send the first fragment of a PUT request with an NDEF message of 20480 octet total size.
  3. Verify that the server replies with a Continue response.
  4. Send the remaining octets of the NDEF message.
  5. Verify that the server replies with a Success response.
  6. Disconnect from the Default Server