Tizen RT 1.0 Specification

From Tizen Wiki
Jump to: navigation, search

IoT Data Management

1. File System Support

Tizen RT supports not only the lightweight File System called SmartFS but also virtual file system (VFS). The VFS can provide a common interface set in the form of POSIX API. Standard libc APIs are already supported. In addition, some advanced features are also included:

  • Proc File System for debug, and ROM File System for read only data.
  • SmartFS for flash file system with wear-leveling, bad sector management, and transaction logging based journaling.
  • MTD (Memory Technology Device) and MTD Partition.

2. Database(AraStorage) Support

Lightweight database called AraStorage is ready to manipulate collected sensor data with SQL-compatible interfaces. AraStorage also provides some advanced features below:

  • b+ tree based Indexing Algorithm.
  • Cursor structure to improve usability for application layer.

Device Management

Tizen RT incorporates the OMA based Lightweight M2M (LWM2M) protocol for Device Management. LWM2M is an application layer communication protocol between an LWM2M server and an LWM2M client that typically resides on a resource constrained device. The LWM2M protocol can be briefly described in context of its Interface and stack design.

LWM2M Interfaces

  1. Bootstrap: The LWM2M client obtains the information about the LWM2M server from the LWM2M Bootstrap server. The LWM2M bootstrap server holds the credentials of all registered LWM2M servers, and can provide the details either on request (client-initiated bootstrap), or explicitly (server-initiated bootstrap). At present, client-initiated bootstrap is already developed and verified. Server-initiated bootstrapping will also be included.
  2. Register: Once the LWM2M client has the necessary information about an LWM2M server, it opens a connection to the server and registers itself as an LWM2M device. Registering in this context, also includes providing details of the LWM2M objects that it has created during initialization.
  3. Device Management and Service Enablement: The LWM2M server uses this interface to query (read and discover operations), modify (write), execute, create and delete attributes on a registered LWM2M client object. While basic read operations are currently verified, support for other operations will be provided.
  4. Information Reporting: The LWM2M server uses this interface to periodically query the registered LWM2M client to send updates on an object attribute (sensor value or communication signal strength). Alternatively, the LWM2M server can also direct the LWM2M client to notify change in attribute values over a programmable time interval. The LWM2M protocol allows the LWM2M server to specify the observation time interval, and the range of permissible attribute values, beyond which notification should be carried out.

LWM2M Protocol Stack

  1. CoAP Protocol: The LWM2M entities (client, server and bootstrap server) use the CoAP (Constrained Application Protocol) for implementing the four LWM2M interfaces described above. CoAP offers the advantage of an efficient payload structure, which is necessary for resource-constrained client devices. In this context, LWM2M-based request and response messages are mapped on to appropriate CoAP methods (such as GET, PUT, POST) as described in RFC 7252.
  2. DTLS Security: While LWM2M optionally functions in a 'NoSec' mode (no security), it also allows the use of DTLS (Datagram Transport Layer Security) to ensure authentication, data confidentiality and integrity between a LWM2M client and a LWM2M server or bootstrap server. The LWM2M client has the option of bootstrapping with a pre-shared secret, or with public certificates (either raw public keys or X.509v3). In all cases, the LWM2M client must possess a unique key for securing communication with the LWM2M bootstrap server and the LWM2M server. These features will be supported on Tizen RT.
  3. UDP: LWM2M allows the use of both UDP and SMS protocol for communication between client and server. The lightweight M2M component in Tizen RT uses the UDP binding over port 5683. Reliability over UDP is achieved by the retransmission mechanism of CoAP.

IP Network

For TCP/UDP/IPv4 protocols, LWIP is already ported on Tizen RT and successfully verified. Regarding IPv6, uIP-based stack is already implemented and is granted IPv6 Ready Logo from IPv6 Forum (Go to https://www.ipv6ready.org/db/index.php/public/?o=4 and search with Tizen in the keyword field.) By the way, a common base for network stack should be needed in order to increase maintainability. Both IPv4 and IPv6 based on the common project (i.e., LWIP or uIP) will be released.

In addition, transition between IPv4 and IPv6 is also required. Suppose that sensor devices are equipped with only IPv6 over IEEE 802.15.4 or IPSP/BLE. These devices are required to connect to Internet directly or via hubs or other IoT devices. Tizen RT will get ready to fit into these relaying IoT devices by implementing the transition functions between IPv4 and IPv6.


Tizen RT 1.0 supports IoTivity 1.1.0 now.

IoTivity will be updated to 1.2 in the next release.

1. IoTivity 1.2 Base layer Support (OCF 1.0 Base Layer Ready)

Tizen RT supports IoTivity base layer for constrained device communication in IoT world. It supports IoTivity 1.2 release as base code with OCF 1.0 spec ready.

Currently IP transport(TCP/UDP over Wi-Fi) is supported in Connectivity Abstraction(CA) Layer.


Figure 2. IoTivity Base Layer Architecture

The figure depicted above shows the architecture of the IoTivity base layer. The architecture can be mainly divided into discovery, messaging, and security modules.

Here is the brief explanation for the features in IoTivity 1.2 of Tizen RT.

Component(Base layer) Feature Description
Discovery Multicast Discovery, Device Presence Discover resource, check device presence
Resource Introspection Resource Type/property management
Messaging CoAP Messaging Transmit message between devices
Message switching Tizen RT does not support message switching
Connectivity Abstraction Currently Wi-Fi transport support. Feature support for BT,BLE, NFC etc.
Block-wise transfer Block data transfer(More than 1KB data)
CoAP over TCP Reliable transmission. It can be used for messaging between device and cloud.
Security DTLS secure channel with data encryption for UDP.
Security Resource Manager Access control mechanism
Security Provisioning Manager transmit credential for authentication

2. Feature support in IoTivity 1.2

  • Tizen RT supports the IoTivity 1.2.0 base layer stack (csdk layer) with Wi-Fi transport.
  • It supports resource creation and publish for resource discovery. (resource registration, discovery , update, delete).
  • It supports Device to Device Communication with UDP over Secured DTLS channel.
  • Wi-Fi transport over IPv4 is supported in Tizen 4.0.
  • It supports CoAP over TCP for communicating with the IoT cloud. (resource registration, discovery , update, delete).
  • TLS support for the TCP to enable security for cloud communication.
  • Support presence for server side and provide presence callback for client side
  • Onboarding support (Wi-Fi provisioning) for new devices to enable easy setup feature on to the network.
  • Cloud provisioning to connect the device to the cloud and to publish the resource on to it.
  • Keep-alive mechanism to keep the cloud session active with CoAP over TCP.
  • Direct pairing support for credential delivery to transfer the ownership of the device for easy setup.
  • This supports multiple ownership transfer and multiple ownership structure in Security Resource Model.
  • Message-oriented communication interface for the cloud. This interface can be used for a publish/subscribe based information exchange. A resource model for a CoAP-based message broker will be provided.

IoTBus Framework

IoTBus Framework supports system I/O APIs for developers including the following 5 categories.

1. GPIO (General Purpose Input/Output)

Provides functions to control generic pins. It can be configured to be input or output because GPIO pins have no predefined purpose.

2. I2C (Inter Integrated Circuit)

Provides functions to read values of I2C devices or write command to I2C devices. It is typically used to connect sensor devices or for intra board communications.

3. SPI (Serial Peripheral Interface)

Provides functions to communicate with SPI devices. It supports synchronous serial communication interfaces used for a short distance communication. Full duplex modes using a master-slave architecture with a single master is also served.

4. PWM (Pulse Width Modulation)

Provides functions to get/set duty cycles and periods of PWM devices. It is typically used to control servo motors or LEDs.

5. UART (Universal Asynchronous Receiver/Transmitter)

Provides functions to read/write for asynchronous serial communication. And it is usually used in conjunction with communication standards such as RS-232, RS-422 or RS-485.

Device Management Framework

The following features will be made available under the Device Management Framework

1. Configuration

The LWM2M client will be configured with a set of parameters that include LWM2M bootstrap server address, bootstrap server port, and the LWM2M session lifetime. Alternatively, if a direct connection to LWM2M server is preferred, then the client will be configured with the LWM2M server address and port information.

2. Temporary halt and resumption

Wireless links, especially in indoor deployments are prone to intermittent failures, and may momentarily halt an on-going LWM2M session. Taking this into account, the Device Management Framework should gracefully close any all LWM2M sessions with their respective servers, and also logically resume the sessions once the wireless link is restored.

3. Support for Multiple Servers

The LWM2M specification allows multiple servers to perform Device Management with a registered LWM2M client. To this end, the framework should facilitate the seamless addition of LWM2M server information.

4. Device Management Services

Services provided under Device Management can be broadly categorized into four types:

  • Connectivity Monitoring: which relates to details such as client IP address, network type, signal strength, and effective data rate.
  • Power Monitoring: which relates to available power states of a device, its current power state, and the time spent in different power states.
  • Error reporting: which relates to out of memory conditions, and also temporary loss of wireless connection.
  • S/W Update: which relates to querying a firmware repository for updates, version checking, downloading and installing the firmware package.

Tizen RT 1.0 supports the former three services. The S/W Update will be included in the next version.