9 ZRP Routing: Zones and Bordercast

9.1 Overview

This first route builds ZRP from local zones through bordercast discovery and a checkable radius calculation.

This is part 1 of 2. Continue with ZRP Routing: Tuning and Deployment for the second focused route.

9.2 Start Simple

Move the Destination Just Beyond the Zone

Picture a rescue sensor that knows nearby paths but must find a moving team outside that area. A protocol means the agreed rules and message order devices follow to exchange information.

Name the source, local zone, zone radius, border nodes, destination, and search rule. Test a nearby destination, one just outside the zone, a broken border link, and a larger radius.

Keep route requests, replies, path length, control traffic, delay, and failures. This proves one network shape and traffic pattern, not universal efficiency; the deeper sections compare local upkeep, wider search, radius choices, and maintenance.

Start with devices that have to pass useful data before any fixed network is guaranteed. In ZRP Hybrid Zone Routing, the first question is not the protocol name; it is which neighbors, routes, failure signals, and degraded behaviors you would trust in the field.

9.3 Start With the Local Zone

ZRP starts from a compromise: keep nearby routes ready, but do not flood the whole network until a destination falls outside the local zone. The zone radius turns routing strategy into a design choice.

For IoT teams, that choice balances local speed against control overhead. Start with one node’s neighborhood, decide how far proactive knowledge should reach, and then trace what happens when the destination is just beyond that boundary.

9.4 Learning Objectives

By the end of this chapter, you will be able to:

• Explain ZRP Architecture: Describe how Zone Routing Protocol combines proactive and reactive approaches with its three components (IARP, IERP, BRP)
• Design Zone Configurations: Select appropriate zone radius values for different network characteristics and justify the choice
• Analyze Intra-Zone Routing: Explain proactive table maintenance within each node’s zone and calculate zone size
• Apply Inter-Zone Routing: Demonstrate reactive discovery for destinations outside the zone using bordercast
• Evaluate Hybrid Trade-offs: Assess routing overhead, latency, and scalability trade-offs in ZRP networks
• Compare Protocol Classes: Choose between proactive, reactive, and hybrid protocols for specific scenarios and defend the selection

9.5 Prerequisites

Before diving into this chapter, you should be familiar with:

• Ad Hoc Routing: Proactive (DSDV): Understanding DSDV’s table-driven approach is essential because ZRP uses proactive routing within zones, making DSDV concepts directly applicable to intra-zone routing
• Ad Hoc Routing: Reactive (DSR): Knowledge of DSR’s on-demand route discovery is critical because ZRP employs reactive routing for inter-zone communication, building on DSR’s flooding and route caching mechanisms
• Multi-Hop Fundamentals: Multi-hop networking concepts underpin ZRP’s zone structure, as zone radius is defined in hops and border nodes forward queries across multiple hops
• Networking Basics: Fundamental networking concepts like routing tables, hop counts, and packet forwarding are prerequisites for understanding how ZRP combines proactive and reactive strategies

9.6 For Beginners: Hybrid Routing (ZRP)

Imagine planning routes in your city. For nearby places (your neighborhood), you keep routes in your head constantly. For distant places (across the city), you only look up directions when needed. Zone Routing Protocol (ZRP) combines both strategies - the best of proactive and reactive routing!

The Goldilocks Protocol:

• Proactive (DSDV): Too much overhead (maintains routes to everywhere continuously)
• Reactive (DSR): Discovery delay for every communication
• Hybrid (ZRP): Just right! Maintains routes only to nearby nodes, discovers distant routes on-demand

How ZRP Works: The Neighborhood Concept

Each node defines a “zone” around itself (like knowing your neighborhood well):

• Zone Radius: Distance in hops defining your neighborhood (typically 2-3 hops)
• Inside Zone: You maintain routes proactively (like knowing every house on your block)
• Outside Zone: You discover routes reactively only when needed (like looking up distant addresses)

Example with Zone Radius = 2:

Node A’s zone includes all nodes within 2 hops:

• 1-hop away: Direct neighbors B, C (always know how to reach them)
• 2-hops away: Neighbors’ neighbors D, E (proactively maintain routes)
• 3+ hops away: F, G, H (discover routes only when needed)

Result: A maintains ~10-12 routes instead of 100 routes (saves 90% memory and overhead!)

Key terms in plain language:

• Zone routing: combine proactive nearby routes with reactive distant discovery, like knowing your neighborhood and using a map for trips across town.
• Zone radius: the local neighborhood size in hops, such as “everyone within 2 hops.”
• Intra-zone routing: proactive routing inside the zone, like knowing all nearby streets.
• Inter-zone routing: reactive routing outside the zone, like looking up directions to another neighborhood.
• Border nodes: nodes at the edge of the zone, like houses on the corner of a block.
• Bordercast: send queries only to border nodes instead of asking the whole network.

The Smart Discovery Process:

When A needs to send to distant node H:

1. Local Check: A checks zone table - “H not in my zone”
2. Bordercast: A sends query to border nodes (D, E) - not full network flood!
3. Border Propagation: D and E check their zones - “Not here either”
4. Zone Overlap: Eventually query reaches zone containing H
5. Local Delivery: That zone delivers to H using proactive routes
6. Reply: Route sent back to A

Comparison:

• DSDV maintains routes to all nodes. It has high idle overhead and high memory use, but no discovery delay.
• DSR maintains no proactive routes. It has low idle overhead, but every new destination needs discovery.
• ZRP maintains only nearby zone routes. It keeps nearby latency low while using reactive discovery for distant nodes.

Zone Radius Selection - The Critical Choice:

Small Zone (radius=1):

• Pros: Low proactive overhead (few nodes), low memory
• Cons: Frequent discoveries (most destinations outside zone)
• Best for: Sparse networks, infrequent communication

Large Zone (radius=5):

• Pros: Most destinations in zone, fewer discoveries
• Cons: High proactive overhead, large routing tables
• Best for: Dense networks, frequent communication

Optimal (radius=2-3):

• Balances both approaches for most IoT networks
• ~10-20 nodes per zone in typical mesh

When to Use ZRP:

Good fit:

• Medium to large IoT networks (100-1000 nodes)
• Clustered topology (sensors grouped around gateways)
• Mixed traffic patterns (frequent local, occasional distant)
• Moderate mobility where zones can still remain useful

Poor fit:

• Very small networks where DSR is simpler
• Very large dense networks where zone maintenance becomes too expensive

Why This Matters for IoT:

Many IoT deployments have clustered communication patterns - sensors talk frequently to nearby devices and their local gateway, but rarely to distant sensors. ZRP perfectly matches this pattern: fast local communication (proactive) + efficient distant communication (reactive) + lower overhead than pure proactive!

Checkpoint: Hybrid Frame

You now know:

• ZRP is the middle path between DSDV’s continuous everywhere table and DSR’s discovery for every new destination.
• The local design question is radius: radius 1 is mostly reactive, radius 2-3 is the usual sweet spot, and radius 10 can become proactive again.
• In the beginner example, a node tracks about 10-12 nearby routes instead of 100 routes, saving about 90% of the local table work.

The opening sections defined the hybrid idea. The next sections trace which component knows the route, which component searches, and how border nodes bound the query.

9.7 Zone Routing Protocol (ZRP)

Zone Routing Protocol (ZRP) combines proactive and reactive approaches to balance their trade-offs.

9.7.1 ZRP Concept

ZRP divides the network into zones centered on each node:

ZRP is hybrid because one configured radius separates maintained knowledge from on-demand discovery. Inspect Figure 9.1 to make that boundary concrete before reasoning about overhead or route delay.

At the centre of the diagram in Figure 9.1, source A keeps IARP local routes through the 1-hop local zone and out to the rho = 2 border zone. A destination beyond those border nodes invokes IERP bordercast instead of global proactive state. The local/distant split is the mechanism the later radius decision must tune from traffic locality and measured control cost. A larger radius shifts work toward IARP maintenance; a smaller radius makes more destinations pay the IERP discovery path.

With the boundary understood, follow Figure 9.2 from the destination lookup. Check the in-zone branch first, then the bordercast branch, and finish at the feedback paths that signal an oversized or undersized zone.

Figure 9.2 shows that ZRP does not apply both routing modes to every packet. A known local destination uses the maintained IARP route immediately; an external destination triggers IERP discovery through border nodes. The tuning feedback connects observed overhead and discovery delay back to radius selection, so the hybrid balance is measured rather than assumed.

Now compare that behaviour with the two limiting strategies in Figure 9.3. Read the DSDV column for always-ready global state, the DSR column for on-demand state, and the ZRP column for the local-versus-distant split.

In Figure 9.3, DSDV trades higher idle overhead for immediate route availability, while DSR avoids that standing cost but pays discovery latency for new destinations. ZRP deliberately occupies the middle: it spends state on frequently useful local routes and accepts discovery for distant ones. The comparison reconnects the three diagrams to the running design question—choose and retune the zone radius from traffic locality, mobility, and measured control cost.

Zone Definitions:

Intra-Zone (Proactive): : Within zone radius, maintain routes proactively using table-driven protocol (like DSDV)

Inter-Zone (Reactive): : Beyond zone, use on-demand route discovery (like DSR)

Zone Radius: : Configurable parameter ρ (rho) defining zone size in hops

Putting Numbers to It

ZRP zone size estimation: In a mesh with average degree d = 5, each extra hop adds another layer of neighbors. A practical estimate is: start with the source node, add the direct neighbors, then add each next hop after accounting for overlap. Worked example:

• rho = 1: about 5 nodes
• rho = 2: about 25 nodes
• rho = 3: can approach 100 nodes in a 100-node network

If rho = 3 already covers nearly the full network, ZRP degenerates toward pure DSDV and loses its hybrid benefit. IoT deployments usually start with rho = 2 or rho = 3, then tune from measured traffic locality.

9.7.2 ZRP Components

Before ZRP Components, inspect Figure 9.4 to compare “Inter-zone routing” with “IERP”. Their juxtaposition makes block diagram showing the three ZRP components: IARP maintaining proactive intra-zone tables, IERP discovering inter-zone routes on demand, and BRP directing route requests to border nodes visible.

Read Figure 9.4 from “Inter-zone routing” to “IERP”. Taken together, “Inter-zone routing” and “IERP” express block diagram showing the three ZRP components: IARP maintaining proactive intra-zone tables, IERP discovering inter-zone routes on demand, and BRP directing route requests to border nodes. For ZRP Components, the observed relationship between “Inter-zone routing” and “IERP” is evidence that “Inter-zone routing” carries into the next decision.

IARP (Intra-zone Routing Protocol):

• Proactive protocol within zone
• Nodes exchange periodic updates
• Maintain routes to all nodes within ρ hops
• Example: Modified DSDV with limited hop count

IERP (Inter-zone Routing Protocol):

• Reactive protocol for distant nodes
• Route requests propagated via border nodes
• Similar to DSR but leverages zone structure

BRP (Bordercast Resolution Protocol):

• Efficient query propagation
• Route requests sent only to zone border nodes
• Reduces flooding overhead

9.7.3 ZRP Operation Example

Scenario: Node A needs to communicate with Node H

Before ZRP Operation Example, inspect Figure 9.5 to compare “3. BRP bordercast RREQ” with “A’s IARP zone”. Their juxtaposition makes sequence diagram showing ZRP inter-zone discovery: source A checks IARP, sends a BRP bordercast to edge nodes, border zones continue the search, and destination H replies through the discovered path visible.

Read Figure 9.5 from “3. BRP bordercast RREQ” to “A’s IARP zone”. Taken together, “3. BRP bordercast RREQ” and “A’s IARP zone” express sequence diagram showing ZRP inter-zone discovery: source A checks IARP, sends a BRP bordercast to edge nodes, border zones continue the search, and destination H replies through the discovered path. For ZRP Operation Example, the observed relationship between “3. BRP bordercast RREQ” and “A’s IARP zone” is evidence that “3. BRP bordercast RREQ” carries into the next decision.

Step-by-Step:

1. Local lookup: A checks IARP table (proactive zone routes)

   • H not within zone radius

2. Bordercast: A sends RREQ to zone border nodes (not full flood)

   • Border nodes: B, C, D

3. Border propagation: Border nodes check their zones

   • If H not found, forward RREQ to their borders

4. Zone overlap: Eventually RREQ reaches zone containing H

   • That zone’s node uses IARP to reach H locally

5. Route reply: RREP sent back to source

6. Data transmission: Source uses discovered route

Smart Campus ZRP Radius

Scenario: A university deploys 200 IoT sensors across a campus for environmental monitoring. Sensors communicate frequently with nearby peers (within buildings) but occasionally need to reach sensors in distant buildings.

Given:

• 200 nodes across 5 buildings
• Average node degree: 6 neighbors per node
• 70% of communication is local (same building)
• 30% of communication is cross-building (distant)
• Battery-powered sensors (energy efficiency critical)

Steps:

1. Estimate nodes per zone radius:

   • ρ=1: ~6 nodes (direct neighbors only)
   • ρ=2: ~6 + (6×5) = 36 nodes (accounting for overlap ~25 nodes)
   • ρ=3: ~75-100 nodes (approaching building-wide coverage)

2. Analyze traffic patterns:

   • 70% local traffic → most destinations should be in-zone
   • Average building has 40 nodes
   • ρ=2 covers ~25 nodes (62% of building) - insufficient
   • ρ=3 covers ~75 nodes (covers full building) - matches traffic pattern

3. Calculate overhead trade-off:

   • ρ=2: Proactive for 25 nodes, reactive for 175 (many discoveries)
   • ρ=3: Proactive for 40 nodes, reactive for 160 (fewer discoveries)
   • Cross-building: 30% traffic × reactive discovery overhead

Result: Zone radius ρ=3 is optimal because:

• Covers entire buildings proactively (matches 70% local traffic)
• Only cross-building communication (30%) requires reactive discovery
• Proactive overhead: 40 entries (acceptable for campus sensors)

Key Insight: Match zone radius to your communication locality. If most traffic is within a certain hop range, set ρ to cover that range proactively. The campus’s building-clustered topology made ρ=3 ideal for intra-building coverage.

Campus Radius Review Record

A ZRP release record should show why the selected radius fits the topology instead of copying a default value. Record traffic locality, typical hop distance, cross-building discovery rate, alarm-latency target, route-table entries, IARP update volume, memory use, battery impact, and the evidence that will trigger retuning, such as zone size above 60 percent of the network, discovery rate above target, mobility churn, or battery drain beyond budget.

Bordercast Route Discovery

Scenario: Node A needs to send critical alarm data to Node H (fire detected). Calculate the route discovery overhead comparing ZRP bordercast versus full network flood (DSR-style).

Given:

• Network: 100 nodes, average degree 5
• Zone radius ρ=2
• Node A has 4 border nodes (B, C, D, E)
• Each border node has 3-4 external connections
• H is 5 hops away from A

Steps:

1. Calculate DSR-style full flood:

   • RREQ flooded to all 100 nodes
   • Each node rebroadcasts once: 100 transmissions
   • Network-wide overhead: 100 RREQ packets

2. Calculate ZRP bordercast:

   • A sends RREQ to 4 border nodes only (not all neighbors)
   • Border nodes check their zones (4 nodes × 25 zone members = 100 lookups, but local)
   • H not found → bordercasting continues from border of border
   • Tier 1: 4 bordercasts
   • Tier 2: 4 borders × 3 external connections = 12 bordercasts
   • Tier 3: H found in zone of tier-2 border node
   • Total: 4 + 12 + local lookup = ~16 transmissions

3. Compare overhead:

   • DSR: 100 transmissions (full flood)
   • ZRP: 16 transmissions (bordercast)
   • Savings: 84% reduction in discovery overhead

Result: ZRP discovered route to H with only 16 messages vs 100 for full flooding.

Key Insight: Bordercast efficiency comes from leveraging zone knowledge - each border node already knows its zone members proactively, so inter-zone discovery only floods between zones, not within them. The larger the zones relative to network size, the greater the savings.

9.9 Continue to Part 2

Continue with ZRP Routing: Tuning and Deployment.