Iocast is a low-power wide-area networking system (LPWAN) designed to operate over narrowband land mobile radio channels. Its architecture is built around a core store-and-forward queuing system, optimized to exchange wireless datagrams with remote nodes. Iocast nodes may be fixed or mobile, and operate with a node availability value ranging from lowest latency to longest battery life.
An Iocast network includes one Linux-based control stack, along with base transceivers, application servers, and nodes. The network establishes data communication between nodes and application servers, enabling each to exchange datagrams with the other. Nodes connect to an Iocast system using node transceivers, while application servers connect using the Iocast API.
Node. An Iocast node is a wireless low-power object that connects to an Iocast system and communicates through that system with its application server. Example nodes include patient monitors, intrusion alarms, and vehicle tracking systems. Iocast nodes may be fixed or mobile, and operate at various power levels optimizing battery life or performance.
System. An Iocast system includes a control stack plus one or more base transceivers, and it facilitates communication between nodes and application servers. Systems may range in size from one building to nation-wide, and may connect to each other to facilitate roaming. An Iocast system is identified by its System ID.
Application Server. An application server is a software or service platform that connects to an Iocast system by way of a the Iocast API. An application server communicates with its nodes to create a complete wireless application (e.g. a SCADA system or a clinical alarm manager).
Datagrams. Iocast communications are based on datagrams, binary messages transmitted between nodes and their application servers. Application servers can send forward datagrams to a single node (unicast) or to multiple nodes through a multicast address (multicast). Nodes transmit reverse datagrams to their application servers, either as unsolicited requests or in response to forward datagrams. Iocast datagrams range in size from 1 byte to 8,160 bytes.
Control Stack. A control stack is the real-time software and database required to support the Iocast air protocol and Iocast API. The control stack includes subscriber data, node connection data, datagram queues, base transceiver control, administrative interfaces, and APIs. The control stack, together with base transceivers, forms the fixed part of an Iocast system.
Base Transceiver (BX). An Iocast base transceiver is a powerful, fixed radio that transmits data to node transceivers on forward channels and receives data from nodes transceivers on reverse channels. Base transceivers are always-on devices that connect to a control stack using the Base Transceiver Interface (BXI). Base transceivers are identified by their BX ID, which is unique within a sector.
Channel. An Iocast channel is a narrowband RF channel used to transmit datagrams. Channels include forward channels and reverse channels. Node transceivers transmit to base transceivers using forward channels, while base transceivers transmit to node transceivers using forward channels.
Sector. A sector describes a geographical area of coverage, including one or more base transceivers and two or more channels. A sector may contain as many as 4 forward channels and 4 reverse channels, and is identified by its Sector ID, which is unique per system. A node must connect to a sector before sending and receiving datagrams. The connection process includes mutual authentication of the node and home system, using a shared private key.
Node Transceiver (NX). A node transceiver (NX) is a digital radios that connects a node to an Iocast network. Node transceivers autonomously handle scanning, sector connection, authentication, and protocol details, and operate with a node availability value (na) describing how often they listen for forward datagrams. Node transceivers include one primary address and up to 16 multicast addresses, all globally unique, coordinated values that serve as both MAC and wide area addresses. Nodes are uniquely identified by their 64-bit node equipment identity value.
Node Availability (na). Node transceivers operate with a node availability value (na), which describes how often they listen for forward datagrams. The na value ranges from 0 (lowest forward datagram delivery latency) to 9 (longest battery life). Node availability does not affect a node's reverse datagram performance. A node may transmit a reverse datagram asynchronously, at any time, regardless of its node availability setting.
The Iocast API includes 11 methods (see the proto file here). It is designed to enable communication between an application server and its nodes, including limited support of node and group configuration. The API does not provide the ability to manage an Iocast system or provision nodes; these functions require other product-specific interfaces and processes. However, it does provide a powerful pathway for building a wide variety of wide area applications.
The Iocast Node Transceiver Interface (NXI) provides a dedicated hardware/software connection between a node controller and its node transceiver.
The controller communicates with the transceiver through a 7-wire interface, which includes handshake lines to establish a session, and an I²C-based link for reading and writing multi-byte registers to perform various real-time functions. NXI is designed to allow both the node controller and node transceiver to enter static low-power states asynchronously, according to their own requirements. This enables the node overall to operate while consuming the lowest possible average power.
The Iocast Air Interface is a synchronous bidirectional protocol comprising OSI layers 1 through 4. Its physical layer is similar to P25 and Digital Mobile Radio, while its higher layers are optimized for low-latency data communications and long battery life.
The Iocast air protocol provides OSI layers 1-4, creating a secure tunnel between each node and its application server. This tunnel, called a secure datagram path, extends from the node, through the sector and control stack, to the application server, which completes the stack by providing layers 5-7. While secure datagram paths are authenticated, established, and secured using strong shared key encryption, additional encryption may be implemented by nodes and application servers as appropriate.
Node transceivers and base transceiver communicate using RF channels, which are organized into sectors. Each sector includes 2-8 such channels, including at least one forward channel and one reverse channel. All forward channels in a sector are effectively simulcast together, transmitting data and providing synchronization and coordination. Return channels are shared between nodes using slotted ALOHA and deterministic scheduling from the control stack.
The Iocast physical layer uses 4-level FSK modulation and transmits 9,600 bits per second, similar to digital mobile radio standards. Iocast symbols and frames align precisely to GPS time, with forward channels providing synchronization for reverse channels. The data link layer, which mostly comprises a MAC sublayer, includes both controller-driven scheduling and slotted ALOHA. The network and transport layers divide datagrams into packets and transmits them using FEC along with selective-repeat ARQ and HARQ protocols.
Iocast node and base transceivers transmit 4-level FSK (emissions designator 7K60FXD). This type of modulation is generally compatible with narrowband RF spectrum described in 47 CFR Parts 22, 24(D), 90, and 101.
These spectrum allocations are divided into distinct forward and reverse channel types, which map directly into the Iocast architecture. Base transceivers transmit data to node transceivers using forward channels, while node transceivers transmit data to base transceivers using reverse channels.
Reverse channels are time-shared between node transceivers while forward channels are always on under control of a base transceiver or set of base transceivers. Forward and reverse channels are universally synchronized together, with the control stack providing coordination, timing, and access arbitration.
Iocast organizes channels into sectors, the basic Iocast coverage unit. A sector may be as small as a building or campus, or as large as a county, and may include multiple channels and base transceivers. Nodes must connect to a sector, authenticating both the node and the home system, before transmitting or receiving datagrams. A sector includes one or more base transceivers and two or more channels. Sectors are identified by their Sector ID.
Iocast sectors do not require strict 1:1 channel pairing and may be asymmetric. For example, a sector designed for a metering application may include one forward channel coupled with three reverse channels. Alternatively, a large-scale alerting application may require two forward channels coupled with one reverse channel for alerting and dispatch applications.
Application servers send forward datagrams to their nodes and groups, while nodes send reverse datagrams to their application servers. A node may at any time transmit a reverse datagram to its application server. Similarly, an application server may at any time transmit a forward datagram to its nodes or groups, although forward datagrams may wait in queue depending on the node's node availability setting (below).
Forward datagrams are addressed to a single node's primary address (unicast) or a group address (multicast). Forward datagrams have no explicit return address as they always originate from the recipient's application server. Likewise, reverse datagrams have no explicit destination address as they are always directed to the node's application server. Datagrams are delivered in the order they're sent, per node or group address.
Datagrams are additionally categorized into unsolicited and response datagrams. Response datagrams are sent in response to a prior unicast or multicast datagram, while unsolicited datagrams have no such association. Datagrams range in size from 1 byte to 8,160 bytes in the air interface; however, their size may be further restricted through on a per-node or per-group basis at the NXI and API level.
The node availability setting determines how often a node wakes up to receive forward datagrams. This value affects both the node's average power consumption and the length of time required to deliver forward datagrams. Nodes that require low latency (e.g., station alerting units) may be configured to receive datagrams quickly, at the cost of increased power consumption. Nodes that require long battery life (e.g., perimeter sensors), may be configured to receive datagrams infrequently.
Node availability does not affect a node's reverse datagram performance. A node may transmit a reverse datagram asynchronously, at any time, regardless of its node availability setting.
Node transceivers scan a list of frequencies as they operate, detecting available sectors and connecting to those with the best available signal strength. Iocast's synchronous architecture makes this process particularly efficient in terms of both time and battery usage, and does not impact datagram performance. This conferring a great deal of mobility to nodes regardless of their node availability setting.
Each time a node connects to a new sector, it re-authenticates, thus keeping the secure datagram path intact. Sector-to-sector mobility is handled by the node transceiver and control stack, largely transparently to nodes and application servers.
As they scan their list of frequencies, nodes are also mindful of systems authorized for connection. This capability extends an Iocast node's mobility into inter-system roaming.
Each time a node connects to a new system, it re-authenticates, thus keeping the secure datagram path intact. Roaming is handled by the node transceiver and control stack, largely transparently to nodes and application servers.