The control stack serves as the "brain" of an iocast network. It includes two software services, conceptually arranged into a two-component stack. The top component, called the home controller, manages high-level network functions such as message queues and API connections. The bottom service, called the sector controller, manages low-level details concerning base transceivers and the air protocol.

The home controller is roughly analogous to a cellular network's Home Location Register (HLR), including a database of node rows, datagram queues, and the API servers. The sector controller is roughly analogous to a Mobile Switching Center (MSC), including a visitor location register, air queues, and real-time logic to control the air protocol for one or more sectors.

The inputs of a home controller are its API connections from application servers, and its outputs are Sector Client Interface (SCI) connections to sector controllers. SCI passes connection requests and reverse datagrams from the sector controller to the home controller. Likewise, SCI passes forward datagrams and supervisory requests from the home controller to the sector controller.

The inputs of a sector controllers are its SCI connections from home controllers, and it's outputs are Base Transceiver Interface (BXI) connections to BXs. BXI sends forward frames and reverse channel scheduling information from the sector controllers to BXs. Likewise, BXI sends reverse packets from BXs to the sector controller. BXI also allows the sector controller to account for variable latency when using satellite connections, and it supports flexible reverse channel diversity and reverse channel reuse algorithms.

For small to medium-sized networks, the control stack may exist as one home controller and one sector controller operating on one physical server computer. However, larger networks may include multiple sector controllers and multiple home controllers. Furthermore, home controller may make SCI connections to sector controllers of other networks in order to facilitate inter-system node roaming.

Iocast operates using narrowband (12.5KHz) radio channels. Base transceivers transmit data to node transceivers using forward channels, while node transceivers transmit data to base transceivers using reverse channels. Node and base transceivers use modulation compatible with 47 CFR Parts 22, 24(D), 90, and 101 (emissions designator 7K60FXD), and transmit a raw rate of 9600 bits per second.

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.

Channels are organized into sectors, which include at least one forward channel and one reverse channel, but which may include up to four forward and four reverse channels. 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.

Transmission symbols and frames align precisely with GPS time, with forward channels providing synchronization for reverse channels. The data link layer includes both controller-driven scheduling and slotted ALOHA media access. The network and transport layers divide datagrams into packets and transmit them using forward error correction along with selective-repeat ARQ and HARQ.

Iocast organizes channels into sectors. A sector may be as small as a building or campus, or as large as a country, and may include multiple channels and base transceivers. Nodes must connect to a sector before transmitting or receiving datagrams. The connection process mutually authenticates the node and control stack to each other. Sectors are identified by their 16-bit sector identification value secid and operate under control of one control stack. Sectors may be globally referenced in dot decimal form as sysid.secid.

In the above illustration, a control stack, sysid 23, operates 3 sectors and six base transceivers. The sectors include secid 23 (23.1), with simulcasted BXs 23.1.1, 23.1.2, and 23.1.3; secid 2 (23.2) with simulcasted BXs 23.2.1 and 23.2.2; and secid 3 (23.3) with BX 23.3.1. The nodes, shown as white circles, are able to move freely between the three sectors, connecting to each as necessary as they pass through.

Each sector can include up to four forward channels and four reverse channels; however, they do not require strict 1:1 forward/reverse channel pairings. For example, a sector designed for a metering application may include one forward channel coupled with three reverse channels. Alternatively, a large-scale alerting or dispatch application may require two forward channels coupled with one reverse channel.

A node's node availability setting (na) 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.

Simularly, a group's group availability setting (ga) determines how often a node must wake up to receive a multicast message. For nodes that are members of a group, this value affects their average power consumption and the length of time required to deliver multicast datagrams to the group.

Node availability and group availability do not impact a node's reverse datagram performance. A node may transmit a reverse datagram asynchronously, at any time, regardless of its availability settings.

Node transceivers scan a list of frequencies as they operate, detecting available sectors and connecting to those with the best available signal strength. Because of the synchronous nature of iocast, this process is particularly efficient in terms of both airtime and battery use, and it does not impact datagram performance.

Each time a node connects to a new sector, it re-authenticates to maintain a secure link to its control stack intact. Sector-to-sector mobility is handled by the node transceiver and control stack, largely transparently to nodes and application servers.

With proper authorizations, nodes are able to move between sectors of different systems, thus enabling inter-system roaming.

Each time a node connects to a new system, it re-authenticates to maintain the secure link to its own control stack. Inter-system mobility is handled by the node transceiver and control stacks of the its roaming and hme system, largely transparently to nodes and application servers.

The Node Transceiver Interface (NXI) provides a dedicated hardware/software connection between a node controller and 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 to operate while consuming the lowest possible average power.

The API allows application servers (clients) to connect to control stacks (servers). Once connected, clients send datagrams to nodes and group, receive datagrams from nodes, and manage their nodes and groups.

The API is based on gRPC and includes 13 methods (see the proto file here).