Connect One Ltd. 20 Atir Yeda Street, Kfar Saba 44643, Israel | Phone: +972-9-766-0456 | Fax: +972-9-766-0461 Email: [email protected] | www.connectone.com
Product Description
iChipNet Device Connectivity Server
Version 2.0.1
iChipNet – Device Connectivity Server
2
Information provided by Connect One Ltd. is believed to be accurate and reliable. However, Connect One Ltd. assumes no
responsibility for its use, nor any infringement of patents or other rights of third parties, which may result from its use. No
license is granted by implication or otherwise under any patent rights of Connect One Ltd. other than for circuitry embodied in
Connect One’s products. Connect One Ltd. reserves the right to change circuitry at any time without notice. This document is
subject to change without notice.
The software described in this document is furnished under a license agreement and may be used or copied only in
accordance with the terms of such a license agreement. It is forbidden by law to copy the software on any medium except as
specifically allowed in the license agreement. No part of this document may be reproduced or transmitted in any form or by
any means, electronic or mechanical, including but not limited to photocopying, recording, transmitting via fax and/or modem
devices, scanning, and/or information storage and retrieval systems for any purpose without the express written consent of
Connect One.
iChipNet – Device Connectivity Server
3
Table of Contents 1. Introduction ............................................................................................................................................. 5
2. The IP Address Problem .......................................................................................................................... 5
3. Server Systems ........................................................................................................................................ 6
4. iChip Web Server ..................................................................................................................................... 6
5. Using a Device as a Server ....................................................................................................................... 7
6. Connect One's Device Connectivity Server ............................................................................................. 7
7. DCS Setup ................................................................................................................................................ 8
8. DCS Operation ......................................................................................................................................... 8
9. Device Connectivity Server Functions ..................................................................................................... 8
10. How it Works ...................................................................................................................................... 9
1) Keep Alive Query ................................................................................................................................ 9
2) Open Web Server Return Socket ........................................................................................................ 9
3) Open AT+i Return Socket .................................................................................................................... 9
4) Open Agent Listen Socket ................................................................................................................... 9
5) Open Return Socket .......................................................................................................................... 10
11. Summary ........................................................................................................................................... 10
Appendix A: Connectivity Server Setup and Usage ............................................................................................ 11
1) Setup and Configuration ......................................................................................................... 11
2) Surfing the DCS’ Web site ....................................................................................................... 12
3) Account management ............................................................................................................ 14
Appendix B: Establish new Account in Connect One DCS HOST ......................................................................... 15
1) Sign Up .................................................................................................................................... 15
2) First usage ............................................................................................................................... 15
3) Purchase Device Connection Package .................................................................................... 15
4) Activating the DCP .................................................................................................................. 15
Appendix C: Self Hosting Connect One Device Connectivity Server .................................................................... 16
Appendix D: Using the DCS API ............................................................................................................................ 16
iChipNet – Device Connectivity Server
4
Revision History
Version Date Description
2.0 Feb 18th 2015 Initial Version
2.0.1 Jan 18th 2016 Revising Appendix A section 1
iChipNet – Device Connectivity Server
5
1. Introduction Machine-to-machine communications or Internet of Things (M2M/IoT) represents the third generation of
computing, following the first generation of business computing in the 1950s and the second generation
of personal computing in the 1980s. IoT/M2M is simply the communication of non-PC devices with each
other or with a computer. Included in the category of communicating non-PC devices are home
appliances, personal electronics, vehicles, financial terminals, machines, utility meters, medical devices,
mobile terminals, transportable assets, information appliances, industrial controllers, security systems,
building controls, telemetry devices, home automation systems and many other products with
embedded microcontrollers. There are literally billions of these devices installed worldwide. Devices can
communicate with each other and with central or back offices via a variety of communication methods,
including dial-up or cellular modems, private radio networks, leased lines, satellite, Wireless LAN or wired
LANs. The common denominator is that communication must be secure and access allowed only to
authorize users and indeed, most networks have some form of security to restrict access. The two most
common forms of network security are firewalls and network address translator (NATs). These security
measures are very effective at keeping unauthorized users out of the network. However, they also keep
out authorized users and legitimate clients who try to gain access from outside of the network or subnet.
Where there is a real business need for IoT/M2M communication, such as improving productivity and
our life style or lowering the cost of service, communication or infrastructure, IP-based networks are the
perfect medium for IoT/M2M communication. IP Based networks utilize packet-switching technology,
which is an efficient form of data communication. With packet-switched transmission, the data is
disassembled into small parts called packets that are then sent in sequence to the receiver, which
reassembles the packets. This ensures that many different users can share the same link at the same
time, the link is used only when there is data to be sent. When there is no data to send, the link may be
used by another user.
2. The IP Address Problem IP-based networks use IP addresses to establish sessions. In order to communicate over the Internet a
system must have an IP address. There are several categories of IP addresses that may be assigned to a
system: Fixed or Dynamic IP addresses, False IP (or non-public IP) addresses, or Real (public) IP addresses.
Real (public) IP addresses needs to be separately purchased by the users and usually requires also
monthly fees, however, it offers a guaranteed means of communicating with a device. Dynamic IP
addresses exist when a device receives a different IP address for each Internet session. Dynamic IP
addresses exist usually in landline and cellular environments where there is a PPP session. Sometimes
they also exist in LANs, where a DHCP server assigns IP addresses from a dynamic pool.
It is complicated for a server device to be based on a dynamic IP address, since the remote client does
not know with which IP address to access the server. False IPs are legal IP addresses only inside a private
subnet, but are not accessible on the public Internet. False IP addresses are usually used for devices
iChipNet – Device Connectivity Server
6
located on a sub-segment in a LAN environment behind a NAT (Network Address Translator). In this case,
the devices can act as servers on their sub-segment; however, they will not be accessible to clients
beyond the subnet and NAT. False IP addresses also are widespread in cellular networks. In some
situations, the assigned IP addresses are both dynamic and false, as is the case for example with many
cellular services. Nodes that are assigned false IP addresses may only act as clients on the network. They
cannot open passive, listening sockets and act as a server. Therefore, networked systems cannot initiate
a connection to these nodes; they may only be replied to. As such, these nodes cannot host a Web
server, which is an important component in remote configuration, remote monitoring and remote
control of networked devices.
3. Server Systems A server is a passive node that accepts connections initiated by a client node. Clients are devices that
connect to the Internet to report their data to a central system. For example, a Web browser is a client
implementation. It initiates a connection to a Web server, which is a server implementation. When a
device acts as a server (providing a service to clients seeking to access data), a client system must know
what IP address to use in order to access the server. Therefore, devices that need to act as servers
generally require a fixed, legal IP address. Server systems that have a dynamic and/or false IP address are
problematic because (a) in the case of dynamic IP address, the client systems do not know what IP
address to use to access them and (b) they cannot approach them in the case of false IP address. A Web
browser must know the Web server’s name or IP address in order to access it. Devices that are
connected to the Internet may also need to act as servers to provide the following services:
Management and configuration
Remote update of data or firmware
Remote activation
Remote control
Port server
4. iChip Web Server iChip™ is a coprocessor that offloads IP connectivity tasks from a host processor. The logical interface
between iChip and the host processor is Connect One's AT+i™ protocol, a high-level command set written
into the host application. AT+i extends an Internet connectivity command set to the industry-standard AT
command set used in modems. It enables rapid implementation of IP connectivity in the host application
by eliminating the need for Internet programming. Many models of Connect One's iChip Internet
Controller™ family include an embedded Web server, which can provide the abovementioned services to
a host device. iChip's Web server stores two Web sites: The iChip configuration Web site and the
Application Web site. The iChip configuration Web site is used to set up the connection and operating
iChipNet – Device Connectivity Server
7
parameters for iChip. The application Web site is used by the host device for controlling the host
application.
5. Using a Device as a Server There are several instances where it is advantageous to configure the device as a server:
Using iChip's configuration Web server – assuming iChip Internet-enables a host device, enabling
its internal configuration Web site will allow remote support and configuration of iChip's setup
parameters.
Using an application Web server – devices may be monitored and controlled by enabling a Web
server application and accessing their Web server via a standard browser. iChip supports this type
of interaction with its application Web site and parameter tags.
Using non-Web server applications – the device manufacturer may decide to implement one or
more services on the device and use listening sockets to accept a remote connection. This is
generally the preferred methodology when providing an asynchronous service to remote systems.
Using remote AT+i commands – in an iChip environment, AT+i commands may be issued across
the network for remote support, configuration and troubleshooting the iChip inside the host
device. In this case, the iChip is configured as an AT+I server and may be approached by a Telnet
client.
In each of these cases, the device acts as a server and must be approachable by a remote client.
Therefore, the client needs to know the IP address of the server to which it needs to connect. As
mentioned, assignment of dynamic and/or false IP addresses precludes the client from knowing the
correct IP. Connect One's Device Connectivity Server (DCS) which is part of the iChipNet™ set of IoT
implementation building blocks, bridges this gap by providing a proxy channel for each device link.
6. Connect One's Device Connectivity Server Connect One's Device Connectivity Server (DCS) is a combination Web server, registration server, and
proxy server. It is a tool for system integrators and device operators to overcome the aforementioned
drawbacks of accessing devices located behind NATs and firewalls. It allows devices with dynamic and/or
illegal IP addresses to act as servers, regardless of the IP address they are assigned. It also provides a
simple Application Programming Interface (API) for a remote application so that it can connect to devices
in the field. The DCS solution is based on two components: an agent running on the iChip (device side)
and the DCS server application. The DCS is permanently connected to the Internet via a fixed IP address,
preferably with a DNS-registered host name. Since the DCS acts as a proxy, its upstream and downstream
bandwidths should be balanced. The DCS is based on SQL database system and a Web server. The Device
Connectivity Server’s Web site is the front-end interface for managing all remote Internet-enabled
devices. Information may be obtained from the DCS by surfing to the DCS’s Web site with a standard
iChipNet – Device Connectivity Server
8
browser or by querying the DCS over a TCP/IP socket using Connect One's API (distributed as an Active-
X).
7. DCS Setup The DCS implementation defines several listening ports where remote device connections are accepted,
in addition to port 80, which is used for the standard Web server. The DCS is intended to be connected
directly to the Internet without a firewall or NAT and therefore should NOT be connected to the
corporate LAN. The DCS includes an application to set up user accounts. A user account must be
associated with a device set using rules. The Device Connectivity Server can manage distinct device
groups. Each device group belongs to a specific user account. After a one-time setup, an iChip-enabled
device can be configured to register with the DCS when it goes online, allowing account owners to log in
and use DCS services. When a device logs in for the first time, a permanent entry is created in the
connectivity server’s database. The connectivity server maintains a status log for each device, which is
displayed in the DCS Web site.
8. DCS Operation When operating with a browser, the DCS user surfs to the DCS’ Web site. The user is authenticated with a
username/password form and/or a secure HTTPS connection. The DCS determines from the user’s
account which subset of devices is “owned” by that account. Subsequent operations for that user are
restricted to those devices only. This methodology allows a DCS to support several customers’ devices.
Only devices belonging to the logged-in account shall be displayed. The user may view a browser page,
which lists all his devices, whether online or not. Pertinent device information shall be displayed with
each device. The information fields may be sourced from the device (iChip) or the DCS database. In
addition, active links to the online devices’ Web servers are listed when the device enables them.
General listening ports and the special iChip remote AT+i server port are listed in informational fields, so
the user may make use of them in potential applications. Note that all links to the devices are actually to
ports on the DCS, which acts as a proxy server and routes the transmissions to the appropriate
iChip/device. To facilitate the development of related client applications, the DCS supports a socket
connection dedicated to retrieving remote device information computationally. Connect One provides a
protocol and a special API, which enable an application programmer to easily retrieve device information
from the DCS, up to the point where he/she may open a client socket to a remote iChip via the DCS.
Detailed description of the API could be found in the iChipNet DCS API Guide.
9. Device Connectivity Server Functions The DCS provides the following functions for each device:
1. Displays current status of all your devices in a standard Web browser: online, offline, elapsed
time, host name (symbolic name), date/time of last connection or last disconnection.
iChipNet – Device Connectivity Server
9
2. Provides direct links to each device's iChip configuration Web server from a standard browser,
when enabled.
3. Link to a device’s application Web site, if enabled.
4. Links to a device's listening sockets when open and enabled.
5. Links to a device's AT+i control port, when enabled.
6. Maintains device logs.
10. How it Works The Device Connectivity Server software is installed on a dedicated computer which is connected directly
to the Internet via a fixed IP address. The DCS listens on a specific registration port, which the iChip-
enabled device uses in order to register itself when goes online. When it registers with the DCS, iChip
transmits its relevant ID information, such as device type, host name, unique serial number, firmware
version number, etc. over a registration socket. When the registration socket is established, iChip
transfers the registration information to the DCS, which logs iChip's dynamic, false or private IP address
into the DCS database. Clients can now browse into the DCS and see what devices are registered and
whether they are online or not. The client can then browse into a specific device via the DCS, which acts
as a proxy for the remote device. As long as the device is online, the registration socket remains open as
a channel to communicate a proprietary control protocol. The following operations may be achieved
through the control protocol:
1) Keep Alive Query
Each system may issue a query to verify that its peer is still connected.
2) Open Web Server Return Socket
The DCS instructs the iChip to open an active socket back to the DCS (the port number is supplied in the
command), to be used as a channel to the iChip’s Web server. iChip treats this socket as if it was an active
socket opened to its listen port 80. The DCS requests this socket in order to route browser requests to
iChip.
3) Open AT+i Return Socket
The DCS instructs the iChip to open an active socket back to the DCS (the port number is supplied in the
command), to be used as an AT+i (like LATI) socket to take over the iChip’s AT+i parser.
4) Open Agent Listen Socket
iChip requests the DCS to open a listen socket on its behalf. iChip makes this request as a result of
processing the AT+iLTCP command. The DCS responds by opening a listen socket on a unique port. The
chosen port number may be retrieved by querying the DCS’ database using a Web browser or special
database information socket. When a remote system opens an active socket to the agent listen socket,
the DCS issues an open return socket command to the iChip over the control socket. When iChip opens
iChipNet – Device Connectivity Server
10
the return socket, the DCS patches this socket to the original active socket opened by the remote system
and routes all data between them.
5) Open Return Socket
The DCS requests iChip to open an active socket back to a listen port on the DCS. When it is open, the
active socket is used to route remote sockets to the iChip.
11. Summary Connect One's Device Connectivity Server, part of the iChipNet set of Building Block for IoT
implementation overcomes the problem of accessing devices located behind firewalls and NATs on IP
networks. It provides an innovative and flexible method for accessing and managing devices with
dynamic, false or non-public IP addresses. It also permits these devices to act as servers when IP-enabled
by Connect One's iChip Internet Controller.
iChipNet – Device Connectivity Server
11
Appendix A: Connectivity Server Setup and Usage
1) Setup and Configuration
The Connectivity Server must have an active ACCOUNT for iChip devices to be allowed to register. An
Account has an associated “Account Name” and “Account Password’. The following parameters need to
be configured in iChip to allow DCS registration:
Connectivity Server Parameter iChip Parameter Comments
Account Name HSTN The Account name needs to be appended to
iChip’s Host Name and surrounded by ‘_’
(underscore).
For example: in case the required Host Name is
“WaterMeter”. To use Connectivity Server, use
the following AT+i command:
AT+iHSTN=”WaterMeter _{account}_”, where
account is the Account name that will be
assigned in the Connectivity Server.
Registration Address RRSV RRSV must contain the Connectivity Server’s IP
address and Port. The general configuration is:
AT+iRRSV={IP address}:443
For example: To use Connect One’s DCS host, the
following configuration needs to be made:
AT+iRRSV= 62.219.183.29:443
If a web site name is associated to the server IP,
the name can be used as well. In that case the
command will looks like the followings:
AT+iRRSV=www.ichipnet.com:443
With these configurations set, iChip will register with the DCS when it goes online to attend to an
Internet session.
iChip may also be forced online and stay online, even without an associated Internet session, using the
AT+iUP command with a ‘1’ flag: AT+iUP:1.
iChipNet – Device Connectivity Server
12
When using an iChip that is connected to a LAN, iChip is already online after power-up. However, the
AT+iUP:1 command must be issued after power up for iChip to register with the Connectivity Server.
2) Surfing the DCS’ Web site
To browse the DCS’ Home page, surf to: http://{Connectivity_Server_IP_address}/mangernew. For
example: Using Connect One’s DCS Host, use: http://62.219.183.29/managernew/ or
http://www.ichipnet.com/managernew
Enter your Account Name and Account Password and click ‘Login’.
The device status page with links to individual registered iChip’s will show up as below:
iChipNet – Device Connectivity Server
13
Devices with green light are online and devices with Red light are offline. When a device goes online and
registers, it would be seen in the next refresh which is done every 10 second.
The device list page includes details on every device and available services the device can support. In the
above image, ‘DEVICE SENSOR’ has a serial number 1405E805, it is On Line since Dec 8 2014 at 1:40:21
PM, it has the configuration site and host site active, and can get remote AT+I command.
Clicking on one of the icons will produce a connection to iChip’s respective Web site (via the Connectivity
Server). Note that a standard browser will be able to surf the iChip’s Web site even if the iChip is behind a
NAT/Firewall.
Similarly, when iChip opens listen sockets, (a remote AT+i socket (LATI) or a SerialNET socket) the related
links will be shown in device list page.
When iChip goes offline (i.e., AT+iDOWN) or powers off, the Connectivity Server’s device list page will
reflect the Off Line status next time it refreshed.
iChipNet – Device Connectivity Server
14
3) Account management
Click on the Account Management icon will open the account management page. The account
management page allows for the followings:
Password changing
Enable/Disable devices (Disabling device will release location for new devices)
Managing the number of the connected devices and availability for new devices
Adding new device packages
iChipNet – Device Connectivity Server
15
Appendix B: Establish new Account in Connect One DCS HOST A service provider can establish new account at Connect One’s DCS Hosting server. Creating new account
will grant the service provider 5 free devices to be registered to its account.
For additional devices to be able to register into the account, the service provider will be required to
purchase a “Device Connection Package” which allows for up to 500 devices to be associated with the
account.
1) Sign Up
Brows to www.ichipnet.com/managernew
Click on the “create account”
An online form will be opened. Fill in all the required information and click “create”
An email with a link will be sent to the email address provided
Clicking on the email will activate the account
2) First usage
Brows to www.ichipnet.com/managernew
Enter the Account name and password chosen in the Sign Up process and click ‘Log in’
New device list page with 5 locations will open up.
At this stage the account is ready to accept new device registrations.
3) Purchase Device Connection Package
Acquiring the Device Connection Package (DCP) will require sending a formal purchase order to
Connect One
The Purchase order should include the followings:
o Company Legal Name
o Company Address, phone number and Fax number.
o Contact person
o Account name in the DCS given in the first Sign Up process
o Part number DCP-500 (or -1000 or -5000)
o Qty, unit price and Total per the latest Connect One’s iChipNet price list.
Following a payment of a pre-forma invoice sent to the customer, a confirmation will be sent over
with a DCP-500 activation number
4) Activating the DCP
Brows to www.ichipnet.com/managernew
Log in using your account name and password
Click “Account Setting” “DCP Activation Code”
Enter the Activation Code located in the purchase confirmation and press “Activate”
iChipNet – Device Connectivity Server
16
After “Activating Success” message shows up, check that the number of “Available Devices” has
been changed.
Appendix C: Self Hosting Connect One Device Connectivity Server Option for self-hosting the Device Connectivity Server is available.
Please contact Connect One at [email protected] for further details regarding system
requirements, installation instruction and pricing
Appendix D: Using the DCS API The Device Connectivity Server (DCS) can be queried for devices associated with a specific account using
a special API. The web API is an ASP based web page residing in the DCS called Util.ASP which all requests
are being made to. The process of accessing the account’s registered devices has two phases as follows:
Phase One – Authentication using the accounts User Name and Password.
Retrieving a session key from the DCS
Using the session key to create an MD5 hash of the Password
Sending the resulting MD5 with the account User Name to the DCS for authentication.
Phase Two - Query for specific device or the entire associated devices.
Successful authentication, which will follows by a specific request, will return the account’s devices status
in XML form.
Option: The client can send, with the User Name and MD-hashed password, a request for a single device
status data using the device serial number. If the device exists in the specified account, only the requested
device
Retrieving Session Key
Request –
http://www.ichipnet.com/managernew/utils.asp?Mode=0
Response in XML format -
<RESULT><KEY>[Session Key]</KEY></RESULT>
Authentication and device retrieving
After creating the MD5 hash of the password the client should send the following request:
Request to retrieve all devices –
iChipNet – Device Connectivity Server
17
http://www.ichipnet.com/managernew/utils.asp?Mode=1
&User=<Account name>&Pass=<MD5 hash>
Request to retrieve specific device –
http://www.ichipnet.com/Managernew/utils.asp?Mode=2
&User=<Account Name>&Pass=<MD5 hash>&SN=<Device
Serial Number>
Response in XML format
<RESULT>
<ICHIP sn='FFFFFFFF' hstn='_M2M_PS-AP' online='true'
www='62.219.183.29:2500' lati='' ltcp1='' ltcp2='' snet=''
condistime='11/24/2014 3:22:43 PM' snetcon='false' laticon='false'
tzoffset='0' />
<ICHIP sn='1406070E' hstn='_M2M_SENSOR2' online='false' www=''
lati='' ltcp1='' ltcp2='' snet='' condistime='12/26/2013 1:13:42 PM'
snetcon='false' laticon='false' tzoffset='0' />
<ICHIP sn='14052F1B' hstn='_M2M_DEMO' online='false' www='' lati=''
ltcp1='' ltcp2='' snet='' condistime='06/27/2013 10:24:47 AM'
snetcon='false' laticon='false' tzoffset='0' />
</RESULT>
Field description
Field Description
sn Device serial number
hstn _{account name}_{device name}
online Online status of the device true = online; false= offline
www DCS Web Site
lati Listen AT+I socket. This service is reflected in the DCS
ltcp1 Listen TCP socket number 1
ltcp2 Listen TCP socket number 2
snet Serial Net port number
condistime Date and time when the last online condition was set
snetcon Serial-net client connection status true = connection with client is active false = connection with client is non active
laticon LATI client connection status true = connection with client is active false = connection with client is non active
tzoffset Time zone offset
