18 SDN for IoT: WSN and Mobile Variants

18.5.1 Historical WSN Control Surfaces

Sensor OpenFlow and Soft-WSN are useful because they make “programmable sensor network” concrete. A value-centric rule matches the observation, such as temperature > 40 °C, and forwards an event because of what it means. An ID-centric rule matches the originating node and forwards because source_id = pump-17. The first supports in-network event selection; the second preserves source-specific routes, permissions, and diagnostics. In either case the rule needs priority, lifetime, units, invalid-value behavior, and a local fallback.

Soft-WSN broadened the control surface beyond forwarding:

The last distinction is easy to miss. A rule installed at node A is not necessarily node-specific in effect; “all nodes drop source X” is network-wide policy and needs coordinated versioning. Likewise, selecting a sensor can change payload size and downstream queue pressure, so control surfaces cannot be approved independently.

One reported Soft-WSN experiment showed packet-delivery ratio near the mid-90% range while a comparison WSN varied around roughly 40–50%, and showed far fewer replicated data packets. The same experiment showed more control messages for Soft-WSN. Those plot values are historical results for one setup, not performance guarantees. They expose the engineering exchange: controller knowledge can reduce wasteful data replication and improve chosen paths, but only by paying synchronization and miss-handling overhead. Re-run the comparison with radio-on time, useful delivered bytes, control bytes, drops, and energy per useful report.

Figure 18.1 compresses this subsection into one review sheet: the four controller levers on top, and beneath them the three meters that decide whether pulling a lever actually paid.

The rail in Figure 18.1 fans the controller’s policy view out to four levers — Sensor selection, Sensing delay, Active/sleep state, and Forwarding scope — each phrased as one concrete, evidence-bearing action, such as moving sampling from 60 s to 10 s or waking two relays on a threatened route. The meter panel repeats the historical result as an honest trade: delivery near the mid-90s and duplicates collapsing while Control msgs roughly quadruple. Read those bars as illustrative shapes rather than guarantees; the durable obligation is the amber line — meter all three quantities on the same clock, before and after any lever is pulled.

18.5.2 SDN-WISE Node Pipeline

An SDN-WISE-style node places programmability inside a constrained IEEE 802.15.4 device. Read the node from the radio upward:

1. The 802.15.4 radio and MAC receive a frame, validate link-layer framing, and expose source, destination, type, and payload to the MCU.
2. A flow-rule forwarding layer above the MAC evaluates match fields plus node state. A hit applies actions such as forward, drop, modify state, or invoke a processing function.
3. In-Network Packet Processing (INPP) performs a bounded local operation—aggregation, thresholding, state update, or packet transformation—without a controller round trip.
4. On a miss, the node sends a PACKET_IN-style control message toward the controller and follows a bounded local policy while waiting.
5. The returned rule is validated, inserted with priority and timeout, and then used for the buffered packet and later matches.

Those five steps hold together better as a picture. Figure 18.2 stacks the node the way the frame experiences it, then splits on the only decision that costs radio: hit or miss.

The stack at the top of Figure 18.2 places the Flow-rule layer directly above the 802.15.4 radio + MAC, with INPP available for bounded local work. A hit resolves inside the node for 0 control bytes spent; a miss buffers the packet and sends a PACKET_IN across h radio hops, and only after the returned rule is validated and installed does the buffered packet leave — from then on the same match is a local hit. The Miss tax card restates this subsection’s formula, and it names the quantity to bound before believing any in-network processing saving.

Unknown packets are not free. If miss rate is $\lambda_m$ and the routed control exchange costs $b_{in}+b_{rule}$ bytes over an average $h$ radio hops each way, offered control traffic is approximately

before MAC headers, acknowledgements, retransmissions, or state synchronization. A simple radio-energy estimate is

which reminds us that relays pay too. In a dense low-power network, a rule miss can consume energy at several nodes even when no application data is delivered.

Bound the pipeline with a small default table, maximum rule count, maximum INPP runtime, miss retry/backoff, authenticated rule origin, and behavior during controller loss. Measure control/data byte ratio, radio-on time, rule-hit ratio, insertion failure, local processing latency, and useful delivery. Stateful local processing is valuable only when it saves more communication and delay than its memory, computation, and synchronization cost.

18.5.3 Mobile Access Control Mechanisms

ODIN separates an agent at each access point from a master at the controller. The agent handles 802.11 frames and enforces client-specific state; the master coordinates policy and mobility. A light virtual access point (LVAP) is a per-client logical AP context—client identity, BSSID/SSID association context, policy and forwarding attachment, plus the security/session material the implementation explicitly supports. Keeping it per client lets state move without pretending the physical AP moved.

For a new client, the serving agent checks whether an LVAP exists. Known data frames are forwarded under that context; an unassigned frame is not silently bridged. For relevant management frames without an LVAP, the agent asks the master. The master authenticates/authorizes the request, assigns an LVAP, sends it to the agent, and only then permits normal processing.

A hand-off should be ordered:

1. Detect a candidate target AP from measured link and load evidence; do not move on RSSI alone.
2. The master checks that target policy and capacity can host the client.
3. Install the LVAP and downstream path at the target, retaining a version and acknowledgement.
4. Switch client delivery to the target and verify receiver/session continuity.
5. Remove or expire old-agent state; late frames and duplicate delivery need explicit handling.
6. Record hand-off latency, loss, stale-state duration, and rollback if the target fails.

Ubi-Flow adds a regional scaling sequence. First partition APs and switches into controller regions so no controller owns an unbounded wireless estate. Next match a moving client and required service to an eligible region/controller using location, policy, and reachability. Then load-balance within or across allowed regions using controller load, AP capacity, path cost, and failure-domain constraints. On cross-region movement, transfer the minimum fresh state, pre-install the new path, and clean up both data-plane and controller ownership. Partitioning without an overlap/partition-failure rule merely moves the outage boundary.

Both mechanisms fit one page once they are drawn as state movements. Part A of Figure 18.3 replays the ODIN assignment as a two-lane exchange; part B shows the UbiFlow estate a client moves across.

In part A of Figure 18.3, follow the two lifelines downward: the AP agent holds an unassigned frame rather than silently bridging it, asks the Ctrl master, and installs the returned LVAP before normal processing resumes — from that point the client’s identity, association context, policy, and path exist as portable state. Part B moves that state across an estate: Region 2 · C2 hosts the crossing because A3 · chosen beats the loaded A4, rules wait before the client lands, and step 5 expires A2’s stale copy after a grace period. The caution names the part reviews usually skip — partitioning without an owner for the client mid-crossing merely relocates the outage.

18.5.4 Mobi-Flow Prediction and Rule Placement

Mobi-Flow turns recent attachment history into proactive rule placement. For an Order-$K$ Markov predictor, the state at time $t$ is the last $K$ locations,

and transition counts estimate

$\alpha>0$ is optional smoothing so an unseen transition is not assigned impossible probability. With $K=2$, if history (AP-A, AP-B) was followed by AP-C six times and AP-D twice, the unsmoothed next-location vector is 0.75 for C and 0.25 for D. Higher $K$ can capture a route but fragments the evidence into sparse histories, so validate prediction accuracy by confidence band and time of day rather than always increasing order.

Prediction does not itself select where rules should be installed. Let binary $x_j$ mean “pre-place at AP $j$.” One useful optimisation is

subject to

plus authorization, path, and failure-domain constraints. $p_j$ is predicted attachment probability, $B$ is the pre-install rule budget, and $r$ is the rule/resource cost. The linear program may choose both C and D when their combined avoided-miss cost exceeds install cost, or only C when TCAM and energy are tight.

Run the mechanism as a controlled loop: observe the new location, update the $K$-state history, produce probabilities and confidence, solve the bounded placement problem, install rules at selected APs, confirm acknowledgements, perform the hand-off, then remove unused/stale rules after a short grace period. If the user attaches somewhere unpredicted, fall back to reactive placement without blocking the session. Track top-$n$ prediction accuracy, proactive hit rate, unused-rule fraction, TCAM occupancy, control bytes, hand-off loss, and energy. Historical plots reported lower control overhead and energy than conventional reactive placement as node count rose; only a repeatable local benchmark can show whether prediction, extra state, and cleanup deliver that advantage here.

Figure 18.4 runs that controlled loop once with this subsection’s own numbers, from the $K=2$ history to the cleanup that keeps the next prediction honest.

Steps 1-3 at the top of Figure 18.4 turn the history (AP-A, AP-B) into P(C)=0.75, P(D)=0.25 from six-of-eight past continuations, then spend the rule budget on C alone unless capacity allows D as well. Steps 4-5 are the operational half — Pre-install, then hand off with acknowledgements confirmed, and Clean up after a grace so stale rules cannot mislead the next decision — while the red strip protects the session when the prediction is simply wrong. The indexed bars, control bytes at 62 and energy at 71 against a reactive 100, are shapes from one historical setup; the amber line lists the counters that would prove or refute them on your network.