About Non-IP Data Delivery (NIDD)

About Non-IP Data Delivery (NIDD)

Non-IP Data Delivery (NIDD) offers efficient communication between IoT devices and enterprise applications. This data delivery method can help applications that transact small amounts of infrequent data. NIDD is capable of transporting up to 1500 bytes in a single transmission without the tens of bytes of overhead required by IP, and higher layer protocols such as TCP or UDP. NIDD helps to reduce management overhead by eliminating the need for maintaining pools of Static IP for devices.    

To use the NIDD service on the Verizon LTE Network, devices must subscribe to Verizon’s NIDD APN, VZWSCEF. During the initial network attach process, the device attempts a Type Non-IP connection request. The device also indicates to the network that it supports CP CIoT Optimization. Verizon’s LTE network supports more than one simultaneous Packet Data Network (PDN) connection. The Verizon Network allows the device to establish and maintain connections with an IP PDN and Non-IP PDN simultaneously (only for devices that support this capability).

An enterprise application can use ThingSpace APIs to enable the NIDD service and to send or receive NIDD to/from an IoT Device. 

NIDD is only supported for NB-IoT devices currently.

  • ThingSpace users should register the callback for the NiddService for receiving asynchronous responses.
  • NIDD service can be enabled by choosing the NIDD priceplan while performing any of the following actions using ThingSpace Provisioning APIs.
    • Activating
    • Restoring
    • ChangeServicePlan
  • NIDD service can be disabled via Deactivations/Suspend a line (device).
    • While Activating/Restoring/ChangeDeviceServicePlan NIDD priceplan for an NB-IoT device, the enterprise application receives additional callbacks:
      • as NIDD is being configured for that device
      • when an NIDD priceplan is being added to that line (device).
    • The enterprise application or the device will need to wait for this additional callback before sending or received NIDD messages.
  • The enterprise application has the following options to send data to a device (after NIDD transportation is enabled for it, as previously mentioned):
    • For sleepy end points, the enterprise application can use Reachability APIs to inquire about the status of device availability. Upon receiving a ‘reachable’ status, the application sends an NIDD message to the device. The enterprise application receives a callback acknowledging the data delivery to device.
    • Or the application can send an NIDD message to the device without knowing if the device is reachable at the moment. If the device is not reachable at that moment, then the data is buffered by the Verizon Network. A callback is sent to the application to indicate that data is buffered at the network, not delivered. The network monitors the device for availability. As soon as the device becomes reachable, the network transmits the buffered data. The application server receives another callback, this time confirming delivery of data.
    • In case the device remains unreachable for the time limit set by maxDeliveryTime (a configurable parameter available through NIDD message request), the application receives a callback to indicate that the data could not be delivered to the device within the established maxDeliveryTime set by the application.
  • The enterprise application receives an NIDD data message from the device asynchronously at the NiddService callback service anytime the device sends the NIDD message to the application.
  • The device can send an NIDD message data to the application server at any time without restriction, as long as it is attached to a Non-IP APN and subscribed to the NIDD Service.