RIPlink technical overview
How RIPlink works?
RIPlink technology relies on a RIPlink Gateway running the IP, TCP and UDP stacks, and connected to IP network or hosting local IP applications. The RSP protocol, acting as a remote procedure call protocol, exposes the RIPlink Gateway TCP/UDP portable socket Application Programming Interfaces (APIs) to the applications running on RIPlink Devices. RIPlink Device does not need any IP, TCP nor UDP stack, but simply an RSP Client.
The IP application running on the RIPlink Device is seen from the IP network as running on a port of the RIPlink Gateway. It can be a client or a server application.
Several IP applications can run on the same RIPlink Device. The RIPlink Gateway can manage simultaneously several RIPlink Devices, on one or more different non-IP networks.
Benefits
RIPlink, by allowing standard IP applications to run on non-native IP devices, drastically simplifies M2M application design and deployment and helps protect investment:
- Application design is standard and portable, using BSD-like TCP/UDP socket APIs: applications are easily developed and portable across usual operating systems; re-use is maximized for both IP and non-IP networks;
- Applications are network independent: no need to learn about the non-IP network specificities; no need to modify the non-IP network: routing capabilities, including mesh when available, are unchanged; no network specific application profile is required;
- Application operates on heterogeneous devices, across heterogeneous non-IP and IP networks, using standard IP addressing principles (address and port).
RIPlink has been designed to optimize the scarce network and device resources by re-using the existing networking and transport layers of the IP and non-IP network:
- IP without IP overhead for bandwith savings, thus allowing more devices to be connected and better battery life: only 3 bytes overhead for TCP data and a few bytes to establish a connection, far below the usual 40 byte overhead for TCP plus IPv4;
- No IP routing need in the device: with the RIPlink Gateway IP address used to address all attached RIPlink Devices, RIPlink can be deployed on IPv4, IP routing is not impacted and remains located into the IP network. As a counterpart, as for a NAT architecture, RIPlink Devices are not individually addressed by an IP address but at application level;
- Minimum requirements on non-IP network transport layer: support networks with small packet size (down to below 25 bytes); no segmentation mechanism needed is usual cases;
- Minimal – software only – impact, typically few kilobytes of code (<10kB), low data memory, no significant CPU requirement, no real-time constraints, no OS required on RIPlink Device.
With such combined performance, simplicity and flexibility, RIPlink can be introduced now and smoothly. RIPlink can co-exist with legacy devices and applications. When needed, non-IP applications can be used in conjunction with IP based applications.
Existing alternatives to RIPlink
Today, the main alternative proposals to RIPlink, for providing IP access to non-IP networks, are:
- Using IP networking evolution to address these specific networks, in particular considering ongoing IETF specification activities such as 6lowPAN and ROLL. Even if the long term benefit is to fully integrate all devices in the IPv6 networks, a gateway device between IP and 6lowPAN networks will be needed for long time, as usual IP networks do not support 6lowPAN – or even IPv6 – from Day One. In addition, this kind of approach imposes some trade-offs on routing and networking capabilities, thereby losing part of the specifics and optimization of each network technology
- Designing an application-level gateway. The gateway embeds an application that on one side connects to the IP world, and on the other side is designed specifically for the non-IP network. Such an approach presents the disadvantage of requiring the re-design of the application, on the gateway and on the end-devices, for each network. It makes the gateway more and more complex as it handles different non-IP networks. In addition, interoperability at the application level requires defining a specific application profile for each network, and for each application.
Read next...
More...
Internal resources
External links
