Chapters

15 DTN Social Routing: Community and Forwarding Decisions

emerging-paradigms
adhoc
dtn
social

15.1 Start With the Decision

A popular node is not always the best carrier for a given community. Social routing must balance group relevance, spread, and delivery cost.

15.2 Route Overview

This is part 2 of 2. Review DTN Social Routing: Contact and Utility Models for the preceding evidence.

15.3 Learning Objectives

  • Explain community-aware SocialCast forwarding.
  • Evaluate social metrics and replication trade-offs.

15.4 Chapter Roadmap

  • SocialCast: Social-Based DTN Routing
  • Figure Summary: SocialCast Workflow
  • Figure Summary: Gamma Trade-off
  • SocialCast Utility Calculation
  • Checkpoint: SocialCast Discipline
  • Test Your Understanding
  • Answer
  • Answer
  • Answer
  • SocialCast Utility Function Explorer
  • SocialCast Advantages for IoT
  • Knowledge Check
  • Quiz: SocialCast Protocol
  • Community Mesh Routing
  • Case Study: Community-Managed Mesh Links
  • Concept Relationships
  • See Also
  • Interactive Quiz: Match Concepts
  • Interactive Quiz: Sequence the Steps
  • Common Pitfalls
  • Social Contacts Are Not Stable
  • Social Centrality Without Full Map
  • Social Routing Beyond Humans
  • Contact Tracking Privacy Risks
  • Label the Diagram
  • Code Challenge
  • Summary
  • What’s Next
  • Key Takeaway

15.5 SocialCast: Social-Based DTN Routing

Time: ~15 min | Difficulty: Advanced | Unit: P04.C01.U04

Before socialCast: Social-Based DTN Routing, inspect Figure 15.1 to compare “Publisher” with “Carrier A”. Their juxtaposition makes socialCast bounded-replication workflow for DTN publish-subscribe delivery visible.

SocialCast workflow showing a publisher creating a bounded set of replicas, carriers forwarding only to higher-utility nodes, and subscribers receiving matching content
Figure 15.1: SocialCast bounded-replication workflow for DTN publish-subscribe delivery

Read Figure 15.1 from “Publisher” to “Carrier A”. Taken together, “Publisher” and “Carrier A” express socialCast bounded-replication workflow for DTN publish-subscribe delivery. For socialCast: Social-Based DTN Routing, the observed relationship between “Publisher” and “Carrier A” is evidence that “Publisher” carries into the next decision.

SocialCast extends CAR by exploiting social network structures for packet dissemination.

15.5.1 SocialCast Concepts

Key Insight: People with similar interests tend to be colocated periodically.

Application: Publish-subscribe in DTN

  • Publishers: Generate content
  • Subscribers: Want to receive content matching interests
  • Carriers: Mobile nodes with high utility transport messages

SocialCast creates a fixed number of replicas at publication time. Each replica moves only when the encountered node has higher delivery utility, so the copy count stays bounded while messages drift toward likely subscribers.

15.5.2 SocialCast Protocol

Message Replication Strategy:

  1. Create gamma replicas at publisher
  2. Forward only to “better” carriers:
    • Better = utility(neighbor) > utility(self)
  3. Carriers hold messages until:
    • Finding even better carrier, OR
    • Encountering subscriber
  4. Replicas never increase (bounded replication)
  5. TTL prevents infinite lifetime

Key Properties:

  • Bounded replicas: Only gamma copies exist (doesn’t grow like epidemic)
  • Selective forwarding: Only to higher-utility nodes
  • Upgrade path: Replicas “climb” to better carriers over time
  • Subscriber participation: Subscribers with high utility can act as carriers

15.5.3 SocialCast Performance

Delivery and overhead vs replicas:

Before socialCast Performance, inspect Figure 15.2 to compare “Good balance for” with “gamma = 14+”. Their juxtaposition makes socialCast delivery and overhead trade-off as gamma increases visible.

Chart summarizing how SocialCast delivery improves with gamma from 2 to 10 replicas while copy overhead also rises, with the 5 to 10 replica range highlighted as the usual operating zone
Figure 15.2: SocialCast delivery and overhead trade-off as gamma increases

Read Figure 15.2 from “Good balance for” to “gamma = 14+”. Taken together, “Good balance for” and “gamma = 14+” express socialCast delivery and overhead trade-off as gamma increases. For socialCast Performance, the observed relationship between “Good balance for” and “gamma = 14+” is evidence that “Good balance for” carries into the next decision.

More replicas improve delivery because more carriers can discover useful contacts. The benefit flattens after roughly 5-10 replicas, while storage, bandwidth, and energy cost continue to rise.

Optimal Configuration:

  • gamma = 5-10 for most scenarios
  • Balance: 88-93% delivery with 200-350% overhead
  • Compare to epidemic: 95% delivery with 800-1200% overhead

TTL Impact:

Longer TTL values usually improve delivery in sparse networks because a copy has more time to encounter a better carrier or subscriber. The trade-off is buffer pressure: every extra hour of TTL keeps stale data in constrained devices longer.

SocialCast Utility Calculation

Scenario: A smart city deploys sensors on delivery vehicles for air quality monitoring. Calculate which vehicle should carry pollution alerts to city hall.

Given:

  • Vehicle A: Delivers to suburbs, encounters city hall area 1x/week
  • Vehicle B: Downtown route, passes city hall 3x/day
  • Vehicle C: Mixed route, passes city hall 1x/day
  • Current carrier: Vehicle A (utility U_A = 0.43 after calculation)
  • Message: PM2.5 alert for city hall environmental office

Steps:

  1. Calculate utility for each vehicle:

    • Utility formula: U(X, Dest) = alpha x P_encounter + beta x Freshness + gamma x Battery
    • Weights: alpha=0.6 (encounter probability), beta=0.3 (data freshness), gamma=0.1 (resources)

  2. Compute encounter probabilities:

    • P_A = 1/week = 0.14/day: U_encounter_A = 0.14
    • P_B = 3/day = 3.0/day: U_encounter_B = min(1.0, 3.0) = 1.0
    • P_C = 1/day = 1.0/day: U_encounter_C = 1.0

  3. Calculate total utilities:

    • U_A = 0.6(0.14) + 0.3(0.9) + 0.1(0.8) = 0.08 + 0.27 + 0.08 = 0.43
    • U_B = 0.6(1.0) + 0.3(0.7) + 0.1(0.9) = 0.60 + 0.21 + 0.09 = 0.90
    • U_C = 0.6(1.0) + 0.3(0.8) + 0.1(0.7) = 0.60 + 0.24 + 0.07 = 0.91

  4. Apply SocialCast forwarding rule:

    • Current: U_A = 0.43
    • Vehicle A encounters B: U_B (0.90) > U_A (0.43): Forward to B
    • Vehicle A encounters C: U_C (0.91) > U_A (0.43): Forward to C
    • Both B and C are “better carriers” - forward to whichever encountered first

Result: Message forwarded from Vehicle A to Vehicle B (or C), moving the alert from a weekly contact opportunity to a daily route past the destination.

Key Insight: SocialCast’s “utility climbing” ensures messages naturally flow toward nodes with better access to the destination. The delivery vehicle example shows how urban mobility patterns create predictable utility scores that SocialCast can exploit.

Blueprint BinaCheckpoint: SocialCast Discipline

You now know:

  • SocialCast creates gamma replicas once, then moves existing copies toward higher-utility carriers instead of growing the copy count like epidemic routing.
  • The usual 5-10 replica range aims for 88-93% delivery with 200-350% overhead, not epidemic-style 800-1200% overhead.
  • The forwarding rule is simple to state but strict to operate: transfer only when the neighbor’s utility is higher than the current carrier’s utility.

Test Your Understanding

Question 1: In context-aware routing, what is the primary purpose of the utility function U(X, D)?

a) To encrypt messages for secure delivery b) To calculate the probability that node X will successfully deliver a message to destination D c) To measure the physical distance between two nodes d) To compress data for efficient transmission

b) To calculate the probability that node X will successfully deliver a message to destination D. The utility function combines colocation probability (how often X encounters D), mobility patterns, and available resources (battery, buffer) into a single score. Messages are forwarded only to nodes with higher utility scores, ensuring they “climb” toward better carriers over time.

Question 2: Why does SocialCast use bounded replication (gamma copies) instead of unlimited replication like epidemic routing?

a) Bounded replication provides higher delivery ratios b) Bounded replication limits resource consumption while maintaining good delivery (88-93%) c) SocialCast cannot create more than one copy d) Unlimited replication is impossible in mobile networks

b) Bounded replication limits resource consumption while maintaining good delivery. SocialCast creates only gamma copies (typically 5-10), which is sufficient for 88-93% delivery but uses 3-5x fewer resources than epidemic routing’s unlimited copies. For battery-constrained IoT devices, this resource efficiency is critical. The slight reduction in delivery ratio (from 95% to 88%) is an acceptable trade-off.

Question 3: A delivery vehicle (Vehicle B) passes city hall 3 times per day. Another vehicle (Vehicle A) passes it once per week. Using SocialCast’s forwarding rule, what happens when Vehicle A carrying a message for city hall encounters Vehicle B?

a) Vehicle A keeps the message since it was the original carrier b) Vehicle A forwards the message to Vehicle B because B has higher utility for city hall c) Both vehicles keep a copy of the message d) The message is dropped because neither vehicle is at city hall

b) Vehicle A forwards the message to Vehicle B because B has higher utility. SocialCast’s core rule is: forward only to nodes with utility(neighbor) > utility(self). Vehicle B’s encounter rate with city hall (3/day) is much higher than Vehicle A’s (1/week), giving B a higher utility score. The message “climbs” to the better carrier, dramatically increasing delivery probability from 14% to nearly 100% per day.

15.6 SocialCast Utility Function Explorer

Adjust the weights and node parameters to see how the utility score changes:

15.7 SocialCast Advantages for IoT

Why SocialCast Works Well:

  1. Interest-based grouping: IoT devices often have natural clusters

    • Smart home devices in same household
    • Wearables owned by same person
    • Sensors monitoring same phenomenon

  2. Predictable mobility: Many IoT devices follow patterns

    • Wearables: user’s daily routine
    • Vehicles: repeated routes
    • Drones: scheduled flight paths

  3. Resource efficiency: Bounded replication suits energy-constrained IoT

  4. Scalability: Local utility decisions scale better than global knowledge

Example IoT Applications:

  • Smart city: Traffic sensors publish updates, delivered to vehicles in area
  • Wildlife monitoring: tracking collars exchange data via high-mobility carriers
  • Wearable health: Health data from many users aggregated via mobile phone carriers

15.8 Knowledge Check

Quiz: SocialCast Protocol

15.9 Community Mesh Routing

Case Study: Community-Managed Mesh Links

Community Wi-Fi mesh networks are not automatically DTNs, and they are not formal SocialCast deployments. They are still useful design analogies because administrators often route content through people and links they trust to be available at predictable times.

How the analogy maps to social routing:

  • Utility function: local operators know which rooftop links, relays, or users are reliable.
  • Encounter probability: evening usage windows and scheduled maintenance create predictable contact opportunities.
  • Bounded replication: popular files are cached on a small number of reliable mirrors instead of copied everywhere.
  • Utility climbing: content moves from peripheral nodes toward better-connected local hubs before crossing weak links.

Design lesson: social routing should be treated as an engineering trade-off, not a magic replacement for connectivity. It works best when contact patterns are predictable, resources are scarce, and forwarding decisions can be made from recent local evidence. Before using SocialCast-like logic in production, collect trace data from the target environment and validate delivery, latency, energy, and privacy impact.

15.10 Concept Relationships

  • Utility functions select carriers by combining encounter probability, mobility patterns, and resource state.
  • SocialCast bounded replication creates limited copies that climb toward higher-utility carriers.
  • Context-aware routing reduces overhead compared with epidemic flooding by forwarding selectively.
  • Colocation prediction uses past encounter history to estimate future contact probability.
  • Social network structure matters only when contact patterns are stable enough to support intelligent forwarding decisions.

15.11 See Also

DTN Fundamentals

Store-carry-forward foundation.

DTN Epidemic Routing

Flooding baseline for comparison.

DTN Applications

ZebraNet and DakNet deployments.

Ad Hoc Routing: Reactive (DSR)

Connected network on-demand routing.

Multi-Hop Fundamentals

Relay and forwarding concepts.
Interactive Quiz: Match Concepts
Interactive Quiz: Sequence the Steps

Common Pitfalls

Social routing relies on contact history as a predictor of future contacts. Work schedules, commuting patterns, and social behavior change over weeks and months. Routing decisions based on stale contact history (months old) may be less accurate than routing based on current network state. Implement contact history decay to weight recent contacts more heavily.

Betweenness centrality requires global network graph knowledge — knowing all nodes and their interconnections. In a distributed DTN, this information is unavailable. Practical social routing uses local approximations (encounter counts, two-hop neighbor counts) that underestimate true centrality.

Social routing exploits human mobility patterns (workplace, home, social events). Animal tracking, vehicle networks, or robot swarms have different mobility patterns that may not exhibit the community structure social routing exploits. Always validate that the target environment exhibits social-like contact patterns before applying social routing.

Social routing requires nodes to share and track contact history. This creates detailed records of who met whom and when — personal location data. Deployments must consider privacy implications and anonymization techniques. Publishing contact graphs can reveal sensitive information about individuals’ movements.

Label the Diagram
Code Challenge

15.12 Summary

This chapter covered context-aware and social-based DTN routing:

  • Context-Aware Routing (CAR): Uses utility functions combining colocation probability, mobility patterns, social relationships, and resources to make intelligent forwarding decisions, reducing overhead to 200-350% while maintaining 88-93% delivery
  • Utility Function Design: The formula U(X, D) = alpha * P_colocation + beta * Mobility + gamma * Resources provides a mathematical framework for carrier selection
  • Colocation Prediction: Kalman filters use past encounter history to predict future contact probabilities, enabling “smart” forwarding
  • SocialCast Protocol: Creates bounded gamma replicas that “climb” to higher-utility carriers over time, exploiting social network structures for publish-subscribe in DTN
  • Performance Optimization: gamma = 5-10 replicas typically achieves 88-93% delivery with 200-350% overhead, compared to epidemic’s 95% delivery with 800-1200% overhead
  • IoT Suitability: SocialCast works well for IoT due to natural device clustering, predictable mobility patterns, resource efficiency, and local decision scalability

15.13 What’s Next

15.14 Key Takeaway

Social routing uses repeated contact patterns, communities, or central nodes to improve DTN forwarding. It only works when those patterns are real, measured, and acceptable from a privacy and governance standpoint.

15.15 Continue Your Route

This final part closes the route from SocialCast: Social-Based DTN Routing through Key Takeaway. Return to DTN Social Routing: Contact and Utility Models or continue from the emerging-paradigms module index.